LLM auto hébergées · 28 October 2026

GGUF, AWQ, GPTQ, EXL2, FP8, NVFP4 : quel format de quantification pour faire tourner un LLM open-weight chez soi en 2026

En 2026, faire tourner un modèle open-weight chez soi ne se joue plus seulement sur le choix du modèle, mais sur celui du format de quantification — et sur le couple format/moteur qui va avec. GGUF, AWQ, GPTQ, EXL3, FP8, NVFP4 : derrière ces acronymes se cachent des compromis très concrets entre vitesse, qualité, compatibilité et dépendance matérielle. Voici comment s’y retrouver sans se ruiner.

Pourquoi la quantification est devenue le champ de bataille de l’IA locale en 2026

Il y a une ironie cruelle dans l’IA locale de 2026. Jamais les modèles open-weight n’ont été aussi capables — des MoE de plusieurs centaines de milliards de paramètres, des contextes étendus, des agents autonomes — et jamais les GPU grand public n’ont semblé aussi à l’étroit. Une carte consumer plafonne toujours à 8, 16 ou 24 Go de VRAM, quand un modèle 70B en pleine précision réclame environ 140 Go. L’écart n’est pas un détail d’ingénierie : c’est le mur contre lequel vient buter quiconque veut posséder son IA plutôt que la louer.

La quantification est la réponse à ce mur. Elle consiste à convertir les poids d’un réseau — initialement stockés en 16 bits — vers des formats plus compacts, 8, 4, voire 2 bits. Le gain est spectaculaire : la quantification réduit la RAM nécessaire de 50 à 75 %, et un modèle 7B qui pesait ~14 Go en FP16 tombe à ~4,5 Go en Q4_K_M, ou ~7 Go en Q8_0. Ce n’est plus un réglage cosmétique : c’est la condition sine qua non pour qu’un modèle tienne sur une machine personnelle.

L’histoire de cette bascule mérite d’être racontée, même si les dates fondatrices circulent surtout par tradition orale technique. Les premiers travaux sur les réseaux quantifiés remontent au milieu des années 2010, avec des approches de quantization-aware training. Mais c’est la vague post-LLaMA (début 2023) qui a tout accéléré : quand des modèles ouverts puissants sont devenus disponibles, la communauté a eu besoin de les faire tourner sur du matériel modeste, et la quantification post-entraînement est devenue indispensable. GPTQ, AWQ, EXL2, puis l’arrivée de FP8 et NVFP4 poussée par NVIDIA avec ses architectures récentes : chaque étape a resserré le lien entre format de quantification et matériel.

En 2026, ce lien est devenu structurant. Le format que vous choisissez détermine non seulement la taille du modèle, mais aussi le runtime que vous pouvez utiliser, la carte que vous devez acheter, et jusqu’à la qualité de vos réponses en contexte long. C’est ce que ce dossier démonte, format par format — en gardant en tête un principe que les comparatifs naïfs oublient trop souvent : à bits égaux, ce n’est pas le format qui décide de la qualité, c’est le couple moteur/kernel qui l’exécute.

GGUF : le couteau suisse qui a conquis le grand public

Si un seul format incarne l’IA locale grand public, c’est GGUF. Ce format conteneur, héritier de GGML, est celui qui stocke les modèles quantifiés pour llama.cpp, Ollama et LM Studio — autrement dit, pour la quasi-totalité des outils que le débutant installe en premier. Sa force tient en un mot : portabilité. GGUF s’exécute sur CPU, sur GPU, ou en configuration hybride CPU+GPU via llama.cpp, et il est le seul grand format à supporter tous les backends — CUDA, Metal, Vulkan, ROCm. C’est le seul qui ne présuppose pas une carte NVIDIA dans votre machine.

Cette universalité s’est encore renforcée à l’automne 2026. Le 9 octobre, Windows ML a ajouté un support expérimental de llama.cpp pour les modèles GGUF, avec une API locale compatible OpenAI et de nouveaux outils runtime. Autrement dit, GGUF n’est plus seulement le format des bidouilleurs Linux : il devient un citoyen de première classe sur Windows, aux côtés de PyTorch et llama.cpp (blog Microsoft Foundry, 7 octobre 2026). Et côté moteur, llama.cpp v0.5.0 a consolidé son backend, son serveur (llama-server) et sa gestion GPU au cours du mois de septembre 2026.

Derrière cette simplicité se cache une nomenclature qui intimide, et pour cause. Le schéma de nommage Q[bits]_[K]_[S/M/L] encode bien plus qu’un nombre de bits. Le « K » désigne un K-quant : une quantification qui stocke, pour chaque petit bloc de poids, non seulement une valeur mais aussi une échelle et une valeur minimale. Conséquence contre-intuitive : la largeur de bits effective dépasse toujours le chiffre nominal. Q4_K_M ne tourne pas à 4 bits par poids, mais à environ 4,89 bits effectifs. C’est précisément ce qui explique qu’un fichier « 4-bit » d’un modèle 8B pèse ~4,6 GiB au lieu des 4 Go théoriques.

Les paliers S, M et L (small, medium, large) ajustent finement combien de couches sensibles reçoivent une précision supérieure. Dans un Q4_K_M, la plupart des poids sont en 4 bits, mais certaines couches critiques passent en 6 bits. C’est cet équilibre qui a fait de Q4_K_M le standard de fait de la communauté — le meilleur compromis qualité/RAM pour le matériel grand public. Au-delà de 5 bits (Q5_K_M, Q6_K), la perte de qualité devient négligeable ; autour de Q4, le compromis reste pratique ; en dessous de 4 bits, la dégradation devient nettement perceptible.

La perte de qualité en Q4_K_M est souvent citée autour de 1 à 3 % sur MMLU par rapport au FP16 — un chiffre à prendre avec des pincettes, car il varie énormément selon le modèle et la méthode d’évaluation. Les K-quants de llama.cpp revendiquent, à 6 bits, une proximité de l’ordre de 0,1 % de perplexité avec le FP16. Mais GGUF a ses limites : en dessous de 4 bits, la dégradation s’accélère, et le format est sensible au contexte long, où le KV-cache vient s’ajouter aux poids. C’est l’angle mort dont nous reparlerons.

Une évolution à surveiller en 2026 : les quants dynamiques UD- d’Unsloth, désormais présentés comme la variante GGUF qui mène la qualité à taille comparable. Et surtout, le format GGUF n’est plus réservé aux formats entiers : il accueille désormais les formats FP4 (MXFP4 et NVFP4) dans son écosystème, ce qui rebat les cartes entre « format logiciel » et « format matériel » — nous y revenons plus bas.

GPTQ, AWQ, EXL2/EXL3 : les formats GPU-first et ce qu’ils font vraiment aux poids

Face à GGUF, une autre famille de formats s’est imposée : les formats GPU-first, conçus pour exploiter les cartes graphiques à fond plutôt que pour la portabilité. GPTQ, AWQ et EXL2/EXL3 en sont les trois piliers, et ils partagent un présupposé : vous avez une carte NVIDIA, et vous voulez du débit.

GPTQ est le plus ancien des trois. Sa méthode est élégante : il quantifie le modèle couche par couche, en utilisant l’information de la matrice de Hessienne pour décider comment arrondir chaque poids de manière à minimiser l’erreur. Résultat : des modèles 3 à 4 bits, organisés en groupes de 128 poids, qui tiennent sur des cartes modestes tout en restant proches de l’original. AWQ (Activation-aware Weight Quantization) prend un angle différent : plutôt que de traiter tous les poids également, il identifie les canaux saillants — ceux dont l’activation est la plus forte — et les protège en ajustant l’échelle des activations. C’est une quantification W4A16 : poids en 4 bits, activations en 16 bits. Ce choix n’est pas anodin, car les activations des LLM contiennent des valeurs aberrantes pouvant atteindre environ 100 fois la médiane ; les garder en haute précision évite de ruiner la qualité.

EXL2, développé par turboderp dans l’écosystème exllamav2, pousse la logique plus loin : il autorise des bits mixtes par couche, avec un choix dynamique du bitrate. Vous pouvez viser 4,5 bpw (bits par poids) et laisser l’algorithme décider quelles couches méritent plus de précision. C’est particulièrement apprécié des utilisateurs qui veulent extraire le maximum d’une carte, en réglant finement le curseur entre vitesse et qualité. En 2026, son successeur EXL3 (moteur ExLlamaV3, souvent servi via TabbyAPI) est devenu la référence pour l’inférence personnelle la plus rapide sur NVIDIA, avec la meilleure qualité à bas bpw selon les comparatifs de terrain — mais il recule dans les tableaux comparatifs « grand public », faute d’adoption dans les outils de masse.

La différence fondamentale avec GGUF est architecturale : ces formats sont optimisés pour le GPU et dépendent étroitement de leur runtime. GPTQ et AWQ s’intègrent à vLLM, TensorRT-LLM ou aux bibliothèques Hugging Face ; EXL3 est intimement lié à ExLlamaV3 et aux workflows CUDA. En contrepartie, sur une carte consumer ou pro, ils surpassent souvent GGUF en débit, parce qu’ils exploitent mieux les kernels GPU. Le prix à payer : une compatibilité limitée. Un fichier AWQ ne tournera pas sur votre CPU, et un GGUF ne tirera pas parti des optimisations TensorRT.

Un ordre de grandeur utile, à prendre comme illustratif du classement relatif et non comme mesure absolue (chiffres d’une génération antérieure, Llama-2-13B, sur RTX 3090 en 4 bits) : GGUF ~31–35 tok/s, AWQ ~39 tok/s, GPTQ ~42–64 tok/s, EXL3 le plus rapide en usage personnel. La perplexité, elle, reste quasi identique entre les quatre (~4,33–4,34) : à 4 bits, la qualité ne départage plus les formats, c’est la vitesse et la compatibilité qui le font.

FP8 et NVFP4 : la quantification native du matériel Blackwell

Voici le tournant de 2026. Jusqu’ici, la quantification était une affaire de logiciel : on prenait un modèle entraîné en haute précision et on le compressait après coup. Avec FP8 puis NVFP4, la quantification devient une propriété du matériel.

FP8 existe sous deux variantes, E4M3 et E5M2, qui diffèrent par la répartition des bits entre exposant et mantisse. Ce format est natif sur les architectures Hopper et Ada, et il est supporté dans vLLM comme dans TensorRT-LLM. Il offre un compromis séduisant : une empreinte mémoire réduite de moitié par rapport au FP16, avec une perte de précision souvent jugée acceptable pour l’inférence. En 2026, FP8 « déborde du datacenter » : on le voit de plus en plus sur du matériel prosumer et dans les workflows locaux, au point de brouiller la frontière entre formats serveur et formats personnels.

NVFP4 va plus loin. Il s’agit d’un format FP4 — donc 4 bits — mais avec une échelle microscale en E4M3 appliquée par bloc de 16 valeurs. Cette granularité fine permet de conserver une précision étonnante malgré une compression agressive, et surtout d’exploiter les tensor cores FP4 natifs des GPU Blackwell. C’est ce qui fait dire à de nombreux observateurs que NVFP4 est le format de 2026 pour les GPU consumer Blackwell : il combine l’avantage matériel (débit brut, efficacité énergétique) avec une précision qui rivalise avec des formats logiciels plus lourds. On trouve déjà des modèles publiés dans ce format sur Hugging Face, à l’image de GLM-5.2-NVFP4.

La comparaison avec les formats logiciels est instructive. Là où GGUF ou AWQ doivent être interprétés par un runtime qui reconstruit les poids à la volée, NVFP4 est compris par le silicium. Le gain en débit et en empreinte est réel. Mais cette efficacité a un prix : la dépendance. NVFP4 est intrinsèquement lié à NVIDIA, et son adoption dans l’écosystème open source reste le point à surveiller. Bonne nouvelle toutefois : la barrière s’abaisse, puisque NVFP4 et MXFP4 sont désormais intégrés à l’écosystème GGUF — llama.cpp sait les servir. Un format propriétaire, même excellent, fragmente l’écosystème ; mais quand il finit par rentrer dans le conteneur universel, la fragmentation recule.

Le KV-cache : l’angle mort qui fait exploser votre VRAM

Voici l’erreur que commettent presque tous les débutants : croire que la quantification des poids suffit à faire tenir un modèle. Elle n’en couvre qu’une partie. En inférence, trois choses consomment de la mémoire : les poids, les activations, et le KV-cache.

Le KV-cache, c’est la mémoire que le modèle conserve des tokens déjà traités pour ne pas les recalculer à chaque nouveau token. Problème : il croît linéairement avec la longueur de contexte. Un modèle qui se charge confortablement en Q4_K_M peut parfaitement provoquer une OOM (erreur de mémoire insuffisante) dès que vous lui envoyez 32k ou 128k tokens de contexte. C’est le piège classique : le modèle « rentre », mais la conversation plante.

La quantification du KV-cache est donc devenue aussi importante que celle des poids. Plusieurs techniques existent : le cache Q8, qui stocke les clés et valeurs en 8 bits ; des approches de recherche comme KIVI ; ou encore le FP8 KV dans vLLM. L’impact sur la qualité en contexte long est réel mais souvent acceptable, à condition de ne pas descendre trop bas. Les guides 2026 insistent désormais sur ce point : quantifier les poids sans quantifier le KV-cache, c’est se préparer à des déceptions en RAG ou en agents, où les contextes sont longs par nature.

Chiffres à l’appui : perplexité, débit et dégradation en long contexte

Confrontons les ordres de grandeur. Côté perplexité, la référence communément citée pour un Llama 3 8B en FP16 tourne autour de 5,5 sur WikiText-2. En Q4_K_M, on monte légèrement, autour de 5,7 ; en Q3_K_M, on dépasse les 6,0. AWQ 4-bit et GPTQ 4-bit se situent dans la même zone (~5,7–5,8), et EXL2 4,0 bpw autour de 5,65. Ces écarts paraissent minimes — et ils le sont sur des benchmarks de perplexité. Mais la perplexité est un indicateur grossier : elle ne capture pas les dégradations sur des tâches de raisonnement ou de code.

Côté débit, les écarts entre formats sont plus francs. Sur une RTX 4090, un modèle 7B en AWQ 4-bit ou EXL2/EXL3 atteint des débits nettement supérieurs à un GGUF équivalent, parce que les kernels GPU sont mieux exploités. Sur Apple Silicon, c’est l’inverse : GGUF via Metal est la voie royale, et les formats GPU-first y sont soit indisponibles, soit sous-optimaux — même si le format natif MLX, servi par LM Studio, devient une alternative crédible sur Mac. Sur CPU pur, seul GGUF (et llama.cpp) est vraiment praticable.

Un mot sur les iGPU et les cartes d’entrée de gamme, souvent oubliés des comparatifs : sur un iGPU AMD Radeon 780M, llama.cpp en Vulkan atteint environ 10–12 tok/s sur Llama 3 8B Q4 et Qwen 2.5 7B, et 8–11 tok/s sur Mistral 7B Q4_K_M — des gains de l’ordre de +50 % grâce aux optimisations Vulkan récentes, et +12,9 % via le seul réglage MMVQ. Autrement dit, même sans GPU dédié, GGUF reste la seule voie praticable.

Le piège des tableaux « à bits égaux » : ce que votre benchmark mesure vraiment

Il faut le dire net, car c’est le péché originel de la plupart des comparatifs qui circulent : 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 table de calibration et la granularité de ses groupes de quantification. Le bit n’est plus le sujet : à 4 bits, tous les grands formats se valent en perplexité, et les écarts de débit viennent des kernels, pas des algorithmes.

C’est pourquoi la vraie matrice de compatibilité — quel format survit dans quel moteur, en 2026 — compte plus que le tableau des bits. GGUF vit partout ; AWQ et GPTQ vivent dans vLLM et TensorRT-LLM ; EXL3 vit dans ExLlamaV3/TabbyAPI ; MLX vit sur Apple ; FP8 et NVFP4 vivent sur le silicium NVIDIA récent. Choisir un format, c’est choisir un moteur, et donc un matériel. Les benchmarks « propres » qui prétendent départager les formats sans nommer le moteur, la version du kernel et la méthode de calibration sont à jeter.

Monter son setup sans se ruiner : la méthode en cinq décisions

Assez de théorie. Voici comment décider, dans l’ordre, en 2026.

1. Partez du matériel, pas du format. Sur CPU ou iGPU : GGUF, point final. Sur Apple Silicon : GGUF via Metal, ou MLX si votre outil le supporte. Sur GPU NVIDIA consumer (Ada/Blackwell) : GGUF pour la simplicité, AWQ ou EXL3 pour le débit maximal. Sur GPU Blackwell récent : NVFP4 devient le choix par défaut dès que le modèle est publié dans ce format.

2. Calibrez la taille sur la VRAM, KV-cache inclus. La règle empirique : poids quantifiés + KV-cache + marge d’activations doivent tenir sous votre VRAM. Un 7B en Q4_K_M (~4,5 Go) laisse de la place pour un contexte confortable sur 8 Go ; un 13B en Q4_K_M (~8 Go) sature une carte de 12 Go dès que le contexte s’allonge. Quantifiez le KV-cache en Q8 ou FP8 avant de blâmer le format des poids.

3. Ne descendez pas sous Q4 sans raison. En dessous de 4 bits, la dégradation s’accélère nettement. Si vous manquez de mémoire, mieux vaut un modèle plus petit en Q5_K_M qu’un gros modèle en Q3_K_M.

4. Vérifiez le moteur avant de télécharger. Un fichier AWQ sur une machine sans vLLM ne sert à rien. Un GGUF NVFP4 sur un GPU non-Blackwell ne tirera aucun bénéfice matériel. Télécharger le bon format pour le mauvais moteur est l’erreur la plus coûteuse en temps.

5. Pensez coût total, pas seulement prix de la carte. Une RTX 4090 d’occasion, une RX 9070 XT 16 Go à 690–740 $, un mini PC à mémoire unifiée (Ryzen AI Halo 128 Go à 3 999 $, Gorgon Halo 192 Go) : chacun a son format de prédilection. Le mini PC à mémoire unifiée, avec ses 120 à 200 milliards de paramètres en GGUF, change la donne pour qui veut de gros modèles sans tour GPU — mais à condition d’accepter le débit plus modeste de la mémoire unifiée.

Ce qui change en 2026 : les signaux à suivre

Trois évolutions structurent l’année. D’abord, la porosité entre formats matériels et conteneurs universels : NVFP4 et MXFP4 entrent dans GGUF, FP8 déborde du datacenter, et la frontière entre « format logiciel » et « format silicium » s’efface. Ensuite, la montée de Windows comme plateforme d’IA locale : avec le support llama.cpp/GGUF de Windows ML (octobre 2026), le PC grand public devient une cible de premier plan, ce qui renforce encore GGUF. Enfin, la fragmentation par les moteurs : EXL3 est excellent mais recule faute d’adoption de masse, tandis que vLLM et llama.cpp consolident leur position de hubs.

La leçon de 2026 tient en une phrase : le format de quantification n’est plus un choix isolé, c’est le point d’articulation entre un modèle, un moteur et une carte. Choisissez les trois ensemble, et vous ferez tourner des modèles de classe 70B — voire bien plus — sur du matériel personnel, sans vous ruiner.

Sources

• Model Formats Explained: GGUF vs GPTQ vs AWQ vs EXL2 — InsiderLLM
• LLM Quantization Guide: GGUF vs EXL2 vs AWQ vs NVFP4 (2026) — CyberPulsTech
• GGUF vs EXL2 vs AWQ vs GPTQ — Local AI Zone
• Guide complet Quantization LLM 2026 : GGUF, GPTQ, AWQ (PDF) — Ayinedjimi Consultants
• Windows ML: 2026 Updates for GGUF Models and Local AI — Techgenyz (9 octobre 2026)
• AI Development on Windows: from PyTorch and llama.cpp to Windows ML — Microsoft Foundry Blog (7 octobre 2026)
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API — Gyanaangan (27 septembre 2026)
• Moteurs d’inférence et runtimes locaux : comparatif 2026 — PromptQuorum (20 septembre 2026)
• Faire tourner une IA en local en 2026 : guide complet — Brief IA (18 septembre 2026)
• Performance LLM sur GPU AMD Radeon 9070XT — QuellLM (25 septembre 2026)
• Mistral Large 4 en open weights — dossier du magazine (octobre 2026)
• Mini PC à mémoire unifiée : LLM de 120 à 200 milliards de paramètres — dossier du magazine (2026)
• EXL3, AWQ, FP8, GGUF : la guerre des formats se joue sur le mauvais terrain — dossier du magazine (2026)

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