Profiling 深入阅读

主故事线

如果把这段排障写成完整过程，它通常是这样推进的：先收到“训练变慢了”的反馈，然后沿着 17 -> 20 -> 13 看时间热点、等待热点和单步热点，发现慢点并不是均匀分布的；接着回到 2.5 -> 19 -> 32，确认 checkpointing 或重算确实在用时间换显存；再往后看 2.8 -> 33 -> 34 -> 42，发现多卡同步和通信热点把一部分收益吞掉了；最后回到 2.9 做 before / after 对照，判断这次改动到底是把瓶颈转移了，还是把系统整体变稳了。

端到端案例

一个更完整的 profiling 过程，通常是从“线上训练任务抖动”开始的。先是发现某个版本上线后，step time 比之前更不稳定；接着在 17 -> 20 -> 13 里看到，慢点不是单个算子，而是少数 step 被等待和重算拉长；然后回到 2.5 -> 19 -> 32，确认 activation 和 checkpointing 的确在抬高训练代价；当多卡扩到 2.8 -> 33 -> 34 -> 42 时，又发现通信热点让理论收益被吃掉一截；最后回到 2.9 做 before / after 对照，判断问题到底是优化策略换了个瓶颈，还是整体训练已经更稳。

阅读建议

• 先把这条长故事线当成“为什么要 profiling”的答案。
• 再回到 Profiling 正文 看摘要层、案例层和清单层。
• 如果你只想先解决训练、推理或通信问题，也可以直接去其他专题正文。