OpenAI a publié la spécification de MRC, un nouveau protocole réseau destiné aux superordinateurs d’intelligence artificielle, développé en collaboration avec AMD, Broadcom, Intel, Microsoft et NVIDIA. La société l’a mis à disposition via l’Open Compute Project avec un objectif clair : permettre à l’industrie d’utiliser et d’améliorer une infrastructure déjà en fonctionnement dans ses plus grands clusters d’entraînement.

Cette announcement ne possède peut-être pas la même visibilité commerciale qu’un nouveau modèle, mais son importance peut être tout aussi grande pour comprendre l’orientation de l’intelligence artificielle. Entraîner des modèles de pointe n’est pas seulement une question d’augmenter le nombre de GPU. Cela exige également 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 une GPU en panne dans un cluster d’entraînement n’est pas qu’un problème technique : c’est de l’argent, de l’énergie et du temps perdus.

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. Cela signifie que la performance n’est pas uniquement dictée par la capacité moyenne du réseau, mais aussi par ses pires cas : paquets arrivant en retard, routes congestionnées ou liens défaillants au pire moment. La société décrit ces charges comme une sorte de « amplificateur de défaillances », car plus le système est vaste, plus un petit problème peut perturber l’ensemble.

Le MRC, ou Multipath Reliable Connection, cherche à résoudre ce goulet d’étranglement. C’est une extension de RoCE, la technologie RDMA sur Ethernet convergent utilisée pour que CPU et GPU échangent des données avec accès mémoire direct. La différence réside dans le fait que 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 des modèles de haute performance, y compris dans des systèmes comme Oracle Cloud Infrastructure à Abilene, Texas, et les superordinateurs Fairwater de Microsoft. La société indique également avoir déjà entraîné plusieurs modèles en utilisant MRC avec du matériel NVIDIA et Broadcom.

Le contexte est clé. OpenAI indique que ChatGPT dépasse actuellement 900 millions d’utilisateurs hebdomadaires, ce qui oblige à repenser l’infrastructure au-delà des seuls modèles. La société ne travaille plus uniquement avec des clusters expérimentaux, mais avec des systèmes qui font partie d’une chaîne de production mondiale de modèles, produits et services d’intelligence artificielle.

L’idée principale : diviser, répartir et résister aux défaillances

Une des caractéristiques les plus innovantes de MRC réside dans sa topologie. 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 ainsi huit plans parallèles de 100 Gb/s. Cette approche modifie la structure du cluster : un switch pouvant connecter 64 ports à 800 Gb/s pourrait connecter 512 ports à 100 Gb/s. Selon OpenAI, cela permet de construire un réseau capable de relier environ 131 000 GPU en seulement deux niveaux de switches, contre trois ou quatre niveaux dans une conception conventionnelle.

La réduction du nombre de niveaux n’est pas un détail insignifiant. Moins de switches signifient moins de consommation, moins de composants susceptibles de tomber en panne, et une complexité opérationnelle moindre. Mais diviser le réseau en plusieurs plans n’a d’intérêt que si le trafic en tire parti. C’est ici qu’intervient le « packet spraying » adaptatif : MRC n’envoie pas une transmission par une seule route, mais répartit ses paquets à travers de nombreux chemins simultanément.

Dans un réseau classique, l’envoi de paquets par routes différentes peut provoquer leur arrivée désordonnée. MRC permet cela puisque chaque paquet inclut sa destination finale de mémoire. La machine destinataire peut le placer à sa position dès son arrivée, sans attendre que tous suivent le même chemin. Cette capacité réduit également les points chauds de congestion et évite que certaines transferts deviennent beaucoup plus lents que d’autres.

Le protocole distingue aussi mieux entre pertes dues à des défaillances et pertes dues à la congestion. Si un switch ne peut pas transmettre un paquet, il peut réduire la charge utile et n’envoyer que l’en-tête. Ce « packet trimming » permet de demander une retransmission explicite sans supposer automatique­ment que tout le chemin est défectueux. C’est une façon de limiter les faux positifs et de maintenir des routes opérationnelles même en cas de problème non physique.

SRv6 : le dénouement de certains déboires difficiles à diagnostiquer

MRC introduit une autre décision stratégique : substituer une partie du routage dynamique traditionnel par le source routing avec SRv6. Au lieu que les switches calculent d’eux-mêmes le chemin, l’origine spécifie la route que doit suivre chaque paquet. Les switches se contentent de lire les identifiants et de suivre des tables statiques préconfigurées.

Ce procédé simplifie considérablement la gestion. Si une route échoue, MRC la désactive. Les switches n’ont pas besoin de recalculer ou de renégocier les chemins. Pour un cluster comportant des millions de liens, réduire cette complexité peut être aussi précieux que d’augmenter la bande passante.

OpenAI cite des exemples concrets pour illustrer l’impact. Lors d’entraînements réels, le système a détecté plusieurs défaillances transitoires par minute entre switches de différents niveaux, sans impact mesurable sur les processus d’entraînement en mode préentraînement synchronisé. Dans un autre cas, lors de l’entraînement d’un modèle récent pour ChatGPT et Codex, il a fallu redémarrer quatre switches sans coordination préalable avec les équipes en charge. Avant, une opération de ce genre pouvait nécessiter une planification minutieuse pour éviter d’interrompre le travail.

Ce n’est pas qu’une avancée technique, c’est aussi une amélioration opérationnelle. Si un réseau peut tolérer des défaillances sans interrompre la formation, cela permet aux équipes de faire de la maintenance, de réparer des liens ou d’opérer de gros clusters avec moins de crainte de perdre des investissements de plusieurs millions de dollars. En supercomputing AI, la résilience devient synonyme de productivité.

Une norme ouverte pour faire avancer l’infrastructure

Le fait qu’OpenAI mette MRC à disposition via l’Open Compute Project constitue une décision stratégique. La société ne garde pas le protocole comme un avantage exclusif, mais en publie la spécification pour permettre à d’autres fabricants, opérateurs cloud et laboratoires de l’adopter. C’est un signal que certaines couches de l’infrastructure IA nécessitent des standards communs pour évoluer efficacement.

La compétition en IA ne se limite 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 centres de données moins énergivores, 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 rapidement, plus gros, en gaspillant moins de ressources.

Le groupe de partenaires est également révélateur : AMD, Broadcom, Intel, Microsoft et NVIDIA ont des intérêts concurrents, mais 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. Cela rappelle que l’infrastructure IA devient une plateforme industrielle impliquant de nombreux acteurs, bien au-delà d’un simple logiciel.

Bien que la publication de MRC ne signifie pas une adoption immédiate et universelle, elle pose une direction claire : 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, et non seulement pour fonctionner en conditions idéales.

En pratique, MRC vise à faire en sorte que les GPU continuent à fonctionner malgré congestion, liens instables, maintenances de switches ou routes dégradées. Cette capacité, bien que discrète face aux annonces de nouveaux modèles, explique en partie comment ces modèles peuvent exister. 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 en permanence.

Questions fréquentes

Qu’est-ce que MRC ?
MRC, ou 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 en IA.

Pourquoi est-ce crucial pour entraîner des modèles volumineux ?
Parce que l’entraînement distribué nécessite de transférer des données entre milliers ou centaines de milliers de GPU. Si une transmission est retardée ou échoue, cela peut ralentir ou arrêter l’entraînement.

Que propose-t-il par rapport à un réseau traditionnel ?
MRC répartit les paquets sur des centaines de routes, utilise des réseaux multicouche, évite les défaillances en microsecondes, et simplifie le routage via SRv6 et des routes statiques.

Qui peut adopter MRC ?
OpenAI a publié la spécification via l’Open Compute Project, afin que l’industrie puisse l’étudier, s’en inspirer et la déployer.