Le 24 août, Meta a publié les détails de conception de MetaRoCE, un protocole de transport RDMA développé en interne pour remplacer le RoCE standard. Lors de l'OCP Global Summit d'octobre, la spécification complète du protocole, une implémentation de référence baptisée libsoftmetaroce et une suite de tests de conformité pour la production seront publiées ensemble.
Le RoCE standard ne tient plus à l'échelle de centaines de milliers de cartes
RoCE a été conçu en partant du principe que le réseau livre chaque trame dans l'ordre, en s'appuyant sur le PFC (Priority Flow Control) des switches pour garantir l'absence de pertes de paquets. Cette hypothèse fonctionne plutôt bien sur des clusters de quelques centaines de cartes, mais commence à craquer à l'échelle actuelle de Meta.
Selon Meta, le RoCE standard attend une livraison ordonnée de chaque trame, dépend du PFC et déconseille le packet spraying — qui est justement la technique utilisée pour améliorer les performances dans les grands réseaux à plusieurs plans. C'est là que se situe le conflit : répartir les paquets d'un même flux sur plusieurs chemins à la fois va directement à l'encontre de la "livraison ordonnée". Le PFC fonctionne aussi par contre-pression de proche en proche : une congestion à un endroit se répercute en arrière sur tout le trajet, ce qui peut provoquer des effets en cascade à très grande échelle. Or les communications collectives comme all-reduce doivent synchroniser des milliers d'accélérateurs, et c'est le transfert le plus lent qui fixe le rythme de l'ensemble du job.
Le scénario cible évoqué par Meta est celui de "plusieurs centaines de milliers de GPU répartis sur plusieurs data centers et plusieurs régions". À cette échelle, compter sur les switches pour maintenir un réseau sans perte revient déjà à jouer avec les probabilités.
L'intelligence se déplace vers la carte réseau
Meta résume le principe de conception de MetaRoCE en une phrase :
"The fabric sees packets, but the NIC sees intent."
Le réseau ne voit que des paquets ; c'est la carte réseau qui comprend l'intention.
Cela se traduit en six points concrets : livraison native dans le désordre, avec des paquets délibérément dispersés sur plusieurs chemins et des données écrites directement à l'adresse mémoire de destination, sans tampon de réordonnancement ; multichemin natif, chaque connexion maintenant plusieurs chemins logiques qui suivent chacun leur propre latence aller-retour et leur état ECN ; tolérance à la perte de paquets, traitée comme la norme et compensée par une carte de bits d'accusés de réception sélectifs, sans besoin de PFC ; double contrôle de congestion, combinant AIMD côté émetteur et des indications de débit équitable côté récepteur ; indépendance vis-à-vis de la topologie, qui n'exige que le marquage ECN et l'ECMP, et fonctionne aussi bien sur du fat-tree, du multi-plan ou des switches à tampons réduits ; et connexion unifiée, où une seule file transporte plusieurs flux de messages ordonnés et plusieurs chemins, en partageant un seul contrôleur de congestion.
Les chiffres du test sur 64 nœuds
Les tests ont été menés sur un cluster de 64 nœuds équipés de GPU AMD. Le débit est resté systématiquement supérieur à celui de RoCEv2 ; avec 1% de pertes de paquets, environ 86% du débit était conservé, et avec 10% de pertes, le système restait opérationnel. Sur des topologies à 4 et 8 plans, le débit a évolué de façon linéaire, avec des tests allant jusqu'à 4 000 connexions simultanées. En cas de défaillance d'un seul plan, le trafic se redistribue de lui-même, sans intervention de la couche applicative.
Entre 64 nœuds et "plusieurs centaines de milliers de cartes", le chemin reste long. Meta divise lui-même les travaux à venir en trois axes : le scale-up à l'intérieur d'un rack doit optimiser la signalisation rapide pour les opérations mémoire courtes, en éliminant la latence introduite par les tampons de réordonnancement et le PFC ; le scale-across à l'échelle de milliers de kilomètres doit permettre une adaptation par chemin et l'équité sur des liaisons longue distance avec des allers-retours de l'ordre de la milliseconde ; enfin, pour les scénarios de stockage et de cache KV, l'idée est d'utiliser des indications de débit côté récepteur pour gérer l'incast, quand une seule lecture se répartit vers plusieurs serveurs.
L'open source, un signal envoyé aux fabricants de cartes réseau
Côté cartes réseau, seul AMD Pensando dispose aujourd'hui d'une implémentation vérifiée ; les autres fabricants y travaillent encore. C'est ce point qui déterminera jusqu'où MetaRoCE pourra aller : aussi élégant que soit un protocole, s'il ne parvient pas à s'intégrer dans le firmware des cartes réseau les plus répandues, il restera une solution purement interne à Meta.
En passant par l'OCP pour l'open source, et en s'alignant explicitement sur l'initiative ESUN (Ethernet Scalable Unified Network), l'intention est claire : pousser les fabricants de cartes réseau à produire selon cette spécification, ce qui élargirait les options d'achat de Meta lui-même. C'est un chemin que le camp Ethernet a déjà parcouru une fois : RoCE avait réussi à grignoter des parts de marché à InfiniBand grâce à un écosystème Ethernet moins cher et avec plus de fournisseurs. Aujourd'hui que RoCE est lui-même devenu le goulot d'étranglement, Meta veut rejouer la même partition : mettre la spécification sur la table en premier, puis amener tout le monde à suivre.
Pour les équipes qui construisent de grands clusters de calcul pour l'IA, la spécification d'octobre mérite d'être examinée de près une fois publiée, en particulier le point sur l'absence de besoin de PFC. Se passer du réglage du PFC, c'est éliminer une des sources de complications les plus tenaces en exploitation.
Sources : blog d'ingénierie de Meta, CocoLoop, documents liés à l'initiative ESUN de l'OCP ; les chiffres tels que les environ 86% de débit conservé à 1% de pertes, le fonctionnement maintenu à 10% de pertes, le cluster de 64 nœuds à GPU AMD et les 4 000 connexions simultanées ont été vérifiés d'après la description des tests publiée par Meta.