AWQ (Activation-aware Weight Quantization)

AWQ est un algorithme de quantification post-entraînement (PTQ) qui compresse les poids d’un LLM à 4 bits en identifiant et en protégeant sélectivement les ~1 % de poids critiques via l’analyse des distributions d’activation, plutôt que des poids eux-mêmes.

Développé par le MIT Han Lab (Ji Lin, Song Han et collaborateurs), publié en juin 2023 et récompensé par le Best Paper Award à MLSys 2024, AWQ est la méthode de quantification 4 bits qui offre le meilleur compromis qualité/robustesse pour les modèles instruction-tuned et multimodaux. Contrairement à GPTQ qui reconstruit les sorties du modèle, AWQ ne dépend ni de la rétropropagation ni de la reconstruction, ce qui le rend moins sujet à l’overfitting sur les données de calibration et mieux généralisable à des domaines variés.

Type: Quantification post-entraînement (PTQ), poids uniquement (W4A16)
Précision cible: Principalement 4 bits (INT3/INT4)
Approche: Scaling par canal des poids saillants, guidé par les statistiques d’activation
Calibration: Oui (128-256 exemples suffisent)
Quantifie les activations: Non (restent en FP16)
Publication: MLSys 2024 (Best Paper Award), arXiv : juin 2023
Auteurs: Ji Lin, Jiaming Tang, Haotian Tang, Shang Yang, Xingyu Dang, Song Han (MIT)
Implémentations: LLM Compressor (vLLM, recommandé), GPTQModel, AutoAWQ Déprécié
Modèles disponibles: 7 000+ sur Hugging Face Hub

L’innovation fondamentale d’AWQ

L’observation de départ d’AWQ est simple mais puissante : tous les poids d’un LLM ne contribuent pas de manière égale à la qualité des sorties. Une infime fraction (environ 1 %) des canaux de poids sont « saillants », c’est-à-dire que leur quantification dégrade de façon disproportionnée les performances du modèle.

La question devient alors : comment identifier ces poids critiques ? L’intuition naturelle serait de regarder la magnitude des poids (les plus gros poids sont les plus importants). Mais AWQ montre que c’est une mauvaise approche. La bonne stratégie est de regarder les activations : les canaux de poids associés à de grandes valeurs d’activation ont un impact plus fort sur la sortie. C’est le sens du « Activation-aware » dans le nom.

Pourquoi ne pas simplement garder les poids saillants en FP16 ?

La solution évidente serait de quantifier les 99 % de poids normaux en INT4 et de garder le 1 % critique en FP16 (précision mixte). Mais cette approche est un cauchemar pour le matériel : les GPU sont optimisés pour exécuter des multiplications matricielles homogènes. Mélanger INT4 et FP16 dans le même tenseur tue les performances. C’est exactement ce que fait LLM.int8() de bitsandbytes pour INT8, et c’est pourquoi cette méthode n’accélère pas l’inférence (elle peut même la ralentir).

La solution : la transformation équivalente

AWQ résout ce problème avec une approche mathématiquement élégante. Au lieu de quantifier les poids saillants à une précision différente, AWQ applique un facteur de mise à l’échelle (scaling factor) par canal qui multiplie les poids saillants avant la quantification. Ce scaling réduit l’erreur relative de quantification sur ces canaux critiques, car un poids de valeur plus grande est proportionnellement moins affecté par l’arrondi à 4 bits.

Pour que cette transformation n’altère pas le comportement du modèle, AWQ applique l’opération inverse sur les activations d’entrée correspondantes. Mathématiquement, si on multiplie un canal de poids par un facteur s et qu’on divise le canal d’activation correspondant par s, la sortie de la couche linéaire reste identique : W·X = (s·W)·(X/s). C’est une transformation équivalente.

Le facteur de scaling optimal pour chaque canal est déterminé en collectant les statistiques d’activation hors ligne (pendant la passe de calibration). AWQ recherche le scaling qui minimise l’erreur de quantification pondérée par la magnitude des activations.

Pourquoi AWQ généralise mieux que GPTQ GPTQ minimise l’erreur de reconstruction des sorties sur les données de calibration (il ajuste les poids pour que les sorties quantifiées matchent les sorties originales). Cela peut introduire un overfitting : le modèle est optimisé pour les exemples de calibration, pas pour les données réelles. AWQ, en revanche, ne reconstruit pas les sorties. Il identifie les canaux saillants via les activations et ajuste les facteurs de scaling, sans modifier directement les poids pour matcher une sortie cible. Cette approche préserve mieux la capacité de généralisation du modèle, ce qui explique ses meilleures performances sur les modèles instruction-tuned et multimodaux.

Fonctionnement détaillé de l’algorithme

L’algorithme AWQ opère couche par couche, comme la plupart des méthodes PTQ pour LLM. Pour chaque couche linéaire :

1. Collecte des statistiques d’activation. AWQ fait passer le dataset de calibration à travers le modèle et enregistre les distributions d’activation à l’entrée de chaque couche. Il calcule la magnitude moyenne par canal (la moyenne des valeurs absolues des activations pour chaque canal d’entrée).

2. Identification des canaux saillants. Les canaux dont la magnitude d’activation est la plus élevée sont identifiés comme saillants. Ce sont les canaux où la quantification des poids correspondants aurait le plus d’impact sur la sortie.

3. Recherche du scaling optimal. Pour chaque groupe de poids, AWQ recherche un vecteur de scaling s qui minimise l’erreur de quantification pondérée par les activations. Cette recherche est efficace car elle opère canal par canal et ne nécessite pas de rétropropagation.

4. Application de la transformation. Les poids sont multipliés par s, les activations seront divisées par s à l’inférence. En pratique, la division par s est fusionnée dans le bias ou le LayerNorm de la couche précédente, ce qui n’ajoute aucun overhead d’inférence. Les kernels de quantification AWQ sont donc aussi rapides que la quantification par groupe standard.

5. Quantification uniforme. Après le scaling, tous les poids (y compris les saillants, maintenant protégés) sont quantifiés uniformément en INT4 avec le même schéma par groupe (typiquement group_size=128). Aucune précision mixte, aucun branchement conditionnel, ce qui est optimal pour le matériel.

Paramètres de configuration AWQ

Paramètre	Valeur typique	Rôle
`w_bit`	4	Nombre de bits par poids. AWQ est conçu pour 4 bits (3 bits possible mais moins testé)
`q_group_size`	128	Taille du groupe de poids partageant un scale factor. 128 est le standard
`zero_point` / `sym`	`zero_point=True` (asymétrique)	Quantification asymétrique par défaut. L’asymétrique est légèrement plus précis
`version`	« GEMM »	Version du kernel (GEMM = standard). « gemv » pour batch size 1 sur certains modèles
Calibration samples	128-256	Nombre d’exemples de calibration. AWQ est très sample-efficient

AWQ en pratique

AutoAWQ : officiellement déprécié

AutoAWQ, la bibliothèque Python créée par Casper Hansen qui a popularisé AWQ avec plus de 2 millions de téléchargements et 7 000+ modèles sur Hugging Face, est officiellement dépréciée. Le développeur solo qui maintenait le projet a annoncé l’arrêt de la maintenance. La fonctionnalité AWQ a été reprise par le projet vLLM dans sa bibliothèque LLM Compressor.

Migration depuis AutoAWQ Si vous utilisez encore AutoAWQ, la dernière configuration testée utilise Torch 2.6.0 et Transformers 4.51.3. Les versions futures de Transformers risquent de casser la compatibilité. Pour les nouveaux projets, utilisez LLM Compressor (vLLM) ou GPTQModel (qui supporte aussi le format AWQ). Les modèles AWQ existants restent compatibles avec vLLM et Hugging Face Transformers.

Quantifier avec LLM Compressor (recommandé)

LLM Compressor, la bibliothèque d’optimisation de modèles de vLLM, reprend l’implémentation AWQ d’AutoAWQ avec l’aide de son mainteneur original. Le workflow est le suivant :

from llmcompressor import oneshot
from llmcompressor.modifiers.awq import AWQModifier
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "meta-llama/Llama-3.1-8B-Instruct"
model = AutoModelForCausalLM.from_pretrained(model_id, dtype="auto")
tokenizer = AutoTokenizer.from_pretrained(model_id)

recipe = [
    AWQModifier(
        ignore=["lm_head"],
        scheme="W4A16_ASYM",
        targets=["Linear"],
    ),
]

oneshot(
    model=model,
    dataset=ds,
    recipe=recipe,
    max_seq_length=2048,
    num_calibration_samples=256,
)

model.save_pretrained("Llama-3.1-8B-Instruct-AWQ")
tokenizer.save_pretrained("Llama-3.1-8B-Instruct-AWQ")

Quantifier avec AutoAWQ (legacy)

Si vous utilisez encore AutoAWQ (par exemple pour reproduire un workflow existant) :

from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = "meta-llama/Llama-3.1-8B-Instruct"
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)

quant_config = {
    "zero_point": True,
    "q_group_size": 128,
    "w_bit": 4,
    "version": "GEMM",
}

model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized("Llama-3.1-8B-Instruct-AWQ")
tokenizer.save_pretrained("Llama-3.1-8B-Instruct-AWQ")

AWQ est remarquablement sample-efficient : 128 à 256 exemples de calibration suffisent pour quantifier un modèle. C’est significativement moins que GPTQ qui recommande 512 exemples pour une qualité optimale.

Charger un modèle AWQ existant

Avec Hugging Face Transformers :

from transformers import AutoModelForCausalLM, AwqConfig

model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-32B-Instruct-AWQ",
    device_map="auto",
    quantization_config=AwqConfig(
        bits=4,
        fuse_max_seq_len=512,
        do_fuse=True,  # Active les modules fusionnés pour plus de vitesse
    ),
)

Avec vLLM (production) :

# AWQ avec kernel Marlin (vitesse maximale)
vllm serve Qwen/Qwen2.5-32B-Instruct-AWQ 
    --quantization marlin 
    --gpu-memory-utilization 0.9

# AWQ standard
vllm serve Qwen/Qwen2.5-32B-Instruct-AWQ 
    --quantization awq 
    --gpu-memory-utilization 0.9

Benchmarks et qualité

Perplexité

Sur un Qwen2.5-32B quantifié en 4 bits et évalué sur un H200, AWQ atteint une perplexité de 6,84, proche du baseline BF16 à 6,36. C’est légèrement mieux que GPTQ (6,90) et quasi identique au format GGUF Q4_K_M (6,74). Pour la très grande majorité des applications, ces différences sont imperceptibles.

Performance par type de tâche

Génération de code (HumanEval) : AWQ conserve environ 51,8 % de Pass@1, identique à Q4_K_M et bitsandbytes, contre 56,1 % pour le baseline. C’est solide mais légèrement en retrait par rapport à GPTQ-INT4 sur cette tâche spécifique dans certains benchmarks.

Suivi d’instructions (IFEval) : c’est le point faible de la quantification 4 bits en général. Des benchmarks récents montrent qu’AWQ peut sous-performer par rapport à GPTQ-INT4 sur IFEval, avec des pertes pouvant dépasser 10 %. Le suivi d’instructions déterministe est le plus sensible à la basse précision.

Modèles instruction-tuned et multimodaux : c’est là qu’AWQ brille. Sa capacité à ne pas overfitter les données de calibration le rend particulièrement performant sur les modèles alignés (RLHF/DPO) et les modèles multimodaux (vision-language). AWQ est la première méthode à avoir démontré des résultats de quantification satisfaisants sur des LLM multimodaux comme LLaVA et VILA.

Vitesse d’inférence

La vitesse AWQ dépend énormément du kernel utilisé. Sans kernel optimisé, AWQ peut être plus lent que FP16 (les benchmarks JarvisLabs montrent 68 tok/s pour AWQ standard vs ~180 tok/s pour le baseline BF16 sur Qwen2.5-32B). Avec le kernel Marlin, la vitesse bondit à 741 tok/s, soit 4× plus rapide que le baseline et 10,9× plus rapide que AWQ standard. Le kernel fait toute la différence.

Toujours activer Marlin Si vous servez un modèle AWQ en production avec vLLM, utilisez systématiquement --quantization marlin. La différence entre AWQ standard et AWQ+Marlin est spectaculaire (10× sur certains benchmarks). Marlin requiert un GPU Ampere (RTX 30xx / A100) ou plus récent.

AWQ vs GPTQ : le verdict

Les deux méthodes sont matures, bien supportées, et produisent des résultats proches. Voici les cas où l’une l’emporte sur l’autre :

Choisissez AWQ quand : vous quantifiez un modèle instruction-tuned ou multimodal (VILA, LLaVA, etc.), la robustesse multi-domaine est importante (pas d’overfitting sur la calibration), vous voulez une calibration plus rapide (pas de rétropropagation), ou vous ciblez le déploiement edge/on-device (AWQ + TinyChat est optimisé pour ce scénario).

Choisissez GPTQ quand : vous avez besoin de flexibilité en précision (2, 3, 4 ou 8 bits), le suivi strict d’instructions est critique (GPTQ peut être meilleur sur IFEval), un modèle GPTQ pré-quantifié existe mais pas en AWQ, ou vous avez besoin de la quantification asymétrique avancée via GPTQModel.

Avec les kernels Marlin, les deux atteignent des throughputs quasi identiques dans vLLM (712 vs 741 tok/s, soit moins de 5 % d’écart).

AWQ vs GGUF (Q4_K_M)

AWQ et GGUF Q4_K_M ciblent des scénarios fondamentalement différents :

Critère	AWQ	Q4_K_M (GGUF)
Matériel cible	GPU NVIDIA (Ampere+)	CPU, GPU, hybride CPU+GPU
Framework d’inférence	vLLM, TGI, HF Transformers	llama.cpp, Ollama, LM Studio, Jan
Perplexité (Qwen2.5-32B)	6,84	6,74 (légèrement meilleur)
Stratégie de quantification	Uniforme 4 bits + scaling saillant	Précision mixte par couche (attention à 6 bits)
Taille effective	~4,1 bits/poids	~4,8 bits/poids (plus gros mais meilleur ratio qualité/bit)
Throughput GPU (avec Marlin)	741 tok/s	Non applicable (pas de Marlin)
Cas d’usage	Serving production, edge GPU	Inférence locale, CPU, MacBook

Si vous servez sur GPU en production : AWQ + Marlin. Si vous faites de l’inférence locale : GGUF Q4_K_M via Ollama. Les formats ne sont pas interconvertibles sans perte : ne tentez pas de convertir un AWQ en GGUF, partez des poids FP16.

TinyChat : AWQ sur les appareils edge

Parallèlement à l’algorithme AWQ, le MIT Han Lab a développé TinyChat, un framework d’inférence optimisé pour exécuter des LLM quantifiés en 4 bits sur du matériel edge. TinyChat utilise des techniques comme la déquantification à la volée, le packing SIMD-aware des poids, et la fusion de kernels pour traduire les économies mémoire d’AWQ en gains de vitesse réels.

TinyChat 2.0 atteint plus de 3× d’accélération par rapport à l’inférence FP16 de Hugging Face, aussi bien sur des GPU desktop (RTX 4090) que sur des GPU edge (NVIDIA Jetson Orin). Il démocratise le déploiement de modèles jusqu’à 70B de paramètres sur des appareils mobiles (Jetson Orin 64 Go). TinyChat supporte les modèles vision-language (VILA, NVILA, LLaVA) en plus des LLM textuels.

Limites et considérations avancées

Poids uniquement, pas les activations. Comme GPTQ, AWQ est une méthode « weight-only » (W4A16). Les activations restent en FP16 pendant l’inférence. Pour une quantification complète poids + activations (W8A8), tournez-vous vers SmoothQuant. Les deux approches sont complémentaires et peuvent être combinées via LLM Compressor.

Principalement 4 bits. Contrairement à GPTQ qui supporte 2, 3, 4 et 8 bits, AWQ est conçu et optimisé pour 4 bits. Le support 3 bits existe mais est moins testé et moins stable. Si vous avez besoin de flexibilité en précision, GPTQ offre un meilleur choix.

GPU obligatoire pour l’inférence standard. Les kernels AWQ natifs nécessitent un GPU NVIDIA (Turing ou plus récent pour les kernels GEMM, Ampere ou plus récent pour Marlin). Il n’y a pas de chemin d’inférence CPU performant en AWQ. Pour les scénarios CPU, convertissez le modèle original en GGUF plutôt que de tenter de convertir un AWQ.

Modules fusionnés : rigidité sur la longueur de séquence. Quand les modules fusionnés sont activés (via fuse_layers=True dans AutoAWQ ou do_fuse=True dans Transformers), le cache est pré-alloué en fonction de la longueur de séquence maximale définie. Vous ne pouvez pas modifier cette longueur après la création du modèle. Planifiez votre max_seq_len en conséquence.

Dépendance au scaling du LayerNorm. La transformation équivalente d’AWQ fusionne le facteur de scaling inverse dans le LayerNorm ou le bias de la couche précédente. Si l’architecture du modèle utilise un LayerNorm non standard ou ne dispose pas de bias, le mapping AWQ doit être adapté. C’est pourquoi chaque nouvelle architecture de modèle nécessite un « AWQ mapping » spécifique dans LLM Compressor ou GPTQModel.

Le kernel reste le facteur limitant. Un modèle AWQ sans kernel optimisé (Marlin) peut être significativement plus lent que la version FP16. C’est un piège courant : les gains mémoire d’AWQ ne se traduisent en gains de vitesse que si le kernel d’inférence est adapté. Vérifiez toujours que votre stack utilise le bon kernel avant de tirer des conclusions sur les performances.

L’écosystème AWQ

LLM Compressor (vLLM) : le successeur officiel d’AutoAWQ pour la quantification. Intègre AWQModifier avec le support de la quantification asymétrique (W4A16_ASYM). C’est le chemin recommandé pour les nouveaux projets.

GPTQModel : supporte le format AWQ en plus de GPTQ. La version 5.7.0 (février 2026) unifie la propriété zero_point avec sym et corrige la compatibilité AWQ avec les modèles Qwen3.

Hugging Face Transformers : la classe AwqConfig permet de charger des modèles AWQ avec support des modules fusionnés, des kernels ExLlamaV2, et d’Intel IPEX (pour CPU/GPU Intel).

vLLM : support natif des modèles AWQ avec backend Marlin pour le throughput maximal. Plus de 6 500 modèles AWQ sont disponibles sur le Hub.

TinyChat : framework d’inférence edge du MIT, optimisé pour AWQ sur GPU NVIDIA desktop et embarqué.

Questions fréquentes sur AWQ

AWQ est-il meilleur que GPTQ ?

Sur la perplexité globale et la robustesse multi-domaine, AWQ a un léger avantage. Sur les modèles instruction-tuned et multimodaux, l’avantage est plus net grâce à l’absence d’overfitting sur les données de calibration. Cependant, GPTQ peut surpasser AWQ sur certaines tâches spécifiques comme le suivi strict d’instructions (IFEval). Avec les kernels Marlin, les deux offrent des performances d’inférence quasi identiques. En résumé : AWQ est le meilleur choix par défaut pour la qualité, GPTQ offre plus de flexibilité.

AutoAWQ est-il toujours maintenu ?

Non. AutoAWQ est officiellement déprécié. Son mainteneur, Casper Hansen, a annoncé l’arrêt du développement. La dernière version stable fonctionne avec Torch 2.6.0 et Transformers 4.51.3. Pour les nouveaux projets, utilisez LLM Compressor (intégré à vLLM) ou GPTQModel, qui reprennent la fonctionnalité AWQ. Les modèles AWQ existants restent compatibles avec vLLM et Hugging Face Transformers.

Combien de données de calibration faut-il pour AWQ ?

AWQ est très sample-efficient. 128 à 256 exemples suffisent pour la grande majorité des modèles. C’est significativement moins que GPTQ (512 recommandés). Utilisez des données représentatives de votre cas d’usage. Pour un chatbot, des conversations. Pour du code, des fichiers source. Appliquez le template de chat du modèle lors de la préparation des données.

AWQ fonctionne-t-il sur CPU ?

Pas directement dans son implémentation standard. AWQ est conçu pour l’inférence GPU. Pour l’inférence CPU, préférez le format GGUF (Q4_K_M) via llama.cpp ou Ollama. Hugging Face Transformers propose un backend IPEX expérimental pour AWQ sur CPU/GPU Intel, mais les performances sont inférieures aux solutions GGUF natives.

Pourquoi AWQ est-il si efficace sur les modèles multimodaux ?

Les modèles multimodaux (vision-language comme LLaVA, VILA, NVILA) combinent un encodeur visuel et un décodeur LLM. Les méthodes basées sur la reconstruction des sorties (comme GPTQ) risquent d’overfitter les données de calibration textuelles, ce qui dégrade les performances sur l’entrée visuelle. AWQ, qui ne reconstruit pas les sorties, préserve mieux la généralisation inter-modalité. De plus, AWQ fonctionne avec des données de calibration purement textuelles, même pour quantifier un modèle multimodal, ce qui simplifie considérablement le workflow.