Dlaczego przetwarzanie promptu może wyprzedzać lokalne generowanie tokenów?

Przetwarzanie promptu może wyprzedzać generowanie tokenów, ponieważ akcelerator ocenia wiele tokenów wejściowych równolegle, ale tokeny wyjściowe musi dekodować sekwencyjnie.

Domowy panel AI może raportować setki lub tysiące tokenów promptu na sekundę, podczas gdy strumieniowane dane wyjściowe pojawiają się ze znacznie niższą częstotliwością. Te liczby opisują różne fazy wykonywania, a nie sprzeczne pomiary. Prefill przetwarza dostarczony kontekst jako blok i buduje stan uwagi, natomiast dekodowanie wielokrotnie uruchamia model, aby za każdym razem przyjąć tylko jeden nowy token. Różnica zależy od długości promptu, rozmiaru modelu, przepustowości pamięci, wsadowania, układu pamięci podręcznej oraz tego, czy inne żądania działające w tle współdzielą ten sam akcelerator.

Prefill i dekodowanie rozwiązują różne problemy obliczeniowe

Przetwarzanie promptu, często nazywane prefill, ocenia sekwencję wejściową i tworzy stan KV potrzebny do późniejszego generowania. Dekodowanie rozpoczyna się dopiero po utworzeniu tego początkowego stanu i wydłuża sekwencję token po tokenie.

Badania nad obsługą LLM opisują prefill ograniczone obliczeniami oraz dekodowanie ograniczone przepustowością pamięci jako odrębne fazy o różnym zachowaniu sprzętu.

Ten sam model może więc osiągać wysoką przepustowość prefill i znacznie niższą przepustowość tokenów wyjściowych bez żadnej awarii. Każda metryka zlicza tokeny przechodzące przez inną ścieżkę wykonywania.

Tokeny promptu można oceniać w dużych macierzach równoległych

Podczas prefill wiele pozycji zapytań jest dostępnych jednocześnie. Mnożenia macierzy mogą łączyć operacje w obrębie sekwencji, partii, głów i wymiarów ukrytych, zapewniając akceleratorowi wystarczającą liczbę równoległych operacji, aby pozostawał obciążony.

FlashAttention ogranicza narzut mechanizmu uwagi dzięki kafelkowym obliczeniom uwagi, które zapobiegają wielokrotnemu umieszczaniu pełnej macierzy uwagi w wolnej pamięci urządzenia.

Dłuższe prompty zwiększają łączną ilość pracy podczas prefill, ale mogą także poprawiać wykorzystanie obliczeń do momentu, gdy dominujące staną się ograniczenia pojemności pamięci, jąder obliczeniowych lub złożoności mechanizmu uwagi.

Jest to przepustowość dla całego bloku wejściowego, a nie oznaka, że serwer może generować taką samą liczbę niezależnych tokenów wyjściowych w każdej sekundzie.

Dekodowanie nie może ustalić następnego tokenu przed bieżącym

Generowanie autoregresywne wybiera lub próbuje jeden token, dołącza go do sekwencji, a następnie uruchamia kolejny krok modelu zależny od zaakceptowanego wyniku. Następny zaakceptowany token nie jest znany z wyprzedzeniem.

DistServe rozdziela te dwie fazy, ponieważ iteracje dekodowania wielokrotnie uzyskują dostęp do wag modelu i aktywnego stanu KV, generując przy tym tylko niewielką ilość nowych danych wyjściowych dla każdej sekwencji.

Wsadowanie kilku użytkowników może zrównoleglić wiele sekwencji dekodowania, ale pojedyncza rozmowa nadal rozwija się jako łańcuch zależnych od siebie decyzji dotyczących tokenów.

Dekodowanie spekulatywne może wspólnie zweryfikować kilka wstępnie przygotowanych kandydatów, jednak zwykłe dekodowanie pozostaje szeregowe, gdy żadne kandydaty nie zostały wcześniej zaakceptowane.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Wysoka przepustowość promptu nadal może oznaczać długie oczekiwanie na pierwszy token

Liczba tokenów na sekundę dzieli ukończoną pracę nad promptem przez jego rozmiar. Bardzo długi kontekst może zapewniać imponującą przepustowość, a mimo to wymagać kilku sekund oczekiwania, zanim pojawi się pierwszy wygenerowany token.

ZimaSpace rozdziela ładowanie, ocenę promptu i generowanie w omówieniu etapów opóźnienia AI. Rozgrzany model eliminuje opóźnienie związane z ponownym ładowaniem, ale nie usuwa kosztu oceny dużego promptu.

Czas do pierwszego tokenu jest więc lepszą miarą interaktywności w przypadku prefill. Liczba tokenów promptu na sekundę przydaje się do porównywania efektywności środowiska wykonawczego przy przetwarzaniu danych wejściowych o różnej długości.

Długie operacje prefill mogą spowalniać użytkowników, którzy już dekodują

Dokument wymagający dużej mocy obliczeniowej może trafić na ten sam akcelerator w chwili, gdy inny użytkownik otrzymuje strumieniowane tokeny. Jeśli środowisko wykonawcze połączy oba obciążenia bez odpowiedniej kontroli, duże zadanie prefill może wydłużyć iteracje dekodowania.

DistServe raportuje silne zakłócenia między prefill a dekodowaniem, gdy obie fazy są umieszczone na tym samym akceleratorze i wspólnie planowane.

Serwer może nadal wykazywać wysokie łączne wykorzystanie zasobów, ale aktywny czat doświadcza większych przerw między tokenami. Przepustowość i płynność widoczna dla użytkownika mogą zmieniać się w przeciwnych kierunkach.

Oddzielne procesy robocze, planowanie uwzględniające fazy lub zarezerwowane możliwości dekodowania mogą chronić interaktywne dane wyjściowe, jeśli pozwalają na to sprzęt i środowisko wykonawcze.

Dzielenie na fragmenty poświęca część efektywności prefill na rzecz lepszej responsywności

Środowisko wykonawcze może podzielić jeden długi prompt na mniejsze fragmenty i przeplatać ich przetwarzanie z pracą dekodowania. Prompt wymaga wtedy większej liczby kolejek planisty, ale żaden pojedynczy etap prefill nie blokuje akceleratora podczas jednej bardzo długiej iteracji.

Sarathi-Serve wykorzystuje prefill podzielony na fragmenty, aby ograniczać zakłócenia przy zachowaniu użytecznych możliwości wsadowania.

Najlepszy rozmiar fragmentu zależy od długości promptów, architektury modelu, możliwości akceleratora oraz docelowego opóźnienia dla aktywnych rozmów.

Mierz osobno czas przetwarzania promptu, czas do pierwszego tokenu, czas między tokenami oraz liczbę tokenów wyjściowych na sekundę. Faza o niższej przepustowości podawanej w nagłówku nie musi automatycznie odpowiadać za najdłuższe oczekiwanie użytkownika.