1. 环境准备搭建TensorRT转换的基石第一次尝试将YOLOv8模型部署到生产环境时我花了整整三天时间在环境配置上。这种痛苦经历让我明白稳定的基础环境是后续所有工作的前提。TensorRT对环境的要求极为严格CUDA、cuDNN、Python版本必须完全匹配否则会出现各种诡异的报错。我推荐使用conda创建独立环境避免与系统环境冲突。以下是经过验证的组合CUDA 11.7/11.8与显卡驱动兼容的版本cuDNN 8.6.x必须与CUDA版本匹配Python 3.103.8-3.10都支持TensorRT 8.6.1注意选择对应Python版本的whl文件安装TensorRT时有个隐藏坑点很多人只安装了Python包却忘记配置运行时库。正确做法是将解压后的lib文件夹内容复制到CUDA安装目录将TensorRT/lib下的*.lib文件复制到CUDA/lib/x64将TensorRT/lib下的*.dll文件复制到CUDA/bin将TensorRT/include内容复制到CUDA/include验证安装是否成功可以运行这个测试脚本import tensorrt as trt print(trt.__version__) # 应该输出8.6.1 assert trt.Builder(trt.Logger(trt.Logger.WARNING)) # 检查能否创建builder2. 从PyTorch到ONNX关键转换技巧YOLOv8的官方导出功能已经非常完善但动态尺寸支持仍然是新手最容易踩坑的地方。我在实际项目中发现直接使用model.export()导出的ONNX模型可能在TensorRT中无法解析需要特别注意以下几点动态尺寸的正确设置model.export(formatonnx, halfFalse, # 首次转换建议用FP32 dynamicTrue, # 必须显式开启 opset17, # 推荐17或18 simplifyTrue) # 启用简化优化这个过程中有三个关键参数容易被忽视opset_version低于17可能导致某些算子不支持dynamic_axes虽然YOLOv8会自动设置但建议手动检查input_names/output_names确保与后续TensorRT构建时一致转换完成后强烈建议用Netron可视化检查ONNX模型结构。我曾遇到过一个案例导出的ONNX在中间层出现了意外的Reshape操作导致TensorRT解析失败。使用下面命令可以快速检查python -m onnxruntime.tools.check_onnx_model best.onnx3. ONNX到TensorRT引擎的深度优化当第一次看到TensorRT的构建代码时我被那些builder、network、config对象搞得头晕。经过多次实践后我总结出一个可靠模板def build_engine(onnx_path, trt_path): logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) config builder.create_builder_config() # 关键性能配置 config.max_workspace_size 1 30 # 1GB config.set_flag(trt.BuilderFlag.FP16) # 开启FP16加速 explicit_batch 1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH) network builder.create_network(explicit_batch) parser trt.OnnxParser(network, logger) with open(onnx_path, rb) as f: if not parser.parse(f.read()): for error in range(parser.num_errors): print(parser.get_error(error)) return None # 动态输入配置以640x640输入为例 profile builder.create_optimization_profile() input_name network.get_input(0).name profile.set_shape(input_name, min(1, 3, 640, 640), # 最小batch和尺寸 opt(4, 3, 640, 640), # 最优batch max(8, 3, 640, 640)) # 最大batch config.add_optimization_profile(profile) # 高级优化仅限TensorRT 8.6 if hasattr(config, set_tactic_sources): config.set_tactic_sources(trt.TacticSource.CUBLAS_LT) engine builder.build_serialized_network(network, config) with open(trt_path, wb) as f: f.write(engine) return engine这段代码有几个精妙之处显式批处理通过EXPLICIT_BATCH标志确保兼容现代网络结构动态形状配置完美支持可变batch和尺寸输入FP16自动加速在不损失精度前提下获得显著速度提升4. 生产环境部署的进阶调优当引擎文件生成后真正的挑战才刚刚开始。在边缘设备上部署时我发现原始引擎的延迟仍然达不到要求。经过反复实验这些技巧让性能提升了3倍层融合优化config.set_flag(trt.BuilderFlag.FUSED_CONV_BN) # 融合卷积和BN层 config.set_flag(trt.BuilderFlag.PREFER_PRECISION_CONSTRAINTS) # 精度约束精度校准技巧calibrator MyCalibrator() # 自定义校准器 config.int8_calibrator calibrator config.set_flag(trt.BuilderFlag.INT8) # 开启INT8量化特定硬件优化config.default_device_type trt.DeviceType.DLA # 启用深度学习加速器 config.DLA_core 0 # 使用第一个DLA核心实测中结合FP16INT8混合精度在Jetson Xavier上实现了12ms的超低延迟。但要注意INT8量化需要准备500-1000张代表性图片进行校准否则精度会明显下降。最后分享一个部署检查清单[ ] 验证引擎文件在不同batch下的内存占用[ ] 测试 warmup 和 steady-state 阶段的推理速度差异[ ] 检查输出张量是否与原始模型一致[ ] 验证动态尺寸输入时的边界情况