開發易、通用難，深度學習框架什麼時候才能飛入尋常百姓家？

本文由 「AI前線」原創，原文連接： 開發易、通用難，深度學習框架什麼時候才能飛入尋常百姓家？
做者｜老師木
編輯｜Emily

AI 前線導讀：」深度學習框架正在快速演化，各大公司都推出了本身的框架，TensorFlow, PyTorch, Caffe2, MXNet, PaddlePaddle，大大推進了深度學習的發展，同時也讓用戶有應接不暇無所適從之感。咱們認爲，深度學習框架用戶有必要去了解深度學習框架的一些基本原理，這有助於咱們用好「框架」這個工具，也有助於根據自身須要去選擇合適的框架。

2018 年 1 月 14 日，袁進輝（老師木）表明 OneFlow 團隊在 AICon 北京站作了標題爲《深度學習框架技術剖析》的演講，AI 前線第一時間受權整理了老師木我的註解版演講全文。」

做爲框架的開發者，OneFlow 團隊（一流科技，老師木的創業公司）發現，雖然框架多種多樣，但框架核心技術正呈現收斂的態勢，通過幾年的發展，在深度學習框架開發者眼裏出現一些「共識」，或所謂「最佳實踐」，幾乎全部框架都去擁抱了這樣技術選型，在架構和技術選擇上趨同。另外一方面，也有一些技術在框架開發者眼裏屬於猶豫不定或機關用盡的狀態。

此次報告會對已經收斂的技術（「最佳實踐」）作一個梳理，讀者會發現，開發一個深度學習框架沒有那麼難。本報告也會簡要討論目前框架未解決的難題，讀者也會發現，開發一個超越已有技術的框架有很難的問題。最後，咱們會從框架開發者的視角去對主流深度學習框架作一句話點評，供用戶在作技術選型時參考。

深度學習框架的定位

首先介紹深度學習框架的背景，而後介紹深度學習框架開發中已經收斂的技術和仍未解決的問題，其次點評主流深度學習框架，最後對 2018 年的深度學習框架技術發展作出展望。

在進入正文前，讓咱們首先聲明一些前提，若是這些前提不成立，那麼「深度學習框架」就沒那麼重要。但這次報告不會花時間筆墨去論證每一個觀點，讀者若想了解這些觀點背後的邏輯，能夠參閱 OneFlow 微信公衆號的歷史文章。

本文僅對第四點作一些闡述，用軟件實現深度學習算法加速，可分微觀和宏觀兩個層次。

微觀層次主要聚焦在單個設備或芯片上的代碼優化，設備廠商一般會工做在這個層次，他們會提供高性能的庫，譬如 x86 或 arm CPU 上 MKL, OpenBlas，Nvidia GPU 上的 CuBlas, Cudnn 等，在大部分稠密計算場景都能貼近設備的理論性能，優化空間不大（固然在終端設備等低功耗場景有不少發揮空間）。

宏觀層次，主要是多設備和多計算節點層面的優化，這要靠分佈式框架的支持，是計算力推向更高水平的關鍵，在性能上仍有巨大優化空間。最後，深度學習軟件要解決編程不夠快（程序員的效率）和程序運行不夠快（計算機的效率）兩個痛點，「兩個痛點的描述」出自尼克著《人工智能簡史》裏的一句話。

weixin.qq.com/r/KSrexuXEu… (二維碼自動識別)

對深度學習框架感興趣，可關注 OneFlow 公衆號，下面幾頁報告的詳細註解均可以在歷史文章 GIAC 報告《深度學習平臺技術演進》中看到。

神經網絡由若干層次構成，每一個層次一般均可以表示成對矩陣的處理，這種稠密計算形式特別適合使用高度並行的硬件加速（GPU、TPU 等）。

限於硬件製造工藝水平，單個設備（GPU、TPU) 不可能無限大，而工業級應用對計算力的渴求是無止境的，此時就必須用高速互聯的多個設備協同來完成大規模計算。上圖展現了 GPU 集羣和 TPU 集羣，在這種配置裏，一般是 CPU 和 GPU （或 TPU) 一起工做，CPU 負責任務的調度和管理，而 GPU 負責實現稠密計算，這就是常常說的異構計算（Heterogenous computing）。

「硬件越快，軟件越難」這個觀點分享過屢次，請參閱《深度學習平臺技術演進》一文。

簡要說：自上而下看，深度學習模型訓練一般使用隨機梯度降低（SGD) 算法，是更接近流式計算的一種負載：每處理一小片數據，就引發系統內部狀態的變化；自下而上看，深度學習普遍採用異構計算技術，GPU 此類的設備吞吐率很是高，是 CPU 的 10 倍以上，意味着一樣大小的計算任務，GPU 能夠更快完成。從小粒度和快設備兩方面看，深度學習訓練中的計算任務粒度很是小，一般是數十毫秒到百毫秒級別。可是，設備互聯帶寬並無實質改進，譬如同機內部 PCIe 或多機互聯使用的高速以太網或 Infiniband 的傳輸帶寬要低於 GPU 內部數據帶寬一兩個數量級。以上因素給分佈式軟件框架帶來巨大壓力，若是處理很差，就會形成設備利用率低，總體系統性能差的後果。打個比方，雖然高鐵要比普通的列車開起來快不少，但若是讓高鐵每一個車站都停兩分鐘，那麼高鐵並不會比普通列車快多少。

軟件層和硬件層都是屬於「計算力」範疇，軟件層扮演了傳統意義上操做系統（OS，如 Windows, Linux），或者互聯網時代瀏覽器，或者移動互聯網時代 Android, IOS，或者大數據時代 Hadoop 的角色，是上層應用的入口。同時軟件生態又定義了底層硬件的角色，會影響底層硬件的發展和命運。

深度學習框架的最佳實踐

咱們首先介紹深度學習框架中已經收斂的技術，理解了這些原理，每一個人應該能開發出一個本身的深度學習框架。

在進入技術細節以前，讓咱們先來理解兩個很重要的概念：控制流（Control flow） 和數據流（Data flow)，這倆概念事關後續一些關鍵的技術選擇。以 a = x + y; b = a * a; c = 4 - a; 這樣一段簡單的程序爲例，有兩種編程模式，一種是以 C 語言爲表明的命令式編程（imperative programming），語句的排列順序隱式的刻畫了程序的執行順序（左圖中虛線箭頭表示執行順序），有哪些語句能夠並行執行，並不太明確，若是要在多個線程中執行這幾條語句，爲了防止出現多個線程間的讀寫衝突，可能要使用鎖 （lock）等技術來保護某一個變量（某一段內存）防止出現 data race。

另外一種編程模式是以 Lisp 爲表明的函數式編程（functional programming），程序用一系列表達式來刻畫，程序的執行不是按表達式的聲明順序來執行，而是從表達式中挖掘出各個表達式之間的數據依賴關係，把數據依賴關係用一個有向無環圖來表示，圖顯式刻畫了哪些表達式必須在另外一些表達式以前求值，或者哪些表達式之間不存在依賴關係，能夠並行執行。在並行和併發愈來愈多的世界，functional programming 和數據流程序正在愈來愈受重視。

數據流模型通常表示成有向無環圖（Directed acyclic graph, DAG）。譬如上一頁的 a = x + y; b = a * a; c = 4 - a; 三個表達式能夠表示成這樣一張圖，圓圈表示數據，方塊表示算子。算子之間靠數據的生產和消費關係產生依賴。數據流模型的優點主要包括兩方面：

（1） 表示上的好處，顯式描述了程序中的全部並行機會；

（2）實現上的好處，數據流的執行引擎能夠用很簡單的方法支持併發和並行，而在控制流程序中對併發和並行的支持就要複雜的多。

比較早的框架 Caffe 經過 Layer 這種抽象，運算和數據是放在一塊兒的。TensorFlow 出現後，有向無環圖中兩個最基本的元素，操做符（運算）和張量（數據）是分開表示的，這種抽象模式也被其它框架所採用。具體地，Operator 通常是運算的描述，Kernel 是運算的具體實現，在實現上還要考慮操做符粒度的問題，理論上若是支持了最基本的加減乘除就能夠經過圖計算自動支持更加複雜的運算（如一些神經網絡層次的計算），但粒度太細就對編譯器要求特別高，當前編譯器生成的代碼不必定能超過工程師手工優化的代碼，所以在多數框架裏都是直接支持一些粗粒度的操做符，譬如卷積操做符，矩陣乘操做符等（值得注意的是 TensorFlow XLA, TVM 在細粒度操做符描述的圖優化方面有一些好的實踐）。對於張量計算的支持，業界也有不少技巧，譬如通常使用 C++ 模板元編程來實現，藉助於編譯時計算來提升運行時的效率，TensorFlow 等框架通常基於 Eigen 庫，MXNet 使用本身開發的 Mshadow。

autograd 已經成爲深度學習框架的標配。有了 autograd，用戶寫程序時，只須要描述前向計算是怎麼作的，後向計算過程由系統本身推導完成。autograd 經過導數的鏈式法則實現，逆拓撲序搭建反向計算圖。須要注意兩點：

（1）後向計算過程可能會依賴於前向計算產生的中間數據，因此前向計算的中間數據可能要一直保持到對應的後向計算完成才能釋放，不然就須要在後向計算時從新進行前向計算。

（2）若是前向計算過程有多個操做符消費了同一個數據，後向計算圖時就須要把這幾個操做符對應的梯度算子上傳過來的偏差信號進行累加。上面的示意圖來自陳天奇在華盛頓大學一門《Deep learning systems》課程的課件，感興趣的讀者能夠去課程網站獲取更多資料。

給定用戶輸入的 DAG （稱之爲邏輯圖，logical graph）, 系統通常會利用編譯器技術對圖進行優化重寫，上圖羅列的一些優化技巧就不一一展開解釋了。通過優化最終送到執行引擎執行的圖叫物理圖（physical graph），物理圖可能和輸入的邏輯圖已經大相徑庭了。在 TensorFlow, PyTorch, MXNet, Caffe2 中均可以看到這些常見的優化辦法。

執行引擎是深度學習引擎的核心，基本原理是按拓撲序去執行算子 / 操做符，以上圖爲例，剛開始，乘法和減法運算沒法執行，由於它們依賴的一個數據 a 尚未生成，引擎首先執行輸入數據已經就緒的操做符，即加法，當加法完成後，執行引擎會從 DAG 中刪掉已經執行的節點，而後發現乘法和減法的執行條件已經知足了，再去執行乘法和減法。事實上，當前全部大數據處理引擎的內核都是用這個原理實現的。在深度學習框架裏，須要注意調度器是在 CPU 上執行的，而操做符的真實運算是在 GPU 上完成的，爲了高效協調 CPU 和 GPU 之間的工做，在具體實現上有一些技巧。感興趣的讀者能夠觀摩 TensorFlow, MXNet, Caffe2 的執行引擎，也許你會發現有更好的實現辦法。

從執行效率考慮，深度學習框架底層通常基於 C++ 開發，從易用性角度出發，也同時提供 Python 前端便於數據科學家使用。上圖來自李飛飛教授在斯坦福的 cs231n 課程課件，展現了 Numpy，TensorFlow 和 PyTorch 對同一個簡單神經網絡訓練過程的實現。

最左側是 Numpy 代碼，它的第一個特點是 imperative programming，是即時求值（eager evaluation），運行完 b = a + z 這條語句，b 的結果就出來了；第二個特點是沒有 autograd，因此用戶不只要寫前向計算的代碼，還要把後向梯度降低的代碼寫出來，而 TensorFlow 和 PyTorch 都支持了 autograd，在代碼中只須要寫前向計算的過程，然後向計算過程是系統自動構建的。

TensorFlow 和 PyTorch 的區別則是，前者是 lazy evaluation，後者是 eager evaluation。在 TensorFlow 中，a = x + y; b = a + z 只是一些表達式，構建了一個數據流圖，在執行 sess.run 時刻纔會被真正執行，並且執行順序不必定和表達式聲明順序一致。在 PyTorch 中，和 Numpy 原理相似，每條語句都是馬上執行，並且按照語句的排列順序執行。看上去，PyTorch 的代碼的確更加簡潔，後文會進一步討論延遲求值和即時求值的問題。

深度學習框架不僅要解決易用性和高效性，還要方便部署運維。當前主流的深度學習框架都是基於檢查點機制實現容錯，Fail fast and warm start。深度學習框架還須要和上下游的開源工具鏈有機銜接，譬如分佈式數據存儲和數據預處理依靠 Hadoop 或者 Spark。部署運維，如今比較推崇基於 Docker 和 Kubernetes 相結合的方案。用戶有時須要在多個框架之間切換，隨着 ONNX 標準的推出，也大大便利了各類框架間的遷移，譬如使用 PyTorch 描述或訓練的模型能夠按 ONNX 規範導出，並被 Caffe2 框架使用。除了解決訓練問題，深度學習框架還便於上線部署，爲此 TensorFlow 推出了單獨的 serving 模塊。

深度學習框架當前技術焦點

下面咱們探討一些當前框架開發者還猶豫不定或束手無策的技術問題。

Define-and-run 和 Define-by-run 近期關注度比較高，PyTorch 靠 Define-by-run 這個特性吸引了不少開發者。這個技術問題還有其它等價的描述，譬如 define-and-run，基本上和 lazy evaluation, 或 declarative programming, data flow 是一回事，一般意味着效率高。define-by-run 則基本上和 eager evaluation， imperative programming 或 control flow 是一回事，一般意味着靈活性。最近，不少框架在積極的推動支持 define-by-run 的運行模式，譬如 TensorFlow 增長了 eager evaluation，MXNet 推出了 gluon 接口，PaddlePaddle Fluid 也是一種 imperative programming 的用法。那這兩種技術選擇究竟是怎麼回事呢？ 咱們認爲：

（1）Imperative programming 只不過是大部分程序員更加熟悉的編程方式，實現一個 imperative programming 的深度學習框架要比實現一個 declarative programming 的框架簡單（最簡只須實現 autograd，複雜點要支持 JIT）。傳統的 lazy evaluation 框架增長 imperative programming 接口能夠作到和 PyTorch 徹底同樣的用戶體驗，只不過要費些周章。

（2）只要 declarative programming 解決了調試困難等問題，就是對用戶更友好的一種編程模式，用戶只要在寫程序時描述 what，而不須要關心 how，底層細節對用戶透明，這是現代變編程語言的發展趨勢。

（3）並行和並發表明着將來的趨勢，那麼數據流（聲明式編程，函數式編程）表明着將來，data flow 模型在任務描述和系統執行引擎的簡潔性上都有自然優點。

並行計算能夠擴大處理任務的規模，也能夠加速計算。具體到深度學習框架，整體狀況是：數據並行已經獲得解決，不管是哪一個框架都能把適合數據並行的任務作到接近理想加速比，譬如計算機視覺領域各類 CNN 模型；數據並行和流水線並行不支持或支持的很差，致使在某些分佈式訓練場景，硬件利用率太低，訓練週期過長。在集合通訊（Collective communication operation）上有基於參數服務器的，MXNet、PaddlePaddle、TensorFlow、也有基於 MPI（或類 MPI）的，譬如 Caffe2。TensorFlow 在宏觀架構上還區分了 Client、Master、Worker 節點，在重構版的 PaddlePaddle 也使用了相似的架構。

數據並行的原理解釋，能夠參見本公衆號《深度學習平臺技術演進》一文，現有框架都能良好支持數據並行。本來限制數據並行的一個問題是隨機梯度降低算法依賴的 mini-batch 不能太大，太大的 mini-batch 算法不收斂，這就致使即便有大量的並行設備，也發揮不出來威力。近期有一系列成果攻克了這個問題，譬如 Facebook 推出的一個小時訓練 ImageNet，以及尤洋作的一系列工做，能夠把 mini-batch 推廣到 32K, 保證算法仍然收斂，這就能充分發揮數據並行的優點。

模型並行的原理請參見本公衆號《深度學習平臺技術演進》一文。模型並行自己實現複雜度不是特別高，主要困難在於有的場景適合數據並行，有的場景適合數據並行，有的場景同時須要模型並行和數據並行，這就須要根據實際狀況正確的對數據從新組織（分裂，合併）和路由（把數據正確的發送到目的地，scatter 或 broadcast）。再有就是，當數據路由比較複雜時，就很難高效的支持，就須要流水線並行的支持。

當神經網絡模型或中間隱狀態體積很大時，譬如超過一張顯卡顯存的容量，除了使用模型並行，還可使用流水線並行。流水線並行有點像接力比賽，上圖展現了一個簡單的例子，第一個 GPU 作完第一層的計算後，把結果傳遞給第二塊 GPU，第二塊 GPU 完成中間四層的計算以後，把結果傳遞給第三塊 GPU 完成計算。一般訓練深度學習模型時，存在多個階段，譬如把數據從磁盤加載到主存，把數據從主存搬運到 GPU, GPU 完成一個階段的計算以後，可能還須要把數據經過網絡傳送到另外一臺機器。在這樣多階段任務中，流水線並行對於系統性能相當重要。能夠注意到，大部分框架在 IO 階段會作流水線並行，而在多個計算階段，或者計算與通訊階段之間都沒有相應支持。基於現有框架去支持模型並行，流水線並行還很是困難。

主流深度學習框架點評

下面分享一些咱們對各類框架的理解和判斷，若是觀點有誤差，敬請理解，歡迎批評指正。

以上框架用戶比較多，開發團隊技術實力雄厚。深度學習框架的先驅 Theano 已中止更新，它的 autograd 機制已經被這些現代框架所吸取；咱們沒有研究微軟開發的 CNTK；Intel 收購的 Nervana 在開發一個新的框架 NGraph，也值得關注，不過它目前主要聚焦在單設備優化；DMLC 的 NVVM 和 TVM 放在 MXNet 內；有一個來自日本研究人員的框架 Chainer 也比較有特點，Python 前端很是清爽。

TensorFlow

TensorFlow 是系統完整度最高的，支持 training 和 inference （serving），支持圖像經常使用的 CNN，也支持天然語言和語音經常使用的 RNN/LSTM， 還有移動端的 TensorFlow Lite，支持 lazy execution 也支持 eager execution，社區生態最強大，Google 在深度學習算法和應用方向的研究也是冠絕天下（參見 Jeff Dean 寫的 Google Brain 2017 年度回顧：zhuanlan.zhihu.com/p/32905123 ）深度學習領域不少新的研究成果都是以 TensorFlow 代碼發佈的。

但 TensorFlow 的性能也是廣受詬病，咱們不大清楚 TensorFlow 在 Google 內部是否是性能卓越，在外部用戶那裏常常能聽到用戶抱怨 TF 慢，在學界和工業界不少 Benchmark 裏，你們也喜歡拿 TensorFlow 作 baseline，譬如 CMU Eric Xing 教授團隊發表的 Poseidon 論文，基於 TF 作了一系列優化以後，性能提升很是顯著；Uber 團隊改造了 TensorFlow 的分佈式實現後（把 PS 換成 MPI)，CNN 數據並行場景還能提升一倍的性能 （見 Uber Horovod github.com/uber/horovo…) 。

從框架開發者的角度看，咱們覺得 TensorFlow 要解決性能問題，須有壯士斷腕的決心，推翻一系列原有設計和實現。最後，TensorFlow 畢竟是功能最完整的框架，若是要訓練大規模 RNN/LSTM，目前只能選擇它，儘管要忍受一下很長的訓練週期。

PyTorch

Facebook AI Lab 出品的 PyTorch 是深度學習框架的一匹黑馬，靠 Eager evaluation 博得了大批深度學習研究人員的青睞。基於 Imperative programming 的理念和基於 Python 的語言構造（控制流）來搭建神經網絡，靈活性高。NLP 領域常有一些動態圖的需求，PyTorch 是首選。

咱們認爲在單機場景下，易用性和靈活性是最重要的用戶需求，其它框架爲了知足這樣的需求，必須在本來爲分佈式設計的技術架構上作一些妥協，難以和 PyTorch 的最簡內核競爭。PyTorch 爲了克服 Eager evaluation 的一些問題，也在經過 JIT 來享受一些 Lazy evaluation 的優勢，同時也在向分佈式場景進軍。如前文所述，在大規模分佈式應用場景下，用戶程序只能是 Lazy evaluation 風格，數據流的執行引擎在高併發高並行的場景有自然的優點，PyTorch 如今的設計實現距離這個目標還比較遙遠。

MXNet

MXNet 開發團隊實力雄厚，如今是 Apache 孵化項目，有 Amazon 官方支持加持。MXNet 的特色是包含不少正對 Geek 品味的實現技巧， 很值得喜歡鑽研前沿技術的人去觀摩。但很差的地方是，給人一種比較「雜」的感受，讓開發者感到困惑，譬如矩陣庫有兩套實現 Mshadow 和 NDArray。MXNet 在計算機視覺領域老是能緊跟前沿應用，一些新的模型出來社區老是第一時間支持。MXNet 有一些關聯項目，譬如 NNVM 和 TVM，目前來看 TVM 更獨特，NNVM 裏實現的一些圖優化技術在其它框架裏也是有對應實現的，而 TVM 和 TensorFlow XLA 應該是處於一個層次：聚焦於單設備程序性能優化。基於 TVM、Halide、TensorFlow XLA ，用戶能夠在單設備上使用聲明式編程，編譯器自動生成高效的後端代碼。

Caffe2

Caffe 的用戶還很是多，第二代 Caffe2 和第一代已經迥然不一樣了，但繼承了一些簡潔的品質在裏面。框架的抽象很是簡潔，不厚重，Op/Kernel 和引擎主要在 C++ 層實現，而複雜的圖拓撲結構在 Python 層面處理。Caffe2 借鑑了 TensorFlow 對 Op/Kernel 的抽象，沒有再使用以前 Layer 那種把數據和操做放在一塊兒的設計。一樣是 Op/Kernel 抽象，Caffe2 也不是簡單的模仿， 代碼看上去更加舒服。Caffe2 目前支持數據並行，曾創造了一個小時訓練 ImageNet 的記錄，對 Caffe 有感情的用戶能夠嘗試。據瞭解，Caffe2 在 Facebook 內部承擔了「工業級應用」和「部署」的重任，也開發了很好的移動端支持，這應該是 Caffe2 的特點。Caffe2 還有一個頗有特點的技術，gloo 網絡庫是定製的 MPI 實現，有「去中心化」集羣通訊的味道，也便於支持流水線。

PaddlePaddle

PaddlePaddle 最大的優點是百度內部在普遍使用，經受了實戰檢驗。第一代 PaddlePaddle 是比較接近 Caffe，分佈式並行也依賴於 Parameter server。最近一年，Paddle 團隊在開展很是激進的重構。以咱們的理解，重構版 PaddlePaddle 借鑑了不少 TensorFlow 的設計，因此 Paddle 可否解決 TensorFlow 面臨的問題呢？ 重構後的 PaddlePaddle 主推命令式編程接口，正像咱們評價 PyTorch 時所說的，命令式編程接口當然親民，但數據流表示在大規模分佈式運行場景有自然的優點（表示能力和引擎實現複雜度方面），要很好的支持大規模分佈式場景，深度學習框架最終要把「控制流」代碼翻譯成「數據流」代碼在後臺運行。

整體來看，深度學習框架開發的絕大部分技術祕密已經公開了，開發一個簡單的深度學習框架沒有那麼難。但從另外一方面看，要開發一個易用性和高效性都很卓越的框架是很是困難的，即便是世界上最優秀的開發團隊也感到困難重重，克服這些問題須要堅苦卓絕的創新和堅持。

展 望

展望將來一年

（1） 咱們認爲在計算機視覺領域也將迎來模型更大的場景，譬如把 Hinton 的 Capsule net 從 Cifar 推向 ImageNet 規模，模型大小就遠超當前各類常見的 CNN, 這種狀況必須把模型分裂到多個設備上去完成，也就是所謂的模型並行。並且學界很關心神經網絡結構學習，元學習，也有必要去探索 CNN 以外的架構，在人腦視皮層儘管存在 CNN 這種神經元分層組織和局部感覺野的神經元，但並無所謂 weight sharing（神經元功能柱有相似的特異選擇性，但不是嚴格同樣），這種神經元之間的鏈接規模很是龐大，若是去掉這個約束會發生什麼？若是深度學習框架不能支持模型並行，那麼這種設想就只能在 Cifar, MNIST 這種數據集合上去探索，並不能在 ImageNet 甚至更大規模的數據上去探索，而有些規律是在大規模數據上纔會「涌現」出來。

（2）將來，通用的深度學習框架會支持模型並行，並且用戶使用模型並行易如探囊取物。

（3）深度學習向更多場景滲透，天然而然。

（4）一旦一項技術被驗證，各類深度學習框架都會去擁抱它，支持它，正現在天不少框架在提供 imperative programming 接口同樣，同質化是比較嚴重的，將來須要一些新的空氣，新的思路去解決那些懸而未決的問題。

（5）在大數據和人工智能時代，數據積累到了臨界點，工業界除了有數據存儲，數據篩選這些需求，將廣泛須要一個大腦（Brain），做爲數據驅動業務的引擎，深度學習框架會像 Hadoop 同樣經歷一個從「舊時王謝堂前燕，飛入尋常百姓家」的過程。

更多幹貨內容，可關注AI前線，ID：ai-front，後臺回覆「AI」、「TF」、「大數據」可得到《AI前線》系列PDF迷你書和技能圖譜。