另一种方法是使用 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