Authors
Rouhani, David, Nic, Tutus, Awwad, Khorzad, Bhandari, Garg
Affiliations
NVIDIA / OCP MX working group
Problem
Narrow formats force a choice between hardware efficiency and accuracy, and per-tensor scales are too coarse for weights and gradients that vary wildly element to element.
Mechanism
Defines the OCP Microscaling (MX) family: a shared power-of-two scale per fixed 32-element block plus a narrow element format (E2M1/E3M2/E4M3/E5M2 for floats, E8M0 for the shared scale). The shared block scale is what makes the format hardware-friendly - one scale for 32 elements amortizes the scale-fetch cost to near nothing - and the choice of block size 32 is a hardware decision, not an accuracy one. Evaluated as a drop-in FP32 replacement across two dozen benchmarks.
Speedup reported
Paper's own claim (abstract): MX formats are a practical drop-in replacement for FP32 for inference and training with low user friction, evaluated over two dozen benchmarks, plus the FIRST instance of training generative language models at sub-8-bit weights, activations AND gradients with minimal accuracy loss and no modification to the training recipe. COMPRESSION RATIO: with the shared scale, 8-bit elements land near 8.3 bits/weight and 4-bit elements near 4.25 bits/weight - the block scale is overhead, not savings. QUALITY COST: 'minimal accuracy loss' for the sub-8-bit training result; the exact per-benchmark deltas are in the paper's tables, not the abstract.
notes
arXiv ID 2310.10537 verified via /abs/; v3. Venue: Semantic Scholar returns arXiv.org and there is no conference record - recorded as arxiv-preprint with year = v1 year 2023. This is the OCP MX specification paper, which is why adoption is in-production: MXFP8/MXFP4 are native formats on Blackwell-class parts, matching the repo's quantization/mxfp8 and mxfp4 records. arXiv ID and title verified by fetching https://arxiv.org/abs/2310.10537 and reading the citation_title meta tag on 2026-10-03. Venue and year from the Semantic Scholar graph API batch endpoint (paper/arXiv:2310.10537) unless the record's notes say otherwise.
VENUE_TRACK BACKFILL 2026-10-04 (paper-fields pass, agent w3p): venue_track 'unknown'. `venue` is 'arxiv-preprint', which means no peer-reviewed venue has been established for this work as of the verification date, so the track genuinely is not known. 'unknown' is used here rather than leaving the field null or guessing 'main': the schema separates 'unknown' from 'main' precisely so that an unprereviewed preprint is not silently counted as main-track work. This annotation is what lets a downstream filter distinguish 'peer reviewed, main track' from 'not peer reviewed' without inferring it from the venue string.