ONNX Runtime Provider 回退：模型能跑，不代表跑在预期设备上
一、Provider 回退会制造性能误判
ONNX Runtime 支持 CPU、CUDA、TensorRT 等 Execution Provider。模型加载成功并能推理，不代表它真的跑在预期设备上。如果某些算子不被 GPU provider 支持，运行时可能回退到 CPU，性能突然变慢。
部署排障时，很多人只看“推理成功”，忽略 provider 分配。结果 benchmark 很差，却误以为模型结构不行或硬件不行。先确认算子跑在哪里，再谈优化。
二、执行路径要显式观察
flowchart TD
A[ONNX 模型] –> B[加载 Session]
B –> C[选择 Provider]
C –> D{算子是否支持}
D –>|支持| E[目标设备执行]
D –>|不支持| F[回退到 CPU]
E –> G[性能指标]
F –> G
Provider 回退可能只发生在少数算子，但数据在 CPU 和 GPU 之间来回搬运，整体延迟会被明显放大。
三、先打印 provider 信息
import onnxruntime as ort
session = ort.InferenceSession(
"model.onnx",
providers=["CUDAExecutionProvider", "CPUExecutionProvider"]
)
print(session.get_providers())
还要开启 profiling，查看每个节点的执行 provider 和耗时。只打印 provider 列表还不够。
四、优化要先定位不支持算子
如果某些算子导致回退，可以尝试导出时替换算子、固定 opset、做图优化，或使用 TensorRT 支持的子图。不要盲目调 batch size。
输入输出格式也会影响性能。数据预处理如果在 CPU 上完成，推理在 GPU 上，后处理又回 CPU，整体链路可能被拷贝主导。端到端 benchmark 要包含预处理和后处理。
不同 provider 的数值结果也要比对。优化图、融合算子、低精度执行可能带来轻微误差。部署前要设置可接受误差阈值。
最后，发布包要锁定 ORT 版本、CUDA 版本、驱动和 provider 配置。环境变化可能让原本 GPU 执行的节点回退。模型文件没变，性能也可能变。
Provider 顺序也要明确。把 CPU provider 放在前面，可能导致节点优先分配到 CPU；把 CUDA 放前面，则不支持的节点才回退。配置顺序不是装饰，它会影响执行计划。
动态 shape 场景还要单独评估。某些 provider 对固定 shape 优化很好，但动态 batch 或动态序列长度会降低优化程度。线上输入形状如果变化很大，benchmark 不能只测一个固定 shape。
还要检查图优化级别。ORT 的 graph optimization 可能融合节点、消除冗余或改变执行计划。优化级别不同，性能和数值误差都可能不同。报告中要记录 session options。
最后，回退不是一定不能接受。少量低耗时算子在 CPU 上执行可能影响很小，强行改图反而增加复杂度。关键是量化回退成本，再决定是否优化。
部署监控也要记录 provider。线上延迟突然上升时，如果没有节点级执行信息，很难判断是输入变大、硬件拥塞，还是 provider 回退。可以在启动日志和模型元数据里写入 provider 配置。
批量推理还要看 provider 的 batch 支持。有些图在 batch=1 时表现正常，batch 增大后触发不同 kernel 或内存布局，性能反而下降。Benchmark 应覆盖计划上线的 batch 范围。
五、总结
ONNX Runtime 模型能跑，不代表跑在预期设备上。Provider 回退会严重影响性能判断。部署时要观察节点执行位置、定位不支持算子、评估端到端拷贝成本，并锁定运行环境。
