想象你走进一家川菜馆的后厨。大厨接到一份新菜谱，并不会立刻开火炒菜。他会先打量工作台：哪些食材发蔫该扔掉，哪些调料可以提前配成秘制酱料，备菜工序能不能合并成一套顺手动作，甚至还要看看自家灶台是猛火炉还是平底电陶炉，再决定锅碗怎么摆。这一整套“开火前的准备工作”，就是后厨的「图优化」。 ONNX Runtime（简称ORT）就是那位大厨。当它加载一个ONNX模型时，模型是一张“计算图”——节点是算子（比如卷积、加法、激活函数），连线是数据流动的方向。如果直接按图里的顺序逐个执行，会有大量不必要的计算和内存搬运。于是，ORT在模型加载后、正式推理前，自动对这张图做三个层次的优化：基本优化负责“扔垃圾、备酱料”，扩展优化负责“合并工序、换趁手的工具”，布局优化则根据不同的“灶台”（硬件执行提供者）调整数据摆放方式。 这些优化对使用者完全透明，就像你点菜时不用关心后厨怎么备菜一样。但它对推理速度、内存占用、服务吞吐量的影响，却实实在在。

岗位关联

掌握图优化原理，你就能理解为什么同一个模型在不同框架、不同硬件上性能差异巨大。部署AI服务时，这是定位性能瓶颈、榨干硬件潜力的关键一环。

目录
  1. 可视化演示
  2. 图优化概览：开火前的备菜台
  3. 基本优化：扔垃圾与调酱料
  4. 扩展优化：合并工序与换工具
  5. 布局优化：看灶台摆家伙
  6. 执行提供者EP：后厨的灶台矩阵
  7. 优化控制与调试：后厨的应急灯
  8. 实战收益与调优：后厨的绩效报表
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示ONNX Runtime图优的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

ONNX Runtime图优：ONNX ONNX Runtime图优化 基本级优化的常量折叠与冗余消除 核心机制可视化 ONNX Runtime图优整体架构与关键组件

图优化概览：开火前的备菜台

大厨为什么非要“多此一举”地提前备菜？因为正式开火后，每一秒都金贵。如果等客人点菜了才开始洗菜、切菜、调酱，再快的颠勺也救不了出菜速度。图优化做的正是这份“提前准备”的活计。

在深度学习推理中，ONNX模型就是一份“计算图菜谱”。图中每个节点是一个算子，比如Conv（卷积，类似“切丝”）、Add（加法，类似“加盐”）、ReLU（激活函数，类似“尝味调整”）；节点之间的连线则标注了数据（张量）的流向，哪个算子的输出会成为下一个算子的输入。直觉上，只要按顺序执行每个节点就能得到结果，但这样做会有大量浪费。

图优化的本质，是在保持模型数学语义不变的前提下，对计算图进行等价变换。它借鉴了传统编译器对中间表示的优化思想，又针对深度神经网络的特点做了专门设计：预计算常量子图、消除恒等节点、融合连续算子等。ORT将优化分为基本、扩展、布局三个级别，在创建推理会话、加载模型时自动按级别应用，整个过程用户无感知。可以这样衡量优化效果：

其中 $T_{\text{baseline}}$ 是关闭优化时的平均推理延迟，$T_{\text{optimized}}$ 是开启优化后的平均推理延迟。

所以，大厨的“备菜”不是多此一举，而是把固定成本提前支付、把可变成本压到最低。图优化也是如此——一次加载时的投入，换来无数次推理的加速回报。

Speedup=TbaselineToptimized\displaystyle \text{Speedup} = \frac{T_{\text{baseline}}}{T_{\text{optimized}}}
加速比公式是衡量任何推理优化的“绩效尺子”：比值大于1，说明优化有效；越大，收益越显著。
  1. 测量基线耗时关闭所有图优化，测量同一模型单次推理的平均延迟
    Tbaseline=1N∑i=1Nti\displaystyle T_{\text{baseline}} = \frac{1}{N}\sum_{i=1}^{N} t_i
  2. 测量优化后耗时开启目标优化级别后，再次测量平均延迟
    Toptimized=1M∑j=1Mtj\displaystyle T_{\text{optimized}} = \frac{1}{M}\sum_{j=1}^{M} t_j
  3. 计算加速比用基线耗时除以优化后耗时，得到加速倍数
    Speedup=TbaselineToptimized>1\displaystyle \text{Speedup} = \frac{T_{\text{baseline}}}{T_{\text{optimized}}} > 1

基本优化：扔垃圾与调酱料

后厨备菜的第一步，永远是清理。蔫了的菜叶直接扔掉，几头大蒜统一剥好装碗。基本优化就干这两件事：扔掉对出菜没帮助的“废料”，提前把固定搭配的“酱料”调好。

在图上，有两类明显的浪费。第一类是冗余节点：比如Identity（恒等变换）节点，输入是什么输出就是什么，对最终结果毫无影响，但每次推理都要白白执行一遍；还有那些从未被使用的“死分支”，计算了却没人要。第二类是常量子图：有些算子的所有输入都是固定常量，比如 Add(2, 3)，每次推理都重复算一遍 2+3，纯粹是浪费。

常量折叠的做法，是在模型加载阶段直接扫描并执行这些“输入全为常量”的子图，把结果算出来，然后用一个常量节点替换整个子图。冗余消除则遍历计算图，标记并删除对输出节点没有贡献的节点。这两步合称基本优化，是任何优化级别下最安全、收益最确定的一类。其核心思想可以写成：

好比大厨把“生抽两勺加老抽一勺加糖半勺”事先调成一大碗照烧汁——备菜花了一次时间，接下来每道菜都省下了重复称量的功夫。这就是常量折叠的智慧。

Const(a)+Const(b)→Const(a+b)\displaystyle \text{Const}(a) + \text{Const}(b) \rightarrow \text{Const}(a+b)
这个式子描述了常量折叠：两个常量经过一个算子，结果还是常量。既然结果恒定不变，不如在加载时就算好，运行时直接取现成答案。
  1. 识别常量子图遍历计算图，找出输入全部来自初始化器的算子节点
    Add(Const(a) , Const(b))\displaystyle \text{Add}\big(\text{Const}(a)\,,\, \text{Const}(b)\big)
  2. 执行预计算在模型加载阶段调用CPU完成这一次运算
    c=a+b\displaystyle c = a + b
  3. 替换为常量节点用新的常量节点取代原算子，此后每次推理零成本
    Subgraph→Const(c)\displaystyle \text{Subgraph} \rightarrow \text{Const}(c)

扩展优化：合并工序与换工具

备菜到后半程，大厨会开始“合工”：切好的肉丝、配好的料汁、调好的芡水，统统装进一个码斗里，下锅时一股脑倒进去。扩展优化做的，正是把计算图里一条流水线上的多个算子“装进同一个码斗”。

深度学习模型里，最经典的连续模式是 Conv（卷积）→ BN（批归一化）→ ReLU（激活函数）。单独执行时，每个算子都要启动一次内核、把中间结果写回内存或显存，下一个算子再读出来。这种反复读写就是性能杀手。同时，每次内核启动本身也有固定开销——算子越多，启动次数越多。

算子融合将这条链上的多个算子合并为一个“融合内核”（fused kernel），在内部一次完成全部计算，中间结果可以留在寄存器或片上缓存中，不必往返主存。典型的融合包括 Conv+BN+ReLU 融合、Conv+Add 融合（用于残差连接）。除了算子融合，扩展优化还包括用高度优化的内核库（如oneDNN、cuDNN）替换标准实现，以及基于张量生命周期分析的内存规划复用——让多个中间张量共享同一块缓冲区，降低峰值内存。融合的数学表达为：

订单高峰时，后厨最怕的不是炒菜慢，而是反复在灶台和备料区之间跑动。把配菜装进一个码斗，一趟就端到灶台，这正是算子融合“一次取数、算到底”的妙处。

ReLU(BN(Conv(x)))→Ffused(x)\displaystyle \text{ReLU}\big(\text{BN}(\text{Conv}(x))\big) \rightarrow F_{\text{fused}}(x)
这个式子表示：三个首尾相连的算子，被一个融合算子 $F_{\text{fused}}$ 取代。输入 $x$ 经过融合内核，一次算到底。
  1. 模式匹配在图中找到 Conv→BN→ReLU 首尾相连的子图
    Conv(x)→BN(⋅)→ReLU(⋅)\displaystyle \text{Conv}(x) \rightarrow \text{BN}(\cdot) \rightarrow \text{ReLU}(\cdot)
  2. 生成融合内核将三段算子合并为一个内核函数
    F(x)=ReLU(BN(Conv(x)))\displaystyle F(x) = \text{ReLU}\big(\text{BN}(\text{Conv}(x))\big)
  3. 消除中间张量中间结果不再写回主存，减少访存开销
    memory_traffic↓\displaystyle \text{memory\_traffic} \downarrow

布局优化：看灶台摆家伙

同样一口铁锅，在猛火灶上要左手握柄、右手颠勺；在平底电陶炉上却要轻推慢移。菜谱不变，但锅碗摆放要根据灶台调整。布局优化，就是根据“灶台”（硬件）的脾气重新安排数据在内存里的排布。

张量在内存中的布局有不同约定。深度学习模型最常用 NCHW：N 是批大小，C 是通道数，H 和 W 是高和宽，数据按“先通道、后空间”的顺序存放；而 NHWC 则是“先空间、后通道”。不同的硬件和内核库对这两种布局的访问效率差异很大：某些 CPU 指令集和部分 GPU 卷积库对 NHWC 更友好，而传统 CV 流水线习惯 NCHW。

布局优化会评估当前执行提供者（EP）首选的数据布局，在子图边界插入 Transpose（转置）节点，将数据从 NCHW 转为 NHWC（或反过来），使主体算子在友好布局下运行。它本质上是一种“以局部转换开销换整体计算效率”的策略。转换本身也有成本，所以 ORT 会做收益判断：只有当布局转换带来的加速大于转置本身的代价时才应用。

大厨不会为了“摆得好看”而把锅碗挪来挪去——只有挪了之后确实顺手，他才会动。布局优化也一样，每一次插入 Transpose，背后都有一笔性价比账。

XNHWC=Transpose(XNCHW , perm=[0,2,3,1])\displaystyle X_{\text{NHWC}} = \text{Transpose}\big(X_{\text{NCHW}}\,,\ \text{perm}=[0, 2, 3, 1]\big)
这个式子展示了一次典型的布局转换：把形状为 [N,C,H,W] 的张量，按维度顺序 [0,2,3,1] 重排，变成 [N,H,W,C]，即 NHWC 布局。
  1. 确定目标布局查询 EP 的内核库，确认高效布局
    Layoutopt=NHWC\displaystyle \text{Layout}_{\text{opt}} = \text{NHWC}
  2. 插入变换算子在子图入口插入 Transpose 重排维度
    perm=[0,2,3,1]\displaystyle \text{perm} = [0, 2, 3, 1]
  3. 权衡转换开销比较布局优化收益与转置本身开销
    Topt+Ttrans<Torig\displaystyle T_{\text{opt}} + T_{\text{trans}} < T_{\text{orig}}

执行提供者EP：后厨的灶台矩阵

现代后厨不止一口锅：有猛火灶、蒸箱、烤箱、低温慢煮机。大厨会根据菜品特点选择最合适的设备。ONNX Runtime 的执行提供者（ExecutionProvider，简称 EP），就是推理引擎后厨里的一排灶台。

EP 是 ORT 抽象硬件后端的核心概念。常见的 EP 包括：CPUExecutionProvider（通用 CPU 默认后端，底层走 oneDNN 等内核库）、CUDAExecutionProvider（NVIDIA GPU，底层是 cuDNN/cuBLAS）、TensorRTExecutionProvider（NVIDIA 专用推理优化引擎）、OpenVINO ExecutionProvider（Intel 硬件）等。每个 EP 实现了相同的接口，向上层提供统一的算子执行能力。

EP 与图优化密切相关：基本优化和扩展优化对所有 EP 一视同仁，在 EP 分配前完成；布局优化则是“EP 感知”的，它针对每个 EP 的布局偏好进行数据重排。更进一步，ORT 支持异构执行：把计算图切分成多个子图，分别交给不同的 EP 执行——比如把预处理子图放 CPU、把卷积子图放 GPU。切分和分配的过程也发生在图优化阶段。理想情况下，每个子图都应该交给当前最优的 EP：

好大厨心里有张“设备地图”：蒸鱼用蒸箱、爆炒用猛火灶、红烧用砂锅慢炖。EP 就是对这张地图的抽象——让模型里的每个子图，都在最合适的“灶台”上被高效执行。

k∗=arg⁡max⁡kPerf(EPk)\displaystyle k^{*} = \arg\max_{k} \text{Perf}(\text{EP}_k)
这个式子表示：在硬件条件允许的情况下，为每个子图挑选性能最好的执行提供者，追求全局最优。
  1. 枚举可用EP检查系统注册的执行提供者列表
    E={CPU, CUDA, TensorRT, … }\displaystyle \mathcal{E} = \{\text{CPU},\ \text{CUDA},\ \text{TensorRT},\ \dots\}
  2. 子图切分将计算图按算子支持情况划分为多个子图
    G=⋃kGk\displaystyle G = \bigcup_{k} G_k
  3. 分配与执行每个子图交给对应的 EP 执行
    y=EPk∗(Gk∗, x)\displaystyle y = \text{EP}_{k^{*}}\big(G_{k^{*}},\ x\big)

优化控制与调试：后厨的应急灯

如果客人吃坏了肚子，后厨要排查是哪个环节出了问题。这时大厨会让所有“自动备菜”先停下来，拿出生肉和菜谱一步步核对。优化控制与调试，就是推理引擎的“应急灯开关”。

ONNX Runtime 通过 SessionOptions 暴露优化级别的开关。GraphOptimizationLevel 枚举定义了四个档位：ORT_DISABLE_ALL（0，完全关闭）、ORT_ENABLE_BASIC（1，基本优化）、ORT_ENABLE_EXTENDED（2，包含基本+扩展优化）、ORT_ENABLE_ALL（99，全部优化，含布局优化）。从数学上讲，这些级别是逐层包含的：$L_0 \subset L_1 \subset L_2 \subset L_{99}$。

调试时最常用的组合拳是：先用 ORT_DISABLE_ALL 跑一遍基线，确认模型本身正确；再逐步提高优化级别，观察延迟和输出变化。如果开启优化后数值出现明显偏差（通常不应发生），可以结合 ORT 的 verbose 日志、onnxruntime_perf_test 命令行工具，以及 profiling 时间线（chrome://tracing 格式）定位是哪个优化引起的。优化级别的包含关系可以写为：

应急灯不是为了永远亮着，而是为了在出问题时能快速定位元凶。掌握优化级别的开关，是每个 AI 部署工程师的“后厨急救技能”。

L∈{0,1,2,99},L0⊂L1⊂L2⊂L99\displaystyle L \in \{0, 1, 2, 99\},\qquad L_0 \subset L_1 \subset L_2 \subset L_{99}
这个式子表明：优化级别不是互斥的四个选项，而是层层叠加的“套餐”——高级别总是包含低级别的全部优化。
  1. 设定目标级别在 SessionOptions 中写入枚举值
    opts.graph_optimization_level=ORT_ENABLE_ALL\displaystyle \text{opts.graph\_optimization\_level} = \text{ORT\_ENABLE\_ALL}
  2. 加载时应用会话创建阶段，按级别执行优化流水线
    Graph′=ΦL(Graph)\displaystyle \text{Graph}' = \Phi_{L}(\text{Graph})
  3. 验证一致性对比优化前后输出，应保持数学等价
    ∥Out′−Out∥≈0\displaystyle \big\| \text{Out}' - \text{Out} \big\| \approx 0

实战收益与调优：后厨的绩效报表

备菜体系搭好了，后厨的绩效自然体现在报表上：高峰期出菜时间从 8 分钟降到 3 分钟，冰箱占用率下降两成。图优化的收益，同样可以用数据说话。

在真实部署中，图优化的收益是多维度的：常量折叠和冗余消除减少了无效计算；算子融合显著降低内核启动次数和中间张量的内存读写；布局优化在高带宽场景（如大分辨率 CV 模型）中收益明显；内存规划复用直接压低了峰值显存占用。这些收益最终表现为推理延迟降低、吞吐量提升、服务成本下降。

调优方法论上有几个推荐步骤：第一，关闭优化测基线（ORT_DISABLE_ALL）；第二，逐级开启优化（BASIC→EXTENDED→ALL），每步复测延迟和显存；第三，用 profiling 工具确认瓶颈在算子执行、内存拷贝还是数据加载；第四，尝试切换 EP（如 CPU→CUDA→TensorRT），找到当前硬件上的最佳组合。不同模型的最优配置可能不同，一切以实测为准。整体收益可以量化：

报表不会说谎。图优化的每一项准备，最终都要折算成“出菜更快、占台更少”的真金白银——这也是推理引擎优化技术最打动人的地方。

Speedup=TbaselineTALL\displaystyle \text{Speedup} = \frac{T_{\text{baseline}}}{T_{\text{ALL}}}
这个式子衡量“全量优化”带来的端到端加速：基线延迟除以全优化延迟，得到综合加速比。
  1. 测量基线延迟关闭优化后，取 N 次推理的平均耗时
    Tbaseline=1N∑i=1Nti(0)\displaystyle T_{\text{baseline}} = \frac{1}{N}\sum_{i=1}^{N} t_i^{(0)}
  2. 测量全量优化延迟开启 ORT_ENABLE_ALL 后重复测量
    TALL=1N∑i=1Nti(99)\displaystyle T_{\text{ALL}} = \frac{1}{N}\sum_{i=1}^{N} t_i^{(99)}
  3. 计算最终收益加速比越大，表示优化后处理速度越快
    Speedup=TbaselineTALL\displaystyle \text{Speedup} = \frac{T_{\text{baseline}}}{T_{\text{ALL}}}

AI 应用场景

在线图片识别服务（云端推理）

阶段：推理服务部署与性能优化

解决的问题：图片识别 API 要支撑高并发请求，P99 延迟直接决定用户体验和成本。未优化的模型每个请求都执行大量冗余算子，中间张量反复读写显存，GPU 利用率偏低。借助 ONNX Runtime 的图优化——特别是算子融合与布局优化——在模型加载时自动压缩计算路径，减少内核启动，让每个请求的成本明显下降。

具体案例：某视觉服务商将分类模型从 PyTorch 导出为 ONNX 后，用 ORT 的 ORT_ENABLE_ALL 加载，配合 CUDA EP。实测 P99 延迟从 12ms 降到 5ms，单卡吞吐量提升近一倍，机器数量相应减少。整个过程只需修改加载代码，模型本身零改动。

边缘端实时检测（智能摄像头）

阶段：边缘部署与资源受限优化

解决的问题：边缘设备算力、内存、功耗都受限，模型必须“精打细算”地运行。扩展优化中的内存规划复用让多个中间张量共享缓冲区，降低峰值内存占用；布局优化让卷积在 CPU 或 NPU 上跑得更快。

具体案例：一款智能摄像头部署 YOLO 风格检测模型，内存峰值从 480MB 降到 310MB，帧率从 18FPS 提升到 30FPS。核心是开启 ORT_ENABLE_EXTENDED 的算子融合与内存复用，并为 CPU EP 启用 NHWC 布局优化。

大规模推荐系统（资源调度）

阶段：模型上线与容量规划

解决的问题：推荐系统推理集群中，延迟和吞吐直接决定服务器数量。图优化带来的延迟降低可以换算成机器减少，是容量规划的重要杠杆。通过对比不同优化级别和 EP 组合，找到每类模型的最优配置。

具体案例：某电商推荐团队对点击率预估模型做 ORT 调优，关闭优化测基线后逐级开启，发现 ORT_ENABLE_ALL 比 ORT_ENABLE_EXTENDED 又快了 15%，同时显存下降 22%。新配置上线后，峰值时段机器数量减少了 30%。

Python 演示

python65 行
import timeimport numpy as npimport onnxfrom onnx import helper, TensorProtoimport onnxruntime as ort  def build_demo_model():    # 两个常量: 2.0 和 3.0    c1 = onnx.numpy_helper.from_array(np.array([2.0], dtype=np.float32), name="c1")    c2 = onnx.numpy_helper.from_array(np.array([3.0], dtype=np.float32), name="c2")    x = helper.make_tensor_value_info("x", TensorProto.FLOAT, [1, 1])    y = helper.make_tensor_value_info("y", TensorProto.FLOAT, [1, 1])     nodes = [        # 常数加法: c2 + c1 = 5, 可被常量折叠        helper.make_node("Add", ["c2", "c1"], ["t2"], name="Add_const"),        # 输入加法: x + c1        helper.make_node("Add", ["x", "c1"], ["t1"], name="Add_input"),        # 恒等节点: 对结果无影响, 可被冗余消除        helper.make_node("Identity", ["t1"], ["t3"], name="Identity_node"),        # 最终输出: t3 + t2        helper.make_node("Add", ["t3", "t2"], ["y"], name="Add_final"),    ]    graph = helper.make_graph(nodes, "demo_graph", [x], [y], initializer=[c1, c2])    return helper.make_model(graph, opset_imports=[helper.make_opsetid("", 13)])  def run_with_level(model_path, level):    opts = ort.SessionOptions()    opts.graph_optimization_level = level    sess = ort.InferenceSession(model_path, opts, providers=["CPUExecutionProvider"])    x = np.array([[5.0]], dtype=np.float32)    for _ in range(5):      # 预热        sess.run(None, {"x": x})    times = []    for _ in range(50):     # 正式计时        t0 = time.perf_counter()        sess.run(None, {"x": x})        times.append(time.perf_counter() - t0)    return float(np.mean(times[5:])) * 1000  # 去掉前5次, 取毫秒  def main():    model = build_demo_model()    onnx.checker.check_model(model)    onnx.save(model, "demo_model.onnx")    print("== 模型信息 ==")    print("节点数:", len(model.graph.node))    print("节点列表:", [n.name for n in model.graph.node])    print("\n== 不同优化级别推理耗时对比 ==")    levels = [        (ort.GraphOptimizationLevel.ORT_DISABLE_ALL, "关闭优化"),        (ort.GraphOptimizationLevel.ORT_ENABLE_BASIC, "基本优化"),        (ort.GraphOptimizationLevel.ORT_ENABLE_EXTENDED, "扩展优化"),        (ort.GraphOptimizationLevel.ORT_ENABLE_ALL, "全部优化"),    ]    for level, name in levels:        ms = run_with_level("demo_model.onnx", level)        print(f"{name}: {ms:.3f} ms")    print("\n提示: 小模型优化后耗时可能无显著差异, 但图中被折叠/消除的节点会减少运行开销.")  if __name__ == "__main__":    main()
目的：构造一个含常量加法和恒等节点的 ONNX 模型，用不同图优化级别加载并测量推理耗时，直观感受优化级别对推理路径的影响。
  1. opts.graph_optimization_level = level设置图优化级别，决定 ORT 加载模型时应用哪一档优化
  2. sess = ort.InferenceSession(model_path, opts, providers=["CPUExecutionProvider"])创建推理会话，图优化在此刻自动完成
  3. helper.make_node("Add", ["c2", "c1"], ["t2"], name="Add_const")构造常量加法，给优化器一个“常量折叠”的机会
  4. helper.make_node("Identity", ["t1"], ["t3"], name="Identity_node")构造恒等节点，给优化器一个“冗余消除”的机会
  5. onnx.checker.check_model(model)校验模型结构合法性，确保优化前没有基础错误
  6. for _ in range(5):预热循环，让缓存和调度器进入稳定状态后再计时
  7. return float(np.mean(times[5:])) * 1000去掉前 5 次异常值，将平均耗时转为毫秒
  8. (ort.GraphOptimizationLevel.ORT_DISABLE_ALL, "关闭优化")定义“关优化”对照组，作为性能调优的基线

常见误区

误区我以为是训练框架在训练过程中就自动把模型优化好了，推理时换个框架也不会差太多。

正解图优化发生在推理引擎加载模型时，而不是训练时。训练框架的优化主要服务于反向传播；ORT 这类推理引擎的图优化针对的是前向计算。同一个 ONNX 模型，用不同推理引擎或不同优化级别加载，运行效率差异巨大。

为何常见：“优化”这个词常和训练（SGD、学习率）绑定，容易让人误以为推理侧优化也是训练流程的一部分。

误区既然 ORT_ENABLE_ALL 包含所有优化，那永远选 ALL 就对了，不用纠结。

正解ORT_ENABLE_ALL 会应用布局优化等“有代价”的变换。对某些小模型或特定硬件，插入 Transpose 的开销可能超过布局收益，反而使延迟变高。正确的做法是逐级开启并实测，用数据选配置，而不是无脑开满。

为何常见：直觉上认为“功能叠加一定等于效果叠加”，忽略了优化之间存在权衡与代价。

误区看到模型开启了图优化，就觉得 CPU、GPU 上跑起来都一样快。

正解基本和扩展优化的通用性强，但布局优化是 EP 感知的，只对特定硬件生效。同一个 NCHW→NHWC 变换，在一款 CPU 上是加速，在另一款 GPU 上可能是负优化。ORT 的优化器会结合 EP 信息进行决策，不同硬件的优化路径并不相同。

为何常见：把“计算图”看成纯抽象的数学对象，忽略了它最终要落在具体硬件上执行。

误区以为图优化只是像任务调度一样调整一下执行先后，计算图本身不会有变化。

正解恰恰相反，优化会大幅修改图结构：常量折叠用新节点替换子图，冗余消除直接删节点，算子融合把多个节点合并成一个。优化后的图，拓扑结构和节点集合都变了，只是输入输出语义保持不变。

为何常见：用户看到“模型文件没变、结果没变”，容易推断出“内部也没变”，忽视了加载期发生的图变换。

误区模型线上推理慢，第一反应就是优化级别没调高，或者在代码里找是不是漏开了某个开关。

正解图优化只能优化“计算图本身”的开销。如果瓶颈在数据加载、预处理、后处理、CPU-GPU 拷贝、线程调度等环节，图优化帮不上忙。正确的排查方式是用 profiling 工具定位瓶颈阶段，再针对性解决。

为何常见：图优化名字响亮，容易让人把所有性能问题都归因到它头上，忽略了推理链路中其他环节的存在。

面试题

Q1. ONNX Runtime 的图优化在哪个阶段执行？

单选题 · easy

  • A.模型训练阶段
  • B.模型加载阶段← 正确答案
  • C.每次前向推理时
  • D.数据预处理阶段

答案：B。图优化在创建 InferenceSession 加载模型时自动完成。训练阶段做的是梯度更新，每次推理只是执行已优化好的计算图，数据预处理与图优化无关。大厨备菜是在“开火前”完成的，而不是每炒一道菜都重新备一次。

Q2. 常量折叠的核心做法是什么？

单选题 · easy

  • A.将多个节点合并成一个内核
  • B.预先执行常量运算并替换结果← 正确答案
  • C.删除所有对输出无用的节点
  • D.调整张量在内存中的存储布局

答案：B。常量折叠是在模型加载时，把输入全为常量的子图先算出来，用常量节点替换。A 是算子融合，C 是冗余消除，D 是布局优化。就像大厨提前调好照烧汁，而不是每道菜都重新称量配料。

Q3. 以下哪一项属于基本优化？

单选题 · easy

  • A.算子融合
  • B.常量折叠← 正确答案
  • C.布局变换
  • D.内核库替换

答案：B。基本优化包含常量折叠、冗余节点消除等最安全、收益确定的变换。算子融合和内核库替换属于扩展优化，布局变换专属于布局优化级别。基本优化就是备菜第一步：扔垃圾、调酱料。

Q4. 算子融合最直接的好处是什么？

单选题 · mid

  • A.减少模型参数总量和模型体积
  • B.减少内核启动与中间张量读写← 正确答案
  • C.提升模型在测试集上的精度
  • D.让推理图更便于人类阅读理解

答案：B。算子融合把多个连续算子合并为一个内核，中间结果不再写回主存，同时减少内核启动次数。它不改变参数量、不提升精度，也不是为了“好看”，而是为了减少访存和启动开销——就像把配菜装进一个码斗，少跑几趟灶台。

Q5. 布局优化主要针对什么进行？

单选题 · mid

  • A.模型训练时的学习率策略
  • B.不同EP对数据布局的偏好← 正确答案
  • C.损失函数对梯度的回传路径
  • D.训练数据在磁盘上的存储格式

答案：B。布局优化根据执行提供者（EP）偏好的数据布局，在子图边界插入 Transpose 调整张量排布，如 NCHW 与 NHWC 互转。它与训练策略、损失函数、磁盘存储无关。就像大厨根据灶台类型重新摆放锅碗。

Q6. 布局优化中插入的 Transpose 节点，在推理时的执行方式是什么？

单选题 · extreme

  • A.编译期自动消除且运行时零开销
  • B.在目标EP上作为普通内核执行← 正确答案
  • C.只在训练阶段参与前向计算
  • D.由用户手动调用触发执行

答案：B。Transpose 是实际存在的数据重排算子，在推理时作为普通内核在目标 EP 上真实执行，是有开销的。它不会在编译期凭空消失，也不是训练专属，更不需要用户手动触发。正因为转置有成本，布局优化才要权衡收益再决定是否插入。

Q7. 关于 ORT_ENABLE_EXTENDED 优化级别，正确的是？

单选题 · hard

  • A.它仅包含算子融合不包括其他优化
  • B.它包含基本优化并叠加扩展优化← 正确答案
  • C.它专门服务于GPU上的推理加速
  • D.它关闭了所有图优化相关功能

答案：B。ORT 的优化级别是逐层包含的，ORT_ENABLE_EXTENDED = 基本优化 + 扩展优化（算子融合、内核库替换、内存规划复用等）。它不局限 GPU，也没有关闭优化。这就像“扩展套餐”一定包含“基础套餐”的内容。

Q8. 扩展优化包括哪些技术？（多选）

多选题 · mid

  • A.算子融合技术← 正确答案
  • B.内核库节点替换← 正确答案
  • C.常量折叠优化
  • D.内存规划复用← 正确答案

答案：ABD。扩展优化的典型技术包括算子融合、用高性能内核库替换标准节点、基于生命周期分析的内存规划复用。常量折叠属于基本优化，不在扩展优化范畴。扩展优化 = 在基本优化的基础上“合并工序、换趁手的工具”。

Q9. 以下哪些属于 ONNX Runtime 的执行提供者？（多选）

多选题 · mid

  • A.CPU执行提供者← 正确答案
  • B.CUDA执行提供者← 正确答案
  • C.数据加载器执行
  • D.TensorRT执行者← 正确答案

答案：ABD。常见的 EP 包括 CPUExecutionProvider、CUDAExecutionProvider、TensorRTExecutionProvider 等，它们封装了不同硬件的后端。不存在“数据加载器执行”这种 EP，数据加载不属于 EP 的职责。EP 是后厨里的一排灶台，各有各的专长。

Q10. 图优化在实际部署中能带来哪些收益？（多选）

多选题 · hard

  • A.降低推理服务延迟← 正确答案
  • B.减少峰值显存占用← 正确答案
  • C.提升模型准确率
  • D.提高服务吞吐能力← 正确答案

答案：ABD。图优化通过减少无效计算、合并算子、复用内存、调整布局，来降低延迟、减少显存占用、提升吞吐量。但优化保持数学语义不变，不提升模型准确率——准确率是训练阶段决定的。就像备菜能加快出菜速度，但不会让菜本身变得更好吃。