企业官网建设流程全解析

TensorRT 7.0在Windows环境的安装方式，如果只看NVIDIA官方文档，其实连下载、解压、配置PATH、pip install这几个步骤都能找到，麻烦在于它们分散在不同章节里，而且中间夹着大量面向Linux的说明。我最早照着整本Getting Started去装的时候，花了整整一下午才把依赖版本、环境变量和Python接口全部理顺。这篇文章算是我把官方文档精简之后、再结合实测结果的一份Windows安装笔记，目标是让已经装好CUDA的人照着二十分钟内跑通。

这篇内容适合谁？一类是在Windows上做模型推理部署、想把训练好的模型用TensorRT编译加速的Python开发者；另一类是准备用C++集成TensorRT、但被官方文档里那句"configure the environment"搞得一头雾水的同学。看完你至少能搞明白三件事：装之前要核对哪些依赖，解压之后目录该怎么用，以及为什么照官方文档做完还会遇到DLL找不到这类问题。

1. 安装前先弄明白：TensorRT 7.0到底装的是什么

很多人装TensorRT，装完发现能用pip import了就以为大功告成，其实是不对的。TensorRT不是一个单纯的Python库，它是一整套推理优化组件。官方文档把这点写在很前面，但写得比较分散，我帮你把关键信息抽出来。

1.1 三个核心组件，缺一个后面都会出问题

TensorRT由三层组成：核心库（Core Library）、插件（Plugins）、编程接口（Python和C++绑定）。核心库就是那一堆DLL，负责模型解析、网络定义、层融合、精度校准和推理执行；插件库是给TensorRT不支持的算子预留的扩展位，比如某些自定义激活函数；编程接口是你实际用来构建引擎和做推理的那一层。

拿Windows版解压包来说，lib目录里那几十个文件分别对应这三层。最核心的几个你要认识：nvinfer.dll是核心库主DLL，nvinfer_plugin.dll是插件库，nvonnxparser.dll负责把ONNX模型解析成TensorRT网络。如果你只用Python，import tensorrt加载的也是这一堆底层DLL，不是纯Python实现。

所以在概念上先建立这个认知：你在Windows上安装TensorRT，实际做的是把这一套DLL和头文件放到一个固定位置，再让系统和程序能找到它们。这不是一次双击安装包就能完成的事，而是把"包"解压出来、手动接入环境的过程。

1.2 Windows版本和Linux版本的关键差异

官方文档默认优先写Linux，Windows用户经常被迫去猜。两个平台差别最大的地方在两点：

第一，分发形式。Linux通常用deb/rpm或者tar包，tar包解压后还要用ldconfig刷新动态链接库缓存；Windows没有这个机制，而是要求你把含DLL的目录手动加进PATH环境变量。官方文档给的步骤很少，但"手动加PATH"这一步恰恰是Windows下绝大多数启动失败的原因。

第二，DLL和可执行文件的存放位置。Linux习惯把库放在lib目录，可执行文件放在bin目录，然后依赖rpath或ldconfig；Windows的zip包也保持了bin和lib分离的布局，但Windows加载DLL时的搜索顺序是从应用程序所在目录到PATH目录，所以bin里的trtexec.exe要找到lib里的nvinfer.dll，就必须把lib目录也加进PATH。这个细节官方文档提了一句，但没强调，导致很多人只加了bin目录。

顺便说一句，官方文档里的"Windows 10"指的系统版本一般要求1809以上，老版本系统上跑TensorRT有时会出现莫名其妙的权限或依赖问题，有条件的话操作系统尽量保持更新。

1.3 先自查GPU算力和驱动状态

TensorRT 7.0对硬件的最低要求是支持CUDA的NVIDIA GPU，官方写明需要Maxwell架构（计算能力5.0）及以后。这意味着GeForce GTX 900系以上的卡基本都能装，但实际开发我更建议用GTX 10系以上，因为FP16和INT8相关的优化在这些卡上更稳定。

自查命令很简单，在cmd里执行nvidia-smi，确认驱动版本和GPU型号。驱动版本不要太老，TensorRT 7.0时代比较稳妥的是驱动411以上；如果你之前为了兼容别的框架升级到了最新驱动，基本不会有问题。这里常见误区是把驱动版本和CUDA版本搞混：nvidia-smi显示的CUDA Version是"最高可支持版本"，不代表你机器里已经装好了对应CUDA Toolkit。这是个很常见的判断失误，下面详细说。

2. 前置依赖核对：CUDA、cuDNN和Visual C++运行库

官方文档会把依赖列成一张表，但表格里的版本号经常容易被忽略。我做增量开发时，遇到的最多问题都集中在依赖不匹配上。

2.1 CUDA版本和TensorRT 7.0的对应关系

TensorRT 7.0.x系列官方支持CUDA 10.0、10.1和10.2，注意7.0.0.11这个初始版本不建议用CUDA 11.x，那是后几个小版本才开始支持的。我实际测试下来，CUDA 10.2是7.0这一代最稳的搭档，如果你没有其他框架强制卡的版本，直接选10.2。

为什么强调用nvcc -V验证？因为经常有人在系统里装了CUDA运行时（runtime版），但没装Toolkit（full版），或者反着装。运行TensorRT需要的是Toolkit里那套开发文件，尤其是编译C++接口时必须要nvcc和头文件。python层面虽然不直接用nvcc，但如果缺了CUDA运行时DLL，TensorRT的核心库加载会直接失败。

我建议装Toolkit的时候不要改默认安装路径。默认路径是C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v10.2，后面配置PATH、排查DLL问题都更容易。装到自定义路径不是不行，但所有第三方库默认去寻找的那些路径就找不到你了，徒增烦恼。

2.2 cuDNN的正确放置方式

cuDNN不是一个安装包形式的软件，它的压缩包里是cuda目录，里面包含bin、include、lib三个子目录。所谓"安装cuDNN"，其实就是把这几个目录里的文件合并到CUDA Toolkit的对应目录里。Copy方式如下：

把cuDNN包里的bin（含cudnn64_8.dll等）、include（含cudnn.h）、lib\x64（含cudnn.lib）分别拷贝到CUDA Toolkit安装目录的bin、include、lib\x64下。

这里有个经验：cuDNN的版本号不需要和CUDA完全一致，但注意cudnn64_8.dll里的"8"表示主版本，和TensorRT期望的主版本要匹配。TensorRT 7.0对cuDNN的最低要求，我记得是7.6.3；如果你图省事装了cuDNN 8.0，TensorRT也能正常工作。真正的问题出在机器里同时存在多个cudnn版本、目录混乱，程序找不到正确那个DLL，这个在后面的坑里展开。

2.3 Visual C++ Redistributable和系统环境

这一项经常被跳过，但它直接导致"缺少VCRUNTIME140.dll"这类报错。TensorRT 7.0的trtexec.exe和部分示例程序依赖Visual C++运行库，Windows 10在完全没有装过相关组件的情况下会缺这个。装一个最新的Microsoft Visual C++ Redistributable（x64）就能覆盖绝大多数情况。

如果你打算用C++接口开发，Visual Studio 2017或2019也建议装好，官方samples里提供的是VS2017格式的工程文件，2019会自动升级兼容。只跑Python则只需要Redistributable就行。

3. 下载与解压：把官方包里的文件真正用起来

这一章看起来没什么好说的，但实际操作中下载入口、包名识别、解压目录位置三个环节都可能卡人。

3.1 下载入口与安装包识别

TensorRT不能直接搜索页下载，需要注册NVIDIA的开发者账号然后登录下载页面，选择TensorRT 7.0对应的版本列表。在列表里找到Windows版本，包的命名类似TensorRT-7.0.0.11.Windows10.x86_64.zip，体积在400MB左右。下载页有时还会列出其他平台包，注意别点成Linux的.tar.gz。

识别包名时看两点：一是版本号，二是平台标志。Windows的zip包一定带Windows10和x86_64字样。如果你拿到的是tar.gz，那是瞒着Windows装不上的版本，即使强行解压能用，依赖库的文件组织方式也不同，不值得折腾。

3.2 解压后目录结构逐个说清楚

把zip包解压到一个固定目录后，你会看到这些文件夹：

重点说一下lib目录。它里面既有DLL又有.lib文件，DLL是程序运行时加载的，.lib是C++编译链接时用的。Python用户只需要关注DLL是否能被找到，C++用户需要把这个目录配置到VS的库目录里。

3.3 解压位置的三条实操经验

第一，路径不要有中文，不要有空格。D:\TensorRT-7.0.0.11比C:\Users\张三\我的 TensorRT 目录要省心得多，虽然现代Windows大多能处理空格路径，但在CMake、脚本、环境变量拼接时，空格经常会让人崩溃。

第二，不要解压到需要管理员权限才能读写的目录。比如Program Files。TensorRT是"绿色解压"版本，不需要写入，但运行时要读取，某些工具还会在目录里生成缓存文件。放在Users目录下或者盘符根目录，权限问题最少。

第三，解压完成后，把整个文件夹的只读属性去掉。zip解压出来的文件有时会保留只读标志，虽然多数场景不影响，但在后续某些样例脚本写文件时会莫名报错，提前处理掉可以省一个坑。

4. 环境变量配置：Windows上最容易翻船的一步

官方文档在这个环节只给了一句"Add TensorRT to your PATH"，但实际要做的比一句话多。

4.1 PATH要加两个目录，而不是一个

我见到有人只把bin目录加进PATH，结果trtexec双击没反应或者提示找不到DLL。原因前面提过：要找的DLL在lib里。正确做法是把下面两个路径都加进PATH：

D:\TensorRT-7.0.0.11\lib D:\TensorRT-7.0.0.11\bin

操作方式是在"此电脑"右键属性 -> 高级系统设置 -> 环境变量 -> 系统变量里的Path，编辑新增两行。注意修改完要新开一个cmd窗口验证，旧的窗口不会刷新环境变量。这一步很多人栽过，改完变量后继续用旧终端跑命令，发现路径没生效，以为改错了。

如果你不想手动点到环境变量面板，也可以在cmd用setx追加，但setx有个坑是截断超长PATH，手动编辑更安全。

4.2 新建系统变量TENSORRT_ROOT

除了PATH，建议新建一个系统变量：

变量名：TENSORRT_ROOT 变量值：D:\TensorRT-7.0.0.11

这个变量不是运行时必需的，但它是TensorRT自身示例工程和很多第三方集成项目会读取的标准变量。官方samples的CMakeLists里查找TensorRT时，常常先看TENSORRT_ROOT。你现在配置好，后面编译样例或者集成到一些开源推理框架时会顺很多。

4.3 验证配置是否生效

新开一个cmd，依次执行：

echo %TENSORRT_ROOT% where trtexec trtexec --help

echo能打印出你刚设置的路径，说明系统变量生效。where能找到trtexec，说明PATH里的bin目录生效。trtexec --help能正常输出大段帮助信息，说明它在启动时找到了配套DLL——如果这步能过，运行时依赖基本就通了。

这里我不建议直接拿trtexec去跑一个很大的ONNX模型做验证，第一次跑官方自带的手写数字示例就行。不过更省事的验证留到Python那步一起做。

5. Python接口安装：pip install之后为什么还要配环境变量

TensorRT 7.0的Python接口在官方包里有两种提供方式，一种是在python目录下放着wheel文件，另一种是官方文档建议的pip install，实际后者也是从本地wheel装。Windows用户请认准前者，不要用pip去网上搜tensorrt安装。

5.1 选择与Python版本匹配的wheel文件

解压包的python目录下会有多个wheel文件，命名类似于：

tensorrt-7.0.0.11-cp36-cp36m-win_amd64.whl tensorrt-7.0.0.11-cp37-cp37m-win_amd64.whl tensorrt-7.0.0.11-cp38-cp38m-win_amd64.whl

cp37表示Python 3.7，cp38表示Python 3.8，以此类推。先执行：

python --version python -m pip --version

确认Python版本和pip可用。我建议优先用Python 3.7，TensorRT 7.0时代官方对这个版本的支持最成熟，我在3.6和3.8上也装过，都能用，只是碰上其他兼容问题的概率会略高一些。如果机器里同时有多个Python，安装时最好用python -m pip而不是pip，避免装到另一个Python的环境里。

5.2 安装与import验证

在Python目录下执行：

python -m pip install tensorrt-7.0.0.11-cp37-cp37m-win_amd64.whl

这个wheel会把Python层的绑定文件装进site-packages，但你需要注意一个容易误解的点：wheel通常不会把nvinfer.dll那一堆核心库完整复制到site-packages，或者即使复制了部分DLL，真正运行引擎时仍需要完整插件库。所以第4章配置的PATH里保留lib目录是必须的，这也是为什么"pip install完就万事大吉"的观点在Windows上不成立。

验证导入：

python -c "import tensorrt as trt; print(trt.__version__)"

能打印出7.0.0.11的小版本号，说明Python绑定层加载成功。如果报ImportError，比如找不到指定的模块，90%是PATH里的lib目录没配好或cuDNN的DLL缺失。

5.3 跑一个最小可用的引擎构建

import成功还只能说明绑定层正常，我更建议做一次最小的引擎构建验证，确认底层DLL能协作干活：

import tensorrt as trt logger = trt.Logger(trt.Logger.WARNING) builder = trt.Builder(logger) flag = builder.platform_has_fast_fp16 print("TensorRT", trt.__version__, "FP16 support:", flag)

这段代码会初始化核心库并创建一个Builder实例，如果这里不抛异常，说明核心库、插件库和CUDA运行时都配合正常。接着你可以用官方sample里的onnx mnist示例走一遍从ONNX解析到engine序列化的完整流程，这才是真正确认"安装完成"的标志。

C++用户在这个环节更要重视：打开samples目录下的解决方案文件（VS2017格式），先用TENSORRT_ROOT指向你的解压目录，然后编译一个官方示例工程。成功编译并运行其中一个sample，比任何"好像装好了"的感觉都可靠。

6. 安装过程中真实的坑，按排查顺序排列

最后整理几个我在Windows环境里实际遇到的坑。按从高频到低频的顺序排，方便你对照排查。

6.1 DLL加载失败：第一步就卡死的典型原因

症状是执行trtexec --help或import tensorrt时提示找不到cudart64_102.dll、cudnn64_8.dll、nvinfer.dll等具体文件名。这类报错其实定位最容易：看清楚缺的是哪个DLL，然后用where命令或Everything搜索确认它存在哪个目录，再把那个目录加进PATH。

这里有个细节：TensorRT的lib目录里没有CUDA运行时DLL，cudart开头的文件在CUDA Toolkit的bin目录里，cudnn开头的文件在cuDNN拷贝后的CUDA bin目录里。如果报缺cudart64_102.dll，说明PATH里没有CUDA安装目录下的bin；报缺cudnn64_8.dll，说明cuDNN没拷贝成功或拷贝到了别的版本目录。

提示：检查PATH时要注意，有些机器里装了多个CUDA版本，环境变量里同时存在v10.2和v11.x的路径，顺序靠前的会被优先加载。版本错乱引发的DLL加载问题往往就是这样产生的。

6.2 CUDA版本和TensorRT包不匹配

这类问题不会有"缺文件"这种明确提示，而是程序启动后直接崩溃，或者构建引擎时报"invalid device function"之类看不懂的错。原因多半是TensorRT 7.0碰到了CUDA 11的环境。

排查思路：先确认你系统PATH里排在前面的CUDA版本，再确认TensorRT包名和lib目录里DLL的名字。lib里如果出现cudart64_110.dll，说明这个TensorRT包是面向CUDA 11的版本，和7.0初始版预期不匹配。建议的做法是统一卸载干净，只保留一个CUDA版本。多个CUDA版本共存不是不行，但需要非常严格地管理PATH顺序，新手不建议尝试。

6.3 老驱动或老GPU架构引起的trtexec崩溃

有些场景下trtexec能启动，但一加载模型就崩溃，报错可能指向某个.dll也看不出问题。查看驱动版本会发现卡特别老，比如官方要求Maxwell架构，但你手里的是一张非常远古的卡，或者驱动停更太久，新CUDA运行时在驱动层拿不到完整的算子支持。这种情况只能换硬件，或者尝试用低精度模式跑更小的模型。

还有一个相对少见的坑：笔记本电脑上装了TensorRT但用的是NVIDIA的Optimus双显卡模式，程序默认跑在集显上，结果TensorRT直接无法识别GPU。解决办法是去显卡控制面板，为trtexec.exe或python.exe指定使用独显。

6.4 多版本TensorRT共存的PATH污染

这个问题在开发机上非常常见：之前为了其他框架装过TensorRT 6，现在又装了7.0，两个解压目录都在PATH里。程序运行时按PATH顺序找DLL，先找到哪个版本就用哪个版本，于是你明明import的是7.0的Python包，底层实际加载的却是6.0的核心库，就会出现各种诡异行为。

做法很简单：只保留一个TensorRT版本的PATH项。如果多个项目需要不同版本，建议不要共用系统PATH，而是按项目写启动脚本，在脚本里临时set PATH="D:\TensorRT-7.0.0.11\lib;%PATH%"，用完不污染全局。

我在自己机器上完整走完一遍流程之后最大的感受是：TensorRT的安装难点从来不在下载那一步，而在依赖版本核对和环境变量这些不写进README的细节里。如果你按第2章认真核对依赖、第4章配好PATH、第5章做一次完整的engine构建验证，一次跑通的概率非常高。最后再分享一个不起眼但实用的习惯：装好之后先别急着优化自己的模型，把官方手写数字示例完整跑一遍，确认引擎能构建能序列化，再去碰那些又大又复杂的模型。这个先后顺序能帮你把"安装问题"和"模型兼容问题"干净地切开，排查时少掉一半的麻烦。