Rail-optimized Topology

Rail-optimized Topology ist die Standardverkabelung für GPU-Cluster: Jede GPU eines Servers hängt an einem eigenen Leaf-Switch, dem Rail.

Ausgangslage

Ein KI-Trainingsserver enthält typischerweise acht GPUs, die intern über eine Scale-up-Verbindung (NVLink, Infinity Fabric) gekoppelt sind, und für das Scale-out-Netz acht Netzwerkkarten mit je 400 oder 800 Gb/s – eine pro GPU. Im klassischen Rechenzentrumsdesign würden alle acht NICs eines Servers an denselben Top-of-Rack-Switch gehen. Für verteiltes Training ist das ungünstig, weil der dominierende Verkehr nicht zwischen beliebigen Servern läuft, sondern zwischen GPUs mit derselben Position in verschiedenen Servern.

Grund dafür ist die Arbeitsweise der Kollektivoperationen (All-Reduce, All-Gather, Reduce-Scatter): Bibliotheken wie NCCL bilden Ringe oder Bäume, in denen GPU n eines Servers vorzugsweise mit GPU n der Nachbarserver kommuniziert. Der Verkehr ist also nach GPU-Index sortiert.

Aufbau

In einer Rail-optimized Topology wird diese Sortierung auf die Verkabelung übertragen. Ein Cluster aus k Servern mit je acht GPUs erhält acht Leaf-Switches. NIC 0 aller Server geht an Leaf 0, NIC 1 aller Server an Leaf 1 und so weiter. Jeder Leaf-Switch bildet mit den an ihm hängenden GPUs einen Rail.

Verkehr zwischen GPU n zweier Server bleibt damit innerhalb des Rails und benötigt nur einen Switch-Hop. Erst wenn GPUs unterschiedlicher Rails kommunizieren müssen, geht der Verkehr über die Spine-Ebene, die alle Leaf-Switches als Fat-Tree verbindet.

Die Größe eines Rails ist durch die Portzahl des Leaf-Switches begrenzt. Bei 64 Ports, hälftig auf Server und Spine verteilt, ergibt sich eine Einheit aus 32 Servern mit 256 GPUs; NVIDIA nennt diese Einheit Scalable Unit (SU). Größere Cluster entstehen durch mehrere SUs, die über die Spine-Ebene (bei sehr großen Systemen über eine dritte Stufe) gekoppelt werden.

Rail-lokaler Verkehr und PXN

Der Anteil des Verkehrs, der im Rail bleibt, lässt sich softwareseitig erhöhen. NCCL nutzt dafür PXN (PCIe × NVLink): Muss GPU 3 eines Servers Daten an GPU 5 eines anderen Servers senden, kopiert sie diese zunächst über NVLink an die lokale GPU 5, die sie dann über Rail 5 verschickt. Der Umweg über den schnelleren Scale-up-Pfad ersetzt den Spine-Hop. Mit diesem Verfahren läuft der Großteil des Trainingsverkehrs über die Leaf-Ebene, und die Spine-Ebene kann schwächer dimensioniert werden als in einem vollständig blockierungsfreien Fat-Tree.

Rail-only

Die Konsequenz dieses Ansatzes ist ein Design ohne Spine-Ebene: Rails sind untereinander gar nicht verbunden, jeder Verkehr zwischen Rails muss über NVLink umgeleitet werden. Wang et al. (2023) zeigen für Sprachmodell-Training, dass der Leistungsverlust gegenüber einem vollen Fat-Tree gering ist, während Switches und Optiken für die Spine-Ebene entfallen. Rail-only setzt allerdings voraus, dass die Kommunikationsmuster tatsächlich rail-lokal sind; für Inferenz-Cluster mit anderem Verkehr oder für gemischte Workloads ist das nicht gegeben.

Praxis

• NVIDIA DGX SuperPOD ist als Rail-optimized Fat-Tree über InfiniBand spezifiziert; die Reference Architecture beschreibt SU-Größen, Switch-Zuordnung und Verkabelung.
• Meta betreibt Trainingscluster mit 24.576 GPUs über RoCEv2 in Rail-optimized-Topologie: Rail-Switches auf Leaf-Ebene, darüber Cluster-Switches, gruppiert in AI Zones.
• Die Topologie ist unabhängig vom Transport und funktioniert mit InfiniBand, RoCEv2 und Ultra Ethernet gleichermaßen.

Nachteile

• Verkabelung: Jeder Server ist mit acht verschiedenen Switches verbunden, die nicht im selben Rack stehen können. Die Kabellängen steigen, DAC scheidet meist aus, AOC oder Transceiver werden nötig.
• Ausfalldomäne: Fällt ein Leaf-Switch aus, verliert jeder Server der SU eine GPU-Anbindung. Kollektivoperationen über den betroffenen Rail müssen umgeleitet werden.
• Spine-Dimensionierung: Wie stark die Spine-Ebene unterbucht werden darf, hängt vom Workload ab und ist beim Bau schwer vorherzusagen.
• Abhängigkeit von der Software: Der Nutzen entsteht nur, wenn die Kommunikationsbibliothek die Topologie kennt und ausnutzt.

Normen und Quellen

• NVIDIA: DGX SuperPOD Reference Architecture (Versionen für DGX H100 und DGX GB200), docs.nvidia.com
• NVIDIA: NCCL Documentation, Abschnitt PXN, docs.nvidia.com/deeplearning/nccl
• Gangidi et al.: RDMA over Ethernet for Distributed AI Training at Meta Scale, SIGCOMM 2024
• Wang et al.: How to Build Low-cost Networks for Large Language Models (without Sacrificing Performance)?, arXiv 2307.12169 (2023)
• Al-Fares et al.: A Scalable, Commodity Data Center Network Architecture, SIGCOMM 2008 (Fat-Tree)