Decision guide
PTQ methods
PTQ works on any vision ONNX model: classification, detection, segmentation, pose. No training, so it is the fastest path to a quantized model.ptq_static (default): smallest and fastest, needs images
ptq_static (default): smallest and fastest, needs images
Needs: a representative set of calibration images (see Calibration).Benefits: the smallest file and the best latency, including on convolution-heavy backbones. The default and the production path when your calibration images match your deployment distribution.Trade-off: poorly chosen images tune the model for the wrong distribution and cost accuracy. A small accuracy drop versus full precision is normal even with good calibration, so always validate.
calibration_method tunes how the activation ranges are derived from those images (minmax, percentile, or entropy). See Calibration.ptq_dynamic: no calibration data, MatMul-heavy models
ptq_dynamic: no calibration data, MatMul-heavy models
Needs: nothing extra, no calibration data.Benefits: zero setup and a smaller file. The path when you have no calibration data on hand.Trade-off: it quantizes MatMul and Gemm (fully connected) layers, so it suits transformer or MatMul-heavy models. On a convolution-heavy vision backbone it finds nothing to quantize and reports an unsupported config, so reach for
ptq_static with calibration data there.QAT
QAT is a separate paradigm, not a PTQmethod. It fine-tunes your model with quantization simulated during training, so the model learns to tolerate lower precision.
Needs: calibration/training images and a training run on GPU (epochs).
Benefits: recovers accuracy PTQ cannot, especially at low bit widths.
Trade-off: it costs a training run and needs representative images.
wbit, abit, and epochs.
Comparison
The engine automatically protects accuracy-sensitive layers, so you set the method and images and let the platform do the rest. Always benchmark on your model before shipping.

