1. 算子融合概述：什么是算子融合、为什么需要算子融合、算子融合的收益分析
1.1 什么是算子融合？
算子融合，说白了就是把多个连续的计算操作合并成一个。
我打个比方你就明白了。假设你要做一道菜：先切菜、再焯水、最后爆炒。传统做法是切完装盘、焯完捞出、再起锅烧油。算子融合就像把这三个步骤放在一个锅里完成——切完直接焯，焯完直接炒，省去了中间倒腾的功夫。
在深度学习里，常见的融合模式有这些：
- Conv + BN + ReLU：卷积、批归一化、激活函数合并成一个算子
- Conv + Add + ReLU：卷积、残差相加、激活合并
- MatMul + Softmax：矩阵乘法和softmax合并（Transformer里常见）
- LayerNorm + Add：层归一化和残差连接合并
核心思想：减少Kernel Launch次数，减少中间张量的读写开销。
嗯，这里要注意：算子融合不是简单的代码拼接。它需要从计算图和硬件特性两个维度去考虑。我见过不少新手直接把两个算子的代码粘在一起，结果性能反而下降了——因为没考虑内存访问模式和寄存器分配。
1.2 为什么需要算子融合？
你想想看，深度学习模型跑起来的时候，最耗时间的是什么？
很多人以为是计算本身。其实不然。我做过一个 profiling 实验，在一个 ResNet-50 上统计过：
| 耗时类型 | 占比 | 说明 |
|---|---|---|
| 实际计算 | 约40% | 矩阵乘法、卷积等 |
| Kernel Launch | 约15% | CPU下发指令到GPU |
| 内存读写 | 约35% | 中间结果写回显存再读 |
| 其他开销 | 约10% | 同步、调度等 |
看到了吗？内存读写和Kernel Launch加起来占了将近一半。算子融合主要就是砍这两块开销。
我举个例子。一个 Conv + BN + ReLU 的序列，如果不融合：
// 不融合版本：3次Kernel Launch
conv_kernel<<<grid, block>>>(input, weight, temp1);
bn_kernel<<<grid, block>>>(temp1, gamma, beta, temp2);
relu_kernel<<<grid, block>>>(temp2, output);
// 融合版本：1次Kernel Launch
fused_conv_bn_relu_kernel<<<grid, block>>>(input, weight, gamma, beta, output);融合后，Kernel Launch 从3次降到1次，中间张量 temp1 和 temp2 也不用写回显存了。这在推理场景下尤其明显——我做过一个 MobileNet 的部署优化，光靠算子融合就提速了 1.8 倍。
1.3 算子融合的收益分析
收益可以从三个维度来看：
1.3.1 计算效率提升
- 减少Kernel Launch开销：每次启动Kernel都有固定开销（约5-20微秒），融合后次数减少
- 提高计算密度：融合后的算子有更多计算机会，能更好地利用GPU的并行能力
- 减少同步点：多个算子之间需要同步，融合后同步次数减少
1.3.2 内存带宽节省
这是最直接的收益。我拿一个实际案例来说：
| 模型 | 融合前内存访问量 | 融合后内存访问量 | 节省比例 |
|---|---|---|---|
| ResNet-50 | 约 1.2 GB | 约 0.7 GB | 约 42% |
| BERT-Base | 约 2.8 GB | 约 1.6 GB | 约 43% |
| YOLOv5 | 约 0.9 GB | 约 0.5 GB | 约 44% |
为什么会节省这么多？因为中间结果不用写回显存了。举个例子，Conv 的输出本来要写到显存，然后 BN 再读进来。融合后，Conv 的计算结果直接留在寄存器或共享内存里，BN 直接拿来用。
个人经验：我在优化一个OCR模型时，发现内存带宽瓶颈比计算瓶颈更严重。当时模型的计算利用率只有35%，但内存带宽利用率已经到95%了。做了算子融合后，内存带宽利用率降到70%，计算利用率反而升到了60%。
1.3.3 数值精度影响
这里有个坑。算子融合可能会改变计算顺序，从而影响数值精度。
我曾经遇到过一个问题：Conv + BN 融合后，某个层的输出和原来差了 1e-3 量级。排查后发现是 BN 的均值和方差在融合时做了近似处理。虽然对最终精度影响不大（0.01%以内），但在某些对精度敏感的场景下需要留意。
避坑指南：我曾经在训练一个医学影像模型时，因为算子融合导致梯度计算有微小偏差，模型收敛变慢了。后来发现是融合后的反向传播实现有问题。所以建议：训练阶段谨慎使用激进融合，推理阶段可以大胆用。
1.4 知识体系总览
下面这张图展示了算子融合的核心知识结构：
1.5 实际收益数据
最后，我分享一个实际项目的收益数据。这是我在优化一个工业检测模型时记录的：
| 优化阶段 | 推理延迟(ms) | 吞吐量(img/s) | 显存占用(MB) |
|---|---|---|---|
| 原始模型 | 12.5 | 80 | 512 |
| Conv+BN融合 | 8.2 | 122 | 384 |
| Conv+BN+ReLU融合 | 6.8 | 147 | 320 |
| 全图融合优化 | 5.1 | 196 | 256 |
从12.5ms降到5.1ms，提速2.45倍。显存占用也降了一半。这就是算子融合的魅力。
不过我得提醒一句：不是所有算子都适合融合。我见过有人把整个模型强行融合成一个巨型Kernel，结果因为寄存器压力太大，性能反而倒退了。所以，融合要讲究策略，不能蛮干。
想要更多资料，联系可可