GPU 利用率很高，内核仍然慢；显存带宽没有跑满，团队却判断“不是内存瓶颈”。这类结论往往缺少同一个分析框架。Roofline 把可达到的计算性能与数据移动能力放在一张图中，用运算强度描述每搬运一定字节数据完成多少运算，再观察内核点位更靠近计算屋顶还是带宽斜线。它的价值是缩小排查方向，不是替代代码与算法分析。输入数据、编译结果、缓存命中和指令类型不同，点位都会变化，因此不能拿另一台机器或另一种输入的图直接套用。
先确认图上的每个量代表什么
横轴运算强度通常来自被统计的浮点操作与数据流量之比，纵轴反映达到的运算速率。这里的“字节”可能对应不同内存层级，计算屋顶也会因精度和指令路径不同。若内核使用 Tensor Core、普通 FP32、整数或混合精度，适用的峰值上限并不相同。分析报告必须记录 Nsight Compute 版本、GPU、时钟策略、内核名称、输入形状和采集的指标集合。否则只保留一张截图，后续无法解释点位为什么移动。
靠近斜线不等于只需优化显存
数据移动可能发生在 HBM、L2、L1、共享内存与寄存器之间。一个内核在设备显存层面看似带宽受限，根因可能是访问不合并、缓存复用差、加载了最终没有参与计算的数据，或中间结果频繁写回。应配合检查全局内存访问效率、缓存命中、每条请求字节数和访存事务，而不是直接改成更宽的加载。对于结构化稀疏、间接索引或分支较多的代码，理论字节数与实际事务之间的差距尤其重要。优化目标是减少无效数据移动并提高复用，不是追求某个计数器绝对接近上限。
靠近水平屋顶也可能有别的限制
点位处于计算侧，并不意味着已充分使用所有执行单元。指令依赖、流水线分布、占用率、分支发散和发射停顿都可能降低实际表现。若单线程存在长依赖链，增加线程块有时能隐藏延迟，有时又会因寄存器和共享内存压力降低驻留。应查看调度器状态、指令混合和主要停顿原因，并用小范围改动验证假设。例如减少一次昂贵运算、调整数据布局、改变线程块大小，每次只改一个变量，再看 Roofline 点位和端到端耗时是否同时改善。
把多阶段算法拆开看
一个应用可能先做数据重排，再执行高强度矩阵运算，最后归约。只看总体时间会把三种性质混在一起。Nsight Compute 以 GPU 内核为分析对象，应先通过系统级追踪找出占时和调用频率，再挑选代表性内核采集详细指标。高频小内核即使单次很短，也可能因启动和同步成本成为主因；某个大内核的 Roofline 很漂亮，也不代表应用已经优化。必要时比较内核融合前后：融合可能减少中间读写，却增加寄存器压力和编译复杂度，收益必须由完整工作流确认。
建议的证据链
- 用真实输入建立端到端基线，确定高占时或高频内核，而非全量盲采。
- 固定时钟与环境，采集与该精度、内存层级相匹配的 Roofline 指标。
- 检查访问效率、缓存、指令混合、停顿和占用率，形成一个可验证假设。
- 进行单变量改动，并同时比较内核时间、应用时间、结果正确性和资源用量。
- 在不同输入形状和批量下回归，确认优化没有只适配一个尺寸。
Roofline 最适合回答“下一步更应关注计算还是数据移动”，不适合单独证明某个优化必然有效。采集详细指标会增加运行开销，生产环境应限定范围，并优先在可复现的测试节点完成。指标含义、采集集合与 Roofline 相关说明可查阅 NVIDIA Nsight Compute Profiling Guide。最终判断应回到业务输入、正确性和端到端服务目标。
WeChat
Profile