AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration
This research paper explains why LLM weights are not equally important under quantization, shows that salience comes from activation magnitudes (not weight norms), and derives a hardware-friendly per-channel scaling transform that protects those channels while keeping a uniform low-bit format.
On-device LLM serving is memory-bound: generation spends most of its time dragging weights from DRAM, not multiplying them. Weight-only INT4 cuts that traffic by about in theory — if you can quantize without wrecking perplexity.
Naive round-to-nearest (RTN) often cannot. A few weight channels matter disproportionately; quantizing them carelessly blows up WikiText perplexity. AWQ’s punchline is precise: find those channels from the activation distribution, then protect them by scaling — not by keeping a mixed-precision format.
What this paper explains
Activation-aware Weight Quantization (AWQ) is a post-training, weight-only method for LLMs (typically W4A16 / W3A16 with group size 128). It does three things:
- Show that protecting a tiny fraction of weights (on the order of –) nearly restores FP16-quality perplexity — but only if those channels are chosen from activations, not weight magnitudes.
- Replace awkward mixed FP16+INT storage with an equivalent scaled transform so every weight stays in the same low-bit grid.
- Search per-channel scales on a small calibration cache to minimize layer output error after quantization, without backprop through .
Alongside the algorithm, the authors ship TinyChat, an on-device runtime that turns the smaller weight footprint into measured generation speedups via fused dequant GEMM and packed INT4 layouts.
Prior limits
- RTN is brittle at 3–4 bits. Group-wise round-to-nearest on LLM weights can spike perplexity even when average weight error looks modest.
- Magnitude pruning intuition fails. Keeping large- channels in FP16 barely helps; randomly kept channels also fail. The “important” weights are not the heaviest ones.
- Mixed precision is accurate but awkward. Literally storing of channels in FP16 restores quality (Table 1), yet breaks uniform kernels, packing, and memory layouts on edge GPUs.
- Reconstruction / GPTQ-style methods can overfit the calibration set and need heavier solvers; AWQ aims for a calibration-light, backprop-free alternative that still generalizes to instruction-tuned and multimodal models.
The mechanism
Weight-only quantization (paper Eq. 1). For a group of weights and bit-width :
is shared across the group — that shared scale is why a few bad channels can dominate rounding error for everyone else.
Salience from activations. A weight channel that multiplies a consistently large activation feature has outsized impact on . Collect calibration activations; rank input channels by magnitude statistics; the top are “salient.”
Why scaling protects. Instead of leaving salient in FP16, multiply that channel by and divide the corresponding activation by :
Empirically, error stays on average, and a single scaled channel rarely moves the group max, so . The relative error on the protected channel therefore shrinks roughly with , while the forward math stays equivalent in the unquantized limit.
Search, don’t guess . Scaling forever hurts non-salient channels (their share of grows). AWQ searches per-input-channel scales:
with cached from a small pretraining calibration set. The inverse scales fuse into the previous operator (LayerNorm / residual path), so inference sees ordinary low-bit weights plus a cheap fused rescale.
Hardware angle. Generation is memory-bound: weight bytes dwarfs activation bytes (paper Fig. 3). W4A16 raises arithmetic intensity about versus FP16 weights. AWQ keeps a uniform INT grid so TinyChat can pack, fuse, and dequant on the fly — unlike a true mixed FP16/INT layout.
Algorithm walkthrough
- Pick target bit-width and group size (paper default: group size ; experiments often use INT3/INT4).
- Run a small calibration batch through the FP16 model; cache per-layer input activations .
- For each linear layer weight :
- Rank input channels by activation magnitude → mark the salient set (order ). - Search scales (salience-biased grid) minimizing quantized output error vs . - Form and fuse into the preceding op. - Quantize with group-wise to INT3/INT4; store scales/zeros for dequant.
- At inference: load packed low-bit weights; TinyChat dequantizes on chip into the GEMM path.
The opening visual is the same story in space: an activation bar chart lights a few channels; those weight columns inflate; a uniform INT grid snaps everything down; a compact edge GPU emits tokens without a mixed-precision exception path.
What to notice when reading
- AWQ is activation-aware weight quantization — activations stay higher precision (W4A16), unlike SmoothQuant’s W8A8 migration story.
- The FP16 ablation is the motivation, not the deployed format. Deployed AWQ is scaled + fully quantized.
- No STE / QAT loop: scales come from a grid search on calibration activations.
- Calibration is intentionally small and from pretraining data so instruction / VLM heads do not overfit a downstream task.
- Group size is the practical knob pairing accuracy with kernel friendliness.
Results and evidence
Numbers below are as reported by Lin et al. — not universal constants.
Table 1 (WikiText PPL , INT3-g128). Keeping a few channels in FP16 only helps when chosen by activations. For OPT-6.7B: FP16 , RTN , act-based FP16 , weight-magnitude FP16 , random . Same pattern on OPT-1.3B / 13B: activation-based protection collapses the RTN blow-up; weight- or random-based does not.
Table 2 (scaling intuition on OPT-6.7B). Multiplying the salient channels by improves RTN’s PPL to at (best among ). Larger protects salient channels more but eventually hurts the rest via drift.
Mixed-precision vs scaled AWQ (Table 3). Scaling-based protection matches the accuracy idea of “ FP16” while remaining hardware-friendly under INT3-g128.
Systems. TinyChat reports more than generation speedup vs HuggingFace FP16 across several LLM families on desktop/mobile GPUs, and enables large models on constrained devices (e.g. Llama-2-70B on Jetson Orin 64GB; interactive 13B on an 8GB laptop GPU — paper claims). AWQ also reports strong retention on instruction-tuned and multimodal models relative to prior PTQ baselines in their eval suite.
Limitations
- Still a calibration method: bad or tiny caches can mis-rank channels (though the paper emphasizes robustness vs reconstruction overfitting).
- Weight-only focus: does not by itself solve activation quantization / W8A8 deployment (pair with SmoothQuant-style ideas if you need that).
- Search adds a one-time offline cost per layer; not free compared to pure RTN.
- Extreme bit-widths and pathological groups can still force quality/speed tradeoffs; group size and bit-width remain knobs.
- Mixed-precision oracle ( FP16) can look slightly better in ablations but is intentionally abandoned for systems reasons.
How to read the paper
- Fig. 2 — RTN damage → FP16 by activation → AWQ scaled protection. Read this before the equations.
- §3.1 / Table 1 — prove to yourself that activation ranking beats weight ranking.
- §3.2 / Eqs. 1–2 / Table 2 — why shrinks relative error without mixed dtypes.
- §3.3 search objective (Eq. 4) — how scales are chosen without differentiating through .
- Fig. 3 + TinyChat — why weight-only INT4 maps to real tokens/sec on edge GPUs.
- Skim related work against GPTQ / SmoothQuant to place AWQ on the PTQ map.
Knowledge check
Why does AWQ rank channels using activations instead of weight magnitudes?
Deployed AWQ protects salient weights primarily by…
On-device generation benefits from W4A16 mainly because…
Keep reading
- SmoothQuant (Xiao et al.) — migrate quantization difficulty from activations into weights for W8A8.
- GPTQ (Frantar et al.) — second-order, reconstruction-based post-training weight quantization.
- DistServe / Orca Daily issues — complementary serving angles once weights already fit.
Sources
- Lin et al., “AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration,” MLSys 2024. https://arxiv.org/abs/2306.00978
- Project / community implementations referenced in the paper ecosystem (Hugging Face, TensorRT-LLM, vLLM, etc.) — verify current docs for production kernels.