简介这是TensorRT 7.1.3.4在Windows10 64位系统下的完整安装资源配套CUDA 11.0与CUDNN 8.0。TensorRT是NVIDIA推出的高性能深度学习推理优化库通过层融合、量化、动态形状等技术将神经网络编译为高效执行引擎特别适合需要低延迟、高吞吐的实时AI场景如自动驾驶、视频分析、语音识别等。资源包共364个文件大小约650MB包含头文件、C源码、Visual Studio解决方案、Python脚本、预编译dll与lib库以及whl安装包覆盖从模型导入、编译到部署的完整开发环节。同时附有PDF文档、Markdown说明和示例模型文件方便开发者快速对照学习。该版本支持TensorFlow、PyTorch等主流框架的模型转换适合正在搭建WindowsCUDA11.0推理环境的深度学习工程师使用。目前已有977人学习下载。1. 为什么专门挑 TensorRT 7.1.3.4CUDA 11.0 和 cuDNN 8.0 环境下的推理加速选型做深度学习部署的人早晚会在 Windows 上碰到一个叫 TensorRT 的库。它不是解压完就能自动把模型跑快的黑匣子而是一套对编译环境和依赖版本极其挑剔的推理加速工具链。在我处理过的几个项目里只要机器的 CUDA 是 11.0、cuDNN 是 8.0TensorRT 7.1.3.4 就是这个组合下最稳的配比——新版本 TensorRT 看起来算子更全、文档更漂亮但驱动、编译器和依赖库都会跟着升级反而让不少老项目直接翻车。这篇笔记会把 7.1.3.4 的下载、解压、环境变量、trtexec 验证、ONNX 转引擎的完整路径走一遍顺带把 Windows 上最容易踩的 DLL 加载、路径长度、算子兼容问题逐条点破。2. 版本边界为什么 7.1.3.4 必须搭配 CUDA 11.0 和 cuDNN 8.0很多开发者下载时只盯着数字大小以为 TensorRT 8.x 一定比 7.1.3.4 强。但如果你手头的运行环境已经围绕 CUDA 11.0 搭好那 7.1.3.4 反而是更值得用的版本。这系列在引擎构建和反序列化阶段都会检查 CUDA 和 cuDNN 的版本配置不一致时轻则性能回退重则直接拒绝加载引擎。下面把版本边界和包结构讲清楚。2.1 版本矩阵为什么不是 8.x 也不是 7.2先看一组我在实际部署时反复确认过的版本对应关系依赖项推荐配置操作系统Windows 10 64 位x86_64显卡驱动451.xx 或更高但不需要强制追新CUDA Toolkit11.0.xcuDNN8.0.x对应 cudnn64_8.dll引擎文件.engine / .plan 均由 7.1.3.4 生成这个组合的边界很明确CUDA 11.0 的 Runtime 被 7.1.3.4 的库文件直接依赖cuDNN 8.0 又决定了部分卷积算子能否走 Tensor Core 优化路径。如果你换成 cuDNN 8.1 或更高不代表一定出错但某些预编译的插件和示例工程在加载时会对不上符号最后表现为莫名其妙的段错误或 DLL 加载失败。到了 7.2 和 8.x 时代官方对算子支持范围扩大了可是要求也随之提高比如更晚版本的 CUDA 11.2 Update、cuDNN 8.2。如果项目要在不同单位的机器上迁移别人机器上的 CUDA 不见得能同步升级。这篇文章基于一个很现实的前提与其为了一个新算子去逼着整条生产链升级不如把模型老实地切成支持范围内的算子组合用 7.1.3.4 先跑通推理。2.2 解压包结构bin、include、lib、targets 各放什么下载下来的 zip 文件名称已经写明了全部关键信息TensorRT-7.1.3.4、Windows10、x86_64、cuda-11.0、cudnn8.0。解压之前建议把目标路径固定在根目录下比如 C:\TensorRT不要解压到桌面或网盘同步目录里否则后面前后路径问题会把你逼疯。Expand-Archive -Path .\TensorRT-7.1.3.4.Windows10.x86_64.cuda-11.0.cudnn8.0.zip -DestinationPath C:\TensorRT Get-ChildItem -Recurse -Depth 1 -Directory C:\TensorRT\TensorRT-7.1.3.4解压完成后第一层目录结构大概是这样的bin存放 trtexec.exe 以及若干运行时动态库trtexec 是后面验证安装和转换引擎的核心工具includeC API 的头文件最常用的是 NvInfer.h、NvOnnxParser.h、NvUtils.hlib存放 nvinfer.dll、nvonnxparser.dll 以及对应的导入库 .libsamples示例工程和编译脚本7.1.3.4 的 zip 里通常只带部分样例的源码targets给某些跨平台构建系统准备的目标目录Windows 下多数项目用不到但不建议删我一般会把整个 TensorRT-7.1.3.4 文件夹原样保留只在 PATH 里指到它的 lib 目录。有人为了省事把 lib 里的 DLL 全部拷贝到 System32短期能跑但版本一旦和 cuDNN 错位排查时连个退路都没有。还需要注意一点bin 目录下的 trtexec.exe 是 64 位程序不要放在带空格和中文的路径里。比如 C:\Program Files 这种路径虽然不算致命但配合后述长路径问题时会产生非常难排查的失败现象。3. Windows 10 上部署 TensorRT 7.1.3.4环境变量、链接库与 trtexec 验证这一章解决两个实际诉求只想用 trtexec 工具完成验证和转换把 TensorRT 集成进自己的 C 工程。两种场景的第一步都一样先把运行环境准备好但很多人只做了一半就去跑命令然后被各种 DLL 报错卡住。3.1 环境变量PATH 里要放什么放错会怎样TensorRT 的 DLL 依赖 CUDA Runtime 和 cuDNN所以 PATH 里至少要包含 TensorRT 的 lib 目录和 CUDA 的 bin 目录。某个环境你已经装了 CUDA 11.0但它的 bin 目录不在 PATH 里那就算 TensorRT 路径配好了trtexec 还是会提示找不到 nvinfer.dll 依赖的某些符号。常见做法是打开系统环境变量编辑界面手动添加两个路径。我更喜欢用 PowerShell 一次性配置$trtRoot C:\TensorRT\TensorRT-7.1.3.4 [Environment]::SetEnvironmentVariable(Path, $env:Path ; $trtRoot \lib, User) # CUDA 的安装路径各机器不同这里只是示例 $cudaBin C:\CUDA\v11.0\bin [Environment]::SetEnvironmentVariable(Path, $env:Path ; $cudaBin, User) $env:Path $env:Path ; $trtRoot \lib这段代码里第一处是持久化到用户级 PATH第二处补上 CUDA 的 bin 目录最后一句只对当前 PowerShell 进程生效适合想立刻验证的场景。需要注意User级别的变量修改不会自动刷新已经在运行的其他程序如果是命令行窗口务必关掉重开或者直接复制粘贴最后一行手动刷新当前会话。放错路径的典型现象是trtexec 能启动但进入实际推理阶段时抛异常原因往往是 PATH 中同时存在多个版本的 cuDNN系统优先加载了旧版本。所以 PATH 的顺序不要乱新加的路径排在前面不一定是好事反而应该让明确版本的那条 cuDNN 路径靠前。3.2 用 trtexec 验证安装版本信息与错误判断部署完成后的第一个验证动作就是运行 trtexec 的版本参数。trtexec --version正常情况下输出会体现 TensorRT 版本号看到 7.1.3.4 字样就说明主程序已经能找到库文件。如果这里直接报找不到 nvinfer.dll不要急着怀疑下载包损坏先回来检查 PATH 里是否真有 lib 目录以及终端是否在 PATH 修改之后启动。还有一种情况是能打印版本号但随后提示缺少 cudart64_110.dll 或 cublas64_11.dll 这类 CUDA 组件。这说明 CUDA 的 bin 目录没进 PATH或者当前 Load 到的 CUDA 版本不是 11.0。你可以按照 3.1 的代码补上路径也可以临时把 CUDA 的 DLL 复制到 trtexec.exe 所在的 bin 目录后者只适合做快速验证不适合当长期方案。3.3 在 C 工程中引用 TensorRTinclude、lib、dll 三段式配置如果你要在一个已有的 C 推理服务里集成 TensorRT正确姿势是配置好头文件目录、库目录和运行时 DLL 三件事。先看一段最简代码#include NvInfer.h #include NvOnnxParser.h static class Logger : public nvinfer1::ILogger { void log(nvinfer1::Severity severity, const char* msg) noexcept override { if (severity ! nvinfer1::Severity::kINFO) { printf([TRT] %s\n, msg); } } } gLogger; int main() { nvinfer1::IBuilder* builder nvinfer1::createInferBuilder(gLogger); if (!builder) { printf(builder create failed\n); return -1; } // 使用完记得释放7.1.3.4 的 API 下直接 delete builder 即可 delete builder; return 0; }这段代码做的事情很直接创建了一个继承自 ILogger 的日志类然后调用 createInferBuilder 得到构建器。其中 Logger 类里的 printf 会导致控制台被日志刷屏实际产品里可以把日志等级收紧只保留错误级。createInferBuilder 是 7.1.3.4 的 API 入口8.x 之后改成了 BuildConfig 的额外步骤这也是我坚持用 7.1.3.4 的一个次要理由。在 IDE 的链接器设置里库目录指向解压后的 lib 文件夹附加依赖项写成nvinfer.libnvonnxparser.lib运行时别忘了把 nvinfer.dll 和 nvonnxparser.dll 放到 exe 的输出目录或者确保 lib 目录在 PATH 中。否则编译能通过程序启动时照样报找不到 DLL。4. TensorRT 7.1.3.4 的避坑指南五个常见问题与排查下面这几条都是我在 Windows 环境里实际处理过的问题按现象、原因、解决三步写方便你直接照着排查。4.1 现象trtexec 启动直接报错找不到 nvinfer.dll后记中 7.1.3.4 的 lib 目录本身就在包内但很多人解压后直接双击运行 bin 下的 trtexec.exe忽略了它依赖同目录或 PATH 下的 DLL。原因其实就一条Windows 加载 DLL 的顺序是先看程序所在目录再看系统目录最后看 PATH。如果你的 bin 目录里没有 nvinfer.dll而 PATH 也没配它就只能报错。解决方法是两种任选把 lib 目录加入 PATH并且重新打开终端或者把 lib 下的全部 DLL 复制到 trtexec.exe 同目录。第二种方法适合临时使用但会让包结构变得混乱我一般不推荐。4.2 现象ONNX 模型路径很深trtexec 转换时卡住或静默失败某次我在部署语义分割模型时把 ONNX 文件放在了一个共享工作目录下完整路径超过了两百个字符。trtexec 启动后没有任何日志输出等了很久也没有结果看上去像死锁。原因就是 Windows 的 MAX_PATH 限制路径太长导致文件句柄打开失败而 trtexec 在某些版本下没有把这类错误及时打到控制台。解决方法是把模型复制到短路径下比如 C:\Models\model.onnx并且确认路径里没有非 ASCII 字符。如果确实要放在深层目录需要批量操作前先开启系统长路径支持在注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem 下把 LongPathsEnabled 设为 1然后重启系统。即便如此trtexec 的 OnnxParser 在 7.1.3.4 里对长路径的兼容仍不算好最省事的方案永远是短路径。4.3 现象推理性能忽高忽低部分算子没有走 Tensor Core某次我把 cuDNN 从 8.0 升级到了 8.2TensorRT 7.1.3.4 构建引擎时没有报错但实际推理耗时比之前长了近一倍跑 profile 发现卷积层没有被自动选用更快的算法。原因就是 cuDNN 版本和 TensorRT 预编译的 Kernel 不匹配时引擎会退回到通用实现性能自然就崩了。解决方法是严格锁定 cuDNN 8.0.x并且卸载系统里其他版本的 cuDNN或者至少保证 PATH 里排在前面的是 8.0 对应的路径。把多个 cuDNN 版本混在同一个目录里是灾难性的建议让 cuDNN 的 DLL 躺在它自己的目录下不要复制进 System32。检查当前加载版本时可以用进程查看器看 nvinfer.dll 依赖链。4.4 现象ONNX 转引擎时报 Unsupported Operator这个报错是 TensorRT 入门者见到最多的。比如你用 PyTorch 1.8 导出的模型默认 ONNX 版本可能是 opset 13而 7.1.3.4 的 OnnxParser 对新 opset 支持有限某些算子如 GatherElements、GridSample 直接不在列表里。不要急着找插件先确认导出的 opset 版本。常见的解决办法是在导出 ONNX 时指定 opset_version11,因为 7.1.3.4 的算子覆盖以 ONNX opset 10 和 11 为基准。如果你必须用一个很新的算子那就只有两条路把该算子在模型图里拆掉或单独写成 TensorRT plugin。注意这里是先看 opset再看单个算子是否在支持清单里顺序不要反。4.5 现象同一份引擎文件换了一台机器后加载失败TensorRT 引擎文件和 CUDA 版本、GPU 架构强相关。你在自己的机器上生成的 .engine换到另一台 GPU 甚至不同驱动版本的机器上可能可以直接加载也可能报 GPU 架构不匹配。原因是在构建引擎时7.1.3.4 会为当前设备的 Compute Capability 固化 Kernel 代码。解决方法是让每台目标机器自己执行一次引擎构建或者你把构建流程做成启动时检查架构的编译服务。另一种做法是加载失败后用 trtexec --loadEngine 查看日志日志里会写清期望的 GPU 架构和设备实际架构。这里没有一劳永逸的银弹好的做法是引擎文件命名时带上 GPU 架构代号比如 sm_75 或 sm_80。5. 把 ONNX 模型转成 TensorRT 引擎trtexec 参数与转换流程跑通环境之后核心工作就是把模型从 ONNX 转成 TensorRT 的引擎文件。7.1.3.4 里最常用的命令行工具就是 trtexec,它既能做转换也能做基准测试关键参数和坑位下面拆开讲。5.1 基础转换命令fp16、workspace 与 batch 的取舍对一个静态 batch 的分类模型基本转换命令长这样trtexec --onnxmodel.onnx --saveEnginemodel.engine --workspace2048 --fp16 --batch1--onnx输入 ONNX 文件路径7.1.3.4 的 trtexec 可以直接解析 ONNX内部调用 NvOnnxParser--saveEngine输出引擎文件路径--workspace2048指定构建过程中最大可用显存单位 MB。这个值不是推理时的固定占用而是构建阶段给算子选择算法时的预算--fp16允许使用半精度浮点需要显卡支持 Tensor Core 或至少支持 FP16 指令--batch1指定 batch size如果模型本身是动态输入这个参数可能和 min/max shapes 有冲突以--workspace为例我见过有人把它调得非常大比如 8192结果构建时显存不够直接抛 bad_alloc。虽然这个参数越大越有可能选到更快算法但实际收益在 2048 之后就明显饱和。如果显存紧张调到 1024 甚至 512 也能出引擎只是延迟可能差几个百分点。构建阶段看的是显存不是显存余量提前用 nvidia-smi 看看可用显存再决定数值。--fp16开启后并不代表所有层都会变成 FP16。TensorRT 会分析网络结构把能安全转换的层转成半精度其余层保留 FP32。有些模型转 FP16 后精度掉得厉害这时候不能盲目关闭 fp16应该改成分层精度控制但那是更进阶的话题7.1.3.4 里可以先通过--fp16看一个整体收益。5.2 动态输入尺寸minShapes、optShapes、maxShapes 的写法很多 ONNX 模型的输入是动态尺寸比如目标检测的输入宽高不固定。7.1.3.4 支持动态 shape但需要在转换时明确三个档位trtexec --onnxmodel.onnx --saveEnginemodel.engine \ --minShapesinput:1x3x224x224 \ --optShapesinput:1x3x224x224 \ --maxShapesinput:4x3x224x224minShapes允许的最小输入尺寸影响 Kernel 选择时的下限optShapes优化参考尺寸TensorRT 会优先保证此尺寸下的性能maxShapes允许的最大输入尺寸决定显存规划上限这里最关键的是 input 这个名称它必须和 ONNX 图中的输入张量名字一致。你可以在导出 ONNX 时把输入名固定下来或者在转换前用工具查看 ONNX 的输入节点名。7.1.3.4 对动态 batch 的支持没有后面版本那么细腻如果你要支持 batch1 和 batch4 两档建议把 optShapes 设为实际服务中最常用的档位而不是取中间值。这个细节很多人忽略结果就是固定 batch 时性能正常动态 batch 时掉速明显。5.3 转换失败时的排错顺序从日志到算子检查转换失败不一定是环境问题也可能是模型结构问题。我的排查顺序通常跟着日志走trtexec --onnxmodel.onnx --saveEnginemodel.engine --verbose --batch1加上--verbose后日志会详细打印 OnnxParser 解析到某个节点时发生的警告和错误。看到 Unsupported Operator 时第一步是定位是哪个节点然后回 ONNX 图里去找父节点。第二步看这个算子的输入输出维度有时不是算子不支持而是输入数据形状不符合 TensorRT 的预期。第三步把该算子的前一层输出用 ONNX Runtime 打印出来对比 TensorRT 的中间结果逐步定位。一个经常被忽略的做法是分块转先把模型从中间某一层截断转一个简化版引擎成功后再加回后半段。这种做法虽然笨但在 7.1.3.4 时代比起翻算子文档反而更快找到问题范围。等确认某个算子不支持后再考虑插件或者重新设计网络结构。6. 用 trtexec 的层性能剖析定位瓶颈三个必须看的输出字段引擎跑起来之后如果性能不达标第一件要做的事不是找代码问题而是看引擎内部的层耗时。trtexec 提供了一个非常直接的剖析接口trtexec --loadEnginemodel.engine \ --shapesinput:1x3x224x224 \ --iterations100 \ --dumpProfile \ --exportProfilelayer_profile.json这个命令使用--loadEngine加载已生成的引擎--shapes指定实际推理输入尺寸--iterations100保证统计量足够稳定最后把每一层的耗时剖析结果导出到 JSON 文件。打开 layer_profile.json 后虽然不同子版本的字段名略有差异但核心就是三个信息层名、耗时、类型。简化后的结构大致是这样[ { Name: conv1_1, Type: Convolution, timeMs: 2.318 }, { Name: conv2_1, Type: Convolution, timeMs: 4.002 } ]第一个必看字段是 timeMs这是每一层的平均耗时。不要只看端到端总耗时那个数值能反映整体快慢但无法告诉你瓶颈在哪。第二个字段是 Type它决定你是否需要关注算法的选择策略。如果在 profile 里发现某个 Convolution 耗时异常高先看该层是不是 FP32如果周边层都转成了 FP16唯独它没有这就是精度退化的典型信号。第三个字段其实不只是一个字段而是卷积层的输入输出通道数和核大小trtexec 的 profile 输出有时不会直接给出需要你对照网络结构去推断。当发现某层耗时占总耗时的 30% 以上时我先会去检查它的通道数是不是特别大然后决定修正模型结构或调整 workspace 重新构建。注意这里的 timeMs 是单层平均耗时包含了数据搬运但排除了上下文切换它和端到端耗时的关系不是简单相加只能用作相对比较。这套剖析方法在 Windows 上最实用的场景是部署性能从 3ms 掉到 10ms 时。你不需要一上来就怀疑是系统调度问题先看 profile 里哪几层的耗时占比再顺着层名回到 ONNX 图里找对应节点。层名在 TensorRT 里不一定和 ONNX 节点名完全一致但 7.1.3.4 通常会在名字里保留下划线分段能对上七八成。有一次我部署视频检测模型时端到端延迟从 1.8ms 涨到了 3.2ms怎么看都像是驱动被系统更新搞乱了。后来跑了一次 dumpProfile发现瓶颈是一个 3x3 卷积层的耗时翻了倍原因是该层输入尺寸不是对齐的TensorRT 没有选用 Winograd 算法。修正方法不是重装驱动而是把输入 pad 到对齐尺寸后重新构建引擎耗时直接回到 1.9ms。从那以后我每次拿到新模型都强制走一遍层剖析流程把 profile 文件存成基线再去做后续优化。这个习惯帮我省掉了大量靠猜的部署问题希望帮到你。本文还有配套的精品资源点击获取