AWQ vs GPTQ : comparatif complet des méthodes de quantization pour l’inférence LLM

Principes fondamentaux de la quantization : pourquoi quantiser un modèle de langage ?

Faire tourner un grand modèle de langage (LLM) est une opération extrêmement gourmande en mémoire. Par défaut, les poids d’un modèle sont stockés en FP16 (virgule flottante 16 bits), ce qui représente 2 octets par paramètre. Pour un modèle de 70B paramètres, cela signifie qu’il faut environ 140 Go de VRAM simplement pour charger les poids, sans compter les activations et le contexte. Une telle capacité est hors de portée pour la plupart des configurations, même professionnelles.

La quantization répond à ce problème en réduisant la précision numérique des poids, une étape clé de la quantization des modèles IA. Au lieu de stocker chaque valeur sur 16 ou 32 bits, on la convertit en entier 8 bits (INT8) ou 4 bits (INT4). Cette compression permet de diviser l’empreinte mémoire par 4x : le même modèle 70B passe alors de 140 Go à environ 35 Go de VRAM, le rendant exécutable sur une seule carte professionnelle ou même sur du matériel grand public haut de gamme.

Qu’est-ce que la quantization et pourquoi réduire la précision ?

Le principe est simple : on établit une plage de valeurs réelles (par exemple, les poids FP16 d’une couche) et on les projette sur une échelle discrète de 16 ou 256 niveaux. La granularité de cette projection varie : on peut quantiser par tenseur entier, par canal (chaque neurone a sa propre échelle), ou par groupe de 32 à 128 poids. Plus la granularité est fine, meilleure est la précision, mais plus l’overhead de calcul est élevé.

L’intérêt ne se limite pas à la mémoire. Un modèle quantisé en 4 bits voit son débit augmenter de 13 à 15 % par rapport à une version bf16, car les calculs sur entiers sont plus rapides, une accélération comparable à celle du speculative decoding, et les transferts mémoire réduits. C’est un levier majeur pour améliorer la latence perçue par l’utilisateur final.

L’impact sur la qualité et les performances

La question centrale est : que perd-on en précision ? Les études convergent vers un constat rassurant : une quantization 4 bits bien menée préserve environ 95 % des performances du modèle d’origine. Concrètement, on observe une perte de 0,5 à 3 points de perplexité (une métrique de fluidité du langage) et une baisse de 0,5 à 1,5 % sur le benchmark MMLU pour les modèles de 13B paramètres et plus. Pour une majorité de cas d’usage génération, résumé, extraction d’information cette dégradation est imperceptible.

Il faut néanmoins distinguer les niveaux de précision. Le FP8 (8 bits) est devenu la référence quand la qualité est prioritaire, car il exploite les Tensor Cores des GPU récents et n’ajoute quasiment aucune erreur. Le 4 bits reste le meilleur compromis pour maximiser la réduction mémoire et la vitesse, au prix d’une attention particulière à la méthode de quantization choisie, comme le réglage de la température ou du top-p pour affiner le comportement du modèle, c’est précisément ce que nous allons comparer dans la suite de cet article avec AWQ et GPTQ.

Comparaison AWQ vs GPTQ vs GGUF : différences techniques et performances

Le choix entre ces trois formats repose sur un arbitrage simple : AWQ privilégie la vitesse et la qualité pour un usage GPU de production, GPTQ offre la maturité et le plus grand catalogue avec plus de 5x plus de modèles disponibles que AWQ, tandis que GGUF reste le seul format viable pour le CPU et les machines Apple Silicon.

Cette flexibilité matérielle rappelle la souplesse offerte par GraphQL dans le choix des endpoints d’une API, où l’on adapte la requête aux besoins plutôt que de subir une structure rigide.

AWQ excelle car il préserve les activations critiques du modèle en appliquant un scaling intelligent sur les 1 % de poids saillants. Résultat : un throughput supérieur de 20 à 50 % par rapport à GPTQ et jusqu’à 218 tokens/s sur un GPU grand public, avec une dégradation quasi imperceptible de 0,5 % par rapport à un modèle FP16.

GPTQ compense l’erreur de quantization couche par couche à l’aide de la matrice Hessienne, ce qui demande une calibration sur 128 à 256 échantillons. Son principal avantage reste son écosystème : les 10 000 modèles pré-quantifiés rendent son adoption immédiate, sans phase de conversion.

AWQ : activation-aware weight quantization fonctionnement, forces et limites

Comment fonctionne le scaling activé par l’activation ?

Proposée par l’équipe de Song Han au MIT, la méthode AWQ (Activation-aware Weight Quantization) repose sur une observation clé : tous les poids d’un réseau ne se valent pas. En analysant les activations, l’algorithme identifie environ 1 % de poids « saillants » qui concentrent l’essentiel de l’information. Plutôt que de les préserver en mixed-precision ce qui complexifie l’implémentation AWQ applique un scaling dépendant des activations sur ces poids critiques.

Ce scaling réduit l’erreur de quantization pour les canaux sensibles, sans coût d’inférence supplémentaire. La technique est particulièrement efficace : la dégradation mesurée par rapport à un modèle en FP16 est inférieure à 0,5 % en moyenne, même en précision 4 bits. Le processus de quantization reste rapide, de l’ordre de quelques minutes, car il ne nécessite pas de rétropropagation ni de calcul de Hessienne, contrairement à d’autres approches.

Performance, écosystème et cas d’usage

Les résultats d’inférence placent AWQ parmi les méthodes les plus rapides du marché. Les benchmarks comparatifs montrent un throughput supérieur de 20 à 50 % par rapport à GPTQ dans des conditions identiques, avec des pointes à 218 tokens/s sur un GPU grand public (RTX 4090). Cette efficacité s’explique par des kernels optimisés qui exploitent pleinement le matériel, particulièrement pour les batchs de taille réduite à moyenne.

Côté écosystème, AWQ dispose de plus de 2 000 modèles pré-quantifiés sur Hugging Face et d’un support natif dans vLLM, ce qui en fait un choix crédible pour la production. Attention toutefois : la bibliothèque AutoAWQ est encore moins répandue que son homologue GPTQ, et le format n’est pas compatible avec un déploiement CPU. En résumé, AWQ s’impose comme la meilleure option pour les serveurs d’inférence GPU où la vitesse prime, mais exige une configuration NVIDIA récente pour libérer tout son potentiel.

GPTQ : quantization par compensation d’erreur fonctionnement, forces et limites

Développée par Frantar et al., GPTQ repose sur une approche par compensation d’erreur. Plutôt que de protéger certains poids comme AWQ, elle minimise l’erreur de quantization couche par couche en s’appuyant sur la matrice Hessienne (H = XᵀX). Cette méthode nécessite une phase de calibration sur 128 à 256 échantillons (C4, WikiText-2), ce qui rend la quantization d’un modèle 70B relativement longue : comptez 2 à 4 heures sur une A100.

Son principal atout réside dans son écosystème mature : plus de 10 000 modèles GPTQ pré-quantifiés sont disponibles sur Hugging Face, soit environ 5x plus que pour AWQ. Les kernels Marlin apportent une accélération jusqu’à 2,8x par rapport aux kernels standard, avec une perte de qualité contenue (environ 0,5 à 3 points de perplexité).

La limite majeure est l’absence de support CPU natif : GPTQ exige un GPU. La précision minimale viable est de 3 bits, mais la qualité se dégrade nettement en dessous de 4 bits. Pour un usage serveur avec GPU dédié, GPTQ reste un choix robuste et polyvalent.

Implémentation pratique : quantiser et servir avec AutoAWQ, AutoGPTQ et vLLM

Quantizer un modèle avec AutoGPTQ et AutoAWQ

La mise en œuvre concrète repose sur deux bibliothèques de référence : AutoGPTQ et AutoAWQ. Le processus est identique pour les deux : installer la bibliothèque, charger le modèle depuis Hugging Face, calibrer, puis lancer la quantization.

• Installer : pip install autoawq ou pip install auto-gptq selon la méthode choisie.
• Charger le modèle source en FP16 depuis Hugging Face, par exemple Llama 3.1 70B.
• Calibrer avec 128 à 256 échantillons issus de C4 ou WikiText-2 pour GPTQ.
• Lancer la quantization : comptez 2 à 4 heures pour un modèle 70B sur A100.
• Exporter le checkpoint quantisé au format 4 bits, prêt pour l’inférence.

Servir les modèles quantisés en production avec vLLM

Une fois le checkpoint généré, vLLM charge nativement les formats AWQ, GPTQ et FP8 sans conversion supplémentaire. Côté throughput, AWQ affiche une avance de 20 à 50 % sur GPTQ, avec un débit mesuré à 218 tokens/s sur GPU consumériste.

Le serveur intègre également les kernels Marlin pour GPTQ, dont l’accélération atteint 2,8x par rapport aux kernels standard. Pour un déploiement via TGI, la configuration se réduit à pointer le répertoire du checkpoint quantisé : l’optimisation mémoire s’applique automatiquement, avec une division par 2,9 de la VRAM nécessaire pour les poids en 4 bits.

Benchmarks concrets : vitesse, qualité, mémoire et perplexité

Pour arbitrer entre AWQ et GPTQ, rien ne vaut les mesures réelles. Les tests comparatifs menés sur des modèles comme Llama 3.1 70B et Qwen 14B permettent de trancher selon vos priorités : vitesse d’inférence, qualité générative ou empreinte mémoire.

La première observation porte sur la mémoire : passer en 4 bits divise la VRAM par 2,9x, et un modèle 70B qui exigeait 140 Go en FP16 tient désormais dans 35 Go. Sur une configuration de test avec deux RTX 4090 (48 Go cumulés), cela rend possible l’inférence locale de très gros modèles, là où le FP16 exigeait 4x A100.

Côté qualité, la dégradation reste minime : les formats 4 bits n’ajoutent que 0,25 à 0,38 points de perplexité sur WikiText-2, et la meilleure valeur AWQ atteint 5,78 contre 5,53 pour le FP16. Sur des benchmarks de raisonnement comme MMLU, la perte se situe entre 0,5 et 1,5 % pour les modèles de 13B et plus, ce qui représente un sacrifice acceptable au regard du gain en ressources.

Enfin, la vitesse d’inférence distingue nettement les méthodes : les formats 4 bits offrent un gain de débit de 13 à 15 % par rapport au bf16, et AWQ surpasse GPTQ de 20 à 50 % en throughput. Sur un GPU grand public, AWQ atteint ainsi 218 tokens/s, une performance remarquable pour une dégradation typique de seulement 0,5 % par rapport au FP16. Si vous utilisez des kernels Marlin avec GPTQ, comptez toutefois une accélération de 2,8x par rapport aux kernels standard, ce qui réduit sensiblement l’écart.

Guide de choix pour la production : quelle méthode adopter selon votre matériel ?

Le choix entre AWQ, GPTQ et GGUF ne se résume pas à une question de goût : il dépend avant tout de votre infrastructure et de votre cas d’usage. Voici une feuille de route concrète, basée sur les compromis mesurés en production.

• GPU NVIDIA haute performance (A100, H100) → AWQ. Pour un serveur dédié avec un batch élevé, AWQ offre un throughput supérieur de 20 à 50 % par rapport à GPTQ, tout en maintenant une dégradation inférieure à 0,5 % face au FP16.
• GPU NVIDIA avec batch important (A10, L4, RTX 4090) → GPTQ avec kernels Marlin. Sur du batch élevé, Marlin accélère l’inférence d’un facteur 2,8x par rapport aux kernels standard, et l’écosystème Hugging Face compte 5x plus de modèles GPTQ pré-quantifiés (plus de 10 000) qu’AWQ.
• CPU ou Apple Silicon → GGUF. C’est le seul format qui tourne nativement sur CPU et en offloading hybride via llama.cpp. Idéal pour Ollama et l’usage local, au prix d’une perte d’environ 3 points sur HumanEval sur le format Q4_K_M.
• Serveur vLLM ou TGI en production → AWQ. vLLM charge nativement AWQ, GPTQ et FP8, mais en pratique AWQ se révèle légèrement plus rapide que GPTQ/Marlin sur du serving continu, avec une perplexité de 5,78 sur WikiText-2 contre 5,53 pour le FP16 de référence.
• Priorité absolue à la qualité → FP8. Pour un modèle 70B qui passe de 140 Go en FP16 à environ 70 Go en 8 bits, vous conservez une qualité quasi identique au FP16 avec un gain de débit de 49 % grâce aux Tensor Cores.

Si votre GPU dispose de 24 Go de VRAM (comme une RTX 4090), un modèle 7B en 4 bits tient confortablement, mais un 70B nécessitera une configuration à 48 Go (double GPU) ou un passage en 8 bits pour rester sous les 70 Go nécessaires.

Pour un déploiement rapide avec un excellent compromis vitesse/qualité, commencez par AWQ 4 bits sur NVIDIA. Si vous visitez Hugging Face et privilégiez la variété de modèles prêts à l’emploi, GPTQ reste un choix sûr surtout pour des batchs importants où Marlin excelle.