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