本文為微信公眾號[深度學習大講堂]特約稿，轉載請註明出處

虛擬框架殺入

從發現問題到解決問題

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

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

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

是否可以寫一個框架：

import xx.tensorflow as tensorflow
import xx.mxnet as mxnet
import xx.theano as theano
import xx.caffe as caffe

這樣，利用工廠模式只編譯執行部件的做法，只需編譯唯一的後端即可，框架的不同僅僅在於前端指令碼的不同。

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

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

import dragon.vm.caffe as caffe
import dragon.vm.theano as theano
import dragon.updaters as updaters

if __name__ == '__main__':

    net = caffe.Net('cifar10.prototxt')
    loss = net.blobs['loss'].data
    updater 
 
= updaters.SGDUpdater(base_lr=0.001, momentum=0.9, l2_decay=0.004)
    for k,v in net.params().iteritems():
        for blob in v:
           updater.append(v, theano.grad(loss, v))
    train = theano.function(outputs=loss)
    update = theano.function(updater=updater)
    max_iters = 2333
    iter 
 
= 0
    while iter < max_iters:
        train()
        update()

我為這種怪異的寫法取名叫CGVM(Computational Graph Virtual Machine)

然後過了幾天，在微博上看到了陳天奇在MXNet的進一步工作NNVM的釋出 (o(╯□╰)o)......

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的建構函式。

這將使記憶體區域完全暴露在全域性(類似MFC的Document)，與TensorFlow一樣，提供Feed/Fetch這一組API用於Python的外部訪問。

這種記憶體的管理方式，同時也為模擬Theano的API提供便利(e.g. theano.shared和get_value，本質就是Feed與Fetch)。

使用Workspace優化視訊記憶體，可使Caffe1做列卷積僅比CUDNN多300M(VGG16全連線) / 900M(VGG16全卷積)，且時間開銷近似為零。

遺憾的是，Caffe1臃腫、錯誤的程式碼結構似乎是無緣Workspace的引入了（這將面臨大面積的程式碼重寫，後果就是社群爆炸）。

P.S: 賈揚清在知乎還吐槽過Caffe1中大面積錯誤的模板寫法，導致Caffe1似乎也是無緣FP16了..(大家趕緊研究Caffe2吧）

面向計算圖的直接除錯

很多使用者抱怨TensorFlow除錯困難，不像Caffe1那樣更容易命中Bug的要害。

Caffe1的除錯簡單，源於Layer/Op的執行段很容易定位，Debug資訊可以有效的輸出。

而TensorFlow在計算圖之上，為了迎合工業界搞了許多莫名其妙的API。

面向計算圖的除錯技術宗旨就是，可以實時輸出模型執行計算圖的文字描述。

對於一個符號單元而言：

①明確它的輸入輸出是什麼Tensor，附加的靜態引數是什麼。

②它的符號名是什麼，是什麼符號型別，如果懷疑錯了，直接if(name=xxx) {.....} 即可針對性除錯。

對於幾個符號組成的區域性圖單元：

只需要各個符號間輸入輸出的拓撲連線關係，這個和看net.prototxt沒什麼區別。

以上兩種規格的單元除錯，最好能夠跳過API，直接暴露給使用者。

只要符號單元的實現正確、計算圖的拓撲連線及傳入引數正確，那麼模型的執行結果理論上是不會錯的。

新的風暴已經出現

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.tensor.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也不是，最好的框架是自己用的舒服的框架，最好是一行行自己敲出來的。

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