Token Management in Multi-Tenant AI Inference Platforms

Il paper propone "token pools", un'astrazione di controllo che gestisce la capacità di inferenza AI in ambienti multi-tenant tramite unità native (token, cache KV, concorrenza) per garantire prestazioni e utilizzo delle risorse superiori rispetto ai tradizionali limiti di velocità, permettendo allo stesso tempo un'allocazione dinamica e equa del carico.

L'essenziale

Immagina di essere il direttore di un ristorante molto esclusivo e affollato, dove i cuochi (le intelligenze artificiali) preparano piatti complessi su richiesta.

Il problema di questo ristorante è che non tutti i clienti sono uguali:

1. Alcuni sono VIP che hanno prenotato un tavolo e vogliono il servizio perfetto, anche se c'è la folla.
2. Altri sono clienti "spot" (come chi entra senza prenotazione) che accettano di aspettare o di essere cacciati se il locale è pieno.
3. Altri ancora sono clienti "elastic" che vogliono mangiare bene, ma se c'è troppa gente, accettano di aspettare un po' di più, purché alla fine vengano serviti equamente.

Il problema attuale dei ristoranti AI (le piattaforme di inferenza) è che usano un sistema di gestione molto stupido:

• Metodo A (Prenotazione fissa): Assegnano un tavolo e un cuoco a ogni cliente. Se il cliente VIP non mangia, quel cuoco sta fermo a guardare il muro. È uno spreco enorme.
• Metodo B (Limiti rigidi): Dicono "Ogni cliente può ordinare massimo 5 piatti al minuto". Ma non sanno che ordinare 5 piccoli antipasti richiede meno lavoro che ordinare 1 enorme arrosto. Se un cliente ordina l'arrosto, intasa la cucina e blocca tutti gli altri, anche se ha rispettato il limite dei "5 piatti".

La soluzione proposta in questo articolo si chiama "Token Pools" (Piscine di Gettoni).

L'Analogia della "Piscina di Gettoni"

Immagina che invece di contare i "piatti" o i "clienti", il ristorante abbia una piscina di gettoni speciali che rappresentano l'energia necessaria per cucinare.

1. I Gettoni sono la valuta reale: Non contano i piatti, ma quanto lavoro richiede il piatto.

   • Un antipasto costa 1 gettone.
   • Un arrosto lungo e complesso costa 50 gettoni.
   • Ogni cliente ha un "portafoglio" (una Entitlement) con un certo numero di gettoni garantiti.

2. Il Portiere Intelligente (Admission Control):
   Quando un cliente arriva al bancone, il portiere non guarda solo se c'è un tavolo libero. Controlla il portafoglio del cliente:

   • "Hai abbastanza gettoni per questo arrosto?"
   • "Sei un VIP? Allora ti garantisco che i tuoi gettoni verranno usati subito."
   • "Sei un cliente spot? Se la piscina è piena, ti dico gentilmente 'Ritorna più tardi' (errore 429) invece di farti aspettare 20 minuti in fila."

   Il risultato: I VIP non subiscono mai ritardi. I clienti spot vengono cacciati prima di entrare in cucina, così la fila non si crea mai e la cucina lavora sempre al massimo della velocità.

La Magia della "Pensione di Debito" (Debt Mechanism)

C'è un secondo problema: cosa succede se un cliente VIP è stato cacciato o servito male per un po' di tempo?

Il sistema usa una Pensione di Debito:

• Se un cliente "Elastico" viene servito lentamente perché c'era troppa gente, il sistema gli accumula un debito positivo.
• Quando la folla si dirada, quel cliente non viene trattato come un normale, ma come un "creditor". Il sistema gli dice: "Scusa per prima, ora che c'è spazio, ti do la priorità per recuperare il tempo perso".
• Questo crea un equilibrio: nessuno viene lasciato indietro per sempre. Se hai aspettato troppo, il sistema ti ripaga con priorità futura.

Come funziona nella vita reale (senza cambiare la cucina)

Il bello di questo sistema è che non serve ristrutturare la cucina (non serve cambiare i motori delle AI come vLLM o i server).

• Si aggiunge solo un portiere intelligente all'ingresso (un livello di controllo software).
• Questo portiere decide chi entra e chi no, basandosi sui gettoni e sulla priorità.
• Una volta dentro, la cucina fa il suo lavoro come sempre.

I Risultati Sperimentali

Gli autori hanno provato questo sistema in un laboratorio:

1. Protezione: Quando la folla era enorme, i clienti VIP hanno mantenuto un servizio rapidissimo (meno di 1,2 secondi), mentre senza questo sistema tutti sarebbero rimasti bloccati per 19 secondi.
2. Equità: Quando la capacità era scarsa, il sistema ha dato priorità a chi aveva bisogno di risposte veloci (come un assistente di coding) rispetto a chi poteva aspettare (come un generatore di report), ma ha assicurato che chi aspettava troppo ricevesse priorità in seguito.

In sintesi

Il paper dice: "Smettete di contare i clienti o i piatti. Contate il lavoro reale (i token) che devono fare. Date a ogni cliente un budget di gettoni. Se la piscina è piena, dite 'no' a chi può aspettare, per proteggere chi non può. E se qualcuno ha aspettato troppo, ripagatelo con la priorità successiva."

È come trasformare un caos di code in un sistema di prenotazioni intelligente, dove ognuno sa esattamente cosa aspettarsi e nessuno spreca tempo o risorse.

Sommario tecnico

1. Il Problema

Le piattaforme di inferenza AI multi-tenant devono bilanciare l'efficienza nell'utilizzo delle risorse con le garanzie di livello di servizio (SLO) in condizioni di domanda variabile. Gli approcci convenzionali falliscono nel raggiungere questo equilibrio per due motivi principali:

• Endpoint dedicati: Assegnano istanze GPU specifiche per modello o tenant. Sebbene offrano un forte isolamento, portano a uno spreco di capacità (capacity stranding) quando i modelli sono inattivi, aggravando l'inefficienza per i modelli a lunga coda.
• Limiti di velocità (Rate Limits): Gestiscono l'ammissione delle richieste basandosi su quote fisse (es. token al minuto) senza considerare il costo effettivo di esecuzione. Due richieste possono richiedere quantità di GPU e memoria KV cache (Key-Value cache) molto diverse a seconda della lunghezza della sequenza e dell'architettura del modello, ma i rate limit tradizionali le trattano allo stesso modo.

Nessuno di questi approcci supporta la "conservazione del lavoro" (work-conservation), impedendo di prestare capacità inattiva ad altri tenant, e fallisce di fronte ai picchi di traffico tipici dell'inferenza (es. burst di lunghezza del prompt o di output).

2. Metodologia: Token Pools

L'autore propone i Token Pools, un'astrazione del piano di controllo (control-plane) che rappresenta la capacità di inferenza in unità native dell'inferenza, invece che in risorse generiche come CPU o GPU.

Modello delle Risorse

La capacità è scomposta in tre risorse schedulabili:

1. Throughput di Token ($\lambda$): Velocità di produzione dei token (token/secondo).
2. Capacità KV Cache ($\chi$): Memoria necessaria per lo stato di attenzione (in byte).
3. Concorrenza ($r$): Numero di sequenze di inferenza attive simultaneamente.

Meccanismo di Priorità e Debito

Il sistema utilizza un meccanismo di priorità dinamico che combina diverse classi di servizio e un sistema di "debito":

• Classi di Servizio: Definiscono l'ordine di protezione (Dedicato, Garantito, Elastico, Spot, Preemptible). Le classi garantite non vengono mai ridotte, mentre le classi Spot vengono limitate per prime.
• Formula di Priorità: Il peso di priorità ($w_e$) di un tenant è calcolato basandosi sulla classe di servizio, l'urgenza dell'SLO, la storia dei picchi (burst) e il debito di servizio accumulato.
• Meccanismo di Debito: Se un tenant riceve meno risorse rispetto alla sua quota base (underservice), accumula un debito. Questo debito aumenta la sua priorità futura, spingendo il sistema verso un equilibrio di "fair-share" (quota equa) nel tempo. Al contrario, chi ha un surplus accumula credito e riduce la priorità.

Architettura del Sistema

L'implementazione è nativa per Kubernetes e non richiede modifiche ai runtime di inferenza sottostanti (come vLLM o TensorRT-LLM):

• Nodi Virtuali: Un "Virtual Node Provider" crea nodi sintetici che pubblicizzano la capacità del pool (token e KV cache) come risorse estese di Kubernetes.
• Admission Control: Un servizio di autenticazione intercetta le richieste all'API Gateway. Valuta se il tenant ha diritto alla risorsa in base al suo stato, ai limiti di concorrenza e al budget di token.
• Gestione della Contesa: In caso di sovraccarico, le richieste a bassa priorità vengono rifiutate (HTTP 429) prima di entrare nella coda, proteggendo le richieste ad alta priorità e mantenendo la latenza controllata.

3. Contributi Chiave

1. Formalizzazione dei Token Pools: Definizione delle risorse di scheduling native per l'inferenza (throughput, KV cache, concorrenza) con un meccanismo di priorità che integra classe di servizio, SLO e debito.
2. Architettura di Sistema: Un design che riutilizza lo scheduler di Kubernetes tramite nodi virtuali per gestire l'ammissione della capacità di token, senza modificare i backend di inferenza esistenti.
3. Evidenza Sperimentale: Dimostrazione che questo approccio mantiene una latenza P99 limitata per i carichi di lavoro garantiti durante i picchi, permettendo al contempo una convergenza equa tra carichi elastici con requisiti eterogenei.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su un cluster Kubernetes con backend vLLM.

• Esperimento 1: Protezione Cross-Class (Isolamento):

  • Scenario: Un carico di lavoro "Spot" (batch job) inondava il sistema, creando un sovraccarico del 38% rispetto alla capacità disponibile.
  • Risultato: Con i Token Pools, le richieste Spot in eccesso sono state rifiutate immediatamente, mantenendo la coda di attesa vuota e la latenza P99 per i carichi "Garantiti" sotto 1,2 secondi.
  • Baseline (Senza controllo): Senza admission control, la coda cresceva fino a 34 richieste, portando la latenza a degradare oltre 19 secondi per tutti i tenant.

• Esperimento 2: Fair-Share Consapevole degli SLO:

  • Scenario: Capacità ridotta a causa di un guasto simulato. Due servizi elastici con SLO diversi (un assistente di coding con SLO stretto di 500ms e una pipeline di dati con SLO largo di 30s) hanno condiviso la capacità residua.
  • Risultato: Il sistema ha limitato selettivamente il servizio a bassa priorità (pipeline dati), proteggendo l'assistente di coding.
  • Meccanismo di Debito: Il servizio a bassa priorità ha accumulato debito, aumentando progressivamente la sua priorità durante l'outage per evitare la fame (starvation), dimostrando una convergenza equa. Quando la capacità è stata ripristinata, il debito è decaduto e le priorità sono tornate ai livelli basati sugli SLO.

5. Significato e Impatto

Il lavoro risolve la tensione fondamentale tra l'alta utilizzazione delle risorse (che richiede condivisione) e le garanzie di servizio (che richiedono isolamento).

• Decisioni al Gateway: Sposta il punto di controllo dall'allocazione delle GPU (dove è troppo tardi per degradare elegantemente) all'ingresso dell'API, permettendo decisioni di priorità sub-secondo.
• Adozione Pratica: Poiché opera come un layer di controllo sopra i runtime esistenti, le organizzazioni possono adottare questa soluzione senza sostituire i motori di inferenza maturi già in produzione.
• Gestione Dinamica: A differenza dei limiti di velocità statici, il sistema si adatta automaticamente ai cambiamenti di capacità e domanda, utilizzando il debito come meccanismo di memoria per garantire equità nel tempo.

In sintesi, i Token Pools offrono una fondazione principiale per la gestione della capacità nelle piattaforme AI multi-tenant, garantendo che i carichi di lavoro critici siano protetti mentre le risorse sottoutilizzate vengono sfruttate in modo efficiente ed equo.