Dlaczego lokalne generowanie obrazów zwalnia po włączeniu podglądu na żywo?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does Local Image Generation Slow Down When Live Preview Is Enabled? - Zima Store Online

Lokalne generowanie obrazów zwalnia przy podglądzie na żywo, ponieważ obrazy pośrednie muszą zostać zdekodowane, przekonwertowane, skopiowane i wyświetlone, gdy odszumianie jest nadal uruchomione.

Model dyfuzyjny zwykle przechowuje stany pośrednie w kompaktowej reprezentacji ukrytej, dopóki obraz końcowy nie będzie gotowy. Podgląd na żywo dodaje dodatkową pracę między krokami próbkowania: dekoder rekonstruuje piksele, środowisko wykonawcze synchronizuje operacje urządzenia, a serwer może zakodować i przesłać klatkę. Powtarzanie tej ścieżki w wysokiej rozdzielczości może konkurować z samym generowaniem o moc obliczeniową i przepustowość pamięci.

Podgląd zamienia jedno końcowe dekodowanie na wiele dekodowań pośrednich

Bez podglądu sampler aktualizuje tensor ukryty przez wiele kroków i uruchamia dekoder obrazu tylko raz, pod koniec procesu. Podgląd w każdym kroku wielokrotnie uruchamia przybliżony lub pełny dekoder, zwielokrotniając pracę, która nie poprawia końcowej trajektorii odszumiania.

Dokumentacja dotycząca narzutu dekodowania podglądu wskazuje, że podglądy z pełnym VAE mogą znacznie wydłużyć czas działania, podczas gdy niewielki dekoder podglądu zmniejsza ten koszt, ale go nie eliminuje. Porównanie pokazuje, że wybór dekodera i częstotliwość podglądu są kluczowymi zmiennymi.

Spowolnienie rośnie wraz z liczbą pikseli, ponieważ zdekodowane mapy cech i klatki wyjściowe skalują się z rozdzielczością. Podgląd co piąty krok przy rozdzielczości 512 pikseli może być wystarczająco tani, ale dekodowanie w pełnej rozdzielczości w każdym kroku może zdominować krótki, przyspieszony przebieg próbkowania.

Synchronizacja urządzenia i ruch danych w pamięci przerywają pętlę próbkowania

Jądra akceleratora zwykle działają asynchronicznie, dzięki czemu środowisko wykonawcze może efektywnie kolejkować pracę. Odczyt podglądu z powrotem do hosta może wymusić synchronizację, przydzielić bufory obrazu, przenieść dane przez ścieżkę współdzielonej pamięci lub PCIe oraz zaczekać na konwersję przed wznowieniem próbkowania.

Architektura ukrytej dyfuzji wyjaśnia, dlaczego ukryta dyfuzja wykonuje kosztowną syntezę obrazów w skompresowanej przestrzeni i korzysta z autoenkodera do przechodzenia między pikselami a reprezentacją ukrytą. Każdy podgląd przekracza tę granicę wcześniej i częściej niż ścieżka generowania wyłącznie obrazu końcowego.

Systemy ze współdzieloną pamięcią unikają jawnego kopiowania przez PCIe, ale nadal konkurują o przepustowość i pojemność pamięci podręcznej. Dedykowane procesory graficzne mogą zamiast tego ponosić koszty transferu i synchronizacji. Widoczna klatka podglądu odzwierciedla więc zarówno dekodowanie neuronowe, jak i narzut systemowy.

Kodowanie obrazu może stać się wąskim gardłem po optymalizacji dekodowania

Lokalny interfejs internetowy może zmienić rozmiar podglądu, przekonwertować kolory, zakodować obraz jako JPEG lub PNG, zserializować go, wysłać przez gniazdo oraz poprosić przeglądarkę o zdekodowanie i wyrenderowanie. Niewielkie operacje powtarzane dziesiątki razy mogą trwać dłużej niż szybki, niewielki dekoder.

Badania nad potokiem dyfuzyjnym czasu rzeczywistego zmniejszają opóźnienie strumieniowej dyfuzji dzięki przetwarzaniu wsadowemu i optymalizacjom potoku, pokazując, że dane wyjściowe w czasie rzeczywistym zależą od całej ścieżki wykonania, a nie od pojedynczego jądra modelu. Transport podglądu pozostaje poza teoretyczną liczbą kroków odszumiania.

Błędem jest zakładanie, że każdy wolniejszy przebieg wynika z renderowania podglądu. Czas trwania mogą zmieniać różne ziarna, rozgrzewanie, ograniczenia termiczne, przenoszenie modelu między urządzeniami lub inne obciążenie GPU. Porównuj identyczne żądania z wyłączonym podglądem, zachowując wszystkie pozostałe ustawienia.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Mierz koszt podglądu według etapu i częstotliwości

Uruchom ten sam prompt, ziarno, model, sampler, liczbę kroków, rozdzielczość i rozmiar partii z wyłączonym podglądem, a następnie z podglądem co dziesiąty krok, co piąty krok i w każdym kroku. Zapisz całkowity czas, czas odszumiania, czas dekodowania, czas kodowania obrazu, liczbę przesłanych bajtów, częstotliwość renderowania przez przeglądarkę, szczytowe zużycie pamięci i wykorzystanie urządzenia.

Powiąż odczyty pamięci i obciążenia obliczeniowego z testowaniem wąskich gardeł zasobów, a następnie powtórz pomiar z niewielkim dekoderem i pełnym VAE. W każdym przebiegu pozostaw włączone końcowe dekodowanie obrazu, aby porównanie mierzyło wyłącznie dodatkowy koszt podglądów pośrednich.

Wybierz najrzadszą częstotliwość podglądu, która nadal zapewnia użyteczne informacje zwrotne. Jeśli dominuje dekodowanie, użyj mniejszego dekodera podglądu lub niższej rozdzielczości; jeśli dominuje kodowanie i transfer, łącz klatki; jeśli zmienia się czas odszumiania, zbadaj synchronizację i presję pamięci.