調研視窗：過去 24 小時（2026-09-17 07:00 ~ 2026-09-18 07:00，北京時間）。上一期為試執行，視窗取在 09-16 19:23 ~ 09-17 19:23，與本視窗在 09-17 白天部分重疊；重疊部分本期只做狀態說明與後續進展，重點放在視窗內新開、新合入的內容。 信源：GitHub（tile-ai 組織 28 個倉庫推送時間全量核查，視窗內 9 個倉庫有推送；主倉視窗內新開 PR 與缺陷單逐條複核，含 RNG 缺陷拆分、GEMM 型別白名單、CuTeDSL 側 FP4 修復；TileOPs、TileOPs-nightly、tilelang-hygon、tilelang-ascend、tilelang-metax、tilelang-musa 的分支、提交與回移植分支逐條核對）、Google News RSS 中英文多組查詢（走代理）、Hacker News、arXiv、媒體報道（NeoTeo 關於 DeepSeek 核心自動化與 TileKernels 的報道）

本期索引

  • 今日重點：TileOPs 批矩陣乘改用共享 GEMM 模板，H200 上最高提速 1.44 倍（09-17）
  • 一、核心專案進展
    • 1.1 主倉 RNG 三處缺陷拆分修復：預設隨機序列、void 結果繫結、缺初始化不報錯（09-17）
    • 1.2 不支援的 GEMM 型別組合提前攔截，不再落到 nvcc 的型別斷言（09-17）
    • 1.3 CuTeDSL 後端 FP4 轉換與儲存修復，DeepSeek V4 啟用量化仍卡在 FP8 階段（09-17）
    • 1.4 分塊量化 GEMM 的 API 文件與指令級變體上線（09-17）
    • 1.5 前一期已報內容的狀態說明（09-17）
  • 二、多後端適配（昇騰 / 沐曦 / 海光 / 摩爾執行緒）
    • 2.1 昇騰：每日迴歸 1925 項全透過，運算元面推進延續（09-17/09-18）
    • 2.2 海光：MLS 地址重基與非同步流水正式合入，並回移植到版本分支（09-17）
    • 2.3 沐曦：非同步複製 GEMM 入庫後轉入分支維護（09-17）
    • 2.4 摩爾執行緒：回移植分支承載 MUSA 5.3.0 文件，主分支自 09-11 起靜止（09-17）
  • 三、生態與採用方
    • 3.1 TileOPs 清單化：複合運算元、資源與可空輸出進入 manifest（09-17）
    • 3.2 TileOPs 文件站跟進統一分派與新的編譯邊界（09-17）
    • 3.3 夜間基準與正確性快照：基準 1039 項中 1 項失敗，正確性 1117 項全透過（09-17）
    • 3.4 媒體：DeepSeek 工程師預測 AI 寫核心 6 至 12 個月可看齊本人工作（09-16/09-17）
    • 3.5 採用方倉庫視窗內安靜：TileKernels、FlashQLA、TileRT 均無推送
  • 四、社群、教程與活動
    • 4.1 文件站與 API 頁面由機器人再生成（09-17）
    • 4.2 學術與社群側無新增：arXiv 與 Hacker News 視窗內零命中（09-17）
    • 4.3 版本節奏：主倉最新標籤仍為 v0.1.14，TileOPs 無釋出（09-02）
  • 五、趨勢觀察
    • 5.1 主倉重心從「加能力」轉向「把靜默錯誤改成編譯期失敗」
    • 5.2 CuTeDSL 首次出現與上游 CUTLASS DSL 版本演進的耦合傷
    • 5.3 國產後端節奏分化：昇騰高頻迭代、海光收口、沐曦與摩爾執行緒轉維護
    • 5.4 TileOPs 一面提速一面立契約，向帶契約的運算元層演進
    • 5.5 本視窗的空白與風險點

今日重點：TileOPs 批矩陣乘改用共享 GEMM 模板，H200 上最高提速 1.44 倍

日期：2026-09-17　來源：TileOPs #2148 批矩陣乘（BMM）改用共享 GEMM 模板

本視窗最重的一筆改動落在運算元庫而不是語言本體：TileOPs 把批矩陣乘前向運算元（BmmFwdOp，對照 torch.bmm）的核心由自帶實現換成共享 GEMM 模板的批處理形態（GemmTemplate(BATCHED) 與由此派生的批處理核心），改動由 michaelwithu 提交、維護者 lcy-seso 合入，共 6 個提交。

作者在 PR 中給出的實測資料（環境為 NVIDIA H200、CUDA 13.2、PyTorch 2.13.0、TileLang 0.1.12）顯示，收益集中在中大形狀：

形狀（B,M,N,K） 型別 舊版（毫秒） 新版（毫秒） 相對舊版 相對 torch-cublas 新版算力
(8, 2048, 2048, 2048) bfloat16 0.2905 0.2023 1.437 倍 1.007 倍 679.6 TFLOPS
(4, 4096, 4096, 4096) bfloat16 1.0413 0.7451 1.398 倍 1.034 倍 737.9 TFLOPS
(128, 512, 512, 2048) bfloat16 0.2942 0.2110 1.394 倍 1.021 倍 651.3 TFLOPS
(8, 1024, 1024, 1024) float16 0.0410 0.0304 1.351 倍 1.021 倍 566.0 TFLOPS
(16, 512, 512, 512) float16 0.0132 0.0118 1.110 倍 1.008 倍 362.3 TFLOPS
(64, 128, 2048, 128) float16 0.0228 0.0199 1.146 倍 1.063 倍 216.1 TFLOPS
(32, 256, 256, 256) bfloat16 0.0064 0.0065 0.985 倍 1.108 倍 166.1 TFLOPS

讀法有三點：其一，新版本在 15 個用例裡對 torch-cublas 全部不落後（1.007 至 1.185 倍），小形狀（8×128×128×128、32×256×256×256、64×128×128×2048）基本持平；其二，唯一回退項是 (32, 256, 256, 256) 的 bfloat16，0.985 倍，屬小形狀上模板開銷未攤平的邊界情形；其三，把批處理統一到共享模板之後，注意力與多頭結構一類的公共底座只在一處維護，後續批處理運算元的最佳化不必逐個複製。

與提速同一批合入的還有 5 個附帶修復，寫法上都是「讓錯誤在構造期或測量期暴露」：MoE 工作區校驗改為構造期安全、批矩陣乘模板按實際啟動的 tile 計數、H200 裝置判定與裝置名大小寫歸一、注意力核心的 grid 按手上裝置填充。這類伴隨改動說明共享模板被多個運算元複用時，裝置判定與資源計數的健壯性成了新的公共課題。

一、核心專案進展

視窗總覽：tile-ai 組織 28 個倉庫中視窗內 9 個有推送，但主倉預設分支的最後一次提交仍是 09-17 09:57 的分支引數型別對映修復——也就是說，視窗後半段（北京時間 09-17 20:00 之後）主倉沒有新合入，活動集中在「已開 PR 的評審與缺陷拆分」。視窗內主倉新開 6 個 PR 與 1 個缺陷單，全部處於未合入狀態。

1.1 主倉 RNG 三處缺陷拆分修復：預設隨機序列、void 結果繫結、缺初始化不報錯（09-17）

日期：2026-09-17　來源：#3242 預設序列改由完整啟動維度推導／#3243 拒絕繫結 void 結果／#3244 未初始化即取數改為明確診斷

CUDA 側隨機數介面的三處缺陷被拆成三個獨立 PR（同一作者提交，前身 #3239 已關閉改為拆分），三處都屬於「型別上能編譯、語義上出錯」的靜默問題：

其一，隨機狀態初始化在不指定序列號時，只用執行緒塊內的 x 維與網格的 x 維推導預設序列，於是二維及以上執行緒塊裡僅 y/z 座標不同的執行緒共用同一條隨機子序列，取出的隨機數按位元組完全相同。修復改為按行主序把全部已啟動維度折算進預設序列，一維情形的歷史取值保持不變（#3242，附帶 4 個新測試，覆蓋二維執行緒塊、二維網格、一維相容與顯式序列號對照）。

其二，隨機初始化本身是純副作用內建，但前端按「有返回值」的方式記錄，照文件寫法繫結結果會生成 void state = ;，把語義錯誤變成 nvcc 的「不完整型別」編譯錯誤。修復在前端拒絕繫結無值表示式，並在報告裡同時給出變數名與出問題的表示式（#3243）。

其三，函式里從未初始化卻直接取隨機數，會生成空的 curand 呼叫，同樣以 nvcc 語法錯誤的形式出現。修復在函式級預掃描中記錄「是否初始化」與「是否消費隨機流」，缺一即報 TileLang 自身的錯誤；作者明確說明檢查是函式級而非控制流敏感——執行期分支內的初始化仍算已初始化，避免演變成確定賦值分析（#3244）。

三條並讀，能看出主倉正在處理的一類系統性問題：前端診斷缺失，讓語義錯誤在底層編譯器裡以晦澀形式出現。

1.2 不支援的 GEMM 型別組合提前攔截，不再落到 nvcc 的型別斷言（09-17）

日期：2026-09-17　來源：tilelang #3245 在 CUDA 程式碼生成前拒絕不支援的 GEMM 型別組合

一些矩陣乘運算元型別組合（例如 bfloat16 乘 bfloat16 輸出 float16）此前會被前端接受，直到 nvcc 階段才以不透明的靜態斷言失敗。該 PR 為 Ampere/Ada 一代的 mma.sync 通路建立顯式的型別白名單，同時在前端入口與 C++ 指令選擇兩處校驗，不支援的組合在程式碼生成前就被拒絕並給出明確資訊；受支援的組合與非 Ampere 目標不受影響，附帶 1 個負向與 3 個正向迴歸測試。這是本期主倉第二條「把靜默錯誤前移成顯式失敗」的線。

1.3 CuTeDSL 後端 FP4 轉換與儲存修復，DeepSeek V4 啟用量化仍卡在 FP8 階段（09-17）

日期：2026-09-17　來源：缺陷單 #3240／修復 #3241

視窗內最值得留意的風險項出現在 CuTeDSL 後端（以 CUTLASS DSL 原語而非 CUDA 程式碼生成的後端）。缺陷單記錄：DeepSeek V4 示例中的啟用量化核心在該後端上無法工作。根因是版本耦合——轉換輔助函式仍在用過時的向量取元素與插元素操作，而 nvidia-cutlass-dsl 4.7 已把這兩個操作改名，導致所有 FP4 型別轉換丟擲 MLIR 屬性錯誤；同一條鏈路上還有一處 FP8 目標型別不匹配。

修復 PR 把 FP4 轉換改為新版 MLIR 介面後，FP4 啟用量化路徑在指定該後端時可編譯並透過，FP8 目標型別不匹配也一併修掉；但組合用例仍失敗——FP8 階段會撞上一個獨立的 libNVVM 編譯失敗，因此該用例暫時還不能從已知失敗清單中移除。缺陷單裡另有一條值得記錄的發現：該後端的實際啟用方式（透過環境變數指定目標）在倉庫裡只有示例測試的夾具與兩處流水線片段讀取，庫本體並不讀這個變數，說明這條通路的測試覆蓋是繞開庫層搭起來的。

同時也要指出，本節對應的是 09-17 的實際活動（集中在上午與傍晚），與上一期時窗有交疊；本期把它單列，是因為它從「缺陷被記錄」推進到了「缺陷被修復一半、餘下部分被明確界定」。

1.4 分塊量化 GEMM 的 API 文件與指令級變體上線（09-17）

日期：2026-09-17　來源：tilelang.github.io 提交 Update docs

文件站由機器人再生成（387 個檔案），把上一期併入主倉的分塊量化 GEMM 推到了公開 API 頁面：CUDA 方言下新增分塊量化 GEMM 的完整簽名說明（縮放因子作為一等輸入、SM100 上要求完成屏障、雙 CTA 模式要求叢集維度配置、SM120 走片段累加的同步路徑），並新列出三條指令級顯式變體——Hopper 的 wgmma 顯式非同步版、Blackwell 的 tcgen05 顯式非同步版、以及兩者對應的分塊量化版本，以及一個縮放佈局構造入口。文件同時把行為約定寫死為「不支援的組合編譯失敗，而不是丟棄縮放因子」。這與 1.2 的取向一致：新增能力的同時把失敗模式寫進文件。

1.5 前一期已報內容的狀態說明（09-17）

下列內容已在前一期報道，視窗內無語義變化，僅記錄當前狀態：主倉分塊量化 GEMM 與其後端選擇器（#3237）、原子向量寬度按目的地址規劃的效能回補（#3238）、批處理引數型別對映補齊（#3229）；TileOPs 的 MoE 索引小路由專家路徑（#2141）與核心選擇、構建分派重構（#2146）；昇騰側 NSA 前向與變長運算元、動態量化與 RMSNorm 融合示例；沐曦非同步複製 GEMM（#156）與其測試修復（#157）。以上十餘項構成本視窗的存量內容，本期不再重複展開。

二、多後端適配（昇騰 / 沐曦 / 海光 / 摩爾執行緒）

視窗總覽：四家國產與第三方後端在視窗內均有動作，但性質不同——昇騰以「高頻運算元補齊 + 每日迴歸」維持最高活躍度，海光完成了一次較大的後端改動合入與回移植，沐曦與摩爾執行緒的重心已轉到版本分支與文件維護。

2.1 昇騰：每日迴歸 1925 項全透過，運算元面推進延續（09-17/09-18）

日期：2026-09-18　來源：tilelang-ascend 每日測試報告 #1811

昇騰適配倉的每日定時測試在 09-18 05:46（北京時間）出報告：1925 項測試全部透過，失敗 0 項，附件保留 30 天。這是本視窗內唯一的跨日資料點，可以作為「上游主倉連續併入新運算元後，昇騰側迴歸仍保持全綠」的證據。視窗內該倉有 4 筆提交（NSA 前向、NSA 前向變長、動態量化示例、RMSNorm 動態量化融合示例），均落在 09-17 上午，屬前一期已報內容；視窗後半段該倉無新提交。

2.2 海光：MLS 地址重基與非同步流水正式合入，並回移植到版本分支（09-17）

日期：2026-09-17　來源：tilelang-hygon #10 重基緩衝儲存並接管非同步複製流水

海光側一筆改動在本視窗正式合入主分支（19 個檔案，+540/-31），內容是兩件事：一是穩定多級儲存（MLS）的地址重基，新增緩衝操作重基標註與對應的屬性對映，使後端程式碼生成可以按塊索引對緩衝儲存的地址做重基，並順帶加快這些路徑上的佈局推斷；二是把帶非同步偏好的並行複製的提交與等待交給軟體流水規劃器管理。改動同時透過了格式檢查。合入後該倉庫在 09-17 20:25（北京時間）把同一改動回移植到 v0.1.12 版本分支，並額外帶入一筆針對三維切片作用域下矩陣乘佈局的修復，新建的開發分支 feat/hcu-mls-rebase-device-flags 上還有一筆流水管理與格式收尾的提交。海光仍是四家中後端程式碼改動最重的一家。

2.3 沐曦：非同步複製 GEMM 入庫後轉入分支維護（09-17）

日期：2026-09-17　來源：tilelang-metax 分支列表

沐曦側視窗內無新的主分支提交，落點仍是 09-17 上午合入的 MACA 非同步複製矩陣乘支援與其測試修復（前一期已報）。當前活動集中在版本分支與測試維護，是四家中改動幅度最小的一家。

2.4 摩爾執行緒：回移植分支承載 MUSA 5.3.0 文件，主分支自 09-11 起靜止（09-17）

日期：2026-09-17　來源：tilelang-musa 分支列表

摩爾執行緒適配倉的主分支最後一次提交在 09-11，視窗內的推送落在版本回移植分支上，內容是該分支 09-17 上午定格的 MUSA 5.3.0 文件提交（前一期已報）。分支列表顯示其維護方式是「一個上游小版本對應一個加字尾的回移植分支」，當前停在 v0.1.12 一線，尚未跟進主倉 v0.1.14。

三、生態與採用方

3.1 TileOPs 清單化：複合運算元、資源與可空輸出進入 manifest（09-17）

日期：2026-09-17　來源：TileOPs #2147 用清單表達複合運算元

TileOPs 側在本視窗提交了一筆規模最大的改動（34 個檔案，+2552/-370，尚未合入）。它讓運算元清單（manifest）能描述複合運算元的內部結構、資源與可空輸出，同時收掉此前散落的重複推導邏輯。作者列出的問題清單很能說明該專案的成熟度瓶頸：清單此前只能描述公開運算元的外部契約，導致六個已實現的複合運算元無處宣告自己是複合運算元；某個融合專家運算元把兩塊臨時緩衝宣告成普通簽名輸入，等於讓工作區取得了「結果依賴的取值」的語義；共享專家運算元既沒有清單條目，基準又自帶一份算力與位元組數計算，類名還違反了既定的命名約定；返回空值的固定輸出位置原先無法表達。這些都不是效能問題，而是介面契約問題——與今日重點裡批矩陣乘的模板複用放在一起看，TileOPs 正在同時補效能與契約兩條線。

3.2 TileOPs 文件站跟進統一分派與新的編譯邊界（09-17）

日期：2026-09-17　來源：TileOPs.github.io #51 跟進統一核心分派

文件站同步了上一期合入的運算元分派重構：核心獲取入口的新簽名（把鍵與構建方式作為顯式引數）、PyTorch 自定義運算元註冊與假實現註冊的邊界、以及由運算元規格元組生成的編譯邊界寫法。中英兩套文件同批修改，作者在驗證章節記錄了介面頁檢查指令碼、文件站構建與全量測試的執行情況。運算元上游改動後文件當日跟進，說明 TileOPs 的文件流程已自動化到可跟隨重構。

3.3 夜間基準與正確性快照：基準 1039 項中 1 項失敗，正確性 1117 項全透過（09-17）

日期：2026-09-17　來源：TileOPs-nightly 快照提交／快照記錄檔案

TileOPs 的夜間流水線在本視窗為「批矩陣乘模板化」那個提交（正是今日重點的合入結果）生成了快照，含基準結果、正確性結果與一份環境後設資料。後設資料把可復現所需的要素全部固定下來：具體提交號、容器映象按其摘要記錄、GPU 型號與功耗上限、SM 時鐘設定、以及全量依賴版本（該次記錄中 Cube 版本 13.2、PyTorch 2.13.0、TileLang 0.1.11 加該次提交的構建標識）。兩份結果的讀數：

  • 正確性：1117 項測試全部透過，跳過 2 項，用時約 219 秒；
  • 基準：1039 個用例中 1 項失敗，失敗項是 GQA 預填充分頁核心在 softcap 50 配置下的用例，報錯來自對照基線實現的函式簽名不匹配（缺少一個引數），並非 TileOPs 自身核心出錯——這類失敗恰好說明「對照側也要進迴歸」的必要性。

基準裡最亮的是稀疏注意力解碼一類運算元：主流批次配置下 TileOPs 為 1.86 毫秒、313.98 TFLOPS，對照實現為 19.88 毫秒、30.79 TFLOPS，另兩個對照（融合注意力實現 5.61 毫秒、編譯版 PyTorch 16.64 毫秒）也在其後；長上下文低 top-k 變體為 0.50 毫秒、291.55 TFLOPS，對照 20.36 毫秒；多頭潛在注意力解碼在 4k 上下文（半精度）為 0.0385 毫秒，對照 0.3147 毫秒。

需要說明兩點邊界：這些數字只出現在夜間流水線單次執行的記錄裡，不是橫向評測；其中稀疏注意力一項的對照實現屬於樸素實現（30.79 TFLOPS），與生產級索引注意力不可直接對比。

3.4 媒體：DeepSeek 工程師預測 AI 寫核心 6 至 12 個月可看齊本人工作（09-16/09-17）

日期：2026-09-17　來源：NeoTeo：DeepSeek engineer forecasts AI-written GPU kernels could match his work

這是視窗內被檢索到的唯一一條主題媒體報道。文章記錄 DeepSeek 工程師 Shengyu Liu 的公開判斷：約一年間，AI 在核心工作中的角色從讀文件、讀程式碼、改缺陷推進到閱讀底層圖形彙編、分析指令停頓並最佳化運算元；他預測 6 至 12 個月內 AI 寫出的核心可達到或超過他本人的水平，人的角色轉向定義目標、解讀效能剖析結果與評判產出。文章同時把 TileLang 生態作為背景梳理：TileKernels 是純用 TileLang 寫成的核心庫，覆蓋門控、混合專家路由、量化、轉置與兩類連線運算元，環境要求為兩代 Hopper/Blackwell 級 GPU、Python 3.10 以上、PyTorch 2.10 以上、TileLang 0.1.9 以上、CUDA 13.1 以上；並引述了 NVIDIA 此前用推理模型生成注意力核心的驗證器閉環實驗（一級數值正確率 100%、二級 96%、單次閉環約 15 分鐘）作為「有限條件下已跑通」的對照。

定位上需要說清楚：這屬於預測性報道加生態綜述，不含 TileLang 本體的任何改動，也不構成對上述能力的獨立驗證；收錄的理由是它是本視窗內唯一把 TileLang 放到產業人才結構語境裡討論的公開材料，對採用方（TileKernels）的敘事有直接關聯。

3.5 採用方倉庫視窗內安靜：TileKernels、FlashQLA、TileRT 均無推送

視窗內，深度求索的 TileKernels（最後一次推送 04-23）、通義千問的 FlashQLA（08-26）、以及同為 tile-ai 組織下的 TileRT（08-13）都沒有提交。TileRT 已連續五週無更新。採用方一側的靜止狀態本視窗不構成風險訊號，但意味著今日的動態完全由上游語言與運算元庫側提供。

四、社群、教程與活動

4.1 文件站與 API 頁面由機器人再生成（09-17）

日期：2026-09-17　來源：tilelang.github.io 提交列表

主倉文件站當日由機器人按上游程式碼再生成（387 個檔案），可見的內容變化集中在矩陣乘相關的 API 頁面（詳見 1.4）。這套「上游合併、文件站當日跟進」的鏈條在本視窗運轉正常，未出現文件與程式碼脫節。

4.2 學術與社群側無新增：arXiv 與 Hacker News 視窗內零命中（09-17）

本視窗內 arXiv 檢索 TileLang 無新論文，最近一篇為 2026-07-24 的效能建模方向論文（TileSight），屬背景材料；Hacker News 近五日無主題討論命中。社群側視窗內沒有教程、教程型倉庫或活動公告類內容，本期不設增量條目。

4.3 版本節奏：主倉最新標籤仍為 v0.1.14，TileOPs 無釋出（09-02）

主倉最新標籤仍為 v0.1.14（09-02 釋出），視窗內無新標籤；TileOPs 至今沒有釋出記錄與標籤，其對外狀態由文件站與夜間快照承擔。

五、趨勢觀察

5.1 主倉重心從「加能力」轉向「把靜默錯誤改成編譯期失敗」

本視窗主倉新開的 6 個 PR 裡，有 5 個屬於同一族：隨機數預設序列錯誤、繫結 void 結果、缺初始化不報錯、型別組合不滿足卻在底層編譯器裡炸掉、以及子位元組浮點轉換的介面過時。共同點是此前都能編譯透過、跑出結果，但結果錯誤或錯誤資訊指向無關層。加上分派重構把「不具備能力的後端靜默降級」改成編譯失敗，可以判斷主倉當前的優先順序是把錯誤邊界做在語言層，而不是繼續擴運算元面。

5.2 CuTeDSL 首次出現與上游 CUTLASS DSL 版本演進的耦合傷

CuTeDSL 後端在本視窗首次暴露出被上游版本改名打穿的問題，且修復後仍有 FP8 階段卡在 libNVVM 上。這提示一個結構性風險：以第三方 DSL 為底座的後端，其穩定性取決於上游介面的穩定性，而這類後端目前又缺少庫層可讀的啟用方式與常規迴歸覆蓋。對依賴這條通路的採用方（尤其是關注 DeepSeek 系量化運算元的團隊），本視窗的進展值得跟蹤。

5.3 國產後端節奏分化：昇騰高頻迭代、海光收口、沐曦與摩爾執行緒轉維護

四家的差異在本視窗格外清楚：昇騰以每日 1925 項迴歸加運算元補齊維持推進；海光完成一次涉及程式碼生成與流水的較大改動並立即回移植到版本分支，屬「合入加收口」；沐曦在非同步複製 GEMM 入庫後轉入測試與分支維護；摩爾執行緒的回移植分支停在 v0.1.12 一線，尚未跟進主倉 v0.1.14。由此看，國產適配的整體節奏仍健康，但能把上游最新語言能力跟到什麼位置，各家已經拉開差距。

5.4 TileOPs 一面提速一面立契約，向帶契約的運算元層演進

今日重點的批矩陣乘提速（最高 1.44 倍、對官方庫不落後）與清單化改動（複合運算元、資源語義、可空輸出）同日推進，加上夜間流水線為每個提交留可復現快照（提交號、映象摘要、時鐘設定），TileOPs 的定位正在從「一批運算元實現」轉向「一批帶契約、可復現對照的運算元」。這對下游推理引擎整合是好事：契約明確比運算元數量更能降低接入成本。

5.5 本視窗的空白與風險點

空白方面：主倉預設分支在視窗後半段無新合入；採用方倉庫（TileKernels、FlashQLA、TileRT）全部靜止；學術與社群側零命中；無新版本釋出。風險方面有兩條：其一，CuTeDSL 上 DeepSeek V4 啟用量化的 FP8 階段仍未打通，組合用例還在已知失敗清單裡；其二，本視窗新開的 6 個主倉 PR 全部未合入，隨機數三缺陷與型別白名單都還在評審佇列中，修復落地時間不確定——這三點是下一期應重點核對的物件。

附錄：素材與核查說明

信源核查表

信源 核查結果
GitHub 組織推送核查 tile-ai 組織 28 個倉庫推送時間全量核查，視窗內 9 個倉庫有推送：主倉、運算元庫與其站點與夜間資料倉、昇騰、沐曦、海光、摩爾執行緒、文件站
主倉提交明細 預設分支視窗內 2 筆（均為前一期已報內容），最後提交時間為 09-17 09:57；視窗內新開 PR 6 個、缺陷單 1 個，均未合入
TileOPs 視窗內 3 筆合入（其中 2 筆為前一期已報），新開 PR 1 個；夜間資料倉為最新提交生成快照
TileOPs-nightly snapshots 分支視窗內 1 次推送；基準 1039 項中 1 項失敗（對照實現簽名問題）、正確性 1117 項全透過
tilelang-ascend 視窗內 4 筆提交（前一期已報）加 1 份每日測試報告（1925 項全透過）
tilelang-hygon 主分支 1 筆合入，回移植分支 2 筆，開發分支 1 筆；改動含地址重基與非同步流水接管
tilelang-metax 預設分支視窗內 2 筆（前一期已報），無新提交
tilelang-musa 預設分支無視窗內提交，推送落在 v0.1.12 回移植分支；主分支最後提交為 09-11
tilelang-mlir-ascend / TileFoundry / DeepStack / tilescale 視窗內均無推送，最近一次分別為 09-16 / 09-15 / 09-15 / 08-25
TileRT 視窗內無推送，最近一次 2026-08-13，連續五週無更新
採用方倉庫 TileKernels / FlashQLA 視窗內無推送，最近一次分別為 2026-04-23 / 2026-08-26
Google News RSS（中英文多組查詢） 主題詞、元件名與團隊片語合查詢後視窗內僅 1 條可用命中（NeoTeo 報道），其餘為同名噪音與股票行情稿，已剔除
Hacker News 近五日主題詞零命中，命中項均為同名詞條
arXiv 視窗內無新論文，最近一篇為 2026-07-24 的效能建模論文
文件站與標籤 文件站當日再生成（387 個檔案）；主倉最新標籤仍為 v0.1.14（09-02），TileOPs 無標籤與釋出

完整信源清單

QwenLM/FlashQLA — https://github.com/QwenLM/FlashQLA