Operator Fusion（算子融合）

3 秒看懂

一句话：把多个相邻的计算步骤”合并”成一个内核执行，少跑几趟内存搬运，速度就快了。

类比：原本你洗完衣服→晾干→折叠分三趟搬运，现在在洗衣机旁直接折叠打包，省了两趟上下楼。

3 分钟产业解释

为什么它重要

深度学习模型的计算图由成百上千个算子（Conv、BN、ReLU、Add……）串联/并联组成。每个算子执行完毕，都要把结果写回显存/内存，下一个算子再读出来——这叫内核启动开销（kernel launch overhead）和内存带宽瓶颈（memory bandwidth bottleneck）。

算子融合（Operator Fusion / Kernel Fusion）的核心思想：如果几个相邻算子之间没有复杂的依赖冲突，就把它们编译成一个 GPU kernel / CPU 函数来执行，中间结果留在寄存器或片上缓存里，不落回全局内存。

产业价值定位

核心约束：融合不是无脑合并——需要保证语义等价、内存访问模式兼容、不超出寄存器/共享内存容量限制。

15 分钟专家深入

算子融合的本质收益拆解

一次算子执行的成本可建模为：

T_total = T_compute + T_memory + T_launch

关键洞察：对于计算密度低的算子（如逐元素操作 Elementwise、激活函数），T_memory 和 T_launch 往往占主导——这正是融合收益最大的场景。

融合的主要类型

1. 生产者-消费者融合（垂直融合 / Vertical Fusion）

将串行链路上的算子合并：

原始：  Conv → BatchNorm → ReLU → (写回显存) → 下一层
融合：  Conv_BN_ReLU → (写回显存)

这是最经典、收益最明确的融合模式。Conv 的输出直接在寄存器中做 BN 归一化和 ReLU 截断，无需落盘。

2. 兄弟节点融合（水平融合 / Horizontal Fusion）

将并行的、互不依赖的算子合并为一个 kernel：

原始：  [Branch_A: Conv1] || [Branch_B: Conv2]  → 各自写回
融合：  Fused_Conv1_Conv2  → 一次写回

适用于多头注意力的多个 head 并行计算等场景。

3. 缩减-广播融合（Reduction-Broadcast Fusion）

将归约操作（如 Softmax 中的 Sum、LayerNorm 的均值/方差计算）与后续广播/逐元素操作融合：

原始：  x → Reduce_Sum → (写回) → Broadcast_Div → (写回)
融合：  x → Fused_Softmax（reduce + broadcast 在一个 kernel 内）

Softmax 的 fused 实现是算子融合的经典教学案例。

融合的约束与代价

可融合性判断伪逻辑：

IF (无数据依赖冲突)
  AND (中间 tensor 不被图中其他节点复用，或复用点可接受延迟写回)
  AND (融合后寄存器/共享内存需求 ≤ 硬件上限)
  AND (融合后不会严重降低并行度)
THEN → 可融合
ELSE → 不可融合 / 需权衡

技术原理

内存层次视角

┌─────────────────────────────────────────────────────────┐
│                     Global Memory (HBM / DRAM)          │
│                     带宽高延迟高，~TB/s 级别               │
├─────────────────────────────────────────────────────────┤
│                     L2 Cache (GPU 片上)                  │
│               容量较大，~数 MB 至数十 MB (GPU)              │
├─────────────────────────────────────────────────────────┤
│              Shared Memory (SMEM) (每 SM 内)              │
│           容量有限，~数十 KB 至上百 KB/SM                    │
├─────────────────────────────────────────────────────────┤
│                   Register File (每线程)                  │
│                   极快但极小，~256 KB/SM 总量               │
└─────────────────────────────────────────────────────────┘

未融合时的数据流：
Kernel_A: Reg → SMEM → Global → [读出] → SMEM → Reg → 计算 → 输出Global
Kernel_B: Global → SMEM → Reg → 计算 → 输出Global
                    ↑                        ↑
                 中间tensor落盘           再次读入

融合后的数据流：
Fused_Kernel: Reg → 计算A → 结果仍在Reg → 计算B → 一次输出Global
                    ↑
              中间结果从未离开寄存器

典型融合模式的技术实现

Conv + BN + ReLU 融合（推理时）

推理阶段，BN 可折叠为线性变换：y = γ * (x - μ) / σ + β

与 Conv 的权重合并后，融合为：

# 数学等价变换
W_fused = W_conv * (γ / σ)
b_fused = (b_conv - μ) * (γ / σ) + β

# 融合后的 kernel 内部
output = ReLU(conv(input, W_fused) + b_fused)  # 全在一个 kernel 中

注意：这在推理时成立（BN 统计量固定），训练时 BN 需要维护 running_mean/running_var，融合方式不同。

FlashAttention 中的融合

FlashAttention 的核心创新之一是将 QKV 的点乘、Softmax、与 V 的加权求和融合在一个 kernel 内，利用 tiling（分块）技术在 SRAM 中完成全部计算，避免将巨大的注意力矩阵 (N×N) 写入 HBM。

传统 Attention：
Q×K^T → 写HBM(N×N) → Softmax → 写HBM(N×N) → ×V → 输出

FlashAttention：
分块(tile)在SRAM内完成：Q_tile×K_tile → online softmax → ×V_tile → 逐块写回
                                            ↑
                                     中间N×N矩阵从未存在于HBM

这是一种算法-编译协同设计的融合，超越了编译器层面的简单算子合并。

编译器中的融合 Pass 实现框架

计算图 → [算子融合Pass] → 优化后计算图 → 代码生成

融合Pass的典型流程：
1. 拓扑排序，识别可融合的算子簇（patterns）
2. 评估融合收益（cost model：内存节省 vs 寄存器压力）
3. 决策融合（贪心 / 基于规则 / 搜索 / ML预测）
4. 图重写（Graph Rewrite）：用融合后的新节点替换原簇

技术演进史

技术路线对比

上下游

上游（输入侧）

下游（输出侧）

关键指标

供需与市场数据

需求侧

• 大模型推理成本压力：万亿参数模型推理的算力/带宽成本构成部署核心瓶颈，编译优化（含融合）是低成本提升吞吐的关键手段
• 边缘部署：手机/车载 NPU 算力和内存受限，融合几乎是强制要求
• GPU 算力供给紧张：H100/A100 供不应求期间，推理优化的 ROI 极高

供给侧

市场规模估算

算子融合本身不单独构成市场，而是编译器/推理优化栈的一部分。推理优化工具和服务市场规模通常嵌入在 AI 编译器和 MLOps 市场中讨论——整体 AI 编译器/优化市场处于快速增长期，但精确拆分融合贡献的数字暂无公开数据，标注为 [未充分披露]。

代表公司与资本映射

投资逻辑映射：算子融合能力是 AI 芯片/推理引擎的”隐性护城河”——芯片卖得好不好，三分靠硬件、七分靠编译器。

投资逻辑

核心观点

1. AI 编译器是基础设施级价值：算子融合是编译器优化的核心子问题，掌握编译器栈的公司在推理效率上具备可持续的竞争力优势
2. 硬件差异化越来越依赖软件：GPU 算力趋同背景下，编译器优化（含融合策略的硬件适配）成为差异化关键
3. 推理市场增速 > 训练市场：推理阶段对延迟和成本更敏感，融合优化 ROI 更高

风险与不确定性

常见误读纠偏

❌ 误读 1：「算子融合就是把所有算子都合并成一个大 kernel」

纠偏：融合是有约束的优化决策，不是越多越好。过度融合会导致：

• 寄存器溢出（register spilling），性能反而下降
• 编译时间和二进制体积爆炸
• 并行度降低

好的编译器会做 cost model 驱动的融合决策，有时”不融合”才是最优选择。

❌ 误读 2：「编译器的算子融合可以替代算法层面的优化（如 FlashAttention）」

纠偏：编译器级融合和算法级融合是不同层次的优化：

• 编译器融合：在不改变数学等价性的前提下，合并已有算子的实现
• 算法融合（如 FlashAttention）：重新设计计算顺序和分块策略，改变中间结果的生命周期，本质上是新算法，不是编译器能自动发现的

FlashAttention 需要手写 CUDA/Triton kernel，而非单纯依赖编译器的融合 pass。

❌ 误读 3：「算子融合只对 GPU 有意义」

纠偏：CPU（减少 cache miss）、NPU/TPU（减少片外带宽）、甚至 FPGA 统统受益。只是 GPU 因其内存层次分明、kernel launch 开销显著，融合效果最直观。

学习路径

入门（2–4 小时）

1. 阅读 TVM 官方文档中关于 Operator Fusion 的章节（有清晰的图解和代码示例）
2. 理解为什么 Conv → BN → ReLU 融合在推理时成立

进阶（1–2 天）

3. 阅读论文 “TVM: An Automated End-to-End Optimizing Compiler”（OSDI 2018）中融合策略部分
4. 阅读 FlashAttention 论文，理解算法级融合与编译器融合的区别
5. 在 PyTorch 中使用 torch.compile()，对比有无融合的推理速度差异

深度（持续）

6. 学习 MLIR Dialect 体系中的 Linalg on Tensors 融合框架
7. 研读 Ansor（TVM 自动调度论文），理解融合搜索空间建模
8. 实践：在 TVM 中定义自定义融合规则，观察对特定模型的性能影响

推荐资源

一句话总结

算子融合是深度学习编译器的核心优化手段——通过将相邻算子合并执行、消除中间结果的冗余内存搬运，以极低的实现成本换取显著的推理性能提升；其技术难点在于在寄存器压力、并行度和编译时间之间取得平衡，且无法替代 FlashAttention 等算法层面的融合创新。

延伸阅读与来源

声明：本文技术事实基于公开论文、官方文档和社区共识。具体性能数字因模型、硬件、框架版本差异较大，文中量化数据标注为 [行业估算] 或 [定性描述]，不作绝对精确承诺。