La règle des 2 Go par milliard de paramètres
Un paramètre de LLM n’est rien d’autre qu’un nombre. La seule question qui détermine son coût mémoire, c’est : sur combien d’octets le stocke-t-on ? Les modèles sont entraînés et distribués en 16 bits — le format FP16 Floating-Point 16 bits. Format de stockage des nombres sur 2 octets, précision par défaut des poids et activations d'un LLM. Deux variantes coexistent : FP16 (IEEE demi-précision) et BF16 (même portée que le FP32, moins de précision fractionnaire). C'est la référence dont la quantification réduit l'empreinte. ou son cousin BF16 —, soit 2 octets par paramètre. Le calcul est alors direct : un modèle de 7 milliards de paramètres pèse 7 × 2 = 14 milliards d’octets, soit ~13 Gio de poids. C’est tout ce que dit la fameuse « règle des 2 Go par milliard » : ce n’est pas une approximation empirique, c’est l’arithmétique du format.
Ce qui rend la règle utile, c’est qu’elle se transpose à n’importe quelle précision. Descendre les poids en 8 bits, c’est un octet par paramètre — la moitié. En 4 bits, c’est un demi-octet — le quart. La quantification Réduction du nombre de bits codant chaque poids d'un modèle — de 16 bits vers 8, 4, voire moins. Elle divise l'empreinte mémoire d'autant, au prix d'une perte de précision contrôlée, sans changer le nombre de paramètres. ne change pas le nombre de paramètres, seulement le nombre de bits qui codent chacun : c’est une multiplication, pas une réécriture du modèle.
Trois postes, pas un seul
La VRAM consommée par un modèle qui sert n’est pas celle du seul fichier de poids. Trois postes s’additionnent, et c’est leur somme qui doit tenir sur la carte :
- Les poids — fixes, donnés par la règle ci-dessus. C’est le seul poste que la plupart des gens calculent, et c’est pour ça que beaucoup se trompent.
- Le KV cache — la mémoire de ce que le modèle a déjà lu. Il part de zéro et grandit à chaque token généré, proportionnellement à la longueur de contexte et au nombre de requêtes servies en parallèle. C’est lui, pas les poids, qui sature la VRAM en premier sur les contextes longs.
- L’overhead — le contexte CUDA Compute Unified Device Architecture. La plateforme de calcul GPU de NVIDIA — langage, compilateur et bibliothèques (cuBLAS, cuDNN). Son écosystème logiciel est le principal verrou face aux alternatives comme ROCm ; à l'exécution, son « contexte » réserve aussi une part incompressible de VRAM. , les tampons d’activation, la fragmentation de l’allocateur. Comptez ~1 Go incompressible, plus quelques pour-cent du volume des poids.
Cette décomposition explique le piège classique : un modèle qui « tient » à VRAM au chargement déborde en cours d’usage. Les poids rentraient ; le KV cache d’un contexte long, lui, n’avait pas été budgété.
Le tableau : ce que pèsent les poids
Avant d’ajouter le reste, il faut savoir ce que coûte le modèle nu. Le tableau ci-dessous applique la règle aux trois tailles les plus courantes, dans les trois précisions de déploiement :
| Modèle | 16 bits (FP16) | 8 bits (INT8) | 4 bits |
|---|---|---|---|
| 7–8 B | ≈ 14–16 Go | ≈ 7–8 Go | ≈ 4–5 Go |
| 13 B | ≈ 26 Go | ≈ 13 Go | ≈ 8 Go |
| 70 B | ≈ 140 Go | ≈ 70 Go | ≈ 42 Go |
La colonne 4 bits mérite une nuance : un format quantifié ne descend jamais exactement à un demi-octet par paramètre. Les schémas comme GGUF GPT-Generated Unified Format. Format de fichier de llama.cpp qui stocke dans un seul fichier les tenseurs, leurs types de quantification, le vocabulaire et les métadonnées du modèle. Sa structure alignée permet de le lire par mmap — le modèle « démarre » en une fraction de seconde. Q4_K_M stockent, en plus des poids, des facteurs d’échelle par bloc de quelques valeurs — l’encombrement réel tourne autour de 4,8 bits par paramètre, soit ~0,6 octet. C’est pourquoi un 70B « en 4 bits » (Q4_K_M) pèse ~42 Go et non 35 : la différence, ce sont les métadonnées de quantification, et elles ne sont pas optionnelles.
Quelle carte pour quel modèle
En pratique, la VRAM disponible vient par paliers — ceux des cartes du marché. Mettre les paliers en face des modèles donne une grille de décision directe :
| VRAM | Cartes typiques | Ce qui tient confortablement |
|---|---|---|
| 8 Go | RTX 4060, cartes d'entrée | 7–8 B en 4 bits |
| 12–16 Go | RTX 4070, RTX 4060 Ti 16G | 13 B en 4 bits, 7–8 B en 8 bits |
| 24 Go | RTX 3090, RTX 4090 | 32 B en 4 bits, 13 B en 8 bits |
| 32 Go | RTX 5090 | 32 B en 4 bits (confort) ; 70 B uniquement en ~3 bits (très serré) |
| 48 Go | RTX A6000, 2× 24 Go | 70 B en 4 bits |
| 80 Go | H100, A100 80G | 70 B en 8 bits (contexte modéré) ou en 4 bits (contexte long) |
Deux lectures de ce tableau valent d’être explicitées. La première : le saut de prix entre 24 et 80 Go ne reflète pas un saut de capacité brute proportionnel, mais l’accès aux modèles 70B et aux contextes longs — c’est tout l’enjeu du match entre une RTX 5090 et un H100 pour le LLM local. La seconde : au-delà de 24 Go, l’arbitrage n’est plus seulement « acheter une plus grosse carte », mais « acheter ou louer » — un 70B servi quelques heures par jour coûte souvent moins cher en GPU cloud qu’en matériel amorti.
Réduire la VRAM nécessaire
Quand le modèle visé ne rentre pas, trois leviers existent, par ordre de rendement décroissant.
Le premier, et de loin le plus puissant, c’est la quantification des poids. Passer de 16 à 4 bits divise le poste principal par quatre — c’est ce qui fait tenir un 70B en 4 bits (~42 Go) sur deux cartes grand public, là où ses 140 Go en FP16 imposent plusieurs GPU datacenter. La perte de qualité d’un Q4_K_M bien calibré reste faible sur la plupart des usages ; c’est le compromis le mieux établi de l’inférence locale.
Le deuxième, c’est la gestion du KV cache. Réduire la longueur de contexte maximale, quantifier le cache en FP8 Format à virgule flottante 8 bits. Format de travail polyvalent pour l'inférence (et l'entraînement) sur GPU récents. Divise par 2 l'empreinte mémoire et le débit nécessaires par rapport au FP16, pour une perte de précision marginale sur la plupart des modèles. — un octet par valeur au lieu de deux, soit le double de capacité —, ou activer le prefix caching libère exactement la VRAM que les contextes longs réclamaient. Sur une charge à fort contexte, ce levier rend plus de mémoire utile qu’un changement de carte.
Le troisième, c’est l’offloading : déporter une partie des couches en RAM CPU, comme le permet llama.cpp. Il débloque l’exécution d’un modèle trop gros pour la VRAM, mais au prix fort — chaque couche en RAM se paie en allers-retours sur le bus PCIe Peripheral Component Interconnect Express. Le bus qui relie le GPU au CPU et à la RAM. Sa bande passante (quelques dizaines de Go/s) est un à deux ordres de grandeur sous celle de la VRAM, ce qui fait du transfert hôte↔GPU un goulot dès qu'on déporte des données hors de la carte. , et le débit s’effondre. C’est une solution de dernier recours, pas de dimensionnement.
Conclusion
La question « combien de VRAM pour un LLM ? » a une réponse arithmétique pour les poids — deux gigaoctets par milliard, divisés par la précision — mais la vraie question de dimensionnement est ailleurs. Ce n’est pas « le modèle rentre-t-il ? », c’est : quelle longueur de contexte et quel niveau de concurrence dois-je absorber, et combien de VRAM reste-t-il pour les héberger une fois les poids posés ? Pour passer de la règle au chiffre exact sur votre modèle et votre contexte, le calculateur de VRAM applique la formule complète — poids, KV cache et overhead — en un coup d’œil.
Sources et méthode
La règle des 2 octets par paramètre en 16 bits est un fait : elle découle des formats IEEE 754 demi-précision (FP16) et bfloat16, tous deux codés sur 16 bits. Le surcoût des formats 4 bits (~4,8 bits par paramètre effectifs pour Q4_K_M — un 70B fait ~42,5 Go) est mesuré sur les schémas GGUF k-quants : voir la documentation llama.cpp sur la quantification et les tailles de fichiers GGUF publiées sur Hugging Face. Les tailles du Tableau 1 sont des ordres de grandeur calculés à partir de la règle ; les valeurs exactes varient de quelques pour-cent d’un modèle à l’autre (têtes partagées, tied embeddings). Les paliers du Tableau 2 reposent sur les capacités VRAM publiées des cartes citées (RTX 4060/4070/4090/5090, RTX 3090, A6000, A100/H100) ; « confortable » est une estimation intégrant une marge usuelle pour le KV cache et l’overhead, pas une garantie — le contexte et le batch réels décident. Le dimensionnement du KV cache et de l’overhead est détaillé dans l’article dédié au KV cache. Taux de conversion non applicable (aucun prix dans cet article).
