算子性能调优基础：计算强度与带宽、Roofline模型、性能分析工具
好，咱们进入正题。算子性能调优，说白了就是搞清楚一件事：你的算子到底被什么卡住了脖子？是计算单元在等数据，还是数据到了计算单元却没事干？
我刚开始做算子优化那会儿，上来就闷头改代码。改完一跑，快了，但不知道为什么快。后来踩的坑多了，才明白一个道理——没有数据支撑的优化，都是瞎蒙。今天这章，我就带你建立一套「诊断思维」。
1. 计算强度与带宽：算子的两个核心指标
先问个问题：一个算子跑得慢，到底是计算慢，还是搬运数据慢？
答案其实就藏在两个指标里：计算强度和带宽。
- 计算强度：每字节数据需要做多少次计算。单位是 FLOPs/Byte。
- 带宽：单位时间内能从显存搬到寄存器多少数据。单位是 GB/s。
我习惯把计算强度想象成「性价比」。你想想看，从显存搬一个 float 进来，如果只做一次加法就扔出去，那这趟搬运就太亏了。反过来，如果搬进来一个数据，能反复用几十次，那就很划算。
核心公式：
计算强度 I = 总计算量 (FLOPs) / 总数据搬运量 (Bytes)
说白了，就是「每口饭能干多少活」。
我在项目中遇到过这样一个案例：一个 element-wise 的加法算子，计算强度极低，大概只有 0.5 FLOPs/Byte。这种算子，你就算把 GPU 频率超到冒烟，性能也上不去。为什么？因为瓶颈在显存带宽，计算单元一直在等数据。
2. Roofline模型：一眼看出瓶颈在哪
光知道计算强度和带宽还不够，你得把它们画在一张图上。这就是 Roofline 模型。
Roofline 模型长什么样？我画个图给你看。
这张图怎么看？我教你个口诀：「看位置，判瓶颈」。
- 如果算子在斜坡区（带宽受限），说明计算单元在等数据。优化方向：减少数据搬运、提高数据复用、用更快的显存。
- 如果算子在平顶区（计算受限），说明计算单元满负荷了。优化方向：提高并行度、用更快的计算指令（如 FMA）、减少指令依赖。
我的经验：大多数深度学习算子，尤其是小 batch 的卷积、GELU、LayerNorm，都落在带宽受限区。我见过有人花两周优化一个卷积 kernel 的计算逻辑，结果性能只提升了 5%。后来用 Roofline 一分析，发现瓶颈在带宽，改了一下数据排布，直接翻倍。嗯，方向比努力更重要。
3. 性能分析工具：nsys、ncu、rocprof
理论讲完了，咱们来点实操。你总不能靠猜来判断瓶颈吧？得用工具。
我常用的三把刀：nsys（NVIDIA Nsight Systems）、ncu（NVIDIA Nsight Compute）、rocprof（AMD ROCm Profiler）。
3.1 nsys：看全局，找热点
nsys 是个「上帝视角」的工具。它能告诉你整个程序的 timeline，每个 kernel 占了多少时间，CPU 和 GPU 之间有没有同步等待。
我习惯先跑一遍 nsys，看看有没有明显的「气泡」——就是 GPU 空闲的时间段。
# 命令行用法
nsys profile -o my_profile -t cuda,nvtx ./my_app
# 生成报告后，用 Nsight Systems GUI 打开
# 或者导出为文本
nsys stats my_profile.qdrep你看，就这么简单。跑完之后，你会看到类似这样的输出：
Time (%) Total Time (ns) Calls Avg (ns) Med (ns) Name
------- --------------- ----- --------- --------- ------------------
45.2 125000000 150 833333 810000 matmul_kernel
30.1 83000000 300 276667 260000 relu_kernel
15.5 42800000 50 856000 840000 softmax_kernel一眼就能看出，matmul 占了 45% 的时间。那好，重点优化它。
我曾经踩过的坑：有一次我优化了一个 kernel，本地测试快了 30%。结果放到完整模型里一跑，整体只快了 2%。为什么？因为那个 kernel 在整体时间占比不到 10%。所以记住：先找热点，再动手。别在无关紧要的地方浪费时间。
3.2 ncu：看细节，抠指令
nsys 告诉你「哪个 kernel 慢」，ncu 告诉你「这个 kernel 为什么慢」。
ncu 能深入到指令级别，告诉你计算吞吐、带宽利用率、warp 占用率、bank conflict 等等。
# 分析单个 kernel
ncu --kernel-name matmul_kernel --set full -o matmul_report ./my_app
# 关键指标解读
# - Memory Throughput: 实际带宽利用率
# - Compute Throughput: 计算单元利用率
# - Occupancy: 每个 SM 上活跃的 warp 数量
# - L1/TEX Cache Throughput: 缓存命中情况我一般先看两个指标：Memory Throughput 和 Compute Throughput。如果 Memory Throughput 接近峰值但 Compute Throughput 很低，那就是带宽受限。反过来就是计算受限。
举个例子，有一次我优化一个卷积 kernel，ncu 报告显示 Memory Throughput 只有峰值的 30%，但 Compute Throughput 已经到 80% 了。这说明什么？说明数据没喂饱计算单元。后来发现是 global memory 访问模式不对，改成 coalesced 访问后，Memory Throughput 直接飙到 85%。
3.3 rocprof：AMD 平台的替代方案
如果你用的是 AMD GPU，别慌，有 rocprof。它的设计思路和 ncu 类似，但命令和输出格式略有不同。
# 基本用法
rocprof --stats --hsa-trace ./my_app
# 输出文件
# - results.csv: kernel 级别的统计
# - results.stats.csv: 汇总统计
# 查看 kernel 耗时
cat results.stats.csv | grep "matmul"rocprof 的输出会包含 KernelName、Duration、Wavefronts、VGPRCount 等信息。我习惯重点关注 L2CacheHit 和 MemUnitBusy，这两个指标能直接反映带宽利用情况。
小技巧：如果你在 AMD 平台上做优化，建议同时用 rocm-smi 监控显存带宽和温度。我遇到过因为散热问题导致降频，性能直接腰斩的情况。工具链要配合使用，别只看 profiler 的数据。
4. 实战思路：从分析到优化
好，工具都介绍完了。那具体怎么用？我给你一个我常用的流程：
- 跑 nsys，找出最耗时的 top 3 kernel。
- 跑 ncu/rocprof，分析每个 kernel 的瓶颈类型（带宽 vs 计算）。
- 对照 Roofline 模型，确认瓶颈区域。
- 针对性优化：
- 带宽受限：优化数据排布（SOA vs AOS）、使用 shared memory、减少 global memory 访问。
- 计算受限：提高并行度、使用向量化指令、减少分支发散。
- 再次 profiling，验证优化效果。
这个流程我用了好几年，基本没翻过车。你想想看，有了数据支撑，你的优化就不再是「玄学」，而是「科学」。
一句话总结：
计算强度决定理论上限，Roofline 模型指明瓶颈方向，profiling 工具提供优化依据。三者缺一不可。
好了，这章的内容就到这儿。记住，别急着改代码，先搞清楚你的算子到底被什么卡住了。下一章咱们会深入具体的算子优化技巧，到时候这些基础工具会反复用到。