Gedesaggregeerde prefill- en decodeerserving
Een dienende architectuur die de gevolgtrekking van grote taalmodellen opsplitst in twee afzonderlijke fasen (vooraf invullen en decoderen) en deze op verschillende groepen GPU's uitvoert.
Overzicht
It matters because these two phases have opposite hardware appetites, and forcing them onto the same machines wastes capacity and hurts latency.
Diepe duik
Wanneer een LLM antwoordt, werkt dit in twee fasen. Prefill leest de volledige prompt in één keer en bouwt de sleutelwaarde-cache (KV) op; dit is een grote, parallelle, rekengebonden burst die de wiskundige eenheden van de GPU verzadigt. Decode genereert vervolgens één voor één tokens, waarbij elke stap de hele KV-cache leest: een geheugenbandbreedte-gebonden, licht rekenstroompje. Als ze samen worden uitgevoerd, blokkeert een lange voorvulling de decodering van iedereen (head-of-line-blokkering), en het batchen van de twee zorgt voor interferentie. Disaggregatie plaatst prefill op de ene GPU-pool en decodering op een andere, waarbij de KV-cache tussen hen wordt overgedragen via snelle verbindingen zoals NVLink of InfiniBand. Elke pool wordt onafhankelijk afgestemd en geschaald, waardoor de goodput wordt verbeterd, de staartlatentie wordt afgevlakt en operators tegelijkertijd strakke tijd-tot-eerste-token- en tijd-per-uitvoer-token-doelen kunnen bereiken.
Technisch inzicht
De twee fasen verschillen in hun knelpunt. Prefill verwerkt alle prompttokens parallel, zodat de FLOP's schalen met de promptlengte en de tensorkernen maximaal worden benut. De decodering is autoregressief: elk nieuw token heeft één voorwaartse doorgang nodig die de volledige KV-cache van HBM opnieuw leest, zodat de doorvoer wordt bepaald door geheugenbandbreedte en niet door rekenkracht. Disaggregatie maakt hiervan gebruik door het formaat, batching en zelfs het kiezen van een ander parallellisme voor elke pool, en vervolgens de KV-cache van prefill-workers naar decodeer-workers te verzenden.
Strategische impact
Cost and budget
Architectuurbeslissingen bepalen jarenlang de prestaties en bedrijfskosten.
Clearer decisions
Technisch onderwijs helpt teams bij het kiezen van de juiste stapel, niet alleen de nieuwste.
Quality control
Betere technische keuzes verminderen het aantal betrouwbaarheidsincidenten in de productie.
De toekomst van gedesaggregeerde prefill- en decodeerserving
Verwacht dat disaggregatie een standaard wordt in productiestapels. Systemen als DistServe, Splitwise en Mooncake hebben het populair gemaakt, en vLLM en NVIDIA Dynamo leveren nu opgesplitste modi. Onderzoek stimuleert optimalisatie van KV-cache-overdracht, cache-pooling en hergebruik tussen verzoeken, dynamische herbalancering van prefill/decode-verhoudingen onder wisselend verkeer, en nauwere integratie met prefix-caching en chunked prefill. Naarmate contextvensters uitgroeien tot miljoenen tokens, wordt het scheiden van deze fasen steeds belangrijker voor kosteneffectieve dienstverlening met lage latentie.
Implementatie in de echte wereld
Een chatassistent stuurt lange documentprompts door naar een rekenintensief prefill-cluster en streamt vervolgens de antwoorden van een voor geheugen geoptimaliseerd decoderingscluster om de typlatentie soepel te houden.
Met NVIDIA Dynamo en vLLM kunnen operators afzonderlijke werkgroepen voor vooraf invullen en decoderen inzetten, zodat een reeks lange prompts de lopende generaties niet bevriest.
Mooncake (gebruikt door Kimi van Moonshot AI) splitst prefill en decodering op en voegt een gedistribueerde KV-cachepool toe om overtollige promptherberekening op schaal te voorkomen.
Een service voor het aanvullen van codes maakt gebruik van een kleine prefill-pool voor korte prompts en een grote decoderingspool, aangezien de meeste kosten voortkomen uit het streamen van veel uitvoertokens.
Risico's en vangrails
Het optimaliseren van één benchmark kan bredere systeemzwakheden verbergen.
Infrastructuur- en onderhoudskosten worden vaak onderschat.
De lacunes op het gebied van beveiliging en waarneembaarheid kunnen groter worden naarmate systemen complexer worden.
Implementatie routekaart
Definieer latentie-, kwaliteits- en kostendoelen vóór implementatie.
Benchmark onder realistische belasting- en gegevensomstandigheden.
Instrumentbewaking op fouten, drift en gebruikersimpact.
Bereid rollback- en incidentresponspaden voor voordat u gaat schalen.
Blijf verkennen
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
Next guide
KServe en Model Serving op Kubernetes
Frequently asked questions
What is Disaggregated Prefill and Decode Serving?
Een dienende architectuur die de gevolgtrekking van grote taalmodellen opsplitst in twee afzonderlijke fasen (vooraf invullen en decoderen) en deze op verschillende groepen GPU's uitvoert. Het is van belang omdat deze twee fasen tegengestelde hardware-eisen hebben, en het dwingen ervan op dezelfde machines capaciteit verspilt en de latentie schaadt.
Wat is de belangrijkste hardwarereden voor het scheiden van vooraf invullen en decoderen op verschillende GPU-pools?
Prefill verwerkt de hele prompt parallel en verzadigt de rekenkracht, terwijl decodering bij elke stap de KV-cache leest en wordt beperkt door de geheugenbandbreedte - tegenovergestelde verlangens die afzonderlijke, onafhankelijk afgestemde pools rechtvaardigen.
Welke gegevensstructuur moet worden overgedragen van prefill-werknemers naar decodeerwerknemers?
Prefill bouwt de KV-cache voor de prompt; decode heeft die cache nodig om door te gaan met genereren, dus de cache wordt via een snelle verbinding met de decodeerpool verzonden.
Welk probleem wordt door disaggregatie specifiek verminderd in een gedeelde GPU-opstelling?
Op gedeelde GPU's kan een lange prefill-burst lopende decodeerstappen blokkeren; het scheiden ervan voorkomt die interferentie en stabiliseert de staartlatentie.
Waarom kan vooraf vullen agressief in batches worden verwerkt, maar kunnen de voordelen van verschillende afstemmingen worden gedecodeerd?
Prefill verwerkt alle prompttokens samen, zodat grotere batches de tensorkernen goed voeden; decode genereert één token tegelijk en wordt afgesloten door het geheugen, zodat het anders wordt geschaald.
Welke verbindingen worden doorgaans gebruikt om de KV-cache tussen opgesplitste pools te verplaatsen?
Er zijn koppelingen met een hoge bandbreedte en lage latentie nodig, zoals NVLink (intra-node) en InfiniBand (inter-node), zodat de overdracht van KV-cache niet het nieuwe knelpunt wordt.