徐治理，霍龍社，曹云飛，崔煜喆（中國聯(lián)通研究院，北京 100176）

0 引言

近年來AI技術(shù)取得了革命性的進(jìn)步，算法方面從統(tǒng)計學(xué)習(xí)方法到深度學(xué)習(xí)，算法的廣度、深度不斷擴(kuò)展，豐富度和復(fù)雜度不斷提高［1］。同時，也涌現(xiàn)出一批能提供常用開發(fā)工具的深度學(xué)習(xí)框架，如Tensorflow、Pytorch 等，廣受AI 開發(fā)者歡迎。AI 的應(yīng)用范圍也在不斷擴(kuò)展，從推薦系統(tǒng)到自然語言處理、計算機視覺、語音處理等各個領(lǐng)域都有了成熟的算法和模型［2］。人工智能技術(shù)的關(guān)注點也從提高算法精度、模型性能擴(kuò)展到了怎樣讓其應(yīng)用到實際的生產(chǎn)環(huán)境中。

在人工智能算法模型開發(fā)、訓(xùn)練完成后，需要將其部署到互聯(lián)網(wǎng)云端以便用戶實時訪問。但目前AI模型的封裝和部署還存在較多問題。AI 模型開發(fā)豐富的框架和工具使在生產(chǎn)中配置模型運行環(huán)境非常復(fù)雜，尤其是在需要運行多個模型時，更是會面對工具和版本的各種沖突。AI 模型運行需要較多的計算資源，在實際運行中如何對AI模型服務(wù)占用的資源進(jìn)行靈活的管理和及時的調(diào)度也是亟待解決的問題。AI技術(shù)對很多用戶來說是一個新的領(lǐng)域，對包含AI服務(wù)代碼的開發(fā)和部署需要很多前置知識，找到一種能靈活支持對各種AI 模型進(jìn)行封裝并能實現(xiàn)自動化發(fā)布和部署的技術(shù)具有十分重要的意義。

1 現(xiàn)有AI模型部署技術(shù)

人工智能模型部署方式根據(jù)處理數(shù)據(jù)的實時性，分為離線模型和在線模型［3］。在線模型根據(jù)使用的技術(shù)、適配的框架又分為專用模型部署、通用模型部署等。在線模型部署后的運行管理方式也有很多種，目前最熱門和有發(fā)展前景的就是云原生服務(wù)網(wǎng)格［4］。

1.1 離線模型（Offline Model）部署

離線模型是最簡單的模型部署方式，雖然出現(xiàn)最早但是目前仍被廣泛使用。當(dāng)在業(yè)務(wù)流程中AI 模型處理過程不需要實時完成時，根據(jù)需要隔一段時間運行一次。離線模型對處理數(shù)據(jù)的時效性要求較低，所以對部署條件和實現(xiàn)的性能的要求比較寬松，也沒有固定的部署模式，甚至可以將訓(xùn)練好的模型直接拿來使用，也是最早的AI模型使用方式。

1.2 在線模型（Online Model）部署

1.2.1 模型封裝

將算法工程師訓(xùn)練好的模型重構(gòu)或繼續(xù)開發(fā)成一個網(wǎng)絡(luò)服務(wù)是在企業(yè)中比較常見的上線方式［5］。模型服務(wù)通過常用開發(fā)框架封裝為一個后端服務(wù)，提供http 端口對外提供服務(wù)。應(yīng)用中提前將訓(xùn)練好的模型加載，通過消息中間件將待預(yù)測數(shù)據(jù)傳入接口進(jìn)行推斷得到最終結(jié)果。這種處理模型的方式每次部署新模型都需要在服務(wù)器中重新配置AI模型運行環(huán)境，每次模型的部署都帶來大量重復(fù)工作。

部分機器學(xué)習(xí)框架提供了模型服務(wù)工具，模型訓(xùn)練完成后直接使用工具將其封裝為一個服務(wù)。比如Google提供了Tensorflow Serving，直接利用模型開發(fā)配置好的環(huán)境以docker 形式封裝，對外提供Restful API［6］。但框架提供的Serving 工具兼容性很差，不同框架需要手動轉(zhuǎn)換文件類型，對于其他框架獨有的算子不能提供支持。

1.2.2 模型部署

對于封裝好的模型可以直接部署在服務(wù)器中，但這種方式難以進(jìn)行靈活的資源管理和調(diào)度，對于AI模型這種需要占用大量算力資源的服務(wù)，需要更靈活和自動化的方式進(jìn)行管理，云原生和服務(wù)網(wǎng)格則是當(dāng)前熱門的研究方向。

1.3 云原生和服務(wù)網(wǎng)格技術(shù)

云原生是一種構(gòu)建和運行程序的方法，被設(shè)計在云平臺上運行，充分發(fā)揮其彈性和分布式的優(yōu)勢［7］。云原生計算基金會（Cloud Native Computing Foundatio），給出了云原生應(yīng)用的三大特征：容器化封裝、動態(tài)和自動化管理、面向微服務(wù)［8］?；贑NCF 云原生技術(shù)開發(fā)的應(yīng)用，能夠在使用這一技術(shù)架構(gòu)的平臺上實現(xiàn)暢通無阻的部署。云原生技術(shù)以容器的形式部署微服務(wù)并進(jìn)行管理，基于微服務(wù)架構(gòu)提高靈活性和可維護(hù)性，借助敏捷方法、DevOps 支持持續(xù)迭代和運維自動化，利用云平臺設(shè)施實現(xiàn)彈性伸縮、動態(tài)調(diào)度、優(yōu)化資源利用率［9］。非常適合作為AI 模型的部署方式。

服務(wù)網(wǎng)格是指用于微服務(wù)應(yīng)用的可配置基礎(chǔ)架構(gòu)層（configurable infrastructure layer），負(fù)責(zé)處理微服務(wù)間復(fù)雜的服務(wù)請求［10］。通常，服務(wù)網(wǎng)格使用一系列的輕量級網(wǎng)絡(luò)代理來實現(xiàn)，網(wǎng)絡(luò)代理和應(yīng)用代碼分別部署。使用服務(wù)網(wǎng)格能為云原生帶來以下4個方面的好處：業(yè)務(wù)邏輯與分布式架構(gòu)完全解耦、一體化的鏈路管理、彈性伸縮能力和動態(tài)化鏈路管理；在安全上服務(wù)網(wǎng)格提供透明的認(rèn)證機制、通道加密、服務(wù)訪問授權(quán)等安全能力；為運維人員提供強大的調(diào)用鏈；監(jiān)控和調(diào)用日志收集輸出的能力［11］。

2 AI模型接口封裝和打包

為了幫助AI 模型開發(fā)者簡單、快速、自動化地實現(xiàn)模型部署，本文提出了一種基于云原生服務(wù)網(wǎng)格的AI 模型部署方案。模型開發(fā)者完成訓(xùn)練的模型一般由模型參數(shù)文件與模型運行控制代碼2 個部分組成，模型參數(shù)文件存儲了訓(xùn)練好的AI模型結(jié)構(gòu)和參數(shù)，運行代碼控制模型的加載和啟動并包含調(diào)用AI 模型的接口方法。AI 模型的基本工作流程為調(diào)用模型接口方法，輸入?yún)?shù)為符合模型需要的特征數(shù)據(jù)，返回模型執(zhí)行推斷過程后的結(jié)果。

本文重點解決的問題就是將AI 模型代碼中的直接調(diào)用AI 模型的接口方法轉(zhuǎn)換成在云平臺上能供用戶調(diào)用的Restful API。為了實現(xiàn)該目的，本方案設(shè)計了3個步驟：模型打包、微服務(wù)鏡像生成和模型部署運行。模型打包是為后續(xù)模型微服務(wù)生成做準(zhǔn)備，需要由開發(fā)者使用撰寫打包腳本調(diào)用模型打包工具在本地完成。

2.1 模型打包腳本

將AI 模型的模型參數(shù)文件和運行文件看作一個整體，對外提供模型推斷接口。模型開發(fā)者撰寫模型打包代碼，打包代碼一般選擇對不同語言兼容性較好腳本語言，方便調(diào)用不同框架下開發(fā)的AI 模型的接口。

打包腳本會根據(jù)業(yè)務(wù)需要聲明模型將要對外提供Restful API 服務(wù)的接口方法，明確聲明方法的函數(shù)名、參數(shù)類型和個數(shù)，以及返回值類型。下面為一個偽代碼接口聲明示例：

from AI_model import predict # 導(dǎo)入AI 模型中的predict方法

def function（para1：num，para2：List［str］）→str：#聲明封裝方法的名稱、參數(shù)和返回值

return predict（para1，para2）# 調(diào)用AI 模型的predict方法

聲明的方法調(diào)用AI 模型提供的接口，完成對AI模型接口的二次封裝。二次封裝所寫的服務(wù)接口方法根據(jù)AI 模型微服務(wù)部署后所提供的服務(wù)的邏輯開發(fā)，將會在微服務(wù)部署后被內(nèi)部的模型運行器調(diào)用。

對于打包腳本中服務(wù)邏輯的開發(fā)，當(dāng)邏輯復(fù)雜時應(yīng)單獨寫在另一個代碼文件中，將其稱為模型服務(wù)腳本，模型服務(wù)腳本處于AI模型文件和打包腳本中間的位置，完成AI 模型方法接口更上層的業(yè)務(wù)邏輯開發(fā)，進(jìn)一步將打包過程和服務(wù)邏輯解耦。在模型服務(wù)腳本中也能完成數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換，將模型打包腳本中定義的接口參數(shù)數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換為AI 模型接口所需要的數(shù)據(jù)結(jié)構(gòu)。

2.2 服務(wù)接口方法實例化

運行腳本會調(diào)用模型打包工具，打包工具中定義了服務(wù)接口的類，并將所有二次封裝的接口實例化為服務(wù)接口類對象。模型打包工具首先運行服務(wù)接口方法實例化過程。實例化過程首先處理模型的參數(shù)等屬性。每個二次封裝的接口方法服務(wù)類中的屬性包括了接口方法名稱、接收參數(shù)的類型和個數(shù)、返回值類型，以及其中直接或間接調(diào)用的所有函數(shù)對象。

圖1給出了調(diào)用樹結(jié)構(gòu)示意。

模型打包工具首先讀取二次封裝的方法，獲取方法屬性信息，驗證方法的定義代碼完整包含服務(wù)類的各個屬性。對于傳遞的參數(shù)類型，接口為了保證通用性，要求只能使用基本數(shù)據(jù)類型，不能傳遞用戶自己定義的類實例。服務(wù)類接口方法的參數(shù)會保存在模型基本信息文件中，供后續(xù)模型管理工具調(diào)用。

圖1 調(diào)用樹結(jié)構(gòu)示意圖

最后將得到的服務(wù)接口方法對象保存進(jìn)文件。模型打包工具獲取運行當(dāng)前腳本和服務(wù)接口方法需要加載的上下文信息，將其和實例化的服務(wù)接口對象和相關(guān)上下文序列化，序列化是將對象轉(zhuǎn)換為字節(jié)流的過程，序列化的對象被寫入二進(jìn)制文件中保存。采用序列化的方式傳遞對象。

用戶在模型打包過程中需要編寫模型運行依賴列表，模型打包工具會將其保存為文件添加到模型打包文件中，用來在微服務(wù)鏡像生成過程中配置環(huán)境。模型打包工具在解析模型服務(wù)接口聲明時，也會將模型名、服務(wù)接口方法名等記錄下來保存在模型屬性文件中。模型打包工具會分4 個部分保存模型文件，生成模型壓縮包，最后得到模型打包文件目錄，其中包括AI 模型代碼、接口服務(wù)實例文件、模型環(huán)境配置文件和模型屬性文件，打包過程示意圖如圖2所示。

通過模型打包，盡可能地降低不同模型之間的差異性，在接口層面實現(xiàn)統(tǒng)一，為后續(xù)利用統(tǒng)一的基礎(chǔ)鏡像和模型運行器完成模型微服務(wù)鏡像生成提供基礎(chǔ)。

3 AI模型微服務(wù)鏡像生成及部署

3.1 微服務(wù)鏡像生成

模型打包過程已經(jīng)完成了模型接口和文件的標(biāo)準(zhǔn)化，所以微服務(wù)鏡像生成過程將通過代碼自動完成。新的模型微服務(wù)鏡像由安裝了模型運行器的Linux 鏡像作為基礎(chǔ)鏡像，每個AI 模型微服務(wù)鏡像都基于基礎(chǔ)鏡像，再向上添加新層組建生成。

圖2 模型打包過程示意圖

微服務(wù)鏡像生成代碼調(diào)用容器接口API，執(zhí)行鏡像生成流程。首先將AI 模型文件和二次封裝接口實例文件拷貝到鏡像中。然后根據(jù)環(huán)境配置文件，使用對應(yīng)的包管理工具配置AI模型和接口腳本運行環(huán)境。封裝好的模型微服務(wù)將通過鏡像倉庫統(tǒng)一管理。

3.2 模型部署

AI 模型提供服務(wù)在生產(chǎn)中存在的一個很大問題就是服務(wù)的實時性不能保證，從數(shù)據(jù)傳輸?shù)侥Ｐ屯茢嘤嬎?，各個環(huán)節(jié)都會帶來延遲?；谠圃?wù)網(wǎng)格的部署方案的跨平臺特性，能讓模型部署在靠近調(diào)用來源的邊緣云MEC 節(jié)點上，盡可能地減小通信成本。而彈性擴(kuò)縮容的特性，讓容器管理平臺在出現(xiàn)大量并發(fā)服務(wù)請求時能及時作出反應(yīng)，部署更多的微服務(wù)容器，更快速地處理請求。

AI 模型微服務(wù)部署于云原生容器堆棧中，實現(xiàn)根據(jù)生產(chǎn)環(huán)境需要對AI 模型的動態(tài)部署、持續(xù)交付；利用云平臺控制部署的AI模型服務(wù)彈性伸縮，充分利用算力資源，節(jié)約運行成本。云原生也為模型的部署提供了優(yōu)秀的跨平臺屬性，解決了跨平臺部署的可移植問題，通過服務(wù)網(wǎng)格動態(tài)管理，實現(xiàn)AI模型發(fā)布、部署的高度自動化。

3.3 模型運行器

打包腳本和模型運行器實現(xiàn)一個“打包—解包”的過程。經(jīng)由打包腳本生成的格式化后的AI模型，由模型運行器恢復(fù)、加載、調(diào)用，對外提供服務(wù)。

模型運行器是使用Web 框架開發(fā)的實現(xiàn)Restful API 的一個應(yīng)用，在模型微服務(wù)鏡像被部署后運行該應(yīng)用對外提供服務(wù)。該應(yīng)用對外接收外部用戶請求，接收用戶發(fā)來的待處理數(shù)據(jù)；驗證被請求的模型方法是否存在，接受的數(shù)據(jù)是否符合接口要求；對內(nèi)調(diào)用模型方法。模型運行完成后，模型運行器將處理結(jié)果返回。

模型運行器獲取調(diào)用AI 模型接口的過程分為2個部分，首先模型運行器讀取打包文件中記載了模型服務(wù)接口列表的模型屬性文件，使用模板引擎生成配置文件。在建立Web 應(yīng)用時，讀取生成的模板引擎，生成對不同模型服務(wù)Restful API的路由。然后獲取服務(wù)接口的具體操作邏輯。模型運行器中導(dǎo)入了和模型打包工具相同的模型接口定義類，在讀取保存模型接口實例列表的文件后，將二進(jìn)制數(shù)據(jù)反序列化，恢復(fù)類實例，從而獲得服務(wù)接口列表和每個接口的參數(shù)、返回值屬性。既實現(xiàn)了不修改運行器代碼即可調(diào)用AI 模型方法，又提高安全性，防止了容器內(nèi)的AI 模型調(diào)用邏輯的篡改。模型運行器對外開放Restful API接口，將服務(wù)端口映射出來，接收外部對AI 模型微服務(wù)的請求。因為恢復(fù)了接口實例，這些方法實例的調(diào)用棧最終指向AI 模型提供的接口，將AI 模型文件拷貝進(jìn)模型鏡像中，AI 模型文件與模型運行器相對路徑必須要與模型打包過程中AI 模型和封裝腳本的相對路徑相同，通過接口實例即可調(diào)用鏡像中模型文件?；謴?fù)后的微服務(wù)鏡像內(nèi)調(diào)用過程如圖3所示。

用戶發(fā)送的http請求json格式的請求示例如下。

圖3 模型運行器功能示意圖

請求頭中說明了請求體中數(shù)據(jù)的編碼方式和模型微服務(wù)返回推斷結(jié)果時結(jié)果數(shù)據(jù)的編碼方式，請求體為對應(yīng)格式的數(shù)據(jù)。請求體可以使用protobuf 等其他編碼方式，需要在運行器代碼中添加對應(yīng)的編解碼代碼和工具即可。

3.4 模型運行

微服務(wù)鏡像部署后，內(nèi)部的模型運行器啟動，加載接口實例二進(jìn)制文件，獲取當(dāng)前運行模型的所有接口信息，實現(xiàn)對模型提供的各個推斷方法的調(diào)用。AI模型服務(wù)啟動后，生產(chǎn)環(huán)境其他服務(wù)即可訪問接口、發(fā)送特征數(shù)據(jù)調(diào)用AI 模型進(jìn)行推理，過程如圖4 所示。

4 結(jié)論

為了解決AI 模型在互聯(lián)網(wǎng)生產(chǎn)環(huán)境中的自動化部署問題，本文提出了基于云原生服務(wù)網(wǎng)格的AI模型微服務(wù)化和跨平臺部署方案，其主要包括模型打包、微服務(wù)生成和AI 模型微服務(wù)部署與運行。該方案主要技術(shù)點已經(jīng)在中國聯(lián)通CubeAI 智立方AI 應(yīng)用共享與能力開放平臺（https：//cubeai.dimpt.com）的開發(fā)和運營中得到了實施與驗證，證實了技術(shù)可行性和實用性的代碼已經(jīng)全棧開源。CubeAI 平臺實現(xiàn)了對絕大多數(shù)AI 開發(fā)框架的支持，已經(jīng)部署上線AI 模型50 多個，涵蓋運維網(wǎng)優(yōu)、營銷客服、人臉識別、圖像處理、自然語言處理等領(lǐng)域，將持續(xù)賦能中國聯(lián)通智能網(wǎng)絡(luò)和創(chuàng)新業(yè)務(wù)。