Notes techniques sur ce qui fait reellement tourner les modeles de langage en production. Ecrites du point de vue de l’ingenieur qui exploite ces systemes : GPU, serveurs d’inference, dimensionnement, fiabilite et cout.
Mesurer une NVIDIA A100 avec Kepler, puis comprendre pourquoi rien ne remontait
Un test de mesure électrique sur une A100, un écart de 0,59 W avec nvidia-smi, puis un bug de permissions remonté au projet Kepler.
Multi-Instance GPU : découper un H100 en tranches
Partitionner physiquement un GPU pour isoler les workloads et éviter le gaspillage.
Observer un parc GPU : DCGM, Prometheus, et ce qu'il faut vraiment mesurer
Mesurer l’utilisation GPU au-delà du pourcentage trompeur affiché par nvidia-smi.
L'interconnect : NVLink, PCIe, InfiniBand, pourquoi le réseau décide du multi-GPU
La bande passante entre GPU détermine quelles stratégies de parallélisme restent viables et à quel coût.
Servir un modèle trop gros pour un GPU : tensor et pipeline parallelism
Quand un modèle ne rentre pas dans un seul GPU, trois stratégies de parallélisme s’offrent à nous, chacune avec son compromis entre débit et latence.
Quantification : FP16, FP8, INT4, ce qu'on gagne et ce qu'on perd
Passer de FP16 à INT4 divise par quatre la VRAM et accélère l’inférence, mais au prix d’une dégradation de qualité mesurable.
Pourquoi un H100 au repos coûte une fortune, et comment on gère ça
Un GPU cloud facturé à l’heure produit un coût constant même au repos, et l’utilisation réelle dépasse rarement 30%.
Le NVIDIA GPU Operator : donner des GPU à Kubernetes
Comment automatiser l’enfer opérationnel des drivers GPU sur chaque nœud Kubernetes.
vLLM : anatomie d'un serveur d'inférence moderne
Comment vLLM a résolu le goulot mémoire de l’inférence LLM en s’inspirant des systèmes d’exploitation.
Dimensionner un GPU pour servir un modèle : la vraie méthode
On peut estimer de façon déterministe si un modèle rentre en mémoire et quel débit attendre, mais jamais le coût cloud.