Chunked Prefill

Chunked Prefill dzieli przetwarzanie promptu na mniejsze porcje, które scheduler może rozłożyć na kolejne iteracje i łączyć z generowaniem odpowiedzi innych żądań. To sposób organizacji Prefill: cały prompt jest już znany, a następna porcja nadal korzysta z wcześniejszych pozycji. Podział nie skraca kontekstu modelu.

Długi prompt przyjęty do jednej iteracji może opóźnić kolejne tokeny już trwających odpowiedzi. W Sarathi-Serve, §4.1–4.3 i algorytm 3 scheduler najpierw rezerwuje miejsce na aktywne kroki generowania, a pozostały budżet wypełnia porcjami promptów. Autorzy łączą to z mieszaniem obu rodzajów pracy w jednym batchu.

Podziel budżet między trzy żądania

Własny przykład: A i B generują już odpowiedzi, C ma 12 tokenów promptu. Budżet wynosi 8 tokenów wejściowych na iterację. A i B zajmują po jednym miejscu, więc dla C zostaje 6. Dwie iteracje kończą Prefill C, a A i B wykonują po dwa kroki generowania. Przy budżecie 4 dla C zostają tylko dwa miejsca: potrzeba sześciu iteracji. W każdej A i B nadal posuwają się o krok.

W demonstracji zmień budżet, zanim wykonasz kolejną iterację. Zobacz, kiedy C może po raz pierwszy odpowiedzieć. Zliczamy przydzielone pozycje, nie mierzymy milisekund: token promptu i krok generowania mogą mieć różny koszt.

Mniejsza porcja ma swój koszt

Dokumentacja vLLM 0.21.0, „Chunked Prefill” opisuje podobny priorytet i budżet max_num_batched_tokens. Mniejsze porcje mogą poprawić Inter-token Latency trwających odpowiedzi, lecz wydłużyć Time to First Token nowych żądań. Więcej porcji oznacza również narzut uruchomień i ponownych odczytów wcześniejszego cache. Rozmiar dobiera się do modelu, sprzętu i obciążenia; liczba tokenów sama nie gwarantuje czasu iteracji.

Continuous Batching pozwala zmieniać skład batcha między iteracjami. Chunked Prefill dodatkowo ogranicza porcję pracy nad długim promptem wpuszczaną do pojedynczej iteracji.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.