Vous pouvez avoir le GPU le plus sophistiqué du marché, un tableau NVMe ultra-rapide et suffisamment de cœurs CPU pour chauffer une petite ville.
Puis un mardi après-midi votre serveur de modèles commence à renvoyer des 500 parce que « CUDA out of memory ».
Pas parce que vous manquiez de calcul. Parce que vous avez manqué de VRAM au pire moment possible.
Après 2026, ce mode de panne ne sera plus un problème de niche pour les laboratoires d’IA. Ce sera une réalité opérationnelle du deuxième jour pour les entreprises normales :
copilotes de support client, scoring de fraude en temps réel, pipelines créatifs, données synthétiques, modèles vidéo et analyses qui se sont « accidentellement » transformées en deep learning.
La VRAM devient la nouvelle planification de capacité disque — sauf que les conséquences arrivent en millisecondes, pas en semaines.
La VRAM est le budget, pas l’ornement
La VRAM était autrefois ce dont les joueurs débattaient sur les forums pendant que tout le monde d’autre haussait les épaules et achetait ce que l’IT validait.
En production pour l’IA et le graphisme, la VRAM est désormais le plafond dur qui décide si vous livrez la fonctionnalité, quel est votre niveau de latence,
et si votre canal d’incidents s’anime à 2 h du matin.
Le schéma central est simple : le calcul a évolué plus vite que la « mémoire utilisable par charge ». Les GPU gagnent en FLOPS.
Parallèlement, les modèles ont grossi, les contextes se sont allongés, le batching s’est amélioré, et tout le monde veut plusieurs locataires concurrents sur le même accélérateur.
La VRAM est l’endroit où ces ambitions se percutent.
En termes SRE : la VRAM est la nouvelle « ressource qu’on ne peut pas exploser ». Le CPU peut piquer. Le disque peut mettre en file d’attente. Le réseau peut tamponner.
La VRAM est une pièce de taille fixe. Une fois pleine, vous ne ralentissez pas en douceur ; vous échouez, vous thrashiez ou vous basculez silencieusement vers un chemin plus lent
qui ruine le SLO et fait mentir votre modèle de coût.
Pourquoi cela s’accélère après 2026
« Après 2026 » n’est pas une date magique. C’est une prédiction sur le moment où plusieurs tendances se cumuleront suffisamment pour que la VRAM devienne le facteur limitant pour plus d’équipes que de cas isolés.
Voici ce qui pousse ce basculement.
1) Les fenêtres de contexte s’allongent, et le cache KV n’est pas gratuit
L’industrie passe de prompts courts et bavards à des interactions longues et état-full : historiques clients, bases de code, documents de politique, traces d’agents en plusieurs étapes.
Pour l’inférence de type transformer, un long contexte signifie un gros cache de clés/valeurs (cache KV).
Ce cache vit en VRAM car il est sur le chemin critique.
Vous pouvez le compresser, le quantifier, le paginer, le sharder — bien sûr. Mais le centre de gravité reste : allonger le contexte déplace le coût du calcul vers la capacité mémoire et la bande passante mémoire.
2) Les modèles multimodaux dévorent la mémoire comme si c’était leur travail
Le texte seul avait déjà étiré la VRAM. Ajoutez images, vidéo, audio, et vous n’ajoutez pas seulement des paramètres.
Vous ajoutez de plus grandes activations, davantage d’états intermédiaires, plus de buffers de pré/post-traitement et plus d’opportunités de fragmentation.
La blague est que « la vidéo n’est que des images dans le temps ». L’addition est que le temps multiplie votre empreinte VRAM.
3) La pression du batching passe de « agréable » à « rentable ou perte »
La plupart des stacks de serving IA améliorent le débit par le batching des requêtes. Le batching veut de la VRAM : plus de séquences simultanées, plus de cache KV, des buffers temporaires plus grands.
Après 2026, davantage d’entreprises exécuteront l’inférence comme un produit, pas comme une démo. Cela signifie une concurrence soutenue, pas une utilisation occasionnelle.
4) Les attentes de fiabilité augmentent plus vite que la marge mémoire
Les outils internes peuvent échouer occasionnellement. Les fonctionnalités AI côté client ne peuvent pas. Si votre VRAM tourne à 92 % en état stable, vous n’avez pas « 8 % de marge ».
Vous avez une panne programmée pour chaque pic de fragmentation ou quand une requête arrive avec un prompt plus long que ce que vous aviez testé.
5) Vous partagerez les GPU plus agressivement
Des GPU dédiés par service sont coûteux et politiquement difficiles à justifier quand les finances découvrent les courbes d’utilisation.
Attendez-vous à plus de GPU multi-locataires utilisant des conteneurs, la partition MIG ou du partage au niveau du scheduler. Le partage augmente la variance.
Variance plus plafonds durs égale bruit sur le pager.
6) La bande passante mémoire devient le gouverneur caché
Même si vous « avez assez de VRAM », vous pouvez ne pas avoir assez de bande passante.
Beaucoup de charges d’inférence sont limitées par la bande passante mémoire, pas par le calcul.
À mesure que les modèles grandissent, l’intensité arithmétique ne vous sauve pas toujours.
Le résultat opérationnel : après 2026, « combien de GPU » devient une question incomplète.
La vraie question est « combien de VRAM par GPU, à quelle bande passante, sous quelle concurrence, avec quel comportement de fragmentation ».
Ce n’est pas de la trivia d’approvisionnement. C’est de l’architecture.
Faits historiques et contexte intéressants (à utiliser en réunion)
- Fait 1 : Les premiers GPU grand public étaient souvent livrés avec « assez de VRAM pour les textures », car la charge dominante était le rendu raster, pas un état persistant gigantesque.
- Fait 2 : Le passage des pipelines à fonctions fixes aux shaders programmables a rendu les GPU plus généraux, mais la VRAM comptait surtout pour les buffers d’image et les assets — jusqu’à ce que le deep learning pirate le matériel.
- Fait 3 : CUDA (2007) a rendu le calcul GPU grand public ; il a aussi fait de la gestion mémoire GPU une préoccupation applicative plutôt qu’une curiosité de pilote.
- Fait 4 : La précision mixte (FP16/BF16) n’a pas seulement accéléré le calcul — elle a réduit l’empreinte des paramètres et des activations, « fabriquant » effectivement de la VRAM via la représentation.
- Fait 5 : L’introduction de HBM (High Bandwidth Memory) était d’abord une histoire de bande passante, mais elle a aussi structuré les niveaux de capacité : toute la VRAM n’évolue pas de la même manière selon les gammes de produits.
- Fait 6 : Unified Virtual Memory et la mémoire gérée promettaient la simplicité, mais beaucoup d’équipes en production ont appris à la dure que « pager vers l’hôte » peut transformer une requête de 50 ms en un désastre de plusieurs secondes.
- Fait 7 : Les mécanismes d’attention ont fait bondir la qualité des modèles, mais ils ont aussi complexifié le comportement mémoire : caches KV, formes dynamiques et contextes longs deviennent des variables de planification de capacité de première importance.
- Fait 8 : MIG et des fonctionnalités de partitionnement similaires répondent à l’économie — pourtant elles transforment la VRAM en ressource ordonnançable avec des frontières dures et de nouveaux modes de panne.
Ce qui remplit réellement la VRAM dans les charges modernes
On parle souvent de « taille du modèle » comme si la VRAM n’était que des paramètres. En production, la VRAM est un appartement en désordre :
le canapé ce sont les poids du modèle, mais le couloir est plein de cartons que vous ne vous souveniez pas d’avoir commandés.
1) Poids du modèle (évident, mais souvent mal compris)
Les poids résident en VRAM pour la vitesse. La quantification peut les réduire. Le sharding peut les répartir.
Mais chaque « astuce intelligente » augmente souvent les frais généraux ailleurs : métadonnées, empaquetage, contraintes de kernel ou buffers supplémentaires.
2) Cache KV (le tueur discret)
Pour la génération autoregressive, vous gardez les clés/valeurs passées pour ne pas recomputer l’attention depuis le début.
Le coût du cache KV croît avec :
- la longueur du contexte
- la taille du batch / nombre de séquences concurrentes
- la dimension cachée et le nombre de couches
- la précision (FP16/BF16/FP8/int8)
C’est pourquoi un modèle qui « rentre » peut encore s’effondrer sous la charge. Vous avez dimensionné pour les poids, puis le trafic a dimensionné votre cache KV pour vous.
3) Activations et buffers temporaires
Les personnes orientées entraînement savent que les activations dominent la mémoire. En inférence, vous avez toujours des temporaires : workspaces d’attention,
buffers pour kernels fusionnés, staging de tokenization et d’embeddings, et surcharge par requête.
Certains frameworks allouent ces éléments opportunément et les gardent pour éviter le churn de l’allocateur.
C’est bon pour la latence jusqu’à ce que ce soit mauvais pour l’usage de pointe.
4) Fragmentation et comportement de l’allocateur
La fragmentation est l’écart entre « mémoire libre » et « mémoire libre que vous pouvez réellement utiliser ».
Vous pouvez avoir des gigaoctets libres et échouer quand même à allouer un bloc contigu nécessaire à un kernel.
C’est une des raisons pour lesquelles les incidents VRAM semblent irrationnels : le tableau de bord dit 20 % libre, mais le job meurt quand même.
5) Surcharge multi‑locataire
Si plusieurs processus partagent un GPU, chacun peut charger sa propre copie des poids.
Si vous utilisez MIG ou une isolation stricte, vous obtenez des frontières prévisibles mais moins de flexibilité.
Si vous n’appliquez pas d’isolation, le pic d’un locataire devient l’incident de tous.
6) « Services de support » sur le GPU
Certaines stacks exécutent le pré/post-traitement sur le GPU : redimensionnement d’image, décodage, extraction de features, filtres de sécurité.
C’est excellent pour le débit. Cela signifie aussi que votre budget VRAM est maintenant partagé avec du code que vous ne considérez pas comme « le modèle ».
Capacité vs bande passante vs latence : les trois façons dont la VRAM vous gâche la journée
La VRAM compte de trois manières distinctes. Les confondre mène à de mauvais achats et pire encore, à des incidents.
Capacité VRAM : pouvez-vous loger l’ensemble de travail ?
Si vous ne pouvez pas loger poids + cache KV + frais, vous plantez, vous paginez, vous déversez vers le CPU ou vous basculez silencieusement vers un batch plus petit.
Les problèmes de capacité sont faciles à voir une fois que vous acceptez que « ça rentre sur ma machine de dev » n’est pas un plan de capacité.
Bande passante VRAM : pouvez-vous nourrir le calcul ?
Beaucoup de charges d’inférence sont limitées par la vitesse à laquelle vous pouvez déplacer les données entre la VRAM et les SM.
C’est pourquoi deux GPU avec des tailles de VRAM similaires peuvent se comporter très différemment avec le même modèle.
Les problèmes de bande passante apparaissent souvent comme « l’utilisation GPU semble faible, mais la latence est mauvaise ».
Latence et schémas d’accès VRAM : pouvez-vous éviter les stalls ?
Toutes les accès mémoire ne se valent pas. La fusion de kernels, les layouts de tenseurs et les comportements de cache comptent.
Certaines optimisations réduisent le calcul mais augmentent le trafic mémoire, et le GPU vous le fait gentiment payer.
Voici la vérité inconfortable : après 2026, les décisions d’achat qui traitent la VRAM comme une case à cocher (« 80 GB bon, 40 GB mauvais »)
perdront face aux équipes qui traitent la VRAM comme un budget avec postes et réserves de risque.
Modes de panne que vous verrez en production
Vous n’avez pas besoin de plus de théorie. Vous devez reconnaître rapidement l’odeur d’un problème VRAM.
1) OOM soudain après un déploiement, alors que le modèle et le GPU n’ont pas changé
Souvent causé par un changement de longueur de contexte max par défaut, de politique de taille de batch, ou une nouvelle fonctionnalité qui conserve plus d’état par requête.
Classique aussi : une mise à jour de framework qui change le comportement de l’allocateur.
2) Pics de latence sous charge, avec de la « VRAM libre » rapportée
Généralement fragmentation, paging ou chemin de repli (kernels plus petits, moins de fusion, offload CPU).
Surveillez la variance de taille de requête : un long prompt peut empoisonner le comportement du cache pour tout le monde.
3) Débit plafonné bien en dessous des capacités théoriques du GPU
Souvent lié à la bande passante ou bloqué par synchronisation et copies mémoire.
Si vous saturez le débit mémoire mais pas les SMs, votre goulot est la bande passante VRAM, pas le « besoin de plus de GPU ».
4) Incidents « voisin bruyant » en multi‑locataire
Un service charge un deuxième modèle, un autre augmente la taille des batches, un troisième commence du prétraitement côté GPU.
Le GPU partagé se comporte alors comme une base de données partagée : tout le monde nie avoir fait quoi que ce soit.
5) « Ça marche, mais seulement après avoir redémarré le pod »
C’est de la fragmentation ou une fuite mémoire, parfois dans le framework, parfois dans votre code.
Redémarrer libère la VRAM et réinitialise l’état de l’allocateur. Ce n’est pas une correction ; c’est un programme d’amnistie.
Une petite blague courte, parce qu’on l’a méritée : la VRAM, c’est comme le parking du bureau — il y a toujours « plein de places » jusqu’à ce que vous essayiez de vous garer.
Playbook de diagnostic rapide
Quand un service d’inférence est lent ou échoue, vous avez besoin d’une séquence déterministe. Pas d’impressions.
Première étape : confirmer s’il s’agit de capacité, de fragmentation ou de bande passante
- Vérifier la VRAM utilisée vs totale (par GPU, par processus). Si vous êtes près du plafond, considérez le risque de capacité.
- Vérifier les logs OOM / allocateur. Si l’OOM survient avec de la mémoire libre rapportée, suspectez la fragmentation ou des allocations contiguës larges.
- Vérifier l’utilisation de la bande passante mémoire. Si la bande passante est saturée et l’utilisation des SM modérée, vous êtes limité par la bande passante.
Deuxième étape : isoler si le problème est dû à la variance par requête ou à l’état stable
- Comparer p50 vs p99 de latence. Si le p99 explose alors que le p50 va bien, vous avez probablement une variance de taille de requête déclenchant la croissance du KV ou le paging.
- Inspecter la distribution des prompts/tokens. Si une équipe a envoyé « prenons tout l’historique client », vous avez votre coupable.
- Regarder la concurrence et le comportement du batcher. Un batching adaptatif peut accidentellement s’adapter en OOM.
Troisième étape : décider de l’atténuation d’urgence
- Limiter temporairement les tokens / la longueur du contexte. C’est brutal, mais ça arrête l’hémorragie.
- Réduire la taille maximale du batch / la concurrence sur le GPU. Le débit baisse ; la disponibilité revient.
- Déplacer un locataire hors du GPU ou appliquer l’isolation (MIG ou séparation des pools de nœuds) si le voisin bruyant est confirmé.
- Redémarrer pour défragmenter seulement en dernier recours — et planifier un suivi pour supprimer ce besoin.
Idée paraphrasée de John Allspaw : « La fiabilité vient de l’apprentissage dans la réalité désordonnée de la production, pas de la prétention que les systèmes se comportent idéalement. »
Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, quelle décision prendre
Voici les tâches que je veux réellement voir dans votre runbook. Chaque item inclut : une commande, ce que la sortie signifie, et la décision à prendre.
Les commandes supposent Linux avec GPU NVIDIA ; adaptez si vous êtes sur une autre plateforme.
Task 1: Snapshot de l’utilisation VRAM par GPU et par processus
cr0x@server:~$ nvidia-smi
Tue Jan 21 10:14:03 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 555.42 Driver Version: 555.42 CUDA Version: 12.5 |
|-------------------------------+----------------------+----------------------+
| 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-80GB On | 00000000:3B:00.0 Off | 0 |
| 35% 62C P0 285W / 400W | 74210MiB / 81920MiB | 71% Default |
+-------------------------------+----------------------+----------------------+
| Processes: |
| GPU PID Type Process name GPU Memory |
|=============================================================================|
| 0 23144 C python3 72112MiB |
| 0 24701 C /usr/bin/tritonserver 1820MiB |
+-----------------------------------------------------------------------------+
Ce que cela signifie : Le GPU 0 est à ~74 Go utilisés ; un processus python en occupe la majorité.
Décision : Si c’est un état stable, vous n’avez aucune marge. Limitez les tokens/batch ou déplacez la charge vers un palier VRAM plus grand avant d’augmenter le trafic.
Task 2: Capturer l’utilisation et la pression mémoire dans le temps
cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 10
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk
# Idx W C C % % % % MHz MHz
0 290 63 - 68 92 0 0 1215 1410
0 296 63 - 70 93 0 0 1215 1410
0 287 62 - 66 94 0 0 1215 1410
0 281 62 - 62 95 0 0 1215 1410
0 275 61 - 58 95 0 0 1215 1410
Ce que cela signifie : L’utilisation mémoire est constamment très élevée tandis que les SM sont modérés.
Décision : Vous êtes peut-être limité par la bande passante. Envisagez un palier VRAM plus rapide, une optimisation de kernel, ou la réduction du trafic mémoire (quantification, meilleur batching, attention fusionnée).
Task 3: Identifier quel GPU un conteneur utilise réellement
cr0x@server:~$ docker exec llm-serving env | grep -E 'CUDA|NVIDIA|VISIBLE'
NVIDIA_VISIBLE_DEVICES=0
CUDA_VISIBLE_DEVICES=0
Ce que cela signifie : Ce conteneur est attaché au GPU 0.
Décision : Si le GPU 0 est surchargé alors que le GPU 1 est inactif, corrigez l’ordonnancement/placement avant d’acheter du matériel.
Task 4: Vérifier l’utilisation VRAM et calcul par processus dans une vue compacte
cr0x@server:~$ nvidia-smi pmon -c 1
# gpu pid type sm mem enc dec command
# Idx # C/G % % % % name
0 23144 C 64 91 0 0 python3
0 24701 C 5 2 0 0 tritonserver
Ce que cela signifie : Un processus domine à la fois le calcul et la mémoire.
Décision : Si la multi‑locativité était attendue, votre isolation échoue (ou vous avez accidentellement chargé les poids deux fois). Envisagez des GPU séparés / des slices MIG par service.
Task 5: Détecter les problèmes ECC ou niveau matériel (rare, mais moche)
cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
==============NVSMI LOG==============
ECC Mode
Current : Enabled
Pending : Enabled
ECC Errors
Volatile
Single Bit
Device Memory : 0
Double Bit
Device Memory : 0
Aggregate
Single Bit
Device Memory : 2
Double Bit
Device Memory : 0
Ce que cela signifie : Quelques erreurs corrigées se sont produites dans le passé.
Décision : Si les compteurs augmentent rapidement ou si vous voyez des erreurs double-bit, traitez cela comme un risque matériel ; drénez le nœud et faites-le vérifier.
Task 6: Confirmer la topologie PCIe / NVLink (bande passante et contention)
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity NUMA Affinity
GPU0 X NV2 0-31 0
GPU1 NV2 X 0-31 0
Ce que cela signifie : Les GPU sont connectés via NVLink (bon pour le sharding/parallelisme).
Décision : Si vous planifiez du tensor parallel across GPUs, cela le supporte. Si vous voyez « PHB » ou une connectivité faible, repensez le sharding ou attendez-vous à de la latence.
Task 7: Vérifier la RAM hôte et le swap (le paging GPU traîne souvent l’hôte dedans)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 503Gi 392Gi 21Gi 11Gi 90Gi 101Gi
Swap: 32Gi 18Gi 14Gi
Ce que cela signifie : Le swap est activement utilisé.
Décision : Si la mémoire gérée GPU ou l’offload CPU est en jeu, l’activité de swap est un signal d’alerte ; réduisez la pression mémoire ou désactivez/limitez les chemins de paging.
Task 8: Repérer les OOM liés au GPU et les erreurs Xid dans les logs du kernel
cr0x@server:~$ sudo dmesg -T | grep -E "NVRM|Xid|Out of memory|oom" | tail -n 20
[Tue Jan 21 10:11:22 2026] NVRM: Xid (PCI:0000:3b:00): 13, pid=23144, Graphics Exception
[Tue Jan 21 10:11:23 2026] Out of memory: Killed process 23144 (python3) total-vm:14223312kB, anon-rss:9123456kB
Ce que cela signifie : Une erreur GPU plus le killer OOM de l’hôte : mauvaise combinaison.
Décision : Traitez cela comme un incident de stabilité : limitez la charge, vérifiez les pilotes et assurez-vous que l’hôte a suffisamment de RAM si l’offload est activé.
Task 9: Confirmer que votre process ne déverse pas silencieusement des tenseurs vers le CPU (exemple PyTorch)
cr0x@server:~$ python3 - <<'PY'
import torch
print("cuda available:", torch.cuda.is_available())
print("device:", torch.cuda.get_device_name(0))
print("mem allocated:", torch.cuda.memory_allocated()//(1024**2), "MiB")
print("mem reserved:", torch.cuda.memory_reserved()//(1024**2), "MiB")
PY
cuda available: True
device: NVIDIA A100-SXM4-80GB
mem allocated: 61520 MiB
mem reserved: 74240 MiB
Ce que cela signifie : Reserved > allocated implique un cache d’allocateur et un risque potentiel de fragmentation.
Décision : Si reserved continue d’augmenter entre les requêtes, vous devrez peut-être ajuster l’allocateur, recycler périodiquement les workers ou uniformiser les formes.
Task 10: Vérifier le résumé de l’allocateur PyTorch pour des indices de fragmentation
cr0x@server:~$ python3 - <<'PY'
import torch
torch.cuda.init()
print(torch.cuda.memory_summary(device=0, abbreviated=True))
PY
|===========================================================================|
| PyTorch CUDA memory summary, device ID 0 |
|---------------------------------------------------------------------------|
| CUDA OOMs: 1 | cudaMalloc retries: 0 |
| Memory Allocated: 61.1 GiB | Memory Reserved: 72.5 GiB |
|---------------------------------------------------------------------------|
| Largest block: 512.0 MiB | Total reserved: 72.5 GiB |
|===========================================================================|
Ce que cela signifie : Il y a eu au moins un OOM ; le plus grand bloc contigu est de 512 MiB.
Décision : Si votre prochaine allocation nécessite >512 MiB contigus, vous pouvez OOM malgré une VRAM « libre ». Corrigez en réduisant les buffers temporaires de pointe, en standardisant les formes ou en redémarrant stratégiquement les workers.
Task 11: Valider l’endpoint métriques du serveur de modèles localement (corrélation latence vs mémoire)
cr0x@server:~$ curl -s localhost:8000/metrics | grep -E 'gpu_memory|request_latency_seconds_bucket' | head
gpu_memory_used_bytes{gpu="0"} 7.775e+10
request_latency_seconds_bucket{le="0.5"} 8123
request_latency_seconds_bucket{le="1"} 9012
request_latency_seconds_bucket{le="2"} 9401
Ce que cela signifie : La mémoire utilisée est élevée ; la distribution de latence est visible.
Décision : Si la latence se dégrade quand gpu_memory_used_bytes augmente, vous êtes lié à la pression mémoire ; ajustez le batching/la concurrence et les caps de tokens.
Task 12: Mesurer la distribution de tokens depuis les logs (proxi de croissance du cache KV)
cr0x@server:~$ awk -F' ' '/tokens_in=/{for(i=1;i<=NF;i++) if($i ~ /^tokens_in=/) {split($i,a,"="); print a[2]}}' /var/log/llm-serving/access.log | sort -n | tail -n 10
4096
6144
8192
8192
12288
16384
16384
24576
32768
65536
Ce que cela signifie : Vous avez des entrées extrêmement longues.
Décision : Si vous n’aviez pas planifié cela, appliquez une limite max de tokens, introduisez de la summarisation ou orientez les requêtes long‑contexte vers un pool dédié à grande VRAM.
Task 13: Vérifier la configuration MIG (la VRAM est-elle partitionnée comme vous le pensez ?)
cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
MIG 1g.10gb Device 0: (UUID: MIG-aaaaaaaa-bbbb-cccc-dddd-000000000001)
MIG 1g.10gb Device 1: (UUID: MIG-aaaaaaaa-bbbb-cccc-dddd-000000000002)
MIG 2g.20gb Device 2: (UUID: MIG-aaaaaaaa-bbbb-cccc-dddd-000000000003)
Ce que cela signifie : La VRAM est découpée en plusieurs instances plus petites.
Décision : Si votre modèle tient à peine dans 20 Go, ne l’envoyez pas dans une tranche 10 Go en espérant que ça passe. Redimensionnez les slices ou changez le modèle/la quantification.
Task 14: Vérifier le throttling des horloges GPU (les charges liées à la mémoire souffrent aussi de la puissance/thermique)
cr0x@server:~$ nvidia-smi --query-gpu=clocks.current.memory,clocks.max.memory,temperature.gpu,power.draw,power.limit --format=csv
clocks.current.memory [MHz], clocks.max.memory [MHz], temperature.gpu, power.draw [W], power.limit [W]
1215, 1593, 63, 292.15, 400.00
Ce que cela signifie : L’horloge mémoire est en dessous du maximum.
Décision : Si elle est constamment basse sous charge, enquêtez sur les limites de puissance/thermique ou les politiques admin ; vous pourriez laisser de la bande passante sur la table.
Task 15: Confirmer la cohérence du driver/CUDA stack entre nœuds (la variance cause des bugs « ça marche sur un nœud »)
cr0x@server:~$ (nvidia-smi --query-gpu=driver_version --format=csv,noheader | head -n1; nvcc --version | tail -n 2) 2>/dev/null
555.42
Cuda compilation tools, release 12.5, V12.5.52
Ce que cela signifie : Les versions de driver et de toolkit sont visibles.
Décision : Si les clusters sont hétérogènes, vous pouvez obtenir des comportements d’allocateur/perf différents et une headroom VRAM incohérente. Standardisez, ou au moins planifiez les workloads par version de stack.
Deuxième blague courte (et c’est tout) : quand quelqu’un dit « on augmente juste le batch », un GPU commence silencieusement à rédiger sa lettre de démission.
Trois mini-histoires d’entreprise (toutes vraies dans l’esprit)
Mini-histoire 1 : L’incident causé par une mauvaise hypothèse
Une entreprise SaaS de taille moyenne a déployé un « assistant de cas » interne pour les ingénieurs support. Le modèle était derrière une API gateway.
L’équipe a fait le test de charge habituel : taille moyenne de prompt, longueur moyenne de réponse, concurrence moyenne. Ça semblait correct.
Ils ont livré et sont partis chez eux comme des adultes responsables.
Deux semaines plus tard, l’assistant est devenu populaire auprès de l’équipe d’escalade. Les escalades signifiaient des tickets longs.
Les gens ont commencé à coller des fils d’email entiers, des logs et des captures d’écran (OCRisées en texte). La moyenne n’a pas beaucoup changé,
mais la queue est devenue vicieuse. Une requête toutes les quelques minutes atteignait une longueur de contexte 10–20× supérieure aux tests initiaux.
Le système n’a pas juste ralenti. Il s’est effondré. Le serveur modèle a OOM, redémarré et rechargé les poids.
Pendant le rechargement, les health checks ont échoué. La gateway a marqué l’instance comme unhealthy, a déplacé le trafic et provoqué un thundering herd sur les pods restants.
En quelques minutes, un outil interne « non critique » était devenu une panne de productivité.
La mauvaise hypothèse n’était pas « la VRAM est trop petite ». C’était « la distribution des prompts est stable ». Elle ne l’était pas.
Le correctif n’était pas simplement d’acheter de plus gros GPU non plus. Ils ont mis en place :
- un plafond strict sur les tokens d’entrée avec une erreur conviviale
- une file séparée pour les contextes longs routée vers un pool de nœuds haute‑VRAM
- un SLO qui suivait le compte de tokens en queue, pas seulement la latence en queue
Après cela, ils ont arrêté de se disputer pour savoir si le modèle « rentre ». Ils ont commencé à budgéter la VRAM pour les queues et la récupération d’incident.
Ce changement est ce qui garde votre pager calme.
Mini-histoire 2 : L’optimisation qui s’est retournée contre eux
Une équipe fintech exécutait du scoring de fraude avec un modèle accéléré GPU. Ils voulaient réduire la latence p95.
L’ingénieur en astreinte (intelligent, bien intentionné) a activé une stratégie de batching plus agressive dans le serveur modèle.
Les premiers graphiques étaient excellents : moins de lancements de kernel, débit plus élevé, p50 légèrement amélioré.
Puis le vrai pattern de trafic est arrivé : en rafales, multi‑tenant, avec quelques clients envoyant de grands vecteurs de features.
Le batcher a empaqueté avidement les requêtes. L’utilisation VRAM de pointe a grimpé. Pas linéairement — par paliers.
À chaque fois qu’un lot contenait plusieurs grosses requêtes, le service flirtait avec le plafond VRAM.
Bientôt ils ont vu un nouveau comportement : pas d’OOM dur, mais des falaises de latence périodiques.
Le framework a commencé des allocations additionnelles, l’allocateur ne trouvait pas de grands blocs contigus,
et le système passait du temps en gestion mémoire plutôt qu’en inférence.
Leur « optimisation » avait créé un nouveau problème p99.
Le rollback fut immédiat. Le correctif permanent fut plus nuancé :
- batcher par buckets de forme (ou par buckets de tokens) plutôt que « qui arrive »
- limiter la taille du batch selon la croissance prédite du KV, pas seulement le nombre de requêtes
- réserver explicitement une marge VRAM (oui, gaspiller un peu) pour éviter les spirales mortelles de l’allocateur
La leçon : les optimisations de débit dépensent souvent la VRAM comme une carte de crédit. L’addition arrive plus tard, avec les intérêts.
Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société média exécutait du rendu GPU et un peu d’inférence ML légère sur la même flotte. Ils avaient une règle que personne n’aimait :
chaque nœud GPU avait un « fichier budget VRAM » dans la gestion de config — usage mémoire attendu par service documenté,
et un pourcentage de headroom requis pour les jobs pire‑cas.
C’était pénible. Les ingénieurs devaient mettre à jour le budget quand ils changeaient la résolution, la version du modèle, le max tokens ou qu’ils activaient un nouveau filtre côté GPU.
Les revues incluaient une question : « Montre‑moi le delta VRAM. » Les gens levaient les yeux au ciel. Les gens lèvent toujours les yeux au ciel pour la prévention.
Puis une mise à jour de bibliothèque vendor a changé le comportement mémoire. Sur un sous‑ensemble de charges, l’utilisation VRAM a légèrement augmenté,
mais la fragmentation s’est aggravée. Les nœuds n’ont pas OOM immédiatement ; ils ont commencé à échouer des jobs après quelques heures de churn.
Les symptômes étaient classiques : échecs d’allocation sporadiques, seulement à haute concurrence, fixés par un restart.
Parce qu’ils avaient des budgets et des politiques de headroom, le rayon d’impact fut limité.
Les schedulers refusèrent de co-localiser deux services à haute VRAM. Des nœuds canary ont détecté la régression avant la mise à jour complète de la flotte.
L’incident fut une nuisance, pas une crise.
La pratique ennuyeuse : traiter la VRAM comme une dimension de capacité de première classe, la tracer dans la config et faire respecter la headroom via des règles d’ordonnancement.
Ça n’a rendu personne célèbre. Ça a maintenu les fonctionnalités génératrices de revenus en vie.
Erreurs courantes : symptôme → cause → correctif
C’est la partie où je vous dis ce qu’il faut arrêter de faire.
1) Symptom : « CUDA out of memory » seulement quand le trafic est élevé
Cause : Croissance du cache KV avec la concurrence ; vous avez dimensionné pour tenir une requête unique.
Correctif : Limiter les tokens max, limiter la concurrence par GPU, adopter le batching conscient des tokens, ou router les requêtes long‑contexte vers des nœuds séparés.
2) Symptom : OOM malgré des gigaoctets libres rapportés
Cause : Fragmentation ou besoin d’une grande allocation contiguë.
Correctif : Standardiser les formes/buckets d’entrée, réduire les allocations peak des workspaces, tuner l’allocateur ou redémarrer périodiquement les workers (avec un plan, pas en panique).
3) Symptom : Pics de latence, utilisation GPU faible, utilisation mémoire élevée
Cause : Charge limitée par la bande passante mémoire.
Correctif : Utiliser des GPU avec plus de bande passante, utiliser la quantification ou des kernels qui réduisent le trafic mémoire, augmenter l’intensité de calcul (fusion), ou réduire le batch si cela diminue le thrash mémoire.
4) Symptom : Performance varie énormément entre des nœuds « identiques »
Cause : Versions différentes de driver/CUDA/framework, partitions MIG différentes, ou limites thermiques/puissance différentes.
Correctif : Standardiser les images, appliquer des labels de nœud et des contraintes d’ordonnancement, et surveiller les horloges/états de puissance.
5) Symptom : Le service se dégrade lentement sur des heures, réparé par un restart
Cause : Fuite mémoire dans les allocations GPU ou croissance du cache de l’allocateur ; accumulation de fragmentation.
Correctif : Ajouter des limites de durée de vie par worker, suivre la VRAM dans le temps, reproduire avec des tests de soak et épingler les versions de framework tant que vérifié.
6) Symptom : GPU multi‑tenant OK jusqu’au déploiement d’une équipe
Cause : Pas d’isolation ; un locataire charge des poids supplémentaires ou augmente la taille du batch ; « voisin bruyant » qui vole la VRAM.
Correctif : Appliquer des politiques d’allocation GPU : slices MIG, pools GPU dédiés, quotas par locataire, ou partage du modèle via une couche de serving unique.
7) Symptom : Copier des données vers le GPU devient subitement une grande part de la latence
Cause : Les transferts hôte↔dispositif ont augmenté ; la mémoire épinglée n’est pas utilisée ; le prétraitement a été déplacé hors GPU ; ou le chemin NUMA/PCIe est sous optimal.
Correctif : Épingler la mémoire, déplacer prudemment le prétraitement vers le GPU, corriger l’affinité CPU/placement NUMA et éviter les copies de tenseurs inutiles.
8) Symptom : « Nous avons monté un modèle plus gros » et le débit s’est effondré
Cause : Le modèle tient, mais le cache KV et le batching ne tiennent plus à la concurrence souhaitée ; la demande en bande passante a augmenté.
Correctif : Recalculer le budget VRAM en incluant le cache KV ; réduire la concurrence, ajouter du sharding ou déployer une variante plus petite/quantifiée pour les chemins à haute concurrence.
Listes de contrôle / plan étape par étape
Checklist A : Planification de capacité VRAM comme un adulte
- Définir l’enveloppe de travail : tokens d’entrée max, tokens de sortie max, concurrence cible et rafales de trafic attendues.
- Budgéter les postes VRAM : poids + cache KV à l’enveloppe max + buffers temporaires + overhead framework + marge de sécurité.
- Choisir une politique de headroom : ne pas tourner en steady‑state au‑dessus d’environ 80–85% VRAM si vous tenez à la latence tail et à la santé de l’allocateur.
- Décider du routage des queues : que faire des requêtes très longues — rejeter, tronquer, résumer ou router vers un pool spécialisé.
- Codifier : fichiers de config, valeurs Helm, variables Terraform, ce que vous utilisez. Pas de connaissance tribale.
Checklist B : Configuration de serving qui évite la douleur VRAM auto‑infligée
- Limiter la taille max du batch par tokens/forme, pas seulement par compte de requêtes.
- Utiliser le bucketing de forme/token pour réduire le churn de l’allocateur et la fragmentation.
- Définir une longueur de contexte max explicite alignée sur les besoins business, pas le marketing du modèle.
- Préférer un serveur modèle partagé par GPU plutôt que plusieurs processus chargeant des poids identiques (quand l’isolation le permet).
- Traquer les métriques VRAM comme signaux SLO de première classe : used, reserved, échecs d’allocation et time-to-first-token sous charge.
Checklist C : Réponse aux incidents pour les pannes liées à la VRAM
- Confirmer : capacité vs fragmentation vs bande passante en utilisant le playbook de diagnostic rapide.
- Atténuer rapidement : limiter tokens, réduire la concurrence, drainer les voisins bruyants, redémarrer seulement si nécessaire.
- Conserver les preuves : capturer nvidia-smi, résumés d’allocateur et instantanés de distribution de tokens.
- Corriger pour l’avenir : appliquer de nouveaux caps/routages et programmer des tests de soak avant d’enlever les mitigations.
- Post‑incident : mettre à jour les budgets VRAM et le contrôle d’admission pour que la même queue ne vous renverse plus.
FAQ
1) La capacité VRAM est‑elle plus importante que le calcul GPU après 2026 ?
Pour beaucoup de charges d’inférence, oui — parce que vous ne pouvez pas calculer ce que vous ne pouvez pas garder en résidence.
Le calcul aide quand vous êtes limité par le calcul. Beaucoup de workloads en production deviennent d’abord limités par la mémoire.
2) Si un modèle tient dans la VRAM, pourquoi ai‑je encore des OOM ?
Parce que les poids ne sont pas toute l’histoire. Le cache KV croît avec le contexte et la concurrence, et la fragmentation peut empêcher de grosses allocations même avec de la mémoire « libre ».
3) La quantification résout‑elle le problème VRAM ?
Elle aide beaucoup pour les poids et parfois pour le cache KV, mais elle peut introduire des frais généraux, des contraintes de kernel et des compromis d’exactitude.
Traitez‑la comme un outil, pas comme une religion.
4) Quel est le réglage le plus simple pour réduire immédiatement l’utilisation VRAM ?
Limiter les tokens max (entrée et sortie) et réduire la concurrence par GPU.
Si vous avez besoin d’un frein d’urgence rapide, ces deux mesures sont généralement les plus propres.
5) Paginer le cache KV vers la mémoire hôte est‑ce une bonne idée ?
Ça peut l’être, si votre tolérance à la latence et le profil de workload correspondent au compromis.
Dans beaucoup de services temps réel, le paging transforme la latence tail en un cauchemar. Benchmarquez avec des queues de production, pas des moyennes.
6) Quelle marge VRAM devrais‑je garder ?
Si vous tenez à la stabilité : gardez une marge significative. Une cible opérationnelle commune est d’environ 15–25% de libre en pic typique,
mais le bon chiffre dépend du comportement de fragmentation et de la variance des requêtes.
7) Dois‑je utiliser MIG pour isoler les locataires ?
Si vous avez des voisins bruyants et des besoins d’isolation stricts, MIG vaut souvent le coup.
Le compromis est une flexibilité réduite : capacité immobilisée et moins de possibilité d’« emprunter » la VRAM entre charges.
8) Pourquoi « VRAM reserved » diffère‑t‑il de « VRAM allocated » ?
Beaucoup d’allocateurs réservent des chunks pour les réutiliser et améliorer la latence. La réserve peut améliorer la latence mais augmente le pic et le risque de fragmentation.
Suivez les deux et observez les tendances dans le temps.
9) Disques plus rapides ou plus de RAM hôte compensent‑ils une VRAM faible ?
Pas de façon fiable. Ils peuvent soutenir des stratégies d’offload, mais l’offload augmente généralement la variance de latence et ajoute de nouveaux modes de panne.
Utilisez l’offload délibérément, pas comme mécanisme de survie.
10) Quelle est l’erreur d’achat la plus courante ?
Acheter en se basant sur « le modèle rentre » plutôt que « le modèle rentre à la concurrence requise avec le contexte max requis, avec headroom, sous des queues réalistes ».
La deuxième déclaration est celle pour laquelle vos clients payent.
Conclusion : prochaines étapes concrètes
La VRAM après 2026 n’est pas un argument marketing sur une fiche technique. C’est une contrainte de production qui façonne la fiabilité, le coût et le débit.
Traitez‑la comme vous traitez les IOPS disque, les connexions base de données ou l’egress réseau : mesurée, budgétée et protégée par des politiques.
Prochaines étapes pratiques :
- Ajouter des métriques VRAM à vos tableaux de bord standards : used, reserved, échecs d’allocation et comptes de tokens par requête.
- Implémenter un contrôle d’admission conscient des tokens : limiter entrées/sorties et router les requêtes long‑contexte intentionnellement.
- Lancer un test de soak avec des prompts tail de production, pas des moyennes. Surveillez la fragmentation sur plusieurs heures.
- Décider de votre modèle d’isolation : GPU partagé avec quotas stricts, slices MIG ou pools dédiés — puis faites‑le respecter.
- Rédiger et maintenir un budget VRAM par service. Oui, c’est ennuyeux. C’est pour ça que ça marche.