十年间，从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...