Le réseau Meta OCP 2026 met les conceptions ouvertes au service des clusters d’IA

Meta a publié ses présentations consacrées au réseau à l’OCP, détaillant son premier rack réseau à refroidissement liquide et une initiative plus large visant à relier une infrastructure d’IA de plus en plus distribuée. Le réseau Meta OCP 2026 associe de nouveaux équipements de commutation, des logiciels de transport et des spécifications partagées. Le défi central consiste à faire fonctionner ces composants ensemble entre différents fournisseurs et environnements d’exploitation.

Le récapitulatif publié par l’entreprise le 26 octobre fait suite à l’Open Compute Project Global Summit, organisé du 12 au 15 octobre à San Jose, en Californie. Ses présentations sur les réseaux d’IA décrivent l’infrastructure qui prend en charge Muse Wonder, Muse Spark et le supercluster Prometheus. Il s’agit des propres explications de l’entreprise sur son architecture, et non d’évaluations indépendantes de chacune de ses affirmations en matière de performances.

La tension principale oppose une infrastructure réutilisable au travail d’intégration qui reste propre à chaque déploiement. NVIDIA illustre l’importance de cette distinction. L’entreprise fournit des technologies et collabore avec Meta, tout en participant à un marché où les fournisseurs se disputent les systèmes d’IA complets. Les interfaces ouvertes n’éliminent pas cette concurrence. Elles modifient l’endroit où les fournisseurs doivent démontrer leur valeur.

Le réseau Meta OCP 2026 s’étend au-delà du commutateur

L’annonce de Meta est importante car elle traite conjointement plusieurs frontières de l’infrastructure d’IA, plutôt que de présenter un commutateur plus rapide de manière isolée.

Les réseaux scale-up relient les accélérateurs au sein d’un système étroitement coordonné. Les réseaux scale-out relient ces systèmes dans des clusters plus vastes. Les réseaux scale-across étendent les connexions entre des infrastructures réparties sur plusieurs sites. Le portefeuille de Meta couvre ces trois domaines, même si ses composants présentent des niveaux de déploiement et de développement différents.

IcePack est le premier rack réseau à refroidissement liquide de Meta. Ses lames de commutation IceCube offrent une capacité de commutation de 102,4 térabits par seconde, avec 128 connexions fonctionnant chacune à 800 gigabits par seconde. Meta identifie des variantes utilisant les puces de commutation Broadcom Tomahawk 6C et NVIDIA Spectrum-6.

Les deux variantes exécutent FBOSS, le système d’exploitation réseau open source de Meta. Un système d’exploitation réseau gère la manière dont un commutateur achemine le trafic et expose les contrôles opérationnels. L’utilisation d’un logiciel partagé entre différentes variantes matérielles donne à Meta un point de départ commun pour exploiter des équipements provenant de différents fournisseurs.

Le portefeuille de réseaux ouverts comprend également une architecture de cluster actualisée et des connexions basées sur Ethernet pour les propres accélérateurs de Meta. Ces annonces élargissent la discussion, des spécifications des équipements à la conception du système.

Cette distinction modifie la façon dont les acheteurs doivent interpréter l’actualité. La capacité annoncée d’un commutateur décrit une aptitude de l’équipement. Elle n’établit pas la vitesse à laquelle se termine une tâche d’entraînement, la fréquence des défaillances de l’infrastructure ou la part de la maintenance qui exige une intervention humaine.

Une évaluation utile sépare donc le composant de son contexte opérationnel. Les questions pertinentes incluent la manière dont le trafic atteint le commutateur, le développement de la congestion et la réaction des applications lorsque de la capacité disparaît. Le refroidissement et la maintenance doivent également faire partie de cette évaluation.

Prenons le cas d’un opérateur qui choisit entre plusieurs variantes de commutateurs. Un système d’exploitation commun constitue une raison d’examiner les deux options. Il ne garantit pas un comportement interchangeable sous chaque charge de travail, version de firmware ou condition de défaillance. La qualification détermine toujours si une option peut être utilisée en production.

Le même raisonnement s’applique au refroidissement liquide. La prise en charge d’équipements plus denses entraîne des dépendances en matière de préparation des installations, de surveillance et de procédures de réparation. Une équipe réseau ne peut pas évaluer le rack entièrement séparément des personnes responsables du bâtiment.

Le réseau Meta OCP 2026 doit donc être compris comme une orientation d’ingénierie coordonnée. L’entreprise cherche à faire évoluer de concert le matériel réseau, les logiciels et l’infrastructure physique. Les documents publics fournissent un point de départ technique pour évaluer cette orientation.

Ils n’établissent pas que chaque organisation devrait reproduire l’architecture de Meta. La question plus utile est de savoir quelles interfaces et pratiques opérationnelles restent pertinentes lorsque l’infrastructure environnante change.

La capacité d’IA distribuée met les opérateurs et les partenaires cloud sous pression

Les organisations soumises à la pression la plus immédiate sont celles chargées de transformer les accélérateurs disponibles en capacité d’entraînement fiable.

Meta décrit Prometheus comme un supercluster réparti dans des bâtiments interconnectés à New Albany, dans l’Ohio. Son compte rendu du 19 octobre indique que la phase initiale est achevée. L’entreprise distingue cette infrastructure déployée de son ambition d’étendre l’ensemble vers environ un million de GPU, des processeurs utilisés pour le calcul parallèle.

Cette distinction évite une interprétation fréquente mais erronée. L’objectif final de conception d’un cluster n’est pas son nombre actuel d’équipements. De même, l’annonce d’une extension d’infrastructure n’établit pas la date à laquelle toutes les ressources planifiées deviendront disponibles pour les équipes d’entraînement.

Le compte rendu de Meta sur l’infrastructure Prometheus indique que sa première phase a entraîné les modèles fondamentaux Muse. L’entreprise fait état d’un goodput supérieur à 85 % pour le préentraînement de Muse Wonder. Le goodput mesure les progrès utiles de l’entraînement plutôt que le simple fonctionnement des équipements.

Ces chiffres correspondent aux résultats opérationnels rapportés par Meta. Ils ne doivent pas devenir des promesses de performance pour des clusters sans lien avec celui-ci. Leur pertinence plus large tient au choix de la mesure : le travail utile compte davantage que le seul matériel installé.

Pour les opérateurs d’infrastructure, ce cadre modifie les critères d’acceptation. La disponibilité des équipements est nécessaire, mais elle ne permet pas de déterminer si une charge de travail distribuée progresse de manière cohérente. Les équipes doivent comprendre les interruptions, les comportements de reprise et les délais de communication qui laissent les ressources de calcul en attente.

Les fournisseurs de cloud font face à un défi comparable. Un client qui apporte une grande charge de travail distribuée a besoin de plus qu’un ensemble de machines disponibles à la location. Il lui faut un comportement prévisible sur les connexions qui relient ces machines.

Cela crée une pression sur les deux parties. Les fournisseurs doivent expliquer les limites de leurs environnements. Les clients doivent préciser les schémas de communication nécessaires à leurs charges de travail. Aucune des deux parties ne gagne à considérer une petite démonstration comme une preuve suffisante pour un déploiement plus important.

Une décision d’achat illustrative rend le sujet concret. Une équipe d’entraînement peut constater que de la capacité est disponible dans plusieurs sites. Avant d’y répartir une tâche coordonnée, elle doit évaluer si la surcharge de communication l’emporte sur le bénéfice procuré par des accélérateurs supplémentaires.

La réponse dépend de la conception de la charge de travail. Certaines tâches peuvent être divisées en éléments relativement indépendants. D’autres échangent à répétition des résultats intermédiaires et attendent les participants les plus lents. Davantage de matériel disponible ne résout pas à lui seul cette dépendance.

Cela explique également pourquoi les annonces d’infrastructure importent aux équipes produit d’IA. La feuille de route d’un modèle dépend en fin de compte d’une capacité de calcul utilisable, même lorsque les développeurs d’applications ne configurent jamais un commutateur réseau. Des retards de qualification peuvent influencer les expériences que les équipes sont en mesure d’exécuter.

Les acheteurs d’entreprise devraient éviter de transformer cette relation en prévisions produit non étayées. Les informations publiées par Meta sur ses réseaux n’établissent ni les futurs temps de réponse des applications, ni les dates de sortie des modèles, ni leur disponibilité pour les clients. Elles montrent l’effort d’ingénierie nécessaire pour fournir de la capacité d’IA.

La pression pratique est claire : les opérateurs et les fournisseurs doivent valider le système qu’ils entendent livrer. Le nombre de composants et la bande passante nominale ne peuvent pas remplacer des preuves relatives à la charge de travail que ce système doit soutenir.

Déplacer les décisions de trafic vers les terminaux modifie la charge d’ingénierie

L’orientation architecturale de Meta confie davantage de responsabilités aux appareils qui envoient le trafic, plaçant le comportement du transport au cœur de la conception réseau.

MetaRoCE est le protocole de transport de Meta pour l’accès direct à la mémoire à distance, qui permet aux machines d’échanger des données avec une intervention limitée du processeur. L’entreprise l’a conçu pour les charges de travail d’IA sur Ethernet, une famille de technologies réseau largement utilisée.

Selon la conception du transport IA de Meta, MetaRoCE répartit les paquets sur plusieurs chemins et accepte leur arrivée dans des ordres différents. Ses terminaux suivent les chemins individuels et réagissent à la congestion ou aux défaillances.

Cette conception est importante car la répartition des paquets crée un problème de réception autant qu’une opportunité de routage. Si le trafic emprunte des chemins présentant des délais différents, son ordre initial de transmission ne correspond pas nécessairement à son ordre d’arrivée. Le transport doit gérer ce comportement délibérément.

L’approche déclarée par Meta fournit davantage d’informations aux appareils émetteurs et récepteurs sur l’avancement des communications. L’entreprise indique que son protocole est conçu pour tolérer la perte de paquets sans imposer au réseau de suspendre le trafic afin de préserver l’absence de perte.

Il s’agit d’affirmations architecturales, et non d’un verdict universel contre les transports existants. La valeur d’une approche dépend de son implémentation, de la charge de travail et des conditions opérationnelles. Une description de protocole établit le comportement visé ; les tests établissent le comportement d’une implémentation particulière.

Le mécanisme plus général est une redistribution des responsabilités. Au lieu d’attendre du réseau seul qu’il préserve toutes les conditions requises par les applications, les terminaux participent plus activement à la gestion des communications. Cela peut donner au système des moyens supplémentaires de réagir lorsque les chemins présentent des comportements différents.

Cela crée aussi de nouvelles obligations. Les logiciels et matériels des terminaux doivent interpréter correctement les signaux. Les opérateurs ont besoin d’une visibilité sur les décisions prises par ces terminaux. Le dépannage doit relier ce que le réseau a observé à ce que le transport a décidé.

Une connexion hypothétique dégradée montre pourquoi cette visibilité importe. Une application ralentit, mais aucun lien n’est complètement indisponible. L’enquête doit distinguer la congestion des problèmes d’équipement et déterminer si le trafic s’est écarté du chemin affecté.

Une architecture peut exposer davantage de choix sans rendre ces choix faciles à diagnostiquer. Les équipes qui évaluent un réseau multipath de type Meta devraient se demander comment elles reconstitueraient une défaillance après son apparition. Un schéma d’architecture ne répond pas à cette question opérationnelle.

Il existe également une séquence d’adoption à prendre en compte. Une spécification publiée, une implémentation logicielle et une implémentation matérielle prise en charge constituent des étapes distinctes. Les organisations doivent identifier de quelle étape dépend réellement un déploiement proposé.

C’est là que les comparaisons entre fournisseurs devraient rester neutres. NVIDIA, Broadcom, AMD et d’autres participants apportent différentes combinaisons de silicium, de logiciels réseau et de capacités d’intégration système. Une interface ouverte crée un espace pour comparer les implémentations ; elle ne désigne pas le gagnant à l’avance.

Pour les acheteurs, la conséquence utile est un processus d’évaluation plus précis. Ils peuvent demander quels comportements sont standardisés, lesquels nécessitent des extensions fournies par un fournisseur et lesquels dépendent de l’ingénierie du client. Cette démarche est plus informative que de choisir entre de vastes étiquettes telles qu’ouvert et propriétaire.

La direction centrée sur les points de terminaison est importante, car elle modifie la responsabilité de l’exactitude et de la reprise. Son succès doit être évalué à travers le comportement observable des applications, les implémentations prises en charge et des procédures de diagnostic claires.

Les interfaces ouvertes laissent toujours un problème d’intégration de plateforme

Une interface de transfert commune ne standardise pas automatiquement les équipements qui entourent la puce de commutation.

L’initiative Open Switch Platform Architecture, ou OSPA, traite cette couche restante. Meta, Microsoft et Alibaba ont lancé l’effort. OCP décrit sa spécification comme une contribution en cours d’examen, une précision importante lorsqu’il est question de son statut.

L’architecture de plateforme de commutateur couvre notamment la gestion de l’alimentation, l’inventaire des équipements, la surveillance environnementale, la maintenance des micrologiciels et les diagnostics. Les protocoles de routage et la gestion du transfert ne relèvent pas de son périmètre déclaré.

Cette frontière est au cœur du sujet. Un commutateur doit faire plus que déplacer correctement les paquets. Son logiciel doit identifier les composants connectés, surveiller les températures, gérer les mises à jour et fournir des informations utiles en cas de défaillance.

Lorsque ces interfaces diffèrent selon les produits, l’adoption d’équipements d’un autre fournisseur peut exiger un travail d’ingénierie supplémentaire. La proposition d’OSPA consiste à rendre une plus grande part de ce travail réutilisable grâce à une architecture de référence commune.

L’avantage potentiel est simple. Si les opérateurs peuvent réutiliser les logiciels et procédures de gestion, l’évaluation d’équipements alternatifs dépend moins de la reconstruction de l’intégration de base. Les fournisseurs peuvent se distinguer par la qualité de leur implémentation tout en exposant des interfaces opérationnelles plus prévisibles.

Il s’agit encore d’un avantage proposé, et non d’un résultat démontré à l’échelle du marché. Une spécification n’établit ni le nombre de produits qui l’implémentent, ni leur niveau de fidélité à celle-ci, ni le temps d’ingénierie économisé par les clients.

L’angle sceptique le plus pertinent concerne donc les preuves d’implémentation. Un équipement peut revendiquer une compatibilité tout en laissant des comportements importants non documentés. Une évaluation sérieuse doit examiner les parcours de reprise, les changements de micrologiciel et les conditions anormales en plus du fonctionnement courant.

Prenons une mise à jour de micrologiciel qui échoue en cours de route. Les questions pertinentes sont notamment de savoir si la reprise fonctionne, quels composants restent accessibles et quelles informations reçoit l’opérateur. Une spécification d’interface aide à cadrer ces questions, mais le matériel doit toujours y apporter des réponses.

Cela compte particulièrement pour les déploiements mixtes. Un modèle de gestion commun a une valeur limitée si chaque plateforme exige un guide opérationnel distinct pour les défaillances courantes. La réutilisation doit s’étendre au-delà du démarrage initial, jusqu’à la maintenance pendant toute la durée de vie de l’équipement.

OSPA confère également une dimension plus pratique à la stratégie plus large de Meta. L’entreprise s’attaque à un travail qui reçoit souvent moins d’attention que les annonces de bande passante. L’intégration de plateforme détermine si des choix matériels supplémentaires deviennent des choix opérationnels réellement utilisables.

Pour les équipes d’ingénierie qui suivent ces évolutions, la documentation doit préserver la distinction entre le comportement attendu et les résultats observés. Conserver les conclusions de qualification dans une base de connaissances consultable peut faciliter les comparaisons ultérieures.

C’est particulièrement utile lorsque les équipements, les micrologiciels et les spécifications évoluent selon des calendriers différents. Un résultat issu d’une configuration antérieure doit rester traçable jusqu’à cette configuration. Sinon, les équipes risquent de transposer des hypothèses dans des déploiements où elles ne s’appliquent plus.

L’implication commerciale est conditionnelle, mais concrète. Les fournisseurs qui réduisent le travail d’intégration et de maintenance donnent aux acheteurs une raison de les envisager. Les acheteurs ont toujours besoin de preuves que cette réduction résiste aux conditions d’exploitation réelles.

L’Ethernet scale-up remet en question la frontière autour des systèmes intégrés

Le travail de Meta sur l’Ethernet scale-up remet en question une frontière de conception, mais il ne démontre pas que chaque système d’accélérateurs peut utiliser la même interconnexion.

Ethernet for Scale-Up Networking, ou ESUN, est un axe de travail d’OCP consacré à la commutation et au formatage Ethernet pour des systèmes d’accélérateurs étroitement connectés. Son périmètre couvre le comportement réseau, et non l’ensemble de la pile logicielle et matérielle qui entoure un accélérateur.

Le périmètre Ethernet scale-up d’OCP sépare explicitement les fonctions réseau des fonctions de point de terminaison. Ces dernières comprennent des considérations étroitement liées à l’architecture des accélérateurs, telles que le partitionnement des charges de travail et l’ordonnancement de la mémoire.

Cette séparation limite les conclusions que les lecteurs devraient tirer d’une participation à l’initiative. Un fournisseur prenant en charge ESUN ne promet pas nécessairement que chaque accélérateur, bibliothèque de communication et conception de rack deviendra interchangeable.

Meta présente Tahan, un commutateur basé sur Ethernet pour son système d’entraînement MTIA 300, comme faisant partie de sa direction scale-up. MTIA est la famille d’accélérateurs développés en interne par Meta. L’entreprise évoque également de futures conceptions et la poursuite du développement des normes.

La distinction entre un système en exploitation et une architecture future compte ici aussi. L’équipement actuel fournit des preuves concernant une implémentation donnée. Un aperçu décrit un développement envisagé. Aucun ne doit être silencieusement substitué à l’autre.

NVIDIA fournit un repère concurrentiel utile sans réduire le sujet à une simple rivalité. L’infrastructure de Meta utilise la technologie NVIDIA, tandis que Meta développe également ses propres accélérateurs et participe à des travaux de réseau partagés. Ces relations peuvent coexister.

Pour les acheteurs, la comparaison importante porte sur différents modèles d’intégration. Un système étroitement coordonné offre un ensemble établi de combinaisons prises en charge. Une conception plus modulaire offre des choix de composants supplémentaires, avec la responsabilité de valider ces combinaisons.

Aucun de ces modèles ne supprime les contraintes d’ingénierie. Un système intégré doit toujours être qualifié pour la charge de travail du client. Un système modulaire doit toujours disposer d’un dispositif de support cohérent lorsque les défaillances franchissent les frontières entre fournisseurs.

La question financière doit donc inclure l’effort d’ingénierie, et pas seulement le choix des équipements. Un éventail plus large de fournisseurs a une valeur pratique limitée si une organisation ne peut pas prendre en charge les combinaisons qui en résultent. À l’inverse, une interface standardisée peut être précieuse même sans remplacement immédiat de fournisseur.

Elle peut offrir à un acheteur un chemin de migration plus clair, un test d’acceptation plus précis ou un moyen de comparer des propositions concurrentes. Ces avantages dépendent de la manière dont l’interface capture complètement le comportement dont le client a besoin.

Pour les développeurs, les conséquences apparaissent plus haut dans la pile. Les bibliothèques de communication et le placement des charges de travail déterminent dans quelle mesure les applications utilisent efficacement les connexions disponibles. Une norme réseau ne peut pas, à elle seule, choisir le meilleur partitionnement pour chaque modèle.

C’est pourquoi l’Ethernet scale-up mérite l’attention comme voie d’ingénierie plutôt que comme résultat de marché proclamé. Ses progrès doivent être mesurés à travers les systèmes pris en charge, les résultats d’interopérabilité et les preuves liées aux charges de travail. Les annonces de participation seules ne peuvent trancher ces questions.

Les réseaux Meta OCP 2026 renforcent l’argument en faveur de l’évaluation de cette voie. Ils ne justifient pas de supposer que toutes les frontières existantes entre systèmes ont disparu.

Les prochains signaux seront les spécifications, les implémentations et les preuves opérationnelles

Les éléments de suivi les plus utiles relieront les conceptions publiques à des équipements et logiciels que les organisations peuvent évaluer elles-mêmes.

Le premier signal est l’avancement des spécifications. Au cours des prochains mois, observez comment l’examen d’OSPA et le développement d’ESUN se traduisent par des exigences d’implémentation plus claires. L’évolution pertinente est une plus grande précision concernant les comportements pris en charge et la conformité.

Un document révisé compte lorsqu’il résout une ambiguïté à laquelle les implémenteurs sont confrontés. Une liste plus longue de participants compte moins si elle n’apporte pas des contributions techniques correspondantes ou des produits pris en charge. Les lecteurs doivent distinguer la dynamique organisationnelle des progrès d’implémentation.

Des exigences plus claires renforceraient l’argument de Meta selon lequel les interfaces partagées peuvent réduire le travail répétitif. Une ambiguïté persistante affaiblirait cet argument, particulièrement lorsque les fournisseurs interprètent différemment une même exigence.

Le deuxième signal est la disponibilité des implémentations. Le récapitulatif d’octobre de Meta identifie une implémentation MetaRoCE en espace utilisateur disponible et décrit d’autres travaux logiciels comme à venir. Les logiciels en espace utilisateur s’exécutent hors du noyau du système d’exploitation, ce qui en fait une catégorie d’implémentation distincte.

Observez si le code disponible s’accompagne d’une documentation utilisable, de tests et de limitations clairement décrites. L’existence d’un dépôt est une invitation à enquêter. Elle n’équivaut pas à une large prise en charge en production.

Des implémentations supplémentaires prises en charge faciliteraient l’évaluation de l’architecture dans différents environnements. Des retards ou des frontières de prise en charge floues limiteraient ce que les organisations externes peuvent raisonnablement adopter, quelle que soit l’attrait de la conception sous-jacente.

Le troisième signal est la preuve opérationnelle. Recherchez des mesures de charges de travail qui expliquent les configurations, les conditions de défaillance et le comportement de reprise. Des évaluations indépendantes ajouteraient une perspective que les présentations d’entreprise ne peuvent fournir à elles seules.

Des preuves utiles doivent répondre à une question précise. Un système maintient-il la progression des applications lorsqu’une connexion se dégrade ? Les opérateurs peuvent-ils identifier le problème ? Le remplacement d’un composant exige-t-il des modifications au-delà de l’interface promise ?

Des résultats répondant à ces questions renforceraient l’argument pratique en faveur d’une infrastructure réutilisable. Des résultats montrant un travail substantiel propre au déploiement révéleraient où la standardisation reste incomplète. Dans les deux cas, ils seraient plus instructifs qu’un nouveau titre sur une capacité de pointe.

Pour les acheteurs d’entreprise, l’action immédiate consiste à affiner les critères d’évaluation. Demandez aux fournisseurs d’identifier les interfaces standardisées, les dépendances d’implémentation et les conditions couvertes par leur validation. Exigez une distinction claire entre les produits disponibles et les projets futurs.

Pour les développeurs et les équipes produits IA, la leçon est de suivre l’infrastructure utilisable plutôt que la capacité annoncée seule. Les progrès réseau comptent lorsqu’ils élargissent les expérimentations et les charges de travail qu’une équipe peut exécuter de manière fiable.

Commencez par l’architecture publiée et suivez les preuves jusqu’aux implémentations, rapports de qualification et comportements de maintenance. Comparez les systèmes en fonction de la charge de travail que vous devez réellement exploiter. Gardez les déploiements actuels séparés des aperçus, et les mesures d’entreprise séparées des conclusions indépendantes. Les réseaux Meta OCP 2026 proposent une orientation détaillée pour une infrastructure IA ouverte ; l’étape suivante utile consiste à examiner quelles parties se traduisent par des résultats opérationnels reproductibles. Lors de l’examen de la prochaine proposition de fournisseur ou mise à jour technique, posez une question concrète : quelle interface documentée, implémentation prise en charge ou comportement mesuré rend ce système plus facile à déployer et à maintenir en fonctionnement ?