10 · Énergie et efficacité

Complément technique de GIIG35. Ce chapitre traite la mesure et le réglage de la consommation — le savoir opérationnel dont une équipe de compétition a besoin sous un budget de 10 000 W, et que l'UE de management n'abordera pas.

Difficulté : ★★ · ⏱ 15 h

Les grandeurs et les unités

Confusion très fréquente, à régler d'emblée.

Grandeur	Symbole	Unité	Ce que c'est
Puissance	\(P\)	watt (W)	Un débit d'énergie, à un instant
Énergie	\(E\)	joule (J) ou kWh	Une quantité, cumulée
Efficacité énergétique	—	FLOP/J ou GFLOPS/W	Le travail par unité d'énergie

La relation, pour une puissance constante :

\[ E = P \times t \]

Les deux contraintes sont différentes. Une compétition impose une limite de puissance instantanée (10 000 W), qui est une contrainte d'alimentation électrique. L'impact environnemental et la facture dépendent de l'énergie consommée, donc du produit puissance-temps.

Conséquence contre-intuitive : paralléliser peut réduire l'énergie, même si cela augmente la puissance. Un code qui tourne deux fois plus vite à puissance 1,5 fois supérieure consomme 25 % moins d'énergie. La raison est la puissance statique — celle que la machine consomme même sans calculer — qui est payée pendant toute la durée.

En notant \(P_{\text{stat}}\) la puissance statique et \(P_{\text{dyn}}\) la puissance dynamique liée au calcul :

\[ E = (P_{\text{stat}} + P_{\text{dyn}}) \times t \]

Réduire \(t\) réduit la part statique. C'est la justification énergétique du HPC : finir vite est économe.

Mesurer la puissance

Quatre voies, de la plus fine à la plus globale.

1. RAPL, côté processeur

Les processeurs Intel et AMD récents exposent des compteurs d'énergie par domaine (paquet, cœurs, mémoire) via l'interface RAPL (Running Average Power Limit).

# L'énergie consommée par le paquet processeur pendant l'exécution
perf stat -e power/energy-pkg/,power/energy-ram/ ./mon_binaire

# Ou directement par le sysfs
cat /sys/class/powercap/intel-rapl:0/energy_uj

LIKWID intègre RAPL : likwid-perfctr -g ENERGY donne directement la puissance moyenne et l'énergie, avec les FLOPS, donc l'efficacité en GFLOPS/W en une seule mesure.

Précision et limites : RAPL est un modèle, pas un wattmètre. Il est généralement bon à quelques pour cent près sur le paquet processeur, moins fiable sur la mémoire selon les générations. Il ne compte ni les disques, ni les ventilateurs, ni l'alimentation.

2. nvidia-smi et équivalents, côté accélérateur

# Puissance instantanée et limites
nvidia-smi -q -d POWER

# Surveillance continue, une ligne par seconde
nvidia-smi dmon -s p

# Journalisation dans un fichier pendant un calcul
nvidia-smi --query-gpu=timestamp,power.draw,utilization.gpu,temperature.gpu \
           --format=csv -l 1 > puissance.csv

L'équivalent AMD est rocm-smi.

3. IPMI, côté serveur

Le contrôleur de gestion de la carte mère expose souvent la consommation totale du serveur à la prise :

ipmitool sensor list | grep -i pwr
ipmitool dcmi power reading

C'est la mesure la plus complète pour un nœud, et c'est celle qui compte pour un budget électrique de compétition.

4. Le wattmètre à la prise

La seule mesure incontestable, et celle qu'utilise le Green500 dans sa méthodologie la plus rigoureuse. Pour une compétition, le boîtier de distribution fourni par l'organisateur joue ce rôle, et c'est lui qui déclenche la pénalité.

Les mesures ne sont pas comparables entre elles

RAPL mesure le paquet processeur. nvidia-smi mesure la carte. IPMI mesure le serveur. Le wattmètre mesure la prise, donc l'alimentation avec son rendement.

Entre la somme des composants et la mesure à la prise, il y a couramment 20 à 30 % d'écart : rendement de l'alimentation, ventilateurs, carte mère, réseau.

Pour un budget de compétition, seule la mesure la plus globale compte. Dimensionnez avec une marge.

Limiter la puissance

Le levier central, et le plus rentable.

Sur accélérateur :

# Voir les limites actuelles et les bornes
nvidia-smi -q -d POWER | grep -i limit

# Fixer un plafond (nécessite les privilèges)
sudo nvidia-smi -pl 250

Sur processeur : les gouverneurs de fréquence et les états de performance.

# Gouverneur performance : fréquence maximale, pas de variation
sudo cpupower frequency-set -g performance

# Limiter la fréquence maximale
sudo cpupower frequency-set -u 2.0GHz

# Limiter la puissance par RAPL (écriture dans le powercap)
echo 150000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw

Et l'autre levier, souvent meilleur : réduire le nombre de cœurs ou d'accélérateurs actifs. Sur un code limité par la bande passante mémoire, la moitié des cœurs suffit à saturer le contrôleur : les autres consomment sans rien apporter. Désactiver la moitié des cœurs peut donc réduire la puissance de 30 % sans perte de performance mesurable.

La courbe performance-puissance

Le résultat expérimental le plus utile du chapitre.

Si l'on trace la performance d'un code en fonction du plafond de puissance imposé, on obtient une courbe concave : la performance croît vite au début, puis sature.

Performance
    │                    ┌──────────  ← saturation
    │                ╱
    │            ╱
    │        ╱
    │    ╱
    │  ╱
    └────────────────────────────────▶ Plafond de puissance
      50 %              80 %    100 %

Le fait à retenir : sur la plupart des accélérateurs et pour la plupart des codes, limiter la puissance à 70-80 % du maximum ne coûte que 5 à 15 % de performance. Le dernier quart de puissance achète très peu de performance, parce que la fréquence croît avec le carré ou le cube de la puissance dissipée.

La conséquence en compétition est directe et importante. Sous un budget global de 10 000 W, deux stratégies :

• A : quatre accélérateurs à pleine puissance. Performance relative : \(4 \times 1{,}00 = 4{,}00\).
• B : cinq accélérateurs à 80 % de puissance. Performance relative : \(5 \times 0{,}90 = 4{,}50\).

La stratégie B est meilleure de 12 %, pour la même enveloppe électrique. C'est le genre de raisonnement qui distingue une équipe préparée.

Le point de meilleure efficacité

Si l'on trace l'efficacité (performance divisée par puissance) plutôt que la performance, la courbe a un maximum, et il n'est jamais à 100 % de puissance. Trouver ce point pour votre code et votre matériel est l'exercice E2 ci-dessous, et le résultat est directement exploitable.

Le Green500 et sa méthodologie

Le Green500 reprend les machines du Top500 et les classe en GFLOPS par watt mesurés pendant l'exécution de HPL.

La méthodologie de mesure de puissance est plus subtile qu'il n'y paraît, et elle définit plusieurs niveaux de qualité selon la fraction de la machine mesurée, la durée de l'échantillonnage et l'inclusion ou non des infrastructures. Lire ce document est instructif : il montre à quel point « mesurer la consommation d'un supercalculateur » est un problème de métrologie et non une simple lecture.

Ce que le Green500 apprend sur les architectures : le classement est dominé par les machines à accélérateurs, avec un écart important par rapport aux machines purement à processeurs généralistes. La raison est architecturale : un accélérateur consacre une bien plus grande fraction de ses transistors aux unités arithmétiques et une bien plus petite au contrôle (prédiction de branchement, exécution dans le désordre, gros caches). Il fait donc plus d'opérations par joule, au prix d'un modèle de programmation plus contraint.

Le PUE, et sa limite

Le PUE (Power Usage Effectiveness) d'un centre de données :

\[ \mathrm{PUE} = \frac{E_{\text{totale}}}{E_{\text{informatique}}} \]

Un PUE de 1,5 signifie que pour chaque kilowattheure de calcul, un demi est consommé par le refroidissement et l'infrastructure. Les centres HPC modernes, avec refroidissement liquide direct, visent 1,1 à 1,2.

La limite de la métrique, déjà signalée dans GIIG35 : le PUE ne dit rien sur l'efficacité du calcul. Un centre à PUE 1,05 qui exécute des codes non optimisés gaspille davantage qu'un centre à PUE 1,4 qui exécute des codes efficaces. Un code deux fois plus rapide vaut mieux, en énergie, qu'une amélioration de PUE de 1,4 à 1,05.

C'est un argument utile à connaître : l'optimisation de code est une action environnementale, et elle est souvent plus efficace que les actions d'infrastructure.

L'empreinte carbone, et le facteur d'émission

Convertir des kilowattheures en équivalent carbone nécessite un facteur d'émission du réseau électrique, exprimé en grammes de CO₂ équivalent par kilowattheure.

Ce facteur varie d'un ordre de grandeur entre pays européens, selon le mélange de production. Il varie aussi dans la journée et dans l'année.

La conséquence est inconfortable : pour un calcul donné, la localisation du centre pèse souvent plus lourd que la qualité de l'optimisation du code. Un code non optimisé exécuté dans un pays à électricité peu carbonée peut avoir une empreinte inférieure à un code optimisé exécuté ailleurs.

Cela ne dispense pas d'optimiser — l'énergie a un coût financier et une disponibilité limitée partout — mais cela doit figurer dans toute analyse honnête.

Pour les calculs pratiques : les facteurs d'émission par pays sont publiés par les agences nationales (l'ADEME en France) et par des services qui exposent des données en temps réel. CodeCarbon est une bibliothèque Python qui automatise l'estimation pour un calcul, très utilisée dans la communauté de l'apprentissage.

Exercices

E1 · ★ ⏱ 2 h — Première mesure d'énergie. Mesurer la puissance moyenne et l'énergie totale d'un calcul de deux minutes, par trois voies : perf stat avec RAPL, likwid-perfctr -g ENERGY, et IPMI si accessible. Comparer les trois valeurs et expliquer les écarts. Convertir en kilowattheures, puis en équivalent carbone avec deux facteurs d'émission différents.

E2 · ★★ ⏱ 4 h — La courbe performance-puissance. Sur un accélérateur, balayer le plafond de puissance de 50 % à 100 % du maximum par pas de 10 %, et mesurer à chaque point la performance d'un code de calcul. Tracer trois courbes : performance, énergie totale, et efficacité en performance par watt. Identifier le maximum d'efficacité et le comparer au point de performance maximale.

E3 · ★★ ⏱ 3 h — Énergie et parallélisme. Mesurer temps, puissance et énergie d'un même code sur 1, 2, 4, …, \(N\) cœurs. Tracer l'énergie totale en fonction du nombre de cœurs. Sur un code qui passe bien à l'échelle, l'énergie diminue quand on parallélise, à cause de la puissance statique. Sur un code qui passe mal, elle augmente. Estimer la puissance statique de la machine par extrapolation.

E4 · ★★★ ⏱ 3 h — L'optimisation sous contrainte. Formaliser puis résoudre le problème suivant : étant donné un budget de puissance \(P_{\text{max}}\), un nombre \(n\) d'accélérateurs disponibles, et la courbe performance-puissance mesurée en E2, quel nombre d'accélérateurs et quel plafond par accélérateur maximisent la performance totale ? Résoudre numériquement, puis vérifier expérimentalement si vous avez le matériel.

C'est le calcul central du projet de GIIG35 et un avantage compétitif réel.

E5 · ★★★ ⏱ 3 h — La surveillance en direct. Mettre en place une chaîne de surveillance qui affiche la puissance totale d'un ensemble de nœuds en temps réel (Scaphandre ou node_exporter vers Prometheus, tableau de bord Grafana), avec une alerte au-delà d'un seuil. Puis lancer un HPL et observer : la puissance pendant un HPL n'est pas constante, elle a un profil caractéristique avec un pic. C'est ce pic qui déclenche une pénalité en compétition, pas la moyenne.

Erreurs fréquentes

Six erreurs sur l'énergie

1. Confondre puissance et énergie. La contrainte de compétition porte sur la puissance instantanée ; l'impact porte sur l'énergie.
2. Prendre le TDP pour la consommation. Le TDP est une enveloppe de conception thermique. La consommation réelle peut être inférieure en charge modérée et supérieure brièvement en boost.
3. Mesurer la moyenne au lieu du pic. Pour un budget électrique, c'est le pic qui compte. Un HPL a un profil de puissance non uniforme.
4. Oublier ce que RAPL ne compte pas : disques, ventilateurs, rendement de l'alimentation, réseau. Entre 20 et 30 % d'écart avec la prise.
5. Ignorer le facteur d'émission dans une conclusion en équivalent carbone. Sans lui, le chiffre ne veut rien dire.
6. Croire que l'efficacité résout le problème. Le paradoxe de Jevons : les machines deviennent plus efficaces, et la consommation totale du secteur augmente parce qu'on calcule davantage. C'est un fait, et il mérite d'être énoncé plutôt que contourné.

Ressources

Priorité 1 :

• La méthodologie du Green500 (top500.org/lists/green500) : le document sur les niveaux de qualité de mesure de puissance. Court et instructif.
• La documentation RAPL et la page powercap de la documentation du noyau Linux.
• LIKWID, groupe ENERGY.

Priorité 2 :

• Scaphandre (hubblo-org.github.io/scaphandre-documentation/), outil français de mesure de consommation logicielle avec export Prometheus.
• CodeCarbon (codecarbon.io) pour l'estimation d'empreinte d'un calcul.
• PowerAPI, autre projet français de mesure fine.
• GEOPM (Global Extensible Open Power Manager) : gestion de puissance à l'échelle du travail sur un cluster. Le sujet de recherche opérationnel du domaine.

Priorité 3 :

• Les rapports de l'ADEME et de l'Arcep sur l'empreinte du numérique en France : les sources chiffrées de référence pour le contexte français.
• Strubell, Ganesh, McCallum, « Energy and Policy Considerations for Deep Learning in NLP », ACL 2019, et les travaux ultérieurs qui en ont révisé les estimations. Lire les deux côtés est l'exercice.
• Sur le paradoxe de Jevons et les effets rebond : la littérature en économie de l'énergie. C'est l'argument central du débat sur l'efficacité.
• Sur le power capping en HPC : chercher les articles sur le compromis performance-énergie et sur l'ordonnancement sous contrainte de puissance.

---

À retenir

Les cinq choses à savoir

1. \(E = P \times t\). La compétition contraint \(P\) ; l'environnement dépend de \(E\). Ce ne sont pas les mêmes optimisations.
2. Finir vite est économe, à cause de la puissance statique payée pendant toute la durée.
3. La courbe performance-puissance est concave : limiter à 70-80 % de la puissance coûte 5 à 15 % de performance. Sous budget électrique, plus d'accélérateurs bridés valent mieux que moins d'accélérateurs à fond.
4. Les quatre voies de mesure ne sont pas comparables : RAPL, nvidia-smi, IPMI, wattmètre. Pour un budget, prenez la plus globale, avec une marge.
5. Le facteur d'émission du réseau électrique pèse souvent plus que l'optimisation du code. À dire honnêtement, sans que cela dispense d'optimiser.

Partie suivante : Projets.