算子融合：水平融合

可视化演示

展示Transformer自注意力机制的QKV矩阵计算、注意力权重归一化及多头并行处理流程，步进切换查看注意力核心步骤。

融合基本概念

快递站里最常听见的声音是站长喊“出车！”。每喊一声，快递员就要从椅子上站起来、穿反光背心、扫码装车、查路线——这一整套动作，无论包裹是一个还是一百个，时间一分不少。在 GPU 计算的世界里，“出车”就是一次 kernel 启动，而快递员的固定准备时间，就是启动开销。

深度学习模型在训练或推理前，会被编译器转换成一幅计算图：节点是算子（比如加法、ReLU、矩阵乘），边是张量流动。编译器接下来要回答一个关键问题：这些算子怎么翻译成 GPU 上真正执行的 kernel？朴素的做法是一个算子一个 kernel，但小算子越多，启动开销就越刺眼。

于是有了算子融合。按合并对象之间的关系，融合分成两类。垂直融合合并的是“生产者—消费者”关系的算子，a 算完把结果交给 b，相当于接力赛——快递员送完一段，下一位在中转站接力；经典案例是把 Conv 和 ReLU 合成一个 kernel，省掉中间结果的显存往返。水平融合合并的则是“相同输入”或“独立执行的同类算子”，相当于拼单——三个包裹都去同一栋楼，装一辆车走一趟。

所以水平融合的本质，是快递站的那条规矩：拼单的前提是“顺路又同类”，而不是不管三七二十一把所有包裹硬塞一辆车——至于什么算顺路，正是下一节要讲的匹配条件。

水平匹配条件

老站长在墙上贴了一张拼单须知：去不同小区的不能拼，生鲜和普通件不能混装，超过车厢容积的不能硬塞。水平融合同样有一张“拼单须知”，每条都对应一个编译期可检查的匹配条件。

编译器在图优化阶段会逐个扫描算子对，判断它们能否水平融合。判断的依据集中在四个维度。第一，相同输入依赖：两个算子读同一个张量（例如 add 和 multiply 都读取 tensor A），融合后这个张量只需读一次，能省访存带宽。第二，算子类型一致：一般要求算子属于同一类别（如都是 element-wise，即逐元素运算的算子），同类算子的计算模式接近，才能在同一个 kernel 里用同一种线程布局处理；类型差太远（一个矩阵乘、一个 ReLU），融合后的 kernel 会变得复杂且难以优化。第三，形状兼容：输入输出张量的形状和内存布局一致，否则线程与数据的映射关系无法统一。第四，无副作用约束：算子不能有全局副作用（比如更新全局计数器、写外部文件），否则合并后执行次序改变会破坏语义。

拼单须知上的每一条，都能在图结构里“对号入座”地检查。只有四张通行证全部盖章的算子对，才配被装进同一辆快递车。

合并调度策略

包裹装上车只是开始。到了小区，快递员是先送三号楼还是先送七号楼，走哪条路线能少爬楼梯，这才是真正决定一趟配送快慢的细节。水平融合后，新 kernel 内部同样要重新做一次“派送路线规划”。

融合完成不代表优化完成。合并后的 kernel 必须回答三个问题：谁来执行、执行多少、数据怎么读。典型的调度策略包含四点。单 kernel 统一调度：所有被融合的算子跑在同一次 kernel 启动里，由一个统一的 kernel 函数体处理，CPU 侧只发一次指令。线程块重划分：不再沿用单个算子的线程块配置，而是按合并后的总工作量重新计算。数据并行展开：把原本串行启动的独立计算展开到不同 SM（流式多处理器，GPU 的计算核心单元）上并行执行，这正是“提升并行度”的来源——一个算子可能填不满 GPU，k 个拼起来却能占满。访存复用优化：对相同输入只读取一次，把数据留在寄存器或共享内存里供多个算子复用。

一趟车出门，走哪条路、先爬哪栋楼，都是调度策略说了算。GPU 上那套线程块分配，就是快递员手里的派送地图——地图画得好，一车顶三车。

启动开销分析

快递老手的账本上，一趟配送的时间分成两块：出发前的准备时间和路上的派送时间。准备时间再短，它也是固定的——不管你这一趟装一个包裹还是十个。这就是“固定开销”最扎心的地方：它是叠加的。

GPU 编程里，CPU 每次启动一个 kernel，都要经过“准备参数→下发指令→GPU 队列排队→执行”的流程。即使现代框架做了异步提交，每一次启动的 CPU 侧指令开销仍然真实存在，通常在几十微秒量级。可别小看这几十微秒——当一个 element-wise 算子本身只算 10 微秒时，启动开销是计算时间的五倍。

关键在对比。假设融合前 k 个算子各自启动，总时间是 k 份“启动开销 + 计算时间”；水平融合后只启动一次，计算仍然要做（每个元素该算的逃不掉），但启动开销只剩一份。于是省下来的时间是 (k-1) 倍的启动开销。这个模型解释了为什么算子越小、融合收益越夸张。

账算明白了，站长就懂了：拼单拼的不是热闹，是“少付几遍出车费”。启动开销占比越高的活，越值得水平融合——这也是下一节要验证的 GPU 收益。

GPU性能收益

拼单试运行一个月后，站长拉出配送报表：车次少了 60%，每趟车满载率上去了，小区门口排队的电瓶车也少了。GPU 的 performance report 同样会告诉你：启动次数、SM 占用率、访存带宽——每一项都在讲同一个故事。

水平融合的收益在 GPU 上分为三个层次，对应三种资源：时间、计算单元、带宽。一是延迟收益：启动次数从 k 降到 1，CPU 侧下发指令的密集程度大幅下降，GPU 队列的空洞变少，端到端单次推理延迟降低。二是并行度收益：独立算子合并后，总工作量 k×n 可以展开到更多线程块，把原本闲置的 SM 填满；单个小算子常常只用到 GPU 的一小块算力，拼起来才能“满载发车”。三是访存收益：相同输入只读一次，省下的显存带宽在小算子场景下非常可观。

实际数据上，在包含大量 element-wise 算子的 Transformer 推理图中，水平融合通常能带来 10%~30% 的端到端加速；小算子密集的老模型上收益更明显。一个典型场景：某模型每层末尾有 4 个逐元素算子，单独启动每次计算约 8 微秒、启动开销约 50 微秒，融合后单层耗时从 232 微秒降到 82 微秒，接近三倍提速。

GPU 报表上的红箭头一翘，站长的拼单方案才算真正落地。但报表也提醒：不是所有算子都适合拼单——这就要说到最后的调优经验了。

配置调优经验

拼单上瘾后，站长把鸡蛋、沙发、汽油桶都塞进一辆车——结果生鲜坏了、沙发蹭花了、小区还进了消防队。拼单有边界。优秀的站长会建立一套“拼单策略”：先看数据，再定规则，最后小范围试跑。

编译器同样内置了融合的“拼单策略”，用户可以在部署时通过配置项影响它。开源框架（如 TVM、TensorRT、ONNX Runtime）普遍支持融合开关与融合等级。调优经验可以总结为四步。打开融合开关：将编译优化等级调到 O2/O3，或显式开启 fusion 选项。依靠启发式规则：编译器默认做一轮启发式判断——启动开销占比高于阈值、算子规模小、类型匹配的算子对优先触发融合。用性能剖析验证：跑一遍 profiler（如 nsys、nvprof），看 kernel 耗时分布和启动次数，定位哪些小 kernel 值得融合。权衡副作用：留意融合后的寄存器压力与占用率变化，融合过度可能触发寄存器溢出（register spill，寄存器不够用被迫把数据存回显存），反而拖慢执行。实践中“小算子优先、大算子谨慎”是普遍心法。

站长的拼单策略最终变成墙上的一张流程图：看数据 → 定规则 → 试跑 → 复盘。水平融合的调优没有银弹，只有“剖析驱动”这一条踏实路——它把玄学变成了工程。

AI 应用场景

Python 演示

"""水平融合性能模拟：对比分离启动与融合启动的耗时"""  class FusionSimulator:    def __init__(self, launch_us=50, compute_us=30, parallel_gain=2.0):        self.launch_us = launch_us          # 单次 kernel 启动开销（微秒）        self.compute_us = compute_us        # 单个算子计算耗时（微秒）        self.parallel_gain = parallel_gain  # 融合后并行度提升系数     def run_separate(self, op_count):        """融合前：k 个算子分别启动，每个都要付一份启动开销"""        return op_count * (self.launch_us + self.compute_us)     def run_fused(self, op_count):        """水平融合：只启动一次，计算量因并行展开而摊薄"""        return self.launch_us + self.compute_us * op_count / self.parallel_gain     def report(self, op_count):        t0 = self.run_separate(op_count)        t1 = self.run_fused(op_count)        print(f"算子数={op_count:2d} 分离={t0:6.1f}us 融合={t1:6.1f}us 加速比={t0 / t1:.2f}x")  def main():    sim = FusionSimulator(launch_us=50, compute_us=30)    for n in (2, 4, 8, 16):        sim.report(n)  if __name__ == "__main__":    main()

1. self.launch_us = launch_us记录单次 kernel 启动的固定开销，相当于快递员每次出车的准备时间。
2. def run_separate(self, op_count)模拟融合前：k 个算子各自启动，每次都支付一份启动开销。
3. return op_count * (self.launch_us + self.compute_us)对应公式 T= k(L+E)，k 次启动叠加。
4. def run_fused(self, op_count)模拟水平融合：所有算子合并成一个 kernel，只启动一次。
5. self.parallel_gain代表独立算子展开到更多 SM 带来的并行收益，是简化模型的核心假设。
6. print(f"...")输出各算子数下的对比，加速比随 k 增大而上升。
7. if __name__ == "__main__":可执行入口，保证模块既可导入也可直接运行。

常见误区

面试题