Accueil › Glossaire › Quantization

Quantization (Quantification de modèles IA)

La quantization est une technique de compression qui réduit la précision numérique des poids (et parfois des activations) d’un modèle d’intelligence artificielle, convertissant par exemple des valeurs en FP16 (16 bits) vers INT8 (8 bits) ou INT4 (4 bits), pour diminuer l’empreinte mémoire et accélérer l’inférence.

Concrètement, un modèle de 7 milliards de paramètres stocké en FP16 occupe environ 14 Go de VRAM. Passez-le en INT8 : il tombe à 7 Go. En INT4 : environ 3,5 Go. C’est cette arithmétique simple qui rend possible l’exécution de LLM sur du matériel grand public, une carte graphique de gaming, un MacBook, voire un smartphone.

Pourquoi la quantization est devenue indispensable

Les LLM ont explosé en taille. Un modèle de 70 milliards de paramètres en FP16 nécessite environ 140 Go juste pour les poids, sans compter le cache KV, les activations et l’overhead du framework. Aucun GPU grand public ne peut gérer ça. Et même côté serveur, chaque Go de VRAM économisé se traduit directement en plus de requêtes simultanées, des contextes plus longs, ou moins de GPU à payer.

La quantization résout trois problèmes en parallèle :

Réduction de la mémoire. Moins de bits par poids signifie un modèle plus petit en VRAM. C’est le bénéfice le plus direct. Un modèle 7B en INT4 (environ 4,5 Go) tient confortablement sur un GPU de 8 Go, là où la version FP16 (14 Go) ne passerait pas.

Accélération de l’inférence. Des tenseurs plus petits transitent plus vite à travers la bande passante mémoire du GPU. Pour les scénarios memory-bound (génération token par token), c’est un gain de throughput direct.

Réduction des coûts. Moins de VRAM consommée par requête signifie plus d’utilisateurs servis par GPU. En production, passer de FP16 à INT4 peut multiplier par 10 le nombre de requêtes concurrentes sur un même GPU H100, selon les benchmarks récents.

Comment fonctionne la quantization

Le principe fondamental est simple : mapper des valeurs à haute précision (beaucoup de bits, beaucoup de valeurs possibles) vers un ensemble réduit de valeurs discrètes (moins de bits).

Les types de données en jeu

Pour comprendre la quantization, il faut d’abord connaître les formats numériques utilisés dans les modèles IA :

FP32 (32 bits) : le format d’entraînement historique. Très précis, mais gourmand : 4 octets par paramètre. Un modèle 7B pèse 28 Go.

FP16 (16 bits) : le standard actuel pour la distribution des modèles. 2 octets par paramètre, bonne précision pour les petits nombres, mais risque d’overflow en entraînement. Un 7B pèse ~14 Go.

BF16 (16 bits) : développé par Google, il conserve la même plage dynamique que FP32 (8 bits d’exposant) tout en réduisant la précision de la mantisse. C’est le format préféré pour l’entraînement des gros modèles. Même empreinte mémoire que FP16.

FP8 (8 bits) : supporté nativement sur les GPU NVIDIA Hopper (H100) et Blackwell (B200). Il combine la compacité de INT8 avec le format flottant, offrant un bon compromis précision/mémoire. Encore limité en termes de support matériel.

INT8 (8 bits) : 1 octet par paramètre. Le standard de l’inférence efficace en production. La plage va de -128 à 127. Réduction de ~50 % par rapport à FP16, avec une dégradation de qualité quasi nulle.

INT4 (4 bits) : 0,5 octet par paramètre. Réduction de ~75 % par rapport à FP16. Plus sensible aux outliers, mais les méthodes modernes (AWQ, GPTQ, K-quants) permettent de conserver 97 à 99 % de la qualité originale.

NF4 (NormalFloat 4 bits) : un format 4 bits spécialement conçu pour les poids de réseaux de neurones. Il exploite le fait que ces poids suivent une distribution normale (centrée autour de zéro) et place plus de niveaux de quantification dans cette zone dense. Utilisé par QLoRA, il offre une meilleure précision que INT4 standard (environ 0,2 % d’erreur vs l’original, contre des valeurs plus élevées pour INT4 naïf).

Le processus de quantification

Prenons un exemple concret avec INT8. Vous avez un poids en FP16 de valeur 0.15625. Le processus fonctionne ainsi :

D’abord, on calcule un facteur d’échelle (scale factor) basé sur la plage de valeurs du groupe de poids. Par exemple, si la valeur max est 1.0, le scale factor est 127 (la valeur max en INT8). Ensuite, on multiplie le poids par ce facteur : 0.15625 × 127 = 19.84. On arrondit à l’entier le plus proche : 20. Ce 20 est stocké en 8 bits. À l’inférence, on déquantifie : 20 ÷ 127 = 0.15748. L’erreur est d’environ 0,7 % par rapport à la valeur originale.

Ce processus se fait par blocs (groupes de 64 ou 128 poids) plutôt que sur l’ensemble du tenseur. Plus les groupes sont petits, plus la quantification est précise, mais plus il faut stocker de facteurs d’échelle (ce qui augmente légèrement la taille finale).

Post-Training Quantization vs Quantization-Aware Training

Il existe deux grandes approches pour quantifier un modèle. Le choix entre les deux dépend de vos contraintes de temps, de budget de calcul, et du niveau de qualité visé.

Post-Training Quantization (PTQ)

C’est la méthode la plus courante, et de loin. On prend un modèle déjà entraîné en FP16/BF16 et on convertit ses poids vers un format à plus basse précision, sans le ré-entraîner. C’est rapide (quelques heures pour un modèle de 70B), ne nécessite pas le dataset d’entraînement complet, et les outils sont matures.

Les méthodes PTQ modernes comme GPTQ et AWQ utilisent un petit jeu de données de calibration (quelques centaines d’exemples) pour mesurer l’impact de la quantification couche par couche et ajuster les paramètres en conséquence. La perte de qualité en INT8 est typiquement inférieure à 0,5 % sur les benchmarks standards. En INT4 avec GPTQ ou AWQ, on conserve généralement 97 à 99 % de la qualité FP16.

Quantization-Aware Training (QAT)

Le QAT intègre la simulation de la quantification directement pendant l’entraînement (ou le fine-tuning). Le modèle « apprend » à fonctionner avec des poids quantifiés, ce qui produit généralement de meilleurs résultats que le PTQ, surtout à très basse précision (2-3 bits).

Le problème : c’est coûteux. Il faut ré-entraîner le modèle (ou au minimum le fine-tuner), ce qui demande du matériel et du temps. Pour un LLM de plusieurs dizaines de milliards de paramètres, c’est rarement pratique. C’est pourquoi le PTQ domine largement dans l’écosystème LLM.

Une approche hybride populaire : QLoRA. Elle quantifie le modèle de base en 4 bits (via NF4 et Double Quantization) puis ajoute de petits adaptateurs LoRA entraînables en FP16. Cela permet de fine-tuner un modèle 65B sur un seul GPU, en combinant les avantages de la quantification et de l’adaptation efficace.

Les principales méthodes de quantization pour LLM

L’écosystème des méthodes de quantification a beaucoup mûri. Voici les techniques qui comptent en pratique.

GPTQ

GPTQ (Generative Pre-trained Transformer Quantization) est une méthode PTQ qui quantifie les poids couche par couche en minimisant l’erreur quadratique par rapport aux sorties du modèle original. C’est la première méthode à avoir démontré qu’on pouvait compresser un LLM à 4 bits tout en conservant une qualité acceptable. Elle peut quantifier un modèle de 175B en environ 4 heures sur GPU. GPTQ ne touche pas aux activations (seulement les poids). Les modèles GPTQ sont largement disponibles sur Hugging Face et supportés par vLLM, AutoGPTQ, et d’autres frameworks de serving.

AWQ

AWQ (Activation-aware Weight Quantization) part d’une observation : environ 1 % des poids sont « saillants » (c’est-à-dire critiques pour la qualité du modèle). Plutôt que de traiter tous les poids de la même façon, AWQ protège sélectivement ces poids importants en se basant sur les distributions d’activation observées (pas seulement les poids eux-mêmes). Le résultat : une qualité légèrement supérieure à GPTQ à précision égale, et un format bien adapté au déploiement sur des appareils edge ou dans des environnements sensibles à la latence.

SmoothQuant

Quantifier les poids est relativement simple. Quantifier les activations, en revanche, est beaucoup plus difficile à cause des outliers (valeurs aberrantes) qui apparaissent dans certains canaux. SmoothQuant résout ce problème en « lissant » les activations : il transfère mathématiquement une partie de la difficulté de quantification des activations vers les poids, via une transformation équivalente. Le résultat est une quantification W8A8 (poids en INT8, activations en INT8) qui fonctionne bien. C’est une solution clé en main pour les déploiements production qui veulent quantifier à la fois poids et activations.

bitsandbytes (LLM.int8() et NF4)

La bibliothèque bitsandbytes, intégrée à l’écosystème Hugging Face Transformers, offre deux méthodes populaires. LLM.int8() quantifie en INT8 tout en préservant les poids outliers dans un chemin séparé en FP16 (décomposition en valeurs mixtes). NF4 (utilisé par QLoRA) est un format 4 bits optimisé pour la distribution normale des poids de LLM. C’est le moyen le plus rapide de charger un modèle quantifié via Transformers, avec deux lignes de code (load_in_8bit=True ou load_in_4bit=True).

K-Quants (llama.cpp / GGUF)

Les K-quants sont le système de quantification développé par la communauté llama.cpp. Contrairement aux méthodes uniformes, les K-quants utilisent une stratégie de précision mixte : les couches d’attention (plus sensibles) reçoivent une précision plus élevée (souvent 6 bits), tandis que les couches feedforward sont quantifiées plus agressivement à 4 bits. Le format Q4_K_M (Medium) est le plus recommandé : il conserve 97 à 99 % de la qualité FP16 sur les benchmarks de perplexité, tout en réduisant la taille de 70 à 75 % par rapport à FP16. Les K-quants excellent pour l’inférence CPU et les configurations hybrides CPU+GPU.

Impact sur la qualité : ce que disent les benchmarks

La question que tout le monde se pose : « Combien de qualité est-ce que je perds ? » La réponse dépend fortement de la méthode et de la précision cible.

INT8 : quasiment transparent

Les benchmarks récents montrent que la quantification en INT8 entraîne une dégradation inférieure à 0,5 % sur les métriques standards (MMLU, HellaSwag, etc.) par rapport au modèle FP16 de référence. Pour la très grande majorité des cas d’usage en production, la différence est indétectable. C’est le choix le plus sûr si vous hésitez.

INT4 : dépend de la méthode

En INT4, l’écart se creuse et la méthode choisie compte beaucoup. AWQ et Q4_K_M surpassent régulièrement le GPTQ-4bit naïf en termes de préservation de la qualité. Sur un Llama 3.1 8B par exemple, Q4_K_M et AWQ conservent environ 98-99 % de la qualité FP16 sur MMLU et HellaSwag, là où un GPTQ sans optimisation peut descendre plus bas. Les tâches de raisonnement complexe sont les plus sensibles : c’est là que les écarts se manifestent le plus.

En dessous de 4 bits : terrain expérimental

Les quantifications à 2-3 bits (INT2, INT3) restent expérimentales. La dégradation devient perceptible, même avec les meilleures méthodes. Des travaux récents comme BitDistiller ou BinaryMoS explorent des approches créatives (binarisation avec experts de scaling adaptatifs), mais ces techniques ne sont pas encore matures pour la production.

Tableau récapitulatif : mémoire et qualité par format

Formats de fichier pour les modèles quantifiés

Les modèles quantifiés sont distribués dans différents formats, chacun lié à un écosystème d’outils :

GGUF : le format de llama.cpp. Un fichier unique contenant poids, tokenizer et métadonnées. C’est le format de référence pour l’inférence locale via Ollama, LM Studio, ou Jan. Il supporte les K-quants (Q4_K_M, Q5_K_M, Q8_0, etc.) et l’offloading CPU+GPU hybride.

SafeTensors (GPTQ/AWQ) : les modèles quantifiés avec GPTQ ou AWQ sont distribués au format SafeTensors sur Hugging Face. Ils nécessitent un framework de serving compatible (vLLM, AutoGPTQ, AutoAWQ) et sont optimisés pour l’inférence GPU pure.

ONNX : le format d’échange interopérable. Un modèle peut être quantifié via ONNX Runtime et déployé sur divers accélérateurs (CPU, GPU, NPU). Moins courant pour les LLM que GGUF ou SafeTensors, mais important pour les pipelines multi-plateformes.

TensorRT (NVIDIA) : le moteur d’optimisation de NVIDIA produit des engines binaires ultra-optimisés pour les GPU NVIDIA. TensorRT-LLM supporte nativement FP8, INT8 et INT4 avec des kernels spécialisés. C’est le choix performance maximale sur hardware NVIDIA, mais les modèles ne sont pas portables vers d’autres plateformes.

Quantization en pratique : les outils

Quantifier un modèle vous-même

Si vous voulez quantifier un modèle open-source pour votre propre usage, voici les approches principales :

Avec bitsandbytes (le plus simple) : intégré dans Hugging Face Transformers, il suffit d’ajouter load_in_8bit=True ou load_in_4bit=True au chargement du modèle. Aucune calibration nécessaire. Idéal pour le prototypage et le fine-tuning avec QLoRA.

Avec AutoGPTQ : fournissez un petit dataset de calibration (128-512 exemples) et le framework quantifie le modèle couche par couche en quelques heures. Les modèles résultants sont compatibles avec vLLM et Hugging Face.

Avec AutoAWQ : même principe que GPTQ, mais avec la méthode AWQ. Légèrement plus lent à quantifier, mais qualité souvent supérieure. Supporte le fusing de couches pour accélérer l’inférence.

Avec llama.cpp (GGUF) : convertissez un modèle FP16 en GGUF avec les scripts de conversion inclus, puis appliquez la quantification souhaitée (Q4_K_M, Q5_K_S, Q8_0, etc.). Pas de dataset de calibration nécessaire pour les K-quants.

Avec LLM Compressor (vLLM) : une bibliothèque dédiée à l’optimisation de modèles pour le déploiement avec vLLM. Elle supporte FP8, INT8, INT4 et d’autres formats, avec un workflow de calibration intégré.

Utiliser un modèle déjà quantifié

Dans la majorité des cas, vous n’avez pas besoin de quantifier vous-même. Des milliers de modèles pré-quantifiés sont disponibles sur Hugging Face Hub, notamment ceux publiés par des contributeurs spécialisés. Pour l’inférence locale :

Ollama : télécharge et lance des modèles GGUF quantifiés en une seule commande (ollama run llama3.1:8b-q4_K_M). C’est la solution la plus accessible.

LM Studio : interface graphique qui parcourt le Hub Hugging Face, télécharge les modèles GGUF, et les exécute localement. Idéal pour les non-développeurs.

Jan : alternative open-source à LM Studio, avec une interface similaire et un focus sur la vie privée.

Pour le serving en production :

vLLM : supporte GPTQ, AWQ, FP8, INT8, et de nombreux autres formats de quantification. C’est le moteur d’inférence de référence pour le serving haute performance.

TGI (Text Generation Inference) : le serveur d’inférence de Hugging Face, avec support natif des modèles quantifiés GPTQ et AWQ.

TensorRT-LLM : performances maximales sur GPU NVIDIA, avec support FP8, INT8, INT4 et des optimisations kernel spécifiques.

Comment choisir la bonne méthode de quantization

Le choix dépend de trois facteurs : votre matériel, votre cas d’usage, et votre tolérance à la perte de qualité.

Quantization vs autres techniques de compression

La quantization n’est pas la seule approche pour réduire la taille d’un modèle. Deux autres techniques coexistent :

Pruning : supprime les poids proches de zéro (considérés comme peu importants). Réduit le nombre de paramètres effectifs. Peut être structuré (suppression de neurones/couches entières) ou non structuré (poids individuels). Le pruning structuré facilite l’accélération matérielle, mais le pruning non structuré rend le tenseur « creux » (sparse), ce qui nécessite un support matériel spécifique pour en tirer un gain de vitesse.

Distillation : entraîne un modèle plus petit (l’« élève ») à reproduire le comportement d’un modèle plus gros (le « professeur »). Contrairement à la quantization, la distillation produit un modèle architecturellement différent, souvent avec moins de couches ou de dimensions cachées. C’est plus coûteux que la quantization, mais permet des réductions de taille plus radicales.

En pratique, ces techniques sont complémentaires. Vous pouvez distiller un modèle 70B en un modèle 7B, puis quantifier ce 7B en INT4 pour une empreinte finale minimale. C’est d’ailleurs la philosophie derrière des modèles comme les Ministral de Mistral AI ou les petits modèles de la famille Phi de Microsoft.

Tendances et évolutions

Le domaine de la quantization évolue vite. Plusieurs tendances se dessinent :

FP8 comme nouveau standard de production. Avec le support natif sur les GPU Hopper (H100) et Blackwell (B200) de NVIDIA, le FP8 combine la simplicité du format flottant avec la compacité du 8 bits. Il nécessite moins de calibration que INT8 et offre une qualité légèrement supérieure grâce à sa capacité à représenter une plage dynamique plus large.

Quantification du cache KV. Au-delà des poids, quantifier le cache KV (de FP16 vers FP8 ou INT8) divise par deux la mémoire consommée par le cache, avec un impact minimal sur la qualité. Combiné avec le GQA (Grouped Query Attention) déjà intégré dans les modèles modernes, c’est un levier puissant pour servir des contextes longs ou plus d’utilisateurs simultanés.

Quantification sub-4-bit. Les recherches sur la binarisation (1 bit) et la quantification à 2-3 bits progressent. Des travaux comme BitNet (Microsoft) explorent des architectures nativement conçues pour fonctionner en 1 bit. Si ces approches mûrissent, elles pourraient permettre de faire tourner des modèles de taille « frontier » sur des appareils mobiles.

Quantification dynamique et adaptative. Plutôt que d’appliquer la même précision à l’ensemble du modèle, les approches récentes adaptent la précision par couche, par tête d’attention, voire par token. L’idée : allouer plus de bits là où le modèle en a besoin, et moins ailleurs.