Netzwerktopologie-Design für GPU-Cluster: Fat-Tree-, Dragonfly- und Rail-optimierte Architekturen

Aktualisiert am 11. Dezember 2025

Update Dezember 2025: DGX SuperPOD spezifiziert dreistufigen Fat-Tree mit Quantum-2 InfiniBand (400 Gb/s). Meta-Studie stellt fest, dass Netzwerkkonfigurationsfehler 10,7% der signifikanten GPU-Job-Ausfälle verursachen. Volle Bisektionsbandbreite ist entscheidend für verteiltes Training, bei dem sich Kommunikationsmuster dynamisch ändern. Google TPU Pods verwenden 3D-Torus; AWS Trainium verwendet workload-optimierte Topologien.

NVIDIAs DGX SuperPOD-Referenzarchitektur spezifiziert eine dreistufige Fat-Tree-Netzwerktopologie, die bis zu 32 DGX-Systeme über Quantum-2 InfiniBand-Switches mit 400 Gb/s pro Port verbindet.[^1] Die Architektur liefert volle Bisektionsbandbreite, was bedeutet, dass die aggregierte Bandbreite zwischen zwei beliebigen Hälften des Clusters der Gesamtbandbreite in jede Hälfte entspricht. Fat-Tree-Topologien dominieren GPU-Cluster-Implementierungen, da sie vorhersehbare Leistung bieten, unabhängig davon, welche GPU-Paare kommunizieren – eine kritische Eigenschaft für verteiltes Training, bei dem sich Kommunikationsmuster dynamisch ändern.

Netzwerktopologie-Entscheidungen beeinflussen direkt die Trainingsleistung, Kosten und betriebliche Komplexität. Eine Meta-Studie ergab, dass Netzwerkkonfigurationsfehler 10,7% der signifikanten Job-Ausfälle in ihren GPU-Clustern verursachten, wobei topologieabhängige Überlastung zur Leistungsvariabilität beitrug.[^2] Googles TPU Pods verwenden 3D-Torus-Topologien, die direkte Verbindungen zwischen benachbarten Beschleunigern ermöglichen, während AWS Trainium-Cluster unterschiedliche Topologien einsetzen, die für ihre Workload-Muster optimiert sind.[^3] Das Verständnis der Topologie-Kompromisse ermöglicht es Organisationen, Architekturen auszuwählen, die ihren spezifischen Workload-Anforderungen und Budgetbeschränkungen entsprechen.

Grundlagen der Fat-Tree-Topologie

Die Fat-Tree-Topologie stammt aus Charles Leisersons Arbeit von 1985, die zeigte, dass Baumstrukturen volle Bisektionsbandbreite erreichen können, wenn die Verbindungskapazität zur Wurzel hin zunimmt.[^4] Moderne Implementierungen verwenden durchgehend Verbindungen gleicher Kapazität und erreichen volle Bandbreite durch mehrere parallele Pfade anstelle dickerer Verbindungen.

Dreistufige Fat-Tree-Architektur

Ein dreistufiger Fat-Tree besteht aus Leaf-Switches, die mit Servern verbunden sind, Spine-Switches, die den Leaf-Verkehr aggregieren, und Core-Switches, die volle Konnektivität zwischen Spines bieten.[^5] Jeder Leaf-Switch ist mit jedem Spine-Switch verbunden, und jeder Spine ist mit jedem Core-Switch verbunden. Das Netzwerk aus Verbindungen schafft mehrere gleichwertige Pfade zwischen zwei beliebigen Servern.

NVIDIA empfiehlt Fat-Tree für DGX-Cluster aufgrund vorhersehbarer Latenz- und Bandbreiteneigenschaften.[^6] Die Topologie stellt sicher, dass kollektive Operationen wie All-Reduce konsistente Leistung unabhängig von der GPU-Platzierung erfahren. Training-Jobs müssen bei der Planung die Netzwerktopologie nicht berücksichtigen, was das Cluster-Management vereinfacht.

Überzeichnungsverhältnisse

Volle Bisektionsbandbreite erfordert teure Switch-Kapazität in den oberen Ebenen. Viele Implementierungen akzeptieren Überzeichnung, bei der die aggregierte Uplink-Bandbreite von unteren Ebenen die verfügbare Kapazität in oberen Ebenen übersteigt.[^7] Ein Überzeichnungsverhältnis von 2:1 bedeutet, dass nur die Hälfte des Verkehrs gleichzeitig die oberen Ebenen durchqueren könnte.

Überzeichnung eignet sich für Workloads mit Lokalität, bei denen die meiste Kommunikation innerhalb von Racks oder Pods stattfindet. Allerdings sättigt verteiltes Training mit All-to-All-Kommunikationsmustern überzeichnete Verbindungen, was Überlastung und Leistungseinbußen verursacht. KI-Trainingscluster erfordern typischerweise nicht überzeichnete Designs trotz höherer Kosten.[^8]

Radix und Skalierung

Der Switch-Radix bestimmt, wie viele Ports jeder Switch bietet, was sowohl Skalierung als auch Kosten beeinflusst. Ein 64-Port-Switch, der einen dreistufigen Fat-Tree mit 32 Downlinks und 32 Uplinks aufbaut, skaliert auf 32.768 Endpunkte.[^9] Switches mit höherem Radix reduzieren die Anzahl der benötigten Switches, erhöhen aber die Kosten pro Switch.

NVIDIAs Quantum-2-Switches bieten 64 Ports bei 400 Gb/s und ermöglichen groß angelegte Fat-Tree-Implementierungen mit angemessener Switch-Anzahl.[^10] Die kommende Quantum-X800-Generation erhöht die Port-Geschwindigkeiten auf 800 Gb/s und verdoppelt die aggregierte Bandbreite ohne Änderung der Topologiestruktur.

Rail-optimierte Topologie

Die Rail-optimierte Topologie entstand aus der Erkenntnis, dass GPU-Server mehrere GPUs enthalten, die sich schnelle interne Interconnects teilen. Anstatt jede GPU unabhängig zu behandeln, richten Rail-optimierte Designs die Netzwerkverbindungen an der GPU-Platzierung innerhalb der Server aus.[^11]

Verständnis der GPU-Rails

Ein DGX H100-System enthält acht GPUs, die über NVLink verbunden sind, wobei jede GPU auch mit einer Netzwerkschnittstellenkarte (NIC) verbunden ist.[^12] Die acht NICs entsprechen acht „Rails", die sich über den Cluster erstrecken. Rail 0 verbindet GPU 0 von jedem Server, Rail 1 verbindet GPU 1 und so weiter. Kommunikation innerhalb eines Rails durchquert weniger Switch-Hops als Rail-übergreifende Kommunikation.

NVIDIA NVLink Switch verbindet GPUs innerhalb und über Server hinweg mit 900 GB/s aggregierter Bandbreite pro GPU.[^13] Die NVLink-Domäne wickelt die meiste GPU-zu-GPU-Kommunikation ab, wobei das InfiniBand-Netzwerk die Kommunikation zwischen NVLink-Domänen übernimmt. Rail-optimierte Topologie richtet InfiniBand-Pfade an NVLink-Domänen aus, um den InfiniBand-Verkehr zu minimieren.

Implementierungsaspekte

Rail-optimierte Implementierungen erfordern sorgfältige Verkabelung, um die Rail-Ausrichtung über Racks und Pods hinweg aufrechtzuerhalten.[^14] Falsch verdrahtete Verbindungen brechen die Rail-Lokalität und zwingen den Verkehr durch zusätzliche Switch-Hops. Disziplin im Kabelmanagement ist essenziell, um die Vorteile der Rail-Optimierung zu realisieren.

Die Topologie reduziert den Switch-Bedarf im Vergleich zu einem vollen Fat-Tree bei gleichwertiger Skalierung. Einsparungen entstehen durch die Eliminierung von Rail-übergreifender Switching-Kapazität, die Rail-optimierte Workloads selten nutzen.[^15] Organisationen müssen überprüfen, ob ihre Workload-Muster tatsächlich Rail-Lokalität aufweisen, bevor sie sich für Rail-optimierte Designs entscheiden.

Dragonfly-Topologie

Die Dragonfly-Topologie organisiert Switches in Gruppen mit dichter Konnektivität innerhalb der Gruppe und spärlichen Verbindungen zwischen Gruppen.[^16] Das Design reduziert die Switch-Anzahl im Vergleich zu Fat-Tree bei gleichzeitiger Aufrechterhaltung angemessener Pfadlängen zwischen zwei beliebigen Endpunkten.

Dragonfly-Struktur

Ein Dragonfly besteht aus Gruppen, die jeweils mehrere Switches enthalten, die innerhalb der Gruppe vollständig verbunden sind. Globale Links verbinden jeden Switch mit Switches in anderen Gruppen.[^17] Zwei beliebige Endpunkte verbinden sich über höchstens drei Hops: lokaler Switch zu Gruppen-Switch zu Remote-Gruppen-Switch zu Ziel.

Die reduzierte Hop-Anzahl senkt die Latenz für groß angelegte Implementierungen. Weniger Switches reduzieren Kapitalkosten und Stromverbrauch. Allerdings bietet Dragonfly niedrigere Bisektionsbandbreite als Fat-Tree, was es anfälliger für Überlastung unter bestimmten Verkehrsmustern macht.[^18]

Anforderungen an adaptives Routing

Die Dragonfly-Leistung hängt stark von adaptivem Routing ab, das den Verkehr über verfügbare Pfade verteilt.[^19] Statisches Routing konzentriert den Verkehr auf bestimmte Links und verursacht Überlastung, während andere Pfade unterausgelastet bleiben. Switches müssen die Link-Auslastung überwachen und den Verkehr dynamisch auf weniger belastete Pfade verschieben.

NVIDIA InfiniBand unterstützt adaptives Routing, das für Dragonfly-Implementierungen geeignet ist.[^20] Die Fähigkeit erfordert Konfiguration und Tests, um sicherzustellen, dass Routing-Algorithmen angemessen auf Workload-Verkehrsmuster reagieren. Falsch konfiguriertes adaptives Routing kann schlechter funktionieren als statisches Routing.

Workload-Sensitivität

Dragonfly eignet sich für Workloads mit lokalisierten Kommunikationsmustern, die den meisten Verkehr innerhalb von Gruppen halten.[^21] Workloads, die gleichmäßig zufälligen Verkehr über alle Endpunkte generieren, belasten die Verbindungen zwischen Gruppen über ihre Kapazität hinaus. Die Topologie funktioniert gut für Inferenz-Serving mit Request-Affinität, kann aber bei groß angelegtem Training mit globalen Collectives Schwierigkeiten haben.

Organisationen, die Dragonfly evaluieren, sollten erwartete Workload-Kommunikationsmuster vor der Implementierung charakterisieren. Simulationswerkzeuge können die erwartete Leistung unter realistischem Verkehr modellieren und potenzielle Überlastungspunkte identifizieren, die Topologieanpassungen erfordern.[^22]

Torus- und Mesh-Topologien

Torus-Topologien verbinden Knoten in regelmäßigen Gittermustern mit Wraparound-Verbindungen an den Grenzen. Googles TPU Pods verwenden 3D-Torus-Topologien, die direkte Nachbarverbindungen ohne Switching bieten.[^23]

Direkte versus geswitchte Netzwerke

Torus-Netzwerke verbinden jeden Knoten direkt mit Nachbarn und eliminieren Switches aus dem Kommunikationspfad.[^24] Die direkte Verbindung reduziert die Latenz für Nachbar-zu-Nachbar-Kommunikation, die in vielen parallelen Algorithmen üblich ist. Allerdings durchquert die Kommunikation zwischen entfernten Knoten mehrere Zwischenknoten, was die Latenz erhöht und Bandbreite an jedem Hop verbraucht.

Geswitchte Netzwerke wie Fat-Tree bieten gleiche Latenz zwischen zwei beliebigen Endpunkten unabhängig von der physischen Platzierung. Die Gleichförmigkeit vereinfacht Programmierung und Lastverteilung. Torus-Netzwerke erfordern topologiebewusste Platzierung, um Kommunikationsentfernungen zu minimieren.[^25]

Dimensionsauswahl

Höherdimensionale Torus-Topologien reduzieren den Durchmesser (maximale Hop-Anzahl) auf Kosten einer erhöhten Verbindungsanzahl pro Knoten.[^26] Ein 3D-Torus mit N Knoten pro Dimension hat einen Durchmesser von 3N/2, während ein 2D-Torus einen Durchmesser von N hat. Googles Wahl eines 3D-Torus balanciert Verbindungsanzahl gegen Durchmesser.

Physische Einschränkungen beeinflussen die Dimensionsauswahl. Ein 2D-Torus lässt sich natürlich auf Zeilen und Spalten in einem Maschinenraum abbilden. Ein 3D-Torus erfordert entweder gestapelte Racks oder Verbindungen, die erhebliche Entfernungen überbrücken. Kabellängen in hochdimensionalen Torus können bei großer Skalierung problematisch werden.[^27]

Rahmenwerk zur Topologieauswahl

Die Auswahl der Netzwerktopologie erfordert die Bewertung von Workload-Charakteristiken, Skalierungsanforderungen, Budgetbeschränkungen und betrieblichen Fähigkeiten.

Workload-Analyse

Verschiedene Workloads belasten Netzwerke unterschiedlich. Das Training großer Sprachmodelle erzeugt All-to-All-Kommunikationsmuster, die hohe Bisektionsbandbreite erfordern.[^28] Inferenz-Serving mit Batching zeigt lokalisiertere Kommunikation innerhalb von GPU-Gruppen, die Anfragen bedienen. Datenvorverarbeitung kann Shuffle-Muster mit zufälliger Kommunikation erzeugen.

Organisationen sollten erwartete Workloads profilieren, um Kommunikationsmuster zu verstehen. Produktions-Cluster-Monitoring enthüllt tatsächliche Verkehrsmuster für bestehende Workloads. Neue Workload-Typen können Schätzungen basierend auf Algorithmusanalyse oder Herstellerberatung erfordern.

Skalierungsaspekte

Kleine Cluster mit Dutzenden von GPUs erfordern möglicherweise keine ausgefeilte Topologieoptimierung. Ein einzelner High-Radix-Switch, der alle GPUs verbindet, bietet volle Konnektivität ohne mehrstufige Komplexität.[^29] Die Topologieauswahl ist am wichtigsten für Cluster, die Hunderte bis Tausende von GPUs umfassen, wo Switching-Kosten und Kabelwege signifikant werden.

Zukünftiges Wachstum beeinflusst die Topologieauswahl. Ein Fat-Tree skaliert durch Hinzufügen von Leaf-Switches und Servern bei gleichzeitiger Aufrechterhaltung der vollen Bisektionsbandbreite. Ein Dragonfly skaliert durch Hinzufügen von Gruppen, erfordert aber möglicherweise eine Neuausbalancierung globaler Links. Wachstumsplanung vermeidet Topologieänderungen, die den Betrieb stören.[^30]

Wirtschaftliche Faktoren

Switch- und Kabelkosten variieren erheblich zwischen Topologien. Fat-Tree erfordert mehr Switches als Dragonfly bei gleichwertiger Skalierung. Rail-optimierte Designs reduzieren InfiniBand-Switching, erfordern aber NVLink-Switch-Systeme.[^31] Die Gesamtkostenanalyse muss Switches, Kabel, Optiken, Strom, Kühlung und Rack-Platz einbeziehen.

Auch die Betriebskosten variieren. Komplexe Topologien erfordern ausgereiftere Überwachungs- und Fehlerbehebungsfähigkeiten. Die Schulung des Betriebspersonals zu topologiespezifischen Überlegungen erhöht die Kosten. Einfachere Topologien können bescheidene Leistungskompromisse durch reduzierten Betriebsaufwand rechtfertigen.

Implementierung und Bereitstellung

Die Implementierung der Netzwerktopologie erfordert sorgfältige Planung, die physische Infrastruktur, Switching-Konfiguration und Validierungstests umfasst.

Planung der physischen Infrastruktur

High-Speed-Netzwerkimplementierungen erfordern strukturierte Verkabelung, die Tausende von Verbindungen bei 400 Gb/s oder höher unterstützt.[^32] Die Kabelführung muss Biegeradiusverletzungen und Signaldegradation minimieren. Hot-Aisle/Cold-Aisle-Anordnungen müssen Kabelpfade berücksichtigen, ohne

[Inhalt für Übersetzung gekürzt]