Jak rozmiar partii wpływa na opóźnienie pierwszego tokena i opóźnienie na token?

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.

How Does Batch Size Affect First-Token and Per-Token Latency? - Zima Store Online

Większe partie często zwiększają całkowitą przepustowość tokenów, ale mogą wydłużać opóźnienie do pierwszego tokena i opóźnienie pojedynczego tokena wskutek kolejkowania, cięższych iteracji oraz presji na pamięć.

Lokalny model przy rozmiarze partii równym jeden może niewykorzystywać w pełni akceleratora, ponieważ każdy krok dekodowania przenosi wagi modelu przy niewielkiej ilości pracy. Łączenie żądań pozwala zamortyzować ten transfer i zwiększyć przepustowość. Żądania mogą jednak czekać na przyjęcie, długie operacje prefill mogą blokować dekodowanie, a każda aktywna sekwencja zwiększa rozmiar pamięci podręcznej KV i ilość pracy związanej z tokenami, dlatego optymalny rozmiar partii zależy od tego, czy celem jest przepustowość, szybkość reakcji czy goodput w ramach założonego celu opóźnienia.

Partiowanie amortyzuje pracę modelu między żądaniami

Operacja macierzowa wykonywana na partii przetwarza tokeny z wielu sekwencji jednocześnie, poprawiając wykorzystanie sprzętu i rozkładając stałe koszty uruchamiania lub transferu wag na większą ilość użytecznej pracy. Zyski są największe, zanim nastąpi nasycenie mocy obliczeniowej, przepustowości pamięci, pojemności pamięci podręcznej lub narzutu planowania.

W systemie Orca harmonogramowanie na poziomie iteracji umożliwia opuszczanie partii przez ukończone sekwencje i dołączanie nowej pracy między iteracjami dekodowania. Dzięki temu każde żądanie nie musi czekać na najdłuższy element statycznej partii.

Rozmiar partii może oznaczać skonfigurowane maksimum, przyjęte sekwencje lub liczbę tokenów przetwarzanych w jednej iteracji. Wartości te różnią się przy ciągłym partiowaniu, dlatego raporty wydajności powinny wskazywać, która wielkość była kontrolowana i obserwowana. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Opóźnienie do pierwszego tokena obejmuje kolejkowanie i prefill

Czas do pierwszego tokena zaczyna się w chwili nadejścia żądania i obejmuje oczekiwanie na harmonogramowanie, wstępne przetwarzanie promptu oraz pierwszy krok dekodowania. Strategia, która czeka na zebranie partii, może wydłużyć czas w kolejce, a przyjęcie dużego promptu może zająć iterację i opóźnić istniejące żądania interaktywne.

Aktualne porównanie ciągłego partiowania wyjaśnia, jak ciągłe partiowanie dynamicznie przyjmuje i usuwa żądania oraz jak agresywne harmonogramowanie równoważy przepustowość z TTFT. Pokazuje, dlaczego sam rozmiar partii nie wystarcza do przewidywania szybkości reakcji do pierwszego tokena. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja przejmie dalsze działania.

Partiowanie fragmentów prefill może przeplatać długie prompty z pracą dekodowania, ale rozmiar fragmentu staje się kolejnym kompromisem. Małe fragmenty chronią tokeny interaktywne, lecz zwiększają narzut harmonogramowania; duże fragmenty poprawiają efektywność prefill, jednocześnie tworząc dłuższe okresy blokowania. Tę granicę należy mierzyć osobno w realistycznych warunkach pracy.

Opóźnienie pojedynczego tokena zależy od bieżącej iteracji

Podczas dekodowania jeden krok zazwyczaj generuje jeden token dla każdej aktywnej sekwencji. Większa liczba sekwencji powiększa partię i może wydłużyć czas każdej iteracji, nawet gdy łączna liczba tokenów na sekundę rośnie. Nierówne długości kontekstów, presja na pamięć podręczną, wywłaszczanie i synchronizacja rozproszona zwiększają zmienność.

Rozdzielenie prefill i dekodowania w DistServe wynika z ich odmiennych właściwości obliczeniowych i celów obsługi. Projekt pokazuje, dlaczego optymalizacja łącznej przepustowości może kolidować zarówno z TTFT, jak i czasem generowania pojedynczego tokena. Praktyczne konsekwencje pojawiają się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Granica błędu pojawia się przy wyborze największej partii na podstawie wykresu przepustowości offline dla interaktywnego domowego asystenta. Jeśli kolejkowanie lub odstępy między tokenami naruszają cel istotny z punktu widzenia użytkownika, nominalna przepustowość nie jest użytecznym goodputem, niezależnie od wykorzystania akceleratora.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Wyznacz granicę goodputu dla partiowania

Odtwarzaj krótkie rozmowy, długie prompty RAG i zadania działające w tle przy kontrolowanych częstotliwościach napływu. Testuj różne maksymalne liczby sekwencji i limity tokenów w partii, mierząc percentyle TTFT, opóźnienie między tokenami, opóźnienie całościowe, przepustowość promptów i wyników, głębokość kolejki, wykorzystanie pamięci podręcznej, wywłaszczanie oraz odrzucone żądania.

Wykorzystaj zachowanie ciągłego partiowania opisane w zachowaniu ciągłego partiowania, aby odróżnić skonfigurowane limity od rzeczywistej partii widocznej w każdej iteracji. Zachowaj stały rozkład promptów i wyników oraz raportuj odsetek żądań spełniających jednocześnie cele dotyczące pierwszego tokena i odstępów między tokenami.

Wybierz ustawienie, które maksymalizuje ilość ukończonej pracy w ramach tych celów, zamiast surowej liczby tokenów na sekundę. Izoluj partie działające w tle lub nadaj im niższy priorytet, gdy ograniczają interaktywny goodput, a następnie powtórz testy po zmianach modelu, kwantyzacji, zestawu kontekstów lub harmonogramu.