【華為云中國信通院】2024云原生AI技術(shù)架構(gòu)白皮書6718mb

白皮書編制組華為云計算技術(shù)有限公司葉坤奇 張 琦 張永明 蔡智源 王雷博 魏鵬程 陶 希 陳佳敦 朱佳瑋 馬紅偉左鵬飛 付森波 張超盟 范恒龍 鮑 玥 馮紹寶 朱 磊中國信息通信研究院云計算與大數(shù)據(jù)研究所劉如明 杜 嵐行吟信息科技（上海）有限公司徐瑞文 胡偉琪 余 奕 陳 磊 熊 峰第四范式（北京）技術(shù)有限公司李孟軒遠(yuǎn)盟康健科技有限公司楊 宇 陳 浩復(fù)旦大學(xué)彭 鑫 沈立煒 陳碧歡01 背景和前言大模型開創(chuàng)智能時代的新紀(jì)元，AI

產(chǎn)業(yè)迎來新一輪創(chuàng)新浪潮……………02云原生助力AI

產(chǎn)業(yè)突破發(fā)展瓶頸，云原生AI

成為產(chǎn)業(yè)發(fā)展新范式………02云原生

AI

基礎(chǔ)設(shè)施發(fā)展和挑戰(zhàn)2.1

云原生AI

技術(shù)的演進(jìn)…………………………052.2 算力訴求井噴，AI

產(chǎn)業(yè)面臨挑戰(zhàn)……………06云原生

AI

技術(shù)概論3.1

云原生AI

資源管理系統(tǒng)建設(shè)要點……………093.2

云原生AI

訓(xùn)練系統(tǒng)建設(shè)要點…………………153.3

云原生AI

推理系統(tǒng)建設(shè)要點…………………263.4

云原生AI

邊緣云系統(tǒng)建設(shè)要點………………303.5

彈性伸縮，應(yīng)對

AI

任務(wù)浪涌挑戰(zhàn)……………32云原生

AI

技術(shù)應(yīng)用4.1

云原生AI

跨地域多集群協(xié)同…………………384.2

云原生AI

算力效能優(yōu)化………………………414.3

云原生AI

云邊協(xié)同計算………………………464.4 大模型云原生化解決方案……………………494.5

云原生AI

設(shè)備驅(qū)動管理………………………51云原生

AI

行業(yè)實踐5.1 社交平臺

RB

云原生

AI

平臺應(yīng)用加速實踐…………………545.2

AI

解決方案提供商FP

多場景AI

云原生化實踐……………585.3 醫(yī)療科技公司

HL

云原生

AI

智能醫(yī)療實踐…………………60目錄CONTENTS云原生

AI

技術(shù)架構(gòu)白皮書 背景和前言·01·大模型開創(chuàng)智能時代的新紀(jì)元，AI

產(chǎn)業(yè)迎來新一輪創(chuàng)新浪潮云原生助力

AI

產(chǎn)業(yè)突破發(fā)展瓶頸，云原生

AI

成為產(chǎn)業(yè)發(fā)展新范式背景和前言01PART

云原生

AI

技術(shù)架構(gòu)白皮書 背景和前言·02·1.1 大模型開創(chuàng)智能時代的新紀(jì)元，AI

產(chǎn)業(yè)迎來新一輪創(chuàng)新浪潮AI

軟件及應(yīng)用市場持續(xù)增長，AI

大模型成為產(chǎn)業(yè)主要增長點。據(jù)IDC

估計，2026

年中國人工智能軟件及應(yīng)用市場規(guī)模將達(dá)到

211

億美元，各行業(yè)的

AI

需求極大地推動著

AI

市場增長。隨著數(shù)字經(jīng)濟、元宇宙等概念的逐漸興起，人工智能進(jìn)入大規(guī)模落地應(yīng)用的關(guān)鍵時期

,

但其開發(fā)門檻高、應(yīng)用場景復(fù)雜多樣、對場景標(biāo)注數(shù)據(jù)依賴等問題開始顯露，阻礙了規(guī)?；涞?。以ChatGPT

為代表的AI

大模型的橫空出世改變了這一局面。憑借其優(yōu)越的泛化性、通用性、遷移性，AI

大模型為人工智能大規(guī)模落地帶來新的希望。面對人工智能的各種挑戰(zhàn)，AI

大模型的出現(xiàn)提供了通用化解決方案，從無標(biāo)注數(shù)據(jù)中通過自監(jiān)督學(xué)習(xí)獲取大量“知識”，實現(xiàn)用更統(tǒng)一的方式推動人工智能產(chǎn)業(yè)落地。廣泛智能需求驅(qū)動AI

產(chǎn)業(yè)不斷創(chuàng)新，大模型助力各行業(yè)生產(chǎn)力變革。隨著辦公、制造、金融、醫(yī)療、政務(wù)等場景中降本增效、生產(chǎn)自動化、降低風(fēng)險、提高診斷準(zhǔn)確率、提高政務(wù)服務(wù)效率等多方面的AI

智能需求，AI產(chǎn)業(yè)迎來了井噴式的創(chuàng)新和發(fā)展。憑借在文字、語音、圖像、視頻等多模態(tài)處理能力上的躍遷，AI

大模型搖身變?yōu)椤爸怼?、“專家”走入辦公室、制造車間、金融市場、醫(yī)療機構(gòu)、政務(wù)大廳，結(jié)合傳統(tǒng)軟件使得各個行業(yè)更加智能化、自動化。AI

大模型已然改變了我們的生活和工作的方方面面，成為各個行業(yè)不可或缺的重要助手。1.2 云原生助力

AI

產(chǎn)業(yè)突破發(fā)展瓶頸，云原生

AI

成為產(chǎn)業(yè)發(fā)展新范式AI

產(chǎn)業(yè)面臨數(shù)據(jù)、算法、算力等多方面發(fā)展瓶頸。據(jù)

IDC

統(tǒng)計

,

中國數(shù)據(jù)規(guī)模將從

2021

年的

18.51ZB增長至

2026

年的

56.16ZB，年均增長速度

CAGR

為

24.9%，增速位居全球第一。隨著數(shù)據(jù)量的高速增長，數(shù)據(jù)特征高維、模態(tài)格式多樣的趨勢也逐漸明顯，對數(shù)據(jù)的

AI

建模也相應(yīng)地更加復(fù)雜，計算復(fù)雜度會隨之呈指數(shù)增加，數(shù)據(jù)標(biāo)注難度也會增加。同時，海量的數(shù)據(jù)將不可避免帶來更大的數(shù)據(jù)噪聲問題、數(shù)據(jù)偏見風(fēng)險。與此同時，AI

應(yīng)用場景更加多元化、復(fù)雜化，往往需要對多個任務(wù)進(jìn)行深度融合和統(tǒng)一建模，這意味著廠商需要針對不同場景、不同任務(wù)開發(fā)大量的算法和模型，增加了

AI

應(yīng)用的開發(fā)難度。算力方面，需要針對不同的場景和高性能計算能力進(jìn)行拓展融合

,

滿足研發(fā)企業(yè)的多芯部署、分布式優(yōu)化、高性能計算等需求，這涉及了計算資源的靈活調(diào)度和統(tǒng)一運營管理，給企業(yè)

AI

創(chuàng)新帶來了額外的成本。云原生

AI

成為

AI

產(chǎn)業(yè)發(fā)展的新范式。為了突破

AI

產(chǎn)業(yè)的發(fā)展瓶頸，云原生

AI

技術(shù)應(yīng)運而生。一方面Kubernetes

的云原生可以有效管理各類網(wǎng)絡(luò)、存儲和計算資源，已逐步演變?yōu)閷嶋H上的云操作系統(tǒng)，服務(wù)

云原生

AI

技術(shù)架構(gòu)白皮書 背景和前言·03·于私有云、公有云以及混合云環(huán)境?；谄涓呖捎锰匦?，云原生系統(tǒng)可通過自動故障恢復(fù)機制在故障發(fā)生時迅速恢復(fù)服務(wù)，確保

AI

應(yīng)用的穩(wěn)定運行。其次，利用

Kubernetes

自動伸縮功能帶來的出色擴展性，云原生可以根據(jù)

AI

應(yīng)用需求快速增加或減少計算資源，滿足不同場景下的計算需求。同時，云原生具備良好的兼容性，可以與各種

AI

框架和工具無縫集成，實現(xiàn)

AI

應(yīng)用的快速開發(fā)和部署。此外，云原生提供了豐富的計算（如

CPU

和

GPU）、網(wǎng)絡(luò)和存儲能力，并提供隔離和受控共享機制，加速了

AI

應(yīng)用開發(fā)的效率和性能，并降低了企業(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)中的潛在威脅或弱點。用于檢測異常網(wǎng)絡(luò)行為的

AI

模型可以輕松地用于保護(hù)工作負(fù)載或在邊緣部署中的一組集群，加強企業(yè)對新興網(wǎng)絡(luò)威脅的防御。本白皮書重點關(guān)注云原生

AI

基礎(chǔ)設(shè)施層支持

AI

開發(fā)和使用，結(jié)合云原生開源生態(tài)發(fā)展現(xiàn)狀和行業(yè)實踐，深入分析云原生

AI

技術(shù)落地所面臨的技術(shù)挑戰(zhàn)并給出具體的技術(shù)指導(dǎo)方案。·03·云原生

AI

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

AI

基礎(chǔ)設(shè)施發(fā)展和挑戰(zhàn)·04·云原生

AI

技術(shù)的演進(jìn)算力訴求井噴，AI

產(chǎn)業(yè)面臨挑戰(zhàn)云原生

AI

基礎(chǔ)設(shè)施發(fā)展和挑戰(zhàn)02PART

云原生

AI

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

AI

基礎(chǔ)設(shè)施發(fā)展和挑戰(zhàn)·05·云原生技術(shù)本質(zhì)上是基礎(chǔ)設(shè)施云化和與之配套的服務(wù)（例如

CI/CD

就是如何在云化的基礎(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)能力。這一章將簡短地回顧一下云原生

AI基礎(chǔ)設(shè)施的技術(shù)演變歷程，我們會看到如今云原生

AI

技術(shù)面臨的挑戰(zhàn)的來源。2.1 云原生

AI

基礎(chǔ)設(shè)施的演進(jìn)2018

年圖靈獎獲得者計算機體系結(jié)構(gòu)泰斗約翰

·

軒尼詩

(John

Hennessy)

和戴維

·

帕特森

(DavidPattArchitecture)

的演講①，指出摩爾定律

(Moore’s

Law)

和登納德定律(Dennard

Scaling

Law)

走到了盡頭，處理器的晶體管密度和單位面積功耗已接近極限，處理器的性能提升不再遵循摩爾定律，后摩爾定律時代到來。AI

技術(shù)的發(fā)展和新的軟硬件接口抽象為云原生基礎(chǔ)設(shè)施帶來了新的挑戰(zhàn)和機遇，以面向特定領(lǐng)域體系結(jié)構(gòu)的能效。2022

年

11

月

30

日

OpenAI

公司推出了智能聊天機器人

ChatGPT，在發(fā)布后的

2

個月內(nèi)用戶數(shù)量就突破

1工業(yè)界對

AGI

從學(xué)術(shù)研究走進(jìn)實際的商業(yè)應(yīng)用有了前所未有的信心，各類基于

Transformer

架構(gòu)的

AIGC

大模型應(yīng)用如雨后春筍，國內(nèi)也出現(xiàn)了百模大戰(zhàn)的態(tài)勢，更進(jìn)一步出現(xiàn)了

Stable

Diffusion

和

Sora

等多模態(tài)大模型。在近幾年的大模型研究和工程實踐中，業(yè)界發(fā)現(xiàn)模型的訓(xùn)練數(shù)據(jù)、參數(shù)量和計算量越大，模型的效果越好，模型規(guī)模與模型效果呈現(xiàn)顯著的正相關(guān)，雖然學(xué)術(shù)界存在爭議，但大模型的

Scaling

Law

仍然是業(yè)界的基本共識。為應(yīng)對大模型對算力、存儲（帶寬、容量）需求，必須把大量加速卡和服務(wù)器節(jié)點通過高速總線和網(wǎng)絡(luò)連接起來，利用節(jié)點內(nèi)總線（Scale-Up）和節(jié)點間網(wǎng)絡(luò)（Scale-Out）的層次化擴展能力，構(gòu)建大規(guī)模

AI集群以提供充足的算力供應(yīng)，隨著模型尺寸的持續(xù)增長，AI

集群的規(guī)模也越來越大。典型的

AI

集群具有兩個或三個網(wǎng)絡(luò)平面及一個高速總線平面，分別是：前端網(wǎng)絡(luò)平面，用于集群管理和

AI

作業(yè)的調(diào)度發(fā)放；后端網(wǎng)絡(luò)（Scale-out

或

Back-end）平面，用于擴展多

AI

服務(wù)器節(jié)點，通過高性能網(wǎng)絡(luò)

Infiniband

或以太網(wǎng)①

https://www.jiqizhixin.com/articles/2019-01-30-12

云原生

AI

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

AI

基礎(chǔ)設(shè)施發(fā)展和挑戰(zhàn)·06·把不同節(jié)點的

GPU/NPU

卡通過

RDMA

協(xié)議連通起來，主要用于模型參數(shù)的數(shù)據(jù)同步（注：也有廠商稱之為參數(shù)平面）；存儲網(wǎng)絡(luò)，通過專用的存儲網(wǎng)卡和交換機將訓(xùn)練節(jié)點和存儲設(shè)備連接起來，用于訓(xùn)練數(shù)據(jù)讀取和模型快照（Checkpoint）存??；高速總線（Scale-Up

link）平面，通過高帶寬高可靠的片間總線（如：PCIe/NVlink

等）將節(jié)點內(nèi)加速卡互聯(lián)起來，用于大模型訓(xùn)推過程中的梯度更新等數(shù)據(jù)同步。2.2 算力訴求井噴，AI

產(chǎn)業(yè)面臨挑戰(zhàn)OpenAI/Meta/

字節(jié)跳動等公司近期所披露出的

AI

集群的規(guī)模都超過萬卡，在他們的研究報告和相關(guān)的學(xué)術(shù)論文中提出大量當(dāng)前

AI

業(yè)務(wù)在使用大規(guī)模算力集群過程中遇到的挑戰(zhàn)和問題，這里我們列舉幾個核心問題：線性度問題相對于單卡和單計算節(jié)點的計算效率，AI

計算任務(wù)在多卡多節(jié)點上的執(zhí)行是否能夠達(dá)到線性的收益目標(biāo)，特別是隨著集群規(guī)模的擴展，線性度能夠持續(xù)保持。以模型訓(xùn)練為例，模型訓(xùn)練的吞吐（樣本數(shù)

/

秒）=

單卡訓(xùn)練吞吐（樣本數(shù)

/

秒）*加速卡數(shù)量

*

線性度，理想的線性度是趨近于

1。通過高性能總線將多個節(jié)點的加速卡連接起來的超節(jié)點（SuperPOD）,

打破了傳統(tǒng)節(jié)點的模型，如英偉達(dá)編址，支持更大參數(shù)規(guī)模的模型加載。這超出了傳統(tǒng)節(jié)點資源和拓?fù)淠Ｐ偷谋磉_(dá)能力。而在

Scale-Out

擴展方面，一般采用二層或三層

Spine-leaf

拓?fù)淠Ｐ?，通過無帶寬的收斂

InfiniBand或網(wǎng)絡(luò)拓?fù)浜?/p>

AI

任務(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)度算法方面存在明顯的能力缺口。大模型訓(xùn)練的主要并行模式和通信需求如下，通信模式具有顯著特征：1. 周期性強，每輪迭代的2. 流數(shù)量少，單流帶寬3.通信量大，帶寬需求高。通信模式一致；大，同步突發(fā)。

云原生

AI

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

AI

基礎(chǔ)設(shè)施發(fā)展和挑戰(zhàn)·07·表

2-2-1 大模型并行模式和通信需求并行模式特

征通信需求Tensor

并行

(TP)通信量巨大（百

GB），通信時間不可掩蓋節(jié)點內(nèi)

allreduce超高帶寬Pipeline

并行

(PP)通信量較大（模型相關(guān)，百M-GB

級），通信時間不可掩蓋

/

流水可掩蓋跨節(jié)點

P2P中帶寬數(shù)據(jù)并行

(DP)通信量大（GB

級），通信時間計算可大部分掩蓋跨節(jié)點

allreduce高帶寬MOE

并行通信量大，通信時間不可掩蓋跨節(jié)點alltoall/allreduce高帶寬集群可用度和資源利用率問題：是

AI

集群使用者和供應(yīng)者共同關(guān)注的問題，集群的可用度直接關(guān)系到

AI

任務(wù)能否在預(yù)期的時間內(nèi)完成過壓低

AI

集群的資源成本取得盈利AI

大模型支持通過保存快照（CheckPoint）加速故障恢復(fù)，避免訓(xùn)練進(jìn)度丟失。提升

Checkpoint

的存取性能，及時發(fā)現(xiàn)故障并快速恢復(fù)都有待云原生

AI

中的存儲、故障和檢測恢復(fù)組件的提供更加完備和高效的方案?？紤]到集群內(nèi)運行不同租戶（公有云）、不同規(guī)格、不同運行時長的

AI

任務(wù)，容易產(chǎn)生資源碎片，需要能夠平衡集群資源利用率和

AI

任務(wù)性能目標(biāo)，這要求云原生

AI

的重調(diào)度和快速任務(wù)遷移協(xié)同解決。對于

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(wǎng)絡(luò)平面也有各自的帶寬限制，如果

AI

任務(wù)部署前還需要考慮這些硬件因素，一方面增加了

AI

開發(fā)者的學(xué)習(xí)成本，另一方面也會耗費他們額外的精力，降低

AI

開發(fā)者的產(chǎn)出效率。userid:549683,docid:171895,date:2024-08-17,云原生

AI

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

AI

技術(shù)概論·08·云原生AI

資源管理系統(tǒng)建設(shè)要點云原生

AI

訓(xùn)練系統(tǒng)建設(shè)要點云原生

AI

推理系統(tǒng)建設(shè)要點云原生

AI

邊緣云系統(tǒng)建設(shè)要點彈性伸縮，應(yīng)對AI

任務(wù)浪涌挑戰(zhàn)云原生

AI

技術(shù)概論03PART

云原生

AI

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

AI

技術(shù)概論·09·如前文所述，云原生

AI

技術(shù)包含了很多方面，從底層的硬件和數(shù)據(jù)中心，到容器集群管理，編排調(diào)度系統(tǒng)多問題，本章將對現(xiàn)今云原生

AI

面臨的熱點技術(shù)問題，給出前沿的技術(shù)指導(dǎo)。圖

3-1-1 云原生AI

技術(shù)架構(gòu)3.1 云原生

AI

資源管理系統(tǒng)建設(shè)要點云原生AI

資源管理系統(tǒng)涵蓋了AI

資源管理、矩陣算力基礎(chǔ)設(shè)置管理、云原生資源管理、資源畫像、垂直彈性、水平彈性以及智能HPA（Horizontal

Pod

Autoscaling）等多個方面，它們共同構(gòu)建了一個靈活、高效、智能的

AI

資源調(diào)度與管理框架，是驅(qū)動現(xiàn)代企業(yè)和組織智能化轉(zhuǎn)型的核心動力。1、現(xiàn)狀與問題AI

算力資源發(fā)展至今，從傳統(tǒng)的

CPU

到

GPU，再到百家齊鳴的

NPU、TPU、DPU

等等，AI

云計算已經(jīng)進(jìn)入了一個高速發(fā)展的

XPU

時代。在

AI

算力業(yè)務(wù)蓬勃發(fā)展的時代背景下，AI

算力訴求急劇膨脹，從最開始的單機單卡、單機多卡，到現(xiàn)在的千卡、萬卡集群，這也引出了一系列的問題和挑戰(zhàn)：集群規(guī)?？焖倥蛎洠珹I

資源管理復(fù)雜度上升。隨著

AI

產(chǎn)品的大眾化、規(guī)?；钶d商業(yè)級算力芯片的大規(guī)模算力集群，成為了各個科技型企業(yè)的必

云原生

AI

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

AI

技術(shù)概論·10·備武器，AI

算力集群規(guī)模也日益膨脹，這就帶了不可避免的問題：如何能更高效的管理成千上萬的

AI

算力資源。AI

芯片種類繁多，對于AI資源管理的可擴展性有了更高要求。無論是現(xiàn)今一家獨大的英偉達(dá)，還是厚積薄發(fā)的華為、谷歌、AMD，都在推出

AI

場景算力芯片，例如英偉達(dá)的

GPU、華為的昇騰

NPU

及谷歌的

TPU。AI

算力云廠商或是

AI

型企業(yè)，面對各家算力廠商迥異的架構(gòu)，也急需有一套可擴展性更好的

AI

資源管理架構(gòu)。參數(shù)面網(wǎng)絡(luò)等新型

AI資源，對于AI

資源管理提出了新的挑戰(zhàn)。大模型、自動駕駛、AIGC

的橫空出世，大規(guī)模的算力參數(shù)面互訪網(wǎng)絡(luò)成為了必需品，參數(shù)面網(wǎng)絡(luò)提供的超高帶寬，發(fā)展出了計算機超節(jié)點架構(gòu)，計算機超節(jié)點是一個由多個和多種計算

(CPU/NPU)，內(nèi)存，IO設(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)的資源，相關(guān)聯(lián)的算力參數(shù)面網(wǎng)絡(luò)設(shè)備及其拓?fù)涞墓芾?，也就成為?/p>

AI

算力資源管理的新課題。XPU

計算吞吐能力快速提升，I/O

瓶頸越發(fā)嚴(yán)重。當(dāng)前

CPU

與

XPU

的發(fā)展出現(xiàn)嚴(yán)重錯位；XPU

的算力雖然遠(yuǎn)超

CPU，CPU

擁有的內(nèi)存容量是

XPU

無法比擬的；這就導(dǎo)致在海量數(shù)據(jù)訓(xùn)練的過程中，數(shù)據(jù)不得不同時分布在CPU

和XPU

的內(nèi)存上，而為了最大限度發(fā)揮

XPU

算力的效率，數(shù)據(jù)必須能夠盡快的被

XPU

訪問到而不是浪費時間等待數(shù)據(jù)；隨著

AI

大模型參數(shù)的指數(shù)級增長，AI

大模型訓(xùn)練和推理越來越面臨內(nèi)存墻和

IO

傳輸墻的挑戰(zhàn)，即

XPU

內(nèi)存容量和

IO

帶寬的增長跟不上

AI

模型大小的增長速度。因此我們需要構(gòu)建可擴展的數(shù)據(jù)管道以高效地將數(shù)據(jù)傳輸?shù)?/p>

XPU

計算設(shè)備至關(guān)重要。在云上多租業(yè)務(wù)場景下，我們需要注意并確保

I/O

瓶頸不會出現(xiàn)在重要業(yè)務(wù)場景比如對性能要求極高的推理場景。Google

②和

Microsoft③的研究表明，高達(dá)

70%

的模型訓(xùn)練時間被

I/O

占用。字節(jié)跳動在

MegaScale④②JayashreeMohan,AmarPhanishayee,AshishRaniwala,andVijayChidambaram.2021.AnalyzingandmitigatingdatastallsinDNNtraining.Proc.VLDBEndow.14,5(January2021),771–784.https://doi.org/10.14778/3446095.3446100③DerekG.Murray,Jirísimsa,AnaKlimovic,andIhorIndyk.2021.Tf.data:amachinelearningdataprocessingframework.

Proc.

VLDB

Endow.

14,

12

(July

2021),

2945–2958.

/10.14778/3476311.3476374④Jiang,Ziheng,etal."MegaScale:ScalingLargeLanguageModelTrainingtoMoreThan10,000GPUs."arXivpreprintarXiv:2402.15627

(2024).

云原生

AI

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

AI

技術(shù)概論·11·的最新研究表明可以達(dá)到

55.2%

的模型

FLOP利用率，換句話說，XPUs

有接近一半的時間的時間處于閑置狀態(tài)，造成的大量的時間和金錢的浪費?，F(xiàn)在，由于

AI

大模型需要的算力和數(shù)據(jù)實在過大，很多中小型

AI廠商無法獲得足夠的計算和存儲資源來訓(xùn)練和優(yōu)化模型，所以不得不在云數(shù)據(jù)中心購買資源。在云上，數(shù)據(jù)分布在不同的地理位置，數(shù)據(jù)集大小已經(jīng)遠(yuǎn)遠(yuǎn)超出了本地和單個

XPU

存儲容量，云上

AI

訓(xùn)練和推理已經(jīng)成為了新的范式。云上

AI

訓(xùn)練和推理過程涉及移動數(shù)據(jù)集或復(fù)制數(shù)據(jù)到

XPU

設(shè)備上，為了最大限度地提升AI

場景XPU效率，I/O

優(yōu)化是云基礎(chǔ)設(shè)施的重要環(huán)節(jié)。隨著

AI

計算規(guī)模增大，例如大規(guī)模

AI

訓(xùn)練，需要多卡甚至多個節(jié)點同時參與一個任務(wù)的計算，其中一個關(guān)鍵點就是如何支持節(jié)點內(nèi)和節(jié)點間算力的高速通信，以便他們可以作為一個巨大的加速器相互協(xié)作。2、AI

通用算力基礎(chǔ)設(shè)施關(guān)鍵技術(shù)和價值面對以上的問題和挑戰(zhàn)，作為

AI

云原生計算基座，kubernetes

的社區(qū)提供了針對

AI

資源設(shè)備的管理機制，Device

Plugin

模式和

Dynamic

Resource

Allocation

模式。（1）大規(guī)模設(shè)備管理無論集群的

AI

算力規(guī)模如何膨脹，AI

算力設(shè)備終究需要依托在服務(wù)器節(jié)點上，這形成了一對多的關(guān)系，出了

Device

Plugin

的插件框架（DP

模式），在每一個算力節(jié)點上運行

Device

Plugin

進(jìn)程。各個

DevicePlugin

進(jìn)程僅需要管理自身節(jié)點上的少量

AI

算力設(shè)備，并將可用算力設(shè)備數(shù)上報至集群數(shù)據(jù)中心側(cè)，由kubernetes

的資源調(diào)度系統(tǒng)進(jìn)行后續(xù)的調(diào)度使用。（2）設(shè)備管理的可擴展性Device

Plugin

模式，將設(shè)備管理抽象成了若干管理

API，包括：監(jiān)聽

(ListAndWatch)、分配

(Allocate)等的邏輯和kubernetes

是解耦合的，算力廠商、第三方使用者僅需要實現(xiàn)極簡的Device

Plugin

管理API，進(jìn)行各種異構(gòu)算力芯片的擴展對接。（3）新型AI

設(shè)備的管理Device

Plugin

模式滿足了絕大多數(shù)的基本算力管理場景，但對于一些新型的復(fù)雜AI

設(shè)備，仍然有所欠缺，才能避免長距離網(wǎng)絡(luò)訪問，避免

AI

訓(xùn)練效率降低。

云原生

AI

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

AI

技術(shù)概論·12·而

Device

Plugin

模式，存在上報資源格式單一、管理模式單一等缺陷，無法滿足復(fù)雜的

AI

資源設(shè)備管理模式，其有以下功能特點：支持自定義資源參數(shù)：DRA

的資源分配管理采取

CustomResource(CR)

的方式，CR其高度可擴展的特征，允許開發(fā)者進(jìn)行特殊

AI

設(shè)備的參數(shù)擴展；支持設(shè)備的初始化和清理過程：設(shè)備的申請

/

注銷是由中心側(cè)控制器負(fù)責(zé)，Kubelet

Plugin

則負(fù)責(zé)響應(yīng)，一些初始化操作；支持設(shè)備的部分分配：相較于

Device

Plugin

的獨占分配，DRA

支持通過

ResourceClaim

的方式，讓設(shè)備在多個

Pod

或容器間的動態(tài)共享。相較于

Device

Plugin

模式，DRA

有更加豐富的語義，可以滿足更復(fù)雜的設(shè)備管理場景，但

DRA

帶來了Device

Plugin，在一些傳統(tǒng)的AI

設(shè)備管理場景，Device

Plugin

仍然是第一選擇。3、矩陣算力基礎(chǔ)設(shè)施關(guān)鍵技術(shù)與價值面對問題和挑戰(zhàn)，作為

AI

云原生基礎(chǔ)設(shè)施資源底座，kubernetes

構(gòu)建了面向超節(jié)點架構(gòu)的整套資源管理方案。雖然計算機超節(jié)點的

High-SpeedLink

高速互聯(lián)能夠提供比傳統(tǒng)互聯(lián)更高的帶寬，但單路徑帶寬仍無法匹配計算單元的吞吐，基礎(chǔ)設(shè)施層通過構(gòu)建全局多路徑I/O

加速技術(shù)，大幅提升了節(jié)點內(nèi)與節(jié)點間I/O

性能。為匹配

AI

行業(yè)所需的龐大算力需求，基礎(chǔ)設(shè)施硬件從主從架構(gòu)逐步演進(jìn)至對等架構(gòu)，傳統(tǒng)的資源管理模型不再適用，需要構(gòu)建面向?qū)Φ燃軜?gòu)的資源管理模型，實現(xiàn)資源的高效管理與合理配置。（1）全局多路徑

I/O加速技術(shù)通過對比各代

GPU

的

GPU

算力和

CPU-GPU

IO

帶寬，不難發(fā)現(xiàn)傳輸墻的限制正在加劇，短期內(nèi)不太可能得到解決。PCIe

帶寬非常有限，PCIe

Gen3

的理論帶寬是

32GB/s，PCIe

Gen4

的理論帶寬是

64GB/s，而實測帶寬大概分別是

24GB/s

和

48GB/s。在

AI

訓(xùn)練中，每完成一輪計算，都要同步更新一次參數(shù)，模型規(guī)模越大，參數(shù)規(guī)模一般也會更大，這樣

GPU

之間通信（P2P）能力對計算效率影響就比較大。NVLink

的

云原生

AI

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

AI

技術(shù)概論·13·目標(biāo)是突破

PCIe

接口的帶寬瓶頸，提高

GPU

之間交換數(shù)據(jù)的效率?；诙ㄖ苹ミB

NVLink，GPU

到

GPU的帶寬明顯快于

PCIe

帶寬。另外，GPU

顯存帶寬（HBM、GDDR）是大模型推理的性能瓶頸。而

GPU

到CPU

之間的互連（PCIe）是瓶頸。典型的

x86

CPU

只能通過

PCIe

與

GPU

通信，而

NVLink-C2C

的帶寬遠(yuǎn)超

PCIe

并具有緩存一致性的優(yōu)勢。目前在

GH200

和

GB200

等超級計算機中，NVLink

并開始應(yīng)用于

GPU服務(wù)器之間的互連，進(jìn)一步擴大

GPU（以及其顯存）集群的規(guī)模。全局多路徑加速是指我們可以利用單機內(nèi)

CPU

與

GPU

等不同芯片的多路徑，以及跨主機的多路徑提升

I/路徑來加速

CPU-GPU

IO

傳輸。但這遠(yuǎn)遠(yuǎn)不夠，

大語言模型（LLM）對顯存容量的需求非常迫切，巨大的顯存容量符合大模型的發(fā)展趨勢。那么，這個前所未見的容量是通過大規(guī)模的機器互聯(lián)來實現(xiàn)；在這種更大規(guī)模互聯(lián)的場景下，集群內(nèi)跨設(shè)備之間的

I/O

通信可以采用的路徑也會越來越多，包括

CPU

與CPU，CPU

與XPU，XPU與XPU之間的高速互聯(lián)；在未來超節(jié)點架構(gòu)中，一個物理超節(jié)點是由很多計算和存儲設(shè)備通過網(wǎng)絡(luò)連接起來的集群；一個物理超元上，這些計算不同業(yè)務(wù)對

I/O

的需求模式可能有區(qū)別。兩個互相通信的設(shè)備之間可能存在不同時延，不同帶寬的多條路徑。如果將大量的I/O-Intensive

負(fù)載放置到同一個物理設(shè)備上怎么樣來動態(tài)選擇IO

傳輸路徑，保證帶寬的高效利用同時又能滿足不同業(yè)務(wù)的

SLO

呢？有如下幾個解決方法：路徑規(guī)劃：通過劫持底層I/O

通信算子，并能夠在跨集群場景下分布式劫持通信需求，結(jié)合全局拓?fù)?，針對劃傳輸?shù)臄?shù)據(jù)量大小并按需使用對應(yīng)路徑；在數(shù)據(jù)量傳輸較大的場景還可以提高性能——通過同時使用多個數(shù)據(jù)路徑，AI

應(yīng)用程序獲得更高的數(shù)據(jù)傳輸吞吐。I/O

同時通過多條路徑傳輸提高性能并降低延遲；我們不僅僅可以通過

XPU

之間的High-Speed

Link

還可以結(jié)合通用計算設(shè)備之間的High-Speed

Link進(jìn)行感知業(yè)務(wù)特征和集群拓?fù)洌和ㄟ^持續(xù)在線監(jiān)控和避免

I/O

負(fù)載瓶頸來簡化多路徑管理。當(dāng)某一條路徑I/O和數(shù)據(jù)傳輸過程中實現(xiàn)最佳性能和提升業(yè)務(wù)可用性；當(dāng)路徑過于飽和的時候，可以根據(jù)業(yè)務(wù)優(yōu)先級分配

I/O帶寬，優(yōu)先滿足時延敏感型業(yè)務(wù)的

I/O

帶寬需求，避免關(guān)鍵業(yè)務(wù)性能受損。

云原生

AI

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

AI

技術(shù)概論·14·減少非必要數(shù)據(jù)傳輸：利用高性能緩存層或者在

XPU

可快速訪存的內(nèi)存中緩存常用的訓(xùn)練數(shù)據(jù)來加速I/O據(jù)放在

I/O

訪問較遠(yuǎn)的內(nèi)存介質(zhì)中，從而盡可能降低非必要的數(shù)據(jù)加載；在

AI

計算過程中，充分利用好多個

XPU之間并行，并通過數(shù)據(jù)分片和調(diào)整

mini-batch

size

來更好地利用好

XPU；（2）超節(jié)點資源管理模型傳統(tǒng)資源管理模型的基本算力單元為單臺服務(wù)器，服務(wù)器模型內(nèi)包含各種設(shè)備（CPU,

內(nèi)存以及

I/O

設(shè)備等器也僅是設(shè)備數(shù)量存在差異，其基本建模均保持一致。超節(jié)點為去中心化的架構(gòu)，雖然物理設(shè)備仍依托于服務(wù)器之上，但超節(jié)點內(nèi)配備有超高速互聯(lián)網(wǎng)絡(luò)，其內(nèi)所有設(shè)備均可以靈活組合成不同的算力單元，超節(jié)點架構(gòu)基本算力單元不再是單臺服務(wù)器，傳統(tǒng)資源管理模型已不再適用。面向超節(jié)點架構(gòu)，Google

的

TPU服務(wù)構(gòu)建的層次化的資源管理模型，是業(yè)界當(dāng)前比較成熟的解決方案。超節(jié)點資源管理模型與資源切片：超節(jié)點資源管理模型包含三個基本算力單元模型：XPU、CPU

和內(nèi)存互聯(lián)被抽象為連接資源節(jié)點之間邊

Edge，一個超節(jié)點被抽象為一個

SuperPoD，多個

SuperPoD

組成一個集群

Cluster，資源池就是集群的聚合。SuperPoD

的資源分配模型是XPU、CPU

和內(nèi)存的組合，稱為超節(jié)點資源切片slice。其中XPU

的資源分配粒度為設(shè)備，CPU

為

CPU

Core，內(nèi)存為容量。Edge

作為資源組合的約束，對資源的組合形式進(jìn)行限制。比如客戶申請一個

64XPU，320CPU

Core,

1024GB

內(nèi)存的

slice，超節(jié)點資源調(diào)度器不僅要調(diào)度足量的XPU、CPU

和內(nèi)存資源，還要通過圖匹配算法確保被調(diào)度的資源節(jié)點之間存在直連

Edge?；舅懔卧獾脑O(shè)備不參與資源調(diào)度過程，而是通過規(guī)格預(yù)定義的方式進(jìn)行管理，在

AI

場景下這些設(shè)備的分配量一般與

XPU資源量錨定，按照不同的XPU請求量劃分為若干檔位。超節(jié)點資源拓?fù)涓兄?/p>

AI

業(yè)務(wù)場景下所需的通信量非常大，其通信算法都會根據(jù)基礎(chǔ)設(shè)施網(wǎng)絡(luò)拓?fù)溥M(jìn)行編排優(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é)點

NN（network

node），并為每一個

NN

進(jìn)行邏輯編號，如

NN001，NN002?？蛻粼诓樵兂?jié)點

slice

的設(shè)備拓?fù)鋾r，接口會返回每一個設(shè)備所屬的每個層級的

NN，客戶可以根據(jù)

NN

的邏輯編號是否相同來確定·15·

云原生

AI

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

AI

技術(shù)概論設(shè)備間高速互聯(lián)的拓?fù)浣Y(jié)構(gòu)。超節(jié)點資源高可用：高可用能力是大規(guī)模集群系統(tǒng)必須具備的基本能力，基礎(chǔ)設(shè)施層的高可用能力之一是故障設(shè)備替換。故障設(shè)備替換指的當(dāng)客戶正在使用的設(shè)備出現(xiàn)故障時，使用一個正常設(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作業(yè)管理平臺在保存好現(xiàn)場后調(diào)用此接口進(jìn)行故障設(shè)備替換，替換成功后再通過讀取checkpoint

恢復(fù)業(yè)務(wù)

。除設(shè)備故障外，網(wǎng)絡(luò)斷連也是典型的故障場景，超節(jié)點資源管理平臺采用借軌通信的方案解決此類問題接，設(shè)備

A

可選擇從設(shè)備

B

跳轉(zhuǎn)的方式與設(shè)備

C

實現(xiàn)通信。跳轉(zhuǎn)節(jié)點通過路徑規(guī)格算法進(jìn)行優(yōu)選。3.2 云原生

AI

訓(xùn)練系統(tǒng)建設(shè)要點云原生

AI

訓(xùn)練能力集成了

AI

調(diào)度加速、AI

訓(xùn)練存儲加速、AI

serverless

訓(xùn)練以及

AI

故障自愈等多項關(guān)鍵功能。這些能力不僅極大地提升了

AI

模型訓(xùn)練的效率和性能，也為企業(yè)的智能化轉(zhuǎn)型提供了強有力的支持。1、AI

調(diào)度加速（1）現(xiàn)狀與問題在訓(xùn)練階段，通過大量數(shù)據(jù)和算法，AI模型學(xué)會識別和生成規(guī)律。有別于一般的通用業(yè)務(wù)場景，AI大

云原生

AI

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

AI

技術(shù)概論·16·模型訓(xùn)練對數(shù)據(jù)傳輸?shù)膸捄托阅苡懈叩囊蟆Ｍ瑫r，隨著大模型的出現(xiàn)，AI

訓(xùn)練

/

推理任務(wù)不再是單卡或單機的規(guī)模，通常表現(xiàn)為多個容器實例組成的分布式任務(wù)負(fù)載，由此對

AI

任務(wù)智能調(diào)度能力提出了更多挑戰(zhàn)。分布式調(diào)度死鎖和忙等：一個分布式訓(xùn)練作業(yè)通常由一批相關(guān)聯(lián)的

Pod

聯(lián)合執(zhí)行訓(xùn)練任務(wù)，比如Tens且同時停。當(dāng)集群中并發(fā)提交多個訓(xùn)練作業(yè)，在資源有限的情況下，每個訓(xùn)練作業(yè)僅部分

Pod

被成功調(diào)度從而獲取到集群資源，此時各訓(xùn)練作業(yè)均在等待更多資源以滿足作業(yè)運行的條件，造成作業(yè)之間的資源死鎖和忙等，訓(xùn)練作業(yè)無法有效執(zhí)行。算力高效利用：在大模型任務(wù)訓(xùn)練場景，動輒需要幾百甚至幾千張

GPU

卡的算力，服務(wù)器節(jié)點多、跨服務(wù)器通信需求巨大，處于同一個機架、Tor（Top

of

Rack）或者超節(jié)點內(nèi)的節(jié)點之間通信效率各不相同，同一個超節(jié)點網(wǎng)絡(luò)拓?fù)鋬?nèi)卡之間的網(wǎng)絡(luò)通信最高，Tor

內(nèi)通信效率次之，最后為普通節(jié)點之間通信。在傳統(tǒng)的分布式并行策略中，Tensor

并行（Tensor

Parallelism）和流水線并行（Pipeline

Parallelism）用來拆分模型，數(shù)據(jù)并行（data

parallel）用來拆分訓(xùn)練樣本，一般來說，數(shù)據(jù)并行和流水線的通信量較小，一輪迭代在

GB

級別，模型的通信量較大，一輪迭代在上百

GB

級別。任務(wù)調(diào)度過程中不同節(jié)點和卡的分配對訓(xùn)練作業(yè)性能影響較大，如何選擇最優(yōu)的資源分配模型是對

AI

任務(wù)調(diào)度的巨大挑戰(zhàn)。資源碎片化：不同訓(xùn)練作業(yè)所需的資源不同，任務(wù)生命周期也各不相同，集群穩(wěn)定運行一段時間后，不可避免出現(xiàn)較多資源碎片問題，導(dǎo)致在集群有空余資源的情況下，某些任務(wù)依舊無法運行。（2）關(guān)鍵技術(shù)和價值在

AI

訓(xùn)練和推理過程中，任務(wù)調(diào)度具有至關(guān)重要的作用，通過對任務(wù)進(jìn)行合理調(diào)度，可以有效地提高計避免不同訓(xùn)練作業(yè)之間資源死鎖和忙等的問題；結(jié)合節(jié)點網(wǎng)絡(luò)拓?fù)湔{(diào)度、Tor

親和調(diào)度和超節(jié)點分組親和調(diào)度能力，大幅度提升

AI

訓(xùn)練任務(wù)性能；裝箱調(diào)度和重調(diào)度配合使用，緩解集群資源碎片過多的問題，提高整體資源分配率。組調(diào)度（Gang）：組調(diào)度滿足了調(diào)度過程中“All

or

nothing”的調(diào)度需求，避免

Pod

的任意調(diào)度導(dǎo)致集群資源的浪費。在

AI

訓(xùn)練場景中，如果某些訓(xùn)練的

Pod

沒有被調(diào)度成功，已調(diào)度完成的

Pod

會繼續(xù)空等，造成資源浪費、甚至資源死鎖。Gang

調(diào)度會根據(jù)訓(xùn)練作業(yè)所需的最小資源量進(jìn)行判斷與調(diào)度，如果集群剩余資源不滿足該作業(yè)所有

Pod

同時運行，該訓(xùn)練作業(yè)不被調(diào)度，直到集群資源滿足該作業(yè)內(nèi)所有

pod資源需求后，作業(yè)才會被真正調(diào)度與執(zhí)行。節(jié)點網(wǎng)絡(luò)拓?fù)涓兄{(diào)度：節(jié)點內(nèi)卡與卡有多種通信方式，比如

GPU

卡之間的網(wǎng)絡(luò)連接方式分別為

云原生

AI

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

AI

技術(shù)概論·17·PCIe

和

Nvlink，其中

Nvlink

的通信效率數(shù)倍于

PCIe。訓(xùn)練作業(yè)內(nèi)

Pod

申請多卡執(zhí)行任務(wù)的場景，調(diào)度器應(yīng)感知節(jié)點內(nèi)卡與卡之間的網(wǎng)絡(luò)拓?fù)漕愋?，選擇網(wǎng)絡(luò)通信最優(yōu)卡資源組合分配，保障訓(xùn)練任務(wù)性能最優(yōu)。超節(jié)點拓?fù)溆H和調(diào)度：相對于跨超節(jié)點通信的場景，超節(jié)點內(nèi)部的

GPU

卡之間具備高一個量級甚至更大的高帶寬互聯(lián)。隨著大模型訓(xùn)練參數(shù)量級的快速增長，在模型并行度超過單節(jié)點卡數(shù)的場景，考慮將分布式并行策略與超節(jié)點拓?fù)浣Y(jié)構(gòu)相結(jié)合，模型并行任務(wù)控制在一個超節(jié)點內(nèi)，超節(jié)點之間執(zhí)行數(shù)據(jù)并行和流水線并行，分利用超節(jié)點內(nèi)

GPU

卡的高速通信優(yōu)勢，提升大模型訓(xùn)練效率。裝箱調(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è)分配整Tor

資源，提升平臺整體訓(xùn)練作業(yè)效率。主動重調(diào)度：AI

訓(xùn)練和推理任務(wù)的生命周期各不相同，短則數(shù)分鐘，長則數(shù)月。隨著

AI

任務(wù)持續(xù)運行集群中不可避免出現(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ù)有一定的要求，比如具備Checkpoint

能力，設(shè)置正確的

PDB（Pod

Disruption

Budget）策略等，確保業(yè)務(wù)在資源碎片重整的過程受影響程度最低。2、AI

訓(xùn)練存儲加速（1）現(xiàn)狀與問題從過去的經(jīng)典

AI，到現(xiàn)在的大模型，AI

模型的參數(shù)及

AI

算力規(guī)模呈現(xiàn)出指數(shù)級的爆發(fā)增長，對存儲基礎(chǔ)設(shè)施也帶來全新的挑戰(zhàn)。AI

訓(xùn)練業(yè)務(wù)上對存儲的主要挑戰(zhàn)如下：大模型訓(xùn)練

AI

集群故障概率高，故障影響大，故障發(fā)生后任務(wù)恢復(fù)耗時長，浪費大量

AI

算力和訓(xùn)練時間NPU

訓(xùn)練集群中很常見，機器崩潰和網(wǎng)絡(luò)故障不可避免。分布式深度神經(jīng)網(wǎng)絡(luò)訓(xùn)練作業(yè)被中斷，將導(dǎo)致模型狀態(tài)（即模型參數(shù)和優(yōu)化器狀態(tài)）丟失，訓(xùn)練作業(yè)失敗導(dǎo)致模型需要重新訓(xùn)練，會浪費大量算力和時間。訓(xùn)練任務(wù)檢查點

Checkpoint

是深度學(xué)習(xí)框架中的容錯方法。檢查點

Checkpoint

通過在給定時間定

云原生

AI

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

AI

技術(shù)概論·20·元數(shù)據(jù)導(dǎo)入（Lazyload）免

AI

芯片因存儲

I/O

等待產(chǎn)生空閑，提升

AI

芯片利用率。大模型訓(xùn)練過程中周期性產(chǎn)生的

CheckPoint

數(shù)據(jù)可以高速寫入高性能文件緩存，減少對上層訓(xùn)練任務(wù)的中斷和阻塞，可以提高

CheckPoint

保存頻率，減少訓(xùn)練任務(wù)故障時需要從最近一次

CheckPoint

重新訓(xùn)練的損失，最后，高性能文件存儲通過配置緩存數(shù)據(jù)淘汰功能，及時將長期未訪問的數(shù)據(jù)從緩存中淘汰，釋放高性能緩存空間。數(shù)據(jù)聯(lián)動技術(shù)包含以下功能：高性能文件系統(tǒng)綁定對象桶后，可以使用元數(shù)據(jù)導(dǎo)入功能。元數(shù)據(jù)導(dǎo)入功能僅會導(dǎo)入文件元數(shù)據(jù)，文件內(nèi)容會在首次訪問時從對象存儲桶中加載并緩存在高性能數(shù)據(jù)預(yù)熱（Preload）數(shù)據(jù)導(dǎo)出緩存數(shù)據(jù)淘汰文件存儲中，后續(xù)重復(fù)訪問會直接命中高性能文件存儲緩存，無需再從對象存儲桶中加載數(shù)據(jù)。元數(shù)據(jù)導(dǎo)入（Lazyload）方式下，初次訪問時需要從對象存儲中加載數(shù)據(jù)內(nèi)容，對文件的第一次讀取操作可能耗時較長，適合對首次數(shù)據(jù)訪問時延不太敏感的業(yè)務(wù)場景。高性能文件系統(tǒng)綁定對象桶后，也可以使用數(shù)據(jù)預(yù)熱功能。數(shù)據(jù)預(yù)熱（Preload）功能會同時導(dǎo)入元數(shù)據(jù)和數(shù)據(jù)內(nèi)容到高性能文件存儲中，上層業(yè)務(wù)訪問數(shù)據(jù)時可以從高性能文件存儲中直接命中，最大程度減少業(yè)務(wù)訪問數(shù)據(jù)時的時延。如果上層業(yè)務(wù)對數(shù)據(jù)訪問時延比較敏感，比如

AI

訓(xùn)練等場景涉及海量小文件，可以選擇數(shù)據(jù)預(yù)熱（Preload）方式。高性能文件系統(tǒng)綁定對象桶后，可以使用數(shù)據(jù)導(dǎo)出功能。當(dāng)上層業(yè)務(wù)在數(shù)據(jù)聯(lián)動目錄里創(chuàng)建一些文件，需要將這些文件存儲到對象桶里，可以使用數(shù)據(jù)導(dǎo)出功能。數(shù)據(jù)導(dǎo)出支持手工導(dǎo)出和配置成自動導(dǎo)出到對象桶。數(shù)據(jù)導(dǎo)出為異步方式，即上層業(yè)務(wù)將數(shù)據(jù)同步寫入高性能文件存儲，高性能文件存儲以異步方式將數(shù)據(jù)導(dǎo)出到對象桶，不阻塞上層業(yè)務(wù)。高性能文件系統(tǒng)綁定對象桶之后，可以配置數(shù)據(jù)淘汰功能，自動釋放設(shè)定時間內(nèi)沒有訪問過的文件數(shù)據(jù)內(nèi)容，僅保留文件元數(shù)據(jù)，數(shù)據(jù)內(nèi)容釋放后不占用高性能文件存儲的緩存空間，再次訪問該文件時，將重新從對象存儲中加載文件數(shù)據(jù)內(nèi)容。數(shù)據(jù)緩存淘汰功能可以減少冷數(shù)據(jù)對高性能緩存空間的占用?！?1·

云原生

AI

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

AI

技術(shù)概論數(shù)據(jù)聯(lián)動技術(shù)相比帶外遷移工具的優(yōu)勢：數(shù)據(jù)聯(lián)動傳統(tǒng)如帶外cp工、具rs遷yn移c

方等式，數(shù)據(jù)同步快依賴外部中間商；慢端并發(fā)度；中轉(zhuǎn)跳數(shù)多；增量數(shù)據(jù)同步極快通過對象存儲增量對象事件通知，只同步增量對象可定制極慢需要全量比對找出增量文件、速度極慢同步策略比如只同步元數(shù)據(jù)、有些大文件

AI

場景下對象數(shù)據(jù)湖吞吐即可滿足性能訴求、加速層只需要緩存元數(shù)據(jù)不可定制、比如不能只導(dǎo)入元數(shù)據(jù)困難、不可靠調(diào)度器集成簡單可靠同步發(fā)起、狀態(tài)展示等通過服務(wù)控制

API

集成中轉(zhuǎn)機復(fù)雜環(huán)境下變數(shù)多、穩(wěn)定性兼容性差、工具狀態(tài)獲取解析困難，調(diào)度器難以集成，人工維護(hù)成本高垃圾回收簡單通過調(diào)度器和系統(tǒng)可以自動釋放資源困難同步失敗會殘留垃圾、需要手工清理、容易遺漏表

3-2-3 數(shù)據(jù)聯(lián)動技術(shù)相比帶外遷移工具的優(yōu)勢高性能文件緩存加速層存儲提供

L1

b服）務(wù)三端內(nèi)級存緩緩存存加，速L2技客術(shù)戶端內(nèi)存緩存，及專門針對

CheckPoint

快存快恢的

SDK，形成三級緩存加速技術(shù)，加速

AI

訓(xùn)練過程中的訓(xùn)練數(shù)據(jù)集讀取，CheckPoint

快速保存及故障時的

CheckPoint

快速恢復(fù)。

云原生

AI

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

AI

技術(shù)概論·23·持久化到服務(wù)端存儲，最大程度減少

CheckPoint

同步保存耗時，減少了訓(xùn)練任務(wù)中斷阻塞。AI

訓(xùn)練任務(wù)發(fā)生進(jìn)程級故障時，利用本機

L2

客戶端內(nèi)存緩存實現(xiàn)

CheckPoint

原地秒級快恢，發(fā)生節(jié)點故障及

JOB

任務(wù)重調(diào)度場景下，利用客戶端節(jié)點間高速參數(shù)面網(wǎng)絡(luò)實現(xiàn)

CheckPoint

廣播技術(shù)加速CheckPoint

恢復(fù)速度，最大程度減少

CheckPoint

并發(fā)恢復(fù)耗時，避免訓(xùn)練任務(wù)故障恢復(fù)時由于遠(yuǎn)端存儲帶寬瓶頸導(dǎo)致長期阻塞。通過L3

CheckPoint

讀寫加速SDK

及

L2

客戶端內(nèi)存緩存技術(shù)，可以有效加速

CheckPoint

保存及恢復(fù)速度，可以提高

CheckPoint

保存頻率，大大減少了故障恢復(fù)時需要從上一次

CheckPoint

重新訓(xùn)練的損失。3、AI

Serverless

訓(xùn)練Serverless

作為一種云原生的應(yīng)用開發(fā)和運行模式，能夠?qū)㈤_發(fā)者從基礎(chǔ)設(shè)施的維護(hù)中解放出來，專注于應(yīng)用本身。這與

AI

算法工程師的需求契合，也能夠解決

AI

訓(xùn)練推理任務(wù)面臨的一些挑戰(zhàn)。（1）現(xiàn)狀與問題對于

AI

算法工程師而言，數(shù)據(jù)清洗、特征工程、訓(xùn)練調(diào)優(yōu)是他們的強項，然而基礎(chǔ)設(shè)施的準(zhǔn)備和

AI訓(xùn)練任務(wù)的部署，會給

AI

算法工程師帶來額外的學(xué)習(xí)成本。通用計算任務(wù)的算力需求比較容易評估，工程師可以根據(jù)業(yè)務(wù)模型提前進(jìn)行性能測試，得出不同業(yè)務(wù)并發(fā)量梯度下的算力需求。AI

訓(xùn)練單次任務(wù)耗時長，模型收斂的速度和學(xué)習(xí)率、batch

大小等超參數(shù)相關(guān)，模型精度更需要通過多輪迭代優(yōu)化才能得到理想效果。因此，AI

訓(xùn)練任務(wù)的算力需求不易提前獲得。為了保證AI

訓(xùn)練任務(wù)的效率，AI算法工程師只能采取保守原則，預(yù)留足量的算力資源，往往造成算力支出的浪費。通用算力場景常見的資源效率提升手段就是彈性擴縮，建立好單實例的業(yè)務(wù)并發(fā)量算力模型后，根據(jù)實際業(yè)務(wù)并發(fā)量進(jìn)行實例數(shù)量的調(diào)整，避免業(yè)務(wù)低谷期空閑實例造成浪費。對于

AI

訓(xùn)練任務(wù)而言，在實際執(zhí)行彈性擴縮時，存在并行任務(wù)分片重新調(diào)度的問題。訓(xùn)練集群彈性擴縮后，worker

的數(shù)量發(fā)生變化，取決于采用的并行策略，每個

worker

負(fù)責(zé)的數(shù)據(jù)、張量需要分配，數(shù)據(jù)分片，梯度狀態(tài)等也需要重新同步。目前這一過程需要

AI

框架的支持和配合，任務(wù)重啟和數(shù)據(jù)、狀態(tài)的同步也會帶來額外的訓(xùn)練開銷。（2）關(guān)鍵技術(shù)和價值支持

Serverless

化的

AI

訓(xùn)練任務(wù)，除了常規(guī)的計算資源維度的調(diào)度，還需要引入拓?fù)涓兄恼{(diào)度。這既包括節(jié)點、超節(jié)點內(nèi)加速卡之間的通信拓?fù)洌舶绻?jié)點的網(wǎng)絡(luò)拓?fù)?。AI

訓(xùn)練任務(wù)為了提升效率，都會采用分布式并行策略。每個

worker

負(fù)責(zé)一部分?jǐn)?shù)據(jù)或張量的處理，各個

worker

完成后通過

gather/reduce

操作合并和同步各自的處理結(jié)果。因此，AI

訓(xùn)練任務(wù)各個

worker

的調(diào)度結(jié)果，應(yīng)該和

AI

訓(xùn)練任務(wù)的分布式并行策略相匹配，避免gather/reduce

階段存在短板worker

導(dǎo)致其他worker

空等待，影響效率。

云原生

AI

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

AI

技術(shù)概論·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)化算法搜索滿足AI

訓(xùn)練任務(wù)SLA

要求的最優(yōu)資源配置和并行策略。從而簡化AI

算法工程師的模型部署流程，降低

AI

訓(xùn)練任務(wù)的成本，提升集群的資源利用率。對于訓(xùn)練任務(wù)的彈性擴縮，業(yè)界有提出稱作“透明彈性”的技術(shù)，以消減worker

數(shù)量變化帶來的開銷?！巴该鲝椥浴保櫭剂x就是彈性擴縮不改變

worker

的數(shù)量，而是通過加速卡虛擬化技術(shù)，調(diào)整

worker

共享的加速卡算力份額。舉個例子，一個訓(xùn)練任務(wù)初始劃分了

4

個worker，每個

worker

各自獨占一張加速卡，將其縮容為原來的

1/4，那其實可以將

4

個worker

的執(zhí)行都調(diào)度到一張加速卡上，分時復(fù)用加速卡的算力。當(dāng)然，“透明彈性”的實現(xiàn)是需要一些關(guān)鍵技術(shù)的支撐的。首先，虛擬化層需要根據(jù)調(diào)度到的

worker

正確地?fù)Q入對應(yīng)的數(shù)據(jù)到顯存；其次，顯存的換入換出需要一些優(yōu)化手段減少開銷，比如識別各個

worker

共享的數(shù)據(jù)，這部分顯存可以常駐；最后，worker

的調(diào)度還需要考慮并行策略下的依賴關(guān)系，避免死鎖產(chǎn)生。4、AI

故障自愈（1）問題與挑戰(zhàn)大模型分布式訓(xùn)練任務(wù)周期以周或者月為周期，集群規(guī)模在千卡甚至萬卡級別。在整個訓(xùn)練任務(wù)過程中會發(fā)生各種類型的故障，導(dǎo)致訓(xùn)練任務(wù)頻繁中斷，從而導(dǎo)致整體資源利用率低?？偨Y(jié)下來，大模型訓(xùn)練在故障快恢領(lǐng)域面臨如下挑戰(zhàn)：故障發(fā)生頻繁：模型越來越大，大規(guī)模訓(xùn)練集群涉及的硬件數(shù)量達(dá)到百萬至千萬級別，特別是高網(wǎng)絡(luò)帶寬對光模塊數(shù)量的要求越來越多，光模塊的故障率相對較高，導(dǎo)致大量的硬件潛在失效風(fēng)險。分布式訓(xùn)練是多個節(jié)點協(xié)同工作，任何一個硬件設(shè)備故障，都可能導(dǎo)致整個訓(xùn)練任務(wù)中斷。故障后恢復(fù)慢：大模型訓(xùn)練涉及到XPU、網(wǎng)絡(luò)、存儲、軟件等多種類型的軟硬件故障。故障排查流程長，根因定位定界復(fù)雜。比如，Meta

訓(xùn)練

OPT

模型平均中斷

12

小時⑤，理論訓(xùn)練需要

33

天。實際訓(xùn)練卻使用了90

天，期間出現(xiàn)了

112

次故障。其中主要問題是硬件故障，由于缺乏有效的故障快速恢復(fù)能力，訓(xùn)練人員只能不斷地花費大量時間來重啟訓(xùn)練任務(wù)，據(jù)統(tǒng)計手動重啟約

35

次，自動重啟約

70

次。⑤

/facebookresearch/metaseq/blob/main/projects/OPT/chronicles/OPT175B_Logbook.pdf

云原生

AI

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

AI

技術(shù)概論·25·大量故障導(dǎo)致頻繁

CKPT

回滾，算力利用率低：訓(xùn)練故障恢復(fù)過程中，關(guān)鍵在于模型狀態(tài)的保存與恢復(fù)GPT-4

的訓(xùn)練中使用了大約

2.15e25

的FLOPS，在大約

25000

個A100

GPU

上進(jìn)行了

90

到

100

天的訓(xùn)練，其算力利用率約為

32%

至

36%

⑥。這種算力利用率低的情況在業(yè)內(nèi)更加普遍。（2）關(guān)鍵技術(shù)和價值故障自愈與訓(xùn)練任務(wù)快速恢復(fù)是一個系統(tǒng)性工程，涉及到準(zhǔn)入檢測、故障快速感知、任務(wù)快速恢復(fù)等多個階段。階段一：準(zhǔn)入檢測在訓(xùn)練任務(wù)開始之前或者新節(jié)點加入集群之前，提前識別潛在故障點，可以防患于未然。相應(yīng)的技術(shù)包括：性能壓測：針對重點模塊壓測，檢出并攔截慢節(jié)點或失效硬件。基礎(chǔ)環(huán)境檢測：對節(jié)點的基礎(chǔ)配置（如驅(qū)動版本、OS

版本等）、關(guān)鍵系統(tǒng)服務(wù)進(jìn)行檢測，提前識別不合規(guī)的節(jié)點并進(jìn)行攔截。階段二：故障快速感知AI

訓(xùn)練遇到的故障總的來說可以分為芯片故障、節(jié)點故障和帶外故障。芯片故障：結(jié)合不同

GPU/NPU

芯片的故障模式，Device

Plugin

訂閱芯片故障并主動上報到故障處理系統(tǒng)，是云原生通用的硬件故障感知系統(tǒng)，可以有效縮短芯片故障響應(yīng)時間。節(jié)點故障：

除了芯片故障外，節(jié)點還會出現(xiàn)其他各種類型的故障，比如磁盤只讀、K8S

核心組件異常等通過污點的形式快速隔離并通過

k8s

event

等形式上報故障。⑥

/facebookresearch/metaseq/blob/main/projects/OPT/chronicles/OPT175B_Logbook.pdf

云原生

AI

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

AI

技術(shù)概論·26·帶外故障：大規(guī)模

AI

分布式訓(xùn)練，一般需要高性能網(wǎng)絡(luò)的支持。如果高性能網(wǎng)絡(luò)出現(xiàn)故障，很難通過節(jié)點檢測手段感知，需要構(gòu)建交換機指標(biāo)和日志采集與實時分析系統(tǒng)來檢測帶外故障。階段三：任務(wù)快速恢復(fù)計算圖和算子編譯緩存：圖編譯緩存功能支持將圖編譯結(jié)果進(jìn)行磁盤持久化，當(dāng)訓(xùn)練任務(wù)重新運行時直接加載磁盤上緩存的編譯結(jié)果，有效減少圖編譯時長，快速恢復(fù)業(yè)務(wù)作業(yè)。在線復(fù)位快速恢復(fù)：部分卡故障支持熱復(fù)位，比如

ECC-Error

故障。通過原地作業(yè)復(fù)位，無需任務(wù)重調(diào)度，可以提升任務(wù)的快速恢復(fù)能力，提升穩(wěn)定性和連續(xù)性。Pod/Job

重調(diào)度：對于無法恢復(fù)的芯片或硬件故障，需要將對應(yīng)的訓(xùn)練

Pod

驅(qū)逐并重新調(diào)度到健康節(jié)點上。比如

volcano

調(diào)度器結(jié)合節(jié)點故障快速感知與隔離技術(shù)，可以實現(xiàn)訓(xùn)練作業(yè)快速重調(diào)度能力。3.3 云原生

AI

推理系統(tǒng)建設(shè)要點云原生

AI

推理能力體系涵蓋了

AI

Serverless

推理以及大型語言模型（LLM）的推理優(yōu)化，旨在為用戶提供系列問題和挑戰(zhàn)，本節(jié)將具體介紹云原生

AI

推理方面的挑戰(zhàn)并給出解決方案。1、Serverless

AI

推理（1）現(xiàn)狀與問題AI

推理任務(wù)同樣有采用彈性擴縮提升資源效率的述求。相比訓(xùn)練任務(wù)，推理任務(wù)單次任務(wù)耗時短，也是請求

/

響應(yīng)的服務(wù)模式，類似通用計算的集群服務(wù)模式。問題在于，推理時長和資源消耗和用戶的輸入規(guī)模有關(guān)，僅以并發(fā)量建模業(yè)務(wù)的算力需求不夠準(zhǔn)確，還需要將推理時長的SLA考慮進(jìn)來。另外

AI

推理任務(wù)運行前的模型文件加載是不小的開銷，推理集群的彈性擴容還需要考慮冷啟動時延的消減問題。（2）關(guān)鍵技術(shù)和價值A(chǔ)I

推理任務(wù)的單實例算力模型可以基于資源畫像建立，而為了消減彈性擴縮時

AI

推理模型加載的冷啟

云原生

AI

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

AI

技術(shù)概論·30·Prefill

和

Decoding

分離：

Prefill

階段，需要計算所有輸入的注意力得分，大量的時間是花在各類矩陣乘相對較小，如果

KV

Cache

在整個系統(tǒng)中存在冷熱分級的情況，Decoding

階段更多面臨的就是顯存

IO

的壓力。因此，在某些場景下，將大模型推理的組件進(jìn)一步細(xì)分為

Prefill

組件和

Decoding

組件，依據(jù)計算側(cè)重的不同，合理搭配計算和存儲資源，進(jìn)一步降低系統(tǒng)的資源消耗。這樣推理后端又會產(chǎn)生變化，并且對KV

Cache

管理和調(diào)度都有新的配合需求。首先要解決的就是

Prefill

和

Decoding

的計算如何銜接的問題。Prefill

的處理相對簡單，跟不分離的推理過程一樣，完成全量輸入的首次推理計算，并生成

KV

Cache。而

Decoding

階段就變得比較復(fù)雜，首先

Decoding

階段的輸入，除了

Prefill

階段的預(yù)測結(jié)果，其他全部存放在

KV

Cache

中，而分離的場景，Prefill

和

Decoding

通常是放在不同的

DSA

上執(zhí)行，此時就需要考慮

Decoding

如何訪問

Prefill

階段的

KVCache

問題。最直接的方式，是將

Prefill

產(chǎn)生的

KV

Cache

遠(yuǎn)程復(fù)制到

Decoding

所在的

DSA的顯存。其次是Prefill

和Decoding

如何搭配的問題，因為Decoding

的計算壓力小，在某些場景，可能會存在一個3.4 云原生

AI

邊緣云系統(tǒng)建設(shè)要點1、邊緣云原生技術(shù)與典型框架邊緣計算作為云計算的拓展，將邊緣設(shè)備從數(shù)據(jù)消費者轉(zhuǎn)變?yōu)榧骖檾?shù)據(jù)生產(chǎn)者和消費者的雙重角色，目的是滿足能耗、隱私保護(hù)和實時性等方面的需求。由于軟硬件分散部署在成百上千的不同位置上，管理這些分布式系統(tǒng)的方法課基于可觀測性、松耦合系統(tǒng)、聲明式

API

等范式，這些范式已經(jīng)在云計算中展現(xiàn)出云原生技術(shù)的成功。將云原生技術(shù)應(yīng)用于邊緣環(huán)境已成為主流趨勢。作為云原生技術(shù)的底座，輕量靈活移植性高的容器技術(shù)天然匹配邊緣資源受限且異構(gòu)的場景，容器化的邊緣部署模式將占主導(dǎo)。另外，自動化、自恢復(fù)的容器編排模式能夠解決邊緣資源分散而維護(hù)管理不便的問題。云原生豐富的技術(shù)生態(tài)亦可以輕松構(gòu)建起監(jiān)控、日志等能力，通過容器、流量控制和網(wǎng)絡(luò)策略等能力能夠有效提升邊緣服務(wù)和邊緣數(shù)據(jù)的安全性。鑒于邊緣