第二讲：计算访存比分析——Roofline模型详解
大家好，我是你们的老朋友。今天咱们聊聊一个非常核心的话题——计算访存比。
说实话，我刚开始做算子优化的时候，经常一头雾水。明明代码写得挺漂亮，跑起来就是慢。后来我才明白，瓶颈往往不在计算，而在数据搬运。你想想看，GPU算得再快，数据喂不进去，不也是白搭？
这一讲，我们就来彻底搞懂Roofline模型。它能帮你一眼看穿：你的算子到底是计算密集型，还是访存密集型。
1. 什么是计算访存比？
先问个问题：一个算子，算一次需要搬多少数据？
计算访存比（Compute-to-Memory Ratio），说白了就是每访问一次内存，能做多少次计算。公式很简单：
计算访存比 = 总计算量（FLOPs） / 总数据访问量（Bytes）单位是 FLOPs/Byte。这个值越大，说明算子越“计算密集”；越小，说明越“访存密集”。
核心观点： 计算访存比决定了你的算子到底被什么卡住——是算力不够，还是带宽不够。
2. Roofline模型——一张图看懂瓶颈
Roofline模型，我愿称之为算子优化的“地图”。它把硬件能力画成一条“屋顶线”，把你的算子画成一个点。点落在哪里，瓶颈就在哪里。
先看这张图：
这张图怎么看？我教你三步：
- 看屋顶：斜线部分是带宽限制，水平线部分是算力限制。拐点就是两者的分界线。
- 找你的算子：算子的计算访存比决定了它在X轴的位置。
- 看落点：落在斜线上，说明被带宽卡住；落在水平线上，说明被算力卡住。
我的经验： 我见过太多人一上来就优化计算，结果发现瓶颈在访存。先看Roofline，再动手，能少走一半弯路。
3. 如何计算算子的计算访存比？
咱们拿一个具体的例子来说。假设有一个 矩阵乘法：C = A × B，其中 A 是 M×K，B 是 K×N，C 是 M×N。
3.1 计算量
矩阵乘法的计算量是：
FLOPs = 2 × M × N × K为什么是2？因为每次乘加算2个操作（乘法和加法）。
3.2 数据访问量
数据访问量取决于你读了多少数据：
Bytes = (M×K + K×N + M×N) × 4 （假设float32，每个数4字节）3.3 计算访存比
计算访存比 = (2 × M × N × K) / ((M×K + K×N + M×N) × 4)举个例子，M=N=K=1024：
FLOPs = 2 × 1024³ ≈ 2.1 × 10⁹
Bytes = (1024² + 1024² + 1024²) × 4 ≈ 12.6 × 10⁶
计算访存比 ≈ 167 FLOPs/Byte这个值算高还是低？咱们对比一下硬件：
| 硬件 | 算力 (TFLOPS) | 带宽 (GB/s) | 拐点 (FLOPs/Byte) |
|---|---|---|---|
| NVIDIA A100 | 19.5 | 2039 | ~9.6 |
| NVIDIA V100 | 15.7 | 900 | ~17.4 |
| NVIDIA T4 | 8.1 | 320 | ~25.3 |
你看，167 远大于拐点值。所以这个矩阵乘法在A100上属于计算密集型。
关键结论： 计算访存比 > 硬件拐点 → 计算密集型；计算访存比 < 硬件拐点 → 访存密集型。
4. 如何定位算子是计算密集型还是访存密集型？
我总结了一套三步定位法，你在项目中可以直接用：
4.1 第一步：理论分析
先用手算或者写个小脚本，算出算子的计算访存比。公式我前面给了，照着套就行。
小技巧： 我习惯用Python写个函数，输入M、N、K，直接输出计算访存比。这样调参数很方便。
4.2 第二步：实际测量
理论归理论，实际跑起来可能不一样。用profiler工具测一下：
- NVIDIA Nsight Compute：看
Memory Throughput和Compute Throughput - PyTorch Profiler：看
self_cuda_time和memory_usage
如果 Memory Throughput 接近带宽上限，那就是访存密集型。反之，如果 Compute Throughput 接近算力上限，那就是计算密集型。
4.3 第三步：对比拐点
把实际测量到的计算访存比和硬件拐点对比：
硬件拐点 = 算力 / 带宽比如A100：
拐点 = 19.5 TFLOPS / 2039 GB/s ≈ 9.6 FLOPs/Byte如果你的算子计算访存比是 5，那它就是访存密集型。如果是 50，那就是计算密集型。
注意： 我曾经踩过一个坑——理论计算访存比很高，但实际跑出来却是访存密集型。后来发现是数据布局不连续，导致实际带宽利用率很低。所以理论分析只是第一步，一定要结合实测。
5. 不同瓶颈的优化策略
定位清楚之后，优化方向就明确了：
| 瓶颈类型 | 优化策略 | 常用手段 |
|---|---|---|
| 计算密集型 | 提高计算效率 | 向量化、指令级并行、使用Tensor Core、减少指令依赖 |
| 访存密集型 | 减少数据搬运 | 数据复用、tiling、合并访存、使用共享内存 |
| 边界情况 | 两者兼顾 | 先优化访存，再优化计算 |
我的建议： 对于访存密集型算子，优先做数据复用。比如把多次用到的数据缓存到共享内存或寄存器里。对于计算密集型算子，优先用Tensor Core或者SIMD指令。
6. 实战案例：一个卷积算子的分析
咱们看一个真实案例。我在优化一个 3×3 卷积 时，输入是 256×256×64，输出是 256×256×128。
先算计算访存比：
计算量 = 2 × 256 × 256 × 64 × 128 × 3 × 3 ≈ 9.4 × 10⁹ FLOPs
数据量 = (256×256×64 + 256×256×128 + 64×128×3×3) × 4 ≈ 50.3 × 10⁶ Bytes
计算访存比 ≈ 187 FLOPs/Byte在A100上，187 > 9.6，理论上是计算密集型。但实际profiling发现，内存带宽利用率只有40%。
为什么？因为卷积的数据复用性差——每次滑动窗口都要重新读数据。我做了两件事：
- im2col + tiling：把卷积转成矩阵乘法，然后用tiling提高数据复用
- 共享内存缓存：把输入特征图的一部分缓存到共享内存
优化后，带宽利用率提升到85%，吞吐提升了2.3倍。
经验之谈： 别被理论值骗了。实际跑起来，数据布局、访存模式、缓存命中率都会影响真实计算访存比。一定要用profiler验证。
7. 总结
这一讲的核心就一句话：先定位瓶颈，再动手优化。Roofline模型就是你的定位工具。
- 计算访存比 = FLOPs / Bytes，决定了算子的类型
- Roofline模型 帮你一眼看出瓶颈在算力还是带宽
- 三步定位法：理论分析 → 实际测量 → 对比拐点
- 优化方向：计算密集型提算力，访存密集型减搬运
下一讲，我们会深入tiling策略，看看如何通过分块来提升数据复用。嗯，到时候我会分享一个让我印象深刻的优化案例——一个看起来简单的算子，我调了整整一周才搞定。