NVIDIA Dynamo und disaggregiertes Serving: wann sich die Trennung von Prefill und Decode über mehrere Server lohnt

NVIDIA Dynamo und disaggregiertes Serving: Zweck und wann es sich lohnt

Disaggregiertes Serving führt die beiden Phasen einer LLM-Anfrage auf getrennten GPUs aus: Prefill-Worker verarbeiten den Prompt und bauen seinen KV-Cache auf, Decode-Worker erzeugen die Antwort, und der Cache wandert bei jeder Anfrage von den einen zu den anderen. NVIDIA Dynamo und llm-d sind Open-Source-Frameworks, die diese Trennung und dazu ein Routing nach KV-Cache-Treffern vor vLLM, SGLang oder TensorRT-LLM setzen. In großem Maßstab erlaubt die Trennung jedem Pool eine eigene Parallelisierung und verhindert, dass lange Prompts laufende Antworten aufhalten.

Bei zwei bis vier Servern hängt der Gewinn von den Prompt-Längen, der Wiederverwendung des Caches und dem Verkehr ab. Die Dokumentation von vLLM zum disaggregierten Prefill, datiert auf den 3. Oktober 2026, hält fest: „Disaggregiertes Prefill verbessert den Durchsatz NICHT.“ Die Dokumentation von Dynamo ergänzt: „Bei wenigen gleichzeitigen Anfragen vermeidet ein aggregierter Worker oft den Overhead von Transfer und Pool-Fragmentierung.“ KV-Cache-bewusstes Routing hilft dagegen immer dann, wenn mehrere Kopien eines Modells wiederholte Präfixe sehen, und es braucht kein besonderes Netzwerk.

Warum Prefill und Decode getrennt werden

Das Prefill berechnet den gesamten Prompt in einem Durchgang und ist durch die Rechenleistung begrenzt; das Decode erzeugt je Schritt ein Token für jede Anfrage im Batch und ist durch die Speicherbandbreite begrenzt. Unser Leitfaden zu Latenzzielen für LLMs zeigt, wie das Prefill die Zeit bis zum ersten Token (TTFT) bestimmt und das Decode die Inter-Token-Latenz (ITL). Die Dokumentation von Dynamo beschreibt die beiden Phasen als Phasen mit „unterschiedlichen Recheneigenschaften und unterschiedlichem Speicherbedarf“.

Auf einer gemeinsam genutzten GPU konkurriert ein langer Prompt mit den Decode-Schritten aller anderen Anfragen. Die Architekturdokumentation von llm-d formuliert es so: „Bei Anfragen mit langem Kontext können Prefills die Verarbeitung bestehender Anfragen in der Decode-Phase verlangsamen.“ Getrennte Pools erlauben auch unterschiedliche Aufteilungen, „mit einem größeren TP für die speichergebundene Decode-Phase und einem kleineren TP für die rechengebundene Prefill-Phase“. vLLM nennt zwei Gründe für die Funktion: „Getrenntes Tuning der Time to First Token (TTFT) und der Inter-Token-Latenz (ITL)“ und „Kontrolle der Tail-ITL“.

Formalisiert wurde die Idee im DistServe-Paper auf arXiv (erste Version Januar 2024), das den Goodput misst, die Anfragerate je GPU, die sowohl die TTFT-Grenze als auch die Grenze je Token einhält. Seine Zusammenfassung berichtet, dass DistServe „7,4x mehr Anfragen oder ein 12,6x strengeres SLO bedienen kann“ als die verglichenen Systeme. vLLM kennzeichnet seine eigene Funktion als experimentell, und eine einzige vLLM-Instanz mildert den Konflikt bereits mit Chunked Prefill, das Prompt-Abschnitte mit Decode-Schritten mischt.

NVIDIA Dynamo und llm-d: die Komponenten

Dokumentation von NVIDIA Dynamo (als latest markiert, v1.5.1) und GitHub-Repository, Dokumentation von llm-d (als v0.10, latest markiert) und NIXL-Repository, gelesen am 10. Oktober 2026.

NVIDIA nennt Dynamo „ein Open-Source-Inferenz-Framework für das Serving generativer KI“. Es steht unter Apache 2.0 und ist, in den Worten seines Repositorys, „in Rust gebaut für Performance, in Python für Erweiterbarkeit“. Seine Kompatibilitätsseite, gelesen am 10. Oktober 2026, nennt Release 1.5.1 vom 6. Oktober 2026, einen Patch zu 1.5.0 vom 18. September, mit vLLM 0.28.0, SGLang 0.5.18 und TensorRT-LLM 1.3.0rc25. Sie nennt CUDA 13.0 oder 13.1, einen Treiber ab 580, Ubuntu 24.04 und die Architekturen Blackwell, Hopper, Ada Lovelace und Ampere. Die Release-Seite auf GitHub, am selben Tag gelesen, markiert noch 1.4.2 als neuestes Release und zeigt 1.5.0 nur als modellspezifische Pre-Releases; prüfen Sie also die Version des Images, das Sie ausrollen. Die vLLM-Version, mit der Dynamo gekoppelt ist, liegt drei Minor-Releases hinter vLLMs eigenem 0.31.0 vom 5. Oktober, eine neue Funktion in vLLM erreicht Dynamo also erst mit einem späteren Release. Unser Vergleich von vLLM, SGLang und TensorRT-LLM behandelt die Engines selbst.

Dynamo läuft auf Bare Metal, unter Slurm oder über seinen Operator auf Kubernetes. Die Worker finden einander über ein Discovery-Backend, außerhalb von Kubernetes standardmäßig etcd, und KV-Events laufen standardmäßig über ZMQ, optional über NATS. llm-d ist ein CNCF-Sandbox-Projekt, gegründet von Red Hat, Google Cloud, IBM Research, CoreWeave und NVIDIA. Seine Dokumentation, markiert als v0.10 (latest), beschreibt einen Proxy, der der Gateway API Inference Extension entspricht; die GitHub-README des Projekts zeigt ein Badge für Version 0.8 und kündigt in ihren Neuigkeiten vom Mai 2026 v0.7 an. LLMInferenceService von KServe, in API-Version v1alpha1 in der Dokumentation von KServe 0.20, ist „auf dem Fundament von llm-d gebaut“, und unser Leitfaden zu einer privaten LLM-Plattform auf Kubernetes ordnet seinen Router in diesen Stack ein.

Ablauf einer disaggregierten Anfrage

In Dynamo, so wie seine Dokumentation den Ablauf mit vLLM beschreibt:

1. Das Frontend nimmt die Anfrage an, wendet das Chat-Template an und tokenisiert sie.
2. Der PrefillRouter wählt einen Prefill-Worker, per KV-Cache-bewusstem Routing oder nach Last.
3. Der Prefill-Worker berechnet den KV-Cache und gibt mit dem Ergebnis Transfer-Metadaten zurück.
4. Der Router fügt die Metadaten der Anfrage hinzu und leitet sie an einen Decode-Worker weiter.
5. Der Decode-Worker holt die KV-Blöcke über NIXL vom Prefill-Worker und erzeugt die Antwort.

Laut Dynamo überträgt NIXL den Cache „direkt aus dem VRAM der Prefill-Engine in den VRAM der Decode-Engine“. Mit vLLM und TensorRT-LLM läuft zuerst das Prefill und das Decode wartet darauf, während mit SGLang das Decode schon beginnt, während der Transfer läuft. In vLLM selbst läuft eine Prefill-Instanz mit kv_role auf kv_producer und eine Decode-Instanz mit kv_consumer, über den NixlConnector.

llm-d kehrt die Reihenfolge um. Sein Endpoint Picker wählt zuerst einen Decode-Worker und fragt einen Entscheider „angesichts dessen, wie viel des Prompts auf D gecacht ist: Soll diese Anfrage disaggregiert laufen?“ Nur eine Anfrage mit einem großen ungecachten Anteil geht an einen entfernten Prefill-Worker; bei den übrigen berechnet der Decode-Worker den Prompt selbst. Der Routing-Proxy läuft als Sidecar in jedem Decode-Pod.

KV-Cache-bewusstes Routing ohne Disaggregation

Ein verbreiteter Aufbau mit zwei bis vier Servern betreibt vollständige Kopien eines Modells hinter einem Load Balancer. KV-Cache-bewusstes Routing verbessert genau diesen Aufbau. Der Router von Dynamo „wählt den Worker, der eine Anfrage zu den niedrigsten prognostizierten Kosten bedienen kann“: „Eine große Cache-Überlappung senkt den Prefill-Anteil des Scores“, während aktive Prefill- und Decode-Blöcke ihn erhöhen. Die Worker veröffentlichen Events zum Anlegen und Freigeben von KV-Blöcken, und Dynamo merkt an: „Round-Robin- und reine Last-Strategien berücksichtigen diesen Unterschied nicht.“

llm-d bietet zwei Modi. Der approximative Modus schätzt Token aus Zeichen und nimmt an, dass der gewählte Pod das Präfix nun hält; der präzise Modus liest KVEvents, die vLLM über ZMQ ausgibt, und „liefert 100 % Genauigkeit, indem er tatsächliche Token-Daten nutzt“, so llm-d. Beide setzen Prefix-Caching in der Engine voraus, etwa das automatische Prefix-Caching von vLLM.

Der Gewinn kommt aus gemeinsamen Präfixen: ein langer System-Prompt, Chats über mehrere Runden, Agenten, die ihren Verlauf erneut senden, und RAG-Prompts über dieselben Dokumente. Unser Leitfaden zu Hardware für Long-Context-LLMs behandelt Prefix-Caching und das Auslagern von Cache-Blöcken in CPU-Speicher und auf SSD, das Dynamo und llm-d beide integrieren.

Was der KV-Transfer vom Netzwerk braucht

Disaggregation über Server hinweg bewegt den Cache jeder Anfrage über das Netzwerk. llm-d hält fest: „Disaggregiertes Serving erfordert leistungsfähige (RDMA-)Verbindungen zwischen den Knoten für einen effizienten KV-Transfer.“ Ohne RDMA fällt NIXL auf TCP zurück, das llm-d „nicht effizient“ nennt und das „nur für Tests und Entwicklung verwendet werden sollte“. Sein Leitfaden zu Prefill und Decode ergänzt, dass „für den Produktionseinsatz ein Netzwerk mit hoher Bandbreite (IB, RoCE, EFA) dringend empfohlen wird“. Der Standardtransport von NIXL in vLLM ist UCX, und Dynamo nennt NVLink, InfiniBand über UCX und PCIe als Wege.

Die Größe eines Transfers ergibt sich aus der Konfiguration des Modells. Llama 3.3 70B hat 80 Schichten, 8 KV-Köpfe und eine Kopfdimension von 128, sein Cache belegt also 320 KiB je Token in 16 Bit und die Hälfte davon in FP8. Ein RAG-Prompt von 4.000 Token trägt rund 0,66 GB FP8-Cache. Bei Leitungsrate sind das nach unserer Rechnung rund 0,2 s bei 25 Gb/s, 26 ms bei 200 Gb/s und 13 ms bei 400 Gb/s, gegenüber einem TTFT-Beispielziel von 2,5 s für RAG in unserem Latenz-Leitfaden. Innerhalb eines Servers läuft derselbe Transfer über PCIe Gen5, rund 10 ms bei den 64 GB/s, die ein x16-Link in jeder Richtung überträgt, oder über die NVLink-Bridge zwischen zwei oder vier H200 NVL, die NVIDIA mit 900 GB/s je GPU angibt. Die RTX PRO 6000 hat kein NVLink.

Unser Leitfaden zu einem GPU-Inferenz-Cluster ohne InfiniBand behandelt die Fabric selbst, RoCE oder InfiniBand, und die Referenzarchitektur von NVIDIA.

Wir bauen KI-Server mit 2 bis 8 GPUs pro Knoten und wählen NICs mit 25 bis 400G passend zum Serving-Muster. Beschreiben Sie Ihre Modelle, Prompt-Längen und die Spitzenzahl der Anfragen in Bearbeitung im Formular unten.

Veröffentlichte Ergebnisse und ihre Testaufbauten

Von Herstellern und Partnern gemeldete Werte, so wie jede Quelle sie angibt; die llm-d README datiert keinen davon; keiner dieser Aufbauten nutzt die RTX PRO 6000 oder die H200 NVL.

Das Hopper-Ergebnis nutzte Prompts von 3.000 Token und Antworten von 50 Token, eine prefilllastige Mischung, die die Trennung begünstigt. Der NVIDIA-Blog testete seinen Router außerdem auf zwei HGX-H100-Knoten mit acht Kopien von DeepSeek-R1-Distill-Llama-70B bei Tensor-Parallelität 2, mit 100.000 R1-Anfragen von im Mittel 4K Eingabe- und 800 Ausgabe-Token, und zeigt den TTFT-Gewinn nur als Diagramm. In den Quellen, die wir gelesen haben, deckt kein Ergebnis die Karten dieses Artikels ab; behandeln Sie diese Werte deshalb als Richtung, nicht als Grundlage für die Auslegung.

Aggregiert oder disaggregiert mit zwei bis vier Servern

Jeder Pool hält eine eigene Kopie der Gewichte, und nur Decode-Worker halten die Caches laufender Gespräche. Auf einem Server mit acht RTX PRO 6000, der Llama 3.3 70B in FP8 mit einem FP8-Cache betreibt, ergibt die Auslegungsregel unseres Leitfadens zur Spezifikation von KI-Servern 12 Gespräche bei vollem 8K-Kontext je Karte. Acht aggregierte Replikate halten 96; zwei Prefill- und sechs Decode-Karten halten 72. Die Dokumentation von Dynamo warnt: „Wenn die KV-Kapazität im Decode der Engpass ist, können zusätzliche Prefill-Replikate die gesamte Serving-Kapazität verringern.“

Unsere Lesart der Dokumentation von Dynamo (Dokumentation v1.5.1), llm-d (Dokumentation v0.10) und vLLM, gelesen am 10. Oktober 2026; Kartenzahlen aus unserem Leitfaden zur Spezifikation.

Für ein Unternehmen mit 500 bis 2.000 Beschäftigten ist es sinnvoll, zuerst Replikate hinter KV-Cache-bewusstem Routing zu betreiben und dann TTFT und ITL im 95. Perzentil mit den Prompt-Längen des Produktionsverkehrs zu messen. Ein Test der Disaggregation lohnt sich, wenn lange Prompts die ITL über ihr Ziel treiben, während im Decode-Speicher noch Platz ist. Dynamo warnt, dass die Grenze „nicht als universeller Token-Schwellenwert festgeschrieben werden sollte“. Für DP/EP-Deployments großer Mixture-of-Experts-Modelle nennt llm-d disaggregiertes Serving „unerlässlich, um Pipeline-Bubbles zu vermeiden“, und dieser Aufbau erstreckt sich über Server auf einer RDMA-Fabric.

Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und Konfiguration und Angebot folgen innerhalb eines Werktages. Schicken Sie uns Ihre Prompt- und Antwortlängen, die Modelle und die Zahl der Server über das Formular unten.

Was wir liefern

Wir bauen KI-Server auf Bestellung mit 2 bis 8 GPUs pro Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern, montiert und im Burn-in getestet, mit Herstellergarantie auf jede Komponente. Zu den Karten gehören die RTX PRO 6000 Server Edition, die H200 NVL mit NVLink-Bridges, die L40S und die L4, mit NICs für 25, 100, 200 oder 400G für das Netzwerk, das das Serving-Muster braucht. NVIDIA-AI-Enterprise- und vGPU-Lizenzen kommen unter demselben EU-Vertrag und auf dieselbe Rechnung. Das Deployment von Modellen mit vLLM und eine Kubernetes-Plattform mit KServe sind Teil unseres Angebots Private AI/ML, umgesetzt von unserem Engineering-Partner Vixen.UNO.

FAQ