Faire tourner un grand modèle de langage de plusieurs milliards de paramètres sur sa propre machine ressemble souvent à un parcours du combattant. Au début, j’avais un peu de mal à m’y retrouver parmi tous ces acronymes, mais j’ai vite compris que la quantification est l’outil indispensable pour s’en sortir.
Cette technique de compression consiste à réduire la précision numérique des poids et des activations d’un modèle afin de réduire son empreinte mémoire, d’accélérer l’inférence et de faire baisser les coûts de déploiement. En convertissant des paramètres de haute précision (comme le FP32 ou le BF16) vers des formats plus légers (comme l’INT8, l’INT4 ou le FP4), je peux faire tourner des modèles massifs sur du matériel grand public ou des appareils embarqués.
Ce qu’il faut retenir
- Le format 4-bit est le compromis idéal : il réduit l’empreinte mémoire d’environ 75 % tout en ne perdant que 1 à 2 % de la précision d’origine du modèle.
- Le choix dépend entièrement du matériel : GGUF est le choix incontestable pour le CPU et l’Apple Silicon, AWQ s’impose sur les GPU grand public, et le FP8/NVFP4 domine les centres de données d’entreprise.
- Il faut absolument éviter le 2-bit : en dessous de 3 bits, la perplexité du modèle s’envole, ce qui provoque des hallucinations sévères et une perte de cohérence textuelle.
- La compression des activations (WAQ) cible le haut débit : contrairement à la compression des poids seuls (WOQ), quantifier les activations permet de libérer la puissance brute des cœurs Tensor lors de fortes charges simultanées.
Les deux approches fondamentales de la quantification
Lorsque je prépare la quantification d’un modèle, je dois choisir entre deux grandes stratégies d’exécution :
- La quantification post-entraînement (PTQ – Post-Training Quantization) : On applique la quantification sur un modèle déjà entièrement entraîné. C’est une méthode rapide, qui demande très peu de ressources de calcul et utilise un minuscule jeu de données de calibrage (généralement entre 128 et 512 échantillons) pour calculer les facteurs d’échelle.
- La quantification attentive à l’entraînement (QAT – Quantization-Aware Training) : Cette approche simule les erreurs d’arrondi de basse précision directement durant la phase d’entraînement ou de réglage fin (fine-tuning). Bien qu’elle soit extrêmement gourmande en calcul, elle permet de récupérer une précision bien supérieure et de maintenir les performances à des niveaux de quantification très agressifs (très bas nombre de bits).
Comment classifier la quantification ?
Pour mieux structurer ma démarche, j’aime diviser la quantification en quatre catégories distinctes :
1. Selon le moment de l’application (le calendrier)
- Post-Training Quantization (PTQ) : Appliquée après coup sur un modèle haute précision. C’est rapide, peu coûteux et calibré sur un très petit jeu de données.
- Quantization-Aware Training (QAT) : Intégrée pendant l’entraînement. Option coûteuse mais indispensable pour préserver la précision aux limites extrêmes de 2 ou 3 bits.
2. Selon le composant compressé
- Weight-Only Quantization (WOQ) : On compresse uniquement les poids statiques du modèle (par exemple en 4-bit) pendant que les activations restent en haute précision (FP16) lors de l’exécution. Cela permet de réduire considérablement la taille du fichier du modèle et d’économiser la mémoire vidéo (VRAM).
- Weight-Activation Quantization (WAQ) : On compresse à la fois les poids et les couches d’activation dynamiques (par exemple en W8A8). Cela libère la vitesse de calcul des cœurs Tensor lors de traitements à forte charge de requêtes simultanées (large batch).
- Quantification du cache KV (KV Cache) : Cette technique compresse l’historique d’attention Key-Value généré durant la génération, en le passant de FP16 à INT8 ou INT4. Cela permet au moteur de gérer des contextes beaucoup plus longs et des volumes de requêtes parallèles plus élevés.
3. Selon la méthode mathématique
- Quantification symétrique : Elle projette la plage de valeurs d’origine sur une plage de basse précision centrée strictement autour de zéro. C’est plus simple et plus rapide à calculer, mais cela nuit à la précision si les données d’origine sont déséquilibrées.
- Quantification asymétrique : Elle utilise un point zéro mobile (zero-point) pour faire correspondre précisément les valeurs minimales et maximales du modèle. Elle gère beaucoup mieux les données asymétriques mais introduit une légère surcharge de calcul lors de l’inférence.
4. Selon la granularité des groupes d’échelle
- Quantification par tenseur (Per-Tensor) : Un seul facteur d’échelle est utilisé pour toute une matrice de poids. C’est l’option la plus économique en mémoire, mais elle peut dégrader fortement la précision à cause des valeurs aberrantes.
- Quantification par canal (Per-Channel) : On applique un facteur d’échelle distinct à chaque ligne ou colonne d’une matrice. Cela offre un bien meilleur équilibre entre précision et vitesse de calcul.
- Quantification par groupe ou bloc (Group-Wise / Block-Wise) : On sépare les canaux en sous-groupes plus petits (par exemple de taille 32 ou 128) et on ajuste l’échelle de chacun de façon indépendante. C’est la base des méthodes d’une grande précision en 4-bit comme AWQ et GPTQ.
Comparatif des méthodes d’inférence PTQ populaires
Sur le terrain, plusieurs frameworks open-source comme vLLM ou Hugging Face intègrent ces méthodes de quantification post-entraînement. Voici un récapitulatif de mes observations sur les formats les plus répandus :
| Méthode | Précision cible | Mécanisme principal | Idéal pour |
|---|---|---|---|
| GPTQ | INT 3-bit ou 4-bit | Utilise une matrice Hessienne couche par couche pour mettre à jour les poids restants et minimiser l’erreur mathématique locale. | Déploiements GPU intensifs, inférence par lots (batching). |
| AWQ | INT 4-bit | Protège le 1 % des poids dits “saillants” en analysant la distribution des activations et en les amplifiant avant la quantification. | Matériel grand public, systèmes aux ressources limitées, réduction de la latence de chat. |
| GGUF | INT 2-bit à 8-bit | Implémente des formats de quantification par blocs hautement optimisés, conçus pour s’exécuter de manière transparente sur un fichier unifié unique. | Exécution locale sur CPU ou mixte CPU/GPU (Apple Silicon / llama.cpp). |
| SmoothQuant | 8-bit (W8A8) | Déplace mathématiquement la difficulté de quantification des activations (difficiles à compresser) vers les poids (plus faciles à compresser). | Serveurs à haut débit où les poids et les activations doivent impérativement rester en 8-bit. |
| BitsandBytes (LLM.int8()) | 8-bit ou 4-bit (NF4) | Isole les valeurs aberrantes via une précision mixte (traitement des extrêmes en FP16 et du reste en INT8/NF4). | Quantification à la volée via les transformers pour une exploration rapide et facile. |
Dans cette liste, le format NF4 (NormalFloat 4) mérite une attention particulière : c’est un type de données spécialement calibré pour les poids qui suivent une distribution normale (ce qui est le cas de la plupart des LLM). C’est théoriquement le format le plus optimal pour les configurations en 4 bits, et il sert de pilier au réglage fin efficace via QLoRA.
Weight-Only Quantization (WOQ) vs Weight-Activation Quantization (WAQ)
La distinction majeure réside dans le traitement des valeurs dynamiques générées durant l’utilisation du modèle.
| Caractéristique | Weight-Only Quantization (WOQ) | Weight-Activation Quantization (WAQ) |
|---|---|---|
| Élément quantifié | Seulement les poids statiques du modèle. | Les poids statiques et les tenseurs d’activation dynamiques. |
| Formats courants | AWQ (INT4), GPTQ (INT4), GGUF (Q4/Q8). | FP8 (E4M3), SmoothQuant (W8A8), INT8. |
| Calculs à l’exécution | Non quantifiés (FP16/BF16). | Basse précision (INT8, FP8, ou NVFP4). |
| Surcharge de calcul | Élevée : les poids doivent être reconvertis en FP16 à la volée pour faire les calculs. | Nulle : le matériel traite directement les calculs en basse précision. |
| Rétention de précision | Excellente : préserve la finesse du raisonnement et de la structure. | Modérée : les activations aberrantes peuvent introduire du bruit. |
| Usage recommandé | Petites tailles de lots (utilisateur unique), matériel local et embarqué. | Serveurs à haute concurrence, API d’entreprise dans le cloud. |
Le fonctionnement de la quantification des poids seuls (WOQ)
Avec la méthode WOQ, le “cerveau” statique du modèle est stocké de manière compressée sur le disque. Au démarrage, le système charge ces poids compressés en mémoire vidéo (VRAM). Cependant, avant que le GPU n’effectue les calculs matriciels, une couche logicielle spécialisée (un noyau ou kernel) doit décompresser ces poids à la volée en format 16-bit pour les aligner sur la précision des requêtes entrantes.
- L’avantage : Économie massive de VRAM (jusqu’à 75 % en 4-bit) avec une dégradation minimale de la précision.
- Le goulot d’étranglement : Le GPU devant continuellement décompresser les poids à la volée pour générer du texte, il ne peut pas exploiter pleinement la vitesse maximale de ses cœurs de calcul matriciel.
- Les meilleures méthodes : AWQ et GPTQ se démarquent en identifiant et en protégeant les poids les plus critiques avant d’appliquer la compression sur le reste du modèle.
Le fonctionnement de la quantification poids-activation (WAQ)
La méthode WAQ va plus loin en compressant l’intégralité du pipeline. Les fichiers du modèle ainsi que les flux de données entrants sont verrouillés en basse précision. Le GPU traite ainsi tous les calculs de bout en bout, sans devoir s’arrêter pour redimensionner ou décompresser les données.
- L’avantage : Libère toute la puissance de traitement des cœurs Tensor modernes, maximisant la vitesse de génération pour des centaines d’utilisateurs simultanés.
- Le goulot d’étranglement : Les activations sont par nature très instables. Un LLM peut soudainement générer des pics mathématiques extrêmes (valeurs aberrantes) lors d’une requête complexe. Forcer ces variations imprévisibles à entrer dans des cases rigides de 8 ou 4 bits dégrade parfois la précision de raisonnement du modèle par rapport à une approche WOQ.
- La réponse moderne : Les architectures récentes de puces comme NVIDIA Hopper et Blackwell intègrent des blocs de calcul natifs FP8 et NVFP4 conçus pour compresser dynamiquement les activations sans détruire la précision.
L’impact sur la gestion du cache KV
Ces deux méthodes influent directement sur la gestion en mémoire de l’historique de la conversation :
- Avec la méthode WOQ, le cache KV reste par défaut dans de grands formats 16-bit, à moins d’appliquer une couche d’optimisation spécifique et distincte.
- Avec la méthode WAQ, la compression des activations réduit naturellement la taille du cache KV vers du 8-bit ou du 4-bit. Le modèle gère ainsi plus facilement de très grandes fenêtres de contexte et des lots de requêtes volumineux sans saturer la VRAM.
La compatibilité matérielle : le facteur limitant
L’un de mes plus grands enseignements est que la compatibilité matérielle dicte entièrement le choix de la méthode. Charger un format inadapté se solde soit par un échec pur et simple, soit par une émulation logicielle extrêmement lente qui efface tout gain de performances.
| Catégorie de matériel | Format recommandé | Accélération silicium native | Meilleur moteur d’exécution |
|---|---|---|---|
| GPU de centres de données haut de gamme (NVIDIA Blackwell, Hopper) | FP8, NVFP4 | Blackwell : FP4 et FP8 natifs Hopper : FP8 natif | vLLM, TensorRT-LLM |
| GPU grand public & stations de travail modernes (NVIDIA Ada/Ampere, AMD RDNA3) | AWQ, GPTQ, INT4 | Cœurs Tensor (INT4 / INT8) | vLLM, Hugging Face transformers |
| CPU grand public & puces Apple Silicon (Série M, CPU Intel/AMD) | GGUF (Q4_K_M, Q8_0) | AVX-512, AMX (Intel), NEON (Apple) | llama.cpp, Ollama |
Analyse par plateforme de silicium
Les capacités matérielles imposent le choix du format selon la génération de l’architecture :
- Architecture NVIDIA Blackwell (RTX 5090, B200, B300) : Elle intègre des cœurs Tensor de cinquième génération capables de traiter nativement le format NVFP4 (Floating-Point 4-bit). Cela permet d’atteindre jusqu’à deux fois la vitesse du FP8 sans perte de précision majeure sur les tâches d’évaluation.
- Architecture NVIDIA Hopper (H100, H200) : Pour ces GPU d’entreprise, le FP8 est le format parfait. Ils accélèrent nativement les calculs en virgule flottante 8 bits, ce qui permet de faire tourner les modèles à un niveau de précision extrêmement proche du format 16-bit d’origine.
- Architectures Ampere & Ada Lovelace (RTX séries 30/40, A100) : Ces puces ne possèdent pas de moteur de calcul natif pour le FP8 ou le FP4. Il est préférable d’utiliser des formats d’entiers par blocs en 4-bit (comme AWQ ou GPTQ) pour exploiter leurs sous-cœurs matériels INT4/INT8.
- CPU grand public et Apple Silicon : Les processeurs traditionnels ne disposent pas des milliers de threads de calcul parallèle des processeurs graphiques, mais ils ont accès à de très larges pools de mémoire vive système. C’est ici que l’écosystème GGUF (conçu pour des projets comme llama.cpp) excelle en sachant répartir les couches du modèle entre la VRAM et la mémoire système. Sur les puces Apple M-series, un modèle GGUF en 4 ou 5 bits tire profit de l’architecture de mémoire unifiée à large bande passante (qui fait d’ailleurs office de VRAM ultra-rapide). C’est une sensation assez incroyable de voir un modèle de 70 milliards de paramètres tourner de manière fluide sur un simple ordinateur portable. Enfin, grâce à des moteurs exploitant Vulkan, d’autres architectures de puces (comme les cartes graphiques AMD Radeon ou Intel Arc) peuvent exécuter des opérations GGUF de façon transparente sans nécessiter l’environnement propriétaire CUDA de NVIDIA.
Les exigences d’intégration logicielle
Disposer d’une puce compatible ne sert à rien sans un logiciel adapté pour l’exploiter :
- vLLM et TensorRT-LLM : Pensés spécifiquement pour les infrastructures de serveurs GPU à haut débit. Ils intègrent des noyaux de calcul (kernels) très optimisés pour AWQ, GPTQ, FP8 et FP4.
- llama.cpp et Ollama : Conçus pour être accessibles à tous. Ils reposent principalement sur les différents niveaux de quantification d’entiers variables de GGUF (de Q2 à Q8) afin d’assurer une bonne répartition de la charge de travail entre le CPU et le GPU.
Comment choisir la meilleure méthode selon votre situation ?
Il n’existe pas de solution universelle, mais j’ai pu identifier des règles claires selon le contexte d’usage :
Scénario A : Vitesse maximale et économie de mémoire sur un seul GPU
- Gagnant : AWQ (4-bit).
- Pourquoi : Cette méthode préserve le premier pourcent des poids les plus sensibles (poids saillants) d’une compression trop agressive. On obtient ainsi une bien meilleure précision de dialogue et de raisonnement qu’avec un format INT4 classique, pour une baisse de VRAM équivalente (environ 75 % d’économie).
Scénario B : Exécuter des modèles massifs sur un ordinateur portable ou un Mac
- Gagnant : GGUF (Q4_K_M).
Scénario C : Héberger une API web à fort trafic (haut débit d’inférence)
- Gagnant : FP8 (ou SmoothQuant W8A8).
- Pourquoi : Lorsque de nombreux utilisateurs interrogent le modèle simultanément, les approches de quantification des poids seuls (WOQ) créent un ralentissement car la puce doit constamment reconvertir les poids en FP16 pour réaliser les calculs. En FP8, les poids et les activations restent quantifiés, permettant aux cœurs Tensor de tourner à plein régime sans surcoût de conversion.
Scénario D : Entraîner ou ajuster un modèle avec un budget limité
- Gagnant : NF4 (via QLoRA).
- Pourquoi : Le type de données NormalFloat 4-bit (NF4) est taillé sur mesure pour la distribution naturelle des poids d’un LLM. Charger le modèle de base en NF4 via la bibliothèque bitsandbytes permet d’ajuster finement un très grand modèle en n’utilisant qu’une fraction de la VRAM habituellement requise.
Comparatif des performances réelles des méthodes de quantification
Pour mesurer concrètement l’impact de la quantification, je regarde d’un côté la rétention de précision (Perplexité, scores MMLU) et de l’autre l’efficacité technique (débit, gain VRAM).
| Méthode de quantification | Largeur de bits (Poids / Activations) | VRAM économisée | Maintien de la précision | Cible matérielle principale | Meilleur framework d’inférence |
|---|---|---|---|---|---|
| FP16 / BF16 | 16-bit / 16-bit | 0 % (Référence) | 100 % (Référence) | GPU Cloud et grand public | Tous |
| FP8 (E4M3 / E5M2) | 8-bit / 8-bit | ~50 % | >99.5 % | NVIDIA Hopper/Blackwell | vLLM, TensorRT-LLM |
| AWQ | 4-bit / 16-bit | ~75 % | 95 % – 97 % | GPU NVIDIA et AMD modernes | vLLM (avec kernels Marlin) |
| GGUF (Q4_K_M) | Variable (moyenne 4-bit) | ~72 % | 92 % – 95 % | Apple Silicon et CPU locaux | llama.cpp, Ollama |
| GPTQ | 4-bit / 16-bit | ~75 % | 90 % – 96 % | GPU anciens et d’entreprise | ExLlamaV2, vLLM |
| NVFP4 | 4-bit / 4-bit | ~80 % | ~90 % – 93 % | NVIDIA Blackwell natif | TensorRT-LLM |
Indicateurs de précision et de qualité
1. La mesure de la perplexité (PPL)
Les méthodes en 4 bits avancées comme AWQ et GGUF (Q4_K_M) parviennent à limiter l’augmentation de la perplexité de manière spectaculaire par rapport aux méthodes de type “arrondi au plus proche” (RTN) plus rudimentaires. Grâce à la protection du premier pourcent des poids sensibles basée sur l’analyse des activations, AWQ maintient la perplexité très proche du modèle de référence. À l’inverse, dès que l’on descend vers des formats 3-bit ou 2-bit (comme le GGUF Q2_K), on assiste à une dégradation brutale : le modèle perd sa cohérence structurelle et peine à suivre un contexte long.
2. Tests académiques (MMLU et HumanEval)
Sur des bancs d’essai exigeants comme MMLU-Pro, le format FP8 ne montre presque aucune perte d’intelligence mesurable, affichant un score situé à seulement 0,5 % ou 0,6 % du modèle BF16 natif. Pour les tâches de génération de code (HumanEval), le FP8 conserve même fréquemment 100 % de la précision d’origine. Si l’on compare AWQ et GPTQ à taille égale (4 bits), AWQ s’en sort légèrement mieux sur le suivi d’instructions complexes, la logique mathématique (GSM8K) et la rédaction créative, tandis que GPTQ perd parfois quelques points sur la rigueur du code produit.
Mesures de vitesse et de latence
1. Débit de génération (Tokens par seconde)
Pour des architectures de serveurs sollicitées par plusieurs utilisateurs en même temps, la quantification poids-activation (W8A8 / FP8) l’emporte haut la main, augmentant le nombre de tokens générés par seconde de 14 % à 26 %. Le GPU évite en effet le coût de décompression des poids lors des calculs en parallèle. Pour un utilisateur unique exécutant un modèle en local, ce sont les méthodes Weight-Only (W4A16) — comme AWQ avec des kernels Marlin ou GPTQ via ExLlamaV2 — qui offrent les vitesses d’inférence brute les plus rapides.
2. Temps de génération du premier token (TTFT – Time to First Token)
Les modèles quantifiés réduisent de manière significative le temps de traitement de la requête initiale (le prompt prefill), car les couches de modèles compressées tiennent entièrement dans la VRAM ou la mémoire SRAM ultra-rapide. Cela évite les goulots d’étranglement de transfert de données. Les configurations statiques en FP8 permettent ainsi de gagner environ 20 % de temps sur la génération du tout premier token par rapport à un modèle non compressé.
Bilan financier et économie de ressources
Passer d’une précision standard de 16 bits à un format 4 bits divise les besoins en mémoire physique par quatre. C’est l’étape indispensable pour réussir à charger un modèle de 70 milliards de paramètres sur une seule carte grand public de 24 Go (comme une RTX 4090) ou sur un Mac Studio standard. Pour une entreprise, cette compression à 4-bit permet de réduire les besoins en serveurs GPU cloud jusqu’à 80 %, offrant un retour sur investissement immédiat.
La quantification appliquée à l’Edge AI
La quantification pour l’Edge AI consiste à adapter les LLM pour les faire tourner directement sur des appareils de tous les jours : smartphones, ordinateurs portables, boîtiers domotiques ou ordinateurs monocartes (comme un Raspberry Pi). Dans ce cas, les contraintes matérielles sont drastiques : mémoire vive réduite, enveloppe thermique stricte et absence d’accès à un GPU cloud.
C’est grâce à la quantification qu’un appareil mobile peut aujourd’hui traiter une requête d’intelligence artificielle locale sans aucune connexion internet.
| Classe de matériel Edge | Contrainte principale | Format de quantification recommandé | Moteur logiciel clé |
|---|---|---|---|
| Ordinateurs portables et fixes (CPU Intel/AMD, Apple Mac) | Mémoire système & bande passante mémoire | GGUF (Q4_K_M ou Q5_K_M) | llama.cpp, Ollama, LM Studio |
| Smartphones et tablettes (Séries Apple A/M, Snapdragon) | Consommation batterie, limites thermiques | AWQ / INT4, GGUF (Q4_0) | MLC LLM, ExecuTorch, Apple MLX |
| Ordinateurs monocartes (Raspberry Pi 5, Jetson Nano) | Processeur très limité, RAM faible | GGUF (Q2_K ou Q3_K_M) | llama.cpp (avec un OS léger optimisé) |
Les formats dominants pour l’Edge
- GGUF : C’est le standard de l’exécution locale. Son point fort réside dans sa gestion par blocs à précision variable. Par exemple, sur un modèle Q4_K_M, les couches d’attention stratégiques sont maintenues en haute précision (5 ou 6 bits) tandis que les autres passent en 4 bits. Si le modèle dépasse légèrement la VRAM disponible, le système bascule intelligemment l’excédent sur la RAM classique pour éviter un plantage.
- INT4 / AWQ Mobile : C’est la solution de choix pour les puces mobiles équipées d’un NPU (Neural Processing Unit). En chargeant des poids de 4 bits depuis l’espace de stockage, on soulage la bande passante de la mémoire, qui est le principal point de blocage sur l’architecture des smartphones.
Les indicateurs clés de performance à l’Edge
Sur le terrain de l’Edge AI, les critères d’évaluation diffèrent radicalement de ceux des centres de données :
- Consommation d’énergie (Joules/Token) : Exécuter des modèles non compressés sollicite énormément le processeur et la puce graphique, ce qui fait surchauffer les téléphones et vide leur batterie. Réduire la précision en 4-bit diminue l’énergie consommée par l’accès à la mémoire de près de 75 %, évitant ainsi la surchauffe.
- Taille en mémoire (VRAM/RAM) : Un téléphone portable ou un ordinateur d’entrée de gamme ne dispose généralement que de 8 à 16 Go de mémoire partagée. Charger un modèle de 7 milliards de paramètres en FP16 réclame déjà 14 Go à lui seul. Compressé en 4-bit, il n’occupe plus que ~4 Go, ce qui laisse une marge confortable pour le système d’exploitation et les applications en arrière-plan.
- Débit de génération (Tokens par seconde) : Pour obtenir une lecture agréable, la vitesse d’écriture doit dépasser la vitesse de lecture humaine moyenne (qui se situe autour de 10 à 15 tokens par seconde). La quantification en 4 bits permet d’atteindre facilement les 20 à 30 tokens par seconde sur des processeurs intermédiaires.
Le processus de déploiement sur matériel Edge
Voici le cheminement logique que je suis pour installer un modèle localement :
- Sélection du modèle de base : Je choisis d’abord un modèle léger, conçu spécifiquement pour l’efficacité (comme Llama-3-8B, Phi-3 ou Gemma-2-9B).
- Quantification en 4 ou 5 bits : J’utilise des outils comme llama.cpp pour convertir et compresser les poids du modèle.
- Intégration via des moteurs Edge : J’exploite des environnements dédiés comme ExecuTorch (le moteur mobile de Meta) ou MLC LLM pour activer l’accélération matérielle native du NPU de l’appareil.