剛剛，華為聯(lián)合硅基流動悄悄發(fā)了一篇論文，把自家的昇騰超節(jié)點CloudMatrix 384狠狠“安利”了一把。

這篇論文有兩大看點：

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

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

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

首先看硬件

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

具體的架構(gòu)長這樣↓

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

1、昇騰910C芯片參數(shù)

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

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

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

2、昇騰910C子節(jié)點

整個超節(jié)點由48個910C子節(jié)點組成。

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

3、UB統(tǒng)一總線架構(gòu)首次揭秘

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

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

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

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

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

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

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

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

再看軟件部分

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

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

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

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

本質(zhì)上講，這是一個多層級的軟件優(yōu)化技術(shù)，簡要概括下。

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

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

實戰(zhàn)效果如何

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

論文中給出了詳細的數(shù)據(jù)，以及與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堆吞吐，仍然拿到了高效輸出。

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

①昇騰的確很能打，在單卡通用硬件算力不如H100的前提下，憑超節(jié)點互聯(lián) + 架構(gòu)級優(yōu)化，實現(xiàn)整體性能反超。

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

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

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