Calculateur de VRAM pour LLM — puis-je faire tourner ce LLM en local ?
Calculez la mémoire GPU nécessaire à un LLM local selon la quantification et la longueur de contexte, vérifiez s’il tient sur votre GPU ou votre Mac, et à quelle vitesse il tournera.
8,03 B de paramètres. Attention : 32 couches × 8 têtes KV × 128 dim.
Foncé : poids · Bleu : cache KV · Gris : surcoût. Ici, Go signifie Gio (1024³ octets), l’unité dans laquelle la mémoire des GPU est vendue.
| GPU / Mac | Utilisable | Verdict | Vitesse est. |
|---|---|---|---|
| RTX 3060 12 GB 360 GB/s | 12 GB | Tient | ~39 tok/s |
| RTX 4060 Ti 16 GB 288 GB/s | 16 GB | Tient | ~31 tok/s |
| RTX 4070 Super 12 GB 504 GB/s | 12 GB | Tient | ~55 tok/s |
| RTX 4080 Super 16 GB 736 GB/s | 16 GB | Tient | ~80 tok/s |
| RTX 5080 16 GB 960 GB/s | 16 GB | Tient | ~104 tok/s |
| RTX 3090 24 GB 936 GB/s | 24 GB | Tient | ~102 tok/s |
| RTX 4090 24 GB 1008 GB/s | 24 GB | Tient | ~110 tok/s |
| RTX 5090 32 GB 1792 GB/s | 32 GB | Tient | ~195 tok/s |
| Radeon RX 7900 XTX 24 GB 960 GB/s | 24 GB | Tient | ~104 tok/s |
| RTX 6000 Ada 48 GB 960 GB/s | 48 GB | Tient | ~104 tok/s |
| A100 40 GB 1555 GB/s | 40 GB | Tient | ~169 tok/s |
| A100 80 GB (SXM) 2039 GB/s | 80 GB | Tient | ~222 tok/s |
| H100 80 GB (SXM) 3350 GB/s | 80 GB | Tient | ~364 tok/s |
| H200 141 GB 4800 GB/s | 141 GB | Tient | ~522 tok/s |
| Ryzen AI Max+ 395 (96 GB to GPU) 256 GB/s | 96 GB | Tient | ~28 tok/s |
| Mac M2/M3/M4, 16 GB 100 GB/s | 10.7 GB | Tient | ~11 tok/s |
| Mac M3/M4, 24 GB 120 GB/s | 16.1 GB | Tient | ~13 tok/s |
| Mac M4 Pro, 48 GB 273 GB/s | 36 GB | Tient | ~30 tok/s |
| Mac M4 Max, 64 GB 546 GB/s | 48 GB | Tient | ~59 tok/s |
| Mac M4 Max, 128 GB 546 GB/s | 96 GB | Tient | ~59 tok/s |
| Mac M2 Ultra, 192 GB 800 GB/s | 144 GB | Tient | ~87 tok/s |
| Mac M3 Ultra, 512 GB 819 GB/s | 384 GB | Tient | ~89 tok/s |
« Juste » signifie à moins de 10 % de la limite : le modèle peut se charger, mais un navigateur ou une autre application peut faire déborder la mémoire. La vitesse correspond à la génération pour un seul utilisateur, estimée à 65 % de la bande passante mémoire divisée par les octets lus par token ; le traitement du prompt est plus rapide, et les chiffres réels varient selon le runtime. Par défaut, Apple Silicon peut allouer au GPU environ deux tiers de la RAM (jusqu’à 36 Go) ou trois quarts (au-delà).
Calculé dans votre navigateur. Rien de ce que vous saisissez n’est envoyé. Parcourir tous les outils gratuits.
Un problème, ou quelque chose à améliorer ? Nous lisons chaque message et corrigeons vite.
Ce calculateur de VRAM pour LLM répond à la question « puis-je faire tourner ce LLM en local ? » en estimant la mémoire dont un modèle a besoin sur votre GPU ou votre Mac : les poids à la quantification choisie, le cache KV pour votre longueur de contexte et le surcoût d’exécution. Choisissez un modèle ouvert populaire ou saisissez un nombre de paramètres, choisissez une quantification comme Q4_K_M, et voyez le total à côté d’un verdict « tient », « juste » ou « ne tient pas » pour les cartes graphiques courantes et les machines Apple Silicon, avec une vitesse de génération approximative pour chacune.
La plupart des estimations rapides multiplient le nombre de paramètres par les octets par poids et s’arrêtent là, ce qui est proche pour des prompts courts et très faux pour des longs. Un modèle Llama 3.1 8B en Q4_K_M a besoin d’environ 4,6 Go pour les poids, mais son cache KV passe de 1 Go pour un contexte de 8K à 16 Go pour 128K. Les préréglages intègrent la véritable structure d’attention de chaque modèle (têtes de requêtes groupées, fenêtres glissantes, attention latente de DeepSeek) : le cache KV est donc dimensionné comme llama.cpp et vLLM l’allouent réellement. Les formules sont détaillées ci-dessous et les calculs sont couverts par des tests unitaires comparés à de vraies tailles de fichiers GGUF.
Mode d’emploi
- Choisissez un modèle dans la liste, ou Personnalisé pour saisir un nombre de paramètres (et, pour un cache KV exact, les valeurs de couches, de têtes KV et de dimension de tête du config.json du modèle).
- Choisissez la quantification que vous comptez télécharger. Q4_K_M est le point de départ habituel pour les modèles GGUF dans llama.cpp, Ollama et LM Studio.
- Définissez la longueur de contexte que vous utiliserez réellement et le nombre de séquences parallèles (1 pour un chat personnel, davantage pour un serveur).
- Lisez le total et sa répartition, puis le verdict pour chaque GPU ou Mac. « Juste » signifie à moins de 10 % de la limite.
- Si ça ne tient pas, essayez une quantification plus petite, un contexte plus court, un cache KV en Q8_0 ou un modèle avec moins de paramètres.
Questions fréquentes
De combien de VRAM ai-je besoin pour faire tourner un modèle 8B ?
Environ 6,5 Go pour Llama 3.1 8B en Q4_K_M avec un contexte de 8K : 4,6 Go de poids, 1 Go de cache KV et moins de 1 Go de surcoût. Cela tient sur un GPU de 8 Go et largement sur une RTX 3060 de 12 Go. En FP16, le même modèle a besoin d’environ 17 Go, soit une carte de 24 Go. La longueur de contexte compte : avec le contexte complet de 128K, le cache KV pèse à lui seul 16 Go.
Puis-je faire tourner un modèle 70B sur un GPU de 24 Go ?
Pas entièrement en VRAM. Llama 3.3 70B en Q4_K_M a besoin d’environ 40 Go pour les poids et d’à peu près 45 Go au total avec un contexte de 8K ; même le Q2_K demande environ 30 Go. Les options sont deux GPU de 24 Go, une carte de 48 Go, un Mac avec 64 Go de mémoire unifiée ou plus, ou le déport d’une partie du modèle dans la RAM système, qui fonctionne mais est plusieurs fois plus lent.
Qu’est-ce que le cache KV et pourquoi grandit-il avec le contexte ?
Pendant la génération, le modèle stocke un vecteur clé et un vecteur valeur pour chaque token précédent dans chaque couche, afin de ne pas les recalculer à chaque nouveau token. Sa taille vaut 2 x couches x têtes KV x dimension de tête x longueur de contexte x octets par valeur. Pour Llama 3.1 8B (32 couches, 8 têtes KV, dimension de tête 128, FP16), cela fait 128 Ko par token : 1 Go pour 8K tokens et 16 Go pour 128K. Les modèles à attention à requêtes groupées, à couches à fenêtre glissante (Gemma) ou à attention latente (DeepSeek) en demandent bien moins.
Quelle quantification utiliser ?
Q4_K_M est le compromis standard : environ un tiers de la taille en FP16, avec une légère perte de qualité pour la plupart des usages. Utilisez Q5_K_M ou Q6_K s’ils tiennent, Q8_0 si vous voulez des résultats pratiquement identiques à l’original, et évitez Q3 et Q2 sur les modèles de moins de 30B paramètres environ, où la baisse de qualité devient flagrante. Un modèle plus grand en Q4 bat généralement un modèle plus petit en Q8 de même taille de fichier.
Un Mac ou un GPU NVIDIA, lequel est le mieux pour les LLM locaux ?
Un Mac accueille des modèles plus gros ; un GPU NVIDIA fait tourner plus vite ceux qui tiennent. Apple Silicon partage un seul pool de mémoire entre le CPU et le GPU : un Mac de 128 Go peut contenir un modèle 70B qu’aucune carte graphique grand public ne peut accueillir, mais sa bande passante mémoire (546 Go/s sur un M4 Max) représente environ la moitié des 1 008 Go/s d’une RTX 4090, et la vitesse de génération dépend de la bande passante. Par défaut, macOS laisse le GPU utiliser environ deux tiers de la RAM sur les machines jusqu’à 36 Go et environ trois quarts sur les plus grandes.
Quelle est la précision de l’estimation des tokens par seconde ?
C’est un ordre de grandeur, généralement à 30 % près pour une génération mono-utilisateur. Générer chaque token implique de lire une fois en mémoire les poids actifs et le cache KV : la vitesse vaut donc environ la bande passante mémoire divisée par les octets par token ; l’outil suppose que 65 % de la bande passante maximale est atteinte. Le traitement du prompt est limité par le calcul et bien plus rapide, les modèles MoE ajoutent un surcoût de routage, et le moteur d’exécution, les pilotes et les réglages font tous varier les chiffres réels.
Les formules utilisées par ce calculateur
Mémoire totale = poids du modèle + cache KV + surcoût d’exécution. Toutes les tailles sont en Gio (1 024³ octets), l’unité dans laquelle la mémoire GPU est vendue : une RTX 4090 de « 24 Go » a 24 Gio.
Poids = paramètres x bits par poids / 8. Pour les k-quants GGUF, les bits par poids sont des valeurs effectives mesurées sur de vrais fichiers, car chaque type de quantification mélange les précisions selon les tenseurs : Q8_0 8,5, Q6_K 6,57, Q5_K_M 5,70, Q4_K_M 4,89, IQ4_XS 4,43, Q3_K_M 4,00, Q2_K 3,17 (d’après les fichiers GGUF de Llama 3.1 8B ; les modèles plus grands ressortent jusqu’à environ 5 % plus petits). AWQ et GPTQ utilisent des poids 4 bits avec un facteur d’échelle pour 128 poids (environ 4,16 bits) et gardent les embeddings et la couche de sortie en 16 bits ; gpt-oss livre ses poids d’experts en MXFP4 (4,25 bits) avec l’attention et les embeddings en BF16.
Cache KV = 2 x couches x têtes KV x dimension de tête x tokens x octets par valeur x séquences parallèles. L’attention à requêtes groupées explique pourquoi kv_heads (8 pour Llama 3 70B) est bien inférieur au nombre de têtes d’attention (64). Les couches à fenêtre glissante stockent au plus leur fenêtre (1 024 tokens sur Gemma 3, 128 sur la moitié des couches de gpt-oss). DeepSeek V3 et R1 stockent un latent de 576 valeurs par couche et par token au lieu de clés et valeurs complètes. Le FP16 utilise 2 octets par valeur, un cache Q8_0 environ 1,06 et Q4_0 environ 0,56.
Surcoût = 0,75 Gio + 3 % des poids, ce qui couvre le contexte CUDA ou Metal et les tampons de calcul. Les moteurs réels diffèrent de quelques centaines de mégaoctets. Vitesse = bande passante mémoire x 0,65 / (octets de poids actifs + cache KV d’une séquence).
Tailles par quantification en un coup d’œil
Poids seuls, d’après ce calculateur, pour Llama 3.1 8B et Llama 3.3 70B :
• FP16 / BF16 : 15,0 Go et 131,5 Go
• Q8_0 : 7,9 Go et 69,9 Go
• Q6_K : 6,1 Go et 54,0 Go
• Q5_K_M : 5,3 Go et 46,8 Go
• Q4_K_M : 4,6 Go et 40,2 Go
• Q3_K_M : 3,7 Go et 32,9 Go
• Q2_K : 3,0 Go et 26,1 Go
Ajoutez le cache KV de votre contexte et environ 1 Go de surcoût pour obtenir ce que le GPU doit contenir.
Modèles à mélange d’experts : la mémoire d’un gros modèle, la vitesse d’un petit
Un modèle à mélange d’experts (MoE) comme Qwen3 30B-A3B, Mixtral 8x7B, gpt-oss ou DeepSeek R1 contient de nombreux sous-réseaux experts mais n’en utilise que quelques-uns pour chaque token. Tous doivent être en mémoire : la mémoire suit donc le nombre total de paramètres. La vitesse suit les paramètres actifs, car seuls ces poids sont lus pour chaque token.
C’est pourquoi Qwen3 30B-A3B en Q4_K_M a besoin d’environ 19 Go, la mémoire d’un modèle dense de 30B, mais génère du texte à la vitesse d’un modèle 3B. C’est aussi pourquoi les modèles MoE conviennent aux Mac et aux autres machines dotées de beaucoup de mémoire plus lente : la capacité est la contrainte, la bande passante beaucoup moins.
DeepSeek R1 et ses 671B paramètres constituent le cas extrême : environ 380 Go en Q4_K_M, au-delà de toute machine grand public, alors que seuls 37B paramètres sont actifs par token.
Outils gratuits similaires
- Calculateur de coût d’API LLM — Comparez le coût de votre charge de travail sur plus de 40 modèles, avec cache, remises batch, paliers de contexte long et tokens de raisonnement. Prix sourcés et datés.
- Compteur de tokens — Comptez les tokens exactement pour les modèles OpenAI, estimez-les pour Claude, Gemini et Llama, voyez le coût et observez le découpage du texte en tokens.
- Calculateur de ROI de l’IA — Estimez combien d’heures et de dollars l’automatisation d’une tâche répétitive pourrait faire économiser à votre entreprise chaque année.