DeepSeek Ascend 核心發布：矩陣運算與專家通訊，跑分可信到哪一步？（2026）

2026 年 9 月 30 日，DeepSeek 在 GitHub 發布了〈DeepGEMM Ascend〉，把矩陣運算核心帶到華為昇騰平台；同一波公開的 DeepEP-Ascend 則處理多顆晶片之間的專家通訊。這次 DeepSeek Ascend 核心發布，值得看的不只是跑分，而是「算得動」與「傳得動」能否在同一套模型工作負載中接起來。

先看原始倉庫說了什麼，再核對公開程式碼與測試條件，最後判斷哪些結論已經站得住、哪些還要等其他團隊重現。

DeepSeek Ascend 發布了兩塊拼圖

DeepGEMM-Ascend 的 README 把它定位為 DeepGEMM 的昇騰移植版，支援 BF16、FP8、FP4 矩陣乘法，以及 MQA logits、MegaMoE 等核心。README 的更新紀錄把 Ascend 950 初版標在 2026 年 9 月 30 日；倉庫也附有程式碼、測試與 MIT 授權檔。

DeepGEMM Ascend is a port of DeepGEMM to the HUAWEI Ascend platform.

中文：DeepGEMM Ascend 是把 DeepGEMM 移植到華為昇騰平台的版本。

DeepSeek 原始 README

所謂 GEMM，可以想成模型在每張晶片上大量重複的矩陣計算；MoE（專家混合）又會把 token 分派到不同專家。這時算子再快，若派送與回收跨晶片資料跟不上，整體吞吐仍會受限。

第二塊是 DeepEP-Ascend: 其 EPBuffer 介面對齊 NVIDIA 版 DeepEP 的公開 buffer API，涵蓋 MoE 的 dispatch 與 combine。README 同時把 PP、Engram、Bucket 標為仍在驗證或開發中的路徑。這是「有可讀程式碼與介面」的具體進展，不能直接讀成各種拓樸、功能與效能都已等價。

跑分亮眼，但分母和環境要一起看

DeepGEMM-Ascend 公布的測試表 寫明：在 Ascend 950DT、CANN 9.20、冷 L2、`bench_msprof` 條件下，某個 BF16×BF16、M=4096／N=7168／K=16384 的 dense GEMM 案例回報 431 TFLOPS，對照表內 432 TFLOPS 的硬體上限，列為 99.8% 利用率。這是單一算子、特定形狀與 DeepSeek 自訂比較基準的結果，不是完整模型訓練速度，也不是和 NVIDIA 晶片的同條件勝負。

DeepEP-Ascend 的表格 則回報，在 Ascend 950DT、CANN 9.2.0、每 rank 16,384 token 容量、top-6 路由、256 個專家、10 次暖機與 50 次取樣等設定下，EP8 的 FP8 dispatch 範圍為 373–375 GB/s；作者稱 EP8 到 EP32 的 dispatch 約達實體有效載荷頻寬上限的 90–95%。量測包含 issue 和 drain，卻排除最後 epilogue。這些限定會直接影響你能不能複製數字。

The performance results in this README were collected using a PoC HDK supplied to DeepSeek, with additional manual configuration.

中文：README 的效能數據來自供 DeepSeek 使用、另有手動設定的概念驗證版 HDK。

DeepSeek 原始 README

更關鍵的是，原始 README 的 HDK 段落 說這套手動配置並非公開發行版本；它建議使用華為預計於 2026 年 10 月中旬提供的 Q3 商用 HDK 作為公開部署基線，並明說表格不是那個尚未發行版本的量測。日期屬供應商計畫，不能預先當成已上架。因此，DeepEP 的最高頻寬目前應讀作開發者在特定 PoC 環境的報告，外部團隊尚缺同一公開環境可核對。

為何這次發布仍有份量

介面相近，降低的是遷移的一部分成本

DeepGEMM-Ascend 宣稱 API 相容，DeepEP-Ascend 對齊公開 buffer API。對已有 DeepSeek 算子或專家並行程式的團隊，這讓移植有明確起點；真正能否轉移，還取決於縮放因子布局、編譯工具鏈、通訊硬體、韌體與每個算子的精度驗收。README 自己指出昇騰與 NVIDIA 的 scaling factor 儲存布局不同，便說明「同名 API」不等於底層資料格式相同。

開放程式碼，尚未交出跨平台結論

華為 2026 年 9 月的官方說明 也描述 Ascend 950 世代的 Ascend C 程式模型更新，提供較大的平台背景；它沒有替 DeepSeek 的 GEMM 或 EP 數據做獨立驗證。從原始碼、測試目錄到明列組態，這次公開足以讓具備硬體的開發者開始審查；但目前看到的效能曲線仍主要出自開發者自身。

若要回答「能不能降低對單一加速器堆疊的依賴」，不能只看峰值。真正要比的是同一模型、相同精度目標和服務水準下的端到端吞吐、延遲、穩定性，以及移植與維運成本。單點 GEMM 接近表內硬體上限，並不會自動消除跨卡通訊、資料搬移或工具鏈摩擦。

我同意什麼，也還想看什麼

我同意這次發布給了昇騰開發者比口號更具體的材料：可檢查的矩陣核心、專家通訊 API、測試程式及明示的硬體條件。這是軟體生態進展。

我對「接近硬體極限」能否推及實際部署仍保留判斷。DeepGEMM 表格需要外部依相同形狀、精度與量測法重跑；DeepEP 更要等可公開取得的 HDK，再核對 EP8、EP32、EP128 的頻寬與 combine 開銷。若兩邊都只在選定案例表現亮眼，整個 MoE 系統仍可能被最慢的步驟限制。

如果你正在評估昇騰，先做這三件事

第一，列出你模型真正使用的 GEMM 形狀、資料格式與 MoE 路由分布，再對照倉庫測試，不要拿單一峰值替代整體工作負載。第二，逐項記錄 CANN、torch_npu、驅動、HDK 與機器拓樸；商用 HDK 可用後再重測通訊。第三，把正確率、端到端吞吐、延遲尾部與故障恢復一起列成驗收表。若需要先練習如何辨別跑分與實用性，可看 {internal(“local-llm-benchmark-scorecard”,”本機 LLM 跑分成績單教學”)}；想理解算子翻譯中的效能陷阱，可讀 {internal(“cuda-rust-agent-kernel-translation”,”CUDA Rust 算子翻譯案例”)}。