Czym jest rozdzielenie faz prefill i decode oraz dlaczego zmienia sposób obsługi modeli LLM?

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.

What Is Prefill-Decode Disaggregation, and Why Does It Change LLM Serving?

Rozdzielenie faz prefill i decode oddziela przetwarzanie promptu od generowania tokenów, dzięki czemu każda faza LLM może korzystać z innych workerów, harmonogramów i planów przepustowości.

Długi prompt RAG wymaga dużego skoku mocy obliczeniowej przed wygenerowaniem pierwszego tokena, podczas gdy dekodowanie wykonuje później wiele mniejszych iteracji wrażliwych na przepustowość pamięci. Uruchomienie obu faz na jednym GPU jest proste, ale pozwala, by długie operacje prefill przerywały aktywne rozmowy. Rozdzielenie przenosi żądanie i jego stan KV między pulami, zamieniając dodatkowy koszt koordynacji i transferu na niezależną kontrolę opóźnienia pierwszego tokena oraz opóźnienia każdego tokena.

Prefill i decode mają różne profile zasobów

Prefill przetwarza wszystkie tokeny promptu równolegle i buduje pamięć podręczną KV, generując intensywny obliczeniowo skok, którego czas rośnie wraz z długością promptu. Decode wielokrotnie odczytuje wagi modelu i zgromadzony stan KV, aby wygenerować jeden lub kilka nowych tokenów.

DistServe identyfikuje interferencję między prefill i decode, gdy obie fazy współdzielą GPU, i wiąże prefill z czasem do pierwszego tokena, podczas gdy decode wpływa na czas generowania każdego tokena wyjściowego. Ich rozdzielenie pozwala harmonogramowi niezależnie chronić każdy z tych celów. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Rozdzielenie nie jest zwykłym paralelizmem modelu. Ten sam model może istnieć w obu pulach, podczas gdy żądania przemieszczają się między funkcjonalnymi fazami, a nie między warstwami jednego przebiegu w przód. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Transfer KV łączy dwie pule workerów

Po zakończeniu prefill system musi udostępnić pamięć podręczną KV żądania workerowi decode. Może przesyłać tensory przez PCIe lub sieć, korzystać z pamięci współdzielonej albo rozmieszczać workery tak, aby ograniczyć koszt transferu.

Splitwise analizuje serwowanie zależne od fazy z maszynami i harmonogramowaniem dopasowanymi do faz, pokazując, dlaczego alokacja sprzętu może odpowiadać różnym charakterystykom obliczeniowym pracy nad promptem i tokenami. Kolejkowanie i przenoszenie stanu stają się częścią ścieżki obsługi. Tę granicę należy mierzyć osobno w realistycznych warunkach pracy.

Pula decode nie może rozpocząć pracy, dopóki nie otrzyma spójnego stanu KV i metadanych żądania. Duże konteksty zwiększają liczbę przesyłanych bajtów, dlatego pozornie szybszy podział faz może przegrać ze współlokowanym wykonaniem w małej sieci domowej.

Niezależne skalowanie zmienia planowanie przepustowości

Oddzielne pule mogą zwiększać przepustowość prefill dla dużych serii długich dokumentów bez proporcjonalnego zwiększania przepustowości decode albo chronić dekodowanie głosu, gdy przetwarzanie w tle zajmuje workery promptów. Kontrola przyjmowania może obsługiwać dwie kolejki i dwa budżety opóźnień. Praktyczne znaczenie widać, gdy kilka źródeł konkuruje o ograniczony kontekst.

Mooncake opisuje koordynację pamięci podręcznej KV, która traktuje przenoszenie i przechowywanie pamięci podręcznej KV jako podstawowe kwestie obsługi. Architektura pokazuje, że rozdzielenie przesuwa wąskie gardło z czystego harmonogramowania GPU w stronę transferu stanu i koordynacji pamięci podręcznej.

Granica opłacalności pojawia się przy niewystarczającej skali lub przepustowości. Jeden lub dwa domowe GPU mogą nie mieć wolnego urządzenia do specjalizacji, a zduplikowane wagi modelu wraz z transferem KV mogą zużywać więcej pamięci i powodować większe opóźnienia niż usuwana interferencja.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Porównaj budżety faz we współlokowanym i rozdzielonym wykonaniu

Mierz liczbę tokenów promptu na sekundę, czas do pierwszego tokena, czas na token wyjściowy, liczbę przesyłanych bajtów KV, czas transferu, oczekiwanie w kolejce, duplikację pamięci modelu, energię i odzyskiwanie po awarii dla krótkich, długich i mieszanych promptów. Ta zależność powinna pozostać wyraźnie określona w końcowym interfejsie.

Użyj segmentowanego prefill jako alternatywy współlokowanej. Najpierw przetestuj segmentowane prefill przed dodaniem drugiej puli, a następnie porównaj identyczne ślady napływu żądań w obu architekturach. Wynik należy zatem sprawdzić względem pierwotnych danych.

Stosuj rozdzielenie tylko wtedy, gdy zmierzono interferencję między fazami, a ścieżka transferu zachowuje oba cele dotyczące opóźnień. Na małym serwerze współlokowane harmonogramowanie z ograniczonymi segmentami prefill może zapewnić taki sam efekt dla użytkownika przy mniejszym transferze stanu.