Quantization GGUF en 2026 : Q4_K_M vs Q5_K_M vs Q6_K en pratique

#Pourquoi ce comparatif

La quantization, c'est l'art de compresser les poids d'un modèle de 16 ou 32 bits par paramètre vers 8, 5, 4, voire 2 bits. Moins de bits = moins de VRAM, plus de vitesse, mais qualité dégradée. Le format GGUF de llama.cpp propose une dizaine de variantes, et 90% des utilisateurs prennent Q4_K_M par défaut sans savoir si c'est le bon choix pour leur modèle ni leur cas d'usage.

Le problème : les recommandations qui circulent datent de 2024, ne tiennent pas compte des matrices d'importance (imatrix) généralisées depuis, et confondent perplexité brute avec qualité réelle en français. On a refait les tests proprement sur trois familles 2026 : Qwen3-14B, Llama 4 Scout (17B-A2B MoE) et DeepSeek V3.2-Lite (16B). L'objectif : un comparatif quantization GGUF Q5_K_M vs Q4_K_M honnête et utilisable.

#Rappel rapide : GGUF et les K-quants

GGUF est le format de fichier de llama.cpp. À l'intérieur, chaque tenseur de poids peut être quantizé indépendamment selon une grille de schémas nommés Q2_K, Q3_K_S, Q3_K_M, Q3_K_L, Q4_K_S, Q4_K_M, Q5_K_S, Q5_K_M, Q6_K, Q8_0 — et les variantes IQ (i-quants) pour les très basses précisions.

Le chiffre

Nombre moyen de bits par poids. Q4 ≈ 4 bits, Q5 ≈ 5 bits, Q8 ≈ 8 bits.

_K

Schéma K-quant : poids groupés par blocs avec mise à l'échelle fine. Bien meilleur que les anciens Q4_0 / Q4_1.

_S / _M / _L

Small / Medium / Large. Les tenseurs « importants » (attention, embed) reçoivent une précision supérieure dans M et L. _M est le défaut raisonnable.

Q6_K

Pas de S/M/L : un seul schéma. Très proche de FP16 en qualité, à 60% de la taille.

Q8_0

Quasi-lossless. À garder pour les modèles très petits (< 3B) ou quand la VRAM ne fait pas mal.

#Protocole de test

On a quantizé chaque modèle dans 7 variantes (Q2_K, Q3_K_M, Q4_K_M, Q5_K_M, Q6_K, Q8_0, FP16 référence) en utilisant une matrice d'importance (imatrix) calibrée sur 4 Mo de texte mixte FR/EN/code — wikipedia français, code Python, fiction technique. Les conversions ont été faites avec llama.cpp release b5500+, sur RTX 4090.

# 1. Calibration imatrix sur un corpus mixte
./llama-imatrix \
  -m qwen3-14b-f16.gguf \
  -f calibration_mixte_fr_en_code.txt \
  -o qwen3-14b.imatrix

# 2. Conversion avec imatrix
./llama-quantize \
  --imatrix qwen3-14b.imatrix \
  qwen3-14b-f16.gguf \
  qwen3-14b-Q5_K_M.gguf \
  Q5_K_M

Pour chaque variante, on a mesuré quatre indicateurs : (1) perplexité sur wikitext-103 anglais et un corpus FR de 200 articles ; (2) score sur 50 prompts FR couvrant raisonnement, traduction, code et synthèse, notés à l'aveugle par trois relecteurs ; (3) vitesse en tokens/seconde à context 4k et 32k ; (4) taille fichier en Go.

#Tableau perplexité par quantization

La perplexité (PPL) mesure à quel point le modèle est « surpris » par un texte de référence. Plus c'est bas, mieux c'est. On la compare en pourcentage de dégradation vs FP16 — c'est ça qui est lisible, pas la valeur brute.

Résultats sur Qwen3-14B (perplexité wikitext anglais / corpus FR, écart vs FP16) :

FP16 (référence)

PPL EN 5.42 / FR 7.18 — baseline, taille 28 Go

Q8_0

+0.04% EN / +0.05% FR — taille 14.9 Go. Indistinguable de FP16 sur du texte normal.

Q6_K

+0.15% EN / +0.21% FR — taille 11.5 Go. Excellent, déjà très difficile à distinguer.

Q5_K_M

+0.48% EN / +0.61% FR — taille 9.9 Go. Le sweet spot qualité.

Q4_K_M

+1.12% EN / +1.48% FR — taille 8.4 Go. Le défaut classique, dégradation visible mais modérée.

Q3_K_M

+3.85% EN / +5.12% FR — taille 6.6 Go. Premier vrai cran de qualité perdue.

Q2_K

+11.4% EN / +16.7% FR — taille 5.3 Go. À éviter sauf urgence VRAM.

Sur Llama 4 Scout (17B-A2B MoE), les pertes sont plus marquées en basse quant : Q4_K_M dégrade de +1.9% en FR, Q3_K_M de +6.4%. Les MoE supportent moins bien les quants agressifs, parce que chaque expert ne voit qu'une fraction des tokens et a moins de redondance. Q5_K_M est nettement préférable sur Scout.

Sur DeepSeek V3.2-Lite, comportement classique : Q4_K_M tient à +1.3% FR, Q5_K_M à +0.5%. Q6_K est quasi gratuit côté qualité.

#Dégradation de la qualité en français

C'est l'angle qu'on oublie le plus souvent dans les benchmarks anglo-saxons. Les LLM ont moins de tokens de français à l'entraînement, donc leurs représentations en FR sont plus fragiles à la compression. La règle empirique qu'on a confirmée : la dégradation FR est ~30 à 40% plus marquée que la dégradation EN à quant égal.

Scores qualitatifs FR sur 50 prompts (note moyenne sur 10, trois juges en aveugle), Qwen3-14B :

FP16

8.4 / 10 — la référence

Q8_0

8.4 / 10 — strictement identique en pratique

Q6_K

8.3 / 10 — différence imperceptible

Q5_K_M

8.1 / 10 — quelques tournures un poil moins élégantes, fond inchangé

Q4_K_M

7.7 / 10 — réponses correctes mais simplifications visibles sur les questions complexes

Q3_K_M

6.9 / 10 — hallucinations qui apparaissent, vocabulaire FR appauvri

Q2_K

5.2 / 10 — fautes d'accord, contresens, parfois passage involontaire en anglais

#Vitesse : speed / quality tradeoff

Sur RTX 4090 avec full GPU offload, Qwen3-14B context 4k :

Q4_K_M

78 tok/s — la plus rapide des K-quants viables

Q5_K_M

65 tok/s (-17%) — pénalité réelle mais pas dramatique

Q6_K

54 tok/s (-31%) — on commence à le sentir

Q8_0

42 tok/s (-46%) — la VRAM bouge plus

FP16

26 tok/s (-67%) — pas compétitif sur cette carte

Sur Mac M4 Pro 48 Go (mémoire unifiée), le profil change : Q4_K_M et Q5_K_M sont quasi à égalité (32 vs 30 tok/s) parce que le goulot d'étranglement est la bande passante mémoire, pas le compute. Sur Mac, la « pénalité » de Q5_K_M est négligeable — autant la prendre.

Sur RTX 3060 12 Go, la VRAM devient le facteur dominant : Q5_K_M de Qwen3-14B passe tout juste avec contexte 8k, Q4_K_M laisse de la marge pour 16k. Là, le choix est dicté par le contexte que vous voulez, pas par la qualité.

#imatrix vs static : l'écart est réel

Une quantization « statique » (sans imatrix) attribue la précision uniformément. Une quantization avec imatrix utilise un corpus de calibration pour identifier les poids importants et leur garder plus de précision. C'est devenu le standard chez Bartowski, mradermacher et la plupart des releases sérieuses sur Hugging Face en 2026.

Gain mesuré sur Qwen3-14B Q4_K_M, FR :

Static (sans imatrix)

PPL FR +2.1% vs FP16, score qualitatif 7.4/10

imatrix EN-only

PPL FR +1.6%, score 7.6/10 — mieux mais sub-optimal pour le FR

imatrix mixte FR/EN/code

PPL FR +1.48%, score 7.7/10 — la bonne pratique

L'écart imatrix vs static est plus grand sur les basses quants (Q2, Q3) que sur les hautes (Q6, Q8). En Q4_K_M, l'imatrix vous fait gagner ~0.5–1% de qualité ; en Q3_K_M, c'est 2–3%. En Q2_K, c'est la seule façon d'obtenir un résultat utilisable.

#Recommandation par cas d'usage

Pas de réponse universelle. Voici les choix qu'on défend, classés par profil :

VRAM confortable (modèle prend < 60% de la carte)

Prenez Q6_K. Différence imperceptible avec FP16, fichier 40% plus léger. Pas de raison de descendre.

VRAM juste suffisante pour le modèle

Q4_K_M reste le défaut raisonnable. Économisez la VRAM pour le KV cache et le contexte long.

Usage francophone exigeant (rédaction, juridique, médical)

Montez à Q5_K_M minimum. La pénalité FR de Q4 se voit. Si possible Q6_K.

Modèle MoE (Llama 4, DeepSeek, Qwen3-A3B)

Q5_K_M plutôt que Q4_K_M. Les MoE souffrent plus de la quantization agressive.

Petit modèle (1B–3B) pour edge / CPU

Q8_0 systématiquement. Les petits modèles ont peu de redondance, perdre des bits leur fait très mal.

Modèle de code (Qwen3-Coder, Devstral)

Q5_K_M ou Q6_K. Le code est intolérant aux hallucinations subtiles ; les bénéfices VRAM de Q4 n'en valent pas la peine.

VRAM très limitée (8 Go), gros modèle voulu

IQ3_M ou IQ3_XS avec imatrix. Mieux que Q3_K_M à taille égale.

Pas de GPU, CPU pur

Q4_K_M. Les IQ-quants ralentissent en CPU pur, Q5 prend trop de RAM, Q4_K_M est le meilleur compromis débit/qualité.

#Pièges fréquents

Comparer perplexité entre familles de modèles

Sans intérêt. La PPL n'est comparable qu'à modèle constant, sur le même corpus. Comparez Qwen3 Q4 vs Qwen3 Q5, pas Qwen3 Q4 vs Llama 4 Q4.

Q4_0 ou Q4_1

Ces vieux schémas non-K n'ont plus de raison d'exister. Si vous tombez sur un GGUF Q4_0 récent, c'est probablement un upload paresseux — passez votre chemin.

Quantization du KV cache

C'est un autre sujet (paramètre --cache-type-k q8_0 dans llama.cpp). Souvent confondu avec la quantization du modèle. Faire les deux à la fois divise la VRAM mais cumule la perte de qualité.

Tenseurs critiques en basse précision

Certains outils permettent de surclasser embed et output en Q8 même dans un GGUF Q4. C'est ce que fait Q4_K_M par défaut. Si vous voyez Q4_K_S marqué « pur Q4 » par un uploader, méfiez-vous : qualité réelle moindre.

Croire que Q5_K_M coûte 25% plus de VRAM que Q4_K_M

Faux. L'écart fichier réel est ~18%. Et une fois en VRAM, le KV cache (contexte) prend autant de place dans les deux cas.

#Pour aller plus loin

Ce comparatif suppose que vous savez déjà manipuler les GGUF et lancer llama.cpp. Si certains points restaient flous, voici les guides connexes :

Choisir sa quantification (Q4, Q5, Q8, FP16)

Notre guide d'introduction si vous voulez les fondamentaux avant ce comparatif avancé.

TurboQuant : quantifier les gros modèles

L'étape d'après pour faire tenir un modèle frontier (>100B) sur du matériel grand public.

Compiler llama.cpp avec CUDA

Indispensable pour quantizer vous-même avec imatrix sur des poids fraîchement publiés.