Topologia di rete rail-optimized per fabric IA
Una rete rail-optimized colloca una NIC di ciascun server GPU a 8 NIC su ognuno degli 8 rail, e rende ogni rail un leaf dedicato, così l'AllReduce intra-rail predominante resta su un solo leaf e non raggiunge mai lo spine. È una disciplina di cablaggio e di località del traffico, non un modo per ridurre il numero di spine: lo spine resta 1:1 non-blocking e trasporta solo il traffico cross-rail residuo. Costruita su OcNOS-DC tramite RoCEv2 lossless su Broadcom Tomahawk 5.
Cosa significa rail-optimized e come si differenzia da rail-only
I moderni server GPU sono dotati di 8 NIC. Un rail è una posizione di NIC presa da ogni server: la NIC-1 di ogni server forma il rail-1, e così via fino al rail-8. Rail-optimized collega ogni rail al proprio leaf dedicato, così ogni server ha un link verso ciascuno degli 8 rail leaf.
Il vantaggio è la località: le librerie xCCL pianificano l'AllReduce predominante all'interno di un singolo rail e, poiché quel rail è un solo leaf, il traffico non lascia mai il leaf. Solo il traffico cross-rail residuo, più ridotto, raggiunge lo spine. Rail-optimized è una disciplina di cablaggio e di località del traffico, non un modo per ridurre lo spine, che resta 1:1 non-blocking.
- Rail-only mantiene i leaf allineati ai rail ma elimina il tier spine, così il traffico cross-rail si appoggia al dominio di scale-up GPU interno al server anziché a un percorso di rete. Più economico per una manciata di rack, ma senza percorso di fabric per i flussi cross-rail una volta che il cluster supera un singolo dominio di scale-up.
- Rail-optimized aggiunge uno spine 1:1 non-blocking sopra i rail leaf, offrendo ai flussi cross-rail un percorso di rete reale. È l'unità scalabile standard a pod singolo; rail-only è il punto d'ingresso sottostante.
L'allineamento per rail mantiene locale il collettivo più intenso
Il training distribuito è dominato da collettivi come AllReduce per la sincronizzazione dei gradienti, eseguiti tramite le librerie xCCL (NCCL, RCCL, oneCCL). L'allineamento per rail colloca le GPU dello stesso rank su un leaf condiviso, così questi collettivi si completano con il numero di hop minimo e senza transito attraverso lo spine nel caso comune. Ciò contiene la latenza di coda, e la latenza di coda detta il ritmo di uno step sincrono: termina solo quando la GPU più lenta completa il proprio scambio.
Località dei collettivi
xCCL pianifica il predominante AllReduce all'interno di un singolo rail. Because a rail is one leaf, that traffic stays on the leaf and never contends for spine capacity.
Numero di hop minimo
Le GPU dello stesso rank condividono un leaf, così gli scambi di sincronizzazione dei gradienti si completano nel minor numero di hop. Lo spine trasporta solo il traffico cross-rail residuo.
Latenza di coda inferiore
Uno step sincrono termina quando termina lo scambio più lento. Tenere il collettivo più intenso lontano dallo spine riduce la lunga coda che blocca l'intero job.
Uso uniforme dei percorsi
Per il traffico cross-rail che raggiunge effettivamente lo spine, Dynamic Load Balancing distribuisce gli elephant flow così che nessun singolo uplink diventi il punto critico.
La fabric rail-optimized, nel dettaglio
Ogni server GPU porta 8 NIC, una per rail, e ogni rail è un leaf dedicato, così tutte le 8 NIC di un server finiscono su leaf diversi. L'AllReduce sul rail-N resta all'interno del leaf-N e non tocca mai lo spine; uno spine 1:1 non-blocking trasporta solo il traffico cross-rail residuo. Il diagramma è schematico: rappresenta un numero ridotto di server e spine per mantenere leggibile l'allineamento per rail.
Componenti OcNOS: Underlay L3 BGP-unnumbered, RoCEv2 lossless (PFC + ECN) su ogni rail leaf, DLB al tier spine, telemetria gNMI/OpenConfig ovunque. Costruito su hardware Tomahawk 5 presente nell'HCL: Edgecore AIS800-64D e UfiSpace S9321-64E (64×800G).
Rail-optimized, rail-only e ToR a confronto
La scelta riguarda a cosa si allinea la fabric. Un layout rail allinea ogni rank GPU a un piano di rete, così le GPU dello stesso rank nell'intero cluster condividono un leaf e il collettivo si completa con il numero di hop minimo. Un layout ToR si allinea al server: ogni NIC di un server finisce sul proprio switch di rack, più semplice da cablare ma costringe le GPU dello stesso rank in rack diversi a salire fino allo spine e tornare. Per le fabric di training GPU in cui domina l'AllReduce, l'allineamento per rail è lo standard; ToR resta una buona scelta per rack di storage e uso generico in cui il traffico non è rank-sincrono.
| Property | Rail-optimizedstandard a pod singolo | Rail-onlypunto d'ingresso per cluster piccoli | Top-of-rack (ToR)server-aligned |
|---|---|---|---|
| Alignment | Ogni rank GPU allineato a un piano di rete; la NIC-N di ogni server è collegata al leaf-N. | Stesso allineamento per rail: la NIC-N è collegata al rail leaf-N, ma con una sola fila di leaf. | Rete allineata al server; ogni NIC di un server è collegata al proprio switch di rack. |
| Spine tier | Spine 1:1 non-blocking sopra i rail leaf. | Nessun tier spine; i rail leaf sono autonomi. | Spine standard sopra gli switch di rack. |
| Percorso cross-rail | Un percorso di rete reale attraverso lo spine non-blocking. | Si appoggia al dominio di scale-up GPU interno al server; nessun percorso di fabric una volta superato un singolo dominio. | Il traffico rank-sincrono viene spinto fino allo spine. |
| Numero di hop dei collettivi | Minimo: i peer dello stesso rank condividono un leaf, quindi l'AllReduce intra-rail resta su un solo leaf. | Anch'esso basso intra-rail, poiché il rail è comunque un solo leaf. | Più alto: i peer dello stesso rank in rack diversi si trovano su switch diversi, quindi i collettivi attraversano lo spine. |
| Scelta ottimale | L'unità scalabile standard a pod singolo per fabric di training e inferenza GPU. | Una manciata di rack al di sotto di un singolo dominio di scale-up; il punto d'ingresso. | Rack di storage, CPU e uso generico in cui il traffico non è rank-sincrono. |
Fino a che punto scala una fabric rail-optimized
La scala è determinata dal radix dello switch e dal modo in cui ogni porta 800G si mappa sulle GPU. Su Broadcom Tomahawk 5 radix-64 (51.2 Tbps, 64×800G), i design vanno da un leaf-spine a 2 tier fino a un Clos a 3 stadi. Poiché la maggior parte del traffico collettivo resta locale al rail, il piano super-spine è dimensionato solo sul rapporto cross-pod effettivamente necessario. Per contesto, Meta ha descritto pubblicamente un cluster di training IA basato su Ethernet da 24,000 GPU, il che dimostra che le fabric Ethernet operano ben oltre un singolo pod.
2 tier, 1:1 non-blocking
Leaf-spine rail-optimized con una porta fabric 800G per GPU. L'unità scalabile standard a pod singolo.
2 tier con breakout 800G
Stesso design a 2 tier con porte 800G suddivise in più NIC GPU per una maggiore densità di GPU per switch.
Clos a 3 stadi
Aggiungete un tier super-spine sopra i pod rail-optimized. Ogni pod resta 1:1 non-blocking; il super-spine determina il rapporto cross-pod.
Limite fat-tree
Il limite teorico del fat-tree a 3 stadi su questo radix. Il rapporto cross-pod è regolato in base al carico di lavoro.
State dimensionando il vostro cluster? The AI Fabric Design Suite dimensiona un pod leaf-spine a due tier non-blocking con una NIC fabric per GPU e segnala quando si passa a una scala a tre tier. Per il quadro completo della topologia, vedi la Topologie AI fabric reference.
Come OcNOS-DC costruisce una fabric rail-optimized
OcNOS-DC trasforma gli switch Tomahawk 5 presenti nell'HCL in una fabric rail-optimized con un underlay instradato, un substrato RoCEv2 lossless, bilanciamento del carico adattivo e telemetria in streaming. È un unico sistema: hardware validato, il sistema operativo di rete OcNOS-DC e un unico contratto di supporto con un solo TAC e un solo SLA.
BGP-unnumbered L3
Un underlay instradato con BGP unnumbered elimina la pianificazione degli indirizzi per singolo link e distribuisce il traffico su ogni percorso rail-spine con ECMP.
RoCEv2 con PFC + ECN
OcNOS-DC fornisce il substrato Ethernet lossless che RoCEv2 richiede: PFC mantiene lossless la priorità ed ECN marca la congestione. RoCEv2 stesso è il trasporto della NIC che viaggia su quel substrato.
Dynamic Load Balancing
DLB distribuisce gli elephant flow in base alla qualità del percorso in tempo reale anziché a un hash statico, così il traffico cross-rail non si accumula su un solo uplink e una fabric ben gestita può puntare a un utilizzo superiore al 90 percento su Tomahawk 4/5.
gNMI / OpenConfig
I contatori di utilizzo per percorso e di profondità delle code vengono trasmessi in streaming tramite gNMI con i modelli OpenConfig, così potete ottimizzare la fabric con dati a ciclo chiuso durante il bring-up del cluster.
Tomahawk 5 presente nell'HCL
Funziona su switch validati da 64×800G: Edgecore AIS800-64D e UfiSpace S9321-64E. Ogni leaf e spine qui è presente nella OcNOS Hardware Compatibility List.
Pronto per Ultra Ethernet
IP Infusion è un membro contribuente dell'Ultra Ethernet Consortium e OcNOS-DC segue il profilo di fabric UEC 1.0, così la fabric si evolve man mano che arrivano le NIC compatibili con UEC. L'allineamento al profilo non costituisce una dichiarazione di certificazione.
Ottieni l'AI Fabric Reference Design
The full PDF: rail-optimized topology, switch and transceiver counts, validated platforms, and a RoCEv2 lossless starting profile on OcNOS-DC.
Ottieni l'AI Fabric Reference Design
Modulo breve: il PDF verrà scaricato subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.
FAQ sulla rete rail-optimized
Che cos'è una rete rail-optimized?
Qual è la differenza tra rail-optimized e rail-only?
Rail vs ToR: quale layout dovrebbe usare una fabric IA?
A quante GPU scala una fabric rail-optimized?
Una rete rail-optimized ha bisogno di InfiniBand?
Come implementa OcNOS-DC una fabric rail-optimized?
Approfondite. Portatelo con voi.
Il datasheet di prodotto e download tecnici e sintetici che vanno oltre questa pagina.
Datasheet OcNOS-DC
Specifica completa di OcNOS-DC: il set di funzionalità EVPN-VXLAN e Ethernet for AI, gli SKU software, le piattaforme hardware supportate e la guida all'ordine della soluzione.
Ottieni il datasheetOcNOS 800G Lossless AI Fabric
Fabric RoCEv2 non bloccante su spine Broadcom Tomahawk 4/5: tier di SKU, piattaforme validate e architettura di deployment.
Scarica il briefEVPN-VXLAN data center fabric
Fabric leaf-spine per data center di livello carrier: IRB simmetrico, route Type-2/Type-5 e gateway anycast distribuito.
Scarica il briefDatasheet OcNOS-DC
Modulo rapido. Il suo PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.
OcNOS 800G Lossless AI Fabric
Modulo rapido. Il suo PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.
EVPN-VXLAN data center fabric
Modulo rapido. Il suo PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.
State pianificando una fabric GPU rail-optimized? Faremo con voi il calcolo del numero di porte.
Indicateci la scala GPU e il numero di rail, e un ingegnere di IP Infusion dimensionerà con voi il pod leaf-spine, oppure iniziate con un layout di primo passaggio nell'AI Fabric Design Suite.
Progettate l'intero fabric AI con OcNOS
Dal business case al calcolo del numero di porte, riprendete da qualunque punto della realizzazione.