調研視窗：過去 24 小時（2026-09-18 07:00 ~ 2026-09-19 07:00，北京時間）。本期為常規日更視窗，與上一期無重疊。 信源：GitHub（tile-ai 組織 28 個倉庫推送時間全量核查，視窗內 6 個倉庫有推送；主倉 2 筆合入與 5 個新開 PR 逐條複核，含 PR 正文、改動檔案數與增刪行數；TileOPs 5 筆合入與 1 個新開 PR；昇騰倉每日迴歸報告、CI 改動與 2 筆提交；TileOPs-nightly 夜間快照的基準與正確性 XML 全量解析；Sunrise 後端發行版倉庫與分支核查）、Google News RSS 中英文多組查詢（走代理）、Hacker News、arXiv、採用方倉庫（TileKernels / FlashQLA）

本期索引

  • 今日重點：主倉新開 CUDA Tile IR 執行後端，134 個檔案、約 3.6 萬行新增（09-18）
  • 一、核心專案進展
    • 1.1 符號化迴圈佈局的單射性證明恢復，混合靜態與動態 T.Parallel 迴歸修復（09-18）
    • 1.2 ROCm CI 接入可移植示例校驗，反向印證 ROCm 通路進入收斂期（09-18）
    • 1.3 視窗內主倉新開五個 PR：Tile IR 後端、複製寬度鉗制、SM100 起 256 位訪存、GLM-5.3 與 KDA 示例（09-18/09-19）
    • 1.4 TileOPs 一日合入五筆：分派與調的解耦、SM90 形狀補齊、分頁 KV 助手外移、稀疏 MLA 越界收口、清單複合運算元（09-18）
    • 1.5 TileOPs 新開 FP8 批矩陣乘轉置核心，正面追趕對照實現（09-18）
  • 二、多後端適配（昇騰 / Sunrise / 沐曦 / 海光 / 摩爾執行緒）
    • 2.1 昇騰：每日迴歸 1936 項全透過，並引入多裝置測試分片（09-18/09-19）
    • 2.2 昇騰：對比運算元文件補齊 dtype 覆蓋，基準指令碼緩衝區生命週期修復（09-18）
    • 2.3 Sunrise 後端發行版：面向 S2 加速器的 TANG 後端進入 0.1.14 候選（09-16/09-18）
    • 2.4 沐曦、海光、摩爾執行緒：視窗內無新提交，維持版本分支維護（09-17）
  • 三、生態與採用方
    • 3.1 FlashQLA 結束靜默：同日合入三筆，含 SM120 反向融合核心（09-18）
    • 3.2 TileOPs 夜間基準 1040 項零失敗，正確性 1118 項全透過（09-18）
    • 3.3 TileKernels 與 TileRT 視窗內無推送（04-23、08-13）
    • 3.4 社群工具：TileSight 效能分析文件倉上線，對應 arXiv 效能模型論文（09-18）
  • 四、社群、教程與活動
    • 4.1 組織文件站視窗內有一次站點部署，預設分支無內容變更（09-18）
    • 4.2 媒體與學術側視窗內零新增（09-19）
    • 4.3 版本節奏：主倉仍為 v0.1.14，各適配倉標籤未動（09-11）
  • 五、趨勢觀察
    • 5.1 第二條 NVIDIA 側執行通路成形：從 CUDA 原始碼生成到 CUDA Tile IR
    • 5.2 主倉繼續把靜默語義錯誤前移為編譯期失敗
    • 5.3 TileOPs 效能與契約雙線並行，夜間基準轉綠
    • 5.4 採用方一側回暖，FlashQLA 單日三筆合入
    • 5.5 後端矩陣擴張：從昇騰一極到多家後端發行版並存
  • 附：素材與核查說明

今日重點：主倉新開 CUDA Tile IR 執行後端，一次提交 134 個檔案

日期：2026-09-18　來源：tilelang #3247 新增 CUDA Tile IR 執行後端

本視窗最重的一筆內容出現在主倉的評審佇列裡：一條名為 tileir 的執行後端被提上 PR，改動規模為 134 個檔案、新增約 35829 行、刪除 111 行，由 0xtaruhi 提交，建立於北京時間 09-18 20:40，視窗內持續更新。

它做的事情是把 TileLang 程式下沉到 NVIDIA 的 CUDA Tile IR，再經由 cuTile 執行時裝載彙編產物啟動，目標版本組合為 CUDA Tile IR 13.4 繫結、tileiras 13.4、cuTile 1.5。與現有 CUDA 後端（直接生成 C/CUDA 原始碼交給 nvcc）相比，這是一條語義層更靠上的新通路：TileLang 的行為直接落到 Tile IR 上，編譯與最佳化交給 NVIDIA 自己的瓷磚級中間表示。

配套改動同樣成體系，說明這不是原型而是按產品化標準在寫：

  • 後端接入 JIT 編譯、核心快取與自動調優三處，tilelang/jit/adapter/tileir、tilelang/cache、tilelang/autotuner 均有改動；帶型別的 IR、下沉與 pass 核心放在 tilelang/tileir；
  • 增加一個 pass 配置項，用於在 Tile IR 啟動物化之前（含從快取恢復的路徑上）仍執行既有的源語言語義檢查，並保留可配置的關閉開關；
  • 恢復新工具鏈下的完整示例覆蓋，其中一項具體工作是把手寫宿主側 pybind 繫結與 nvcc 隔離，使擴充套件標頭檔案在 CUDA 13.4 下能幹淨編譯；
  • 補上兩篇文件（編譯器內部與程式設計指南各一）與一條專門構建固定版本 TileIR 繫結的 CI 作業。

作者給出的測試計劃覆蓋單測與下沉用例、JIT 與快取與調優鏈路、以及全部示例的迴歸。需要說明的是，該 PR 截至視窗結束仍處未合入狀態，改動規模大、目標工具鏈版本新，最終能否落入主線取決於評審；本期把它列為重點，依據是它在視窗內貢獻了最大一筆實質工程內容，且指向 TileLang 的後端路線選擇。

一、核心專案進展

視窗總覽：主倉預設分支視窗內只有 2 筆合入（09-18 14:56 與 09-19 01:56 各一筆），但評審佇列活躍——視窗內新開 5 個 PR，全部處於未合入狀態。也就是說，主倉本視窗的重心在「提交新通路 + 提交防禦性修復」，合入節奏偏慢。TileOPs 一側相反，單日合入 5 筆。

1.1 符號化迴圈佈局的單射性證明恢復，混合靜態與動態 T.Parallel 迴歸修復（09-18）

日期：2026-09-18　來源：tilelang #3233 恢復符號化迴圈佈局的單射性證明／關聯缺陷單 #2906

主倉本視窗唯一一筆語義修復，修的是一個從 v0.1.12 到主線之間的迴歸，由 sepcnt 提交，4 個檔案、+198/-13，09-18 14:56（北京時間）合入。

觸發場景很具體：當 T.Parallel 迭代空間是靜態與動態的混合形態（例如 (16, n) 且 n 取 T.dynamic）時，佈局帶有填充出來的尾部，其迴圈佈局是單射但非雙射，定義域無法列舉。此前這條路上的判定會退回到「不檢查」，而中間某次改動換成了真正去證明，卻又無法處理符號化步長，於是這類核在主線直接報「找不到可用佈局」——在 v0.1.12 上是能跑的。

修復恢復了對符號化填充迴圈佈局的單射性證明：嘗試從待檢迭代對映構造逆對映，再在定義域上證明往返相等。作者在 PR 裡把兩種判定手段的盲區差異寫明在呼叫點，兩者都保留——這意味著這不是簡單回退舊行為，而是補上了正確性論證。

第二個獨立部分是拒絕在符號化共享記憶體瓷磚上附加布局，與前一部分同批提交，屬同一作者在評審中被重新劃定範圍後的結果。

1.2 ROCm CI 接入可移植示例校驗，反向印證 ROCm 通路進入收斂期（09-18）

日期：2026-09-19　來源：tilelang #3165 在 CI 中執行可移植示例校驗

09-19 01:56（北京時間）合入，內容是在 ROCm CI 作業里加入一份小型白名單，直接跑示例自身的正確性路徑，而不是在測試目錄下維護一套重複用例。白名單覆蓋四類：Seer 注意力、通用 Top-K、稀疏多頭潛在注意力前向、基於張量的分組矩陣乘。

這條改動的意義在於覆蓋面來源的變化：此前 AMD 側的驗證由專門維護的測試副本承擔，現在是「示例即測試」。當一個後端開始用示例本身當迴歸資產，通常說明該後端的示例已經穩定到可以當作基準，維護者不必再為它單獨鋪一套測試。

1.3 視窗內主倉新開五個 PR：Tile IR 後端、複製寬度鉗制、SM100 起 256 位訪存、GLM-5.3 與 KDA 示例（09-18/09-19）

日期：2026-09-18 至 2026-09-19　來源：#3246 複製寬度鉗制／#3247 Tile IR 後端／#3248 256 位訪存／#3249 KDA 解碼示例／#3250 GLM-5.3 壓縮

除今日重點介紹的 Tile IR 後端外，視窗內另有四條新開條目，按建立時間排列：

其一，#3246（09-18 15:39）把 T.copy 與 T.async_copy 的合併寬度上限鉗制到實際可達的向量寬度，取代原來的致命日誌。此前傳入不支援的寬度會直接以 LOG(FATAL) 終止程序，改動後鉗制為可用值繼續編譯。這與前一期的「把靜默錯誤前移成顯式失敗」方向相反但互補——這裡是把「直接崩掉」改成「降級並繼續」，判定標準是寬度上限屬於能力約束而非使用者語義錯誤。

其二，#3248（09-19 01:35）修正 256 位全域性訪存的適用目標：僅在 SM100 及更新架構且 CUDA 12.9 以上才發出該寬度，舊架構退回 128 位通路，並補充了舊架構上的負向測試。這一條與前一期的原子向量寬度規劃屬同一類工作，都是在新的寬向量能力上補齊從屬條件。

其三與其四均在 ROCm 方向：#3249（09-19 02:23）新增帶安全門控的 KDA 解碼示例，用 TileLang 寫打包解碼核，就地更新按槽位索引的迴圈狀態池，並補上輸出與狀態一致性、多步、空狀態索引、亂序槽位、可配置邊界等正確性覆蓋；#3250（09-19 06:42）新增 GLM-5.3 的 k 池壓縮與快取寫入，含逐維 softmax 池化、歸一化 Hadamard-128 變換與逐向量 FP8 量化，並把 FP8 的 K 值與 FP32 縮放寫入呼叫方持有的分頁快取。

值得注意的是，這幾條 ROCm 方向的新內容都是面向具體模型的具體運算元（GLM-5.3 的壓縮注意力、KDA 門控線性注意力的解碼態），而不是籠統的後端能力補齊。這說明 AMD 側的推進已經從「後端能用」轉到「新模型的原生運算元在這裡也要有」。

1.4 TileOPs 一日合入五筆：分派與調的解耦、SM90 形狀補齊、分頁 KV 助手外移、稀疏 MLA 越界收口、清單複合運算元（09-18）

日期：2026-09-18　來源：#2147 清單複合運算元／#2149 稀疏 MLA 越界／#2150 分頁 KV 助手外移／#2151 SM90 形狀補齊／#2152 分派與調優解耦

TileOPs 在本視窗合入 5 筆，性質分成三類：

契約類——#2147（08:36 合入）讓運算元清單能夠描述複合運算元，這是上一期以未合入狀態報道過的條目，本視窗落地。它同時收掉了此前散落在多處的重複推導邏輯、支援可空輸出。上一期已詳細展開其問題清單，此處不重複。

分派正確性——#2152（19:27 合入）把「調優請求」與「實現選擇」解耦。此前 tune 這個引數只應影響核心如何構建，卻被兩個特化實現當作分派條件使用，導致同一個形狀僅僅因為呼叫方要求調優就選到不同實現，其中批矩陣乘模板直接拒絕調優請求。修復後選擇器核心與調優無關。

盲區補齊——#2151（15:42 合入）補上 SM90 上無人負責的形狀區間：基礎 GEMM 核心把整個 SM90 排除在外，而通用 GEMM 核心只服務 TMA 能定址的呼叫，兩者相減留下一個空檔，具體是運算元為半精度且 K 不是 8 的倍數、同時 M 大於 2 的情形。修復讓基礎核心接下這部分。

正確性收口——#2149（13:02 合入）修兩處：稀疏多頭潛在注意力解碼的聚集操作此前只檢查因果上界，當 top-k 槽位被填充為序列長度或 -1 時會讀到快取並未持有的行，修復把上界鉗制到序列長度減一併對每個索引做非負檢查；另一處是讓分頁注意力在碎片化佈局下的計時可信。

結構性重構——#2150（13:22 合入）把五個分頁 KV 快取輔助函式從分組查詢注意力模組中移出。這五個函式（交錯塊表構造、碎片塊表構造、分頁快取取行、按邏輯序列填充分頁快取、單位快取縮放構造）都不專屬於分組查詢注意力，此前多頭注意力模組不得不反向依賴它，現獨立成層。

五筆合入的共同點是：TileOPs 當前的主要工程量不在「新增運算元」，而在運算元增多之後暴露出來的分派一致性、模組邊界與記憶體安全。

1.5 TileOPs 新開 FP8 批矩陣乘轉置核心，正面追趕對照實現（09-18）

日期：2026-09-18　來源：TileOPs #2153 用合併訪存核心轉置 FP8 的 B 運算元

視窗內 TileOPs 唯一的新開 PR（09-18 16:18 更新，未合入）。背景寫得很直白：FP8 批矩陣乘前向運算元在 trans_b=False 的 5 個用例裡有 4 個輸給對照實現，最差一檔落後到 0.34 倍。作者先複核了對照實現與 fp32 參考的一致性，確認對照沒有作弊，然後選擇把 B 運算元的轉置改成一個合併訪存的核心來做，而不是繼續在共享模板上打補丁。

這條與上一期的批矩陣乘提速（改用共享 GEMM 模板、H200 上最高 1.44 倍）是同一戰線的延續：批矩陣乘在標準形狀上已經追平甚至反超對照，剩下的短板集中在資料型別變體（FP8）與佈局變體（需要轉置 B）這些邊角。是否影響共享模板的通用性，需等合入後看夜間基準的迴歸結果。

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

視窗總覽：本視窗的國產與第三方後端格局出現一個結構性變化——除既有的昇騰、海光、沐曦、摩爾執行緒四家之外，tile-ai 組織下已存在一個面向新加速器的後端發行版倉庫（Sunrise），並已推進到候選釋出分支。四家既有後端中，視窗內只有昇騰有提交。

2.1 昇騰：每日迴歸 1936 項全透過，並引入多裝置測試分片（09-18/09-19）

日期：2026-09-19　來源：tilelang-ascend 每日測試報告 #1813／CI 多裝置測試分片 #1812

昇騰側的每日定時測試在北京時間 09-19 05:52 出報告：1936 項全部透過，失敗 0 項，透過率 100%。對照前一日（09-18 05:46 的 1925 項）與再前一日（09-17 的 1919 項），用例總數在兩日內淨增 17 項且保持全綠——這是「上游持續併入新能力、昇騰側迴歸仍不破」的直接證據。

同一視窗內，該倉另開一條 CI 改動（#1812，標題為新增通用的多裝置測試分片），建立於 09-18 16:31、當日 19:22 仍在更新，未合入。用例數持續增長而單機迴歸時間會隨之拉長，分片是順勢而為。

2.2 昇騰：對比運算元文件補齊 dtype 覆蓋，基準指令碼緩衝區生命週期修復（09-18）

日期：2026-09-18　來源：tilelang-ascend #1602 更新對比運算元文件並補 dtype 覆蓋／#1779 修復基準指令碼的緩衝區返回令牌生命週期

視窗內昇騰倉的兩筆提交都落在 09-18 15:10 與 15:31（北京時間）：一筆更新比較運算元的文件字串、補上資料型別覆蓋測試與 API 文件；另一筆修 bench_sfa 中累加器與輸出臨時緩衝的返回令牌生命週期，避免緩衝區在使用完成前被回收。兩筆都不是運算元能力擴張，而是把已有運算元的文件、測試覆蓋與基準指令碼的穩健性補齊——與 2.1 的迴歸規模增長放在一起看，昇騰側當前處於「能力已鋪開、重點轉向質量與可維護性」的階段。

2.3 Sunrise 後端發行版：面向 S2 加速器的 TANG 後端進入 0.1.14 候選（09-16/09-18）

日期：2026-09-18　來源：tile-ai/tilelang-sunrise 倉庫

tile-ai 組織下有一個此前未被本日報點到的倉庫進入視窗內的推送列表：tilelang-sunrise，建倉於 2026-08-26。其自述定位是 TileLang 的 Sunrise S2/TANG 後端發行版——Sunrise S2 是面向大模型推理的國產 GPGPU，TANG 為其編譯與執行時棧（倉庫要求 TANG Runtime 與配套的 torch 後端包、匹配的 Triton 包）。提供的運算元示例覆蓋矩陣乘、反量化矩陣乘、FlashAttention、Flash 線性注意力、Flash 多頭潛在注意力解碼與原生稀疏注意力，即與主倉保持同一套示例面。

進展狀態：倉庫在視窗內有推送（09-18 11:03），但預設分支最後提交停在 09-04；承載釋出準備的候選分支上，最新一筆提交是 09-16 的版本更新，把版本號推到 0.1.14+sunrise.1.1.0，即已經跟到主倉 v0.1.14 一線。倉庫另有一批待處理的依賴升級 PR 與一條 CI 分支。

判讀要點：這是「後端發行版」而非「補丁分支」的形態——獨立建倉、獨立發版號（在主倉版本號後加字尾）、獨立 CI。它與海光的 feat/hcu-... 分支、摩爾執行緒的加字尾回移植分支構成三種不同的適配組織方式。由於該倉庫自述與示例與主倉同構，可視為 TileLang 在 NVIDIA/AMD/昇騰之外的又一條推理加速器通路正在進入可釋出狀態。

2.4 沐曦、海光、摩爾執行緒：視窗內無新提交，維持版本分支維護（09-17）

日期：2026-09-17　來源：tilelang-metax／tilelang-hygon／tilelang-musa

三家適配倉在 24 小時視窗內均無提交，最近一次推送分別落在 09-17 17:38、09-17 20:25、09-17 03:47（北京時間），均在視窗之前，屬上一期已報內容：沐曦的非同步複製矩陣乘與其測試修復、海光的多級儲存地址重基與非同步流水合入、摩爾執行緒的 MUSA 5.3.0 文件。三家的版本標籤視窗內均未更新，最新標籤仍分別是沐曦無釋出、海光無釋出、摩爾執行緒 v0.1.14+musa.1（09-11）。

三、生態與採用方

3.1 FlashQLA 結束靜默：同日合入三筆，含 SM120 反向融合核心（09-18）

日期：2026-09-18　來源：FlashQLA #34 SM120/121 反向融合核心／#41 SM100 KKT 解算佔用率／#44 變長尾塊的非同步流水

上一期報告裡，「採用方一側視窗內安靜」中明確記到 FlashQLA 無推送；本視窗它同日合入三筆，且時間高度集中在北京時間 09-18 15:51 至 15:53，是一次批次收口。

三筆的內容分別是：

  • 新增硬體支援（#34）：為分塊門控 delta 規則補上 SM120/SM121 的反向融合核心。實現大體沿用早前在 Hopper 上的流水，主要差異是共享記憶體歸約策略——SM120 的共享記憶體上限較低，歸約要按這個約束重新設計。
  • 佔用率調優（#41）：給固定長度與變長兩種 KKT 解算核加最小每流多處理器駐留塊數標註，目標是在每個流多處理器上駐留八個 128 執行緒的執行緒塊，KT 數學、佈局、啟動網格與公開介面均不變。
  • 正確性修復（#44）：變長打包場景下，最後一組不足 64 行的瓦片此前會越讀進下一條序列。修復保留完整瓦片的直接記憶體訪問快路徑，對不完整尾塊改用帶謂詞的零填充非同步複製，並把尾塊暫存拆分到多條通道。

這兩類改動指向同一件事：FlashQLA（通義千問側基於 TileLang 的門控線性注意力實現）的工程重心正在從「新架構適配」轉向「同一架構上的佔用率與邊界正確性」。三筆集中合入也說明其維護節奏是批次評審而非逐筆合併。

3.2 TileOPs 夜間基準 1040 項零失敗，正確性 1118 項全透過（09-18）

日期：2026-09-18　來源：TileOPs-nightly 快照提交／快照環境後設資料

夜間流水線在本視窗為 TileOPs 的 4c5b441f（即 1.4 中「分派與調優解耦」那筆合入）生成了快照，含基準結果、正確性結果與環境後設資料三件。解析兩份結果檔案得到的讀數：

  • 正確性：1118 項，失敗 0，跳過 2；
  • 基準：1040 個用例，失敗 0，跳過 3。

與前一日快照（正確性 1117 項全透過、基準 1039 項中 1 項失敗）相比，用例數各增 1，且昨日唯一那項基準失敗已消失——昨天失敗的是分組查詢注意力預填充分頁核心在 softcap 50 配置下的用例，報錯來自對照基線實現的函式簽名不匹配（缺少引數）、並非 TileOPs 自身核心出錯。本日轉綠說明該對照側問題已被處理。

環境後設資料把可復現要素固定得比較完整：H200、CUDA 13.2、驅動 595.71.05、功耗上限 700 瓦、單流多處理器時鐘 1500 兆赫茲（上限 1980）、記憶體時鐘 3201 兆赫茲、映象按其內容標識記錄、以及全量依賴版本（其中 TileLang 為該次提交構建的 0.1.11 加代號版本、PyTorch 2.13.0）。基準用例面覆蓋解碼類運算元（稀疏注意力解碼、多頭潛在注意力解碼、分組查詢注意力變體）與 27 項批矩陣乘用例，後者正是 1.5 中對照實現被超越的戰場。

3.3 TileKernels 與 TileRT 視窗內無推送（04-23、08-13）

視窗內，深度求索的 TileKernels 與 tile-ai 組織下的 TileRT 都沒有提交，最近推送時間仍分別為 2026-04-23 與 2026-08-13。TileRT 已連續六週靜止。採用方一側本視窗的動態全部來自 FlashQLA。

3.4 社群工具：TileSight 效能分析文件倉上線，對應 arXiv 效能模型論文（09-18）

日期：2026-09-18　來源：tilelang4tilesight-doc 倉庫／arXiv 2607.22432 TileSight

視窗內出現一個由社群成員新建的文件倉，主題是把 TileLang 的效能分析接到 TileSight 工具鏈上：從 Python 與高層 TIR 中提取語義、工作量與依賴資訊，接入 TileSight 的快取與流水分析介面，再用執行時觀測生成獨立報告與聯合預測。倉庫給出四篇中文文件的閱讀順序（模型與執行時兩條路徑的整體方案、TileSight 的階段與前端介面與流水分析、快取模組、效能分析功能與協議對照索引），並把效能問題分成六類：流水瓶頸、跨層級搬運異常、快取利用異常、計算與訪存重疊失敗、負載不均等；文件明確要求報告區分「模型預測」「執行時觀測」「證據不足」三種結論強度。

與之對應的學術側背景是 arXiv 上一篇 2026-07-24 的效能建模論文（從核心到叢集的瓷磚級分析式 GPU 效能模型），是 TileLang 主題下最近一篇預印本。兩條材料合起來說明：圍繞 TileLang 的效能可解釋性正在形成獨立於語言本體與運算元庫的第三條社群線索。該倉庫為個人專案、尚無星標，收錄依據是它是本視窗內社群側唯一實質新增。

四、社群、教程與活動

4.1 組織文件站視窗內有一次站點部署，預設分支無內容變更（09-18）

日期：2026-09-18　來源：TileOPs.github.io 倉庫

TileOPs 文件站在視窗內有推送記錄（09-18 08:00），但其預設分支在視窗內沒有新提交，判斷為站點部署類動作而非內容更新。主倉文件站在本視窗沒有推送，與前一日的機器人再生成（387 個檔案）形成對照——文件站跟隨上游程式碼的節奏本來就是脈衝式的。

4.2 媒體與學術側視窗內零新增（09-19）

主題的 Google News RSS 中英文多組查詢在本視窗零新增命中：英文側近 7 天僅一條與主題強相關的報道，即前一期已收錄的關於 DeepSeek 工程師評估 AI 編寫核心能力的那篇，其釋出時間在前一視窗內，本期不重複；中文側針對元件名、國產加速器與運算元核心的組合查詢全部無視窗內結果。Hacker News 側近五日內無主題討論命中（檢索到的 TileOPs、tile 類關鍵詞命中項均為無關話題）。arXiv 側視窗內無新預印本。

4.3 版本節奏：主倉仍為 v0.1.14，各適配倉標籤未動（09-11）

主倉最新標籤仍為 v0.1.14（09-02 釋出），視窗內無新標籤；TileOPs 至今無釋出記錄；昇騰倉最新標籤為 TileLang-ascend v0.1.2.000-release（09-09）；摩爾執行緒倉最近標籤為 v0.1.14+musa.1（09-11）。後兩者的釋出節奏都與主倉的小版本對齊，當前都停留在 v0.1.14 一線，尚未跟隨主線推進到新版本。

五、趨勢觀察

5.1 第二條 NVIDIA 側執行通路成形：從 CUDA 原始碼生成到 CUDA Tile IR

本期最值得追蹤的是 #3247 的開出。TileLang 此前的 NVIDIA 通路是「下沉到帶瓷磚語義的中間表示、再生成 CUDA 原始碼、最後交給 nvcc」，新通路改為「下沉到 CUDA Tile IR、由 NVIDIA 的瓷磚級工具鏈編譯最佳化、經 cuTile 執行時裝載」。兩條通路並存意味著：其一，TileLang 的抽象層級與 NVIDIA 自家的瓷磚級抽象開始正面接壤，誰承擔排程與佈局決策會變成長期議題；其二，一旦 Tile IR 通路成熟，TileLang 在 NVIDIA 平臺上的價值主張會從「更好的程式碼生成」部分轉向「更完整的程式表達與跨後端一致性」。這條 PR 的規模（一個後端從編譯到快取到調優再到文件與 CI 齊全）也說明它不是實驗性分支。

5.2 主倉繼續把靜默語義錯誤前移為編譯期失敗

延續上一期的觀察，本視窗主倉的兩筆合入裡有明確的一筆（1.1 的佈局證明恢復）屬於「把悄悄出錯變成明確報錯」，加上前三期累計的隨機數診斷、不支援型別組合攔截、稀疏後設資料形狀拒絕，已經把「編譯期失敗優先」變成主倉穩定的工程取向。本期新增的資訊是這條原則的邊界：1.3 中把複製寬度的致命日誌改成鉗制降級，說明維護者在區分「使用者語義錯誤」（應當失敗）與「能力約束」（應當降級）——這不是原則鬆動，而是把判據寫清楚了。

5.3 TileOPs 效能與契約雙線並行，夜間基準轉綠

TileOPs 本視窗 5 筆合入裡，3 筆是分派、模組邊界與記憶體安全，1 筆是清單契約，只有 1 筆（新開的 FP8 批矩陣乘）是純效能。與夜間基準從「1 項失敗」轉為「零失敗」放在一起看，它的當前狀態是：效能基線穩定且已能壓過對照實現的主要形狀，因此工程資源轉向多運算元共存之後的一致性與契約。這是運算元庫成熟期的典型訊號——運算元越多，分派與清單的正確性對上層越重要。

5.4 採用方一側回暖，FlashQLA 單日三筆合入

上一期「採用方安靜」的判斷在本期被推翻：FlashQLA 同日合入三筆，覆蓋新架構（SM120/SM121 反向融合核心）、佔用率調優與變長尾塊正確性。這提示採用方倉庫的更新是脈衝式的——評審積壓到一定量後批次合入，單日或數日的靜默不構成趨勢。日報層面需要避免把單期靜默解讀為採用停滯。

5.5 後端矩陣擴張：從昇騰一極到多家後端發行版並存

本視窗發現的 Sunrise 後端發行版給出了一個新的格局讀數：TileLang 的後端生態已不止於「主倉內建的後端」與「廠商在組織內開的適配倉」兩種形態，還出現了帶獨立版本號與 CI 的後端發行版。目前已識別的適配形態共有三類——昇騰的獨立適配倉（多分支，含每日迴歸）、海光的特性分支與加字尾回移植分支、摩爾執行緒的版本對齊回移植分支，加上 Sunrise 的獨立發行版。形態差異本身反映了各廠商對 TileLang 的投入深度與產品化程度，是判斷國產加速器對 TileLang 生態依賴度的一個可用指標。

5.6 本視窗的空白與風險點

三點需要標註：其一，主倉視窗內只合入 2 筆，且其中一筆是回退型修復（恢復 v0.1.12 的行為），主線淨增能力有限；其二，#3247 這類超大改動一旦合入，對既有 CUDA 通路與快取格式的迴歸面需要額外觀察，本期尚無證據；其三，本視窗未見任何新標籤或釋出，主倉自 09-02 的 v0.1.14 後已連續兩個多星期未發版，而評審佇列在持續累積。

附：素材與核查說明

信源核查表

信源 核查結果
tile-ai 組織（28 倉庫） 視窗內 6 個倉庫有推送：tilelang、TileOPs、TileOPs-nightly、tilelang-ascend、tilelang-sunrise、TileOPs.github.io
主倉 tilelang 預設分支 2 筆合入（#3233、#3165），新開 5 個 PR（#3246 至 #3250），無新標籤
主倉夜間/組織倉庫 TileOPs-nightly 為 TileOPs 提交生成快照；TileRT、TileFoundry、tilescale、DeepStack、tilelang-puzzles 視窗內無推送
國產後端四家 僅昇騰視窗內有提交與迴歸報告；沐曦、海光、摩爾執行緒最近推送在視窗之前
第三方/新增後端 Sunrise 後端發行版倉庫視窗內有推送，候選分支版本推到 0.1.14+sunrise.1.1.0
採用方 FlashQLA 合入 3 筆；TileKernels 無推送
Google News RSS（中英多組查詢，走代理） 視窗內零新增；元件名與技術片語合查詢同樣無視窗內結果
Hacker News 視窗內無主題命中，關鍵詞噪音已剔除
arXiv 視窗內無新預印本，最近一篇為 2026-07-24 的效能建模論文
文件站 TileOPs 文件站有站點部署動作，預設分支無內容變更

完整信源清單

.com/QwenLM/FlashQLA/pull/41>