整合PyTorch 0.4和Caffe 2,PyTorch 1.0能挑戰TensorFlow嗎?
譯者 | 梁紅麗
編輯 | Mavis
出品 | AI科技大本營(公眾號ID:rgznai100)
【AI 科技大本營導讀】5月2日,在加利福尼亞州舉辦的年度開發者 F8 大會上,Facebook 正式推出 PyTorch 1.0 。其實,早在 2017 年 1 月,Facebook 就首次公布了該信息,截至目前,它已被下載超過 110 萬次,是過去一個月研究門戶網站 Arxiv 上的第二大深度學習框架,排名第一的是 TensorFlow 。
另外,手握 ArXiv Sanity 大數據的特斯拉人工智慧部門主管 Andrej Karpathy 給出的精確數據顯示,過去一個月,各個框架在論文中被提到(單次計算)的比例分別是:TensorFlow 14.3% ,PyTorch 4.7% ,Keras 4.0% ,Caffe 3.8% ,Theano 2.3% ,Torch 1.5% ,MXNet 、Chainer 和 CNTK 均小於 1%。
2017 年 3 月,Karpathy 第一次做這個全面統計的時候,各框架的排名是:
對比兩組數據可以發現,PyTorch 漲勢驚人,看來想要挑戰 TensorFlow ,並不是沒有可能。接下來,和營長一起了解下 PyTorch 1.0 。
過去幾年中,Facebook 發行了 0.2 , 0.3 , 0.4 幾個版本,從類似 Torch+Chainer 的界面改組為試驗版本,增加了雙擊後退、numpy-like 函數、高級索引和刪除變數功能,且界面更清晰。
但是,1.0 的界面不僅僅是穩定性有所提高。
PyTorch 最大的優勢之一就是一流的 Python 交互、命令式風格、API 和選項簡約,所有這些特點都使 PyTorch 利於研究和整改。
PyTorch 最大的缺點一直以來都是產品支持。「產品支持」指為了使模型在大規模使用時高效運行而必須對其做出的不計其數的修改,包括:
在大項目中,將模型輸出到只支持 C++ 的環境中使用;
優化 iPhone,Android,Qualcomm 和其他系統的移動端系統;
用更高效的數據框架和內核加快推理(大規模使用中速度加快 10% 或內存減少 10% 就是重大勝利)。
量化推理
初創公司、大公司和任何想用 PyTorch 做產品的人都要求提供產品支持。在 Facebook,我們有 Caffe2,它隨時可以投產,在數據中心運行、被載入超過 10 億部手機中,包括八代的 iPhone 和六代的 Android CPU 架構。它有 Intel/ARM 的伺服器優化推理,TensorRT 支持和所有產品生產所必須的條件。考慮到所有這些有價值的特點都集成在與 PyTorch 團隊工作如此貼近的平台上,我們決定將 PyTorch 和 Caffe2 進行嫁接,使 PyTorch 可直接用於產品。
▌產品 != 研究者的痛
增加產品功能需要提高 API 的複雜度和模型設置選項的數量。模型設置項有內存配置(NCHW vs NHWC vs N,C/32, H, W,32,每個的表現都不同)、量化 bit 數(8 bit 或 3 bit?)、用於組合的低層核(如將 Conv+BatchNorm+ReLU 組合為單核)、可分層選擇的後端(例如幾層用MKLDNN,另外幾層用 NNPACK)等。
PyTorch 的中心目標是為研究和可修改性提供良好平台,因此,加入這些優化的同時,我們也進行了硬體設計,以使這些優化不影響使用。
為了完成這一目標,我們引入了 torch.jit ——一個即時( JIT )編譯器,它在運行時使用 PyTorch 模型並將其重寫,使其以產品效率運行。即時編譯器還可以將模型輸出到基於 Caffe2 bit 的 C++ 環境。
1.0 版本中,你的代碼可一如既往地使用,我們對當前 API 沒有做大的改動。
▌Torch.jit:模型的即時編譯器
我們深知將具體模型直接寫為 Python 代碼來滿足效率並不容易,這是 PyTorch 如此靈活的原因,但這也意味著 PyTorch 很可能不知道你下一步要運行什麼。這會阻礙輸出/產品化和重量級自動性能優化,因為它們在執行前就需要如何進行計算的先驗知識。
我們提供了從代碼還原該信息的兩種方法,一種以追蹤本地 Python 代碼為基礎,一種以編譯 Python 語言子集並注釋為沒有 Python 的中間表示為基礎。深入討論後,我們得出結論:它們均可在不同環境中使用,所以你可以自由組合。
▌追蹤模式
PyTorch 追蹤器是一個記錄在代碼中執行的所有 PyTorch 本地操作及操作間數據依賴的函數。和之前的版本不同,在 1.0 版本中,不需要再記錄軌跡放在其他地方運行,PyTorch 會代你用認真設計的表現性能好的 C++ 環境重新執行。
這種方法的最大好處是,它不關心你的 Python 代碼是如何組織的,你可以通過生成器或協成程序( coroutines )、模塊或函數組進行追蹤。
對不包含循環和判斷的網路,追蹤是非侵入式的,且處理多種多樣的代碼風格時足夠穩定。下面的代碼提供了追蹤示例:
# 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)
▌腳本模式
追蹤模式是最小化代碼影響的很好方式,但我們對主要使用控制流的模型(如 RNNs )也頗有興趣,這種解決方式就是腳本模式。
這種情況下,你寫一個與常用 Python 函數幾乎相同的函數,只是你不能再用一些複雜的語言特徵。分離目標函數後,通過用裝飾器 @script 裝飾函數表示你想編譯該函數,該裝飾器就會把你的 Python 函數直接轉為表現性能良好的 C++ 環境。
▌優化和輸出
不管你是否使用追蹤和 @script,結果都是與 Python 無關的模型表示,可以用於優化模型或從 Python 輸出模型到產品環境。
將模型的更大組件提取到中間表示為以下兩項提供了可能:複雜的整體項目優化以及把計算載荷轉移到專門在計算圖上執行的 AI 加速器。我們已經著手開始這些優化,包括融合 GPU 操作的方法來提高小型 RNN 模型的性能。
我們也可以使用 Caffe2 中可用的現有高性能的後端來高效運行模型。此外,@script 函數(還有模塊)可以完全輸出到 ONNX 且保留其動態特性,這樣你便可以用 Caffe2 的模型執行器或把模型轉為其他支持 ONNX 的框架來方便地在沒有 Python 的環境中運行。
▌可用性
我們對維持當前可用性水平深表關心,我們知道,不在 Python 中直接運行代碼會加大調試難度,但關於這一點我們也考慮了很多,並保證不會陷入完全不同的編程語言。
首先,我們遵循按需付費的原則,如果你不需要優化或輸出模型,就不必使用這些新特點,也不會看到任何負面影響。另外,追蹤或 @script 模塊/函數可以遞進使用。
最重要的是,這些模式將建於 PyTorch 的核心部分,這樣可將它們與現有代碼進行無縫對接和匹配。
▌結語
產品支持是 1.0 的特點,但我們會在標準發行的同時繼續優化和改進 PyTorch 的其他部分。
在後端部分,PyTorch 會略有改動,這可能影響用戶編寫的 C 或 C++ 的拓展。我們正在替換後端 ATen library,旨在兼容 Caffe2 的特點和優化操作。
作者:PyTorch 團隊
https://pytorch.org/2018/05/02/road-to-1.0.html
GIF
AI科技大本營
公眾號ID:rgznai100
※李飛飛等提出新的迭代視覺推理框架,在ADE上實現8.4 %的絕對提升
TAG:AI科技大本營 |