滴滴機器學習平臺架構演進

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