PyTorch 创建者 Soumith Chintala：我们是如何将 PyTorch 社区搞起来的？

本文是作者 Soumith Chintala 在 8 月初 JuliaCon 上演讲的精编版。

引言

大多数开源项目的起点并不是“我们需要吸引 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 研究人员市场做出了经过深思熟虑的预判，我们认为：

• 他们在未来几年所做的建模需要更多的灵活性和可调试性

• ML 研究人员市场将继续追求更疯狂的模型架构，这会是未来的主旋律

根据这样的预测，我们需要一个非常广泛的 API，并提供出色的用户体验来帮助大家真正轻松地使用和扩展它。我们下的这个赌注可能有一百万种落空的理由，因为机器学习社区的未来可能是另一种样貌。例如，假设未来十年我们可能停止在 ResNets 上创新的脚步，那么人们对广泛而大型的 API 的需求也就会随之消失——这样的未来将需要一个更垂直专注于 ResNets 的库。

在我的这次演讲中，你可以听到更多我对这个话题的看法，以及我对未来 ML 框架的看法。

测量/指标

除了我们的核心原则和范围外，我们还希望与客户建立一个反馈循环，这是产品开发中所需的标准操作。然后我们问自己了一个问题，那就是我们想要如何跟踪 PyTorch 的各个维度：

• 它们是否可测量

• 它们是否可以很好地测量？

• 你应该测量它们吗？

• 你如何处理不可测量的区域？处理方法如何扩展？

在我们的 Torch 时代，我们看到了人们都非常喜欢测量各种事物，而且都特别喜欢对比各种测量结果。微基准测试、github 星星数量、特性对比表等等都是例子。

人们在社区发布了一些测量结果和对比分析之后，我们觉得其中一些结果对我们是不公平的，并且对此感到很生气。但是我们从 Torch 的经验中意识到的更重要一点是，过早地测量某些东西会将产品引导向不正确的方向。尽管我们没有把 Torch 的测试结果写在博文里公开给竞争对手，但我们一直在努力优化这些指标并对其作出反应，而不是专注于其他对用户更重要的层面上。

因此当我们开始编写 PyTorch 时，我们在两件事情上明确了态度。第一，我们的核心能力不是像速度或其他一些统计数据那样可衡量的东西，但我们需要追求一种将灵活性、API 设计和可调试性作为最优先事项的黄油般流畅的用户体验。没有什么好的方法可以测量这一点，我们必须真正适应这种模糊的局面，并且能够主观地不断重新评估那些体现我们工作水平的内部信号。其次，我们相信，如果我们不对 PyTorch 的外部测量结果做出反应，就可以专注于我们真正关心的事情——即使这种态度会造成短期的用户流失。

因此，在 PyTorch 的历史中，我们从未对速度基准测试或不相关的测量标准（例如 github 星数）作出回应。作为 PyTorch 的作者，我们还没有把项目提交给那些行业基准测试，例如 MLPerf。这是我们有意为之的结果，我们对这种方法也非常满意。当我发表 PyTorch 演讲时，经常有人会问：“与 X 相比，你的速度有多快？”。即使我知道我们在某些用例上和竞品一样快甚至更快，我也会简单地回避这个问题——“我们更灵活，我们跟竞品的性能差距可能还不到 10%，所以试试我们的东西吧”。这给了我们惊人的力量——专注于我们的核心竞争力，而不会被拖进那种与我们重视的价值毫无关联的争论之中。

我们所参考的指标是 PyTorch 的采用率，以及它和竞品的采用率对比。这里我们看的不是收藏率（例如 github 星数）或微基准测试的性能表现——而是有多少人在实际用它编写代码。因此，我们使用了 Github 的全局代码搜索（针对 import torch 之类的东西）和 arxiv 引用等指标，它们可以更准确地反映有多少人在使用这款产品，而且不会有歧义。

然而，问题在于这些指标是滞后的。我们根本不能依靠它们来实时了解我们社区的需求，因为它们的更新周期很长，大约 6 个月。

我们也没有尝试使用指标来近似测量用户的整体体验，以及他们对可调试性和 API 易用性等方面的感受。但我们确实主观地衡量了它们......

在较小的范围内，我们所做的事情基本上就是让我来阅读我们社区产生的全部信息——github 问题、论坛帖子、slack 消息、推特帖子、reddit 和 hackernews 评论，等等。它们都是非常有用的信号——是的，有很多噪音，但也有很多有用的信息。它帮助我们很好地确定了优先级，我认为这是通过主观领域塑造产品的好方法。除了我之外，几乎所有的核心开发者都花了很多时间与用户互动，因此我们在非常模糊和主观的方面有很深的共识。然而，这种方法到了一定程度就没法继续扩展下去了

扩展

随着我们的扩展，我认为 PyTorch 再发展不到 2 年，我继续这么做下去就会达到物理/人类的极限。我每天会在 twitter/Reddit/HN 上浏览大约 500 个 github 通知、50 多个论坛帖子、大量的 slack 活动和许多互动。我每天工作 15 个小时，精力耗尽但实际上没有做太多其他事情。我一开始想到的解决方案显然是把这项工作推给别人，希望他们工作得更努力、更好，让我可以轻松一下。

这显然是行不通的。我的同事 Edward Yang 比我厉害多了，他接管了这个流程，然后首先观察了一番，再建立了一个更好的流程来扩展它。他写了一篇精彩的博客文章，总结了他在这方面所做的事情。我从他的做事方法中学到的很好一课是，一旦你达到了一定的规模，你就不能指望做完所有事情。你必须高度重视优先级，没有其他办法，不过这没关系。无法关闭每一个 github 问题并不是什么大不了的事情。

在扩展问题上要考虑的另一件事是选择垂直整合还是水平整合。2009 年，AMD 将他们的晶圆厂部门分拆成了一家独立的公司。那个时候我觉得这太难理解了。几年后我读到一篇文章，作者认为 AMD 这样做是因为晶圆厂（后端）与设计师（前端）的合作不顺利，那种垂直整合弊大于利。相比之下，苹果的 M1 处理器及其神奇的实际性能表现归功于令人难以置信的出色垂直整合能力，软件团队能够衡量苹果软件生态系统中的瓶颈，并找到需要加速的关键底层操作，这些信息会一直传达到硬件设计层面。我不知道这两种理论是否正确，但我确实认为垂直整合做得不好会带来一份巨大的开销，但做得好就会是一个强大的力量倍增器——所以请明智地选择你要走的路线。在 PyTorch 上，我们垂直集成了 distributed、jit 和 quantization 等包，这些包需要更深入的垂直集成，因为它们与前端设计有很大的交集。我们将诸如 torchvision 或 torchserve 之类的包分支到了它们自己的 github 存储库中，因为它们不需要那么多端到端的思考。在这个问题上，我认为围绕垂直与水平整合的决策也严重依赖于构建这些东西的人们之间的有效带宽——他们是否在同一家公司内，是否在同一时区或物理空间，或者他们是否主要使用异步长文通信格式来交流——所有这些都决定了垂直整合是否可以有效推行下去。

我想谈论的另一个关于扩展的话题是，你不仅要发展自身，还要发展你的生态系统。正确的激励措施是很重要的。从 PyTorch 开始，我们就希望根据人们使用 PyTorch 或为 PyTorch 做出贡献时所感兴趣、希望发展成产品的内容来规划社区的发展路线。我们努力排除掉了其他类型的激励措施。因此在很长一段时间内，我们没有提供任何奖品、赏金或其他经济激励措施来鼓励人们使用 PyTorch。我们的观点是，一旦你引入经济激励措施，就会以不可逆转的方式塑造你社区的文化。即使是现在，除了一年一两次黑客马拉松外，我们都会尽量避免这种方式，即便我们有了足够的预算也不行。我们非常在意的另一种激励措施是确保我们为他人提供成长的空间，而不是自己包办一切。我们会尽量帮助社区成长，引导社区去填补各种空白，只有在没有人能满足需求的情况下，我们才会踏足其中并自上而下地进行这些投资。

结语

这次演讲是为了告诉大家一些来自 PyTorch 团队、项目和我个人旅程的轶事和故事。我希望将它们与你在构建和发展开源项目（无论项目是否属于 Julia 领域）时所考虑的四个有用维度联系起来。我希望这些内容可以对你有所帮助，如果你有任何反馈，请给我发电子邮件。

原文链接：https://soumith.ch/posts/2021/02/growing-opensource/