8 rails · RoCEv2 · Tomahawk 5

Topologie réseau rail-optimized pour les fabrics IA

Un réseau rail-optimized place une carte réseau de chaque serveur GPU à 8 cartes sur chacun des 8 rails, et fait de chaque rail son propre leaf dédié, si bien que l'AllReduce intra-rail dominant reste sur un seul leaf et n'atteint jamais le spine. C'est une discipline de câblage et de localité de trafic, pas un réducteur du nombre de spines : le spine reste 1:1 non bloquant et ne transporte que le reliquat inter-rail. Bâti sur OcNOS-DC au-dessus de RoCEv2 sans perte sur Broadcom Tomahawk 5.

8 railsune carte réseau par rail, par serveur
~2,048plafond 1:1 à deux niveaux GPU
TH4 & TH5Silicon Broadcom
1 NOSOcNOS-DC sur matériel ouvert
La discipline de câblage

Ce que signifie rail-optimized, et en quoi il diffère de rail-only

Les serveurs GPU modernes sont livrés avec 8 cartes réseau. Un rail est une position de carte réseau prise sur chaque serveur : la NIC-1 de chaque serveur forme le rail-1, et ainsi de suite jusqu'au rail-8. Le rail-optimized rattache chaque rail à son propre leaf dédié, si bien que chaque serveur dispose d'un lien vers chacun des 8 leaves de rail.

Le bénéfice est la localité : les bibliothèques xCCL ordonnancent l'AllReduce dominant à l'intérieur d'un seul rail, et parce que ce rail est un seul leaf, le trafic ne quitte jamais le leaf. Seul le reliquat inter-rail, plus réduit, atteint le spine. Le rail-optimized est une discipline de câblage et de localité de trafic, pas un moyen de réduire le spine, qui reste 1:1 non bloquant.

  • Rail-only conserve les leaves alignés sur les rails mais supprime le niveau spine, si bien que le trafic inter-rail s'appuie sur le domaine de scale-up GPU interne au serveur plutôt que sur un chemin réseau. Moins cher pour une poignée de racks, mais sans route de fabric pour les flux inter-rail dès que le cluster dépasse un domaine de scale-up.
  • Rail-optimized ajoute un spine 1:1 non bloquant au-dessus des leaves de rail, offrant aux flux inter-rail un vrai chemin réseau. C'est l'unité évolutive standard à un seul pod ; rail-only est le point d'entrée en dessous.
Pourquoi c'est important

L'alignement sur les rails garde le collectif chaud en local

L'entraînement distribué est dominé par des collectifs tels que l'AllReduce pour la synchronisation des gradients, exécutés au travers des bibliothèques xCCL (NCCL, RCCL, oneCCL). L'alignement sur les rails place les GPU de même rang sur un leaf partagé, si bien que ces collectifs s'achèvent avec le plus faible nombre de sauts et sans transit par le spine dans le cas courant. Cela contient la latence de queue, et la latence de queue fixe le rythme d'une étape synchrone : elle ne s'achève que lorsque le GPU le plus lent termine son échange.

Locality

Localité collective

xCCL ordonnance l'AllReduce dominant à l'intérieur d'un seul rail. Because a rail is one leaf, that traffic stays on the leaf and never contends for spine capacity.

Hop count

Plus faible nombre de sauts

Les GPU de même rang partagent un leaf, si bien que les échanges de synchronisation de gradient s'achèvent en un minimum de sauts. Le spine ne transporte que le reliquat inter-rail.

Latence de queue

Latence de queue réduite

Une étape synchrone se termine lorsque l'échange le plus lent se termine. Tenir le collectif chaud à l'écart du spine réduit la longue traîne qui bloque toute la tâche.

Path use

Utilisation uniforme des chemins

Pour le trafic inter-rail qui atteint effectivement le spine, Équilibrage de charge dynamique répartit les flux éléphants afin qu'aucune liaison montante ne devienne le point chaud.

Architecture de référence

Le fabric rail-optimized, en schéma

Chaque serveur GPU porte 8 cartes réseau, une par rail, et chaque rail est son propre leaf dédié, si bien que les 8 cartes d'un serveur aboutissent sur des leaves différents. L'AllReduce sur le rail-N reste à l'intérieur du leaf-N et ne touche jamais le spine ; un spine 1:1 non bloquant ne transporte que le reliquat inter-rail. Le schéma est schématique : il représente un nombre réduit de serveurs et de spines pour garder l'alignement sur les rails lisible.

Rail-optimized AI data center on OcNOS-DC: a shared 800G Tomahawk 5 spine tier over two GPU pods where every server maps its eight NICs one per rail to eight color-coded rail leaves, plus a separate storage fabric (leaf-spine Clos, NVMe-oF and NFS) and an isolated out-of-band management plane that reaches every switch.
Le centre de données IA rail-optimized complet : deux pods GPU avec chaque carte réseau sur son propre leaf de rail, un fabric de stockage dédié et un plan de gestion hors bande isolé, le tout sur un seul NOS (OcNOS-DC).

Composants OcNOS : Underlay L3 BGP unnumbered, RoCEv2 sans perte (PFC + ECN) sur chaque leaf de rail, DLB au niveau spine, télémétrie gNMI/OpenConfig de bout en bout. Bâti sur du matériel Tomahawk 5 inscrit à la HCL : l'Edgecore AIS800-64D et l'UfiSpace S9321-64E (64×800G).

Aligner le fabric

Rail-optimized, rail-only et ToR, côte à côte

Le choix porte sur ce à quoi le fabric s'aligne. Une disposition en rail aligne chaque rang GPU sur un plan réseau, si bien que les GPU de même rang à travers le cluster partagent un leaf et que le collectif s'achève avec le plus faible nombre de sauts. Une disposition ToR s'aligne sur le serveur : chaque carte réseau d'un serveur aboutit sur son commutateur de rack, plus simple à câbler mais forçant les GPU de même rang situés dans des racks différents à remonter jusqu'au spine et à redescendre. Pour les fabrics d'entraînement GPU où l'AllReduce domine, l'alignement sur les rails est la norme ; le ToR reste un bon choix pour le stockage et les racks polyvalents où le trafic n'est pas synchrone par rang.

Property Rail-optimizedstandard à un seul pod Rail-onlyentrée pour petit cluster Top-of-rack (ToR)server-aligned
Alignment Chaque rang GPU aligné sur un plan réseau ; la NIC-N de chaque serveur se rattache au leaf-N. Même alignement sur les rails : la NIC-N se rattache au leaf de rail N, mais une seule rangée de leaves. Réseau aligné sur le serveur ; chaque carte réseau d'un serveur se rattache à son propre commutateur de rack.
Spine tier Spine 1:1 non bloquant au-dessus des leaves de rail. Aucun niveau spine ; les leaves de rail sont autonomes. Spine standard au-dessus des commutateurs de rack.
Chemin inter-rail Un vrai chemin réseau à travers le spine non bloquant. S'appuie sur le domaine de scale-up GPU interne au serveur ; aucune route de fabric dès qu'il dépasse un domaine. Le trafic synchrone par rang est poussé jusqu'au spine.
Nombre de sauts du collectif Le plus faible : les pairs de même rang partagent un leaf, si bien que l'AllReduce intra-rail reste sur un seul leaf. Également faible en intra-rail, puisque le rail reste un seul leaf. Plus élevé : les pairs de même rang situés dans des racks différents se trouvent sur des commutateurs différents, si bien que les collectifs traversent le spine.
Choix le plus adapté L'unité évolutive standard à un seul pod pour les fabrics d'entraînement et d'inférence GPU. Une poignée de racks sous un seul domaine de scale-up ; le point d'entrée. Racks de stockage, de CPU et polyvalents où le trafic n'est pas synchrone par rang.
Scale

Jusqu'où un fabric rail-optimized passe à l'échelle

L'échelle est fixée par le radix du commutateur et par la manière dont chaque port 800G est associé aux GPU. Sur du Broadcom Tomahawk 5 radix-64 (51.2 Tbps, 64×800G), les architectures vont d'un leaf-spine à 2 niveaux jusqu'à un Clos à 3 étages. Comme la majeure partie du trafic collectif reste locale au rail, le plan super-spine n'est dimensionné qu'au ratio inter-pod dont vous avez réellement besoin. Pour situer le contexte, Meta a décrit publiquement un cluster d'entraînement IA de 24,000-GPU fondé sur Ethernet, ce qui montre des fabrics Ethernet fonctionnant bien au-delà d'un seul pod.

~2,048 Tomahawk 5 · 64×800G

2 niveaux, 1:1 non bloquant

Leaf-spine rail-optimized à un port de fabric 800G par GPU. L'unité évolutive standard à un seul pod.

8,000+ Tomahawk 5 · breakout 800G

2 niveaux avec breakout 800G

Même conception à 2 niveaux avec des ports 800G éclatés vers plusieurs cartes réseau GPU pour une densité GPU plus élevée par commutateur.

16,000+ Tomahawk 5 · plan super-spine

Clos 3 étages

Ajoutez un niveau super-spine au-dessus des pods rail-optimized. Chaque pod reste 1:1 non bloquant ; le super-spine fixe le ratio inter-pod.

~65,535 Tomahawk 5 · plafond fat-tree

Limite fat-tree

Le plafond théorique du fat-tree à 3 étages sur ce radix. Le ratio inter-pod est ajusté à la charge de travail.

Vous dimensionnez votre propre cluster ? The AI Fabric Design Suite dimensionne un pod leaf-spine non bloquant à deux niveaux à une carte réseau de fabric par GPU et signale lorsque vous franchissez l'échelle à trois niveaux. Pour la vue complète de la topologie, voir Topologies de fabric IA reference.

La construction IP Infusion

Comment OcNOS-DC construit un fabric rail-optimized

OcNOS-DC transforme les commutateurs Tomahawk 5 inscrits à la HCL en un fabric rail-optimized avec un underlay routé, un substrat RoCEv2 sans perte, un équilibrage de charge adaptatif et de la télémétrie en continu. C'est un seul système : du matériel validé, le système d'exploitation réseau OcNOS-DC et un contrat de support unique avec un seul TAC et un seul SLA.

Underlay

L3 BGP unnumbered

Un underlay routé avec BGP unnumbered supprime la planification d'adresses par lien et répartit le trafic sur chaque chemin rail-à-spine avec ECMP.

Lossless

RoCEv2 avec PFC + ECN

OcNOS-DC fournit le substrat Ethernet sans perte que RoCEv2 exige : PFC maintient la priorité sans perte et ECN marque la congestion. RoCEv2 lui-même est le transport de la carte réseau qui s'appuie sur ce substrat.

Balancing

Équilibrage de charge dynamique

DLB répartit les flux éléphants selon la qualité de chemin en temps réel au lieu d'un hachage statique, si bien que le trafic inter-rail ne s'accumule pas sur une seule liaison montante et qu'un fabric bien exploité peut viser une utilisation supérieure à 90 pour cent sur Tomahawk 4/5.

Télémétrie

gNMI / OpenConfig

Les compteurs d'utilisation et de profondeur de file d'attente par chemin sont diffusés via gNMI avec les modèles OpenConfig, si bien que vous réglez le fabric avec des données en boucle fermée pendant la mise en service du cluster.

Matériel

Tomahawk 5 inscrit à la HCL

Fonctionne sur des commutateurs 64×800G validés : Edgecore AIS800-64D et UfiSpace S9321-64E. Chaque leaf et spine ici figure sur la liste de compatibilité matérielle (HCL) d'OcNOS.

Forward-looking

Prêt pour Ultra Ethernet

IP Infusion est un membre contributeur de l'Ultra Ethernet Consortium, et OcNOS-DC suit le profil de fabric UEC 1.0, si bien que le fabric se prolonge à mesure que les cartes réseau compatibles UEC arrivent. L'alignement sur le profil n'est pas une revendication de certification.

FAQ

FAQ sur le réseau rail-optimized

Qu'est-ce qu'un réseau rail-optimized ?
A rail-optimized network is an AI fabric wiring pattern for GPU servers. Each server carries 8 NICs, one per "rail", and every rail is homed to its own dedicated leaf. Because rail-N from every server lands on leaf-N, the dominant same-rail AllReduce traffic stays inside one leaf and never traverses the spine. That keeps hop count and tail latency low for the collective patterns that dominate distributed training.
Quelle est la différence entre rail-optimized et rail-only ?
Les deux alignent les cartes réseau GPU sur des rails. Rail-only est le cas du petit cluster : une seule rangée de leaves alignés sur les rails sans niveau spine, si bien que le trafic inter-rail s'appuie sur le domaine de scale-up GPU. Rail-optimized ajoute un spine 1:1 non bloquant au-dessus de ces leaves de rail, si bien que les flux inter-rail disposent d'un vrai chemin réseau. Rail-only est plus simple et moins cher pour une poignée de racks ; rail-optimized est l'unité évolutive standard à un seul pod dès que vous avez besoin de bande passante inter-rail.
Rail contre ToR : quelle disposition un fabric IA doit-il adopter ?
Une disposition en rail aligne chaque rang GPU sur un plan réseau, offrant le plus faible nombre de sauts pour les collectifs car les pairs du même rail partagent un leaf. Une disposition top-of-rack (ToR) est alignée sur le serveur : chaque carte réseau d'un serveur aboutit sur le même commutateur de rack, ce qui est plus simple à câbler mais pousse davantage de trafic collectif jusqu'au spine, puisque les GPU de même rang situés dans des racks différents ne sont jamais sur le même leaf. Pour les fabrics d'entraînement GPU, l'alignement sur les rails est la norme car il garde le motif AllReduce local.
À combien de GPU un fabric rail-optimized passe-t-il à l'échelle ?
Sur des commutateurs Broadcom Tomahawk 5 radix-64 (51.2 Tbps, 64×800G), un leaf-spine rail-optimized à 2 niveaux atteint environ 2,048 GPU à un port de fabric 800G par GPU (1:1 non bloquant), et évolue vers plus de 8,000 GPU lorsque les ports 800G sont éclatés vers plusieurs cartes réseau GPU. L'extension à un Clos à 3 étages avec un niveau super-spine atteint plus de 16,000 GPU dans les architectures de référence, et jusqu'à environ 65,535 GPU à la limite fat-tree.
Un réseau rail-optimized a-t-il besoin d'InfiniBand ?
Non. Un fabric rail-optimized fonctionne sur de l'Ethernet standard. OcNOS-DC fournit le substrat Ethernet sans perte que RoCEv2 exige à l'aide de PFC et d'ECN, si bien que le RDMA s'exécute sans perte à travers les rails. IP Infusion est également un membre contributeur de l'Ultra Ethernet Consortium, et OcNOS-DC suit le profil de fabric UEC 1.0, si bien que le même fabric se prolonge à mesure que les cartes réseau compatibles UEC arrivent. L'alignement sur le profil n'est pas une revendication de certification.
Comment OcNOS-DC met-il en œuvre un fabric rail-optimized ?
OcNOS-DC construit l'underlay avec un routage L3 BGP unnumbered, rend chaque leaf de rail sans perte pour RoCEv2 avec PFC et ECN, répartit les flux éléphants avec le Dynamic Load Balancing (DLB) et diffuse la télémétrie gNMI/OpenConfig pour un réglage en boucle fermée. Il fonctionne sur du matériel Tomahawk 5 inscrit à la HCL tel que l'Edgecore AIS800-64D et l'UfiSpace S9321-64E. Un seul contrat IP Infusion couvre le logiciel OcNOS-DC et le matériel de commutation validé, avec un seul TAC et un seul SLA.

Vous planifiez un fabric GPU rail-optimized ? Nous ferons les calculs de nombre de ports avec vous.

Indiquez-nous l'échelle GPU et le nombre de rails, et un ingénieur IP Infusion dimensionnera avec vous le pod leaf-spine, ou commencez par un premier schéma dans l'AI Fabric Design Suite.