LLM VRAM Calculator: Dimensionnez le GPU avant de télécharger le modèle.
S’exécute dans votre navigateur — rien de ce que vous collez ne quitte cette page. Comment nous le prouvons
Espace de test de la LLM VRAM Calculator
KV cache is counted at FP16. Overhead is a fixed 1.5 GiB estimate for the runtime and compute buffers. A custom size borrows the architecture of the nearest preset.
Results update as you type — press Enter to run now.
GPU tiers
- 8 GiBfitsRTX 4060, RTX 3070, RX 7600
- 12 GiBfitsRTX 4070, RTX 3060 12GB, RTX 5070
- 16 GiBfitsRTX 4060 Ti 16GB, RTX 4080, RTX 5080
- 24 GiBfitsRTX 4090, RTX 3090, RX 7900 XTX
- 32 GiBfitsRTX 5090, V100 32GB
- 48 GiBfitsRTX A6000, RTX 6000 Ada, L40S
- 80 GiBfitsA100 80GB, H100 80GB
Choisissez un préréglage de modèle comme Llama 3.1 8B ou saisissez un nombre de paramètres, une quantification GGUF comme Q4_K_M et une longueur de contexte, et obtenez la VRAM qu’un LLM local requiert — poids, cache KV et surcharge d’exécution en Gio, avec un verdict face aux tailles de GPU courantes — le tout calculé dans votre navigateur, sans inscription.
Le fossé
Les poids tiennent. Puis la fenêtre de contexte ne tient plus.
La mémoire GPU d’un LLM local, ce sont trois factures, pas une. Les poids sont la part que tout le monde dimensionne : paramètres fois bits par poids, ce qui explique qu’une quantification 4 bits d’un modèle 8B soit un fichier de 4,5 Gio. Le cache KV est la part que tout le monde oublie — deux tenseurs par couche qui croissent linéairement avec la longueur de contexte, si bien que le même modèle 8B réclame 1 Gio de cache à 8k tokens et 16 Gio à 128k. La surcharge d’exécution est le reste : tampons de calcul, contexte CUDA ou Metal et le framework lui-même, un coût fixe d’environ 1,5 Gio.
Deux systèmes d’unités aggravent les cas limites. Un GPU vendu « 24 Go » expose 24 Gio (2³⁰ octets chacun), alors que les fiches de modèle et les tailles de fichier citent souvent des Go (10⁹ octets) — un écart de 7,4 %. Ce calculateur travaille en Gio de bout en bout, de sorte qu’un ajustement est jugé face à ce que le pilote rapporte réellement, et la référence ci-dessous donne les deux chiffres pour l’exemple détaillé. Sur Apple silicon, la mémoire unifiée est partagée avec le système ; comptez sur environ 75 % de la RAM du Mac disponible pour le modèle.
Demander à une IA combien de VRAM un modèle requiert est le raccourci risqué : un modèle de langage se rappelle des chiffres plausibles tirés de forums à propos d’autres quantifications et longueurs de contexte. Ce calculateur calcule le vrai cache KV par couche à partir de la forme du config.json de chaque modèle et des bits par poids mesurés par llama.cpp — des nombres auxquels vous pouvez confronter la réponse d’une IA, et non du texte plausible de plus.
Vous convertissez entre Gio et Go ? Le Data Size Converter affiche les nombres d’octets exacts.
Le processus
Comment ça marche.
Quatre étapes déterministes s’exécutent à chaque changement — toutes dans l’onglet de votre navigateur, avec des formes de modèle vérifiées contre chaque config.json.
-
Choisit la forme.
Un préréglage fournit le nombre de couches, les têtes KV et la dimension de tête du modèle depuis son config.json ; un nombre de paramètres personnalisé emprunte la forme du préréglage le plus proche et est signalé comme estimé.
-
Pèse les poids.
Paramètres × bits effectifs par poids de la quantification choisie, ÷ 8, ÷ 2³⁰. Les bits par poids viennent de la table mesurée de llama.cpp, pas des 4 ou 8 nominaux.
-
Dimensionne le cache KV.
Deux tenseurs par couche (K et V) × têtes KV × head-dim × tokens de contexte × 2 octets en FP16 — la part de la facture qui grandit avec votre fenêtre de contexte.
-
Ajoute la surcharge, puis tranche.
1,5 Gio fixes pour le runtime et les tampons de calcul ; le total est ensuite confronté aux tailles de carte courantes et la plus petite qui convient est nommée.
Référence des formules
Les deux formules, détaillées.
Tout ce qu’affiche le panneau vient de ces deux lignes plus une surcharge fixe. Les voici avec de vraies formes de modèle, pour que vous puissiez vérifier le résultat à la main.
Le cache KV grandit avec le contexte
L’attention par groupes de requêtes garde le cache petit : Llama 3.1 a 32 têtes d’attention mais seulement 8 têtes KV par couche, et c’est ce nombre qui compte ici.
KV cache (FP16) = 2 × layers × kv_heads × head_dim × context × 2 bytes
Llama 3.1 8B at 128k context
layers 32 · kv_heads 8 · head_dim 128 · context 131,072
= 2 × 32 × 8 × 128 × 131,072 × 2 B
= 17,179,869,184 B
= 16.0 GiB (17.2 GB — the KV cache alone outgrows a 16 GiB card)
Same model at 8k context
= 1.0 GiBPoids par quantification
Un GGUF « 4 bits » ne fait pas 4 bits par poids : Q4_K_M atteint en moyenne 4,89 une fois ses échelles et les tenseurs de plus haute précision comptés, et Q8_0 en moyenne 8,5.
Weights = params × bits_per_weight ÷ 8 ÷ 2^30
Llama 3.1 70B, Q4_K_M (4.89 bpw measured)
weights 70e9 × 4.89 ÷ 8 ÷ 2^30 = 39.85 GiB
KV @ 8k 2 × 80 × 8 × 128 × 8,192 × 2 B = 2.50 GiB
overhead = 1.50 GiB
total = 43.85 GiB → fits a 48 GiB card, not 24 or 32
Llama 3.1 8B, Q4_K_M
weights 8e9 × 4.89 ÷ 8 ÷ 2^30 = 4.55 GiB
KV @ 8k = 1.00 GiB
total (with overhead) = 7.05 GiB → fits an 8 GiB cardÉtape suivante
Vous servez le modèle sur un cluster ? Dimensionnez aussi le pod.
Une fois la carte choisie, la Kubernetes Resource Calculator transforme votre nombre de réplicas et les demandes CPU, mémoire et GPU par pod en totaux par nœud et en marge — pratique avant d’écrire le Deployment qui monte le modèle.
Llama 3.1 8B Q4_K_M 8k → 7.05 GiB fits 8 GiB
Llama 3.1 8B FP16 128k → 32.4 GiB fits 48 GiB
Llama 3.1 70B Q4_K_M 8k → 43.8 GiB fits 48 GiBFAQ
Vos questions, nos réponses.
Appuyez sur une question pour afficher la réponse.
De combien de VRAM un modèle a-t-il besoin ?
Additionnez trois parts. Les poids sont le nombre de paramètres multiplié par les bits par poids de la quantification choisie, divisé par 8 pour obtenir des octets et par 2^30 pour obtenir des GiB — un modèle de 8B occupe environ 15 GiB en FP16, 8 GiB en Q8_0 et 4,6 GiB en Q4_K_M. Le cache KV grandit avec la longueur du contexte (question suivante), et le runtime ajoute un tampon fixe, que cette calculatrice fixe à 1,5 GiB. Le total doit tenir dans la mémoire de la carte avec un peu de marge ; sinon, choisissez d'abord une quantification plus petite ou un contexte plus court avant de viser un GPU plus gros.
Que fait la quantification, et en quoi Q4_K_M, Q8_0 et FP16 diffèrent-ils ?
La quantification stocke chaque poids sur moins de bits que les 16 de son entraînement. FP16 garde 16 bits par poids (bpw) ; Q8_0 en utilise environ 8,5 et est pratiquement sans perte ; Q4_K_M en utilise environ 4,89 — à peu près un tiers de la taille FP16 — avec un léger coût en qualité que la plupart des gens ne remarquent pas en conversation. Les valeurs fractionnaires viennent des agencements mixtes de llama.cpp, qui gardent quelques tenseurs sensibles en précision supérieure et stockent un facteur d'échelle par bloc ; c'est pourquoi un fichier « 4 bits » ne fait pas exactement la moitié d'un fichier 8 bits.
Comment la longueur du contexte influe-t-elle sur la VRAM ?
Chaque token du contexte conserve un vecteur clé et un vecteur valeur dans chaque couche, donc le cache KV vaut 2 × couches × têtes KV × dimension de tête × tokens × 2 octets en FP16. Pour Llama 3.1 8B (32 couches, 8 têtes KV, dimension de tête 128), cela fait 128 KiB par token : 1 GiB à 8 192 tokens et 16 GiB aux 131 072 complets — plus que les poids Q4_K_M eux-mêmes. L'attention à requêtes groupées (8 têtes KV au lieu de 32) divise le cache par quatre, ce qui explique que Llama 3 tienne de longs contextes là où Llama 2 échouait. Le curseur de contexte dessine le cache comme un segment à part de la barre, pour que vous voyiez où part la mémoire.
Pourquoi la calculatrice affiche-t-elle des GiB et non des GB ?
La mémoire GPU se vend en gigaoctets binaires : une RTX 4090 « 24 GB » contient 24 GiB, soit 25,77 GB. Un GB vaut 10^9 octets et un GiB vaut 2^30 = 1 073 741 824 octets, 7,37 % de plus ; diviser par 10^9 ferait paraître chaque modèle 7,4 % plus gros qu'il n'est et tromperait les verdicts à la limite. La calculatrice divise partout par 2^30, afin qu'un verdict compare ce qui est comparable.
Qu'est-ce que le surcoût de 1,5 GiB ?
Les poids et le cache KV ne font pas tout : le runtime (llama.cpp, Ollama, vLLM) alloue des tampons de calcul pour les activations, le contexte CUDA ou Metal prend quelques centaines de MiB, et le pilote réserve un peu de mémoire pour lui-même. 1,5 GiB est une estimation ronde qui couvre tout cela pour la plupart des modèles sur une seule carte ; la valeur réelle dépend du runtime, de la taille de lot et du GPU. Voyez-y une marge, pas une mesure — si un verdict tombe à moins d'un demi-GiB d'un palier, attendez-vous à des ennuis.
Un modèle 70B peut-il tourner sur un GPU de 24 GB ?
Pas entièrement sur le GPU. Llama 3.1 70B en Q4_K_M demande environ 40 GiB pour les seuls poids, avant le cache KV et le surcoût du runtime, donc une seule carte de 24 GiB ne peut pas le contenir. Il tient sur une carte de 48 GiB (RTX 6000 Ada, A6000) ou réparti sur deux cartes de 24 GiB par découpage des couches ; Q2_K, à environ 3,16 bpw, ramène les poids vers 26 GiB, encore trop pour une carte et avec un coût en qualité visible. Les runtimes peuvent décharger les couches restantes vers la RAM système, mais la vitesse en tokens retombe alors à ce que permet la bande passante mémoire du CPU, typiquement quelques tokens par seconde.
Qu'en est-il de la mémoire unifiée d'Apple ?
Apple Silicon partage un seul réservoir de mémoire entre CPU et GPU, donc un Mac à 64 GB peut charger des modèles qu'aucune carte de 24 GiB n'accepte. Par défaut, macOS laisse le GPU utiliser environ 75 % de la mémoire unifiée (près de 48 GiB sur une machine à 64 GB) et garde le reste pour le système ; le sysctl iogpu.wired_limit_mb permet de relever la limite, à vos risques. Saisissez comme budget environ les trois quarts de la mémoire du Mac, et rappelez-vous que la bande passante, non la capacité, fixe la vitesse en tokens : un M-series Max débite environ 400 GB/s, une RTX 4090 près de 1 TB/s.
Ma sélection quitte-t-elle un jour le navigateur ?
Non. La calculatrice s'exécute à 100 % côté client : les préréglages d'architecture et l'arithmétique sont livrés avec la page, et chaque nombre est calculé dans l'onglet de votre navigateur. Rien n'est envoyé à un serveur, il n'y a ni compte ni inscription, et le lien de partage encode votre sélection dans le fragment de l'URL, que les navigateurs n'envoient jamais à un serveur.
De combien de VRAM ai-je besoin pour un modèle 7B, 14B ou 70B ?
Pour les seuls poids : un modèle de 8B demande environ 4,6 GiB en Q4_K_M, 7,9 GiB en Q8_0 et 14,9 GiB en FP16 (un 7B environ 4,0, 6,9 et 13,0 GiB) ; un 14B environ 8,0, 13,9 et 26,1 GiB ; un 70B environ 39,9, 69,3 et 130,4 GiB. Ajoutez le cache KV de votre contexte — à 8 192 tokens, 1 GiB pour Llama 3.1 8B et 2,5 GiB pour Llama 3.1 70B — plus les 1,5 GiB de surcoût du runtime : un 8B en Q4_K_M avec 8k de contexte arrive ainsi vers 7,1 GiB au total. Chaque modèle populaire a sa propre page avec son vrai nombre de couches et de têtes KV, pour lire directement le verdict de ce modèle.
Pourquoi le cache KV est-il parfois plus gros que les poids ?
Les poids ont une taille fixe, mais le cache KV grandit à chaque token : il coûte 2 × couches × têtes KV × dimension de tête × 2 octets par token en FP16. Pour Llama 3.1 8B, cela fait 2 × 32 × 8 × 128 × 2 = 128 KiB par token, donc le contexte complet de 131 072 tokens demande 16 GiB de cache contre environ 4,6 GiB de poids Q4_K_M. C'est l'attention à requêtes groupées qui le garde aussi petit — 8 têtes KV au lieu de 32 ramènent le cache au quart —, alors que les anciens modèles à attention multi-têtes, avec une tête KV par tête de requête, saturent la mémoire à des contextes bien plus courts.
More free, private DevOps tools.
La LLM VRAM Calculator est l’un des outils de OpsCanopy — une canopée grandissante de validateurs, convertisseurs et testeurs basés sur le navigateur qui ne touchent jamais à un serveur.
Outils associés
Vous débutez avec AI & local LLMs ? Lire le guide AI & local LLMs →
42 outils gratuits, tous utilisables hors ligne — opscanopy.com fonctionne sans inscription et sans rien téléverser.
Plus de dimensionnement : la Kubernetes Resource Calculator et le Data Size Converter, ou parcourez le répertoire complet des outils.
Estimations seulement ; le cache KV est dimensionné en FP16 et la surcharge est une provision fixe, alors confirmez toujours auprès du rapport de votre propre runtime avant d’acheter du matériel. OpsCanopy est gratuit et ouvert.