DeepSeek 與華為昇騰近期公開一批面向昇騰平台的開源工具，涵蓋程式編寫、矩陣運算、注意力與跨晶片通信。很多人第一個會先想到，CUDA 程式能不能直接在昇騰上跑？答案要先看工具處理的是哪一層：這批專案提供新的開發入口與部分相容介面，不能把 CUDA 生態或既有模型程式碼當成已經整套搬過去。真正要估算的，是晶片支援、軟體版本、模型算子和部署流程能否對得上。

一、DeepSeek 開源工具能讓 CUDA 程式直接跑在昇騰上嗎？

不能把 CUDA 程式直接視為可在昇騰執行；部分工具提供相近 API 或多後端編譯入口，仍須確認算子、資料格式與硬體支援。「介面相似」可以減少某些改寫，並不等於程式、效能與部署環境完全相同。

NVIDIA CUDA 是一套面向 NVIDIA GPU 的程式設計與運算平台；華為昇騰則透過 CANN（Compute Architecture for Neural Networks，昇騰異構計算架構）和相關工具鏈管理 NPU 運算。晶片架構、編譯器、記憶體布局與通信機制各有設計。要讓模型跨平台運作，通常需讓每個關鍵算子有對應實作，再處理資料搬移、核心呼叫與多卡通信。

跨晶片工作可拆成三層理解：模型框架負責串起各步運算，算子核心執行矩陣乘法或注意力等工作，執行環境負責編譯、呼叫設備和管理記憶體。上層流程可保留，不代表底層核心也能照搬。若核心沒有目標平台版本，或框架尚未把算子接入昇騰後端，就需補上實作、測試邊界條件，再確認輸出數值。

因此，開源工具降低的是某些環節的起步成本。團隊仍需理解原程式依賴哪些硬體特性，哪些功能由框架提供，哪些來自自訂 CUDA 核心。先列出模型呼叫的算子清單，再比對官方支援矩陣，通常比先安裝一整套工具更能看出缺口，也較容易估算需要投入的移植工程。

這次更新值得留意的部分，是幾個工具開始把昇騰納入支援範圍。例如 DeepGEMM-Ascend 的專案文件寫明，該版本於 2026 年 9 月 30 日首次發布，支援昇騰 950 系列；DeepEP-Ascend 則提供面向昇騰的機器學習通信庫。這代表可用組件增加，仍不能推導所有 CUDA 程式都能無修改執行。

二、這次開源補上模型部署的哪些工具層？

工具組合涵蓋算子編寫與編譯、矩陣乘法、注意力計算、TopK 篩選，以及專家並行通信。這些元件分別處理模型運算中的不同瓶頸，不能單獨視為完整部署平台。

TileLang：算子編寫與編譯入口

TileLang 是以 Python 風格撰寫高效能 GPU、CPU 或 NPU 核心的領域專用語言。開發者可用較高層的語法描述矩陣乘法、注意力等運算，再由後端產生對應程式碼。官方專案在 2026 年 9 月 30 日列出昇騰 950 後端，支援原生程式碼生成、自動排程與同步，以及 SIMD、SIMT 向量程式設計。

它提供的是新的核心開發方式。原本以 CUDA 撰寫的核心仍要確認能否改寫成 TileLang 表達，並檢查昇騰後端目前支援的操作和限制。若程式大量依賴特定 CUDA 函式庫、手工記憶體管理或特殊同步方式，改用較高層語言也可能需要重新設計與調校。

矩陣運算、通信、注意力與資料篩選

DeepGEMM-Ascend 著重 GEMM（general matrix multiplication，通用矩陣乘法）等核心運算，專案列出 BF16、FP8、FP4 等格式與特定運算支援。文件也指出，昇騰端縮放因子的排列格式與 NVIDIA 版本不同。即使沿用類似呼叫介面，資料布局仍可能需要轉換，呼叫端也得符合特定對齊條件。

DeepEP-Ascend 處理 MoE（mixture of experts，混合專家模型）等架構在多張加速卡間分派資料與彙整結果的通信。其文件說明，部分公開 buffer API 與 NVIDIA 版本 DeepEP 對齊，但昇騰後端的支援模式、資料型別與串流行為仍有平台差異；部分 PP、Engram 與 Bucket 通信功能目前仍屬實驗或開發中。

FlashMLA 的昇騰版本提供稀疏注意力的 prefill（輸入提示處理）與 decoding（逐字生成）算子；DeepSelect 則負責 TopK（取出分數最高的 K 個項目）核心，可用於稀疏注意力索引或取樣。兩者只涵蓋特定工作，不代表整個模型推論流程都已備妥。DeepSeek 的 TileKernels 則是以 TileLang 撰寫的核心函式庫，須依目標後端與具體算子檢視支援情形。

「DeepGEMM Ascend 是華為昇騰平台上的 DeepGEMM 實現」，其文件同時註明，昇騰端縮放因子格式與 NVIDIA 不同。這正好說明 API 可沿用時，底層資料表示仍可能需要調整。（DeepGEMM-Ascend 專案文件，中文摘譯）

三、API 對齊能省下哪些遷移工作，哪些仍要改？

對齊 API 可降低部分呼叫端改寫成本，但不會自動完成核心移植、資料轉換、效能調校與集群驗證。節省多少工程時間，要按模型與昇騰目標環境實測。

評估面向NVIDIA CUDA 環境華為昇騰環境遷移時要確認
運算硬體NVIDIA GPU昇騰 NPU具體型號與可取得設備
軟體堆疊CUDA、驅動與 GPU 函式庫CANN、昇騰驅動、torch_npu 等版本配套及編譯器是否吻合
核心實作CUDA 核心或 GPU 函式庫Ascend C、TileLang 或昇騰專用核心模型需要的算子是否已覆蓋
數值與資料布局依 GPU 核心及函式庫而定依昇騰核心及資料格式而定精度、張量布局、對齊及輸出差異
多卡通信GPU 通信函式庫及互連HCCL/HCOMM、網路與昇騰通信元件拓撲、同步、吞吐與錯誤復原
部署驗收既有 GPU 工作負載基準目標昇騰設備上的端到端測試正確性、延遲、吞吐、維運成本

可重用的 API、模型圖或上層框架能縮小改動範圍，尤其是工作負載主要依賴已支援的高階運算時。但相同名稱不保證完全相同的功能語意：DeepEP-Ascend 文件列出特定參數約束，DeepGEMM-Ascend 也揭露縮放格式差異。輸入張量是否連續、資料精度能否接受、工作流是否依賴特定 CUDA 擴充，都要單獨盤點。

資料格式還會牽動模型精度與速度。低精度格式能減少記憶體用量並提高運算吞吐，但各核心對縮放因子、對齊和支援形狀的要求可能不同。轉換資料時若多出額外搬移，或為相容而退回較高精度，原先預期的速度與成本優勢便可能改變。驗證時應同時記錄輸出誤差和端到端耗時，不能只看程式是否順利執行。

效能評估也不能只看單一算子或官方基準。端到端表現會受到批次大小、提示長度、模型量化方式、記憶體容量、晶片間連線與併發請求影響。若某個核心測得高吞吐，模型其他層、資料預處理或通信等待仍可能成為瓶頸。部署比較應固定模型版本、輸入分布、併發量與軟體配置，並同步檢查輸出正確性、每秒生成量、延遲及故障處理。

多卡環境還要把通信和維運納入成本。專家並行的資料分派取決於卡間頻寬、拓撲與同步安排，單機測試通過並不足以預測集群表現。正式上線前可測不同併發程度、長時間運行與設備重啟後的恢復；同時確認日誌、監控和版本回退方式是否具備。這些條件會影響服務穩定性，也會決定少掉的硬體費用是否被工程支出抵銷。

「DeepEP-Ascend 的公開 buffer API 與 NVIDIA 版本 DeepEP 對齊」，但同一份專案文件也列出昇騰專屬的支援模式與參數條件。API 對齊能讓部分程式碼較容易重用，後端行為仍應以實際設備測試為準。（DeepEP-Ascend 專案文件，中文摘譯）

表格中的版本與功能範圍以各專案文件為準，會隨程式更新而改變。跨晶片比較時，需固定軟體版本和測試條件，才有可解讀的結果。

四、台灣開發者怎麼判斷是否值得試用？

先分辨雲端 API 試用、昇騰設備概念驗證（PoC）與正式集群部署，再確認設備、版本、授權及工作負載。若只是呼叫雲端模型 API，通常無須自行處理晶片核心；若要自建推論服務，硬體和軟體堆疊就會直接影響可行性。

先確認設備取得、軟體版本與支援條件

雲端 API 試用可先測功能和應用流程，不能代表自建昇騰部署已通過驗證。進入 PoC 前，應確認能否取得目標型號、驅動與 CANN 套件，以及 PyTorch、torch_npu、TileLang 和模型服務框架的相容版本。DeepGEMM-Ascend 文件以昇騰 950 系列作為開發與驗證環境；這個條件不能直接延伸到其他昇騰世代。

還要查看專案授權與相依元件授權，確認商用、修改、散布及第三方程式碼的條款。開源降低取得原始碼的門檻，不會自動提供硬體、企業支援、維運人力或符合組織需求的安全審查。若設備須透過特定供應商或雲端服務取得，也應先釐清區域供應、帳號資格、付款和服務支援方式。

台灣團隊特別需要確認設備和支援能否落到實際專案時程。文件列出某型號或工具可用，不等於本地供應商已有現貨、維修備品或熟悉該版本的工程支援。若設備從海外雲端租用，還需查清資料位置、網路延遲、使用限制與計費方式。把取得條件寫進 PoC 假設，可避免把「技術上能跑」誤當成「目前能穩定營運」。

用代表性工作負載檢查正確性、效能與維運成本

PoC 不宜只挑最容易跑通的展示模型。應選一個預計實際服務的模型與資料，涵蓋常見輸入長度、精度、批次和併發情境。先比對輸出是否符合品質要求，再觀察冷啟動、編譯時間、吞吐、延遲、記憶體占用與長時間穩定性。若使用多卡，也要測試通信拓撲和節點故障後的復原方式。

試驗結果要連同環境記錄：昇騰型號、韌體、驅動、CANN、框架、工具版本、模型權重、量化設定和測試資料。工具仍快速演進時，重現能力是判斷成熟度的一部分。若團隊無法固定版本、追蹤上游變更或維護自訂核心，短期可跑通的程式也可能形成長期維運負擔。

驗證可分階段進行：先跑單一算子確認安裝與數值，再串起完整模型檢查資料流，最後才測多卡與服務流量。每一階段都先訂出可接受的正確率、延遲和故障率門檻，遇到差異便能回到特定算子或版本追查。這樣能把技術風險逐層暴露，也讓擴大設備採購有明確依據。

雲端 API 試用、單台昇騰設備概念驗證，再到正式集群部署的三階段流程。
先確認應用需求，再逐步驗證模型與部署規模，能讓擴大上線有明確依據。

實際決策可設一個明確門檻：目標模型能否在指定設備上正確運行，端到端成本是否達標，團隊是否能持續維護。若只在特定核心或廠商展示環境得到結果，先把結論限定在該環境；不要直接推估其他晶片世代、模型或台灣採購條件。

  • DeepSeek 與華為昇騰開源工具補上多個運算層，CUDA 程式仍需檢查並移植。
  • API 對齊可減少部分改寫，晶片、CANN、資料格式和算子範圍會限制適用條件。
  • 台灣團隊宜以代表性模型做小規模驗證，再依端到端效能、設備供應與維護能力決定是否擴大。

評估時可先選定一個模型和實際工作負載，逐項核對目標昇騰型號、驅動與 CANN 版本、算子支援、資料格式、通信需求及授權。完成正確性、效能和維運測試後，再比較 GPU 與昇騰方案的整體成本。

昇騰加速器伺服器旁排列晶片型號、驅動與 CANN 版本、算子、資料布局、卡間通信、授權及工作負載測量項目。
逐項核對設備、軟體、算子與工作負載條件，才能判斷部署是否適用。

五、常見問題

它代表面向昇騰的開源工具和部分相容介面增加，部署是否可行仍要依硬體與模型驗證。CUDA 程式能否遷移、沒有昇騰設備能否測試、API 相容是否帶來相同效能，都要分開回答。

常見問題

Q1: 這些工具是否能取代 CUDA？

目前不宜將它描述成 CUDA 的替代品。TileLang 提供新的多後端核心開發方式，其他專案補上昇騰運算與通信元件；既有 CUDA 程式仍須移植或改寫，支援範圍也需逐項確認。

Q2: 沒有昇騰設備能否先測試？

可透過雲端 API 檢查應用功能，也可先閱讀專案程式和建置條件；這些方式無法驗證昇騰核心是否能編譯、執行與達到預期效能。硬體相關的結論仍需在目標設備或可用的昇騰雲端環境上測試。

Q3: API 相容是否代表遷移後效能一致？

不代表。API 相容描述的是程式介面可否沿用，效能則受核心實作、資料格式、晶片架構與軟體版本影響。應以同一模型、輸入和併發條件，比較端到端品質與成本。