Wat is continuous batching en wanneer is het relevant voor een AI-thuisserver?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Continuous batching plant actieve reeksen bij elke decoderingsiteratie in, waardoor nieuwe aanvragen kunnen deelnemen en voltooide aanvragen kunnen vertrekken zonder te wachten op een vaste batch.

Een gezin kan binnen enkele seconden een spraakaanvraag, documentvraag en codeerprompt naar één lokaal model sturen. Hun prompts en uitvoerlengtes verschillen, waardoor een vaste batch slots verspilt terwijl kortere antwoorden op het langste wachten. Continuous batching blijft nuttig werk rond het model opbouwen, maar is alleen relevant wanneer aanvragen elkaar overlappen en de server voldoende geheugen en planningsruimte heeft.

Planning op iteratieniveau is het bepalende idee

Autoregressieve decodering brengt elke actieve reeks per modeliteratie ongeveer één token verder. Een continue planner selecteert de uitvoerbare reeksen voor de volgende iteratie, laat nieuwe aanvragen toe wanneer capaciteit vrijkomt en verwijdert reeksen onmiddellijk nadat ze zijn voltooid.

Het Orca-paper introduceerde planning op iteratieniveau op het niveau van modeliteraties in plaats van volledige aanvragen. Selective batching groepeert vervolgens compatibele bewerkingen, terwijl aanvraag-specifiek werk afzonderlijk blijft. Dit onderscheid blijft zichtbaar tijdens latere tests in een huishouden.

Dit is niet hetzelfde als tokens naar een gebruiker streamen. Streaming verandert wanneer uitvoer wordt geleverd; continuous batching verandert hoe meerdere aanvragen intern de modeluitvoering delen. Het tussenresultaat moet inspecteerbaar blijven voordat automatisering verdergaat.

Het verschilt van statische batching en batching met een aankomstvenster

Statische batching houdt een vaste groep bij elkaar en vult kortere reeksen vaak aan totdat de langste is voltooid. Batching met een aankomstvenster, of dynamic batching, wacht kort om aanvragen te verzamelen, maar kan de resulterende groep nog steeds als één geheel uitvoeren. Continuous batching bekijkt het lidmaatschap bij elke iteratie opnieuw.

Het vLLM-paper combineert planning op iteratieniveau met beheer van de gepagineerde KV-cache, zodat veranderende verzamelingen reeksen geen rigide aaneengesloten reserveringen vereisen. Planning en geheugenbeheer zijn aanvullende, geen uitwisselbare functies. Die grens moet afzonderlijk worden gemeten onder realistische gebruiksomstandigheden.

Meer actieve reeksen spreiden het inlezen van gewichten en kunnen de doorvoer verbeteren, maar elke aanvraag concurreert om KV-geheugen en rekenkracht. Een grotere actieve batch is niet automatisch beter voor latentie of eerlijkheid. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen om beperkte context concurreren.

Concurrentie, niet alleen modelgrootte, creëert het voordeel

Een enkele interactieve gebruiker merkt mogelijk weinig winst, omdat er geen tweede aanvraag beschikbaar is om ongebruikte capaciteit te vullen. Voordelen ontstaan bij overlappende gebruikers in een huishouden, vertakkingen van agents, samenvattingen op de achtergrond of meerdere toepassingen die hetzelfde residente model delen.

Sarathi-Serve analyseert hoe interferentie tijdens prefill de decode-latentie kan verstoren en gebruikt opgedeelde prefills om gemengde planning voorspelbaarder te maken. Het resultaat laat zien dat het toelatingsbeleid naast het label continuous batching van belang is. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

De grens waarop het misgaat, ligt bij geheugendruk of agressieve toelating, waardoor de tijd per uitvoertoken en de staartlatentie toenemen. Wanneer de KV-cache vol raakt, kunnen preëmptie, swapping of herberekening de doorvoordelen tenietdoen en de interactieve service instabiel maken.

Bepaal of gelijktijdige vraag dit rechtvaardigt

Herhaal één, twee, vier en acht overlappende aanvragen met realistische prompt- en uitvoerlengtes. Noteer de doorvoer, tijd tot het eerste token, tijd per uitvoertoken, p95-voltooiingstijd, KV-benutting, preëmpties en eerlijkheid per aanvraagklasse.

Vergelijk het gedrag met hiaten in GPU-benutting tijdens batching. Herhaal de test met continuous batching uitgeschakeld of met een baseline met vaste batches, terwijl model, kwantisering, contextlimieten en hardware constant blijven. Het resultaat moet daarom worden gecontroleerd aan de hand van het oorspronkelijke bewijsmateriaal.

Gebruik continuous batching wanneer overlap aanzienlijke winst in doorvoer of capaciteit oplevert zonder de interactieve staartlatentie te overschrijden. Als aanvragen zelden overlappen, geef dan prioriteit aan modelresidentie en opstartlatentie voordat je plannercomplexiteit toevoegt. Dit onderscheid blijft zichtbaar tijdens latere tests in een huishouden.

Tech & AI HUB

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.