算子融合初探：什么是算子融合？为什么它能解决带宽瓶颈？
大家好，欢迎来到第三章。
前两章我们聊了内存带宽这个“拦路虎”。你可能会问：“既然带宽是瓶颈，那我们能不能少读几次数据？”
问得好。这恰恰就是算子融合的核心思想。
什么是算子融合？
说白了，算子融合就是把多个连续的计算步骤合并成一个。
举个例子。假设你要做两件事：
- 把数组 A 每个元素加 1，得到 B
- 把 B 每个元素乘以 2，得到 C
传统做法是两步走：
// 步骤1：A → B
for i in range(N):
B[i] = A[i] + 1
// 步骤2：B → C
for i in range(N):
C[i] = B[i] * 2融合之后：
// 一步到位：A → C
for i in range(N):
C[i] = (A[i] + 1) * 2你看，中间结果 B 根本不需要写回显存。这就是融合的魔力。
核心要点：算子融合的本质是减少中间结果的读写次数。每次少读少写，就是在节省带宽。
为什么它能解决带宽瓶颈？
我刚开始做 GPU 优化时，犯过一个低级错误。当时写了一个三层卷积的流水线，每层之间都保存了中间特征图。结果显存带宽被中间结果读写占掉了 70%。
后来我把这三层卷积融合成一个 kernel，中间结果直接留在寄存器里。性能提升了 3 倍。
为什么会这样？我们来算一笔账：
| 方案 | 读数据量 | 写数据量 | 总带宽消耗 |
|---|---|---|---|
| 未融合（3层独立） | 3 × N | 3 × N | 6N |
| 融合后（1个 kernel） | 1 × N | 1 × N | 2N |
带宽消耗直接降到原来的 1/3。你想想看，这还只是三层融合。如果是 ResNet 那种几十层的网络，融合带来的收益更夸张。
融合的几种常见模式
根据我的经验，实际项目中常见的融合模式有这几种：
- 逐元素融合：比如 ReLU + BatchNorm，每个元素独立计算，天然适合融合
- 降维融合：比如 Conv + Pooling，把卷积和池化合并，减少中间特征图
- 横向融合：比如多个分支的 concat 操作，把多个小 kernel 合并成一个大 kernel
我的建议：刚开始做融合时，先从逐元素融合入手。它逻辑简单，不容易出错。我当年第一个融合优化就是 ReLU + 加法，改完直接提速 40%。
融合的代价
嗯，这里要注意。融合不是万能的。
我曾经在一个项目里，把 5 个算子强行融合成一个。结果呢？寄存器压力太大，每个线程需要保存的中间变量太多，反而导致 occupancy 下降，性能不升反降。
避坑指南：我曾经把 7 个算子融合在一起，结果寄存器溢出，性能比未融合还差 20%。后来我拆成 3+4 两组融合，才拿到最佳效果。记住：融合不是越多越好，要适可而止。
所以，融合的决策需要权衡：
- 融合带来的带宽节省 vs 寄存器压力增加
- kernel 启动开销减少 vs 单个 kernel 复杂度上升
- 代码可维护性 vs 极致性能
一张图看懂算子融合
下面这张图展示了融合前后的数据流对比。左边是未融合的 3 个独立算子，右边是融合后的 1 个算子。注意看中间结果的读写次数变化。
从这张图可以清楚看到：未融合时，每个算子都要读写一次显存。融合后，数据从显存读一次，在寄存器里完成所有计算，最后写回一次。带宽消耗大幅降低。
什么时候该用融合？
根据我的实战经验，以下场景特别适合融合：
- 计算密集且数据复用率高：比如卷积 + 激活函数，卷积结果马上被激活函数用
- 中间结果体积大：比如高分辨率特征图，写一次中间结果可能消耗几 MB 带宽
- 算子之间无数据依赖冲突：比如逐元素操作，天然可以合并
反过来，如果算子之间数据依赖复杂，或者每个算子本身计算量极小，融合的收益就不明显。
一个小技巧：我习惯先用 profiler 跑一遍，看看哪些 kernel 的读写比（Bytes / FLOPs）最高。读写比高的，就是融合的优先候选。
小结
算子融合不是什么高深莫测的技术。它的核心逻辑很简单：减少中间结果的读写，把数据留在离计算单元最近的地方。
你想想看，GPU 的显存带宽就那么点，每少一次读写，就是实打实的性能提升。我见过太多项目，花大量精力优化计算逻辑，却忽略了带宽这个真正的瓶颈。结果呢？计算快了，但数据搬不动，白忙活。
下一章，我们会深入具体的融合实现技巧。到时候我会拿一个真实的 CUDA 案例，手把手带你做融合优化。
想要更多资料，联系可可