Bloc 1 · D. Lopez · ISEN partie 1
Green IT : ordres de grandeur, matériel, métriques
Un logiciel n'est jamais « hors sol » : microservices, puis conteneurs ou VMs, puis serveurs, réseau et datacenters, avec des utilisateurs partout dans le monde.
Les chiffres à connaître
ÉNERGIE 2020
4 % → 8–9 %
Part du numérique dans l'énergie mondiale : 4 % (estimation optimiste) à 8–9 % (IEA).
GES 2020
1,4 % (764 Mt) → 4 %
L'écart vient du périmètre choisi. La part monte chaque année.
PROJECTION
3,5 % en 2030 · 10 % en 2050
Si le numérique reste à 764 Mt par an pendant que le monde décarbone pour 1,5 °C (hypothèse jugée « trop optimiste »).
Secteurs (2016) : énergie 73,2 % (industrie 24,2 %, bâtiments 17,5 %, transport 16,2 %), agriculture et sols 18,4 %, procédés 5,2 %, déchets 3,2 %. Autres repères : 40 smartphones achetés par seconde, 281 milliards d'emails par jour, 50 milliards d'objets connectés, 344 Go par mois et par foyer (2020).
Proportionnalité énergétique
- Nameplate = somme des maxima des composants, plus haut que le pic réel mesuré à pleine charge.
- Idéal : la consommation monte proportionnellement à la charge en partant de 0 W. En réalité il y a un gros
P_idle, ce qui en fait presque un modèle ON/OFF.
- La proportionnalité s'améliore au fil des générations (2004 → 2018), mais l'écart à l'idéal reste.
- Réseau : la consommation ne suit pas le débit, elle dépend du nombre de modules et de ports actifs.
- Le matériel moderne consomme moins par unité (PUE, énergie par calcul, énergie par To), mais la demande dépasse toujours les gains.
Langage de programmation
Pas de gagnant universel
Cela dépend du problème (Pereira et al., SLE 2017). Mais les langages compilés sont plus verts que les interprétés : C, C++ et Rust sont de bons choix.
Temps ≈ énergie
Relation linéaire entre le temps de calcul et l'empreinte (HPC en astrophysique, Portegies Zwart 2020).
Cœurs et overclocking
L'overclocking augmente la consommation. Plus de cœurs améliore la capacité et l'efficacité, jusqu'à un point où trop de cœurs devient contre-productif.
SCI — Software Carbon Intensity (Green Software Foundation)
SCI = C / R = (O + M) / R O = E × I M = TE × (TiR / EL) × (RR / ToR)
| Symbole | Sens |
|---|
| R | unité de service rendu (utilisateur, requête…) : le SCI est une intensité, pas un total |
| E · I | énergie consommée (kWh) · intensité carbone de la région (gCO2eq/kWh) |
| TE | émissions de fabrication totales du matériel (analyse de cycle de vie) |
| TiR / EL | temps réservé pour le logiciel / durée de vie attendue du matériel |
| RR / ToR | ressources réservées / ressources totales |
| tSCI | version étendue (tO + tM)/R avec tO = O + O_idle et tM = M + M_idle : la part inactive du matériel est imputée au job au prorata |
| oSCI | version opérationnelle seule O/R : ignore la fabrication |
Exemple de calcul de tM (slide 31)
Serveur A : TE = 400 g, durée de vie 10 ans, 40 cœurs, J2 sur 10 cœurs. Serveur B : TE = 50 g, 5 ans, 10 cœurs, J1 sur 10 cœurs. Les jobs durent 1 an.
M(J1) = 50 × 1/5 × 10/10 = 10 g
tM(J1) = 10 + (400 × 1/10) × (30/40) × (10/20) = 10 + 15 = 25 g
30/40 = fraction inactive de A. 10/20 = part de J1 parmi les 20 cœurs utilisés du cluster.
The Sunk Carbon Fallacy (Bashir et al., SoCC 2024)
S_A est un ancien serveur (fabrication 0,11, usage 0,83), S_B un serveur récent (0,45 / 0,56), en g par Score-Yr, avec une électricité suédoise à 14 g/kWh.
| Métrique | S_A | S_B | Choix |
|---|
| SCI | 0,94 | 1,01 | S_A (à tort) |
| tSCI | 1,39 | 1,12 | S_B |
| oSCI | 0,83 | 0,56 | S_B |
| Bilan réel du cluster | 1,39 | 1,12 | S_B |
La fabrication de S_B est déjà dépensée (« sunk »), qu'on s'en serve ou non. Le SCI la compte quand même et pousse vers S_A. Le tSCI colle au bilan réel. L'oSCI donne ici le bon choix, mais pour une mauvaise raison (il ignore toute fabrication, ce qui favorise le renouvellement du matériel).
KPI des datacenters
PUE
Énergie totale / énergie IT
Il mesure l'efficacité de l'infrastructure (refroidissement, alimentation), pas celle du datacenter dans son ensemble. 1 = limite théorique. Slide : « Standard = 1,6, Good = 1,6, Better = 1,1 » (#à-revoir).
WUE
Eau du site / énergie IT
Water Use Effectiveness, en L/kWh.
ERE
(Total − réutilisée) / IT
Energy Reuse Effectiveness : elle récompense la chaleur réutilisée.
Écrans : mode clair ou sombre ?
AMOLED (chaque pixel émet sa lumière)
À faible luminosité (< 25 %), noir et blanc consomment presque pareil. À 100 %, le noir consomme beaucoup moins que le bleu ou le blanc.
IPS (rétroéclairage)
Toutes les couleurs consomment pareil : c'est la luminosité de l'écran qui pilote la consommation. Le mode sombre ne change presque rien.
IA vue par D. Lopez
Croissance
- ChatGPT : 1 million d'utilisateurs en 5 jours, 1,7 milliard de visites par mois.
- 149 LLM sortis en 2023 (×2). 25,2 Md$ de financements en IA générative (×8).
- Investissements des 5 géants de la tech : plus de 500 Md$ en 2025, +75 % prévus en 2026.
- Les performances augmentent grâce aux algorithmes, à des jeux de données plus gros, plus de stockage et de mémoire, du nouveau matériel (NVLink…) et le renouvellement du matériel.
Entraînement, inférence, déchets, société
- BLOOM (176 milliards de paramètres) ≈ 24,7 t CO2eq, mais sous-estimé : seule la partie dynamique des GPU est comptée, avec l'intensité française très basse, sans le réseau, sans les 1,6 To de données, sans les essais préalables. Un modèle perd en efficacité dans le temps et doit être réentraîné.
- Inférence : coût de l'instance au repos non nul. Les modèles de raisonnement pourraient la rendre plus gourmande que l'entraînement (débat ouvert).
- Déchets électroniques : 62 Mt en 2022 (+82 % depuis 2010), 82 Mt en 2030, dont 1,2 à 5 Mt dus à l'IA. Seulement 22 % recyclés. Les appareils durent 2 à 5 ans.
- Ghost data workers (annotation de données, salaires bas, contenus traumatisants), transformation des métiers, données personnelles, désalignement.
Bloc 2 · D. Lopez · sessions 1–2 · Lab 1 · Lab AI
Mesurer : profiling, RAPL, énergie des LLM
Profiling sous Linux
Pourquoi
Optimiser la mémoire, le CPU et la latence, donc baisser le coût d'exécution. Trois niveaux : matériel (IO, CPU, GPU), noyau (appels système, événements, changements de contexte), espace utilisateur (fonctions).
Sondes (probing)
Statiques (kprintf) ou dynamiques : kprobe/kretprobe (noyau), uprobe/uretprobe (espace utilisateur), avec offset possible. Flexibles mais fragiles : un renommage ou un inlining par le compilateur les casse.
Tracepoints
Annotations nommées posées par les développeurs : TRACE_EVENT (noyau), USDT (espace utilisateur). Coût nul s'ils ne servent pas, plus stables, mais seulement là où on les a mis.
Lab 1 — l'essentiel
sudo PYTHONPERFSUPPORT=1 perf record -g -o ~/perf.data python3 best_offer.py. Sans PYTHONPERFSUPPORT, les fonctions Python (compilées à la volée) sont invisibles pour perf. -g = --call-graph=fp.
Call graph = la chaîne des appels. Par défaut, perf mesure le temps d'une fonction mais pas qui l'appelle.
perf script > stack_traces.txt, puis speedscope en mode Left Heavy (temps agrégés, les plus lourds à gauche).
① sorth() est un tri naïf en O(n²) : on le remplace par results.sort(key=lambda x: x["score"], reverse=True) (tri intégré, powersort). ② calc_svc_score() recalcule rsvc.lower().strip() len(req)×len(avail) fois : on le sort de la boucle. ③ Changement d'architecture : table de hachage (dict ou set) au lieu de listes.
Comparaison : Java ≈ 1,6 s < Python, Rust ≈ 700 ms < Java. Dans la trace Rust, on ne reconnaît plus nos fonctions : le compilateur les inline et les renomme (mangling).
RAPL — Running Average Power Limit
- Intel depuis Sandy Bridge, aussi sur AMD. Il fixe des limites de puissance et fournit des « mesures », souvent des estimations par modèle, en joules.
- Domaines : Package (le socket) · PP0 (les cœurs) · PP1 (le GPU intégré) · DRAM · Psys (le SoC).
- Compteurs cumulés depuis le démarrage, mis à jour toutes les 1 ms, aveugles aux processus, 32 ou 64 bits donc risque de débordement. L'unité dépend du modèle (Sandy Bridge : 15,3 µJ).
- Réservé aux machines physiques : une VM n'y a souvent pas accès.
- Linux :
/sys/class/powercap/intel-rapl/, perf stat -a -e "power/energy-pkg/", ou les registres MSR (root).
- Windows : pas d'interface officielle, il faut le pilote Hubblo ou Scaphandre. Mac ARM : pas de RAPL, on utilise
powermetrics.
- Outils basés sur RAPL : Scaphandre, Joular Core, CodeCarbon. Autres méthodes : wattmètre externe (PDU intelligente), capteurs GPU (
nvidia-smi, NVML), simulateurs (CloudSim, DCSim).
Modèles de puissance du CPU (CloudSim)
P(u) = Pidle + (Pmax − Pidle) · f(u) f(u) ∈ { u , u² , u³ , √u }
EcoLogits : impact d'une requête LLM
E_GPU = #T_out × f_E(P_active, B) f_E = α·e^(β·B)·P_active + γ (α=1,17e-6 · β=−1,12e-2 · γ=4,05e-5)
ΔT = min(TTFT + #T_out / TPS , ΔT_req) M_model = 1,2 × P_total × Q / 8 #GPU = 2^⌈log2(M_model / M_GPU)⌉
E_svr = E_svr\GPU + #GPU × E_GPU (serveur hors GPU : W = 1,2 kW, 8 GPU installés, au prorata ΔT / B)
I_req = E_req × CI + (ΔT / ΔL) × I_fabrication_serveur
ML.ENERGY : E_req = (E_steady / Tks_steady) × (nombre moyen de tokens par requête).
Prefill ou decode ?
TOKENS D'ENTRÉE
Prefill : limité par le calcul
Toute l'entrée est traitée d'un coup, de façon massivement parallèle : très gourmand à durée égale.
TOKENS DE SORTIE
Decode : limité par la mémoire
Un token à la fois, beaucoup d'accès mémoire. Moins gourmand à durée égale, mais il y a bien plus de tokens de sortie (raisonnement inclus). C'est donc le nombre de tokens de sortie qui sert à estimer l'énergie. Exception : les entrées énormes (agents de code, résumés).
Lab AI — réponses du guide
Gemini 3 Flash : 0,5 $ par million de tokens d'entrée, 3 $ par million de tokens de sortie. Tokens de sortie facturés = candidates_token_count + thoughts_token_count.
Entrée courte et sortie longue : résolution de problème (raisonnement + explication). Entrée longue et sortie courte : code (beaucoup de contexte, une fonction à compléter).
EcoLogits donne une énergie min et max (chunk.impacts.energy.value.min/max), envoyée en POST JSON {"min","max"} avec un jeton Bearer.
Bloc 4 · F. Giroire · Green Algorithm Design
Algorithmes verts : consolider, puis éteindre
Les datacenters (45 %) et les réseaux (24 %) dominent la consommation du numérique. L'infrastructure est surdimensionnée, allumée 24 h/24, prévue pour l'heure de pointe, et sa consommation reste plate alors que le trafic descend à 40–50 % du pic la nuit. L'effort de recherche date de 2008–2009 (premiers travaux : Gupta 2003, Christensen 2004).
Taxonomie des approches (combinables)
RE-ENGINEERING
Silicium efficace · moins de complexité
Exemple : commutation optique, des térabits pour beaucoup moins de puissance. Encore loin d'être adoptée, bloquée par le plan de contrôle (Baliga 2007).
ADAPTATION DYNAMIQUE
Power scaling · idle logic
DVFS : on baisse la fréquence et la tension (P ≈ C·V²·f). Standard dans les CPU, rare dans les équipements réseau. Idle logic : on éteint des sous-composants entre deux rafales et on les réveille par un ordonnanceur interne, au prix d'une latence de réveil.
MISE EN VEILLE
Proxy de présence réseau
Mettre en veille des parties entières. Comme les services doivent rester joignables, un NCP (Network Connectivity Proxy, Christensen & Nordman 2004) répond à la place de l'hôte endormi. C'est la famille étudiée en cours.
Figure de Nedevschi 2008 : (a) aucune optimisation, puissance au max en permanence. (b) idle seul, la puissance tombe entre les rafales mais il y a un temps de réveil. (c) scaling seul, puissance plate mais plus basse. (d) les deux, le plus bas.
Les 4 cas de la figure de Nedevschi (2008, slide 129)
Rouge = puissance, bleu = paquets servis, pointillés = arrivée d'une rafale. (b) et (d) paient un temps de réveil (latence). (c) et (d) servent plus lentement à puissance réduite. Les niveaux sont illustratifs.
① Datacenters : consolidation de VMs = bin packing
- VM = objet de taille s(i), serveur = boîte de capacité B, K = nombre de serveurs allumés à minimiser, puis on éteint les serveurs vides.
- Fortement NP-complet. Aucune approximation absolue < 3/2 sauf si P = NP. Pseudo-polynomial si K est fixé, polynomial si B est fixé.
- Borne inférieure :
OPT ≥ ⌈Σ s(i) / B⌉.
- Algorithme d'approximation : temps polynomial + solution réalisable + facteur garanti de OPT (exemple : une 2-approximation utilise ≤ 2·OPT boîtes).
| Algo | Règle | Garantie |
|---|
| FF | toutes les boîtes restent ouvertes ; première boîte où l'objet rentre | ≤ 1,7·OPT |
| BF | boîte la plus remplie où l'objet rentre | ≤ 1,7·OPT |
| FFD | tri décroissant, puis FF | ≤ 11/9·OPT + 6/9 |
Les exercices des slides sont corrigés dans l'onglet 🧮 Exercices.
Pourquoi il faut éteindre : consolidation FFD sur 4 serveurs de capacité 10
—1 / 3
Planificateurs dynamiques : quand une VM arrive, ils considèrent toutes les VMs, manipulent la file d'attente et migrent des VMs pour faire de la place.
② Réseaux mobiles : antennes en veille = set cover
- Les antennes ne sont pas proportionnelles au trafic. Solution 1 : éteindre les antennes inutilisées (gain faible). Solution 2 : consolider (réassocier les utilisateurs aux antennes qui se chevauchent, puis éteindre les autres).
- Minimum Set Cover : U = les utilisateurs, S_i = les utilisateurs couverts par l'antenne i, coût uniforme c = 1. On cherche le minimum d'ensembles qui couvrent tout U.
- Filaire et sans-fil ont une empreinte comparable (0,14 contre 0,16 Gt en 2020), mais le mobile croît plus vite (5 %/an contre 4 %/an).
Glouton
On prend à chaque fois l'ensemble qui couvre le plus d'éléments non couverts. Temps linéaire (bucket queue). Ratio H(s) = Σ 1/k ≤ ln s + 1.
Contre-exemple (Ex. 2b) : S1 = {3,4}, S2 = {1,3,5}, S3 = {5,6}, S4 = {1,2}. Le glouton prend S2, puis S1, S3, S4, soit 4. L'optimum vaut 3 (S1, S3, S4).
Ex. 1 : S3 et S4 sont forcés (4 et 2 ne sont que dans eux), plus S1 ou S5, donc 3. Astuce : un élément présent dans un seul ensemble force cet ensemble.
Mettre les antennes en veille (slides 42 à 47)
—
③ Réseaux filaires : Energy Aware Routing
Un routeur consomme E0 à vide, déjà proche de Emax : la charge a peu d'influence, donc on éteint des interfaces et des châssis. On route toutes les demandes avec le minimum de routeurs et liens actifs, sous la contrainte de capacité. Le problème est NP-complet et non approximable : on utilise un MILP + solveur, ou l'heuristique LL-SP.
capacité des liens = 2 · demandes A–D, F–C, A–E
LL-SP
L = V
tant que L non vide :
lln = nœud le moins chargé de L
essayer d'éteindre lln ; router toutes les demandes par plus courts chemins
si impossible : rallumer lln, revenir au routage précédent
retirer lln de L
À retenir et annexe
| Où | Technique | Problème | Algorithmes |
|---|
| Datacenters | consolidation de VMs | bin packing | FF, BF, FFD |
| Mobile | antennes en veille | set cover | glouton, ratio H(s) |
| Réseau cœur | energy-aware routing | MILP, NP-complet et non approximable | LL-SP |
Annexe (slides 94–254) en 8 lignes
- Le trafic fait ×2 et la capacité des routeurs ×2,5 tous les 18 mois, contre ×1,65 pour l'efficacité du silicium (Dennard) : le matériel seul ne suffit pas.
- Empreinte du numérique : 1,3 % (2002), 1,9 % (2011), 2,3 % attendus (2020). Datacenters ≈ réseaux, terminaux ×2.
- Routeurs : le plan de données pèse 54 % de la consommation (dont 32 % pour la recherche d'adresse IP et le transfert). Serveurs utilisés à 15–20 %, liens de bordure à quelques %.
- Routage vert sur 10 topologies : 35 à 55 % d'équipements économisés, des routes plus longues d'un facteur 1,1 à 1,3, des chemins disjoints qui passent de 2,5 à 1,2. Une grille 4×4 prend 10 h avec CPLEX.
- SDN : contrôleur centralisé, le réseau devient un programme, ce qui permet le routage dynamique donc l'EAR. Mais la mémoire TCAM est chère et limitée à ~1000 règles, d'où la compression par règles joker (≈ −66 % de règles, 52 à 65 % d'énergie économisée).
- NFV : fonctions réseau virtualisées (pare-feu, DPI, répartiteur de charge, cache…), routes plus courtes, moins de matériel dédié, problèmes de placement et de migration.
- Virtualisation de réseau (Orange loue à Free) : on mutualise le matériel redondant.
- Défis : optimisation conjointe réseaux + datacenters (80 % du trafic est de la vidéo), IoT (des dizaines de milliards d'objets). GeSI SMART 2020 : le numérique ferait économiser plus qu'il ne consomme.
Les exercices du cours
Exercices avec énoncé et corrigé
Fais l'exercice sur papier, puis ouvre la correction. Chaque énoncé indique sa slide d'origine.
D'où viennent les corrigésLes slides donnent les énoncés, mais presque jamais la solution. corrigé du cours = la solution est sur les slides. corrigé calculé = la solution n'est pas sur les slides, je l'ai calculée en appliquant l'algorithme du cours et vérifiée par programme.
① Bin packing : ranger les VMs sur le moins de serveurs possible
Le problème (slide 26). On a des objets de tailles s(i) et des boîtes de capacité B. On veut le
nombre minimum de boîtes, noté OPT, sans dépasser B dans une boîte. Ici, objet = VM, boîte = serveur.
- FF (First-Fit) : l'objet va dans la première boîte ouverte où il rentre, sinon on en ouvre une nouvelle.
- BF (Best-Fit) : l'objet va dans la boîte la plus remplie où il rentre, sinon on en ouvre une nouvelle.
- FFD (First-Fit-Decreasing) : on trie les objets par taille décroissante, puis on applique FF.
Réflexe : commence par la borne inférieure ⌈somme des tailles / B⌉, on ne pourra jamais faire moins (remarque personnelle, pas écrite sur les slides).
Ex. 1.1slide 27corrigé calculé
I = {4, 8, 1, 4, 2, 1}, B = 10. Combien de boîtes sont nécessaires ?
Voir la correction
Somme = 20, donc au moins ⌈20/10⌉ = 2 boîtes.
{8, 2} et {4, 4, 1, 1} : 2 boîtes, c'est l'optimum puisqu'on atteint la borne.
Ex. 1.2slide 28corrigé calculé
I = {9, 8, 2, 2, 5, 4}, B = 10. Combien de boîtes sont nécessaires ?
Voir la correction
Somme = 30, donc au moins 3 boîtes. Mais la borne n'est pas atteignable : le 9 laisse 1 place et aucun objet ne fait 1, il reste donc seul. Les autres objets totalisent 21 > 20, donc il leur faut 3 boîtes.
{9}, {8, 2}, {5, 4}, {2} : 4 boîtes, c'est l'optimum.
Ex. 1.3slide 28corrigé calculé
I = {2, 5, 4, 7, 1, 3, 8}, B = 10. Combien de boîtes sont nécessaires ?
Voir la correction
Somme = 30, donc au moins 3 boîtes. {8, 2}, {7, 3}, {5, 4, 1} : 3 boîtes, c'est l'optimum.
Ex. 1.4slide 32corrigé calculé
I = {5, 7, 3, 4, 8}, B = 10. Applique FF.
Voir la correction
L'optimum vaut 3 : {7, 3}, {5, 4}, {8}. FF n'est donc pas optimal ici.
Ex. 1.5slide 34corrigé calculé
I = {5, 7, 3, 4, 8}, B = 10. Applique BF.
Voir la correction
3 boîtes, c'est l'optimum. BF met le 3 dans la boîte la plus remplie (celle du 7), ce qui laisse la place du 4 à côté du 5.
Ex. 1.6slide 35corrigé calculé
I = {5, 7, 2, 4, 3, 8}, B = 10. Applique FF puis BF.
Voir la correction
FF
BF
Les deux donnent 4 boîtes, alors que la borne vaut ⌈29/10⌉ = 3.
Ex. 1.7slide 37corrigé calculé
I = {5, 7, 2, 4, 3, 8}, B = 10. Applique FFD.
Voir la correction
On trie d'abord : 8, 7, 5, 4, 3, 2.
3 boîtes, c'est l'optimum (la borne vaut 3). L'ordre d'arrivée pénalisait FF et BF, trier d'abord corrige le problème ici.
② Set cover : allumer le moins d'antennes possible
Le problème (slide 49). On a un univers U d'éléments et des sous-ensembles S
i de coût 1. On veut le
minimum de sous-ensembles qui couvrent tout U. Ici, U = les utilisateurs, S
i = les utilisateurs à portée de l'antenne i.
Algorithme glouton (slide 51) : à chaque étape, on prend l'ensemble qui contient le plus d'éléments encore non couverts. Il n'est pas toujours optimal (voir Ex. 2.3). Réflexe pour l'optimum : un élément présent dans un seul ensemble force cet ensemble.
Ex. 2.1slide 50, Ex1corrigé calculé
Résous le minimum set cover : U = {1, 2, 3, 4, 5, 6}, S1 = {1}, S2 = {5, 6}, S3 = {3, 4, 5}, S4 = {2, 6}, S5 = {1, 3}.
Voir la correction
4 n'est que dans S3, donc S3 est obligatoire. 2 n'est que dans S4, donc S4 est obligatoire.
S3 ∪ S4 = {2, 3, 4, 5, 6}, il manque 1. On ajoute S1 ou S5.
Optimum = 3 ensembles : {S3, S4, S1} ou {S3, S4, S5}.
Ex. 2.2slide 52, Ex2corrigé calculé
Applique le glouton : U = {1, …, 6}, S1 = {2, 3, 5}, S2 = {1, 3}, S2' = {2, 3, 6}, S3 = {1, 4}, S4 = {5, 6}. (La slide écrit « S2 » deux fois, je renomme le second S2'.)
Voir la correction
| Étape | Choix | Nouveaux couverts | Reste |
|---|
| 1 | S1 (3 éléments, à égalité avec S2') | 2, 3, 5 | 1, 4, 6 |
| 2 | S3 | 1, 4 | 6 |
| 3 | S2' ou S4 | 6 | — |
3 ensembles, c'est l'optimum : 4 force S3, et aucun ensemble seul ne couvre {2, 3, 5, 6}.
Ex. 2.3slide 52, Ex2corrigé calculépiège
Applique le glouton : U = {1, …, 6}, S1 = {3, 4}, S2 = {1, 3, 5}, S3 = {5, 6}, S4 = {1, 2}. Est-ce optimal ?
Voir la correction
| Étape | Choix | Nouveaux couverts | Reste |
|---|
| 1 | S2 (3 éléments) | 1, 3, 5 | 2, 4, 6 |
| 2 | S1 | 4 | 2, 6 |
| 3 | S3 | 6 | 2 |
| 4 | S4 | 2 | — |
Le glouton donne 4 ensembles. Or {S1, S3, S4} couvre tout : l'optimum vaut 3. C'est le contre-exemple à retenir : le glouton n'est pas optimal, sa garantie est le ratio H(s).
Ex. 2.4slide 53, Ex3corrigé calculé
Applique le glouton. Une personne qui touche un disque peut utiliser l'antenne de ce disque.
Lecture de la figure : T1 = {P1}, T2 = {P1, P2}, T3 = {P2}, B1 = {P1, P3}, B2 = {P2, P3, P4}.
Voir la correction
① B2 couvre le plus de monde (P2, P3, P4). ② Il reste P1, que T1, T2 ou B1 couvrent : on en prend une, par exemple B1.
2 antennes, c'est l'optimum : P4 force B2, et B2 ne couvre pas P1. C'est aussi la solution montrée slide 47 sur la même configuration.
Ex. 2.5slide 54, Ex4corrigé calculé
Applique le glouton, même règle.
Lecture de la figure : T1 = {P1, P2}, T2 = {P2, P3, P4, P5}, T3 = {P5}, B1 = {P2, P3, P4}, B2 = {P4, P5, P6}. P2 ne touche B1 que de justesse, mais cela ne change pas le résultat.
Voir la correction
① T2 couvre 4 personnes. ② Il reste P1 et P6 : T1 couvre P1, B2 couvre P6, on les prend.
3 antennes, c'est l'optimum : P1 force T1, P6 force B2, et il reste P3 à couvrir.
Ex. 2.6slide 73, exercice supplémentairecorrigé calculé
Trouve le minimum d'antennes, puis applique le glouton.
Lecture de la figure : A = {1, 2, 4, 5}, B = {2, 3, 4}, C = {1, 6}, D = {4, 5, 6, 7}.
Voir la correction
Optimum : 3 n'est que dans B, 7 n'est que dans D, donc B et D sont obligatoires. Ils couvrent {2, 3, 4, 5, 6, 7}, il manque 1 : on ajoute A ou C. 3 antennes.
Glouton : A et D sont à égalité avec 4 personnes. Avec A : il reste {3, 6, 7}, D en couvre 2, puis B couvre 3. Résultat {A, D, B}, soit 3 antennes : optimal ici.
③ Energy Aware Routing : router avec le moins d'équipements
Le problème (slide 58). On doit router toutes les demandes en
minimisant le nombre de routeurs et de liens actifs, sans dépasser la capacité des liens. Une demande utilise 1 unité de capacité sur chaque lien traversé. Les extrémités d'une demande restent allumées.
LL-SP (slide 63)
L = tous les nœuds
tant que L n'est pas vide :
lln = nœud le moins chargé de L
essayer d'éteindre lln, router toutes les demandes par plus courts chemins
si le routage est impossible : rallumer lln, revenir au routage précédent
retirer lln de L
Ex. 3.1slides 58–61corrigé du cours
Capacité des liens = 2. Demandes : A–D, F–C, A–E. Donne le routage par plus courts chemins, puis un routage energy-aware.
Voir la correction
Plus courts chemins (slide 59) : A-B-G-D, F-E-I-C, A-C-I-E. Seul H est éteint.
Energy-aware (slide 61) : A-C-H-D, F-D-H-C, A-C-I-E. B et G sont éteints. Les liens A–C, C–H et H–D portent 2 demandes : ils sont pleins, mais ça passe. J'ai vérifié qu'on ne peut pas éteindre plus de 2 routeurs.
Ex. 3.2slide 64corrigé calculé
Même instance. Applique LL-SP en partant du routage par plus courts chemins de la slide.
Voir la correction
Départ : A-B-G-D, F-E-I-C, A-C-I-E. Charge = nombre de demandes qui traversent le nœud : H = 0 · B, D, F, G = 1 · A, C, E, I = 2.
| Essai | Conséquence | Décision |
|---|
| H (charge 0) | Aucune demande ne passe par H, le routage ne change pas | éteint |
| B (charge 1) | A–D doit passer par A-C-I-E-F-D, et le lien C–I porterait 3 demandes > 2 | rallumé |
| G (charge 1) | Même blocage | rallumé |
| A, C, D, E, F | Extrémités de demandes | rallumés |
| I (charge 2) | A–E et F–C devraient passer par C–H ou D–H avec H éteint : impossible | rallumé |
Résultat : 1 seul routeur éteint (H), alors que l'optimum en éteint 2 (B et G). LL-SP est une heuristique. Éteindre le moins chargé d'abord peut bloquer la meilleure solution.
Le résultat dépend du départage : F–C a deux plus courts chemins de même longueur. En prenant F-D-H-C au départ, LL-SP trouve l'optimum.
Ex. 3.3slide 74, exercice supplémentairecorrigé calculé
Même réseau, capacité des liens = 3. Demandes : A–D, C–F, C–D. Applique LL-SP.
Voir la correction
Plus courts chemins de la slide : A-B-G-D, C-I-E-F, C-H-D. Tous les routeurs sont allumés.
| Essai | Conséquence | Décision |
|---|
| B (charge 1) | A–D passe par A-C-H-D | éteint |
| G (charge 0) | Plus rien ne passe par G | éteint |
| E (charge 1) | C–F passe par C-H-D-F. C–H et H–D portent 3 = la capacité | éteint |
| I (charge 0) | Plus rien ne passe par I | éteint |
| A, C, D, F, H | Extrémités de demandes, et H est le seul passage restant | rallumés |
B, G, E et I sont éteints, et c'est l'optimum (vérifié) : routage A-C-H-D, C-H-D-F, C-H-D. Ici LL-SP réussit.
④ Questions des labs
Les réponses viennent des guides de solution publiés sur Moodle. corrigé du cours
Lab 1Profiling
Qu'est-ce qu'un call graph ? Quelles fonctions optimiser dans best_offer.py, et comment ? Qui est le plus rapide entre Java et Rust, et pourquoi ne reconnaît-on plus nos fonctions dans la trace Rust ?
Voir la correction
- Call graph : la chaîne des appels de fonctions. Par défaut, perf enregistre le temps d'exécution d'une fonction, mais pas qui l'appelle.
- 1re fonction :
sorth(), un tri naïf en O(n²). On appelle le tri intégré de Python : results.sort(key=lambda x: x["score"], reverse=True). - 2e fonction :
calc_svc_score(). rsvc.lower().strip() s'exécute len(reqservcs) × len(availservcs) fois au lieu de len(reqservcs) fois : on le sort de la boucle interne. - Changement d'architecture : remplacer les listes par une table de hachage (dictionnaire Python).
- Java ≈ 1,6 s bat Python, Rust ≈ 700 ms bat Java. Le compilateur Rust optimise en inlinant et en renommant les fonctions (mangling), on ne les reconnaît donc plus.
Lab AIÉnergie des LLM
Quel est le prix des tokens de Gemini 3 Flash ? Quelle différence énergétique entre tokens d'entrée et de sortie ? Donne un cas « entrée courte, sortie longue » et un cas « entrée longue, sortie courte ».
Voir la correction
- Prix : 0,5 $ par million de tokens d'entrée, 3 $ par million de tokens de sortie.
- Entrée = prefill, tâche limitée par le calcul, très gourmande. Sortie = decode, limitée par la mémoire, un token à la fois. Les tokens de raisonnement comptent comme tokens de sortie.
- À durée égale, le decode consomme moins que le prefill. Mais il y a souvent bien plus de tokens de sortie, donc l'énergie est estimée à partir du nombre de tokens de sortie.
- Entrée courte, sortie longue : résolution de problème (un énoncé de maths, une solution détaillée).
- Entrée longue, sortie courte : code (beaucoup de contexte, juste le contenu d'une fonction à compléter).
Lab 3CodeCarbon
Même programme en France et en Allemagne : qu'observe-t-on sur l'énergie, puis sur les émissions ? Le mode en ligne donne-t-il plus ou moins d'émissions que le mode hors ligne ? Pourquoi l'intensité carbone monte-t-elle le 6 janvier 2026 ?
Voir la correction
- Énergie similaire : elle dépend du matériel, pas du pays.
- Émissions plus fortes en Allemagne : en France, l'énergie est surtout décarbonée grâce au nucléaire.
- Mode en ligne : l'intensité instantanée est en général plus basse, donc les émissions aussi, sauf événement extrême.
- 6 janvier 2026 : l'un des jours les plus froids et neigeux. Le nucléaire ne suffit plus, la part fossile augmente légèrement, avec un effet visible sur l'intensité carbone.
⑤ D'autres instances, en libre
Bin packing : instances au hasard et déroulé pas à pas
Set cover : instances au hasard, glouton et optimum
Clique sur les ensembles pour construire ta couverture. Les éléments couverts passent au vert.
Par cœur, puis appliquer
Toutes les formules
Les formules marquées ★ sont à connaître par cœur. Les autres servent surtout à savoir les lire et les appliquer si on te les donne. Ce tri est le mien, le cours n'indique pas ce qui sera exigé.
Carbone d'un logiciel
SCI★ par cœur
SCI = C / R = (O + M) / R
C = émissions totales · R = unité de service rendu (requête, utilisateur…). Résultat en gCO2eq par unité R : une intensité, pas un total.
Émissions opérationnelles★ par cœur
O = E × I
E = énergie consommée (kWh) · I = intensité carbone de la région (gCO2eq/kWh).
Émissions de fabrication imputées★ par cœur
M = TE × (TiR / EL) × (RR / ToR)
TE = émissions totales de fabrication du matériel · TiR = temps réservé · EL = durée de vie attendue · RR = ressources réservées · ToR = ressources totales.
SCI étendu★ par cœur
tSCI = (tO + tM) / R tO = O + Oidle tM = M + Midle
Oidle et Midle = part du matériel inactif imputée au job au prorata.
SCI opérationnel★ par cœur
oSCI = O / R
Ignore toute la fabrication.
Indicateurs d'un datacenter
PUE★ par cœur
PUE = énergie totale du site / énergie des équipements IT
≥ 1. Plus c'est proche de 1, plus l'infrastructure est efficace. Ne dit rien de l'utilisation réelle des serveurs.
WUE★ par cœur
WUE = eau utilisée sur le site / énergie IT
En litres par kWh.
ERE★ par cœur
ERE = (énergie totale − énergie réutilisée) / énergie IT
Récompense la chaleur réutilisée.
Puissance du matériel
Modèles de puissance CPU (CloudSim)★ par cœur
P(u) = Pidle + (Pmax − Pidle) · f(u) f(u) = u, u², u³ ou √u
u = taux d'utilisation entre 0 et 1. Linéaire, carré, cubique, racine carrée.
Puissance d'un circuit CMOS★ par cœur
P = C · V² · f
C = capacité · V = tension · f = fréquence. Baisser V et f réduit la puissance, au prix de la performance : c'est le principe du DVFS.
Algorithmes verts
Borne inférieure du bin packing★ par cœur
OPT ≥ ⌈ Σ s(i) / B ⌉
s(i) = taille de l'objet i · B = capacité d'une boîte. Remarque personnelle, pas écrite sur les slides.
Garanties du bin packing★ par cœur
FF ≤ 1,7·OPT BF ≤ 1,7·OPT FFD ≤ 11/9·OPT + 6/9
Aucune approximation absolue en dessous de 3/2 sauf si P = NP. Les slides omettent le symbole ≤ et écrivent « = » pour FFD.
Garantie du glouton (set cover)★ par cœur
H(s) = Σk=1..s 1/k ≤ ln s + 1
s = taille de l'ensemble à couvrir. La couverture trouvée peut être jusqu'à H(s) fois plus grande que l'optimale.
Énergie d'une requête LLM
Impact d'une requête (EcoLogits)à savoir appliquer
Ireq = Ereq · CI + (ΔT / ΔL) · Isvre
1er terme = usage : énergie × intensité carbone (CI). 2e terme = fabrication du serveur (Isvre) au prorata de la latence ΔT sur la durée de vie ΔL.
Énergie GPU★ par cœur
EGPU = #Tout × fE(Pactive, B)
#Tout = nombre de tokens de sortie · fE = énergie par token.
Énergie par tokenà savoir appliquer
fE = α · eβ·B · Pactive + γ
Pactive = paramètres actifs (en milliards) · B = taille du batch · α = 1,17·10⁻⁶ · β = −1,12·10⁻² · γ = 4,05·10⁻⁵. La slide annonce des joules par token, mais la courbe EcoLogits juste après est en Wh par token (γ ≈ 40 µWh) : j'utilise les Wh. Constantes inutiles à apprendre.
Énergie du serveur hors GPUà savoir appliquer
Esvr\GPU = ΔT × Wsvr\GPU × (GPU / #GPUinstallés) × 1/B
ΔT = latence d'inférence · W = 1,2 kW · 8 GPU installés · GPU = GPU utilisés.
Latence d'inférenceà savoir appliquer
ΔT = min( TTFT + #Tout / TPS , ΔTreq )
TTFT = temps jusqu'au premier token · TPS = tokens par seconde · ΔTreq = latence de la requête.
Mémoire pour héberger le modèleà savoir appliquer
Mmodel = 1,2 × Ptotal × Q / 8
Ptotal = nombre de paramètres · Q = précision en bits (Q/8 = octets) · 1,2 = surcoût d'hébergement.
Nombre de GPUà savoir appliquer
GPU = 2⌈ log(Mmodel / MGPU) / log 2 ⌉
La puissance de 2 suffisante. MGPU = mémoire d'un GPU.
Énergie totale du serveur★ par cœur
Esvr = Esvr\GPU + GPU × EGPU
Énergie d'une requête (ML.ENERGY)à savoir appliquer
Ereq = (Esteady / Tkssteady) × (1/N) Σ Tksreq,i
Énergie par token en régime établi × nombre moyen de tokens par requête.
Formules des labs
Coût d'une requête Gemini 3 Flash★ par cœur
coût = (#entrée × 0,5 + (#sortie + #raisonnement) × 3) / 10⁶ $
Prix du Lab AI. Sortie facturée = candidates_token_count + thoughts_token_count.
Score du Lab 3★ par cœur
score = 0,1 / ( Emoy × (1 + Σ |doptimale − dtrouvée|) )
Emoy = énergie moyenne en Wh · d = distance d'édition entre deux mots.
IA frugale
Précision selon le temps de calcul★ par cœur
aj(tj) = (amax − amin) (1 − e−θj tj)
tj = temps de traitement (niveau de compression) · θj = pente à l'origine. Courbe concave : c'est ce qui rend la sobriété intéressante.
Coût d'une cascade★ par cœur
Coût = Σétapes i Probi × Coûti
Probi = probabilité d'atteindre l'étape i.
Perte d'un early-exit (entraînement joint)★ par cœur
Ltotal = Σi=1..N wi · LCE(ŷi, y)
wi = poids de la sortie i · LCE = entropie croisée entre la prédiction de la sortie i et le vrai label y.
Temperature scaling★ par cœur
p̂i = softmax(zi / T)
zi = logits · T = un scalaire ajusté sur un jeu de validation, poids du modèle figés.
ECE★ par cœur
ECE = Σb=1..B (|Sb| / N) · |acc(Sb) − conf(Sb)|
Sb = prédictions du groupe de confiance b · acc = précision réelle · conf = confiance moyenne.
Speculative decoding : acceptation★ par cœur
accepté avec la probabilité min(1, p(x) / q(x)) sinon tirage dans p'(x) = norm(max(0, p(x) − q(x)))
p = grand modèle cible · q = petit modèle brouillon.
Speculative decoding : proximité★ par cœur
α = Σx min(p(x), q(x))
α = probabilité qu'un token du brouillon soit accepté.
Speculative decoding : gain★ par cœur
E[tokens par passe] = (1 − αγ+1) / (1 − α) gain = (1 − αγ+1) / ((1 − α)(γc + 1))
γ = nombre de tokens proposés · c = temps d'une passe de q / temps d'une passe de p.
Attention (KV cache)à savoir appliquer
Attention = softmax(Q Kᵀ / √dk) V
Q, K, V = matrices requêtes, clés et valeurs. Le KV cache évite de recalculer K et V à chaque token.
Entraînement d'un réseauà savoir appliquer
minw (1/n) Σi L(Rw(xi), yi)
w = poids · Rw = le réseau · L = la perte.
Appliquer : calculs à vérifier
Saisis ta réponse, puis clique sur « vérifier » (tolérance de 1 %). Les nombres sont des exemples, sauf ceux des slides 31 et 32.
App. 3Sunk carbon (slide 32)
S_A : M = 0,11 et O = 0,83. S_B : M = 0,45 et O = 0,56. Les deux serveurs existent déjà. Calcule le SCI de chacun, puis le tSCI de S_B, qui ajoute le M du serveur resté inactif (S_A).
Voir le calcul
SCI_A = 0,11 + 0,83 = 0,94. SCI_B = 0,45 + 0,56 = 1,01 : le SCI choisit S_A. tSCI_B = 1,01 + 0,11 = 1,12 et tSCI_A = 0,94 + 0,45 = 1,39 : le tSCI choisit S_B, comme le bilan réel du cluster.
App. 6DVFS
On baisse la tension et la fréquence de 20 %. Par quel facteur la puissance est-elle multipliée ?
Voir le calcul
P = C·V²·f. Facteur = 0,8² × 0,8 = 0,512, soit −48,8 %.
App. 7EcoLogits : énergie GPU
Pactive = 70 (milliards), B = 100, #Tout = 500. Calcule fE en µWh par token, puis EGPU en Wh.
Voir le calcul
e−1,12 ≈ 0,326. fE = 1,17·10⁻⁶ × 0,326 × 70 + 4,05·10⁻⁵ ≈ 6,72·10⁻⁵ Wh. EGPU = 500 × 6,72·10⁻⁵ ≈ 0,0336 Wh.
App. 8EcoLogits : mémoire et serveur
Modèle de 7 milliards de paramètres en Q = 16 bits, GPU de 16 Go. Calcule Mmodel et le nombre de GPU. Puis, avec TTFT = 0,5 s, 500 tokens à 50 tokens/s, ΔTreq = 60 s et B = 1, calcule ΔT et Esvr\GPU en Wh.
Voir le calcul
M = 1,2 × 7·10⁹ × 16/8 = 16,8 Go. 16,8/16 = 1,05, donc ⌈log₂ 1,05⌉ = 1 et 2¹ = 2 GPU. ΔT = min(0,5 + 500/50, 60) = 10,5 s. E = (10,5/3600) h × 1200 W × (2/8) × 1 = 0,875 Wh.
App. 10Coût d'une cascade
Coûts 1, 10 et 100. 90 % des entrées sortent à l'étape 1, puis 70 % des restantes à l'étape 2. Calcule le coût moyen. (Exemple inventé.)
Voir le calcul
Toutes les entrées paient l'étape 1. 10 % atteignent l'étape 2, 3 % l'étape 3. Coût = 1 + 0,1 × 10 + 0,03 × 100 = 5.
App. 11ECE et température
10 prédictions : 6 de confiance moyenne 0,9 avec une précision réelle de 0,7, et 4 de confiance moyenne 0,6 avec une précision réelle de 0,5. Calcule l'ECE. Puis, pour des logits z = (2, 0), calcule la plus grande probabilité avec T = 2.
Voir le calcul
ECE = 0,6 × |0,7 − 0,9| + 0,4 × |0,5 − 0,6| = 0,12 + 0,04 = 0,16. z/T = (1, 0) : p̂ = e / (e + 1) ≈ 0,731. Avec T = 1, on aurait 0,881 : la température réduit la sur-confiance.
App. 12Speculative decoding
p = (0,5 ; 0,3 ; 0,2) et q = (0,4 ; 0,4 ; 0,2). Calcule α, puis la probabilité d'accepter le 2e token. Ensuite, avec α = 0,75, γ = 7 et c = 0,05, calcule le nombre de tokens par passe et le gain.
Voir le calcul
α = 0,4 + 0,3 + 0,2 = 0,9. Acceptation = min(1, 0,3/0,4) = 0,75. Tokens = (1 − 0,75⁸)/0,25 ≈ 3,60. Gain = 3,60 / (7 × 0,05 + 1) ≈ 2,67.