将开源从 Torch 发展到 PyTorch

注意：我没有在 JuliaCon 上介绍这个演讲大纲的一些内容，并在其他部分即兴创作，因此视频不匹配或涵盖这里写的所有内容。据我所知，Julia 社区邀请来自相邻开源社区的人们发表主题演讲，向他们学习。因此，在我的主题演讲中，我试图介绍我通过 Torch 和 PyTorch 的旅程。大多数开源项目并不仅仅从“我们需要拥有 1 万用户”开始。那只是没有意义，而且通过开源的旅程更加有机。我们从一开始——尤其是在开源方面——是做一些符合个人兴趣的事情。通常，我们试图将它与更广泛的兴趣或需要的东西相交。这里的做市有点自我实现的预言。只有当许多想要共度时光的人都感兴趣时，想法和项目才会自然地成长。有极少数例外，例如大型公司推出具有庞大营销计划的自上而下的产品，但这并不是我在这里真正想谈论的内容。大多数小型开源项目，经过足够的努力和参与后，都会考虑增长。那时，他们已经确定了他们的核心兴趣和理念，这是他们技术和文化堆栈的基础。接下来，他们想知道他们是否正在尽其所能来销售、营销和发展这个项目。在本说明中，我将讨论四个方面，这些方面对于您从项目的这个阶段成长时有意勾勒出的轮廓非常有用。我通过从 Torch 到 PyTorch 的故事讲述了这些方面：当我们考虑一个项目时，它可能是一个以技术为中心的项目，比如试图传播多面体优化思想的 Tensor Comprehensions，或者一个以用户为中心的项目像 Torch-7 这样的项目，它传播易于使用的想法，而不关心哪些技术或想法让您易于使用。

我于 2010/2011 年开始使用 Torch。随着时间的推移，我在 Torch 社区交了朋友，我理解了他们作为一个整体所代表的隐含原则。开源，就像政治一样，在关系和原则方面可能相当不明确——不是每个人都代表同一件事。因此，多年来，我吸收并欣赏 Torch 是一款以用户为中心的产品，它代表着即时模式、易于调试、不碍事的明确性。它针对的是对编程问题有些熟悉的人，他们可以对性能等事情进行推理，如果需要，可以编写一个 C 函数并快速绑定它。当我们编写 PyTorch 时，我意识到在一个有机的开源社区中，并不是每个人都代表相同的原则。我们在 Torch 社区中有几个非常重要的成员反对 Python，尽管我们以用户为中心的观点允许我们朝着这个方向前进。然后，我们必须做出决定是带他们走还是留下他们。这些都是艰难的决定，因为没有正确的答案，只有作为领导者必须迅速做出的主观判断。在这种情况下，通常值得思考什么时候保持坚强，什么时候妥协。我的观点是，你必须对你所驾驶的原则/哲学非常固执，但其他一切都是可变的。这种观点对带动人们非常有用。随着时间的推移，PyTorch 带来并整合了 Caffe2 社区和 Chainer 社区，并自 Jax 和 Swift4TF 成立以来一直保持友好。带上其他人有巨大的优势。社区变得更大，你可以说得到更广阔的视野，随着时间的推移，使项目变得更好和更广泛。如果你对你的核心原则固执己见，你并没有真正妥协你最初的愿景，只是严格地让它变得更好。除了推动 Torch 社区发展的挑战之外，我们面临的第二件事是我们当时最强大的竞争对手——TensorFlow 据说拥有 10 到 30 倍的开发人员。不过，对我们来说真正的好处是，TensorFlow 正在努力为每个人提供一切。从我们的知名度来看，这是一个自上而下计划的项目，拥有大量资源和广度。因此，我们自然而然地尝试采取完全相反的方法，主要是为了生存并在现实条件下竞争。我们决定除了 ML 研究人员之外，我们不会专注于任何人，让他们的生活变得非常美好。这样，我们就可以保持专注并以更少的资源交付。我们故意缩小范围，因此承担了更多的垂直风险，但减少了水平风险。我们只是想锁定我们的目标市场。

然而，一旦我们使用 PyTorch 在该市场取得成功，我们的野心就会越来越大。随着我们的成长和成熟，我们慢慢地、渐进地扩大了我们的范围和雄心。这接近缩放。在这里，我还想谈谈你所承担风险的故意性质以及它如何塑造你的命运。他们在未来几年所做的建模将需要更大的灵活性和可调试性 ML 研究人员市场将继续在更疯狂的模型架构上进行创新，并且它将成为未来的主流 因此，有了这个赌注，我们需要一个非常广泛的 API 和用户- 有助于轻松使用和扩展该 API 的经验。基于机器学习社区如何塑造它的未来，我们做出的这个赌注可能因数百万个原因而失败。例如，假设我们可能在十年内停止在 ResNets 上进行创新，这将使对广泛而大型 API 的需求变得过时——而未来将需要一个更垂直地专注于 ResNets 的库。在我的演讲中，您可以听到更多我对这个话题的看法，以及我对未来 ML 框架的看法。除了我们的核心原则和范围外，我们还希望与客户建立反馈循环，这是产品开发中的标准操作需求。然后，我们问自己我们想如何跟踪 PyTorch 的各个维度：

在我们的 Torch 时代，我们学到了很多关于人们如何喜欢测量事物，以及其他人如何喜欢将测量的比较视为福音。比如微基准测试，github star增长，特征对比表等等。在社区发布了一些这样的测量和对比之后，我们对其中的一些测量感到委屈，对他们感到恼火。但是我们从 Torch 的经验中得到的更大的认识是问自己过早地测量某些东西如何以一种糟糕的方式塑造了产品。尽管我们没有将测量 Torch 的博文写给竞争对手，但我们一直在努力优化这些测量并对其做出反应，而不是专注于其他更重要的用户优先级。因此，当我们编写 PyTorch 时，我们很清楚两件事。第一，我们的核心能力不是像速度或其他一些统计数据那样可衡量的东西，但我们需要朝着一种将灵活性、API 设计和可调试性作为重中之重的黄油般流畅的用户体验迈进。没有什么好的方法可以衡量这一点，我们必须真正适应这种模糊性，并且能够主观地不断重新评估我们是否能够做好工作的内部信号。其次，我们相信，如果我们不对 PyTorch 的外部测量做出反应，我们就可以专注于我们关心的事情——即使这会造成短期流失。所以，在 PyTorch 的历史上，我们从来没有对速度基准或不相关的衡量标准（如 github 星数）做出回应。作为 PyTorch 的作者，我们还没有提交给行业基准测试，例如 MLPerf。这是非常深思熟虑的，我们对我们的方法非常满意和满意。当我进行 PyTorch 演讲时，通常有人会问：“与 X 相比，你的速度有多快？”。即使我知道我们在给定用例上的速度和速度一样快或更快，我也会简单地回避这个问题——“我们更灵活，我们可能在其他地方的性能不到 10%，试试我们”。这给了我们令人难以置信的超能力——专注于我们的核心竞争力，而不会被拖入我们所认为的对我们产品的简化看法——一种根本不重视我们的优势的观点。我们勉强依赖的指标是人们是否在使用 PyTorch 以及它与我们的竞争对手的相对使用。不是衡量书签（如 github 星）或微基准性能的指标——而是实际在其中编写代码。因此，我们使用了 Github 的全局代码搜索（用于导入火炬和其他东西）和 arxiv 引用等指标，它们更准确地描述了是否有人真正使用了我们，没有歧义。然而，问题在于这些是滞后的指标。我们根本不能依靠他们来了解我们社区的即时需求，因为他们的交货时间很长，大约 6 个月。我们也没有使用指标来尝试近似用户对其整体体验的感受，以及可调试性和 API 易用性等方面。但我们确实主观地衡量了它们......

在较小的范围内，我们所做的基本上是让我阅读我们社区产生的全部信息——github 问题、论坛帖子、slack 消息、推特帖子、reddit 和hackernews 评论。这是非常有用的信号——是的，有很多噪音，但也有很多信号。它帮助我们很好地确定了优先级，我认为这是通过主观领域塑造我们产品的好方法。除了我之外，几乎所有的核心开发者都花了很多时间与我们的用户互动，因此我们通过非常模糊和主观的方面有大量的共同理解。然而，这种方法并没有超出一点。随着我们的扩展，我认为在 PyTorch 的 2 年内，我已经达到了每天这样做的物理/人类极限。我在 twitter/Reddit/HN 上浏览了大约 500 个 github 通知、大约 50 多个论坛帖子、大量的松弛活动和许多参与。我想我每天工作 15 个小时，只是一直筋疲力尽，实际上没有做太多其他事情。我的直接想法显然是把它典当给其他人，即他们工作得更努力、更好，我可以缓解我的倦怠。这显然行不通。我的同事 Edward Yang 拥有我没有的超能力，他接管了这个过程，目的是首先观察它，然后构建一个更好的过程来扩展它。他写了一篇精彩的博客文章，总结了他在这里所做的事情。我从看着他做这件事中得到的一个很好的认识是，一旦你达到了一定的规模，你就不能瞄准做所有事情，你必须高度重视优先级，没有其他办法，这没关系。不能关闭每个 github 问题并不会让你变得残忍。在规模上要考虑的另一件事是您是垂直整合还是水平整合。 2009 年，AMD 将他们的晶圆厂部门分拆成一家独立的公司。那个时候，我觉得这太难理解了。几年后，我读到一篇文章，该文章认为 AMD 这样做是因为晶圆厂（后端）与设计师（前端）的合作不佳，而且那里的垂直整合弊大于利。相比之下，Apple 的 M1 处理器及其神奇的快速实用速度归功于令人难以置信的良好垂直扩展，软件团队能够衡量 Apple 软件生态系统中的瓶颈，并找到需要加速的关键低级操作，并且该信号一直转换到硬件设计。我不知道这两种理论是否正确，但我确实相信垂直整合做得不好是一个巨大的开销，做得好是一个巨大的力量倍增器——所以明智地选择你要走的路。在 PyTorch 上，我们垂直集成了分布式、jit 和量化等包，这些包需要更深入的垂直集成，因为它们与前端设计有很大的交集。我们将诸如 torchvision 或 torchserve 之类的软件包分支到他们自己的 github 存储库中，因为它们不需要那么多端到端的思考。在这里，我认为围绕纵向与横向整合的决策也严重依赖于构建这些东西的人之间的有效带宽——无论他们在同一家公司内，是否在同一时区或物理空间，或者他们是否主要在交谈通过长格式异步通信——所有这些都定义了垂直整合是否可以有效执行。我想谈论的另一个关于扩展的话题是不仅要发展你自己，还要发展你的生态系统。正确的激励措施很重要——很多。从 PyTorch 开始，我们就希望根据人们是否有兴趣使用 PyTorch 或为 PyTorch 做出贡献，因为他们喜欢将其作为产品来发展社区。我们非常努力地消除其他类型的激励措施。因此，在很长一段时间内，我们没有提供任何奖品、赏金或其他经济激励措施来让人们使用 PyTorch。我们的观点是，一旦您引入经济激励措施，就会以不可逆转的方式塑造您社区的文化。即使是现在，除了一年一两次黑客马拉松，我们努力不按这个按钮太多，即使我们作为一个项目有更大的预算并且我们可以。我们非常关心的另一个激励是确保我们为他人提供成长的空间，而不是为自己包办一切。我们关心帮助社区成长并首先填补空白，只有在没有人满足需求的情况下，我们才会故意进入并自上而下地进行这些投资。我的目标是告诉你一些来自 PyTorch 团队、项目和我个人旅程的轶事和故事。我希望将它们与您在构建和发展开源项目时所考虑的四个有用维度联系起来，无论是在 Julia 领域还是其他地方。我希望这是有用的，如果您有任何反馈，请给我发电子邮件。