AIREITER公開在 GitHub 上的程式碼，很容易讓人誤以為整套硬體架構已經隨時可用。DeepSeek 的 Ascend 開發確實具備實用價值，但它並不是能用一行指令取代 NVIDIA 叢集的完整方案：目前公開版本以 Ascend 950 kernel 為核心，並要求 CANN、torch_npu 與相容硬體。
先講結論：公開的是元件，不是開箱即用的 Ascend 叢集
DeepSeek 已公開多項針對 Ascend 的程式碼，包括 DeepGEMM-Ascend。這是一套採 MIT 授權、維持 DeepGEMM API 形狀，並改以 Huawei NPU 為目標的平台專用 kernel 函式庫。儲存庫的初始版本支援 Ascend 950 裝置，並將 CANN 9.20、torch_npu、Python 3.10 以上版本、C++20 工具鏈與 TileLang 列為環境組成。
對於手上已有相容 Ascend 資源的團隊來說，這些內容足以用來檢視、建置、測試效能，並整合特定 kernel。但它還不是一套完整的訓練或正式環境架構。
目前擁有 Ascend 設備的實驗室、雲端業者與企業團隊，都可以開始評估這些程式碼。只有 NVIDIA 硬體的開發者則可以研究程式，或使用 DeepSeek 面向 NVIDIA 的專案，但無法在 H100 或消費級 GeForce 顯示卡上執行這些 Ascend kernel。
DeepSeek 實際公開了哪些東西？
DeepSeek 的 open-infra-index 將基礎架構工作分成多個層次。原始索引大多以 NVIDIA/Hopper 為主：FlashMLA 是 Hopper GPU 的 MLA 解碼 kernel，DeepEP 是專家平行運算通訊函式庫，DeepGEMM 是 FP8 GEMM 函式庫，DualPipe 與 EPLB 處理分散式平行運算，而 3FS/Smallpond 則負責資料存取。
Ascend 版本的重點，是先替部分運算路徑更換硬體目標，而不是一次把所有層級完整替換。現階段最明確的公開成果是 DeepGEMM-Ascend，涵蓋：
- BF16、FP8 與 FP4 GEMM；
- MQA logits；
- 分組 GEMM 與 MegaMoE 路徑；
- mHC prenorm kernel；以及
- Ascend 專用的 JIT 編譯與 layout 轉換。
專案表示其 API 與 DeepGEMM 相容。這對模型工程師很有價值，但不代表 CUDA 二進位檔可以直接移植。Ascend 的矩陣 layout、縮放因子封裝方式、編譯器、runtime 與裝置管理 API，仍然各有一套要求。
元件對照：把 Ascend 放進以 NVIDIA 為主的技術堆疊
下表對照的是各元件扮演的角色，不代表兩者採用完全相同的實作。所謂對應方案，是指處理相近工作；它可能使用不同的 API、通訊互連或 kernel 策略。
| 層級 | 已確認的 Ascend 程式碼或依賴 | 以 NVIDIA 為主的對應方案 | 界線 |
|---|---|---|---|
| 矩陣乘法 | DeepGEMM-Ascend | DeepGEMM 加上 CUDA/Tensor Core kernel | 扮演相同 GEMM 角色，但硬體原語與資料 layout 不同 |
| MoE 分組運算 | DeepGEMM-Ascend 中的 M-Grouped GEMM 與 MegaMoE | DeepGEMM MoE layout 加上客製化 CUDA kernel | 融合專家運算，但 shape 與限制取決於平台 |
| 專家分派 | 本次版本未確認包含完整的 DeepSeek Ascend 分派函式庫；需使用 Ascend collective 與 operator 整合 | DeepEP 搭配 NVLink/RDMA | 處理的是相近的系統問題，但兩者儲存庫不可互換 |
| Attention/logits | DeepGEMM-Ascend 中的 MQA logits | 面向 Hopper 的 FlashMLA | 工作負載相近，但 FlashMLA 明確以 Hopper 為目標 |
| PyTorch 裝置橋接 | TorchNPU（torch_npu） | PyTorch CUDA backend、CUDA runtime 與 cuBLAS | TorchNPU 會呼叫 Ascend NPU，不會模擬 CUDA |
| 編譯器與 operator 工具鏈 | CANN 與 Ascend C/Bisheng 工具 | CUDA Toolkit、NVCC、PTX、cuBLAS、Triton | Python 程式碼看起來可能很熟悉，但裝置契約已經改變 |
| 分散式 runtime | TorchNPU collective 加上 Huawei/operator 部署工具 | NCCL、支援 CUDA-aware 的網路與 NVIDIA 叢集軟體 | 互連、驅動程式、collective 與 framework 版本仍各自獨立 |
| 儲存與資料路徑 | 這裡未確認有 DeepSeek 專用的 Ascend 儲存元件；儲存由業者提供 | DeepSeek 的 3FS/Smallpond 加上業者的儲存堆疊 | 這套 kernel 版本不包含相應的儲存叢集 |
簡單說，每個 Ascend 對應方案都能補上某個系統角色，但不會因此消除 NVIDIA 軟體生態系的差異。
運算 kernel：DeepGEMM-Ascend 對上 DeepGEMM
DeepGEMM-Ascend 是這次發布中最具體的橋接元件。README 將它描述為建構在 Ascend MAD 原語之上的輕量抽象層，負責隱藏 fractal layout、對齊限制、位址計算與底層參數。同時，它也採用了稀疏資料載入與以 coroutine 為基礎的 pipeline 等 Ascend 專用技術。
官方列出的需求相當明確：Ascend 950 系列硬體、CANN 9.20、torch_npu、Python 3.10 或更新版本、相容 C++20 的標準函式庫、TileLang，以及包括 Tree-sitter 在內的建置依賴。文件中的安裝流程包含 git clone --recursive，接著執行 pip install . --no-build-isolation。
儲存庫回報，在 Ascend 950DT 測試環境中，dense-GEMM 使用率最高可達所列硬體上限的 99.8%。其中一個 BF16 案例為 431 TFLOPS，對照 432 TFLOPS 的硬體上限；FP8 案例則列出 861 對 865。這些是特定 shape 下的 kernel 結果，不是 DeepSeek 端到端吞吐量，也不能證明它與 NVIDIA 叢集效能相當。
MoE 執行：MegaMoE 與專家分派
DeepSeek 的 open-infra-index 已指出 V3/R1 系統使用專家平行基礎架構，因此真正重要的問題，不只是單次矩陣乘法有多快。Token 必須先路由，專家完成運算後，結果還要跨 rank 合併。
DeepGEMM-Ascend 的 MegaMoE benchmark 將專家平行分派、兩次分組 GEMM、SwiGLU 與 combine 融合在一起。其公開設定為 EP8、top-k 6、1 個共享專家，並以 8 個 rank 的結果取平均。以 384 個專家、16,384 個 token 的案例來看，README 在一組列出的 hidden/intermediate 設定中回報 846.3 TFLOPS，另一個列出的案例則有 103.3 GB/s 通訊頻寬。
NVIDIA 這邊的對應方案是 DeepEP，加上 DeepGEMM 的 MoE layout，以及周邊的 NCCL/NVLink/RDMA 環境。兩邊面對的是相似的架構問題，但若沒有對齊 token 數量、專家路由、精度、rank 數量與網路條件，就不能直接跨廠商比較這些數字。
模型專用 kernel：MQA logits 與 mHC prenorm
如果只把這次發布描述成「GEMM 移植版」，很容易忽略 Ascend 專案中另外幾個模型專用 kernel。DeepGEMM-Ascend README 將 MQA logits benchmark 標示為 DeepSeek Lightning Indexer 路徑的一部分，並列出 FP8 與 FP4 的 prefill、decode 案例；在文件所列的 shape 下，FP4 decode 為 124.2 微秒，FP8 則為 150.9 微秒。
同一份 README 也將 HC prenorm kernel 標示為 DeepSeek mHC 模組使用，也就是 Manifold-Constrained Hyper-Connections。在文件列出的 N 與 K 值下，M=8,192 時記憶體頻寬最高達 3,463 GB/s。這些數字說明專案針對特定工作負載做了調校，但不代表已涵蓋所有模型 operator 或 serving 路徑。
Framework 與 runtime：CANN、TorchNPU 對上 CUDA
Huawei 的 TorchNPU 儲存庫 將 TorchNPU 定義為 Ascend NPU 的 PyTorch adapter。功能清單包括原生與客製化 PyTorch API、FSDP2、DTensor、collective operation、graph capture、profiling、WatchDog 監控與記憶體管理功能。
在 NVIDIA 世界裡，概念上的對應組合是 PyTorch 加上 CUDA runtime 與相關函式庫。但實際部署差異不小：Ascend 環境需要彼此匹配的 CANN 版本、驅動程式、韌體、Python 版本、PyTorch 版本與 TorchNPU 版本。TorchNPU 文件中的範例安裝 CANN 9.1.0、PyTorch 2.12.0 與 torch-npu 2.12.0，而 DeepGEMM-Ascend 則另外記載 CANN 9.20。這個版本差異提醒我們，應該依照各儲存庫的相容性矩陣操作，不要把不同指南中的指令混在一起。
Huawei 自己的 CANN 文件將 CANN 定義為連接 framework 與 Ascend 硬體的軟體層，涵蓋 runtime 與 operator 開發路徑。實務上，CANN 更接近整個平台的基礎，而不是某一個單獨的 CUDA 函式庫。PyTorch 模型或許仍可保留熟悉的 Python 語法，但底層依舊需要 Ascend 專用 kernel、圖執行行為與除錯流程。
目前仍不在這次發布範圍內的部分
DeepSeek 原本的 open-infrastructure index 還包含 3FS、Smallpond 等儲存與系統層級專案，也介紹 DualPipe、EPLB 與推論系統架構。這些專案確實是重要的參考，但不能把這次 Ascend 專用 kernel 發布解讀成所有元件都已完成移植。
正式環境的叢集仍需要硬體配置、驅動程式與韌體、CANN 安裝、互連設定、分散式 runtime 支援、可觀測性、checkpoint、故障復原，以及 serving 或訓練 orchestrator。Huawei Cloud 的 DeepSeek 部署指南，便透過執行個體、網路、子網路與安全群組說明基礎架構層面的工作；但這些服務是部署前提，並不屬於 DeepGEMM-Ascend 本身。
對訓練工作而言，這個界線尤其重要。公開 kernel 可以降低某個瓶頸，卻不能證明只靠公開儲存庫，就能重現前沿規模的訓練作業。
目前哪些人能使用這套技術？
| 使用者或組織 | 現在能用嗎？ | 需要什麼 | 實務判斷 |
|---|---|---|---|
| 擁有 Ascend 950 硬體的團隊 | 可以，限於支援的 kernel | Linux 環境、相符的驅動程式/韌體、CANN 9.20、TorchNPU、編譯器，以及相容的 Python/PyTorch 設定 | 最適合的早期使用者 |
| 擁有 Ascend 資源的 Huawei Cloud 或企業業者 | 有可能 | 支援的執行個體/叢集，加上完整軟體版本矩陣與部署能力 | 適合受控環境的評估與 serving |
| 使用較舊 Ascend 硬體的研究實驗室 | 不能直接假設 | 確認裝置支援情況；初始版 DeepGEMM-Ascend 是以 Ascend 950 系列開發與驗證 | 不要假設相容 910B/910C |
| 只有 NVIDIA 工作站的使用者 | 不能執行 Ascend kernel | 文件明確要求 Ascend 硬體 | 改用面向 NVIDIA 的 DeepSeek 儲存庫 |
| 沒有加速器資源的一般 PyTorch 開發者 | 無法以有意義的 runtime 方式使用 | 可以檢視程式碼與研究 API，但無法重現硬體 benchmark | 能讀文件，不等於能執行 |
| 想找一套開箱即用前沿訓練替代方案的團隊 | 目前沒有 | 除了 kernel 儲存庫，還需要完整叢集、系統整合與正式環境驗證 | 應視為基礎架構計畫，而不是一次 pip install |
從需求也能看出實際界線：在目前文件所描述的版本中，軟體仍綁定 Ascend 950 硬體、CANN 與 torch_npu。這比「支援一般加速器移植」的說法要窄得多。
公開數據能證明什麼，又不能證明什麼？
99.8% 的 dense-GEMM 數字，足以證明列出的 Ascend kernel 在特定 shape 下能有效利用測試裝置。MegaMoE 表格則進一步顯示，DeepSeek 處理的不只是單一矩陣乘法，也包含融合後的專家平行工作負載。
但這些結果仍無法回答採購或訓練團隊最後一定會問的問題：
- 完整模型的端到端每秒 token 數是多少？
- 在目標 batch size 下，每個 token 的成本是多少？
- 長時間執行與重啟的穩定性如何？
- 哪些 operator 會退回效能較差的路徑？
- 互連、記憶體與功耗，和預定採用的 NVIDIA 叢集相比如何？
- 離開原始測試環境後，能否重現相同結果？
DeepSeek 已公開具備完整設定細節與部分效能表格的 Ascend kernel 工作。這次發布降低了已在 Ascend 生態系內的團隊採用相關軟體的門檻，但硬體與版本門檻依然存在。
常見問題
DeepSeek Ascend 基礎架構是完全開源的嗎？
不是。DeepGEMM-Ascend 與相關文件已公開，但目前並沒有提供一套包含所有依賴與營運流程、可以直接使用的 DeepSeek 訓練叢集。
可以在 NVIDIA GPU 上執行 DeepGEMM-Ascend 嗎？
不行。它的目標硬體是 Ascend 950。NVIDIA 使用者應該改用面向 NVIDIA 的 DeepSeek 專案。
這是否證明 DeepSeek 使用 Ascend 訓練前沿模型？
不代表。它只能證明 DeepSeek 已公開 Ascend kernel，並針對特定工作負載進行 benchmark。這並未建立一套公開、端到端的前沿模型訓練重現方案。
如果你已經掌握受支援的 Ascend 資源，也有能力處理 CANN/TorchNPU 的相容性工作，現在就可以開始使用這套技術。若手上只有 NVIDIA 硬體，應把這次發布視為技術參考，而不是可以直接執行的 backend。