想象你是一家顶级宴会厅的总厨师长。宴会开席前，你手里拿着一张完整的做菜流程图：洗菜、切配、焯水、爆炒、装盘，每一站之间都有食材在传递。行家一看就知道，这张图有太多浪费——有些固定配料明明可以提前备好，却要等客人点菜时才临时处理；有些半成品在两个灶台间来回搬运，甚至反复进出冰柜；食材的切法也没考虑下一站厨师用起来顺不顺手。TVM 的 RELAY IR 图优化，干的就是“优化这张做菜流程图”的活：常量折叠是提前备好固定配料，算子融合是把相邻步骤并进一口锅，布局变换是换成更顺手的切配方式。本文就从这三张“优化卡片”讲起，带你看看编译器是怎样在正式开火之前，把整条流水线打磨得更快、更省的。看完你不仅能看懂官方优化 Pass 的套路，还能亲自动手写一张新的优化卡片。

岗位关联

对 AI 从业者的价值：图优化是 AI 编译器里性价比最高的优化环节。掌握它，你就真正理解了“模型为什么跑得快”，并具备对推理引擎做性能调优、为新一代硬件定制优化流程的工程能力。

目录
  1. 可视化演示
  2. 图优化概览：先把整条流水线看明白
  3. 常量折叠：能提前备的菜，绝不现场做
  4. 算子融合：能一锅出的菜，绝不分开炒
  5. 布局变换：换一种更顺手的切配方式
  6. Pass基础设施：厨房的标准化作业流程
  7. 自定义Pass开发：写一张你自己的 SOP 卡片
  8. 优化实践与调试：不测不知道，一测吓一跳
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示TVM RELAY IR图优的核心机制，通过源头/管道/节点/终端四种模式展示关键概念与交互流程。

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

TVM RELAY IR图优：核心Pa 核心Pass实现原理剖析 FoldConstant折叠实 核心机制可视化 TVM RELAY IR图优整体架构与关键组件

图优化概览：先把整条流水线看明白

假设你是“满汉全席”厨房的总厨师长。宴会开始前，你手里有一张画好的做菜流程图：洗菜、切菜、焯水、爆炒、装盘，每一步之间都有食材在传递。仔细一算，有些配菜今天根本用不到却提前备了，有些食材在两个灶台之间来回搬，甚至反复进出冰柜，白白浪费力气。图优化要做的事，就是在正式开火之前，把这些流程上的浪费找出来并改掉。

在 TVM 的 RELAY IR 层，这张“做菜流程图”就是计算图（Computation Graph）。节点（Node）是算子，如卷积、加法、ReLU，相当于一个做菜步骤；边（Edge）表示张量的流向，相当于食材在灶台间的传递。RELAY IR 是 TVM 的中间表示层，专门承载这种图结构，供编译器的各个优化阶段反复改写。

图优化发生的时机很特殊：模型已被翻译成 RELAY IR、但还没生成底层机器码之前。这个阶段看不到寄存器和线程块，只看得到图层面的结构。优化目标有两个：一是减少计算量（少做几道菜），二是减少内存访问（少搬几次食材）。内存访问往往比计算更贵——一次显存读写可能比一次浮点运算慢一个数量级，所以减少中间张量搬运的收益常常更大。

有了这本“总开销”账，我们就知道该从哪里下手：能提前备的提前备（常量折叠），能一锅炖的合灶（算子融合），能让下一站更顺手的换切法（布局变换）。接下来，我们逐一拜访这三位“流程优化大师”。

总开销=∑i=1n计算(Opi)+∑e∈E搬运(e)\displaystyle \text{总开销} = \sum_{i=1}^{n} \text{计算}(Op_i) + \sum_{e \in E} \text{搬运}(e)
这个公式告诉我们：图优化的全部努力，就是在“算得少”和“搬得少”这两笔账上做文章。
  1. 算子计算求和把图中 n 个算子的计算耗时全部加起来，相当于统计“做每道菜”的时间。
    ∑i=1n计算(Opi)\displaystyle \sum_{i=1}^{n} \text{计算}(Op_i)
  2. 数据搬运求和把每条边上张量读一次、写一次的内存访问时间加起来，相当于统计“食材搬运”的时间。
    ∑e∈E搬运(e)\displaystyle \sum_{e \in E} \text{搬运}(e)
  3. 优化目标让总开销尽可能小，既少做菜，也少搬菜，这是所有图优化 Pass 的共同方向。
    min⁡(∑i=1n计算(Opi)+∑e∈E搬运(e))\displaystyle \min \left( \sum_{i=1}^{n} \text{计算}(Op_i) + \sum_{e \in E} \text{搬运}(e) \right)

常量折叠：能提前备的菜，绝不现场做

开席后，客人点了“宫保鸡丁”。如果这时候才开始给花生米剥皮、调酱汁，上菜就太慢了。聪明的厨师会在备菜阶段就把这些固定配料准备好——因为无论客人点什么，这些配料都是一样的。数学上，如果某个算子的所有输入都是“固定值”（常量），那它的输出也必然是固定值，完全可以提前算好。

在 RELAY IR 里，这些“固定配料”就是常量节点（Constant）。一个算子如果所有输入都来自常量节点（或已经折叠出来的常量），它的结果在编译期就确定了。FoldConstant Pass 专门找出这样的子图，在编译期执行一次计算，把结果替换成新的常量节点。运行时根本不需要再执行这个算子，就像宴会当天直接从冰箱拿出酱汁，不用现场调。

实现上，FoldConstant 会对 RELAY 表达式做一次遍历。遇到 Call 节点（代表一次算子调用）时，检查所有参数是否都是 Constant；如果是，就调用求值器（ConstantEvaluator）在编译期算出结果，再用新的 Constant 替换整个 Call。新替换出的常量还可能继续参与下一轮折叠，所以这个 Pass 常需迭代执行，直到图不再变化。

这里的收益就像“提前备菜”：运行时少了一次算子启动和计算。但要注意，如果折叠出的常量特别大——比如一张 100MB 的权重表——把它固化进模型反而会让模型文件膨胀，就像为了图方便把整个菜市场搬进冰箱，结果冰箱都装不下了。这就是常量折叠的边界。

y=f(c1,c2,…,cn)  ⟹  y=c^\displaystyle y = f(c_1, c_2, \ldots, c_n) \;\Longrightarrow\; y = \hat{c}
右边的新常量 $\hat{c}$ 在编译期就已算好，运行时只需读取，计算开销归零。
  1. 算子调用算子 f 的 n 个输入全部是常量，结果 y 原本要在运行时才算。
    y=f(c1,c2,…,cn)\displaystyle y = f(c_1, c_2, \ldots, c_n)
  2. 编译期求值在编译阶段把 f 算出来，得到一个新的常量。
    c^=f(c1,c2,…,cn)\displaystyle \hat{c} = f(c_1, c_2, \ldots, c_n)
  3. 替换规则整个算子调用被一个常量节点取代，运行时零计算。
    y=f(c1,c2,…,cn)  ⟹  y=c^\displaystyle y = f(c_1, c_2, \ldots, c_n) \;\Longrightarrow\; y = \hat{c}

算子融合：能一锅出的菜，绝不分开炒

做“地三鲜”时，土豆、茄子、青椒要分别过油再汇合。聪明的做法是放进同一口锅按顺序下料，一锅出——中间不必把每样半成品端回冰柜再拿出来。算子融合的思路一模一样：把计算图上首尾相接的几个算子合并成一个“融合算子”，它们之间的中间结果不写回显存，直接留在寄存器或片上缓存里递给下一个算子。

为什么要融合？因为一次算子执行不只是做运算：它要从显存读输入，算完写回中间结果，接着下一个算子再把它读出来。每一次读写都是真金白银的带宽开销。融合后，中间张量在“锅”里就完成了接力，省掉了多次全局内存的写和读，还顺带减少了 Kernel 的启动次数——每次启动都像刷一次锅。

在 RELAY 中，FuseOps Pass 从输出节点开始，沿数据依赖反向遍历。它根据算子的融合模式（OpPatternKind）判断哪些算子能归为一组：逐元素类（kElementWise）、广播类（kBroadcast）、注入类（kInjective）通常可以融合，而缩减类（kCommReduce）和复杂算子往往不行。判定合法后，多个算子被包进一个“融合组”，最终由后端代码生成编译成单个 Kernel。

合灶不仅省了“端回冰柜再拿出来”的功夫，还省了洗多个锅的时间——每次 Kernel 启动都像刷一次锅。当然，不能什么菜都往一锅扔，火候不兼容的算子（模式不匹配）强行融合反而会糊锅。

Tseparate=∑i=1mTcompute(i)+∑j=1m−1(Twrite(j)+Tread(j))\displaystyle T_{separate} = \sum_{i=1}^{m} T_{compute}^{(i)} + \sum_{j=1}^{m-1} \left( T_{write}^{(j)} + T_{read}^{(j)} \right)
融合后，公式里那一大串中间读写项被整体消灭，这正是 FuseOps 的甜头所在。
  1. 独立执行时间每个算子各自执行的时间总和，包括计算与中间搬运。
    Tseparate=∑i=1mTcompute(i)+∑j=1m−1(Twrite(j)+Tread(j))\displaystyle T_{separate} = \sum_{i=1}^{m} T_{compute}^{(i)} + \sum_{j=1}^{m-1} \left( T_{write}^{(j)} + T_{read}^{(j)} \right)
  2. 算子计算项m 个算子的纯计算时间，这部分融合前后基本不变。
    ∑i=1mTcompute(i)\displaystyle \sum_{i=1}^{m} T_{compute}^{(i)}
  3. 中间搬运项每两个相邻算子之间，中间结果写一次、读一次的开销，共 m-1 次。
    ∑j=1m−1(Twrite(j)+Tread(j))\displaystyle \sum_{j=1}^{m-1} \left( T_{write}^{(j)} + T_{read}^{(j)} \right)
  4. 融合收益中间变量留在片上高速存储，m-1 次写读被省掉。
    Tfused=∑i=1mTcompute(i)+Twrite(first)+Tread(last)\displaystyle T_{fused} = \sum_{i=1}^{m} T_{compute}^{(i)} + T_{write}^{(first)} + T_{read}^{(last)}

布局变换：换一种更顺手的切配方式

切土豆丝有两种流派：先切片再切丝（按“片→丝”的层次切），或者直接用擦丝器（按“丝”直接擦）。两种做法最后的土豆丝一样，但下一道工序“爆炒”用起来顺手程度不同——擦出来的丝更整齐，下锅时受热更均匀。数据在内存里的排列方式，也有类似的“切法”之分，这就是数据布局（Data Layout）。

深度学习里最常见的两种布局是 NCHW（通道在前）和 NHWC（通道在后）。同样一份张量，横着摆还是竖着摆，会显著影响算子访问内存的局部性。比如某些硬件上，卷积用 NHWC 能连续访问通道数据，速度更快。AlterOpLayout Pass 干的事，就是在不改变张量数值的前提下，把算子数据布局换成对目标硬件更友好的形式。

在 TVM 中，每个算子可以通过注册 FAlterOpLayout 属性来提供布局变换规则。Pass 调用这些规则，把算子替换成使用新布局的版本，必要时插入一个 layout_transform 节点负责数据重排。注意，重排本身有开销——数据要一块块搬到新位置，所以只有当“换布局省下的钱”大于“重排花的钱”时才值得做。这也是 AlterOpLayout 要和 FuseOps 等 Pass 配合的原因：有时重排可以被融合顺手消化掉。

用厨房的话说，这是“换一种切配方式”：食材本身没变，但让下一道工序“抄起来就顺手”。优秀厨师会盯着整条流水线权衡——这一刀切下去，到底是为后面省了更多时间，还是仅仅自己过瘾？布局变换的成功关键在于全局算账。

Cconvert=N×C×H×W,NHWC[n,h,w,c]=NCHW[n,c,h,w]\displaystyle C_{convert} = N \times C \times H \times W, \qquad \text{NHWC}[n,h,w,c] = \text{NCHW}[n,c,h,w]
重排成本等于元素总数乘以单元素搬移代价；布局映射只换位置、不改数值。
  1. 元素总数四维张量的元素个数，就是重排需要搬动的数据总量。
    N×C×H×W\displaystyle N \times C \times H \times W
  2. 索引映射NHWC 与 NCHW 之间的对应关系，说明两种布局存的数值完全相同。
    NHWC[n,h,w,c]=NCHW[n,c,h,w]\displaystyle \text{NHWC}[n,h,w,c] = \text{NCHW}[n,c,h,w]
  3. 收益比较只有重排开销明显小于后续内存访问的节省时，变换才划算。
    Cconvert<Csaved  ⟹  执行 AlterOpLayout\displaystyle C_{convert} < C_{saved} \;\Longrightarrow\; \text{执行 AlterOpLayout}

Pass基础设施：厨房的标准化作业流程

一家厨房如果只有“临时起意”的改良，没法保证每场宴会都稳定发挥。专业的厨房会把每项改进写成标准作业流程（SOP）：叫什么名字、在哪个环节执行、有什么前提条件。TVM 的 Pass 就是一张张“SOP 卡片”，Pass Manager 则是按顺序分发卡片的总调度。

一个 Pass 本质上是“作用在 RELAY IR 上的一次变换”。它有名字（比如 FoldConstant）、优化等级（opt_level）和一个具体的变换函数。Pass 又分函数级（Function Pass）和模块级（Module Pass）：函数级只改写某个 Relay Function，模块级面对整个 IRModule，可以做跨函数的改动。

Pass 的执行顺序非常有讲究：先 FoldConstant 再 FuseOps，能让融合器看到更干净的图；先布局变换再做融合，能让重排节点有机会被融合消化。TVM 用 Sequential 机制把多个 Pass 串成流水线，并通过 PassContext 管理选项、记录日志。改写表达式时，编译器靠两种“访问者”：ExprVisitor 只读不改，ExprMutator 生成新表达式——这是所有改写型 Pass 的地基。

有了这套 SOP 体系，编译器工程师就能像搭积木一样组合改进方案，随时查日志看每一步改了什么。这也是我们能安全加入“自定义 Pass”的原因——它不过是在这套流程里再插入一张新卡片。

G′=Pk∘Pk−1∘⋯∘P1(G)\displaystyle G' = P_k \circ P_{k-1} \circ \cdots \circ P_1 (G)
一张图按顺序经过 k 张 SOP 卡片，前一个的输出正是后一个的输入。
  1. 单个变换第 i 个 Pass 作用在计算图 G 上，产出新图。
    Pi(G)\displaystyle P_i (G)
  2. 顺序复合按 1 到 k 的顺序依次执行，前一步的输出作为后一步的输入。
    Pk∘Pk−1∘⋯∘P1\displaystyle P_k \circ P_{k-1} \circ \cdots \circ P_1
  3. 最终结果经过整条流水线打磨后的优化图。
    G′=Pk∘Pk−1∘⋯∘P1(G)\displaystyle G' = P_k \circ P_{k-1} \circ \cdots \circ P_1 (G)

自定义Pass开发：写一张你自己的 SOP 卡片

你是这家厨房的研发主厨，发现一道菜的流程有优化空间：切好的土豆丝在传到下一站之前，被“加一个零”地多颠了一下勺——完全多余。你想写一条新规：见到“乘 1”或“加 0”就直接跳过，别白费力气。在 RELAY 里，这就是开发一个自定义 Pass。

开发自定义图优化 Pass 通常分四步：第一，决定 Pass 类型，函数级用 function_pass，模块级用 module_pass；第二，继承 ExprMutator 编写改写规则，用模式匹配找到目标子图（比如 relay.multiply 且一个参数是常量 1）；第三，把改写逻辑包在一个带名字的类里；第四，用装饰器注册，然后丢进 Sequential 和官方 Pass 一起跑。

工程上有几个关键点：一是匹配条件要严谨，改写的表达式必须数学上等价（乘 1、加 0 才成立）；二是注意处理嵌套表达式，子表达式改写后还要递归检查；三是用打印图或 PassContext 验证改写确实发生了。注册好的 Pass 用法与官方 Pass 完全一致，这正是 RELAY Pass 框架开放性的体现。

写一张自定义 SOP 卡片并不神秘：你只是告诉编译器“遇到这种情况，就这么省着做”。这正是开源编译器的魅力——每个团队都能把自己的硬件特性和算子习惯沉淀成一张张 Pass 卡片，组合出最适合自己的优化流水线。

MatchPattern(e)=true  ⟹  e↦enew\displaystyle \text{MatchPattern}(e) = \text{true} \;\Longrightarrow\; e \mapsto e_{new}
命中模式就替换，但必须保证 $e_{new}$ 与 $e$ 在数学上等价，优化不能改变模型语义。
  1. 模式匹配判断当前表达式 e 是否命中目标模式，比如“乘以常量 1”。
    MatchPattern(e)=true\displaystyle \text{MatchPattern}(e) = \text{true}
  2. 改写行动命中后把 e 替换为等价但更省的表达式。
    e↦enew\displaystyle e \mapsto e_{new}
  3. 不变量保证e 与 e_new 数学等价，优化前后模型输出一致。
    value(e)=value(enew)\displaystyle \text{value}(e) = \text{value}(e_{new})

优化实践与调试：不测不知道，一测吓一跳

流程改进之后，厨师长当然要先尝菜、掐表：这道菜是不是真的更快了？味道有没有变？图优化也一样：改完图之后，必须做两件事——验证正确性和测量性能。否则就可能出现“优化了个寂寞”甚至“算错结果”的翻车现场。

调试方面，TVM 有几个趁手工具：用 mod["main"] 直接打印优化前后的 IR 文本，肉眼对比图结构；用 PassContext 开启 -dump_pass，把每个 Pass 之后的那一版图都输出到文件；还可以逐 Pass 单步执行，定位是哪一步把图改坏了。验证正确性最朴素的办法，是给优化前后的模型喂同样的输入，对比输出是否一致。

性能评估一定要“在目标硬件上测”。图优化是启发式的——A 硬件上变快的变换，在 B 硬件上可能反而变慢。正确姿势是用 TVM 的 time_evaluator 在真实设备上跑端到端、多次取平均，再与优化前基线对比。常用的指标就是加速比：优化后耗时是之前的几分之一。

就像主厨用秒表记录上菜时间，编译器工程师要用数据说话。优化是优化者的一厢情愿，加速比才是客人的真实反馈。把“改图—验证—测速”的循环跑顺，你才算真正掌握了图优化的手艺。

Speedup=TbaseTopt\displaystyle \text{Speedup} = \frac{T_{base}}{T_{opt}}
加速比大于 1 说明优化有效，小于 1 说明帮了倒忙，需要回退该 Pass。
  1. 基线耗时优化前模型在目标硬件上的端到端运行时间。
    Tbase\displaystyle T_{base}
  2. 优化后耗时同一模型、同一输入、同一硬件上优化后的运行时间。
    Topt\displaystyle T_{opt}
  3. 加速比两者之比，是判断优化是否有效的硬指标。
    Speedup=TbaseTopt\displaystyle \text{Speedup} = \frac{T_{base}}{T_{opt}}

AI 应用场景

云端推理服务：BERT 延迟直降三成

阶段：推理部署优化

解决的问题：预训练模型部署到 GPU 推理服务后，每次请求都要重复计算与权重相关的常量变换（如 LayerNorm 的权重归一化、注意力 mask 的常量准备），延迟虚高，QPS 上不去。传统做法是手工改写模型代码，费时且易错。

具体案例：某团队用 FoldConstant 把 attention 中固定的 mask 计算搬到编译期，再用 FuseOps 把 LayerNorm 里的多个小算子融合成一个 Kernel。优化后单次推理延迟下降约 30%，QPS 明显提升，且整个过程无需改动模型结构。

端侧 NPU 适配：自动换成芯片顺手的布局

阶段：异构硬件适配

解决的问题：同一份模型在不同芯片上最优数据布局不同，端侧 NPU 对 NHWC 布局的卷积更友好，而训练导出的模型通常是 NCHW。手工改布局等价于重写一遍模型，不可维护。

具体案例：在端侧 NPU 上部署人脸检测模型时，用 AlterOpLayout 自动把模型布局切到 NHWC，再注册一个自定义 Pass 消掉多余的 layout_transform 节点，最终内存访问命中率提升，端到端延迟下降约 20%。

自研 NPU 算子适配：为硬件定制融合

阶段：算子适配与图定制

解决的问题：新硬件往往不支持某些通用算子组合，官方 Pass 也不了解自家硬件的“脾气”，直接用通用优化效果不佳。

具体案例：某团队为自研 NPU 编写了自定义融合 Pass，把"Conv+BN+ReLU"融合成硬件原生支持的单算子，并用模块级 Pass 批量改写整个模型图，配合官方 FuseOps 一起执行，kernel 数量减少一半以上。

Python 演示

python51 行
"""演示: 编写一个自定义 RELAY 图优化 Pass(化简 乘1/加0)."""import numpy as npimport tvmfrom tvm import relayfrom tvm.relay import ExprMutator, transform  class _SimplifyMulOne(ExprMutator):    """把 x * 1.0 直接改写成 x 的表达式访问者."""     def visit_call(self, call):        new_call = super().visit_call(call)        # 只处理乘法, 且右操作数是常量 1.0        if getattr(new_call.op, "name", "") == "multiply":            lhs, rhs = new_call.args            if isinstance(rhs, relay.Constant) and float(rhs.data.numpy()) == 1.0:                return lhs        return new_call  @transform.function_pass(opt_level=1)class SimplifyIdentities:    """函数级 Pass: 对每个函数体应用上面的改写器."""     def __init__(self):        self.name = "SimplifyIdentities"     def transform_function(self, func, mod, ctx):        return relay.Function(func.params, _SimplifyMulOne().visit(func.body), func.type_params, func.attrs)  def main():    # 构造一个简单计算图: y = x * 1.0 + 0.0    x = relay.var("x", shape=(4, 4), dtype="float32")    y = relay.add(relay.multiply(x, relay.const(1.0)), relay.const(0.0))    mod = tvm.IRModule.from_expr(relay.Function([x], y))    print("原始 main 函数:\n", mod["main"])    mod2 = SimplifyIdentities()(mod)    print("优化后 main 函数:\n", mod2["main"])    # 验证数值等价: 用同一个输入跑优化前后的图    x_data = np.random.rand(4, 4).astype("float32")    exe = relay.create_executor("graph", mod=mod, ctx=tvm.cpu())    exe2 = relay.create_executor("graph", mod=mod2, ctx=tvm.cpu())    out1 = exe.evaluate(mod["main"])(x_data)    out2 = exe2.evaluate(mod2["main"])(x_data)    assert np.allclose(out1.numpy(), out2.numpy()), "结果不一致!"    print("数值等价验证通过, 乘1/加0 已化简")  if __name__ == "__main__":    main()
目的：演示如何用 ExprMutator 编写一个自定义的 RELAY 函数级 Pass，把“乘以常量 1”的冗余算子化简掉，并验证优化前后数值等价。
  1. @transform.function_pass(opt_level=1)把下面的类注册为函数级 Pass，opt_level=1 表示基础优化。
  2. class _SimplifyMulOne(ExprMutator):继承 ExprMutator 才能遍历并改写表达式树。
  3. if getattr(new_call.op, "name", "") == "multiply":只匹配乘法算子，避免误改其他调用。
  4. return relay.Function(func.params, _SimplifyMulOne().visit(func.body), func.type_params, func.attrs)用改写后的函数体重建 Relay Function。
  5. mod2 = SimplifyIdentities()(mod)自定义 Pass 的直接调用方式，和官方 Pass 用法完全一致。
  6. assert np.allclose(out1.numpy(), out2.numpy()), "结果不一致!"数值等价验证，确保优化不改变模型语义。

常见误区

误区我运行 FoldConstant 之后，图里还有很多算子没被折叠，是不是我的图有问题？它难道不应该把所有能提前算的都提前算好吗？

正解FoldConstant 只折叠“所有输入都是常量节点”的子图。只要有一个输入来自网络的数据流（比如上一层激活输出），这个算子的结果就依赖运行时输入，无法在编译期确定。另外，超大常量也要谨慎——折叠会把计算结果固化进模型文件，如果结果是一份 100MB 的表，模型体积反而可能膨胀。

为何常见：初学者容易把“常量”等同于“不变的权重”，但图优化语境里的常量特指编译期就能确定值的字面量节点，两者不是一回事。

误区融合能省内存访问，那把能合的算子全合在一起，性能一定最好吧？反正中间结果都不出内存了。

正解并非如此。融合会改变算子的调度方式，融合组过大会导致寄存器压力爆表、片上存储被占满，反而降低并行度；某些模式不兼容的算子强行融合还可能生成更差的代码。真正靠谱的做法是在目标硬件上实测对比，让数据说话。

为何常见：“减少中间搬运”的直觉容易被推广成“减得越多越好”，却忽略了硬件资源是有限的，融合组过大照样会“锅满为患”。

误区布局只是内存里改了个排法，数值完全不变，那怎么换都对，性能肯定只升不降吧？

正解布局变换本身会引入数据重排（layout_transform），重排需要搬动整份数据，开销不小；而且新布局在某些硬件上未必更快。必须验证数值等价，并在目标设备上实测，才能确定这笔“换切法”的买卖是否划算。

为何常见：“数值不变”让初学者误以为变换是免费的，忽略了搬数据的时间和访存模式变化带来的代价。

误区反正都是把图优化一遍，先跑哪个 Pass 不都一样吗？最后结果应该差不多吧。

正解Pass 之间是流水线关系——前一个 Pass 的输出是后一个的输入。图结构被改写后，后一个 Pass 看到的匹配机会完全不同。比如先 FoldConstant 再 FuseOps，融合器能看到更干净的图；先 AlterOpLayout 再 FuseOps，重排节点有机会被融合消化。顺序反了，优化机会就白白丢了。

为何常见：每个 Pass 单独看都是局部变换，初学者很难意识到局部变换串起来后会产生全局的先后依赖，就像先切菜还是先热锅，顺序错了整道菜都会受影响。

面试题

Q1. RELAY IR 图优化的核心目标是？

单选题 · easy

  • A.减少计算量与内存开销← 正确答案
  • B.增大模型参数数量
  • C.替换训练数据集
  • D.改变模型输出类别

答案：A。图优化在不改模型语义的前提下，让计算图少算、少搬。核心目标正是降低计算量与内存访问开销。增大参数、替换数据集、改变输出类别都不属于图优化范畴，甚至违背“保持语义不变”的根本原则。

Q2. FoldConstant 适合折叠哪种子图？

单选题 · easy

  • A.输入包含网络激活值
  • B.输入包含用户占位符
  • C.输入全部是编译期常量← 正确答案
  • D.输入包含动态形状

答案：C。折叠的充要条件是“所有输入均为编译期常量节点”。包含激活值、占位符、动态形状时，算子结果依赖运行时输入，无法提前求值，就像客人没点菜，你没法提前炒他的那份。

Q3. FuseOps 主要节省哪一类开销？

单选题 · mid

  • A.模型权重参数初始化耗时
  • B.中间张量写读内存的流量← 正确答案
  • C.训练样本的数据增强耗时
  • D.梯度计算的反向传播耗时

答案：B。FuseOps 把相邻算子合成一个 Kernel，最直接的好处是中间张量不用写回显存再读回，同时减少 Kernel 启动次数。权重初始化、数据增强、反向传播都不是推理阶段图优化关心的对象。

Q4. AlterOpLayout 变换布局后可能插入？

单选题 · mid

  • A.额外增加的权重约束项
  • B.定制开发的损失函数
  • C.自动划分的训练批次
  • D.数据重排的layout变换节点← 正确答案

答案：D。布局变换改变张量在内存中的排列，当后续算子不认新布局时，就需要插入 layout_transform 节点把数据重排回来。权重约束、损失函数、训练批次都与数据布局无关。

Q5. 注册自定义 Relay Pass 常用装饰器是？

单选题 · mid

  • A.tvm.relay.transform.function_pass← 正确答案
  • B.tvm.relay.backend.lower_schedule
  • C.tvm.contrib.download.download_test
  • D.tvm.runtime.ndarray.array

答案：A。TVM Python 前端通过 @relay.transform.function_pass 装饰器，把实现了 transform_function 方法的类注册为函数级 Pass。其余选项分别属于调度、下载、张量创建，与 Pass 注册无关。

Q6. 改写 Relay 表达式最常用的基类是？

单选题 · hard

  • A.NDArray 张量运行时
  • B.IRModule 模块容器
  • C.ExprMutator 表达式改写器← 正确答案
  • D.PassContext 上下文

答案：C。ExprMutator 是改写型 Pass 的地基，提供 visit_call 等方法返回新表达式。NDArray 是运行时张量，IRModule 是被优化对象的容器，PassContext 管理上下文，它们都不能遍历并改写表达式树。

Q7. 关于算子融合，下列说法正确的有？

多选题 · mid

  • A.可以减少内核启动次数← 正确答案
  • B.任何算子都无条件可融
  • C.中间结果可留片上存储← 正确答案
  • D.融合与算子模式无关

答案：AC。融合后多个算子共用一个 Kernel，启动次数减少（A 对）；中间结果留在寄存器或片上缓存，省掉显存读写（C 对）。融合要求算子满足特定模式（如逐元素、注入类），并非无条件，也与算子模式密切相关（B、D 错）。

Q8. 评估图优化收益的可靠方法是？

单选题 · hard

  • A.比较优化前后节点数
  • B.目标硬件实测端到端耗时← 正确答案
  • C.查看代码的注释数量
  • D.统计日志的打印长度

答案：B。图优化是启发式的，同一变换在不同硬件上效果可能相反，只有目标硬件上的端到端实测最可靠。节点数、注释量、日志长度都不能反映真实性能，就像数菜谱页数无法知道菜好不好吃。

Q9. FoldConstant 可能的局限性有？

多选题 · hard

  • A.含输入变量时无法折叠← 正确答案
  • B.大常量会膨胀模型体积← 正确答案
  • C.一定拖慢编译的速度
  • D.一定减少全部显存

答案：AB。折叠要求输入全部是常量，遇到变量输入只能放弃（A 对）；超大常量被固化进模型后会让模型文件膨胀（B 对）。折叠不一定拖慢编译，也不保证减少所有显存占用（C、D 错）。

Q10. 为什么 Pass 执行顺序很重要？

多选题 · mid

  • A.前序 Pass 会改写图的结构← 正确答案
  • B.各 Pass 之间完全互不影响
  • C.顺序决定后续优化机会← 正确答案
  • D.顺序只影响代码的注释

答案：AC。Pass 按顺序串成流水线，前一个改写图结构，后一个在改写后的图上匹配，所以顺序决定了优化机会是否暴露（A、C 对）。Pass 之间存在依赖，既非完全独立，影响也远不止注释（B、D 错）。