Pourquoi les CPU chauffent : turbo, limites de puissance et réalité

décembre 22, 2025 • février 3, 2026 • Lecture : 31 min • Views: 0

Cet article vous a aidé ?

Vous avez acheté « un CPU 125W » et il consomme 230W, frôle les 100 °C, et vos outils de supervision ont l’impression que la salle est en feu. Pendant ce temps, la charge est « juste » un travail de compilation, un vacuum de base de données, ou un nœud Kubernetes qui devait être sans histoire.

Ce n’est pas un mystère. C’est le contrat moderne : le CPU sprinte jusqu’à atteindre une limite—température, puissance, courant ou durée—puis il négocie avec la physique en temps réel. Votre rôle, en tant que personne qui exploite des systèmes et qui ne doit pas mettre l’entreprise dans l’embarras, est de rendre ces limites explicites, observables et alignées avec la réalité.

Les CPU chauffent volontairement

Les CPU modernes ne « s’emballent » pas. Ils font exactement ce pour quoi ils ont été conçus : transformer une marge thermique et électrique en performance, puis ralentir dès qu’ils atteignent une contrainte. C’est tout l’intérêt du comportement turbo chez Intel et AMD, sur bureau comme sur serveur, portable ou station de travail.

Les anciens modèles mentaux—« le CPU utilise sa puissance nominale », « la température est un signe de panne », « la fréquence est fixe »—sont aujourd’hui coûteux en exploitation. Ils créent le pire type d’incident : le lent, plausible. Le service ne tombe pas ; il devient juste plus lent, plus bruyant et plus difficile à diagnostiquer parce qu’il oscille avec la température ambiante, la poussière, les courbes de ventilateur et les décisions de l’ordonnanceur.

Si vous exploitez en production, cessez de traiter la température CPU comme un simple voyant rouge/jaune/vert. La température est une variable de commande pour le boost. Un CPU à 95 °C peut être sain et rapide ; un CPU à 70 °C peut être en mauvais état et se faire throttler à cause de limites de puissance ou de courant. La question intéressante n’est pas « quelle est la température », mais «quelle limite est active, et est-ce la limite que nous avons voulue ?»

Faits intéressants et contexte historique (à utiliser en réunion)

Le TDP est passé d’une spécification d’ingénierie à un raccourci marketing. Le « thermal design power » initial servait à dimensionner le refroidissement dans des conditions de base, pas à indiquer « la puissance max que la puce tirera ».
Intel Turbo Boost (généralisé autour de 2008) a rendu la puissance du CPU dynamique. La fréquence est devenue une fonction de la marge disponible, pas une propriété statique du SKU.
Les instructions AVX ont changé la donne. Les calculs vectoriels lourds peuvent faire monter la densité de puissance et déclencher des règles de turbo ou des offsets différents par rapport au code scalaire.
L’ère Zen d’AMD a normalisé « la température comme objectif ». Beaucoup de Ryzen pousseront volontiers jusqu’à une limite thermique pendant le boost parce que la boucle de contrôle est conçue ainsi.
Les centres de données ont poussé les concepteurs vers des pics de courte durée. La performance en rafale vend bien sur les benchs ; la performance soutenue devient votre problème sauf si vous fixez des limites.
Les nœuds de processus ont réduit la taille, mais la densité de puissance n’a pas disparu. Des transistors plus petits signifient parfois plus de chaleur par millimètre carré, pas moins.
Les serveurs étaient autrefois « axés sur le flux d’air ». Des ventilateurs à haute pression statique et du guidage d’air étaient la norme ; les boîtiers grand public priorisent silence et esthétique.
La gestion d’énergie par le firmware est devenue centrale pour le comportement de la plateforme. Le CPU n’est pas seul—les limites VRM de la carte mère et les paramètres BIOS peuvent beaucoup changer la façon dont un « 125W » se comporte.

Une citation que les opérateurs devraient coller sur leur écran (idée paraphrasée) : « L’espoir n’est pas une stratégie. » — idée souvent attribuée au leadership militaire ; en SRE : mesurez, sinon vous devinez.

Blague n°1 : Un CPU à 100 °C ne « panique » pas, il « maximise la valeur pour les actionnaires ». Malheureusement, vous êtes la valeur pour les actionnaires.

Turbo, PL1/PL2/Tau et le piège du « TDP »

Commencez par la vérité inconfortable : l’étiquette « 125W » n’est généralement pas une promesse sur la consommation réelle. C’est un point de conception. La puissance réelle du package peut la dépasser—parfois de façon spectaculaire—selon les défauts du firmware, les caractéristiques de la charge et le refroidissement. Si le système peut le refroidir et l’alimenter, le CPU saisira l’opportunité.

La boucle de contrôle basique : la performance suit les limites

Les CPU modernes choisissent continuellement fréquence et tension en fonction de :

Limite de température (TjMax, typiquement autour de 95–105 °C selon le modèle)
Limites de puissance (Intel : PL1/PL2 avec une fenêtre temporelle Tau ; AMD : PPT/TDC/EDC et règles PBO)
Limites de courant électrique (capacité du VRM, contraintes d’alimentation du socket)
Garde-fous de fiabilité (modèles de vieillissement du silicium, capteurs de points chauds)
Classification de la charge (AVX, largeur vectorielle, occupation des cœurs, rafales transitoires)

Votre CPU est essentiellement son propre SRE : il tente d’atteindre un SLO (« aller vite ») tout en respectant un budget d’erreurs (« ne pas fondre »). Quand vous voyez « il monte à 5,6 GHz puis redescend », ce n’est pas un défaut ; c’est la politique qui fonctionne.

Vocabulaire Intel : PL1, PL2, Tau

Sur de nombreuses plateformes Intel :

PL1 : limite de puissance à long terme. Pensez « budget en régime permanent ».
PL2 : limite de puissance turbo à court terme. Pensez « rafale ». Souvent bien plus haute que PL1.
Tau : la fenêtre temporelle (en secondes) pendant laquelle PL2 est autorisé avant de revenir vers PL1.

En pratique, beaucoup de cartes sont livrées avec des valeurs permissives : PL2 élevé et Tau long, ou effectivement « illimité » dans une certaine mesure. C’est pourquoi vous pouvez voir un CPU « 125W » à 200W indéfiniment—parce que le fabricant de la carte mère a décidé que vendre des chiffres de bench importait plus que respecter une enveloppe thermique conservative.

Vocabulaire AMD : PPT, TDC, EDC et PBO

Le comportement de boost d’AMD s’articule souvent autour de :

PPT : package power tracking (plafond de puissance total du socket)
TDC : limite de courant soutenue
EDC : limite de courant à court terme
PBO : Precision Boost Overdrive (règles pour assouplir les limites si le thermique et les VRM le permettent)

AMD a tendance à traiter la température comme un objectif : il montera les fréquences jusqu’à approcher une cible thermique (ou atteindre des plafonds de puissance/courant). C’est pourquoi « il va toujours à 95 °C » n’est pas automatiquement « mauvais », surtout sur de petits refroidisseurs ou des boîtiers compacts. La question est : obtenez-vous une performance stable et prévisible, ou le système oscille-t-il et se fait-il throttler sous charge soutenue ?

Le piège du TDP en termes d’exploitation

Le TDP est utile pour un concepteur matériel qui doit dimensionner un refroidisseur dans des conditions de base. En exploitation, « TDP » est un mensonge que vous vous racontez pour arrêter de réfléchir. Ne basez pas vos plans de capacité dessus.

Planifiez plutôt autour de la puissance soutenue du package sous votre charge réelle, avec vos paramètres BIOS réels, dans votre châssis réel, à votre température ambiante réelle, et avec votre niveau de poussière réel six mois plus tard. Ce n’est pas romantique, mais c’est comme ça que vous éviterez les appels le week-end.

Objectifs de température et pourquoi 95–100 °C est « normal »

Il y a deux conversations différentes que les gens mélangent :

Le silicium est-il en sécurité ? Généralement oui, jusqu’à la température maximale de jonction spécifiée (TjMax). Le CPU se throttlera pour se protéger.
Le système a-t-il un comportement prévisible ? C’est là que vous pouvez perdre de l’argent. Le throttling, le bruit des ventilateurs et la dérive de fréquence peuvent transformer un nœud prévisible en un nœud chaotique.

Les fournisseurs n’ont pas choisi 95–100 °C pour le plaisir. Ils l’ont choisi parce que cette marge thermique permet d’envoyer des fréquences boost plus élevées dans une enveloppe puissance/aire fixe, et parce que les capteurs internes et les boucles de contrôle sont assez bonnes pour fonctionner près de la limite en toute sécurité.

Throttling thermique vs throttling de puissance vs throttling de courant

« Throttle » est un terme fourre-tout. Il faut différencier :

Throttling thermique : la température atteint la limite ; la fréquence baisse pour réduire la chaleur.
Throttling par limite de puissance : la puissance du package atteint PL1/PL2/PPT ; la fréquence chute même si les températures sont acceptables.
Throttling courant/VRM : des limites de la plateforme, la température du VRM ou des plafonds de courant forcent le downclocking.

Chacun demande une solution différente. Refaire la pâte thermique ne réglera pas une limite de puissance. Augmenter les limites de puissance ne réglera pas un radiateur mal monté. Et augmenter les limites pour « améliorer la performance » peut discrètement déstabiliser des racks si vos PDU et votre flux d’air ne sont pas dimensionnés.

Réalité du refroidissement : contact, flux d’air et physique du boîtier

La température CPU dans un tableau de bord est le dernier maillon d’une chaîne. La chaîne commence au die, passe par le heatspreader, la pâte thermique, la base du refroidisseur, les ailettes, l’air du boîtier, l’air de la salle, et enfin votre budget HVAC.

Quand vous diagnostiquez des CPU chauds, supposez d’abord les défaillances physiques ennuyeuses. La moitié du temps ce n’est pas le firmware ; c’est la mécanique.

Les coupables les plus fréquents en vrai

Mauvaise pression de contact ou montage inégal. Le capteur de point chaud du CPU rapporte la vérité : un coin cuit.
Problèmes de pâte thermique. Trop, trop peu, sèche, ou expulsée après cycles thermiques.
Recirculation d’air. Le refroidisseur réutilise son propre flux d’échappement parce que l’agencement du boîtier est décoratif, pas aérodynamique.
Courbes de ventilateur optimisées pour le « silence ». Le silence est agréable. Le silence sous charge soutenue est aussi la façon d’acheter du throttling.
Négligence des filtres et de la poussière. La perte de charge augmente, le flux d’air diminue, les températures grimpent, puis un jour tout franchit un seuil en même temps.
Dérive de la température ambiante. Les hypothèses de « couloir froid » du datacenter échouent quand des panneaux d’obturation manquent ou qu’un CRAC est en panne.

Blague n°2 : « On réparera ça avec un plus gros refroidisseur » est la version hardware de « ajoutez des retries ». Ça marche jusqu’au jour où ça ne marche plus du tout.

Méthode de diagnostic rapide

Vous voulez une réponse rapide à deux questions : quelle limite est active, et est-ce que cette limite est attendue. Voici la séquence qui vous y mène sans sacrifices rituels.

Première étape : confirmer que le symptôme est réel (pas un artefact de capteur/télémétrie)

Vérifiez la température et la fréquence du CPU sous une charge connue.
Recoupez avec au moins deux outils (capteurs noyau + outil fournisseur ou outil basé sur MSR).
Vérifiez que la charge est bien celle que vous pensez (un fil chaud vs tous les cœurs).

Deuxième étape : identifier la limite active

Cherchez des drapeaux de throttling thermique et des chutes de fréquence corrélées à un plafond de température.
Vérifiez la puissance du package et les limites de puissance (PL1/PL2/Tau ou PPT/TDC/EDC).
Vérifiez les limites de courant/VRM et les capteurs thermiques de la plateforme (VRM, température d’entrée).

Troisième étape : décider s’il faut réparer le refroidissement, la politique de puissance, ou la charge

Si limitation thermique : améliorez le contact, le flux d’air, la courbe des ventilateurs, ou réduisez la tension/la puissance.
Si limitation de puissance : décidez si vous voulez une performance soutenue (augmenter PL1/PPT) ou des thermiques prévisibles (baisser PL2/Tau ou limiter la fréquence).
Si déclenchée par la charge : identifiez les chemins de code AVX lourds, les limites CPU des conteneurs, l’affectation des threads et les voisins bruyants.

Cet ordre a de l’importance. Les gens aiment commencer par le BIOS parce que ça donne l’impression de maîtriser. Commencez par l’observation, puis la politique. Le hardware se moque de vos sentiments.

Tâches pratiques (commandes, sorties, ce que ça signifie, ce que vous décidez)

Conçues pour les serveurs et stations de travail Linux. Certaines requièrent des paquets (comme lm-sensors, linux-tools), mais les commandes sont réalistes et courantes dans les runbooks de production.

Tâche 1 : Voir le comportement actuel de la fréquence CPU (est-ce qu’il booste, est-ce bloqué ?)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core|Socket|MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU(s):                               32
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            1
CPU MHz:                              1198.523

Ce que ça signifie : La ligne « CPU MHz » est un instantané et peut être trompeuse sur les systèmes modernes. Toutefois, si elle ne monte jamais sous charge, vous pouvez être limité par un governor bas ou une limite d’alimentation.

Décision : Si la fréquence semble basse, passez à la surveillance en direct par cœur (Tâche 2) et vérifiez le governor (Tâche 3).

Tâche 2 : Surveiller la fréquence par cœur, la température et les indicateurs de throttling (Intel)

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz   TSC_MHz  PkgTmp  PkgWatt
       -        4123   92.15      4473      2500      98   212.34
     IRQ        1020

Ce que ça signifie : Un Busy% élevé et un PkgTmp élevé proche du plafond avec un PkgWatt important suggèrent que le CPU utilise la puissance turbo. Si PkgTmp atteint 100 et que Bzy_MHz chute, vous êtes probablement en throttling thermique.

Décision : Si PkgTmp est proche du maximum, vérifiez les indicateurs de throttling thermique (Tâche 4) et le chemin de refroidissement. Si PkgWatt est élevé, confirmez PL1/PL2 (Tâche 5).

Tâche 3 : Confirmer le governor d’échelle de fréquence (êtes-vous accidentellement en « powersave » ?)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Ce que ça signifie : performance demande des fréquences plus élevées. powersave ou une politique plateforme peut vous caper.

Décision : Si ce n’est pas performance (ou la politique voulue), changez-le via les outils de votre distro ou les profils tuned. Si c’est correct, cherchez des limites de puissance/thermiques à la place.

Tâche 4 : Vérifier les compteurs de throttling thermique du noyau (MSR Intel exposés via sysfs sur certaines plateformes)

cr0x@server:~$ grep . /sys/devices/system/cpu/cpu*/thermal_throttle/* 2>/dev/null | head
/sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count:3
/sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count:8

Ce que ça signifie : Si ces compteurs augmentent pendant la charge, le CPU se throttle activement pour cause de température.

Décision : Si les compteurs de throttling montent, traitez cela comme un problème de refroidissement ou de politique de puissance, pas comme un mystère « le CPU est lent ». Améliorez le refroidissement ou réduisez la puissance (Tâches 11–12).

Tâche 5 : Lire les limites de puissance Intel RAPL (PL1/PL2) si disponibles

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
125000000
cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw
225000000

Ce que ça signifie : La contrainte 0 est communément la limite soutenue (voisine de PL1) et la contrainte 1 la limite courte (PL2). Ici : 125W soutenus, 225W en turbo.

Décision : Si PL2 est énorme et que les thermiques posent problème, baissez PL2 ou raccourcissez Tau (BIOS ou outils plateforme). Si la performance est trop basse, vous devrez peut‑être augmenter PL1—mais seulement si votre refroidissement et votre distribution d’alimentation peuvent le supporter.

Tâche 6 : Vérifier les capteurs de température CPU (générique)

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +97.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +95.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +96.0°C  (high = +90.0°C, crit = +100.0°C)

Ce que ça signifie : Vous vivez près de la limite critique. Cela peut être attendu lors de tests de stress, mais si c’est sous une charge normale de service, vous dépensez votre budget de performance en chaleur.

Décision : Corrélez températures, fréquence et puissance (Tâches 2 et 5). Si les températures sont élevées à puissance modeste, suspectez un problème de montage/flux d’air.

Tâche 7 : Confirmer la charge et si elle est mono‑fil ou multi‑fil

cr0x@server:~$ top -b -n1 | head -15
top - 12:20:18 up 41 days,  3:10,  1 user,  load average: 23.41, 18.92, 12.10
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s): 92.7 us,  2.1 sy,  0.0 ni,  4.8 id,  0.2 wa,  0.0 hi,  0.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8421 build     20   0 2451280 512404  23344 R  3200  3.1  18:01.22 clang

Ce que ça signifie : Un processus consommant ~3200% CPU sur un système à 32 threads suggère un fort parallélisme. Cela change le comportement de boost : le turbo pour tous les cœurs est inférieur au turbo 1–2 cœurs, et la puissance du package augmente rapidement.

Décision : Si c’est « normal », fixez des objectifs de puissance/refroidissement soutenus réalistes. Si c’est inattendu, trouvez pourquoi le job s’exécute (CI mal déclenchée, pool de threads en fuite, chevauchement de cron).

Tâche 8 : Vérifier si vous êtes bloqué en I/O (la chaleur est imputée au CPU, mais la limitation est ailleurs)

cr0x@server:~$ iostat -xz 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.20    0.00    4.10   42.30    0.00   18.40

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  svctm  %util
nvme0n1         220.0   180.0  50240   38912     390.4      8.12   18.21   1.05  42.00

Ce que ça signifie : Un iowait élevé signifie que les cycles CPU ne sont pas le facteur limitant ; le système attend le stockage. Les CPU chauds peuvent encore apparaître (rafales turbo en arrière-plan), mais « le CPU est chaud donc le CPU est le problème » est souvent faux.

Décision : Si l’iowait est élevé, corrigez la latence/le queueing du stockage d’abord. Sinon vous réglerez des limites CPU pour masquer un problème I/O et manquerez toujours votre SLO.

Tâche 9 : Vérifier les limites CPU des conteneurs ou le throttling Kubernetes (on dirait du throttling thermique, mais ce sont des cgroups)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
200000 100000

Ce que ça signifie : Cet exemple est un quota de 200 ms de temps CPU par période de 100 ms, soit effectivement 2 CPU. Si votre charge attend 8 cœurs, elle sera « throttlée » indépendamment de la température.

Décision : Si des quotas existent, alignez demandes/limites de ressources avec les attentes. Ne poursuivez pas des fantômes de refroidissement.

Tâche 10 : Détecter indirectement un comportement AVX via des pics de puissance et des chutes de fréquence

cr0x@server:~$ sudo perf stat -a --timeout 5000 2>&1 | head -12
 Performance counter stats for 'system wide':

       120,345,882,112      cycles
        65,112,004,331      instructions              #    0.54  insn per cycle
             2,114,220      context-switches
                12,804      cpu-migrations

Ce que ça signifie : Un IPC faible sous calcul intensif peut corréler avec du code vectoriel, des stalls mémoire, ou du throttling. Perf n’indiquera pas « AVX » ici, mais couplé à turbostat montrant des watts élevés et des fréquences plus basses, l’AVX est un coupable habituel.

Décision : Si cela se corrèle avec des charges prévisibles (compression, crypto, inférence ML), envisagez des politiques de fréquence AVX, des plafonds de puissance, ou déplacez cette charge vers des nœuds dimensionnés pour cela.

Tâche 11 : Vérifier la vitesse des ventilateurs et la santé du flux d’air (serveurs avec IPMI)

cr0x@server:~$ sudo ipmitool sdr type Fan
FAN1             | 8600 RPM        | ok
FAN2             |  900 RPM        | cr
FAN3             | 8700 RPM        | ok

Ce que ça signifie : Un ventilateur est dans un état critique et tourne à peine. Votre CPU va chauffer, et pire, le système peut avoir un flux d’air inégal provoquant des points chauds.

Décision : Remplacez le ventilateur, vérifiez les politiques de contrôle des ventilateurs, confirmez qu’aucun câble ne gêne. Ne « résolvez » pas ça en baissant les limites CPU sauf comme mesure temporaire.

Tâche 12 : Valider la température d’entrée/ambiante (votre « refroidissement » peut être une défaillance de la salle)

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'Inlet|Ambient|Temp' | head
Inlet Temp       | 29 degrees C     | ok
Ambient Temp     | 30 degrees C     | ok
CPU1 Temp        | 96 degrees C     | ok

Ce que ça signifie : Une entrée de 29–30 °C n’est pas catastrophique, mais elle réduit votre marge thermique. Si vos CPU étaient à 80 °C et qu’ils passent à 96 °C avec la même charge, regardez la salle et le confinement d’air.

Décision : Si l’entrée est élevée, traitez cela comme un problème de facilities/flux d’air. Baisser le turbo peut être une garde‑fou temporaire, pas la solution réelle.

Tâche 13 : Détecter les raisons de throttling sur des nœuds GPU NVIDIA (les plaintes CPU arrivent souvent sur des nœuds mixtes)

cr0x@server:~$ nvidia-smi -q | egrep -i 'Power Limit|Clocks Throttle Reasons' -A5
    Power Limit                      : 300.00 W
    Clocks Throttle Reasons
        Idle                         : Not Active
        Applications Clocks Setting   : Not Active
        SW Power Cap                 : Active
        HW Thermal Slowdown          : Not Active

Ce que ça signifie : Si le GPU est limité en puissance, votre charge peut se reporter sur le CPU, augmentant la puissance et la chaleur CPU de façon inattendue. Les nœuds mixtes sont pleins d’effets de second ordre.

Décision : Coordonnez les budgets CPU/GPU. Évitez de « réparer le CPU » isolément quand le plafonnement au niveau du nœud est la vraie politique.

Tâche 14 : Repérer une mauvaise configuration BIOS via dmesg (zones thermiques, disponibilité RAPL, indices microcode)

cr0x@server:~$ dmesg | egrep -i 'microcode|rapl|thermal|throttl' | tail -10
microcode: updated early to revision 0x2f, date = 2023-08-10
intel_rapl_common: Found RAPL domain package
thermal thermal_zone0: failed to read out thermal zone (-61)

Ce que ça signifie : Si les zones thermiques échouent à se lire, votre OS peut manquer de capteurs ou les tables ACPI peuvent être bizarres. Vous pourriez être aveugle ou partiellement aveugle aux raisons du throttling.

Décision : Rétablissez la visibilité d’abord (mise à jour firmware, paramètres noyau, bons pilotes). Ne touchez pas à ce que vous ne pouvez pas observer.

Trois micro-histoires du monde de l’entreprise

Micro‑histoire 1 : L’incident causé par une fausse hypothèse

Une entreprise a déployé une série de « runners de build haute performance » pour le CI. La fiche d’achat indiquait des CPU 125W. L’équipe facilities a budgété la puissance et le refroidissement du rack en conséquence. Tout le monde se sentait responsable. Tout le monde s’était trompé dans la même direction, et c’est ainsi que naissent les incidents.

Le premier jour, tout allait bien. Les builds étaient plus rapides, les développeurs contents, et les runners semblaient stables. Puis une release produit est arrivée et le volume CI a doublé. La flotte de runners est passée de « rafales » à « soutenue sur tous les cœurs ». La puissance du package a grimpé bien au‑dessus de 125W sur la plupart des nœuds, les ventilateurs hurlaient, puis le cluster a commencé à se comporter comme s’il y avait un réseau capricieux.

Le réseau n’était pas capricieux. Les CPU étaient fortement en throttling thermique, et les nœuds oscillaient : boost → chauffe → throttle → refroidissement → boost. Les latences ont augmenté aux mauvais endroits : uploads d’artefacts, récupérations de cache, même les sessions SSH pour diagnostiquer le problème. Les humains ont interprété les symptômes comme « le réseau est saturé » parce que c’est ce que la lenteur donne comme impression.

Ils ont fini par tracer fréquence vs température vs puissance du package et ont vu le motif en dents de scie. La vraie correction était ennuyeuse : définir des limites de puissance soutenue raisonnables (réduire les défauts « turbo infini »), ajuster les courbes de ventilateur, et ajouter deux panneaux d’obturation qui manquaient depuis l’installation. La performance a légèrement baissé au pic, mais les builds ont fini plus vite globalement parce qu’ils ont cessé de thrash.

La fausse hypothèse n’était pas « les CPU chauffent ». C’était « le TDP est le maximum ». Une fois cette hypothèse retirée, le système est redevenu prévisible—comme il aurait dû l’être dès le départ.

Micro‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre équipe a fait tourner des services sensibles à la latence sur des nœuds généralistes. Ils voulaient une performance consistante et ont décidé de « forcer le mode performance » sur la flotte : governor sur performance, turbo maximal autorisé, et P‑states agressifs. Sur le papier, c’était correct. Moins de transitions de fréquence, moins de pics de latence tail. Simple.

Pendant une semaine, les métriques ont été meilleures. Puis l’été est arrivé et l’entrée d’air du datacenter a augmenté de quelques degrés. Rien de dramatique. Toujours « dans les specs ». Mais les nœuds avaient désormais moins de marge thermique. La fréquence élevée en permanence maintenait la puissance moyenne du package plus haute même à charge modérée. Les courbes de ventilateur réagissaient en retard. Les températures CPU restaient proches de la limite toute la journée.

Le retour de bâton était subtil : pas d’arrêts thermiques, mais des micro‑throttlings sous trafic de pointe. Le service ne plantait pas ; il est devenu imprévisible. L’autoscaling s’est déclenché plus souvent, ce qui a augmenté la charge du cluster, ce qui a augmenté encore les températures. Une jolie boucle de rétroaction : pas catastrophique, juste coûteuse et agaçante.

La correction n’était pas « désactiver le turbo ». C’était une politique : capping de la puissance soutenue à ce que le châssis pouvait évacuer à la pire température d’entrée, puis laisser le turbo exister dans cette garde‑fou. Ils ont aussi scindé la flotte : certains nœuds réglés pour la latence, d’autres pour le débit. Le « mode performance » universel était la vraie erreur.

Une optimisation qui ignore la variance de l’environnement n’est pas une optimisation. C’est un incident bien intentionné.

Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe stockage exploitait un cluster de nœuds de base de données avec de fortes compactions et chiffrement. Ils avaient déjà été brûlés, alors ils standardisaient une check‑list de mise en service : vérifier la visibilité des capteurs, vérifier les limites de puissance, vérifier le contrôle des ventilateurs, puis lancer un test de charge soutenue en capturant fréquence, température et puissance du package.

Pendant un rafraîchissement matériel de routine, un nouveau lot de nœuds montrait de meilleurs benchs chez le fournisseur. Tout le monde s’attendait à un gain. La check‑list de l’équipe a détecté autre chose : lors d’un run de stress de 30 minutes, la puissance du package restait élevée bien au‑delà de la fenêtre turbo attendue et les températures flottaient près du plafond thermique.

Les nœuds n’étaient pas encore en panne, mais ils vivaient sur le fil. L’équipe a comparé les profils BIOS et trouvé le coupable : un preset « performance » qui supprimait effectivement la limite de puissance soutenue voulue. C’était probablement correct pour un banc de test en air libre avec un technicien à côté. Dans un rack, c’était un problème en mode ralenti.

Ils sont revenus à leur politique BIOS de base, ont revalidé, et ont expédié les nœuds. Deux semaines plus tard, une unité de refroidissement sur une rangée a eu un problème ; les températures d’entrée ont monté. Ces nœuds sont restés stables tandis que des hôtes « réglages par défaut » d’une équipe voisine ont commencé à throttler. Aucun rapport d’incident. Juste une journée tranquille, ce qui est le plus grand compliment qu’on puisse faire à la production.

La validation ennuyeuse et reproductible bat toujours le tuning héroïque. À chaque fois.

Erreurs courantes : symptôme → cause racine → correctif

Ce sont les schémas qui apparaissent dans les canaux d’incident réels : affirmations confiantes, mauvais diagnostics, résolution lente.

1) Symptom : le CPU atteint 100 °C instantanément sous charge

Cause racine : Problème de contact du refroidisseur (pression de montage, entretoise manquante, film protecteur encore en place, pâte sèche).

Correctif : Reposer le refroidisseur, réappliquer la pâte correctement, vérifier le couple de serrage uniforme. Retester avec une charge soutenue en surveillant la vitesse de montée en température ; un passage instantané à la limite est un indicateur physique rouge.

2) Symptom : la température est correcte (70–80 °C) mais la performance est basse et les fréquences sont plafonnées

Cause racine : Throttling par limite de puissance (PL1/PPT bas) ou quota cgroup CPU.

Correctif : Vérifiez RAPL/limites BIOS et quotas cgroup. Augmentez les limites soutenues uniquement si le refroidissement et le budget d’alimentation du nœud le permettent.

3) Symptom : la performance oscille toutes les 10–60 secondes

Cause racine : Comportement de fenêtre Tau ou hystérésis des courbes de ventilateur provoquant des cycles boost/throttle ; possible cyclage thermique du VRM.

Correctif : Ajustez PL2/Tau et les courbes de ventilateur pour la stabilité. Envisagez un pic légèrement inférieur pour éliminer l’oscillation et améliorer le débit.

4) Symptom : un nœud chauffe plus que des nœuds identiques

Cause racine : Variance mécanique (pâte, montage), défaillance d’un ventilateur, flux d’air obstrué, ou dérive du profil BIOS.

Correctif : Comparez les paramètres BIOS, RPM des ventilateurs et relevés de capteurs côte à côte. Échangez les ventilateurs, vérifiez le guidage d’air, puis reposez le refroidisseur si nécessaire.

5) Symptom : après une mise à jour microcode/BIOS, les CPU chauffent davantage

Cause racine : Le firmware a modifié la politique de boost ou les limites de puissance. Parfois des « correctifs de sécurité » altèrent indirectement performance/power.

Correctif : Revalidez PL1/PL2/PPT après les changements firmware. Gardez une capture de référence de turbostat/sensors sous une charge fixe pour comparaison.

6) Symptom : seules certaines charges surchauffent (compression, crypto, ML), d’autres non

Cause racine : Chemin de code vectoriel/AVX augmentant la densité de puissance ; aussi possible utilisation de tous les cœurs à haute charge.

Correctif : Envisagez l’affectation de la charge (nœuds dédiés), ajustez les plafonds de puissance, ou acceptez un turbo all‑core inférieur. Ne dimensionnez pas le refroidissement sur « le comportement moyen d’une application ».

7) Symptom : la rangée du datacenter est « dans les specs » mais le throttling augmente les après‑midi chauds

Cause racine : La température d’entrée réduit la marge ; problèmes de confinement ; panneaux d’obturation manquants ; recirculation.

Correctif : Réparez la gestion du flux d’air et l’hygiène du rack. Utilisez les capteurs de température d’entrée comme télémétrie de première classe et alertez sur la dérive, pas seulement sur des seuils absolus.

Listes de contrôle / plan pas à pas

Plan pas à pas : rendre les thermiques CPU prévisibles (pas forcément plus froids)

Définissez votre objectif. Ce nœud est‑il réglé pour le débit, la latence ou l’acoustique ? Choisissez un objectif principal ; les autres sont des contraintes.
Capturez une référence sous une charge soutenue. Enregistrez puissance du package, température, fréquence et compteurs de throttling.
Vérifiez la visibilité et la justesse des capteurs. Si les capteurs manquent ou sont cassés, arrêtez et réparez cela d’abord.
Identifiez le type de throttling. Thermique vs puissance vs cgroups. Diagnostiquez avant de tourner des boutons.
Définissez une politique de puissance soutenue. Choisissez PL1/PPT que votre refroidissement peut tenir au pire cas d’ambiante.
Définissez délibérément le comportement de rafale. PL2/Tau doit refléter la rafale de vos charges. Les builds CI et compactions ne sont pas « rafales ».
Validez la santé du flux d’air. RPM ventilateurs, filtres, guidage, panneaux d’obturation et gestion des câbles.
Re‑testez la même charge. Cherchez la stabilité : pas de fréquence en dents de scie, pas de montée progressive des températures.
Déployez avec des garde‑fous. Alertez sur les compteurs de throttling, pas seulement sur la température. La température seule raconte une histoire incomplète.
Re‑validez après chaque changement. Mises à jour BIOS, upgrades noyau et déplacements de châssis changent tous le comportement.

Checklist opérationnelle : sur quoi alerter

Augmentation des compteurs de throttling thermique (par cœur et package) pendant les fenêtres de charge normales.
Fréquence soutenue inférieure à l’all‑core attendu à forte utilisation.
Dérive de la température d’entrée par rapport à la référence normale pour ce rack/rangée.
Anomalies ventilateurs : un ventilateur à bas RPM, ventilateur en état « cr », ou PWM ventilateur constamment au max.
Anomalies de puissance du package : nœuds consommant beaucoup plus que leurs pairs sous charge similaire.

FAQ

1) 95–100 °C est‑ce sûr pour mon CPU ?

Généralement oui si c’est dans le TjMax spécifié et si le CPU se comporte normalement (pas de crash, pas d’explosion de WHEA, pas d’arrêt). Sûr ne veut pas dire optimal. Si vous êtes en throttling, vous payez pour de la performance que vous n’obtenez pas.

2) Pourquoi mon CPU « 125W » tire 200W ?

Parce que le TDP n’est pas la « consommation max », et parce que les limites firmware (PL2 et Tau, ou politiques PBO) peuvent autoriser un turbo soutenu bien au‑dessus du chiffre marketing. Beaucoup de cartes mères sont livrées avec des paramètres agressifs.

3) Dois‑je désactiver le turbo pour corriger la chaleur ?

En dernier recours ou comme mitigation temporaire, oui. Mais désactiver le turbo est une arme lourde. Préférez définir des limites soutenues raisonnables (PL1/PPT) et une limite de rafale raisonnable (PL2/Tau). Vous obtenez souvent un meilleur débit total en empêchant l’oscillation.

4) Pourquoi une mise à jour BIOS a‑t‑elle changé mes températures ?

Les mises à jour BIOS peuvent changer le microcode, les tables de boost, les valeurs par défaut des limites de puissance, la logique de contrôle des ventilateurs et l’étalonnage des capteurs. Traitez les mises à jour firmware comme des changements de performance : capturez une référence avant, validez après.

5) Mon CPU est frais mais la performance est mauvaise. Pourquoi ?

Causes courantes : throttling par limite de puissance, quota cgroup, contention de bande passante mémoire, ou iowait. La température n’est pas un indicateur universel de goulot d’étranglement. Vérifiez les limites de puissance et l’iowait avant de refaire la pâte thermique.

6) Une meilleure pâte thermique compte‑t‑elle dans les serveurs ?

La qualité de la pâte compte moins que son application correcte et la pression de montage correcte. Une pâte milieu de gamme bien appliquée vaut mieux qu’une pâte exotique mal appliquée. Aussi : la pâte vieillit et se dégrade avec les cycles thermiques ; planifiez la maintenance pour les hôtes de longue durée.

7) Les AIO (liquides) sont‑ils la solution ?

Parfois. Ils peuvent déplacer la chaleur vers un plus grand radiateur et réduire la température des points chauds. Ils ajoutent aussi des pompes, des risques de fuite et un mode de défaillance plus difficile à détecter que « ventilateur arrêté ». Dans les flottes de production, la simplicité l’emporte souvent sauf si vous avez une forte maturité opérationnelle autour du refroidissement liquide.

8) Pourquoi la température CPU grimpe instantanément puis se stabilise ?

Les capteurs de point chaud réagissent vite, et les boosts turbo peuvent appliquer tension et fréquence élevées immédiatement. Un pic rapide qui se stabilise peut être normal. Un pic qui atteint la limite thermique et déclenche le throttling de façon répétée suggère un contact de refroidisseur défaillant ou un turbo trop agressif.

9) Quel est le meilleur indicateur unique pour alerter ?

Si vous ne pouvez en choisir qu’un, alertez sur les événements de throttling thermique (augmentation des compteurs) pendant les charges habituelles. C’est plus proche de « la performance est refusée » que la température brute.

10) L’undervolting peut‑il aider ?

Oui, il peut réduire la puissance et la chaleur pour une même performance, mais c’est de plus en plus contraint sur de nombreuses plateformes et cela introduit un risque de stabilité si c’est fait agressivement. En production, préférez des limites de puissance supportées par le fournisseur et des profils BIOS validés plutôt que des aventures d’undervolt par nœud.

Conclusion : prochaines étapes pratiques

Les CPU chauffent parce que le contrat moderne est simple : utiliser chaque watt et chaque degré disponible pour aller plus vite, jusqu’à ce qu’une limite dise « stop ». Si vous ne choisissez pas les limites, votre fabricant de carte mère, les défauts du firmware et les conditions ambiantes les choisiront pour vous. Ce n’est pas de la gouvernance ; c’est du hasard.

Étapes concrètes à réaliser cette semaine :

Baseliner un nœud représentatif sous charge soutenue avec turbostat et sensors ; capturez fréquence, température et puissance du package ensemble.
Décidez votre objectif de puissance soutenue (PL1/PPT) en fonction de ce que votre châssis et votre salle peuvent refroidir à la pire température d’entrée.
Définissez le comportement de rafale intentionnellement (PL2/Tau ou politique PBO) pour éviter le throttling en dents de scie.
Alertez sur les compteurs de throttling, anomalies de ventilateurs et dérive de température d’entrée—pas seulement « température CPU > 90 °C ».
Documentez le profil BIOS comme politique de production. Traitez‑le comme de la configuration, parce que c’en est.

Vous n’avez pas besoin de CPU plus froids. Vous avez besoin de CPU prévisibles. La prévisibilité, c’est ce qui vous permet de dormir.