云原生AI技術(shù)架構(gòu)白皮書 2024

4.4大模型云原生化解決方案 ·01· ·02·及應(yīng)用市場規(guī)模將達(dá)到211億美元，各行業(yè)的AI需求極大地推動著AI市場增長。隨著數(shù)字經(jīng)濟(jì)、元宇宙等概念的逐漸興起，人工智能進(jìn)入大規(guī)模落地應(yīng)用的關(guān)鍵時期一局面。憑借其優(yōu)越的泛化性、通用性、遷移性，AI大模型為人工智能大規(guī)模落地帶來新的希望。面對人產(chǎn)業(yè)迎來了井噴式的創(chuàng)新和發(fā)展。憑借在文字、語音、圖像、視頻等多模態(tài)處理能力上的躍遷，AI大模型搖身變?yōu)椤爸怼薄ⅰ皩＜摇弊呷朕k公室、制造車間、金融市場、醫(yī)療機構(gòu)、政務(wù)大廳，結(jié)合傳統(tǒng)軟件使得各個行業(yè)更加智能化、自動化。AI大模型已然改變了我們的生活和工作的方方面面，成為各個行業(yè)不可據(jù)特征高維、模態(tài)格式多樣的趨勢也逐漸明顯，對數(shù)據(jù)的AI建模也相應(yīng)地更加復(fù)雜，計算復(fù)雜度會隨之呈此同時，AI應(yīng)用場景更加多元化、復(fù)雜化，往往需要對多個任務(wù)進(jìn)行深度融合和統(tǒng)一建模，這意味著廠商需要針對不同場景、不同任務(wù)開發(fā)大量的算法和模型，增加了AI應(yīng)用的開發(fā)難度。算力方面，需要針對不同的場景和高性能計算能力進(jìn)行拓展融合,滿足研發(fā)企業(yè)的多云原生AI成為AI產(chǎn)業(yè)發(fā)展的新范式。為了突破AI產(chǎn)業(yè)的發(fā)展瓶頸，云原生AI技術(shù)應(yīng)運而生。一方Kubernetes的云原生可以有效管理各類網(wǎng)絡(luò)、存儲和計算資源，已逐步 于私有云、公有云以及混合云環(huán)境?；谄涓呖捎锰匦裕圃到y(tǒng)可通過自動故障恢復(fù)機制在故障發(fā)生原生可以根據(jù)AI應(yīng)用需求快速增加或減少計算資源，滿足不同場景下的計算需求。同時，云原生具備良好性能，并降低了企業(yè)的成本。另一方面，AI也可以從調(diào)度資源、安全等方面增強云原生。在涉及多個優(yōu)化標(biāo)準(zhǔn)的情況下，AI可以分析集群的歷史使用情況并預(yù)測未來工作負(fù)載模式和資源可用性，更好地調(diào)度云基礎(chǔ)設(shè)施資源，進(jìn)而降低能源消耗和使用成本。在安全方面，AI可以分析大規(guī)模數(shù)據(jù)集并預(yù)測系統(tǒng)中的潛在本白皮書重點關(guān)注云原生AI基礎(chǔ)設(shè)施層支持AI開發(fā)和使用，結(jié)合云原生開源生態(tài)發(fā)展現(xiàn)狀和行業(yè)實·03· ·04··05· 云原生技術(shù)本質(zhì)上是基礎(chǔ)設(shè)施云化和與之配套的服務(wù)（例如CI/CD就是如何在云化的基礎(chǔ)設(shè)施部署軟件）的技術(shù)。這在云原生AI里也是一樣的，云原生AI基礎(chǔ)設(shè)施是云原生AI基礎(chǔ)設(shè)施向上為AI訓(xùn)練作業(yè)、推理服務(wù)及模型開發(fā)等各類AI業(yè)務(wù)提供任務(wù)編排和調(diào)度能力，向下對多數(shù)據(jù)中心的異構(gòu)硬件設(shè)備統(tǒng)一納管并提供高效、可靠的資源供應(yīng)能力。這一章將簡短地回顧一下云原生AI2018年圖靈獎獲得者計算機體系結(jié)構(gòu)泰斗約翰·軒尼詩(JohnHennessy)和戴維·帕特森(DavidAI技術(shù)的發(fā)展和新的軟硬件接口抽象為云原生基礎(chǔ)設(shè)施帶來了新的挑戰(zhàn)和機遇，以面向特定領(lǐng)域體系破1億，成為史上用戶增長最快速的現(xiàn)象級應(yīng)用。ChatGPT表現(xiàn)出的對文本的超凡理解力和生成能力，讓大模型。在近幾年的大模型研究和工程實踐中，業(yè)界發(fā)現(xiàn)模型的訓(xùn)練數(shù)據(jù)、參數(shù)量和計算量越大，模型的效果越好，模型規(guī)模與模型效果呈現(xiàn)顯著的正相關(guān)，雖然學(xué)術(shù)界存在爭議，但大模型的ScalingLaw仍然為應(yīng)對大模型對算力、存儲（帶寬、容量）需求，必須把大量加速卡和服務(wù)器節(jié)點通過高速總線和網(wǎng)集群以提供充足的算力供應(yīng)，隨著模型尺寸的持個或三個網(wǎng)絡(luò)平面及一個高速總線平面，分別是：前端網(wǎng)絡(luò)平面，用于集群管理和AI作業(yè)的調(diào)度發(fā)放；后·06· 為參數(shù)平面存儲網(wǎng)絡(luò)，通過專用的存儲網(wǎng)卡和交換機將訓(xùn)練節(jié)點和存儲設(shè)備連接起來，用于訓(xùn)練數(shù)據(jù)的學(xué)術(shù)論文中提出大量當(dāng)前AI業(yè)務(wù)在使用大規(guī)模算力集群過程中遇到的挑戰(zhàn)和問題，這里我們列舉幾個核相對于單卡和單計算節(jié)點的計算效率，相對于單卡和單計算節(jié)點的計算效率，AI計算任務(wù)在多卡多節(jié)點上的執(zhí)行是模型訓(xùn)練為例，模型訓(xùn)練的吞吐（樣本數(shù)/秒）=單卡訓(xùn)練吞吐（樣本數(shù)/秒）*或以太網(wǎng)絡(luò)將加速卡節(jié)點連接成AI集群。要保持AI算力集群中AI任務(wù)的線性度，需要綜網(wǎng)絡(luò)拓?fù)浜虯I任務(wù)的并行策略及其通訊需求進(jìn)行作業(yè)任務(wù)的層次化調(diào)度，這對集群的調(diào)度器提出了新的要求，即：要感知集群的資源的網(wǎng)絡(luò)拓?fù)浜停ǔ┕?jié)點拓?fù)?，并根?jù)AI任務(wù)的并行模式和通訊要求，將任務(wù)切分并調(diào)度到合適的節(jié)點和卡上，目前云原生AI調(diào)度器方案在拓?fù)涓兄白鳂I(yè)并行策略表達(dá)及調(diào)度算法方.·07· 是AI集群使用者和供應(yīng)者共同關(guān)注的問題，集群的可用度直接關(guān)系到AI任務(wù)能否在預(yù)期的時間內(nèi)完存取性能，及時發(fā)現(xiàn)故障并快速恢復(fù)都有待云原生AI中的存儲、故障和檢測恢復(fù)組件的提供更加完備和高對于AI開發(fā)者而言，AI基礎(chǔ)設(shè)施首先應(yīng)該屏蔽底層基礎(chǔ)設(shè)施的細(xì)節(jié)，使AI開發(fā)者可以聚焦在數(shù)據(jù)質(zhì)量的提升和模型架構(gòu)的優(yōu)化。加速卡有不同的型號和參數(shù)、加速卡間通過不同的網(wǎng)絡(luò)拓?fù)渫ㄐ?，不同的網(wǎng) ·08· ·09·如前文所述，云原生AI技術(shù)包含了很多方面，從底層的硬件和數(shù)據(jù)中心，到容器集群經(jīng)進(jìn)入了一個高速發(fā)展的XPU時代。在AI算力業(yè)務(wù)蓬勃發(fā)展的時代背景下，AI算力訴求急劇膨脹，從最隨著AI產(chǎn)品的大眾化、規(guī)?；钶d商業(yè)級算力芯片的大規(guī) ·10·備武器，AI算力集群規(guī)模也日益膨脹，這就大模型、自動駕駛、AIGC的橫空出世，大規(guī)模的的超高帶寬，發(fā)展出了計算機超節(jié)點架構(gòu)，計算機超節(jié)設(shè)備等計算機資源單元，高速互聯(lián)緊耦合在一起的集群計算系統(tǒng)，是生成式AI時代的產(chǎn)物。區(qū)別于傳統(tǒng)以服務(wù)器中心松耦合架構(gòu)，超節(jié)點是去中心化的緊耦合架構(gòu)。隨著技術(shù)的進(jìn)一步演進(jìn)，未來超節(jié)點內(nèi)所有服務(wù)器的設(shè)備可做到靈活組合成為各種算力單元，也可被稱為矩陣式算力。為了能夠有效利用超節(jié)點內(nèi)的資度發(fā)揮XPU算力的效率，數(shù)據(jù)必須能夠盡快的被XPU訪問到而不是浪費時間等待數(shù)據(jù)；隨著算設(shè)備至關(guān)重要。在云上多租業(yè)務(wù)場景下，我們需要注意并確保I/O瓶頸不會出現(xiàn)在重要業(yè)務(wù)場景比如對②和②JayashreeMohan,AmarPhanishayee,AshishRaniwala,andVijayChidambaram.2021.AnalyzingandmitigatingdatastallsinDNNtraining.Proc.VLDBEndow.14,5(January2021),771–784.https://doi. ·11·狀態(tài)，造成的大量的時間和金錢的浪費?，F(xiàn)在，由于AI廠商無法獲得足夠的計算和存儲資源來訓(xùn)練和優(yōu)化模型，所以不得不在云數(shù)據(jù)中心購買資源。在云上，數(shù)隨著AI計算規(guī)模增大，例如大規(guī)模AI訓(xùn)練，需要多卡甚至多個節(jié)點同時參與一個任務(wù)的計算，其中無論集群的AI算力規(guī)模如何膨脹，AI算力設(shè)備終究需要依托在服務(wù)器節(jié)點上，這形成了一對多的關(guān)），Plugin進(jìn)程僅需要管理自身節(jié)點上的少量AI算力設(shè)備，并將可用算力設(shè)備數(shù)上報至集群數(shù)據(jù)中心側(cè)，由缺，例如大規(guī)模模型訓(xùn)練場景的高性能網(wǎng)絡(luò)設(shè)備(RDMA設(shè)備)，是依賴于網(wǎng)絡(luò)拓?fù)涓兄?，就近分配資源 ·12·支持設(shè)備的初始化和清理過程：設(shè)備的申請/注銷是由中心側(cè)控制器負(fù)責(zé)，KubeletPlugin則負(fù)責(zé)響相較于DevicePlugin模式，DRA有更加豐富的語義，可以滿足更復(fù)雜的設(shè)備管理場景，但D來了豐富語義和擴(kuò)展性的同時，其管理成本的開銷、效率也是有所增加，所以DRA的出現(xiàn)并不代表替換雖然計算機超節(jié)點的High-SpeedLink高速互為匹配AI行業(yè)所需的龐大算力需求，基礎(chǔ)設(shè)施硬件從主從架構(gòu)逐步演進(jìn)至模越大，參數(shù)規(guī)模一般也會更大，這樣GPU之間通信（P2P）能力對計算效率影響就比較大。NVLink的 ·13·全局多路徑加速是指我們可以利用單機內(nèi)CPU與GPU等不同芯片的多路徑，以及跨主機的多路徑提路徑來加速CPU-GPUIO傳輸。但這遠(yuǎn)遠(yuǎn)不夠，大語言模型（LLM）對顯存容量的需求非常迫切，巨大的顯存容量符合大模型的發(fā)展趨勢。那么，這個前所未見的容量是通過大規(guī)模的機器互聯(lián)來實現(xiàn)；在這種更大規(guī)?；ヂ?lián)的場景下，集群內(nèi)跨設(shè)備之間的I/O通信可以采用的路徑也會越來越多，包括CPU與在未來超節(jié)點架構(gòu)中，一個物理超節(jié)點是由很多計算和存儲設(shè)備通過網(wǎng)絡(luò)連接起來的集群；一個物理超節(jié)點可能會被拆分成多個邏輯節(jié)點分配給不同租戶的不同業(yè)務(wù)，這些業(yè)務(wù)可能會同時分布在多個計算單元上，這些計算不同業(yè)務(wù)對I/O的需求模式可能有區(qū)別。兩個互相通信的設(shè)備之間可能存在不同時延，不對當(dāng)前不同設(shè)備之間的通信需求快速地生成對應(yīng)的可用路徑；并根據(jù)每一條路徑上的當(dāng)前帶寬和可用性規(guī)劃傳輸?shù)臄?shù)據(jù)量大小并按需使用對應(yīng)路徑；在數(shù)據(jù)量傳輸較大的場景還可以提高性能——通過同時使用多感知業(yè)務(wù)特征和集群拓?fù)洌和ㄟ^持續(xù)在線監(jiān)控和避免I/O負(fù)載瓶頸來簡化多路徑管理。當(dāng)某一條路徑 ·14·減少非必要數(shù)據(jù)傳輸：利用高性能緩存層或者在XPU可快速訪存的內(nèi)存中緩存常用的訓(xùn)練數(shù)據(jù)來加速I/O。與此同時也可以通過冷熱數(shù)據(jù)分級分區(qū)存放，熱數(shù)據(jù)盡量放在據(jù)放在I/O訪問較遠(yuǎn)的內(nèi)存介質(zhì)中，從而盡可能降低非必要的數(shù)據(jù)加載；在AI計傳統(tǒng)資源管理模型的基本算力單元為單臺服務(wù)器，服務(wù)器模型內(nèi)包含各種設(shè)備等資源池模型由服務(wù)器模型聚合而成，其資源分配也是以服務(wù)器為基本粒度，云化場景下的云服務(wù)器也僅是設(shè)備數(shù)量存在差異，其基本建模均保持一致。超節(jié)點為去中心化的架構(gòu)，雖然物理設(shè)備仍依托于服務(wù)器之上，但超節(jié)點內(nèi)配備有超高速互聯(lián)網(wǎng)絡(luò)，其內(nèi)所有設(shè)備均可以靈活組合成不同的算力單元，超節(jié)超節(jié)點資源管理模型與資源切片：超節(jié)點資源管理模型包含三個基本算力單元模型：XPU、CPU和內(nèi)外的設(shè)備不參與資源調(diào)度過程，而是通過規(guī)格預(yù)定義的方式進(jìn)行管理，在AI場景下這些設(shè)備的分配量一般超節(jié)點資源拓?fù)涓兄篈I業(yè)務(wù)場景下所需的通信量非常大，其通信算法都會根據(jù)基礎(chǔ)設(shè)施行編排優(yōu)化，以達(dá)到充分利用網(wǎng)絡(luò)帶寬的目的。為了有效利用超節(jié)點的高速互聯(lián)網(wǎng)絡(luò)，客戶也需要感知到超節(jié)點內(nèi)部的拓?fù)浣Y(jié)構(gòu)來優(yōu)化通信算法。然而算力服務(wù)提供商出于安全和保密方面的考慮，一般不會對客戶暴露物理信息，而是通過抽象方式隱藏物理信息。AWS提供了一套網(wǎng)絡(luò)拓?fù)涞某橄蠼Ｋ悸纺軌蛟跐M足通信算法優(yōu)化需求的同時隱藏物理信息。超節(jié)點資源拓?fù)涓兄Ｐ蛯⒉煌木W(wǎng)絡(luò)設(shè)備抽象為虛擬的網(wǎng)絡(luò)節(jié) ·15·超節(jié)點資源高可用：高可用能力是大規(guī)模集群系統(tǒng)必須具備的基本能力，基礎(chǔ)設(shè)施層的高可用能力之助客戶快速恢復(fù)業(yè)務(wù)。在超節(jié)點架構(gòu)下，由于超節(jié)點內(nèi)的設(shè)備之間具備高速互聯(lián)網(wǎng)絡(luò)，所以可用于替換的設(shè)備必須在超節(jié)點內(nèi)部，不能跨超節(jié)點進(jìn)行設(shè)備替換。在超節(jié)點架構(gòu)下執(zhí)行故障設(shè)備替換時，資源管理平臺會約束調(diào)度系統(tǒng)的調(diào)度范圍不能超出設(shè)備所在的超節(jié)點。此外，由于超節(jié)點規(guī)模有限，為了確保超節(jié)點內(nèi)存在可用于替換的設(shè)備，資源管理平臺會在每個超節(jié)點內(nèi)預(yù)留部分設(shè)備作為保底手段。在故障替換時會優(yōu)先選擇非預(yù)留的空閑設(shè)備，在非預(yù)留空閑設(shè)備不滿足替換需求時才會動用預(yù)留資源。在某個預(yù)留設(shè)備被使用后，預(yù)留設(shè)備池的容量隨之減少，資源管理平臺會周期性的掃描超節(jié)點內(nèi)設(shè)備使用狀態(tài)，若存在被釋放的設(shè)備則將其加入預(yù)留池，以實現(xiàn)預(yù)留池容量的輪轉(zhuǎn)。同時，資源你管理平臺也會通知運維人員及時維修故障設(shè)備。在AI場景下，為了與Checkpiont機制相配合，資源管理平臺會對外暴露設(shè)備替換接口。AI除設(shè)備故障外，網(wǎng)絡(luò)斷連也是典型的故障場景，超節(jié)點資源管理平臺采用借軌通信的方案解決此類問關(guān)鍵功能。這些能力不僅極大地提升了AI模型訓(xùn)練的效率和性能，也為企業(yè)的智能化轉(zhuǎn)型在訓(xùn)練階段，通過大量數(shù)據(jù)和算法，AI模型學(xué)會識別和生成規(guī)律。有別于一般的通用業(yè)務(wù)場景，AI大 ·16·模型訓(xùn)練對數(shù)據(jù)傳輸?shù)膸捄托阅苡懈叩囊?。同時，隨著大模型的出現(xiàn)，AI訓(xùn)練/推理任務(wù)不再是單卡或單機的規(guī)模，通常表現(xiàn)為多個容器實例組成的分布式任務(wù)負(fù)載，由此對AI任務(wù)智能調(diào)度能力提出了更分布式調(diào)度死鎖和忙等：一個分布式訓(xùn)練作業(yè)通常由一批相關(guān)聯(lián)的Pod聯(lián)合執(zhí)行訓(xùn)練任務(wù)，比如且同時停。當(dāng)集群中并發(fā)提交多個訓(xùn)練作業(yè)，在資源有限的情況下，每個訓(xùn)練作業(yè)僅部分Pod被成功調(diào)度從而獲取到集群資源，此時各訓(xùn)練作業(yè)均在等待更多資源以滿足作業(yè)運行的條件，造成作業(yè)之間的資源死在AI訓(xùn)練和推理過程中，任務(wù)調(diào)度具有至關(guān)重要的作用，通過度能力，大幅度提升AI訓(xùn)練任務(wù)性能；裝箱調(diào)度和重調(diào)度配合使用，緩解集群資源碎片過多的問題，提高群剩余資源不滿足該作業(yè)所有Pod同時運行，該訓(xùn)練作業(yè)不被調(diào)度節(jié)點網(wǎng)絡(luò)拓?fù)涓兄{(diào)度：節(jié)點內(nèi)卡與卡有多種通信方式，比如GPU卡之間的網(wǎng)絡(luò)連接方式分別為 ·17·大的高帶寬互聯(lián)。隨著大模型訓(xùn)練參數(shù)量級的快速增長，在模型并行度超過單節(jié)點卡數(shù)的場景，考慮將分布式并行策略與超節(jié)點拓?fù)浣Y(jié)構(gòu)相結(jié)合，模型并行任務(wù)控制在一個超節(jié)點內(nèi)，超節(jié)點之間執(zhí)行數(shù)據(jù)并行和裝箱調(diào)度（Binpack裝箱調(diào)度主要用于解決集群資源碎片的問題，在AI訓(xùn)練場景下包含兩種維度的裝箱調(diào)度，分別為節(jié)點維度和Tor維度。對于不滿8卡的訓(xùn)練作業(yè)優(yōu)先進(jìn)行節(jié)點級裝箱調(diào)度，填滿集群內(nèi)節(jié)點資源碎片，空余更多節(jié)點用于調(diào)度需要整8卡的訓(xùn)練作業(yè)；對于單個節(jié)點無法承載的訓(xùn)練作業(yè)，優(yōu)先進(jìn)行Tor級別裝箱調(diào)度，優(yōu)先填滿Tor級別的節(jié)點資源碎片，結(jié)合Tor親和調(diào)度為后續(xù)訓(xùn)練作業(yè)分配整集群中不可避免出現(xiàn)節(jié)點資源碎片，在集群內(nèi)資源碎片現(xiàn)象嚴(yán)重的場景下，大模型訓(xùn)練作業(yè)往往會因無法獲取整節(jié)點資源而長時間排隊。重調(diào)度策略主動識別集群碎片率過高的節(jié)點，驅(qū)逐并按照裝箱策略重新調(diào)度該部分節(jié)點對應(yīng)的任務(wù)，整合節(jié)點資源碎片。重調(diào)度涉及業(yè)務(wù)的驅(qū)逐與重啟，對AI任務(wù)的故障恢復(fù)有一大模型訓(xùn)練AI集群故障概率高，故障影響大，故障發(fā)生后任務(wù)恢復(fù)耗時長，浪費大量AI算力和訓(xùn)練。訓(xùn)練大模型涉及大量GPU/NPU（成千上萬個）和訓(xùn)練時間（以月為單位因此作業(yè)失/NPU訓(xùn)練集群中很常見，機器崩潰和網(wǎng)絡(luò)故障不可避免。分布式深度神經(jīng)網(wǎng)絡(luò)訓(xùn)練作業(yè)被中斷，將導(dǎo)致模訓(xùn)練任務(wù)檢查點Checkpoint是深度學(xué)習(xí)框架中的容錯方法。檢查點Checkpoint通過在給定時間定bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI技術(shù)概論>>但checkpoint檢查點和故障終止之間的進(jìn)度仍會丟失,因為必須重新執(zhí)行計算以恢復(fù)未保存間結(jié)果。根據(jù)checkpoint檢查點保存頻率,通常會導(dǎo)致幾個小時的計算時間損失。此外,保存和恢復(fù)卡的時間。圖3-2-1訓(xùn)練過程中checkpoint保存和故障恢復(fù)時的時間和算力開銷更高的checkpoint保存頻率,更快的checkpoint保存速度,以及訓(xùn)練任務(wù)故障時更快的checkpoint速度,提高大規(guī)模集群的算力利用率。CV多模態(tài)/自動駕駛等訓(xùn)練任務(wù)場景模型訓(xùn)練計算速度很快,但底層訓(xùn)練數(shù)據(jù)量很大,數(shù)據(jù)集讀取慢導(dǎo)致GPU/NPU算力出現(xiàn)空閑,訓(xùn)練任務(wù)變慢。隨著AI數(shù)據(jù)量不斷增長,訓(xùn)練使用GPU/NPU越來越多,底層存儲的10已經(jīng)跟不上計算能力,企業(yè)希望存儲系統(tǒng)能提供高吞吐的數(shù)據(jù)訪問能力,充分發(fā)揮GPU/NPU的計算性能,包括訓(xùn)練數(shù)據(jù)的讀取,訓(xùn)練數(shù)據(jù)的讀取要盡量讀得快,減少上層算力對存儲1/O的等(2)(2)關(guān)鍵技術(shù)和價值針對AI訓(xùn)練場景中面臨的挑戰(zhàn),我們可以提供基于大容量對象存儲服務(wù)+高性能文件服務(wù)的AI云存儲?！?8·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI技術(shù)概論>>圖3-2-2基于大容量對象存儲服務(wù)+高性能文件服務(wù)的AI云存儲架構(gòu)圖首先,云原生時代,業(yè)務(wù)數(shù)據(jù)首先是集中積累到數(shù)據(jù)湖存儲中,是數(shù)據(jù)入云的第一個落腳點,數(shù)據(jù)湖存儲是AI數(shù)據(jù)采集和導(dǎo)入、大數(shù)據(jù)預(yù)處理、模型開發(fā)、訓(xùn)練、模型推理分發(fā)部署等各個業(yè)務(wù)環(huán)節(jié)進(jìn)行數(shù)據(jù)流轉(zhuǎn)的核心,能夠方便地和各個業(yè)務(wù)環(huán)節(jié)進(jìn)行數(shù)據(jù)交流,通過S3/HDFS多協(xié)議能訪問到同一份數(shù)據(jù),數(shù)據(jù)免搬遷,因此對象存儲是數(shù)據(jù)湖存儲的首選。在數(shù)據(jù)湖之上,針對AI最為核心的訓(xùn)練環(huán)節(jié)涉及的海量小文件高性能、低時延,及大模型訓(xùn)練撐AI高性能計算時性能不足的問題,加速訓(xùn)練過程。AI訓(xùn)練在數(shù)據(jù)加載以及為了故障恢復(fù)做的checkpoint機制中,AI訓(xùn)練集群需要進(jìn)行高性能數(shù)據(jù)讀寫,高性能文件緩存在AI訓(xùn)練場景是必須的服務(wù),高性能數(shù)據(jù)緩存用于加載訓(xùn)練任務(wù)需要的數(shù)據(jù)集,保存checkpoint、模型文件等熱數(shù)據(jù),用于訓(xùn)練任務(wù)故障恢復(fù),模型評測時基于近期checkpoint進(jìn)行訓(xùn)練算法微調(diào)等場景。a)數(shù)據(jù)聯(lián)動技術(shù)高性能文件存儲內(nèi)置BucketLink數(shù)據(jù)聯(lián)動功能,高性能文件存儲內(nèi)的文件系統(tǒng)可以綁定容量層的對象桶,用戶無需手工部署外部遷移工具即可實現(xiàn)在對象存儲和高性能文件存儲兩個分布式存儲服務(wù)之間進(jìn)行高速數(shù)據(jù)流動,存儲各節(jié)點均可參與數(shù)據(jù)導(dǎo)入、導(dǎo)出,數(shù)據(jù)流轉(zhuǎn)比人工帶外工具方式更加簡潔高效。AI訓(xùn)練場景中,通過高性能文件系統(tǒng)來加速對象存儲中的數(shù)據(jù)訪問,用戶通過指定高性能文件存儲文件系統(tǒng)內(nèi)的目錄與對象存儲桶進(jìn)行關(guān)聯(lián),然后通過創(chuàng)建數(shù)據(jù)導(dǎo)入導(dǎo)出任務(wù)實現(xiàn)數(shù)據(jù)同步,訓(xùn)練開始前可以將對象存儲數(shù)據(jù)湖中的AI訓(xùn)練集數(shù)據(jù)高速預(yù)熱到高性能文件緩存加速層中,實現(xiàn)訓(xùn)練時數(shù)據(jù)集高速讀取,避 ·20·會導(dǎo)入文件元數(shù)據(jù)，文件內(nèi)容會在首次訪問時從對象存儲桶中加載并緩存在高性能文件存儲中，后續(xù)重復(fù)訪問會直接命中高性能文件存儲緩存，無數(shù)據(jù)內(nèi)容，對文件的第一次讀取操作可能耗時較長，適合對首次數(shù)據(jù)訪問時延不太功能會同時導(dǎo)入元數(shù)據(jù)和數(shù)據(jù)內(nèi)容到高性能文件存儲中，上層業(yè)務(wù)訪問數(shù)據(jù)時可以從高性能文件存儲中直接命中，最大程度減少業(yè)務(wù)訪問數(shù)據(jù)時的時延。如務(wù)對數(shù)據(jù)訪問時延比較敏感，比如AI訓(xùn)練等場景涉及海量小文件，可以選擇數(shù)據(jù)高性能文件系統(tǒng)綁定對象桶后，可以使用數(shù)據(jù)導(dǎo)出功能。當(dāng)上層業(yè)務(wù)在數(shù)據(jù)高性能文件系統(tǒng)綁定對象桶后，可以使用數(shù)據(jù)導(dǎo)出功能。當(dāng)上層業(yè)務(wù)在數(shù)據(jù)聯(lián)動目錄里創(chuàng)建一些文件，需要將這些文件存儲到對象桶里，可以使用數(shù)據(jù)能。數(shù)據(jù)導(dǎo)出支持手工導(dǎo)出和配置成自動導(dǎo)出到對象桶。上層業(yè)務(wù)將數(shù)據(jù)同步寫入高性能文件存儲，高性能文高性能文件系統(tǒng)綁定對象桶之后，可以配置數(shù)據(jù)淘汰功能，自動釋放設(shè)定時高性能文件系統(tǒng)綁定對象桶之后，可以配置數(shù)據(jù)淘汰功能，自動釋放設(shè)定時間內(nèi)沒有訪問過的文件數(shù)據(jù)內(nèi)容，僅保留文件元數(shù)據(jù)，數(shù)據(jù)內(nèi)容釋放后不占能文件存儲的緩存空間，再次訪問該文件時，將重新從對 ·21·快系統(tǒng)所有節(jié)點參與數(shù)據(jù)同步、并發(fā)度高；不慢依賴中轉(zhuǎn)機CPU/網(wǎng)絡(luò)開銷、客戶通過對象存儲增量對象事件通知，只同步增需要全量比對找出增量文件、速度象數(shù)據(jù)湖吞吐即可滿足性能訴求、加速層只同步發(fā)起、狀態(tài)展示等通過服務(wù)控制API集成中轉(zhuǎn)機復(fù)雜環(huán)境下變數(shù)多、穩(wěn)定性同步失敗會殘留垃圾、需要手工清存快恢的SDK，形成三級緩存加速技術(shù)，加速AI訓(xùn)練過程中的訓(xùn)練數(shù)據(jù)集讀取，CheckPoint快速保存及bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI技術(shù)概論>>圖3-2-4三級緩存加速技術(shù)吞吐。checkpoint保存及恢復(fù)加速:L3checkpoint讀寫加速SDK組件針對進(jìn)程級故障和JOB任務(wù)級故障等場景,對接pytorch/Mindspore/Deepspeed等主流大語言模型訓(xùn)練框架,專門針對A·22· ·23·3、AIServerless3、AIServerless訓(xùn)練Serverless作為一種云原生的應(yīng)用開發(fā)和運行模式，能夠?qū)㈤_發(fā)者從基礎(chǔ)設(shè)施的維護(hù)中解放出來，專對于AI算法工程師而言，數(shù)據(jù)清洗、特征工程、訓(xùn)練調(diào)優(yōu)是他們的強項，然而基礎(chǔ)設(shè)施的準(zhǔn)備和AI通用計算任務(wù)的算力需求比較容易評估，工程師可以根據(jù)業(yè)務(wù)模型提前進(jìn)行性能測試，得出不同業(yè)務(wù)型精度更需要通過多輪迭代優(yōu)化才能得到理想效果。因此，AI訓(xùn)練任務(wù)的算力需求不易提前獲得。為了保通用算力場景常見的資源效率提升手段就是彈性擴(kuò)縮，建立好單實例的業(yè)務(wù)并發(fā)量算力模型后，根據(jù)實際業(yè)務(wù)并發(fā)量進(jìn)行實例數(shù)量的調(diào)整，避免業(yè)務(wù)低谷期空閑實例造成浪費。對于AI訓(xùn)練任務(wù)而言，在實際執(zhí)行彈性擴(kuò)縮時，存在并行任務(wù)分片重新調(diào)度的問題。訓(xùn)練集群彈性擴(kuò)縮后，worker的數(shù)量發(fā)生變化，取既包括節(jié)點、超節(jié)點內(nèi)加速卡之間的通信拓?fù)?，也包括跨?jié)點的網(wǎng)絡(luò)拓?fù)?。AI訓(xùn)練任務(wù)為了提升效率，都會采用分布式并行策略。每個worker負(fù)責(zé)一部分?jǐn)?shù)據(jù)或張量的處理，各個worker完成后通過gather/ ·24·為準(zhǔn)確評估AI訓(xùn)練任務(wù)的算力需求，為算力消費提供指導(dǎo)，需要引入AI訓(xùn)練任務(wù)的資源畫像。以AI模型源代碼為輸入，提取模型的靜態(tài)計算圖?；谟嬎銏D進(jìn)行算子拆分，對計算過程中的資源用量進(jìn)行測算。同時根據(jù)設(shè)備網(wǎng)絡(luò)拓?fù)浜屯ㄐ艤y量（包含帶寬、時延等指標(biāo)構(gòu)建網(wǎng)絡(luò)通信模型。最后通過優(yōu)化算明彈性”，顧名思義就是彈性擴(kuò)縮不改變worker的數(shù)量，而是通過加速卡虛擬化技術(shù)，大模型分布式訓(xùn)練任務(wù)周期以周或者月為周期，集群規(guī)模在千卡甚至萬卡級別。在整個訓(xùn)練任務(wù)過程中會發(fā)生各種類型的故障，導(dǎo)致訓(xùn)練任務(wù)頻繁中斷，從而導(dǎo)致整體資源利用率低?？偨Y(jié)下來，大模型訓(xùn)練故障發(fā)生頻繁：模型越來越大，大規(guī)模訓(xùn)練集群涉及的硬件數(shù)量達(dá)到百萬至千萬級別，特別是高網(wǎng)絡(luò)帶寬對光模塊數(shù)量的要求越來越多，光模塊的故障率相對較高，導(dǎo)致大量的硬件潛在失效風(fēng)險。分布式訓(xùn) ·25·大量故障導(dǎo)致頻繁CKPT回滾，算力利用率低：訓(xùn)練故障恢復(fù)過程中，關(guān)鍵在于模型狀態(tài)的保存與恢復(fù)。傳統(tǒng)的checkpoint方法由于保存耗時較長，往往導(dǎo)致訓(xùn)練效率較低。據(jù)相關(guān)分析稱，OpenAI在故障自愈與訓(xùn)練任務(wù)快速恢復(fù)是一個系統(tǒng)性工程，涉及到準(zhǔn)入檢測、故障快速感知、任務(wù)快速恢復(fù)等在訓(xùn)練任務(wù)開始之前或者新節(jié)點加入集群之前，提前識別潛在故障點，可以防患于未然。相應(yīng)的技術(shù)基礎(chǔ)環(huán)境檢測：對節(jié)點的基礎(chǔ)配置（如驅(qū)動版本、OS版本等）、關(guān)階段二：故障快速感知節(jié)點故障：除了芯片故障外，節(jié)點還會出現(xiàn)其他各種類型的故障，比如磁盤只讀、K8S核心組件異常 ·26·帶外故障：大規(guī)模AI分布式訓(xùn)練，一般需要高性能網(wǎng)絡(luò)的支持。如果高性能網(wǎng)絡(luò)出階段三：任務(wù)快速恢復(fù)計算圖和算子編譯緩存：圖編譯緩存功能支持將圖編譯結(jié)果進(jìn)行磁盤持久化，當(dāng)訓(xùn)練任務(wù)重新運行時在線復(fù)位快速恢復(fù)：部分卡故障支持熱復(fù)位，比如ECC-Error故障。通過原地作業(yè)復(fù)位，無需任務(wù)重提供高效、靈活且可靠的AI服務(wù)。然而，隨著技術(shù)的深入發(fā)展和應(yīng)用場景的復(fù)雜化，這些方面都面臨著一AI推理任務(wù)同樣有采用彈性擴(kuò)縮提升資源效率的述求。相比訓(xùn)練任務(wù)，推理任務(wù)單次任務(wù)耗時短，也是請求/響應(yīng)的服務(wù)模式，類似通用計算的集群服務(wù)模式。問題在于，推理時長和資源消耗和用戶的輸入bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI技術(shù)概論>>動時延,需要引入基于容量預(yù)測的集群彈性擴(kuò)縮,在業(yè)務(wù)高峰期到來前開始準(zhǔn)備實例。集群容量預(yù)測可以采用基于統(tǒng)計的算法,基于集群歷史的容量在一定的時間區(qū)間內(nèi)計算如均值、峰值、方差等統(tǒng)計值,預(yù)測值由這些統(tǒng)計值組合計算得出。也可以采用傳統(tǒng)的機器學(xué)習(xí)方法,如將排隊論、傅里葉分析應(yīng)用到歷史數(shù)據(jù)的分析當(dāng)中,提取出數(shù)據(jù)的分布規(guī)律和周期特征,以此進(jìn)行預(yù)測。消減冷啟動時延的另一個方向是加速模型的加載。比如基于加速卡虛擬化的模型切換技術(shù),對于單卡可以完整加載的小模型,在進(jìn)行模型切換時,無需等待上一個模型的顯存完全釋放后,才開始下一個模型的加載。而是根據(jù)模型網(wǎng)絡(luò)的分層結(jié)構(gòu)將推理過程劃分為傳輸階段和執(zhí)行階段,不同模型的傳輸階段和執(zhí)行階段可以在加速卡內(nèi)流水線化并行處理,從而將模型的加載時延縮短至一個傳輸環(huán)節(jié)。又比如基于模型分層加載的預(yù)熱機制,先測量不同層的加載時長,僅對加載時長較大的層進(jìn)行預(yù)先加載,而非對模型進(jìn)行全量預(yù)熱,在推理任務(wù)效率和資源成本間求取一個平衡。(1)(1)LLM推理原理LLM大模型推理過程分為prefill和Decode兩個階段。prefill階段,會對prompt進(jìn)行分詞,Kvcache矩陣計算,生成首token;Decode階段,直接利用prefill階段計算出的kvcache及首token,自延將不斷增加。轉(zhuǎn)化為系統(tǒng)實現(xiàn)視角,參考云原生傳統(tǒng)AI服務(wù)的架構(gòu),可以表示為(為了避免過多的細(xì)節(jié),將負(fù)載均衡等一些常規(guī)的元素省略):圖3-3-1大模型推理系統(tǒng)基礎(chǔ)架構(gòu)·27·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI技術(shù)概論>>(2)(2)現(xiàn)狀與問題AI加速器內(nèi)存容量增長速度遠(yuǎn)低于大模型存儲需求的增長速度。典型的Transformer大模型的參數(shù)量數(shù)量和AI加速器內(nèi)存容量增長速度之間的鴻溝,意味著訓(xùn)練和推理一個模型需要更多數(shù)量的AI加速器,這將大幅增加AI訓(xùn)練和推理的成本。另外,增加AI加速器的數(shù)量主要是為了讓大模型能夠在AI加速器內(nèi)存中存儲得下,這通常會造成AI算力的利用率低。一方面大模型推理需要大量的顯存,另一方面為了加速模型推理,還需要新的顯存來做以存代算,比如kvcache技術(shù)。(4)(4)關(guān)鍵技術(shù)和價值載到大容量的共享彈性內(nèi)存池。計算層與內(nèi)存池通過高性能網(wǎng)絡(luò)總線相連,同時將數(shù)據(jù)傳輸與計算過程流水線并行,有效降低了內(nèi)存池訪存開銷。得益于大容量、高性能、共享訪問的彈性內(nèi)存池,顯存擴(kuò)展技術(shù)增大推理的批處理大小,從而提升AI推理的整體吞吐率。大容量、大帶寬的優(yōu)勢緩解了內(nèi)存墻問題。成可以在多個專用加速器(DSA)上運行的任務(wù),利用多卡的顯存來解決單卡顯存不足的問題。原理如圖所示:為了解決顯存容量問題,LLM推理后端需要從單體形態(tài)演變?yōu)榉植际酵评硇螒B(tài),以TP切分為2個分布式推理任務(wù)為例,如圖所示:圖3--3-2分布式推理后端·28·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI技術(shù)概論>>而分布式推理系統(tǒng),需要結(jié)合分布式計算框架+分布式推理兩個方面的技術(shù),前者將推理任務(wù)拆分為分拆為多個計算并行時需要考慮的問題,比如張量的切分,算子并行+集合通信等。在輸入比較多的場景,kvcache將極大的節(jié)省計算時間。為了獲取其收益,需要在系統(tǒng)中加入kvcache管理技術(shù):1)在計算之前,提前規(guī)劃好需要申請的kvcache地址空間,2)在計算的過程中,將根據(jù)輸入計算得出的K、V值,存放在kvcache中,3)下次需要使用對應(yīng)的K、V時,從對應(yīng)的cache地址直接讀取使用。但這只是kvcache管理的基本邏輯,放在分布式推理系統(tǒng)的上下文中,我們還需要考慮kvcache在多個計算節(jié)點上的生命周期管理,甚至節(jié)點之間的kvcache遷移問題。因此從整個系統(tǒng)的角度,我們會需要一個新增的kvcache管理微服務(wù),來實現(xiàn)上述邏輯的管理,如圖所示:圖3--3-3kvcache管理微服務(wù) ·30·力。因此，在某些場景下，將大模型推理的組件進(jìn)一步細(xì)分為Prefill組件和Decoding組件，依據(jù)計算側(cè)重的不同，合理搭配計算和存儲資源，進(jìn)一步降低系統(tǒng)的資源消耗。這樣推理后端又會產(chǎn)生變化，并且對首先要解決的就是Prefill和Decoding的計算如何銜接的問題。Prefill的處理相對簡單，跟的是滿足能耗、隱私保護(hù)和實時性等方面的需求。由于軟硬件分散部署在成百上千的不同位置上，管理這些分布式系統(tǒng)的方法課基于可觀測性、松耦合系統(tǒng)、聲明式API等范式，這些范式已經(jīng)在云計算中展現(xiàn)出將云原生技術(shù)應(yīng)用于邊緣環(huán)境已成為主流趨勢。作為云原生技術(shù)的底座，輕量靈活移植性高的容器技術(shù)天然匹配邊緣資源受限且異構(gòu)的場景，容器化的邊緣部署模式將占主導(dǎo)。另外，自動化、自恢復(fù)的容器 ·31·將Kubernetes集群概念直接應(yīng)用于邊緣環(huán)境的一個輕量化解決方案是rancher公司開發(fā)的K3s項孵化出許多的開源項目，其中的主流代表是KubeEdge。KubeEdge提供云端組件和邊緣組件，通過兩者之間的通信將云集群與邊緣節(jié)點連接起來，形成一個整體的集群。在云端，KubeEdge的組件旨在監(jiān)聽Apiserver，管理邊緣節(jié)點和設(shè)備信息，將集群的消息轉(zhuǎn)化并下發(fā)至邊緣節(jié)點。在邊緣端，KubeEdge對邊緣計算的發(fā)展使得在靠近數(shù)據(jù)源的邊緣設(shè)備上進(jìn)行人工智能計算和處理（即邊緣AI）成為必然的發(fā)模型壓縮通過減少參數(shù)和計算量提升推理效率，能夠適用于資源有限的邊緣設(shè)備，有利于基于容器的模型部署與資源分配，以及模型的快速更新迭代。模型壓縮方法如量化和知識蒸餾，可以在邊緣設(shè)備上實現(xiàn)高效推理，滿足實時性和資源限制需求。隨著邊緣計算和移動設(shè)備的普及，資源稀缺性問題如帶寬限制、計算能力和能源消耗變得突出。高分辨率視頻流和實時數(shù)據(jù)分析等資源密集型應(yīng)用加劇了資源競爭，而強大的安全算法增加了通信延遲和能源消耗。邊緣計算通過將任務(wù)卸載到附近節(jié)點緩解資源緊張，但動態(tài)拓?fù)浣Y(jié)構(gòu)和環(huán)境變化增加了通信性能和可靠性管理的難度。這些挑戰(zhàn)要求在云邊AI系統(tǒng)設(shè)計中采用靈活且適應(yīng) ·32·為了應(yīng)對以上挑戰(zhàn)，業(yè)界提出了多種大模型輕量化技術(shù)，包括混合專家架構(gòu)、邊緣友好的量化、邊緣混合專家（MoE）架構(gòu)在邊緣環(huán)境中具有廣泛應(yīng)用，通過整合多種數(shù)據(jù)源和分布式專家處理，實現(xiàn)高效的數(shù)據(jù)處理和決策。該架構(gòu)從各種輸入數(shù)據(jù)（如GPS、視頻、生物識別、多媒體內(nèi)容、激光雷達(dá)、速度信息、物聯(lián)網(wǎng)數(shù)據(jù)等）中提取有用信息，并通過預(yù)處理和稀疏門控策略選擇適當(dāng)?shù)膶＜疫M(jìn)行處理。專家執(zhí)行的任務(wù)包括但不限于自動駕駛、智慧城市、車路云、路徑預(yù)測、環(huán)境監(jiān)測。通過全局通信，所有專家共而減少模型的存儲需求和計算量。針對邊緣環(huán)境的低功耗處理器，一般會采用4位或更低的精度，以提升邊緣感知的知識蒸餾通過訓(xùn)練一個較小的模型（學(xué)生模型）來模仿一個較大的模型（教師模型）的行為，從而獲得一個輕量級但性能優(yōu)異的模型。該方法也可通過分層知識蒸餾的方法逐層學(xué)習(xí)教師模型的特自適應(yīng)模型壓縮用于邊緣設(shè)備工作環(huán)境多變、計算資源和電池電量也隨時變化的場景。該方法可以根據(jù)當(dāng)前設(shè)備的狀態(tài)，通過啟用或禁用某些神經(jīng)網(wǎng)絡(luò)層，或者調(diào)整量化精度，在性能和效率之間找到最佳平在人工智能場景中，AI任務(wù)的資源調(diào)度面臨著許多不確定性任務(wù)可以通過擴(kuò)容獲得更多的實例以保證服務(wù)的正常運行；在業(yè)務(wù)低谷期，通過縮容減少AI任務(wù)的實例以儲等資源消耗進(jìn)行監(jiān)控之外，還需要對AI任務(wù)的跨機跨卡的網(wǎng)絡(luò)流量和帶寬進(jìn)行監(jiān)控。然而，當(dāng)前云廠商提供的監(jiān)控工具（例如Prometheus）無 ·33·雖然容器技術(shù)提供了對CPU、內(nèi)存、存儲等資源的抽象，容器編排系統(tǒng)為容器資源管理提供了聲明式表達(dá)，但是為運行應(yīng)用的容器選擇合適的資源規(guī)格仍然是一個棘手的問題。在通用算力場景中，云廠商通過收集資源消耗的歷史數(shù)據(jù)，通過統(tǒng)計學(xué)或者機器學(xué)習(xí)算法對應(yīng)用進(jìn)行資源畫像，為容器的資源規(guī)格選擇同類型的實例，且根據(jù)并行策略的不同，實例之間的相互依賴關(guān)系復(fù)雜多變。同時，由于實例之間存在依賴關(guān)系且需要頻繁的數(shù)據(jù)同步操作，網(wǎng)絡(luò)帶寬在資源畫像中顯得至關(guān)重要。目前AI任務(wù)的資源畫像面臨以AI任務(wù)的資源需求往往是動態(tài)變化的。在推理場景中，根據(jù)AI任務(wù)請求的變個實例所需要的資源也是變化的。如何捕捉動態(tài)負(fù)載的資源使用特征，對于不同的AI任務(wù)，由于模型結(jié)構(gòu)的復(fù)雜度不同，對資源的需求差異也很明顯，因此需要資源畫像算法能夠?qū)Σ煌哪Ｐ瓦M(jìn)行學(xué)習(xí)。為了實現(xiàn)對模型多層次資源畫像：在大模型場景中，當(dāng)模型跨機跨卡部署的時候，AI任務(wù)的資源畫像不僅需要考慮單卡上計算子圖或者算子的資源消耗情況，還要考慮跨機跨卡通信對資源畫像的影響，因此需要一個將資源規(guī)格和并行策略都考慮在內(nèi)的多層次資源畫像，既可以從總體上對AI任務(wù)進(jìn)行畫像，也可以對分解之后的預(yù)訓(xùn)練模型和遷移學(xué)習(xí)：為了讓資源畫像功能能夠適用于更多的AI任務(wù)， ·34·學(xué)習(xí)等技術(shù)以減少畫像算法適用于多種模型的學(xué)習(xí)成本。預(yù)訓(xùn)練模型通常僅僅需要少量的算力進(jìn)行微調(diào)就修改實例的配置文件來動態(tài)調(diào)整資源的規(guī)格以實現(xiàn)垂直彈性。為了實現(xiàn)AI任務(wù)的垂直彈性，目前面臨以下于AI任務(wù)來說，單個主機上的硬件加速卡的數(shù)量是固定的，因此彈性擴(kuò)展也受限對運行中的實例進(jìn)行垂直彈性伸縮會引入不對運行中的實例進(jìn)行垂直彈性伸縮會引入不可避免的開銷。由于對實例的資源規(guī)格進(jìn)行調(diào)整時，需要中斷當(dāng)前實例并重啟，因此需要對實例內(nèi)的AI任務(wù)進(jìn)行中斷或者遷移。在大模型場景中，AI任務(wù)的中斷意味著需要回退模型的checkpoint，會造成算力的浪費，在推理場景中，AI任務(wù)的中斷也會造成請求的基于畫像和預(yù)測的彈性伸縮：基于資源畫像功能，對AI任務(wù)的資源需求進(jìn)行預(yù)混合彈性伸縮方法：將AI任務(wù)的垂直彈性伸縮和水平彈性伸縮結(jié)合起來，一方面對于可預(yù)測的負(fù)載需求變化可以使用垂直彈性伸縮方法；另一方面，對于垂直彈性無法滿足需求的場景下，可以使用水平彈性 ·35·AI任務(wù)的水平彈性是指動態(tài)地增加或者減少實例的數(shù)量以適應(yīng)AI任務(wù)的資源需求變化。智能HPA存使用率、硬件加速卡使用率等）發(fā)生變化時自動對Pod進(jìn)行擴(kuò)容或縮容。通過在資源管理平臺中設(shè)置相面臨以下的挑戰(zhàn)：據(jù)需要在不同的主機上的實例間傳輸和同步，因此進(jìn)行水平彈性伸縮時就不得不考慮網(wǎng)水平彈性伸縮不僅需要考慮實例數(shù)對AI任務(wù)性能的影響，還要考慮實例數(shù)對成本監(jiān)控AI任務(wù)相關(guān)的指標(biāo)，例如硬件加速卡的算力和顯存使用情跨機跨卡運行，因此也需要監(jiān)控網(wǎng)絡(luò)通信指標(biāo)。因此在設(shè)定觸發(fā)指標(biāo)的時候，需要考慮由于擴(kuò)展AI任務(wù)的pod的時候，實例需要一段時間來準(zhǔn)備資源和加載AI模型參數(shù)，因此不可避免地引入了冷啟動開銷。此外，在AI任務(wù)中由于模型參數(shù)較大，加載時間長，因此冷啟動的開銷也較大。冷啟動的時間會造成實例啟動運行的滯后，從而影 ·36·于這些類型的實例可以以折扣價格提供有效的資源，因此基于資源畫像功能可以將執(zhí)行時間較短的AI任務(wù)分配到這些實例上，在降低成本的同時也避免了這些實例因為資源創(chuàng)建新的實例來保障AI任務(wù)的正常運行，因此可以將水平彈性伸縮功能與故障檢測和基于資源畫像功能，配合AI任務(wù)的性能表現(xiàn)監(jiān)控，通過人工智能算法學(xué)習(xí)智能的擴(kuò)縮容規(guī)則，部署于智能HPA中。同時，通過實時監(jiān)控和增量學(xué)習(xí)不斷改進(jìn)智能為了減少冷啟動對AI任務(wù)性能的影響，開發(fā)和使用預(yù)熱技術(shù)，在資源需求低谷期保留一個最小數(shù)量的實例，而當(dāng)預(yù)測到需求高峰即將到來的時候，提前創(chuàng)建和啟動實加載時間，可以對AI模型進(jìn)行無損或者低損壓縮，同時對容器鏡像的大小也進(jìn)行相應(yīng)·37·云原生AI技術(shù)架構(gòu)白皮書云原生AI技術(shù)應(yīng)用>>oooo稀缺AI硬件資源未充分使用。GPU等AI硬件資源分散在用戶IDC、不同廠商的公有云集群等不同位置,導(dǎo)致資源利用率不高。一般不同的集群靜態(tài)分配給不同業(yè)務(wù)團(tuán)隊分開使用,當(dāng)一個團(tuán)隊使用完后,資源處于空閑狀態(tài)。而與此同時,其他需要使用資源的團(tuán)隊卻無資源可用。即分布在多個集群的稀缺AI硬件資源不能靈活高效地被使用。單集群可用性影響AI任務(wù)執(zhí)行。雖然kubernetes集群提供的節(jié)點、AZ等反親和部署能力,在單個節(jié)點或者整個AZ故障時,保證有一定的可用實例提供服務(wù),客觀上也提高了業(yè)務(wù)的可用性。但是當(dāng)集群控制面和數(shù)據(jù)面組件故障時,特別是集群版本的原地升級時,集群內(nèi)GPU驅(qū)動升級時,小概率的集群故障會引發(fā)了全局的業(yè)務(wù)斷服巖機。這種故障會導(dǎo)致正在向用戶提供服務(wù)的推理任務(wù)全部不可用,直接導(dǎo)致最終用戶業(yè)務(wù)受損。超大模型超出單集群資源上限。隨著訓(xùn)練的模型越來越復(fù)雜,模型參數(shù)數(shù)量也越來越龐大,對于AI資源的需求越來越大,經(jīng)常需要萬卡以上的GPU集群。當(dāng)資源規(guī)模超過一定量后這將超出單個集群的管理能力,如超出了單集群能管理節(jié)點上限。這就需要有一種機制在不能提升單集群管理規(guī)模的前提下,提供單集群兼容的的負(fù)載管理能力、AI任務(wù)調(diào)度能力,滿足大模型訓(xùn)練的需求場景。圖4-1-1多集群架構(gòu)·39·解決分布式環(huán)境資源分散、利用率不充分的問題的有效手段就是對這些資源的統(tǒng)一管理。即將分散的多個集群注冊到一個艦隊上進(jìn)行管理，構(gòu)建全局的資源視圖，在艦隊統(tǒng)一資源池上運行AI任務(wù)?；A(chǔ)設(shè)施管理無需分開維護(hù)一組AI集群，再靜態(tài)地分配給不同的團(tuán)隊使用，而是將艦隊分配個多個業(yè)務(wù)團(tuán)隊，在艦多集群的AI任務(wù)的調(diào)度支持分組調(diào)度，根據(jù)訓(xùn)練作業(yè)聲源，確保只有目標(biāo)資源滿足所有Pod同時運行時才會調(diào)度成功，否則不調(diào)度。同時調(diào)度算法也可此外，在多集群分布式環(huán)境下，通過描述各個集群的算力規(guī)模、資源類型、算力成本等因素，結(jié)合用戶提交的任務(wù)的偏好，綜合評價最優(yōu)的源調(diào)度策略，通過最低的資源成本完成業(yè)務(wù)要求。如可以控制在任務(wù)調(diào)度時優(yōu)先使用本地IDC內(nèi)的資源，當(dāng)IDC內(nèi)資源不能滿足要求時將任務(wù)分發(fā)到云分的資源彈性目標(biāo)，提高總體的資源利用率。同時，在多集群環(huán)境下，調(diào)度算法充分利用不同集群的不同單個集群自身的控制面數(shù)據(jù)面故障發(fā)生的幾率雖然比較小，但一旦發(fā)生將產(chǎn)生全局的業(yè)務(wù)故障。生產(chǎn)中的大部分案例發(fā)生在集群升級階段，特別是集群數(shù)據(jù)面組件或驅(qū)動和現(xiàn)網(wǎng)環(huán)境特有的業(yè)務(wù)的兼容性問題戶在升級過程中，選擇一個集群作為獨立的灰度集級成功后再升級另一個集云原生AI技術(shù)架構(gòu)白皮書云原生AI技術(shù)應(yīng)用>>使出現(xiàn)問題,也不會導(dǎo)致用戶最終業(yè)務(wù)不可用。在AI推理場景中,基于艦隊的多集群管理,當(dāng)識別到一個集群全部或個別的推理服務(wù)實例異常,會自動執(zhí)行故障倒換,將流量切換到另外一個集群上。同時將異常集群中的負(fù)載遷移到其他集群中,確保始終有足夠數(shù)量的負(fù)載實例向用戶提供服務(wù),以確保服務(wù)的可用性。這種結(jié)合了流量遷移和負(fù)載遷移的方式,保障了用戶推理業(yè)務(wù)的可用性,確保了總體服務(wù)質(zhì)量符合用戶期望。(3)(3)基于多集群構(gòu)建大規(guī)模訓(xùn)練資源池當(dāng)單集群的資源上限難以突破時,解決當(dāng)前超大規(guī)模和未來更大訓(xùn)練模型對資源極限需求的方案是通過構(gòu)造基于容器艦隊的多集群方案,提供資源的可擴(kuò)展性。圖4-1-3基于容器艦隊的多集群架構(gòu)在艦隊一層提供單和集群完全兼容的API和對象模型,像管理單集群一樣在多集群上發(fā)放描述訓(xùn)練任務(wù)的作業(yè)集合和各種資源。在艦隊層進(jìn)行全局的作業(yè)調(diào)度,將作業(yè)集合拆分成作業(yè)分發(fā)到子集群。在子集群內(nèi)基于集群的作業(yè)調(diào)度,將任務(wù)實例分發(fā)到對應(yīng)的資源上。同時在全局資源視圖上,當(dāng)某個集群資源不足或故障時,基于艦隊的全局調(diào)度可以在多集群間間協(xié)調(diào),動態(tài)地在其他集群重新投放。當(dāng)然在這種方式下,根據(jù)訓(xùn)練任務(wù)的需要,一般要求多集群資源的在一個參數(shù)面網(wǎng)絡(luò)平面下,同時在同一個數(shù)據(jù)面網(wǎng)絡(luò)平面下。通過這種方式可以突破單集群容量限制,大幅提升總體容量,滿足大規(guī)模模型不斷增長的需求。·41·隨著人工智能技術(shù)的不斷發(fā)展，越來越多的企業(yè)開始將AIAI推理業(yè)務(wù)存在明顯的波峰波谷現(xiàn)象，用戶請求頻繁時業(yè)務(wù)處于波峰狀態(tài)，資源需求量大，用戶請求量減少，業(yè)務(wù)處于波谷狀態(tài)，對應(yīng)資源需求降低。為保證推理業(yè)務(wù)SLA要求，平臺需根據(jù)業(yè)務(wù)峰值備貨AI訓(xùn)練和推理所需計算資源通過統(tǒng)一的集群管理，訓(xùn)推一體調(diào)度管理器通過資源分時復(fù)用與多業(yè)務(wù)驅(qū)·42·資源出讓策略：調(diào)度器根據(jù)系統(tǒng)運行現(xiàn)狀和用戶自定義信息計算當(dāng)前集群內(nèi)可以共享給AI訓(xùn)練任務(wù)的系統(tǒng)運行現(xiàn)狀包括但不限于AI推理任務(wù)的歷史提交規(guī)律任務(wù)填充策略：調(diào)度器根據(jù)AI推理任務(wù)共享出的計算資源選擇合適的AI訓(xùn)練任務(wù)進(jìn)行資源填充，需滿足兩個要求，首先訓(xùn)練任務(wù)符合共享資源量要求并最大化使用該部分共享資源量，保證當(dāng)前填充的訓(xùn)練任務(wù)擁有足夠資源運行；其次訓(xùn)練任務(wù)的計劃運行時長符合資源共享的時間段要求，并可以最大化利用該時段資源。同時對于滿足上述要求的AI訓(xùn)練任務(wù)按照優(yōu)選策略排序，選擇排序最靠前的任務(wù)完成填充。優(yōu)障高等級SLA任務(wù)優(yōu)先獲取集群資源，低等級SLA網(wǎng)絡(luò)隔離策略：從安全性方面考慮，推理和訓(xùn)練混合部署運行需具備參數(shù)面網(wǎng)絡(luò)隔離能力。當(dāng)前參數(shù)面網(wǎng)絡(luò)隔離方案通過節(jié)點的時分復(fù)用實現(xiàn)，調(diào)度器需分發(fā)業(yè)務(wù)時，需確保同一節(jié)點在同一時間點運行同一類業(yè)務(wù)，即單個計算節(jié)點內(nèi)同時運行的業(yè)務(wù)是推理任務(wù)或者訓(xùn)練任務(wù)。AI推理任務(wù)波谷時期，調(diào)度器共享租期回收策略：多業(yè)務(wù)驅(qū)逐決策器根據(jù)AI推理任務(wù)共享資源的租期進(jìn)行資源回收，到期后自沖突檢測驅(qū)逐策略：多業(yè)務(wù)驅(qū)逐決策器進(jìn)行業(yè)務(wù)沖突的實時監(jiān)測，當(dāng)集群內(nèi)存在高SLA等級任務(wù)因資源不足而無法調(diào)度的場景，或者集群內(nèi)運行中的業(yè)務(wù)SLA無法得到保障的場景，系統(tǒng)認(rèn)定當(dāng)前存在業(yè)務(wù)沖·43·合業(yè)務(wù)歷史被中斷次數(shù)進(jìn)行排序，優(yōu)先選擇中斷次數(shù)少的業(yè)務(wù)進(jìn)行驅(qū)逐，避免同一個統(tǒng)計訓(xùn)練作業(yè)的運行時長，并根據(jù)同類業(yè)務(wù)的歷史運行規(guī)律預(yù)估其剩余時長，優(yōu)可能分布在節(jié)點的網(wǎng)絡(luò)高性能連通域內(nèi)，釋放的資源可以為新調(diào)度業(yè)務(wù)提供更高的計在現(xiàn)今單卡算力膨脹的時代，針對微量AI資源訴求場景，例如圖像識別、語音識別等等·44·劃分為多個獨立的GPU實例，每個實例都可以有自己的GPU內(nèi)存、于它只支持固定比例的GPU資源切分。這意味著用戶不能自由定義任意大小的GPU實例，而必須從預(yù)設(shè)細(xì)粒度的切分，模擬出多個虛擬的XPU設(shè)備。這種切分不僅包括計算單元，還涉及到顯存的劃分，確保每資源按需動態(tài)分配：XPU虛擬化支持按需分配XPU的計算單元、顯存等資源，可以將XPU資源切分成更小的單位進(jìn)行分配，而不是僅僅以整個XPU或大塊XPU資源為單位，提高了資源使用的靈活性和效XPU資源的能力。這種機制使得資源能夠更加高效、靈活地被多個容器或虛擬機共享，同時確保每個應(yīng)用用情況，其中關(guān)鍵監(jiān)控指標(biāo)包括XPU算力使用率、顯存使用量等。XPU虛擬化監(jiān)控指標(biāo)與AI云原生基礎(chǔ)顯存碎片：顯存和通用物理內(nèi)存一樣，在物理上存在連續(xù)顯存的概念，當(dāng)應(yīng)用程序使用顯存時，不同的應(yīng)用程序規(guī)律不同，因使用顯存的大小、申請釋放的頻率不同，不可避免的導(dǎo)致產(chǎn)生顯存碎片。而不能申請釋放開銷：顯存的申請釋放涉及到從軟件到硬件的開銷，包括軟件申請時不同特權(quán)級切換的CPU開銷，內(nèi)核態(tài)訪問物理資源帶來的PCI帶寬開銷，以及顯存申請釋放過程中需要清零和刷新顯存操作帶來的開銷。因此和解決通用內(nèi)存的思路相似，需要盡可能減少應(yīng)用在使用顯存時涉及的各個節(jié)點影響，最通塊顯存區(qū)域故障、訪問顯存的通道故障。需要提供技術(shù)能夠更高效地發(fā)現(xiàn)顯存亞健康狀態(tài)，通過提供故障可以本地使用（增加可靠性加固）、也可以通過高速網(wǎng)絡(luò)協(xié)議訪問其它物理節(jié)點的顯存。用戶態(tài)·45··45··46·如應(yīng)用程序顯存池化原理介紹的所述，設(shè)備層顯存池化屬于驅(qū)動側(cè)對顯存的管理，設(shè)備層顯存池化原理基于驅(qū)動的實現(xiàn)框架，內(nèi)存管理機制在設(shè)備層做內(nèi)存API的處理，不僅可以在單個物理機上將其它XP和傳統(tǒng)內(nèi)存面臨的問題一樣，顯存在使用中顯存硬件故障的檢測，硬件故障和傳統(tǒng)內(nèi)存面臨的問題一樣，顯存在使用中顯存硬件故障的檢測，硬件故障的容錯需要經(jīng)過可靠性加固處理，以減少顯存異常對業(yè)務(wù)的影響?？梢酝ㄟ^兩個b）通過定期支持顯存快照，在顯存異常后，異常上報系統(tǒng)支持應(yīng)用做業(yè)務(wù)高生產(chǎn)效率與質(zhì)量。然而工業(yè)設(shè)備通常存在數(shù)據(jù)無法共享、網(wǎng)絡(luò)瓶頸等問題，導(dǎo)致數(shù)據(jù)集在地理上天然分這些場景對實時性要求較高，傳統(tǒng)的AI技術(shù)需要將采樣數(shù)據(jù)上傳到云中心帶來的高時延無法滿足毫秒級的云原生AI技術(shù)架構(gòu)白皮書云原生AI技術(shù)應(yīng)用>>實時響應(yīng)需求。另外對于AR、VR、互動直播、視頻監(jiān)控等場景,數(shù)據(jù)量大,資源用量大,對安全隱私的要求比較高,無法實現(xiàn)將所有采集數(shù)據(jù)上傳到云端?；谝陨蠎?yīng)用場景,面對邊緣AI可能存在的資源受限、數(shù)據(jù)孤島、小樣本以及數(shù)據(jù)異構(gòu)等問題,主要云邊協(xié)同AI基于云側(cè)算力和邊緣側(cè)數(shù)據(jù)合作完成持續(xù)推理和訓(xùn)練,以云端知識庫作為中心,實現(xiàn)跨邊的知識共享并處理邊緣端任務(wù),同時持久化和維護(hù)云端知識。圖4-3-1云邊協(xié)同AI框架云邊協(xié)同AI框架從接口、性能、算法等多個方面進(jìn)行優(yōu)化。在接口方面,框架提供云邊協(xié)同的lib庫了云邊通信、邊緣存儲的優(yōu)化,使得云邊協(xié)同更高效;在算法方面,集成了增量學(xué)習(xí)、聯(lián)邦學(xué)習(xí)等多種適合邊緣的訓(xùn)練推理算法,以下從協(xié)同推理和協(xié)同訓(xùn)練兩個方面介紹云邊協(xié)同AI的關(guān)鍵技術(shù)?！?7··48·協(xié)同推理將推理性能較強的云端作為推理后端來提升推理精度。對推理來說，邊緣端的推理可以獲得更短的時延和更高的吞吐量，而云上的推理則可以獲得更好的推理模型。云邊協(xié)同推理通過難例檢測算法對邊緣端新數(shù)據(jù)進(jìn)行判別，將簡單樣本在邊緣端推理，難例樣本發(fā)送到云端處理。簡單的樣本通常占大多始數(shù)據(jù)在邊緣端進(jìn)行本地推理，再將模型參數(shù)傳到云端進(jìn)行匯聚，以充分利用分散在不同邊緣端的數(shù)據(jù)。主要用于解決AI算法在工業(yè)落地時所面臨的“數(shù)據(jù)孤島”問題，在保障大數(shù)據(jù)交換時的信息安全、保護(hù)終端數(shù)據(jù)和個人數(shù)據(jù)隱私的前提下，在多參與方或多計算節(jié)點之間開展高效率的機器學(xué)針對邊緣小樣本和邊緣數(shù)據(jù)異構(gòu)的問題，云邊協(xié)同的增量學(xué)習(xí)對單個租戶從時間的維度幫助提升模型效果。通過增量學(xué)習(xí)，云端持續(xù)在邊緣端監(jiān)控生成的新數(shù)據(jù)并學(xué)習(xí)新知識，利用云邊協(xié)同框通過云邊協(xié)同AI，無需直接將所有邊緣端的原始數(shù)據(jù)全部傳輸?shù)皆贫耍部杀苊鈱⒃紨?shù)據(jù)從其本地邊緣端存儲庫傳輸?shù)狡渌吘壎讼到y(tǒng)中執(zhí)行推理，對于由于數(shù)據(jù)隱私或者合規(guī)等原因?qū)е聰?shù)據(jù)無法遷移時尤其關(guān)鍵；可利用聯(lián)邦學(xué)習(xí)或者遷移學(xué)習(xí)，基于所有邊緣端的完整數(shù)據(jù)集進(jìn)行高精度建模；可基于歷史和更新數(shù)據(jù)，持續(xù)訓(xùn)練和改進(jìn)邊緣端的機器學(xué)習(xí)模型，在邊緣端自動補充數(shù)據(jù)實·49·模型如何快速部署，快速提供推理API，也成為一個AI服務(wù)提供商的棘手問題。大模型對并行計算硬件的需求已經(jīng)不再是一塊小的推理芯片能解決的，甚至需要多塊高性能GPU和NPU協(xié)作，才能完成大模經(jīng)成為AI應(yīng)用部署的首選。本章將介紹在云原生環(huán)境中，如何實現(xiàn)大模型的快速部署，并提供性能參數(shù)監(jiān)AI大模型從訓(xùn)練到部署。用戶在對基礎(chǔ)大模型進(jìn)行微調(diào)和優(yōu)化以后，需要將其轉(zhuǎn)化為可部署格式，并存儲到響應(yīng)網(wǎng)絡(luò)存儲位置(不推薦直接打包到容器鏡像中)，根據(jù)部署框架的不同，模型的參數(shù)存儲格式可能有差異。隨后根據(jù)不同的部署框架，準(zhǔn)備推理的鏡像，并選擇環(huán)境進(jìn)行部署。部署后通過ELB等方式暴境提供的各種監(jiān)控和運維手段，實時監(jiān)控推理集群的資源占用和性能瓶頸。配置相應(yīng)的彈性策略實現(xiàn)推理實例的自動彈性擴(kuò)縮容。最后，通過包括模型推理的準(zhǔn)確性、吞吐和時延性能等數(shù)據(jù)，優(yōu)化模型并重復(fù)上·50·Inference)、RayServe因其對大模型推理的優(yōu)化、更好地適應(yīng)大模型接口和數(shù)據(jù)格式、以及大模型的分部署推理訴求等，獲得了更多的關(guān)注。而這其中，vLLM又因其極高的吞吐和高效的顯存使用率，以及和蔽了應(yīng)用擴(kuò)縮容、網(wǎng)絡(luò)、運行狀況檢查和服務(wù)器配置的復(fù)雜性，為大模型部署帶來GPU自動擴(kuò)縮容、和將模型存儲到成本相對較低的對象存儲系統(tǒng)中。雖然對象存儲價格低廉，擴(kuò)展性好，但是對于模型的加載模型加載就是將模型完整讀取載入顯存的過程，在推理服務(wù)部署時需要模型加載過程。加載過程需要從存儲系統(tǒng)中單線程順序讀取，影響速度的關(guān)鍵因素是單線程順序讀取時的吞吐量。而對象存儲由于遠(yuǎn)離運行中的實例，導(dǎo)致其加載速度受到網(wǎng)絡(luò)帶寬等因素限制。尤其是在Serverless場景下，推理實例無法快因此對于存儲在對象桶中的大模型文件，如果要實現(xiàn)Serverless部署，還需要在近計算側(cè)部署一套緩·51·云原生技術(shù)為應(yīng)用的監(jiān)控和運維提供了豐富的組件支持。對于推理性能的監(jiān)控，可以通過Prometheus+Grafana實現(xiàn)可視化的性能監(jiān)控dashboard和豐富的組合查詢能力。對于分散在推理集群有效的GPU驅(qū)動管理對于確保AI系統(tǒng)的穩(wěn)定運行、最大化計算效率和促進(jìn)創(chuàng)新至關(guān)重要。GPU硬件廠商會定期更新驅(qū)動程序來修復(fù)已知的問題和安全漏洞，引入新的特性，優(yōu)化硬件性能，因此定期更新的潛力，支撐AI技術(shù)的快速發(fā)展和廣泛應(yīng)用同的內(nèi)核版本和不同的應(yīng)用場景，以上都是影響GPU驅(qū)動升級影響業(yè)務(wù)：GPU硬件驅(qū)動升級通常都會導(dǎo)致服務(wù)器上的AI應(yīng)用中核版本等，建立驅(qū)動程序和兼容性依賴的匹配關(guān)系，運維人員可輕松獲取AI業(yè)務(wù)可用的驅(qū)動版本和推薦的利用kubernetes的應(yīng)用編排能力，將驅(qū)動安裝和升級流程容器化實現(xiàn)驅(qū)動管理自動化。kubernetes將業(yè)務(wù)影響降到最低。此外對于不可中斷的業(yè)務(wù)可制定閑時升級策略，節(jié)點上AI業(yè)務(wù)全部結(jié)束后進(jìn)行驅(qū)動·52· ·53·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI行業(yè)實踐>>社交平臺RB基本上涵蓋了互聯(lián)網(wǎng)行業(yè)的所有典型場景,包括大規(guī)模搜索業(yè)務(wù)、推薦業(yè)務(wù)、廣告文案、筆最新的大模型技術(shù)以及自身的平臺,構(gòu)建了云原生AI平臺。云原生AI平臺分層架構(gòu)如圖5-1所示,平臺層包含了AI模型從開發(fā)、樣本生成、模型訓(xùn)練、數(shù)據(jù)管先級調(diào)度能力以及失敗重試功能。工具提供灰度發(fā)布、命令行以及智能的巡檢。圖5-1-1業(yè)務(wù)架構(gòu)圖·54·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI行業(yè)實踐>>kubernetes提供了良好的異構(gòu)資源統(tǒng)一管理的能力,RB在此基礎(chǔ)上管理了Cpu、NvidiaGPU等多種異構(gòu)資源。在資源層,RB采取了典型的多云方案,提供了豐富的存儲類型以及跨機房、跨云、跨地域的多種網(wǎng)絡(luò)傳輸類型。隨著RB業(yè)務(wù)的快速增長以及大模型技術(shù)的引入,RBAI平臺面臨的兩大核心的挑戰(zhàn):一是,如何綜合考慮訓(xùn)練、推理平臺,提升整體異構(gòu)資源的利用率,降低成本?二是,大規(guī)模分布式訓(xùn)練中,如何在單任務(wù)達(dá)到千卡甚至萬卡規(guī)模時,保障高計算效率和高穩(wěn)定性?圖5-1-2調(diào)度業(yè)務(wù)架構(gòu)圖調(diào)度器實現(xiàn)了對AI任務(wù)和在線任務(wù)的統(tǒng)一調(diào)度,然后將訓(xùn)練任務(wù)和近現(xiàn)任務(wù)部署到一個集群進(jìn)行混部,在近現(xiàn)業(yè)務(wù)的低谷期,調(diào)度訓(xùn)練任務(wù)填充到閑置的資源,保證GPU資源的高利用率。在線服務(wù)或近現(xiàn)服務(wù)對時延敏感,對SLO有更高的要求,如果在提升利用率的同時保障在線服務(wù)或近現(xiàn)服務(wù)的SLO是一個關(guān)鍵的問題,混部平臺提供了熱點檢測、快速避讓,離線GPU壓制等技術(shù),在線任務(wù)業(yè)務(wù)洪峰來臨,混部系統(tǒng)及時識別干擾和資源競爭,將離線任務(wù)進(jìn)行壓制,極端情況下,會根據(jù)算力優(yōu)先級,驅(qū)逐優(yōu)先級低的離線任務(wù)保障在線服務(wù)的快速響應(yīng),該方案在該社交平臺取得了顯著的收益,如圖所示,整體的集群利用率保持在80%左右?！?5·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI行業(yè)實踐>>圖5-1-3資源利用提升對比圖在資源調(diào)度層,對GPU進(jìn)行了虛擬化,研發(fā)了VGPU技術(shù),調(diào)度器會調(diào)度多個容器來共享使用一張卡提升利用率,為了避免多個容器對現(xiàn)存以及算力的競爭,VGPU方案還提供了顯存隔離和算力隔離。為了應(yīng)對單任務(wù)千卡甚至萬卡的性能及穩(wěn)定性的挑戰(zhàn),進(jìn)行了很多技術(shù)的探索,從多個方面進(jìn)行系統(tǒng)優(yōu)化。圖5-1-4計算效率和調(diào)度優(yōu)化方向圖5-1-5計算網(wǎng)絡(luò)示意圖隨著模型和參數(shù)的快速膨脹,模型訓(xùn)練過程,任務(wù)間的數(shù)據(jù)和參數(shù)通信量越來越大,網(wǎng)絡(luò)成為了關(guān)鍵瓶頸,如何通過網(wǎng)絡(luò)拓?fù)涞母兄{(diào)度增強,釋放和發(fā)揮硬件網(wǎng)絡(luò)的極限性能是非常關(guān)鍵的。RBAI平臺在調(diào)數(shù)據(jù)遷移,降低網(wǎng)絡(luò)帶寬消耗?！?6·bb云原生AI技術(shù)架構(gòu)白皮書 云原生AI行業(yè)實踐>>在計算節(jié)點內(nèi),AI平臺提供了GPU拓?fù)湔{(diào)度來加速訓(xùn)練,Agent負(fù)責(zé)Nvlink的拓?fù)浒l(fā)現(xiàn)和上報,scheduler根據(jù)拓?fù)滟Y源以及容器資源請求給出最佳的決策。對于網(wǎng)絡(luò)數(shù)據(jù)傳輸中常見的擁塞,通過定等各個維度進(jìn)行了優(yōu)化增強。大模型訓(xùn)練周期長,目前普遍故障率比較高,尤其是訓(xùn)練集群規(guī)模擴(kuò)大到數(shù)萬個GPU,軟件和硬件自檢診斷。在實踐中取得非常好的效果。圖5-1-6AI業(yè)務(wù)數(shù)據(jù)流圖該企業(yè)的云原生AI平臺已深耕多年,未來會從彈性、加速