Mit dem Wachstum von LLM-Produktions-Workloads wird deutlich: Die klassischen Mechanismen von Kubernetes verstehen die Natur von Inference nicht. llm-d ist ein Versuch, diese Lücke auf Plattformebene zu schließen.
Die wichtigste Einschränkung zeigt sich, wenn Inference über den Rahmen eines „stateless HTTP-Services“ hinausgeht. Anfragen an LLMs haben unterschiedliche Kosten: Prompt-Länge, Generierungsphase, Treffer im KV-Cache. In Kubernetes erscheinen all diese Anfragen als identisch. Das Ergebnis: Ungünstige Platzierung von Pods, Zerstörung der Cache-Lokalität und schwankende Latenz unter Last. Besonders deutlich wird dies in Multi-Tenant-Szenarien, wo die Effizienz vom Wiederverwenden des Kontexts abhängt. Die grundlegenden Mechanismen für Autoscaling und Service-Routing sind hier blind für den Zustand des Inference.
llm-d schlägt vor, verteiltes Inference als First-Class-Workload zu betrachten. Die Schlüsselidee ist, die Orchestrierungsebene (Kubernetes) mit der Semantik des Inference zu verbinden. Das Projekt integriert sich zwischen Control Plane (z. B. KServe) und Engines wie vLLM und fügt zustandsbewusstes Routing sowie Cache-Management hinzu. Der Trade-off ist offensichtlich: Die Plattform wird komplexer und es entsteht eine neue Abstraktionsebene, aber im Gegenzug erhält man Kontrolle über die wichtigsten Inference-Metriken und verzichtet auf „Black Boxes“ im Produktivbetrieb.
Die Umsetzung basiert auf mehreren Prinzipien. Erstens hierarchisches Management des KV-Caches mit der Möglichkeit zum Offload zwischen GPU, CPU und Storage – das ermöglicht einen Ausgleich zwischen Geschwindigkeit und Kosten. Zweitens Routing unter Berücksichtigung von Modell und Zustand: Die Anfrage wird dorthin geleitet, wo der benötigte Kontext oder die passende Hardware bereits vorhanden ist. Drittens disaggregiertes Serving – die Trennung von Rollen (z. B. Leader/Worker über LWS), was Skalierung und Ressourcenmanagement vereinfacht. Ein besonderer Fokus liegt auf einem hardware-agnostischen Ansatz: Das System soll mit NVIDIA, AMD, TPU und anderen Beschleunigern gleichermaßen funktionieren. Das reduziert Vendor Lock-in, erfordert aber eine sorgfältige Abstraktion der Unterschiede bei Performance und Speicher.
Praktische Ergebnisse zeigen, wo genau der Vorteil entsteht. Im Multi-Tenant-SaaS-Szenario mit Prefix-Caching hält llm-d nahezu null Time To First Token auch bei steigender Last, während ein Standard-Kubernetes-Service schnell degradiert. Der Durchsatz erreicht etwa 120.000 Tokens pro Sekunde im Cluster (8×vLLM, 16×H100), wobei die Latenz vorhersagbar bleibt. Wichtig ist: Das Projekt setzt auf reproduzierbare Benchmarks statt auf Marketingzahlen, was in der AI-Infrastruktur bislang selten ist.
Die Aufnahme von llm-d in die CNCF Sandbox ist weniger ein Statussymbol als vielmehr der Versuch, eine bislang fehlende Schicht zu standardisieren: zustandsbewusste Orchestrierung von Inference. Sollte sich der Ansatz durchsetzen, wird Kubernetes LLM-Workloads nicht mehr als Ausnahme, sondern als Normalfall betrachten.