13. Profiling and Bottleneck Analysis | Profiling and Bottleneck Analysis

难度： Medium | 标签： Profiling, Performance, Bottleneck | 目标人群： 准备进入 Chapter 2 / 3 的学习者

这一页把 Chapter 1 的“会算、会估”，接到“会判断哪里慢、值不值得优化、该怎么查”上。核心是先观察，再优化。

前置关系

• Chapter 1 已经讲过参数量、显存、Attention 和系统架构
• Chapter 2 / 3 会直接遇到训练慢、推理慢、显存高和通信瓶颈
• 先建立“怎么找瓶颈”的基础思维

你应该先建立的直觉

1. 先观察，再优化

优化不是一上来就改代码，而是先回答：

• 哪一段最慢
• 慢的是计算、内存还是通信
• 是单次慢，还是总耗时慢
• 是平均慢，还是尾部慢

没有 profiling，很多优化只是猜。

2. bottleneck 不一定只在算法本身

一个系统可能慢在：

• 计算不足
• memory bandwidth 不够
• 显存分配和碎片
• CPU-GPU 数据搬运
• 多卡通信

所以 Chapter 1 的作用不是告诉你“要先动手优化”，而是先告诉你“可能慢在哪”。

3. 关注“值不值得优化”

不是所有慢的地方都值得动：

• 如果只占总耗时很小，可能不值得折腾
• 如果是高频路径，就值得认真看
• 如果优化后不影响主瓶颈，收益可能很有限

这个判断能力，后面 Chapter 2 / 3 会非常常用。

一个最常见的分析顺序

你可以把 profiling 粗略理解成下面这条线：

先看整体耗时 -> 再看热点算子 -> 再看内存和通信 -> 最后决定是否优化

这不是工具教程，而是思路教程。
真正到 Chapter 2 / 3 时，你会把这个思路应用到训练、推理和 kernel 上。

常见误区

• 看到慢就马上改代码
• 以为 profiling 只看 GPU 利用率
• 以为所有 bottleneck 都在算子
• 把一次测量当成结论，不看多轮结果

这一页学完后，你应该能回答

• 怎么判断一个系统到底慢在哪
• 怎么区分计算瓶颈、内存瓶颈和通信瓶颈
• 为什么优化之前要先做 profiling
• 为什么 Chapter 2 / 3 的很多结论都要靠数据验证，而不是靠直觉

和后续章节的联系

• Chapter 2: Attention / FlashAttention / PagedAttention
  你会用 profiling 判断慢点到底在算子还是显存

• Chapter 2: Gradient Checkpointing / ZeRO / Parallelism
  你会用 profiling 判断瓶颈是计算还是通信

• Chapter 3: Triton / CUDA / 算子融合
  你会用 profiling 判断 kernel 的改动是否真的有收益

小结

这一页的作用也很简单：

• 先让你知道如何找瓶颈
• 再让你知道为什么要先测量再优化
• 最后让你知道为什么 Chapter 2 / 3 的优化必须建立在 profiling 之上

如果你已经知道“慢在哪里”比“怎么改”更重要，这一页的目标基本达成，后面 Chapter 2 / 3 还会继续用到这套思路。