鉴于此，你可能会对 PyTorch 成为主流框架的现象感到不解，而这是因为现代深度学习模型通常执行大规模运算。此外，像 PyTorch 这样的框架是异步执行的。因此，大部分框架开销可以完全忽略。

如果我们的 GPU 算子足够大，那么 CPU 可以跑在 GPU 之前（因此 CPU 开销是无关紧要的）。另一方面，如果 GPU 算子太小，那么 GPU 将在 paperweight 上花费大部分时间。

那么，如何判断你是否处于这个问题中？由于额外开销通常不会随着问题的规模变化而变化（而计算和内存会），所以最简单的判断方法是简单地增加数据的大小。如果运行时间不是按比例增加，应该可以说遇到了开销限制。例如，如果将批大小翻倍，但运行时间仅增加 10%，则可能会受到开销限制。

另一种方法是使用 PyTorch 分析器。如下图，粉红色块显示了 CPU 内核与 GPU 内核的匹配情况。

CPU 运行地比 GPU 更超前。

另一方面，nvidia-smi 中的「GPU-Util」（不是「Volatile GPU-Util」）入口会测量实际运行的 GPU 内核的百分占比，所以这是另一种观察是否遇到开销限制的好方法。这种开销是 PyTorch 等所有灵活的框架所具有的，本质上都需要花费大量时间来「弄清楚要做什么」。

这可能来自 Python（查找属性或调度到正确的函数）或 PyTorch 中的代码。例如，当你执行 a b 时，需要执行以下步骤：

1. Python 需要在 a 上查找__add__调度到的内容。
2. PyTorch 需要确定张量的很多属性（比如 dtype、device、是否需要 autograd）来决定调用哪个内核。
3. PyTorch 需要实际启动内核。

从根本上说，这种开销来自能够在每个步骤中执行不同运算的灵活性。如果不需要这种灵活性，解决这种灵活性的一种方法是跟踪它，例如使用 jit.trace、FX 或 jax.jit。或者，可以换用 CUDA Graphs 之类的东西在更低的级别上执行此运算。

不幸的是，这是以失去灵活性为代价的。一种两全其美的方法是，通过在 VM 级别进行 introspect 来编写更多符合「真实」的 JIT 的内容。有关更多信息，可参阅 TorchDynamo (https://dev-discuss.pytorch.org/t/torchdynamo-an-experiment-in-dynamic-python-bytecode-transformation/361)。

总结

如果你想加速深度学习系统，最重要的是了解模型中的瓶颈是什么，因为瓶颈决定了适合加速该系统的方法是什么。

很多时候，我看到研究人员和其他对加速 PyTorch 代码感兴趣的人，会在不了解所处问题的情况下盲目尝试。

当然，另一方面，如果用户需要考虑这些东西，也反映了框架的部分失败。尽管 PyTorch 是一个活跃的关注领域，但 PyTorch 的编译器或配置文件 API 并不是最容易使用的。

总而言之，我发现对系统基本原理的理解几乎总是有用的，希望这对你也有用。

原文链接：https://horace.io/brrr_intro.html