ONNX Runtime 怎样为不同硬件选择执行提供者

ONNX Runtime 选择执行提供者（Execution Provider，简称 EP），应先匹配硬件、运行库、算子与模型形状，再用同一批真实输入比较端到端耗时。NVIDIA GPU 可从 CUDA 开始，TensorRT 作为进一步候选；Intel、Windows 通用 GPU、Apple 设备则分别考察对应方案。EP 名字出现在列表里，不等于整个模型都在加速硬件上运行。

官方地址：https://onnxruntime.ai/

先为同一个模型建立 CPU 基线

例如图像分类服务，从 CPU 迁到 GPU 时，先保留一份 CPU 配置。固定模型文件、输入尺寸、批大小、数据类型及业务并发，再记录初始化时间、预热后推理中位数、P95、内存和任务准确性。没有这组基线，就难以判断收益来自 EP、批量变化，还是输入精度变化。

这里提供可复用的比较方法，没有运行模型，也没有实测速度。适合优先比较批大小为 1 的在线请求与真实业务批量两个场景，分别报告，避免混成一个“快了几倍”的结论。

按硬件和运行库缩小候选范围

先确认目标系统和驱动，再选包含所需 EP 的发行包。不要把不同后端的包全部装进同一环境碰运气；EP 的依赖与发布形式应逐一按官方说明确认。

CUDA 官方说明给出了分版本的依赖表，不能把不同 CUDA 或 cuDNN 大版本当成可随意互换。不要仅凭“系统装过 CUDA”就认定 GPU 包能加载。

TensorRT 文档建议同时注册 CUDA，以承接 TensorRT 不支持而 CUDA 可以执行的节点。需要更少依赖或更短启动时间时，可以先只比较 CUDA 与 CPU。

OpenVINO 文档已将内置旧 EP 标为弃用，推荐独立 Plugin EP。DirectML 文档说明该路线仍受支持，但新功能转向 WinML；不能把它理解为已经不能使用。CoreML 文档则应作为 Apple 系统、包与算子支持的依据。上表是候选入口，不是对所有模型的速度排名。

明确注册顺序并拒绝意外降级

对 NVIDIA 场景，可先设置 CUDA 在前、CPU 在后；顺序表示有能力执行的节点优先交给前面的 EP，不表示两个设备平均分摊任务。ONNX Runtime 依据 EP 的能力划分节点或子图，参见EP 架构说明。

import onnxruntime as ort

# 本例针对已准备 CUDA 依赖的机器；其他硬件请使用相应 EP 的配置。
wanted = ["CUDAExecutionProvider", "CPUExecutionProvider"]
available = ort.get_available_providers()
missing = [name for name in wanted if name not in available]
if missing:
    raise RuntimeError(f"当前安装包缺少执行提供者：{missing}")

# providers 的顺序是优先级；模型路径应替换为自己的模型。
session = ort.InferenceSession("model.onnx", providers=wanted)
registered = session.get_providers()
if wanted[0] not in registered:
    raise RuntimeError("目标 EP 没有注册成功，请检查依赖和会话日志")

# 关闭运行时异常触发的自动重试降级，便于暴露配置问题。
# 这不会禁止建图阶段把不支持的节点分配给 CPU。
session.disable_fallback()
print("会话已注册：", registered)

get_available_providers()反映当前安装包可用的 EP，get_providers()反映当前会话注册列表；两者都不是逐算子的执行清单。关闭运行时 fallback 也不是“强制所有节点上 GPU”。这些 API 的语义见Python API 文档。

分开比较启动开销与稳态推理

把前一节创建会话的代码保存为脚本，并在后面接入下面片段。准备 inputs.npz，键必须与模型输入名一致，数组形状及数据类型必须符合模型要求。文件应来自实际预处理结果，不要为了方便给未知模型塞一个固定形状的随机数组。

import math
import statistics
import time
import numpy as np

# 从真实预处理结果读取全部输入；禁止加载对象 pickle。
with np.load("inputs.npz", allow_pickle=False) as data:
    names = [item.name for item in session.get_inputs()]
    feeds = {name: data[name].copy() for name in names}

# 先完成预热，避免把首次调用开销混入稳态指标。
for _ in range(5):
    session.run(None, feeds)

samples_ms = []
for _ in range(30):
    started = time.perf_counter()
    session.run(None, feeds)
    samples_ms.append((time.perf_counter() - started) * 1000)

# P95 采用最近秩定义；单请求串行样例不等于服务并发吞吐。
ordered = sorted(samples_ms)
p95 = ordered[math.ceil(len(ordered) * 0.95) - 1]
print({
    "median_ms": statistics.median(samples_ms),
    "p95_ms": p95,
    "providers": session.get_providers()
})

分别用 CPU 会话与候选会话运行，保持输入不变。初始化时间应另在创建会话前后计时；TensorRT 的首次准备成本与后续复用情况也要分别记录。上例包含主机输入及返回主机输出的调用耗时，不能当成纯 GPU 内核耗时。吞吐评估还应匹配业务并发及批量，正确性对比需覆盖业务样本及允许误差。

例如仅作计算演示，若 CPU 中位数为 12 毫秒、候选为 8 毫秒，则相对加速比为 1.5，耗时降幅约 33.3%。这些是假设数字，不是某种硬件的承诺；真实结论还要同时满足准确性与尾延迟要求。

解释局部分配与性能反差

如果注册成功却没有加速，应检查模型是否被切成许多小子图、CPU 与设备之间的数据复制是否抵消计算收益，以及实际批量是否太小。一次只改变一个条件，才容易解释差异。

需要了解算子耗时时，可为单独的诊断会话设置 SessionOptions.enable_profiling = True，完成调用后使用 end_profiling()获取文件。官方Profiling 说明介绍了这类跟踪记录。结合当前版本支持的节点分配信息和日志理解 EP 覆盖；不要用“注册成功”替代分配证据。正式耗时对比宜关闭诊断开销并保持两组条件一致。

有 GPU 就应该优先选 GPU EP 吗？

先把它列为候选。对计算量小、批量低或复制成本高的任务，CPU 也可能更合适；最终看同样业务负载的指标及部署成本。

把 CPU 放在最后会掩盖配置错误吗？

它允许不受加速 EP 支持的节点由 CPU 承接。对必须使用某加速器的服务，应检查目标 EP 注册和实际节点分配，并明确允许多少 CPU 执行；仅靠列表顺序不足以执行这项要求。

换 EP 时可以同时开启低精度吗？

可以另做一组候选，但要单列。先只替换 EP，再考察低精度，分别比较任务精度与耗时，避免把两个改动的效果混在一起。