如何看待MXNet在CVPR2017上公布的gluon介面？

Slide：https://github.com/mli/cvpr17/blob/master/gluon_part1.pdf

Doc：Deep Learning - The Straight Dope

謝邀，之前在專欄發過介紹了，既然很多人關注這個問題就在這裡再貼一遍吧。

轉自：https://zhuanlan.zhihu.com/p/28648399

經過3個月的開發，MXNet 0.11版發布啦！0.11是MXNet正式加入Apache以後的第一個版本，官方網站搬到了Apache的伺服器（注意：要在最上方Version處選擇master才能看到包含Gluon的最新文檔）。

這次最大的改進是加入了動態圖介面Gluon。Gluon學習了Keras，Chainer，和Pytorch的優點，並加以改進。介面更簡單，且支持動態圖（Imperative）編程。相比TF，Caffe2等靜態圖（Symbolic）框架更加靈活易用。同時Gluon還繼承了MXNet速度快，省顯存，並行效率高的優點，並支持靜、動態圖混用，比Pytorch更快。

同時為了徹底解決MXNet文檔不全的弱點，我們還特地邀請了前CMU知名教授Alex Smola和即將出任CMU教授的小網紅Zachary Lipton聯手為Gluon打造文檔！

介面更簡潔

Gluon採用Keras和Numpy風格API，並且Layer可以自動判斷輸入長度。用過Chainer和Pytorch的人想必都體會過每一層都要記住前一層輸出長度的麻煩，從卷積層到全聯接層過度時長度計算更是痛苦，往往要運行一遍才知道。在Gluon里則沒有這種問題，每層只要指定輸出長度，輸入長度則可以由系統自動計算。

速度更快

深度學習框架大體分為兩類：以TensorFlow，caffe2為代表的靜態圖（Symbolic）框架和以Chainer，Pytorch為代表的動態圖（Imperative）框架。靜態圖的優勢在於速度快，省內存，便於線上部署。而動態圖框架的優勢是靈活，易用，debug方便，特別是在自然語言處理和增強學習等領域，比起靜態圖框架有顯著優勢。

Gluon同時支持靈活的動態圖和高效的靜態圖，讓你在享受動態編程的靈活易用的同時最小化性能的損失。而Gluon的HybridBlock和hybridize介面讓你可以在靜態動態間一鍵切換。0.11版Gluon比0.20版Pytorch快10%以上，在未來的一兩個月我們會加入更多優化，再提高10%以上的性能。

即是文檔，又是教材

深度學習的教材和樣例雖多，但是教材往往重理論輕實踐，而樣例重實踐卻不系統。為了填補理論和實踐之間的空白，並一舉解決MXNet文檔不全的弱項，我們特邀兩位CMU教授Alex Smola和Zachary Lipton為Gluon撰寫一部兼顧深度學習理論，動手編程，和實戰應用的文檔+教材。

Gluon教程包括深度學習理論講解和代碼實踐。前五章每個例子都包括了兩個版本。從零開始（from scratch）版本深入講解所有細節，Gluon版本則著重演示高級封裝的靈活高效。建議剛開始接觸深度學習的同學從頭開始順序閱讀，而已經有一定經驗的同學可以跳過基礎教程只看Gluon版。這套教程現在在Github上公開寫作，共計劃18章，已經完成了前五章。印刷出版和中文翻譯也在計劃中。我們保證每天更新，絕不棄坑，歡迎大家試讀，也歡迎參與創作！

Gluon與其他框架的對比

Tensorflow：Gluon同時支持靜態圖和動態圖，在靈活性和速度上都有優勢。但由於Gluon剛剛面市，在成熟度和線上部署方便還有不足。總的來說在做深度學習研究的同學不妨一試。

Pytorch：Gluon與Pytorch的相似度很高，而Gluon獨特的靜、動態圖混合功能可以在不犧牲靈活性的前提下提高性能。如果你喜歡pytorch的簡單易用又在乎性能，那麼強烈建議你試一試Gluon。

鏈接

Apache MXNet官方網站：https://mxnet.incubator.apache.org/

0.11 新特性：https://github.com/apache/incubator-mxnet/releases

安裝指南：https://mxnet.incubator.apache.org/versions/master/get_started/install.html

Gluon教程：http://gluon.mxnet.io/

Gluon講座PPT： https://github.com/zackchase/mxnet-slides/blob/master/kdd-mxnet-slides.pdf

Gluon深度學習樣例：https://github.com/apache/incubator-mxnet/tree/master/example/gluon

PS：本文允許轉載

轉一篇我的文章

經過了3個月的開發，MXNet 0.11版本終於發布了，其中也發布了最為重要的一個更新，動態圖介面Gluon，李沐大神也在CVPR17上面介紹了Gluon介面，足以看出MXNet對這次新發布的Gluon介面的重視。

下面我就以一個PyTorch使用者的角度為大家介紹一個我對Gluon這個介面的看法。

為何要開發Gluon

很多人說MXNet將戰線拉得太大了，發布了兩年，api處於極速的更新狀態，非常不穩定。這一點我贊同，我認為一個成熟的框架必須要具有非常穩定的api，試想幾個月前寫的代碼現在想做一些修改，結果發現好多api不能用了，這無疑會讓人非常崩潰。而且我認為目前MXNet的api也存在一些問題，有很多可以改進的空間，但是我認為最為重要的問題是沒有規範的教程和文檔，同時官方沒有建立討論的社區，大家有問題就去github上提issue，這樣效率是非常底下的，這也給很多想使用MXNet的用戶造成了極大的困難。

既然說到了MXNet的這麼多可以改進的問題，當然dmlc他們自己肯定是意識到了，但是因為精力和時間的關係沒有很快去改進，反而他們將他們的重心放到了開發一個全新的動態圖介面Gluon上。對於這個工作量並不小的工程，我想他們肯定是經過了深思熟慮才做出的解決，下面我就談一談我個人的感受。

先放上一張沐神在CVPR17 tutorial上的一張圖片吧。

圖片上不僅從時間上，還從編程方式上將目前主流的框架做了一下區分，可以明顯看出2015年之前框架都是符號式編程，tensorflow繼承theano的特點出現，因為Google的背書，強力地吸引了很多人去使用，很快成為了最流行的框架。但是tensorflow真的很好用嗎？就我自己的使用情況而言，答案是否定的，一是因為tensorflow是由一群Google的工程師開發的，他們一方面希望工程能力很強，有希望tensorflow可以做科研，這樣必定顧此失彼；二是因為tensorflow是符號式編程方式，繼承了theano一大堆缺點，不僅寫法麻煩，而且bug難調；三是暫時只能用於靜態圖，現在很多深度學習的研究希望能夠使用動態圖。上面是我自己使用時感覺的問題，知乎上專門有一個問題來吐槽tensorflow，有興趣的讀者可以去看看。雖然說了這麼多tensorflow的不好，但是毫無疑問tensorflow仍然是深度學習框架的霸者地位。

我一直認為越新的東西就會越滿足用戶的需求，所以隨後Facebook新出的PyTorch的用戶體驗就感覺非常的好，一是因為其是命令式編程的方式，隨時能夠運行結果，跟我們寫python程序幾乎一模一樣，不用像tensorflow一樣要先定義graph，然後一個session去運行；二是因為bug非常好找，那裡出了問題就能夠直接定位；三是因為文檔非常清楚，乾淨整潔，同時源碼非常清晰，容易看懂和修改；四是因為其支持動態圖，非常靈活，能夠隨意取出其中的tensor進行操作和查看；五是因為其有非常非常清晰的教程和官方論壇，Soumith等主要開發者都會經常在論壇上面解答問題，而且一般遇到了問題去論壇上搜都能夠很容易搜到之前有人提過，所有能夠很方便地找到解答方法。

正是由於這些優點，使得PyTorch才剛剛發布半年的時間就被大量的人推崇和使用，最新的cs231n都推出了PyTorch版本的作業，可想而知PyTorch是多麼簡單易用。

說了這麼多tensorflow和PyTorch，這跟Gluon有什麼關係呢？我想MXNet正是看到了以PyTorch為首的命令式編程框架的潛力，對於新用戶特別友好，易於上手，所以他們決定模仿PyTorch開發一個動態圖介面Gluon。Gluon還邀請了CMU的兩位教授來聯手寫教程，也是一本書，我想也是因為他們發現PyTorch良好的教程對於吸引用戶實在是太有幫助了。但是目前還是沒有官方的社區和論壇，希望MXNet的開發者能夠看到這個問題，擁有一個官方的論壇能夠留住很多使用者。

其實PyTorch也是仿照Chainer開發的，其後端也是調用的torch的運算，定位比keras低，但是又比tensorflow高。所以Gluon也可以看作這樣一個介面，調用底層的MXNet，但是前端使用符號式編程的方式。

Gluon的定位

PyTorch定位於科研，在Facebook內部使用Caffe2作為產品的部署和應用，那麼Gluon是如何定位的呢？

官方稱Gluon不僅定位於科研，同時也可用於產品。這無疑比PyTorch更好，因為這樣不需要再重寫代碼，而且兩個框架之間轉化也容易丟掉一些細節，從而模型達不到之前的精度，能夠有一套統一的框架，不僅能做科研，同時能夠用於產品部署無疑是最好的解決方案。我相信以dmlc的實力肯定能做出了，畢竟MXNet的設計理念是非常領先的。

Gluon的優勢

大致看完Gluon的api，和PyTorch非常非常像，開發者也說了Gluon學習了Keras，Chainer和PyTorch的優點並加以改進，相似的api無疑是一個優勢。之前我是PyTorch使用者，這兩天我嘗試著將之前的PyTorch教程移植到Gluon下面，發現非常方便，幾乎大體的框架都不用改動，只需要該一些小的api就可以了，所以非常方便用戶遷移過來，這是我的PyTorch教程和移植的Gluon教程。

第二個優勢是MXNet的優勢，就是速度快，省顯存，並行效率高，分散式簡單等等。這些優勢並不是Gluon帶來的，而是MXNet一直以來的優勢。

第三個優勢就是靜態圖和動態圖的轉換，PyTorch只有動態圖的模式，有的時候我們的網路結構其實是一個靜態圖，但是通過PyTorch每次都會重新構建動態圖，而Gluon提供了一個靜態圖和動態圖之間切換的方式。Gluon中的模塊gluon.nn.Sequential和gluon.Block分別與PyTorch中的torch.nn.Sequential和torch.nn.Module對應，他們都是動態圖的構建，而Gluon中還提供了gluon.nn.hybridSequential和gluon.HybridBlock，這兩個模塊就可以在動態圖和靜態圖之間轉換，使用者可以先用imperatvie的方式寫網路，debug，最後跑通網路之後，如果網路是一個靜態圖結構，就可以用net.hybridize()的方式將其轉換成靜態圖，眾所周知靜態圖的運算會比動態圖快，所以這是Gluon比PyTorch更好的地方，具體可以看看這個教程。

第四個優勢就是前面提到過的，科研和工業界可以都用同一個框架開發，避免的代碼的重寫，減少勞動效率，避免出現問題。

Gluon與PyTorch的對比

Gluon和PyTorch非常相似，比如PyTorch中的`torch.Tensor()`可以對應Gluon中的mx.nd.array()，PyTorch中tensor.cuda()可以對應Gluon中ndarray.as_in_context(mx.gpu())等等，大家在使用中就會慢慢發現很多相似的地方，我就不一一列舉了。除了這些相似之處，還有一些不同的地方具體說一下。

首先，Gluon和PyTorch在網路定義的部分有一個不同點，PyTorch定義網路的時候必須要明確的網路輸入和輸出的維度，所以我們需要自己去算，或者讓網路向前傳播一次print出維度。而Gluon並不需要這樣做，其能夠根據網路定義自動去判斷維度，避免了我們自己運算的麻煩，可以說是變得更加方便了。

由此帶來了另外一點的不同，就是lazy loading。定義好網路之後其實裡面的權重並沒有真實存在，這和PyTorch不同，PyTorch定義好網路之後就能夠將每一層的權重print出來，而Gluon定義好網路之後是沒有辦法print出來的。但是想像PyTorch一樣print出具體的權重數值也可以做到，就是定義一個輸入，然後feed進網路做一次前向傳播，這樣網路中的參數就真實存在了，可以print出裡面的具體數值了。這就是lazy loading，在使用的時候才會去真正地賦值，而不是定義的時候就賦值，究其原因，還是因為Gluon希望在定義的時候能夠盡量方便，不需要人為去推斷輸入的維度，這帶來的問題就是需要網路前向傳播一次才能夠真正賦予網路中的參數。這和PyTorch對比到底哪個更好了，這就見仁見智了。

最後一點不同之處就是PyTorch在網路定義的時候就會默認初始化，而且初始化的api並沒有暴露出來，如果你想要自己重新初始化就需要手動提取出裡面的tensor進行賦值。而Gluon有點像tensorflow，需要在定義網路之後進行一次參數的初始化，net.collect_params().initialize(ctx=mx.gpu())，而且PyTorch中可以使用model.cuda()將網路放到GPU上，而Gluon需要在初始化中指明ctx=mx.gpu()或者ctx=mx.cpu()。同時Gluon還可以在網路定義的時候就定義當前層的初始化方式，比如gluon.nn.Dense(weight_initializer=mx.init.Normal())，我感覺這比PyTorch方便一些。

Gluon的不足

最後說一說Gluon的不足吧，畢竟Gluon是剛剛上線的產品，所以難免存在一些bug，api偏少，線上部署不成熟，同時ndarray存在一些奇怪的問題，比如a = mx.nd.array([2, 3, 4])，我想取最後一位，a[-1]就會報錯，但是我用a[2]就沒有問題，雖然說影響不是很大，但是感覺用著有點煩。另外ndarray的操作也沒有PyTorch中tensor多，比如squeeze這個操作我就沒有在ndarray中找到類似，也許是我沒有發現，知道的同學可以告訴我一下。

總結

說了這麼多，最後總結一下，Gluon的出現是現在深度學習框架發展的趨勢，目前剛剛上線，雖然不成熟，但是提供了一套從科研到工業的簡單的、統一的框架。對於使用PyTorch的用戶比較友好，遷移成本比較低，同時還能夠保證性能，如果是使用tensorflow等框架的用戶，也強烈建議感受一下imperative框架的魅力。

最後，希望dmlc的開發者們能夠好好去更新和維護Gluon，如果真的能夠將科研和工業界統一起來，那麼一定會有很多人來使用Gluon的。

已經有官方論壇了

歡迎查看我的知乎專欄，深度煉丹

歡迎訪問我的博客

首先，我感覺現在mxnet戰線拉的有點大，我認為目前對於mxnet，編程範式的改進不應排在第一位，因為之前的api已經具備了很強的神經網路構建能力。但是之前的api的功能其實還存在很大的提升的空間，包括文檔和bug等都未完善或修補。現在大家好不容易接受了老api，又來一個新的api而且是更不完善的版本，這樣做其實不利於平台吸引用戶，包括新老用戶。

其次，mxnet不應對標tensorflow、pytorch、keras這些平台。特別是keras，因為gluon api簡直相當於是keras的翻版。mxnet一定要做出自己的特色，經過我長時間考察，我認為mxnet的特色在於，同時具備tensorflow的構建網路（尤其是構建rnn等非卷積網路）的能力和caffe的容易修改底層代碼的靈活性，但又在兩方面分別略遜於二者，所以mxnet的主要發力點應該在構建能力和代碼修改靈活性方面，前者有利於吸引研究人員，而後者對社區貢獻者友好。

另外一點就是mxnet一直也在學習pytorch在傳統命令式網路構建方面的特性，但我認為pytorch包括torch做研究其實並不方便，這是因為python環境仍然缺乏強有力的IDE，lua就更不用說了，可視化調試等方面和MATLAB差距還很大。所以我覺得，mxnet應該提供完善的MATLAB介面，像MatConvnet那樣，把中間的symbol和ndarray等結構變為MATLAB獨有的表格模式。這裡要提一下，MatConvnet雖然是小眾平台，且只用於MATLAB，但優點也是十分明顯，在MATLAB下進行中間過程可視化斷點調試Profile等相當方便，我認為目前沒有架構能與之相比，畢竟是VGG出品，我覺得mxnet應該好好學習一下MatConvnet。所以完善的MATLAB介面對於mxnet是非常必要的，這比偷一個tensorboard過來更湊效。

贊同@kook china的觀點，我覺得現在mxnet的戰線拉得有點大，離發布已經兩年了，api仍舊處於rapid develop的狀態，很不穩定。現在很多基於mxnet的research paper公開的代碼都必須指明mxnet的版本，否則基本上跑不通。

mxnet的優點在於既能像caffe這樣方便修改底層代碼，又具有tensorflow這樣方便構建計算圖的能力，同時基於param-server的設計似的多卡並發加速比接近線性。現在mxnet有很多我覺得沒有必要的功能，比如perl，java等不太常用語言的binding，以及各種為了跟tf和torch對其而增加的若干功能。

經過這幾年的發展，我覺得深度學習框架有趨於同質化的趨勢，tf和pytorch現在都支持dynamic computational graph，都支持auto-grad。作為一個計算機視覺研究者，我更喜歡caffe和torch/pytorch的設計，簡介而專註。我基本不用auto-grad，一是有很多複雜邏輯用框架支持的variable操作很難實現，二是覺得作為一個研究者，基本的求導還是自己寫一遍比較好。