Geswitchte Cluster-Topologien: Fat-Tree, Leaf-Spine, Dragonfly+, Tesseract

Jedes Cluster-Diagramm in einem Hersteller-Deck beginnt gleich: eine Reihe Kästchen mit der Beschriftung „Knoten“, eine Reihe Kästchen mit der Beschriftung „Switch“ und Pfeile dazwischen. Die Diagramme sind bewusst simpel, denn die eigentliche Entscheidung dahinter — welche Topologie, mit wie viel Überbuchung, mit welcher Geschwindigkeit pro Port — ist nach den GPUs selbst die größte Kostenentscheidung in einem KI-Cluster.

Dieser Artikel ist die Topologie-Ebene zwischen N02 (welches Protokoll — InfiniBand, RoCE, schlichtes Ethernet) und N06–N08 (wie sich die Leitung tatsächlich verhält, sobald die Topologie verkabelt ist). Er behandelt die vier Familien, die 2026 zählen: Fat-Tree / Clos / Leaf-Spine, Dragonfly / Dragonfly+, Tesserakt / Hyperwürfel und die Torus-Familie, die in zwei speziellen Nischen des HPC überlebt hat. Am Ende steht die ehrliche Einschätzung: Rund neun von zehn Kentino-Kunden brauchen nichts davon — der Artikel existiert für den zehnten.

Zielgruppe: alle, die ein Trainings-Cluster mit 8 bis 64 Knoten und das Netzwerk drumherum dimensionieren. Kein Konfigurations-Kochbuch von Cisco oder NVIDIA — sondern das Denkmodell, das ein solches Kochbuch überhaupt erst lesbar macht.

Drei verschiedene Dinge, die alle „Bandbreite“ heißen

Bevor wir Kästchen und Pfeile zeichnen, zunächst das Vokabular. Drei Begriffe werden in Cluster-Verkaufsunterlagen synonym verwendet — und meinen doch nicht dieselbe Zahl:

Ein 400-GbE-Switch mit 32 Ports besitzt 12.8 Tb/s aggregierte Bandbreite. Hängen Sie 16 Knoten mit je 400 GbE daran, erhalten Sie 3.2 Tb/s Bisection-Bandbreite (8 Knoten × 400 Gb/s auf jeder Seite des Schnitts). Bei einem Allreduce-Schritt, in dem jede der 16 GPUs die Hälfte ihres Gradienten über die Bisection schickt, wird die Schrittzeit durch diese 3.2 Tb/s geteilt — nicht durch 12.8.

Die Kurzfassung: Die Bisection-Bandbreite ist die einzige dieser drei Zahlen, die bei einem allreduce-limitierten Workload die Trainings-Schrittzeit vorhersagt. Nennt eine Hersteller-Broschüre den aggregierten Wert, denken Sie sich den ungünstigsten Schnitt und teilen entsprechend, um zur Bisection zurückzurechnen.

Für ein Cluster aus 16 Knoten mit je 8 GPUs (128 GPUs insgesamt) und einer einzelnen 100-GbE-NIC pro Knoten:

Gleiche Knotenzahl, gleiche Leitungsgeschwindigkeit, andere Zahlen — je nachdem, was gemeint ist. Mit diesem Rahmen arbeitet der Rest des Artikels.

Fat-Tree, Clos, Leaf-Spine — dieselbe Sache in drei Dialekten

Charles Clos bewies 1953, dass ein mehrstufiges Netzwerk aus kleinen Crossbar-Switches blockierungsfrei sein kann — jeder Eingang erreicht jeden Ausgang ohne Konkurrenz — und das zu einem Bruchteil der Kosten eines einzigen riesigen Crossbars. Jedes moderne Rechenzentrumsnetz ist eine Variante dieser Idee. Die Begriffe sind dabei gründlich durcheinandergeraten:

• Ein Clos-Netzwerk ist die mathematische Struktur: Eingangs-, Mittel- und Ausgangsstufen aus kleineren Switches.
• Ein Fat-Tree (Charles Leiserson, 1985) ist eine Clos-Variante, bei der die Stämme Richtung Wurzel immer dicker werden, damit die Bisection-Bandbreite mit N skaliert.
• Ein gefaltetes Clos faltet die Ausgangsstufe auf die Eingangsstufe zurück. Ein Leaf-Spine ist ein zweistufiges gefaltetes Clos. Ein dreistufiges gefaltetes Clos mit Leaf, Spine und Super-Spine ist das, was in der Praxis die meisten als Fat-Tree bezeichnen.

Zweistufiges Leaf-Spine: Jedes Leaf ist mit jedem Spine verbunden. Zwei beliebige Knoten kommunizieren über genau zwei Hops. Volle Bisection = keine Überbuchung auf der Spine-Ebene.

Jedes Leaf ist mit jedem Spine verbunden. Any-to-any-Verkehr läuft höchstens Leaf → Spine → Leaf, also über zwei Hops. Mit ausreichend Spine-Bandbreite ist das Fabric blockierungsfrei: Jeder Knoten kann gleichzeitig mit jedem anderen Knoten bei voller Leitungsgeschwindigkeit sprechen.

Das Überbuchungsverhältnis ist die Stellschraube, die über die Kosten entscheidet. Hat jedes Leaf 32 Downlinks mit 100 GbE (3.2 Tb/s ins Rack) und 8 Uplinks mit 100 GbE (800 Gb/s aus dem Rack heraus), beträgt die Überbuchung 4:1 — viermal so viel Bandbreite ins Rack hinein wie heraus. Volle Bisection bedeutet 1:1: so viel Uplink wie Downlink. 2:1 ist in Allzweck-Rechenzentren üblich. 1:1 (volle Bisection) ist der Standard für KI-Cluster.

Die Kosten verdoppeln sich beim Schritt von 4:1 auf 1:1 ungefähr, weil Sie doppelt so viele Spine-Ports und doppelt so viel Optik kaufen. Der Grund, warum jedes ernsthafte KI-Cluster diesen Aufpreis zahlt: Überbuchung zerstört den Allreduce-Durchsatz. Ein synchronisiertes Allreduce mit 8 Flows läuft auf einem 4:1 überbuchten Fabric nicht mit einem Viertel der Geschwindigkeit — es bricht unter PFC-Gegendruck zusammen (N07) und verliert in der Praxis 60–80 % des theoretischen Durchsatzes. Die Rechnung sagt „durch 4 teilen“. Die Realität sagt „durch 5 bis 10 teilen“.

Die DGX-SuperPOD-Referenzarchitektur von NVIDIA schreibt einen dreistufigen Fat-Tree mit voller Bisection auf Quantum-2 NDR InfiniBand mit 400 Gb/s pro Port vor. Die von Meta veröffentlichten RoCE-Trainingscluster und Microsofts Azure ND-Serie bauen dieselbe Form auf Spectrum-X-Ethernet. Die Branche hat sich für KI-Training auf den Fat-Tree mit voller Bisection geeinigt, und die Entwicklung 2024–2026 macht den Fat-Tree breiter (400 GbE → 800 GbE pro Port) oder Rail-optimiert (nächster Abschnitt) — sie ändert nicht die grundlegende Topologie.

Rail-optimierter Fat-Tree — der KI-spezifische Dialekt

Der Standard-Fat-Tree behandelt jede NIC gleich. Beim KI-Training kommt es darauf an, welche GPU-NIC welchen Gradienten sendet, denn Allreduce-Verkehrsmuster sind nicht gleichförmig. Die Rail-optimierte Variante ordnet jede GPU eines Knotens einer bestimmten „Rail“ zu — einem dedizierten Leaf-Spine-Pfad — und stellt sicher, dass die i-te GPU jedes Knotens nur über die i-te Rail mit der i-ten GPU jedes anderen Knotens spricht.

Rail-optimierter Fat-Tree: Jeder GPU-Slot wird auf eine eigene, unabhängige Spine-Ebene abgebildet. Der Allreduce-Ring auf GPU 3 nutzt ausschließlich Rail 3.

Acht unabhängige zweistufige Fat-Trees, einer pro GPU-Slot. Der Allreduce-Ring auf GPU 3 über 16 Knoten nutzt ausschließlich Rail 3 und wechselt nie in andere Rails. Vorteile: keine ECMP-Kollisionen zwischen den Rails, einfacheres Routing, geringerer Switch-Radix pro Ebene. Der Haken: Ein Job, der sich über GPU-Slots erstreckt (Tensor-parallel innerhalb eines Knotens, Daten-parallel über Knoten hinweg), wird von NCCL ohnehin auf mehrere Rails verteilt — die Topologie hilft also nur, wenn der Workload dazu passt. Für Daten-Parallelität und Rail-bewusstes NCCL ist sie ein klarer Gewinn; bei Tensor-Parallelität über Rails hinweg verpufft der Vorteil.

Dragonfly und Dragonfly+ — wenn der Fat-Tree zu teuer wird

Die Kosten eines Fat-Trees wachsen ungefähr mit N log N — jede Verdopplung der Knotenzahl verlangt mehr Spine-Bandbreite, und die dritte Stufe verdoppelt die Switch-Anzahl pro Endpunkt. Für 1024 Knoten lässt sich ein blockierungsfreier dreistufiger Fat-Tree noch bauen. Bei 10,000 Knoten werden Switch-Anzahl und Optik-Kosten erdrückend. Dragonfly, 2008 von John Kim, William Dally und anderen vorgeschlagen, wurde genau dafür entworfen, diese Wand zu überwinden.

Die Idee: Knoten zu Gruppen zusammenfassen. Innerhalb einer Gruppe sind alle Switches dicht vernetzt (oft ein kleineres Clos). Zwischen den Gruppen besitzt jede Gruppe eine direkte Verbindung zu jeder anderen. Das Ergebnis ist ein Netzwerk mit Durchmesser 3 (gruppeninterner Hop, Hop zwischen Gruppen, gruppeninterner Hop), das auf enorme Knotenzahlen skaliert — mit weit weniger Langstreckenkabeln als ein Fat-Tree.

Dragonfly: dichtes Clos innerhalb der Gruppe, ein globaler Link je Gruppenpaar. Durchmesser 3. Skaliert auf 1000+ Knoten mit weniger Langstreckenkabeln als ein Fat-Tree.

Die große Ersparnis liegt bei der optischen Verkabelung. Langstrecken-Optik zwischen Racks ist der teuerste Teil eines Fat-Trees. Dragonfly ersetzt sie durch eine dicke Verbindung je Gruppenpaar statt einer je Leaf-Spine-Kombination. Für ein Cluster mit G Gruppen zu je S Knoten braucht ein Fat-Tree rund G × S × log(G × S) Kabel; Dragonfly braucht G(G − 1)/2 Kabel zwischen den Gruppen plus das Fabric innerhalb jeder Gruppe. Bei G = 32 Gruppen zu je 32 Knoten (1024 insgesamt) sinkt die Zahl der Langstreckenkabel um rund eine Größenordnung.

Dragonfly+ (Mellanox, 2017) verfeinert das für InfiniBand. Das gruppeninterne Fabric wird zu einem kleinen bipartiten Clos, sodass eine Gruppenerweiterung keine Neuverkabelung erfordert, und die Links zwischen den Gruppen nutzen adaptives Routing, um überlasteten Gruppen auszuweichen. Das ist die Topologie von Frontier (ORNL, Exascale, AMD MI250X) und El Capitan (LLNL, MI300A) — beide mit HPE-Slingshot-11-Switches in Dragonfly-Anordnung verkabelt, maximaler Durchmesser drei Hops, 12.8 Tb/s pro Switch.

Der Haken ist das Fehlerverhalten bei kleinen Jobs, die sich über Gruppen erstrecken. In einem Fat-Tree sehen zwei Knoten an entgegengesetzten Enden des Clusters dieselbe Bisection-Bandbreite wie zwei Knoten, die nur ein Rack voneinander entfernt stehen (abgesehen von der Hop-Zahl). In einem Dragonfly teilen sich zwei Knoten in verschiedenen Gruppen ihren Link zwischen den Gruppen mit jedem anderen gruppenübergreifenden Flow. Landet Ihr Trainingsjob mit 16 GPUs auf 8 Knoten in Gruppe A und 8 Knoten in Gruppe B, teilen Sie sich diesen einen Link mit allen anderen, die dasselbe Gruppenpaar überspannen. Adaptives Routing hilft; es beseitigt die Konkurrenz nicht.

Praktische Konsequenz: Dragonfly funktioniert bei Hyperscaler-Größenordnungen hervorragend (1000+ Knoten, Jobs, die ganze Gruppen füllen) und bei mittelgroßen Clustern mit vielen kleinen, unterschiedlichen Jobs eher schlecht. Für ein Trainings-Cluster mit 16 Knoten ist es die falsche Topologie — in dieser Größenordnung ist der Fat-Tree günstiger und schneller. Für einen Supercomputer mit 1024 Knoten und gemischten Workloads ist es die richtige.

Tesserakt — der 4D-Hyperwürfel

Ein Tesserakt ist ein 4D-Hyperwürfel: 16 Ecken, jede mit genau 4 Nachbarn verbunden, Durchmesser 4 (der längste kürzeste Pfad zwischen zwei beliebigen Knoten). Verallgemeinert auf k Dimensionen ergibt sich ein k-Würfel: 2^k Knoten, jeder mit k direkten Links, Durchmesser k. Routing über die Hamming-Distanz — Quell- und Zieladresse per XOR verknüpfen und jeweils ein Bit kippen — ist trivial deterministisch und bei zufälligem Verkehr von selbst lastverteilt.

Tesserakt (4D-Hyperwürfel): 16 Knoten mit je 4 Nachbarn. Durchgezogene Linien = Kanten des 3D-Würfels; gestrichelte Linien = Verbindungen der 4. Dimension. Durchmesser 4. Jede Knotenbeschriftung ist eine 4-Bit-Adresse; benachbarte Knoten unterscheiden sich in genau einem Bit.

Hyperwürfel-Topologien dominierten das massiv parallele Rechnen der 1980er-Jahre. Die Connection Machine CM-2 (Thinking Machines, 1987) bestand aus 65,536 Knoten, verkabelt als 12-dimensionaler Hyperwürfel. Intel iPSC/2 arbeitete mit 7D-Hyperwürfeln. Die CM-5 (Thinking Machines, 1991) gab den Hyperwürfel zugunsten des Fat-Trees auf, weil der Ansatz jenseits von rund 1024 Knoten nicht mehr elegant skalierte — jede neue Dimension verdoppelt die Knotenzahl und erfordert eine Neuverkabelung jedes bestehenden Knotens.

2026 taucht der Begriff „Tesseract“ noch an drei Stellen auf, die man auseinanderhalten sollte:

1. Als Name eines Forschungs- bzw. DiRAC-HPC-Systems. Der DiRAC Tesseract am EPCC (Edinburgh) ist ein HPE-SGI-8600-Cluster mit 1476 Knoten auf Intel Omni-Path. „Tesseract“ ist Branding; das Fabric ähnelt eher einem Fat-Tree.
2. Als Forschungsbegriff rund um die „SDN Control Plane“ (Tesseract: a 4D control plane, Yan et al.). Ohne Bezug zur physischen Topologie.
3. Als zugrunde liegende Topologie kompakter, switchloser Beschleuniger-Cluster. Ein Cluster aus 16 Knoten, das buchstäblich als 4D-Hyperwürfel verkabelt ist, hat interessante Eigenschaften: Jeder Knoten besitzt genau 4 NICs, es gibt keinen zentralen Switch, das Routing ist deterministisch, der Durchmesser beträgt 4. Ausführlich behandeln wir das in N05 (switchlose Topologien).

Was ein Tesserakt 2026 bietet: keine Switch-Kosten, deterministisches Routing über XOR der Hamming-Distanz und einen kleinen Durchmesser (log₂(N)). Was ihn schwierig macht: festes N (muss eine Zweierpotenz sein), die Verkabelungskomplexität wächst mit der Dimension, die Zahl der NICs pro Knoten entspricht k — und moderne KI-Kollektive (NCCL Ring/Tree) nutzen die Hyperwürfel-Struktur nicht nativ aus.

Torus — der Überlebende in zwei speziellen Nischen

Der k-äre n-Würfel verallgemeinert den Hyperwürfel: statt einer Binäradresse mit einem Link pro Dimension ein Gitter der Form k×k×k mit Umlauf. In einem 3D-Torus ist jeder Knoten mit 6 Nachbarn verbunden (±x, ±y, ±z). Ein 6D-Torus hat 12 Nachbarn.

IBM Blue Gene/L und /P liefen auf einem 3D-Torus und skalierten auf Hunderttausende Knoten, wobei jeder Knoten nur 6 Hochgeschwindigkeits-Links besaß. Fujitsu Tofu (der Interconnect des K computer, 2011) verallgemeinerte das zu einem 6D-Mesh/Torus — 158,976 Knoten in Fugaku (bis 2026 in Betrieb), angeordnet als 24×23×24×2×3×2.

Cerebras Wafer-Scale Engine nutzt einen 2D-Torus auf dem Wafer: Jedes Rechenelement hat 4 Nachbarn, mit Umlauf, ~1 ns pro Hop. Das funktioniert, weil Leiterbahnen auf dem Wafer nahezu kostenlos sind; Kabel außerhalb des Wafers wären es nicht.

Warum der Torus überall sonst verloren hat: asymmetrische Pfade und schlechtes Verhalten bei ungleichmäßigen KI-Workloads. Moderne KI-Workloads (NCCL Ring/Tree, die hierarchischen Algorithmen von NVIDIA) setzen ein bandbreiten-uniformes Any-to-any voraus. Der Torus verletzt genau das. 2026 überlebt der Torus an drei Stellen: im On-Wafer-Interconnect von Cerebras, in Fujitsus Fugaku und dessen Nachfolgern sowie innerhalb von SXM-Knoten über NVSwitch. Außerhalb dieser Nischen ist jedes neue KI-Cluster der Jahre 2025–2026 ein Clos.

Vergleichstabelle

Cluster-Uplink — wie die Topologie auf die Außenwelt trifft

Ein geswitchtes Fabric ist eine Insel. Es muss an das Unternehmensnetz angebunden werden (Modell-Registries, Datensatz-Speicher, S3, Telemetrie), an die Workstations der Entwickler (SSH, Jupyter, Herauskopieren von Checkpoints) und an andere Cluster (Übergabe vom Training an die Inferenz). Diese Verbindung ist der Cluster-Uplink.

Zwei Modelle mit sehr unterschiedlichen Folgen:

Einzelner Uplink-Punkt. Ein Paar Spine-Switches (oder ein dedizierter Uplink-Router) terminiert die gesamte externe Anbindung. Einfach abzusichern, einfach zu drosseln, einfach zu überwachen. Fehlerbild: Dieser Link ist ein Single Point of Failure; wird er ausgelastet (ein großer Checkpoint-Export, das Ziehen eines 10 GB großen Datensatz-Shards), trifft das alle Knoten gleichzeitig.

Verteilter Uplink. Jedes Leaf hat einen eigenen Uplink ins Campus-Netz, oft langsamere 25 GbE zusätzlich zum 100-GbE-Fabric. Datensatz-Downloads und externer Verkehr bleiben lokal am Leaf — keine Überlast im internen Fabric. Fehlerbild: Jedes Leaf ist eine Sicherheitsgrenze, die Firewall-Arbeit vervielfacht sich, und die Überwachung wird schwieriger.

Für den Kentino-Standardfall (Trainings-Cluster mit 4–16 Knoten) ist der einzelne Uplink-Punkt die richtige Antwort. Das interne Fabric ist reines RDMA (RoCE oder InfiniBand), abgestimmt auf niedrige Latenz und verlustfreien Betrieb. Der Uplink ist schlichtes Ethernet, TCP, normales QoS. Betreiben Sie niemals den Objektspeicher für Datensätze im selben verlustfreien Fabric wie das GPU-Allreduce — ein fehlerhaft arbeitender S3-Client darf nicht in der Lage sein, PFC-Gegendruck auf den Trainingsverkehr auszulösen. Zwei Fabrics: die Datenebene (verlustfreies RDMA) und die Management-/Uplink-Ebene (verlustbehaftetes TCP). N08 behandelt die praktische Einrichtung.

Die ehrliche Kentino-Einschätzung

Die meisten Kentino-Kunden kaufen 1 bis 4 Knoten. In dieser Größenordnung gilt:

• 1 Knoten. Keine Topologiefrage. PCIe im Gehäuse (K07), eine 25-GbE-Management-NIC nach außen, fertig.
• 2 Knoten. Ein Direktkabel zwischen zwei RDMA-NICs. Kein Switch. Keine Topologie zu wählen.
• 3–4 Knoten. Ein einzelner 100-GbE-Switch mit 32 Ports bedient jeden mit jedem bei voller Bisection, für $30k–50k komplett. Immer noch keine Topologie zu wählen.

Die Topologie-Diskussion beginnt bei 8 Knoten, wenn die Portzahl eines einzelnen Switches knapp wird, und wird spätestens bei 16 Knoten unvermeidlich. Darunter lautet die richtige Antwort: „ein guter Switch, volle Bisection auf jedem Port, und weiter im Programm.“ Darüber lautet sie: „zweistufiges Leaf-Spine, 100 oder 200 GbE pro Knoten, volle Bisection (1:1) — und fassen Sie die Überbuchungs-Stellschraube nur an, wenn Sie jemand dazu zwingt.“

Dragonfly+ ist die richtige Antwort bei Hyperscaler-Größenordnungen. Tesserakt bzw. Hyperwürfel ist als switchlose Option für kompakte Cluster interessant (N05). Der Torus ist eine herstellergebundene Wahl für HPC-Betreiber mit topologiebewussten Workloads. Für alle anderen in der Kentino-Preisklasse ist der Fat-Tree der Standard. Volle Bisection, wenn das Budget es zulässt; 2:1, wenn nicht; niemals 4:1 für KI-Training.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Computing, Robotik und den Systemen, die beides verbinden. Kommentare und Korrekturen gerne an info@kentino.com.