PyTorch Design Philosophy

以下内容翻译自：PyTorch Design Philosophy

本文档旨在帮助贡献者和模块维护者理解 PyTorch 演化出的高层设计原则。这些规则并不是硬性规定的，而是用来作为指南，以帮助权衡不同的关注点，解决开发 PyTorch 时可能出现的分歧。有关贡献、模块维护以及如何将分歧升级至核心维护者的更多信息，请参见 PyTorch Governance。

Design Principles

Principle 1: Usability over Performance

这一原则或许令人惊讶!正如一位黑客新闻海报写道：PyTorch令人惊叹!……虽然我很困惑。一个 ML 框架如何不被速度/性能所困扰？参见 Hacker News 对 PyTorch 的讨论。

Soumith在 Growing the PyTorch Community 的博客文章中对这一点进行了深入的探讨，但可高度概括为：

• PyTorch 的首要目标是可用性
• 第二个目标是具有合理的性能

我们认为，保持我们的灵活性以支持在我们的抽象之上构建的研究成果的能力仍然至关重要。我们不知道工作负载的未来会是什么，但我们知道我们希望它们首先建立在 PyTorch 之上，这需要灵活性。

更具体地说，我们以可用性优先的方式进行操作，尽量避免在没有对权衡的清晰看法前跳到限制优先的机制(例如，静态形状、仅图模式)。通常会有一种诱惑，即预先施加严格的用户限制，因为它可以简化实施，但这也会带来风险：

• 性能可能不值得用户争执，要么是因为性能收益不够引人注目，要么只适用于一组相对狭窄的子问题。
• 即使性能优势令人信服，这些限制也会将生态系统分割成不同的限制集，以致用户很快就会无法理解。

我们希望用户能够将他们的 PyTorch 代码无缝地移植到不同的硬件和软件平台，与不同的库和框架进行互操作，并感受 PyTorch 用户体验的丰富性，而不是最常见的子集。

Principle 2: Simple Over Easy

在这里，我们借用 The Zen of Python：

• 显式优于隐式

• 简单胜于复杂

描述这两个目标的更简洁的方式是 Simple Over Easy。让我们从一个例子开始，因为简单和容易在日常英语中经常互换使用。考虑如何在 PyTorch 中为 设备 建模：

• 简单/显式(对于理解、调试)： 每个张量都与设备相关。用户显式指定张量设备移动。需要跨设备移动的操作会导致错误。

• 容易/隐含（使用起来）： 用户不必担心设备；系统计算出全局最优的设备放置。

在这种特定的情况下，并且作为一种通用的设计哲学，PyTorch 倾向于暴露简单而明确的构建块，而不是容易被实践者使用的 API。PyTorch 新用户可以立即理解和调试简单版本：如果您在程序中实际调用运算符的位置调用需要跨设备移动的运算符，则会得到一个明显的错误。容易的解决方案可能会让新用户一开始移动得更快，但调试这样的系统可能很复杂：系统是如何做出决定的？插入这样的系统的 API 是什么？对象在其 IR 中是如何表示的？

支持这种设计的一些经典论点来自 A Note on Distributed Computation （TLDR：不对性能特性差异较大的资源进行统一建模，会泄露细节） and the End-to-End Principle （TLDR：在堆栈的低层构建智能可能会阻止在堆栈的高层开发高性能特性，而且通常不会起作用）。例如，我们可以构建运算符级或全局设备移动规则，然而精确的选择不够明显，构建可扩展的机制具有不可避免的复杂性和延迟成本。

这里需要注意的是，这并不意味着更高级的“简单” API 没有价值；当然，例如，堆栈中的更高级别支持基于大型集群中的异构计算体系进行高效张量计算是有价值的。相反，我们的意思是，关注简单的底层构建块有助于了解易用的 API，同时在用户需要摆脱常规时仍然保持良好的体验。它还为创新和更多自用工具提供了空间，其增长速度我们无法在 PyTorch 核心库中支持，但最终会从中受益，我们丰富的生态系统证明了这一点。换句话说，在一开始就不自动化可以让我们更快地达到良好的自动化水平。

Principle 3: Python First with Best In Class Language Interoperability

这一原则始于 Python First：

PyTorch 不是 Python 绑定到单一 C++框架中。它是为了与 Python 深度集成而构建的。您可以像使用 NumPy、SciPy、scikit-learn 或其他 Python 库一样自然地使用它。您可以使用 Python 自己编写新的神经网络层，使用 Cython 和 Numba 等软件包。我们的目标是在适当的情况下不重新发明轮子。

多年来，PyTorch 需要处理的一件事就是 Python 开销：我们首先在 C++中重新编写了 autograd 引擎，然后定义了大部分运算符，接着开发了 TorchScript 和 C++前端。

尽管如此，使用 Python 很容易为我们的用户提供最佳体验：它是灵活的、熟悉的，也许最重要的是，它有一个庞大的科学计算库和可供使用的扩展生态系统。这一事实激发了我们最近的一些贡献，这些贡献试图达到接近 Python 可用性曲线末端的帕累托最优点：

• TorchDynamo，一个 Python 框架评估工具，能够以最少的用户干预加速现有的动态图模式 PyTorch 程序。

• torch_function 和 torch_dispatch 扩展点， 它们使得 Python 首选功能可以在 C++内部库之上构建，如 torch.fx tracer 和 functorch。

这些设计原则并不是硬性规定，而是来之不易的选择，也是我们如何将 PyTorch 构建为当今可调试、可破解和灵活的框架的基础。随着我们有更多的贡献者和维护者，我们期待着在我们的库和生态系统中与您一起应用这些核心原则。随着我们学习新事物和人工智能领域的发展，我们也对它们的发展持开放态度，正如我们所知道的那样。