TensorRT 8.4+ 动态加载 ONNX 并启用 FP16 推理需满足：显式 batch 模式、手动设置输入输出为 half、完整配置 dynamic shape 的 min/opt/max 三元组且 H/W 为 32 倍数，优先用 trtexec 快速验证。
直接用 nvonnxparser::IParser 解析 ONNX 文件、配 BuilderFlag::kFP16、走 buildEngineWithConfig 流程，就能完成动态加载 + FP16 推理——但实际卡住你的几乎从来不是“能不能做”，而是“为什么解析失败”“为什么推理输出全零”“为什么 FP16 结果和 PyTorch 对不上”。
ONNX 解析失败：常见错误和显式 batch 必须开
TensorRT 8.4+ 要求网络定义必须启用显式 batch 模式，否则 parser->parseFromFile() 会静默失败（返回 false），且不报具体算子错误。很多 ONNX 模型（尤其是 YOLOv8/v11 导出的）默认是隐式 batch，解析后 network->getNbLayers() 可能为 0。
- 创建 network 时必须传入
1U (nvinfer1::NetworkDefinitionCreationFlag::kEXPLICIT_BATCH)，不能传0 - 检查 parser 日志级别：把
ILogger::Severity::kWARNING改成kINFO或kVERBOSE，能看到具体哪一层/哪个算子不支持（比如Resize的 coordinate_transformation_mode 不兼容） - YOLOv8 导出 ONNX 时务必加
dynamic=True，否则输入 shape 固定，后续无法适配不同分辨率视频流
FP16 推理结果异常：精度对齐的关键三步
FP16 不是简单加个 flag 就完事。YOLO 类模型输出坐标和置信度对数值敏感，开 FP16 后常见现象是 NMS 前 scores 全为 0 或 bbox 坐标溢出，本质是 pre-process 和 post-process 没同步降精度。
-
config->setFlag(nvinfer1::BuilderFlag::kFP16)只影响网络内部计算，输入/输出 tensor 仍默认是 FP32；必须手动调用engine->getBindingDataType(bindingIndex)确认 input binding 是nvinfer1::DataType::kHALF - 预处理输出要转
half：用__half* h_input = static_cast<__half>(buffers[inputIndex])</__half>，再用__hadd/__hmul或cudaMemcpyAsync(..., cudaMemcpyHostToDevice)传入，别用float*强转 - 后处理前必须把输出 buffer 从
__half转回float：用__half2float()逐元素转换，尤其注意 YOLO 的preds输出是[batch, num_boxes, 4+nc]，漏转某维会导致解码错乱
动态 shape 支持：optShapes 和 profile 必须配对设
只设 --optShapes=input:1x3x640x640 或只调 config->setOptimizationProfile(config->createOptimizationProfile()) 都不行。TensorRT 要求 profile 的 min/opt/max 三个 shape 全部显式指定，否则构建 engine 会失败或运行时报 Invalid value for shape dimension。
立即学习“C++免费学习笔记（深入）”；
- 先调
IExprBuilder构造 dynamic shape：例如 YOLOv8 输入名通常是"images"，需确保 ONNX 中该 input 的 shape 是[batch, 3, -1, -1]（非[1,3,640,640]） - 创建 profile 后，必须调三次
setDimensions("images", OptProfileSelector::kMIN, Dims4{1,3,320,320})、kOPT、kMAX，且 H/W 必须是 32 的倍数（如 320/640/1280），否则 runtime 报错 - 验证是否生效：构建后用
engine->getProfileNumber()应 ≥1，且context->setBindingDimensions(0, Dims4{4,3,640,640})调用不崩溃
trtexec 工具链调试比手写 C++ 更快定位问题
别一上来就写几百行 C++ 加载逻辑。用 trtexec 快速验证 ONNX 是否可被 TensorRT 消化、FP16 是否真起效、动态 shape 是否被接受——它暴露的错误信息比 API 更直白。
- 基础验证命令：
trtexec --onnx=model.onnx --fp16 --workspace=2048 --minShapes=images:1x3x320x320 --optShapes=images:4x3x640x640 --maxShapes=images:8x3x1280x1280 - 加
--dumpProfile查看各 layer 的 FP16/FP32 混合情况；加--separateProfile输出 per-layer timing，确认 bottleneck 是在 pre-process 还是 kernel - 如果
trtexec成功但你自己的 C++ 代码失败，90% 是IBuilderConfig缺少setMaxWorkspaceSize()或没设setMemoryPoolLimit(nvinfer1::MemoryPoolType::kWORKSPACE, 1
真正难的不是调通一个固定分辨率的单图推理，而是让同一份 engine 在 batch=1（单路低延迟）和 batch=8（多路高吞吐）下都稳定输出正确框。这时候 profile 切换、CUDA stream 绑定、host/device memory pinned 分配，一个没对齐，FPS 就掉一半——这些细节不会出现在任何 “Hello World” 示例里，但每一条都决定你能不能把模型真正交到运维手上。
