國產(chǎn)GPU重大利好！“中國英偉達(dá)”千卡集群已就位

十三 2024-04-28 18:51:14 來源：量子位

金磊 發(fā)自 凹非寺

量子位 | 公眾號 QbitAI

算力基礎(chǔ)設(shè)施建設(shè)，北京市有了最新的大動作——

《北京市算力基礎(chǔ)設(shè)施建設(shè)實(shí)施方案（2024-2027年）》。

其中，《方案》在“保障措施”中提出了對企業(yè)利好的辦法：

• 對采購自主可控GPU芯片開展智能算力服務(wù)的企業(yè)，按照投資額的一定比例給予支持，加速實(shí)現(xiàn)智算資源供給自主可控。
• 對主動進(jìn)行綠色節(jié)能改造的存量數(shù)據(jù)中心，按照投資額的一定比例給予支持。

對企業(yè)擴(kuò)大資金的舉措，意在提升人工智能算力券政策效能，鼓勵企業(yè)用好智能算力資源，加快推動大模型賦能行業(yè)應(yīng)用。

除此之外，在《方案》的規(guī)劃目標(biāo)中，也釋放出了一個重要的信號——智算資源供給集群化：

改變智算建設(shè)“小、散”局面，集中建設(shè)一批智算單一大集群。

到2025年，本市智算供給規(guī)模達(dá)到45EFLOPS，2025-2027年根據(jù)人工智能大模型發(fā)展需要和國家相關(guān)部署進(jìn)一步優(yōu)化算力布局。

為何會如此？這就要結(jié)合當(dāng)下算力市場的需求和供給展開來看了。

一方面，自從ChatGPT問世引爆AIGC以來，大模型的數(shù)量可謂是極速增長，單是北京這一座城市，就已經(jīng)擁有122家大模型創(chuàng)新團(tuán)隊(duì)，約占全國的一半，大模型數(shù)量更是居全國首位。對于算力市場的需求之大可見一斑。

不僅如此，隨著Sora、Suno等應(yīng)用的問世，大模型的發(fā)展已然加速駛?cè)?strong>多模態(tài)階段，AI算力的需求在Scaling Law為主旋律的當(dāng)下還會持續(xù)上漲。

△圖源：由DALL·E 3生成

另一方面，AIGC誠然帶火了“N卡”，但目前著眼于全球已然是一卡難求的態(tài)勢，并且因稀缺導(dǎo)致其價(jià)格日益水漲船高。

而且單從GPU的性能角度來看，即便是英偉達(dá)也只能接受加速計(jì)算到達(dá)了臨界點(diǎn)的事實(shí)，算力供給方需要另一種方式來進(jìn)行計(jì)算——

通過芯片與芯片間的連接技術(shù)，一步步構(gòu)建出大型AI大規(guī)模算力集群。

聚焦到國內(nèi)，其實(shí)這種“集群”模式也已經(jīng)緊鑼密鼓地在展開，國內(nèi)已有不少廠商在不斷探索和實(shí)踐，例如云計(jì)算巨頭華為云、AI芯片公司摩爾線程等等。

以摩爾線程為例，就在前不久他們發(fā)布了名為夸娥（KUAE）的智算集群解決方案，旨在以一體化交付的方式解決大規(guī)模GPU算力的建設(shè)和運(yùn)營管理問題，可以大幅降低傳統(tǒng)算力建設(shè)、應(yīng)用開發(fā)和運(yùn)維運(yùn)營平臺搭建的時間成本。

從這一點(diǎn)來看，國內(nèi)市場算力的發(fā)展是與《方案》所提出的“智算資源供給集群化”是相契合的，也從側(cè)面印證著國產(chǎn)GPU智算集群已經(jīng)到了勢在必行的階段。

然而，路線雖已清晰，但在實(shí)踐過程當(dāng)中，尤其是GPU數(shù)量達(dá)到千卡甚至萬卡時，集群落地并非是件易事。

那么難點(diǎn)都有什么？國產(chǎn)GPU又是如何應(yīng)對的？我們繼續(xù)往下看。

千卡GPU集群落地痛點(diǎn)

首先我們需要了解GPU集群在實(shí)際落地過程中的規(guī)模會達(dá)到什么量級。

以Llama 3為例，在它問世之際，Meta就公布了其基礎(chǔ)設(shè)施詳情：

我們在兩個定制的24K GPU集群上做訓(xùn)練。

與之類似的，馬斯克的Grok 2據(jù)悉訓(xùn)練已經(jīng)用了20000張H100，Grok 3更是傳出需要驚人的100000張；即使是參數(shù)量僅為30億的Sora，GPU的數(shù)量也估算在4200至10500張之間。

而事實(shí)上，當(dāng)下要滿足一些基礎(chǔ)模型的算力需求，千卡集群已然是標(biāo)配一樣的存在；這不僅僅是因?yàn)榍Эㄊ谴蠹旱幕締卧且驗(yàn)榘倏ɑ蚋∫?guī)模的GPU數(shù)量往往滿足不了大模型訓(xùn)練需求，只能是實(shí)驗(yàn)性的。

但智算集群中GPU的數(shù)量也還只是一方面，之于GPU本身，在諸如訓(xùn)練大模型等落地過程中的難點(diǎn)也是不少。

因?yàn)榻ㄔO(shè)集群本身還是一個非常復(fù)雜的系統(tǒng)性工程，它不僅是堆GPU這么簡單，從一個GPU到一個服務(wù)器，再到把它們組成群，期間包含了硬件的網(wǎng)絡(luò)、存儲、軟件、再到大模型調(diào)度等各種細(xì)節(jié)因素，均會影響到集群的最終性能。

例如同樣是Llama 3，Meta在介紹基礎(chǔ)設(shè)施的時候還提到了一個關(guān)鍵信息：

當(dāng)在16K GPU上同時訓(xùn)練時，我們有效地實(shí)現(xiàn)了每個GPU超過400 TFLOPS的計(jì)算利用率。

若是每張卡的利率用不夠高，很顯然就會降低最終智算集群的效率。

再如分布式訓(xùn)練過程中，一張卡壞掉就會影響整體的訓(xùn)練，對于千卡甚至更大規(guī)模的集群來說，這種情況出現(xiàn)的概率就會更高；因此對于千卡集群的穩(wěn)定性和可靠性也提出了極高的要求。

聚焦到國產(chǎn)智算集群，還需得具備可以兼容主流GPU軟件的能力（例如CUDA），由此才能應(yīng)對更多且日新月異的主流大模型任務(wù)。

……

一言蔽之，構(gòu)建千卡智算集群難，構(gòu)建國產(chǎn)千卡智算集群難上加難。

如何破局？

雖說困境重重，但也正如上文所言，摩爾線程已經(jīng)在探索與實(shí)踐，并且他們在構(gòu)建千卡智算集群這件事上也已交出了“高分作業(yè)”。

我們不妨以摩爾線程的夸娥（KUAE）智算中心解決方案為例，來看下構(gòu)建國產(chǎn)GPU智算集群的破局之道。

整體來看，夸娥（KUAE）智算中心解決方案是一個以全功能GPU為底座，軟硬件一體化的全棧的解決方案。

之所以叫做全棧，是因?yàn)榭涠鸬哪芰κ怯|及到了構(gòu)建GPU智算集群中的方方面面，包括最底層的基礎(chǔ)設(shè)施建設(shè)、中間層的智算集群管理，以及上層的大模型服務(wù)。

首先來看基礎(chǔ)設(shè)施。

從內(nèi)容上來看主要包含夸娥（KUAE）計(jì)算集群、RDMA網(wǎng)絡(luò)與分布式存儲三大方面。據(jù)了解，其建設(shè)周期只需30天，可支持千億參數(shù)模型的預(yù)訓(xùn)練、微調(diào)和推理，可實(shí)現(xiàn)高達(dá)91%的千卡集群性能擴(kuò)展系數(shù)。

并且基于大規(guī)模智算加速卡MTT S4000和雙路8卡GPU服務(wù)器MCCX D800的能力，夸娥集群還支持從單機(jī)多卡到多機(jī)多卡，從單卡到千卡集群的無縫擴(kuò)展。

據(jù)悉未來將推出更大規(guī)模的集群，以滿足更大規(guī)模的大模型訓(xùn)練需求。

其次是集群管理平臺。

這一軟硬件一體化平臺主要是用于AI大模型訓(xùn)練、分布式圖形渲染、流媒體處理和科學(xué)計(jì)算等工作，深度集成全功能GPU計(jì)算、網(wǎng)絡(luò)和存儲，提供高可靠、高算力服務(wù)。

通過這個平臺，用戶可靈活管理多數(shù)據(jù)中心、多集群算力資源，集成多維度運(yùn)維監(jiān)控、告警和日志系統(tǒng)，幫助智算中心實(shí)現(xiàn)運(yùn)維自動化。

最后是模型服務(wù)。

覆蓋了大模型預(yù)訓(xùn)練、微調(diào)和推理全流程，支持所有主流開源大模型。通過摩爾線程MUSIFY開發(fā)工具，可以輕松復(fù)用CUDA應(yīng)用生態(tài)，內(nèi)置的容器化解決方案，則可實(shí)現(xiàn)API一鍵部署。

這個平臺意在提供大模型生命周期管理，通過簡潔、易操作的交互界面，用戶可按需組織工作流，大幅降低大模型的使用門檻。

那么實(shí)際效果如何？

據(jù)了解，摩爾線程目前已經(jīng)支持了包括LLaMA、GLM、Aquila、Baichuan、GPT、Bloom、玉言等在內(nèi)的各類主流大模型的訓(xùn)練和微調(diào)：

• 以200B訓(xùn)練數(shù)據(jù)量為例，智源研究院70B參數(shù)Aquila2可在33天完成訓(xùn)練
• 1300億參數(shù)規(guī)模的模型可在56天完成訓(xùn)練

至于剛才提到的千卡GPU集群落地難的種種細(xì)節(jié)，摩爾線程也有自己的應(yīng)對策略。

例如在提高集群算力利用率這件事上，摩爾線程采用軟硬件協(xié)同設(shè)計(jì)和端到端的并行策略，通過對集群通信庫的算法、網(wǎng)絡(luò)拓?fù)浜陀布囊?guī)格進(jìn)行精心設(shè)計(jì)與配置，實(shí)現(xiàn)了高度的集群兼容性。

具體到技術(shù)，則是綜合利用了MTLink和PCIe，使得通訊性能提升一倍，綜合調(diào)優(yōu)下MFU提升幅度超過50%。

在穩(wěn)定性方面，摩爾線程在根兒上先保證GPU的質(zhì)量，從卡出廠開始便進(jìn)行多項(xiàng)嚴(yán)格的檢測。

其后，摩爾線程還開發(fā)了集群系統(tǒng)監(jiān)控和診斷工具，有助于篩選和快速定位到有問題的卡和服務(wù)器，可以自動恢復(fù)和硬件替換。

并且結(jié)合異步檢查點(diǎn)（Checkpoint）加速，寫的時間從10分鐘降到秒級，讀的速度從40分鐘降到2分鐘；即使是遇到訓(xùn)練異常，系統(tǒng)也可以自動重新拉起。

在可擴(kuò)展性方面，夸娥目前已經(jīng)支持了包括DeepSpeed、Megatron-DeepSpeed、Colossal-AI、FlagScale在內(nèi)的業(yè)界主流分布式框架。

除此之外，還融合了多種并行算法策略，包括數(shù)據(jù)并行、張量并行、流水線并行和ZeRO，且針對高效通信計(jì)算并行和Flash Attention做了額外優(yōu)化。

最后，在兼容性方面，摩爾線程代碼移植Musify工具，可快速將現(xiàn)有的主流遷移至MUSA，零成本完成CUDA代碼自動移植。

借助摩爾線程元計(jì)算統(tǒng)一系統(tǒng)架構(gòu)MUSA，用戶還可以復(fù)用PyTorch開源社區(qū)的大量模型算子，降低開發(fā)成本。

整體而言，摩爾線程的夸娥智算集群全棧方案的優(yōu)勢可以歸結(jié)為八點(diǎn)，即：覆蓋主流大模型、兼容CUDA等主流生態(tài)、斷點(diǎn)續(xù)訓(xùn)、大語言模型分布式訓(xùn)練、加速推理、高性能通信、高性能存儲，以及高可靠性。

它就像把所有復(fù)雜的方案打包成了一把鑰匙，交付到用戶手上開箱即用。

而且摩爾線程的夸娥（KUAE）智算集群解決方案不只是說說那么簡單，是已經(jīng)做到了上崗。

據(jù)了解，夸娥目前已經(jīng)完成了三個千卡智算集群的落地，分別位于北京亦莊、北京密云和南京。

不僅如此，摩爾線程仍在持續(xù)譜寫著“打造國產(chǎn)GPU集群”的篇章。

就在前不久，摩爾線程與清華系創(chuàng)業(yè)公司無問芯穹達(dá)成合作，成為第一家接入無問芯穹并成功完成千卡級別大模型訓(xùn)練的國產(chǎn)GPU公司。雙方聯(lián)合推進(jìn)基于夸娥（KUAE）千卡智算集群的“MT-infini-3B”合作大模型實(shí)訓(xùn)，目前性能已在同規(guī)模模型中躋身前列。

并且無問芯穹CEO公開肯定了夸娥（KUAE）的實(shí)力：

經(jīng)驗(yàn)證，摩爾線程夸娥千卡智算集群在性能、穩(wěn)定性、易用性和算力利用率上均有優(yōu)異表現(xiàn)，可以為千億參數(shù)級別大模型訓(xùn)練提供持續(xù)高效的高性能算力支持。

由此可見，摩爾線程的夸娥千卡智算集群是得到了實(shí)踐驗(yàn)證的那種，那么最后一個問題便是：為什么是摩爾線程能率先落地？

其實(shí)早在2022年的時候，團(tuán)隊(duì)便已經(jīng)設(shè)定了建集群的大方向與策略，這是因?yàn)楫?dāng)時A100算力也是處于緊缺的狀態(tài)，國內(nèi)市場急需能夠替代它的產(chǎn)品。

從GPU功能情況來看，摩爾線程是在唯一可以對標(biāo)英偉達(dá)的國產(chǎn)GPU企業(yè)，雖然單芯片性能還有差距，但若是集成起來便可解決單一性的不足。

而隨著2023年大模型的火爆，這種GPU集群式的方向就顯得更加正確，畢竟黃仁勛在發(fā)布B200之際就表示“我們需要更大的GPU，如果不能更大，就把更多GPU組合在一起，變成更大的虛擬GPU”。

因此，現(xiàn)在回頭再看摩爾線程當(dāng)時的策略和決定，確實(shí)是具備前瞻性的。

總而言之，有實(shí)力，有技術(shù)，有戰(zhàn)略，也有成績，摩爾線程還將在國產(chǎn)GPU的發(fā)展道路上帶來怎樣的驚喜，是值得期待了。

參考鏈接：
[1]https://www.mthreads.com/product/KUAE
[2]https://jxj.beijing.gov.cn/zwgk/zcjd/202404/t20240425_3637629.html
[3]https://ai.meta.com/blog/meta-llama-3/