Magazine LLM Opensource · 1 November 2026

Quantization en 2026 : ce que les formats 4-bit et 2-bit font vraiment à vos modèles open weight

Les modèles ouverts sont devenus obèses : 816 milliards de paramètres pour Muse Spark Open, 78 milliards pour Kolibri-1, des fenêtres de contexte à un million de tokens. Le matériel, lui, n’a pas suivi. La quantization est devenue le seul pont entre les deux — et un champ de bataille où le marketing des formats 4-bit natifs masque une réalité plus nuancée. Voici ce qu’on sait vraiment, et ce qu’on ne sait pas.

Le mur de mémoire, et pourquoi il change tout

Il y a un an, la quantization était un sujet d’ingénieur pour faire tourner un 7B sur une RTX consumer. En octobre 2026, c’est un sujet d’infrastructure. Le 16 octobre, le site the-agent-report.com titrait sur « la vague open-weight qui se heurte désormais à un mur de mémoire » : 816B, 560B, 120B de paramètres publiés en une seule journée. Le même jour, Meta dévoilait Muse Spark Open, un MoE de 816 milliards de paramètres totaux pour 42 milliards actifs, avec un contexte d’un million de tokens. Trois jours plus tôt, Aleph Alpha publiait Kolibri-1, 78,1 milliards de paramètres totaux, 3,46 milliards actifs, contexte maximal de 1 048 576 tokens et fenêtre recommandée en production autour de 262 144 tokens.

Faites le calcul. Un 816B en BF16, c’est de l’ordre de 1,6 téraoctet de poids. Même un 78B en BF16 pèse environ 156 Go — plus que n’importe quel accélérateur unique grand public, et à la limite des H100/H200 en configuration multi-utilisateurs. La quantization n’est plus une optimisation : c’est la condition d’existence de ces modèles hors des datacenters hyperscale.

Et le problème s’est déplacé. Là où la question était « 4-bit ou 8-bit ? », elle est devenue « quel 4-bit, sur quel matériel, avec quelle perte sur quelle tâche ? ». Parce que les formats ne se valent pas, et parce que les benchmarks qui prétendent les départager sont, dans leur grande majorité, méthodologiquement fragiles.

Panorama : qui fait quoi, sur quoi ça tourne

Commençons par la cartographie. Les sources disponibles pour ce dossier — un blog de conseil (ayinedjimi-consultants.fr), un cours technique (aiengineeringfromscratch.com), des guides pratiques — convergent sur une taxonomie de fait, qu’on peut résumer ainsi.

Deux remarques sur ce tableau. D’abord, il faut distinguer ce qui est maintenu activement de ce qui est supporté passivement. Le roadmap « Quantization 2026 H2 » du dépôt SGLang (mis à jour le 29 juillet 2026) liste un support étendu pour AWQ, GPTQ, GGUF, Compressed-Tensors, ModelSlim, Quark, ModelOpt et AutoRound, avec une architecture cible Config→Method→Scheme→Kernel. C’est le signe d’une industrialisation : on ne bricole plus des kernels, on normalise une pile. Une RFC MXFP8/MXFP4 pour l’Ascend A5 est ouverte, et une roadmap FP4 pour le KV cache existe également.

Ensuite, il faut être honnête sur les lacunes de la documentation publique. Les formats EXL2/EXL3, bitsandbytes NF4, MLX d’Apple et les approches BitNet/ternaire ne sont quasiment pas couverts par les sources techniques accessibles. On sait qu’ils existent, on sait à quoi ils servent, mais les données de dégradation publiées sont rares. C’est un angle mort à signaler plutôt qu’à masquer.

La mécanique : ce qui se passe vraiment quand on passe en 4-bit

Pour comprendre pourquoi deux formats à 4 bits peuvent produire des résultats très différents, il faut regarder sous le capot. Trois axes structurent toutes les méthodes.

PTQ contre QAT. La quantization post-entraînement (PTQ) prend un modèle déjà entraîné et compresse ses poids, sans jamais retoucher les gradients. C’est la voie dominante en 2026 parce qu’elle est rapide et bon marché : AWQ, par exemple, ne nécessite pas de rétro-propagation, avec une calibration en quelques minutes contre plusieurs heures pour GPTQ. La quantization-aware training (QAT) intègre la contrainte de quantification pendant l’entraînement — c’est ce que fait BitNet, et c’est ce qui explique sa robustesse à très basse précision. Mais QAT exige de réentraîner, donc de disposer du compute et des données. Pour la quasi-totalité des praticiens qui récupèrent un modèle sur Hugging Face, la question ne se pose même pas : ce sera du PTQ.

La granularité. C’est le paramètre le plus déterminant et le moins discuté. Une échelle (scale) et un zero-point peuvent être calculés par tenseur entier (per-tensor), par canal de sortie (per-channel), ou par groupes de N poids (group-wise, typiquement 128). Plus la granularité est fine, plus on préserve de dynamique locale — mais plus on paie en métadonnées et en complexité de kernel. Un 4-bit group-wise à 128 n’occupe pas le même espace mémoire effectif qu’un 4-bit per-tensor, et ne se dégrade pas de la même façon. C’est là que se joue une grande partie de l’écart entre AWQ et GPTQ d’un côté, et les formats natifs de l’autre.

Ce qu’on quantifie. Les poids, mais aussi — et c’est souvent oublié — les activations et le KV cache. Une quantification W4A16 (poids 4 bits, activations 16 bits) ne pose pas les mêmes problèmes qu’une W4A4 ou W8A8. Les activations ont des distributions à longue queue, avec des valeurs aberrantes qui font exploser l’erreur si on les quantifie naïvement. Les techniques d’importance-aware — dont AWQ est l’illustration canonique — préservent environ 1 % des canaux d’activation saillants et limitent la perte de perplexité à moins de 0,5 % en typique. GPTQ, de son côté, minimise l’erreur de reconstruction couche par couche via une approximation du second ordre. Deux philosophies différentes pour le même objectif.

Le KV cache mérite un paragraphe à part. Avec des contextes d’un million de tokens, le cache devient un poste de coût majeur — parfois comparable aux poids eux-mêmes. Les sources convergent sur un ordre de grandeur : pour un Llama 3.1 70B en INT4 tenant sur un H100 80 Go, il reste 20 à 30 Go pour le KV cache à 128 séquences et 2k de contexte. Sur un contexte long, ce budget explose. D’où l’intérêt des roadmaps FP4 KV cache chez SGLang, et des guides 2026 sur la quantification du KV cache avec PagedAttention. Mais là encore : peu de chiffres publics sur la dégradation réelle d’un KV cache 4-bit sur du raisonnement long.

Enfin, les IQ-quants de GGUF (importance matrix) méritent d’être cités : ils utilisent une matrice d’importance calculée sur un corpus de calibration pour décider quels poids peuvent être écrasés sans dommage. C’est ce qui permet à un Q2_K de rester « utilisable » là où un 2-bit naïf serait catastrophique. Mais « utilisable » n’est pas « équivalent ».

Les chiffres qu’on a, et ceux qu’on n’a pas

C’est ici qu’il faut être très clair : il n’existe pas, dans la documentation publique accessible, de table de dégradation indépendante et complète comparant FP4 natif, MXFP4, NVFP4, AWQ/GPTQ 4-bit et GGUF Q2/IQ2 sur MMLU-Pro, GSM8K, HumanEval, SWE-bench, RULER et le tool-calling multilingue. Les blogs qui prétendent le contraire sont, dans leur immense majorité, des contenus SEO sans protocole de mesure.

Ce qu’on a, ce sont des ordres de grandeur. Pour un modèle 70B : environ 140 Go en FP16, environ 70 Go en INT8 avec une perte de perplexité inférieure à 1 %, environ 35 Go en INT4 (GPTQ/AWQ) avec une perte de perplexité de 1 à 3 %. Un 7B en 4 bits pèse environ 3,5 à 4 Go, ce qui le fait tenir sur un GPU grand public ou un Mac M-series. Ces chiffres sont cohérents entre sources et arithmétiquement triviaux — 70B × 2 octets = 140 Go, × 0,5 = 35 Go. On peut les considérer comme fiables.

Pour les débits, c’est plus fragile. Un tutoriel avance des chiffres sur un 7B : GPTQ à environ 712 tok/s avec kernels Marlin (2,6× le GPTQ non-Marlin), AWQ à environ 741 tok/s avec Marlin-AWQ (10,9× le naïf), GGUF en vLLM à environ 93 tok/s (non optimisé GPU). Ces chiffres ne précisent ni le matériel, ni le batch size, ni la longueur de contexte, ni la version de vLLM. Ils sont invérifiables en l’état. Prenez-les comme des illustrations d’un rapport de grandeur — les kernels Marlin changent effectivement la donne — pas comme des benchmarks.

Quelques affirmations supplémentaires circulent, à prendre avec des pincettes. AWQ serait « la méthode de référence » pour l’INT4 en 2026, avec une accuracy MMLU souvent supérieure de 1 à 2 points à GPTQ. GPTQ-Int4 serait le seul format INT4 supportant les adaptateurs LoRA dans vLLM (multi-LoRA, 10 à 50 variantes fine-tunées), NVFP4 ne supportant pas LoRA « début 2026 ». Ces points proviennent d’une source unique et datée ; ils mériteraient d’être recoupés avec la documentation officielle de vLLM avant d’être pris pour argent comptant.

Ce qui manque, en revanche, est massif : aucune donnée publique sur la dégradation du tool-calling à 4 bits et 2 bits, alors que c’est précisément la charge de travail de 2026. Kolibri-1 affiche 61,4 % sur BFCL v4 en BF16 — combien en AWQ 4-bit ? Personne ne le dit. Aucune donnée sur les langues non-anglaises, alors que Kolibri-1 est explicitement positionné allemand/anglais et que Muse Spark Open est entraîné sur plus de 100 langues. Aucune donnée sur le long contexte à 4 bits, alors que les fenêtres à un million de tokens sont devenues le standard.

Le piège méthodologique des tables de perplexité

La perplexité est le benchmark le plus cité et le moins utile. Elle mesure la capacité du modèle à prédire le token suivant sur un corpus — une métrique lisse, agrégée, insensible aux défaillances catastrophiques localisées. Un modèle peut avoir une perplexité à +0,3 % et rater systématiquement ses appels d’outils, ou produire du code syntaxiquement correct mais logiquement faux.

Les benchmarks académiques ne sont pas beaucoup plus fiables en l’état. MMLU est largement saturé — plusieurs modèles atteignent 100 % sur AIME 2025, ce qui devrait nous alerter sur la valeur discriminante des jeux de test classiques. Les scores rapportés par les auteurs de formats de quantization sont souvent mesurés avec leur propre harnais, sur leurs propres prompts, avec leurs propres seeds. La contamination des benchmarks par les corpus d’entraînement est un problème connu et non résolu.

Pour un praticien, la seule méthodologie défendable est de construire son propre jeu d’évaluation, sur ses propres tâches, avec des critères de succès binaires plutôt que des scores agrégés. Concrètement : un jeu de 50 à 200 prompts représentatifs de votre usage réel (extraction structurée, appels d’outils, génération de code, questions multilingues), un script de notation automatique, et une comparaison entre le modèle de référence en BF16/FP16 et ses variantes quantifiées. Ça prend une journée. Ça évite des semaines de débogage en production.

Les arbitrages concrets : self-hosting contre serving

La grille de décision dépend moins du format que du contexte de déploiement.

Self-hosting local (desktop, edge, un seul utilisateur). GGUF est le choix par défaut, via llama.cpp ou Ollama. Les variantes Q4_K_M et Q5_K_M offrent le meilleur compromis taille/qualité pour la majorité des usages. Les IQ-quants permettent de descendre plus bas à qualité comparable — un IQ3_M sera généralement préférable à un Q3_K_S. En dessous de 3 bits, on entre dans le territoire où la dégradation devient visible sur les tâches de raisonnement, même si elle reste tolérable pour de la génération de texte court. EXL2/EXL3, sur ExLlamaV2, offre un contrôle fin du bits-par-poids et reste populaire chez les utilisateurs de GPU consumer, mais manque de données publiques de dégradation.

Serving GPU datacenter. AWQ et GPTQ dominent, avec des kernels Marlin qui changent l’ordre de grandeur des débits. FP8 reste la référence quand la précision prime — et c’est le format natif de Kolibri-1, publié en BF16 et FP8. Sur Blackwell, MXFP4 et NVFP4 entrent en scène : ils permettent de servir des modèles massifs en multi-utilisateur avec un débit supérieur, au prix d’une perte de qualité encore mal documentée. Muse Spark Open est explicitement proposé en BF16 et NVFP4 sur SageMaker JumpStart — c’est un signal fort de l’adoption industrielle du NVFP4 pour les très gros modèles.

Fine-tuning. bitsandbytes NF4 (QLoRA) reste la voie standard pour adapter un modèle sur un GPU unique. AWQ et GPTQ ne sont pas conçus pour l’entraînement ; les tentatives de QLoRA-AWQ restent expérimentales. Si votre cas d’usage est le fine-tuning, la question de la quantization d’inférence se pose après, pas avant.

Un mot sur les MoE, qui sont devenus la norme. Un MoE à 816B de paramètres totaux pour 42B actifs ne se quantifie pas comme un modèle dense. Les experts peu sollicités peuvent tolérer une quantification plus agressive que les experts très actifs, mais les méthodes de calibration standard ne le savent pas — elles traitent tous les poids de la même façon. Les sources disponibles mentionnent que les MoE très sparses exigent une calibration adaptée, sans détailler comment. C’est un chantier ouvert.

Ce qui vient : poids FP4 natifs, QAT, distillation

Trois tendances de fond redessinent le paysage.

La première est la publication de poids en FP4 natif. Quand un modèle est entraîné ou converti en FP4 dès l’origine, la quantization n’est plus une dégradation post-hoc mais une propriété du modèle. NVFP4 et MXFP4 sont les candidats, et leur support par TensorRT-LLM sur Blackwell en fait une voie crédible pour le serving à grande échelle. Le revers : la portabilité. Un modèle NVFP4 tourne sur Blackwell ; sur Hopper, il faut revenir à FP8 ou AWQ.

La deuxième est la montée en puissance de la QAT. BitNet et ses dérivés ternaires (1,58-bit) démontrent qu’on peut descendre très bas si on accepte de réentraîner. Mais l’écart entre la recherche et la production reste large : peu de modèles open weight majeurs sont publiés en version QAT, et les kernels dédiés sont rares. La vraie question est de savoir si les laboratoires accepteront de payer le coût de la QAT pour des modèles de plusieurs centaines de milliards de paramètres. Rien n’est moins sûr.

La troisième est la distillation vers des modèles plus petits — Muse Glimmer, 30B dense, distillé de Muse Spark, en est l’illustration. Si un 30B distillé atteint 90 % des performances d’un 816B sur vos tâches, la question de la quantization du 816B devient secondaire. C’est peut-être l’arbitrage le plus important de 2026 : ne pas quantifier un géant, mais choisir un plus petit qui n’a pas besoin de l’être.

La grille de décision

En synthèse, pour un praticien en novembre 2026 :

• Desktop, usage personnel : GGUF Q4_K_M ou Q5_K_M. Ne descendez en dessous de Q3 que si vous avez mesuré la dégradation sur vos tâches.
• Serving GPU, un seul modèle, priorité qualité : FP8 si le modèle le supporte, sinon AWQ 4-bit avec kernels Marlin.
• Serving GPU, multi-LoRA : GPTQ-Int4, seul format INT4 à supporter les adaptateurs LoRA dans vLLM à ce jour (à vérifier dans la doc de votre version).
• Blackwell, très gros modèles : NVFP4 ou MXFP4, en acceptant l’absence de données publiques de dégradation — donc en évaluant soi-même.
• Fine-tuning : bitsandbytes NF4 (QLoRA), pas de débat.
• MoE très sparse : calibration sur mesure, et méfiance envers les recettes génériques.

Et une règle qui vaut plus que toutes les autres : ne faites jamais confiance à une table de perplexité pour décider d’un déploiement. Construisez votre propre jeu d’évaluation, sur vos tâches, avec des critères binaires. C’est la seule mesure qui compte, et c’est aussi la seule qui ne soit pas contaminée par le marketing des formats.

Sources

• Deconstructing Mixture-of-Experts (MoE) Routing in Open-Weight Models — 28 octobre 2026
• Meta lance Muse Spark Open : modèle MoE de 816 milliards avec un contexte de 1 million de tokens — 16 octobre 2026
• Meta unveils Muse Spark Open with 1M context, 42B active — 15 octobre 2026
• Introducing Muse Spark Open, The Most Capable US Open-Weight Model to Date — 15 octobre 2026
• 816B, 560B, 120B en un jour : la vague open-weight se heurte désormais à un mur de mémoire — 16 octobre 2026
• Aleph Alpha Kolibri-1 — fiche modèle — 3 octobre 2026
• SGLang — roadmap Quantization 2026 H2 — mise à jour du 29 juillet 2026
• llm-d 1.0 Debuts at PyTorch Conference with Production Inference Stack — 20 octobre 2026
• 「vLLM」「SGLang」がTPUに対応。何が変わる？ — 21 octobre 2026
• Guide de quantification AWQ / GPTQ / GGUF — source tierce
• Cours technique sur la quantization des LLM — source tierce
• Guide pratique de quantification GGUF (Q2/IQ2) — source tierce
• Guide de quantification du KV cache et PagedAttention — source tierce
• Guide Muse Spark Open sur Hugging Face — 16 octobre 2026

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