Home · Risorse · Come scegliere un fabric di rete AI
Guida all'acquisto vendor-neutral

Come scegliere un fabric di rete AI

Le vostre GPU raggiungono il throughput nominale solo se il fabric sottostante tiene il passo. Questo è un framework vendor-neutral per valutare un AI fabric sui sei criteri che lo determinano, prima di firmare.

Come si sceglie un fabric di rete AI? Valutate i candidati secondo sei criteri: prestazioni lossless sul piano GPU (RoCEv2 con PFC, ECN e bilanciamento dinamico del carico), scala e topologia adatte al vostro numero di GPU, apertura rispetto al lock-in del fornitore, operazioni e telemetria, responsabilità del supporto sotto un unico contratto e roadmap degli standard, incluso Ultra Ethernet. Mettete al primo posto l'assenza di perdite, perché protegge il throughput del training, poi pesate il resto in base al vostro piano di crescita.

Considerate il fabric come un'unica decisione, composta da sei

Un fabric di rete AI si acquista una volta e lo si usa per anni, quindi valutatelo in base a come sei proprietà si adattano al modo in cui gestirete il cluster, non su un singolo numero di punta. Sul tavolo ci sono tre tipi di fabric:

  • Gli stack chiusi single-vendor raggruppano NIC, switch e scheduler in un unico SKU e fissano i compromessi al posto vostro.
  • I NOS community e open source vi danno il codice ma lasciano a voi integrazione e supporto.
  • I NOS commerciali aperti mantengono la libertà di scelta dell'hardware e includono un contratto di supporto.

I criteri seguenti valutano ciascuno di essi alle stesse condizioni.

1

Prestazioni e assenza di perdite

Le collective AI usano RDMA, e RDMA richiede un substrato lossless. RoCEv2 lo offre su Ethernet, ma solo con il toolkit completo di gestione della congestione, non come una casella da spuntare. Un fabric che gestisce male le pause o scarta pacchetti sotto carico è la causa più comune di un throughput di training bloccato, quindi risolvete questo criterio per primo.

Cosa chiedere

  • Fornite il fabric Ethernet lossless richiesto da RoCEv2, incluso PFC su L3 con DCBX e LLDP?
  • È presente la marcatura ECN, ed esiste una variante dinamica che adatta le soglie sotto carico?
  • Sono previsti rilevamento e ripristino dei deadlock PFC, oltre a WRED e tuning dei buffer?
  • Come viene contenuta la tail-latency quando un link si satura durante una collective?

Come valutare

Chiedete le funzionalità di gestione della congestione esatte e verificate che funzionino sul silicio che acquisterete. Una risposta credibile cita PFC (anche su L3, con DCBX e LLDP), ECN e Dynamic ECN, ETS, WRED, rilevamento e ripristino dei deadlock PFC, e un load balancing dinamico che sposta i flussi dai link saturi. Un hash statico può lasciare grandi flussi in collisione su un sottoinsieme di link, mentre il load balancing dinamico su Tomahawk 4 e Tomahawk 5 punta a un utilizzo del fabric intorno al 90%, quindi trattatelo come una funzionalità di throughput, non come un optional. Consultate il RoCE vs InfiniBand confronto per capire in che cosa il modello lossless differisce dal controllo di flusso a crediti di InfiniBand.

2

Scala e adeguatezza della topologia

La topologia giusta è il design non bloccante più piccolo che mantiene saturo il link di ogni GPU durante una collective, con un percorso pulito verso la dimensione successiva. Una topologia che non può crescere impone in seguito una sostituzione completa, quindi dimensionate per dove il cluster sta andando, non per dove parte.

Cosa chiedere

  • Il piano GPU è 1:1 non bloccante, e dove inizia l'oversubscription?
  • Qual è il cluster più grande che questo design raggiunge prima di dover aggiungere un livello?
  • Supporta il cablaggio rail-optimized e un livello super-spine per la scala multi-pod?

Come valutare

Confrontate i candidati con numeri di GPU concreti. Sugli switch Tomahawk 5, un leaf-spine a 2 livelli raggiunge 4.096 GPU a 1:1 non bloccante con 800G per GPU, con ogni switch configurato come 128×400G e ogni GPU su due porte leaf a 400G. Oltre, un livello super-spine sopra gli stessi pod rail-optimized si estende a 16.000+ GPU. Utilizzate rail-optimized per la località single-pod e un Clos per la scala multi-pod; i topologie di riferimento mostrano i calcoli sulle porte, e la Suite di progettazione per fabric AI fornisce un primo dimensionamento.

3

Apertura e lock-in

Un AI fabric chiuso lega NIC, switch e scheduler a un unico fornitore, che stabilisce prezzi e roadmap al posto vostro. Un approccio aperto esegue un NOS commerciale su silicio Ethernet standard di più di un vendor hardware, così mantenete la scelta dell'hardware e potete ricorrere a una seconda fonte. È qui che si decidono il costo pluriennale e il potere negoziale.

Cosa chiedere

  • Switch, NOS e ottiche possono essere acquistati ciascuno in modo indipendente?
  • Il fabric si basa su Ethernet pubblicato e basato su standard, o su un trasporto proprietario?
  • Esiste più di una piattaforma hardware qualificata per lo stesso software?

Come valutare

Cercate una lista di hardware qualificato con più di un vendor alle spalle. I NOS commerciali aperti eseguono lo stesso software su piattaforme Broadcom Tomahawk 5 di produttori diversi, ad esempio Edgecore AIS800-64D e UfiSpace S9321-64E, rendendo una seconda fonte reale e non teorica. Al contrario, gli SKU chiusi single-vendor di NIC, switch e scheduler funzionano solo insieme. La domanda utile non è un prodotto contro un altro, ma quanti fornitori potete ritenere responsabili dello stesso fabric.

4

Operazioni, automazione e telemetria

Un fabric difficile da avviare o cieco in produzione costa più del suo prezzo. Il modello operativo, cioè come eseguite provisioning, osservazione e tuning, è un criterio d'acquisto di primo piano, non un ripensamento una volta arrivato l'hardware.

Cosa chiedere

  • Esiste una telemetria in streaming via gNMI con modelli OpenConfig?
  • È supportato lo zero-touch provisioning (ZTP) per l'avvio del fabric su larga scala?
  • Si automatizza con strumenti standard come Ansible, e segnala la QoS con DCBX?

Come valutare

Chiedete di vedere telemetria e automazione nella documentazione del candidato stesso, non su una slide. Una risposta solida copre la telemetria in streaming gNMI e OpenConfig verso il vostro stack di osservabilità, ZTP per il provisioning, DCBX e LLDP per la segnalazione lossless e una configurazione basata su Ansible. Il punto è il tuning a ciclo chiuso durante l'avvio: contatori per coda e stato dei buffer che potete osservare mentre affinate le soglie PFC ed ECN, non una scatola nera che si imposta una volta sperando per il meglio.

5

Supporto e responsabilità

Quando un training si blocca alle 3 di notte, la domanda è a chi spetta la soluzione. Un build multi-vendor senza un unico contratto responsabile si trasforma in un rimpallo di responsabilità tra i vendor di NIC, switch, ottiche e software. Il rimedio è un solo contratto, non un solo stack chiuso.

Cosa chiedere

  • Esiste un unico contratto di supporto che copra il software e l'hardware qualificato?
  • C'è un solo TAC e un solo SLA, o più di uno da coordinare?
  • Chi ha validato la specifica combinazione di hardware e software che state acquistando?

Come valutare

Separate la responsabilità dal lock-in: volete la responsabilità di un singolo vendor senza l'hardware di un singolo vendor. Il modello solido è la scelta aperta dell'hardware abbinata a un unico accordo di supporto, un contratto che copre il software più l'hardware qualificato, un TAC, un SLA, così un guasto ha un responsabile end-to-end anche se avete acquistato i componenti in modo aperto.

6

Standard e roadmap

Il trasporto per i fabric AI evolve rapidamente. L'Ultra Ethernet Consortium (UEC) pubblica un trasporto Ethernet multipath aperto per AI e HPC, il cui comportamento endpoint funziona su NIC compatibili UEC, quindi distinguete ciò che ogni fornitore esegue oggi in produzione da ciò che pianifica.

Cosa chiedere

  • Il fornitore è membro dell'Ultra Ethernet Consortium?
  • Cosa esegue oggi il fabric in produzione, e su quale silicio?
  • Cosa prevede la roadmap a breve termine per load balancing e controllo della congestione?

Come valutare

Separate ciò che viene rilasciato da ciò che è pianificato. IP Infusion è membro dell'Ultra Ethernet Consortium, e OcNOS-DC esegue oggi in produzione RoCEv2 lossless con PFC, marcatura ECN e DLB su switch Broadcom Tomahawk 4 e Tomahawk 5. DCQCN viene eseguito sulle NIC e reagisce a queste marcature ECN. Il Global Load Balancing (GLB) arriva con OcNOS 7.1. Sulla roadmap, chiedete voci precise: ECN basato sulla latenza (7.1.0), link-level retry, controllo di flusso basato su crediti e packet trimming. Si veda InfiniBand vs Ethernet per un confronto con la via aperta.

La checklist dell'acquirente

Sottoponete ogni fabric candidato, stack chiuso single-vendor, NOS community o NOS commerciale aperto, alla stessa lista. Se una casella non può essere spuntata, chiedete perché prima di decidere che non conta.

  • Substrato lossless. RoCEv2 con PFC (anche su L3, DCBX, LLDP), ECN e Dynamic ECN, ETS, WRED, e rilevamento e ripristino dei deadlock PFC.
  • Load balancing dinamico. I flussi vengono spostati dai link saturi, non solo con hashing ECMP statico.
  • Piano GPU 1:1 non bloccante. Nessuna oversubscription sul fabric GPU, dimensionato per il vostro numero di GPU target con margine fino al livello successivo.
  • Adeguatezza della topologia. Design single-pod rail-optimized e multi-pod a tre livelli sul silicio che acquistate.
  • Scelta dell'hardware. Più di un vendor hardware qualificato per lo stesso NOS, così una seconda fonte è reale.
  • Trasporto aperto. Ethernet basato su standard, non un bundle proprietario di NIC, switch e scheduler.
  • Telemetria e automazione. Telemetria in streaming gNMI e OpenConfig, ZTP, DCBX e Ansible.
  • Un unico contratto responsabile. Un unico accordo di supporto per software e hardware acquistati come un unico sistema, un TAC, un SLA.
  • Roadmap degli standard. Il fornitore è membro dell'Ultra Ethernet Consortium e indica le voci di roadmap per bilanciamento del carico e controllo della congestione.

Dove si colloca l'Ethernet aperto con OcNOS-DC

Leggete i criteri qui sopra e scegliete ciò che ottiene il punteggio migliore per il vostro cluster. Per gli acquirenti che vogliono una scelta aperta dell'hardware con un unico contratto responsabile, ecco come si posiziona IP Infusion rispetto alla stessa checklist, esposto in modo chiaro così da poterlo confrontare con le alternative.

Fabric RoCEv2 in produzione

OcNOS-DC fornisce il fabric Ethernet lossless richiesto da RoCEv2 su Broadcom Tomahawk 5: PFC su L3 con DCBX e LLDP, ECN e Dynamic ECN, ETS, WRED, rilevamento e ripristino dei deadlock PFC, e DLB con ribilanciamento reattivo dei percorsi.

Da 4.096 a 16.000+ GPU

Un pod TH5 a 2 livelli raggiunge 4.096 GPU a 1:1 non bloccante con 800G per GPU; oltre, un livello super-spine si estende a 16.000+ GPU.

Hardware multi-vendor

Un unico NOS su piattaforme Tomahawk 5 di più produttori, tra cui Edgecore AIS800-64D e UfiSpace S9321-64E e S9321-64EO con 400G ZR+, così una seconda fonte resta reale.

Telemetria e automazione aperte

Telemetria in streaming gNMI e OpenConfig, ZTP, DCBX e Ansible, con hashing RTAG7 e tuning dei buffer per un avvio a ciclo chiuso.

OcNOS Systems: un contratto, un TAC, un SLA

Con OcNOS Systems, un unico accordo IP Infusion copre il software OcNOS e l'hardware qualificato, così ottenete la responsabilità di un unico fornitore senza il lock-in di un unico fornitore.

Membro UEC, roadmap specifica

IP Infusion è membro dell'Ultra Ethernet Consortium. GLB arriva con OcNOS 7.1, e l'ECN basato sulla latenza è sul ramo OcNOS 7.1 per OcNOS-DC.

Soluzione AI fabric Topologie di fabric AI Rete rail-optimized InfiniBand vs Ethernet RoCE vs InfiniBand Suite di progettazione per fabric AI

FAQ della guida all'acquisto di AI fabric

Cosa devo valutare per prima cosa nella scelta di un AI fabric?
Partite dalle prestazioni lossless sul piano GPU, perché sono ciò che protegge il throughput di training. Verificate che il fabric fornisca il substrato RoCEv2 lossless richiesto da RDMA: PFC (anche su L3, con segnalazione DCBX e LLDP), marcatura ECN e Dynamic ECN, WRED, e rilevamento e ripristino dei deadlock PFC. Verificate poi il load balancing dinamico, così che nessun link diventi un hot-spot durante le collective. Solo dopo aver risolto le prestazioni dovreste valutare scala, apertura, operazioni, supporto e roadmap.
Per l'AI è meglio Ethernet o InfiniBand?
Entrambi possono trasportare traffico AI; la differenza sta nell'ecosistema e nel lock-in. InfiniBand è uno stack single-vendor con cablaggio e gestione propri. Ethernet è multi-vendor e basato su standard: RoCEv2 con PFC ed ECN offre oggi RDMA lossless, e la direzione dell'Ultra Ethernet Consortium (UEC) colma il divario di prestazioni residuo su hardware aperto. Per gli acquirenti che vogliono scegliere l'hardware senza dipendere da un singolo vendor, l'Ethernet aperto è la via con minore lock-in. Si vedano i nostri InfiniBand vs Ethernet e RoCE vs InfiniBand confronti.
Per quante GPU devo pianificare?
Pianificate per il cluster verso cui crescerete, non solo per quello che acquistate per primo, così che la topologia non imponga una ricostruzione. Sugli switch Tomahawk 5, un leaf-spine a 2 livelli raggiunge 4.096 GPU a 1:1 non bloccante con 800G per GPU, con ogni switch configurato come 128×400G e ogni GPU su due porte leaf a 400G. Oltre, un livello super-spine sopra gli stessi pod rail-optimized si estende a 16.000+ GPU. Fate un primo dimensionamento con il Suite di progettazione per fabric AI.
Come evito il vendor lock-in?
Separate i livelli che acquistate. Un AI fabric chiuso lega NIC, switch e scheduler a un unico fornitore, così prezzi e roadmap vengono stabiliti al posto vostro. Un approccio di open networking vi permette di eseguire un NOS commerciale su silicio Ethernet standard di più di un vendor hardware, così mantenete la scelta dell'hardware e potete ricorrere a una seconda fonte. Chiedete se switch, NOS e ottiche possono essere acquistati ciascuno in modo indipendente, e se il fabric gira su Ethernet pubblicato e basato su standard anziché su un trasporto proprietario.
Cosa significa UEC per il mio acquisto?
L'Ultra Ethernet Consortium (UEC) pubblica un trasporto Ethernet multipath aperto per AI e HPC. UEC 1.0 distribuisce un flusso su molti percorsi, con questo comportamento endpoint eseguito su NIC compatibili UEC. Per un acquisto oggi, basatevi su ciò che il fabric esegue in produzione adesso e chiedete a ogni fornitore voci di roadmap specifiche. IP Infusion è membro dell'UEC, e OcNOS-DC esegue già in produzione RoCEv2 lossless con PFC, marcatura ECN e DLB su switch Broadcom Tomahawk 4 e Tomahawk 5. DCQCN viene eseguito sulle NIC e reagisce a queste marcature ECN.
Ho bisogno di un unico vendor per hardware e software?
Vi serve un unico contratto responsabile, che non equivale a un unico stack chiuso. Con l'open networking scegliete separatamente l'hardware dello switch e il NOS, poi li acquistate con un unico accordo di supporto. Con IP Infusion, quando acquistate gli switch come OcNOS Systems, un contratto copre il software OcNOS e l'hardware, con un TAC e un SLA, così ottenete la responsabilità di un singolo vendor senza il lock-in di un singolo vendor. Per l'hardware che comprate voi stessi, IP Infusion supporta il software e il produttore supporta l'hardware.

Progettate l'intera fabric AI con OcNOS

Dal business case al calcolo del numero di porte, riprendete da qualunque punto della realizzazione.

Soluzione Fabric AI aperta La fabric AI a 800G completa: switch aperti, OcNOS-DC e supporto sotto un unico contratto. Design di riferimento Topologie di fabric AI Fabric rail-optimized a due e tre livelli, e DCI coerente, dimensionati in numeri reali di porte. Dimensionamento e realizzazione Suite di progettazione per fabric AI Dimensionate una fabric GPU: conteggi di leaf, spine e super-spine con un riepilogo di componenti e alimentazione.
Primi passi con le fabric AI? Iniziate qui Cos'è una fabric AI? Cos'è una fabric GPU? Cos'è l'Ethernet senza perdite? Cos'è RDMA? Switch per AI networking
La tecnologia all'interno RoCEv2 senza perdite Rete rail-optimized DLB GLB (7.1) Ultra Ethernet Tomahawk 5 Tomahawk 6 a 1.6T Silicio Broadcom DCQCN Deadlock PFC InfiniBand vs Ethernet RoCE vs InfiniBand Architettura della fabric AI DCI coerente
Valuta la fabric Come scegliere un fabric di rete AI Prove dell'AI fabric Neocloud networking

Approfondite. Portatelo con voi.

Due download brevi e tecnici che vanno oltre questa pagina: il datasheet completo di OcNOS-DC e l'architettura della fabric AI lossless a 800G.

Datasheet

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
Solution brief

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

State valutando i fabric per il vostro cluster? Esaminiamo la checklist insieme a voi.

Prenota una Architecture Review →