編者按：今天是Facebook F8年度開發(fā)者大會(huì)的第二天，繼5月2日發(fā)布約會(huì)功能、新隱私保護(hù)功能、Oculus Go VR頭盔等消息后，3日Facebook又帶來了機(jī)器學(xué)習(xí)方面的一些重大更新，包括即將在夏季末發(fā)布的Pytorch 1.0和新開源的圍棋AI項(xiàng)目。以下是論智編譯的Pytorch 1.0公告。

Pytorch源：pytorch.org/2018/05/02/road-to-1.0.html

Caffe2源：caffe2.ai/blog/2018/05/02/Caffe2PyTorch1_0.html

Caffe2公告摘要

構(gòu)建和包

在Pytorch 1.0中，Caffe2和PyTorch的python軟件包（在pip和conda中）會(huì)合并；

繼續(xù)提供本地庫(kù)和python擴(kuò)展作為單獨(dú)的安裝選項(xiàng)（和Caffe2和PyTorch現(xiàn)狀一樣）；

所有交叉編譯的構(gòu)建模式均支持Caffe2平臺(tái)（iOS，Android，Raspbian，Tegra等），將繼續(xù)拓展新平臺(tái)支持。

模型生成（前端）

Caffe2的圖形構(gòu)建API（brew，core.Net）繼續(xù)保留，現(xiàn)有的序列化模型NetDefs會(huì)擁有向后兼容性；

nn.Module-like將成為構(gòu)建神經(jīng)網(wǎng)絡(luò)的首選。Pytorch 1.0會(huì)用“混合前端”取代現(xiàn)有前端，它利用跟蹤和編譯功能，能以圖形格式（兼容Caffe2的NetDef和ONNX）提取完全序列化的模型，可用于高效部署。

Caffe2和PyTorch的運(yùn)算符將合并使用；

PyTorch 1.0能本地支持ONNX，連接其他框架或庫(kù)以便提取、傳遞模型。

精簡(jiǎn)和整合

Caffe2高度可擴(kuò)展的執(zhí)行引擎（各種加速后端和庫(kù)集成和可伸縮圖執(zhí)行器）基本保持不變，還能與Python程序段交互操作，以實(shí)現(xiàn)快速原型設(shè)計(jì)；

Caffe2現(xiàn)有的predictor支持會(huì)成為本地模型在加速硬件支持上的主要手段（數(shù)據(jù)中心和移動(dòng)設(shè)備可用）。

硬件集成和加速庫(kù)支持

在PyTorch 1.0軟件包的原型環(huán)境中直接提供Caffe2的各種設(shè)備支持和運(yùn)行集成；

保留Caffe2針對(duì)加速硬件或完整圖形運(yùn)行的大部分接口代碼，現(xiàn)有集成仍然有效。對(duì)于圖形運(yùn)行，官方正致力于ONNX的可視化。

Pytorch公告全文

親愛的Pytorch用戶，

在這篇文章中，我們想帶你預(yù)覽一下Pytorch 1.0的發(fā)展路線。Pytorch 1.0是Pytorch的下一代版本，在過去一年中，我們陸續(xù)推出了PyTorch0.2、0.3和0.4，并把原先類似[Torch + Chainer]的接口轉(zhuǎn)換成了更簡(jiǎn)潔的形式，我們還引入double-backward、類似numpy的函數(shù)、高級(jí)索引，同時(shí)刪除了變量樣板。截至目前，我們確信所有API都處于穩(wěn)定合理的狀態(tài)，因此現(xiàn)在也是時(shí)候可以放心發(fā)布Pytorch 1.0了。

但是，Pytorch 1.0不僅僅意味著更高的穩(wěn)定性。

Pytorch最大的優(yōu)勢(shì)之一是一流的Python集成水平，強(qiáng)制性的風(fēng)格、簡(jiǎn)單的API選項(xiàng)，這些都是它方便用戶研究和操作的重要因素。但它也有不少缺點(diǎn)，其中最大的一點(diǎn)是“production-support”。這意味著為了更高效地大規(guī)模運(yùn)行神經(jīng)網(wǎng)絡(luò)，用戶必須對(duì)模型進(jìn)行大量處理：

做大型項(xiàng)目時(shí)，用戶需要把模型導(dǎo)出到C++；

要針對(duì)iPhone、Android、Qualcomm等其他移動(dòng)設(shè)備系統(tǒng)和硬件進(jìn)行優(yōu)化；

為了更快地推斷，用戶需要使用更高效的數(shù)據(jù)布局和執(zhí)行內(nèi)核融合（節(jié)省10%地耗時(shí)和內(nèi)存占用已經(jīng)稱得上是個(gè)巨大勝利）；

量化精度（如8-bit推斷）。

許多初創(chuàng)公司、大公司以及一些想用PyTorch構(gòu)建產(chǎn)品的個(gè)人用戶都曾向我們要求提供產(chǎn)品支持。在Facebook（PyTorch最大的利益相關(guān)者），我們已經(jīng)有了Caffe2這個(gè)面向移動(dòng)設(shè)備的平臺(tái)，它曾在超過10億部手機(jī)上運(yùn)行，橫跨8代iPhone和6代Android CPU架構(gòu)。為了能更好地支持Intel / ARM、TensorRT，它也優(yōu)化過服務(wù)器推斷?？紤]到PyTorch團(tuán)隊(duì)想開發(fā)的內(nèi)容和Caffe2已經(jīng)成熟的功能基本一致，因此我們決定結(jié)合PyTorch和Caffe2，讓后者為PyTorch提供生產(chǎn)支持。

有了它，研究人員和終端用戶就能在不產(chǎn)生可用性問題的基礎(chǔ)上進(jìn)行產(chǎn)品設(shè)計(jì)，而這需要?jiǎng)?chuàng)造性的解決方案。

生產(chǎn)！= 研究人員的痛點(diǎn)

提高PyTorch的生產(chǎn)能力意味著要引入更復(fù)雜的API和更多的可配置選項(xiàng)的數(shù)量。詳細(xì)來說，就是一個(gè)配置內(nèi)存布局（NCHW vs NHWC vs N、C/32、H、W、32，每個(gè)提供不同的性能特性），量化精度（8-bit？3-bit？），低水平內(nèi)核融合（把Conv + BatchNorm + ReLU融合進(jìn)一個(gè)內(nèi)核），以及分離后端選項(xiàng)（把MKLDNN作為某幾層的后端，NNPACK作為剩余層的后端）等。

PyTorch的核心目標(biāo)是為研究和操作提供一個(gè)良好的平臺(tái)，因此除了以上這些優(yōu)化，我們也一直致力于設(shè)計(jì)一個(gè)嚴(yán)格的約束，以避免因完善功能犧牲用戶體驗(yàn)。

為了做到這一點(diǎn)，我們這次推出了torch.jit——一個(gè)即時(shí)（JIT）編譯器，它能在運(yùn)行時(shí)重寫用戶模型并實(shí)現(xiàn)快速產(chǎn)品化。這個(gè)新的JIT編譯器還能把模型遷移到C++上，然后以Caffe2的比特精度運(yùn)行。

對(duì)于Pytorch 1.0，你的代碼可以持續(xù)運(yùn)行，但我們沒有對(duì)已有API做過多調(diào)整。

當(dāng)然，這是一個(gè)可選項(xiàng)。用戶可以使用torch.jit編譯器把自己的模型導(dǎo)出到無Python環(huán)境并提高其性能。下面讓我們對(duì)它做一下詳細(xì)介紹。

torch.jit：一個(gè)為模型設(shè)計(jì)的即時(shí)編譯器

我們堅(jiān)信一點(diǎn)，如果直接用Python代碼寫一個(gè)模型來應(yīng)用，它的適用性太低了。這也是PyTorch為什么這么靈活的原因，但有得必有失，如果用戶不下指令，PyTorch就不知道接下來該運(yùn)行哪一段。這對(duì)生產(chǎn)和自動(dòng)性能優(yōu)化來說是個(gè)不小的問題，因?yàn)樵趫?zhí)行代碼前，它們需要獲知模型的整體情況。

為了解決這個(gè)問題，我們提供了兩種從代碼中恢復(fù)信息的方法，一種基于追蹤本地Python代碼，另一種則基于編譯表示中間形態(tài)的Python語言子集。經(jīng)過充分討論后，我們認(rèn)為它們?cè)诓煌h(huán)境中都由突出表現(xiàn)，因此用戶可以搭配使用。

追蹤模式

PyTorch tracer是一個(gè)函數(shù)torch.jit.trace，它記錄了當(dāng)前代碼區(qū)執(zhí)行的所有本地PyTorch操作和它們之間的數(shù)據(jù)依賴關(guān)系。其實(shí)早在PyTorch 0.3時(shí)我們就提供了類似功能，它能被用于通過ONNX導(dǎo)出模型。而Pytorch 1.0的變化在于你可以在C++運(yùn)行過程中就直接執(zhí)行追蹤，而不需要到別處。C++運(yùn)行期間，Pytorch 1.0將集成Caffe2提供的所有優(yōu)化和硬件集成。

而這種方法的最大好處是它并不關(guān)心你的Python代碼是怎么寫的，由于我們只記錄本地的Pytorch操作，這些詳細(xì)信息對(duì)記錄的跟蹤并沒有影響。但它也是把雙刃劍，如果一個(gè)模型中包含了循環(huán)，它會(huì)把循環(huán)展開，每做一次循環(huán)就插入一個(gè)副本，這樣副本數(shù)量就多得和循環(huán)次數(shù)相等了。但另一方面，這樣做適合和數(shù)據(jù)相關(guān)的一些循環(huán)，比如用于處理變化的序列，這種方法能有效地將單個(gè)長(zhǎng)度硬編碼到循環(huán)過程中。

對(duì)于不包含循環(huán)和if語句的神經(jīng)網(wǎng)絡(luò)，追蹤模式是非侵入式的，它能高性能處理各種編碼風(fēng)格，如下所示：

# 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)

script模式

追蹤是一種好方法，但我們希望能為一些涉及大量循環(huán)的模型，如RNN，提供同樣優(yōu)秀的解決方案。這就是我們接著要介紹的script模式。

在script模式下，除了無法使用一些特殊的語言功能，用戶只需寫一個(gè)常規(guī)的Python函數(shù)。一旦你隔離其他函數(shù)，用@script標(biāo)記出你想要編譯的函數(shù)，Pytorch 1.0就會(huì)為這個(gè)python函數(shù)添加注釋并轉(zhuǎn)換成高性能C++代碼運(yùn)行。這就做到了恢復(fù)恢復(fù)所有PyTorch操作及其循環(huán)、條件。它們將嵌入到我們對(duì)此函數(shù)的內(nèi)部表示中，并且每次運(yùn)行此函數(shù)時(shí)都會(huì)計(jì)入它們。

from torch.jit import script

@script

def rnn_loop(x):

hidden = None

forx_tin x.split(1):

x, hidden = model(x, hidden)

return x

優(yōu)化和導(dǎo)出

無論最終用戶用的是追蹤模式還是script模式，Pytorch 1.0輸出的都會(huì)是一個(gè)非Python的模型表示。它可用于模型優(yōu)化，或從python中導(dǎo)出模型用于生產(chǎn)環(huán)境。

像這種將大部分模型信息提取為中間表示的做法有助于執(zhí)行復(fù)雜的整體程序優(yōu)化，在這個(gè)背景下，我們可以把計(jì)算分配給專門用來計(jì)算圖形的AI加速器，以提高整體效率。事實(shí)上我們也正在這么做，我們已經(jīng)在嘗試融合GPU操作提高小型RNN的性能，成效斐然。

它還意味著用戶能使用Caffe2現(xiàn)有的高性能后端高效運(yùn)行模型。此外，用@script標(biāo)記的函數(shù)和模塊還可以以動(dòng)態(tài)的方式導(dǎo)出到ONNX，這就意味著它們可以輕松地在非Python語言環(huán)境中運(yùn)行。

可用性

可用性是我們十分關(guān)注的一個(gè)點(diǎn)，我們知道，如果不是直接在Python里運(yùn)行代碼，模型后期調(diào)試起來會(huì)很麻煩，但我們希望能做更多的事，而不是把用戶局限在一種編程語言上。

首先，這是一項(xiàng)付費(fèi)服務(wù)——如果用戶不需要優(yōu)化和導(dǎo)出模型，他們就不用在意這些新功能，也不會(huì)看到其中的缺陷。其次，追蹤模式和script模式是可以逐步使用的，例如用戶可以追蹤部分模型、在大型未追蹤模型中嵌入追蹤模式、對(duì)模型的90%使用追蹤、只對(duì)循環(huán)代碼使用@script……他們可以用@script編寫一個(gè)函數(shù)，并讓它調(diào)用一個(gè)本地python函數(shù)，如果@script函數(shù)中出現(xiàn)錯(cuò)誤，他們也可以刪除注釋?？偠灾?，用戶喜歡怎么調(diào)試，就可以怎么調(diào)試。

最重要的是，這些模式將被構(gòu)建到PyTorch的核心中，以便與用戶現(xiàn)有代碼混合并無縫運(yùn)行。

其他更新與改進(jìn)

“production-support”是Pytorch 1.0最重要的特征，但作為標(biāo)準(zhǔn)發(fā)布過程的一部分，我們也會(huì)繼續(xù)優(yōu)化和修復(fù)PyTorch的其他內(nèi)容。

在后端，PyTorch的一些更新可能會(huì)影響用戶編寫C和C ++的擴(kuò)展。因?yàn)槲覀冋谔鎿Q（或重構(gòu)）后端ATen庫(kù)，以整合來自Caffe2的功能和優(yōu)化。