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

這篇論文有兩大看點(diǎn)：

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

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

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

首先看硬件

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

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

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

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

910C為雙die封裝，每die算力達(dá)到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é)點(diǎn)

整個(gè)超節(jié)點(diǎn)由48個(gè)910C子節(jié)點(diǎn)組成。

每個(gè)子節(jié)點(diǎn)板載8張昇騰910C芯片+4張?chǎng)H鵬CPU+7張UB交換芯片，并集成一張擎天DPU卡，負(fù)責(zé)節(jié)點(diǎn)級(jí)資源管理和南北向網(wǎng)絡(luò)連接。

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

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

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

每個(gè)L1端口對(duì)應(yīng)16條上行鏈路（16×28GB/s），確保整個(gè)超級(jí)節(jié)點(diǎn)網(wǎng)絡(luò)無阻塞。

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

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

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

正是因?yàn)閁B的存在，CloudMartix才可以放棄傳統(tǒng)Scale out的做法，用Scale up的理念攢一臺(tái)大家伙，來搞定計(jì)算墻、顯存墻、通信墻。

當(dāng)然，“一菊獨(dú)放不是春，百菊齊放春滿園”，就像下圖一樣，CloudMatrix的遠(yuǎn)景是先Scale-UP，再Scale-Out，組成一片超級(jí)“大菊?qǐng)@”。

再看軟件部分

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

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

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

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

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

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

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

實(shí)戰(zhàn)效果如何

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

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

1、Prefill預(yù)填充階段：

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

2、Decode解碼階段：

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

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

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

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

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

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

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