融合规则定义了编译器自动识别和执行算子合并的策略集合，是融合优化Pass的核心配置。文章讨论融合规则的DSL设计、规则优先级与冲突处理机制以及基于机器学习的自动规则生成方法，帮助理解如何构建可扩展的算子融合系统，为编译器融合策略的工程实现提供方法论。

学习提示

需要学习融合规则定义，端侧推理依赖编译器优化（TFLite/NCNN/Triton）。本篇涵盖TVM/XLA/Triton、算子融合、图优化，帮助你掌握编译器优化技术。

目录
  1. 可视化演示
  2. AI 应用场景
  3. Python 演示
  4. 常见误区
  5. 面试题

可视化演示

状态—

融合规则定义了编译器自动识别和执行算子合并的策略集合，是融合优化Pass的核心配置。文章讨论融合规则的DSL设计、规则优先级与冲突处理机制以及基于机器学习的自动规则生成方法，帮助理解如何构建可扩展的算子融合系统，为编译器...

融合规则概述

中央厨房的第一页工作手册，写的不是具体菜谱，而是一张"合并建议分类表"：哪些工序适合合并、合并后省了什么、什么情况下不能合。主厨老周拿到手册，心里先有了全局。他清楚，手册的架构决定了后厨能优化到什么程度——如果分类混乱，后面的每一餐都会手忙脚乱。

在 AI 编译器中，这张"分类表"就是融合规则的总体框架。融合规则定义了编译器自动识别和执行算子合并的策略集合，它是融合优化 Pass 的"核心配置"。计算图中的算子可以类比为流程表上的工序：加法算子 Add 是"称重配比"，乘法算子 Mul 是"搅拌调味"，卷积算子 Conv 是"改刀切配"，激活函数 ReLU 是"过油定型"。规则要回答的问题只有一个：哪些工序能安全地并为一道，让中间步骤不再产生额外的"碟子"（中间张量）。

一条融合规则可以用形式化的方式描述为：模式（Pattern）声明可融合的算子子图结构；条件（Condition）是匹配后仍需满足的约束；动作（Action）把命中的子图重写成新算子。融合策略大体分两类：垂直融合把流水线上下游算子合并，减少中间结果写回内存的开销；水平融合把并列的同形态算子合并，共享调度与内核启动。规则引擎是编译器优化管线中的一个 Pass，它读入计算图、对照规则库执行匹配与重写，产出融合后的新图。

这条式子是说：当计算图中出现符合 Pattern 的子图，并且 Condition 约束全部满足时，编译器就执行 Action 把它们融合成一个算子。

R:Pattern→Condition  Action\displaystyle R: Pattern \xrightarrow[Condition]{\;} Action
  1. Pattern（匹配模式）描述可融合算子子图的结构模板，是规则识别融合机会的"眼睛"。
    Pattern:=op1∘op2∘⋯∘opn\displaystyle Pattern := op_1 \circ op_2 \circ \cdots \circ op_n
  2. Condition（守卫条件）结构匹配通过后仍需满足的语义与形状约束，防止错合并。
    Condition:=shape_compatible∧no_side_effect\displaystyle Condition := shape\_compatible \land no\_side\_effect
  3. Action（重写动作）将命中的子图替换为融合算子，完成计算图的重写。 就像手册第一页先分类再定细则，编译器也需要先建立规则的总体框架，后续的 DSL、优先级、冲突处理才有立足之地。分类表定得好，后厨动线才能顺。
    Action:=Replace(Pattern,fused_op)\displaystyle Action := Replace(Pattern, fused\_op)

规则DSL设计

手册条目用什么语言写？老周的要求很明确：一眼看懂、不会误读、任何新来的帮厨都能安全修改。用大白话写太长，用自由代码写太容易出歧义，于是后厨约定了一套"厨师速记符号"——比如"切配→腌制"一条短箭头，代表把这两道工序合起来。

这套"速记符号"在编译器里就叫 DSL（Domain-Specific Language，领域专属语言）。融合规则 DSL 被刻意设计成声明式的：你只需要写清楚"想匹配什么结构、满足什么条件、怎么改"，而不需要写"一步步怎么遍历图、怎么重写"的命令式逻辑。声明式的最大好处是规则库像一张表一样直观，编译器还能在解析阶段做静态检查，把字段拼写错误、类型不匹配这类低级 bug 提前暴露。

规则 DSL 通常围绕四个字段展开：pattern 用节点模式和边模式描述目标子图；guard 表达附加约束，比如数据类型一致、张量形状可广播；rewrite 描述融合后新算子的构造方式；priority 给出规则在库中的排序权重。这种四字段结构几乎覆盖了主流编译器框架（如 MLIR、XLA）中融合规则的实际写法，它把"规则是什么"与"规则怎么执行"彻底解耦。

这条式子把一条规则拆成四个字段：模式告诉编译器"看哪里"，守卫告诉它"确认什么"，重写告诉它"怎么变"，优先级告诉它"排第几"。

Rule:=⟨pattern,  guard,  rewrite,  priority⟩\displaystyle Rule := \langle pattern,\; guard,\; rewrite,\; priority \rangle
  1. pattern（模式字段）声明规则匹配的算子子图结构，是 DSL 的骨架。
    pattern:=⟨node_pattern,edge_pattern⟩\displaystyle pattern := \langle node\_pattern, edge\_pattern \rangle
  2. guard（守卫字段）声明应用融合的附加约束，如形状可广播、无副作用。
    guard:=dtype_ok∧shape_broadcastable\displaystyle guard := dtype\_ok \land shape\_broadcastable
  3. rewrite（重写字段）声明融合后新算子的构造方式与参数传递规则。
    rewrite:=mk_fused_op(children,attrs)\displaystyle rewrite := mk\_fused\_op(children, attrs)
  4. priority（优先级字段）声明规则在规则库中的排序权重，决定执行先后。 好的速记语言，让新帮厨在十分钟内读懂整本手册。DSL 的设计哲学正是如此：通过主动限制表达能力，换取规则库的可读性、可验证性和可维护性——这是一笔聪明的"约束换秩序"的买卖。
    priority∈{0,1,2,…,100}\displaystyle priority \in \{0, 1, 2, \ldots, 100\}

规则匹配机制

手册写好了，老周开始在实际流程表上找"哪里能合并"。他扫视工序链：切配后面紧跟腌制，中间没有隔其他工序——好，这一处匹配上了。但老周不会马上动手，他还得看分量是否合适、时间节点是否允许，也就是说，"看起来像"不等于"真的能合"。

编译器里的对应动作叫图模式匹配：拿着规则中的 Pattern，在计算图上寻找同构的子图。但真实计算图远比菜谱复杂：算子属性各异、张量形状不同、数据布局不一，不能只看算子类型相同就下结论。因此匹配机制分为两步：先做结构匹配（子图同构搜索），再做属性校验（用代价模型评估匹配质量）。

代价模型的思路是给每个候选匹配打一个"匹配代价分"：属性的差异越小、数据布局越契合，代价越低。只有通过代价评估的候选才会进入候选集，交给后续的优先级与冲突仲裁模块。候选集的生成质量直接决定了融合优化的上限——如果结构匹配漏掉了好组合，后面再好的规则也没机会执行；如果代价模型放过了坏组合，融合后反而更慢。

这条式子用于计算一个候选匹配的整体代价：逐项比较模式声明的属性与实际节点的属性，用距离函数衡量差异，再按重要性加权求和。

Cost(m)=∑i=1nwi⋅d(aip,aig)\displaystyle Cost(m) = \sum_{i=1}^{n} w_i \cdot d(a_i^{p}, a_i^{g})
  1. 模式属性 aᵢᵖ规则声明中第 i 个属性的期望值，如算子类型、张量形状。
    aip:=type_pattern∣shape_pattern\displaystyle a_i^p := type\_pattern \mid shape\_pattern
  2. 图上属性 aᵢᵍ计算图实际节点的第 i 个属性值，是匹配时的真实对象。
    aig:=actual_type∣actual_shape\displaystyle a_i^g := actual\_type \mid actual\_shape
  3. 距离函数 d度量属性差异的函数，差异越小表示匹配度越高。
    d(a,b):=(a≠b) for boolean attrs\displaystyle d(a,b) := (a \neq b) \text{ for boolean attrs}
  4. 权重 wᵢ不同属性在匹配判定中的重要性系数，归一化后总和为 1。 老周不是见到"切配+腌制"就盲目合并，他还要看分量、时间、冷藏条件。匹配机制也一样：结构搜索负责"能不能匹配"，代价模型负责"匹配了值不值"，两者合起来才是完整的匹配决策。
    wi:=normalized_importance,∑iwi=1\displaystyle w_i := normalized\_importance, \quad \sum_i w_i = 1

规则优先级

手册几十条建议，不可能同时执行。老周的习惯是先做收益最大、副作用最小的合并。比如午市高峰，把"慢炖+收汁"并成一个灶头能省出宝贵的位置，那这条建议就优先执行；晚上客流低，再按原工序慢慢来也不迟。

规则库中的规则同样有执行先后问题。规则优先级定义了当多条规则都匹配同一张图时，谁先被尝试执行。优先级设计不当会导致两种典型故障：低收益规则先匹配并占用了子图，使高收益规则失去匹配机会；或者规则反复重写同一个子图，形成死循环。因此优先级不是简单的"排序编号"，而是一套需要精心设计的策略。

优先级计算在实践中往往综合三方面：特异性（Specificity）即模式越具体、约束越多，越应优先执行，因为精确的规则通常来自明确的优化意图；命中频率（Frequency）即历史上越常被成功使用的规则越值得优先；预估收益（Benefit）即融合后节省的访存与内核启动开销越大越优先。三者加权得到最终优先级 P(R)，规则引擎按 P(R) 降序应用规则。

这条式子表示规则的最终优先级是三个指标的加权和。α、β、γ 是权重系数，控制"精确""常用""有收益"三者谁说了算。

P(R)=α⋅Sp(R)+β⋅Fr(R)+γ⋅Bn(R)\displaystyle P(R) = \alpha \cdot Sp(R) + \beta \cdot Fr(R) + \gamma \cdot Bn(R)
  1. Sp(R) 特异性规则模式的精确程度，约束条件越多、可匹配子图越少则特异性越高。
    Sp(R):=∣约束条件数∣∣可匹配子图数∣\displaystyle Sp(R) := \frac{|\text{约束条件数}|}{|\text{可匹配子图数}|}
  2. Fr(R) 命中频率规则在历史编译任务中被成功使用的次数占比。
    Fr(R):=hits(R)∑R′hits(R′)\displaystyle Fr(R) := \frac{hits(R)}{\sum_{R'} hits(R')}
  3. Bn(R) 预估收益融合后预估节省的访存流量与内核启动开销。
    Bn(R):=saved_memory_traffic+saved_launch_overhead\displaystyle Bn(R) := saved\_memory\_traffic + saved\_launch\_overhead
  4. 权重系数 α/β/γ通过基准测试标定的调参系数，决定三者相对重要性。 先重后轻、先准后宽，老周的排序智慧就是编译器的优先级策略。优先级设计的本质是把"你希望规则库怎么表现"这种模糊愿望，翻译成一组可以计算、可以调优的数值。
    α+β+γ=1\displaystyle \alpha + \beta + \gamma = 1

冲突处理

有时候，两条建议同时适用，合并结果却互相矛盾。比如流程表上"焯水→过凉"这一步，既能按规则 A 合并成"焯冲一体"，又能按规则 B 合并成"焯水入高汤"。二选一，选错了整锅菜都会串味。老周遇到这种情况会先放下手册，想想哪个更省、哪个更安全。

规则冲突指多条规则同时匹配同一子图，但重写结果互斥。在编译器实践中，冲突处理不当会导致融合后的代码比原来更慢，甚至产生错误结果。因此规则引擎必须内置明确的仲裁机制，避免"两个主厨同时下令"的混乱局面。

冲突处理通常有三种方法。收益仲裁：从冲突规则集合中选出 Gain(R) 最大的一条执行，其余被抑制。条件细化：给冲突规则增加 guard 条件，让它们的适用区域互不重叠——比如规则 A 只处理形状相同的情形，规则 B 只处理可广播的情形。保守回退：如果无法判定哪条更优，默认不融合，宁可不优化也不要做错。高级实现还会记录执行轨迹，在线上检测到性能回退时自动撤销规则。

这条式子表示：在冲突规则集合 C 中，选择预估收益 Gain 最大的规则 R* 执行。这是"收益仲裁"策略的形式化。

\displaystyle R^{\*} = \arg\max_{R \in \mathcal{C}} \; Gain(R)
  1. 冲突集 C同时匹配同一子图且重写结果互斥的规则集合。
    C:={R∣R matches g and R≢R′}\displaystyle \mathcal{C} := \{R \mid R \text{ matches } g \text{ and } R \not\equiv R'\}
  2. 收益函数 Gain融合后相对融合前的端到端性能收益，通常用耗时差度量。
    Gain(R):=Tbefore(R)−Tafter(R)\displaystyle Gain(R) := T_{before}(R) - T_{after}(R)
  3. argmax 选择在冲突集中挑出收益最大的规则执行，其余规则被压制。 打架的建议，要么比收益，要么分场景，要么干脆不合并——宁可少赚，不可做砸。冲突处理的核心原则始终是：正确性优先，性能其次。这条铁律让融合优化在复杂模型上依然可靠。
    R∗:={R∈C∣Gain(R)=max⁡R′∈CGain(R′)}\displaystyle R^* := \{R \in \mathcal{C} \mid Gain(R) = \max_{R' \in \mathcal{C}} Gain(R')\}

自动规则生成

老主厨快要退休了，AI 学徒被派去观察他做菜，记录"哪些合并让出餐变快"。看了几万条流程后，学徒总结出若干新建议——比如"卤水豆腐和清蒸搭配时，合并出餐速度提升两成"。但学徒心里清楚，每一条建议都要老主厨审核过后才能上墙。

人工编写融合规则既慢又容易遗漏，研究者和工程师们因此开始用机器学习自动生成规则。整体流程分为四步。样本构建：从开源模型库中采集大量算子子图，请编译器专家标注"这个组合是否值得融合"。特征表征：把算子类型、张量形状、访存模式等编码成向量，让模型能"看懂"子图。模型训练：训练一个二分类模型，预测某个算子组合的融合收益是否为正，损失函数用二元交叉熵。规则提炼：从模型决策边界中提取出可解释的符号规则，直接加载进规则引擎。

这套方法的价值在于规则覆盖面广、能随新模型架构迭代更新。但与"AI 完全替代人工"的想象不同，工程上采用的是"半自动"流程：模型产出候选规则，人工评审语义正确性，通过回归测试后才并入规则库。

这是二元交叉熵损失函数，用来训练"是否值得融合"的分类器。它衡量模型的预测概率与专家标注之间的差距，训练目标就是让这个差距最小。

L(θ)=−1N∑j=1N[yjlog⁡σ(sj)+(1−yj)log⁡(1−σ(sj))]\displaystyle \mathcal{L}(\theta) = -\frac{1}{N} \sum_{j=1}^{N} \left[ y_j \log \sigma(s_j) + (1 - y_j) \log (1 - \sigma(s_j)) \right]
  1. N 样本总数训练数据中不同的算子子图样本个数。
    N:=∣Dtrain∣\displaystyle N := |\mathcal{D}_{train}|
  2. 标签 yⱼ第 j 个样本是否值得融合，由专家标注，1 表示值得融合。
    yj∈{0,1},1 表示值得融合\displaystyle y_j \in \{0, 1\}, \quad 1 \text{ 表示值得融合}
  3. 预测概率 σ(sⱼ)模型对第 j 个样本融合收益为正的预测概率。
    σ(sj):=11+e−sj\displaystyle \sigma(s_j) := \frac{1}{1 + e^{-s_j}}
  4. 损失最小化目标通过优化参数 θ 让预测概率尽量贴近人工标签。 AI 学徒的成长路径——观察、总结、交老师傅把关，与工程中"自动生成 + 人工评审"的闭环如出一辙。机器负责广度和速度，人负责安全和判断，这才是自动规则生成落地的最佳姿势。
    θ∗=arg⁡min⁡θL(θ)\displaystyle \theta^* = \arg\min_\theta \mathcal{L}(\theta)

工程与验证

新建议贴上手册之前，都要先试运行一周。老周会让帮厨记录两个数字：出餐速度提升了多少？菜品质量有没有下降？数据说话，而不是拍脑袋。一条建议哪怕听起来再美，试菜不过关就绝不上墙。

融合规则的工程化同样需要系统验证。衡量规则库质量有两个核心指标。覆盖率（Coverage）：规则库在全量模型图上命中的融合机会占全部可融合子图的比例，覆盖率越高说明规则库越完备。加速比（Speedup）：在标准基准模型上测试融合前后的端到端耗时，验证真实性能收益。

工程团队还会维护一组回归测试集，防止新规则引入编译错误或性能回退。规则库的演进是一个闭环：编写规则 → 单元测试 → 基准评测 → 部署上线 → 采集线上性能数据 → 把数据回填到自动规则生成模块 → 产生新规则候选。这个循环把"人工经验"和"机器发现"拧成一股持续进化的力量。

这条式子计算规则库的覆盖率：分子是所有规则命中子图的并集大小，分母是图中全部可融合子图的总数。覆盖率越接近 1，规则库越完备。

Coverage=∣⋃R∈RMatch(R)∣∣Gfuseable∣\displaystyle Coverage = \frac{\left| \bigcup_{R \in \mathcal{R}} Match(R) \right|}{|G_{fuseable}|}
  1. Match(R)规则 R 在模型图 G 上命中的全部子图集合。
    Match(R):={g⊆G∣g⊨Pattern(R)}\displaystyle Match(R) := \{g \subseteq G \mid g \models Pattern(R)\}
  2. 并集算子把所有规则命中的子图合并去重，得到规则库实际覆盖的集合。
    ⋃R∈RMatch(R)\displaystyle \bigcup_{R \in \mathcal{R}} Match(R)
  3. 分母 |G_fuseable|图中全部可融合子图的总数，代表理想状态下应覆盖的机会。 试菜合格，建议才允许上墙——这就是规则工程化的"品控"精神。覆盖率和加速比是规则库的两把尺子，一把量"看得多全"，一把量"跑得多快"，缺一不可。
    ∣Gfuseable∣:=全部可融合子图数量\displaystyle |G_{fuseable}| := \text{全部可融合子图数量}

AI 应用场景

深度学习编译器中的融合规则库建设

阶段：编译优化（后端 Pass 开发与调优）

解决的问题：XLA、TVM 等编译器需要把越来越复杂的模型（Transformer、多模态）编译成高效内核。传统上工程师手写几十条融合规则，面对新模型结构时反复"打补丁"，规则库迅速膨胀且互相干扰。AI 编译器团队用结构化的 DSL 定义规则，配合优先级与冲突仲裁机制，让规则库像插件一样可以安全扩展。

具体案例：某推理优化团队为大语言模型编写融合规则库时，将"QKV 投影 + 转置 + 缩放点积"这一高频模式定义为一条高优先级规则，同时利用代价模型拒绝在序列长度极短时执行融合，因为此时融合带来的内存节省抵不过内核复杂度增加。最终推理延迟降低 28%，规则库仍保持在 40 条以内的可维护规模。

相关角色：编译器工程师、性能优化工程师、MLOps 平台工程师

端侧推理引擎的算子融合配置

阶段：模型部署（端侧推理引擎配置）

解决的问题：手机、IoT 设备的内存和带宽极其有限。如果每个算子都单独执行，每一层激活值都要写回内存，显存占用和功耗都会飙升。融合规则让多个算子共享一次内存读写，是端侧部署的关键手段之一。端侧编译器的融合规则往往更保守：规则优先保证数值正确性和低内存峰值，而非极限性能。

具体案例：在移动端部署图像分割模型时，工程师通过配置"Conv+BN+ReLU"三合一融合规则，把激活值中间读写减少了两轮，峰值内存占用从 412MB 降到 236MB，同时推理耗时缩短 31%。规则库通过"白名单制"严格放行，任何新规则都必须在三款真机上跑通回归测试。

相关角色：端侧 AI 工程师、嵌入式编译器工程师、移动端开发工程师

自动化融合规则发现平台

阶段：AI for Systems（用机器学习优化系统）

解决的问题：人工维护规则库无法跟上模型架构的快速迭代。自动化平台从海量模型中采集算子子图，训练"是否值得融合"的预测模型，再自动提炼出符号规则供编译器加载。它同时保留了人工审核环节，确保每次规则变更都可追溯、可回滚。

具体案例：某云厂商搭建了融合规则自动发现平台，周期性扫描内部的模型仓库（上千个生产模型），自动生成候选规则并提交到评审队列。编译器团队每周花半天审核候选规则、跑基准测试，合入后平台自动跟踪线上延迟指标。运行一年后，规则库规模扩大 2.3 倍，融合覆盖率提升 35%，而性能回退事故次数为零。

相关角色：AI 系统研究员、编译器自动化平台工程师、性能分析工程师

Python 演示

python69 行
class Op:    ""“计算图中的一个算子节点。”""    def init(self, name, op_type, inputs=None):        self.name = name        self.op_type = op_type        self.inputs = inputs if inputs is not None else []     def repr(self):        return self.name  class FuseRule:    ""“一条融合规则：pattern 为 (op_type1, op_type2)。”""     def init(self, pattern, fused_type, priority=0):        self.pattern = pattern        self.fused_type = fused_type        self.priority = priority     def match(self, ops):        ""“在计算图上寻找所有相邻匹配位置。”""        matches = []        for i in range(len(ops) - 1):            a, b = ops[i], ops[i + 1]            if (a.op_type, b.op_type) == self.pattern:                matches.append((i, i + 1))        return matches     def apply(self, ops, match):        ""“执行融合：把两个算子替换为一个融合算子。”""        i, j = match        fused = Op(            "fused_" + self.fused_type,            self.fused_type,            inputs=ops[i].inputs + ops[j].inputs,        )        return ops[:i] + [fused] + ops[j + 1:]  def optimize(ops, rules):    ""“按优先级反复应用规则，直到计算图不再变化。”""    changed = True    while changed:        changed = False        for rule in sorted(rules, key=lambda r: r.priority, reverse=True):            for match in rule.match(ops):                ops = rule.apply(ops, match)                changed = True                break            if changed:                break    return ops  if name == "main":    graph = [        Op("a", "Add"),        Op("b", "Mul"),        Op("c", "Conv"),        Op("d", "ReLU"),        Op("e", "Pool"),    ]    rules = [        FuseRule(("Add", "Mul"), "AddMul", priority=10),        FuseRule(("Conv", "ReLU"), "ConvReLU", priority=5),    ]    fused = optimize(graph, rules)    print(“融合前：”, graph)    print(“融合后：”, fused)

常见误区

误区我以为融合规则写得越多、能合并的算子越多，编译出来的模型就越快。最好把所有相邻算子都合在一起，一步到位。

正解融合不是免费的。合并后的算子可能寄存器压力暴增、并行度下降，甚至在 GPU 上因为内核过大而触发寄存器溢出。"过度融合"的代码往往比原始代码更慢。工程实践强调"收益可控"：每条规则都要回答"省了多少访存、付出了多少代价"。激进而非理性的融合是性能事故的常见来源，就像把整桌菜倒进一口锅，看似省事，实则全糊了。

为何常见：融合的直接收益（减少中间张量访存）很容易感知，而副作用（寄存器压力、并行度下降）要上硬件才知道，初学者容易只看到前者。

误区我以为规则优先级只是一个启动顺序，先定义的规则先跑，后定义的规则后跑，跟性能关系不大。

正解优先级本质是策略排序，直接决定融合收益能否兑现。高特异性规则应优先于低特异性规则，高频规则应获得更高权重，收益大的组合要优先尝试。设计不当会导致低收益规则先匹配、占用了子图，使高收益规则失去匹配机会——就像主厨先做了不咸不淡的菜，好食材却没派上用场。

为何常见：很多入门教程只讲规则的写法而不展开执行语义，让人误以为执行顺序只是"小事"。

误区我觉得融合规则 DSL 应该像通用编程语言一样强大，任何逻辑都能表达，这样写规则才自由。

正解DSL 的力量恰恰来自限制。只暴露模式、守卫、重写、优先级四个抽象，规则库才能保持声明式、可静态检查、可验证。如果 DSL 引入循环、分支、指针，规则读者没法一眼看出"这条规则会改什么"，编译器也没法做冲突分析。强大的表达能力换来的是失控的规则行为，就像给厨师一本字典而不是一张速记符号表。

为何常见：开发者熟悉通用语言，下意识想把所有灵活性都带进 DSL，忽略了 DSL 的设计目标是"受限才有秩序"。

误区我以为是规则匹配就是在计算图上找一个同构子图，找到就合，就像拼图一样简单。

正解结构相同不代表融合就有收益。两个算子形状不匹配、数据布局不一致、或融合后访存反而增加，这些都靠代价模型来判断。匹配机制必须把结构搜索与代价评估结合起来：结构搜索负责"能不能匹配"，代价模型负责"匹配了值不值"。老周看到"切配+腌制"也不会盲目合并，还要看分量和时间呢。

为何常见：图结构的抽象比较直观，而代价模型涉及访存、并行度等硬件知识，初学者容易忽略后者的重要性。

误区我以为模型自动生成的融合规则肯定比人写的全面，输出后直接加进规则库就行，不用再检查。

正解自动生成规则必须经过人工评审、回归测试、覆盖率验证三个关卡。模型可能在训练分布内表现良好，但遇到未见过的模型架构会产生荒谬规则。工程上采用"半自动"流程：模型产出候选规则，工程师审查语义、跑基准测试，通过后才合入规则库。AI 学徒总结的建议，也得老主厨点头才能上墙。

为何常见："AI 替代人工"的宣传很多，让人误以为生成规则可以跳过质量管控，忽略了编译器是安全关键系统。

面试题

Q1. 融合规则的三要素是什么？

单选题 · easy

  • A.名称、描述、优先级
  • B.算子、边、张量
  • C.模式、条件、动作← 正确答案
  • D.输入、输出、中间值

答案：C。融合规则的核心形式是"Pattern → Action [when Condition]"，三要素即模式（匹配什么子图）、条件（满足什么约束）、动作（如何重写）。名称和优先级只是辅助属性，算子和边是图的构成而非规则要素，输入输出是算子接口，都不属于三要素。

Q2. 垂直融合的主要收益来自哪里？

单选题 · easy

  • A.提高算子的并行度
  • B.增大批量推理尺寸
  • C.减少中间结果的访存← 正确答案
  • D.压缩模型的体积

答案：C。垂直融合把流水线上下游算子合并，例如 Add→Mul→Conv 串成一条线，中间结果不再写回全局内存，而是留在寄存器或片上缓存，从而减少访存开销。算子的并行度由硬件和调度器决定，批量尺寸由上层配置决定，模型体积由压缩量化决定，都不是垂直融合的主要收益。

Q3. 规则 DSL 中 guard 字段的作用是什么？

单选题 · mid

  • A.声明融合算子的代码生成方式
  • B.控制规则执行时的循环次数
  • C.记录规则的修改历史信息
  • D.声明匹配之外的附加约束条件← 正确答案

答案：D。guard 字段声明匹配之后仍需满足的形状、数据类型、副作用等约束，防止结构相同但语义不合的场景被误融合。rewrite 字段才负责声明代码生成方式；循环次数与 DSL 无关；修改历史属于版本管理范畴，均不是 guard 的职责。

Q4. 规则优先级设计中"特异性（Specificity）"的含义是什么？

单选题 · mid

  • A.规则在历史优化中的使用频率
  • B.规则匹配模式的精确程度← 正确答案
  • C.规则融合算子的代码长度
  • D.规则在不同硬件上的运行速度

答案：B。特异性衡量规则模式的精确程度：约束条件越多、能匹配的子图越少，特异性越高，越应优先执行。使用频率是命中频率 Fr(R)，预估收益是 Bn(R)，代码长度和硬件运行速度都不是优先级计算的输入。

Q5. 冲突仲裁中的"保守回退"策略是指什么？

单选题 · mid

  • A.永远选择最先匹配的规则
  • B.随机选择一条规则执行
  • C.无法判定优劣时放弃融合← 正确答案
  • D.同时执行所有冲突规则

答案：C。保守回退指当冲突规则无法判定优劣时，默认放弃融合，保证正确性优先。这与"选最先匹配"（依赖定义顺序）和"随机选择"（引入不确定性）都不同；同时执行互斥规则会破坏图结构，显然是错误选项。

Q6. 下列哪些属于规则冲突处理的常见方法？

多选题 · mid

  • A.收益仲裁，选 Gain 最大者← 正确答案
  • B.条件细化，让适用区域不重叠← 正确答案
  • C.保守回退，无法判定则不融合← 正确答案
  • D.暴力重写，覆盖所有冲突规则

答案：ABC。收益仲裁从冲突集中选 Gain 最大者；条件细化通过增加 guard 让规则各管一段；保守回退在无法判定时不融合，三者都是工程实践中的合法策略。"暴力重写覆盖所有规则"违背规则互斥性，会破坏计算图语义，不是冲突处理手段。

Q7. 自动规则生成中"规则提炼（Rule Extraction）"的目标是什么？

单选题 · hard

  • A.提升模型的训练准确率
  • B.减少训练样本总量
  • C.将规则库编译为二进制
  • D.抽取可解释符号规则集← 正确答案

答案：D。规则提炼从训练好的模型决策边界中提取可解释的符号规则，供规则引擎直接加载。提升训练准确率是模型训练阶段的目标，减少样本数量不是目标，编译成二进制是工程部署细节，都不是规则提炼的本质含义。

Q8. 融合覆盖率指标 Coverage 的分母是什么？

单选题 · hard

  • A.图中全部可融合子图数← 正确答案
  • B.规则库中规则的总数
  • C.模型的总参数量大小
  • D.编译器的活跃用户数

答案：A。Coverage 的分母是图中全部可融合子图的总数，分子是规则库命中子图的并集。它衡量规则库的完备程度——规则库最多能抓住多少融合机会。规则总条数、模型参数量、用户数量都与覆盖率无关。

Q9. 规则 DSL 采用声明式语法的主要好处有哪些？

多选题 · easy

  • A.规则库可读性强方便维护← 正确答案
  • B.编译期执行静态语法检查← 正确答案
  • C.减少手写遍历重写逻辑← 正确答案
  • D.生成代码运行速度会更快
  • E.在 guard 中增加互斥条件
  • F.用收益函数选择最优规则
  • G.检测到性能回退时自动撤销
  • H.关闭全部融合优化策略

答案：ABC。增加互斥 guard 能让冲突规则各管一段；收益函数仲裁选最优；回退机制在性能倒退时自动撤销，三者构成完整的冲突处理链。"关闭全部融合优化"是放弃策略而非处理冲突的方法，只在极端场景下作为终极保险手段，不属于常规冲突处理手段。