Magazine LLM Opensource · 6 September 2026

Quantification des LLM en 2026 : GGUF, AWQ, GPTQ, FP8 — le guide complet pour faire tourner des modèles de 100 milliards sur du matériel accessible

Un modèle de 70 milliards de paramètres pèse 140 Go en FP16 — trop pour une seule carte grand public. La quantification est devenue le passage obligé pour faire tourner les LLM open source sur du matériel accessible. Mais entre GGUF, AWQ, GPTQ et les méthodes émergentes, comment choisir ? Ce comparatif de fond décortique les mécanismes, les chiffres et les cas d’usage pour vous aider à trancher.

140 Go en FP16, 40 Go en 4-bit : la quantification, sésame des LLM de 100 milliards

L’open source a franchi un cap que peu imaginaient il y a trois ans. Les modèles de plus de 100 milliards de paramètres ne sont plus des exceptions : Kimi K3, présenté par Moonshot AI en juillet 2026 comme le plus grand modèle open source jamais développé, en est l’illustration la plus récente. Mais cette démesure a un prix — littéralement. Un modèle de 70B de paramètres stocké en FP16 (2 octets par paramètre) exige environ 140 Go de VRAM. Pour un 13B, comptez environ 26 Go. Autrement dit, même les cartes les plus généreuses du marché grand public — les 24 Go d’une RTX 4090 — plafonnent rapidement.

C’est ici que la quantification entre en scène. Le principe est simple : réduire la précision numérique des poids du modèle pour compresser son empreinte mémoire. En passant de 16 bits à 4 bits par paramètre, on divise la taille par quatre. Un 70B passe ainsi de 140 Go à environ 35-40 Go en AWQ ou GPTQ, et 40-45 Go en GGUF Q4_K_M. Soudain, un déploiement qui exigeait deux A100 80 Go ou quatre RTX 4090 devient envisageable sur une seule carte professionnelle, voire sur du matériel grand public pour les modèles plus petits.

La post-quantization training (PTQ) — la quantification appliquée après l’entraînement, sans toucher aux poids originaux — réduit l’empreinte d’un facteur 2 à 4. C’est devenu le levier n°1 pour les praticiens : pas besoin de réentraîner, pas besoin de données massives, juste un peu de calibration et un format adapté. Mais toutes les méthodes ne se valent pas, et le choix d’une approche plutôt qu’une autre conditionne la qualité, la vitesse et la compatibilité matérielle. D’où l’importance de comprendre ce qui se cache derrière les acronymes.

En 2026, la quantification est d’autant plus cruciale que les modèles open source récents poussent la démesure : DeepSeek V4-Pro atteint 1,6 trillion de paramètres (49 milliards actifs en MoE), Kimi K3 dépasse les 2,8 trillions, et Qwen 3.8 joue dans la même cour avec son architecture de 2,4 trillions de paramètres (95 milliards actifs). Même les modèles « compacts » comme Muse Glimmer de Meta (30B, publié le 10 août 2026 sous licence Apache 2.0) sont pensés pour tourner sur 24 Go de VRAM — une contrainte qui n’est tenable que grâce à la quantification. Sans elle, aucun de ces modèles ne serait exécutable sur du matériel grand public.

Le cas de GLM-5.3, sorti le 14 août 2026 par Z.ai, illustre parfaitement cette dynamique : ce modèle de 753 milliards de paramètres (architecture MoE) n’apporte aucun nouveau paramètre par rapport à GLM-5.2 — il réutilise la même base et n’a été amélioré que par post-entraînement. Pourtant, il talonne Kimi K3 au sommet des classements open source, notamment sur le code et la cybersécurité. La quantification est ce qui rend ces modèles exploitables en conditions réelles, et les frameworks d’inférence comme vLLM l’intègrent nativement.

Trois philosophies de compression : GGUF, AWQ, GPTQ décortiqués

Il faut d’abord lever une confusion fréquente : GGUF n’est pas un algorithme, c’est un format conteneur — celui de llama.cpp et de son écosystème (Ollama, LM Studio). AWQ et GPTQ sont des algorithmes de quantification dont les poids sont stockés en safetensors, le format standard de Hugging Face. Cette distinction n’est pas anodine : elle détermine l’écosystème d’outils et de runtimes compatibles.

GGUF et les K-quants : la précision mixte pragmatique. Le format GGUF a popularisé les K-quants, une approche de précision mixte intra-modèle. L’idée est simple : tous les tenseurs d’un modèle ne contribuent pas également à la qualité finale. Les couches d’attention, plus sensibles, sont quantifiées en bits plus élevés (Q6_K, Q5_K_M), tandis que les couches feed-forward, plus tolérantes, descendent en bits plus faibles (Q4_K_M, Q3_K_S). Cette calibration est empirique : elle repose sur des tests de perplexité sur des corpus de référence, et chaque variante (Q4_K_M, Q5_K_M, Q6_K…) représente un point d’équilibre entre taille et qualité. Les i-quants (IQ) poussent la logique plus loin avec des formats encore plus agressifs, souvent couplés à des techniques de regroupement de scalaires. Le résultat est une gamme très fine de compromis, du presque-lossless au très compressé.

La force de GGUF reste sa portabilité : il tourne sur CPU, sur GPU grand public, sur Apple Silicon, et en mode mixte CPU+GPU où certaines couches résident en VRAM et le reste déborde en RAM système. C’est le format par défaut d’Ollama, LM Studio et llama.cpp — de loin le plus utilisé par les praticiens locaux.

AWQ et la protection des activations. L’Activation-aware Weight Quantization part d’un constat différent : tous les poids ne sont pas égaux face à la quantification. Certains canaux — ceux qui activent des valeurs aberrantes (outliers) dans les activations — sont critiques pour la qualité. AWQ identifie ces canaux sensibles en analysant les statistiques d’activation sur un petit ensemble de calibration, puis préserve leurs poids en précision plus élevée, tout en appliquant une échelle de quantification adaptée aux autres. C’est une approche dite "activation-aware" : elle ne regarde pas seulement les poids, mais leur comportement en conditions réelles. Les résultats rapportés sont impressionnants : sur un benchmark tiers, AWQ aurait réduit la pénalité de perplexité INT4 de 4,57 à 1,17 par rapport à GPTQ, soit environ 74 % de réduction. Ce chiffre provient d’une source unique non recoupée — prenons-le avec prudence — mais il illustre la direction : AWQ vise à minimiser la dégradation perçue, pas seulement l’erreur mathématique.

GPTQ et la compensation par Hessienne. GPTQ (pour Generalized Post-Training Quantization) adopte une approche plus mathématique. Il minimise l’erreur de reconstruction couche par couche en utilisant une approximation du second ordre — la matrice de Hessienne de la fonction de perte. Concrètement, GPTQ ajuste les poids restants pour compenser l’erreur introduite par la quantification de chaque poids précédent. C’est une méthode de compression "globale" qui vise à préserver la sortie du modèle aussi fidèlement que possible, au prix d’une calibration plus coûteuse en calcul. En pratique, GPTQ est un standard pour l’inférence serveur sur GPU NVIDIA, souvent via vLLM ou TGI.

Le traitement des outliers distingue nettement les trois approches : GGUF les gère par la précision mixte (les couches sensibles restent en haute précision), AWQ par une protection ciblée des canaux critiques, GPTQ par une compensation d’erreur systématique. La calibration, elle, varie : GGUF est quasi sans calibration (les K-quants sont prédéfinis), AWQ nécessite quelques centaines d’échantillons d’activation, GPTQ demande un peu plus de données et de calcul. Pour les praticiens pressés, GGUF est le plus simple ; pour ceux qui veulent le meilleur compromis qualité/taille, AWQ et GPTQ offrent plus de contrôle.

Au-delà du 4-bit : ternaire, dynamique, FP8, les pistes qui montent

Le 4-bit est devenu le standard de fait, mais la course à la compression ne s’arrête pas là. Trois directions émergent en 2026, chacune avec ses promesses et ses limites.

Le 1,58-bit ternaire. L’idée est radicale : ne stocker que trois valeurs possibles par poids (-1, 0, +1), soit environ 1,58 bit. Les modèles ternaires (inspirés de BitNet) réduisent drastiquement l’empreinte mémoire et ouvrent la voie à des LLM sur CPU pur ou sur du matériel embarqué très contraint. Mais la qualité reste le talon d’Achille : les modèles ternaires sont souvent entraînés spécifiquement pour ce format (on parle de quantization-aware training), et la PTQ vers le ternaire dégrade fortement les performances. En 2026, le 1,58-bit reste une piste de recherche prometteuse plutôt qu’une solution de production généralisée — sauf pour des cas très spécifiques où la mémoire prime sur tout.

La quantification dynamique. Les méthodes weight-only (poids uniquement) ne compressent que les poids. Or, en inférence, la mémoire est aussi consommée par les activations et le KV-cache — cette mémoire qui stocke les clés et valeurs de l’attention pour chaque token généré. Quantifier dynamiquement le KV-cache à la volée permet de réduire la mémoire totale nécessaire pour de longues conversations, au prix d’une latence légèrement accrue. C’est une approche complémentaire : on combine souvent une quantification statique des poids (AWQ, GPTQ) avec une quantification dynamique du KV-cache pour maximiser la longueur de contexte tenable sur une carte donnée. Les gains sont réels, mais la complexité d’implémentation reste un frein pour les frameworks généralistes.

Le FP8 sur Hopper et Blackwell. Les GPU NVIDIA de dernière génération (H100, H200, B200) supportent nativement le FP8 — un format à virgule flottante sur 8 bits, plus stable que l’INT8 pour certaines opérations. Le FP8 est particulièrement pertinent pour l’entraînement et le fine-tuning, où la plage dynamique est cruciale, et pour l’inférence à très haute performance sur du matériel spécialisé. Mais il reste moins compressé que l’INT4 : un modèle 70B en FP8 pèse environ 70 Go, soit le double d’un INT4. Le FP8 n’est donc pas un concurrent direct de l’INT4 ; c’est un compromis différent, qui privilégie la stabilité et la vitesse sur les GPU récents plutôt que la réduction maximale de mémoire. Sur du matériel Hopper/Blackwell, il peut être le choix idéal pour du serveur haute performance ; sur une RTX grand public, l’INT4 reste plus pertinent.

Benchmarks 2026 : ce que disent vraiment les chiffres

Parlons chiffres — mais avec méthode. La matière disponible en 2026 est riche en affirmations, pauvre en données brutes recoupées. Voici ce que l’on peut établir avec une confiance raisonnable.

Tailles de fichiers. Pour un Llama 3 8B, le poids FP16 avoisine 16 Go ; en GGUF Q4_K_M, il descend à environ 4,5 Go. Pour un modèle 7B, les K-quants donnent : Q4_K_M ~3,8 Go, Q5_K_M ~4,45 Go, Q6_K ~5,15 Go. Les pénalités de perplexité associées sont de +0,0535, +0,0142 et +0,0044 respectivement — des valeurs qui montrent la progressivité du compromis. Pour un 70B, la fourchette 4-bit est de 35-40 Go en AWQ/GPTQ, 40-45 Go en GGUF Q4_K_M. Ces chiffres sont cohérents entre les sources consultées (fungies.io, teqvolt.com, blog.stephane-robert.info).

Qualité. Les sources s’accordent sur une dégradation "imperceptible" à "1-5 %" selon les benchmarks et les modèles. Mais aucun score précis de MMLU-Pro, HumanEval ou IFEval n’est fourni dans les sources fiables — les chiffres circulent sur des blogs, rarement sur des papiers de recherche. La prudence s’impose : les écarts entre blogs et études académiques sont souvent significatifs, car les conditions de test varient (prompts, génération, matériel).

Débits d’inférence. L’affirmation la plus répandue est qu’AWQ et GPTQ surpassent GGUF et bitsandbytes en débit tokens/s pour l’inférence serveur via vLLM et TGI sur RTX 4090 et A100. Le guide pratique de Stéphane Robert, mesuré en lab sur H100, confirme que le choix du format impacte significativement le débit et la VRAM, mais les chiffres exacts dépendent fortement du modèle et de la configuration. Les données récentes sur vLLM (86K étoiles GitHub, développé à UC Berkeley) indiquent que ce moteur d’inférence supporte nativement AWQ, GPTQ, FP8 et même GGUF (expérimental), avec un gain de débit pouvant atteindre 9x par rapport à Ollama sur le même GPU grâce à PagedAttention et au continuous batching. C’est un argument fort pour les déploiements serveur : vLLM est conçu pour la production, avec clustering, monitoring et API compatible OpenAI, là où Ollama reste un gestionnaire de modèles orienté local.

Ce tableau résume l’état de l’art, mais il faut insister : les données GGUF proviennent de sources convergentes (fungies.io, blog.stephane-robert.info), tandis que les tailles AWQ/GPTQ sont des ordres de grandeur rapportés par les praticiens. Pour les modèles massifs de 2026 (DeepSeek V4-Pro, Kimi K3, Qwen 3.8, GLM-5.3), la quantification 4-bit est la seule voie viable sur du matériel accessible — et les frameworks comme vLLM ou SGLang l’intègrent désormais nativement, avec un support FP8 sur les GPU récents.

Le contexte 2026 : des modèles toujours plus gros, une quantification toujours plus indispensable

La sortie de GLM-5.3 le 14 août 2026 a confirmé une tendance lourde : les laboratoires chinois dominent le haut du classement open source, et la quantification est ce qui rend ces modèles utilisables. GLM-5.3, avec ses 753B de paramètres MoE, a grimpé de 4,6 % à 28,3 % sur Terminal-Bench 3.0 grâce au seul post-entraînement, et atteint 84,5 % sur le benchmark cybersécurité CyberGym — devant Claude Sonnet 5 et GPT-5.6 Sol. Mais sans quantification, un tel modèle est inexploitable hors des centres de données.

Muse Glimmer, le modèle agentique 30B de Meta publié le 10 août 2026 sous licence Apache 2.0, illustre l’autre extrémité du spectre : un modèle compact, conçu pour tourner sur 24 Go de VRAM (RTX 5090, MacBook M4 Max), et qui excelle dans le tool-calling et le raisonnement multi-étapes. Ici encore, la quantification joue un rôle clé : même un 30B dense en FP16 pèserait 60 Go, hors de portée du grand public. Les versions quantifiées en GGUF Q4_K_M (~17 Go) ou AWQ 4-bit (~16 Go) le rendent accessible sur une carte grand public.

Enfin, l’écosystème des outils a mûri. vLLM, SGLang et TensorRT-LLM se disputent le marché de l’inférence serveur, chacun avec ses forces : vLLM pour la flexibilité et le support large des formats de quantification, SGLang pour les workloads agentiques complexes, TensorRT-LLM pour la performance maximale sur GPU NVIDIA. Le choix d’un format de quantification ne se fait donc plus isolément : il est dicté par le runtime cible, le matériel disponible et le cas d’usage.

Sources

• Comprendre la quantification des LLM — blog.stephane-robert.info
• DeepSeek et les LLM open source : héberger sa propre IA en 2026 — morgannriu.fr
• vLLM: установка, настройка и оптимизация для продакшена 2026 — n202.ru
• Best Open Source LLM 2026 — codersera.com
• GLM-5.3 : Z.ai domine l’open coding par le seul post-entraînement — the-agent-report.com
• Muse Glimmer : le modèle agentique ouvert de 30B de Meta — contextstudios.ai
• LLM Inference Optimization: vLLM vs TensorRT-LLM vs SGLang — spheron.network

Article recherché et rédigé automatiquement · Magazine Electrosens