近日，由Linux基金會、云原生計算基金會(CNCF)主辦的云原生頂級盛會KubeCon+CloudNativeCon+Open Source Summit+China AI_dev 2024成功舉辦，浪潮云海高級軟件工程師王成龍受邀出席會議，發(fā)表《通過功能化調度和RDMA加速無服務器AI大模型推理》主題演講，以下為議題要點實錄。
1前言：今年是Kubernetes發(fā)展的十周年，在這十年里Kubernetes已經(jīng)成為云原生的事實標準，根據(jù)云原生計算基金會(CNCF)調查報告，在2023年全球84%用戶在生產(chǎn)中使用或計劃使用Kubernetes，這更加鞏固了其在云原生的技術地位。
與此同時，以ChatGPT為代表的AIGC技術也在迅猛地發(fā)展，將人們對AI期待推向一個新的高峰。從CNCF發(fā)布的云原生AI白皮書中我們看到，人工智能已經(jīng)形成上云趨勢，越來越多的AI應用正在借助Kubernetes強大的容器編排能力來提高開發(fā)和部署效率，容器和 Serverless 技術將成為未來 AI 應用開發(fā)的主要平臺。
2KServe：簡化模型管理，推動云原生AI應用落地
2.1KServe架構解析
KServe作為Kubernetes上的模型推理平臺，成為簡化和加速機器學習模型部署、管理的重要工具。KServe最初是從 Kubeflow 項目中的 KFServing 演變而來的，從架構圖中能夠看出，它的底層是基于Kubernetes，對加速推理的設備進行統(tǒng)一管理;中間是Serverless層，依托于 Knative，支持 GPU 自動縮放、按需擴縮至零等功能;上層是支持的主流的機器學習框架、像PyTorch、Tensorflow。
總之KServe解決的就是把訓練后的模型怎么快速上線提供服務的問題，簡化AI模型的部署。
2.2KServe——Serverless層
KServe 的 Serverless 層通過服務抽象、配置管理和流量路由實現(xiàn)了無服務器的 AI 模型推理。
Knative主要分為兩部分：
1. 上半部分通過CRD自定義資源Configuration來管理Deployment的生命周期，每次修改Configuration都會生成一個Revision，Revision記錄并對應著Deployment的一個版本，所以Knative基于這種機制來實現(xiàn)灰度發(fā)布的功能;
2. 下半部分通過CRD Route來定義流量的路由規(guī)則，將網(wǎng)絡請求路由到特定的 Revision，從而實現(xiàn)流量切分功能。這使得不同版本的模型可以同時處理請求，進行平滑過渡和流量控制。
2.3KServe——基于GPU的彈性伸縮
如何通過請求數(shù)來實現(xiàn)推理服務的冷啟動和GPU自動彈性伸縮?
Knative提供兩種訪問模式：代理模式和直連模式。AI容器縮容到0后，當有推理請求時，這個時候為代理模式，請求先被送到Activator組件進行緩存，同時觸發(fā)autoscaler進行快速擴容。擴容完成后，緩存的請求會被重新轉發(fā)，并切換為直連模式，隨后的流量就會直接請求到對應的Pod。這種動態(tài)切換模式設計，既能在沒有請求時節(jié)省資源，又能在有請求時快速響應。
2.4KServe——控制面
可以通過一個直觀的例子來了解如何使用KServe快速部署AI推理服務：
第一步：創(chuàng)建InferenceService CR 資源，指定模型運行時和checkpoint存儲路徑
第二步：確定網(wǎng)關地址
第三步：進行推理請求
從架構圖和示例中能夠看出，KServe在Knative的基礎上又進一步的抽象和封裝，通過使用InferenceService這個CRD，KServe實現(xiàn)了對AI服務整個生命周期的管理。
2.5KServe——數(shù)據(jù)面
每個 InferenceService 由多個組件組成：“預測器”、“解釋器”和“轉換器”：
預測器：系統(tǒng)的核心組件，負責實際的模型推理
解釋器：提供模型解釋功能，有助于調試和驗證模型的行為，特別是在高風險或需要高透明度的應用場景中
轉換器：用于對輸入數(shù)據(jù)進行預處理，或對輸出數(shù)據(jù)進行后處理?？梢詧?zhí)行數(shù)據(jù)清洗、特征提取、格式轉換等操作，以確保輸入數(shù)據(jù)符合模型要求，或將輸出結果轉換為用戶期望的格式
這些組件協(xié)同工作，確保數(shù)據(jù)平面能夠高效、準確地執(zhí)行推理任務。KServe另一個大的優(yōu)點就是模型服務的調用協(xié)議更加標準化和統(tǒng)一化，使得跨系統(tǒng)的集成更加方便，從而提升了模型推理的兼容性和靈活性
2.6KServe——高級特性
KServe原本的InferenceService是一個模型一個服務的模式，在部署大量模型的情況下，會面臨計算資源限制(每個 Pod 中注入了 Sidecar，每個 InferenceService 額外增加 0.5核 CPU 和 0.5G 內存開銷)、最大 Pod 限制(Kubernetes建議每個節(jié)點最多 110 個 Pod，假設每個 InferenceService 平均有 4 個 Pod，50 節(jié)點集群最多可以運行 1000 個模型)、最大IP地址限制(4096 個 IP 地址的集群最多可以部署 1024 個模型)
因此KServe開發(fā)了ModelMesh技術，一個Pod可以加載多個模型，這些模型可以共享GPU，由Mesh層來調度轉發(fā)推理請求，Puller負責模型拉取，提高資源利用率。
ML 推理系統(tǒng)越來越大、越來越復雜，它們通常由許多模型組成，才能做出單一預測。例如，人臉識別需要先在圖像中定位人臉區(qū)域，然后計算人臉的特征以匹配數(shù)據(jù)庫中的記錄。所以KServe推理圖允許用戶將多個機器學習模型和處理步驟鏈接在一起，形成一個圖形化的推理工作流。這種方法使得用戶能夠在單一的推理請求中組合多個模型的輸出和處理邏輯，簡化了復雜機器學習應用的部署和管理。
3 浪潮云?；贙Serve的實踐方案：突破性能瓶頸，實現(xiàn)大規(guī)模推理高效運行
3.1 浪潮云海產(chǎn)品簡介
浪潮云海云操作系統(tǒng) InCloud OS 是浪潮面向私有云領域，以可繼承、可演進為理念自研的一套開放、穩(wěn)定、高效、安全的云平臺軟件，提供云主機、容器、數(shù)據(jù)庫、中間件、云安全等服務和智能運維、靈活運營等能力，助力政企數(shù)字化轉型。
整體架構秉承可繼承、可演進的理念，橫向上各組件靈活選配，不強綁定;縱向上各層次間分層解耦，開放融合。
3.2AI 模型推理流程
AI 服務的生產(chǎn)流程涵蓋了從數(shù)據(jù)準備、模型訓練與微調，到模型推理服務上線的全周期管理，形成一個自我增強的閉環(huán)。在推理階段生成的結果以及使用過程中收集的新數(shù)據(jù)，會回流至數(shù)據(jù)處理環(huán)節(jié)，持續(xù)推動模型的優(yōu)化與迭代
3.3浪潮云海AI模型推理服務上云
浪潮云海推理模型的上云過程有如下步驟, 為了將導出的推理數(shù)據(jù)，也就是checkpoint存儲到浪潮的分布式文件系統(tǒng)里, 以PVC的形式進行統(tǒng)一數(shù)據(jù)管理：
①創(chuàng)建持久卷聲明 (PVC)
②創(chuàng)建一個 Pod 來訪問 PVC
③將模型存儲在持久卷上
④自定義運行時：基于KServe API 實現(xiàn)自定義 REST ServingRuntime 模型
⑤部署新的推理服務
⑥執(zhí)行推理請求
通過一系列步驟確保了模型可以順利地在云端環(huán)境中運行，滿足實際業(yè)務需求。
3.4面臨的挑戰(zhàn)
在模型推理服務上云和使用的過程中，浪潮云海團隊遇到了多個技術挑戰(zhàn)。
挑戰(zhàn)一：模型鏡像大，拉取時間長，影響AI推理模型啟動速度
浪潮云海的解決方案：
引入 Fluid(開源的Kubernetes原生的分布式數(shù)據(jù)集編排和加速引擎)， 與 KServe 相結合，通過數(shù)據(jù)預熱到分布式緩存加速模型加載流程，提升冷啟動速度
通過數(shù)據(jù)復用，多個任務能夠共享數(shù)據(jù)緩存，避免重復拉取同一份數(shù)據(jù)，減少網(wǎng)絡消耗
挑戰(zhàn)二：高并發(fā)場景下，推理存在延遲，影響服務的響應時間
浪潮云海的解決方案：
自適應批處理：將多個推理請求組合成單個批處理，從而優(yōu)化吞吐量和延遲
自適應彈性伸縮：模型推理服務Serverless部署，基于請求數(shù)快速彈性伸縮，加快處理速度
挑戰(zhàn)三：模型推理過程中傳輸?shù)腒V 緩存數(shù)據(jù)高達 GB 級別，通信開銷高
浪潮云海的解決方案：
基于 SR-IOV 和容器多網(wǎng)卡技術，為容器提供 RDMA 和標準Kubernetes網(wǎng)絡的雙重能力
通過 RDMA 高性能通信技術，加速模型推理中的高速 KV 緩存遷移，避免傳統(tǒng)網(wǎng)絡協(xié)議棧的高開銷
挑戰(zhàn)四：現(xiàn)有Kubernetes的集中式控制平面無法及時應對大規(guī)模的突發(fā)請求
為了解決上述問題，浪潮云海提出了函數(shù)化的控制平面設計。通過將控制平面解耦成可拓展的控制函數(shù)，根據(jù)請求負載動態(tài)地調整每個控制函數(shù)的實例數(shù)量，應對擴容請求的高并發(fā)和稀疏性特征。彈性Serverless控制平面的設計如圖所示，浪潮云海設計了一個頂層控制平面用于協(xié)調和管理函數(shù)化控制平面，它會根據(jù)請求負載動態(tài)地區(qū)調整每個控制模塊的實例數(shù)量，而函數(shù)化控制平面使用解耦出的各個控制函數(shù)去管理數(shù)據(jù)平面的各個函數(shù)實例。為了實現(xiàn)快速調度，浪潮云海進行了動態(tài)分區(qū)和探測兩大設計。為了避免調度沖突，將節(jié)點拆分為多個分區(qū)，每個分區(qū)由單獨的控制函數(shù)進行管理和調度，實現(xiàn)對于調度質量和調度速度的權衡。在分區(qū)資源不足時，控制函數(shù)會探測其他分區(qū)的可用資源并進行任務遷移，控制函數(shù)級的探測相比集中架構和節(jié)點級的探測開銷顯著降低，并且額外設計了探測緩存進行分區(qū)的預先過濾，可以進一步降低探測開銷?？偨Y：浪潮云海團隊積極參與CNCF等開源社區(qū)活動，并持續(xù)為社區(qū)做出貢獻。未來，浪潮云海將持續(xù)深入?yún)⑴c社區(qū)，聚焦資源調度、云原生AI、Serverless等方向，助力構建更為開放、智能的云原生基礎設施，推動全球開源技術的落地與創(chuàng)新。
（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
