Pilotes comme armes : comment le logiciel peut « changer » votre GPU

décembre 26, 2025 • février 3, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Vous redémarrez une machine et votre GPU « identique » est soudainement plus lent, plus chaud, moins stable, ou simplement… différent.
Le silicium n’a pas changé. C’est le pilote qui a changé. Et le pilote est la couche qui a des opinions : sur la puissance,
les fréquences, la mémoire, l’ordonnancement, la gestion des erreurs, voire sur les fonctionnalités disponibles aujourd’hui versus hier.

En production, une mise à jour du pilote GPU n’est pas « juste un patch ». C’est une réécriture comportementale du périphérique que vous pensez posséder.
Traitez-la comme une modification du contrat matériel. Parce que c’est exactement cela.

Ce que signifie que le logiciel « change » un GPU

Quand les ingénieurs disent « le pilote a changé mon GPU », ils ne veulent pas dire qu’il a recâblé des transistors.
Ils veulent dire que le pilote a changé le comportement observable du GPU—le contrat pratique :
à quelle vitesse il s’exécute, comment il planifie, comment il utilise la mémoire, comment il gère les erreurs, et comment il se bride sous pression thermique ou électrique.

Un GPU moderne est un accord négocié entre le matériel, le firmware, le module noyau, les bibliothèques en espace utilisateur, et parfois un démon
qui conserve l’état entre les processus. Différentes versions de pilote peuvent :

Modifier les limites de puissance par défaut et le comportement de boost.
Modifier les transitions d’état P (horloges à l’arrêt versus en calcul).
Modifier la gestion de la mémoire et le comportement d’éviction (surtout en cas de sursouscription).
Modifier l’équité d’ordonnancement entre contextes (MPS, MIG, time-slicing).
Activer ou désactiver des fonctionnalités (taille BAR, SR-IOV, resizable BAR, accès peer-to-peer).
Modifier la récupération d’erreur : ce qui devient une faute récupérable vs un GPU mort nécessitant un reset.
Modifier les heuristiques de sélection de noyaux de bibliothèques (cuDNN, cuBLAS) et les résultats d’autotuning.

Ce qui pique, c’est ceci : vous pouvez tout faire « correctement » dans votre code et voir quand même une variation de 20 % parce que le pilote a changé un paramètre par défaut.
Le deuxième point douloureux : le pilote a des raisons légitimes. Les pilotes récents corrigent des problèmes de correction, de sécurité et de conditions de concurrence.
Mais ils changent aussi le comportement, et le comportement est ce qui compte en production.

Remarque sur ce que le terme « pilote » inclut

On dit « pilote » par raccourci, mais vous devriez mentalement séparer :

Module noyau (Linux: nvidia.ko et alliés) : possède le périphérique, gère les interruptions, le mappage mémoire, la logique de reset.
Bibliothèques en espace utilisateur (runtime CUDA, ICD OpenCL, piles GL/Vulkan) : traduisent les appels d’API en travail GPU.
Firmware (sur la carte) : gère les tâches du microcontrôleur comme la gestion de puissance et parfois des primitives d’ordonnancement.
Stack de gestion (NVML, nvidia-smi, démon de persistance) : définit horloges, limites de puissance, mode compute, partitions MIG.

Chacun de ces éléments peut changer entre la « version A » et la « version B ». Parfois vous mettez à jour l’un et pas l’autre. C’est là que commence le spectacle.

Faits et histoire : comment nous sommes arrivés aux GPU façonnés par les pilotes

Voici quelques points de contexte concrets qui expliquent pourquoi les pilotes ont tant de levier aujourd’hui. Gardez-les en tête ; ils aident à diagnostiquer la réalité.

Les premiers GPU étaient à fonction fixe. À la fin des années 1990 et début 2000, les GPU exécutaient surtout des pipelines graphiques prédéfinis. Les pilotes étaient importants, mais « changer le GPU » signifiait corrections de bugs et ajustements de performance, pas de nouveaux comportements de calcul complets.
La programmabilité des shaders a déplacé la complexité vers les pilotes. Dès que les GPU sont devenus programmables (shaders), les pilotes ont commencé à faire des compilations agressives et des décisions d’ordonnancement. Vous avez gagné en performance… et en variabilité.
CUDA (2006) a fait des GPU des dispositifs de calcul généraux. Cela a augmenté les enjeux : la correction et la déterminisme ont commencé à entrer en concurrence avec le débit maximal. La politique du pilote est devenue partie intégrante des performances applicatives.
Les boost clocks ont transformé la fréquence en un bouton de politique logicielle. Le boost dynamique signifie que deux cartes « identiques » peuvent tourner à des fréquences différentes selon la thermique, la puissance et les heuristiques du pilote.
L’ECC sur certains GPU a introduit un compromis vitesse vs sécurité. Activer l’ECC peut réduire la mémoire utilisable et parfois les performances ; les pilotes contrôlent le reporting, le scrubbing et parfois les valeurs par défaut.
MPS puis MIG ont changé les sémantiques de partage. Le service multi-processus et le multi-instance GPU sont des moyens de partager un périphérique. Ils sont aussi de nouvelles façons d’avoir des voisins bruyants, du thrash de contextes, et des statistiques d’utilisation confuses.
Le resizable BAR et les grands mappages BAR ont modifié les voies CPU↔GPU. Selon la plateforme et le pilote, le CPU peut mapper plus de VRAM directement, changeant le comportement des transferts et les performances de certains workloads.
La sécurité est devenue une fonctionnalité du pilote, pas seulement du système d’exploitation. Isolation, protections mémoire et mitigations vivent dans la pile pilote. Certaines mitigations coûtent en performance ; d’autres corrigent des problèmes sérieux. Choisissez votre compromis puis documentez-le.

Les pilotes comme armes : la vraie surface d’attaque

« Arme » ne signifie pas toujours « malware ». En exploitation, « arme » signifie souvent « un levier qui peut ruiner votre SLO en silence ».
Les pilotes sont exactement ce levier parce qu’ils se situent sous votre application et au-dessus de votre matériel.

Armés par accident : des politiques qui ressemblent à une dérive matérielle

Les mises à jour de pilotes apportent souvent de nouveaux paramètres par défaut : courbes de boost différentes, nouvelles politiques de ventilateur, nouveaux allocateurs mémoire, nouvel ordonnancement.
Vous ne le remarquez pas avant que quelque chose qui tournait en P0 se retrouve en P2 sous la « même » charge,
ou que les copies mémoire régressent parce que le chemin IOMMU a changé.

La façon la plus facile de perdre une semaine est de supposer que « le matériel est stable ». Le matériel est stable. Le contrat ne l’est pas.

Armés volontairement : vous pousser dans un écosystème

Les fournisseurs ne sont pas des œuvres de charité. Les pilotes peuvent vous orienter vers certaines chaînes d’outils et vous éloigner d’autres :
dépréciations, verrouillage de fonctionnalités, versions « supportées », matrices de compatibilité qui vous punissent discrètement pour avoir mis à jour le mauvais composant.

Ce n’est pas automatiquement malveillant. C’est simplement l’évolution des stacks commerciaux. Mais en production, traitez cela comme un gradient d’incitations.
Décidez si vous suivez ce gradient ou si vous vous isolez avec des versions épinglées et des déploiements contrôlés.

Armés par des adversaires : chaîne d’approvisionnement et privilèges

Les pilotes GPU s’exécutent avec de hauts privilèges. Ils touchent l’espace noyau, le DMA, le mappage mémoire. Si vous raisonnez comme un attaquant,
le pilote est un endroit spectaculaire où chercher.

Votre réponse ne doit pas être panique. Votre réponse doit être : paranoïa mesurée.
Paquets signés, dépôts contrôlés, secure boot quand possible, et un plan de rollback exécutable à 3 h du matin.

Comment les pilotes modifient performance et fiabilité

1) Horloges : votre GPU « identique » à une fréquence différente

Le comportement des horloges est une politique. Les pilotes lisent la température, la consommation, le type de charge, et parfois les réglages « application clocks ».
Si votre nouveau pilote a changé l’agressivité du boost ou l’interprétation des limites de puissance, vous verrez une différence de débit sans aucun changement de code.

Cherchez ces indices : état P bloqué au-dessus de l’inactivité, ou impossibilité d’atteindre P0 sous charge ; oscillations d’horloge ; atteintes précoces du plafond de puissance.

2) Limites de puissance et cibles thermiques

La limite de puissance n’est pas seulement « combien de chaleur vous dégagez ». C’est la fréquence à laquelle le GPU peut maintenir son boost.
Les centres de données aiment le power capping. L’entraînement ML déteste les plafonds de puissance surprise. Votre pilote peut appliquer ou interpréter ces plafonds différemment.

3) Gestion mémoire et sursouscription

Sur le papier, votre GPU a X Gio. En pratique, allocations, fragmentation et comportement de migration de pages sont définis par le pilote.
Unified memory, pinned memory et UVA ajoutent des couches où « le pilote décide ».

C’est pourquoi une mise à jour du pilote peut transformer une charge de travail de « s’exécute bien » à « OOM aléatoire à l’étape 8000 ».
L’allocateur mémoire a changé. Ou le seuil d’éviction. Ou le pilote réserve désormais plus de mémoire pour lui-même.

4) Ordonnancement et concurrence : MPS, MIG et time-slicing

Si vous partagez des GPU, vous faites confiance à l’ordonnanceur du pilote pour être équitable et performant.
Cet ordonnanceur change. Parfois il s’améliore. Parfois il modifie la forme des pics de latence.

MPS peut améliorer le débit pour beaucoup de petits noyaux. Il peut aussi étaler les fautes entre clients et compliquer l’attribution.
MIG peut offrir une isolation forte, mais vous pouvez encore vous retrouver limité par des ressources partagées et des surcoûts au niveau pilote.

5) Gestion des erreurs et récupération : différence entre « avertissement » et « nœud mort »

Le pilote décide quoi faire quand le GPU se comporte mal : reset du canal, reset du périphérique, ou abandon.
C’est là que réside la fiabilité.

Sous Linux, vous verrez des messages NVRM Xid. Parfois ils sont bénins et récupérables. Parfois ils prédisent une mort imminente.
Les versions de pilote changent ce que « récupérable » signifie.

6) Sélection de noyaux de bibliothèques : une « mise à jour du pilote » qui n’est pas que le pilote

Beaucoup de variations de performance attribuées au « pilote » proviennent en réalité de bibliothèques en espace utilisateur changeant leurs heuristiques :
cuDNN choisit différents algorithmes de convolution ; cuBLAS change la sélection GEMM ; les résultats d’autotuning varient avec de petits changements.

Si vous mettez à jour le pilote et le toolkit CUDA dans la même fenêtre, vous venez de créer un roman policier. Séparez-les.

Une citation sur la fiabilité pour rester lucide

Idée paraphrasée de Werner Vogels : Tout échoue, tout le temps ; construisez des systèmes qui s’y attendent et qui récupèrent automatiquement.

Guide de diagnostic rapide (premier/deuxième/troisième)

Quand une charge GPU ralentit ou devient instable après un changement de pilote, ne commencez pas par réécrire votre modèle ou blâmer le « PCIe ».
Démarrez par une boucle de triage serrée qui isole où le contrat a changé.

Premier : confirmez ce qui a effectivement changé

Version du pilote, version CUDA, version du noyau.
Version du firmware GPU si disponible.
Limite de puissance, mode persistence, mode compute, état MIG/MPS.
ECC activé/désactivé.

Deuxième : décidez si le goulot est horloges, mémoire, ou ordonnancement

Problème horloges/puissance : état P n’atteint pas les niveaux attendus, atteintes du plafond de puissance, pics de température, perf qui oscille.
Problème mémoire : OOM, symptômes de fragmentation, pics de paging/migration, chute soudaine de la taille effective des batches.
Problème ordonnancement : régressions multi-tenant, utilisation étrange, pics de latence en queue, noyaux retardés derrière d’autres contextes.

Troisième : reproduisez avec un test minimal et verrouillez les variables

Exécutez un microbenchmark stable ou un petit pas d’inférence/entraînement représentatif avec des seeds fixes.
Utilisez la même image de conteneur et le même pilote hôte entre les tests (ou inversement — contrôlez un côté).
Collectez : horloges, puissance, température, utilisation, usage mémoire, logs Xid.

Si vous ne pouvez pas le reproduire dans un test minimal, c’est probablement un problème de concurrence ou de contention, pas une question de « vitesse brute du GPU ».

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute réellement quand quelqu’un dit « le pilote a changé nos GPU ».
Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision que vous prenez.

Tâche 1 : Identifier le pilote et l’inventaire GPU

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 A100-SXM4-40GB          On  | 00000000:3B:00.0 Off |                    0 |
|  36%   48C    P0             210W / 400W|  1234MiB / 40960MiB   |     12%      Default |
+-----------------------------------------+----------------------+----------------------+

Sens : Confirme la version du pilote, la compatibilité CUDA rapportée, le mode persistence, la limite de puissance, l’état de perf, et les compteurs de santé de base.

Décision : Si la version du pilote diffère de votre base de référence, considérez tout le reste comme suspect tant que ce n’est pas stabilisé. Enregistrez-le dans les notes d’incident.

Tâche 2 : Confirmer la version du module noyau chargé

cr0x@server:~$ modinfo nvidia | head -n 8
filename:       /lib/modules/6.5.0-28-generic/updates/dkms/nvidia.ko
version:        550.54.14
license:        NVIDIA
description:    NVIDIA kernel module
author:         NVIDIA Corporation
srcversion:     8F6C9C5B6B61A2D4E3B1B19
depends:
retpoline:      Y

Sens : S’assure que le module noyau en cours d’exécution correspond à la version du paquet que vous pensez avoir installée.

Décision : Si nvidia-smi et modinfo ne sont pas d’accord, vous avez une mise à jour partielle ou un module obsolète. Corrigez avant de benchmarker.

Tâche 3 : Voir les erreurs récentes du pilote (Xid) et les resets GPU

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|gpu has fallen off|reset' | tail -n 20
[Tue Jan 13 10:18:02 2026] NVRM: Xid (PCI:0000:3b:00): 31, pid=24811, name=python, Ch 0000002a
[Tue Jan 13 10:18:02 2026] NVRM: Xid (PCI:0000:3b:00): 31, pid=24811, name=python, MMU Fault: ENGINE GRAPHICS
[Tue Jan 13 10:18:04 2026] nvidia-modeset: WARNING: GPU:0: Corrected error detected

Sens : Les codes Xid sont des rapports de faute au niveau pilote. Les fautes MMU peuvent indiquer des noyaux bogués, des accès mémoire incorrects, ou des régressions du pilote.

Décision : Si des Xid apparaissent après la mise à jour et se corrèlent avec des échecs de jobs, arrêtez de débattre sur la « performance » et considérez-le comme une régression de fiabilité. Envisagez un rollback ou isolez sur des nœuds canaris.

Tâche 4 : Vérifier la limite de puissance et si elle a été changée silencieusement

cr0x@server:~$ nvidia-smi -q -d POWER | egrep -i 'Power Limit|Default Power Limit|Enforced Power Limit'
    Power Limit                    : 400.00 W
    Default Power Limit            : 400.00 W
    Enforced Power Limit           : 400.00 W

Sens : Montre la politique de puissance actuelle et par défaut. Un décalage entre « default » et « enforced » est un signal d’alerte.

Décision : Si la limite appliquée a baissé (commun dans les racks partagés), décidez de l’augmenter (si autorisé) ou réajustez les tailles de batch et les attentes. Ne pas benchmarker avec des plafonds inconnus.

Tâche 5 : Observer en temps réel les horloges et raisons de throttling

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 1 -c 5
# gpu   pwr  u  c  v  m  t
# Idx     W  %  MHz  MHz  %  C
    0   212 12  1410 12150  3  49
    0   225 85  1410 12150 61  56
    0   238 92  1410 12150 72  59
    0   399 98  1170 12150 84  66
    0   401 99  1140 12150 86  67

Sens : Vous pouvez voir les horloges chuter quand la puissance atteint le plafond. L’utilisation reste élevée, les horloges tombent : c’est du throttling lié à la puissance.

Décision : Si les horloges s’effondrent au plafond de puissance, soit augmentez le plafond (si la politique le permet), améliorez le refroidissement/flux d’air, ou acceptez un débit moindre. Ne blâmez pas « le modèle ».

Tâche 6 : Confirmer le mode persistence (pour éviter les jitter d’initialisation)

cr0x@server:~$ nvidia-smi -q | egrep -i 'Persistence Mode' | head -n 1
    Persistence Mode               : Enabled

Sens : La persistance désactivée peut engendrer des coûts d’initialisation répétés et des délais de stabilisation des horloges entre jobs.

Décision : Dans les clusters partagés avec de courts jobs, activez la persistence sur les nœuds compute pour réduire la variabilité—à moins qu’une raison organisationnelle s’y oppose.

Tâche 7 : Vérifier le mode ECC et les compteurs d’erreurs

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i 'ECC Mode|Volatile|Aggregate'
    ECC Mode
        Current                     : Enabled
        Pending                     : Enabled
    Volatile Uncorrectable ECC Errors : 0
    Aggregate Uncorrectable ECC Errors : 0

Sens : L’ECC change le comportement mémoire et peut mettre en évidence des défauts matériels. Les erreurs volatiles sont depuis le boot ; l’agrégat persiste.

Décision : Si les erreurs uncorrectable agrégées augmentent, cela tend vers une conversation RMA matériel, pas un tuning. Mettez le nœud en quarantaine.

Tâche 8 : Vérifier l’état MIG et la disposition (le GPU est-il réellement partitionné ?)

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-0a1b2c3d-4e5f-6789-abcd-0123456789ef)
  MIG 1g.5gb Device 0: (UUID: MIG-GPU-0a1b2c3d-4e5f-6789-abcd-0123456789ef/1/0)
  MIG 1g.5gb Device 1: (UUID: MIG-GPU-0a1b2c3d-4e5f-6789-abcd-0123456789ef/2/0)

Sens : Si des dispositifs MIG existent, votre « GPU 0 » n’est pas un GPU complet du point de vue du job.

Décision : Si la performance a régressé après mise à jour et que MIG est activé, confirmez que votre ordonnanceur assigne le profil MIG attendu. Beaucoup de « régressions » sont en fait des parts plus petites.

Tâche 9 : Valider la largeur/vitesse du lien PCIe (limiteur silencieux classique)

cr0x@server:~$ sudo lspci -s 3b:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <8us
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Sens : Le GPU tourne à une vitesse/largeur PCIe réduite. Cela peut arriver après des changements de firmware, réglages BIOS, ou matériel marginal.

Décision : Si le lien est dégradé, votre goulot peut être l’I/O hôte. Réparez la plateforme (reseat, BIOS, riser, réglages ASPM) avant d’accuser le pilote.

Tâche 10 : Vérifier l’état IOMMU (peut affecter performance DMA et compatibilité)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0-28-generic root=/dev/nvme0n1p2 ro quiet splash intel_iommu=on iommu=pt

Sens : Montre si l’IOMMU est activé et si le mode passthrough est utilisé. Certaines configurations régressent si l’IOMMU est en traduction complète.

Décision : Si vous voyez des paramètres IOMMU inattendus après une mise à jour noyau/pilote, réévaluez la performance DMA et les besoins d’isolation du dispositif. N’« optimisez » pas cela à l’aveugle.

Tâche 11 : Confirmer que le conteneur voit le runtime CUDA attendu

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
Tue Jan 13 10:25:10 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4  |
+---------------------------------------------------------------------------------------+

Sens : Confirme que le pilote hôte est exposé dans le conteneur et que les outils du conteneur concordent.

Décision : Si le conteneur ne peut pas exécuter nvidia-smi ou rapporte des composants incompatibles, corrigez l’intégration du runtime conteneur (NVIDIA Container Toolkit) avant de chasser des « bugs modèle ».

Tâche 12 : Détecter des changements au niveau des bibliothèques (cuDNN / cuBLAS) qui ressemblent à des régressions du pilote

cr0x@server:~$ python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.backends.cudnn.version())"
2.2.1
12.1
8902

Sens : Les versions CUDA/cuDNN de votre framework comptent autant que le pilote. Une mise à jour du pilote peut coïncider avec un rafraîchissement du conteneur.

Décision : Si les versions ont changé, vous n’avez pas un test A/B propre. Ré-exécutez les tests avec une seule variable modifiée (pilote uniquement, ou conteneur uniquement).

Tâche 13 : Vérifier la liste des processus GPU et si « utilisation » vous ment

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   jpg   ofa   command
# Idx          #   C/G     %     %     %     %     %     %     name
    0      24811     C    92    18     0     0     0     0     python
    0      25102     C     5     2     0     0     0     0     python

Sens : Plusieurs processus compute partagent le périphérique. Votre « ralentissement » peut être de la contention, pas une régression du pilote.

Décision : Si des processus inattendus existent, corrigez d’abord l’ordonnancement/l’isolation. Le débogage de performance sans contrôle de la tenancy est de l’astrologie avec de meilleurs graphiques.

Tâche 14 : Capturer une courte trace de performance (haut niveau) comme preuve de régression

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,driver_version,pstate,clocks.sm,clocks.mem,power.draw,temperature.gpu,utilization.gpu,utilization.memory --format=csv -l 1 -c 5
timestamp, driver_version, pstate, clocks.sm [MHz], clocks.mem [MHz], power.draw [W], temperature.gpu, utilization.gpu [%], utilization.memory [%]
2026/01/13 10:26:31, 550.54.14, P0, 1410, 12150, 225.11, 56, 85, 61
2026/01/13 10:26:32, 550.54.14, P0, 1410, 12150, 238.42, 59, 92, 72
2026/01/13 10:26:33, 550.54.14, P0, 1170, 12150, 399.72, 66, 98, 84
2026/01/13 10:26:34, 550.54.14, P0, 1140, 12150, 401.03, 67, 99, 86
2026/01/13 10:26:35, 550.54.14, P0, 1140, 12150, 401.10, 67, 99, 86

Sens : C’est le « reçu » le plus simple à joindre à un incident : horloges, puissance, temp, util dans un CSV.

Décision : Si vous pouvez montrer les horloges chutant exactement quand la puissance atteint le plafond, vous arrêtez de débattre et commencez à négocier la politique de puissance ou la remédiation thermique.

Petite blague #1 : Une mise à jour de pilote GPU, c’est comme une « demande de changement mineure » venant de la finance — techniquement petite, émotionnellement dévastatrice.

Trois mini-récits d’entreprises venus des opérations

Mini-récit 1 : L’incident provoqué par une mauvaise hypothèse

Une entreprise exploitait une flotte mixte de GPU pour entraînement et inférence. L’équipe SRE avait une règle claire : mettre à jour les pilotes chaque mois, patcher les noyaux chaque trimestre.
Ils supposaient que la frontière de compatibilité clé était la « version CUDA dans le conteneur ». Si le conteneur tournait, ils étaient contents.

Un mois, une mise à jour du pilote a été déployée sur la moitié des nœuds d’inférence. En quelques heures, la latence en queue est devenue étrange : pas catastrophique, juste suffisante pour manquer un SLO interne.
Les ingénieurs voyaient une utilisation GPU élevée. Ils ont supposé que le modèle était devenu plus lourd. Ce n’était pas le cas.

Le véritable changement était la politique de puissance. Le nouveau pilote interprétait différemment les contrôles de limite de puissance de la plateforme. Sous charge soutenue, les GPU atteignaient le plafond et se bridèrent davantage.
Même utilisation, moins de cycles effectifs. Le système avait l’air « occupé » tout en produisant moins de travail — effondrement du débit déguisé en productivité.

La mauvaise hypothèse était que « les mises à jour de pilote ne changent pas le comportement de puissance ». Elles le font. La correction a été ennuyeuse : enregistrer et appliquer explicitement les limites de puissance comme partie du provisioning du nœud,
et conserver une trace CSV de référence (comme celle ci-dessus) d’une exécution connue bonne. Une fois cela en place, les « régressions de performance » sont devenues des événements prouvables, pas des impressions.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation poursuivait le débit maximal sur un cluster d’entraînement multi-tenant. Ils ont activé une fonctionnalité de partage pour améliorer l’utilisation :
plus de jobs par GPU, moins de périodes d’inactivité, de meilleurs chiffres sur un tableau de bord.

Ça a marché le premier jour. Puis est venue la mise à jour du pilote. Soudain, des runs d’entraînement rares ont commencé à échouer avec des erreurs liées à la mémoire et parfois des Xid pilote.
Les échecs n’étaient pas uniformes : certaines équipes étaient affectées, d’autres pas, ce qui a rendu la situation politiquement délicieuse et techniquement horrible.

L’optimisation avait un coût caché : la nouvelle version du pilote a changé le comportement de gestion mémoire en cas de sursouscription et augmenté le surcoût des changements de contexte
pour le mélange de noyaux spécifiques qu’ils exécutaient. Plus de concurrences signifiait plus de pression de fragmentation et plus de temps passé dans les chemins du pilote, pas sur les SMs.

Le « fix » n’a pas été d’abandonner le partage pour toujours. Il a consisté à l’appliquer avec des contraintes : imposer une marge mémoire par job, limiter le nombre de contextes concurrents par GPU,
et placer la mise à jour du pilote derrière des tests de stress conçus pour déclencher le chemin de fragmentation. La leçon : l’utilisation n’est pas le débit, et le débit n’est pas la fiabilité.

Petite blague #2 : Nous avons essayé « d’optimiser le partage GPU » et avons accidentellement inventé un générateur de nombres aléatoires avec ventilateur.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une troisième entreprise a fait quelque chose peu à la mode : elle a gardé un « nœud doré » par classe de GPU. Même réglages BIOS, même noyau, même pilote,
mêmes images de conteneur. Il exécutait une suite nocturne : un microbenchmark, un batch d’inférence représentatif et une courte boucle d’entraînement.

Quand une mise à jour du pilote était proposée, elle arrivait d’abord sur le nœud doré et un petit pool canari. La suite s’exécutait automatiquement et se comparait à une base épinglée.
L’équipe n’exigeait pas la perfection ; elle exigeait une explication. Si la performance bougeait, ils voulaient une raison : puissance, horloges, mémoire, ordonnancement, ou changements de bibliothèques.

Une mise à jour a montré une petite régression de débit mais a aussi éliminé une classe d’erreurs Xid qui auparavant provoquait des drains rares de nœud.
L’impact business favorisait la fiabilité. Parce qu’ils avaient des preuves, ils ont pu choisir le compromis intentionnellement plutôt que par surprise.

La pratique « ennuyeuse » était : épingler les versions + canaris contrôlés + artefacts de preuve de régression. Ça n’a rendu personne célèbre.
Mais cela a gardé le cluster hors du canal des incidents.

Erreurs courantes : symptôme → cause racine → fix

Voici des motifs que je vois répétitivement quand des équipes traitent les pilotes GPU comme une dépendance anodine.
Utilisez ceci comme table de recherche des modes de panne.

1) Symptom : Utilisation GPU élevée, débit inférieur à la semaine dernière

Cause racine : Changement de power cap / throttling thermique ; horloges plus basses alors que l’utilisation SM reste élevée.

Fix : Mesurer horloges/puissance avec nvidia-smi --query-gpu et dmon. Confirmer la limite de puissance. Améliorer le refroidissement ou ajuster les caps ; retuner les tailles de batch si les caps sont une contrainte politique.

2) Symptom : OOM aléatoires après mise à jour du pilote, même batch size

Cause racine : Le pilote réserve maintenant plus de VRAM ; le comportement de l’allocateur a changé ; la fragmentation a augmenté sous concurrence.

Fix : Réduire le peak VRAM (batch/longueur de séquence), ajouter de la marge, réduire les contextes concurrents, et comparer les baselines d’usage mémoire entre versions.

3) Symptom : Jobs d’entraînement bloqués, le nœud nécessite un reboot

Cause racine : Canal GPU bloqué ; le pilote ne peut pas récupérer ; le chemin de reset a changé. Souvent corrélé avec des Xid.

Fix : Collecter les Xid via dmesg, isoler par version de pilote, tester un rollback. Envisager une vérification de santé qui draine le nœud sur certains patterns Xid avant qu’il ne se bloque complètement.

4) Symptom : Après mise à jour, certains nœuds sont lents, d’autres OK

Cause racine : Versions de pilote mixtes, dispositions MIG mixtes, ou différences de plateforme (PCIe dégradé, réglages BIOS).

Fix : Appliquer des contrôles de dérive de configuration. Vérifier versions de pilote, état MIG, et statut du lien PCIe. Ne comparez pas des pommes avec des pommes légèrement cassées.

5) Symptom : Le conteneur indique CUDA version X, mais des erreurs runtime mentionnent pilote incompatible

Cause racine : Pilote hôte trop ancien pour les attentes du runtime conteneur ; ou intégration du runtime conteneur cassée.

Fix : Aligner le pilote hôte avec la compatibilité CUDA requise. Valider avec un simple test docker run --gpus all ... nvidia-smi avant d’exécuter des workloads réels.

6) Symptom : Pics de latence dans l’inférence multi-tenant après mise à jour

Cause racine : Changements d’équité de l’ordonnanceur ; time-slicing plus agressif ; différences de comportement MPS ; surcoût des changements de contexte augmenté.

Fix : Réduire le partage, utiliser des profils MIG pour une isolation plus forte, ou dédier des GPU aux services sensibles à la latence. Mesurer la latence en queue sous charge, pas seulement le débit moyen isolé.

7) Symptom : Performance de transfert PCIe en baisse

Cause racine : Largeur/vitesse de lien PCIe dégradée ; mode IOMMU changé ; resizable BAR togglé par combinaison BIOS/pilote.

Fix : Vérifier lspci -vv LnkSta, confirmer les réglages BIOS, valider les paramètres IOMMU. Si nécessaire, reseat le matériel ou échangez les risers avant d’optimiser le logiciel.

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

Étape par étape : déploiement sûr d’un pilote GPU en production

Inventairez et classifiez les nœuds par modèle GPU, carte mère, version BIOS, version noyau, et type de workload (entraînement vs inférence).
Épinglez une baseline : enregistrez la version du pilote, les limites de puissance, le mode ECC, l’état MIG/MPS, et un petit benchmark avec trace horloges/puissance.
Mettez à jour d’abord le pilote (pas le toolkit CUDA, pas les conteneurs) sur un nœud doré. Collectez la même trace.
Exécutez une suite de stress qui inclut des noyaux longue durée, pression mémoire, et concurrence si vous l’utilisez en production.
Canarisez un petit pool avec des workloads représentatifs. Surveillez la latence en queue et les taux d’erreur, pas seulement le débit.
Définissez des politiques explicites : limites de puissance, mode persistence, mode compute, et layout MIG doivent être configurés, pas supposés.
Déployez progressivement avec une condition claire de rollback : patterns Xid spécifiques, seuil de régression du débit, ou SLO manqué.
Verrouillez après le déploiement : assurez-vous que personne ne met à jour automatiquement les pilotes sur des nœuds au hasard. La dérive est la cause des « seuls les mardis sont lents ».

Checklist pré-vol pour les rapports « le GPU semble différent »

Avons-nous un enregistrement de la version du pilote avant/après ?
Les horloges/puissance/temps sont-ils comparables ?
L’état MIG/MPS a-t-il changé ?
Le mode ECC a-t-il changé ?
Le lien PCIe est-il dégradé ?
Y a-t-il des Xid dans dmesg ?
Les versions CUDA/cuDNN du conteneur ont-elles changé en même temps ?
Y a-t-il une multi-tenancy inattendue sur le GPU ?

Garde-fous opérationnels que je recommande (opinionnés)

Ne mettez jamais à jour pilote + toolkit CUDA + framework dans une même fenêtre de changement si vous tenez à la traçabilité de la cause racine.
Gardez un nœud doré par classe GPU avec une suite de régression automatisée.
Rendez les limites de puissance explicites. Les valeurs par défaut ne sont pas des contrats.
Exigez un plan de rollback incluant rollback du module noyau et automatisation du drain de nœud.
Mesurez la latence en queue pour l’inférence et la stabilité steps/sec pour l’entraînement. Les moyennes cachent les changements de politique du pilote.

FAQ

1) Un pilote GPU peut-il vraiment changer les performances sans toucher mon code ?

Oui. Les pilotes définissent horloges, comportement de puissance, politique d’ordonnancement, stratégie d’allocation mémoire, et heuristiques de sélection de noyaux dans les bibliothèques.
Votre code peut être identique tandis que le contrat matériel effectif change.

2) Si `nvidia-smi` montre une utilisation élevée, cela ne prouve-t-il pas que le GPU est pleinement utilisé ?

Non. L’utilisation est le « temps occupé », pas le « travail utile effectué ». Vous pouvez être occupé à 99 % à des fréquences plus basses à cause d’un power cap et produire moins de débit.
Regardez toujours les horloges et la puissance en parallèle de l’utilisation.

3) Quelle est la manière la plus rapide de prouver une régression puissance/horloge ?

Collectez une courte trace CSV de pstate, horloges SM, consommation, température et utilisation durant la charge.
Si les horloges chutent quand la puissance atteint le plafond, vous avez votre coupable.

4) Les mises à jour de pilotes concernent-elles surtout les performances ?

Non. Beaucoup visent la correction, la sécurité et la stabilité à travers noyaux et plateformes. Les changements de performance sont souvent des effets secondaires de changements de politique.
En production, des correctifs de stabilité peuvent valoir un petit ralentissement—si vous le choisissez en connaissance de cause.

5) MIG est-il toujours meilleur pour le multi-tenancy ?

C’est une meilleure isolation que le simple time-slicing, mais ce n’est pas magique. Vous pouvez encore être limité par des ressources partagées et le surcoût pilote.
MIG est excellent quand vous avez besoin de tranches prévisibles ; il peut être gaspilleur si vos workloads sont en rafales et n’entrent pas bien dans les profils.

6) Pourquoi certaines mises à jour de pilotes augmentent-elles l’usage mémoire ?

Les pilotes peuvent réserver des quantités différentes de VRAM pour la bookkeeping interne, les tables de pages, ou de nouvelles fonctionnalités.
De plus, le comportement des bibliothèques et des allocateurs peut changer. Ces « 1–2 Gio manquants » sont souvent réels, pas votre imagination.

7) Devons-nous épingler les pilotes pour toujours une fois que tout fonctionne ?

Non. Épingler pour toujours accumule le risque de sécurité et la dette d’incompatibilité future. Épinglez délibérément, mettez à jour délibérément.
Un cadence contrôlée avec des canaris bat à la fois le chaos et la stagnation.

8) Quelle est la différence entre problèmes de pilote et problèmes matériels ?

Les problèmes matériels montrent souvent des tendances persistantes d’erreurs ECC, des fautes reproductibles à travers les versions de pilote, ou des dégradations physiques de lien.
Les problèmes de pilote se corrèlent fortement avec des changements de version et affectent souvent plusieurs nœuds de la même manière. Utilisez les logs Xid et les compteurs ECC pour les séparer.

9) Pourquoi la performance varie-t-elle entre GPU « identiques » ?

Variation siliconique, différences de refroidissement, alimentation, et politiques de boost comptent tous. Les pilotes amplifient ces différences en changeant les heuristiques de boost et de throttling.
En d’autres mots : des numéros de pièce identiques n’offrent pas forcément un comportement identique à l’exécution.

10) Que dois-je conserver dans les artefacts d’incident pour une régression GPU ?

Au minimum : version du pilote, version du noyau, modèle GPU, réglages de limite de puissance, état MIG/MPS/ECC, une courte trace nvidia-smi --query-gpu,
et des extraits pertinents de dmesg avec les Xid.

Conclusion : que faire lundi prochain

Si vous exploitez des GPU en production, cessez de traiter les pilotes comme une dépendance de fond et commencez à les considérer comme du firmware avec des opinions.
Les pilotes ne se contentent pas « d’activer le périphérique ». Ils définissent son comportement sous puissance, chaleur, contention et panne.

Étapes pratiques :

Choisissez un pilote de référence par classe de GPU et enregistrez explicitement les politiques de puissance/ECC/MIG/MPS.
Construisez une petite suite de régression et exécutez-la sur un nœud doré et un pool canari avant les rollouts.
Quand vous voyez des régressions, capturez d’abord les traces horloges/puissance/util et les logs Xid. Argumentez ensuite.
Séparez les mises à jour du pilote des mises à jour CUDA/toolkit/framework quand vous voulez une cause racine propre.
Gardez des chemins de rollback répétés, pas théoriques.

Le matériel vieillit. Les pilotes évoluent. Votre travail est de rendre ces changements visibles, testables et réversibles — pour que « le GPU a changé » devienne un diagnostic, pas une superstition.