Disaggregated Serving
Disaggregated Serving w kontekście LLM oznacza wykonywanie Prefill i Decode na osobnych instancjach i zasobach obliczeniowych. Jedna pula przetwarza prompty, druga kontynuuje generowanie odpowiedzi. Między nimi trzeba przekazać stan potrzebny do dalszych obliczeń, przede wszystkim KV Cache.
DistServe, §2.3–3.3 opisuje powód tego podziału: długi Prefill może zakłócać generowanie innych odpowiedzi, a obie fazy mają różne potrzeby związane z batchingiem i równoległością. Osobne pule pozwalają dobrać im inną liczbę GPU i konfigurację. Każda nadal wykonuje właściwe dla swojej fazy operacje modelu; nie jest to po prostu podział jego warstw na dwie połowy.
Przekazanie stanu też zajmuje czas
W DistServe instancja Prefill wyznacza pierwszy token, a instancja Decode otrzymuje go wraz z cache i generuje kolejne. Pierwszy token może więc być dostępny przed zakończeniem transferu; opóźnienie przekazania stanu może pojawić się między nim a następnym tokenem.
Własny bilans: zostało 64 MiB cache do przesłania. Przy efektywnym transferze 1 GiB/s samo przesłanie trwa 62,5 ms, a przy 8 GiB/s — 7,8125 ms. Korzystamy z , z jednostkami binarnymi. To obliczenie dydaktyczne przy stałej przepustowości, bez narzutów i nakładania transferu na obliczenia.
Zmień przepustowość i porównaj transfer z umownym opóźnieniem 20 ms, którego udałoby się uniknąć przez rozdzielenie faz. Przy 1 GiB/s bilans tego uproszczenia jest niekorzystny, przy 8 GiB/s — korzystny. Granica wypada przy 3,125 GiB/s.
Dwie pule nie gwarantują przyspieszenia
Rzeczywisty bilans obejmuje również kolejki obu pul, zajętą pamięć, kopie wag, synchronizację i wykorzystanie GPU. DistServe, §4.2–4.3 i §7 wiąże rozmieszczenie instancji z dostępną siecią i omawia ograniczenia przy małej liczbie GPU. Wynik zależy od obciążenia oraz wymaganych opóźnień. Porównuj także Inter-token Latency: po szybkim pierwszym tokenie może nastąpić długa przerwa.
Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.