Un consortium d'OpenAI, AMD, Broadcom, Intel, Microsoft et NVIDIA a publié MRC — Multipath Reliable Connection — via l'Open Compute Project le 5 mai, avec le papier de recherche associé (Araujo et al., arXiv:2605.04333) détaillant son déploiement sur les plus gros supercalculateurs GB200 d'OpenAI, incluant le site Stargate avec Oracle Cloud Infrastructure à Abilene, Texas, et Fairwater de Microsoft. MRC est la couche réseau derrière les training runs des derniers modèles frontières ChatGPT et Codex, et l'analyse approfondie de Gokul Chandra Purnachandra Reddy dans Towards Data Science fait remonter l'observation porteuse que la couverture de presse a manquée : MRC élimine effectivement toute la couche de contrôle Layer 3 du fabric du data center. Pas d'OSPF, pas de BGP, pas d'IS-IS, pas de FIB ; les switches maintiennent zéro état de forwarding dynamique. À la connaissance de Reddy, c'est l'élimination la plus agressive du routage dynamique dans un fabric d'entraînement IA en production publiquement documenté à ce jour.
Les cinq décisions de design contre-intuitives, chacune individuellement familière mais radicales en combinaison : (1) Diviser le NIC 800 Gb/s en huit liens 100 Gb/s, chacun sur son propre switch — crée huit plans réseau indépendants. La topologie deux tiers supporte 131 072 GPUs à pleine bissection bande passante contre ~64K GPUs à trois tiers conventionnellement. Le pire chemin est 3 hops vs 5-7 hops. Utilise 2/3 des optiques et 3/5 des switches d'un déploiement 3 tiers. (2) Pas de protocoles de routage dynamique — routes statiques seulement, zéro état de forwarding, plan de contrôle assez simple pour qu'une petite équipe gère plusieurs supercalculateurs simultanément. (3) Packet spraying : chaque transfert est sprayé à travers des centaines de chemins aléatoires sur les huit plans ; quand un lien échoue, le NIC retire cette valeur d'entropie et redistribue le trafic aux sept plans restants en microsecondes. (4) Ethernet lossy par design — accepter la perte de paquets intentionnellement plutôt que de bâtir des cascades de backpressure, avec retransmission sélective gérant le petit taux de perte. (5) ECN réorienté comme signal de load-balancing plutôt que comme signal de contrôle de congestion. Les NICs 800 Gb/s expédient depuis trois vendors de silicon différents.
Le cadrage du problème est ce qui rend les compromis d'ingénierie défendables. Le pré-entraînement synchrone à 131 072 GPUs tourne en lock-step — chaque étape d'entraînement dépend du transfert le plus lent. Le cadrage cité du papier : « à mesure que les calculs s'échellent, la communication devient de plus en plus dominée par les outliers. » À ~300 000 $/heure aux tarifs cloud pour 100K GPUs classe H100, un stall de 10ms de tail-latency par étape à travers des milliers d'étapes se compose en argent réel. L'anecdote d'incident de production est la partie à pondérer : un transceiver optique sur un switch T0 a subi un glitch et a flappé ses quatre liens en succession rapide, affectant trois nœuds d'entraînement actifs ; dans un réseau conventionnel ça aurait planté le job d'entraînement, et avec MRC l'entraînement a continué. Les maths de résilience sur les pannes de lien : NIC 800 Gb/s single-plane perd 3 % de capacité sur un lien défaillant ; 100 Gb/s multi-plane perd 0,4 % et continue d'opérer sur les sept plans restants. L'architecture achète une bande passante prévisible au coût de la complexité de monitoring réseau (8× les liens à suivre) et un modèle mental différent pour les équipes ops qui ont grandi sur des fabrics L3 conventionnels.
Pour les builders et équipes infra : c'est le point de donnée le plus concret à ce jour sur ce qu'est devenue l'architecture de fabric d'entraînement de labo frontière, et la publication OCP signifie que tu peux étudier le design du protocole plutôt que de le reverse-engineer à partir d'analyses de mots-clés d'annonces d'emploi. Trois implications concrètes. Premièrement, si tu achètes de la capacité à un cloud adjacent aux labos frontières, attends-toi à ce que les fabrics multi-plan style MRC soient la baseline d'ici Q3 — tes hypothèses de tuning workload sur le RoCE single-path doivent être revisitées. Deuxièmement, chaque vendor de réseau OSS qui a expédié des optimisations OSPF/BGP spécifiquement pour les fabrics IA a maintenant un marché qui rétrécit ; le consortium OpenAI est le plus gros déploiement unique d'élimination de routage dynamique jamais documenté, et là où ils vont, les clients NVIDIA/Microsoft/Oracle suivent. Troisièmement, le papier vaut la peine d'être lu d'un bout à l'autre — l'analyse TDS de Reddy est un guide utile, mais la référence arXiv (2605.04333) est la source canonique. Le cadrage « cinq décisions contre-intuitives » est éditorial ; la vraie surprise est que chacune a passé le test de stress production simultanément dans un déploiement 131K GPU, et que le consortium OpenAI a choisi de publier comment plutôt que de garder l'ingénierie propriétaire.