Combien de VRAM pour faire tourner un LLM en local ? Le guide de calcul (2026)

« Est-ce que ce modèle tient sur ma carte ? » C'est LA question de l'IA locale, et la plupart des réponses qu'on trouve sont fausses — parce qu'elles ne regardent que le poids du modèle et oublient le reste. Résultat : un modèle qui « devrait tenir » sature votre GPU dès que le contexte s'allonge.

Cet article démonte la vraie formule, composant par composant, avec des chiffres réels et des tableaux exploitables. À la fin, vous saurez calculer de tête si un LLM rentre dans votre VRAM — KV cache compris.

Les 4 postes de consommation

La VRAM d'un LLM ne se résume pas aux poids. Vous payez pour quatre choses :

• Les poids du modèle — les paramètres eux-mêmes. Le plus gros poste, mais pas le seul.
• Le KV cache — l'état de l'attention, qui grandit linéairement avec la longueur de contexte. Le piège principal.
• Les activations — tenseurs temporaires de la passe avant.
• L'overhead du framework — CUDA, le backend d'inférence : typiquement 0,5 à 1 Go.

Règle rapide : un LLM consomme environ 2 Go de VRAM par milliard de paramètres en FP16, ou ~0,5 Go/milliard en INT4, plus 15–20 % par-dessus pour le KV cache, les activations et l'overhead.

Les poids selon la quantification

En pleine précision FP16, chaque paramètre pèse 2 octets. Un 70B occupe donc 140 Go, un 7B occupe 14 Go : c'est le plancher avant toute optimisation. La quantification fait fondre ce chiffre :

• FP16 : 2 octets/param → 7B = 14 Go
• Q8 : 1 octet/param → 7B = 7 Go
• Q4 : ~0,5 octet/param → 7B = 3,5 Go

Le cas Q4_K_M (le format roi)

Dans l'écosystème GGUF (Ollama, LM Studio, llama.cpp), le format dominant est Q4_K_M. Attention : ses bits-par-poids réels sont plus élevés que « 4 » à cause des métadonnées de bloc, facteurs d'échelle et zéro-points. On parle de ~4,5 à 4,8 bits effectifs/poids, soit ~0,56 Go par milliard de paramètres :

• 7B en Q4_K_M ≈ 4 Go de poids
• 32B en Q4_K_M ≈ 18 Go
• 70B en Q4_K_M ≈ 40 Go

Côté qualité, Q4_K_M est le sweet spot : il conserve ~95 % de la qualité pleine précision pour ~4× moins de mémoire. En dessous de Q4, la dégradation devient perceptible, surtout sur le raisonnement et le code.

Le KV cache : le consommateur caché

C'est lui qui décide souvent si un modèle tient ou pas, surtout à long contexte. Pendant la génération, le modèle stocke les tenseurs clés/valeurs pour chaque couche, à chaque position de token du contexte. La formule :

KV_cache ≈ 2 × n_couches × n_têtes_KV × dim_tête × longueur_contexte × octets_par_élément

La croissance est brutale avec le contexte. Quelques exemples réels :

• 8B : ~0,3 Go à 2K de contexte → ~5 Go à 32K → ~20 Go à 128K (rien que le KV cache !)
• 70B : ~1,6 Go à 2K → plus de 42 Go à 128K

Autrement dit : à long contexte, le KV cache peut dépasser le poids du modèle lui-même. Pour un Llama 3.1 70B à 128K, le KV cache ajoute ~40 Go, soit ~29 % du total. C'est l'erreur classique : on dimensionne pour les poids, on oublie le cache, et on plante à 32K tokens.

Quantifier le KV cache (avec prudence)

On peut quantifier le cache lui-même : passer OLLAMA_KV_CACHE_TYPE de f16 à q8_0 ou q4_0 réduit sa taille de moitié ou plus. Mais attention : le KV cache est plus sensible à la quantification que les poids. La qualité se dégrade plus vite — à réserver pour gratter les derniers Go nécessaires.

L'architecture change aussi la donne : la MLA de DeepSeek compresse le KV cache ~28× par rapport à l'attention standard, et certains MoE hyper-optimisés ne réclament qu'~1,2 Go de cache pour 64K de contexte. Le choix du modèle compte autant que sa taille.

Totaux pratiques en Q4_K_M (contexte 8K)

Poids + KV cache + overhead, pour un usage réaliste :

• 7–8B : ~6–7 Go
• 13–14B : ~10–12 Go
• 32B : ~21–23 Go
• 70B : ~43–46 Go

Formule de poche : VRAM ≈ (nb_paramètres × 0,5) + 2 Go. Exemple : Llama 3.1 8B en Q4_K_M = (8 × 0,5) + 2 = 6 Go.

Quelle VRAM pour quel modèle ?

• 8 Go : un 7B Q4_K_M passe confortablement jusqu'à ~8K de contexte, et peut s'étirer à 32K en serrant l'overhead.
• 16–24 Go : modèles de 22–35B (Gemma 3 27B, Qwen3 32B, GPT-OSS 20B, DeepSeek R1 32B) en Q4_K_M.
• 48 Go et plus : requis pour les 70B+ (Llama 3.3 70B, Qwen2.5 72B). Deux RTX 3090 (2×24 Go) suffisent, et le NVLink n'est pas nécessaire.

Quatre pièges à éviter

• Les MoE ont quand même besoin de toute la VRAM. Idée fausse répandue : non, tous les paramètres doivent être en mémoire, pas seulement les experts actifs. Mixtral 8x7B loge 46,7B de paramètres même si ~13B sont actifs par token. Le compte actif rend le modèle plus rapide, pas plus petit.
• La taille du fichier ne fait pas foi. Le footprint runtime dépasse la taille du .gguf : un fichier de 15,6 Go peut réclamer plus de 20 Go de VRAM réelle à 64K de contexte.
• L'offload tue les performances. Décharger les couches excédentaires d'un 70B vers la RAM fait chuter la vitesse de 25+ tok/s à 3–5 tok/s. Mieux vaut un modèle plus petit qui tient entièrement.
• Prévoyez de la marge. Pour de la production à long contexte ou forte concurrence, ajoutez 30–50 % de VRAM au-delà de la taille de base pour absorber la croissance du KV cache.

En résumé

Pour savoir si un modèle tient : prenez 0,56 Go × milliards de paramètres (poids en Q4_K_M), ajoutez le KV cache (qui explose avec le contexte) et ~1 Go d'overhead. Si le total dépasse votre VRAM, vous avez trois leviers : descendre en quantification, réduire le contexte, ou quantifier le KV cache — dans cet ordre de préférence. Et n'oubliez jamais : un modèle qui ne tient pas entièrement en VRAM ne « tourne pas plus lentement », il rampe.