Community

Where the awkward cases get written down. Most of what is useful about a quantization format is not in the specification.

Empty data centre corridor between cabinets under cool blue lighting — A cold-aisle corridor between cabinets.

What this community is for

Most of what is useful about a quantization format is not in the specification. It is in the accumulated experience of people who hit a strange result and worked out why.

MXFP4 documentation splits awkwardly. The OCP specification tells you what the bits mean and nothing about what happens when you apply it to a real model. Vendor material tells you what runs fast on their part. Library documentation tells you which function to call. None of them tell you why your 3B model fell over when the 70B one was fine.

That gap is what this exists for. It is vendor-neutral by construction, and it is more interested in reproducible negative results than in success stories.

How to write a useful report

A report with these eight things in it will get a useful answer. One without them usually generates six clarifying questions first.

State the model, parameter count and whether it was already distilled or pruned
State weight-only or weight-and-activation, and the exact exclusion list
State the block size and which axis the blocks run along
Give the bf16 baseline measured on the same harness, plus its run-to-run spread
Say whether the kernel path was native, emulated or storage-only
Include the per-layer relative Frobenius error report if you have it
Say explicitly which numbers are measured and which are estimated
Attach the smallest reproduction you can — one layer beats a whole model

Discussion areas

Format and numerics. Encoding questions, scale selection policies, error analysis, and arguments about whether a given behaviour is spec-mandated or library-specific.
Kernels and performance. Unpack scheduling, tile shapes, native versus emulated paths, and profiling methodology.
Model reports. What worked, what did not, and the exclusion lists people actually shipped.
Interoperability. Checkpoint conventions, converter bugs, and the ongoing campaign to get people to ship a test vector with their format.
Beginner questions. Explicitly welcome. Half the FAQ came from them.

Ground rules

No vendor benchmarketing without a reproducible method. Label illustrative numbers as illustrative. If you correct someone, correct them with a test case. Uncertainty is fine to state; confident hand-waving is not.

Standing principles

Vendor-neutral: no sponsored content, ever
Test vectors: shipped with every converter we endorse
Negative results: explicitly wanted, not buried
Plain language: the spec is already precise enough

Where to start

Start here

Bring a reproduction. The fastest way to get a real answer is a single layer, a block size, and a number that disagrees with what you expected.

Contact · Read the guides