Si vous avez déjà vu votre GPU grimper dans la fourchette 80–90°C en vous disant « ça ne peut pas être sain », vous n’êtes pas paranoïaque. La chaleur est la taxe que vous payez pour le débit. Parfois c’est une taxe normale. Parfois c’est le signe que votre système se dégrade en silence.
En production, des GPU chauds ne sont pas une ambiance : c’est un problème de fiabilité, un problème de performance, et parfois un « pourquoi ce nœud a redémarré à 3 h du matin ». Rendons la physique intuitive, puis transformons-la en une feuille de route pratique que vous pouvez réellement exécuter.
L’explication claire : petit espace, grande puissance, mathématiques sévères
Les GPU chauffent pour la même raison que les cuisines animées : beaucoup de travail dans une petite zone, de l’énergie constamment injectée, et seulement quelques issues pour que cette énergie parte.
Au niveau le plus simple :
- La puissance électrique entre. Votre GPU peut tirer 200–600 watts sous charge.
- Presque toute cette puissance devient de la chaleur. Pas « une partie ». Presque tout. Le résultat utile est le calcul, mais le calcul ne sort pas de la boîte sous forme d’énergie ; il sort sous forme de résultats. La puissance se transforme toujours en chaleur.
- La chaleur doit traverser une chaîne de matériaux. Silicium → boîtier → interface thermique (pâte/pads) → plaque froide du dissipateur → ailettes → air (ou liquide) → salle → HVAC.
- Tout maillon faible élève les températures en amont. Les systèmes thermiques sont des files d’attente. Si la sortie se bouche, tout devient plus chaud.
Voici ce que les gens oublient : un GPU haut de gamme moderne est un appareil à haute densité de puissance. Ce n’est pas seulement « 600 W ». C’est « 600 W dans une zone de la taille d’une paume », avec des pics locaux qui importent plus que la moyenne.
Autre moyen de s’en souvenir : les CPU sont des sprinters avec de fortes hypothèses de refroidissement intégrées aux châssis serveurs et aux standards de socket. Les GPU sont des trains de marchandises avec un radiateur d’appoint vissé sur le côté. Même électricité, conditionnement et réalité du flux d’air différents.
Petite blague n°1 : Un GPU est essentiellement une calculatrice très chère qui fait aussi office de chauffage d’appoint — votre facture d’électricité veut juste qu’on l’apprécie.
Ce que signifie « chauffe » (et quels chiffres comptent)
« Mon GPU est à 85°C » n’est pas assez d’information pour diagnostiquer quoi que ce soit. Il faut savoir quel capteur, ce que fait la charge de travail, et si le GPU bride.
Les températures importantes
- Température du cœur du GPU : le classique « temp GPU » que la plupart des outils affichent. Utile, mais souvent plus rarement le premier limiteur aujourd’hui.
- Température du hotspot / jonction : le point le plus chaud mesuré sur la puce. C’est souvent celle qui atteint les limites en premier, surtout avec un contact imparfait ou de la pâte vieillie.
- Température de jonction de la mémoire (notamment GDDR6X) : la mémoire peut être plus chaude que le cœur et déclencher du throttling. Vous pouvez avoir un cœur « correct » et être quand même en difficulté.
- Températures des VRM / étages d’alimentation : les composants de régulation de tension chauffent sous fort courant. Ce sont des tueurs de fiabilité discrets.
- Température d’arrivée / ambiante : la température de l’air entrant dans le refroidisseur du GPU, pas la température « quelque part dans la pièce ». Une hausse de 5°C à l’entrée est significative.
Ce que « trop chaud » signifie en pratique
Les GPU sont conçus pour fonctionner chaud. Les fournisseurs savent que le silicium supporte des températures de jonction élevées. Mais « conçu pour » et « bon pour votre parc » sont deux choses différentes. Pour les cartes grand public, voir des températures de cœur dans les 70–mids-80°C en charge soutenue peut être normal selon le modèle et le flux d’air. Pour les pièces datacenter, le comportement dépend du design de refroidissement (les dissipateurs passifs dépendent du flux d’air du châssis).
Ce qui compte opérationnellement :
- Bridage : baisse de performance parce que des limites de température ou de puissance sont atteintes.
- Taux d’erreurs : erreurs ECC mémoire, erreurs PCIe, réinitialisations du pilote, plantages d’applications.
- Marges de stabilité : un GPU « correct » à 22°C ambiant peut être catastrophique à 30°C par une journée chaude ou avec un filtre partiellement bouché.
- Vieillissement des composants : des températures plus élevées accélèrent les mécanismes d’usure. Vos rêves de MTBF meurent lentement, puis tous à la fois.
Une citation pour garder les priorités claires : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan
Pourquoi les GPU chauffent plus que les CPU en pratique
Il n’y a pas une seule raison. C’est une pile de raisons qui s’alignent comme des dominos défavorables.
1) Les GPU recherchent le débit via un parallélisme massif
Un CPU a quelques cœurs complexes optimisés pour les décisions à faible latence. Un GPU a des milliers d’unités d’exécution plus simples conçues pour effectuer le même type de travail sur de larges jeux de données. Ce parallélisme est excellent pour le graphisme et l’apprentissage automatique. Il signifie aussi beaucoup de transistors qui commutent en même temps. La commutation coûte de l’énergie. L’énergie devient chaleur.
2) Ils fonctionnent près de leurs limites de puissance et thermiques par conception
Les GPU modernes utilisent des algorithmes de boost agressifs : ils montent fréquence et tension jusqu’à atteindre une limite — température, puissance, ou contrainte de fiabilité de la tension. Vous n’achetez pas un « GPU à 3.0 GHz ». Vous achetez un système de contrôle qui exploite la limite de ce que le refroidissement et l’alimentation permettent.
3) La puissance de la carte inclut plus que le cœur
Les discussions CPU se concentrent souvent sur la puissance du package. La « board power » d’un GPU comprend mémoire, VRM, et d’autres composants. Le refroidisseur doit gérer plusieurs sources de chaleur, pas seulement une puce emballée proprement sous un dissipateur.
4) Les hypothèses de refroidissement sont souvent fausses
Les CPU serveurs vivent dans un monde où le flux d’air du châssis est conçu pour eux. Les GPU sont souvent fixés dans des boîtiers « assez bons », poussé à côté d’un autre GPU, et invités à respirer à travers un câble ruban et l’optimisme de quelqu’un.
5) Les charges de travail sont soutenues
Les jeux ont des pics et varient. Les entraînements et les pipelines d’inférence peuvent maintenir un GPU à forte utilisation pendant des heures ou des jours. La saturation thermique arrive. Un dissipateur qui semble correct pendant 10 minutes peut s’effondrer à la minute 45.
6) La densité de chaleur est le véritable ennemi, pas les watts absolus
Un appareil de 300 W réparti sur une grande surface peut être plus facile à refroidir qu’un appareil de 250 W avec un hotspot minuscule. La température du hotspot est là où la pâte thermique, la pression de montage et la conduction micro‑échelle deviennent votre limite de performance.
Anecdotes et histoire qui expliquent la chaleur actuelle
Les problèmes thermiques n’apparaissent pas parce que les ingénieurs sont devenus négligents. Ils apparaissent parce que les GPU ont gagné et que nous avons commencé à leur demander de tout faire.
- Les premiers accélérateurs 3D étaient des dispositifs de faible puissance. Les cartes d’extension de la fin des années 1990 consommaient une fraction de la puissance moderne ; beaucoup utilisaient de petits dissipateurs et de petits ventilateurs parce que la densité de puissance était faible.
- Les connecteurs d’alimentation dédiés aux GPU sont devenus classiques à mesure que la puissance de carte augmentait. Le passage au-delà de ce que le slot PCIe pouvait fournir en toute sécurité a forcé de nouveaux standards de connecteurs et de nouveaux modes de défaillance (y compris, oui, des connecteurs fondus quand les tolérances et la manipulation sont mauvaises).
- Les « shader cores » ont unifié les pipelines graphiques — et rendu le calcul général plus simple. Ce changement d’architecture a facilité le calcul sur GPU ; plus de calcul signifiait une consommation soutenue plus élevée.
- CUDA (2007) a popularisé le GPGPU. Une fois que les développeurs ont pu traiter les GPU comme des dispositifs de calcul, les charges sont passées de « graphismes en rafales » à « fournaise mathématique 24/7 ».
- HBM a montré la volonté de rapprocher la mémoire du GPU. La mémoire à haute bande passante empile la mémoire près du GPU avec une interface large. Cela améliore la bande passante et modifie où la chaleur se concentre et comment elle est refroidie.
- GDDR6X a augmenté la densité de puissance mémoire. Des signaux plus rapides peuvent signifier des modules mémoire plus chauds, faisant de la température de jonction mémoire un limiteur fréquent sur certaines cartes grand public.
- Les GPU datacenter ont fortement poussé le refroidissement passif. Beaucoup de GPU serveurs dépendent du flux d’air du châssis plutôt que de ventilateurs embarqués ; si le serveur n’est pas conçu pour cela, les températures s’envolent.
- Les algorithmes de boost sont devenus plus audacieux avec le temps. Les GPU modernes boostent opportunément jusqu’à atteindre des limites, signifiant que « il chauffe » est souvent littéralement la stratégie d’exploitation prévue.
- Les configurations multi-GPU ont créé des interférences thermiques. Placer des cartes puissantes côte à côte peut faire de l’air d’échappement d’une carte l’air d’admission d’une autre, ce qui est essentiellement du cannibalisme thermique.
Le chemin de la chaleur : du transistor à l’air ambiant
Quand quelqu’un dit « mon GPU est chaud », votre travail est de demander : où se trouve la résistance thermique ?
Étape 1 : la puissance est générée sur la puce
La puissance dynamique est dominée par l’activité de commutation et la tension. Sans vous plonger dans les équations, la vérité opérationnelle clé est : les variations de tension coûtent plus que les variations de fréquence. Une petite hausse de tension peut provoquer une augmentation disproportionnée de la puissance, et la chaleur suit.
Étape 2 : la chaleur se propage à travers le package
La chaleur doit quitter le silicium et traverser le boîtier et le dissipateur (s’il y en a un). Les imperfections ici ne sont pas réparables par l’utilisateur, mais elles se manifestent par « hotspot beaucoup plus élevé que le cœur », surtout en charge.
Étape 3 : l’interface thermique est une couche décisive
La pâte thermique et les pads comblent les gaps microscopiques. Si la pâte sèche, ou si un pad est trop épais, ou si la pression de montage est inégale, vous obtenez une signature classique : la température du hotspot grimpe rapidement tandis que la température moyenne du cœur semble « passable ».
Étape 4 : le dissipateur doit transférer la chaleur vers l’air
C’est là que la densité d’ailettes, la pression du ventilateur et la poussière comptent. Un dissipateur n’est bon que si l’air le traverse. L’air qui contourne les ailettes est un flux « marketing », pas un flux de refroidissement.
Étape 5 : le boîtier et la salle doivent évacuer la chaleur
Si le boîtier recircule l’échappement, votre refroidisseur GPU est forcé d’utiliser de l’air d’admission plus chaud. Même dissipateur, delta-T pire, températures plus élevées. En datacenter, si la séparation allée chaude/allée froide fuit, votre entrée « froide » devient lentement un « tiède regret ».
Petite blague n°2 : Le dépannage thermique, c’est comme du travail de détective, sauf que le coupable est toujours « le flux d’air », et il a toujours un alibi.
Feuille de diagnostic rapide : trouver le goulot en quelques minutes
C’est l’ordre qui fait gagner du temps. L’objectif est de déterminer si vous êtes limité par la température, la puissance, le flux d’air/ambiant, ou la confusion des capteurs/télémétrie.
Premier : confirmez que le GPU bride réellement (pas seulement qu’il est « chaud »)
- Vérifiez les fréquences et l’utilisation sous charge.
- Vérifiez les raisons de bridage (thermique, puissance, tension, fiabilité).
- Décision : si ça ne bride pas et que la stabilité est OK, vous poursuivez peut‑être un nombre, pas un problème.
Deuxième : comparez cœur vs hotspot vs températures mémoire
- Si le hotspot est bien au‑dessus du cœur, suspectez un mauvais contact/pâte/pression de montage ou une région de charge localisée.
- Si la jonction mémoire mène, suspectez le refroidissement mémoire (pads, flux d’air, conception du backplate) ou la pression mémoire de la charge.
- Décision : corrigez le limiteur dominant, pas le nombre le plus visible.
Troisième : vérifiez l’admission/ambiant et la réalité du flux d’air
- Mesurez la température de l’air d’admission là où le GPU respire.
- Validez le régime des ventilateurs et le comportement de la courbe ventilateur.
- Décision : si l’admission est chaude ou le flux obstrué, ne repastez pas en premier. Bougez l’air d’abord.
Quatrième : vérifiez le comportement de puissance et les caps
- Regardez la consommation, la limite de puissance et la performance par watt.
- Décision : dans beaucoup de cas en production, une petite limitation de puissance procure une grosse baisse de température avec une perte minime de débit.
Cinquième : vérifiez les problèmes au niveau plateforme
- Erreurs PCIe, throttling CPU provoquant une sous‑utilisation GPU (et des motifs thermiques étranges), réinitialisations de pilote.
- Décision : si le nœud est instable, traitez la « chaleur » comme symptôme, pas comme cause racine.
Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, quelles décisions
Voici des contrôles réels que vous pouvez exécuter sur un hôte Linux avec GPU NVIDIA. Les sorties montrées sont représentatives. Vos champs exacts varient selon le pilote et le modèle GPU. L’important est ce que vous lisez et ce que vous faites ensuite.
Tâche 1 : Instantané des thermiques, fréquences et puissance du GPU en une vue
cr0x@server:~$ nvidia-smi
Tue Jan 13 10:22:41 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------|
| 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 A10 On | 00000000:3B:00.0 Off | 0 |
| 30% 78C P2 143W / 150W | 10980MiB / 23028MiB | 92% Default |
+-----------------------------------------+------------------------+----------------------+
Ce que ça signifie : Temp à 78°C pour 92% d’utilisation, puissance proche du cap. L’état de performance P2 suggère qu’il est en mode haute performance. Ventilateur à 30% peut être conservateur.
Décision : Si la performance est stable et qu’il n’y a pas de bridage, cela peut être acceptable. Si vous voyez du bridage fréquent, augmentez la courbe ventilateur ou réduisez la limite de puissance.
Tâche 2 : Surveiller en direct pour repérer les motifs de bridage
cr0x@server:~$ watch -n 1 nvidia-smi --query-gpu=timestamp,temperature.gpu,utilization.gpu,clocks.sm,power.draw,pstate --format=csv
timestamp, temperature.gpu, utilization.gpu, clocks.sm, power.draw, pstate
2026/01/13 10:23:00, 79, 95, 1695, 149.22, P2
2026/01/13 10:23:01, 81, 96, 1695, 149.80, P2
2026/01/13 10:23:02, 83, 96, 1620, 149.90, P2
Ce que ça signifie : Les fréquences chutent à mesure que la température augmente alors que la puissance reste bloquée. C’est souvent une gestion thermique ou de fiabilité.
Décision : Confirmez la raison du bridage ensuite. Si c’est thermique, améliorez le refroidissement ou capez la puissance. Si c’est une limite de puissance, ajustez la limite ou acceptez-la.
Tâche 3 : Demandez au pilote pourquoi la performance est limitée
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============
Timestamp : Tue Jan 13 10:23:10 2026
Driver Version : 550.54.14
CUDA Version : 12.4
Performance State : P2
Clocks Throttle Reasons
Idle : Not Active
Applications Clocks Setting : Not Active
SW Power Cap : Active
HW Slowdown : Not Active
Thermal Slowdown : Not Active
Sync Boost : Not Active
SW Thermal Slowdown : Not Active
Ce que ça signifie : Vous êtes limité par la puissance, pas par la température. Le GPU obéit aux consignes : respecter le cap.
Décision : Si vous avez besoin de plus de débit, augmentez la limite de puissance (et assurez-vous d’un refroidissement/PSU adéquat). Si vous avez besoin d’un fonctionnement plus frais, maintenez ou réduisez le cap et optimisez le perf/W.
Tâche 4 : Logger températures et puissance dans le temps pour corrélation (observabilité simple)
cr0x@server:~$ nvidia-smi --query-gpu=timestamp,temperature.gpu,power.draw,utilization.gpu,clocks.sm --format=csv -l 5 -f /tmp/gpu_telemetry.csv
# Monitoring GPU 00000000:3B:00.0.
# Logging to /tmp/gpu_telemetry.csv
Ce que ça signifie : Vous obtenez une série temporelle que vous pouvez tracer ou comparer entre des runs « bons » et « mauvais ».
Décision : Si la température monte lentement jusqu’à un plateau, c’est probablement flux d’air/ambiant. Si la température bondit instantanément, c’est plutôt interface/contact ou contrôle ventilateur.
Tâche 5 : Vérifier si le pilote permet le comportement ventilateur attendu
cr0x@server:~$ nvidia-settings -q GPUFanControlState -q GPUTargetFanSpeed
Attribute 'GPUFanControlState' (server:0[gpu:0]): 0.
Attribute 'GPUTargetFanSpeed' (server:0[gpu:0]): 30.
Ce que ça signifie : L’état de contrôle ventilateur 0 signifie typiquement contrôle automatique. La cible est 30% (mais l’actuel peut différer).
Décision : Si les températures sont élevées et que le ventilateur reste bas, activez le contrôle manuel (si la politique le permet) ou corrigez la courbe dans le firmware/outil logiciel.
Tâche 6 : Vérifier le régime réel du ventilateur et s’il est défaillant
cr0x@server:~$ nvidia-smi --query-gpu=fan.speed,temperature.gpu --format=csv
fan.speed, temperature.gpu
30 %, 83
Ce que ça signifie : Le ventilateur tourne, mais on ignore si 30% suffit.
Décision : Si le GPU bride pour température, augmentez la vitesse du ventilateur et retestez. Si la vitesse est élevée mais que les températures restent hautes, suspectez obstruction du flux d’air, ailettes bouchées ou mauvais contact thermique.
Tâche 7 : Vérifier les thermiques CPU et le bridage (parce que la plateforme trompe)
cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: 92.0°C (high = +100.0°C, crit = +105.0°C)
Core 0: 89.0°C
Core 1: 91.0°C
nvme-pci-0100
Adapter: PCI adapter
Composite: +68.9°C (low = -40.1°C, high = +84.8°C, crit = +89.8°C)
Ce que ça signifie : Le package CPU est très chaud et proche du bridage. Cela peut fausser le comportement de la charge GPU (taux d’alimentation réduit, utilisation différente, cycles thermiques étranges).
Décision : Fixez le flux d’air du châssis et le refroidissement CPU aussi. Un incident thermique GPU est souvent un incident de flux d’air au niveau du nœud entier.
Tâche 8 : Vérifier la santé du lien PCIe (les erreurs peuvent masquer un « GPU qui se comporte bizarrement »)
cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | sed -n '1,80p'
3b:00.0 VGA compatible controller: NVIDIA Corporation Device 2236 (rev a1)
Subsystem: NVIDIA Corporation Device 147e
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq-
Ce que ça signifie : Des erreurs corrigeables sont enregistrées. Ce n’est pas une catastrophe immédiate, mais c’est un signal. La chaleur peut aggraver des liens marginaux.
Décision : Si vous voyez des erreurs corrigeables qui augmentent corrélées aux hautes températures, améliorez le refroidissement et réinsérez le matériel pendant la maintenance. Si les erreurs persistent, considérez des problèmes de carte/slot.
Tâche 9 : Confirmer qu’il n’y a pas une obstruction d’air simple (le classique « pourquoi on en est là »)
cr0x@server:~$ sudo lsblk -o NAME,HCTL,SIZE,MODEL
NAME HCTL SIZE MODEL
sda 0:0:0:0 447.1G Samsung SSD 860
nvme0n1 1.8T SAMSUNG MZVL21T0HCLR-00B00
Ce que ça signifie : Ce n’est pas une commande d’air. C’est un rappel : ne pas se focaliser uniquement sur le GPU. NVMe à 69°C et CPU à 92°C suggèrent que le flux d’air du châssis est sous‑dimensionné ou bloqué.
Décision : Inspectez les filtres, les parois de ventilateurs, le routage des câbles, les panneaux obturateurs, et si le serveur est installé dans une baie avec une prise d’air en allée froide appropriée.
Tâche 10 : Vérifier les logs kernel pour événements thermiques ou pilotes GPU
cr0x@server:~$ sudo journalctl -k -b | egrep -i 'nvrm|pcie|thermal|throttl' | tail -n 20
Jan 13 10:20:11 server kernel: nvidia-modeset: Allocated GPU:0 (GPU-2d3a...)
Jan 13 10:22:58 server kernel: NVRM: Xid (PCI:0000:3b:00): 79, GPU has fallen off the bus.
Jan 13 10:23:00 server kernel: pcieport 0000:00:03.1: AER: Correctable error received: 0000:3b:00.0
Ce que ça signifie : « Fallen off the bus » et les erreurs AER sont des indicateurs de stabilité sérieux. La chaleur peut contribuer, mais l’intégrité de l’alimentation, le siège PCIe, ou le firmware peuvent aussi être responsables.
Décision : Traitez cela comme un incident : réduisez la charge, augmentez le refroidissement, vérifiez la marge PSU, réinsérez le GPU, mettez à jour firmware/driver, et envisagez le remplacement matériel si récurrent.
Tâche 11 : Mesurer la consommation GPU et appliquer une limite de puissance sensée
cr0x@server:~$ sudo nvidia-smi -pl 130
Power limit for GPU 00000000:3B:00.0 was set to 130.00 W from 150.00 W.
Ce que ça signifie : Vous venez de réduire la puissance maximale de la carte. Cela diminue généralement les températures rapidement.
Décision : Lancez votre charge et comparez le débit. Si vous perdez 2–5% de performance mais gagnez 10°C et de la stabilité, c’est un compromis acceptable en production.
Tâche 12 : Confirmer que le cap est appliqué et observer les thermiques après le changement
cr0x@server:~$ nvidia-smi --query-gpu=temperature.gpu,power.draw,clocks.sm,utilization.gpu --format=csv
temperature.gpu, power.draw, clocks.sm, utilization.gpu
74, 129.12, 1620, 96
Ce que ça signifie : La température est passée du bas des 80s au milieu des 70s tandis que l’utilisation reste élevée. Les fréquences peuvent être légèrement plus basses, mais stables.
Décision : Conservez le cap comme politique pour cet environnement thermique, ou utilisez‑le comme mesure palliative pendant que vous corrigez le flux d’air.
Tâche 13 : Vérifier si le mode persistance est activé (réduit le churn, aide à la prévisibilité)
cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:3B:00.0.
All done.
Ce que ça signifie : Le pilote garde le GPU initialisé, ce qui peut réduire les pics de latence et les transitions de puissance/fréquence étranges entre jobs.
Décision : Sur des nœuds partagés en production, le mode persistance améliore souvent la prévisibilité. Si votre modèle multi‑locataire ou de sécurité l’interdit, documentez le compromis.
Tâche 14 : Valider que votre processus ne cause pas de chaleur inutile (utilisation hors contrôle)
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec command
# Idx # C/G % % % % name
0 28741 C 92 40 0 0 python
Ce que ça signifie : Un seul processus conduit une utilisation SM élevée. Cela peut être attendu. Ça signifie aussi que la chaleur est pilotée par la charge, pas par un « fond mystérieux ».
Décision : Si cela devrait être inactif, tuez ou replanifiez le job. Si c’est intentionnel, ajustez limites de puissance/courbes ventilateur et assurez la capacité de flux d’air.
Tâche 15 : Vérifier les goulots CPU qui créent un comportement GPU en rafales (et des thermiques étranges)
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server) 01/13/2026 _x86_64_ (64 CPU)
10:25:01 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
10:25:02 AM all 92.11 0.00 6.44 0.73 0.00 0.11 0.00 0.61
Ce que ça signifie : Le CPU est fortement chargé. Si votre pipeline GPU dépend du prétraitement CPU, vous pouvez obtenir une utilisation GPU en rafales, ce qui peut provoquer un comportement ventilateur étrange (les ventilateurs prenant du retard) et du cyclage thermique.
Décision : Profilez le pipeline. Déchargez le prétraitement, augmentez la capacité CPU, ou lissez l’ordonnancement des lots pour stabiliser la charge thermique.
Tâche 16 : Vérifier que les limites cgroup/conteneur ne créent pas un comportement thermique accidentel
cr0x@server:~$ systemd-cgls --no-pager | head -n 25
Control group /:
-.slice
├─system.slice
│ ├─docker.service
│ │ ├─4121 /usr/bin/dockerd -H fd://
│ │ └─...
│ └─ssh.service
└─user.slice
└─user-1001.slice
└─user@1001.service
└─app.slice
Ce que ça signifie : Vous voyez le placement des workloads. Les incidents thermiques viennent parfois de la colocation de jobs : deux jobs GPU « moyens » atterrissent sur le même nœud et le transforment en grille‑pain.
Décision : Corrigez les contraintes d’ordonnancement (un job GPU lourd par nœud), ou imposez des caps de puissance par classe de job.
Trois mini-histoires d’entreprise issues des tranchées thermiques
Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse
L’équipe a reçu une nouvelle série de serveurs GPU — même modèle de châssis que le trimestre précédent, même modèle de GPU, même agencement de baie. Le runbook de déploiement était « copier/coller ». C’est toujours comme ça jusqu’à ce que ça ne le soit plus.
En quelques heures, les jobs d’entraînement ont commencé à échouer d’une manière qui ressemblait à un problème logiciel : erreurs CUDA aléatoires, réinitialisations du pilote, et parfois le host enregistrait des erreurs PCIe correctables. Rien n’alertait « surchauffe » parce que les températures du cœur n’étaient pas outrageuses — milieu des 70s, parfois 80°C. Le responsable d’incident s’est concentré sur les versions et les rollbacks.
Après trop de temps et pas assez de café, quelqu’un a vérifié les températures de jonction mémoire. Elles étaient moches. Pas « chaudes », moches. L’hypothèse fautive était que la « temp GPU » dans les tableaux de bord reflétait le capteur limitant réel. Ce n’était pas le cas. La mémoire était fortement bridée, puis le pilote plantait sous contrainte soutenue.
La cause racine était banale : le fournisseur avait révisé la spécification des pads mémoire en cours de cycle, et les pads préinstallés sur ce lot avaient une compression légèrement différente. Ce n’était pas une conspiration. C’était la réalité de la chaîne d’approvisionnement. Le contact n’était pas bon, la mémoire chauffait, et le taux d’erreurs augmentait sous charges soutenues.
La solution a été tout aussi banale : remplacement des pads lors d’une fenêtre de maintenance contrôlée, plus un cap de puissance temporaire en attendant. La correction à plus long terme fut procédurale : baseliner tous les capteurs pertinents (cœur, hotspot, mémoire) et alerter sur les deltas, pas seulement sur la température absolue du cœur.
Mini‑histoire 2 : L’optimisation qui a mal tourné
Autre société, autre problème. Ils payaient cher pour la colocation et voulaient réduire la facture énergétique. Quelqu’un a proposé un « mode efficacité » : réduire la vitesse des ventilateurs de datacenter et augmenter de quelques degrés la consigne de l’allée froide. Le fournisseur disait que c’était dans les spécifications. La direction adorait parce que ça montrait des économies immédiates.
Au début, rien n’a brûlé. En fait, les températures cœur GPU semblaient seulement un peu plus élevées. Le changement a donc été étendu. Puis les bizarreries ont commencé : régressions de performance intermittentes. Pas des pannes totales — celles‑ci sont faciles à repérer. C’était des temps d’époque plus lents, des dépassements de job sporadiques, et des manques occasionnels aux SLA.
Le retour de bâton venait d’un détail : le comportement de boost GPU est un système de contrôle. Augmentez la température d’admission et vous réduisez la marge thermique. Les GPU passaient plus de temps en états de gestion thermique, faisant fluctuer les fréquences. L’utilisation moyenne restait élevée, mais le débit effectif chutait. Parallèlement, la température d’équilibre plus élevée augmentait le taux d’erreurs mémoire corrigeables sur certains nœuds, ce qui déclenchait des relances d’entraînement en amont. L’« optimisation énergétique » est devenue une « taxe calcul ».
Le rollback n’a pas été total. L’équipe a conservé une partie du changement, mais seulement après segmentation : certaines baies avec un meilleur flux d’air et confinement ont supporté les nouvelles consignes avec des caps de puissance. D’autres non. La leçon n’était pas « ne jamais optimiser ». C’était « optimiser avec garde‑fous et télémétrie qui reflète le débit, pas seulement la température ».
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une startup exécutant de l’inférence GPU avait une habitude qui paraissait trop basique pour être utile : chaque nouveau nœud passait par un burn‑in de 30 minutes avec une charge standardisée, et ils enregistraient une baseline pour temp cœur, hotspot, jonction mémoire, vitesse ventilateur et puissance à l’état stable.
Six mois plus tard, ils ont commencé à voir quelques nœuds chauffer 8–12°C de plus pour le même job. Rien n’était encore « cassé », mais ça dérivait. Comme ils avaient des baselines, il n’y avait pas de discussion sur ce qui était « normal ». Ils avaient des preuves.
L’équipe a retiré un nœud et a trouvé des ailettes de dissipateur partiellement obstruées — pas des amas de poussière spectaculaires, juste un tapis fin réduit suffisamment le flux d’air pour être important. Un autre nœud avait un câble interne légèrement mal routé qui gênait l’admission d’air près du GPU. Des choses ennuyeuses.
Ils ont nettoyé, corrigé le routage, relancé le burn‑in, et remis les nœuds en service. Pas d’incident. Pas de maintenance d’urgence. Pas de page le week‑end. La partie glamour du SRE est d’écrire des automations ingénieuses. La partie qui vous garde employable est de détecter la dégradation banale avant qu’elle ne devienne une panne.
Erreurs fréquentes : symptôme → cause racine → correctif
1) Symptom : « La temp du GPU est correcte, mais la performance est incohérente »
Cause racine : La température hotspot ou jonction mémoire bride, pas la température du cœur.
Correctif : Surveillez hotspot et températures mémoire. Améliorez le refroidissement mémoire (pads, flux d’air), ajustez les courbes ventilateur, ou appliquez un cap de puissance pour réduire la densité thermique.
2) Symptom : « Les températures montent instantanément au démarrage de la charge »
Cause racine : Mauvais contact thermique (pâte sèche, pression de montage inégale, pads déplacés) ou délai de réponse du contrôle ventilateur.
Correctif : Confirmez la réponse des ventilateurs lors d’une montée en charge ; si les ventilateurs réagissent mais que la température bondit, planifiez un repaste/re‑pad avec bonne épaisseur et couple de serrage. Ne devinez pas la taille des pads.
3) Symptom : « Un GPU dans un boîtier multi‑GPU est toujours plus chaud »
Cause racine : Recirculation thermique ou effets de placement (carte du dessus recevant l’échappement, admission bloquée).
Correctif : Réorganisez les cartes si possible, ajoutez des conduits/obturateurs, augmentez le flux d’air du châssis, ou imposez des limites de puissance par slot. Considérez le flux d’air de rack comme partie du système.
4) Symptom : « Les ventilateurs sont bruyants, les températures restent élevées »
Cause racine : Ailettes de dissipateur bouchées, mauvaise pression de boîtier, ou contournement du flux d’air (l’air prend le chemin le plus facile autour des ailettes).
Correctif : Nettoyez ailettes et filtres, assurez les shrouds/obturateurs, validez la séparation admission/échappement. Le flux d’air sans direction n’est que de la turbulence.
5) Symptom : « Réinitialisations du pilote / erreurs Xid pendant les jobs lourds »
Cause racine : Peut être thermique, instabilité d’alimentation, problèmes PCIe, ou matériel marginal ne faillant qu’à chaud.
Correctif : Corrélez les logs avec températures/puissance. Réduisez la limite de puissance, améliorez le refroidissement, vérifiez le siège PCIe et les erreurs AER, mettez à jour firmware/driver, et mettez en quarantaine le matériel instable.
6) Symptom : « Le GPU chauffe plus après un changement de boîtier ou un “nettoyage” »
Cause racine : Gestion de câbles bloquant une admission, panneaux obturateurs manquants, ou ventilateurs mal orientés.
Correctif : Validez physiquement la direction du flux d’air. Utilisez de la fumée/streamers si nécessaire. Remettez les panneaux obturateurs. Ne sacrifiez pas le flux d’air pour l’esthétique.
7) Symptom : « Les températures sont stables, mais le débit a baissé après tuning »
Cause racine : Cap de puissance trop agressif ou courbe ventilateur qui maintient des températures basses mais force des fréquences plus faibles.
Correctif : Tirez le meilleur parti du perf/watt. Augmentez progressivement la limite de puissance en observant les raisons de bridage et le débit, pas seulement la température.
8) Symptom : « N’échoue que par temps chaud / haute température ambiante »
Cause racine : Pas de marge. Le système de refroidissement est juste à la limite ; de petites variations d’admission le poussent au‑dessus.
Correctif : Créez de la marge : baissez la limite de puissance, augmentez le flux d’air, améliorez le confinement, planifiez les charges lourdes pendant les périodes plus fraîches si vous êtes contraints.
Listes de contrôle / plan pas-à-pas
Étape par étape : stabiliser un nœud GPU chaud (ordre sûr pour la production)
- Confirmer le bridage et le limiteur : utilisez
nvidia-smi -qpour les raisons de bridage ; identifiez thermique vs puissance vs autre chose. - Vérifier la répartition des capteurs : cœur vs hotspot vs jonction mémoire (si dispo). Identifiez l’indicateur principal.
- Vérifier les conditions d’admission : validez ventilateurs de châssis, filtres, et température d’admission en rack.
- Appliquer un cap de puissance temporaire : réduire de 10–20% et observer l’impact sur le débit.
- Augmenter la courbe ventilateur si autorisé : viser des températures stables, pas des oscillations.
- Rechercher signaux de stabilité : logs kernel pour Xid, erreurs AER, réinitialisations inattendues.
- Nettoyer et retester : filtres, dissipateurs et obstructions. Refaire la même charge pour comparaison.
- Planifier la maintenance corrective : repaste/re‑pad seulement après que l’air et la puissance soient sains ; faire en fenêtre contrôlée.
- Documenter une baseline : enregistrer températures/power/fréquences à l’état stable pour détecter la dérive plus tard.
Checklist : que capturer dans un ticket d’incident
- Modèle GPU, version du pilote, firmware si pertinent
- Description de la charge (motif d’utilisation, durée, taille de lot)
- Température cœur, température hotspot, température jonction mémoire (et quel outil les a lues)
- Puissance consommée, cap de puissance, pstate, fréquences
- Raisons de bridage depuis
nvidia-smi -q - Vitesse ventilateur et état des ventilateurs du châssis
- Emplacement de la mesure de la température d’admission
- Logs kernel pour Xid/AER/événements thermiques
- Résultats avant/après d’un test de cap de puissance
Checklist : décisions qui battent souvent « repastez tout »
- Cappez la puissance d’abord si vous avez besoin de stabilité immédiate.
- Corrigez le flux d’air ensuite (ça aide tout dans le nœud).
- Réfléchissez au repaste/re‑pad seulement ensuite — c’est invasif, variable, et facile à rater.
- Alertez sur les deltas et raisons de bridage, pas seulement sur un seul seuil de température.
FAQ
1) Est‑ce normal qu’un GPU tourne à 80–85°C ?
Souvent oui — selon le modèle GPU, la conception du refroidisseur, la température ambiante et la charge. « Normal » signifie « ne bride pas, stable, et dans les limites du fournisseur ». En production, vous voulez néanmoins de la marge.
2) Quelle est la différence entre température GPU et température hotspot/jonction ?
La température GPU est généralement un capteur moyen ou représentatif du cœur. Hotspot/jonction est la lecture maximale sur la puce. Le hotspot détecte une mauvaise pâte, une mauvaise pression de montage et une densité de chaleur locale.
3) Pourquoi ma température de jonction mémoire est‑elle plus élevée que celle du cœur ?
Parce que la mémoire est une source de chaleur indépendante et parfois a un contact de refroidissement moins bon. Le trafic HBM ou certains types de GDDR peuvent chauffer beaucoup. Si la jonction mémoire mène, vous avez un problème de refroidissement mémoire, pas du cœur.
4) Dois‑je undirvolter ou limiter la puissance de mon GPU ?
La limitation de puissance est généralement le geste le plus sûr et le plus reproductible en production : définissez un cap, mesurez le débit, conservez le meilleur point perf/W. L’undervolting peut fonctionner, mais il est plus fragile face aux variations silicium et aux changements pilote/firmware.
5) Mes ventilateurs GPU sont à 100% et les températures sont toujours élevées — que faire ?
Cela signifie généralement que l’air ne traverse pas les ailettes (bouchage, contournement, mauvais shroud), que l’air d’admission est trop chaud, ou que l’interface thermique est mauvaise. Nettoyage et vérification du flux d’air avant le repaste.
6) Pourquoi les systèmes multi‑GPU chauffent plus même si chaque GPU est « dans les specs » ?
Parce que le flux d’air système et la recirculation importent. L’échappement d’une carte devient l’admission d’une autre. Les ventilateurs du châssis peuvent ne pas être dimensionnés pour la charge combinée. « Dans les specs » pour chaque composant ne garantit pas un système combiné stable.
7) Le throttling thermique endommage‑t‑il le GPU ?
Le throttling thermique est un mécanisme de protection ; il cherche à éviter les dégâts. Le risque est que vous fonctionniez proche des limites, augmentant la probabilité d’instabilité et accélérant le vieillissement avec le temps.
8) Pourquoi la performance s’empire parfois après amélioration du refroidissement ?
Si votre « amélioration » a modifié trop agressivement les courbes ventilateur ou les caps de puissance, vous pouvez avoir abaissé les fréquences ou déclenché des bridages de puissance. Validez avec les raisons de bridage et des métriques de débit, pas seulement la température.
9) Quel est le changement le plus efficace pour réduire rapidement la température GPU ?
Dans beaucoup de flottes réelles : réduire la limite de puissance de 10–20%. C’est immédiat, réversible, et coûte souvent moins de performance que prévu. Ensuite corrigez le flux d’air pour récupérer de la marge.
Conclusion : prochaines étapes qui font vraiment la différence
Les GPU chauffent parce qu’ils transforment beaucoup de puissance électrique en calcul à l’intérieur d’un petit morceau de silicium, et la chaleur doit s’échapper à travers une longue chaîne de matériaux et d’hypothèses de flux d’air « assez bons ». Quand cette chaîne faiblit n’importe où — pâte, pads, ailettes, ventilateurs, châssis, rack, HVAC — vous obtenez des températures plus élevées, du bridage et éventuellement de l’instabilité.
Faites ceci ensuite, dans l’ordre :
- Arrêtez de deviner : vérifiez les raisons de bridage et les bons capteurs (cœur, hotspot, jonction mémoire).
- Obtenez de la stabilité avec un cap de puissance : testez une réduction de 10–20% et mesurez l’impact sur le débit.
- Rendez le flux d’air ennuyeux et correct : nettoyez, débloquez, shridez, et validez la température d’admission là où le GPU respire réellement.
- Baselinez tout : enregistrez températures/power/fréquences à l’état stable pour détecter la dérive avant qu’elle ne vous génère des pages.
- Et seulement ensuite, faites le travail invasif : repaste/re‑pad pendant une fenêtre de maintenance, avec matériaux corrects et procédure reproductible.
La chaleur n’est pas une faute morale. C’est de la comptabilité. Votre travail est d’équilibrer les comptes : watts entrants, chaleur sortante, performance délivrée, pannes évitées.