今年，AI 大廠采購 GPU 的投入又雙叒瘋狂加碼——
馬斯克 xAI 打算把自家的 10 萬卡超算擴增 10 倍，Meta 也計劃投資 100 億建設一個 130 萬卡規模的數據中心……
GPU 的數量，已經成為了互聯網企業 AI 實力的直接代表。
GPU 雖然計算性能好，但是在集群化的模式下依然有很多挑戰，即便強如英偉達，也面臨通信瓶頸、內存碎片化、資源利用率波動等問題。
簡單說就是，由于通信等原因的限制，GPU 的功力沒辦法完全發揮出來。
所以，建設 AI 時代的云數據中心，不是把卡堆到機柜里就能一勞永逸，現有數據中心的不足，需要用架構的創新才能解決。
最近，華為發布了一篇 60 頁的重磅論文，提出了他們的下一代 AI 數據中心架構設計構想—— Huawei CloudMatrix，以及該構想的第一代產品化的實現 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, 均超過業績在 NVIDIA H100/H800 上實現的性能；
夠準確：DeepSeek-R1 模型在昇騰 NPU 上 INT8 量化的基準測試精度與官方 API 一致；
夠靈活：支持動態調整推理時延 SLO，在 15ms 嚴格延遲約束下仍維持 538 token/s 解碼吞吐量。
在深入剖析這篇重磅論文之前，我們有必要先來了解一下"Why we need CloudMatrix384"。
若是一句話來概括，就是滿足不了當下 AI 發展的算力需求。
因為傳統的 AI 集群，它內部運行的過程更像是 " 分散的小作坊 "，每個服務器（節點）有種各玩各的感覺；算力、內存和網絡資源等等，都是被固定分配的。
在這種傳統模式下，AI 集群一旦遇到超大規模的模型，就會出現各種問題，例如算力不夠、內存帶寬卡脖子、節點間通信慢如蝸牛等等。
而華為在這篇論文中要做的事情，就是提出一種新的模式，把這種 " 小作坊 " 改成 " 超級算力工廠 "——
以 CloudMatrix（首個生產級實現 CloudMatrix384）為代表的華為云下一代 AI 數據中心架構。
因此在這里，像剛才提到的算力、內存、網絡資源等等，會像工廠里的流水線一樣被統一管理起來，哪里需要就調哪里。
并且數據在 CloudMatrix384 里，就像是搭乘了工廠里的高速傳送帶，因為所有芯片的連接都是由超高帶寬、低延遲的統一總線（UB）網絡完成，數據在芯片之間是" 全對等 "直接傳輸，這就避免了傳統網絡 " 堵車 " 的問題。
也正因如此，無論 CloudMatrix384 是遇到多大參數規模的大模型，亦或是需要頻繁訪問緩存的推理任務，都能通過動態分配資源，高效完成計算。
△華為 CloudMatrix 架構愿景
在了解完下一代 AI 數據中心的設計愿景之后，我們繼續深扒一下細節創新技術和獨特優勢。
全對等互聯：華為提前邁出的重要的一步
全對等互聯（Peer-to-Peer），可以說是 CloudMatrix384 在硬件架構設計上的一大創新之處。
因為傳統的 AI 集群中，CPU 相當于扮演一個 " 領導 " 的角色，NPU 等其它硬件更像是 " 下屬 "，數據傳輸的過程中就需要 CPU" 審批簽字 "，效率自然就會大打折扣。
尤其是在處理大規模模型的時候，通信開銷甚至可以占整體任務時長的 40%！
但在 CloudMatrix384 中，情況就截然不同了。
CPU 和 NPU 等硬件更像是一個 " 扁平化管理的團隊 "，它們之間的地位比較平等，直接通過 UB 網絡通信，省去了 " 領導傳話 " 的時間。
△CloudMatrix384 全對等互聯硬件架構設計
而實現如此 " 扁平化管理團隊 " 的關鍵，就是我們剛才提到的UB 網絡，是一種無阻塞全連接拓撲。
它采用 Clos 架構設計，16 個機架中的 L1/L2 交換機形成多層級無阻塞網絡，可以確保任意兩個 NPU/CPU 間通信帶寬恒定。
而在傳統集群中，節點間是通過 RoCE 網絡來通信，帶寬通常僅為 200Gbps（約 25GB/s），并且還存在 " 南北向帶寬瓶頸 "（如數據中心核心交換機負載過高）。
但在 UB 網絡的加持下，每個 NPU 可以提供392GB/s的單向帶寬，相當于每秒能傳 48 部 1080P 電影，數據傳輸又快又穩。
除此之外，傳統 NPU 之間通信還依賴 SDMA 引擎（類似 " 快遞中轉站 "），它的缺點就是啟動延遲比較高（約 10 微秒）。
為此，全對等互聯引入了 AIV 直連（AIV-Direct）的機制，它可以直接通過 UB 網絡寫入遠程 NPU 內存，跳過 SDMA 的中轉，傳輸啟動延遲從 10 微秒降至 1 微秒以內。
這個機制就非常適合 MoE 中 token 分發等高頻通信的場景，把單次通信耗時縮短 70% 以上。
但除了硬件上的設計之外，軟件層面的加持對于 CloudMatrix384 的高效率也是起到了功不可沒的作用。
例如 UB 網絡通過結合內存池化技術，實現了 CloudMatrix384 的 " 全局內存視圖 "，即所有 NPU/CPU 可直接訪問跨節點內存，無需關心數據物理位置。
解碼階段的 NPU 可直接讀取預填充階段 NPU 生成的 KV 緩存，不用再通過 CPU 中轉或磁盤存儲，數據訪問延遲從毫秒級降至微秒級，緩存命中率提升至 56% 以上。
再以 671B 的 DeepSeek-R1 為例，通過 FusedDispatch 融合算子與 AIV 直連，token 分發延遲從 800 微秒降至 300 微秒。預填充計算效率提升 4.45 token/ 秒 /TFLOPS，超越了英偉達 H100 的 3.75 token/ 秒 /TFLOPS。
并且在 TPOT<50ms 的約束下，解碼吞吐量達到了 1943 token/ 秒 / 每 NPU，即使收緊至 TPOT<15ms，仍能維持 538 token/ 秒，這就驗證了全對等互聯在嚴苛延遲場景下的穩定性。
除了 " 全對等互聯 " 之外，這篇重磅論文的第二個技術關鍵詞，非" 云 "莫屬了。
簡單來說，這是一套面向云的基礎設施軟件棧，它就像一個 " 智能管家團隊 "，可以把復雜的硬件設備變成人人能用的 " 云端算力超市 "。
值得一提的是，早在 CloudMatrix384 問世之前，華為云團隊早早地就敲定下一代 AI 數據中心要以 " 面向云 " 為基礎，這就體現了華為在技術戰略布局上的前瞻性。
并且團隊通過兩年多時間的打磨，已經讓部署 CloudMatrix384 這事變成 " 零門檻 "，用戶無需關心硬件細節直接可以部署。
△部署 CloudMatrix384 的華為云基礎設施軟件棧
整體來看，這套面向云的基礎設施軟件棧主要包含以下幾大模塊：MatrixResource、MatrixLink、MatrixCompute、MatrixContainer，以及頂層的 ModelArts 平臺，它們之間可以說是分工明確且相互協作。
首先我們來看下MatrixResource。
它在軟件棧中起到的是 " 資源分配管家 " 的作用，主要負責超級節點內物理資源的供應，包括基于拓撲感知的計算實例分配。
通過運行在每個計算節點擎天卡上的 MatrixResource 代理，動態管理 NPU、CPU 等硬件資源的分配，確保資源按拓撲結構高效調度，避免跨節點通信瓶頸。
MatrixLink則是一位 " 網絡通信管家 "。
它為 UB 和 RDMA 網絡提供服務化功能，支持 QoS 保障、動態路由及網絡感知的工作負載放置。可以優化超節點內 384 個 NPU 及跨節點間的通信效率，例如在推理場景中通過并行傳輸和多路徑負載均衡技術，輔助提升推理效率 20%。
MatrixCompute的角色像是 " 邏輯超節點管家 "。
它的任務是管理超節點的 " 生老病死 "，從開機啟動到故障修復全負責，包括裸金屬供應、自動擴縮容、故障恢復等。
具體實現的方式是跨物理節點編排資源，將分散的硬件組件構建為緊密耦合的邏輯超級節點實例，實現資源的彈性擴展和高可用性。
MatrixContainer是 " 容器部署管家 "。
它的作用是讓用戶的 AI 應用能像 " 快遞包裹 " 一樣輕松部署到超節點上：基于 Kubernetes 容器技術，把復雜的 AI 程序打包成標準化容器，用戶只需 " 點擊部署 "，它就會自動安排到合適的硬件上運行。
最后，就是ModelArts這位 "AI 全流程管家 " 了。
它位于整個軟件棧的頂層，提供從模型開發、訓練到部署的全流程服務，包括 ModelArts Lite（裸金屬 / 容器化硬件訪問）、ModelArts Standard（完整 MLOps 流水線）、ModelArts Studio（模型即服務，MaaS）。
新手可以用 ModelArts Lite 直接調用硬件算力；進階用戶可以用 ModelArts Standard 管理訓練、優化、部署全流程；企業用戶則可以用 ModelArts Studio 把模型變成 API 服務（如聊天機器人），一鍵發布。
由此可見，在 CloudMatrix384 本身高效的基礎上，面向云的基礎設施軟件棧起到了 " 如虎添翼 " 的作用，使得部署這件事變得更加便捷。
軟硬一體：高效、便捷的同時，也夠靈活
除了 " 全對等互聯 " 和 " 云原生 " 這兩個關鍵詞，論文中也還涉及到了二者 " 軟硬一體 " 結合下，在靈活性上體現出來的優勢。
例如剛才我們提到的 " 用戶無需關注底層硬件細節，只需調用 API" 這方面，具體而言，是華為云 EMS（彈性內存服務）通過內存池化技術，將 CPU 連接的 DRAM 聚合為共享內存池，NPU 可直接訪問遠程內存，實現 KV 緩存復用，使首 Token 時延降低 80%，同時減少 NPU 購買量約 50%。
以及 MatrixCompute 支持超節點實例的自動擴縮容，例如根據工作負載動態調整預填充 / 解碼集群的 NPU 數量，在嚴苛的 15ms TPOT 約束下仍能維持 538 token/ 秒的解碼吞吐量。
通過確定性運維服務和昇騰云腦技術，還可以實現萬卡集群故障 10 分鐘內恢復，HBM 和網絡鏈路故障場景下恢復時間挑戰 30 秒，例如光模塊故障影響降低 96%，保障訓練 / 推理任務的連續性。
軟件棧還支持超節點資源的多租戶切分，不同用戶可共享硬件資源但邏輯隔離，例如通過命名空間隔離不同模型的緩存數據，確保數據安全與資源公平分配。
通過智能化調度實現 " 朝推夜訓 "，白天運行推理任務，夜間利用閑置算力進行模型訓練，節點在訓練 / 推理間切換 <5 分鐘，提升算力利用率。
據了解，CloudMatrix384 已經在華為云烏蘭察布、和林格爾、貴安、蕪湖四大節點上線，用戶可按需開通算力，無需自行搭建硬件環境，10 毫秒時延圈覆蓋全國 19 個城市群，支持低延遲訪問。
并且 CloudMatrix384 還提供全棧智能運維的能力，例如昇騰云腦的故障知識庫已經覆蓋了 95% 的常見場景，一鍵診斷的準確率達到了 80%、網絡故障診斷＜10 分鐘，可以說是把運維的門檻也打了下去。
打破 " 不可能三角 "
看到這里，我們可以做個簡單總結了。
華為的 CloudMatrix384 通過 " 全對等架構 + 軟硬協同 " 的模式，打破了傳統上算力、延遲和成本之間的 " 不可能三角 "。
硬件層面，它的全對等 UB 總線實現 392GB/s 卡間帶寬，讓 384 張 NPU 能夠高效協同工作，在 EP320 專家并行模式下，token 分發延遲控制在 100 微秒以內。
軟件層面的 CloudMatrix-Infer 采用全對等推理架構、大 EP 并行、昇騰定制融合算子、UB 驅動的分離式內存池等，最大化發揮硬件效率。
這種設計讓高算力、低延遲、可控成本同時成為可能，總之有了 CloudMatrix384，云端的大模型部署方案變得更香了。
云端可以在數據中心級別進行統一規劃，構建專門的高速網絡拓撲，突破單一企業的物理限制。
更關鍵的是，云端支持彈性擴縮容，企業可以根據業務需求動態調整資源規模，從幾十張卡擴展到數百張卡，而無需對物理設施進行改動。
CloudMatrix384 的運維自動化設計更是將故障影響降低 96%，萬卡集群故障恢復時間控制在 5 分鐘以內，這種專業化運維能力是大部分企業無法自建的。
更重要的，CloudMatrix384 代表的云端 AI 服務模式為中國企業提供了一個更現實的 AI 落地路徑。
比如 DeepSeek-R1 從模型遷移到上線僅用 72 小時，相比傳統方案的 2 周時間，效率提升顯著。
這種成本和效率優勢讓更多企業能夠嘗試 AI 應用，而不需要承擔巨額的基礎設施投入風險。
CloudMatrix384 證明了國產云端方案不只是 " 能用 "，更是在性能和成本效益上都具備競爭優勢。
AI 基礎設施正在重新被定義
CloudMatrix384 代表的不只是一臺更強的 AI 超算，還是對 " 什么是 AI 基礎設施 " 的重新定義。
技術上，它通過 UB 顛覆了過往以 CPU 為中心的層級式設計，將整個超級節點變成了一個統一的計算實體。
面向未來，華為論文中也給出了兩條發展路徑——一方面繼續擴大節點規模，另一方面進行更強力的解耦。
擴大規模容易理解，未來 LLM 參數規模更大，需要更緊密耦合的計算資源。
而解耦，可以分別從資源和應用兩個維度來看。
資源上，CPU 和 NPU 資源物理將分離為專用資源池，從邏輯解耦將走向物理解耦，實現更好的資源利用率。
總之，作者描繪了一個完全解耦、自適應、異構的 AI 數據中心架構，這種架構將進一步提升可擴展性、靈活性、效率和性能。
未來，計算資源將不再是固定的物理設備，而是可以動態編排的抽象能力。
通過 CloudMatrix384 和其未來暢想，我們正在見證又一次新的技術迭代，也在見證整個 AI 數據中心范式的深刻變革。
一鍵三連「點贊」「轉發」「小心心」
歡迎在評論區留下你的想法！
— 完 —
點亮星標
科技前沿進展每日見
