> Calculatrice VRAM GGUF : vérifiez avant de télécharger▋

ggml_backend_cuda_buffer_type_alloc_buffer: failed to allocate 3412 MiB. Le fichier s'est téléchargé sans histoire. La carte n'aurait de toute façon jamais pu le prendre — et l'arithmétique qui le prédisait tenait sur un ticket de caisse. Le workflow habituel part à l'envers : lancer le téléchargement, regarder la barre de progression, laisser l'erreur out-of-memory faire le calcul. C'est cet ordre-là que l'outil du jour refuse. La calculatrice VRAM GGUF est en ligne : taille du modèle, quantization et contexte en entrée — poids, cache KV et verdict pour chaque carte courante en sortie. Ou à l'envers : partez de votre budget VRAM vers le quant le plus large qui tient. Tout tourne dans votre navigateur, rien n'est envoyé, et l'outil rejoint le hub run-LLMs-locally à côté du reste du cluster.

Deux modes, parce que la question arrive sous deux formes :

• « De quelle VRAM ce modèle a-t-il besoin ? » — paramètres, quant, contexte, architecture en entrée ; le détail chiffré et un verdict carte par carte (6 à 96 Go) en sortie.
• « Qu'est-ce qui tient dans ma VRAM ? » — budget, taille du modèle, contexte en entrée ; chaque quant de Q2_K à F16 avec son verdict en sortie.

De quelle VRAM un modèle GGUF a-t-il besoin ?

Trois parts, toujours les mêmes :

VRAM ≈ poids + cache KV + surcharge
poids      = params × bits-par-poids / 8
cache KV   = 2 × couches × kv_dim × contexte × 2 octets   (f16)
surcharge  ≈ 0,7 Go CUDA/exécution + ~5% de buffers de calcul

Exemple concret, le plus courant : un modèle 8B en Q4_K_M avec 32k de contexte. Poids : 8 × 4,85 / 8 = 4,85 Go. Cache KV : 2 × 32 couches × 1024 kv-dim × 2 octets = 128 Ko par token × 32 768 = 4,0 Go. Avec la surcharge : ~9,8 Go au total — le « Q4 8B » que tout le monde présente comme un modèle pour carte 8 Go la rate de 23 % dès que le contexte s'allonge. Le quant n'a jamais été le coupable ; le contexte, si. Ce mode de panne a sa note de terrain, puisqu'il mange aussi la RAM système en cas d'offload.

Quelle quant tient sur ma carte ?

Le mode 2 existe parce que c'est la question inversée que les gens posent vraiment : une carte fixe, un modèle en tête. Un 7B en contexte 4096 face à un budget de 8 Go renvoie exactement ceci :

Quant	Poids	Total (est.)	Verdict
Q4_K_M	4,24 Go	~5,7 Go	tient avec marge
Q6_K	5,77 Go	~7,3 Go	juste
Q8_0	7,44 Go	~9,0 Go	offload CPU partiel, bien plus lent

Un écran, et le vieux débat de forum « Q4 ou Q8 » se réduit à la réponse de votre matériel plutôt qu'à celle du voisin.

D'où viennent les chiffres

La table bits-par-poids vient des formats de quant ggml de llama.cpp — les mêmes chiffres que ceux des fichiers publiés sur Hugging Face :

Quant	bpw	Quant	bpw
Q2_K	3,35	Q5_K_M	5,69
Q3_K_M	3,91	Q6_K	6,59
IQ4_XS	4,25	Q8_0	8,50
Q4_K_M	4,85	F16	16,0

La moitié cache KV s'appuie sur la géométrie publique de chaque famille. L'attention groupée par requête (GQA) y fait tout : un 8B de classe Llama-3 garde 8 têtes KV × 128 dims × 32 couches, soit 128 Ko par token — alors qu'un Llama 2 13B, sans GQA, brûle 640 Ko par token, cinq fois plus, pour un modèle d'une génération plus ancienne. Le menu déroulant d'architecture couvre les quatre formes courantes plus un mode personnalisé pour tout ce qu'on peut lire dans un config.json.

La taille du fichier vous disait ce que vous alliez télécharger. Elle n'a jamais dit ce que vous pourriez exécuter.

Ce que les estimations ignorent volontairement

Trois choses, à dessein. Le routage mixture-of-experts : l'infrance ne touche que les experts actifs, mais l'outil price le jeu de poids complet, donc les totaux MoE lisent haut. La quantization mixte : Q4_K_M est lui-même une moyenne entre tenseurs, un vrai fichier atterrit à quelques pourcents de la valeur table. Et le padding côté CUDA varie selon la version du backend — les 0,7 Go forfaits sont un chiffre médian, pas une constante physique. Quand une décision vaut plus que quelques centaines de Mo, sautez les estimations et lisez l'en-tête du fichier avec le gguf_dump.py de llama.cpp — les calculatrices qui lisent l'en-tête font exactement cela. Celle-ci reste arithmétique à dessein : trois entrées que vous pouvez recalculer à la main, et un verdict avec lequel vous pouvez argumenter.

L'outil vit sur github.com/mrsaynothing/gguf-vram-calculator — un fichier HTML, zéro dépendance, zéro build. Il côtoie le guide GGUF local, llama.cpp vs Ollama et la shortlist best-local-LLM, avec le pendant côté service dans vLLM peut-il lire du GGUF.

Si un verdict contredit vos temps de chargement, ouvrez une issue sur le dépôt avec le modèle, le quant et le contexte — la table doit survivre au contact du vrai matériel, et chaque écart est une ligne à corriger.