一、前言

在過去的幾年中，以容器技術(shù)為代表的云原生領(lǐng)域受到了極大的關(guān)注和發(fā)展，容器化的落地是企業(yè)降本增效的一個(gè)重要手段，截止目前得物已基本完成了全域的容器化。容器化過程中，一方面平穩(wěn)地將服務(wù)的部署和運(yùn)維方式從以前的ECS模式切換到了容器化模式；另一方面為公司在資源利用率、研發(fā)效率上拿到了許多提效的收益。

得物作為新一代潮流網(wǎng)購社區(qū)，以AI和大數(shù)據(jù)技術(shù)為基礎(chǔ)的搜索引擎、個(gè)性化推薦系統(tǒng)是業(yè)務(wù)開展的強(qiáng)大支撐力，所以業(yè)務(wù)應(yīng)用當(dāng)中算法域的應(yīng)用占了的很大比例。容器化過程中，針對(duì)算法應(yīng)用服務(wù)的研發(fā)流程和普通服務(wù)的差異性，在充分調(diào)研算法域研發(fā)同學(xué)需求的基礎(chǔ)上，我們面向算法域的研發(fā)場景建設(shè)了得物云原生AI平臺(tái)—KubeAI平臺(tái)。經(jīng)過功能的不斷迭代，在支持的場景上不斷拓展，KubeAI當(dāng)前已經(jīng)支持CV、搜索推薦、風(fēng)控算法和數(shù)據(jù)分析等涉及AI能力的業(yè)務(wù)域順利完成了容器化，在資源利用率提升、研發(fā)效率提升上面均拿到了不錯(cuò)的成果，本文將帶大家一起了解KubeAI的落地實(shí)踐過程。

二、AI業(yè)務(wù)的容器化推進(jìn)

2.1 AI算法模型開發(fā)流程

AI業(yè)務(wù)更多的是針對(duì)模型的迭代開發(fā)過程，通常模型的開發(fā)過程可以歸納為以下幾個(gè)步驟：

確定需求場景：這個(gè)過程要明確解決的問題是什么，為哪種場景提供功能，功能/服務(wù)的輸入是什么，輸出是什么？例如：針對(duì)哪種品牌的鞋子做鑒別或質(zhì)檢，該品牌的產(chǎn)品特征是什么，樣本有哪些維度的特征，特征類型等等。不同的場景對(duì)樣本數(shù)據(jù)的要求、使用的處理算法也是不一樣的。

數(shù)據(jù)準(zhǔn)備：按照?qǐng)鼍靶枨蠓治龅慕Y(jié)果，通過各種方式（線上/線下/mock等）獲取樣本數(shù)據(jù)，對(duì)數(shù)據(jù)做必要的清洗、標(biāo)注等操作。這個(gè)過程是AI業(yè)務(wù)開發(fā)的基礎(chǔ)，因?yàn)楹罄m(xù)的所有過程都是在數(shù)據(jù)的基礎(chǔ)上進(jìn)行的。

確定算法，編寫訓(xùn)練腳本：基于對(duì)業(yè)務(wù)目標(biāo)的理解，在這個(gè)環(huán)節(jié)算法同學(xué)會(huì)根據(jù)過往的經(jīng)驗(yàn)，或者針對(duì)該場景調(diào)研、實(shí)驗(yàn)結(jié)果，選擇合適的算法，編寫模型訓(xùn)練腳本。

模型訓(xùn)練：對(duì)于算法模型，我們可以將它理解為是一個(gè)復(fù)雜的數(shù)學(xué)公式，這個(gè)公式里會(huì)有很多參數(shù)，就像f(x)=wx+b里的w和b一樣。訓(xùn)練就是為了使得模型具有高識(shí)別率，而使用大量的樣本數(shù)據(jù)，找到最優(yōu)參數(shù)的過程。模型訓(xùn)練是AI業(yè)務(wù)開發(fā)過程中很重要的一環(huán)，可以說業(yè)務(wù)目標(biāo)的達(dá)成就靠模型的準(zhǔn)確度。所以，這個(gè)環(huán)節(jié)相比其它環(huán)節(jié)要花費(fèi)更多的時(shí)間、精力和資源，而且要反復(fù)地進(jìn)行實(shí)驗(yàn)訓(xùn)練，以期望達(dá)到最好的模型精度和預(yù)測準(zhǔn)確性。這個(gè)過程也不是一次性的，而是周期性的，根據(jù)業(yè)務(wù)場景的更新，數(shù)據(jù)的更新，要周期性的進(jìn)行。針對(duì)算法模型的開發(fā)和訓(xùn)練工作，業(yè)界有一些主流的AI引擎可供選擇，比如TensorFlow、PyTorch、MXNet等，這些引擎可以提供一定程度上的API支持，方便算法開發(fā)人員將復(fù)雜的模型進(jìn)行分布式訓(xùn)練，或者針對(duì)硬件做一些優(yōu)化，以提高模型訓(xùn)練效率。模型訓(xùn)練的結(jié)果是拿到模型文件，這個(gè)文件的內(nèi)容可以理解為保存的是模型的參數(shù)。

模型評(píng)估：為了防止由于偏差過大造成模型欠擬合或者由于方差過大導(dǎo)致的過擬合，通常需要一些評(píng)價(jià)指標(biāo)來指導(dǎo)開發(fā)人員評(píng)估模型的泛化能力。常用的一些評(píng)價(jià)指標(biāo)，比如：精度、召回率、ROC曲線/AUC、PR曲線等。

模型部署：通過反復(fù)的訓(xùn)練和評(píng)估，得到較為理想的模型之后就可以幫助業(yè)務(wù)去處理在線/生產(chǎn)數(shù)據(jù)了。這就需要把模型以服務(wù)的形態(tài)，或者以任務(wù)的形態(tài)部署起來，以達(dá)到接受輸入數(shù)據(jù)，給出推理結(jié)果的目的，我們把這個(gè)服務(wù)稱之為模型服務(wù)。模型服務(wù)是一個(gè)在線服務(wù)腳本對(duì)模型進(jìn)行加載，就緒以后，對(duì)預(yù)處理之后的數(shù)據(jù)進(jìn)行推理計(jì)算。

一個(gè)模型服務(wù)上線之后，會(huì)隨著數(shù)據(jù)特征的變更、算法的升級(jí)、在線推理服務(wù)腳本的升級(jí)、業(yè)務(wù)對(duì)推理指標(biāo)的新要求等情況，需要對(duì)模型服務(wù)進(jìn)行迭代。需要注意的是，這個(gè)迭代過程，有可能需要對(duì)模型進(jìn)行重新訓(xùn)練、重新評(píng)估；也有可能只是推理服務(wù)腳本的迭代升級(jí)。

2.2 如火如荼的容器化遷移

從去年開始，我們逐步推進(jìn)得物各域業(yè)務(wù)服務(wù)的容器化落地。為了減少容器化過程中因部署方式的變化而引起用戶操作習(xí)慣的改變，我們繼續(xù)沿用發(fā)布平臺(tái)的部署流程，將容器部署與ECS部署的差異進(jìn)行屏蔽。

在CI過程中，根據(jù)不同的開發(fā)語言類型，定制不同的編譯構(gòu)建模板，從源碼編譯再到容器鏡像制作，由容器平臺(tái)層統(tǒng)一完成，解決了普通研發(fā)同學(xué)因?qū)θ萜飨嚓P(guān)知識(shí)不了解而無法將工程代碼制成一個(gè)容器鏡像的問題。在CD過程中，我們在應(yīng)用類型級(jí)別、環(huán)境級(jí)別、環(huán)境組級(jí)別進(jìn)行配置分層管理，執(zhí)行部署時(shí)將多層配置合并成Helm Chart的values.yaml，向容器集群提交編排文件。用戶只需根據(jù)自己實(shí)際需求，設(shè)置相應(yīng)的環(huán)境變量，即可提交部署，而后獲取應(yīng)用集群實(shí)例（容器實(shí)例，類似于ECS服務(wù)實(shí)例）。

針對(duì)應(yīng)用集群的運(yùn)維操作，容器平臺(tái)提供WebShell登陸容器實(shí)例的功能，就像登陸到ECS實(shí)例一樣，便于排查應(yīng)用進(jìn)程相關(guān)問題；容器平臺(tái)也提供了文件的上傳和下載、實(shí)例的重啟和重建、資源監(jiān)控等運(yùn)維功能。

AI業(yè)務(wù)（CV、搜推、風(fēng)控算法服務(wù)等）作為占比較大的業(yè)務(wù)，與普通的業(yè)務(wù)服務(wù)一起參與到容器化過程中，我們逐步完成了以社區(qū)、交易的瀑布流、金剛位為代表的核心場景服務(wù)的遷移。容器化之后，測試環(huán)境的資源利用率得到了極大的提升，生產(chǎn)環(huán)境也有了大幅的提升，運(yùn)維效率倍增。

2.3 算法同學(xué)不能承受之痛

得物容器化的過程，是伴隨著公司技術(shù)體系快速發(fā)展一起的，這讓初期不成熟的AI服務(wù)研發(fā)流程對(duì)容器化提出了更多的需求，讓本來只關(guān)注在線推理服務(wù)容器化的我們看到了算法同學(xué)在模型開發(fā)過程中的痛點(diǎn)和難點(diǎn)。

痛點(diǎn)1：模型的管理和推理服務(wù)的管理是不連貫的。CV的模型大多是在臺(tái)式機(jī)上訓(xùn)練的，然后手動(dòng)上傳到OSS上，然后將模型文件在OSS上的地址配置給在線推理服務(wù)。搜推的模型大多是在PAI上進(jìn)行訓(xùn)練，但是也是手動(dòng)存儲(chǔ)在OSS上，發(fā)布時(shí)與CV的類似?？梢钥吹?，對(duì)模型這個(gè)產(chǎn)物的管理，在模型訓(xùn)練和發(fā)布的過程中是不連貫的，無法追蹤一個(gè)模型到底部署在了哪幾個(gè)服務(wù)上，也沒法直觀看到一個(gè)服務(wù)部署了哪一個(gè)或者多個(gè)模型，模型版本管理不方便。

痛點(diǎn)2：模型開發(fā)環(huán)境準(zhǔn)備耗時(shí)長，資源申請(qǐng)和使用缺少彈性機(jī)制。在容器化之前，資源一般以ECS實(shí)例的方式提供，要走流程申請(qǐng)資源，申請(qǐng)到以后要做各種初始化工作，安軟件，裝依賴，傳數(shù)據(jù)（算法研究工作使用的軟件庫大多體積較大，安裝也較復(fù)雜）。當(dāng)一臺(tái)ECS搞定以后，后續(xù)如果資源不夠要再申請(qǐng)，相同的流程再走一遍，效率較低。同時(shí)，資源的申請(qǐng)?jiān)谂漕~（預(yù)算）的約束下，缺少自主管理、按需彈性申請(qǐng)和釋放的機(jī)制。

痛點(diǎn)3：想嘗試云原生支持的一些模型解決方案難。隨著云原生技術(shù)在各個(gè)領(lǐng)域的不斷落地，Kubeflow，Argo Workflow等解決方案為AI場景提供了很好的支持。比如：tfjob-operator可以將基于TensorFlow框架的分布式訓(xùn)練任務(wù)以CRD的方式進(jìn)行管理，用戶只需要設(shè)置相應(yīng)組件（Chief、PS、Worker等）的參數(shù)后，就可以向Kubernetes集群提交訓(xùn)練任務(wù)。在容器化以前，如果算法的同學(xué)想要嘗試這種方案，就必須熟悉和掌握Docker、Kubernetes等容器相關(guān)知識(shí)，而并不能以一個(gè)普通用戶的角色去使用這種能力。

痛點(diǎn)4：非算法部門想快速驗(yàn)證一個(gè)算法時(shí)找不到可以很好支撐的平臺(tái)。AI的能力顯然在各個(gè)業(yè)務(wù)域都會(huì)用到，特別是一些成熟的算法，業(yè)務(wù)團(tuán)隊(duì)可以很輕松地用它來做一些基線指標(biāo)預(yù)測，或者分類預(yù)測工作，以便幫助業(yè)務(wù)取得更好的效果。這時(shí)就需要有一個(gè)能提供AI相關(guān)能力的平臺(tái)，滿足這些場景對(duì)異構(gòu)資源（CPU/GPU/存儲(chǔ)/網(wǎng)絡(luò)等）的需求，對(duì)算法模型管理等需求，為用戶提供上手即用的功能。

立足于對(duì)以上痛點(diǎn)和難點(diǎn)問題的梳理和分析，同時(shí)基于容器化過程中算法同學(xué)對(duì)容器平臺(tái)提出的其它需求（比如：模型統(tǒng)一管理需求、日志采集需求、資源池需求、數(shù)據(jù)持久化需求等），我們逐一討論，各個(gè)擊破，在解決當(dāng)前問題的同時(shí)，也考慮平臺(tái)長遠(yuǎn)的功能規(guī)劃，逐步建成了以容器平臺(tái)為基礎(chǔ)，面向AI業(yè)務(wù)的KubeAI平臺(tái)解決方案。

三、KubeAI平臺(tái)解決方案

在充分調(diào)研和學(xué)習(xí)了業(yè)內(nèi)AI平臺(tái)的基本架構(gòu)、產(chǎn)品形態(tài)的基礎(chǔ)上，著眼于AI業(yè)務(wù)場景及其周邊業(yè)務(wù)需求，容器技術(shù)團(tuán)隊(duì)在得物容器化過程中設(shè)計(jì)和逐步落地了云原生AI平臺(tái)-KubeAI平臺(tái)。KubeAI平臺(tái)著力于解決算法同學(xué)的痛點(diǎn)需求，提供必要的功能模塊，貫穿模型的開發(fā)、發(fā)布和運(yùn)維流程，幫助算法開發(fā)者快速、低成本地獲取和使用AI基礎(chǔ)設(shè)施資源，快速高效地進(jìn)行算法模型設(shè)計(jì)、開發(fā)和實(shí)驗(yàn)。

3.1 整體架構(gòu)

KubeAI平臺(tái)圍繞模型的整個(gè)生命周期，提供了以下功能模塊：

數(shù)據(jù)集管理：主要是對(duì)不同的數(shù)據(jù)源進(jìn)行兼容，此外提供了數(shù)據(jù)緩存加速能力。

模型訓(xùn)練：既提供了Notebook進(jìn)行模型開發(fā)和訓(xùn)練，又支持對(duì)一次性/周期性任務(wù)進(jìn)行管理；這個(gè)流程中對(duì)異構(gòu)資源（CPU/GPU/存儲(chǔ)）彈性申請(qǐng)和釋放。

模型管理：對(duì)模型元數(shù)據(jù)（模型基本信息，版本列表等）進(jìn)行統(tǒng)一管理，與模型服務(wù)發(fā)布、運(yùn)維過程無縫銜接。

推理服務(wù)管理：把模型與推理代碼解耦，不需要把模型打包到鏡像里面，提高了推理服務(wù)更新的效率；支持對(duì)在線服務(wù)升級(jí)模型。

AI-Pipeline引擎：支持以流水線的方式編排任務(wù)，滿足數(shù)據(jù)分析、模型周期性例行訓(xùn)練任務(wù)、模型迭代等場景的需求。

KubeAI平臺(tái)不僅支持個(gè)人用戶，也支持平臺(tái)用戶。個(gè)人開發(fā)者同學(xué)使用KubeAI的Notebook進(jìn)行模型腳本開發(fā)，較小的模型可直接在Notebook中進(jìn)行訓(xùn)練，復(fù)雜模型通過任務(wù)的方式進(jìn)行訓(xùn)練。模型產(chǎn)出后在KubeAI上進(jìn)行統(tǒng)一管理，包括發(fā)布為推理服務(wù)，以及新版本的迭代。第三方業(yè)務(wù)平臺(tái)以O(shè)penAPI的方式獲取KubeAI的能力進(jìn)行上層業(yè)務(wù)創(chuàng)新。

下面我們重點(diǎn)介紹下數(shù)據(jù)集管理、模型訓(xùn)練、模型服務(wù)管理和AI-Pipeline引擎 4個(gè)模塊的功能。

3.2 數(shù)據(jù)集管理

經(jīng)過梳理，算法同學(xué)使用的數(shù)據(jù)要么保存在NAS里，要么從ODPS里讀取，或者從OSS上拉取。為了統(tǒng)一數(shù)據(jù)管理，KubeAI以Kubernetes PVC（Persistent Volume Claim）資源為基礎(chǔ)，向用戶提供數(shù)據(jù)集的概念，兼容了不同的數(shù)據(jù)源格式。同時(shí)，為了解決因計(jì)算和存儲(chǔ)分離架構(gòu)帶來的數(shù)據(jù)訪問開銷大的問題，我們使用Fluid為數(shù)據(jù)集配置緩存服務(wù)，既可以將數(shù)據(jù)緩存在本地供下輪迭代計(jì)算使用，也可以將任務(wù)調(diào)度到數(shù)據(jù)集已有緩存的計(jì)算節(jié)點(diǎn)上來。

3.3 模型訓(xùn)練

針對(duì)模型訓(xùn)練，我們主要做了三方面的工作：

（1）以JupyterLab為基礎(chǔ)，提供了Notebook功能，用戶可通過shell或者Web IDE以等同于本地的開發(fā)模式展開算法模型開發(fā)工作。

（2）以任務(wù)的方式進(jìn)行模型訓(xùn)練，能更靈活地申請(qǐng)和釋放資源，提高了資源的使用率，極大降低模型訓(xùn)練的成本?；贙ubernetes良好的擴(kuò)展性，業(yè)內(nèi)各種TrainingJob CRD都可輕松對(duì)接，Tensorflow、PyTorch、xgbost等訓(xùn)練框架均可支持。任務(wù)支持批調(diào)度，支持任務(wù)優(yōu)先級(jí)隊(duì)列。

（3）與算法團(tuán)隊(duì)合作，對(duì)Tensorflow訓(xùn)練框架做了部分優(yōu)化，在批量數(shù)據(jù)讀取效率、PS/Worker間通信速率上取得了一些提升效果；在PS負(fù)載不均衡、慢worker等問題上做了一些解決方案。

3.4 模型服務(wù)管理

模型服務(wù)與普通的服務(wù)相比，最大的特點(diǎn)是服務(wù)需要加載一個(gè)或者多個(gè)模型文件。在容器化的初期，因歷史原因大多CV的模型服務(wù)都是直接將模型文件與推理腳本一起打包到容器鏡像里的，這就導(dǎo)致容器鏡像比較大，模型版本更新繁瑣。

KubeAI改變了上述問題，基于對(duì)模型的規(guī)范化管理，把模型服務(wù)通過配置與模型進(jìn)行關(guān)聯(lián)，發(fā)布時(shí)由平臺(tái)根據(jù)模型配置去拉取相應(yīng)的模型文件，供推理腳本加載。這種方式減輕了算法模型開發(fā)者對(duì)推理服務(wù)鏡像/版本的管理壓力，減少了存儲(chǔ)冗余，提升了模型更新/回滾的效率，提高了模型復(fù)用率，幫助算法團(tuán)隊(duì)更加方便快捷地管理模型及其關(guān)聯(lián)的在線推理服務(wù)。

3.5 AI-Pipeline引擎

實(shí)際的業(yè)務(wù)場景不會(huì)是一個(gè)單一的任務(wù)節(jié)點(diǎn)，比如一個(gè)完整的模型迭代過程大致包含了數(shù)據(jù)處理環(huán)節(jié)、模型訓(xùn)練環(huán)節(jié)、使用新的模型更新在線推理服務(wù)、小流量驗(yàn)證環(huán)節(jié)和正式發(fā)布環(huán)節(jié)。KubeAI平臺(tái)在Argo Workflow的基礎(chǔ)上提供了工作流編排引擎，工作流節(jié)點(diǎn)支持自定義任務(wù)、平臺(tái)預(yù)置模板任務(wù)，以及各種深度學(xué)習(xí)AI訓(xùn)練任務(wù)（TFJob、PyTorchJob等）。

四、AI業(yè)務(wù)場景的在KubeAI上落地典型案例

4.1 CV算法模型開發(fā)流程

CV算法模型的開發(fā)模式一般是邊研究理論算法，邊開發(fā)工程實(shí)踐算法模型，隨時(shí)調(diào)試。因?yàn)槟Ｐ鸵话惚容^小，相比搜推類的模型，訓(xùn)練代價(jià)更低一些，所以CV的同學(xué)更習(xí)慣于在Notebook當(dāng)中開發(fā)好訓(xùn)練腳本以后，直接在Notebook里進(jìn)行訓(xùn)練。用戶可以自主為Notebook選擇配置CPU、GPU卡以及網(wǎng)絡(luò)存儲(chǔ)盤等資源。

通過開發(fā)調(diào)試，訓(xùn)練腳本滿足需求以后，用戶就可以使用KubeAI提供的任務(wù)管理功能，將訓(xùn)練腳本配置為一個(gè)單機(jī)訓(xùn)練任務(wù)，或者分布式訓(xùn)練任務(wù)，提交給KubeAI平臺(tái)去執(zhí)行。平臺(tái)會(huì)調(diào)度任務(wù)到資源充足的資源池進(jìn)行運(yùn)行，在運(yùn)行成功之后將模型推送到模型倉庫，并注冊到KubeAI的模型列表中；或者將模型保存在指定位置，供用戶做選擇和確認(rèn)。

模型產(chǎn)出以后，用戶可以直接在KubeAI的模型服務(wù)管理中將模型部署為推理服務(wù)。后續(xù)有新版本的模型產(chǎn)出時(shí)，用戶可以為推理服務(wù)配置新的模型版本。而后，根據(jù)推理引擎是否支持模型熱更新，可以通過重新部署服務(wù)或者創(chuàng)建模型升級(jí)任務(wù)，來完成推理服務(wù)中模型的升級(jí)。

在機(jī)器鑒別業(yè)務(wù)場景中，通過AI-Pipeline工作流，將上述過程進(jìn)行編排，周期性執(zhí)行模型迭代，模型迭代效率提高65%左右。CV場景接入KubeAI平臺(tái)之后，棄用了以前本地訓(xùn)練的方式，在平臺(tái)上靈活按需獲取資源的方式大大提高了資源使用率；在模型管理、推理服務(wù)管理和模型迭代等方面，研發(fā)效率提高50%左右。

4.2 搜推模型訓(xùn)練任務(wù)從PAI遷移到KubeAI平臺(tái)

相比CV的模型，搜推的模型訓(xùn)練成本較高，主要體現(xiàn)在數(shù)據(jù)樣本大，訓(xùn)練時(shí)間長，單個(gè)任務(wù)需要的資源量大。在KubeAI落地之前，由于我們的數(shù)據(jù)存儲(chǔ)在ODPS（阿里通用計(jì)算平臺(tái)提供的一種數(shù)據(jù)倉庫解決方案，現(xiàn)在已更名為MaxCompute）上，所以搜推的算法同學(xué)基本都在Dataworks（基于ODPS的大數(shù)據(jù)開發(fā)治理平臺(tái)）控制臺(tái)上構(gòu)建數(shù)據(jù)處理任務(wù)，同時(shí)向PAI平臺(tái)提交模型訓(xùn)練任務(wù)。但由于PAI是一款公有云產(chǎn)品，提交給它的單個(gè)任務(wù)成本是要高于任務(wù)本身所需要的資源成本的，高出部分其實(shí)可以理解為技術(shù)服務(wù)費(fèi)；另外，這種公有云產(chǎn)品，對(duì)企業(yè)內(nèi)部的成本管控需求也是無法滿足的。

在KubeAI逐步落地之后，我們將搜推場景在PAI上的模型訓(xùn)練任務(wù)，按照2個(gè)方式逐步遷移到我們的平臺(tái)上。方式1是保持用戶在Dataworks進(jìn)行作業(yè)的習(xí)慣，將一些SQL任務(wù)依然放在Dataworks去完成，然后通過shell命令向KubeAI平臺(tái)提交任務(wù)；方式2是用戶直接向KubeAI平臺(tái)提交任務(wù)。我們期望隨著數(shù)倉基礎(chǔ)設(shè)施的完善，后續(xù)會(huì)逐步完全切成第二種方式。

搜推的模型訓(xùn)練任務(wù)開發(fā)過程，充分使用了KubeAI提供的開發(fā)環(huán)境和工具。通過自研訓(xùn)練工程Framwork，在僅使用CPU的情況下，訓(xùn)練時(shí)長可與在PAI上使用GPU訓(xùn)練的時(shí)長打齊；訓(xùn)練引擎?zhèn)冗€針對(duì)大模型訓(xùn)練、實(shí)時(shí)訓(xùn)練場景做了支持，配合多類型存儲(chǔ)（OSS/文件存儲(chǔ)）方案、模型分發(fā)方案，確保大模型訓(xùn)練任務(wù)的成功率，以及高效率地完成對(duì)在線服務(wù)的模型更新。

在資源調(diào)度和管理上，KubeAI充分使用集群聯(lián)邦、超賣機(jī)制、任務(wù)綁核等技術(shù)手段，逐步將訓(xùn)練任務(wù)使用專有資源池轉(zhuǎn)變?yōu)闉槿蝿?wù)Pod分配彈性資源，調(diào)度到在線資源池、公共資源池。充分利用生產(chǎn)任務(wù)周期性執(zhí)行、開發(fā)任務(wù)白天為主的特點(diǎn)，實(shí)施錯(cuò)峰調(diào)度、差異化調(diào)度（比如：小規(guī)格使用彈性資源，大規(guī)格使用常規(guī)資源等策略）。從近幾個(gè)月的數(shù)據(jù)來看，我們做到了在總的資源增量變化不大的情況下，持續(xù)承接較大幅度的任務(wù)增量。

4.3 基線指標(biāo)預(yù)測場景

這是一個(gè)典型的非算法業(yè)務(wù)場景使用AI的能力。比如，使用Facebook的prophet算法預(yù)測某個(gè)業(yè)務(wù)指標(biāo)基線。KubeAI為這些場景的需求提供了基礎(chǔ)AI能力，解決了他們“想快速驗(yàn)證成熟算法難”的問題。用戶只需將算法模型進(jìn)行工程化的實(shí)現(xiàn)（使用已有最佳實(shí)踐，或者二次開發(fā)），然后制成一個(gè)容器鏡像，在KubeAI上提交一個(gè)任務(wù)，啟動(dòng)執(zhí)行，便可獲取想要的結(jié)果；或者周期性地執(zhí)行訓(xùn)練和推理，獲取基線預(yù)測結(jié)果。

用戶對(duì)任務(wù)所需的計(jì)算資源，或者其它異構(gòu)的資源，按需配置即可使用。當(dāng)前，以線上某業(yè)務(wù)場景的12個(gè)指標(biāo)為例，每天有近2萬次的任務(wù)執(zhí)行，相比以往類似需求的資源成本，KubeAI幫助其節(jié)省近90%的成本，在研發(fā)效率上提升3倍左右。

五、展望

得物在較短的時(shí)間里順利實(shí)現(xiàn)了業(yè)務(wù)的容器化，這一方面得益于越來越成熟的云原生技術(shù)本身，另一方面得益于我們對(duì)自身業(yè)務(wù)場景需求的深入理解，并能針對(duì)性地給出解決方案。KubeAI平臺(tái)就是我們在深入分析算法業(yè)務(wù)場景的痛點(diǎn)需求之后，立足于如何持續(xù)提升AI業(yè)務(wù)場景的工程化效率，提高資源使用率，降低AI模型/服務(wù)開發(fā)門檻而思考構(gòu)建、逐步迭代落地實(shí)現(xiàn)的。

后續(xù)，我們將繼續(xù)在訓(xùn)練引擎優(yōu)化、AI任務(wù)精細(xì)化調(diào)度、彈性模型訓(xùn)練等方面繼續(xù)努力，進(jìn)一步提升AI模型訓(xùn)練和迭代效率，提高資源使用率。