Prefill a dekodowanie: dlaczego inferencja LLM ma dwie fazy
Tłumaczenie automatyczne
Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.
Prefill przetwarza prompt i tworzy jego pamięć podręczną mechanizmu uwagi. Dekodowanie wykorzystuje tę pamięć do generowania kolejnych tokenów. Długi prefill lub prefill przetwarzany w partiach może efektywnie wykonywać duże operacje macierzowe; dekodowanie z małymi partiami często spędza więcej czasu na odczytywaniu wag oraz zapisanych w pamięci podręcznej kluczy i wartości.
To rozróżnienie pomaga inżynierom osobno diagnozować opóźnienie pierwszego tokenu i powolne generowanie kolejnych.
Ustal, która faza jest powolna
Zwykły autoregresyjny prefill wytwarza logity używane do próbkowania pierwszego tokenu wyjściowego. Kolejne kroki dekodowania dodają po jednym tokenie. Czas do pierwszego tokenu obejmuje też oczekiwanie w kolejce, tokenizację, planowanie i przesyłanie przez sieć, więc wysoki TTFT nie dowodzi, że sam prefill jest powolny.
| Objaw | Co zmierzyć przed zmianą serwera |
|---|---|
| Pierwszy token pojawia się później przy dłuższych promptach | Czas w kolejce i czas prefill według długości wejścia |
| Kolejne tokeny zwalniają przy dłuższej historii | Czas dekodowania i ruch związany z KV cache |
| Nowy długi prompt wstrzymuje inne strumienie | Iteracje planisty i odstępy między tokenami |
| Oddzielne serwery poświęcają czas na przesyłanie stanu | Liczba przesyłanych bajtów KV, przepustowość i oczekiwanie w kolejce |
Prefill ponownie wykorzystuje wagi dla różnych tokenów promptu. Implementacja może jednak wczytywać bloki macierzy więcej niż raz; nie gwarantuje dokładnie jednego odczytu każdej wagi z HBM. Splitwise opisuje, jak te fazy korzystają z różnych zasobów sprzętowych.
Co zmienia prefill w blokach
Prefill w blokach przetwarza długi prompt w kilku iteracjach planisty. Planista opisany w dokumentacji vLLM najpierw dopuszcza trwające żądania dekodowania i wykorzystuje pozostały budżet tokenów danej iteracji na prefill. Rzeczywisty rozmiar bloku zależy od dostępnego budżetu.
Może to ograniczyć przerwy w istniejących strumieniach, jednocześnie zwiększając TTFT nowego żądania. Mniejsze bloki wymagają też dodatkowej pracy planisty i ponownego odczytu wcześniejszego stanu pamięci podręcznej. Sarathi-Serve ocenia ten kompromis; dodatkowy czas prefill wynoszący około 25% przy blokach po 512 tokenów zmierzono dla Yi-34B z równoległością tensorową o stopniu dwa.
Serwowanie rozdzielone umieszcza natomiast prefill i dekodowanie w oddzielnych pulach GPU. Pozwala dostroić każdą fazę niezależnie, ale wymaga przesłania KV cache żądania. Przed przyjęciem tego projektu sprawdź koszt transferu i wykorzystanie pul. Podział na bloki zmienia planistę; rozdzielenie faz zmienia także wdrożenie i komunikację.
Przewodnik inżynierski: prefill a dekodowanie zawiera osie czasu dla obu podejść.