Pénurie de GPU : comment les joueurs sont devenus des dommages collatéraux

Ce qui s’est réellement passé : une pénurie est une file d’attente

Appeler cela une « pénurie de GPU » fait penser qu’un seul méchant a volé toutes les cartes graphiques. La réalité est plus terne et plus brutale : nous avons construit une file d’attente mondiale, puis fait semblant qu’elle n’existait pas.

Quand la demande explose et que l’offre ne peut pas monter en cadence rapidement, vous n’obtenez pas « pas de GPU ». Vous obtenez de l’allocation. Quelqu’un est servi en premier : les fournisseurs cloud avec contrats à long terme, les acheteurs d’entreprise avec engagements de volume, les OEM avec bons de commande prévisibles, et—oui—les personnes qui lancent des bots qui se comportent comme des traders haute fréquence mais pour le RGB.

Les joueurs se sont retrouvés mis en retrait parce que le segment gaming est le moins lié contractuellement. Il est aussi le plus fragmenté. Des millions d’acheteurs individuels sont faciles à ignorer comparés à une poignée de clients qui signent des accords pluriannuels et peuvent déplacer les marchés avec une seule réservation de capacité.

Deux chiffres qui décident discrètement de votre sort

• Temps pour monter en capacité : construire une nouvelle capacité de semi-conducteurs se mesure en années, pas en trimestres.
• Valeur marginale par heure-GPU : si un datacenter peut facturer un GPU à des tarifs entreprise 24/7, une vente ponctuelle au consommateur est moins attractive—surtout quand l’offre est tendue.

En tant que SRE, je reconnais immédiatement ce schéma : quand un service est surchargé, il n’échoue pas « équitablement ». Il échoue en faveur de ceux qui ont des retries, de la priorité et de la persistance. L’inventaire retail des GPU s’est comporté comme une API surchargée sans limitation de débit. Et les bots étaient les seuls clients à savoir parler ce langage.

Faits rapides et contexte historique (la liste « ah, voilà pourquoi »)

Voici des points concrets qui rendent les dernières années de chaos autour des GPU moins mystérieuses—et plus prévisibles.

1. Les GPU modernes reposent sur du packaging avancé (comme les approches de type CoWoS pour le calcul haut de gamme), et la capacité de packaging peut devenir un goulot même si la capacité wafer existe.
2. L’approvisionnement en mémoire GDDR compte : une carte graphique n’est pas « un GPU plus un ventilateur ». Si les allocations de VRAM sont serrées, les cartes ne sont pas assemblées.
3. Les délais sont longs par conception : la production de semi-conducteurs est planifiée très en avance ; « faites-en plus au dernier moment » n’existe pas.
4. Les consoles entrent en concurrence pour les mêmes chaînes : quand une nouvelle génération de consoles monte en cadence, elles consomment substrats, mémoire et capacité logistique que les GPU consommateurs utilisent aussi.
5. La demande liée au crypto-minage a connu des cycles et est singulièrement élastique : les mineurs achètent tant que la rentabilité tient, puis revendent des cartes usagées quand elle s’effondre.
6. Les centres de données ont normalisé l’accélération GPU : les GPU sont devenus la norme pour l’entraînement ML et de plus en plus pour l’inférence, orientant le « meilleur silicium » vers l’entreprise.
7. Les changements de génération PCIe n’étaient pas le goulot, mais ils ont augmenté la rotation des plates-formes et les mises à jour de cartes mères—amplifiant les dépenses totales par configuration.
8. La logistique de l’ère COVID n’a pas seulement ralenti les expéditions ; elle a faussé les prévisions. Quand tout le monde commande par panique, la prévision devient de l’astrologie sur tableurs.
9. La qualité du marché de l’occasion s’est dégradée après les périodes de minage intensif : plus de cartes avec ventilateurs fatigués, problèmes thermiques VRAM et pannes intermittentes.

Le changement de demande : joueurs vs trois industries aux portefeuilles plus gros

La demande gaming n’a pas disparu. Elle a été surenchérie et priorisée différemment par des industries qui traitent les GPU comme des équipements d’investissement. Si vous aviez l’habitude de voir les GPU comme « une chose qu’on achète », c’est le renversement mental : pour beaucoup d’acheteurs, les GPU sont désormais « une chose dont on loue le temps », et le marché de la location pousse l’allocation matérielle en amont.

1) Cloud et entreprise : le GPU comme moteur de revenus

Les fournisseurs cloud n’achètent pas des GPU parce qu’ils aiment le ray tracing. Ils les achètent parce que les GPU transforment l’électricité en factures. Le matériel reste dans une baie, amorti sur des années, utilisé presque 24/7, facturé à l’heure. Ce taux d’utilisation change tout.

Les GPU grand public sont souvent inactifs. Même les joueurs dédiés dorment, travaillent, ou prétendent sortir. Un GPU de datacenter ne dort pas ; il change juste de locataire.

Quand l’offre est contrainte, les vendeurs allouent aux demandes prévisibles et contractuelles. En pratique, cela signifie que les hyperscalers et grandes entreprises obtiennent les premiers choix sur les SKU désirables ou les bins de silicium. Le retail reçoit le reste, quand il reste.

2) IA : une courbe de demande qui se moque de votre week-end

Les charges IA sont une tempête parfaite pour la demande GPU : parallélisables, exigeantes en performance, et de plus en plus indispensables pour les produits compétitifs. Des entreprises qui géraient auparavant des flottes CPU ont commencé à provisionner des clusters GPU. Puis elles ont réalisé que l’inférence voulait aussi des GPU. Puis elles ont réalisé que l’inférence les veut tout le temps.

Et parce que l’IA est désormais une priorité au niveau du conseil d’administration dans de nombreuses entreprises, le budget GPU provient d’« investissement stratégique », pas d’un « centre de coût IT ». Cela signifie moins de contraintes d’achat et plus de volonté de signer des engagements longs.

3) Crypto et spéculation : une demande qui arrive comme un DDoS

Les booms du minage se sont comportés comme une attaque DDoS sur l’inventaire retail. Ils ont été insensibles au prix jusqu’à ce que la rentabilité bascule. Le résultat n’a pas été seulement « plus d’acheteurs », mais une classe d’acheteurs optimisés pour acquérir à grande échelle, souvent avec automatisation et disposition à payer au-dessus du MSRP.

Puis arrive la phase de krach et le marché de l’occasion inonde l’offre. Cela aide la disponibilité mais crée une loterie de fiabilité pour les joueurs—parce que les cartes avaient un travail différent avant que vous ne les adoptiez.

Blague courte #1 : Acheter un GPU en période de pénurie ressemblait à du scalp de billets, sauf que le concert était votre propre ordinateur qui démarre correctement.

Le côté offre : fonderies, packaging, mémoire et contraintes ennuyeuses

Les gens aiment une narration nette : « il suffit de fabriquer plus de GPU. » Si vous avez déjà tenté de monter un système en production, vous savez que scaler n’est jamais « ajouter des serveurs ». Avec les puces, les « serveurs » sont les fonderies, et les fonderies sont incroyablement chères, lentes à construire, et contraintes par des équipements et matériaux spécialisés.

Capacité wafer et nœuds de processus

Les GPU avancés utilisent souvent des nœuds de pointe où la capacité est finie et partagée avec les SoC de smartphone, les CPU serveur et d’autres siliciums à forte marge. Quand plusieurs industries veulent le même nœud, quelqu’un est rationné. Devinez qui n’a pas un contrat pluriannuel take-or-pay ?

Même si un vendeur veut plus de wafers, le foundry doit avoir la capacité. Et s’il ne l’a pas, vous ne pouvez pas « commander plus fort ». Vous pouvez redessiner sur un autre nœud—lent, risqué et pas toujours rentable—ou accepter l’allocation.

Rendement : la partie que personne ne veut expliquer à la caisse

Le rendement est le pourcentage de dies sur un wafer qui sont fonctionnels à un niveau de qualité donné. Les GPU haut de gamme ont de gros dies, ce qui complique le rendement. Tôt dans un cycle produit, les rendements peuvent être plus faibles, ce qui signifie moins de puces haut de gamme par wafer. Les vendeurs peuvent recycler des dies imparfaits en SKU inférieurs, mais cela ne résout pas entièrement le problème si la demande est concentrée sur le haut de gamme.

Packaging et substrats : le goulot discret

Même avec de bons départs wafer, il faut empaqueter les puces. La capacité de packaging avancé n’est pas infinie, et les substrats peuvent être contraints. C’est l’équivalent chaîne d’approvisionnement d’avoir des serveurs applicatifs parfaitement sains mais pas assez d’équilibrages de charge. C’est embarrassant, mais ça arrive.

Mémoire et composants de carte

La VRAM est une chaîne d’approvisionnement à part entière. La production GDDR concurrence d’autres marchés mémoire, et les partenaires de cartes comptent sur un flux régulier de composants VRM, condensateurs et connecteurs. Une pénurie d’un petit composant peut bloquer un produit fini entier, parce qu’on ne peut pas expédier « une carte GPU presque complète ».

Logistique et distribution retail

Enfin, l’expédition et le retail comptent. Quand l’inventaire est maigre, les choix de distribution amplifient la perception : si une région reçoit une petite expédition, elle se vend instantanément et donne l’impression qu’il n’y a « pas de stock partout ». En réalité, du stock existe, juste pas là où vous êtes, pas quand vous regardez, et pas sous une forme qui vous plaît (bonjour, bundles forcés).

Dynamique du commerce de détail : bots, bundles, et pourquoi le « MSRP » est devenu art de la performance

Le retail est l’endroit où la pénurie est devenue personnelle. Pas parce que la chaîne d’approvisionnement amont se souciait de votre configuration, mais parce que le retail est optimisé pour le débit, pas pour l’équité. En période de demande extrême, le chemin le plus simple pour « vendre rapidement l’inventaire » devient « le vendre à celui qui peut cliquer le plus vite ». Ce sont les bots.

Bots et tempête de retries

Pensez à un site retail comme à une API. Sous charge, les utilisateurs normaux se comportent poliment : ils rafraîchissent de temps en temps, cliquent une fois, attendent. Les bots ne font pas ça. Ils martèlent les endpoints, font tourner des identités, et exploitent tout avantage de latence. Si le site manque de mise en file robuste, de limitation de débit et d’anti-automation, l’issue est déterministe : les bots gagnent.

Bundles et remplissage de canal

Les bundles sont une réponse rationnelle à un marché cassé. Les détaillants utilisaient des bundles pour augmenter la marge, écouler des stocks morts, et réduire l’arbitrage des scalpeurs. Les joueurs l’ont vécu comme une taxe : achetez une carte plus une alimentation que vous ne vouliez pas, ou n’achetez pas de carte.

Scalpeurs : symptôme, pas cause racine

Les scalpeurs n’ont pas créé la pénurie ; ils l’ont exploitée. En termes SRE, ce ne sont pas l’incident. Ce sont le voisin bruyant qui vous montre que votre système n’a pas de quotas.

Si vous voulez réduire le scalp, ne moralisez pas. Concevez pour des clients adversariaux : files appliquées, identités vérifiées, limites d’achat qui fonctionnent réellement, et stratégies de libération d’inventaire qui n’autorisent pas les millisecondes à décider des gagnants.

Le point de vue SRE : les GPU sont une ressource partagée, et les ressources partagées sont exploitées

Dans les systèmes de production, la rareté se transforme en politique. La rareté des GPU s’est transformée en économie. Mêmes mécanismes.

À l’intérieur des entreprises, l’allocation GPU est devenue un générateur d’incidents interne. Les équipes se sont battues pour l’accès. Les achats ont appris un nouveau vocabulaire (délai, allocation, capacité réservée). Les ingénieurs ont appris que « il suffit de lancer une instance plus grosse » cesse de fonctionner quand l’instance plus grosse est en rupture de stock.

Citation fiabilité (paraphrasée)

Werner Vogels (CTO d’AWS) a une mantra bien connue des opérations—idée paraphrasée : « Tout échoue, tout le temps. » Dans le monde GPU, « tout » inclut les chaînes d’approvisionnement et les bons de commande.

La rareté GPU change les modes de défaillance

• Le risque de capacité se décale à gauche : vous découvrez les pénuries lors de la planification, pas au déploiement—si vous êtes discipliné. Sinon, vous les découvrez pendant une panne et faites semblant que c’était imprévisible.
• La performance devient un budget : vous cessez de demander « est-ce rapide ? » et commencez à demander « est-ce rapide par watt, par dollar, par unité de disponibilité ? »
• La multi-location devient plus méchante : le partage GPU (MIG, vGPU, conteneurs) se généralise, et les effets du voisin bruyant se multiplient.

Pour les joueurs, la leçon opérationnelle est simple : vous ne rivalisez pas avec d’autres joueurs. Vous rivalisez avec l’utilisation. Un GPU qui rend votre jeu 2–4 heures par jour est moins « valable » pour le marché qu’un GPU loué 24/7 pour entraîner des modèles, exécuter de l’inférence, ou calculer des simulations.

Trois mini-histoires d’entreprise du terrain

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

Une entreprise SaaS de taille moyenne a décidé d’ajouter du traitement vidéo accéléré par GPU à son produit. L’équipe a fait la bonne chose sur le papier : prototype, tests de charge, et confirmation qu’une instance GPU unique pouvait gérer le débit attendu. Tout le monde était confiant. Date de lancement verrouillée.

L’hypothèse erronée était discrète : ils ont supposé que les GPU étaient « comme des CPU » en termes d’achats. Ils s’attendaient à monter en capacité en lançant de nouvelles instances le jour où ils en auraient besoin. Leur code infra le supportait. Leur architecture le supportait. Leurs runbooks le supportaient. Leur fournisseur non.

La semaine de lancement est arrivée, et la demande a dépassé les prévisions. L’autoscaling a essayé d’ajouter des nœuds GPU. Le compte cloud avait un quota. La demande d’augmentation de quota est passée en file. Pendant ce temps, les uploads clients s’accumulaient, la latence a grimpé, et les retries ont amplifié l’arriéré. Le service n’a pas échoué rapidement ; il s’est dégradé lentement, ce qui est le type de défaillance le plus coûteux parce que vous continuez à servir de mauvaises expériences au lieu de réduire la charge.

La revue d’incident a été inconfortable parce que personne n’avait « cassé » quelque chose. Le système s’est comporté exactement comme conçu. Le design ignorait simplement que la capacité GPU n’est pas infinie et n’est pas instantanément provisionnable. Ils ont atténué en ajoutant un pipeline de secours CPU (moins bonne qualité, plus lent), en implémentant du contrôle d’admission sur les uploads, et en pré-réservant de la capacité GPU—même si cela a fait mal au budget.

La vraie correction n’était pas technique. C’était de la planification : traiter les GPU comme une ressource contrainte avec des délais, comme l’approvisionnement matériel. La capacité est devenue un risque produit, pas un effet secondaire infra.

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

Une équipe d’analytique d’entreprise gérait un cluster GPU pour l’entraînement de modèles. Ils ont remarqué que les GPU étaient souvent sous-utilisés—workloads en pics, gaps d’inactivité, et beaucoup de temps perdu sur le chargement des données. Quelqu’un a proposé une optimisation : empiler plus de jobs par GPU en augmentant la concurrence et laisser le scheduler « s’en occuper ».

Le premier jour, les graphes d’utilisation avaient l’air fantastiques. Les GPU tournaient à ~90–95 %. L’équipe célébrait. La semaine suivante, les temps d’entraînement se sont dégradés. Pas légèrement—terriblement imprévisibles. Certains jobs terminaient vite ; d’autres ramenaient et timeoutaient. Les ingénieurs ont accusé le réseau, puis le stockage, puis le code du modèle.

Le vrai problème était la contention mémoire et le surcroît de context-switch. En poussant la concurrence trop loin, ils ont provoqué des évictions fréquentes de VRAM, des lancements de noyau supplémentaires, et plus de transferts PCIe. Leur « haute utilisation » était en partie du overhead. Le cluster était occupé, pas productif. En termes SRE : ils ont optimisé une métrique, pas l’expérience utilisateur.

Ils sont revenus à une cible de concurrence plus basse, ont implémenté des limites de mémoire GPU par job, et ajouté une règle au scheduler : si l’empreinte VRAM d’un job dépasse un seuil, il obtient l’accès exclusif au GPU. L’utilisation est redescendue à un chiffre moins impressionnant—et le débit s’est amélioré. Voilà l’âge adulte opérationnel : on arrête de courir après des graphes jolis.

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

Un studio de jeu (ni énorme, ni minuscule) avait besoin de GPU pour la validation de build et les tests automatisés—vérifications de rendu, compilation de shaders, instantanés de performance. Leur responsable procurement a insisté sur une chose douloureusement peu sexy : une prévision matérielle roulante mise à jour mensuellement, des relations fournisseurs, et un petit inventaire tampon.

Les ingénieurs grognaient parce que l’inventaire tampon ressemblait à du « matériel inutilisé ». La finance grognait parce que les commandes prépayées et les longs délais sont pénibles. Puis le marché s’est tendu. Soudain, tout le monde était « surpris » par les pénuries—sauf ce studio, qui avait déjà des bons de commande passés des mois à l’avance et une réserve de cartes de génération précédente gardée pour les urgences.

Quand une pipeline de build critique a commencé à échouer à cause d’un lot de GPU défectueux (ventilateurs qui lâchent tôt sous charge continue), le studio a basculé immédiatement sur les unités tampon, isolé le lot défectueux, et livré à temps. Pas de héros. Pas de cellule de crise nocturne. Juste un plan ennuyeux exécuté comme si ça comptait.

C’est la leçon que les gens détestent : la fiabilité ressemble souvent à de la capacité « gaspillée » jusqu’au jour où elle ne l’est plus. Là, elle ressemble à de la compétence.

Playbook de diagnostic rapide : quoi vérifier en premier, deuxième, troisième

Quand quelqu’un dit « le GPU est lent » ou « nous avons besoin de plus de GPU », ne supposez rien. Les GPU échouent de manières qui ressemblent à des problèmes GPU mais sont en réalité CPU, stockage, réseau, thermiques, pilotes, ou politique de scheduler.

Premier : confirmer que le GPU est réel, sain, et réellement utilisé

• Le GPU attendu est-il présent, avec le pilote attendu ?
• L’utilisation est-elle élevée quand elle devrait l’être, ou le GPU est-il inactif pendant que le job attend autre chose ?
• La carte est-elle limitée en puissance ou en throttling thermique ?

Deuxième : identifier la catégorie dominante du goulot

• Limité par le calcul : forte utilisation GPU, clocks stables, VRAM proche de l’attendu, faible attente CPU hôte.
• Limité par la mémoire : VRAM proche de la limite, forte utilisation du contrôleur mémoire, allocations fréquentes, page faults/OOM kills.
• Limité par le pipeline de données : utilisation GPU en dents de scie ; iowait CPU élevé ; lectures disque lentes ; réseau saturé.
• Limité par la planification : le temps en file domine ; les GPU sont inactifs parce que les jobs ne peuvent pas atterrir à cause de politiques, fragmentation, ou manque de VRAM adaptée.

Troisième : décider d’upscaler, de scaler horizontalement ou de réparer le pipeline

• Monter en puissance si vous êtes limité par le calcul et ne pouvez pas paralléliser efficacement.
• Scalage horizontal si la charge se partitionne proprement et que le réseau/stockage suit.
• Réparer si l’utilisation est basse à cause d’une famine d’entrée, d’un mauvais batching, de transferts excessifs, ou de pilotes mal configurés.

Blague courte #2 : Si votre GPU est à 2 % d’utilisation, félicitations—vous avez construit un radiateur extrêmement cher via PCIe.

Tâches pratiques (avec commandes) : vérifier, diagnostiquer et décider

Vous vouliez de l’actionnable. Voici des tâches que je lancerais réellement sur une machine Linux en production ou un poste de travail sérieux. Chaque point inclut ce que la sortie signifie et quelle décision prendre ensuite.

Task 1: Confirm the kernel sees the GPU

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

Ce que cela signifie : Le périphérique PCIe est présent et identifié. Si rien n’apparaît, vous avez peut-être un problème d’insertion/alimentation/BIOS.

Décision : Si absent, stoppez. Vérifiez les connecteurs d’alimentation physiques, les réglages BIOS (Above 4G decoding), et la configuration du slot de la carte mère avant d’accuser les pilotes.

Task 2: Check NVIDIA driver presence and basic telemetry

cr0x@server:~$ nvidia-smi
Wed Jan 22 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 RTX A5000               Off | 00000000:01:00.0 Off |                  N/A |
| 30%   49C    P2              112W / 230W |   8120MiB / 24576MiB |     76%      Default |
+-----------------------------------------+----------------------+----------------------+

Ce que cela signifie : Le pilote est chargé, le GPU est actif, l’utilisation et la mémoire sont visibles. P2 indique un état de performance ; pas toujours les clocks max.

Décision : Si nvidia-smi échoue, corrigez les pilotes avant d’ajuster les workloads. Si l’utilisation est basse alors que des jobs tournent, vous êtes probablement lié par l’entrée ou mal configuré.

Task 3: Watch utilization over time to see starvation patterns

cr0x@server:~$ nvidia-smi dmon -s pucm
# gpu   pwr  u  c  m
# Idx     W  %  %  %
    0   115 78 68 33
    0   112 12 10 31
    0   118 81 70 35

Ce que cela signifie : Un usage en dents de scie (78 % puis 12 % puis 81 %) pointe souvent vers des blocages de chargement de données ou des points de synchronisation.

Décision : Si l’utilisation oscille, inspectez CPU, disque et réseau avant de commander plus de GPU.

Task 4: Check GPU clocks and throttling reasons

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,THERMAL | sed -n '1,120p'
==============NVSMI LOG==============
Clocks
    Graphics                    : 1815 MHz
    SM                          : 1815 MHz
    Memory                      : 7001 MHz
Power Readings
    Power Draw                  : 118.34 W
    Power Limit                 : 230.00 W
Temperature
    GPU Current Temp            : 50 C
    GPU Shutdown Temp           : 95 C
    GPU Slowdown Temp           : 83 C

Ce que cela signifie : Températures saines, loin du seuil de ralentissement. Si les températures sont proches du seuil, les clocks baisseront et la performance s’effondrera.

Décision : Si limitation thermique, dépoussiérez, améliorez le flux d’air, refaites la pâte thermique si nécessaire, ou réduisez volontairement la limite de puissance pour stabiliser.

Task 5: Verify PCIe link width and speed (common hidden limiter)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x8

Ce que cela signifie : Le slot supporte x16, mais vous tournez à x8—parfois acceptable, parfois un vrai goulot selon les transferts.

Décision : Si c’est inattendu (devrait être x16), vérifiez le partage de lanes de la carte mère, les réglages BIOS, les risers et le choix de slot. Corrigez avant d’acheter du matériel.

Task 6: Check system load and CPU bottlenecks (GPU idle because CPU can’t feed it)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(32 CPU)

11:03:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
11:03:02 AM  all  72.10  0.00  8.20    9.80 0.00  0.60   0.00  9.30
11:03:03 AM  all  70.85  0.00  7.95   10.10 0.00  0.55   0.00 10.55

Ce que cela signifie : Un iowait élevé (~10 %) suggère des stalls sur le stockage. Le CPU est aussi occupé. Le GPU peut attendre des données.

Décision : Si l’iowait est élevé, allez aux métriques disque et au comportement des jeux de données/caches. Ne touchez pas aux réglages GPU pour l’instant.

Task 7: Identify storage latency causing pipeline stalls

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          68.50    0.00    8.00   10.20    0.00   13.30

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         220.0  35200.0     0.0   0.00    1.20   160.0    40.0   9600.0    2.10   0.55  35.0
sda             180.0   7200.0     2.0   1.10   22.50    40.0    30.0   2400.0   18.90   6.10  98.0

Ce que cela signifie : sda est saturé à ~98 % avec des attentes ~20 ms. C’est le classique « GPU affamé par disque lent ».

Décision : Déplacez les datasets sur NVMe, ajoutez du caching, ou préchargez/bufferisez en RAM. Plus de GPU n’aidera pas si sda est le point de congestion.

Task 8: Check memory pressure and swapping (silent performance killer)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        98Gi       3.2Gi       2.1Gi        24Gi        18Gi
Swap:           16Gi       6.8Gi       9.2Gi

Ce que cela signifie : L’utilisation du swap est non négligeable. Si votre data loader swap, votre GPU restera inactif pendant que l’OS thrash brutalement.

Décision : Réduisez la taille des batchs, corrigez les fuites de mémoire, augmentez la RAM, ou reconfigurez le caching. Le swap dans un pipeline GPU est une panne auto-infligée.

Task 9: Watch per-process GPU memory and utilization

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   jpg   ofa   command
    0      24711     C     72    31     0     0     0     0   python
    0      25102     C      4     2     0     0     0     0   python

Ce que cela signifie : Un job utilise le GPU ; un autre ne fait presque rien mais retient malgré tout des ressources.

Décision : Tuez ou replanifiez les processus de faible valeur. Faites respecter des politiques de scheduling pour que les « petits » jobs ne squattent pas la VRAM.

Task 10: Verify CUDA toolkit compatibility (driver/toolkit mismatch)

cr0x@server:~$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Cuda compilation tools, release 12.4, V12.4.131

Ce que cela signifie : Confirme la version du toolkit installé. Un mismatch entre runtime attendu et pilote peut provoquer crashes ou chemins lents.

Décision : Si des apps requièrent une version CUDA spécifique, alignez images conteneur/base toolkit et pilote. Épinglez les versions ; ne faites pas de freestyle.

Task 11: Check for GPU errors in kernel logs

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|amdgpu|gpu fault' | tail -n 20
[Wed Jan 22 10:41:10 2026] NVRM: Xid (PCI:0000:01:00): 31, pid=24711, name=python, Ch 0000002b, intr 00000000

Ce que cela signifie : Les erreurs Xid peuvent indiquer des bugs de pilote, des clocks instables, une surchauffe, ou du matériel défaillant.

Décision : Si les Xid se répètent, réduisez les overclocks, mettez à jour le pilote, testez avec un workload connu sain, et préparez un RMA si persistant.

Task 12: Validate power delivery (undervoltage = weird crashes)

cr0x@server:~$ sudo sensors | egrep -i 'in12|in5|in3|vcore|temp' | head
Vcore:        +1.08 V
in12:        +11.76 V
in5:          +5.04 V
temp1:        +42.0°C

Ce que cela signifie : Les rails semblent dans les tolérances. Une chute de la ligne 12V sous charge GPU peut provoquer des reset « aléatoires ».

Décision : Si les rails sortent des specs sous charge, remplacez l’alimentation ou redistribuez les câbles d’alimentation (câbles PCIe séparés, pas en chaîne).

Task 13: Check cgroup/container constraints (GPU present, job still slow)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max
200000 100000

Ce que cela signifie : Le CPU est plafonné (équivalent 2 cœurs). Votre job GPU peut être affamé par des limites CPU pour le prétraitement.

Décision : Augmentez les limites CPU pour les pods/conteneurs GPU, ou externalisez le prétraitement. L’accélération GPU n’excuse pas de priver l’hôte.

Task 14: Measure network throughput for remote datasets

cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,20p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  overrun  mcast
    9876543210  8765432  0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier  collsns
    1234567890  2345678  0       3        0        0

Ce que cela signifie : Il y a des drops. Si les RX drops augmentent pendant l’entraînement/le streaming, vous pouvez perdre du débit et provoquer des stalls d’entrée.

Décision : Inspectez les buffers NIC, la congestion des switches, les mismatches MTU, ou localisez les données. Les pipelines GPU détestent la jitter.

Task 15: Identify “queue time” vs “run time” in a scheduler context (Slurm example)

cr0x@server:~$ squeue -u $USER -o "%.18i %.9P %.8j %.8T %.10M %.10l %.6D %R"
12345678 gpu        trainA   RUNNING   00:21:10  02:00:00      1 node17
12345679 gpu        trainB   PENDING   00:00:00  02:00:00      1 (Resources)

Ce que cela signifie : En attente pour cause de ressources, pas parce que le job est cassé. Le goulot est l’allocation, pas le code.

Décision : Si le temps en file domine, envisagez des demandes GPU plus petites, des politiques de packing, MIG/vGPU, ou de la planification hors-pointe.

Task 16: Sanity-check a used GPU for prior abuse (basic fan and thermals check)

cr0x@server:~$ nvidia-smi --query-gpu=fan.speed,temperature.gpu,power.draw,power.limit --format=csv
fan.speed, temperature.gpu, power.draw, power.limit
30 %, 51, 119.02 W, 230.00 W

Ce que cela signifie : Le ventilateur répond, les températures paraissent normales sous charge. Les cartes usées par le minage montrent souvent un comportement de refroidissement dégradé.

Décision : Si les températures montent vite ou que les ventilateurs sont erratiques, prévoyez maintenance (remplacement ventilateur, repaste) ou évitez la carte entièrement.

Erreurs courantes : symptômes → cause racine → correction

1) « L’utilisation GPU est basse, donc il nous faut plus de GPU »

Symptômes : 5–20 % d’utilisation GPU, temps mur élevé, nvidia-smi dmon en dents de scie.

Cause racine : Famine d’entrée : disque lent, réseau lent, goulot CPU de prétraitement, tailles de batch trop petites.

Correction : Déplacez les datasets sur NVMe/SSD local, augmentez le nombre de workers du dataloader, épinglez la mémoire, batchgez plus agressivement, profilez le temps CPU vs GPU.

2) « La performance a chuté après une mise à jour du pilote »

Symptômes : Même code, débit plus lent ; Xid occasionnels ; instabilité étrange.

Cause racine : Mismatch pilote/toolkit, régressions, gestion d’alimentation par défaut différente.

Correction : Épinglez les versions de pilote. Validez les mises à jour sur des nœuds canary. Alignez les conteneurs avec le runtime CUDA supporté par le pilote.

3) « Nous manquons de VRAM, achetez un GPU plus gros »

Symptômes : Erreurs OOM, pagination, gros stalls, crashes aux pics d’utilisation.

Cause racine : Fragmentation VRAM, fuites mémoire, caches non bornés, batch trop grand, précision inefficace.

Correction : Utilisez la mixed precision, gradient checkpointing (ML), réduisez la taille du batch, réutilisez les buffers, limitez les caches, redémarrez les processus long-lived.

4) « Le GPU est installé mais l’app tourne sur CPU »

Symptômes : CPU saturé ; GPU inactif ; logs indiquant un backend CPU.

Cause racine : Bibliothèques runtime manquantes, conteneur non configuré pour l’accès GPU, mauvais flags de build.

Correction : Validez avec nvidia-smi à l’intérieur du conteneur, assurez-vous de la présence de NVIDIA Container Toolkit, vérifiez LD_LIBRARY_PATH et la sélection de device du framework.

5) « Le GPU d’occasion était une bonne affaire, puis il a commencé à planter »

Symptômes : Crashes sous charge, bruit de ventilateur, températures élevées, artefacts intermittents.

Cause racine : Usure par minage : ventilateurs dégradés, pâte thermique sèche, thermiques VRAM, stabilité d’alimentation marginale.

Correction : Stress-testez avant de lui faire confiance ; remplacez ventilateurs/pâte/pads thermiques ; undervoltez ou limitez la puissance ; en cas de doute, ne l’utilisez pas en production critique.

6) « Notre cluster GPU est ‘occupé’ mais l’achèvement des travaux est plus lent »

Symptômes : Forte utilisation, file importante, débit réduit.

Cause racine : Sursouscription, overhead de context-switch, contention mémoire, voisins bruyants.

Correction : Faites respecter des quotas VRAM par job, ajustez la concurrence, utilisez MIG/vGPU correctement, mesurez le taux d’achèvement des jobs et non l’utilisation.

7) « Nous avons acheté des GPU, mais ne pouvons pas les racker assez vite »

Symptômes : Matériel dans les cartons, pas déployé ; projets retardés.

Cause racine : Contraintes d’alimentation/refroidissement, espace en rack, PDUs, câblage, processus de firmware, préparation d’image pilote.

Correction : Planifiez l’alimentation et le refroidissement tôt ; standardisez les images ; pré-déployez le firmware ; ayez une pipeline de burn-in ; traitez le déploiement comme un service de production.

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

Pour les joueurs : achetez plus intelligemment, pas plus en colère

1. Déterminez votre véritable goulot : êtes-vous limité par le GPU, le CPU, la VRAM, ou la résolution/taux de rafraîchissement du moniteur ? N’upgradez pas à l’aveugle.
2. Ciblez la VRAM de façon réaliste : les jeux modernes et les packs de textures punissent la faible VRAM plus qu’ils ne punissent des cœurs légèrement moins puissants.
3. Privilégiez les canaux réputés : évitez les vendeurs du marché gris sauf si vous aimez la comptabilité légale et les litiges de retour.
4. Stress-testez immédiatement : lancez une charge réelle, vérifiez températures, clocks et stabilité tant que les retours sont faciles.
5. Budgetez pour l’ensemble du système : la qualité de l’alimentation, le flux d’air et les contraintes du boîtier peuvent transformer un GPU haut de gamme en machine bridée.
6. Soyez flexibles sur la génération : une génération précédente à un prix raisonnable peut surpasser la génération courante à un prix ridicule, surtout si vous êtes limité par le CPU de toute façon.

Pour les équipes : traitez la capacité GPU comme une capacité de production

1. Prévision mensuelle de la demande : suivez les GPU-heures nécessaires, pas seulement « le nombre de GPU ».
2. Séparez interactif et batch : ne laissez pas les jobs ad-hoc cannibaliser le travail planifié.
3. Réservez une capacité de base : engagez-vous sur un minimum que vous savez utiliser ; burstez stratégiquement.
4. Mesurez le débit de bout en bout : performance du pipeline, pas seulement utilisation GPU.
5. Construisez une voie de secours : une qualité inférieure ou un chemin CPU plus lent vaut mieux qu’une panne totale quand les GPU manquent.
6. Standardisez images et pilotes : l’épinglage de versions réduit les échecs « marche sur le nœud A ».
7. Planifiez l’alimentation et le refroidissement : les GPU convertissent les watts en chaleur avec enthousiasme. L’infra doit suivre.
8. Gardez une petite réserve : quelques cartes/nœuds de rechange peuvent transformer un délai d’approvisionnement en non-événement.

Reality check procurement (la partie que les ingénieurs évitent)

1. Connaissez vos délais et commandez avant d’« avoir besoin » de matériel.
2. Vérifiez les allocations par écrit : « nous prévoyons d’expédier » n’est pas un plan.
3. Qualifiez des alternatives : multiples SKU, multiples fournisseurs, multiples partenaires de carte.
4. Budgetez pour les pièces de rechange et les défaillances : DOA arrive. Les défaillances précoces arrivent. Ne transformez pas ça en crise.

FAQ

1) Pourquoi les fabricants de GPU n’ont-ils pas simplement augmenté la production ?

Parce que la production est contrainte par la capacité des foundries, les rendements, le packaging, l’approvisionnement en VRAM, et des horizons de planification longs. Vous ne pouvez pas « autoscaler » des fonderies.

2) Les scalpeurs sont-ils la raison principale des ruptures de stock ?

Non. Les scalpeurs ont amplifié la rareté et capturé la marge, mais le problème sous-jacent était une demande supérieure à l’offre. Corrigez la conception de la file d’attente et vous réduisez l’impact du scalp.

3) Est-ce que le minage crypto a vraiment autant compté ?

Pendant les périodes de boom, oui—la demande du minage se comportait comme une poussée soudaine insensible au prix ciblant les canaux retail. Quand la rentabilité s’effondre, le marché de l’occasion inonde l’offre, souvent avec du matériel usé.

4) La demande IA est-elle le nouveau moteur « permanent » de pénurie ?

La demande IA est plus structurellement persistante que le minage parce qu’elle est liée aux feuilles de route produit et aux charges d’inférence continues. Elle concentre aussi le pouvoir d’achat entre moins d’acheteurs, mais plus gros.

5) Les joueurs devraient-ils acheter des GPU d’occasion pendant ou après les pénuries ?

Parfois. Mais traitez cela comme l’achat d’une voiture d’occasion qui a peut-être été louée : stress-testez immédiatement, surveillez les thermiques, vérifiez la transférabilité de la garantie, et prévoyez de la maintenance.

6) Pourquoi je vois des GPU « en stock » seulement dans des bundles ?

Les bundles augmentent la marge du détaillant et réduisent l’arbitrage. Ils aident aussi à écouler de l’inventaire moins populaire. C’est une réponse du marché à une demande extrême et une offre mince.

7) Comment un système peut-il avoir une forte utilisation GPU mais être lent ?

Parce que l’utilisation peut être du overhead : context switching, thrash mémoire, kernels inefficients, ou attentes de synchronisation. Mesurez le débit et la latence des jobs, pas seulement l’utilisation.

8) Quelle est la manière la plus rapide de savoir si je suis limité par le GPU ou par les données ?

Surveillez l’utilisation GPU dans le temps (nvidia-smi dmon) et corrélez avec l’iowait CPU (mpstat) et la latence disque (iostat). Une utilisation GPU en pics plus un iowait élevé signifient généralement une limitation par les données.

9) Les cartes avec plus de VRAM sont-elles toujours meilleures pour le jeu ?

Pas toujours, mais le manque de VRAM provoque des saccades et du pop-in de textures qu’aucune vitesse de cœur ne corrige. Si vous jouez en haute résolution avec des titres modernes, la VRAM est souvent la contrainte la plus douloureuse.

10) Que doit faire une organisation si les quotas cloud GPU bloquent la montée en charge ?

Négociez les quotas et la capacité réservée à l’avance, maintenez des modes de secours, et concevez des schedulers qui se dégradent proprement. Le quota est une dépendance de capacité ; traitez-le comme telle.

Conclusion : prochaines étapes réalistes

Les pénuries de GPU n’étaient pas un simple désagrément retail temporaire. Elles étaient la manière dont le marché a admis que les GPU sont désormais une infrastructure stratégique. Les joueurs n’ont rien fait de mal ; ils sont simplement arrivés à un combat à l’arme blanche avec un panier d’achat.

Faites ceci ensuite :

1. Diagnostiquez avant de dépenser : confirmez si vous êtes limité par le GPU, la VRAM, le CPU, ou le pipeline. Les commandes ci-dessus vous y conduiront vite.
2. Planifiez pour les contraintes : si vous êtes une équipe, traitez la capacité GPU comme une capacité de production—prévision, réservation, et petit tampon.
3. Achetez pour la stabilité : évitez les PSU limites, le mauvais flux d’air, et les cartes d’occasion suspectes si vous tenez à la disponibilité (et vous tenez à la cohérence du framerate).
4. Cessez d’adorer l’utilisation : que vous soyez joueur ou gestionnaire de cluster, optimisez l’expérience—images fluides ou achèvement de jobs prévisible—pas une seule métrique jolie.

L’ère de la pénurie a enseigné une vérité utile, si agaçante : les marchés matériels se comportent comme des systèmes distribués sous charge. Si vous voulez équité et fiabilité, vous concevez pour des conditions adversariales. Sinon, le client le plus impitoyable gagne—et ce n’est rarement celui qui tient une manette.