算子融合：融合边界

可视化演示

融合收益来源：为什么大厨要“一锅出”

老周后厨的墙上贴着一张泛黄的纸，上面写着“并菜三不炒”——这是他自己总结的规矩。可这规矩是怎么来的？老周说：“并一锅菜，最省的是来回跑腿。原来炒完回锅肉，要端出去放架子上，等下一道菜再端回来；合并了，这盘菜不出锅直接进另一道菜的锅。”算子融合的动机一模一样。GPU 执行一个算子，要从全局内存（相当于后厨仓库）把数据读进计算单元，算完再写回仓库。算子越多，数据在仓库和灶台之间往返的次数就越多。融合后，中间结果就留在灶台旁的调料架上（片上缓存或寄存器），下一道菜直接用，跑腿次数大幅减少。

每个算子单独执行时，GPU 都要经历一次“点火”——内核启动的开销。几千个算子就是几千次点火，每次点火都有固定的指令分发成本。融合把 N 个内核合并成 1 个，启动成本直接除以 N。更妙的是缓存局部性：原本被写回仓库的中间数据，现在留在高速缓存里被紧接着的算子反复使用，命中率上升，整体延迟下降。

$$\displaystyle \text{Saved} = (m + n + k) - (m + k) = n$$

1. \(\displaystyle (m + n + k)\)（融合前总访存量）：三个独立算子各自运行，每个算子的中间结果都要完整写回全局内存一次。m 是第一个中间张量，n 是第二个中间张量，k 是最终输出。

$$\displaystyle (m + n + k)$$

2. \(\displaystyle (m + k)\)（融合后总访存量）：三个算子合并成一个内核后，中间张量 m 和 n 不再写回全局内存，只保留最终输出 k。

$$\displaystyle (m + k)$$

3. \(\displaystyle = n\)（净节省量）：相减之后，节省的访存量恰等于第二个中间张量 n 的大小——这就是融合带来的最直接收益。

$$\displaystyle = n$$

当然，融合不是免费的午餐。把多道菜倒进一口锅，锅里的空间、火候的调配、食材下锅的顺序都成了新问题。要判断哪些算子值得融合、哪些硬融合反而翻车，需要先看清束缚融合的四道无形边界。

数据依赖分析：菜的先后顺序

老周知道，有些菜是“喂”出来的：蒜香排骨的炸蒜末，是另一道蒜蓉娃娃菜的灵魂；如果为了省火把两锅硬并成一锅，蒜末还没炸够火候就被娃娃菜的水汽泡软了。算子之间也有这种“喂养”关系。在编译器里，它叫数据依赖。最重要的依赖叫 RAW（读后写）依赖：算子 A 的输出恰好是算子 B 的输入，B 必须等 A 算完才能开工。好消息是，链式的 RAW 依赖（A→B→C）恰恰是融合最理想的场景——A 的产物留在片上直接喂给 B，连写回都省了。

真正卡住融合的是另外两种情况。第一种是多消费者：A 的输出同时被 B 和 C 两个算子使用，B 和 C 在图中分处不同分支。如果要让 B 和 A 融合，中间结果就必须复制一份；这份拷贝的代价可能抵消融合收益。第二种是 WAR/WAW 依赖——在循环体或并行上下文中，后一个算子可能覆盖前一个算子还没读完的数据，这种依赖限制了内核的重新排序。此外，如果算子之间形成了依赖环，整个环上就不能做任何跨算子的调度优化。

$$\displaystyle \text{consumers}(t) = \left|\{op \in \text{Graph} : t \in \text{inputs}(op)\}\right| \leq 1$$

1. \(\displaystyle \text{consumers}(t)\)（张量 t 的消费者数量）：统计整个计算图里，有多少个算子把张量 t 作为输入。食材 t 被几道菜取用，决定了它能不能安心待在调料架上。

$$\displaystyle \text{consumers}(t)$$

2. \(\displaystyle |\{op \in \text{Graph} : t \in \text{inputs}(op)\}|\)（集合的大小）：花括号里筛选出所有输入中包含 t 的算子，外层竖线表示这个集合的元素个数。

$$\displaystyle |\{op \in \text{Graph} : t \in \text{inputs}(op)\}|$$

3. \(\displaystyle \leq 1\)（不超过一个消费者）：只有消费者数量不大于 1 时，融合才可能在依赖层面放行。

$$\displaystyle \leq 1$$

数据依赖是边界的内圈——它划定了“能不能合”的最低底线。但即使依赖没问题，有些菜依然不能一锅出，因为口味会串。

精度约束：口味不能串

老周最头疼的客人是点“清蒸鲈鱼”的：这道菜必须单独一口蒸锅，小火慢蒸八分钟，期间开盖次数都有讲究。有一次他图省事，把鲈鱼架在麻辣香锅上面一起蒸，结果鱼肉吸足了麻辣味，被客人骂了三天。算子里也有这种“口味敏感”的主儿。数值稳定性差的算子，对中间结果的舍入时机极其敏感。

把两个算子融合，意味着中间结果的命运被改写：原来要先写回全局内存（相当于端到架子上晾着），按照目标精度做一次舍入；融合后则留在寄存器里直接传递，少了一次舍入。多数情况下这会更精确，但如果融合改变了运算顺序——比如把 A+B+C 的逐次相加改成一次树状归约——浮点数的累积误差就会产生偏差。对于训练中梯度的累积、Softmax 这类对数值范围极其敏感的操作，编译器宁可保守一点：一旦模拟出的误差超过阈值，就拒绝融合。

$$\displaystyle |f_{\text{fused}}(x) - f_{\text{orig}}(x)| \le \tau$$

1. \(\displaystyle f_{\text{fused}}(x)\)（融合后的算子）：把多个算子合并成一个内核后，输入 x 得到的计算结果。

$$\displaystyle f_{\text{fused}}(x)$$

2. \(\displaystyle f_{\text{orig}}(x)\)（融合前的算子组合）：没有做融合、按原始顺序逐个执行时的计算结果。它是精度的“基准线”。

$$\displaystyle f_{\text{orig}}(x)$$

3. \(\displaystyle |\cdot|\)（绝对误差）：两条计算路径的输出差异，取绝对值保证比较的是差距大小。

$$\displaystyle |f_{\text{fused}}(x) - f_{\text{orig}}(x)|$$

4. \(\displaystyle \le \tau\)（容忍阈值）：误差不超过 τ 才能放行融合；超过了，说明“串味”严重，编译器会维持原状。

$$\displaystyle \le \tau$$

精度这道边界像后厨的口味红线——过了线的菜宁可不卖也不能砸招牌。但就算依赖和精度都放行，还有一道更物理的边界拦在面前：锅就那么大。

硬件资源限制：锅有多大灶有几个

小面馆的灶台只有四个，最大的炒锅只能装下三斤食材。老周并菜前必须心里过一遍：这道菜要占多大锅、多少油、几个灶眼。GPU 里的“锅”就是寄存器文件和片上共享内存。每个算子都声明需要多少寄存器、多少共享内存；融合后的内核要把所有算子的资源需求累加在一起。一旦总和超过硬件上限，编译器就必须把一部分“食材”倒退回全局内存——这叫寄存器溢出，性能反而暴跌。

资源限制还包括线程块规模：融合后的算子可能对线程/数据映射有不同要求，比如一个算子需要 512 线程，另一个需要 128 线程，合并后统一成 512 并不总是合理。另外不要小看编译时间——把 N 个算子揉进一个内核，指令调度、寄存器分配的复杂度会急剧上升，编译器可能要花几十分钟去优化一个每秒执行几十次的小算子，这在动态图训练场景下是不可接受的。

$$\displaystyle \sum_{op \in \text{fused}} \text{regs}(op) \le R_{\text{max}}$$

1. \(\displaystyle \sum_{op \in \text{fused}}\)（对融合组求和）：把准备融合到一起的每一个算子的资源需求全部加起来。

$$\displaystyle \sum_{op \in \text{fused}}$$

2. \(\displaystyle \text{regs}(op)\)（算子 op 的寄存器需求）：每个算子在编译时生成的代码需要占用多少个寄存器。

$$\displaystyle \text{regs}(op)$$

3. \(\displaystyle \le R_{\text{max}}\)（硬件寄存器上限）：当前 GPU 微架构每个流处理器可用的寄存器总数。资源超限，融合方案直接被否决。

$$\displaystyle \le R_{\text{max}}$$

硬件边界是刚性的——锅就那么大，装不下就是装不下。可就算资源够用，有些算子天生“性格孤僻”，压根不适合跟别人挤一口锅。

不可融合特征：必须单做的菜

老周的后厨有这么几样宝贝，永远单独占一个灶：老鸭汤要文火慢炖六小时，期间不能揭盖；炸串的油锅温度必须恒定在 180 度，放别的菜进去就会串味、降油温。这类“单做菜”在算子世界里同样存在，它们有鲜明的特征。

首当其冲的是归约算子（如全局求和、Softmax 的分母计算）。它需要跨线程、跨线程块地通信汇总，天然要求一个独立的 kernel 来协调同步；强行把它和逐元素算子融合，要么引入巨大的同步开销，要么需要用复杂的置换让整个线程块停下来等待。其次是动态形状——如果算子的输出尺寸取决于数据本身（比如非极大值抑制或条件筛选），编译器在编译期无法确定中间张量多大，融合后难以分配片上存储。控制流分支多的算子（如包含 if-else 的复杂算子供 逻辑）会让 fused kernel 的指令调度变成一团乱麻。最后是多消费者输出：一个算子的结果被图上多个算子使用，融合后无论跟哪边“绑定”，另一边都会被迫重复计算或追加拷贝。

$$\displaystyle \text{NoFuse}(B) : \text{Reduce}(B) \lor \text{Dynamic}(B) \lor \text{Branch}(B) \lor (\text{consumers}(B) > 1)$$

1. \(\displaystyle \text{NoFuse}(B)\)（不可融合判定）：判定算子 B 是否属于不可融合的类型。

$$\displaystyle \text{NoFuse}(B)$$

2. \(\displaystyle \text{Reduce}(B) \lor \text{Dynamic}(B) \lor \text{Branch}(B)\)（或逻辑连接）：B 是归约算子、动态形状、含控制流分支——三者命中其一即可判负。符号 \(\lor\) 表示逻辑“或”，像后厨的黑名单上列了四类禁并菜。

$$\displaystyle \text{Reduce}(B) \lor \text{Dynamic}(B) \lor \text{Branch}(B)$$

3. \(\displaystyle \text{consumers}(B) > 1\)（多消费者）：B 的输出被不止一个算子依赖。即使前三个特征都没命中，这一条也会把它推回“单做”阵营。

$$\displaystyle \text{consumers}(B) > 1$$

这四个特征像是后厨黑名单：凡是命中，无论融合收益多诱人，编译器都会坚决守住边界。这四类“硬钉子”划定了融合边界的最外围。

边界判定规则：大厨的决策清单

老周的灶台边贴着一张脏兮兮的“并菜检查单”，上面四行字：一看先后（依赖）、二看口味（精度）、三看锅量（资源）、四看值不值（收益）。编译器里的融合边界判定器，执行的是同一套流程——按顺序过四关，任何一关不过就否决。

第一关依赖优先检查：确认目标算子间是否存在连接关系。链式 RAW 依赖是融合的“绿灯”，多消费者或依赖环则是“红灯”。第二关精度兼容检查：在模拟器上跑一遍融合前后的数值误差，超阈值则打回。第三关资源预算核算：把寄存器、共享内存、线程数需求逐项累加，对照硬件上限。最后一关收益预估：估算融合到底能省多少访存、多少启动开销，如果收益小于某个经验阈值，编译器觉得“不值得为省一毛钱费这么大的劲”，也会放弃。

$$\displaystyle \text{CanFuse}(A,B) = \text{DepOK}(A,B) \land \text{PrecOK}(A,B) \land \text{ResOK}(A,B) \land \text{GainOK}(A,B)$$

1. \(\displaystyle \text{CanFuse}(A,B)\)（融合可行性结论）：判定算子 A 和 B 能否被合并进同一个内核，结果是一个布尔值。

$$\displaystyle \text{CanFuse}(A,B)$$

2. \(\displaystyle \land\)（逻辑与）：四个条件必须全部为真。符号 \(\land\) 表示“且”，有一个假就是假。

$$\displaystyle \land$$

3. \(\displaystyle \text{DepOK}(A,B)\)（依赖检查）：A 与 B 之间不存在禁止融合的依赖模式（多消费者、依赖环）。

$$\displaystyle \text{DepOK}(A,B)$$

4. \(\displaystyle \text{PrecOK}(A,B) \land \text{ResOK}(A,B) \land \text{GainOK}(A,B)\)（精度、资源、收益）：精度模拟误差在容忍阈值内；寄存器与共享内存预算充足；预估收益大于设定阈值。

$$\displaystyle \text{PrecOK}(A,B) \land \text{ResOK}(A,B) \land \text{GainOK}(A,B)$$

这套检查单把融合从“经验之谈”变成了可以自动执行的工程规则。但规则的背后，永远藏着更微妙的权衡——因为每道菜都同时受多个目标拉扯。

融合权衡决策：不是所有融合都划算

并菜一定要赚钱吗？老周吃过一次大亏：为了把一个回锅肉和一个水煮肉片并锅，他省下了 40 秒，但两道菜同时起锅导致锅温不够，肉片全老在锅里，客人退菜赔了 20 分钟。这个教训说明：省下的时间≠净赚的时间。融合决策同样是一场得失权衡。

融合最大的隐性成本是并行度损失。独立的算子执行时，GPU 可以在两个 kernel 之间重叠部分计算；融合后这种重叠消失，不同算子之间的并行机会化为乌有。同时，融合把多个中间值都塞进寄存器，可能让单个线程的寄存器压力逼近上限——一旦触发溢出，代价相当高昂。反过来，融合带来的缓存重用收益十分可观：中间结果在 L1/L2 里被当下一个算子的输入，命中一次能省数倍于计算本身的延迟。这里没有恒定的公式，只能靠经验阈值——编译器通常内置一套收益预测模型，根据目标硬件的访存带宽和缓存大小，估算每个融合点的预期收益，低于阈值就收手。

$$\displaystyle \Delta T = T_{\text{mem}}(A,B) - T_{\text{overlap}}(A,B) - T_{\text{spill}}(A,B) > 0$$

1. \(\displaystyle \Delta T\)（净收益）：融合相比不融合真正节省的执行时间。正数才值得做。

$$\displaystyle \Delta T$$

2. \(\displaystyle T_{\text{mem}}(A,B)\)（省下的访存时间）：中间张量不再写回全局内存所节省的时间，这是融合的主要收益来源。

$$\displaystyle T_{\text{mem}}(A,B)$$

3. \(\displaystyle T_{\text{overlap}}(A,B)\)（损失的并行重叠时间）：原本两个独立内核可以在不同流上并行执行，融合后这种重叠被取消。

$$\displaystyle T_{\text{overlap}}(A,B)$$

4. \(\displaystyle T_{\text{spill}}(A,B)\)（寄存器溢出代价）：融合导致寄存器不够用，数据被挤回内存的额外开销；如果为负收益，说明融合方案该放弃了。

$$\displaystyle T_{\text{spill}}(A,B) > 0$$

权衡的艺术让融合边界变成了一条动态的曲线，而不是一堵僵硬的墙。但好在，这条曲线是可以被量化和调校的——这就是调优实践要做的事。

调优实践方向：大厨如何精进

每个季度末，老周都会翻一遍点单记录，找出“被退菜最多”的几道并菜组合，重新调整他的并菜清单。编译器工程师也这样做。性能剖析定位是第一步：用 NVIDIA Nsight Compute 或 PyTorch Profiler 打出每个 kernel 的耗时，凡是“执行时间短但访存量极大”的 kernel 序列，就是融合的重点候选。编译器开关探索则是第二板斧——TVM 里的 allow_fuse 配置、XLA 的融合等级、Triton 的手写 kernel，都是一层层揭开边界的方式：调松融合等级看是否更快，调紧是否更稳。

更精细的手法叫手工融合标注：当自动融合器因为保守规则放弃某个边界案例时，工程师可以用自定义算子手写一个融合 kernel，比如把 LayerNorm 的均值、方差、归一化三个算子手工合并成一个。但踩过坑的人都知道，任何手工优化都必须经过融合后验证——数值误差对比、吞吐对比、多硬件平台回归。毕竟，老周的新菜谱也是先给熟客试吃一周，确认不砸招牌才正式上菜单的。

$$\displaystyle \min_{F \in \mathcal{F}} \text{latency}(\text{graph}, F)$$

1. \(\displaystyle \min_{F \in \mathcal{F}}\)（在所有合法方案中取最小）：遍历所有满足边界条件的融合方案，找到延迟最小的那一个。

$$\displaystyle \min_{F \in \mathcal{F}}$$

2. \(\displaystyle \text{latency}(\text{graph}, F)\)（端到端延迟）：给定融合方案 F 时，整个计算图的运行时间——这是衡量调优效果的最终指标。

$$\displaystyle \text{latency}(\text{graph}, F)$$

从收益来源到边界判定，从权衡取舍到调优实践，融合边界始终在回答那个朴素的问题：并菜到底省不省？ 了解这条边界，你就能在编译器的决策日志里看出门道，在性能剖析中找到真正的瓶颈，甚至亲手优化出一条更高效的执行路径。

AI 应用场景

Python 演示

"""融合边界检查器：模拟编译器对算子融合的四关检查。"""from dataclasses import dataclass, fieldfrom typing import List, Set  @dataclassclass Operator:    name: str    op_type: str          # "elementwise" 或 "reduce"    inputs: List[str]    outputs: List[str]    uses_branch: bool = False     def regs(self) -> int:        return 8 if self.op_type == "elementwise" else 32  class FusionBoundaryChecker:    def __init__(self) -> None:        self.ops: Set[str] = set()        self.cons_map: dict[str, Set[str]] = {}        self.reg_limit = 48     def add_op(self, op: Operator) -> None:        self.ops.add(op.name)        self.cons_map[op.name] = set(op.outputs)        self._ops_list.append(op)     def _find(self, name: str) -> Operator | None:        for op in self._ops_list:            if op.name == name:                return op        return None     def consumers(self, tensor: str) -> int:        count = 0        for op in self._ops_list:            if tensor in op.inputs:                count += 1        return count     def dep_ok(self, a: Operator, b: Operator) -> bool:        for t in a.outputs:            if self.consumers(t) > 1:                return False        shared = set(a.inputs) & set(b.inputs)        return len(shared) == 0 or all(self._find(x) is None for x in shared)     def prec_ok(self, a: Operator, b: Operator) -> bool:        return not (a.op_type == "reduce" and b.op_type == "reduce")     def res_ok(self, a: Operator, b: Operator) -> bool:        return a.regs() + b.regs() <= self.reg_limit     def fuse(self, a: Operator, b: Operator) -> bool:        checks = {            "dep": self.dep_ok(a, b),            "prec": self.prec_ok(a, b),            "res": self.res_ok(a, b),            "branch": not (a.uses_branch or b.uses_branch),        }        return all(checks.values()), checks  def main():    checker = FusionBoundaryChecker()    relu = Operator("Relu", "elementwise", ["x"], ["t1"])    add = Operator("Add", "elementwise", ["t1", "b"], ["t2"])    softmax = Operator("Softmax", "reduce", ["t2"], ["y"])    mul = Operator("Mul", "elementwise", ["t2"], ["z"])    for op in [relu, add, softmax, mul]:        checker.add_op(op)     pairs = [("Relu", "Add"), ("Add", "Softmax"), ("Softmax", "Mul")]    for na, nb in pairs:        oa = checker._find(na)        ob = checker._find(nb)        ok, why = checker.fuse(oa, ob)        print(f"fuse {na} + {nb}: {ok} {why}")  if __name__ == "__main__":    main()

1. class FusionBoundaryChecker:检查器的主体，类比老周后厨的“并菜检查单”，每个方法对应一道关卡。
2. def consumers(self, tensor) -> int:统计一个张量被多少个算子消费。返回值大于 1 意味着多消费者，融合需要额外拷贝。
3. def dep_ok(self, a, b) -> bool:第一关：依赖检查。任一中间张量被多个消费者使用时返回 False。
4. def prec_ok(self, a, b) -> bool:第二关：精度检查。归约算子与归约算子融合容易造成数值不稳定，拒绝放行。
5. def res_ok(self, a, b) -> bool:第三关：资源检查。两算子寄存器需求之和不能超过硬件上限（此处简化为 48 个寄存器）。
6. checks = {"dep": ..., "prec": ..., ...}收集四项检查结果，用 all() 做逻辑与，对应公式中的 \(\land\) 判定。
7. pairs = [("Relu", "Add"), ...]依次测试三对算子的融合可能性，输出每一对的检查明细。

常见误区

面试题