NVIDIA Dynamo and LLM-D Assess
Überblick
NVIDIA Dynamo und LLM-D fokussieren disaggregierte, hochskalige LLM-Inference über GPU-Fleets mit KV-Cache-Optimierung (NVIDIA Dynamo). Dynamo ist NVIDIAs Open-Source-Framework für verteilte Inference oberhalb von Engines wie vLLM, SGLang und TensorRT-LLM (Dynamo GitHub); llm-d ist ein Kubernetes-nativer Stack für verteilte Inference, gegründet von Red Hat, Google Cloud, IBM Research, CoreWeave und NVIDIA und seit März 2026 in der CNCF Sandbox (CNCF). Beide schließen sich nicht strikt aus: NVIDIAs Ankündigung von Dynamo 1.0 nennt llm-d unter den Open-Source-Frameworks, die Dynamo-Komponenten integrieren (NVIDIA Pressemitteilung).
Assess für Hyperscale Self-Hosted Inference. Braucht tiefes GPU Platform Engineering; kein Ersatz für Application-Level Agent Design.
Adoptionssignale
- NVIDIA hat Dynamo 1.0 am 16. März 2026 als Produktionssoftware angekündigt und nennt die Integration durch AWS, Microsoft Azure, Google Cloud und OCI sowie die Adoption durch Unternehmen wie Cursor, Perplexity, PayPal und Pinterest (NVIDIA Pressemitteilung).
- NVIDIAs Technical Blog listet unter anderem Produktions-Deployments bei AstraZeneca, Baseten, ByteDance, CoreWeave, DigitalOcean, SoftBank Corp. und Together AI (NVIDIA Technical Blog).
- llm-d wurde am 24. März 2026 als CNCF-Sandbox-Projekt aufgenommen, neben den Gründern unterstützt von AMD, Cisco, Hugging Face, Intel, Lambda und Mistral AI; der CNCF-Beitrag nennt rund 120.000 Tokens/s auf Qwen3-32B mit 8 vLLM-Pods auf 16 H100-GPUs (CNCF).
- Red Hat hat llm-d im Oktober 2025 mit Red Hat OpenShift AI 3.0 allgemein verfügbar gemacht und damit eine supportete Distribution für regulierte Unternehmen geschaffen (Red Hat Pressemitteilung).
- Aktive Release-Züge Stand 30. September 2026: Dynamo v1.5.0 (21. September 2026, rund 8.200 GitHub-Stars) und llm-d v0.10.0 (29. September 2026, rund 4.700 Stars), das llm-d auf vLLM v0.30.0 hebt (Dynamo Releases, llm-d Releases).
Risiken
- Benchmark-Bedingungen passen selten zur eigenen Umgebung. Das Dynamo-Ergebnis von bis zu 7x bezieht sich auf DeepSeek R1 in FP4 auf GB200 NVL72 im SemiAnalysis-InferenceX-Benchmark (NVIDIA Technical Blog); auf wenigen H100- oder L40S-Nodes mit mittelgroßen Modellen fallen die Gewinne kleiner aus und müssen gemessen werden.
- Hardware-Kopplung. Dokumentation und Optimierungen von Dynamo konzentrieren sich auf NVIDIA Hopper und Blackwell (Dynamo GitHub); wer AMD- oder TPU-Optionen offenhalten will, behält mit llm-d mehr Spielraum, da es ausdrücklich mehrere Beschleuniger-Hersteller adressiert (CNCF).
- Größerer Blast Radius im Cluster. Disaggregierte Pods tauschen KV Cache und Requests über das interne Netz aus; das vLLM-SSRF-Advisory CVE-2026-24779 nennt ausdrücklich llm-d-artige Deployments, in denen ein kompromittierter Pod andere Pods erreichen kann (OSV).
- Bewegliche Schnittstellen. llm-d v0.10.0 hat Repositories umbenannt und zusammengelegt und eigene Container-Images zugunsten der Upstream-vLLM-Images als deprecated markiert (llm-d v0.10.0); Helm-Values, Image-Referenzen und Routing-Konfiguration müssen über Releases hinweg nachgezogen werden.
Vorteile & Nachteile
Vorteile
- Beide Projekte haben produktionsreife Releases: NVIDIA hat Dynamo 1.0 im März 2026 für produktionsreif erklärt, Red Hat liefert llm-d seit OpenShift AI 3.0 (Oktober 2025) als generally available aus, und llm-d ist seit März 2026 CNCF-Sandbox-Projekt.
- Sie ergänzen, was einem einzelnen vLLM-Deployment im großen Maßstab fehlt: KV-Cache- und Prefix-Cache-bewusstes Routing, getrennte Prefill- und Decode-Pools, Auslagerung des KV Cache auf CPU- und Storage-Tiers sowie SLA-gesteuertes Autoscaling.
- Beide sind Apache-2.0-Open-Source und bis zu einem gewissen Grad engine-unabhängig: Dynamo betreibt vLLM-, SGLang- und TensorRT-LLM-Backends, llm-d baut auf der Kubernetes Gateway API Inference Extension auf und adressiert Beschleuniger von NVIDIA, AMD und Google.
Nachteile
- Die Spitzenwerte stammen von Rack-Scale-Hardware: NVIDIAs Faktor von bis zu 7 wurde auf GB200 NVL72 mit Wide Expert Parallelism für DeepSeek R1 gemessen, einem Setup, das die meisten GPU-Umgebungen im europäischen Mittelstand nicht haben.
- Der Betriebsaufwand ist hoch: Disaggregated Serving, KV-Transfer zwischen Pods, Gang Scheduling und inference-bewusste Gateways bringen zusätzliche Komponenten und Failure Modes, die eigene GPU-Platform-Engineers erfordern.
- Beide entwickeln sich schnell: Dynamo hat im September 2026 v1.5.0 veröffentlicht, llm-d v0.10.0 hat eigene CUDA- und AWS-Images sowie eine Latency-Predictor-Komponente als deprecated markiert. Konfigurationen veralten entsprechend rasch.
Empfehlung
Dynamo und llm-d nur dann im Assess bewerten, wenn vLLM oder SGLang bereits auf einem Multi-Node-GPU-Cluster produktiv laufen und ein gemessenes Problem vorliegt, das diese Projekte adressieren: schlechte Prefix-Cache-Trefferquoten unter Last, lange Prompts, bei denen Prefill und Decode um Ressourcen konkurrieren, oder eine GPU-Auslastung, die die Flotte nicht rechtfertigt. Die Evaluation sollte mit eigenen Modellen, der eigenen Verteilung der Prompt-Längen und den eigenen GPU-Typen laufen und gegen eine getunte Single-Engine-Baseline mit einfachem Load Balancer vergleichen, nicht gegen Standardeinstellungen.
Für Kubernetes-zentrierte Umgebungen mit mehreren Hardware-Herstellern und für Teams auf OpenShift ist llm-d der naheliegende Startpunkt; für reine NVIDIA-Cluster mit Blackwell-Hardware lohnt ein paralleler Test von Dynamo. Für Teams, die wenige Modelle auf ein oder zwei Nodes betreiben, passt keines der beiden, und keines ersetzt AI Gateway, Evaluation oder Guardrails auf Anwendungsebene. Network Policies zwischen Serving-Pods sollten strikt bleiben, und die Security Advisories beider Projekte gehören neben denen von vLLM ins Monitoring.
Quellen
Beratung
Vom Radar zur Umsetzung
Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.
