Servire dezagregată pentru completare și decodificare
O arhitectură de servire care împarte inferența modelului de limbaj mare în două faze separate — precompletare și decodare — și le rulează pe grupuri diferite de GPU.
Prezentare generală
It matters because these two phases have opposite hardware appetites, and forcing them onto the same machines wastes capacity and hurts latency.
Scufundare în profunzime
Când un LLM răspunde, funcționează în două etape. Precompletarea citește întreaga solicitare simultan și construiește memoria cache-cheie-valoare (KV); aceasta este o rafală mare, paralelă, legată de calcul, care saturează unitățile matematice ale GPU-ului. Decodificarea generează apoi token-uri pe rând, fiecare pas citind întregul cache KV - un proces de calcul ușor legat de lățimea de bandă a memoriei. Rulați împreună, o pre-umplere lungă blochează decodarea tuturor (blocarea capului de linie), iar gruparea celor două creează interferențe. Dezagregarea pune precompletarea unui grup de GPU și decodifică pe altul, transferând memoria cache KV între ele prin interconexiuni rapide precum NVLink sau InfiniBand. Fiecare grup este reglat și scalat în mod independent, îmbunătățind randamentul bun, netezind latența finală și permițând operatorilor să atingă ținte strânse de timp până la primul token și timp pe jeton de ieșire simultan.
Perspectivă tehnică
Cele două faze diferă prin blocajul lor. Prefill procesează toate jetoanele prompt în paralel, astfel încât FLOP-urile sale se scalează cu lungimea promptului și maximizează nucleele tensorului. Decodarea este autoregresivă: fiecare token nou are nevoie de o trecere înainte care recitește întregul cache KV de la HBM, astfel încât debitul este determinat de lățimea de bandă a memoriei, nu de calcul. Dezagregarea exploatează acest lucru prin dimensionarea, gruparea și chiar alegerea unui paralelism diferit pentru fiecare grup, apoi trimiterea cache-ului KV de la lucrătorii de precompletare pentru a decoda lucrătorii.
Impact strategic
Cost și buget
Deciziile de arhitectură generează performanța și costurile de operare de ani de zile.
Decizii mai clare
Educația tehnică ajută echipele să aleagă stiva potrivită, nu doar cea mai nouă.
Controlul calității
Opțiuni de inginerie mai bune reduc incidentele de fiabilitate în producție.
Viitorul servirii dezagregate de precompletare și decodare
Așteptați-vă ca dezagregarea să devină implicită în stivele de producție. Sisteme precum DistServe, Splitwise și Mooncake l-au popularizat, iar vLLM și NVIDIA Dynamo oferă acum moduri dezagregate. Cercetările promovează optimizările transferului KV-cache, poolingul și reutilizarea cache-ului între solicitări, reechilibrarea dinamică a rapoartelor de pre-completare/decodare în condiții de schimbare a traficului și o integrare mai strânsă cu memorarea în cache a prefixelor și pre-completarea fragmentată. Pe măsură ce ferestrele de context cresc în milioane de jetoane, separarea acestor faze devine din ce în ce mai esențială pentru difuzarea rentabilă, cu latență redusă.
Implementare în lumea reală
Un asistent de chat direcționează solicitările de documente lungi către un cluster de pre-completare cu un număr mare de calculatoare, apoi transmite răspunsuri dintr-un cluster de decodare optimizat pentru memorie pentru a menține latența de tastare fără probleme.
NVIDIA Dynamo și vLLM le permit operatorilor să implementeze grupuri separate de precompletare și decodare de lucrători, astfel încât o explozie de solicitări lungi să nu înghețe generațiile în curs.
Mooncake (folosit de Kimi de la Moonshot AI) dezagregează pre-completarea și decodifică și adaugă un grup de cache KV distribuit pentru a reduce recalcularea promptă redundantă la scară.
Un serviciu de completare a codului dedică un mic grup de precompletare pentru solicitări scurte și un grup mare de decodare, deoarece majoritatea costurilor provin din transmiterea în flux a multor jetoane de ieșire.
Riscuri și balustrade
Optimizarea unui punct de referință poate ascunde slăbiciunile mai largi ale sistemului.
Costurile de infrastructură și întreținere sunt adesea subestimate.
Lacunele de securitate și observabilitate pot crește pe măsură ce sistemele devin mai complexe.
Foaia de parcurs de implementare
Definiți obiectivele de latență, calitate și cost înainte de implementare.
Benchmark în condiții realiste de încărcare și date.
Monitorizarea instrumentelor pentru erori, deriva și impactul utilizatorului.
Pregătiți căile de retragere și răspuns la incident înainte de scalare.
Continuați să explorați
Free newsletter
Get the daily AI briefing
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Take the Disaggregated Prefill and Decode Serving quiz
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
Următorul ghid
KServe și Model Serving pe Kubernetes
Întrebări frecvente
What is Disaggregated Prefill and Decode Serving?
O arhitectură de servire care împarte inferența modelului de limbaj mare în două faze separate — precompletare și decodare — și le rulează pe grupuri diferite de GPU. Contează pentru că aceste două faze au apetite hardware opuse, iar forțarea lor pe aceleași mașini irosește capacitatea și dăunează latenței.
What is the core hardware reason for separating prefill and decode onto different GPU pools?
Prefill processes the whole prompt in parallel and saturates compute, while decode reads the KV cache each step and is limited by memory bandwidth—opposite appetites that justify separate, independently tuned pools.
What data structure must be transferred from prefill workers to decode workers?
Prefill builds the KV cache for the prompt; decode needs that cache to continue generating, so the cache is shipped over a fast interconnect to the decode pool.
Which problem does disaggregation specifically reduce in a shared-GPU setup?
On shared GPUs a long prefill burst can block ongoing decode steps; separating them prevents that interference and stabilizes tail latency.
Why can prefill be batched aggressively but decode benefits from different tuning?
Prefill processes all prompt tokens together, so larger batches feed the tensor cores well; decode generates one token at a time and is gated by memory, so it scales differently.
Which interconnects are typically used to move the KV cache between disaggregated pools?
High-bandwidth, low-latency links like NVLink (intra-node) and InfiniBand (inter-node) are needed so KV-cache transfer doesn't become the new bottleneck.