LLM auto hébergées · 31 October 2026

Le vrai coût du Q4 : ce que la quantification GGUF fait vraiment à vos modèles en 2026

On télécharge du Q4_K_M comme on choisissait un JPEG à 80 % : par réflexe, sans y penser. Pourtant, en 2026, les modèles MoE, les fenêtres de contexte de plusieurs dizaines de milliers de tokens et les usages multilingues changent la donne. Voici ce qu’on perd réellement quand on compresse un LLM — et pourquoi le « Q4 par défaut » est souvent un mauvais calcul.

Le Q4 par réflexe : comment un réglage technique est devenu le JPEG du LLM local

Il y a une scène que tout le monde connaît dans la communauté du LLM local. Vous découvrez un modèle qui fait envie — un Qwen, un Llama, un Mistral fraîchement publié — et vous vous retrouvez face à une liste interminable de fichiers : Q2_K, Q3_K_S, Q4_0, Q4_K_M, Q5_K_M, Q6_K, Q8_0, IQ4_XS… Le réflexe, presque pavlovien, consiste à cliquer sur le Q4_K_M. Pourquoi lui plutôt qu’un autre ? Parce que « c’est le bon compromis », parce que « tout le monde le prend », parce que c’est le fichier que les guides mettent en avant et que les interfaces de téléchargement suggèrent en premier.

La comparaison avec le JPEG à 80 % est éclairante. Quand vous exportez une photo, vous savez intuitivement qu’à 80 % de qualité vous ne verrez pas la différence sur un écran, mais que vous économisez 70 % de l’espace disque. Le Q4_K_M fonctionne sur la même promesse : diviser par quatre environ la mémoire nécessaire tout en conservant, dit-on, l’essentiel de la qualité. Un blog tiers résume l’argument marketing en une ligne : environ 72 % de VRAM économisée pour 92 à 95 % de la qualité conservée. Sur le papier, c’est imbattable.

Mais cette promesse mérite d’être disséquée. D’abord parce que ces chiffres proviennent de sources éditoriales qui ne publient ni protocole ni jeu de données de référence. Ensuite parce que la notion même de « qualité » d’un LLM n’est pas un scalaire unique : un modèle peut conserver une perplexité quasi intacte et se mettre à produire du code subtilement faux, ou à dérailler dans une chaîne de raisonnement à la troisième étape. La perplexité globale est une moyenne, et une moyenne masque toujours les dégâts localisés.

Le contexte de 2026 rend ce réflexe encore plus discutable. Les modèles populaires ne sont plus seulement des denses de 7 ou 8 milliards de paramètres : ce sont des architectures à mélange d’experts (MoE), des fenêtres de contexte étendues, des usages multilingues et du code en production. Or ces trois dimensions — MoE, contexte long, tâches exigeantes — sont précisément celles où la quantification à 4 bits frappe le plus fort. Le Q4_K_M n’est pas « mauvais » ; il est simplement devenu un choix par défaut hérité d’une époque où l’on faisait tourner un 7B sur un laptop pour discuter. Le fil conducteur de ce dossier : arrêter de répéter le dogme du forum et regarder la chaîne de dégradation réelle, maillon par maillon.

Sous le capot : ce qu’un bloc de 32 poids devient quand on le compresse

Pour comprendre où la perte se produit, il faut ouvrir le capot. Un modèle en FP16 stocke chaque poids sur 16 bits, soit 2 octets. La quantification consiste à représenter ces poids sur moins de bits — 8, 6, 5 ou 4 — en regroupant les valeurs par blocs. Le principe de base est simple : au lieu de stocker chaque poids individuellement, on découpe le tenseur en blocs (typiquement 32 poids), et pour chaque bloc on stocke une échelle (scale) et parfois un minimum, plus les valeurs compressées. À la lecture, on reconstruit approximativement chaque poids par une opération inverse. La formule de taille est d’ailleurs d’une simplicité désarmante : octets ≈ (paramètres × bits par poids) ÷ 8. Un modèle de 8 milliards de paramètres pèse ainsi environ 16 Go en FP16 et environ 4,5 Go en 4 bits.

Le format GGUF, successeur de GGML issu du projet llama.cpp, a standardisé tout cela dans un fichier unique qui embarque les poids quantifiés, les métadonnées d’architecture, le tokenizer et le vocabulaire. Le fichier est aligné (par défaut sur 32 octets) pour permettre le mmap, c’est-à-dire le chargement paresseux en mémoire. C’est ce qui explique sa portabilité : un binaire C++ sans dépendances lourdes, pas de framework Python, un format autoportant qui a fait de GGUF le standard de fait du déploiement local, utilisé par llama.cpp, Ollama et LM Studio.

La nomenclature GGUF raconte elle-même sa mécanique. Le chiffre indique les bits moyens par poids ; le suffixe _K désigne les k-quants, qui reposent sur des super-blocs et des échelles doublement quantifiées, avec une allocation de bits sensible aux couches ; les suffixes _S, _M, _L signifient petite, moyenne et grande. Le _M a une propriété cruciale : il conserve sélectivement certaines couches sensibles — attention, sortie — en précision plus élevée, tout en compressant plus agressivement le reste. C’est là toute l’astuce : tous les tenseurs ne se valent pas.

Les quants dits « legacy » (Q4_0, Q4_1, Q8_0) appliquent un schéma uniforme, sans cette finesse. Les i-quants (IQ2, IQ3, IQ4_XS) vont plus loin en s’appuyant sur des treillis et des codebooks, une approche qui permet de descendre très bas en bits en puisant dans un dictionnaire de vecteurs représentatifs plutôt qu’en quantifiant indépendamment chaque bloc. Le prix à payer : une dépendance forte à la qualité de l’imatrix (matrice d’importance) utilisée lors de la quantification, faute de quoi le résultat peut être catastrophique.

Q4_K_M, Q5_K_M, Q6_K, Q8_0 : la carte d’identité chiffrée de chaque niveau

Passons aux chiffres. Les mesures les plus citées pour Llama-3.1-8B, avec une référence FP16 à une perplexité d’environ 7,32, donnent le tableau suivant. Attention : ces valeurs proviennent d’une source tierce qui cite une évaluation « évaluée par les pairs » non nommée — nous les rapportons comme ordre de grandeur, pas comme vérité gravée.

Ce qu’il faut lire dans ce tableau, c’est d’abord la petitesse des écarts : entre FP16 et Q4_K_M, la perplexité passe de 7,32 à 7,56, soit moins d’un demi-point. Voilà pourquoi le Q4_K_M est présenté comme « le point optimal en pratique ». Mais deux réserves majeures s’imposent.

Première réserve méthodologique : les guides 2026 que l’on croise volontiers (LocalClaw, PromptQuorum, Pristren, CanItRun) ne publient pas tous les mêmes protocoles. La perplexité dépend du jeu de données d’évaluation, de la taille de l’échantillon, de la version de llama.cpp et de la graine. Comparer un 7,56 d’une source à un 7,40 d’une autre n’a de sens que si les protocoles sont alignés — ce qui est rarement documenté.

Seconde réserve, plus importante : la perplexité globale n’est pas un benchmark de tâche. On ne dispose pas, dans la matière disponible, de mesures systématiques de MMLU, HumanEval ou GSM8K par niveau de quantification. Autrement dit, personne ne peut affirmer sérieusement, chiffres en main, que « le Q4_K_M perd 3 % sur le raisonnement ». La perplexité mesure la capacité à prédire le token suivant sur un corpus ; elle ne dit rien de la robustesse d’une chaîne de pensée à dix étapes. C’est précisément là que le bât blesse.

Là où le Q4 craque vraiment : raisonnement multi-étapes, code et langues non anglaises

La dégradation n’est pas uniforme. Les retours convergent sur un point : la quantification frappe plus durement le code et les mathématiques que la conversation. Une discussion banale tolère une approximation de poids ; une fonction qui doit compiler, un calcul qui doit tomber juste, beaucoup moins. Un poids arrondi de travers peut transformer une condition limite correcte en bug silencieux — le pire des scénarios, car il ne plante pas, il produit simplement du code faux qui passe la relecture rapide.

Le raisonnement multi-étapes est le second point de rupture. Une chaîne de pensée est une suite de décisions où chaque token conditionne les suivants. Une légère dérive à l’étape 2 se propage et s’amplifie jusqu’à l’étape 7. Sur une tâche de conversation, cette dérive est invisible ; sur un problème de maths à plusieurs étapes, elle aboutit à un résultat erroné. C’est pourquoi un Q4_K_M peut sembler parfait en chat et décevant dès qu’on lui demande de raisonner.

Les langues non anglaises constituent le troisième angle mort. Le tokenizer et les embeddings, souvent entraînés majoritairement sur de l’anglais, sont des zones sensibles. Or les couches basses — celles qui traitent les représentations lexicales — sont précisément celles que la quantification compresse parfois le plus agressivement. Résultat : un modèle qui répond brillamment en anglais peut produire un français plus plat, avec des tournures qui glissent, des accords qui sautent, une terminologie technique mal rendue. La perplexité globale, mesurée sur un corpus majoritairement anglophone, ne capte pas cette perte.

Concrètement, on observe des cas où un Q4_K_M échoue là où un Q5_K_M réussit : une fonction de tri avec gestion des cas limites, une démonstration mathématique à plusieurs étapes, une traduction technique où le terme exact compte. Le surcoût d’un cran de quantification (Q4 → Q5) est modeste en mémoire ; le gain en fiabilité, sur ces tâches, ne l’est pas.

Le piège du « Q4 par défaut » pour les MoE et les contextes longs

Voici où le calcul change radicalement en 2026 : les architectures à mélange d’experts. Dans un MoE, seuls quelques experts sont activés par token, mais tous les experts doivent être chargés en mémoire. La quantification des experts, moins sollicités individuellement, peut sembler un bon terrain de compression. En pratique, la sensibilité accrue des couches d’attention et la dérive possible du routage — le mécanisme qui choisit quel expert activer — rendent les MoE plus fragiles face à un Q4 agressif. Un expert mal quantifié qui se retrouve sélectionné produit une sortie dégradée que le routeur ne « voit » pas.

Les contextes longs ajoutent une couche de complexité. À mesure que la fenêtre s’étend, le KV cache — la mémoire des clés et valeurs d’attention pour tous les tokens déjà traités — grossit. Et c’est là que se joue un piège classique : on descend les poids en Q4 pour économiser de la VRAM, puis on se retrouve avec un KV cache non quantifié qui mange le budget restant. Le gain apparent sur les poids est annulé par le coût du cache. La taille réelle en VRAM n’est donc jamais la taille du fichier : c’est fichier + KV cache + activations + overhead du runtime. Un modèle « 4,58 Gio » sur le disque peut occuper bien davantage une fois chargé avec un long contexte.

Le KV cache, ce faux ami qui mange votre budget mémoire

Le KV cache mérite qu’on s’y arrête, car il est systématiquement sous-estimé dans les calculs de budget. À contexte court, il est négligeable. À contexte long — plusieurs dizaines de milliers de tokens —, il devient une part croissante de la VRAM. Sa quantification, via des types comme q8_0 ou q4_0, permet de le comprimer, mais introduit sa propre dégradation.

La question stratégique devient alors : vaut-il mieux descendre les poids en Q4 ou garder des poids en Q5/Q6 et quantifier le KV cache en q8_0 ? La réponse dépend de l’usage. Pour un contexte long avec des poids déjà comprimés, passer le KV cache en q8_0 est souvent un meilleur arbitrage que de sacrifier un cran de poids : on préserve la qualité des représentations tout en récupérant de la mémoire sur le cache. À l’inverse, pour des conversations courtes, le KV cache pèse peu et le choix du quant de poids redevient le levier principal.

Le point crucial : le choix du quant de poids et celui du KV cache interagissent. Optimiser l’un sans regarder l’autre revient à remplir un seau percé. Et mesurer l’impact réel sur la qualité de génération exige de tester sur ses propres tâches, pas de se fier à la perplexité.

Q5 ou Q6 : à quelles conditions le surcoût en RAM vaut vraiment le coup

Voici une grille de décision concrète, à adapter à votre matériel et à vos usages.

Le Q5_K_M apparaît comme le sweet spot dès que la VRAM le permet — c’est d’ailleurs la recommandation qui émerge de plusieurs guides. Le Q6_K se justifie quand la qualité prime et que le budget mémoire suit. Le Q8_0, en revanche, est souvent un gaspillage : doubler la taille pour gagner quelques pour cent de qualité n’a de sens que dans des cas très spécifiques. Et le Q4_K_M reste excellent pour ce pour quoi il a été pensé : du chat, du contexte court, du matériel contraint.

i-quants, imatrix et fichiers anonymes : le Far West de la qualité cachée

Un problème rarement mentionné : le nom du fichier ne dit jamais si une imatrix a été utilisée lors de la quantification. Or l’imatrix est indispensable en dessous de 4 bits, et bénéfique au-dessus. Un IQ4_XS quantifié avec une bonne imatrix peut surpasser un Q4_K_M bâclé ; le même IQ4_XS sans imatrix peut être une catastrophe. Comme le nom du fichier ne l’indique pas, l’utilisateur télécharge à l’aveugle.

Les i-quants (IQ2, IQ3, IQ4_XS) sont prometteurs — ils permettent de faire tenir de gros modèles dans peu de mémoire — mais risqués sans vérification. Les bons réflexes : consulter la provenance du GGUF sur Hugging Face, lire la carte du modèle, vérifier qui a quantifié et avec quelle méthode, préférer les quantifieurs reconnus. Éviter les fichiers anonymes dont on ne connaît ni l’imatrix ni le protocole.

GGUF face à GPTQ, AWQ, EXL2 et MLX : quand le format universel n’est plus le bon choix

GGUF n’est pas seul au monde. GPTQ, AWQ, EXL2/EXL3, bitsandbytes NF4, la quantification native de MLX sur Apple Silicon et TensorRT-LLM côté NVIDIA occupent chacun un créneau. GGUF reste imbattable pour la portabilité : CPU, GPU, Mac, un seul fichier, un écosystème mature (llama.cpp, Ollama, LM Studio), et une intégration qui s’étend — Windows ML a ajouté en octobre 2026 un support expérimental de llama.cpp pour les modèles GGUF, avec une API locale compatible OpenAI.

Mais sur GPU dédié, quand le débit maximal et une quantification fine comptent, EXL2/EXL3, AWQ ou MLX reprennent l’avantage. Sur Apple Silicon, MLX exploite nativement la mémoire unifiée. Sur NVIDIA, TensorRT-LLM optimise au plus près du matériel. Le format universel n’est donc plus toujours le bon choix : il l’est quand la portabilité prime, moins quand la performance pure est l’objectif.

Sources

• GGUF Quantization Guide: Q4, Q5, Q8 Explained | LocalClaw
• Q4 vs Q5 vs Q8: Best LLM Quantization for Speed, RAM & Quality (2026) — PromptQuorum
• Moteurs d’inférence et runtimes locaux : comparatif 2026 — PromptQuorum
• Windows ML: 2026 Updates for GGUF Models and Local AI — Techgenyz
• AI Development on Windows: from PyTorch and llama.cpp to Windows ML — Microsoft Foundry Blog
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API
• Décodage spéculatif : quand un petit modèle accélère votre LLM — lecompute.fr
• Faire tourner une IA en local en 2026 : guide complet — Brief IA

Article recherché et rédigé automatiquement · Magazine Electrosens