DeepSeek 與華為開源昇騰工具鏈：降低對 NVIDIA 軟體棧依賴

2026 年 10 月上旬，DeepSeek 與華為聯合開源了一批面向昇騰（Ascend）生態的軟體工具。據 Tom's Hardware 報道——其依據是 9 月 30 日路透的一則報道——這批開源內容包括用於 AI 計算與晶片間通訊的庫，以及昇騰對高層程式語言 TileLang 的支援。目的很明確：降低對 NVIDIA 軟體生態（CUDA 棧）的依賴，讓開發者在國產算力上訓練和部署大模型時少一些移植成本。

兩件事：把一張卡用滿，把一群卡連起來

要理解這批工具解決什麼，得先看多卡跑大模型的兩個硬需求：一是在每張加速器上把計算效率做上去，二是晶片之間搬資料要足夠快，快到不會讓處理器空等。第二個需求常被低估——大模型訓練和推理在很多階段是通訊受限而不是算力受限，卡再多，資料運不過來也白搭。官方說這兩家公司正是在這一點上做了聯合最佳化。

具體做法落在一個超節點系統上：據同一報道，雙方圍繞由 128 張昇騰 950 晶片組成的超節點優化了計算與通訊。超節點的思路是把大量加速器通過高速互聯當成一個邏輯整體來用，減少跨機跳數、縮短資料路徑；軟體要做的，就是讓上層程式碼不必關心資料實際落在哪張卡上。

混合專家（MoE）模型讓通訊問題更尖銳。MoE 的訓練與推理要把每個 token 路由到不同的「專家」上，再把結果合併回來，這個來回收發的模式在業界被稱為 all-to-all。它天然是通訊密集的：專家分散在不同晶片上，資料就得來回跑。也正因為如此，DeepSeek 這次把通訊庫與計算庫一起開源，而不是隻給一個運算元庫。

開源了什麼：兩個庫與一門語言

計算側是 DeepGEMM-Ascend。它負責矩陣乘法以及 DeepSeek 模型中使用的其他計算，支援 BF16、FP8 與 FP4 三種精度格式，並且沿用既有 DeepGEMM 庫的程式設計介面——這一點對遷移很關鍵：開發者把工作負載搬到昇騰上時，不需要重學一套 API。矩陣乘法是深度學習裡最核心的運算元，幾乎所有線性層最終都歸到這裡，所以這個庫的效率基本決定了模型的吞吐上限。順帶解釋一下這三種精度。BF16、FP8 與 FP4 指的是參與計算的數值用多少位來表示：位數越少，同樣時間裡能算的次數越多、搬運的資料量也越小，但數值誤差的風險越高。近兩年推理側的加速，很大一部分就是靠往低精度遷移換來的，代價是要在設計上處理精度損失——所以一個運算元庫同時提供這三檔，意味著開發者可以按任務的重要性自己權衡速度與準確度。

通訊側是 DeepEP-Ascend，負責訓練與推理中的通訊，包括把資料路由到混合專家模型的各個專家上，再把它們的輸出合併起來。官方說明這兩個庫都是在昇騰 950 硬體上開發並測試的——這一點比介面列表更能說明成熟度，因為通訊庫的效能高度依賴具體的互聯拓撲與硬體特性，脫離真實硬體寫的實現很難跑出效果。

第三個部分是 TileLang。它為編寫最佳化核心提供更高一層的程式設計抽象，DeepSeek 形容它提供了一種比 NVIDIA 的 CUDA「更簡單的程式設計模型」，目標是提高開發效率、簡化程式碼。這門語言此前已經支援 NVIDIA 與其他硬體，也存在針對昇騰處理器的早期適配；9 月 30 日的更新加入了對昇騰 950 的原生支援，包括程式碼生成、自動排程與同步。

這裡要說明一件容易混淆的事：這批工具是建立在華為既有的 CANN 軟體平臺之上的。CANN 是昇騰上執行 AI 工作負載的底層基礎設施，角色類似於 NVIDIA 的 CUDA 平臺。CUDA 之所以難被替代，不只是因為編譯器本身，而是它多年積累的成熟程式設計環境、庫與開發者習慣構成了整套生態；而 TileLang 這類多平臺語言的價值恰恰在於，它對多個平臺的支援讓它對 NVIDIA GPU 同樣有用，不會被鎖死在單一硬體上。

放在更大的節奏裡看

時間線上有個細節：這批工具的公開，出現在華為釋出其下一代 AI 處理器與超節點系統兩週之後。華為當時表示，預計其 AI 系統將在 2027 年被廣泛用於模型訓練。把兩件事排在一起看，硬體路線圖與軟體工具鏈是配套推進的——晶片換代的同時，程式設計層與運算元庫也需要跟上，否則新硬體的能力落不到開發者手上。

兩家公司的合作也不是從這次開始的。DeepSeek 的 V4 模型在 4 月以預覽形式釋出時就帶有對華為昇騰晶片的支援；按報道口徑，華為稱其昇騰 950 超節點完全支援 V4 系列模型，並且它的晶片參與了更輕量的 V4-Flash 模型的部分訓練。到了這次開源，合作的位置從「讓模型跑得起來」移到了「讓開發者寫得順手」。

另外值得一提的是，這與 DeepSeek 在自家模型線上的動作是兩回事，但方向一致：V4.1-Flash 釋出時，官方也宣佈將與開源社群合作支援它的推理部署。一個是在模型側把部署路徑開放出來，一個是在硬體側把程式設計與通訊的門檻降下來，兩條線都在做同一件事——把工具鏈補齊。

為什麼叫「軟體棧補課」

在硬體受限的背景下，這一步是繞不開的。晶片能用只是第一道門，開發者的日常體驗取決於編譯器、運算元庫、通訊庫與程式語言是否順手：寫起來彆扭、調優要靠猜、換個硬體就要重寫，再好的峰值算力也會被放棄。反過來，當遷移只意味著換一組介面、程式碼結構基本不動時，生態才有可能真正長起來。

還有一層是開源本身的作用。硬體生態的建設很少有廠商能獨自做完：運算元庫要覆蓋真實業務裡五花八門的形狀與精度，通訊庫要適配各種互聯拓撲，編譯器要接住開發者寫出來的千奇百怪的程式碼。把這些放到開源社群裡，第三方可以審計、測速、提交適配，廠商也省下了一部分重複勞動；相應地，用的人也更容易判斷這套棧到底能不能用在生產裡，而不是隻能看廠商自己給的數字。

所以這批開源工具的意義，不在於它立刻把效能拉到什麼水平，而在於它補的是什麼位置。計算庫、通訊庫與程式語言這三件，正好是「把硬體能力交到開發者手裡」最短的一段路徑；把這三件開源，等於把這條路徑上的入場費降下來。接下來值得關注的，是這些庫在真實工程中的成熟度、社群適配的速度，以及昇騰在 2027 年訓練場景裡的實際佔比——這些都需要時間給出答案，而不是靠一份公告。