编辑：杜伟、陈
众所周知，深度学习框架 PyTorch 的前身是 Torch，从 Torch 发展到 PyTorch，创建团队都做了哪些努力，又碰着了哪些寻衅呢？在近日结束的 JuliaCon 2021 活动中，PyTorch 创始人 Soumith Chintala 做了 Keynote 演讲，分享了一起走来的发展进程和履历教训。
PyTorch 是深度学习领域最受欢迎的框架之一，初始版本于 2016 年 9 月由 Adam Paszke、Sam Gross、Soumith Chintala 等人创建，并于 2017 年在 GitHub 上开源。PyTorch 很简洁、易于利用、支持动态打算图而且内存利用很高效，因此越来越受开拓者的喜好。
（图片来自网络侵删）7 月 28 日 - 30 日，JuliaCon 2021 线上活动顺利召开。在 7 月 30 日的 Single Track 活动环节，活动主理方约请到了 FAIR 研究工程师、深度学习框架 PyTorch 创建者之一 Soumith Chintala。目前，他的研究兴趣集中于打算机视觉、机器人和机器学习系统。
在他的 Keynote 演讲中，Soumith Chintala 回顾了自己从 Torch 发展至 PyTorch 的心途经程，以及对开源社区的意见。他从以下几个方面进行了阐述：
理念原则范围 & 风险度量指标项目的扩展在正式进入到演讲主题之前，Soumith Chintala 阐述了他对开源项目的意见，表示大多数开源项目并不仅仅是从「我们须要拥有 1 万名用户」这种预期开始的。这种预期没故意义，开源之旅该当更纯粹并充满活力。
在开源领域，我们一开始是基于个人兴趣来干工作的。常日来讲，只有当很多人都对某些想法和项目感兴趣并乐意付出韶光时，它们才会自然地发展。
此外，就开源项目的发展规律而言，大多数小型开源项目在经由足够的努力和参与后，都会考虑发展壮大。那时，项目参与者已经确定了他们的核心兴趣和理念，这也是技能和文化堆栈的根本。接下来，他们就会竭尽所能营销并扩展自己的开源项目。从 Torch 到 PyTorch 也遵照这一发展规律。
PyTorch 的理念 & 原则
当考虑一个项目时，它可能因此技能为中央的项目，比如对张量的理解，又比如以用户为中央（例如 Torch-7）的项目，它们传播的是易用性理念，而不关心什么技能或想法能让研究者更随意马虎利用。
我在 2010/2011 年开始与 Torch 互助，并在 Torch 社区交了许多朋友，理解了他们作为一个整体所代表的隐含原则，和政治一样，开源在关系和原则上的定义是相称模糊的。
因此，多年来，我逐渐理解并欣赏到 Torch 是一款以用户为中央的产品，它具有即时模式、易于调试、不受影响等特性。Torch 的目标用户是一些熟习编程的人，这些用户能够理解性能等问题，可以根据事情须要，他们能够编写一个 C 函数并快速地将其绑定进去。
当我们编写 PyTorch 程序时，我意识到在一个有机的开源社区中，并不是每个人都支持相同的原则。我们在 Torch 社区中有一些非常主要的成员反对 Python，只管我们以用户为中央的不雅观点许可我们朝着这个方向提高。然后，我们必须做出决定是带他们一起发展还是把他们留下。这些都是困难的决定，由于没有精确的答案，只能领导者必须迅速做出的主不雅观判断。
在这种情形下该当思考什么时候保持固执，什么时候保持妥协。我的不雅观点是，你必选在理念、原则上保持固执，但其他统统都是可以改变的。
这一不雅观点非常有用，随着韶光的推移，PyTorch 带来并集成了 Caffe2 社区和 Chainer 社区，并与 Jax 和 Swift4TF 保持友好关系。PyTorch 社区变得越来越大，在这个社区中你可以得到更广阔的视角，随着韶光的推移，这些视角会使项目变得越来越好。如果你坚持自己的核心原则，你就不会真的在你最初的愿景上妥协，只会让它变得更好。
PyTorch 的范围 & 风险
推动 Torch 社区发展是一个寻衅，除此以外，面临的另一个寻衅是 TensorFlow ，据理解 TensorFlow 拥有比 PyTorch 多 10 到 30 倍的开拓职员。不过，TensorFlow 正在努力为所有人供应便利，这对 PyTorch 研究者来说是非常有益的。此外，TensorFlow 是一个自上而下操持的项目，须要大量的资源。
以是，我们很自然地采纳了完备相反的方法，紧张是为了在现实的条件下生存和竞争。我们决定，除了 ML 研究职员，我们不关注任何人。这样，我们就可以集中精力，用更少的资源完成任务。我们故意缩小范围，因此承担了更多的垂直风险，但同时减少了水平风险。我们只是想确定我们的潜在市场。
然而，一旦我们用 PyTorch 在该市场取获胜利，我们的野心就变大了。随着我们的发展和成熟，我们渐进地扩大了范围和抱负，这靠近于规模化。
在这里，先容一下须要承担的风险，以及它的影响。我们在 ML 研究市场上做了一个赌注：
他们在未来几年所做的建模将须要更多的灵巧性和可调试性；ML 研究市场将连续在更前辈的模型架构上进行创新，它将成为未来的主流。因此，有了这个赌注，我们须要一个非常广泛的 API 结合用户体验，以真正轻松地利用和扩展该 API。基于 ML 社区如何塑造它的未来，我们所做的这个赌注可能无法实现，缘故原由有很多。
在我的演讲中，你可以听到我对这个主题的更多意见，以及我对未来 ML 框架的意见。
PyTorch 的度量指标
除了核心原则和范围外，我们还希望与客户建立反馈回路，这是产品开拓的标准操作需求。然后，我们从不同维度对如何跟踪 PyTorch 进行了总结：
它们是可度量的吗？是否可以很好的进行度量？你该当度量吗？如何处理不可度量的区域？在我们的 Torch 时期，我们学到了很多关于人们如何喜好度量事物。例如微基准、GitHub star 量、特色比拟表等。当人们在社区发布了一些这样的度量和比较之后，我们不赞许个中的一些丈量。但是我们从 Torch 中得到履历是过早地度量会对产品造成负面影响。只管我们并没有把度量 Torch 的博客文章写给竞争对手，但我们一贯在努力优化这些度量结果，并对它们做出反应，而不是专注于其他更主要的用户优先事变。
以是，当我们编写 PyTorch 时，须要明白两件事：第一，我们的核心竞争力不是像速率或其他数据那样可以度量的东西，而是我们须要向流畅的用户体验迈进，将灵巧性、API 设计和可调试性作为紧张任务；其次，我们相信，如果我们不对 PyTorch 的外部度量做出反应，我们就可以专注于我们所关心的东西，纵然这会造成短期的变动。
因此，在 PyTorch 的发展过程中，我们从未对速率基准或者 GitHub star 量等不干系的度量指标做出回应。作为 PyTorch 的创建者，我们从未提交至 MLPerf 等行业基准。这是经由寻思熟虑的，我们对此做法感到满意。在做 PyTorch 干系的演讲时，常碰到有人问：「与 X 比较，PyTorch 的速率有多快？」纵然我知道 PyTorch 在给定用例上能够达到相同乃至更快的速率，但我只会这样回答：「PyTorch 更灵巧，试试吧。」这使得我们专注于自己的核心竞争力。
我们勉强依赖的指标是开拓者是否在利用 PyTorch 以及竞品框架的利用情形。我们倚重的指标不是 GitHub star 量或者微基准上的性能等，而是 PyTorch 实际编写代码的体验。以是，我们采取的度量指标有 GitHub 的全局代码搜索和 arXiv 引用等，这种做法更准确地获知开拓者是否利用 PyTorch。
我们勉强依赖的指标是开拓者是否在利用 PyTorch 以及它与我们的竞争对手的相对利用。不是衡量书签（如 github 星）或微基准性能的指标——而是实际在个中编写代码。因此，我们利用了 Github 的全局代码搜索（用于导入 torch 和其他东西）和 arxiv 引用等指标，它们可以更准确地描述是否有人真正利用过我们，没有歧义。
然而，问题在于这些是滞后的指标。我们根本不能依赖它们来理解社区的即时需求，由于交付周期很长，大约为 6 个月。
我们也没有利用指标来考试测验近似用户对其整体体验以及可调试性和 API 易用性等方面的感想熏染，但确实从主不雅观上衡量了这些方法…
在较小的范围内，我所做的基本上是阅读社区产生的全部信息，比如 GitHub 问题、论坛帖子、slack 、twitter 帖子以及 reddit 和 hackernews 评论等。这些都是非常有用的旗子暗记，虽然也充斥着很多不和谐的声音，但也可以从中理解用户的一些想法。这些指标帮助我们很好地确定了优先级，并且我认为这是从主不雅观层面塑造自身产品的好方法。
除了我之外，险些所有的核心开拓者都花了很多韶光与用户进行互动，因此我们从非常模糊和主不雅观的视角达成了大量的共同理解。然而，这种方法并没有超出一个点。
PyTorch 的扩展
随着项目的扩展，我认为在 PyTorch 推出的两年韶光里，自己每天的事情已经达到了人体极限。我要在 twitter、Reddit 和 Hacenews 上浏览 500 条旁边的 GitHub 关照、50 篇旁边的论坛帖子、大量的 slack 活动和很多其他的参与。我以为自己每天事情 15 个小时，每时每刻都筋疲力尽，但实际上并没有做太多事情。因此，我想直接将这些繁琐的事情交给其他更尽力且做得更好的人，这样我就解脱了。
之后，我的同事 Edward Yang 拥有我没有的超能力，他接管了全体事情流程，并打算前辈行不雅观察，然后再创建了一个更好的扩展流程。2021 年 1 月，他撰写了一篇精彩的博客文章《The PyTorch Ppen Source Process》。我从他做这些事情中学到了一点，即当你达到一定的规模，就无法顾全所有事情，必须有明确的优先级。
博客地址：http://blog.ezyang.com/2021/01/pytorch-open-source-process/
在项目规模上须要考虑的其余一件事情是进行垂直整合还是水平整合。在 PyTorch 项目上，我们集成了 distributed、jit 和 quantization 包，这些包须要更深的垂直集成，由于它们与前端设计具有很深的交集。我们还将 torchvision 或 torchserve 等包分支到了各自的 GitHub 库中，由于它们不须要很多的端到端思考。
末了想谈一谈生态系统的问题。从 PyTorch 开始，我们希望开拓者利用 PyTorch 并向该项目做出贡献，由此发展社区。在全体过程中，我们竭力避免任何形式的勉励方法。因此，在很长一段韶光里，我们没有供应任何奖品、奖金或其他经济褒奖方法来鼓励研究者利用 PyTorch。我们的不雅观点是，一旦引入经济勉励方法，就会以一种不可逆转的办法塑造社区文化。
截止 2020 年底，PyTorch 项目的贡献者大约 1626 人、下贱项目 45k + 个，PyTorch 论坛用户达到了 34k。
纵然是现在，纵然我们的项目有了更多预算，但是除了每年一两次的黑客马拉松比赛，我们并不会在这方面投入太多。我们非常关心的另一个勉励成分是为其他人供应更大的发展空间，而不是自己包办统统。我们会着力帮助社区发展，并首先补充一些空缺，只有当没人能够知足一些需求时，我们才会参与并自上而下投入韶光和精力办理问题。
参考链接：
https://soumith.ch/posts/2021/02/growing-opensource/
