摘要：滴滴機(jī)器學(xué)習(xí)平臺(tái)的治理思路主要是減少重復(fù)提高效率。本文將對(duì)滴滴的機(jī)器學(xué)習(xí)平臺(tái)進(jìn)行全面解讀，重點(diǎn)分享機(jī)器學(xué)習(xí)平臺(tái)不同階段所要解決的問題，以及解決問題的思路和技術(shù)方案。綜合和各自的利弊，滴滴機(jī)器學(xué)習(xí)平臺(tái)開始由架構(gòu)向建構(gòu)遷移。

前言：現(xiàn)在很多互聯(lián)網(wǎng)公司都有自己的機(jī)器學(xué)習(xí)平臺(tái)，冠以之名雖然形形色色，但就平臺(tái)所要解決的問題和技術(shù)選型基本還是大同小異。所謂大同是指大家所要處理的問題都相似，技術(shù)架構(gòu)和選型也差不太多，比如都會(huì)使用 GPU 集群、采用 Spark 或 K8s 平臺(tái)等。所謂小異是指各家規(guī)模不同，各家都在結(jié)合自己的情況、所處的階段并根據(jù)自己的特點(diǎn)解決平臺(tái)化的問題。滴滴機(jī)器學(xué)習(xí)平臺(tái)的治理思路主要是：減少重復(fù)、提高效率。本文將對(duì)滴滴的機(jī)器學(xué)習(xí)平臺(tái)進(jìn)行全面解讀，重點(diǎn)分享機(jī)器學(xué)習(xí)平臺(tái)不同階段所要解決的問題，以及解決問題的思路和技術(shù)方案。希望能夠?qū)Υ蠹矣兴鶐椭?/p>

▍機(jī)器學(xué)習(xí)平臺(tái)1.0：從“作坊”向“集中化”過渡

滴滴的機(jī)器學(xué)習(xí)平臺(tái)建設(shè)開始于2016年，當(dāng)時(shí)滴滴內(nèi)部各算法團(tuán)隊(duì)逐步開展機(jī)器學(xué)習(xí)、深度學(xué)習(xí)等 AI 相關(guān)的研究和實(shí)踐應(yīng)用，這類算法大都屬于計(jì)算密集型應(yīng)用，一般都會(huì)使用單價(jià)較昂貴的 GPU 服務(wù)器。但隨著業(yè)務(wù)的開展，各算法團(tuán)隊(duì)僅針對(duì)各自的問題做規(guī)劃，導(dǎo)致了一種小作坊式的生產(chǎn)局面。

作坊式生產(chǎn)方式在早期有其積極的一面，能夠保證創(chuàng)新的靈活性，但是越往后，這種小作坊式算法生產(chǎn)模式的局限就越明顯：資源缺乏統(tǒng)籌調(diào)度，無法形成規(guī)模化效應(yīng)，大量重復(fù)性工作，自擁算力有限。逐漸增多的這種小作坊式生產(chǎn)方式致使整體投入產(chǎn)出的效益大打折扣。

滴滴機(jī)器學(xué)習(xí)平臺(tái)在這種背景下應(yīng)運(yùn)而生，這個(gè)階段也主要致力于解決這些問題。這期間機(jī)器學(xué)習(xí)平臺(tái)所采用的架構(gòu)和技術(shù)選型主要針對(duì)作坊式生產(chǎn)方式的問題來展開，也就是提高復(fù)用性和規(guī)?；芰Α?/p>

首先要解決的問題就是統(tǒng)一資源管理，這個(gè)“統(tǒng)一”要解決包括線下和線上兩類問題。

線下“統(tǒng)一”的問題著重解決 GPU 的服務(wù)器選型、測(cè)試、引入、上線等的集中化。這類集中化一方面提高了服務(wù)器引入的上線質(zhì)量；另一方面相比于作坊式模式，由于有 GPU 相關(guān)專業(yè)人員參與進(jìn)來，GPU 的選型避免了一味追新的盲目性和發(fā)散性。

再者，集中化能夠和公司整體大局結(jié)合起來，從而可以做最優(yōu)化的選型和引入方案。

線上“統(tǒng)一”需要解決的問題細(xì)分為資源管理問題和任務(wù)調(diào)度問題，使資源使用方能夠用即申請(qǐng)，完即釋放，從而盤活整個(gè)資源大池，對(duì)平臺(tái)要求則需要做到資源的隔離和管理。

這個(gè)階段需要解決資源統(tǒng)一管理后如何避免重復(fù)性工作的問題。此時(shí)所謂的避免重復(fù)性，意在讓各個(gè)算法業(yè)務(wù)不需重復(fù)諸如 Caffe、TensorFlow、PyTorch 等運(yùn)行環(huán)境的構(gòu)建，而是要一次構(gòu)建所有用戶都可用。這對(duì)平臺(tái)來講，需要做到應(yīng)用環(huán)境管理、用戶自定義環(huán)境、快速環(huán)境部署。

厘清這些需求之后，結(jié)合當(dāng)時(shí)的技術(shù)環(huán)境和成熟度來看及以上的基本要求，平臺(tái)選擇當(dāng)下盛行的 Docker 來兼做環(huán)境的管理、資源的弱隔離和任務(wù)的調(diào)度。

但由于此時(shí)支持 GPU 資源調(diào)度的資源管理器乏善可陳，所以我們選擇對(duì) Yarn 做了擴(kuò)展以支持 GPU 資源維度上的資源管理和任務(wù)調(diào)度，環(huán)境上平臺(tái)同時(shí)提供 Notebook、Jupyter 的交互接口給用戶。

統(tǒng)一資源管理、環(huán)境管理后，不得不面對(duì)的問題是多個(gè)資源節(jié)點(diǎn)間數(shù)據(jù)共享的問題，用戶在當(dāng)前資源釋放后申請(qǐng)新資源時(shí)往往對(duì)之前的數(shù)據(jù)有依賴。

多節(jié)點(diǎn)數(shù)據(jù)共享在作坊式時(shí)期受限于單個(gè)的規(guī)模，問題不會(huì)十分突出，但是集中化之后隨用戶增多就會(huì)逐漸尖銳起來乃至是個(gè)大的技術(shù)挑戰(zhàn)。因?yàn)椋?/p>

機(jī)器學(xué)習(xí)的任務(wù)計(jì)算特點(diǎn)依賴于 GPU 的高速計(jì)算，它們對(duì)數(shù)據(jù)訪問延遲有一定要求，這要求必須有足夠高的 IO 帶寬做支持；
用戶數(shù)量增加，對(duì)存儲(chǔ)帶寬的需求會(huì)變的非常大；
對(duì)存儲(chǔ)系統(tǒng)來說，支持 POSIX 接口的要求使得現(xiàn)有技術(shù)方案大大減小，另外也需在高可靠性、高性能以及成本之間做折中。

滴滴機(jī)器學(xué)習(xí)平臺(tái)在存儲(chǔ)系統(tǒng)上的嘗試還是借用傳統(tǒng)超算使用的 PFS 作為整個(gè)數(shù)據(jù)存儲(chǔ)的一級(jí)，底層網(wǎng)絡(luò)基礎(chǔ)設(shè)施使用高帶寬的以太網(wǎng)絡(luò)，使用 RoCE 協(xié)議做 RDMA 的支持，并往這個(gè)方向演進(jìn)。

                               機(jī)器學(xué)習(xí)平臺(tái)架構(gòu)-Yarn

總的來看，這個(gè)階段所面對(duì)的問題以內(nèi)部問題為主，從作坊式到集中化生產(chǎn)的發(fā)展階段，要解決的相關(guān)重復(fù)性的問題也比較簡(jiǎn)單。其中有些問題本質(zhì)屬于集中化后產(chǎn)生的問題，但是解決思路還是作坊式的，技術(shù)選型上的局限性也沒有完全暴露出來。

▍機(jī)器學(xué)習(xí)平臺(tái)2.0：平臺(tái)發(fā)展

隨著作坊逐漸消失，機(jī)器學(xué)習(xí)平臺(tái)作為一種集中化的生產(chǎn)方式呈現(xiàn)給公司所有算法團(tuán)隊(duì)。平臺(tái)功能開始完整和完善，監(jiān)控體系，運(yùn)維體系，更加精細(xì)化的資源隔離、管理及優(yōu)化；根據(jù)用戶不同的任務(wù)性質(zhì)也提供了不同性質(zhì)的任務(wù)支持。

經(jīng)歷了前一個(gè)階段后，雖然有效降低了作坊生產(chǎn)的重復(fù)性工作，但也幾乎必然的產(chǎn)生了一些新形態(tài)的重復(fù)工作。用戶接入的增多，用戶任務(wù)的性質(zhì)也多樣化，有些是實(shí)驗(yàn)性質(zhì)的、有些是在線生產(chǎn)任務(wù)、有些是單卡任務(wù)、有些是多卡多機(jī)的訓(xùn)練任務(wù)等等。

每種性質(zhì)的任務(wù)都有各自重復(fù)的具體形式，比如用戶在模型生產(chǎn)后要部署模型服務(wù)就需要解決服務(wù)的 HA、負(fù)載均衡等生產(chǎn)服務(wù)問題，每一個(gè)在線模型都要解決這類問題。

再比如，用戶訓(xùn)練時(shí)往往需要調(diào)參，而這些參數(shù)都是同形的，只是數(shù)值上的變化，這種值上的變化后就是一個(gè)個(gè)獨(dú)立任務(wù)，需要用戶提交任務(wù)的流程，這也是重復(fù)性的工作。

再比如，用戶在運(yùn)行多機(jī)多卡時(shí)需要參數(shù)服務(wù)器，低效的參數(shù)服務(wù)器把大量的時(shí)間浪費(fèi)在通信上，這種浪費(fèi)會(huì)加重用戶資源使用上的重復(fù)；與這種重復(fù)形式相似的，還有模型服務(wù)要上線，為了滿足服務(wù)的延遲、QPS、資源的約束，需要做從服務(wù)、到深度學(xué)習(xí)框架、再到計(jì)算庫(kù)的全棧優(yōu)化，基本上，大部分模型上線也需要經(jīng)歷這個(gè)優(yōu)化過程。

針對(duì)上述新出現(xiàn)的問題，平臺(tái)需要更加強(qiáng)大的資源管理和任務(wù)調(diào)度能力。

在上一時(shí)期選用作為資源管理和任務(wù)調(diào)度器的 Yarn 開始呈現(xiàn)出疲態(tài)，具體表現(xiàn)在 K8S 日臻成熟，與 Docker 的結(jié)合更加合理和完整，并能夠整合多種維度的資源，使用 K8S 為解決模型服務(wù)的自動(dòng)化部署提供了環(huán)境和條件，也降低了服務(wù)的運(yùn)維成本。

綜合 K8S 和 Yarn 各自的利弊，滴滴機(jī)器學(xué)習(xí)平臺(tái)開始由 Yarn 架構(gòu)向 K8S 建構(gòu)遷移。

                               機(jī)器學(xué)習(xí)平臺(tái)架構(gòu)-K8S

針對(duì)用戶同形調(diào)參的效率問題，平臺(tái)對(duì)用戶的 Python 代碼做語(yǔ)義分析以自動(dòng)識(shí)別出哪些參數(shù)可能會(huì)是需要調(diào)整的參數(shù)，用戶只需要設(shè)置值域和步距就可以自動(dòng)獲取整套參數(shù)的模型訓(xùn)練任務(wù)以及最終的結(jié)果。

針對(duì)多機(jī)多卡訓(xùn)練效率問題，平臺(tái)結(jié)合自己的硬件特點(diǎn)和通信模式特點(diǎn)，開發(fā)了滴滴參數(shù)服務(wù)器。滴滴參數(shù)服務(wù)器采取環(huán)狀結(jié)構(gòu)，實(shí)現(xiàn)了高效的 RDMA 通信的 Allreduce 算法。

環(huán)狀結(jié)構(gòu)而非中心集中的 server-client 模式，消除了網(wǎng)絡(luò)傳輸可能的帶寬競(jìng)爭(zhēng)和網(wǎng)絡(luò)擁塞。底層自研的高效 RDMA 通信庫(kù)，規(guī)避了設(shè)備廠家提供用戶態(tài) Verbs 內(nèi)部分性能損失，重寫的底層通信庫(kù)實(shí)現(xiàn)了 sig/read 及 post/recv 兩種模式，盡量規(guī)避了 RDMA 固有的通信開銷，充分挖掘了硬件的屬性來提高性能。

另外，自研的 Allreduce 算法巧妙重疊了計(jì)算和傳輸，盡量減少了不必要的內(nèi)存拷貝來減少額外代價(jià)，并充分考慮了 GPU 拓?fù)?、CPU 親和性等硬件屬性來提高性能。

在機(jī)房 40G 帶寬的 RoCE v2 RDMA 網(wǎng)絡(luò)實(shí)際測(cè)試中，對(duì)比業(yè)界的 OpenMPI 和 Nvidia 的 NCCL2 方案，滴滴參數(shù)服務(wù)器有明顯優(yōu)勢(shì)。

針對(duì)模型服務(wù)部署和優(yōu)化，平臺(tái)結(jié)合自己的場(chǎng)景特點(diǎn)開發(fā)了 DDL（DiDi Deep Learning） Serving 服務(wù)框架、IFX 框架和 Autotuning 優(yōu)化庫(kù)，極大加速了模型上線部署和優(yōu)化過程。

針對(duì)模型服務(wù)部署和優(yōu)化，平臺(tái)結(jié)合自己的場(chǎng)景特點(diǎn)開發(fā)了 DDL（DiDi Deep Learning） Serving 服務(wù)框架、IFX 框架和 Autotuning 優(yōu)化庫(kù)，極大加速了模型上線部署和優(yōu)化過程。

DDL Serving 獨(dú)創(chuàng)自適應(yīng)的 batch 機(jī)制，優(yōu)化 RPC 協(xié)議，解決 Tensorflow Serving 的缺陷，相比于 Tensorflow Serving 性能對(duì)比加速如下：

DDL Serving 框架服務(wù)本身不再成為整個(gè)服務(wù)鏈路中的瓶頸點(diǎn)，對(duì)于一些輕量模型可以有 3 倍的性能提升，包括 RT 和 QPS 的提升, 而對(duì)于一般模型，性能熱點(diǎn)落在深度學(xué)習(xí)框架層。

因此，針對(duì)框架層，我們自主研發(fā)了深度學(xué)習(xí)框架 IFX，并同時(shí)適配于 GPU 服務(wù)器和移動(dòng)端平臺(tái)。在 GPU 服務(wù)器上，由于 CUDA 存在 context 管理的問題，所以我們?cè)O(shè)計(jì)實(shí)現(xiàn)了一種 GPU 上的并發(fā)機(jī)制，有效地繞開了這些問題所帶來的額外開銷，另外對(duì)大量的 OP 做了優(yōu)化，使得 IFX 的性能遠(yuǎn)高于 Tensoflow 乃至 TensorRT。

IFX 針對(duì)移動(dòng)端的不同硬件配置，比如：流水線長(zhǎng)度、順序亂序、超標(biāo)量等特點(diǎn)進(jìn)行指令重排、訪存優(yōu)化，結(jié)合業(yè)務(wù)的計(jì)算特點(diǎn)，使得 IFX 的性能取得不俗的表現(xiàn)：

在 IFX 的優(yōu)化過程中，大量的重復(fù)工作基本在 Tuning Blas 計(jì)算，由于硬件架構(gòu)不同，不同模型的計(jì)算量、計(jì)算訪存比、計(jì)算訪存模式都不同，在極高性能要求下都需要綜合這些具體的情況做針對(duì)性的優(yōu)化。這些優(yōu)化都很底層，并且調(diào)優(yōu)都相對(duì)繁瑣，對(duì)于上層服務(wù)用戶來講，不必關(guān)心這些底層細(xì)節(jié)。

為解決這類問題，平臺(tái)開發(fā)了 Autotuning 工具鏈，包括 Kepler、Pascal、Volta 架構(gòu)的原生匯編器。

對(duì)于用戶來講，只需要把 GPU 上的二進(jìn)制代碼發(fā)給平臺(tái)，平臺(tái)就可產(chǎn)生在該 GPU 平臺(tái)上幾乎是最優(yōu)，也就是當(dāng)前最高性能優(yōu)化后的二進(jìn)制代碼。

滴滴機(jī)器學(xué)習(xí)平臺(tái)團(tuán)隊(duì)也是目前除了 NV 以外，自己掌握 NV GPU 原生匯編器支持版本最多，對(duì) NV GPU 微架構(gòu)最了解的。

這些“重復(fù)問題”隨著集中化和平臺(tái)化產(chǎn)生，也在平臺(tái)化的環(huán)境下使得解決這些“重復(fù)”變得有意義。

集中化、平臺(tái)化帶來的第二個(gè)好處便是在此基礎(chǔ)上，通用性的需求逐漸會(huì)沉淀為平臺(tái)的服務(wù)。

比如，相似檢索的需求在滴滴地圖的 POI 優(yōu)化、人臉檢索、視頻圖像內(nèi)容檢索等業(yè)務(wù)場(chǎng)景中都是共性需求，因此平臺(tái)會(huì)獲得足夠的業(yè)務(wù)信息來開發(fā)這種平臺(tái)級(jí)的服務(wù)，而在作坊式時(shí)代很難獲得這類跨業(yè)務(wù)場(chǎng)景的需求而自發(fā)的沉淀出平臺(tái)服務(wù)，大多還是自掃門前雪。

▍機(jī)器學(xué)習(xí)平臺(tái)2.1：內(nèi)外云平臺(tái)成形

集中化生產(chǎn)后的第二個(gè)影響，隨著平臺(tái)能力的增加以及孵化落地算法逐步豐富，加上滴滴內(nèi)部數(shù)據(jù)、AI 工程和算法逐步積累成熟，機(jī)器學(xué)習(xí)平臺(tái)的功能、定位也變得多樣化。

除了服務(wù)好滴滴內(nèi)部機(jī)器學(xué)習(xí)平臺(tái)用戶，進(jìn)一步夯實(shí)資源調(diào)度、任務(wù)管理、監(jiān)控運(yùn)維等能力外，平臺(tái)開始承接內(nèi)部能力對(duì)外輸出的職能，期間機(jī)器學(xué)習(xí)平臺(tái)和滴滴云著手在公有云上打造從底層資源到上層平臺(tái)、從公有云到私有云的解決方案。

機(jī)器學(xué)習(xí)內(nèi)部的集中化生產(chǎn)也給滴滴機(jī)器學(xué)習(xí)平臺(tái)能力的輸出做了儲(chǔ)備，但外部客戶的技術(shù)產(chǎn)品要求相對(duì)更復(fù)雜。

這種復(fù)雜首先體現(xiàn)在產(chǎn)品要求的多層次性：有對(duì)資源乃至對(duì)硬件的直接要求、有對(duì)具體服務(wù)的需求、也有例如在私有云中對(duì)平臺(tái)能力的需求；其次, 產(chǎn)品考量因素的多維性：資源的性價(jià)比往往只是一方面，安全性、穩(wěn)定性、與其他基礎(chǔ)設(shè)施的整合能力等也都是影響用戶決策的因素；最后，橫向各友商競(jìng)品的對(duì)比。

所有這些問題都是滴滴機(jī)器學(xué)習(xí)平臺(tái)對(duì)外服務(wù)碰到的問題，但是這些問題不可能做到“畢其功于一役”，都是分階段分步驟，有側(cè)重的解決此間的問題。

第一步要解決的是基礎(chǔ)問題，如何透出能力，如何保證客戶的安全性，如何在前兩個(gè)能力的基礎(chǔ)上，盡最大力減少外部用戶的重復(fù)性工作（用戶使用的成本）和滴滴機(jī)器學(xué)習(xí)平臺(tái)的重復(fù)性工作（產(chǎn)品性價(jià)比）。

▍GPU 資源：減少資源的重復(fù)性工作

相比于內(nèi)部的用戶，外部用戶使用資源需要有一個(gè)安全的隔離環(huán)境，僅用 Docker 的弱隔離方式無法給用戶提供安全且隔離的環(huán)境。所以滴滴云上 GPU 云資源使用 KVM 和 GPU 透?jìng)鞯姆绞桨?GPU 資源透?jìng)鹘o用戶。

滴滴機(jī)器學(xué)習(xí)平臺(tái)技術(shù)團(tuán)隊(duì)對(duì) GPU 的使用頗有心得，團(tuán)隊(duì)成員也是早期一批在工業(yè)界嘗試 GPU 的團(tuán)隊(duì)，積累了豐富的 GPU 使用一線的知識(shí)和經(jīng)驗(yàn)，而且這些在滴滴內(nèi)部被佐證十分有效，從 GPU 資源、拓?fù)浜拖嚓P(guān)配套上都特別花心思，所以相同 GPU 型號(hào)，用戶往往可以獲得更好的性能，對(duì)比如下圖。這部分的沉淀也減少了外部用戶在探索使用 GPU 過程中的重復(fù)性工作，降低了使用的隱性成本。

▍彈性推理服務(wù)（EIS）：減少服務(wù)部署優(yōu)化的重復(fù)

所有的算法模型最終都需要用于生產(chǎn)服務(wù)，國(guó)外有很多 PAML 平臺(tái)能夠部署機(jī)器學(xué)習(xí)模型服務(wù)，機(jī)器學(xué)習(xí)平臺(tái)在滴滴云上也提供了一種模型部署服務(wù)——EIS（彈性預(yù)測(cè)服務(wù)）。

EIS 服務(wù)根植于內(nèi)部使用的 DDL Serving 服務(wù)，但因在云上服務(wù)我們對(duì)一些理念的堅(jiān)持，所以大家可能會(huì)產(chǎn)生我們有“起大早趕晚集”的疑問。

實(shí)際上，EIS 在滴滴內(nèi)部以 DDL 的形式出現(xiàn)的相對(duì)不算晚，這一塊的服務(wù)市場(chǎng)現(xiàn)在只能說是剛剛起步，產(chǎn)品的差異化和多樣化會(huì)是必然的趨勢(shì)，對(duì)用戶來講也有更好更大的選擇空間。

目前，市面上大大小小提供 PA 服務(wù)的廠商大都有各自的特點(diǎn)，但總的來說他們對(duì)這個(gè)產(chǎn)品的定位依然僅僅是作為資源產(chǎn)品的輔助角色，著重為用戶解決資源和部署問題。這種輔助角色，有他的好處，主要包括：

模式簡(jiǎn)單，把服務(wù)轉(zhuǎn)化為最小粒度資源開銷，按最小單位資源消耗來計(jì)費(fèi)；
對(duì)基礎(chǔ)設(shè)施的能力要求降低，簡(jiǎn)化為資源開銷，本質(zhì)上只是多了一種資源的售賣形式；
服務(wù)廠商的工作最小化，雖然用戶可以選擇多種資源，并且每種資源的都有各自理論上的計(jì)算能力，用戶怎么利用好這些資源是用戶自己的事情。

這個(gè)模式的問題在于服務(wù)商雖然為客戶解決了一部分問題，但是對(duì)用戶實(shí)際的服務(wù)部署考慮仍然不周。為什么？

原因在 DDL 描述中也提到過，模型服務(wù)部署服務(wù)都需要用戶自己優(yōu)化服務(wù)以滿足 RT、QPS 的要求，更進(jìn)一步說，成本如何最優(yōu)化，用戶使用云服務(wù)，成本幾乎是必然會(huì)面對(duì)和慎重考慮的。

所以從這個(gè)點(diǎn)來看，PA 服務(wù)提供商以資源為主，服務(wù)為輔的模式的缺點(diǎn)也顯而易見：

最小粒度資源的粒度對(duì)模型服務(wù)來說，粒度依舊比較粗，如若使用到 GPU，問題更加突出；

資源的理論計(jì)算能力對(duì)用戶來講往往僅是個(gè)理論數(shù)字，受限于硬件的限制和客戶自己的技術(shù)能力，客戶往往并不能充分利用 PA 廠商提供的資源的計(jì)算能力，而一般利用率都有限，這實(shí)際使用和標(biāo)稱的理論數(shù)字之間的資源費(fèi)用實(shí)際是由用戶買單的，而更甚者，對(duì)用戶來講這里有兩部分工作是重復(fù)的：資源的使用優(yōu)化的重復(fù)，服務(wù)部署的運(yùn)維相關(guān)工作的重復(fù)。

根據(jù)我們內(nèi)部用戶和一些外部用戶的經(jīng)驗(yàn)，服務(wù)最核心的技術(shù)指標(biāo)是 QPS 和 RT，進(jìn)而才是滿足這兩個(gè)指標(biāo)情況下的部署成本和使用成本。而這些成本的降低則必須在盡可能減少用戶的重復(fù)工作和“實(shí)用實(shí)銷”的基礎(chǔ)上，除了一般服務(wù)部署需要的 HA 和運(yùn)維支持外，EIS 從技術(shù)架構(gòu)設(shè)計(jì)上側(cè)重于解決這兩方面問題。

從 RT 來講：用戶服務(wù) RT 的開銷受限于網(wǎng)絡(luò)鏈路和實(shí)際前向計(jì)算的開銷，為了減少網(wǎng)絡(luò)鏈路的開銷，滴滴云花了不少時(shí)間，在公有云上實(shí)現(xiàn)了純公有云化的 Gateway，一方面用于支持用戶自定義的鑒權(quán)等操作，另一方面也最小化網(wǎng)路跳數(shù)以降低網(wǎng)絡(luò)的開銷，保證用戶服務(wù)的 RT。

從 QPS 來講，EIS 使用滴滴機(jī)器學(xué)習(xí)平臺(tái)的 DDL Serving 作為服務(wù)引擎框架，使用 DDL Serving 的用戶可以忽略底層硬件的細(xì)節(jié)，從而可以避免用戶重復(fù)地去做服務(wù)框架層面的已知的優(yōu)化工作，這樣也為實(shí)現(xiàn)用戶“實(shí)用實(shí)銷”提供了條件?？梢酝ㄟ^以下的架構(gòu)圖了解：

要做到“實(shí)用實(shí)銷”，還有一個(gè)非常關(guān)鍵的環(huán)節(jié)就是需要知道用戶的模型實(shí)際的計(jì)算需求量，以及某一種硬件下的計(jì)算利用率。

我們開發(fā)了一個(gè)自動(dòng)壓測(cè)模塊，用戶提供模型和部署輸入就可以獲得使用 DDL Serving 在某種硬件下的計(jì)算性能，進(jìn)一步回歸出某種 RT 性能要求下的 QPS 能力。

對(duì)用戶來講，用戶折算出業(yè)務(wù)需總的 QPS 后按 QPS 橫向擴(kuò)容即可，相當(dāng)于用戶只負(fù)擔(dān)了實(shí)際消耗的計(jì)算性能的那部分資源，這比之前的模式是更加細(xì)粒度的資源控制。

用戶優(yōu)化上的重復(fù)性工作的減少，如之前講過的除了服務(wù)框架的優(yōu)化外，還有一部分優(yōu)化是花在計(jì)算性能的優(yōu)化上，但計(jì)算性能的優(yōu)化往往取決于程序的計(jì)算特性和相關(guān)的硬件特性，并且每種模型都有各自的特點(diǎn)。

這部分工作 EIS 也提供了 Autotuning 的優(yōu)化服務(wù)，用戶需要提供他的二進(jìn)制代碼，通過 Autotuning 服務(wù)后會(huì)產(chǎn)生某種模型和框架下在指定硬件下幾乎是最優(yōu)的性能代碼。

Autotuning 服務(wù)除了能降低重復(fù)基礎(chǔ)的和瑣碎的優(yōu)化工作外，也能夠提升用戶模型服務(wù) RT 和每 QPS 實(shí)際資源消耗資源。

目前 EIS 已經(jīng)接入滴滴內(nèi)部大量的業(yè)務(wù)，其整個(gè)功能模塊圖如下。因?yàn)橐恍┫拗?，?duì)外部客戶，當(dāng)前滴滴云 EIS 服務(wù)還是通過提交工單接入的方法，用戶自助的方式馬上會(huì)上線。

▍簡(jiǎn)樞：降低用戶重復(fù)平臺(tái)建設(shè)

同 EIS 一樣，機(jī)器學(xué)習(xí)平臺(tái)級(jí)產(chǎn)品在內(nèi)部積累了豐富的一線的平臺(tái)經(jīng)驗(yàn)，基于此，機(jī)器學(xué)習(xí)平臺(tái)在滴滴云上開發(fā)了平臺(tái)級(jí)產(chǎn)品簡(jiǎn)樞。

簡(jiǎn)樞包裝了多種平臺(tái)能力，弱隔離方案的資源管理、多種任務(wù)管理、監(jiān)控報(bào)警、在線服務(wù)快速部署等，能夠幫助其他公司在平臺(tái)化過程中少踩坑，快速具備平臺(tái)能力，提高生產(chǎn)效益。

▍未來展望

對(duì)于機(jī)器學(xué)習(xí)來講，計(jì)算力仍然是最具革命性的力量，正如 2011 年開始的這波深度學(xué)習(xí)浪潮的助力正是 GPU 一樣，未來計(jì)算力還是工程層面的制約力。

如 Jeff Dean 所言“事實(shí)證明，我們真正需要的是超過現(xiàn)在 100 萬倍的計(jì)算能力，而不僅僅是幾十倍的增長(zhǎng)?！币虼?，對(duì)平臺(tái)來講，如何更好的管理不斷爆發(fā)式增加的計(jì)算力、如何有效的釋放出這些計(jì)算力，如何駕馭好這些計(jì)算力仍然需要平臺(tái)不斷的探索、實(shí)踐、技術(shù)升級(jí)等等。

所有平臺(tái)的生命力源自于生產(chǎn)效率的綜合提高，降低整體成本。對(duì)于滴滴機(jī)器學(xué)習(xí)平臺(tái)而言，內(nèi)部第一目標(biāo)是要降低滴滴在使用最新的機(jī)器學(xué)習(xí)、深度學(xué)習(xí)、強(qiáng)化學(xué)習(xí)等技術(shù)上能夠保證整體效率和成本控制，同時(shí)兼顧創(chuàng)新的活力。

對(duì)于外部而言，秉承持續(xù)為客戶創(chuàng)造價(jià)值的理念，深化云平臺(tái)產(chǎn)品的各項(xiàng)產(chǎn)品功能、質(zhì)量和成本，為客戶打造物美價(jià)廉的技術(shù)產(chǎn)品。

                         機(jī)器學(xué)習(xí)平臺(tái)3.0
                         

具體來說，滴滴機(jī)器學(xué)習(xí)平臺(tái)要實(shí)現(xiàn) 3.0 階段，也即從硬件選型到基礎(chǔ)設(shè)施到上層整個(gè)軟件棧，能夠做到內(nèi)外統(tǒng)一架構(gòu)，降低內(nèi)外兩部分的重復(fù)性工作。

同時(shí)，我們會(huì)從 AI 解決問題的效率和規(guī)模兩方面著手，在平臺(tái)上提供更豐富的功能，比如開發(fā)算法市場(chǎng)、模型市場(chǎng)、數(shù)據(jù)市場(chǎng)、GUI 界面以提高用戶使用各種學(xué)習(xí)技術(shù)的效率，也會(huì)繼續(xù)沉淀更多的具體服務(wù)，比如：人臉比對(duì)、語(yǔ)音識(shí)別、翻譯等等。

如果您對(duì)滴滴云GPU云主機(jī)、彈性推理服務(wù)（EIS）、機(jī)器學(xué)習(xí)平臺(tái)等產(chǎn)品、技術(shù)解決方案感興趣，歡迎訪問滴滴云官網(wǎng)。