編者按：今天是Facebook F8年度開發(fā)者大會的第二天，繼5月2日發(fā)布約會功能、新隱私保護功能、Oculus Go VR頭盔等消息后，3日Facebook又帶來了機器學習方面的一些重大更新，包括即將在夏季末發(fā)布的Pytorch 1.0和新開源的圍棋AI項目。以下是論智編譯的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公告摘要

構建和包

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

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

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

模型生成（前端）

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

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

Caffe2和PyTorch的運算符將合并使用；

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

精簡和整合

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

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

硬件集成和加速庫支持

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

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

Pytorch公告全文

親愛的Pytorch用戶，

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

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

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

做大型項目時，用戶需要把模型導出到C++；

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

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

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

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

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

生產！= 研究人員的痛點

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

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

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

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

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

torch.jit：一個為模型設計的即時編譯器

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

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

追蹤模式

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

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

對于不包含循環(huán)和if語句的神經網(wǎ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模式下，除了無法使用一些特殊的語言功能，用戶只需寫一個常規(guī)的Python函數(shù)。一旦你隔離其他函數(shù)，用@script標記出你想要編譯的函數(shù)，Pytorch 1.0就會為這個python函數(shù)添加注釋并轉換成高性能C++代碼運行。這就做到了恢復恢復所有PyTorch操作及其循環(huán)、條件。它們將嵌入到我們對此函數(shù)的內部表示中，并且每次運行此函數(shù)時都會計入它們。

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)化和導出

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

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

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

可用性

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

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

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

其他更新與改進

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

在后端，PyTorch的一些更新可能會影響用戶編寫C和C ++的擴展。因為我們正在替換（或重構）后端ATen庫，以整合來自Caffe2的功能和優(yōu)化。