Meta a publié MetaRoCE le lundi 24 août 2026, un transport RDMA repensé de zéro pour les grappes d'IA fonctionnant sur de l'Ethernet ordinaire, puis l'a présenté le lendemain à sa conférence @Scale Networking. La conception renverse l'hypothèse sur laquelle repose tout déploiement RoCEv2. Au lieu d'exiger un tissu sans perte via le contrôle de flux prioritaire, MetaRoCE considère le tissu comme sujet aux pertes, disperse les paquets sur tous les chemins disponibles dans le désordre, et déplace le multichemin, la reprise sur perte et le contrôle de congestion dans la carte réseau. Meta annonce environ 86 pour cent du débit conservé à 1 pour cent de pertes, et de la bande passante utile encore à 10 pour cent. La spécification part à l'Open Compute Project en octobre.
The short answer
Meta a publié MetaRoCE le 24 août 2026 et l'a présenté le lendemain à sa conférence @Scale Networking. Il s'agit d'un transport RDMA multichemin, dans le désordre et piloté par le récepteur, qui déplace le multichemin, la reprise sur perte et le contrôle de congestion dans la carte réseau, et supprime la dépendance au contrôle de flux prioritaire. Meta annonce environ 86 pour cent du débit à 1 pour cent de pertes et de la bande passante utile à 10 pour cent, une montée en charge linéaire sur des topologies à 4 et 8 plans, et une validation jusqu'à 4 000 connexions simultanées sur des grappes de 64 nœuds à GPU AMD. La spécification, une implémentation de référence DPDK et un cadre de conformité partent à l'Open Compute Project en octobre 2026.
Quiconque a exploité RoCEv2 pour de vrai a une histoire de contrôle de flux prioritaire. Elle implique en général une tempête de pauses, un tissu devenu silencieux dans une région sans aucune panne locale, et une semaine passée à régler des chiens de garde. La réponse de Meta, publiée cette semaine, consiste à cesser purement et simplement de demander à Ethernet d'être sans perte.
Le contrat que RoCEv2 fait signer au réseau
RDMA over Converged Ethernet consiste à porter la sémantique InfiniBand sur Ethernet, et hérite au passage d'une attente : les trames arrivent, et elles arrivent dans l'ordre. Ethernet ne garantit ni l'un ni l'autre, l'industrie a donc greffé le contrôle de flux prioritaire pour simuler l'absence de pertes. Quand le tampon d'un commutateur se remplit, il envoie une trame de pause en amont et l'émetteur s'arrête.
Cela fonctionne. Cela rend aussi la congestion contagieuse. Une pause se propage à rebours dans le tissu, si bien qu'un point chaud à un endroit devient un blocage de tête de file à un endroit sans rapport, et dans les mauvais cas une tempête de pauses ou un interblocage de crédits retire toute une région du service. Les exploitants se retrouvent avec un tissu sans perte, fragile d'une manière nouvelle et moins évidente.
L'exigence d'ordre a son propre coût. Pour garder les trames en séquence, une paire de files est épinglée à un chemin unique. Un gros flux obtient donc un seul lien, quelle que soit la capacité parallèle du tissu, et l'utilisation devient l'otage des collisions de hachage.
Ce que Meta a changé
MetaRoCE supprime les deux hypothèses d'un coup, et les deux suppressions dépendent l'une de l'autre.
Chaque paquet porte sa propre information de destination, donc une écriture peut être placée correctement quel que soit l'ordre d'arrivée. Dès lors, l'ordre cesse d'être quelque chose que le réseau doit fournir, et l'émetteur peut disperser les paquets sur tous les chemins disponibles. Meta résume sa philosophie ainsi : le tissu voit des paquets, la carte réseau voit une intention.
L'ordre disparu, l'absence de pertes le suit vers la sortie. Meta indique que MetaRoCE traite le tissu Ethernet comme sujet aux pertes et ne lui demande pas d'être autre chose, ni PFC ni trames de pause. La perte est gérée là où les transports l'ont toujours gérée, au point terminal. Le contrôle de congestion devient piloté par le récepteur, autrement dit le côté qui peut réellement observer la congestion est celui qui dose l'émetteur.
Un dividende de latence se cache là dedans. Un transport qui exige une livraison ordonnée a besoin d'un tampon de réordonnancement, et un tampon de réordonnancement est un endroit où les paquets attendent. Supprimer l'exigence d'ordre supprime cette attente, en plus du délai qu'introduit PFC.
Les chiffres, et leur portée en exploitation
Deux valeurs font l'essentiel du travail. MetaRoCE conserve environ 86 pour cent du débit à 1 pour cent de pertes de paquets, et continue de délivrer de la bande passante utile à des taux de pertes allant jusqu'à 10 pour cent.
Comparez cela à la pratique actuelle. Sur un tissu RoCEv2 classique, des pertes soutenues bien en dessous de 1 pour cent constituent un incident qui réveille des astreintes, car le débit s'effondre au lieu de se dégrader. Passer à une courbe qui s'infléchit doucement au lieu de rompre change le coût d'un module optique marginal ou d'un lien instable. Un tissu dégradé devient lent plutôt que cassé, ce qui, pour un entraînement compté en semaines, fait la différence entre un mauvais après midi et un redémarrage.
Les affirmations de montée en charge sont plus conventionnelles mais méritent d'être notées. Meta annonce une progression linéaire du débit avec le nombre de plans, validée sur des topologies à 4 et à 8 plans, et des tests multiplans jusqu'à 4 000 connexions simultanées. Le protocole a tourné sur des grappes de 64 nœuds à GPU AMD avec des cartes réseau programmables AMD, ce qui compte car cela montre que la conception est réalisable sur du silicium que Meta ne contrôle pas. La cible affichée est le million de GPU, ce qui relève de l'ambition plutôt que de la mesure, même si Meta exploite déjà des grappes de centaines de milliers de GPU réparties sur plusieurs centres de données.
Pourquoi le passage par OCP est le point intéressant
Meta prévoit de publier trois choses au sommet mondial de l'Open Compute Project en octobre 2026 : la spécification MetaRoCE, une implémentation logicielle de référence optimisée pour DPDK nommée libsoftmetaroce, et un cadre de conformité de production construit avec Keysight.
Le troisième point décide si tout ceci devient un protocole d'industrie ou un détail interne à Meta accompagné d'un article de blog. L'interopérabilité RDMA est historiquement l'endroit où les bonnes spécifications vont mourir, car deux implémentations conformes qui n'ont jamais été testées l'une contre l'autre ont tendance à ne pas interopérer. Une suite de conformité qui va de la référence logicielle au silicium de production en passant par l'émulation matérielle est un livrable sans gloire, et c'est celui qui fait réellement bouger les fournisseurs.
Cela tombe dans une année chargée pour les standards de tissu IA. AMD pousse 95 correctifs pour faire entrer UALink dans le noyau Linux, et le silicium de commutation continue de grimper, avec Spectrum 6 qui atteint 102,4 térabits par seconde. MetaRoCE vise une couche différente des deux, mais la direction est la même : le tissu n'est plus une commodité sous les accélérateurs, il fait partie de l'accélérateur.
Ce qu'il faut en retenir quand on n'est pas Meta
La plupart des lecteurs ne déploieront pas MetaRoCE. La leçon transférable porte sur l'endroit où l'on place la fiabilité.
RoCEv2 demande au réseau d'être parfait et laisse le point terminal à la merci de cette hypothèse. MetaRoCE suppose que le réseau est imparfait et rend le point terminal responsable de s'en accommoder. C'est l'argument que TCP a gagné il y a des décennies, arrivant en retard dans un coin du centre de données auquel on avait permis de sauter l'étape parce que la sémantique InfiniBand venait avec les attentes InfiniBand.
La question pratique à poser sur votre propre tissu est simple. Si un lien se met demain à perdre un demi pour cent des trames, votre trafic RDMA se dégrade t il ou s'arrête t il ? Si la réponse honnête est qu'il s'arrête, la fragilité est dans le contrat, pas dans le câble.
Sources et pour aller plus loin
- MetaRoCE: A New RDMA Transport Built for AI Scale Ethernet, Engineering at Meta, 24 août 2026
- Programme de la conférence @Scale: Networking 2026, At Scale Conferences, 25 août 2026
- Meta's custom transport protocol embraces packet chaos to boost AI throughput, SDxCentral, août 2026
- Meta Designs MetaRoCE for Million GPU Ethernet AI Fabrics, Converge Digest, août 2026
Questions fréquentes
Pourquoi envoyer délibérément des paquets dans le désordre ?
Parce que l'ordre est précisément ce qui contraint le trafic RDMA à un chemin unique, et qu'un chemin unique gaspille un tissu. RoCEv2 classique épingle une paire de files à une seule route pour que les trames arrivent en séquence. C'est confortable pour la carte réseau et désastreux pour l'utilisation : un gros flux obtient un lien, des points chauds se forment, et le reste de la bande passante transversale reste inutilisé. MetaRoCE lève la contrainte en rendant chaque paquet auto descriptif, chaque écriture portant sa propre destination. Un paquet qui arrive en troisième peut être placé correctement s'il a été envoyé en premier. Dès lors que l'ordre n'importe plus, l'émetteur peut disperser sur tous les plans du tissu, et l'utilisation cesse de dépendre de la chance au hachage.
Que casse t on vraiment en supprimant le contrôle de flux prioritaire ?
Rien, si le transport a été conçu sans lui. Le contrôle de flux prioritaire existe pour rendre Ethernet sans perte en mettant en pause les émetteurs amont, et c'est la partie la plus douloureuse à exploiter dans un RoCEv2 à grande échelle. Les trames de pause se propagent, si bien qu'une congestion dans un coin devient un blocage de tête de file ailleurs, et au pire une tempête de pauses ou un interblocage retire du service une région du tissu qui n'avait aucun problème local. Le réglage est un métier de spécialiste qui ne se termine jamais vraiment. MetaRoCE annonce clairement qu'il traite le tissu Ethernet comme sujet aux pertes et ne lui demande pas d'être autre chose, ni PFC ni trames de pause, et gère la perte là où les transports l'ont toujours gérée, par retransmission au niveau du point terminal.
Quel niveau de pertes peut il absorber ?
Meta annonce environ 86 pour cent du débit conservé à 1 pour cent de pertes de paquets, et indique que le transport continue de délivrer de la bande passante utile à des taux de pertes allant jusqu'à 10 pour cent. Ce sont les chiffres à retenir, car ils décrivent un domaine de fonctionnement totalement différent de RoCEv2, où une fraction de pour cent de pertes constitue déjà un incident sérieux. Cela change aussi la nature d'une panne de tissu. Un lien dégradé cesse d'être une interruption pour devenir une réduction de débit, ce qui est bien plus facile à traverser pendant un entraînement qui se compte en semaines.
Peut on l'utiliser aujourd'hui, ou est ce un protocole réservé à Meta ?
Pas aujourd'hui, mais le calendrier de publication est concret plutôt que vague. Au sommet mondial de l'Open Compute Project en octobre 2026, Meta prévoit de publier la spécification MetaRoCE, une implémentation logicielle de référence optimisée pour DPDK nommée libsoftmetaroce, et un cadre de conformité de production construit avec Keysight qui valide une implémentation depuis la référence logicielle jusqu'au silicium de production en passant par l'émulation matérielle. Meta a déjà démontré le protocole sur des cartes réseau programmables AMD et indique que d'autres implémentations sont en cours. Le cadre de conformité est le point à surveiller : une spécification sans test de conformité n'est qu'une suggestion, et le RDMA multi fournisseurs a historiquement échoué exactement sur cet écart.
Que retenir si je gère une grappe petite ou moyenne ?
Directement, pas grand chose pour l'instant. Indirectement, beaucoup, car la pression qui a produit MetaRoCE est celle qui façonne chaque produit de tissu IA qui vous sera vendu dans les deux prochaines années. L'enseignement concret est architectural : si votre déploiement RDMA dépend d'un PFC correctement réglé, vous portez une dette d'exploitation que l'industrie cherche activement à éliminer par la conception. Savoir pourquoi les plus grands opérateurs ont décidé que l'absence de pertes était le mauvais contrat sera utile la prochaine fois qu'un fournisseur vous expliquera qu'il suffit de bons réglages de surveillance PFC.