ONNX Runtime GPU推理部署指南：Windows x64环境从配置到调优

简介：onnxruntime-win-x64-gpu-1.18.0.zip 是面向 Windows x64 的 ONNX Runtime GPU 版推理库，专为需要在 C++ 工程中部署深度模型的开发者准备。借助 NVIDIA CUDA 并行能力，它能明显加速图像识别、语音处理、NLP 等计算密集型任务的推理过程；同时兼容 PyTorch、TensorFlow 等框架导出的 ONNX 模型，实现跨框架统一推理。

压缩包共 35 个文件、约 201.61 MB，包括 16 个头文件、4 个 DLL、4 个 LIB、4 个 PDB 调试符号，以及 README、License、版本号等文档。include 目录含有完整 C++ API 声明，lib 目录提供链接所需的导入库和运行库，VERSION_NUMBER、GIT_COMMIT_ID 便于追溯构建版本，LICENSE 与第三方声明则明确了合规信息。

已有 849 人学习下载。include 与 lib 目录划分清晰，方便 Visual Studio 等项目配置头文件索引和库链接；VERSION_NUMBER、GIT_COMMIT_ID 及 README 又能帮助核对 CUDA/cuDNN 兼容版本，降低环境适配与排错难度。配合 LICENSE 等合规文档，可以直接集成到 C++ 工程中，用于高性能 GPU 推理场景。

1. onnxruntime-win-x64-gpu-1.18.0.zip 出现在桌面上时，多半是你刚把 PyTorch 模型导出成 ONNX，正愁 Windows 上的 GPU 推理怎么落地。这个 zip 不是模型，也不是安装器，而是 ONNX Runtime 在 Windows x64 + NVIDIA GPU 平台的预编译推理引擎：里面有运行时 dll、C/C++ 头文件、导入库和 CUDA provider 动态库。它解决部署阶段最烦的三件事：不用从源码编译 ONNX Runtime、把推理从 CPU 挪到 GPU、让 C++ 程序直接链接一份本地动态库。适合两类人：做 C++ 桌面端或服务端集成的工程师，以及想绕开复杂 pip 环境、直接控制 dll 的 Python 用户。注意：它只适配 x64，ARM64 机器得另找对应包。

2. 解压与前置环境：CUDA、cuDNN、DLL 和 PATH 一个都不能少

拿到 zip 之后的第一件事不是双击解压然后到处拷，而是先把解压目录、运行库版本和系统 PATH 理清楚。这一层没弄明白，后面所有代码都会在“找不到 dll”和“用不上 GPU”之间反复横跳。

2.1 包内文件结构：dll、lib、include 各管什么

解压之后你会看到 include 和 lib 两个主目录，部分版本会把 dll 平铺在根目录。include 下面是一堆头文件，核心是 onnxruntime_c_api.h 和 onnxruntime_cxx_api.h，它们只服务于编译期；lib 目录是整个包的价值所在，运行期真正需要的是下面这四个文件。

这里最容易翻车的是只把 onnxruntime.dll 当作“整个运行时”，发布安装包的时候漏了 provider 相关的两个 dll。程序在自己的机器上能跑，一换到干净环境就只有 CPU。还有一个隐藏依赖：onnxruntime.dll 自身依赖 VC++ 运行库，缺了 vcruntime140.dll 和 msvcp140.dll，程序会在启动瞬间报错而不是进入推理逻辑。所以部署清单里除了上面四个文件，系统级的 VC++ redistributable 也必须带上。

2.2 1.18.0 对应的 CUDA/cuDNN 版本：先对表再动手

1.18.0 这个版本号的预编译 GPU 包，官方是按 CUDA 11.8 工具链构建的，配套 cuDNN 8.x。你机器上如果只有 CUDA 12.x 的 runtime，直接拿 1.18.0 的包来跑，大概率是“dll 能加载，但 provider 起不来”。我一般拿到包之后先做三件事：看驱动版本、看 CUDA 版本、看 cuDNN 是否存在。

驱动是向下兼容的，你装了新驱动不代表不能用旧的 CUDA runtime。但 nvcc 没有装也没关系，运行时只需要 cudart64_110.dll 和 cuDNN 的 dll 能被系统找到，整套 CUDA Toolkit 安装下来一般都会带齐。验证命令就两条：

nvidia-smi nvcc --version

nvcc 不存在时不用慌，继续检查 C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\ 下有没有对应版本目录，把该目录的 bin 和 cuDNN 的 bin 都加进 PATH 即可。如果你已经用上了 CUDA 12.x，建议直接换 1.19 之后的 onnxruntime 包，别再跟 1.18.0 较劲，跨大版本混跑是典型的“能加载但不工作”的玄学问题。

2.3 把 DLL 目录加进 PATH：两种做法与验证方法

PATH 配置有两种方式。方式一是永久写入用户环境变量，适合固定开发机和部署机；方式二是在进程内临时指定，适合嵌入到安装包或服务里，不污染全局。

:: 永久写入用户 PATH，新开终端生效 setx PATH "%PATH%;C:\ort\lib" :: 当前终端临时生效 set "PATH=C:\ort\lib;%PATH%"

setx 有一个隐藏的坑：它会展开当前 PATH 原值再写回，如果 PATH 本身很长，存在截断风险。所以我更推荐在系统设置里手动粘贴这一条，而不是反复 setx。Windows 的 PATH 环境变量有长度上限，喜欢把所有 dll 目录都堆在里面的人，总有一天会遇到程序找不到根本不可能找不到的文件。

Python 侧更推荐用进程内方式：

import os # Python 3.8+ 可用，把 DLL 搜索路径指向 zip 解压目录 os.add_dll_directory(r"C:\ort\lib")

这个调用只对当前 Python 进程里的动态库加载生效，不会影响其它程序，也不会污染 PATH。配置完之后用where onnxruntime.dll验证，能输出来自 C:\ort\lib 的路径，说明加载器能找到它。注意别在同一个 PATH 里放两个不同版本的 onnxruntime 目录，Windows 加载 dll 是按搜索顺序取第一个命中的，版本混了之后，报错信息会指向一些根本不在你代码里的符号，排查成本极高。

2.4 它和 pip 的 onnxruntime-gpu 是什么关系

先澄清一个概念：ONNX 文件只是模型的中间表示，它本身不会算任何东西；ONNX Runtime 才是那个把模型读进来、调度算子、真正执行推理的引擎。这个 zip 和 pip 的 onnxruntime-gpu 是同一个引擎的两种交付形态，版本对应时行为完全等价。

区别在于使用方式。pip 包安装到 site-packages，由 Python 的依赖管理统一控制；zip 包可以放在任意路径，拷进安装包、塞进 Docker 镜像、配合 C++ 或 C# 程序使用都不受限。离线部署时我一般会刻意避开 pip 二次下载依赖，直接把 zip 解压后的 lib 目录打成安装包的一部分，这就是 zip 包最大的存在理由。

还有一个常见误区是觉得文件名带 x64 就能通吃 64 位系统。ARM64 和 x64 的指令集完全不同，Windows on ARM 上跑这个包会被加载器直接拒绝，具体表现是 exe 启动报“试图加载格式不正确的程序”。在 ARM64 设备上做部署，需要单独找 ARM64 版本的 onnxruntime 包，不是改个文件名能解决的事。

3. 用 Python 和 C++ 把这份 zip 跑起来：两条接入路径

前置环境就绪之后，接入方式分两条线。Python 用户想快速验证模型能不能在 GPU 上跑，C++ 用户关心的是链接和分发。两条线我都会给最小可运行代码，以及代码跑完之后判断“真的用了 GPU”的方法。

3.1 Python 侧：让 session 优先加载本地 dll 的最小代码

假设你已经 pip 安装了 onnxruntime-gpu 1.18.0，只是想让运行时的 dll 从 zip 解压目录加载，那核心是 os.add_dll_directory。它解决的是“dll 明明在机器上，系统却找不到”的典型问题。

import os import onnxruntime as ort # 让加载器优先从 zip 包解压目录找同名 dll os.add_dll_directory(r"C:\ort\lib") session_options = ort.SessionOptions() # 开全部图优化：常量折叠、算子融合、冗余去除 session_options.graph_optimization_level = ort.EnableGraphOptimizationLevel.ORT_ENABLE_ALL session = ort.InferenceSession( "model.onnx", sess_options=session_options, providers=["CUDAExecutionProvider", "CPUExecutionProvider"], ) print(session.get_providers())

providers 参数是数组，顺序就是优先级。CUDAExecutionProvider 排前面，加载失败时 onnxruntime 会自动落到 CPUExecutionProvider，所以这个顺序既是加速配置也是兜底机制。get_providers() 输出列表里第一个是 CUDAExecutionProvider，说明 session 实际挂载成功。如果你的 pip 包和 zip 包版本不一致，这里可能会加载到另外一份 dll，行为会变得不可预期，所以务必保持版本一致。Windows 7 就别折腾了，1.18.0 已经在系统支持上放弃老平台，浪费时间。

3.2 C++ 侧：链接 onnxruntime.lib 的最小工程

C++ 集成才是这个 zip 包的主场。最小工程包含三个部分：头文件、导入库、运行时 dll。下面是一个能跑通的最小示例。

#include <onnxruntime/core/session/onnxruntime_cxx_api.h> #include <cstdio> int main() { Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "ort-gpu-demo"); Ort::SessionOptions opt; opt.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); // 第一个参数是 device_id，默认 0；多卡时显式传第几张 Ort::ThrowOnError(OrtSessionOptionsAppendExecutionProvider_CUDA( static_cast<OrtSessionOptions*>(opt), 0)); Ort::Session session(env, "model.onnx", opt); auto input_info = session.GetInputNameAllocated(0, Ort::Allocator::GetWithDefault()); std::printf("input: %s\n", input_info.get()); return 0; }

CMake 配置如下：

cmake_minimum_required(VERSION 3.20) project(ort_demo CXX) set(ORT_HOME "C:/ort") add_executable(ort_demo main.cpp) target_include_directories(ort_demo PRIVATE ${ORT_HOME}/include) target_link_directories(ort_demo PRIVATE ${ORT_HOME}/lib) target_link_libraries(ort_demo PRIVATE onnxruntime)

这里链接的 onnxruntime 对应 onnxruntime.lib，编译期用导入库就够了，运行时会去搜索 onnxruntime.dll。有三个方式让程序找到 dll：拷到 exe 同目录、PATH 加 lib 目录、或者在代码里用绝对路径加载。注意 Debug 和 Release 别混用，CMake 默认如果是 Debug 生成，但 onnxruntime.lib 是 Release 编译的，链接阶段会报一些关于 _ITERATOR_DEBUG_LEVEL 不匹配的莫名错误，把生成配置切成 Release 就安静了。头文件里如果暴露了 C++ 版本的 AppendExecutionProvider_CUDA，也可以直接用，但 C API 版本更保守，跨小版本兼容性更好。

3.3 三个输出确认 GPU provider 真正生效

很多人代码写完看到不报错就以为在跑 GPU，其实经常是“安全降级到 CPU”。我习惯检查三个输出，全部满足才算真的生效。

import onnxruntime as ort print("available:", ort.get_available_providers()) # ['CPUExecutionProvider', 'CUDAExecutionProvider'] 表示 provider dll 可加载 sess = ort.InferenceSession( "model.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"], ) print("active:", sess.get_providers()[0]) # active: CUDAExecutionProvider 表示当前 session 用的是 CUDA

第一个输出是 get_available_providers()，它告诉你引擎编译时带了哪些 provider，如果 CUDAExecutionProvider 根本没出现，说明 provider dll 依赖的 CUDA 库缺失，问题出在环境而不是代码。第二个输出是 get_providers()[0]，告诉你这个 session 实际选中了谁。第三个是行为确认：打开任务管理器的“GPU 引擎”列，跑推理时能看到 3D 或 Compute 引擎利用率跳动；或者用 profiler 看每次 run 被哪个 provider 接管。

session_options.enable_profiling = True # run 之后生成 onnxruntime_profile_*.json

这个 profiler 输出的 json 文件里会记录每个算子在哪类设备上执行，看到 CUDA 相关的 kernel 名字，才算盖章确认。前两个输出是软件层面，第三个是事实层面，我一般三个都过一遍。如果 available 列表里没有 CUDA，优先回去查 cuDNN 的 dll 是否在 PATH，而不是怀疑代码。

3.4 保留 CPU 回退：别让 CUDA 崩掉整个服务

在服务端部署时，依赖自动降级有个隐患：CUDA 能加载但显存分配失败时，session 创建阶段会直接抛异常，进程可能跟着挂掉。自动回退只在“provider 加载失败”时生效，不会帮你处理“加载成功但资源不足”的情况。

providers = ["CUDAExecutionProvider", "CPUExecutionProvider"] try: session = ort.InferenceSession("model.onnx", providers=providers) except Exception as exc: print("CUDA init failed:", exc) session = ort.InferenceSession("model.onnx", providers=["CPUExecutionProvider"])

这块的真正价值在于，它把“模型能不能用 GPU”变成显式决策。生产环境我一般把 provider 列表做成配置项，模型加载失败时明确报错，而不是悄悄用没硬件加速的 CPU 扛着，否则线上延迟异常时你根本不知道模型在用什么设备跑。

4. GPU 推理调优：从“能跑”到“跑满”的几个必调参数

session 能创建、GPU provider 能挂载，只是起步。实际部署时，如何让 GPU 利用率上去、显存不爆、延迟稳定，这才是 onnxruntime 和 onnx 这类推理框架真正拉开差距的地方。下面四个参数组是我每次部署都会过一遍的。

4.1 SessionOptions：图优化和并行执行该开哪档

SessionOptions 控制的是整个会话的行为，第一优先级是图优化级别。默认级别不差，但做 GPU 推理时我一般直接开到 ORT_ENABLE_ALL，它会做常量折叠、算子融合和冗余消除，对推理延迟的影响是实打实的。

ExecutionMode 有两个值，ORT_SEQUENTIAL 和 ORT_PARALLEL。并行模式听着更快，实际上只适合图中存在大量可并行分支的情况。一个 20 MB 以内的模型，并行调度的开销可能大于收益，延迟反而变差。我一般是先跑 SEQUENTIAL，再用 profiler 看图中是否有明显的空档期，确有必要才切 PARALLEL。

动态 shape 场景下，ORT_ENABLE_ALL 偶尔会把某些分支优化成错误的等价结构，表现是输出误差变大或偶发崩溃。遇到这类诡异行为，先用 BASIC 级别跑一遍对照，如果 BASIC 正常而 ALL 异常，这个版本的图优化和你的模型结构有不兼容，别硬上。

4.2 CUDA provider 的参数：device_id、arena 策略和显存上限

创建 InferenceSession 时，providers 参数除了传字符串，还能传二元组，第二项是给该 provider 的参数字典。CUDA provider 值得调的参数主要是下面三个：

cuda_options = { "device_id": 0, # 多卡时对应 nvidia-smi 里的编号 "arena_extend_strategy": "kSameAsRequested", # 减少显存预占 "gpu_mem_limit": 4 * 1024 * 1024 * 1024, # 4 GB，单位是字节 } sess = ort.InferenceSession( "model.onnx", sess_options=session_options, providers=[("CUDAExecutionProvider", cuda_options), "CPUExecutionProvider"], )

显存管理是 GPU 部署的大头问题。ONNX Runtime 的 CUDA provider 会维护一个显存 arena，默认策略倾向于预占较大空间以避免反复分配，这在单模型场景没问题，但多模型共存或与其它显存占用冲突时就容易爆。kSameAsRequested 会尽量按请求大小扩展，减少预占，代价是频繁的小块分配会带来少量延迟毛刺。gpu_mem_limit 是硬上限，单位是字节，别把整卡显存全设进去，给 CUDA context 和驱动留点余量。

4.3 延迟和吞吐验证：warmup 不能省

调参之后如何判断有没有效果？我习惯写一个 20 行以内的基准脚本，重点是 warmup 不能省。CUDA 的 context 初始化、kernel 算法选择都发生在第一次 run，直接计时会得到一个比真实延迟大几个数量级的数字。

import time import numpy as np import onnxruntime as ort sess = ort.InferenceSession( "model.onnx", providers=["CUDAExecutionProvider", "CPUExecutionProvider"], ) input_meta = sess.get_inputs()[0] shape = [d if isinstance(d, int) else 1 for d in input_meta.shape] x = np.random.rand(*shape).astype(np.float32) io = {input_meta.name: x} # 前 5 次用于 CUDA context 初始化和算法选择，不能计入 for _ in range(5): sess.run(None, io) times = [] for _ in range(50): t0 = time.perf_counter() sess.run(None, io) times.append((time.perf_counter() - t0) * 1000) print("avg %.2f ms, p95 %.2f ms" % (np.mean(times), np.percentile(times, 95)))

p95 比平均延迟更能代表线上真实体验，因为 GPU 推理的延迟分布偶尔会被显存带宽争用拉出长尾。跑完这个脚本如果 GPU 比 CPU 还慢，先别急着怀疑驱动，看看模型输入是否太小。单张图片几十毫秒的计算量，CPU 可能已经够快，GPU 反而把数据拷贝的耗时显出来了——小模型用 GPU 不是玄学，是真的不划算。

4.4 混合精度和图优化：什么时候值得开

图优化已经由 ORT_ENABLE_ALL 自动处理了大部分，手动能介入的下一步是 FP16。ONNX Runtime 没有直接提供一个“一键半精度”的 API，常见做法是用 onnxconverter_common 先把模型转成 FP16 再加载。

from onnxconverter_common import float16 model_fp16 = float16.convert_float_to_float16(model)

这不是没有代价的。FP16 的动态范围只有 FP32 的零头，激活值分布在极端范围时精度会明显劣化。我转换之后一定会跑一次全量验证集，比较 FP16 和 FP32 的输出误差，平均绝对误差在 1e-2 以下才敢上生产。那些包含大数值跨度归一化层的模型，FP16 经常会产出 NaN，这类模型就别碰半精度了。

5. 避坑 / 常见问题 / 排查：Windows 上容易翻车的 5 个点

这部分是从零到一跑通这个包最容易摔跤的地方。每一条我都按“现象、原因、解决”的顺序写，多数是环境问题而不是代码问题。

5.1 现象：程序启动就报找不到 onnxruntime.dll，或报 api-ms-win-crt 系列 dll 缺失

原因分两层。第一层是 PATH 或进程加载路径里没有包含 lib 目录，加载器按系统搜索顺序找不到 dll；第二层是系统缺少 VC++ 运行库，最典型的就是 vcruntime140.dll 和 msvcp140.dll。那些 api-ms-win 开头的报错，多数是 Windows 系统补丁和运行库没装齐，不是 onnxruntime 本身的问题。

解决：先把 lib 目录加进 PATH，Python 侧用 os.add_dll_directory 更干净。然后安装对应版本的 Visual C++ Redistributable x64 包，装完重启程序。还有一个容易被忽视的点：解压路径别带中文或特殊符号，某些工具链对非 ASCII 路径处理有历史遗留问题，换个纯英文路径能省去很多奇怪错。

5.2 现象：get_providers() 列表里只有 CPUExecutionProvider，代码跑完了但根本没用到 GPU

原因：onnxruntime_providers_cuda.dll 没有被成功加载。最常见的是 CUDA/cuDNN 版本和 1.18.0 不匹配，官方预编译 GPU 包基于 CUDA 11.8 构建，需要配套 cuDNN 8.x。另一个常见原因是部署时只拷了 onnxruntime.dll，provider 的两个 dll 没带全。

解决：先看 available 列表，如果 CUDAExecutionProvider 压根不出现，说明是环境问题。用 nvcc --version 核对 CUDA，再去%CUDA_PATH%\bin检查 cudart64_110.dll，去 cuDNN 安装目录检查 cudnn64_8.dll，全部齐了再加进 PATH。这里有个血泪经验：不要试图把 CUDA 12 的 dll 改名成 11.8 的文件名来骗过加载器，跨大版本混跑大概率是加载成功但 kernel 执行错误，这种错最难排查。想用 CUDA 12 就直接换 1.19 之后的包，把 1.18.0 留给 CUDA 11.8 环境。

5.3 现象：显存明明还有空闲，创建 session 或第一次 run 时却报 CUDA out of memory

原因：CUDA provider 的显存 arena 会预占和扩展，默认策略下它看到的可用显存包括整卡容量，而其它进程占用的显存、WDDM 模式的虚拟显存预留在 nvidia-smi 里不一定直观可见。你的“空闲”和 CUDA 看到的“可分配”不是一回事。

解决：给显存上锁。把 arena_extend_strategy 改成 kSameAsRequested，再用 gpu_mem_limit 设一个合理的显存上限。多模型共存时，把每个 session 的 gpu_mem_limit 设成总显存的一半左右，让 arena 不会吃掉所有余量。Electron 或浏览器宿主还会占一部分图形显存，这块在 nvidia-smi 里也看不见，但 CN 分配时能感知到，所以上限别卡太满。

5.4 现象：动态 shape 的模型第一次推理要 3 秒，后面才恢复几十毫秒，偶尔第一帧直接超时

原因：CUDA EP 面对动态维度时，需要重新选择甚至重新构建 kernel。第一次遇到某个 shape，会触发算法搜索和内核编译，这是 GPU 推理框架的共性行为，不是 onnxruntime 独有的毛病。某些图优化在动态 shape 下还会退化成保守路径，导致性能断崖。

解决：产品层面把动态轴固定下来，最常见的是把 batch size 固定成 1 或固定成推理服务支持的最大值，导出 ONNX 时就写死。如果必须支持动态 batch，提前用典型 shape 做 warmup，让 kernel 缓存命中，再给推理入口设置超时，不要在不确定时长的地方无限等待。另外可以对照 ORT_ENABLE_BASIC 和 ORT_ENABLE_ALL 分别跑一遍，动态场景下过激的图优化有时候是负优化。

5.5 现象：笔记本双显卡或服务器多卡，程序只跑 0 号卡，或干脆只看到 Intel 核显

原因：没显式传 device_id。Windows 双显卡机器上，CUDA 默认会选择性能最好的独显，但某些驱动和机型的组合下，CUDA 看到的设备编号和 nvidia-smi 显示的不一样；服务器多卡场景，设备编号与 PCIe 拓扑相关，不是简单的物理位置 0、1、2。

解决：先运行 nvidia-smi -L 列出所有 GPU，再在 provider 参数里显式指定 device_id。另一种方式是环境变量 CUDA_VISIBLE_DEVICES=1，只暴露第二张卡给 CUDA 运行时，但注意设置之后 onnxruntime 看到的编号就变成了 0。这两个方案选一个用就行，同时用容易把自己绕晕。笔记本上如果发现 CUDA 看不到独显，先去 Windows 图形设置里把程序分配到 NVIDIA 处理器，再回来看 provider 列表。

6. 进阶：把 CPU/GPU 切换和基准测试固化成一个可复用脚本

部署迭代到后期，反复手写 benchmark 和 provider 配置容易疲劳，也容易漏掉 warmup。我习惯维护一个小工具函数，换机器、换驱动、换模型时都先跑它，把结果留档。

6.1 一个够用的 provider 基准函数

def bench(model_path, providers, repeat=50): import time import numpy as np import onnxruntime as ort sess = ort.InferenceSession(model_path, providers=providers) meta = sess.get_inputs()[0] shape = [d if isinstance(d, int) else 1 for d in meta.shape] io = {meta.name: np.random.rand(*shape).astype(np.float32)} for _ in range(5): # warmup sess.run(None, io) ts = [] for _ in range(repeat): t0 = time.perf_counter() sess.run(None, io) ts.append((time.perf_counter() - t0) * 1000) return np.mean(ts), np.percentile(ts, 95) print("cpu:", bench("model.onnx", ["CPUExecutionProvider"])) print("gpu:", bench("model.onnx", ["CUDAExecutionProvider", "CPUExecutionProvider"]))

这个函数的核心不在于代码量，而在于输出口径一致。平均延迟看趋势，p95 看稳定性，warmup 次数固定，这样不同机器、不同驱动版本之间的对比才有意义。每次跑完把结果记到文件里，驱动更新之后再跑一次，数字一对比就知道性能有没有倒退。

6.2 判断配置合不合格的三个读数

跑完基准，我看三个读数。第一个是 p95 与 avg 的差距，差距超过 30% 说明存在长尾，优先怀疑显存碎片和动态 shape；第二个是 GPU 利用率，用 nvidia-smi 或任务管理器看单位时间内的利用率，持续低于 50% 且延迟没优势，说明模型太小或数据拷贝占了主导；第三个是第一次 run 和 warmup 后的差距，差距过大说明这次启动在做 kernel 编译，线上环境需要提前预热。

这三件事做完，这套 onnxruntime-win-x64-gpu 方案到底适合不适合你的业务，基本就有结论了。如果 GPU 收益明显，把 provider 配置和基准脚本一起收进项目的部署脚本；如果没收益，也留下记录了，至少知道问题不在引擎而在模型规模。我自己的习惯是每次拿到新机器都先跑一遍这个脚本，把数据归档，免得半年后回来说不清为什么当初选了某个配置。希望帮到你。

本文还有配套的精品资源，点击获取