Dernière mise à jour : 2026-06-22

La VRAM pour l'inférence LLM

Servir un grand modèle de langage commence par une question brutale : tiendra-t-il sur le GPU ? La réponse est dominée par les poids du modèle, mais les poids seuls sous-estiment le besoin, car un serveur d'inférence doit aussi conserver le cache clé-valeur, les activations traversant chaque couche, et un peu de mémoire perdue à cause de la fragmentation. Ce calculateur estime la VRAM totale à partir de trois entrées — le nombre de paramètres, la précision de stockage des poids, et une surcharge d'exécution qui regroupe le reste en une seule valeur ajustable.

Les poids fixent le plancher

Les poids d'un modèle sont son plus gros coût fixe en mémoire. Chaque paramètre est stocké à une précision choisie : les poids 16 bits pleins occupent deux octets chacun, la quantification 8 bits un octet, et le 4 bits un demi-octet. Ainsi, un nombre de paramètres $N$ en milliards, stocké à $b$ bits, occupe

Un milliard de paramètres 16 bits vaut exactement 2 Go, ce qui explique qu'un modèle 7B requière 14 Go rien que pour ses poids. Diviser le nombre de bits par huit convertit les bits en octets, et comme les paramètres se comptent en milliards et la mémoire en gigaoctets, les unités s'alignent directement.

Ajouter la surcharge d'exécution

Les poids ne sont que le plancher. Pendant l'inférence, le serveur maintient un cache clé-valeur contenant les clés et valeurs d'attention de chaque jeton en cours de traitement, alloue des activations au passage de chaque requête à travers les couches, et perd un peu de mémoire à cause de la fragmentation. Le total vaut

où $o$ est la surcharge exprimée en fraction de la taille des poids. Le cache clé-valeur est le composant le plus volumineux et le plus variable — il croît avec la longueur du contexte et le nombre de requêtes simultanées — si bien que la bonne surcharge dépend fortement de la charge de travail. Vingt pour cent est un point de départ raisonnable pour des invites courtes avec des tailles de lot modestes ; un service à contexte long et fort débit peut la faire monter bien plus haut.

Exemple chiffré

Prenons un modèle de 7 milliards de paramètres servi en précision 16 bits avec 20 pour cent de surcharge :

Les 16,8 Go au total tiennent à l'aise sur une carte de 24 Go mais ne laissent aucune place sur une de 16 Go. Pour faire tourner le même modèle sur un GPU plus petit, passer en 8 bits diviserait les poids par deux pour les ramener à 7 Go et porterait le total autour de 8,4 Go. La relation entre la taille du modèle et la précision est approfondie dans le Calculateur de taille de modèle selon la quantification.

Faire tenir un modèle

Comme la mémoire est directement proportionnelle au nombre de bits par poids, la quantification est le levier le plus direct : passer de 16 bits à 8 bits divise par deux la mémoire des poids, et de 8 bits à 4 bits la divise encore par deux, généralement avec une perte de qualité de sortie modeste et acceptable. Lorsque même un modèle quantifié dépasse un seul accélérateur, les alternatives sont de répartir les poids sur plusieurs GPU ou de décharger une partie du modèle vers la mémoire système au prix d'une forte baisse de vitesse. Estimer le nombre d'accélérateurs requis par un modèle est traité dans le Calculateur du nombre de GPU pour un modèle. Considérez la valeur indiquée ici comme une estimation de planification et vérifiez-la face à un service réel, car le framework, la longueur du contexte et la taille des lots déplacent tous le nombre réel.