Quantification

La quantification est le processus de conversion des poids d'un LLM, depuis des nombres à virgule flottante de haute précision (typiquement bfloat ou float 16 bits) vers des entiers ou des flottants de plus faible précision (8 bits, 4 bits, parfois 2 bits), réduisant l'empreinte mémoire et accélérant l'inférence pour seulement une légère perte de qualité. Le déploiement open source moderne, à savoir llama.cpp, Ollama, vLLM, GPTQ, AWQ, s'exécute presque entièrement sur des modèles quantifiés.

Pourquoi c'est important

Un modèle de 70 milliards de paramètres au format natif 16 bits nécessite environ 140 Go de mémoire GPU, hors de portée d'une seule carte grand public. Le même modèle en quantification 4 bits occupe environ 35 Go et tient sur deux GPU grand public, sur une seule carte de station de travail, voire sur un Mac Studio. La quantification est ce qui a rendu les LLM locaux praticables : Llama 3 70B, Mixtral 8×22B et DeepSeek-V3 s'exécutent tous sur du matériel à 3 000 dollars grâce à la quantification. Pour les développeurs, c'est la différence entre « nous ne pouvons pas nous permettre l'auto-hébergement » et « nous pouvons servir nos propres modèles ».

Comment cela fonctionne

Niveaux de précision :

• FP32 (flottant 32 bits) : valeur par défaut pour l'entraînement. 4 octets par poids. Rarement utilisé pour l'inférence.
• FP16 / BF16 (16 bits) : valeur par défaut pour l'inférence. 2 octets par poids.
• INT8 (entier 8 bits) : moitié de la mémoire, qualité quasi identique.
• INT4 / FP4 (4 bits) : quart de la mémoire, légère perte de qualité (généralement 1 à 3 % sur les benchmarks).
• INT2 (2 bits) : huitième de la mémoire, perte de qualité notable sur la plupart des tâches.

Processus de quantification :

1. Calibration : le modèle est exécuté sur un petit jeu de données pour observer les plages d'activation.
2. Calcul de l'échelle et du point zéro : pour chaque tenseur de poids, calculez les facteurs d'échelle qui mappent la plage d'origine sur la plage des entiers.
3. Conversion des poids : chaque poids est quantifié, stocké sous forme d'entier accompagné de facteurs d'échelle par groupe ou par canal.
4. Déquantification à l'inférence : au moment du calcul, les poids sont réétendus en virgule flottante juste avant la multiplication matricielle.

Méthodes de quantification

RTN (Round to Nearest) : la méthode la plus rudimentaire. Arrondit simplement les poids à la valeur quantifiée la plus proche. Rapide, faible qualité.

GPTQ : quantification post-entraînement par groupes qui minimise l'erreur de reconstruction. Norme open source pour le 4 bits.

AWQ (Activation-aware Weight Quantization) : préserve les poids qui gèrent les fortes activations ; quantifie le reste de manière plus agressive. Très populaire pour les LLM 4 bits.

GGUF (Q4_K_M, Q5_K_M, etc.) : la famille de formats de quantification par blocs de llama.cpp. Les variantes K_M équilibrent taille et précision. Q4_K_M est le format par défaut pour l'inférence locale.

SmoothQuant : déplace les valeurs aberrantes d'activation dans les poids afin que les deux puissent être quantifiés proprement. Permet l'INT8 sans grande perte de précision sur les grands modèles.

QAT (Quantization-Aware Training) : entraîne le modèle avec la quantification intégrée à la boucle. Meilleure qualité mais nécessite un réentraînement.

FP8 : un format de flottant 8 bits natif matériel pris en charge par les GPU H100/H200. Plus rapide que l'INT8 pour l'entraînement et l'inférence.

Compromis

Qualité vs compression : plus la précision est basse, plus le modèle se dégrade. Le 8 bits est presque gratuit ; le 4 bits est un bon choix par défaut ; le 2 bits nuit visiblement.

Sensibilité des tâches : les mathématiques, le code et les raisonnements longs sont plus durement touchés par la quantification que la conversation ou le résumé.

Vitesse vs mémoire : la quantification économise de la mémoire mais n'accélère pas toujours l'inférence sur des GPU disposant d'une abondante puissance de calcul. Sur du matériel limité par la mémoire (GPU grand public, Apple Silicon), c'est une énorme accélération.

Qualité des données de calibration : une mauvaise calibration peut silencieusement ruiner les modèles quantifiés. Utilisez des prompts représentatifs.

Que choisir et quand

Exécution sur GPU grand public (8 à 24 Go) : GGUF 4 bits (Q4_K_M) ou AWQ.

Exécution sur H100/H200 : FP8 ou INT8 avec SmoothQuant.

Edge / mobile : GGUF 4 bits ou 2 bits agressif ; acceptez la perte de qualité.

Recherche de benchmarking : conservez FP16/BF16 comme référence ; ne quantifiez que pour la comparaison de déploiement.

Production à forts enjeux : 8 bits ou 16 bits. Le coût marginal vaut la garantie de qualité.

Erreurs courantes

Comparer des benchmarks entre précisions sans le préciser : le score MMLU d'un modèle quantifié n'est pas directement comparable au score FP16 du même modèle.

Ignorer la dérive de la perplexité : même si les benchmarks semblent corrects, la quantification peut dégrader des compétences spécifiques (les mathématiques surtout). Testez sur votre charge de travail réelle.

Trop agressif trop vite : passer du FP16 directement à l'INT2 sans tester les étapes intermédiaires masque l'endroit où la qualité a chuté.

Utiliser des données de calibration périmées : un modèle calibré uniquement sur l'anglais perdra en qualité sur les prompts en coréen.

Ne pas mesurer la latence de bout en bout : la quantification affecte à la fois le chargement mémoire et le calcul. Parfois le débit ne s'améliore pas parce que le goulot d'étranglement était ailleurs.

Sources :

• Un guide visuel de la quantification - Maarten Grootendorst
• Article AWQ - MIT
• Quantification GGUF et llama.cpp - Hugging Face