Edge AI Quantisation: INT8, INT4 and Vendor Toolchains

Overview

Every dedicated edge AI accelerator – Hailo, Axelera, Blaize and their peers – runs neural networks in low-precision integer arithmetic. Your FP32-trained model does not run as-is: it must be quantised to INT8 or INT4 and compiled by the vendor’s toolchain before it executes at all. That pipeline, not the datasheet, determines what you actually ship: how much accuracy you lose, which operators run on the accelerator versus falling back to the host CPU, and how far real throughput lands from the headline TOPS. This article walks through the quantisation decisions – INT8 vs INT4, post-training quantisation vs quantisation-aware training, calibration data, accuracy measurement – and explains why toolchain evaluation matters more than silicon comparison.

Why edge accelerators force quantisation

Integer maths is the entire efficiency argument. An INT8 multiply-accumulate costs a fraction of the energy and silicon area of its FP32 equivalent, and 8-bit weights quarter the memory footprint and bandwidth – which is why a 2.5 W part can do useful work at all. Accelerator datapaths are therefore built integer-first: the vendor-stated 26 TOPS (INT8) of a Hailo-8 or 214 TOPS (INT8) of an Axelera Metis exist only at those precisions. This is a genuine architectural difference from GPUs, which retain strong FP16/FP32 paths – one reason the decision framework in edge AI accelerators vs GPUs starts with whether your model quantises well.

INT8 vs INT4: what actually changes

Quantisation maps floating-point tensors onto a small integer grid via a scale factor (and optionally a zero point). INT8 gives 256 levels per tensor – enough that mature per-channel schemes hold accuracy loss on well-behaved CNNs to a fraction of a percent. INT4 gives 16 levels: compute density and effective memory capacity roughly double – this is how the Hailo-10H reaches its published 40 TOPS (INT4) and fits ~2B-parameter language models into 8 GB of LPDDR4X – but outlier weights and activation spikes become much harder to represent. In practice INT4 is applied selectively: weights-only, per-group scales, sensitive layers (first, last, attention) kept at INT8 or higher. Two rules follow. Never compare an INT4 TOPS headline with an INT8 one – the operations are not equivalent. And treat INT4 accuracy claims as per-model empirical questions, not properties of the chip.

PTQ vs QAT: choosing the path

Post-training quantisation (PTQ) takes your trained FP32 model, runs a few hundred representative samples through it to observe activation ranges, and picks scales – no retraining, minutes to hours of work. It is the default path in every vendor toolchain and is usually sufficient at INT8. Quantisation-aware training (QAT) instead simulates quantisation during fine-tuning so the network learns around the rounding error. It recovers several points of accuracy on hard cases – compact models like MobileNet variants, heavily optimised detectors, most INT4 configurations – but requires your training data, pipeline and GPU time. The pragmatic sequence: PTQ first, measure, and escalate to QAT only where the measurement fails your acceptance threshold.

Calibration data and honest accuracy measurement

PTQ quality depends heavily on the calibration set. Use a few hundred to a few thousand samples drawn from your deployment distribution – your cameras, your lighting, your lens grime – not the vendor’s demo images. Include hard and rare cases; a calibration set of clean daytime frames will misquantise the night shift. Then measure properly:

• Compare compiled INT8/INT4 output against the FP32 baseline on a held-out validation set using task metrics – mAP for detection, F1 for classification – not just cosine similarity of logits.
• Check tail behaviour, not just averages: quantisation errors concentrate in exactly the rare classes and edge conditions that matter operationally.
• Re-run the full evaluation after every toolchain version bump; compiler updates change numerics.

Why toolchains diverge from datasheets

Two accelerators with similar TOPS can deliver wildly different compiled throughput on the same ONNX file. The reasons are structural. Operator coverage differs: each compiler supports a finite operator set, and anything outside it – an exotic activation, a custom NMS, a transformer block variant – either blocks compilation or falls back to the host CPU, where a single unsupported layer mid-graph can force round-trips that dominate latency. Graph-mapping quality differs: how well the compiler tiles, fuses and schedules your specific layer shapes decides utilisation, which is why vendor model zoos (all conveniently compiler-friendly) flatter every platform. And maturity differs: Hailo’s Dataflow Compiler, Axelera’s Voyager and Blaize’s Picasso are each years younger than TensorRT, and each has its own sharp edges – see our Hailo deep dive and Axelera Metis deep dive for the specifics. The only reliable evaluation is compiling your own models, and the toolchain column deserves as much weight as silicon in choosing edge inference silicon.

Toolchain landscape at a glance

Frequently asked questions