一、前言

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

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

二、AI業務的容器化推進

2.1 AI算法模型開發流程

AI業務更多的是針對模型的迭代開發過程，通常模型的開發過程可以歸納為以下幾個步驟：

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

數據準備：按照場景需求分析的結果，通過各種方式（線上/線下/mock等）獲取樣本數據，對數據做必要的清洗、標注等操作。這個過程是AI業務開發的基礎，因為后續的所有過程都是在數據的基礎上進行的。

確定算法，編寫訓練腳本：基于對業務目標的理解，在這個環節算法同學會根據過往的經驗，或者針對該場景調研、實驗結果，選擇合適的算法，編寫模型訓練腳本。

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

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

模型部署：通過反復的訓練和評估，得到較為理想的模型之后就可以幫助業務去處理在線/生產數據了。這就需要把模型以服務的形態，或者以任務的形態部署起來，以達到接受輸入數據，給出推理結果的目的，我們把這個服務稱之為模型服務。模型服務是一個在線服務腳本對模型進行加載，就緒以后，對預處理之后的數據進行推理計算。

一個模型服務上線之后，會隨著數據特征的變更、算法的升級、在線推理服務腳本的升級、業務對推理指標的新要求等情況，需要對模型服務進行迭代。需要注意的是，這個迭代過程，有可能需要對模型進行重新訓練、重新評估；也有可能只是推理服務腳本的迭代升級。

2.2 如火如荼的容器化遷移

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

在CI過程中，根據不同的開發語言類型，定制不同的編譯構建模板，從源碼編譯再到容器鏡像制作，由容器平臺層統一完成，解決了普通研發同學因對容器相關知識不了解而無法將工程代碼制成一個容器鏡像的問題。在CD過程中，我們在應用類型級別、環境級別、環境組級別進行配置分層管理，執行部署時將多層配置合并成Helm Chart的values.yaml，向容器集群提交編排文件。用戶只需根據自己實際需求，設置相應的環境變量，即可提交部署，而后獲取應用集群實例（容器實例，類似于ECS服務實例）。

針對應用集群的運維操作，容器平臺提供WebShell登陸容器實例的功能，就像登陸到ECS實例一樣，便于排查應用進程相關問題；容器平臺也提供了文件的上傳和下載、實例的重啟和重建、資源監控等運維功能。

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

2.3 算法同學不能承受之痛

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

痛點1：模型的管理和推理服務的管理是不連貫的。CV的模型大多是在臺式機上訓練的，然后手動上傳到OSS上，然后將模型文件在OSS上的地址配置給在線推理服務。搜推的模型大多是在PAI上進行訓練，但是也是手動存儲在OSS上，發布時與CV的類似。可以看到，對模型這個產物的管理，在模型訓練和發布的過程中是不連貫的，無法追蹤一個模型到底部署在了哪幾個服務上，也沒法直觀看到一個服務部署了哪一個或者多個模型，模型版本管理不方便。

痛點2：模型開發環境準備耗時長，資源申請和使用缺少彈性機制。在容器化之前，資源一般以ECS實例的方式提供，要走流程申請資源，申請到以后要做各種初始化工作，安軟件，裝依賴，傳數據（算法研究工作使用的軟件庫大多體積較大，安裝也較復雜）。當一臺ECS搞定以后，后續如果資源不夠要再申請，相同的流程再走一遍，效率較低。同時，資源的申請在配額（預算）的約束下，缺少自主管理、按需彈性申請和釋放的機制。

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

痛點4：非算法部門想快速驗證一個算法時找不到可以很好支撐的平臺。AI的能力顯然在各個業務域都會用到，特別是一些成熟的算法，業務團隊可以很輕松地用它來做一些基線指標預測，或者分類預測工作，以便幫助業務取得更好的效果。這時就需要有一個能提供AI相關能力的平臺，滿足這些場景對異構資源（CPU/GPU/存儲/網絡等）的需求，對算法模型管理等需求，為用戶提供上手即用的功能。

立足于對以上痛點和難點問題的梳理和分析，同時基于容器化過程中算法同學對容器平臺提出的其它需求（比如：模型統一管理需求、日志采集需求、資源池需求、數據持久化需求等），我們逐一討論，各個擊破，在解決當前問題的同時，也考慮平臺長遠的功能規劃，逐步建成了以容器平臺為基礎，面向AI業務的KubeAI平臺解決方案。

三、KubeAI平臺解決方案

在充分調研和學習了業內AI平臺的基本架構、產品形態的基礎上，著眼于AI業務場景及其周邊業務需求，容器技術團隊在得物容器化過程中設計和逐步落地了云原生AI平臺-KubeAI平臺。KubeAI平臺著力于解決算法同學的痛點需求，提供必要的功能模塊，貫穿模型的開發、發布和運維流程，幫助算法開發者快速、低成本地獲取和使用AI基礎設施資源，快速高效地進行算法模型設計、開發和實驗。

3.1 整體架構

KubeAI平臺圍繞模型的整個生命周期，提供了以下功能模塊：

數據集管理：主要是對不同的數據源進行兼容，此外提供了數據緩存加速能力。

模型訓練：既提供了Notebook進行模型開發和訓練，又支持對一次性/周期性任務進行管理；這個流程中對異構資源（CPU/GPU/存儲）彈性申請和釋放。

模型管理：對模型元數據（模型基本信息，版本列表等）進行統一管理，與模型服務發布、運維過程無縫銜接。

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

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

KubeAI平臺不僅支持個人用戶，也支持平臺用戶。個人開發者同學使用KubeAI的Notebook進行模型腳本開發，較小的模型可直接在Notebook中進行訓練，復雜模型通過任務的方式進行訓練。模型產出后在KubeAI上進行統一管理，包括發布為推理服務，以及新版本的迭代。第三方業務平臺以OpenAPI的方式獲取KubeAI的能力進行上層業務創新。

下面我們重點介紹下數據集管理、模型訓練、模型服務管理和AI-Pipeline引擎 4個模塊的功能。

3.2 數據集管理

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

3.3 模型訓練

針對模型訓練，我們主要做了三方面的工作：

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

（2）以任務的方式進行模型訓練，能更靈活地申請和釋放資源，提高了資源的使用率，極大降低模型訓練的成本。基于Kubernetes良好的擴展性，業內各種TrainingJob CRD都可輕松對接，Tensorflow、PyTorch、xgbost等訓練框架均可支持。任務支持批調度，支持任務優先級隊列。

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

3.4 模型服務管理

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

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

3.5 AI-Pipeline引擎

實際的業務場景不會是一個單一的任務節點，比如一個完整的模型迭代過程大致包含了數據處理環節、模型訓練環節、使用新的模型更新在線推理服務、小流量驗證環節和正式發布環節。KubeAI平臺在Argo Workflow的基礎上提供了工作流編排引擎，工作流節點支持自定義任務、平臺預置模板任務，以及各種深度學習AI訓練任務（TFJob、PyTorchJob等）。

四、AI業務場景的在KubeAI上落地典型案例

4.1 CV算法模型開發流程

CV算法模型的開發模式一般是邊研究理論算法，邊開發工程實踐算法模型，隨時調試。因為模型一般比較小，相比搜推類的模型，訓練代價更低一些，所以CV的同學更習慣于在Notebook當中開發好訓練腳本以后，直接在Notebook里進行訓練。用戶可以自主為Notebook選擇配置CPU、GPU卡以及網絡存儲盤等資源。

通過開發調試，訓練腳本滿足需求以后，用戶就可以使用KubeAI提供的任務管理功能，將訓練腳本配置為一個單機訓練任務，或者分布式訓練任務，提交給KubeAI平臺去執行。平臺會調度任務到資源充足的資源池進行運行，在運行成功之后將模型推送到模型倉庫，并注冊到KubeAI的模型列表中；或者將模型保存在指定位置，供用戶做選擇和確認。

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

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

4.2 搜推模型訓練任務從PAI遷移到KubeAI平臺

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

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

搜推的模型訓練任務開發過程，充分使用了KubeAI提供的開發環境和工具。通過自研訓練工程Framwork，在僅使用CPU的情況下，訓練時長可與在PAI上使用GPU訓練的時長打齊；訓練引擎側還針對大模型訓練、實時訓練場景做了支持，配合多類型存儲（OSS/文件存儲）方案、模型分發方案，確保大模型訓練任務的成功率，以及高效率地完成對在線服務的模型更新。

在資源調度和管理上，KubeAI充分使用集群聯邦、超賣機制、任務綁核等技術手段，逐步將訓練任務使用專有資源池轉變為為任務Pod分配彈性資源，調度到在線資源池、公共資源池。充分利用生產任務周期性執行、開發任務白天為主的特點，實施錯峰調度、差異化調度（比如：小規格使用彈性資源，大規格使用常規資源等策略）。從近幾個月的數據來看，我們做到了在總的資源增量變化不大的情況下，持續承接較大幅度的任務增量。

4.3 基線指標預測場景

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

用戶對任務所需的計算資源，或者其它異構的資源，按需配置即可使用。當前，以線上某業務場景的12個指標為例，每天有近2萬次的任務執行，相比以往類似需求的資源成本，KubeAI幫助其節省近90%的成本，在研發效率上提升3倍左右。

五、展望

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

后續，我們將繼續在訓練引擎優化、AI任務精細化調度、彈性模型訓練等方面繼續努力，進一步提升AI模型訓練和迭代效率，提高資源使用率。