Quantification GGUF : Q4_K_M vs Q8_0, taille et VRAM

Choisis Q4_K_M par défaut ; monte en Q6_K ou Q8_0 quand il te reste de la VRAM et qu'il te faut les derniers pourcents de qualité. La quantification GGUF compresse les poids d'un modèle depuis 16 bits vers moins — Q4_K_M stocke environ 4.85 bits par poids, donc un modèle 7B passe de ~14 Go à ~4.1 Go avec une perplexité qui se dégrade en général de moins de 1 %. La question « quel niveau de quantification GGUF utiliser » a une réponse d'un ennui rassurant, que tout le drame en ligne masque. Voici : la table complète des niveaux — de Q2_K à Q8_0, taille, VRAM et perte de qualité mesurée — le calcul de taille à faire toi-même, et une commande pour mesurer les dégâts sur ton propre matériel au lieu de croire le benchmark d'un inconnu. Si la quant part vers vLLM plutôt que llama.cpp, can vLLM run GGUF détaille le plugin et la règle GPU-only.

Que fait concrètement la quantification GGUF ?

Un modèle est entraîné en flottant 16 bits (FP16 ou BF16) : chacun de ses milliards de poids est un nombre de 2 octets. La quantification compresse chaque poids sur moins de bits. La méthode naïve — arrondir chaque poids en entier 4 bits — détruit les valeurs petites mais importantes, alors GGUF a deux astuces :

1. Le scaling par blocs. Les poids sont groupés par blocs (32 en général), et chaque bloc reçoit son propre facteur d'échelle. Les valeurs 4 bits sont des offsets à l'intérieur de ce bloc, donc une large plage de magnitudes survit.
2. Les k-quants sensibles à l'importance. Le « K » de Q4_K_M désigne des super-blocs d'échelles, plus un traitement distinct des couches d'attention et feed-forward, parce qu'elles tolèrent la compression de façon inégale.

La famille « I » (IQ4_XS et compagnie) va plus loin avec des dictionnaires de codes issus de la théorie de l'information, empruntés à la compression d'images. Même idée, encodage plus raffiné : moins de bits par poids à qualité comparable, au prix d'une inférence un peu plus lente sur certains backends.

Une clarification qui évite l'essentiel de la confusion : la quantification ne touche que les poids stockés. Architecture, tokenizer et gestion du contexte restent intacts. Un fichier Q4 et un fichier Q8 du même modèle, c'est le même modèle avec un manteau différent.

Q4 vs Q8 : plus de bits, vraiment mieux ?

Oui techniquement, non perceptivement. En prenant pour référence les mesures de perplexité de llama.cpp lui-même sur les modèles Llama : Q8_0 reste à ~0.02 % du FP16 — pour tout usage pratique, c'est sans perte. Q6_K est quasi indiscernable. Q4_K_M prend environ 1 à 2 % de perplexité, Q4_0 un peu plus, et Q2_K, c'est là que les réponses cohérentes commencent à s'effondrer sur les petits modèles.

Deux règles que ces chiffres imposent :

• La taille du modèle achète de la marge. Un 70B survit bien mieux au Q2/Q3 qu'un 7B, parce que les grands modèles sont plus redondants. Quantifier un 7B en Q2, c'est de l'amputation ; quantifier un 70B en Q3, c'est de la couture.
• Le plancher de qualité bouge avec la tâche. Le chat tolère le Q4. La génération de code exact, les maths et le RAG sur des documents précis exposent le bruit de quantification plus tôt. Si un modèle Q4 écrit du code subtilement faux, teste le même modèle en Q6_K avant de condamner le modèle.

Niveau	Bits/poids	Taille vs FP16	Perte de qualité	À utiliser quand
Q2_K	~3.4	~21 %	Sévère sous 13B	Rien d'autre ne rentre, grands modèles uniquement
Q3_K_M	~3.9	~25 %	Notable	VRAM juste, modèles ≥14B
Q4_K_S	~4.6	~29 %	Faible	Q4_K_M ne rentre pas et on s'en approche
Q4_K_M	~4.85	~30 %	~1 % de perplexité	Le défaut. Le meilleur compromis qualité/taille
Q5_K_M	~5.7	~35 %	~0.5 %	VRAM dispo, tâches critiques sur la qualité
Q6_K	~6.6	~41 %	Quasi nulle	Code/maths, tient encore confortablement
Q8_0	~8.5	~53 %	Quasi aucune	Runs de référence, bases de fine-tune
IQ4_XS	~4.3	~27 %	≈Q4_K_M	Q4_K_M un peu trop gros, backend compatible i-quants

Combien de VRAM demande chaque niveau ?

Fais le calcul toi-même au lieu d'apprendre des tableaux par cœur — c'est une ligne :

size_GB ≈ (bits_per_weight × params) / 8
# modèle 8B @ Q4_K_M : 4.85 × 8 / 8 ≈ 4.9 Go
# modèle 8B @ Q8_0 :   8.50 × 8 / 8 ≈ 8.5 Go

Ajoute ensuite ce que la formule oublie : le cache KV (il grandit avec la longueur de contexte — de quelques centaines de Mo à plusieurs Go), les activations et les buffers de calcul. Marge pratique : un modèle « 4.9 Go » veut une carte de 6 Go en contexte 4k, plus flash-attention et quantification du cache KV pour y rester à 16k. Les poids font le titre, pas toute l'addition.

Quelle quantification GGUF utiliser ?

Ordre de décision, sans exception qui vaille d'être apprise par cœur :

1. Calcule d'abord ton budget contexte + KV, ensuite les poids. Un contexte qui ne rentre pas est pire qu'une qualité que tu ne peux pas mesurer.
2. Par défaut, Q4_K_M. C'est le défaut de la communauté pour une raison — environ 1 % de perplexité pour 70 % de la taille. Chaque registre, y compris celui d'Ollama, l'expédie en baseline.
3. Passe au Q6_K quand la tâche punit le bruit : code, maths, extraction, tout ce que tu envoies à un pipeline sans surveillance.
4. Q8_0 uniquement pour référence — tests A/B, mesure des dégâts de quantification, base de fine-tune. Au quotidien, ça achète surtout de la chaleur dans tes capteurs de VRAM.
5. Descends sous Q4 sous contrainte seulement, et seulement sur de grands modèles. Teste avec un prompt volontairement coriace avant de te fier au résultat.

Si tu choisis quel fichier télécharger sur Hugging Face, préfère un Q4_K_M.gguf unique aux splits shardés, sauf si l'uploader ne publie que ces derniers — moins de pièces mobiles. Et si tu choisis où l'exécuter, le choix du moteur est un autre axe : voir llama.cpp vs Ollama pour cet axe-là.

Comment mesurer toi-même les dégâts de la quantification ?

Les benchmarks diffèrent ; ton prompt, lui, est constant. Compile llama.cpp une fois, télécharge deux niveaux du même modèle, et mesure à la fois la perplexité (plus bas = mieux) et les tokens/seconde :

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf \
  --local-dir models

# perplexité sur un extrait de wiki-text (plus bas = plus proche du modèle d'origine)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# et la vitesse sur le même matériel
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Le chiffre du Q4_K_M sera quelques centièmes de point moins bon que celui du Q8_0, et le fichier sera ~40 % plus petit. Si ta tâche en aval ne voit pas la différence — et pour la plupart, c'est le cas — tu as ta réponse sans lire le leaderboard de personne.

La quantification compromet-elle la vie privée ou le 100 % local ?

Non — c'est de l'arithmétique sur les poids, entièrement hors ligne, et le fichier quantifié n'est qu'un conteneur plus petit des mêmes paramètres. Faire tourner un Q4_K_M en local fuit exactement autant (ou aussi peu) que le modèle pleine précision en local : rien ne quitte la machine. La variable qui compte pour la vie privée, c'est où tourne l'inférence, pas la largeur en bits. Les habituelles réserves sur la provenance des modèles valent pour tous les niveaux : un fine-tune « uncensored » à base volée en Q8 n'est pas plus sûr que les mêmes poids en Q4. Pour le côté format de fichier, voir comment exécuter des modèles GGUF en local.

Quel niveau choisir, au final ?

Q4_K_M, et arrête de lire des forums à ce sujet. Monte au Q6_K pour le travail gourmand en précision si la VRAM suit, garde un Q8_0 sous le coude pour les comparaisons A/B, et traite tout ce qui est sous Q4 comme une ration de secours réservée aux grands modèles. La seule erreur qui vaille la peine d'être évitée est symétrique : se soucier du Q4 contre Q5 en ignorant la longueur de contexte, qui casse plus de setups locaux que n'importe quel quant ne l'a jamais fait.