Introduzione a Kinference
Buoyant, noto per il service mesh Linkerd, ha annunciato Kinference, un progetto open source pensato per costruire piattaforme di inferenza su Kubernetes. Kinference agisce come piano di controllo per Kubernetes e vLLM, posizionandosi davanti a una flotta di worker vLLM e decidendo a quale endpoint indirizzare ogni richiesta.
Il progetto è rilasciato con licenza Apache 2.0 su GitHub (Kinference‑AI/kinference) e la versione corrente è v0.1.0‑alpha.7. È pensato per team di sviluppo che servono numerosi modelli open‑weight a molteplici client interni, fornendo un livello di governance sopra il semplice server di modello.
Caratteristiche principali (TL;DR)
- Dimensione: v0.1.0‑alpha.7, scritto in Rust, configurabile tramite 5 CRD Kubernetes.
- Requisiti: qualsiasi cluster Kubernetes abilitato GPU con vLLM; il benchmark di Buoyant ha usato 3 GPU L40S per pool.
- Performance: guadagni notevoli su traffico con prefissi condivisi rispetto al routing tradizionale di Kubernetes Service (dati auto‑segnalati).
- Best case: tempo medio TTFT sceso da 6,88 s a 0,31 s (‑95 %) su carico con prefissi condivisi.
- Worst case: nessun miglioramento medio su prompt senza prefissi condivisi (6,92 s vs 6,83 s).
Cos’è Kinference?
Kinference è un piano di controllo basato su policy che trasforma Kubernetes + vLLM in una piattaforma di inferenza multi‑tenant. Come spiegato nella FAQ di Buoyant, vLLM costituisce il data plane mentre Kinference è il control plane.
Architettura e funzionamento
Il sistema è composto da due parti fondamentali: un gateway di traffico e un handler di inferenza. Il README su GitHub indica che l’handler espone un’interfaccia gRPC, riceve la richiesta e restituisce l’endpoint scelto insieme a eventuali modifiche al corpo della richiesta. Questo handler si accoppia a un proxy, ad esempio il Buoyant Gateway.
Kinference osserva gli eventi della KV‑cache di vLLM e le metriche del motore. Al momento utilizza il crate NVIDIA dynamo‑kv‑router per processare gli eventi di cache. La configurazione è gestita tramite cinque CRD:
- GatewayBackend
- InferencePolicy
- InferencePool
- InferenceProvider
- InferenceWorkerSet
Policy di inferenza
Le InferencePolicy sono regole dichiarative che determinano come ogni richiesta viene instradata o rifiutata. Le regole possono fare matching su tenant, modello richiesto, stato del pool GPU e tag semantici. Sul sito del progetto sono mostrati cinque pattern di policy:
- Simple to cheaper: instrada prompt a bassa complessità verso un modello più piccolo, a meno che la sovrapposizione di cache non renda più veloce il modello grande.
- Burst to cloud: salta i worker con più di 2 prompt in coda, ricorrendo a provider esterni come Bedrock.
- PII stays local: rimuove provider esterni quando scatta un tag PII e fallisce chiudendo con
onEmpty: Reject. - Batch on idle GPUs: invia richieste batch solo a worker con utilizzo KV‑cache inferiore al 70 %.
- Model aliasing: pubblica un nome stabile (es.
standard-model) supportato da più modelli reali.
La maggior parte delle regole termina con minimize: PredictedTTFT. Kinference predice il tempo al primo token (TTFT) per ogni endpoint candidato, usando la sovrapposizione di cache e la lunghezza della coda. Le policy sono versionate in git e possono essere validate offline con il CLI kinfctl.
Benchmark e prestazioni
Buoyant ha pubblicato un benchmark comparativo contro il bilanciamento tradizionale di Kubernetes. Ogni ramo del test ha utilizzato 3 pod vLLM 0.31.0, ciascuno su una GPU L40S, con modello Qwen3.8‑27B‑FP8. Il carico è stato generato da GuideLLM 0.8.1.
Il baseline era un Service di tipo ClusterIP, con kube‑proxy che sceglieva un pod a caso per connessione.
Risultati di latenza (median TTFT)
| Workload | Kubernetes Service | Kinference | Variazione |
|---|---|---|---|
| Control (no shared prefix) | 6.92 s | 6.83 s | Nessuna differenza significativa |
| Shared‑prefix | 6.88 s | 0.31 s | ≈ ‑95 % |
| Multiturn | 1.70 s | 0.59 s | ≈ ‑65 % |
La latenza end‑to‑end mediana è diminuita del 45 % su carico con prefissi condivisi e del 32 % su multiturn. Anche sul traffico di controllo il p95 TTFT è sceso da 21.46 s a 12.33 s, grazie al bilanciamento consapevole della coda.
Test di capacità
Il test di capacità ha misurato il goodput, cioè le richieste al minuto che rispettano uno SLO TTFT. I risultati più alti sono stati:
- Shared‑prefix: 103,0 req/min vs 14,0 req/min (≈ 7.4×).
- Multiturn: 82,7 req/min vs 23,8 req/min (≈ 3.5×).
Il Service di base non ha mai soddisfatto lo SLO a nessun livello di concorrenza testato. È importante notare che i numeri sono auto‑segnalati e il baseline utilizza routing casuale, non un router avanzato come llm‑d o Dynamo.
Confronto con soluzioni concorrenti
| Feature | Kinference | llm‑d | NVIDIA Dynamo | vLLM Production Stack |
|---|---|---|---|---|
| Backer | Buoyant | CNCF sandbox (Red Hat, Google Cloud, IBM, CoreWeave, NVIDIA) | NVIDIA | vLLM project |
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Maturity | v0.1.0‑alpha.7 | v0.7 (May 2026) | 1.x (1.5.1 containers) | Reference stack |
| Engines supportati | vLLM (SGLang, TensorRT‑LLM in road‑map) | vLLM, SGLang | vLLM, SGLang, TensorRT‑LLM | vLLM |
| Routing KV‑cache aware | Yes, predicted TTFT | Yes, prefix‑cache and predicted latency | Yes, KV‑aware router | Session‑based; prefix‑aware WIP |
| Policy declarative (CRD) | Yes (InferencePolicy) | Not documented | Not documented | Not documented |
| Burst to external providers | Yes (InferenceProvider) | Not documented | Not documented | Not documented |
| Disaggregated prefill/decode | Not disclosed | Yes | Yes | On roadmap |
| Multi‑tenant controls | Per‑tenant metrics; rate limits planned | Flow control for multi‑tenant serving | Gateway‑level rate limiting via GAIE | Not documented |
| Main result | -95 % median TTFT vs kube‑proxy (3 × L40S) | 3× throughput, 2× faster TTFT vs round‑robin (4 × MI300X) | 2× faster TTFT with KV‑aware routing (Baseten) | Not disclosed |
Kinference si distingue per la governance: policy, alias, fallback a provider esterni e contabilità per tenant. llm‑d e Dynamo eccellono invece in prestazioni grezze, disaggregazione e copertura di più motori.
Distribuzione e monitoraggio
L’installazione segue cinque passaggi descritti nella guida di avvio rapido:
- Installare le CRD dell’API Gateway v1.5.1.
- Distribuire il Helm chart del Buoyant Gateway.
- Installare il chart Helm di Kinference.
- Configurare le InferencePolicy, InferencePool e gli altri CRD.
- Verificare il corretto funzionamento tramite i metrici Prometheus.
Kinference esporta metriche Prometheus e fornisce dashboard Grafana (link) con TTFT, ITL, latenza end‑to‑end, token in cache vs non in cache, tipicamente per tenant.
Considerazioni finali
- Kinference è un piano di controllo Apache 2.0 per vLLM su Kubernetes, proveniente dagli autori di Linkerd.
- Le regole dichiarative InferencePolicy gestiscono scelta del modello, burst a provider esterni, routing PII e ammissione batch.
- I benchmark auto‑segnalati mostrano una riduzione del 95 % del median TTFT su traffico con prefissi condivisi rispetto a kube‑proxy.
- Il goodput massimo è aumentato di circa 7.4× su carico shared‑prefix e 3.5× su multiturn.
- Il progetto è ancora in fase alpha: rate limiting, classificatori e supporto all’API Anthropic non sono ancora disponibili.
Per approfondire, consultate il repo GitHub, la documentazione, il post di lancio e il rapporto di benchmark. Seguite gli aggiornamenti su Twitter e partecipate al subreddit ML con oltre 150 k membri.