華為CloudMatrix重磅論文披露AI數(shù)據(jù)中心新范式，推理效率超 H100

金磊 克雷西 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI

今年，AI大廠采購GPU的投入又雙叒瘋狂加碼——

馬斯克xAI打算把自家的10萬卡超算擴增10倍，Meta也計劃投資100億建設一個130萬卡規(guī)模的數(shù)據(jù)中心……

GPU的數(shù)量，已經(jīng)成為了互聯(lián)網(wǎng)企業(yè)AI實力的直接代表。

的確，建設AI算力，這種堆卡模式是最簡單粗暴的，但實際上，AI集群卻并非是卡越多就越好用。

GPU雖然計算性能好，但是在集群化的模式下依然有很多挑戰(zhàn)，即便強如英偉達，也面臨通信瓶頸、內存碎片化、資源利用率波動等問題。

簡單說就是，由于通信等原因的限制，GPU的功力沒辦法完全發(fā)揮出來。

所以，建設AI時代的云數(shù)據(jù)中心，不是把卡堆到機柜里就能一勞永逸，現(xiàn)有數(shù)據(jù)中心的不足，需要用架構的創(chuàng)新才能解決。

最近，華為發(fā)布了一篇60頁的重磅論文，提出了他們的下一代AI數(shù)據(jù)中心架構設計構想——Huawei CloudMatrix，以及該構想的第一代產(chǎn)品化的實現(xiàn)CloudMatrix384。相對于簡單的“堆卡”，華為CloudMatrix給出的架構設計原則是，高帶寬全對等互連和細粒度資源解耦。

這篇論文干貨滿滿，不僅展示了CloudMatrix384的詳細硬件設計，并介紹了基于CloudMatrix384進行DeepSeek推理的最佳實踐方案——CloudMatrix-Infer。

那么，華為提出的CloudMatrix384到底有多強？簡單地說，可以概括成三個方面——

• 夠高效：預填充吞吐量達6688 token/s/NPU，解碼階段1943 token/s/NPU；計算效率方面，預填充達4.45 token/s/TFLOPS，解碼階段1.29 token/s/TFLOPS,均超過業(yè)績在NVIDIA H100/H800上實現(xiàn)的性能；
• 夠準確：DeepSeek-R1模型在昇騰NPU上INT8量化的基準測試精度與官方API一致；
• 夠靈活：支持動態(tài)調整推理時延SLO，在15ms嚴格延遲約束下仍維持538 token/s解碼吞吐量。

AI數(shù)據(jù)中心架構，華為云提前邁出了一步

在深入剖析這篇重磅論文之前，我們有必要先來了解一下“Why we need CloudMatrix384”。

若是一句話來概括，就是滿足不了當下AI發(fā)展的算力需求。

因為傳統(tǒng)的AI集群，它內部運行的過程更像是“分散的小作坊”，每個服務器（節(jié)點）有種各玩各的感覺；算力、內存和網(wǎng)絡資源等等，都是被固定分配的。

在這種傳統(tǒng)模式下，AI集群一旦遇到超大規(guī)模的模型，就會出現(xiàn)各種問題，例如算力不夠、內存帶寬卡脖子、節(jié)點間通信慢如蝸牛等等。

而華為在這篇論文中要做的事情，就是提出一種新的模式，把這種“小作坊”改成“超級算力工廠”——

以CloudMatrix（首個生產(chǎn)級實現(xiàn)CloudMatrix384）為代表的華為云下一代AI數(shù)據(jù)中心架構。

它最鮮明的一大特點就是，所有的資源是可以統(tǒng)一調度的：CloudMatrix384把384個NPU、192個CPU以及其它硬件都集成到了一個超級節(jié)點當中。

因此在這里，像剛才提到的算力、內存、網(wǎng)絡資源等等，會像工廠里的流水線一樣被統(tǒng)一管理起來，哪里需要就調哪里。

并且數(shù)據(jù)在CloudMatrix384里，就像是搭乘了工廠里的高速傳送帶，因為所有芯片的連接都是由超高帶寬、低延遲的統(tǒng)一總線（UB）網(wǎng)絡完成，數(shù)據(jù)在芯片之間是“全對等”直接傳輸，這就避免了傳統(tǒng)網(wǎng)絡“堵車”的問題。

也正因如此，無論CloudMatrix384是遇到多大參數(shù)規(guī)模的大模型，亦或是需要頻繁訪問緩存的推理任務，都能通過動態(tài)分配資源，高效完成計算。

△華為CloudMatrix架構愿景

在了解完下一代AI數(shù)據(jù)中心的設計愿景之后，我們繼續(xù)深扒一下細節(jié)創(chuàng)新技術和獨特優(yōu)勢。

全對等互聯(lián)：華為提前邁出的重要的一步

全對等互聯(lián)（Peer-to-Peer），可以說是CloudMatrix384在硬件架構設計上的一大創(chuàng)新之處。

因為傳統(tǒng)的AI集群中，CPU相當于扮演一個“領導”的角色，NPU等其它硬件更像是“下屬”，數(shù)據(jù)傳輸?shù)倪^程中就需要CPU“審批簽字”，效率自然就會大打折扣。

尤其是在處理大規(guī)模模型的時候，通信開銷甚至可以占整體任務時長的40%！

但在CloudMatrix384中，情況就截然不同了。

CPU和NPU等硬件更像是一個“扁平化管理的團隊”，它們之間的地位比較平等，直接通過UB網(wǎng)絡通信，省去了“領導傳話”的時間。

△CloudMatrix384全對等互聯(lián)硬件架構設計

而實現(xiàn)如此“扁平化管理團隊”的關鍵，就是我們剛才提到的UB網(wǎng)絡，是一種無阻塞全連接拓撲。

它采用Clos架構設計，16個機架中的L1/L2交換機形成多層級無阻塞網(wǎng)絡，可以確保任意兩個NPU/CPU間通信帶寬恒定。

而在傳統(tǒng)集群中，節(jié)點間是通過RoCE網(wǎng)絡來通信，帶寬通常僅為200Gbps（約25GB/s），并且還存在 “南北向帶寬瓶頸”（如數(shù)據(jù)中心核心交換機負載過高）。

但在UB網(wǎng)絡的加持下，每個NPU可以提供392GB/s的單向帶寬，相當于每秒能傳48部1080P電影，數(shù)據(jù)傳輸又快又穩(wěn)。

除此之外，傳統(tǒng)NPU之間通信還依賴SDMA引擎（類似 “快遞中轉站”），它的缺點就是啟動延遲比較高（約10微秒）。

為此，全對等互聯(lián)引入了AIV直連（AIV-Direct）的機制，它可以直接通過UB網(wǎng)絡寫入遠程NPU內存，跳過SDMA的中轉，傳輸啟動延遲從10微秒降至1微秒以內。

這個機制就非常適合MoE中token分發(fā)等高頻通信的場景，把單次通信耗時縮短70%以上。

但除了硬件上的設計之外，軟件層面的加持對于CloudMatrix384的高效率也是起到了功不可沒的作用。

例如UB網(wǎng)絡通過結合內存池化技術，實現(xiàn)了CloudMatrix384的“全局內存視圖”，即所有NPU/CPU可直接訪問跨節(jié)點內存，無需關心數(shù)據(jù)物理位置。

解碼階段的NPU可直接讀取預填充階段NPU生成的KV緩存，不用再通過CPU中轉或磁盤存儲，數(shù)據(jù)訪問延遲從毫秒級降至微秒級，緩存命中率提升至56%以上。

再以671B的DeepSeek-R1為例，通過FusedDispatch融合算子與AIV直連，token分發(fā)延遲從800微秒降至300微秒。預填充計算效率提升4.45 token/秒/TFLOPS，超越了英偉達H100的3.75 token/秒/TFLOPS。

并且在TPOT<50ms的約束下，解碼吞吐量達到了1943 token/秒/每NPU，即使收緊至TPOT<15ms，仍能維持538 token/秒，這就驗證了全對等互聯(lián)在嚴苛延遲場景下的穩(wěn)定性。

因為云原生：不用關心硬件細節(jié)，華為云上開箱即用

除了“全對等互聯(lián)”之外，這篇重磅論文的第二個技術關鍵詞，非“云”莫屬了。

簡單來說，這是一套面向云的基礎設施軟件棧，它就像一個“智能管家團隊”，可以把復雜的硬件設備變成人人能用的 “云端算力超市”。

值得一提的是，早在CloudMatrix384問世之前，華為云團隊早早地就敲定下一代AI數(shù)據(jù)中心要以“面向云”為基礎，這就體現(xiàn)了華為在技術戰(zhàn)略布局上的前瞻性。

并且團隊通過兩年多時間的打磨，已經(jīng)讓部署CloudMatrix384這事變成“零門檻”，用戶無需關心硬件細節(jié)直接可以部署。

△部署CloudMatrix384的華為云基礎設施軟件棧

整體來看，這套面向云的基礎設施軟件棧主要包含以下幾大模塊：MatrixResource、MatrixLink、MatrixCompute、MatrixContainer，以及頂層的ModelArts平臺，它們之間可以說是分工明確且相互協(xié)作。

首先我們來看下MatrixResource。

它在軟件棧中起到的是“資源分配管家”的作用，主要負責超級節(jié)點內物理資源的供應，包括基于拓撲感知的計算實例分配。

通過運行在每個計算節(jié)點擎天卡上的MatrixResource代理，動態(tài)管理NPU、CPU等硬件資源的分配，確保資源按拓撲結構高效調度，避免跨節(jié)點通信瓶頸。

MatrixLink則是一位“網(wǎng)絡通信管家”。

它為UB和RDMA網(wǎng)絡提供服務化功能，支持QoS保障、動態(tài)路由及網(wǎng)絡感知的工作負載放置。可以優(yōu)化超節(jié)點內384個NPU及跨節(jié)點間的通信效率，例如在推理場景中通過并行傳輸和多路徑負載均衡技術，輔助提升推理效率20%。

MatrixCompute的角色像是“邏輯超節(jié)點管家”。

它的任務是管理超節(jié)點的 “生老病死”，從開機啟動到故障修復全負責，包括裸金屬供應、自動擴縮容、故障恢復等。

具體實現(xiàn)的方式是跨物理節(jié)點編排資源，將分散的硬件組件構建為緊密耦合的邏輯超級節(jié)點實例，實現(xiàn)資源的彈性擴展和高可用性。

MatrixContainer是“容器部署管家”。

它的作用是讓用戶的AI應用能像 “快遞包裹” 一樣輕松部署到超節(jié)點上：基于Kubernetes容器技術，把復雜的AI程序打包成標準化容器，用戶只需“點擊部署”，它就會自動安排到合適的硬件上運行。

最后，就是ModelArts這位“AI全流程管家”了。

它位于整個軟件棧的頂層，提供從模型開發(fā)、訓練到部署的全流程服務，包括ModelArts Lite（裸金屬/容器化硬件訪問）、ModelArts Standard（完整MLOps流水線）、ModelArts Studio（模型即服務，MaaS）。

新手可以用ModelArts Lite直接調用硬件算力；進階用戶可以用ModelArts Standard管理訓練、優(yōu)化、部署全流程；企業(yè)用戶則可以用ModelArts Studio把模型變成API服務（如聊天機器人），一鍵發(fā)布。

由此可見，在CloudMatrix384本身高效的基礎上，面向云的基礎設施軟件棧起到了“如虎添翼”的作用，使得部署這件事變得更加便捷。

軟硬一體：高效、便捷的同時，也夠靈活

除了“全對等互聯(lián)”和“云原生”這兩個關鍵詞，論文中也還涉及到了二者“軟硬一體”結合下，在靈活性上體現(xiàn)出來的優(yōu)勢。

例如剛才我們提到的“用戶無需關注底層硬件細節(jié)，只需調用API”這方面，具體而言，是華為云EMS（彈性內存服務）通過內存池化技術，將CPU連接的DRAM聚合為共享內存池，NPU可直接訪問遠程內存，實現(xiàn)KV緩存復用，使首Token時延降低 80%，同時減少NPU購買量約50%。

以及MatrixCompute支持超節(jié)點實例的自動擴縮容，例如根據(jù)工作負載動態(tài)調整預填充/解碼集群的NPU數(shù)量，在嚴苛的15ms TPOT約束下仍能維持538 token/秒的解碼吞吐量。

通過確定性運維服務和昇騰云腦技術，還可以實現(xiàn)萬卡集群故障10分鐘內恢復，HBM和網(wǎng)絡鏈路故障場景下恢復時間挑戰(zhàn)30秒，例如光模塊故障影響降低96%，保障訓練/推理任務的連續(xù)性。

軟件棧還支持超節(jié)點資源的多租戶切分，不同用戶可共享硬件資源但邏輯隔離，例如通過命名空間隔離不同模型的緩存數(shù)據(jù)，確保數(shù)據(jù)安全與資源公平分配。

通過智能化調度實現(xiàn)“朝推夜訓”，白天運行推理任務，夜間利用閑置算力進行模型訓練，節(jié)點在訓練/推理間切換<5分鐘，提升算力利用率。

據(jù)了解，CloudMatrix384已經(jīng)在華為云烏蘭察布、和林格爾、貴安、蕪湖四大節(jié)點上線，用戶可按需開通算力，無需自行搭建硬件環(huán)境，10毫秒時延圈覆蓋全國19個城市群，支持低延遲訪問。

并且CloudMatrix384還提供全棧智能運維的能力，例如昇騰云腦的故障知識庫已經(jīng)覆蓋了95%的常見場景，一鍵診斷的準確率達到了80%、網(wǎng)絡故障診斷＜10分鐘，可以說是把運維的門檻也打了下去。

打破“不可能三角”

看到這里，我們可以做個簡單總結了。

華為的CloudMatrix384通過“全對等架構+軟硬協(xié)同”的模式，打破了傳統(tǒng)上算力、延遲和成本之間的“不可能三角”。

硬件層面，它的全對等UB總線實現(xiàn)392GB/s卡間帶寬，讓384張NPU能夠高效協(xié)同工作，在EP320專家并行模式下，token分發(fā)延遲控制在100微秒以內。

軟件層面的CloudMatrix-Infer采用全對等推理架構、大EP并行、昇騰定制融合算子、UB驅動的分離式內存池等，最大化發(fā)揮硬件效率。

這種設計讓高算力、低延遲、可控成本同時成為可能，總之有了CloudMatrix384，云端的大模型部署方案變得更香了。

云端可以在數(shù)據(jù)中心級別進行統(tǒng)一規(guī)劃，構建專門的高速網(wǎng)絡拓撲，突破單一企業(yè)的物理限制。

更關鍵的是，云端支持彈性擴縮容，企業(yè)可以根據(jù)業(yè)務需求動態(tài)調整資源規(guī)模，從幾十張卡擴展到數(shù)百張卡，而無需對物理設施進行改動。

而且，選擇云也意味著不需要用戶自己找專業(yè)團隊去處理模型優(yōu)化、分布式訓練、故障處理等復雜問題。

CloudMatrix384的運維自動化設計更是將故障影響降低96%，萬卡集群故障恢復時間控制在5分鐘以內，這種專業(yè)化運維能力是大部分企業(yè)無法自建的。

更重要的，CloudMatrix384代表的云端AI服務模式為中國企業(yè)提供了一個更現(xiàn)實的AI落地路徑。

比如DeepSeek-R1從模型遷移到上線僅用72小時，相比傳統(tǒng)方案的2周時間，效率提升顯著。

這種成本和效率優(yōu)勢讓更多企業(yè)能夠嘗試AI應用，而不需要承擔巨額的基礎設施投入風險。

CloudMatrix384證明了國產(chǎn)云端方案不只是“能用”，更是在性能和成本效益上都具備競爭優(yōu)勢。

AI基礎設施正在重新被定義

CloudMatrix384代表的不只是一臺更強的AI超算，還是對“什么是AI基礎設施”的重新定義。

技術上，它通過UB顛覆了過往以CPU為中心的層級式設計，將整個超級節(jié)點變成了一個統(tǒng)一的計算實體。

面向未來，華為論文中也給出了兩條發(fā)展路徑——一方面繼續(xù)擴大節(jié)點規(guī)模，另一方面進行更強力的解耦。

擴大規(guī)模容易理解，未來LLM參數(shù)規(guī)模更大，需要更緊密耦合的計算資源。

而解耦，可以分別從資源和應用兩個維度來看。

資源上，CPU和NPU資源物理將分離為專用資源池，從邏輯解耦將走向物理解耦，實現(xiàn)更好的資源利用率。

應用中，大模型的推理過程中內存密集型注意力計算將從解碼路徑解耦，注意力和專家組件也會分離為獨立執(zhí)行服務。

總之，作者描繪了一個完全解耦、自適應、異構的AI數(shù)據(jù)中心架構，這種架構將進一步提升可擴展性、靈活性、效率和性能。

未來，計算資源將不再是固定的物理設備，而是可以動態(tài)編排的抽象能力。

通過CloudMatrix384和其未來暢想，我們正在見證又一次新的技術迭代，也在見證整個AI數(shù)據(jù)中心范式的深刻變革。