前言：現在很多網際網路公司都有自己的機器學習平臺，冠以之名雖然形形色色，但就平臺所要解決的問題和技術選型基本還是大同小異。所謂大同是指大家所要處理的問題都相似，技術架構和選型也差不太多，比如都會使用 GPU 叢集、採用 Spark 或 K8s 平臺等。所謂小異是指各家規模不同，各家都在結合自己的情況、所處的階段並根據自己的特點解決平臺化的問題。滴滴機器學習平臺的治理思路主要是：減少重複、提高效率。本文將對滴滴的機器學習平臺進行全面解讀，重點分享機器學習平臺不同階段所要解決的問題，以及解決問題的思路和技術方案。希望能夠對大家有所幫助。
▍機器學習平臺1.0：從“作坊”向“集中化”過渡
滴滴的機器學習平臺建設開始於2016年，當時滴滴內部各演算法團隊逐步開展機器學習、深度學習等 AI 相關的研究和實踐應用，這類演算法大都屬於計算密集型應用，一般都會使用單價較昂貴的 GPU 伺服器。但隨著業務的開展，各演算法團隊僅針對各自的問題做規劃，導致了一種小作坊式的生產局面。
作坊式生產方式在早期有其積極的一面，能夠保證創新的靈活性，但是越往後，這種小作坊式演算法生產模式的侷限就越明顯：資源缺乏統籌排程，無法形成規模化效應，大量重複性工作，自擁算力有限。逐漸增多的這種小作坊式生產方式致使整體投入產出的效益大打折扣。
滴滴機器學習平臺在這種背景下應運而生，這個階段也主要致力於解決這些問題。這期間機器學習平臺所採用的架構和技術選型主要針對作坊式生產方式的問題來展開，也就是提高複用性和規模化能力。
首先要解決的問題就是統一資源管理，這個“統一”要解決包括線下和線上兩類問題。
線下“統一”的問題著重解決 GPU 的伺服器選型、測試、引入、上線等的集中化。這類集中化一方面提高了伺服器引入的上線質量；另一方面相比於作坊式模式，由於有 GPU 相關專業人員參與進來，GPU 的選型避免了一味追新的盲目性和發散性。
再者，集中化能夠和公司整體大局結合起來，從而可以做最優化的選型和引入方案。
線上“統一”需要解決的問題細分為資源管理問題和任務排程問題，使資源使用方能夠用即申請，完即釋放，從而盤活整個資源大池，對平臺要求則需要做到資源的隔離和管理。
這個階段需要解決資源統一管理後如何避免重複性工作的問題。此時所謂的避免重複性，意在讓各個演算法業務不需重複諸如 Caffe、TensorFlow、PyTorch 等執行環境的構建，而是要一次構建所有使用者都可用。這對平臺來講，需要做到應用環境管理、使用者自定義環境、快速環境部署。
釐清這些需求之後，結合當時的技術環境和成熟度來看及以上的基本要求，平臺選擇當下盛行的 Docker 來兼做環境的管理、資源的弱隔離和任務的排程。
但由於此時支援 GPU 資源排程的資源管理器乏善可陳，所以我們選擇對 Yarn 做了擴充套件以支援 GPU 資源維度上的資源管理和任務排程，環境上平臺同時提供 Notebook、Jupyter 的互動介面給使用者。
統一資源管理、環境管理後，不得不面對的問題是多個資源節點間資料共享的問題，使用者在當前資源釋放後申請新資源時往往對之前的資料有依賴。
多節點資料共享在作坊式時期受限於單個的規模，問題不會十分突出，但是集中化之後隨使用者增多就會逐漸尖銳起來乃至是個大的技術挑戰。因為：
機器學習的任務計算特點依賴於 GPU 的高速計算，它們對資料訪問延遲有一定要求，這要求必須有足夠高的 IO 頻寬做支援；
使用者數量增加，對儲存頻寬的需求會變的非常大；
對儲存系統來說，支援 POSIX 介面的要求使得現有技術方案大大減小，另外也需在高可靠性、高效能以及成本之間做折中。
滴滴機器學習平臺在儲存系統上的嘗試還是借用傳統超算使用的 PFS 作為整個資料儲存的一級，底層網路基礎設施使用高頻寬的乙太網路，使用 RoCE 協議做 RDMA 的支援，並往這個方向演進。
機器學習平臺架構-Yarn
總的來看，這個階段所面對的問題以內部問題為主，從作坊式到集中化生產的發展階段，要解決的相關重複性的問題也比較簡單。其中有些問題本質屬於集中化後產生的問題，但是解決思路還是作坊式的，技術選型上的侷限性也沒有完全暴露出來。
▍機器學習平臺2.0：平臺發展
隨著作坊逐漸消失，機器學習平臺作為一種集中化的生產方式呈現給公司所有演算法團隊。平臺功能開始完整和完善，監控體系，運維體系，更加精細化的資源隔離、管理及優化；根據使用者不同的任務性質也提供了不同性質的任務支援。
經歷了前一個階段後，雖然有效降低了作坊生產的重複性工作，但也幾乎必然的產生了一些新形態的重複工作。使用者接入的增多，使用者任務的性質也多樣化，有些是實驗性質的、有些是線上生產任務、有些是單卡任務、有些是多卡多機的訓練任務等等。
每種性質的任務都有各自重複的具體形式，比如使用者在模型生產後要部署模型服務就需要解決服務的 HA、負載均衡等生產服務問題，每一個線上模型都要解決這類問題。
再比如，使用者訓練時往往需要調參，而這些引數都是同形的，只是數值上的變化，這種值上的變化後就是一個個獨立任務，需要使用者提交任務的流程，這也是重複性的工作。
再比如，使用者在執行多機多卡時需要引數伺服器，低效的引數伺服器把大量的時間浪費在通訊上，這種浪費會加重使用者資源使用上的重複；與這種重複形式相似的，還有模型服務要上線，為了滿足服務的延遲、QPS、資源的約束，需要做從服務、到深度學習框架、再到計算庫的全棧優化，基本上，大部分模型上線也需要經歷這個優化過程。
針對上述新出現的問題，平臺需要更加強大的資源管理和任務排程能力。
在上一時期選用作為資源管理和任務排程器的 Yarn 開始呈現出疲態，具體表現在 K8S 日臻成熟，與 Docker 的結合更加合理和完整，並能夠整合多種維度的資源，使用 K8S 為解決模型服務的自動化部署提供了環境和條件，也降低了服務的運維成本。
綜合 K8S 和 Yarn 各自的利弊，滴滴機器學習平臺開始由 Yarn 架構向 K8S 建構遷移。
機器學習平臺架構-K8S
針對使用者同形調參的效率問題，平臺對使用者的 Python 程式碼做語義分析以自動識別出哪些引數可能會是需要調整的引數，使用者只需要設定值域和步距就可以自動獲取整套引數的模型訓練任務以及最終的結果。
針對多機多卡訓練效率問題，平臺結合自己的硬體特點和通訊模式特點，開發了滴滴引數伺服器。滴滴引數伺服器採取環狀結構，實現了高效的 RDMA 通訊的 Allreduce 演算法。
環狀結構而非中心集中的 server-client 模式，消除了網路傳輸可能的頻寬競爭和網路擁塞。底層自研的高效 RDMA 通訊庫，規避了裝置廠家提供使用者態 Verbs 內部分效能損失，重寫的底層通訊庫實現了 sig/read 及 post/recv 兩種模式，儘量規避了 RDMA 固有的通訊開銷，充分挖掘了硬體的屬性來提高效能。
另外，自研的 Allreduce 演算法巧妙重疊了計算和傳輸，儘量減少了不必要的記憶體拷貝來減少額外代價，並充分考慮了 GPU 拓撲、CPU 親和性等硬體屬性來提高效能。
在機房 40G 頻寬的 RoCE v2 RDMA 網路實際測試中，對比業界的 OpenMPI 和 Nvidia 的 NCCL2 方案，滴滴引數伺服器有明顯優勢。
針對模型服務部署和優化，平臺結合自己的場景特點開發了 DDL（DiDi Deep Learning） Serving 服務框架、IFX 框架和 Autotuning 優化庫，極大加速了模型上線部署和優化過程。
針對模型服務部署和優化，平臺結合自己的場景特點開發了 DDL（DiDi Deep Learning） Serving 服務框架、IFX 框架和 Autotuning 優化庫，極大加速了模型上線部署和優化過程。
DDL Serving 獨創自適應的 batch 機制，優化 RPC 協議，解決 Tensorflow Serving 的缺陷，相比於 Tensorflow Serving 效能對比加速如下：
DDL Serving 框架服務本身不再成為整個服務鏈路中的瓶頸點，對於一些輕量模型可以有 3 倍的效能提升，包括 RT 和 QPS 的提升, 而對於一般模型，效能熱點落在深度學習框架層。
因此，針對框架層，我們自主研發了深度學習框架 IFX，並同時適配於 GPU 伺服器和移動端平臺。在 GPU 伺服器上，由於 CUDA 存在 context 管理的問題，所以我們設計實現了一種 GPU 上的併發機制，有效地繞開了這些問題所帶來的額外開銷，另外對大量的 OP 做了優化，使得 IFX 的效能遠高於 Tensoflow 乃至 TensorRT。
IFX 針對移動端的不同硬體配置，比如：流水線長度、順序亂序、超標量等特點進行指令重排、訪存優化，結合業務的計算特點，使得 IFX 的效能取得不俗的表現：
在 IFX 的優化過程中，大量的重複工作基本在 Tuning Blas 計算，由於硬體架構不同，不同模型的計算量、計算訪存比、計算訪存模式都不同，在極高效能要求下都需要綜合這些具體的情況做針對性的優化。這些優化都很底層，並且調優都相對繁瑣，對於上層服務使用者來講，不必關心這些底層細節。
為解決這類問題，平臺開發了 Autotuning 工具鏈，包括 Kepler、Pascal、Volta 架構的原生彙編器。
對於使用者來講，只需要把 GPU 上的二進位制程式碼發給平臺，平臺就可產生在該 GPU 平臺上幾乎是最優，也就是當前最高效能優化後的二進位制程式碼。
滴滴機器學習平臺團隊也是目前除了 NV 以外，自己掌握 NV GPU 原生彙編器支援版本最多，對 NV GPU 微架構最瞭解的。
這些“重複問題”隨著集中化和平臺化產生，也在平臺化的環境下使得解決這些“重複”變得有意義。
集中化、平臺化帶來的第二個好處便是在此基礎上，通用性的需求逐漸會沉澱為平臺的服務。
比如，相似檢索的需求在滴滴地圖的 POI 優化、人臉檢索、視訊影像內容檢索等業務場景中都是共性需求，因此平臺會獲得足夠的業務資訊來開發這種平臺級的服務，而在作坊式時代很難獲得這類跨業務場景的需求而自發的沉澱出平臺服務，大多還是自掃門前雪。
▍機器學習平臺2.1：內外雲平臺成形
集中化生產後的第二個影響，隨著平臺能力的增加以及孵化落地演算法逐步豐富，加上滴滴內部資料、AI 工程和演算法逐步積累成熟，機器學習平臺的功能、定位也變得多樣化。
除了服務好滴滴內部機器學習平臺使用者，進一步夯實資源排程、任務管理、監控運維等能力外，平臺開始承接內部能力對外輸出的職能，期間機器學習平臺和滴滴雲著手在公有云上打造從底層資源到上層平臺、從公有云到私有云的解決方案。
機器學習內部的集中化生產也給滴滴機器學習平臺能力的輸出做了儲備，但外部客戶的技術產品要求相對更復雜。
這種複雜首先體現在產品要求的多層次性：有對資源乃至對硬體的直接要求、有對具體服務的需求、也有例如在私有云中對平臺能力的需求；其次, 產品考量因素的多維性：資源的價效比往往只是一方面，安全性、穩定性、與其他基礎設施的整合能力等也都是影響使用者決策的因素；最後，橫向各友商競品的對比。
所有這些問題都是滴滴機器學習平臺對外服務碰到的問題，但是這些問題不可能做到“畢其功於一役”，都是分階段分步驟，有側重的解決此間的問題。
第一步要解決的是基礎問題，如何透出能力，如何保證客戶的安全性，如何在前兩個能力的基礎上，盡最大力減少外部使用者的重複性工作（使用者使用的成本）和滴滴機器學習平臺的重複性工作（產品價效比）。
▍GPU 資源：減少資源的重複性工作
相比於內部的使用者，外部使用者使用資源需要有一個安全的隔離環境，僅用 Docker 的弱隔離方式無法給使用者提供安全且隔離的環境。所以滴滴雲上 GPU 雲資源使用 KVM 和 GPU 透傳的方式把 GPU 資源透傳給使用者。
滴滴機器學習平臺技術團隊對 GPU 的使用頗有心得，團隊成員也是早期一批在工業界嘗試 GPU 的團隊，積累了豐富的 GPU 使用一線的知識和經驗，而且這些在滴滴內部被佐證十分有效，從 GPU 資源、拓撲和相關配套上都特別花心思，所以相同 GPU 型號，使用者往往可以獲得更好的效能，對比如下圖。這部分的沉澱也減少了外部使用者在探索使用 GPU 過程中的重複性工作，降低了使用的隱性成本。
▍彈性推理服務（EIS）：減少服務部署優化的重複
所有的演算法模型最終都需要用於生產服務，國外有很多 PAML 平臺能夠部署機器學習模型服務，機器學習平臺在滴滴雲上也提供了一種模型部署服務——EIS（彈性預測服務）。
EIS 服務根植於內部使用的 DDL Serving 服務，但因在雲上服務我們對一些理念的堅持，所以大家可能會產生我們有“起大早趕晚集”的疑問。
實際上，EIS 在滴滴內部以 DDL 的形式出現的相對不算晚，這一塊的服務市場現在只能說是剛剛起步，產品的差異化和多樣化會是必然的趨勢，對使用者來講也有更好更大的選擇空間。
目前，市面上大大小小提供 PA 服務的廠商大都有各自的特點，但總的來說他們對這個產品的定位依然僅僅是作為資源產品的輔助角色，著重為使用者解決資源和部署問題。這種輔助角色，有他的好處，主要包括：
模式簡單，把服務轉化為最小粒度資源開銷，按最小單位資源消耗來計費；
對基礎設施的能力要求降低，簡化為資源開銷，本質上只是多了一種資源的售賣形式；
服務廠商的工作最小化，雖然使用者可以選擇多種資源，並且每種資源的都有各自理論上的計算能力，使用者怎麼利用好這些資源是使用者自己的事情。
這個模式的問題在於服務商雖然為客戶解決了一部分問題，但是對使用者實際的服務部署考慮仍然不周。為什麼？
原因在 DDL 描述中也提到過，模型服務部署服務都需要使用者自己優化服務以滿足 RT、QPS 的要求，更進一步說，成本如何最優化，使用者使用雲服務，成本幾乎是必然會面對和慎重考慮的。
所以從這個點來看，PA 服務提供商以資源為主，服務為輔的模式的缺點也顯而易見：
最小粒度資源的粒度對模型服務來說，粒度依舊比較粗，如若使用到 GPU，問題更加突出；
資源的理論計算能力對使用者來講往往僅是個理論數字，受限於硬體的限制和客戶自己的技術能力，客戶往往並不能充分利用 PA 廠商提供的資源的計算能力，而一般利用率都有限，這實際使用和標稱的理論數字之間的資源費用實際是由使用者買單的，而更甚者，對使用者來講這裡有兩部分工作是重複的：資源的使用優化的重複，服務部署的運維相關工作的重複。
根據我們內部使用者和一些外部使用者的經驗，服務最核心的技術指標是 QPS 和 RT，進而才是滿足這兩個指標情況下的部署成本和使用成本。而這些成本的降低則必須在儘可能減少使用者的重複工作和“實用實銷”的基礎上，除了一般服務部署需要的 HA 和運維支援外，EIS 從技術架構設計上側重於解決這兩方面問題。
從 RT 來講：使用者服務 RT 的開銷受限於網路鏈路和實際前向計算的開銷，為了減少網路鏈路的開銷，滴滴雲花了不少時間，在公有云上實現了純公有云化的 Gateway，一方面用於支援使用者自定義的鑑權等操作，另一方面也最小化網路跳數以降低網路的開銷，保證使用者服務的 RT。
從 QPS 來講，EIS 使用滴滴機器學習平臺的 DDL Serving 作為服務引擎框架，使用 DDL Serving 的使用者可以忽略底層硬體的細節，從而可以避免使用者重複地去做服務框架層面的已知的優化工作，這樣也為實現使用者“實用實銷”提供了條件。可以通過以下的架構圖瞭解：
要做到“實用實銷”，還有一個非常關鍵的環節就是需要知道使用者的模型實際的計算需求量，以及某一種硬體下的計算利用率。
我們開發了一個自動壓測模組，使用者提供模型和部署輸入就可以獲得使用 DDL Serving 在某種硬體下的計算效能，進一步迴歸出某種 RT 效能要求下的 QPS 能力。
對使用者來講，使用者折算出業務需總的 QPS 後按 QPS 橫向擴容即可，相當於使用者只負擔了實際消耗的計算效能的那部分資源，這比之前的模式是更加細粒度的資源控制。
使用者優化上的重複性工作的減少，如之前講過的除了服務框架的優化外，還有一部分優化是花在計算效能的優化上，但計算效能的優化往往取決於程式的計算特性和相關的硬體特性，並且每種模型都有各自的特點。
這部分工作 EIS 也提供了 Autotuning 的優化服務，使用者需要提供他的二進位制程式碼，通過 Autotuning 服務後會產生某種模型和框架下在指定硬體下幾乎是最優的效能程式碼。
Autotuning 服務除了能降低重複基礎的和瑣碎的優化工作外，也能夠提升使用者模型服務 RT 和每 QPS 實際資源消耗資源。
目前 EIS 已經接入滴滴內部大量的業務，其整個功能模組圖如下。因為一些限制，對外部客戶，當前滴滴雲 EIS 服務還是通過提交工單接入的方法，使用者自助的方式馬上會上線。
▍簡樞：降低使用者重複平臺建設
同 EIS 一樣，機器學習平臺級產品在內部積累了豐富的一線的平臺經驗，基於此，機器學習平臺在滴滴雲上開發了平臺級產品簡樞。
簡樞包裝了多種平臺能力，弱隔離方案的資源管理、多種任務管理、監控報警、線上服務快速部署等，能夠幫助其他公司在平臺化過程中少踩坑，快速具備平臺能力，提高生產效益。
▍未來展望
對於機器學習來講，計算力仍然是最具革命性的力量，正如 2011 年開始的這波深度學習浪潮的助力正是 GPU 一樣，未來計算力還是工程層面的制約力。
如 Jeff Dean 所言“事實證明，我們真正需要的是超過現在 100 萬倍的計算能力，而不僅僅是幾十倍的增長。”因此，對平臺來講，如何更好的管理不斷爆發式增加的計算力、如何有效的釋放出這些計算力，如何駕馭好這些計算力仍然需要平臺不斷的探索、實踐、技術升級等等。
所有平臺的生命力源自於生產效率的綜合提高，降低整體成本。對於滴滴機器學習平臺而言，內部第一目標是要降低滴滴在使用最新的機器學習、深度學習、強化學習等技術上能夠保證整體效率和成本控制，同時兼顧創新的活力。
對於外部而言，秉承持續為客戶創造價值的理念，深化雲平臺產品的各項產品功能、質量和成本，為客戶打造物美價廉的技術產品。
機器學習平臺3.0
具體來說，滴滴機器學習平臺要實現 3.0 階段，也即從硬體選型到基礎設施到上層整個軟體棧，能夠做到內外統一架構，降低內外兩部分的重複性工作。
同時，我們會從 AI 解決問題的效率和規模兩方面著手，在平臺上提供更豐富的功能，比如開發演算法市場、模型市場、資料市場、GUI 介面以提高使用者使用各種學習技術的效率，也會繼續沉澱更多的具體服務，比如：人臉比對、語音識別、翻譯等等。
如果您對滴滴雲GPU雲主機、彈性推理服務（EIS）、機器學習平臺等產品、技術解決方案感興趣，歡迎訪問滴滴雲官網。
