PyTorch为何如此受欢迎？创始人Soumith亲述成长秘

　　机器之心报道
　　编辑：杜伟、陈
　　众所周知，深度学习框架PyTorch的前身是Torch，从Torch发展到PyTorch，创建团队都做了哪些努力，又遇到了哪些挑战呢？在近日结束的JuliaCon2021活动中，PyTorch创始人SoumithChintala做了Keynote演讲，分享了一路走来的成长历程和经验教训。
　　PyTorch是深度学习领域最受欢迎的框架之一，初始版本于2016年9月由AdamPaszke、SamGross、SoumithChintala等人创建，并于2017年在GitHub上开源。PyTorch很简洁、易于使用、支持动态计算图而且内存使用很高效，因此越来越受开发者的喜爱。
　　7月28日30日，JuliaCon2021线上活动顺利召开。在7月30日的SingleTrack活动环节，活动主办方邀请到了FAIR研究工程师、深度学习框架PyTorch创建者之一SoumithChintala。目前，他的研究兴趣集中于计算机视觉、机器人和机器学习系统。
　　在他的Keynote演讲中，SoumithChintala回顾了自己从Torch发展至PyTorch的心路历程，以及对开源社区的看法。他从以下几个方面进行了阐述：理念原则范围风险度量指标项目的扩展
　　在正式进入到演讲主题之前，SoumithChintala阐述了他对开源项目的看法，表示大多数开源项目并不仅仅是从我们需要拥有1万名用户这种预期开始的。这种预期没有意义，开源之旅应该更纯粹并充满活力。
　　在开源领域，我们一开始是基于个人兴趣来做事情的。通常来讲，只有当很多人都对某些想法和项目感兴趣并愿意付出时间时，它们才会自然地成长。
　　此外，就开源项目的发展规律而言，大多数小型开源项目在经过足够的努力和参与后，都会考虑发展壮大。那时，项目参与者已经确定了他们的核心兴趣和理念，这也是技术和文化堆栈的基础。接下来，他们就会竭尽所能营销并扩展自己的开源项目。从Torch到PyTorch也遵循这一发展规律。
　　PyTorch的理念原则
　　当考虑一个项目时，它可能是以技术为中心的项目，比如对张量的理解，又比如以用户为中心（例如Torch7）的项目，它们传播的是易用性理念，而不关心什么技术或想法能让研究者更容易使用。
　　我在20102011年开始与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时代，我们学到了很多关于人们如何喜欢度量事物。例如微基准、GitHubstar量、特征对比表等。当人们在社区发布了一些这样的度量和比较之后，我们不赞同其中的一些测量。但是我们从Torch中得到经验是过早地度量会对产品造成负面影响。尽管我们并没有把度量Torch的博客文章写给竞争对手，但我们一直在努力优化这些度量结果，并对它们做出反应，而不是专注于其他更重要的用户优先事项。
　　所以，当我们编写PyTorch时，需要明白两件事：第一，我们的核心竞争力不是像速度或其他数据那样可以度量的东西，而是我们需要向流畅的用户体验迈进，将灵活性、API设计和可调试性作为首要任务；其次，我们相信，如果我们不对PyTorch的外部度量做出反应，我们就可以专注于我们所关心的东西，即使这会造成短期的变动。
　　因此，在PyTorch的发展过程中，我们从未对速度基准或者GitHubstar量等不相关的度量指标做出回应。作为PyTorch的创建者，我们从未提交至MLPerf等行业基准。这是经过深思熟虑的，我们对此做法感到满意。在做PyTorch相关的演讲时，常碰到有人问：与X相比，PyTorch的速度有多快？即使我知道PyTorch在给定用例上能够达到相同甚至更快的速度，但我只会这样回答：PyTorch更灵活，试试吧。这使得我们专注于自己的核心竞争力。
　　我们勉强依赖的指标是开发者是否在使用PyTorch以及竞品框架的使用情况。我们倚重的指标不是GitHubstar量或者微基准上的性能等，而是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个小时，每时每刻都筋疲力尽，但实际上并没有做太多事情。因此，我想直接将这些繁琐的工作交给其他更尽力且做得更好的人，这样我就解脱了。
　　之后，我的同事EdwardYang拥有我没有的超能力，他接管了整个工作流程，并打算先进行观察，然后再创建了一个更好的扩展流程。2021年1月，他撰写了一篇精彩的博客文章《ThePyTorchPpenSourceProcess》。我从他做这些事情中学到了一点，即当你达到一定的规模，就无法顾全所有事情，必须有明确的优先级。
　　博客地址：http：blog。ezyang。com202101pytorchopensourceprocess
　　在项目规模上需要考虑的另外一件事情是进行垂直整合还是水平整合。在PyTorch项目上，我们集成了distributed、jit和quantization包，这些包需要更深的垂直集成，因为它们与前端设计具有很深的交集。我们还将torchvision或torchserve等包分支到了各自的GitHub库中，因为它们不需要很多的端到端思考。
　　最后想谈一谈生态系统的问题。从PyTorch开始，我们希望开发者使用PyTorch并向该项目做出贡献，由此发展社区。在整个过程中，我们竭力避免任何形式的激励措施。因此，在很长一段时间里，我们没有提供任何奖品、奖金或其他经济奖励措施来鼓励研究者使用PyTorch。我们的观点是，一旦引入经济激励措施，就会以一种不可逆转的方式塑造社区文化。
　　截止2020年底，PyTorch项目的贡献者大约1626人、下游项目45k个，PyTorch论坛用户达到了34k。
　　即使是现在，即使我们的项目有了更多预算，但是除了每年一两次的黑客马拉松比赛，我们并不会在这方面投入太多。我们非常关心的另一个激励因素是为其他人提供更大的发展空间，而不是自己包办一切。我们会着力帮助社区成长，并首先填补一些空白，只有当没人能够满足一些需求时，我们才会介入并自上而下投入时间和精力解决问题。
　　参考链接：
　　https：soumith。chposts202102growingopensource