Buoyant, l’azienda che sviluppa Linkerd, ha pubblicato Kinference, un progetto open source destinato a costruire piattaforme di inferenza su Kubernetes. Posizionato davanti a un insieme di server vLLM, decide, per ogni richiesta, verso quale server viene inviata. Il progetto è distribuito con licenza Apache 2.0 su GitHub, nella sua versione v0.1.0-alpha.7.
- Buoyant pubblica Kinference, un progetto open source con licenza Apache 2.0.
- Kinference decide quale server vLLM riceve ogni richiesta su Kubernetes.
- Secondo Buoyant, con prefisso condiviso la latenza mediana scende del 95%.
- I risultati sono auto-dichiarati e il progetto resta in fase alpha.
Un livello di controllo sopra vLLM
Kinference combina Kubernetes, la piattaforma di orchestrazione di container, e vLLM, il motore che fa girare i modelli linguistici. Secondo la FAQ di Buoyant, vLLM costituisce il piano dati, mentre Kinference svolge il ruolo di piano di controllo. In un unico strato, applica politiche di routing, limiti di velocità in token, un bilanciamento del carico che tiene conto della cache KV, cioè la memoria che conserva i calcoli già effettuati, oltre a metriche per tenant.
Il sistema comprende due elementi: un gateway per il traffico e un gestore di inferenza. Quest’ultimo espone un’interfaccia gRPC, riceve una richiesta e restituisce l’endpoint selezionato, oltre al corpo della richiesta eventualmente modificato. Funziona con un proxy, come la Buoyant Gateway. Kinference monitora gli eventi della cache KV e le metriche del motore, e si basa sul crate dynamo-kv-router di NVIDIA per elaborare questi eventi. La sua configurazione si basa su cinque risorse Kubernetes: GatewayBackend, InferencePolicy, InferencePool, InferenceProvider e InferenceWorkerSet.
Le politiche di inferenza sono regole dichiarative che specificano come ogni richiesta viene instradata o rifiutata. Possono basarsi sul tenant, sul modello richiesto, sullo stato dei pool di GPU o su etichette semantiche. Il sito del progetto ne presenta diversi esempi, come l’invio di richieste semplici verso un modello più piccolo, o il ricorso a un fornitore cloud come Bedrock quando un server ha più di 2 richieste in attesa. Le politiche sono memorizzate in git e possono essere validate offline con lo strumento da riga di comando kinfctl.
Risultati misurati da Buoyant
Buoyant ha confrontato Kinference con il semplice bilanciamento del carico di Kubernetes. Ogni configurazione utilizzava tre pod vLLM 0.31.0, ciascuno su una GPU L40S, con il modello Qwen3.8-27B-FP8. Su un traffico che condivide lo stesso prefisso, la latenza mediana prima del primo token (TTFT) passa, secondo Buoyant, da 6,88 s a 0,31 s, ovvero una riduzione di circa il 95%. Senza prefisso condiviso, i valori sono 6,92 s contro 6,83 s, senza differenza significativa secondo l’editore.
Durante un test di capacità, il throughput utile, misurato in richieste al minuto che rispettano un obiettivo di TTFT, raggiunge 103,0 contro 14,0 req/min sul traffico a prefisso condiviso, ovvero circa 7,4 volte di più. Questi dati sono auto-dichiarati. Il riferimento è un routing casuale, e non un altro router che tiene conto della cache, come llm-d o Dynamo. Buoyant precisa inoltre che le sue soglie di 8 s e 4 s sono più adatte ad agenti offline che a chatbot. La tabella comparativa pubblicata con l’articolo presenta l’angolo distintivo di Kinference come la governance, ovvero le politiche, gli alias dei modelli, i fallback verso fornitori e la contabilità per tenant, mentre llm-d e Dynamo sono descritti come più performanti sul servizio grezzo.
Il progetto rimane in fase alpha. La limitazione della velocità, i classificatori e il supporto per l’API Anthropic non sono ancora disponibili.
