Besoins en VRAM des LLM : le tableau maître 2026 (tous les modèles, tous les quants)

Besoins en VRAM des LLM : le tableau maître 2026 (tous les modèles, tous les quants)

Voici le chiffre qui surprend tout le monde : DeepSeek-V3.2 a 671 milliards de paramètres, mais seuls 37 milliards s'activent pour un token donné. Alors, de combien de VRAM a-t-il vraiment besoin ? Des 671 milliards en entier, soit environ 382 GB en Q4. Les besoins en VRAM des LLM suivent rarement l'intuition, et l'écart entre les « paramètres actifs » et « ce qu'il faut charger » est exactement l'endroit où les budgets matériel explosent. Ce guide vous donne le tableau maître (tous les grands modèles open source, tous les niveaux de quantification, le chiffre en GB et le GPU qui le fait tourner) ainsi que la formule pour dimensionner n'importe quel modèle vous-même en une dizaine de secondes.

Points clés

• La VRAM pour les poids ≈ paramètres × octets par paramètre : FP16 = 2.0, Q8 = 1.0, Q5_K_M ≈ 0.68, Q4_K_M ≈ 0.57. Ajoutez le cache KV et environ 15-20% de marge en plus.
• Les modèles Mixture-of-Experts (DeepSeek, GLM-5.2, Qwen3-235B) doivent charger chaque expert en VRAM. Les « paramètres actifs » vous offrent de la vitesse, pas de la mémoire.
• Le cache KV est le coût caché. Llama 3.3 70B a besoin d'environ 2.6 GB de cache pour un contexte de 8K et d'environ 41 GB à 128K, en plus des poids.
• Q4_K_M est le choix par défaut le plus sensé : une qualité quasi intacte pour environ un quart de l'empreinte de FP16.
• Un modèle de 12B comme Gemma 4 tient sur une carte de 8 GB en Q4. Un modèle dense de 70B a besoin d'environ 40 GB. Un MoE de pointe à 671B a besoin d'un petit serveur.

Besoins en VRAM des LLM par modèle : le tableau maître

Réponse rapide : en Q4_K_M, les petits modèles (moins de 14B) tiennent sur des cartes grand public de 8-12 GB, les modèles de taille moyenne (24-32B) veulent 16-24 GB, un modèle dense de 70B a besoin d'environ 40 GB, et les modèles MoE de pointe grimpent à des centaines de gigaoctets parce que chaque expert doit rester résident en mémoire. Voici la vue d'ensemble complète. Tous les chiffres correspondent à la mémoire des poids seuls, calculés à partir du nombre de paramètres de chaque modèle et vérifiés face aux fiches techniques officielles de Meta AI, Qwen et Hugging Face.

Ce tableau donne deux enseignements. D'abord, la quantification est le levier le plus puissant : passer de FP16 à Q4 réduit l'empreinte d'environ 4x pour une perte de qualité à peine perceptible. Ensuite, les lignes MoE ont l'air brutales, et elles le sont. Qwen3-30B-A3B n'active que 3B de paramètres par token, donc il tourne à la vitesse d'un tout petit modèle, mais il faut quand même garder les 30B en mémoire pour que chaque expert soit prêt. Vous voulez le détail modèle par modèle derrière ces chiffres ? Notre analyse approfondie de Gemma 4 12B et notre comparatif des meilleurs LLM open source de 2026 couvrent les benchmarks et les licences.

La formule VRAM : calculez n'importe quel modèle vous-même

Pour dimensionner n'importe quel modèle, multipliez son nombre de paramètres par le nombre d'octets par paramètre de votre quantification, puis ajoutez un peu pour le cache KV et la marge d'exécution. C'est tout. Les poids sont le terme dominant, et le calcul est assez simple pour se faire au dos d'une enveloppe.

L'équation de base pour les poids :

VRAM_weights (GB) = parameters (billions) × bits_per_weight ÷ 8

Voici les valeurs de bits par poids dont vous avez besoin (ce sont les taux effectifs pour les fichiers GGUF k-quant, qui portent un peu de métadonnées de bloc en plus de la profondeur de bits nominale) :

Exemple concret, Gemma 4 12B en Q4_K_M : 11.95 × 4.5 ÷ 8 = environ 6.7 GB pour les poids. Ça correspond aux environ 6.6 GB annoncés par la fiche technique officielle, et ça explique pourquoi il tient sur une carte de 8 GB avec un peu de marge pour un contexte modeste. Refaites le même calcul pour un modèle de 70B en Q4 et vous obtenez 70 × 4.5 ÷ 8 = 39.4 GB, d'où la règle empirique que tout le monde répète : « il faut deux cartes de 24 GB ou une carte de 48 GB pour un 70B ».

Le tableau complet ajoute deux termes de plus : VRAM totale ≈ poids + cache KV + ~15-20% de marge. Cette marge couvre les buffers d'activation, le contexte CUDA et la fragmentation mémoire, et votre GPU réserve aussi environ un demi-gigaoctet pour le pilote, donc ne prévoyez jamais d'utiliser 100% de la VRAM annoncée.

Pourquoi le cache KV est le chiffre qui vous piège

Le cache KV stocke les clés et valeurs d'attention pour chaque token déjà présent dans le contexte, et il croît linéairement avec la longueur du contexte. Sur des prompts courts, c'est une erreur d'arrondi. Poussez vers un long contexte et il peut rivaliser avec les poids eux-mêmes, voire les dépasser. C'est la raison la plus courante pour laquelle un modèle qui « devrait tenir » balance une erreur de mémoire insuffisante en pleine génération.

La formule, par token :

KV_cache_per_token (bytes) = num_layers × 2 × kv_dim × precision_bytes
kv_dim = num_kv_heads × head_dim   (grouped-query attention shrinks this)

Prenons Llama 3.3 70B : 80 couches, 8 têtes KV, une dimension de tête de 128, donc kv_dim vaut 1024. En FP16, ça donne 80 × 2 × 1024 × 2 = 327,680 octets par token, soit environ 0.31 MB. Multipliez par la longueur du contexte et l'histoire s'écrit toute seule : à 8K tokens, le cache fait environ 2.6 GB, à 32K environ 10 GB, et à 128K il gonfle jusqu'à environ 41 GB. Ce dernier chiffre s'ajoute aux 40 GB de poids, donc un « modèle de 40 GB » devient discrètement un problème à 80 GB dès que vous remplissez la fenêtre de contexte.

Deux échappatoires concrètes. Le grouped-query attention (que tous les modèles récents utilisent) réduit déjà kv_dim par rapport à l'ancien design multi-têtes, donc les modèles modernes sont bien plus cléments ici que ne l'était Llama 2. Et la plupart des moteurs d'inférence peuvent quantifier le cache KV en 8-bit ou 4-bit, ce qui divise sa taille par deux ou par quatre pour une petite perte de qualité. Si vous servez de longs contextes en production, notre comparatif vLLM vs SGLang détaille quel backend gère cette mémoire le plus efficacement avec le paged attention.

Modèles MoE : pourquoi les « paramètres actifs » n'économisent pas de VRAM

C'est le piège qui coûte le plus cher aux gens. Un modèle Mixture-of-Experts comme DeepSeek-V3.2 (671B au total, 37B actifs, avec l'architecture V3) ou GLM-5.2 (744B au total, 40B actifs) fait passer chaque token par un petit sous-ensemble de ses experts. Le marketing met en avant le nombre actif parce qu'il décrit la vitesse : vous ne payez que le calcul de 37B de paramètres par token, donc l'inférence est rapide pour la taille du modèle. Mais chaque expert doit rester en mémoire, prêt à être sollicité, ce qui veut dire que votre budget VRAM est fixé par le nombre total de paramètres, pas par le nombre actif.

En clair, si on lit honnêtement le tableau ci-dessus : GLM-5.2 tourne à la vitesse d'un modèle de 40B mais occupe la mémoire d'un modèle de 744B. C'est pour ça que ces modèles open source de pointe ont besoin d'un serveur à 8 GPU ou d'une grosse machine à mémoire unifiée, même si un seul passage avant est bon marché en calcul. Qwen3-235B-A22B suit le même schéma à plus petite échelle : rapide par token, lourd à héberger.

L'avantage du MoE se voit sur le matériel à mémoire unifiée. Un Mac Studio avec 512 GB de mémoire unifiée peut charger un modèle de 671B en Q4 et le faire tourner à une vitesse utilisable, précisément parce que seuls 37B s'activent, donc la demande en bande passante mémoire par token reste raisonnable. Si vous débutez avec l'exécution en local, commencez par notre guide de configuration LLM en local avant de dépenser dans du matériel.

Quelle quantification choisir ?

Pour presque tout le monde, Q4_K_M est le bon choix par défaut : il conserve une qualité quasi intacte tout en réduisant l'empreinte FP16 d'environ 4x. Passez à Q5_K_M ou Q8 seulement si vous avez de la VRAM en réserve et une tâche sensible à la qualité, et réservez FP16 au fine-tuning ou au benchmark face à une référence. En dessous de Q4, la dégradation de qualité devient vite perceptible, donc Q3 et en dessous sont un dernier recours pour faire tenir un modèle sur une carte vraiment trop petite.

Un bémol : la qualité de la quantification n'est pas identique d'un modèle à l'autre. Les très petits modèles (moins de 4B) ressentent plus l'effet du Q4 que les grands, parce qu'ils ont moins de redondance à revendre. Sur un modèle de 70B, Q4 face à Q8 est difficile à distinguer sur la plupart des tâches. Sur un modèle de 1.7B, l'écart est bien réel.

De quel GPU avez-vous vraiment besoin ?

Faites correspondre la colonne Q4 du tableau maître à une carte avec un peu de marge pour le cache KV. Voici la correspondance pratique, du matériel grand public d'entrée de gamme jusqu'au datacenter, avec le niveau de modèle que chaque catégorie fait tourner confortablement en Q4.

Apple Silicon mérite une mention spéciale, car la mémoire unifiée change la donne. Un Mac ne sépare pas la VRAM de la RAM système, donc une machine série M de 128 GB peut charger des modèles qui nécessiteraient normalement plusieurs GPU distincts, au prix d'un débit de pointe plus faible en échange de la capacité à faire tenir d'énormes poids sur un seul bureau. Pour les backends qui tirent le maximum de chacune de ces cartes, notre comparatif des meilleurs outils pour exécuter des LLM en local mesure les vraies différences de vitesse.

Comment nous dimensionnons la VRAM pour les déploiements clients

Chez Techsy, nous déployons des modèles open source pour des clients assez souvent pour que le dimensionnement de la VRAM soit la première conversation, avant le choix du modèle, avant les prompts, avant tout le reste. Notre méthode est volontairement sans surprise, parce que le mode d'échec (un OOM en production sous une vraie charge de contexte) coûte cher. Voici le processus que nous suivons vraiment.

Nous partons du calcul du tableau, puis nous mesurons. Après avoir chargé un modèle, nous vérifions l'empreinte résidente réelle plutôt que de faire confiance à l'estimation :

# What the GPU is actually holding
nvidia-smi --query-gpu=memory.used,memory.total --format=csv

# For an Ollama-served model, its real memory + how much sits on GPU vs CPU
ollama ps

# llama.cpp: control the split explicitly and cap context to bound KV cache
llama-server -m model-Q4_K_M.gguf --n-gpu-layers 999 --ctx-size 8192

La leçon qui revient sans cesse : les équipes dimensionnent pour les poids et oublient le cache KV, puis se demandent pourquoi un modèle qui chargeait sans problème plante au bout de trois longues requêtes pendant une démo. Nous dimensionnons pour les poids plus le cache KV au contexte maximum que l'application utilisera vraiment, plus une marge, et nous plafonnons --ctx-size pour qu'une requête incontrôlée ne puisse pas faire planter la machine par manque de mémoire. Pour tout ce qui est en contact avec le client, nous préférons faire tourner un modèle quantifié de 32B qui ne tombe jamais qu'un FP16 70B qui plante sous charge.

Si vous hésitez entre auto-héberger un modèle open source ou rester sur une API hébergée, cet arbitrage (coût matériel et charge opérationnelle contre tarification au token et contrôle) est exactement ce que notre équipe évalue lors d'une mission d'intégration IA. Si ça peut aider d'avoir quelqu'un pour faire les calculs sur votre charge de travail réelle, demandez une consultation gratuite et nous la dimensionnerons avec vous.

Questions fréquentes

De combien de VRAM ai-je besoin pour faire tourner un modèle de 70B ?

Un modèle dense de 70B comme Llama 3.3 70B a besoin d'environ 40 GB de VRAM pour les poids en Q4_K_M, donc prévoyez une carte de 48 GB (RTX 6000 Ada) ou deux cartes de 24 GB. Ajoutez plusieurs gigaoctets de plus pour le cache KV si vous utilisez un long contexte, ce qui pousse le besoin pratique vers 48 GB ou plus.

De combien de VRAM Llama, Qwen ou DeepSeek ont-ils besoin ?

Ça dépend entièrement de la variante. Llama 4 Scout a besoin d'environ 62 GB en Q4, Qwen3-32B d'environ 18 GB, et Qwen3-8B de moins de 5 GB. DeepSeek-V3.2, un MoE de 671B, a besoin d'environ 382 GB parce que chaque expert doit être chargé. Vérifiez toujours le nombre total de paramètres, pas le nombre actif, pour les modèles MoE.

Puis-je faire tourner un LLM sur un GPU de 8GB ?

Oui, confortablement. Une carte de 8 GB comme une RTX 4060 fait tourner des modèles jusqu'à environ 12B de paramètres en Q4_K_M. Gemma 4 12B tient dans environ 6.8 GB, ce qui laisse de la place pour un contexte modeste. Pour quelque chose de plus gros, il faut soit quantifier plus fort, soit garder un contexte court, soit passer à une carte plus grosse.

Que peut faire tourner un GPU de 24GB comme la RTX 4090 ?

Une carte de 24 GB gère des modèles denses jusqu'à environ 32B en Q4_K_M avec de la marge pour un contexte raisonnable, donc Qwen3-32B et Mistral Small 3.2 24B passent confortablement. Elle fait aussi tourner le MoE Qwen3-30B-A3B, qui charge 30B de poids mais génère à la vitesse d'un modèle de 3B grâce à l'activation sparse.

La quantification nuit-elle à la qualité du modèle ?

À partir de Q4_K_M, la perte de qualité est faible et souvent imperceptible sur des tâches réelles, surtout pour les modèles de plus de 13B. L'écart se creuse quand on descend en quantification et que les modèles se réduisent, donc le Q4 sur un 70B est presque gratuit tandis que le Q4 sur un 1.7B se remarque. Le Q8 est sans perte en pratique si vous avez la mémoire disponible.

Les modèles MoE ont-ils besoin de moins de VRAM que les modèles denses ?

Non, et c'est l'idée reçue la plus répandue. Un modèle Mixture-of-Experts doit garder chaque expert en VRAM, donc sa mémoire est fixée par le nombre total de paramètres. Le chiffre des paramètres actifs décrit seulement la vitesse d'inférence. GLM-5.2 tourne à la vitesse d'un modèle de 40B mais a besoin de la mémoire d'un modèle de 744B.

La mémoire unifiée est-elle la même chose que la VRAM ?

Fonctionnellement, pour charger des modèles, oui. Apple Silicon et certains autres systèmes partagent un seul bassin de mémoire entre le CPU et le GPU, donc un Mac de 128 GB peut charger des modèles qui nécessiteraient sinon plusieurs GPU distincts. Le compromis, c'est la bande passante : la mémoire unifiée offre généralement un débit de pointe plus faible qu'un GPU de datacenter haut de gamme, donc le nombre de tokens par seconde est plus bas.

Puis-je délester une partie d'un modèle vers la RAM système ou le CPU ?

Oui. Des moteurs comme llama.cpp et Ollama vous permettent de garder certaines couches sur le GPU et le reste en RAM système avec un paramètre comme --n-gpu-layers. Ça permet de faire tourner un modèle trop gros pour votre VRAM, mais chaque couche sur le CPU ralentit fortement la génération, donc utilisez cette option pour rendre un modèle possible, pas rapide.

Comment calculer la VRAM pour un modèle qui n'est pas dans le tableau ?

Multipliez le nombre de paramètres en milliards par le nombre de bits par poids de votre quantification, puis divisez par 8. Pour Q4_K_M, comptez environ 4.5 bits, donc un modèle de 40B a besoin de 40 × 4.5 ÷ 8 = environ 22.5 GB pour les poids. Ajoutez environ 15-20% de marge plus votre cache KV pour obtenir le besoin réel.