PyTorch模型必须先导出为ONNX再交由TensorRT解析，因TensorRT不支持直接读取torch.nn.Module或.pt文件；ONNX提供跨框架中间表示，保留算子语义、shape及动态轴信息，是TRT优化前提。
PyTorch 模型不能直接喂给 TensorRT；必须先导出为 ONNX，再经 TensorRT 解析构建引擎——跳过 ONNX 这步会直接报错 AssertionError: Unsupported input type 或静默失败。
为什么必须走 ONNX 中转？
TensorRT 不原生解析 PyTorch 的 torch.nn.Module 或 .pt 权重文件。它只接受明确的计算图定义（ONNX）或自定义网络描述（C++ API）。ONNX 提供了跨框架的中间表示，能保留算子语义、输入输出 shape 和动态轴信息——这是后续优化的前提。
常见误区：
- 直接用
torch.jit.trace导出的.pt文件传给trt.Builder→ 报错Invalid model format - 未固定输入 shape 或未标注 dynamic axes → TensorRT 构建时卡在
builder.build_engine(network, config)无提示 - ONNX opset 版本过高（如 opset=18），而 TensorRT 8.x 仅支持到 opset=17 → 解析失败，日志里出现
Unsupported operator 'Cast' with domain ''
导出 ONNX 时的关键参数控制
导出质量直接决定 TensorRT 能否成功构建及推理性能。重点不是“能导出”，而是“导出得对”：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
input_names和output_names必须显式指定，否则 TensorRT 无法绑定 I/O tensor - 若模型含动态 batch 或 resolution（如检测/分割），需用
dynamic_axes明确声明，例如：{"input": {0: "batch", 2: "height", 3: "width"}} - 务必设
opset_version=11（TRT 7.2+ 稳定支持）或opset_version=17（TRT 8.6+），避免高版本 op 导致解析中断 - 测试导出后用
onnx.checker.check_model(model)验证结构合法性，再用onnx.shape_inference.infer_shapes(model)补全缺失 shape
构建 TensorRT 引擎的最小可靠流程
绕过 Python API 的封装陷阱（如 trt.OnnxParser 不报详细错误），用最简路径验证流程：
- 用
trt.Logger(trt.Logger.WARNING)启动 logger，避免关键警告被吞掉 - 创建 builder → config → network 后，必须调用
parser.parse(model_bytes)并检查返回值：if not parser.parse(...): raise RuntimeError("ONNX parse failed") - 设置
config.max_workspace_size = 1 （1GB），太小会导致某些层（如 ConvTranspose）构建失败 - 启用 FP16 前先确认 GPU 支持：
if builder.platform_has_fast_fp16: config.set_flag(trt.BuilderFlag.FP16)，否则强制启用会静默回退但性能不增 - 构建完成后，用
engine.serialize()保存为.plan文件，别依赖内存对象长期存活
加载引擎推理时的隐性约束
生成的 .plan 文件与构建环境强绑定：CUDA 版本、TensorRT 版本、GPU 架构（如 sm_75 vs sm_86）不一致就会 deserialize_cuda_engine 失败，错误信息常是模糊的 Invalid engine。
实际部署中容易忽略的点：
- Python 加载引擎必须用和构建时**完全相同版本**的
tensorrt包（pip show nvidia-tensorrt核对Version字段） - 输入 tensor 必须是 GPU 上的
torch.cuda.FloatTensor或np.ndarray+cuda.mem_alloc分配，CPU tensor 直接传入会卡死或 segfault - 每次推理前需调用
context.execute_v2(bindings)，其中bindings是按engine.get_binding_index(name)排序的地址列表，顺序错一位就输出乱码 - TRT 引擎不管理内存生命周期，
cuda.mem_alloc分配的 buffer 必须在进程退出前手动free，否则反复加载会 OOM
真正卡住人的往往不是语法，而是 ONNX shape 推断失败、TRT 构建时的 silent fallback、或者 plan 文件跨环境失效——建议每次变更都用 trtexec --onnx=model.onnx --saveEngine=model.plan --verbose 独立验证，比纯 Python 脚本更容易定位问题源头。
