Optimum ONNX Runtime 怎样为推理模型选择执行提供程序

Optimum ONNX Runtime 选择执行提供程序时，先不要把“机器有 GPU”直接等同于“模型会走 GPU”。更稳妥的做法是：读取当前安装包可用的 provider，把目标后端排在前面，再根据模型是否量化和是否需要 CPU 兜底决定加载参数。单一后端用 provider，多后端按优先级回退用 providers。

官方地址：https://huggingface.co/docs/optimum-onnx/onnxruntime/usage_guides/models

先把硬件能力与模型类型分开判断

ONNX Runtime 的 Execution Provider（EP）是硬件后端与运行库之间的适配层。CPU、CUDA、TensorRT、OpenVINO 等 provider 能否使用，首先取决于当前 Python 包是否注册了它，其次取决于系统动态库和模型算子是否匹配。下面的判断表适合放在代码之前：

建议先记录环境实际暴露的名字，再选择目标。名字拼写错误、安装的是 CPU 版 onnxruntime，都会让 CUDA 看起来像“配置不生效”。

用 provider 完成单一后端选择

当部署环境已经确定，最容易维护的是显式传入一个 provider。Optimum 的 ORTModelForSequenceClassification 等模型类会把加载参数交给 ONNX Runtime；下面的代码展示同一个模型在 CPU 与 CUDA 之间切换的最小结构。

from optimum.onnxruntime import ORTModelForSequenceClassification

# 用环境变量决定后端，便于同一份代码部署到 CPU 或 GPU
provider = "CUDAExecutionProvider" if use_cuda else "CPUExecutionProvider"

# 明确指定执行提供程序；模型仓库必须包含可加载的 ONNX 文件
model = ORTModelForSequenceClassification.from_pretrained(
    model_id,
    provider=provider,
)

# 预处理仍由 Transformers 负责，推理由 ORTModel 接管
result = model(**inputs)

这里的关键不是把 use_cuda 写成固定值，而是让它来自部署配置，并在启动阶段先检查 provider 是否真的可用。若当前环境只有 CPUExecutionProvider，直接指定 CUDA 应该快速失败并暴露安装问题，而不是默默把性能问题留到压测时。

用 providers 排优先级并保留 CPU 兜底

需要兼容多种节点或允许降级时，使用 providers 列表。列表按优先级排列，前面的 provider 能处理某个节点就优先使用它，不能处理的部分再交给后面的 provider。这个模式适合服务启动在 GPU 机器上，但仍要保留可控的 CPU 路径。

import onnxruntime as ort
from optimum.onnxruntime import ORTModelForSequenceClassification

# 只从当前安装包的能力中选择，避免把不存在的后端传给 ORT
available = set(ort.get_available_providers())
preferred = ["CUDAExecutionProvider", "CPUExecutionProvider"]
providers = [name for name in preferred if name in available]

# CPU 是服务的最后兜底；若它也不存在，启动阶段给出明确错误
if not providers or providers[-1] != "CPUExecutionProvider":
    raise RuntimeError("当前环境没有可用的 CPUExecutionProvider 兜底")

# 前面的 provider 优先，未覆盖的节点才交给后面的 provider
model = ORTModelForSequenceClassification.from_pretrained(
    model_id,
    providers=providers,
)

# 这里记录的是配置选择，不把它当成每个节点都使用 GPU 的证明
result = model(**inputs)

如果要使用 TensorRT，可把它放在 CUDA 前面，但应先确认模型与 TensorRT 的约束；如果只想做确定性对比，也可以只传 CPU。生产服务还应把实际 provider 列表和模型类型写入启动日志，方便把“降级成功”和“GPU 配置失败”区分开。

三个容易误判的边界

• 能列出 provider 不代表依赖完全可用：动态库缺失时，创建会话仍可能失败，必须把启动错误当成环境问题处理。
• 量化模型不能简单套用浮点模型配置：Optimum 的 GPU 指南明确区分 CUDA 与 TensorRT 对量化模型的支持限制，量化方式要和目标后端一起设计。
• provider_options 要和 provider 一一对应：需要传选项时，保持列表与选项字典的顺序一致，不要同时用互相冲突的两种选项传法。

判断是否真的达到加速目标，不能只看加载没有报错。应在固定输入下做预热和延迟对比，并记录模型是否量化、provider 顺序、批大小与输入形状；这些条件变化后，单次耗时没有可比性。

常见问题

只写 provider 不写 providers 可以吗？

可以。单一后端且不需要回退时，provider 更直观；需要多个后端按优先级协作时，改用 providers。

为什么机器有 NVIDIA GPU 仍然只有 CPUExecutionProvider？

通常是安装了 CPU 版 ONNX Runtime，或 CUDA/cuDNN 依赖没有被当前进程加载。先查看 get_available_providers()，再按官方 GPU 安装要求处理。

providers 包含 CPU 后就一定会自动加速吗？

不一定。它只定义优先级和回退路径；模型算子、量化形式、运行库和 provider 依赖仍决定哪些节点能由加速后端执行。