CuteDSL, latentna teleportacja i najkrótsza droga do szybszej generacji

Obciążenia generatywne są często opisywane tak, jakby model był całym systemem. W praktyce, wolną częścią może być ruch wokół modelu: ładowanie wag, tłumaczenie formatów, kopiowanie tensorów, czekanie na pracownika i odrzucanie pośredniego wyniku, który mógłby zostać ponownie wykorzystany przez inny etap.

CuteDSL to użyteczny sposób myślenia o tej granicy. Mały, deklaratywny opis pracy może podróżować przez system, podczas gdy kosztowna reprezentacja pozostaje blisko akceleratora. Celem nie jest sprytna składnia; chodzi o utrzymanie niskich kosztów orkiestracji i zajętości wnioskowania.

Na co wskazuje „latentna teleportacja”

Użyj tej frazy jako modelu mentalnego: przenieś kompaktowy latent lub już użyteczny półprodukt między kompatybilnymi etapami, zamiast za każdym razem rekonstruować cały problem z pikseli lub tekstu. Jeśli zmiana rozmiaru, przejście stylu, przejście czasowe lub skalowanie w górę może bezpośrednio wykorzystać tę reprezentację, potok unika niepotrzebnych pętli dekodowania-kodowania.

Trzy miejsca, w których pojawiają się oszczędności

1. Utrzymaj rezydencję ścieżki krytycznej

Rozgrzej workerów i ponownie użyj załadowanych wag. Kolejka powinna decydować, co zostanie uruchomione jako następne, a nie wielokrotnie odbudowywać środowisko wykonawcze.

2. Grupuj kompatybilne zadania

Obrazy o tym samym kształcie, modelu i precyzji mogą współdzielić konfigurację. Grupowanie jest najbardziej użyteczne, gdy harmonogram widzi wystarczająco dużo pracy wystarczająco wcześnie, aby utworzyć partię.

3. Buforuj właściwą granicę

Buforuj deterministyczne przetwarzanie wstępne i możliwe do ponownego użycia warunkowanie. Nie buforuj gigantycznego artefaktu końcowego, gdy kompaktowy półprodukt może służyć wielu konsumentom końcowym.

Szkic kompaktowego potoku

request -> normalize prompt + references
        -> choose model / shape / precision
        -> warm worker or form a compatible batch
        -> generate in latent space
        -> decode only at the delivery boundary
        -> durable result + usage record

Ważna granica to ta ostatnia. Dekoduj, gdy człowiek lub zewnętrzne API potrzebuje pikseli lub klatek, a nie za każdym razem, gdy wewnętrzny etap chce podjąć decyzję.

Zmierz całą ścieżkę

Śledź osobno czas oczekiwania w kolejce, uruchamianie workera, ładowanie modelu, wnioskowanie, dekodowanie, przesyłanie i czas do pierwszego podglądu. Szybsze jądro jest miłe, ale rozgrzany worker, który eliminuje dziesięciosekundowe uruchamianie, jest często większym zwycięstwem. Zoptymalizuj najwolniejszy widoczny segment, a następnie zmierz ponownie z rzeczywistymi promptami i rzeczywistymi kształtami wyjściowymi.