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 dalla radix dello switch e da come ogni porta a 800G viene mappata sulle GPU. Su Broadcom Tomahawk 5 (51.2 Tbps, 64×800G o 128×400G), i design vanno da un leaf-spine a 2 livelli fino a tre livelli con un super-spine. 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 AI basato su Ethernet da 24.576 GPU, a dimostrazione di fabric Ethernet che operano ben oltre un singolo pod.
2 tier, 1:1 non-blocking
Leaf-spine rail-optimized a 800G per GPU, ogni GPU su due porte leaf a 400G: 128 leaf, 64 spine. Il pod a due livelli più grande su questo silicio.
2 livelli a 400G per GPU
Lo stesso design a 2 livelli per GPU con una NIC a 400G ciascuna.
3 livelli, super-spine
Oltre 4.096 GPU, aggiungete un livello super-spine sopra i pod rail-optimized. Ogni pod resta 1:1 non bloccante; il super-spine fissa il rapporto cross-pod.
State dimensionando il vostro cluster? La Suite di progettazione per fabric AI dimensiona un pod leaf-spine non bloccante a due livelli e segnala quando si passa alla scala a tre livelli. Per il quadro completo delle topologie, si veda 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 dinamico del carico e telemetria in streaming. È un unico sistema: hardware qualificato, 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
La telemetria viene trasmessa 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 qualificati 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 qualificate 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 datasheet
Fabric AI senza perdite OcNOS 800G
Fabric RoCEv2 lossless su spine Tomahawk 5: livelli di SKU, piattaforme qualificate e architettura di deployment.
Scarica il brief
Fabric data center EVPN-VXLAN
Fabric data center leaf-spine su EVPN-VXLAN: una VRF e VNI per tenant, multihoming EVPN, BGP unnumbered e filtraggio per route target.
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.