想象你刚搬进一间老房子。厨房里水槽在最里面、灶台靠门口、吊柜堆满杂物——做一顿饭要在三个角落来回跑二十趟。ONNX Runtime 的“图优化”就是一次厨房改造：它先画一张“厨房平面图”（计算图），然后按不同力度帮我们把水槽、砧板、灶台重新布局，把永远不变的料汁提前调好，把洗切炒合成一个集成灶，把没用的吊柜全部扔掉。改造成度有四个档位：从只擦灰到精装。本文就用这次改造之旅，带你彻底搞懂 Graph Optimization Level——AI 推理引擎里最接地气的性能加速术。

岗位关联

对 AI 从业者而言，理解图优化级是性能调优的必修课：同样的模型，正确的优化级别能让推理快数倍、内存降一半，是推理引擎与 ML 平台工程师的核心竞争力。

目录
  1. 可视化演示
  2. 基本概念
  3. 四个级别
  4. 常量折叠
  5. 算子融合
  6. 冗余消除
  7. 优化配置
  8. 性能影响
  9. 实践建议
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

演示ONNX Runtime不同Graph Optimization Level下算子融合与执行加速的逐步增强，展示优化级别与运行时性能的对应关系。

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

Graph Optimization Level Basic Extended Layout 级别越高融合越多

基本概念

想象你刚搬进一间老房子。厨房里的一切都保持原样——笨重的双门冰箱紧挨窗台，水槽在最里面，灶台却靠近门口。这个布局虽然能用，但每次做饭你得端着菜盆横跨整个厨房。在 AI 的世界里，这种“布局”叫计算图（Computational Graph）：它是模型所有运算步骤的“平面图”，画出了数据如何从一个算子流向另一个算子。

ONNX Runtime 是一个“厨房改造团队”。它不可能一上来就动工，得先拿到这份平面图，然后按你的需求做优化。这个优化动作就是图优化（Graph Optimization）。图优化的终极目的只有一个——让推理跑得更快、占得更少，就像好的厨房布局让你少走冤枉路。ONNX Runtime 这类负责把模型跑起来的系统，我们叫它推理引擎，它是 AI 上线后的“总厨师长”。

在数学上，计算图可以精确地写成一张二元组：

拿到这份“厨房布局图”后，ONNX Runtime 这个改造团队就要开始决定：改造到什么程度？是简单粉刷一下，还是大拆大建？这就引出了优化级别的概念。

G=(V,E)\displaystyle G = (V, E)
一个计算图由“节点集合 V”和“边集合 E”构成：每个节点是一个算子，每条边是张量数据的流向。
  1. 节点集 V图中的每个圆圈是一个算子（如 Add、Relu、MatMul），相当于厨房里的一件电器（水槽、灶台、冰箱）。
    V={v1,v2,…,vn}\displaystyle V = \{v_1, v_2, \ldots, v_n\}
  2. 边集 E连接两个节点的箭头，表示数据张量从上游节点流向下游节点，相当于厨师从冰箱到砧板的动线。
    E={(vi,vj)∣vi→vj}\displaystyle E = \{(v_i, v_j) \mid v_i \to v_j\}
  3. 语义保持变换图优化把原图 G 变成新图 G'，但二者在“同样的输入给出同样的输出”上完全等价——改造厨房可以挪电器，但绝不能让你没法做饭。
    G⇒G′,s.t.fG(x)=fG′(x)\displaystyle G \Rightarrow G', \quad \text{s.t.} \quad f_G(x) = f_{G'}(x)

四个级别

装修公司问你：“老哥，你想怎么改？”你摸了摸钱包，说：“分四种吧：不生锈就行、一般般顺眼、不差钱、怎么顺手怎么来。”ONNX Runtime 的图优化也分了四档，官方叫 GraphOptimizationLevel 枚举。从完全不动到全量优化，每种级别都对应不同的“装修预算”。

这四档分别是：ORT_DISABLE_ALL（0），完全不优化，原样执行，相当于只请保洁不请装修；ORT_ENABLE_BASIC（1），基础优化，做常量折叠、冗余消除等“不动大结构”的活儿，相当于给厨房重新粉刷、把明显碍事的东西挪一挪；ORT_ENABLE_EXTENDED（2），扩展优化，在基础之上再做算子融合等更激进的改造，相当于把水电线路都重排了；ORT_ENABLE_ALL（3），全部优化，包含所有能做的优化，包括与特定硬件（如 GPU、NPU）相关的深度融合，相当于精装大改造。

你可以把“是否敢动承重墙”（是否改变算子之间的融合边界）作为分档依据：越往后的级别，越敢大改结构。四个级别的强度关系可以写成：

你选了“基础优化”，装修队进场后第一件事往往是——把那些永远不变的“老规矩”直接固化下来。这就是图优化里的常量折叠。

Ldisable<Lbasic<Lextended<Lall\displaystyle L_{\text{disable}} < L_{\text{basic}} < L_{\text{extended}} < L_{\text{all}}
这串不等式表示优化力度逐级增强：处理的手段越来越多，性能天花板也越来越高。
  1. 级别取值L 是优化等级的记号，在 ONNX Runtime 的枚举里对应 0 到 3 四个整数。
    L∈{0,1,2,3}\displaystyle L \in \{0, 1, 2, 3\}
  2. 代价与收益级别越高，编译期（会话创建时）花在“设计新布局”上的时间越长，但换来的是推理期（运行时）更短的延迟——精装前要量尺定做，装完住着才舒服。
    tsetup(Lall)≫tsetup(Ldisable)\displaystyle t_{\text{setup}}(L_{\text{all}}) \gg t_{\text{setup}}(L_{\text{disable}})

常量折叠

你发现每周都做糖醋排骨，每次都要重新调酱汁：生抽两勺、醋一勺、糖半勺……麻烦死了。于是你干脆提前调好一瓶“秘制糖醋汁”存起来，做菜时直接倒。常量折叠（Constant Folding）就是这个思路的计算机版。

在模型里，有些算子的输入是永远不变的常量，比如权重矩阵、固定超参数。每次推理都重新计算这些“永远不变”的结果，纯属浪费。图优化会在编译期把 常量 + 常量 这类子图先算好，把结果塞进一个新常量节点，推理时直接取值，连算子都不用执行。

具体来说，如果算子 f 的所有输入都是编译期已知的常量张量，优化器就提前执行这段计算：

调好的酱汁瓶放在调料架上，做菜时直接倒——省下了洗姜切蒜调味的全套工夫。但这只是第一步，接下来装修队会说：“你这水槽、砧板、灶台隔得太远，我给你合成一个集成灶。”

f(c1,c2)⇒v,v=f(c1,c2)\displaystyle f(c_1, c_2) \Rightarrow v, \quad v = f(c_1, c_2)
常量折叠把“由常量输入推出的新常量”在编译期算出结果 v，并用这个常量节点替换原来的子图，从而在推理期省掉这段计算。
  1. 模式匹配遍历计算图，找到所有输入都是常量的算子——就像扫一眼调料架，发现所有料都齐了。
    op(vi)wherevi∈Constant,∀i\displaystyle \text{op}(v_i) \quad \text{where} \quad v_i \in \text{Constant}, \forall i
  2. 预计算在编译期调用该算子的内核完成数值运算，得到确定的结果张量 v——提前把料汁调好装瓶。
    v=op(c1,c2,…,ck)\displaystyle v = \text{op}(c_1, c_2, \ldots, c_k)
  3. 子图替换用常量节点 v 替换整个子图，原算子节点失去作用变成了“死节点”（下一节讲怎么清理）。
    Subgraph(c1,c2,op)→Const(v)\displaystyle \text{Subgraph}(c_1, c_2, \text{op}) \to \text{Const}(v)

算子融合

旧厨房里水槽在左、砧板在中、灶台在右，每道菜都要端着菜盘来回走三趟。装修队建议学集成灶：把“洗-切-炒”合并到一张智能台面上，食材从左端进去，熟菜从右端出来。算子融合（Operator Fusion）就是这个“集成灶”。

以经典的 MatMul + Add 为例：模型先做矩阵乘法，再把偏置加进去。如果不融合，推理引擎需要先把 MatMul 的中间结果写回内存，然后 Add 算子再把它读出来做加法。中间结果写进内存又读出来，是典型的性能浪费。融合之后，一个融合内核 FusedMatMulAdd 在 CPU/GPU 的寄存器级别就完成了两步，中间结果根本不落内存。

算子融合的数学本质是构造复合算子。两个相邻算子 f 和 g 原本顺序执行：

集成灶的妙处是“食材不过夜”——洗好的菜从左边递进去，右边装盘，中间直接在灶台上一体炒完。在 AI 推理里，数据不过内存，自然快得多。

h(x)=g(f(x))\displaystyle h(x) = g(f(x))
融合把 f 和 g 的组合 h 交给单一内核一次执行，省去中间激活值在内存中的写回与重读。
  1. 复合函数h 是 f 和 g 的复合，输入 x 先经过 f 再经过 g——菜先洗再炒。
    h(x)=g(f(x))\displaystyle h(x) = g(f(x))
  2. 内核合并h 由单个内核实现。设中间激活值 m = f(x)，分离执行需要先把 m 写回内存，再由 g 读回；融合后 m 留在寄存器或片上缓存。
    Kernelh=Kernelg∘Kernelf\displaystyle \text{Kernel}_h = \text{Kernel}_g \circ \text{Kernel}_f
  3. 访存节省融合省下了中间张量的写回代价 C_w 和读回代价 C_r，这是加速的主要来源。
    Δsave=Cw(m)+Cr(m)\displaystyle \Delta_{\text{save}} = C_w(m) + C_r(m)

冗余消除

老厨房的吊柜里堆着发霉的绿豆、过期的酱油，还有一口从没用过的铸铁锅。这些“僵尸”占了地方，还让你每次找东西都要翻半天。冗余消除（Redundancy Elimination）就是装修队帮你清空吊柜、扔掉永远不用的旧物，把厨房动线重新理顺。

图优化里的冗余主要来自两类。第一类是死节点：常量折叠或其他优化之后，有些算子节点的输出再也没有消费者，整个子图成了“僵尸区域”，留着只会白白增加调度开销。第二类是公共子表达式：图里两处计算一模一样的东西，比如同样的 x * 2 出现两次，完全可以复用第一次的结果，不用重复劳动。

设原图 G = (V, E)，冗余消除之后得到更精简的图 G'：

清完吊柜，厨房一下子清爽了。但改造队队长这时拿出施工单问你：“你确认要这么改吗？”你点头，于是他在施工单上勾选了“优化级别”。这张施工单，就是 ONNX Runtime 的 SessionOptions。

G′=G∖{vd}\displaystyle G' = G \setminus \{v_d\}
其中 v_d 是死节点集合：它们的输出无法沿任何路径到达最终输出，对结果毫无贡献，直接删除。
  1. 定义死节点一个节点 v 的所有输出边都不被任何“关键输出”消费，则 v 对最终结果无贡献——旧吊柜从来没人打开过。
    dead(v)  ⟺  ∄ path from v to output\displaystyle \text{dead}(v) \iff \nexists\, \text{path from } v \text{ to } \text{output}
  2. 回溯删除从输出端反向做引用计数，当某节点输出边的引用数降到 0 时把它从图里移除。
    ref(v)=0⇒v removed\displaystyle \text{ref}(v) = 0 \Rightarrow v \text{ removed}
  3. 公共子表达式合并若两个节点 v_a、v_b 的算子类型与输入完全相同，把它们的输出合并为同一份——同样的料汁只调一瓶，大家共用。
    va≡vb⇒vb→va\displaystyle v_a \equiv v_b \Rightarrow v_b \to v_a

优化配置

装修合同上你有三处要“打勾”：要不要大改、哪些区域要动、什么时候施工。ONNX Runtime 的 SessionOptions 就是这份施工单——所有图优化相关的决定都写在这里。

在实际代码里，配置优化级别只需三步：创建 SessionOptions 对象，设置 graph_optimization_level 属性，把它传给 InferenceSession 构造函数。

默认情况下，ONNX Runtime 使用 ORT_ENABLE_ALL（全部优化）——相当于装修队默认按最高标准方案进场。配置里还有一个实用参数 optimized_model_filepath，可以把优化后的图序列化到磁盘，下次加载直接跳过优化阶段，有点像是把装修方案存档，下次搬新家直接复刻。

优化配置和推理性能之间存在一个基本权衡：

施工单签完，装修队进场两个月。等厨房交付那天，你站在崭新的厨房里，看着新布局，忍不住算了一笔账：以前做一顿饭一个小时，现在二十分钟。这就是性能影响。

tsession=toptimize+tinference\displaystyle t_{\text{session}} = t_{\text{optimize}} + t_{\text{inference}}
优化级别越高，建会话阶段的时间 t_optimize 越大，但单次推理时间 t_inference 越小。
  1. 总耗时分解会话总时间由两部分构成——优化阶段发生在会话创建时，推理阶段发生在每次运行时。
    tsession=toptimize+tinference\displaystyle t_{\text{session}} = t_{\text{optimize}} + t_{\text{inference}}
  2. 摊销权衡跑 N 次推理时，单次推理的平均成本是优化开销均摊后加上推理延迟。
    tˉ=toptimizeN+tinference\displaystyle \bar{t} = \frac{t_{\text{optimize}}}{N} + t_{\text{inference}}
  3. 决策准则当 N 趋向无穷大时，优化开销均摊趋近于 0，因此高优化级别对高频推理几乎总是有利的——装修一次，住十年，摊到每天没多少。
    lim⁡N→∞toptimizeN=0\displaystyle \lim_{N \to \infty} \frac{t_{\text{optimize}}}{N} = 0
python5 行
import onnxruntime as ort sess_options = ort.SessionOptions()sess_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALLsession = ort.InferenceSession('model.onnx', sess_options)

性能影响

改造前，你在旧厨房做一顿饭要 60 分钟，改造后只要 20 分钟。这个“省下来的时间比”在性能优化里叫加速比（Speedup）。图优化带来的性能影响，就是这本清清楚楚的账。

图优化主要在三个维度改善性能。第一是推理延迟：单次推理耗时从 10ms 降到 4ms，最直观。第二是吞吐量：单位时间能处理的样本数，延迟降了，服务端每个 worker 每秒能跑的请求数自然升上去。第三是内存占用：常量折叠消除了中间张量，算子融合减少了缓冲申请，峰值显存和内存都降下来。

加速比的定义很直白：

账本是漂亮的，但装修队撤场时留下一句话：“建议你别急着高兴，先按新厨房的动线做一周的菜，看看是不是真的顺心。”这提醒我们：图优化不是无脑开最高档最合适，需要根据场景做基准测试。

S=tbaselinetoptimized\displaystyle S = \frac{t_{\text{baseline}}}{t_{\text{optimized}}}
加速比 = 基线延迟 ÷ 优化后延迟。S > 1 说明优化有效，S 越大越快。
  1. 基线时间t_baseline 指未做任何图优化的推理延迟（用 ORT_DISABLE_ALL 或原始模型测得）——装修前的旧厨房做饭时间。
    tbaseline=latency(Ldisable)\displaystyle t_{\text{baseline}} = \text{latency}(L_{\text{disable}})
  2. 优化时间t_optimized 是启用目标优化级别后的平均延迟，注意要把建会话的优化开销按请求数均摊进去。
    tˉopt=toptimizeN+latency(Ltarget)\displaystyle \bar{t}_{\text{opt}} = \frac{t_{\text{optimize}}}{N} + \text{latency}(L_{\text{target}})
  3. 加速比两者相除得到“快了多少倍”。ONNX Runtime 官方基准中，在典型 CV/NLP 模型上启用全部优化相比不启用，CPU 端通常有 1.5~4 倍加速，GPU 端约 1.2~2 倍。
    S=tbaselinetˉopt>1\displaystyle S = \frac{t_{\text{baseline}}}{\bar{t}_{\text{opt}}} > 1

实践建议

装修完的厨房，你不可能看了一眼就签字交付。你得开火试菜、测油烟机吸力、数储物格。基准测试（Benchmark）就是你的“验收试菜”，是判断图优化级别是否值得的最终标准。

实践建议可以总结为三条。第一，建基准测试仓库：用代表真实数据的样本加上代表性模型（如 ResNet50、BERT-base），对四个优化级别分别测延迟和吞吐。第二，按场景选级别：延迟敏感型应用（在线推荐、实时翻译）优先 ORT_ENABLE_ALL；资源受限的边缘设备要关注激进优化是否带来额外内存峰值，必要时降到 EXTENDED。第三，留意不确定因素：不同硬件和算子库版本下，同一模型的优化收益可能不同；某些融合操作可能改变数值行为（比如把多个操作合并后精度略有变化），必须用精度回归测试兜住。

实践中最好用的一个决策公式是“优化性价比”——每花 1 秒优化时间换来的加速收益：

厨神不是天生的，而是反复试菜试出来的。图优化也一样——今天你记住了四个级别、三种优化手段、一套验收方法，就已经完成了从“看到图就头痛”到“对着图优化游刃有余”的蜕变。

E=Stoptimize\displaystyle E = \frac{S}{t_{\text{optimize}}}
加速比 S 是收益，优化耗时 t_optimize 是成本。性价比 E 最大的优化级别，才是你的最优档位。
  1. 收益S 是加速比，代表图优化带来的性能提升——改造后每顿饭省下的分钟数。
    S=tbaselinetoptimized\displaystyle S = \frac{t_{\text{baseline}}}{t_{\text{optimized}}}
  2. 成本t_optimize 是会话构建阶段花在图优化上的时间——装修队进场的施工天数。
    toptimize=time(build session with L)\displaystyle t_{\text{optimize}} = \text{time}(\text{build session with } L)
  3. 最优级别在所有可选级别中，挑出性价比最高的那个——既不要为了省钱住毛坯房，也别为了豪装等半年。
    L∗=arg⁡max⁡LS(L)toptimize(L)\displaystyle L^* = \arg\max_{L} \frac{S(L)}{t_{\text{optimize}}(L)}

AI 应用场景

在线推荐服务的延迟优化

阶段：推理部署与性能调优

解决的问题：传统方式下，推荐模型在 CPU 上直接跑原始 ONNX 模型，推理延迟高达 18ms，超过业务方要求的 10ms SLA。每次新增请求都要排队，用户体验明显卡顿。

具体案例：某电商平台将 PNN 推荐模型导出为 ONNX 格式，接入 ONNX Runtime 并开启 ORT_ENABLE_ALL。图优化自动完成了 MatMul+Add 融合、LayerNorm 融合和常量折叠，延迟从 18ms 降到 6ms，吞吐量提升了 2.1 倍，服务端只需要原来一半的机器。

边缘摄像头的内存瘦身

阶段：模型部署与资源优化

解决的问题：边缘设备内存紧张，目标检测模型在弱优化级别下推理内存峰值高达 900MB，而设备只有 512MB 可用内存，传统方案只能不断手动裁剪算子、反复试错。

具体案例：某安防厂商在智能摄像头上改用 ONNX Runtime，选择 ORT_ENABLE_EXTENDED 而非全量优化，配合常量折叠消除了大量中间张量，峰值内存降到 380MB，推理延迟仍保持在可接受的 35ms，成功在低成本芯片上跑通了实时检测。

大模型服务的冷启动加速

阶段：服务启动与弹性扩容

解决的问题：大模型服务每次新起一个 Pod，都要重新做图优化，冷启动时间长达 5 秒。高峰期自动扩容时，新实例迟迟不能接流量，体验很差。

具体案例：某 NLP 团队在 BERT 服务中启用 optimized_model_filepath，把优化后的计算图持久化到共享存储。新实例加载时跳过优化阶段，冷启动从 5 秒降到 0.3 秒，扩容速度提升 15 倍。

Python 演示

python58 行
"""演示 ONNX Runtime 图优化级别对推理延迟的影响(模拟版)"""import random  class GraphOptimizationLevel:    ORT_DISABLE_ALL = 0    ORT_ENABLE_BASIC = 1    ORT_ENABLE_EXTENDED = 2    ORT_ENABLE_ALL = 3  LEVEL_NAMES = [    "ORT_DISABLE_ALL",    "ORT_ENABLE_BASIC",    "ORT_ENABLE_EXTENDED",    "ORT_ENABLE_ALL",] # 各优化级别相对禁用优化的延迟比例(模拟数据)LATENCY_RATIO = [1.0, 0.62, 0.42, 0.28]  class SessionOptions:    def __init__(self):        self.graph_optimization_level = GraphOptimizationLevel.ORT_ENABLE_ALL  class InferenceSession:    def __init__(self, model_path, sess_options=None):        opts = sess_options or SessionOptions()        self.level = opts.graph_optimization_level        self._latency = 10.0 * LATENCY_RATIO[self.level]        self._rng = random.Random(42)     def run(self, input_name, input_data):        noise = self._rng.uniform(0.97, 1.03)        return self._latency * noise  def benchmark(session, n_runs=100):    total = 0.0    for _ in range(n_runs):        total += session.run("x", [1.0])    return total / n_runs  if __name__ == "__main__":    baseline = None    print("=== ONNX Runtime 图优化级别模拟对比 ===")    for level in range(4):        opts = SessionOptions()        opts.graph_optimization_level = level        sess = InferenceSession("model.onnx", opts)        lat = benchmark(sess)        if level == 0:            baseline = lat        speedup = baseline / lat        print(f"{LEVEL_NAMES[level]:<20} 延迟 {lat:5.2f} ms  加速比 {speedup:4.2f}x")
目的：用模拟数据展示四个图优化级别对推理延迟与加速比的影响。真实环境中，把 InferenceSession 替换为 onnxruntime.InferenceSession，并把 SessionOptions 换成 onnxruntime.SessionOptions() 即可直接复用。
  1. LATENCY_RATIO = [1.0, 0.62, 0.42, 0.28]预定义四档优化级别对应的延迟缩减比例，模拟“级别越高、延迟越低”
  2. opts.graph_optimization_level = level这是 ONNX Runtime 实践中最核心的配置行，直接决定装修队动工力度
  3. self._latency = 10.0 * LATENCY_RATIO[self.level]模拟推理延迟 = 基线延迟 × 优化系数
  4. noise = self._rng.uniform(0.97, 1.03)加入 3% 以内的随机噪声，模拟真实运行时的抖动
  5. speedup = baseline / lat加速比 = 基线延迟 ÷ 优化后延迟，对应正文中的公式
  6. if level == 0: baseline = lat以禁用优化级别作为性能对比的基准线

常见误区

误区“我直接把 `ORT_ENABLE_ALL` 打开，所有模型肯定最快！默认就是最高档，那就不用想了。”

正解ALL 是绝大多数情况下的推荐解，但并非恒定最优。高优化级别会在建会话时消耗更多 CPU 做图分析和内核选择，大模型场景下冷启动可能从 0.5 秒飙到 5 秒。极端内存受限的边缘设备上，激进融合还可能临时抬高内存峰值。正确做法是永远用基准测试数据说话，而不是拍脑袋开最高档。

为何常见：把“官方默认最高档”理解成“任何场景下的最优档”，忽略了编译期与推理期之间的权衡。

误区“图优化做了这么多变换，把算子都融合了，输出精度肯定变差了。”

正解图优化的核心约束是语义保持——优化前后的图在“相同输入 → 相同输出”上严格一致。浮点运算的重排可能带来 1e-7 级别的数值差异，但整体数学语义完全不变。真正改变精度的是量化、剪枝等“近似”手段，那属于模型压缩的范畴，不是图优化干的活。

为何常见：把“优化”和“模型压缩/量化”混为一谈，误以为所有优化都会以精度换速度。

误区“常量折叠把预计算的结果都存进 ONNX 文件里，导出后模型体积肯定膨胀不少。”

正解常量折叠处理的是“由常量输入推出的新常量”，这些中间张量通常比原始权重小，而且折叠操作发生在推理引擎加载图之后，并不会改变磁盘上 ONNX 文件的大小。文件体积的主要来源是权重本身，常量折叠反而消除了运行时临时计算的开销。

为何常见：误以为“预计算结果”必须存进文件才会生效，忽略了图优化是在内存中完成的。

误区“图优化做得好，建 session 应该和原来一样快，反正都是读同一个模型文件。”

正解优化级别越高，图分析、模式匹配、算子融合和内核选择的工作量越大，冷启动时间明显变长。行业里的标准解法是用 optimized_model_filepath 把优化后的图落盘缓存，下次加载直接跳过优化阶段——这才是“又快又稳”的正确姿势。

为何常见：把“推理快”等同于“整体快”，忽略了请求到达之前的一次性编译成本。

误区“GPU 上瓶颈是 CUDA 内核，图优化肯定没什么用。”

正解GPU 上同样有效。算子融合减少的是内核启动（kernel launch）开销和全局内存往返——这恰恰是 GPU 推理的常见瓶颈。把多个 elementwise 算子融合成一个内核，能省掉多次 kernel launch 的固定开销，也能让中间数据留在高速缓存里。

为何常见：以为图优化只是“减少 CPU 指令数”，不理解内存搬运在 GPU 推理中同样昂贵。

面试题

Q1. ONNX Runtime 中“禁用所有图优化”的枚举值是哪个？

单选题 · easy

  • A.ORT_ENABLE_BASIC
  • B.ORT_DISABLE_ALL← 正确答案
  • C.ORT_ENABLE_EXTENDED
  • D.ORT_ENABLE_ALL

答案：B。ORT_DISABLE_ALL 值为 0，表示完全不做图优化，相当于只请保洁不请装修。其他三个选项分别是基础、扩展和全部优化级别。

Q2. 常量折叠的核心意义是什么？

单选题 · easy

  • A.消除计算图中的死节点
  • B.把常量子图的运算提前到编译期← 正确答案
  • C.把多个算子合并成一个内核
  • D.减小模型文件的体积

答案：B。常量折叠检测“所有输入均为常量”的算子，在编译期提前算出结果 v=op(c1,c2)，推理时直接取值。选项 A 是冗余消除的职责，C 是算子融合，D 不是常量折叠的目标。

Q3. 算子融合最大的性能收益来自哪里？

单选题 · mid

  • A.减少了图中的算子数量
  • B.减少了中间张量的内存读写← 正确答案
  • C.提高了算子的并行度
  • D.增加了 CPU 的缓存容量

答案：B。融合把“中间结果写回内存、下一个算子再读出来”的往返省掉了。中间激活值留在寄存器或片上缓存里，内存访问代价 C_w+C_r 被消除，这才是加速的主要来源。

Q4. ONNX Runtime 默认使用的图优化级别是哪个？

单选题 · easy

  • A.ORT_DISABLE_ALL
  • B.ORT_ENABLE_BASIC
  • C.ORT_ENABLE_EXTENDED
  • D.ORT_ENABLE_ALL← 正确答案

答案：D。ONNX Runtime 创建 InferenceSession 时默认用 ORT_ENABLE_ALL，即最高档优化。实践中除非有特殊理由（如调试原生行为），不建议降到更低的级别。

Q5. 冗余消除主要针对以下哪类图元素？

单选题 · mid

  • A.模型的过拟合参数
  • B.死节点和公共子表达式← 正确答案
  • C.推理框架的版本问题
  • D.张量的数值精度损失

答案：B。冗余消除清理两类冗余：输出不被任何关键路径消费的“死节点”，以及重复计算相同内容的“公共子表达式”。它属于图结构化简，与参数、框架版本、数值精度无关。

Q6. 图优化必须满足的硬性约束是什么？

单选题 · mid

  • A.输出张量的形状必须变小
  • B.优化前后语义保持一致← 正确答案
  • C.模型文件必须变小
  • D.算子类型不能变化

答案：B。图优化的底线是语义保持：同样的输入，优化前后的图必须给出同样的输出。允许合并算子、删除节点，也允许内部实现变化，但计算结果不能错，就像改造厨房可以挪灶台，但不能让人做不了饭。

Q7. 加速比 S 的正确计算公式是哪个？

单选题 · easy

  • A.S = 优化后时间 ÷ 优化前时间
  • B.S = 优化前时间 ÷ 优化后时间← 正确答案
  • C.S = 优化前时间 + 优化后时间
  • D.S = 优化后时间 - 优化前时间

答案：B。加速比 S = t_baseline / t_optimized。S>1 表示优化有效，比如从 10ms 降到 4ms，S=2.5，也就是“快了 2.5 倍”。

Q8. 以下哪些属于图优化的常用手段？

多选题 · mid

  • A.常量折叠← 正确答案
  • B.算子融合← 正确答案
  • C.冗余消除← 正确答案
  • D.模型量化

答案：ABC。常量折叠、算子融合、冗余消除是图优化的三大手段，都发生在推理引擎的编译期。模型量化属于模型压缩领域，它改变权重精度和计算类型，不属于图优化的范畴。

Q9. 关于 ONNX Runtime 优化配置，下列说法正确的有哪些？

多选题 · mid

  • A.SessionOptions 可配置优化级别← 正确答案
  • B.优化后的图可落盘缓存← 正确答案
  • C.级别越高建会话越耗时← 正确答案
  • D.优化级别只影响 CPU 推理

答案：ABC。SessionOptions.graph_optimization_level 配置优化力度；optimized_model_filepath 可把优化后的图缓存到磁盘；优化级别越高，建会话时的图分析耗时越长。D 错误，算子融合在 GPU 上同样有效，减少 kernel launch 和全局内存往返。

Q10. 关于图优化对性能的影响，正确的有哪些？

多选题 · hard

  • A.图优化可降低推理延迟← 正确答案
  • B.图优化可能增加内存峰值← 正确答案
  • C.图优化能提升服务吞吐量← 正确答案
  • D.级别越高加速比必然单调递增

答案：ABC。延迟下降、吞吐提升是图优化的主要收益；但某些激进融合可能临时增加内存峰值，所以边缘设备要谨慎选档。D 错误，加速比不是单调的——模型结构、硬件、算子库版本都会影响实际收益，必须靠基准测试验证。