剛剛，華為聯合硅基流動悄悄發了一篇論文，把自家的昇騰超節點CloudMatrix 384狠狠“安利”了一把。

這篇論文有兩大看點：

1、詳細介紹了CloudMatrix384超節點的硬件架構：910C芯片、節點板卡、尤其是UB架構。

2、針對像DeepSeek這樣數千億參數、MoE架構、超長上下文的推理需求，如何用軟硬協同的“菊花寶典”來搞定。

這份「菊花寶典」，包含CloudMatrix 384超節點硬件和CloudMatrix-Infer推理優化方案。

首先看硬件

華為 CloudMatrix 384 將 384 顆 昇騰 910C NPU、192 顆鯤鵬 CPU 封裝進單一“超節點”，通過 UB（Unified Bus）高帶寬、低時延總線實現全互聯，使計算、內存、網絡資源可池化、等價訪問并獨立伸縮。

具體的架構長這樣↓

包含三個平面：①UB平面完成超節點Scale-up；②RDMA平面，提供多個超節點Scale-out；③VPC平面，南北向通信，連接到數據中心網絡。

1、昇騰910C芯片參數

910C為雙die封裝，每die算力達到376TFLOPS@FP16或1054TFLOPS@INT8。（比較遺憾的是，910系列不支持FP8，也不支持現在N卡和A卡都在狂帶節奏的FP4/FP6，期待下一代可以）

板載128GB HBM3顯存，帶寬3.2TB/s。

每die提供7 × 224 Gbps UB 通道 + 200 Gbps RDMA 通道，既能 scale-up 又能 scale-out。

2、昇騰910C子節點

整個超節點由48個910C子節點組成。

每個子節點板載8張昇騰910C芯片+4張鯤鵬CPU+7張UB交換芯片，并集成一張擎天DPU卡，負責節點級資源管理和南北向網絡連接。

3、UB統一總線架構首次揭秘

超級節點橫跨了16個機架，其中12個計算機架（含48個昇騰910C節點）、4個通信機架，通信機架其實就是所謂的UB統一總線。

這很像典型的Spine-Leaf兩層脊葉架構，一層Leaf集成在每個910C節點機上，二層Spine擱在4個通信機架里面。

每個L1端口對應16條上行鏈路（16×28GB/s），確保整個超級節點網絡無阻塞。

UB 架構的本質，是把傳統“CPU-GPU-交換機多層異構系統”壓縮進一個機柜內部的單級互連域，交付“近芯片級帶寬 + 微秒級延遲 + 統一尋址”的算力池。

大家可以看看菊廠給出的節點內和跨節點通信的帶寬/時延對比：跨die帶寬接近die內帶寬，單跳時延接近1微秒。

菊廠不愧是做通信出身的，這UB做得真NB，大模型推理的三個主要瓶頸（帶寬、延遲、內存可用性），UB都提供了顯著改進。

正是因為UB的存在，CloudMartix才可以放棄傳統Scale out的做法，用Scale up的理念攢一臺大家伙，來搞定計算墻、顯存墻、通信墻。

當然，“一菊獨放不是春，百菊齊放春滿園”，就像下圖一樣，CloudMatrix的遠景是先Scale-UP，再Scale-Out，組成一片超級“大菊園”。

再看軟件部分

配套軟件上，華為有自己的“菊版CUDA”，這就是CANN，包括驅動、運行時和庫三層架構。

同時，為了實現在更大規模的云環境中部署 CloudMatrix384，菊廠提供了一套“Matrix全家桶”，包括 MatrixResource、MatrixLink、MatrixCompute 和 MatrixContainer。

下圖給出了一個16.5萬張卡組成的超大集群的示范，以及在這樣的云平臺上，全家桶各自的位置。

為了更好的跑DeepSeek這樣的大參數、MoE、長上下文模型，菊廠專門提出了CloudMartrix-Infer推理優化方案。

本質上講，這是一個多層級的軟件優化技術，簡要概括下。

1、PDC 解耦（Prefill-Decode-Caching）：
Prefill：16 × NPU 實例（EP32）專管長輸入串、首 token 生成。
Decode：160 × NPU 實例（EP320）追求極低 TPOT 的自回歸生成。
Caching：所有 NPU 通過 UB 總線直連一片分布式 DRAM 池，歷史 KV + 模型權重都放這兒，誰需要誰 DMA 取。
2、LEP 大規模專家并行
讓 DeepSeek-R1 的 320 個專家“一人一核”地攤到 320 個 NPU die 上，通信靠 UB，MoE 延遲不再是瓶頸。
3、硬件友好的優化包
Ascend-native算子 + 微批管線并發，通信與計算重疊。
INT8 五件套量化：混合精度、自適應尺度搜索、離群點抑制、高效INT8 GEMM、塊級剪裁與誤差補償。（彌補昇騰芯片不支持FP8的短板，）

所有這些優化手段，在論文中都有超長篇幅的圖文介紹，詳細到足以讓你相信，這是菊廠真干成了。

實戰效果如何

用這套軟硬協同的“菊花寶典”，進行滿血版DeepSeek推理實戰，是一種怎樣的體驗？

論文中給出了詳細的數據，以及與N記H100/H800對比。（注意不是比H200更不是B200）

1、Prefill預填充階段：

在同樣16384×4096 的重載場景里，華為單卡吞吐達到6688tps，并拿到全場最佳算力利用率（4.45tok/s/TPFOPS）。

2、Decode解碼階段：

在TPOT=50ms的級別下，華為吞吐達到每卡1943tps。同樣獲得了最高的算力利用率（1.29tok/s/TFlops）。

而且華為并沒有使用更大的Batch Size堆吞吐，仍然拿到了高效輸出。

總體來講，這波實戰華為客觀的展示了自身的能力，起到了雙重袪魅效果：

①昇騰的確很能打，在單卡通用硬件算力不如H100的前提下，憑超節點互聯 + 架構級優化，實現整體性能反超。

②昇騰沒有坊間吃瓜群眾吹得那么能打，一頓操作猛如虎，也只是能跟H100掰掰手腕。

華為通過這波操作，驗證了“超節點+軟硬協同”在 LLM 時代的工程可行性與性能上限，為后續萬億參數、大稀疏推理平臺提供了可實戰的“菊花寶典”。

總之，這篇論文來得非常及時，讓我們可以既不盲目自信，也不妄自菲薄。