Vous téléchargez un modèle sur Hugging Face et vous tombez sur une liste interminable : Q4_K_M, Q5_K_M, Q6_K, Q8_0, sans parler des IQ4_XS et autres Q3_K_S. Quinze fichiers du même modèle, des tailles qui vont du simple au double, et zéro explication claire. Résultat : on prend le plus gros « pour être tranquille », on sature sa VRAM, et le modèle rame. Ou l'inverse : on prend le plus petit, et le modèle devient bête sans qu'on comprenne pourquoi.
Cet article démonte le sujet sans jargon inutile. Objectif : que vous sachiez, en 2 minutes, quel quant télécharger pour votre machine et votre usage, avec de vrais chiffres à l'appui.
Quantifier, c'est quoi exactement ?
Un LLM stocke ses poids en virgule flottante 16 bits (FP16/BF16) à la sortie de l'entraînement. Pour Llama 3.1 8B, ça représente environ 16 Go (32 Go en F32). La quantification consiste à réduire le nombre de bits par poids : 8, 6, 5, 4, voire 2 bits. Moins de bits = fichier plus petit, moins de VRAM, mais une perte de précision sur chaque poids.
Le format GGUF (GPT-Generated Unified Format), créé par le projet llama.cpp, est le standard mono-fichier qui embarque poids quantifiés, métadonnées et tokenizer. C'est ce qu'utilisent Ollama, LM Studio et llama.cpp. Si vous faites de l'IA locale, vous manipulez du GGUF, point.
Bits par poids : ne vous fiez pas au chiffre du nom
Le piège numéro un : croire que « Q4 » veut dire exactement 4 bits par poids. Faux. Les K-quants (le K dans Q4_K_M) utilisent une structure en super-blocs avec double quantification et une approche layer-aware : les couches d'attention et de sortie reçoivent plus de bits, les couches feed-forward moins. Du coup les bits effectifs par poids (bpw) sont non entiers :
- Q4_K_M — ~4,9 bpw effectifs
- Q5_K_M — ~5,5 bpw
- Q6_K — ~6,5 bpw
- Q8_0 — 8,0 bpw (quasi sans perte)
Le suffixe _S / _M / _L (Small / Medium / Large) ajuste le compromis taille/fidélité à bit-depth égal. La stratégie compte plus que le nombre de bits brut. Démonstration imparable : un Q4_K_M (delta de perplexité +0,0535 vs FP16) écrase littéralement un vieux Q4_0 legacy (+0,2499) — même budget de bits, mais une intelligence de répartition radicalement supérieure. Conséquence pratique : fuyez les formats legacy Q4_0 / Q4_1 / Q5_0, ils n'ont plus aucune raison d'exister.
L'impact réel sur la qualité (perplexité)
La perplexité mesure à quel point le modèle est « surpris » par un texte de référence : plus c'est bas, mieux c'est. En prenant Q4_K_M comme base 100 %, la rétention de qualité relative ressemble à ça :
- Q2_K : ~85 % — décrochage net, à éviter sauf désespoir matériel
- Q3_K_M : ~90 %
- Q4_K_M : 100 % (référence pratique)
- Q5_K_M : ~101,5 %
- Q6_K : ~102 %
- Q8_0 : ~103 % — quasi indiscernable du FP16
Q8_0 mérite une mention spéciale : sa hausse de perplexité face au FP16 est d'environ 0,01 point (par exemple 6,00 → 6,01). C'est essentiellement sans perte, et son chemin de déquantification simple le rend rapide en inférence CPU. Mais regardez bien l'échelle : entre Q5_K_M et Q8_0, vous gagnez ~1,5 % de qualité pour ~50 % de taille en plus. Les rendements décroissants sont brutaux dans le haut du spectre.
Le piège de la perplexité : tous les usages ne sont pas égaux
Voici ce que les tableaux ne disent pas. La perplexité est une moyenne statistique sur du texte général. Or la quantification ne dégrade pas toutes les tâches uniformément : elle frappe plus fort le code et les maths/STEM que la conversation, et surtout elle amplifie les faiblesses préexistantes du modèle au lieu d'en créer de nouvelles partout.
Traduction concrète : si vous faites de l'assistant chat généraliste, Q4_K_M passe inaperçu. Si vous faites de la génération de code ou du raisonnement mathématique exigeant, montez à Q5_K_M ou Q6_K — la différence devient palpable sur les cas tordus. Et validez toujours sur vos propres prompts : un benchmark de perplexité n'est qu'un guide, jamais une garantie sur votre tâche réelle.
L'imatrix : le levier gratuit que tout le monde ignore
L'importance matrix (imatrix) est une technique de calibration qui identifie quels poids comptent le plus. On fait passer des données de calibration dans le modèle (outil llama-imatrix), et le quantizer garde les poids « importants » avec plus de soin via le flag --imatrix.
Deux idées reçues à tuer :
- L'imatrix n'est pas réservée aux IQ-quants. On peut (et on devrait) l'appliquer aussi aux K-quants classiques. C'est de la qualité gratuite. Si les imatrix et les i-quants sont apparus en même temps, c'est surtout parce que le premier i-quant était un 2 bits, inutilisable sans calibration.
- On ne peut pas deviner du nom de fichier si une imatrix a été utilisée. Vérifiez la carte du modèle sur Hugging Face. Les quants de bartowski, par exemple, sont systématiquement imatrix.
Règle d'or : en dessous de 4 bits (et surtout ≤ 3 bits), l'imatrix est indispensable. Au-dessus, elle reste un bonus appréciable. Quant aux craintes de biais linguistique de la calibration : les tests de la discussion #5263 de llama.cpp montrent que n'importe quel jeu de données fait mieux qu'une quantification « vanilla » sans imatrix.
K-quants vs IQ-quants : qualité par octet contre vitesse
Les IQ-quants (i-quants) sont la génération suivante, bâtie autour de l'imatrix. Leur atout : la qualité par octet. Exemple chiffré sur Llama 3.1 8B (chiffres llama.cpp) : IQ4_XS = ~4,46 bpw / 4,17 Gio contre Q4_K_M = ~4,89 bpw / 4,58 Gio. IQ4_XS est plus compact et un poil plus rapide en génération, mais plus lent en traitement de prompt, et surtout plus sensible à la qualité de la calibration.
Le vrai critère de choix est souvent le matériel : les i-quants compressent plus mais décodent plus lentement sur CPU ; les K-quants donnent souvent de meilleurs tokens/s sur matériel grand public, vieux GPU, Mac, ou inférence CPU pure. La consigne communautaire est simple : testez les deux sur votre machine. Sur ce point, comprendre le rapport entre VRAM, RAM et taille de modèle change tout pour calibrer vos attentes.
Tailles réelles et choix par matériel
Voici les tailles concrètes des quants bartowski de Llama 3.1 8B sur Hugging Face — la référence que tout le monde télécharge :
| Quant | Taille | Bits/poids | Qualité relative | Usage |
|---|---|---|---|---|
| Q3_K_M | ~4,0 Go | ~3,9 bpw | ~90 % | Moins de 8 Go de VRAM, avec imatrix |
| IQ4_XS | 4,17 Gio | ~4,46 bpw | ≈ Q4_K_M | Plus compact, mais décodage CPU plus lent |
| Q4_K_M | 4,92 Go | ~4,89 bpw | 100 % (référence) | Le défaut sensé — 8 à 12 Go de VRAM |
| Q5_K_M | 5,73 Go | ~5,5 bpw | ~101,5 % | Sweet spot — 12 à 16 Go, code et maths |
| Q6_K | 6,6 Go | ~6,5 bpw | ~102 % | Quasi-lossless équilibré — 24 Go et plus |
| Q8_0 | 8,54 Go | 8,0 bpw | ~103 % | Datasets de référence, distillation |
| F32 | 32,1 Go | 32 bpw | référence brute | Non pertinent en inférence locale |
Arbre de décision selon votre VRAM (en gardant de la marge pour le contexte/KV-cache) :
- < 8 Go VRAM → Q3_K_M ou IQ4_XS (avec imatrix)
- 8–12 Go VRAM → Q4_K_M (le choix par défaut pour la majorité)
- 12–16 Go VRAM → Q5_K_M ou Q6_K (recommandé pour code/maths)
- 16–24 Go VRAM → Q8_0 si vous voulez du quasi-lossless
- 24 Go+ → Q6_K reste un excellent défaut équilibré pour servir du 7B–14B ; gardez F16 pour les cas vraiment critiques
Bon à savoir : Ollama télécharge du Q4_K_M par défaut. Un simple ollama pull llama3.1:8b vous donne le Q4_K_M. Pour un autre quant : ollama pull llama3.1:8b-q8_0. Et pour récupérer un fichier précis depuis Hugging Face : huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF --include "*Q5_K_M.gguf" --local-dir ./. Si vous orchestrez ça avec des clients modernes, voyez nos intégrations Ollama (Codex, Claude, OpenCLAW).
Le verdict
Pas de suspense, voici la hiérarchie honnête :
- Q4_K_M = le défaut universel. 72 % de VRAM économisée, 92–95 % de la qualité conservée. Si vous hésitez, c'est lui.
- Q5_K_M = le sweet spot. +15–20 % de VRAM pour une marge de sécurité réelle sur le code et le raisonnement. Mon choix par défaut dès qu'on a la VRAM.
- Q6_K = quasi-lossless équilibré. Idéal pour servir du 7B–14B sur 24–48 Go quand on veut dormir tranquille.
- Q8_0 = pour le quasi sans perte. Mais 2× la taille de Q4_K_M pour ~3 % de qualité en plus : réservez-le aux cas où chaque token compte (datasets de référence, distillation).
La leçon de fond : ne chassez pas les derniers pourcentages de perplexité au prix de votre VRAM. Le bon réflexe en 2026, c'est de prendre le quant le plus gros qui rentre confortablement avec votre contexte, de privilégier les fichiers imatrix, et de valider sur vos vrais prompts. Le reste, c'est de la cosmétique.
Commentaires