Kernel Fusion（算子融合）

3 秒看懂

一句话定义： Kernel Fusion（算子融合）是把 GPU/AI 加速器上原本需要多次独立执行的计算”小任务”（kernel）合并为一次执行的编译优化技术，核心目的是减少对 HBM（高带宽显存）的反复读写和消除逐次内核启动（kernel launch）的开销。

类比： 如果把每次 kernel launch 比作去厨房烧一道菜，那 kernel fusion 就是把需要相同食材的五道菜一次做好端出来——省去了反复进出厨房的跑腿时间，也避免了反复开关冰箱门（HBM 访问）的浪费。

为什么此刻重要： 当 LLM 推理/训练的瓶颈从”算力不够”转向”显存带宽不够”（memory-bandwidth bound），Kernel Fusion 成为让每一块 GPU 发挥出更接近理论算力的关键编译层技术，也是 FlashAttention、TorchInductor、Triton 等当前热门工具的核心优化原理之一。

3 分钟产业解释

问题的本质：GPU “空转”与”搬运浪费”

现代 AI 加速器（GPU、TPU 等）的计算能力（FLOPS）增长速度远快于显存带宽（HBM GB/s）的增长速度。以 NVIDIA 产品线为例，HBM 带宽与峰值算力的比值（bytes/FLOP，即每做一次浮点运算能搬运多少字节数据）在过去几代中持续恶化，这意味着芯片越来越容易”算完了等数据”。

在典型的深度学习推理中，一个 Transformer 层包含数十个子操作（element-wise add、LayerNorm、MatMul、softmax、残差连接等）。如果每个操作都独立作为一个 kernel：

1. 每次 kernel launch 存在启动开销（GPU 命令队列提交、参数设定、block/grid 配置等），在轻量推理或小 batch 场景下，这个开销可能占总延迟的显著比例；
2. 每次 kernel 结束时，中间结果必须写回 HBM，下一次 kernel 再从 HBM 读回来——而这些数据可能只需要用一次就丢弃了；
3. 大量 HBM 带宽被”搬运中间结果”消耗，芯片实际执行的有用计算量远低于峰值。

Kernel Fusion 就是解决这个问题的最直接手段：把多个 kernel 合并为一个，让中间数据留在片上（寄存器、shared memory / scratchpad、L1/L2 cache），只读写一次输入、只写出一次最终结果。

对产业的影响链

15 分钟专家深入

从 Roofline 模型理解 Fusion 的价值

Roofline 模型是分析 kernel 性能的基本框架：

Achievable Performance = min(Peak FLOPS, Peak BW × Arithmetic Intensity)

• Arithmetic Intensity（算术强度）= FLOPs / Bytes（每搬运一个字节能做多少次运算）
• 如果 kernel 的算术强度低于”屋顶拐点”（ridge point），它就是memory-bound——显存带宽是瓶颈，再多算力也用不满。

大量深度学习子操作（逐元素加法、激活函数、归一化等）算术强度极低（远低于 1 FLOP/Byte），属于典型的 memory-bound kernel。Fusion 通过减少读写次数提升了融合后 kernel 的有效算术强度，使其更靠近 compute-bound 区域。

Fusion 的三种基本模式

┌─────────────────────────────────────────────────────┐
│  类型 1：Vertical Fusion（纵向融合 / 生产者-消费者融合） │
│                                                       │
│  Kernel A → 写 HBM → Kernel B → 写 HBM → Kernel C     │
│         ↓ 合并为 ↓                                     │
│  Kernel ABC（中间结果留在片上寄存器/shared memory）       │
│                                                       │
│  典型场景：Add + LayerNorm + Dropout 融合               │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│  类型 2：Horizontal Fusion（横向融合 / 并行融合）       │
│                                                       │
│  Kernel A（处理数据块X）  Kernel B（处理数据块Y）        │
│         ↓ 合并为 ↓                                     │
│  Kernel AB（一次 launch 同时处理 X 和 Y）               │
│                                                       │
│  典型场景：同一层的多个 head 或多个 channel 并行计算     │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│  类型 3：Input Fusion / Reduction Fusion              │
│                                                       │
│  多个 kernel 读同一份输入，合并为一个 kernel 一次读入    │
│  或多个 kernel 各自 reduce → 合并为一次 reduce          │
│                                                       │
│  典型场景：多路 loss 计算共享底层 feature               │
└─────────────────────────────────────────────────────┘

FlashAttention：Kernel Fusion 的标志性案例

FlashAttention（Tri Dao, 2022）本质上是对 Transformer Attention 的极致纵向融合：

标准 Attention 实现：

S = Q × K^T    ← 写入 HBM（N×N 矩阵，N 为序列长度）
P = softmax(S) ← 从 HBM 读 S，写入 HBM
O = P × V      ← 从 HBM 读 P 和 V

三步操作，中间矩阵 S 和 P 都必须落地到 HBM，O(N²) 的显存占用。

FlashAttention 的融合策略：

┌─────────────────────────────────────────────┐
│  将 Q、K、V 按块（tile）切分                  │
│  在一个 kernel 内完成：                       │
│    1. 逐块计算 S_block = Q_block × K_block^T │
│    2. 在片上对 S_block 做 softmax（用 online  │
│       softmax 算法维护 running max/sum）      │
│    3. 立即乘以 V_block 累加到输出 O           │
│    4. S_block 和 P_block 不写回 HBM          │
│  → 整个 attention 一个 kernel 完成            │
│  → 显存 O(N²) → O(N)                         │
└─────────────────────────────────────────────┘

FlashAttention 的核心创新不仅仅是 fusion 本身，还有**在线 softmax（online softmax / safe softmax with running statistics）**算法，使得 softmax 可以分块计算而不需要先看到完整的 N×N 矩阵。

这是为什么 FlashAttention 被视为”改变游戏规则”——它同时解决了带宽问题和显存问题。

编译器视角：Fusion 是如何自动完成的？

在工业级 ML 编译器中，Fusion 通常分为以下阶段：

前端模型 (PyTorch / TF / ONNX)
        │
        ▼
  Graph IR 层（计算图）
   → 算子级 Fusion 模式匹配
   → 常见模式库：Conv+BN+ReLU、Linear+Bias+GELU 等
        │
        ▼
  Tensor IR / Lower IR 层
   → 更细粒度的循环级 Fusion
   → Tiling（分块）+ 内存层次分析
   → 确定数据留在哪个层级（寄存器 / shared / L2 / HBM）
        │
        ▼
  Hardware codegen（PTX / ROCm / 自定义 ISA）

关键编译器/工具栈：

Fusion 的工程挑战

并非越融合越好：

1. 寄存器压力（register pressure）：融合过多计算会导致单个 kernel 使用过多寄存器，反而减少可并行运行的 warp 数量（occupancy 下降），可能降低 GPU 利用率。
2. Shared memory 容量限制：片上 scratchpad 有限（NVIDIA A100 的 shared memory 为每 SM 最多 164 KB [配置依具体架构而定]），如果融合后的 kernel 需要的中间数据超过此容量，就必须部分溢出到 L2 或 HBM。
3. 编译搜索空间爆炸：自动 fusion 的最优方案是 NP-hard 级别的搜索问题，工业编译器通常用启发式规则 + auto-tuning 解决。
4. 调试困难：融合后的 kernel 难以分步排查错误。
5. 跨算子边界优化：融合改变了执行顺序，在有数值敏感操作（如 fused multiply-add 精度差异）时可能影响最终结果。

技术原理

一个具体的 Fusion 示例：LayerNorm 融合

标准 PyTorch 实现中，Transformer 层的一个典型操作序列：

# 未融合的 4 个 kernel
residual = x + shortcut          # Kernel 1: Elementwise Add
normed   = LayerNorm(residual)   # Kernel 2: Reduce (mean) → Subtract → 
                                  #           Reduce (variance) → Normalize → Scale + Shift
out      = Linear(normed)         # Kernel 3: MatMul
out      = out + bias             # Kernel 4: Elementwise Add

融合后的逻辑（伪代码）：

fused_residual_layernorm_linear_bias_kernel(x, shortcut, W, b, gamma, beta):
    // 所有操作在一个 kernel 内
    // 使用 shared memory 保存 reduction 中间结果
    
    for each token in parallel:           // 线程并行
        r = x[token] + shortcut[token]    // 残差加法（片上寄存器）
        
        // 在线计算 mean（Welford 算法或两次 pass）
        mean = reduce_mean(r)
        var  = reduce_variance(r, mean)
        normed = (r - mean) * rsqrt(var + eps) * gamma + beta  // LayerNorm
        
        out = matmul(normed, W) + b       // 线性层
        write_out(token, out)             // 只写最终结果到 HBM

读写对比：

融合决策的关键参数

┌─────────────────────────────────────────────┐
│         Fusion Decision Factors             │
├─────────────────────────────────────────────┤
│                                             │
│  1. 数据重用程度（reusability）              │
│     → 中间结果被消费几次？                   │
│     → 1 次 → 强 fusion 候选                 │
│     → 多次 → 可能需要缓存策略               │
│                                             │
│  2. 中间数据量 vs 片上容量                   │
│     → 乘积累加的中间张量是否超过              │
│       shared memory / register 容量？       │
│     → 超过则需 tiling 或放弃 fusion         │
│                                             │
│  3. Kernel launch 开销占比                   │
│     → 单个 kernel 计算量越小，               │
│       launch 开销占比越高 → 越值得融合       │
│     → 大 MatMul 本身计算量足够，             │
│       launch 开销可忽略 → 融合收益小         │
│                                             │
│  4. 并行度影响（occupancy）                  │
│     → 融合后寄存器使用是否导致               │
│       活跃 warp 数下降？                     │
│     → 需要 profile 验证                     │
│                                             │
│  5. 数值精度约束                             │
│     → 融合改变了 reduce 和 elementwise      │
│       的执行顺序，可能影响浮点结果           │
│                                             │
└─────────────────────────────────────────────┘

Kernel Launch 开销量化

NVIDIA GPU 上单次 CUDA kernel launch 的延迟通常在 5~15 微秒量级（具体取决于驱动版本、GPU 架构、是否使用 CUDA Graph 等）。在 LLM 生成式推理中，每个 token 的生成可能涉及数十甚至上百个 kernel。如果每个 token 的计算仅需数十微秒（小 batch、小模型），则 launch 开销本身可能占到总延迟的 **10%~30%**以上。

这就是为什么 CUDA Graph（预先录制 kernel launch 序列，一次性回放）和 kernel fusion 在推理场景中尤为重要——它们从不同维度减少 launch 开销。

技术演进史

技术路线对比

加速比为行业经验性量级，具体数值取决于模型架构、batch size、硬件等因素。

上下游

上游：Kernel Fusion 需要什么

下游：Kernel Fusion 影响什么

关键指标

供需与市场数据

需求侧驱动

• LLM 推理爆发：生成式推理的逐 token 解码是 memory-bound 场景，每层数十个小 kernel 导致带宽利用效率低 → 对 fusion 的需求空前强烈。
• 小模型 + 端侧部署：参数量小但推理频率极高，launch 开销占比大 → fusion 收益大。
• 长上下文推理：序列长度增长使 attention 的 memory 压力倍增 → FlashAttention 类融合成为刚需。

供给侧格局

• NVIDIA：拥有最成熟的融合生态（cuDNN fused kernels、TensorRT fusion pass、Triton 生态支持）。
• AMD：ROCm 生态追赶中；Triton 已支持 AMD GPU 后端，但 cuDNN 级别的手写 fused kernel 库仍落后。
• Google：XLA/MLIR 基础设施，TPU 上自动 fusion 能力成熟。
• AI 编译器创业公司：包括 Modular（Mojo/MAX）、Centml、各种基于 MLIR 的优化层——fusion 是其核心技术卖点。
• 推理框架：vLLM、TensorRT-LLM、SGLang 等在推理引擎层面对关键路径做手动/半自动融合优化。

市场角度

Kernel Fusion 本身不是一个可直接量化的市场规模，但它是影响每 FLOP 有效利用率的关键技术。当全球 GPU 支出每年数百亿美元时，即使 fusion 只带来 20%~30% 的端到端效率提升，等效节省的算力采购成本在行业层面可达数十亿美元量级[推算]。

代表公司与资本映射

标注 “私有” 表示截至知识截止日该公司尚未上市或未有公开可交易标的。投资映射仅作信息参考，不构成建议。

投资逻辑

看多逻辑

1. Memory-bound 趋势不可逆：GPU 算力增长快于 HBM 带宽 → 每一代新硬件都需要更激进的 fusion → 软件栈价值持续提升。
2. LLM 推理成本敏感：推理占 AI 计算的比重持续上升 → fusion 直接降低推理成本 → 谁的 fusion 好谁的推理便宜。
3. 编译器成为新战场：硬件差异化缩小时，软件/编译器成为竞争壁垒 → 拥有强 fusion 能力的编译器栈有护城河效应。
4. NVIDIA 生态优势放大：Triton + cuDNN + TensorRT 构成了三层 fusion 防线 → 竞争对手追赶困难。

风险/需关注点

1. Fusion 可能被”固化”进硬件：如果硬件架构演进使得更多操作在硬件层面自动融合（如 NVIDIA 的 FP8 Tensor Core 融合乘加），则纯软件 fusion 的边际价值可能下降。
2. 开源标准化：Triton 等开源工具降低了 fusion 的”技术壁垒” → 竞争差异化缩小。
3. 架构变换：如果 MoE、SSM/Mamba 等非 Transformer 架构兴起，现有的 Transformer 专用 fusion pattern 可能需要重写。

常见误读纠偏

❌ 误读 1：“Kernel Fusion 就是把所有算子合并成一个大 kernel”

纠偏： 融合是有选择的。过多融合会导致寄存器溢出（register spilling）、occupancy 下降、编译时间增长。工业级编译器使用 cost model 来决定哪些算子值得融合、哪些保持独立。融合不是”越多越好”，而是”恰到好处”。实际部署中，一个典型 Transformer 模型的推理图上仍会有数十个独立 kernel，并非所有都被融合。

❌ 误读 2：“Kernel Fusion 主要节省的是计算时间”

纠偏： Fusion 最主要的收益来自减少 HBM 访问次数和 kernel launch 开销，而非减少计算量。融合不改变总 FLOPs（计算量基本不变），但大幅减少了数据搬运量。在 memory-bound 的小算子场景中，计算时间可能只占总执行时间的很小比例，真正的瓶颈是数据搬运。因此 fusion 节省的主要是等数据的时间和启动调度的时间。

❌ 误读 3：“FlashAttention 是一个模型架构创新”

纠偏： FlashAttention 不是一个新的注意力算法，而是一个注意力计算的 kernel fusion 实现。它不改变注意力的数学结果（在数值精度范围内），而是改变了计算的执行顺序和内存访问模式，使得注意力可以在