The same model, run on a laptop, on a server and on an emulated microcontroller, returns the same words byte for byte. Not "close". Identical to a single-precision computation. For a product that has to be certified or formally reviewed, that turns "the deployed model behaves like the validated one" from an argument into a test that either passes or fails.
The three environments
| Stage | What it is |
|---|---|
| Python · PyTorch | The reference forward pass. This is the thing your data scientist validated. |
| C99 · zero-heap | The inference engine. No allocator, no syscalls. This is the thing that ships. |
| Cortex-M3 · QEMU MPS2-AN385 | The cross-compiled ELF actually executing on an emulated core. |
The numbers
| Check | Result |
|---|---|
| Max |Δ| across all three stages | 3.7e-7 |
| Multi-token parity, 60K demo model | 48 / 48 exact |
| Multi-token parity, 944K model | 16 / 16 exact |
| Test suite at HEAD | 146 / 146 green |
Verified by tests/test_parity_with_c.py and
tests/test_parity_multitoken.py. Every number reproducible from a cold
checkout.
Why the multi-token test is the one that matters
A single-forward-pass parity test is easy to pass and easy to fool. Generation is autoregressive: the model's own output becomes its next input, so a discrepancy in the seventh decimal place at token 1 can become a different word at token 40. Multi-token parity runs the whole generation loop in both environments and compares the emitted sequences. 48 of 48 and 16 of 16 exact means the divergence never got a chance to compound.
The same discipline on the EDGE line
The sensing engine gets the same treatment against a harsher bar, because there the artifact is int8 and quantization is where parity claims usually die.
- The real C99 engine scored on all 2,947 held-out windows, not a sample: 0.9206 accuracy, 99.19% agreement with the Python float model.
- The ternary-32 export: 2947/2947 windows identical between the real C engine and the reference — exact parity, not statistical agreement.
- The streaming path: bit-identical decisions to full recomputation on every window, which is what makes the 27.3× per-decision saving a free lunch rather than a trade.
What a parity claim is worth when it is not executed
A cautionary note that belongs on this page rather than in a changelog. A previous export carried the line "parity: C == torch-static (by construction)". The reasoning was sound and the C engine had never actually been run on the test set. When it finally was, it surfaced a buffer overflow: three arrays hardcoded to 24 channels while the channel count was read at runtime, with no bounds check. On a device that is silent memory corruption, not a wrong answer. It sat there for four weeks behind a claim that sounded like a measurement.
That is why the numbers on this page name the test file that produces them. "By construction" is a hypothesis. A green test on the real artifact is a result.
What is not proved here
- Silicon timing. QEMU proves the arithmetic, not the clock. Cycle counts elsewhere on this site are Unicorn emulation with a documented cycle table and are labelled as lower bounds.
- Cortex-M33. The ARMv8-M build faults under Unicorn's ARM model and never reaches its semihosting write under QEMU mps2-an505. No M33 number exists.
- Energy. Never measured on hardware. See limitations.
Questions
What does bit-exact parity mean?
That the Python reference implementation, the C99 engine and the cross-compiled binary running on an emulated Cortex-M3 produce the same output, byte for byte. The maximum absolute difference across all three stages is 3.7e-7, and multi-token generation is exact: 48 of 48 on the 60K model and 16 of 16 on 944K.
Why does bit-exactness matter for a regulated device?
Because certification asks you to show that what ships behaves like what was validated. If the on-device engine is byte-identical to the reference, that becomes a test with a pass or fail rather than an argument about acceptable drift.
Is parity verified on real hardware or in emulation?
In emulation — QEMU MPS2-AN385 running the actual cross-compiled ELF. That proves the arithmetic path. It does not prove timing or energy, and this site does not claim it does. Separately, the 944K model has been run on a physical ESP32-WROOM-32.