Hai appena investito in un cluster GPU per il training AI. L'hardware è di primo livello. Lo stack software è configurato. Avvii il primo job di training distribuito, e l'utilizzo delle GPU si ferma al 41%.
Il problema non sono le GPU. Non è il modello. È la rete, la congestione RoCEv2. Ed era completamente evitabile.
Questa guida spiega cos'è RoCEv2, perché fallisce negli ambienti AI data center, quali sono le metriche che rivelano la salute della rete, e come Netmetrix, come partner certificato VIAVI, valida le configurazioni RoCEv2 prima che raggiungano la produzione.
Cos'è RoCEv2 e perché è critico per i workload AI
RoCEv2 (RDMA over Converged Ethernet version 2) è il protocollo di rete che permette ai nodi GPU di un data center AI di scambiarsi dati direttamente, bypassando completamente la CPU. Questo accesso diretto alla memoria è ciò che rende possibile il training AI distribuito su larga scala: senza di esso, la CPU diventerebbe il collo di bottiglia per ogni evento di sincronizzazione dei gradienti durante il training.
RoCEv2. RDMA over Converged Ethernet v2. Abilita trasferimenti diretti di memoria GPU-to-GPU su Ethernet standard senza coinvolgimento della CPU. Protocollo standard per il fabric dei data center AI dal 2014.
RDMA. Addestramento di un modello AI su più nodi GPU simultaneamente. Richiede sincronizzazione costante, per questo la rete è un componente critico per le performance.
Distributed Training. Pattern di traffico in cui molti nodi trasmettono simultaneamente verso una o poche destinazioni. È la principale causa di congestione RoCEv2 durante le operazioni collettive come AllReduce.
Il motivo per cui RoCEv2 è così critico per i workload AI è il pattern di traffico. Il traffico di rete tradizionale è relativamente uniforme. Il traffico AI è sincronizzato e a burst: tutti i nodi GPU trasmettono simultaneamente durante le operazioni di comunicazione collettiva (AllReduce, AlltoAll, RingAllReduce), creando condizioni di incast che l'Ethernet tradizionale non è progettato per gestire.
Qualsiasi perdita di pacchetti o ritardo nel traffico RoCEv2 blocca l'intero job di training, non solo un nodo GPU. Un singolo link congestionato può ridurre le performance di un cluster a 64 nodi del 40-70%. Per questo la validazione pre-produzione non è opzionale.
I pattern di traffico AI: perché sono diversi da tutto il resto
RingAllReduce è l'algoritmo distribuito usato durante il training AI per mediare i gradienti tra tutti i nodi GPU. I dispositivi sono disposti in un anello logico. Ogni GPU invia i propri dati di gradiente al nodo successivo mentre riceve da quello precedente in due fasi: ReduceScatter (aggregazione) e AllGather (distribuzione).
L'impatto sulla rete è un grande volume di traffico east-west sincronizzato tra tutti i nodi simultaneamente. Ogni nodo trasmette nello stesso momento. Il fabric di rete deve gestire questo senza congestione o perdita di pacchetti perché qualsiasi singolo flusso ritardato blocca l'intero job.
Cos'è il pattern AlltoAll e perché è il più esigente?
AlltoAll è il pattern di comunicazione collettiva più esigente: ogni GPU scambia dati con ogni altra GPU simultaneamente. Questo crea traffico full-mesh attraverso lo switch fabric ed è il principale stress test per le topologie leaf-spine. Gli strumenti di testing tradizionali che generano traffico uniforme non riescono a simulare le condizioni AlltoAll.
Cos'è RingAllReduce e perché sollecita la rete?
RingAllReduce è l'algoritmo distribuito utilizzato durante l'addestramento dell'IA per calcolare la media dei gradienti su tutti i nodi GPU. I dispositivi sono disposti ad anello logico. Ogni GPU invia i propri dati di gradiente al nodo successivo mentre li riceve dal precedente, in due fasi: ReduceScatter (aggregazione) e AllGather (distribuzione). L'impatto sulla rete è un elevato volume di traffico sincronizzato est-ovest tra tutti i nodi simultaneamente. Ogni nodo trasmette nello stesso momento. L'infrastruttura di rete deve gestire questo traffico senza congestione o perdita di pacchetti, perché qualsiasi singolo flusso ritardato blocca l'intero processo.
Cos'è la comunicazione AlltoAll e perché è il modello più impegnativo?
AlltoAll è il modello di comunicazione collettiva più impegnativo: ogni GPU scambia dati con tutte le altre GPU simultaneamente. Questo crea traffico full-mesh attraverso l'infrastruttura di rete ed è il principale stress test per le topologie leaf-spine. Gli strumenti di test tradizionali che generano modelli di traffico uniformi non riescono a simulare le condizioni di AlltoAll.
Cos'è la Collective Communication Library (CCL)?
La Collective Communication Library (CCL) è il livello software che coordina la sincronizzazione tra i nodi GPU. L'implementazione più diffusa è NCCL di NVIDIA. Le operazioni CCL (AllReduce, AllGather, ReduceScatter, Broadcast) generano ciascuna modelli di traffico differenti con requisiti di rete diversi. Una validazione completa deve testare tutti i modelli CCL rilevanti per i carichi di lavoro di intelligenza artificiale specifici che vengono implementati.
Sopra: AlltoAll esempio di message path da GPU0 in DGX-A a GPU3 in DGX-B
Congestione in RoCEv2: perché si verifica e come rilevarla.
RoCEv2 non ha un meccanismo nativo di controllo della congestione. Quando la rete diventa congestionata, si attivano due protocolli: PFC (Priority Flow Control) e DCQCN (Data Center Quantized Congestion Notification). Se uno dei due è configurato in modo errato, le prestazioni crollano e il problema si manifesta nelle metriche di calcolo, non in quelle di rete, motivo per cui viene spesso diagnosticato erroneamente.
PCF. Priority Flow Control. Meccanismo di livello 2 che mette in pausa il traffico per classe di priorità quando i buffer dello switch sono prossimi al sovraccarico. Previene la perdita di pacchetti, ma può causare deadlock se configurato in modo errato.
DCQC. Data Center Quantized Congestion Notification. Algoritmo di controllo della congestione per RoCEv2. Riduce la velocità di trasmissione del mittente quando viene rilevata congestione tramite marcatura ECN.
ECN. Explicit Congestion Notification. Meccanismo a livello IP che contrassegna i pacchetti quando attraversano uno switch congestionato, segnalando ai mittenti di ridurre la loro velocità.
CNP. Congestion Notification Packet. Generato dalla scheda di rete del ricevitore quando rileva pacchetti contrassegnati con ECN. Inviato al mittente per attivare la riduzione della velocità.
PFC Operation
▸ La comparsa di frame di pausa PFC sulle porte dello switch rivolte verso la GPU indica che la congestione ha già raggiunto un livello critico.
▸ L'utilizzo della GPU scende al di sotto del 60% durante l'addestramento distribuito senza alcun collo di bottiglia a livello di modello.
▸ La latenza delle operazioni collettive AllReduce o AlltoAll presenta picchi irregolari tra le iterazioni di addestramento.
▸ Il tasso di ritrasmissione dei pacchetti è superiore allo 0,01% sul traffico tra i nodi; anche questa piccola quantità causa un visibile degrado delle prestazioni.
▸ L'elevata varianza del tempo di completamento del job (JCT) indica che lo stesso job di addestramento richiede tempi diversi tra le varie esecuzioni a causa dell'instabilità della rete.
Il dettaglio cruciale riguardo ai frame di pausa PFC è che rappresentano l'ultima linea di difesa prima che si verifichi la perdita di pacchetti. La loro comparsa in produzione indica che la congestione è già grave. Quando si notano le pause PFC nel sistema di monitoraggio, si è già verificata una significativa perdita di prestazioni della GPU per un periodo di tempo imprecisato.
| Metric | Healthy | Warning | Critical |
| GPU utilisation (distributed training) | 85-95% | 60-84% | < 60% |
| Packet retransmission rate | < 0.001% | 0.001-0.01% | > 0.01% |
| PFC pause frames per minute | 0 | 1-50 | > 50 |
| AllReduce latency p95 | < 50ms | 50-200ms | > 200ms |
| Job Completion Time variance | < 5% | 5-15% | > 15% |
| ECN marking rate | < 1% | 1-5% | > 5% |
Come Netmetrix convalida RoCEv2: il framework in 4 fasi
In qualità di partner certificato VIAVI, operante in Italia, Spagna, Francia, Portogallo e Regno Unito, Netmetrix applica un framework di convalida strutturato prima di ogni messa in produzione di un data center per l'intelligenza artificiale.
Il framework utilizza appliance VIAVI TestCenter (serie A1-400G e B3-800G) per emulare modelli di traffico AI realistici, inclusi i pattern RoCEv2, RingAllReduce, AlltoAll e CCL, in condizioni che corrispondono ai carichi di lavoro di produzione effettivi.
1. Caratterizzazione di base
Misurare il throughput e la latenza per ogni percorso GPU-to-GPU nella rete. Caratterizzare il comportamento del buffer dello switch sotto carico crescente. Stabilire la frequenza dei frame di pausa PFC al carico nominale come riferimento di base. Documentare le soglie di marcatura ECN per ogni switch.
2. Test di stress con Incast
Simulare modelli di traffico AllReduce al 25%, 50%, 75% e 100% della capacità di progetto. Iniettare scenari Incast, N nodi verso 1 destinazione simultaneamente, con dimensioni di burst variabili. Misurare il tasso di perdita di pacchetti, il tasso di ritrasmissione e il degrado del throughput a ogni livello di carico. Identificare il punto di inizio della congestione in cui le prestazioni si degradano in modo non lineare.
3. Validazione della configurazione DCQCN
Testare le impostazioni correnti dei parametri DCQCN rispetto agli scenari Incast. Iterare la configurazione dei parametri e ripetere il test fino a quando la frequenza di pausa PFC non scende al di sotto della soglia. Verificare che la configurazione non introduca nuove modalità di errore, come una risposta alla congestione insufficiente. Documentare il set di parametri finale validato per la distribuzione in produzione.
4. Approvazione per la produzione
Eseguire una simulazione completa del carico di lavoro AI distribuito alla capacità di progetto per un minimo di 4 ore. Verificare che l'utilizzo della GPU sia superiore all'85% sotto carico costante. Verificare che la perdita di pacchetti sia pari a zero e che il tasso di pausa PFC sia inferiore allo 0,001%. Redigere il report di test con tutte le metriche documentate come documento di approvazione per la produzione.
FAQ
D: Qual è la differenza tra RoCEv2 e InfiniBand per i data center di IA?
R: InfiniBand offre una latenza leggermente inferiore e un controllo della congestione storicamente più efficace, ma richiede hardware e infrastrutture dedicati. RoCEv2 funziona su Ethernet standard, supporta il routing di livello 3 e può scalare su implementazioni multi-rack e multi-sito senza switch dedicati. Per la maggior parte delle implementazioni di IA aziendali e hyperscale, RoCEv2 su Ethernet 100G/400G è la scelta standard. La metodologia di validazione per entrambi i protocolli condivide gli stessi requisiti fondamentali: test incast, verifica del controllo della congestione ed emulazione del modello di comunicazione collettiva.
D: Perché l'utilizzo della GPU diminuisce durante l'addestramento distribuito di IA?
R: La causa più comune è la congestione della rete nella struttura RoCEv2, in particolare gli eventi incast durante le operazioni AllReduce, in cui tutti i nodi GPU trasmettono simultaneamente per sincronizzare i gradienti. Quando la rete si congestiona, i nodi GPU si bloccano in attesa del completamento della sincronizzazione, manifestandosi come un basso utilizzo della GPU nel monitoraggio del calcolo. Altre cause includono la configurazione errata di DCQCN, il deadlock PFC e lo squilibrio di routing ECMP. Una validazione pre-produzione strutturata, che esegue test con modelli di traffico CCL realistici, identifica la causa prima che il sistema venga messo in produzione.
D: Quali strumenti vengono utilizzati per la validazione di RoCEv2 nei data center per l'IA?
R: La validazione professionale di RoCEv2 richiede piattaforme di generazione di traffico appositamente progettate, in grado di emulare modelli specifici per l'IA, tra cui operazioni RingAllReduce, AlltoAll e CCL alla velocità di linea. Netmetrix utilizza appliance VIAVI TestCenter (serie A1-400G-16-port e B3-800G) a questo scopo. Strumenti di base come iPerf non sono in grado di emulare i modelli di burst sincronizzati dei carichi di lavoro di training per l'IA e non sono adatti alla validazione pre-produzione delle infrastrutture dei data center per l'IA.
D: Cos'è DCQCN e come previene la congestione di RoCEv2?
R: DCQCN (Data Center Quantized Congestion Notification) è l'algoritmo di controllo della congestione progettato per RoCEv2. Quando uno switch rileva congestione, contrassegna i pacchetti con bit ECN (Explicit Congestion Notification). La scheda di rete ricevente genera pacchetti CNP (Congestion Notification Packets) e li invia al mittente. Il mittente riduce la sua velocità di trasmissione in modo moltiplicativo quando riceve un pacchetto CNP. Quando non viene rilevata congestione per un periodo configurabile, la velocità aumenta gradualmente. Parametri DCQCN errati, in particolare il valore Alpha e le soglie di aumento/diminuzione della velocità, sono la causa più comune di problemi di prestazioni di RoCEv2 in produzione.
D: Quanto tempo richiede la validazione di RoCEv2 prima della messa in produzione di un data center?
R: Un processo completo di validazione di Netmetrix RoCEv2, che comprende la caratterizzazione della baseline, i test di stress incast, la configurazione di DCQCN e l'approvazione per la prontezza alla produzione, richiede in genere da 2 a 3 settimane. Per le tempistiche di messa in produzione urgenti, è disponibile una valutazione accelerata di 5 giorni che copre gli scenari a più alto rischio. Il documento di approvazione prodotto include tutti i risultati dei test, i parametri di configurazione convalidati e la determinazione della prontezza per la produzione.
D: È possibile eseguire la convalida di RoCEv2 senza apparecchiature specializzate?
R: La caratterizzazione di base può essere eseguita con strumenti open source come ib_send_bw e i test NCCL. La convalida completa, che include la simulazione incast su larga scala, la messa a punto dei parametri DCQCN e l'approvazione della prontezza per la produzione, richiede piattaforme professionali di generazione di traffico in grado di emulare i pattern CCL specifici dell'IA alla velocità di linea. Netmetrix utilizza VIAVI TestCenter a questo scopo, che fornisce l'emulazione del traffico, la precisione di misurazione e la qualità di reporting necessarie per una determinazione documentata della prontezza per la produzione.
Per la validazione dei modelli LLM, consulta la guida dedicata.
Questo articolo si basa sui concetti e sulla ricerca del white paper VIAVI Solutions 'AI/ML Data Center Network Validation' (2025) e sull'esperienza sul campo di Netmetrix come partner certificato VIAVI in area EMEA.
