算子融合的收益量化：显存带宽瓶颈下的 Kernel 拼接实测

在现代 GPU（如 NVIDIA A100 / H100）上运行深度学习推理时，硬件计算单元的峰值浮点算力（FLOPs）正在以每两年翻倍的惊人速度膨胀，而高带宽显存（HBM）的物理带宽增长却相对缓慢。

这种算力与带宽增速的巨大失衡，导致大模型推理网络中绝大多数非 GEMM 算子（如 LayerNorm、GELU、Residual Add、Softmax）的执行时间，完全被**显存访存延迟（Memory Bandwidth Wall）**所统治。

将多个离散的算子融合成单个复合 Kernel，究竟能带来多少实际收益？收益的极限在哪里？

通过在真实生产环境下对未融合与融合 Kernel 进行底层 Profiling 与定量测量，才能看清性能爆发背后的物理账本。

+--------------------------------------------------------------------------+
|                     未融合 vs 融合 Kernel 物理显存带宽消耗对比               |
+--------------------------------------------------------------------------+
| [优化前: 3 个离散 Kernel 串行执行]                                         |
| 1. Kernel A (BiasAdd)  ---> 从 HBM 读取 8MB ---> 写回 HBM 8MB (总流量 16MB) |
| 2. Kernel B (GELU)     ---> 从 HBM 读取 8MB ---> 写回 HBM 8MB (总流量 16MB) |
| 3. Kernel C (Residual) ---> 从 HBM 读取 8MB ---> 写回 HBM 8MB (总流量 16MB) |
| -> 🚨 总全局显存流量: 48 MB, 经历 3 次 Kernel Launch 调度开销              |
+--------------------------------------------------------------------------+
                                    | 算子融合 (Kernel Fusion)
                                    v
| [优化后: 1 个复合融合 Kernel]                                              |
| 1. Fused_Kernel        ---> 从 HBM 读取 8MB (仅一次!)                     |
|                             | 在片上寄存器/SRAM 内部连续执行 Add + GELU + Res  |
|                        ---> 写回 HBM 8MB (仅一次!)                        |
| -> 🚀 总全局显存流量: 16 MB (显存搬运暴降 66.7%), 仅 1 次 Kernel Launch      |
+--------------------------------------------------------------------------+

1. 物理流量量化：减少 66.7% 的全局显存吞吐

设张量尺寸为 $[B, S, H] = [1, 2048, 4096]$，采用 FP16 存储，单张量体积为：

$$\text{Size} = 1 \times 2048 \times 4096 \times 2\text{ Bytes} = 16\text{ MB}$$

在执行经典的 ResidualAdd + LayerNorm 子图时：

• 未融合状态：
  1. Residual Add：读取输入 X（16MB）、读取残差 R（16MB），写回中间激活值 A（16MB） $\rightarrow$ 流量 48MB；
  2. LayerNorm：读取中间激活值 A（16MB），计算均值方差，写回输出 Y（16MB） $\rightarrow$ 流量 32MB；
  3. 总显存吞吐量 = 80 MB。
• 融合状态（Fused Add + LayerNorm）：
  1. 融合 Kernel 一次性将 X 和 R 读入 GPU 寄存器，就地完成残差相加与层归一化规约；
  2. 仅向全局显存写出最终的 Y（16MB）；
  3. 总显存吞吐量 = 48 MB（显存流量直接减少 40%）。

在 HBM 显存带宽打满的前提下，Kernel 的物理执行耗时与总访存流量呈严格的正比例关系。仅消除中间张量的搬运，就能让该模块的执行耗时直接缩短近一半！

2. Kernel Launch 开销的物理消除

除了显存带宽，另一个在高并发短序列场景下不容忽视的开销是 Kernel 发射延迟（Launch Overhead）。

在 CUDA/GPU 驱动模型中，Host 端 CPU 通过 CUDA Driver 向 GPU 提交一个 Kernel 任务，硬件指令流水线解析并启动 Thread Block 需要消耗 3 ~ 8 微秒 的时间。

如果一个 Transformer Block 包含 25 个微小算子，每个算子运行 2 微秒：

• 算子实际计算时间：$25 \times 2\mu s = 50\mu s$；
• Kernel Launch 累计开销：$25 \times 5\mu s = 125\mu s$！
• CPU 发射延迟居然是 GPU 实际计算耗时的 2.5 倍！

通过编译期将这 25 个小算子融合成 4 个大 Kernel，Launch 消耗瞬间从 $125\mu s$ 骤降至 $20\mu s$，彻底消除了 Host-Device 通信的气泡。

3. 实测数据对比与 Roofline 验证

我们在 NVIDIA A100-SXM4-80GB（峰值带宽 2.0 TB/s）上使用 Nsight Compute 进行实际 Profile 抓取：

实测 Benchmark 数据

数据清晰地揭示了算子融合的威力：通过将多个算子拼接在一个 Kernel 内部，将中间状态牢牢锁死在片上寄存器与 Shared Memory 中，我们不仅消灭了巨额的内存带宽损耗，更让硬件算力利用率真正逼近了理论极限。