)
DeepSeek一口氣開源6個昇騰組件TileLang、DeepGEMM-Ascend與FlashMLA如何對標CUDA生態(tài)9 月 30 日至 10 月 1 日多個技術資訊渠道集中報道了 DeepSeek 與華為昇騰合作、一次性開源 6 個面向昇騰平臺的基礎軟件組件的消息組件包括 TileLang昇騰版、TileKernels、DeepGEMM-Ascend、DeepEP-Ascend、FlashMLA、DeepSelect并被媒體概括為與此前面向英偉達平臺的開源組件一一對應、“國產 AI 芯片軟件生態(tài)的換軌時刻”[1]。同一批報道還提到這套棧包含TileLang 高級語言編譯器及 DeepGEMM、FlashMLA 等核心計算與通信庫[2]并在行業(yè)日報中被歸入國產算力全棧突破主線[3]。本文不復述這些通稿式結論而是做三件事把六個組件放回加速器軟件棧的分層結構里逐個說明它們各自對應 CUDA 生態(tài)的哪一段、映射關系有多可靠按開發(fā)者角色拆解從 CUDA 遷移到昇騰的真實成本層級最后給出一套可自行復現的性能驗證方法。需要先聲明的是本文可獲得的全部材料均為 9 月 28 日至 10 月 1 日之間的中文資訊日報類二手轉述[1][2][3][4]沒有倉庫 README、官方公告原文、License 文件或任何性能數據。因此下文會嚴格區(qū)分轉述中已出現的表述與基于技術常識的推斷凡涉及具體 API、版本號、芯片型號、性能數字處一律留白或標注待核實。一、先把事實擺清楚這次到底開源了什么1.1 信息來源與證據分級本文采用四級證據口徑A 級官方倉庫 / LICENSE / Release 頁。當前材料中一條都沒有提供六個倉庫的確切 URL、License 類型、版本號均未出現。B 級官方公告或官方技術博客原文。當前材料同樣沒有直接給出。C 級媒體獨立報道。材料中《財聯社》對 FTC 調查的報道被掘金日報轉引[1]但與本主題無關。D 級日報 / 資訊聚合的二手轉述。本文關于本次開源的全部具體描述都來自這一級[1][2][3]。這意味著一個必須寫在前面的結論“DeepSeek 聯合華為昇騰開源全套基礎軟件?！睂崿F國產算力全棧對標 CUDA是媒體轉述中的表述不是本文已經驗證的事實[2]。讀者如果要把這些結論寫進選型報告應先回到 DeepSeek 與華為昇騰的官方組織頁面核對倉庫、License 與 README 自述定位。時間線在轉述中也存在細微差異掘金日報明確寫9 月 30 日DeepSeek 宣布開源面向華為昇騰平臺的全套基礎設施組件[1]而另一篇日報把這一事件放在 10 月 1 日的當日要聞中[2][3]。合理解釋是 9 月 30 日發(fā)布、10 月 1 日進入各資訊日報但這仍屬推斷發(fā)布日期與各組件是否同步發(fā)版需要在 Release 頁確認。1.2 六個組件的功能定位卡下表整理自轉述材料中出現的組件名稱[1][2]。“定位一列凡轉述未說明的一律標注未給出”不做補寫。組件轉述中的名稱變體轉述給出的定位主要使用者推斷待核實項TileLang-AscendTileLang昇騰版、TileLang 高級語言編譯器[1][2]高級語言編譯器 / DSL 層組件寫自定義 kernel 的性能工程師準確倉庫名、是否與 CUDA 側同源、后端切換方式TileKernelsTileKernels[1]轉述未給出功能描述待確認全部名稱暗示為 kernel 集合但官方定義缺失DeepGEMM-AscendDeepGEMM-Ascend、DeepGEMM[1][2]核心計算庫歸入計算與通信庫[2]框架與推理引擎開發(fā)者面向的精度格式、shape 覆蓋、是否含 MoE 特化DeepEP-AscendDeepEP-Ascend[1]轉述歸入通信類組件MoE / 大規(guī)模分布式團隊依賴的底層通信庫、接口與 NVIDIA 版差異FlashMLAFlashMLA[1][2]核心計算庫注意力方向[2]推理引擎開發(fā)者是否區(qū)分 CUDA / 昇騰兩個實現、API 形態(tài)DeepSelectDeepSelect[1]轉述完全未給出功能描述待確認全部這張表本身就說明了一件事六個名字里有兩個TileKernels、DeepSelect在現有材料中沒有任何功能說明。任何在此基礎上猜測它們對應 NCCL對應專家負載均衡器的說法都是編造本文不做這種補全。1.3 全套基礎軟件棧這句話的邊界全棧在不同語境里指代的層完全不同。把加速器軟件棧按依賴關系粗分可以得到五層固件、驅動與 runtime集合通信庫與互聯拓撲管理算子 / kernel 庫GEMM、Attention、歸一化、激活等kernel DSL 與編譯器、自動調優(yōu)模型級庫、調度與并行策略組件。從轉述看本次開源至少覆蓋第 3 層DeepGEMM-Ascend、FlashMLA、第 4 層TileLang-Ascend并疑似覆蓋第 2 層的一部分DeepEP-Ascend與第 5 層DeepSelect功能待確認[1][2]。第 1 層即驅動與 runtime 不在轉述提及范圍內大概率仍由華為昇騰平臺軟件體系提供而不是這六個開源倉庫的組成部分。所以更準確的說法是這是一次面向高性能算子與編譯層的開源補齊而不是把昇騰的全部軟件棧開源了。對開發(fā)者而言遷移工作仍然要經過廠商提供的設備管理、算子覆蓋、框架適配與工具鏈這批組件主要降低的是寫高性能 kernel 與調通信這一段的門檻。二、逐一映射從 CUDA 生態(tài)組件到昇騰組件2.1 映射方法論按棧層對照而不是按名字對號入座媒體使用了一一對應的說法[1]。在工程評估中對應至少有三種強度必須區(qū)分M1 同源移植同一份代碼基線、同一套 API換后端即可編譯。遷移成本最低但需要確認是否有大量#ifdef或后端專用分支。M2 功能等價、API 獨立解決同一類問題但接口、數據布局、調優(yōu)參數各不相同需要真實改代碼。M3 僅生態(tài)位相似處于同一棧層、服務同類上層組件但設計目標不同不能直接替換。下面的映射矩陣中“置信度一列的依據是轉述文本里是否有明確的對應表述。凡轉述只給出組件名而未給出對應物的一律記為未確認”。昇騰組件CUDA 生態(tài)側的參照物映射置信度依據與差異TileLang-AscendTileLangCUDA 后端M1 傾向待核實名稱與TileLang 昇騰版表述暗示同項目多后端[1]是否同一倉庫、同一源碼需查證DeepGEMM-AscendDeepGEMMM2 傾向轉述稱核心計算庫并使用-Ascend后綴[1][2]后綴通常表示移植/適配版本API 兼容性未知FlashMLAFlashMLA不確定轉述未區(qū)分該名字是否同時指代兩個后端實現[1][2]需查倉庫結構DeepEP-AscendDeepEPM2 傾向命名規(guī)則與 DeepGEMM-Ascend 一致[1]底層通信庫依賴未說明TileKernels未確認未確認轉述無對應表述DeepSelect未確認未確認轉述無對應表述2.2 DSL / 編譯層TileLang-Ascend 對標的是寫 kernel 的方式在 CUDA 生態(tài)里寫一個高性能算子通常有三條路直接寫 CUDA C、用 CUTLASS 之類的模板庫做 tile 級組合、或用 Triton 這類 Python 層 DSL 讓編譯器負責底層調度。TileLang 在社區(qū)認知中屬于tile 級 DSL 編譯器這一類用戶聲明 tile 劃分、內存層次與計算原語編譯器生成目標后端代碼。這一段描述屬于技術常識層面的背景推斷本次材料沒有提供 TileLang 的官方文檔具體編程模型、原語集合與自動調優(yōu)能力需以倉庫 README 為準。TileLang-Ascend 的工程意義要看兩個問題是否同一份源碼可切換后端。如果是那么在 CUDA 上積累的 TileLang kernel 有機會以較低成本遷到昇騰如果只是同名 DSL、不同實現則要重新驗證語義一致性。昇騰后端的編譯目標是什么。是落到昇騰自有算子指令層還是經過某個中間表示再下沉到廠商編譯器這決定了編譯耗時、可調試性與錯誤信息質量。對性能工程師來說這兩個問題比支持多少個算子更重要因為它們決定了一個新 kernel 從原型到上線的迭代周期。2.3 稠密計算層DeepGEMM-Ascend 不應被理解為 cuBLAS 的替代品轉述把 DeepGEMM 歸入核心計算與通信庫[2]。在 CUDA 生態(tài)里GEMM 有兩類定位截然不同的實現一類是 cuBLAS 這種通用庫覆蓋大量 shape 與精度組合追求穩(wěn)定與普適另一類是 CUTLASS、DeepGEMM 這類面向特定場景深度調優(yōu)的實現常常服務于大模型訓練/推理中的典型 shape、混合精度乃至 MoE 分組 GEMM。因此評估 DeepGEMM-Ascend 時應當問的是支持哪些精度組合FP16 / BF16 / FP8 / INT8轉述未給出支持的 shape 范圍與對齊要求非典型 shape 是否退化是否包含 MoE 場景下的分組 GEMM 語義與框架默認算子的分派關系是透明接管還是需要顯式調用。把 DeepGEMM-Ascend 直接與 cuBLAS 做全量覆蓋對比是無效的把它的調優(yōu)收益當成昇騰 GEMM 性能整體水平同樣是無效的。2.4 注意力層FlashMLA 的關鍵詞是專用FlashMLA 的名字來自 MLAMulti-head Latent Attention這一注意力結構它是 DeepSeek 系模型使用的注意力變體。這一背景來自社區(qū)通行認知材料中沒有給出 FlashMLA 的技術定義。如果這個定位成立那么 FlashMLA 與 FlashAttention 這類通用注意力實現的關系就不是替代關系前者是面向特定模型結構的深度優(yōu)化 kernel后者覆蓋更廣的注意力變體集合。對遷移者的實際含義是如果模型不用 MLA 結構FlashMLA 的價值有限如果用 MLA 結構那么它是推理/訓練路徑上的關鍵 kernel其正確性與數值行為需要單獨驗證包括 softmax 縮放、KV 緩存布局、序列長度分塊策略等。轉述沒有說明 FlashMLA 在昇騰側是新實現還是移植實現這一點必須查倉庫提交歷史。2.5 通信與 MoE 層DeepEP-Ascend 與集合通信庫是互補關系在 CUDA 生態(tài)里NCCL 提供 all-reduce、all-to-all 等集合通信原語DeepEP 這類項目則在其上實現面向 MoE 專家并行的高效通信與調度模式。這一層次關系是技術常識層面的推斷DeepEP-Ascend 在昇騰側究竟建立在哪個通信庫之上、是否復用廠商集合通信能力現有轉述完全未說明[1]。評估 DeepEP-Ascend 需要確認三點底層依賴是調用廠商集合通信庫還是自帶傳輸實現語義是否支持 MoE 的分發(fā)—組合dispatch / combine語義粒度如何調優(yōu)參數通信計算重疊、chunk 大小、SM / 計算單元占用策略在昇騰上如何映射。第 3 點最容易被低估在 CUDA 上積累的重疊調優(yōu)經驗不能直接搬過去因為計算單元占用模型、片上內存層次與互聯拓撲都不同。2.6 TileKernels 與 DeepSelect明確留白TileKernels 與 DeepSelect 在本文可獲得的材料里只有名字[1]。合理的下一步是閱讀倉庫 README、目錄結構與提交記錄確認 TileKernels 是否為若干 TileLang kernel 的集合實現、DeepSelect 是否與并行調度或專家選擇有關——但在官方描述出現之前這只是待驗證的問題清單不是結論。三、這套棧補的是哪一段從能跑到能調優(yōu)3.1 缺口分析性能可預期性的三個來源在昇騰 NPU 上跑通一個大模型訓練或推理任務與讓它達到可預期的高性能是兩個不同難度的問題。后者依賴三個條件關鍵路徑上有高效 kernelGEMM 與 Attention 通常占據絕大部分計算時間這兩處不達標端到端性能就沒有討論基礎。分布式通信不成為瓶頸尤其在 MoE 模型里專家并行的 all-to-all 通信經常比計算更容易成為短板。第三方能以可承受的成本寫新 kernel模型結構、量化方案、稀疏化策略都在快速演化如果每次變化都要等廠商出算子生態(tài)就無法自我生長。本次開源的組件大致對應這三條DeepGEMM-Ascend 與 FlashMLA 對應第 1 條DeepEP-Ascend 對應第 2 條TileLang-Ascend 對應第 3 條[1][2]。這是從組件命名與轉述定位得出的對應關系屬于本文的結構性分析不是官方口徑。其中第 3 條的分量最重。算子庫解決今天能跑多快DSL 與編譯器解決明天能不能自己調。一個只有算子庫的平臺本質上是把性能上限交給了有限的庫維護者一個有可用 kernel DSL 的平臺才有可能吸引第三方貢獻者參與優(yōu)化。3.2 與模型側開源動作的關系值得注意的是在 9 月 28 日前后另一條相關消息是華為宣布 openPangu-2.0 的預訓練、監(jiān)督微調與后訓練強化學習代碼開源面向昇騰集群提供一體化訓練能力[4]。這與本次基礎軟件棧開源是互補關系而不是同一件事前者打開的是模型與訓練流程后者打開的是算子與編譯層。兩條線合起來才構成從模型到硬件的完整開放度但二者的倉庫、License、維護主體需要分別核查不能因為都在昇騰生態(tài)里就混為一談。3.3 仍然沒有被覆蓋的部分按現有材料以下環(huán)節(jié)仍依賴廠商平臺或需要單獨解決驅動與 runtime 的版本節(jié)奏、兼容性承諾算子覆蓋完整性除 GEMM 與 Attention 外的長尾算子Profiling 與調試工具時間線、通信流水、片上內存占用的可視化能力量化工具鏈校準、精度回退、誤差分析框架級適配層PyTorch 等框架的設備、流、隨機數語義如何映射編譯緩存、圖編譯、算子融合等運行時行為。這幾項恰恰是遷移過程中最花時間的部分。六個開源組件降低了 kernel 層門檻但不等于降低了整體遷移門檻。一個能說明問題的思想實驗是新增一個自定義 attention 變體 kernel。在 CUDA 路徑上成熟團隊通常有可復用的模板、成熟的 profiler、大量的社區(qū)參考實現在昇騰路徑上即便有 TileLang-Ascend團隊仍需自行確認數值語義、性能瓶頸位置與調試工具鏈的成熟度。這一段是推演而非實測目的在于提醒讀者把驗證成本計入預算。四、開發(fā)者遷移成本從 CUDA 代碼搬到昇騰到底要動哪些東西4.1 遷移成本的四個層級層級內容典型改動成本性質L1設備、張量搬運、流與同步 API設備聲明、內存分配、事件計時替換機械替換為主L2算子調用與算子覆蓋缺口框架算子分派、缺失算子的臨時實現適配 少量重寫L3自定義 kernel用 TileLang-Ascend 或廠商算子接口重寫結構性重寫L4并行策略與通信原語MoE 專家并行、通信計算重疊、調度參數策略級重構需要強調的是L3 的成本高度依賴 TileLang-Ascend 是否做到一份源碼多后端L4 的成本高度依賴 DeepEP-Ascend 與 NVIDIA 版 DeepEP 的語義相似度。這兩個變量在現有材料里都未確認因此任何遷移只需幾天或遷移成本極高的斷言都不成立。4.2 三類開發(fā)者的成本畫像只跑 PyTorch 訓練的算法工程師成本集中在 L1、L2。主要風險是算子覆蓋缺口帶來的回退實現以及混合精度下的數值差異排查。建議先把固定隨機種子的單步訓練跑通對比 loss 曲線與關鍵張量的相對誤差再談吞吐。寫自定義 kernel 的性能工程師成本集中在 L3。第一步不是重寫而是驗證 TileLang-Ascend 能否表達現有 kernel 的關鍵結構tile 劃分、片上緩存使用、向量化訪問。選一個真實但足夠小的算子做 POC比通讀文檔更能暴露問題。大規(guī)模 MoE / 推理 Infra 團隊成本集中在 L4。除了接口差異還要重建性能模型通信原語的開銷特征、重疊策略、拓撲敏感性都需要重新測量。這部分往往要重做壓測矩陣不能沿用在 CUDA 上的調優(yōu)結論。4.3 遷移檢查清單以下清單可以作為遷移啟動時的任務表固定并記錄全部軟件版本驅動、runtime、編譯器、框架適配層、各開源組件的 commit明確設備與流的語義映射確認默認流、事件計時的行為是否與原實現一致固定隨機種子記錄隨機數生成器差異帶來的數值偏差基線記錄混合精度與量化格式的對應關系避免精度格式被靜默改變逐項登記算子覆蓋缺口并為每個缺口指定臨時方案與驗收標準重建 profiling 與計時口徑確認預熱、編譯、數據加載是否計入確認分布式啟動方式、通信組劃分與故障恢復行為保留一份可對照的 CUDA 側基線用于數值與性能雙向比對。4.4 一個端到端走查示例示意骨架下面的代碼只是遷移結構示意不是可運行代碼函數名與簽名一律以各倉庫實際 API 為準# 示意骨架非可運行代碼# TODO: 設備、流、計時、kernel 入口名稱均以官方 API 為準defbuild_baseline_case():# 1) 固定 shape 與精度先保證兩側輸入完全一致m,n,k4096,4096,4096dtypebf16# 精度格式以實際支持情況為準a,bmake_inputs(m,n,k,dtype,seed2026)# 2) 記錄軟件棧版本便于復現log_versions(driver...,compiler...,framework...,component...)# 3) 預熱與編譯階段單獨計時不混入穩(wěn)態(tài)結果withtimer(compile_and_warmup):for_inrange(10):outgemm_or_attention(a,b)# 具體入口待核對# 4) 穩(wěn)態(tài)測量報告 P50 / P99 而非單次結果latencies[]withtimer(steady_state):for_inrange(100):outgemm_or_attention(a,b)latencies.append(elapsed())# 5) 數值一致性檢查容限需與精度格式匹配refreference_result(a,b)assertrelative_error(out,ref)tolerance_for(dtype)returnsummarize(latencies)真正的遷移差異往往體現在第 5 步之外如果gemm_or_attention在新平臺上走的是另一條算子分派路徑那么即使數值正確性能特征也可能完全不同。五、性能驗證怎么做一套可復現的基準測試設計由于現有材料沒有提供任何性能數據[1][2][3]本文不給誰快誰慢的結論只給驗證方法。5.1 基準測試的四個層次層級測試對象關注指標主要作用Micro單個 GEMM / Attention kernel達成算力、帶寬利用率、延遲判斷 kernel 本身是否達標Kernel 組合一層 MoE 或 FFN計算—通信重疊率、chunk 開銷判斷組合損耗子模塊單個 decoder layer層內耗時分布、內存峰值定位結構級瓶頸端到端訓練 step / 推理吞吐tokens/s、step time、P99面向業(yè)務的最終口徑必須分層報告。只報端到端數字會掩蓋 kernel 差異只報 micro 數字又會忽略通信與調度開銷。5.2 環(huán)境對齊必須控制的變量同代硬件、相同互聯拓撲與卡數、固定軟件版本、相同 batch 與序列長度、相同精度格式、相同編譯與預熱策略。拿不同代硬件或不同互聯規(guī)模的設備對比 TFLOPS 是無效對照把冷啟動時間混進穩(wěn)態(tài)吞吐同樣無效。一個容易被忽略的口徑問題是峰值算力的來源。廠商公開的峰值與實際可達算力之間的差距受 shape、精度、kernel 實現影響很大。報告中應同時寫明參照的峰值口徑、實際測得的達成率、測試 shape。5.3 指標與口徑建議至少包含達成算力與有效帶寬利用率延遲分布P50、P99而非平均值通信時間占比與計算—通信重疊比例端到端 tokens/s 或 step time數值一致性相對誤差分布與最大偏差內存占用峰值與編譯/預熱耗時。常見口徑陷阱包括是否包含數據加載、是否包含編譯、是否開啟融合優(yōu)化、是否使用圖形捕獲或等價機制、卡數變化后通信占比是否可比。5.4 最小驗證套件對一個剛開始評估的團隊最小可行套件是跑通一個 GEMM 基準 一層 attention確認環(huán)境、版本、計時正確對齊在 CUDA 側跑同一 shape、同一精度建立數值與性能基線歸因用 profiling 工具確認時間分布區(qū)分計算、通信、空轉與同步等待放大擴到完整 decoder layer 與小規(guī)模分布式觀察組合損耗固化把腳本、版本記錄與結果寫進報告模板作為向廠商或內部決策的可復現證據?；鶞蕡蟾婺０褰ㄗh字段 - 測試目的 - 硬件與互聯拓撲 - 軟件棧版本清單 - 測試 shape / batch / seq / 精度 - 預熱與計時規(guī)則 - 基線來源與口徑 - 各層級結果Micro / 組合 / 子模塊 / 端到端 - 數值一致性結果 - 已知偏差與未解釋現象 - 結論與后續(xù)驗證項六、工程與生態(tài)風險開源之后還有哪些不確定性License 與治理。現有材料沒有給出任何一個組件的許可證類型[1][2]。商用、修改、再分發(fā)、專利條款都需要逐一確認。此外要看貢獻流程是否開放、修復是否會回流到通用上游項目這決定了長期維護是單廠商路線還是共享生態(tài)。版本與兼容承諾。芯片型號、平臺軟件版本、框架版本之間的兼容矩陣是否存在、是否有明確的版本支持周期是生產落地的前提。缺少兼容矩陣時團隊只能自行 pin 版本并承擔升級成本。社區(qū)信號的正確讀法。star 數、issue 響應速度、示例完整性、文檔語言與深度都是可觀察指標但必須在同一時間點抓取同一倉庫的真實數據。本批材料中的 GitHub 熱榜 star 增量屬于其他項目與這六個組件無關不能借用作影響力論據同時這批資訊條目的熱度字段均記錄為 0無法用來論證事件影響力。盡調清單License 與專利條款、倉庫活躍度與維護主體、兼容矩陣、官方 benchmark、遷移指南與示例、問題響應機制、上下游回流策略。每一項都應附證據鏈接與核實日期而不是印象分。七、結論給三類開發(fā)者的行動清單算法工程師先跑通最小訓練或推理路徑重點排查算子覆蓋缺口與數值一致性把 loss 曲線對比作為第一驗收項把吞吐放在第二階段。Kernel 工程師選一個真實算子做 TileLang-Ascend 的可行性 POC驗證三個問題——能否表達現有 kernel 結構、編譯與調試體驗如何、性能差距出在哪里。這個 POC 的結論比任何轉述都有價值。技術決策者把六個開源組件與完整可用生態(tài)嚴格區(qū)分要求供應商按分層基準模板提供可復現數據并把 License、兼容矩陣、維護承諾寫進評估報告。綜合來看這次開源動作更準確的定位是降低昇騰生態(tài)在高性能算子與 kernel 編程層面的進入門檻。它是否構成真正的換軌取決于三件事的后續(xù)兌現——TileLang-Ascend 的多后端真實成本、性能數據能否被第三方復現、以及兼容承諾與社區(qū)治理是否持續(xù)。在這些證據出現之前全棧對標 CUDA應被視為媒體表述而非工程結論[2]而6 個組件開源這一事件本身值得每一個做國產算力評估的團隊認真跟進與獨立驗證。參考資料[1] 今日AI大事件 | 2026.10.01FTC 立案調查失控AI智能體、Google 發(fā)布 Gemini 4 Argon、DeepSeek 昇騰全套開源掘金https://juejin.cn/post/7691219326315626511[2] AI 日報2026年10月1日今日主題Google Gemini 4 Argon 發(fā)布中美 AI 算力與政策博弈掘金https://juejin.cn/post/7691160156303163392[3] 2026年10月1日AI行業(yè)日報 | Gemini 4 Argon 正式發(fā)布全球AI監(jiān)管收緊國產算力全棧突破CSDNhttps://blog.csdn.net/Smoothly_Lu/article/details/166937993[4] AI 資訊日報 | 2026年9月28日OpenAI 因智能體越界再停前沿訓練華為盤古2.0全棧開源英偉達加碼玻璃基板與代理安全CSDNhttps://blog.csdn.net/IT_ORACLE/article/details/166827913 DeepSeek一口氣開源6個昇騰組件：TileLang、DeepGEMM-Ascend與FlashMLA如何對標CUDA生態(tài)
DeepSeek一口氣開源6個昇騰組件TileLang、DeepGEMM-Ascend與FlashMLA如何對標CUDA生態(tài)9 月 30 日至 10 月 1 日多個技術資訊渠道集中報道了 DeepSeek 與華為昇騰合作、一次性開源 6 個面向昇騰平臺的基礎軟件組件的消息組件包括 TileLang昇騰版、TileKernels、DeepGEMM-Ascend、DeepEP-Ascend、FlashMLA、DeepSelect并被媒體概括為與此前面向英偉達平臺的開源組件一一對應、“國產 AI 芯片軟件生態(tài)的換軌時刻”[1]。同一批報道還提到這套棧包含TileLang 高級語言編譯器及 DeepGEMM、FlashMLA 等核心計算與通信庫[2]并在行業(yè)日報中被歸入國產算力全棧突破主線[3]。本文不復述這些通稿式結論而是做三件事把六個組件放回加速器軟件棧的分層結構里逐個說明它們各自對應 CUDA 生態(tài)的哪一段、映射關系有多可靠按開發(fā)者角色拆解從 CUDA 遷移到昇騰的真實成本層級最后給出一套可自行復現的性能驗證方法。需要先聲明的是本文可獲得的全部材料均為 9 月 28 日至 10 月 1 日之間的中文資訊日報類二手轉述[1][2][3][4]沒有倉庫 README、官方公告原文、License 文件或任何性能數據。因此下文會嚴格區(qū)分轉述中已出現的表述與基于技術常識的推斷凡涉及具體 API、版本號、芯片型號、性能數字處一律留白或標注待核實。一、先把事實擺清楚這次到底開源了什么1.1 信息來源與證據分級本文采用四級證據口徑A 級官方倉庫 / LICENSE / Release 頁。當前材料中一條都沒有提供六個倉庫的確切 URL、License 類型、版本號均未出現。B 級官方公告或官方技術博客原文。當前材料同樣沒有直接給出。C 級媒體獨立報道。材料中《財聯社》對 FTC 調查的報道被掘金日報轉引[1]但與本主題無關。D 級日報 / 資訊聚合的二手轉述。本文關于本次開源的全部具體描述都來自這一級[1][2][3]。這意味著一個必須寫在前面的結論“DeepSeek 聯合華為昇騰開源全套基礎軟件?！睂崿F國產算力全棧對標 CUDA是媒體轉述中的表述不是本文已經驗證的事實[2]。讀者如果要把這些結論寫進選型報告應先回到 DeepSeek 與華為昇騰的官方組織頁面核對倉庫、License 與 README 自述定位。時間線在轉述中也存在細微差異掘金日報明確寫9 月 30 日DeepSeek 宣布開源面向華為昇騰平臺的全套基礎設施組件[1]而另一篇日報把這一事件放在 10 月 1 日的當日要聞中[2][3]。合理解釋是 9 月 30 日發(fā)布、10 月 1 日進入各資訊日報但這仍屬推斷發(fā)布日期與各組件是否同步發(fā)版需要在 Release 頁確認。1.2 六個組件的功能定位卡下表整理自轉述材料中出現的組件名稱[1][2]。“定位一列凡轉述未說明的一律標注未給出”不做補寫。組件轉述中的名稱變體轉述給出的定位主要使用者推斷待核實項TileLang-AscendTileLang昇騰版、TileLang 高級語言編譯器[1][2]高級語言編譯器 / DSL 層組件寫自定義 kernel 的性能工程師準確倉庫名、是否與 CUDA 側同源、后端切換方式TileKernelsTileKernels[1]轉述未給出功能描述待確認全部名稱暗示為 kernel 集合但官方定義缺失DeepGEMM-AscendDeepGEMM-Ascend、DeepGEMM[1][2]核心計算庫歸入計算與通信庫[2]框架與推理引擎開發(fā)者面向的精度格式、shape 覆蓋、是否含 MoE 特化DeepEP-AscendDeepEP-Ascend[1]轉述歸入通信類組件MoE / 大規(guī)模分布式團隊依賴的底層通信庫、接口與 NVIDIA 版差異FlashMLAFlashMLA[1][2]核心計算庫注意力方向[2]推理引擎開發(fā)者是否區(qū)分 CUDA / 昇騰兩個實現、API 形態(tài)DeepSelectDeepSelect[1]轉述完全未給出功能描述待確認全部這張表本身就說明了一件事六個名字里有兩個TileKernels、DeepSelect在現有材料中沒有任何功能說明。任何在此基礎上猜測它們對應 NCCL對應專家負載均衡器的說法都是編造本文不做這種補全。1.3 全套基礎軟件棧這句話的邊界全棧在不同語境里指代的層完全不同。把加速器軟件棧按依賴關系粗分可以得到五層固件、驅動與 runtime集合通信庫與互聯拓撲管理算子 / kernel 庫GEMM、Attention、歸一化、激活等kernel DSL 與編譯器、自動調優(yōu)模型級庫、調度與并行策略組件。從轉述看本次開源至少覆蓋第 3 層DeepGEMM-Ascend、FlashMLA、第 4 層TileLang-Ascend并疑似覆蓋第 2 層的一部分DeepEP-Ascend與第 5 層DeepSelect功能待確認[1][2]。第 1 層即驅動與 runtime 不在轉述提及范圍內大概率仍由華為昇騰平臺軟件體系提供而不是這六個開源倉庫的組成部分。所以更準確的說法是這是一次面向高性能算子與編譯層的開源補齊而不是把昇騰的全部軟件棧開源了。對開發(fā)者而言遷移工作仍然要經過廠商提供的設備管理、算子覆蓋、框架適配與工具鏈這批組件主要降低的是寫高性能 kernel 與調通信這一段的門檻。二、逐一映射從 CUDA 生態(tài)組件到昇騰組件2.1 映射方法論按棧層對照而不是按名字對號入座媒體使用了一一對應的說法[1]。在工程評估中對應至少有三種強度必須區(qū)分M1 同源移植同一份代碼基線、同一套 API換后端即可編譯。遷移成本最低但需要確認是否有大量#ifdef或后端專用分支。M2 功能等價、API 獨立解決同一類問題但接口、數據布局、調優(yōu)參數各不相同需要真實改代碼。M3 僅生態(tài)位相似處于同一棧層、服務同類上層組件但設計目標不同不能直接替換。下面的映射矩陣中“置信度一列的依據是轉述文本里是否有明確的對應表述。凡轉述只給出組件名而未給出對應物的一律記為未確認”。昇騰組件CUDA 生態(tài)側的參照物映射置信度依據與差異TileLang-AscendTileLangCUDA 后端M1 傾向待核實名稱與TileLang 昇騰版表述暗示同項目多后端[1]是否同一倉庫、同一源碼需查證DeepGEMM-AscendDeepGEMMM2 傾向轉述稱核心計算庫并使用-Ascend后綴[1][2]后綴通常表示移植/適配版本API 兼容性未知FlashMLAFlashMLA不確定轉述未區(qū)分該名字是否同時指代兩個后端實現[1][2]需查倉庫結構DeepEP-AscendDeepEPM2 傾向命名規(guī)則與 DeepGEMM-Ascend 一致[1]底層通信庫依賴未說明TileKernels未確認未確認轉述無對應表述DeepSelect未確認未確認轉述無對應表述2.2 DSL / 編譯層TileLang-Ascend 對標的是寫 kernel 的方式在 CUDA 生態(tài)里寫一個高性能算子通常有三條路直接寫 CUDA C、用 CUTLASS 之類的模板庫做 tile 級組合、或用 Triton 這類 Python 層 DSL 讓編譯器負責底層調度。TileLang 在社區(qū)認知中屬于tile 級 DSL 編譯器這一類用戶聲明 tile 劃分、內存層次與計算原語編譯器生成目標后端代碼。這一段描述屬于技術常識層面的背景推斷本次材料沒有提供 TileLang 的官方文檔具體編程模型、原語集合與自動調優(yōu)能力需以倉庫 README 為準。TileLang-Ascend 的工程意義要看兩個問題是否同一份源碼可切換后端。如果是那么在 CUDA 上積累的 TileLang kernel 有機會以較低成本遷到昇騰如果只是同名 DSL、不同實現則要重新驗證語義一致性。昇騰后端的編譯目標是什么。是落到昇騰自有算子指令層還是經過某個中間表示再下沉到廠商編譯器這決定了編譯耗時、可調試性與錯誤信息質量。對性能工程師來說這兩個問題比支持多少個算子更重要因為它們決定了一個新 kernel 從原型到上線的迭代周期。2.3 稠密計算層DeepGEMM-Ascend 不應被理解為 cuBLAS 的替代品轉述把 DeepGEMM 歸入核心計算與通信庫[2]。在 CUDA 生態(tài)里GEMM 有兩類定位截然不同的實現一類是 cuBLAS 這種通用庫覆蓋大量 shape 與精度組合追求穩(wěn)定與普適另一類是 CUTLASS、DeepGEMM 這類面向特定場景深度調優(yōu)的實現常常服務于大模型訓練/推理中的典型 shape、混合精度乃至 MoE 分組 GEMM。因此評估 DeepGEMM-Ascend 時應當問的是支持哪些精度組合FP16 / BF16 / FP8 / INT8轉述未給出支持的 shape 范圍與對齊要求非典型 shape 是否退化是否包含 MoE 場景下的分組 GEMM 語義與框架默認算子的分派關系是透明接管還是需要顯式調用。把 DeepGEMM-Ascend 直接與 cuBLAS 做全量覆蓋對比是無效的把它的調優(yōu)收益當成昇騰 GEMM 性能整體水平同樣是無效的。2.4 注意力層FlashMLA 的關鍵詞是專用FlashMLA 的名字來自 MLAMulti-head Latent Attention這一注意力結構它是 DeepSeek 系模型使用的注意力變體。這一背景來自社區(qū)通行認知材料中沒有給出 FlashMLA 的技術定義。如果這個定位成立那么 FlashMLA 與 FlashAttention 這類通用注意力實現的關系就不是替代關系前者是面向特定模型結構的深度優(yōu)化 kernel后者覆蓋更廣的注意力變體集合。對遷移者的實際含義是如果模型不用 MLA 結構FlashMLA 的價值有限如果用 MLA 結構那么它是推理/訓練路徑上的關鍵 kernel其正確性與數值行為需要單獨驗證包括 softmax 縮放、KV 緩存布局、序列長度分塊策略等。轉述沒有說明 FlashMLA 在昇騰側是新實現還是移植實現這一點必須查倉庫提交歷史。2.5 通信與 MoE 層DeepEP-Ascend 與集合通信庫是互補關系在 CUDA 生態(tài)里NCCL 提供 all-reduce、all-to-all 等集合通信原語DeepEP 這類項目則在其上實現面向 MoE 專家并行的高效通信與調度模式。這一層次關系是技術常識層面的推斷DeepEP-Ascend 在昇騰側究竟建立在哪個通信庫之上、是否復用廠商集合通信能力現有轉述完全未說明[1]。評估 DeepEP-Ascend 需要確認三點底層依賴是調用廠商集合通信庫還是自帶傳輸實現語義是否支持 MoE 的分發(fā)—組合dispatch / combine語義粒度如何調優(yōu)參數通信計算重疊、chunk 大小、SM / 計算單元占用策略在昇騰上如何映射。第 3 點最容易被低估在 CUDA 上積累的重疊調優(yōu)經驗不能直接搬過去因為計算單元占用模型、片上內存層次與互聯拓撲都不同。2.6 TileKernels 與 DeepSelect明確留白TileKernels 與 DeepSelect 在本文可獲得的材料里只有名字[1]。合理的下一步是閱讀倉庫 README、目錄結構與提交記錄確認 TileKernels 是否為若干 TileLang kernel 的集合實現、DeepSelect 是否與并行調度或專家選擇有關——但在官方描述出現之前這只是待驗證的問題清單不是結論。三、這套棧補的是哪一段從能跑到能調優(yōu)3.1 缺口分析性能可預期性的三個來源在昇騰 NPU 上跑通一個大模型訓練或推理任務與讓它達到可預期的高性能是兩個不同難度的問題。后者依賴三個條件關鍵路徑上有高效 kernelGEMM 與 Attention 通常占據絕大部分計算時間這兩處不達標端到端性能就沒有討論基礎。分布式通信不成為瓶頸尤其在 MoE 模型里專家并行的 all-to-all 通信經常比計算更容易成為短板。第三方能以可承受的成本寫新 kernel模型結構、量化方案、稀疏化策略都在快速演化如果每次變化都要等廠商出算子生態(tài)就無法自我生長。本次開源的組件大致對應這三條DeepGEMM-Ascend 與 FlashMLA 對應第 1 條DeepEP-Ascend 對應第 2 條TileLang-Ascend 對應第 3 條[1][2]。這是從組件命名與轉述定位得出的對應關系屬于本文的結構性分析不是官方口徑。其中第 3 條的分量最重。算子庫解決今天能跑多快DSL 與編譯器解決明天能不能自己調。一個只有算子庫的平臺本質上是把性能上限交給了有限的庫維護者一個有可用 kernel DSL 的平臺才有可能吸引第三方貢獻者參與優(yōu)化。3.2 與模型側開源動作的關系值得注意的是在 9 月 28 日前后另一條相關消息是華為宣布 openPangu-2.0 的預訓練、監(jiān)督微調與后訓練強化學習代碼開源面向昇騰集群提供一體化訓練能力[4]。這與本次基礎軟件棧開源是互補關系而不是同一件事前者打開的是模型與訓練流程后者打開的是算子與編譯層。兩條線合起來才構成從模型到硬件的完整開放度但二者的倉庫、License、維護主體需要分別核查不能因為都在昇騰生態(tài)里就混為一談。3.3 仍然沒有被覆蓋的部分按現有材料以下環(huán)節(jié)仍依賴廠商平臺或需要單獨解決驅動與 runtime 的版本節(jié)奏、兼容性承諾算子覆蓋完整性除 GEMM 與 Attention 外的長尾算子Profiling 與調試工具時間線、通信流水、片上內存占用的可視化能力量化工具鏈校準、精度回退、誤差分析框架級適配層PyTorch 等框架的設備、流、隨機數語義如何映射編譯緩存、圖編譯、算子融合等運行時行為。這幾項恰恰是遷移過程中最花時間的部分。六個開源組件降低了 kernel 層門檻但不等于降低了整體遷移門檻。一個能說明問題的思想實驗是新增一個自定義 attention 變體 kernel。在 CUDA 路徑上成熟團隊通常有可復用的模板、成熟的 profiler、大量的社區(qū)參考實現在昇騰路徑上即便有 TileLang-Ascend團隊仍需自行確認數值語義、性能瓶頸位置與調試工具鏈的成熟度。這一段是推演而非實測目的在于提醒讀者把驗證成本計入預算。四、開發(fā)者遷移成本從 CUDA 代碼搬到昇騰到底要動哪些東西4.1 遷移成本的四個層級層級內容典型改動成本性質L1設備、張量搬運、流與同步 API設備聲明、內存分配、事件計時替換機械替換為主L2算子調用與算子覆蓋缺口框架算子分派、缺失算子的臨時實現適配 少量重寫L3自定義 kernel用 TileLang-Ascend 或廠商算子接口重寫結構性重寫L4并行策略與通信原語MoE 專家并行、通信計算重疊、調度參數策略級重構需要強調的是L3 的成本高度依賴 TileLang-Ascend 是否做到一份源碼多后端L4 的成本高度依賴 DeepEP-Ascend 與 NVIDIA 版 DeepEP 的語義相似度。這兩個變量在現有材料里都未確認因此任何遷移只需幾天或遷移成本極高的斷言都不成立。4.2 三類開發(fā)者的成本畫像只跑 PyTorch 訓練的算法工程師成本集中在 L1、L2。主要風險是算子覆蓋缺口帶來的回退實現以及混合精度下的數值差異排查。建議先把固定隨機種子的單步訓練跑通對比 loss 曲線與關鍵張量的相對誤差再談吞吐。寫自定義 kernel 的性能工程師成本集中在 L3。第一步不是重寫而是驗證 TileLang-Ascend 能否表達現有 kernel 的關鍵結構tile 劃分、片上緩存使用、向量化訪問。選一個真實但足夠小的算子做 POC比通讀文檔更能暴露問題。大規(guī)模 MoE / 推理 Infra 團隊成本集中在 L4。除了接口差異還要重建性能模型通信原語的開銷特征、重疊策略、拓撲敏感性都需要重新測量。這部分往往要重做壓測矩陣不能沿用在 CUDA 上的調優(yōu)結論。4.3 遷移檢查清單以下清單可以作為遷移啟動時的任務表固定并記錄全部軟件版本驅動、runtime、編譯器、框架適配層、各開源組件的 commit明確設備與流的語義映射確認默認流、事件計時的行為是否與原實現一致固定隨機種子記錄隨機數生成器差異帶來的數值偏差基線記錄混合精度與量化格式的對應關系避免精度格式被靜默改變逐項登記算子覆蓋缺口并為每個缺口指定臨時方案與驗收標準重建 profiling 與計時口徑確認預熱、編譯、數據加載是否計入確認分布式啟動方式、通信組劃分與故障恢復行為保留一份可對照的 CUDA 側基線用于數值與性能雙向比對。4.4 一個端到端走查示例示意骨架下面的代碼只是遷移結構示意不是可運行代碼函數名與簽名一律以各倉庫實際 API 為準# 示意骨架非可運行代碼# TODO: 設備、流、計時、kernel 入口名稱均以官方 API 為準defbuild_baseline_case():# 1) 固定 shape 與精度先保證兩側輸入完全一致m,n,k4096,4096,4096dtypebf16# 精度格式以實際支持情況為準a,bmake_inputs(m,n,k,dtype,seed2026)# 2) 記錄軟件棧版本便于復現log_versions(driver...,compiler...,framework...,component...)# 3) 預熱與編譯階段單獨計時不混入穩(wěn)態(tài)結果withtimer(compile_and_warmup):for_inrange(10):outgemm_or_attention(a,b)# 具體入口待核對# 4) 穩(wěn)態(tài)測量報告 P50 / P99 而非單次結果latencies[]withtimer(steady_state):for_inrange(100):outgemm_or_attention(a,b)latencies.append(elapsed())# 5) 數值一致性檢查容限需與精度格式匹配refreference_result(a,b)assertrelative_error(out,ref)tolerance_for(dtype)returnsummarize(latencies)真正的遷移差異往往體現在第 5 步之外如果gemm_or_attention在新平臺上走的是另一條算子分派路徑那么即使數值正確性能特征也可能完全不同。五、性能驗證怎么做一套可復現的基準測試設計由于現有材料沒有提供任何性能數據[1][2][3]本文不給誰快誰慢的結論只給驗證方法。5.1 基準測試的四個層次層級測試對象關注指標主要作用Micro單個 GEMM / Attention kernel達成算力、帶寬利用率、延遲判斷 kernel 本身是否達標Kernel 組合一層 MoE 或 FFN計算—通信重疊率、chunk 開銷判斷組合損耗子模塊單個 decoder layer層內耗時分布、內存峰值定位結構級瓶頸端到端訓練 step / 推理吞吐tokens/s、step time、P99面向業(yè)務的最終口徑必須分層報告。只報端到端數字會掩蓋 kernel 差異只報 micro 數字又會忽略通信與調度開銷。5.2 環(huán)境對齊必須控制的變量同代硬件、相同互聯拓撲與卡數、固定軟件版本、相同 batch 與序列長度、相同精度格式、相同編譯與預熱策略。拿不同代硬件或不同互聯規(guī)模的設備對比 TFLOPS 是無效對照把冷啟動時間混進穩(wěn)態(tài)吞吐同樣無效。一個容易被忽略的口徑問題是峰值算力的來源。廠商公開的峰值與實際可達算力之間的差距受 shape、精度、kernel 實現影響很大。報告中應同時寫明參照的峰值口徑、實際測得的達成率、測試 shape。5.3 指標與口徑建議至少包含達成算力與有效帶寬利用率延遲分布P50、P99而非平均值通信時間占比與計算—通信重疊比例端到端 tokens/s 或 step time數值一致性相對誤差分布與最大偏差內存占用峰值與編譯/預熱耗時。常見口徑陷阱包括是否包含數據加載、是否包含編譯、是否開啟融合優(yōu)化、是否使用圖形捕獲或等價機制、卡數變化后通信占比是否可比。5.4 最小驗證套件對一個剛開始評估的團隊最小可行套件是跑通一個 GEMM 基準 一層 attention確認環(huán)境、版本、計時正確對齊在 CUDA 側跑同一 shape、同一精度建立數值與性能基線歸因用 profiling 工具確認時間分布區(qū)分計算、通信、空轉與同步等待放大擴到完整 decoder layer 與小規(guī)模分布式觀察組合損耗固化把腳本、版本記錄與結果寫進報告模板作為向廠商或內部決策的可復現證據?；鶞蕡蟾婺０褰ㄗh字段 - 測試目的 - 硬件與互聯拓撲 - 軟件棧版本清單 - 測試 shape / batch / seq / 精度 - 預熱與計時規(guī)則 - 基線來源與口徑 - 各層級結果Micro / 組合 / 子模塊 / 端到端 - 數值一致性結果 - 已知偏差與未解釋現象 - 結論與后續(xù)驗證項六、工程與生態(tài)風險開源之后還有哪些不確定性License 與治理。現有材料沒有給出任何一個組件的許可證類型[1][2]。商用、修改、再分發(fā)、專利條款都需要逐一確認。此外要看貢獻流程是否開放、修復是否會回流到通用上游項目這決定了長期維護是單廠商路線還是共享生態(tài)。版本與兼容承諾。芯片型號、平臺軟件版本、框架版本之間的兼容矩陣是否存在、是否有明確的版本支持周期是生產落地的前提。缺少兼容矩陣時團隊只能自行 pin 版本并承擔升級成本。社區(qū)信號的正確讀法。star 數、issue 響應速度、示例完整性、文檔語言與深度都是可觀察指標但必須在同一時間點抓取同一倉庫的真實數據。本批材料中的 GitHub 熱榜 star 增量屬于其他項目與這六個組件無關不能借用作影響力論據同時這批資訊條目的熱度字段均記錄為 0無法用來論證事件影響力。盡調清單License 與專利條款、倉庫活躍度與維護主體、兼容矩陣、官方 benchmark、遷移指南與示例、問題響應機制、上下游回流策略。每一項都應附證據鏈接與核實日期而不是印象分。七、結論給三類開發(fā)者的行動清單算法工程師先跑通最小訓練或推理路徑重點排查算子覆蓋缺口與數值一致性把 loss 曲線對比作為第一驗收項把吞吐放在第二階段。Kernel 工程師選一個真實算子做 TileLang-Ascend 的可行性 POC驗證三個問題——能否表達現有 kernel 結構、編譯與調試體驗如何、性能差距出在哪里。這個 POC 的結論比任何轉述都有價值。技術決策者把六個開源組件與完整可用生態(tài)嚴格區(qū)分要求供應商按分層基準模板提供可復現數據并把 License、兼容矩陣、維護承諾寫進評估報告。綜合來看這次開源動作更準確的定位是降低昇騰生態(tài)在高性能算子與 kernel 編程層面的進入門檻。它是否構成真正的換軌取決于三件事的后續(xù)兌現——TileLang-Ascend 的多后端真實成本、性能數據能否被第三方復現、以及兼容承諾與社區(qū)治理是否持續(xù)。在這些證據出現之前全棧對標 CUDA應被視為媒體表述而非工程結論[2]而6 個組件開源這一事件本身值得每一個做國產算力評估的團隊認真跟進與獨立驗證。參考資料[1] 今日AI大事件 | 2026.10.01FTC 立案調查失控AI智能體、Google 發(fā)布 Gemini 4 Argon、DeepSeek 昇騰全套開源掘金https://juejin.cn/post/7691219326315626511[2] AI 日報2026年10月1日今日主題Google Gemini 4 Argon 發(fā)布中美 AI 算力與政策博弈掘金https://juejin.cn/post/7691160156303163392[3] 2026年10月1日AI行業(yè)日報 | Gemini 4 Argon 正式發(fā)布全球AI監(jiān)管收緊國產算力全棧突破CSDNhttps://blog.csdn.net/Smoothly_Lu/article/details/166937993[4] AI 資訊日報 | 2026年9月28日OpenAI 因智能體越界再停前沿訓練華為盤古2.0全棧開源英偉達加碼玻璃基板與代理安全CSDNhttps://blog.csdn.net/IT_ORACLE/article/details/166827913