一文讀懂得物雲原生AI平臺--KubeAI的落地實踐過程

　　 一、前言

　　在過去的幾年中，以容器技術為代表的雲原生領域受到了極大的關注和發展，容器化的落地是企業降本增效的一個重要手段，截止目前得物已基本完成了全域的容器化。容器化過程中，一方面平穩地將服務的部署和運維方式從以前的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模型訓練和迭代效率，提高資源使用率。