Microscaling: MXFP8, MXFP6, MXFP4 and Block Scales
OpenAI's gpt-oss models ship with their mixture-of-experts weights in a format called MXFP4, which is what lets the 120-billion-parameter version run on a single 80 GB GPU. MXFP4 is one of a family of formats, the OCP microscaling formats, defined jointly by AMD, Arm, Intel, Meta, Microsoft, NVIDIA, and Qualcomm. This piece explains the idea behind them, a scale for every block of 32 values, and measures what each member of the family costs on a real model.
Why blocks
The previous pieces showed that every low-precision format needs a scale, and that INT4 needs it shared by few values. The same is true for 4-bit floats. FP4 E2M1 has only eight magnitudes: 0, 0.5, 1, 1.5, 2, 3, 4, and 6. With one scale for a whole weight matrix of Qwen3-8B, the error is 68%: most weights fall below the smallest step. Floats help less than you might hope at 4 bits, because two exponent bits cannot follow values that vary by orders of magnitude.
The fix is to give each small group of values its own scale. The MX formats fix the group at 32 consecutive values and define the scale precisely.
The MX family


An MX block is:
- 32 elements in a small format: FP8 (E4M3 or E5M2), FP6 (E2M3 or E3M2), FP4 (E2M1), or INT8.
- One shared scale in a format called E8M0: 8 exponent bits, no sign, no mantissa. It can only be a power of two, from 2⁻¹²⁷ to 2¹²⁷, which is the exponent range of FP32.
Each value is element × scale. The scale costs 8 bits per 32 values, a quarter of a bit each: MXFP8 is 8.25 bits per value, MXFP6 6.25, MXFP4 4.25.
A power of two is a deliberate choice. Multiplying by a power of two only changes an exponent, so hardware can apply it almost for free, and the specification's dot product factors both blocks' scales out of the sum: multiply the 32 element pairs, add them, then apply the two scales once.
The specification also says how to choose the scale (section 6.3): take the largest power of two not above the block's largest absolute value, and divide it by the largest power of two the element format can represent. Elements that end up beyond the element format's maximum are clamped. Other conversion algorithms are allowed.
What each format costs
I applied each MX format, with the specification's scale rule, to all of Qwen3-8B's linear-layer weights and to the inputs of every linear layer on three prompts, and measured the error:


With a block scale, the mantissa sets the error. MXFP6 E2M3 (3 mantissa bits) is as accurate as MXFP8 E4M3 (also 3), and MXFP6 E3M2 matches MXFP8 E5M2 (both 2). The extra exponent bits of the 8-bit formats buy range that a scale per 32 values no longer needs. In this measurement, MXFP6 E2M3 gives FP8-level accuracy with 25% fewer bits.
MXFP4 is a big step down: about 12% error on weights and 11% on activations. With only one mantissa bit, that is expected; how much of it comes from the scale is the next question.
The scale rule matters
Two things about the E8M0 scale cost accuracy, and they can be separated by changing only the scale:
| Variant (weights / activations) | FP8 E4M3 elements | FP4 E2M1 elements |
|---|---|---|
| Spec rule, power of two rounded down, clamped | 3.05% / 3.49% | 11.75% / 11.30% |
| Power of two rounded up, nothing clamped | 2.66% / 2.60% | 11.76% / 9.05% |
| Exact FP32 scale per 32 values | — | 10.11% / 4.38% |
| One FP32 scale per tensor (no blocks) | 2.65% / 1.54% | 67.5% / 24.1% |
- Clamping. The specification's rule can place a block's largest value just above the element format's maximum, where it is clamped. For FP8 elements, that is the whole difference: rounding the scale up instead brings MXFP8 E4M3 back to plain FP8's 2.66% on weights.
- Coarseness. For FP4 elements, rounding up does not fix it. A power-of-two scale can be up to twice too large, and with only eight magnitudes, wasting half the range is costly. An exact scale on the same blocks of 32 cuts the activation error from 11% to 4.4%.
So MXFP4's weakness is its scale, not its block size. That is the problem NVIDIA's NVFP4 addresses with a finer scale and smaller blocks, at 4.5 bits per value: 9.5% on weights and 3.7% on activations here, close to exact scales. The next piece covers it.
These are weight and activation errors with round to nearest. A model trained or fine-tuned for the format, like gpt-oss, which OpenAI post-trained with MXFP4 weights, does better than this rounding suggests; how much each format costs in answers is measured in the quantization series.
In practice
- Models. gpt-oss-20b and gpt-oss-120b store their mixture-of-experts weights in MXFP4 and keep attention, the router, embeddings, and the output layer in higher precision.
- Engines. vLLM 0.31 lists
mxfp4and a dedicatedgpt_oss_mxfp4method, MXFP4 and MXFP8 schemes for llm-compressor checkpoints, and online MXFP8 quantization of BF16 models. - Hardware. The MX formats are an open standard, and support varies by GPU. The DeepSeek-V3 report notes that the tensor cores of NVIDIA's Blackwell generation "have announced the support for microscaling formats"; on GPUs without native support, engines convert to 16 bits to compute. The hardware piece of this series lists who supports what.
What to take away
- MX formats share one power-of-two (E8M0) scale per 32 values: MXFP8, MXFP6, MXFP4, MXINT8, at 8.25, 6.25, 4.25 and 8.25 bits per value.
- With a block scale, mantissa bits set the error: MXFP6 E2M3 matches MXFP8 E4M3 on Qwen3-8B (about 3%).
- MXFP4 costs about 12% on weights; its power-of-two scale is the main reason, which NVFP4 addresses.
This post is part of the Number Formats for AI collection (6 of 9)
Inference engineering and AI in production — depth-first, no hype.
Inference Notes
Once a week: what changed in serving AI models, and what it means if you build, run or pay for them, in about five minutes.
Related Articles
Quantization-Aware Training: When the Model Learns Its Own Precision
Why Kimi K2 Thinking ships in INT4 and gpt-oss and K3 in MXFP4: training with rounding in the loop, explained and measured on a small model.
Where Low Precision Bites: Rounding, Overflow, and Accumulation
Five places where low precision breaks real computations, each reproduced on Qwen3-8B's own tensors, and the fix every serious implementation applies.
Which GPU Computes Which Format: Ampere to Rubin, MI300 to MI355
Which number formats each data-center GPU computes natively, at what rate, from the vendors' own pages: A100 to Rubin, MI300X to MI355X.