為什麼強大的 MXNet 一直火不起來？

11-24

看了下mxnet，覺得很厲害的，支持各個流行的平台，支持多種語言，支持多機多GPU並行。相比起來，caffe就沒這麼好的支持的。既然這麼好，為什麼mxnet就一直沒火起來呢？我看周圍基本上沒人用，比較好的論文開源出的代碼也沒見到mxnet。有什麼深層次的原因嗎？

簡單來說就是我們沒有足夠的人手能夠在短時間內同時技術上做出足夠的深度而且大規模推廣，所以我們前期是舍推廣保技術。

詳細來說我稍微發散下，可以把當下的深度學習（DL）比作修真世界（傳統武俠也類似）。學術界是各個門派，公司是世家，不過這個世界裡世家比較強勢。目前是盛世，各個流派之爭，新人和技術層出不窮，各大擂台（例如imagenet）和大會（據說今年nips 8k人參加，一個月前就把票賣光了）熱火朝天。平台作為修真練級法寶，自然也是各家PK重要之地。

各個平台是怎麼「火」起來的

簡單的來吧DL分三個階段來看，前DL時代就是Alexnet沒有刷出imagenet第一的時候，當時候主流算是torch和theano，從上一個神經網路的時代的兩大修正大門流傳下來，還是有堅實的用戶基礎。之後魔界（kernel）入侵，神經網路衰敗。但10年後Alexnet橫空出世，借著大數據和GPU的重劍無鋒，橫掃三界。同時也促使了很多新的平台的出現，caffe是之一，很多公司也有做自己的，例如百度的paddle，G的distbelief，我們也有做一個類似的項目叫cxxnet。大體上這些平台使用體驗差不多，給一個configure就能跑。這裡面caffe是最成功，我覺得重要兩點是時間點很好，就是dl在cv爆發的那段時間，然後caffe有在imagenet pretrain的模型，這個很方便大家的研究。畢竟大部分工作要麼是改改operator重新跑一下，要麼是基於pretrained的模型來finetune一個別的任務。

之後出來的比較成功的平台主要是靠提供更加靈活的開發環境來吸引新人。例如tensorflow和keras。

tf作為當下修真界最大門的平台，成功沒有什麼意外（1）G brain在這個領域上耕耘了5，6年，做為第二代產品在質量確實很優秀。（2）在jeff dean的號召下brain網羅了一大幫人，跟他們團隊接觸過很多次，整體人員質量甩出其他家很遠，以至於經常是好幾個我覺得能獨當一面的大牛一起在做一些很小的事情。例如我在cmu系統方向的老闆dave在brain好長一段時間就是debug為什麼inception v3從distbelief移植到tf老是跑不出想要的精度。（另，類似的坑我們也踩過，我還笑過dave你如果問我們一下可以省下你大筆時間，dave回我們人多任性不求人。）（3）G的宣傳機器如果稱第二，那業界估計沒人敢說第一。這次G不遺餘力的宣傳tf，連帶推動了整個DL的火熱。

keras比較有意思，基本是Fran?ois Chollet一人之力做的，有點是散修自己折騰出來的（他人現在在G，不過他去G之前就開始keras了）。它的優勢就是簡單，底層靠theano或者tensorflow，上層提供一個非常簡單的介面，非常適合新用戶使用。修真界新人練氣的不二法寶。

MXNet現狀

mxnetet是散修小團體一起合力做出來的平台。如果去看排名前20的開發者，基本都是出自不同的門派和世家。這個是mxnet最大的特色。我對此表示很自豪，這裡匯聚了一大幫跑得出實驗寫得出代碼的小夥伴。

不論是開始時間還是平台特性，mxnet最靠近tensorflow。有完整的多語言前端，後端類似編譯器，做這種內存和執行優化。應用場景從分散式訓練到移動端部署都覆蓋。整個系統全部模塊化，有極小的編譯依賴，非常適合快速開發。相對於tf這種重量型的後端，mxnet的輕量化路線使得可以我們在花費G brain 1/10的人力的情況下做到類似tf技術深度的系統。

從推廣的角度來說，需要的是清晰的文檔，大量的樣例，媒體曝光，和客服。這個對於散修團體而說前期比較困難。不過最近也慢慢趕上了。

根據keras作者的平台排名，目前mxnet屬於第四，前三分別是tf，caffe，keras。因為dl也是剛興起不久，目前的用戶可能一大半是剛入門不久，選擇tf/keras很符合情理。對於學術界而言，通常性能不是很關鍵，最重要是開發成本，如果前面的工作用了caffe/torch，那基本會一直用下去。

我們也回訪過我們用戶，很多都是工業界用戶，基本都是屬於有很強的技術能力，他們關心性能，開發和移植的便利性，和是不是能在開發社區里獲得一定的話語權。事實上，mxnet離人也很近，例如

- 某佔有率很高手機利用mx處理圖片
- 好幾個常見的app雲端利用mx處理數據
- aws/azure都寫了好幾篇blog普及在雲上面運行mxnet
- 國內幾個技術能力很強的ai創業公司內部用mx

整體而言，不管是dl技術，應用，還是平台，目前說什麼都尚早。技術和潮流都是日新月異，修仙之路也剛開始。我覺得最核心的是，有一群有最求的人，一起合力做一件事情，不斷往前。

PS. 我在考慮要不要寫一個關於DL/ML的修仙系列。例如「魔界小王子，譽為最有希望帶領魔界重殺回來領袖的叛逃心路歷程」，「我跟修真界第一門掌門的故事」，「如何利用入門道具組裝小型陣法加速修鍊」，「解析為什麼大門長老屢屢逃奔世家」。。。

mxnet用戶來談談感受。

優點：速度快省顯存。在復現一個caffe model的時候我們用了resnet，原版caffe的顯存佔用至少是mxnet的兩倍。

缺點：
1. API文檔差。這個問題很多人也提過了，很多時候要看源碼才能確定一個函數具體是做什麼的，看API描述有時候並不靠譜，因為文檔有點過時。不過畢竟開源力量有限，這都是可以理解的，希望有AWS撐腰後會有所改善。

2. 缺乏完善的自定義教程。比如寫data iter的時候，train和validation的data shape必須一致，這是我當時找了半天的一個bug。

3. 代碼小bug有點多。mxnet的大神們開發速度確實是快，但是有的layer真的是有bug，暑假我們就修了不少。舉個例子，原來batch norm的實現就是有問題的，不知道現在主branch有沒有修復。寫代碼有bug其實很正常，這些小bug有時候不會導致你完全跑不了，而是精度到一定程度就上不去了，但是因為真正用mxnet來刷benchmark死磕精度的人並不多，這就很難發現的了了。很多人死活跑不出想要的精度然後又不像我們一樣死磕，就棄坑了。

總結：性能確實是非常好，但是如果沒人帶的話，上手難度太大。大家時間都很寶貴，搞研究的人只想快速出原型調參數，不是所有人都有時間來踩坑然後一點點看源碼來學的。雖然我會繼續用mxnet（在我已經基本學會的情況下速度快省顯存確實是很吸引人的特性），但是我不太會推薦身邊的人在沒有mxnet老司機帶路的情況下入坑。

利益相關：來自於某官方已欽定 TensorFlow 框架的公司，必須匿名

前期調研過 MXNet （當時對深度學習不太了解），MXNet 本身的優點確實很多：比如多語言、多設備分散式支持、運行性能之類。

根據調研的情況說一下 MXNet 「可能」火不起來的原因：

1、推廣太強，而對應的效果可能還沒發揮出來：有一種僅次於Tensorflow的名頭（沐神說拍第三第四應該是謙虛），想想有 Amazon、Nvidia 以及余凱等一眾大佬站台，這個推廣還不強的話，黑人問號臉？

2、社區人員經歷嚴重不足，但同時有點避重就輕。像 TensorFlow 核心集中於 C++ 和 Python 的支持，核心人員重點解決主要問題，其他的主要依賴於強大的社區貢獻；而 MXNet 卻重點宣揚多語言支持，把核心成員本來就較少的精力分散到各語言去了，造成的結果就是看著樣樣有，但是樣樣不精。

3、框架本身屬於開始容易，入門難：簡單跑格樣例還好，但是目前文檔之缺乏和混亂的問題還是很嚴重的，不過似乎最近在重點改善。我是一點點扒issue和代碼才弄明白 CSVIter 根本不能用（然後核心 IO 庫裡面似乎沒有 LibsvmIter），SoftmaxOutput 外怎麼定義損失函數，DataIter 怎麼寫，Metrics 怎麼實現，Epoch/Batch結束之後的 callback 怎麼寫，Operator 怎麼實現（其實還沒完全弄明白）等等。

4、實驗效果上有差距，部分模型跑不出state-of-art的效果這個是致命傷，不過既然能做到性能上的優勢，這個應該不是大問題，慢慢來吧

5、其他比如 TensorFlow 吸引力太強，部分實驗室已經綁定在以往比較稱手的框架，這些問題暫時是無解的。

雖然已棄坑，但還是希望 MXNet 好好發展的，給點建議：
1、社區要有主心骨，定一下運營發展藍圖；

2、核心人員還是集中精力做框架核心的功能，主動延緩對某些語言和平台的支持（雖然有語言之爭，但是覺得既然某些小眾語言的社區這麼喜歡，他們自己還是會想辦法的^_^）

3、找人集中整理文檔，把入門弄得容易些，至少保證用戶從開始跑樣例到實現自己想要的網路和損失函數等這個學習過程弄得平緩些。

4、據說現在有Amazon等大公司背書了，可以考慮組織點會議多多宣傳，邀請部分contributor來報告、給社區title等等福利，國內有些公司和工程師還是很在意這些的，不過我想MXNet社區應該很擅長。

5、可以主動聯繫前端開發的人員來支持可視化，感覺相關社區嚴重精力過剩，搞一個深度學習的前端框架/庫對這個群體來說肯定很有吸引力。

沐神在上面分析的很透徹了，我來從使用者的角度來分析一下吧。
我從mxnet剛剛產生的時候，就已經在關注了，一直覺得是一個很不錯的框架，之前一直想跳坑，後來有人語重心長的和我說，mxnet文檔太少了，裡面有很多坑，你得一個一個的去踩。
進來之後才發現，還真是。裡面只有粗略的使用代碼，但是沒有很細緻的，具體詳細到每一個函數，每一個方法，每一個類的文檔。雖然已經有大量的例子，但是往往令新手望而卻步，這個是很關鍵的一個問題。
當然，你自己看源碼也是可以的，因為mxnet在各種模塊上，已經提供了不錯的源碼。你看源碼就可以慢慢分析出來，具體這裡是怎麼使用的，具體到底在哪種情境下使用。
真心希望mxnet會發展壯大，並且有自己的詳細的文檔。:)
利益相關：目前一直在用mxnet的用戶。

我覺得mxnet作為一個野生的項目，能達到現在這個流行程度已經很牛x了。如果非要說有什麼需要改進的，可能就是易用性。畢竟大家都是兼職在寫代碼，於是都比較懶得去弄文檔和例子。這點以後有亞麻和微軟支持應該會好一些。

theano, torch都比mxnet要早不少，而且拿這倆發論文的人很多，流行是正常的
caffee就不用說了，做圖像標配，主要就是使用方便，改起來簡單
TF就不用說了
比上不足，比下還是有餘的，要知道最近幾年，DNN框架不上百至少也有幾十個了。。。

仔細研究過MXNet的源碼，也嘗試過幫其做分散式實現的擴展和性能提升。由於這個原因，也曾經在朋友和學校中推廣這個框架，大家的反饋總結如下：

代碼的質量在不同源文件中差別很大，很多Bug不需要運行，仔細讀一下就能發現。
代碼中有很多dirty fix的痕迹，後期也沒有進一步更新。
文檔更新跟不上代碼的更新，很多樣例代碼跑不起來。
整個社群過於關注架構和代碼的推進，而忽視了穩定性和兼容性。

不過這也是可以理解，畢竟維護人員基本都是學生和科研工作者。希望Amazon加入後，能在架構和代碼質量下實現提升。

相比之下，其他框架一部署基本就可以跑起來，第三方文檔和拓展庫也很豐富。絕大多數的數據科學家其實並沒有太多部署的經驗，那麼如果框架難以一鍵部署或者缺乏豐富的文檔，很多初學者迅速就轉向其他選擇了。

總結一句話：一個穩定的「Hello World」都難以跑起來的話，跟使用者談性能優勢那就有點言之尚早了。

文檔太少，幹啥都要看代碼。

沒有在科研界形成社區。

一個框架／語言／平台能否成功，很多時候不在於他有多優秀，而在於他有多少的不可替代性。

Caffe，早期框架之一，只需要改一改 prototxt 就可以嘗試不同的參數／模型。Hinto那篇AlextNet橫空出世後，caffe 提供的 imagenet finetune 模型被不少後續研究使用，使得其快速形成了自己的圈子。即便它佔用顯存多，自定義 layer 麻煩，手寫複雜模型的 prototxt 惱人（現在可以通過 Python 寫），它依舊是許多實驗室的不二選擇。

要出多個 bouding box，上fast rcnn，發現別人 release 的代碼是基於caffe的。
聽聞 vgg 效果出類拔萃，發現別人也是在 caffe 上的。
FCN 系列，最早的 experiment 也是在 caffe 上的。為避免換個平台復現不出效果，只好去學 caffe。

同樣的看Torch，一是 Facebook 和 deepmind 的大部分工作都基於這些，如果你想繼續他們的研究，或者進行比較，都需要在一定程度上了解 Torch；二是在 caffe 早期對於 RNN 支持缺乏的情況， Torch 佔據了 RNN 的半壁江山。你想玩玩 word2vec ，seq2seq 不可避免會碰到這個框架。縱然 Torch 的報錯非常不友好，涉及到非 GPU layer 時計算效率低下，文檔不齊全（基本只有 github 的 readme 有用）。許多研究所還是選擇了它。

要知道實驗室遷移框架是一件很傷經動骨的事，不僅需要學生去重新學習，還要找人重寫歷史代碼。對於大部分水貨來說（例如我），學習新框架的最大動力，就是重現別人工作進行比較。反觀 mxnet ，每年有多少 oral 文章是基於他的呢？通讀完 CVPR 14~16 的文章，NIPS 15，ECCV 16後，我嘗試著復現了不少新穎的工作，release 中鮮有基於 mxnet 的。試想一下，要是某一年會議中有好幾篇 oral，甚至 best paper 是基於 mxnet 的，這個平台不用推廣也會名聲大噪吧。

學術界的推廣並不需要太高成本，建議團隊多勾搭勾搭能出 oral 的實驗室，讓他們放代碼時考慮下 mxnet，或是隨著潮流，在新工作出來時第一時間給出 mxnet 實現。個人而言還是很看好 mxnet 的，散修加油。

print help(mx.symbol)

我們可以看到

sum(*args, **kwargs) Take sum of the src.The result will be ndarray of shape (1,) on the same device.


        Parameters

        ----------

        lhs : Symbol

            Left symbolic input to the function

        rhs : Symbol

            Left symbolic input to the function
        name : string, optional.

            Name of the resulting symbol.

Returns ------- symbol: Symbol The result symbol.

查文檔，我們可以看到

mxnet.symbol.sum(*args, **kwargs) Take sum of the src in the given axis and returns a NDArray. Follows numpy semantics.

Parameters: src (Symbol) – Left symbolic input to the function axis (Shape(tuple), optional, default=()) – Same as Numpy. The axes to perform the reduction.If left empty, a global reduction will be performed. keepdims (boolean, optional, default=False) – Same as Numpy. If keepdims is set to true, the axis which is reduced is left in the result as dimension with size one. name (string, optional.) – Name of the resulting symbol. Returns: symbol – The result symbol. Return type: Symbol

不管了，試試再說，於是你敲下

mx.symbol.sum(None, axis=1)

你將會看到

Check failed: (kwargs.size()) == (0) Operator sum donot accept any keyword arguments

那麼我希望sum_axis怎麼辦呢？我也不知道... p.s.我用的是官網20160531的prebuilt

文檔太亂，python沒有自動提示，也就是說，你根本不知道mx.nd.裡面有哪些方法，想知道支持哪些方法你必須跑去看api

我承認它的性能好，我也嘗試過很多次去學習它，但是我真的hold不動它了...

簡單的說缺少文檔是不準確的, 應該說缺少教學類的文檔. 好在現在有 mxnet-notebook 了, 比我之前看源碼去領悟幸福多了. 例如之前我在寫自己的 DataIter 的時候, provide_data, provide_label 完全是懵逼的 o(╯□╰)o. DataBatch 中的 self.data 是必須的, 輸入的 Variable 的name最好是 "data" 不然會和默認值衝突.
另外, 一個小缺點是, 輸入的 NDArray 的shape 一定要和 Symbol 的shape 匹配, 但是, Symbol 和輸入NDArray 是分開的, 這就需要大家自己去小心調整了.
最後說一個不能說是缺點, 但是, 我不太喜歡的一點, 默認的參數太多了, 有時候代碼跑起來了, 但是, 因為使用的是默認的參數, 所以, 有可能你都不知道發生了什麼.
使用默認參數也可以, 但是最好能列印一下默認參數的log

用過MXNet，也想推廣MXNet。但並不同意它是因為沒有進行推廣而沒火起來。
說一說它的直觀感受:

1.數值穩定性。

同樣的神經網路結構和優化方法，在Keras上跑是state of the art，在MXNet上是NaN，並不收斂。神經網路的複雜性，使得這種錯誤很難排查是哪裡出了錯。給人的第一印象變得就不太靠譜了，這個不管對於公司還是科研都很致命。選擇一個框架，一般都會做對比測試的，如果這個階段就出現這種問題，直接就會默默無聞的被pass掉了，不會在Github上得到任何反饋的。

2.輸出的介面。

一個logger輸出，在IPython Notebook里用的死去活來，出現中間結果輸出問題。只想輸出每個epoch的結果，並不想看batch的結果，竟然是不行的，要手動自己寫一些代碼。這麼自然和標準的輸出方式都要自己查看源代碼和改寫，影響開發效率。

3.支持的語言多。

既是優勢又是劣勢，劣勢更多一點。每種語言都支持，支持的程度還是有些差別的。不同的人的對於不同的語言理解的不一樣，實現的程度也不一樣。

4.介面的靈活性有待提高。

數據擴充DataAugmentation，只能用RGB三個波段，剩下的多波段數據都沒辦法了，我的數據有5個波段，哭泣中。

Softmax和CrossEntropy其實是兩個不同的東西，MXNet封裝在一起了。也有單獨提供的Softmax Activation，裡面的參數看的一頭霧水。想修改它的CrossEntropy的代碼，這個是C++的代碼，我用的是Python，現在還是不知道該怎麼用Python實現它。繼續哭泣。

5.社區氛圍

很多問題都是問了之後一直處於沒人應答的狀態的，keras的氛圍就好很多，基本是當天就能解決問題。看到MXNET有個關於Softmax的問題，那人問了之後，一個主要代碼貢獻者很含糊的說他應該用SoftmaxOutput，並沒有真正關心那個人的需求和問題。

6.代碼注釋

注釋的力度還不夠。都是跑去TensorFlow或者Keras的網站對照著看代碼，本人讀起來還是比較費力。

7.多機多GPU

其實TensorFlow也可以多機多GPU的，只不過MXNET做的更好。如果不是因為TensorFlow這點做得太差（那個代碼真的是複雜，沒有封裝），MXNet用的人會更少一些。這個是核心亮點。它的多平台其實不太算優勢。

8.文檔

文檔不多就罷了，函數參數的解釋讀起來有點繞且抽象。這點也是很多人提到的硬傷。

綜上，MXNet是有潛力成為一個有用且流行的庫的，但目前還不是。

@李沐
為什麼inception v3從distbelief移植到tf老是跑不出想要的精度?
我們把caffe的model轉到mxnet上,發現精度也不一樣,為什麼?

就說說我用MXNET的感受：
教學文檔不夠系統、全面和詳細，行文有錯別字，教學文檔里至少發現四五個以上鏈接失效問題。也找不到官方的無root許可權安裝MXNET的方法，這樣在有些伺服器上沒法用。我是先用的Theano和Keras，想試試MXNET，看了主頁介紹感覺棒棒噠，用了以後有點失望。希望這些問題能儘快解決，穩定性、可靠性、易用性也很重要啊。
用Theano和Keras的感受：
教學文檔系統、全面、詳細，沒有錯別字，沒有鏈接失效問題。並且按照Theano的教程過一遍，相當於對深度學習入門了。而用Keras實現各個模型就像搭積木一樣直觀。
TF沒怎麼用，就不說了。

缺乏亮點。

其他幾個主流 frameworks，都有各自的特點：

TF 不用說了
Caffe 算是最早流行起來的 framework，很多 vision 的模型都是基於 Caffe，不用不行
Torch 靈活度比較高，一些演算法用 Torch 寫起來方便
Keras 容易上手
……

MxNet 很優秀，但給我的感覺是在任何一個維度上都有比他更好的。最大的特點似乎是中文社區很活躍，很多中國人在用，或許 MxNet 可以以這個為特色，加強向國內推廣，而不要和 TF 等框架去競爭。

用過一年的caffe，現在開始往mx上轉。也遇到了不少坑，大概舉例一下：
1. 更新的太快，有時候前後版本不兼容，大概8月份的時候更新了pooling層，然後就發現之前的pretrained model不能用了。更新過一次bn層，然後跑驗證集的準確率就出問題了。當然官方馬上就修改了，而且確實很快。。
2. 有些很簡單的需求需要很複雜的實現。就像沐神所說，caffe的流行得益於pretrained model和快速在這些model上finetune, 但是mxnet的官方例子到目前好像都沒有一個簡單可靠的finetune腳本。而且在自己實現finetune時，還會遇到很多坑。比如我想「固定住前面幾層，只計算後面幾層的梯度」這個caffe中很容易的例子時，貌似需要通過simple_bind這個比較底層函數來完成，而不能用FeedForward這個高級的類來實現. 使用gradblock op或設置不同層learning rate這兩種方法時，還要注意底層weight decay的問題（看到winsty在很多issue里提示這個問題。。）。
3. 本人C++水平一般，但是caffe的C++代碼我基本可以全部看懂。自我覺得mx的後端代碼比caffe難懂很多，主要原因是有很多設計方法之前沒有接觸過，導致很多dmlc里封裝的類第一次見時有些懵（如dmlc::Parameter）。雖然大部分人用caffe時也不會改很多後端源代碼，但是能看懂源代碼的工具用起來肯定是有種得心應手的感覺。也希望mx能多出更詳細文檔介紹一下。

但是瑕不掩瑜，mxnet是一個極為優秀的平台。

更新很快，是優點也是缺點。

優點當然不必提，及時解決bug，各種666功能飛起。

我說一下缺點：
我記得我四月中旬編譯了一個版本，五月份對照官網API寫代碼時一直報錯，後來發現是更新了，API中的方法在老版本中並沒有。（不知道以後更新時API能不能標個時間戳）
聽說前一段時間核心代碼在重構，不知道完成沒：）

我想很多人固守caffe等框架，一方面是文檔、資料比較豐富，另一方面是感覺比較穩定吧。

是否能考慮捐贈入apache foundation ,獲得更好的支持？

關於DL框架，我覺得自己研究課題的引領大牛或者頂尖實驗室都在用什麼框架，以及該框架是否有足夠的說明文檔教程，最好是視頻教程，對我們剛入門的學生來說，是最重要的，什麼性能啊，靈活性啊，都可以後面在考慮。。。

tf：pip install tensorflow
然後去跑樣例，看源代碼，握日，好**炫酷
來我們來學習一個

keras：pip install keras
然後跑樣例，看源代碼，握日，更**炫酷
來來來學習一個

mxnet：emmmmmmmm

我勒個去，還嫌不夠火？一開源項目干到三個大佬官方支持，還想鬧哪樣？非要幹掉tf才算火？