Comparer GGUF GPTQ et AWQ pour LLM local

La quantification réduit la précision numérique des poids d’un LLM (Large Language Model) afin de faire tenir un modèle dans moins de mémoire et de l’exécuter plus vite. Le compromis central est brutal : chaque bit retiré économise de la mémoire et de la bande passante, mais augmente le risque de dégrader le raisonnement, les langues rares, le code et le respect des consignes.

→ Lire l’explication complète de la marmotte

Le compromis mémoire, débit et qualité des quantifications

Un modèle dense stocke ses poids sous forme de nombres à virgule flottante, souvent sur 16 bits. Un modèle de 8 milliards de paramètres en FP16 (Floating Point 16 bits) exige donc environ 16 Go pour les seuls poids. Les métadonnées, le contexte et le cache d’attention s’ajoutent ensuite. La mémoire annoncée par une fiche de modèle est rarement la mémoire réellement consommée. Quelle surprise, les slides vendeurs ont oublié le cache.

Une quantification de poids remplace ces valeurs par des entiers codés sur moins de bits, accompagnés de facteurs d’échelle. En 4 bits, le même modèle descend vers 4 à 5 Go selon le format et les métadonnées. Ce n’est pas une compression sans perte : les petites variations de poids sont arrondies, parfois par blocs de poids plutôt que globalement.

La vitesse dépend davantage de la bande passante mémoire et des noyaux de calcul disponibles que du nombre de bits seul. Sur CPU (Central Processing Unit), lire quatre fois moins de données apporte souvent un gain net. Sur GPU (Graphics Processing Unit), un format 4 bits sans noyau optimisé peut être plus lent qu’un format 8 bits bien pris en charge. Une quantification n’est donc pas un bouton « accélérer ». C’est un contrat entre le format, le moteur d’inférence et le matériel.

Les quantifications 4 bits constituent le point d’équilibre habituel pour l’inférence conversationnelle locale. Descendre à 3 bits est défendable pour un assistant de recherche documentaire tolérant aux reformulations imparfaites. Descendre à 2 bits relève surtout de la démonstration matérielle, ou de l’art de découvrir que le modèle répond avec l’assurance d’un grille-pain promu consultant.

La qualité ne se mesure pas seulement par des benchmarks académiques. Une perte faible sur des questionnaires standardisés peut masquer des régressions sur les sorties structurées, le respect d’un schéma JavaScript Object Notation (JSON), les appels d’outils ou les réponses multilingues. Toute validation doit inclure les requêtes métier, les longues fenêtres de contexte et les cas où une réponse erronée est plus coûteuse qu’une absence de réponse. La page IA locale pose les autres contraintes d’exécution, notamment l’isolation réseau et le choix du moteur.

GGUF pour CPU, compatibilité et exécution hybride

GGUF est le format de distribution utilisé principalement par llama.cpp et ses dérivés. Il regroupe les poids, le vocabulaire, les paramètres d’architecture et des métadonnées dans un fichier unique. Son intérêt n’est pas une précision théorique supérieure à elle seule, mais une chaîne d’exécution mature sur CPU, Apple Silicon et GPU avec déport partiel de couches.

Les variantes Q4_K_M, Q5_K_M et Q6_K sont des quantifications par blocs. Le suffixe K désigne une famille de schémas plus élaborés que les anciens Q4_0 et Q4_1, avec plusieurs échelles dans un bloc. Le suffixe M signale un compromis mixte : certaines couches sensibles reçoivent davantage de précision. Pour un modèle généraliste, Q4_K_M est le choix par défaut défendable. Q5_K_M vaut le surcoût lorsque le modèle doit produire du code, du français précis ou du JSON strict.

GGUF domine lorsque l’infrastructure doit fonctionner sans GPU NVIDIA, lorsque la mémoire est limitée, ou lorsqu’un même artefact doit tourner sur plusieurs postes. Le chargement par mappage mémoire réduit la copie initiale en mémoire vive, mais n’abolit pas la pression sur le système : le cache de clés et valeurs augmente avec la longueur du contexte et le nombre de requêtes simultanées.

Le déport de couches vers GPU dans llama.cpp accélère le calcul sans exiger que tous les poids résident en mémoire vidéo. Il introduit toutefois des transferts entre mémoire système et GPU. Si seules quelques couches tiennent en VRAM (Video Random Access Memory), le gain peut devenir marginal, voire négatif selon le bus et le contexte. Mesurer les jetons par seconde et la latence du premier jeton, pas seulement admirer l’occupation GPU dans un tableau de bord.

GGUF ne garantit ni l’origine du modèle, ni l’absence de comportement malveillant, ni la confidentialité des requêtes. Le format transporte un modèle, pas une politique de sécurité. Les données saisies dans une interface locale restent exposées aux journaux applicatifs, aux exports de traces et aux plugins connectés.

GPTQ et AWQ pour GPU NVIDIA

GPTQ (Generative Pre-trained Transformer Quantization) est une méthode de quantification après entraînement. Elle traite les poids couche par couche et minimise l’erreur de reconstruction à partir d’un jeu de calibration. Elle est généralement distribuée avec les tenseurs au format safetensors, pas dans un conteneur unique imposant un moteur précis. Les paramètres déterminants sont le nombre de bits, la taille de groupe et l’activation order, souvent notée act-order.

Une taille de groupe de 128 signifie qu’un facteur d’échelle est partagé par 128 poids. Des groupes plus petits préservent mieux la qualité mais ajoutent des métadonnées et compliquent les noyaux de calcul. GPTQ en 4 bits, groupe 128, reste un profil équilibré sur GPU NVIDIA lorsque le moteur fournit des noyaux dédiés, par exemple ExLlamaV2 ou vLLM (Virtual Large Language Model). Sans ce support, le fichier GPTQ n’est qu’un paquet de poids compact qui attend tristement un noyau capable de le lire.

AWQ (Activation-aware Weight Quantization) protège les poids associés aux activations les plus fortes observées pendant la calibration. Cette stratégie conserve souvent mieux la qualité à 4 bits sur les modèles instruction-tuned, surtout pour les sorties longues. AWQ privilégie cependant l’écosystème CUDA (Compute Unified Device Architecture) et les moteurs exploitant ses noyaux 4 bits, notamment ceux compatibles Marlin ou AutoAWQ.

Entre GPTQ et AWQ, le choix dépend du moteur retenu, pas d’un slogan sur la qualité. AWQ est préférable lorsqu’un serveur GPU NVIDIA moderne, un moteur AWQ maintenu et un profil de requêtes stable sont disponibles. GPTQ reste valable si le moteur cible dispose de meilleurs noyaux GPTQ ou si le modèle fournisseur est déjà calibré et testé dans ce format. Requantifier un modèle disponible en AWQ vers GPTQ pour « uniformiser » le stockage ajoute une perte sans bénéfice automatique.

Ni GPTQ ni AWQ ne sont de bons formats universels pour ordinateur portable CPU. Les faire tourner sans noyau GPU dédié revient à installer un moteur de course sur une péniche : techniquement possible dans certains cas, architecturalement absurde dans presque tous.

Critère	GGUF	GPTQ	AWQ
Cible principale	CPU, Apple Silicon, GPU hybride	GPU NVIDIA	GPU NVIDIA
Distribution	Fichier unique avec métadonnées	Tenseurs et configuration	Tenseurs et configuration
Profil 4 bits courant	Q4_K_M	4 bits, groupe 128	4 bits, groupe 128
Point fort	Portabilité et maturité locale	Large compatibilité de moteurs GPU	Qualité 4 bits avec noyaux récents
Risque principal	Débit CPU insuffisant à forte concurrence	Noyau non compatible ou dégradé	Dépendance accrue à CUDA et aux versions

Mesurer GGUF, GPTQ et AWQ avant de standardiser

Le test doit fixer le modèle de base, le modèle de prompt, la température, la taille de contexte et la version exacte du moteur. Comparer des jetons par seconde entre deux interfaces ayant des modèles de chat différents ne mesure rien, sauf la capacité collective à produire des graphiques décoratifs.

Mesurer au minimum quatre points : délai avant le premier jeton, débit de génération, consommation mémoire maximale et taux d’échec sur un corpus de réponses attendues. Ajouter une mesure de conformité syntaxique pour le JSON, car les erreurs de ponctuation apparaissent souvent avant les erreurs de contenu visibles.

Le cache KV (Key-Value cache) n’est pas quantifié par défaut dans tous les moteurs. Un modèle en 4 bits peut donc échouer par manque de VRAM sur un contexte long, malgré des poids confortablement chargés. Réduire la taille du contexte, activer une quantification du cache lorsqu’elle est prise en charge, ou limiter la concurrence sont les seules réponses honnêtes. Acheter un modèle 4 bits ne crée pas de mémoire par génération spontanée.

Exemple reproductible avec GGUF et llama.cpp

Cet exemple mesure un modèle GGUF avec un prompt déterministe. La commande suppose un binaire llama-cli compilé depuis llama.cpp et un fichier de modèle local. Fixer le nombre de jetons et désactiver l’aléa permet de comparer les variantes Q4_K_M et Q5_K_M dans les mêmes conditions.

# Exécuter exactement le même prompt sur un modèle GGUF.
# -ngl 99 déporte toutes les couches possibles vers le GPU.
# Remplacer 99 par 0 pour une mesure strictement CPU.
# -c fixe la fenêtre de contexte et -n limite la génération.
./llama-cli \
  -m ./models/modele-q4_k_m.gguf \
  -ngl 99 \
  -c 4096 \
  -n 256 \
  --temp 0 \
  -p "Retourner uniquement un objet JSON contenant les champs service et criticite."

Répéter au moins cinq fois après un premier lancement de chauffe. Les premières lectures incluent les défauts de cache du système de fichiers et l’initialisation GPU. Conserver les journaux bruts, la somme SHA-256 du fichier et la version du binaire. Sans ces trois éléments, une comparaison est impossible à reproduire et mérite le même statut qu’une prédiction astrologique sous Grafana.

Surface d’attaque et exploitation des modèles quantifiés

Un fichier quantifié est un artefact logiciel non fiable jusqu’à vérification cryptographique. Télécharger un GGUF ou un dépôt safetensors depuis une source non contrôlée expose au remplacement de modèle, à une corruption de poids ou à l’exploitation d’un parseur vulnérable. Vérifier une empreinte SHA-256 fournie par un canal distinct, conserver un manifeste signé et bloquer les téléchargements implicites au démarrage.

Préférer safetensors aux archives exécutables et refuser tout chargement Python fondé sur pickle, qui peut exécuter du code à la désérialisation. GGUF n’exécute pas du code Python par nature, mais le moteur qui analyse ses métadonnées reste une surface d’attaque. Isoler le processus, appliquer les correctifs du moteur et imposer des limites de mémoire, de contexte et de durée d’exécution.

La quantification ne neutralise pas l’injection de prompt, l’exfiltration par connecteur, les réponses inventées ni les attaques par épuisement de ressources. Une instruction hostile dans un document indexé reste hostile après passage en 4 bits. La protection doit venir de l’isolation des outils, de listes d’autorisations d’actions, de filtres de sortie et d’une journalisation expurgée des données sensibles.

Prévoir la rotation des jetons d’accès aux dépôts, le chiffrement des volumes contenant les modèles propriétaires, des sauvegardes vérifiées des manifestes et une procédure de retour vers une version connue. Les modèles sont volumineux, mais leur provenance est plus précieuse que leur taille. Un stockage objet versionné avec rétention est préférable à un répertoire partagé nommé final-vraiment-final.

🦫 Explication de la marmotte 🍫

Un modèle de langage contient des milliards de nombres qui déterminent les mots qu’il choisit. Dans sa version complète, chaque nombre prend beaucoup de place en mémoire. La quantification réduit la place occupée par ces nombres en gardant moins de précision. Avant de lancer le modèle, un programme lit le fichier, charge ses paramètres dans la mémoire de l’ordinateur ou de la carte graphique, puis prépare une zone de mémoire pour retenir les éléments déjà lus dans la conversation.

GGUF sert surtout quand le calcul se fait sur le processeur ou sur plusieurs types de matériel. Il propose plusieurs niveaux de réduction. GPTQ et AWQ servent surtout avec des cartes graphiques NVIDIA. Ils stockent aussi des nombres réduits, mais leur lecture dépend de programmes de calcul spécialisés. Si le programme ne connaît pas le format, le modèle ne démarre pas ou perd son avantage de vitesse.

Réduire trop fortement la précision fait perdre des détails. Le modèle peut alors écrire un mauvais format de données, suivre moins bien une consigne, produire du code incorrect ou répondre moins bien dans certaines langues. Il faut donc tester les mêmes demandes avec chaque version, mesurer le temps de réponse et vérifier les résultats attendus.

Un fichier de modèle peut être falsifié ou abîmé. Il faut contrôler son empreinte numérique, limiter les droits du programme qui le charge et garder une copie vérifiée. Réduire la taille du modèle ne protège pas les informations saisies ni les réponses fausses. Ces risques demandent des contrôles séparés.

Pages voisines

La citent

Comparer GGUF GPTQ et AWQ pour LLM local

Elle cite

: les deux pages se citent l’une l’autre.

Comparer GGUF GPTQ et AWQ pour LLM local

Comparer GGUF GPTQ et AWQ pour LLM local

Le compromis mémoire, débit et qualité des quantifications

GGUF pour CPU, compatibilité et exécution hybride

GPTQ et AWQ pour GPU NVIDIA

Mesurer GGUF, GPTQ et AWQ avant de standardiser

Exemple reproductible avec GGUF et llama.cpp

Surface d’attaque et exploitation des modèles quantifiés

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines