TensorRT转换失败主因是ONNX导出时数据类型不匹配或dynamic_axes未设，需强制float32、opset_version=11；trtexec推理异常多因精度设置、GPU环境或shape绑定错误；engine文件不跨版本兼容，须同版本构建。
TensorRT 转换失败：报错 AssertionError: Unsupported data type 怎么办
常见于 PyTorch 模型导出为 ONNX 时未显式指定输入输出张量的 dynamic_axes 或数据类型不匹配。TensorRT 对 ONNX 的算子支持严格，尤其对 torch.float64、torch.int64 输入直接拒绝。
- 导出 ONNX 前务必用
.to(torch.float32)强制转换模型和 dummy input，避免残留float64 -
torch.onnx.export中必须设opset_version=11（最低兼容 TensorRT 7.2），更高版本（如 17）可能引入不支持的算子 - 若模型含自定义 op 或 control flow（如
if/for），优先用torch.jit.trace导出 TorchScript，再用trtexec --onnx=...转换会失败
trtexec 转换成功但推理结果全零或 NaN
不是模型没加载，而是 TensorRT 默认启用精度校准（int8）或内存绑定异常。尤其在无 GPU 上运行 trtexec 时，它仍会尝试分配显存，但失败后不报错，只静默返回无效 buffer。
- 先加
--fp16或--fp32显式指定精度，禁用自动 int8 校准（除非你真有校准集） - 确认
trtexec运行在有 GPU 的环境：nvidia-smi可见设备，且 CUDA_VISIBLE_DEVICES 正确设置 - 用
--verbose查看实际绑定的输入 shape 是否与模型期望一致；常见坑是 ONNX 中 shape 为-1，但trtexec默认用1推理，导致 reshape 错误
Python 中加载 .engine 文件后 context.execute_v2() 返回 False
这表示推理执行失败，但错误不抛出异常，需主动查 context.get_error_recorder()。最常踩的坑是输入/输出 buffer 地址没按要求对齐，或 tensor 绑定顺序与 engine 内部 binding index 不一致。
- 务必用
engine.get_binding_shape(i)动态读取每个 binding 的 shape，别硬编码；尤其 output binding 的 batch 维可能被折叠 - host buffer 必须用
numpy.ascontiguousarray(..., dtype=np.float32)创建，且 device buffer 用cuda.mem_alloc()分配后，再用cuda.memcpy_htod()同步 - 调用
execute_v2()前，确保传入的bindingslist 是纯 Python list（非 tuple 或 np.array），且索引 0 是 input，1 是 output
TensorRT 8.6+ 加载旧版 .engine 报错 Invalid engine file format
engine 文件不跨版本兼容。TensorRT 生成的 engine 本质是序列化后的 runtime 状态，包含 CUDA kernel 编译产物，升级主版本后 ABI 变更，旧 engine 直接失效。
立即学习“Python免费学习笔记（深入）”；
- 不要试图“升级”老 engine 文件——必须用当前 TensorRT 版本重新跑
trtexec或 Python API 构建 - 若部署环境无法重装 TensorRT（如 JetPack 5.1 固定 TRT 8.4），开发机也得降级到同版本构建，否则现场 load 失败
- 建议把
build_engine()流程固化进 CI，每次模型变更都生成对应版本的 engine，避免手动操作遗漏
真正卡住人的从来不是转换命令本身，而是 ONNX 的隐式行为、TensorRT 对硬件状态的强依赖、以及 engine 文件那毫不留情的版本锁死——这些地方一错，连日志都不会多给你一行。
