Continue batching verbetert de benutting door actieve batches opnieuw aan te vullen, maar eerlijkheid hangt af van hoe gebruikers in de loop der tijd toegang, tokens en geheugen krijgen.
Een AI-thuisserver kan meerdere gesprekken combineren zonder te wachten tot elke reeks gezamenlijk is voltooid. Voltooide aanvragen verdwijnen, nieuwe aanvragen komen binnen en actieve gebruikers delen herhaalde inferentie-iteraties. Dat verhoogt de doorvoer, maar de aanvragen zijn niet gelijk: de ene gebruiker dient een korte opdracht in, de andere een lang document en weer een andere een agent die honderden tokens genereert. Een eerlijke planner moet bepalen welke werkeenheid telt, hoe nieuwe aanvragen worden toegelaten en hoe prioriteiten omgaan met onvoorspelbare uitvoerlengtes.
Continue batching verandert de planningseenheid van een vaste batch in iteraties
Statische batching houdt één groep bijeen totdat de groep is voltooid, waardoor capaciteit verloren gaat wanneer korte aanvragen vroeg klaar zijn. Continue batching kan de vrijgekomen plaatsen tussen generatie-iteraties opnieuw vullen.
Orca introduceerde planning op iteratieniveau, zodat aanvragen kunnen toetreden en vertrekken naarmate hun reeksstatus verandert.
Dit verbetert de benutting, maar betekent ook dat gebruikers herhaaldelijk concurreren om een plaats in de volgende iteratie, in plaats van één ondeelbare aanvraagplaats te krijgen.
De toelatingsvolgorde bepaalt wie service begint op te bouwen
Een aanvraag buiten de actieve batch ontvangt geen modelvoortgang. De planner kan toelaten op basis van aankomsttijd, geschatte lengte, prioriteit, beschikbare KV-blokken of een eerlijkheidsteller.
vLLM combineert continue toelating met gepagineerd KV-cachebeheer, zodat geheugen kan worden toegewezen naarmate reeksen groeien.
First come, first served is eenvoudig, maar een wachtrij met lange aanvragen kan latere korte opdrachten van huisgenoten vertragen, zelfs wanneer die opdrachten snel zouden zijn voltooid.
Aanvragen gelijk tellen kan ongelijke acceleratorservice opleveren
Een antwoord van vijf tokens en een antwoord van vijfhonderd tokens zijn beide één aanvraag, maar ze nemen een zeer verschillend aantal decoderingsiteraties in beslag. Ook promptlengtes veroorzaken verschillende hoeveelheden prefillwerk.
De Virtual Token Counter definieert eerlijkheid op basis van tokens, omdat alleen het aantal aanvragen niet weergeeft hoeveel service heterogene LLM-werklasten verbruiken.
Een huishoudelijk beleid moet bepalen of eerlijkheid betekent: gelijk tokenwerk, gelijke wachttijd, gelijke kans op voltooiing of prioriteit voor latentiegevoelige taken.
Geen enkele maatstaf past bij elke werklast. Een spraakopdracht en een samenvatting op de achtergrond hoeven niet noodzakelijk identiek te worden behandeld.
Een onbekende uitvoerlengte maakt toekomstige service moeilijk voorspelbaar
De planner kent bij toelating de promptgrootte, maar weet meestal niet precies hoeveel uitvoertokens het model zal genereren. Eén aanvraag kan veel langer actief blijven dan verwacht.
Onderzoek naar eerlijkheid benadrukt onvoorspelbare aanvraaglengtes als een kenmerkende uitdaging bij het aanbieden van LLM's.
Service in rekening brengen op basis van daadwerkelijk verwerkte tokens voorkomt dat men volledig afhankelijk is van een slechte lengteschatting, maar kan er nog steeds toe leiden dat een lange aanvraag gedurende vele iteraties geheugen bezet houdt.
Grote prefills kunnen gebruikers die al tokens ontvangen verstoren
Een nieuwe documentprompt kan binnenkomen terwijl meerdere gebruikers aan het decoderen zijn. De rekenintensieve prefill ervan kan de iteratie verlengen waarop actieve gesprekken moeten wachten.
Sarathi-Serve gebruikt planning zonder stilstand om grote prefills op te splitsen en hun effect op de latentie van lopende decodering te beperken.
Een planner die alleen decodeertokens telt, kan nog steeds oneerlijk zijn als één gebruiker herhaaldelijk grote prefills invoert die de gestreamde uitvoer van iedereen vertragen.
Eerlijke verrekening moet daarom zowel invoerverwerking als gegenereerde tokens omvatten.
Geheugendruk kan eerlijkheidsproblemen veroorzaken voordat de rekenkracht verzadigd is
Elk actief gesprek heeft KV-cache nodig en langere contexten verbruiken meer blokken. Eén gebruiker met een grote context kan het aantal andere aanvragen dat in de actieve batch past verminderen.
De analyse van ZimaSpace over meerdere gebruikers verbindt gelijktijdig gebruik binnen huishoudens met gedeeld modelgeheugen en plannerbeslissingen.
Een aanvraag onderbreken of verwisselen kan capaciteit vrijmaken, maar de onderbroken gebruiker kan later te maken krijgen met herberekening, het opnieuw laden van de cache of een langere voltooiingstijd.
Geheugentoelating en rekenplanning moeten daarom hetzelfde eerlijkheidsbeleid volgen, in plaats van als losstaande beperkingen te werken.
Prioriteiten hebben veroudering, quota en zichtbare metingen voor gebruikers nodig
Spraakbediening, toegankelijkheidstools en korte interactieve chats verdienen mogelijk een hogere prioriteit dan embeddings of nachtelijke samenvattingen. Zuivere prioriteitsplanning kan werk met een lage prioriteit echter uithongeren.
Llumnix gebruikt dynamische planning om de plaatsing van aanvragen en beslissingen over resources aan te passen wanneer de omstandigheden voor het aanbieden veranderen.
Voeg veroudering, quota per gebruiker, maximale context- of uitvoerlimieten en een gereserveerd aandeel voor achtergrondtaken toe, zodat voorkeurswerk snel reageert zonder al het andere voor onbepaalde tijd te blokkeren.
Meet wachtrijtijd, tijd tot het eerste token, vertraging tussen tokens, voltooiingstijd, geleverde tokens en onderbrekingen per gebruiker of werklastklasse. Continue batching is alleen eerlijk wanneer de waargenomen verdeling overeenkomt met het huishoudelijke beleid, niet alleen wanneer het totale aantal tokens per seconde hoog is.
Tech & AI HUB
Meer om te lezen

Welke functies maken een vertrouwensgrens voor thuis-AI rond gevoelige bestanden mogelijk?
Een vertrouwensgrens voor thuis-AI combineert versleuteling van gegevens in rust, rechten volgens het principe van minimale bevoegdheden, sandboxing tijdens runtime en retrieval met beperkte...

Waardoor krijgen vaak bewerkte bestanden voorrang in privézoekresultaten?
Vaak bewerkte bestanden krijgen een hogere ranking wanneer elke update versheid, chunks, versies of interactiesignalen toevoegt zonder te normaliseren op basis van de bron.

Waardoor verwarren slimme-aanwezigheidsmodellen gasten met bewoners?
Gasten kunnen op bewoners lijken wanneer het systeem activiteitspatronen in het huishouden waarneemt, maar geen stabiel identiteitssignaal heeft voor de persoon die deze veroorzaakt.

