98. Quantization 4 - Professional Serving Decisions
Choose a quantization level for a real workload, and defend the choice with measurements rather than a leaderboard.
By Jacques Botte, founder of Toptronic®. Last updated 17 October 2026.
The lesson
In production the question is never 'which quantization is best' but 'which quantization for this task at this budget'. Start by fixing the constraint: is it memory (must fit one card), latency (must answer in two seconds), throughput (must serve a thousand requests an hour), or cost per request? Each points at a different setting, and optimizing the wrong one is how teams ship a model that is cheap and unusable.
Then build a small evaluation set from your own traffic: fifty to two hundred real prompts with known good answers, scored by a rule where possible and by a human where not. Run the 16-bit model through it to establish the ceiling, then each candidate quantization. Report the delta, not the absolute score. A 4-bit model that loses one point on a translation task is a bargain; the same loss on a strict JSON-extraction task may be unacceptable because failures are silent.
Watch the failure shape, not only the rate. Quantization damage rarely looks like a random wrong answer; it looks like longer rambling, weaker instruction-following at the edges, and more frequent format violations. For structured output that means more parse errors downstream, which cost more than the memory you saved. For free text it may be invisible. Measure the thing you actually consume.
Serving hardware decides more than the bit width. A quantized model whose kernels are not optimized for your GPU can be slower than a 16-bit model with good kernels, because dequantization work and memory access patterns dominate. Memory bandwidth, not arithmetic, is the usual limit during token generation, and that is precisely why smaller weights help: fewer bytes move per token. If your stack spends its time dequantizing badly, a supported 8-bit format beats an exotic 4-bit one.
Finally, record the decision. Write down the model, the exact file or quant recipe, the hardware, the evaluation set, the measured delta and the date. Models and stacks change monthly, and a configuration chosen six months ago on a now-unsupported kernel is a silent regression waiting to be rediscovered. This is the same discipline the rest of this course applies to prompts: a number you cannot reproduce is not evidence.
Check yourself
Question 1: What should you measure before choosing a quantization level?
- Only the model's published benchmark score
- Your own small evaluation set from real traffic, compared against the 16-bit ceiling — correct
- The file size on disk
- The vendor's marketing page
Answer: Your own small evaluation set from real traffic, compared against the 16-bit ceiling
A task-specific evaluation set is the only evidence that speaks to your workload; published tables were measured on someone else's.
Question 2: Which failure shape should worry you most when quantizing a JSON-extraction task?
- Slightly longer answers
- More format violations that break parsing downstream — correct
- A different writing style
- Faster responses
Answer: More format violations that break parsing downstream
Structured-output failures are silent at the model level and expensive at the integration level.
Question 3: Why can an exotic 4-bit format be slower than a well-supported 8-bit one?
- Because 4-bit always uses more memory
- Because dequantization cost and memory access patterns can dominate when kernels are not optimized — correct
- Because GPUs cannot do 4-bit arithmetic
- Because 8-bit models are smaller
Answer: Because dequantization cost and memory access patterns can dominate when kernels are not optimized
Token generation is usually bandwidth-bound. If the kernel dequantizes badly, the byte saving is spent again in compute.
← Previous lesson · All 106 lessons · Next lesson →
The full course — 106 lessons and 318 quiz questions — ships inside the app. Get TPEE to study it offline.