一文讀懂得物雲原生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模型訓練和迭代效率，提高資源使用率。

以上是一文讀懂得物雲原生AI平台-KubeAI的落地實作過程的詳細內容。更多資訊請關注PHP中文網其他相關文章！