KubeAI: Inferenz-Operator mit eigenem Proxy statt Istio und Knative

Welche Lücke der Operator schließt

Ein Kubernetes-Service vor mehreren vLLM-Replicas verteilt Anfragen zufällig. Das ist für zustandslose Dienste richtig und für Inferenz falsch. Das README begründet das damit, dass vLLM nicht zustandslos ist, weil seine Leistung stark vom Zustand des KV-Cache abhängt. Trifft eine Folgeanfrage einen Replica, der den passenden Prefix nicht im Cache hat, muss der Prompt neu verarbeitet werden. KubeAI setzt an dieser Stelle an: Der mitgelieferte Proxy implementiert eine prefix-bewusste Lastverteilung, die auf die KV-Cache-Auslastung der Backends optimiert. Das Projekt verweist dazu auf ein eigenes Paper im Verzeichnis blog/posts/llm-load-balancing-at-scale-chwbl.md und auf ein Benchmark-Bild zu TTFT. Wer diese Zahlen prüfen will, muss sie im Repository nachlesen, denn sie sind nicht Teil der Projektdokumentation im engeren Sinn.

Die Zielgruppe sind Plattformteams, die Modelle im eigenen Cluster betreiben und die Modellverwaltung nicht in ein separates Serving-Framework auslagern wollen. Der Operator kennt vier Aufgabentypen: Textgenerierung über vLLM und Ollama, Transkription über FasterWhisper, Embeddings über Infinity und Reranking über Cross-Encoder-Modelle. Das ist ein klar umrissener Zuschnitt. Wer fein abgestimmte Klassifikatoren, Objekterkennung oder eigene Torch-Skripte ausrollen will, findet hier keine Antwort.

Proxy und Operator: zwei Rollen, ein Deployment

KubeAI besteht laut README aus zwei Teilen. Der Model Proxy stellt die OpenAI-kompatible API bereit und sitzt vor den Backends. Er macht drei Dinge: prefix-bewusstes Load-Balancing, Request-Queueing während des Scale-from-Zero und Retries auf fehlerhafte Backends. Der Model Operator verwaltet die Backend-Pods direkt. Er lädt Modelle herunter, bindet Volumes ein und lädt LoRA-Adapter über das Model-CRD. Beide Komponenten laufen im selben Deployment, lassen sich laut einem verlinkten Issue aber getrennt betreiben.

Bemerkenswert ist, was der Proxy nicht braucht. Für Scale-from-Zero wird kein Knative vorausgesetzt, für Autoscaling kein Prometheus-Metrics-Adapter, für Traffic-Routing kein Istio. Das ist eine bewusste Reduktion der Abhängigkeiten, und sie hat einen Preis: Wer bereits ein Service Mesh mit eigenem Routing, mTLS und Observability betreibt, bekommt hier einen zweiten Pfad, der an diesem Mesh vorbeiführt. Die Entscheidung für Null-Abhängigkeiten ist also nicht kostenlos, sie verschiebt Verantwortung in den Operator. Die Request-Queueing-Funktion ist ebenfalls ein zweischneidiges Detail: Sie hält Anfragen, während von null Replicas hochskaliert wird. Das README nennt keine Obergrenze für Wartezeit oder Queue-Tiefe, und ohne diese Angabe bleibt offen, wie sich ein überlasteter Proxy gegenüber Clients verhält.

Installation: Helm, kind und ein Modellkatalog als YAML

Der Quickstart ist knapp. Zuerst wird ein lokaler Cluster erstellt:

kind create cluster

Danach folgt das Helm-Repository:

helm repo add kubeai https://www.kubeai.org helm repo update helm install kubeai kubeai/kubeai --wait --timeout 10m

Modelle kommen aus einem zweiten Chart, kubeai/models, das mit einer eigenen Werte-Datei überschrieben wird. Das README zeigt dafür kubeai-models.yaml mit einem Abschnitt catalog. Jeder Eintrag hat die Felder enabled, features, url, engine, minReplicas und resourceProfile. Das Beispiel aktiviert deepseek-r1-1.5b-cpu mit url ollama://deepseek-r1:1.5b, engine OLlama und resourceProfile cpu:1. Zwei weitere Einträge, qwen2-500m-cpu und nomic-embed-text-cpu, werden nur über enabled: true eingeschaltet, weil ihre übrige Konfiguration im Katalog bereits hinterlegt ist.

Das ist der eigentliche Komfortgewinn: Der Katalog enthält populäre Modelle, vorkonfiguriert für gängige GPU-Typen. Man muss die vLLM-Flags nicht selbst zusammenstellen. Die Kehrseite ist die Kopplung an diesen Katalog. Wenn ein Modell dort fehlt oder eine andere Quantisierung gewünscht ist, muss der Eintrag von Hand geschrieben werden, und die Feldnamen sind Teil der Operator-API. Das README dokumentiert den vollständigen Satz möglicher Felder nicht, es zeigt nur das Beispiel. Wer mehr als die genannten Schlüssel setzen will, ist auf die CRD-Definition im Repository angewiesen.

Was der Proxy an der OpenAI-API nachbildet

KubeAI bedient sieben Endpunkte: /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/rerank, /v1/models und /v1/audio/transcriptions. Das ist die Schnittmenge aus Textgenerierung, Embeddings, Reranking und Transkription, also genau die vier Aufgabentypen, die das Projekt nennt. Bestehende Client-Bibliotheken müssen nicht angepasst werden, solange sie sich auf diese Pfade beschränken.

Die Einschränkung liegt auf der Hand und wird im README nicht ausgeführt: Was nicht in dieser Liste steht, fehlt. Es gibt keinen Endpunkt für Bilder, kein /v1/images/generations, und die Beschreibung erwähnt VLMs in der Kurzbeschreibung, listet aber keinen multimodalen Endpunkt auf. Wer visuelle Modelle über KubeAI anbinden will, muss klären, ob das über /v1/chat/completions mit Bildinhalten läuft oder nicht. Das Material gibt darüber keine Auskunft. Ähnlich verhält es sich mit Streaming, Tool-Calling und Structured Output: Diese Details sind Teil der OpenAI-Kompatibilität, aber das README nennt sie nicht. Man sollte sie nicht als zugesichert betrachten, nur weil der Pfadname gleich ist.

Hardware, Engines und die Grenzen der Abstraktion

KubeAI läuft laut README auf CPU, GPU oder TPU. Die Engine-Auswahl erfolgt pro Modelleintrag über das Feld engine, im Beispiel OLlama. Die Themenliste des Repositories nennt vllm, ollama, faster-whisper und whisper als zugehörige Stichworte. Damit ist der Kreis der Backends im Wesentlichen umrissen: vLLM und Ollama für Text, FasterWhisper für Sprache, Infinity für Embeddings.

Das ist eine Abstraktion mit einer klaren Bruchstelle. Jede Engine hat eigene Flags, eigene Speicheranforderungen und eigene Grenzen bei Kontextlänge oder Parallelität. Der Operator versteckt diese Unterschiede hinter dem Katalog, aber er hebt sie nicht auf. Ein Modell, das auf einer A100 mit einem bestimmten Tensor-Parallelismus läuft, wird auf einer kleineren Karte andere Einstellungen brauchen, und ob der Katalog dafür Varianten bereitstellt, sagt das README nicht. Die Formulierung, man plane eine Modelloptimierungs-Pipeline, deutet an, dass dieser Teil noch nicht ausgebaut ist. Für den Einstieg reicht der Katalog, für Sonderfälle wird man an den Engine-Flags selbst arbeiten müssen. Wer heute schon heterogene Hardware mit unterschiedlichen Quantisierungen betreibt, sollte den Katalog vor der Entscheidung durchsehen statt sich auf die Beschreibung zu verlassen.

Wo KubeAI das falsche Werkzeug ist

Der Operator verwaltet Backend-Pods direkt, mit einem Model-CRD pro Modell. Das ist eine Eins-zu-eins-Beziehung zwischen Modellobjekt und Pod-Gruppe. Für eine Plattform mit vielen kleinen Modellen und wechselnden Mandanten bedeutet das viele Objekte und viele Pod-Gruppen, jede mit eigener Skalierung. Ob der Proxy Mandantengrenzen kennt, geht aus dem Material nicht hervor, und die genannten Adopter (Arcee mit multi-tenant SLM inference, Telescope mit Multi-Region-Batch-Inferenz) zeigen nur, dass solche Setups existieren, nicht wie sie konfiguriert sind.

Ein zweiter Fall: Wer bereits KServe oder ein vergleichbares Serving-Framework mit eigener Routing-Schicht betreibt, würde mit KubeAI eine zweite Zuständigkeit für dasselbe Problem einführen. Der prefix-bewusste Lastverteiler ist nur dann ein Gewinn, wenn er auch der Pfad ist, über den der Verkehr läuft. Hinter einem bestehenden Gateway verliert er seinen Zweck, weil die Verteilung dann woanders entschieden wird. Und wer Modelle außerhalb der vier genannten Engines betreibt, also eigene Triton-Konfigurationen oder selbstgebaute TorchServe-Handler, findet hier keine Anknüpfung. KubeAI ist kein generischer Serving-Layer, sondern eine Sammlung von Engine-Adaptern mit gemeinsamer API.

Alternative: KServe mit Knative und Istio

Der naheliegende Vergleich ist KServe, das Inferenz ebenfalls über Kubernetes-CRDs abbildet. Der Unterschied liegt weniger im Funktionsumfang als im Abhängigkeitsmodell. KServe stützt sich für Scale-from-Zero auf Knative und für Traffic-Management auf Istio. KubeAI lehnt genau das ab und begründet es mit Day-two-Betrieb: keine Versions- und Konfigurationskonflikte zwischen Projekten. Wer Knative und Istio ohnehin betreibt, für den ist das kein Argument, sondern eine Doppelung. Wer sie nicht betreibt, spart mit KubeAI zwei Kontrollebenen ein, muss aber auf deren Fähigkeiten verzichten, etwa auf die feinere Traffic-Aufteilung und die Observability, die ein Mesh mitbringt.

Der zweite Unterschied ist das Routing-Ziel. KServe verteilt über die Standard-Service-Mechanik von Kubernetes. KubeAI baut einen eigenen Proxy davor, der den KV-Cache-Zustand der Backends berücksichtigt. Das ist der eigentliche Grund, sich für KubeAI zu entscheiden, und gleichzeitig der Grund, es nicht leichtfertig zu tun: Ein eigener Proxy im Datenpfad ist eine Komponente mehr, die ausfallen kann, und die Queueing-Logik während des Scale-from-Zero ist ein Verhalten, das man testen muss, bevor man es Produktionsverkehr aussetzt.

Lizenz, Wartung und was vor dem Einsatz zu prüfen ist

KubeAI steht unter Apache-2.0. Das ist eine permissive Lizenz mit Patentgewährung und ohne Copyleft-Pflichten für abgeleitete Werke. Wer den Operator in ein eigenes Produkt einbettet oder modifiziert, muss die Lizenzbedingungen und die Namensrechte beachten, insbesondere die Hinweise im NOTICE-File, falls eines vorhanden ist. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Lizenzpflichten bei Weitergabe greifen.

Die Release-Historie zeigt ein aktives Projekt. Die Helm-Charts helm-chart-kubeai-0.23.4 und helm-chart-models-0.23.4 stammen vom 30. Juli 2026, die Version v0.23.3 vom 20. Juli 2026, der letzte Push auf main vom 3. September 2026. Chart und Anwendung werden getrennt versioniert, was beim Upgrade bedeutet, dass man beide Versionsnummern im Blick behalten muss. Der Upgrade-Pfad für CRDs ist im Material nicht beschrieben. Bei einem Operator mit eigenem Model-CRD ist das der kritische Punkt, denn CRD-Änderungen lassen sich nicht ohne Weiteres zurückrollen.

Vor dem Produktiveinsatz würde ich drei Dinge konkret prüfen. Erstens, ob der Katalog die eigenen Modelle und GPU-Typen abdeckt, notfalls durch einen eigenen catalog-Eintrag mit passenden Werten für url, engine und resourceProfile. Zweitens, wie sich der Proxy unter Last verhält, wenn die Queue während des Scale-from-Zero vollläuft, denn dazu nennt das README keine Grenze. Drittens, ob die sieben OpenAI-Endpunkte die benötigten Parameter abdecken, insbesondere Streaming und multimodale Eingaben, die in der Kurzbeschreibung als VLM-Unterstützung anklingen, in der Endpunktliste aber nicht auftauchen.

Redaktionelles Fazit

KubeAI passt zu Teams, die vLLM oder Ollama auf einem eigenen Cluster betreiben und dabei weder Istio noch Knative noch den Prometheus-Adapter einführen wollen. Wer pro Modell eigene Scheduling-Logik braucht, ein Multi-Tenant-Modell mit harten Isolationsgrenzen oder Backends außerhalb der unterstützten Engines, sollte zuerst prüfen, ob der Operator diese Fälle abbildet. Vor dem Produktiveinsatz ist der prefix-bewusste Lastverteiler gegen die eigene Anfrageverteilung zu messen, denn genau dort liegt der Unterschied zu einem gewöhnlichen Kubernetes-Service.

Offizielle Quellen

1. kubeai-project/kubeai on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases