⚡ electrical engineering

Provisioning to Runtime Optimization of a +100 MW AI Cluster

Ce document présente le premier compte rendu de bout en bout de la gestion de l'énergie pour un centre de données d'IA à hyper-échelle, détaillant le processus depuis la planification précoce de l'alimentation pour les accélérateurs de nouvelle génération jusqu'à l'optimisation en temps réel d'une installation de 150 MW hébergeant 83 000 GPU GB200.

Auteurs originaux : Ehsan K. Ardestani, Leonardo Piga, Jovan Stojkovic, Pavan Balaji, Mustafa Ozdal, Mikel Jimenez Fernandez, Mihaela Dimovska, Luka Tadic, Hao Shen, Devika Vishwanath, Richa Mishra, Melaku Mihret, Valent

Publié 2026-05-26

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Ehsan K. Ardestani, Leonardo Piga, Jovan Stojkovic, Pavan Balaji, Mustafa Ozdal, Mikel Jimenez Fernandez, Mihaela Dimovska, Luka Tadic, Hao Shen, Devika Vishwanath, Richa Mishra, Melaku Mihret, Valentin Andrei, Mauricio Cespedes, Julien Prigent, James Monahan, Tyler Graf, Bin Li, Charles Marquez, Shobhit Kanaujia, Kaushik Veeraraghavan, Chunqiang Tang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez de construire le plus grand et le plus puissant supercalculateur au monde pour résoudre les problèmes les plus difficiles de l'intelligence artificielle. Vous avez acheté des milliers des puces informatiques les plus rapides que l'argent puisse acheter (GPU). Mais il y a un piège : vous n'avez pas assez d'électricité pour les faire tous fonctionner à pleine vitesse.

En fait, l'article soutient que manquer d'électricité est désormais un problème plus grand que manquer de puces informatiques. C'est comme avoir une flotte de 100 voitures de course mais seulement assez d'essence pour en remplir la moitié.

Cet article décrit comment Meta (la société derrière Facebook) a résolu ce problème pour un centre de données massif de 150 mégawatts. Ils n'ont pas simplement branché tout le monde et espéré le meilleur ; ils ont traité l'électricité comme une ressource précieuse et limitée devant être gérée en trois étapes distinctes.

Voici l'histoire de comment ils l'ont fait, en utilisant des analogies simples.

Les Trois Étapes de la Gestion de l'Électricité

Les auteurs décomposent le processus en trois phases : Planification, Vérification et Exécution.

Phase 1 : Planification (La phase de « Budgetisation »)

Avant même que les ordinateurs n'arrivent, l'équipe devait déterminer combien ils pouvaient en faire entrer dans leur budget électrique fixe.

L'Ancienne Méthode : Habituellement, les ingénieurs regardent la « vitesse maximale » d'une puce (sa Puissance de Conception Thermique, ou TDP) et supposent que c'est ce qu'elle utilisera toujours. Si une puce est évaluée à 1 200 Watts, ils prévoient 1 200 Watts.
La Méthode Meta : Ils ont réalisé que s'ils forçaient chaque puce à fonctionner à son maximum absolu, ils ne pourraient en installer que quelques-unes dans le bâtiment. Au lieu de cela, ils se sont demandé : « Et si nous faisions fonctionner toutes les puces légèrement moins vite ? »
L'Analogie : Imaginez un buffet avec une quantité fixe de nourriture.
- Stratégie A : Donnez à chacun un repas massif de 10 plats. Vous ne pouvez nourrir que 50 personnes.
- Stratégie B : Donnez à chacun un repas légèrement plus petit de 8 plats. Maintenant, vous pouvez nourrir 60 personnes.
- Le Résultat : Même si chaque personne a reçu un peu moins de nourriture, la quantité totale de nourriture consommée par le groupe est plus élevée, et plus de personnes sont nourries.
La Découverte : Ils ont constaté qu'en abaissant la limite de puissance de chaque GPU de 1 200 Watts à environ 1 000 Watts, ils pouvaient installer beaucoup plus de GPU dans le centre de données. La légère baisse de vitesse pour chaque puce individuelle était plus que compensée par le fait d'avoir plus de puces travaillant ensemble. Cela leur a donné un saut de 10 % dans la puissance de calcul totale.

Phase 2 : Vérification (La phase de « Réalité »)

Une fois les ordinateurs installés, l'équipe a réalisé que leurs plans ne correspondaient pas parfaitement à la réalité.

Le Problème : Les compteurs de puissance internes des ordinateurs (PSU) mentaient. Ils étaient excessivement prudents, signalant que les machines consommaient plus d'électricité qu'elles ne le faisaient réellement. C'est comme un jauge de carburant de voiture qui indique toujours « Vide » alors qu'il reste encore un quart de réservoir.
La Solution : Ils ont comparé les compteurs internes aux capteurs principaux du bâtiment (qui sont très précis). Ils ont constaté que s'ils ignoraient les lectures « au pire des cas » et regardaient la consommation « moyenne » (spécifiquement le 70e percentile), ils pouvaient faire davantage confiance aux chiffres.
Le Résultat : Parce qu'ils ont cessé de faire confiance aux compteurs internes excessivement prudents, ils ont réalisé qu'ils avaient un peu de puissance « cachée » qu'ils n'utilisaient pas. Ils ont légèrement remonté la puissance (de 1 000 W à 1 020 W), extrayant un autre gain de performance de 2 %.

Phase 3 : Exécution (La phase de « Agent de Circulation »)

Maintenant, le centre de données exécute des tâches d'entraînement d'IA en direct. Le problème est que les charges de travail d'IA sont « synchrones », ce qui signifie que toutes les puces doivent attendre les autres. Si une puce est lente, tout le travail ralentit.

Le Problème : Parfois, le réseau électrique subit une pointe soudaine. Si le système détecte une pointe, l'ancienne méthode consistait à immédiatement éteindre ou ralentir une puce spécifique pour économiser de l'énergie. Mais dans une course synchronisée, si vous ralentissez un coureur, toute l'équipe perd.
La Solution (Gradateur) : Ils ont construit un système intelligent appelé « Dimmer ». Au lieu de punir une puce, il réduit doucement la puissance de toutes les puces de la tâche d'une quantité minuscule et égale.
L'Analogie : Imaginez un groupe de coureurs dans une course de relais. Si la piste devient glissante (limite de puissance), au lieu de faire trébucher un coureur (ce qui arrête toute l'équipe), l'entraîneur dit à tout le monde de courir juste un tout petit peu moins vite. L'équipe reste ensemble et la course continue sans s'arrêter.
Le Résultat : Cela empêche le système de planter et leur permet d'utiliser les derniers pourcents d'électricité « échouée » qui étaient auparavant gaspillés. Cela a ajouté un autre gain d'environ 2 %.

Autres Insights Clés

L'Effet « Goulot d'Étranglement » : Le centre de données est un mélange de différents matériels (ordinateurs, refroidissement, commutateurs réseau). Parfois, la limite de puissance n'est pas fixée par les ordinateurs, mais par le système de refroidissement ou les câbles réseau. Si une partie de la chaîne est faible, elle limite toute la chaîne.
Oscillations de Puissance : Lorsque les puces d'IA travaillent, elles s'arrêtent parfois une fraction de seconde pour se parler, ce qui fait que la consommation d'électricité plonge puis explose. L'équipe a créé un « lisseur logiciel » qui comble ces minuscules écarts avec du travail factice, maintenant la consommation d'électricité stable comme une rivière calme au lieu d'une mer agitée. Cela protège le réseau électrique du bâtiment contre les chocs.
Plus Récent est Mieux : Ils ont comparé leurs nouvelles puces (GB200) aux anciennes (H100). Les nouvelles puces sont si efficaces que même si elles consomment moins d'énergie par puce, le nouveau cluster est presque deux fois plus rapide que l'ancien l'aurait été dans le même bâtiment.

La Conclusion

En traitant l'électricité comme une ressource flexible plutôt que comme une limite fixe, et en la gérant soigneusement depuis la phase de planification jusqu'aux opérations quotidiennes, Meta a réussi à obtenir environ 14 % de puissance de calcul en plus de son centre de données de 150 mégawatts, sans construire un seul nouveau mur ni acheter un seul nouveau fil.

Ils n'ont pas trouvé de batterie magique ; ils ont simplement appris à utiliser l'électricité qu'ils avaient déjà beaucoup plus sagement.

Résumé Technique : De la Provisioning à l'Optimisation Runtime d'un Cluster IA de +100 MW

Énoncé du Problème

Le goulot d'étranglement principal dans la course vers l'Intelligence Artificielle Générale (IAG) a basculé de la disponibilité des accélérateurs d'IA vers l'alimentation électrique des centres de données. Alors que les recherches précédentes se sont concentrées sur la réduction des coûts des services publics, l'optimisation de l'utilisation des énergies vertes ou l'exploitation de la surabonnement d'énergie, ces études négligent souvent la réalité critique selon laquelle la planification de l'alimentation des centres de données doit prioriser la maximisation de la capacité de calcul totale dans un budget énergétique fixe. De plus, les travaux antérieurs ne traitent généralement que de la phase opérationnelle finale de la gestion de l'énergie, négligeant le processus de bout en bout qui s'étend de la planification précoce (6 à 12 mois avant la disponibilité du matériel) à la validation du déploiement et au réglage dynamique runtime.

Ce papier aborde le défi de la gestion de l'énergie pour un cluster IA hyperscale (150 MW, 83 000 GPU GB200) en présentant une approche holistique en trois phases : Provisioning, Validation du Déploiement et Optimisation Runtime Opérationnelle.

Méthodologie

Les auteurs proposent un cadre en trois phases pour la gestion de l'énergie, utilisant un centre de données de 150 MW hébergeant 83 000 GPU GB200 connectés via un réseau backend RDMA.

Phase 1 : Planification et Provisioning

Dans cette phase, l'objectif est de déterminer la configuration optimale du cluster pour maximiser le débit agrégé ( $T(p)$ ) dans un budget énergétique fixe ( $P_{total}$ ).

Modèle d'Optimisation : Les auteurs formulent le problème comme la maximisation de $T(p) = N(p) \cdot f(p)$ , où $N(p)$ est le nombre de GPU qui rentrent dans le budget et $f(p)$ est la performance par GPU à la limite de puissance $p$ .
Sélection de la Limite de Puissance : Au lieu d'utiliser la Puissance de Conception Thermique (TDP) de 1200 W, l'équipe analyse la courbe de performance par watt. Ils constatent que la réduction de la limite de puissance permet une densité de GPU plus élevée. Les données empiriques montrent que, bien que la bande passante HBM chute brutalement en dessous de 1000 W, elle reste constante entre 1000 W et 1200 W. Par conséquent, ils sélectionnent une limite de puissance de 960 W (80 % de la TDP) comme point de fonctionnement optimal, équilibrant la perte de performance par GPU contre le gain du nombre total de GPU.
Provisioning Holistique : La méthodologie prend en compte toute la hiérarchie de distribution d'énergie (Tableaux électriques principaux, Tableaux électriques, Panneaux de puissance des réacteurs) et inclut la consommation d'énergie non GPU (refroidissement, réseaux, CPU).

Phase 2 : Validation du Déploiement

Une fois le matériel déployé, l'équipe valide les hypothèses et affine les paramètres d'alimentation basés sur la télémétrie du monde réel.

Correction des Mesures : Les auteurs identifient que les lectures de l'Unité d'Alimentation (PSU) surestiment systématiquement la consommation réelle d'énergie. Pour corriger cela, ils comparent les données PSU avec des oscilloscopes haute précision et des capteurs DCIM du Panneau de Puissance des Réacteurs (RPP). Ils déterminent que l'utilisation du 70e percentile (P70) des échantillons PSU au sein d'une minute fournit l'estimation la plus précise de la puissance agrégée de l'armoire, minimisant le biais des valeurs maximales de PSU.
Analyse de la Marge : L'étude révèle un déséquilibre statique significatif de l'alimentation dans tout le centre de données dû à des mélanges de matériel hétérogènes (armoires GPU, armoires réseau, refroidissement) et à des contraintes de placement physique. Ce déséquilibre laisse environ 5 à 10 % de l'énergie « échouée » aux Tableaux Électriques Principaux (MSB) les plus contraints.
Ajustement : Sur la base des données de validation, l'équipe augmente la limite de puissance opérationnelle de la planification de 960 W à 1020 W, garantissant que la consommation de puissance P70 s'aligne sur le budget de l'armoire.

Phase 3 : Optimisation Runtime Active

Cette phase se concentre sur la gestion dynamique de l'énergie pour capturer l'énergie échouée restante et gérer les pics transitoires sans perturber les tâches d'entraînement.

Oscillations de Puissance : Les algorithmes d'entraînement synchrone provoquent des oscillations de puissance synchronisées. Pour atténuer cela, les auteurs mettent en œuvre une technique de « remplissage des lacunes » utilisant un lisseur de puissance basé sur le logiciel. Ce noyau génère une charge synthétique sur les Tensor Cores pendant les lacunes de communication, maintenant une consommation de puissance stable (jusqu'à 800 W par accélérateur) avec moins de 3 % de surcharge de performance.
Algorithme Dimmer : Pour gérer le plafonnement de l'énergie dynamiquement, ils ont développé « Dimmer ». Contrairement au plafonnement traditionnel qui force des baisses abruptes ou l'éviction des tâches, Dimmer réduit progressivement les limites de puissance sur tous les GPU d'une tâche lorsqu'un dispositif d'alimentation approche de sa limite (par exemple, 97 %).
- Conscience du Planificateur : Dimmer s'intègre au planificateur de tâches pour prioriser les grandes tâches de pré-entraînement critiques pour la mission. Il distribue les réductions de puissance uniformément pour éviter de créer des « traînards » qui bloqueraient l'ensemble de la tâche.
- Mécanismes de Sécurité : Le système utilise une fenêtre de moyenne de 7 secondes pour distinguer les pics transitoires des dépassements soutenus, s'alignant sur les caractéristiques de déclenchement des disjoncteurs. Un mécanisme de sécurité garantit que les hôtes reviennent à une limite globale sûre si la communication avec le contrôleur est perdue.

Contributions et Résultats Clés

Gestion de l'Énergie de Bout en Bout : C'est le premier papier décrivant le cycle de vie complet de la gestion de l'énergie pour un cluster IA hyperscale, de la planification pré-déploiement à l'optimisation runtime.
Limitation de Puissance Optimale : L'étude démontre que faire fonctionner les GPU en dessous de leur TDP maximale (spécifiquement à 960 W initialement, puis validé à 1020 W) maximise le débit total du cluster. Réduire la puissance de 1200 W à 1000 W économise 16,7 % d'énergie avec seulement une baisse de performance de 5 %, permettant une densité de GPU significativement plus élevée.
Précision des Mesures : Le papier identifie que la télémétrie PSU surestime l'utilisation de l'énergie. L'adoption d'une méthode d'agrégation P70 corrige ce biais, permettant une budgétisation de l'énergie plus précise.
Déséquilibre Statique : L'hétérogénéité du matériel et les contraintes physiques créent une marge de puissance inégale dans l'installation. Les MSB les plus contraints dictent la plage de fonctionnement sûre, laissant jusqu'à 10 % de l'énergie échouée si elle n'est pas gérée dynamiquement.
Optimisation Dynamique : Le système « Dimmer » et les techniques de lissage de puissance capturent avec succès le pourcentage final d'énergie échouée. En évitant le throttling abrupt et en distribuant les réductions de charge, le système maintient la stabilité des tâches tout en maximisant l'utilisation.

Résultats

Le papier quantifie les améliorations de débit obtenues à travers chaque phase de leur méthodologie, comparant l'état final optimisé à une ligne de base de 1200 W par GPU :

Phase de Provisioning : L'optimisation pour la performance par watt (limite de 960 W) a augmenté le débit du cluster de 10 % par rapport à la ligne de base de 1200 W en permettant une densité de GPU plus élevée.
Validation du Déploiement : L'affinement de la limite de puissance à 1020 W basé sur la télémétrie du monde réel a fourni une augmentation supplémentaire de débit d'~2 %.
Optimisation Runtime (Dimmer) : La gestion dynamique de l'énergie échouée et des oscillations de puissance a produit une amélioration supplémentaire d'~2 %.
Gain Total : L'effet cumulatif de ces stratégies a résulté en une amélioration totale de ~14 % du débit du cluster par rapport à la configuration initiale de 1200 W.

De plus, le papier note que par rapport à la génération H100, le GB200 à 960 W délivre 2,4 fois la performance par GPU et 1,9 fois le débit agrégé du cluster dans le même budget énergétique.

Signification et Revendications

Les auteurs positionnent ce travail comme un guide fondamental pour l'industrie, allant au-delà de la gestion de l'énergie centrée sur les coûts pour des stratégies centrées sur la capacité essentielles au développement de l'IAG. Ils affirment qu'il s'agit du premier rapport à l'échelle de la production couvrant les trois phases de la gestion de l'énergie pour un cluster IA de 150 MW.

Le papier souligne que l'alimentation électrique est désormais le facteur limitant principal pour l'IAG, surpassant la disponibilité des accélérateurs. En partageant des insights sur le provisioning de l'énergie, la correction des mesures et le réglage dynamique runtime, les auteurs visent à encourager d'autres praticiens à partager leurs expériences et à faire progresser collectivement l'efficacité de l'infrastructure IA. Ils déclarent explicitement que leur objectif n'est pas de proposer de nouveaux algorithmes théoriques, mais de partager des expériences et des résultats pratiques, testés en production, qui peuvent guider les futurs praticiens dans la conception de centres de données IA efficaces et évolutifs.