如何看待 2020 年 3 月 28 日華為開源的深度學習框架 MindSpore？

作為友商，並且是做相同方向的友商，再加上最近關於AI框架開源的節奏很熱鬧，忍不住也來蹭個wifi，表達些觀點：）

純技術討論，不涉及其他，部分我拿不準的地方，會直接以(?)標識出來，歡迎菊花廠同學來指正解惑。

華為的運營同學蠻專業的，在回答里介紹了一些比較重要的技術細節，哪怕不看code，對於做這個方向的同學，也大概也能捕捉到裡面的一些core concepts，YongCHN同學也對MindSpore的auto parallel部分有一個小調研，也可以供感興趣的同學了解。

最近關於AI框架開源的討論比較多，包括Jittor和MegEngine以及MindSpore，所以我想還是盡量能夠提供一些有額外信息量的輸入。

從框架的設計原則上，個人認為MindSpore還是蠻中規中矩的，能夠看到明顯從TF，PyTorch里分別借鑒了兩家的經驗（不要忽略MxNet的Gluon，其實也是把靜態圖和動態圖結合在了一起，可惜這兩年日漸勢微，其實也從一個側面反映出引擎技術核心以外因素對AI框架推廣的重要性，參見這裡的一個回答，更不要忽略了Theano這樣的已經deprecated框架里早就有的靜態圖的淵源以及當年還小引領過風騷的Chainer）。都是做這個方向的，就不客套了，官宣里提到的將python的模型描述JIT編譯成計算圖的思想，在Google的JAX/auto-graph以及PyTorch的TorchScript相關的工作里比較早就已經touch了，不過有決心去從頭build並落實，這個還是值得點贊。

2. 如YongCHN同學關於auto-parallel的分析里所說，在TF里，為了在python層加入auto-parallel的支持，同時還兼顧TF 2.0的eager mode，在python代碼里引入了大量的 if (eager_mode) 的判斷，讓整個代碼的可維護性受到了不小的影響，而TF為了加入Distribution Strategy的支持，對其現有的python構圖代碼也做了大量的修改和插樁，其實讓整個框架的python層實現複雜了不少。而MindSpore的整個code base，在auto-parallel的實現上能夠感覺到還是清晰了不少，引入了ANF這個IR層（關於ANF的設計理念之前自己並不了解，感謝@葉子豪同學的輸入，稍微補了些課，相關的background材料可以參見這裡和這裡，也對照著重新看了一下ir/anf.h里的定義，認為設計動機確實如ANF的背景材料所說是為了簡化source-level的變換複雜性，關於細節，這方面不是我的expertise，如果有了解的同行能夠share更精準的理解就太好了），把分散式策略的工作有不少沉到了以ANF IR這一層，避免把python API層改得太慘，這個設計認為是更合理的分拆，也確實在沒有歷史包袱的框架里更容易make這樣的design choice。站在前人的肩膀上總是能夠也應該有更好的創新。

3.在我的理解中，MindSpore的架構層次大體上可以拆分為

ME(Mind Expression)
Graph Compiler
運算元庫(GPU/CPU平台上的比較常規，Ascend上是對CANN運算元庫的封裝，只不過在代碼庫里只看到了少量的CPU運算元和GPU運算元的實現，Ascend的運算元實現則沒有看到源碼，沒有理解錯的話，是通過拼裝JSON串作為輸入再通過一層bridge獲取到對應運算元的執行碼，對應的具體執行碼目前並沒有開源出來，說得不對請花廠同學指正)
Runtime

這幾個大層次。

從git repo的組織來看，ME、運算元庫(部分運算元庫目前以閉源.so的方式提供)基本都放在MindSpore的主體repo里，Graph Compiler和Runtime放到了GE(Graph Engine)的repo里。按官網的doc似乎主要的fusion工作是在GE里完成的。但是呢，一些涉及到運算元fusion的邏輯又散在了MindSpore主repo里，同時也在GE的repo里看到了一些fusion的pass。這讓我稍微有些curious為什麼是這樣組織。從架構設計上，會感覺fusion相關的邏輯應該統一放到GE的repo里才自然。

目前我能夠推測出的一個原因是GE主要target Ascend硬體，對於GPU相關的fusion不屬於GE的範疇，所以在 MindSpore的repo里針對GPU的fusion做了一些比較直接的工作(?)。

4. 整個執行flow從代碼結構來看是這樣的，

用戶完成python層的模型構圖
調用python層的train API(mindspore/train/model.py)以後，會通過pybind11的介面觸發 ExecutorPy::Compile()，在這個函數的實現里，會將用戶python模型描述的AST解析成ANF的格式(了解JAX和auto-graph的同學就能看到相似之處了)
完成ANF graph的構建之後，剩下的事情就比較自然了，在這個graph上bla bla bla做一系列的transformation，直到生成一個編譯好的byte string，並將這個編譯好的結果序列化保存下來
再通過一個pybind11的介面觸發ExecutorPy::Run()，對上面的編譯結果進行實際運行。

這個流程其實蠻自然的，至少在JAX和TF auto-graph項目里都有類似的作法，在PyTorch里其實也有類似的嘗試，核心的難點我認為是在於Python的語法太靈活了，於是在不太起眼的AST2XXX(XXX可能是TF GraphDef，可能是JAX里的HLO graph也可能是MindSpore里的ANF graph)這個步驟可能會出現大量的corner case。PyTorch通過python解釋器和PyTorch核心交互調用的方式（算是一種trace的方式）來犧牲一定性能但根本性的避免了這個陷阱，而JAX也好，auto-graph也好，以及MindSpore也好，在想獲取動靜結合的組合優勢的同時，也需要pay for對應的engineering cost。

5. 當前開源出的結果里，model zoo還是偏少，這其實不難理解。AI框架演化到現在這個階段，我個人認為，哪怕是為一個新的硬體平台，從頭開發一個AI框架的核心idea也都已經基本是顯學了（扒扒TF/PyTorch的code，讀讀相關的system design的paper，有精力興趣的話再去刨一下Chainer/Theano/MxNet相關工作的材料，主流AI框架的核心idea也就拿到了），難點其實在於如何結合具體的硬體平台以及業務場景將構成框架的各個pieces有效地組織起來，獲得好的trade-off。這背後有著大量的系統設計和工程架構的要求。之前Jittor剛出來那會兒，有商湯的朋友在朋友圈裡感嘆說兩三個可以做一個AI引擎，我對這個觀點持很大的保留意見，如果說兩三個精幹的人搭一個能夠跑通幾個public model的AI引擎原型甚至在個別模型上有不錯的性能表現我沒有任何疑問，但從跑通幾個模型到達到工業級生產水準，我認為還有著巨大的宏溝需要跨越(性能的魯棒性，計算結果正確性，訓練到推理鏈路的完整和流暢性，從雲到端不同設備覆蓋的廣闊性，針對不同場景的架構設計的妥協等等，背後都對應著比較巨大的工程資源的投入)，這裡先不展開了。

6. 關於材料中提到的整圖下沉的技術點，確實需要承認，當能夠自已掌握從硬體到軟體全鏈路時，系統的整體優化空間變得就更為廣闊，整圖下沉就是一個例子了。在DaVinci的晶元，配備了ARM的cpu，就使得加速器上也具備了通用計算的處理能力，四個CPU core跑一個OS，四個CPU core跑一些不適合DaVinci的Scalar/Vector/Cube計算特點的邏輯（比如一些條件控制邏輯甚至IO預處理邏輯等）是一個聽起來make sense的技術點。這裡可能有一個小的陷阱是，在AI作業里，有些時候，對CPU的算力需求可能會比較大（比如IO或網路通信），甚至超過DaVinci的片上ARM CPU的算力capacity，這種情況下，MindSpore在DaVinci晶元上的性能表現就更值得關注，也是更考究系統設計魯棒性的地方了。系統設計沒有magic，每一個晶體管，每一個cycle，用到這個地方以後，就不能再用到另一個地方了。軟體系統的設計也類似。當然了，花廠有很強的硬體自研能力，如果說未來的晶元會引入IO core或對AI晶元上的通信能力進行強化，進一步offload對片上通用CPU算力的需求，讓整個AI作業的執行過程儘可能不要跳出片子，我倒是也不會意外。不過另一個設計維度也許是，不一定要求作業執行過程完全不能跳出片子，而是通過一些機制來保證當作業部分執行環節跳出片子，也能進行性能補位（類比GPU設計理念里通過高Occupancy來確保可並行調度的計算需求足夠高，來緩解消隱訪存latency開銷的作法）也許是一個可以考慮的點。Again，這裡的難點在於設計trade-off的抉擇，比如說作業完全在片子內能cover性能是100分的話，如果不能cover，是期望對這類作業退化到90分呢，還是退化到80分但同時反過來把那10分的餘量用於確保片內完全能cover作業的性能達到120分？這需要結合workload趨勢理解，軟體棧系統把握能力，以及硬體架構設計，用至最終的硬體工藝實現來進行一個全局的把握，是一個值得玩味也迷人的複雜系統設計問題。

7. 對於MindSpore背後的計算密集運算元相關AI編譯的工作，其實還有著比較強的興趣想進一步了解，即對應於TBE(以及TIK(?))背後的工作，不知道未來是否也會開源出來。

先寫這麼多。

最後聲明一下，以上理解，完全基於周末對MindSpore的代碼層閱讀理解，很大可能會有偏差，還請相關同學指正。

【2020.4.3 更新】：我孢B站上線了！後面社區例會、在線分享等活動的錄屏都會上傳，儘可能保證我們所有討論的公開可獲得性，方便開發者查閱。社區例會對於我們來說也是一種新的嘗試，昨天Data SIG做了第一次試水，來自中加的開發者中英文混雜的討論，可能不像一般上游社區例會那樣有序，但畢竟是邁開第一步，求大家彈幕輕噴：）

嗶哩嗶哩 ( ゜- ゜)つロ乾杯~ Bilibili?

space.bilibili.com

大家好，作為MindSpore的社區運營負責人，來還願(怨？)了。前情可見：

如何評價華為全場景AI框架MindSpore即將開源，能否超越Tensorflow和Pytorch？?

www.zhihu.com

說實話即便對於無腦黑，我也是非常感激的，因為在衝刺準備的3月，和他們的對話給我帶來了無盡的歡樂，極大的緩解了壓力，還幫我們做了免費的預熱。本來想安排這次扯淡事件中爆火的我們可愛又超牛的TommyLike同學，提交initial commit，打一打某些人的臉(除了此前話題下面的各位噴，還有像這位同學這樣的

後來想想那陣沸騰魚鄉般的熱鬧暖場，還是應該心存感激才對。

閑話少說，書歸正傳，再扯多了又該被批評不懂開源偷偷去聽Tensorflow seminar了。。。不想搞很長的貼，官網資料^[1]或者公眾號很多軟文都可以看，這裡就挑MindSpore兩個最重要的層面：Frontend Expression (簡稱ME) 和 Graph Engine (簡稱GE)來說說MindSpore一些主要特色吧。

ME:

ME採用模塊化方式描述網路，採用及時編譯(JIT)的方式將Python描述的網路靜態編譯成計算圖，提高網路被執行的效率。

自動微分方面實現了一種通用的基於源碼轉換(SCT)的自動微分，可以做到支持全部主要的語法結構(閉包，函數調用，條件跳轉，循環，遞歸等)。

並且在執行前對反向計算過程進行靜態分析和圖優化，這樣可以提前規劃計算任務和數據搬移以及優化掉冗餘的計算和內存開銷，達到最佳的執行效率。

在此基礎上，支持自定義梯度和基於剪枝優化的stop_gradient以及可控制反向傳播的梯度hook，來滿足不同場景的自動微分需求。

基於graph-based IR在表達性上具有高度的靈活性，甚至可以做到打破圖跟運算元的邊界，把運算元側的一些優化提前到圖優化階段來做，達到圖算聯合優化效率。

ME編譯得到的計算圖是device無關的，針對不同後端進行特化，可以在Ascend、CPU及GPU等多種不同的後端上進行訓練和推理。

GE:

圖引擎的核心設計理念是以並行和資源為中心，即挖掘模型計算的並行性，高效映射到計算/內存資源。以下兩個設計是當前MindSpore性能關鍵。

Pipeline並行：訓練中的每次迭代包含多種計算處理，包括數據處理、前向/反向計算、梯度聚合等，充分的並行是發揮硬體中多種引擎算力（Scalar/Vector/Cube/Comm）的關鍵。GE圖拆分基於引擎代價模型自動映射圖節點，實現不同子圖之間全非同步，比如log/metric處理和前向計算全非同步，數據處理和前向/反向計算全非同步，反向計算和梯度聚合全非同步等。同時GE設計上解耦圖表達和計算引擎，新增引擎自動註冊即可實現網路圖在新引擎的並發映射，適應晶元未來架構。

TF 2.1實驗性支持CollectiveHints(bytes_per_pack)來強化反向計算和梯度聚合的全非同步從而減少拖尾。MindSpore基於昇騰組網實現自動融合通信，無需開發者指定Hints。
Horovod: fast and easy distributed deep learning in TensorFlow這篇文章通過Host側MPI控制融合策略，需要引入gather和broadcast同步，對於算力強的晶元這個同步開銷不可忽略，也不適應能夠整圖下沉的晶元架構。

整圖下沉：得益於昇騰晶元的創新架構，圖引擎針對高性能訓練場景使用整圖下沉設計，即圖優化的結果一次下發到晶元，無需在Host上通過圖Runtime分發op，極大減少交互開銷。這對GE圖優化能力提出極高要求，類似傳統VLIW中的靜態指令調度，每個task的排布都要充分對齊晶元資源利用。GE圖優化既實現通用優化（比如const folding，CSE，代數化簡、數學融合等），也實現硬體感知優化（Stream分配/Memory分配/Task編譯/Buffer Fusion等），特別支持包含控制流結構的網路圖的優化和硬體映射。Format是Tensor的基礎屬性，也是NPU硬體設計的性能選擇。GE實現以重開銷運算元為錨點的擴散演算法，實現整圖的全局format最佳適應，匹配運算元的硬體偏好實現性能最佳，並最小化轉換開銷。MindSpore GE的圖優化是業界第一個支持NPU的開源圖引擎。

Show Me The Code

當然，直接擼代碼是最好的體驗方法。MindSpore目前提供了pip、源代碼、docker(CPU，GPU)^[2]等多種安裝試用方法^[3]。4月份我們會開始提供昇騰開發者環境的體驗，但開發者即便沒有GPU或者昇騰910的環境，在CPU上也能驗證MindSpore的簡單構建和執行。只不過有時候三方庫的下載可能會有些慢，如果大家都遇到這種情況的話，去提一個ISSUE，我們在社區給大家把緩存弄好。

我們也準備了一個很挫很基礎的基於kubeflow 1.0和kubernetes 1.14版本的MindSpore Operator^[4]實現，熟悉kubeflow的開發者可以按照README中的步驟進行一個超級簡單場景的復現，大致體驗一下MindSpore的容器化部署和運行。MindSpore Operator這個坑我們會一直填下去的。

如果在試用過程中有問題，請先移步我們的FAQ，如果FAQ不能幫到你，請直接在ISSUE區按照模板提交ISSUE。

為了方便海外開發者參與，我們在github同時維護了一個鏡像倉^[5]，並且開放了PR和ISSUE的提交。

代碼相關的許可證採用的是很多開發者所熟悉的Apache 2.0，文檔和書籍中的非代碼內容，則使用了CC-BY-4.0的許可證。

總體來說，MindSpore還很年輕，開源不是終止符，開源只是萬里長征第一步，後面要和大家一起走。

寫在後面

對於我們這些常年混跡上游開源社區的人來說，做開源的本質其實就是做內容，只有做好了內容，無論是選擇商業、非盈利還是其他模式，都不會太差。我在之前帖子的回復中也提到過，我們這次準備MindSpore開源也是想盡全力把內容做好，但是這個內容的維度，實際上往往是超過技術本身的，它包括了技術項目、社區基礎設施、網站、社區治理模式、文化建設等方方面面的事情。希望我們這次提供出的，是一份合格的內容。

我們也經常會被問及各種比較的問題，其實對於開源人來說，與你死我活的產品營銷不同，我們更希望通過交流、合作，碰撞出有趣的新的idea出來，所以比如最近開源的Jitor和MegEngine，對於開源界來說都是極好的事情，我們也在想和這些很牛的開源項目挖掘出一些合作點。之前在啟智OpenI開發者大會的panel中，我跟Oneflow的袁老師說，特別希望兩者有沒有可能結合起來，MindSpore負責貌美如花(開發與部署體驗)，Oneflow負責掙錢養家(大規模集群並行的編譯優化)，如果能有這麼一種解決方案的話，豈不是太好了。順便推薦袁老師最近的一個帖子：

袁進輝：如何欣賞一個深度學習框架？?

zhuanlan.zhihu.com

2020年出生的MindSpore，感恩前人的積累，野望AI的新方向。

(例行廣告，歡迎加入我菊的頭孢大軍:) -

社會招聘 | 分散式並行計算實驗室?

mp.weixin.qq.com

華為海思 | 社會招聘?

mp.weixin.qq.com

參考

^https://www.mindspore.cn
^https://gitee.com/mindspore/ms-operator/blob/master/README.md#mindspore-docker-image
^https://gitee.com/mindspore/mindspore/blob/master/README.md
^https://gitee.com/mindspore/ms-operator
^https://github.com/mindspore-ai
^https://gitee.com/mindspore
^https://gitee.com/mindspore/community/blob/master/governance.md
^https://gitee.com/mindspore/community/blob/master/code-of-conduct_zh_cn.md

為什麼大家不約而同的造輪子？那一定是現在還有很多沒有解決的問題。

問題1，目前的AI框架難以支持如雨後春筍般冒出的AI處理器；tf或者pytorch能很容易的支持一個新的AI加速器嗎？tf或者pytorch演進了怎麼辦，重新遷移一次代碼嗎？想想這個代價吧。第二種選擇，那就自己造個框架，支持自己的晶元。HW這種巨型玩家，居然既要又要，也是服了，真有錢。

類似的，我們看看gcc和llvm是怎麼支持一個新的硬體的？經過幾十年的發展，淘汰了很多編譯器，最終gcc和llvm二分天下；在這個過程中，傳統cpu的設計也逐漸趨同，使得編譯器能做到比較容易的支持一個新的cpu。而中立的編譯器一旦出現，最早的編譯器玩家，例如IBM、intel會逐步轉向開源編譯器。

但是做過DSP或者其他古怪的晶元的同學，發現gcc或者llvm支持起來，需要很多定製化的修改。類似的AI晶元支持和GPU的支持，對框架開發來說，難度也不可同日而語，HW同學可以談談體會。目前的AI晶元架構應該還處於早期發散階段，所以誕生一個能支持大多數架構的中立的框架，從客觀上講還需要一定的時間。

因此在這個階段，自己做一個框架支持自己的晶元，甚至去嘗試一下成為未來的gcc或者llvm，是一個理所當然的選擇。目前猜測HW應該意在AI晶元的生態。

問題2，拋開AI生態，框架其實還有不少問題，運算元和圖層隔離，需求跨度太大（運算元庫在廠商手裡，自定義和優化難），對新應用的發展不利，同時物理分層，難以全棧優化。TVM、MLIR等項目的誕生，也是想解決這個問題，自定義運算元，運算元優化，全棧優化。就拿自動微分來說，你很容易使用tf和pytorch的python api組一個運算元，自動生成微分運算元出來，但是這個肯定沒辦法直接跑在AI加速器上，有產能沒性能。如果你用cuda或者加速器的介面或者運算元開發語言手寫一個運算元出來，性能還不錯，但是有性能沒產能。如果有一種既有產能有又性能的方式出現，這是一個巨大創新。

問題3，框架的IR設計還沒有成熟。運算元IR應該設計成粒度，使用什麼樣的抽象來組織？這些問題在現有的框架中都沒完整、成熟、通用的方案。jittor xla都在嘗試解決和優化這些問題，但還是有缺陷難以克服（運算元粒度太小，丟失信息融合回不去了）。

問題4，優化還是比較adhoc。相比傳統編譯器中的理論和演算法，AI框架的優化手段不值一提，全是pattern match！而這個方向上，出現了傳統編譯裡面類似迭代編譯的技術，所以我們看到autotvm，TASO都在嘗試用AI的方法來做編譯優化。但是這些方案只能離線使用，在線還是需要類似傳統編譯的演算法或者cost model。

問題5：框架難以支持更複雜模型。對控制流，高級數據類型的支持和優化還比較弱。這是一個雞生蛋和蛋生雞的問題。很難說是制約著誰。或許只有框架支持了，更多的應用才會誕生。

先點個贊啊，看了一眼代碼和例子，感覺完成度非常高

一些感想

比起pytorch，其實mindspore更接近於tensorflow

GHLO對應了TF HLO，下面的圖執行引擎對應了xla
編程的python介面類似於keras/pytorch lightning，通過model+封裝好的optimizer/callback來進行訓練。這樣做的缺點是需要定製訓練過程的時候會損失靈活性，優點是利用現有常見的訓練方法更容易，而且非常容易擴展到多機多卡上

粗看了一眼Source code transformation似乎完成度非常高（但是沒看到詳細例子，建議多加點例子到doc里）

亮點

MindInsight（link）從截圖來看比Tensorboard功能更豐富，那麼多年了可視化終於可以有了新選項……
並行策略豐富（link）

支持model parallel/混合modeldata parallel，這方面現有框架都做得比較少，不知道mindspore在引入這個之後性能有多少提升？
通過Cost Model, 同時考慮內存的計算代價和通信代價對訓練時間建模。這個之前只在論文里出現過，算是第一個開源工程實現？從之前華為的DawnBenchmark排名來看這個對多機效率的提升應該還是比較明顯的