进击的PyTorch，和它背后的开源领袖

十年间，从Torch进化到PyTorch，再到近期落地Linux基金会，PyTorch从一个无心插柳的项目逐渐演变为最有影响力的开源项目之一。它究竟是如何一步步成长起来的？背后有那些与众不同的故事？

OneFlow社区编译整理了Linux基金会对PyTorch创始人Soumith Chintala的最新采访以及他此前分享的关于PyTorch的开源历程，从中我们会看到一个开源项目的蜕变和社区构建经验，以及PyTorch社区领袖所信奉的开源之道。

翻译｜胡燕君、贾川、程浩源

1

归入Linux基金会

时至今日，PyTorch已“落地”Linux基金会，成为其主要项目之一。
Meta造就了PyTorch，后者的生态也为Meta带来了巨大品牌价值。当PyTorch成为最流行的外部技术栈，Meta雇佣新员工时就不需要对其进行内部技术栈培训，同时，许多硬件供应商从一开始就支持PyTorch，所以当Meta购买新硬件时可以有更多选择，也无需等待硬件与Meta内部软件栈进行集成。

如今，PyTorch归入Linux基金会后也会给生态中的大型企业带来好处。毕竟，企业在投资某一项技术时需要考虑许多因素，比如，竞争对手是否也在开发这项技术，还有地缘政治等因素。

过去的三年里，Microsoft、Amazon和Google一直在为PyTorch做贡献，即便Google的TensorFlow是PyTorch的竞争对手。大约一年半前，Microsoft首席执行官Satya Nadella在演讲中公开表示，Microsoft十分喜欢并且正在大力投资PyTorch。

不过，新的治理结构将保证PyTorch在技术方面不会被某一家企业左右。未来，PyTorch各个部分和模块的维护人员将保持不变。在PyTorch项目中，拥有代码提交权限的只有个人而非任何公司。

2

PyTorch的开源旅程

回顾PyTorch的开源之路，从一开始，我们就想做符合个人兴趣的事，在开源方面尤其如此。

大多数开源项目不只是从“我们需要拥有10000名用户”开始的，那没有意义，开源历程实际上要更加充满活力。

通常，我们试图将它与更广泛的兴趣或需求相联系。只有当许多想要共度光阴的人都感兴趣时，想法和项目才会自然地成长。也有极少数例外，例如巨头企业会推出具有庞大营销计划的自上而下的产品。

大多数小型开源项目，经过足够地努力和投入后，都会考虑增长问题。那时，他们已经确定了核心利益和理念，这是他们的技术和文化底蕴的基础。接下来，他们想知道他们是否正在尽其所能来销售、营销和发展这个项目。

PyTorch的发展至今，我认为在理念/原则、眼界和风险、衡量指标、项目扩张这四方面的认知和实践发挥了很大作用。

理念/原则

当我们考量一个项目时，它可能是一个以技术为中心的项目，比如试图宣扬多面体（polyhederal）优化思想的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 ，能帮助用户真正轻松地使用和扩展该API。基于机器学习社区如何塑造它的未来，我们做出的这个赌注可能因数百万个原因而失败。例如，假设我们可能在十年内停止在ResNets上进行创新，那么广泛而大型的API需求就会过时，而未来将需要一个更垂直的专注于ResNets的库（译者注：这件事是不是正在Transformer上发生？）。

衡量指标

除了核心原则和视野外，我们还希望与客户建立反馈机制，这是产品开发中的标准操作需求。然后，我们问自己要如何从各个维度去监测PyTorch：它们是否可衡量？它们是否可以很好地衡量？你应该衡量它们吗？你如何处理不可衡量的区域？

在Torch时代，我们学到了很多关于人们如何喜欢衡量事物，以及其他人如何喜欢将衡量的比较结果奉为圭臬。例如微基准测试、Github标星数量、特征对比图表等。

当用户在社区发布了一些这样的衡量指标和比较结果后，我们对其中一些衡量指标感到委屈、恼火。但是，我们从Torch的经验中得到的认知是，我们要问自己，过早地衡量某些东西会对产品造成怎样的负面影响。尽管我们没有写衡量Torch的博文展示给竞争对手，但一直在努力优化这些衡量指标并对其做出反应，而不仅是专注于其他对用户更重要的优先级功能。

因此，当开发PyTorch时，我们很清楚两件事：首先，我们的核心能力不是像速度或其他一些统计数据那样可衡量的东西，但我们需要将灵活性、API设计和可调试性作为重中之重，向丝滑般流畅的用户体验迈进。没什么好的方法可以衡量这一点，我们必须真正适应这种模糊性，并且能够主观地不断重新评估我们是否能够做好工作的内部信号。其次，我们相信，如果不对PyTorch的外部衡量指标做出反应，就可以专注于我们所关心的事情，即便这在短期内会造成用户流失。

所以，在PyTorch的历史上，我们从来没有对速度基准或不相关的衡量标准（如Github标星数量）做出回应。作为PyTorch的作者，我们还没有提交MLPerf这样的基准测试。这是经过深思熟虑的选择，我们对自己的方法非常满意。

当我作关于PyTorch的相关演讲时，通常有人会问“与某框架相比，PyTorch的速度有多快？”即使我知道我们在给定的用例上一样快或更快，我也会回避掉这个问题，“PyTorch更灵活，可能在其他地方的性能快了不到 10%，试试PyTorch吧。”这给了我们一种令人难以置信的超能力——专注于核心竞争力，而不会被拖入我们所认为的那些衡量产品的简单化看法——这是一种根本不重视PyTorch优势的观点。

我们谨慎依赖的指标是人们是否在使用PyTorch以及它与竞品的相对使用情况，不是衡量Github标星数量或微基准性能的指标，而是衡量在框架中真正写代码这一指标。因此，我们使用了 Github的全局代码搜索（for import torch和 stuff）和arxiv引用等指标，它们更准确地描述了是否有人真正使用了PyTorch，这无可争辩。

然而，问题在于这些指标是滞后的。我们根本不能依靠它们来了解社区用户的即时需求，因为它们大约有6个月的交付周期。

我们也没有使用指标来尝试估计用户对其整体体验，以及可调试性和API易用性等方面的感受。但我们确实主观地对它们进行了衡量......
在较小的视野内，我们所做的基本上是由我阅读社区里的全部信息，包括Github Issues、论坛帖子、Slack消息、推特帖子、Reddit和Hackernews的评论。是的，尽管有很多无效信息，但也有很多非常有用的信号。

这帮助我们很好地确定了任务的优先级，我认为这是通过主观判断打磨产品的好方法。除我之外，几乎所有的核心开发者都花了很多时间与用户互动，因此通过非常模糊和主观的要素，我们达成了很多共同理解的看法。然而，这种方法却无法突破这一点挑战。

项目扩张

随着项目不断扩张，在PyTorch开源的2年内，我认为自己每天阅读社区信息已经达到人类极限了。我会浏览大约500个Github的通知、大约50个论坛帖子、大量的slack活动和twitter/Reddit/HN上的活动。我想我每天工作了15个小时，一直觉得筋疲力尽，但实际上没有做太多其他事情。我的直接想法显然是把这个转交给其他人，而我可以缓解一下倦怠感。

我的同事Edward Yang拥有我所没有的超能力，他承接了这个工作，目的是首先观察它，然后构建一个更好的过程来对它进行扩展。我从他做这件事中得到的一个很好的认知是，一旦达到一定的规模，你就不能瞄准所有事情，必须高度重视任务的优先级，没有其他办法了，就得这样。不能解决掉Github上的每个问题并不会让你看起来很残忍。

在扩张上要考虑的另一件事是，要垂直地整合还是平行地整合。2009年，AMD将他们的晶圆厂部门分拆成一家独立公司，那时我觉得难以理解。

几年后，我读到的一篇文章认为，AMD这样做是因为晶圆厂（后端）与设计师（前端）合作不佳，并且那里的垂直整合弊大于利。相比之下，Apple的M1处理器及其神奇地快速实用速度归功于令人难以置信的良好垂直扩展，软件团队能够衡量Apple软件生态系统中的瓶颈，并找到需要加速的关键低级别操作，并且该信号一路转换到硬件设计。我不知道这些理论是否正确，但我确实相信，垂直整合做得不好会带来巨大开销，做得好会带来巨大的力量倍增效果，所以应该明智地选择你要走的路。

在PyTorch上，我们垂直集成了软件包，例如distributed,jit和quantization，它们需要更深入的垂直整合，因为它们与前端设计有很大的交集。我们将诸如torchvision或torchserve之类的软件包转移到它们自己的Github存储库中，因为它们不需要那么多端到端的思想。

我认为，围绕纵向与横向整合的决策也严重依赖于构建这些事物的人之间的有效带宽——无论他们在同一家公司内，他们是否在同一时区或同一物理空间，或者他们是否主要通过long-form异步通信进行交谈——所有这些都定义了垂直整合是否可以有效执行。

另一个关于扩张的话题是不仅要发展项目本身，还要发展项目的生态系统。

正确的激励措施很重要。从PyTorch开始，我们就希望根据人们是否有兴趣使用PyTorch或为PyTorch做出贡献，我们非常努力地消除其他类型的激励措施。因此，很长一段时间，我们没有提供任何奖品、奖金或其他经济激励措施来让开发者使用PyTorch。

我们的观点是，一旦引入经济激励措施，就会以不可逆转的方式塑造社区文化。即使是现在，我们有了更大的推广预算，但除了每年一、两次的黑客马拉松大赛，我们都在努力控制这些推广措施。

我们非常关心的另一个激励措施是，确保我们给他人成长空间，而不是只扩张我们自己的势力范围。我们关心与帮助社区成长并率先去填补空白，只有在没有其他人满足这些需求的情况下，我们才会有意介入并自上而下地投入相应资源去解决问题。

3

Soumith参与开源的发端

我的整个职业生涯与开源紧密相关，参与开源是为了享受其中的乐趣并追求进步，我在开源领域的影响力帮我赢得了许多工作和晋升机会。

2010年，当我在纽约大学攻读机器学习方向的硕士时，与自己共事的还有Yann LeCun（2018年图灵奖得主）。当时，Yann LeCun的博士生Pierre Sermanet是我的导师。Pierre安排我研究一个行人检测项目，该项目是EBLearn开源库的一部分。EBLearn是一个面向对象的C++库，里面整合了各种机器学习模型，包括由多个异构模块组成的机器学习模型。

参与这个项目是我回馈开源社区的第一步，在印度上学时，我能学习的公开知识就来自那些免费的开源知识，一些有远见卓识的人决定开源他们所掌握的技术，供更多人学习，这在当时比较少见。

不久后，实验室迎来一位客人，他带来了一个诱人的项目。Clement Farabet现在是NVIDIA AI基础设施副总裁，当时他是Torch7项目的创建者之一，他想让我试用一下。

Torch7是用Lua语言写的，我试用后发现，Torch7框架的效率比EBLearn高出许多，而且在一些特定任务上的表现尤其出色。所以我直接选用了Torch7来完成我的NLP课程项目。

在Torch论坛上，我回答了用户提出的所有问题，还给Torch开发人员发送了Torch存在的问题和希望具备的功能。

我想集合更多人的力量来改进Torch7，但社区创建者Koray Kavukcuoglu（现DeepMind研究副总裁）和Ronan Collobert（当时就职于Facebook）正忙于各自的工作和生活，所以虽然他们创立了这个项目，但却没有时间来解决项目中不断浮现的问题。

于是，我给他们发了一封邮件，大致内容如下：“你们审查PR的速度太慢，而且从来没有回复过问题。我真的很想帮助你们，所以基本上论坛上的问题我都做了回答。你们能在这个项目上多花点时间吗？"
这大概是十年前的事。他们回复了，问我想不想接手负责这个项目的维护，我答应了，毕竟我当时已经为这个项目做了很多实际的维护工作。在我接手之前，没有人像我一样为Torch7付出这么多。

2012年，当我从纽约大学毕业时，我所拥有的只有一纸文凭和一个在维护的Torch社区。人工智能市场还不像今天这样火爆，我也曾一度找不到工作，需要别人的引荐。

2012年7月，我在MuseAmi公司找到了一份工作，工作内容是为移动设备构建机器学习和视觉系统，但我对开源社区的贡献引起了科技巨头的注意。

如果你是开源社区的贡献者，就有更多展现自己的机会。当我现在准备招聘人员扩大团队时，也一定会考察候选人的开源贡献，选择那些在开源工作中展现出非凡能力的人。

从2013年开始，我成为Torch的官方维护人员，随后我正式加入Facebook。从Torch到构建PyTorch的过程挺戏剧化的，当时我和几名全职员工一起搭建Torch，包括构建新功能、处理已知issue、完善新的软件堆栈、进行层升级等。通过解决项目中的问题，我深入地了解到用户需要什么。

Facebook是人工智能领域三大研究公司之一，当时使用Torch的用户有一千人左右，虽然仍只是一个小型社区，但比起我最初使用Torch时仅有20个用户，显然壮大了很多。

2015年末，Google Brain团队开发的TensorFlow横空出世。TensorFlow拥有世界级工程师，成熟的文档体系，还有真正的营销部门、品牌部门等资源。相比由研究生们构建的Torch、Caffe和Theano框架，TensorFlow更像一个专业产品。

我曾像试用Torch一样试用TensorFlow，想看看它是否可以成为Torch后续的发展方向。TensorFlow明显和Theano的模型相似，可在其中用Python编写一个符号化元程序，然后每个部分都在单独的虚拟机中进行编译。编译器必须非常强大，才能实现更有效的创新。但如果需要进行堆栈跟踪，你将无法理解堆栈跟踪报告，因为它不是纯编程语言，它会形成另一个难以追踪的通信层，这会带来麻烦。

在各种组件中，我们曾把脚本语言置于首要关键问题，但这种想法是错的。

我们团队中大多数成员都认为我们需要重构Torch，但不是重走TensorFlow的路径，而是要构建一种更现代、更可用、质量更高的产品，应在生产效率上有不同的侧重。我们相信我们可以讲述一个更好的产品故事。

PyTorch的模型非常简单，没有元编程。举个例子，假设你在iPad的空白屏上用智能笔写字，而智能笔可以将你所写的内容翻译成不同的程序或系统。所以你不仅要考虑写的是什么，还要考虑另一个系统如何解释它，这会在抽象层面产生脱节。

我们做PyTorch时的想法是，只要构建了强大的基础组件，并进行适当优化，那么就不需要独立的复杂引擎，人们只需要进行编码，就可以使其快速运行。

我和大部分Torch社区的成员都认为，开发者的意图必须得到保护，不能受框架的影响，这意味着要给程序员更多的权力。

PyTorch的创建者来自Torch社区。PyTorch原始论文的第一作者Adam Paszke当时在波兰读本科。他找到了我，说他正在找实习，问我有没有实习渠道。我说我们空闲时一直在做PyTorch，你可以以实习生的身份加入我们。所以我、Adam还有Sam Gross（现任职于Meta）三个人开始全职开发PyTorch。此外还有18名成员，他们基本上都是在晚上哄孩子睡觉后，立即打开电脑投入到PyTorch的研发工作中。就这样，PyTorch诞生了。

想法决定方向，工具则是到达目的地的车轮。每隔几年，行业就需要新的工具来探索未知的领域，所以我们必须不断升级工具。

回头来看，我为PyTorch制定的路线非常务实。我相信科学的发展是有机的，产品如何发展取决于行业的方向。现在，人工智能行业发展迅速，行业所需理想工具的特点也不断变化。我相信，这个行业每隔五六年就会需要一种新的工具。

自2012年以来AI一直高速发展，我感到非常高兴。过去每隔三年就有人说AI行业不行了，但事实证明这都没有发生。我认为，起码在未来三到五年内，AI的发展都不会放缓，我们也将继续为AI行业出力。

*（来源：1. https://soumith.ch/posts/2021...；
2.https://podcasts.google.com/f...*）

欢迎下载体验 OneFlow v0.8.0 最新版本：
https://github.com/Oneflow-In...