Magazine LLM Opensource · 31 October 2026Quantification des LLM open source en 2026 : GGUF, AWQ, GPTQ, FP8, NVFP4 — le guide pour choisir (et ne pas se tromper de chiffres)
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, EXL2, MLX, FP8 et NVFP4, comment choisir ? Ce comparatif de fond décortique les mécanismes, les chiffres et les cas d’usage pour vous aider à trancher — en distinguant systématiquement ce qui est mesuré, ce qui est rapporté par un éditeur, et ce qui relève du marketing.
140 Go en FP16, 35-42 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 le 28 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 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 autour de 42 Go en GGUF Q4_K_M — un chiffre que confirment aussi bien le guide de Cast AI que celui d’Ayinedjimi Consultants. 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-training quantization (PTQ) — la quantification appliquée après l’entraînement, sans toucher aux poids originaux — réduit l’empreinte d’un facteur 2 à 8 selon le format cible. 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 — et de ne pas confondre un format conteneur avec un algorithme, erreur que la documentation de vLLM elle-même entretient en listant GGUF parmi ses options de quantification, comme le relève Cast AI.
En 2026, la quantification est d’autant plus cruciale que les modèles open source récents poussent la démesure. DeepSeek V4, sorti le 24 avril 2026, atteint 1,6 trillion de paramètres (49 milliards actifs en MoE) ; Kimi K3 dépasse les 2,8 trillions ; Qwen3.8-Max, dévoilé le 3 août 2026, 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.
La vague d’octobre 2026 a d’ailleurs donné un nom au problème : « 816B, 560B, 120B en un jour : la vague open-weight se heurte désormais à un mur de mémoire », titrait the-agent-report.com le 16 octobre. Le cas d’école est Muse Spark Open, publié par Meta le 15-16 octobre 2026 : 816 milliards de paramètres totaux, 42 milliards actifs par token, un contexte d’un million de tokens, et un déploiement mis en avant sur des Mac Studio M5 Ultra — donc sur mémoire unifiée, pas sur VRAM discrète. Le billet de recherche de Meta insiste sur le BF16 contre NVFP4, c’est-à-dire sur le choix du format de compression comme paramètre de déploiement à part entière. Sans quantification, un modèle de cette taille ne tient sur aucune machine que possède un particulier.
Le cas de GLM-5.3, sorti le 14 août 2026 par Z.ai, illustre une autre 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é. Autrement dit : à gabarit constant, c’est le post-entraînement qui fait la différence — et à l’inférence, c’est la quantification qui rend le gabarit exploitable. Les frameworks comme vLLM, SGLang ou llm-d (dont la version 1.0 a été présentée le 20 octobre 2026 à la PyTorch Conference North America) intègrent ces formats nativement.
Un dernier élément de contexte, souvent négligé : « poids ouverts » ne veut pas dire « open source ». La plupart de ces modèles publient des poids téléchargeables sous licence restrictive, sans le code d’entraînement ni les données — un point que nous détaillons dans notre dossier sur les licences, et qui conditionne aussi ce que vous avez le droit de faire d’un modèle quantifié, redistribué ou servi derrière une API.
Trois philosophies de compression (et deux outsiders) : GGUF, AWQ, GPTQ, EXL2, MLX
Il faut d’abord lever une confusion fréquente, que Cast AI souligne explicitement : 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. Les comparatifs 2026 de MarkTechPost et de Digital Applied ajoutent deux formats que les guides de 2024 ignoraient encore : EXL2 (ExLlamaV2) et MLX (Apple Silicon).
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. Le guide pratique de Stéphane Robert montre d’ailleurs que l’on peut reproduire tout le pipeline GGUF — conversion d’un modèle Hugging Face en GGUF 16 bits, puis quantification vers un format compact — sur un simple poste CPU, avec un petit modèle comme Qwen2.5-1.5B-Instruct.
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. Cast AI la présente comme une amélioration directe de GPTQ, avec un double bénéfice revendiqué : meilleure exactitude et inférence plus rapide.
Les chiffres de vitesse, eux, sont désormais mesurés et recoupés. Sur un benchmark Mistral 7B exécuté sur une A100 80 Go, AWQ complète l’inférence en 4,96 secondes contre 8,78 secondes pour GPTQ — un écart considérable pour les charges sensibles à la latence, rapporte Cast AI. En revanche, le fameux chiffre d’une réduction de la pénalité de perplexité INT4 « de 4,57 à 1,17 » que l’on trouve dans certains comparatifs provient d’une source unique non recoupée : nous le laissons de côté plutôt que de le présenter comme un fait établi. Ce qui est solidement établi, c’est 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. Historiquement, GPTQ (W4A16) a été la première méthode à compresser des LLM en 4 bits ; en pratique, c’est un standard pour l’inférence serveur sur GPU NVIDIA, souvent via vLLM ou TGI.
EXL2 et MLX : les deux outsiders devenus sérieux. EXL2, le format d’ExLlamaV2, se distingue par sa granularité : il autorise des bits par poids non entiers (2,5, 3,5, 4,5 bpw), ce qui permet de viser exactement la taille qui rentre dans votre VRAM disponible plutôt que de choisir dans une gamme discrète. C’est le format préféré de ceux qui « bricolent » au bit près sur GPU NVIDIA. MLX, de son côté, est le format natif du framework Apple pour Apple Silicon : il exploite la mémoire unifiée des Mac, ce qui en fait le choix évident pour faire tourner un modèle de plusieurs centaines de milliards de paramètres actifs sur un Mac Studio — exactement le scénario mis en avant par Meta pour Muse Spark Open. Ces deux formats ne remplacent pas GGUF/AWQ/GPTQ : ils couvrent des niches matérielles que les trois grands traitent mal.
Le traitement des outliers distingue nettement les 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 ; pour ceux qui veulent tenir au bit près, EXL2 ; pour les Mac, MLX.
Au-delà du 4-bit : ternaire, dynamique, FP8, NVFP4 — les pistes qui montent
Le 4-bit est devenu le standard de fait, mais la course à la compression ne s’arrête pas là. Quatre 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, QAT), et la PTQ vers le ternaire dégrade fortement les performances. Cast AI le formule sans détour : le QAT donne une meilleure exactitude à 4 bits et en dessous, mais exige un entraînement complet. 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 et le KV-cache. 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. À noter que DeepSeek V4.1 Flash, présenté le 10 septembre 2026, met en avant un KV-cache nettement réduit grâce à son architecture Causal Encoder Decoder — signe que la compression du cache devient un argument produit à part entière.
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.
Le NVFP4, le nouveau venu qui compte. C’est peut-être le changement le plus significatif de l’année, et il vient du matériel plus que des algorithmes. Le NVFP4 est un format 4 bits à virgule flottante introduit avec les GPU Blackwell de NVIDIA, qui combine la compacité de l’INT4 et une plage dynamique de type flottant. Meta l’a explicitement mis en avant pour Muse Spark Open, en le comparant au BF16 dans sa documentation de déploiement. Concrètement, NVFP4 permet de faire tourner un modèle de 816 milliards de paramètres (42 milliards actifs) sur du matériel Blackwell avec une dégradation de qualité revendiquée comme faible — là où un INT4 classique aurait été plus brutal. La nuance importante : NVFP4 est lié au matériel. Sur une carte antérieure à Blackwell, il n’apporte aucun gain de vitesse, même s’il reste lisible. C’est le rappel que Cast AI martèle : le support matériel détermine quels types de quantification accélèrent réellement l’inférence, et tous les GPU ne supportent pas nativement tous les formats.
Benchmarks 2026 : ce que disent vraiment les chiffres
Parlons chiffres — mais avec méthode. La matière disponible en 2026 est riche en affirmations, plus pauvre en données brutes recoupées. Voici ce que l’on peut établir avec une confiance raisonnable, et ce qu’il faut prendre avec des pincettes.
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, autour de 42 Go en GGUF Q4_K_M. Ces chiffres sont cohérents entre les sources consultées (Cast AI, Ayinedjimi Consultants, blog.stephane-robert.info). Attention toutefois à une erreur répandue dans certains comparatifs : le passage de FP32 à 4 bits divise par 8, pas par 4 — c’est le passage de FP16 à 4 bits qui divise par 4. Les deux formulations circulent ; la seconde est la bonne pour un modèle publié en BF16/FP16.
Vitesse. Le seul chiffre de latence solidement recoupé dont nous disposons est celui de Cast AI sur Mistral 7B / A100 80 Go : 4,96 s pour AWQ contre 8,78 s pour GPTQ. C’est un écart d’environ 43 % en faveur d’AWQ sur cette configuration précise — à ne pas généraliser à tous les modèles ni à tous les GPU, mais qui donne un ordre de grandeur. Les débits annoncés par les éditeurs (Mercury 3 et ses 1 000+ tokens par seconde, par exemple) relèvent d’architectures de diffusion, pas de la quantification, et ne doivent pas être mélangés à ce comparatif.
Qualité. Les sources s’accordent sur la hiérarchie générale : à 4 bits, AWQ et GPTQ sont proches, AWQ légèrement devant en exactitude et nettement devant en vitesse sur GPU NVIDIA ; GGUF Q4_K_M est un cran en dessous en perplexité mais reste excellent en pratique ; Q5_K_M et Q6_K sont quasi lossless. En dessous de 4 bits (3 bits, 2 bits), la dégradation devient visible sur les tâches de raisonnement long et de code, même si elle reste tolérable sur de la génération courte. Le QAT reste la seule voie pour descendre bas sans s’effondrer — au prix d’un entraînement.
Ce qu’il faut retenir sur la méthode. Trois pièges reviennent dans les comparatifs 2026. Premièrement, la perplexité seule ne prédit pas la qualité perçue : un modèle peut avoir une perplexité quasi identique et se comporter très différemment sur du code ou des mathématiques. Deuxièmement, les benchmarks de vitesse dépendent du GPU, du batch size et du framework : un chiffre AWQ vs GPTQ sur A100 ne se transpose pas à une RTX 4090. Troisièmement, la vérification d’intégrité des modèles compressés est un enjeu de sécurité à part entière — un fichier GGUF ou safetensors quantifié circule facilement, et rien ne garantit a priori qu’il provient bien de l’éditeur d’origine. Le guide d’Ayinedjimi Consultants insiste sur ce point : la chaîne de confiance des poids quantifiés est un risque opérationnel réel.
Choisir en pratique : un arbre de décision
Assez de théorie. Voici comment trancher, selon votre matériel et votre usage.
Vous êtes sur un laptop, un mini-PC ou un CPU seul. GGUF, sans hésiter. Les K-quants Q4_K_M ou Q5_K_M offrent le meilleur rapport taille/qualité, et le mode mixte CPU+GPU de llama.cpp permet d’exploiter la moindre parcelle de VRAM disponible. Ollama et LM Studio rendent l’opération triviale.
Vous êtes sur une RTX grand public (24 Go ou moins). Pour un modèle qui tient entièrement en VRAM, AWQ ou GPTQ en 4 bits sont les meilleurs choix : plus rapides que GGUF à taille égale sur GPU NVIDIA, et compatibles vLLM. Si le modèle déborde, GGUF avec offload CPU reste la solution. EXL2 vaut le détour si vous voulez viser exactement votre limite de VRAM.
Vous êtes sur un Mac (Apple Silicon). MLX est le format natif, et c’est celui qui exploite le mieux la mémoire unifiée. GGUF fonctionne aussi très bien via llama.cpp, mais MLX est généralement plus rapide sur les puces M-series récentes. Pour les très gros modèles (Muse Spark Open et ses 816 milliards de paramètres), c’est la seule voie réaliste sur un poste de travail Apple.
Vous êtes en production serveur sur NVIDIA Hopper/Blackwell. AWQ ou GPTQ en 4 bits pour maximiser la densité, FP8 si la stabilité et le fine-tuning priment, NVFP4 si vous êtes sur Blackwell et que vous voulez le meilleur compromis compacité/qualité sur les très gros modèles. vLLM, SGLang et désormais llm-d 1.0 (Kubernetes-native, présenté le 20 octobre 2026) supportent ces formats.
Vous voulez fine-tuner. Oubliez la quantification des poids pour l’entraînement : on fine-tune en BF16 ou en FP8, puis on quantifie pour le déploiement. Le QAT (quantization-aware training) n’a de sens que si vous ciblez du 4 bits ou moins en production et que vous acceptez le coût d’un entraînement complet.
Vous déployez sur TPU. Nouveauté d’octobre 2026 : Google a publié le 20 octobre des versions TPU de vLLM et SGLang. Les formats de quantification disponibles sur TPU restent plus restreints que sur GPU NVIDIA, mais l’écosystème s’ouvre — un point à surveiller si vous êtes sur Google Cloud.
Le mot de la fin : la quantification n’est plus un détail
Il y a trois ans, la quantification était un bricolage de passionnés pour faire tenir un 7B sur une carte de jeu. En 2026, c’est devenu une discipline d’ingénierie à part entière, avec ses formats standardisés, ses benchmarks, ses pièges et ses enjeux de sécurité. La vague open-weight d’octobre 2026 — 816B, 560B, 120B publiés en quelques jours — a rendu la question incontournable : aucun de ces modèles n’est exploitable sans une stratégie de compression réfléchie.
La bonne nouvelle, c’est que l’outillage a suivi. GGUF pour la portabilité, AWQ et GPTQ pour la performance GPU, EXL2 pour le réglage fin, MLX pour Apple, FP8 et NVFP4 pour le matériel de dernière génération : chaque besoin a sa réponse. La mauvaise nouvelle, c’est que les chiffres circulent plus vite que les vérifications, et qu’un comparatif mal sourcé peut vous faire choisir le mauvais format pour votre infrastructure. La règle reste la même qu’en 2024 : mesurez sur votre matériel, avec votre modèle, sur vos tâches. La quantification est un compromis, et aucun tableau ne remplacera un test sur votre propre machine.
Sources
- Cast AI — Demystifying Quantizations of LLMs (guide de référence, distinction format/algorithme, benchmark Mistral 7B AWQ vs GPTQ sur A100)
- Ayinedjimi Consultants — Guide complet Quantization LLM 2026 : GGUF, GPTQ, AWQ (facteurs de compression, risques de sécurité, méthodologie)
- MarkTechPost — GGUF vs GPTQ vs AWQ vs EXL2: LLM Model Formats Explained (2026)
- Digital Applied — GGUF vs AWQ vs GPTQ vs MLX: LLM Quant Formats 2026
- PremAI — LLM Quantization Guide: GGUF vs AWQ vs GPTQ vs bitsandbytes Compared (2026)
- Lyceum — GGUF vs GPTQ vs AWQ: 2026 LLM Quantization Guide
- DasRoot — GGUF vs GPTQ vs AWQ: LLM Quantization Methods Compared
- Stéphane Robert — Quantification pratique d’un LLM
- Meta Research — Introducing Muse Spark Open (816B MoE, 42B actifs, 1M de contexte, BF16 vs NVFP4, déploiement Apple M5 Ultra)
- The Agent Report — 816B, 560B, 120B en un jour : la vague open-weight se heurte à un mur de mémoire (16 octobre 2026)
- Unite.ai — llm-d 1.0 Debuts at PyTorch Conference with Production Inference Stack (20 octobre 2026)
- Note.com — vLLM et SGLang passent au TPU (20 octobre 2026)
- DTS Conseil — Open weights : ce que Kimi K3 change vraiment pour vous (distinction open weights / open source, rapport technique Kimi K3 du 28 juillet 2026)
Article recherché et rédigé automatiquement · Magazine Electrosens