Guide des formats de quantification pour LLM locaux
Dans la parabole de Borges sur l'empire et sa carte, les cartographes finissent par dessiner une carte aussi grande que le territoire lui-même, pour découvrir qu'elle ne sert à rien. Un modèle linguistique en 16 bits est cette carte : parfaitement fidèle, à l'échelle 1:1, mais bien trop encombrant pour tenir sur un bureau. La quantification est l'art de réduire l'échelle sans perdre les routes essentielles, et en 2026, les outils pour la réaliser sont si nombreux qu'ils exigent un glossaire avant même d'effectuer un choix. Dans la lignée du guide des moteurs d'inférence, cet article met de l'ordre parmi les formats : nature, coût en matière de qualité et compatibilité matérielle.
Un préambule, comme toujours : il s'agit d'une analyse d'articles de recherche, de documentations et de dépôts, et non d'un benchmark. Les chiffres proviennent des sources citées en lien, n'ont pas été reproduits de manière indépendante, et lorsqu'une source présente un intérêt commercial, cela est explicité.
Conteneurs contre méthodes
Le premier malentendu est d'ordre lexical. Un conteneur définit la manière dont les nombres sont écrits sur le disque ; une méthode de quantification définit la manière dont ils sont réduits. Parmi les conteneurs, on trouve safetensors, GGUF et les anciens fichiers pickle (.bin, .pt) ; parmi les méthodes, GPTQ, AWQ, NF4 ainsi que les K-quants et I-quants de llama.cpp ; sans oublier les cas hybrides : EXL2 et EXL3 forment à la fois une méthode et une structure de fichiers liées à une bibliothèque unique. Un fichier pickle peut exécuter du code arbitraire lors du chargement : méfiez-vous des fichiers d'origine inconnue. En revanche, GGUF, selon la documentation de Hugging Face, rassemble des tenseurs et des métadonnées standardisés, et a été conçu par Georgi Gerganov, le créateur de llama.cpp.
Le calcul de base est d'ordre arithmétique : le tableau utilisé par Hugging Face pour un modèle Llama-2 de 7 milliards de paramètres le montre clairement : 13 Go à l'origine, 4,1 Go en Q4KM.
Le second calcul : le cache
Les poids ne représentent que la partie visible. Comme expliqué dans l'article sur la KV cache, Llama-3.1-70B en 16 bits accumule environ 0,31 mégaoctet de cache par jeton : à 128 000 jetons, cela représente environ 40 Go, et à un million de jetons, plus de 300 Go—soit bien au-delà des 140 Go requis pour les seuls poids. Le cache est l'archive dans laquelle le modèle conserve les clés et les valeurs de ce qu'il a déjà lu, et à chaque mot généré, l'intégralité du cache doit être parcourue : le goulot d'étranglement réside dans la bande passante avant l'espace disque.
Les solutions appartiennent à deux familles. La première compresse : TurboQuant, OSCAR et EpiCache, examinés dans cet article précédent, travaillent sur les bits par valeur ou sur les éléments à conserver ; pour OSCAR sur Qwen3-8B, l'écart par rapport au BF16 descend à 1,42 point avec un cache huit fois plus petit. La seconde gère, et constitue le sujet de l'article sur PagedAttention et RadixAttention. Le papier de vLLM a mesuré que dans les systèmes antérieurs, seuls 20,4 à 38,2 % de la mémoire cache contenaient de véritables jetons ; avec la pagination, le gaspillage devient presque nul et le débit est multiplié par deux à quatre. Pourquoi en parler ici ? Parce que compresser le cache constitue un second levier, indépendant de celui des poids : ExLlamaV3, par exemple, quantifie le cache de 2 à 8 bits. Lorsqu'un format promet une longue fenêtre de contexte sur une petite carte graphique, le mérite en revient presque toujours à ces deux mécanismes combinés.
GGUF, le passe-partout
Si un format a remporté la bataille de l'inférence locale, c'est bien GGUF, pour une raison peu spectaculaire : il fonctionne partout. Comme abordé lors du panorama des moteurs d'inférence, llama.cpp l'exécute sur CPU, NVIDIA, AMD, Intel et Apple, et Hugging Face liste LM Studio, Ollama et GPT4All parmi les outils qui l'utilisent. Un fichier unique transporte à la fois poids et métadonnées.
Le nom révèle la recette. Selon le même tableau de Hugging Face, Q4K utilise 4,5 bits par poids, Q5K 5,5 bits, Q6K 6,5625 bits ; les I-quants descendent à 4,25 (IQ4XS), 2,06 (IQ2XXS) et 1,56 (IQ1S) en s'appuyant sur une importance matrix, un échantillon de texte qui indique au quantificateur les poids primordiaux. Les lettres S, M et L désignent des assemblages où certaines couches restent codées à une précision supérieure, ce qui explique pourquoi un fichier Q4KM est plus lourd que le strict calcul théorique.
C'est sur cette base qu'est apparue l'ère de la quantification dynamique. Unsloth, bien connu pour Unsloth Studio, attribue un nombre de bits différent à chaque couche, et dans ses tests sur Qwen3.5, affirme que ses variantes Q4KXL et IQ3_XXS se situent sur la meilleure frontière entre taille et fidélité. La prudence reste de mise : les entités qui mesurent la quantification sont aussi celles qui la produisent, bien qu'elles publient les données brutes. De plus, les I-quants ont un coût : lors des tests, l'inférence ralentit de 5 à 10 %.
Là où GGUF s'incline, c'est lors du service multi-utilisateurs : la documentation de vLLM le qualifie d'extrêmement expérimental et peu optimisé, nécessitant aujourd'hui un plugin externe. La contrepartie, précieuse pour un usage individuel, est qu'un modèle plus volumineux que la mémoire vidéo peut tout de même s'exécuter en répartissant la charge entre GPU et CPU au détriment de la vitesse.
GPTQ et AWQ, les chevaux de trait
Imaginez un menuisier devant réduire cent planches à des épaisseurs standardisées : GPTQ, en les découpant une à une, corrige les coupes suivantes pour compenser l'erreur commise. Hors métaphore, selon le papier de recherche, il s'agit d'une méthode en une passe (one-shot) utilisant une information de second ordre pour décider des arrondis couche par couche, sur la base d'un court échantillon de calibration (128 extraits de 2048 jetons). Sur OPT-175B, la perplexité passe de 8,34 à 8,37 avec GPTQ en 4 bits, alors qu'un simple arrondi la porte à 10,54 ; en 3 bits, l'arrondi s'effondre au-delà de 7000, tandis que GPTQ se maintient à 8,68. Un modèle de 175 milliards de paramètres se compresse en quatre heures environ sur un seul GPU. Les accélérations annoncées—3,25 fois sur A100 et 4,5 fois sur A6000 par rapport au FP16—s'appliquent pour des requêtes individuelles et découlent d'un volume de données déplacé plus faible en mémoire, et non d'une réduction des calculs, comme le soulignent les auteurs parmi les limites.
AWQ, conçu par le groupe de Song Han au MIT et récompensé par le prix du meilleur papier à MLSys 2024, repose sur un constat : tous les poids n'ont pas la même importance, et protéger environ 1 % d'entre eux réduit considérablement l'erreur. L'astuce réside dans leur identification—en observant les activations plutôt que les poids—et dans la méthode de protection : non pas en les conservant avec une précision en bits supérieure, me en les appliquant à une transformation équivalente afin de maintenir un format uniforme. Sans rétropropagation, soutiennent les auteurs, le modèle généralise mieux sans surajustement à l'échantillon de calibration, et leur moteur TinyChat dépasse de plus de trois fois la vitesse d'exécution de l'implémentation FP16 de Hugging Face.
Qui l'emporte ? Les sources ne désignent aucun vainqueur tranché : chaque étude compare sa méthode au FP16 ou à l'arrondi simple, et non à l'autre méthode sur un moteur identique. Vous les croiserez principalement au sein de vLLM et SGLang, où la gestion de requêtes simultanées est requise.
Le terrain des outils s'avère plus instable. Une proposition sur le dépôt vLLM note qu'AutoGPTQ et AutoAWQ ne sont plus maintenus et que les chargeurs GPTQ et AWQ subsisteront temporairement pour des raisons de compatibilité avec les modèles publiés, avant d'être retirés ; la documentation indique d'ailleurs qu'AutoAWQ est obsolète et recommande llm-compressor. De son côté, GPTQModel affirme avoir remplacé ces composants au sein de Transformers, Optimum et PEFT. Le conseil pratique : vérifiez quel outil a été utilisé et à quelle date a été produit un modèle 4 bits, car un format très répandu n'est pas forcément activement maintenu.
EXL3, NF4, MLX : les spécialistes
Pour exploiter pleinement une carte graphique NVIDIA grand public en solo, vous rencontrerez ExLlamaV3. Son format EXL3 s'appuie sur QTIP, une technique issue de l'Université Cornell, et selon son README, la conversion s'effectue avec le seul modèle d'origine et le nombre de bits souhaité (y compris fractionnaire) : quelques heures sur une RTX 4090 pour un modèle de 70B, contre environ 720 heures de GPU A100 (soit 850 dollars) attribuées à AQLM dans le README. Le fait le plus cité reste anecdotique : Llama-3.1-70B conserve sa cohérence à 1,6 bit par poids et, avec la couche de sortie à 3 bits et un cache de contexte de 4096 jetons, tient dans moins de 16 Go de VRAM. Cohérent ne signifie pas évalué par benchmark : il ne s'agit pas d'un score mesuré. Limites : CUDA 12.4+ est requis et la prise en charge de ROCm figure encore parmi les chantiers à venir ; la structure d'origine des fichiers est conservée, ce qui rendrait possible son portage vers Transformers et vLLM, bien que le README l'évoque au futur.
NF4, le type 4 bits NormalFloat de bitsandbytes introduit avec QLoRA, répond à un autre besoin. Le papier montre comment affiner un modèle de 65 milliards de paramètres sur un seul GPU de 48 Go tout en conservant les performances d'un affinage complet en 16 bits : le modèle quantifié de base reste congelé et les gradients le traversent jusqu'à de petits adaptateurs entraînabiles. Il ne s'agit pas d'un format à télécharger mais d'une quantification appliquée à la volée lors du chargement, sans phase de calibration, et Marktechpost rappelle qu'elle ne garantit aucun gain de vitesse lors de l'inférence. C'est le flux de travail proposé sans ligne de commande par des outils comme Unsloth Studio.
Sur Mac, le paysage diffère. Selon la documentation de Hugging Face, MLX est le framework développé par Apple pour Apple Silicon, et MLX-LM permet de convertir et de quantifier des modèles en une seule commande, tandis que la communauté mlx-community publie des poids prêts à l'emploi. La limite réside dans le verrouillage de l'écosystème : il fonctionne exclusivement sur cette plateforme, et sur Mac, GGUF demeure une option tout aussi solide.
Le coût de la perte de précision
Au début des années 2000, William Basinski a enregistré ses Disintegration Loops en faisant tourner de vieilles bandes magnétiques qui se désagrégeaient progressivement à chaque passage : la musique naissait de la dégradation. Pour les poids d'un modèle, la perte n'a rien de poétique, mais suit la même trajectoire : légère au départ, puis brutale.
Dans le tableau de Hugging Face, sur un modèle Llama-2 de 7 milliards de paramètres, la perplexité (mesurant le degré de surprise du modèle face à un texte réel) augmente par rapport au 16 bits de 0,03 % avec Q80, 0,13 % avec Q6K, 0,39 % avec Q5KM et 1,68 % avec Q4KM, tandis que la taille du fichier passe de 13 à 4,1 Go. Plus bas, le coût s'accroît rapidement : 6,07 % avec Q3KM, et 15,3 % avec Q2_K. Il s'agit d'un modèle de 2023, et les architectures plus récentes peuvent réagir différemment.
Cependant, la perplexité demeure un indicateur sommaire. Dans l'analyse citée plus haut, Unsloth montre un cas où un fichier IQ2XXS de moins de 11 Go surpasse une version IQ3S sur des benchmarks réels (LiveCodeBench et MMLU Pro), malgré une perplexité et une divergence dégradées, rappelant que ces indices dépendent étroitement du texte de calibration utilisé (souvent Wikipedia). Bien qu'il s'agisse d'une source engagée, le message pratique reste valable : cet indicateur ne remplace pas un test sur vos propres cas d'usage. Une comparaison directe et rigoureuse entre tous ces formats à modèle, matériel et tâche identiques brille par son absence dans la littérature publique consultée.
FP4, modèles ternaires et QAT
Dans Return of the Obra Dinn, Lucas Pope a créé un univers tridimensionnel en utilisant seulement deux couleurs, et le résultat fonctionne parce que chaque pixel a été choisi avec soin. C'est l'image de cette frontière : sous la barre des 4 bits, on n'arrive pas en arrondissant, mais en concevant dès le départ.
La première évolution concerne les nombres en virgula flottante 4 bits, NVFP4 et MXFP4, qui divisent les poids en petits blocs dotés d'un facteur d'échelle propre. NVIDIA présente NVFP4 comme le format destiné à ses GPU Blackwell, offrant une réduction mémoire d'environ 3,5 fois par rapport au 16 bits et une précision généralement située à moins de 1 % du FP8, tout en recommandant une évaluation au cas par cas (données constructeur). Côté llama.cpp, un kernel CUDA générique pour NVFP4 a été intégré début avril 2026, et la pull request annonce un kernel spécifique pour Blackwell par la suite : l'accélération maximale ne concerne donc que les générations de puces récentes. Dans les tests d'Unsloth, MXFP4 utilise 4,25 bits par poids contre 4,5 pour Q4_K, avec des résultats inférieurs sur de nombreux tenseurs.
La deuxième voie réside dans le Quantization-Aware Training (QAT), qui consiste à entraîner le modèle en sachant à l'avance qu'il sera quantifié. Unsloth indique pour Gemma 3 de 12 milliards en Q4_0 un score de 67,07 % sur MMLU en 5-shot contre 67,15 % pour la version 16 bits : un écart d'un dixième de point. C'est le costume sur mesure plutôt que le vêtement retouché après coup.
La troisième voie, plus radicale, concerne les modèles ternaires. Ternary Bonsai 2 27B de PrismML, publié le 18 septembre, utilise des poids restreints aux valeurs -1, 0 ou +1, occupant 5,93 Go contre 53,80 Go en 16 bits. L'entreprise revendique 98,2 % des performances du modèle de base sur vingt benchmarks internes ; sur des tâches agentiques longues, les performances chutent toutefois aux alentours de 75 % (Terminal-Bench 2.1 : 52,8 contre 69,7), et son exécution nécessite le fork llama.cpp fourni par l'éditeur, la version officielle refusant ces fichiers.
Pour la version précédente, un développeur indépendant a publié sur GitHub un banco d'essai sur une RTX 5060 Ti de 16 Go face à une version IQ2XXS du même modèle de base. Sur la culture générale (MMLU-Redux), le résultat est une égalité statistique (0,871 contre 0,860) ; sur AIME26 avec 60 000 jetons de raisonnement, le modèle ternaire l'emporte (0,867 contre 0,633), me l'écart provient principalement de la convergence : la variante IQ2XXS raisonne plus longtemps et dépasse plus fréquemment la limite de jetons, bien que lorsqu'elle converge, ses réponses soient exactes. D'où le conseil de l'auteur : explicitez toujours le budget de raisonnement. Avertissements : auteur unique, échantillons réduits (30 problèmes sur AIME26 avec une p-value de 0,072 pour l'écart de précision), analyse orchestrée avec l'aide d'un assistant IA comme déclaré par l'auteur, et absence de revue par des pairs. De plus, pour gérer plusieurs utilisateurs en parallèle, l'auteur indique qu'il s'agit à ce jour d'un outil inadapté.
Choisir selon son matériel
Il convient de démarrer à partir du matériel disponible, comme détaillé dans le panorama des moteurs d'inférence. Si vous disposez d'un GPU AMD, à l'image de la Radeon 16 Go de notre banc d'essai, GGUF constitue la voie la plus praticable : EXL3 nécessite CUDA, tandis que llama.cpp prend en charge HIP de manière transparente. Si vous utilisez une carte NVIDIA grand public en solo, optez pour GGUF par simplicité, ou pour EXL3 si vous recherchez le débit maximal en jetons par seconde tout en acceptant un écosystème plus restreint. Si vous devez servir plusieurs utilisateurs simultanés, orientez-vous vers GPTQ ou AWQ sous vLLM et SGLang, ou vers FP8 et FP4 sur des cartes récentes. Sur Mac, le choix s'effectue entre MLX et GGUF, et pour affiner un grand modèle avec peu de VRAM, QLoRA demeure la référence.
Quelle dégradation de qualité accepter ? Une règle empirique : démarrez sur Q4KM et passez à Q5KM ou Q6_K si la mémoire le permet. Ne descendez sous la barre des 3 bits qu'avec des quantifications spécifiquement conçues pour ces niveaux (dynamiques ou ternaires), et évaluez systématiquement sur vos tâches réelles, qu'il s'agisse de code, de raisonnement ou d'une langue moins représentée dans les jeux de données comme l'italien. Les sources publiques mesurent rarement les performances sur la langue italienne : il s'agit d'une zone d'ombre dont l'évaluation vous incombe.
Règle empirique de qualité :
Qui sort gagnant de cette évolution ? L'utilisateur disposant de 16 Go de VRAM et d'ambitions sur des modèles de 27 milliards de paramètres. Les perdants sont ceux qui se fient à un chiffre unique de benchmark ou à un format isolé au sein d'un écosystème où les forks multiplient les exceptions. Des questions restent ouvertes concernant la tenue sur les contextes longs, la reproductibilité des benchmarks constructeurs et l'intégration native des modèles ternaires dans les moteurs d'inférence standards. La carte parfaite, comme le rappelait Borges, ne sert à personne : seule importe la carte qui tient dans le sac à dos et vous mène à destination.
Note technique : Les données proviennent des études de recherche, de la documentation officielle et des dépôts cités en lien, et n'ont pas fait l'objet d'une reproduction indépendante. Les chiffres du tableau Hugging Face sur Llama-2-7B datent de 2023 ; les mesures d'Unsloth, NVIDIA et PrismML émanent des créateurs de ces formats ; le banc d'essai sur Bonsai est l'œuvre d'un auteur indépendant unique sans revue par des pairs.