Token Management in Multi-Tenant AI Inference Platforms

Each language version is independently generated for its own context, not a direct translation.

Le Problème : Le Restaurant Trop Populaire

Imaginez un restaurant très célèbre (votre plateforme d'IA) qui sert des plats complexes (des réponses d'IA). Ce restaurant a deux gros problèmes :

Les tables sont réservées à l'avance (Endpoints dédiés) : Si vous réservez une table pour un seul client, mais qu'il ne vient pas, la table reste vide. C'est du gaspillage d'argent et d'espace.
Le comptage des couverts (Limites de taux classiques) : Le gérant dit : "Chaque client peut commander 10 plats par heure". Mais il ne se rend pas compte que certains plats sont des "hamburgers rapides" (demandes simples) et d'autres sont des "banquets de 50 plats" (demandes complexes qui prennent beaucoup de temps et de ressources). Si un client commande 10 banquets, il épuise toute la cuisine, et les autres clients affamés doivent attendre des heures.

Résultat : Quand tout le monde veut manger en même temps (pics de demande), la cuisine s'effondre, les plats mettent une éternité à arriver, et tout le monde est mécontent.

La Solution : Le Système de "Jetons" (Token Pools)

L'auteur propose une nouvelle façon de gérer le restaurant, qu'il appelle les Token Pools (Pools de jetons). Au lieu de compter les clients ou les heures, on compte l'énergie réelle nécessaire pour cuisiner.

Voici comment cela fonctionne avec trois analogies clés :

1. La Monnaie de l'IA (Les Jetons)

Imaginez que chaque demande d'IA ne coûte pas "1 ticket", mais un certain nombre de jetons d'énergie.

Une petite question coûte 10 jetons.
Une longue histoire complexe coûte 1000 jetons.
Le système ne regarde pas seulement combien de personnes entrent, mais combien de jetons elles vont consommer. C'est comme si le restaurant facturait selon le poids des ingrédients utilisés, et non selon le nombre de couverts.

2. Les Catégories de Clients (Classes de Service)

Le restaurant a différents types de clients, chacun avec des règles différentes :

Les VIP (Garantis/Dédiés) : Ils ont une table réservée. Même si le restaurant est plein, leur commande passe toujours en premier. Ils ne sont jamais bloqués.
Les Clients Flexibles (Élastiques) : Ils peuvent commander beaucoup quand il y a de la place, mais s'il y a une foule, ils acceptent de patienter un peu.
Les Clients "En Attente" (Spot/Préemptibles) : Ils arrivent sans réservation. Ils mangent ce qui reste. Si le restaurant est plein, on leur dit gentiment "Désolé, repassez plus tard".

3. La Récompense de l'Attente (La Dette)

C'est l'astuce la plus intelligente du système.

Si un client "Flexible" doit attendre parce que les VIP mangent, il accumule de la dette.
Cette dette n'est pas une mauvaise note ! C'est un bon de réduction. Plus il a attendu, plus son "bon de réduction" est gros.
Quand un peu de place se libère, le système dit : "Ah, ce client a accumulé beaucoup de dette, on va lui donner la priorité maintenant pour qu'il rattrape son retard."
Cela évite qu'un client soit oublié indéfiniment. C'est comme une file d'attente équitable qui s'ajuste automatiquement.

Comment ça marche en pratique ?

Au lieu de laisser les clients entrer dans la cuisine et de se battre pour les fourneaux, le système met un gardien à la porte (le Gateway).

Le Gardien vérifie le portefeuille : Avant même que la demande n'arrive à la cuisine, le gardien regarde : "Est-ce que ce client a assez de jetons ? Est-ce qu'il a de la place dans son quota ?"
Le tri intelligent : Si la cuisine est pleine, le gardien refuse poliment les clients "En Attente" (Spot) pour protéger les VIP. Il ne bloque pas tout le monde, juste ceux qui peuvent attendre.
L'équilibre dynamique : Si un client VIP ne commande rien pendant un moment, ses jetons inutilisés peuvent être prêtés aux clients Flexibles. Personne ne perd de temps, tout le monde est plus efficace.

Les Résultats de l'Expérience

L'auteur a testé ce système dans un laboratoire (un petit serveur) :

Sans ce système : Quand tout le monde commandait en même temps, les clients VIP attendaient 19 secondes pour leur plat (très lent !).
Avec ce système : Les clients VIP ont eu leur plat en moins de 1,2 seconde, même quand le restaurant était bondé. Les clients "En Attente" ont simplement reçu un message "Repassez plus tard" et ont attendu leur tour sans ralentir les VIP.

En Résumé

Ce papier propose de passer d'une gestion rigide (compter les clients) à une gestion intelligente (compter l'effort réel).

Avant : Tout le monde souffre ensemble quand il y a du monde.
Maintenant : Les clients importants sont protégés, les autres sont gérés équitablement grâce à un système de "dette" qui récompense l'attente, et la cuisine fonctionne à plein régime sans jamais s'effondrer.

C'est comme transformer un restaurant chaotique en un service de livraison ultra-efficace où chaque commande est pesée, priorisée et livrée au bon moment.

Each language version is independently generated for its own context, not a direct translation.

1. Problématique

Les plateformes d'inférence d'IA multi-locataires (multi-tenant) actuelles peinent à concilier une utilisation efficace des ressources et des garanties de niveau de service (SLO) face à une demande variable. Les approches conventionnelles échouent pour deux raisons principales :

Les endpoints dédiés : Ils isolent fortement les locataires mais entraînent une sous-utilisation des ressources (capacité « échouée ») lorsque les modèles sont inactifs.
Les limites de débit (Rate Limits) : Elles gèrent l'admission des requêtes (ex: tokens par minute) sans tenir compte du coût d'exécution hétérogène. Une requête peut consommer des ressources GPU (mémoire KV cache, temps de calcul) de manière disproportionnée par rapport à une autre, selon la longueur du contexte ou la complexité du modèle.

De plus, les systèmes actuels ne gèrent pas bien les bursts (pics de demande) caractéristiques du trafic d'inférence, tels que les explosions de longueur de prompt (épuisant le cache KV) ou les sessions concurrentes. Il n'existe pas de mécanisme permettant de « récupérer » la capacité inutilisée (work-conservation) pour d'autres locataires sans modifier les moteurs d'inférence sous-jacents.

2. Méthodologie : Les « Token Pools »

L'auteur propose une nouvelle abstraction de contrôle, les Token Pools, qui représente la capacité d'inférence en unités natives à l'inférence plutôt qu'en unités de calcul brutes (CPU/GPU).

A. Modèle de Ressources

La capacité d'un pool est décomposée en trois ressources planifiables :

Débit de tokens ( $\lambda$ ) : Tokens/seconde (bornant le temps GPU).
Capacité de cache KV ( $\chi$ ) : Mémoire en octets nécessaire pour l'état d'attention (facteur limitant pour les longs contextes).
Concurrence ( $r$ ) : Nombre de séquences d'inférence actives simultanément.

B. Classes de Service et Priorité

Les locataires possèdent des droits d'accès (entitlements) à une partie de la capacité du pool, classés selon une hiérarchie de protection :

Dédicacé (Dedicated) : Allocation réservée, jamais rétractée.
Garanti (Guaranteed) : Allocation réservée, mais sans dépassement (burst).
Élastique (Elastic) : Garantie moyenne dans le temps, peut être réduite en cas de contention.
Spot / Préemptible : Aucune garantie, première ligne de réduction ou d'éviction.

Un mécanisme de poids de priorité ( $w_e$ ) combine :

La classe de service.
L'urgence du SLO (Objectif de Latence).
L'historique des bursts.
La dette de service ( $d_e$ ) : Un mécanisme de rétroaction qui augmente la priorité d'un locataire s'il a été sous-servi dans le passé (approche de type « Fair Share »).

C. Architecture Système

Le système s'intègre dans Kubernetes sans modifier les moteurs d'inférence (vLLM, TensorRT-LLM) :

Nœuds Virtuels : Le pool de tokens est exposé à Kubernetes via des nœuds virtuels synthétiques qui annoncent des ressources étendues (tokens, KV cache).
Contrôle d'Admission : Un service d'authentification (API Gateway) intercepte chaque requête. Il vérifie si le droit d'accès du locataire peut « financer » la requête selon la capacité disponible et la priorité.
Boucle de Rétroaction : Après l'exécution, le gateway met à jour la consommation réelle (dette et burst) dans Redis, ajustant dynamiquement les priorités pour les requêtes suivantes.

3. Contributions Clés

Formalisation des Token Pools : Une abstraction de ressources native à l'inférence (débit, KV cache, concurrence) avec un mécanisme de priorité combinant classes de service, SLO et dette.
Architecture Kubernetes-Native : Utilisation de nœuds virtuels et de ressources personnalisées (CRDs) pour déplacer le contrôle d'admission du niveau du conteneur/GPU vers la frontière de l'API, sans toucher au runtime d'inférence.
Preuve Expérimentale : Validation que cette approche maintient une latence bornée pour les charges de travail critiques lors de surcharges et assure une convergence équitable entre charges élastiques.

4. Résultats Expérimentaux

Les expériences ont été menées sur un cluster Kubernetes avec un backend vLLM (modèle Qwen3-8B).

Expérience 1 : Protection Inter-Classes
- Scénario : Une charge de travail « Spot » inonde le système, créant une surcharge de 38 %.
- Résultat : Avec les Token Pools, les requêtes Spot sont rejetées (HTTP 429) avant d'entrer dans la file d'attente, protégeant les charges « Garanti ». La latence P99 reste inférieure à 1,2 seconde.
- Comparaison : Sans contrôle d'admission, la file d'attente s'accumule et la latence P99 explose à plus de 19 secondes pour tous les locataires.
Expérience 2 : Partage Équitable Sensible au SLO (Intra-Classe)
- Scénario : Deux charges élastiques (un assistant de codage avec SLO strict de 500ms et un pipeline de données avec SLO de 30s) partagent une capacité réduite de moitié.
- Résultat : Le système privilégie l'assistant de codage (priorité plus élevée due au SLO serré). Cependant, le pipeline de données accumule de la « dette » en étant sous-servi, ce qui augmente progressivement sa priorité pour éviter la famine (starvation).
- Dynamique : L'écart de priorité se réduit de 4,6x à 3,9x au fil du temps, démontrant la convergence vers un partage équitable tout en respectant les hiérarchies de service.

5. Signification et Impact

Ce travail résout la tension fondamentale entre l'efficacité des ressources (partage) et la garantie de service (isolation) dans l'IA générative.

Granularité Fin : Contrairement aux limites de débit statiques, les Token Pools comprennent le coût réel de l'inférence (longueur de contexte, architecture).
Adoption Facile : En opérant au niveau du plan de contrôle (Control Plane) et non du runtime, cette solution peut être adoptée sans remplacer les infrastructures d'inférence matures existantes.
Équité Dynamique : Le mécanisme de dette permet une gestion automatique de la capacité en cas de pénurie, assurant que les locataires sous-servis sont compensés ultérieurement, évitant ainsi les conflits manuels de reconfiguration.

En conclusion, les Token Pools offrent une fondation principielle pour la gestion de capacité dans les plateformes d'inférence multi-locataires, permettant de maintenir des engagements de niveau de service tout en optimisant l'utilisation des GPU coûteux.