今年，AI 大廠采購 GPU 的投入又雙叒瘋狂加碼——
馬斯克 xAI 打算把自家的 10 萬卡超算擴增 10 倍，Meta 也計劃投資 100 億建設一個 130 萬卡規(guī)模的數(shù)據(jù)中心……
GPU 的數(shù)量，已經(jīng)成為了互聯(lián)網(wǎng)企業(yè) AI 實力的直接代表。
GPU 雖然計算性能好，但是在集群化的模式下依然有很多挑戰(zhàn)，即便強如英偉達，也面臨通信瓶頸、內(nèi)存碎片化、資源利用率波動等問題。
簡單說就是，由于通信等原因的限制，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。
夠高效：預填充吞吐量達 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)調(diào)整推理時延 SLO，在 15ms 嚴格延遲約束下仍維持 538 token/s 解碼吞吐量。
在深入剖析這篇重磅論文之前，我們有必要先來了解一下"Why we need CloudMatrix384"。
若是一句話來概括，就是滿足不了當下 AI 發(fā)展的算力需求。
因為傳統(tǒng)的 AI 集群，它內(nèi)部運行的過程更像是 " 分散的小作坊 "，每個服務器（節(jié)點）有種各玩各的感覺；算力、內(nèi)存和網(wǎng)絡資源等等，都是被固定分配的。
在這種傳統(tǒng)模式下，AI 集群一旦遇到超大規(guī)模的模型，就會出現(xiàn)各種問題，例如算力不夠、內(nèi)存帶寬卡脖子、節(jié)點間通信慢如蝸牛等等。
而華為在這篇論文中要做的事情，就是提出一種新的模式，把這種 " 小作坊 " 改成 " 超級算力工廠 "——
以 CloudMatrix（首個生產(chǎn)級實現(xiàn) CloudMatrix384）為代表的華為云下一代 AI 數(shù)據(jù)中心架構。
因此在這里，像剛才提到的算力、內(nèi)存、網(wǎng)絡資源等等，會像工廠里的流水線一樣被統(tǒng)一管理起來，哪里需要就調(diào)哪里。
并且數(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 引擎（類似 " 快遞中轉(zhuǎn)站 "），它的缺點就是啟動延遲比較高（約 10 微秒）。
為此，全對等互聯(lián)引入了 AIV 直連（AIV-Direct）的機制，它可以直接通過 UB 網(wǎng)絡寫入遠程 NPU 內(nèi)存，跳過 SDMA 的中轉(zhuǎn)，傳輸啟動延遲從 10 微秒降至 1 微秒以內(nèi)。
這個機制就非常適合 MoE 中 token 分發(fā)等高頻通信的場景，把單次通信耗時縮短 70% 以上。
但除了硬件上的設計之外，軟件層面的加持對于 CloudMatrix384 的高效率也是起到了功不可沒的作用。
例如 UB 網(wǎng)絡通過結合內(nèi)存池化技術，實現(xiàn)了 CloudMatrix384 的 " 全局內(nèi)存視圖 "，即所有 NPU/CPU 可直接訪問跨節(jié)點內(nèi)存，無需關心數(shù)據(jù)物理位置。
解碼階段的 NPU 可直接讀取預填充階段 NPU 生成的 KV 緩存，不用再通過 CPU 中轉(zhuǎn)或磁盤存儲，數(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)定性。
除了 " 全對等互聯(lián) " 之外，這篇重磅論文的第二個技術關鍵詞，非" 云 "莫屬了。
簡單來說，這是一套面向云的基礎設施軟件棧，它就像一個 " 智能管家團隊 "，可以把復雜的硬件設備變成人人能用的 " 云端算力超市 "。
值得一提的是，早在 CloudMatrix384 問世之前，華為云團隊早早地就敲定下一代 AI 數(shù)據(jù)中心要以 " 面向云 " 為基礎，這就體現(xiàn)了華為在技術戰(zhàn)略布局上的前瞻性。
并且團隊通過兩年多時間的打磨，已經(jīng)讓部署 CloudMatrix384 這事變成 " 零門檻 "，用戶無需關心硬件細節(jié)直接可以部署。
△部署 CloudMatrix384 的華為云基礎設施軟件棧
整體來看，這套面向云的基礎設施軟件棧主要包含以下幾大模塊：MatrixResource、MatrixLink、MatrixCompute、MatrixContainer，以及頂層的 ModelArts 平臺，它們之間可以說是分工明確且相互協(xié)作。
首先我們來看下MatrixResource。
它在軟件棧中起到的是 " 資源分配管家 " 的作用，主要負責超級節(jié)點內(nèi)物理資源的供應，包括基于拓撲感知的計算實例分配。
通過運行在每個計算節(jié)點擎天卡上的 MatrixResource 代理，動態(tài)管理 NPU、CPU 等硬件資源的分配，確保資源按拓撲結構高效調(diào)度，避免跨節(jié)點通信瓶頸。
MatrixLink則是一位 " 網(wǎng)絡通信管家 "。
它為 UB 和 RDMA 網(wǎng)絡提供服務化功能，支持 QoS 保障、動態(tài)路由及網(wǎng)絡感知的工作負載放置?？梢詢?yōu)化超節(jié)點內(nèi) 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 直接調(diào)用硬件算力；進階用戶可以用 ModelArts Standard 管理訓練、優(yōu)化、部署全流程；企業(yè)用戶則可以用 ModelArts Studio 把模型變成 API 服務（如聊天機器人），一鍵發(fā)布。
由此可見，在 CloudMatrix384 本身高效的基礎上，面向云的基礎設施軟件棧起到了 " 如虎添翼 " 的作用，使得部署這件事變得更加便捷。
軟硬一體：高效、便捷的同時，也夠靈活
除了 " 全對等互聯(lián) " 和 " 云原生 " 這兩個關鍵詞，論文中也還涉及到了二者 " 軟硬一體 " 結合下，在靈活性上體現(xiàn)出來的優(yōu)勢。
例如剛才我們提到的 " 用戶無需關注底層硬件細節(jié)，只需調(diào)用 API" 這方面，具體而言，是華為云 EMS（彈性內(nèi)存服務）通過內(nèi)存池化技術，將 CPU 連接的 DRAM 聚合為共享內(nèi)存池，NPU 可直接訪問遠程內(nèi)存，實現(xiàn) KV 緩存復用，使首 Token 時延降低 80%，同時減少 NPU 購買量約 50%。
以及 MatrixCompute 支持超節(jié)點實例的自動擴縮容，例如根據(jù)工作負載動態(tài)調(diào)整預填充 / 解碼集群的 NPU 數(shù)量，在嚴苛的 15ms TPOT 約束下仍能維持 538 token/ 秒的解碼吞吐量。
通過確定性運維服務和昇騰云腦技術，還可以實現(xiàn)萬卡集群故障 10 分鐘內(nèi)恢復，HBM 和網(wǎng)絡鏈路故障場景下恢復時間挑戰(zhàn) 30 秒，例如光模塊故障影響降低 96%，保障訓練 / 推理任務的連續(xù)性。
軟件棧還支持超節(jié)點資源的多租戶切分，不同用戶可共享硬件資源但邏輯隔離，例如通過命名空間隔離不同模型的緩存數(shù)據(jù)，確保數(shù)據(jù)安全與資源公平分配。
通過智能化調(diào)度實現(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 微秒以內(nèi)。
軟件層面的 CloudMatrix-Infer 采用全對等推理架構、大 EP 并行、昇騰定制融合算子、UB 驅(qū)動的分離式內(nèi)存池等，最大化發(fā)揮硬件效率。
這種設計讓高算力、低延遲、可控成本同時成為可能，總之有了 CloudMatrix384，云端的大模型部署方案變得更香了。
云端可以在數(shù)據(jù)中心級別進行統(tǒng)一規(guī)劃，構建專門的高速網(wǎng)絡拓撲，突破單一企業(yè)的物理限制。
更關鍵的是，云端支持彈性擴縮容，企業(yè)可以根據(jù)業(yè)務需求動態(tài)調(diào)整資源規(guī)模，從幾十張卡擴展到數(shù)百張卡，而無需對物理設施進行改動。
CloudMatrix384 的運維自動化設計更是將故障影響降低 96%，萬卡集群故障恢復時間控制在 5 分鐘以內(nèi)，這種專業(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)更好的資源利用率。
總之，作者描繪了一個完全解耦、自適應、異構的 AI 數(shù)據(jù)中心架構，這種架構將進一步提升可擴展性、靈活性、效率和性能。
未來，計算資源將不再是固定的物理設備，而是可以動態(tài)編排的抽象能力。
通過 CloudMatrix384 和其未來暢想，我們正在見證又一次新的技術迭代，也在見證整個 AI 數(shù)據(jù)中心范式的深刻變革。
一鍵三連「點贊」「轉(zhuǎn)發(fā)」「小心心」
歡迎在評論區(qū)留下你的想法！
— 完 —
點亮星標
科技前沿進展每日見
