The canary that was already dead
Quantising a model to INT8 is supposed to cost accuracy. The question is never “does it cost some” — it is “does it push a passing case under the bar.” A note on measuring the right thing.
The plan named a canary: one detection column, torpedo_1, which INT8 must not push below 15 inliers. Sensible-sounding. It was also wrong, and following it would have killed a working feature.
The bar was set up honestly: re-run the murky-water clip table with the chip as the backbone and everything else identical — the same post-processing, the same MAGSAC, the same 15-inlier trust threshold, the same protocol. The only variable was float32-on-CPU versus INT8-on-Hailo. Every clip scored exactly what it scored on CPU: 4/4, 3/4, 4/4, 4/4, 4/4.
Read the tell
Quantisation cost a median 7.7% of inliers — and in 5 of 20 columns INT8 read higher, up to +40%, which is MAGSAC’s own scatter, not the chip being smarter. The number that actually decides the arm is different: zero passing columns crossed the bar. 19 of 20 clear 15 inliers on CPU, and the same 19 of 20 clear it on the chip.
Reporting the wrong quantity is what lets a defect survive three attempts.
The canary, torpedo_1 at 12 inliers on the chip, already read 13 on float32. It was below the bar before quantisation ever touched it. Reading its 12 as an “INT8 failure” would have condemned a working arm on a case that was already dead. The real question was whether quantisation pushed any passing column under — and none did. Measure the effect you actually care about, through the shipped code path, or you are measuring the harness.