llm-d: KI-Inferenz wird Kubernetes-nativ

Wer große Sprachmodelle auf Kubernetes betreibt, kennt das Problem: Prompt-Verarbeitung (Prefill) und Token-Generierung (Decode) haben völlig unterschiedliche Rechenanforderungen, laufen aber auf derselben GPU. Das Ergebnis: GPUs sind schlecht ausgelastet, Latenz schwankt, und Skalierung ist ein Kompromiss.

Das Projekt llm-d löst dieses Problem, indem es Prefill und Decode in getrennte Kubernetes-Pods aufteilt, die unabhängig voneinander skalieren. Seit dem 24. März 2026 ist llm-d ein offizielles CNCF-Sandbox-Projekt.

Wie llm-d funktioniert

Bei einer klassischen LLM-Inferenz passiert alles in einem Prozess: Erst wird der gesamte Prompt verarbeitet (Prefill), dann werden Token für Token die Antwort generiert (Decode). Diese beiden Phasen haben grundlegend verschiedene Anforderungen:

Prefill ist rechenintensiv, braucht viele GPU-Kerne gleichzeitig und ist pro Anfrage schnell erledigt
Decode ist speicherintensiv, braucht weniger Rechenkraft pro Schritt, läuft aber über die gesamte Antwortlänge

llm-d trennt diese Phasen in eigene Pod-Pools mit jeweils eigenem Autoscaling. Ein intelligenter Scheduler routet Anfragen zuerst an den Prefill-Pool, dann an den Decode-Pool. Dazwischen wird der KV-Cache (der Zwischenspeicher für bereits verarbeitete Token) über einen Sidecar-Container transferiert. Quelle: CNCF Blog | The New Stack

Was das bringt

Durch die Trennung konkurrieren Prefill und Decode nicht mehr um dieselben GPU-Zyklen. Wenn 100 Anfragen gleichzeitig eintreffen, kann llm-d den Prefill parallel über den gesamten Prefill-Pool verteilen, statt wie bei klassischem vLLM eine Anfrage nach der anderen abzuarbeiten.

Konkrete Zahlen aus dem v0.5-Release: Bis zu 3.100 Token pro Sekunde pro B200-Decode-GPU und bis zu 50.000 Output-Token pro Sekunde auf einer 16x16-B200-Topologie. Die Zeit bis zum ersten Token (TTFT) sinkt laut Benchmarks um eine Größenordnung gegenüber Round-Robin-Loadbalancing. Quelle: GitHub llm-d

Wer dahinter steckt

llm-d wurde im Mai 2025 von IBM Research und Red Hat gestartet, mit Google Cloud, CoreWeave und NVIDIA als Co-Entwickler. Die Spende an die CNCF soll sicherstellen, dass das Projekt herstellerneutral bleibt.

Der Ansatz: "Any model, any accelerator, any cloud." llm-d ist nicht an einen bestimmten Modell-Anbieter oder eine GPU-Generation gebunden. Es baut auf vLLM als Inferenz-Engine auf und nutzt die Gateway API von Kubernetes für das Routing.

Für wen das interessant ist

llm-d richtet sich an Teams, die LLMs in Produktion betreiben oder planen:

Self-Hosted Inference: Wer Modelle wie Llama, Gemma oder Mistral auf eigener Infrastruktur betreibt und bessere GPU-Auslastung braucht
Multi-Tenant-Serving: Mehrere Teams oder Anwendungen teilen sich einen GPU-Cluster, llm-d bringt Fairness und Priorisierung mit
Kosten-Optimierung: Durch gezielte Skalierung von Prefill und Decode getrennt lässt sich GPU-Kapazität effizienter einsetzen als bei monolithischen Deployments
On-Premise/DSGVO: Für Teams im DACH-Raum, die Modelle lokal betreiben müssen und dafür möglichst viel Durchsatz aus vorhandener Hardware herausholen wollen

Wer heute bereits Kubernetes für andere Workloads nutzt und über lokale LLM-Inferenz nachdenkt, sollte llm-d als Referenzarchitektur im Blick behalten.