Si vous exécutez des charges GPU en production, vous avez rencontré le même antagoniste sous dix costumes différents : « Le GPU est lent. »
Parfois, c’est vrai. Plus souvent, le GPU attend — votre CPU, votre stockage, votre réseau, vos pilotes, votre runtime de conteneur,
ou un seul drapeau manquant qui transforme un accélérateur à 20 000 $ en chauffage d’appoint.
Ci‑dessous, dix mythes GPU qui continuent d’engloutir budgets et nuits. Chaque mythe est accompagné d’une correction pratique,
de commandes que vous pouvez lancer aujourd’hui, et des modes de défaillance qui surgissent à 2 h du matin quand un entraînement « régresse mystérieusement ».
Playbook de diagnostic rapide : trouver le goulot d’étranglement en 10 minutes
La façon la plus rapide de déboguer la « performance » GPU est d’arrêter de parler seulement des GPU et de commencer à mesurer l’ensemble du pipeline.
Vous cherchez la première ressource rare. Pas la plus chère.
1) Premier examen : le GPU fait‑il réellement du travail ?
- Regardez l’utilisation SM, l’utilisation mémoire et la consommation électrique. Si la puissance est basse, vous n’êtes probablement pas limité par le calcul.
- Vérifiez les fréquences et le throttling. Un GPU à 300 MHz n’est pas « lent », il est limité.
2) Deuxième examen : le CPU/le pipeline de données l’affame‑t‑il ?
- Une forte utilisation CPU, un iowait élevé ou des lectures lentes signifient généralement que le GPU attend des entrées.
- Recherchez des blocages du dataloader, des tailles de batch trop petites, des augmentations excessives côté CPU, ou de la mémoire hôte non verrouillée (non‑pinned).
3) Troisième examen : êtes‑vous lié par la bande passante (PCIe / réseau / stockage) ?
- Un lien PCIe downtrainé (x16 → x4) ou Gen4 → Gen3 réduira silencieusement le débit.
- Le réseau ou un stockage partagé peut plafonner l’entraînement distribué bien avant que vous « manquiez de GPU ».
4) Quatrième examen : luttez‑vous contre des frictions logicielles ?
- Incompatibilités driver/runtime, mauvais runtime de conteneur, mode persistence désactivé, ou variables d’environnement mal réglées peuvent forcer des chemins lents.
- Les versions du noyau, les réglages IOMMU et les cgroups peuvent aussi introduire des surcoûts surprenants.
5) Dernier examen : profilez une itération de bout en bout
- Ne devinez pas. Mesurez le temps de l’étape décomposé en entrée, transformations CPU, transfert H2D, calcul GPU, D2H et synchronisation.
Une idée paraphrasée (lore fiabilité, attribuée) : l’idée paraphrasée
— John Allspaw (opérations et réponse aux incidents) : le comportement du système devient logique une fois que l’on voit les contraintes.
Dans l’univers GPU, les contraintes sont presque jamais là où vous les souhaitez.
Les 10 mythes (et que faire à la place)
Mythe 1 : « L’utilisation du GPU devrait être ~100 % sinon vous jetez de l’argent par les fenêtres. »
« Utilisation » est l’un de ces indicateurs qui semble objectif et qui se comporte comme une rumeur. Un GPU peut afficher 20–40 % d’utilisation
et être parfaitement sain si votre modèle a des points de synchronisation fréquents, des noyaux courts, ou est limité par la latence.
À l’inverse, vous pouvez atteindre 99 % d’utilisation en faisant le mauvais travail — comme reformater constamment des tenseurs ou brûler des cycles sur des casts inutiles.
Que faire à la place :
- Suivez le temps par étape et le débit (ex‑s / exemples/s) comme indicateurs principaux.
- Surveillez la consommation électrique et les fréquences. Le travail intensif en calcul tend à tirer plus de puissance.
- Recherchez l’attente CPU et les blocages du dataloader avant de courir après « plus d’utilisation ».
Décision pratique : si le temps par étape est stable et respecte les SLO, ne « corrigez » pas l’utilisation. Si le temps par étape a régressé, trouvez le blocage.
Mythe 2 : « Plus de VRAM accélère l’entraînement. »
La VRAM est de la capacité, pas de la puissance. Plus de VRAM vous permet d’ajuster des batches plus grands, des modèles plus gros, des séquences plus longues, ou de mettre en cache plus d’activations.
Elle n’augmente pas automatiquement les FLOPS ou la bande passante mémoire. Parfois, une VRAM plus grande incite les équipes à utiliser des batches plus volumineux qui réduisent
la généralisation ou déstabilisent l’entraînement, ce qui revient à une régression des performances malgré des étapes plus rapides.
Que faire à la place :
- Achetez de la VRAM pour la capacité (est‑ce que ça s’exécute ?) et pour réduire la recomputation (choix de checkpointing d’activations), pas pour la vitesse seule.
- Benchmarquez d’abord avec une taille de batch fixe. Puis explorez l’augmentation de batch et l’ajustement du taux d’apprentissage correctement.
Fait historique : les premiers GPU de l’ère CUDA avaient souvent beaucoup moins de mémoire que les CPU, poussant l’industrie à inventer des batching plus intelligents,
des noyaux fusionnés et la précision mixte pour travailler dans des budgets VRAM serrés.
Mythe 3 : « Si ça tient dans la VRAM, vous êtes à l’abri des erreurs out‑of‑memory. »
L’expression « tient dans la VRAM » cache deux pièges : la fragmentation et le pic d’utilisation.
Beaucoup de frameworks allouent et libèrent des buffers temporaires pendant les passes avant/arrière. Les pics peuvent dépasser l’empreinte en régime permanent.
La fragmentation peut empêcher l’allocation d’un grand bloc contigu même si la « mémoire libre » semble abondante.
Que faire à la place :
- Mesurez la mémoire de pointe par itération. Surveillez la croissance au fil du temps (fuites, cache, accumulation de graphes).
- Utilisez les contrôles d’allocateur (lorsque disponibles) et évitez les schémas d’allocation pathologiques (beaucoup de tailles de tenseurs variables).
- Privilégiez des formes et tailles de batch cohérentes ; les formes dynamiques sont utiles jusqu’à ce qu’elles deviennent un test de résistance pour l’allocateur.
Fait intéressant : les allocateurs de mémoire GPU utilisent fréquemment des stratégies de cache pour éviter des allocations device coûteuses ; « réservé » n’est pas « fuit ».
Mythe 4 : « Le PCIe n’a pas d’importance — le calcul est le goulot d’étranglement. »
Le PCIe compte chaque fois que vous déplacez des données hôte↔device ou device↔device sans un tissu plus rapide. Des batches petits, des transferts fréquents,
ou un prétraitement intensif côté CPU peuvent transformer le PCIe en métronome de votre job. Pire, le PCIe échoue souvent silencieusement :
un slot en x4 ou un lien entraîné en Gen3 au lieu de Gen4 peut sembler « correct » mais fonctionner comme une voiture de location avec le frein à main serré.
Que faire à la place :
- Gardez les données sur le GPU plus longtemps. Fusionnez les opérations. Évitez de renvoyer les tenseurs au CPU par commodité.
- Validez la largeur et la vitesse du lien. Ne faites pas d’hypothèses.
- Utilisez la mémoire verrouillée (pinned) et des copies asynchrones quand vous devez transférer.
Fait historique : NVLink a été introduit en partie parce que la bande passante PCIe ne suivait pas l’entraînement multi‑GPU et le parallélisme de modèle.
Mythe 5 : « Les Tensor Cores / la précision mixte sont toujours plus rapides. »
La précision mixte peut être une aubaine. Elle peut aussi coûter cher. Vous obtenez des accélérations lorsque votre modèle et la combinaison de noyaux
sont configurés pour utiliser les chemins mathématiques rapides et lorsque les surcoûts (casts, loss scaling, synchronisation) ne dominent pas.
Certains modèles deviennent limités par la mémoire ou subissent un coût de lancement de noyau, où la précision réduite n’aide pas beaucoup.
Que faire à la place :
- Comparez FP32 vs AMP avec des seeds fixes et le même chargement de données.
- Surveillez l’instabilité numérique : NaN, pics de loss, gradients divergents.
- Confirmez que le chemin mathématique rapide est réellement utilisé (profiling), pas seulement demandé.
Fait intéressant : « l’ère des Tensor Cores » a commencé avec NVIDIA Volta (V100), et elle a changé la manière dont les frameworks ML ordonnancent les GEMM et convolutions.
Mythe 6 : « Si nvidia‑smi montre de la mémoire utilisée, le GPU travaille. »
L’utilisation de la VRAM n’est pas une activité. Cela peut simplement signifier que le processus a initialisé un contexte et mis en cache des allocations.
Vous pouvez parquer 30 Go de tenseurs sur un GPU et ne faire absolument aucun calcul utile si votre job est bloqué sur le prétraitement CPU,
bloqué sur un verrou, ou en interblocage lors d’un rendez‑vous distribué.
Que faire à la place :
- Vérifiez l’utilisation SM, la consommation électrique et l’utilisation par processus.
- Corrélez avec les journaux de l’application : le compteur d’itérations augmente‑t‑il ? Êtes‑vous bloqué avant la première étape ?
Blague n°1 : Un GPU avec la VRAM pleine et aucun calcul est comme une salle de réunion « réservée » toute la journée parce que quelqu’un y a laissé une bouteille d’eau.
Mythe 7 : « La mise à l’échelle multi‑GPU est essentiellement linéaire. »
La mise à l’échelle linéaire est une démo marketing où le réseau ne perd jamais un paquet, les tailles de batch s’ajustent parfaitement, et personne ne journalise au niveau INFO.
Dans les systèmes réels, le surcoût d’all‑reduce, les têtes lentes, la contention du pipeline d’entrée, et les contraintes de topologie NCCL grignotent vos gains.
Que faire à la place :
- Mesurez l’efficacité de mise à l’échelle (débit / nombre de GPU) et surveillez quand elle chute.
- Validez la topologie : PCIe, NVLink, placement NUMA et affinité NIC.
- Corrigez d’abord les têtes lentes : un worker lent peut freiner tout le job.
Fait intéressant : l’all‑reduce en anneau a rendu l’entraînement distribué pratique car il évite un goulot unique de serveur de paramètres, mais il reste sensible au lien le plus lent.
Mythe 8 : « Les problèmes de performance GPU se règlent en « mettant à jour le driver ». »
Les pilotes comptent. Mais « mettre à jour le driver » est l’équivalent opérationnel de « essayez d’éteindre et rallumer ». Parfois c’est la bonne solution ; souvent c’est une distraction
du véritable goulot — blocages de données, mauvais clocks, limites de puissance, ou un runtime de conteneur qui n’expose même pas correctement le GPU.
Que faire à la place :
- Épinglez des combinaisons driver/toolkit connues comme bonnes pour votre flotte. Faites les mises à jour de façon intentionnelle, pas émotionnelle.
- Quand vous mettez à jour, validez avec une petite batterie de tests de performance et de correction.
Fait historique : la séparation driver/runtime de CUDA est puissante mais impitoyable ; le fossé « ça marche sur mon laptop » se cache souvent dans la compatibilité de version.
Mythe 9 : « Les contraintes thermiques n’intéressent que les gamers. »
En production, les thermiques sont une question financière. Un GPU qui throttle la puissance ou atteint des limites thermiques rétrograde ses fréquences,
transformant votre job finement réglé en un filet lent. Les centres de données regorgent de raisons : filtres encrassés,
ventilateurs défaillants, flux d’air étrange dans un châssis, ou quelqu’un qui a monté du matériel haut‑TDP à côté du serveur déjà chaud.
Que faire à la place :
- Surveillez les températures, la puissance et les raisons de throttling.
- Validez que votre limite de puissance est correctement définie et que votre refroidissement fait réellement ce que vous pensez.
Fait intéressant : Beaucoup de GPU préfèrent le throttling par limite de puissance avant l’arrêt thermique ; vous pouvez perdre des performances sans jamais voir un événement dramatique de « surchauffe ».
Mythe 10 : « Les GPU sont la partie difficile ; le stockage est un problème résolu. »
Le stockage est l’endroit où le « training rapide » vient mourir en silence. Si votre jeu de données vit sur un système de fichiers partagé très utilisé,
ou si vous faites des lectures aléatoires de nombreux petits fichiers, votre GPU passera sa vie à attendre le batch suivant.
Vous blâmerez CUDA, puis les pilotes, puis la phase de la lune, alors qu’en réalité c’est une tempête de métadonnées sur le NAS.
Que faire à la place :
- Mesurez le débit du pipeline d’entrée et la latence de stockage pendant l’entraînement.
- Utilisez le sharding, des formats d’enregistrement plus volumineux, des caches NVMe locaux, et moins de petits fichiers.
- Privilégiez des lectures plutôt séquentielles et le préfetching plutôt que l’accès aléatoire « YOLO ».
Blague n°2 : Le GPU est une voiture de course ; l’alimenter depuis un NFS partagé plein de petits JPEGs, c’est comme remorquer un bateau avec un vélo.
Fait historique : L’essor des formats TFRecord/WebDataset a été motivé autant par l’évolutivité du stockage et des métadonnées que par la commodité ML.
Faits historiques et contexte (parce que les mythes ont des histoires d’origine)
- CUDA a été lancé en 2007, transformant les GPU d’appareils graphiques en matériel de calcul parallèle à usage général.
- Les Tensor Cores sont arrivés avec Volta (2017), déplaçant l’optimisation des performances vers les mathématiques matricielles et les choix de précision.
- Le « mode persistence » existe parce qu’initialiser des contextes GPU à répétition peut ajouter des secondes de latence — pénible avec des ordonnanceurs de batch.
- Multi‑Instance GPU (MIG) de NVIDIA a rendu les GPU segmentables pour l’isolation, mais a aussi fait surgir la question hebdomadaire « pourquoi mon GPU est‑il petit ? ».
- NCCL est devenu la bibliothèque de communication collective par défaut car l’entraînement distribué nécessite des collectives efficaces en bande passante.
- Les problèmes d’entraînement de lien PCIe sont plus anciens que le ML moderne ; le problème est juste devenu coûteux quand l’appareil est devenu un GPU.
- Sur Linux, la mémoire hôte verrouillée (page‑locked) fait la différence entre des transferts asynchrones et « pourquoi memcpy bloque mon étape ? »
- Les fréquences GPU peuvent être gouvernées par des plafonds de puissance, des contraintes thermiques et des clocks applicatives — trois réglages différents que les gens confondent constamment.
Tâches pratiques : commandes, sorties et décisions
Ce sont des choses réelles que vous pouvez exécuter sur un hôte GPU Linux. Chaque tâche inclut ce que la sortie signifie et quelle décision en découle.
Ne les traitez pas comme une checklist à exécuter une fois ; considérez‑les comme des instruments que vous gardez étalonnés.
Task 1: Confirm the GPU is visible and the driver is healthy
cr0x@server:~$ nvidia-smi
Tue Jan 21 11:02:13 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:81:00.0 Off | 0 |
| 34% 52C P0 180W / 400W| 12000MiB / 40536MiB | 62% Default |
+-----------------------------------------+----------------------+----------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 23141 C python 11850MiB |
+---------------------------------------------------------------------------------------+
Meaning: driver loads, GPU is present, and a process is actually using it.
Decision: if this fails or shows “No devices were found,” stop and fix drivers/container runtime/PCIe before chasing performance.
Task 2: Watch utilization, clocks, and power over time (spot starvation vs throttling)
cr0x@server:~$ nvidia-smi dmon -s pucmt
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk
# Idx W C C % % % % MHz MHz
0 185 53 - 61 48 0 0 1215 1410
0 85 50 - 8 6 0 0 1215 510
0 190 54 - 63 49 0 0 1215 1410
Meaning: when SM% and power drop together, the GPU is idle or waiting. When SM% is high but clocks are low, you might be throttling.
Decision: idle → investigate input pipeline/CPU/IO; throttling → check thermals, power limits, and clocks.
Task 3: Check throttling reasons (power/thermal caps)
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,160p'
==============NVSMI LOG==============
Performance
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
Meaning: “SW Power Cap: Active” indicates the GPU is being capped by a power limit.
Decision: confirm power caps are intentional; if not, adjust power limit or fix rack power/cooling policies.
Task 4: Confirm PCIe link speed and width (silent performance killer)
cr0x@server:~$ nvidia-smi -q | grep -A3 "PCI"
PCI
Bus : 0x81
Device : 0x00
Domain : 0x0000
--
Link Width : 16x
Link Generation : 4
Meaning: x16 Gen4 is what you want on modern servers; x8 or Gen3 may be expected on some platforms but should be known.
Decision: if you see x4 or Gen1/2/3 unexpectedly, reseat card, check BIOS settings, check risers, and validate slot wiring.
Task 5: Check NUMA topology and device affinity (avoid cross-socket pain)
cr0x@server:~$ nvidia-smi topo -m
GPU0 NIC0 CPU Affinity NUMA Affinity
GPU0 X PHB 0-31 0
NIC0 PHB X 0-31 0
Meaning: GPU and NIC share a PCIe host bridge (PHB) and are close to the same NUMA node.
Decision: if GPU is attached to NUMA node 1 and your dataloader threads run on node 0, pin processes/IRQs to reduce latency.
Task 6: Validate container GPU access (the “it’s running on CPU” classic)
cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
Tue Jan 21 11:03:48 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 |
+---------------------------------------------------------------------------------------+
Meaning: the container can see the GPU through the runtime.
Decision: if this fails, fix NVIDIA Container Toolkit/runtime configuration before blaming your ML code.
Task 7: Confirm the right kernel driver modules are loaded
cr0x@server:~$ lsmod | grep -E '^nvidia|^nvidia_uvm'
nvidia_uvm 1679360 0
nvidia_drm 126976 2
nvidia_modeset 1327104 1 nvidia_drm
nvidia 62287872 72 nvidia_uvm,nvidia_modeset
Meaning: missing nvidia_uvm can break some CUDA workloads; missing core modules means the driver isn’t loaded.
Decision: if modules are absent, inspect secure boot, DKMS build, kernel upgrade, and driver installation health.
Task 8: Spot CPU-side bottlenecks (iowait and context switching)
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0-21-generic (train-node-07) 01/21/2026 _x86_64_ (64 CPU)
11:04:10 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
11:04:11 AM all 420.0 0.0 35.0 98.0 0.0 2.0 0.0 3445.0
11:04:12 AM all 415.0 0.0 33.0 105.0 0.0 2.0 0.0 3445.0
Meaning: significant iowait suggests storage latency is throttling your pipeline; high sys can hint at networking or filesystem overhead.
Decision: if iowait is high while GPU is idle, prioritize storage and input format fixes over GPU tuning.
Task 9: Check filesystem latency and throughput on the dataset path
cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-21-generic (train-node-07) 01/21/2026 _x86_64_ (64 CPU)
Device r/s rkB/s rrqm/s %rrqm r_await aqu-sz %util
nvme0n1 820.0 52480.0 12.0 1.4 1.2 0.9 58.0
nfs0 1200.0 19200.0 0.0 0.0 18.5 22.0 99.0
Meaning: the NFS-like device shows high await and 99% utilization: you are storage-bound for reads.
Decision: stage data to local NVMe, shard/pack files, add caching, or move to a format with fewer metadata ops.
Task 10: Prove you’re not swapping or under memory pressure on the host
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 503Gi 212Gi 21Gi 2.1Gi 270Gi 286Gi
Swap: 16Gi 7.5Gi 8.5Gi
Meaning: swap usage during training is a red flag; it can stall dataloaders, tokenizers, and caching layers.
Decision: reduce host memory footprint, increase RAM, or cap parallelism; avoid swap for performance-critical training nodes.
Task 11: Confirm the process is actually using the GPU (and not stuck)
cr0x@server:~$ ps -o pid,ppid,stat,etime,cmd -p 23141
PID PPID STAT ELAPSED CMD
23141 22980 Sl+ 00:17:42 python train.py --config prod.yaml
Meaning: the process is alive; “Sl+” indicates sleeping with threads—could be normal, could be waiting.
Decision: if GPU is idle and process sleeps, inspect dataloader, locks, or distributed barriers.
Task 12: Inspect per-process GPU usage and compute mode
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec jpg ofa command
0 23141 C 62 48 0 0 0 0 python
0 1822 G 0 1 0 0 0 0 Xorg
Meaning: python is consuming SM and memory. If SM is 0 while memory is high, you’re likely stalled or between steps.
Decision: correlate with app logs; if stuck, attach profiler or enable debug logging around data fetch and forward pass.
Task 13: Check GPU ECC and error counters (silent corruption and retries)
cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
ECC Mode
Current ECC : Enabled
Pending ECC : Enabled
ECC Errors
Volatile
Single Bit
Device Memory : 0
Double Bit
Device Memory : 0
Meaning: ECC is enabled and counters are clean.
Decision: if you see rising correctable errors, plan maintenance; if uncorrectable errors appear, drain the node.
Task 14: Validate GPU persistence mode (reduce init overhead and flakiness)
cr0x@server:~$ nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:81:00.0.
Meaning: persistence mode keeps the driver context warm.
Decision: enable it on dedicated compute nodes unless your operational model requires otherwise (e.g., strict power savings).
Task 15: Confirm clock policy / application clocks (avoid accidental downclock)
cr0x@server:~$ nvidia-smi -q -d CLOCK | sed -n '1,140p'
Clocks
Graphics : 1410 MHz
SM : 1410 MHz
Memory : 1215 MHz
Applications Clocks
Graphics : 1410 MHz
Memory : 1215 MHz
Meaning: clocks are where you expect. If application clocks are set low, you’ll underperform “mysteriously.”
Decision: standardize clock settings via provisioning, and audit drift after driver updates.
Trois mini‑histoires du monde de l’entreprise
Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse (« panne » GPU qui était en réalité le stockage)
Une entreprise de taille moyenne exécutait un retraitement nocturne sur un cluster partagé. Un week‑end, le temps d’entraînement a doublé. L’astreinte a vu une faible utilisation GPU,
a classé ça comme une « dégradation GPU » et a escaladé au matériel. Un ticket fournisseur a été ouvert. Des délais de remplacement ont été discutés.
Le CFO s’est brièvement intéressé au machine learning, ce qui est un bon signe que c’était sérieux.
Le premier indice était que les GPU n’étaient pas chauds. La consommation était basse et en pics, comme un job qui sprinte puis roupille.
Pendant ce temps, l’iowait CPU montait, et le système de fichiers partagé avait l’air d’avoir attrapé la grippe : latence élevée, charge métadonnées élevée.
Le modèle allait bien ; les GPU aussi. C’était le pipeline du jeu de données qui était discrètement cassé.
L’« optimisation » qui a déclenché ça était innocente : un rafraîchissement de dataset qui a augmenté le nombre de petits fichiers en scindant les shards « pour le parallélisme ».
Cela a amélioré un benchmark sur le laptop d’un développeur avec SSD local, puis a détoné en production sur le stockage partagé.
Le job d’entraînement a commencé à effectuer des dizaines de milliers de petits opens et stat par minute sur de nombreux workers.
La correction fut ennuyeuse : empaqueter les échantillons dans des shards plus gros, prépositionner sur NVMe local, et préfetcher. L’utilisation GPU a augmenté en conséquence,
mais le vrai gain a été un temps par étape prévisible. Le ticket matériel a été clos avec la honte discrète qu’il méritait.
Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux (précision mixte partout, correction nulle)
Une autre organisation cherchait la vitesse d’entraînement. Ils ont activé l’AMP globalement et ont fêté une grosse augmentation de débit sur un nœud unique.
Puis l’entraînement distribué a commencé à produire des NaN intermittents. Pas tout le temps. Juste assez pour ruiner la confiance et déclencher des reruns.
Le schéma d’incident était classique : « Ça marche en staging, ça échoue en production, seulement quand la lune est… occupée. »
Le vrai problème n’était pas l’AMP en soi. C’était une couche du modèle numériquement sensible sous précision réduite,
plus une configuration de loss scaling qui allait pour une distribution de données et fragile pour une autre.
Ajoutez un ordre différent dû au dataloading multi‑worker, et l’instabilité a émergé.
L’équipe a répondu en désactivant entièrement l’AMP. L’entraînement s’est stabilisé, mais le débit est tombé sous l’objectif business.
Ils ont ensuite essayé de compenser en augmentant la taille du batch. Cela a changé la convergence, exigé un retuning du learning rate, et provoqué une deuxième vague de régressions :
modèles plus rapides mais moins performants.
La solution finale fut disciplinée : garder sélectivement des opérations sensibles en FP32, valider le loss scaling, ajouter des gardes NaN,
et verrouiller les changements avec une petite suite de tests de correction. L’AMP est revenu — cette fois comme un choix d’ingénierie, pas un interrupteur global.
La leçon n’était pas « l’AMP est risqué ». La leçon était « traitez les changements de performance comme des changements de production : observez, testez, déployez prudemment. »
Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (topologie et pinning)
Une entreprise exécutait de l’inférence multi‑GPU avec des SLOs de latence tail serrés. Un jour, la latence p95 a augmenté sans changement évident de code.
Le service semblait sain : pas d’erreurs, GPU visibles, pas d’alarmes thermiques. Mais la latence dérivait vers le haut comme une fuite lente.
Ils avaient une pratique ennuyeuse qui a payé : à chaque démarrage de nœud, un petit script de « sanity hardware » s’exécutait.
Il capturait la largeur de lien PCIe, l’affinité NUMA, les clocks GPU, les versions de drivers et des métriques de stockage basiques, puis les comparait à une baseline connue.
Quand le p95 bougeait, ils ne devinaient pas ; ils diffaient.
Le diff a montré qu’un nœud avait le GPU sur un autre NUMA que le NIC après un remplacement de carte mère.
La charge faisait des transferts hôte↔device fréquents pour le pré/post‑traitement.
Le trafic inter‑socket a augmenté la latence et la gigue. Le GPU n’était pas plus lent ; le chemin mémoire était plus long.
La correction fut simple : pinner le processus et les allocations mémoire sur le NUMA correct, ajuster l’affinité IRQ,
et mettre à jour la documentation du rack pour que les remplacements futurs respectent la topologie des slots. Pas d’héroïsme, pas de réécritures.
Juste un refus de « supposer que le bus est correct ».
Erreurs courantes : symptôme → cause racine → correction
1) Symptom: GPU memory is high, GPU utilization is near zero
- Root cause: data pipeline stall (storage latency, dataloader deadlock, CPU transforms too slow), or the job is stuck before first iteration.
- Fix: measure step-time breakdown; check iowait; reduce small-file reads; enable prefetch; increase dataloader workers carefully; use pinned memory.
2) Symptom: Newer GPU is slower than the old one
- Root cause: power cap, wrong clocks, PCIe downtraining, or a model that is memory-bound and not compute-bound.
- Fix: check throttling reasons and PCIe link; compare power draw; profile kernels; adjust batch size and fusion rather than blaming silicon.
3) Symptom: Random CUDA OOMs even though “free memory” exists
- Root cause: fragmentation or peak memory spikes (different shapes, variable sequence lengths, dynamic graphs), or memory leak in caching layers.
- Fix: use fixed shapes where possible; cap max sequence length; reduce batch; clear caches at safe boundaries; restart workers to reset fragmentation when needed.
4) Symptom: Multi-GPU scaling is terrible, one GPU always behind
- Root cause: straggler worker (CPU contention, different NUMA node, noisy neighbor IO), or NCCL using a suboptimal interface/topology.
- Fix: validate topology; pin CPU threads; ensure consistent storage locality; set NCCL to the right NIC; eliminate per-rank skew in dataloading.
5) Symptom: Training is fast for a while, then gradually slows
- Root cause: background storage contention, CPU thermal throttling, memory pressure causing swap, or a metrics/logging storm growing with time.
- Fix: monitor over time; throttle logging; isolate training IO; check host thermals; verify no memory growth/leaks.
6) Symptom: “GPU available” but code runs on CPU
- Root cause: container not using GPU runtime, wrong build (CPU-only), missing device visibility env vars, or framework not moving tensors to device.
- Fix: validate
docker run --gpus all nvidia-smi; check framework device placement; enforce device assertions in code and CI.
7) Symptom: High GPU utilization but low throughput
- Root cause: you’re doing expensive work inefficiently: tiny kernels, excessive synchronization, poor batch sizing, or non-fused operations.
- Fix: profile; increase batch; fuse ops; reduce sync points; avoid frequent CPU round-trips.
Listes de contrôle / plan étape par étape
Étape par étape : du signal « GPU lent » à la cause racine
- Capturez une baseline. Enregistrez le temps par étape, le débit et les identifiants matériels pour une exécution. Si vous ne pouvez pas comparer, vous ne pouvez pas déboguer.
- Vérifiez la santé du GPU. Lancez
nvidia-smi, vérifiez erreurs/ECC, clocks et puissance. - Vérifiez l’utilisation avec contexte. Utilisez
nvidia-smi dmonpendant que le job est actif ; corrélez les creux avec les logs du dataloader. - Validez la topologie. Confirmez la largeur/génération du lien PCIe et l’affinité NUMA. Corrigez d’abord les mauvais placements évidents.
- Inspectez la pression hôte. iowait CPU, utilisation du swap, pression mémoire et latence du système de fichiers pendant le job.
- Prouvez le débit du pipeline de données. Mesurez les taux de lecture et la latence sur le chemin du dataset ; confirmez le nombre de fichiers et le pattern d’accès.
- Profilez une itération. Identifiez le temps en entrée vs transfert H2D vs calcul GPU vs synchronisation.
- Changez une variable à la fois. Taille de batch, num_workers, profondeur de prefetch, mode de précision. Mesurez après chaque changement.
- Déployez prudemment. Gatez les changements avec une petite suite performance+correction ; évitez les basculements globaux sans canaris.
Checklist : « Nous allons acheter des GPU »
- Décidez si vous êtes limités par le calcul ou par la mémoire/bande passante via le profiling, pas l’intuition.
- Budgetez pour le stockage et le réseau. Vos GPU ne sont aussi rapides que vos entrées et votre all‑reduce.
- Validez l’alimentation et le refroidissement pour des charges soutenues, pas des démonstrations en rafale.
- Standardisez une matrice driver/toolkit connue et intégrez‑la dans le provisioning.
Checklist : « Nous allons lancer du multi‑GPU / distribué »
- Confirmez la topologie NCCL et l’affinité NIC.
- Éliminez les têtes lentes : dataloading cohérent, pinning CPU cohérent, IO cohérent.
- Mesurez l’efficacité de mise à l’échelle à 1, 2, 4, 8… GPUs. Arrêtez‑vous quand les gains s’aplatissent et corrigez la contrainte.
FAQ
1) Pourquoi mon utilisation GPU est faible alors que l’entraînement est lent ?
Une faible utilisation accompagnée d’un entraînement lent signifie généralement que le GPU attend : dataloading, latence de stockage, transformations CPU, ou synchronisation.
Vérifiez la consommation électrique et les clocks ; puis l’iowait et la latence de lecture du dataset.
2) 100 % d’utilisation GPU est‑ce un bon objectif pour des services d’inférence ?
Pas si vous tenez à la latence. Pour l’inférence en ligne, maintenir le système « chaud » augmente souvent la latence tail et vous rend fragile face aux pics de trafic.
Ciblez les SLOs (p95/p99) et la planification de capacité, pas des trophées d’utilisation.
3) Comment savoir si je suis limité par le calcul ou par la mémoire ?
Un indice rapide : une forte utilisation SM et une forte consommation électrique suggèrent une pression de calcul ; un SM faible mais un fort débit mémoire suggère un comportement limité par la mémoire.
La vraie réponse vient du profiling : il faut voir où le temps est passé et si les noyaux sont limités par la bande passante.
4) Pourquoi ai‑je des CUDA OOM après des heures d’entraînement ?
Causes courantes : fragmentation due à des formes variables, allocations en cache qui croissent, ou une fuite (stocker des tenseurs dans une liste, accumuler des graphes).
Surveillez la mémoire de pointe au fil du temps, imposez des limites de forme, et n’accrochez pas involontairement des graphes de calcul.
5) La mémoire verrouillée (pinned) aide‑t‑elle toujours ?
Elle aide pour les transferts hôte→device et les copies asynchrones, mais trop de mémoire locked peut nuire à l’hôte en réduisant la flexibilité de la mémoire pageable.
Utilisez‑la intentionnellement : activez‑la pour les buffers du dataloader, pas pour tout.
6) Pourquoi le multi‑GPU est‑il plus lent que le GPU unique ?
Parce que vous avez ajouté de la communication et de la synchronisation. Si votre batch est trop petit, l’all‑reduce domine.
Si un worker est plus lent (IO, CPU, NUMA), tout le monde attend. Corrigez les têtes lentes et validez la topologie NCCL.
7) Dois‑je toujours activer la précision mixte ?
Activez‑la lorsqu’elle aide mesurablement et qu’elle est prouvée n’abîmer pas la correction. Certains modèles requièrent des opérations FP32 sélectives, un loss scaling stable,
ou des hyperparamètres différents. Traitez‑la comme un changement d’ingénierie avec des tests.
8) Pourquoi l’entraînement s’accélère quand je copie le dataset sur un NVMe local ?
Parce que les systèmes de fichiers partagés échouent souvent sur des patterns d’accès riches en métadonnées, beaucoup de petits fichiers, ou une forte concurrence.
Le NVMe local réduit la latence, évite les voisins bruyants, et transforme « l’enfer des lectures aléatoires » en quelque chose que le noyau peut mettre en cache et préfetcher.
9) Les mises à jour de drivers améliorent‑elles les performances ?
Parfois. Elles peuvent aussi régressiver les performances ou casser la compatibilité. Épinglez des versions, testez les mises à jour sur un canari,
et ne déployez que si vous pouvez mesurer le bénéfice.
10) Comment prévenir les surprises du type « GPU tourne à de faibles fréquences » ?
Surveillez les clocks, les limites de puissance et les raisons de throttling. Appliquez des réglages de base via le provisioning, et alertez sur les dérives.
La plupart des « ralentissements mystères » proviennent de changements de politique, pas de la physique.
Conclusion : prochaines étapes actionnables
Les mythes GPU persistent parce qu’ils rassurent. « Le GPU est sous‑utilisé » donne l’impression d’une action possible.
« Notre agencement de stockage provoque de la contention métadonnées sous concurrence » semble être du vrai travail. Faites le travail.
Prochaines étapes :
- Choisissez un job représentatif et enregistrez une baseline de bout en bout : temps par étape, débit, puissance/clocks GPU et latence IO.
- Exécutez le playbook de diagnostic rapide quand la performance change. Ne commencez pas par des mises à jour de drivers ; commencez par les contraintes.
- Standardisez des vérifications de sanity node (largeur/génération PCIe, affinité NUMA, clocks, versions de drivers) et differez‑les quand ça change.
- Corrigez d’abord les goulots ennuyeux : format du dataset, cache local, mémoire pinned et placement CPU. Les GPU récompensent la discipline.