Évolution de la VRAM : du GDDR simple à l’absurdité pure

Ce qu’est vraiment la VRAM (et ce qu’elle n’est pas)

La VRAM est la mémoire à large bande directement attachée au GPU. Ce n’est pas la « RAM GPU » de la même manière que la DRAM système.
Elle est conçue pour alimenter des processeurs massivement parallèles avec un débit prévisible, pas pour être un heap généraliste et convivial.
Le GPU peut désormais faire du paging et de l’oversubscription, certes. Mais si votre working set ne rentre pas, vous le payez d’une manière douloureuse : stalls, copies, ou pics de latence.

Pensez au chemin mémoire GPU comme le ferait un ingénieur stockage :
les unités de calcul sont vos CPU ; la VRAM est votre NVMe local ; le PCIe est votre lien réseau ; la RAM système est un stockage distant ; et le disque est une catastrophe.
Vous pouvez faire fonctionner tout cela. La facture risque de ne pas vous plaire.

La vraie hiérarchie : caches, VRAM, mémoire hôte et le lien entre eux

La plupart des arguments de performance sur la VRAM tombent à l’eau parce que les gens sautent la hiérarchie :

• Caches on-chip (L2, parfois L1/mémoire partagée) sont petits mais rapides et critiques pour la réutilisation.
• VRAM (GDDR/HBM) est votre pool de bande passante principal ; la latence est pire que le cache mais prévisible.
• Mémoire hôte est énorme mais « loin » ; même avec des astuces, c’est un autre monde de latence.
• PCIe / NVLink est la gorge ; quand c’est le facteur limitant, tout le reste est hors sujet.

Votre travail en production n’est pas de mémoriser cela. C’est d’identifier quel niveau vous utilisez accidentellement comme chemin critique.

Une citation à tatouer sur votre runbook

Idée paraphrasée — Gene Amdahl : « L’accélération d’un système est limitée par la partie que vous n’avez pas améliorée. »

Faits et contexte historique (concret, pas vague comme une étiquette de musée)

1. La “VRAM” initiale était littéralement de la video RAM conçue pour des frame buffers et pipelines d’affichage ; l’accélération 3D l’a transformée en ligne d’alimentation pour le calcul.
2. Le GDDR a évolué à partir de la DDR SDRAM mais a priorisé la bande passante et le signaling plutôt que la latence absolue ; les GPU tolèrent la latence en lançant d’autres warps.
3. La largeur du bus est devenue un champ de bataille marketing : 128-bit, 256-bit, 384-bit, et même 512-bit ont été utilisés pour augmenter la bande passante sans packaging exotique.
4. Le GDDR5 a aidé à normaliser les débits « effectifs » sur les fiches techniques ; ce qui compte opérationnellement, c’est la bande passante soutenue selon votre pattern d’accès.
5. La HBM a déplacé le champ de bataille du PCB vers le package : des interposeurs silicium et des dies empilés ont remplacé des acres de routage et des problèmes de bruit d’alimentation.
6. L’ECC sur la VRAM est devenu courant dans les GPU datacenter parce que les erreurs silencieuses à l’échelle ne sont pas « rares », elles sont « hebdomadaires ».
7. La compression mémoire GPU est devenue une vraie fonctionnalité pour le graphisme et parfois le calcul ; elle dépend de la charge de travail, ce n’est pas gratuit.
8. La mémoire unifiée et l’oversubscription existent parce que les gens vont toujours allouer plus que ce qu’ils possèdent ; la performance est la punition.

Blague 1 : la VRAM, c’est comme le minibar d’un hôtel — techniquement disponible, mais si vous en abusez, vous vous ferez facturer au matin.

Du GDDR au GDDR6X : les années du bus large

Pendant longtemps, la stratégie pour plus de bande passante VRAM était simple :
augmenter la vitesse par pin, ajouter des pins, élargir le bus, et prier pour que votre ingénieur PCB ne démissionne pas.
Les générations GDDR racontent essentiellement « jusqu’où peut-on pousser le signaling haute vitesse sur un PCB avant que la physique n’émette une injonction ».

Les calculs de bande passante qui importent vraiment

Le chiffre en une ligne est la bande passante mémoire :

• Bande passante ≈ (débit par pin) × (largeur du bus) ÷ 8

Exemple : 16 Gbps par pin sur un bus 256-bit donne ~512 GB/s de bande passante théorique de pointe. Votre bande passante effective peut être bien plus basse selon les patterns d’accès, la contention et le comportement du contrôleur.

Ce qui rendait le GDDR « simple » (et pourquoi il a cessé de l’être)

« Simple » est relatif. Le GDDR a toujours été exigeant :

• Beaucoup de puces discrètes autour du package GPU, chacune avec des lignes haute vitesse qui doivent être appairées en longueur.
• Beaucoup de complexité en distribution d’alimentation parce que commuter ces signaux à haute fréquence est coûteux.
• Répartition thermique sur la carte : les puces mémoire chauffent ; elles sont proches des VRM ; la circulation d’air n’est jamais aussi bonne que le dessin CAO.

Au fur et à mesure que les taux de signaling augmentaient, les problèmes se sont amplifiés : diaphonie, réflexions, pertes et marges de timing. Le GDDR6X est allé plus loin avec des schémas de signaling plus agressifs pour compresser plus de bits par seconde par pin. C’est excellent pour la bande passante, mais cela rend le système plus sensible à la qualité de la carte, aux thermiques et au réglage. En d’autres termes : c’est plus rapide, et aussi plus capricieux.

Réalité opérationnelle : pourquoi une même « taille VRAM » peut se comporter différemment

Deux GPU peuvent tous deux afficher « 24 GB VRAM » et pourtant se comporter de façon radicalement différente :

• L’un peut avoir un bus 384-bit, l’autre 256-bit.
• L’un peut fonctionner à des débits effectifs plus élevés mais réduire la fréquence en cas de chaleur.
• L’un peut disposer d’un meilleur ordonnancement du contrôleur mémoire pour votre pattern (aléatoire vs streaming).
• L’un peut avoir un L2 plus grand masquant la latence mémoire et réduisant le trafic VRAM.

Si vous traitez la capacité VRAM comme l’histoire complète, vous achèterez le mauvais GPU et passerez des mois à « optimiser » un code qui n’était jamais le vrai facteur limitant.

Arrivée de la HBM : empiler la mémoire comme un rack de datacenter

La HBM (High Bandwidth Memory) est l’admission de l’industrie que pousser toujours plus vite des signaux sur une carte traditionnelle devenait un crime contre la qualité de vie.
L’alternative était folle : placer des piles de mémoire juste à côté du GPU dans le même package, les relier avec un interposeur, et utiliser une interface très large à des fréquences plus basses.

Ce que la HBM change au niveau physique

La HBM empile verticalement plusieurs dies DRAM et les connecte avec des TSV (through-silicon vias). Au lieu d’avoir 8–12 puces discrètes autour du GPU, vous obtenez quelques piles sur le package.
L’interface est extrêmement large, ce qui est la clé : vous obtenez une énorme bande passante sans avoir besoin d’une vitesse par pin folle.

Concrètement, cela signifie :

• Des fils plus courts (sur le package) → meilleure intégrité du signal.
• Fréquence plus basse pour une même bande passante → souvent meilleure efficacité énergétique par bit.
• La complexité du packaging augmente → risque de rendement, coût et contraintes d’approvisionnement.

Le gain caché : moins de contraintes au niveau carte

Avec la HBM, la carte devient moins un champ de bataille de routage haute vitesse. Cela peut améliorer la cohérence entre fournisseurs et réduire les problèmes du type « cette révision de carte est maudite ».
Cela ne les élimine pas : l’alimentation et les thermiques comptent toujours, mais l’interface mémoire est moins exposée à la variabilité du routage sur carte.

Le coût caché : montée en capacité et segmentation produit

La capacité HBM dépend de la taille des piles et du nombre de piles. Vous ne pouvez pas remplacer « quelques puces de plus » comme sur un design GDDR.
Les vendeurs peuvent (et font) utiliser cela pour segmenter les produits : bande passante, capacité et prix deviennent étroitement liés. Si vous avez besoin de plus de VRAM, vous pourriez être obligé d’acheter plus de bande passante que nécessaire — ou l’inverse.

Blague 2 : la HBM, c’est ce qui arrive quand vous dites aux ingénieurs hardware « le routage, c’est dur » et qu’ils répondent en inventant une ville 3D.

Pourquoi la bande passante a gagné (et pourquoi la capacité compte toujours)

Les GPU sont des machines de débit. Ils cachent la latence en gardant beaucoup de travail en vol. Mais ils ne peuvent pas masquer un plafond de bande passante indéfiniment.
Quand vous augmentez le calcul, il faut augmenter l’alimentation en données ou vous construirez une voiture de sport avec une paille pour tuyau à carburant.

Pression sur la bande passante : d’où elle vient dans des charges réelles

• Résolution plus élevée et shaders plus riches en graphisme qui poussent le trafic de textures et de framebuffers.
• L’entraînement IA est essentiellement un générateur de trafic mémoire : activations, gradients, état de l’optimiseur, et lectures/écritures fréquentes.
• L’inférence à petits batchs peut être sensible à la latence et peu favorable au cache, augmentant la pression sur la VRAM et le PCIe.
• Le calcul scientifique touche souvent de grands tableaux avec peu de réutilisation ; vous n’êtes aussi rapide que votre sous-système mémoire.

Pression sur la capacité : pourquoi « ajouter de la VRAM » n’est pas toujours la solution

La capacité importe lorsque le working set ne rentre pas. Mais quand il rentre, vous êtes souvent limité par la vitesse à laquelle vous pouvez le streamer.
Le piège : des gens achètent de la capacité VRAM pour résoudre des problèmes de bande passante et se demandent ensuite pourquoi la performance change à peine.

Heuristique pratique :

• Si vous avez des OOM, vous avez un problème de capacité.
• Si vous n’avez jamais d’OOM mais que l’utilisation est basse, vous avez probablement un problème de bande passante, de latence de lancement de kernels ou de transferts de données.
• Si votre GPU est « occupé » mais lent, vous pouvez être lié au calcul — ou souffrir de mauvais patterns d’accès mémoire qui ressemblent à une haute utilisation de calcul mais se comportent comme des stalls mémoire.

Pourquoi la « vitesse » de la VRAM n’est pas un seul chiffre

La bande passante de pointe n’est pas la bande passante soutenue. La soutenue dépend de :

• Pattern d’accès : coalescé vs dispersé, stride, réutilisation.
• Taux de hit du cache : un L2 plus grand peut transformer un « VRAM-bound » en « cache-bound », ce qui est généralement meilleur.
• Concurrence : trop peu de parallélisme et vous ne cachez pas la latence ; trop et vous thrasherez les caches.
• Comportement thermique : le downclock de la mémoire peut réduire silencieusement la bande passante et créer des régressions « aléatoires ».

Arbitrages d’ingénierie : coût, puissance, rendement et fiabilité

L’évolution de la VRAM n’est pas une ligne droite « meilleur ». C’est une lutte entre la physique, l’économie et l’exploitation.
Si vous gérez des flottes GPU en production, vous vivez à l’intérieur de ces compromis que ça vous plaise ou pas.

GDDR : plus simple à étendre en disponibilité, plus difficile à maîtriser sur la carte

• Avantages : chaîne d’approvisionnement modulaire, souvent moins cher par Go, fabrication mature, configurations de capacité flexibles.
• Inconvénients : complexité de routage sur la carte, défis liés aux hautes vitesses par pin, puissance mémoire et chaleur réparties sur le PCB.

HBM : bande passante élégante, packaging compliqué

• Avantages : bande passante énorme, souvent bonne efficacité énergétique par bit, moins de douleur au niveau routage carte.
• Inconvénients : packaging coûteux, sensibilité au rendement, moins d’options de configuration, et approvisionnement pouvant être tendu en cas de pic de demande.

Fiabilité dans le monde réel : ECC, gestion d’erreurs et pannes « molles »

Si vous faites de l’entraînement ML ou du HPC longue durée, la corruption silencieuse est un ennemi plus grand que les crashs. Un crash est bruyant ; la corruption est chère et silencieuse.
L’ECC sur la VRAM aide, mais ne vous rend pas immortel. Vous avez toujours besoin de :

• Surveillance des erreurs (les erreurs correctibles qui augmentent sont un signal d’alerte).
• Surveillance thermique (la chaleur accélère les défaillances et déclenche le throttling).
• Politiques de quarantaine pour les GPU qui commencent à mal se comporter sous charge.

Note production : « Le job s’est terminé » n’est pas la même chose que « la sortie est correcte ». Traitez les erreurs mémoire GPU comme des événements d’intégrité des données, pas comme des incidents de performance.

Trois mini-histoires d’entreprise depuis le terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse (capacité ≠ localité)

Une équipe a déployé un nouveau service d’inférence sur une flotte de GPU avec beaucoup de VRAM. Le modèle tenait confortablement. Personne n’attendait que la mémoire soit au cœur du problème.
La latence en staging semblait correcte. La production a bien démarré aussi, puis s’est dégradée pendant les plages de pointe. Pas une chute brutale. Un enveniment progressif.

Le premier réflexe de l’on-call a été la taille du batch. Ils l’ont réduite, ont vu une amélioration, et ont déclaré victoire. Deux jours plus tard le même schéma est revenu.
Le vrai symptôme était que l’utilisation GPU oscillait pendant que l’utilisation CPU hôte montait en flèche. Le système faisait du travail — juste pas le travail pour lequel vous payez.

La mauvaise hypothèse : « Si le modèle rentre dans la VRAM, alors la mémoire n’est pas le goulot. » En réalité, le chemin de la requête effectuait une tokenisation dynamique et parfois du feature engineering côté CPU. Chaque requête provoquait plusieurs petits transferts hôte→device. Sous charge, ces transferts se sont serialisés derrière un chemin PCIe saturé et une pile de points de synchronisation.

La correction fut peu glamour : fusionner le prétraitement, regrouper les transferts, utiliser de la mémoire hôte pinned pour un DMA stable, et supprimer les synchronisations implicites dans le handler de requêtes.
La capacité VRAM n’était pas la contrainte. La localité et le comportement des transferts l’étaient.

La leçon retenue : la capacité vous dit « est-ce que ça va crasher », pas « est-ce que ça va monter en charge ». Si vous ne profilez pas le chemin de bout en bout, le lien devient votre réseau de stockage caché — sauf que c’est le PCIe et il ne vous pardonne pas.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux (réutilisation mémoire intelligente vs fragmentation)

Une autre organisation a voulu réduire le coût d’allocation en introduisant un pool de buffers GPU personnalisé. L’intention était bonne : moins d’allocations, moins de frees, moins d’overhead, latence plus stable.
Il a été livré sous forme de bibliothèque partagée utilisée par plusieurs services. Ça « fonctionnait » dans les benchmarks.

En production, un sous-ensemble de workloads a commencé à échouer avec des erreurs out-of-memory bien que nvidia-smi affichait beaucoup de VRAM libre.
Pire, les échecs étaient bruyants et intermittents. Redémarrer le service « corrigeait » généralement le problème jusqu’à ce que ça ne le fasse plus. De la classique bizarrerie d’allocateur, mais sur GPU.

Le pool gardait de grands blocs, et sa stratégie de réutilisation ne correspondait pas à la distribution réelle des tailles d’allocations. Avec le temps, il a transformé la VRAM en une casse de fragments inutilisables.
L’allocateur interne du framework aurait pu mieux gérer ça, mais le pool personnalisé s’y est ajouté et l’a contrarié.

Le rollback fut douloureux car d’autres améliorations de latence avaient été empaquetées dans la même release. Ils ont fini par garder un petit pool pour quelques buffers « hot » et laisser le framework gérer le reste.
Ils ont aussi ajouté une fenêtre de maintenance périodique « défragmentation par redémarrage » pour les pires coupables — ennuyeux, oui, mais mieux que l’agacement du pager.

À retenir : le pooling mémoire peut aider. Mais si vous ne mesurez pas la fragmentation et le comportement à long terme sous trafic réaliste, votre « optimisation » n’est qu’une panne différée.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (budgets d’erreur pour la santé VRAM)

Un cluster GPU utilisé pour des jobs d’entraînement longue durée avait une politique qui ressemblait à de la paperasserie : suivre les erreurs mémoire correctibles par GPU et mettre en quarantaine les dispositifs qui franchissent un seuil.
Les ingénieurs se plaignaient car cela retirait parfois du matériel coûteux « qui fonctionne encore ».

Puis un nouvel entraînement a commencé à produire des métriques subtilement pires. Pas catastrophique. Juste constamment pire. On a débattu dérive des données, seeds aléatoires, et réglages de l’optimiseur.
Pendant ce temps, un nœud montrait une hausse d’erreurs VRAM correctibles pendant les périodes de haute température. Le scheduler avait placé plusieurs runs sur ce nœud pendant des semaines.

Parce que l’organisation avait cette pratique ennuyeuse, le nœud a été automatiquement drainé et le GPU mis en quarantaine. Le job d’entraînement a été relancé ailleurs.
Les métriques sont revenues dans les plages attendues. Pas de debugging héroïque, pas de chasse aux sorcières.

Le postmortem fut court et insatisfaisant dans le meilleur sens : « nous avons détecté une dégradation matérielle tôt et évité la corruption silencieuse. » C’est ce que vous voulez en production : moins d’histoires excitantes.

Tâches pratiques : commandes, signification des sorties et la décision que vous prenez

Voici le type de vérifications que vous pouvez effectuer pendant un incident sans le transformer en projet scientifique.
Les commandes sont orientées Linux et supposent les outils NVIDIA quand pertinent. Adaptez au besoin.

Tâche 1 : Identifier les GPU, les drivers, et si l’OS voit ce que vous pensez qu’il voit

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:41:05 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-PCIE-40GB           On  | 00000000:17:00.0 Off | 0                    |
|  1  NVIDIA A100-PCIE-40GB           On  | 00000000:65:00.0 Off | 0                    |
+-----------------------------------------+----------------------+----------------------|

Ce que cela signifie : Confirme l’inventaire GPU, la version du driver, et des signaux de santé basiques.

Décision : Si des GPU manquent ou si le driver/CUDA est manifestement incompatible, arrêtez d’optimiser les workloads et corrigez d’abord la plateforme.

Tâche 2 : Surveiller l’utilisation VRAM et l’utilisation dans le temps (détecter thrash, pics et inactivité)

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1
# gpu   pwr  ut   mem   sm   enc  dec  mclk  pclk
# Idx     W   %     %    %     %    %   MHz   MHz
    0   210  35    88   34     0    0  1215  1410
    1   115   5    12    3     0    0   405   585

Ce que cela signifie : Le GPU 0 est gourmand en mémoire (88% mem utilisé) avec une utilisation modérée ; le GPU 1 est principalement inactif.

Décision : Si l’utilisation est basse alors que la mémoire est élevée, suspectez des stalls mémoire, des synchronisations ou des problèmes de pipeline d’entrée plutôt que « besoin de plus de GPU ».

Tâche 3 : Confirmer la largeur et la génération du lien PCIe (un tueur de débit silencieux)

cr0x@server:~$ nvidia-smi -q | sed -n '/PCI/,+12p'
    PCI
        Bus                             : 0x17
        Device                          : 0x00
        Domain                          : 0x0000
        Bus Id                          : 00000000:17:00.0
        PCIe Generation
            Max                         : 4
            Current                     : 3
        Link Width
            Max                         : 16x
            Current                     : 8x

Ce que cela signifie : Vous attendiez Gen4 x16 ; vous avez Gen3 x8. C’est un vrai goulot pour les transferts.

Décision : Traitez cela comme un problème matériel/plateforme (slot, BIOS, riser, bifurcation). Ne perdez pas de temps à « optimiser » des kernels pendant que le bus est handicapé.

Tâche 4 : Valider la localité NUMA (le placement de la mémoire CPU affecte les transferts hôte→device)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      PHB     0-31            0
GPU1    PHB      X      32-63           1

Ce que cela signifie : GPU0 est local au noeud NUMA 0, GPU1 au noeud 1. « PHB » indique que le trafic traverse un PCIe Host Bridge.

Décision : Pinner les threads CPU et allouer la mémoire hôte sur le noeud NUMA correct. Si vous ignorez cela, vous générerez de la latence artificielle.

Tâche 5 : Repérer les problèmes ECC VRAM (les tendances correctibles sont des signaux précoces)

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

Ce que cela signifie : Des erreurs correctibles existent et peuvent être en tendance. Les erreurs double-bit (incorrigibles) sont à zéro, c’est bon.

Décision : Si les correctibles agrégés montent rapidement ou corrèlent avec la température/charge, mettez le GPU en quarantaine avant que cela devienne un problème d’intégrité des données.

Tâche 6 : Vérifier l’usage VRAM par processus (trouver le vrai gobeur)

cr0x@server:~$ nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
pid, process_name, used_memory [MiB]
18422, python, 31748 MiB
19103, python,  6020 MiB

Ce que cela signifie : Le PID 18422 possède la VRAM. Vous avez maintenant une cible.

Décision : Si un processus « sidecar » ou un notebook traînard squatte, tuez-le ou déplacez-le. Si c’est le service principal, inspectez le comportement d’allocation et le cache.

Tâche 7 : Chercher les raisons de throttling (votre bande passante peut fondre)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,140p'
Performance State                    : P2
Clocks Throttle Reasons
    Idle                            : Not Active
    Applications Clocks Setting     : Not Active
    SW Power Cap                    : Active
    HW Slowdown                     : Not Active
    HW Thermal Slowdown             : Not Active

Ce que cela signifie : Un power cap logiciel est actif ; les clocks peuvent être bridées.

Décision : Si le power cap est inattendu, vérifiez les limites de puissance, les thermiques et les politiques du datacenter. Un GPU capé peut paraître « mystérieusement lent » sous charge mémoire.

Tâche 8 : Corréler l’activité GPU avec la pression CPU et I/O (ne blâmez pas la VRAM pour des stalls stockage)

cr0x@server:~$ pidstat -dru -p 18422 1 5
Linux 6.5.0 (server)  01/13/2026  _x86_64_  (64 CPU)

10:41:18 PM   UID       PID   %usr %system  %CPU   RSS   kB_rd/s kB_wr/s  iodelay  Command
10:41:19 PM  1001     18422  220.0     8.0 228.0  18G    5120.0    120.0        8  python

Ce que cela signifie : CPU élevé et lectures significatives. Si votre GPU est sous-utilisé, votre pipeline d’entrée peut être le vrai goulot.

Décision : Augmentez le prefetching, utilisez un stockage local plus rapide, ou mettez en place le staging des datasets. Ne chassez pas la bande passante VRAM quand vous affamez le GPU.

Tâche 9 : Vérifier hugepages et limites de mémoire verrouillée (le pinned memory a besoin de support OS)

cr0x@server:~$ ulimit -l
64

Ce que cela signifie : Le processus ne peut verrouiller que 64 KB de mémoire. Les allocations de mémoire hôte pinned peuvent échouer ou se dégrader.

Décision : Pour des services qui comptent sur la mémoire pinned, augmentez les limites memlock (avec prudence) via systemd ou la politique de sécurité, puis validez le comportement.

Tâche 10 : Inspecter les logs système pour événements PCIe/NVRM (les problèmes matériels se déguisent en « code lent »)

cr0x@server:~$ journalctl -k -S -2h | egrep -i 'nvrm|pcie|aer|xid' | tail -n 20
Jan 13 08:55:02 server kernel: pcieport 0000:00:03.1: AER: Corrected error received: id=00e1
Jan 13 08:55:02 server kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Physical Layer
Jan 13 08:55:02 server kernel: NVRM: Xid (PCI:0000:17:00): 79, GPU has fallen off the bus.

Ce que cela signifie : Erreurs PCIe et un Xid indiquant que le GPU est tombé du bus. Ce n’est pas un problème d’« optimisation ».

Décision : Drainer le nœud, vérifier câbles/risers/assise des slots, firmware, alimentation, et envisager le remplacement matériel.

Tâche 11 : Vérifier la fréquence mémoire réelle du GPU sous charge

cr0x@server:~$ nvidia-smi --query-gpu=clocks.mem,clocks.gr,temperature.gpu,power.draw --format=csv -l 1
clocks.mem [MHz], clocks.gr [MHz], temperature.gpu, power.draw [W]
1215, 1410, 78, 232.45
405,  585,  60, 115.10

Ce que cela signifie : Si la fréquence mémoire chute sous charge de façon inattendue, vous êtes probablement en throttling (puissance/thermique) ou en état de performance inférieur.

Décision : Améliorez le refroidissement, les limites de puissance, ou la politique d’horloges d’application. Sinon, les graphiques de bande passante vous mentiront.

Tâche 12 : Confirmer que le conteneur voit les mêmes capacités GPU (mismatches cgroups/runtime)

cr0x@server:~$ docker exec -it ml-infer bash -lc 'nvidia-smi -L'
GPU 0: NVIDIA A100-PCIE-40GB (UUID: GPU-2c1b0f0a-1a7c-9c1a-bd73-3b0b62f4d2b2)

Ce que cela signifie : Le conteneur a accès au GPU. S’il ne l’a pas, vous verrez des fallbacks CPU et une mauvaise « performance VRAM » (parce que vous n’utilisez pas la VRAM).

Décision : Corrigez la configuration du runtime avant de toucher le code du modèle.

Tâche 13 : Mesurer le débit PCIe pendant les transferts (détecter la domination host-device)

cr0x@server:~$ nvidia-smi dmon -s t -d 1
# gpu    rxpci   txpci
# Idx   MB/s    MB/s
    0    9800    2100

Ce que cela signifie : Trafic PCIe important en réception. Si votre temps de kernel est faible, les copies peuvent dominer la latence.

Décision : Réduisez les transferts (batching, fusion), utilisez la mémoire pinned, et évitez les points de sync qui sérialisent les copies et le calcul.

Tâche 14 : Inspecter l’allocation mémoire NUMA CPU pendant que le GPU est occupé

cr0x@server:~$ numastat -p 18422
Per-node process memory usage (in MBs) for PID 18422 (python)
Node 0          14820.5
Node 1           120.0
Total          14940.5

Ce que cela signifie : La mémoire hôte du processus est majoritairement sur le Node 0. Si elle alimente le GPU1 sur le Node 1, vous forcez du trafic inter-socket.

Décision : Pinner le processus sur le CPU proche de son GPU et allouer la mémoire localement (numactl ou pinning au niveau service).

Mode opératoire de diagnostic rapide : trouver le goulot en quelques minutes

Quand un workload GPU est lent, vous n’avez pas le droit de deviner. Vous triez. L’objectif est d’identifier le niveau limitant — calcul, bande passante VRAM, capacité VRAM, transferts PCIe/NVLink, pipeline d’entrée CPU, ou throttling — avant de toucher au code.

Première étape : établir si le GPU est réellement occupé

• Exécutez nvidia-smi et nvidia-smi dmon.
• Si l’utilisation GPU est basse : suspectez la famine de données, la synchronisation, le pipeline CPU, ou l’overhead des transferts.
• Si l’utilisation GPU est élevée : vous pourriez être compute-bound ou bandwidth-bound ; poursuivez l’investigation.

Deuxième étape : vérifier les « mensonges faciles » (throttling et problèmes de bus)

• Confirmez Gen et largeur du lien PCIe : nvidia-smi -q.
• Vérifiez les raisons de throttling : nvidia-smi -q -d PERFORMANCE.
• Scannez les logs kernel pour AER/Xid : journalctl -k.

Si l’un d’eux est mauvais, arrêtez. Corrigez la santé de la plateforme. Le tuning de performance sur une tuyauterie cassée n’est que du spectacle.

Troisième étape : décider si c’est de la pression de capacité ou de bande passante

• Pression de capacité : OOM, évictions fréquentes/oversubscription, VRAM proche de 100% avec churn.
• Pression de bande passante : la VRAM tient mais la vitesse est faible ; les kernels montrent une forte charge mémoire et une faible intensité arithmétique ; la fréquence mémoire et les patterns d’utilisation correspondent.

Quatrième étape : valider les transferts et la localité

• Utilisez nvidia-smi dmon -s t pour voir les niveaux de trafic PCIe.
• Utilisez nvidia-smi topo -m et numastat pour vérifier le placement NUMA.
• Si le service est conteneurisé, confirmez la visibilité GPU à l’intérieur du conteneur.

Cinquième étape : seulement alors profilez en profondeur

Une fois que vous avez établi que le GPU est sain, correctement lié, non bridé, et pas affamé, sortez les outils de profilage plus profonds.
Sinon vous générerez des graphiques qui n’expliquent rien.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « La VRAM est pleine, mais la performance est correcte… jusqu’à ce que non »

Cause racine : fragmentation de l’allocateur ou comportement de cache qui réduit lentement l’espace contigu utilisable.

Correction : réduisez la variété des buffers longue durée, évitez les pools custom sauf si vous pouvez mesurer la fragmentation, et planifiez des redémarrages contrôlés pour les fuites connues.

2) Symptom : faible utilisation GPU, latence élevée, et fort trafic PCIe

Cause racine : les copies host→device dominent ; trop de synchronisation force une exécution sérielle.

Correction : regroupez les transferts, utilisez la mémoire pinned judicieusement, superposez copies et calcul, et retirez les synchronisations implicites dans le code de requête.

3) Symptom : régression soudaine après migration vers un GPU avec « VRAM plus rapide »

Cause racine : throttling thermique/puissance ou bande passante effective plus faible due au downclock de la mémoire sous charge soutenue.

Correction : validez les clocks sous charge ; améliorez le refroidissement ; ajustez les limites de puissance si la politique le permet ; assurez-vous que le flux d’air n’est pas bloqué par des câbles.

4) Symptom : hangs GPU intermittents ou jobs échouant sur plusieurs modèles

Cause racine : erreurs PCIe, riser/slot instable, alimentation marginale, ou GPU en fin de vie.

Correction : vérifiez les logs kernel pour AER/Xid ; reseatez le matériel ; mettez à jour le firmware ; mettez en quarantaine les GPU suspects selon la tendance des erreurs.

5) Symptom : job multi-GPU plus lent que single-GPU

Cause racine : limitation interconnect (topologie PCIe, absence de chemins NVLink), ou overhead de synchronisation des gradients dominant.

Correction : vérifiez la topologie avec nvidia-smi topo -m ; pinner les processus ; utilisez la bonne stratégie de parallélisme ; évitez les paires GPU cross-socket.

6) Symptom : OOM alors que de la « mémoire libre » existe

Cause racine : fragmentation, pools réservés, ou multiples processus avec allocateurs séparés.

Correction : identifiez l’usage par processus ; consolidez les processus ou limitez la concurrence ; réduisez la taille d’allocation maximale ; redémarrez pour vider la fragmentation si nécessaire.

7) Symptom : métriques d’entraînement deviennent « bizarres » sans crash

Cause racine : risque de corruption silencieuse, matériel instable, ou nondéterminisme exposé par la précision mixte et des kernels agressifs.

Correction : surveillez les tendances ECC ; isolez le matériel ; effectuez des checks de reproductibilité ; désactivez temporairement les chemins fast-math risqués pour valider.

8) Symptom : « On a ajouté de la capacité VRAM ; la performance n’a pas changé »

Cause racine : vous étiez limited par la bande passante ou les transferts, pas par la capacité.

Correction : mesurez la bande passante obtenue, vérifiez le trafic PCIe, améliorez la localité et les patterns d’accès, et envisagez des GPU avec plus de bande passante ou des caches plus grands.

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

Checklist A : Choisir entre GDDR et HBM (quoi faire, pas quoi débattre)

1. Classifiez la charge : streaming-heavy (bande passante), reuse-heavy (cache), ou capacity-heavy (grand working set).
2. Mesurez le comportement des transferts : débit hôte↔device et fréquence sous trafic réel.
3. Décidez de ce que vous payez :
   • Choisissez HBM quand la bande passante est le facteur limitant et que le packaging premium est justifiable.
   • Choisissez GDDR quand le coût/$ et la flexibilité d’approvisionnement par capacité comptent davantage, et que vos workloads tolèrent une bande passante plus faible.
4. Prévoir les thermiques : si vous ne pouvez pas garder les clocks mémoire stables, la bande passante théorique est de la fantaisie.
5. Planifier la fiabilité : exiger l’ECC là où la correction compte ; définir des seuils de quarantaine et automatiser le draining.

Checklist B : Déploiement en production d’un workload GPU (éviter les pièges classiques)

1. Validez largeur/génération PCIe et la topologie sur chaque classe de nœud.
2. Activez le persistence mode si votre environnement bénéficie d’une initialisation stable et d’un jitter réduit.
3. Définissez et documentez les limites de puissance et la politique d’horloges applicatives ; ne laissez pas cela à la rumeur.
4. Pinner les threads CPU et la mémoire hôte au domaine NUMA du GPU pour les services sensibles à la latence.
5. Instrumentez : utilisation GPU, mémoire utilisée, clock mémoire, RX/TX PCIe, événements ECC, et latence tail.
6. Chargez en test avec des distributions de requêtes réalistes (pas seulement du throughput steady-state).
7. Définissez une réponse opérationnelle : ce qui déclenche un drain, un rollback, ou une quarantaine matérielle.

Checklist C : Quand la perf régresse après une mise à jour driver/kerne

1. Comparez la sortie de nvidia-smi (driver, compatibilité CUDA) avant/après.
2. Vérifiez tout nouveau comportement de throttling sous charge soutenue.
3. Confirmez que la négociation du lien PCIe n’a pas changé (des régressions Gen/width arrivent).
4. Revalidez l’accès GPU du runtime conteneur et les mounts de bibliothèques.
5. Ensuite seulement profilez les kernels et le trafic mémoire ; n’assumez pas que le compilateur s’est dégradé.

FAQ

1) La vitesse de la VRAM, c’est surtout une histoire de MHz ?

Non. La bande passante est le produit du débit par pin et de la largeur du bus (et de l’architecture). Les MHz seuls ignorent la méthode de signaling, la largeur, et l’efficacité du contrôleur.

2) Pourquoi les GPU tolèrent-ils une latence mémoire plus élevée que les CPU ?

Les GPU cachent la latence avec une énorme concurrence : quand un warp bloque, d’autres s’exécutent. Cela marche jusqu’à ce que vous atteigniez un plafond de bande passante ou que votre workload manque de parallélisme.

3) Si mon modèle tient dans la VRAM, puis-je ignorer le PCIe ?

Non. Beaucoup de chemins d’inférence copient encore fréquemment les entrées/sorties, et les pipelines de prétraitement peuvent forcer des synchronisations. Le PCIe devient le goulot silencieux et fiable.

4) La HBM est-elle toujours meilleure que le GDDR ?

Meilleure pour la bande passante par package, souvent meilleure en efficacité, oui. Mais c’est plus cher et les configurations de capacité peuvent être contraignantes. Choisissez selon des goulots mesurés, pas des impressions.

5) Pourquoi je vois des erreurs out-of-memory alors que nvidia-smi montre de la VRAM libre ?

Fragmentation, pools réservés, ou multiples processus avec allocateurs séparés peuvent rendre la « mémoire libre » inutilisable pour une grosse allocation contiguë. Identifiez l’usage par processus et les patterns d’allocation.

6) L’ECC réduit-elle la performance ?

Parfois un peu, selon l’architecture et la charge. En échange, vous avez moins de corruptions silencieuses. Pour l’entraînement ou l’inférence critique, ce compromis vaut généralement le coup.

7) Comment savoir si je suis lié par la bande passante ou par le calcul ?

Signaux rapides : forte utilisation mémoire/trafic avec une utilisation SM modeste suggère une pression sur la bande passante ; forte utilisation SM avec trafic mémoire stable suggère compute-bound.
Confirmez avec du profiling une fois les vérifications de santé plateforme faites.

8) Quelle est la différence pratique entre capacité VRAM et bande passante VRAM ?

La capacité détermine si votre working set tient sans éviction. La bande passante détermine la vitesse à laquelle vous pouvez alimenter le calcul une fois que ça tient.
L’une empêche les crashs ; l’autre empêche les ralentissements.

9) Pourquoi un même GPU se comporte-t-il différemment selon les serveurs ?

La topologie PCIe, le placement NUMA, le refroidissement, les limites de puissance, et même les réglages BIOS peuvent changer la bande passante effective et la stabilité. Traitez les serveurs comme partie intégrante du système GPU.

10) Dois-je compter sur la mémoire unifiée/oversubscription pour « résoudre » les limites VRAM ?

Utilisez-la comme valve de sécurité, pas comme plan. Elle peut sauver la correction, mais la performance peut s’effondrer quand le paging démarre. Si vous en avez besoin régulièrement, achetez plus de VRAM ou repensez la charge.

Étapes suivantes à réaliser

Si vous exploitez des GPU en production, traitez la VRAM comme un sous-système de première classe : elle a de la planification de capacité, de la planification de bande passante, de la surveillance de santé, et des modes de défaillance.
L’évolution du GDDR vers la HBM n’était pas une mode technique ; c’était la réponse de l’industrie à la même contrainte que vous dépannez à 3 h du matin : le mouvement des données.

1. Référencez chaque classe de nœud : Gen/largeur PCIe, topologie, thermiques, limites de puissance, et mode ECC.
2. Instrumentez les bons signaux : VRAM utilisée, clock mémoire, RX/TX PCIe, erreurs ECC, raisons de throttling, et latence tail.
3. Codifiez des règles de quarantaine : tendances d’erreurs correctibles et événements Xid doivent drainer automatiquement les nœuds.
4. Faites de la localité une fonctionnalité de déploiement : pinning NUMA et placement mémoire doivent faire partie de la configuration du service, pas du savoir tribal.
5. Choisissez le hardware sur la base des goulots mesurés : n’achetez pas de capacité pour résoudre la bande passante, et n’achetez pas de bande passante pour résoudre un lien PCIe cassé.

L’ère de la VRAM « pure folie » ne ralentit pas. Le packaging deviendra plus étrange, les caches plus gros, les liens plus rapides, et votre workload trouvera toujours la partie la plus étroite du pipeline.
C’est acceptable. Ne laissez simplement pas cela être une surprise.