Quantization LLM : choisir entre GGUF, AWQ, GPTQ et FP8

Choisissez la précision la plus élevée qui permet d’exécuter votre charge de travail et satisfait vos propres critères de qualité. Un téléchargement plus léger n’a d’intérêt que si le modèle répond toujours correctement et laisse assez de mémoire pour la conversation.

La documentation et les informations de compatibilité ont été vérifiées sur les pages officielles des projets le 20 octobre 2026. Les chiffres de mémoire sont calculés à partir du nombre de paramètres documenté de Qwen2.5-7B-Instruct : ce ne sont ni des mesures d’utilisation du GPU ni des résultats de benchmark.

Quantization LLM : moins de précision, une architecture inchangée

La quantification stocke les valeurs apprises par le modèle avec moins de bits. Un grand modèle de langage, ou LLM, génère du texte à l’aide de paramètres numériques appris, appelés poids. Réduire leur précision diminue le coût de leur stockage et de leur transfert, au prix d’une erreur d’approximation. La présentation de la quantification par Hugging Face décrit ce compromis entre mémoire et exactitude.

Imaginez un plan d’architecte dont les cotes sont consignées avec une grande précision. Arrondir les mesures permet de les noter plus brièvement, mais modifie légèrement certaines dimensions. Le bâtiment conserve pourtant les mêmes pièces. De même, la quantification classique des poids ne réduit ni le nombre de couches ni le nombre de paramètres appris d’un grand modèle : elle change la précision avec laquelle ses poids sont représentés.

L’analogie a ses limites : la quantification ne consiste pas simplement à supprimer des décimales. Les valeurs peuvent être regroupées, associées à un facteur d’échelle, puis ramenées à un ensemble plus restreint de valeurs représentables. Ce facteur permet au moteur d’exécution de retrouver une approximation au moment du calcul. Les parties importantes peuvent conserver une précision supérieure. L’explication d’IBM détaille ces correspondances et l’erreur qui en résulte.

Avant de choisir un fichier à télécharger, distinguez trois éléments :

• Les poids : les valeurs apprises, stockées avec le modèle.
• Les activations : les valeurs intermédiaires produites lors du traitement de votre entrée.
• Le cache KV : les données d’attention conservées pour le contexte déjà traité, qui occupent davantage de mémoire à mesure que la conversation s’allonge.

Une quantification limitée aux poids réduit la première catégorie. Elle ne réduit pas automatiquement les deux autres. Voilà pourquoi un modèle peut se charger correctement, puis manquer de mémoire sur une requête longue. La documentation d’Ollama sur la mémoire et le cache traite séparément la capacité de contexte et la précision du cache.

Quantification après entraînement ou entraînement tenant compte de la quantification ?

Pour un développeur qui télécharge un modèle, la quantification après entraînement est généralement le point de départ pertinent. La quantification après entraînement, ou PTQ, convertit un checkpoint déjà entraîné. Certaines méthodes utilisent des données de calibration : des entrées représentatives qui aident à déterminer comment approximer les poids. L’entraînement tenant compte de la quantification, ou QAT, intègre les effets de la faible précision pendant l’entraînement ou le fine-tuning. IBM décrit les deux approches.

Il n’est pas nécessaire d’entraîner un modèle pour utiliser un checkpoint quantifié déjà publié. En revanche, il faut connaître son modèle d’origine, la méthode et les réglages qui ont servi à le produire, ainsi que le moteur capable de le charger. Un nom de fichier ne remplace pas ces informations.

GGUF, AWQ, GPTQ et FP8 : quel moteur pour quel format ?

Ces noms désignent des éléments de nature différente : ce ne sont pas des options interchangeables. GGUF est un conteneur. AWQ et GPTQ sont des méthodes de quantification. FP8 est un format numérique. Un checkpoint est une sauvegarde du modèle qui rassemble les poids et les informations nécessaires à leur chargement.

Hugging Face, plateforme d’hébergement de modèles et développeur de Transformers, documente les formats de fichiers comme les méthodes de chargement. Le tableau rapproche cette documentation de celle des moteurs d’exécution. Il sert à orienter le choix, sans garantir que chaque architecture de modèle fonctionne avec toutes les configurations indiquées.

L’extension .safetensors ne permet pas non plus de connaître la précision. Elle désigne un format de stockage des tenseurs. Pour savoir comment ces tenseurs sont représentés et quel chargeur utiliser, lisez la configuration de quantification et la fiche du modèle. La documentation GGUF de Hugging Face distingue les métadonnées du conteneur des données des tenseurs, tandis que son guide AWQ présente les champs pertinents de quantization_config.

Que signifie Q4_K_M ?

Q4_K_M est un préréglage à précision mixte, pas la garantie que chaque paramètre occupe exactement quatre bits. Q4 désigne la famille nominale à quatre bits, K le schéma de blocs K-quant et M le préréglage intermédiaire. Certains tenseurs peuvent conserver une précision supérieure selon l’architecture du modèle et les règles du quantificateur. L’implémentation de la quantification dans llama.cpp explicite ces choix.

Même un simple bloc Q4_K contient des informations auxiliaires : le tableau d’encodage des tenseurs du projet indique 4.5 bits par poids une fois inclus les facteurs d’échelle et les informations de minimum. Ce chiffre concerne le bloc ; ce n’est pas la moyenne de tous les modèles Q4_K_M.

Sur une machine locale aux ressources limitées, Q4_K_M constitue un candidat raisonnable à évaluer. Si une variante plus précise tient en mémoire avec le contexte prévu, comparez-la également. Ne sacrifiez pas la qualité des réponses simplement parce qu’un fichier plus petit existe.

Estimer la mémoire : le cas de Qwen2.5-7B-Instruct

Partez du nombre total de paramètres, puis ajoutez la mémoire nécessaire à l’exécution. Qwen2.5-7B-Instruct, le modèle de Qwen ajusté au suivi d’instructions qui sert ici d’exemple concret, compte 7.61 milliards de paramètres au total. Sa fiche indique séparément 6.53 milliards de paramètres hors embeddings : utiliser ce chiffre inférieur ferait oublier une partie du modèle stocké. Fiche du modèle Qwen.

Le calcul théorique est le suivant :

Taille des poids en octets ≈ nombre de paramètres × bits par paramètre ÷ 8

En 16 bits, le calcul donne 7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytes. Reprenons-le pour les autres précisions :

Il s’agit de nos calculs à partir du nombre arrondi de paramètres indiqué dans la fiche du modèle, en supposant que tous les paramètres utilisent la largeur annoncée. Les GB décimaux correspondent au nombre d’octets divisé par 1,000,000,000 ; les GiB, au nombre d’octets divisé par 1,073,741,824. Le changement d’unité modifie le chiffre affiché, pas la quantité de mémoire.

Le tableau exclut volontairement les facteurs d’échelle de quantification, les tenseurs de précision supérieure, les métadonnées du fichier, le cache, les activations, les buffers de travail temporaires et la mémoire réservée par le moteur. La taille d’un fichier Q4_K_M à télécharger ne correspondra donc pas à la ligne théorique en quatre bits. Cette ligne ne prouve pas non plus que le modèle fonctionnerait sur un GPU hypothétique de 4 GB.

Pour un assistant de programmation local, une courte conversation ne suffit donc pas à tester la capacité. Un test utile inclut les fichiers source, les instructions et la longueur de réponse que vous comptez utiliser. Pour un serveur, ajoutez les requêtes simultanées. Ollama documente explicitement l’effet des requêtes parallèles et de l’allocation du contexte sur la mémoire.

Consultez le guide du cache KV pour calculer séparément la mémoire du contexte. La quantification des poids et celle du cache sont deux réglages distincts ; vLLM documente aussi la quantification du cache KV comme une fonctionnalité à part entière.

Choisir le format en fonction du moteur d’exécution

Choisissez le mode d’exécution avant la précision affichée. La compatibilité est impérative. Une fois celle-ci assurée, arbitrez selon la mémoire disponible, la qualité des réponses et la latence mesurée sur votre charge de travail.

llama.cpp : partir d’un GGUF compatible

llama.cpp, un moteur d’inférence local, permet d’utiliser directement GGUF lorsque vous souhaitez maîtriser le fichier du modèle et sa répartition sur le matériel. La documentation du projet mentionne l’exécution sur CPU, la prise en charge d’Apple silicon et l’exécution mixte CPU/GPU. C’est utile lorsque tous les poids du modèle ne peuvent pas résider sur un GPU dédié. Documentation du projet llama.cpp.

Sa limite : réussir à charger le modèle ne garantit pas une vitesse exploitable. Une répartition entre CPU et GPU change les conditions d’exécution ; il faut toujours mesurer le traitement de vos propres prompts et réponses. Choisissez d’abord l’architecture du modèle, ensuite un GGUF compatible, puis un préréglage de quantification.

Le guide des meilleurs LLM locaux du site vous aidera à sélectionner le modèle de départ. La quantification ne peut pas rendre un modèle inadapté capable de comprendre une tâche qu’il maîtrise mal avec une précision supérieure.

Ollama : importer le modèle avec la quantification voulue

Ollama, un outil d’exécution de modèles en local, peut importer un GGUF préparé, mais l’import ne le quantifie pas. Son guide d’import actuel demande de préparer d’abord le fichier quantifié. C’est un point essentiel si vous pensez qu’une commande d’import convertira automatiquement un modèle de précision supérieure en Q4_K_M. Documentation d’import d’Ollama.

Une fois Ollama installé et un fichier compatible, déjà quantifié, enregistré sous le nom model.gguf dans le répertoire courant, la procédure documentée donne :

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

Exécutez ollama ps dans un autre terminal pour examiner la répartition CPU/GPU du modèle chargé. Cela vérifie ce qui a été chargé ; ce n’est pas un benchmark de qualité. FAQ d’Ollama.

Ollama reste limité par les besoins en mémoire de la charge de travail. Une commande pratique ne dispense pas de prévoir la mémoire du contexte et des requêtes concurrentes. Le comparatif Ollama et llama.cpp explique quel niveau de contrôle choisir sur les fichiers du modèle et le moteur d’exécution.

vLLM : faire correspondre checkpoint, noyau de calcul et GPU

vLLM, un moteur d’inférence et de mise à disposition de modèles, exige un checkpoint quantifié correspondant à un mode d’exécution pris en charge. Partez du fichier AWQ, GPTQ ou FP8 pris en charge par l’éditeur du modèle, puis vérifiez votre GPU dans la matrice matérielle de vLLM. Un noyau de calcul, ou kernel, est l’implémentation de bas niveau qui permet d’exécuter efficacement un format sur ce matériel.

Pour de nouveaux travaux de quantification AWQ, la documentation actuelle oriente vers LLM Compressor. AutoAWQ est déprécié ; AWQ existe toujours en tant que méthode et famille de checkpoints. Pour GPTQ dans Transformers, le backend maintenu est GPTQModel, et la compatibilité peut dépendre des réglages du checkpoint. Recommandations AWQ de vLLM, recommandations GPTQ de Hugging Face.

FP8 demande une distinction supplémentaire. W8A8 désigne des poids et des activations sur huit bits ; W8A16, des poids sur huit bits et des activations sur seize bits. vLLM documente le FP8 W8A8 natif pour NVIDIA Ada, Hopper et Blackwell, tandis que Turing et Ampere peuvent utiliser un mode W8A16 via Marlin, avec la réduction de précision limitée aux poids. La mention « FP8 pris en charge » ne suffit donc pas à savoir quel mode de calcul sera utilisé. Documentation FP8 de vLLM.

Ne choisissez pas GGUF par défaut pour un déploiement vLLM simplement parce qu’il fonctionnait en local. La documentation actuelle fait passer GGUF par vllm-gguf-plugin et décrit toujours cette prise en charge comme expérimentale et insuffisamment optimisée, avec de possibles incompatibilités fonctionnelles. C’est une contrainte de migration, pas la preuve que GGUF serait intrinsèquement inférieur. Documentation GGUF de vLLM.

API hébergée : s’en tenir aux options proposées

Si une API hébergée ne propose aucun réglage de précision, vous n’avez aucun choix de quantification locale à effectuer. Lisez les spécifications du point d’accès. S’il propose des variantes de précision nommées, évaluez celle que vous sélectionnez. Sinon, évaluez les réponses et la latence du service sans supposer la représentation qu’il utilise en interne.

Un même nom de modèle ne suffit pas à déduire une quantification, un moteur ou des résultats identiques d’un fournisseur à l’autre. Ne demandez un checkpoint documenté ou une garantie de précision que si votre application en a besoin. Téléverser et servir vos propres poids relève d’un autre choix de déploiement, qui vous ramène aux questions de compatibilité du moteur et du matériel.

Mémoire, vitesse, qualité : les compromis de la quantification

Des représentations plus compactes réduisent la mémoire nécessaire ; la vitesse et la qualité doivent être évaluées séparément. Garder moins de données en mémoire peut réduire le travail de transfert des poids. Mais le moteur peut aussi devoir décompacter ou convertir ces valeurs avant les calculs. La documentation GPTQ de Hugging Face explique comment un noyau fusionné peut restaurer les poids de faible précision pour les calculs sans décompacter tout le modèle dans la mémoire globale du GPU.

C’est à la fois l’intérêt et la limite de l’approche. Un noyau pris en charge peut tirer parti de poids compacts. Un mode d’exécution inadapté peut annuler cet avantage. Mesurez le délai jusqu’au premier token, la vitesse de génération et le débit au niveau de concurrence prévu, au lieu d’assimiler la taille du fichier à un benchmark de vitesse.

La qualité dépend tout autant de l’usage. Pour un assistant de programmation, vérifiez si les modifications proposées passent les tests pertinents. Pour l’extraction documentaire, comparez les champs requis et la validité des sorties structurées. Pour un assistant multilingue, incluez les langues dans lesquelles il devra répondre. Une réponse fluide ne suffit pas à prouver que la quantification a préservé le comportement attendu pour votre tâche.

La comparaison utile porte sur le même checkpoint d’origine, d’une part à précision supérieure, d’autre part avec la quantification envisagée, en conservant les mêmes prompts, le même gabarit de conversation et les mêmes réglages de génération. Si vous comparez aussi des modèles sans rapport entre eux, vous ne pouvez pas isoler l’effet de la quantification.

Quand éviter la quantification, et quelles promesses relativiser ?

Conservez une précision supérieure lorsqu’elle tient déjà en mémoire et que la version quantifiée n’apporte aucun bénéfice mesuré en exploitation. Compresser davantage ajoute un fichier de modèle et un comportement à valider. Cette démarche doit répondre à un problème réel.

N’adoptez pas une variante moins précise si elle échoue à des vérifications importantes pour votre tâche, si son mode d’exécution est mal pris en charge ou si votre charge de travail à contexte long dépasse toujours la mémoire disponible. Dans ce dernier cas, examinez le contexte et la concurrence avant de réduire encore les poids.

Ne considérez pas non plus une version quantifiée pour l’inférence comme un checkpoint universel d’entraînement. Bitsandbytes documente la prise en charge de l’entraînement en faible précision pour des paramètres supplémentaires, tels que les poids d’adaptateurs. Il s’agit d’un workflow de fine-tuning précis : cela ne permet pas de supposer que toute version quantifiée téléchargée accepte un entraînement classique de l’ensemble des poids. Documentation bitsandbytes de Hugging Face.

Les promesses exagérées se repèrent facilement :

• « En quatre bits, toute l’application utilise quatre fois moins de mémoire. » Cela décrit le rapport théorique de largeur des poids par rapport au seize bits. La mémoire d’exécution comprend d’autres éléments.
• « Le huit bits est un format unique. » FP8, INT8 et Q8_0 correspondent à des représentations et à des modes d’exécution différents.
• « Moins de bits, c’est toujours plus rapide. » Le checkpoint, le noyau de calcul, le matériel et la charge de travail déterminent si la réduction de mémoire améliore la latence ou le débit.
• « Un grand modèle quantifié bat toujours un petit modèle plus précis. » Le nombre de paramètres et la largeur en bits ne suffisent pas à établir la qualité sur une tâche. Évaluez les deux candidats si tous deux tiennent en mémoire.

Pour sélectionner des modèles destinés à la programmation, utilisez le guide des meilleurs modèles d’IA locaux pour coder, puis comparez les variantes de quantification du checkpoint retenu sur les tâches que vous comptez lui confier.

Quantification des LLM : passer à un premier déploiement

Commencez par un fichier de modèle pris en charge et une évaluation limitée, reproductible. Gardez le même modèle d’origine jusqu’à ce que vous compreniez l’effet de la précision.

Questions fréquentes

Pour recevoir des guides pratiques sur l’exécution et le déploiement de systèmes d’IA, abonnez-vous à la newsletter.