🚀 Meta Prometheus : 1M GPU Nvidia pour supercalculateur IA
Découvrez Meta Prometheus : 1M de GPU Nvidia pour un supercalculateur IA. Fiabilité, réseau et énergie en centre de données IA—coûts réels inclus.
Prometheus : le pari de Meta sur un million de GPU pour l'IA
Un modèle d'intelligence artificielle ne se construit pas seulement avec de bons algorithmes. À grande échelle, il faut aussi des milliers de machines capables de travailler ensemble, un réseau qui ne casse pas l'entraînement, et une infrastructure assez fiable pour qu'une panne ne transforme pas des heures de calcul en perte sèche. C'est exactement le genre de problème industriel que Meta cherche à résoudre avec Prometheus, son supercalculateur installé à New Albany, dans l'Ohio.
La première phase du projet est en service et a déjà servi à entraîner la famille de modèles Muse, dont Muse Wonder. Meta annonce ensuite vouloir faire évoluer l'infrastructure vers environ un million de GPU distribués, coordonnés entre eux. L'ambition est réelle. Mais le chiffre, à lui seul, ne dit pas comment tout cela se comporte dans la durée : à cette taille, le réseau, la maintenance, la consommation électrique et le pilotage opérationnel pèsent autant que les puces.
Voici ce que les détails publiés par Meta permettent de comprendre : comment Prometheus est assemblé, pourquoi la fiabilité devient un enjeu central, et quels compromis l'infrastructure impose aux entreprises qui veulent entraîner des modèles à grande échelle.
Un million de GPU : l'ambition derrière Prometheus
Meta présente Prometheus comme un supercluster destiné à regrouper environ un million de GPU distribués, avec un fonctionnement annoncé « en parfaite coordination ». Le site est à New Albany, dans l'Ohio. Selon l'entreprise, l'endroit était encore, deux ans plus tôt, un centre de données plus classique, orienté vers le trafic web. Il accueille désormais une infrastructure de calcul dédiée à l'entraînement de modèles d'IA.
La première phase du projet, qualifiée de gigawattique par Meta, est terminée. Elle a notamment servi à entraîner Muse, dont Muse Wonder. Cette transformation reflète un changement de fond : les centres de données ne servent plus uniquement à stocker des données et répondre à des requêtes. Ils doivent aussi encaisser des charges de calcul très élevées, parfois pendant longtemps, avec des milliers d'accélérateurs qui travaillent en même temps.
Le cap d'un million de GPU mérite toutefois d'être pris pour ce qu'il est : une cible d'infrastructure. Meta indique que Prometheus exploite aujourd'hui des centaines de milliers de GPU et qu'une montée en puissance est prévue. Autrement dit, la capacité maximale annoncée ne veut pas dire que tout l'équipement est installé, disponible et utilisé en continu.
Pourquoi réunir autant d'accélérateurs ?
L'entraînement de modèles de grande taille demande beaucoup de calcul. Ajouter des GPU peut réduire le temps nécessaire pour certaines opérations, à condition que les machines échangent les données rapidement et restent synchronisées. Sinon, la complexité liée aux communications augmente plus vite que le gain.
C'est là que la formule mise en avant par Meta - des GPU qui fonctionnent « en lockstep » - éclaire mieux l'enjeu que le seul nombre. Dans un entraînement distribué, plusieurs machines calculent des morceaux du travail et doivent se coordonner régulièrement. Si une partie du cluster répond lentement (ou tombe en panne), le reste doit attendre. Dans ces conditions, la capacité installée ne vaut que si le système qui l'orchestre tient la route.
Pour une entreprise, la question utile n'est donc pas seulement « combien de GPU avons-nous ? ». Elle doit aussi porter sur : combien sont réellement disponibles pour le travail prévu, quelle part du temps est productive, et à quel coût énergétique et opérationnel. Ce sont ces indicateurs qui relient la taille du cluster à un résultat concret : entraîner un modèle, améliorer un service, ou réduire le délai de mise sur le marché.
Une première phase déjà associée à des modèles
Meta précise que la première phase de Prometheus a été utilisée pour entraîner les modèles Muse. Cela aide à situer l'usage de l'infrastructure, mais pas à comparer directement la qualité des modèles, ni le coût, ni la performance par rapport à d'autres acteurs. Pour juger la valeur d'un supercalculateur, il faut séparer la performance matérielle de ce que produisent réellement les modèles et de l'utilité de ces modèles dans des produits concrets.
Cette nuance compte particulièrement pour les entreprises européennes qui observent l'accélération de la course aux infrastructures. Un parc de calcul peut devenir un avantage si les équipes savent le traduire en fonctionnalités, en gains de productivité ou en nouveaux services. Sans cas d'usage bien établi, il reste surtout un coût fixe élevé : de l'énergie à payer, de la maintenance à assurer, et des compétences à mobiliser au quotidien.
Une infrastructure pensée comme un système distribué
Prometheus n'est pas un simple ensemble de serveurs. Meta dit s'appuyer sur deux plateformes Nvidia : Catalina, basée sur des racks GB200 NVL72, et Clemente, qui utilise des racks GB300 NVL72. Dans chaque rack, on retrouve 72 GPU conçus pour fonctionner comme un accélérateur à grande échelle. Une troisième plateforme, San Miguel, doit intégrer des racks Vera Rubin NVL72.
Avoir plusieurs générations n'est pas qu'une question technique : c'est aussi un choix opérationnel. Les équipements n'arrivent pas tous au même moment, les besoins évoluent, et les composants ne se trouvent pas à la même vitesse. Le défi consiste alors à faire cohabiter ces plateformes sans transformer le logiciel, l'exploitation et la maintenance en chantier permanent. Une architecture plus récente apporte plus de capacité, mais elle ne supprime pas les contraintes liées au parc déjà déployé.
Les racks sont installés dans différents types de bâtiments : des centres de données classiques, des bâtiments pensés pour l'IA, et des structures déployables plus rapidement. Tout cela est relié par des kilomètres de fibre. À l'intérieur d'un site, le réseau peut connecter jusqu'à 20 736 GPU. Un autre réseau d'agrégation relie ensuite les bâtiments, parfois distants de 2 kilomètres à plus de 100 kilomètres. Meta ajoute aussi utiliser de la capacité louée auprès de partenaires.
Le réseau est une partie du calcul
Dans un cluster distribué, le réseau n'est pas un accessoire qu'on ajoute après avoir choisi les GPU. Les accélérateurs doivent échanger des données pendant l'entraînement. Si ces échanges prennent trop de temps, les unités de calcul restent en attente, au lieu de travailler. À grande échelle, une fragilité locale peut donc dégrader le rendement global d'un ensemble très coûteux.
Le réseau à l'intérieur d'un bâtiment et le réseau entre bâtiments posent des contraintes différentes. À courte distance, l'objectif est d'assurer des échanges extrêmement rapides. À plus longue distance, la bande passante, la latence et la disponibilité des liaisons deviennent décisives. Et relier plusieurs bâtiments ne revient pas automatiquement à en faire un seul ordinateur : il faut que le logiciel gère la distribution du travail, ainsi que les incidents, sans trop pénaliser les calculs.
C'est un point utile pour les organisations qui projettent leurs propres infrastructures IA. La performance dépend d'un tout : accélérateurs, interconnexions, stockage, logiciel de pilotage, refroidissement, alimentation électrique et équipes d'exploitation. Acheter du matériel haut de gamme sans vérifier où se situent les goulots d'étranglement du système revient à payer une capacité « sur le papier » qui restera en partie inutilisée.
Les architectures mixtes et la capacité louée
Le fait que Meta combine plusieurs générations de racks et ajoute de la capacité venant de partenaires rappelle qu'un supercluster peut se construire par étapes. Il n'est pas toujours nécessaire de posséder chaque bâtiment et chaque GPU. La location peut accélérer l'accès aux ressources, mais à condition de maîtriser les coûts, les niveaux de service, la sécurité et la dépendance à un fournisseur.
Pour une entreprise française ou européenne, l'arbitrage dépend surtout du profil de charge. Si la demande est irrégulière, la location peut réduire le risque d'avoir des équipements sous-utilisés. À l'inverse, si l'usage est prévisible, intensif et durable, une infrastructure dédiée peut mieux coller. Dans les deux cas, il faut intégrer les coûts réseau, d'exploitation et de disponibilité, pas seulement le prix d'un GPU.
La fiabilité, condition économique de l'entraînement
À grande échelle, une panne isolée peut suffire à perturber un entraînement qui mobilise des milliers de machines. Meta indique qu'au milieu de 2025, lors de la première phase, les interruptions ont atteint près de 1 000 événements par jour pour 8 000 GPU. Après environ un an de travail d'ingénierie, l'entreprise dit avoir réduit ce niveau de 99 %.
Ce chiffre ne veut pas dire que tout a disparu. Il montre surtout que la fiabilité se construit et se reconstruit : détection des défauts, analyse des causes, corrections logicielles et matérielles, puis validation à l'échelle. Un système peut paraître stable sur quelques dizaines de machines et révéler d'autres modes de panne une fois que l'on mobilise des milliers d'accélérateurs.
Meta rapporte que les premiers gros problèmes concernaient la qualité du signal sur plus de 600 000 connexions NVLink entre GPU. Puis, à mesure que les racks GB300 ont été déployés, les défauts liés à la mémoire auraient pris plus d'importance. Les causes évoluent donc avec l'architecture et la taille du cluster. Une amélioration obtenue sur une génération ou un sous-système ne garantit pas que le même sujet restera prioritaire après une nouvelle étape de croissance.
Mesurer le temps réellement productif
Pendant l'entraînement de Muse Wonder, Meta indique que le cluster a maintenu plus de 85 % du temps de pré-entraînement en activité productive, et plus de 90 % pour l'apprentissage par renforcement. L'entreprise évoque aussi environ 47 000 heures GPU en moyenne entre les interruptions, un chiffre qui serait passé au-delà de 54 000 après des correctifs de micrologiciel. Son objectif est d'atteindre environ 100 000 heures GPU entre interruptions.
Ces indicateurs ne se résument pas à une seule lecture. La part de temps productif dit combien de temps, sur une période donnée, est réellement consacré au travail utile selon la définition retenue par l'entreprise. Le temps moyen entre interruptions donne une autre perspective : à quelle fréquence le système casse. Pour suivre un cluster, une équipe doit regarder plusieurs métriques et préciser ce qu'elles recouvrent : une valeur isolée ne suffit pas à décrire la disponibilité réelle d'un entraînement.
Et le raisonnement économique est assez direct. Si des milliers de GPU attendent une réparation ou un redémarrage, l'organisation paie l'électricité, l'infrastructure et le temps des équipes, sans produire le même volume de calcul utile. Réduire les interruptions peut donc rapporter autant (ou plus) que gagner une génération de performance. Dans certains cas, améliorer l'exploitation produit plus de valeur que d'empiler encore de la capacité.
Les GPU de réserve ont un coût, mais aussi une fonction
Meta explique que chaque rack de 72 GPU exécute une tranche de 64 GPU, et garde les huit autres comme unités de secours. Environ 2 % des racks seraient aussi conservés en réserve. Pour un entraînement mobilisant 32 768 GPU, l'entreprise estime avoir besoin d'environ 37 656 GPU au total, soit une surcapacité d'environ 13 %.
Sur le papier, ça peut sembler lourd. Mais ces unités de secours servent à remplacer rapidement un composant défaillant et éviter d'interrompre une large partie du travail. Le bon comparatif n'oppose donc pas simplement GPU actifs et GPU inutilisés : il faut mettre en balance le coût de la redondance et celui des interruptions qu'elle permet d'éviter.
C'est un principe connu en exploitation, mais à cette échelle, il devient décisif. Une marge de sécurité raisonnable aide le système à encaisser les pannes. Une réserve trop généreuse immobilise du capital et de l'énergie. Le dimensionnement optimal dépend des taux de panne observés, du délai de remplacement, de la durée des tâches et de la capacité du logiciel à reprendre un calcul après interruption.
Énergie et stratégie : le coût du passage à l'échelle
Un cluster de cette taille ne consomme pas toujours de façon parfaitement régulière. Meta indique que lorsque des dizaines de milliers de GPU calculent et communiquent de manière synchronisée, la demande électrique peut varier de 30 à 40 %. Le lancement ou la mise en pause d'un grand travail peut provoquer des variations de plusieurs dizaines de mégawatts en quelques secondes.
Pour absorber ces mouvements, Meta utilise un mécanisme logiciel appelé Dynamo Dimmer, qui limite progressivement la puissance des GPU. Le dispositif est associé à des batteries déployées à plusieurs niveaux : dans les racks, sur le site, et à l'échelle du réseau. L'idée est d'éviter qu'un changement brutal de charge informatique se traduise immédiatement par une variation équivalente côté électricité.
Ce choix rappelle une évidence souvent sous-estimée : l'énergie ne se « règle » pas une fois que le centre de données est construit. Le logiciel d'orchestration doit intégrer les contraintes électriques, et l'infrastructure doit encaisser les variations sans faire décrocher le cluster. Au final, la performance dépend d'une coordination entre calcul, refroidissement, alimentation et exploitation du réseau.
Une promesse énergétique à examiner avec précision
Meta affirme payer l'intégralité de l'énergie consommée à New Albany et compenser cette consommation via de nouveaux achats et approvisionnements en énergie propre et renouvelable. Sauf que l'entreprise a quitté en juillet le pacte RE100, alors que son développement du gaz pour répondre aux besoins liés à l'IA avançait plus vite que ses approvisionnements renouvelables.
Ces éléments doivent être lus ensemble. Dire que l'entreprise paie l'énergie consommée décrit une responsabilité financière. Expliquer qu'elle compense par des achats ou des projets renouvelables décrit une stratégie d'approvisionnement. Mais cela ne signifie pas nécessairement que l'électricité renouvelable alimente physiquement le site à chaque heure où il tourne. Pour juger l'impact climatique, il faut plutôt regarder les sources disponibles localement, les périodes réelles de consommation, et les capacités qui sont réellement ajoutées au réseau.
Pour les entreprises européennes, cette précision compte aussi pour piloter les engagements climatiques et répondre aux obligations de reporting. Une promesse générale sur l'énergie « verte » ne remplace pas une analyse : contrats, consommation, émissions associées, et effets sur le réseau local. L'IA peut créer de la valeur, mais il faut mesurer l'empreinte avec des données exploitables pour les décisions d'investissement.
Prometheus comme modèle pour les projets suivants
Meta indique que son prochain supercluster, Hyperion, situé à Richland Parish, en Louisiane, est conçu à partir des enseignements tirés de Prometheus. L'entreprise a aussi annoncé un engagement d'un milliard de dollars envers les communautés où se trouvent ses centres de données. Pris ensemble, ces éléments replacent le développement d'une infrastructure de calcul dans un contexte plus large : énergie, emplois, eau, réseaux, et relations avec les collectivités.
Le projet met en avant un changement de nature des investissements autour de l'IA. Construire un centre de données ne consiste pas seulement à installer des serveurs dans un bâtiment disponible. Il faut aussi sécuriser une capacité électrique suffisante, anticiper l'évolution du matériel, relier plusieurs sites, et recruter des équipes capables d'exploiter l'ensemble au quotidien. Les enjeux locaux peuvent finir par compter autant que le choix des processeurs.
Pour une entreprise qui ne construit pas elle-même un supercluster, la leçon reste valable. Avant d'augmenter le volume de calcul, il faut établir un lien clair entre les ressources consommées et le résultat métier. Un cluster plus grand n'est pas automatiquement plus pertinent pour un service client, une fonction de recherche interne ou un projet d'automatisation. Parfois, le bon choix est un modèle plus petit, une approche hybride ou une solution hébergée - à condition que le besoin soit couvert avec un coût et un niveau de risque maîtrisés.
Conclusion : le calcul ne suffit pas
Prometheus montre ce que signifie, concrètement, faire passer l'IA à l'échelle industrielle. Le million de GPU attire l'œil, mais l'enjeu central, c'est la capacité à faire fonctionner l'ensemble : accélérateurs, réseau, logiciels, systèmes électriques et équipes d'exploitation. La baisse des interruptions, le recours à des unités de secours et la gestion des variations de puissance comptent autant que la « capacité brute ».
Pour une organisation, la leçon n'est pas de vouloir reproduire la taille de Meta. Elle consiste plutôt à mesurer le rendement du système complet : temps utile, coût par tâche, consommation énergétique, disponibilité et valeur produite. Avant d'augmenter le calcul, cherchez les goulots d'étranglement et vérifiez que l'usage métier justifie réellement la dépense.
Pour approfondir les chiffres et les choix techniques rapportés par l'entreprise, consultez l'article de The Next Web consacré à Prometheus.