必须调用torch.quantization.convert才能保存真正量化模型，否则加载报AttributeError；TensorRT仅支持ONNX导出的静态量化，需prepare→校准→convert流程，且ONNX须用opset=12。
量化后模型加载报 AttributeError: 'NoneType' object has no attribute 'data'
这是 PyTorch 量化模型保存/加载不匹配的典型症状。核心原因：没调用 torch.quantization.convert 就直接保存了伪量化模型（qconfig 设了但没真正转换权重）。
- 训练后必须显式调用
torch.quantization.convert(model)，否则model.state_dict()里还是 float 权重 + 一堆 observer，不是真正的 int8 张量 - 保存前检查：打印
next(model.parameters()).dtype，量化后应为torch.qint8，不是torch.float32 - 加载时别用
torch.load(..., map_location=...)直接覆盖模型参数，要先实例化结构，再用load_state_dict()
TensorRT 加速时 torch.quantization.quantize_dynamic 不起作用
动态量化（quantize_dynamic）生成的是 CPU 友好型模型，TensorRT 根本不认——它只吃 ONNX 导出后的静态量化图，且要求量化参数已固化。
- 给 TensorRT 用，必须走
torch.quantization.prepare→ 校准（跑几 batch 数据触发 observer）→torch.quantization.convert这条静态量化路径 - 校准数据不能太少，至少 100–200 张图，否则
observer统计的 min/max 偏差大，推理时容易溢出或精度崩塌 - 导出 ONNX 前，确保模型已
eval()，且所有torch.nn.quantized模块都就位，否则 ONNX exporter 会报Unsupported value type
量化后推理变慢，torch.backends.quantized.engine = 'fbgemm' 没生效
Linux 下默认引擎是 fbgemm，但 macOS 和 Windows 默认是 qnnpack，后者在小 batch 场景下反而更慢；另外，没关掉梯度和启用 inference mode 也会拖累速度。
- 显式设置引擎：运行前加
torch.backends.quantized.engine = 'fbgemm'（Linux）或'qnnpack'（移动端），设完立刻验证torch.backends.quantized.engine - 推理前务必调用
model.eval()，并用torch.no_grad()包裹前向，否则 quantized 模块内部仍会做冗余检查 - batch size 太小（如 1）时，fbgemm 的调度开销可能超过收益，建议实测
batch_size=4/8/16的 latency 曲线，别默认认为越小越好
ONNX 导出后 TensorRT 构建失败，报错含 Unsupported operator QuantizeLinear
这是 ONNX opset 版本和 TensorRT 支持范围不一致导致的。PyTorch 默认导出 opset=13，但 TRT 8.6 及以下只完全支持到 opset=12，且对 QuantizeLinear/DequantizeLinear 的 schema 要求严格。
- 导出 ONNX 时强制指定
opset_version=12，并设do_constant_folding=True，减少中间节点 - 避免用
torch.quantization.quantize_jit，它导出的 ONNX 常含自定义算子；优先用torch.quantization.convert+torch.onnx.export - TRT 解析前，先用
onnx.shape_inference.infer_shapes补全 shape 信息，否则某些量化节点因 shape unknown 被跳过校验
量化不是“设个 qconfig 就完事”的开关操作，真正的瓶颈常卡在校准数据分布是否贴近线上真实输入、ONNX 节点是否被 TRT 完整支持、以及引擎后端有没有真正跑进硬件加速路径里——这些地方一漏，模型体积小了，速度反而更慢。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
