【華為云中國信通院】2024云原生AI技術架構白皮書6718mb_第1頁
【華為云中國信通院】2024云原生AI技術架構白皮書6718mb_第2頁
【華為云中國信通院】2024云原生AI技術架構白皮書6718mb_第3頁
【華為云中國信通院】2024云原生AI技術架構白皮書6718mb_第4頁
【華為云中國信通院】2024云原生AI技術架構白皮書6718mb_第5頁
已閱讀5頁,還剩62頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

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

產業迎來新一輪創新浪潮……………02云原生助力AI

產業突破發展瓶頸,云原生AI

成為產業發展新范式………02云原生

AI

基礎設施發展和挑戰2.1

云原生AI

技術的演進…………………………052.2 算力訴求井噴,AI

產業面臨挑戰……………06云原生

AI

技術概論3.1

云原生AI

資源管理系統建設要點……………093.2

云原生AI

訓練系統建設要點…………………153.3

云原生AI

推理系統建設要點…………………263.4

云原生AI

邊緣云系統建設要點………………303.5

彈性伸縮,應對

AI

任務浪涌挑戰……………32云原生

AI

技術應用4.1

云原生AI

跨地域多集群協同…………………384.2

云原生AI

算力效能優化………………………414.3

云原生AI

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

云原生AI

設備驅動管理………………………51云原生

AI

行業實踐5.1 社交平臺

RB

云原生

AI

平臺應用加速實踐…………………545.2

AI

解決方案提供商FP

多場景AI

云原生化實踐……………585.3 醫療科技公司

HL

云原生

AI

智能醫療實踐…………………60目錄CONTENTS云原生

AI

技術架構白皮書 背景和前言·01·大模型開創智能時代的新紀元,AI

產業迎來新一輪創新浪潮云原生助力

AI

產業突破發展瓶頸,云原生

AI

成為產業發展新范式背景和前言01PART

云原生

AI

技術架構白皮書 背景和前言·02·1.1 大模型開創智能時代的新紀元,AI

產業迎來新一輪創新浪潮AI

軟件及應用市場持續增長,AI

大模型成為產業主要增長點。據IDC

估計,2026

年中國人工智能軟件及應用市場規模將達到

211

億美元,各行業的

AI

需求極大地推動著

AI

市場增長。隨著數字經濟、元宇宙等概念的逐漸興起,人工智能進入大規模落地應用的關鍵時期

,

但其開發門檻高、應用場景復雜多樣、對場景標注數據依賴等問題開始顯露,阻礙了規模化落地。以ChatGPT

為代表的AI

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

大模型為人工智能大規模落地帶來新的希望。面對人工智能的各種挑戰,AI

大模型的出現提供了通用化解決方案,從無標注數據中通過自監督學習獲取大量“知識”,實現用更統一的方式推動人工智能產業落地。廣泛智能需求驅動AI

產業不斷創新,大模型助力各行業生產力變革。隨著辦公、制造、金融、醫療、政務等場景中降本增效、生產自動化、降低風險、提高診斷準確率、提高政務服務效率等多方面的AI

智能需求,AI產業迎來了井噴式的創新和發展。憑借在文字、語音、圖像、視頻等多模態處理能力上的躍遷,AI

大模型搖身變為“助理”、“專家”走入辦公室、制造車間、金融市場、醫療機構、政務大廳,結合傳統軟件使得各個行業更加智能化、自動化。AI

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

AI

產業突破發展瓶頸,云原生

AI

成為產業發展新范式AI

產業面臨數據、算法、算力等多方面發展瓶頸。據

IDC

統計

,

中國數據規模將從

2021

年的

18.51ZB增長至

2026

年的

56.16ZB,年均增長速度

CAGR

24.9%,增速位居全球第一。隨著數據量的高速增長,數據特征高維、模態格式多樣的趨勢也逐漸明顯,對數據的

AI

建模也相應地更加復雜,計算復雜度會隨之呈指數增加,數據標注難度也會增加。同時,海量的數據將不可避免帶來更大的數據噪聲問題、數據偏見風險。與此同時,AI

應用場景更加多元化、復雜化,往往需要對多個任務進行深度融合和統一建模,這意味著廠商需要針對不同場景、不同任務開發大量的算法和模型,增加了

AI

應用的開發難度。算力方面,需要針對不同的場景和高性能計算能力進行拓展融合

,

滿足研發企業的多芯部署、分布式優化、高性能計算等需求,這涉及了計算資源的靈活調度和統一運營管理,給企業

AI

創新帶來了額外的成本。云原生

AI

成為

AI

產業發展的新范式。為了突破

AI

產業的發展瓶頸,云原生

AI

技術應運而生。一方面Kubernetes

的云原生可以有效管理各類網絡、存儲和計算資源,已逐步演變為實際上的云操作系統,服務

云原生

AI

技術架構白皮書 背景和前言·03·于私有云、公有云以及混合云環境。基于其高可用特性,云原生系統可通過自動故障恢復機制在故障發生時迅速恢復服務,確保

AI

應用的穩定運行。其次,利用

Kubernetes

自動伸縮功能帶來的出色擴展性,云原生可以根據

AI

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

AI

框架和工具無縫集成,實現

AI

應用的快速開發和部署。此外,云原生提供了豐富的計算(如

CPU

GPU)、網絡和存儲能力,并提供隔離和受控共享機制,加速了

AI

應用開發的效率和性能,并降低了企業的成本。另一方面,AI

也可以從調度資源、安全等方面增強云原生。在涉及多個優化標準的情況下,AI

可以分析集群的歷史使用情況并預測未來工作負載模式和資源可用性,更好地調度云基礎設施資源,進而降低能源消耗和使用成本。在安全方面,AI

可以分析大規模數據集并預測系統中的潛在威脅或弱點。用于檢測異常網絡行為的

AI

模型可以輕松地用于保護工作負載或在邊緣部署中的一組集群,加強企業對新興網絡威脅的防御。本白皮書重點關注云原生

AI

基礎設施層支持

AI

開發和使用,結合云原生開源生態發展現狀和行業實踐,深入分析云原生

AI

技術落地所面臨的技術挑戰并給出具體的技術指導方案。·03·云原生

AI

技術架構白皮書 云原生

AI

基礎設施發展和挑戰·04·云原生

AI

技術的演進算力訴求井噴,AI

產業面臨挑戰云原生

AI

基礎設施發展和挑戰02PART

云原生

AI

技術架構白皮書 云原生

AI

基礎設施發展和挑戰·05·云原生技術本質上是基礎設施云化和與之配套的服務(例如

CI/CD

就是如何在云化的基礎設施部署軟件AI

基礎設施向上為

AI

訓練作業、推理服務及模型開發等各類

AI

業務提供任務編排和調度能力,向下對多數據中心的異構硬件設備統一納管并提供高效、可靠的資源供應能力。這一章將簡短地回顧一下云原生

AI基礎設施的技術演變歷程,我們會看到如今云原生

AI

技術面臨的挑戰的來源。2.1 云原生

AI

基礎設施的演進2018

年圖靈獎獲得者計算機體系結構泰斗約翰

·

軒尼詩

(John

Hennessy)

和戴維

·

帕特森

(DavidPattArchitecture)

的演講①,指出摩爾定律

(Moore’s

Law)

和登納德定律(Dennard

Scaling

Law)

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

技術的發展和新的軟硬件接口抽象為云原生基礎設施帶來了新的挑戰和機遇,以面向特定領域體系結構的能效。2022

11

30

OpenAI

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

ChatGPT,在發布后的

2

個月內用戶數量就突破

1工業界對

AGI

從學術研究走進實際的商業應用有了前所未有的信心,各類基于

Transformer

架構的

AIGC

大模型應用如雨后春筍,國內也出現了百模大戰的態勢,更進一步出現了

Stable

Diffusion

Sora

等多模態大模型。在近幾年的大模型研究和工程實踐中,業界發現模型的訓練數據、參數量和計算量越大,模型的效果越好,模型規模與模型效果呈現顯著的正相關,雖然學術界存在爭議,但大模型的

Scaling

Law

仍然是業界的基本共識。為應對大模型對算力、存儲(帶寬、容量)需求,必須把大量加速卡和服務器節點通過高速總線和網絡連接起來,利用節點內總線(Scale-Up)和節點間網絡(Scale-Out)的層次化擴展能力,構建大規模

AI集群以提供充足的算力供應,隨著模型尺寸的持續增長,AI

集群的規模也越來越大。典型的

AI

集群具有兩個或三個網絡平面及一個高速總線平面,分別是:前端網絡平面,用于集群管理和

AI

作業的調度發放;后端網絡(Scale-out

Back-end)平面,用于擴展多

AI

服務器節點,通過高性能網絡

Infiniband

或以太網①

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

云原生

AI

技術架構白皮書 云原生

AI

基礎設施發展和挑戰·06·把不同節點的

GPU/NPU

卡通過

RDMA

協議連通起來,主要用于模型參數的數據同步(注:也有廠商稱之為參數平面);存儲網絡,通過專用的存儲網卡和交換機將訓練節點和存儲設備連接起來,用于訓練數據讀取和模型快照(Checkpoint)存取;高速總線(Scale-Up

link)平面,通過高帶寬高可靠的片間總線(如:PCIe/NVlink

等)將節點內加速卡互聯起來,用于大模型訓推過程中的梯度更新等數據同步。2.2 算力訴求井噴,AI

產業面臨挑戰OpenAI/Meta/

字節跳動等公司近期所披露出的

AI

集群的規模都超過萬卡,在他們的研究報告和相關的學術論文中提出大量當前

AI

業務在使用大規模算力集群過程中遇到的挑戰和問題,這里我們列舉幾個核心問題:線性度問題相對于單卡和單計算節點的計算效率,AI

計算任務在多卡多節點上的執行是否能夠達到線性的收益目標,特別是隨著集群規模的擴展,線性度能夠持續保持。以模型訓練為例,模型訓練的吞吐(樣本數

/

秒)=

單卡訓練吞吐(樣本數

/

秒)*加速卡數量

*

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

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

打破了傳統節點的模型,如英偉達編址,支持更大參數規模的模型加載。這超出了傳統節點資源和拓撲模型的表達能力。而在

Scale-Out

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

Spine-leaf

拓撲模型,通過無帶寬的收斂

InfiniBand或網絡拓撲和

AI

任務的并行策略及其通訊需求進行作業任務的層次化調度,這對集群的調度器提出了新的要求,即:要感知集群的資源的網絡拓撲和(超)節點拓撲,并根據

AI

任務的并行模式和通訊要求,將任務切分并調度到合適的節點和卡上,目前云原生

AI

調度器方案在拓撲感知及作業并行策略表達及調度算法方面存在明顯的能力缺口。大模型訓練的主要并行模式和通信需求如下,通信模式具有顯著特征:1. 周期性強,每輪迭代的2. 流數量少,單流帶寬3.通信量大,帶寬需求高。通信模式一致;大,同步突發。

云原生

AI

技術架構白皮書 云原生

AI

基礎設施發展和挑戰·07·表

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

征通信需求Tensor

并行

(TP)通信量巨大(百

GB),通信時間不可掩蓋節點內

allreduce超高帶寬Pipeline

并行

(PP)通信量較大(模型相關,百M-GB

級),通信時間不可掩蓋

/

流水可掩蓋跨節點

P2P中帶寬數據并行

(DP)通信量大(GB

級),通信時間計算可大部分掩蓋跨節點

allreduce高帶寬MOE

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

AI

集群使用者和供應者共同關注的問題,集群的可用度直接關系到

AI

任務能否在預期的時間內完成過壓低

AI

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

大模型支持通過保存快照(CheckPoint)加速故障恢復,避免訓練進度丟失。提升

Checkpoint

的存取性能,及時發現故障并快速恢復都有待云原生

AI

中的存儲、故障和檢測恢復組件的提供更加完備和高效的方案。考慮到集群內運行不同租戶(公有云)、不同規格、不同運行時長的

AI

任務,容易產生資源碎片,需要能夠平衡集群資源利用率和

AI

任務性能目標,這要求云原生

AI

的重調度和快速任務遷移協同解決。對于

AI

開發者而言,AI

基礎設施首先應該屏蔽底層基礎設施的細節,使

AI

開發者可以聚焦在數據質量的提升和模型架構的優化。加速卡有不同的型號和參數、加速卡間通過不同的網絡拓撲通信,不同的網絡平面也有各自的帶寬限制,如果

AI

任務部署前還需要考慮這些硬件因素,一方面增加了

AI

開發者的學習成本,另一方面也會耗費他們額外的精力,降低

AI

開發者的產出效率。userid:549683,docid:171895,date:2024-08-17,云原生

AI

技術架構白皮書 云原生

AI

技術概論·08·云原生AI

資源管理系統建設要點云原生

AI

訓練系統建設要點云原生

AI

推理系統建設要點云原生

AI

邊緣云系統建設要點彈性伸縮,應對AI

任務浪涌挑戰云原生

AI

技術概論03PART

云原生

AI

技術架構白皮書 云原生

AI

技術概論·09·如前文所述,云原生

AI

技術包含了很多方面,從底層的硬件和數據中心,到容器集群管理,編排調度系統多問題,本章將對現今云原生

AI

面臨的熱點技術問題,給出前沿的技術指導。圖

3-1-1 云原生AI

技術架構3.1 云原生

AI

資源管理系統建設要點云原生AI

資源管理系統涵蓋了AI

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

Pod

Autoscaling)等多個方面,它們共同構建了一個靈活、高效、智能的

AI

資源調度與管理框架,是驅動現代企業和組織智能化轉型的核心動力。1、現狀與問題AI

算力資源發展至今,從傳統的

CPU

GPU,再到百家齊鳴的

NPU、TPU、DPU

等等,AI

云計算已經進入了一個高速發展的

XPU

時代。在

AI

算力業務蓬勃發展的時代背景下,AI

算力訴求急劇膨脹,從最開始的單機單卡、單機多卡,到現在的千卡、萬卡集群,這也引出了一系列的問題和挑戰:集群規模快速膨脹,AI

資源管理復雜度上升。隨著

AI

產品的大眾化、規模化,搭載商業級算力芯片的大規模算力集群,成為了各個科技型企業的必

云原生

AI

技術架構白皮書 云原生

AI

技術概論·10·備武器,AI

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

AI

算力資源。AI

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

AI

場景算力芯片,例如英偉達的

GPU、華為的昇騰

NPU

及谷歌的

TPU。AI

算力云廠商或是

AI

型企業,面對各家算力廠商迥異的架構,也急需有一套可擴展性更好的

AI

資源管理架構。參數面網絡等新型

AI資源,對于AI

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

的橫空出世,大規模的算力參數面互訪網絡成為了必需品,參數面網絡提供的超高帶寬,發展出了計算機超節點架構,計算機超節點是一個由多個和多種計算

(CPU/NPU),內存,IO設備等計算機資源單元,高速互聯緊耦合在一起的集群計算系統,是生成式

AI

時代的產物。區別于傳統以服務器中心松耦合架構,超節點是去中心化的緊耦合架構。隨著技術的進一步演進,未來超節點內所有服務器的設備可做到靈活組合成為各種算力單元,也可被稱為矩陣式算力。為了能夠有效利用超節點內的資源,相關聯的算力參數面網絡設備及其拓撲的管理,也就成為了

AI

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

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

瓶頸越發嚴重。當前

CPU

XPU

的發展出現嚴重錯位;XPU

的算力雖然遠超

CPU,CPU

擁有的內存容量是

XPU

無法比擬的;這就導致在海量數據訓練的過程中,數據不得不同時分布在CPU

和XPU

的內存上,而為了最大限度發揮

XPU

算力的效率,數據必須能夠盡快的被

XPU

訪問到而不是浪費時間等待數據;隨著

AI

大模型參數的指數級增長,AI

大模型訓練和推理越來越面臨內存墻和

IO

傳輸墻的挑戰,即

XPU

內存容量和

IO

帶寬的增長跟不上

AI

模型大小的增長速度。因此我們需要構建可擴展的數據管道以高效地將數據傳輸到

XPU

計算設備至關重要。在云上多租業務場景下,我們需要注意并確保

I/O

瓶頸不會出現在重要業務場景比如對性能要求極高的推理場景。Google

②和

Microsoft③的研究表明,高達

70%

的模型訓練時間被

I/O

占用。字節跳動在

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

技術架構白皮書 云原生

AI

技術概論·11·的最新研究表明可以達到

55.2%

的模型

FLOP利用率,換句話說,XPUs

有接近一半的時間的時間處于閑置狀態,造成的大量的時間和金錢的浪費。現在,由于

AI

大模型需要的算力和數據實在過大,很多中小型

AI廠商無法獲得足夠的計算和存儲資源來訓練和優化模型,所以不得不在云數據中心購買資源。在云上,數據分布在不同的地理位置,數據集大小已經遠遠超出了本地和單個

XPU

存儲容量,云上

AI

訓練和推理已經成為了新的范式。云上

AI

訓練和推理過程涉及移動數據集或復制數據到

XPU

設備上,為了最大限度地提升AI

場景XPU效率,I/O

優化是云基礎設施的重要環節。隨著

AI

計算規模增大,例如大規模

AI

訓練,需要多卡甚至多個節點同時參與一個任務的計算,其中一個關鍵點就是如何支持節點內和節點間算力的高速通信,以便他們可以作為一個巨大的加速器相互協作。2、AI

通用算力基礎設施關鍵技術和價值面對以上的問題和挑戰,作為

AI

云原生計算基座,kubernetes

的社區提供了針對

AI

資源設備的管理機制,Device

Plugin

模式和

Dynamic

Resource

Allocation

模式。(1)大規模設備管理無論集群的

AI

算力規模如何膨脹,AI

算力設備終究需要依托在服務器節點上,這形成了一對多的關系,出了

Device

Plugin

的插件框架(DP

模式),在每一個算力節點上運行

Device

Plugin

進程。各個

DevicePlugin

進程僅需要管理自身節點上的少量

AI

算力設備,并將可用算力設備數上報至集群數據中心側,由kubernetes

的資源調度系統進行后續的調度使用。(2)設備管理的可擴展性Device

Plugin

模式,將設備管理抽象成了若干管理

API,包括:監聽

(ListAndWatch)、分配

(Allocate)等的邏輯和kubernetes

是解耦合的,算力廠商、第三方使用者僅需要實現極簡的Device

Plugin

管理API,進行各種異構算力芯片的擴展對接。(3)新型AI

設備的管理Device

Plugin

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

設備,仍然有所欠缺,才能避免長距離網絡訪問,避免

AI

訓練效率降低。

云原生

AI

技術架構白皮書 云原生

AI

技術概論·12·而

Device

Plugin

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

AI

資源設備管理模式,其有以下功能特點:支持自定義資源參數:DRA

的資源分配管理采取

CustomResource(CR)

的方式,CR其高度可擴展的特征,允許開發者進行特殊

AI

設備的參數擴展;支持設備的初始化和清理過程:設備的申請

/

注銷是由中心側控制器負責,Kubelet

Plugin

則負責響應,一些初始化操作;支持設備的部分分配:相較于

Device

Plugin

的獨占分配,DRA

支持通過

ResourceClaim

的方式,讓設備在多個

Pod

或容器間的動態共享。相較于

Device

Plugin

模式,DRA

有更加豐富的語義,可以滿足更復雜的設備管理場景,但

DRA

帶來了Device

Plugin,在一些傳統的AI

設備管理場景,Device

Plugin

仍然是第一選擇。3、矩陣算力基礎設施關鍵技術與價值面對問題和挑戰,作為

AI

云原生基礎設施資源底座,kubernetes

構建了面向超節點架構的整套資源管理方案。雖然計算機超節點的

High-SpeedLink

高速互聯能夠提供比傳統互聯更高的帶寬,但單路徑帶寬仍無法匹配計算單元的吞吐,基礎設施層通過構建全局多路徑I/O

加速技術,大幅提升了節點內與節點間I/O

性能。為匹配

AI

行業所需的龐大算力需求,基礎設施硬件從主從架構逐步演進至對等架構,傳統的資源管理模型不再適用,需要構建面向對等架構的資源管理模型,實現資源的高效管理與合理配置。(1)全局多路徑

I/O加速技術通過對比各代

GPU

GPU

算力和

CPU-GPU

IO

帶寬,不難發現傳輸墻的限制正在加劇,短期內不太可能得到解決。PCIe

帶寬非常有限,PCIe

Gen3

的理論帶寬是

32GB/s,PCIe

Gen4

的理論帶寬是

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

24GB/s

48GB/s。在

AI

訓練中,每完成一輪計算,都要同步更新一次參數,模型規模越大,參數規模一般也會更大,這樣

GPU

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

云原生

AI

技術架構白皮書 云原生

AI

技術概論·13·目標是突破

PCIe

接口的帶寬瓶頸,提高

GPU

之間交換數據的效率。基于定制互連

NVLink,GPU

GPU的帶寬明顯快于

PCIe

帶寬。另外,GPU

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

GPU

到CPU

之間的互連(PCIe)是瓶頸。典型的

x86

CPU

只能通過

PCIe

GPU

通信,而

NVLink-C2C

的帶寬遠超

PCIe

并具有緩存一致性的優勢。目前在

GH200

GB200

等超級計算機中,NVLink

并開始應用于

GPU服務器之間的互連,進一步擴大

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

CPU

GPU

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

I/路徑來加速

CPU-GPU

IO

傳輸。但這遠遠不夠,

大語言模型(LLM)對顯存容量的需求非常迫切,巨大的顯存容量符合大模型的發展趨勢。那么,這個前所未見的容量是通過大規模的機器互聯來實現;在這種更大規模互聯的場景下,集群內跨設備之間的

I/O

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

CPU

與CPU,CPU

與XPU,XPU與XPU之間的高速互聯;在未來超節點架構中,一個物理超節點是由很多計算和存儲設備通過網絡連接起來的集群;一個物理超元上,這些計算不同業務對

I/O

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

負載放置到同一個物理設備上怎么樣來動態選擇IO

傳輸路徑,保證帶寬的高效利用同時又能滿足不同業務的

SLO

呢?有如下幾個解決方法:路徑規劃:通過劫持底層I/O

通信算子,并能夠在跨集群場景下分布式劫持通信需求,結合全局拓撲,針對劃傳輸的數據量大小并按需使用對應路徑;在數據量傳輸較大的場景還可以提高性能——通過同時使用多個數據路徑,AI

應用程序獲得更高的數據傳輸吞吐。I/O

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

XPU

之間的High-Speed

Link

還可以結合通用計算設備之間的High-Speed

Link進行感知業務特征和集群拓撲:通過持續在線監控和避免

I/O

負載瓶頸來簡化多路徑管理。當某一條路徑I/O和數據傳輸過程中實現最佳性能和提升業務可用性;當路徑過于飽和的時候,可以根據業務優先級分配

I/O帶寬,優先滿足時延敏感型業務的

I/O

帶寬需求,避免關鍵業務性能受損。

云原生

AI

技術架構白皮書 云原生

AI

技術概論·14·減少非必要數據傳輸:利用高性能緩存層或者在

XPU

可快速訪存的內存中緩存常用的訓練數據來加速I/O據放在

I/O

訪問較遠的內存介質中,從而盡可能降低非必要的數據加載;在

AI

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

XPU之間并行,并通過數據分片和調整

mini-batch

size

來更好地利用好

XPU;(2)超節點資源管理模型傳統資源管理模型的基本算力單元為單臺服務器,服務器模型內包含各種設備(CPU,

內存以及

I/O

設備等器也僅是設備數量存在差異,其基本建模均保持一致。超節點為去中心化的架構,雖然物理設備仍依托于服務器之上,但超節點內配備有超高速互聯網絡,其內所有設備均可以靈活組合成不同的算力單元,超節點架構基本算力單元不再是單臺服務器,傳統資源管理模型已不再適用。面向超節點架構,Google

TPU服務構建的層次化的資源管理模型,是業界當前比較成熟的解決方案。超節點資源管理模型與資源切片:超節點資源管理模型包含三個基本算力單元模型:XPU、CPU

和內存互聯被抽象為連接資源節點之間邊

Edge,一個超節點被抽象為一個

SuperPoD,多個

SuperPoD

組成一個集群

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

的資源分配模型是XPU、CPU

和內存的組合,稱為超節點資源切片slice。其中XPU

的資源分配粒度為設備,CPU

CPU

Core,內存為容量。Edge

作為資源組合的約束,對資源的組合形式進行限制。比如客戶申請一個

64XPU,320CPU

Core,

1024GB

內存的

slice,超節點資源調度器不僅要調度足量的XPU、CPU

和內存資源,還要通過圖匹配算法確保被調度的資源節點之間存在直連

Edge。基本算力單元之外的設備不參與資源調度過程,而是通過規格預定義的方式進行管理,在

AI

場景下這些設備的分配量一般與

XPU資源量錨定,按照不同的XPU請求量劃分為若干檔位。超節點資源拓撲感知:

AI

業務場景下所需的通信量非常大,其通信算法都會根據基礎設施網絡拓撲進行編排優化,以達到充分利用網絡帶寬的目的。為了有效利用超節點的高速互聯網絡,客戶也需要感知到超節點內部的拓撲結構來優化通信算法。然而算力服務提供商出于安全和保密方面的考慮,一般不會對客戶暴露物理信息,而是通過抽象方式隱藏物理信息。AWS

提供了一套網絡拓撲的抽象建模思路能夠在滿足通信算法優化需求的同時隱藏物理信息。超節點資源拓撲感知模型將不同的網絡設備抽象為虛擬的網絡節點

NN(network

node),并為每一個

NN

進行邏輯編號,如

NN001,NN002。客戶在查詢超節點

slice

的設備拓撲時,接口會返回每一個設備所屬的每個層級的

NN,客戶可以根據

NN

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

云原生

AI

技術架構白皮書 云原生

AI

技術概論設備間高速互聯的拓撲結構。超節點資源高可用:高可用能力是大規模集群系統必須具備的基本能力,基礎設施層的高可用能力之一是故障設備替換。故障設備替換指的當客戶正在使用的設備出現故障時,使用一個正常設備將其替換掉,幫助客戶快速恢復業務。在超節點架構下,由于超節點內的設備之間具備高速互聯網絡,所以可用于替換的設備必須在超節點內部,不能跨超節點進行設備替換。在超節點架構下執行故障設備替換時,資源管理平臺會約束調度系統的調度范圍不能超出設備所在的超節點。此外,由于超節點規模有限,為了確保超節點內存在可用于替換的設備,資源管理平臺會在每個超節點內預留部分設備作為保底手段。在故障替換時會優先選擇非預留的空閑設備,在非預留空閑設備不滿足替換需求時才會動用預留資源。在某個預留設備被使用后,預留設備池的容量隨之減少,資源管理平臺會周期性的掃描超節點內設備使用狀態,若存在被釋放的設備則將其加入預留池,以實現預留池容量的輪轉。同時,資源你管理平臺也會通知運維人員及時維修故障設備。在

AI

場景下,為了與

Checkpiont

機制相配合,資源管理平臺會對外暴露設備替換接口。AI作業管理平臺在保存好現場后調用此接口進行故障設備替換,替換成功后再通過讀取checkpoint

恢復業務

。除設備故障外,網絡斷連也是典型的故障場景,超節點資源管理平臺采用借軌通信的方案解決此類問題接,設備

A

可選擇從設備

B

跳轉的方式與設備

C

實現通信。跳轉節點通過路徑規格算法進行優選。3.2 云原生

AI

訓練系統建設要點云原生

AI

訓練能力集成了

AI

調度加速、AI

訓練存儲加速、AI

serverless

訓練以及

AI

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

AI

模型訓練的效率和性能,也為企業的智能化轉型提供了強有力的支持。1、AI

調度加速(1)現狀與問題在訓練階段,通過大量數據和算法,AI模型學會識別和生成規律。有別于一般的通用業務場景,AI大

云原生

AI

技術架構白皮書 云原生

AI

技術概論·16·模型訓練對數據傳輸的帶寬和性能有更高的要求。同時,隨著大模型的出現,AI

訓練

/

推理任務不再是單卡或單機的規模,通常表現為多個容器實例組成的分布式任務負載,由此對

AI

任務智能調度能力提出了更多挑戰。分布式調度死鎖和忙等:一個分布式訓練作業通常由一批相關聯的

Pod

聯合執行訓練任務,比如Tens且同時停。當集群中并發提交多個訓練作業,在資源有限的情況下,每個訓練作業僅部分

Pod

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

GPU

卡的算力,服務器節點多、跨服務器通信需求巨大,處于同一個機架、Tor(Top

of

Rack)或者超節點內的節點之間通信效率各不相同,同一個超節點網絡拓撲內卡之間的網絡通信最高,Tor

內通信效率次之,最后為普通節點之間通信。在傳統的分布式并行策略中,Tensor

并行(Tensor

Parallelism)和流水線并行(Pipeline

Parallelism)用來拆分模型,數據并行(data

parallel)用來拆分訓練樣本,一般來說,數據并行和流水線的通信量較小,一輪迭代在

GB

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

GB

級別。任務調度過程中不同節點和卡的分配對訓練作業性能影響較大,如何選擇最優的資源分配模型是對

AI

任務調度的巨大挑戰。資源碎片化:不同訓練作業所需的資源不同,任務生命周期也各不相同,集群穩定運行一段時間后,不可避免出現較多資源碎片問題,導致在集群有空余資源的情況下,某些任務依舊無法運行。(2)關鍵技術和價值在

AI

訓練和推理過程中,任務調度具有至關重要的作用,通過對任務進行合理調度,可以有效地提高計避免不同訓練作業之間資源死鎖和忙等的問題;結合節點網絡拓撲調度、Tor

親和調度和超節點分組親和調度能力,大幅度提升

AI

訓練任務性能;裝箱調度和重調度配合使用,緩解集群資源碎片過多的問題,提高整體資源分配率。組調度(Gang):組調度滿足了調度過程中“All

or

nothing”的調度需求,避免

Pod

的任意調度導致集群資源的浪費。在

AI

訓練場景中,如果某些訓練的

Pod

沒有被調度成功,已調度完成的

Pod

會繼續空等,造成資源浪費、甚至資源死鎖。Gang

調度會根據訓練作業所需的最小資源量進行判斷與調度,如果集群剩余資源不滿足該作業所有

Pod

同時運行,該訓練作業不被調度,直到集群資源滿足該作業內所有

pod資源需求后,作業才會被真正調度與執行。節點網絡拓撲感知調度:節點內卡與卡有多種通信方式,比如

GPU

卡之間的網絡連接方式分別為

云原生

AI

技術架構白皮書 云原生

AI

技術概論·17·PCIe

Nvlink,其中

Nvlink

的通信效率數倍于

PCIe。訓練作業內

Pod

申請多卡執行任務的場景,調度器應感知節點內卡與卡之間的網絡拓撲類型,選擇網絡通信最優卡資源組合分配,保障訓練任務性能最優。超節點拓撲親和調度:相對于跨超節點通信的場景,超節點內部的

GPU

卡之間具備高一個量級甚至更大的高帶寬互聯。隨著大模型訓練參數量級的快速增長,在模型并行度超過單節點卡數的場景,考慮將分布式并行策略與超節點拓撲結構相結合,模型并行任務控制在一個超節點內,超節點之間執行數據并行和流水線并行,分利用超節點內

GPU

卡的高速通信優勢,提升大模型訓練效率。裝箱調度(Binpack):裝箱調度主要用于解決集群資源碎片的問題,在

AI

訓練場景下包含兩種維度的裝箱調度,分別為節點維度和

Tor

維度。對于不滿

8

卡的訓練作業優先進行節點級裝箱調度,填滿集群內節點資源碎片,空余更多節點用于調度需要整

8

卡的訓練作業;對于單個節點無法承載的訓練作業,優先進行

Tor

級別裝箱調度,優先填滿

Tor

級別的節點資源碎片,結合

Tor

親和調度為后續訓練作業分配整Tor

資源,提升平臺整體訓練作業效率。主動重調度:AI

訓練和推理任務的生命周期各不相同,短則數分鐘,長則數月。隨著

AI

任務持續運行集群中不可避免出現節點資源碎片,在集群內資源碎片現象嚴重的場景下,大模型訓練作業往往會因無法獲取整節點資源而長時間排隊。重調度策略主動識別集群碎片率過高的節點,驅逐并按照裝箱策略重新調度該部分節點對應的任務,整合節點資源碎片。重調度涉及業務的驅逐與重啟,對

AI

任務的故障恢復有一定的要求,比如具備Checkpoint

能力,設置正確的

PDB(Pod

Disruption

Budget)策略等,確保業務在資源碎片重整的過程受影響程度最低。2、AI

訓練存儲加速(1)現狀與問題從過去的經典

AI,到現在的大模型,AI

模型的參數及

AI

算力規模呈現出指數級的爆發增長,對存儲基礎設施也帶來全新的挑戰。AI

訓練業務上對存儲的主要挑戰如下:大模型訓練

AI

集群故障概率高,故障影響大,故障發生后任務恢復耗時長,浪費大量

AI

算力和訓練時間NPU

訓練集群中很常見,機器崩潰和網絡故障不可避免。分布式深度神經網絡訓練作業被中斷,將導致模型狀態(即模型參數和優化器狀態)丟失,訓練作業失敗導致模型需要重新訓練,會浪費大量算力和時間。訓練任務檢查點

Checkpoint

是深度學習框架中的容錯方法。檢查點

Checkpoint

通過在給定時間定

云原生

AI

技術架構白皮書 云原生

AI

技術概論·20·元數據導入(Lazyload)免

AI

芯片因存儲

I/O

等待產生空閑,提升

AI

芯片利用率。大模型訓練過程中周期性產生的

CheckPoint

數據可以高速寫入高性能文件緩存,減少對上層訓練任務的中斷和阻塞,可以提高

CheckPoint

保存頻率,減少訓練任務故障時需要從最近一次

CheckPoint

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

AI

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

云原生

AI

技術架構白皮書 云原生

AI

技術概論數據聯動技術相比帶外遷移工具的優勢:數據聯動傳統如帶外cp工、具rs遷yn移c

方等式,數據同步快依賴外部中間商;慢端并發度;中轉跳數多;增量數據同步極快通過對象存儲增量對象事件通知,只同步增量對象可定制極慢需要全量比對找出增量文件、速度極慢同步策略比如只同步元數據、有些大文件

AI

場景下對象數據湖吞吐即可滿足性能訴求、加速層只需要緩存元數據不可定制、比如不能只導入元數據困難、不可靠調度器集成簡單可靠同步發起、狀態展示等通過服務控制

API

集成中轉機復雜環境下變數多、穩定性兼容性差、工具狀態獲取解析困難,調度器難以集成,人工維護成本高垃圾回收簡單通過調度器和系統可以自動釋放資源困難同步失敗會殘留垃圾、需要手工清理、容易遺漏表

3-2-3 數據聯動技術相比帶外遷移工具的優勢高性能文件緩存加速層存儲提供

L1

b服)務三端內級存緩緩存存加,速L2技客術戶端內存緩存,及專門針對

CheckPoint

快存快恢的

SDK,形成三級緩存加速技術,加速

AI

訓練過程中的訓練數據集讀取,CheckPoint

快速保存及故障時的

CheckPoint

快速恢復。

云原生

AI

技術架構白皮書 云原生

AI

技術概論·23·持久化到服務端存儲,最大程度減少

CheckPoint

同步保存耗時,減少了訓練任務中斷阻塞。AI

訓練任務發生進程級故障時,利用本機

L2

客戶端內存緩存實現

CheckPoint

原地秒級快恢,發生節點故障及

JOB

任務重調度場景下,利用客戶端節點間高速參數面網絡實現

CheckPoint

廣播技術加速CheckPoint

恢復速度,最大程度減少

CheckPoint

并發恢復耗時,避免訓練任務故障恢復時由于遠端存儲帶寬瓶頸導致長期阻塞。通過L3

CheckPoint

讀寫加速SDK

L2

客戶端內存緩存技術,可以有效加速

CheckPoint

保存及恢復速度,可以提高

CheckPoint

保存頻率,大大減少了故障恢復時需要從上一次

CheckPoint

重新訓練的損失。3、AI

Serverless

訓練Serverless

作為一種云原生的應用開發和運行模式,能夠將開發者從基礎設施的維護中解放出來,專注于應用本身。這與

AI

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

AI

訓練推理任務面臨的一些挑戰。(1)現狀與問題對于

AI

算法工程師而言,數據清洗、特征工程、訓練調優是他們的強項,然而基礎設施的準備和

AI訓練任務的部署,會給

AI

算法工程師帶來額外的學習成本。通用計算任務的算力需求比較容易評估,工程師可以根據業務模型提前進行性能測試,得出不同業務并發量梯度下的算力需求。AI

訓練單次任務耗時長,模型收斂的速度和學習率、batch

大小等超參數相關,模型精度更需要通過多輪迭代優化才能得到理想效果。因此,AI

訓練任務的算力需求不易提前獲得。為了保證AI

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

AI

訓練任務而言,在實際執行彈性擴縮時,存在并行任務分片重新調度的問題。訓練集群彈性擴縮后,worker

的數量發生變化,取決于采用的并行策略,每個

worker

負責的數據、張量需要分配,數據分片,梯度狀態等也需要重新同步。目前這一過程需要

AI

框架的支持和配合,任務重啟和數據、狀態的同步也會帶來額外的訓練開銷。(2)關鍵技術和價值支持

Serverless

化的

AI

訓練任務,除了常規的計算資源維度的調度,還需要引入拓撲感知的調度。這既包括節點、超節點內加速卡之間的通信拓撲,也包括跨節點的網絡拓撲。AI

訓練任務為了提升效率,都會采用分布式并行策略。每個

worker

負責一部分數據或張量的處理,各個

worker

完成后通過

gather/reduce

操作合并和同步各自的處理結果。因此,AI

訓練任務各個

worker

的調度結果,應該和

AI

訓練任務的分布式并行策略相匹配,避免gather/reduce

階段存在短板worker

導致其他worker

空等待,影響效率。

云原生

AI

技術架構白皮書 云原生

AI

技術概論·24·為準確評估

AI

訓練任務的算力需求,為算力消費提供指導,需要引入

AI

訓練任務的資源畫像。以

AI模型源代碼為輸入,提取模型的靜態計算圖。基于計算圖進行算子拆分,對計算過程中的資源用量進行測算。同時根據設備網絡拓撲和通信測量(包含帶寬、時延等指標),構建網絡通信模型。最后通過優化算法搜索滿足AI

訓練任務SLA

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

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

AI

訓練任務的成本,提升集群的資源利用率。對于訓練任務的彈性擴縮,業界有提出稱作“透明彈性”的技術,以消減worker

數量變化帶來的開銷。“透明彈性”,顧名思義就是彈性擴縮不改變

worker

的數量,而是通過加速卡虛擬化技術,調整

worker

共享的加速卡算力份額。舉個例子,一個訓練任務初始劃分了

4

個worker,每個

worker

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

1/4,那其實可以將

4

個worker

的執行都調度到一張加速卡上,分時復用加速卡的算力。當然,“透明彈性”的實現是需要一些關鍵技術的支撐的。首先,虛擬化層需要根據調度到的

worker

正確地換入對應的數據到顯存;其次,顯存的換入換出需要一些優化手段減少開銷,比如識別各個

worker

共享的數據,這部分顯存可以常駐;最后,worker

的調度還需要考慮并行策略下的依賴關系,避免死鎖產生。4、AI

故障自愈(1)問題與挑戰大模型分布式訓練任務周期以周或者月為周期,集群規模在千卡甚至萬卡級別。在整個訓練任務過程中會發生各種類型的故障,導致訓練任務頻繁中斷,從而導致整體資源利用率低。總結下來,大模型訓練在故障快恢領域面臨如下挑戰:故障發生頻繁:模型越來越大,大規模訓練集群涉及的硬件數量達到百萬至千萬級別,特別是高網絡帶寬對光模塊數量的要求越來越多,光模塊的故障率相對較高,導致大量的硬件潛在失效風險。分布式訓練是多個節點協同工作,任何一個硬件設備故障,都可能導致整個訓練任務中斷。故障后恢復慢:大模型訓練涉及到XPU、網絡、存儲、軟件等多種類型的軟硬件故障。故障排查流程長,根因定位定界復雜。比如,Meta

訓練

OPT

模型平均中斷

12

小時⑤,理論訓練需要

33

天。實際訓練卻使用了90

天,期間出現了

112

次故障。其中主要問題是硬件故障,由于缺乏有效的故障快速恢復能力,訓練人員只能不斷地花費大量時間來重啟訓練任務,據統計手動重啟約

35

次,自動重啟約

70

次。⑤

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

云原生

AI

技術架構白皮書 云原生

AI

技術概論·25·大量故障導致頻繁

CKPT

回滾,算力利用率低:訓練故障恢復過程中,關鍵在于模型狀態的保存與恢復GPT-4

的訓練中使用了大約

2.15e25

的FLOPS,在大約

25000

個A100

GPU

上進行了

90

100

天的訓練,其算力利用率約為

32%

36%

⑥。這種算力利用率低的情況在業內更加普遍。(2)關鍵技術和價值故障自愈與訓練任務快速恢復是一個系統性工程,涉及到準入檢測、故障快速感知、任務快速恢復等多個階段。階段一:準入檢測在訓練任務開始之前或者新節點加入集群之前,提前識別潛在故障點,可以防患于未然。相應的技術包括:性能壓測:針對重點模塊壓測,檢出并攔截慢節點或失效硬件。基礎環境檢測:對節點的基礎配置(如驅動版本、OS

版本等)、關鍵系統服務進行檢測,提前識別不合規的節點并進行攔截。階段二:故障快速感知AI

訓練遇到的故障總的來說可以分為芯片故障、節點故障和帶外故障。芯片故障:結合不同

GPU/NPU

芯片的故障模式,Device

Plugin

訂閱芯片故障并主動上報到故障處理系統,是云原生通用的硬件故障感知系統,可以有效縮短芯片故障響應時間。節點故障:

除了芯片故障外,節點還會出現其他各種類型的故障,比如磁盤只讀、K8S

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

k8s

event

等形式上報故障。⑥

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

云原生

AI

技術架構白皮書 云原生

AI

技術概論·26·帶外故障:大規模

AI

分布式訓練,一般需要高性能網絡的支持。如果高性能網絡出現故障,很難通過節點檢測手段感知,需要構建交換機指標和日志采集與實時分析系統來檢測帶外故障。階段三:任務快速恢復計算圖和算子編譯緩存:圖編譯緩存功能支持將圖編譯結果進行磁盤持久化,當訓練任務重新運行時直接加載磁盤上緩存的編譯結果,有效減少圖編譯時長,快速恢復業務作業。在線復位快速恢復:部分卡故障支持熱復位,比如

ECC-Error

故障。通過原地作業復位,無需任務重調度,可以提升任務的快速恢復能力,提升穩定性和連續性。Pod/Job

重調度:對于無法恢復的芯片或硬件故障,需要將對應的訓練

Pod

驅逐并重新調度到健康節點上。比如

volcano

調度器結合節點故障快速感知與隔離技術,可以實現訓練作業快速重調度能力。3.3 云原生

AI

推理系統建設要點云原生

AI

推理能力體系涵蓋了

AI

Serverless

推理以及大型語言模型(LLM)的推理優化,旨在為用戶提供系列問題和挑戰,本節將具體介紹云原生

AI

推理方面的挑戰并給出解決方案。1、Serverless

AI

推理(1)現狀與問題AI

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

/

響應的服務模式,類似通用計算的集群服務模式。問題在于,推理時長和資源消耗和用戶的輸入規模有關,僅以并發量建模業務的算力需求不夠準確,還需要將推理時長的SLA考慮進來。另外

AI

推理任務運行前的模型文件加載是不小的開銷,推理集群的彈性擴容還需要考慮冷啟動時延的消減問題。(2)關鍵技術和價值AI

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

AI

推理模型加載的冷啟

云原生

AI

技術架構白皮書 云原生

AI

技術概論·30·Prefill

Decoding

分離:

Prefill

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

KV

Cache

在整個系統中存在冷熱分級的情況,Decoding

階段更多面臨的就是顯存

IO

的壓力。因此,在某些場景下,將大模型推理的組件進一步細分為

Prefill

組件和

Decoding

組件,依據計算側重的不同,合理搭配計算和存儲資源,進一步降低系統的資源消耗。這樣推理后端又會產生變化,并且對KV

Cache

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

Prefill

Decoding

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

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

KV

Cache。而

Decoding

階段就變得比較復雜,首先

Decoding

階段的輸入,除了

Prefill

階段的預測結果,其他全部存放在

KV

Cache

中,而分離的場景,Prefill

Decoding

通常是放在不同的

DSA

上執行,此時就需要考慮

Decoding

如何訪問

Prefill

階段的

KVCache

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

Prefill

產生的

KV

Cache

遠程復制到

Decoding

所在的

DSA的顯存。其次是Prefill

和Decoding

如何搭配的問題,因為Decoding

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

AI

邊緣云系統建設要點1、邊緣云原生技術與典型框架邊緣計算作為云計算的拓展,將邊緣設備從數據消費者轉變為兼顧數據生產者和消費者的雙重角色,目的是滿足能耗、隱私保護和實時性等方面的需求。由于軟硬件分散部署在成百上千的不同位置上,管理這些分布式系統的方法課基于可觀測性、松耦合系統、聲明式

API

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論