Kapitel 12 — Disaggregiertes Serving und Kubernetes
Zwölfter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel teilt Prefill und Decode endlich auf separate GPU-Pools auf und zeigt die Kubernetes-Primitive, die die Pods auf die richtige Seite des Interconnects halten.
Warum es dieses Kapitel gibt
Kapitel 11 zog eine saubere Linie zwischen Engines und Plattformen — bis die Engine selbst darauf hinweist, dass Prefill und Decode widersprüchliche Arbeitslasten sind. Prefill ist rechengebunden; Decode ist speicherbandbreitengebunden. Sie auf derselben GPU laufen zu lassen zwingt ein Stück Hardware, in zwei widersprüchlichen Dingen gut zu sein, und sie wird in beidem mittelmäßig. Disaggregiertes Serving teilt sie auf separate GPU-Pools auf, verschickt den KV-Cache zwischen den Pools und lässt jeden Pool auf seine eigene Arbeitslast tunen. Der Preis ist operative Komplexität, bezahlt in Kubernetes-Primitiven, Pod-Topologie und der Netzwerk-Fabric, die den KV-Traffic trägt. Kapitel 12 geht die Gestalt dieser Komplexität ab — die Komponenten, den Transferpfad und die CRDs (LeaderWorkerSet, Groves PodCliqueSet, KAI Scheduler), die sie ausdrücken.
12.1 Prefill und Decode wollen andere Chips bei anderen Takten
Auf derselben H100 erreicht ein langer Prefill tatsächlich 60–80 Prozent der Peak-FLOPs, und ein Dekodierschritt nutzt 5–15 Prozent der FLOPs, während er 70–90 Prozent der HBM-Bandbreite sättigt. Ihre Verzahnung unter Continuous Batching ist ein tragfähiger Kompromiss, leckt aber auf zwei Weisen. Der Rechenpass des Prefills trifft denselben HBM-Bus, über den anstehende Dekodierungen streamen wollen, und die Zeit zwischen Tokens bläht sich auf. Und die Karte läuft nur an einem Betriebspunkt: auf Prefill getunt ist Decode bandbreitenbeschränkt, auf Decode getunt ist Prefill rechenbeschränkt. Prompts sind mit RAG und Agenten von hunderten auf tausende Tokens gewachsen, und die Verzahnungskosten sind mitgewachsen. Disaggregation gibt jeder Phase ihren eigenen Pool. Prefill-Worker können auf Roh-FLOPs-Karten laufen (H100 SXM, B200). Decode-Worker können auf Kapazitäts- und Bandbreiten-Karten laufen (H200, MI300X). Jeder Pool ist auf seine eigene Arbeitslast dimensioniert — langkontextiger, kurzer Output-Traffic braucht mehr Prefill; Chat-Traffic braucht mehr Decode.
12.2 Die Gestalt sind vier Komponenten plus ein KV-Transferpfad
Ein funktionierendes disaggregiertes Deployment hat vier Komponenten. Prefill-Worker nehmen eine Anfrage an, rechnen den Prefill, geben das erste Token aus und bereiten den KV-Cache für den Transfer vor. Decode-Worker nehmen einen ankommenden KV-Cache samt Metadaten an, installieren ihn in ihrem paged Attention-Pool und führen Continuous Batching über ihre laufenden Generierungen. Ein KV-Cache-Router — die Steuerungsebene — hält den Blick auf freie KV-Kapazität, Batch-Füllstand und Netzwerkstandort jedes Decode-Workers und weist jedem Prefill-Output den Zielpunkt zu, der Transferkosten minimiert und Last balanciert. Ein Frontend-Gateway terminiert die HTTP-Verbindung des Nutzers, streamt das erste Token vom Prefill-Worker und schaltet transparent auf Streaming vom Decode-Worker um. Die kritische Beschränkung ist der KV-Transfer: eine 70B-GQA-Sequenz bei 4.096 Tokens sind 1,5–2 GB, und sie müssen innerhalb desselben 50–100-ms-TTFT-Budgets, das der Nutzer beobachtet, vom Prefill-Knoten zum Decode-Knoten wandern. NVLink mit 900 GB/s innerhalb eines Knotens und InfiniBand mit 400 Gb/s zwischen Knoten lassen die Zahlen aufgehen — wenn die Pods auf der richtigen Seite der Fabric landen.
12.3 LeaderWorkerSet, Grove und KAI drücken die Topologie aus
Kubernetes hatte ursprünglich kein Primitiv für „diese beiden typisierten Pods sind ein logisches Replikat". LeaderWorkerSet, 2024 upstream ergänzt, drückt ein Multi-Pod-Replikat mit einem Leader (etwa Prefill) und Workern (etwa Decodes) aus; der Controller hält die Gruppe als eine Scheduling-Einheit zusammen. NVIDIA Groves PodCliqueSet (2025, Teil von NVIDIA AI Enterprise) verallgemeinert weiter mit typisierten Cliques (Prefill, Decode, Router), jeweils mit eigenem Template und eigener Größe, plus einer Clique-Topologie-Beschreibung, wie die Cliques zueinander stehen. Grove reicht das gesamte Set gemeinsam mit intra- und inter-Clique-Lokalitätsbedingungen an den Scheduler. Keine CRD reicht allein; beide brauchen einen Scheduler, der die physische Topologie des Clusters kennt, was der Standard-Kubernetes-Scheduler nicht tut. KAI Scheduler — 2024 von Run:ai open-sourced — konsumiert einen Topologiegraphen, den nvidia-smi topo --matrix und der InfiniBand-Subnet-Manager erzeugen, und bewertet Platzierungskandidaten dagegen. Fordert eine Grove-Clique nvlinkDomain: required, beschränkt KAI die Platzierung auf eine einzelne NVLink-kohärente Domäne (die acht GPUs eines HGX-Baseboards an einem NVSwitch). Sagt die Inter-Clique-Topologie sameInfiniBandIsland, hält KAI die Cliques innerhalb einer Leaf-Switch-Gruppe, in der die KV-Roundtrip unter 100 μs bleibt.
Was Kapitel 12 vorbereitet
Kapitel 12 hat dem Deployment ein statisches Bild gegeben: zu jedem Zeitpunkt läuft eine feste Anzahl Cliques und bedient Traffic. Realer Traffic ist nicht statisch — Chat-Assistenten schwanken über einen Tag um den Faktor 30 zwischen Spitze und Tal, Entwicklertools gehen am Wochenende auf null, Konsumentenprodukte jagen die Sonne. Kapitel 13 geht die Autoscaling-Geschichte ab: warum Standard-HPA der falsche Skalierer für LLM-Serving ist, auf welchen Signalen KEDA stattdessen skaliert, wie Knative Scale-to-Zero ausdrückt und was einen 60–180-Sekunden-Cold-Start in etwas komprimiert, das eine nutzergerichtete Anwendung absorbieren kann.
Als Nächstes — Kapitel 13: Autoscaling und Cold-Start-Minderung. KEDA, Knative, CRIU, CUDA-Graph-Caching, NVMe — der Stack, der Scale-to-Zero mit echten Nutzern koexistieren lässt.
