MetaRoCE veut réécrire le transport réseau des modèles IA

Meta publie MetaRoCE, un protocole RDMA pensé pour l’IA sur Ethernet commodity. La version spec, le code de référence et les tests de conformité doivent passer par l’OCP, avec une arrivée annoncée en octobre 2026.

Meta a présenté MetaRoCE, un protocole de transport RDMA conçu pour les charges d’IA sur Ethernet classique, afin de mieux faire circuler les données entre GPU sans gaspiller de calcul. L’enjeu est concret : dans les grands entraînements et l’inférence distribuée, le réseau devient souvent le goulot d’étranglement qui ralentit tout le reste. La société prévoit de publier la spécification, une implémentation logicielle de référence et une suite de conformité via l’Open Compute Project, avec une sortie annoncée pour octobre 2026. C’est un signal fort pour un marché où l’on discute désormais réseau presque autant que GPU.

Quand le réseau décide du rythme des modèles

Les modèles de pointe ne se contentent plus d’avaler des GPU. Ils dépendent aussi d’un trafic réseau rapide et stable entre accélérateurs, car des opérations collectives comme all-reduce et all-to-all synchronisent des milliers de puces à chaque étape d’entraînement. Si une seule liaison ralentit, c’est toute la chaîne qui prend du retard.

Meta dit avoir fait monter des grappes à plusieurs centaines de milliers de GPU, réparties sur plusieurs data centers et régions. Dans ce contexte, la moindre friction réseau immobilise de la capacité de calcul. Pas très élégant, ni très rentable.

Ce que MetaRoCE change dans l’architecture

Le principe est simple à formuler, même si l’exécution reste sportive : le réseau transporte des paquets, mais la NIC, la carte réseau, comprend l’intention de bout en bout. MetaRoCE déplace donc davantage d’intelligence vers l’équipement au bord du réseau, plutôt que de compter sur une fabric qui impose l’ordre et la perte nulle.

Le protocole repose sur plusieurs choix de conception. D’abord, l’arrivée hors ordre devient normale : les paquets peuvent emprunter de multiples chemins et être réassemblés sans tampon de réordonnancement ni blocage en tête de file. Ensuite, le multipathing est natif, avec des chemins gérés par la NIC et ajustés selon l’état observé en temps réel. Enfin, MetaRoCE considère l’Ethernet comme un réseau potentiellement perdant, sans PFC ni pause frames, et déclenche des retransmissions ciblées quand un trou est détecté dans son vecteur d’acquittement sélectif.

La logique vise aussi la simplicité opérationnelle. Le protocole demande surtout ce que les commutateurs savent déjà faire, à savoir l’ECN et l’ECMP, sans dépendre de fonctions plus intrusives comme le packet trimming ou la télémétrie dans le réseau.

Pourquoi l’absence de PFC compte autant

Le PFC, pour pause frame priority, sert à éviter les pertes en mettant le trafic en attente. En pratique, il complique les grands réseaux et peut favoriser des blocages en cascade. MetaRoCE prend l’option inverse : accepter la perte, la mesurer, puis corriger précisément là où elle apparaît. Le réseau reste donc plus souple, et la panne d’un chemin ne paralyse pas la connexion entière.

Cette approche s’applique aussi au contrôle de congestion. Meta combine un mécanisme classique côté émetteur, fondé sur ECN et AIMD, avec des indications de débit côté récepteur. Résultat annoncé : les goulets d’étranglement d’incast, quand plusieurs serveurs répondent en même temps, seraient résolus en une ou deux allers-retours réseau.

Des résultats mesurés sur un cluster AMD

Pour valider le protocole, Meta a travaillé avec AMD sur des NIC Pensando programmables. Les tests ont été menés sur un cluster de 64 nœuds GPU, avec la bibliothèque RCCL, sur des collectifs all-reduce et all-to-all. Dans ces essais, MetaRoCE affiche un débit supérieur à RoCEv2 et des temps de fin de flux plus faibles.

Les chiffres mis en avant racontent surtout la tenue en conditions dégradées. À 1 % de perte de paquets, Meta indique conserver environ 86 % du débit. Même à 10 % de perte, le protocole continue à fournir de la bande passante utile, là où un transport plus classique s’effondrerait plus vite. En topologies multiplane, avec 4 ou 8 plans et jusqu’à 4 000 connexions simultanées, le débit grimpe de façon linéaire avec le nombre de plans.

Ouverture, conformité et angle marché

Meta ne garde pas ce travail sous clé. La spécification doit être versée à l’Open Compute Project, avec une implémentation logicielle de référence, libsoftmetaroce, et une suite de conformité destinée aux fabricants de matériel. L’objectif est clair : permettre à plusieurs acteurs de bâtir des NIC compatibles, qu’elles soient programmables ou plus fixes dans leur architecture.

Cette ouverture s’inscrit dans une tendance de fond chez les opérateurs de très grande échelle : l’infrastructure IA se standardise par morceaux, du réseau au calcul. MetaRoCE ne règle pas tout, notamment pas les contraintes de très courte distance à l’intérieur d’un rack ni les échanges sur de longues distances, mais il trace une voie pour les transports RDMA sur Ethernet. Et pour une fois, le réseau n’a pas seulement le dernier mot ; il commence à prendre des notes.

Reste la question de l’adoption réelle. À ce stade, Meta parle d’un déploiement encore à venir, avec des travaux en cours chez d’autres fournisseurs de NIC [à vérifier]. Pour les exploitants de grands clusters, l’intérêt est évident : moins de dépendance à des fabric complexes, plus de tolérance aux pertes, et un modèle pensé pour l’IA plutôt que recyclé à partir d’un usage généraliste.

Points clés

  • MetaRoCE vise l’IA sur Ethernet commodity.
  • Sortie annoncée : octobre 2026, via l’OCP.
  • Tests sur 64 nœuds AMD avec RCCL.
  • Le protocole tolère les pertes sans PFC.
  • Jusqu’à 4 000 connexions en validation multiplane.
  • AMD Pensando sert de première implémentation.

À lire