llm-d: Orchestrierungsschicht für LLM-Inferenz auf Kubernetes

Was llm-d zwischen Modellserver und Kubernetes setzt

vLLM und SGLang führen ein Modell auf einem Accelerator aus. Sie treffen aber keine Entscheidungen darüber, welcher Knoten eine Anfrage bekommt, wie der KV-Cache über mehrere Replikate hinweg wiederverwendet wird oder wann eine zusätzliche Replikation gestartet werden muss. Genau diese Lücke beschreibt das Repository als Aufgabe von llm-d: eine Orchestrierungsschicht oberhalb der Modellserver, die laut README auf hohe reale Last ausgelegt ist. Die Zielgruppe sind Betriebsteams, die LLM-Inferenz auf Kubernetes ausliefern und dabei mehrere Acceleratoren und Infrastrukturanbieter abdecken müssen. Das Projekt wird von Red Hat, Google Cloud, IBM Research, CoreWeave und NVIDIA gegründet und ist als CNCF-Sandbox-Projekt registriert. Wer heute eine einzelne Modellinstanz hinter einem LoadBalancer betreibt, bekommt durch llm-d nichts, was nicht schon der Modellserver selbst leistet.

Vier Mechanismen, die die README unterscheidet

Die angebotenen Funktionen sind in vier Themen gruppiert. Intelligent Routing verteilt Anfragen prefix-cache-bewusst und lastabhängig, ergänzt um einen als experimentell bezeichneten Scheduler auf Basis vorhergesagter Latenz. Advanced KV-Cache Management verlagert KV-Cache-Einträge stufenweise auf CPU oder Disk und indiziert den Cache-Zustand global, damit mehrteilige Konversationen auf mehr Replikate zugreifen können. Serving Large Models adressiert sehr große Modelle über Prefill/Decode-Disaggregation und Wide Expert-Parallelism über schnelle Accelerator-Interconnects, genannt werden DeepSeek-R1 und GPT-OSS. Operational Excellence umfasst Flow Control für Mandantentrennung und SLO-basiertes Autoscaling auf Basis von Inferenzsignalen. Dazu kommt Batch Processing mit OpenAI-kompatiblen Batch-APIs für Offline-Last. Das sind vier getrennte Baustellen, nicht vier Varianten derselben Sache. Wer einsteigt, wählt eine davon, nicht alle.

Well-lit paths statt allgemeiner Anleitung

Die Dokumentation ist um sogenannte well-lit paths organisiert. Jeder Pfad ist laut README ein gebenchmarktes Recipe mit Helm-Charts, das einen konkreten Aufbau beschreibt, etwa Optimized Baseline, Tiered Prefix Cache oder Wide Expert Parallelism. Der Einstieg läuft über einen Quickstart, der den Stack aufsetzt, den Router konfiguriert und die Ergebnisse mit Benchmarks validiert. Die README empfiehlt für die meisten Nutzer den Pfad Optimized Baseline als Ausgangspunkt. Der Release-Hinweis zu v0.7 nennt eine Migration der Guides auf Kustomize, erweiterte nächtliche CI-Läufe auf OpenShift, GKE und CoreWeave sowie einen Batch-Gateway im experimentellen Status. Diese Struktur ist die eigentliche Stärke des Projekts: Man übernimmt eine bekannte Konfiguration statt selbst Router-Regeln und Cache-Topologie zu entwerfen. Der Preis ist Bindung an die im Recipe getroffenen Annahmen.

Die Leistungszahlen stammen aus Partner-Benchmarks

Die README listet mehrere Ergebnisse auf, jeweils mit Quelle. Prefix-cache-bewusstes Routing gegenüber Round-Robin ergab den Angaben zufolge dreifachen Output-Durchsatz und halbierte Time to First Token bei Llama 3.1 70B auf vier AMD MI300X, gemessen von Tesla und Red Hat. Predicted-Latency-Scheduling reduzierte TTFT und Inter-Token-Latenz um 40 Prozent gegenüber Heuristiken auf NVIDIA-GPUs, veröffentlicht von Google. Für Prefill/Decode-Disaggregation nennt AWS bis zu 70 Prozent mehr Tokens pro Sekunde gegenüber Standard-vLLM bei GPT-OSS auf NVIDIA B200, Oracle 10 bis 30 Prozent Durchsatzgewinn auf identischer Infrastruktur. Wide Expert-Parallelism erreichte 50k Tokens pro Sekunde auf 16×16 NVIDIA B200, rund 3,1k Tokens pro Sekunde und GPU. Hierarchisches KV-Offloading ergab bei 250 gleichzeitigen Nutzern auf vier NVIDIA H100 den Faktor 13,9 gegenüber reiner GPU-Nutzung. Das sind Fremdmessungen auf fremder Hardware. Keine dieser Zahlen lässt sich ohne identischen Aufbau auf die eigene Umgebung übertragen.

Wann llm-d die falsche Wahl ist

Die README macht eine Einschränkung selbst sichtbar: Der Scheduler auf Basis vorhergesagter Latenz trägt in der Funktionsbeschreibung das Etikett experimentell, ebenso der Batch-Gateway in den Release-Hinweisen zu v0.7. Wer diese beiden Bausteine als Grundlage einer Produktionszusage einplant, plant gegen einen instabilen Teil des Projekts. Ein zweiter Punkt betrifft die Hardware. Die genannten Ergebnisse stammen von MI300X, B200 und H100. Für Acceleratoren außerhalb der dokumentierten Kombinationen sagt das Material nichts darüber aus, ob ein passendes Recipe existiert. Wer eine einzelne Modellinstanz ohne Mandantentrennung, ohne mehrteilige Konversationen und ohne Autoscaling-Bedarf betreibt, zahlt mit llm-d für Routing, Cache-Index und Flow Control, die nichts beitragen. In diesem Fall ist der Modellserver direkt die einfachere und günstigere Wahl.

Der Vergleich mit KServe und KServe LLMInferenceService

KServe ist die naheliegende Alternative, weil llm-d in einem gemeinsamen Blogbeitrag mit KServe und vLLM beschrieben wird und die Prefix-Cache-Zahlen aus diesem Aufbau stammen. Der Unterschied liegt in der Zuständigkeit. KServe liefert das Serving-Framework auf Kubernetes: Modell-Deployment, Skalierung, InferenceService als Schnittstelle. llm-d setzt darüber an und kümmert sich um die Fragen innerhalb einer laufenden Auslieferung, also darum, welches Replikat eine Anfrage mit passendem Prefix-Cache bekommt, wie Cache-Stufen zwischen GPU, CPU und Disk verteilt werden und wann Flow Control greift. Beide Ansätze schließen sich nicht aus, sie überlappen aber bei Autoscaling und Routing. Wer bereits KServe betreibt, muss klären, welche der beiden Schichten die Skalierungsentscheidung trifft, bevor er llm-d ergänzt. Für reine Online-Inferenz mit einem Modell und wenigen Replikaten bleibt KServe ohne llm-d ausreichend.

Versionen, Wartung und Lizenz

Der Versionszyklus ist eng: v0.8.0 und v0.8.1 erschienen im Juni 2026, v0.9.0 im August 2026. Zwischen v0.5 und v0.7 nennt die README jeweils strukturelle Änderungen, darunter umbenannte und stabilisierte Pfade, eine Migration der Guides auf Kustomize sowie neue nächtliche CI-Ziele. Solche Umbenennungen und Migrationsschritte sind der eigentliche Wartungsposten, nicht die Releases selbst: Wer eigene Manifeste von den Recipes abgeleitet hat, muss sie bei jeder strukturellen Änderung nachziehen. Das Repository ist überwiegend in Shell gehalten, die Integrationsarbeit liegt entsprechend in Skripten und Helm-Werten. Die Lizenz ist Apache-2.0, was die Nutzung und Weitergabe auch in kommerziellen Umgebungen erlaubt, sofern die Lizenzbedingungen eingehalten werden. Das ist eine Einordnung, keine Rechtsberatung; die Bedingungen im LICENSE file sind maßgeblich. Ein Hinweis zur Reife: Das Projekt ist CNCF-Sandbox, nicht graduiert. Ein Sandbox-Status sagt nichts über Produktionstauglichkeit im Einzelfall, aber er markiert eine frühe Phase der Governance.

Redaktionelles Fazit

llm-d lohnt sich für Teams, die bereits Kubernetes betreiben und LLM-Inferenz auf mehreren Acceleratoren mit mehreren Modellreplikaten ausliefern. Wer eine einzelne Modellinstanz ohne Cluster aufsetzt, greift besser direkt zu vLLM oder SGLang. Vor dem Einstieg sollte man zuerst prüfen, ob für die eigene Accelerator-Kombination ein Recipe unter den well-lit paths existiert und ob der Standardpfad Optimized Baseline die eigene Last abdeckt. Fehlt beides, bedeutet llm-d zuerst Integrationsarbeit am eigenen Stack, nicht schnellere Inferenz.

Offizielle Quellen

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