FP8, NVFP4, or GGUF Quants: Datacenter Formats vs llama.cpp Formats

updated 2026-09-10 · verified 2026-09-10

When you go to download a model, you meet two parallel universes: official checkpoints labeled FP8 or NVFP4 on Hugging Face, and a wall of GGUF files in the bartowski repos. Both are “low precision,” but they target different hardware, different software stacks, and different workloads. The cost of picking the wrong universe isn’t quality — it’s that nothing runs at all.

Two formats, two ecosystems

GGUF is llama.cpp’s container format. Its quantization schemes (Q4_K_M, Q8_0, and friends) are integer quantization: weights are stored as low-bit integers plus scaling factors, then dequantized back to FP16/BF16 before the matrix math runs. The design goal is portability — one file runs on CPU, CUDA, Metal, or Vulkan, and Ollama, LM Studio, and llama.cpp all load it directly.

FP8 / NVFP4 are NVIDIA’s datacenter-lineage floating-point formats. Their purpose is to let Tensor Cores do the matrix math directly in low precision — no dequantization, the compute itself happens at 8 or 4 bits. They ship as ordinary safetensors checkpoints (NVIDIA publishes FP8/NVFP4 variants of popular models; DeepSeek-V3/R1 ship native FP8 weights) and load through serving frameworks like vLLM, TensorRT-LLM, and SGLang.

The one-line distinction: GGUF saves bytes moved; FP8/NVFP4 save the computation itself.

FP8: 8-bit floats from Hopper onward

FP8 comes in two flavors: E4M3 (4 exponent bits, 3 mantissa bits, used for weights and activations) and E5M2 (wider dynamic range, used for gradients). Each weight is exactly 8 bits, paired with per-tensor or per-block scaling factors.

The hardware gate is explicit: fourth-generation Tensor Cores — Ada (RTX 40 series) and Hopper (H100) and later — run FP8 matrix math natively. Ampere (RTX 30 series, A100) and older have no such instruction: an FP8 checkpoint there gets converted back to FP16 at load time. The file stays small, but there’s zero speed benefit and you lose GGUF’s ecosystem convenience.

DeepSeek-V3 pushed FP8 into the spotlight: its 671B weights were trained and released natively in FP8, making “datacenter models default to FP8” a practical reality — training saves compute, inference saves VRAM, and one checkpoint serves both.

NVFP4: 4-bit floats, Blackwell only

NVFP4 arrived with Blackwell (RTX 50 series, B200/GB200). Each weight uses E2M1 (2 exponent bits, 1 mantissa bit), every 16 weights share one FP8 (E4M3) scaling factor, plus one FP32 factor per tensor. That works out to roughly 4.5 bits per weight.

This “small blocks plus high-precision scales” structure is exactly why it beats legacy 4-bit formats: GGUF’s Q4_K_M uses integers with super-block scales, NVFP4 uses micro-floats with FP8 scales — same idea, different arithmetic. Per NVIDIA’s own figures, NVFP4 cuts memory by about 3.5× versus FP16 and 1.8× versus FP8, and when paired with QAT (quantization-aware training) the accuracy loss stays small — NVIDIA’s NVFP4 pretraining experiments (a 12B hybrid model at 10T tokens) report training loss and downstream accuracy close to the BF16 baseline.

The hardware gate is hard: FP4 matrix math exists only on Blackwell’s fifth-generation Tensor Cores. RTX 40 and older cards cannot accelerate NVFP4 natively.

Size and VRAM: both formats on one table

Both ecosystems plug into the same VRAM formula this site uses: weights = params (billions) × bits per weight ÷ 8, plus KV cache and ~1.5GB runtime overhead. Using FP8 = 8.0 bits, NVFP4 ≈ 4.5 bits, and measured GGUF rates (Q8_0 = 8.51, Q4_K_M = 4.9):

Model	FP8	Q8_0 (GGUF)	NVFP4	Q4_K_M (GGUF)
Llama-3.1-8B (8.03B)	8.0 GB	8.5 GB	4.5 GB	4.9 GB
Qwen3-32B (32.8B)	32.8 GB	34.9 GB	18.5 GB	20.1 GB
Llama-3.3-70B (70.6B)	70.6 GB	75.1 GB	39.7 GB	43.2 GB

Full requirements after adding KV cache (8K context, fp16) and 1.5GB overhead, and where each lands (comfortable = need ≤ 80% of usable VRAM, tight = ≤ 100%):

Setup	Total VRAM	Where it lands
8B FP8	10.6 GB	tight on 12GB, comfortable on 16GB (RTX 4070 Ti S)
8B NVFP4	7.1 GB	comfortable on 12GB (but only Blackwell accelerates it)
32B NVFP4	22.1 GB	tight on 24GB, comfortable on RTX 5090 32GB
32B FP8	36.4 GB	tight on a 48GB card (A6000)
70B NVFP4	43.9 GB	tight on 48GB, comfortable on 2×32GB or 80GB
70B FP8	74.8 GB	tight on H100/A100 80GB

Note the last row: a 70B model at FP8 still demands an 80GB-class GPU. FP8’s point is not “run big models on small cards” — it’s throughput on datacenter hardware. What actually moves the consumer hardware threshold is the 4-bit tier — whether it’s called NVFP4 or Q4_K_M, the size is nearly identical (39.7 vs 43.2 GB); what differs is how fast it runs, and on what.

Quality: the decisive variable is QAT, not the format

People searching “qat vs q8” are really asking: can 4-bit avoid losing to 8-bit? The answer: at the same 4 bits, QAT and PTQ are different worlds.

• PTQ (post-training quantization) takes a trained model and compresses it. All of GGUF and most third-party FP8 checkpoints are PTQ. A 4-bit PTQ model (Q4_K_M class) is fine for everyday chat but measurably worse than 8-bit on math and long reasoning chains.
• QAT (quantization-aware training) injects quantization noise into the forward pass during training or continued training, so the model learns to live with low precision. It costs enormously (only model labs or NVIDIA-scale teams can afford it) but preserves far more fidelity at the same 4 bits. Meta’s small Llama 3.2 models and NVIDIA’s official NVFP4 checkpoints both take this route.

The practical corollary: an official QAT’d NVFP4 checkpoint usually beats a community PTQ Q4_K_M in quality; conversely, without QAT, don’t expect any 4-bit format to catch Q8. The format sets the size and the hardware; the training method sets the quality ceiling.

Speed: GGUF saves bandwidth, FP8/NVFP4 save compute too

Token-by-token generation (decode) is always bandwidth-bound, and both format families are treated equally there. This site’s speed formula theoretical tok/s = bandwidth × 0.75 ÷ weight GB read per token applies to both (theoretical estimates — frameworks, drivers, and CPU overhead move reality by roughly ±30%):

Hardware	Model and format	Bytes per token	Theoretical speed
RTX 4090 (1008 GB/s)	8B FP8	8.0 GB	~95 tok/s
RTX 4090	8B Q4_K_M	4.9 GB	~154 tok/s
RTX 5090 (1792 GB/s)	70B NVFP4	39.7 GB	~34 tok/s
H100 (3350 GB/s)	70B FP8	70.6 GB	~36 tok/s

The real gap shows up in prefill (prompt processing), which is compute-bound. GGUF integer weights must be dequantized first, and the Tensor Cores still execute FP16 instructions — prefill gets no acceleration. FP8/NVFP4 matrix math runs directly on low-precision Tensor Cores, and prefill throughput can improve severalfold. That’s exactly why multi-user serving (where most tokens are prefill) needs FP8/NVFP4 — and why single-user chat can safely ignore them.

How to choose: hardware first, workload second

Your situation	Recommendation
Consumer GPU + llama.cpp/Ollama/LM Studio	GGUF Q4_K_M, done (see our Q4 vs Q8 guide)
RTX 40 series + vLLM serving	FP8 checkpoints (native acceleration), optionally FP8 KV cache
RTX 50 series / B200 + vLLM or TensorRT-LLM	Official NVFP4 + QAT checkpoints first; fall back to GGUF Q4_K_M if none exist
Long context is the priority	Keep the format, enable q8/FP8 KV cache first (see the KV cache guide)
Reproducing paper numbers, fine-tune baselines	Original FP16/BF16 weights — neither quantization family

Common misconceptions

• “FP8 files are smaller, so it’s more advanced.” FP8 is 8 bits — the same size class as Q8_0 and over 70% bigger than Q4. Its advantage is the compute path, not compression.
• “NVFP4 is a new GGUF tier.” It isn’t. NVFP4 lives outside the GGUF ecosystem — it’s a native Blackwell data type loaded by vLLM/TensorRT-LLM. If a download page offers an NVFP4 variant, first confirm you have Blackwell hardware and a serving framework.
• “All 4-bit is the same.” NVFP4’s micro-float scaling structure and QAT training put it in a different quality class from legacy integer Q4. At the same bit width, the training method matters more than the format.
• “With FP8 weights, the KV cache takes care of itself.” Weight quantization and KV cache are independent variables. At 128K context, Llama-3.1-8B’s fp16 KV cache alone is ~17GB — more than double its FP8 weights. You still need to enable FP8/q8 KV explicitly.

The one-line summary

Personal local use: GGUF Q4_K_M — it runs everywhere. Serving on Ada/Hopper: FP8. Blackwell with an official QAT checkpoint: NVFP4. Not sure whether your card fits a given format? Plug the format’s bits-per-weight into our VRAM calculator, or check your card directly with the GPU checker — every VRAM figure in this article comes from the same formulas behind them.

FAQ

Sources

• NVIDIA: Introducing NVFP4 for Efficient and Accurate Low-Precision Inference
• Pretraining Large Language Models with NVFP4 (arXiv 2509.25149)
• FP8 Formats for Deep Learning (arXiv 2209.05433)
• llama.cpp (GGUF quantization and K-quants implementation)
• vLLM quantization documentation