En bref

Un modèle 70 milliards de paramètres stocké en FP16 occupe environ 140 Go de mémoire GPU. Aucun PC grand public ne peut l’héberger. La quantization réduit la précision numérique de chaque poids — de 16 bits à 4 bits, par exemple — et fait passer ce même modèle à 35 Go. La qualité baisse un peu. Mais souvent moins qu’on ne le craint.

Le problème de départ : les nombres flottants coûtent cher

Un réseau de neurones, c’est une immense liste de nombres — les poids. Chaque poids encode une fraction de ce que le modèle a appris. Pendant l’entraînement, ces nombres sont stockés en FP32 (virgule flottante 32 bits) pour une précision maximale. À l’inférence, on passe souvent en FP16 ou BF16 (16 bits) : un gain de 2× en mémoire, sans perte notable.

Mais 16 bits par poids, sur 70 milliards de poids, ça fait 140 Go. Pour tenir sur un GPU grand public (16-24 Go de VRAM), il faut descendre davantage.

La quantization pousse cette logique plus loin : représenter chaque poids avec 8, 4, ou même 2 bits. La mémoire chute. L’inférence s’accélère. Le prix à payer : une perte d’information que le modèle doit absorber sans trop se dégrader.

L’échelle de précision

La progression standard des formats va de la haute précision vers la compression extrême :

  • FP32 (32 bits) : entraînement, précision maximale
  • FP16 / BF16 (16 bits) : inférence standard, perte quasi nulle
  • INT8 / FP8 (8 bits) : compression 2× supplémentaire, dégradation <2 % de perplexité
  • INT4 / NF4 (4 bits) : compression 4× vs FP16, dégradation 2–8 %
  • 3 bits : dégradation 8–15 %, usage expérimental
  • 2 bits : dégradation 15–30 %, terrain de recherche

Chaque palier divise approximativement la mémoire par deux. La dégradation n’est pas linéaire : descendre de 16 à 8 bits est presque gratuit, descendre de 4 à 2 bits commence à faire mal.

Deux familles de méthodes

PTQ — Post-Training Quantization

La quantization s’applique après l’entraînement, sur un modèle déjà entraîné. On utilise un petit dataset de calibration (quelques centaines d’exemples) pour estimer comment compresser les poids avec le minimum de dégâts. Coût : quelques heures de calcul, pas de GPU A100 nécessaire. C’est la méthode dominante en pratique.

QAT — Quantization-Aware Training

La quantization est simulée pendant l’entraînement ou le fine-tuning. Le modèle apprend à fonctionner avec des poids compressés. Résultat : meilleure qualité, surtout en dessous de 4 bits. Coût : prohibitif pour les grands modèles. Sur des modèles plus petits, PyTorch QAT récupère jusqu’à 96 % de la dégradation observée en PTQ sur le benchmark HellaSwag avec Llama 3. Pour un modèle de 70B, personne n’a encore publié un pipeline QAT viable à cette échelle.

Les méthodes PTQ qui comptent

GPTQ

GPTQ (2022-2024) est la première méthode à avoir rendu la quantization 4 bits réellement viable. Elle fonctionne couche par couche : pour chaque couche du transformeur, elle quantize les poids en compensant l’erreur introduite sur les poids suivants, via une reformulation algébrique basée sur le Hessien (Optimal Brain Quantization). C’est l’approche la plus répandue sur HuggingFace.

AWQ

AWQ (Activation-Aware Weight Quantization) part d’un constat : tous les poids ne sont pas égaux. Environ 1 % des canaux sont “saillants” — ils influencent disproportionnellement la sortie, comme le révèle l’analyse des activations. AWQ identifie ces canaux et leur applique un scaling avant la quantization uniforme, ce qui préserve l’essentiel de l’information. Résultat : AWQ surpasse régulièrement GPTQ en précision à taille de compression équivalente.

SmoothQuant

SmoothQuant cible un objectif différent : quantizer à la fois les poids et les activations (format W8A8). Le problème des activations, c’est la présence de valeurs aberrantes (outliers) difficiles à compresser. SmoothQuant transfère mathématiquement la difficulté des activations vers les poids, rendant les deux quantizables de façon uniforme. Cette approche est particulièrement adaptée aux accélérateurs hardware optimisés pour W8A8.

AQLM et SpQR — pour la compression extrême

Pour descendre sous 3 bits, deux méthodes se distinguent. SpQR combine une représentation sparse et la quantization : les poids les plus importants restent en haute précision, les autres sont compressés agressivement, avec une perte de perplexité inférieure à 1 % à environ 4 bits par paramètre. AQLM pousse jusqu’à 2 bits grâce à une quantization additive par bloc avec optimisation conjointe des codebooks — premier schéma Pareto-optimal sous 3 bits selon la littérature.

Les formats concrets

INT8 et FP8 : la zone sûre

INT8 est le format le plus stable et le plus largement supporté. La perte de qualité est négligeable (<2 % de perplexité). FP8 (format flottant 8 bits, variantes E4M3 et E5M2) est encore plus stable sur les grands modèles : c’est l’option recommandée pour le déploiement production selon une étude IJCAI 2025 couvrant plusieurs architectures et tâches. NVIDIA a intégré FP8 nativement dans ses GPU Hopper (H100) ; vLLM 0.5 (2024) en tire un gain de ~33 % de latence.

INT4 / NF4 : le compromis populaire

NF4 (NormalFloat 4 bits) est un format flottant 4 bits conçu pour des poids normalement distribués — ce que sont les poids de la majorité des LLMs. Introduit par l’article QLoRA (Dettmers et al., 2023), il est utilisé via la librairie bitsandbytes pour le fine-tuning sur GPU consommateur. La dégradation reste dans une fourchette de 2–8 % selon les modèles et les tâches.

GGUF et llama.cpp : l’écosystème CPU

GGUF est le format de fichier standard pour l’inférence locale sur CPU, développé par le projet llama.cpp. Il remplace l’ancien format GGML et supporte des niveaux de compression allant de Q2 à Q8, avec des variantes K-quant (suffixes _S, _M, _L pour small/medium/large).

Le compromis recommandé est Q4_K_M : un modèle 7B passe de 13,5 Go (FP16) à 4,08 Go, avec environ 95 % de la qualité conservée. Pour des usages critiques — codage, STEM — Q5_K_M est préférable. llama.cpp permet l’inférence native sur CPU sans GPU, ce qui explique son adoption massive pour le déploiement local.

NVFP4 : le format des prochains datacenters

Lancé en 2025 pour les GPU Blackwell (B200), NVFP4 est un format flottant 4 bits avec une taille de bloc de 16. Comparé à FP16, il réduit la mémoire de 3,5×. Comparé à FP8, il offre 2,3× de débit en plus avec une dégradation inférieure à 1 % sur les tâches de langage. C’est le format cible pour les déploiements haute performance de nouvelle génération.

Ce qui résiste à la compression

Les modèles ne vieillissent pas tous aussi bien sous compression. Quelques observations empiriques issues de la littérature :

Les tâches de codage et de STEM souffrent davantage. La génération de texte générale est plus robuste que la production de code exact ou de raisonnement mathématique. Un modèle quantizé en 4 bits sur une tâche de génération conversationnelle peut sembler intact, mais produire davantage d’erreurs sur du code.

Les petits modèles (<7B) sont plus fragiles. La quantization basse précision est calibrée pour les grands modèles. En dessous de 7B de paramètres, les pertes sont disproportionnées. SLMQuant (novembre 2025) a documenté ce phénomène mais sans proposer de solution générale.

Un risque peu connu : les hallucinations de packages. Une étude de 2025 montre que la quantization 4 bits augmente significativement le taux d’hallucination de noms de packages logiciels dans les tâches de génération de code — les modèles quantizés inventent davantage de bibliothèques inexistantes ou vulnérables. Ce risque n’est pas couvert par les benchmarks standards de perplexité.

L’outillage

Pour déployer un modèle quantizé, plusieurs outils s’imposent selon l’usage :

  • llama.cpp — inférence CPU/GPU en C++, format GGUF, multi-plateforme. Standard de facto pour le déploiement local.
  • bitsandbytes — librairie PyTorch pour charger des modèles en NF4/INT8 à la volée. Indispensable pour QLoRA et le fine-tuning sur GPU consommateur.
  • vLLM — serving GPU haute performance, supporte FP8, GPTQ, AWQ, NVFP4. Intégration directe de LLM Compressor (Red Hat).
  • TensorRT-LLM (NVIDIA) — optimisation pour déploiement datacenter, FP8/NVFP4 sur Hopper et Blackwell. Open-source depuis janvier 2025.
  • ExecuTorch (Meta) — runtime edge, disponibilité générale octobre 2025, 50 Ko de base, supporte plus de 80 % des LLMs edge disponibles sur HuggingFace.

Les questions ouvertes

PTQ vs QAT à grande échelle. QAT est supérieur en qualité mais son coût reste prohibitif au-delà de 70B paramètres. Un pipeline hybride PTQ→QAT est en émergence mais non standardisé.

Quantization des modèles MoE. Depuis début 2025, plus de 60 % des modèles frontière utilisent une architecture Mixture of Experts. La quantization de ces modèles soulève des questions spécifiques — experts actifs vs inactifs — peu documentées dans la littérature.

Impact sur la sécurité. L’effet de la quantization sur les propriétés d’alignement, les guardrails RLHF et la résistance au jailbreak est presque inexploré. Un seul article récent (arXiv:2502.15799) traite le sujet ; ses conclusions ne sont pas encore répliquées.

Métriques d’évaluation. La perplexité est le proxy dominant mais insuffisant. Il n’existe pas de benchmark unifié post-quantization couvrant codage, STEM, sécurité et hallucination. C’est un angle mort structurel des comparaisons publiées.

Ce qu’il faut retenir

  • La quantization réduit la précision des poids (FP16 → INT8 → INT4) pour diminuer la mémoire et accélérer l’inférence.
  • INT8 et FP8 offrent une compression 2× avec une dégradation négligeable. INT4 offre 4× avec une dégradation modérée mais acceptable dans la majorité des usages.
  • PTQ (post-training) domine en pratique ; QAT est supérieur mais réservé aux petits modèles ou aux équipes avec ressources de fine-tuning.
  • GPTQ et AWQ sont les méthodes PTQ de référence ; AWQ est généralement plus précis. GGUF/llama.cpp est le standard pour l’inférence locale sur CPU.
  • Les modèles <7B, les tâches de codage et la génération de code sont plus sensibles à la dégradation que ce que les benchmarks standards montrent.
  • L’impact sur la sécurité et l’alignement reste une zone grise : peu étudié, potentiellement non négligeable.

Sources

  1. arXiv:2409.11055 — Survey quantization LLM 2024 — https://arxiv.org/pdf/2409.11055
  2. Cast AI — LLM Quantization Methods: GPTQ, AWQ, GGUF — https://cast.ai/blog/demystifying-quantizations-llms/
  3. BentoML — LLM quantization handbook — https://bentoml.com/llm/getting-started/llm-quantization
  4. IJCAI 2025 — Quantization Methods, Task Difficulty, and Model Size — https://www.ijcai.org/proceedings/2025/0902.pdf
  5. AWS Blog — GPTQ and AWQ on SageMaker AI — https://aws.amazon.com/blogs/machine-learning/accelerating-llm-inference-with-post-training-weight-and-activation-using-awq-and-gptq-on-amazon-sagemaker-ai/
  6. HuggingFace Blog — bitsandbytes 4-bit + QLoRA — https://huggingface.co/blog/4bit-transformers-bitsandbytes
  7. arXiv:2305.14314 — QLoRA: Efficient Finetuning of Quantized LLMs — https://arxiv.org/abs/2305.14314
  8. NVIDIA Blog — Introducing NVFP4 — https://developer.nvidia.com/blog/introducing-nvfp4-for-efficient-and-accurate-low-precision-inference/
  9. Red Hat — vLLM FP8 inference open source — https://developers.redhat.com/articles/2024/07/15/vllm-brings-fp8-inference-open-source-community
  10. Baseten — 33% faster LLM inference with FP8 — https://www.baseten.co/blog/33-faster-llm-inference-with-fp8-quantization/
  11. PyTorch — QAT for LLMs — https://pytorch.org/blog/quantization-aware-training/
  12. arXiv:2411.06084 — PTQ vs QAT comparative analysis — https://arxiv.org/pdf/2411.06084
  13. arXiv:2401.06118 — AQLM: Extreme Compression via Additive Quantization — https://arxiv.org/html/2401.06118v2
  14. arXiv:2211.10438 — SmoothQuant — https://arxiv.org/pdf/2211.10438
  15. GitHub — ggml-org/llama.cpp — https://github.com/ggml-org/llama.cpp
  16. arXiv:2502.15799 — Quantization and LLM safety/reliability — https://arxiv.org/html/2502.15799v1
  17. arXiv:2512.08213 — Package hallucinations in quantized LLMs — https://arxiv.org/html/2512.08213
  18. arXiv:2511.13023 — SLMQuant: Small LM quantization benchmarking — https://arxiv.org/html/2511.13023v1
  19. Red Hat — AutoRound x LLM Compressor — https://developers.redhat.com/articles/2025/12/09/advancing-low-bit-quantization-llms-autoround-x-llm-compressor
  20. ACL 2025 — Low-Bit Quantization Favors Undertrained LLMs — https://aclanthology.org/2025.acl-long.1555.pdf