Roofline模型：一眼看穿你的算子瓶颈在哪

做算子融合，第一步不是急着写代码。

我个人的习惯是——先搞清楚一个问题：当前这个算子，到底是卡在计算上，还是卡在带宽上？

这个问题不搞清楚，你后面做的所有优化都可能是在瞎忙活。今天我们就用Roofline模型，把这个事情彻底说透。

什么是Roofline模型？

说白了，Roofline模型就是一个二维坐标系。横轴是计算强度（Operations per Byte），纵轴是性能（FLOPS）。

它把硬件的天花板画成了两条线：

• 水平线：计算峰值，GPU能跑多快
• 斜线：带宽天花板，内存能喂多快

这两条线相交的地方，就是所谓的“拐点”。

嗯，这里要注意：绝大多数深度学习算子，都落在带宽受限区。这也是为什么算子融合能带来巨大收益的根本原因。

SVG图解：Roofline模型的核心逻辑

我画了一张图，帮你直观理解这个模型。你看一眼就明白了：

你看这张图，Element-wise算子（比如ReLU、Add）落在最左边，计算强度极低。这意味着GPU大部分时间都在等数据从内存搬过来，算力根本用不上。

而大矩阵乘法落在右边，计算强度高，GPU的算力才能充分发挥。

如何计算算子的计算强度？

公式其实很简单：

计算强度 = 总计算量 (FLOPs) / 总数据访问量 (Bytes)

举个例子，一个简单的向量加法：

// C = A + B, 每个向量长度 N
// 计算量: N 次加法 = N FLOPs
// 数据访问: 读A(N*4B) + 读B(N*4B) + 写C(N*4B) = 12N Bytes
// 计算强度 = N / 12N ≈ 0.083 Ops/Byte

0.083 Ops/Byte，这个值非常低。我做过一个项目，里面有个逐元素操作的kernel，计算强度只有0.05左右。当时我一看这个数字就知道——带宽瓶颈，没跑了。

实战：用Roofline定位瓶颈

假设你有一个算子，在A100上跑。A100的峰值算力是312 TFLOPS，带宽是2 TB/s。

我们先算拐点：

拐点 = 312 TFLOPS / 2 TB/s = 156 Ops/Byte

现在看你的算子：

算子	计算量 (FLOPs)	数据访问 (Bytes)	计算强度 (Ops/Byte)	瓶颈类型
ReLU	1M	12M	0.08	带宽受限
Conv 3x3	500M	50M	10	带宽受限
MatMul 4096x4096	137G	256M	535	计算受限

看到没？ReLU和Conv都远低于156这个拐点。这就是为什么我们要做算子融合——把多个带宽受限的算子合并，减少数据搬运次数。

Roofline模型的实用技巧

在实际项目中，我一般这样用Roofline：

1. 先算拐点：查一下目标GPU的峰值算力和带宽，算出拐点值
2. 再算算子：估算当前算子的计算强度
3. 对比定位：看算子在拐点左边还是右边
4. 制定策略：
   • 带宽受限 → 做融合、减少访存、用共享内存
   • 计算受限 → 优化算法、用更快的指令、增加并行度

你想想看，如果你连瓶颈在哪都不知道，怎么知道该往哪个方向优化？

一个真实案例

我记得有一次帮一个团队优化Transformer推理。他们发现整个模型跑得很慢，但不知道问题出在哪。

我用Roofline一分析，发现：

• Self-Attention中的MatMul → 计算受限（在拐点右边）
• LayerNorm + Residual Add → 带宽受限（在拐点左边，计算强度只有0.1）
• FeedForward中的GELU → 带宽受限

于是我们重点优化了LayerNorm和GELU的融合，把这两个带宽受限的算子合并成一个kernel。结果整个推理延迟降低了30%。

你看，找准瓶颈，事半功倍。

总结一下

Roofline模型不是什么高深的理论，它就是一个帮你看清问题本质的工具。

• 算子在拐点左边 → 带宽受限 → 做融合
• 算子在拐点右边 → 计算受限 → 优化算法

我个人建议，每次写kernel之前，先花5分钟算一下计算强度。这5分钟，能帮你省下后面几天的弯路。

下一节，我们会深入具体的融合策略，看看如何把多个带宽受限的算子“粘”在一起。但在此之前，先把Roofline模型吃透——这是所有融合优化的基础。

---

想要更多资料，联系可可