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

從發現問題到解決問題

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

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

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

是否可以寫一個框架：

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

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

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

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

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

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

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

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

.......

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

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

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

計算圖走向成熟

計算圖的兩種形式

計算圖最早的出處應該是追溯到Bengio在09年的《Learning Deep Architectures for AI》，Bengio使用了有向圖結構來描述神經網絡的計算:

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

隨后在Bengio組的Theano框架執行中，Graph就被隱式應用于Op的連接。

不過這時候，Op還是執行時-動態編譯的。

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

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

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

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

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

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

計算圖被劃分為三個階段，定義階段、構造階段、執行階段：

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

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

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

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

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

當符號粒度過細時，一個Layer的實現就會變成連續執行多個子過程，導致“TensorFlowSlow”。

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

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

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

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

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

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

后端的獨立，不僅減少了編譯工作，較大的優勢在于降低了傳統框架做跨設備計算的代碼耦合度。

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

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

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

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

所以IR之上，分為兩派：

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

第二派不搞自己的API，反而去模擬現有的API，表示我很低調。

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

計算圖優化

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

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

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

①依賴性剪枝

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

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

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

②符號融合

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

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

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

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

③內存共享

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

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

1、bottom和top數量都為1，即：計算圖中構成一條直線路徑，

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

常見的激活函數都符號以上兩個條件，因而可以減少內存的開銷。

但是Caffe1在多網絡內存共享優化上極其糟糕的，以至于Caffe1并不適合用來跑GAN，以及更復雜的網絡。

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

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

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

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

新的風暴已經出現

VM的側重點

CGVM和NNVM的側重點是不太一樣的，CGVM更強調前端上的擴展化，后端上的化。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VM的形式

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

即便后端是的，根據支持前端的不同，各家寫的VM也很難統一。

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

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

VM的主要工作

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

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

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

除此之外，我可能比較熟悉一些經典框架，那么不妨讓VM去實現那些耳熟能詳的函數吧！

1、模擬Theano.function

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

2、模擬Theano.grad

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

3、模擬Theano.scan

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

4、模擬PyCaffe

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

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

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

VM的重要性

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

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

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

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

回顧與展望

回顧2016：框架圈減肥大作戰的開始

高調宣布開源XXX框架，再封裝一些API，實際上已經多余了。

VM的出現，將上層接口的編寫引向模擬經典的框架，從而達到減肥的目的。

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

展望2017：DL社區能否聯合開源出跨平臺、跨設備的后端解決方案

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

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

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

展望2017：來寫框架吧

VM的出現，帶來另一個值得思考的問題：現在是不是人人應該學寫框架了？

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

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

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

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

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

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

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

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

商業智能與數據分析群

興趣范圍包括各種讓數據產生價值的辦法，實際應用案例分享與討論，分析工具，ETL工具，數據倉庫，數據挖掘工具，報表系統等全方位知識

QQ群：81035754