本文轉載自微信公眾號：半輕人
作者：王詠剛
作者：王詠剛
王詠剛 AI科技大本營
AI 時代，我們總說做科研的 AI 科學家、研究員、演算法工程師離產業應用太遠，這其中的一個含義是說，搞機器學習演算法的人，有時候會因為缺乏架構（Infrastructure）方面的知識、能力而難以將一個好的演算法落地。我們招的演算法工程師裡，也有同學說，我發的頂會 paper 一級棒，或者我做 Kaggle 競賽一級棒，拿了不少第一名的，不懂架構就不懂唄，我做出一流演算法，自然有其他工程師幫我上線、執行、維護的。鑑於此，我給創新工場暑期深度學習訓練營 DeeCamp （ps：這個訓練營太火了，只招生 36 名，總共有 1000 多計算機專業同學報名，同學們來自 CMU、北大、清華、交大等最好的大學）設計培訓課程時，就刻意把第一節課安排為《AI 基礎架構：從大資料到深度學習》，後續才給大家講《TensorFlow 實戰》、《自然語言處理》、《機器視覺》、《無人駕駛實戰》等框架和演算法方向的課。
為什麼我要說，AI 工程師都要懂一點架構呢？大概有四個原因吧：
原因一：演算法實現 ≠ 問題解決
學生、研究員、科學家關心的大多是學術和實驗性問題，但進入產業界，工程師關心的就是具體的業務問題。簡單來說，AI 工程師扮演的角色是一個問題的解決者，你的最重要任務是在實際環境中、有資源限制的條件下，用最有效的方法解決問題。只給出結果特別好的演算法，是遠遠不夠的。
比如一些演算法做得特別好，得過 ACM 獎項或者 Kaggle 前幾名的學生到了產業界，會驚奇地發現，原來自己的動手能力還差得這麼遠。做深度學習的，不會裝顯示卡驅動，不會修復 CUDA 安裝錯誤；搞機器視覺的，沒能力對網上爬來的大規模訓練圖片、視訊做預處理或者格式轉換；精通自然語言處理的，不知道該怎麼把自己的語言模型整合在手機聊天 APP 裡供大家試用……
當然可以說，做演算法的專注做演算法，其他做架構、應用的幫演算法工程師做封裝、釋出和維護工作。但這裡的問題不僅僅是分工這麼簡單，如果演算法工程師完全不懂架構，其實，他根本上就很難在一個團隊裡協同工作，很難理解架構、應用層面對自己的演算法所提出的需求。
原因二：問題解決 ≠ 現場問題解決
有的演算法工程師疏於考慮自己的演算法在實際環境中的部署和維護問題，這個是很讓人頭疼的一件事。面向 C 端使用者的解決方案，部署的時候要考慮 serving 系統的架構，考慮自己演算法所佔用的資源、執行的效率、如何升級等實際問題；面向 B 端使用者的解決方案要考慮的因素就更多，因為客戶的現場環境，哪怕是客戶的私有云環境，都會對你的解決方案有具體的介面、格式、作業系統、依賴關係等需求。
有人用 Python 3 做了演算法，沒法在客戶的 Python 2 的環境中做測試；有人的演算法只支援特定格式的資料輸入，到了客戶現場，還得手忙腳亂地寫資料格式轉換器、介面卡；有人做了支援實時更新、自動迭代的機器學習模型，放到客戶現場，卻發現實時接收 feature 的介面與邏輯，跟客戶內部的大資料流程根本不相容……
部署和維護工程師會負責這些麻煩事，但演算法工程師如果完全不懂得或不考慮這些邏輯，那隻會讓團隊內部合作越來越累。
原因三：工程師需要最快、最好、最有可擴充套件性地解決問題
AI 工程師的首要目的是解決問題，而不是顯擺演算法有多先進。很多情況下，AI 工程師起碼要了解一個演算法跑在實際環境中的時候，有哪些可能影響演算法效率、可用性、可擴充套件性的因素。
比如做機器視覺的都應該瞭解，一個包含大量小圖片（比如每個圖片 4KB，一共 1000 萬張圖片）的資料集，用傳統檔案形式放在硬碟上是個怎樣的麻煩事，有哪些更高效的可替代儲存方案。做深度學習的有時候也必須瞭解 CPU 和 GPU 的連線關係，CPU/GPU 快取和記憶體的排程方式，等等，否則多半會在系統效能上碰釘子。
擴充套件性是另一個大問題，用 AI 演算法解決一個具體問題是一回事，用 AI 演算法實現一個可擴充套件的解決方案是另一回事。要解決未來可能出現的一大類相似問題，或者把問題的邊界擴充套件到更大的資料量、更多的應用領域，這就要求 AI 工程師具備最基本的架構知識，在設計演算法時，照顧到架構方面的需求了。
原因四：架構知識，是工程師進行高效團隊協作的共同語言
AI 工程師的確可以在工作時專注於演算法，但不能不懂點兒架構，否則，你跟其他工程師該如何協同工作呢？
別人在 Hadoop 裡搭好了 MapReduce 流程，你在其中用 AI 演算法解決了一個具體步驟的資料處理問題（比如做了一次 entity 抽取），這時其他工程師裡讓你在演算法內部輸出一個他們需要監控的 counter——不懂 MapReduce 的話，你總得先去翻查、理解什麼是 counter 吧。這個例子是芝麻大點兒的小事，但小麻煩是會日積月累，慢慢成為團隊協作的障礙的。往大一點兒說，系統內部到底該用 protocol buffers 還是該用 JSON 來交換資料，到底該用 RPC 還是該用 message queue 來通訊，這些決定，AI 工程師真的都逆來順受、不發表意見了？
Google 的逆天架構能力是 Google AI 科技強大的重要原因
這個不用多解釋，大家都知道。幾個現成的例子：
（1）在前 AI 時代，做出 MapReduce 等大神級架構的 Jeff Dean（其實嚴格說，應該是以 Jeff Dean 為代表的 Google 基礎架構團隊），也是現在 AI 時代裡的大神級架構 TensorFlow 的開發者。
（2）在 Google 做無人駕駛這類前沿 AI 研發，工程師的幸福感要比其他廠的工程師高至少一個數量級。比如做無人駕駛的團隊，輕易就可以用已有的大資料架構，管理超海量的 raw data，也可以很簡單的在現有架構上用幾千臺、上萬臺機器快速完成一個程式碼更新在所有已收集的路況資料上的迴歸測試。離開這些基礎架構的支援，Google 這幾年向 AI 的全面轉型哪會有這麼快。
課件分享：AI 基礎架構——從大資料到深度學習
下面是我給創新工場暑期深度學習訓練營 DeeCamp 講的時長兩小時的內部培訓課程《AI 基礎架構：從大資料到深度學習》的全部課件。全部講解內容過於細緻、冗長，這裡就不分享了。對每頁課件，我在下面只做一個簡單的文字概括。
注：以下這個課件的講解思路主要是用 Google 的架構發展經驗，對大資料到機器學習再到近年來的深度學習相關的典型系統架構，做一個原理和發展方向上的梳理。因為時間關係，這個課件和講解比較偏重 offline 的大資料和機器學習流程，對 online serving 的架構討論較少——這當然不代表 online serving 不重要，只是必須有所取捨而已。
這個 slides 是最近三四年的時間裡，逐漸更新、逐漸補充形成的。最早是英文講的，所以後續補充的內容就都是英文的（英文水平有限，錯漏難免）。
如何認識 AI 基礎架構的問題，直到現在，還是一個見仁見智的領域。這裡提的，主要是個人的理解和經驗，不代表任何學術流派或主流觀點。
上面這個圖，不是說所有 AI 系統/應用都有這樣的 full stack，而是說，當我們考慮 AI 基礎架構的時候，我們應該考慮哪些因素。而且，更重要的一點，上面這個架構圖，是把大資料架構，和機器學習架構結合在一起來討論的。
架構圖的上層，比較強調雲服務的架構，這個主要是因為，目前的 AI 應用有很大一部分是面向 B 端使用者的，這裡涉及到私有云的部署、企業雲的部署等雲端計算相關方案。
上面這個圖把機器學習和深度學習並列，這在概念上不太好，因為深度學習是機器學習的一部分，但從實踐上講，又只好這樣，因為深度學習已經枝繁葉茂，不得不單提出來介紹了。
