LLM auto hébergées · 27 October 2026

EXL3, AWQ, FP8, GGUF : la guerre des formats de quantification se joue (aussi) sur le mauvais terrain

Un praticien qui aligne côte à côte un GGUF Q4_K_M, un AWQ 4 bits et un EXL2 4,0 bpw « à bits égaux » croit mesurer la qualité du format. Il mesure en réalité la qualité de son couple moteur/kernel, la fraîcheur de sa toolchain et la pertinence de son cas d’usage. Voici pourquoi le débat sur la quantification a changé de nature — et comment s’y retrouver en 2026.

Le bit n’est plus le sujet : pourquoi votre format préféré perd la bataille avant même de commencer

Il y a une scène qui se répète sur tous les forums de praticiens : quelqu’un publie un tableau de perplexité avec quatre lignes — GGUF Q4_K_M, AWQ 4 bits, GPTQ 4 bits, EXL2 4,0 bpw — et conclut qu’« AWQ gagne de 0,3 point ». Sauf que dans la même phrase, on ne sait ni quel moteur a servi (llama.cpp ? vLLM ? ExLlamaV2 ?), ni quelle version de kernel, ni sur quel matériel, ni à quel batch. Or c’est précisément là que se logent les écarts. Le format n’est plus qu’une variable parmi d’autres dans une équation système.

La thèse de ce dossier est simple : la guerre des formats de quantification se joue en grande partie sur le mauvais terrain. On continue de la disputer sur le terrain de la perplexité décontextualisée, alors que l’arbitrage réel est un arbitrage système — couplage runtime/format, disponibilité des kernels, coût de conversion, sensibilité du cas d’usage. Un format « meilleur » sur le papier peut être inutilisable dans votre pile ; un format « moyen » peut être le seul à tourner sur votre matériel.

Ce n’est pas une posture intellectuelle. La matière disponible pour 2026 le montre : les guides comparatifs (GGUF vs GPTQ vs AWQ vs EXL2, tests sur 24 Go, guides vLLM) convergent tous vers la même conclusion pratique — le choix du format est principalement déterminé par le moteur d’exécution. GGUF pour llama.cpp/Ollama/LM Studio/KoboldCpp ; GPTQ et AWQ pour les moteurs GPU comme vLLM ; EXL2/EXL3 pour ExLlama ; FP8 côté datacenter. Le format suit le moteur, pas l’inverse.

Nous allons donc dérouler une grille de décision concrète, en croisant la généalogie des formats, leur mécanique interne, la matrice de compatibilité que personne ne publie, l’autopsie des tableaux qui circulent, les signaux terrain (déclin d’EXL3, montée de FP8, verrouillage de GGUF) et la qualité réelle par usage. À la fin, vous saurez pourquoi la vraie bataille se déplace vers l’intégration runtime — et quel critère surveiller désormais.

De GGML à EXL3 : petite chronologie d’une fragmentation par les moteurs, pas par les algorithmes

L’histoire de la quantification des LLM open source est moins une histoire d’algorithmes qu’une histoire de runtimes qui ont chacun enfanté leur format. GGUF n’est pas né d’une percée mathématique : c’est le conteneur mono-fichier créé pour llama.cpp, qui a remplacé l’ancien format GGML en août 2023. Il embarque poids, tokenizer, chat template et métadonnées dans un seul fichier — un choix d’ergonomie locale, pas de performance brute. C’est un fait confirmé par plusieurs guides tiers de 2026.

GPTQ et AWQ, eux, sont des algorithmes de quantification dont la sortie est stockée en safetensors Hugging Face, et qui ciblent les moteurs GPU (vLLM, TGI, ExLlama, GPTQModel/llm-compressor). Ils ne sont pas des formats de fichier au sens de GGUF : ce sont des méthodes qui produisent des tenseurs quantifiés lisibles par des kernels GPU dédiés. La nuance est capitale : on peut « faire de l’AWQ » et le servir dans vLLM, mais on ne peut pas charger un AWQ dans llama.cpp.

EXL2, puis EXL3, sont l’exemple le plus pur du format né d’un moteur unique. EXL2 est un format lié à un seul runtime (ExLlamaV2), ciblant un débit binaire fractionnaire entre 2 et 8 bpw sur un seul GPU NVIDIA. EXL3 est la génération suivante, portée par ExLlamaV3. FP8, enfin, n’est pas un « format de quantification » au sens communautaire : c’est un type natif accéléré par les GPU Hopper (H100), avec moitié de la mémoire du BF16 et une qualité proche du BF16.

Le point que la chronologie rend visible : chaque format naît d’un moteur, pas l’inverse. Et quand un moteur est archivé, le format ne meurt pas forcément — il survit tant qu’un autre moteur le porte. C’est exactement ce qui s’est passé en 2026. ExLlamaV2 est archivé, le développement passe à ExLlamaV3 et EXL3. AutoGPTQ est archivé, HuggingFace indique qu’il n’est plus supporté dans Transformers, et l’implémentation maintenue devient GPTQModel. AutoAWQ est en lecture seule, mais le format AWQ reste vivant et servi quotidiennement par vLLM. Trois archivages, trois sorts différents — et un seul enseignement : le sort d’un format dépend de sa présence dans les runtimes majeurs, pas de sa qualité intrinsèque.

Sous le capot : granularité, calibration et kernels — ce qui différencie vraiment un GGUF Q4_K_M d’un AWQ 4 bits

Pour comprendre pourquoi les comparaisons « à bits égaux » sont trompeuses, il faut descendre d’un niveau. Chaque famille de quantification a sa mécanique propre, et cette mécanique interagit avec un kernel spécifique.

GGUF est un conteneur mono-fichier pour modèles quantifiés, créé pour llama.cpp. Il inclut poids, tokenizer, chat template et métadonnées. Sa quantification repose sur les k-quants — Q4_K_M signifie « 4 bits, K-quant, taille M » — avec une granularité par bloc, et une calibration facultative (imatrix). C’est un point souvent oublié : GGUF n’exige pas de dataset de calibration pour fonctionner, ce qui abaisse drastiquement le coût de production. Les kernels sont ceux de ggml/llama.cpp, multi-backend (Metal, CUDA, HIP, Vulkan, SYCL, CANN, OpenCL, CPU). C’est le seul format à répartir un modèle entre GPU et RAM système — un avantage décisif en local.

GPTQ utilise la Hessienne de la fonction de perte pour trouver la quantification INT4/INT3 optimale par couche, avec un dataset de calibration (typiquement WikiText-2). La calibration est donc requise. Les kernels associés sont ExLlama, Marlin et vLLM.

AWQ (Activation-aware Weight Quantization) préserve environ 1 % des poids les plus importants — sélectionnés selon l’amplitude d’activation — en précision supérieure, et quantifie les 99 % restants en INT4. La calibration est requise. Les kernels sont ceux de vLLM et llm-compressor.

EXL2/EXL3 offrent un débit binaire fractionnaire (2 à 8 bpw) et reposent sur des kernels ExLlama dédiés. C’est le format le plus « couplé » : il n’existe que dans son runtime.

FP8 (E4M3/E5M2) exploite des tenseurs natifs Hopper, avec des kernels vLLM et TensorRT-LLM.

La leçon technique est nette : à bits constants, la granularité (par tenseur, canal, groupe), la présence ou non de calibration et surtout le kernel d’exécution changent le résultat. Un Q4_K_M et un AWQ 4 bits ne font pas le même travail mathématique, et ne sont pas exécutés par le même code. Comparer leurs perplexités sans préciser le kernel revient à comparer deux moteurs de voiture sans dire lequel tourne sur quel circuit.

La matrice de compatibilité que personne ne publie : quel format survit dans quel moteur, en 2026

Voici le tableau que les comparatifs de perplexité oublient systématiquement de publier. C’est pourtant lui qui décide, en pratique, de ce que vous pouvez réellement exécuter.

Ce que la matrice met en évidence, ce sont les trous. Pas d’EXL3 dans vLLM : si vous servez en concurrence, EXL3 est hors jeu, quelle que soit sa vitesse mono-flux. Pas de GGUF performant en serving concurrent : convly.ai le dit explicitement — GGUF est conçu pour l’inférence locale mono-utilisateur, et pour du serving concurrent on privilégie safetensors + vLLM. FP8 hors datacenter reste marginal sur 24 Go, malgré sa présence dans vLLM et TensorRT-LLM.

Autrement dit : un praticien qui choisit son format avant son moteur se condamne à réécrire sa pile. La matrice, pas la perplexité, est le premier document à consulter.

24 Go de VRAM, quatre formats, zéro benchmark propre : autopsie des tableaux comparatifs qui circulent

Passons aux chiffres qui circulent réellement. Ils sont peu nombreux, et leur provenance mérite examen.

• Q4_K_M ≈ 0,6 Go par milliard de paramètres (un Llama 3.1 8B pèse environ 5 Go). Source : convly.ai, guide tiers.
• Un modèle 70B nécessitant 140 Go en BF16 peut tourner en ~40 Go en INT4 (deux RTX 3090). Source : singularitymoments.com.
• AWQ réduirait la pénalité de perplexité INT4 de 4,57 à 1,17 (environ 74 %), et surpasserait GPTQ sur le raisonnement à 4 bits. Source : digitalapplied.com, citant une évaluation de janvier 2026 — sans lien vers l’évaluation originale.
• FP8 = moitié de la mémoire du BF16, qualité proche du BF16. Source : singularitymoments.com.
• Q4_K_M serait le meilleur compromis en 2026 (~4x réduction VRAM vs BF16, <2 % de perte de qualité). Source : singularitymoments.com.

Que remarque-t-on ? D’abord, que ces chiffres proviennent de blogs tiers, sans spécification de moteur, sans version de kernel, sans date de mesure ni matériel homogène. Ensuite, que le fameux « 4,57 → 1,17 » est un chiffre unique, non recoupé, sans protocole. Enfin, qu’aucune source ne fournit de tableau reproductible comparant, pour un même modèle, GGUF Q4_K_M/Q5_K_M/Q8_0, AWQ 4 bits, GPTQ 4 bits, EXL2 4,0/4,5 bpw et FP8 sur un matériel donné (RTX 3090/4090 24 Go) avec version de kernel et date.

La conséquence est directe : les divergences qualité/débit que l’on observe entre tableaux s’expliquent d’abord par le kernel et le batch, pas par l’algorithme de quantification. Un même AWQ 4 bits peut afficher des tokens/s très différents selon qu’il tourne sous vLLM avec Marlin ou sous une version antérieure du même moteur. Publier un tableau sans ces métadonnées, c’est publier un résultat non falsifiable — et donc inutilisable pour décider.

EXL3 recule, FP8 déborde du datacenter : les signaux terrain que les benchmarks ignorent

Au-delà des chiffres, il y a les signaux faibles — ceux qui annoncent les recompositions avant qu’elles ne soient mesurables. Il faut ici distinguer ce qui est documenté de ce qui reste rumeur de forum.

Ce qui est documenté. ExLlamaV2 est archivé, le développement passe à ExLlamaV3 et EXL3. AutoGPTQ est archivé, remplacé par GPTQModel. AutoAWQ est en lecture seule, mais AWQ reste servi quotidiennement par vLLM. GGUF est verrouillé comme standard de fait du local, avec la plus large couverture matérielle. FP8 est le format natif des H100, avec moitié de la mémoire du BF16.

Ce qui reste à qualifier. Le « déclin d’EXL3 dans les discussions LocalLLaMA » et son « adoption par les UIs » ne sont étayés, dans la matière disponible, par aucune source primaire : pas de posts Reddit datés, pas de numéros d’issues GitHub, pas de fréquence de commits, pas de dates d’adoption/rejet par TabbyAPI, LM Studio ou text-generation-webui. Il faut donc le traiter comme une tendance plausible mais non documentée à ce stade — et non comme un fait établi.

Ce que l’on peut affirmer sans risque, en revanche, c’est le mécanisme : le sort d’un format dépend désormais de sa présence dans les runtimes majeurs. EXL3 reste présenté comme le chemin le plus rapide en mono-flux sur un seul GPU NVIDIA lorsque le modèle tient en VRAM (source non vérifiée, d-central.tech) — mais s’il n’est pas dans vLLM, il ne participe pas au serving concurrent. AWQ et GPTQ, portés par vLLM et les chaînes llm-compressor/GPTQModel, survivent à l’archivage de leurs outils d’origine. GGUF, porté par tout l’écosystème local, est intouchable. FP8, porté par Hopper et les serveurs, déborde progressivement vers les GPU récents.

La règle est presque darwinienne : un format survit tant qu’un moteur majeur le porte. L’archivage d’un outil n’est pas la mort du format ; l’absence d’un moteur est la mort certaine.

Code, agentique, long contexte : le bon format change avec le cas d’usage, pas avec le nombre de bits

La vraie question n’est pas « quel format est le meilleur », mais « quel format pour quel usage ». Voici comment décliner la qualité réelle.

Génération de code. La sensibilité aux erreurs de quantification porte sur les tokens rares — identifiants, symboles, structures syntaxiques peu fréquentes. Un format qui préserve les poids saillants (AWQ) ou qui dispose d’une calibration soignée (GPTQ) a un avantage théorique. Mais sans benchmark HumanEval reproductible par format et par moteur dans la matière disponible, il faut rester prudent : la recommandation est de tester sur votre codebase, pas de se fier à un classement universel.

Workflows agentiques. Tool calling, JSON strict, respect du template : ici, GGUF a un avantage structurel documenté — il embarque le chat template dans le fichier, ce qui élimine une classe entière de bugs de formatage. Pour un agent local, c’est souvent plus décisif que 0,2 point de perplexité.

Long contexte. La dégradation des schémas de quantification et le coût du KV cache deviennent dominants. FP8 et EXL3 sont en pointe sur GPU unique, mais les données manquent pour trancher entre eux sur des contextes très longs. Là encore, la recommandation est conditionnelle.

Le fil rouge : fournir des recommandations conditionnelles plutôt qu’un classement universel. Le bon format change avec le cas d’usage, pas avec le nombre de bits.

Le coût caché de la conversion : temps de calibration, reproductibilité et dette de toolchain

Le « format gratuit » n’existe pas. Chaque choix de quantification a un coût de production, et ce coût est souvent invisible dans les comparatifs.

GPTQ et AWQ requièrent une calibration : dataset (WikiText-2 pour GPTQ), GPU-heures, reproductibilité. GGUF n’exige pas de calibration (imatrix facultative), ce qui abaisse le coût — mais impose de choisir un niveau k-quant parmi Q2_K à Q8_0, avec des compromis différents. EXL2/EXL3 nécessitent une calibration (non détaillée dans les extraits disponibles) et un runtime dédié.

À cela s’ajoute la dette de toolchain. AutoGPTQ et AutoAWQ sont archivés ou en lecture seule ; les chaînes maintenues sont GPTQModel et llm-compressor. Un praticien qui a bâti son pipeline sur AutoAWQ doit migrer. Et à chaque nouveau modèle, il faut re-quantifier — avec la toolchain du moment, pas celle d’il y a deux ans.

La vraie économie ne se joue donc pas sur les Go de VRAM gagnés, mais sur la maintenance de la chaîne de production. Un format qui économise 2 Go de VRAM mais exige une re-quantification mensuelle coûte plus cher qu’un format légèrement moins efficace mais produit en une commande.

Grille de décision 2026 : choisir son format en fonction de son moteur, de son matériel et de son usage — et ce que la prochaine bataille va déplacer

Voici la synthèse actionnable, sous forme d’arbre de décision.

L’ouverture, maintenant. La bataille des formats se déplace vers l’intégration runtime : kernels fusionnés, formats natifs matériels, serving unifié. Windows ML ajoute un support expérimental de llama.cpp pour les modèles GGUF et une API locale compatible OpenAI (octobre 2026) ; llama.cpp passe en v0.5.0 (septembre 2026) avec des changements de backend, de modèle et de serveur. Ces évolutions comptent plus que n’importe quel tableau de perplexité, parce qu’elles déterminent ce qui tourne.

Le critère à surveiller n’est donc plus la perplexité. C’est le commit. Un format vit tant qu’un moteur majeur le porte ; il meurt quand le dernier moteur cesse de le lire. La guerre des formats se joue sur le terrain de l’intégration runtime — et c’est là qu’il faut désormais regarder.

Sources

• GGUF vs GPTQ vs AWQ vs EXL2: LLM Model Formats Explained (2026)
• GGUF vs AWQ vs GPTQ vs FP8: Tested on 24GB
• Modèles GGUF : types de quantification et exécution (convly.ai, 9 septembre 2026)
• Quantization formats GGUF, GPTQ, AWQ — guide (arte.itlibra.com)
• Model quantization in 2026: from foundations to production serving (slavadubrov.github.io, 5 juillet 2026)
• Guide vLLM (quelllm.fr)
• Glossaire GGUF (polydesk.ai)
• GGUF format: a complete guide (datacamp.com)
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API (gyanaangan.in, 27 septembre 2026)
• Windows ML: 2026 Updates for GGUF Models and Local AI (techgenyz.com, 9 octobre 2026)
• AI Development on Windows: from PyTorch and llama.cpp to Windows ML (Microsoft Foundry on Windows Blog, 7 octobre 2026)
• Moteurs d’inférence et runtimes locaux : comparatif 2026 (promptquorum.com, 20 septembre 2026)
• Faire tourner une IA en local en 2026 : guide complet (briefia.fr, 18 septembre 2026)

Note de transparence : les chiffres de perplexité AWQ (4,57 → 1,17) et les affirmations sur le déclin d’EXL3 dans les discussions LocalLLaMA proviennent de sources tierces non recoupées par une étude primaire et sont signalés comme tels dans le corps de l’article.

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