Neural-network weights that sit near each other tend to share a magnitude. Block floating-point exploits that: a block of weights keeps a single shared exponent, and every element in it stores only a handful of bits. That is the idea behind the OCP Microscaling (MX) formats — MXFP4, MXFP6, MXFP8 — and SC-NeuroCore encodes weights into them for compact weight storage. Drive the encoder below and watch the trade between size and fidelity.
In ordinary float32 every number carries its own 8-bit exponent, most of which is redundant across neighbouring weights. Microscaling factors that redundancy out: partition the weights into blocks of $B=32$, store one 8-bit exponent for the block, and give each element just $k\in\{4,6,8\}$ bits. The block's exponent sets the scale; the element bits place each value within it.
Every reconstructed value snaps to one of a few discrete levels set by the block scale — coarsely for MXFP4 (one mantissa bit per element, so each nonzero weight rounds to $0$ or the block scale), finely for MXFP8. Widen the weight spread and the shared exponent climbs to keep the largest weight in range, spreading the same levels over a wider window. The compression ratio and round-trip error shown are the ones the library produces on this block, computed the same way its encoder and decoder do.
Each format is a point on a single trade-off: fewer element bits give more compression and coarser weights. The bit budgets and compression ratios below are exact for a 32-element block with an 8-bit shared exponent; the round-trip error figures are representative of a unit-scale weight block and move with the weight distribution.
| Format | Element bits | Mantissa | Bits / block | Compression | Typical use |
|---|---|---|---|---|---|
| MXFP4 | 4 | 1 | 136 | 7.5× | Aggressive weight ROM shrink; coarsest |
| MXFP6 | 6 | 2 | 200 | 5.1× | Middle ground of size and fidelity |
| MXFP8 E4M3 | 8 | 3 | 264 | 3.9× | Highest fidelity of the MX set here |
| MXFP8 E5M2 | 8 | 2 | 264 | 3.9× | Wider element range, coarser mantissa |
A standalone FP8 variant (block size 1, no shared exponent) is also in the catalogue for element-wise use. The compression ratios are the library's bits_per_block against a 32-bit baseline — the same arithmetic the demo prints.
Honesty about the implementation: this is a block floating-point encoder in the MX family. It stores one 8-bit exponent per block and, for each element, a sign plus a low-bit linear mantissa scaled by that block exponent. The element widths (4/6/8) and the 32-element block match the OCP Microscaling naming and geometry, and the labels E4M3 / E5M2 are carried through — but the per-element value here is a linear mantissa, not a full per-element mini-float with its own exponent field. So it is a faithful block-FP quantiser in the MX family, not a bit-exact reproduction of every OCP per-element datatype.
Compact weights are a hardware concern: on an FPGA the weight ROM is often the tightest resource, and cutting each weight from 32 bits to 4–8 multiplies how large a network fits on-chip. Microscaling sits in the compiler's analysis layer alongside the other target-side transforms, and it composes with the stochastic and spike encodings the rest of the site describes — those encode activations into streams, this encodes weights into blocks.
Evidence boundary: the demo runs the library's exact block encode/decode arithmetic in your browser on random weights — compression ratios are exact from the bit budget; round-trip errors are for the block on screen and depend on the weight distribution, not a model-wide accuracy claim. Accelerator names (H100 / B100 / MI300) refer to formats those devices consume, not to a shipped vendor integration. No throughput figures are quoted.