GGUF, AWQ, GPTQ, EXL2 et MLX : quel format de quantification LLM en 2026 ?

Cinq formats, une seule vraie question : lequel colle à votre stack. GGUF partout, AWQ sur GPU NVIDIA, MLX sur Mac — et encore EXL2, GPTQ et bitsandbytes à placer correctement.

GGUF, GPTQ, AWQ, EXL2 et MLX ne sont pas interchangeables. Chacun cible un matériel différent et négocie vitesse contre précision à sa façon. La plupart des comparatifs brouillent une distinction de base : GGUF est un format de fichier autonome, tandis que GPTQ et AWQ sont des algorithmes de quantification dont les poids vivent dans des safetensors Hugging Face. Ce guide relie chaque option à son runtime, son matériel et son meilleur cas d’usage.

Choisir entre GGUF, AWQ, GPTQ, EXL2 et MLX est la décision de quantification LLM que les développeurs se trompent le plus souvent — et le mauvais format peut, selon certaines estimations, coûter une part significative de la vitesse d’inférence avant même d’avoir réglé un seul paramètre. Les formats ne se substituent pas les uns aux autres.

La confusion commence par une erreur de catégorie. GGUF est un artefact autonome : poids, tokenizer et métadonnées dans un seul fichier portable. GPTQ et AWQ sont des procédures dont la sortie est stockée en safetensors Hugging Face classiques. EXL2 et MLX sont à nouveau des formats, chacun soudé à un runtime. Les traiter comme un seul menu mène à associer un format à un matériel pour lequel il n’a jamais été conçu.

Ci-dessous : une lecture claire des six options — GGUF, GPTQ, AWQ, EXL2, MLX et bitsandbytes —, un tableau propriétaire liant chacune à son runtime et à son matériel, des données de benchmarks contre-intuitives issues d’une évaluation de janvier 2026, et un arbre de décision pour CPU, NVIDIA et Apple Silicon.

Points clés

1. Format et algorithme ne sont pas la même chose. GGUF est un conteneur autonome ; GPTQ et AWQ sont des algorithmes dont les poids sont stockés en safetensors Hugging Face ; EXL2 et MLX sont des formats liés chacun à un runtime. Choisissez d’abord sur cet axe, avant la largeur de bits.
2. GGUF est le défaut universel. Il tourne sur CPU, NVIDIA, AMD et Apple Silicon, peut répartir les couches entre CPU et GPU, et ses k-quants approchent la qualité GPTQ-4 à largeur de bits moyenne égale. Le choix sûr quand le matériel est mixte ou inconnu.
3. Sur NVIDIA, AWQ a dépassé GPTQ. La mise à l’échelle consciente des activations a réduit la pénalité de perplexité INT4 de 4,57 à 1,17 (environ 74 %) et surpasse GPTQ sur le raisonnement à 4 bits. Les nouveaux modèles sortent désormais en AWQ ou GGUF en premier.
4. EXL2 ajuste le bitrate à votre VRAM ; MLX règne sur le Mac. EXL2 cible toute moyenne fractionnaire entre 2 et 8 bits par poids sur un GPU NVIDIA unique ; MLX exploite la mémoire unifiée Apple et est devenu le backend Apple Silicon par défaut dans Ollama.
5. bitsandbytes est le seul format « safe training » ici. Son chemin NF4 4 bits alimente le fine-tuning QLoRA en gelant une base compressée et en entraînant de petits adaptateurs. Tous les autres formats de cette comparaison sont réservés à l’inférence.

Indicateur	Valeur	Détail
Erreur INT4 AWQ	−74 %	Pénalité de perplexité de 4,57 à 1,17 vs INT4 naïf
Portée matérielle GGUF	4 cibles	CPU · NVIDIA · AMD · Apple
Téléchargements AWQ	6 M+	Sur Hugging Face
Plage bitrate EXL2	2–8 bpw	Toute moyenne fractionnaire

01 — Format vs algorithme : l’erreur de catégorie

Avant de comparer les vitesses, clarifions le vocabulaire. On dit « format de quantification » pour désigner trois choses distinctes — et cette confusion mène exactement à se retrouver avec un fichier EXL2 impossible à charger sur Mac, ou à attendre qu’un GGUF tourne dans vLLM. Il y a trois familles.

Un format de fichier est un artefact complet et autonome : le fichier téléchargé est le modèle. GGUF, EXL2 et MLX sont des formats de fichier, chacun lié à un runtime précis. Un algorithme de quantification est une procédure, pas un type de fichier — GPTQ et AWQ produisent des shards safetensors Hugging Face ordinaires plus une config, d’où l’apparence « comme n’importe quel dépôt HF » d’un « modèle AWQ ». Et la quantification à la volée, approche bitsandbytes, ne livre aucun fichier pré-quantifié : les poids sont compressés au chargement et décompressés pendant le forward pass.

Famille	Exemples	Ce que vous téléchargez
Formats de fichier (conteneur)	GGUF · EXL2 · MLX	Le fichier est l’artefact — poids, tokenizer et paramètres de quant, liés à un runtime (llama.cpp, ExLlamaV2, mlx-lm).
Algorithmes (méthode)	GPTQ · AWQ	Procédure de quantification. Sortie = safetensors HF + config.
À la volée (runtime)	bitsandbytes NF4 / INT8	Pas de fichier pré-quantifié. Compression au chargement, décompression par forward pass — ce qui rend QLoRA possible.

Pourquoi ça compte d’abord. Associez l’artefact au runtime avant de débattre de la largeur de bits. Un format autonome ne tourne que dans le moteur pour lequel il a été conçu ; la sortie safetensors d’un algorithme exige un runtime qui implémente ses kernels. Se tromper à ce niveau, et aucun réglage soigneux en 4 bits ne chargera le modèle sur votre machine.

02 — GGUF : le format qui tourne partout

GGUF signifie « Georgi Gerganov Universal Format », du nom du créateur de llama.cpp et ggml. Il a remplacé l’ancien format GGML en août 2023 — une distinction utile, car GGML est le prédécesseur et GGUF la norme actuelle. Un seul fichier GGUF emballe poids, tokenizer, métadonnées et paramètres de quantification dans un artefact portable.

Sa caractéristique distinctive est l’agnosticisme matériel. GGUF tourne sur CPU via llama.cpp, sur GPU NVIDIA via CUDA, sur AMD via ROCm, et sur Apple Silicon via Metal — et il peut répartir les couches d’un modèle entre CPU et GPU (partial offload), ce qui permet de faire tourner un modèle un peu trop grand pour la VRAM. Aucun autre format de cette comparaison ne couvre autant de cibles.

Côté qualité, les K-quants de llama.cpp utilisent une structure en super-blocs : les poids sont groupés et chaque bloc reçoit son propre facteur d’échelle, le suffixe S/M/L indiquant la taille de bloc (plus grand = plus de compression, un peu moins de précision). Les K-quants battent régulièrement les anciens formats Q4_0 et Q5_0 à largeur de bits moyenne égale. Le tableau ci-dessous reprend des mesures indépendantes de perplexité et de benchmarks issues d’une évaluation arXiv de janvier 2026 sur Llama-3.1-8B-Instruct.

Niveaux de quantification GGUF testés sur Llama-3.1-8B-Instruct : bits moyens, réduction de taille, perplexité WikiText-2, score agrégé et score GSM8K (évaluation arXiv janvier 2026).

Deux points méritent un second regard. D’abord, le palier Q4_K_M que la plupart des gens utilisent réellement se situe juste au-dessus de Q4_K_S en allocation de bits et reste le défaut populaire — nettement meilleur que l’ancien Q4_0 à largeur nominale égale, car les couches d’attention et d’embedding reçoivent un budget de bits un peu plus élevé. Ensuite, plus surprenant : le palier 5 bits Q5_0 a dépassé le FP16 sur cette course — 69,92 contre 69,47 au score agrégé, et 79,08 contre 77,63 sur GSM8K. L’article attribue cela à un léger effet de régularisation du bruit de quantification. À traiter comme un résultat spécifique et reproductible pour ce modèle, pas comme une règle universelle selon laquelle le 5 bits battrait toujours la pleine précision.

GGUF est le format que l’on charge dans LM Studio pour la gestion locale de modèles, dans Ollama, ou directement via llama.cpp. Si la priorité est de faire tourner un modèle capable sur la machine devant vous — y compris un laptop sans GPU discret — GGUF est presque toujours le bon premier mouvement.

03 — GPTQ : le standard GPU que 2025 a dépassé

GPTQ a été le format qui a rendu possible l’inférence mono-GPU de modèles géants. Il peut quantifier un modèle à 175 milliards de paramètres en environ 4 heures GPU à 3 ou 4 bits avec une dégradation négligeable, et a plus que doublé la compression par rapport aux méthodes one-shot précédentes. Pendant deux ans, c’était l’histoire de la quantification GPU — un contributeur Hugging Face prolifique, TheBloke, a publié plus de 2 000 modèles quantifiés GPTQ et a de fait fixé le standard de 2023 et 2024.

Côté runtime, le socle est solide : vLLM sert GPTQ via ses kernels Marlin et Machete, optimisés pour Ampere (A100 et plus) et Hopper (H100 et plus). GPTQ prend aussi en charge une compression extrême jusqu’à 2 bits, voire ternaire — mais ici les claims papier et la réalité production divergent. L’expérience communautaire montre une dégradation nette sous 4 bits : traitez le GPTQ sub-4 bits comme expérimental, pas comme quelque chose à livrer.

Le cadrage honnête en 2026 : GPTQ a largement été remplacé par AWQ pour les nouvelles sorties de modèles. Il conserve la plus grande bibliothèque héritée et reste un choix raisonnable pour des checkpoints GPTQ existants, mais quand un nouveau modèle sort, il arrive désormais d’abord en AWQ ou GGUF.

Repère	Chiffre	Lecture
Temps de quantification	~4 h GPU	175B en 3–4 bits avec perte négligeable — première méthode à permettre l’inférence mono-GPU de modèles qui demandaient un cluster.
Écosystème TheBloke	2 000+ uploads	Pourquoi GPTQ est devenu le standard GPU de facto en 2023–2024.
Plancher extrême	2 bits	Supporté, mais la qualité chute sous 4 bits — gardez le GPTQ production en 4 bits. NVIDIA seulement.

04 — AWQ : protéger le 1 % qui compte

AWQ — Activation-Aware Weight Quantization, du Han Lab du MIT — repose sur une observation nette : les poids ne sont pas tous égaux. Identifier et protéger seulement le 1 % supérieur des poids saillants, sélectionnés selon l’amplitude des activations plutôt que selon les valeurs des poids elles-mêmes, réduit fortement l’erreur de quantification. AWQ le fait avec une mise à l’échelle par canal informée par les motifs d’activation, sans rétropropagation ni reconstruction des poids.

Cette idée a remporté le Best Paper Award à MLSys 2024, et les chiffres suivent. En INT4 avec taille de groupe 128, AWQ a fait passer la pénalité de perplexité de 4,57 à 1,17 — environ 74 % de réduction de la dégradation — et à la même profondeur 4 bits, il surpasse régulièrement GPTQ sur les benchmarks de raisonnement et d’instruction-following. Il est aussi rapide : plus de 3× le FP16 Hugging Face rapporté, sur GPU desktop comme mobile. Les modèles AWQ sur Hugging Face ont dépassé 6 millions de téléchargements.

L’insight AWQ. Selon le Han Lab du MIT, protéger seulement 1 % des poids saillants — choisis par amplitude d’activation, pas par valeur de poids — peut fortement réduire l’erreur de quantification, sans rétropropagation ni reconstruction. En INT4 (groupe 128), cela a coupé la pénalité de perplexité de 4,57 à 1,17, soit environ −74 %.

En pratique, AWQ est devenu le défaut pour l’inférence GPU de production. Il est supporté nativement dans les stacks NVIDIA majeures — vLLM, Hugging Face TGI, NVIDIA TensorRT-LLM et LMDeploy — et vise surtout NVIDIA et l’accélération GPU edge/mobile. Une nuance marketing : la claim « lossless » d’AWQ vise surtout les modèles vision-langage comme VILA. Pour la plupart des LLM texte, AWQ en 4 bits est quasi sans perte — excellent, mais pas littéralement lossless. Benchmarkez sur vos propres prompts avant de considérer la qualité comme un problème résolu.

Le passage GPTQ → AWQ est la tendance la plus claire de la quantification GPU. Ce n’est pas que GPTQ a cessé de fonctionner ; c’est que l’approche activation-aware d’AWQ livre une meilleure qualité au même budget de bits, avec un support runtime de première classe plus large. Quand un format gagne à la fois sur la qualité et sur l’outillage, le reste du champ suit en un ou deux cycles de release — exactement ce qui s’est passé en 2025 et 2026.

05 — EXL2 : régler le bitrate pour remplir la VRAM

EXL2, format d’ExLlamaV2, a une idée réellement différente : au lieu de s’engager sur un nombre entier de bits, il permet de cibler n’importe quelle moyenne entre 2 et 8 bits par poids en mélangeant les niveaux de quantification dans un même modèle. Vous voulez 4,65 bpw pour remplir exactement une carte 24 Go ? C’est possible. L’algorithme mesure l’erreur de quantification par matrice et alloue plus de bits aux couches les plus sensibles.

« EXL2 prend en charge la quantification en 2, 3, 4, 5, 6 et 8 bits, et permet de mélanger les niveaux au sein d’un modèle pour atteindre n’importe quelle moyenne entre 2 et 8 bits par poids. » — turboderp, auteur d’ExLlamaV2

Le compromis : EXL2 est NVIDIA seulement. Pas d’AMD, pas d’Apple Silicon, pas d’inférence CPU. Il reste rétrocompatible avec les modèles GPTQ 4 bits, et la stack production recommandée associe ExLlamaV2 à TabbyAPI comme serveur d’API local. Là où il gagne sa place, c’est le débit mono-GPU brut — les utilisateurs rapportent 2 à 5× plus de vitesse vs chargeurs standards pour modèles quantifiés sur setups mono-GPU.

Config	Débit annoncé	Note
TinyLlama 1.1B @ 3,0 bpw — RTX 4090	770 t/s	Chiffre vendor single-batch (mainteneur ExLlamaV2)
Llama 2 7B @ 3,0 bpw — RTX 4090	257 t/s	Toujours >250 t/s sur une carte consumer
Llama 2 70B @ 2,55 bpw — une carte 24 Go	~38 t/s	Le bitrate fractionnaire fait tenir un 70B sur 24 Go

Lisez ces chiffres comme un meilleur cas, pas une garantie. Ce sont des benchmarks vendor du mainteneur ExLlamaV2, en génération single-batch optimale ; attendez un débit plus bas sous charge multi-utilisateurs ou en batch. EXL2 est le format power-user — le bon choix quand vous avez une seule carte NVIDIA, voulez le maximum de tokens/s, et acceptez de régler le bitrate au mégaoctet près.

06 — MLX : pensé pour la mémoire unifiée de chaque Mac

MLX est le framework open-source d’Apple pour le machine learning sur Apple Silicon, lancé en novembre 2023. Il est construit autour de ce qui rend un Mac différent : l’architecture à mémoire unifiée, où CPU, GPU et Neural Engine partagent un même pool physique. MLX l’exploite avec de vraies opérations tenseur zero-copy et une évaluation paresseuse qui fusionne les opérations avant exécution — pas de copie de tenseurs d’avant en arrière sur un bus PCIe, parce qu’il n’y a pas de VRAM séparée vers laquelle copier.

C’est pourquoi Apple Silicon « frappe au-dessus de son poids » sur les grands modèles. Un M4 Max offre jusqu’à 128 Go de mémoire unifiée à 546 Go/s de bande passante — du niveau GPU datacenter — ce qui permet de tenir et d’alimenter des modèles qui dépassent la VRAM d’un GPU discret à prix comparable. La capacité, pas seulement la vitesse, est le point : vous chargez un modèle qu’une carte discrète ne pourrait tout simplement pas loger.

Le runtime s’est nettement amélioré en 2026. Ollama est passé à un backend MLX pour Apple Silicon, et ses propres benchmarks de mars 2026 sur un modèle Qwen 3.5 35B-A3B montrent un prefill passé de 1 154 à 1 810 tokens/s et un decode de 58 à 112 après le basculement — les accélérateurs neuronaux GPU du M5 étant ciblés nativement pour le prefill. Chiffres vendor-reported : à lire comme directionnels.

Repère	Valeur	Contexte
Plafond M4 Max	128 Go unifié · 546 Go/s	Modèles trop gros pour la VRAM d’un GPU discret comparable
Ollama prefill (Qwen 3.5 35B-A3B, M5)	1 810 t/s	Après backend MLX (mars 2026) : prefill 1 154→1 810, decode 58→112
MacBook Air 16 Go — Qwen 3.5 9B MLX 4 bits	25–35 t/s	Benchmarks communautaires — inférence locale sans GPU desktop

On voit aussi des claims selon lesquelles MLX utiliserait environ 10 % de mémoire en moins que GGUF sur Mac et tournerait 15 à 30 % plus vite à niveau de quantification équivalent, et qu’un MLX 4 bits retiendrait environ 97 % du score MMLU pleine précision. Ces chiffres viennent de benchmarks communautaires secondaires plutôt que de mesures indépendamment vérifiées : directionnels, pas précis. Le takeaway fiable est plus simple : sur un Mac série M, MLX est le chemin natif et désormais le backend Apple Silicon par défaut dans Ollama — et pour le edge / on-device, une option de première classe.

07 — bitsandbytes : le seul format safe pour l’entraînement

bitsandbytes est volontairement l’outsider. Il fait de la quantification à la volée — NF4 (4-bit Normal Float) et LLM.int8() (8 bits) — sans exiger de fichier de modèle pré-quantifié. Les poids ne sont décompressés que lorsqu’ils sont nécessaires pendant le forward pass. NF4 est théoriquement optimal pour des poids normalement distribués : issu du papier QLoRA, ses bins de quantiles sont calés sur la CDF de la loi normale, ce qui lui donne un avantage sur le FP4 naïf. NF4 divise la mémoire par 4 vs FP16, et la quantification imbriquée (« double ») économise encore 0,4 bit par paramètre.

Ce qui distingue bitsandbytes, c’est qu’il est le seul format de cet ensemble conçu pour l’entraînement, pas seulement l’inférence. Un fine-tune QLoRA gèle le modèle de base NF4 4 bits et entraîne de petites matrices adaptatrices LoRA par-dessus — ce qui rend possible le fine-tuning d’un 13B sur une seule NVIDIA T4 16 Go. Le chemin 8 bits, LLM.int8(), utilise une décomposition en précision mixte : les valeurs outlier d’état caché au-dessus d’environ 6 restent en FP16, le reste passe en INT8, ce qui évite la perte catastrophique de qualité d’un INT8 naïf sur les transformers. Matériel minimum : GPU NVIDIA Turing (RTX 20-series ou T4) ou plus récent.

Chemin	Technique	Usage
4 bits NF4 + QLoRA	double-quant · −0,4 bit/param	Geler la base NF4, entraîner des adaptateurs LoRA — fine-tune 13B sur T4 16 Go. Training-safe.
8 bits LLM.int8()	outliers FP16 + reste INT8	Évite la catastrophe INT8 naïf. Turing (T4) ou plus récent.

Ce que « training-safe » signifie vraiment. D’après la documentation Hugging Face, l’entraînement 8 et 4 bits n’est supporté que pour entraîner des paramètres supplémentaires — les adaptateurs LoRA. Les poids de base quantifiés restent gelés. Vous ne fine-tunez pas pleinement un modèle en NF4 ; vous entraînez de petites matrices adaptatrices contre un backbone compressé. Pour de l’inférence pure, un format dédié (GGUF, AWQ ou EXL2) servira plus vite.

08 — Matrice de décision : six formats, mappés à votre matériel

Voici le champ entier en une vue. Lisez d’abord par matériel : le format qui colle à votre silicium élimine l’essentiel du menu avant même que qualité ou vitesse n’entrent en jeu. Le regroupement renforce la distinction de la section 01 — formats de fichier autonomes, algorithmes stockés en safetensors, et outlier à la volée.

Comparaison maître de GGUF, EXL2, MLX, GPTQ, AWQ et bitsandbytes NF4 par cible matérielle, runtimes principaux, profondeurs de bits, caractère training-safe, et note qualité/vitesse.

Arbre de décision rapide

• CPU ou matériel mixte / inconnu → GGUF. Laptops, boîtiers CPU-only, ou mix CPU/GPU : GGUF est le seul format qui couvre tout et peut splitter un modèle. Démarrez en Q4_K_M, montez en Q5_0 ou Q8_0 si vous avez la mémoire.
• Serveur NVIDIA production → AWQ d’abord, EXL2 pour la vitesse. Sur NVIDIA, défaut AWQ pour les nouveaux modèles — meilleur raisonnement en 4 bits et support de première classe dans vLLM, TGI et TensorRT-LLM. Si vous êtes mono-GPU et chassez le maximum de tokens/s, EXL2 laisse régler le bitrate à la carte.
• Apple Silicon → MLX, ou GGUF pour la portabilité. Sur Mac série M, MLX est le chemin natif et le backend Apple Silicon par défaut dans Ollama. Choisissez GGUF seulement si le même fichier doit aussi tourner sur un boîtier CPU ou un GPU PC.
• Fine-tuning QLoRA → bitsandbytes NF4. Entraîner des adaptateurs, pas seulement servir : NF4 gèle une base 4 bits et entraîne des couches LoRA, ce qui fait tenir un fine-tune 13B sur T4 16 Go. Convertissez ensuite en GGUF ou AWQ pour un serving rapide.

Pour la plupart des équipes, la réponse honnête est plus d’un format : GGUF pour le prototype laptop, AWQ sur le serveur d’inférence, bitsandbytes pour le fine-tune. Monter ce pipeline — choisir les formats, benchmarker sur vos propres prompts, et brancher le runtime adapté — est le vrai travail d’ingénierie derrière une stack locale crédible.

09 — Conclusion : le format est une décision matérielle, pas une largeur de bits

Le menu s’effondre dès que l’on trie par silicium. GGUF pour la portabilité et les machines CPU ou mixtes ; AWQ, EXL2 ou GPTQ sur NVIDIA ; MLX sur Apple Silicon ; bitsandbytes quand vous fine-tunez plutôt que vous ne servez. Une fois cette première coupe juste, la comparaison cesse d’être écrasante — la plupart des formats ne s’appliquent tout simplement pas à la boîte devant vous.

La tendance la plus claire est que les formats natifs matériels prennent l’avantage. AWQ a déplacé GPTQ sur NVIDIA parce que son approche activation-aware exploite là où l’erreur vit réellement ; MLX gagne sur Apple parce qu’il est bâti autour de la mémoire unifiée ; les k-quants GGUF tiennent parce qu’ils répartissent intelligemment un budget de bits fixe entre couches. Les formats qui gagnent sont ceux qui comprennent l’architecture mémoire, pas seulement la largeur de bits nominale.

Attendez-vous à ce que la question continue de se simplifier — les runtimes convergent vers quelques défauts sensés par plateforme — mais la distinction format de fichier vs algorithme restera, et le levier orthogonal du nombre de bits à conserver est la décision suivante. Quel que soit le format vers lequel votre matériel vous pointe, lancez un test rapide de perplexité et de latence sur votre propre modèle avant de vous engager. Le résultat Q5_0-bat-FP16 est un rappel utile : le seul benchmark qui compte est celui de votre charge de travail.

FAQ — formats de quantification LLM

Quelle est la différence entre GGUF, GPTQ et AWQ ?

Ce ne sont pas le même type de chose — le point de confusion le plus fréquent. GGUF est un format de fichier autonome — un seul fichier portable qui emballe poids, tokenizer, métadonnées et paramètres de quantification, et tourne via llama.cpp, Ollama ou LM Studio sur CPU, NVIDIA, AMD et Apple Silicon. GPTQ et AWQ sont des algorithmes de quantification, pas des formats de fichier : leur sortie est stockée en shards safetensors Hugging Face ordinaires plus une config, et ils tournent sur GPU NVIDIA via des moteurs comme vLLM et TGI. Donc GGUF est un conteneur que vous chargez directement, tandis que GPTQ et AWQ sont des méthodes dont les résultats se servent via un runtime GPU. Choisir d’abord sur cet axe — conteneur vs algorithme, et quel matériel chacun cible — compte davantage que la largeur de bits nominale.

Quel format de quantification est le plus rapide ?

Cela dépend du matériel. Sur un GPU NVIDIA unique et en chasse au débit, EXL2 (ExLlamaV2) rapporte souvent les meilleurs tokens/s. Pour du serving production multi-utilisateurs sur NVIDIA, AWQ via vLLM / TensorRT-LLM est le défaut moderne. Sur Mac, MLX est le chemin natif le plus rapide. Sur CPU ou matériel mixte, GGUF (llama.cpp) est le plus pertinent — pas forcément le plus rapide en pico, mais le seul portable.

GGUF est-il la même chose que GGML ?

Non. GGML est le format prédécesseur ; GGUF l’a remplacé en août 2023 comme standard actuel de llama.cpp. Les anciens fichiers GGML ne sont plus le chemin recommandé.

Que signifie Q4_K_M en GGUF ?

Q4 indique une quantification autour de 4 bits ; K désigne la famille des K-quants (super-blocs avec facteurs d’échelle par bloc) ; M (Medium) indique une taille de bloc / budget de bits intermédiaire — typiquement un peu plus généreuse que S sur les couches sensibles. C’est le défaut populaire pour un bon équilibre taille / qualité.

AWQ vs GPTQ — lequel utiliser ?

Pour les nouveaux modèles en 2026, préférez AWQ : meilleure qualité de raisonnement à 4 bits, support runtime de première classe plus large. Conservez GPTQ pour des checkpoints hérités déjà en production, ou si votre stack ne parle qu’à GPTQ.

Puis-je faire tourner AWQ ou EXL2 sur Mac ou GPU AMD ?

En pratique, non pour le chemin natif prévu. AWQ et EXL2 ciblent NVIDIA. Sur Mac, utilisez MLX (ou GGUF pour la portabilité). Sur AMD, GGUF via ROCm / llama.cpp est la voie réaliste de cette comparaison.

Quel format pour le fine-tuning ?

bitsandbytes NF4 (QLoRA) : base 4 bits gelée + adaptateurs LoRA. Les autres formats de cet article sont pensés pour l’inférence. Après le fine-tune, convertissez souvent vers GGUF ou AWQ pour servir vite.

Un modèle quantifié a-t-il déjà battu la pleine précision ?

Oui, sur des mesures précises : dans l’évaluation de janvier 2026 sur Llama-3.1-8B-Instruct, le GGUF Q5_0 a légèrement dépassé le baseline F16 sur le score agrégé et sur GSM8K — attribué à un effet de régularisation du bruit de quantification. Ce n’est pas une garantie universelle ; c’est une raison de benchmarker votre propre charge.