一、算子融合概述：从理论到实战
大家好，我是你们的老朋友。今天咱们聊聊算子融合。
说实话，我第一次接触这个概念时，觉得它挺玄乎的。不就是把几个算子拼在一起吗？能有多大收益？后来在项目中踩了坑，才明白——嗯，这玩意儿真不是花架子。
1.1 什么是算子融合
算子融合，说白了就是把多个连续的计算操作合并成一个。
举个例子。你写神经网络时，经常看到这样的代码：
# 常见的分离写法
x = torch.add(x, bias) # 加法
x = torch.relu(x) # 激活
x = torch.conv2d(x, weight) # 卷积这三个操作，在底层是三个独立的 kernel 调用。每个 kernel 都要从显存读数据、计算、写回。而算子融合，就是把它们合并成一个 kernel：
# 融合后的写法（伪代码）
x = fused_conv_bias_relu(x, weight, bias)一次读取，一次计算，一次写回。就这么简单。
核心思想：减少访存次数，提升计算密度。
我在项目中遇到过一种情况：一个简单的残差块，拆成了 7 个算子。性能惨不忍睹。融合后变成 2 个，速度直接翻倍。你想想看，这差距有多大。
1.2 为什么需要算子融合
这个问题，我经常被问到。其实原因很直接——GPU 的算力远大于显存带宽。
我给大家算笔账：
| 硬件指标 | A100 (典型值) | V100 (典型值) |
|---|---|---|
| FP16 算力 | 312 TFLOPS | 125 TFLOPS |
| 显存带宽 | 1.6 TB/s | 0.9 TB/s |
| 计算/带宽比 | ~195 | ~139 |
什么意思呢？你每从显存读一个字节，理论上可以做 100 多次浮点运算。但实际中，很多小算子根本做不了这么多计算——数据刚读完，算两下就写回去了。
这就是典型的访存瓶颈。
我的经验：判断一个模型是否适合融合，就看它的算子粒度。如果大部分算子的计算量小于 1 微秒，那基本就是访存受限。这时候融合收益最大。
我曾经优化过一个 BERT 模型。里面大量的小算子——LayerNorm、Add、GELU 都是独立的。融合后，单层推理时间从 2.3ms 降到了 1.1ms。你猜怎么着？就是靠把 6 个算子合并成 2 个。
1.3 算子融合的收益分析
收益到底有多大？我习惯从三个维度看：
- 访存减少：这是最直接的收益。融合后，中间结果不用写回显存，直接在寄存器或共享内存里传递。
- kernel 启动开销降低：每个 kernel 启动都有几十微秒的固定开销。融合后，启动次数从 N 次变成 1 次。
- 计算密度提升：融合后的 kernel 可以做更多计算，让 GPU 的算力真正跑起来。
我给大家看一个实际案例。这是我在优化 ResNet-50 时记录的数据：
| 优化阶段 | 算子数量 | 单步耗时 (ms) | 加速比 |
|---|---|---|---|
| 原始版本 | 176 | 12.4 | 1.0x |
| Conv+BN+ReLU 融合 | 98 | 8.7 | 1.43x |
| 残差块内全融合 | 52 | 6.2 | 2.0x |
看到了吗？算子数量从 176 降到 52，速度翻了整整一倍。而且这还是在没有改动任何数学逻辑的前提下。
注意：不是所有算子都能融合。比如涉及不同数据类型转换、或者需要跨设备通信的算子，强行融合反而会引入额外开销。我曾经就犯过这个错——把两个需要不同 CUDA 核心的算子硬凑在一起，结果性能反而下降了 15%。
所以我的建议是：先分析，再动手。用 profiling 工具看看哪些算子是热点，哪些是访存受限。然后针对性地融合。
我个人习惯用 PyTorch 的 torch.profiler 或者 NVIDIA 的 Nsight Systems。跑一遍 profile，哪些算子该融合，一目了然。
1.4 知识体系总览
为了让大家更直观地理解算子融合的全貌，我画了一张图：
这张图把算子融合的核心脉络理清楚了。从「是什么」到「为什么」再到「怎么做」，每一步都有对应的实战方法。
一句话总结：算子融合不是银弹，但它是目前加速训练最有效、最稳定的手段之一。我做了这么多优化项目，每次都能从融合里拿到 20% 以上的收益。
好了，这一章就到这里。记住我说的——先 profile，再动手。下一章咱们会深入具体的融合策略，包括 Conv+BN+ReLU 的经典融合、残差块融合，还有 Transformer 里的 QKV 融合。到时候我会手把手带大家写代码。
想要更多资料，联系可可