分享嘉賓 | ZOMI 醬

審校 | Kitty

策劃 | QCon 全球軟件開發(fā)大會

隨著大模型技術(shù)從技術(shù)變革轉(zhuǎn)向產(chǎn)業(yè)變革，大模型應(yīng)用也會進一步繁榮，傳統(tǒng)基礎(chǔ)設(shè)施技術(shù)已經(jīng)不足以滿足大模型應(yīng)用的快速發(fā)展。整個基礎(chǔ)設(shè)施技術(shù)和產(chǎn)業(yè)鏈正在快速轉(zhuǎn)型，向大模型基礎(chǔ)設(shè)施技術(shù)演變。2025 QCon 全球軟件開發(fā)大會（北京站）策劃了「面向 AI 的研發(fā)基礎(chǔ)設(shè)施」專題，通過本專題的深入探討，希望讓聽眾了解并掌握大模型基礎(chǔ)設(shè)施技術(shù)的發(fā)展趨勢和前沿動態(tài)，從企業(yè)工程實踐和學(xué)術(shù)研究領(lǐng)域借鑒成功經(jīng)驗，為自身企業(yè)制定更大規(guī)模、更高性能以及更加穩(wěn)定的大模型基礎(chǔ)設(shè)施技術(shù)。詳見會議官網(wǎng)：https://qcon.infoq.cn/2025/beijing/

萬卡集群在執(zhí)行大規(guī)模網(wǎng)絡(luò)模型訓(xùn)練任務(wù)時負(fù)載重，面臨功耗、網(wǎng)絡(luò)拓?fù)洹⒖煽啃院凸收匣謴?fù)、并行計算、成本分析等多方面的挑戰(zhàn)。越來越多開發(fā)者希望更好地駕馭萬卡集群，提升大規(guī)模網(wǎng)絡(luò)模型在萬卡集群訓(xùn)練的集群整體性能。

在 InfoQ 舉辦的 QCon 全球軟件開發(fā)大會上，華為昇騰生態(tài)技術(shù)首席 ZOMI 醬為我們帶來了精彩演講“大模型在超大規(guī)模集群上的性能提升實踐”，深入探索如何在萬卡昇騰 NPU 集群上，基于業(yè)界典型 AI 框架和 MindSpeed 分布式并行加速庫，結(jié)合網(wǎng)絡(luò)拓?fù)鋬?yōu)化算法和華為開源 HCCL 集合通信庫協(xié)同優(yōu)化，并深入剖析了萬卡集群訓(xùn)練過程中涉及的技術(shù)原理和難點，探討萬卡集群訓(xùn)練的性能和穩(wěn)定性策略，最后結(jié)合案例講解面向萬卡集群的性能提升實踐。

以下是演講實錄（經(jīng) InfoQ 進行不改變原意的編輯整理）：

我整體分享的內(nèi)容分為四個部分。首先，我們來看一下大規(guī)模集群的發(fā)展；接著，我們探討集群組網(wǎng)的整體優(yōu)化，特別是華為是如何做的，從百卡集群到千卡集群，再到如今的萬卡集群，整體組網(wǎng)方案的演進；然后我會分享多模態(tài)性能優(yōu)化的案例；最后通過一個小紅書的簡單案例做一些總結(jié)。

大規(guī)模集群發(fā)展

盡管萬卡集群在當(dāng)下似乎已不再稀奇，但對于高校、個人開發(fā)者以及一些小型獨立軟件供應(yīng)商（ISV）而言，萬卡集群的構(gòu)建仍然極具挑戰(zhàn)性。Meta 的 LLaMA 43.1 基于 1.6 萬張 H100 GPU 卡片開發(fā)；而近期發(fā)布的 MovieGen 則是基于 6000 張 H100 卡片進行訓(xùn)練。由此可見，千卡乃至萬卡集群已成為眾多模型和廠商的標(biāo)配。xAI 更是宣布將自建一個 10 萬卡的集群。這表明，萬卡集群已成為新的技術(shù)門檻。

在萬卡集群中，有幾個核心指標(biāo)備受關(guān)注。首先是 MFU（Model Flops Utilization，模型利用率），其次是 HFU（Hardware Flops Utilization，硬件算力利用率），兩者存在一定差異。此外，集群的可用率，包括中斷次數(shù)等，也是當(dāng)前關(guān)注的焦點。

用戶角度看 AI 集群

從用戶視角來看，AI 集群面臨三大主要問題。首先，AI 集群的成本居高不下。用戶期望使用更強大的芯片和更高速的網(wǎng)絡(luò)，但這無疑會進一步推高成本。其次，集群的穩(wěn)定性問題亟待解決。穩(wěn)定性受到多種因素的影響，例如計算錯誤率、ECC（Error-Correcting Code，糾錯碼）錯誤率、網(wǎng)絡(luò)中斷以及板卡元器件失效等。這些因素都可能影響整個 AI 集群的穩(wěn)定性。目前，一個大模型通常運行在一個集群上，若其中一張卡出現(xiàn)中斷，整個模型可能都需要中斷。再次，集群的啟動和運行速度過慢。即使使用 PyTorch 拉起一個萬卡集群，完成心跳同步可能需要 20 到 30 分鐘，而下發(fā)任務(wù)時還需等待通信。因此，從用戶角度總結(jié)，AI 集群目前面臨的問題主要集中在成本高、穩(wěn)定性差以及運行速度慢三個方面。

從生態(tài)角度看，英偉達在 PyTorch 領(lǐng)域構(gòu)建了天然的生態(tài)壁壘。無論是對于華為還是國內(nèi)其他芯片廠商而言，打破這種壟斷都并非易事。因此，越來越多的廠商開始逐漸接入 PyTorch 生態(tài)。從需求角度看，當(dāng)前大模型的訓(xùn)練場景，無論是大語言模型還是多模態(tài)大模型，都在推動整個 AI 集群的發(fā)展。未來，推理場景可能會逐漸成為推動集群發(fā)展的新動力。

AI 集群當(dāng)前的通用問題

從我們真正從事底層 Infra（基礎(chǔ)設(shè)施）工作的人的角度來看，當(dāng)前面臨的問題主要集中在以下幾個方面。首先，摩爾定律已開始逐漸失效。目前，計算芯片和網(wǎng)絡(luò)的增速遠(yuǎn)遠(yuǎn)落后于 AI 的計算量和參數(shù)量的增長，差距甚至達到數(shù)倍之多。其次，假設(shè)芯片制程無法繼續(xù)提升，那么堆疊數(shù)量就成為一種解決方案。我們通過貼合封裝技術(shù)，將單個芯片擴展為節(jié)點，將節(jié)點升級為超節(jié)點，最終將超節(jié)點組成一個超大規(guī)模的網(wǎng)絡(luò)集群。這種堆疊的方式已經(jīng)發(fā)展到相當(dāng)復(fù)雜的程度。

此外，芯片層級的新技術(shù)不斷涌現(xiàn)，但發(fā)展速度卻遠(yuǎn)低于預(yù)期。例如，片上 SRAM（靜態(tài)隨機存取存儲器）、片內(nèi) HBM（高帶寬存儲器）的 IO 帶寬，以及芯片的光照面積限制等問題，都在制約著芯片技術(shù)的發(fā)展。這些技術(shù)的發(fā)展速度遠(yuǎn)沒有我們想象中那么快，尤其是在我國，掌握這些核心技術(shù)的難度仍然較大。除了芯片內(nèi)部的技術(shù)挑戰(zhàn)，片外、帶外以及跨節(jié)點的互聯(lián)技術(shù)，如微光互聯(lián)和光交換，也相對落后。盡管國內(nèi)有一些創(chuàng)新創(chuàng)業(yè)公司在嘗試突破，但這一領(lǐng)域?qū)儆谥刭Y本產(chǎn)業(yè)，尤其是硅光互聯(lián)和光交換技術(shù)。一旦通信數(shù)據(jù)量達到一定規(guī)模，光交換就會受到物理極限的約束。同時，scale-up（縱向擴展）與 scale-out（橫向擴展）、存內(nèi)計算與寄存計算之間的爭論也在不斷涌現(xiàn)。例如，面對內(nèi)存不足的問題，是否可以通過凈存計算來解決？是否可以將或 HBM 與計算更加緊密地結(jié)合？這些都成為當(dāng)前需要面對的新問題。

能耗問題也尤為突出。一些二級市場或一級市場的投資人曾問我，是否有必要投資能源公司的股票，或者關(guān)注新建智算中心的能耗占比。事實上，智算中心的能耗占比非常高。目前，我們的機房大多建在貴州、內(nèi)蒙古等地，利用自然冷源進行散熱，但風(fēng)冷已無法滿足需求，因此不得不轉(zhuǎn)向液冷技術(shù)，以降低溫度并減少能耗。然而，上述許多問題并非短時間內(nèi)能夠解決，但這并不意味著我們應(yīng)放棄努力。實際上，我們?nèi)杂性S多工作可以開展。

在這一領(lǐng)域，國內(nèi)外涌現(xiàn)出許多新的集群和云平臺公司。例如，國內(nèi)的阿里云、騰訊云、火山云、百度百舸，國際上的谷歌 TPU、亞馬遜 AWS，以及 Meta 等。華為也有自己的華為云，而昇騰則在很大程度上支撐了這些云服務(wù)和集群服務(wù)的運行。

基于這些現(xiàn)狀，我們看到 AI 集群的性能提升主要集中在芯片能力、集群能力、算力效率和可用率等方面。在算法層面，常見的優(yōu)化手段包括計算優(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)性并不強，顯得有些過于宏觀。今天，我主要想分享的是更深入、更具體、與昇騰或華為業(yè)務(wù)強相關(guān)的內(nèi)容。

集群組網(wǎng)優(yōu)化

參數(shù)面多軌組網(wǎng)

從百卡集群到千卡集群，再到萬卡集群，我們進行了架構(gòu)的逐步優(yōu)化。下圖右邊的圖例中 100G 網(wǎng)絡(luò)對應(yīng)的是 100Gbps 的通信帶寬；GE（Gigabit Ethernet）是普通的以太網(wǎng)通信，帶寬相對較低；10GE 是帶外通信。在日常操作中，我們通常通過公網(wǎng)、云專用網(wǎng)或 IP 承載網(wǎng)，經(jīng)由最外層的路由器接入整個集群。而集群內(nèi)部真正運行模型的部分是下圖中間的 AI 集群，存儲和計算集群是分開的。

因此我們產(chǎn)生了多個不同的業(yè)務(wù)面：參數(shù)面、業(yè)務(wù)面 / 數(shù)據(jù)面。參數(shù)面是指網(wǎng)絡(luò)模型參數(shù)傳遞的網(wǎng)絡(luò)。在一個萬卡集群中，用英偉達的卡， GPT-3 模型的 MFU（Model Flops Utilization，模型利用率）最高能達到 50%，大部分時間都在進行網(wǎng)絡(luò)通信，通信對我們來說已經(jīng)變得非常關(guān)鍵。當(dāng)時，參數(shù)面主要采用多軌主網(wǎng)架構(gòu)，參數(shù)面接入的是 100G 的 RoCE（RDMA over Converged Ethernet）網(wǎng)絡(luò)，這是一種典型的配置。數(shù)據(jù)面和業(yè)務(wù)面負(fù)責(zé)將存儲的圖片、文本以及對話數(shù)據(jù)等，通過存儲后端傳遞給計算面，即我們的 AI 集群。在參數(shù)面的早期階段，即 2020 年之前，當(dāng)時還沒有大規(guī)模推動千卡或萬卡集群時，我們的組網(wǎng)方案相對簡單。

參數(shù)面由多軌調(diào)整為單軌

集群組網(wǎng)，尤其是英偉達的萬卡組網(wǎng)，是在近兩年才逐漸興起的概念。在過去，很少有人提及萬卡集群或千卡集群。由于早期集群中沒有獨立的數(shù)據(jù)面，數(shù)據(jù)面與業(yè)務(wù)面合為一體，通常通過 NFS（Network File System，網(wǎng)絡(luò)文件系統(tǒng)）協(xié)議進行訪問。這種架構(gòu)存在潛在風(fēng)險，數(shù)據(jù)可能因訪問協(xié)議的開放性而外泄。這成為許多客戶極為關(guān)心的問題：購買集群后，數(shù)據(jù)應(yīng)如何得到有效保護？如果數(shù)據(jù)面與業(yè)務(wù)面沒有分離，且上層連接路由器，一旦接入路由器，網(wǎng)絡(luò)很容易受到攻擊，進而導(dǎo)致數(shù)據(jù)被訪問或泄露。

盡管目前在大模型訓(xùn)練中，數(shù)據(jù)安全問題尚未成為主要關(guān)注點，但對于許多 B 端企業(yè)，尤其是業(yè)務(wù)級公司來說，數(shù)據(jù)泄露風(fēng)險是他們極為重視的問題。在早期的百卡集群中，樣本面與業(yè)務(wù)面的網(wǎng)絡(luò)是共享的，組成了一個多軌的 100G RoCE 網(wǎng)絡(luò)。這種架構(gòu)會影響整個 IO 的讀取速率，因此我們對方案進行了升級。

在千卡集群階段，我們不能再沿用早期的架構(gòu)。經(jīng)過深入研究并與眾多客戶交流后，我們將數(shù)據(jù)面從整體架構(gòu)中分離出來。在 AI 集群中，我們從多軌方案轉(zhuǎn)變?yōu)閱诬壏桨?。多軌方案存在一個較為致命的問題：維護成本極高。雖然它可以連接多個二級交換機，使集群規(guī)模更大，但維護成本的增加會導(dǎo)致可用性下降。尤其是在千卡集群中，我們希望集群能夠隨時啟動，避免像萬卡集群那樣頻繁出現(xiàn)錯誤、掉卡或網(wǎng)絡(luò)中斷等問題，包括光模塊故障等。

因此，我們將參數(shù)面從多軌調(diào)整為單軌，并將網(wǎng)絡(luò)帶寬從 100G RoCE 升級到 200G RoCE，從而提升了參數(shù)面的整體性能。提升參數(shù)面性能的目的是為了提高節(jié)點之間的通信效率，最終實現(xiàn)參數(shù)面與數(shù)據(jù)面（即業(yè)務(wù)面）的分離，并將 NFS 協(xié)議改為 DPC（Direct Parallel Communication，直接并行通信）協(xié)議進行訪問。

目前，一些廠商可能會將數(shù)據(jù)直接存儲在 AI 集群的每個節(jié)點中，但這種方式對數(shù)據(jù)的維護和管理帶來了極大挑戰(zhàn)，尤其是對于 CKPT（Checkpoint，檢查點）數(shù)據(jù)。在實際業(yè)務(wù)上線時，可能會存在多個分散的 AI 集群，因此配備一個集中的存儲端口是非常必要的，尤其是面向未來的推理集群。如今，我們的整體架構(gòu)包括一個訓(xùn)練集群、一個獨立的存儲區(qū)域以及一個管理區(qū)域，分別用于管理帶內(nèi)和帶外網(wǎng)絡(luò)。通過這種方式，我們將之前提到的問題進行了有效隔離，盡可能確保整個網(wǎng)絡(luò)和網(wǎng)段的安全性，同時實現(xiàn)了數(shù)據(jù)與業(yè)務(wù)的分離。

提高計算側(cè)數(shù)據(jù)面接入網(wǎng)卡速率

我們正在進行架構(gòu)演進，以應(yīng)對對萬卡集群甚至更大規(guī)模的方案。隨著大模型的興起，尤其是強化學(xué)習(xí)的廣泛應(yīng)用，數(shù)據(jù)源源不斷地從存儲集群流向 AI 集群，甚至推理集群。在推理業(yè)務(wù)中，數(shù)據(jù)持續(xù)產(chǎn)生，因此我們需要減少 AI 集群與存儲區(qū)之間的數(shù)據(jù)傳輸延遲，盡可能拉近它們之間的距離。為此，我們制定了新的方案，適用于萬卡集群以及未來的 Post-Training（后訓(xùn)練）和推理業(yè)務(wù)場景。在這一方案中，我們將計算面的網(wǎng)絡(luò)從 2×25G 升級為 2×100G 的 RoCE 網(wǎng)絡(luò)。整體網(wǎng)絡(luò)架構(gòu)中，綠色的連接線已發(fā)生變化，全部采用 DPC（Direct Parallel Communication）協(xié)議進行訪問。最重要的是，我們再次分離了樣本面與業(yè)務(wù)面，目前仍采用單軌方案，服務(wù)器到 Leaf（葉節(jié)點）之間采用二分之一的線纜連接。這種設(shè)計的核心目標(biāo)是提升網(wǎng)絡(luò)性能，盡可能減少等待時間。

針對萬卡集群的維護難題，我們優(yōu)化了方案。萬卡集群的維護極為復(fù)雜，一旦有一張卡掉線，可能會影響整個萬卡集群的大模型訓(xùn)練。因此，我們通過減少維護工作量，提高集群的整體可用性。此外，訓(xùn)練區(qū)采用了全液冷方案，參數(shù)面和業(yè)務(wù)面被進一步分離，整體線路更加清晰，便于維護。同時，存儲區(qū)和管理區(qū)也進行了新的業(yè)務(wù)隔離，以更好地支持萬卡集群的運維需求。

從百卡方案到千卡方案，再到萬卡集群方案，我們在做的事情可能用戶難以感知，但對于從事底層系統(tǒng)工作的人來說，這些內(nèi)容極為核心且備受關(guān)注。性能的優(yōu)劣并非僅僅取決于并行策略的先進性，更在于網(wǎng)絡(luò)如何組網(wǎng)，以及并行策略如何根據(jù)組網(wǎng)方案進行優(yōu)化。在使用英偉達集群時，用戶會發(fā)現(xiàn)其提供了成熟的 TPPP（Tensor Parallelism、Pipeline Parallelism 等）切分方案，大家通常會按照這一方案進行并行計算。然而，當(dāng)面對新的集群，尤其是國產(chǎn)集群或不同網(wǎng)絡(luò)架構(gòu)的集群時，切分方式和并行方式會有所不同。因此，若想真正做好這一領(lǐng)域，實現(xiàn)性能的最優(yōu)，就必須深入到底層進行探索。

多模態(tài)性能優(yōu)化

SORA 多模態(tài)

在多模態(tài)場景中，以我們近期支持的 SORA 大模型為例，該模型自 2 月中旬推出以來，國內(nèi)已有眾多公司在開展圖文生成和視頻生成的相關(guān)工作。在視頻生成任務(wù)中，大規(guī)模集群的應(yīng)用必不可少。然而，大規(guī)模集群不僅成本高昂，還面臨諸多問題。首先，面向新的業(yè)務(wù)場景時，不再是像 LLM 那樣可以直接使用。例如，SORA 并未公開代碼，用戶需要自行編寫或運行代碼。如果代碼無法運行，那么大量計算資源（如萬卡集群）將被閑置浪費。即使集群處于通電狀態(tài)但未運行任何業(yè)務(wù)，也是一種巨大的浪費。如果代碼運行出錯，同樣意味著計算資源的浪費。因此，我們希望在按下回車鍵的那一刻，所有配置都是正確的，能夠在兩個月內(nèi)成功訓(xùn)練出一個文生視頻的大模型。

我們在 SORA 多模態(tài)業(yè)務(wù)中究竟做了哪些工作呢？首先，我們會分析網(wǎng)絡(luò)模型或業(yè)務(wù)場景對每一層的挑戰(zhàn)。客戶最關(guān)心的往往是軟件層面的挑戰(zhàn)，因為軟件與客戶的算法和業(yè)務(wù)緊密相關(guān)。其次，我們也會關(guān)注芯片層面的挑戰(zhàn)，而生態(tài)和算法層面雖然也很重要，但并非我們最關(guān)注的點。從性能角度來看，我們目前如何基于千卡規(guī)模訓(xùn)練一個文生圖模型，因為文生視頻模型本質(zhì)上仍源于文生圖模型。我們會分析文生圖模型的業(yè)務(wù)痛點和問題。例如，batch size（批量大?。粫貏e大，是否容易出現(xiàn) host bonding（下發(fā)瓶頸）問題。由于圖片是一張張?zhí)幚淼?，即使設(shè)置了 batch size，將多張圖片打包下發(fā)時，很容易形成瓶頸。此外，在文生圖和文生視頻的訓(xùn)練中，我們不是像大語言模型那樣一次性處理所有圖片和文字，而是多次處理所有數(shù)據(jù)或圖片，這相當(dāng)于多次訓(xùn)練 RoPE（Rotary Position Embedding）。接著，我們會處理不同分辨率的負(fù)載問題。在訓(xùn)練視頻或圖片大模型時，數(shù)據(jù)分辨率的差異較大，有些圖片大，有些圖片小。如果將圖片尺寸固定為某一規(guī)格，生成結(jié)果的靈活性將大打折扣。此外，我們還會研究分布式推理、稀疏場景以及下采樣策略等，深入剖析每一個算法細(xì)節(jié)，以提升性能。

在內(nèi)存方面，國產(chǎn)芯片的內(nèi)存規(guī)格與英偉達的有所不同。英偉達的 A100 芯片內(nèi)存為 80GB，H100 為 96GB，甚至還有高配版 164GB，但國產(chǎn)芯片由于 HBM（High Bandwidth Memory，高帶寬存儲器）供應(yīng)問題（HBM 主要依賴國外供應(yīng)，國內(nèi)產(chǎn)量較低），其內(nèi)存規(guī)格與英偉達不同。由于供應(yīng)鏈問題導(dǎo)致內(nèi)存大小的差異，我們可能需要采用不同的內(nèi)存優(yōu)化方案、切分方式，以及在每張卡上運行的小模型或參數(shù)的大小也會有所不同。因此，我們需要深入研究內(nèi)存優(yōu)化策略。此外，精度問題也極為復(fù)雜。它可能涉及硬件問題、用戶代碼問題，甚至可能是訓(xùn)練技巧不足。目前，真正掌握大模型訓(xùn)練技巧的人才極為稀缺，每個人在運行萬卡大模型時，一旦按下回車鍵，模型運行失敗，往往會懷疑是硬件不行，而不會首先考慮是算法問題。因此，精度問題也是我們研究的重點之一。

性能瓶頸分析

對于 3D Attention 來說，當(dāng)圖片或視頻的分辨率提升 n 倍時，序列長度和動態(tài)內(nèi)存的使用量會變?yōu)樵瓉淼?n2 倍，而 Attention 計算的開銷則會增加到 n? 倍。這是因為圖片和視頻的維度包括長、寬、高以及時間序列，整體計算開銷非常大。此外，視頻的變化也會導(dǎo)致整體計算開銷顯著增加。

在 3D Attention 的應(yīng)用場景中，例如生成紋身視頻時，序列長度可以達到百 k 級別。大部分計算集中在 Fresh Attention 這一算子上，因此我們可以進行整體分析。在下圖的左側(cè)，我們將每一幀及其對應(yīng)的 Fashion Attention 的 Ship 提取出來，并分析整個 MPU 的耗時，以及每次計算所使用的內(nèi)存或顯存。而在右側(cè)的細(xì)節(jié)圖中，我們進一步深入分析在每一微秒、每一毫秒內(nèi)需要執(zhí)行的具體計算內(nèi)容。

整體來看，3D Attention 對性能和內(nèi)存的挑戰(zhàn)極大。目前，單步迭代時間已達到 170 秒，這意味著僅完成一次迭代就需要如此長的時間。因此，除了前面提到的優(yōu)化措施外，我們還需要引入序列并行或改進模型結(jié)構(gòu)，以進一步提升性能。

訓(xùn)練 DeepSpeed 精度問題

精度問題。最初，我們與北京大學(xué)的兔展智能合作，參與了 Open SORA Plan 這一開源項目。當(dāng)時，該項目使用的是 DeepSpeed 框架，即微軟的分布式訓(xùn)練框架。然而，我們在使用過程中發(fā)現(xiàn)該框架存在一些問題，尤其是在算子層面。因此，我們決定不再使用 DeepSpeed 框架。在萬卡集群的訓(xùn)練場景下，我們無法確切判斷每一個中間件是否存在潛在問題。DeepSpeed 是微軟開發(fā)的，但業(yè)界尚未有在萬卡集群上運行的成功案例。如果出現(xiàn)問題，很難判斷是微軟框架的問題還是硬件本身的問題。因此，我們最終放棄了 DeepSpeed，轉(zhuǎn)而使用 PyTorch 的分布式數(shù)據(jù)并行 DDP 進行訓(xùn)練。結(jié)果發(fā)現(xiàn)，使用 PyTorch DDP 時精度表現(xiàn)正常，而使用 DeepSpeed 時則會出現(xiàn)精度問題。

在 DeepSpeed 框架下，我們還發(fā)現(xiàn)了一個有趣的現(xiàn)象：當(dāng)使用 4GB 的混合精度訓(xùn)練時，loss（損失值）表現(xiàn)正常；但當(dāng)擴展到 8GB 訓(xùn)練時，loss 會異常。我們當(dāng)時對這一問題進行了深入研究。在 DeepSpeed 的框架下，我們嘗試通過梯度累積的方式模擬大 batch size 的訓(xùn)練，此時 loss 仍然表現(xiàn)正常。然而，在實際運行大模型時，情況并非如此簡單。

為了避免潛在問題，我們會在小規(guī)模參數(shù)下進行“演習(xí)”，例如將一個 100B 參數(shù)的模型縮減為 10B 參數(shù)，在小規(guī)模集群中進行簡單驗證。通過這種方式，我們能夠排除許多與算法或超參數(shù)相關(guān)的影響。在 DeepSpeed 框架中，我們發(fā)現(xiàn)精度問題主要源于 all_gather 算子。因此，我們對 DeepSpeed 框架進行了一些修改和優(yōu)化，并將這些代碼貢獻給了 DeepSpeed 社區(qū)。此外，我們還更新了底層算子庫，解決了 DeepSpeed Zero-1 和 Zero-2 的一些精度問題。

對內(nèi)存的優(yōu)化

我們看一下內(nèi)存性能和精度優(yōu)化的相關(guān)案例。實際上，在進入 DIT（Diffusion-based Inference and Training，基于擴散模型的推理與訓(xùn)練）領(lǐng)域后，盡管 Meta 最近發(fā)布的文章指出，使用 DIT 進行推理或生成時，其整體耗時可能會受到影響，因此目前許多互聯(lián)網(wǎng)廠商和合作伙伴又開始轉(zhuǎn)向使用自回歸方法進行文生視頻任務(wù)。然而，在使用 DIT 的過程中，整個流程會涉及視頻數(shù)據(jù)處理、分辨率變換、VAE 編碼、文本編碼以及編解碼問題。如果考慮到不同分辨率，目前多種分辨率會導(dǎo)致不同的 batch 預(yù)處理開銷，而每個 batch 的開銷不同又會導(dǎo)致 host 負(fù)載不均衡，進而影響整體訓(xùn)練性能，表現(xiàn)為訓(xùn)練性能的抖動。

那么，這種抖動究竟是由硬件還是軟件引起的呢？經(jīng)過分析，我們最終發(fā)現(xiàn)這是由算法原因?qū)е碌?。因此，我們總結(jié)出文生視頻的三個典型特點：

1. 數(shù)據(jù)預(yù)處理是一個重負(fù)載；

1. 數(shù)據(jù)通常需要訓(xùn)練多個 Epoch；

1. 訓(xùn)練步數(shù)（200k-1000k）更重要，Batch Size 不那么重要。

針對上述三個問題，我們采用了數(shù)據(jù)預(yù)處理方案。在 EPOCH 0（第 0 輪訓(xùn)練）時，我們保存 VAE 編碼和文本編碼的結(jié)果，盡可能多地將這些中間結(jié)果存儲下來。從第二輪訓(xùn)練（EPOCH 1）開始，不再重新計算整體編碼，從而減少 host 的計算開銷，并充分發(fā)揮存儲系統(tǒng)的性能優(yōu)勢。這一優(yōu)化方案也與我們之前提到的參數(shù)面與業(yè)務(wù)面分離、提升計算集群與存儲集群網(wǎng)絡(luò)性能等內(nèi)容密切相關(guān)。由于集群組網(wǎng)方案的變更，我們引入了新的加速手段。

解決內(nèi)存不足問題

在當(dāng)前的 NPU 架構(gòu)中，為了應(yīng)對內(nèi)存不足的問題并提升性能，引入了序列并行技術(shù)，尤其是在處理類似 SORA 這種復(fù)雜模型時顯得尤為重要。與傳統(tǒng)的 LLM 相比，SORA 的序列并行更為復(fù)雜，主要面臨以下三大挑戰(zhàn)：

1. 訓(xùn)練模式復(fù)雜：Sora 的訓(xùn)練同時涉及圖片和視頻數(shù)據(jù)，其中圖片不參與序列并行（SP），而視頻數(shù)據(jù)則參與 SP 并行。這種差異導(dǎo)致在并行策略設(shè)計上需要針對不同類型的數(shù)據(jù)進行區(qū)分處理。

1. 時空 Attention 機制復(fù)雜：Sora 模型包含時空 Attention 機制，其空間 Transformer 層中，Batch 維度對應(yīng)時間，序列維度對應(yīng)空間；而時間 Transformer 層中，Batch 維度對應(yīng)空間，序列維度對應(yīng)時間。序列并行僅針對時間 Transformer 層進行處理，且在并行過程中，Tensor 的布局會在 BSH（Batch, Sequence, Hidden）和 SBH（Sequence, Batch, Hidden）之間交替變換，以適應(yīng) All2All 通信的需求。

1. 輸入數(shù)據(jù)多且復(fù)雜：Sora 基于 Text2Video，屬于多模態(tài)模型，輸入數(shù)據(jù)包括 Timestep（用于擴散模型）、文本編碼（用于 Cross Attention）、視頻 Mask 和文本 Mask 等。由于序列并行需要對所有輸入數(shù)據(jù)進行 All2All 處理，以確保計算的正確性，這進一步增加了并行策略的復(fù)雜性。

解決 Attention 計算復(fù)雜度高問題

在算法層面，我們不僅進行了諸多工程性的細(xì)粒度優(yōu)化，還提出了一種稀疏注意力（Sparse Attention）機制，以解決傳統(tǒng)注意力機制計算復(fù)雜度較高的問題。這一機制與傳統(tǒng)方法有所不同，是我們與華為諾亞研究院（2012 實驗室）合作探索的新算法方向。具體實現(xiàn)分為三個階段：

第一階段：聚類

在注意力模塊中，$\text{Softmax}\left(\frac{QK^T}{\text{Scale}}\right)$ 權(quán)重矩陣的每個 Token $Q _ i$ 與向量 _K_ 的相似度呈現(xiàn)出一定的規(guī)律性?；谶@種規(guī)律性，可以將相似度分布相近的 Token $Q _ i$ 進行聚類，聚類結(jié)果如圖 3 所示。

第二階段：重排計算

對第一階段得到的聚類結(jié)果，每行按照相似度大小由高到低進行排序。由于每份聚類結(jié)果 $CQ ^ i$ 中的每個 Token 與向量 _K_ 的相似度分布相近，可以設(shè)置一個固定閾值 _?_，對相似度小于 _?_ 的 Token $K _ i$ 進行過濾。因此，每份 $CQ ^ i$ 都將對應(yīng)得到一個更小的矩陣 $CK ^ i$。隨后，對重排后的矩陣 $CQ ^ i$ 和 $CK ^ i$ 進行計算，得到權(quán)重矩陣的子結(jié)果（如圖 4 紅色框內(nèi)部分所示）。整體計算性能的提升與矩陣 $CK ^ i$ 的序列縮短長度成正比。

第三階段：補齊還原

將第二階段得到的子結(jié)果按照向量 _K_ 的長度進行補齊（補齊值為 0），然后重排還原。最后，將所有子結(jié)果拼接，得到完整的權(quán)重矩陣計算結(jié)果。

通過這一系列操作，我們主要目的是去除大量冗余的、無關(guān)緊要的計算。計算量的減少自然也會導(dǎo)致數(shù)據(jù)量的降低，進而減少存儲需求。存儲需求的降低進一步提升了訓(xùn)練性能，因為芯片內(nèi)部的數(shù)據(jù)搬運過程是按照微秒級別進行的：數(shù)據(jù)從存儲單元搬運到計算核心，計算完成后又在微秒級別內(nèi)搬運回存儲單元。這一過程非常耗時，因此通過減少計算和存儲需求，整體性能得到了顯著提升。

小紅書案例

在支撐多模態(tài)場景的工作中，我們進行了一些基礎(chǔ)但關(guān)鍵的 Infra（基礎(chǔ)設(shè)施）層面的優(yōu)化。華為在這方面的工作與其他公司有所不同，我們專注于分析業(yè)務(wù)需求，抽象出可以提升性能的關(guān)鍵點，特別是在計算、內(nèi)存以及路由通信網(wǎng)絡(luò)等方面。在在這個小紅書案例中使用了華為云服務(wù)。由于華為云的組網(wǎng)方案已經(jīng)確定并構(gòu)建完成，因此我們不再需要考慮組網(wǎng)方案的演進，而是在一個已經(jīng)達到次優(yōu)狀態(tài)的云環(huán)境中工作。

在處理大模型時，我們面臨的主要任務(wù)是提升性能。許多基礎(chǔ)問題已經(jīng)得到解決，因此我們轉(zhuǎn)而分析可以進一步優(yōu)化的方案。我們對算子通信、算法等方面進行了深入分析，并收集了性能分析數(shù)據(jù)。通過對比 GPU 和 NPU 的性能分析，我們確定了性能瓶頸和通信耗時的阻塞點，以及計算耗時的具體位置。

經(jīng)過分析，我們識別出了所有可以提升性能的關(guān)鍵點。對于耗時過長的算子，我們進行了等價替換。例如，我們發(fā)現(xiàn) reduce getter 算子實際上是由 all reduce 和 all getter 兩個算子組合而成的，可以將其視為一個通信算子。此外，All2All 通信也可以通過點對點通信的組合來實現(xiàn)，這是一種等價替換。

我們還充分利用了 AI Core 的能力。華為的芯片以及國內(nèi)其他芯片廠商的產(chǎn)品與英偉達的 GPU 有所不同，后者擁有大量的 CUDA Core 和 Tensor Core。而我們的芯片擁有專門的 AI Core，這是華為芯片的最大特點之一。我們盡可能地將算力集中在 AI Core 上。此外，我們還采用了空間換時間的策略，以及多融合算子或自定義融合算子進行優(yōu)化。最后，我們還進行了通信優(yōu)化，進一步提升了系統(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)時的工作重心集中在分布式并行上。因此，我主導(dǎo)開發(fā)了一個名為“AscendSpeed”、現(xiàn)在稱為“MindSpeed”的框架，專門用于性能優(yōu)化。

除了分布式并行策略，我們還需要在單個芯片上運行一些大型融合算子，例如 Fetch Attention。這種算子在小規(guī)模集群中能夠顯著提升性能，甚至可能達到兩倍的提升效果。此外，我們還需要研究集合通信算法各種 NCCL 庫，以及環(huán)回算法。內(nèi)存優(yōu)化算法也是我們研究的重點。

大多數(shù)人可能會認(rèn)為，在萬卡集群中提升性能只需關(guān)注上述這些方面。但實際上，萬卡集群的構(gòu)成遠(yuǎn)比這復(fù)雜。例如，光模塊的功率、溫度、連通性以及信噪比等各種各樣的因素都會影響集群的性能。在真正的基礎(chǔ)設(shè)施層面，尤其是在底層基礎(chǔ)設(shè)施層面，我們的工作往往并不那么“高大上”，很多時候更像是在從事體力勞動。

以我 2024 年 6 月份在集群機房的兩周經(jīng)歷為例，我在那里就是為了解決這些基礎(chǔ)設(shè)施層面的問題。這些問題雖然看似瑣碎，但卻對集群的整體性能有著至關(guān)重要的影響。因此，我們的工作不僅僅是研究和應(yīng)用先進的并行策略，還包括了對基礎(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)播放量超千萬。

會議推薦

在 AI 大模型重塑軟件開發(fā)的時代，我們?nèi)绾伟盐兆兏?？如何突破技術(shù)邊界？4 月 10-12 日，QCon 全球軟件開發(fā)大會· 北京站 邀你共赴 3 天沉浸式學(xué)習(xí)之約，跳出「技術(shù)繭房」，探索前沿科技的無限可能。

本次大會將匯聚頂尖技術(shù)專家、創(chuàng)新實踐者，共同探討多行業(yè) AI 落地應(yīng)用，分享一手實踐經(jīng)驗，深度參與 DeepSeek 主題圓桌，洞見未來趨勢。