NVFP4 does not range from -8 to 7.5: the 16 values, corrected

A single NVFP4 weight can hold one of fifteen numbers. The largest is 6. The smallest is -6. There is no 7.5 anywhere in the format, and there is no -8.

We keep meeting the claim that NVFP4 covers -8 to 7.5. It is wrong, it is specific enough to sound researched, and it is easy to disprove from NVIDIA’s own source code. So here is the actual value table, where the wrong number came from, and why the mistake matters more than a rounding quibble.

The sixteen bit patterns

NVFP4 stores each element as E2M1: one sign bit, two exponent bits, one mantissa bit. Four bits, sixteen possible patterns. NVIDIA’s TensorRT documentation writes it as S1E2M1.

Those sixteen patterns decode to exactly this:

“

0, +/-0.5, +/-1, +/-1.5, +/-2, +/-3, +/-4, +/-6

`

Count them and you get sixteen encodings but fifteen distinct numbers, because +0 and -0 are separate bit patterns naming the same value. The exponent bias is 1. The value 0.5 is the format's only subnormal. Normals follow (-1)^s x 2^(exp-1) x (1 + m/2).

There is no infinity and no NaN. All sixteen patterns are finite numbers, which is unusual enough that it trips people up. If you have read that E2M1 reserves an encoding for NaN, that source is wrong.

You do not have to take our word for the table. NVIDIA's quantization library states it as a literal in nvfp4_tensor.py:

`python

E2M1_MAX = 6

e2m1_values = [0, 0.5, 1, 1.5, 2, 3, 4, 6, 0, -0.5, -1, -1.5, -2, -3, -4, -6]

“

Note the 0 appearing twice, at index 0 and index 8. That is the plus-zero and minus-zero pair, and it is why sixteen slots hold fifteen values.

Three independent NVIDIA sources agree: the NVFP4 introductory blog post lists “0.0, 0.5, 1.0, 1.5, 2, 3, 4, 6” and describes the range as approximately -6 to 6; the TensorRT quantized-types documentation gives the quantized value range as [-6, 6]; and the code above hard-codes it.

So where does -8 to 7.5 come from?

The -8 is INT4. The 7.5 appears to be contamination.

INT4 is a signed four-bit integer, and its range is [-8, 7]. That is a real range for a real format that sits directly beside NVFP4 in every quantization comparison written. The clearest evidence for how the two got fused is that both numbers appear on the same NVIDIA documentation page. The TensorRT quantization schemes page gives NVFP4 as [-6, 6] and, further down, says of INT4 that the quantized value falls “in the range [-8, 7]“. Skim that page and you can walk away with the wrong pairing.

The .5 is the tell. E2M1’s distinctive feature is its half-steps: 0.5 and 1.5 are in the table, and no integer format has them. Our reading is that INT4’s upper bound of 7 picked up a half from E2M1’s grid on the way through somebody’s memory, and 7.5 was born. We want to be straight about the status of that explanation: it is an inference from where the two ranges sit in the documentation, not a traced origin. We could not find a single published page that states “NVFP4 ranges from -8 to 7.5” as a claim. It circulates as a *question*, which is its own interesting signal about how these errors now propagate.

What we can prove is that the claim is internally inconsistent. The fuller version of it asks for “-8 to 7.5, 16 values”. Check the arithmetic:

• -8 to 7.5 in steps of 0.5 is 32 values, not 16.
• -8 to 7 in steps of 1 is 16 values exactly. That is INT4, precisely.

The phrase takes INT4’s cardinality and welds it to a bound that belongs to nothing. No four-bit format, and no floating-point format we could find at any width, has a maximum magnitude of 7.5.

Why the correction is not pedantry

If you think NVFP4 spans -8 to 7.5 you will draw two wrong conclusions.

First, you will think NVFP4 is a competitor to INT4 on dynamic range. It is not, and it does not need to be. A raw NVFP4 element caps out at 6, which would be uselessly small for storing real model weights. The format works because of what sits above the element.

Second, you will misjudge where the precision comes from. NVFP4 is a *block-scaled* format, and the scaling is the whole design:

Sixteen elements at four bits each, plus one eight-bit scale, is 72 bits per 16 weights: 4.5 bits per weight, plus one negligible per-tensor float.

The two-level structure exists so the block scale can never overflow. NVIDIA’s quantizer computes the global scale as amax(tensor) / (E2M1_MAX x E4M3_MAX), which is amax / (6 x 448), the product of the two formats’ maximum magnitudes. Map the tensor’s largest absolute value into that product and every per-block scale is guaranteed to fit in E4M3. The global scale handles dynamic range; the block scale handles local precision. The element’s -6 to 6 is not the model’s range, it is the *shape of the grid* that a scale then stretches over each group of 16 weights.

That is the sentence worth keeping: the element range is a grid, not a limit.

The comparison that actually matters

Since the confusion is with INT4, put them side by side properly.

The important row is grid spacing. INT4’s sixteen values are evenly spaced. NVFP4’s fifteen are not: they crowd near zero, where the steps are 0.5, and spread out at the top, where the step from 4 to 6 is 2. Model weights cluster near zero, so a grid that is dense near zero and sparse at the extremes fits the data better than an even one at the same bit width. That is the argument for a floating-point four-bit format over an integer one, and it has nothing to do with which one reaches a larger number.

What NVFP4 buys, in NVIDIA’s numbers

Two figures are worth quoting, both from NVIDIA and both about the format rather than any one model.

Against MXFP4, the OCP standard format that uses the same E2M1 element but a 32-element block and a power-of-two E8M0 scale, NVIDIA’s own 4-bit pretraining write-up reports that MXFP4 needs 36% more training tokens to reach the same loss (1.36T against 1T in that ablation). Relative training-loss error came out around 2.5% for MXFP4 against 1.5% for NVFP4. We take that comparison apart in NVFP4 vs MXFP4.

Against FP8 at inference, NVIDIA reports 1% or less accuracy degradation for DeepSeek-R1-0528 moving from FP8 to NVFP4, at roughly 1.8x the memory saving, or about 3.5x against FP16.

We have not reproduced either result and are not presenting them as ours. Both come with the usual caveat that a vendor is measuring its own format. The 36% figure in particular comes from a smaller ablation, not from the paper’s headline 12B-on-10T-tokens run, so attribute it to the ablation rather than the flagship.

The short version

• An NVFP4 element holds one of 15 distinct values, from -6 to 6, across 16 bit patterns.
• The set is 0, +/-0.5, +/-1, +/-1.5, +/-2, +/-3, +/-4, +/-6. No infinity, no NaN.
• -8 to 7 is INT4. 7.5 is not a bound of any format.
• The element grid is stretched by an FP8 E4M3 scale over every 16 elements, with an FP32 global scale above that. Total cost: 4.5 bits per weight.
• If a source tells you NVFP4 spans -8 to 7.5, it has confused two adjacent rows of a comparison table, and you should distrust the rest of what it says about quantization.

For what the format does to output quality on a machine you can actually buy, see what Ollama NVFP4 means for local model quality. For the more surprising practical question of which hardware can run it, see NVFP4 on Apple Silicon. The answer inverts what the name implies.