Disaggregated Serving im eigenen Rack: warum Prefill und Decode getrennte Hardware brauchen

Wer 2025 einen GPU-Server für Inferenz beschafft hat, hat meistens nach einer einzigen Kennzahl gekauft: genug VRAM für die Modellgewichte, dazu Tensor-Parallelismus über acht GPUs, fertig. Diese Rechnung geht seit dem Sommer 2026 nicht mehr auf. Die offenen Gewichte, die derzeit interessant sind, sind keine dichten 70-Milliarden-Modelle mehr, sondern Mixture-of-Experts-Architekturen im Billionenbereich mit einer Million Token Kontext.

Damit ändert sich die Beschaffungsfrage grundlegend. Es geht nicht mehr nur darum, wie viel Speicher ein Knoten hat, sondern welche Rolle er im Cluster spielt – und wie die Knoten miteinander verbunden sind. Dieser Beitrag zeigt, warum die Trennung von Prefill und Decode technisch zwingend wird, welche Bausteine sie produktionsreif machen und wie man daraus ein belastbares Sizing für das eigene Rack ableitet.

Warum ein Server für 100-Mrd-aktiv-Modelle nicht reicht

Die einfachste Version des Arguments ist eine Rechnung, die jeder selbst nachvollziehen kann. Ein voll bestückter Knoten mit acht H200-GPUs bringt 8 × 141 GB = 1.128 GB HBM. Kimi K3, seit dem 27. Juli 2026 mit offenen Gewichten auf Hugging Face verfügbar, hat 2,8 Billionen Gesamtparameter. Selbst in 4-Bit-Quantisierung belegen allein die Gewichte rund 1,4 TB – und zwar bevor ein einziges Byte KV-Cache oder eine Aktivierung angelegt ist. Ein einzelner Server scheidet damit nicht aus Performancegründen aus, sondern rein arithmetisch.

Das Modell ist dabei kein Ausreißer, sondern der Normalfall des Jahrgangs 2026. Ein Blick auf die relevanten offenen Gewichte:

Modell	Gesamt / aktiv	Kontext	Verfügbar seit
Kimi K3 (Moonshot AI)	2,8 Bio. / 104 Mrd.	1 Mio. Token	27.07.2026
DeepSeek V4-Pro	1,6 Bio. / 49 Mrd.	1 Mio. Token	26.04.2026 (Report)
DeepSeek V4-Flash	284 Mrd. / 13 Mrd.	1 Mio. Token	26.04.2026 (Report)
DeepSeek-V4-Flash-0731	304 Mrd. gesamt	1 Mio. Token	31.07.2026
DeepSeek-V4-Pro-0813	1,7 Bio. gesamt	1 Mio. Token	13.08.2026

Kimi K3 ist mit 896 Experten, von denen pro Token 16 aktiv sind, 93 Layern und einer Mischung aus KDA- und Gated-MLA-Attention der derzeit extremste Fall. 104 Milliarden aktive Parameter bedeuten: Selbst wenn das Routing nur einen Bruchteil der Experten anspricht, müssen sämtliche Gewichte irgendwo im Cluster resident liegen. Drei Ressourcen konkurrieren dabei um denselben HBM: die dichten Layer-Gewichte, die Expertenmatrizen und der KV-Cache, dessen Größe linear mit der Kontextlänge wächst. Bei einer Million Token Kontext ist der KV-Cache kein Rundungsfehler mehr, sondern ein eigenständiger Kostenblock.

Dazu kommt ein zweiter, unabhängiger Grund. Selbst wenn ein Modell rechnerisch in einen Knoten passen würde, bleibt die Annahme falsch, dass dieselbe GPU-Rolle beide Phasen der Inferenz gut bedient. Die Zielgrößen Time-to-First-Token (TTFT) und Time-per-Output-Token (TPOT) lassen sich auf einem gemeinsamen Pool nicht gleichzeitig optimieren: Große Prefill-Batches verbessern den Durchsatz, blockieren aber die laufenden Decode-Schritte und lassen TPOT einbrechen. Wer stattdessen Decode priorisiert, verschenkt Rechenleistung beim Prefill.

Prefill ist compute-bound, Decode ist memory-bound

Die Trennung ergibt sich aus den physikalischen Eigenschaften der beiden Phasen, nicht aus einer Software-Mode. Beim Prefill verarbeitet das Modell alle Eingabetokens in einem einzigen Forward-Pass. Der Speicherbedarf wächst mit O(n), die benötigten FLOPs skalieren mit der Promptlänge – die GPU rechnet dichte Matrixmultiplikationen mit hoher Auslastung, und zwar für kurze Zeit am Stück. Ein 200.000-Token-Prompt aus einem Vertragsarchiv beschäftigt die Tensor Cores für Sekunden, aber die Speicherbandbreite bleibt weitgehend ungenutzt.

Beim Decode ist es exakt umgekehrt. Pro Schritt entsteht genau ein Token, und dafür muss der KV-Cache aller vorherigen Tokens gelesen werden. Die Rechenlast pro Schritt ist winzig, das Lesevolumen enorm. Decode ist damit vollständig von der Speicherbandbreite dominiert – die Rechenwerke laufen im Leerlauf mit.

Praktisch bedeutet das auch, dass beide Rollen unterschiedliche Konfigurationen vertragen: andere Batch-Größen, andere Parallelisierungsgrade, andere Kommunikations-Backends. Genau diese Freiheit ist der eigentliche Gewinn, nicht die Trennung an sich.

NVIDIA Dynamo 1.0: Orchestrierung über vLLM, TensorRT-LLM und SGLang

Seit dem 16. März 2026 ist NVIDIA Dynamo in Version 1.0 als Produktionsrelease verfügbar. Dynamo ist keine Inferenz-Engine, sondern eine Schicht darüber: Es orchestriert bestehende Engines – vLLM, NVIDIA TensorRT-LLM und SGLang, laut Produktseite zusätzlich PyTorch und NIM-Microservices – und verteilt Arbeit auf getrennte Worker-Pools. Bestehendes Model Serving muss also nicht ersetzt, sondern eingebettet werden.

Drei Stufen statt zwei: Encode, Prefill, Decode

Neu in 1.0 ist, dass die Disaggregation nicht bei zwei Rollen aufhört. Dynamo trennt Encode, Prefill und Decode (E/P/D) und skaliert alle drei unabhängig voneinander, statt sie gemeinsam auf derselben GPU laufen zu lassen. Der Encode-Schritt ist für reine Textmodelle irrelevant, wird aber sofort zum dritten Knotentyp, sobald multimodale Eingaben – Bilder, Scans, PDFs mit Layout – im Spiel sind. Wer heute eine Topologie plant und morgen Dokumentenbilder verarbeiten will, sollte diese Rolle von Anfang an einkalkulieren.

Was Dynamo 1.0 tatsächlich misst

Bei Leistungszahlen lohnt Genauigkeit, weil im Markt zwei Werte durcheinandergeraten. Der aktuelle, zu Dynamo 1.0 gehörende Wert lautet: bis zu 7-fach mehr bediente Requests auf NVIDIA Blackwell (Benchmark SemiAnalysis InferenceX, DeepSeek R1-0528, FP4, 1k/1k-Kontext). Die NVIDIA-Produktseite nennt für GB200 NVL72 mit Wide Expert Parallel ebenfalls bis zu 7-fachen MoE-Durchsatz gegenüber B200-Systemen.

Die vielzitierte 30-fache Steigerung stammt dagegen aus der ursprünglichen Dynamo-Ankündigung vom 18. März 2025 und bezieht sich auf erzeugte Tokens pro GPU für DeepSeek-R1 auf einem großen Cluster aus GB200-NVL72-Racks – nicht auf bediente Requests und nicht auf Dynamo 1.0. Wer mit dieser Zahl kalkuliert, kalkuliert falsch.

Weitere belastbare Werte aus dem 1.0-Release: bis zu 4-fach niedrigere TTFT und 1,5-fach höherer Durchsatz bei agentischer Inferenz (Llama 3.1 auf Hopper), ein Multimodal-Embedding-Cache, der TTFT um bis zu 30 % und den Durchsatz um bis zu 25 % verbessert (Qwen3-VL-30B), sowie Model-Weight-Streaming, das das Laden großer MoE-Modelle um bis zu 7-fach beschleunigt (DeepSeek V3 auf H200). Gerade der letzte Punkt ist im Eigenbetrieb unterschätzt: Wer ein 1,7-Billionen-Modell nach jedem Wartungsfenster von Platte lädt, merkt den Unterschied im Betriebsalltag deutlich.

Routing erfolgt nicht per Round-Robin, sondern nach Auslastung – inklusive Kenntnis darüber, welcher Worker bereits welche Prefix-Blöcke im Cache hat. Für Kubernetes-Deployments bringt Dynamo mit „Grove" eine topologieoptimierte Komponente für Single- und Multi-Node-Inferenz mit; Integrationen bestehen unter anderem mit AWS, Google Cloud, Azure, Alibaba Cloud und OCI sowie den Storage-Anbietern DDN, NetApp, WEKA und Pure Storage.

vLLM Expert Parallelism für MoE-Schichten

Die zweite Hälfte des Puzzles liegt in der Engine selbst. Expert Parallelism verteilt die Expertenschichten eines MoE-Modells über GPUs, statt jede GPU eine Scheibe jeder Matrix halten zu lassen. Für Modelle mit 896 Experten ist das der einzige sinnvolle Weg – Tensor-Parallelismus allein würde die Kommunikation pro Layer ins Absurde treiben.

Am 14. Mai 2026 hat das vLLM-Projekt Elastic Expert Parallelism veröffentlicht. Aktiviert wird es über die Flags --enable-expert-parallel und --enable-elastic-ep, optional ergänzt um --enable-eplb für Load Balancing der Experten sowie --all2all-backend allgather_reducescatter. Wichtig für die Erwartungshaltung: Die Implementierung zielt zunächst auf Ray-DP-Deployments mit tensor_parallel_size=1, einem einzigen API-Server und ohne Dual-Batch-Overlap. Der Blogpost nennt keine Benchmark-Zahlen, Demo-Modell ist DeepSeek-V2-Lite-Chat. Das ist eine frühe Stufe, kein fertiges Produktionsfeature – wer heute plant, sollte Elastic EP als Richtungsentscheidung werten, nicht als Betriebsgarantie.

Warum die All2All-Backends das eigentliche Argument liefern

Unabhängig von Elastic EP kennt vLLM in der Expert-Parallel-Dokumentation mehrere Kommunikations-Backends, und deren Zuschnitt ist das stärkste technische Argument für die Rollentrennung überhaupt:

--all2all-backend	Optimiert für	Hinweis
allgather_reducescatter	Allgemeiner Betrieb (Default)	Läuft mit jeder EP+DP-Konfiguration
deepep_high_throughput	Prefill	Große Batches, Durchsatz vor Latenz
deepep_low_latency	Decode	Mit CUDA-Graph-Unterstützung
flashinfer_nvlink_one/two_sided	Multi-Node-NVLink-Systeme	deepep_v2 setzt NCCL ≥ 2.30.4 voraus

Die Konsequenz ist unmittelbar: Es gibt kein Backend, das für Prefill und Decode gleichzeitig optimal ist. In einem gemeinsamen Pool muss man sich entscheiden. Getrennte Worker-Pools können deepep_high_throughput für Prefill und deepep_low_latency für Decode fahren – zwei verschiedene Optima statt eines Kompromisses. Für deepep_v2 ist zu beachten, dass das mit PyTorch ausgelieferte NCCL aktualisiert werden muss; das ist ein klassischer Stolperstein beim ersten Rollout.

Das Interconnect wird zur Kaufentscheidung

Wenn Prefill und Decode auf verschiedener Hardware laufen, muss der KV-Cache zwischen ihnen bewegt werden. Dynamo nutzt dafür die NIXL-Schicht: KV-Blöcke werden non-blocking per RDMA direkt aus dem VRAM der Prefill-Engine in das VRAM der Decode-Engine geschrieben – über NVLink innerhalb eines Knotens oder InfiniBand zwischen Knoten.

Der Mechanismus ist bewusst sparsam: Die Memory-Deskriptoren liegen in etcd, über die Leitung gehen nur Block-IDs. Prefill-Worker führen einen „remote NIXL read" für Prefix-Cache-Treffer aus und einen „remote NIXL write" für neu berechnete Blöcke. Laufen Prefill- und Decode-Pool mit unterschiedlichen TP-Konfigurationen, transponiert ein spezieller Kernel das KV-Layout. Der SGLang-Pfad arbeitet zusätzlich mit einem Bootstrap-Server im tokenizer_manager in Verbindung mit NIXL beziehungsweise Mooncake; die RDMA-Verbindungen werden einmalig aufgebaut und für alle folgenden Requests wiederverwendet.

Für die Beschaffung heißt das konkret: NVLink für die Kopplung innerhalb eines Knotens, InfiniBand mit RDMA für die Kopplung zwischen Knoten. Ein Cluster ohne RDMA-fähiges Netz kann Disaggregated Serving zwar konfigurieren, wird aber im Millionen-Token-Regime keinen Vorteil sehen. Wie sich diese Entscheidung über fünf Jahre auf die Gesamtkosten auswirkt, lässt sich mit unserem TCO-Rechner für GPU-Cluster durchspielen.

Sizing: wie viele Knoten in welcher Rolle

Die Aufteilung zwischen Prefill- und Decode-Knoten ist keine Glaubensfrage, sondern eine Funktion des Lastprofils. Ein nachvollziehbares Vorgehen in fünf Schritten:

1. Lastprofil messen, nicht schätzen. Erheben Sie über mindestens zwei Wochen die mittlere Promptlänge, die mittlere Antwortlänge und die gleichzeitige Nutzerzahl. Ohne diese drei Zahlen ist jedes Sizing geraten.
2. Zielwerte festlegen. TTFT und TPOT vorab definieren – etwa 2 Sekunden TTFT und 50 ms TPOT für interaktive Assistenten, deutlich lockerer für Batch-Auswertungen. Diese Werte bestimmen die Pool-Größen, nicht umgekehrt.
3. Verhältnis ableiten. Ein Profil mit 100.000 Token Prompt und 500 Token Antwort ist prefill-lastig und braucht mehr Prefill-Kapazität. Ein Chat-Profil mit 1.500 Token Prompt und 800 Token Antwort ist decode-lastig – dort liegt der Schwerpunkt umgekehrt.
4. Modellwahl in die Rechnung nehmen. Gegenüber DeepSeek V3.2 benötigt V4-Pro im Millionen-Token-Kontext nur 27 % der Rechenkosten pro Token und 10 % des KV-Cache. Das verschiebt das Prefill/Decode-Verhältnis spürbar und damit die Knotenaufteilung – dieselbe Last verlangt mit einem anderen Modell eine andere Topologie.
5. Reserve für die Encode-Rolle einplanen, falls multimodale Eingaben absehbar sind.

Zwei weitere Faktoren gehören 2026 ins Sizing. Erstens spekulatives Decoding: Die Sommer-Checkpoints DeepSeek-V4-Flash-0731 und DeepSeek-V4-Pro-0813 bringen das DSpark-Modul mit, das im Beispiel 7 Tokens pro Schritt erzeugt. Das entlastet den Decode-Pool erheblich und verschiebt den Bedarf Richtung Prefill. Zweitens die Cache-Präzision: Beide Checkpoints unterstützen FP8-KV-Cache und FP4-Indexer-Cache, bei einer empfohlenen maximalen Ausgabelänge von 384K Tokens. Ein halbierter KV-Cache halbiert auch das Transfervolumen über NIXL.

Eine belastbare Auslegung entsteht aus Messung plus Lasttest auf Leihhardware, nicht aus Datenblättern. Wir begleiten diesen Schritt im Rahmen der On-Premise-KI-Infrastruktur und des KI-Full-Stack-Providings, inklusive Betrieb der Orchestrierungsschicht.

Wann sich Disaggregation nicht lohnt

Der ehrlichste Teil der Technologie steckt in ihrer eigenen Abschaltlogik. Dynamo schickt einen Request nur dann an einen Remote-Prefill-Worker, wenn beide Bedingungen erfüllt sind: Erstens liegt die Prefill-Länge ohne Prefix-Cache-Treffer über einem Schwellwert, zweitens liegt die Warteschlange der Prefill-Worker unter einem Schwellwert. Kurze Prefills werden lokal per Piggyback auf laufende Decode-Batches erledigt. Bei einem langen Prefix-Cache-Treffer wird der Vorgang selbst memory-bound und gehört damit auf die Decode-Engine. Ist die Prefill-Queue überlastet, fällt das System auf lokales Prefill zurück.

Wenn die Software also selbst permanent prüft, ob sich die Trennung im Einzelfall lohnt, sollte man diese Prüfung auch auf der Beschaffungsebene ernst nehmen. Disaggregation lohnt sich nicht, wenn:

• weniger als zwei Knoten vorhanden sind – ohne zweiten Pool gibt es nichts zu trennen;
• ein dichtes Modell im Bereich 8B bis 70B ausreicht, das ohnehin auf einen Knoten passt;
• die Nutzerzahl niedrig ist und Batches selten voll werden – dann ist die GPU nicht der Engpass;
• Batching, Prefix-Caching und Quantisierung noch nicht ausgereizt sind. Diese drei bringen im Mittelstandsmaßstab regelmäßig mehr als jede Topologieänderung, und sie kosten keine zusätzliche Hardware.

Nicht zu unterschätzen ist die Betriebskomplexität. Zwei bis drei Worker-Rollen, eine Orchestrierungsschicht, etcd, eine RDMA-Fabric und versionsabhängige NCCL-Anforderungen ergeben deutlich mehr bewegliche Teile als ein einzelner vLLM-Prozess. Wer keine Mannschaft hat, die das im Störfall um 22 Uhr auseinandernehmen kann, sollte entweder klein anfangen oder den Betrieb auslagern.

Die pragmatische Reihenfolge lautet daher: erst das kleinstmögliche Modell wählen, das die Aufgabe löst; dann Batching und Prefix-Caching ausreizen; dann quantisieren; und erst wenn das Lastprofil weiterhin an TTFT oder TPOT scheitert, die Rollen trennen. Wer diesen Weg einhält, kauft Hardware für einen gemessenen Engpass – und nicht für eine Architekturüberschrift.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. NVIDIA Technical Blog Dynamo 1.0, Produktionsrelease vom 16.03.2026, E/P/D-Disaggregation, Benchmarkwerte
2. NVIDIA Dynamo Produktseite Unterstützte Engines, Wide Expert Parallel auf GB200 NVL72, Grove, Cloud- und Storage-Integrationen
3. NVIDIA Newsroom Ursprüngliche Dynamo-Ankündigung vom 18.03.2025, Herkunft der 30x-Zahl (Tokens pro GPU)
4. Dynamo-Dokumentation: Disaggregated Serving Bedingte Disaggregation, NIXL-Read/Write, etcd-Deskriptoren, Layout-Transpose
5. Dynamo 1.0.1 Docs: SGLang-Disaggregation Bootstrap-Server im tokenizer_manager, NIXL/Mooncake, RDMA-Verbindungswiederverwendung
6. vLLM-Blog: Elastic Expert Parallelism Release 14.05.2026, Flags, Einschränkungen auf Ray-DP mit tensor_parallel_size=1
7. vLLM-Dokumentation: Expert Parallel Deployment All2All-Backends, DeepEP-Varianten, NCCL ≥ 2.30.4 für deepep_v2
8. Hugging Face: moonshotai/Kimi-K3 2,8 Bio. gesamt / 104 Mrd. aktiv, 896 Experten, 93 Layer, 1 Mio. Token Kontext
9. Hugging Face: Kimi-K3 Commit-Historie Initial Commit der offenen Gewichte am 27.07.2026
10. Hugging Face: DeepSeek AI Übersicht der Sommer-2026-Checkpoints
11. Hugging Face: DeepSeek-V4-Pro-0813 13.08.2026, 1,7 Bio. gesamt, DSpark, FP8-KV-Cache, 384K Ausgabelänge
12. Hugging Face: DeepSeek-V4-Flash-0731 31.07.2026, 304 Mrd. gesamt, spekulatives Decoding
13. arXiv 2606.19348 – DeepSeek-V4 Technical Report V4-Pro/Flash Parameter, Hybrid Attention, 27 % Rechenkosten und 10 % KV-Cache ggü. V3.2

Häufig gestellte Fragen zu Disaggregated Serving

Brauche ich Dynamo, oder reicht vLLM allein?

Für einen einzelnen Knoten reicht vLLM. Dynamo lohnt sich, sobald Prefill und Decode auf getrennte Worker-Pools verteilt und dynamisch skaliert werden sollen.

Was ist NIXL und warum ist es kaufentscheidend?

NIXL ist die Transportschicht für den KV-Cache zwischen Prefill- und Decode-Workern. Sie läuft über NVLink oder InfiniBand – das Interconnect bestimmt damit direkt die erreichbare Latenz.

Funktioniert Expert Parallelism auch mit dichten Modellen?

Nein, Expert Parallelism verteilt MoE-Expertenschichten. Für dichte Modelle bleiben Tensor- und Pipeline-Parallelismus die relevanten Verfahren.

Ab welcher Größe lohnt Disaggregated Serving?

Praktisch erst ab zwei Knoten und bei MoE-Modellen mit hoher aktiver Parameterzahl. Darunter gewinnt man mehr durch Batching, Prefix-Caching und Quantisierung.