RoCEv2 · DCQCN · DLB · UEC 1.0

Una AI fabric aperta: progettato per ciò che il job di training percepisce realmente.

Il collo di bottiglia nel training AI su larga scala e la rete tra le GPU. OcNOS-DC gestisce un fabric RoCEv2 800G lossless su switch Ethernet aperti, ottimizzato oggi per i collective GPU e domani per Ultra Ethernet: l'alternativa aperta a uno stack AI proprietario e a fornitore unico.

600+Reti OcNOS in esercizio
60+Countries in service
26 anniStack di routing in produzione
16kLimite del reference design GPU
The stakes

Cosa incide sul tempo di completamento dei job

Cio che conta su larga scala e la rapidita con cui i job vengono completati e quanto le GPU restano occupate, non il throughput degli switch. Ogni volta che il cluster si ferma per sincronizzarsi, le GPU inattive fanno bruciare denaro, quindi il fabric non deve perdere nulla e deve reagire alla congestione nell'istante in cui inizia.

OcNOS-DC espone ogni impostazione, cosi il tuo team puo ottimizzarlo sul traffico reale dei collective GPU (NCCL, RCCL, oneCCL). Ogni pattern qui sotto mostra il problema, il meccanismo che lo risolve e cio che se ne ricava.

Sincronizzazione del training (AllReduce)
Ogni GPU comunica con tutte le altre GPU contemporaneamente
Il load balancing standard vincola questi grandi flow a un solo uplink, quindi alcuni link si congestionano mentre altri restano inattivi e la sincronizzazione attende quello piu lento.
DLB sposta i flow verso percorsi meno congestionati in meno di un millisecondo.
GLB (OcNOS 7.1) bilancia il traffico sull'intero fabric, non solo sull'hop locale.
Risultato: nessun hot spot di traffico; la fase di sincronizzazione procede a velocita quasi piena.
Picchi di traffico (incast)
Molti sender colpiscono una sola porta in pochi microsecondi
Perdi un pacchetto e l'intero collective riparte da capo; applica un pause troppo aggressivo e il link si blocca. In entrambi i casi l'esecuzione si arresta.
DCQCN rallenta i sender in anticipo, prima che qualcosa vada in overflow.
PFC watchdog libera autonomamente una porta bloccata.
Risultato: i job assorbono i picchi e una porta bloccata si ripristina senza un reset manuale.
Scale-out (multi-rail)
Un singolo flow ha bisogno di tutti i percorsi paralleli contemporaneamente
Oggi un flow percorre un solo percorso, lasciando inutilizzati gli altri rail.
Ultra Ethernet (UEC 1.0) distribuisce un singolo flow su ogni percorso contemporaneamente.
→ Lo switch che acquisti oggi resta valido quando arriveranno le NIC UEC, senza sostituzioni.
Risultato: i trasferimenti piu lenti accelerano man mano che le NIC UEC vengono adottate.
~55% → 90%+

Benchmark di riferimento. DLB porta l'utilizzo del fabric da circa il 55% con il load balancing standard a oltre il 90% sugli stessi switch, senza uplink aggiuntivi. (Dato Broadcom pubblicato dal settore, riproducibile su Tomahawk 4 e 5.)

Approfondimento DLB →
Reference topology

800G spine-leaf, senza perdite da estremo a estremo

Un design leaf-spine (Clos) standard: un underlay eBGP instradato, traffico distribuito uniformemente su ogni percorso, code prioritarie lossless per il traffico GPU e una rete di gestione separata per il provisioning zero-touch e la telemetria. Passa il mouse su un nodo per vedere piattaforma, numero di porte e chip.

Topologia AI fabric: spine-leaf 800G con leaf paralleli, eBGP full-mesh, un bus di gestione isolato e storage collegato ai leaf
AI Fabric: spine-leaf 800G, eBGP full-mesh, un bus di gestione isolato e storage collegato ai leaf.
The hardware

Switch aperti validati

OcNOS-DC gira su switch Broadcom Tomahawk e Trident di Edgecore e UfiSpace, quindi ogni piattaforma e validata, ordinabile e reperibile da una seconda fonte.

Edgecore AIS800-64D 800G spine switch
Spine · Tomahawk 5

Edgecore AIS800-64D

64 x 800G · 51.2 Tbps

QSFP-DD800 · breakout to 2x400G / 4x200G / 8x100G

Datasheet →
UfiSpace S9321-64E 800G spine switch
Spine · Tomahawk 5

UfiSpace S9321-64E

64 x 800G · 51.2 Tbps

QSFP-DD800 · breakout to 2x400G / 4x200G / 8x100G

Datasheet →
Edgecore AS9736-64D 400G leaf switch
Leaf · Tomahawk 4

Edgecore AS9736-64D

64 x 400G · 25.6 Tbps · deep buffer

QSFP56-DD 400G · breakout to 4x100G / 4x25G · DAC / AOC

Datasheet →

Vedi tutte le oltre 40 piattaforme validate nell'HCL →

Un solo fornitore dietro software, hardware e supporto

SUPPORTO A FORNITORE UNICO

Un solo contratto, un solo team a cui rivolgersi

Un unico contratto IP Infusion copre insieme il software OcNOS-DC e l'hardware degli switch validati, quindi c'e un solo TAC e un solo SLA anziche un NOS e un fornitore hardware separati. Un portale di supporto 24/7 e disponibile nei livelli Premium ed Enterprise.

Vedi i dettagli del supporto
IP MAESTRO MANAGEMENT

Una sola console per il fabric

IP Maestro e un element management system per OcNOS: topologia, guasti, configurazione e immagini software su ogni switch tramite NETCONF, integrato al di sotto dell'OSS esistente. Validato fino a 250 dispositivi per istanza.

Esplora IP Maestro
AUTOMATED DAY 2

Telemetria in streaming e zero-touch

La telemetria in streaming gNMI alimenta Prometheus e Grafana, DCBX applica automaticamente le corrette impostazioni lossless a ogni server e il provisioning zero-touch avvia gli switch gia configurati all'accensione.

Esplori l'automazione
Il panorama delle AI fabric nel 2026

Dove si colloca OcNOS-DC

La maggior parte delle opzioni fa ormai le stesse cose fondamentali: RoCEv2 lossless, congestion control, adaptive routing, allineamento a Ultra Ethernet. Cio che fa davvero la differenza e la forma dell'accordo: un sistema operativo aperto oppure uno stack proprietario, hardware aperto o proprietario, Ethernet standard o InfiniBand chiuso.

Forma della soluzione Esempi Trade-off
Open NOS, AI-hardened, allineato UEC OcNOS-DC su Edgecore / UfiSpace Stesso silicio Broadcom, la stessa base tecnica. DCQCN ottimizzato per xCCL, DLB sub-ms, GLB nella roadmap 7.1, watchdog anti-deadlock PFC, profilo fabric UEC 1.0. Supporto a fornitore unico. Nessun lock-in di NIC, GPU o hardware.
Stack AI verticale chiuso NVIDIA Spectrum-X + Quantum + ConnectX Prestazioni integrate eccellenti. NIC, switch e software di fabric vincolati a un unico vendor, e a una sola roadmap GPU.
NOS chiuso su merchant silicon Arista EOS · Cisco NX-OS · Juniper Junos Sotto, lo stesso silicio Broadcom. Premio di licenza per porta. Telemetria e tuning confinati alla pipeline del singolo vendor.
Fabric chassis proprietaria basata su celle DriveNets Network Cloud Architettura diversa: cell fabric a scheduling, non un NOS Ethernet. Solida in ambito hyperscale; non portabile su switch standard.
InfiniBand closed-loop NVIDIA Quantum InfiniBand La latenza piu bassa oggi per i collective serrati. Cablaggio separato, operativita separata, ecosistema a fornitore unico. UEC colma il divario su Ethernet.
Open NOS, senza AI hardening Community SONiC Hardware aperto, software gratuito, senza SLA. I valori di default ottimizzati per xCCL, il watchdog deadlock e la maturità del tuning restano interamente a carico dell'operatore.

Ogni opzione risponde a una priorita diversa. OcNOS-DC punta su hardware aperto, una soluzione completa e nessun lock-in.

Guida al dimensionamento dell'AI Fabric

Dimensiona il tuo fabric GPU in pochi minuti

Inserisci il numero di GPU e la velocita della NIC. L'AI Fabric Design Suite lo traduce in una topologia leaf-spine, nel numero di switch e porte e in una distinta base che puoi portare direttamente a un preventivo. Nessun foglio di calcolo richiesto.

Domande frequenti

Domande frequenti

OcNOS-DC è davvero "AI-native", o solo RoCEv2 con qualche estensione?
Nessun NOS Ethernet su merchant silicon è letteralmente AI-native: nessuno elabora collettive xCCL (NCCL / RCCL / oneCCL) né schedula job sullo switch; questo compete alla NIC e allo scheduler. OcNOS-DC implementa ogni meccanismo di fabric richiesto da un workload AI nel 2026: RoCEv2 lossless, DCQCN con default validati su xCCL, DLB sotto il millisecondo, GLB (OcNOS 7.1), watchdog di deadlock PFC, allineamento a UEC 1.0: restando fuori dai layer superiori. «AI-aware fabric» di norma significa solo che un singolo vendor vende NIC + switch + scheduler come un'unica SKU vincolata.
Dove finisce OcNOS-DC e dove subentrano la NIC e lo scheduler del cluster?
OcNOS-DC presidia il layer 1: trasporto RDMA lossless, controllo della congestione, routing adattivo, recovery dei deadlock, telemetria. La NIC presidia il layer 2 (xCCL, RDMA verbs, packet spray, GPU-direct memory); lo scheduler presidia il layer 3 (collocazione dei job, finestre di gradient sync, isolamento dei tenant). OcNOS-DC trasmette telemetria gNMI verso il layer 3, ma non aspira mai a sostituire lo scheduler: questa separazione mantiene intercambiabili NIC, GPU e orchestrazione.
Come si confronta OcNOS AI Fabric con NVIDIA Spectrum-X, SONiC, Arista, Cisco o DriveNets?
Spectrum-X è uno stack chiuso NVIDIA composto da NIC, switch e software: prestazioni eccellenti, vendor lock-in totale. Arista, Cisco e Juniper offrono funzioni RoCEv2 analoghe su hardware vincolato con licenze proprietarie. La SONiC community è aperta ma non fornisce default AI-hardened, watchdog né SLA. DriveNets DDC è una cell fabric proprietaria, non un NOS Ethernet. OcNOS-DC: NOS aperto sullo stesso silicio Broadcom, allineato a UEC, DCQCN tarato per xCCL, SLA 24/7: stessa base tecnica, nessun lock-in.
Cosa significa Ultra Ethernet (UEC) 1.0 per OcNOS AI Fabric?
UEC 1.0 porta packet spray, RDMA multi-path e consegna out-of-order su Ethernet: la risposta aperta a InfiniBand. I fabric in produzione oggi utilizzano RoCEv2 + DCQCN + DLB, tutti pienamente supportati; UEC parallelizza ogni flusso su più percorsi invece di vincolarlo a un singolo hash ECMP. OcNOS-DC segue il profilo di fabric UEC 1.0, così lo switch che acquista oggi passa alle NIC UEC senza sostituire NOS o hardware. Consulti l'approfondimento su Ultra Ethernet.
Cos'è RoCEv2 e perché richiede un fabric Ethernet lossless?
RoCEv2 abilita il trasferimento diretto di memoria GPU-to-GPU senza overhead di CPU per le collettive come AllReduce e AllGather. RDMA non prevede ritrasmissione: un singolo pacchetto perso fa ripartire l'operazione su tutte le GPU: quindi una fabric lossless (PFC + ECN) è un requisito imprescindibile in esercizio. OcNOS-DC include profili di buffer RoCEv2 e default DCQCN allineati ai pattern collettivi xCCL.
Come garantisce OcNOS-DC l'assenza di perdita di pacchetti, e cosa protegge dal deadlock PFC?
Tre meccanismi: PFC mette in pausa il traffico per priorità prima che i buffer trabocchino, ECN marca i pacchetti in anticipo per rallentare i mittenti, ed ETS mantiene i flussi RDMA davanti al traffico a priorità inferiore. Sopra di essi, un watchdog di deadlock per porta e per priorità rileva i cicli di code in pausa e svuota automaticamente la coda prima che i job si blocchino: la modalità di guasto che in passato costringeva al power-cycle dello switch nel mezzo di un job. PFC su L3 è supportato attraverso i confini routed.
Cos'è il DLB e cosa cambia con GLB in OcNOS 7.1?
L'ECMP standard vincola un flusso a un singolo uplink per tutta la sua durata, generando collisioni di elephant flow durante AllReduce. DLB utilizza la telemetria live della profondità di coda dell'ASIC per ridirigere i flowlet su percorsi meno carichi entro il millisecondo, colmando la lacuna sull'hop locale. GLB (OcNOS 7.1) estende questo principio end-to-end: gli spine pubblicano telemetria di qualità del percorso verso i leaf di ingresso, così il routing si basa sull'intero punteggio multi-hop e scala in modo pulito fino a cluster da 16k GPU.
Quale scala supporta OcNOS AI Fabric, e quali sono i reference design qualificati?
OcNOS-DC supporta fabric leaf-spine 400G e 800G. Gli spine Tomahawk 5 (Edgecore AIS800-64D, UfiSpace S9321-64E) offrono 51,2 Tbps / 64 × 800G; i leaf Tomahawk 4 funzionano a 400G / 25,6 Tbps con deep buffer HBM; Trident 4 copre fabric 100G/400G più piccoli. I reference design coprono topologie rail-only, rail-optimized e Clos a 3 stadi fino a 16k GPU: consulti l'approfondimento sulle AI Fabric Topologies.
OcNOS-DC supporta automazione e telemetria per le operazioni di AI fabric?
Si. DCBX automatizza la configurazione RoCEv2 da server a switch, ZTP (IPv4/IPv6) gestisce l'onboarding zero-touch e gNMI trasmette in streaming la telemetria on-change tramite OpenConfig YANG. I pause PFC, il marking ECN, le soglie DCQCN e le profondita dei buffer sono sensor path gNMI utilizzabili da Prometheus, InfluxDB, Telegraf, Grafana o qualsiasi pipeline OpenTelemetry. I playbook Ansible e un provider Terraform coprono dal Day-0 al Day-2. IP Maestro, un element management system per OcNOS, gestisce topologia, guasti, configurazione e immagini software da un'unica console tramite NETCONF ed e validato fino a 250 dispositivi per istanza.
Quale hardware di switch e quali ottiche 800G supporta l'AI fabric OcNOS?
La fabric si basa su switch Broadcom Tomahawk 4 e 5 validati di Edgecore e UfiSpace. Gli spine 800G (Edgecore AIS800-64D e UfiSpace S9321-64E, Tomahawk 5, 64 x 800G QSFP-DD800, 51.2 Tbps) si suddividono in 400G, 200G e 100G; il leaf 400G (Edgecore AS9736-64D, Tomahawk 4, 64 x 400G QSFP56-DD, 25.6 Tbps con deep buffer) si suddivide in 100G e 25G. Le ottiche sono multi-vendor e vengono qualificate per ogni deployment, quindi contattateci per ottenere l'elenco dei transceiver validati per la vostra configurazione. Le piattaforme di switch sono elencate nella HCL.
Chi fornisce il supporto per l'AI fabric e l'hardware e coperto anche?
Un unico contratto IP Infusion copre insieme il software OcNOS-DC e l'hardware degli switch validati, quindi c'e un solo TAC e un solo SLA. Il supporto e articolato in livelli: Standard include TAC via email, telefono in orario lavorativo e coordinamento delle RMA hardware con risposta P1 entro 8 ore; Premium aggiunge un portale di supporto clienti 24/7 e una risposta P1 entro 2 ore; Enterprise aggiunge una risposta P1 entro 30 minuti e un Customer Success Manager. Il portale 24/7 e disponibile nei livelli Premium ed Enterprise.