简介为Windows端C开发者提供Paddle Inference 3.2.1官方预编译包配合CUDA 12.9、cuDNN 9.9.0与TensorRT 10.5.0.18适用于需要高性能深度学习推理的本地服务与桌面应用。包内共629个文件以570个h头文件和15个hpp头文件为主附带14个lib导入库与6个dll运行时库方便直接链接调用同时包含proto、exp、manifest等配套文件整体约614.76MB配置较为完整。针对VS2019环境并启用MKL与AVX优化开发者无需从源码自行编译可快速搭建推理管线。目前已有107人浏览学习。该预编译包解决了CUDA/TensorRT版本匹配和Windows依赖配置的常见难题适用于图像分类、目标检测、OCR等模型的工业级部署也可以作为学习Paddle推理接口的现成运行环境。1. 当部署把版本选择变成硬门槛这个文件名里已经写好了所有依赖答案把 paddle-inference-3.2.1-windows-x86-64-cuda12.9-cudnn9.9.0-trt10.5.0.18-mkl-avx-vs2019.zip 这个文件名拆开读部署的答案其实已经在里面Paddle Inference 3.2.1 推理库、Windows x86-64 平台、CUDA 12.9、cuDNN 9.9.0、TensorRT 10.5.0.18、MKL、AVX、VS2019 工具链。这是一份官方发布流程里典型的预编译推理包目的就一个让手里已有训练好模型的人在 Windows 环境里不必重新编译 Paddle Inference直接链接库就能完成推理服务落地。你不必再去翻长篇的“从源码构建”教程对普通人来说源码编译光等待就够呛真正要做的是把 CUDA、cuDNN、TensorRT 三个运行时版本和文件名对齐再把路径配好、写几十行代码跑通一次预测。这份包适合正在做生产级推理服务的后端工程师也适合算法工程师在本地快速验证效果但如果你想要的是可训练的 Paddle 框架这份推理包帮不上忙那是另一套东西。2. 从文件名读出依赖链CUDA 12.9、cuDNN 9.9.0、TensorRT 10.5.0.18 各自在部署里担任什么角色2.1 CUDA 12.9 与 cuDNN 9.9.0驱动层和算子库必须成对出现先明确一件事这份 zip 不是源码而是已经链接了特定 CUDA 12.9 和 cuDNN 9.9.0 运行时的二进制集合。你在 Windows 上部署时不需要重新编译这两个库但目标机器上必须准备好三层东西NVIDIA 驱动、CUDA 运行时、cuDNN 运行时。CUDA 12.9 运行时提供cudart64_12.dll、cublas64_12.dll这些基础库负责设备管理、显存分配和通用数值运算cuDNN 9.9.0 则提供cudnn64_9.dll负责卷积、池化、归一化这些深度学习算子的高速实现。Paddle 的二进制在编译期按版本号链接了特定接口运行时也必须找到同一 ABI 的 dll否则就是“找不到指定模块”或者“无法定位程序输入点”。在 Windows 上安装 CUDA流程和 Ubuntu 那种把文件软链到/usr/local/cuda的做法完全不同。双十一期间的技巧是别装多版本直接冲突直接运行安装器时老版本不会自动卸载而是并存。很多人最后nvcc -V显示的版本和期望值不一致就是因为 PATH 里排在前面的老版本目录挡住了新版本。处理这类“CUDA 多版本安装”的问题核心就两个点一个是环境变量优先级另一个是命令行窗口要重新打开。不要在旧终端里调试改完 PATH 不重启终端等于没改。还有一点容易忽略NVIDIA 驱动要支持 CUDA 12.9 对应的最小驱动版本先执行nvidia-smi看一眼右上角支持的 CUDA 版本版本偏低就先升级驱动再装工具包顺序反了容易多跑一次安装器。cuDNN 9.9.0 在 Windows 上的安装方式是把解压后的bin、include、lib三个目录合并进 CUDA 安装目录或者单独保留一个目录并把bin加入 PATH。这里最容易翻车的地方是版本混用把旧的cudnn64_8.dll留在 PATH 里程序启动时先加载到旧库第一次执行卷积就崩溃。文件名里既然写了 9.9.0运行时就必须找到对应的cudnn64_9.dll不要凭感觉“8 和 9 应该差不多”。像 RTX 4060 Ti 这类 Ada 架构显卡计算能力是 8.9用这套 CUDA 12.9 加 cuDNN 9.9.0 的组合完全没有问题网上关于“4060ti 支持哪个 cuda 版本”的疑问本质只要查一下显卡计算能力和驱动支持范围就能确认。2.2 TensorRT 10.5.0.18为优化引擎而存在的第三层TensorRT 在这套组合里的职责不是训练而是把训练好的推理模型转换成经过层融合、精度调整的优化引擎。Paddle Inference 在 GPU 模式下并不强制要求 TensorRT而是像文件夹名的trt10.5.0.18所暗示的包的二进制是跟特定版本的 TensorRT 链接过的。你有两种用法完全不调用EnableTensorRtEngine只走普通 GPU 推理或者打开 TensorRT 路径让 Paddle 调用nvinfer.dll去生成并运行优化引擎。前一种部署简单后一种延迟更低但依赖也更多。一旦要打开 TensorRT 路径运行时就必须找得到与 10.5.0.18 匹配的nvinfer.dll。这个 dll 可能在解压后的third_party目录里也可能需要你单独安装 TensorRT 后把它的lib目录加入 PATH。关键是版本不能错用 10.4 的nvinfer.dll去顶替 10.5表面上 API 一样实际内核缓存格式和算子注册表都变了构建引擎时会出现间歇性的“trt init failed”或“网络不存在”。TensorRT 版本匹配更像一个黑匣子差一个小版本都可能出现诡异行为我吃过这个亏后来干脆记住一条死规矩包上写多少运行环境就放多少。还要提前确认 GPU 架构下限。TensorRT 10 对老显卡并不友好如果你的目标机器是 GTX 10 系列这种 Pascal 架构计算能力 6.1普通 CUDA 推理可以跑但 TRT 引擎初始化阶段很可能直接失败。这种失败不会在启动时报“硬件不支持”而是隐藏在一堆日志后面表现成“engine build failed”。所以部署前先查一下计算能力别等上线了才发现到那时就真没有后悔药可吃。2.3 VS2019 与 MKL-AVX工具链和 CPU 优化后缀为什么也写进文件名vs2019后缀说明这份库是用 MSVC 14.2x 工具链编译的。你在自己工程里只要也用 Visual Studio 2019 或更高版本打开一般不会碰到 STL 布局不一致造成的 ABI 问题用 VS2022 链接 VS2019 生成的库通常也可以。但如果你偏要用 MinGW 或者老版本 VC 去链接那大概率会在编译期遇到符号修饰不一致、链接失败之类的问题。这里最典型的坑是运行时库选择Paddle 的 dll 构建时用的几乎都是动态 MSVC 运行时/MD你自己的项目如果用了静态运行时/MT运行时内存管理两边各持一端堆上分配和释放对不上程序跑一阵子就会莫名崩溃这个在章节 4.3 里专门讲。mkl和avx这两个后缀管的是 CPU 推理质量。MKL 版用的是 Intel oneMKL 数学库在纯 CPU 环境下做矩阵乘和卷积时会调用 Intel 优化过的内核延迟通常比非 MKL 版低百分之二三十具体收益取决于模型里卷积和全连接的比例。avx表示这份二进制启用了 AVX 指令集要求 CPU 必须支持 AVX2010 年之后的 x86-64 处理器基本都支持但一些低功耗工控机、老赛扬处理器没有这时跑程序会直接报“非法指令”。如果目标机器是老旧型号你需要去找不带 AVX 后缀的包而不是硬编译。这几个后缀平时没人讲但每次线上事故都可能是它们引起的。3. 在 Windows x86-64 上部署这份推理包解压、配置、编译、跑通的四个步骤3.1 先做环境对齐CUDA、cuDNN、TensorRT 的安装顺序与多版本共存先装驱动再装 CUDA 12.9。去官方下载 CUDA Toolkit 12.9 安装包双击进入安装界面时选“自定义”把 CUDA 运行时、开发工具这些核心组件留下NSight 插件、Visual Studio Integration 这些如果不需要就去掉免得系统里多一堆用不上的服务。安装器会把文件放到C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.9这是 Windows 上的默认路径建议保持别改。装完在命令行执行nvcc --version确认输出的版本号是 12.9。接下来装 cuDNN 9.9.0。它的 Windows 版就是一个 zip解压后会看到bin、include、lib三个目录。最省事的方法是直接合并进 CUDA 安装目录把cudnn*.h放入 CUDA 的include把cudnn64_9.dll放入 CUDA 的bin把cudnn*.lib放入lib\x64。不想污染系统目录的人也可以保留独立目录比如D:\cudnn\9.9.0然后把bin单独加进 PATH。这两种方式我都试过独立目录的好处是以后换版本清理得干净适合经常折腾多版本共存的人。TensorRT 10.5.0.18 的安装流程和 cuDNN 类似解压后lib目录里有nvinfer.dll、nvparsers.dll、nvinfer_plugin.dll等文件。把这些文件所在的目录加入 PATH 即可。有个小提醒不要把所有第三方 dll 全放在同一个目录里比如把 Paddle 的paddle_inference.dll、cuDNN 的cudnn64_9.dll、TensorRT 的nvinfer.dll一股脑丢进C:\Windows\System32。系统目录能加载不假但以后升级任何一个组件都会因为版本覆盖问题把整个环境搞乱而且很难排查。用独立目录加 PATH 的方式才是可维护的部署结构。多版本共存时把 PATH 顺序摆在前面才是关键。当前项目需要的 CUDA、cuDNN、TensorRT 目录放在靠前位置切回 CUDA 11.8 时再改 PATH 顺序。这里最容易让人晕的就是命令行窗口的环境变量继承问题修改系统 PATH 后旧窗口不会自动刷新必须新开终端。很多“cuda 多版本安装”的求助帖最后原因都是没重启终端这点你踩过一次就能记住了。3.2 解压目录结构paddle、third_party 各自该放哪里解压这份 zip 后如同类预编译包的惯例你会看到下面这样的目录布局。这不是我手动造的而是所有统一发布格式都类似路径内容Windows 部署时的关注点paddle\include\paddle_inference_api.h等头文件C 工程里加入 Include 目录paddle\lib\paddle_inference.dll、paddle_inference.lib链接时指向 lib运行时保证 dll 在 PATHthird_party\部分第三方依赖如 MKL、protobuf 等不要手动清理有些库只在特定路径下加载解压位置我用的是D:\paddle_inference这种纯英文无空格的路径。不是说中文路径完全不能用而是 Windows 上部分动态库在加载带空格和中文路径时会遇到引号处理不一致的问题第三方脚本往往没有做这层防护。为了少踩坑从一开始就别给自己制造麻烦。解压后打开一个新的 cmd 窗口执行下面这条命令把各 dll 目录加入 PATHset PATHD:\paddle_inference\paddle\lib;D:\paddle_inference\third_party;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.9\bin;D:\cudnn\9.9.0\bin;D:\TensorRT-10.5.0.18\lib;%PATH%这个排列顺序有讲究Paddle 的 dll 放最前CUDA 的bin其次第三方依赖放后面。Windows 加载 dll 时按 PATH 顺序逐个查找如果多个目录里都存在同名 dll排在前面的优先加载。设完变量后执行where paddle_inference.dll、where cudart64_12.dll、where cudnn64_9.dll、where nvinfer.dll确认每个 dll 都指向预期的那一份。这一步虽然基础但能让你后面少折腾半天我每次换机器都会先做这组检查再写代码。3.3 最小 C 推理程序读入模型、准备输入、执行一次预测假设手头已有一份导出的 Paddle 推理模型目录结构是resnet50/inference.pdmodel和resnet50/inference.pdiparams。下面这个最小程序足够验证整条链路#include paddle_inference_api.h #include iostream #include vector int main() { paddle_infer::Config config; config.SetModel(./resnet50); // 目录下需有 inference.pdmodel 和 inference.pdiparams config.EnableUseGpu(128, 0); // 显存池 128 MB使用 0 号 GPU auto predictor paddle_infer::CreatePredictor(config); // 准备输入 auto input_names predictor-GetInputNames(); auto input_tensor predictor-GetInputTensor(input_names[0]); std::vectorint shape {1, 3, 224, 224}; input_tensor-Reshape(shape); std::vectorfloat data(1 * 3 * 224 * 224, 0.5f); input_tensor-CopyFromCpu(data.data()); // 执行推理 predictor-Run(); // 读输出 auto output_names predictor-GetOutputNames(); auto output_tensor predictor-GetOutputTensor(output_names[0]); std::vectorint out_shape output_tensor-shape(); std::cout 输出维度数: out_shape.size() std::endl; for (int v : out_shape) { std::cout v ; } std::cout std::endl; return 0; }这段代码的关键点有五个。paddle_infer::Config是推理配置入口几乎所有优化开关都挂在它上面。EnableUseGpu(128, 0)的第一个参数是初始显存池大小单位是 MB不是字节设得太小会频繁向驱动申请显存性能打折一般 CV 模型建议至少 256。第二个参数是设备号多卡机器上要确认模型和数据放在同一张卡。CreatePredictor返回的 predictor 对象是整个推理过程的执行者输入输出都通过它来操作。CopyFromCpu只负责拷贝数据不会校验 shapeshape 不匹配可能出现段错误所以 Reshape 和 Copy 的顺序不要颠倒。如果想跑 CPU 推理把EnableUseGpu换成config.DisableGpu()即可不用改其他代码。用 VS2019 的开发者命令行编译命令大致是这样cl /EHsc /O2 /MD /I D:\paddle_inference\paddle\include test_infer.cpp ^ /link /LIBPATH:D:\paddle_inference\paddle\lib paddle_inference.lib/EHsc是打开 C 异常处理/O2是速度优化/MD表示动态链接到 MSVC 运行时库。这里把/MD单独拎出来是因为 MKL 版 Paddle 的 dll 几乎都是/MD构建你自己的工程若用/MT静态运行时运行期会出现内存跨模块释放问题。编译成功后把生成的test_infer.exe放在任意目录只要 PATH 里有前面那些 dll 就能跑。第一次运行如果一切正常你会看到输出维度数量这就说明整条链路已经通了。3.4 Python 侧也可以调用paddle.inference 的快速路径不想写 C 的人也可以直接用 Python。先建一个干净的 conda 环境Python 版本建议 3.9 或 3.10然后安装paddlepaddle-gpu发布包。这里要注意Python 侧的paddle.inference和 C 的paddle_inference底层共用同一套推理库所以 DLL 和环境变量的要求完全一致。代码结构也很接近import paddle.inference as paddle_infer config paddle_infer.Config( ./resnet50/inference.pdmodel, ./resnet50/inference.pdiparams, ) config.enable_use_gpu(128, 0) predictor paddle_infer.create_predictor(config) input_names predictor.get_input_names() input_tensor predictor.get_input_handle(input_names[0]) input_tensor.reshape([1, 3, 224, 224]) input_tensor.copy_from_cpu([0.5] * (1 * 3 * 224 * 224)) predictor.run() output_names predictor.get_output_names() output_tensor predictor.get_output_handle(output_names[0]) print(output_tensor.shape())这段 Python 和前面 C 版本一一对应只是命名风格从 PascalCase 换成了 snake_case。需要注意Config的第一个参数是模型文件路径第二个是参数文件路径如果你的模型还是旧版__model__和__params__格式要先导出成inference.pdmodel和inference.pdiparamsPaddle 的模型导出工具会自动生成这两个文件不需要手动改名。Python 侧最常见的坑是机器上原来装过 CPU 版paddlepaddle再装 GPU 版时 pip 不会自动卸载旧包两个包文件同名最后装的决定谁生效于是出现“装完还是 CPU 推理”的假象。先pip uninstall paddlepaddle再装 GPU 版基本就不会翻车。4. 避坑与常见排查Windows 部署里排前三的报错和它们的修法4.1 找不到 paddle_inference.dll或 cudart64_12.dll 提示缺失现象编译链接都顺利通过但运行程序时弹窗提示“找不到 paddle_inference.dll”或者“由于找不到 cudart64_12.dll无法继续执行代码”。原因链接时用到的paddle_inference.lib只是导入库真正的逻辑在 dll 里。运行时Windows 只会在 exe 所在目录、系统目录、当前目录以及 PATH 中查找依赖 dll。链接成功只代表导入库的符号表对上了不保证 dll 在运行路径里。解决先用where paddle_inference.dll和where cudart64_12.dll确认 dll 是否存在再检查 PATH 是否把 Paddle 的lib目录和 CUDA 的bin目录放在有效位置。如果程序是从 IDE 启动的还要重启 IDE因为 IDE 继承的是启动时的环境变量。不要把 dll 拷贝进C:\Windows\System32应急那样会污染系统目录以后装别的版本时就会陷入“找不到正确 dll”的混乱。把 dll 目录统一配置在 PATH 里才是可维护的做法。4.2 TensorRT 初始化失败或者 nvinfer 版本对不上现象在开启EnableTensorRtEngine后日志里出现Failed to load TensorRT或TRT engine init failed有的环境会直接抛异常终止推理。原因要么是 PATH 里找不到nvinfer.dll要么是找到了但版本不是 10.5.0.18。TensorRT 的老版本 dll 和新版本引擎在工作空间分配、算子缓存格式上不兼容Paddle 在加载时会做版本校验校验不通过就放弃 TRT 路径。如果你的显卡计算能力太低TRT 引擎初始化阶段同样会失败而且这种失败日志往往不直白你可能会误以为是代码问题。解决在命令行执行where nvinfer.dll查看路径指向哪里。右键查看 dll 属性在文件版本里确认版本号以 10.5.0.18 开头。如果版本不对安装对应版本的 TensorRT并把它的 lib 目录提前到 PATH 靠前位置。如果硬件计算能力不足那就只能关闭 TRT 优化用普通 GPU 推理延迟会高一些但功能正常。这也算是一种降级方案至少系统还能用。4.3 自己工程编不过或者跑起来内存乱掉/MD 与 /MT 的冲突现象第一种是链接阶段报一堆unresolved external symbol第二种是程序能启动但运行几十次后突然在free()或 vector 析构处崩溃。原因这两种现象背后往往是同一个元凶你的工程用了/MT或/MTd也就是静态 MSVC 运行时而 Paddle 的 dll 是按/MD动态运行时构建的。两端各持有一份堆管理状态内存从其中一端分配、交给另一端释放堆就坏了。链接阶段找不到符号则多是因为自己的工程用了老版本 VS导入库里的符号修饰与当前工具链不一致。解决打开项目属性在“C/C → 代码生成 → 运行时库”里把选项改为“多线程 DLL (/MD)”。Debug 配置用/MDd。同时确认平台工具集选择“Visual Studio 2019 (v142)”或更高版本。命令行编译时直接给cl加上/MD参数。这个设置看起来是玄学实际原因非常确定一旦改对问题立刻消失。4.4 GPU 显存只增不减多次调用后爆显存现象程序循环执行推理前几次正常跑到第 50 次开始变慢第 100 次时nvidia-smi显示显存占用接近上限进程被系统或驱动干掉。原因每次调用都重新paddle_infer::CreatePredictor(config)每次都初始化新的 GPU context旧 context 没有及时释放。另一个常见原因是输入虽然是固定 shape但动态 shape 模式下每次请求长度有波动TensorRT 工作区会不断重分配。解决进程级只创建一个 predictor反复复用同一个对象做推理。如果必须多线程每个线程各建各的 predictor不要共享同一个实例。开启 TRT 时把use_static参数设为true让优化引擎落盘下次启动直接加载避免每次重新分配工作区。显存曲线如果仍然上涨用nvidia-smi -l 1每秒刷新一次确认是哪个进程在涨再决定是缺释放还是缺复用。显存泄漏这种事越早定位越省心别等到线上挂了再查。5. 从能跑到跑得快TensorRT 开关、动态形状、CPU 线程数这三个调优点5.1 打开 TensorRT 引擎EnableTensorRtEngine 的参数怎么设环境没问题后我建议立刻试一下EnableTensorRtEngine因为同样的 GPU 卡开不开 TRT 延迟差距肉眼可见。最简配置如下// 开启 TensorRT工作区 4 MB批大小 1FP32 精度 config.EnableTensorRtEngine( 1u 22, // workspace 大小单位字节4 MB 1, // max_batch_size paddle_infer::Precision::kFloat32, true, // use_static序列化引擎到本地 false); // use_calib_mode仅 INT8 校准时需要每个参数都要说清楚。workspace是 TensorRT 构建引擎时可用的最大显存工作区单位是字节1u 22就是 4 MB模型较大时改成1u 26也就是 64 MB但不要设成几 GB那会影响显存里其他任务的空间。max_batch_size是构建引擎时的最大批大小运行时实际批大小不能超过它。Precision有三个取值kFloat32是默认 FP32kHalf是 FP16kInt8是 INT8 量化。FP16 在 RTX 30 系以上显卡上很划算INT8 需要配合use_calib_modetrue做校准直接打开很容易精度崩掉。开 TRT 后第一次运行会有一段引擎构建时间有时几十秒有时几分钟取决于模型复杂度。use_statictrue会把构建好的引擎缓存写到磁盘第二次启动直接加载不用重新构建。我通常会把引擎构建这一步放在服务发布前的准备阶段单独跑一次“预热”而不是让用户第一个请求去等。需要特别提醒的是装包里的 TRT 和非 TRT 逻辑是共存的即使EnableTensorRtEngine失败也只是普通 GPU 推理不会让进程退出。所以这个开关可以放心开最坏情况是没加速不至于坏掉。5.2 动态形状min、max、opt 三组 shape 的取舍如果模型的输入尺寸不固定TRT 需要告诉它动态形状的范围。常见的设置方法是config.SetTRTDynamicShapeInfo( {{image, {1, 3, 224, 224}}}, // min最小形状 {{image, {8, 3, 224, 224}}}, // max最大形状 {{image, {4, 3, 224, 224}}} // opt最常见形状 );第一组是输入张量名image和它的最小形状第二组是最大形状第三组是最常出现的形状。TensorRT 在编译引擎时会针对opt形状做内核调优并在运行时对落在 min 和 max 之间的形状做适配。如果你的业务里 90% 请求都是 batch 4偶尔有 batch 8把opt设在 4 是最合理的这样常见请求拿到的都是优化过的内核稀少的 batch 8 会稍慢但要能接受。这里有个容易踩的误区把max设很大比如{16, 3, 224, 224}以为这样万无一失。实际上 max 越大TRT 预留的资源越多引擎体积和首次构建时间都变大不一定划算。我一般做法是用业务统计的 P90 作为 max用均值作为 opt没有统计数据时先用max2*opt起步跑一段时间再根据监控调。调完以后观察显存和延迟你会发现两个指标基本就是围绕 opt 展开的设置合理了内存曲线会平滑很多。5.3 CPU 路上的 MKL 线程数不是开得越多越好纯 CPU 部署场景里MKL 版 Paddle 依赖 OpenMP 做多线程并行。默认行为是让 OpenMP 自己探测逻辑核数四核八线程的 CPU 上往往开 8 个线程但推理是短任务对线程切换非常敏感8 个线程经常比 4 个线程还慢。这时候要显式控制// 把 CPU 数学库线程数设为物理核心数而不是逻辑线程数 config.SetCpuMathLibraryNumThreads(4);这个参数必须在创建 predictor 前设置。如果你的机器是 8 核 16 线程建议先试 8再试 6看延迟曲线再微调。MKL 多线程对矩阵乘规模较大的模型提升明显但对轻量模型单次推理只有几毫秒线程创建和同步的开销反而占了主导这时设 2 或 3 个线程也许更优。容器环境更要小心有些容器nproc显示 96但实际只分配到 4 个核默认 OpenMP 直接跑满 96 线程性能反而掉到三分之一。我见过不止一次这种问题最后都靠显式设置线程数解决。CPU 核心数线程数典型表现4 核 8 线程8短任务下线程切换多延迟略涨4 核 8 线程4卷积模型常见最优区间8 核 16 线程8合理起点再按实测调整这张表不是参数大礼包而是建议的测试方向。每台机器的内存带宽、模型算子构成都不同跑一组 1 到 16 线程的对比取最低平均延迟的配置写死进配置文件才是理性的做法。调线程数花不了十分钟但带来的收益在长时间运行的服务上是实打实的。6. 交付前的最后一道验证用一条命令确认所有依赖在位再做一次显存稳定性观察我交付前习惯先跑一段 PowerShell 验证全部通过才敢说环境就绪。这条命令会把关键的四个 dll 逐个查一遍并显示它们实际解析到的路径$dlls (paddle_inference.dll, cudart64_12.dll, cudnn64_9.dll, nvinfer.dll) foreach ($name in $dlls) { $path (Get-Command $name -ErrorAction SilentlyContinue).Source if ($path) { Write-Host $name - $path } else { Write-Host $name - MISSING -ForegroundColor Red } }看到四个路径都指向你预期的那份目录说明 PATH 没问题。如果哪个 MISSING根据缺失的 dll 回到对应安装目录检查不要继续往下走。这一步的价值在换机器、换环境时特别明显能帮你把“环境变量没配好”和“代码有问题”两类原因快速分开。确认 dll 后再跑一次循环推理观察显存是否平稳for /L %i in (1,1,200) do test_infer.exe nul跑完 200 次后再看nvidia-smi显存占用应该保持在一个稳定水平。如果持续上涨回到章节 4.4 去查 predictor 的复用方式。我个人的交付习惯是第一次只跑通功能第二次才开 TRT 优化第三次再调整 CPU 线程数。每一步都留好验证手段不要一次性把所有开关全打开否则真出了问题你连哪个环节导致的都分不清。做完这些验证这份包在你机器上的部署才算真正收口。CUDA、cuDNN、TensorRT 三者的版本对齐看起来繁琐但只要你照着文件名逐项核对再把 PATH 和运行时库这两件事做对后面就是快速迭代的坦途。希望帮到你。本文还有配套的精品资源点击获取
