Quantization and VRAM: BF16, FP8, INT8 and INT4

Quantization stores a model's weights in fewer bits. Weights are usually the largest part of GPU memory, so it is the first lever people reach for — but it shrinks only the weights, and every step down trades some accuracy.

Bytes per parameter

Weights take parameters × bytes per parameter. BF16 and FP16 are the reference — most models are released in one of them — and every other precision is a multiple of it.

Weights only, before the KV cache and overhead. At FP8, INT8 and INT4 the embedding and the output layer stay at 16 bits.

The formats you will meet

• BF16 and FP16 — 16-bit floating point. BF16 keeps FP32's range with less precision, which is why training and most released checkpoints use it.
• FP8 — 8-bit floating point, one byte per weight, supported in hardware by recent NVIDIA GPUs (Ada Lovelace, Hopper and later). Some models ship FP8 checkpoints.
• INT8 — 8-bit integers with scaling factors, one byte per weight.
• AWQ and GPTQ — 4-bit, weight-only methods: weights are stored in 4 bits and computed at 16. They ship as safetensors and aim at GPU serving engines such as vLLM.
• GGUF — llama.cpp's file format, with quantization levels named by bits (Q4, Q5, Q8…), used on CPUs, Apple Silicon and consumer GPUs.
• NVFP4 and MXFP4 — 4-bit floating-point formats with shared scales. gpt-oss ships its expert weights in MXFP4, which is how gpt-oss 120B fits on a single 80 GB GPU: 64.48 GiB at 8k context for one user, against 72.82 GiB usable on an H100 SXM 80GB.
• NF4 — QLoRA's 4-bit NormalFloat, for fine-tuning adapters on a frozen, quantized base model.

Why 4-bit is not exactly half a byte

Real 4-bit formats also store their scaling factors — a 16-bit scale for every group of 128 weights in AWQ and GPTQ, an 8-bit scale for every block of 32 in MXFP4 — which comes to about 4.25 bits a weight, and they keep the embedding and the output layer at 16 bits. LLMScale counts both, so its 4-bit figure comes out well above half of BF16: Qwen2.5-7B lands within 2% of Qwen's own AWQ checkpoint, and Qwen3-8B at FP8 matches RedHat's FP8 checkpoint to the hundredth of a GiB. A checkpoint that already ships quantized is sized by its own files. QLoRA's NF4 with double quantization measures 4.127 bits, or 0.516 bytes, per parameter, and that is the figure the fine-tuning calculator uses.

It does not shrink the KV cache

The KV cache has a precision of its own, set by the serving engine rather than by the weights' format. Take Llama 3.3 70B Instruct with one user at 128k context: its weights take 131.4 GiB at BF16 and 37.78 GiB at INT4, while the KV cache stays at 40.00 GiB in FP16 — more than the INT4 weights. Storing the cache in FP8 is a separate choice that halves it; see KV cache size.

Mixture-of-Experts models

Every expert is quantized, and every expert still has to be in memory. Mixtral 8x7B Instruct holds 46.70B parameters: 86.99 GiB of weights at BF16, 23.46 GiB at INT4. Its 12.90B active parameters decide how much work each token does, not how much memory the model takes.

Choosing a precision

• Start from what fits. When a model outgrows a card, the calculator names the first lighter precision that fits it.
• Measure the cost. Each step down trades accuracy for memory, and how much depends on the model and the method; test on your own task before serving.
• Let a pre-quantized checkpoint speak for itself. LLMScale reads its precision from quantization_config, the repository name or the safetensors header, and vLLM loads AWQ, GPTQ and FP8 checkpoints without a --quantization flag.

• Compare precisions for your model
• KV cache size
• GQA, MQA and MLA
• Which LLMs fit on which GPU