PyTorch攻势凶猛，程序员正在抛弃TensorFlow？

【线上直播】11月21日晚8点贝壳技术总监侯圣文《数据安全之数据库安全黄金法则》

自 2012 年深度学习重新获得重视以来，许多机器学习框架便争相成为研究人员和行业从业人员的新宠。从早期的学术成果 Caffe 和 Theano ，到背靠庞大工业支持的 PyTorch 和 TensorFlow，大量的选择让我们很难跟踪最流行的框架到底是哪个。

如果你平常只看 Reddit，可能会认为每个人都在切换到 PyTorch。如果根据 Francois Chollet 的Twitter来判断，TensorFlow / Keras 则可能是最受欢迎的，而 PyTorch 的发展势头却停滞不前。

在 2019 年，机器学习框架之战仍然由两个主要竞争者主导：PyTorch 和 TensorFlow。我的分析表明，研究人员正在放弃 TensorFlow 并大量涌向 PyTorch。同时，在行业中，Tensorflow 当前是首选平台，但从长久来看可能并非如此。

首先，我们先对这两者的特性和有点进行简单的比较：

TF是目前深度学习的主流框架，Tensorflow主要特性：

• TensorFlow支持python、JavaScript、C ++、Java和Go，C＃和Julia等多种编程语言。

• TF不仅拥有强大的计算集群，还可以在iOS和Android等移动平台上运行模型。

• TF编程入门难度较大。初学者需要仔细考虑神经网络的架构，正确评估输入和输出数据的维度和数量。

• TF使用静态计算图进行操作 。 也就是说我们需要先定义图形，然后运行计算，如果我们需要对架构进行更改，我们会重新训练模型。 选择这样的方法是为了提高效率，但是许多现代神经网络工具能够在学习过程中考虑改进而不会显着降低学习速度。 在这方面，TensorFlow的主要竞争对手是PyTorch 。

TensorFlow优点：

• 它非常适合创建和试验深度学习架构，便于数据集成，如输入图形，SQL表和图像。

• 它得到谷歌的支持，这就说明该模型短期内不会被抛弃，因此值得投入时间来学习它。

PyTorch基本特性：

• 与TensorFlow不同，PyTorch库使用动态更新的图形进行操作 。 这意味着它可以在流程中更改体系结构。

• 在PyTorch中，您可以使用标准调试器 ，例如pdb或PyCharm。

PyTorch优点：

• 训练神经网络的过程简单明了。 同时，PyTorch支持数据并行和分布式学习模型，并且还包含许多预先训练的模型。

• PyTorch更适合小型项目和原型设计。

再来看看 PyTorch 是如何渐渐缩小与 TensorFlow 之间的差距的。

PyTorch在研究领域的主导地位不断提高

让我们看数据说话。下图显示了在每个顶级研究会议上，使用 PyTorch 的论文与使用 Tensorflow 或 PyTorch 的论文之间的比率。所有的直线都在向上倾斜，2019 年的每个主要会议的论文都用 PyTorch 实现。

会议说明：

CVPR, ICCV, ECCV - 计算机视觉会议

NAACL, ACL, EMNLP - NLP 会议

ICML, ICLR, NeurIPS - 综合 ML 会议

有关数据收集过程的详细信息

该图根据过去几年在大型 ML 会议上发表的所有论文生成。根据论文是否提及 PyTorch 或TensorFlow 进行分类，但不包括与 Google 或 Facebook 关联的作者以及同时提及 Tensorflow和 PyTorch 的论文。这些去处的因素可以在附录中找到 https://thegradient.pub/p/cef6dd26-f952-4265-a2bc-f8bfb9eb1efb/

图的交互式版本：https://chillee.github.io/pytorch-vs-tensorflow/

如果你需要更多证据证明 PyTorch 在研究界的发展速度，下面是 PyTorch 与 TensorFlow 原始统计表。

2018 年，PyTorch 是少数派。现在，它却已经占据绝对优势，使用 PyTorch 的 CVPR 占 比 69％，NAACL 和 ACL 的占比在 75％ 以上，而 ICLR 和 ICML 的占比在 50％ 以上。PyTorch 不仅 在视觉和语言会议上的统治地位最强（分别是 TensorFlow 的 2 倍和 3 倍），在诸如 ICLR 和 ICML 之类的综合机器学习会议上也比 TensorFlow 受欢迎。

尽管有些人认为 PyTorch 仍然是一个新贵框架，试图在 TensorFlow 主导的世界中开拓一席之地，但数据却揭示了另一个真相。除了 ICML 之外，TensorFlow 的增长速度甚至无法与论文增长速度保持同步。在 NAACL、ICLR 和 ACL 上，今年 TensorFlow 实现的论文实际上少于去年。

不是 PyTorch 需要担心它的未来，而是 TensorFlow。

为什么研究人员喜欢 PyTorch？

• 简单。它与 numpy 类似，非常具有 python 风格，并且可以轻松地与其他 Python 生态系统集成。例如，你可以在 PyTorch 模型中的任何地方简单地插入一个 pdb 断点就能用了。在TensorFlow 中，调试模型需要有效时间，且复杂得多。

• 很棒的 API。与 TensorFlow 的 API 相比，大多数研究人员更喜欢 PyTorch 的 API。一方面是因为 PyTorch 的设计更好，另一方面是 TensorFlow 多次切换 API（例如“图层”->“超薄”->“估算器”->“ 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 的统治地位可能会开始切断 Google 研究人员与其他研究社区的联系。他们不仅很难在外部研究的基础上进行构建，而且外部研究人员也不太可能在 Google 发布的代码基础上进行构建。

TensorFlow 2.0 是否将获得新的 TensorFlow 用户还有待观察。尽管 eager 模式一定会很吸引人，但对于 Keras API 就不一定了。

PyTorch和TensorFlow用于生产

尽管 PyTorch 现在在研究领域中处于主导地位，但快速过一下产业界就会发现，TensorFlow 仍然是主导框架。例如，基于 2018 年至 2019年 的数据，在公共招聘平台上，TensorFlow 的招聘岗位有 1541个，而 PyTorch 为 1437 个，Medium 文章中 TensorFlow 相关文章有 3230 篇，PyTorch 为 1200 篇，GitHub 上 TensorFlow 和 PyTorch 的 Star 数分别为 1.37 万个和 7.2k。

因此，如果 PyTorch 在研究人员中变得如此受欢迎，为什么它在工业上没有获得同样的成功呢？很明显，第一个答案就是惯性。TensorFlow 早于 PyTorch 出现，而且行业采用新技术的速度比研究人员要慢。另一个原因是 TensorFlow 在生产方面比 PyTorch 更好。但是，这是什么意思？

要回答这个问题，我们需要知道研究人员和行业的需求有何不同。

研究人员关心他们能够以多快的速度进行研究，这类研究通常是在相对较小的数据集（可以容纳在一台计算机上的数据集）上运行的，并且运行在 <8 个 GPU 上。通常，主要决定因素不在于性能方面，而在于快速实现他们的新想法的能力。另一方面，产业界认为性能是重中之重。尽管将运行时间提高 10％ 对研究人员而言毫无意义，但这可以直接为公司节省数百万美元的费用。

另一个区别是部署。研究人员将在自己的计算机或专用于运行研究工作的服务器集群上进行实验。另一方面，行业有很多限制/要求。

• 没有 Python。一些公司使用的服务器在 运行 Python 时开销太大。

• 移动。你无法在移动二进制文件中嵌入 Python 解释器。

• 服务。功能全面，例如无停机更新模型，在模型之间无缝切换，在预测时进行批处理等。

TensorFlow 是专门针对这些要求而构建的，并为所有这些问题提供了解决方案：图形格式和执行引擎本来就不需要 Python，TensorFlow Lite 和 TensorFlow Serving 分别解决了移动和服务上的顾虑。

从历史上看，PyTorch 未能满足这些考虑，因此大多数公司目前在生产中使用 TensorFlow。

框架“融合”

2018 年底，两个重大事件让事情变得棘手：

1. PyTorch 引入了 JIT 编译器和“ TorchScript”，从而引入了基于图形的功能。

2. TensorFlow 宣布默认情况下它们将转为 eager 模式。

显然，这些都是试图解决各自弱点的举动。那么这些功能到底是什么？它们提供了什么？

PyTorch Torch脚本

PyTorch JIT 是 PyTorch 的中间表示（IR），称为 TorchScript。TorchScript 是 PyTorch 的“图形”表示。你可以使用跟踪或脚本模式将常规 PyTorch 模型转换为 TorchScript。跟踪采用一个函数和一个输入，记录使用该输入执行的操作，并构造 IR。跟踪虽然简单明了，但也有其缺点。例如，它无法捕获未执行的控制流。再如，如果执行条件块，则无法捕获条件块的错误块。

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

一旦你的 PyTorch 模型进入此 IR，我们将获得图形模式的所有好处。我们可以在不依赖 Python的情况下以 C ++ 部署 PyTorch 模型，或对其进行优化。

Tensorflow Eager

在 API 层面，TensorFlow Eager 模式与 PyTorch 的Eager 模式基本相同，该模式最初因为 Chainer 流行起来。这为 TensorFlow 提供了 PyTorch Eager 模式的大多数优势（易于使用，可调试性等）。

但是，这也给 TensorFlow 带来了同样的缺点。TensorFlow Eager 模式无法导出到非 Python 环境，无法优化，无法在移动设备上运行等。

这使 TensorFlow 与 PyTorch 都面临着各自的问题，并且它们以基本相同的方式来解决——你可以跟踪代码（tf.function）或重新解释 Python 代码（Autograph）。

（图12-4 TensorFlow 如何使用 autograph 和跟踪生成图像）

因此，TensorFlow 的 Eager 模式并不能真正为你提供“两全其美”的体验。虽然确实可以使用tf.function 批注将 eager 代码转换成静态图形，但这绝不是一个无缝的过程（PyTorch 的TorchScript 也存在类似的问题）。跟踪从根本上受到限制，并且重新解释 Python 代码本质上需要重写许多 Python 编译器。当然，通过限制深度学习中使用的 Python 子集，可以大大缩小范围。

默认情况下，在启用 Eager 模式时，TensorFlow 会强制用户进行选择——使用 eager execution 以简化使用并需要重写以进行部署，或者完全不使用 eager execution。这一点TensorFlow 与 PyTorch 相同，但 PyTorch 的 TorchScript 可供选择，这可能比 TensorFlow 的“默认 eager”更让人愉快。

机器学习框架现状

因此，我们得出了 ML 框架的当前状态。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 在这方面的重大进展。

• Google 在产业界的孤立会伤害到它吗？Google 推动 TensorFlow 的主要原因之一是帮助其迅速发展的云服务。由于 Google 试图占整个 ML 框架垂直市场，这激励了 Google 的竞争对手（微软、亚马逊、英伟达）支持这个唯一可与之抗衡的机器学习框架。

下一步是什么？

机器学习框架对机器学习研究的影响也许被低估了。它们不仅支持机器学习研究，它们还促进或限制了研究人员轻松探索的想法。单是因为没有简单的方法可以在框架中表达，多少新生的想法被扼杀在摇篮之中？PyTorch 可能已经达到了本地研究的最低要求，但是继续挖掘其他框架能够提供的能力，以及它们可能带来的研究机会也是值得探索的。

高阶微分：

PyTorch 和 Tensorflow 的核心是自动分化框架。也就是说，它们允许人们采用某些函数的导数。但是，有许多方法可以实现自动分化，而大多数现代 ML 框架选择的特定实现为“反向模式自动分化”，通常称为“反向传播”。事实证明，此实现对于采用神经网络极为有效。

但是，计算高阶导数（Hessian / Hessian 矢量乘积）时情况发生了改变。有效地计算这些值需要所谓的“前向模式自动分化”。如果没有此功能，则计算 Hessian Vector Products 的速度可能会慢几个数量级。

输入 Jax。Jax 和 Autograd 的发明者是同一拨人，并具有正向和反向模式自动分化功能。这使得高阶导数的计算速度比 PyTorch / TensorFlow 快。

但是，Jax 不仅提供高阶导数。Jax 开发人员将 Jax 视为组成任意功能转换的框架，包括vmap（用于自动批处理）或 pmap（用于自动并行化）。

最初的 autograd 拥有忠实的粉丝（尽管没有 GPU 支持，ICML 上仍 有 11 篇论文使用了它），而且 Jax 可能很快就会形成一个忠实社区，将其用于各种 n 阶导数。

代码生成

当你运行 PyTorch / TensorFlow 模型时，大多数工作实际上不是在框架本身中完成的，而是由第三方内核完成的。这些内核通常由硬件供应商提供，并且由高级框架可以利用的 operator libraries 组成。这些就是 MKLDNN（用于CPU）或 cuDNN（用于Nvidia GPU）之类的东西。更高级别的框架将其计算图分成多个块，然后可以调用这些计算库。这些库代表数千个小时的人工，并且经常针对体系结构和应用程序进行优化，以产生最佳性能。

但是，最近对非标准硬件、稀疏/量化张量和新 operators 的兴趣暴露了依赖这些 operators libraries 的主要缺陷：它们不灵活。如果你想在研究中使用像胶囊网络这样的新operator 怎么办？如果要在 ML 框架没有很好支持的新硬件加速器上运行模型怎么办？现有的解决方案经常达不到要求，比如在 GPU 上实现胶囊网络比最佳实现要慢 2 个数量级。

每个新的硬件体系结构、张量类别或运算符，都会大大增加此问题的难度。有许多工具可以解决不同方面的问题（Halide、TVM、PlaidML、Tensor Comprehensions、XLA、Taco等），但是扔不清楚正确的方法到底是什么。

如果没有更多的工作来解决这个问题，我们就有将 ML 研究过度适合于我们拥有的工具的风险。

ML框架的未来

TensorFlow 和 PyTorch 的设计已经趋于一致，以至于任何一个框架都不会凭借其设计获得决定性的胜利。双方各占一方领土——一个拥有研究界，另一方拥有产业界。

在我个人看来，在 PyTorch 和 TensorFlow 之间，我认为 PyTorch 更有优势。机器学习仍然是研究驱动的领域。产业界不能忽视研究成果，只要 PyTorch 主导研究，这将迫使公司做出选择。

但是，正在快速发展的不仅是框架。机器学习研究本身也处于不断变化的状态。框架不仅会发生变化，而且 5 年内使用的模型/硬件/范例可能与我们今天使用的模型/外观大不相同。随着另一种计算模型的普及，也许 PyTorch 和 TensorFlow 之间的斗争将变得无关紧要。