Un modèle 7B en fp16 pèse 14 Go de VRAM. Avec une quantization int4 bien calibrée, il descend à 4 Go — et tourne sur une RTX 3060 à 200 €, voire sur CPU. C'est ça, la quantization de LLM : comprimer les poids du modèle en réduisant leur précision numérique pour économiser de la mémoire et accélérer l'inférence, avec une perte de qualité maîtrisée selon le niveau de compression choisi.
Ce guide couvre les trois formats/méthodes qui comptent en 2026 — GGUF (llama.cpp, Ollama), GPTQ et AWQ — avec un tableau précision/VRAM/qualité, les outils concrets pour se lancer, et les situations où il ne faut surtout pas trop quantifier. On parle ici de compression de modèle, pas de serveur d'inférence : pour les architectures de serving en production, voir notre article sur les serveurs d'inférence LLM open source.
Ce que la quantization fait vraiment aux poids d'un modèle
Un LLM est fondamentalement un immense tableau de nombres : ses poids, ou paramètres. En entraînement, ces nombres sont stockés en fp32 (32 bits, virgule flottante). À l'inférence, la plupart des modèles modernes utilisent fp16 ou bf16 (16 bits), ce qui divise déjà par deux l'empreinte mémoire.
La quantization va plus loin. Elle convertit ces poids flottants en entiers de précision réduite :
- int8 : 8 bits par poids. Quasi sans perte. Un 7B passe de 14 Go à ~7 Go.
- int4 : 4 bits par poids. Légère dégradation. Un 7B descend à ~4 Go.
- int3 / int2 : dégradation visible, souvent rédhibitoire sur les tâches précises.
L'idée intuitive : au lieu de stocker 3,14159265… avec 16 bits de précision, on stocke "3" sur 4 bits. On gagne en mémoire, on perd en finesse. La vraie question est : cette perte de finesse est-elle perceptible sur votre cas d'usage ?
Soyons honnêtes : en int8, la réponse est presque toujours non. En int4 avec une bonne méthode de calibration, c'est acceptable sur la grande majorité des tâches de génération. En Q2, ça commence à déraper.
Tableau de référence : précision, VRAM et qualité
Voici les chiffres qui comptent pour un modèle 7B de référence (Mistral 7B, Llama 3 8B) selon le niveau de quantization. Les tailles VRAM sont des approximations — elles varient légèrement selon le modèle exact et la méthode de quantization :
| Précision | VRAM (7B) | VRAM (13B) | Perte qualité | Cas d'usage |
|---|---|---|---|---|
| fp16 / bf16 | ~14 Go | ~26 Go | Référence (0) | GPU A100/H100, RTX 4090 |
| int8 | ~7 Go | ~13 Go | Quasi nulle (<1%) | RTX 3080 10 Go, RTX 4070 |
| Q4_K_M (int4) | ~4,5 Go | ~7,5 Go | Faible (1-3%) | RTX 3060 8 Go, RTX 4060 |
| Q3_K_M | ~3,5 Go | ~6 Go | Modérée | GPU 6-8 Go, CPU hybride |
| Q2_K | ~2,5 Go | ~4,5 Go | Significative | CPU only, tests rapides |
Le niveau Q4_K_M est devenu le standard de facto pour une utilisation en local : il donne le meilleur rapport taille/qualité. Le suffixe "K_M" dans la nomenclature GGUF indique une méthode de quantization mixte (certaines couches critiques gardent plus de bits), plus précise qu'un Q4 naïf uniforme.
GGUF, GPTQ, AWQ : quelles différences concrètes ?
Trois méthodes dominent le paysage en 2026. Elles répondent à des besoins légèrement différents :
GGUF et llama.cpp : la quantization pour le CPU (et l'hybride CPU/GPU)
GGUF est le format natif de llama.cpp, le projet qui a démocratisé l'inférence locale de LLM. Son atout principal : faire tourner un modèle quantifié sur CPU, avec possibilité de décharger certaines couches sur GPU si disponible (offloading de couches). Un modèle 7B en Q4_K_M tourne à 3-5 tokens/seconde sur un CPU moderne — trop lent pour un chatbot interactif, mais suffisant pour de la génération batch ou des tests.
Ollama, LM Studio et Jan.ai s'appuient tous sur llama.cpp. Ils gèrent la quantization de façon transparente via des tags de modèle (ex. ollama pull mistral:7b-instruct-q4_K_M). Pour une équipe qui veut faire tourner un LLM en local sans GPU dédié, c'est l'entrée la plus simple.
La librairie llama.cpp dispose d'un outil intégré (llama-quantize) pour convertir un modèle HuggingFace en GGUF à n'importe quel niveau de quantization — de Q8_0 jusqu'à Q2_K. La documentation officielle de llama.cpp liste tous les niveaux disponibles avec leur taille et leur score de perplexité.
GPTQ : la quantization GPU par calibration
GPTQ (Generalized Post-Training Quantization) est une méthode qui calibre la quantization sur un petit dataset représentatif pour minimiser l'erreur de reconstruction des activations. Elle cible les GPU NVIDIA et génère des noyaux CUDA optimisés pour l'inférence.
En pratique : on prend un modèle fp16, on choisit un dataset de calibration (souvent WikiText ou C4), on lance la quantization — quelques minutes à quelques heures selon la taille du modèle. Le résultat est un modèle GPTQ int4 qui s'intègre directement dans les frameworks vLLM et Text Generation Inference (TGI) de HuggingFace pour un serving GPU.
La librairie AutoGPTQ, intégrée à l'écosystème HuggingFace, est l'outil de référence. La documentation HuggingFace sur la quantization GPTQ couvre l'intégration complète.
AWQ : GPTQ plus précis, couches critiques protégées
AWQ (Activation-Aware Weight Quantization) affine l'approche GPTQ en identifiant les poids les plus "saillants" — ceux dont la variation impacte le plus les activations du modèle — et en les protégeant lors de la quantization (ils gardent plus de bits). Résultat : à niveau de compression égal, AWQ préserve mieux la qualité que GPTQ, en particulier sur les petits modèles (7B et moins).
AutoAWQ est la librairie de référence. Elle s'intègre également avec vLLM pour un serving GPU optimisé. Sur un Mistral 7B ou un Llama 3 8B, le delta de qualité entre GPTQ et AWQ est faible mais mesurable sur des benchmarks de raisonnement et de code.
bitsandbytes NF4 : quantization à la volée pour le prototypage
Un quatrième outil mérite d'être mentionné : bitsandbytes de HuggingFace, avec son format NF4 (Normal Float 4). Il quantifie le modèle directement au chargement, en mémoire, sans pré-générer un fichier quantifié. C'est le mode utilisé par QLoRA pour le fine-tuning efficace en mémoire réduite.
Pour l'inférence en production, bitsandbytes NF4 est moins rapide que GPTQ ou AWQ (pas de noyaux CUDA aussi optimisés). En revanche, pour tester rapidement un gros modèle sur une machine avec peu de VRAM, c'est le moyen le plus simple : une seule ligne de config dans BitsAndBytesConfig et le modèle se charge en 4 bits.
Combien on gagne vraiment : exemples concrets par taille de modèle
Un tableau vaut mieux qu'un long discours. Voici les gains VRAM réels selon la taille du modèle et la méthode, avec le matériel minimum associé :
| Modèle | fp16 | int8 | int4 (Q4_K_M) | GPU accessible en int4 |
|---|---|---|---|---|
| Mistral 7B | 14 Go | 7 Go | 4,5 Go | RTX 3060 8 Go, RTX 4060 |
| Llama 3 8B | 16 Go | 8 Go | 5 Go | RTX 3060 8 Go, RTX 4060 |
| Mistral / Llama 13B | 26 Go | 13 Go | 7,5 Go | RTX 3080 10 Go, RTX 4070 |
| Llama 3 70B | 140 Go | 70 Go | 40 Go | 2× A100 40 Go, ou CPU (lent) |
| Mistral / Qwen 0.5-3B (SLM) | 3-6 Go | 1,5-3 Go | ~1-2 Go | N'importe quel GPU, ou CPU |
Ce dernier cas — les petits modèles de langage (SLM) — est particulièrement intéressant en combinaison avec la quantization : un Qwen 1.5B ou un Phi-3 Mini en Q4 tient dans 1 Go de RAM, assez pour du déploiement on-device ou edge.
La perte de qualité réelle selon le niveau : ce que disent les benchmarks
Soyons précis, parce que "légère perte" est vague. Voici ce que donnent les mesures de perplexité et les benchmarks pratiques sur Mistral 7B :
int8 : quasi indolore
La quantization int8 — via bitsandbytes LLM.int8() ou GPTQ 8 bits — introduit une augmentation de perplexité de l'ordre de 0,1 à 0,3 points sur WikiText-2. En pratique, impossible à distinguer à l'usage. C'est le niveau recommandé quand on a les contraintes de VRAM mais qu'on ne veut prendre aucun risque sur la qualité.
int4 bien calibré (Q4_K_M, AWQ, GPTQ) : acceptable
En Q4 avec une bonne calibration, la perte de perplexité monte à 1 à 3 points. Sur des tâches de génération de texte, de résumé ou de Q&A sur documents, c'est imperceptible pour un utilisateur humain. Sur des tâches qui exigent de la précision numérique ou du raisonnement multi-étapes, on peut observer une légère régression — à valider sur votre benchmark métier avant de déployer.
Le choix entre Q4_K_M (GGUF) et AWQ dépend du contexte : GGUF si vous ciblez du CPU ou de l'offloading hybride, AWQ si vous avez un GPU NVIDIA et utilisez vLLM pour le serving.
int3 et int2 : attention
En dessous de int4, les choses se dégradent notablement. Q2_K sur llama.cpp peut faire baisser les benchmarks de raisonnement de 10 à 20 %. On commence à voir des hallucinations accrues et des incohérences dans les longues générations. À réserver aux cas extrêmes où la VRAM est vraiment la contrainte absolue — ou aux tests rapides pour vérifier qu'un modèle tourne bien avant de quantifier à un niveau plus raisonnable.
Les pièges à éviter avec la quantization
On voit régulièrement les mêmes erreurs sur des projets où la quantization a été mal appliquée.
Quantifier avant de fine-tuner
C'est le piège classique. Si vous prévoyez de faire du fine-tuning, gardez le modèle en fp16 (ou bf16) pendant l'entraînement. QLoRA quantifie le modèle de base pendant le fine-tuning pour économiser la VRAM — c'est une quantization de confort d'entraînement, pas un artefact final. Quantifier après fine-tuning, pas avant.
Supposer que Q4 suffit sans valider sur votre cas d'usage
Q4_K_M est souvent un excellent défaut. Mais "souvent" n'est pas "toujours". Sur de l'extraction structurée de données juridiques ou de la génération de code Python complexe, la perte en Q4 peut être tangible. Mesurez toujours sur votre propre benchmark — 50 à 100 exemples représentatifs suffisent pour détecter une régression.
Choisir GGUF pour un GPU NVIDIA dédié
GGUF brille sur CPU et sur les déploiements locaux avec Ollama. Mais pour un serving GPU avec vLLM ou TGI, GPTQ ou AWQ donnent de meilleures performances à l'inférence : les noyaux CUDA sont plus optimisés pour l'inférence batch que les noyaux llama.cpp. Utilisez le bon outil pour le bon contexte.
Négliger les couches d'embedding et de sortie
Certains outils de quantization quantifient aussi les couches d'embedding et la tête de langage finale. Ces couches sont particulièrement sensibles à la perte de précision. Les bonnes implémentations (Q4_K_M, AWQ) les maintiennent en fp16. À vérifier dans vos configs avant de lancer.
Quand ne pas quantifier (ou quantifier moins)
La quantization est un outil, pas une fin en soi. Il y a des situations où elle n'a pas lieu d'être, ou où il faut s'arrêter à int8 :
- Vous avez assez de VRAM en fp16. Inutile de dégrader la qualité. Si vous avez un A100 40 Go pour un modèle 7B, gardez-le en fp16.
- Votre tâche est très sensible à la précision. Raisonnement mathématique, génération de code complexe, extraction fine sur documents critiques : restez en int8 au minimum, testez Q4 soigneusement avant de décider.
- Vous opérez en production à fort débit batch. Sur un cluster GPU homogène, les noyaux CUDA fp16 peuvent être plus rapides que de l'int4 pour de l'inférence batch massive — à mesurer, pas à supposer.
- Vous allez fine-tuner ensuite. Quantifiez après, pas avant.
Pour un accompagnement sur le choix d'architecture d'inférence et de modèle adapté à votre usage, notre équipe d'expert IA générative et LLM peut cadrer rapidement les contraintes matérielles et les compromis pertinents.
Pour aller plus loin
- Top serveurs d'inférence LLM open source : vLLM, TGI, Triton — comment choisir son stack de serving GPU une fois le modèle quantifié.
- Déployer un LLM en production : infrastructure, coûts, monitoring — le guide complet pour passer du modèle quantifié à un service stable.
- Coût de migration Mistral on-premise : TCO réel d'un déploiement GPU privé, où la quantization peut diviser par deux les coûts matériels.
- SLM pour l'entreprise : petits modèles + quantization, la combinaison gagnante pour les déploiements contraints en ressources.
- Top modèles LLM open source pour l'entreprise : Mistral, Llama, Qwen — lequel choisir comme base avant de quantifier.
- SLM on-device et edge IA embarquée : quantization int4 + SLM pour des déploiements sans cloud, sur matériel embarqué.
- Documentation quantization llama.cpp : tous les niveaux GGUF avec perplexité mesurée et taille réelle — la référence technique.
- Guide quantization HuggingFace Transformers : comparatif GPTQ, AWQ, bitsandbytes NF4 avec exemples de code prêts à l'emploi.
Vous hésitez encore ?
Votre contrainte matérielle mérite une réponse précise. 30 minutes pour identifier le bon niveau de quantization pour votre cas d'usage.
En résumé : quantizer oui, mais avec méthode
La quantization n'est pas un tour de passe-passe : c'est un compromis engineering entre mémoire, vitesse et qualité. Int8 est quasi gratuit. Int4 bien calibré (Q4_K_M, AWQ) est acceptable sur la plupart des tâches. En dessous, ça dégrade et il faut valider sérieusement avant de déployer.
Pour le choix du format : GGUF si votre contrainte est le CPU ou un déploiement local avec Ollama ; GPTQ ou AWQ si vous avez un GPU NVIDIA et visez un serving en production avec vLLM. Bitsandbytes NF4 pour le prototypage rapide ou le fine-tuning QLoRA, pas pour la production.
Et quand la quantization ne suffit plus — parce que même en Q4 le modèle 7B est trop lent ou trop gros pour votre matériel — la piste suivante est de descendre en taille de modèle, pas de descendre à Q2. Un bon SLM bien choisi battra toujours un 7B mal quantifié.
