Quelqu’un dans votre équipe achète « le modèle RTX », le devis est approuvé, la boîte arrive, puis les benchmarks tombent avec un bruit sourd. Même nom de GPU que les unités de test, mêmes arguments marketing, et pourtant il fonctionne comme s’il courait avec un parachute.
Ce parachute, c’est généralement le TGP : la puissance graphique totale. C’est le budget en watts qui décide à quelle vitesse le GPU du portable est autorisé à fonctionner au-delà de quelques secondes. Les marques savent que c’est important. Elles savent aussi que cela gâche les beaux classements produits. Alors elles le cachent, l’embrouillent ou l’enterrent trois notes de bas de page plus loin.
Le TGP est le véritable numéro de modèle
Sur les ordinateurs de bureau, « RTX 4070 » signifie quelque chose de relativement stable. Sur les portables, c’est plus un nom de famille. La personne que vous rencontrez réellement est « RTX 4070 Laptop GPU à 140 W avec un MUX et un refroidissement correct » ou « RTX 4070 Laptop GPU à 60 W dans un châssis fin qui privilégie le silence plutôt que la physique ». Ce sont des produits différents portant le même badge.
Le TGP est l’enveloppe en watts pour le package GPU (et parfois ses rails d’alimentation associés). Il dicte les fréquences soutenues, le comportement soutenu de la mémoire sous charge et la vigueur des boosts lorsque le CPU réclame aussi de la puissance. Si vous travaillez avec la performance pour vivre — SRE, développeur, designer, data scientist — le comportement soutenu est le seul qui compte. Les chiffres éphémères servent les slides de keynote.
En pratique, le TGP influence :
- Les taux d’images et les temps de rendu après les premières 30–120 secondes.
- La constance : saccades, jitter et « pourquoi cette build est-elle plus lente à 14h qu’à 9h ? »
- Le bruit des ventilateurs et la température de surface : la puissance devient chaleur, et la chaleur devient bruit ou throttling.
- Le comportement de la batterie : des cibles de puissance plus élevées impliquent souvent des commutations plus agressives et une moins bonne stabilité débranchée.
Si vous retenez une chose : en comparant des portables, vous comparez autant les systèmes de refroidissement et les politiques d’alimentation que les GPU.
TGP, TDP, TBP : qui est quoi et pourquoi le marketing aime la confusion
Ces acronymes forment une parfaite tempête de « assez scientifique pour sonner crédible » et « suffisamment différents pour être utilisés comme arme sur une fiche technique ». Voici la cartographie pratique qui fonctionne sur le terrain.
TGP (puissance graphique totale)
Le TGP est le budget de puissance défini par le vendeur pour le GPU du portable. Il est généralement appliqué par le firmware et les pilotes comme une limite de puissance (parfois plusieurs limites : long terme, court terme, et crête). Certaines plateformes autorisent une marge via des fonctions comme NVIDIA Dynamic Boost, qui peut transférer du budget puissance du CPU vers le GPU dans les bonnes conditions.
TDP (puissance de conception thermique)
Le TDP est un nombre de planification thermique. Sur les CPU, il peut être une base pour la puissance soutenue aux fréquences de base, pas forcément le maximum. Sur les GPU, le marketing des portables utilise parfois le TDP de façon lâche quand il veut dire « une limite de puissance dans ce voisinage ». Ne misez pas votre achat dessus.
TBP (puissance totale de la carte)
Sur les machines de bureau, le TBP inclut souvent l’ensemble de la carte graphique : GPU, VRAM, régulateurs, et parfois les ventilateurs. Sur les portables, le TBP est moins utilisé de manière cohérente. Certains OEM parlent de « Maximum Graphics Power » ou de « GPU power » et attendent que vous fassiez comme si c’était un terme standard.
Ce qui vous importe lors d’un achat ou d’un diagnostic : la consommation GPU soutenue réelle sous votre charge de travail et si le système est limité par la puissance ou par la température.
Une citation que je garde collée à mon moniteur mental est une idée paraphrasée souvent attribuée à W. Edwards Deming : Si vous ne pouvez pas le mesurer, vous ne pouvez pas l’améliorer.
Que l’attribution soit parfaite ou non, le point est clair : vous ne corrigez pas ce que vous refusez d’observer.
Comment le TGP se traduit en FPS (et pourquoi ce n’est pas linéaire)
Plus de watts signifie généralement plus de performance, mais ce n’est pas une droite. Vous verrez des rendements décroissants à cause des courbes voltage-fréquence, des goulots de mémoire et de la saturation thermique. Le modèle mental utile :
- Tranches TGP basses (par ex., 45–80 W) : le GPU est souvent limité par la puissance presque en permanence. La performance évolue fortement avec les watts. Ce sont les portables où « même nom de GPU » ne veut rien dire.
- Tranches TGP moyennes (par ex., 90–115 W) : la montée en performance se poursuit mais s’aplatit. La qualité du refroidissement devient le facteur différenciant.
- Tranches TGP élevées (par ex., 125–175 W) : on peut encore gagner, mais vous payez en bruit, chaleur et parfois en portabilité. De plus, la puissance CPU devient une part plus importante de la performance en jeu/workstation, surtout en scénarios haute-FPS.
De plus, les GPU de portable vivent rarement seuls. Ils partagent un écosystème thermique et électrique avec :
- Le comportement de boost CPU (PL1/PL2 chez Intel, PPT/EDC/TDC chez AMD, limites OEM sur les deux).
- Tuyaux thermiques/vapor chamber partagés : la charge CPU peut chauffer la voie thermique du GPU et vice versa.
- Le refroidissement des VRM : des régulateurs en surchauffe peuvent déclencher des réductions de puissance même si les températures du die GPU semblent « correctes ».
- Le chemin d’affichage : Optimus, Advanced Optimus, commutateur MUX et sorties externes peuvent changer les caractéristiques de performance et la latence.
Blague n°1 : le marketing des portables traite les wattages comme votre salaire — jamais discuté en public, et tout le monde suppose qu’il est plus élevé qu’il ne l’est.
Pourquoi les marques enterrent le TGP
Parce que le TGP casse le récit bien rangé. Si un vendeur liste clairement « RTX 4070 (60 W) » à côté de « RTX 4070 (140 W) », une part des acheteurs comprendra instantanément qu’ils ne sont pas équivalents, et certains rétrograderont le modèle fin vers une carte moins coûteuse qui offre des performances similaires à faible puissance.
Il y a aussi des raisons pratiques pour lesquelles les OEM sont évasifs :
- La puissance est « jusqu’à » : Dynamic Boost et les modes OEM changent les limites selon les thermiques, la puissance du bloc d’alimentation et la charge CPU. Publier un seul chiffre leur semble risqué.
- Le casse-tête des SKU régionaux : le même châssis vendu dans deux régions peut partir avec des pads thermiques différents, des versions BIOS différentes ou des adaptateurs secteur différents.
- Objectifs d’acoustique : certaines gammes sont réglées pour le silence. Elles ne veulent pas « ceci est plus lent » en gras ; elles veulent « studio-silencieux ».
En tant qu’opérateur, peu importe pourquoi c’est caché. Ce qui compte, c’est que c’est caché. Considérez un TGP masqué comme un signe d’alarme lors de l’achat.
Faits intéressants et contexte historique
Ce ne sont pas des anecdotes pour le plaisir. Elles expliquent pourquoi la puissance GPU sur portable est devenue un tel bazar.
- Le branding « Max-Q » initial (fin des années 2010) a tenté de signaler des variantes GPU axées sur l’efficacité, mais les implémentations OEM variaient fortement en fréquences, thermiques et cibles acoustiques.
- Plus tard, « Max-Q » est devenu moins un SKU distinct et davantage un ensemble de technologies (gestion de puissance, réglage acoustique), ce qui a rendu difficile d’inférer le wattage depuis le nom.
- Le nommage GPU réutilisé sur de larges plages de wattage à mesure que les designs de portables se diversifiaient : ultrafins, laptops créateurs et remplaçants desktop voulaient tous le même badge pour vendre.
- Les mécanismes de type Dynamic Boost sont devenus plus courants quand les OEM ont réalisé qu’ils pouvaient échanger la marge CPU contre la marge GPU en jeu — jusqu’à ce que la charge bascule et que l’échange devienne pénalisant.
- Les adaptateurs sont devenus partie prenante de la performance : un système livré avec un adaptateur plus petit peut plafonner la consommation CPU+GPU, même si le refroidissement pourrait en gérer davantage.
- Les vapor chambers et la pâte thermique liquide ont permis à certains designs de soutenir un TGP plus élevé, mais ont aussi augmenté la variabilité : la qualité d’assemblage et les effets à long terme changent les résultats.
- Le routage d’affichage (Optimus vs MUX) est devenu un facteur de performance : là où les images sont acheminées affecte l’overhead et la latence, surtout aux taux de rafraîchissement élevés.
- Les mises à jour firmware peuvent changer les limites de puissance : les OEM ajustent parfois les courbes de ventilateur et les limites après le lancement suite aux retours, plaintes de bruit ou cas limites thermiques.
Guide de diagnostic rapide
Si un portable avec un « bon GPU » semble lent, ne devinez pas. Vous pouvez trouver le goulot d’étranglement en moins de 10 minutes si vous vérifiez les bonnes choses dans le bon ordre.
Premier point : confirmez que vous utilisez bien la voie dGPU que vous pensez
- L’application s’exécute-t-elle sur la carte dédiée, pas sur l’iGPU ?
- L’écran interne est-il routé par l’iGPU (Optimus) ce qui coûte en performance/latence ?
- Une mise à jour du pilote a-t-elle réinitialisé les paramètres « GPU préféré » ?
Deuxième point : déterminez si vous êtes limité par la puissance ou par la température
- Surveillez la consommation GPU, les fréquences et la température sous une charge soutenue.
- Si la consommation atteint un plafond dur avec des températures raisonnables, c’est une limite de puissance.
- Si la température se bloque à un plafond et que les fréquences chutent, c’est une saturation thermique ou un problème de hotspot/VRM.
Troisième point : identifiez qui vole le budget (CPU vs GPU)
- Exécutez une charge principalement GPU et une charge principalement CPU séparément, puis ensemble.
- Si la charge combinée fait chuter la puissance GPU, vous avez un design à partage thermique/puissance où le CPU se comporte en prédateur.
Quatrième point : vérifiez les modes OEM et le comportement BIOS/EC
- Les modes « Silent », « Balanced » et « Performance » ne sont pas cosmétiques. Ils changent souvent les plafonds TGP.
- Certaines options ne se déverrouillent qu’en AC, avec l’adaptateur de bonne puissance connecté.
Cinquième point : décidez quel type de correctif est acceptable
- Si c’est un échec d’achat : retour/échange, SKU différent, châssis différent.
- Si c’est un échec opérationnel : pilote, mode, poussière, pâte thermique, courbe de ventilateur, plan d’alimentation.
- Si c’est un échec de physique : acceptez-le ou redéfinissez l’exigence (eGPU, desktop, GPU distant).
Tâches pratiques : commandes, sorties et décisions
Ce sont des vérifications réelles et exécutables. Elles ne sont pas théoriques. Chaque tâche inclut ce que vous regardez et la décision que vous en tirez. Les exemples supposent Linux. Windows a des outils équivalents, mais Linux vous laisse voir la plomberie sans la danse d’interprétation GUI.
Task 1: Identify the GPU and driver actually in use
cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Xe Graphics [8086:9a49]
01:00.0 3D controller [0302]: NVIDIA Corporation AD106M [GeForce RTX 4070 Laptop GPU] [10de:2820]
Ce que cela signifie : Vous avez un iGPU et un dGPU NVIDIA. Le dGPU est présent sur le PCIe et devrait être utilisable.
Décision : Continuez. Si le dGPU n’apparaît pas, vous êtes face à un réglage BIOS, une absence matérielle ou un appareil mort — pas un mystère TGP.
Task 2: Confirm the NVIDIA driver is loaded and the GPU is visible to NVML
cr0x@server:~$ nvidia-smi
Tue Jan 13 10:22:41 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.58.02 Driver Version: 555.58.02 CUDA Version: 12.5 |
|-----------------------------------------+------------------------+----------------------|
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 4070 ... Off | 00000000:01:00.0 Off | N/A |
| N/A 54C P2 62W / 140W | 2210MiB / 8192MiB | 43% Default |
+-----------------------------------------+------------------------+----------------------+
Ce que cela signifie : NVML rapporte un plafond de puissance à 140 W. C’est un indice fort du plafond TGP configuré (ou d’un des plafonds).
Décision : Si Pwr:Usage/Cap affiche quelque chose comme 50W / 60W sur un modèle supposé haute-performance, vous avez trouvé le coupable. Ensuite : vérifiez si ce plafond change avec les modes OEM, l’adaptateur AC ou Dynamic Boost.
Task 3: Sample power draw and clocks over time (sustained behavior)
cr0x@server:~$ nvidia-smi --query-gpu=timestamp,power.draw,power.limit,clocks.sm,clocks.mem,temperature.gpu,utilization.gpu --format=csv -l 2
timestamp, power.draw [W], power.limit [W], clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, utilization.gpu [%]
2026/01/13 10:23:02, 118.45 W, 140.00 W, 2100 MHz, 8001 MHz, 72, 98 %
2026/01/13 10:23:04, 139.12 W, 140.00 W, 2235 MHz, 8001 MHz, 78, 99 %
2026/01/13 10:23:06, 139.87 W, 140.00 W, 2220 MHz, 8001 MHz, 79, 99 %
Ce que cela signifie : Le GPU sature la limite de puissance tandis que l’utilisation reste élevée. C’est un comportement classique limité par la puissance.
Décision : Si la performance est faible et que vous êtes calé sur une faible limite de puissance, vos seules corrections sont : changer de mode/BIOS, améliorer le refroidissement (parfois augmente la puissance autorisée), ou accepter que le SKU soit faible en TGP par conception.
Task 4: Check for Optimus/iGPU display path (common hidden tax)
cr0x@server:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x43 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 5 associated providers: 1 name:modesetting
Provider 1: id: 0x1f3 cap: 0x2, Sink Output crtcs: 4 outputs: 4 associated providers: 1 name:NVIDIA-G0
Ce que cela signifie : Le système fonctionne probablement en mode hybride où l’iGPU est le fournisseur d’affichage principal, et la GPU NVIDIA est un dispositif d’offload.
Décision : Si vous avez besoin du maximum de FPS/latence la plus faible, envisagez d’activer un mode MUX « dGPU only » (si disponible) ou d’utiliser un moniteur externe connecté à la sortie du dGPU.
Task 5: Confirm which GPU is rendering a given app (per-process)
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec jpg ofa command
0 24819 G 78 12 0 0 0 0 blender
Ce que cela signifie : Le processus utilise effectivement la GPU NVIDIA (bien). Si vous ne voyez rien, vous êtes probablement sur l’iGPU ou en rendu CPU.
Décision : Si l’app n’est pas sur le dGPU, corrigez les paramètres applicatifs, les variables d’environnement ou la préférence GPU de l’OS avant d’accuser le TGP.
Task 6: See whether power management is clamping performance states
cr0x@server:~$ nvidia-smi --query-gpu=pstate,clocks.sm,clocks.gr,clocks.mem --format=csv
pstate, clocks.sm [MHz], clocks.gr [MHz], clocks.mem [MHz]
P2, 2100 MHz, 2100 MHz, 8001 MHz
Ce que cela signifie : Beaucoup de GPU portables restent en P2 sous charge compute ; P0 est courant en gaming/graphisme. Ne paniquez pas parce que vous n’êtes pas en P0, mais surveillez fréquences et utilisation.
Décision : Si vous êtes coincé dans un P-state bas avec des fréquences faibles alors que l’utilisation est élevée, cela peut indiquer une restriction de politique, un bug de pilote, ou le fonctionnement sur batterie/mode silencieux.
Task 7: Check AC adapter and power supply constraints (the silent limiter)
cr0x@server:~$ upower -d | sed -n '/line-power/,/Device/p'
Device: /org/freedesktop/UPower/devices/line_power_AC
native-path: AC
power supply: yes
online: yes
has history: no
has statistics: no
Ce que cela signifie : La machine voit l’alimentation AC. Certains OEM imposent encore des plafonds différents selon la puissance de l’adaptateur, mais au moins vous n’êtes pas en « mode batterie ».
Décision : Si online: no, arrêtez les tests de performance. Branchez. Retestez ensuite, car le mode batterie réduit souvent fortement le TGP.
Task 8: Look for CPU power limits that starve the GPU
cr0x@server:~$ sudo turbostat --Summary --quiet --interval 2 | head -n 6
Avg_MHz Busy% Bzy_MHz IPC PkgWatt CorWatt GFXWatt
3180 62.14 5116 1.41 62.33 39.88 0.05
4022 71.02 5663 1.38 78.90 52.41 0.06
Ce que cela signifie : La puissance du package CPU est élevée. Dans un design à partage, cela peut réduire la marge GPU via inversion Dynamic Boost ou saturation thermique.
Décision : Si la performance GPU chute quand le CPU est actif, limitez le boost CPU (réglage OEM, plan d’alimentation) ou choisissez un portable avec un meilleur refroidissement partagé.
Task 9: Check kernel logs for thermal or power events
cr0x@server:~$ sudo dmesg -T | egrep -i 'thrott|thermal|power limit' | tail -n 8
[Tue Jan 13 10:18:11 2026] thermal thermal_zone7: critical temperature reached (105 C), shutting down
[Tue Jan 13 10:19:42 2026] CPU: Package power limit exceeded, capping frequency
[Tue Jan 13 10:23:15 2026] nvidia-modeset: WARNING: GPU temperature threshold exceeded, performance state reduced
Ce que cela signifie : Le système se dénonce lui-même. Ces messages font la différence entre « le TGP est bas par conception » et « votre refroidissement échoue ».
Décision : Si vous voyez des événements thermiques critiques, arrêtez. Nettoyez, refaites la pâte, vérifiez le comportement des ventilateurs et validez les ventilations. C’est du travail de fiabilité, pas de l’ajustement.
Task 10: Verify fan control and thermal zones (are fans even responding?)
cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +93.0°C (high = +100.0°C, crit = +105.0°C)
nvme-pci-0100
Adapter: PCI adapter
Composite: +68.9°C (low = -0.1°C, high = +84.8°C)
nvidia-gpu-pci-0100
Adapter: PCI adapter
temp1: +79.0°C
Ce que cela signifie : Le CPU tourne chaud, le GPU est tiède, le NVMe est chaud. Ce chiffre NVMe compte plus que ce que l’on croit : la mise en throttling du SSD peut se faire passer pour une « lenteur GPU » dans les workflows de création de contenu.
Décision : Si le CPU est proche du critique sous charge mixte, attendez-vous à voir la puissance GPU chuter. Améliorez le refroidissement, changez de mode, ou réduisez le boost CPU.
Task 11: Check NVMe throttling during “GPU workloads” that actually stream data
cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|warning|critical'
temperature : 69 C
warning_temp_time : 17
critical_comp_time : 0
Ce que cela signifie : Le SSD a passé du temps au-dessus de sa température d’avertissement. Dans de gros builds d’actifs ou lors du scrubbing vidéo, cela peut réduire le débit et provoquer des blocages.
Décision : Si le temps d’avertissement augmente pendant votre charge, ajoutez un pad thermique/dissipateur, améliorez le flux d’air, ou évitez les portables qui placent le NVMe sous un GPU chauffé.
Task 12: Validate that the GPU is hitting “PerfCap” reasons (power vs thermal)
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '/Performance State/,/Clocks Event Reasons/p'
Performance State : P2
Clocks Event Reasons
Idle : Not Active
Applications Clocks Setting : Not Active
SW Power Cap : Active
HW Slowdown : Not Active
HW Thermal Slowdown : Not Active
Sync Boost : Not Active
Ce que cela signifie : Le GPU est bridé par une limite de puissance logicielle, pas par les thermiques. C’est l’empreinte d’un plafond TGP bas ou d’un mode limitant les watts.
Décision : Si SW Power Cap: Active domine, chassez la politique de puissance (mode OEM, Dynamic Boost, pilote, VBIOS). Si HW Thermal Slowdown est actif, chassez le refroidissement.
Task 13: Watch CPU frequency scaling policy (Linux power governor matters)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
Ce que cela signifie : Vous êtes en powersave. Sur beaucoup de systèmes, cela peut réduire la réactivité des rafales et changer la manière dont la plateforme partage la puissance.
Décision : Pour les tests de performance, fixez une politique cohérente. Sinon, vos données de benchmark sont inutilisables.
Task 14: Set a consistent CPU governor for repeatable tests
cr0x@server:~$ sudo apt-get install -y linux-tools-common linux-tools-generic
...output...
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 avez réduit une source de variance. Maintenant le comportement de puissance GPU est plus facile à interpréter.
Décision : Utilisez ceci avant de comparer « mode A vs mode B » ou avant d’accuser le TGP. Sinon vous mesurez le gouverneur.
Task 15: Confirm if the system is running in a vendor “quiet” mode (common hidden TGP clamp)
cr0x@server:~$ cat /sys/firmware/acpi/platform_profile
quiet
Ce que cela signifie : La plateforme est explicitement réglée pour une opération silencieuse. Cela implique souvent une courbe de ventilateur et un TGP réduits.
Décision : Passez en performance ou balanced pour du travail réel si vous avez besoin du GPU. Si l’acoustique est inacceptable, vous avez acheté le mauvais châssis pour la tâche.
Task 16: Switch platform profile (when supported) and re-measure power cap
cr0x@server:~$ echo performance | sudo tee /sys/firmware/acpi/platform_profile
performance
cr0x@server:~$ nvidia-smi --query-gpu=power.limit --format=csv
power.limit [W]
140.00 W
Ce que cela signifie : Sur certains systèmes, le plafond GPU change avec le profil ; sur d’autres non. L’important est que vous l’ayez mesuré, pas supposé.
Décision : Si la limite augmente après le changement de profil, intégrez cela à votre procédure opérationnelle standard. Si rien ne change, vous êtes probablement lié par le VBIOS ou des plafonds OEM.
Trois mini-histoires d’entreprise tirées du monde réel
Mini-histoire 1 : L’incident causé par une fausse hypothèse
Une équipe de design a déployé une nouvelle norme d’ordinateur portable pour un groupe distribué effectuant des rendus accélérés par GPU. Les achats ont standardisé sur un seul modèle « classe RTX » et négocié une remise. Tout le monde était content. Pendant environ deux semaines.
Puis les tickets ont afflué. Les rendus prenaient 30–50 % de temps en plus que la génération précédente. On a d’abord suspecté des régressions de pilote, puis le moteur de rendu, puis les mises à jour Windows. Les SREs ont été entraînés parce que « la ferme de rendu est lente », alors que la moitié des jobs tournaient localement sur des portables.
L’équipe a fait ce qui était évident : benchmarker l’ancien et le nouveau côte à côte. Le nouveau portable grimpait à des fréquences impressionnantes pendant une minute, puis se stabilisait à un état permanent… curieusement médiocre. Les thermiques semblaient corrects. Les ventilateurs étaient silencieux. Trop silencieux.
La cause racine était douloureusement simple : ils avaient supposé que le nom du GPU impliquait une classe de performance. Ce n’était pas le cas. Le GPU du nouveau portable était configuré avec un TGP beaucoup plus bas que le modèle précédent. Même badge. Physique différente. Le vendeur avait optimisé le châssis pour le confort acoustique et l’autonomie, et la limite de puissance GPU faisait partie de cet accord.
La solution n’était pas un réglage. C’était un renversement d’achat. Ils ont déplacé l’équipe vers un châssis plus épais avec une limite de puissance soutenue plus élevée, et ont inscrit « puissance GPU soutenue minimale » comme exigence ferme dans le prochain RFP. La leçon réelle : traitez le nom du GPU comme un indice, pas comme un contrat.
Mini-histoire 2 : L’optimisation qui a mal tourné
Un groupe produit voulait une meilleure autonomie en déplacement. Ils ont déployé un script de configuration « efficacité » : profil plateforme sur quiet, préférence iGPU pour la plupart des applis, et limitation des performances CPU. Le déploiement était propre, automatisé et bien intentionné.
Puis des bugs étranges sont apparus. Les développeurs disaient que les builds Docker allaient bien, mais leurs notebooks ML étaient incohérents. Parfois l’entraînement était rapide ; parfois il ramait. Les appels vidéo déclenchaient occasionnellement des saccades pendant une compilation GPU-intensive. Tout le monde accusait « le pilote GPU » parce que c’est une habitude.
Le post-mortem était un classique « deux optimisations qui se percutent ». Le mode quiet réduisait l’agressivité des ventilateurs et plafonnait la puissance GPU. Pendant ce temps, la limitation CPU changeait la manière dont la plateforme allouait la puissance partagée. Sous des charges mixtes — navigateur, appel, notebook — le système oscillait entre politiques, et le GPU heurtait des plafonds de puissance de façon imprévisible.
Ils ont essayé de le régler avec plus de scripts. Ça a empiré. La vraie solution était ennuyeuse : séparer le mode voyage du mode station de travail, et rendre la bascule explicite. Sur secteur en mode station, le portable tournait avec un plafond GPU élevé et des thermiques prévisibles. Sur batterie en mode voyage, les utilisateurs acceptaient des entraînements plus lents comme compromis.
L’optimisation a échoué parce qu’elle n’était pas cadrée. Les politiques d’efficacité doivent être opt-in et conscientes des charges de travail. Sinon elles deviennent des incidents de performance invisibles.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une équipe média avait l’habitude qui paraissait pédante : chaque nouveau SKU de portable passait par un court « test d’entrée de performance soutenue ». Dix minutes de charge GPU lourde, dix minutes de charge CPU lourde, puis dix minutes de charge combinée. Ils enregistraient la consommation, les fréquences et les températures, et archivaient les résultats avec les dossiers d’achat.
Ce n’était pas glamour. Ça ne faisait pas des slides. Mais cela créait une base. Quand une mise à jour firmware est arrivée en milieu de trimestre et que les éditeurs se sont mis à se plaindre des temps d’export, l’équipe n’a pas débattu des impressions. Ils ont comparé la nouvelle télémétrie avec la base.
Les données montraient que le plafond de puissance GPU n’avait pas changé, mais que le comportement de la courbe de ventilateur avait bougé ; le GPU atteignait maintenant une décélération thermique dans les mêmes conditions ambiantes. La mise à jour était probablement un ajustement pour réduire le bruit. L’équipe a roll-backé le firmware sur les unités affectées, épinglé la version qui marche et escaladé auprès du vendeur avec des preuves.
Ils ont évité un mois de perte de productivité parce qu’ils traitaient les portables comme des systèmes de production : baseline, observer et contrôler le changement. Ennuyeux. Correct. Efficace.
Erreurs courantes : symptôme → cause racine → correctif
Voici la partie où l’on arrête d’accuser le « mauvais silicium » et où l’on commence à diagnostiquer comme des adultes.
1) Symptom: “Same GPU as reviews, but 20–40% slower”
Cause racine : Configuration TGP plus basse (souvent liée à un châssis fin, un profil silencieux ou un SKU régional).
Correctif : Vérifiez le plafond de puissance via nvidia-smi. Contrôlez le mode performance OEM et les réglages MUX. Si le plafond est fondamentalement bas, échangez contre un SKU à TGP supérieur ou changez de châssis.
2) Symptom: “Fast for one minute, then drops and stays low”
Cause racine : Saturation thermique ou surchauffe des VRM ; parfois des caloducs partagés avec le CPU provoquent un soak thermique.
Correctif : Enregistrez les températures et les raisons de PerfCap. Nettoyez les aérations, vérifiez la montée des ventilateurs, envisagez une nouvelle pâte thermique. Réduisez le boost CPU pour des charges mixtes.
3) Symptom: “GPU power draw won’t exceed X watts even when cool”
Cause racine : Plafond de puissance logiciel (politique), limite VBIOS, ou clamp OEM de mode.
Correctif : Changez le profil plateforme, assurez-vous d’être sur AC avec l’adaptateur correct, mettez à jour BIOS/EC et retestez. Si rien ne change, considérez-le comme une limite de conception.
4) Symptom: “External monitor makes games faster”
Cause racine : L’écran interne est routé via l’iGPU (Optimus), le port externe est câblé au dGPU.
Correctif : Utilisez le mode MUX « dGPU only » pour l’écran interne si disponible, ou utilisez le port câblé au dGPU pour les sessions critiques.
5) Symptom: “GPU utilization low, but FPS is low too”
Cause racine : Goulot CPU, budget de puissance volé par le CPU, ou un cap de synchronisation/rafraîchissement (V-Sync, limiteur de frame).
Correctif : Vérifiez la puissance package CPU et la fréquence par cœur sous charge, désactivez les caps pour tester et comparez comportement GPU-seul vs charge combinée.
6) Symptom: “Performance is inconsistent day-to-day”
Cause racine : Variations de température ambiante, accumulation de poussière, changements firmware, ou applications d’arrière-plan changeant la charge CPU (et donc la puissance partagée).
Correctif : Établissez une baseline en mode contrôlé, suivez versions firmware/pilote, et mesurez les raisons de PerfCap pour séparer problèmes thermiques et politiques.
7) Symptom: “On battery, it’s unusable”
Cause racine : Les limites de décharge batterie plafonnent fortement la puissance GPU et CPU pour protéger la batterie.
Correctif : Acceptez la physique. Pour du travail GPU, branchez. Si vous avez besoin de performance GPU sans fil, vous décrivez une autre classe d’appareil (et il sera plus lourd).
8) Symptom: “After a driver update, GPU won’t boost”
Cause racine : Réinitialisation des paramètres (GPU préféré, mode de gestion d’alimentation), ou bug interagissant avec l’EC OEM.
Correctif : Revérifiez la sélection GPU par application, vérifiez les plafonds de puissance, et revenez en arrière si nécessaire. Traitez les mises à jour de pilote comme des fenêtres de changement.
Listes de contrôle / plan étape par étape
Checklist d’achat : comment ne pas acheter le mauvais « même GPU »
- Exigez la fourchette de TGP par écrit pour le SKU exact (pas la famille produit).
- Exigez la puissance de l’adaptateur incluse dans la boîte ; ne laissez pas « varie selon la région ».
- Demandez s’il y a un commutateur MUX et s’il peut être forcé en dGPU-only.
- Demandez des revendications de performance soutenue (10–20 minutes de charge), pas seulement le « boost clock ».
- Préférez les tests qui enregistrent la puissance dans le temps et montrent les raisons de PerfCap, pas seulement la moyenne FPS.
- Achetez d’abord une unité, exécutez votre test d’entrée, puis élargissez la commande.
Checklist d’intake (15–30 minutes par modèle)
- Mettez à jour l’OS, mais figez les versions de pilote pour la fenêtre de test.
- Définissez un profil plateforme cohérent (balanced ou performance) et confirmez l’AC.
- Enregistrez la puissance/fréquence/températures GPU toutes les 2 secondes pendant une charge soutenue.
- Exécutez une charge CPU-only et observez si la puissance GPU change ensuite.
- Exécutez une charge combinée CPU+GPU et mesurez si la puissance GPU s’effondre.
- Enregistrez la température ambiante et le bruit des ventilateurs subjectivement (« silencieux, tolérable, sèche-cheveux »).
- Sauvegardez les logs avec le dossier d’achat.
Checklist opérations : quand un utilisateur dit « mon portable GPU est lent »
- Vérifiez que l’app utilise le dGPU (pas l’iGPU).
- Vérifiez que le portable est sur AC et en profil non-silencieux.
- Vérifiez le plafond de puissance
nvidia-smiet les raisons de PerfCap sous charge. - Vérifiez températures et messages dmesg liés au thermique/power-limit.
- Vérifiez si un écran externe change la performance.
- Décidez : correction de configuration, maintenance, ou remplacement par achat.
Blague n°2 : si vous voulez un portable fin, silencieux, frais et rapide, vous cherchez une licorne — alimentée par un adaptateur 240W.
FAQ
1) Qu’est-ce exactement que le TGP ?
Le TGP est le budget de puissance que le portable autorise au GPU sous charge soutenue. Un TGP plus élevé signifie en général des fréquences et donc des performances soutenues supérieures — si le refroidissement suit.
2) Pourquoi deux portables avec le même nom de GPU ont-ils des performances différentes ?
Parce que le nom n’inclut pas la limite de puissance, la capacité de refroidissement, la conception des VRM, les règles de partage de puissance OEM ou le routage d’affichage. Sur les portables, ces facteurs sont le produit.
3) « Jusqu’à 140W » est-ce fiable ?
C’est un plafond, pas une promesse. Vous pouvez l’atteindre seulement sous conditions spécifiques : AC, mode performance, température ambiante fraîche, et une charge liée GPU sans que le CPU ne vole le budget.
4) Un TGP plus élevé signifie-t-il toujours mieux ?
Pas toujours. Au-delà d’un certain point, vous obtenez des rendements décroissants et beaucoup plus de bruit et de chaleur. De plus, certains portables haute-TGP ont une mauvaise exécution du refroidissement et throttleront quand même.
5) Comment vérifier le TGP sur un portable que je possède déjà ?
Sur NVIDIA, nvidia-smi montre souvent un plafonnement de puissance. La méthode la plus fiable est d’enregistrer la consommation réelle sous charge soutenue et de vérifier les raisons de PerfCap pour voir ce qui vous limite.
6) Quelle est la relation entre Dynamic Boost et le TGP ?
Dynamic Boost peut transférer le budget de puissance entre CPU et GPU. Il peut effectivement augmenter la puissance GPU dans des charges GPU-intensives, mais il peut aussi réduire la marge GPU quand la charge CPU augmente.
7) Un commutateur MUX a-t-il un impact sur le TGP ?
Pas directement, mais il peut changer la performance réalisée. Un MUX peut router l’affichage directement vers le dGPU, réduisant l’overhead et parfois améliorant la cohérence et la latence.
8) L’undervolting peut-il aider un portable à faible TGP ?
Ça peut améliorer l’efficacité et les thermiques, ce qui pourrait permettre au GPU de maintenir des fréquences plus élevées dans le même plafond de puissance. Mais l’undervolting ne transformera pas une conception 60W en une conception 140W.
9) Pourquoi mon GPU atteint-il des hautes températures même à des watts modestes ?
Limitations de refroidissement : ventilations bouchées, pâte thermique sèche, mauvais contact, courbes ventilateurs conservatrices, ou soak thermique depuis le CPU. Vérifiez aussi les limites VRM ou hotspots qui ne sont pas évidents à partir d’une seule valeur « temp GPU ».
10) Dois-je prioriser le TGP GPU ou les performances CPU pour le travail ?
Ça dépend de la charge. Pour rendu GPU, entraînement ML et jeux, le TGP est souvent déterminant. Pour du travail de compilation et simulation, la puissance CPU soutenue et le refroidissement peuvent être plus importants. Beaucoup de charges réelles sont mixtes, donc vous voulez un portable qui ne s’effondre pas sous charge combinée.
Conclusion : que faire ensuite
Si vous achetez : exigez le wattage. Pas « RTX machin », pas « Max performance », pas « creator edition ». Demandez la fourchette de limite de puissance GPU, la puissance de l’adaptateur, et si le portable peut soutenir cette puissance pendant au moins 10–15 minutes sans throttling. Si le vendeur ne peut pas répondre, considérez-le comme un élément à risque non borné — parce que c’en est un.
Si vous diagnostiquez : arrêtez de vous battre avec des impressions. Mesurez la consommation GPU, les plafonds de puissance, les raisons de PerfCap et les températures sous une charge soutenue. Décidez si vous êtes limité par la puissance, par les thermiques, ou si le budget est volé par le CPU. Ensuite choisissez la catégorie de correctif : mode/configuration, maintenance, ou remplacement. Les systèmes de production ne se règlent pas par souhaits. Les portables non plus.