摘要：兩者取長補短，所以深度學習框架在年，迎來了前后端開發(fā)的黃金時代。陳天奇在今年的中，總結(jié)了計算圖優(yōu)化的三個點依賴性剪枝分為前向傳播剪枝，例已知，，求反向傳播剪枝例，，求，根據(jù)用戶的求解需求，可以剪掉沒有求解的圖分支。

從發(fā)現(xiàn)問題到解決問題

半年前的這時候，暑假，我在SIAT MMLAB實習。

看著同事一會兒跑Torch，一會兒跑MXNet，一會兒跑Theano。

SIAT的服務(wù)器一般是不給sudo權(quán)限的，我看著同事掙扎在編譯這一坨框架的海洋中，開始思考：

是否可以寫一個框架：

這樣，利用工廠模式只編譯執(zhí)行部件的做法，只需編譯的后端即可，框架的不同僅僅在于前端腳本的不同。

Caffe2Keras的做法似乎是這樣，但Keras本身是基于Theano的編譯后端，而我們的更希望Theano都不用編譯。

當我9月份拍出一個能跑cifar10的大概原型的時候：

我為這種怪異的寫法取名叫CGVM(Computational Graph Virtual Machine)然后過了幾天，在微博上看到了陳天奇在MXNet的進一步工作NNVM的發(fā)布 .....

NNVM使用2000行模擬出了TensorFlow，我大概用了500行模擬出了Caffe1。

VM(Virtual Machine)的想法其實是一個很正常的想法，這幾年我們搞了很多新框架，名字一個比一個炫，但是本質(zhì)都差不多，框架的使用者實際上是苦不堪言的：

○ 這篇paper使用了A框架，我要花1天配置A框架。

○ 這篇paper使用了B框架，我要花1天配置B框架。

.......

正如LLVM不是一種編譯器，NNVM也不是一種框架，看起來更像是框架的屠殺者。

NNVM的可行性恰恰證明了現(xiàn)行的各大框架底層的重復性，而上層的多樣性只是一個幌子。

我們真的需要為僅僅是函數(shù)封裝不同的框架買單嗎？這是值得思考的。

計算圖走向成熟

計算圖的兩種形式

計算圖最早的出處應(yīng)該是追溯到Bengio在09年的《Learning Deep Architectures for AI》，Bengio使用了有向圖結(jié)構(gòu)來描述神經(jīng)網(wǎng)絡(luò)的計算:

如圖，符號集合{*，+，sin} 構(gòu)成圖的結(jié)點，整張圖可看成三部分：輸入結(jié)點、輸出結(jié)點、從輸入到輸出的計算函數(shù)。

隨后在Bengio組的Theano框架執(zhí)行中，Graph就被隱式應(yīng)用于Op的連接。

不過這時候，Op還是執(zhí)行時-動態(tài)編譯的。

Caffe1中計算圖其實就是Net，因為Net可以被Graph模擬出來(CGVM和Caffe2Keras都實現(xiàn)了)。

賈揚清在Caffe1中顯式化了計算圖的表示，用戶可以通過編輯net.prototxt來設(shè)計計算圖。

Caffe1在Jonathan Long和Evan Shelhamer接手后，他們開發(fā)了PyCaffe。

PyCaffe通過Python天然的工廠(__getattr__)，實現(xiàn)了net.prototxt的隱式生成。

之后的Caffe2，也就直接取消了net.prototxt的編輯，同樣利用Python的(__getattr__)獲取符號類型定義。

Caffe1帶來一種新的計算圖組織Op的描述方式，不同于Theano直接翻譯Op為C執(zhí)行代碼，然后動態(tài)編譯，軟件工程中的高級設(shè)計模式——工廠模式被廣泛使用。

計算圖被劃分為三個階段，定義階段、構(gòu)造階段、執(zhí)行階段：

1、定義階段：定義Layer/Op的name、type、bottom(input)，top(output)及預設(shè)參數(shù)。

2、構(gòu)造階段：通過工廠模式，由字符串化的定義腳本構(gòu)造類對象。

3、執(zhí)行階段：根據(jù)傳入的bottom(input)，得到額外參數(shù)(如shape)，此時計算圖才能開始執(zhí)行。階段劃分帶來的主要問題是限制了編譯代碼的完整性和優(yōu)化程度。

在Theano中，C代碼生成是最后一步，編譯前你可以組合數(shù)個細粒度符號，依靠編譯器做一次硬件執(zhí)行上的優(yōu)化。

而工廠模式編譯符號時只考慮了單元，編譯器沒有上下文可供參考優(yōu)化，故最終只能順序執(zhí)行多個預先編譯的符號單元。

當符號粒度過細時，一個Layer的實現(xiàn)就會變成連續(xù)執(zhí)行多個子過程，導致“TensorFlowSlow”。

計算圖作為中間表示(IR)

PyCaffe和Caffe2將定義階段移到Python中，而將構(gòu)造和執(zhí)行階段保留在C++中做法，是計算圖作為IR的思想啟蒙。

Python與C++較大的不同在于：一個是腳本代碼，用于前端。一個是本地代碼，用于后端。

腳本代碼創(chuàng)建/修改模型方便(無需因模型變動而重新編譯)、執(zhí)行慢，本地代碼則正好相反。

兩者取長補短，所以深度學習框架在2016年，迎來了前后端開發(fā)的黃金時代。

如上圖，無論是9月份先提出的NNVM，還是最近Intel曝光的Nervana，都分離了前后端。

后端的獨立，不僅減少了編譯工作，較大的優(yōu)勢在于降低了傳統(tǒng)框架做跨設(shè)備計算的代碼耦合度。

在paper每周都有一大堆的現(xiàn)在，如果后端的每一次變動都要大量修改前端，那么框架的維護開銷是非常大的。

在前端定義用于描述輸入-輸出關(guān)系的計算圖有著良好的交互性，我們可以通過函數(shù)和重載腳本語言的操作符，定義出媲美MATLAB的運算語言，這些語言以顯式的Tensor作為數(shù)據(jù)結(jié)構(gòu)，Operator作為計算符和函數(shù)，Theano和MXNet都是這樣隱蔽處理由表達式向計算圖過渡的。

而Caffe2則比較直接，你需要先創(chuàng)建一個Graph，然后顯示地調(diào)用Graph.AddOperator(xxx) TensorFlow同樣可以顯式化處理Graph。

與用戶交互得到的計算圖描述字串是的，但是與用戶交互的方式卻是不的。

所以IR之上，分為兩派：

第一派要搞自己的API，函數(shù)封裝非常有個性，宣示這是自己的專利、獨門語言。

第二派不搞自己的API，反而去模擬現(xiàn)有的API，表示我很低調(diào)。

顯然，用戶更喜歡用自己熟悉框架的寫法去描述模型，不喜歡天天背著個函數(shù)速查手冊。

計算圖優(yōu)化

用于中間表示得到的計算圖描述較好不要直接構(gòu)造，因為存在冗余的求解目標，且可共享變量尚未提取。

當限制計算圖描述為有向無環(huán)圖(DAG)時，一些基本的圖論算法便可應(yīng)用于計算圖描述的化簡與變換。

陳天奇在今年的MSR Talk：Programming Models and Systems Design for Deep Learning中，總結(jié)了計算圖優(yōu)化的三個點：

①依賴性剪枝

分為前向傳播剪枝，例：已知A+B=X，A+B=Y，求X？

反向傳播剪枝, ?例：A+B=X，A+B=Y，求X、Y，dX/dA？

根據(jù)用戶的求解需求，可以剪掉沒有求解的圖分支。

②符號融合

符號融合的自動實現(xiàn)是困難的，因為Kernel基本不再實時編譯了，所以更多體現(xiàn)在符號粗細粒度的設(shè)計上。

粗粒度的符號融合了數(shù)個細粒度的符號，一次編譯出連續(xù)多個執(zhí)行步驟的高效率代碼。

粗粒度和細粒度并無好壞區(qū)分，一個速度快，一個更靈活。

從貪心角度，VM框架通常會提供粗細粒度兩種實現(xiàn)給用戶，因而需要更多人力維護編譯后端。

③內(nèi)存共享

Caffe1對于激活函數(shù)大多使用的inplace處理——即bottom和top是同一個Blob。

inplace使用新的輸出y立即覆蓋的輸入x，需要以下兩個條件：

1、bottom和top數(shù)量都為1，即：計算圖中構(gòu)成一條直線路徑，

2、d(y)/d(x)與x是無關(guān)的，所以x被y覆蓋不影響求導結(jié)果。

常見的激活函數(shù)都符號以上兩個條件，因而可以減少內(nèi)存的開銷。

但是Caffe1在多網(wǎng)絡(luò)內(nèi)存共享優(yōu)化上極其糟糕的，以至于Caffe1并不適合用來跑GAN，以及更復雜的網(wǎng)絡(luò)。

一個簡單例子是交叉驗證上的優(yōu)化：訓練網(wǎng)絡(luò)和驗證網(wǎng)絡(luò)的大部分Layer都是可以共享的，但是由于Caffe1錯誤地將Blob獨立的放在每個Net里，使得跨Net間很難共享數(shù)據(jù)。

除此之外，Caffe1還錯誤地將臨時變量Blob獨立放在每個Layer里，導致列卷積重復占用幾個G內(nèi)存。

讓Net和Layer都能共享內(nèi)存，只需要將Tensor/Blob置于最頂層，采用MVC來寫框架即可。

Caffe2引入了Workspace來管理Tensor，并將工作空間的指針傳給每一個Op、每一個Graph的構(gòu)造函數(shù)。

新的風暴已經(jīng)出現(xiàn)

VM的側(cè)重點

CGVM和NNVM的側(cè)重點是不太一樣的，CGVM更強調(diào)前端上的擴展化，后端上的化。

所以CGVM不會去支持Torch編譯后端，也不會去支持Caffe編譯后端。

在NNVM的知乎討論帖中，有一種觀點認為VM是輕視Operator的實現(xiàn)。

但實際上，我們手里的一堆框架，在Operator、Kernel、Math級別的不少實現(xiàn)是沒有多少區(qū)別的。

但恰恰折磨用戶的正是這些沒有多少區(qū)別的編譯后端：各種依賴庫、裝Linux、編譯各種錯。

所以我個人更傾向整個DL社區(qū)能夠提供一份完善的跨平臺、跨設(shè)備解決方案，而不是多而雜的備選方案。

從這點來看，CGVM似乎是一個更徹底的框架殺手，但在ICML"15上， Jürgen Schmidhuber指出：

真正運行AI 的代碼是非常簡短的，甚至高中生都能玩轉(zhuǎn)它。不用有任何擔心會有行業(yè)壟斷AI及其研究。

簡短的AI代碼，未必就是簡單的框架提供的，有可能是自己熟悉的框架，這種需求體現(xiàn)在前端而不是后端。

VM指出了一條多框架混合思路：功能A，框架X寫簡單。功能B，框架Y寫簡單。

功能A和功能B又要end-to-end，那么顯然混起來用不就行了。

只有使用頻率不高的框架才會消亡，VM將框架混合使用后，熟悉的味道更濃了，那么便構(gòu)不成”框架屠殺者“。

強大的AI代碼，未必就是VM提供的，有可能是龐大的后端提供的。

隨著paper的快速迭代，后端的擴展仍然是最繁重的編程任務(wù)。

VM和后端側(cè)重點各有不同，難分好壞。但分離兩者的做法確實是成功的一步。

VM的形式

VM及計算圖描述方式是連接前后端的橋梁。

即便后端是的，根據(jù)支持前端的不同，各家寫的VM也很難統(tǒng)一。

實際上這就把框架之間的斗爭引向了VM之間的斗爭。

兩人見面談笑風生，與其問對方用什么框架，不如問對方用什么VM。

VM的主要工作

合成計算圖描述的過程是乏味的，在Caffe1中，我們恐怕已經(jīng)受夠了人工編輯prototxt。

API交互方面，即便是MXNet提供給用戶的API也是復雜臃腫的，或許仍然需要一個handbook。

TensorFlow中的TensorBoard借鑒了WebOS，VM上搞一個交互性更強的操作系統(tǒng)也是可行的。

除此之外，我可能比較熟悉一些經(jīng)典框架，那么不妨讓VM去實現(xiàn)那些耳熟能詳?shù)暮瘮?shù)吧！

1、模擬Theano.function

Theano的function是一個非常貼近數(shù)學表達計算圖掩飾工具。function內(nèi)部轉(zhuǎn)化表達式為計算圖定義，同時返回一個lambda函數(shù)引向計算圖的執(zhí)行。總之這是一個百看不膩的API。

2、模擬Theano.grad

結(jié)合計算圖優(yōu)化，我們現(xiàn)在可以指定任意一對求導二元組(cost, wrt)。因而，放開手，讓自動求導在你的模型中飛舞吧。

3、模擬Theano.scan

Theano.scan是一個用來搭建RNN的神器。盡管最近Caffe1更新了RNN，但是只支持固定循環(huán)步數(shù)的RNN。而Theano.scan則可以根據(jù)Tensor的shape，為RNN建動態(tài)的計算圖，這適合在NLP任務(wù)中處理不定長句子。

4、模擬PyCaffe

PyCaffe近來在RCNN、FCN、DeepDream中得到廣泛應(yīng)用，成為搞CV小伙伴們的最愛。PyCaffe大部分是由C++數(shù)據(jù)結(jié)構(gòu)通過Boost.Python導出的，不幸的是，Boost.Thread導出之后與Python的GIL沖突，導致PyCaffe里無法執(zhí)行C++線程。嘗試模擬移除Boost.Python后的PyCaffe，在Python里把Solver、Net、Layer給寫出來吧。

5、模擬你熟悉的任意框架

.......等等，怎么感覺在寫模擬器.....當然寫模擬器基本就是在重復造輪子，這個在NNVM的知乎討論帖中已經(jīng)指明了。

VM的重要性

VM是深度學習框架去中心化、解耦化發(fā)展邁出的重要一步。

同時暴露了目前框架圈混亂的本質(zhì)：計算圖之下，眾生平等。計算圖之上，群魔亂舞。

在今年我們可以看多許多框架PK對比的文章，然而大多只是從用戶觀點出發(fā)的簡單評測。

對比之下，NNVM關(guān)注度不高、反對者還不少這種情況，確實讓人感到意外。

回顧與展望

回顧2016：框架圈減肥大作戰(zhàn)的開始

高調(diào)宣布開源XXX框架，再封裝一些API，實際上已經(jīng)多余了。

VM的出現(xiàn)，將上層接口的編寫引向模擬經(jīng)典的框架，從而達到減肥的目的。

框架維護者應(yīng)當將大部分精力主要放在Kernel的編寫上，而不是考慮搞一些大新聞。

展望2017：DL社區(qū)能否聯(lián)合開源出跨平臺、跨設(shè)備的后端解決方案

后端上，隨著ARM、神經(jīng)芯片的引入，我們迫切需要緊跟著硬件來完成繁重的編程。

后端是一個敏感詞，因為硬件可以拿來賣錢，所以更傾向于閉源。

除此之外，即便出現(xiàn)了開源的后端，在山寨和混戰(zhàn)之前是否能普及也是一個問題。

展望2017：來寫框架吧

VM的出現(xiàn)，帶來另一個值得思考的問題：現(xiàn)在是不是人人應(yīng)該學寫框架了？

傳統(tǒng)框架編寫的困難在代碼耦合度高，學習成本昂貴。

VM流框架分離了前后端之后，前端編寫難度很低，后端的則相對固定。

這樣一來，框架的編程層次更加分明，Keras地位似乎要危險了。

展望2017：更快迭代的框架，更多變的風格，更難的壟斷地位

相比于paper的迭代，框架的迭代似乎更快了一點。

余凱老師前段時間發(fā)出了TensorFlow壟斷的擔憂，但我們可以很樂觀地看到：越來越多的用戶，在深入框架的底層。

TensorFlow并不是較好的框架，MXNet也不是，較好的框架是自己用的舒服的框架，較好是一行行自己敲出來的。

如果你已經(jīng)積累的數(shù)個框架的使用經(jīng)驗，是時候把它們無縫銜接在一起了。

商業(yè)智能與數(shù)據(jù)分析群

興趣范圍包括各種讓數(shù)據(jù)產(chǎn)生價值的辦法，實際應(yīng)用案例分享與討論，分析工具，ETL工具，數(shù)據(jù)倉庫，數(shù)據(jù)挖掘工具，報表系統(tǒng)等全方位知識

QQ群：81035754