Profiling 深入阅读

假设你接手的是一次“系统突然变慢”的问题：有人说是 kernel 慢了，有人说是显存抖了，也有人怀疑是多卡同步。接下来你要做的不是立刻改代码，而是先把证据链立住。

这条线最重要的是按暴露顺序判断：先问问题是什么，再采证，再归因，最后再决定到底该不该动系统。

第一段：先问问题，而不是先开工具

故事通常从“感觉变慢了”开始。第一步不是打开 profiler，而是先分清：这是时间问题、显存问题，还是多卡等待问题。

对应正文：01 为什么 Profiling 值得单独成章。先写清现象和影响指标，避免采集了大量 trace 却没有待验证的问题。

第二段：先看时间，再看空间

大多数性能问题先从时间热点开始；如果时间问题又伴随显存波动，再进入 memory timeline。也就是说，时间和空间虽然相关，但不应该一开始就混在一起看。

对应正文：02 时间拆分与 Trace 阅读 和 03 Memory Timeline 与 Residency。先定位时间，再解释空间，才能区分“算得慢”和“等资源”。

第三段：跨卡以后，再看等待

一旦问题进入多卡，重点就不再只是“哪个算子慢”，而是“谁在等谁”。这时同步等待、overlap 和 communication trace 才会成为主问题。

对应正文：04 通信等待与 Overlap。多卡结论必须与单卡基线比较，否则无法判断通信代价是否真的改变了整体结果。

第四段：最后回到验证和行动

真正的收口不在“看到了热点”，而在 benchmark 和回归验证能不能说明这次动作值得保留。把这条故事走完以后，一个更像真实结论的说法通常不是“我们看到某个红条”，而是：证据链先定位了问题，再支持了最终行动建议。

对应正文：05 Benchmark 设计与回归验证 和 06 从诊断到行动决策。最终输出应是可复现的行动建议，而不是一张孤立的 profile 截图。