Le tableau de fit VRAM 8 Go ment de 7 pour cent

Meilleur modèle ollama pour 8 Go de VRAM : qwen2.5:7b (Q4_K_M) — environ 5.4 GiB tout compris à 8k de contexte, la plus grosse marge, et le seul des cinq qui tienne encore à 32k. llama3.1:8b (≈6.2 GiB) et qwen3:8b (≈6.4 GiB) passent à 8k. gemma2:9b réclame ≈8.6 GiB à 8k et échoue — 4k de contexte, pas plus.

Que contient réellement une VRAM de 8 Go ?

Thèse : une carte « 8 Go » n'héberge jamais 8 Go décimaux de modèle — elle héberge 8 GiB binaires, et le bureau prend sa part avant même que le modèle n'arrive. Le marketing a acheté le « 8 » deux fois et lui a donné deux sens différents ; votre tueur de mémoire ne reconnaît que l'un des deux. Les 8 Go de la carte, ce sont 8 × 2³⁰ octets = 8.59 Go décimaux. Les 4.92 Go d'un fichier GGUF, ce sont 4.92 × 10⁹ octets. Même mot, deux règles, un écart fixe de 7.4 % entre elles — j'ai commencé à l'appeler le fantôme des sept pour cent : il hante chaque tableau de VRAM du web, et presque aucun tableau n'avoue quelle règle il a choisie.

La deuxième entaille que personne ne provisionne : la carte n'est jamais vide. Un bureau Linux avec compositeur y gare 0.3–0.5 GiB, et le contexte CUDA/ROCm en prend ~0.3 de plus. Sans bureau, vous jouez avec ~7.6 GiB ; sur un bureau, comptez 7.3 GiB utilisables. Chaque verdict de fit de cet article se juge à cette ligne.

Pourquoi les tableaux de VRAM divergent-ils de 7 pour cent ?

Thèse : les tableaux n'arrondissent pas différemment — ils mélangent les règles, et à la marge, c'est le mélange qui décide. Prenons gemma2:9b. Le fichier annonce 5.76 Go (décimal). Un tableau naïf compare 5.76 à « 8 » et imprime 72 % plein — très bien, on livre. La pile honnête à 4k de contexte : 5.37 GiB (fichier) + 1.31 GiB (KV) + 0.6 GiB (plancher) = 7.28 GiB face à 7.3 utilisables. Même modèle, même carte, même contexte : les 72 % du tableau et les 99.7 % du réel sont la même ligne. La division tient en une ligne — GiB = Go ÷ 1.074 — et chaque verdict ci-dessous montre sa division.

Meilleur modèle ollama pour 8 Go de VRAM : le tableau des verdicts

Thèse : à 8k de contexte, quatre des cinq valeurs par défaut de la communauté passent — et celle qui échoue est le 9B que les listicles n'arrêtent pas de recommander. Tailles mesurées aujourd'hui via l'API fichiers de Hugging Face (dépôts GGUF de bartowski, Q4_K_M — le quant par défaut d'ollama pour ces familles ; mistral:7b livre du q4_0 par défaut, à ~2 % du fichier mesuré) :

curl -s https://huggingface.co/api/models/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/tree/main \
  | jq '.[] | select(.path | test("Q4_K_M"))'

vérification : Q4_K_M.gguf → 4,920,739,232 octets, relevés le 2026-11-01. La même ligne de commande a tourné pour les cinq dépôts.

modèle (tag ollama)	fichier, Go décimaux	÷ 1.074 = GiB	KV à 8k	plancher d'overhead	total GiB	verdict à 8k
qwen2.5:7b	4.68	4.36	0.44	0.6	5.40	passe — le plus à l'aise ; tient 32k (6.71)
mistral:7b	4.37	4.07	1.00	0.6	5.67	passe, à l'aise
llama3.1:8b	4.92	4.58	1.00	0.6	6.18	passe ; 16k au fil du rasoir (7.18) ; 32k échoue (9.18)
qwen3:8b	5.03	4.68	1.13	0.6	6.41	passe — surveillez le budget de réflexion
gemma2:9b	5.76	5.37	2.63	0.6	8.59	échoue à 8k — 4k seulement (7.28, au fil du rasoir)

Le gagnant est ennuyeux à dessein : ollama pull qwen2.5:7b vous donne le plus de contexte utilisable par GiB, et c'est la seule ligne qui tienne encore quand vous doublez le contexte à 32k (6.71 GiB). La ligne d'échec, c'est le reçu qui justifie l'article : gemma2:9b rate 8k de 1.29 GiB même sans aucun overhead provisionné — 5.37 + 2.63 = 8.0 face à 7.3 utilisables. Aucun quant ne l'arrange ; Q4_K_M est déjà le plus petit.

Quelle VRAM le cache KV mange-t-il ?

Thèse : le contexte est le second modèle que vous chargez, et l'architecture fixe le prix — par token, gemma2:9b facture six fois le tarif de qwen2.5:7b. Le cache KV est la mémoire de travail du modèle pour la conversation : 2 octets × couches × kv-heads × head-dim, en fp16, par token. L'attention svelte du Qwen2.5-7B, 28×4×128, facture 56 KiB/token. Celle du Gemma-2-9B, 42×8×256, facture 336 KiB/token. Ce tarif au token — non la taille du fichier — est ce qui tue le long contexte sur une petite carte.

modèle	KV à 4k	KV à 8k	KV à 16k	KV à 32k
qwen2.5:7b (56 KiB/tok)	0.22 GiB	0.44	0.88	1.75
mistral:7b / llama3.1:8b (128)	0.50	1.00	2.00	4.00
qwen3:8b (144)	0.56	1.13	2.25	4.50
gemma2:9b (336)	1.31	2.63	5.25	10.50

Note propre à 2026 : qwen3 est un modèle réflexif. Ses tokens de raisonnement sont des tokens de contexte — une réponse courte qui a « réfléchi » pendant 3,000 tokens paie ces 3,000 à 144 KiB pièce jusqu'à la remise à zéro du contexte. Sur une carte de 7.3 GiB, le budget de réflexion n'est pas un réglage d'ambiance : c'est le tableau KV ci-dessus, intérêts composés.

Le calcul, ligne par ligne

Ligne utilisable : 8 GiB − 0.4 (bureau, compositeur + affichage) − 0.3 (contexte CUDA) ≈ 7.3 GiB ; le headless récupère ~0.3 de plus. Plancher d'overhead 0.6 = contexte CUDA ~0.3 + tampon de calcul ~0.3 à 8k ; la fourchette honnête est de 0.4 à 1.2 GiB selon le backend et le contexte — le verdict d'échec de gemma2 tient sur toute la fourchette, voilà pourquoi le plancher suffit. Taux KV : llama3.1-8B 32L×8kv×128d ; qwen2.5-7B 28×4×128 ; qwen3-8B 36×8×128 ; gemma2-9B 42×8×256 ; mistral-7B-v0.3 32×8×128 — le tout ×2 octets ×2 (K et V). Conversions en GiB : octets du fichier ÷ 2³⁰ (4,920,739,232 → 4.58 ; 4,683,074,240 → 4.36 ; 4,372,812,000 → 4.07 ; 5,027,784,224 → 4.68 ; 5,761,057,728 → 5.37). Note d'honnêteté sur gemma2 : la moitié de ses couches sont à fenêtre glissante, donc le KV réel de llama.cpp est plus petit que ce chiffre conservateur à attention complète — le verdict d'échec n'a pas besoin de cette remise pour tenir. dernier test 2026-11-01.

Ce que ce tableau ne peut pas vous dire

Thèse : chaque nombre ci-dessus est de l'arithmétique sur des tailles publiques — et les deux nombres que le tableau devine encore sont l'overhead et le MoE, précisément là où vivra la prochaine mesure. Le plancher d'overhead est une fourchette en uniforme ; tout calculateur qui imprime un seul chiffre d'overhead devine, y compris notre article sur la calculatrice GGUF VRAM — sa plaie, celle qui refuse la math MoE, y est documentée. Et la ligne de fit bouge avec votre bureau : démarrez en headless, récupérez ~0.3 GiB, et gemma2:9b à 4k passe du fil du rasoir à simplement serré. Ce qui trancherait : les cinq modèles via ollama sur une vraie carte de 8 Go, avec les chiffres de nvidia-smi imprimés face aux prédictions de ce tableau. Ce banc n'est pas cet article — la carte de ce bureau n'a pas à se faire passer pour lui.

dernier test 2026-11-01 — tailles relevées en direct via l'API fichiers de Hugging Face ; le calcul de fit est une division, pas du ressenti.