Limites de puissance et Boost : pourquoi votre GPU agit comme s’il avait sa propre volonté

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

Cet article vous a aidé ?

Vous avez acheté un GPU qui annonce « jusqu’à » une fréquence Boost héroïque. Puis vous lancez une charge réelle, regardez les fréquences osciller comme un métronome sous caféine, et votre débit varie de « correct » à « pourquoi je paie pour ça ». Bienvenue dans les performances GPU modernes : c’est négocié, pas garanti.

En production, ce n’est pas une curiosité de geek. Les plafonds de puissance, la thermique et les gouverneurs de Boost décident si vous respectez votre SLA, ratez une fenêtre de batch, ou passez votre week-end à prouver aux finances que « rien n’a changé » est un mensonge.

Le vrai contrat : « jusqu’à » fait beaucoup de travail

La plupart des gens considèrent un GPU comme un moteur à fréquence fixe : vous achetez un modèle, vous obtenez une vitesse. Mais les GPU modernes se comportent plutôt comme une flotte de petits gouverneurs en négociation avec la physique et le firmware. La fréquence Boost annoncée est un plafond, pas une promesse, et la distance entre « plafond » et « réalité » est décidée par une pile de limites :

Limite de puissance (W) : le budget que la carte est autorisée à consommer.
Limite de tension (V) : ce que le silicium et les VRM tolèrent à cet instant.
Limite thermique (°C) : ce que le refroidissement peut dissiper et l’agressivité du firmware pour se protéger.
Limites de courant/VRM : la réalité électrique de la carte, souvent invisible sauf avec les outils du fournisseur.
Caractéristiques de la charge de travail : différents kernels sollicitent différentes parties de la puce ; « 100% d’utilisation » n’est pas une seule chose.

Donc votre GPU n’a pas une volonté propre. Il a des contraintes. Sauf que ces contraintes changent dans le temps, et la boucle de contrôle réagit plus vite que vos tableaux de bord de monitoring.

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

Les Boosts sont devenus courants parce que les fréquences fixes laissaient de l’efficacité sur la table. Le silicium varie ; la puissance et la thermique varient ; le contrôle dynamique vend de meilleures performances « typiques ».
GPU Boost de NVIDIA (ère Kepler) a rendu les fréquences opportunistes. Au lieu d’« une seule fréquence », vous avez une plage de fréquences modulée par la marge disponible.
Les GPU datacenter n’ont pas échappé au Boost ; ils l’ont juste enveloppé dans une politique. Les plafonds de puissance, le mode persistence et les application clocks existent parce que les opérateurs voulaient de la prévisibilité.
Les power viruses sont réels. Certains mélanges d’instructions peuvent tirer une puissance disproportionnée ; les fournisseurs règlent les gouverneurs en partie pour survivre aux charges pires cas.
Le slot PCIe et les connecteurs 8 broches sont des contrats d’alimentation physiques. Les partenaires de cartes ne peuvent pas juste « envoyer la sauce » sans respecter ce que les connecteurs et pistes peuvent livrer en toute sécurité.
Le « TDP » n’est pas une unité universelle de vérité. C’est une cible de conception et un raccourci marketing ; ce qui compte en exploitation, c’est la puissance réelle de la carte et le comportement soutenu.
La température de la mémoire est devenue un problème majeur avec le GDDR6X et les empilements HBM denses. Votre cœur peut être heureux tandis que la mémoire chauffe silencieusement et déclenche un throttling.
Les courbes de ventilateurs sont passées d’objectifs acoustiques à objectifs de fiabilité. Beaucoup de profils « silencieux » laissent se développer des points chauds ; les datacenters préfèrent un flux d’air ennuyeux plutôt que du bruit agréable.

Le Boost n’est pas magique ; c’est une boucle de contrôle

Le comportement du Boost est un contrôleur en rétroaction. Le GPU mesure un ensemble de capteurs — consommation, températures, rails de tension, parfois le courant inféré — et choisit l’état de performance le plus élevé et stable dans les limites. Ce choix est réévalué en continu. Si vous attendez que la fréquence soit une ligne droite, vous attendez qu’un thermostat soit un interrupteur.

Ce que le Boost cherche à optimiser

L’algorithme de Boost essaie généralement de maximiser la performance tout en respectant :

la limite de puissance configurée,
la(les) cible(s) thermique(s),
les marges de stabilité tension/fréquence,
les contraintes de sécurité de la carte (températures VRM, limites de courant),
et parfois des règles acoustiques via les courbes de ventilateurs.

Si votre charge est courte et en rafales, le Boost montera en pointe. Si elle est longue et soutenue, le Boost se stabilisera. La première minute peut sembler magnifique. Les 30 minutes suivantes disent la vérité.

Une citation pour rester honnête

Idée paraphrasée (attribuée à W. Edwards Deming) : « Vous ne pouvez pas gérer ce que vous ne mesurez pas. » En terre de GPU : vous ne pouvez pas régler ce que vous ne pouvez pas attribuer.

Deux types de « ça a ralenti »

Il existe deux grands modes d’échec qui sont souvent confondus :

Throttling des fréquences : le GPU réduit intentionnellement la fréquence en raison de contraintes de puissance/thermie/tension.
Famine du pipeline : le GPU pourrait tourner plus vite, mais il attend la mémoire, des transferts PCIe, la planification CPU, le disque ou le réseau. Cela apparaît souvent comme une « faible utilisation » et pousse à chasser la mauvaise cause.

Règle sèchement drôle : un GPU à 99% d’utilisation peut quand même s’ennuyer ; il s’ennuie juste très régulièrement.

La pile des limites : puissance, tension, température et « réalité de la carte »

Limite de puissance : le gros bouton évident qui cache des bords tranchants

La limite de puissance est le concept le plus simple : plafonner la puissance de la carte à X watts. Mais elle interagit avec tout le reste. Si vous plafonnez la puissance trop bas, la fréquence chute pour rester dans le budget. Si vous la montez, vous pouvez obtenir plus de performance — jusqu’à ce que la thermique ou la stabilité de tension devienne le nouveau limiteur. En pratique, vous choisissez quel limiteur vous voulez atteindre en premier.

En production, les plafonds de puissance sont souvent des décisions politiques : « nous avons 2,4 kW par serveur », « nous avons besoin de N GPU par rack », « nous ne pouvons pas faire sauter les disjoncteurs pendant les batchs ». Ce sont des contraintes légitimes. L’erreur est d’attendre la même enveloppe de performance après avoir changé la physique.

Thermique : pas seulement la « température GPU », mais les points chauds et la mémoire

La plupart des gens vérifient la « température GPU » et passent à autre chose. C’est comme vérifier le thermostat du hall et déclarer le bâtiment entier sain. Les cartes modernes ont des hotspots (température de jonction), des températures mémoire, des températures VRM, et parfois des capteurs séparés pour différentes parties du package. Le cœur peut indiquer 70°C tandis qu’un point chaud atteint le seuil de throttling.

Aussi : le refroidissement est un système. Le flux d’air du boîtier, les filtres à poussière, les courbes de ventilateurs, les pads thermiques et la température d’entrée du rack importent tous. Votre GPU ne voit pas votre bon de commande. Il voit de la chaleur.

Tension et qualité du silicium : pourquoi deux GPU « identiques » se comportent différemment

Même au sein d’un seul SKU, les puces varient. Un GPU atteint une fréquence donnée à une tension plus faible ; un autre en a besoin de plus. Plus de tension signifie plus de puissance. Plus de puissance signifie plus de chaleur. Ainsi deux cartes réglées sur la même limite de puissance peuvent atteindre des fréquences d’équilibre différentes. Ce n’est pas « défectueux ». C’est la réalité du binning qui fuit dans vos graphiques.

Limites de la carte : VRM, connecteurs et garde-fous du firmware

Le die GPU n’est qu’une partie de l’histoire. Les régulateurs de tension de la carte (VRM) et le chemin d’alimentation ont des limites. Quand les VRM chauffent, certaines cartes réduisent la puissance ou la fréquence pour se protéger. Vous n’obtiendrez pas forcément une alerte claire. Vous constaterez une baisse « mystérieuse » de performance après 10–20 minutes.

Et oui, le firmware de votre GPU est volontairement conservateur. L’alternative, c’est un service garantie qui ne dort plus.

Pourquoi les fréquences et performances fluctuent (même quand vous jurez que rien n’a changé)

1) Changements de phase de la charge

Les jobs d’entraînement et les pipelines de rendu ont des phases : chargement des données, augmentation, calcul, synchronisation. Certaines phases sont intensives en calcul et atteignent les limites de puissance. D’autres sont intensives en mémoire et atteignent la bande passante. D’autres encore sont liées au CPU et laissent le GPU attendre. Si vous tracez les fréquences sans les corréler à l’activité des kernels ou à l’utilisation, vous interpréterez un comportement normal de phase comme un « problème ».

2) Température ambiante et variation de l’air d’entrée

Les datacenters ne sont pas des utopies thermodynamiques. Quelques degrés d’air d’entrée plus chaud peuvent faire la différence entre tenir un bin de boost et atteindre une cible thermique. Si votre rack est près d’un flux de retour ou d’une fuite d’allée chaude, votre GPU ralentira « au hasard » lors des pics de charge du bâtiment.

3) Politique de courbe de ventilateur (acoustique vs performance)

Les cartes grand public privilégient souvent le silence. Le silence est agréable jusqu’à ce qu’il devienne une stratégie de throttling. En serveur, vous voulez généralement le contraire : un refroidissement agressif et prévisible pour que la performance en régime permanent soit stable. Si vous tenez à traverser davantage de travail, définissez une politique de ventilateur qui vous rendra impopulaire dans les bureaux ouverts.

4) L’application de la limite de puissance est moyennée, pas instantanée

Les plafonds de puissance sont typiquement appliqués sur un intervalle de contrôle. Les courtes pointes peuvent dépasser puis être « remboursées » par une baisse. Cela peut créer des oscillations : la fréquence monte, la puissance dépasse, le gouverneur recule, et ainsi de suite. Vous verrez cela comme des fréquences saccadées et des temps d’image inégaux ou une variance du temps par étape.

5) Domaines d’alimentation partagés et contention multi-GPU

Dans un serveur dense, plusieurs GPU partagent la capacité PSU, parfois les zones de refroidissement, et partagent toujours la réalité thermique de l’installation. Un GPU qui chauffe le châssis peut dégrader ses voisins. De plus, « même configuration serveur » n’est pas la même chose que « même flux d’air », surtout si le ventilateur d’un GPU est légèrement moins efficace ou si un carénage est mal positionné.

6) Mises à jour des pilotes et du firmware

Les pilotes peuvent changer le comportement du Boost, le reporting de puissance et les politiques thermiques. Les mises à jour firmware peuvent modifier les tables de puissance. Si vous traitez les pilotes comme « juste du logiciel », vous serez surpris. Les pilotes font partie du système de contrôle.

Blague courte #1 : Une mise à jour de pilote, c’est comme une mise à niveau gratuite des performances — jusqu’à ce que ce soit une dégradation des performances gratuite avec de meilleures notes de version.

Guide de diagnostic rapide

Si la performance est incohérente, ne commencez pas par « tuner ». Commencez par l’attribution. C’est le chemin le plus court que j’ai trouvé qui fonctionne sous pression de pager.

Première étape : déterminez si vous êtes lié par le calcul, la puissance ou par attente

Vérifiez l’utilisation, les fréquences et la puissance pendant la période lente. Si l’utilisation est élevée et la puissance proche de la limite, vous êtes limité par la puissance. Si l’utilisation est élevée et la température proche de la cible, vous êtes limité thermiquement. Si l’utilisation est faible, vous attendez probablement autre chose.
Comparez la télémétrie d’un « bon run » vs un « mauvais run » sur le même hôte si possible. Cherchez ce qui a changé : consommation, températures, compteurs d’erreurs, largeur du lien PCIe, temps CPU volé, débit disque.
Identifiez le motif du limiteur (puissance vs thermique vs fiabilité). Sur NVIDIA, cela mappe souvent à « PerfCap Reason ». Sur AMD, vous l’inférerez depuis les capteurs SMI et le comportement des fréquences.

Deuxième étape : validez rapidement la couche physique

Le flux d’air du châssis est-il correct ? RPM des ventilateurs, température d’entrée, poussière, carénages, panneaux de remplissage. Les problèmes de refroidissement se déguisent en « performance aléatoire ».
L’alimentation/entrée PSU est-elle stable ? Les plafonds de puissance au niveau serveur peuvent bridder les GPU sans vous prévenir poliment.
Le lien PCIe est-il sain ? Un lien rétrogradé en x8 ou Gen3 peut pénaliser certaines charges et causer des blocages étranges.

Troisième étape : vérifiez les politiques logicielles et la planification

Paramètres de gestion de la puissance (persistence, application clocks, power cap). Les mauvaises configurations sont fréquentes, surtout après des images système ou des changements d’orchestration.
Contraintes de conteneur/VM (partitions MIG, cgroups, limites des device plugins). Parfois vous « perdez des performances » parce que vous avez reçu une tranche différente du matériel.
Interactions thermiques/puissance avec d’autres locataires sur le même hôte. Les voisins bruyants existent aussi en physique.

Tâches pratiques : commandes, sorties et ce que signifie la sortie

Voici des tâches réelles que vous pouvez exécuter aujourd’hui sur des hôtes Linux. Chaque tâche inclut (1) la commande, (2) une sortie représentative, et (3) la décision à prendre en fonction de celle-ci. L’objectif est opérationnel : isoler le limiteur, puis choisir la correction la moins risquée.

Task 1: Snapshot de la puissance GPU, fréquences, utilisation (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,uuid,pstate,clocks.sm,clocks.mem,temperature.gpu,power.draw,power.limit,utilization.gpu --format=csv
name, uuid, pstate, clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, power.draw [W], power.limit [W], utilization.gpu [%]
NVIDIA A10, GPU-6b7..., P0, 1680, 6251, 74, 142.31, 150.00, 98

Signification : Vous êtes proche de la limite de puissance (142/150 W) à forte utilisation en P0. Si la performance est faible, vous êtes probablement limité par la puissance, pas « pilote cassé ».

Décision : Si la thermique est correcte et que le budget PSU le permet, augmentez légèrement la limite de puissance (ou cessez d’attendre les fréquences maximales sous un plafond serré). Si la limite est imposée par une politique, concentrez-vous sur le perf-per-watt (undervolt, planification des charges, ou fusion de kernels).

Task 2: Identifier pourquoi le GPU bride la performance (PerfCap reason)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============

Performance State                      : P0
Clocks Throttle Reasons
    Idle                               : Not Active
    Applications Clocks Setting         : Not Active
    SW Power Cap                        : Not Active
    HW Slowdown                         : Not Active
    HW Thermal Slowdown                 : Not Active
    HW Power Brake Slowdown             : Not Active
    Sync Boost                          : Not Active
    SW Thermal Slowdown                 : Not Active
    Display Clock Setting               : Not Active

Signification : Aucune raison de throttling n’est active pour l’instant. Si vous observez toujours une faible performance, le goulot d’étranglement n’est probablement pas un throttle dur ; vous êtes peut-être limité par la mémoire, le CPU ou l’I/O.

Décision : Arrêtez de « réparer les fréquences ». Passez au profiling (décomposition de l’utilisation, trafic PCIe, saturation CPU) et vérifiez le pipeline de données.

Task 3: Surveiller le jitter de puissance/fréquence dans le temps (rapide et sale)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,power.draw,clocks.sm,temperature.gpu,utilization.gpu --format=csv -l 1 | head -n 8
timestamp, power.draw [W], clocks.sm [MHz], temperature.gpu, utilization.gpu [%]
2026/01/13 09:21:01, 148.22, 1710, 78, 99
2026/01/13 09:21:02, 149.87, 1695, 79, 99
2026/01/13 09:21:03, 150.02, 1665, 80, 99
2026/01/13 09:21:04, 149.95, 1635, 81, 99
2026/01/13 09:21:05, 149.90, 1605, 82, 99
2026/01/13 09:21:06, 149.88, 1590, 83, 99

Signification : La puissance est plafonnée tandis que la température monte ; les fréquences descendent par paliers. C’est le comportement classique « limite de puissance + thermique croissante ».

Décision : Améliorez le refroidissement ou réduisez la consommation par unité de travail (undervolt ou optimisation des kernels). Augmenter la limite de puissance n’aidera pas si vous approchez aussi des cibles thermiques.

Task 4: Vérifier la limite de puissance configurée vs min/max supportés (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d POWER | sed -n '1,120p'
Power Readings
    Power Management                    : Supported
    Power Draw                          : 142.31 W
    Power Limit                         : 150.00 W
    Default Power Limit                 : 150.00 W
    Enforced Power Limit                : 150.00 W
    Min Power Limit                     : 60.00 W
    Max Power Limit                     : 180.00 W

Signification : La carte peut aller jusqu’à 180 W, mais vous êtes plafonné à 150 W (par défaut). Si vous attendiez plus de débit, votre attente est mal alignée avec la politique configurée.

Décision : Si votre rack/serveur supporte cela en alimentation et refroidissement, augmentez à une valeur testée. Sinon, optimisez pour l’efficacité et acceptez des fréquences plus basses.

Task 5: Définir une limite de puissance (NVIDIA) et vérifier qu’elle est appliquée

cr0x@server:~$ sudo nvidia-smi -pl 170
Power limit for GPU 00000000:65:00.0 was set to 170.00 W from 150.00 W.

cr0x@server:~$ nvidia-smi --query-gpu=power.limit,power.draw --format=csv
power.limit [W], power.draw [W]
170.00, 156.04

Signification : La nouvelle limite est appliquée. Si les fréquences augmentent et que la thermique reste contrôlée, vous avez acheté des performances avec des watts.

Décision : Lancez un test long et stable. Si la performance s’améliore mais que le taux d’erreurs augmente ou que la marge thermique disparaît, revenez en arrière et poursuivez une optimisation plus sûre (undervolt, flux d’air ou ordonnancement).

Task 6: Vérifier largeur/vitesse du lien PCIe (NVIDIA via nvidia-smi)

cr0x@server:~$ nvidia-smi -q -d PCI | sed -n '1,140p'
PCI
    Bus                               : 00000000:65:00.0
    PCIe Generation
        Max                           : 4
        Current                       : 3
    Link Width
        Max                           : 16x
        Current                       : 8x

Signification : Vous attendiez Gen4 x16 mais vous tournez en Gen3 x8. Cela peut écraser les charges lourdes en transfert de données et causer une « sous-utilisation GPU » qui ressemble à un throttling.

Décision : Vérifiez les paramètres BIOS, le bon enfichage du riser, la bifurcation des lanes, et si un autre périphérique a volé des lanes. Réparez le PCIe avant de toucher aux fréquences.

Task 7: Confirmer le driver kernel et le mode persistence (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=driver_version,persistence_mode --format=csv
driver_version, persistence_mode
550.54.14, Disabled

Signification : Le mode persistence est désactivé. Cela peut ajouter de la latence et provoquer du churn de clock/pstate entre les jobs, surtout pour les tâches de courte durée.

Décision : Sur des nœuds de calcul dédiés, activez le mode persistence pour réduire la variabilité. Sur des postes partagés, pesez les compromis.

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:65:00.0.

Task 8: Forcer les application clocks (là où c’est supporté) pour la prévisibilité

cr0x@server:~$ nvidia-smi -q -d SUPPORTED_CLOCKS | sed -n '1,80p'
Supported Clocks
    Memory                             : 6251 MHz
        Graphics                       : 1710 MHz
        Graphics                       : 1680 MHz
        Graphics                       : 1650 MHz

cr0x@server:~$ sudo nvidia-smi -ac 6251,1680
Applications clocks set to "(MEM 6251, SM 1680)" for GPU 00000000:65:00.0

Signification : Vous avez troqué le Boost opportuniste contre des fréquences stables (dans les contraintes de puissance/thermique). Cela réduit le jitter entre exécutions pour de nombreux workloads batch.

Décision : Utilisez-le pour les jobs de production qui privilégient la prévisibilité plutôt que le pic maximal. Validez la thermique et les taux d’erreur.

Task 9: Vérifier les erreurs ECC corrélées au throttling ou aux retries

cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
ECC Mode
    Current ECC                        : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory              : 0
        Double Bit
            Device Memory              : 0
    Aggregate
        Single Bit
            Device Memory              : 12
        Double Bit
            Device Memory              : 0

Signification : Vous avez eu des erreurs corrigées historiquement. Ce n’est pas nécessairement fatal, mais cela peut se corréler avec une thermique marginale, du matériel vieillissant ou un tuning trop agressif.

Décision : Si les erreurs augmentent pendant les périodes de forte puissance/thermique, réduisez les fréquences/puissance, améliorez le refroidissement et envisagez des contrôles santé hardware ou une politique RMA.

Task 10: Vérifier clocks/puissance/températures GPU AMD (outils ROCm)

cr0x@server:~$ rocm-smi --showtemp --showpower --showclocks --showuse
===================== ROCm System Management Interface =====================
GPU  Temp   AvgPwr  SCLK     MCLK     GPU%  
0    79.0c  262.0W  1720Mhz  1200Mhz  97%

Signification : Forte utilisation, forte puissance, et températures dans les hauts 70s. Si les fréquences dérivent vers le bas avec le temps, vous approchez probablement d’une limite thermique ou de puissance.

Décision : Vérifiez les températures des hotspots/mémoire si disponibles, puis ajustez la politique ventilateur/puissance ou améliorez le flux d’air du châssis.

Task 11: Valider la pression CPU et la planification (ne pas blâmer le GPU pour des problèmes CPU)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

09:24:01     CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %idle
09:24:02     all   62.10    0.00   12.55    8.31   0.00    1.22    0.00  15.82
09:24:02      7   98.00    0.00    1.00    0.00   0.00    0.00    0.00   1.00
09:24:02     19   97.00    0.00    2.00    0.00   0.00    0.00    0.00   1.00

Signification : Certains CPUs sont proches de 100%. Si votre pipeline est CPU-intensif (préparation des données, compression, augmentation), le GPU peut être affamé et montrer des baisses d’utilisation périodiques.

Décision : Augmentez l’allocation CPU, épinglez les threads de manière sensée, réduisez le travail CPU par échantillon, ou déplacez le prétraitement vers le GPU.

Task 12: Identifier les goulots d’I/O (stockage ou réseau) qui ressemblent à « le GPU ne booste pas »

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          41.12    0.00   10.44   18.90    0.00   29.54

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         220.0  35200.0     0.0    0.0    8.90   160.0     40.0   5120.0    3.20   2.10  92.0

Signification : Fort iowait et ~92% d’utilisation du dispositif. Votre chargeur de données peut affamer le GPU, causant des baisses d’utilisation et des fréquences moyennes plus faibles.

Décision : Corrigez l’I/O d’abord : mettez les datasets en cache local, augmentez prudemment le parallélisme de lecture, préfetch, utilisez des niveaux de stockage plus rapides, ou réduisez les lectures par étape.

Task 13: Détecter les problèmes thermiques via les capteurs système (ventilateurs et châssis)

cr0x@server:~$ sensors | sed -n '1,120p'
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +79.9°C  (low  =  -0.1°C, high = +84.8°C)

ipmi_si-isa-0000
Adapter: ISA adapter
System Fan1:  9800 RPM
System Fan2:  9600 RPM

Signification : Les températures système et NVMe sont élevées ; les ventilateurs tournent déjà à plein régime. Si les GPU throttlent, cela peut être le flux d’air du châssis ou la température d’entrée, pas « le GPU ».

Décision : Vérifiez le flux d’air du rack, les panneaux de remplissage, les filtres bouchés, et si le serveur aspire de l’air d’allée chaude.

Task 14: Vérifier le plafonnement de puissance au niveau serveur (IPMI)

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   980 Watts
    Minimum during sampling period:                740 Watts
    Maximum during sampling period:               1080 Watts
    Average power reading over sampling period:    945 Watts

Signification : La consommation instantanée du serveur est proche de ce que beaucoup de PSU/feeds de rack peuvent tolérer. Certaines plateformes imposent des plafonds ou un comportement de « power brake » quand elles approchent les limites.

Décision : Confirmez les politiques d’alimentation dans le BIOS/firmware. Si la plateforme freine la puissance sous charge, les ajustements au niveau GPU ne stabiliseront pas la performance avant d’avoir adressé le budget d’alimentation plateforme.

Task 15: S’assurer que personne n’a défini accidentellement une limite basse cachée (persistence et scripts de démarrage)

cr0x@server:~$ grep -R --line-number "nvidia-smi -pl" /etc /usr/local 2>/dev/null | head
/etc/systemd/system/gpu-tune.service:9:ExecStart=/usr/bin/nvidia-smi -pl 120

Signification : Il y a une unité systemd forçant un plafonnement à 120 W. Cela explique votre régression de performance « soudaine » après le provisioning.

Décision : Corrigez la source de vérité de la gestion de configuration. Ne « hotfixez » pas un seul hôte en espérant que cela reste corrigé.

Trois mini-histoires d’entreprise issues du terrain

Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse

Ils ont déployé un nouveau lot de nœuds GPU pour l’entraînement nocturne. Même SKU GPU, même version de pilote, même image de conteneur. La première semaine semblait correcte. Puis un mardi : les jobs ont commencé à rater le délai du matin, et l’intervenant a reçu des pages d’un dashboard qui ne comprenait que « débit en baisse ».

L’hypothèse initiale était charmante et humaine : « Le cluster est plus grand maintenant, donc ça doit être l’ordonnanceur. » Ils ont ajusté les règles de placement, déplacé des jobs entre nœuds, même redémarré quelques daemons. La performance restait incohérente. Certains nœuds étaient rapides. D’autres lents. Aucun motif, sauf que les lents étaient tous dans une même rangée de racks.

Un SRE sceptique a finalement tracé la puissance GPU et la température en fonction de la température d’entrée fournie par les capteurs de l’installation. La corrélation était grossière. Cette rangée de racks avait un air d’entrée légèrement plus chaud à cause d’une dalle mal positionnée et d’un passage non scellé près d’une découpe pour câbles. Les GPU ne tombaient pas en panne ; ils se protégeaient, s’établissant à une fréquence d’équilibre plus basse sous pression thermique.

La correction n’était pas un patch logiciel. C’était une réparation des installations plus une politique de ventilateur plus agressive sur ces nœuds. Après cela, les temps d’entraînement se sont stabilisés. L’action postmortem était douloureusement simple : « Arrêtez de supposer que des numéros de pièces identiques signifient des performances identiques in situ. »

Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux

Une équipe de perf voulait améliorer le perf-per-watt. Ils ont testé l’undervolt sur un petit ensemble de GPU, obtenu des résultats prometteurs, et l’ont intégré à leur image dorée. Le débit moyen était légèrement meilleur, et les graphiques de facture d’électricité étaient plus jolis. Tout le monde se sentait intelligent.

Puis les rares failures sont apparues. Pas immédiatement. Quelques semaines plus tard, certains jobs ont commencé à crasher avec des erreurs CUDA « illegal memory access ». Pas tous les jobs, pas tous les nœuds. Le pire genre de bug : intermittent, dépendant de la charge, et récalcitrant à la reproduction pendant les heures ouvrables.

La cause racine était un réglage d’undervolt stable pour leur benchmark mais marginal pour un autre mélange de kernels utilisé par une autre équipe. Le gouverneur de Boost choisissait occasionnellement un bin de fréquence plus élevé sous certaines conditions thermiques, et cette fréquence n’était pas stable à la tension réduite. L’« optimisation » avait discrètement réduit la marge de stabilité.

La correction fut de traiter l’undervolt comme tout autre changement avec rayon d’impact : profils par SKU, tests de soak plus longs, et gate aux workloads spécifiques. Ils ont gardé l’undervolt, mais ont cessé de prétendre que c’était un déjeuner gratuit. On peut échanger des watts contre de la fiabilité ; il faut juste le formaliser.

Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe exécutant de l’inférence GPU avait l’habitude d’une pratique qui paraissait old-school : chaque nœud subissait un « caractère thermique et puissance » de base dans le CI avant d’être admis au pool. Ce n’était pas glamour. C’était un test long qui produisait quelques graphiques et un label pass/fail.

Un jour, une livraison fournisseur est arrivée avec une petite révision de carte. Même nom de SKU, mêmes specs annoncées. Le test de caractérisation a signalé plusieurs nœuds : ils atteignaient les limites thermiques plus tôt et se stabilisaient à des fréquences plus basses sous charge soutenue. Rien n’était « cassé », mais l’enveloppe de performance était suffisamment différente pour impacter la planification de capacité.

Parce qu’ils l’ont détecté avant la production, ils ont ajusté le placement en rack (zones plus fraîches pour ces nœuds), mis à jour la politique de power cap, et évité de surengager la flotte d’inférence. Pas d’incident. Pas de page. Juste une note interne : « La nouvelle révision se comporte différemment ; planifier en conséquence. »

Il est difficile de célébrer des incidents qui n’arrivent pas, mais c’est littéralement le travail. Les pratiques ennuyeuses sont souvent les seules qui s’échelonnent.

Blague courte #2 : Le meilleur genre de panne est celle que vous évitez. Le second meilleur est celle qui arrive pendant vos vacances.

Erreurs fréquentes : symptôme → cause racine → correction

Cette section est lue par ceux qui ont déjà essayé trois « tweaks » et ont empiré la situation. De rien.

1) Symptom : « La fréquence Boost n’atteint jamais la valeur annoncée »

Cause racine : Le Boost annoncé est opportuniste et dépend de la marge ; vous êtes limité par la puissance ou la thermique, ou votre charge est suffisamment lourde pour déclencher des bins soutenus plus bas.
Correction : Mesurez les fréquences soutenues sous votre charge réelle ; alignez vos attentes. Améliorez le refroidissement, augmentez la limite de puissance (si sûr), ou utilisez des application clocks pour la prévisibilité.

2) Symptom : « La performance est bonne pendant 60 secondes, puis chute »

Cause racine : Soak thermique. Le radiateur, la mémoire, les VRM atteignent l’état permanent et déclenchent cibles thermiques ou protections VRM.
Correction : Exécutez des tests de 20–30 minutes ; corrigez le flux d’air, les courbes de ventilateur, refaites la pâte/pads thermiques si applicable, réduisez légèrement la limite de puissance pour éviter la saturation thermique.

3) Symptom : « Utilisation GPU faible ; fréquences basses ; ça doit être un throttling »

Cause racine : Le GPU attend — prétraitement CPU, goulot d’I/O, transfert PCIe, synchronisation, ou tailles de batch trop petites.
Correction : Vérifiez iowait, saturation CPU, lien PCIe, et recouvrement du pipeline. Optimisez l’entrée de données, augmentez la taille de batch si possible, et préfetch.

4) Symptom : « Même job, différents nœuds, variance 15–25% »

Cause racine : Zones de refroidissement différentes, qualité du silicium différente, plafonds de puissance différents, états PCIe différents, ou locataires de fond différents.
Correction : Standardisez : appliquez les limites de puissance via la gestion de configuration, validez le PCIe, caractérisez les nœuds, et isolez les voisins bruyants.

5) Symptom : « Après mise à jour du pilote, la consommation et les fréquences sont bizarres »

Cause racine : Le pilote/firmware a modifié les tables de Boost, l’interprétation des capteurs, ou les politiques par défaut (y compris le comportement des ventilateurs).
Correction : Traitez les mises à jour de pilotes comme des mises à jour de kernel : testez sur des canaris avec vos workloads réels, comparez la télémétrie et gardez des chemins de rollback.

6) Symptom : « Augmenter la limite de puissance n’a pas augmenté la performance »

Cause racine : Vous êtes limité thermiquement, par la bande passante mémoire, ou par la stabilité tension/fréquence.
Correction : Vérifiez les températures (y compris hotspots/mémoire si disponibles), améliorez le refroidissement, ou optimisez les accès mémoire. N’ajoutez pas des watts à un problème de chaleur.

7) Symptom : « Les fréquences oscillent chaque seconde ; le débit est saccadé »

Cause racine : Oscillation de la boucle de contrôle du power cap, boost transitoire agressif, ou un workload qui alterne rapidement entre calcul et attente.
Correction : Envisagez des application clocks, un power cap légèrement inférieur pour éviter les dépassements, lissez l’ordonnancement des workloads, et assurez un refroidissement stable.

8) Symptom : « Erreurs GPU ou plantages après undervolt/overclocking »

Cause racine : Marge de stabilité réduite ; le Boost sélectionne occasionnellement des points V/F instables ; les changements de température altèrent la stabilité.
Correction : Revenez au stock, puis réintroduisez les réglages avec des tests de soak et une surveillance des erreurs. En production, priorisez la correction sur le prestige.

Checklists / plan étape par étape (performance stable volontaire)

Checklist A : Établir une baseline fiable

Choisissez une charge représentative et soutenue (pas un benchmark de 30 secondes). Exécutez-la 20–30 minutes.
Collectez la télémétrie : consommation, limite de puissance, fréquences, température, utilisation, et toute raison de throttling.
Enregistrez l’environnement : température d’entrée, politique de ventilateur, modèle de châssis, version pilote, version firmware.
Documentez les plages attendues en régime permanent : « Puissance 145–155 W, temp 70–78°C, fréquences 1600–1700 MHz. »

Checklist B : Décidez ce que vous voulez réellement (pic vs prévisible)

Si vous avez besoin de la moindre latence tail ou d’une complétion de batch constante : préférez des application clocks fixes et des limites de puissance conservatrices.
Si vous avez besoin du débit maximal et pouvez tolérer la variabilité : laissez le Boost, mais imposez une marge thermique et évitez les undervolts marginaux.
Si vous voulez le meilleur perf-per-watt : ajustez les power caps et l’undervolt avec prudence, et validez la stabilité sous votre mix de kernels réel.

Checklist C : Séquence de tuning sûre (faites ceci, pas du bidouillage aléatoire)

Corrigez d’abord le flux d’air. Un environnement thermique stable rend chaque autre changement plus facile à raisonner.
Définissez/vérifiez la politique de limite de puissance (et assurez-vous qu’elle persiste au redémarrage).
Testez les application clocks si votre plateforme les supporte et si votre workload bénéficie de la stabilité.
Ensuite seulement, envisagez l’undervolt, avec des tests de soak et une surveillance des erreurs.
Relancez le workload de référence et comparez les métriques en régime permanent, pas la première minute.

Checklist D : Surveiller et alerter (parce que les surprises sont l’ennemi)

Consommation soutenue bloquée à la limite avec fréquences en chute : vous êtes power-limited ; la planification de capacité doit supposer cet état.
Température approchant la cible avec augmentation du RPM des ventilateurs : vous êtes près du plafond thermique ; un jour chaud peut causer une chute de performance.
Lien PCIe rétrogradé (Gen/largeur) : indique des problèmes d’enfichage/matériel ou une contention plateforme.
Erreurs ECC corrigées en hausse : peut être un avertissement précoce pour une marginalité hardware ou un tuning trop agressif.

FAQ

1) Pourquoi la fréquence de mon GPU change-t-elle même quand l’utilisation est à 100% ?

Parce que 100% d’utilisation ne signifie pas une densité de puissance constante. Différents kernels sollicitent différentes unités fonctionnelles, changeant la consommation et la thermique. Le gouverneur ajuste les fréquences pour rester dans les limites.

2) « Limite de puissance » est-ce la même chose que le TDP ?

Non. Le TDP est une cible de conception utilisée de façon inconsistante entre fournisseurs. La limite de puissance est une politique appliquée (souvent en watts) qui contraint directement l’algorithme de Boost. Opérationnellement, la limite de puissance est ce que vous pouvez contrôler et mesurer.

3) Si j’augmente la limite de puissance, la performance va-t-elle toujours s’améliorer ?

Non. Si vous êtes limité par la bande passante mémoire, augmenter la puissance n’aidera pas. Si vous êtes limité thermiquement, augmenter la puissance peut empirer la situation en vous poussant plus vite vers le throttling. Validez avec des tests soutenus.

4) Quelle est la manière la plus rapide de savoir si je suis power-limited ?

Vérifiez si power.draw est proche de power.limit pendant que l’utilisation est élevée et que les fréquences sont sous le maximum supporté. Sur NVIDIA, « PerfCap reason » ou les raisons de throttling peuvent le confirmer.

5) Pourquoi deux GPU identiques ont-ils des fréquences d’équilibre différentes ?

Variance du silicium (tension requise pour une fréquence donnée), différences mineures de refroidissement, différences de carte/VRM, et même la pression de montage peuvent causer des différences mesurables. Dans une flotte, considérez la performance comme une distribution, pas un seul nombre.

6) Dois-je verrouiller les application clocks en production ?

Si la prévisibilité compte et que votre plateforme le supporte, oui — souvent. Vous échangez le pic de performance pour la répétabilité. Pour des pipelines batch avec des deadlines, c’est généralement gagnant.

7) L’undervolt réduit-il la performance ?

Ça peut, mais souvent non si vous êtes power-limited. L’undervolt peut vous permettre de tenir des fréquences plus élevées sous le même cap de puissance. Le piège est la stabilité : il faut des tests de soak sous votre mix réel de kernels et surveiller les erreurs.

8) Pourquoi mon GPU est « froid » mais lent ?

Parce que vous pouvez être en attente du CPU, du stockage, du réseau ou des transferts PCIe. Un GPU froid avec faible utilisation est généralement sous-alimenté en données, pas throttlé. Corrigez le pipeline, pas la courbe de ventilateur.

9) La containerisation peut-elle affecter le comportement du Boost et de la puissance ?

Oui. Les conteneurs peuvent changer la disponibilité CPU, le comportement I/O et la concurrence des jobs, ce qui modifie le cycle de travail GPU. Aussi, les device plugins et le partitionnement (comme MIG) peuvent changer la tranche de matériel que vous obtenez.

10) Qu’est-ce que je devrais standardiser sur une flotte GPU ?

Versions pilote/firmware, politique de limite de puissance, mode persistence, politique ventilateur/flux d’air, et un test de caractérisation steady-state de base. La standardisation transforme « art » en opérations.

Conclusion : prochaines étapes qui réduisent vraiment les surprises

Si votre GPU se comporte comme s’il avait sa propre volonté, c’est parce que vous ne regardez que le chiffre en titre (la fréquence) et ignorez le contrat (les limites). Le Boost n’est pas une promesse ; c’est un algorithme best-effort qui négocie des watts et de la chaleur.

Faites ceci ensuite, dans cet ordre :

Mesurez le comportement soutenu sous des charges réelles (20–30 minutes), pas des benchmarks en rafale.
Attribuez le limiteur : puissance, thermique, ou « attente sur autre chose ».
Corrigez la couche physique : flux d’air, température d’entrée, santé du lien PCIe, politique d’alimentation serveur.
Choisissez une politique : fréquences prévisibles (application clocks) ou Boost opportuniste (avec marge thermique).
Affinez prudemment : power caps d’abord, undervolt en dernier, et seulement avec des tests de soak et surveillance d’erreurs.

Quand vous traitez les GPU comme des systèmes de production — gouvernés, contraints et observables — le « mystère » disparaît. Vous vous battrez toujours contre la physique. Mais au moins vous saurez de quel côté elle gagne.