PyTorch原生推理延迟高的根本原因是Python调度开销、动态图执行、算子未融合及内存频繁分配；TensorRT优化需严格配合模型转换、FP16/INT8校准和ONNX规范化，缺一不可。
PyTorch 原生推理延迟高，根本原因不是 GPU 不够快，而是 Python 层调度开销、动态图执行、算子未融合、内存反复分配这些“软件栈冗余”在拖后腿。TensorRT 的量化加速不是简单调个 fp16_enable=True 就完事——它必须配合模型表示转换、精度校准链路和引擎序列化，否则容易白忙活。
PyTorch 推理慢的底层原因在哪
你看到的“几百毫秒”，往往不是计算本身慢，而是框架在做一堆与推理无关的事：
- 每次
model(input)都重建计算图，无法复用编译结果 - Conv + BN + ReLU 这类常见组合没被合并，导致三次显存读写+三次 kernel launch
- Python GIL 锁住主线程，GPU 等 CPU 调度，空转率高
- tensor 在 CPU/GPU 间隐式拷贝（比如输入是 numpy，输出要转回 numpy）
这些问题在 TensorRT 中被逐层剥离：图被静态化、算子被融合、内存被预分配、Python 只负责喂数据和取结果。
FP16 量化不是开关，而是三步闭环
直接设 config.set_flag(trt.BuilderFlag.FP16) 可能没效果，甚至报错。FP16 加速依赖三个前提同时成立：
立即学习“Python免费学习笔记（深入）”；
- 模型权重和激活值必须支持半精度计算（ResNet/YOLO 类 CNN 通常没问题，含大量除法或自定义 op 的模型可能 fallback 到 FP32）
- GPU 架构需支持原生 FP16（Turing/Ampere 及更新显卡 OK；Pascal 不行）
- ONNX 导出时不能丢精度信息：
torch.onnx.export(..., opset_version=13, keep_initializers_as_inputs=True)
验证是否真走 FP16：用 trtexec --onnx=model.onnx --fp16 --verbose 查日志，搜索 Selected precision: fp16 和 Fused activation 行。
INT8 校准必须用真实数据，不能用 dummy
想压到最低延迟？INT8 是必选项，但它不接受“模拟数据”。以下操作极易翻车：
- 用
torch.randn()生成校准集 → 激活值分布完全失真，量化后精度崩塌 - 只校准 10 张图 → 统计不充分，
trt.IInt8Calibrator生成的 scale 偏差大 - 校准后不验证输出分布 → 某些 layer 的 INT8 输出全为 0 或饱和，后续层直接失效
正确做法：取 500–1000 张**真实业务场景下的输入样本**（如检测任务就用实际摄像头截图），喂给校准器；再用少量验证集比对 TensorRT INT8 和 PyTorch FP32 的 top-1 输出差异，误差 >3% 就得换校准策略或加样本。
ONNX 不是中转站，而是精度守门员
很多团队导出 ONNX 后直接喂给 TensorRT，结果加速不如预期——问题常出在 ONNX 本身。
- PyTorch 导出默认用
opset_version=11，但 TensorRT 8.6+ 推荐opset_version=13（支持 dynamic axes 更稳） - 导出时漏掉
dynamic_axes参数 → 引擎只能跑固定 shape，一换分辨率就 crash - 没跑
onnx-simplifier→ ONNX 里残留Identity、Unsqueeze等冗余节点，TensorRT 无法融合关键路径
安全导出示例：
torch.onnx.export(model, dummy_input, "model.onnx",
input_names=["input"],
output_names=["output"],
dynamic_axes={"input": {0: "batch", 2: "height", 3: "width"},
"output": {0: "batch"}},
opset_version=13,
do_constant_folding=True)导出后立刻执行：onnxsim model.onnx model_sim.onnx。
真正卡住落地的，从来不是“会不会加 FP16”，而是 ONNX 是否干净、校准数据是否真实、动态 shape 边界是否对齐——这三处任意一个出问题，量化后的引擎要么跑不起来，要么快但不准。
