Meta ha presentato MetaRoCE, un nuovo protocollo di trasporto RDMA progettato specificamente per i grandi carichi di lavoro AI e per ridurre i colli di bottiglia di rete nei cluster composti da decine o centinaia di migliaia di GPU. Il sistema nasce dalla necessità di sostenere comunicazioni sempre più intense tra acceleratori durante training e inferenza di modelli di grandi dimensioni, dove velocità, stabilità e prevedibilità del trasferimento dati incidono direttamente sulle prestazioni complessive. Meta gestisce già centinaia di migliaia di GPU ad alte prestazioni e, per un singolo processo di training, può utilizzare contemporaneamente oltre 32.000 GPU per diverse settimane.
Le implementazioni tradizionali ad alta velocità sono state progettate sulla base di un principio molto rigido: nessun dato deve andare perso e l’ordine dei pacchetti deve essere preservato. In presenza di congestione o blocchi localizzati, questo approccio può portare a fermare porzioni molto estese del traffico per evitare inconsistenze, aumentando il rischio di deadlock e provocando rallentamenti che si propagano all’intera rete. MetaRoCE cambia impostazione spostando parte della logica di controllo dagli switch alle schede di rete, cioè alle NIC, e adottando un’architettura end-to-end nella quale sono gli endpoint a gestire direttamente una parte maggiore delle decisioni di trasporto.
La scelta consente di semplificare l’infrastruttura centrale e di utilizzare comuni apparati Ethernet ad alta capacità invece di dipendere da una rete costruita attorno a componenti specializzati particolarmente complessi. In un cluster composto da centinaia di migliaia di acceleratori, questa differenza incide sia sulla scalabilità sia sui costi, perché riduce la quantità di intelligenza che deve essere implementata e coordinata all’interno degli switch e trasferisce una maggiore responsabilità alle NIC installate sui nodi.
MetaRoCE è stato progettato per trattare il riordinamento e la perdita dei pacchetti come condizioni normali della rete, invece di considerarli eventi eccezionali da prevenire a ogni costo. I dati possono essere suddivisi su più percorsi e arrivare al destinatario fuori sequenza; la NIC ricevente è in grado di gestirli e collocarli direttamente in memoria senza attendere necessariamente che tutti i pacchetti precedenti siano arrivati. Questo elimina una parte dei tempi morti legati al riordinamento e permette di utilizzare in modo più efficace reti multipath.
Anche la gestione delle perdite cambia rispetto alle implementazioni più rigide. Se uno o più pacchetti non raggiungono il destinatario, il sistema non interrompe l’intero flusso, ma identifica esattamente i dati mancanti e richiede soltanto la loro ritrasmissione. In questo modo il protocollo evita di bloccare traffico che sta già procedendo correttamente e riduce l’impatto della perdita di pacchetti sulle prestazioni complessive del cluster.
Il controllo della congestione utilizza informazioni raccolte in tempo reale sul percorso di rete. La NIC ricevente misura le variazioni dell’RTT, cioè il tempo di andata e ritorno dei pacchetti, e combina questi dati con i segnali ECN, Explicit Congestion Notification. In questo modo MetaRoCE può correggere la velocità di trasmissione prima che i buffer degli switch raggiungano livelli critici. Il sistema è stato progettato anche per le situazioni di incast, nelle quali molti nodi trasmettono simultaneamente verso uno stesso destinatario, facendo convergere grandi quantità di traffico su un punto comune. In questi scenari gli endpoint possono convergere verso una velocità di trasmissione adeguata nell’arco di uno o due round trip.
Meta ha verificato MetaRoCE su cluster GPU equipaggiati con schede di rete AMD. Nei test con operazioni All-Reduce e All-To-All, due schemi di comunicazione particolarmente importanti nei carichi di lavoro distribuiti di intelligenza artificiale, il nuovo protocollo ha mostrato un incremento del throughput e una maggiore capacità di mantenere prestazioni elevate in presenza di perdita di pacchetti. Con un packet loss dell’1%, la rete ha conservato circa l’86% del throughput, mentre anche con un tasso di perdita del 10%, considerato una condizione di congestione estrema, il sistema ha continuato a mantenere una quantità utile di banda senza subire un crollo improvviso delle prestazioni.
Ulteriori prove sono state effettuate utilizzando architetture multipath composte da quattro e otto network plane. In queste configurazioni MetaRoCE ha gestito in modo stabile fino a 4.000 connessioni contemporanee. Quando uno dei plane diventava indisponibile, il traffico veniva ridistribuito automaticamente sugli altri percorsi disponibili senza richiedere l’intervento manuale di un operatore. Questa capacità permette al sistema di mantenere le comunicazioni attive anche in presenza di guasti localizzati all’interno della rete.
La differenza rispetto alle reti tradizionali riguarda quindi anche il livello di visibilità e controllo disponibile agli endpoint. Invece di trattare la rete come un unico collegamento poco trasparente, MetaRoCE suddivide il traffico su percorsi più precisi e lascia alle NIC il compito di controllare l’invio, la ricezione, il riordinamento, la ritrasmissione dei dati mancanti e parte della gestione della congestione. Questo consente di sfruttare maggiormente la capacità aggregata di più percorsi senza richiedere che la rete centrale garantisca sempre un comportamento perfettamente ordinato e privo di perdite.
Meta intende sviluppare MetaRoCE come tecnologia indipendente da un singolo produttore di semiconduttori. Il protocollo sarà portato nell’ecosistema dell’Open Compute Project, OCP, attraverso la pubblicazione delle specifiche standard, degli strumenti per la verifica della compatibilità e di un modello software di riferimento chiamato libsoftmetaroce. L’obiettivo è consentire a produttori differenti di implementare e validare il protocollo senza legarlo a una specifica famiglia di NIC o acceleratori.
Ulteriori dettagli tecnici su MetaRoCE saranno presentati durante l’OCP Global Summit previsto per ottobre. Il progetto nasce quindi come intervento diretto sull’infrastruttura di rete dei cluster AI, con l’obiettivo di sostenere sistemi distribuiti nei quali decine di migliaia di GPU devono comunicare contemporaneamente senza lasciare che congestioni, perdita di pacchetti o guasti localizzati degradino l’intero processo di training o inferenza.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)