Les chiffres TDP des CPU portables sont souvent des contes de fées

Le TDP n’est ni un thermomètre, ni un wattmètre

Le TDP (Thermal Design Power) ressemble à une mesure. Il a l’air d’une mesure. Les gens le citent comme une mesure. Sur les portables, ce n’est souvent pas une mesure de la puissance que vous verrez à la prise, à la batterie, ni même au niveau du package CPU sous votre charge de travail.

En pratique, le « TDP » d’un portable est généralement une étiquette pour l’enveloppe thermique prévue du processeur dans certaines conditions définies qui peuvent ne pas correspondre à vos conditions, au refroidissement de votre portable ou aux choix du firmware du fabricant. Le CPU dispose d’un modèle interne de puissance et de température, le firmware fixe des limites et l’OS demande de la performance. La seule chose que garantit « TDP », c’est qu’une réunion a eu lieu à ce sujet.

Ce que le TDP est censé représenter

Historiquement, le TDP était utilisé par les concepteurs système pour dimensionner le refroidissement : dissipateurs, ventilateurs, ouvertures et flux d’air du châssis. L’objectif n’était pas la « puissance max », mais la « chaleur à évacuer lors d’une charge soutenue qui intéresse le fabricant ». Cette différence subtile compte : charge soutenue, définie, règles définies par le fabricant.

Ce que les acheteurs de portables pensent que cela représente

• Une promesse de performance soutenue.
• Une promesse de puissance maximale absorbée.
• Un indicateur de « ce CPU est plus rapide que cet autre CPU ».
• Une garantie que deux portables avec le même CPU auront des performances similaires.

Un seul de ces points est occasionnellement vrai, et encore, seulement par accident.

Ce que devient souvent le TDP dans les portables

Il devient un argument marketing pour segmenter une famille de CPU : « la série U est efficace », « la série H est rapide », « HX est proche du desktop ». Ensuite, les OEM fixent leurs propres limites soutenues et de pic pour s’adapter au châssis, à la batterie, aux objectifs de nuisance sonore et au positionnement produit. La puce peut être capable de pics à 60–90W, mais le portable peut n’autoriser cela que pendant 10 secondes, 28 secondes, ou « jusqu’à ce que l’utilisateur ouvre Slack ».

Blague n°1 : Le TDP des portables est comme une prévision météo : techniquement dérivé de modèles, mais pas quelque chose sur lequel vous devriez parier votre trajet quotidien.

Comment on en est arrivé là : la lente dérive du TDP vers le marketing

Les CPU mobiles n’ont pas commencé à tromper du jour au lendemain. L’industrie a évolué vers des processeurs qui peuvent dépasser régulièrement leur « enveloppe de base », et vers des OEM qui optimisent agressivement la finesse et l’autonomie. Le problème est que la fiche technique n’a pas évolué en quelque chose d’utile pour les consommateurs.

Faits intéressants et contexte historique (court et concret)

1. Le Turbo boost a rendu la « puissance de base » politiquement gênante. Dès que les CPU ont commencé à monter la fréquence de façon opportuniste, la « puissance typique » a cessé d’être stable.
2. Le modèle de limites de puissance d’Intel (PL1/PL2/Tau) a normalisé les pics. La puissance soutenue et la puissance court terme sont devenues des réglages distincts, pas un seul nombre.
3. Les pièces mobiles ont poussé l’intégration. GPUs intégrés et contrôleurs mémoire signifient que la puissance du package CPU n’est pas « seulement des cœurs », donc le mix de charges varie fortement.
4. Le design fin et léger est devenu un argument majeur. Beaucoup de portables sont conçus d’abord pour le bruit et l’épaisseur, puis les limites de puissance sont définies après coup.
5. La segmentation produit par les OEM est réelle. Deux modèles avec le même CPU peuvent être intentionnellement réglés pour des puissances soutenues différentes afin de préserver une grille tarifaire.
6. Batterie et contraintes VRM comptent. Un portable peut ne pas pouvoir fournir beaucoup de puissance depuis la batterie sans chute de tension, chaleur ou problèmes d’usure à long terme.
7. La température de surface et le confort utilisateur sont des contraintes. « Ne brûlez pas l’utilisateur » est une limite de conception ; elle prime souvent sur « atteindre le score du benchmark ».
8. Les bascules Windows « Meilleure performance » ont changé les attentes des utilisateurs. Les profils d’énergie de l’OS peuvent modifier le comportement PL1/PL2 sans l’expliquer clairement.
9. Les limites au niveau plateforme (adaptateur AC, USB-C PD) sont devenues des goulots courants. Un adaptateur USB-C de 65W peut plafonner un CPU « 45W » une fois que le reste du système prend sa part.

Voici la partie inconfortable : le fournisseur de CPU peut publier un nombre, mais votre portable est un traité négocié entre firmware, thermiques et une volonté commerciale de ne pas cannibaliser le modèle « Pro ».

Les vrais réglages : PL1, PL2, Tau, cTDP, et alliés

Si vous voulez la réalité, ignorez le TDP et apprenez la couche de contrôle. Les noms diffèrent selon les fournisseurs, mais la structure est similaire : une limite de puissance soutenue, une limite de boost court terme, et des contraintes thermiques qui annulent tout quand le refroidissement est saturé.

PL1 : le budget de puissance soutenue

PL1 est souvent la puissance « long terme ». Le portable peut tourner à ce niveau indéfiniment si le refroidissement le permet. Les OEM définissent fréquemment PL1 en dessous de la « classe TDP » annoncée du CPU, car ils conçoivent pour l’acoustique, l’autonomie ou la température de surface du châssis.

Dans le monde réel : PL1 est le nombre qui gouverne votre compilation de 10 minutes, votre rendu long, votre simulation soutenue et vos plaintes du type « pourquoi l’ordinateur est-il plus lent après la première minute ? »

PL2 : le budget de boost court terme

PL2 est la limite de « rafale ». C’est ce qui rend les portables réactifs à l’ouverture d’apps, à l’export d’un petit fichier ou à un benchmark court. PL2 est aussi la raison pour laquelle les reviewers obtiennent de jolis graphiques avec des runs courts.

PL2 peut être 2–3× PL1 sur certains designs. Ce n’est pas de la triche. C’est le but. Le mensonge survient quand le marketing laisse entendre que le comportement en rafale est le comportement soutenu.

Tau : la fenêtre temporelle (la partie que tout le monde oublie)

Tau est en pratique « combien de temps pouvons-nous faire semblant d’être sur un desktop ? » Il définit combien de temps PL2 peut être utilisé avant de retomber vers PL1. Certains portables sont livrés avec un Tau long pour être compétitifs sur les benchmarks. D’autres le gardent court pour éviter l’accumulation de chaleur et les pics de bruit.

cTDP / plages de puissance configurables

Beaucoup de CPU mobiles supportent des plages configurables : 12–15W, 15–28W, 35–45W, etc. Cette plage ne signifie pas que vous obtenez « un CPU à 28W ». Cela signifie que le CPU peut fonctionner dans différentes enveloppes selon le réglage OEM.

Si vous voyez le même CPU dans différents portables avec des performances très différentes, c’est la raison dans neuf cas sur dix.

Throttling thermique vs limitation de puissance

Les gens attribuent « le throttling thermique » à tout, mais la limitation de puissance est souvent le premier frein. Le CPU peut ne jamais atteindre sa température maximale ; il peut simplement être maintenu sur un PL1 bas parce que l’OEM veut une courbe de ventilateur silencieuse.

Cette distinction compte, car la correction diffère :

• Limitée en puissance : changez la politique de puissance (si possible), les réglages firmware, ou acceptez le choix produit.
• Limitée thermiquement : améliorez le refroidissement (nettoyage, changement de pâte thermique, alignement des pads, courbe de ventilateur), réduisez l’ambiance ou réduisez la charge.

Vue d’un responsable fiabilité sur la gestion de la puissance

Dans les systèmes de production, on suppose qu’il y a une boucle de contrôle. Dans les portables, vous en avez plusieurs : DVFS CPU, logique ventilateur du contrôleur embarqué, plans d’énergie OS, et parfois des démons constructeurs qui se battent entre eux. Vous ne « fixez » pas un TDP. Vous gérez un système de contraintes.

Une citation opérationnelle s’impose. Voici une idée paraphrasée de Werner Vogels (CTO d’Amazon) : paraphrased idea: Everything fails, and you should design and operate as if failure is normal.

Les limites de puissance ne sont pas une défaillance, mais il faut les traiter comme un mode normal à observer et planifier.

L’ordinateur portable est le produit (le CPU n’est qu’un passager)

Deux portables peuvent partager le même modèle de CPU et pourtant se comporter comme des espèces différentes. Parce que le CPU n’est pas le système. Le système, c’est : capacité de refroidissement, masse du dissipateur, qualité de la chambre à vapeur, design des ventilateurs, géométrie d’entrée/sortie d’air, réglages firmware, conception VRM, wattage de l’adaptateur, et si l’OEM a discrètement plafonné les performances sur batterie.

Refroidissement : l’état stable prime sur les pics

La performance du refroidissement concerne l’évacuation de chaleur en régime permanent. Un portable fin peut absorber un pic (masse thermique), mais ne peut pas le soutenir sans flux d’air et surface de ailettes. Quand les reviewers lancent une boucle de benchmark courte, la première passe est la lune de miel. La dixième passe, c’est le mariage.

Alimentation et limites de l’adaptateur

Un « CPU 45W » dans un système avec un adaptateur USB-C PD 65W est déjà en négociation avec le GPU, l’écran, le SSD et la charge. Sous charge, le système peut :

• réduire la puissance CPU pour continuer la charge,
• arrêter la charge et maintenir la performance, ou
• vidanger la batterie tout en étant branché (oui, vraiment).

Le mode batterie est un univers à part

Beaucoup de portables plafonnent fortement la puissance CPU sur batterie pour préserver la durée de vie des cycles et éviter les chutes de tension. Si vous faites un vrai travail sur batterie, vous devez mesurer les performances sur batterie. Sinon vous évaluez une machine différente de celle que vous utilisez.

Logiciels constructeur et « modes IA de puissance »

Les utilitaires constructeurs peuvent outrepasser les politiques OS, brider PL1 quand le « mode silencieux » est activé, ou même changer les limites selon l’application active. Parfois ils fonctionnent bien. Parfois ils le font pour atteindre une certification acoustique. Dans tous les cas, vous devez savoir qui est aux commandes.

Blague n°2 : La courbe des ventilateurs du portable a été conçue par quelqu’un qui pense que « silencieux » signifie « laisser souffrir le CPU en silence ».

Modes de défaillance que vous pouvez réellement diagnostiquer

Quand un portable sous-performe, vous voulez une courte liste de causes plausibles. Voici l’ensemble que j’utilise, car il se mappe proprement à des mesures.

1) Pic court, puis effondrement

Schéma : rapide pendant 10–60 secondes, puis les fréquences chutent et ne se rétablissent pas.

Cause probable : PL2 autorisé, mais PL1 est bas, ou le refroidissement est saturé et impose un état soutenu bas.

Décision : si vous avez besoin de performance soutenue, choisissez un châssis plus épais ou un modèle connu pour une puissance soutenue plus élevée, pas une classe TDP annoncée supérieure.

2) Toujours lent, même au démarrage

Schéma : ne monte jamais beaucoup en fréquence.

Cause probable : OS en économiseur d’énergie, « mode silencieux » constructeur, plafonnement sur batterie, adaptateur de faible puissance, ou capteur thermique / ventilateur bloqué.

Décision : validez d’abord la source d’alimentation et le plan d’énergie ; ne chassez les problèmes thermiques qu’après.

3) Performance très variable d’un jour à l’autre

Schéma : parfois excellent, parfois terrible, sans changement de charge.

Cause probable : logiciels en arrière-plan, tâches de mise à jour Windows, service d’alimentation constructeur basculant les modes, accumulation de poussière, température ambiante ou installation de dock/charge instable.

Décision : établissez une mesure reproductible : même source d’alimentation, même mode, même charge, même ambiance.

4) Branché mais toujours fortement limité

Schéma : « mode AC » mais puissance limitée comme sur batterie.

Cause probable : adaptateur non reconnu, négociation USB-C PD à une puissance inférieure, câble endommagé, ou bug firmware forçant la politique batterie.

Décision : confirmez la puissance négociée et si la batterie se charge sous charge.

5) Le CPU n’est pas le goulot

Schéma : les fréquences sont correctes, mais les tâches restent lentes.

Cause probable : pression mémoire, limites I/O stockage, chiffrement de disque en arrière-plan, ou throttling thermique du SSD.

Décision : prouvez la saturation CPU avant de blâmer le « mensonge du TDP ».

Guide de diagnostic rapide

Quand quelqu’un dit « ce portable est lent », ne commencez pas par repaster. Ne commencez pas par acheter un pad de refroidissement. Ne lancez pas une suite de benchmarks d’une heure. Vous voulez un triage de 10 minutes qui isole le limiteur dominant.

Première étape : confirmer la source d’alimentation et la politique

• La machine est-elle sur batterie, sur secteur ou sur une station d’accueil ?
• Se recharge-t-elle réellement sous charge ?
• L’OS est-il dans un plan d’énergie restrictif ?
• Un logiciel constructeur force-t-il le « silence » ou l’« éco » ?

Deuxième étape : observer les limites pendant une charge soutenue

• Surveillez la puissance du package CPU dans le temps (pas seulement le pic).
• Surveillez fréquence et température ensemble.
• Cherchez des indicateurs de « limite de puissance » vs « throttling thermique ».

Troisième étape : vérifiez le reste du système pour le vrai goulot

• Pression mémoire et activité de swap.
• Débit et latence stockage sous charge.
• Utilisation GPU si la charge décharge sur le GPU.
• Tâches d’arrière-plan qui volent du temps CPU.

Quatrième étape : décider si c’est une réparation ou un mauvais produit

Si le portable se comporte exactement comme conçu (PL1 bas pour le silence), vous pouvez parfois ajuster des paramètres. Mais souvent la « réparation » consiste à choisir un portable conçu pour la puissance soutenue. C’est brutal, mais moins cher que des semaines de frustration.

Tâches pratiques : commandes, sorties et décisions

Voici des vérifications réelles et exécutables. J’utilise des exemples Linux parce qu’ils sont observables et scriptables. La méthode importe plus que l’OS.

Task 1: Identify CPU model and base characteristics

cr0x@server:~$ lscpu | sed -n '1,25p'
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Model name:                           13th Gen Intel(R) Core(TM) i7-13700H
CPU(s):                               20
Thread(s) per core:                   2
Core(s) per socket:                   14
CPU max MHz:                          5000.0000
CPU min MHz:                          400.0000

Ce que cela signifie : Confirme le CPU et la fréquence max annoncée. Cela ne vous dit rien sur la performance soutenue, mais fixe les attentes pour le comportement en boost.

Décision : Si c’est une puce « U » dans un châssis fin et que vous attendez un comportement d’atelier de travail, stoppez et réajustez vos attentes avant de poursuivre.

Task 2: Confirm which driver and governor is active (Linux)

cr0x@server:~$ cpupower frequency-info | sed -n '1,40p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  hardware limits: 400 MHz - 5.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5.00 GHz.
                  The governor "powersave" may decide which speed to use

Ce que cela signifie : Avec intel_pstate, « powersave » est souvent le mode par défaut et permet tout de même le turbo, mais il peut être influencé par EPP/energy bias.

Décision : Si vous diagnostiquez la performance, forcez temporairement « performance » pour ôter une variable.

Task 3: Temporarily switch to performance governor (diagnostic)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Ce que cela signifie : Vous demandez à l’OS de favoriser la performance. Cela n’outrepasse pas PL1/PL2 du firmware, mais cela montre ce que la plateforme peut faire.

Décision : Si la performance s’améliore beaucoup, le problème est de politique, pas de refroidissement. Ensuite, décidez si vous pouvez tolérer l’impact sur batterie/bruit.

Task 4: Watch frequency and temperature in real time

cr0x@server:~$ sudo turbostat --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt
       -       3120    92.15     3385     1896     86.0    90.0    44.72
       -       2650    99.02     2675     1896     92.0    96.0    28.11
       -       2580    99.11     2600     1896     94.0    97.0    24.95

Ce que cela signifie : Vous voyez le schéma classique : forte puissance du package initialement, puis chute (souvent vers PL1), tandis que la température approche du plafond.

Décision : Si PkgWatt chute alors que les temp. sont élevées, vous êtes soit limité thermiquement, soit le firmware impose une puissance soutenue plus basse pour éviter l’accumulation de chaleur.

Task 5: Run a sustained CPU load to expose PL1 behavior

cr0x@server:~$ stress-ng --cpu 0 --timeout 180s --metrics-brief
stress-ng: info:  [23110] dispatching hogs: 20 cpu
stress-ng: metrc: [23110] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [23110] cpu            3154210    180.00   1790.22    12.11     17523.39

Ce que cela signifie : Une charge soutenue de 3 minutes suffit souvent à faire sortir beaucoup de portables du PL2 et à atteindre les limites d’état stable.

Décision : Associez cela à turbostat. Si vous observez une baisse après 28–60 secondes, voilà votre réalité soutenue.

Task 6: Check Intel RAPL energy counters (power telemetry)

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone 0
  Name: package-0
  Enabled: yes
  Energy: 879.23 J
  Max energy range: 262143.99 J
Zone 0 subzone 0
  Name: core
  Energy: 522.17 J
Zone 0 subzone 1
  Name: uncore
  Energy: 101.55 J
Zone 0 subzone 2
  Name: dram
  Energy: 87.49 J

Ce que cela signifie : Les compteurs RAPL vous permettent d’estimer la puissance moyenne sur un intervalle en échantillonnant l’énergie avant / après.

Décision : Si l’énergie du package augmente lentement pendant une charge soutenue, votre plateforme applique un plafond de puissance bas indépendamment du « TDP ».

Task 7: Look for thermal and power limit messages in the kernel log

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|pstate|rapl|power limit' | tail -n 15
intel_rapl_common: Found RAPL domain package
thermal thermal_zone7: critical temperature reached (105 C), shutting down
intel_pstate: turbo disabled by BIOS or unavailable on processor

Ce que cela signifie : Cela révèle des événements matériels : turbo désactivé, événements thermiques critiques ou problèmes de configuration plateforme.

Décision : Si vous voyez « turbo disabled by BIOS », arrêtez de modifier l’OS. Votre limiteur est une politique firmware.

Task 8: Inspect current thermal zones and temperatures

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/type; do echo -n "$(basename $(dirname $z)) "; cat $z; done | head
thermal_zone0 x86_pkg_temp
thermal_zone1 acpitz
thermal_zone2 INT3400 Thermal

cr0x@server:~$ cat /sys/class/thermal/thermal_zone0/temp
94000

Ce que cela signifie : Les températures sont souvent en millidegrés Celsius. 94000 signifie 94°C.

Décision : Si la temp. du package est proche du point de throttling sous charge modérée, vous avez probablement un problème de refroidissement (poussière, ventilateur défaillant, pâte dégradée) ou une courbe de ventilateur extrêmement conservative.

Task 9: Check whether you’re swapping (memory pressure masquerading as CPU slowness)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        29Gi       1.1Gi       1.2Gi       2.3Gi       1.9Gi
Swap:            8Gi       6.5Gi       1.5Gi

Ce que cela signifie : Une utilisation intensive du swap peut rendre les « tâches CPU » lentes car tout dépend du stockage.

Décision : Si le swap est actif pendant des builds, des VMs ou des charges de conteneurs, votre « problème de TDP » peut en fait être « pas assez de RAM ».

Task 10: Confirm storage isn’t the bottleneck (NVMe)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (laptop) 	01/12/2026 	_x86_64_	(20 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.12    0.00    6.21   22.18    0.00   36.49

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1          92.0   8120.0     0.0    0.00   12.10    88.26    41.0   6240.0    18.33   152.20    1.22  96.00

Ce que cela signifie : Un %iowait élevé et un %util proche de saturation signifient que le disque est occupé ; le CPU peut attendre.

Décision : Si l’I/O est le goulot, augmenter les limites CPU n’aidera pas. Réparez le stockage (SSD plus rapide, éviter le throttling thermique, réduire l’amplification d’écriture) ou réduisez la charge I/O.

Task 11: Check NVMe drive temperature (SSD throttling can look like CPU throttling)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning'
temperature                             : 72 C
warning_temp_time                       : 3
critical_temp_time                      : 0

Ce que cela signifie : Un SSD à 72°C avec un temps d’avertissement suggère qu’il peut s’accélérer en throttling, surtout dans les portables fins avec un mauvais flux d’air sur le SSD.

Décision : Si le temps d’avertissement augmente pendant les builds, ajoutez un pad / dissipateur thermique ou réduisez les écritures soutenues (par exemple, déplacez le répertoire de build vers tmpfs si la RAM le permet).

Task 12: Check for cgroup CPU throttling (containers make everything confusing)

cr0x@server:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cpu.stat 2>/dev/null | head
usage_usec 928381223
user_usec  812332110
system_usec 116049113
nr_periods  22990
nr_throttled 1420
throttled_usec 91822111

Ce que cela signifie : Si nr_throttled est élevé, l’ordonnanceur bride l’usage CPU à cause des quotas cgroup, pas parce que le CPU est limité en puissance.

Décision : Corrigez les limites de conteneurs (Docker/Kubernetes CPU quota) avant de blâmer les thermiques du portable.

Task 13: Check AC adapter / battery state (on Linux via upower)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | egrep -i 'state|percentage|energy-rate|time to'
  state:               charging
  percentage:          83%
  energy-rate:         28.1 W
  time to full:        0.9 hours

Ce que cela signifie : Un état de charge positif et un taux d’énergie raisonnable indiquent que l’adaptateur fournit assez de puissance pour faire tourner le système et charger.

Décision : Si l’état passe à « discharging » sous charge alors que l’appareil est branché, votre adaptateur / dock est un limiteur. Augmentez le wattage de l’adaptateur ou évitez ce dock pour les charges lourdes.

Task 14: Verify CPU idle behavior (background load stealing your turbo budget)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:18:02 up  2:41,  1 user,  load average: 6.21, 5.90, 4.40
Tasks: 412 total,   3 running, 409 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.2 us,  6.3 sy,  0.0 ni, 63.1 id,  4.1 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  31890.8 total,   1220.4 free,  29401.1 used,   1269.3 buff/cache
MiB Swap:   8192.0 total,   1581.2 free,   6610.8 used.   1820.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 5429812 617148  82192 R  182.3   1.9   5:21.83 chrome
 8892 cr0x      20   0 2916420 501120  61444 S   78.1   1.5   2:11.20 docker

Ce que cela signifie : CPU et pression mémoire en arrière-plan peuvent empêcher les états de repos profonds et réduire la marge pour le turbo, surtout sur des systèmes thermiquement contraints.

Décision : Si « idle » n’est pas idle, éliminez les coupables en arrière-plan avant de blâmer l’enveloppe CPU.

Trois mini-histoires d’entreprise des tranchées des limites de puissance

Mini-histoire 1 : Un incident causé par une mauvaise hypothèse

Une équipe a déployé une flotte de « portables développeur standard » pour un nouveau système de build interne exécutant compilations locales, tests unitaires et builds de conteneurs. La décision d’achat reposait sur un simple critère : CPU dernière génération, « classe 45W », 32Go RAM, bon clavier. Les machines semblaient identiques sur le papier. Le service achats était ravi. Les ingénieurs… moins.

En une semaine, les temps de build ont divergé. Certains développeurs terminaient un build complet dans un délai raisonnable ; d’autres mettaient presque le double. Les machines lentes n’étaient pas cassées. Elles n’étaient pas infectées. Elles n’étaient même pas particulièrement chaudes. Elles étaient simplement coincées à une limite de puissance soutenue plus basse parce que ces unités étaient une variante de châssis plus fine avec une cible acoustique plus silencieuse.

La mauvaise hypothèse était subtile : « même modèle de CPU = même performance ». Cette hypothèse fonctionnait sur desktop. Elle échouait sur portable, car l’enveloppe soutenue du CPU est essentiellement une décision OEM. L’étiquette « 45W » ne décrivait pas ce que les portables pouvaient soutenir ; elle décrivait ce que le CPU pouvait théoriquement être configuré pour atteindre.

La correction fut ennuyeuse et coûteuse : standardiser sur un modèle de portable spécifique, pas un SKU CPU, et le qualifier par un test de charge soutenue de 10 minutes lors de l’acceptation. Ils ont aussi mis à jour le formulaire interne de demande matériel pour inclure « puissance package soutenue en charge », car c’est plus difficile à maquiller que « TDP ».

Mini-histoire 2 : Une optimisation qui s’est retournée

Un ingénieur orienté performance a décidé de « réparer » des charges CI lentes sur les portables en forçant des modes performance maximum sur toute la flotte. Le changement a été poussé comme configuration : définir le governor CPU sur performance, désactiver les économies agressives et rendre les ventilateurs plus proactifs. Les benchmarks courts se sont améliorés immédiatement, et l’ingénieur a reçu quelques messages reconnaissants.

Puis le retour de bâton est arrivé. L’usure des batteries a augmenté sensiblement en quelques mois. Des machines qui tenaient autrefois toute une journée de réunions nécessitaient une recharge en milieu de journée. Certains portables ont commencé à chauffer même au repos, parce que les tâches en arrière-plan plus le biais de performance empêchaient le CPU d’entrer dans des états basse consommation efficaces. Sur un sous-ensemble d’unités, les roulements de ventilateurs ont commencé à faire des bruits désagréables plus tôt que prévu.

La surprise majeure fut l’expérience développeur : les portables devinrent bruyants dans les open-spaces, et les gens commencèrent à activer les « modes silencieux » des constructeurs pour s’adapter. Cela réintroduisit discrètement des PL1 bas et des performances incohérentes. L’optimisation créa un système à deux vitesses : ceux qui toléraient le bruit obtenaient la vitesse, et les autres avaient de l’imprévisibilité.

La leçon : forcer le mode performance global traite un symptôme (vitesse court terme) et ignore la fonction objective du système (batterie, acoustique, thermiques, longévité). L’approche correcte était de fournir un profil « charge lourde » documenté que les ingénieurs pouvaient activer branchés, et de mesurer la performance soutenue plutôt que de poursuivre le turbo maximal.

Mini-histoire 3 : Une pratique ennuyeuse mais correcte qui sauva la situation

Une équipe plateforme maintenait une liste interne de « portables validés » pour les ingénieurs qui exécutent régulièrement des bases de données locales, VMs et compilations. La liste ne mentionnait jamais le TDP. Elle spécifiait modèles, versions BIOS, wattage adaptateur et un test d’acceptation simple : exécuter une charge CPU soutenue de 10 minutes et enregistrer la puissance package stabilisée, la fréquence et la température.

Quand un cycle de renouvellement est arrivé, le vendeur proposa un nouveau modèle séduisant : plus fin, plus léger, même génération de CPU et un badge « haute performance ». Il séduisit lors des démos courtes. L’équipe plateforme exécuta quand même le test d’acceptation, parce que c’est ce qu’elle faisait toujours.

Le nouveau modèle boostait fort, puis se stabilisait sur une puissance soutenue bien plus basse que l’ancien modèle. Ce n’était pas catastrophique ; ce n’était juste pas l’outil adapté aux ingénieurs qui vivent de compilations et de VMs. L’explication du vendeur fut prévisible : objectifs acoustiques, contraintes de châssis et courbe de ventilateur différente. Rien n’était « cassé ».

Parce que l’équipe avait institutionnalisé un test ennuyeux, elle détecta l’inadéquation avant d’émettre les bons de commande. Ils approuvèrent le modèle pour un usage bureau général, mais conservèrent la ligne plus épaisse (ou une alternative) pour les utilisateurs intensifs. Pas de drame. Pas de « pourquoi les builds sont lents » en réunion d’urgence. Juste une évitement tranquille de la douleur.

Erreurs courantes : symptôme → cause racine → solution

1) « Mon CPU est 45W mais il ne tire qu’environ 25W en charge »

Symptôme : la puissance package se stabilise bien en dessous de la classe annoncée.

Cause racine : l’OEM a fixé PL1 bas pour atteindre des objectifs de bruit/température de surface, ou la source d’alimentation (adaptateur/dock) ne fournit pas assez d’enveloppe.

Solution : validez sur l’adaptateur OEM ; vérifiez l’état de charge sous charge ; si PL1 est plafonné par le firmware, votre véritable solution est un autre modèle de portable ou un mode performance constructeur qui augmente PL1.

2) « Il est rapide pendant 30 secondes, puis lent pour toujours »

Symptôme : fréquences élevées initialement, puis palier stable bas.

Cause racine : le burst PL2 expire (fenêtre Tau), puis le CPU retombe vers PL1 ; parfois la chaleur forcée impose des limites encore plus basses.

Solution : mesurez la puissance soutenue après 3–10 minutes ; choisissez le matériel en fonction de ce palier, pas de la première passe d’un benchmark.

3) « Sur batterie, mon portable devient une autre machine »

Symptôme : chute importante de performance débranché.

Cause racine : limites de décharge batterie, firmware conservateur sur batterie ou changement de plan OS.

Solution : si vous avez besoin de performance sur batterie, achetez spécifiquement des systèmes connus pour autoriser plus de puissance sur batterie. Sinon, acceptez que le mode batterie soit pour l’efficacité et organisez votre travail en conséquence.

4) « Branché, mais toujours lent et pas en charge »

Symptôme : le pourcentage de batterie diminue lentement alors que l’appareil est connecté.

Cause racine : wattage de l’adaptateur trop faible, négociation USB-C PD à une puissance inférieure, ou dock incapable de fournir sous charge.

Solution : utilisez l’adaptateur OEM haute puissance ; remplacez le câble ; évitez les docks basse puissance pour les charges soutenues.

5) « La temp. CPU est correcte, mais les fréquences restent basses »

Symptôme : températures sous le seuil de throttling, pourtant fréquence/puissance basses.

Cause racine : enforcement de limite de puissance, EPP/energy bias, « mode silencieux » constructeur ou quota cgroup.

Solution : vérifiez la politique de puissance et le throttling cgroup ; vérifiez que le turbo n’est pas désactivé par le BIOS ; puis considérez les profils performance constructeur.

6) « J’ai repasté et ça n’a presque rien changé »

Symptôme : pics de température plus bas mais même performance soutenue.

Cause racine : la performance soutenue est limitée par la puissance, pas par la thermique ; PL1 OEM est le plafond.

Solution : arrêtez de considérer le refroidissement comme le seul levier. Mesurez le comportement PL1 ; s’il est plafonné, acceptez-le ou changez de matériel.

7) « Les benchmarks sont excellents, le travail réel est médiocre »

Symptôme : bons scores sur tests courts, lent sur compilations/rendus longs.

Cause racine : les benchmarks favorisent les rafales ; votre charge est soutenue et chauffe le châssis.

Solution : utilisez des benchmarks soutenus (runs en boucle, charges de 10 minutes) et suivez la puissance package stabilisée et les fréquences.

8) « La montée de gamme CPU n’a pas beaucoup aidé ma charge »

Symptôme : le nouveau CPU semble similaire.

Cause racine : la charge est limitée par l’I/O, la mémoire ou le GPU ; ou le nouveau portable a des limites soutenues plus basses malgré une silicon plus récente.

Solution : mesurez les goulots (iowait, swap, utilisation GPU). Si la puissance soutenue est plus basse, vous avez acheté une histoire plus fine, pas une machine plus rapide.

Listes de contrôle / plan étape par étape

Checklist A : Acheter un portable pour du travail CPU soutenu

1. Choisissez par modèle, pas par CPU SKU. Le même CPU dans des châssis différents peut se comporter très différemment.
2. Exigez des chiffres soutenus. Recherchez des tests qui montrent des boucles de plusieurs minutes et la puissance stabilisée.
3. Privilégiez un refroidissement plus épais pour les charges longues. Chambre à vapeur, ventilateurs doubles, bonne évacuation. Le poids est une caractéristique de performance.
4. Vérifiez le wattage de l’adaptateur. Assurez-vous que l’alimentation peut couvrir CPU+GPU+charge. USB-C PD est pratique, pas magique.
5. Confirmez les attentes de performance sur batterie. Si vous en avez vraiment besoin, testez-le.
6. Surveillez les modes performance constructeur. Certains sont de vrais réglages ; d’autres ne sont que des habillages UI pour « rendre plus bruyant ».
7. Prévoyez le refroidissement du SSD. Les builds et VMs soutenus peuvent chauffer les NVMe jusqu’au throttling.
8. Ne misez pas tout sur des graphiques de benchmark en une seule exécution. Demandez : que se passe-t-il à la minute 8 ?

Checklist B : Diagnostiquer un portable existant qui « devrait être plus rapide »

1. Normalisez les variables : adaptateur OEM, branché, ambiance stable, lid ouvert, pas de couverture sur le lit.
2. Définissez une politique d’énergie connue (mode performance temporaire) et désactivez le « mode silencieux » constructeur.
3. Exécutez une charge CPU soutenue pendant 3–10 minutes.
4. Observez : puissance package, fréquence, température, comportement des ventilateurs.
5. Décidez : limité par la puissance vs limité thermiquement vs autre goulot (RAM/SSD/cgroups).
6. Si limité thermiquement : nettoyez les évents/ventilateurs, vérifiez la rotation des ventilateurs, inspectez pâte/pads, envisagez un pad de refroidissement en dépannage.
7. Si limité par la conception : évaluez les options firmware ; sinon arrêtez de perdre du temps et acceptez l’enveloppe produit.
8. Si « autre goulot » : corrigez la pression RAM, la saturation I/O ou les quotas de conteneurs.

Checklist C : Fixer les attentes pour les équipes (édition entreprise)

1. Standardisez sur des modèles spécifiques. Pas « n’importe quel i7 ». Un modèle, baseline BIOS, adaptateur de référence.
2. Définissez un test d’acceptation. Charge soutenue + observation de la puissance stabilisée.
3. Documentez les modes énergie. « Silencieux », « équilibré », « performance » et quand les utiliser.
4. Fournissez un niveau workstation. Certains ingénieurs ont besoin de performance soutenue ; prétendre que tout le monde n’en a pas est gaspiller la paie.
5. Instrumentez la douleur des développeurs. Suivez les temps de build et la pression des ressources ; traitez cela comme la latence en production.

FAQ

1) Le TDP est-il la puissance maximale absorbée ?

Non. Sur les CPU mobiles modernes, les rafales courtes peuvent dépasser la « classe TDP » de beaucoup. La puissance soutenue peut aussi être inférieure, selon les limites OEM.

2) Pourquoi deux portables avec le même CPU ont-ils des performances différentes ?

Parce que l’OEM fixe les limites soutenues et de rafale, les courbes de ventilateur et parfois des solutions thermiques différentes. Le modèle CPU n’est qu’une entrée parmi d’autres pour la performance.

3) Qu’est-ce qui compte plus que le TDP pour le travail soutenu ?

La puissance package et la fréquence stabilisées après plusieurs minutes de charge, ainsi que savoir si le système est limité par la puissance ou par la thermique dans cet état stable.

4) Si j’augmente les limites de puissance, aurai‑je toujours plus de performance ?

Seulement si vous avez une marge thermique et une alimentation suffisante. Sinon vous obtiendrez des températures plus élevées, des ventilateurs plus bruyants, puis un retour au même point par throttling.

5) Pourquoi mon portable throttle alors que la temp. CPU n’est pas au maximum ?

Parce que des limites de puissance peuvent plafonner la performance avant d’atteindre les limites thermiques. De plus, d’autres capteurs (VRM, température de surface) peuvent déclencher des throttles au niveau plateforme.

6) L’undervolting aide-t-il ?

Parfois. Réduire la tension peut faire baisser la puissance à une fréquence donnée, ce qui peut améliorer les fréquences soutenues dans la même enveloppe thermique/puissance. Sur beaucoup de plateformes modernes, l’undervolting peut être restreint par le firmware pour des raisons de sécurité/stabilité.

7) « 15W » vs « 28W » fait-il une grosse différence ?

Cela peut être énorme pour les charges soutenues, mais seulement si le portable autorise réellement ces limites soutenues. Certaines puces « capables de 28W » sont intégrées dans des portables qui tiennent bien moins en charge.

8) Quel est le test le plus simple pour voir la capacité CPU soutenue de mon portable ?

Exécutez un stress CPU de 3–10 minutes (ou votre charge réelle) tout en surveillant la puissance package et la fréquence dans le temps. Le plateau est votre réalité.

9) Pourquoi les reviewers et fiches techniques se focalisent-ils encore sur le TDP ?

Parce que c’est un nombre unique qui tient dans un tableau comparatif. Le comportement soutenu est une courbe, et les courbes sont gênantes pour le marketing et les filtres d’achat.

10) Dois-je acheter un portable gaming pour du travail CPU ?

Pas automatiquement, mais beaucoup de châssis gaming ont un meilleur refroidissement soutenu et des budgets de puissance plus élevés. Si vous valorisez la performance soutenue plutôt que la portabilité et le silence, c’est un choix rationnel.

Conclusion : prochaines étapes qui ne gaspillent pas votre argent

Arrêtez d’acheter des portables comme s’ils étaient des CPU desktop dans un autre boîtier. Le TDP n’est pas un contrat. Sur les portables, c’est plutôt une suggestion amendée par le firmware, le refroidissement et la stratégie produit.

Ce qu’il faut faire ensuite :

1. Mesurez votre réalité : exécutez une charge soutenue et observez la puissance package, la fréquence et la température jusqu’à stabilisation.
2. Classez le limiteur : politique de puissance, PL1 plafonné par l’OEM, saturation thermique, adaptateur/dock, ou goulots non-CPU comme RAM/SSD.
3. N’tweakez que ce qui vaut la peine : corrigez les charges en arrière-plan, confirmez le wattage adaptateur, nettoyez les voies de refroidissement. Ne repastez pas un portable juste parce qu’il est plafonné par le firmware.
4. À l’achat : choisissez des modèles prouvés pour soutenir la puissance dont vous avez besoin, et traitez la « classe TDP » comme une étiquette de famille, pas une garantie de performance.

Le CPU peut être excellent. Le portable peut toujours mentir. Votre travail consiste à le faire avouer avec des mesures.