Kinference: Buoyant veröffentlicht Open-Source-Control-Plane für Inferenz mit vLLM

Was Kinference leistet

Kinference entstand bei Buoyant, nachdem das Unternehmen beobachtet hatte, wie Kunden Schwierigkeiten hatten, Open-Weight-Modelle in ihren eigenen Umgebungen zu betreiben. Es ist als Control-Plane-Schicht einer Inferenzplattform konzipiert, während vLLM die eigentliche Inferenz übernimmt.

Der Funktionsumfang deckt ab, was Buoyant für den praktischen Aufbau einer Plattform als notwendig beschreibt: Token-Ratenbegrenzung, Nutzungs- und Kostenerfassung pro Mandant, intelligentes Load Balancing und Inferenz-Policies.

Kinference lässt sich mit einem bestehenden Stack kombinieren. Teams richten ihre Inferenz-Clients auf den HTTP-Endpunkt aus und senden dorthin OpenAI- oder Anthropic-kompatiblen Traffic. Laut Buoyant bedient es eine heterogene, sich weiterentwickelnde Palette von Modellen, die auf einem heterogenen, sich weiterentwickelnden GPU-Pool laufen, für ebenso vielfältige Clients.

Cache-bewusstes Load Balancing und Benchmark-Ergebnisse

Das Load Balancing von Kinference ist speziell auf Inferenz zugeschnitten. Es berücksichtigt Signale wie die Größe der GPU-Warteschlangen, die bisherige Performance und den Inhalt des KV-Cache auf der GPU. Dank dieser KV-Cache-Kenntnis kann es eine Anfrage an den vLLM-Worker senden, der für genau diese Anfrage den geringsten Aufwand hat.

Buoyant verweist auf eigene öffentliche Benchmarks. Im Vergleich zum standardmäßigen Kubernetes-Load-Balancing senkte Kinference laut Unternehmen die mediane Time-to-First-Token (TTFT) um 95 Prozent und die mediane Ende-zu-Ende-Latenz um 45 Prozent bei einem Workload-Typ.

In einem separaten Kapazitäts-Benchmark, der maß, wie viele Anfragen pro Minute jeder Endpunkt innerhalb eines Latenz-SLO bedienen konnte, erreichte Kinference bei einem Workload mit gemeinsamem Präfix den 7,4-fachen Goodput und bei einem Multiturn-Workload etwa den 3,5-fachen. Das gewählte SLO erreichte es beim Shared-Prefix-Workload bei einer Concurrency von 32 (dem höchsten gemessenen Wert) und beim Multiturn-Workload bei einer Concurrency von 8. Der kube-proxy-Ansatz erreichte das SLO bei keiner Concurrency-Stufe.

Inferenz-Policies

Die zentrale Idee in Kinference ist die Inferenz-Policy, mit der Plattformbetreiber Zielkonflikte zwischen Nutzung, Performance und Prioritäten austarieren können. Buoyant zufolge fragten Kunden, wie sie Nutzern ermöglichen können, breitere Modellklassen anzufordern, etwa "irgendein Qwen-3.8-Modell" oder "was auch immer sich fürs Coding eignet", statt konkreter Checkpoints. Außerdem wollten sie wissen, wie sich einfache Anfragen auf günstigere Modelle umleiten lassen, ohne einen ganzen Prompt-Verlauf an eine kalte GPU zu schicken und einen hohen Latenzaufschlag in Kauf zu nehmen.

Statt Einzelfunktionen zu bauen, entwickelte Buoyant eine Policy-Schicht, die in YAML definiert wird. Die Ankündigung nennt drei Beispiele:

• Semantisches Routing: Prompts nach Komplexität klassifizieren und einfachere an günstigere Modelle leiten, es sei denn, die Cache-Nutzung macht ein teures Modell schneller.
• Cloud Bursting: überschüssige Anfragen an Endpunkte von Cloud-Anbietern senden, wenn Warteschlangentiefe oder Cache-Druck zeigen, dass die GPUs ausgelastet sind.
• Umgang mit PII: Prompts mit personenbezogenen Daten (PII) so klassifizieren, dass sie auf lokaler Infrastruktur bleiben; steht keine lokale Option zur Verfügung, werden Anfragen abgelehnt (Fail Closed).

Policies können auf Mandant, angefordertem Modell, Zustand des GPU-Pools, semantischer Klassifizierung und weiteren Faktoren basieren. Sie können von Menschen oder Agenten geprüft, in Git eingecheckt, gelintet und freigegeben sowie unabhängig voneinander angewendet oder zurückgerollt werden.

Metriken, Installation und Verfügbarkeit

Kinference stellt zudem Metriken für Monitoring, Alerting und SLOs bereit. Dazu zählen Token-Raten für Ein- und Ausgabe, Histogramme der Größen von Eingabe- und Ausgabe-Tokens, Histogramme für TTFT, ITL und Ende-zu-Ende-Latenz, gecachte gegenüber nicht gecachten Prompt-Tokens zur Kostenschätzung, Modellnutzung und GPU-Auslastung. Fast jede Metrik ist auch pro Mandant verfügbar.

Die Installation erfolgt über Helm und die Gateway-API-CRDs. Die Schritte: zuerst die Gateway-API-CRDs installieren, dann das Kinference-Gateway, danach Kinference samt CRDs und schließlich prüfen, ob die Pods laufen. Buoyant weist darauf hin, dass sich die Schritte weiterentwickeln werden, und verweist auf die Dokumentation unter kinference.ai/docs.

Kinference ist vollständig Open Source unter Apache v2 und auf GitHub verfügbar. Buoyant freut sich über Feedback, Issues und Benchmark-Berichte aus anderen Deployments.

Was das für Plattformteams bedeutet

Für Teams, die Open-Weight-Modelle auf eigenen GPUs betreiben, bietet Kinference eine fertige Schicht für Routing, Nutzungserfassung und Policy-Steuerung auf Basis von vLLM. Die Benchmark-Werte stammen aus Buoyants eigenen Tests, in anderen Umgebungen können die Ergebnisse daher abweichen. Deshalb bittet das Unternehmen um Berichte aus anderen Deployments.