尧图网站建设 
简介针对在Windows 10系统下使用TensorRT加速YOLOv5目标检测的部署需求这份PDF文档提供了完整的软件依赖清单与现成下载入口面向想要快速完成环境搭建的开发者或入门者免去逐个查找安装包、反复匹配版本以及处理依赖冲突的困扰。包内为单个PDF文档大小仅169KB却浓缩了十多个关键组件的下载与配置信息包括CUDA 10.2、cuDNN 7.6.5、Visual Studio 2019、OpenCV 3.4.0、Anaconda3、CMake 3.19.4、TensorRT 7.0.0.11及YOLOv5 V4.0等并附带已经预配置好的百度网盘链接下载后可直接按说明使用。目前已有三千四百九十二人学习浏览对于希望将YOLOv5模型在英伟达显卡上加速推理的读者来说文档中的版本选型、安装顺序梳理和常见配置要点能够明显降低踩坑概率。阅读这份说明还能理解各个依赖库在部署链路中的具体作用比如CUDA提供GPU计算平台cuDNN加速卷积网络Visual Studio用于编译工程CMake负责构建配置TensorRT则把模型转换成优化的执行引擎最终帮助读者完成从源码构建到引擎生成的完整过程实现更低延迟的实时物体检测。1. TensorRT 部署 YOLOv5为什么说环境版本匹配比算法本身更磨人在 Windows 上把 YOLOv5 跑起来不算难真正让人原地放弃的是把 TensorRT 接进工程的那一步。手头这份资源是 Win10 CUDA 10.2 cuDNN 7.6.5 VS2019 OpenCV 3.4.0 Anaconda3 CMake 3.19.4 TensorRT 7.0.0.11 的全套预配置环境打包配合 CSDN 那篇《Win10—YOLOv5 实战TensorRT 部署VS2019 编译(小白教程~易懂易上手)》使用。它的核心价值在于所有软件依赖都修改配置完毕下载解压就能直接进入编译和部署流程而不是像裸装那样在版本冲突里折腾两三天。适合新手第一次在 Win10 上体验 TensorRT 加速也适合熟手想快速拿到一套已验证可用的工程环境跳过环境地狱直接验证自己的推理代码。先说结论这套组合里最磨人的不是 YOLOv5 本身而是 TensorRT 7 和 CUDA 10.2 之间苛刻的版本对应关系版本错一个位编译期和运行期都会给你颜色看。2. 版本选型逻辑为什么是 CUDA 10.2 TensorRT 7.0.0.112.1 TensorRT 与 CUDA 的版本绑定关系TensorRT 对 CUDA 版本的依赖极其敏感不是随便拿个新版本就能搭配。TensorRT 7.0.0.11 官方支持的是 CUDA 10.2 和 cuDNN 7.6.5这个组合在 2020 年到 2021 年之间是 NVIDIA 官方验证过的稳定配对。如果你换成 CUDA 11.xTensorRT 7 的库文件在链接阶段就会报一堆找不到符号的错误即使能编译通过运行时也会出现CudaRuntime版本不匹配的异常。常见做法是先确认显卡的算力。TensorRT 7 对 Turing 架构RTX 20 系和 Ampere 架构RTX 30 系都有支持但 Ampere 在 CUDA 10.2 下需要 460 以上的驱动版本。你装驱动的时候注意别用太老的版本否则 TensorRT 初始化会报CUDA driver version is insufficient for CUDA runtime version。我一般装机前先跑一次nvidia-smi看驱动版本再决定要不要升级 NVIDIA 驱动。2.2 VS2019 与 CMake 的编译器匹配VS2019 对应的 MSVC 工具集是 v142CMake 3.19.4 对 VS2019 的生成器支持得很好。选 CMake 3.19.4 而不是更新的版本是为了避开新版本 CMake 对旧版 CUDA 探测方式的改变。CMake 从 3.20 开始对 CUDA 语言支持做了调整探测 CUDA 10.2 的方式不再兼容导致配置阶段直接失败。这是一个很隐蔽的坑很多人卡在这里以为是 CUDA 装坏了其实是 CMake 版本太新。OpenCV 3.4.0 的选择也值得说一句。YOLOv5 的后处理对 OpenCV 的依赖主要在图像读取和画框这些基础功能上3.4.x 完全够用而且预编译的 Windows 包在 VS2019 下链接稳定。不要换成 OpenCV 4.x原因在于 4.x 对cv::dnn模块的默认行为有改动如果你顺着老教程走部分 API 调用会报找不到符号。2.3 这份资源包帮你省掉了哪些配置步骤全套软件环境已经配置修改好下载即可使用——这句话的实际含义是环境变量已经加好TensorRT-7.0.0.11的lib目录已经加入PATHCMake 的CUDA_TOOLKIT_ROOT_DIR指到了 CUDA 10.2 的安装路径OpenCV 的OpenCV_DIR也指到了对应的build目录。这些路径配置如果自己手动做极其容易出岔子比如最常见的装了 CUDA 后忘记把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin加进系统 PATH导致运行时找不到cudart64_102.dll。这份资源包的核心价值就在这里下载解压后你省掉的不仅是安装时间更是排查路径配置的精力。3. 环境落地与验证先确认基础软件真的能用3.1 安装顺序与最小验证清单拿到资源包后安装顺序还是建议按官方教程来驱动 → CUDA 10.2 → cuDNN 7.6.5 → VS2019 → OpenCV → Anaconda → CMake → TensorRT。资源包里已经放好了安装文件但安装动作还是得你自己执行。装完每个组件我都习惯跑一个最快的验证命令确认它真的可用而不是装完就算nvcc -V输出里能看到Cuda compilation tools, release 10.2, V10.2.89说明 CUDA 编译器就位了。如果nvcc不是内部或外部命令多半是没把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin加进 PATH。接着验证 cuDNNwhere cudnn64_7.dll能搜到路径说明 cuDNN 的动态库在 PATH 里。cudnn64_7.dll是 cuDNN 7 系列在 Windows 下的动态链接库文件名注意 7 这个数字是版本号的一部分不是随意命名的。3.2 验证 TensorRT 库文件是否存在TensorRT 7.0.0.11 解压后的目录结构里最关键的是lib和include两个目录。用下面的命令确认核心库文件dir C:\TensorRT-7.0.0.11\lib\nvinfer.dll dir C:\TensorRT-7.0.0.11\lib\nvinfer_plugin.dllnvinfer.dll是 TensorRT 的核心动态库nvinfer_plugin.dll是插件库YOLOv5 的某些自定义层依赖后者。如果nvinfer_plugin.dll缺失运行时加载引擎会报Cannot load TensorRT plugin library。这两个 DLL 建议手动复制到C:\Windows\System32或者确保它们在系统 PATH 下否则 VS2019 编译出的 exe 运行时找不到。OpenCV 的验证方式更直接python -c import cv2; print(cv2.__version__)注意这里要用 Anaconda3 的 Python 环境来跑。如果报ModuleNotFoundError说明 OpenCV 没有装进当前 Python 环境需要执行conda activate切换到正确的环境。资源包里预装好了但你还是得知道自己在哪个环境里操作。3.3 资源包内容速览与适用边界这份资源包适合的是「把环境跑通验证加速效果」这个目标。它不包含训练好的 YOLOv5 权重文件权重文件需要你从 YOLOv5 V4.0 官方仓库单独下载yolov5s.pt。如果连权重也想要现成的需要额外去找不要指望环境包里有。另一个边界是 GPU。TensorRT 的加速本质上是 CUDA 内核执行集显或者老掉牙的 GT 710 这种没有独立 CUDA 核心的卡装了也跑不起来。建议是有 GTX 1060 6G 或以上的显卡再折腾这个显存低于 4G 的卡在构建 TensorRT 引擎时会经常报out of memory不是代码问题是显存容量真不够。注意下载的资源包解压后建议先看一下目录结构确认各软件的路径没有中文和空格。C:\Program Files这种带空格的路径在 CMake 里需要引号包裹稍不注意就会配置失败。4. 编译与部署全流程从源码到 TensorRT 引擎4.1 CMake 配置关键路径一个都不能错YOLOv5 的 TensorRT 部署通常走的是 GitHub 上开源的 C 推理工程工程里包含 CMakeLists.txt。用 CMake-GUI 配置时重点关注这几个路径变量变量名应填路径说明OpenCV_DIR指向 OpenCV 的build目录必须含OpenCVConfig.cmakeCUDA_TOOLKIT_ROOT_DIRCUDA 10.2 安装根目录必须含bin\nvcc.exeTensorRT_ROOTTensorRT 解压根目录必须含lib\nvinfer.dllCMAKE_PREFIX_PATH依赖库搜索路径可用分号分隔多个路径配置时最容易翻车的是OpenCV_DIR的指向。很多人把路径指到了opencv\build\include这不对CMake 要找的是OpenCVConfig.cmake文件所在目录也就是opencv\build这一级。指错之后 CMake 会报Could not find OpenCV但你把路径改来改去依然报错这时候九成是目录级别不对。CUDA 和 TensorRT 的路径设置也有讲究。cmake配置命令窗口里如果报错说找不到 CUDA先检查CUDA_TOOLKIT_ROOT_DIR是不是指到了 CUDA 的根目录而不是bin目录。我见过不少人把路径填到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin导致 CMake 找不到include目录下的头文件。4.2 用 VS2019 编译推理工程CMake 配置成功点击 Generate 生成 VS2019 解决方案文件.sln然后打开解决方案把目标配置从 Debug 切到 Release。这里有个重要理由TensorRT 的发布库是 Release 版本的Debug 模式下链接会报nvinfer.lib和nvinfer.dll不匹配的错误因为发布了版库文件没有带调试符号。编译时你要在解决方案里找到yolov5这个项目右键设为启动项目然后选择生成。编译过程可能遇到三类问题错误 C1083: 无法打开包括文件: NvInfer.h: No such file or directory这个错误是你编译时没有找到 TensorRT 的头文件。解决方式是确认工程属性里的包含目录添加了TensorRT-7.0.0.11\include路径库目录添加了TensorRT-7.0.0.11\lib\x64路径。.lib文件是静态链接库.dll是运行时要加载的动态库VS2019 编译链接阶段用.lib运行时去 PATH 里找.dll两个阶段都要覆盖到。错误 LNK1104: 无法打开文件 opencv_world340.libOpenCV 3.4.0 的库文件名中的340是版本号。找不到库是因为链接器没找到 OpenCV 的.lib路径。注意链接器配置里要选附加库目录而不是附加包含目录后者只管头文件。另外Release 模式找的是不带d后缀的opencv_world340.libDebug 模式找的是opencv_world340d.lib如果工程里只放了一个文件切换模式后就会找不到。编译完成后生成的.exe文件在Release目录里。如果运行时提示缺少 DLL优先检查前文提到的PATH环境变量把 OpenCV 的bin目录和 TensorRT 的lib目录都加进去。这个步骤在资源包里已经做过了但如果是你自己装的系统就需要手动补上。4.3 将 PyTorch 权重转换为 ONNX 再转 TensorRTYOLOv5 官方权重是.pt格式TensorRT 不能直接吃这种格式。要先转成 ONNX再用 TensorRT 的解析器生成引擎。转换脚本直接用 YOLOv5 V4.0 仓库里的export.pypython export.py --weights yolov5s.pt --include onnx --img 640 640--include onnx指定导出格式--img 640 640指定输入尺寸为 640×640。YOLOv5 默认输入是 640×640转 ONNX 时必须保持这个尺寸否则后续 TensorRT 引擎的输入尺寸和你推理时实际喂进去的尺寸不一致会直接报维度不匹配的错误。常见做法是先固定一个推理尺寸一般用 640 或者 320YOLOv5 配置里imgsz参数要和这个值一致。然后在 Python 环境里用 TensorRT 的 Python 绑定的trtexec工具生成引擎。trtexec是 TensorRT 自带的命令行工具在TensorRT-7.0.0.11\bin目录下trtexec --onnxyolov5s.onnx --saveEngineyolov5s.trt --workspace4096--workspace4096指定使用 4096MB 显存作为构建引擎的工作空间。如果你的显卡显存只有 6G建议调低到 2048因为工作空间设置太高会叠加模型本身占用的显存超出显存容量直接构建失败。--saveEngine生成.trt后缀的引擎文件这就是最终推理要用的模型文件。转出来的引擎文件只能适配同型号的 GPU比如在 3060 上转的引擎换到 2080 上直接加载会报engine could not be deserialized这是正常现象换机器就得重新转一次。5. 避坑记录部署过程中最折腾人的六个问题5.1 推理结果全黑或全零的框不是模型坏了现象加载 TensorRT 引擎跑推理输出全是数值异常画框位置全乱。原因预处理时图像缩放方式与训练时不一致。YOLOv5 训练时用 letterbox 填充灰度边做了缩放保持宽高比而推理代码里如果直接用cv2.resize拉伸图像破坏了宽高比检测结果完全失效。解决推理前必须执行 letterbox 预处理把图像等比缩放到 640×640剩余区域填充 114 这个灰度值。这个参数写在 YOLOv5 官方预处理逻辑里11.4 是 114 除以 10 的结果细节对不齐结果就是乱的。5.2Could not find TensorRT library明明安装好了现象运行已经编译好的 exe程序启动即报错提示找不到 TensorRT 库。原因TensorRT 的 DLL 文件没有在系统 PATH 中或者依赖的 CUDA DLL 缺失。解决把TensorRT-7.0.0.11\lib加入系统 PATH 后还要确认C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin也在 PATH 里并放在 TensorRT 前面。在 Windows 下 DLL 搜索顺序是先当前目录、再系统路径如果你把 exe 放在了一个不含 DLL 的目录下运行就会优先报缺失。更稳妥的方式是把所有依赖的 DLL 复制到 exe 同目录下。5.3 C 推理速度比 PyTorch 还慢现象TensorRT 推理的耗时比 PyTorch 半精度推理还高完全没有加速效果。原因没有开启 FP16 精度模型一直在 FP32 精度下执行。TensorRT 的主要加速来源是 FP16 和 INT8 低精度推理FP32 模式虽然有层融合优化但预期加速差异不明显。解决config-setFlag(BuilderFlag::kFP16);构建引擎前在 TensorRT 构建配置里开启 FP16 标志。注意BuilderFlag是 TensorRT 7 的 C API 中IBuilderConfig的成员不同版本的 API 位置略有变化。开启 FP16 后在有 Tensor Core 支持的 GPURTX 系列上推理速度能提升 40% 到 60%。5.4 引擎构建时显存不够构建到一半崩溃现象trtexec构建引擎时进程直接崩溃日志里有CUDA error: out of memory。原因--workspace参数设置过大加上模型本身的中间张量总显存超出显卡容量。解决先确认显卡显存大小把 workspace 调到显存的一半以下。GTX 1060 6G 用 2048 更稳妥RTX 3060 12G 可以用 4096。显存不足的另一个隐藏原因是 Windows 的桌面显示也在占用显存笔记本双显卡切换模式下 TensorRT 可能跑在核显上需要确认 CUDA 设备是独立显卡。5.5 NMS 后处理的框数量不一致现象检测出的目标数量在 PyTorch 和 TensorRT 下不同置信度高的大目标会漏检。原因TensorRT 部署代码中后处理程序的 NMS 阈值与 PyTorch 推理时不一致。YOLOv5 的 NMS 默认iou_thres0.45、conf_thres0.25你 C 端如果设成0.6和0.5结果当然不同。解决把后处理参数与训练检测阶段对齐记住这些阈值是工程参数不是玄学必须逐项核对。5.6 VS2019 编译报一堆 MSB8028 警告但能用现象编译时提示MSB8028: The intermediate directory is shared但编译产物能正常生成。原因同一个项目在多配置下共用了中间目录Microsoft 默认中间目录是$(Configuration)如果工程改了设置就会冲突。解决这个警告可以忽略不影响生成结果。但如果你执意要消除打开项目属性把配置属性 → 常规 → 中间目录改成$(Platform)\$(Configuration)\每个配置就分开了。作为一个有洁癖的人我每次都改掉因为后续如果要并行编译多个配置共用目录会互相覆盖文件引发莫名奇怪的问题。6. 引擎优化的经验手把手教你验证加速效果引擎构建完成后你要验证它有没有真的加速。验证方法别只看程序打印的推理耗时还需要一个可信的对照实验。我习惯先把 PyTorch 的版本跑一遍记录同一个视频文件的单帧推理耗时再切换到 TensorRT 引擎跑一遍同一段视频对比数据才可信。如果你没有现成的视频用图片循环推理产生结果但注意循环里不要包含图像解码时间TensorRT 加速测的是纯推理耗时把图像预处理和后处理排除在耗时统计外。验证时可以参考下面这个简单的 C 计时模板#include chrono auto start std::chrono::high_resolution_clock::now(); context-enqueueV2(buffers, stream, nullptr); auto end std::chrono::high_resolution_clock::now(); float ms std::chrono::durationfloat, std::milli(end - start).count();enqueueV2是 TensorRT 7 的异步推理接口把输入输出缓冲区放进去执行。计时要围绕这个调用做不是把整个 with 循环都算进去。别忘了在循环前先预热推理 10 次因为首次推理有 CUDA kernel 加载和显存分配开销这个时间和真正稳定推理阶段的耗时差异很大不预热的话数据会高得离谱。用 Nsight Systems 做 Profiling 是一个进阶习惯。nsys profile --statstrue能看到 GPU kernel 的执行时间占比一眼看出耗时的瓶颈在预处理、推理还是后处理。以前我遇到过一种情况TensorRT 推理只占 30% 的时间剩下的全在 OpenCV 的resize上这就是典型的图像预处理拖后腿。后来我把图像的resize改成 CUDA 上的cudaMemcpy2D做优化整体性能又往前拱了一大截。关于 FP16 和 INT8补充一个选择经验。FP16 是无损的常见选项YOLOv5 在 FP16 下精度几乎没有损失速度提升明显无脑开启即可。INT8 需要标定标定数据集选不好还会掉点我一般不推荐新手把 INT8 作为第一步优化目标。先用 FP16 跑通确认加速效果后有多余精力再尝试 INT8 的 PTQ 量化但前提是你的 GPU 必须支持 INT8 的 Tensor Core 运算Turing 和 Ampere 架构都有Pascal 架构部分阉割。另外批次大小也是一个常被忽略的参数。TensorRT 引擎构建时指定了最大批次推理时如果每次只处理单张图片引擎并没有跑满。如果你的应用场景是视频流连续帧可以尝试把批次提高到 4 或 8吞吐量提升明显代价是延迟略微上升。视频流的批处理优化要从需求出发如果你做的是实时交互系统单帧延迟优先不建议上大批次如果做离线批量处理吞吐量优先批次调大很划算。文字识别的场景我就不展开摆了但道理是通用的你想清楚自己是延迟敏感还是吞吐敏感再决定要不要动批次大小。构建引擎时把工作空间设得恰到好处也很重要这是我从多次爆显存里得出的血泪经验。显存容量比较紧的时候我会用--workspace2048甚至更低并在构建前用nvidia-smi先看一眼当前 GPU 显存占用确保没有其他程序占着显存不放。从那以后我每次部署前都强制走一遍 PLONK 流程先确认版本匹配再核椭圆曲线路径最后验验证完时机再清显存。想少走弯路的同行们记住这套循环能帮你省下大量排查时间。希望帮到你。本文还有配套的精品资源点击获取 TensorRT部署YOLOv5：环境版本匹配与推理加速实战指南
简介针对在Windows 10系统下使用TensorRT加速YOLOv5目标检测的部署需求这份PDF文档提供了完整的软件依赖清单与现成下载入口面向想要快速完成环境搭建的开发者或入门者免去逐个查找安装包、反复匹配版本以及处理依赖冲突的困扰。包内为单个PDF文档大小仅169KB却浓缩了十多个关键组件的下载与配置信息包括CUDA 10.2、cuDNN 7.6.5、Visual Studio 2019、OpenCV 3.4.0、Anaconda3、CMake 3.19.4、TensorRT 7.0.0.11及YOLOv5 V4.0等并附带已经预配置好的百度网盘链接下载后可直接按说明使用。目前已有三千四百九十二人学习浏览对于希望将YOLOv5模型在英伟达显卡上加速推理的读者来说文档中的版本选型、安装顺序梳理和常见配置要点能够明显降低踩坑概率。阅读这份说明还能理解各个依赖库在部署链路中的具体作用比如CUDA提供GPU计算平台cuDNN加速卷积网络Visual Studio用于编译工程CMake负责构建配置TensorRT则把模型转换成优化的执行引擎最终帮助读者完成从源码构建到引擎生成的完整过程实现更低延迟的实时物体检测。1. TensorRT 部署 YOLOv5为什么说环境版本匹配比算法本身更磨人在 Windows 上把 YOLOv5 跑起来不算难真正让人原地放弃的是把 TensorRT 接进工程的那一步。手头这份资源是 Win10 CUDA 10.2 cuDNN 7.6.5 VS2019 OpenCV 3.4.0 Anaconda3 CMake 3.19.4 TensorRT 7.0.0.11 的全套预配置环境打包配合 CSDN 那篇《Win10—YOLOv5 实战TensorRT 部署VS2019 编译(小白教程~易懂易上手)》使用。它的核心价值在于所有软件依赖都修改配置完毕下载解压就能直接进入编译和部署流程而不是像裸装那样在版本冲突里折腾两三天。适合新手第一次在 Win10 上体验 TensorRT 加速也适合熟手想快速拿到一套已验证可用的工程环境跳过环境地狱直接验证自己的推理代码。先说结论这套组合里最磨人的不是 YOLOv5 本身而是 TensorRT 7 和 CUDA 10.2 之间苛刻的版本对应关系版本错一个位编译期和运行期都会给你颜色看。2. 版本选型逻辑为什么是 CUDA 10.2 TensorRT 7.0.0.112.1 TensorRT 与 CUDA 的版本绑定关系TensorRT 对 CUDA 版本的依赖极其敏感不是随便拿个新版本就能搭配。TensorRT 7.0.0.11 官方支持的是 CUDA 10.2 和 cuDNN 7.6.5这个组合在 2020 年到 2021 年之间是 NVIDIA 官方验证过的稳定配对。如果你换成 CUDA 11.xTensorRT 7 的库文件在链接阶段就会报一堆找不到符号的错误即使能编译通过运行时也会出现CudaRuntime版本不匹配的异常。常见做法是先确认显卡的算力。TensorRT 7 对 Turing 架构RTX 20 系和 Ampere 架构RTX 30 系都有支持但 Ampere 在 CUDA 10.2 下需要 460 以上的驱动版本。你装驱动的时候注意别用太老的版本否则 TensorRT 初始化会报CUDA driver version is insufficient for CUDA runtime version。我一般装机前先跑一次nvidia-smi看驱动版本再决定要不要升级 NVIDIA 驱动。2.2 VS2019 与 CMake 的编译器匹配VS2019 对应的 MSVC 工具集是 v142CMake 3.19.4 对 VS2019 的生成器支持得很好。选 CMake 3.19.4 而不是更新的版本是为了避开新版本 CMake 对旧版 CUDA 探测方式的改变。CMake 从 3.20 开始对 CUDA 语言支持做了调整探测 CUDA 10.2 的方式不再兼容导致配置阶段直接失败。这是一个很隐蔽的坑很多人卡在这里以为是 CUDA 装坏了其实是 CMake 版本太新。OpenCV 3.4.0 的选择也值得说一句。YOLOv5 的后处理对 OpenCV 的依赖主要在图像读取和画框这些基础功能上3.4.x 完全够用而且预编译的 Windows 包在 VS2019 下链接稳定。不要换成 OpenCV 4.x原因在于 4.x 对cv::dnn模块的默认行为有改动如果你顺着老教程走部分 API 调用会报找不到符号。2.3 这份资源包帮你省掉了哪些配置步骤全套软件环境已经配置修改好下载即可使用——这句话的实际含义是环境变量已经加好TensorRT-7.0.0.11的lib目录已经加入PATHCMake 的CUDA_TOOLKIT_ROOT_DIR指到了 CUDA 10.2 的安装路径OpenCV 的OpenCV_DIR也指到了对应的build目录。这些路径配置如果自己手动做极其容易出岔子比如最常见的装了 CUDA 后忘记把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin加进系统 PATH导致运行时找不到cudart64_102.dll。这份资源包的核心价值就在这里下载解压后你省掉的不仅是安装时间更是排查路径配置的精力。3. 环境落地与验证先确认基础软件真的能用3.1 安装顺序与最小验证清单拿到资源包后安装顺序还是建议按官方教程来驱动 → CUDA 10.2 → cuDNN 7.6.5 → VS2019 → OpenCV → Anaconda → CMake → TensorRT。资源包里已经放好了安装文件但安装动作还是得你自己执行。装完每个组件我都习惯跑一个最快的验证命令确认它真的可用而不是装完就算nvcc -V输出里能看到Cuda compilation tools, release 10.2, V10.2.89说明 CUDA 编译器就位了。如果nvcc不是内部或外部命令多半是没把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin加进 PATH。接着验证 cuDNNwhere cudnn64_7.dll能搜到路径说明 cuDNN 的动态库在 PATH 里。cudnn64_7.dll是 cuDNN 7 系列在 Windows 下的动态链接库文件名注意 7 这个数字是版本号的一部分不是随意命名的。3.2 验证 TensorRT 库文件是否存在TensorRT 7.0.0.11 解压后的目录结构里最关键的是lib和include两个目录。用下面的命令确认核心库文件dir C:\TensorRT-7.0.0.11\lib\nvinfer.dll dir C:\TensorRT-7.0.0.11\lib\nvinfer_plugin.dllnvinfer.dll是 TensorRT 的核心动态库nvinfer_plugin.dll是插件库YOLOv5 的某些自定义层依赖后者。如果nvinfer_plugin.dll缺失运行时加载引擎会报Cannot load TensorRT plugin library。这两个 DLL 建议手动复制到C:\Windows\System32或者确保它们在系统 PATH 下否则 VS2019 编译出的 exe 运行时找不到。OpenCV 的验证方式更直接python -c import cv2; print(cv2.__version__)注意这里要用 Anaconda3 的 Python 环境来跑。如果报ModuleNotFoundError说明 OpenCV 没有装进当前 Python 环境需要执行conda activate切换到正确的环境。资源包里预装好了但你还是得知道自己在哪个环境里操作。3.3 资源包内容速览与适用边界这份资源包适合的是「把环境跑通验证加速效果」这个目标。它不包含训练好的 YOLOv5 权重文件权重文件需要你从 YOLOv5 V4.0 官方仓库单独下载yolov5s.pt。如果连权重也想要现成的需要额外去找不要指望环境包里有。另一个边界是 GPU。TensorRT 的加速本质上是 CUDA 内核执行集显或者老掉牙的 GT 710 这种没有独立 CUDA 核心的卡装了也跑不起来。建议是有 GTX 1060 6G 或以上的显卡再折腾这个显存低于 4G 的卡在构建 TensorRT 引擎时会经常报out of memory不是代码问题是显存容量真不够。注意下载的资源包解压后建议先看一下目录结构确认各软件的路径没有中文和空格。C:\Program Files这种带空格的路径在 CMake 里需要引号包裹稍不注意就会配置失败。4. 编译与部署全流程从源码到 TensorRT 引擎4.1 CMake 配置关键路径一个都不能错YOLOv5 的 TensorRT 部署通常走的是 GitHub 上开源的 C 推理工程工程里包含 CMakeLists.txt。用 CMake-GUI 配置时重点关注这几个路径变量变量名应填路径说明OpenCV_DIR指向 OpenCV 的build目录必须含OpenCVConfig.cmakeCUDA_TOOLKIT_ROOT_DIRCUDA 10.2 安装根目录必须含bin\nvcc.exeTensorRT_ROOTTensorRT 解压根目录必须含lib\nvinfer.dllCMAKE_PREFIX_PATH依赖库搜索路径可用分号分隔多个路径配置时最容易翻车的是OpenCV_DIR的指向。很多人把路径指到了opencv\build\include这不对CMake 要找的是OpenCVConfig.cmake文件所在目录也就是opencv\build这一级。指错之后 CMake 会报Could not find OpenCV但你把路径改来改去依然报错这时候九成是目录级别不对。CUDA 和 TensorRT 的路径设置也有讲究。cmake配置命令窗口里如果报错说找不到 CUDA先检查CUDA_TOOLKIT_ROOT_DIR是不是指到了 CUDA 的根目录而不是bin目录。我见过不少人把路径填到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin导致 CMake 找不到include目录下的头文件。4.2 用 VS2019 编译推理工程CMake 配置成功点击 Generate 生成 VS2019 解决方案文件.sln然后打开解决方案把目标配置从 Debug 切到 Release。这里有个重要理由TensorRT 的发布库是 Release 版本的Debug 模式下链接会报nvinfer.lib和nvinfer.dll不匹配的错误因为发布了版库文件没有带调试符号。编译时你要在解决方案里找到yolov5这个项目右键设为启动项目然后选择生成。编译过程可能遇到三类问题错误 C1083: 无法打开包括文件: NvInfer.h: No such file or directory这个错误是你编译时没有找到 TensorRT 的头文件。解决方式是确认工程属性里的包含目录添加了TensorRT-7.0.0.11\include路径库目录添加了TensorRT-7.0.0.11\lib\x64路径。.lib文件是静态链接库.dll是运行时要加载的动态库VS2019 编译链接阶段用.lib运行时去 PATH 里找.dll两个阶段都要覆盖到。错误 LNK1104: 无法打开文件 opencv_world340.libOpenCV 3.4.0 的库文件名中的340是版本号。找不到库是因为链接器没找到 OpenCV 的.lib路径。注意链接器配置里要选附加库目录而不是附加包含目录后者只管头文件。另外Release 模式找的是不带d后缀的opencv_world340.libDebug 模式找的是opencv_world340d.lib如果工程里只放了一个文件切换模式后就会找不到。编译完成后生成的.exe文件在Release目录里。如果运行时提示缺少 DLL优先检查前文提到的PATH环境变量把 OpenCV 的bin目录和 TensorRT 的lib目录都加进去。这个步骤在资源包里已经做过了但如果是你自己装的系统就需要手动补上。4.3 将 PyTorch 权重转换为 ONNX 再转 TensorRTYOLOv5 官方权重是.pt格式TensorRT 不能直接吃这种格式。要先转成 ONNX再用 TensorRT 的解析器生成引擎。转换脚本直接用 YOLOv5 V4.0 仓库里的export.pypython export.py --weights yolov5s.pt --include onnx --img 640 640--include onnx指定导出格式--img 640 640指定输入尺寸为 640×640。YOLOv5 默认输入是 640×640转 ONNX 时必须保持这个尺寸否则后续 TensorRT 引擎的输入尺寸和你推理时实际喂进去的尺寸不一致会直接报维度不匹配的错误。常见做法是先固定一个推理尺寸一般用 640 或者 320YOLOv5 配置里imgsz参数要和这个值一致。然后在 Python 环境里用 TensorRT 的 Python 绑定的trtexec工具生成引擎。trtexec是 TensorRT 自带的命令行工具在TensorRT-7.0.0.11\bin目录下trtexec --onnxyolov5s.onnx --saveEngineyolov5s.trt --workspace4096--workspace4096指定使用 4096MB 显存作为构建引擎的工作空间。如果你的显卡显存只有 6G建议调低到 2048因为工作空间设置太高会叠加模型本身占用的显存超出显存容量直接构建失败。--saveEngine生成.trt后缀的引擎文件这就是最终推理要用的模型文件。转出来的引擎文件只能适配同型号的 GPU比如在 3060 上转的引擎换到 2080 上直接加载会报engine could not be deserialized这是正常现象换机器就得重新转一次。5. 避坑记录部署过程中最折腾人的六个问题5.1 推理结果全黑或全零的框不是模型坏了现象加载 TensorRT 引擎跑推理输出全是数值异常画框位置全乱。原因预处理时图像缩放方式与训练时不一致。YOLOv5 训练时用 letterbox 填充灰度边做了缩放保持宽高比而推理代码里如果直接用cv2.resize拉伸图像破坏了宽高比检测结果完全失效。解决推理前必须执行 letterbox 预处理把图像等比缩放到 640×640剩余区域填充 114 这个灰度值。这个参数写在 YOLOv5 官方预处理逻辑里11.4 是 114 除以 10 的结果细节对不齐结果就是乱的。5.2Could not find TensorRT library明明安装好了现象运行已经编译好的 exe程序启动即报错提示找不到 TensorRT 库。原因TensorRT 的 DLL 文件没有在系统 PATH 中或者依赖的 CUDA DLL 缺失。解决把TensorRT-7.0.0.11\lib加入系统 PATH 后还要确认C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin也在 PATH 里并放在 TensorRT 前面。在 Windows 下 DLL 搜索顺序是先当前目录、再系统路径如果你把 exe 放在了一个不含 DLL 的目录下运行就会优先报缺失。更稳妥的方式是把所有依赖的 DLL 复制到 exe 同目录下。5.3 C 推理速度比 PyTorch 还慢现象TensorRT 推理的耗时比 PyTorch 半精度推理还高完全没有加速效果。原因没有开启 FP16 精度模型一直在 FP32 精度下执行。TensorRT 的主要加速来源是 FP16 和 INT8 低精度推理FP32 模式虽然有层融合优化但预期加速差异不明显。解决config-setFlag(BuilderFlag::kFP16);构建引擎前在 TensorRT 构建配置里开启 FP16 标志。注意BuilderFlag是 TensorRT 7 的 C API 中IBuilderConfig的成员不同版本的 API 位置略有变化。开启 FP16 后在有 Tensor Core 支持的 GPURTX 系列上推理速度能提升 40% 到 60%。5.4 引擎构建时显存不够构建到一半崩溃现象trtexec构建引擎时进程直接崩溃日志里有CUDA error: out of memory。原因--workspace参数设置过大加上模型本身的中间张量总显存超出显卡容量。解决先确认显卡显存大小把 workspace 调到显存的一半以下。GTX 1060 6G 用 2048 更稳妥RTX 3060 12G 可以用 4096。显存不足的另一个隐藏原因是 Windows 的桌面显示也在占用显存笔记本双显卡切换模式下 TensorRT 可能跑在核显上需要确认 CUDA 设备是独立显卡。5.5 NMS 后处理的框数量不一致现象检测出的目标数量在 PyTorch 和 TensorRT 下不同置信度高的大目标会漏检。原因TensorRT 部署代码中后处理程序的 NMS 阈值与 PyTorch 推理时不一致。YOLOv5 的 NMS 默认iou_thres0.45、conf_thres0.25你 C 端如果设成0.6和0.5结果当然不同。解决把后处理参数与训练检测阶段对齐记住这些阈值是工程参数不是玄学必须逐项核对。5.6 VS2019 编译报一堆 MSB8028 警告但能用现象编译时提示MSB8028: The intermediate directory is shared但编译产物能正常生成。原因同一个项目在多配置下共用了中间目录Microsoft 默认中间目录是$(Configuration)如果工程改了设置就会冲突。解决这个警告可以忽略不影响生成结果。但如果你执意要消除打开项目属性把配置属性 → 常规 → 中间目录改成$(Platform)\$(Configuration)\每个配置就分开了。作为一个有洁癖的人我每次都改掉因为后续如果要并行编译多个配置共用目录会互相覆盖文件引发莫名奇怪的问题。6. 引擎优化的经验手把手教你验证加速效果引擎构建完成后你要验证它有没有真的加速。验证方法别只看程序打印的推理耗时还需要一个可信的对照实验。我习惯先把 PyTorch 的版本跑一遍记录同一个视频文件的单帧推理耗时再切换到 TensorRT 引擎跑一遍同一段视频对比数据才可信。如果你没有现成的视频用图片循环推理产生结果但注意循环里不要包含图像解码时间TensorRT 加速测的是纯推理耗时把图像预处理和后处理排除在耗时统计外。验证时可以参考下面这个简单的 C 计时模板#include chrono auto start std::chrono::high_resolution_clock::now(); context-enqueueV2(buffers, stream, nullptr); auto end std::chrono::high_resolution_clock::now(); float ms std::chrono::durationfloat, std::milli(end - start).count();enqueueV2是 TensorRT 7 的异步推理接口把输入输出缓冲区放进去执行。计时要围绕这个调用做不是把整个 with 循环都算进去。别忘了在循环前先预热推理 10 次因为首次推理有 CUDA kernel 加载和显存分配开销这个时间和真正稳定推理阶段的耗时差异很大不预热的话数据会高得离谱。用 Nsight Systems 做 Profiling 是一个进阶习惯。nsys profile --statstrue能看到 GPU kernel 的执行时间占比一眼看出耗时的瓶颈在预处理、推理还是后处理。以前我遇到过一种情况TensorRT 推理只占 30% 的时间剩下的全在 OpenCV 的resize上这就是典型的图像预处理拖后腿。后来我把图像的resize改成 CUDA 上的cudaMemcpy2D做优化整体性能又往前拱了一大截。关于 FP16 和 INT8补充一个选择经验。FP16 是无损的常见选项YOLOv5 在 FP16 下精度几乎没有损失速度提升明显无脑开启即可。INT8 需要标定标定数据集选不好还会掉点我一般不推荐新手把 INT8 作为第一步优化目标。先用 FP16 跑通确认加速效果后有多余精力再尝试 INT8 的 PTQ 量化但前提是你的 GPU 必须支持 INT8 的 Tensor Core 运算Turing 和 Ampere 架构都有Pascal 架构部分阉割。另外批次大小也是一个常被忽略的参数。TensorRT 引擎构建时指定了最大批次推理时如果每次只处理单张图片引擎并没有跑满。如果你的应用场景是视频流连续帧可以尝试把批次提高到 4 或 8吞吐量提升明显代价是延迟略微上升。视频流的批处理优化要从需求出发如果你做的是实时交互系统单帧延迟优先不建议上大批次如果做离线批量处理吞吐量优先批次调大很划算。文字识别的场景我就不展开摆了但道理是通用的你想清楚自己是延迟敏感还是吞吐敏感再决定要不要动批次大小。构建引擎时把工作空间设得恰到好处也很重要这是我从多次爆显存里得出的血泪经验。显存容量比较紧的时候我会用--workspace2048甚至更低并在构建前用nvidia-smi先看一眼当前 GPU 显存占用确保没有其他程序占着显存不放。从那以后我每次部署前都强制走一遍 PLONK 流程先确认版本匹配再核椭圆曲线路径最后验验证完时机再清显存。想少走弯路的同行们记住这套循环能帮你省下大量排查时间。希望帮到你。本文还有配套的精品资源点击获取