Llm-D 1.0 feiert Premiere auf der PyTorch Conference mit einem produktionsreifen Inferenz-Stack

Mitwirkende am Projekt llm-d kündigten am 20. Oktober 2026 auf der PyTorch Conference North America llm-d 1.0 an, einen Kubernetes-nativen, verteilten Inferenz-Serving-Stack, wie aus einer Ankündigung von IBM Research hervorgeht. IBM erklärte, die Veröffentlichung führe llm-d über den Nachweis einzelner Leistungstechniken hinaus und solle Unternehmen dabei helfen, die Bereitstellung von Modellen angesichts steigender Inferenzkosten selbst zu übernehmen.

llm-d wurde entwickelt, um Inferenz-Stacks für jedes Modell, auf jedem Beschleuniger und in jeder Cloud bereitzustellen. Red Hat, IBM und Google sind die federführenden Betreuer des Projekts und haben llm-d gemeinsam mit CoreWeave und NVIDIA gegründet; AMD, Cisco, Hugging Face, Intel, Lambda und Mistral AI sind als Mitwirkende hinzugekommen. Die Cloud Native Computing Foundation (CNCF) hostet llm-d als Sandbox-Projekt. IBM beschreibt das Ergebnis als herstellerneutrale Alternative für Unternehmen, die eine von IBM als Spitzenklasse bezeichnete Inferenzleistung erzielen möchten, ohne vollständig von einem proprietären Modellanbieter, einer Cloud oder einer Hardwareplattform abhängig zu sein.

Carlos Costa, Distinguished Engineer bei IBM Research sowie Mitgründer und federführender Betreuer von llm-d, sagte, Version 1.0 verleihe llm-d die nötige Reife, um den Stack wie jeden anderen geschäftskritischen Dienst zu betreiben. Als Beispiele nannte er eine stabile API, mehrere Mandanten mit konkurrierenden Prioritäten, die dieselbe Infrastruktur gemeinsam nutzen, und Aktualisierungen, die den Betrieb nicht unterbrechen.

Was Version 1.0 hinzufügt

Die am 20. Oktober 2026 auf GitHub veröffentlichten Versionshinweise zu v1.0.0, versehen mit signierten und verifizierten Tags, stellen die Dienstgüte im mandantenfähigen Betrieb in den Mittelpunkt: eine prioritäts- und fairnessbewusste Flusssteuerung mit kontrolliertem Lastabwurf, einschließlich eines probabilistischen Zulassungsmechanismus, programmbezogener Fairness und einer Prioritätsbewertung für einzelne Gesprächsrunden. So können latenzempfindliche Anfragen und stoßweise auftretende Agenten-Workloads eine Infrastruktur gemeinsam nutzen, ohne sich bei Überlastung gegenseitig Ressourcen zu entziehen. Die Konfiguration der Flusssteuerung wird in einem einzigen Feld namens flowControl zusammengeführt.

Für einen unterbrechungsfreien Betrieb erhält der Router Hochverfügbarkeit mit Hot-Standby und sicheren Rolling Updates. Ein DisaggregatedSet-Controller verwaltet Prefill- und Decode-Replikate als eine logische Einheit – mit koordinierten Rollouts, synchronisierten Aktualisierungen, einer Bereitschaftsprüfung auf Grundlage des Pod-Snapshots und nativem Revisions-Routing. Die Konfigurations-API des Routers wird auf Version 1 angehoben, die Responses API unterstützt previous_response_id, und der Anfragepfad des Endpunkt-Auswahldienstes wird im Hinblick auf Zuverlässigkeit, Leistung und Skalierbarkeit gehärtet. Außerdem ist eine topology-aware Anleitung für Beschleuniger mit DRA und DRANET enthalten.

Das agentenbewusste Serving umfasst ein Plugin zur Erzeugung des Sitzungszustands und eine dynamische Sitzungsaffinität, damit mehrteilige Unterhaltungen nahe an ihrem zwischengespeicherten Kontext bleiben. Die Prioritätsplanung für einzelne Gesprächsrunden und der Status der Responses API helfen Agenten dabei, den Kontext über mehrere Gesprächsrunden hinweg wiederzuverwenden. Mit der Veröffentlichung werden die Komponenten des Projekts auf Version v1.0.0 vereinheitlicht und zusätzliche Bestandteile des Ökosystems eingeführt, darunter eine Integration mit ai-dynamo/modelexpress zum Peer-to-Peer-Laden von Modellgewichten, das Paket llm-d-api-extensions und die Diagnosetools llm-d-pd-utils. Die eigenen Container-Image-Builds von llm-d-rocm werden eingestellt. Die Modellserver-Images umfassen Builds von vLLM und SGLang für verschiedene Beschleunigerziele. Für die Anleitung zur Disaggregation von Prefill und Decode ist nun LeaderWorkerSet v0.11.1 oder neuer erforderlich; außerdem muss die DisaggregatedSet-API aktiviert sein.

Kerntechniken und Flusssteuerung

Seit dem Start konzentriert sich das Projekt auf fünf Ansätze zur Verbesserung der Inferenz: Routing unter Berücksichtigung des Präfix-Caches, bei dem Anfragen an eine Infrastruktur weitergeleitet werden, die den gemeinsamen Kontext möglicherweise bereits enthält; das Auslagern des KV-Caches, bei dem zwischengespeicherte Informationen zwischen GPU, CPU und Speicherressourcen verschoben werden; die Optimierung der Batch-Inferenz; die Disaggregation von Prefill und Decode, bei der das Einlesen eines Prompts von der Generierung einer Antwort getrennt wird; und umfassende Expertenparallelisierung, bei der große Mixture-of-Experts-Modelle auf viele Beschleuniger verteilt werden. Diese Techniken gab es bereits vor Version 1.0. Neu sind laut IBM ihre Integration und die betriebliche Reife, einschließlich der Disziplin des Day-2-Betriebs: Die Leistung soll auch dann erhalten bleiben, wenn sich der Datenverkehr ändert, Hardware ausfällt, Software aktualisiert wird oder verschiedene Nutzer um dieselben Ressourcen konkurrieren.

In Version 1.0 sollen Flusssteuerung, Fairness und Priorisierung verhindern, dass stoßweise auftretende Workloads latenzempfindliche Dienste überlasten – unabhängig davon, ob die Workloads dieselbe Hardware nutzen oder sich über verschiedene Beschleuniger hinweg erstrecken. Anfragen können über mehrere Gesprächsrunden hinweg an die passende Infrastruktur gebunden bleiben, damit die Präfix-Caches warm bleiben. llm-d arbeitet mit Inferenz-Engines wie vLLM oder SGLang zusammen und ergänzt diese um verteiltes Routing und betriebliche Funktionen. Stephen Watt, Vizepräsident im Büro des Chief Technology Officer von Red Hat, sagte, llm-d vereine die Ökosysteme von PyTorch und CNCF, indem es Kubernetes-native Orchestrierung direkt in vLLM und moderne Inferenz-Engines einbringe.

Demonstrierte Ergebnisse und angegebene Kosten

In einem am 22. Juli 2026 veröffentlichten Benchmark-Beitrag maß das Projekt das Serving für agentische Anwendungen mit GLM-5.2, das dort als Mixture-of-Experts-Modell mit 744 Milliarden Parametern, 39 Milliarden aktiven Parametern und 78 Schichten beschrieben wird. Die Workload-Analyse stützte sich auf 219 Claude-Code-Sitzungen im Produktivbetrieb. Bei diesen umfasste eine Anfrage des Hauptagenten im Median 195.000 Eingabetokens und lieferte 317 Ausgabetokens; bei 96 % der Durchläufe des Hauptagenten wurden mindestens 90 % der Eingabe wiederverwendet. Dem Beitrag zufolge erfasste das präfixbewusste Routing 96–97 % der Cache-Wiederverwendung, die der Workload ermöglichte. Bei einem angenommenen Mietpreis für H200-GPUs von 2,71 $ pro GPU-Stunde beziffert der Beitrag die Kosten für selbst gehostetes Serving auf zwei Konfigurationen mit je 64 GPUs auf 0,05 bis 0,08 $ pro Million Eingabetokens und 1,92 bis 3,55 $ pro Million Ausgabetokens. Die Autoren geben an, dass diese Beträge ausschließlich die GPU-Miete abdecken und eine anhaltende Auslastung voraussetzen.

In einer separaten Demonstration setzten IBM und Red Hat GLM-5.2 auf 544 NVIDIA-H100-GPUs ein. In einem Bericht von IBM Research wird das Modell als Modell mit offenen Gewichten und etwa 753 Milliarden Parametern beschrieben, von denen ungefähr 39 Milliarden aktiv sind. IBM berichtet, dass die Bereitstellung in der Spitze mehr als 6,6 Millionen Ausgabetokens pro Minute lieferte und dabei bis zu 3.000 gleichzeitig aktive Coding-Agenten ohne Präemption bediente. Bei einer Auslastung mit 2.500 Agenten wurden dauerhaft 7.612 Anfragen pro Minute verarbeitet. IBM gibt an, dass das selbst gehostete GLM-5.2 auf H100-GPUs mit llm-d bei den aktuellen Cloud-Mietpreisen pro Token fünf- bis zehnmal weniger kostet als vergleichbare kommerzielle API-Angebote. „Tausende gleichzeitig aktive Agenten ohne Präemption zu bedienen, bietet Betreibern einen realistischen Weg vom Benchmark-Ergebnis zur Produktivbereitstellung“, sagte Maroon Ayoub, Senior Principal Engineer für maschinelles Lernen im Inference-Engineering-Team von Red Hat.

Der gleichen Darstellung zufolge führte die disaggregierte Datenebene im Hintergrund dieser Ergebnisse 6,2 Millionen KV-Cache-Übertragungen mit durchschnittlich 2,71 GiB pro Übertragung und ohne Übertragungsfehler durch. Alle Benchmarks wurden ohne Serving-Fehler abgeschlossen.