OpenAI vient de publier la spécification de MRC, un nouveau protocole réseau conçu pour les superordinateurs d’intelligence artificielle, développé avec AMD, Broadcom, Intel, Microsoft et NVIDIA. La société le met à disposition via l’Open Compute Project avec un objectif précis : permettre à l’industrie d’utiliser et d’améliorer une infrastructure déjà en fonctionnement dans ses plus grands clusters d’entraînement.
Cette annonce n’a pas la visibilité commerciale d’un nouveau modèle, mais son importance pour comprendre l’orientation de l’IA est réelle. Entraîner des modèles de pointe n’est pas seulement une question de GPU supplémentaires. Cela exige une communication extrêmement précise entre ces GPU. Si une transmission arrive en retard, si un lien échoue ou si un switch introduit de la latence, des milliers d’accélérateurs peuvent se retrouver à attendre. Et dans un cluster d’entraînement, une GPU en pause n’est pas qu’un problème technique : c’est de l’argent, de l’énergie et du temps perdus — la même logique économique que celle qui fait exploser les coûts de production de tokens IA quand les infras sous-performent.
Pourquoi OpenAI avait besoin d’un réseau différent
OpenAI explique que l’entraînement de grands modèles peut impliquer des millions de transferts de données en un seul passage. Lors d’un entraînement synchronisé, de nombreuses GPU travaillent en coordination sur le même modèle. La performance n’est pas dictée par la capacité moyenne du réseau, mais par ses pires cas : paquets arrivant en retard, routes congestionnees ou liens défaillants au mauvais moment. La société décrit ces charges comme un « amplificateur de défaillances » : plus le système est vaste, plus un petit problème peut perturber l’ensemble.
MRC, Multipath Reliable Connection, cherche à résoudre ce goulot. C’est une extension de RoCE — RDMA over Converged Ethernet, la technologie qui permet à CPU et GPU d’échanger des données avec accès mémoire direct. La différence : MRC répartit une même transmission sur des centaines de routes, peut contourner des défaillances en microsecondes, et simplifie le plan de contrôle du réseau grâce à un routage statique basé sur SRv6.
OpenAI affirme que MRC est déjà déployé sur tous ses plus grands superordinateurs avec NVIDIA GB200, utilisés pour entraîner ses modèles haute performance — notamment sur Oracle Cloud Infrastructure à Abilene (Texas) et les superordinateurs Fairwater de Microsoft. La société mentionne également ChatGPT, qui dépasse 900 millions d’utilisateurs hebdomadaires, comme signal de la pression opérationnelle qui rend ces choix d’infrastructure indispensables.
Diviser, répartir, résister : la mécanique de MRC
L’innovation la plus concrète de MRC est topologique. Plutôt que de traiter une interface réseau de 800 Gb/s comme une seule connexion, OpenAI propose de la diviser en plusieurs liens plus petits. Par exemple, une interface peut se connecter à huit switches différents, créant huit plans parallèles de 100 Gb/s. Cela modifie la structure du cluster : un switch pouvant connecter 64 ports à 800 Gb/s peut connecter 512 ports à 100 Gb/s. Résultat : un réseau capable de relier environ 131 000 GPU en seulement deux niveaux de switches, contre trois ou quatre dans une conception conventionnelle.
Moins de switches, c’est moins de consommation, moins de composants susceptibles de tomber en panne, et moins de complexité opérationnelle. Mais diviser le réseau en plusieurs plans n’a d’intérêt que si le trafic en tire parti. C’est là qu’intervient le « packet spraying » adaptatif : MRC ne concentre pas une transmission sur une seule route, il répartit ses paquets sur de nombreux chemins simultanément.
| Problème dans les grands clusters IA | Approche traditionnelle | Ce que propose MRC |
|---|---|---|
| Congestion de liens spécifiques | Chaque flux suit généralement un seul chemin | Répartit les paquets sur plusieurs chemins |
| Défaillances de liens ou switches | Recalcul des routes, peut prendre des secondes | Contourne les routes défaillantes en microsecondes |
| Plus de 100 000 GPU | Nécessite 3–4 niveaux de switches | Réseau multiplan en seulement deux niveaux |
| Paquets désordonnés | Pénalisent la performance | Chaque paquet porte son adressage mémoire final |
| Complexité du plan de contrôle | Protocoles dynamiques comme BGP | Routage statique SRv6, contrôlé depuis l’origine |
| Maintenance réseau | Nécessite coordination avec l’entraînement | Réparations sans interrompre l’entraînement |
Dans un réseau classique, envoyer des paquets par routes différentes risque de provoquer des arrivées désordonnées. MRC contourne ce problème car chaque paquet inclut sa destination finale en mémoire. La machine destinataire peut le placer à sa position dès son arrivée, sans attendre que tous suivent le même chemin. Cela réduit également les points chauds de congestion et évite que certains transferts deviennent beaucoup plus lents que d’autres.
MRC distingue aussi mieux entre pertes dues à des défaillances et pertes dues à la congestion. Si un switch ne peut pas transmettre un paquet, il envoie uniquement l’en-tête (« packet trimming »). Cela permet une retransmission explicite sans supposer que tout le chemin est défectueux — une façon de limiter les faux positifs et de maintenir des routes opérationnelles même en cas de problème transitoire.
SRv6 : du routage statique pour simplifier ce qu’on ne voit pas
MRC remplace une partie du routage dynamique traditionnel par du source routing avec SRv6. Au lieu que les switches calculent eux-mêmes le chemin, l’origine spécifie la route que chaque paquet doit suivre. Les switches lisent les identifiants et suivent des tables statiques préconfigurées.
Si une route échoue, MRC la désactive. Les switches n’ont pas besoin de recalculer ou de renégocier. Pour un cluster avec des millions de liens, réduire cette complexité peut être aussi précieux qu’augmenter la bande passante.
OpenAI cite des exemples concrets : lors d’entraînements réels, le système a détecté plusieurs défaillances transitoires par minute entre switches, sans impact mesurable sur les processus d’entraînement. Dans un autre cas, il a fallu redémarrer quatre switches pendant l’entraînement d’un modèle pour ChatGPT et Codex, sans coordination préalable avec les équipes. Avant MRC, une opération de ce type demandait une planification minutieuse pour éviter d’interrompre le travail et de perdre des heures de calcul à très haut coût.
Standard ouvert : pourquoi OpenAI ne garde pas MRC pour lui seul
Publier MRC via l’Open Compute Project est une décision stratégique. OpenAI ne conserve pas le protocole comme avantage exclusif, mais publie la spécification pour que d’autres fabricants, opérateurs cloud et laboratoires puissent l’adopter. C’est un signal clair que certaines couches de l’infrastructure IA ont besoin de standards communs pour évoluer efficacement.
Le groupe de partenaires est éloquent : AMD — dont les GPU Instinct ont été utilisés pour repousser les limites de la simulation quantique —, Broadcom, Intel, Microsoft et NVIDIA partagent une problématique commune : si de grands clusters ne communiquent pas efficacement, le matériel ne donne pas tout son potentiel. OpenAI mentionne aussi Microsoft Azure, OCI, NVIDIA et Arista dans ses déploiements à grande échelle, ce qui confirme que l’infrastructure IA est devenue une plateforme industrielle impliquant de nombreux acteurs.
La compétition en IA ne se réduit pas à améliorer les modèles ou disposer de plus d’accélérateurs. Elle passe aussi par des réseaux optimisés pour exploiter ces GPU, des systèmes résilients aux défaillances et des architectures extensibles sans complexifier la gestion. MRC s’insère dans cette couche invisible mais déterminante, celle qui conditionne si un laboratoire peut entraîner plus vite, plus gros, en gaspillant moins de ressources.
La publication de MRC ne garantit pas une adoption immédiate et universelle. Mais elle pose une direction nette : pour gérer des clusters de plus de 100 000 GPU, il faut des réseaux conçus pour supporter des défaillances fréquentes, pas seulement pour fonctionner en conditions idéales. La frontière de l’IA commence dans les algorithmes, mais elle repose aussi sur des câbles, switches, protocoles et choix d’architecture qui doivent être fiables à toute heure.
Questions fréquentes
Qu’est-ce que MRC ?
MRC, Multipath Reliable Connection, est un protocole réseau développé par OpenAI avec AMD, Broadcom, Intel, Microsoft et NVIDIA pour améliorer la performance et la résilience des grands clusters d’entraînement IA. Il est publié via l’Open Compute Project.
Pourquoi MRC est-il crucial pour entraîner des grands modèles ?
L’entraînement distribué nécessite de transférer des données entre des milliers ou des centaines de milliers de GPU simultanément. Si un transfert est retardé ou échoue, cela peut ralentir ou bloquer l’entraînement entier, avec des pertes financières directes.
En quoi MRC diffère-t-il d’un réseau traditionnel ?
MRC répartit les paquets sur des centaines de routes simultanément, utilise un réseau multiplan en deux niveaux seulement pour 131 000 GPU, évite les défaillances en microsecondes, et simplifie le routage via SRv6 avec des tables statiques.
Qui peut adopter MRC ?
OpenAI a publié la spécification via l’Open Compute Project. N’importe quel fabricant, opérateur cloud ou laboratoire peut l’étudier, l’implanter ou contribuer à son évolution.
Sur quels systèmes MRC est-il déjà déployé ?
OpenAI l’a déployé sur ses plus grands superordinateurs NVIDIA GB200, notamment sur Oracle Cloud Infrastructure à Abilene (Texas) et les superordinateurs Fairwater de Microsoft. Plusieurs modèles ont déjà été entraînés avec MRC sur matériel NVIDIA et Broadcom.
