**Quantization** stores numbers in fewer bits. A weight that was 16 bits becomes 8 or 4 bits, so the model takes less memory and can move faster. The naming convention WxAy tells you the bits on weights (W) and activations (A).
W8A8 means 8-bit weights AND 8-bit activations. Because both sides are integers, the actual matrix multiply can run on INT8 tensor cores, which are roughly twice as fast as FP16 cores. This helps when raw math throughput is the bottleneck.
W4A16 means 4-bit weights but 16-bit activations. The weights are tiny in memory, but they get unpacked back to FP16 before the multiply. So the math is still FP16; you only saved on the bytes you had to read for the weights.
Why two schemes? LLM serving has two phases with different limits. Prefill, reading the prompt, is compute-bound, so faster INT8 math helps. Decode, writing tokens one by one, is memory-bound, so a smaller weight read helps. W8A8 fits prefill; W4A16 fits decode.
**Quantization** choices follow the bottleneck of the phase. The WxAy notation gives weight bits then activation bits. The matching trick is to ask whether you are compute-bound or bandwidth-bound.
W8A8 quantizes both sides to INT8, so the whole matmul runs on INT8 tensor cores. That doubles math throughput versus FP16. It shines in prefill and large-batch serving, where you are compute-bound. The canonical method is SmoothQuant. It migrates activation outliers into the weights so INT8 activations stay accurate.
W4A16 quantizes only the weights to 4-bit and keeps activations in FP16. The weights are dequantized to FP16 before the multiply, so math runs in FP16. The only win is a 4x smaller weight read from HBM. That is what decode at small batch needs, because decode is memory-bandwidth-bound. The canonical methods are AWQ and GPTQ, both weight-only with group-wise scales.
So decode at batch 1 on a 70B model picks W4A16. Bandwidth dominates there. Prefill or high-batch throughput picks W8A8, because at large batch the workload turns compute-bound and INT8 math wins.
Quick reference
TL;DR
W8A8 quantizes weights and activations to INT8 for compute-bound prefill on INT8 tensor cores; W4A16 shrinks only the weight read to 4-bit for bandwidth-bound decode.
Imagine a kitchen with two very different rushes. The lunch rush sends hundreds of identical orders at once, so the bottleneck is how fast the cooks can chop. You hire faster cooks who work in a coarser, quicker style. That is W8A8: everything runs in a faster, lower-precision mode because raw cooking speed is the limit. The late-night rush sends one order at a time, and the bottleneck is the long walk to the pantry for ingredients. You shrink the ingredients so each trip carries less weight. That is W4A16: you compress only what you fetch from storage, but cook it carefully in full precision. Same kitchen, two regimes, each matched to where the real wait is.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Serving a small model that already fits comfortably in HBM at FP16 The bandwidth and capacity wins are marginal, and quantization adds accuracy risk for little gain.
Picking W4A16 for a high-batch throughput service At large batch the workload becomes compute-bound, so FP16 math caps you; W8A8 or W4A8 wins instead.
Applying naive INT8 activations without any outlier handling Activation outliers blow up the quantization range; you need SmoothQuant or per-channel scales first.
Quality-critical tasks with very tight accuracy budgets Aggressive 4-bit weights can shift outputs measurably; validate per task before shipping low-bit serving.
Quick scan · 2–4 min
Everything important, quickly.
4 min: roofline framing (compute vs bandwidth) + W8A8 INT8 math for prefill + W4A16 weight-only read for decode + SmoothQuant vs AWQ/GPTQ + batch-size crossover.
Side-by-side
Aspect
W8A8
W4A16
Weight bits
8 (INT8)
4 (INT4)
Activation bits
8 (INT8)
16 (FP16)
Matmul precision
INT8 tensor cores
FP16 (weights dequantized first)
Primary win
2x math throughput
4x smaller weight read
Bottleneck it relieves
Compute-bound
Memory-bandwidth-bound
Best-fit phase
Prefill, large-batch serving
Decode at small batch
Canonical method
SmoothQuant
AWQ, GPTQ
Real-world examples
Real products, models, and research that use this idea.
1vLLM and SGLang in 2026 ship AWQ and GPTQ W4A16 kernels as the default for low-batch decode of Llama 4 and Qwen 3.
2TensorRT-LLM (NVIDIA) exposes SmoothQuant W8A8 INT8 GEMMs tuned for compute-bound prefill on H100 and B200.
3NVIDIA B200 hardware adds native FP4 tensor cores, pushing W4A4 and W4A8 mixed regimes into production serving.
4DeepSeek V4 and Mistral Large 3 publish AWQ-quantized W4A16 checkpoints sized for single-GPU 4-bit decode.
5Hugging Face's compressed-tensors and llm-compressor toolkits export both SmoothQuant W8A8 and GPTQ W4A16 from one model.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does W4A16 give zero matmul speedup despite using 4-bit weights?
Sign in or go Pro to see the approach for this follow-up.
QAt what batch size does decode flip from bandwidth-bound to compute-bound?
Sign in or go Pro to see the approach for this follow-up.
QWhy are activations harder to quantize to INT8 than weights?
Sign in or go Pro to see the approach for this follow-up.
QHow does B200 FP4 hardware change the W4A16 versus W8A8 calculus?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating all quantization as one knob. The phase decides: prefill is compute-bound and wants INT8 math, decode is bandwidth-bound and wants the smallest weight read, regardless of compute precision.