llm-d 1.0 wurde am 20. Oktober 2026 auf der PyTorch Conference North America offiziell vorgestellt, IBM Research kündigte die Version im eigenen Blog an. Das Kubernetes-native Projekt für verteilte Inferenz wird von Red Hat, IBM und Google federführend gepflegt; die drei hatten es 2025 gemeinsam mit CoreWeave und NVIDIA gegründet, AMD, Cisco, Hugging Face, Intel, Lambda und Mistral AI kamen später als Beitragende hinzu. Der Punkt von 1.0 ist kein schnellerer Benchmark, sondern der Schritt von Inferenz, die läuft, zu Inferenz, die sich dauerhaft betreiben lässt.
Ergänzt wurde der Betrieb, nicht eine weitere Leistungstechnik
Die fünf bekannten Techniken von llm-d — Routing mit Blick auf den Präfix-Cache, Auslagerung des KV-Cache, Optimierung der Batch-Inferenz, Trennung von Prefill und Decode sowie breite Expertenparallelität — bleiben in 1.0 unverändert. Neu ist die Betriebsschicht darüber: eine stabile API, Dienstgüte für mehrere Mandanten, Upgrades ohne Ausfallzeit und eine Flusssteuerung, die verhindert, dass sich Lasten mit unterschiedlichen Prioritäten auf geteilter Infrastruktur gegenseitig ausbremsen. Carlos Costa, Distinguished Engineer bei IBM Research und Mitgründer von llm-d, sagt es deutlich: 1.0 soll llm-d wie jeden anderen kritischen Dienst betreibbar machen, statt nur Demo-Werte zu liefern.
Ein Endpunkt, unterschiedliche Behandlung für Menschen und Agenten
Der Datenverkehr von Inferenzdiensten in Unternehmen verändert seine Form: Hinter einem einzigen Endpunkt warten Menschen auf die sofortige Antwort eines Programmierassistenten, während Agenten Anfragen in Schüben senden, für Werkzeugaufrufe pausieren und dann zurückkehren. Flusssteuerung und faire Verteilung in 1.0 entscheiden bei Spitzenlast ausdrücklich, wer zuerst Ressourcen bekommt, und halten mehrstufige Anfragen auf derselben Replik, damit Präfix-Caches warm bleiben. In IBMs Tests nutzte der präfixbewusste Router 97 Prozent der verfügbaren Cache-Wiederverwendung bei einer agentischen Programmierlast, und in einer selbst gehosteten Demonstration liefen 3.000 Software-Engineering-Agenten gleichzeitig zu einem Fünftel bis einem Zehntel der Kosten des vergleichbaren gehosteten Dienstes.
Eine herstellerneutrale Option für Teams mit eigener Inferenz
llm-d ersetzt Inferenz-Engines wie vLLM oder SGLang nicht, es setzt auf ihnen auf und ergänzt verteiltes Routing und Betriebsfunktionen; das Projekt läuft als Sandbox-Projekt der CNCF. Für Teams, die Modelle bereits auf eigenen Kubernetes-Clustern betreiben, senkt 1.0 die Hürde, aus offenen Modellgewichten einen Produktionsdienst zu machen, und macht steuerbar, wohin Rechenleistung fließt und wie viel Cache tatsächlich getroffen wird. Die Grenzen gehören dazu: Kubernetes-Betriebswissen bleibt Voraussetzung, und kleine Teams, denen die verwaltete Inferenz eines Cloud-Anbieters genügt, holen sich die Kosten des Eigenbetriebs nicht unbedingt zurück.
