ONNX Runtime 怎样为指定会话选择图优化等级

ONNX Runtime 的图优化等级不是全局开关，而是挂在某个 SessionOptions 上，随后传给指定的 InferenceSession。最小写法是先创建会话选项，再设置 graph_optimization_level。如果目标是普通 CPU 推理，可以从 ORT_ENABLE_ALL 开始基准；如果执行提供者或离线模型有硬件兼容边界，则应从更保守的等级开始比较。

官方地址：https://onnxruntime.ai/docs/performance/model-optimizations/graph-optimizations.html

一、先把“等级”与“执行提供者”放在一起判断

ONNX Runtime 的等级是逐层叠加的。BASIC 主要做常量折叠、冗余节点删除和语义保持的融合；EXTENDED 在此基础上加入更复杂的节点融合；ALL 还包括可用的 layout 优化。它们不是四条互斥流水线，选择高一级通常会带上前一级的优化。

真正的取舍来自图会被哪个 Execution Provider 承接。官方文档说明，basic 优化发生在图分区前，适用范围更广；extended 优化发生在分区后，主要作用于 CPU、CUDA 或 ROCm 承接的节点；layout 优化还可能改变数据布局。因此“等级越高越快”不能脱离 provider 和硬件直接下结论。

二、在指定会话上显式设置等级

Python API 的配置点是 SessionOptions.graph_optimization_level。下面的函数把等级作为参数传入，便于同一模型分别创建多个会话做对比；不要把“默认值”当成业务配置写死在脑中，因为不同语言绑定和版本文档都应以当前安装包的 API 为准。

import onnxruntime as ort

def create_session(model_path: str, level: ort.GraphOptimizationLevel) -> ort.InferenceSession:
    # 图优化等级绑定到本次会话，不会修改模型文件或其他会话。
    options = ort.SessionOptions()
    options.graph_optimization_level = level

    # provider 顺序表达优先级；示例只展示显式配置，不伪造执行结果。
    return ort.InferenceSession(
        model_path,
        sess_options=options,
        providers=["CPUExecutionProvider"],
    )

session = create_session(
    "model.onnx",
    ort.GraphOptimizationLevel.ORT_ENABLE_EXTENDED,
)

如果只是验证模型是否能在没有高层变换的情况下运行，可以传入 ORT_DISABLE_ALL；如果是固定 CPU 线上服务，则把 ORT_ENABLE_ALL 纳入基准。每次比较都应保持模型、输入形状、provider 和线程配置一致，否则测到的不是优化等级差异。

三、在线优化与离线模型不是同一个开关

默认的在线模式会在初始化会话时做优化，然后再开始推理。模型较大时，首个请求前的初始化成本可能明显；这时可以设置 optimized_model_filepath，让 ONNX Runtime 把优化后的模型保存下来。之后加载这个文件时，仍要按官方规则保持目标环境的选项一致。

import onnxruntime as ort

options = ort.SessionOptions()
# 先为目标 CPU 生成包含全部可用优化的离线模型。
options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL
options.optimized_model_filepath = "artifacts/model.cpu.optimized.onnx"

# provider、优化等级和硬件应与离线生成阶段保持一致。
session = ort.InferenceSession(
    "model.onnx",
    sess_options=options,
    providers=["CPUExecutionProvider"],
)

离线模式的核心不是“保存后一定更快”，而是把启动阶段的图变换成本前移。若模型带有依赖特定 CPU 指令集的数据布局优化，离线文件就不能随意搬到另一类硬件上。生产部署应把优化文件与 provider、硬件型号和生成参数一起作为发布物记录。

四、常见配置误区与回退顺序

第一，别把图优化和线程优化混为一谈。intra_op_num_threads、execution_mode 影响执行调度，不会替代图融合；应先固定线程配置，再单独比较图优化等级。第二，别把 ALL 当成所有 provider 的统一答案。某些 provider 会在自己的后端执行硬件相关优化，官方建议可能是关闭 ONNX Runtime 的高层优化，或先使用 basic 再测。

一个稳妥的比较顺序是：先用 ORT_DISABLE_ALL 建立能运行的基线，再测 BASIC、EXTENDED，最后在目标硬件上测 ALL。记录会话初始化耗时、稳定输入下的推理延迟、内存占用和输出一致性；只看单次延迟，很容易把首次初始化成本误判为推理性能。

上线前检查清单

• 等级是否和目标 Execution Provider 一起测试，而不是只在默认 CPU 上测试。
• 离线优化文件是否标记了生成时的 provider、优化等级与硬件约束。
• 遇到异常时能否回退到 ORT_ENABLE_BASIC 或 ORT_DISABLE_ALL 做定位。

常见问题

怎样只给一个会话设置图优化等级？

创建独立的 SessionOptions，设置 graph_optimization_level，再把它通过 sess_options 传给目标 InferenceSession。其他会话不会因为这次设置自动改变。

EXTENDED 和 ALL 的主要区别是什么？

EXTENDED 包含基础优化和更复杂的节点融合；ALL 还会启用 layout 优化。layout 可能带来更高性能，也会提高硬件兼容性和离线模型迁移的约束。

为什么关闭优化后反而更适合某些 provider？

部分 provider 会在自己的后端执行硬件相关图变换，ONNX Runtime 的高层变换可能与其分区或内核策略不一致。应以该 provider 的官方说明和同一模型基准为准，而不是预设最高等级一定最好。