前言：現在很多互聯網公司都有自己的機器學習平臺，冠以之名雖然形形色色，但就平臺所要解決的問題和技術選型基本還是大同小異。所謂大同是指大家所要處理的問題都相似，技術架構和選型也差不太多，比如都會使用 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）、機器學習平臺等產品、技術解決方案感興趣，歡迎訪問滴滴雲官網。
