Gedesaggregeerde inferentie: waarom AI-chatbots hun rekenwerk opsplitsen

Stel je een drukke restaurantkeuken voor. Een groep koks staat de hele ochtend groenten te snijden, sauzen te maken en vlees voor te bereiden: zwaar, intensief werk dat in bulk gebeurt voordat de eerste gast er ook maar iets van merkt. Aan de andere kant van de keuken staat de kok aan de "pass": die maakt borden één voor één af, in het tempo waarin bestellingen binnenkomen, en moet steeds opnieuw dezelfde voorraad kruiden en pannen binnen handbereik hebben. Twee heel verschillende soorten werk, die in dezelfde keuken elkaar voortdurend in de weg zitten als je ze niet scheidt.

Iets vergelijkbaars gebeurt binnen de computerchips die grote taalmodellen (large language models, LLM's) zoals ChatGPT, Claude of Kimi laten antwoorden. Het genereren van een antwoord bestaat uit twee fases met heel andere eisen aan de hardware: het "lezen" van je vraag (prefill) en het "schrijven" van het antwoord, woord voor woord (decode). Gedesaggregeerde inferentie is de techniek waarbij die twee fases niet langer op dezelfde grafische processor (GPU) worden uitgevoerd, maar over gescheiden groepen machines worden verdeeld, elk geoptimaliseerd voor hun eigen taak. Het woord "desaggregeren" betekent simpelweg: uit elkaar halen wat voorheen samen op één plek gebeurde.

Wat is het precies?

Wanneer een taalmodel een antwoord genereert, doorloopt het altijd twee fases. De eerste heet prefill: het model verwerkt in één keer je hele prompt (de vraag of instructie die je typt) en berekent daaruit een interne representatie. Dit is rekenintensief werk: de GPU kan hierbij vrijwel al zijn rekenkracht (compute) benutten, omdat alle woorden van de prompt tegelijk, parallel, door het model gehaald worden. Deze fase wordt daarom "compute-bound" genoemd: de snelheid wordt vooral bepaald door hoeveel rekenwerk de chip per seconde aankan.

Daarna volgt decode: het model genereert het antwoord token voor token (een token is ruwweg een woorddeel). Voor elk nieuw token moet het model opnieuw door zijn volledige geheugen aan gewichten (parameters) en eerdere berekeningen bladeren, maar dan voor slechts één nieuw woorddeel tegelijk. Dat maakt deze fase inefficiënt voor een GPU: er wordt relatief weinig gerekend, maar er moet enorm veel data van het geheugen naar de rekenkernen verplaatst worden. Dit heet "memory-bandwidth-bound": niet het rekenwerk, maar de snelheid waarmee data door het geheugen stroomt, is de beperkende factor.

Bij elke stap in de decode-fase gebruikt het model ook de zogeheten KV-cache (key-value cache): een soort geheugensteun met tussentijdse berekeningen over alle eerdere tokens in het gesprek, zodat het model die niet steeds opnieuw hoeft uit te rekenen. Deze cache wordt tijdens de prefill-fase opgebouwd en moet tijdens de decode-fase beschikbaar blijven. Precies hier zit de crux van desaggregatie: als prefill en decode op aparte machines gebeuren, moet die KV-cache na de prefill-fase razendsnel van de ene machine naar de andere worden gestuurd, via een zeer snelle netwerkverbinding (vaak technieken als RDMA of InfiniBand, die data rechtstreeks tussen het geheugen van machines uitwisselen zonder omwegen via de processor).

Historisch gezien liepen prefill en decode gewoon na elkaar op dezelfde GPU, voor dezelfde gebruikersaanvraag. Het probleem: omdat een GPU maar één ding tegelijk goed kan, blokkeert een lange prefill-beurt (bijvoorbeeld voor iemand die een heel document laat samenvatten) de decode-stappen van andere gebruikers die intussen op hun volgende woord wachten. Dit heet "head-of-line blocking": één trage taak houdt de wachtrij van andere taken op. Bovendien is een GPU die is ingericht voor de ene fase, per definitie niet optimaal voor de andere, wat leidt tot verspilde rekenkracht en een slechte "GPU-benutting" (hoe efficiënt de dure chip daadwerkelijk wordt gebruikt).

Wat wil men ermee bereiken?

Het belangrijkste doel is simpel: sneller antwoord geven aan meer gebruikers, tegen lagere kosten, met dezelfde hoeveelheid dure GPU's. Daarbij spelen twee latency-maatstaven (vertragingsmaatstaven) een centrale rol. De eerste is time to first token (TTFT): hoe lang duurt het voordat het eerste woord van het antwoord verschijnt, wat vooral afhangt van de prefill-snelheid. De tweede is time per output token (TPOT), ook wel inter-token latency genoemd: hoe vlot volgen de daaropvolgende woorden elkaar op, wat vooral afhangt van de decode-snelheid.

Door prefill en decode te scheiden, kan elke pool machines specifiek worden ingericht en opgeschaald voor zijn eigen taak: bijvoorbeeld meer prefill-capaciteit inzetten wanneer veel gebruikers lange documenten uploaden, en meer decode-capaciteit wanneer veel gebruikers tegelijk korte chatgesprekken voeren. Dat verhoogt de totale doorvoer (throughput, het aantal aanvragen dat het systeem per tijdseenheid kan afhandelen) en verlaagt de kosten per beantwoorde vraag, omdat GPU's minder tijd verspillen aan taken waarvoor ze niet ideaal zijn ingericht. Voor grote aanbieders van AI-diensten, die miljoenen aanvragen per dag verwerken, kan dit een aanzienlijk verschil maken in zowel gebruikerservaring als operationele kosten.

Voorbeelden uit de praktijk

DistServe is een onderzoeksproject, onder meer verbonden aan Peking University en UC San Diego, dat rond 2024 liet zien dat het scheiden van prefill en decode over verschillende GPU's de doorvoer van een LLM-server aanzienlijk kan verhogen zonder dat gebruikers trager antwoord krijgen.

Splitwise is een vergelijkbaar onderzoek van Microsoft Research, eveneens gepubliceerd in 2024, dat expliciet voorstelde om binnen een datacenter twee soorten machinepools te gebruiken: één voor prefill, één voor decode, verbonden via snelle netwerklinks.

Mooncake is de naam van het serving-systeem van Moonshot AI, het Chinese bedrijf achter de populaire chatbot Kimi. In een gepubliceerde technische beschrijving (2024) presenteerde het bedrijf een "KVCache-centric" architectuur, waarbij de KV-cache als het centrale onderdeel van het hele systeem wordt behandeld en apart wordt beheerd van de reken-pools.

In de open source wereld heeft vLLM, een veelgebruikt project voor het efficiënt draaien van taalmodellen, sinds 2024 experimentele ondersteuning voor gedesaggregeerde prefill toegevoegd, zodat ontwikkelaars deze aanpak ook zonder eigen onderzoeksteam kunnen uitproberen. Ook NVIDIA bracht in 2025 met zijn open source inferentieplatform Dynamo ingebouwde ondersteuning voor gedesaggregeerde serving, gericht op grootschalige datacenters met veel GPU's.

Daarnaast wordt algemeen aangenomen dat grote Chinese AI-labs zoals DeepSeek vormen van prefill/decode-scheiding toepassen in hun eigen productie-infrastructuur, gezien de schaal waarop zij modellen bedienen; de precieze technische details van hun interne systemen zijn echter niet altijd volledig openbaar gemaakt, dus hier is enige voorzichtigheid op zijn plaats.

Hoe ver is de techniek?

Gedesaggregeerde inferentie is inmiddels de stap voorbij van pure onderzoekscuriositeit: het wordt actief toegepast door grote aanbieders van AI-chatbots en is opgenomen in gangbare open source serving-software zoals vLLM en, met eigen implementaties, in projecten als SGLang en NVIDIA Dynamo. Toch is het geen kant-en-klare, uitontwikkelde standaardoplossing die iedereen zomaar kan inzetten.

Een belangrijk obstakel is dat het netwerk tussen de prefill- en decode-machines zelf een nieuw knelpunt kan worden: als de KV-cache niet snel genoeg wordt overgedragen, gaat de gewonnen efficiëntie weer verloren. Dit vereist dure, snelle netwerkverbindingen die niet in elk datacenter standaard aanwezig zijn. Daarnaast is de orkestratie complex: een systeem moet voortdurend beslissen hoeveel machines aan prefill en hoeveel aan decode worden toegewezen, afhankelijk van een wisselende mix van korte en lange aanvragen, en fouten in die afweging kunnen de voordelen tenietdoen. Niet elke workload profiteert bovendien evenveel: bij zeer korte gesprekken, waar prefill en decode qua rekentijd dicht bij elkaar liggen, is de winst kleiner dan bij systemen die veel lange documenten of lange gesprekken verwerken.

Het onderzoeksveld beweegt op dit moment snel: nieuwe varianten en optimalisaties verschijnen met enige regelmaat, en het is nog niet uitgekristalliseerd wat de "standaardarchitectuur" voor de komende jaren zal worden. Wie beweert dat dit probleem definitief is opgelost, loopt op de feiten vooruit.

Wie werken eraan?

Grote chipmaker NVIDIA speelt een prominente rol via zijn open source inferentieplatform Dynamo, mede omdat het bedrijf belang heeft bij een efficiëntere benutting van zijn eigen GPU's. Microsoft Research heeft met Splitwise vroeg academisch werk verricht op dit vlak. Academische groepen, onder meer verbonden aan Peking University en UC San Diego, leverden met DistServe belangrijke bijdragen aan het theoretisch kader.

Aan de bedrijfskant is vooral China opvallend actief: naast Moonshot AI (Mooncake) werken ook labs als DeepSeek aan grootschalige, efficiënte inferentie-infrastructuur waarin vormen van prefill/decode-scheiding een rol spelen. In de Verenigde Staten dragen daarnaast open source gemeenschappen rond projecten als vLLM (met wortels aan UC Berkeley) en SGLang actief bij aan het toegankelijk maken van deze technieken voor een breder publiek van ontwikkelaars en bedrijven, buiten de grote techlabs om.

Verder lezen

• vLLM-documentatie — officiële documentatie van het open source LLM-serving-project, met uitleg over gedesaggregeerde prefill.
• vLLM op GitHub — broncode en technische discussies over serving-optimalisaties.
• Mooncake op GitHub — de door Moonshot AI gepubliceerde KVCache-centric architectuur.
• NVIDIA Dynamo — NVIDIA's open source platform voor grootschalige, gedesaggregeerde LLM-inferentie.
• SGLang op GitHub — open source serving-framework met ondersteuning voor gedesaggregeerde inferentie.