MXFP4

Four bits per weight, one exponent per block. A vendor-neutral reference for MXFP4: how the format is laid out, what the block scale actually buys you, where the error comes from, and the cases where you should reach for something else instead.

Specification

OCP Microscaling Formats · MXFP4

Element format

E2M1 — 1 sign, 2 exponent, 1 mantissa

Scale format

E8M0 — 8 exponent bits, one per block

Block size

k = 32, along the reduction axis

Effective width

4.25 bits/element (3.76× vs bf16)

Status

community reference, vendor-neutral

Definition

MXFP4 is a block floating-point format from the Open Compute Project microscaling specification. Every group of 32 values shares a single 8-bit power-of-two scale (E8M0), and each value in that group is stored as a 4-bit E2M1 float — one sign bit, two exponent bits, one mantissa bit. That works out to 4.25 bits per element, roughly a 3.8× reduction against bf16, and unlike a flat 4-bit integer scheme the per-block exponent lets a tensor with wildly varying magnitudes keep its dynamic range.

The catch is precision, not range. With one mantissa bit there are eight representable magnitudes per sign, spaced non-uniformly, so the relative error inside a block is large and irreducible. MXFP4 wins where a model tolerates that; it loses where it does not. This site tries to be specific about which is which.

Numbers worth memorising

4.25

effective bits per element, including the shared scale

32

elements per block in the common MX configuration

8

representable magnitudes per sign in E2M1

E8M0

scale format: exponent only, no sign, no mantissa

Format reference

Start here if you want to know what the bits mean before you trust a benchmark.

Bit Layoutspec

/format/bit-layout/E2M1 element encoding, the E8M0 scale, subnormals, NaN handling and nibble packing.

Block Scalingspec

/format/block-scaling/How the shared exponent is chosen, what it recovers, and where it fails.

Quantization Erroranalysis

/format/quantization-error/Where the error actually comes from, and why it is relative rather than absolute.

Hardware Supportecosystem

/format/hardware-support/Native vs emulated paths, and why 'supported' means three different things.

Kernel Supportecosystem

/format/kernel-support/What a real MXFP4 GEMM does, dequant-in-register vs native MMA, and packing conventions.

Practical guides

Written assuming you have a checkpoint and a bad evaluation number.

Quantizing Your First Modelguide

/guides/quantizing-your-first-model/A weight-only pass end to end, with the layers you should not touch.

Calibrationguide

/guides/calibration/What calibration does and does not do for a block-scaled format.

Choosing Block Sizeguide

/guides/choosing-block-size/Block size 32 is the default for a reason. When 16 is worth the overhead.

Troubleshooting Quality Lossguide

/guides/troubleshooting-quality-loss/A decision tree for when the quantized model is worse than it should be.

What this site is careful about

This is a community reference, not a vendor page. Where something is uncertain, it is labelled uncertain.

• Separating what the OCP spec mandates from what a given library happens to do
• Saying when a number is illustrative rather than measured
• Distinguishing weight-only quantization from full activation quantization
• Naming the cases where int8 or a mixed-precision scheme is simply the better answer
• Flagging behaviour that is implementation-specific rather than portable
• Keeping hardware claims tied to what the vendor documentation actually says

Contributing