垂直融合 Vertical Fusion：算子融合优化核心技术

可视化演示

展示垂直融合将相邻算子串联为单kernel的数据流过程、融合窗口选择策略与垂直/水平融合对比，理解AI编译器核心优化技术。

融合基础

前面说到，餐厅后厨的传菜环节浪费了大量时间。在 AI 芯片的世界里，这道“菜”就是计算产生的中间结果，而“传菜的盘子”就是全局内存（Global Memory），也叫 HBM（高带宽内存）。每当一个算子计算完毕，结果就要被“装盘”——写回全局内存；下一个算子开始前，又要把“菜”从盘子里取出来——从全局内存读取。这一写一读的访存操作，比计算本身慢上数百倍，是整个推理链路中最拖后腿的环节。

算子融合（Operator Fusion） 正是为此而生。它把数据流上相邻的多个算子合并成一个“超级算子”（mega-kernel），让中间结果在芯片内部的寄存器或共享内存中直接传递，省去了“装盘传菜”的往返。这种沿数据流方向、将前后串联的算子合并的方式，就是垂直融合（Vertical Fusion）。与之相对的是把同层、互不依赖的算子合并的水平融合（Horizontal Fusion），后续章节会详细对比。

垂直融合的核心洞察其实非常简单：访存是瓶颈，计算是便宜的。芯片的计算单元每秒能做几万亿次运算，但数据的搬运速度远远跟不上。正如餐厅里，师傅们切菜炒菜的速度极快，但传菜员在厨房里跑来跑去才是真正浪费时间的地方。垂直融合要做的，就是把这些“传菜员”从关键路径上撤掉。

回到厨房的比喻：如果一次请客要上十道菜，每道菜都由洗、切、炒三个师傅完成，传统的做法是每道菜都装盘传一次。垂直融合相当于让三位师傅组成一个“流水线小组”，第一道菜洗完直接滑到切菜板，切完直接进炒锅，十道菜下来省掉了二十次传菜。这就是它最朴素也最强大的威力。

数据流分析

既然要融合，首先得知道哪些算子能融合、哪些不能。这就好比餐厅经理要搞清楚：哪道菜必须等前面的工序完成才能开始？哪些工序之间可以无缝衔接？在编译器领域，这个摸底过程叫做数据流分析（Data Flow Analysis）。

数据流分析的核心是依赖关系识别。编译器会为每个算子建立一张“食材清单”（输入数据）和“菜品列表”（输出数据）。如果一个算子的输出恰好是下一个算子的输入，它们之间就存在生产者-消费者（Producer-Consumer）关系，这就是垂直融合的候选对象。就像切好的土豆丝恰好是炒菜师傅的原料，这两个工序天然适合肩并肩。

进一步地，编译器需要追踪中间结果的完整生命周期：从它被第一个算子“生产”出来，到被最后一个算子“消费”完毕。这个过程叫做访存轨迹追踪（Memory Access Tracing）。如果中间结果只被一个下游算子消费一次，那么融合后它就可以完全停留在寄存器中——这是最理想的融合场景。但如果它被多个算子共享，就需要仔细权衡是否值得融合。

数据流分析就像餐厅经理拿着“菜品流程图”，把每一道菜从洗菜到上桌的全过程画出来。通过这张图，经理能一眼看出哪些步骤是环环相扣的“流水线”，哪些是各自独立的“小作坊”。只有流水线上的工序才适合垂直融合，而独立的工序强行融合反而会打乱节奏。

融合窗口策略

知道了哪些算子可以融合，下一个问题是：一次融合多少个？这就像餐厅经理决定把多少道工序组成一个流水线小组。这个决策在编译器中被称为融合窗口（Fusion Window）策略，简单说就是一个“滑动窗口”在算子序列上滑动，每次圈定一批算子尝试融合。

窗口大小是其中最核心的权衡。窗口太大，一次融合的算子过多，中间结果虽然不再写回内存，但都要占着寄存器不放。而芯片的寄存器文件（Register File） 容量有限，就像厨房的操作台只有那么大，把所有食材都堆在上面会放不下，导致“溢出”到内存——这反而比不融合更慢。这就是寄存器压力（Register Pressure）预算问题。

编译器需要精打细算：融合后的超级算子在执行过程中，最多同时需要多少个寄存器来存放中间结果？这个数量必须小于芯片的寄存器总数。因此，窗口的选择本质上是一个约束优化问题：在寄存器容量允许的前提下，让融合的算子数量尽量多。

除了寄存器压力，融合窗口还会影响缓存局部性（Cache Locality）。窗口越大，数据被重复从内存读取的机会越少，缓存的命中率越高——就像流水线小组越长，菜在半成品状态下流转次数越多，越不需要从冷库重新取货。但过长又会导致操作台拥挤。编译器需要在这两者之间寻找甜蜜点。

水平协同组合

垂直融合并非孤军奋战。在真实的编译器中，它还有一个默契的搭档——水平融合（Horizontal Fusion）。如果说垂直融合是“前后串联的流水线合并”，那么水平融合就是“平行排列的工位合并”。

想象餐厅里有两位甜品师傅，分别在两个工作台做一模一样的提拉米苏。水平融合相当于把两个工作台合并成一个，让一位师傅同时对两份食材进行操作，共享配料和工具。在 AI 计算中，水平融合针对的是同层、共享输入或共享计算的算子，比如把两个独立的 element-wise 操作合并成一个，减少 kernel 启动次数。

实际优化中，编译器通常遵循先水平后垂直（Horizontal First, Then Vertical） 的策略。原因不难理解：先做水平融合，可以把同层的多个算子先“折叠”成少数几个；再做垂直融合，把这几层再“串联”成一条更紧凑的流水线。这就像先收拾桌面——把散落的工具归类放好——再规划流水线流程。

餐厅经理最终决定：先把所有甜品工位合并成一个“甜品岛”，再把甜品岛与主厨的灶台串联成“前菜-主菜-甜品”的无缝流水线。垂直融合与水平融合的协同，正是编译器优化中“两条腿走路”的智慧。

寄存器驻留

垂直融合最核心的收益，在于让中间结果驻留（Reside）在寄存器或共享内存中，而不写回全局内存。这需要深入理解芯片的存储层级。

在 GPU 等 AI 加速芯片中，存储系统是一个金字塔：最顶端是寄存器（Register），速度最快、容量最小，大约几十 KB；中间是共享内存（Shared Memory） 和一级缓存，速度次之；底层是全局内存 HBM，容量大但速度慢。数据离计算单元越近，访问越快。垂直融合的目标，就是让中间结果尽量留在金字塔的顶层。

实现寄存器驻留的关键在于中间结果传递机制。在融合后的超级算子中，每个算子从寄存器中读取输入，计算结果仍然写回寄存器，下一个算子直接从同一个寄存器读取——中间完全不触碰内存。这就像流水线上，洗好的菜直接滑到切菜板上，切好的菜直接推进炒锅，案板之间用滑槽连接，菜永远不会被端离这条线。

当然，寄存器驻留也有代价：寄存器是稀缺资源，驻留的数据越多，每个线程可用的寄存器越少，可能降低并行度。这再次回到融合窗口策略的权衡。但无论如何，让中间结果“住在”寄存器里，是垂直融合性能收益的最大来源，也是编译器优化中最诱人的一块蛋糕。

性能实战

理论讲得再好，不如用数据说话。在深度学习模型的实际部署中，垂直融合的收益可以用一个具体的例子来说明。

以 ResNet-50 中的一段典型计算为例：一个 Conv2D 卷积层后面紧跟着 BatchNorm 批归一化和 ReLU 激活函数。在未融合的朴素实现中，这三个算子依次执行：卷积结果写回 HBM，BatchNorm 读取再写回，ReLU 再读取再写回。每一步都涉及数百 MB 的数据搬运。而经过垂直融合后，三个算子合并为单个 kernel，卷积的结果直接进入寄存器，BatchNorm 和 ReLU 依次在相邻寄存器中完成，数据从不离开芯片内部。

访存延迟对比是衡量收益最直观的指标。在一次典型的推理任务中，融合前每个算子平均访存延迟约 120 个时钟周期，融合后下降到约 20 个时钟周期。这意味着，仅访存一项就节省了超过 80% 的时间。在端到端延迟上，垂直融合通常可以为推理模型带来 1.5x 到 3x 的加速，具体取决于模型中算子间的数据复用程度。

回到厨房的比喻：把洗、切、炒三个环节垂直融合后，原本做一道菜要跑三次操作台，现在只需要一条滑槽从头滑到尾。餐厅翻台率从每小时十桌提升到二十桌，这就是垂直融合在真实世界中的威力。理解这条优化路径，你就掌握了 AI 编译器性能优化的核心密码之一。

AI 应用场景

Python 演示

"""Simple vertical fusion simulation. Simulate the memory access cost of fused vs unfused operators."""  class VerticalFusionSimulator:    def __init__(self, operators, data_size=1024):        # data_size: per-operator intermediate data size (KB)        self.ops = operators        self.data_size = data_size        self.mem_latency = 200  # cycles per KB        self.compute_latency = 20  # cycles per operator     def unfused_cost(self):        # Each op writes and reads its result from global memory        total = 0        for _ in self.ops:            total += self.compute_latency            total += 2 * self.data_size * self.mem_latency        return total     def fused_cost(self):        # Single kernel: compute all ops, only one memory write at the end        total = len(self.ops) * self.compute_latency        total += self.data_size * self.mem_latency        return total     def speedup(self):        unfused = self.unfused_cost()        fused = self.fused_cost()        return unfused / fused  def main():    ops = ["Conv2D", "BatchNorm", "ReLU", "Add"]    sim = VerticalFusionSimulator(ops, data_size=1024)     unfused = sim.unfused_cost()    fused = sim.fused_cost()    sp = sim.speedup()     print("=== Vertical Fusion Cost Simulation ===")    print(f"Operators: {ops}")    print(f"Unfused total cost: {unfused} cycles")    print(f"Fused total cost: {fused} cycles")    print(f"Speedup: {sp:.2f}x")  if __name__ == "__main__":    main()

1. class VerticalFusionSimulator定义模拟器类，封装算子列表和数据量参数，类比“厨房流水线模拟器”。
2. self.mem_latency = 200设置每 KB 数据的访存延迟为 200 周期，在实际硬件中全局内存延迟约为计算延迟的 10 倍以上。
3. for _ in self.ops遍历每个算子，未融合时每个算子都独立产生一次完整的写回+读取开销。
4. total += 2 * self.data_size * self.mem_latency一次写入加一次读取，共两次全局内存访问，这是融合要消除的“传菜”开销。
5. fused_cost融合后所有算子共享一次访存，相当于把多个工序放在同一条流水线上，只需一次“装盘”。
6. speedup计算加速比，即未融合总成本除以融合总成本，量化优化收益。

常见误区

面试题