AI-Fabric-Topologien: Rail-optimierte Designs bis 16K GPUs
Passen Sie die Topologie an die GPU-Anzahl an: ein Rail-optimierter zweistufiger Leaf-Spine-Pod bis 4.096 GPUs, darüber eine dritte Super-Spine-Ebene bis zu 16.384 und kohärentes DCI zur Verbindung von Standorten. Wählen Sie das kleinste nicht-blockierende Design, das den Link jeder GPU während Collectives ausgelastet hält. Alle drei laufen auf OcNOS-DC über eine verlustfreie RoCEv2-(PFC + ECN)-L3-Fabric, hier dimensioniert in konkreten Portanzahlen auf Broadcom Tomahawk 4 und Tomahawk 5.
Das kleinste nicht-blockierende Design, das zu Ihrer GPU-Anzahl passt
Eine AI-Fabric-Topologie hat eine Aufgabe: den ausgehenden Link jeder GPU während eines Collectives ausgelastet zu halten, ohne Tail-Latency-Ausreißer zu erzeugen. Die richtige Topologie ist die kleinste, die dies für Ihre GPU-Anzahl leistet, mit einem Ausweichpfad für die nächste Größe. Drei Referenzpunkte mit konkreter Port-Rechnung auf Broadcom-Tomahawk-Silicon.
Ein zweistufiges Leaf-Spine erreicht 4.096 GPUs bei 800G pro GPU; ein Aufbau mit 1.024 GPUs umfasst 32 Leaves und 16 Spines, 48 Switches. Oberhalb von 4.096 GPUs fügen Sie die Super-Spine-Ebene hinzu. Dasselbe OcNOS-DC-Image läuft auf jeder Ebene, sodass die Fabric mit dem Cluster skaliert, statt bei jedem Schritt neu entworfen zu werden.
Dimensionieren Sie Ihr eigenes Cluster? Die AI Fabric Design Suite liefert eine schnelle erste Dimensionierung: Es dimensioniert einen nicht blockierenden zweistufigen Leaf-Spine-Pod und weist darauf hin, wenn Sie in den dreistufigen Maßstab übergehen. Die folgenden Referenzdesigns nutzen dieselbe nicht blockierende Leaf/Spine-Rechnung und fügen oberhalb von 4.096 GPUs eine Super-Spine-Ebene hinzu, sodass die Switch-Anzahlen mit dem Tool übereinstimmen. Rail-optimiert bezeichnet hier die Verkabelungsdisziplin eines GPU-Servers mit 8 NICs (ein Rail pro Leaf, sodass Intra-Rail-AllReduce auf dem Leaf bleibt), aufgesetzt auf diese nicht blockierende Fabric: Sie ändert die Traffic-Lokalität, nicht die Switch-Anzahl. Nutzen Sie das Tool für eine Größenordnung; nutzen Sie diese Designs für den Aufbau.
Zweistufiger Pod, dreistufige Fabric und kohärentes DCI
Drei Referenztopologien decken Single-Pod-, Multi-Pod- und Multi-Site-AI-Fabrics ab, jeweils dimensioniert auf Broadcom-Hardware aus der HCL.
Rail-optimierter Single-Pod
Bei jedem GPU-Server landen die 8 NICs auf 8 dedizierten Rail-Leaves, sodass Same-Rail-AllReduce auf einem Leaf bleibt und nie den Spine durchläuft. Ein nicht blockierender Spine trägt Cross-Rail-Flows. Die skalierbare Single-Pod-Einheit, bis zu 4.096 GPUs auf Tomahawk 5.
Dreistufige Rail-optimierte Fabric
Leaf, Spine und Super-Spine Ebenen führen die Fabric über 4.096 GPUs hinaus, auf 16.384 im Referenzdesign. Nicht blockierend innerhalb jedes Pods, wobei die Super-Spine-Plane das Cross-Pod-Verhältnis festlegt. DLB auf jedem Hop, GLB durchgängig in OcNOS 7.1.
Kohärentes Multi-DC-DCI
Wenn ein Trainingslauf mehrere Rechenzentrumshallen umfasst, erweitern Sie die Fabric mit 400G ZR / ZR+ kohärenter Optik auf dem Spine. Transponderloses DCI zwischen Standorten, bei unveränderter Fabric am Standort.
Rail-optimierter Single-Pod
Jeder GPU-Server verfügt über 8 NICs, eine pro Rail (ein dedizierter xCCL-Kollektivkanal (NCCL / RCCL / oneCCL)). Jedes Rail ist sein eigenes dediziertes Leaf, sodass alle 8 NICs jedes Servers auf einem anderen Leaf landen. AllReduce über Rail-N bleibt innerhalb von Leaf-N, sodass für das dominierende Kollektivmuster kein East-West-Druck auf dem Spine entsteht.

OcNOS-Komponenten: BGP-unnumbered L3-Underlay, RoCEv2 verlustfrei (PFC + ECN) auf jedem Leaf, DLB auf der Spine-Tier. Aufgebaut auf HCL-gelisteter Hardware: Die 800G-Skalierungseinheit nutzt TH5 64x800G Leaves und Spines (Edgecore AIS800-64D oder UfiSpace S9321-64E); der Einstiegs-Pod mit 256 GPUs nutzt Edgecore AS9736-64D (TH4, 64x400G).
Dreistufige Rail-optimierte Fabric: oberhalb von 4.096 GPUs
Ein zweistufiger Rail-optimierter Pod auf Tomahawk 5 endet bei 4.096 GPUs mit 800G pro GPU, wenn den Spines die Ports ausgehen. Darüber hinaus fügt dasselbe Rail-optimierte Design eine dritte Ebene hinzu: Leaf, Spine, Super-Spine. Zwei beliebige GPUs liegen höchstens vier Switch-Hops auseinander; Peers am selben Leaf und im selben Pod liegen näher.
Der schwierige Teil bei einem Clos besteht darin, Flows gleichmäßig zu verteilen, damit kein Link zum Hotspot wird. Die Ansätze reichen von Per-Flow-ECMP über dynamisches Load Balancing bis hin zu Per-Packet-Spray, dem Modell, das Ultra Ethernet mit Neuordnung an der NIC verwendet. Eine eigene Kategorie, zellbasierte Scheduled Fabrics wie Broadcom DDC, segmentiert den Verkehr in Zellen und verteilt ihn per Scheduling innerhalb der Fabric. OcNOS hält die GPU-Ebene mit DLB im Gleichgewicht und ergänzt fabric-weites GLB in OcNOS 7.1.
Das Diagramm ist schematisch: Es zeigt eine reduzierte Anzahl je Ebene. Der Aufbau mit 16.384 GPUs umfasst 512 Leaves / 256 Spines / 128 Super-Spines auf TH5 800G.

OcNOS-Komponenten: eBGP-unnumbered L3-Underlay, RoCEv2 verlustfrei (PFC + ECN), DLB auf jeder Tier, GLB Ende-zu-Ende in OcNOS 7.1 und gNMI-Streaming-Telemetrie an Ihren Observability-Stack. Durchgängig aufgebaut auf HCL-gelisteten TH5 64x800G Chassis.
Die Überbuchung ist ein Regler, keine feste Regel. Diese Anzahlen machen jeden Pod mit 1.024 GPUs 1:1 nicht blockierend und nutzen ein kostenoptimiertes Super-Spine mit ~2:1 für Cross-Pod-Traffic, der Rail-optimierte Ansatz, auf den Hyperscale-Ethernet-Fabrics setzen (veröffentlichte Großdesigns überbuchen die oberste Ebene weit stärker, da Collective-Traffic pod-lokal bleibt). Sie möchten stattdessen maximalen Any-to-Any-Spielraum? Ein vollständig nicht blockierender 1:1-Aufbau umfasst 512 / 512 / 256 bei 16.384 GPUs; nur die Spine- und Super-Spine-Anzahlen ändern sich. Modellieren Sie beides im AI Fabric Design Suite.
Multi-DC-AI-Fabric: kohärentes DCI
Wenn ein einzelner Trainingslauf mehr als eine Data Hall umfasst, was bei Modellen mit Billionen Parametern zunehmend üblich ist, erstreckt sich die Fabric über das WAN. OcNOS-DC unterstützt kohärente 400G-ZR-/ZR+-Optiken direkt auf dem Spine für transponderloses DCI zwischen Standorten. Die Fabric innerhalb jedes Standorts bleibt unverändert.

OcNOS-Komponenten: 400G ZR/ZR+ steckbare kohärente Optik an einem DWDM-fähigen Spine- oder Border-Leaf-Port, mit gNMI-Telemetrie über Standorte hinweg. Keine externen Transponder erforderlich. Reichweite: 400ZR bis etwa 120 km verstärkt; OpenZR+ reicht mit oFEC weiter.
Design-Faustregeln
Eine Handvoll Regeln hält eine AI-Fabric auf der richtigen Seite der Leistungs- und Kostenkurve, unabhängig davon, von welchem Referenzdesign Sie ausgehen.
- Passen Sie die Topologie an die GPU-Anzahl an. Kleinste Pods (unterhalb der NIC-Radix eines Leaf): Rail-only genügt. Single-Pod-Maßstab, bis zu 4.096 GPUs auf Tomahawk 5: Rail-optimiertes Leaf-Spine. Darüber hinaus: Fügen Sie demselben Rail-optimierten Design eine Super-Spine-Ebene hinzu, wobei der Pod nicht blockierend bleibt und das Cross-Pod-Verhältnis auf den Workload abgestimmt wird.
- Immer 1:1-Subscription auf der AI-Plane. Storage- und CPU-Racks können höhere Oversubscription-Ratios fahren. Die GPU-Plane sollte das nicht.
- Planen Sie die Rail-Anzahl von xCCL aus, nicht nach Verkabelungs-Komfort. 8 Rails sind der aktuelle De-facto-Standard für GPU-Server mit 8 NICs. Fassen Sie Rails nicht zu weniger Leaves zusammen.
- Wählen Sie das Silicon nach Leistung und Dichte, nicht nach dem Label. TH4 (25,6T) und TH5 (51,2T) sind die Arbeitspferde; die Wahl zwischen beiden hängt von der Rack-Leistung und den Kosten für Breakout-Kabel ab.
- Gegen die HCL validieren. Jede Referenz hier basiert auf Hardware, die in der OcNOS-Hardware-Kompatibilitätsliste; wählen Sie von dort aus für erstklassigen Support.
FAQ zur AI-Fabric-Topologie
Was ist eine rail-optimierte Topologie, und wie unterscheidet sie sich von rail-only?
Wann braucht eine AI-Fabric eine dritte Ebene?
Sollte ich Tomahawk 4 oder Tomahawk 5 verwenden?
Brauche ich InfiniBand, oder reicht Ethernet aus?
Wo endet Scale-up und wo beginnt Scale-out?
Tiefer einsteigen. Zum Mitnehmen.
Das Produktdatenblatt und kurze, technische Downloads, die über diese Seite hinausgehen.
OcNOS-DC-Datenblatt
Vollständige OcNOS-DC-Spezifikation: Funktionsumfang für EVPN-VXLAN und Ethernet for AI, Software-SKUs, unterstützte Hardware-Plattformen und der Solution Ordering Guide.
Datenblatt abrufenOcNOS: verlustfreie 800G-AI-Fabric
Non-Blocking-RoCEv2-Fabric auf Broadcom-Tomahawk-4/5-Spines: SKU-Stufen, validierte Plattformen und Deployment-Architektur.
Brief anfordernEVPN-VXLAN-Data-Center-Fabric
Carrier-Grade-Leaf-Spine-Data-Center-Fabric: symmetrisches IRB, Type-2/Type-5-Routen und verteiltes Anycast-Gateway.
Brief anfordernOcNOS-DC-Datenblatt
Kurzes Formular. Ihr PDF öffnet sich unmittelbar nach dem Absenden in einem neuen Tab.
✓ Ihr PDF wird in einem neuen Tab geöffnet…
Falls es sich nicht geöffnet hat, nutzen Sie den untenstehenden Link.
OcNOS: verlustfreie 800G-AI-Fabric
Kurzes Formular. Ihr PDF öffnet sich unmittelbar nach dem Absenden in einem neuen Tab.
✓ Ihr PDF wird in einem neuen Tab geöffnet…
Falls es sich nicht geöffnet hat, nutzen Sie den untenstehenden Link.
EVPN-VXLAN-Data-Center-Fabric
Kurzes Formular. Ihr PDF öffnet sich unmittelbar nach dem Absenden in einem neuen Tab.
✓ Ihr PDF wird in einem neuen Tab geöffnet…
Falls es sich nicht geöffnet hat, nutzen Sie den untenstehenden Link.
Sie konzipieren Ihr AI-Fabric? Wir berechnen die Port-Anzahl gemeinsam mit Ihnen.
Nennen Sie uns den Workload und die GPU-Größenordnung, und ein IP Infusion-Ingenieur dimensioniert die Leaf-, Spine- und Super-Spine-Tiers gemeinsam mit Ihnen, oder beginnen Sie mit einem ersten Entwurf in der AI Fabric Design Suite.
Die gesamte AI-Fabric mit OcNOS entwerfen
Vom Business Case bis zur Portanzahl-Berechnung: Steigen Sie dort ein, wo Sie beim Aufbau gerade stehen.