简介TensorRT 7.2.3.4 是 NVIDIA 推出的高性能深度学习推理优化库该版本面向 Windows10 x86-64 平台匹配 CUDA 11.0 与 cuDNN 8.1主要用于解决深度学习模型在 GPU 上推理速度慢、延迟高的问题适合自动驾驶、视频分析、智能物联网等实时推理场景。压缩包内共 367 个文件约 493MB包含约 67 个头文件与 47 个 C 源码便于开发者理解 API 并二次开发50 个 batch 校准文件和 3 个 wts 权重文件用于模型量化13 个 Python 脚本辅助模型转换与自动化处理26 个 Markdown 与 8 个 PDF 文档提供使用说明还带有 Visual Studio 工程sln/vcxproj、lib/dll 动态库、onnx/caffemodel/uff 等模型文件基本构成一套完整的 TensorRT 部署工具链。目前已有 186 人学习下载。开发者可借此快速搭建开发环境参考示例工程与官方文档把 Caffe、TensorFlow、ONNX 等模型转换为 TensorRT 引擎。再通过层融合、精度校准、多 GPU 分配等手段提升推理性能降低显存占用在实时业务场景中落地高效 AI 服务。1. TensorRT-7.2.3.4.Windows10.x86-64.cuda-11.0.cudnn8.1.zip 到底在装什么先给一个反直觉结论TensorRT 7.2.3.4 这个包根本不需要 setup 安装解压即用。文件名里那串TensorRT-7.2.3.4.Windows10.x86-64.cuda-11.0.cudnn8.1.zip已经把兼容性边界写死在名字上了——它绑定 CUDA 11.0 和 cuDNN 8.1只能在 64 位 Windows 10 环境里跑。很多人在这一步栽跟头不是因为不会解压而是没搞明白 TensorRT 和 CUDA、cuDNN 三者是独立的。TensorRT 只是推理加速库它依赖 CUDA 运行时和 cuDNN 的 DLL但不会替你装驱动也不会覆盖你已有的 CUDA 安装。这篇文章解决三类实际问题老项目被锁在 CUDA 11.0 上想上 TensorRT新机器要装一个和现有 CUDA 版本匹配的 TensorRT以及装完之后怎么用 trtexec 和 Python API 把模型转成 engine 并跑起来。适合在 Windows 上做推理优化、部署的工程师如果你是拿 Linux 服务器跑推理这个 zip 包不适用去找对应平台的 tar 包。开始之前先确认一件事你的显卡驱动版本是否支持 CUDA 11.0这个决定你后面要不要装低版本 CUDA。2. 先对齐运行环境CUDA 11.0 与 cuDNN 8.1 的版本匹配检查TensorRT 不会做系统级登记它只是在你跑推理时加载 CUDA 和 cuDNN 的动态库。所以环境对齐是第一步也是最容易忽略的一步。Windows 上常见的问题是驱动太新CUDA 版本太老或者 CUDA 装好了cuDNN 版本不对导致 TensorRT 加载cudnn64_8.dll失败。这一章把检查方法和安装顺序讲清楚。2.1 查看 cuda cudnn 版本的三条命令先看你机器上真实的 CUDA 运行时版本而不是看环境变量里写的是什么。打开 CMD依次执行nvidia-smi输出右上角的 CUDA Version 表示当前驱动支持的最高 CUDA 版本不代表你装了 CUDA Toolkit。如果这里显示的是 12.x而你项目里要求 CUDA 11.0显卡驱动本身是可以向下兼容运行时的但这取决于驱动分支。NVIDIA 从 CUDA 11 开始推行驱动新老兼容策略较新的驱动通常仍能运行 CUDA 11 的应用程序但个别专业卡和特挑驱动分支会有限制。nvcc --version这个命令输出的是 CUDA Toolkit 编译器版本。如果提示nvcc 不是内部或外部命令说明 CUDA Toolkit 没装或者没加入 PATH但 TensorRT 运行时不强制需要 nvcc它只依赖 CUDA 运行时库。你的机器上如果已经装了 CUDA 12再装 CUDA 11.0 需要手动处理 PATH 优先级常见做法是安装到不同目录然后在项目脚本里显式指定路径。再看 cuDNN 版本。Windows 上 cuDNN 是以文件形式存在的没有注册表信息需要打开目录确认type C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\include\cudnn_version.h如果文件不存在说明你的 cuDNN 只是简单拷贝或者没装全。这个头文件里会定义CUDNN_MAJOR、CUDNN_MINOR、CUDNN_PATCHLEVEL三个宏对应 8.1.x 中的 8、1、x。老版本 cuDNN 可能没有这个头文件只有cudnn.h那就直接看文件版本属性右键cudnn64_8.dll在详细信息里查看文件版本。2.2 安装顺序与版本对应关系组件版本作用安装方式显卡驱动不低于 451.x提供 CUDA 驱动 APIexe 安装全局生效CUDA Toolkit11.0提供 nvcc 与运行时库exe 安装自定义目录cuDNN8.1深度神经网络加速库解压后拷贝到 CUDA 目录TensorRT7.2.3.4推理优化与 engine 生成解压 zip 即用安装顺序我一般固定为驱动 → CUDA Toolkit → cuDNN → TensorRT。驱动装完先重启再继续不然nvidia-smi可能读不到 GPU。CUDA Toolkit 安装时不要勾选 Visual Studio IntegrationTensorRT 7.2.3.4 这个年代的版本对 VS 版本敏感集成失败反而会影响后续编译。cuDNN 的安装方式很机械解压后把bin、include、lib三个目录里的文件分别复制到 CUDA 11.0 安装目录对应的同名目录下。注意不要只复制 DLLcudnn_ops_infer64_8.dll、cudnn_ops_train64_8.dll、cudnn_cnn_infer64_8.dll这些文件在 TensorRT 推理时会被调用漏一个就报错。复制完成后可以用 2.1 节的命令验证版本。2.3 Windows10 原生环境与 WSL2 的边界很多人查资料时看到 WSL2 里能跑 CUDA就想着把 TensorRT 也扔进去。这个 zip 包不能在 WSL2 里用。WSL2 虽然共享 Windows 的 GPU 驱动但它内部的 CUDA 库是 Linux 版需要下载 Linux 平台的 TensorRT tar 包。Windows 原生环境使用这个 zip 包时也要注意 32 位应用调用不到 64 位 DLLPython 解释器必须用 64 位版本。另外提醒一句如果你用的是 RTX 4060 Ti 这类新卡先查驱动是否支持 CUDA 11.0。新卡通常需要新驱动而新驱动一般不会提供对老 CUDA 运行时的完整兼容测试。遇到加载失败时第一反应不应该是怀疑 TensorRT而是先用nvidia-smi确认驱动版本再决定要不要换驱动分支。3. 解压后的目录结构与最小可运行验证zip 包解压后目录结构和 Linux 版略有差异但核心组成一致。很多人解压完直接找setup.exe找不到就开始怀疑包损坏其实是没理解 TensorRT 的分发方式。这一章从目录用途讲起然后给一个最快验证路径。3.1 解压后先看这四个目录解压到纯英文路径比如D:\TensorRT-7.2.3.4。目录里值得关注的是bin、include、lib、samples四个子目录。bin包含trtexec.exe、polygraphy.exe等命令行工具。trtexec.exe是你最常用的工具负责模型转换和 benchmark。includeC API 的头文件。你写 C 推理代码时头文件路径指向这里。lib核心库文件包含nvinfer.dll、nvinfer_plugin.dll、nvparsers.dll以及对应的lib文件。samples官方示例代码里面能参考sampleOnnxMNIST的 C 实现以及trtexec的完整调用方式。python目录在 7.2.3.4 这个版本里通常不直接出现在根目录而是打包在python\tensorrt-7.2.3.4-cp37-none-win_amd64.whl。如果你解压后没找到直接搜索*.whl文件用 pip 安装即可。3.2 配置 PATH 与最小验证命令把D:\TensorRT-7.2.3.4\lib和D:\TensorRT-7.2.3.4\bin加入系统 PATH。这一步很关键TensorRT 运行时需要通过 PATH 找到nvinfer.dll否则 Python 里import tensorrt会报找不到 DLL。加完之后在 CMD 里执行trtexec.exe --version正常输出会显示TensorRT Version: 7.2.3.4。如果提示找不到nvinfer.dll说明 PATH 没生效或者 DLL 文件缺失。检查D:\TensorRT-7.2.3.4\lib下是否存在这几个文件nvinfer.dll、nvinfer_plugin.dll、nvparsers.dll。3.3 常见 DLL 加载失败与排查报错信息原因解决找不到nvinfer.dllPATH 未配置或 lib 目录缺失检查 PATH确认 DLL 存在找不到cudnn64_8.dllcuDNN 未安装或版本不对重新拷贝 cuDNN 到 CUDA 目录找不到cublas64_11.dllCUDA 11.0 运行时缺失重装或修复 CUDA Toolkit应用程序无法启动 0xc000007b32 位应用调用 64 位 DLL确认应用是 64 位我用过一个偏门解法把cudnn64_8.dll直接复制到 TensorRT 的lib目录。这样能绕开 PATH 的问题但治标不治本。如果你需要同时维护多个 TensorRT 版本建议不要做这种拷贝而是为每个版本写一个环境变量脚本切换版本时改 PATH 即可。检查 DLL 依赖可以用dumpbin /dependents nvinfer.dll这是 VS 自带的工具能一眼看出缺失的依赖项。4. 用 trtexec 把 ONNX 模型转成 TensorRT engine环境没问题接下来就是核心操作把模型转成 TensorRT 的 engine 格式。这一章用trtexec.exe完成转换。不要一上来就写 Python API先用命令行工具跑通流程确认模型能转换、target 平台能加载再考虑集成到代码里。4.1 静态 batch 最小命令假设你有一个model.onnx先转一个固定 batch 为 1 的 engine。CMD 里执行trtexec.exe --onnxmodel.onnx --saveEnginemodel.engine --workspace1024 --fp16各参数含义--onnxmodel.onnx指定输入 ONNX 模型文件路径。--saveEnginemodel.engine把构建好的 engine 序列化到磁盘下次直接加载不需要重新构建。--workspace1024指定 TensorRT 构建时能使用的显存上限单位是 MB。7.2 这个版本还没有--memPoolSize你用--workspace就对了。--fp16开启 FP16 推理。如果显卡不支持 FP16比如部分老 Quadro 卡这个参数会导致构建失败去掉即可。转换过程中trtexec会打印每层的信息包括层名、输入输出维度、显存占用。转换时间取决于模型复杂度一个 ResNet50 大约需要 30 到 60 秒。转换完成后目录下会多出一个model.engine文件这就是最终要分发和加载的文件。4.2 动态 shape 参数与三种 profile很多场景下输入 batch 不固定需要动态 shape。这时要指定--minShapes、--optShapes、--maxShapes三个参数TensorRT 会根据这三个 profile 做尺寸优化trtexec.exe --onnxmodel.onnx --saveEnginemodel.engine ^ --minShapesinput:1x3x224x224 ^ --optShapesinput:4x3x224x224 ^ --maxShapesinput:8x3x224x224 ^ --workspace1024 --fp16参数说明input是 ONNX 模型里输入张量的名字。如果你不知道输入名可以先用--onnxmodel.onnx --printLayerInfo查看或者在 Python 里用 onnx 库读出graph.input[0].name。三个 shape 的顺序是NCHW分别是最小、最优、最大。optShapes是性能优化目标实际推理时 shape 越接近optShapes性能越好。动态 shape 模式下加载 engine 后每次推理都要显式set_binding_shape不设置会报INVALID_BINDING错误。4.3 三个必踩的坑第一--workspace不是实际显存占用而是构建阶段的允许上限。构建完成后推理阶段的显存占用由 TensorRT 自行管理这个参数对推理性能影响不大。如果构建时显存不足优先调低这个值而不是换显卡。第二FP16 精度不一定能无损。图像分类这类模型通常没问题但检测、分割模型里的某些层对精度敏感。建议转换后跑一遍精度对比方法很简单同一张输入图ONNX Runtime 输出和 TensorRT engine 输出做逐元素比较误差超过 1e-2 就要考虑关闭--fp16或者用 INT8 量化。INT8 需要校准数据集不是一条命令能解决的前期不要碰。第三构建过程中如果出现Error[3]: invalid argument绝大多数情况是输入 shape 和模型不匹配。多模态模型或带 text 输入的模型尤其容易触发用--printLayerInfo查看输入要求再重新写参数。7.2 版本对 Transformer 结构的支持不如 8.x 版本如果模型架构过新转换失败时不要硬调参数回归到 Pytorch 导出的 ONNX 版本上检查算子支持情况。5. Python API 加载 engine 并完成一次推理命令行跑通之后就该把 engine 集成到实际代码里了。这一章用 Python 完成从加载 engine 到输出结果的完整流程。注意 7.2.3.4 的 Python API 风格和 8.x、9.x 有差异不要拿新版本的写法硬套否则会碰到AttributeError。5.1 环境准备与 wheel 安装先安装 TensorRT 的 Python 包。解压目录里找到对应的 wheel 文件CMD 中执行pip install D:\TensorRT-7.2.3.4\python\tensorrt-7.2.3.4-cp37-none-win_amd64.whl注意文件名里的cp37表示 CPython 3.7但 7.2 时代的 wheel 多数是纯 ABI 的cp37后缀在 3.8、3.9 下通常也能装。如果安装失败检查 Python 版本然后找一个对应版本的 wheel。安装完成后验证import tensorrt as trt print(trt.__version__)能打印7.2.3.4就说明 TensorRT Python 绑定没问题。这时如果报ImportError: DLL load failed回头检查 3.3 节的 DLL 依赖pycuda也需要提前安装pip install pycudapycuda 的作用是管理 GPU 显存分配TensorRT 本身不提供 Python 端的显存管理接口没有 pycuda 你就没法在 Python 里给输入输出分配 device 内存。5.2 最小推理代码与参数说明import tensorrt as trt import pycuda.driver as cuda import pycuda.autoinit import numpy as np # 创建 TensorRT 运行时和日志对象 TRT_LOGGER trt.Logger(trt.Logger.WARNING) def load_engine(engine_path): with open(engine_path, rb) as f, trt.Runtime(TRT_LOGGER) as runtime: return runtime.deserialize_cuda_engine(f.read()) engine load_engine(model.engine) context engine.create_execution_context() # 获取输入输出 binding 索引 input_idx engine.get_binding_index(input) output_idx engine.get_binding_index(output) print(finput binding index: {input_idx}, output binding index: {output_idx}) # 分配 host 内存和 device 显存 input_shape (1, 3, 224, 224) output_shape (1, 1000) h_input np.random.randn(*input_shape).astype(np.float32) h_output np.empty(output_shape, dtypenp.float32) d_input cuda.mem_alloc(h_input.nbytes) d_output cuda.mem_alloc(h_output.nbytes) # 如果是动态 shape需要先 set_binding_shape # context.set_binding_shape(input_idx, input_shape) # 拷贝输入数据传输到 GPU cuda.memcpy_htod(d_input, h_input) # 执行推理 context.execute_v2(bindings[int(d_input), int(d_output)]) # 把结果拷贝回 CPU cuda.memcpy_dtoh(h_output, d_output) # 查看 top-5 置信度 top5 np.argsort(h_output[0])[::-1][:5] print(top5 class ids:, top5) print(top5 scores:, h_output[0][top5])代码逻辑拆开看先反序列化 engine 文件拿到engine对象再通过create_execution_context()创建执行上下文这是每次推理独立的状态容器。get_binding_index拿到的索引是数据的通行证后续无论拷贝还是推理都靠它定位缓冲区。execute_v2的bindings参数要求传入 device 指针列表顺序必须和 binding 索引一一对应这就是为什么要把d_input和d_output转成int再包装进列表。5.3 首次推理时间与性能验证代码能跑通后关注两个时间指标首次推理时间first inference latency和稳定推理时间。首次推理时间通常明显比后续慢因为 TensorRT 在首次调用时会加载 CUDA kernel、做显存初始化和算子调度。你可以在代码里加一个循环预热 10 次再计时for _ in range(10): context.execute_v2(bindings[int(d_input), int(d_output)])预热完成后再用time.perf_counter()测 100 次推理取平均值。这个平均值才是真实的部署性能。如果对比 ONNX RuntimeTensorRT 7.2.3.4 在常见 CNN 模型上通常有 1.5 到 4 倍的提升但 transformer 类模型的提升幅度可能没那么明显这是 7.x 的老问题。6. 把老版本加速跑稳workspace 调参、错误码与性能验证最后一章落到实用技巧针对 7.2.3.4 这个特定版本在 Windows 上的三个具体优化点。第一个技巧是合理控制--workspace。构建阶段把它设成显存最大值的 50%而不是往大了调。原因在于 TensorRT 选择算子融合算法时workspace 越大搜索空间越大构建时间越长但推理性能提升在 50% 之后基本趋平。如果构建时遇到cudaErrorMemoryAllocation说明 workspace 超过实际可用显存直接减半再试。第二个技巧是处理cudaErrorInsufficientDriver。这个错误看起来像驱动缺失实际上多数情况是驱动版本太老不满足 CUDA 11.0 的最低要求。用nvidia-smi查看驱动版本对照 CUDA 11.0 的兼容表。不建议重装系统或大版本升级驱动先试 NVIDIA 官方的驱动更新小版本往往能解决。第三个技巧是设置CUDA_CACHE_MAXSIZE环境变量。运行多次 TensorRT 推理后CUDA 驱动会缓存编译好的 kernel默认缓存容量有限。设置一个较大的值可以减少重复编译实测把CUDA_CACHE_MAXSIZE设为 536870912512MB后连续跑多个模型的首次推理延迟有明显降低。CMD 中执行set CUDA_CACHE_MAXSIZE536870912最后性能验证不只看解码速度还要关注 GPU 利用率。用nvidia-smi -l 1实时监控推理时的 GPU 占用如果发现利用率持续低于 50%大概率是数据拷贝或者 CPU 预处理成了瓶颈和 TensorRT 无关。建议对照同一模型在trtexec的 benchmark 输出那个数据排除了 Python 开销能更客观地反映 engine 的真实性能。本文还有配套的精品资源点击获取