1、算子融合初探：什么是算子融合？为什么需要算子融合？算子融合如何提升推理效率？

1.1 从一个让我头疼的推理任务说起

我记得刚入行做模型部署那会儿，接手了一个BERT的推理优化项目。模型在GPU上跑得挺快，但换到手机端，延迟直接飙到让人崩溃。我盯着Profiling结果看了半天，发现一个现象：大量时间花在了读写中间结果上，而不是真正的计算上。

举个例子，一个简单的Conv + BatchNorm + ReLU组合，在框架里被拆成了三个独立的算子。每个算子都要把结果写回显存，下一个算子再读出来。你想想看，这中间有多少次无谓的访存？

说白了，这就是算子融合要解决的问题。

1.2 什么是算子融合？

算子融合，就是把多个连续的、有依赖关系的算子，合并成一个更大的算子。合并之后，中间结果不再需要落盘，直接在寄存器或L1 cache里传递。

我习惯用一个比喻来解释：
传统方式就像你去超市买三样东西，每买一样就回家放好，再出门买下一样。
融合之后，你一次性买齐三样，直接拎回家。

从数学角度看，融合的本质是函数复合。假设我们有三个算子：

y = f(x)   # Conv
z = g(y)   # BatchNorm
w = h(z)   # ReLU

融合后变成：

w = h(g(f(x)))   # 一个融合算子

嗯，这里要注意：不是所有算子都能随便融合。融合的前提是算子之间没有数据依赖冲突，且计算语义等价。

1.3 为什么需要算子融合？

我在项目中遇到过最典型的场景：一个ResNet-50，在TensorRT里开启融合后，推理速度提升了2.3倍。为什么效果这么明显？

核心原因有三个：

• 减少访存开销：这是最大的收益。GPU的计算速度远快于显存带宽，每次读写中间结果都是在浪费算力。
• 减少kernel launch开销：每个算子对应一个CUDA kernel。启动kernel有固定开销，融合后kernel数量减少，这部分开销自然降低。
• 提升计算密度：融合后的算子往往有更高的算术强度（ops/byte），更容易打满计算单元。

1.4 算子融合如何提升推理效率？

我们来拆解一下具体过程。以Conv + BatchNorm + ReLU为例：

融合前：

1. Conv计算 → 写回显存（假设大小4MB）
2. BN读取4MB → 计算 → 写回4MB
3. ReLU读取4MB → 计算 → 写回4MB

总访存量：4MB × 3次读 + 4MB × 3次写 = 24MB

融合后：

1. Conv计算 → 结果直接传给BN（在寄存器中）
2. BN计算 → 结果直接传给ReLU
3. ReLU计算 → 写回最终结果4MB

总访存量：4MB × 1次写 = 4MB

你看，访存量直接降到了原来的六分之一。这就是效率提升的核心来源。

1.5 常见的融合模式

根据我的经验，下面这些融合模式在实际工程中最常用：

融合模式	典型场景	收益
Conv + BN + ReLU	CNN主干网络	访存减少50%以上
Conv + Add + ReLU	ResNet残差结构	减少一次写回
MatMul + Add + Softmax	Transformer Attention	减少中间矩阵写回
LayerNorm + Add	Transformer Block	减少一次访存

1.6 一张图看懂算子融合

下面这张SVG图展示了算子融合的核心逻辑：

1.7 融合的代价与限制

说实话，算子融合不是银弹。我在实际部署中踩过几个坑：

• 寄存器压力增大：融合后的算子需要更多寄存器来保存中间结果，如果寄存器不够用，反而会 spill 到栈上，得不偿失。
• 调试难度增加：融合后的算子是一个黑盒，出了问题很难定位是哪个子步骤导致的。
• 并非所有场景都适用：比如当中间结果被多个后续算子共享时，强行融合反而会导致重复计算。

1.8 小结

算子融合的核心思想很简单：减少中间结果的访存，让数据在计算单元内部流动。它不是什么高深的理论，而是工程实践中被反复验证的有效手段。

我个人习惯在开始任何推理优化工作前，先用Profiling工具看看访存占比。如果访存开销超过30%，那算子融合大概率能带来显著收益。

嗯，这一章就到这里。记住一句话：融合不是目的，减少无效访存才是。

---