自从2012年深度学习再一次声名鹊起以来，许多机器学习框架都争先恐后地要成为研究人员和行业从业者的新宠。面对如些众多的选择，人们很难判断最流行的框架到底是什么。
以下为译文：
自从2012年深度学习再一次声名鹊起以来，许多机器学习框架都争先恐后地要成为研究人员和行业从业者的新宠。从早期的学术性的Caffe（卷积神经网络框架）和Theano（一个基于Python的深度学习库），到业界支持的大规模PyTorch和TensorFlow，面对如些众多的选择，人们很难判断最流行的框架到底是什么。如果你只浏览Reddit网站，你可能会认为PyTorch正是如日中天。但是如果你再浏览Francois Chollet（谷歌AI研究员、Keras创建者）的推特，你可能又会认为TensorFlow/Keras正在成为主流框架，而PyTorch的势头却停滞不前。到了2019年，机器学习（ML）框架大战只剩下了两个主要竞争者，那就是PyTorch和TensorFlow。我的研究表明，研究人员正在逐渐放弃TensorFlow，他们正扎堆涌向PyTorch。而同时在工业领域，TensorFlow目前仍然是首选平台，但这种局面可能不会持续太久。下图显示了每次顶级研究会议，接受的PyTorch的论文数占TensorFlow和PyTorch的论文数总和的比率。所有的线条都向上倾斜，意味着接受的PyTorch论文的占比越来越大。而2019年的主要会议的论文中，大部分使用的都是PyTorch。
CVPR, ICCV, ECCV - 计算机视觉大会NAACL、ACL、EMNL P - NLP(自然语言处理）会议ICML、ICLR、NEURIPS - 通用机器学习会议这张图是通过对过去几年在一个主要的机器会议上发表的每一篇论文进行统计而生成的。论文归类的依据是根据它是否提到了PyTorch还是TensorFlow，不包括那些与谷歌或脸书有关联作者的论文，也不包括那些同时提到TensorFlow和PyTorch的论文。欲知详情可以参考这里的附录。如果你觉得这些数据还不足以证明PyTorch在研究界的发展速度，这里有一张PyTorch和TensorFlow的论文个数的原始数据对比图。在2018年，PyTorch的论文个数还是少数，但是现在，它变成了压倒性的多数。69%的CVPR论文，超过75%的NAACL和ACL论文，和50%以上的ICLR和ICML论文，都在使用PyTorch。PyTorch不但在视觉和语言会议上的优势最强（分别以2:1和3:1的优势压倒TensorFlow），而且在像ICLR和ICML这样的通用机器学习会议上也比TensorFlow更受欢迎。
虽然有人认为PyTorch仍然是一个新兴的框架，正在试图从TensorFlow主导的全球市场中分得一杯羹，但数据告诉我们的却并非如此。除ICML外，TensorFlow的在其他任何会议上的论文数量都没有实质性的增长或者跟上论文的总体增长速度。在NAACL、ICLR和ACL会议上，TensorFlow今年的论文数量实际上比去年少。所以，担心未来的不应该是PyTorch，而是TensorFlow。简单：它类似于numpy，非常Python化，很容易就能和Python生态系统的其他部分集成。例如，你只需在PyTorch模型中的任何地方插入一个pdb断点，它就可以工作了。在TensorFlow中，调试模型需要一个活动会话，整个过程非常棘手。
非常棒的API：大多数研究者更喜欢PyTorch的API而不是TensorFlow的API。一部分原因是因为PyTorch设计得更好，另一部分是因为TensorFlow频繁切换API（例如“layers”->“slim”->“estimators”->“tf.keras”）而导致自己的使用变得非常困难。
优秀的性能：尽管PyTorch的动态图提供的优化机会非常少，还有许多传闻称PyTorch的速度不比TensorFlow快。目前尚不清楚这是否属实，但至少，TensorFlow在这一领域并没有取得决定性的优势。
即使TensorFlow在功能上与PyTorch不相上下，但PyTorch已经覆盖了机器学习社区的大部分。这意味着PyTorch的实现将更容易找到，研究人员将更有动力在PyTorch中发布代码（因为人们会使用它），而且你的合作者很可能更喜欢PyTorch。因此，任何向TensorFlow 2.0的回迁都可能很慢，如果最终会发生的话。TensorFlow在谷歌/DeepMind公司总是会有一些不情愿的受众，但我不知道谷歌是否最终会不再坚持这一点。即便是现在，谷歌希望招募的许多研究人员已经在不同的程度上更倾向于PyTorch，我也听到过谷歌内部的研究人员的一些抱怨，他们当中有许多人希望使用TensorFlow以外的框架。此外，PyTorch的主导地位可能开始割裂谷歌研究人员与其他研究群体之间的联系。这样不仅谷歌的研究人员难以在外部研究的基础上进行构建，而且外部的研究人员也不太可能在谷歌发布的代码基础上进行构建。TensorFlow 2.0是否会帮助TensorFlow吸引回来部分研究领域的受众，这一点还有待观察。尽管Eager模式肯定会很吸引人，但对于Keras API来说，这种吸引力可能为零。用于工业生产环境的PyTorch和TensorFlow尽管目前PyTorch在研究领域占据了主导地位，但纵观业界，TensorFlow仍然是主导框架。例如，根据2018年至2019年的数据，在公开的工作机会列表中，TensorFlow有1541份新的职位空缺，而PyTorch的职位空缺则为1437份。TensorFlow在Medium上的新文章有3230篇，而PyTorch只有1200篇，TensorFlow在GitHub上的新增的星星（Star）数为13.7K，而PyTorch只有7.2K......那么，如果PyTorch在研究人员中如此受欢迎，为什么它在工业环境中没有看到同样的成功呢？一个显而易见的第一个答案就是惯性。TensorFlow比PyTorch早几年问世，工业界采用新技术的速度总是比研究人员要慢。另一个原因是TensorFlow在工业生产环境中的表现要优于PyTorch。但那是什么意思？为了回答这个问题，我们需要知道研究人员和工业界的需求之间存在的不同。研究人员关心他们在研究中迭代的速度，他们通常是在相对较小的数据集（适合在一台机器运行上的数据集）上，并且在少于运行8个GPU的环境上工作。这就决定了他们通常不以性能好坏作为主要考虑因素，而是看重其快速实现他们新想法的能力。另一方面，在工业生产环境下，性能是第一重要的。虽然运行速度提高10%对研究人员来说毫无意义，但是可以直接为公司节省数百万美元。另外一个不同是部署。研究人员会在他们自己的机器上或在专门用于运行研究工作的服务器集群上运行实验。而在另一方面，工业生产环境有一系列的限制/要求。没有Python：一些公司运行的服务器不支持Python，额外运行Python的开销太大而无法接受；
Mobile（移动端支持）：你无法在移动端二进制代码中嵌入一个Python解释器；
Serving（服务）：需要支持各种各样的功能，包括但不限于：不停机更新模型，无缝切换模型，在预测时间进行批处理作业，等等。
TensorFlow是专门针对这些需求而构建的，并且有解决所有这些问题的方案：图形格式和执行引擎本身不需要Python，而TensorFlow Lite和TensorFlow Serving分别考虑了移动端和服务器端的需求。由于历史原因，PyTorch在满足这些要求方面做得不够，所以，目前大多数公司在工业生产环境中还是使用TensorFlow。但是，临近2018年底发生的两件大事，让这种局面发生了翻天覆地的变化：PyTorch引入了JIT编译器和“TorchScript”，从而引入了基于图的特性。TensorFlow宣布他们在2.0中默认使用Eager模式。显然，这些举措都是为了解决PyTorch和TensorFlow各自的弱点。那么这些特性到底是什么，它们能提供什么呢？PyTorch JIT是PyTorch的一个中间表示（Intermediate Representation，IR），称为TorchScript。TorchScript是PyTorch的“图”表示。你可以使用跟踪或脚本模式将常规PyTorch模型转换为TorchScript。跟踪接受一个函数和一个输入，记录用该输入执行的操作，并构造IR。尽管追踪很简单，但也有其缺点。例如，它无法捕获未执行的控制流。例如，如果它执行了一个条件语句块中的True块，它就不能捕获False块。Script模式接受一个函数/类，重新解释Python代码并直接输出TorchScript IR。这允许它支持任意代码，但实际上它需要重新解释Python。
一旦你的PyTorch模型进入了这个IR中，我们就可以获得图形模式的所有好处。我们可以在C++中部署PyTorch模型，而不依赖于Python，或者对其进行优化。在API级别，TensorFlow的Eager模式基本上与PyTorch的Eager模式相同，后者最初由Chainer流行开来。这为TensorFlow提供了PyTorch Eager模式的大部分优点（易用性、可调试性等等）。然而，这也给TensorFlow带来了同样的问题。例如，TensorFlow Eager模型不能导出到非Python环境中，不能进行优化，不能在移动设备上运行，等等。这将TensorFlow置于与PyTorch相同的位置，它们的解析方式基本相同：你可以跟踪代码（tf.function）或重新解释Python代码（Autograph）。
因此，TensorFlow的Eager模式并不能真正做到“两全其美”。尽管你可以使用tf.function注释将Eager的代码转换为静态图，但这绝不是一个无缝转换的过程（PyTorch的TorchScript也有类似的问题）。跟踪从根本上来说是有局限的，重新解释Python代码本质上需要重写Python编译器的大部分功能。当然，通过限制在深入学习中使用的Python的子集，可以大大简化范围。在默认情况下启用Eager模式时，TensorFlow会强制用户做出选择：使用Eager Execution以方便使用，但是需要重写以进行部署，或者根本不使用Eager Execution。虽然这与PyTorch所处的情况相同，但PyTorch的TorchScript的opt-in特性可能比TensorFlow的“默认Eager模式”更容易接受
从上面的分析中，我们可以得出当前机器学习框架的现状是：PyTorch在研究领域占据优势，并试图将这一成功扩展到工业生产领域。而TensorFlow正试图在不牺牲太多工业生产领域优势的情况下，挽回其在研究领域的损失。PyTorch肯定需要很长时间才能对工业生产领域产生有意义的影响，毕竟TensorFlow在发展缓慢的工业生产领域的地位已经根深蒂固。然而，从TensorFlow 1.0到2.0的过渡将是困难的，这为PyTorch得到业界的评估提供了一个绝好的时机。研究人员的偏好对工业生产的影响有多大？当现在的博士生开始毕业时，他们会带着PyTorch进入行业。这种偏好是否足够强烈，以至于公司会选择PyTorch作为招聘的条件？同时毕业生们会在PyTorch的基础上创业吗？
TensorFlow的Eager模式在可用性方面能否赶上PyTorch？我从问题追踪者和在线社区得到的印象是，TensorFlow Eager严重受到性能/内存方面问题的困扰，而且Autograph也有自己的问题。谷歌将不得不花费大量的工程努力，来解决TensorFlow背负的沉重的历史包袱；
PyTorch满足产业需要的速度有多快？PyTorch还有很多基本问题悬而未决：没有好的量化支持，不支持移动、不支持服务端等等。在这些问题解决之前，PyTorch基本不会成为许多公司的选择。PyTorch能为企业提供一个足够吸引人的故事来实现转变吗？注：本文发布当天，PyTorch宣布支持量化和移动。两者都还处在试验阶段，但这代表了PyTorch在这方面的重大进展；
谷歌在行业中的孤立会对TensorFlow造成伤害吗？谷歌推出TensorFlow的主要原因之一是帮助其新兴的云服务。由于谷歌正试图拥有整个机器学习垂直领域，这会刺激正在与谷歌展开竞争的公司（如微软、亚马逊、Nvidia）只能选择支持唯一的替代机器学习框架：PyTorch。
接下来会如何？
机器学习框架在多大程度上影响了机器学习的研究，这一点可能没有得到充分的认识。它们不仅使机器学习研究成为可能，而且使得研究人员能够轻松探索的想法成为可能。有多少新生的思想仅仅因为没有一种简单的方法可以在一个框架中表达而被粉碎？PyTorch可能已经使得研究工作达到了局部的最简化，但是值得深究一下其他框架提供了什么，以及它们为研究工作提供了什么样的机会。
高阶导数问题：
PyTorch和TensorFlow，就其核心来说，都是自动微分（自动求导）框架。也就是说，它们允许人们对某个函数求导。然而，有很多方法可以实现自动微分（求导），大多数现代机器学习框架选择的特定实现方式是“反向模式自动微分”，也就是通常所说的“反向传播”算法。结果证明，对于神经网络的导数计算，这种方式是非常有效的。然而，在计算高阶导数（Hessian/Hessian向量积）时，情况就会发生变化。有效地计算这些需要所谓的“前向模式自动微分”。如果没有这种能力，计算Hessian向量积的速度可能会慢几个数量级。我们来看看Jax。Jax是由最初构建Autograd的同一批人构建的，它具有正向和反向模式的自动微分功能。这使得计算更高阶导数的速度比PyTorch/TensorFlow的更快。并且，Jax能够提供的不仅仅是高阶导数。Jax开发人员将Jax视为编排任意函数转换的框架，包括vmap（用于自动批处理）或pmap（用于自动并行化）。最初的Autograd有其忠实的追随者（尽管没有GPU支持，但ICML有11篇论文使用了它），Jax很可能很快就会找到一个类似的忠实社区，并将其应用于各种n阶导数运算。
框架的灵活性问题
当运行PyTorch/TensorFlow模型时，大多数工作实际上并不是在框架本身中完成的，而是由第三方核心库完成的。这些核心库通常由硬件供应商提供，如MKLDNN（用于CPU）或cuDNN（用于Nvidia GPU），由高级框架可以使用的算子库组成。高级框架将它们的计算图分解成块，然后由这些块来调用这些计算库。这些库通常需要运算数千个工时，并且经常需要针对体系结构和应用程序进行优化，以获得最佳性能。然而，最近对非标准硬件、稀疏张量/量化张量和新算子的兴趣暴露了依赖这些算子库的一个主要缺陷：它们的灵活度不够。如果你想在你的研究中（比如胶囊网络Capsule Network）使用新的算子，该怎么办？如果你想在机器框架不支持的新硬件加速器上运行你的模型，该怎么办？现有的解决方案往往达不到要求。正如本文所说，现有的胶囊网络在GPU上的实现比最优实现慢2个数量级。每一种新的硬件结构，张量或算子的类别，都大大增加了这个问题的难度。已经有许多工具可以处理不同的方面（Halide, TVM, PlaidML, Tensor Comprehensions, XLA, Taco等），但是正确的方法还未找到。如果我们不做更多的工作来解决这个问题，我们就会面临机器学习研究和与我们现有的工具过度匹配的风险。对于TensorFlow和PyTorch的未来来说，这是一个激动人心的时刻。他们的设计已经趋同到这样的程度，以至于任何一个框架都不能凭借其设计而赢得最终的胜利，并且每一方都有各自的地盘：一方拥有研究领域，另一方则拥有工业生产领域。就我个人而言，在PyTorch和TensorFlow之间，我会觉得PyTorch更占优势。机器学习仍然是一个研究驱动的领域。产业不能忽视研究成果，只要PyTorch在研究领域占据主导地位，最终企业就会被迫实现转换。然而，快速前进的不仅仅是框架。机器学习研究本身也处于一个巨大的变革当中。不仅框架发生了变化，5年后使用的模型/硬件/范式与我们现在今天使用的可能会截然不同。未来如果有另一个计算模型占据主导地位，PyTorch和TensorFlow之间的战斗就会变得无足轻重。在所有这些相互冲突的利益中，以及在机器学习上投入的所有资金中，退一步想想是很好的。我们大多数人都不是为了钱而开发机器学习软件，也不是为了协助公司的战略计划。我们从事机器学习是因为我们关心推进机器学习的研究，关心人工智能的民主化，或者仅仅想构建一些很酷的东西。不管你喜欢TensorFlow还是PyTorch，我们的目标都只有一个，让机器学习软件做到最好！作者简介：Horace He是一名康奈尔大学的学生，对编译器和机器学习的交叉领域有研究兴趣。他今年夏天在PyTorch JIT团队实习，但本文/数据是独立于PyTorch团队编写/收集的。在推特上关注他，了解机器学习社区数据的未来更新。原文：https://thegradient.pub/state-of-ml-frameworks-2019-PyTorch-dominates-research-TensorFlow-dominates-industry/【END】
热 文 推 荐
☞「2019中国大数据技术大会」超值学生票来啦！
☞阿里乌镇大动作：平头哥开源 MCU 设计平台！
☞【当头棒喝】你是真的了解云计算吗？