Question presented to candidate: "We want to self-host an open-weight model. Someone suggested running a 4-bit quantized version. Explain what quantization actually does to the model, why it makes inference cheaper and faster, what it costs in quality, and how you would decide whether to ship it."
What a strong answer should cover:
- Quantization stores weights (and optionally activations or the KV cache) in fewer bits: map each value to a small integer grid with a scale factor, w โ q ร scale; 16-bit to 4-bit cuts weight memory about 4x
- Why it speeds things up: single-sequence decoding is memory-bandwidth bound (every weight is read once per generated token), so fewer bytes per weight raises the tokens-per-second ceiling, not just the file size
- Granularity and outliers: one large value stretches the scale for everything that shares it; per-group scales (32 to 128 weights) and outlier-aware methods (LLM.int8(), AWQ, GPTQ) keep 4-bit error manageable at a small bits-per-weight overhead
- The main formats and where they run: GGUF / llama.cpp for CPUs and consumer GPUs, GPTQ and AWQ for GPU serving, bitsandbytes NF4 (QLoRA) for fine-tuning on a quantized base
- When to use it: fitting a bigger model on the hardware you have, on-device and local use, cutting serving cost; when not to: tasks where small accuracy losses matter (maths, code, long reasoning) without an eval on your own data
- The decision rule: compare "bigger model, quantized" against "smaller model, full precision" on your own eval, measuring quality, latency and memory
Clarifying questions expected:
- What hardware are we serving on (GPU memory, CPU only, edge device) and what batch sizes?
- Which tasks matter most, and do we have an eval that would detect a few points of quality loss?
Code / implementation expected: Optional โ a small absmax quantizer showing per-tensor vs per-group error, the outlier effect, and the memory and bandwidth arithmetic.