Topologia di rete rail-optimized per fabric AI
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. Poiché un rail corrisponde a un leaf, quel traffico resta sul leaf e non compete mai per la capacità dello spine.
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, Bilanciamento dinamico del carico 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.
| Proprietà | Rail-optimizedstandard a pod singolo | Rail-onlypunto d'ingresso per cluster piccoli | Top-of-rack (ToR)allineato al server |
|---|---|---|---|
| Allineamento | 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. |
| Livello spine | 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 5 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 5 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 5 stadi su questo radix. Il rapporto cross-pod è regolato in base al carico di lavoro.
State dimensionando il vostro cluster? La Suite di progettazione per fabric AI 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 di fabric AI riferimento.
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.
Bilanciamento dinamico del carico
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.
Membro dell'Ultra Ethernet Consortium
IP Infusion è membro dell'Ultra Ethernet Consortium (UEC). UEC 1.0 definisce un trasporto Ethernet multipath che distribuisce un flusso su molti percorsi e funziona su NIC compatibili UEC.
Ottieni il design di riferimento della fabric AI
Il PDF completo: topologia rail-optimized, numero di switch e transceiver, piattaforme validate e un profilo iniziale RoCEv2 lossless su OcNOS-DC.
Ottieni il design di riferimento della fabric AI
Modulo breve: il PDF verrà scaricato subito dopo l'invio.
✓ Apertura del vostro PDF in una nuova scheda…
Se non si è aperto, usate 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 AI?
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 datasheetFabric AI senza perdite OcNOS 800G
Fabric RoCEv2 non bloccante su spine Broadcom Tomahawk 4/5: tier di SKU, piattaforme validate e architettura di deployment.
Scarica il briefFabric data center EVPN-VXLAN
Fabric leaf-spine carrier-grade per data center: IRB simmetrico, route Type-2/Type-5 e gateway anycast distribuito.
Scarica il briefDatasheet OcNOS-DC
Modulo rapido. Il vostro PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del vostro PDF in una nuova scheda…
Se non si è aperto, usate il link qui sotto.
Fabric AI senza perdite OcNOS 800G
Modulo rapido. Il vostro PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del vostro PDF in una nuova scheda…
Se non si è aperto, usate il link qui sotto.
Fabric data center EVPN-VXLAN
Modulo rapido. Il vostro PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del vostro PDF in una nuova scheda…
Se non si è aperto, usate 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'intera fabric AI con OcNOS
Dal business case al calcolo del numero di porte, riprendete da qualunque punto della realizzazione.