必须显式指定input_names、output_names和dynamic_axes，固定opset_version为11或17，启用do_constant_folding=True，并确保dummy_input在GPU上且ONNX经checker验证与shape推断。
PyTorch模型不能直接喂给TensorRT——跳过ONNX这步会直接报错AssertionError: Unsupported input type，或静默失败。必须走torch.onnx.export → trt.OnnxParser → builder.build_engine这条链路，否则整个流程卡在第一步。
torch.onnx.export导出时必设的参数有哪些？
导出质量决定后续能否成功构建引擎。不是“能跑通”，而是“导出得对”：
-
input_names和output_names必须显式指定，否则trt.IExecutionContext绑定I/O tensor时找不到对应名，报get_tensor_name() returned None - 若模型支持动态batch（如检测/分割），必须用
dynamic_axes声明，例如{"input": {0: "batch"}, "output": {0: "batch"}}；漏掉会导致builder.build_engine(network, config)卡住无提示 -
opset_version建议固定为11（TRT 7.2+稳定）或17（TRT 8.6+支持），避免用18——TRT 8.x解析时会报Unsupported operator 'Cast' with domain '' - 务必加
do_constant_folding=True，否则BN层未折叠、残差连接中常量未内联，TRT可能无法融合层，性能损失明显
ONNX转TensorRT引擎时最常卡在哪？
不是报错，而是build过程卡死或返回None，根本原因往往藏在前期准备里：
- ONNX文件本身不合法：用
onnx.checker.check_model(model)验证，再用onnx.shape_inference.infer_shapes(model)补全shape；缺shape信息时TRT parser直接跳过某些节点 - 输入tensor未预分配GPU内存：
dummy_input = torch.randn(...).cuda()必须在导出前就上GPU，否则ONNX中shape可能含-1或unk__1，TRT拒绝解析 - builder配置遗漏
max_workspace_size：即使只做FP32推理，也需设至少1 （1GB），否则<code>build_engine返回None且无日志 - 未调用
parser.parse()成功就进build_engine：应检查parser.parse(model_bytes)返回值，False时立刻打印parser.get_error(0)查具体算子问题
为什么FP16/INT8量化后结果错得离谱？
精度崩塌通常不是量化本身的问题，而是校准和输入预处理没对齐：
立即学习“Python免费学习笔记（深入）”；
- FP16启用但未设
config.set_flag(trt.BuilderFlag.FP16)，或GPU不支持（如GTX系列无FP16 Tensor Core），实际仍走FP32路径却误以为加速了 - INT8校准用的dataset必须和线上推理时的输入分布一致：若训练时归一化是
(x - 0.5) / 0.5，校准数据也必须走同一套变换，否则IInt8Calibrator统计的range完全失效 - TRT默认禁用dla_core，但某些INT8 kernel只在DLA上可用；若强制用GPU执行，会fallback到低效实现甚至报错
Cannot find kernel for node - 输出tensor未同步：调用
context.execute_v2()后，必须cuda.Stream.synchronize()，否则读到的是旧内存值，看起来像“随机错误”
最容易被忽略的是ONNX导出时的training=False和do_constant_folding=True组合——如果模型里有nn.Dropout或nn.BatchNorm2d且没调model.eval()，导出图会保留训练态分支，TRT构建时虽不报错，但推理结果随batch size变化而抖动，极难定位。
