Sous-tension des GPU : l’astuce silencieuse de performance que personne ne vous révèle

Ce qu’est réellement la sous-tension (et ce que ce n’est pas)

La sous-tension signifie faire fonctionner le GPU à une tension inférieure à la valeur par défaut du fabricant pour une fréquence donnée.
Bien faite, elle réduit la consommation et la chaleur tout en gardant les performances identiques — ou en les améliorant en évitant
les limitations thermiques et de puissance.

Ce que ce n’est pas :

• Ce n’est pas de l’underclocking : vous pouvez sous-tensionner tout en conservant des fréquences élevées. L’underclocking réduit la fréquence ; la sous-tension réduit la tension. Vous pouvez faire les deux, mais ne les confondez pas.
• Ce n’est pas un « overclocking gratuit » : vous optimisez le point de fonctionnement. Si vous voulez des scores de benchmark maximaux pour des captures d’écran, ce n’est pas la même approche.
• Ce n’est pas une promesse de garantie : certains fournisseurs considèrent les modifications de courbe comme du « tuning ». En datacenter, les power caps sont généralement plus sûrs que les bidouillages de courbe de tension.
• Ce n’est pas un réglage universel : deux GPU du même modèle peuvent avoir des qualités de silicium différentes. Vous ne copiez-collez pas un nombre de millivolts comme un manifeste Kubernetes.

Voici le modèle mental : vous essayez d’atteindre le genou de la courbe où chaque watt supplémentaire vous apporte très peu de performance.
Si vous opérez au-dessus de ce genou, vous payez pour de la chaleur.

Pourquoi ça marche : comportement de boost, limites de puissance et réalité thermique

Les GPU modernes ne tournent pas à une fréquence fixe. Ils poursuivent une cible mouvante limitée par au moins trois plafonds :
limite de puissance, limite de température et limite de fiabilité de la tension.
Le pilote/firmware réduira volontiers les fréquences pour se protéger. Votre charge n’a pas son mot à dire.

La puissance est la limite silencieuse de la performance

La consommation d’un GPU est approximativement proportionnelle à V² × f (tension au carré fois fréquence), plus les fuites.
Ce terme au carré explique pourquoi la sous-tension est si efficace. Rognez un peu la tension et vous réduisez souvent une part notable de la puissance,
ce qui abaisse la température, ce qui réduit les fuites, ce qui réduit encore la puissance. C’est une boucle de rétroaction positive, dans le bon sens.

Pourquoi « moins de tension » peut signifier « plus de vitesse »

Lorsque vous êtes limité par la puissance ou la thermique, le GPU booste jusqu’à toucher un plafond, puis il recule.
Si vous baissez la tension, la même fréquence coûte moins de watts. Cela signifie que le GPU peut soutenir des fréquences plus élevées plus longtemps avant
d’atteindre le plafond. Votre fréquence moyenne augmente. Votre temps réel diminue.

C’est pourquoi la sous-tension peut surpasser les réglages d’origine dans les charges soutenues :
rendus longs, époques d’entraînement, lots d’inférence, kernels de compilation, tout ce qui tourne pendant des minutes, pas des millisecondes.

Le throttling n’est pas un échec ; c’est un symptôme

En termes SRE, le throttling est de la contre-pression. C’est le GPU qui vous dit : « Je n’ai plus de budget : watts, thermique, ou les deux. »
La sous-tension augmente la marge en rendant chaque unité de travail moins coûteuse.

Une citation que les opérationnels apprennent à la dure :
idée paraphrasée : Tout échoue, tout le temps ; votre travail est de concevoir pour ça. — Werner Vogels

La sous-tension fait partie de la conception pour la réalité : la puissance et le refroidissement sont limités, et vos charges ne s’arrêtent pas poliment à 17h.

Faits et histoire : comment nous en sommes arrivés là

La sous-tension donne l’impression d’un tour moderne parce que l’on parle surtout d’overclocking. Mais elle existe depuis que le silicium
présente des variabilités et que les fabricants doivent livrer des pièces qui fonctionnent pour le pire cas plausible.

8 faits concrets qui rendent la sous-tension pertinente

1. Le DVFS (scaling dynamique tension/fréquence) a des décennies ; CPU et GPU cherchent depuis longtemps la « tension juste suffisante » pour la performance.
2. Les bins existent car les puces diffèrent : deux dies d’une même tranche peuvent nécessiter des tensions différentes pour la même fréquence. Les défauts doivent couvrir l’extrémité faible de la distribution.
3. Les algorithmes de type GPU Boost (noms variables selon les générations) ont rendu les fréquences opportunistes plutôt que fixes, faisant de la puissance et de la température les véritables gouverneurs.
4. L’alimentation est devenue plus complexe : les GPU modernes ont de nombreuses voies et des comportements transitoires agressifs ; les fabricants intègrent des marges pour survivre aux pics.
5. Les nœuds de fabrication ont rétréci, les fuites ont augmenté : aux géométries plus petites, les fuites et les points chauds sont devenus des parties majeures de l’histoire de la puissance, pas seulement la commutation.
6. Les datacenters ont commencé à se soucier des watts comme d’argent : parce que c’en est — CAPEX, OPEX et la capacité à caser plus de calculs sous la même enveloppe d’installation.
7. Le mobile a imposé une culture d’efficacité : les GPU de portables et les SoC ont normalisé l’idée que la gestion de la puissance est de la gestion de la performance.
8. La densité thermique est la nouvelle vitesse d’horloge : vous ne pouvez pas « mieux refroidir » indéfiniment ; le flux thermique et les limites acoustiques deviennent des contraintes dures.

Blague 1/2 : La sous-tension, c’est comme enfin corriger votre régime au lieu d’acheter une ceinture plus grande. C’est moins spectaculaire, mais votre futur vous enverra des cartes de remerciement.

Où la sous-tension aide (et où elle ne sert à rien)

Où elle brille

• Calcul soutenu : entraînement, inférence, rendu, transcodage, simulation scientifique. Tout ce qui tourne assez longtemps pour atteindre l’équilibre thermique.
• Acoustique et budgets thermiques : stations de travail en bureau, déploiements en périphérie, racks avec flux d’air contraint.
• Densité multi-GPU : lorsque plusieurs cartes partagent le flux d’air du châssis et que la « carte du milieu » vit toujours plus durement.
• Environnements à puissance limitée : colocation, circuits de labo, UPS partagé ou enveloppes de puissance strictes au niveau du rack.
• Prédictibilité : réduire le throttling réduit la variance run-to-run, ce qui compte dans les pipelines de production.

Où c’est une perte de temps

• Pipelines liés au CPU : si votre GPU attend des données ou le CPU, rogner des watts ne changera pas le débit.
• Entraînement lié à l’I/O : lectures lentes du dataset, goulots de décompression ou saturation du stockage en réseau.
• Charges de rafale critiques en latence : si la charge est courte et n’atteint jamais l’équilibre thermique, la sous-tension concerne surtout le bruit et la consommation, pas la vitesse.

Le but n’est pas « toujours sous-tensionner ». Le but est « arrêter de supposer que les paramètres d’usine sont optimaux pour vos contraintes ».
Les fournisseurs optimisent pour « fonctionne pour tout le monde », pas pour « meilleur pour vous ».

Mode d’emploi diagnostic rapide : trouver le goulot rapidement

Quand un job GPU est lent ou instable, les gens blâment immédiatement « le GPU ». C’est paresseux.
Diagnosez dans cet ordre pour éviter de passer une journée à régler quelque chose qui ne vous limitait pas.

Première étape : confirmer que le GPU est réellement occupé

• Vérifiez l’utilisation GPU et les fréquences pendant la charge.
• Si l’utilisation est faible, inspectez le CPU, l’I/O, le dataloader, le réseau ou l’ordonnancement.

Deuxième étape : vérifier le throttling (puissance, thermique, fiabilité)

• Cherchez des raisons de limite de puissance, des seuils de température atteints, ou des baisses de fréquence sous charge.
• Corrélez température, consommation et fréquence dans le temps.

Troisième étape : vérifier les « ennuis de datacenter »

• Largeur/vitesse du lien PCIe négociée incorrectement.
• Partitions MIG/vGPU limitant les ressources.
• Erreurs ECC ou événements Xid provoquant des retries ou des réinitialisations de contexte.
• Courbes de ventilateur ou flux d’air du châssis faisant throttler une carte plus tôt que d’autres.

Quatrième étape : optimiser pour l’efficacité, pas la bravoure

• Commencez par un power cap (simple, réversible, facilement auditable).
• Si nécessaire, ajustez la fréquence et la courbe tension/fréquence (plus risqué, plus variable).
• Testez la stabilité avec votre pattern de charge réel, pas seulement un test synthétique à fond.

Tâches pratiques avec commandes : mesurer, changer, vérifier, décider

Ce sont des tâches de terrain. Chacune inclut : une commande, ce que signifie une sortie typique, et la décision à prendre.
Les commandes supposent Linux avec les drivers NVIDIA installés lorsque pertinent.

Tâche 1 : Identifier les GPU et la baseline du pilote

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:12:04 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 RTX A5000              Off   | 00000000:3B:00.0  Off |                  N/A |
| 30%   67C    P2               188W / 230W|   8120MiB / 24576MiB |     92%      Default |
+-----------------------------------------+----------------------+----------------------+

Signification : Vous avez la baseline du pilote/CUDA, la consommation et le cap actuels, et l’utilisation.
Si vous ne pouvez pas reproduire des chiffres plus tard, commencez ici.

Décision : Notez la version du pilote et le modèle de GPU. Les résultats de tuning ne se généralisent pas aussi bien que beaucoup le pensent lors des changements de pilote.

Tâche 2 : Vérifier si le mode persistence aide ou nuit

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

Signification : Le mode persistence garde le contexte du pilote chaud ; il peut réduire la latence du premier job et prévenir des comportements étranges de clock/état de puissance.

Décision : Activez-le sur des nœuds de calcul dédiés. Sur des postes partagés, pondérez cela avec les politiques de consommation au repos.

Tâche 3 : Logger puissance, fréquences, température dans le temps (l’étape « arrêtez de deviner »)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,pstate,clocks.sm,clocks.mem,temperature.gpu,power.draw,power.limit,utilization.gpu --format=csv -l 2
timestamp, pstate, clocks.sm [MHz], clocks.mem [MHz], temperature.gpu, power.draw [W], power.limit [W], utilization.gpu [%]
2026/01/13 10:14:00, P2, 1785, 7001, 69, 192.34, 230.00, 94
2026/01/13 10:14:02, P2, 1740, 7001, 72, 201.11, 230.00, 95
2026/01/13 10:14:04, P2, 1650, 7001, 78, 229.85, 230.00, 96

Signification : Si les fréquences chutent alors que l’utilisation reste élevée et que la puissance est plafonnée, vous êtes limité par la puissance. Si la température monte et que les fréquences tombent avant d’atteindre la limite de puissance, vous êtes limité thermiquement.

Décision : Décidez si la sous-tension doit être implémentée d’abord comme un power cap (habituellement oui), ou si des travaux d’airflow/thermiques sont nécessaires.

Tâche 4 : Vérifier les raisons de throttling (la preuve évidente)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE
==============NVSMI LOG==============

Performance State                          : P2
Clocks Throttle 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
    SW Thermal Slowdown                     : Not Active
    Display Clock Setting                   : Not Active

Signification : « SW Power Cap: Active » signifie que le pilote applique une limite de puissance. Votre GPU veut booster plus haut mais est bloqué par les watts.

Décision : Le tuning du power cap est susceptible d’augmenter les fréquences soutenues si vous pouvez réduire les watts par MHz via des méthodes proches de la sous-tension (souvent via une limite de puissance plus basse et/ou une courbe de fréquence).

Tâche 5 : Inspecter les limites de puissance supportées et le cap par défaut

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

Power Readings
    Power Management                  : Supported
    Power Draw                        : 201.11 W
    Power Limit                       : 230.00 W
    Default Power Limit               : 230.00 W
    Enforced Power Limit              : 230.00 W
    Min Power Limit                   : 120.00 W
    Max Power Limit                   : 230.00 W

Signification : Vous pouvez régler entre 120W et 230W. Cette plage est votre levier sûr « power cap ».

Décision : Commencez par une réduction modeste (par ex., 230W → 200W) et mesurez le débit et les fréquences. Si les performances tiennent, continuez de réduire jusqu’à ce que ce ne soit plus le cas.

Tâche 6 : Appliquer un power cap (proxy de sous-tension le plus adapté à la production)

cr0x@server:~$ sudo nvidia-smi -i 0 -pl 200
Power limit for GPU 00000000:3B:00.0 was set to 200.00 W from 230.00 W.

Signification : Vous avez contraint la puissance maximale du GPU. Cela réduit souvent la tension et améliore automatiquement l’efficacité.

Décision : Relancez immédiatement votre charge et journalisez fréquences/utilisation. Si les fréquences deviennent plus stables (moins en dents de scie) et que la performance est égale ou meilleure, conservez le réglage.

Tâche 7 : Vérifier que les fréquences soutenues se sont améliorées (ou au moins cessé de se détériorer)

cr0x@server:~$ nvidia-smi --query-gpu=clocks.sm,power.draw,temperature.gpu,utilization.gpu --format=csv -l 2
clocks.sm [MHz], power.draw [W], temperature.gpu, utilization.gpu [%]
1800, 198.22, 70, 95
1800, 199.01, 71, 96
1800, 199.44, 71, 96

Signification : Des fréquences stables à une consommation plus faible sont l’objectif. Si le GPU passait auparavant de 1650–1800 MHz et qu’il reste maintenant à 1800 MHz, vous avez acheté du débit réel.

Décision : Gardez le cap s’il réduit la variance. La variance est une taxe sur la planification de capacité.

Tâche 8 : Vérifier la largeur et la vitesse du lien PCIe (éviter d’attribuer la faute à la puissance alors que c’est le bus)

cr0x@server:~$ nvidia-smi -q | sed -n '/PCI/,/GPU Link/p'
    PCI
        Bus                               : 0x3B
        Device                            : 0x00
        Domain                            : 0x0000
        Bus Id                            : 00000000:3B:00.0
        GPU Link Info
            PCIe Generation
                Max                       : 4
                Current                   : 1
            Link Width
                Max                       : 16x
                Current                   : 1x

Signification : Si vous voyez Gen1 x1 alors que vous attendiez Gen4 x16, votre charge peut être limitée par le PCIe, pas par la tension du GPU.

Décision : Corrigez le positionnement physique, les réglages du BIOS, les risers ou la bifurcation. Ne « sous-tensionnez pas pour réparer les performances » quand le bus est ralenti.

Tâche 9 : Confirmer que la charge est GPU-bound (rapide et sale)

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 2 -c 5
# gpu   pwr gtemp mtemp  sm   mem   enc   dec   mclk   pclk
# Idx     W     C     C   %     %     %     %   MHz    MHz
    0   199    71     -  96    42     0     0  7001   1800
    0   199    71     -  97    41     0     0  7001   1800
    0   198    71     -  96    41     0     0  7001   1800
    0   199    71     -  97    42     0     0  7001   1800
    0   199    72     -  96    42     0     0  7001   1800

Signification : « sm » proche de 100% suggère compute-bound. Si « sm » est bas tandis que le CPU est élevé ou que l’I/O est saturée, la sous-tension ne changera pas grand-chose.

Décision : Ne touchez au réglage de puissance GPU que si vous avez confirmé que le GPU est la ressource limitante du chemin critique.

Tâche 10 : Vérifier CPU, pression mémoire et goulots I/O (pour ne pas courir après des fantômes)

cr0x@server:~$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0      0 421032  52224 812340    0    0    12    34  812 1490 62 11 26  1  0
 9  0      0 418900  52224 811998    0    0    10    22  790 1522 64 10 25  1  0
12  1      0 120044  52180 812100    0    0  9020  1100  920 1801 55 12 16 17  0
10  2      0  98020  52000 812220    0    0 12010  2300  980 2102 48 10 12 30  0

Signification : Une « wa » croissante (attente I/O) et de grands « bi/bo » signifie que le CPU attend le disque. Votre GPU peut être affamé.

Décision : Corrigez le pipeline de données : bande passante du stockage, caching, threads du dataloader, prélecture, format du dataset. La sous-tension n’est pas un remède pour des disques lents.

Tâche 11 : Rechercher erreurs GPU et réinitialisations (stabilité avant la créativité)

cr0x@server:~$ sudo dmesg -T | egrep -i "NVRM|Xid|gpu" | tail -n 8
[Tue Jan 13 10:20:11 2026] NVRM: Xid (PCI:0000:3b:00): 31, Ch 0000007e, intr 00000000. MMU Fault
[Tue Jan 13 10:20:11 2026] NVRM: Xid (PCI:0000:3b:00): 13, Graphics Engine Exception
[Tue Jan 13 10:20:12 2026] NVRM: GPU 0000:3b:00.0: GPU has fallen off the bus.

Signification : Les erreurs Xid peuvent indiquer des bugs de pilote, des fréquences/tensions instables, une mauvaise signalisation PCIe, ou des problèmes d’alimentation. « Fallen off the bus » n’est pas une opportunité de tuning ; c’est un incident.

Décision : Rétablissez les réglages d’usine, vérifiez l’insertion matérielle/l’alimentation, envisagez un changement de pilote, puis retentez des power caps conservateurs.

Tâche 12 : Confirmer les compteurs ECC et erreurs mémoire quand disponibles

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

ECC Mode
    Current                            : Enabled
    Pending                            : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory              : 0
        Double Bit
            Device Memory              : 0
    Aggregate
        Single Bit
            Device Memory              : 2
        Double Bit
            Device Memory              : 0

Signification : Des corrections single-bit agrégées peuvent être normales sur de longues durées ; des pics ou des erreurs double-bit sont un problème. Des sous-tensions instables peuvent parfois faire ressortir des erreurs mémoire, selon l’architecture et les conditions.

Décision : Si les compteurs augmentent pendant le tuning, faites marche arrière. La corruption silencieuse est le pire type d’accélération.

Tâche 13 : Valider que votre power cap persiste réellement (ou qu’il ne persiste pas délibérément)

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

Signification : « Enforced » correspond à la configuration. S’il revient après reboot, c’est normal sauf si vous l’avez défini via un service au démarrage.

Décision : Décidez de la politique : tuning éphémère pour expérimentations vs tuning codifié via systemd pour la production.

Tâche 14 : Créer une petite unité systemd pour appliquer un power limit au démarrage

cr0x@server:~$ cat /etc/systemd/system/gpu-powercap.service
[Unit]
Description=Set NVIDIA GPU power limit
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -i 0 -pl 200

[Install]
WantedBy=multi-user.target

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl enable --now gpu-powercap.service
Created symlink /etc/systemd/system/multi-user.target.wants/gpu-powercap.service → /etc/systemd/system/gpu-powercap.service.

Signification : Vous avez opérationnalisé le tuning. Personne n’a besoin de se souvenir d’une étape manuelle à 2h du matin.

Décision : Utilisez cela pour des caps stables et conservateurs. N’appliquez pas automatiquement des offsets de courbe expérimentaux sur une flotte sans portes de validation.

Tâche 15 : Comparer la performance par watt (il vous faut une métrique comprise par la direction)

cr0x@server:~$ python3 - <<'PY'
import time, subprocess, statistics
def sample(n=10, interval=1):
    p=[]
    for _ in range(n):
        out=subprocess.check_output(["nvidia-smi","--query-gpu=power.draw","--format=csv,noheader,nounits"]).decode().strip()
        p.append(float(out.splitlines()[0]))
        time.sleep(interval)
    return statistics.mean(p), statistics.pstdev(p)
mean, sd = sample()
print(f"avg_power_w={mean:.2f} stdev_w={sd:.2f}")
PY
avg_power_w=199.12 stdev_w=0.63

Signification : Une puissance moyenne plus basse et un écart-type plus faible corrèlent typiquement avec des fréquences plus stables et moins d’événements de throttling.

Décision : Associez cela au débit de votre charge (images/sec, tokens/sec, samples/sec). Adoptez le tuning uniquement si le débit par watt s’améliore sans régressions de stabilité.

Méthodes : power caps, courbes tension/fréquence et « ne pas lutter contre le firmware »

Méthode A : Power cap d’abord (recommandé pour la production)

Fixer une limite de puissance inférieure est la façon la plus ennuyeuse de « sous-tensionner », et c’est pourquoi elle gagne en entreprise.
C’est auditable, réversible, et ça ne dépend pas autant de la loterie du silicium par carte que l’édition manuelle des courbes de tension.

Les power caps fonctionnent parce que le contrôleur interne du GPU choisira souvent un point de fonctionnement tension/fréquence inférieur pour rester sous le cap.
Vous n’éditez pas explicitement des millivolts, mais vous obtenez le même résultat : moins de watts pour un travail presque identique.

Approche pratique :

• Réduire par étapes (par ex. 10–15% à la fois).
• Exécuter la charge réelle suffisamment longtemps pour atteindre le saturation thermique (10–30 minutes minimum).
• Journaliser fréquences/power/temp ; enregistrer le débit.
• S’arrêter quand le débit chute sensiblement ou que les SLO de latence sont menacés.

Méthode B : Verrouillage de fréquence (parfois utile, parfois un piège)

Verrouiller les horloges GPU peut rendre la performance plus prévisible, utile pour l’inférence sensible à la latence.
Mais les verrouillages peuvent aussi forcer une tension plus élevée que nécessaire ou lutter contre l’algorithme de boost de façon négative.

Si vous verrouillez les fréquences, vous devez vérifier que la puissance et les températures ne grimpent pas et que vous ne déclenchez pas de problèmes de stabilité.
Prévisible c’est bien. Prévisible et chaud ne l’est pas.

Méthode C : Édition de la courbe tension/fréquence (puissant, à haute maintenance)

L’édition de courbe est la sous-tension de l’enthousiaste : choisissez une fréquence cible et forcez-la à un point de tension plus bas.
Elle peut offrir d’excellents résultats sur une station de travail unique où vous pouvez la surveiller.

Dans les flottes, l’édition de courbe pose deux problèmes :

• Variabilité par carte : une carte est stable à une tension donnée ; sa voisine ne l’est pas.
• Complexité opérationnelle : mises à jour du pilote, outils GUI et comportement au reboot peuvent casser les hypothèses. Votre file de tickets ne sera pas impressionnée.

Méthode D : L’option « ne rien toucher » qui aide quand même

Parfois, la meilleure sous-tension est d’améliorer le flux d’air pour que la carte ne reste pas toute la journée à la limite thermique.
Baisser la température réduit les fuites, ce qui est efficacement un gain d’efficacité « gratuit » sans toucher aux contrôles de tension.

Blague 2/2 : Le plus facile des undervolts, c’est dépoussiérer le filtre d’admission. C’est aussi la retouche de performance la moins à la mode, et c’est pour ça que ça marche.

Tests de stabilité sans perdre une semaine

Les échecs de sous-tension sont rarement polis. Ils apparaissent sous la forme d’un job qui plante à la sixième heure, d’une réinitialisation de pilote, ou d’un problème numérique subtil.
Vos tests doivent correspondre à la façon dont vous utilisez réellement le GPU.

Ce que « stable » signifie en production

• Pas de réinitialisations de pilote : pas d’averses Xid, pas de « fallen off the bus ».
• Pas de régressions de correction : les distributions de sortie restent cohérentes ; pas de NaN inexpliqués.
• Pas de dégradation de fréquence sur le long terme : la performance ne diminue pas lentement à mesure que la chaleur du châssis s’accumule.
• Queue de latence prévisible : p95/p99 ne doivent pas empirer à cause de throttling sporadique ou de retries.

Conception de tests qui respecte la réalité

Utilisez au moins deux patrons :

• État stable : charge constante pendant 30–60 minutes. Cela détecte les problèmes d’équilibre thermique.
• Cycles rafale + repos : le workload réel en production. Cela détecte les bugs de transition DVFS et les problèmes transitoires de puissance/tension.

Ce qu’il faut logger pendant les tests

• clocks.sm, clocks.mem
• power.draw, power.limit
• temperature.gpu (et hotspot si disponible via vos outils)
• utilization.gpu, usage mémoire
• dmesg pour Xid, logs applicatifs pour NaN ou retries

Critères d’acceptation défendables

• Débit dans ±1–2% de la baseline (ou amélioré) en charge stable.
• Pas d’augmentation des compteurs d’erreurs ; pas de nouvelles erreurs noyau/pilote.
• Baisse de la consommation moyenne et/ou de la température à débit égal.
• Réduction de la variance : moins de plongées de fréquence, distribution de latence resserrée.

Trois mini-récits d’entreprise issus du terrain

Récit 1 : L’incident causé par une fausse hypothèse (« les réglages d’usine sont sûrs »)

Une équipe a déployé de nouveaux nœuds GPU pour l’entraînement de modèles. Même fournisseur, même châssis, même image « approuvée ».
La seule différence était l’installation : une rangée plus chaude, un flux d’air légèrement pire, et une PDU qui travaillait plus près de sa limite.
Tout a passé des tests rapides.

Trois jours plus tard, les jobs ont commencé à échouer selon un schéma apparemment aléatoire. Un entraînement plantait à la fin d’une époque.
Un autre ralentissait sans cause claire. Les gens ont blâmé le framework, puis le dataset, puis le pilote.
Entre-temps, les métriques GPU racontaient une histoire ennuyeuse : consommation bloquée sur le cap, températures flirtant avec la limite thermique,
fréquences oscillant comme un métronome.

La mauvaise hypothèse était que « les défauts du fournisseur sont conservateurs ». Ils le sont pour la correction fonctionnelle à travers les environnements,
pas pour la stabilité de performance dans une baie encombrée à une température ambiante élevée. Les réglages par défaut supposent aussi que vous avez le refroidissement que la diapositive marketing du fournisseur imagine.

La correction fut embarrassante de simplicité : réduire légèrement la puissance et cesser de pousser la carte dans un coin où elle throttlait constamment.
Les plantages ont disparu. Le débit est devenu prévisible. L’équipe a appris la leçon opérationnelle : la stabilité n’est pas un réglage par défaut ; c’est un état réglé.

Récit 2 : L’optimisation qui a mal tourné (« on peut descendre plus bas, tout va bien »)

Un autre groupe a cherché l’efficacité parce que le prix de l’électricité était devenu un sujet. Ils ont piloté la sous-tension en abaissant agressivement
les limites de puissance et en appliquant des verrous de fréquence pour « garder la cohérence ». Les premiers benchmarks étaient excellents : moins de puissance, presque le même débit.
Quelqu’un a déclaré la victoire.

Puis l’inférence a commencé à montrer des pics rares de latence et des sorties parfois invalides — juste assez pour déclencher des retries en aval.
Les retries ont augmenté la charge. La charge a augmenté la température. La température a augmenté le throttling. Le throttling a augmenté la latence. Une boucle de rétroaction s’est formée, du mauvais type.
Rien n’a « échoué » bruyamment ; c’est juste devenu plus lent et plus cher.

Le retour de bâton est venu du fait d’avoir réglé uniquement pour le comportement moyen et d’avoir ignoré le risque de queue. En poussant trop près du bord de stabilité, ils ont augmenté le taux
d’erreurs corrigeables et de ralentissements transitoires. Le système a compensé avec des retries et des timeouts, rendant le service instable.

Le plan de réparation fut de reculer : assouplir le cap, enlever les verrous de fréquence, et adopter une politique « efficacité avec marge ».
Ils ont aussi ajouté un canari : un nœud avec le nouveau réglage, avec alertes sur la distribution de latence et les erreurs pilote. Le tuning final a quand même permis des économies,
mais ce n’était plus un sport à adrénaline.

Récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (« mesurer d’abord, changer ensuite »)

Une équipe plateforme gérait une flotte GPU mixte pour plusieurs lignes produits. Ils avaient un passé chargé avec du « tuning intelligent » :
scripts aléatoires, réglages non documentés, et outages le week-end.
Ils ont donc mis en place une politique terne : chaque changement GPU doit être lié à une métrique et validé sur un jeu de canaris avec rollback.

Quand ils ont exploré la sous-tension, ils n’ont pas commencé par toucher les courbes de tension. Ils ont commencé par logger :
distributions de consommation, raisons de throttling, et débit par job. Puis ils ont appliqué un changement : un power cap modéré, identique par modèle.
Ils ont utilisé une unité systemd pour l’appliquer et un tag dans leur inventaire pour suivre les nœuds réglés.

Un mois plus tard, une mise à jour du pilote a changé légèrement le comportement de boost. Sur les nœuds non réglés, la variance de performance a augmenté — certains jobs ralentissaient aux heures de pointe.
Sur les nœuds réglés, le power cap a agi comme un garde-fou : températures et fréquences restaient dans une enveloppe prévisible.
Les nœuds réglés sont devenus la baseline « connue bonne » lors de l’analyse d’incident.

La leçon n’était pas « les power caps sont magiques ». La leçon était que l’hygiène opérationnelle bat les actions héroïques.
La sous-tension, faite comme un changement contrôlé, devient une fonctionnalité de fiabilité, pas un hobby.

Erreurs courantes : symptôme → cause racine → correction

1) Les performances se sont immédiatement dégradées après la sous-tension

Symptôme : Le débit chute, les fréquences GPU sont plus basses qu’avant, l’utilisation reste élevée.

Cause racine : Power cap trop agressif ; vous avez poussé en dessous du genou et le GPU ne peut pas soutenir la fréquence cible.

Correction : Augmentez la limite de puissance par petits pas jusqu’à stabilisation des fréquences ; arrêtez-vous au meilleur point perf/watt, pas au chiffre le plus bas en watts.

2) Plantages aléatoires de jobs après des heures de fonctionnement « correct »

Symptôme : Longs runs d’entraînement échouent ; dmesg affiche des erreurs Xid ou réinitialisations GPU.

Cause racine : Courbe tension/fréquence trop optimiste pour cette carte particulière en conditions heat-soaked ; ou instabilité PSU/PCIe révélée sous transitoires.

Correction : Revenir aux réglages d’usine ou appliquer un power cap conservateur, retester en cas d’ambiance défavorable ; vérifier l’insertion PCIe et les câbles d’alimentation ; éviter le tuning par carte dans les flottes.

3) Moins de puissance, mais aucune amélioration de performance

Symptôme : Les watts baissent, mais le temps réel reste inchangé et l’utilisation GPU n’est pas saturée.

Cause racine : Goulot CPU, I/O ou réseau ; le GPU n’est pas la ressource limitante.

Correction : Profilez le pipeline : dataloader, bande passante stockage, décompression, threads CPU, PCIe. Réglez la couche qui compte.

4) Une carte dans un boîtier multi-GPU throttlle pendant que les autres non

Symptôme : Le GPU 2 est toujours plus chaud, fréquences plus basses, plus de flags de throttling.

Cause racine : Déséquilibre du flux d’air ; la carte du milieu recircule de l’air chaud ; courbes de ventilateur contraintes par le châssis.

Correction : Améliorez le flux d’air, réorganisez l’ordre des cartes si possible, ou appliquez des power caps par GPU pour que la carte la plus chaude cesse de se cuire.

5) Les réglages de « sous-tension » ne survivent pas au reboot

Symptôme : Après redémarrage, la limite de puissance est revenue par défaut.

Cause racine : Les power caps sont des réglages au runtime sauf si persistés via la gestion de service.

Correction : Utilisez une unité systemd (comme montré) ou votre outil de gestion de configuration pour imposer des limites connues au démarrage.

6) La queue de latence empire tandis que les moyennes semblent correctes

Symptôme : p99 de latence grimpe sous charge ; le débit moyen OK.

Cause racine : Réglage trop près du bord provoquant throttling intermittent ou retries ; les verrous de fréquence peuvent aggraver le comportement transitoire.

Correction : Reculer : augmenter légèrement le cap, enlever les verrous de fréquence, et régler pour réduire la variance. Surveillez les raisons de throttling et les logs d’erreur.

7) Les ventilateurs sont plus silencieux mais le GPU est toujours chaud

Symptôme : Moins de bruit, mais les températures restent proches de la limite, les fréquences oscillent.

Cause racine : Politique de courbe de ventilateur ou flux d’air du châssis limitant la capacité de refroidissement ; réduire la vitesse des ventilateurs masque le symptôme mais pas la contrainte.

Correction : Conservez la sous-tension/power cap, mais corrigez le flux d’air. Le silence est agréable ; la stabilité est requise.

Listes de contrôle / plan pas à pas

Pas à pas : sous-tension sûre pour la production via power caps

1. Ligne de base : enregistrez le modèle, la version du pilote, la limite de puissance par défaut et le débit de la charge.
2. Observer : journalisez fréquences, puissance, température et raisons de throttling pendant un run représentatif.
3. Confirmer le goulot : assurez-vous que l’utilisation GPU est élevée et que le throttling est présent (puissance/thermique).
4. Appliquer un cap modeste : réduisez la limite de puissance d’environ 10–15%.
5. Test de saturation thermique : exécutez la charge pendant 30–60 minutes ; journalisez les métriques.
6. Évaluer : comparez débit, variance, erreurs et températures.
7. Itérer : réduisez encore jusqu’à ce que la performance diminue ou que la queue de latence s’aggrave.
8. Codifier : implémentez un mécanisme d’application au démarrage (systemd/gestion de config).
9. Canari : déployez sur un sous-ensemble ; surveillez pendant une semaine avec les charges réelles.
10. Déploiement : étendez progressivement ; gardez le rollback trivial.

Pas à pas : tuning de courbe pour station de travail (hautement supervisé)

1. Commencez de toute façon par un power cap ; cela vous donne une baseline sûre.
2. Choisissez une fréquence soutenue que vous observez déjà sous charge.
3. Réduisez la tension progressivement tout en maintenant cette fréquence ; testez la stabilité en condition heat-soaked.
4. Arrêtez-vous au premier signe d’instabilité (erreurs, réinitialisations, NaN) et reculez.
5. Documentez le réglage par GPU, pas par modèle. Oui, c’est pénible. C’est la réalité.

Checklist opérationnelle : quoi surveiller en continu

• Consommation GPU et limite de puissance appliquée
• Raisons de throttling
• Température et comportement des ventilateurs (y compris hotspot si vous pouvez le collecter)
• Erreurs Xid / réinitialisations de pilote
• Distribution du débit des jobs et latence tail
• Compteurs d’erreurs ECC quand applicables

FAQ

1) La sous-tension est-elle sûre pour le GPU ?

Une tension plus basse est généralement moins stressante électriquement que des tensions plus élevées, mais « sûre » en opération signifie « stable et correcte ».
Une sous-tension instable peut faire planter des jobs ou corrompre des résultats. Utilisez d’abord des power caps conservateurs, puis validez la stabilité.

2) Pourquoi la sous-tension améliore-t-elle parfois la performance ?

Parce que vous réduisez la puissance et la chaleur, ce qui réduit le throttling. Le GPU peut soutenir des fréquences de boost plus longtemps dans les mêmes limites.
Les fréquences moyennes comptent plus que les fréquences maximales.

3) Dois-je sous-tensionner en éditant une courbe de tension ou simplement définir une limite de puissance ?

En production : commencez par un power cap. C’est plus simple, plus cohérent entre les cartes, et plus facile à automatiser et rollbacker.
L’édition de courbe convient mieux aux stations de travail mono-utilisateur où vous pouvez tester par carte.

4) Comment savoir si je suis limité par la puissance ou par la thermique ?

Regardez les raisons de throttling et corrélez les fréquences avec la consommation et la température. Si la consommation est bloquée au cap et que « SW Power Cap » est actif, c’est limité par la puissance.
Si la température atteint une limite et que « HW Thermal Slowdown » est actif, c’est limité thermiquement.

5) Quelle réduction de power cap raisonnable pour commencer ?

Environ 10–15% en dessous de la valeur par défaut est un point de départ pratique. Ensuite, mesurez. La bonne valeur dépend du modèle, du refroidissement et de la charge.
Le seul mauvais mouvement est de faire un grand saut et d’appeler ça du « tuning ».

6) La sous-tension réduira-t-elle la durée de vie du GPU ?

Des températures et une puissance plus basses aident généralement la longévité. Le risque plus grand est l’instabilité causant des réinitialisations et des perturbations opérationnelles, pas l’usure physique.
Gardez de la marge et surveillez les signaux d’erreur.

7) La sous-tension aide-t-elle les charges liées à la mémoire ?

Parfois. Si votre charge est limitée par la bande passante mémoire et que le GPU ne booste pas beaucoup les fréquences cœur, la sous-tension peut ne pas changer beaucoup le débit.
Elle peut néanmoins réduire la consommation et le bruit. N’attendez pas de miracles.

8) Puis-je appliquer les mêmes réglages de sous-tension à chaque GPU du même modèle ?

Pour les power caps, souvent oui dans une certaine mesure. Pour les éditions de courbe tension, non — la variance du silicium rend cela risqué.
Même les power caps devraient être testés en canari car le flux d’air du châssis et les conditions ambiantes varient par rack.

9) Comment la sous-tension interagit-elle avec l’ordonnancement multi-locataire ?

Les power caps peuvent améliorer l’équité en réduisant les emballements thermiques et en empêchant une carte chaude d’affecter négativement les voisines via un flux d’air partagé.
Mais si les locataires ont des attentes de performance différentes, il vous faut une politique : caps par file, par partition, ou par classe de nœud.

10) Quel est le signe le plus rapide que la sous-tension aide ?

Une réduction du phénomène de fréquence en dents de scie sous charge soutenue, une température plus basse, et un débit égal ou meilleur.
Si vos fréquences cessent de rebondir alors que l’utilisation reste élevée, vous avez généralement trouvé un meilleur point de fonctionnement.

Étapes suivantes

Si vous ne faites qu’une action : implémentez un power cap mesuré, pas une courbe de tension héroïque, et évaluez-le avec la télémétrie de charge réelle.
La sous-tension n’est pas un tour de fête ; c’est de l’ingénierie de capacité.

1. Établissez la baseline de votre charge : débit, fréquences, puissance, température, raisons de throttling.
2. Appliquez un power cap modéré et re-mesurez en conditions heat-soaked.
3. Arrêtez-vous quand la perf chute, la queue de latence s’aggrave ou des erreurs apparaissent.
4. Codifiez le réglage avec systemd/gestion de configuration, et déployez via des canaris.

Vous aurez au final des GPU qui tournent plus froids, plus silencieux, et souvent plus rapides là où ça compte : du travail soutenu et reproductible en production.
C’est le seul type de performance qui compte quand on a quitté les graphiques de benchmark.