隨著大數(shù)據(jù)技術(shù)和人工智能技術(shù)的發(fā)展，越來越多的業(yè)務(wù)場景，如金融風控、在線廣告、商品推薦、智能城市等，采用大量的機器學(xué)習(xí)技術(shù)來提升服務(wù)質(zhì)量和智能決策水平。針對具體的任務(wù)，訓(xùn)練得到模型后，需要將其封裝、部署上線，提供在線推理服務(wù)，解決實際業(yè)務(wù)問題。

本文提出一種分布式機器學(xué)習(xí)模型在線推理系統(tǒng)的完整技術(shù)方案，該系統(tǒng)主要采用CPU/GPU 計算節(jié)點來提供推理任務(wù)的基礎(chǔ)算力，通過Docker容器技術(shù)封裝、打包模型推理任務(wù)，將不同服務(wù)的運行環(huán)境完全隔離，并借助Kubernetes進行服務(wù)編排，提供服務(wù)的分布式容災(zāi)和資源的彈性伸縮功能，同時結(jié)合模型倉庫、容器鏡像倉庫、系統(tǒng)/服務(wù)狀態(tài)監(jiān)控、服務(wù)注冊/訂閱、可視化面板等功能模塊使算法模型與服務(wù)架構(gòu)解耦，使模型的部署上線、更新和管理流程變得簡單，上線效率高、風險低，同時提高預(yù)測服務(wù)的穩(wěn)定性、靈活性和服務(wù)能力。

模型在線推理服務(wù)部署的技術(shù)回顧

1. 現(xiàn)有的技術(shù)方法

將模型部署為在線推理服務(wù)，當前存在以下幾種技術(shù)方法：

① 直接在物理機器上部署。將訓(xùn)練好的模型文件及對應(yīng)的推理代碼借助Flask、Tensorflow Serving等封裝為Web服務(wù)包，拷貝至物理機器，啟動部署。一個物理機器上可能部署一個或多個模型服務(wù)。然后將服務(wù)接口和調(diào)用方式通過文檔的形式提供給模型服務(wù)調(diào)用方法。

② 在虛擬機上部署。先將物理機器通過vmware、virtual box等虛擬化技術(shù)劃分為多個虛擬機，然后將訓(xùn)練好的模型文件及對應(yīng)的推理代碼借助Flask、Tensorflow Serving等封裝為Web服務(wù)包部署至一個或多個虛擬機上。每個虛擬機上一般只部署一個模型服務(wù)，以避免資源沖突。為解決大規(guī)模并發(fā)請求，會啟用多個虛擬機和模型服務(wù)，通過負載均衡技術(shù)將請求流量分轉(zhuǎn)發(fā)至多個機器。最后將統(tǒng)一的對外服務(wù)接口和調(diào)用方式通過文檔的形式提供給模型服務(wù)調(diào)用方法。

2. 現(xiàn)有技術(shù)存在的問題

① 由于機器學(xué)習(xí)模型運行的軟件環(huán)境、依賴基礎(chǔ)庫及版本多樣，不同模型之間存在差異，部署不同的模型都需要搭建一次基礎(chǔ)環(huán)境，存在重復(fù)工作，且可能與模型訓(xùn)練時的環(huán)境不一樣，導(dǎo)致運行異常。

② 直接在物理機器上部署多個機器學(xué)習(xí)模型服務(wù)時，雖然可以通過Conda等工具創(chuàng)建虛擬軟件環(huán)境的方式隔離多個服務(wù)的基礎(chǔ)環(huán)境，但多個服務(wù)之間會存在資源沖突，影響服務(wù)的穩(wěn)定性。另外，服務(wù)均為單實例部署，不能保證模型服務(wù)的高可用性。

③ 在虛擬機上部署同樣存在基礎(chǔ)環(huán)境重復(fù)搭建問題。另外，為應(yīng)對大規(guī)模服務(wù)請求情況，往往配置較高的虛擬機數(shù)量和硬件規(guī)格，而大多數(shù)服務(wù)的調(diào)用量往往會隨著業(yè)務(wù)的漲落而漲落，經(jīng)常出現(xiàn)類似白天高、夜間低的現(xiàn)象，導(dǎo)致硬件資源在調(diào)用量較低期間使用率低，造成資源浪費。

④ 模型推理的準確性由于數(shù)據(jù)分布的漂移在一定時間后需要重新訓(xùn)練模型，更新線上服務(wù)，當前的部署方式需要人工選擇某個版本的模型文件、上傳，替換線上的模型文件，根據(jù)模型服務(wù)封裝方式的不同，可能還需要重啟服務(wù)，導(dǎo)致線上服務(wù)中斷。另外，該更新過程需要人工操作、無法自動化，且過程繁瑣、缺乏統(tǒng)一管理和追蹤，容易出錯。

高可用模型在線推理系統(tǒng)的設(shè)計

1. 總體設(shè)計思路

① 基于容器技術(shù)，通過預(yù)置模型服務(wù)的執(zhí)行環(huán)境和容器鏡像，支持Scikit-learn、Tensorflow、PyTorch、Keras、Caffe、MXNet等多種模型框架和基礎(chǔ)環(huán)境，無需重復(fù)搭建機器學(xué)習(xí)模型運行的軟件環(huán)境。

② 基于開源Kubernetes技術(shù)和自研插件，構(gòu)建Kubernetes集群，對CPU異構(gòu)集群、GPU異構(gòu)集群、Ceph/HDFS存儲服務(wù)等基礎(chǔ)資源進行隔離和合理的分配、調(diào)度，為模型服務(wù)提供高可用的運行時環(huán)境，將計算節(jié)點集群化，提供全系統(tǒng)容災(zāi)保障，無需擔心單點故障。

③ 基于模型在線推理服務(wù)資源的彈性擴縮容方法，基于模型服務(wù)的資源使用率實時監(jiān)控指標和期望資源計算公式進行動態(tài)的擴展或回縮調(diào)整，既保證模型推理服務(wù)的資源需求，又減少資源的閑置浪費。

④ 基于模型自動化的模型篩選方法和策略模板，對線上模型服務(wù)的更新升級方式進行可視化的配置，使過程變得靈活簡單，且減少人工操作。

2. 系統(tǒng)架構(gòu)設(shè)計

高可用模型在線推理系統(tǒng)的架構(gòu)圖如下：

圖1 機器學(xué)習(xí)模型在線推理系統(tǒng)架構(gòu)圖

該系統(tǒng)包含的各功能模塊的設(shè)計以及模塊之間相互協(xié)作關(guān)系如下文所述：

（A）模型在線服務(wù)設(shè)計器：用戶需要將訓(xùn)練好的機器學(xué)習(xí)模型部署為在線服務(wù)、對用戶請求服務(wù)傳遞的數(shù)據(jù)進行推理時，通過該系統(tǒng)可視化界面進行相關(guān)配置。配置內(nèi)容包括：

1）服務(wù)名稱、服務(wù)類型(無狀態(tài)服務(wù)、有狀態(tài)服務(wù))、服務(wù)升級策略等；

2）從（B）模型倉庫中選擇需要部署為在線推理服務(wù)的模型及對應(yīng)的版本；

3）從（C）容器鏡像倉庫中選擇模型在線推理服務(wù)運行的容器鏡像，例如安裝好Scikit-learn、Tensorflow、PyTorch、Keras、Caffe、MXNet等基礎(chǔ)算法庫、依賴包；

4）配置服務(wù)運行所需的硬件資源(CPU/GPU/內(nèi)存/存儲等)的需求范圍和分布式實例的數(shù)量范圍；

5）模型在線推理服務(wù)的輸入/輸出參數(shù)等等。

（B）模型倉庫：指模型構(gòu)建人員基于不同的框架針對具體機器學(xué)習(xí)任務(wù)訓(xùn)練好的模型文件及模型元數(shù)據(jù)信息的管理倉庫，提供模型的版本管理、模型元數(shù)據(jù)信息的預(yù)覽對比、模型的多維度分類、排序、搜索等功能。可將模型倉庫的任意版本模型部署為批量離線服務(wù)或?qū)崟r在線服務(wù)或發(fā)布到模型交易市場。

（C）容器鏡像倉庫：主要提供模型訓(xùn)練、模型推理任務(wù)等的容器鏡像及鏡像管理，包括不同硬件平臺(CPU/GPU服務(wù)器等)上算法模型運行所需的基礎(chǔ)算法庫、依賴包等軟件環(huán)境。在（A）模型在線服務(wù)設(shè)計器中設(shè)計具體模型在線推理任務(wù)時選擇相應(yīng)的容器鏡像即可，無需運維重新搭建運行環(huán)境。

（D）模型微服務(wù)引擎：根據(jù)用戶在（A）模型在線服務(wù)設(shè)計器中的具體配置，（E）Kubernetes集群調(diào)度器依據(jù)服務(wù)的計算規(guī)格配置，利用節(jié)點選擇器將模型服務(wù)調(diào)度到指定的目標計算節(jié)點上，然后從（B）模型倉庫中拉取用戶配置模型文件和對應(yīng)的模型元數(shù)據(jù)信息以及從（C）容器鏡像倉庫中拉取用戶配置的模型推理服務(wù)運行的容器鏡像到目標節(jié)點，通過Service WrApper模塊將模型算法自動封裝為可容器化運行的模型推理服務(wù)，最后啟動引擎對外提供服務(wù)。（D）模型微服務(wù)引擎與（E）Kubernetes集群協(xié)同配合。

（E）Kubernetes集群：指基于開源的Kubernetes和自研適用于機器學(xué)習(xí)場景的調(diào)度插件搭建的生產(chǎn)級別的容器編排系統(tǒng)，用于對（D）模型微服務(wù)引擎中的模型推理服務(wù)及其配套的資源進行管理。

基于容器技術(shù)、自研調(diào)度編排技術(shù)對（F）基礎(chǔ)設(shè)施中CPU異構(gòu)集群、GPU異構(gòu)集群、Ceph/HDFS存儲服務(wù)等基礎(chǔ)資源進行合理的分配和調(diào)度，為模型服務(wù)提供高可用的運行時環(huán)境。通過標簽的方式來管理CPU/GPU異構(gòu)集群中的計算節(jié)點，即將不同的計算節(jié)點劃分為不同的可用區(qū)或組。

在部署模型在線服務(wù)時，使用節(jié)點選擇器將模型在線服務(wù)部署至帶有指定標簽的目標計算節(jié)點上。為了保證高可用，每個標簽組合的目標計算節(jié)點數(shù)大于1。從而避免一臺目標節(jié)點宕機后，調(diào)度器還能找到滿足條件的計算節(jié)點將宕機節(jié)點上的在線服務(wù)對應(yīng)的容器遷移到其它計算節(jié)點上，從而保證模型在線服務(wù)的高可用性。

（F）基礎(chǔ)設(shè)施：包括CPU異構(gòu)集群、GPU異構(gòu)集群、Ceph/HDFS存儲服務(wù)等，為模型推理服務(wù)提供基礎(chǔ)的硬件資源。

（G）模型服務(wù)管理：包括模型在線推理服務(wù)的服務(wù)發(fā)布、服務(wù)注冊、服務(wù)發(fā)現(xiàn)、服務(wù)上下線、服務(wù)重啟、服務(wù)版本管理等。

（H）壓力測試/在線服務(wù)：指將部署上線的模型推理服務(wù)進行壓力測試或開發(fā)給需求方提供模型推理服務(wù)的功能模塊。壓力測試提供json、數(shù)據(jù)文件、并發(fā)請求三種方式對部署的模型推理服務(wù)進行長時間或滿負荷的運行測試，并生成服務(wù)的性能、可靠性、穩(wěn)定性報告；在線服務(wù)是指將模型推理服務(wù)的API接口、調(diào)用方式及反饋狀態(tài)相關(guān)說明暴露出來，供內(nèi)、外網(wǎng)請求服務(wù)。服務(wù)請求經(jīng)由（I）負載均衡器分發(fā)到（D）模型微服務(wù)引擎中的各個模型服務(wù)實例中。

（I）負載均衡器：為每個模型推理在線服務(wù)提供自動負載均衡能力，即將（H）壓力測試/在線服務(wù)中產(chǎn)生大規(guī)模請求流量通過負載均衡算法將請求分配到各個計算節(jié)點的容器實例中。負載均衡算法采用隨機法、輪詢法、原地址哈希法、加權(quán)輪詢法、最小連接數(shù)法等。

（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊：對每個模型服務(wù)推理的準確性指標(如面向分類模型的精確率、召回率、F1值、AUC等和面向回歸模型的MSE、RMSE、MAE等)、模型推理服務(wù)的使用情況以及資源的使用狀態(tài)進行全方位的采集、存儲，并進行不同時間粒度的匯總計算，主要的監(jiān)控指標包括CPU使用率、GPU使用率、內(nèi)存使用率、占用存儲空間、上下行流量、服務(wù)請求數(shù)量、服務(wù)調(diào)用失敗/成功數(shù)量、服務(wù)響應(yīng)時延等，并計算反應(yīng)模型服務(wù)性能穩(wěn)定性和可靠性的衍生指標，如TP99、TP9999等。該部分信息一方面是（K）監(jiān)控面板上進行可視化的基礎(chǔ)，另一方面也會反饋給（E）Kubernetes集群，用于指導(dǎo)資源的分配調(diào)度和服務(wù)的編排。

（K）監(jiān)控面板：將（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊中采集、計算的指標進行可視化，方便用戶了解模型在線推理服務(wù)的狀態(tài)。

3. 模型自動篩選與更新流程

機器學(xué)習(xí)模型往往會隨著時間的推移進行迭代更新，為保障模型在線推理服務(wù)的準確性，需對其進行即時的升級。本文提出一種模型自動化的模型篩選方法和策略，以減少人工操作。具體流程如圖2所示。

圖2 模型自動篩選、更新流程示意圖

用戶根據(jù)系統(tǒng)提供的多種篩選策略模板，進行策略配置以初始化模型篩選器，模型篩選器對（B）模型倉庫中的每個模型及其不同版本的元信息進行檢測，篩選出符合策略所定義要求的模型文件，然后由（D）模型微服務(wù)引擎對模型在線推理服務(wù)在合適的時段(如（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊監(jiān)測到的服務(wù)調(diào)用量較低的時段或用戶自定義的時段)進行更新。

具體地，本文提出以下5種模型篩選策略模板：

① 由上游數(shù)據(jù)驅(qū)動的模型更新，即篩選出該驅(qū)動事件對應(yīng)的模型；

② 模型推理準確性指標下降或低于一定閾值事件驅(qū)動的模型更新，即篩選出該驅(qū)動事件對應(yīng)的模型，模型推理準確性指標由（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊監(jiān)測模塊反饋，見圖1；

③ 定期從當前眾多版本中篩選出模型性能評估指標(可以是用戶定義的加權(quán)指標，下同)最優(yōu)的一個模型；

④ 定期從當前眾多版本中篩選出模型性能評估指標在一定閾值之上的最新迭代的一個模型；

⑤ 人工手動指定的模型版本。

4. 資源彈性擴縮容方法

大多數(shù)模型在線推理服務(wù)的調(diào)用量往往會隨著業(yè)務(wù)的漲落而漲落，經(jīng)常出現(xiàn)類似白天高、夜間低的服務(wù)請求量波動現(xiàn)象，一方面導(dǎo)致硬件資源在調(diào)用量較低期間使用率低，造成資源浪費，另一方面當用量過大時可能影響服務(wù)的穩(wěn)定性和可用性。本文提出一種模型服務(wù)資源的彈性擴縮容方法，既保證模型推理服務(wù)的資源需求，又減少資源的閑置浪費。具體流程如圖3所示。

圖3 模型服務(wù)資源彈性擴縮容流程示意圖

當模型在線推理服務(wù)成功部署上線后，（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊實時監(jiān)測、計算該服務(wù)各容器實例的資源使用率等指標，如CPU使用率、GPU使用率、內(nèi)存使用率、響應(yīng)時延等，并進行不同時間粒度的匯總計算。

對上一個時間窗口內(nèi)資源使用率指標，采用本文提出的容器實例數(shù)量計算公式或用戶定義自定義的公式進行計算，得到下一個時間窗口內(nèi)期望的容器實例數(shù)量，然后借助Kubernetes中的橫向自動擴縮容的功能（HorizontalPod Autoscaling，簡稱 HPA），自動化地調(diào)整容器實例數(shù)量，然后（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊繼續(xù)實時監(jiān)控更新后各容器實例的資源使用率等指標，以此循環(huán)，實現(xiàn)模型在線推理服務(wù)資源的動態(tài)調(diào)整。

期望的容器實例數(shù)量計算公式如下所示：

式中，分別為CPU使用率、GPU使用率、內(nèi)存使用率、響應(yīng)時延4個衡量維度的權(quán)重因子，取值范圍為[0,1],總和為1，用戶可自行調(diào)整，也可以調(diào)整時間窗口的大小。ceil表示向下取整。另一方面，用戶也可以基于（J）系統(tǒng)/服務(wù)狀態(tài)監(jiān)控模塊提供的其他指標完全自定義期望的容器實例數(shù)量計算公式。

總 結(jié)

1、本文提出了一種分布式機器學(xué)習(xí)模型在線推理系統(tǒng)的完整技術(shù)方案，通過Docker容器技術(shù)封裝、打包模型推理任務(wù)，將不同服務(wù)的運行環(huán)境完全隔離，并借助Kubernetes進行服務(wù)編排，提供服務(wù)的分布式容災(zāi)和資源的彈性伸縮功能，同時結(jié)合模型倉庫、容器鏡像倉庫、系統(tǒng)/服務(wù)狀態(tài)監(jiān)控、服務(wù)注冊/訂閱、可視化面板等功能模塊使算法模型與服務(wù)架構(gòu)解耦，使模型的部署上線、更新和管理流程變得簡單，上線效率高、風險低，同時提高預(yù)測服務(wù)的穩(wěn)定性、靈活性和服務(wù)能力。

2、本文提出了一種模型自動化的模型篩選方法和策略，提出了5種模型篩選策略模板，使線上模型服務(wù)的更新升級變得靈活簡單，且減少了人工操作。

3、本文提出了一種模型在線推理服務(wù)資源的彈性擴縮容方法，基于模型服務(wù)的資源使用率實時監(jiān)控指標和期望資源計算公式進行動態(tài)調(diào)整，既保證了模型推理服務(wù)的資源需求，又減少了資源的閑置浪費。【END】

招聘研發(fā)/算法工程師

KuAI平臺是京東數(shù)科中臺建設(shè)的重要平臺之一，提供從模型開發(fā)、訓(xùn)練到部署、監(jiān)控的一站式服務(wù)，幫助用戶快速構(gòu)建、部署模型，并實現(xiàn)機器學(xué)習(xí)工作流全生命周期管理。

KuAI團隊廣納賢才，歡迎對AI平臺建設(shè)感興趣，具有AI平臺系統(tǒng)架構(gòu)、K8S容器平臺開發(fā)或算法方面經(jīng)驗的同學(xué)加入。