Continuous batching: hoe AI-chatbots duizenden gebruikers tegelijk bedienen
Als je een vraag stelt aan een chatbot zoals ChatGPT, gebeurt er op de achtergrond iets dat lijkt op een drukke aanmeerplaats voor bootjes. Elk bootje is een vraag van een gebruiker, en de "veerboot" is de dure grafische chip (GPU) die de antwoorden genereert. Een veerboot die pas vertrekt als hij helemaal vol is, laat mensen soms onnodig lang wachten en staat tussendoor stil te wachten op de laatste passagier. Continuous batching is een techniek die ervoor zorgt dat de veerboot blijft varen en onderweg voortdurend nieuwe passagiers oppikt zodra er een plek vrijkomt, in plaats van steeds te wachten tot iedereen aan boord klaar is.
Concreet is continuous batching een methode waarmee servers die taalmodellen (large language models, LLM's) draaien, veel gebruikersvragen tegelijk en efficiënt kunnen verwerken. In plaats van vragen in vaste groepjes ("batches") te verwerken die pas starten als de groep compleet is en pas stoppen als iedereen klaar is, herschikt het systeem de groep bij elke kleine rekenstap. Zodra het antwoord aan één gebruiker klaar is, springt er meteen een nieuwe vraag in die vrijgekomen plek. Het resultaat: de dure GPU staat vrijwel nooit stil, en een server kan met dezelfde hardware veel meer mensen tegelijk bedienen.
Wat is het precies?
Om continuous batching te begrijpen, helpt het om te weten hoe een taalmodel tekst genereert. Dat gebeurt woord voor woord, of eigenlijk token voor token (een token is een stukje tekst, vaak een woord of een deel daarvan). Voor elk nieuw token moet het model een volledige berekening door zijn neurale netwerk uitvoeren. Dat proces kent twee fasen: eerst de "prefill", waarbij het model de hele binnenkomende vraag in één keer verwerkt, en daarna de "decode"-fase, waarin het model steeds één token tegelijk genereert totdat het antwoord af is.
GPU's zijn het efficiëntst wanneer ze veel berekeningen tegelijk (parallel) uitvoeren. Daarom worden meerdere gebruikersvragen samengevoegd in een batch: de GPU verwerkt ze in één moeite door. Bij de oudere aanpak, statische batching, wordt een vaste groep vragen samengesteld en blijft die groep bij elkaar totdat alle antwoorden in die groep klaar zijn. Het probleem: antwoorden verschillen sterk in lengte. Een kort antwoord is na een paar tokens klaar, maar de GPU moet toch wachten tot ook het langste antwoord in de groep af is voordat er nieuwe vragen worden toegelaten. Ondertussen staat een deel van de rekencapaciteit stil.
Continuous batching, ook wel iteration-level scheduling genoemd, lost dit op door na elke afzonderlijke rekenstap (elke gegenereerde token) te controleren welke gebruikersvragen klaar zijn. Die worden dan direct uit de batch verwijderd, en nieuwe wachtende vragen krijgen onmiddellijk die vrijgekomen plek. De samenstelling van de batch verandert dus voortdurend, in plaats van één keer per volledige groep.
Dit klinkt eenvoudig, maar vraagt om een slimmere planner (scheduler) en een zorgvuldiger geheugenbeheer. Elk actief gesprek heeft namelijk een eigen "geheugen" nodig: de zogeheten key-value cache, oftewel opgeslagen tussentijdse berekeningen die het model nodig heeft om consistent verder te praten. Omdat gesprekken voortdurend beginnen en eindigen, moet dat geheugen dynamisch worden toegewezen en weer vrijgegeven, zonder dat het versnippert. Technieken zoals PagedAttention, ontwikkeld voor het opensourceproject vLLM, beheren dat geheugen op een manier die te vergelijken is met hoe een besturingssysteem het werkgeheugen van een computer in kleine "pagina's" indeelt.
Wat wil men ermee bereiken?
Het hoofddoel van continuous batching is simpel: meer gebruikers bedienen met dezelfde hardware, zonder dat individuele gebruikers daar veel van merken in wachttijd. Dat heet in vaktermen een hogere doorvoer (throughput, het aantal tokens of verzoeken dat een server per seconde kan verwerken) bij een vergelijkbare latency (de tijd die één gebruiker moet wachten op zijn antwoord).
Dit is economisch en praktisch belangrijk omdat de GPU's waarop taalmodellen draaien duur, schaars en energie-intensief zijn. Een chatbotdienst die miljoenen gebruikers bedient, betaalt in feite per gebruikte GPU-seconde. Als een groot deel van die tijd verloren gaat aan wachten, kost het antwoorden onnodig veel geld en energie. Efficiëntere serving-technieken zoals continuous batching kunnen de kosten per gegenereerd antwoord met een veelvoud verlagen, wat rechtstreeks doorwerkt in hoe betaalbaar en toegankelijk AI-diensten kunnen zijn.
Daarnaast speelt schaalbaarheid mee: naarmate meer bedrijven en toepassingen (chatbots, programmeerassistenten, zoekmachines met AI) leunen op dezelfde onderliggende modellen, groeit de vraag naar rekencapaciteit sneller dan het aanbod aan geschikte chips. Software die zuiniger omgaat met bestaande hardware is dan ook een van de weinige knoppen waaraan bedrijven op korte termijn kunnen draaien, naast het kopen van meer of snellere chips.
Voorbeelden uit de praktijk
Het idee van iteration-level scheduling werd voor het eerst uitgebreid beschreven in het onderzoekssysteem Orca, gepresenteerd in 2022 door onderzoekers verbonden aan de Seoul National University en het bedrijf FriendliAI. In hun paper op de vakconferentie OSDI lieten ze zien dat deze aanpak, gecombineerd met selectieve batching, de doorvoer van een LLM-server aanzienlijk kon verhogen ten opzichte van de toen gangbare systemen.
vLLM, een opensourceproject dat in 2023 werd gelanceerd door onderzoekers van UC Berkeley, combineerde continuous batching met de eerdergenoemde PagedAttention-techniek voor geheugenbeheer. vLLM groeide uit tot een van de meest gebruikte serving-engines voor open taalmodellen en wordt inmiddels door tal van bedrijven en onderzoeksgroepen ingezet.
Hugging Face bracht in 2023 zijn eigen serving-systeem uit, Text Generation Inference (TGI), dat eveneens continuous batching gebruikt en onder meer de eigen chatdienst HuggingChat en de Inference Endpoints-dienst van het bedrijf aandrijft.
NVIDIA voegde een vergelijkbare functie, die het bedrijf "in-flight batching" noemt, toe aan zijn TensorRT-LLM-softwarebibliotheek en de Triton Inference Server, waarmee de techniek breed beschikbaar kwam voor bedrijven die op NVIDIA-hardware draaien.
Ook Anyscale, het bedrijf achter het gedistribueerde rekenraamwerk Ray, beschreef en implementeerde continuous batching in zijn Ray Serve-platform, en droeg met technische blogposts bij aan de bredere bekendheid van de techniek buiten gespecialiseerde onderzoekskringen.
Hoe ver is de techniek?
Continuous batching is geen experimenteel idee meer: het is inmiddels de facto standaard geworden in vrijwel alle serieuze LLM-serveersoftware. Naast vLLM, TGI en TensorRT-LLM ondersteunen ook andere veelgebruikte systemen, zoals SGLang en DeepSpeed-MII van Microsoft, de techniek. Wie tegenwoordig een taalmodel op schaal wil aanbieden, kiest vrijwel altijd voor een van deze bestaande engines in plaats van zelf iets te bouwen.
De ontwikkeling gaat echter door. Een belangrijk vervolgvraagstuk is "chunked prefill": het opknippen van de zware prefill-berekening van een nieuwe, lange vraag in kleinere stukjes, zodat die niet de lopende decode-stappen van andere gebruikers blokkeert. Ook wordt onderzocht hoe je eerlijk kunt plannen tussen verzoeken met verschillende prioriteiten of afgesproken maximale wachttijden (service-level agreements), en hoe continuous batching zich verhoudt tot andere versnellingstechnieken zoals speculative decoding, waarbij een klein model vast tokens "voorspelt" die het grote model achteraf controleert.
Een nieuwere richting is het volledig scheiden van de prefill- en decode-fase over verschillende GPU's of zelfs verschillende machines, omdat beide fasen andere eisen stellen aan rekenkracht versus geheugenbandbreedte. Dit "disaggregated serving" wordt gezien als een mogelijke volgende stap, maar is nog volop in ontwikkeling en brengt eigen complexiteit met zich mee op het gebied van netwerkverkeer tussen machines.
Een eerlijke kanttekening: de winst die continuous batching oplevert, hangt sterk af van het gebruikspatroon. Bij zeer voorspelbare, gelijkvormige verzoeken is het voordeel kleiner dan bij de wisselende, onvoorspelbare vragen die typisch zijn voor consumenten-chatbots. Bovendien blijft er een fundamentele afweging tussen doorvoer en latency bestaan: agressiever batchen verhoogt de capaciteit van een server, maar kan in drukke periodes de wachttijd voor individuele gebruikers licht verlengen.
Wie werken eraan?
De ontwikkeling van continuous batching is sterk verspreid over een handvol academische groepen en techbedrijven, voornamelijk in de Verenigde Staten en Zuid-Korea. De Sky Computing Lab van UC Berkeley ontwikkelde vLLM en blijft een van de meest invloedrijke onderzoeksgroepen op dit gebied. De oorspronkelijke Orca-aanpak kwam voort uit onderzoek aan de Seoul National University, en werd verder commercieel doorontwikkeld door het daaruit voortgekomen bedrijf FriendliAI.
Hugging Face, met vestigingen in Frankrijk en de Verenigde Staten, onderhoudt TGI als onderdeel van zijn bredere platform voor open AI-modellen. Chipfabrikant NVIDIA investeert fors in serveersoftware zoals TensorRT-LLM en Triton, deels omdat efficiëntere software de facto ook de vraag naar (en het nut van) zijn eigen GPU's beïnvloedt. Anyscale en Microsoft (met DeepSpeed) leveren eigen bijdragen vanuit de bredere cloud- en infrastructuurhoek.
Daarnaast bouwen grote AI-labs als OpenAI, Google en Anthropic naar verluidt op eigen, niet-publiek gemaakte varianten van dit soort serveertechnieken om hun eigen chatdiensten draaiende te houden, al zijn de precieze technische details daarvan doorgaans niet openbaar gemaakt.