TinyML Integer Quantization: Keep Calibration Data in the Deployed Input Domain

A model becomes smaller after conversion, so the firmware team assumes it is ready for an integer-only inference path. The exported input is still float, or the model now classifies poorly despite accepting the expected data. These are different problems: the conversion policy controls which numeric forms remain, while calibration determines ranges from the samples actually supplied.

Make the model-input boundary explicit before adjusting quantization flags. A representative dataset must represent what reaches that boundary, not merely come from the same physical sensor.

Feed calibration in the original model's input domain

The RepresentativeDataset API requires generated samples to match the model inputs in order, type and shape. The converter uses them to estimate ranges for floating-point tensors, including intermediate activations.

Suppose a deployed pipeline converts raw sensor counts into normalized features before calling a float model. Calibration must supply those normalized features at that model boundary. Passing raw counts instead can cause range estimation to describe a different signal. If the normalization is inside the graph, however, feeding already-normalized values can apply it twice.

Inspect a generated calibration item before converting: its input order, dimensions, element type and representative value range. For multiple inputs, a swapped pair with identical shapes can evade a superficial shape check while changing the model's meaning.

Do not pre-encode calibration inputs as int8 merely because the desired exported interface is int8. Match the original model's declared input contract, then let the converter determine the quantized representation.

Distinguish weight quantization from an integer interface

Google's integer-quantization tutorial separates dynamic-range quantization, calibration with float fallback and integer-only conversion. Enabling Optimize.DEFAULT alone can quantize stored weights while leaving other data in float form.

Providing representative data does not by itself force integer input and output tensors. The tutorial explicitly shows that float interfaces can remain, and unsupported operations can remain float when fallback is allowed.

For an intended int8 interface, review these settings together:

  • converter.optimizations = [tf.lite.Optimize.DEFAULT]
  • converter.representative_dataset = representative_data_gen
  • converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
  • converter.inference_input_type = tf.int8 and converter.inference_output_type = tf.int8

The converter API reference documents int8 and uint8 interface choices for integer quantization. The intended choice must agree with the firmware; copying a uint8 tutorial into an int8 input path creates a different contract.

Diagram linking representative input preparation, integer conversion settings, exported tensor inspection and model evaluation.
Original calibration and conversion diagram. No model was trained, converted or evaluated.

Inspect the exported artifact rather than its filename

Open the actual converted model and inspect its input and output details. A filename ending in int8 is not evidence about tensor types. Read the resulting scales and zero points as well, since the firmware must consume this export's parameters.

An integer-only conversion constraint deliberately turns an unsupported quantized operation into a conversion failure. Removing that constraint may make conversion finish, but it changes the deployment requirement rather than satisfying it.

Also avoid equating integer-only with “every tensor is eight bits.” The quantization specification includes int32 biases for common int8 operators. The important question is whether the runtime supports the complete resulting graph, including its types and operations.

Evaluate calibration quality separately from conversion success

Compare the float and quantized models on the same labeled evaluation examples using equivalent preprocessing. Examine class-specific failures and operating conditions, not only whether one demonstration sample still gives the expected label.

Choose calibration examples that cover plausible deployed inputs. A convenient group collected under one quiet, well-lit or stationary condition may miss important activation ranges. The API's description of a small representative subset is not a guarantee that a fixed sample count suits every application.

If the float model already fails on device-like inputs, quantization is not the only issue. If float performance is acceptable but the quantized result degrades, investigate calibration coverage and numeric effects before changing the MCU's decision thresholds.

Finally, the microcontroller conversion guide retains separate memory and operator constraints. Passing conversion and host evaluation does not establish target compatibility or timing. Carry the verified exported tensor contract into the firmware test, where those remaining deployment questions can be checked directly.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *