How Quantisation works in practice
A language model's parameters are stored as millions or billions of floating-point numbers. In standard 16-bit precision (`BF16` or `FP16`), every billion parameters requires 2 gigabytes of GPU VRAM just to hold the weights, before accounting for the KV cache needed for active context windows: a 70-billion-parameter model needs roughly 140 GB of VRAM, requiring multiple expensive data-centre GPUs. Worse, LLM token generation is typically memory-bandwidth bound rather than compute bound; the GPU cores spend most of their time waiting for weights to move from VRAM into registers.
Quantisation maps those high-precision continuous numbers onto a smaller grid of discrete values using scaling factors and zero-points. Most production teams use Post-Training Quantisation (PTQ) methods such as AWQ (Activation-aware Weight Quantisation), GPTQ, or GGUF, which calibrate a small sample of data to protect the less than 1 per cent of 'outlier' weights that disproportionately affect model accuracy, or native `FP8` execution on modern Hopper and Blackwell GPUs.
For example, a Sheffield software house quantised a 70-billion-parameter open-weight model from BF16 to 4-bit AWQ, shrinking its VRAM footprint from 140 GB to ~38 GB so it runs at 45 tokens per second on a single cloud GPU instance instead of an expensive multi-GPU node.
Why it matters and trade-offs
Quantisation directly changes the deployment economics of self-hosted and edge AI. Dropping from 16-bit to 8-bit (`FP8` or `INT8`) is nearly lossless on modern benchmarks while nearly doubling throughput and halving hardware costs; 4-bit quantisation enables local coding models on developer laptops and high-density multi-LoRA serving in private clouds.
The trade-off appears when pushing down to aggressive 4-bit or 3-bit schemes on complex reasoning, arithmetic, or long-context retrieval tasks, where subtle perplexity degradation can cause higher hallucination rates or broken JSON formatting. Teams should never trust generic perplexity scores alone; always run your domain-specific eval suite against the quantised checkpoint before promoting it to production.
