Scale-up vs Scale-out: Die Netzwerk-Mathematik hinter LLM-Clustern

Jeder LLM-Cluster besteht aus zwei übereinanderliegenden Netzen: einem Scale-up-Netz, das einen Rack wie eine einzige große GPU wirken lässt (NVLink + NVSwitch), und einem Scale-out-Netz, das Tausende dieser Racks verbindet (InfiniBand oder Ethernet/RoCE). Hersteller verkaufen beide mit Peak-Bandbreiten; die interessante Frage ist, was diese Gigabits unter echten Kollektiven taugen. Dieser Artikel rechnet die Mathematik explizit vor — Linkraten, Ring-Allreduce-Kosten, Skalierungsdecken — und blickt danach auf die Silizium-Physik, warum diese zwei Ebenen überhaupt existieren.

1. Die Link-Mathematik

Zuerst die nackten Zahlen, festgetackert auf aktuelle Datasheets der aktuellen Generation. NVLink 5 (Blackwell, GB200/GB300 NVL72) gibt jeder GPU 18 Links mit je 100 GB/s pro Richtung — 900 GB/s pro Richtung, 1,8 TB/s bidirektional — über eine Kupfer-Backplane zu neun NVSwitch-Trays, die eine einzige nicht-blockierende 72-GPU-Domain mit 130 TB/s aggregierter bidirektionaler Bandbreite bilden¹². Die aktuellen InfiniBand-Generationen sind NDR mit 400 Gb/s pro Port (Quantum-2) und XDR mit 800 Gb/s pro Port (Quantum-3 / Quantum-X800, 144 × 800 Gb/s pro 4U-Switch, 115,2 Tb/s Switching-Kapazität)³⁴. Ethernet liegt bei 400G/800G mit RoCEv2, getragen von der Spectrum-X-Plattform (SN5600: 64 × 800G OSFP, 51,2 Tb/s) und ConnectX-8-SuperNICs, die auf GB300-Systemen 2 × 400 Gb/s pro GPU bereitstellen⁵².

Die Pro-GPU-Zeile ist die entscheidende. Eine B200 in einer NVL72-Domain hat 900 GB/s Switch-Fabric-Bandbreite zu jeder anderen GPU im Rack. Dieselbe GPU in ein anderes Rack über Scale-out schickt höchstens 800 Gb/s (100 GB/s) über die NIC — 9× weniger, und das ist der Bestfall (1:1-NIC-zu-GPU ohne Oversubscription). Die Einheitenfalle: 900 gegen 800 wirkt wie Fast-Parität — bis man GB/s gegen Gb/s umrechnet. Auch die Einheiten verdienen Aufmerksamkeit: Hersteller wechseln zwischen „1,8 TB/s" (bidirektionale Summe) und „900 GB/s" (pro Richtung); die Kollektiv-Rechnung unten funktioniert nur mit Zahlen pro Richtung.

2. Die Latenz-Hierarchie (und warum sie weniger zählt als Bandbreite)

Gemessene und Datasheet-Latenzbereiche der beiden Ebenen:

• Intra-Domain (NVLink/NVSwitch): GPU-zu-GPU über einen NVSwitch-Hop liegt bei rund 0,1–0,25 µs; veröffentlichte Messungen auf NVSwitch-Fabrics berichten ~100 ns Switch-Latenz plus einen Bruchteil einer Mikrosekunde NIC-Overhead⁶.
• NIC + ein Switch-Hop (NDR InfiniBand): kleine RDMA-Nachrichten über einen einzelnen Switch brauchen grob 1–2 µs Round-Trip; der Quantum-2-Switch selbst trägt in Cut-Through etwa 100 ns pro Hop bei⁶⁴.
• RoCEv2 über Ethernet: typischerweise 1,5–2,5 µs RTT innerhalb desselben Switches, mit Ethernet-Switch-Hops bei etwa 400–600 ns — ein Mehrfaches von InfiniBand pro Hop, aber in derselben Größenordnung⁶.

Der Unterschied zwischen 0,2 µs und 2 µs sieht nach einem 10×-Problem aus. Für LLM-Kollektive ist er das meistens nicht. Eine Latenzschranke gilt pro Nachricht:

wobei $\alpha$ die Latenz pro Nachricht und $S$ die Chunk-Größe ist. NCCL pipelint Ringe mit Chunks von 512 KB und größer⁷, sodass sich die Latenz auf eine Handvoll Round-Trips amortisiert. Der Bandbreiten-Term skaliert dagegen mit dem Payload selbst:

Bei einem 2-GB-Allreduce ist selbst eine 10-µs-Latenzstrafe Rauschen gegen Millisekunden Transferzeit. Latenz dominiert nur kleine Kollektive — MoE-KleinNachrichten-All-to-all, Barrier-artige Metadaten-Syncs, Decode-phasige Inferenz. Bandbreite dominiert alles, was Aktivierungen oder Gradienten bewegt. Genau deshalb existieren NVLink-Domains: sie kaufen ein 9× an Bandbreite, nicht in erster Linie Latenz.

3. Kollektiv-Mathematik: Warum Kommunikation die Skalierung begrenzt

Das Ring-Allreduce-Kostenmodell

Ein Ring-Allreduce über $N$ GPUs mit Per-GPU-Payload $V$ zerfällt in Reduce-Scatter (Daten zirkulieren einmal, $V$ pro GPU wird zu $V/N$ pro GPU reduziert) und All-Gather (die reduzierten Shards zirkulieren einmal). Jede Phase bewegt $\frac{N-1}{N}V$ pro GPU, also gilt für die Gesamtzeit:

mit $B$ als Per-GPU-Bus-Bandbreite (pro Richtung — im Ring sendet und empfängt jede GPU gleichzeitig). Der Faktor $\frac{2(N-1)}{N}$ nähert sich der 2 an und überschreitet sie nie — die berühmte „algorithmische Bandbreiten"-Eigenschaft: Ein RING bleibt bandbreitenlimitiert, egal wie viele GPUs man hinzufügt. Der N-Faktor, berechnet:

Durchgerechnetes Beispiel: Aktivierungs-Allreduce bei Tensor-Parallelismus

Ein Transformer-Layer mit tensor-parallelem Attention-Output-Allreduce, dem klassischen TP-Flaschenhals: Hidden Size 16.384, Batch 8, Sequenz 8.192, BF16:

Ring-Allreduce-Zeit über drei Netze, mit obiger Formel berechnet:

Jetzt die Rechenzeit daneben. Die GEMM hinter dieser Aktivierung ist eine 16k→64k-Expansion, etwa $1,4 \cdot 10^{14}$ FLOPs; bei einer B200 mit rund 2,25 PFLOPS dichtem BF16 pro GPU ergibt das 31,3 ms auf 2 GPUs, aber nur 7,8 ms auf 8 und 0,87 ms auf 72 GPUs. Mit Kommunikationsterm ergibt sich das tatsächliche Skalierungsbild:

Zwei Schlussfolgerungen fallen direkt aus der Arithmetik raus. Von 2 auf 8 GPUs innerhalb einer NVLink-Domain erhält man 2,81× statt der idealen 4× — der Kommunikationsterm frisst rund 35 %. Von 8 auf 72 GPUs erhält man nur 2,15× statt 9× — bei einem Komm-Anteil von 84 % bewegt man Aktivierungen länger als man matmul-t, und das bei NVLink-Klasse. Das ist die Decke, die kein Marketing-Slide wegwischt, denn die Beschleunigung sättigt bei

Da $T_c$ mit $1/n$ schrumpft, der Kommunikationsterm aber näherungsweise konstant bleibt, rennt jede Strong-Scaling-Workload gegen die Wand beim $N$, wo $\frac{2(N-1)}{N}\frac{V}{B} \approx T_c/1$.

Baum-Algorithmen und In-Network-Reduction

Baum-Algorithmen erreichen dasselbe Datenvolumen $\mathcal{O}(V \log N)$, gewinnen aber bei kleinem $V$ auf Latenz: Ein Binärbaum-Allreduce braucht $\log N$ statt $N-1$ Schritte, erkauft sich das aber mit schlechterer Bandbreitenausnutzung nahe der Wurzel. Der Ausweg aus Software-Bäumen ist die Reduktion im Netz selbst. Auf InfiniBand führt SHARP die Reduktion direkt in der Switch-ASIC aus, während die Daten durch einen Hardware-Reduktionsbaum strömen — die SHARP-Streaming-Aggregation-Studie misst MPI_Allreduce bei rund 95 % der Rohbandbreite und 2–5× der Bandbreite host-basierter Reduktion für mittlere bis große Nachrichten⁸, sowie bis zu 5,1× niedrigere MPI_Allreduce-Latenz bei 7.861 Nodes auf TACC Frontera⁹. NVIDIA berichtet für SHARPv2 (HDR-Generation) eine Verdopplung der Allreduce-Bandbreite, was in deren MLPerf-v1.0-Einreichung 17 % End-to-End-BERT-Trainingsdurchsatz einbrachte (Herstellerangabe)¹⁰. Die NVLink-Domain hat ein eigenes Pendant: NVSwitch-ASICs implementieren SHARP-artiges Multicast und Reduktion für Intra-Rack-Kollektive²; NVIDIA nennt 4× Bandbreiteneffizienz mit FP8-SHARP auf dem NVLink-Switch-Chip des GB200 NVL72 (Herstellerangabe)². In-Network-Reduction durchbricht nicht die Bandbreitenschranke — sie erhöht den erreichbaren Anteil davon und spart einen Durchlauf.

4. Die Silizium-Sicht: Warum Scale-out mehr pro GB/s kostet

Wäre Ethernet kostenlos, würde es überall reichen. Der Grund, warum NVLink-Domains überhaupt existieren, ist Pro-Bit-Physik.

Kupfer gegen SerDes. Im Rack laufen NVLink-5-Links mit 100 GB/s als passives Kupfer über die NVL72-Backplane — kaum Reichweite (deshalb Rack-Maßstab), aber nahezu null Transceiver-Energie. Außerhalb des Racks quert jedes Bit PAM4-SerDes mit 100–200 Gb/s pro Lane. Die Task-Force-Umfrage der IEEE 802.3df beziffert 200-Gb/s-pro-Lane-SerDes auf etwa 3,5–4,5+ pJ/Bit projiziert je nach Kanalverlust, gegenüber Long-Reach-100G/Lane-SerDes mit 4,6–6,5 pJ/Bit gemessen; nur intra-Package-XSR-Links erreichen ≈1,7 pJ/Bit¹¹. Das pro SerDes-Ende; jeder steckbare Link zahlt beide Enden.

Optik. Jenseits von ~2–3 m passivem Kupfer (oder ~7 m mit Active-Copper-Kabeln bei 2–4 pJ/Bit) springt Scale-out auf Optik: 800G-Steckmodule verbrauchen all-in 15–20 pJ/Bit (25–30 W pro 1,6T-Modul mit DSP-dominiertem Verbrauch), allein der DSP liegt bei 6–7 W pro 800G-Modul in der 100G/200G-Lane-Generation¹¹. Co-Packaged Optics und Silizium-Photonik versprechen eine Senkung Richtung 3–5 pJ/Bit — das ist aber Roadmap-Mathematik, keine ausgelieferte Rack-Realität (Stand 2026).

Die Arithmetik eines Hops: 800 Gb/s über eine optische Strecke kosten rund $800 \cdot 10^9 \cdot 15 \cdot 10^{-12} \approx 12$ W pro Richtung pro Link-Ende, gegenüber Bruchteilen eines Watt für eine Kupfer-NVLink-Lane im Rack. Multipliziert mit den zehntausenden Links eines 100k-GPU-Clusters wird Scale-out-Interconnect zu einem messbaren — teils dominanten — Anteil des Rack-Power-Budgets. Die Dämpfung des Kupfers setzt die umgekehrte Zange: Retimer und DSPs kaufen Reichweite zu pJ/Bit-Kosten, die mit dem Verlust steigen. Deshalb ist die NVLink-Domain ein Rack, keine Reihe: Das „eine Domain" des GB300 NVL72 sind neun kupferverbundene NVSwitch-Trays in einem Rack — keine beliebig getroffene Designentscheidung². Scale-up endet, wo Kupfer billig ist; Scale-out beginnt, wo Kupfer nicht mehr funktioniert.

5. Topologie: Bisektionsbandbreite und Oversubscription

Scale-out-Netze sind Fat-Trees. Die Schlüsselmetrik ist die Bisektionsbandbreite: halbiere den Cluster und summiere die Bandbreite der geschnittenen Links. In einem idealen (nicht-blockierenden) zweistufigen Fat-Tree entspricht die Bisektionsbandbreite der hostseitigen Bandbreite — jede GPU kann mit jeder anderen mit Leitungsgeschwindigkeit sprechen, bei jedem Traffic-Muster. Das erfordert, dass die Spine-Ebene exakt die aggregierte Bandbreite der Leaves hat; in der Praxis drückt die Kostenfrage Betreiber zur Oversubscription: z. B. 2:1 oder 4:1 (auf 4 Gb/s Leaf-Downlink kommen 1 Gb/s Uplink). Unter einem Gleichverteilungs-Muster halbiert eine 2:1-oversubscribed Fabric die worst-case-effektive Allreduce-Bandbreite, obwohl auf jedem Port weiterhin „800 Gb/s" steht. NVIDIAs AI-Factory-Referenzarchitektur für GB300 baut ein zweistufiges SN5600-Leaf-Spine-Netz mit 144 × 400 Gb/s Uplinks pro 72-GPU-Rack bei 1:1 — bewusst nicht-oversubscribed, pro Ebene — genau damit diese Rechnung für Allreduce ehrlich bleibt².

Multiplane-Designs verteilen jede SuperNIC auf 2–8 unabhängige Leaf-Spine-Ebenen und balancieren Pakete in Hardware darüber aus — Radix-Grenzen lockern sich bei konstanter Bisektionsbandbreite⁵. Der Preis ist die Fragmentierung der Pfade eines einzelnen Kollektivs; NCCL muss Multiplane-aware sein.

Was bedeutet „GB300 NVL72 ist eine Domain" für ein Allreduce? Ein 72-GPU-Ring kann vollständig innerhalb der Kupfer-Domain gezogen werden und läuft mit 900 GB/s pro GPU. Dasselbe 72-GPU-Allreduce, über neun 8-GPU-Server via Ethernet verteilt, muss $\frac{2 \cdot 71}{72}$ des Payloads über Inter-Node-Links schicken — bei noch so idealer 1:1-XDR-Provisionierung sind das die 5,29 ms gegen 4,71 ms plus ein bis zwei Switch-Hops, und das ganze Kollektiv steht und fällt mit der Oversubscription-Rate der Fabric, der Congestion Control auf dem Hot Path und dem Adaptive Routing.

6. Entscheidungstabelle nach Workload

Bei MoE sagen die Zahlen: bei einem realistischen Tokenfluss — etwa 65.536 Tokens × 4.096 Hidden in BF16, 0,54 GB pro GPU pro Dispatch — bewegt eine 800-Gb/s-pro-GPU-Ethernet/NIC-Zuteilung das in rund 5,37 ms, derselbe Dispatch im effektiven ~450 GB/s Halbduplex-Anteil einer NVLink-Domain braucht etwa 1,19 ms. Aber MoE-Dispatch sättigt in der Praxis unterhalb dieser Leitungsraten, denn All-to-all ist das Muster, das am empfindlichsten auf Oversubscription und Incast reagiert (viele GPUs treffen gleichzeitig beim Combine auf denselben Leaf-Switch): Die Fabric knickt in ihrem Lossless-Verhalten und Adaptive Routing ein, bevor die Linkrate es tut. Was zuerst sättigt, ist nicht rohe Gb/s — sondern die effektive Bisektionsbandbreite unter der tatsächlich anliegenden Permutation, plus die Latenzschranke für Kleinste-Nachrichten der Experten-Routen.

Faustregeln: TP ≤ Domain-Breite (8 auf HGX, 72 auf NVL72); PP ist Netz-agnostisch; DP ist ein Scale-out-Problem, das jedes Netz bei 1:1-Provisionierung stemmt; MoE-All-to-all will NVLink-Klasse innerhalb der Expert-Gruppen und eine nicht-oversubscribed Scale-out-Fabric — mit SHARP- und Multiplane-Offload, wo der Fan-out das Rack verlässt.

7. Kritische Sicht: Marketing-Zahlen gegen nutzbare Bandbreite

Die Datasheet-Zahl ist nicht die Zahl, die das Kollektiv bekommt. Drei systematische Lücken:

1. Peak-Gb/s gilt pro Richtung bei 100 % Auslastung. Echte RoCEv2-Fabrics stemmen 60–90 % der Leitungsgeschwindigkeit unter Kollektiv-Traffic, je nach Tuning der Congestion Control; InfiniBand mit SHARP wird mit rund ≈95 % der Netzbandbreite gemessen⁸. Die Lücke multipliziert sich mit jedem Hop.
2. „Aggregierte" Bandbreite ist eine Summe, keine Fabric-Eigenschaft. Die gefeierte NVL72-Zahl von 130 TB/s ist $\sum 72 \cdot 1,8$ TB/s bidirektional — die Summe aller GPU-Linkbandbreiten, keine Zahl, die ein einzelnes Kollektiv je sieht¹. Ein Ring-Allreduce auf NVL72 erreicht eine algorithmische Bandbreite von $\frac{N}{2(N-1)} \cdot 900 \approx 456$ GB/s — hervorragend, aber „130 TB/s" ist es nicht, und ein Marketing-Slide, der „130 TB/s NVLink" gegen „51,2 Tb/s Ethernet-Switch" stellt, vergleicht eine rackweite aggregierte Summe mit einer Switch-Kapazität.
3. Bisektionsbandbreite und Oversubscription stehen selten im Datenblatt. Berechnetes Beispiel: eine aus 800-Gb/s-Links gebaute „100.000-GPU-Fabric" mit 4:1-Spine-Oversubscription hat eine Worst-Case-Bisektion von $\frac{1}{4} \cdot N \cdot 100$ GB/s — 2,5 PB/s, was gewaltig klingt, bis man pro GPU teilt: 25 GB/s nutzbar im Worst Case pro GPU statt der beworbenen 100 GB/s. Unter einem bandbreitenlimitierten Ring-Allreduce läuft der Kommunikationsterm schlicht mit $B = 25$ GB/s und vervierfacht $T_{\text{Ring}}$ gegenüber der Datasheet-Behauptung. Einheitsbreite „AI-Fabric"-Behauptungen erben alle drei Lücken gleichzeitig.

Der ehrliche Vergleich, pro GPU und pro Richtung: NVLink 5 liefert 900 GB/s in-domain; XDR und 800G RoCEv2 provisionieren bis zu 100 GB/s im Idealverhältnis 1:1; Oversubscription und Protokolleffizienz skalieren diese Zahl nach unten, nie nach oben. Scale-up kauft ein ~4,5–9×-Bandbreitenplus gegenüber einem gut provisionierten Scale-out-Link, und die Kollektiv-Mathematik zeigt, dass genau dieses Plus das ist, was TP-lastige und MoE-Workloads verbrauchen. Alles andere — DP-Gradienten, PP-Übergaben, Checkpoint- und Storage-Traffic — läuft gut auf der Scale-out-Fabric, und genau deshalb existieren riesige Trainingscluster überhaupt.

Verwandte Ressourcen

• NVIDIA NVLink-Lösungen
• NVIDIA GB200 NVL72-Übersicht