huggingface的系列博客：PyTorch 性能分析地址：huggingface.co/blog/torch-profiler目前已经完成了两篇."不能被性能分析的东西，就无法被优化。

无论你是想从大型语言模型（LLM）中榨出更高的每秒 token 数，想把推理延迟再减少几毫秒，还是只是想弄明白为什么你的训练循环比规格表承诺的速度慢，最终都会走到性能分析这一步。

问题在于，性能分析的入门门槛很高。trace 看起来像一堵由彩色矩形组成的密集墙。事件名称也常常让人望而生畏。大多数教程默认你已经会读这些内容。所以即使我们知道自己应该做性能分析，打开一个 trace 仍然会让人觉得像是一件最好留到以后再做，或者交给别人做的麻烦事。这篇文章，以及它开启的这个系列，就是我们试图降低这个入门门槛的一次尝试。这是《PyTorch 性能分析》系列的开篇文章。

在这个系列中，我们会循序渐进地培养阅读 profiler trace 的能力，并用它来指导优化。计划如下：第一部分（本文）：从最简单的操作开始，也就是一次矩阵乘法后接一次偏置加法，并学习如何阅读 profiler 返回的内容。第二部分：扩展到 nn.Linear 和一个小型 MLP，用 trace 来引出优化思路，并观察底层 kernel。第三部分：把这些内容整合起来，应用到使用 transformers 的大型语言模型上。我们会从初学者的视角记录这段过程。除了基本的 PyTorch 知识之外，不需要其他前置条件。你可以把它当作一篇轻松阅读的文章，其中会有一些“原来如此！”的时刻。

文章结构刻意以问题为导向：我们打开一个 trace，问一句“等等，为什么会这样？”，然后一路追问答案，直到某个点突然变得清晰。读完之后，你应该会知道：如何设置 torch.profiler，以及它实际会返回什么；如何阅读 profiler 表格和 trace，包括 CPU 轨道、GPU 轨道，以及两者之间那些可疑的空白；从一次 Python 调用一路向下到 CUDA kernel 的事件链路；当你在上面加上 torch.compile 时，哪些东西会改变，以及更有意思的是，哪些东西不会改变。

在开始之前，先给出两个定义，它们会让下面的内容读起来更顺畅：GPU kernel 是一个在 GPU 的许多线程上并行运行的程序。CPU 负责调度并启动这些 kernel。你通常不需要自己编写 GPU kernel；当你使用一个 PyTorch 操作时，它会被自动转换成一个或多个在 GPU 上完成相应工作的 kernel。带着这两个概念，我们开始提问吧。"AI创造营