如何評價陳天奇的模塊化深度學習系統NNVM？

01-04

介紹文章：MXNet專欄 | 陳天奇：NNVM打造模塊化深度學習系統
項目地址：GitHub - dmlc/nnvm: Intermediate Computational Graph Representation for Deep Learning Systems
NNVM是否會成為深度學習時代的彙編語言，成為溝通底層計算設備（GPU、FPGA）與高層的計算圖描述語言（Tensorflow、MXNet）的通用橋樑？

北京時間 10 月 13 日 12:00 更新：

加個 Disclaimer: 本文僅代表個人觀點，與僱主無關。

北京時間 10 月 4 日 1:40 更新：

看到作者 @crowowrk 的回答，並且在評論中進行了簡單交流。我的看法和作者的想法，都是認同 graph 定義和優化這一層的，區別是我認為這一層放在框架內部更方便開發，而 NNVM 想把這一層拿出來大家一起做大做強避免重複勞動。這個想法我是非常支持的，但最終是否好用還是要看工程的發展和理論總結，尤其是在當前 NNVM 的實現還非常單薄的情況下。

我之前的回答，主要是在把 NNVM 跟 TF 內部的 graph 這層比對，並不是為了分出高下，而只是在做技術上的比對，並表達我的一些想法。希望大家不要有門派之爭，理性討論，共同促使技術進步。

=== 10 月 3 日答案原文如下 ===

tl;dr NNVM 的出現不在於技術上有多大突破（該有的 TF 都有），而在於意欲打造一個公共介面（雖然我並不認同）。當下推出的 TinyFlow, 也有一點集合社區力量對抗 Google 的 TensorFlow 的意思。不管怎麼說，DL Framework 社區活躍，終歸是一件好事，作為從業者非常感謝！

首先建議想做技術分析的同學，都先看看 TensorFlow 的代碼，雖然量很大，但核心都在core/framework 和 common_runtimecore/distributed_runtime 幾個目錄下面，從 Session 一路分析進去，並不難懂。

nnvm 從 github 上看，是為了作為模塊化 DL 系統中的計算圖的一環。

NNVM offers one such part, it provides a generic way to do computation graph optimization such as memory reduction, device allocation and more while being agnostic to the operator interface definition and how operators are executed. NNVM is inspired by LLVM, aiming to be a high level intermediate representation library for neural nets and computation graphs generation and optimizations.

這些部分，在 TensorFlow 裡面都有相對成熟的實現。

先說圖表示，在 TensorFlow 裡面有兩種圖，一種是用於介面的，基於 protobuf 表示的圖 tensorflow/graph.proto，稱之為 GraphDef。另一種是 C++ 內部運行時用的圖表示 tensorflow/graph.h，稱之為 Graph. 而 Operator 的定義，TF 是通過一個在 C++ 裡面實現的 DSL 做的 tensorflow/op.h 使用方法例如 tensorflow/math_ops.cc，這個在 NNVM 裡面也採用了類似的形式。

之後做圖的優化，在 C++ 層面有 tensorflow/graph_optimizer.h. 基於這個介面，目前也做了若干實現 tensorflow/graph_optimizer.cc 如常數摺疊，公共表達式消除等。除此之外，在 Python 層面也有 graph_editor 用來做圖的編輯。比如 Sublinear Memory 理論上用 GraphEditor 是可以做到的。

TF 的 Operator 和 Kernel 也是分開的，相同的 Operator 可以有 CPU/CUDA 等多種實現，OpenCL 也在進行中。往 TF 裡面加 Operator 並不複雜 https://www.tensorflow.org/versions/r0.11/how_tos/adding_an_op/index.html.

所以先潑一瓢冷水：我粗略的掃了一下 NNVM 的代碼，可以說目前 NNVM 的目標，在 TF 內部都有實現並且都有比較好的抽象隔離。重新造輪子，政治意義大於技術意義。

轉載作者陳天奇的微博關於今天深度學習系統爭論。目前的壁壘並非... 來自陳天奇怪:

關於今天深度學習系統爭論。目前的壁壘並非使用哪一個，而是系統內部高度耦合，使得改進或者從頭fork打造系統的代價變高。通過模塊化，去中心化來解決這些問題，防止壟斷。當大家都可以通過組裝組件幾天從頭打造MX, TF或者類似系統的時候。這些爭論就不復存在了。

最近推出的 TinyFlow 號稱是 2k 行的 TensorFlow，但其實看代碼會發現，做到當面這個層面，即使完全重寫，代碼成本也不算高。TinyFlow 目前（2016.10.3）的本質是一個 Python DSL 到 Lua 代碼的轉換器。而 TensorFlow 本身的結構並不複雜，難點在於無窮多 Operator 的實現，和當初分散式架構的設計。這兩個實現出來，本質上都是工作量問題，這也是 TF 的 codebase 如此龐大的原因。

NNVM 目前（2016.10.3）自身也不包括 Operator 的定義，這會導致使用 NNVM 的不同框架本質上是無法互換的。而定義 Operator 這個工作量比較大，甚至不一定能完成（比如不同 Framework 對 padding 的定義就不太一樣），不知道 NNVM 是否有意願往這個方向發展。

目前 DL 的領域還在高速發展，新的網路結構（比如 ResNet, GAN）、計算節點（各種神奇的 Operator）、計算方法（比如 lowbit, sublinear memory）、計算設備（比如 TPU，寒武紀）都在不斷湧現。分散式架構也在不斷演進。在這個時間點，我認為 monolithic 的框架重構相對方便，會有更加旺盛的生命力。而 NNVM 的理想，恐怕跟現實還是有一定差距的。目前更有價值的，我覺得並不在圖表示層，而是各種 Operator 的 kernels. 每個設備的 kernel 都需要專業人員定製，工作量大，難度高。cudnn 解決了 CUDA 設備上的大部分問題，但仍然有很多 Operator 需要自己實現。lowbit 目前也並沒有特別可用的實現。如果能有一個統一的庫，定義每個 Operator 在各種設備上的最優運行代碼，應該對社區更有幫助。而上層的網路定義，和具體每個圖的運行調度方式（比如 MXNet 的 Dependency Engine，TensorFlow 的分散式框架和 rendezvous 設計），這些代碼量不大，但更容易體現出差異化的部分，我想還是留待每個框架自己解決吧。

個人愚見，請各位參考。雖然我並不認同 NNVM 的目標，但依然對陳天奇先生對社區的貢獻非常欽佩。各位如想評論，請至少大略了解 NNVM，TensorFlow 和 MXNet 的內部實現架構，以節省大家時間。

之前討論過後更加意識到了@王健飛所說的更好地支持更多平台的op調優的重要性。昨天我們發布了dmlc/tvm 來解決這部分問題。

-------

在幾個月之後給了幾個關於NNVM的報告，也思考了它和已有系統的差別。追加一下這一頁slide，是我對於在抽象成面上面各個系統差別的理解。

原回答

-------

我是NNVM的作者。

總結一下，技術上本身的NNVM和現有的東西的差別是最小模塊化和去中心化，降低深度學習系統優化門檻。除了為了解決現有問題，更多是為了未來考慮。

關於是否重複造輪子的問題，圖表示和優化本身在MXNet就已經存在，樓上也提到TF也有對應的抽象，為什麼我們需要重新寫一遍呢，基本上也就是以上兩點原因。

基本上現有的深度學習系統分成兩塊，1) 基本的operator的實現, 2)支撐其中的系統調度，優化，解釋或者編譯架構。

在工程難點上，operator需要堆代碼，但是對於工程架構的難度上面而言相對較低(也就是說可以寫的人比較多一些)，但是需要堆比較大量的代碼。而剩下的系統優化部分，內存，執行調度和分散式優化對於整體系統而言的難度相對高一些。Operator的集合問題雖然是一個問題，看已經有的成熟框架不論是Torch, Theano或者MXNet的operator完整程度基本上可以滿足於大部分應用，也就是說這部分暫時屬於已經解決或者可以通過堆積工程力量容易解決的問題。樓上說的最小化通用的 Op介面很重要，和NNVM我們考慮的方向垂直。我覺得相對乾淨的Op應該去推動成為一個獨立的模塊，而Op實現本身其實沒有必要和框架耦合很深（雖然遺憾的是目前的設計暫時沒有做到這一點）。

NNVM希望解決的是垂直於operator實現的問題。有趣的是其實TF在這一暫時沒有花特別多的力氣，所以會讓人覺得operator是大頭。其實這裡有很多有趣的東西，在執行，調度和編譯優化上面。編程模型和一個圖本身的執行模式和硬體也會有更多的差異。

直接討論一下設計，目前TF採取了單一的動態執行模式，使得本身執行特別依賴於動態內存分配以及threading。而這並非是大部分場景下的最優方案。大部分場景下基於對於有限的圖進行的靜態分配，可以更大的緩解這個問題，實際情況如MX本身的內存損耗可以做的更好。為什麼目前TF不會出現多種執行模式呢，是因為TF本身Op的介面還是過於一般地針對的動態，而如果要更好的優化需要更細化的Op介面（分開內存分配和計算的部分），這就考慮到一個Op甚至可能有多種介面的可能性。

NNVM本身的圖的設計參考了TF，MX和caffe2的圖部分。樓上的評論基本上提到了幾個非常重要的概念，即系統優化和Op具體的性息相關。但是和PL不同，我們不能直接簡單的抽象出有限個操作來表示整個程序。這個時候似乎框架和Op會有比較強的關聯性，導致比較大的耦合。但是也並非如此，因為每一個優化本身其實只依賴於Op的部分屬性。比如有同學提到的常數摺疊，其實需要知道的是一個Op是否是常數，以及如何去展開常數兩個函數。NNVM本身的做法是允許註冊這兩個額外屬性來允許常數摺疊優化。但是當不需要這個優化的時候，可以直接去掉這一部分。使得深度學習的優化可以插拔。現在看起來可能有些overkill，但是我們相信未來深度學習系統在這方面會有很大的發展，允許不同的優化來自於不同群體和研究人員是我們更加喜歡的方式。

基於以上原因，NNVM允許給每個op註冊任意的信息。並且可以使得屬性和註冊和op的實現分開。這相對於TF的op介面而言是一個進步的地方。TF內部的所有op屬性是需要提前數據結構指定的，也就是說，目前TF可以註冊shape inference, op的輸入參數的個數，但是無法註冊比如我們需要的新的細化Op介面，或者有些人關心的代碼生成函數。如果需要加入這些特性，必須要修改Op的介面。這意味著所有的開發需要在一個中心，並且只能保留大家關心的東西。如果forkA有feature1, forkB有feature2的情況，forkB想要拿到 feature1就會比較不方便。因為NNVM允許不修改Op介面註冊任意信息，相對解決了這個問題。

當然模塊化和去中心化並非對於所有人都重要，就是見仁見智把。

未來的深度學習系統會有更多系統的問題，使得優化和執行更加多樣化。我們不能夠期待所有的優化都來自於一個團隊，或者只應用於一個框架。更多的優化看起來會帶來更多的耦合，但是也並非如此。

發布TinyFlow原因很簡單。大部分人並沒有意識到其實目前深度學習的「系統」部分可以通過簡單抽象得到。TinyFlow作為一個教程性質的項目，可以用比較短的代碼展示目前有的大部分優化概念，並且把Op的部分代理給Torch（因為Op本身雖然重要，但是並不作為架構一部分）。如果可以有更多的同學來關注深度學習系統優化，基本這個項目的目的就達到了。

值得承認的是，NNVM目前只是走出了第一步，只是包含了MXNet原有的一些優化，暫時內容不多，我們會繼續帶來更多好玩的東西。我們也會繼續堅持模塊化和去中心化的思想，使得我們新的成果可以更好的用在各個平台裡面

NNVM Compiler: Open Compiler for AI Frameworks

盜一張文中圖：

給我一種感覺，nnvm牽起了pytorch，cntk，caffe2，caffe，keras（？）的小手，開始干xla。。（keras怎麼哪都有你。。）

就就像xen理論性能等比kvm優秀，但是redhat準備全力推kvm的時候，趨勢開始轉移到kvm，所以，長期的運營支持，精確高質量的實現都是一個平台的核心競爭力，而且DL平台對交叉專業領域的需求，加速硬體，系統架構，通信架構，互聯基礎網路，分散式並行架構，等等都也非常重要。

例如一個高速網路架構下，一個關鍵內存未對齊的操作可能損失可觀的整體性能，一個忽視的鎖的設計也可能損失可觀的性能，一個tcp超時參數的不合理可能損失樂觀的性能，甚至一個硬體插槽的不合理也可能損失可觀整體的性能，一個不合理的通信演算法架構等等。

通常，系統領域fine-grained的優化實現至關重要，這需要對平台的長期耕耘，也需要決策層面長期的支持，絕逼幾個單純的架構能解決的問題。

很少見到從distributed level將系統設計，大都還是還是based single node層面講靈活性，期待有更多關於整體system層面討論架構。

NNVM的想法是，我來做DL框架的優化，別人來豐富具體的Operator

我不清楚作者們是否想考慮過相反的情形，即對DL來說，有沒有可能Operator是核心，框架是輔助？

從作者的回復來看，是有些看不上Op開發的，都打算代理給Torch了