Wat is prefill-decode-disaggregatie en waarom verandert dit de manier waarop LLM's worden aangeboden?

Prefill-decode-disaggregatie scheidt promptverwerking van tokengeneratie, zodat elke LLM-fase verschillende workers, planningen en capaciteitsplannen kan gebruiken.

Een lange RAG-prompt vereist een grote rekenpiek voordat de eerste token verschijnt, terwijl decodering daarna veel kleinere, geheugenbandbreedtegevoelige iteraties uitvoert. Beide fasen op één GPU uitvoeren is eenvoudig, maar hierdoor kunnen lange prefills actieve gesprekken onderbreken. Disaggregatie verplaatst het verzoek en de bijbehorende KV-status tussen pools en ruilt extra coördinatie- en overdrachtskosten in voor onafhankelijke controle over de latentie van de eerste token en per token.

Prefill en decode hebben verschillende resourceprofielen

Prefill verwerkt alle prompttokens parallel en bouwt de KV-cache op, wat een rekenintensieve piek oplevert waarvan de duur toeneemt met de promptlengte. Decode leest herhaaldelijk modelgewichten en de opgebouwde KV-status om één of enkele nieuwe tokens te genereren.

DistServe identificeert prefill-decode-interferentie wanneer beide fasen GPU's delen, waarbij prefill bepalend is voor de tijd tot de eerste token en decode de tijd per uitvoertoken bepaalt. Door ze te scheiden kan de scheduler elke doelstelling afzonderlijk beschermen. Dit onderscheid blijft zichtbaar tijdens latere tests in een thuisomgeving.

Disaggregatie is geen gewone modelparallelisatie. Hetzelfde model kan in beide pools aanwezig zijn, terwijl verzoeken tussen functionele fasen worden verplaatst in plaats van tussen lagen van één forward pass. Het tussenresultaat moet inspecteerbaar blijven voordat automatisering verdergaat.

KV-overdracht verbindt de twee workerpools

Na prefill moet het systeem de KV-cache van het verzoek beschikbaar maken voor een decode-worker. Het kan tensors via PCIe of een netwerkverbinding overdragen, gedeeld geheugen gebruiken of workers zo plaatsen dat de verplaatsingskosten minimaal blijven.

Splitwise onderzoekt fasegebonden serving met fasegebonden machines en planning, en laat zien waarom hardwaretoewijzing kan aansluiten op de verschillende computationele kenmerken van prompt- en tokenwerk. Wachtrijen en statusverplaatsing worden onderdeel van het servingpad. Die grens moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.

De decodepool kan pas starten wanneer deze over een consistente KV-status en verzoekmetadata beschikt. Grote contexten vergroten het aantal overdrachtsbytes, waardoor een nominaal snellere fasescheiding op een klein thuisnetwerk slechter kan uitpakken dan uitvoering op dezelfde locatie.

Onafhankelijk schalen verandert capaciteitsplanning

Afzonderlijke pools kunnen extra prefillcapaciteit toevoegen voor pieken met lange documenten zonder de decodecapaciteit evenredig uit te breiden, of voicedecodering beschermen terwijl achtergrondssamenvatting promptworkers gebruikt. Toelatingsbeheer kan zich richten op twee wachtrijen en twee latentiebudgetten. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.

Mooncake beschrijft een coördinatie van de KV-cache waarbij verplaatsing en opslag van de KV-cache als eersteklas servingkwesties worden behandeld. De architectuur laat zien dat disaggregatie de bottleneck verschuift van pure GPU-planning naar statusoverdracht en cachecoördinatie.

De foutgrens ligt bij onvoldoende schaal of bandbreedte. Eén of twee GPU's voor thuisgebruik hebben mogelijk geen vrij apparaat voor specialisatie, en dubbele modelgewichten plus KV-overdracht kunnen meer geheugen en latentie verbruiken dan de interferentie die wordt weggenomen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vergelijk budgetten voor colocated en gedisaggregeerde fasen

Meet prompttokens per seconde, tijd tot de eerste token, tijd per uitvoertoken, overgedragen KV-bytes, overdrachtstijd, wachttijd in de wachtrij, duplicatie van modelgeheugen, energieverbruik en foutherstel voor korte, lange en gemengde prompts. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

Gebruik chunked prefill als colocated alternatief. Test chunked prefill voordat je een tweede pool toevoegt en vergelijk vervolgens identieke aankomstpatronen onder beide architecturen. Het resultaat moet daarom worden getoetst aan het oorspronkelijke bewijsmateriaal.

Stap alleen over op disaggregatie wanneer fase-interferentie is gemeten en het overdrachtspad beide latentiedoelstellingen behoudt. Op een kleine server kan colocated planning met begrensde prefillchunks dezelfde gebruikerservaring bieden met minder statusverplaatsing.