PyTorch是深度学习领域最流行的框架之一。初始版本由AdamPaszke、SamGross、SoumithChintala等人于2016年9月创建。在GitHub上开源。PyTorch非常简洁、易用、支持动态计算图、内存效率高，因此越来越受到开发者的青睐。7月28日-30日，JuliaCon2021线上活动圆满举行。在7月30日的SingleTrack活动中，活动的组织者邀请了FAIR的研究工程师、深度学习框架PyTorch的创建者之一SoumithChintala。目前，他的研究兴趣集中在计算机视觉、机器人和机器学习系统。SoumithChintala在他的Keynote演讲中回顾了他从Torch到PyTorch的历程，以及他对开源社区的看法。他从以下几个方面进行了阐述：哲学原则Scope&RiskMetricProjectExpansionWeneedtohave10,000users”，期待开始了。这种期待是没有意义的，开源之旅应该更纯粹，更充满活力。在开源中，我们都是从个人兴趣开始做事的。一般来说，只有很多人有兴趣，愿意付出时间，想法和项目才会自然成长。另外，从开源项目的发展规律来看，大多数小开源源项目在足够的努力和参与之后，才会考虑成长。到那时，项目参与者已经确定了自己的核心兴趣和理念，这也是技术和文化堆栈的基础。接下来，他们将竭尽全力进行营销和扩大开放sourceprojects.从Torch到PyTorch也遵循这个发展规律.PyTorch'sPhilosophy&PrinciplesWhenconsideringaproject,itcouldb以技术为中心，例如理解张量，或以用户为中心（例如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星数、特性比较表等。虽然人们已经在社区中发布了其中一些指标和比较，但我们不同意其中的一些。但我们使用Torch的经验是，过早的测量会对产品产生负面影响。尽管我们不会向竞争对手撰写衡量Torch的博客文章，但我们一直在努力优化这些指标并对其做出反应，而不是专注于其他更重要的用户优先事项。所以，当我们写PyTorch的时候，我们需要明白两件事：第一，我们的核心竞争力不是像速度或其他数据那样可以衡量的东西，而是我们需要朝着流畅的用户体验迈进，结合灵活性、API设计和可调试性作为首要任务;其次，我们相信，如果我们不对PyTorch的外部指标做出反应，我们就可以专注于我们关心的事情，即使它会造成短期变化。因此，在PyTorch的开发过程中，我们从不响应速度基准或GitHub星级等无关指标。作为PyTorch的创造者，我们从未提交过MLPerf等行业基准。这是故意的，我们对这种方法感到满意。在进行与PyTorch相关的演讲时，经常有人问我：“与X相比，PyTorch有多快？”即使我知道PyTorch对于给定的用例可以达到相同的速度甚至更快，我也只会这样回答它：“PyTorch更灵活，试试看。”这使我们能够专注于我们的核心竞争力。我们依赖的指标是开发人员是否在使用PyTorch以及竞争框架的使用情况。我们依赖的指标不是GitHub星级或微基准测试的性能，而是在PyTorch中实际编写代码的经验。因此，我们使用的指标包括GitHub的全局代码搜索和arXiv引用等。这种方法更准确地告知开发者是否使用PyTorch。我们依赖的指标是开发人员是否在使用PyTorch及其相对于我们竞争对手的使用情况。不是书签（如githubstars）或微基准测试性能的指标-但实际上是在其中编写代码。因此，我们使用Github的全球代码搜索（用于导入火炬和东西）和arxiv引用等指标，这些指标可以更准确地说明是否有人真正使用过我们，没有歧义。然而，问题在于这些都是滞后指标。由于大约6个月的漫长交付周期，我们根本不能依靠他们来了解社区的即时需求。我们也没有使用指标来尝试估计用户对他们的整体体验以及可调试性和API易用性等事物的感受，但我们确实主观地测量了这些……在较小的范围内，我所做的基本上是阅读社区生成的所有信息，例如GitHub问题、论坛帖子、slack消息、twitter帖子以及reddit和hackernews评论。这些都是非常有用的信号。虽然不和谐的声音很多，但我们也能从中了解到用户的一些想法。这些指标帮助我们很好地确定优先级，我认为这是在主观层面上塑造我们产品的好方法。除了我以外，几乎所有的核心开发人员都花了很多时间与用户互动，所以我们从非常模糊和主观的角度来看有很多共同的理解。但是，这种方法并没有超出一点。扩展PyTorch随着项目规模的扩大，我认为自PyTorch推出以来的两年里，我已经达到了人体每天工作的极限。我正在浏览500条左右的GitHub通知、50条左右的论坛帖子、大量的闲散活动，以及Twitter、Reddit和Hacenews上的许多其他参与。我觉得我每天工作15小时，每时每刻都精疲力尽，但实际上并没有完成多少工作。所以，我只想把这些繁琐的工作交给其他更努力、做得更好的人，这样我就可以放下心来。后来有我没有的超能力的同事EdwardYang接管了整个工作流程，准备先观察再创造更好的扩展流程。2021年1月，他写了一篇优秀的博文《The PyTorch Ppen Source Process》。我从他做这些事情中学到的一件事是，当你达到一定规模时，你不能什么都做，你必须有明确的轻重缓急。博客地址：http://blog.ezyang.com/2021/01/pytorch-open-source-process/另外一个需要考虑项目规模的是纵向整合还是横向整合。在PyTorch项目中，我们集成了分布式、jit和量化包，由于它们与前端设计的交叉点很深，因此需要更深入的垂直集成。我们还将torchvision或torchserve等软件包分叉到各自的GitHub存储库中，因为它们不需要大量的端到端思考。最后，我想谈谈生态系统。从PyTorch开始，我们希望开发人员使用PyTorch并为项目做出贡献，从而发展社区。在整个过程中，我们努力避免任何形式的激励措施。因此，长期以来，我们没有提供任何奖品、奖金或其他经济激励措施来鼓励研究人员使用PyTorch。我们的观点是，一旦引入经济激励措施，它们就会以不可逆转的方式塑造社区文化。截至2020年底，PyTorch项目约有1626名贡献者，45k+下游项目，PyTorch论坛上有34k用户。即使是现在，尽管我们的项目有更大的预算，但除了每年举办一两次黑客马拉松外，我们并没有花太多钱。我们非常关心的另一个激励因素是给其他人更多的成长空间，而不是自己做所有事情。我们试图帮助社区成长并首先填补一些空白，只有当没有人可以填补某些需求时，我们才会介入并自上而下投入时间和精力来解决问题。
