Okay, scendiamo nei dettagli tecnici di una cosa che sulla carta sembra banale ma che in realtà è un casino: come fai a far comunicare 100.000 GPU senza che il tutto collassi al primo singhiozzo di rete?
OpenAI ha appena rilasciato MRC (Multipath Reliable Connection), un protocollo di rete sviluppato insieme ad AMD, Broadcom, Intel, Microsoft e NVIDIA. L’hanno reso open source attraverso l’Open Compute Project. La promessa? Supercomputer più veloci, più affidabili, che non si bloccano ogni volta che salta un link di rete.
Il problema: le reti tradizionali non reggono questa scala
Quando addestri modelli giganti tipo GPT, una singola iterazione può coinvolgere milioni di trasferimenti dati tra GPU. Se anche uno solo di questi arriva in ritardo, l’effetto domino può bloccare tutto il cluster. Le GPU stanno lì ferme ad aspettare. Soldi bruciati, tempo perso.
Congestione di rete, link che saltano, switch che crashano – a questa scala sono problemi costanti. Prima di MRC, bastava un singolo guasto per mandare in crash l’intero training job. Restart da checkpoint, oppure attese di decine di secondi mentre la rete ricalcolava i percorsi. Un incubo.
Il tutto peggiora esponenzialmente con la dimensione del cluster. Stargate è enorme – stiamo parlando di oltre 100.000 GPU che devono lavorare in sincronia perfetta. Ogni minuscolo intoppo si amplifica.
La soluzione: MRC cambia le regole del gioco
MRC fa tre cose fondamentali che i protocolli tradizionali non fanno.
1. Reti multi-plane: più ridondanza, meno componenti
Invece di trattare ogni interfaccia di rete come un singolo link da 800Gb/s, MRC lo divide in link più piccoli. Per esempio, otto link da 100Gb/s che si collegano a otto switch diversi. Costruisci quindi otto reti parallele separate – i cosiddetti “plane”.
Risultato pratico? Colleghi 131.000 GPU con solo due livelli di switch invece dei tre o quattro che servirebbero normalmente. Meno componenti che possono rompersi, meno energia consumata, più percorsi disponibili per far girare i dati.
Il problema è che tutta questa diversità di percorsi diventa difficile da sfruttare con i protocolli tradizionali, dove ogni trasferimento segue un singolo percorso per mantenere i pacchetti in ordine. Risultato: congestione su alcuni link mentre altri restano sottoutilizzati.
2. Packet spraying: spalmare il traffico su centinaia di percorsi
Qui sta la vera innovazione di MRC. Invece di assegnare un trasferimento a un singolo percorso, MRC prende i pacchetti di quel trasferimento e li spruzza letteralmente attraverso centinaia di percorsi diversi, usando tutti i plane disponibili contemporaneamente.
I pacchetti possono arrivare fuori ordine? Sì. Ma ogni pacchetto MRC include l’indirizzo finale di memoria, quindi la destinazione può piazzarli dove servono man mano che arrivano.
Questo elimina virtualmente la congestione nel core della rete. Niente più colli di bottiglia dove alcuni trasferimenti rallentano drammaticamente mentre altri vanno lisci. Per un training sincrono – dove tutte le GPU devono muoversi insieme – questo è critico.
MRC monitora continuamente lo stato dei percorsi. Se rileva congestione su un path, lo sostituisce immediatamente con un altro. Se perde un pacchetto, assume che ci sia un guasto e smette di usare quel percorso, ritrasmettendo i pacchetti persi. Poi manda probe packet per verificare se il guasto è reale e se si è ripreso.
C’è anche il “packet trimming”: se uno switch sta per droppare un pacchetto per congestione, invece taglia via il payload e inoltra solo l’header alla destinazione, che richiede esplicitamente la ritrasmissione. Questo riduce i falsi positivi dove si pensa ci sia un guasto quando invece è solo traffico intenso.
3. Source routing statico: addio routing dinamico
Normalmente gli switch usano protocolli di routing dinamico come BGP per calcolare i percorsi disponibili e aggirare i guasti. Ma gli switch sono dispositivi complessi che eseguono software complesso. Quando falliscono in modi sottili, i problemi diventano difficili da diagnosticare.
Con MRC, il routing dinamico non serve più. OpenAI lo ha completamente disabilitato, usando invece IPv6 Segment Routing (SRv6). Il mittente specifica direttamente il percorso che ogni pacchetto deve seguire, incorporando la sequenza di identificatori degli switch nell’indirizzo di destinazione del pacchetto.
Funziona così: quando inoltra, uno switch controlla se il suo identificatore è presente. Se sì, lo rimuove shiftando l’indirizzo di destinazione in modo che venga rivelato l’identificatore dello switch successivo. Lo switch cerca questo identificatore in una tabella di routing statica – configurata una volta sola all’inizio e mai più cambiata.
MRC usa SRv6 per spruzzare pacchetti attraverso tutti i plane della rete e molti percorsi su ogni plane simultaneamente. Se un percorso fallisce, MRC semplicemente smette di usarlo. Gli switch non devono ricalcolare niente – seguono ciecamente le rotte statiche con cui sono stati configurati.
Come funziona in produzione: dati reali
Le reti di training di OpenAI hanno milioni di link. A questa scala, alcuni link che saltano sono inevitabili. Durante il training hanno osservato casi di multipli link flap ogni minuto tra switch tier-0 e tier-1. Impatto sul training? Zero misurabile. Così irrilevante che non hanno nemmeno dovuto dare priorità alla riparazione immediata di quei link.
Durante il training di un recente modello frontier per ChatGPT e Codex, hanno dovuto riavviare quattro switch tier-1. Prima di MRC, riavviare uno switch richiedeva coordinamento attentissimo con i team operativi per non mandare in crash il training. Con MRC? Non hanno nemmeno dovuto avvisare i team che stavano facendo girare i job nel cluster.
Stesso discorso per le riparazioni dei link. Prima dovevano disabilitare un link quando serviva fare manutenzione. Ora riparano i link mentre sono ancora in servizio. Se un link funziona abbastanza bene, MRC lo usa. Se no, lo evita finché non viene fixato.
Caso interessante: se un link tra l’interfaccia di rete di una GPU e uno switch tier-0 fallisce, prima il training job crashava. Con MRC, il job sopravvive con performance ragionevoli. Se un’interfaccia da 8 porte perde una porta, il rate massimo si riduce di un ottavo. MRC lo rileva, ricalcola i percorsi per evitare il plane fallito, e dice immediatamente ai peer di non usare quel plane per il traffico in entrata. La maggior parte dei link falliti si riprende entro un minuto, momento in cui MRC riporta il plane in uso.
Il rallentamento causato dalla perdita di un link dell’interfaccia GPU è variato tra diversi training job, ma in pratica tende a essere significativamente inferiore alla quantità di capacità fisica persa.
I tre vantaggi chiave
Primo: reti multi-plane ad alta velocità per supercomputer con oltre 100.000 GPU usando solo due livelli di switch Ethernet. Ridondanza sufficiente per sopravvivere ai guasti di rete, consumando meno energia di reti equivalenti single-plane a tre o quattro livelli.
Secondo: il packet spraying adattivo di MRC bilancia il carico così bene che la congestione nel core della rete è praticamente inesistente. Questo riduce drasticamente la variazione nel throughput tra i flussi durante il training sincrono, dove eliminare gli outlier è centrale per le performance. Significa anche che quando più job condividono il cluster, non si impattano a vicenda.
Terzo: MRC usa SRv6 source routing per bypassare i guasti rapidamente e inviare pacchetti solo su percorsi funzionanti. Questo permette di far girare un control plane di rete statico e semplice, eliminando intere classi di comportamenti di fallimento del routing dinamico.
Aperto a tutti
MRC è ora disponibile come contributo all’Open Compute Project. OpenAI ha anche pubblicato un paper dettagliato: “Resilient AI Supercomputer Networking using MRC and SRv6”.
Il messaggio è chiaro: man mano che i cluster di training crescono, il design della rete determina sempre più quanto del compute disponibile può essere effettivamente utilizzato. MRC aiuta a tenere le GPU sincronizzate attraverso congestione, guasti di link ed eventi di manutenzione che prima avrebbero interrotto il training.
A questa scala, quell’affidabilità ed efficienza non è un nice-to-have – è parte di ciò che rende possibile il training sincrono di modelli frontier.
