分享嘉賓 | ZOMI 醬
審校 | Kitty
策劃 | QCon 全球軟件開發(fā)大會(huì)
隨著大模型技術(shù)從技術(shù)變革轉(zhuǎn)向產(chǎn)業(yè)變革，大模型應(yīng)用也會(huì)進(jìn)一步繁榮，傳統(tǒng)基礎(chǔ)設(shè)施技術(shù)已經(jīng)不足以滿足大模型應(yīng)用的快速發(fā)展。整個(gè)基礎(chǔ)設(shè)施技術(shù)和產(chǎn)業(yè)鏈正在快速轉(zhuǎn)型，向大模型基礎(chǔ)設(shè)施技術(shù)演變。2025 QCon 全球軟件開發(fā)大會(huì)（北京站）策劃了「面向 AI 的研發(fā)基礎(chǔ)設(shè)施」專題，通過本專題的深入探討，希望讓聽眾了解并掌握大模型基礎(chǔ)設(shè)施技術(shù)的發(fā)展趨勢(shì)和前沿動(dòng)態(tài)，從企業(yè)工程實(shí)踐和學(xué)術(shù)研究領(lǐng)域借鑒成功經(jīng)驗(yàn)，為自身企業(yè)制定更大規(guī)模、更高性能以及更加穩(wěn)定的大模型基礎(chǔ)設(shè)施技術(shù)。詳見會(huì)議官網(wǎng)：https://qcon.infoq.cn/2025/beijing/
萬卡集群在執(zhí)行大規(guī)模網(wǎng)絡(luò)模型訓(xùn)練任務(wù)時(shí)負(fù)載重，面臨功耗、網(wǎng)絡(luò)拓?fù)洹⒖煽啃院凸收匣謴?fù)、并行計(jì)算、成本分析等多方面的挑戰(zhàn)。越來越多開發(fā)者希望更好地駕馭萬卡集群，提升大規(guī)模網(wǎng)絡(luò)模型在萬卡集群訓(xùn)練的集群整體性能。
在 InfoQ 舉辦的 QCon 全球軟件開發(fā)大會(huì)上，華為昇騰生態(tài)技術(shù)首席 ZOMI 醬為我們帶來了精彩演講“大模型在超大規(guī)模集群上的性能提升實(shí)踐”，深入探索如何在萬卡昇騰 NPU 集群上，基于業(yè)界典型 AI 框架和 MindSpeed 分布式并行加速庫，結(jié)合網(wǎng)絡(luò)拓?fù)鋬?yōu)化算法和華為開源 HCCL 集合通信庫協(xié)同優(yōu)化，并深入剖析了萬卡集群訓(xùn)練過程中涉及的技術(shù)原理和難點(diǎn)，探討萬卡集群訓(xùn)練的性能和穩(wěn)定性策略，最后結(jié)合案例講解面向萬卡集群的性能提升實(shí)踐。
以下是演講實(shí)錄（經(jīng) InfoQ 進(jìn)行不改變?cè)獾木庉嬚恚?/strong>
我整體分享的內(nèi)容分為四個(gè)部分。首先，我們來看一下大規(guī)模集群的發(fā)展；接著，我們探討集群組網(wǎng)的整體優(yōu)化，特別是華為是如何做的，從百卡集群到千卡集群，再到如今的萬卡集群，整體組網(wǎng)方案的演進(jìn)；然后我會(huì)分享多模態(tài)性能優(yōu)化的案例；最后通過一個(gè)小紅書的簡(jiǎn)單案例做一些總結(jié)。
大規(guī)模集群發(fā)展
盡管萬卡集群在當(dāng)下似乎已不再稀奇，但對(duì)于高校、個(gè)人開發(fā)者以及一些小型獨(dú)立軟件供應(yīng)商（ISV）而言，萬卡集群的構(gòu)建仍然極具挑戰(zhàn)性。Meta 的 LLaMA 43.1 基于 1.6 萬張 H100 GPU 卡片開發(fā)；而近期發(fā)布的 MovieGen 則是基于 6000 張 H100 卡片進(jìn)行訓(xùn)練。由此可見，千卡乃至萬卡集群已成為眾多模型和廠商的標(biāo)配。xAI 更是宣布將自建一個(gè) 10 萬卡的集群。這表明，萬卡集群已成為新的技術(shù)門檻。
在萬卡集群中，有幾個(gè)核心指標(biāo)備受關(guān)注。首先是 MFU（Model Flops Utilization，模型利用率），其次是 HFU（Hardware Flops Utilization，硬件算力利用率），兩者存在一定差異。此外，集群的可用率，包括中斷次數(shù)等，也是當(dāng)前關(guān)注的焦點(diǎn)。
用戶角度看 AI 集群
從用戶視角來看，AI 集群面臨三大主要問題。首先，AI 集群的成本居高不下。用戶期望使用更強(qiáng)大的芯片和更高速的網(wǎng)絡(luò)，但這無疑會(huì)進(jìn)一步推高成本。其次，集群的穩(wěn)定性問題亟待解決。穩(wěn)定性受到多種因素的影響，例如計(jì)算錯(cuò)誤率、ECC（Error-Correcting Code，糾錯(cuò)碼）錯(cuò)誤率、網(wǎng)絡(luò)中斷以及板卡元器件失效等。這些因素都可能影響整個(gè) AI 集群的穩(wěn)定性。目前，一個(gè)大模型通常運(yùn)行在一個(gè)集群上，若其中一張卡出現(xiàn)中斷，整個(gè)模型可能都需要中斷。再次，集群的啟動(dòng)和運(yùn)行速度過慢。即使使用 PyTorch 拉起一個(gè)萬卡集群，完成心跳同步可能需要 20 到 30 分鐘，而下發(fā)任務(wù)時(shí)還需等待通信。因此，從用戶角度總結(jié)，AI 集群目前面臨的問題主要集中在成本高、穩(wěn)定性差以及運(yùn)行速度慢三個(gè)方面。
從生態(tài)角度看，英偉達(dá)在 PyTorch 領(lǐng)域構(gòu)建了天然的生態(tài)壁壘。無論是對(duì)于華為還是國(guó)內(nèi)其他芯片廠商而言，打破這種壟斷都并非易事。因此，越來越多的廠商開始逐漸接入 PyTorch 生態(tài)。從需求角度看，當(dāng)前大模型的訓(xùn)練場(chǎng)景，無論是大語言模型還是多模態(tài)大模型，都在推動(dòng)整個(gè) AI 集群的發(fā)展。未來，推理場(chǎng)景可能會(huì)逐漸成為推動(dòng)集群發(fā)展的新動(dòng)力。
AI 集群當(dāng)前的通用問題
從我們真正從事底層 Infra（基礎(chǔ)設(shè)施）工作的人的角度來看，當(dāng)前面臨的問題主要集中在以下幾個(gè)方面。首先，摩爾定律已開始逐漸失效。目前，計(jì)算芯片和網(wǎng)絡(luò)的增速遠(yuǎn)遠(yuǎn)落后于 AI 的計(jì)算量和參數(shù)量的增長(zhǎng)，差距甚至達(dá)到數(shù)倍之多。其次，假設(shè)芯片制程無法繼續(xù)提升，那么堆疊數(shù)量就成為一種解決方案。我們通過貼合封裝技術(shù)，將單個(gè)芯片擴(kuò)展為節(jié)點(diǎn)，將節(jié)點(diǎn)升級(jí)為超節(jié)點(diǎn)，最終將超節(jié)點(diǎn)組成一個(gè)超大規(guī)模的網(wǎng)絡(luò)集群。這種堆疊的方式已經(jīng)發(fā)展到相當(dāng)復(fù)雜的程度。
此外，芯片層級(jí)的新技術(shù)不斷涌現(xiàn)，但發(fā)展速度卻遠(yuǎn)低于預(yù)期。例如，片上 SRAM（靜態(tài)隨機(jī)存取存儲(chǔ)器）、片內(nèi) HBM（高帶寬存儲(chǔ)器）的 IO 帶寬，以及芯片的光照面積限制等問題，都在制約著芯片技術(shù)的發(fā)展。這些技術(shù)的發(fā)展速度遠(yuǎn)沒有我們想象中那么快，尤其是在我國(guó)，掌握這些核心技術(shù)的難度仍然較大。除了芯片內(nèi)部的技術(shù)挑戰(zhàn)，片外、帶外以及跨節(jié)點(diǎn)的互聯(lián)技術(shù)，如微光互聯(lián)和光交換，也相對(duì)落后。盡管國(guó)內(nèi)有一些創(chuàng)新創(chuàng)業(yè)公司在嘗試突破，但這一領(lǐng)域?qū)儆谥刭Y本產(chǎn)業(yè)，尤其是硅光互聯(lián)和光交換技術(shù)。一旦通信數(shù)據(jù)量達(dá)到一定規(guī)模，光交換就會(huì)受到物理極限的約束。同時(shí)，scale-up（縱向擴(kuò)展）與 scale-out（橫向擴(kuò)展）、存內(nèi)計(jì)算與寄存計(jì)算之間的爭(zhēng)論也在不斷涌現(xiàn)。例如，面對(duì)內(nèi)存不足的問題，是否可以通過凈存計(jì)算來解決？是否可以將或 HBM 與計(jì)算更加緊密地結(jié)合？這些都成為當(dāng)前需要面對(duì)的新問題。
能耗問題也尤為突出。一些二級(jí)市場(chǎng)或一級(jí)市場(chǎng)的投資人曾問我，是否有必要投資能源公司的股票，或者關(guān)注新建智算中心的能耗占比。事實(shí)上，智算中心的能耗占比非常高。目前，我們的機(jī)房大多建在貴州、內(nèi)蒙古等地，利用自然冷源進(jìn)行散熱，但風(fēng)冷已無法滿足需求，因此不得不轉(zhuǎn)向液冷技術(shù)，以降低溫度并減少能耗。然而，上述許多問題并非短時(shí)間內(nèi)能夠解決，但這并不意味著我們應(yīng)放棄努力。實(shí)際上，我們?nèi)杂性S多工作可以開展。
在這一領(lǐng)域，國(guó)內(nèi)外涌現(xiàn)出許多新的集群和云平臺(tái)公司。例如，國(guó)內(nèi)的阿里云、騰訊云、火山云、百度百舸，國(guó)際上的谷歌 TPU、亞馬遜 AWS，以及 Meta 等。華為也有自己的華為云，而昇騰則在很大程度上支撐了這些云服務(wù)和集群服務(wù)的運(yùn)行。
基于這些現(xiàn)狀，我們看到 AI 集群的性能提升主要集中在芯片能力、集群能力、算力效率和可用率等方面。在算法層面，常見的優(yōu)化手段包括計(jì)算優(yōu)化、通信優(yōu)化、并行優(yōu)化和內(nèi)存優(yōu)化。在推理加速方面，我們也做了大量工作，包括通信加速、解碼優(yōu)化、量化壓縮以及最優(yōu)并行調(diào)度優(yōu)化等。然而，這些內(nèi)容大多是脫離業(yè)務(wù)的。如果僅從硬件 Infra 支撐的角度來看，這些內(nèi)容與業(yè)務(wù)的關(guān)聯(lián)性并不強(qiáng)，顯得有些過于宏觀。今天，我主要想分享的是更深入、更具體、與昇騰或華為業(yè)務(wù)強(qiáng)相關(guān)的內(nèi)容。
集群組網(wǎng)優(yōu)化
參數(shù)面多軌組網(wǎng)
從百卡集群到千卡集群，再到萬卡集群，我們進(jìn)行了架構(gòu)的逐步優(yōu)化。下圖右邊的圖例中 100G 網(wǎng)絡(luò)對(duì)應(yīng)的是 100Gbps 的通信帶寬；GE（Gigabit Ethernet）是普通的以太網(wǎng)通信，帶寬相對(duì)較低；10GE 是帶外通信。在日常操作中，我們通常通過公網(wǎng)、云專用網(wǎng)或 IP 承載網(wǎng)，經(jīng)由最外層的路由器接入整個(gè)集群。而集群內(nèi)部真正運(yùn)行模型的部分是下圖中間的 AI 集群，存儲(chǔ)和計(jì)算集群是分開的。
因此我們產(chǎn)生了多個(gè)不同的業(yè)務(wù)面：參數(shù)面、業(yè)務(wù)面 / 數(shù)據(jù)面。參數(shù)面是指網(wǎng)絡(luò)模型參數(shù)傳遞的網(wǎng)絡(luò)。在一個(gè)萬卡集群中，用英偉達(dá)的卡， GPT-3 模型的 MFU（Model Flops Utilization，模型利用率）最高能達(dá)到 50%，大部分時(shí)間都在進(jìn)行網(wǎng)絡(luò)通信，通信對(duì)我們來說已經(jīng)變得非常關(guān)鍵。當(dāng)時(shí)，參數(shù)面主要采用多軌主網(wǎng)架構(gòu)，參數(shù)面接入的是 100G 的 RoCE（RDMA over Converged Ethernet）網(wǎng)絡(luò)，這是一種典型的配置。數(shù)據(jù)面和業(yè)務(wù)面負(fù)責(zé)將存儲(chǔ)的圖片、文本以及對(duì)話數(shù)據(jù)等，通過存儲(chǔ)后端傳遞給計(jì)算面，即我們的 AI 集群。在參數(shù)面的早期階段，即 2020 年之前，當(dāng)時(shí)還沒有大規(guī)模推動(dòng)千卡或萬卡集群時(shí)，我們的組網(wǎng)方案相對(duì)簡(jiǎn)單。
參數(shù)面由多軌調(diào)整為單軌
集群組網(wǎng)，尤其是英偉達(dá)的萬卡組網(wǎng)，是在近兩年才逐漸興起的概念。在過去，很少有人提及萬卡集群或千卡集群。由于早期集群中沒有獨(dú)立的數(shù)據(jù)面，數(shù)據(jù)面與業(yè)務(wù)面合為一體，通常通過 NFS（Network File System，網(wǎng)絡(luò)文件系統(tǒng)）協(xié)議進(jìn)行訪問。這種架構(gòu)存在潛在風(fēng)險(xiǎn)，數(shù)據(jù)可能因訪問協(xié)議的開放性而外泄。這成為許多客戶極為關(guān)心的問題：購(gòu)買集群后，數(shù)據(jù)應(yīng)如何得到有效保護(hù)？如果數(shù)據(jù)面與業(yè)務(wù)面沒有分離，且上層連接路由器，一旦接入路由器，網(wǎng)絡(luò)很容易受到攻擊，進(jìn)而導(dǎo)致數(shù)據(jù)被訪問或泄露。
盡管目前在大模型訓(xùn)練中，數(shù)據(jù)安全問題尚未成為主要關(guān)注點(diǎn)，但對(duì)于許多 B 端企業(yè)，尤其是業(yè)務(wù)級(jí)公司來說，數(shù)據(jù)泄露風(fēng)險(xiǎn)是他們極為重視的問題。在早期的百卡集群中，樣本面與業(yè)務(wù)面的網(wǎng)絡(luò)是共享的，組成了一個(gè)多軌的 100G RoCE 網(wǎng)絡(luò)。這種架構(gòu)會(huì)影響整個(gè) IO 的讀取速率，因此我們對(duì)方案進(jìn)行了升級(jí)。
在千卡集群階段，我們不能再沿用早期的架構(gòu)。經(jīng)過深入研究并與眾多客戶交流后，我們將數(shù)據(jù)面從整體架構(gòu)中分離出來。在 AI 集群中，我們從多軌方案轉(zhuǎn)變?yōu)閱诬壏桨?。多軌方案存在一個(gè)較為致命的問題：維護(hù)成本極高。雖然它可以連接多個(gè)二級(jí)交換機(jī)，使集群規(guī)模更大，但維護(hù)成本的增加會(huì)導(dǎo)致可用性下降。尤其是在千卡集群中，我們希望集群能夠隨時(shí)啟動(dòng)，避免像萬卡集群那樣頻繁出現(xiàn)錯(cuò)誤、掉卡或網(wǎng)絡(luò)中斷等問題，包括光模塊故障等。
因此，我們將參數(shù)面從多軌調(diào)整為單軌，并將網(wǎng)絡(luò)帶寬從 100G RoCE 升級(jí)到 200G RoCE，從而提升了參數(shù)面的整體性能。提升參數(shù)面性能的目的是為了提高節(jié)點(diǎn)之間的通信效率，最終實(shí)現(xiàn)參數(shù)面與數(shù)據(jù)面（即業(yè)務(wù)面）的分離，并將 NFS 協(xié)議改為 DPC（Direct Parallel Communication，直接并行通信）協(xié)議進(jìn)行訪問。
目前，一些廠商可能會(huì)將數(shù)據(jù)直接存儲(chǔ)在 AI 集群的每個(gè)節(jié)點(diǎn)中，但這種方式對(duì)數(shù)據(jù)的維護(hù)和管理帶來了極大挑戰(zhàn)，尤其是對(duì)于 CKPT（Checkpoint，檢查點(diǎn)）數(shù)據(jù)。在實(shí)際業(yè)務(wù)上線時(shí)，可能會(huì)存在多個(gè)分散的 AI 集群，因此配備一個(gè)集中的存儲(chǔ)端口是非常必要的，尤其是面向未來的推理集群。如今，我們的整體架構(gòu)包括一個(gè)訓(xùn)練集群、一個(gè)獨(dú)立的存儲(chǔ)區(qū)域以及一個(gè)管理區(qū)域，分別用于管理帶內(nèi)和帶外網(wǎng)絡(luò)。通過這種方式，我們將之前提到的問題進(jìn)行了有效隔離，盡可能確保整個(gè)網(wǎng)絡(luò)和網(wǎng)段的安全性，同時(shí)實(shí)現(xiàn)了數(shù)據(jù)與業(yè)務(wù)的分離。
提高計(jì)算側(cè)數(shù)據(jù)面接入網(wǎng)卡速率
我們正在進(jìn)行架構(gòu)演進(jìn)，以應(yīng)對(duì)對(duì)萬卡集群甚至更大規(guī)模的方案。隨著大模型的興起，尤其是強(qiáng)化學(xué)習(xí)的廣泛應(yīng)用，數(shù)據(jù)源源不斷地從存儲(chǔ)集群流向 AI 集群，甚至推理集群。在推理業(yè)務(wù)中，數(shù)據(jù)持續(xù)產(chǎn)生，因此我們需要減少 AI 集群與存儲(chǔ)區(qū)之間的數(shù)據(jù)傳輸延遲，盡可能拉近它們之間的距離。為此，我們制定了新的方案，適用于萬卡集群以及未來的 Post-Training（后訓(xùn)練）和推理業(yè)務(wù)場(chǎng)景。在這一方案中，我們將計(jì)算面的網(wǎng)絡(luò)從 2×25G 升級(jí)為 2×100G 的 RoCE 網(wǎng)絡(luò)。整體網(wǎng)絡(luò)架構(gòu)中，綠色的連接線已發(fā)生變化，全部采用 DPC（Direct Parallel Communication）協(xié)議進(jìn)行訪問。最重要的是，我們?cè)俅畏蛛x了樣本面與業(yè)務(wù)面，目前仍采用單軌方案，服務(wù)器到 Leaf（葉節(jié)點(diǎn)）之間采用二分之一的線纜連接。這種設(shè)計(jì)的核心目標(biāo)是提升網(wǎng)絡(luò)性能，盡可能減少等待時(shí)間。
針對(duì)萬卡集群的維護(hù)難題，我們優(yōu)化了方案。萬卡集群的維護(hù)極為復(fù)雜，一旦有一張卡掉線，可能會(huì)影響整個(gè)萬卡集群的大模型訓(xùn)練。因此，我們通過減少維護(hù)工作量，提高集群的整體可用性。此外，訓(xùn)練區(qū)采用了全液冷方案，參數(shù)面和業(yè)務(wù)面被進(jìn)一步分離，整體線路更加清晰，便于維護(hù)。同時(shí)，存儲(chǔ)區(qū)和管理區(qū)也進(jìn)行了新的業(yè)務(wù)隔離，以更好地支持萬卡集群的運(yùn)維需求。
從百卡方案到千卡方案，再到萬卡集群方案，我們?cè)谧龅氖虑榭赡苡脩綦y以感知，但對(duì)于從事底層系統(tǒng)工作的人來說，這些內(nèi)容極為核心且備受關(guān)注。性能的優(yōu)劣并非僅僅取決于并行策略的先進(jìn)性，更在于網(wǎng)絡(luò)如何組網(wǎng)，以及并行策略如何根據(jù)組網(wǎng)方案進(jìn)行優(yōu)化。在使用英偉達(dá)集群時(shí)，用戶會(huì)發(fā)現(xiàn)其提供了成熟的 TPPP（Tensor Parallelism、Pipeline Parallelism 等）切分方案，大家通常會(huì)按照這一方案進(jìn)行并行計(jì)算。然而，當(dāng)面對(duì)新的集群，尤其是國(guó)產(chǎn)集群或不同網(wǎng)絡(luò)架構(gòu)的集群時(shí)，切分方式和并行方式會(huì)有所不同。因此，若想真正做好這一領(lǐng)域，實(shí)現(xiàn)性能的最優(yōu)，就必須深入到底層進(jìn)行探索。
多模態(tài)性能優(yōu)化
SORA 多模態(tài)
在多模態(tài)場(chǎng)景中，以我們近期支持的 SORA 大模型為例，該模型自 2 月中旬推出以來，國(guó)內(nèi)已有眾多公司在開展圖文生成和視頻生成的相關(guān)工作。在視頻生成任務(wù)中，大規(guī)模集群的應(yīng)用必不可少。然而，大規(guī)模集群不僅成本高昂，還面臨諸多問題。首先，面向新的業(yè)務(wù)場(chǎng)景時(shí)，不再是像 LLM 那樣可以直接使用。例如，SORA 并未公開代碼，用戶需要自行編寫或運(yùn)行代碼。如果代碼無法運(yùn)行，那么大量計(jì)算資源（如萬卡集群）將被閑置浪費(fèi)。即使集群處于通電狀態(tài)但未運(yùn)行任何業(yè)務(wù)，也是一種巨大的浪費(fèi)。如果代碼運(yùn)行出錯(cuò)，同樣意味著計(jì)算資源的浪費(fèi)。因此，我們希望在按下回車鍵的那一刻，所有配置都是正確的，能夠在兩個(gè)月內(nèi)成功訓(xùn)練出一個(gè)文生視頻的大模型。
我們?cè)?SORA 多模態(tài)業(yè)務(wù)中究竟做了哪些工作呢？首先，我們會(huì)分析網(wǎng)絡(luò)模型或業(yè)務(wù)場(chǎng)景對(duì)每一層的挑戰(zhàn)。客戶最關(guān)心的往往是軟件層面的挑戰(zhàn)，因?yàn)檐浖c客戶的算法和業(yè)務(wù)緊密相關(guān)。其次，我們也會(huì)關(guān)注芯片層面的挑戰(zhàn)，而生態(tài)和算法層面雖然也很重要，但并非我們最關(guān)注的點(diǎn)。從性能角度來看，我們目前如何基于千卡規(guī)模訓(xùn)練一個(gè)文生圖模型，因?yàn)槲纳曨l模型本質(zhì)上仍源于文生圖模型。我們會(huì)分析文生圖模型的業(yè)務(wù)痛點(diǎn)和問題。例如，batch size（批量大?。?huì)不會(huì)特別大，是否容易出現(xiàn) host bonding（下發(fā)瓶頸）問題。由于圖片是一張張?zhí)幚淼?，即使設(shè)置了 batch size，將多張圖片打包下發(fā)時(shí)，很容易形成瓶頸。此外，在文生圖和文生視頻的訓(xùn)練中，我們不是像大語言模型那樣一次性處理所有圖片和文字，而是多次處理所有數(shù)據(jù)或圖片，這相當(dāng)于多次訓(xùn)練 RoPE（Rotary Position Embedding）。接著，我們會(huì)處理不同分辨率的負(fù)載問題。在訓(xùn)練視頻或圖片大模型時(shí)，數(shù)據(jù)分辨率的差異較大，有些圖片大，有些圖片小。如果將圖片尺寸固定為某一規(guī)格，生成結(jié)果的靈活性將大打折扣。此外，我們還會(huì)研究分布式推理、稀疏場(chǎng)景以及下采樣策略等，深入剖析每一個(gè)算法細(xì)節(jié)，以提升性能。
在內(nèi)存方面，國(guó)產(chǎn)芯片的內(nèi)存規(guī)格與英偉達(dá)的有所不同。英偉達(dá)的 A100 芯片內(nèi)存為 80GB，H100 為 96GB，甚至還有高配版 164GB，但國(guó)產(chǎn)芯片由于 HBM（High Bandwidth Memory，高帶寬存儲(chǔ)器）供應(yīng)問題（HBM 主要依賴國(guó)外供應(yīng)，國(guó)內(nèi)產(chǎn)量較低），其內(nèi)存規(guī)格與英偉達(dá)不同。由于供應(yīng)鏈問題導(dǎo)致內(nèi)存大小的差異，我們可能需要采用不同的內(nèi)存優(yōu)化方案、切分方式，以及在每張卡上運(yùn)行的小模型或參數(shù)的大小也會(huì)有所不同。因此，我們需要深入研究?jī)?nèi)存優(yōu)化策略。此外，精度問題也極為復(fù)雜。它可能涉及硬件問題、用戶代碼問題，甚至可能是訓(xùn)練技巧不足。目前，真正掌握大模型訓(xùn)練技巧的人才極為稀缺，每個(gè)人在運(yùn)行萬卡大模型時(shí)，一旦按下回車鍵，模型運(yùn)行失敗，往往會(huì)懷疑是硬件不行，而不會(huì)首先考慮是算法問題。因此，精度問題也是我們研究的重點(diǎn)之一。
性能瓶頸分析
對(duì)于 3D Attention 來說，當(dāng)圖片或視頻的分辨率提升 n 倍時(shí)，序列長(zhǎng)度和動(dòng)態(tài)內(nèi)存的使用量會(huì)變?yōu)樵瓉淼?n2 倍，而 Attention 計(jì)算的開銷則會(huì)增加到 n? 倍。這是因?yàn)閳D片和視頻的維度包括長(zhǎng)、寬、高以及時(shí)間序列，整體計(jì)算開銷非常大。此外，視頻的變化也會(huì)導(dǎo)致整體計(jì)算開銷顯著增加。
在 3D Attention 的應(yīng)用場(chǎng)景中，例如生成紋身視頻時(shí)，序列長(zhǎng)度可以達(dá)到百 k 級(jí)別。大部分計(jì)算集中在 Fresh Attention 這一算子上，因此我們可以進(jìn)行整體分析。在下圖的左側(cè)，我們將每一幀及其對(duì)應(yīng)的 Fashion Attention 的 Ship 提取出來，并分析整個(gè) MPU 的耗時(shí)，以及每次計(jì)算所使用的內(nèi)存或顯存。而在右側(cè)的細(xì)節(jié)圖中，我們進(jìn)一步深入分析在每一微秒、每一毫秒內(nèi)需要執(zhí)行的具體計(jì)算內(nèi)容。
整體來看，3D Attention 對(duì)性能和內(nèi)存的挑戰(zhàn)極大。目前，單步迭代時(shí)間已達(dá)到 170 秒，這意味著僅完成一次迭代就需要如此長(zhǎng)的時(shí)間。因此，除了前面提到的優(yōu)化措施外，我們還需要引入序列并行或改進(jìn)模型結(jié)構(gòu)，以進(jìn)一步提升性能。
訓(xùn)練 DeepSpeed 精度問題
精度問題。最初，我們與北京大學(xué)的兔展智能合作，參與了 Open SORA Plan 這一開源項(xiàng)目。當(dāng)時(shí)，該項(xiàng)目使用的是 DeepSpeed 框架，即微軟的分布式訓(xùn)練框架。然而，我們?cè)谑褂眠^程中發(fā)現(xiàn)該框架存在一些問題，尤其是在算子層面。因此，我們決定不再使用 DeepSpeed 框架。在萬卡集群的訓(xùn)練場(chǎng)景下，我們無法確切判斷每一個(gè)中間件是否存在潛在問題。DeepSpeed 是微軟開發(fā)的，但業(yè)界尚未有在萬卡集群上運(yùn)行的成功案例。如果出現(xiàn)問題，很難判斷是微軟框架的問題還是硬件本身的問題。因此，我們最終放棄了 DeepSpeed，轉(zhuǎn)而使用 PyTorch 的分布式數(shù)據(jù)并行 DDP 進(jìn)行訓(xùn)練。結(jié)果發(fā)現(xiàn)，使用 PyTorch DDP 時(shí)精度表現(xiàn)正常，而使用 DeepSpeed 時(shí)則會(huì)出現(xiàn)精度問題。
在 DeepSpeed 框架下，我們還發(fā)現(xiàn)了一個(gè)有趣的現(xiàn)象：當(dāng)使用 4GB 的混合精度訓(xùn)練時(shí)，loss（損失值）表現(xiàn)正常；但當(dāng)擴(kuò)展到 8GB 訓(xùn)練時(shí)，loss 會(huì)異常。我們當(dāng)時(shí)對(duì)這一問題進(jìn)行了深入研究。在 DeepSpeed 的框架下，我們嘗試通過梯度累積的方式模擬大 batch size 的訓(xùn)練，此時(shí) loss 仍然表現(xiàn)正常。然而，在實(shí)際運(yùn)行大模型時(shí)，情況并非如此簡(jiǎn)單。
為了避免潛在問題，我們會(huì)在小規(guī)模參數(shù)下進(jìn)行“演習(xí)”，例如將一個(gè) 100B 參數(shù)的模型縮減為 10B 參數(shù)，在小規(guī)模集群中進(jìn)行簡(jiǎn)單驗(yàn)證。通過這種方式，我們能夠排除許多與算法或超參數(shù)相關(guān)的影響。在 DeepSpeed 框架中，我們發(fā)現(xiàn)精度問題主要源于 all_gather 算子。因此，我們對(duì) DeepSpeed 框架進(jìn)行了一些修改和優(yōu)化，并將這些代碼貢獻(xiàn)給了 DeepSpeed 社區(qū)。此外，我們還更新了底層算子庫，解決了 DeepSpeed Zero-1 和 Zero-2 的一些精度問題。
對(duì)內(nèi)存的優(yōu)化
我們看一下內(nèi)存性能和精度優(yōu)化的相關(guān)案例。實(shí)際上，在進(jìn)入 DIT（Diffusion-based Inference and Training，基于擴(kuò)散模型的推理與訓(xùn)練）領(lǐng)域后，盡管 Meta 最近發(fā)布的文章指出，使用 DIT 進(jìn)行推理或生成時(shí)，其整體耗時(shí)可能會(huì)受到影響，因此目前許多互聯(lián)網(wǎng)廠商和合作伙伴又開始轉(zhuǎn)向使用自回歸方法進(jìn)行文生視頻任務(wù)。然而，在使用 DIT 的過程中，整個(gè)流程會(huì)涉及視頻數(shù)據(jù)處理、分辨率變換、VAE 編碼、文本編碼以及編解碼問題。如果考慮到不同分辨率，目前多種分辨率會(huì)導(dǎo)致不同的 batch 預(yù)處理開銷，而每個(gè) batch 的開銷不同又會(huì)導(dǎo)致 host 負(fù)載不均衡，進(jìn)而影響整體訓(xùn)練性能，表現(xiàn)為訓(xùn)練性能的抖動(dòng)。
那么，這種抖動(dòng)究竟是由硬件還是軟件引起的呢？經(jīng)過分析，我們最終發(fā)現(xiàn)這是由算法原因?qū)е碌?。因此，我們總結(jié)出文生視頻的三個(gè)典型特點(diǎn)：
數(shù)據(jù)預(yù)處理是一個(gè)重負(fù)載；
數(shù)據(jù)通常需要訓(xùn)練多個(gè) Epoch；
訓(xùn)練步數(shù)（200k-1000k）更重要，Batch Size 不那么重要。
針對(duì)上述三個(gè)問題，我們采用了數(shù)據(jù)預(yù)處理方案。在 EPOCH 0（第 0 輪訓(xùn)練）時(shí)，我們保存 VAE 編碼和文本編碼的結(jié)果，盡可能多地將這些中間結(jié)果存儲(chǔ)下來。從第二輪訓(xùn)練（EPOCH 1）開始，不再重新計(jì)算整體編碼，從而減少 host 的計(jì)算開銷，并充分發(fā)揮存儲(chǔ)系統(tǒng)的性能優(yōu)勢(shì)。這一優(yōu)化方案也與我們之前提到的參數(shù)面與業(yè)務(wù)面分離、提升計(jì)算集群與存儲(chǔ)集群網(wǎng)絡(luò)性能等內(nèi)容密切相關(guān)。由于集群組網(wǎng)方案的變更，我們引入了新的加速手段。
解決內(nèi)存不足問題
在當(dāng)前的 NPU 架構(gòu)中，為了應(yīng)對(duì)內(nèi)存不足的問題并提升性能，引入了序列并行技術(shù)，尤其是在處理類似 SORA 這種復(fù)雜模型時(shí)顯得尤為重要。與傳統(tǒng)的 LLM 相比，SORA 的序列并行更為復(fù)雜，主要面臨以下三大挑戰(zhàn)：
訓(xùn)練模式復(fù)雜：Sora 的訓(xùn)練同時(shí)涉及圖片和視頻數(shù)據(jù)，其中圖片不參與序列并行（SP），而視頻數(shù)據(jù)則參與 SP 并行。這種差異導(dǎo)致在并行策略設(shè)計(jì)上需要針對(duì)不同類型的數(shù)據(jù)進(jìn)行區(qū)分處理。
時(shí)空 Attention 機(jī)制復(fù)雜：Sora 模型包含時(shí)空 Attention 機(jī)制，其空間 Transformer 層中，Batch 維度對(duì)應(yīng)時(shí)間，序列維度對(duì)應(yīng)空間；而時(shí)間 Transformer 層中，Batch 維度對(duì)應(yīng)空間，序列維度對(duì)應(yīng)時(shí)間。序列并行僅針對(duì)時(shí)間 Transformer 層進(jìn)行處理，且在并行過程中，Tensor 的布局會(huì)在 BSH（Batch, Sequence, Hidden）和 SBH（Sequence, Batch, Hidden）之間交替變換，以適應(yīng) All2All 通信的需求。
輸入數(shù)據(jù)多且復(fù)雜：Sora 基于 Text2Video，屬于多模態(tài)模型，輸入數(shù)據(jù)包括 Timestep（用于擴(kuò)散模型）、文本編碼（用于 Cross Attention）、視頻 Mask 和文本 Mask 等。由于序列并行需要對(duì)所有輸入數(shù)據(jù)進(jìn)行 All2All 處理，以確保計(jì)算的正確性，這進(jìn)一步增加了并行策略的復(fù)雜性。
解決 Attention 計(jì)算復(fù)雜度高問題
在算法層面，我們不僅進(jìn)行了諸多工程性的細(xì)粒度優(yōu)化，還提出了一種稀疏注意力（Sparse Attention）機(jī)制，以解決傳統(tǒng)注意力機(jī)制計(jì)算復(fù)雜度較高的問題。這一機(jī)制與傳統(tǒng)方法有所不同，是我們與華為諾亞研究院（2012 實(shí)驗(yàn)室）合作探索的新算法方向。具體實(shí)現(xiàn)分為三個(gè)階段：
第一階段：聚類
在注意力模塊中，$\text{Softmax}\left(\frac{QK^T}{\text{Scale}}\right)$ 權(quán)重矩陣的每個(gè) Token $Q _ i$ 與向量 _K_ 的相似度呈現(xiàn)出一定的規(guī)律性?；谶@種規(guī)律性，可以將相似度分布相近的 Token $Q _ i$ 進(jìn)行聚類，聚類結(jié)果如圖 3 所示。
第二階段：重排計(jì)算
對(duì)第一階段得到的聚類結(jié)果，每行按照相似度大小由高到低進(jìn)行排序。由于每份聚類結(jié)果 $CQ ^ i$ 中的每個(gè) Token 與向量 _K_ 的相似度分布相近，可以設(shè)置一個(gè)固定閾值 _?_，對(duì)相似度小于 _?_ 的 Token $K _ i$ 進(jìn)行過濾。因此，每份 $CQ ^ i$ 都將對(duì)應(yīng)得到一個(gè)更小的矩陣 $CK ^ i$。隨后，對(duì)重排后的矩陣 $CQ ^ i$ 和 $CK ^ i$ 進(jìn)行計(jì)算，得到權(quán)重矩陣的子結(jié)果（如圖 4 紅色框內(nèi)部分所示）。整體計(jì)算性能的提升與矩陣 $CK ^ i$ 的序列縮短長(zhǎng)度成正比。
第三階段：補(bǔ)齊還原
將第二階段得到的子結(jié)果按照向量 _K_ 的長(zhǎng)度進(jìn)行補(bǔ)齊（補(bǔ)齊值為 0），然后重排還原。最后，將所有子結(jié)果拼接，得到完整的權(quán)重矩陣計(jì)算結(jié)果。
通過這一系列操作，我們主要目的是去除大量冗余的、無關(guān)緊要的計(jì)算。計(jì)算量的減少自然也會(huì)導(dǎo)致數(shù)據(jù)量的降低，進(jìn)而減少存儲(chǔ)需求。存儲(chǔ)需求的降低進(jìn)一步提升了訓(xùn)練性能，因?yàn)樾酒瑑?nèi)部的數(shù)據(jù)搬運(yùn)過程是按照微秒級(jí)別進(jìn)行的：數(shù)據(jù)從存儲(chǔ)單元搬運(yùn)到計(jì)算核心，計(jì)算完成后又在微秒級(jí)別內(nèi)搬運(yùn)回存儲(chǔ)單元。這一過程非常耗時(shí)，因此通過減少計(jì)算和存儲(chǔ)需求，整體性能得到了顯著提升。
小紅書案例
在支撐多模態(tài)場(chǎng)景的工作中，我們進(jìn)行了一些基礎(chǔ)但關(guān)鍵的 Infra（基礎(chǔ)設(shè)施）層面的優(yōu)化。華為在這方面的工作與其他公司有所不同，我們專注于分析業(yè)務(wù)需求，抽象出可以提升性能的關(guān)鍵點(diǎn)，特別是在計(jì)算、內(nèi)存以及路由通信網(wǎng)絡(luò)等方面。在在這個(gè)小紅書案例中使用了華為云服務(wù)。由于華為云的組網(wǎng)方案已經(jīng)確定并構(gòu)建完成，因此我們不再需要考慮組網(wǎng)方案的演進(jìn)，而是在一個(gè)已經(jīng)達(dá)到次優(yōu)狀態(tài)的云環(huán)境中工作。
在處理大模型時(shí)，我們面臨的主要任務(wù)是提升性能。許多基礎(chǔ)問題已經(jīng)得到解決，因此我們轉(zhuǎn)而分析可以進(jìn)一步優(yōu)化的方案。我們對(duì)算子通信、算法等方面進(jìn)行了深入分析，并收集了性能分析數(shù)據(jù)。通過對(duì)比 GPU 和 NPU 的性能分析，我們確定了性能瓶頸和通信耗時(shí)的阻塞點(diǎn)，以及計(jì)算耗時(shí)的具體位置。
經(jīng)過分析，我們識(shí)別出了所有可以提升性能的關(guān)鍵點(diǎn)。對(duì)于耗時(shí)過長(zhǎng)的算子，我們進(jìn)行了等價(jià)替換。例如，我們發(fā)現(xiàn) reduce getter 算子實(shí)際上是由 all reduce 和 all getter 兩個(gè)算子組合而成的，可以將其視為一個(gè)通信算子。此外，All2All 通信也可以通過點(diǎn)對(duì)點(diǎn)通信的組合來實(shí)現(xiàn)，這是一種等價(jià)替換。
我們還充分利用了 AI Core 的能力。華為的芯片以及國(guó)內(nèi)其他芯片廠商的產(chǎn)品與英偉達(dá)的 GPU 有所不同，后者擁有大量的 CUDA Core 和 Tensor Core。而我們的芯片擁有專門的 AI Core，這是華為芯片的最大特點(diǎn)之一。我們盡可能地將算力集中在 AI Core 上。此外，我們還采用了空間換時(shí)間的策略，以及多融合算子或自定義融合算子進(jìn)行優(yōu)化。最后，我們還進(jìn)行了通信優(yōu)化，進(jìn)一步提升了系統(tǒng)的整體性能。
總結(jié)與思考
在大模型訓(xùn)練領(lǐng)域，尤其是千卡萬卡規(guī)模的模型訓(xùn)練中，基礎(chǔ)設(shè)施（Infra）性能提升的關(guān)鍵并非僅限于分布式并行策略的研究與應(yīng)用。去年，我主要負(fù)責(zé)大模型訓(xùn)練的系統(tǒng)工程（SE），當(dāng)時(shí)的工作重心集中在分布式并行上。因此，我主導(dǎo)開發(fā)了一個(gè)名為“AscendSpeed”、現(xiàn)在稱為“MindSpeed”的框架，專門用于性能優(yōu)化。
除了分布式并行策略，我們還需要在單個(gè)芯片上運(yùn)行一些大型融合算子，例如 Fetch Attention。這種算子在小規(guī)模集群中能夠顯著提升性能，甚至可能達(dá)到兩倍的提升效果。此外，我們還需要研究集合通信算法各種 NCCL 庫，以及環(huán)回算法。內(nèi)存優(yōu)化算法也是我們研究的重點(diǎn)。
大多數(shù)人可能會(huì)認(rèn)為，在萬卡集群中提升性能只需關(guān)注上述這些方面。但實(shí)際上，萬卡集群的構(gòu)成遠(yuǎn)比這復(fù)雜。例如，光模塊的功率、溫度、連通性以及信噪比等各種各樣的因素都會(huì)影響集群的性能。在真正的基礎(chǔ)設(shè)施層面，尤其是在底層基礎(chǔ)設(shè)施層面，我們的工作往往并不那么“高大上”，很多時(shí)候更像是在從事體力勞動(dòng)。
以我 2024 年 6 月份在集群機(jī)房的兩周經(jīng)歷為例，我在那里就是為了解決這些基礎(chǔ)設(shè)施層面的問題。這些問題雖然看似瑣碎，但卻對(duì)集群的整體性能有著至關(guān)重要的影響。因此，我們的工作不僅僅是研究和應(yīng)用先進(jìn)的并行策略，還包括了對(duì)基礎(chǔ)設(shè)施的細(xì)致打磨和優(yōu)化。
演講嘉賓介紹
ZOMI 醬，華為昇騰生態(tài)技術(shù)首席。作為第一作者著有《 AI 系統(tǒng)：原理與架構(gòu)》等 3 本專著，并累積發(fā)表了 113 篇發(fā)明類專利。B 站 AI 領(lǐng)域著名 UP 主（ ZOMI 醬），全網(wǎng)播放量超千萬。
會(huì)議推薦
在 AI 大模型重塑軟件開發(fā)的時(shí)代，我們?nèi)绾伟盐兆兏?？如何突破技術(shù)邊界？4 月 10-12 日，QCon 全球軟件開發(fā)大會(huì)· 北京站 邀你共赴 3 天沉浸式學(xué)習(xí)之約，跳出「技術(shù)繭房」，探索前沿科技的無限可能。
本次大會(huì)將匯聚頂尖技術(shù)專家、創(chuàng)新實(shí)踐者，共同探討多行業(yè) AI 落地應(yīng)用，分享一手實(shí)踐經(jīng)驗(yàn)，深度參與 DeepSeek 主題圓桌，洞見未來趨勢(shì)。
熱門跟貼