La quantification sans mythes : ce que vous gagnez, ce que vous perdez, ce qu'il faut mesurer

Ce que fait la quantification, avec un exemple chiffré

Un modèle, ce sont des milliards de poids ; en BF16, chacun occupe 16 bits, soit 2 octets. Quantifier, c'est stocker chaque poids sur moins de bits (sur 4 bits, l'une de 16 valeurs possibles) avec une échelle partagée par chaque petit bloc de poids. Les formats diffèrent par les blocs, les échelles et les couches qui gardent plus de bits.

mémoire des poids (Go) ≈ paramètres (milliards) × bits par poids ÷ 8
 8B en BF16 :     8 × 16 ÷ 8  = 16 Go
 8B en Q4_K_M :   8 × 4,9 ÷ 8 ≈ 4,9 Go
70B en Q4_K_M :  70 × 4,9 ÷ 8 ≈ 43 Go

C'est cohérent avec llama.cpp : Q4_K_M fait en moyenne 4,89 bits par poids et Llama 3.1 70B arrive à 43,1 Go. Avec un seul utilisateur, la lecture des poids en mémoire est le goulot d'étranglement, donc la vitesse suit la taille : de 29 à 72 tokens par seconde entre F16 et Q4_K_M. Restent le cache KV et la qualité.

La carte des formats : qu'est-ce qui tourne où

Votre moteur et votre matériel choisissent le format avant tout classement.

Les noms sont des recettes : Q4_K_M est un mélange « medium » en 4 bits qui donne 6 bits à certains tenseurs sensibles, et les i-quants avec matrice d'importance (imatrix) s'appuient sur un texte de calibration pour savoir où l'arrondi fait le plus de dégâts. Côté GPU, AutoGPTQ et AutoAWQ, archivés, ont cédé la place à GPTQModel et à llm-compressor de vLLM (v7.5.0 et v0.14.0, septembre 2026) ; ExLlamaV3 (v1.5.2) a remplacé ExLlamaV2, mais son serveur, TabbyAPI, se présente comme un projet amateur.

Combien de qualité on perd : ce que disent les mesures

La perplexité dit peu ; l'écart avec l'original et les réponses qui basculent en disent plus.

Les moyennes cachent les dégâts : dans Accuracy is Not All You Need (Microsoft Research, 2024), des schémas qui ne déplaçaient la précision que de 0 à 2 % faisaient basculer jusqu'à 13,6 % des réponses. La taille compte aussi : dans l'étude ACL 2025 Give Me BF16 or Give Me Death?, les poids en 4 bits conservaient 99,5 % du score d'un modèle de raisonnement de 32B, mais 93,5 % pour un 1,5B.

Pour nous, la langue pèse le plus. L'étude de Cohere sur les modèles multilingues quantifiés (Findings of EMNLP 2024) montre que, pour un modèle de 103B en 4 bits, les métriques automatiques indiquaient une baisse de 0,3 % en français, et les évaluateurs humains de 16,6 %.

Sous 4 bits, la courbe se casse, et Unsloth déconseille le 1 bit pour les agents : ils bouclent et cassent les appels d'outils. À mémoire égale, un modèle plus grand en 4 ou 5 bits l'emporte en général : dans les tests d'Unsloth, Gemma 3 27B en Q4_K_M (15,4 Go) obtient 71,2 % sur MMLU, contre 67,2 % pour Gemma 3 12B en BF16 (environ 24 Go).

FP8, FP4 et les modèles livrés déjà quantifiés

Sur les GPU récents, le format est gravé dans le silicium, et de plus en plus de modèles sont entraînés pour lui.

Le FP8 est le choix sûr sur serveur : la même étude ACL 2025 (plus de 500 000 évaluations sur Llama 3.1) le juge pratiquement sans perte à toutes les tailles, l'INT8 perdant de 1 à 3 %. vLLM annonce deux fois moins de mémoire et jusqu'à 1,6 fois plus de débit, mais le calcul en FP8 exige Ada, Hopper ou Blackwell ; une A100 n'exécute les checkpoints FP8 que comme des poids 8 bits.

MXFP4 et NVFP4 sont des formats à virgule flottante sur 4 bits : MXFP4 partage une échelle en puissance de deux sur 32 valeurs (4,25 bits par poids), le NVFP4 de NVIDIA une échelle FP8 plus fine toutes les 16 (4,5 bits). NVIDIA annonce une dégradation de 1 % ou moins en passant DeepSeek-R1-0528 du FP8 au NVFP4. Seul Blackwell accélère le NVFP4 ; le MXFP4 l'est aussi sur la MI355X d'AMD.

Les versions natives changent les règles. OpenAI a publié gpt-oss (5 août 2025) avec des poids d'experts en MXFP4 : le 120b tient sur un GPU de 80 Go, et les scores publiés sont ceux du modèle quantifié. Kimi K2 Thinking utilise un INT4 natif, DeepSeek-V4 (avril 2026) livre ses experts en FP4, et Gemma 4 en version QAT (entraînée pour la quantification, 5 juin 2026) ramène le 31B de 69,9 Go à 17,5 Go.

Le cache KV : la mémoire que personne ne budgète

Avec un long contexte, la mémoire de travail de la conversation peut peser plus que le modèle.

Chaque token du contexte stocke des clés et des valeurs dans chaque couche d'attention ; la taille se déduit du config.json du modèle :

KV par token = 2 × couches × têtes KV × dimension de tête × octets par valeur
Qwen3-32B, 16 bits : 2 × 64 × 8 × 128 × 2 o = 256 Kio
32 768 tokens ≈ 8 Gio, 131 072 tokens ≈ 32 Gio (par requête)

L'architecture change le résultat : gpt-oss-120b, avec ses couches à fenêtre glissante, n'a besoin que de 36 Kio par token, et Qwen3.8-27B, avec ses couches d'attention linéaire, de 64 Kio. Chaque requête parallèle a son propre cache : la mémoire croît avec les slots parallèles multipliés par le contexte, rappelle Ollama.

Quantifier le cache est le levier suivant : q8_0 ou q4_0 dans Ollama (OLLAMA_KV_CACHE_TYPE) et llama-server (--cache-type-k, --cache-type-v), FP8 dans vLLM (--kv-cache-dtype). Une étude COLM 2025 trouve un cache 4 bits sans perte sur des modèles de 14B et 32B, mais un cache 3 bits qui coûte plus de 5 % sur ceux de 1,5B et 7B, et recommande 8 bits ; Unsloth a constaté une dégradation en 4 bits.

Quel format pour quel matériel

Nos points de départ en septembre 2026 ; votre propre évaluation tranche.

Les lignes serveur suivent l'étude ACL 2025 : 4 bits est rentable quand peu d'utilisateurs attendent, 8 bits l'emporte avec le batching continu. Sur Mac et DGX Spark, la bande passante commande : les modèles à mélange d'experts (MoE) avec peu de paramètres actifs y tournent bien plus vite. Voir aussi le matériel pour l'IA locale en 2026 et du portable au serveur.

Comment valider une quantification sur vos propres tâches

Une demi-journée de tests évite des semaines de défaillances silencieuses.

1. Figez un jeu d'évaluation tiré du travail réel, avec réponses attendues. Chez Slash, nous utilisons 30 prompts fixes par client en espagnol, en anglais et en français (méthode dans notre guide des évaluations de LLM).
2. Fixez une référence : le même modèle en BF16 ou FP8, ou la version native, en décodage glouton.
3. Mesurez la KLD et les réponses qui basculent sur vos textes, par tâche et par langue, pas sur le texte de calibration : Unsloth prévient que cela surestime la qualité.
4. Relisez l'espagnol et le français à la main : accents, accords, registre (tú ou usted, vous), glissements vers l'anglais.
5. Testez les appels d'outils et le JSON avec le template de chat de production, en validant chaque sortie contre son schéma.
6. Testez le contexte long avec le cache KV de production, et consignez hash, type de quantification, version du moteur et template pour tout relancer au moindre changement.

Cinq erreurs fréquentes

• Le mauvais template de chat. Un GGUF embarque son propre template Jinja, appliqué par défaut dans llama-server. S'il ne correspond pas au format d'entraînement, les réponses se dégradent sans erreur visible et les appels d'outils lâchent en premier. Un template peut aussi cacher des instructions (Pillar Security, 2025) : relisez-le comme du code.
• Trop quantifier les petits modèles. IQ1_S fait passer la perplexité de Llama 3 8B de 6,2 à 60,7. Sous 8B, restez à 4 bits ou plus.
• Oublier le contexte par défaut. D'après Ollama, il utilise 4K tokens sous 24 Gio de VRAM : un long document ne tient pas sans l'augmenter.
• Requantifier ce qui l'est déjà : des poids natifs MXFP4 ou INT4, ou un GGUF construit à partir d'un checkpoint quantifié plutôt que du BF16. Et gardez le projecteur de vision (mmproj) en BF16 ou Q8, comme le conseille llama.cpp.
• Se fier au chiffre d'un autre. Une perplexité mesurée sur un autre texte avec un autre moteur dit peu de chose de votre cas. Pour choisir d'abord le modèle, voir les modèles open-weight en 2026.