FP8 vs MXFP4 vs BF16: Why Your Quantized LLM Disagrees Across GPUs

A checkpoint quantized to “FP8” on one GPU can legitimately round to different bits on another, because FP8 names a family of formats, not a number system: E4M3 tops out at ±448 while E5M2 reaches ±57344², and MXFP4 layers a power-of-2 block scale on top of that ambiguity. A new preprint, the “Golden Ruler” numeric format catalog (arXiv:2606.09686), ships six bit-exact conformance packs covering FP8 E4M3 and E5M2, BF16, GF16, MXFP4 elements, and E8M0 block scales, giving builders a testable definition of what each format guarantees. Everything in this article is conditional on one caveat: this is a single, author-reported preprint with no peer review, cross-validated against exactly one software reference implementation (ml_dtypes 0.5.4 from Google/JAX) and zero vendor hardware. Nothing in it has been independently run on NVIDIA, AMD, or Apple silicon, so treat its divergence claims as a hypothesis your own CI can confirm, not as measured fact.

What do “FP8” and “MXFP4” actually name?

Neither term names a single number system; both are umbrella specs that collapse several distinct rounding behaviors into one marketing-friendly label. “FP8” covers at least two formats with different exponent and mantissa splits, E4M3 and E5M2, a point both NVIDIA’s Transformer Engine primer and Exxact’s FP8/FP6/FP4 explainer state explicitly. Two checkpoints that both say “FP8” on the model card can therefore disagree on every large-magnitude value they store, because the two variants allocate their eight bits differently.

MXFP4 belongs to a structurally different family. Microscaling (MX) formats are a kind of block floating point in which a block of elements, typically 32, shares a single scaling factor stored as an 8-bit exponent: a Hugging Face MXFP4 writeup describes “small blocks (typically 32 elements)” each assigned “a single, shared 8-bit exponential scaling factor,” and the Golden Ruler catalog names that scale format E8M0 and ships a conformance pack for it (arXiv:2606.09686). The element values and the scale are quantized separately, under different rules, and both contribute rounding error. Calling MXFP4 “4-bit FP8’s little sibling” misses the point: it is a two-level number system where the exponent of a shared scale does work that per-element exponent bits do in plain FP8.

NVIDIA’s own documentation blurs this line. The Transformer Engine primer introduces MXFP8 in passing, “Blackwell added support for NVFP4 and MXFP8 datatypes,” grouped with FP8 under the primer’s blanket phrase “these low precision datatypes,” a framing that treats block floating point as one more item in the FP8 lineage rather than a different scaling architecture. That framing is convenient if you sell the silicon that runs it natively. It is less convenient if you are trying to reproduce a number across vendors.

The scope of the ambiguity is what the Golden Ruler paper is actually about. The catalog now covers 109 numeric formats spanning 12 clusters¹, up from 83 formats at v2, and the authors note that the count “is a catalog invariant, not a fixed number.” Read that sentence twice. The authors of the most thorough conformance work in this area are telling you the format landscape is still expanding faster than their own catalog can stabilize. Any build pipeline that assumes “FP8” is a settled target is assuming something the people measuring it decline to assume.

How do the formats differ, bit by bit?

The core tradeoff inside 8-bit floats is exponent range against mantissa precision, and the two FP8 variants sit on opposite ends of it. NVIDIA’s primer gives the layouts directly:

The table’s rows for BF16 and GF16 are deliberately absent: the Golden Ruler’s conformance packs cover both (arXiv:2606.09686), but none of the documentation cited here lays out their bits the way NVIDIA’s primer does for FP8, so those rows wait for a source that documents them.

The ±448 ceiling on E4M3² is the number that should worry anyone running activations through it. An activation tensor with outliers past that ceiling has nowhere to go in E4M3; it clips or wraps depending on the saturating behavior of the implementation, while the same tensor in E5M2 fits comfortably at the cost of a mantissa only two bits wide. Two runtimes that both advertise “FP8 inference” but default to different variants will produce measurably different outputs on activation-heavy workloads, and the difference will be largest exactly where the model’s outlier structure is most pronounced. This is not a subtle numerical-analysis footnote. It is the expected behavior of two formats that made opposite bets on the same eight bits.

E5M2’s inclusion of ±inf is also operationally relevant. Values that overflow E4M3’s finite range can exist in E5M2 as infinity, which changes how downstream NaN and overflow handling behaves. A pipeline validated on E5M2 hardware that silently produces inf may fault differently on an E4M3 path that saturates instead. Bit-exact conformance testing catches this class of divergence before users do.

Why is scaling the portability killer?

The structural difference between plain FP8 and MXFP8 is not the element precision but the scaling semantics: FP8 uses an FP32 (E8M23) scaling factor, while MX formats assign each 32-element block a shared 8-bit power-of-2 scale, per the Hugging Face MXFP4 writeup; the Golden Ruler catalog names the scale format E8M0 and tests it as its own conformance pack (arXiv:2606.09686). One is a near-continuous multiplier chosen per tensor. The other is a coarse, exponent-only multiplier chosen per 32-element block.

That difference compounds. With per-tensor FP32 scaling, one scale decision affects the whole tensor uniformly, and the scale itself is essentially exact. With per-block E8M0 scaling, every 32-element group gets its own scale, that scale must round to a power of two, and the rounding of the scale is itself a quantization step applied multiplicatively to all 32 elements. Two implementations that choose block boundaries differently, or that round the scale exponent differently at edge cases, will produce different dequantized weights from identical input tensors. The element format can be identical bit for bit and the final values still diverge.

This is where “portable quantized checkpoint” stops being a coherent phrase. A checkpoint stores elements and scales. If the consuming runtime’s block size, scale rounding mode, or scale dtype differs from the producing runtime’s, the checkpoint is not wrong; it is under-specified. The model card said “MXFP4” and meant a specific configuration of element format, block geometry, and scale encoding. The reader saw “MXFP4” and assumed a different one. Both parties followed the spec, because the umbrella spec permits both readings.

The IEEE is working on closing exactly this hole. The Golden Ruler paper ships a cross-walk mapping each of its conformance packs to a corresponding IEEE P3109 v3.2.0 configured format, described in the abstract as standards-track (arXiv:2606.09686). Standards-track is process language, not ratification. Until a finished standard lands and vendors implement against it, “the spec allows it” will keep covering behavior that breaks reproducibility.

What does the hardware actually support?

Native acceleration, as far as the documentation for this article reaches, is a NVIDIA story. NVIDIA’s primer states that the “H100 GPU introduced support for a new datatype, FP8” and that “Blackwell added support for NVFP4 and MXFP8 datatypes.” That is where the documented record stops. Nothing here addresses low-precision float support on AMD, Apple, or any other vendor’s silicon, and every cross-vendor portability claim should be read against that gap.

The implication for the title’s question is uncomfortable. Where a platform lacks native MXFP4, the path is emulation, dequantization to a wider format, or a software kernel, each of which introduces its own rounding decisions. Emulated MXFP4 is not required to round the way a native path rounds, and absent a conformance suite, nobody is checking. No documentation reviewed for this article covers how AMD or Apple hardware rounds MXFP4, so any specific claim about those platforms would be a guess wearing a citation.

The honest summary of hardware coverage: Blackwell does MXFP8 and NVFP4 natively, per NVIDIA’s own primer; everything else is some mixture of native FP8 (in one or both variants), wider-format fallback, and software emulation. “We ran the MXFP4 model on three platforms” currently means three different numerical paths sharing a checkpoint, which is a fine thing to benchmark as long as nobody calls the output spread a quality difference.

How do you run the conformance packs in CI?

The Golden Ruler’s practical contribution is six bit-exact conformance packs, covering GF16, MXFP4 element, BF16, FP8 E4M3, FP8 E5M2, and E8M0 block scale, each cross-validated against ml_dtypes 0.5.4 and mapped to a P3109 v3.2.0 configured format (arXiv:2606.09686). A conformance pack is a set of input values with known-correct output bit patterns: feed the input through your conversion path, compare the resulting bits against the vector, fail the build on any mismatch. The pack turns “does our E4M3 cast round correctly?” from a philosophical question into an assertion.

An operational CI gate built on this looks roughly like:

1. Pin the format variant in the model card. “FP8” is not acceptable; “FP8 E4M3, per-tensor FP32 scale” is. “MXFP4” is not acceptable; the block size and E8M0 scale encoding must be explicit. This step costs nothing and eliminates the largest class of portability failure, which is two teams reading the same label differently.
2. Pin the reference implementation. The packs are validated against ml_dtypes 0.5.4 specifically (arXiv:2606.09686). Conformance vectors are only as portable as their reference; an unpinned ml_dtypes dependency means your gate can change meaning when the library updates.
3. Run all six packs against your conversion kernels, including any emulation or dequantization paths you ship for hardware without native support. A mismatch on the E8M0 block-scale pack is a red flag that your scale rounding diverges from the reference, which will corrupt every value in affected blocks.
4. Gate the quantized build on the result. Ship the checkpoint only if every pack passes on every target you claim to support. Where a target fails, the correct output is a documented divergence, not a silent ship.

A sketch of the gate, with the details left to your harness:

PACKS = ["gf16", "mxfp4_element", "bf16", "fp8_e4m3", "fp8_e5m2", "e8m0_scale"]

def test_conformance(target_backend):
  import ml_dtypes
  assert ml_dtypes.__version__ == "0.5.4" # the reference the packs were validated against
  for pack in PACKS:
  vectors = load_golden_ruler_pack(pack)
  for inp, expected_bits in vectors:
  got_bits = target_backend.convert_and_pack(inp, format=pack)
  assert got_bits == expected_bits, (
  f"{pack}: {inp} -> {got_bits:#x}, expected {expected_bits:#x}"
  )

The point of running this in CI rather than once at quantization time is that the failure modes arrive later: a kernel update, a new backend, a compiler flag that flips a rounding mode. Bit-exact vectors catch all of these because they do not care why the bits changed.

What does this do to cross-vendor benchmarks?

Cross-vendor comparisons of quantized models inherit format noise, which converts reproducibility from a documentation task into a test-suite task. The standard benchmark report format, “model X quantized to FP8, run on hardware A vs hardware B,” assumes the quantization is a fixed point and the hardware is the variable. The format taxonomy says otherwise. If hardware A’s runtime defaulted to E4M3 and hardware B’s to E5M2, or if one used per-tensor scaling and the other per-block E8M0, the measurement compared two different number systems and attributed the spread to the silicon.

This has second-order consequences for anyone buying on benchmarks. A vendor whose stack happens to default to the more permissive variant (E5M2’s ±57344 range² with inf) will look better on activation-heavy workloads than one defaulting to E4M3, regardless of hardware quality. A MXFP4 result from a native path, wherever one exists, is not comparable to an emulated MXFP4 result elsewhere until someone demonstrates bit-level agreement on the conformance vectors, which today means running the Golden Ruler packs and publishing the pass/fail. Benchmark methodology sections need a new line item: exact format variant, scaling regime, and conformance status. Absent that line, the numbers are not wrong, but they are not about what the headline claims they are about.

The fix is cultural as much as technical. The field absorbed “what precision?” years ago; FP16 vs BF16 is now a standard footnote. “Which FP8, scaled how, verified against what?” is the same question one layer down, and the tooling to answer it, per arXiv:2606.09686, now exists in runnable form. The excuse window is closing.

How far should you trust the catalog?

Trust the format mechanics, which are corroborated by vendor documentation, and treat the conformance suite as a promising, unverified artifact until it has been run against actual hardware from more than one vendor. The paper’s own evidence base is narrow: one preprint, author-reported, cross-validated against a single software reference (ml_dtypes 0.5.4), with no independent verification against NVIDIA, AMD, or Apple silicon (arXiv:2606.09686). The environments explicitly excluded from its validation are the ones readers care about most: the physical tensor cores whose rounding behavior the vectors claim to define. There is also a bootstrapping subtlety worth naming: the packs are validated against ml_dtypes, so a bug shared by the paper’s generator and the library would pass every check.

The catalog’s churn reinforces the caution. It grew from 83 formats at v2 to 109 now¹, with the authors describing the count as a catalog invariant rather than a fixed number. The P3109 formats the paper cross-walks against are versioned v3.2.0 and described as standards-track, process language rather than ratification. The ground under this article is moving; the bit layouts above are durable, but the catalog version numbers and standards references will date quickly.

The practical verdict stands regardless of how the preprint fares under replication. Pin the exact format variant and scaling regime in every model card. Gate quantized builds on bit-exact conformance vectors, pinned to a specific reference implementation, run on every backend you ship. Treat any cross-vendor quantized benchmark delta as containing format noise until the two runs demonstrate conformance on the same vectors. If the Golden Ruler’s packs survive contact with real hardware, they are the obvious candidate for that gate; if they do not, the divergence they expose will itself be the finding, because it will mean the reference implementations the ecosystem quietly relies on do not agree with the silicon either.

Frequently Asked Questions

Does the Golden Ruler conformance suite validate against AMD or Apple silicon?

No. The packs are cross-validated exclusively against ml_dtypes 0.5.4, a software reference implementation from Google/JAX. There is zero independent verification against NVIDIA, AMD, or Apple hardware, meaning the suite defines a software baseline rather than a cross-vendor hardware standard.

How does the E8M0 block scale in MXFP4 differ structurally from the FP32 scale in standard FP8?

E8M0 is an exponent-only format with no mantissa, forcing the scale to be a strict power of two. Standard FP8 uses an FP32 (E8M23) scale, which includes a mantissa and allows non-power-of-two multipliers. This makes E8M0 coarser and more prone to rounding errors when applied to 32-element blocks.

What is the risk of pinning ml_dtypes 0.5.4 as the conformance reference?

The primary risk is a shared bug between the conformance vector generator and the ml_dtypes library. If both implementations contain the same error, the test will pass despite incorrect behavior. Additionally, pinning to a specific version means the conformance gate may become stale if the library updates its rounding logic or format support.

Why is the format count in the Golden Ruler catalog described as a ‘catalog invariant’?

The term indicates the count is a dynamic property of the catalog’s current state, not a fixed specification limit. The catalog grew from 83 formats in v2 to 109 in the current version, signaling that the numeric format landscape is still expanding and that the catalog is a living document rather than a static standard.