Token Management in Multi-Tenant AI Inference Platforms

Die Arbeit stellt „Token Pools" als neue Steuerungsabstraktion vor, die die Kapazitätsverwaltung in Multi-Tenant-KI-Inferenzplattformen durch die explizite Darstellung von Ressourcen in tokenspezifischen Einheiten optimiert und so eine konsistente, priorisierte Lastverteilung mit garantierter Latenz auch bei Überlastung ermöglicht.

Das Wesentliche

Stellen Sie sich vor, ein Multi-Tenant-KI-System ist wie eine riesige, hochmoderne Bäckerei, die für viele verschiedene Kunden (Unternehmen) gleichzeitig Brot backt.

In dieser Bäckerei gibt es ein Problem:

1. Die Nachfrage schwankt: Manchmal kommen nur ein paar Kunden, manchmal stürmen hunderte herein.
2. Die Aufträge sind unterschiedlich: Ein Kunde bestellt vielleicht nur ein kleines Brötchen (kurze Anfrage), ein anderer bestellt einen riesigen, mehrstöckigen Hochzeitstorte (komplexe KI-Anfrage mit langer Antwort).
3. Das Problem der alten Systeme:
   • Der "Dedizierte Ofen"-Ansatz: Jeder Kunde bekommt seinen eigenen Ofen. Wenn er nichts bestellt, steht der Ofen leer und verschwendet Energie. Wenn er aber einen riesigen Kuchen bestellt, reicht der Ofen vielleicht nicht aus.
   • Der "Zähl-Strich"-Ansatz (Rate Limits): Die Bäckerei sagt: "Jeder darf maximal 10 Aufträge pro Minute stellen." Das ist fair, aber dumm. Ein kleiner Auftrag (ein Brötchen) kostet genauso viel "Zeit am Zähler" wie ein riesiger Auftrag (ein Hochzeitstorte), obwohl der Torte den Ofen viel länger blockiert. Wenn plötzlich alle riesige Torten bestellen, bricht die Bäckerei zusammen, obwohl sie eigentlich genug Platz für Brötchen hätte.

Die Lösung: Der "Token-Pool" (Der Token-Pool)

Der Autor William Cunningham schlägt eine neue Methode vor, die er Token-Pools nennt.

Stellen Sie sich den Token-Pool nicht als Zähler für Aufträge vor, sondern als eine Art "Guthaben-Konto" für Backzeit und Platz im Ofen.

1. Die Währung ist "Token" (Backzeit & Platz)

Anstatt zu zählen, wie viele Aufträge jemand stellt, misst das System, wie viel Ressourcen jeder Auftrag verbraucht.

• Token-Durchsatz: Wie schnell backen wir? (Token pro Sekunde).
• KV-Cache (Der Platz im Ofen): Wie viel Platz braucht der Teig im Ofen? Ein langer Kuchen braucht mehr Platz als ein Brötchen.
• Parallelität: Wie viele Kuchen können gleichzeitig im Ofen liegen?

Das System sagt also nicht: "Du darfst 10 Aufträge machen", sondern: "Du hast ein Guthaben von 1000 Back-Einheiten. Ein Brötchen kostet 1 Einheit, ein Hochzeitstorte kostet 100."

2. Die Kunden-Kategorien (Service-Klassen)

Nicht jeder Kunde ist gleich wichtig. Das System unterscheidet verschiedene Kunden-Typen, ähnlich wie bei einem Hotel:

• Der VIP (Dediziert/Guaranteed): Hat einen eigenen, reservierten Ofenbereich. Egal wie voll es ist, sein Brot wird immer gebacken. Er wird nie vertrieben.
• Der Flexible Gast (Elastic): Hat ein garantiertes Mindestmaß, darf aber bei freiem Platz mehr backen. Wenn es voll wird, muss er etwas zurückstecken, bekommt aber später eine "Rückzahlung" (mehr Priorität), weil er vorher geduldig war.
• Der Schnäppchenjäger (Spot): Darf nur backen, wenn wirklich alles leer ist. Wenn ein VIP kommt, wird der Schnäppchenjäger sofort aus dem Ofen geworfen (seine Anfrage wird abgelehnt), damit der VIP Platz hat.
• Der Prekäre (Preemptible): Kann jederzeit komplett rausgeworfen werden, wenn es brennt.

3. Der "Schuld-Algorithmus" (Debt Mechanism) – Das Fairness-System

Das ist das Geniale an der Idee. Stellen Sie sich vor, der flexible Gast musste heute Mittag warten, weil es voll war. Das System merkt sich das.

• Es sagt: "Hey, du hast heute etwas weniger bekommen als versprochen. Du hast jetzt Schulden beim System."
• Wenn später wieder Platz ist, bekommt dieser Gast höhere Priorität, um seine Schulden zurückzuzahlen.
• Wer hingegen immer alles bekommen hat (keine Schulden), muss bei der nächsten Knappheit vielleicht etwas warten.

Das verhindert, dass ein Kunde dauerhaft benachteiligt wird, und sorgt dafür, dass alle fair behandelt werden, auch wenn die Nachfrage schwankt.

4. Wie funktioniert das in der Praxis? (Die Türsteher)

Früher wurde entschieden, wer in den Ofen darf, erst wenn der Teig schon im Ofen lag (zu spät!).
Bei Token Pools steht ein Türsteher (API-Gateway) vor der Bäckerei.

• Bevor der Kunde überhaupt den Auftrag aufgibt, prüft der Türsteher: "Hast du genug Guthaben? Ist dein Auftrag zu groß für den aktuellen Platz? Bist du ein VIP oder ein Schnäppchenjäger?"
• Wenn es zu voll ist, sagt der Türsteher dem Schnäppchenjäger: "Entschuldigung, heute ist kein Platz mehr. Komm später wieder." (Das ist die Ablehnung).
• Der VIP kommt sofort durch.
• Das Ergebnis: Die VIPs haben immer eine schnelle Bedienung (niedrige Wartezeit), während die Schnäppchenjäger ab und zu abgewiesen werden, aber das System insgesamt effizient läuft.

Zusammenfassung in einem Satz

Statt einfach nur zu zählen, wie viele Leute an der Theke stehen, misst Token-Pool, wie viel Platz und Zeit jeder Kunde wirklich braucht, und verteilt die knappen Ofenplätze so, dass die wichtigsten Kunden immer bedient werden, während die anderen fair warten oder später nachgeholt werden – alles ohne den Ofen selbst umbauen zu müssen.

Das Ergebnis: Die Bäckerei läuft immer voll ausgelastet, niemand verhungert (wird komplett ignoriert), und die VIPs bekommen ihr Brot immer frisch und schnell, egal wie viele Schnäppchenjäger gerade versuchen, reinzukommen.

Technische Zusammenfassung

1. Problemstellung

Multi-Mandanten-fähige KI-Inferenzplattformen stehen vor der Herausforderung, Ressourcennutzung und Service-Level-Garantien (SLAs) unter schwankender Nachfrage in Einklang zu bringen. Herkömmliche Ansätze versagen dabei aus folgenden Gründen:

• Dedizierte Endpunkte: Führen zu ineffizienter Kapazitätsbindung, da GPU-Ressourcen für inaktive Modelle „gestrandet" sind.
• Rate Limits (Häufigkeitsbegrenzungen): Steuern nur die Zulassung von Anfragen, ignorieren jedoch die heterogenen Kosten einer einzelnen Inferenzanfrage. Zwei Anfragen können sich um eine Größenordnung in GPU-Zeit und KV-Cache-Verbrauch unterscheiden (abhängig von Prompt-Länge und Modellarchitektur), werden aber bei Token-basierten Limits gleich behandelt.
• Fehlende Work-Conservation: Inaktive Kapazität kann nicht von anderen Mandanten genutzt werden.
• Bursts: Herkömmliche Drosselmechanismen können nicht mit Burst-Szenarien umgehen, die durch lange Prompts (KV-Cache-Erschöpfung), komplexe Reasoning-Ausgaben oder parallele Sitzungen entstehen.

2. Methodik: Token Pools

Die Autoren stellen Token Pools als eine neue Abstraktionsebene für das Ressourcenmanagement vor. Im Gegensatz zu herkömmlichen Containern oder GPU-Scheduling-Modellen wird die Kapazität in inferenz-nativen Einheiten ausgedrückt.

A. Ressourcenmodell

Ein Token Pool verwaltet Kapazität basierend auf drei skalierbaren Ressourcen:

1. Token-Throughput ($\lambda$): Token pro Sekunde (begrenzt die GPU-Zeit).
2. KV-Cache-Kapazität ($\chi$): Speicherbedarf für den Attention-Zustand (in Bytes).
3. Konkurrenz ($r$): Anzahl gleichzeitiger aktiver Inferenzsequenzen.

Jeder Mandant erhält Entitlements (Berechtigungen), die ihm Anteile an diesen Ressourcen garantieren.

B. Service-Klassen und Priorisierung

Entitlements werden verschiedenen Klassen zugeordnet, die Schutz und Verhalten bei Engpässen definieren:

• Dedicated/Guaranteed: Garantierte Basisallokation, die nie gekürzt wird.
• Elastic: Baseline-Garantie über die Zeit, aber mit Burst-Möglichkeit. Bei Engpässen werden sie gekürzt und sammeln „Schulden" (Debt).
• Spot/Preemptible: Keine Garantie, werden bei Engpässen zuerst gedrosselt oder vollständig beendet.

C. Debt-basierter Fair-Share-Mechanismus

Ein zentrales Element ist der Schulden-Mechanismus (Debt Mechanism), der eine faire Verteilung über die Zeit sicherstellt:

• Schulden ($d_e$): Werden akkumuliert, wenn ein Mandant weniger als seine Basisallokation erhält (Unterversorgung).
• Prioritätsformel: Die Priorität $w_e$ eines Mandanten setzt sich zusammen aus:
  • Basisgewicht der Service-Klasse.
  • SLO-Dringlichkeit (strengere Latenzanforderungen = höhere Priorität).
  • Burst-Historie (Drosselung bei übermäßigem Verbrauch).
  • Akkumulierte Schulden: Höhere Schulden erhöhen die Priorität, um den Mandanten nachzuholen (ähnlich einem PI-Regler).
• Dies verhindert, dass Mandanten dauerhaft benachteiligt werden, und sorgt für eine Konvergenz zur fairen Aufteilung.

D. Systemarchitektur

Das System operiert als Control-Plane-Layer über der bestehenden Infrastruktur (z. B. Kubernetes, vLLM), ohne den Inferenz-Runner selbst zu modifizieren.

• Virtual Nodes: Der TokenPool-Controller erstellt virtuelle Kubernetes-Knoten, die die Pool-Kapazität (Tokens, KV-Cache) als erweiterbare Ressourcen advertise.
• Admission Control: Ein Auth-Service (z. B. via LiteLLM) prüft jede Anfrage vor der Ausführung. Er validiert, ob das Entitlement die Anfrage finanzieren kann, unter Berücksichtigung von aktuellen Schulden, Burst-Historie und Pool-Konkurrenz.
• Feedback-Schleife: Nach Abschluss einer Anfrage werden tatsächlicher Token-Verbrauch und Latenz gemeldet, um Schulden und Burst-Werte zu aktualisieren.

3. Hauptbeiträge

1. Formalisierung von Token Pools: Eine Abstraktion, die Kapazität in Throughput, KV-Cache und Konkurrenz zerlegt und eine Prioritätsmechanik kombiniert, die Service-Klassen, SLOs und Schulden integriert.
2. Systemarchitektur: Eine Kubernetes-native Implementierung, die den Scheduler für die Zulassung von Token-Kapazität über virtuelle Knoten wiederverwendet.
3. Experimenteller Nachweis: Validierung, dass Token Pools die Latenz für geschützte Workloads auch bei Überlastung begrenzen und eine faire Aufteilung unter elastischen Workloads mit unterschiedlichen SLOs ermöglichen.

4. Ergebnisse (Evaluation)

Die Evaluation erfolgte auf einem Kubernetes-Cluster mit vLLM-Backends (Qwen3-8B).

• Experiment 1: Schutz über Klassen hinweg (Cross-Class Protection)

  • Szenario: Ein Spot-Workload flutet den Pool, während garantierte Workloads laufen.
  • Ergebnis: Mit Token Pools bleibt die Warteschlange leer und die P99-Latenz für garantierte Workloads bleibt unter 1,2 Sekunden. Ohne Admission Control (Baseline) stieg die Latenz auf über 19 Sekunden an, da alle Workloads in die Warteschlange gerieten. Spot-Anfragen wurden selektiv mit HTTP 429 (Too Many Requests) abgelehnt.

• Experiment 2: SLO-bewusste faire Aufteilung (Fair Share)

  • Szenario: Kapazitätsengpass (Ausfall einer GPU) bei drei elastischen Workloads mit unterschiedlichen Latenzanforderungen (Coding-Assistent: 500ms, Batch-Daten: 30s, Reports: 5s).
  • Ergebnis: Der Mechanismus drosselte den Workload mit der lockersten SLO (Batch-Daten) am stärksten, während der kritische Coding-Assistent bevorzugt wurde.
  • Schulden-Mechanismus: Der unterversorgte Batch-Workload akkumulierte Schulden, was seine Priorität im Laufe der Zeit erhöhte und eine Verhungern (Starvation) verhinderte. Nach Wiederherstellung der Kapazität decayed die Schuld und die Priorität normalisierte sich.

5. Bedeutung und Fazit

Das Paper zeigt, dass Admission Control auf der API-Ebene (Gateway) effektiver ist als auf der GPU-Ebene. Durch die Verschiebung der Entscheidungsebene vor die Ausführung kann das System Ressourcen effizienter nutzen und Latenzgarantien einhalten, ohne die zugrunde liegenden Inferenz-Engines (wie vLLM oder TensorRT-LLM) ändern zu müssen.

Kernaussage: Token Pools schließen die Lücke zwischen Zulassungsentscheidungen und Ausführungskosten. Sie ermöglichen eine feinkörnige, priorisierte Ressourcenverwaltung, die sowohl die Effizienz der Hardware-Nutzung maximiert als auch Service-Level-Agreements für verschiedene Mandantentypen (von kritisch bis Spot) zuverlässig durchsetzt. Dies ist ein entscheidender Schritt hin zu skalierbaren, multi-tenant-fähigen Enterprise-KI-Plattformen.