距离我上一次在 Windows 上折腾 TensorRT 7.0已经过去很久了。当时项目要在 Windows 10 下跑一个实时图像识别的原型模型从 PyTorch 导出之后 CPU 推理怎么压都压不到实时于是想试试 TensorRT 做 GPU 加速。翻了十几篇帖子大部分讲的都是 Linux 上的流程Windows 下要么一笔带过要么版本对不上。后来我把官方文档重新啃了一遍又结合自己踩过的坑总算整理出一套能稳定复现的安装方式。如果你正准备在 Windows 上装 TensorRT 7.0这篇笔记基本就是你需要的完整路线图。TensorRT 是高性能深度学习推理加速器它会把训练好的模型重新优化成推理引擎包括层融合、精度校准、kernel 自动调优等等核心目标就是把 GPU 的推理性能榨到极致。它解决的问题非常明确模型太大、推理太慢、GPU 利用率太低。适合正在做模型部署、需要低延迟推理、或者想把手头模型跑得更快的开发者参考。文章里没有花哨的东西全部是能直接执行的步骤。安装过程中最常见的版本匹配问题我也会按排查顺序列出来。建议你准备一个干净的 Windows 10 环境照着往下走。1. 安装前必须搞清楚的三个硬性条件很多人在 TensorRT 安装上翻车不是因为操作复杂而是因为没搞清楚它的依赖关系。它不是一个独立软件而是寄生在 CUDA 和 cuDNN 之上的组件版本错一位就会导致 DLL 加载失败。所以在动手之前先把下面三类条件逐项核对。1.1 硬件和系统要求TensorRT 本质上是 NVIDIA 显卡的推理加速库所以第一步是确认你的 GPU 够不够格。操作系统Windows 10 64 位。TensorRT 7.0 没有 32 位版本也基本不支持 Windows 7建议直接上 Windows 10 x64。显卡NVIDIA 独立显卡架构建议 Pascal 及以上也就是 GTX 10 系、RTX 20 系以及后续产品。官方对计算能力Compute Capability有最低要求TensorRT 7.0 支持的计算能力范围大致在 5.0 到 7.5 之间。太老的 Kepler、Maxwell 架构不一定能完整发挥全部特性。显存建议至少 2 GB。TensorRT 做优化时会临时申请显存模型本身 中间 buffer 后处理显存太小容易崩。内存8 GB 起步16 GB 更稳。TensorRT 在解析和优化模型时对内存有一定要求特别是跑 trtexec 构建 engine 的时候。怎么看自己 GPU 的计算能力直接在搜索引擎查设备型号对应的 Compute Capability 表就行。我遇到过有人拿 GT 730 想跑 TensorRT折腾一晚上结果发现计算能力 3.5 根本不在支持范围内这就是典型的硬件条件不足。1.2 依赖组件的版本匹配这是整篇文章最核心的一节请反复看到背诵。TensorRT 7.0 对依赖有极其严格的指向装错了它不会给你提示“版本不对”而是直接报 DLL missing 或者干脆闪退。CUDA Toolkit必须装 10.2注意是 10.2不是 10.1也不是 11.0。TensorRT 7.0 是在 CUDA 10.2 时代发布的二进制层面只认这个版本。cuDNN需要 7.6.5 版本并且是 for CUDA 10.2 的那一个包。注意 cuDNN 8.x 里 DLL 命名是 cudnn64_8.dll而 TensorRT 7.0 找的是 cudnn64_7.dll如果装了 cuDNN 8.xTensorRT 根本找不到对应文件。显卡驱动不能太老。CUDA 10.2 对驱动版本有最低要求建议直接装 2020 年以后发布的驱动或者至少保证驱动支持的 CUDA 版本 ≥ 10.2。Python 版本如果走 Python API官方 wheel 只支持 Python 3.5、3.6、3.7 的 64 位版本。我用的是 3.7实际上 3.7 也是最稳的。Visual Studio如果只是运行和使用不一定需要。但如果你要自己编译官方 samples或者打算用 C 做二次开发建议装 Visual Studio 2017 或 2019安装时选上“使用 C 的桌面开发”工作负载。为什么非要这么精确因为 CUDA 运行时库的名字里带着版本号比如 cudart64_102.dll这是 CUDA 10.2 的运行时。TensorRT 编译的时候链接的就是这个具体版本的符号表你换个版本的 DLL符号可能名字相同但内部结构有差异很容易在运行时崩溃。所以版本对齐是第一条军规。1.3 安装前你要准备哪些工具准备阶段不需要花太多时间但下面几样缺一不可管理员权限的命令行窗口。后续配置环境变量、启动验证程序都会用到。WinR 输入 cmd然后 CtrlShiftEnter 以管理员身份运行即可。文本编辑器用来修改环境变量位置其实系统自带 notepad 就够了。提前建好一个纯英文路径的安装目录比如C:\TensorRT-7.0.0.11。不要带中文、不要带空格更不要放在桌面上。这是 Windows 下 DLL 加载的老大难问题路径里有中文有时候会导致一些 DLL 搜索失败。从官方下载渠道获取两个文件TensorRT 7.0 的 Windows ZIP 包完整包和对应的 Python wheel 文件如果用 Python 的话。下载需要注册账号这个不多说。准备就绪后下面进入正式安装。2. TensorRT 7.0 的两种主流安装方式TensorRT 7.0 在 Windows 上提供了两种安装载体一个是完整的 ZIP 压缩包包含所有库文件、头文件、工具链和示例代码另一个是 Python wheel 包专门给 Python 用户用。两者的安装过程和适用场景差别不小我分开讲。2.1 方式一ZIP 压缩包全量部署这是官方推荐的完整安装方式适合需要 C API、trtexec 工具、或者想研究示例代码的人。整个流程分为四步。第一步解压 ZIP 包。把下载到的TensorRT-7.0.0.11.Windows10.x86_64.zip解压到刚才准备的目录比如C:\TensorRT-7.0.0.11。解压完成后你应该能看到这些目录或文件include 存放 C 头文件lib 存放静态库和动态库bin 存放 trtexec.exe 等可执行程序samples 存放官方示例源码docs 存放文档data 存放示例模型数据。第二步把动态库目录加入系统 PATH。TensorRT 在 Windows 上的 DLL 位于lib\x64子目录下不是lib根目录。很多人加错路径结果运行的时候还是找不到 nvinfer.dll。打开“此电脑 - 属性 - 高级系统设置 - 环境变量”在系统变量里找到 PATH点编辑新建一行填入C:\TensorRT-7.0.0.11\lib\x64。注意是这个目录不要填到lib就停了。第三步验证 PATH 是否生效。重新打开一个命令行窗口输入trtexec.exe --help如果能看到一堆参数说明说明 TensorRT 核心库已经在能搜索到的路径里了。如果提示“不是内部或外部命令”多半是 PATH 没保存成功或者你还在旧窗口里操作。重开窗口再看一次。第四步把 cuDNN 的 DLL 放到能被找到的位置。TensorRT 运行的时候会依赖 cuDNN 的 cudnn64_7.dll这个文件不在 TensorRT 包里需要你自己解压 cuDNN然后把cuda\bin\cudnn64_7.dll复制到 CUDA 10.2 的bin目录下。这是官方文档里也推荐的做法因为这样 CUDA 自带的 PATH 搜索就能覆盖到。有个细节值得注意完整 ZIP 包里的 bins 下除了 trtexec.exe 之外还有一些工具比如 polygraphy 相关的命令行工具。这些工具的 DLL 依赖都在 lib\x64 下只要 PATH 配好了一般都能跑起来。2.2 方式二pip wheel 轻量安装如果你的主要使用方式是 Python不想管一堆 C 路径可以用 pip 直接装 wheel。TensorRT 7.0 为 Windows 发布了多个 Python 版本的 wheel 包文件名里已经标好了对应的 Python 版本例如tensorrt-7.0.0.11-cp37-cp37m-win_amd64.whl其中 cp37 就代表 Python 3.7。安装步骤很简洁pip install tensorrt-7.0.0.11-cp37-cp37m-win_amd64.whl装完之后用一个简单的命令验证python -c import tensorrt; print(tensorrt.__version__)如果能看到 7.0.0.11 这样的版本号说明 Python 绑定已经装好了。但这里有个隐患Python wheel 本质上只是把 TensorRT 的 DLL 和 Python 的.pyd绑定文件打包在一起底层仍然需要 CUDA 10.2 和 cuDNN 7.6.5。也就是说你依然要先装好 CUDA 和 cuDNN否则 import 时会报 DLL 加载失败。还有一点pip 安装的目录是可变的。如果 Python 环境是 conda 虚拟环境那么 TensorRT 会被装到C:\Users\你的用户名\.conda\envs\环境名\Lib\site-packages\tensorrt这类路径下。这个路径下的 DLL 是否能在 Python 启动时被加载取决于当前环境 PATH 里是否包含 CUDA bin 目录。稳妥起见建议在 conda 环境里也把 CUDA 的 bin 目录加入 PATH。2.3 两种方式怎么选很多人会纠结其实很简单看你会不会用到 C、trtexec 或者想直接改模型优化参数。只用 Python不碰 C选 pip wheel。安装快、依赖少一个命令搞定。需要 C API、自己写插件、编译 samples选 ZIP 包。既要 Python 又要 C先装 ZIP 包然后手动下载 wheel 再装也行但我更推荐直接都用 ZIP 包里的 Python 绑定文件。ZIP 包里其实也带了 Python 绑定目录只是需要手动设置引导路径过程稍微麻烦。如果你不想费这个劲那就先 pip 装 wheel需要 C 工具时再把 ZIP 解压只把 bin 目录加入 PATH不要重复安装同一个 TensorRT 版本到 Python 环境里否则容易产生 DLL 来源冲突。我还想提醒一个问题TensorRT 的 wheel 包不提供 trtexec.exe 这些命令行工具。所以如果你之后想用 trtexec 对模型做转换和 FP16 精度评估即使走了 pip 路线也需要下载 ZIP 包至少把 bin 目录用起来。很多教程不会讲这一步等到需要的时候才发现工具没有。3. 安装后的环境配置与快速验证装完只是第一步能不能在真实项目里跑通是另一回事。这一节我重点讲环境变量的完整细节以及验证方法。验证不需要什么复杂的模型一分钟就能确认你的安装是否健康。3.1 环境变量配置的完整细节先回顾一下 PATH 要配几个关键位置TensorRT 的lib\x64为了让 nvinfer.dll、nvparsers.dll、nvonnxparser.dll 这些核心库能被系统找到。CUDA 的bin目录通常是C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin。如果安装时改了路径以实际安装路径为准。这里提供 cudart64_102.dll 等运行时库。cuDNN 的bin目录如果你没有把 cudnn64_7.dll 复制到 CUDA bin就要把 cuDNN 解压后的cuda\bin加入 PATH。二选一不要重复。重复也没事但容易把自己搞晕。这里有一个常见的误区不要把 TensorRT 的lib根目录加入 PATH。因为 7.0 在 Windows 下默认把 DLL 放在lib\x64你只配置lib根目录系统搜不到任何有用的 DLL。我在帮同事排查时遇到过三次这种问题最后发现都是只看教程的一步“加入 lib 目录”没有注意子目录。配置完成后最好在命令行里用echo %PATH%检查一下确认路径没有被畸形拼接。有些环境变量编辑器会把新加的路径放在最后但前面如果有其他含 ASCII 空格的路径一般不影响。只要能看到完整的C:\TensorRT-7.0.0.11\lib\x64字样就说明没问题。另外如果你在系统里同时装了多个 CUDA 版本PATH 里的顺序很重要。Windows 在加载 DLL 时按 PATH 顺序从前到后查找如果前面有 CUDA 11 的 binTensorRT 7.0 首次加载时可能先命中了 cudart64_110.dll导致后续符号不匹配。所以需要把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin放在其他 CUDA 目录之前或者在项目启动脚本里临时置顶。3.2 Python API 一条龙验证用 Python 验证是最直观的方式。打开命令行先检查版本号python -c import tensorrt as trt; print(trt.__version__)如果这个命令能输出 7.0.0.11说明 Python 绑定层面没问题。但这里只验证了 import还没验证核心 builder 是否能正常工作。很多情况下 import 能过但创建一个 builder 反而崩这就是 DLL 深层依赖的问题。建议再执行一段更完整的代码import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network() print(TensorRT builder created successfully)这段代码创建了一个 Logger 对象和 Builder 对象覆盖了 TensorRT 大部分基础组件的加载过程。如果它能顺利打印出 “TensorRT builder created successfully”说明 CUDA 运行时、cuDNN、TensorRT 核心 DLL 之间的依赖关系已经全部打通。我在实际测试中有几次 import 成功但 builder 创建时直接弹窗崩溃就是因为 cuDNN 版本不对。所以这步很有必要。如果你想进一步验证能不能真正构建一个最小的 engine可以写一个显式 batch 的网络。不过这涉及 TensorRT 网络定义 API内容会超出安装范畴。对于新手到 builder 创建成功这一步就可以放心使用 Python API 了。3.3 用 trtexec 命令行工具做冒烟测试如果你装了 ZIP 包trtexec 是更底层的验证工具。在命令行里直接运行trtexec.exe --help能看到输出就是基础安装成功。更进一步如果你手里有 ONNX 格式的模型可以用它体验完整转换trtexec.exe --onnxmodel.onnx --saveEnginemodel.trt这条命令会读取 ONNX 模型解析、推理并生成一个 TensorRT engine 文件。第一次运行会比较久因为 TensorRT 会做多轮优化和 kernel 自动调优耗时几十秒到几分钟不等取决于模型大小和显卡性能。看到最后输出类似Engine created successfully的信息说明不仅仅是安装成功整个推理链路也可以正常工作。注意trtexec 在运行 ONNX 模型时需要在当前目录能找到模型文件最好将模型路径写成绝对路径。如果遇到“Failed to parse ONNX”这类报错说明模型里有 TensorRT 7.0 不支持的算子这属于安装之外的问题可以先不理会用更简单的模型验证。4. 常见问题与排查实录下面这些问题是真实踩坑次数最多的场景。安装后一旦出现报错按分类去排查大概率几分钟就能解决。4.1 DLL 加载失败最常见也最容易被误导现象运行 trtexec 或 Python import 时报错“找不到 nvinfer.dll”或“DLL load failed”。排查顺序检查 PATH 是否包含lib\x64。很多人配的是lib这是错误的。检查是否安装了 VC 运行库。TensorRT 的 DLL 依赖微软的 Visual C Redistributable缺少时经常会报 0xc000007b 错误或者“不是有效的 Win32 应用程序”。到微软官网搜索 “Visual C Redistributable for Visual Studio 2015-2022”把 x64 版本装上。检查 DLL 冲突。用where nvinfer.dll命令查看当前路径下有没有两个以上的 nvinfer.dll如果有说明之前安装过其他版本需要把 PATH 顺序调整到正确版本或者彻底删除旧版本。检查系统 PATH 中是否包含 TensorRT 动态库所需的其他第三方 DLL比如 zlib.dll、libprotobuf 等。如果缺失会变成非常隐蔽的崩溃。这种问题不好排查遇到的时候建议下载依赖分析工具查看缺失模块。这套排查顺序我自己用下来命中率最高的还是前两步。尤其是 VC 运行库很多人根本不会想到因为报错信息完全没提。推荐先装最新版 VC x64 运行库再回头看 PATH。4.2 CUDA、cuDNN 版本错位现象加载报错里提到了具体 DLL比如 cudart64_102.dll 缺失、cudnn64_7.dll 缺失。这种情况基本可以断定CUDA 或 cuDNN 版本不对或者文件没有被放在正确位置。第一步用命令行确认当前 CUDA 版本nvcc -V如果输出的是 10.2说明 CUDA Toolkit 本身没问题。如果不是很可能你 PATH 里的 nvcc 是别的版本或者你根本没装 10.2。TensorRT 7.0 对 CUDA 10.2 的依赖是硬性的不要想用 10.1 或者 11.0 侥幸替代我试过失败率几乎是百分之百。cuDNN 的排查方式也很简单在命令行里输入where cudnn64_7.dll看它究竟在哪个目录。如果提示找不到说明 cuDNN 没装对。解压 cuDNN 7.6.5 后确保cuda\bin\cudnn64_7.dll存在并且已经复制到 CUDA 10.2 的 bin 目录或者 cuDNN 的 bin 已加入 PATH。注意如果你复制了文件后依然报错多半是复制的目标目录并不在 PATH 里。用dir C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2\bin\cudnn64_7.dll确认文件是否真实存在。这里要特别强调CUDA 10.2 运行时 DLL 的名字是cudart64_102.dll而 CUDA 11.0 的运行时 DLL 是cudart64_110.dll。如果你的机器上只装了 CUDA 11即使把 SDK 路径改成 10.2 的样子实际库文件还是不会出现 102 结尾的 DLL。所以不能用兼容版本做“障眼法”。4.3 Python 环境问题现象Python 安装 wheel 成功但 import tensorrt 报 ModuleNotFoundError 或者 DLL 加载失败且前面 PATH 检查都没问题。这时候先看 Python 位数。TensorRT 7.0 的 wheel 只支持 64 位 Python如果你用的是 32 位 Python即使你完美安装import 也会报错。在命令行里运行python -c import sys; print(64 if sys.maxsize 2**32 else 32)输出 64 才行。如果是 32去 Python 官网下载 64 位版本重装解释器。再看版本号。TensorRT 7.0 官方 wheel 支持 cp35、cp36、cp37 三种不支持 cp38 及以上。如果你用 Python 3.8 或者 3.9即使把 wheel 改名也无法安装因为 pip 也会拒绝。要么换 Python 3.7要么换对应新版本的 TensorRT。从项目历史看TensorRT 7.2 开始才支持 Python 3.8所以别跟版本较劲。第三个可能性是虚拟环境隔离问题。conda 创建的虚拟环境默认不继承系统 PATH 里的内容TenserRT 的 DLL 可能搜不到。解决方案有两个一是把 CUDA bin 和 TensorRT lib\x64 路径加入虚拟环境对应的激活脚本二是在每次使用前用set PATH%PATH%;C:\TensorRT-7.0.0.11\lib\x64临时追加路径。我个人更喜欢第二种简单直接不污染全局变量。还有一个很少人提到但会被坑到的情况如果你机器上装了一个叫 PyCUDA 的库它自带 CUDA 运行时 DLL版本可能跟 TensorRT 依赖的不一致。有时候 import tensorrt 会先加载 PyCUDA 的 cudart 版本导致后续执行崩溃。遇到这种问题建议在验证环境里conda remove pycuda或者不 import pycuda保持环境干净。4.4 模型转换阶段的坑严格来说这个问题不属于安装但很多人在安装完成后会立刻遇到专门写一节。TensorRT 7.0 发布于 2019 年对深度学习模型算子的支持度远不如现在的新版本。如果你拿一个较新的 ONNX 模型尤其是包含大量动态 shape、注意力机制、LayerNorm 等算子的模型去解析很可能报 “Unsupported operator” 错误。这不代表 TensorRT 没装好而是版本太老。通常的解决办法有用 onnx-simplifier 简化模型把不支持的算子拆解成 TensorRT 认识的基础算子。检查模型导出的 opset 版本。TensorRT 7.0 对 ONNX opset 9/10 支持相对好opset 11 会出现部分不支持的情况建议导出时降低 opset。如果只是做 FP16 推理先不用自定义 plugin因为 plugin 开发涉及 C 和 CUDA 知识工作量不小。如果模型必须原样支持建议换用更新的 TensorRT 版本但要注意 CUDA 版本同步升级。我在那次实时识别项目中最后是靠简化 ONNX 和切换到更合理的模型结构才跑通的。等 8.x 系列出来之后很多旧问题自动消失了。所以如果你不是为了兼容某个旧产品建议直接考虑更高版本。5. 一些来自实操的额外提醒写到最后分享几个环境管理上的习惯。安装 TensorRT 这类依赖链很长的库最忌讳的就是“装完就行”的心态。我在实际使用中每次都会先把手头的显卡驱动、CUDA 版本、cuDNN 版本、TensorRT 版本、Python 版本列成一个表贴在工程目录的 README 里。这看起来多花了五分钟但后面排查问题的时候能省下几个小时。另一个习惯是尽量区分“系统环境”和“项目环境”。TensorRT 7.0 更适合放在系统层面因为它本身是 C 库Python 绑定只是桥梁。如果你在一台机器上同时开发多个项目建议不要频繁覆盖系统里的 CUDA/cuDNN/TensorRT 版本而是用 docker 或者多块 GPU 环境隔离版本的冲突。Windows 下虽然没有原生容器但你可以给不同项目写不同的环境变量批处理脚本启动项目前执行一遍也能起到类似的效果。安装 TensorRT 7.0 这件事本身不复杂复杂的是版本矩阵。只要版本对齐了剩下的操作基本就是解压、配 PATH、验证三步。希望这篇笔记能帮你在 Windows 上更快跑通第一个 TensorRT 推理程序少走我当年走过的弯路。