Win10下YOLOv5 TensorRT部署：环境配置与避坑指南

简介这份资源面向希望在Windows 10平台上完成YOLOv5目标检测模型TensorRT加速部署的开发者与初学者重点解决环境搭建繁琐、依赖版本难以匹配的问题。资源以PDF文档形式整理了CUDA 10.2、cuDNN 7.6.5、VS2019、OpenCV 3.4.0、Anaconda3、CMake 3.19.4、TensorRT 7.0.0.11及YOLOv5-V4.0等全部软件与依赖库的下载信息并附有百度网盘链接与提取码下载后可直接使用。压缩包共1个文件为1个PDF整体约169KB体积轻便便于快速查阅与保存。文档内容围绕Win10系统下的部署流程展开涵盖各依赖库的作用说明、环境配置思路以及TensorRT构建优化引擎的关键环节可帮助读者理清从源码编译到推理加速的完整链路。目前已有3492人学习适合需要快速获取配套软件环境、减少版本兼容性排查时间的YOLOv5实战学习者参考使用。1. 从 PyTorch 到 TensorRT为什么 Win10 上这套 YOLOv5 部署包值得拆一遍训练完一个 YOLOv5 模型detect.py跑出来 30 FPS一上产线工控机就掉到 8 FPS这种落差做过边缘部署的人都遇到过。PyTorch 推理时大量算子没有针对具体 GPU 做融合卷积、BN、激活各走各的 kernel显存来回读写延迟自然下不来。TensorRT 干的事就是把这些算子做层融合、精度校准、kernel 自动调优同一块显卡上推理速度翻两三倍是常态。但 TensorRT 部署的麻烦从来不在原理而在环境。CUDA 10.2、cuDNN 7.6.5、TensorRT 7.0.0.11、VS2019、OpenCV 3.4.0、CMake 3.19.4这几个版本之间是强绑定的错一个就是几小时的编译报错。这份资源把 Win10 下 YOLOv5-V4.0 转 TensorRT 所需的全部软件和依赖库打包好了下载解压就能对上版本省掉的正是这段最耗人的环境对齐时间。适合手上有 N 卡、要在 Windows 上做 YOLOv5 加速推理的开发者尤其是被版本冲突卡过的人。2. 环境版本对齐CUDA 10.2 到 TensorRT 7 的依赖链怎么锁死2.1 为什么这套版本组合不能随便换TensorRT 7.0.0.11 官方只认 CUDA 10.2 和 cuDNN 7.6.x这是硬约束。你换成 CUDA 11TensorRT 7 的nvinfer.dll直接加载失败cuDNN 升到 8cudnn64_7.dll找不到编译期就断。VS2019 这边TensorRT 7 的 Windows 包只提供 MSVC 2017/2019 的 lib用 VS2022 打开工程会提示工具集不匹配。OpenCV 3.4.0 是这套包里比较老的一环但 YOLOv5 的 C 推理代码里用到的cv::Mat和dnn模块接口在 3.4 和 4.x 之间没有破坏性变更所以 3.4.0 够用且它和 CUDA 10.2 的兼容性经过验证。CMake 3.19.4 负责生成 VS2019 的.sln版本太低会不认 VS2019 的 generator。组件版本作用绑定关系CUDA Toolkit10.2GPU 计算平台TensorRT 7 强制要求cuDNN7.6.5深度神经网络加速库对应 CUDA 10.2TensorRT7.0.0.11推理优化器与运行时依赖 CUDA 10.2 cuDNN 7.6.5VS201916.xC 编译与调试提供 MSVC 工具集OpenCV3.4.0图像预处理与后处理与 CUDA 10.2 兼容CMake3.19.4构建系统生成 VS2019 工程Anaconda3任意较新版Python 环境管理跑 PyTorch 导出 ONNX2.2 安装顺序与路径规范安装顺序错了后面全是坑。正确顺序是显卡驱动 → CUDA 10.2 → cuDNN 7.6.5 → TensorRT 7.0.0.11 → VS2019 → OpenCV 3.4.0 → CMake → Anaconda3。CUDA 安装时选自定义取消 Visual Studio Integration 那一项因为 VS2019 还没装装完再手动补。cuDNN 解压后把bin、include、lib三个目录的文件分别拷进 CUDA 安装目录对应文件夹。TensorRT 同理解压后把lib下的 dll 拷到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\binlib 文件拷到lib\x64。# 验证 CUDA 安装 nvcc --version # 应输出Cuda compilation tools, release 10.2, V10.2.89 # 验证 cuDNN查看 CUDA 目录下是否存在 dir C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin\cudnn64_7.dll # 验证 TensorRT dir C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin\nvinfer.dll这三条命令是环境是否装对的第一道关卡。nvcc --version输出 10.2 说明 CUDA 本体没问题cudnn64_7.dll存在说明 cuDNN 拷贝到位nvinfer.dll存在说明 TensorRT 运行时库已就位。任何一条失败后面编译必然翻车先回头补。环境变量也要检查CUDA_PATH应指向C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2Path里要有%CUDA_PATH%\bin和%CUDA_PATH%\lib\x64。TensorRT 的 lib 路径如果没加进Path运行时会出现nvinfer.dll找不到的弹窗。3. YOLOv5 转 ONNX 再转 TensorRT模型导出与 engine 生成3.1 从 PyTorch 权重导出 ONNXTensorRT 不直接吃.pt文件中间要过一道 ONNX。YOLOv5-V4.0 的仓库里自带models/export.py但直接跑默认参数导出的 ONNX 在 TensorRT 7 上解析会报错因为 TensorRT 7 对动态 shape 的支持有限需要固定 batch 和输入尺寸。# export_onnx.py import torch from models.experimental import attempt_load # 加载 YOLOv5 权重map_location 确保在 CPU 上加载避免显存占用 model attempt_load(yolov5s.pt, map_locationtorch.device(cpu)) model.eval() # 构造固定尺寸输入batch1, 3通道, 640x640 dummy_input torch.randn(1, 3, 640, 640) # 导出 ONNXopset_version11 是 TensorRT 7 能稳定解析的版本 torch.onnx.export( model, dummy_input, yolov5s.onnx, opset_version11, input_names[images], output_names[output], dynamic_axesNone # 固定 shape不用动态轴 ) print(ONNX export done.)opset_version11是关键参数TensorRT 7 对 opset 12 以上的某些算子支持不完整用 11 最稳。dynamic_axesNone表示不做动态 batch如果产线需要变 batch得在 TensorRT 构建 engine 时用 optimization profile 单独配不能靠 ONNX 的动态轴。input_names和output_names要和后面 C 推理代码里的绑定名称一致否则getBindingIndex返回 -1。导出后用onnxsim简化一下图结构去掉冗余的 Identity 和 Constant 节点TensorRT 解析会更快pip install onnx-simplifier python -m onnxsim yolov5s.onnx yolov5s_sim.onnx3.2 用 trtexec 生成 engine 并验证TensorRT 包里自带trtexec.exe在bin目录下。它是验证 ONNX 能否被 TensorRT 正确解析的最快工具不用写一行 C。# 进入 TensorRT 的 bin 目录 cd C:\TensorRT-7.0.0.11\bin # 用 trtexec 把 ONNX 转成 engine trtexec.exe --onnxyolov5s_sim.onnx --saveEngineyolov5s.engine --fp16 --workspace2048 # 参数说明 # --onnx 输入 ONNX 模型路径 # --saveEngine 输出 engine 文件路径 # --fp16 启用 FP16 精度速度提升明显精度损失通常可接受 # --workspace 显存工作空间上限单位 MB2048 够 YOLOv5s 用跑完会输出每层的耗时和总推理时间。如果报Unsupported operation或Could not parse说明 ONNX 里有 TensorRT 7 不认的算子常见的是Resize的 coordinate_transformation_mode 参数需要在导出时改成align_cornersFalse对应的模式。engine 文件是跟 GPU 架构绑定的在 2080Ti 上生成的 engine 拿到 1080Ti 上跑不了必须重新生成。这是 TensorRT 的硬特性不是 bug。产线部署时要么在目标机器上现场生成要么确保生成和运行的 GPU 型号一致。3.3 VS2019 编译 C 推理工程拿到 engine 后用 VS2019 打开 TensorRT 自带的sampleOnnxMNIST或 YOLOv5 的 C 推理工程配置项目属性。需要改的地方集中在三处VC 目录 → 包含目录加入 CUDA 的include、TensorRT 的include、OpenCV 的includeVC 目录 → 库目录加入 CUDA 的lib\x64、TensorRT 的lib、OpenCV 的lib链接器 → 输入 → 附加依赖项加入nvinfer.lib、nvinfer_plugin.lib、nvonnxparser.lib、cudart.lib、opencv_world340.lib// 推理核心片段加载 engine 并创建执行上下文 #include NvInfer.h #include NvOnnxParser.h // 创建 loggerTensorRT 所有日志都走这个接口 class Logger : public nvinfer1::ILogger { void log(Severity severity, const char* msg) noexcept override { if (severity ! Severity::kINFO) std::cout msg std::endl; } } gLogger; // 从文件读取 engine 并反序列化 std::ifstream engineFile(yolov5s.engine, std::ios::binary); engineFile.seekg(0, std::ios::end); size_t size engineFile.tellg(); engineFile.seekg(0, std::ios::beg); std::vectorchar buffer(size); engineFile.read(buffer.data(), size); nvinfer1::IRuntime* runtime nvinfer1::createInferRuntime(gLogger); nvinfer1::ICudaEngine* engine runtime-deserializeCudaEngine(buffer.data(), size, nullptr); nvinfer1::IExecutionContext* context engine-createExecutionContext();deserializeCudaEngine把 engine 文件加载成可执行的 CUDA 引擎createExecutionContext创建推理上下文。一个 engine 可以创建多个 context 做并发推理但每个 context 占一份显存。Logger里过滤掉kINFO级别日志否则 TensorRT 会刷屏。推理时的显存分配用cudaMalloc给输入输出各开一块context-enqueue异步执行cudaMemcpyAsync做主机和设备间拷贝。YOLOv5 的输出是三个尺度的特征图后处理需要做 decode 和 NMS这部分在 CPU 上做还是 GPU 上做直接影响端到端延迟。4. 部署避坑从 dll 缺失到 engine 不匹配的排查记录4.1 现象编译通过但运行时报 nvinfer.dll 找不到原因TensorRT 的 dll 没有拷到 CUDA 的 bin 目录或者Path环境变量里没有 TensorRT 的 lib 路径。VS2019 编译时链接的是.lib导入库运行时才去加载.dll两者路径不一致就报错。解决把TensorRT\lib下的所有 dll 拷到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin重启命令行让Path生效。或者直接在系统环境变量Path里追加 TensorRT 的 lib 路径。4.2 现象trtexec 解析 ONNX 报 Unsupported operation: Resize原因YOLOv5 的export.py默认导出的 ONNX 里上采样用的Resize节点带了coordinate_transformation_modehalf_pixelTensorRT 7 只认asymmetric和align_corners。解决在导出脚本里把torch.onnx.export的opset_version设为 11并在模型定义里把nn.Upsample的align_corners显式设为False。如果还报错用onnxsim简化后再试简化过程会重写部分节点属性。4.3 现象engine 在开发机上正常拷到工控机上反序列化失败原因engine 文件绑定了生成时的 GPU 架构和 TensorRT 版本。开发机是 RTX 2080图灵架构工控机是 GTX 1050Ti帕斯卡架构SM 版本不同engine 里的 kernel 无法执行。解决在工控机上重新跑trtexec生成 engine。如果工控机没有完整的 TensorRT 环境至少要把trtexec.exe和依赖的 dll 拷过去用--saveEngine现场生成。4.4 现象FP16 模式下检测框偏移mAP 掉点原因FP16 精度下YOLOv5 的 decode 部分涉及大量小数值运算半精度浮点的表示范围不够导致框坐标回归偏差。解决把 decode 和 NMS 部分留在 FP32 做只对 backbone 和 neck 做 FP16 量化。在 TensorRT 里可以通过setLayerPrecision对特定层强制 FP32或者在导出 ONNX 时把 decode 部分单独拆出来用 CPU 实现。4.5 现象VS2019 编译报 MSB8020 工具集不匹配原因工程文件是用 VS2017 的工具集创建的本机只装了 VS2019 的 v142 工具集。解决右键项目 → 属性 → 常规 → 平台工具集改成Visual Studio 2019 (v142)。如果下拉框里没有说明 VS2019 安装时没勾 C 桌面开发工作负载用 Visual Studio Installer 补上。5. 进阶技巧用 Python 脚本批量生成 engine 并做多模型对比环境跑通之后真正提效的是把重复劳动脚本化。我一般会写一个 Python 脚本遍历models目录下所有.onnx文件自动调trtexec生成 engine并记录每个模型的推理耗时和显存占用方便选型。# build_engines.py import subprocess import os import time TRTEXEC rC:\TensorRT-7.0.0.11\bin\trtexec.exe ONNX_DIR ./onnx_models ENGINE_DIR ./engines os.makedirs(ENGINE_DIR, exist_okTrue) # 遍历所有 onnx 文件逐个生成 engine for onnx_file in os.listdir(ONNX_DIR): if not onnx_file.endswith(.onnx): continue name os.path.splitext(onnx_file)[0] onnx_path os.path.join(ONNX_DIR, onnx_file) engine_path os.path.join(ENGINE_DIR, f{name}.engine) # 跳过已生成的 engine避免重复耗时 if os.path.exists(engine_path): print(fskip {name}, engine exists) continue cmd [ TRTEXEC, f--onnx{onnx_path}, f--saveEngine{engine_path}, --fp16, --workspace2048, --iterations100, # 跑100次取平均减少抖动 --avgRuns10 # 前10次作为预热不计入 ] print(fbuilding {name} ...) start time.time() result subprocess.run(cmd, capture_outputTrue, textTrue) elapsed time.time() - start if result.returncode ! 0: print(fFAILED {name}: {result.stderr[-500:]}) else: print(fOK {name}, build time {elapsed:.1f}s)--iterations100和--avgRuns10是让 trtexec 跑够次数取稳定值单次跑受 GPU 调度影响波动大。subprocess.run捕获 stderr失败时只打印最后 500 字符避免日志刷屏。这个脚本在换模型做对比时特别省事扔一批 ONNX 进去出来就是一组 engine 和耗时数据。验证 engine 是否真的加速了不能只看 trtexec 的输出要在实际推理代码里用std::chrono打点。我习惯在enqueue前后各记一次时间跑 100 帧取平均和 PyTorch 的time.time()结果对比。同一张 1080Ti 上YOLOv5s 640 分辨率PyTorch FP32 大约 25msTensorRT FP16 能压到 8ms 左右差距主要来自层融合和 FP16 的吞吐优势。还有一个容易忽略的点engine 文件不要提交到 Git。它跟 GPU 绑定换机器就失效而且动辄几十上百 MB。正确做法是把 ONNX 和生成脚本一起管理engine 在部署时现场生成。从那以后我每次换部署机器第一件事就是重新跑一遍build_engines.py确认 engine 是在目标 GPU 上生成的再往下做性能测试。希望帮到你。本文还有配套的精品资源点击获取