Buoyant rilascia Kinference, control plane open source per inference con vLLM

Nel benchmark pubblico su un tipo di carico di lavoro, Kinference ha ridotto la mediana del tempo al primo token del 95% e la latenza end-to-end mediana del 45% rispetto al bilanciamento standard di Kubernetes¹.

Kinference è un progetto open source di Buoyant per costruire piattaforme di inference su vLLM. Fa da piano di controllo sopra vLLM, che esegue l’inference. Aggiunge limitazione dei token, tracciamento di utilizzo e costi per tenant, bilanciamento del carico specifico per l’inference e un motore di politiche¹. I client puntano all’endpoint HTTP di Kinference e inviano traffico compatibile con le API di OpenAI o Anthropic. Il sistema serve insiemi eterogenei e variabili di modelli, GPU e client¹.

Il bilanciamento del carico usa segnali operativi: dimensione delle code GPU, performance storica, contenuto della cache di chiavi e valori (KV) sulla GPU. La consapevolezza della cache indirizza ogni richiesta al worker vLLM che dovrà fare meno lavoro per quel prompt. Modellare il contenuto della KV cache può produrre guadagni netti nelle prestazioni dell’inference distribuita¹.

I test di capacità mostrano lo stesso effetto. Nel benchmark di throughput utile, Kinference ha servito 7,4 volte il traffico accettabile sul carico “shared-prefix” e circa 3,5 volte sul “multiturn”, sempre rispetto a kube-proxy. Ha rispettato lo SLO con concorrenza 32 sullo “shared-prefix” e 8 sul “multiturn”. L’approccio kube-proxy non ha raggiunto lo SLO a nessun livello di concorrenza misurato¹.

Il motore di politiche permette di definire regole esplicite su come instradare o rifiutare una richiesta. Le regole possono considerare tenant, modello richiesto, stato del pool GPU e classificazione semantica del prompt. Un esempio instrada i prompt semplici verso modelli più economici, a parità di lavoro considerando la cache. Un altro devia le richieste in eccesso verso endpoint di provider esterni, come OpenAI, Anthropic o Databricks, quando la coda o la pressione della cache indicano saturazione. Una politica aggiuntiva classifica i prompt che contengono PII e li invia al provider terzo se il pool è saturo¹. Le politiche possono passare revisione umana o agentica, essere versionate in git, verificate e applicate o annullate in modo indipendente¹.

Kinference espone metriche per monitoraggio, allarmi e SLO. Include tassi di token in ingresso e in uscita, con istogrammi delle dimensioni di input e output. Fornisce istogrammi di TTFT, ITL e latenza end-to-end. Conta i token di prompt in cache e fuori cache, utile per stimare i costi. Traccia uso dei modelli e saturazione delle GPU. Quasi tutte le metriche sono disponibili anche per tenant, per SLO e monitoraggi mirati per singoli team interni¹.

L’installazione parte dalle Gateway API CRD, poi dal gateway di Kinference. L’architettura pubblica due componenti: un gateway di traffico e un gestore dell’inference¹.

Per chi costruisce piattaforme interne con vLLM e Kubernetes, l’unione di bilanciamento sensibile alla cache, politiche dichiarative e metriche per tenant offre leve operative concrete. I risultati dei benchmark e la documentazione sulle politiche indicano dove intervenire per ridurre la latenza, controllare i costi e rispettare gli SLO in produzione¹.