KubeCon 演講實(shí)錄|通過功能化調(diào)度和RDMA加速無服務(wù)器AI大模型推理

近日,由Linux基金會(huì)、云原生計(jì)算基金會(huì)(CNCF)主辦的云原生頂級(jí)盛會(huì)KubeCon+CloudNativeCon+Open Source Summit+China AI_dev 2024成功舉辦,浪潮云海高級(jí)軟件工程師王成龍受邀出席會(huì)議,發(fā)表《通過功能化調(diào)度和RDMA加速無服務(wù)器AI大模型推理》主題演講,以下為議題要點(diǎn)實(shí)錄。

1前言:今年是Kubernetes發(fā)展的十周年,在這十年里Kubernetes已經(jīng)成為云原生的事實(shí)標(biāo)準(zhǔn),根據(jù)云原生計(jì)算基金會(huì)(CNCF)調(diào)查報(bào)告,在2023年全球84%用戶在生產(chǎn)中使用或計(jì)劃使用Kubernetes,這更加鞏固了其在云原生的技術(shù)地位。

與此同時(shí),以ChatGPT為代表的AIGC技術(shù)也在迅猛地發(fā)展,將人們對(duì)AI期待推向一個(gè)新的高峰。從CNCF發(fā)布的云原生AI白皮書中我們看到,人工智能已經(jīng)形成上云趨勢(shì),越來越多的AI應(yīng)用正在借助Kubernetes強(qiáng)大的容器編排能力來提高開發(fā)和部署效率,容器和 Serverless 技術(shù)將成為未來 AI 應(yīng)用開發(fā)的主要平臺(tái)。

2KServe:簡化模型管理,推動(dòng)云原生AI應(yīng)用落地

2.1KServe架構(gòu)解析

KServe作為Kubernetes上的模型推理平臺(tái),成為簡化和加速機(jī)器學(xué)習(xí)模型部署、管理的重要工具。KServe最初是從 Kubeflow 項(xiàng)目中的 KFServing 演變而來的,從架構(gòu)圖中能夠看出,它的底層是基于Kubernetes,對(duì)加速推理的設(shè)備進(jìn)行統(tǒng)一管理;中間是Serverless層,依托于 Knative,支持 GPU 自動(dòng)縮放、按需擴(kuò)縮至零等功能;上層是支持的主流的機(jī)器學(xué)習(xí)框架、像PyTorch、Tensorflow。

總之KServe解決的就是把訓(xùn)練后的模型怎么快速上線提供服務(wù)的問題,簡化AI模型的部署。

2.2KServe——Serverless層

KServe 的 Serverless 層通過服務(wù)抽象、配置管理和流量路由實(shí)現(xiàn)了無服務(wù)器的 AI 模型推理。

Knative主要分為兩部分:

1. 上半部分通過CRD自定義資源Configuration來管理Deployment的生命周期,每次修改Configuration都會(huì)生成一個(gè)Revision,Revision記錄并對(duì)應(yīng)著Deployment的一個(gè)版本,所以Knative基于這種機(jī)制來實(shí)現(xiàn)灰度發(fā)布的功能;

2. 下半部分通過CRD Route來定義流量的路由規(guī)則,將網(wǎng)絡(luò)請(qǐng)求路由到特定的 Revision,從而實(shí)現(xiàn)流量切分功能。這使得不同版本的模型可以同時(shí)處理請(qǐng)求,進(jìn)行平滑過渡和流量控制。

2.3KServe——基于GPU的彈性伸縮

如何通過請(qǐng)求數(shù)來實(shí)現(xiàn)推理服務(wù)的冷啟動(dòng)和GPU自動(dòng)彈性伸縮?

Knative提供兩種訪問模式:代理模式和直連模式。AI容器縮容到0后,當(dāng)有推理請(qǐng)求時(shí),這個(gè)時(shí)候?yàn)榇砟J剑?qǐng)求先被送到Activator組件進(jìn)行緩存,同時(shí)觸發(fā)autoscaler進(jìn)行快速擴(kuò)容。擴(kuò)容完成后,緩存的請(qǐng)求會(huì)被重新轉(zhuǎn)發(fā),并切換為直連模式,隨后的流量就會(huì)直接請(qǐng)求到對(duì)應(yīng)的Pod。這種動(dòng)態(tài)切換模式設(shè)計(jì),既能在沒有請(qǐng)求時(shí)節(jié)省資源,又能在有請(qǐng)求時(shí)快速響應(yīng)。

2.4KServe——控制面

可以通過一個(gè)直觀的例子來了解如何使用KServe快速部署AI推理服務(wù):

第一步:創(chuàng)建InferenceService CR 資源,指定模型運(yùn)行時(shí)和checkpoint存儲(chǔ)路徑

第二步:確定網(wǎng)關(guān)地址

第三步:進(jìn)行推理請(qǐng)求

從架構(gòu)圖和示例中能夠看出,KServe在Knative的基礎(chǔ)上又進(jìn)一步的抽象和封裝,通過使用InferenceService這個(gè)CRD,KServe實(shí)現(xiàn)了對(duì)AI服務(wù)整個(gè)生命周期的管理。

2.5KServe——數(shù)據(jù)面

每個(gè) InferenceService 由多個(gè)組件組成:“預(yù)測(cè)器”、“解釋器”和“轉(zhuǎn)換器”:

預(yù)測(cè)器:系統(tǒng)的核心組件,負(fù)責(zé)實(shí)際的模型推理

解釋器:提供模型解釋功能,有助于調(diào)試和驗(yàn)證模型的行為,特別是在高風(fēng)險(xiǎn)或需要高透明度的應(yīng)用場(chǎng)景中

轉(zhuǎn)換器:用于對(duì)輸入數(shù)據(jù)進(jìn)行預(yù)處理,或?qū)敵鰯?shù)據(jù)進(jìn)行后處理??梢詧?zhí)行數(shù)據(jù)清洗、特征提取、格式轉(zhuǎn)換等操作,以確保輸入數(shù)據(jù)符合模型要求,或?qū)⑤敵鼋Y(jié)果轉(zhuǎn)換為用戶期望的格式

這些組件協(xié)同工作,確保數(shù)據(jù)平面能夠高效、準(zhǔn)確地執(zhí)行推理任務(wù)。KServe另一個(gè)大的優(yōu)點(diǎn)就是模型服務(wù)的調(diào)用協(xié)議更加標(biāo)準(zhǔn)化和統(tǒng)一化,使得跨系統(tǒng)的集成更加方便,從而提升了模型推理的兼容性和靈活性

2.6KServe——高級(jí)特性

KServe原本的InferenceService是一個(gè)模型一個(gè)服務(wù)的模式,在部署大量模型的情況下,會(huì)面臨計(jì)算資源限制(每個(gè) Pod 中注入了 Sidecar,每個(gè) InferenceService 額外增加 0.5核 CPU 和 0.5G 內(nèi)存開銷)、最大 Pod 限制(Kubernetes建議每個(gè)節(jié)點(diǎn)最多 110 個(gè) Pod,假設(shè)每個(gè) InferenceService 平均有 4 個(gè) Pod,50 節(jié)點(diǎn)集群最多可以運(yùn)行 1000 個(gè)模型)、最大IP地址限制(4096 個(gè) IP 地址的集群最多可以部署 1024 個(gè)模型)

因此KServe開發(fā)了ModelMesh技術(shù),一個(gè)Pod可以加載多個(gè)模型,這些模型可以共享GPU,由Mesh層來調(diào)度轉(zhuǎn)發(fā)推理請(qǐng)求,Puller負(fù)責(zé)模型拉取,提高資源利用率。

ML 推理系統(tǒng)越來越大、越來越復(fù)雜,它們通常由許多模型組成,才能做出單一預(yù)測(cè)。例如,人臉識(shí)別需要先在圖像中定位人臉區(qū)域,然后計(jì)算人臉的特征以匹配數(shù)據(jù)庫中的記錄。所以KServe推理圖允許用戶將多個(gè)機(jī)器學(xué)習(xí)模型和處理步驟鏈接在一起,形成一個(gè)圖形化的推理工作流。這種方法使得用戶能夠在單一的推理請(qǐng)求中組合多個(gè)模型的輸出和處理邏輯,簡化了復(fù)雜機(jī)器學(xué)習(xí)應(yīng)用的部署和管理。

3 浪潮云?;贙Serve的實(shí)踐方案:突破性能瓶頸,實(shí)現(xiàn)大規(guī)模推理高效運(yùn)行

3.1 浪潮云海產(chǎn)品簡介

浪潮云海云操作系統(tǒng) InCloud OS 是浪潮面向私有云領(lǐng)域,以可繼承、可演進(jìn)為理念自研的一套開放、穩(wěn)定、高效、安全的云平臺(tái)軟件,提供云主機(jī)、容器、數(shù)據(jù)庫、中間件、云安全等服務(wù)和智能運(yùn)維、靈活運(yùn)營等能力,助力政企數(shù)字化轉(zhuǎn)型。

整體架構(gòu)秉承可繼承、可演進(jìn)的理念,橫向上各組件靈活選配,不強(qiáng)綁定;縱向上各層次間分層解耦,開放融合。

3.2AI 模型推理流程

AI 服務(wù)的生產(chǎn)流程涵蓋了從數(shù)據(jù)準(zhǔn)備、模型訓(xùn)練與微調(diào),到模型推理服務(wù)上線的全周期管理,形成一個(gè)自我增強(qiáng)的閉環(huán)。在推理階段生成的結(jié)果以及使用過程中收集的新數(shù)據(jù),會(huì)回流至數(shù)據(jù)處理環(huán)節(jié),持續(xù)推動(dòng)模型的優(yōu)化與迭代

3.3浪潮云海AI模型推理服務(wù)上云

浪潮云海推理模型的上云過程有如下步驟, 為了將導(dǎo)出的推理數(shù)據(jù),也就是checkpoint存儲(chǔ)到浪潮的分布式文件系統(tǒng)里, 以PVC的形式進(jìn)行統(tǒng)一數(shù)據(jù)管理:

①創(chuàng)建持久卷聲明 (PVC)

②創(chuàng)建一個(gè) Pod 來訪問 PVC

③將模型存儲(chǔ)在持久卷上

④自定義運(yùn)行時(shí):基于KServe API 實(shí)現(xiàn)自定義 REST ServingRuntime 模型

⑤部署新的推理服務(wù)

⑥執(zhí)行推理請(qǐng)求

通過一系列步驟確保了模型可以順利地在云端環(huán)境中運(yùn)行,滿足實(shí)際業(yè)務(wù)需求。

3.4面臨的挑戰(zhàn)

在模型推理服務(wù)上云和使用的過程中,浪潮云海團(tuán)隊(duì)遇到了多個(gè)技術(shù)挑戰(zhàn)。

挑戰(zhàn)一:模型鏡像大,拉取時(shí)間長,影響AI推理模型啟動(dòng)速度

浪潮云海的解決方案:

引入 Fluid(開源的Kubernetes原生的分布式數(shù)據(jù)集編排和加速引擎), 與 KServe 相結(jié)合,通過數(shù)據(jù)預(yù)熱到分布式緩存加速模型加載流程,提升冷啟動(dòng)速度

通過數(shù)據(jù)復(fù)用,多個(gè)任務(wù)能夠共享數(shù)據(jù)緩存,避免重復(fù)拉取同一份數(shù)據(jù),減少網(wǎng)絡(luò)消耗

挑戰(zhàn)二:高并發(fā)場(chǎng)景下,推理存在延遲,影響服務(wù)的響應(yīng)時(shí)間

浪潮云海的解決方案:

自適應(yīng)批處理:將多個(gè)推理請(qǐng)求組合成單個(gè)批處理,從而優(yōu)化吞吐量和延遲

自適應(yīng)彈性伸縮:模型推理服務(wù)Serverless部署,基于請(qǐng)求數(shù)快速彈性伸縮,加快處理速度

挑戰(zhàn)三:模型推理過程中傳輸?shù)腒V 緩存數(shù)據(jù)高達(dá) GB 級(jí)別,通信開銷高

浪潮云海的解決方案:

基于 SR-IOV 和容器多網(wǎng)卡技術(shù),為容器提供 RDMA 和標(biāo)準(zhǔn)Kubernetes網(wǎng)絡(luò)的雙重能力

通過 RDMA 高性能通信技術(shù),加速模型推理中的高速 KV 緩存遷移,避免傳統(tǒng)網(wǎng)絡(luò)協(xié)議棧的高開銷

挑戰(zhàn)四:現(xiàn)有Kubernetes的集中式控制平面無法及時(shí)應(yīng)對(duì)大規(guī)模的突發(fā)請(qǐng)求

為了解決上述問題,浪潮云海提出了函數(shù)化的控制平面設(shè)計(jì)。通過將控制平面解耦成可拓展的控制函數(shù),根據(jù)請(qǐng)求負(fù)載動(dòng)態(tài)地調(diào)整每個(gè)控制函數(shù)的實(shí)例數(shù)量,應(yīng)對(duì)擴(kuò)容請(qǐng)求的高并發(fā)和稀疏性特征。彈性Serverless控制平面的設(shè)計(jì)如圖所示,浪潮云海設(shè)計(jì)了一個(gè)頂層控制平面用于協(xié)調(diào)和管理函數(shù)化控制平面,它會(huì)根據(jù)請(qǐng)求負(fù)載動(dòng)態(tài)地區(qū)調(diào)整每個(gè)控制模塊的實(shí)例數(shù)量,而函數(shù)化控制平面使用解耦出的各個(gè)控制函數(shù)去管理數(shù)據(jù)平面的各個(gè)函數(shù)實(shí)例。為了實(shí)現(xiàn)快速調(diào)度,浪潮云海進(jìn)行了動(dòng)態(tài)分區(qū)和探測(cè)兩大設(shè)計(jì)。為了避免調(diào)度沖突,將節(jié)點(diǎn)拆分為多個(gè)分區(qū),每個(gè)分區(qū)由單獨(dú)的控制函數(shù)進(jìn)行管理和調(diào)度,實(shí)現(xiàn)對(duì)于調(diào)度質(zhì)量和調(diào)度速度的權(quán)衡。在分區(qū)資源不足時(shí),控制函數(shù)會(huì)探測(cè)其他分區(qū)的可用資源并進(jìn)行任務(wù)遷移,控制函數(shù)級(jí)的探測(cè)相比集中架構(gòu)和節(jié)點(diǎn)級(jí)的探測(cè)開銷顯著降低,并且額外設(shè)計(jì)了探測(cè)緩存進(jìn)行分區(qū)的預(yù)先過濾,可以進(jìn)一步降低探測(cè)開銷??偨Y(jié):浪潮云海團(tuán)隊(duì)積極參與CNCF等開源社區(qū)活動(dòng),并持續(xù)為社區(qū)做出貢獻(xiàn)。未來,浪潮云海將持續(xù)深入?yún)⑴c社區(qū),聚焦資源調(diào)度、云原生AI、Serverless等方向,助力構(gòu)建更為開放、智能的云原生基礎(chǔ)設(shè)施,推動(dòng)全球開源技術(shù)的落地與創(chuàng)新。

(免責(zé)聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請(qǐng)進(jìn)一步核實(shí),并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 )