關于人工智能大模型的幾點思考-清華大學

報告內(nèi)容輸入小標題人工智能進入大模型時代AI基礎大模型從單模態(tài)向多模態(tài)發(fā)展ChatGPT實現(xiàn)真正像人類一樣來聊天交流文本交互Midjourney

AIGC畫作《太空歌劇院》獲得人類藝術比賽冠軍圖像創(chuàng)作阿里云視頻生成大模型I2VGen-XL，上傳1張圖后2分鐘生成高清視頻視頻生成行業(yè)+AI加速行業(yè)智能化升級，開始創(chuàng)造更大價值AI+金融企業(yè)財務異常識別準確率提升20%AI+醫(yī)療藥物研發(fā)周期從數(shù)年縮短到1個月AI+智能制造工業(yè)質(zhì)檢準確率提升14%AI+司法智慧司法系統(tǒng)AI+汽車自動駕駛智能網(wǎng)絡AI+氣象比傳統(tǒng)天氣預報提速10000倍+報告內(nèi)容，數(shù)據(jù)預處理頻繁、隨機小樣本讀取對文件系統(tǒng)提出挑戰(zhàn)隨機讀取訓練樣本進行預處理

大數(shù)據(jù)模型訓練訓練GPT4:一萬塊A100

x

11月大量數(shù)據(jù)經(jīng)過模型需要海量算力模型微調(diào)垂域模型:基座模型精調(diào)需要算力精調(diào)垂域模型需要可控算力模型推理實時的用戶請求對算力需求強勁實時處理用戶請求需要穩(wěn)定可靠算力數(shù)據(jù)獲取海量小文件存儲對文件系統(tǒng)提出需求獲取不同類型的原始數(shù)據(jù)并存儲，數(shù)據(jù)預處理頻繁、隨機小樣本讀取對文件系統(tǒng)提出挑戰(zhàn)隨機讀取訓練樣本進行預處理

大數(shù)據(jù)模型訓練訓練GPT4:一萬塊A100

x

11月大量數(shù)據(jù)經(jīng)過模型需要海量算力模型微調(diào)垂域模型:基座模型精調(diào)需要算力精調(diào)垂域模型需要可控算力模型推理實時的用戶請求對算力需求強勁實時處理用戶請求需要穩(wěn)定可靠算力數(shù)據(jù)獲取海量小文件存儲對文件系統(tǒng)提出需求獲取不同類型的原始數(shù)據(jù)并存儲120億圖像文件

(<20

KB)Dall-E數(shù)據(jù)集1億音頻文件

(<2

MB)Youtube大模型訓練需要收集海量多模態(tài)小文件多模態(tài)：文本、音頻、圖像、視頻特點：任一模態(tài)的數(shù)據(jù)集包含多達數(shù)億至數(shù)百億個小文件海量小文件的存儲挑戰(zhàn)——元數(shù)據(jù)管理難擴展性要求高：存儲100億的小文件需要管理7TB元數(shù)據(jù)延遲要求高：典型要求百微秒級讀取延遲，以滿足數(shù)據(jù)分析、模型訓練等應用的需求因元數(shù)據(jù)瓶頸，現(xiàn)有系統(tǒng)延遲在毫秒級,如Ceph0%50%100%數(shù)據(jù)部分

元數(shù)據(jù)部分10%65%大文件 小文件小文件讀取，元數(shù)據(jù)開銷成瓶頸500億網(wǎng)頁文件

(<8

KB)Common

Crawl[1]

/zh/oss/support/apsara-file-storage-nas問題：現(xiàn)有分布式文件系統(tǒng)無法同時滿足可擴展和低延遲的需求—元數(shù)據(jù)集中式管理架構(HDFS、Lustre)：訪問延遲低，但無法橫向擴展—元數(shù)據(jù)分布式管理架構(CephFS)：可橫向擴展，但訪問延遲高采用元數(shù)據(jù)集中式管理架構的

文件系統(tǒng)最大文件數(shù)HDFS1億Lustre40億能存儲的最大文件數(shù)受限，無法支持AI場景的海量文件目錄樹元數(shù)據(jù)服務器目錄樹data/homellmcv

alice

bobf4

f5

f6f7

…f1

f2

…

f3元數(shù)據(jù)服務器2元數(shù)據(jù)服務器1元數(shù)據(jù)服務器3路徑解析需跨多臺元數(shù)據(jù)服務器，導致元數(shù)據(jù)延遲高，超過數(shù)據(jù)延遲兩倍data/homellmcv

alice

bobf1f2f3…f4f5f6…f7低延遲：將目錄元數(shù)據(jù)集中在一臺目錄元數(shù)據(jù)服務器中，實現(xiàn)路徑解析的低延遲路徑解析在目錄元數(shù)據(jù)服務器本地完成，無跨網(wǎng)開銷可擴展：將文件元數(shù)據(jù)分布到多臺文件元數(shù)據(jù)服務器中，支持文件數(shù)目橫向可擴展文件元數(shù)據(jù)服務器之間無共享，擴展性好文件元數(shù)據(jù)服務器1目錄元數(shù)據(jù)服務器文件元數(shù)據(jù)服務器??圖例

/

目錄元數(shù)據(jù) 文件元數(shù)據(jù)路徑解析低延遲data/llmf1

f2

…

f3f1f2f3f4f5f6…h(huán)omecv

alice

bobf4

f5

f6

f7

f8

…解耦文件數(shù)目可擴展f目錄樹1101001000File

CreateFile

Delete16452031平均延遲(us)51x59x文件操作延遲File

Stat文件操作1080[1]

SingularFS:

A

Billion-Scale

Distributed

File

System

Using

a

Single

Metadata

Server,

USENIX

ATC’232023年5月(ISC

23):

IO

500總分全球第一2023年11月(SC

23):

IO

500總分全球第一2024年5月(ISC

24):

IO

500總分全球第一數(shù)據(jù)預處理頻繁、隨機小樣本讀取對文件系統(tǒng)提出挑戰(zhàn)隨機讀取訓練樣本進行預處理

大數(shù)據(jù)模型訓練訓練GPT4:一萬塊A100

x

11月大量數(shù)據(jù)經(jīng)過模型需要海量算力模型微調(diào)垂域模型:基座模型精調(diào)需要算力精調(diào)垂域模型需要可控算力模型推理實時的用戶請求對算力需求強勁實時處理用戶請求需要穩(wěn)定可靠算力數(shù)據(jù)獲取海量小文件存儲對文件系統(tǒng)提出需求獲取不同類型的原始數(shù)據(jù)并存儲Murray

D

G,

Simsa

J,

Klimovic

A,

et

al.

tf.

data:

A

machine

learning

data

processing

framework.

VLDB

2021.Mohan

J,Phanishayee

A,

Raniwala

A,

et

al.

Analyzing

and

mitigating

data

stalls

in

DNN

training.

arXiv

2020.據(jù)谷歌數(shù)據(jù)中心統(tǒng)計，30%的訓練時間用于數(shù)據(jù)預處理[1]微軟分析了9種常見模型，數(shù)據(jù)預處理最多占用65%的模型訓練時間[2]數(shù)據(jù)解碼變換…隨機采樣模型計算NVMeSSDHDD緩存數(shù)據(jù)預處理挑戰(zhàn)：預處理需要從分布式文件系統(tǒng)讀取數(shù)據(jù)，開銷大已有的方法通常以計算為中心，將需要處理的數(shù)據(jù)搬移到進行計算任務的節(jié)點需要處理的數(shù)據(jù)分散在多個節(jié)點上，讀遠端節(jié)點的數(shù)據(jù)會引入極大的網(wǎng)絡開銷解決方法：提出以數(shù)據(jù)為中心，將計算任務搬到數(shù)據(jù)節(jié)點上將計算任務動態(tài)地根據(jù)其需要的數(shù)據(jù)調(diào)度到數(shù)據(jù)所在的節(jié)點上從分布式系統(tǒng)的數(shù)據(jù)讀入轉(zhuǎn)換成從本地文件系統(tǒng)讀入管理節(jié)點輸入數(shù)據(jù)計算節(jié)點輸入數(shù)據(jù)計算節(jié)點輸入數(shù)據(jù)1.調(diào)度任務計算節(jié)點2.反饋結果諸葛弩大數(shù)據(jù)處理引擎的設計理念：領域支持層高效能底座層諸葛弩運行時諸葛弩SDK(基于C++

RDD的擴展接口)編譯優(yōu)化層MinHash

CCNet

……諸葛弩Catalyst插件

諸葛弩Python

UDF編譯器諸葛弩PySpark

API以數(shù)據(jù)為中心的執(zhí)行模式：數(shù)據(jù)讀入開銷低，動態(tài)負載均衡兼容PySpark編程接口：對PySpark用戶沒有額外的學習成本采用大量編譯優(yōu)化技術：通過靜態(tài)分析、算子融合、向量化、緊湊化數(shù)據(jù)排布等編譯技術，降低數(shù)據(jù)處理開銷提供良好的編程接口：提供基于C++RDD編程接口，供性能工程師編寫高性能計算模塊，嵌入端到端PySpark數(shù)據(jù)預處理管線中解析將JSON文件從文件系統(tǒng)中讀入并解析成關系表格式哈希計算MinHashLSH算法計算文檔在各條帶下的

MinHash值GroupBy按照條帶與哈希值進行分組生成邊每個條帶下，相同MinHash值的文檔被視為相似，并生成邊Join將文檔編號與文檔屬性關聯(lián)寫回將表數(shù)據(jù)以

JSON格式寫回文件系統(tǒng)刪冗前的文本數(shù)據(jù)（JSON）文檔的相似關系（JSON）SQL流程RDD流程MinHash流程100.2495.64102.56721.380100200300400

500600700800900PySparkChukonuMinHash時間（秒）讀寫時間 計算時間數(shù)據(jù)預處理頻繁、隨機小樣本讀取對文件系統(tǒng)提出挑戰(zhàn)隨機讀取訓練樣本進行預處理

大數(shù)據(jù)模型訓練訓練GPT4:一萬塊A100

x

11月大量數(shù)據(jù)經(jīng)過模型需要海量算力模型微調(diào)垂域模型:基座模型精調(diào)需要算力精調(diào)垂域模型需要可控算力模型推理實時的用戶請求對算力需求強勁實時處理用戶請求需要穩(wěn)定可靠算力數(shù)據(jù)獲取海量小文件存儲對文件系統(tǒng)提出需求獲取不同類型的原始數(shù)據(jù)并存儲模型訓練對分布式技術的挑戰(zhàn)頂層通信網(wǎng)絡超節(jié)點超節(jié)點超節(jié)點……

……存儲系統(tǒng)頂層存儲網(wǎng)絡新一代神威平臺的存儲與網(wǎng)絡架構原因：對于十萬卡規(guī)模萬億參數(shù)量檢查點讀寫默認策略：采用每個專家的0號進程寫數(shù)據(jù)方案1

(單超節(jié)點寫)：負載不均(超過10小時)方案2

(跨超節(jié)點寫)：進程數(shù)少(~3小時)影響性能核心因素：存儲系統(tǒng)架構神威平臺存儲系統(tǒng)與計算網(wǎng)絡系統(tǒng)共享同一套鏈路網(wǎng)絡利用效率會直接影響存儲系統(tǒng)性能默認讀寫策略性能差的因素：進程數(shù)不足：無法充分利用網(wǎng)絡鏈路帶寬負載不均：進程分布不均勻，無法利用所有交換機資源采用分布式檢查點策略＞

21＜解決思路：分布式檢查點策略調(diào)整檢查點處理適應神威平臺的存儲架構特點分布式檢查點存儲策略效果：十萬億參數(shù)量模型每次檢查點~10分鐘數(shù)據(jù)預處理頻繁、隨機小樣本讀取對文件系統(tǒng)提出挑戰(zhàn)隨機讀取訓練樣本進行預處理

大數(shù)據(jù)模型訓練訓練GPT4:一萬塊A100

x

11月大量數(shù)據(jù)經(jīng)過模型需要海量算力模型微調(diào)垂域模型:基座模型精調(diào)需要算力精調(diào)垂域模型需要可控算力模型推理實時的用戶請求對算力需求強勁實時處理用戶請求需要穩(wěn)定可靠算力數(shù)據(jù)獲取海量小文件存儲對文件系統(tǒng)提出需求獲取不同類型的原始數(shù)據(jù)并存儲數(shù)據(jù)預處理頻繁、隨機小樣本讀取對文件系統(tǒng)提出挑戰(zhàn)隨機讀取訓練樣本進行預處理

大數(shù)據(jù)模型訓練訓練GPT4:一萬塊A100

x

11月大量數(shù)據(jù)經(jīng)過模型需要海量算力模型微調(diào)垂域模型:基座模型精調(diào)需要算力精調(diào)垂域模型需要可控算力模型推理實時的用戶請求對算力需求強勁實時處理用戶請求需要穩(wěn)定可靠算力數(shù)據(jù)獲取海量小文件存儲對文件系統(tǒng)提出需求獲取不同類型的原始數(shù)據(jù)并存儲報告內(nèi)容時間2024算力密度上限

AI模型

HBM外部限制強化，中國AI內(nèi)循環(huán)加速到來管制范圍2018AI要素全面進入本地化時代數(shù)據(jù)屬地化算法主權化算力國產(chǎn)化2030國產(chǎn)算力 非國產(chǎn)算力國產(chǎn)AI算力總量和占比快速提升>90%>50%2025國家力量推動智算中心建設，引導國產(chǎn)算力發(fā)展上海：到2025年新建智算中心國產(chǎn)算力使用占比超50%北京：智算基礎設施2027年實現(xiàn)100%國產(chǎn)算力覆蓋江蘇：要求新建算力中心國產(chǎn)算力使用占比達70%以上其他：在建的杭州人工智能計算中心、貴安人工智能計算中心等均采用100%國產(chǎn)算力部署數(shù)據(jù)來源：國家智能算力規(guī)劃，公開資料整理通信庫NCCL并行系統(tǒng)編程語言Megatron-LMAI編譯器

算子庫調(diào)度器 內(nèi)存管理 容錯系統(tǒng) 存儲系統(tǒng)cuBLAS

cuDNN編程框架團隊自研系統(tǒng)編程語言并行加速

Megatron-LM

SmartMoE算子庫

cuBLAS

cuDNN內(nèi)存管理存儲系統(tǒng)底層系統(tǒng)通信庫

NCCLAI編譯器

EinNet

PETSelf

CheckpointSpread-n-Share編程框架國產(chǎn)AI芯片只要達到國外芯片60%的性能，如果生態(tài)做好了，客戶也會滿意。大多數(shù)任務不會因為芯片性能只有60%而有明顯感知，大家感覺到的不好用還是生態(tài)不行。在神威新一代超級計算機上研制了大模型訓練加速系統(tǒng)：八卦爐擴展到全機規(guī)模（10萬臺服務器）目前正適配八卦爐系統(tǒng)支持更多國產(chǎn)芯片八卦爐支撐多個大模型的訓練任務：北京智源研究院悟道2.0、阿里巴巴M6大模型等支撐多個AI

for

Science應用程序：跨尺度大氣預測模型：swMPAS-A第一性原理大模型：乾坤Net國產(chǎn)算力基礎軟件層“八卦爐”基礎軟件系統(tǒng)并行層計算層編程語言底層系統(tǒng)并行加速通信庫容錯系統(tǒng)內(nèi)存系統(tǒng)存儲系統(tǒng)調(diào)度系統(tǒng)編譯器加速庫實現(xiàn)百萬億參數(shù)量預訓練模型加速模型規(guī)模：174萬億參數(shù)量（世界最大）訓練性能：1.18

EFLOPS

（世界最快）運行規(guī)模：3700萬處理器核八卦爐+國產(chǎn)超算神威E級超級計算機（算力等效1.8萬塊A100）八卦爐：支撐國產(chǎn)AI算力的基礎軟件集PowerFusion：面向國產(chǎn)AI芯片智能編譯器

FastMoE：MOE大模型并行加速系統(tǒng)Einet：圖算融合智能編譯器

FreeTensor：面向不規(guī)則智能程序編程語言

FastDecode：高吞吐大模型推理系統(tǒng)精度驗證：國產(chǎn)超算與其它平臺一致Baichuan-7b精調(diào)任務：精度與百川公司實現(xiàn)對齊LLaMA-7b預訓練任務：與NVIDIA實現(xiàn)loss曲線對齊目前“八卦爐”已經(jīng)在國產(chǎn)超算系統(tǒng)成功移植百川、LLAMA等大模型硬件環(huán)境GPU：512

×沐曦曦云C500系列GPU卡機內(nèi)互連：4卡間高速互連，前后4卡PCIe

5.0機間互連：每機配備2個400Gb

IB卡LLAMA-70B：廣泛使用的benchmark模型稠密模型Global

batch

size設置為256MoE-567B:

MOE模型是目前大模型發(fā)展趨勢稀疏模型參數(shù)量大，每token計算量與LLAMA持平Global

batch

size設置為64和1024提升算子效率:計算密集型算子和訪存密集型算子開展優(yōu)化改進并行方案:減少通信量、提高硬件利用率底層系統(tǒng)支持:提高內(nèi)存利用率和通信效率“八卦爐”優(yōu)化沐曦512卡智算集群訓練任務，平均性能提升30%部分優(yōu)化后算子效率提升300%并行方案效率提升整體性能≥10%

數(shù)據(jù)并行相關集合通信帶寬提升50%Llama

70B模型，性能提升15%MoE

567B模型(Batchsize=64)，性能提升31%MoE

567B模型(Batchsize=1024)，性能提升45%優(yōu)化前后，精度曲線保持一致混合專家模型（MoE）已成為擴展模型規(guī)模的主流手段傳統(tǒng)的MoE模型訓練采用數(shù)據(jù)并行或?qū)＜也⑿蟹绞?，難以解決顯存容量不足、網(wǎng)絡通信量過大、集群負載不均衡等問題FastMoE采用新的并行策略，解決了上述問題經(jīng)移植，已在摩爾線程MCCX-D800

8卡機取得1.32倍加速比11.32Megatron（專家并行）加速比（以MEGATRON為基準）基礎算子性能是制約AI大模型性能的主要因素之一IntelliGen編譯器擅長為Attention等訪存密集型算子自動生成高性能執(zhí)行代碼經(jīng)初步移植，已能在摩爾線程S4000上取得2.95倍加速在其他平臺上IntelliGen

可取得20×加速，還有進一步提升空間1111.431.962.95GPTBERTVIT加速比（以PyTorch為基準）PyTorchIntelliGen容量挑戰(zhàn)：GPU顯存容量難以滿足大模型推理的需求為節(jié)省算力，必需保存kv-cache，即推理過程的歷史中間結果隨著生成序列越來越長，kv-cache大小線性增加以萬億模型為例:模型大小2TB，至少需26張顯卡KV-Cache大小為7TB，還需要86張顯卡挑戰(zhàn)：如何為kv-cache設計高容量、高帶寬的存儲系統(tǒng)？假設顯存大小為80GB，batch

size為8，序列長度128k10987654321020488192

32768

131072序列長度所需顯存大小/TB模型參數(shù)

kv-cache

其它解決思路：使用閑置CPU和主存來處理KV-CacheKV-Cache處理所需計算/訪存比例更適合CPUCPU主存容量更大，可容納更多KV-Cache，同時處理更多序列例子：僅需4臺CPU服務器，即可容納8TB的KV-Cache優(yōu)勢1：Batch

size不再受到KV-Cache顯存占用限制，GPU利用率提升優(yōu)勢2：聚合存儲帶寬高，KV-Cache處理吞吐量提升，成本降低清程pro推理服務器清程max推理機柜燧原S60推理加速卡燧原S60推理加速卡燧原S60推理

加速卡燧原S6推理

加速卡0CPUCPU大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大容量主存大大大大容容容容量量量量主主主主存存存存清程pro推理服務器Attention

加速服務器(純CPU)Attention

加速服務器(純CPU)Attention

加速服務器(純CPU)高速本地網(wǎng)絡FastDecode

高吞吐推理軟件系統(tǒng)FastDecode

高吞吐推理軟件系統(tǒng)某國產(chǎn)130b模型清程Max相比原有方案吞吐量提升7.6倍吞吐13b模型均使用單燧原加速卡數(shù)值為生成長度1-1024的平均吞吐量。Llama-13b模型清程Pro相比云燧S60+vLLM

提升1.7倍吞吐清程Max

提升5.4倍吞吐清程Pro比英偉達A10+vLLM提升1.3倍130b模型均使用四塊燧原加速卡+W8量化數(shù)值為生成長度1-1024的平均吞吐量。35014.983258.8450.297

1394.092

15001200900600300027.5851075.772205.795300250200150100500所用數(shù)據(jù)越多算力缺口越大模型越大推理成本越高輸入越長響應延遲越長更多可參見：/kvcache-ai/Mooncake

Mooncake

(1):在月之暗面做月餅，Kimi以

KVCache為中心的分離式推理架構_Kimi底層推理架構，承載其80%以上的流量以存換算！提升Kimi吞吐75%以上以超大規(guī)模分離式內(nèi)存池為中心的

KVCache緩存和調(diào)度用戶體驗（SLO）優(yōu)先、面向過載場景的調(diào)度策略月之暗面+清華KVCache.AI團隊KVCache-centricConductorDecoding

InstancePaged

KVCacheGPU/VRAMLocalSchedulerPaged

KVCacheGPU/VRAMLocalChunkedPrefillSchedulerPrefill

InstanceCPU/DRAM/SSDDistributed

KVCache

PoolCPU/DRAM/SSDDistributed

KVCache

PoolPaged

KVCacheGPU/VRAMPrefill

InstanceCPU/DRAM/SSDDistributed

KVCache

PoolPP/SPLocalChunkedPrefillSchedulerInter-node

KVCache

TransferDecoding

InstancePaged

KVCacheGPU/VRAMLocalSchedulerCPU/DRAM/SSDDistributed

KVCache

PoolPrefill

Pool

KVCache

Pool

Decoding

Pool

Cache-awarePrefillSchedulerKVCacheBalanceSchedulerLoad-balanceDecodingSchedul