pytorch 1.0将会在今年夏天发布,将于Caffe2合并支持研究和生产环境

Song • 1043 次浏览 • 0 个回复 • 2018年05月03日

通往1.0的道路:生产就绪PyTorch

PyTorch团队2018年5月2日发布公告。

我们想给你一个关于PyTorch 1.0的路线图的预览,PyTorch的下一个版本是1.0。在过去的一年中,我们已经将0.2,0.30.4``PyTorch[Torch + Chainer]类接口转换为更干净的接口,增加了double-backwards,类似numpy的函数,高级索引和删除Variable。目前,我们确信API处于合理稳定的状态,可以放心地发布1.0版本。

但是,1.0不仅仅是界面的稳定性。

PyTorch的最大优势之一是其一流的Python集成,强制性的风格,简单的API和选项。这些都是PyTorch有利于研究和可操作的方面。

其最大的缺点之一是支持生产环境。我们所说的生产支持指的是对模型进行无数次的训练,才能在大规模的范围内有效地运行它们:

  • 导出到C++ - 仅用于大型项目的运行时
  • 优化iPhoneAndroidQualcomm和其他系统上的移动系统
  • 使用更高效的数据布局和执行内核融合来做更快的推理(节省10%的速度和内存是一个巨大的胜利)
  • 量化推理(如8位推理)

初创公司,大公司以及任何想要围绕PyTorch构建产品的人都要求提供产品支持。在FacebookPyTorch的支持者),我们拥有Caffe2,它已经是支持生产环境,运行在我们的数据中心,并向跨8代iPhone和6代Android CPU架构的超过10亿部手机发货。它在Intel / ARM,TensorRT支持以及所有生产所需的位上都有服务器优化推理。考虑到PyTorch团队与其密切合作的平台锁定了所有这些价值,我们决定将PyTorch和Caffe2结合,从而为PyTorch提供生产级作准备。

为我们的研究人员和终端用户支持生产功能而不增加可用性问题需要创造性解决方案。

Production != Pain for researchers

增加生产能力涉及增加模型的API复杂性和可配置选项的数量。一个配置内存布局(NCHW vs NHWC vs N,C/32,H,W,32,,每个提供不同的性能特性),量化(8-bit? 3-bit?),融合的低级内核(我们使用Conv + BatchNorm + ReLU,将它们融合到一个单独的内核中),分离后端选项(后端MKLDNN为几层并且NNPACK后端用于其他层)等。

PyTorch的核心目标是为研究和可操作性提供一个很好的平台。所以,在我们添加所有这些优化的同时,我们一直在努力设计一个严格的约束,以避免将这些优化与可用性进行交易。

为了解决这个问题,我们介绍torch.jit,了一个即时(JIT)编译器,它在运行时将您的PyTorch模型重写为以生产效率运行。JIT编译器还可以导出你的模型来在C++Caffe2上运行。

在1.0中,你的代码继续工作,我们没有对现有的API做任何大的改变。

使您的模型可以运用到生产环境是一个opt-in注释,它使用torch.jit编译器将您的模型导出到无Python环境并提高其性能。让我们详细介绍JIT编译器。

torch.jit:您模型的JIT编译器

我们坚信,将您的模型直接指定为惯用Python代码所带来的生产力很难相匹配。这就是PyTorch如此灵活的原因,但这也意味着PyTorch几乎永远不会知道接下来要运行的操作。然而,这对于导出/生产和重量级自动性能优化来说是一个很大的阻碍因素,因为它们需要充分了解计算在执行之前的外观。

我们提供两种选择性的方式从代码中恢复这些信息,一种是基于追踪本地Python代码,另一种是基于编译注释为python的中间表示形式的Python语言子集。经过充分的讨论后,我们得出结论,他们都将在不同的环境中发挥作用,因此您可以自由混合搭配。

追踪模式

PyTorch tracer torch.jit.trace是一个函数,它记录了在代码区执行的所有本地PyTorch操作,以及它们之间的数据依赖关系。事实上,PyTorch从0.3开始就有了一个示踪器,它已被用于通过ONNX导出模型。现在发生的变化是,您不再需要追踪并在别处运行它 - PyTorch可以使用精心设计的高性能C ++运行时为您重新执行它。当我们开发PyTorch 1.0时,这个运行时将集成Caffe2提供的所有优化和硬件集成。

这种方法的最大好处是它并不关心你的Python代码是如何构建的 - 你可以通过生成器或协程,模块或纯函数来追踪。由于我们仅记录本地PyTorch操作员,因此这些详细信息对记录的跟踪没有影响。然而,这种行为是一把双刃剑。例如,如果模型中有一个循环,它将在循迹中展开,插入循环体的一个副本,循环的次数与循环的运行次数相同。这为零成本抽象提供了机会(例如,你可以遍历模块,而实际的跟踪将是循环开销免费的!),但另一方面,这也会影响与数据相关的循环(想想例如处理变化的序列长度),有效地将单个长度硬编码到迹线中。

对于不包含循环和if语句的网络,跟踪是非侵入式的,并且足够健壮以处理各种编码风格。此代码示例说明了跟踪的样子:

# This will run your nn.Module or regular Python function with the example
# input that you provided. The returned callable can be used to re-execute
# all operations that happened during the example run, but it will no longer
# use the Python interpreter.
from torch.jit import trace
traced_model = trace(model, example_input=input)
traced_fn = trace(fn, example_input=input)

# The training loop doesn't change. Traced model behaves exactly like an
# nn.Module, except that you can't edit what it does or change its attributes.
# Think of it as a "frozen module".
for input, target in data_loader:
    loss = loss_fn(traced_model(input), target)

脚本模式

跟踪模式是一种减少对代码的影响的好方法,但我们对基本上使用控制流的模型(例如RNN)也非常兴奋。我们的解决方案是一种脚本模式。

在这种情况下,您需要编写一个常规的Python函数,但不能再使用某些更复杂的语言功能。一旦你隔离了所需的功能,你就让我们知道你希望函数能够通过装饰@script器来装饰它。这个注解将把你的python函数直接转换成我们的高性能C ++运行时。这让我们可以恢复所有PyTorch操作以及循环和条件。它们将嵌入到我们对此函数的内部表示中,并且每次运行此函数时都会计入它们。

from torch.jit import script

@script
def rnn_loop(x):
    hidden = None
    for x_t in x.split(1):
        x, hidden = model(x, hidden)
    return x

优化和导出

无论您是使用跟踪还是使用跟踪@script,结果都是模型的python-free表示,可用于优化模型或从python中导出模型以用于生产环境。

将模型的更大部分提取到中间表示中,可以执行复杂的整体程序优化,并将计算卸载到专门用于计算图形的AI加速器。我们已经在开发这些优化的开始,包括将GPU操作融合在一起以提高较小RNN模型性能的通行证。

它还使我们能够使用Caffe2现有的高性能后端高效运行模型。此外,@script功能(和模块!)可以以保持其动态特性的方式完全导出到ONNX,以便您可以使用Caffe2的模型执行器轻松地在无Python环境中运行它们,或者通过将模型转换为任何其他支持ONNX的框架。

可用性

我们非常关心保持当前的可用性水平,并且我们知道,不直接在Python中执行代码会导致调试更难,但这是我们想到的很多事情,并且我们确保您没有得到锁定在一个完全不同的编程语言。

首先,我们遵循付费原则 - 如果您不需要优化或导出模型,则不必使用这些新功能,也不会看到任何缺点。此外,可以逐步使用跟踪或@script模块/函数。例如,所有这些行为都是允许的:您可以跟踪部分模型,并在较大的未跟踪模型中使用跟踪。您可以对模型的90%使用跟踪,并将@script用于实际上具有一定控制流的子模块。你可以使用@script编写一个函数,并让它调用一个本地python函数。如果@script函数中出现错误,您可以删除注释,代码将在本地python中执行,您可以使用自己喜欢的工具和方法轻松进行调试。

最重要的是,这些模式将被构建到PyTorch的核心中,以便与您现有的代码混合并匹配它们可以无缝地进行。

注意:这些组件的名称JIT有点不恰当,并且源于历史原因。PyTorch中的跟踪/函数执行从一个优化的JIT编译器开始,它生成融合的CUDA内核,但随后发展到包含优化,@script和导出。当它准备发布时,我们可能会将此功能重新命名为混合前端,但我们希望在此代表它,因为它是在代码中命名的,以便您可以在开发过程中遵循此功能。

其他更改和改进

支持生产环境是1.0的重要特性,但我们将继续优化和修复PyTorch的其他部分,作为标准发布过程的一部分。

在事物的后端,PyTorch会看到一些变化,这可能会影响用户编写的CC ++扩展。我们正在替换(或重构)后端ATen库,以整合Caffe2的功能和优化。

最后的话

Pytorch 1.0预计在今年夏天推出。您可以在Pull Requests上跟进Pytorch1.0的开发进度。

您可以从Caffe2项目的角度阅读以下内容:https://caffe2.ai/blog/2018/05/02/Caffe2_PyTorch_1_0.html


原创文章,转载请注明 :pytorch 1.0将会在今年夏天发布,将于Caffe2合并支持研究和生产环境 - pytorch中文网
原文出处: https://ptorch.com/news/167.html
问题交流群 :168117787
提交评论
要回复文章请先登录注册
用户评论
  • 没有评论
Pytorch是什么?关于Pytorch! pytorch使用numpy和scipy创建扩展