NVFP4 and MXFP4 store weights using the identical element format. Same E2M1 encoding, same fifteen values, same -6 to 6 grid. If you diffed the element tables you would find nothing.
Everything that separates them is metadata: how many elements share a scale, and what that scale is allowed to be. Those two choices are worth 36% more training tokens.
If you are here because a model tag said NVFP4 and you wanted to know whether to pull it, what Ollama NVFP4 means for local model quality is the practical version. This piece is the format comparison underneath it.
The two decisions
| NVFP4 | MXFP4 | |
|---|---|---|
| Defined by | NVIDIA | OCP, MX v1.0 standard |
| Element | FP4 E2M1 | FP4 E2M1, identical |
| Block size | 16 | 32 |
| Block scale | FP8 E4M3 | E8M0 |
| Scale can express | Arbitrary values (has mantissa bits) | Powers of two only |
| Second-level scale | FP32 per tensor | None in the standard |
| Bits per weight | 4.5 | 4.25 |
Block size. NVFP4 shares a scale across 16 elements, MXFP4 across 32. A smaller block means one outlier contaminates fewer neighbours. NVIDIA’s framing: “By reducing the block size from 32 to 16 elements compared to MXFP4, NVFP4 minimizes the influence of outliers and enables more precise scaling.”
Scale format. This is the bigger one. E8M0 has eight exponent bits and zero mantissa bits, so an MXFP4 scale can only ever be a power of two. If a block’s ideal scale is 1.5x, MXFP4 must round to 1x or 2x. NVFP4’s E4M3 has three mantissa bits and can land near the ideal. NVIDIA again: MXFP4 “is limited to power-of-two scale factors (E8M0) and prone to high rounding errors.”
The trade. NVFP4 costs 0.25 more bits per weight, 72 bits per 16 elements against 136 per 32. It buys accuracy with metadata, not with element width. That is the cleanest way to state the difference: same precision per number, more precision per group.
The 36% figure
From NVIDIA’s NVFP4 pretraining paper, the result worth quoting:
> MXFP4 matches NVFP4 loss when trained on 36% more tokens, 1.36T instead of 1T.
Also reported: relative training-loss error of roughly 2.5% for MXFP4 against 1.5% for NVFP4.
Read that as a compute statement. If MXFP4 needs 36% more tokens to reach the same loss, the 0.25-bit saving is not a saving at all: it costs a third more compute to cash in.
Two caveats we will keep attached to that number. It is NVIDIA measuring a format NVIDIA designed against the standard it chose not to adopt. And the 36% comes from an ablation at a 1T-token budget, not from the paper’s headline run (a 12B model on 10T tokens, described as the longest publicly documented 4-bit training run). Attribute it to the ablation, not the flagship.
Worth noting what the headline run actually required, because it undercuts any “just switch to 4-bit” reading: Random Hadamard transforms, 2D quantization, stochastic rounding, and selective high-precision layers. The format alone did not get there.
Why MXFP4 exists anyway
Because it is the standard, and NVFP4 is not.
MXFP4 comes from the Open Compute Project’s Microscaling Formats v1.0 spec, backed by AMD, Arm, Intel, Meta, Microsoft, NVIDIA and Qualcomm. NVIDIA signed that standard and then shipped a format that, in its own words, “departs from the OCP MX standard in two ways.”
So the choice is not purely technical. MXFP4 is what you reach for when you want a format that multiple vendors’ silicon will read. NVFP4 is what you reach for on Blackwell, or, as it turns out, on a Mac through MLX, which is the more surprising availability story and one we cover separately in NVFP4 on Apple Silicon.
What we have not verified
Three honest gaps:
- We did not read the OCP MX v1.0 spec PDF directly. The MXFP4 parameters here come from NVIDIA’s blogs and AMD’s ROCm documentation, which agree with each other, but are not the standard itself.
- We have not reproduced the 36% result, and it would take a training budget we do not have. This article is source reading, not measurement.
- We have no first-hand inference comparison of the two formats on the same model on our own hardware. Ollama’s MLX path imports mxfp4, mxfp8 and nvfp4, so once matching tags exist for one model family the comparison is runnable on a studio machine: the tensor audit we used in NVFP4 vs Q4_K_M, then size, memory, tokens per second and perplexity. That is the obvious follow-up, and it is measurement rather than reading.
The short version
- Identical element format. Both use FP4 E2M1: fifteen values, -6 to 6. See the corrected value table.
- NVFP4 differs in exactly two ways: block of 16, not 32, and an E4M3 scale instead of power-of-two E8M0, plus an FP32 per-tensor scale on top.
- NVFP4 costs 4.5 bpw against MXFP4’s 4.25. It buys accuracy with metadata.
- NVIDIA reports MXFP4 needs 36% more tokens for equal loss. Vendor-measured, from an ablation, not the headline run.
- MXFP4’s advantage is that it is the OCP standard and vendor-portable. NVFP4’s is that it is better, on the hardware that has it.