2019机器学习框架之争：与Tensorflow竞争白热化，进击的PyTorch赢在哪里？

2019年10月10日 321点热度 0人点赞 0条评论

大数据文摘出品

来源：thegradient

编译：张大笔茹、曹培信、刘俊寰、牛婉扬、Andy

2019年，机器学习框架之争进入了新阶段：PyTorch与TensorFlow成为最后两大玩家，PyTorch占据学术界领军地位，TensorFlow在工业界力量依然强大，两个框架都在向对方借鉴，但是都不太理想。

最后谁能胜出？还得看谁更好的回答几个关键问题。

来自康奈尔大学的Horace He刚刚在Gradient发布了一篇长文探讨2019年的两大机器学习框架之争，他论述了PyTorch和TensorFlow各自的优劣和发展趋势，但是很明显更看好PyTorch，特别是其在学术领域起到的驱动作用。

刚好，今天也是PyTorch 1.3发布的日子，最新的版本增加了更多工业方面的能力，量化还有终端支持。PyTorch官方称还将启动许多其他工具和库，以支持模型的可解释性，并将多模式研究投入生产。

PyTorch 1.3发布官方链接：

https://PyTorch.org/blog/PyTorch-1-dot-3-adds-mobile-privacy-quantization-and-named-tensors/

机器学习的未来你更看好PyTorch还是TensorFlow呢？也欢迎留言告诉我们。

以下是全文：

自2012年深度学习重新获得突出地位以来，许多机器学习框架也相应成为研究人员和行业从业者的新宠。

从Caffe和Theano的早期学术成果，到业界支持的大规模PyTorch和TensorFlow，面对如此多的选择，人们很难知道最好的框架是什么。

如果从Reddit看，你可能会认为PyTorch风头正盛。但如果你浏览的是机器学习大咖Francois Chollet的Twitter，你可能会认为TensorFlow/Keras是主流框架。

2019年，机器学习框架之战主要是PyTorch和TensorFlow的对峙。

根据我的分析，在学术领域，研究人员正逐渐放弃TensorFlow，扎堆涌向PyTorch。与此同时，在工业领域，TensorFlow是首选平台，但这种情况可能不会持续很久。

PyTorch在研究领域日益占据主导地位

首先当然是先用数据说话。

下图显示了顶级研究会议接受论文中，使用TensorFlow或Pythorch的比率。可以发现，所有的折线都向上倾，并且在2019年，主要会议的论文中，多数使用的都是PyTorch。

如果觉得仅靠会议论文数据还不够，这里还有一张图来证明PyTorch在研究社区获得关注的速度。

下图显示了PyTorch和TensorFlow在各类会议上被提及的次数图。

2018年，PyTorch获得的关注还比较少。但现在，大多数人都在使用PyTorch：69%的CVPR、75%以上的NAACL和ACL、50%以上的ICLR和ICML使用的也是PyTorch。

PyTorch在视觉和语言会议方面的优势最为明显，分别以2:1和3:1的比例超过了TensorFlow。此外可以看到，在ICLR和ICML等通用机器学习会议上，PyTorch也比TensorFlow更受欢迎。

虽然有人认为PyTorch还是一个全新的框架，并试图在TensorFlow主导的世界中分得一杯羹，但是数据告诉我们并非如此。除了ICML，在NAACL、ICLR和ACL等会议上，TensorFlow今年的论文整体上都比去年少。

也就是说，慌的不是PyTorch，而是TensorFlow。

为什么研究人员喜欢PyTorch？

简单。PyTorch类似于numpy，非常Python化，很容易就能与Python生态系统的其余部分集成。例如，可以在PyTorch模型中任何地方添加pdb断点。而在TensorFlow中，调试模型需要一个活动会话，整个过程非常麻烦。

API。大多数研究人员更喜欢PyTorch的API而不是TensorFlow的API。部分原因是因为PyTorch的设计更好，还有部分是因为TensorFlow切换其API接口过于频繁(比如“layers”-“slim”-“estimators”-“tf.keras”)，这阻碍了其自身的发展。

表现。尽管PyTorch的动态图给出的优化机会很少，但许多传闻称PyTorch的速度不比TensorFlow慢多少。目前尚不清楚这是否属实，但至少，TensorFlow在这一方面还没有获得决定性的优势。

TensorFlow 未来的研究方向是什么？

即使TensorFlow在功能上与PyTorch不相上下，但PyTorch已经覆盖了机器学习社区的大部分。这意味着PyTorch实现将更容易找到，作者将更有动力用PyTorch发布代码，而且你的合作者也很可能会更喜欢PyTorch。因此，任何向TensorFlow 2.0的回迁可能会很慢。

TensorFlow在Google/Deepmind中有一批忠实的用户，但不知道Google最终是否会在这一点上动摇。现在，很多Google想招募的研究人员已经开始喜欢上PyTorch了，我也听到抱怨说Google内部很多研究人员希望使用TensorFlow之外的框架。

此外，PyTorch的统治地位很可能会切断谷歌研究人员与其他研究社区的联系。他们不仅难以在外部研究的基础上进行构建，而且外部研究人员也不太可能在谷歌发布的代码基础上进行构建。

TensorFlow 2.0是否能重新俘获回之前的粉丝还有待观察。尽管eager模式很吸引人，但对于Keras API而言并非如此。

用于产业的PyTorch和TensorFlow

虽然PyTorch目前在研究领域占据主导地位，但稍微注意一下就会发现TensorFlow仍然是占据主导地位的框架。

例如，根据2018年到2019年的数据，TensorFlow在招聘的页面上有1541个新工作岗位，而PyTorch有1437个，TensorFlow在Medium上有3230个新文章，而PyTorch有1200篇，TensorFlow在GitHub有13.7K标星，而PyTorch有7.2K。

那为什么PyTorch现在已经如此受研究人员欢迎了，但它在工业上还没有同样的成功呢？

显而易见的第一个答案就是使用习惯。TensorFlow比PyTorch早几年问世，而产业接受新技术的速度要比研究人员慢。

另一个原因就是TensorFlow在产业适应方面优于PyTorch，什么意思呢？要回答这个问题，我们需要知道研究人员和工业界的需求有何不同。

研究人员关心的是他们在研究中迭代的速度有多快，这通常是在相对较小的数据集(可以在一台机器上运行的数据集)上，并在8个GPU上就可以运行。这通常不是出于对性能的考虑，而是更关注可以快速实现自己的想法。

而工业界则认为性能是最优先考虑的。虽然运行时速度提高10%对研究人员来意义不大，但这可以直接为公司节省数百万美元。

另一个区别是部署。研究人员一般在自己的机器上或某个专门用于运行研究工作的服务器集群上进行实验。但是在产业上，部署则有一连串的限制与要求。

没有Python。运行Python对服务器的开销太大了；
移动。你不能在移动终端二进制文件中嵌入Python解释器；
服务。需要包罗万象的功能：不用停机更新的模型，在模型之间无缝切换，批处理在预测时间，等等。

TensorFlow就是特别针对这些需求构建的，并为所有这些问题提供了解决方案：网络图格式和执行引擎本身不需要Python，而TensorFlow Lite和TensorFlow Serving可以分别处理移动终端和服务器需求。

从历史上看，PyTorch在满足这些需求方面做得还不够，因此大多数公司目前在生产中都还是使用 TensorFlow。

架构「融合」

2018年末，两件大事彻底改变了这一局面:

PyTorch引入了JIT编译器和“TorchScript”，从而引入了基于图的特性；
TensorFlow宣布他们将在2.0版本中默认转移到Eager模式。

显然，这些举措都是为了解决PyTorch和TensorFlow各自的弱点。那么这些特性到底是什么，它们能提供什么呢？

PyTorch TorchScript

PyTorch JIT是PyTorch的一个中间表示(intermediate representation，IR) ，称为TorchScript。Torchscript是PyTorch的“图”表示。你可以通过使用跟踪或脚本模式将常规PyTorch模型转换为TorchScript。跟踪接受一个函数和一个输入，记录用该输入执行的操作，并构造IR。

虽然很简单，但是跟踪也有它的缺点。例如，它不能捕获未执行的控制流。例如，如果它执行了true块，它就不能捕获条件块的false块。

Script模式接受一个函数/类，重新解释Python代码并直接输出TorchScript IR。这允许它支持任意代码，但是它实际上需要重新解释Python。

一旦PyTorch模型进入了这个IR，我们就可以获得图模式的所有优势。我们既可以在C++中部署PyTorch模型，而不依赖Python，或者对其进行优化。

TensorFlow Eager

在API级别上，TensorFlow Eager模式基本上与PyTorch Eager模式相同，后者最初由Chainer推出,这为TensorFlow提供了PyTorchEager模式的大部分优势(易用性、可调试性等等)

然而，这也给TensorFlow带来了同样的缺点。TensorFlow Eager模型不能导出到非python环境中，也不能进行优化，不能在移动设备上运行。

这将TensorFlow置于与PyTorch相同的位置，它们的解析方式基本相同——你可以跟踪代码(tf.function)或重新解释Python代码(Autograph)。

因此，TensorFlow的Eager模式并不能真正做到“两全其美”。虽然可以使用 tf.function注释将eager code转换为静态图，但这永远不会是一个无缝转换的流程(PyTorch的TorchScript也有类似的问题)。跟踪基本上是有限的，重新解释Python代码实际上需要重写Python编译器的大部分内容。

当然，通过限制在深度学习中使用的Python子集，范围可以大大简化。

在默认启用Eager模式时，TensorFlow将强迫用户做出选择——为了便于使用而Eager执行，并且需要为部署而重写，或者根本不使用急于执行。

虽然这与PyTorch的情况相同，但PyTorch的TorchScript的可选择加入特性可能比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 Vector Products)时，就出问题了。有效地计算需要“正向模式自动微分”，如果没有这个功能，Hessian Vector Products的计算速度就会降低一个数量级。

Jax是由最初建造Autograd的同一批人创建的，它具有正向和反向模式自动分化的功能，这使得计算高阶导数的速度比PyTorch/TensorFlow的更快。

并且，Jax不仅能计算高阶导数，Jax开发人员将Jax视为组成任意函数转换的框架，包括vmap(用于自动批处理)或pmap(用于自动并行化)。

Jax最初的使用者主要是大学毕业生(尽管没有GPU支持，但ICML有11篇论文使用了它)，但相信Jax很快就会找到一个类似的忠实粉丝社区，用它来做各种n阶导数。

不够灵活！

当运行PyTorch/TensorFlow模型时，大部分工作实际上并不是在框架本身中完成的，而是由第三方内核完成的。这些内核通常由硬件供应商提供，类似于MKLDNN（用于 CPU）或cuDNN（用于Nvidia GPUs），由高级框架可以利用的操作符库组成。高级框架将计算图表分解成块，然后调用计算库。这些库代表了数千小时的工作量，并针对体系结构和应用程序进行优化以获得最佳性能。

然而，最近非标准硬件、稀疏/量子化张量和新运算符的流行暴露了依赖这些运算符库的一个缺陷：它们不够灵活！如果你想在研究中使用像胶囊网络（capsule networks）这样的新操作怎么办？现有的解决方案还不够完善。正如本文所说，现有的胶囊网络在GPU上的实现比最优实现慢2个数量级。

每个新的硬件体系结构、张量或算子的类别，都大大增加了问题的难度。目前已经有许多处理工具，如Halide、TVM、PlaidML、TensorComprehensions、XLA、Taco等，但是正确的方法还没找到。

如果没有解决这个问题，我们就会面临机器学习研究与工具过度匹配的风险。