Token Management in Multi-Tenant AI Inference Platforms

Dit paper introduceert 'token pools', een besturingsvlak-abtractie die multi-tenant AI-inferentieplatforms in staat stelt om resources efficiënt te balanceren en servicegaranties te waarborgen door capaciteit te beheren in inzichtelijke token-eenheden in plaats van via traditionele rate limits.

De kern

Stel je voor dat een AI-platform een groot, drukke restaurant is. De koks zijn de krachtige GPU-chips (de "motoren" van de AI), en de klanten zijn de mensen die vragen stellen aan de AI (zoals "schrijf een gedicht" of "analyseer deze data").

Het probleem in de huidige wereld is dat dit restaurant vaak in de war raakt. Soms komen er te veel mensen tegelijk, en dan wordt het wachten voor iedereen lang. Of er zijn mensen die alleen maar een klein kopje koffie willen, maar ze bezetten de hele tafel, terwijl iemand anders die een heel groot diner bestelt, in de kou moet staan.

Dit artikel introduceert een slim nieuw systeem genaamd "Token Pools" (Token-pools). Laten we uitleggen hoe dit werkt met een paar creatieve vergelijkingen.

1. Het oude probleem: De verkeerde manier om te tellen

Vroeger hielden restaurants (AI-platforms) het aantal bestellingen simpelweg in de gaten. Ze zeiden: "Je mag maar 10 bestellingen per minuut doen."

Maar dit werkt niet goed voor AI, omdat niet alle bestellingen evenveel werk zijn:

• Bestelling A: "Wat is de hoofdstad van Frankrijk?" (Korte vraag, kort antwoord). Dit kost de kok 1 seconde.
• Bestelling B: "Schrijf een roman over een robot die verliefd wordt." (Lange vraag, heel lang antwoord). Dit kost de kok 10 minuten.

Als je alleen naar het aantal bestellingen kijkt, kan Bestelling B de hele keuken blokkeren terwijl Bestelling A maar een fractie van de tijd kost. De ene klant "kost" dus veel meer dan de andere, maar het systeem zag dat niet.

2. De oplossing: De "Token-Portemonnee"

Het nieuwe systeem, Token Pools, kijkt niet naar het aantal bestellingen, maar naar de inhoud ervan. Het gebruikt een eenheid die we "tokens" noemen (woorden of stukjes tekst).

Stel je voor dat elke klant een portemonnee krijgt met een bepaald aantal munten (tokens).

• Een korte vraag kost 10 munten.
• Een lange roman kost 10.000 munten.

De keuken (de AI) heeft een totale voorraad munten per seconde. Het systeem zorgt ervoor dat niemand meer bestelt dan wat er in zijn portemonnee zit. Als je portemonnee leeg is, moet je wachten, ongeacht of je nu 1 of 100 bestellingen hebt gedaan. Dit zorgt voor eerlijkheid: wie meer vraagt, betaalt meer (in munten).

3. De VIP-kaarten en de "Schulden"

Maar wat als het restaurant vol zit? Wie mag er dan nog binnen? Hier komt het slimme deel van het systeem: Service Classes (Dienstklassen) en Schulden.

Het systeem kent verschillende soorten klanten:

• De VIP's (Garantieklanten): Zij hebben een vaste tafel. Ze betalen vast, en ze krijgen altijd hun eten, zelfs als het druk is.
• De Gewone Klanten (Elastisch): Zij kunnen soms extra bestellingen doen als er ruimte is, maar als het erg druk is, moeten ze even wachten.
• De "Tussenklanten" (Spot/Preemptible): Zij betalen heel weinig. Ze mogen alleen eten als er echt ruimte over is. Als de VIP's binnenkomen, worden zij direct uit de keuken gegooid (hun bestelling wordt geannuleerd).

Het slimme trucje: De Schulden-methode
Stel je voor dat een "Gewone Klant" (Elastisch) een paar uur lang geen eten heeft gekregen omdat het te druk was. Het systeem houdt dit bij als een schuld.

• Zodra er weer ruimte is, krijgt deze klant met een grote "schuld" automatisch extra prioriteit.
• Het systeem zegt: "Je hebt te lang moeten wachten, dus nu krijg je je eten eerst, zelfs als er een nieuwe klant binnenkomt."
• Zodra de klant zijn "schuld" heeft terugbetaald (door weer normaal te eten), gaat de prioriteit weer terug naar normaal.

Dit zorgt ervoor dat niemand oneindig lang in de kou blijft staan, terwijl de VIP's toch hun bescherming houden.

4. Hoe werkt dit in de praktijk?

Het mooie aan dit systeem is dat het niet de koks (de AI-software) hoeft te veranderen. Het is als een super-slome ober die voor de deur staat.

• De Ober (Admissiecontrole): Voordat een bestelling de keuken in gaat, kijkt de ober: "Heeft deze klant genoeg munten in zijn portemonnee? Is de VIP-klant aan de beurt? Heeft deze klant schulden die we moeten aflossen?"
• Als het antwoord "nee" is, zegt de ober: "Sorry, u moet even buiten wachten," en stuurt een berichtje naar de klant om het later te proberen.
• De keuken zelf (de AI) merkt hier niets van. Ze werken gewoon door met de bestellingen die de ober doorgeeft.

Waarom is dit belangrijk?

In de echte wereld betekent dit:

1. Geen lange wachtrijen voor iedereen: Als een "spot" klant (die weinig betaalt) de server overbelast, wordt die klant gewoon geweerd, zodat de belangrijke zakelijke klanten (VIP's) snel hun antwoord krijgen.
2. Eerlijkheid: Als een klant een tijdje heeft moeten wachten, krijgt hij later extra ruimte om zijn "schuld" goed te maken.
3. Flexibiliteit: Het systeem past zich automatisch aan. Als er plotseling veel vraag is, weet het systeem precies wie er moet wachten en wie niet, zonder dat iemand handmatig ingrijpen hoeft.

Kortom:
Dit artikel beschrijft een slimme manier om de chaos in AI-keukens te regelen. In plaats van te tellen hoeveel mensen er binnenkomen, kijken ze naar hoeveel werk er gedaan moet worden, en ze zorgen dat de belangrijkste klanten altijd bediend worden, terwijl de anderen eerlijk worden behandeld op basis van wat ze hebben betaald en hoe lang ze al wachten. Het is als een super-georganiseerd restaurant waar niemand ooit in de kou hoeft te staan, tenzij ze echt geen plaats meer hebben.

Technische samenvatting

Probleemstelling

Meer-tenant AI-inferentiplatforms (platforms waar meerdere klanten of toepassingen dezelfde GPU-resources delen) staan voor een fundamenteel dilemma: hoe kan men de resource-uitbating maximaliseren terwijl er tegelijkertijd service-level garanties (SLO's) worden geboden onder wisselende vraag?

De huidige benaderingen falen in het vinden van dit evenwicht:

1. Gedecentraliseerde eindpunten (Dedicated Endpoints): Hierbij wordt per model of tenant een aparte GPU-instantie geprovisioned. Dit biedt sterke isolatie, maar leidt tot "vastzittende capaciteit" (stranded capacity) wanneer modellen of tenants inactief zijn. Dit is inefficiënt voor modellen met een lange "long tail" van zelden gebruikt verkeer.
2. Snelheidsbeperkingen (Rate Limits): Deze regelen de toegang tot het systeem op basis van het aantal verzoeken per tijdseenheid (bijv. tokens per minuut). Het grote nadeel is dat ze geen rekening houden met de heterogene kosten van inferentieverzoeken. Twee verzoeken kunnen hetzelfde aantal tokens bevatten, maar door verschillen in promptlengte, output-complexiteit en modelarchitectuur kan het ene verzoek tien keer meer GPU-tijd en KV-cache (Key-Value cache) geheugen verbruiken dan het andere.
3. Gebrek aan werkbehoud (Work-Conservation): Geen van deze methoden staat toe dat idle capaciteit door andere tenants wordt gebruikt. Bij pieken (bursts) in het verkeer, zoals lange prompts of complexe redeneringen, raken systemen snel verzadigd, wat leidt tot onbeperkte latentievertragingen voor alle gebruikers.

Methodologie: Token Pools

De auteur introduceert Token Pools, een besturingsslaag (control-plane) abstractie die inferentiecapaciteit uitdrukt in "inference-native" eenheden in plaats van traditionele CPU/RAM-metingen.

1. Resource Model:
In plaats van alleen verzoeken te tellen, worden drie schaalbare resources gedefinieerd:

• Token Throughput ($\lambda$): Tokens per seconde (bepaalt de GPU-tijd).
• KV Cache Capaciteit ($\chi$): Geheugen in bytes voor de attention-state (cruciaal voor lange contexten).
• Concurrentie ($r$): Het aantal gelijktijdig actieve inferentiesequenties.

2. Entitlements en Service Classes:
Tenants krijgen "entitlements" (rechten) op een deel van de poolcapaciteit. Deze worden ingedeeld in serviceklassen die bepalen hoe ze zich gedragen bij schaarste:

• Dedicated/Guaranteed: Altijd gegarandeerde baseline, nooit verkleind.
• Elastic: Krijgt een gemiddelde garantie over tijd; mag "bursten" (boven de baseline gaan) maar kan worden verkleind bij schaarste.
• Spot/Preemptible: Geen garantie, gebruikt alleen surplus capaciteit en wordt als eerste afgewezen of gestopt.

3. Prioriteits- en Schuldmecanisme:
Het systeem gebruikt een dynamische prioriteitsformule ($w_e$) die vier factoren combineert:

• Serviceklasse (basisgewicht).
• SLO-noodzaak (strakkere latentie-eisen = hogere prioriteit).
• Burst-geschiedenis (te veel verbruik boven de baseline verlaagt de prioriteit).
• Service Debt (Schuld): Dit is een kerninnovatie. Als een tenant minder resources krijgt dan beloofd (underserved), accumuleert deze "schuld". Deze schuld verhoogt de prioriteit in de toekomst, waardoor het systeem naar een eerlijke verdeling (fair-share) convergeert. Het werkt analoog aan een PI-regelaar (Proportional-Integral).

4. Architectuur:
De oplossing is gebouwd bovenop bestaande infrastructuren (Kubernetes, vLLM) zonder de inferentie-runtime zelf te wijzigen.

• Virtual Nodes: Token pools worden vertegenwoordigd als virtuele Kubernetes-nodes die de token-capaciteit adverteren.
• Admission Control: De beslissing om een verzoek toe te laten of af te wijzen wordt genomen op de API-gateway (voor de uitvoering), gebaseerd op de huidige entitlement-status en prioriteit.
• Feedback Loop: Na uitvoering worden daadwerkelijke resourceverbruik en latentie teruggekoppeld naar de autorisatieservice om de schuld- en burst-metingen te updaten.

Belangrijkste Bijdragen

1. Formalisatie van Token Pools: Het definiëren van capaciteit in tokens/sec, KV-cache en concurrentie, gekoppeld aan een prioriteitsmechanisme dat serviceklassen, SLO's en schuld combineert.
2. Systeemarchitectuur: Een Kubernetes-native implementatie die de Kubernetes-scheduler hergebruikt voor token-capaciteitsadmissie via virtuele nodes en custom resources (TokenPool, TokenEntitlement).
3. Experimenteel Bewijs: Validatie dat dit systeem latentie voor gegarandeerde workloads beperkt houdt tijdens overbelasting, terwijl het eerlijke verdeling realiseert tussen elastische workloads met verschillende eisen.

Resultaten

De auteurs voerden twee experimenten uit op een Kubernetes-cluster met vLLM-backends:

• Experiment 1: Bescherming tussen klassen (Cross-Class Protection):

  • Scenario: Een "spot"-tenant (lage prioriteit) floodt het systeem, terwijl "guaranteed"-tenants (hoge prioriteit) actief zijn.
  • Resultaat: Met Token Pools blijven de gegarandeerde workloads stabiel met een P99-latentie van < 1,2 seconden**. Het systeem weigert automatisch de excessieve spot-verzoeken (HTTP 429). Zonder dit systeem (baseline) loopt de wachtrij op en degradeert de latentie voor *alle* workloads naar **> 19 seconden.
  • Conclusie: Selectieve throttling op de API-gateway voorkomt dat lage-prioriteit verkeer de hoge-prioriteit verkeer "verstikt".

• Experiment 2: SLO-bewuste eerlijke verdeling (Intra-Class Fair Share):

  • Scenario: Twee elastische tenants delen capaciteit tijdens een uitval (capaciteit gehalveerd). De ene heeft een strikte SLO (500ms), de andere een losse SLO (30s).
  • Resultaat: De tenant met de strikte SLO krijgt voorrang bij toelating. De tenant met de losse SLO wordt meer afgewezen, maar accumuleert hierdoor schuld. Deze schuld verhoogt hun prioriteit geleidelijk, zodat ze niet volledig worden uitgehongerd en uiteindelijk een eerlijkere verdeling krijgen naarmate de schaarste aanhoudt.
  • Conclusie: Het schuldmecanisme zorgt voor dynamische aanpassing zonder handmatige ingreep, in tegenstelling tot statische rate limits.

Betekenis en Impact

Dit paper biedt een principieel fundament voor het beheer van capaciteit in multi-tenant AI-platforms. De belangrijkste inzichten zijn:

• Admissiecontrole moet plaatsvinden bij de gateway, niet bij de GPU: Zodra een verzoek de runtime bereikt, zijn resources al gereserveerd. Graceful degradation vereist beslissingen voor uitvoering.
• Inference-native units: Het meten van capaciteit in tokens en cache-geheugen is essentieel, aangezien traditionele CPU/RAM-metingen de werkelijke kosten van generatieve AI niet weerspiegelen.
• Geen wijziging van bestaande backends: De oplossing werkt als een overlay op bestaande systemen (zoals vLLM of TensorRT-LLM), wat de adoptie in productieomgevingen aanzienlijk vergemakkelijkt.

De "Token Pool"-benadering lost de spanning op tussen hoge uitbating en service-garanties, waardoor organisaties AI-diensten kunnen aanbieden die zowel kostenefficiënt als betrouwbaar zijn, zelfs onder extreme pieken in vraag.