Precision is a choice you make for a dedicated endpoint
Quantization means storing a model's numbers, its weights, with fewer bits than it was trained with. Start at 8 bits. Go to 4 bits only when memory or cost forces it and your own test still passes. Keep 16 bits where no drift in answers is acceptable.
Should you run your dedicated endpoint at full precision, FP8 or NVFP4? The question comes up when a workload leaves a shared per-token API. There, the provider picked the precision for you. On your own endpoint, you pick it.
Lyceum is a sovereign European AI inference provider for open-source models, as our press page puts it. Sovereign here means our GPUs run in European data centres. On our dedicated endpoints, the GPUs are reserved for your endpoint. The model configuration is agreed before launch, so your model fits your workload. Precision is part of that decision.
A dedicated deployment runs your model on reserved GPU replicas, meaning running copies of the model. You reach it through an OpenAI-compatible endpoint. As our dedicated inference docs describe, you pay for the time the replicas run, not per request. Each deployment also has a hardware profile: the GPU type every replica runs on.
That billing model is why precision matters. If a lower precision fits the model on fewer or smaller GPUs, every hour costs less. If it leaves more memory free on the same GPU, each replica serves more requests at once.
What 16-bit, FP8 and NVFP4 store per weight
Each precision is a different number format for the same weights. The fewer bits per weight, the less GPU memory the model needs.
- 16-bit (FP16 or BF16) is the usual serving format and the baseline here. NVIDIA describes FP16 and BF16 as the 16-bit floating-point formats that FP8 improves on in memory and throughput. Throughput is the number of tokens a server delivers per second.
- FP8 stores each weight in 8 bits. The vLLM project, an open-source serving engine, documents a 2x cut in model memory with minimal impact on accuracy. It also reports up to 1.6x more throughput.
- NVFP4 is a 4-bit floating-point format that NVIDIA introduced with its Blackwell GPUs. It stores one 4-bit value per weight. Every block of 16 weights also shares one 8-bit scale, which adds 8 ÷ 16 = 0.5 bit per weight. That comes to about 4.5 bits per weight.
The shared scales are what keep 4 bits usable. A scale stretches a small block of 4-bit values back to the range the original numbers had. NVIDIA's article of 24 June 2025 puts the saving at about 3.5x against FP16 (16 ÷ 4.5) and about 1.8x against FP8 (8 ÷ 4.5).
| Precision | Bits per weight | Memory vs 16-bit | Source |
|---|---|---|---|
| 16-bit (FP16, BF16) | 16 | baseline | NVIDIA |
| FP8 | 8 | half | vLLM docs |
| NVFP4 | about 4.5 | about 3.5x less | NVIDIA |
How much accuracy each step down costs
Accuracy is the price of fewer bits, and the published measurements say the price is small for FP8. They also say it is not zero for 4 bits.
A study submitted on 4 November 2024 ran over 500,000 evaluations on the Llama-3.1 model family. It found FP8 weights and activations effectively lossless at every model size. Activations are the intermediate numbers a model computes while it answers. Well-tuned 8-bit integers (INT8) lost 1 to 3%.
The same study looked at cost and speed. Compared with 8-bit, storing only the weights in 4 bits gave the lowest cost when requests arrive one at a time. On a busy server that keeps mixing new requests into one running batch, the order flipped: 8-bit weights and activations won. That study used 4-bit integers, not NVFP4, so read it as a hint about traffic, not a result for NVFP4.
For NVFP4, NVIDIA converted DeepSeek-R1-0528 from FP8 by post-training quantization. That means the finished model is converted without training it again. Accuracy fell by 1% or less on key language tasks. That loss is measured against FP8, not against 16-bit.
These are other teams' models and benchmarks. They show how big the effect usually is. They do not show what happens to your prompts, your output format or your edge cases.
Which GPUs run FP8 and NVFP4
The GPU decides which precisions run at full speed. NVIDIA states that FP8 is supported by its Hopper and Blackwell generations. The vLLM engine runs FP8 weights and activations on three NVIDIA GPU generations: Ada Lovelace, Hopper and Blackwell. On the older NVIDIA generations Turing and Ampere, it stores the weights in FP8 but still computes in 16 bits.
NVFP4 is a Blackwell format. The H100 and H200 are Hopper GPUs. The B200 is a Blackwell GPU.
| GPU | Generation | Memory | 16-bit | FP8 | NVFP4 |
|---|---|---|---|---|---|
| H100 | Hopper | 80 GB | yes | yes | no |
| H200 | Hopper | 141 GB | yes | yes | no |
| B200 | Blackwell | 192 GB | yes | yes | yes |
Our compute page lists the H100 with 80 GB, the H200 with 141 GB and the B200 with 192 GB. Which hardware profile your endpoint uses is part of the setup you agree with us. Our comparison of the B200 and H200 for inference goes deeper on the hardware.
Worked example: Qwen3.8 27B on an H100 and a B200
One of our models shows what the choice means in gigabytes. Qwen3.8 27B is a compact, dense model with a 256K-token context window. Dense means every one of its weights is used for every token, so all 27 billion must sit in GPU memory.
The code block below is a calculated example for the weights only. Dividing by 8 turns bits into bytes.
weights (GB) = parameters × bits per weight ÷ 8
16-bit: 27e9 × 16 ÷ 8 = 54.0 GB
FP8: 27e9 × 8 ÷ 8 = 27.0 GB
NVFP4: 27e9 × 4.5 ÷ 8 = 15.2 GBOn an 80 GB H100, the 16-bit weights leave 26.0 GB free (80 − 54.0). FP8 weights leave 53.0 GB (80 − 27.0), which is 2.0x the room. That free memory holds the KV cache (key-value cache), the record the model keeps of every token in each running request. More room means more requests at once, or longer ones.
NVFP4 does not run natively on an H100, because it is a Blackwell format. On a 192 GB B200, NVFP4 weights leave 176.8 GB free (192 − 15.2).
The example favours the smaller formats in one way: it counts weights only, and the weights are the part that quantization shrinks. A real server also needs memory for activations and the serving engine, so the free memory is smaller than shown. The example does not show latency, real throughput or the accuracy of Qwen3.8 27B at each precision. Our sizing tool shows the memory a Hugging Face model needs and how many requests it serves. You can switch its precision between 16-bit, 8-bit and 4-bit. For KV cache sizing at long contexts, see our long-context GPU guide.
Test precision on your own prompts before you commit
Published benchmarks set your expectations. Your own evaluation decides. Run the same eval set at 16-bit, FP8 and, if your GPU supports it, NVFP4. Compare the scores against the drop you can accept.
Write that acceptable drop down before you start. Then the decision rule is short. Pick FP8 when it stays within budget. Pick NVFP4 only when FP8 does not fit your memory or cost target and NVFP4 still passes. Keep 16-bit when even a small change in answers is a problem.
A proof of concept on a dedicated endpoint is the place to run that test. Make your accuracy threshold one of its agreed success criteria. On a shared API today? Our guide on whether your provider quantizes the model shows how to check. Other 4-bit file formats are compared in our guide to 4-bit quantization formats.
Start with the memory. Enter your model in the sizing tool on our compute page and compare its memory at 16-bit, 8-bit and 4-bit.
Frequently asked questions
Does a quantized model give different answers from the 16-bit one?
It can, because each weight is rounded to a coarser value. For FP8 the published difference is usually too small to measure on standard benchmarks. Your own eval set is the only way to see it on your task.
Is NVFP4 the same as 4-bit GGUF or AWQ?
No. NVFP4 is a floating-point format with a shared scale for every 16 values, built for Blackwell GPUs. GGUF and AWQ are other open-source ways to store weights in 4 bits. Each has its own file format and tools.
Can I test Lyceum for free before committing, for example with trial credits or a proof of concept?
For serverless inference, you pay as you go with no commitment, so you can start small and scale when you're ready. For dedicated inference, we run time-boxed proofs of concept with success criteria we agree on before you commit. The customer pays for these proofs of concept. They usually run for a few days, up to a week, depending on the workload.