調研視窗：過去 24 小時（2026-09-19 07:00 ~ 2026-09-20 07:00，北京時間）。本期為常規日更視窗，與上一期無重疊。 信源：GitHub（tile-ai 組織 28 個倉庫推送時間全量核查，視窗內 3 個倉庫有推送；主倉 3 筆合入與 5 個新開 PR 逐條複核，含 PR 正文、改動檔案數與增刪行數；TileOPs 5 筆合入與 1 個新開 PR；GLM-5.3 分頁 k 池系列 4 個 PR 的依賴鏈、模型契約與驗證記錄；TileOPs-nightly 快照的基準與正確性結果檔案全量解析及環境後設資料；昇騰每日迴歸報告；各適配倉與採用方倉庫推送核查）、Google News RSS 中英文多組查詢（走代理）、Hacker News、arXiv

本期索引

  • 今日重點：ROCm 側 GLM-5.3 稀疏注意力 k 池全鏈路在 24 小時內成鏈，四筆合計約 9.8 千行新增（09-19/09-20）
  • 一、核心專案進展
    • 1.1 主倉：Metal 後端補上 32 位整數原子加，計數器類可移植核心不再卡在程式碼生成（09-19）
    • 1.2 主倉：256 位全域性訪存限定 SM100 及更新架構，舊架構退回 128 位（09-19）
    • 1.3 主倉：測試套件一次減重 509 行，快數學斷言改用真參考實現（09-20）
    • 1.4 主倉評審佇列：資料型別攔截 PR 有更新，Metal 行數 PR 關閉未合入，Tile IR 後端為草稿狀態且無更新（09-19/09-20）
    • 1.5 TileOPs：FP8 批矩陣乘轉置核心合入，H200 上最高 4.66 倍提速（09-19）
    • 1.6 TileOPs：GEMM 核心按服務區域重新命名併合並 GEMV 兩帶（09-19）
    • 1.7 TileOPs 新開：分組 GEMM 尾塊分塊，正面追趕 CUTLASS 分組核心（09-19）
  • 二、多後端適配（昇騰 / Sunrise / 沐曦 / 海光 / 摩爾執行緒）
    • 2.1 昇騰：每日迴歸 1936 項全透過，連續第二日（09-20）
    • 2.2 沐曦、海光、摩爾執行緒、Sunrise：視窗內無新提交（09-17/09-18）
  • 三、生態與採用方
    • 3.1 夜間快照：基準 1040 項與正確性 1118 項零失敗（09-19）
    • 3.2 基準可信度治理：8 行頻寬異常與同日三筆修復（09-19/09-20）
    • 3.3 採用方：TileKernels 與 FlashQLA 視窗內無推送（09-18）
    • 3.4 遷移線：稠密 Gated DeltaNet 預填充遷移 PR 更新（09-19）
  • 四、社群、教程與活動
    • 4.1 文件站：TileOPs 文件站一次站點部署，站點內容未變（09-19）
    • 4.2 媒體與學術側：視窗內零新增（09-20）
    • 4.3 版本節奏：主倉仍為 v0.1.14，各適配倉標籤未動（09-02）
  • 五、趨勢觀察
    • 5.1 ROCm 線：從「後端可用」到「新模型原生運算元成鏈」
    • 5.2 TileOPs 把一天投向度量體系：先讓判定可信，再談快慢
    • 5.3 主倉本視窗的三筆合入全是補課型，增量在評審佇列
    • 5.4 後端矩陣的靜默面擴大：僅昇騰保持日更迴歸
    • 5.5 空白與風險點
  • 附：素材與核查說明

今日重點：ROCm 側 GLM-5.3 稀疏注意力 k 池全鏈路在 24 小時內成鏈

日期：2026-09-19 至 2026-09-20　來源：tilelang #3251 GLM-5.3 k 池解碼尾部維護／#3253 分頁 k 池 logits／#3254 k 池 Top-K 變換／#3255 分頁 k 池融合選擇

上一視窗（09-18 晚間）ROCm 方向開出 #3250，為 GLM-5.3 做 k 池壓縮與快取寫入；本視窗同一位作者在同一天內連開四筆，把這條鏈路從解碼尾部維護一路補到融合選擇，四筆合計新增約 9767 行、改動 40 個檔案（逐筆 7、9、11、13 個檔案）。四筆均標註為堆疊依賴（stacked），其中 #3255 自述「包含 #3250 至 #3254 的提交，直至各自合入」——作者是按一條完整交付鏈來組織評審的。截至視窗結束，四筆均未合入。

這條鏈服務的物件是已釋出配置的 GLM-5.3-Flash：index_kpool=4、index_topk=2048、index_head_dim=128、index_n_heads=32。按此契約，長行路徑選擇 512 個四 token 池，展開為 2048 個歷史 token，再補上不足三個 token 的尾部——這就是稀疏注意力預算在快取側的具體形態。

四筆各自的分工：

  • #3251（09-19 08:31 建立）：解碼尾部維護。預填充核為每個請求播種滾動的 BF16 尾部，按序批次解碼（普通與推測解碼兩種路徑），池在收口 token 到達時壓縮寫回；校驗尾部歸屬、位置序、填充與快取寫唯一性。
  • #3253（09-19 13:10 建立）：分頁 logits。在壓縮 k 池快取上做分頁 FP8 MQA 打分：按池施加縮放、逐查詢頭 ReLU、用呼叫方提供的 FP32 頭權重歸約；支援按請求的池區間與頁錶行歸屬，並在啟動前拒絕非法形狀、型別、區間與頁行。
  • #3254（09-19 14:06 建立）：Top-K 變換。複用 ROCm 側安全的 tl_topk 選擇器，按 2048 token 預算選出 512 池並展開為邏輯 token 索引；短行直接列舉、長行走基數選擇；支援恆等、直接 token 表與不規則偏移三種輸出對映。
  • #3255（09-20 00:21 建立）：融合選擇。一次啟動完成打分、基數選擇與 token 索引變換；直接消費生產形態的交錯 uint8 快取佈局（FP8 鍵後接 FP32 縮放），把第一輪基數直方圖折進打分階段；為圖重放的穩定性提供呼叫方自有的 FP32 暫存與 INT32 輸出緩衝。

驗證以 exact-head CI 為準：ROCm 7.2 gfx942 上， #3251 報 2423 項透過、1852 項跳過，六例聚焦解碼尾部用例全過；#3255 報 2435 項透過、1816 項跳過，六例融合選擇器用例全過。測試面覆蓋長行與短行、已釋出的 2048 幾何、零歷史與超過 4096 個等分場景。

判讀：把 #3249（KDA 解碼示例）、#3250 與本視窗四筆連起來看，AMD 側的推進已從「把後端跑起來」切換為「新模型的原生運算元這裡也要有」，且採用堆疊 PR 的組織方式，把整條稀疏注意力路徑當作一個交付物在推。

一、核心專案進展

視窗總覽：主倉預設分支 3 筆合入，全部為補課型（補能力、修適用面、減測試冗餘）；評審佇列新開 5 個 PR，其中 4 個屬今日重點的 ROCm 系列。TileOPs 連續第二日單日合入 5 筆，並新開 1 個效能 PR；其夜間基準在視窗內出快照。

1.1 主倉：Metal 後端補上 32 位整數原子加（09-19）

日期：2026-09-19　來源：tilelang #3211 Metal 支援 32 位整數原子加

09-19 20:55 合入，作者 anerli，2 個檔案、+77/-0；該 PR 從 09-12 進入評審，視窗內落定。

修的是一個具體的能力空缺：Metal 無法下沉標量 int32 與 uint32 的 T.atomic_add（含返回舊值的形式），依賴整數計數器或槽位分配的可移植核心會在程式碼生成階段直接失敗。改動把這類呼叫下沉到 Metal 的 atomic_fetch_add_explicit：在原子指標轉換裡保留 device 與 threadgroup 地址空間的區別，採用 relaxed 序（與該操作既有的歸約語義一致），對不支援的寬度、型別與儲存域顯式拒絕，並補上原始碼下沉與 Metal 執行迴歸（覆蓋執行緒組原子與返回舊值兩種形態）。

驗證上，作者在 Apple Metal 上跑了有競爭的執行緒組直方圖，核對最終計數與返回的舊位置集合；本地 Metal 套件 20 項透過、3 項跳過，兩例新原子測試透過。

判讀：原子加是計數器、槽位分配與直方圖這類基礎模式的前置能力，這一筆把 Metal 側的基礎原語補齊一格——配合其繼續維護的 Metal 專項測試面，Metal 作為「可移植核心的第二塊試金石」在持續補短板。

1.2 主倉：256 位全域性訪存限定 SM100 及更新架構（09-19）

日期：2026-09-19　來源：tilelang #3248 256 位全域性訪存限定 SM100 及更新架構

09-19 13:15 合入，作者 penguin-wwy，3 個檔案、+56/-7。該 PR 在前一視窗以新開條目出現，本視窗完成合入。

內容：把 256 位 PTX 全域性 load/store 路徑限定在 SM100 及更新架構、且 CUDA 12.9 以上才發出；舊架構退回 128 位通路；新增 pre-SM100 的 CUDA 測試，覆蓋 T.ldg256/T.stg256 與向量 store 的回退行為。

判讀：寬訪存是新架構的能力，「先上寬度、後補從屬條件」的路徑裡，回退面就是迴歸風險所在；這條修正是把「能發就發」收緊成「該發才發」，與 1.3 的測試整並同屬把歷史欠賬清掉的一類工作。

1.3 主倉：測試套件一次減重 509 行，快數學斷言改用真參考實現（09-20）

日期：2026-09-20　來源：tilelang #3252 刪除重複程式碼生成冒煙測試並修復快數學斷言

09-20 01:44 合入，作者 penguin-wwy，6 個檔案、+20/-509。刪除 CPU 與 LLVM 兩側重複的 matmul 與 T.gemm 程式碼生成冒煙測試，整體刪除獨立的快數學 CUDA 測試模組；並修復「拿快數學輸出與自身比較」的斷言——為 exp10、log2、log10、cos、sin、tan 補上真正的參考實現，tan 改用確定性輸入並把容差放寬到 rtol=atol=1e-2，不支援的運算改為顯式斷言失敗而不再自比較。

判讀：刪的是重複覆蓋，補的是真覆蓋——自比較斷言等於沒有斷言；這是測試資產「提質去重」的一筆，與主倉把質量問題前移的整體取向一致。

1.4 主倉評審佇列：資料型別攔截 PR 有更新，Metal 行數 PR 關閉未合入，Tile IR 後端轉入草稿（09-19/09-20）

日期：2026-09-19 至 2026-09-20　來源：#3245 在 CUDA 程式碼生成前拒絕不支援的 GEMM 資料型別組合／#3215 Metal 執行時可變的 GEMM 行數／#3247 CUDA Tile IR 執行後端

三筆既有 PR 的狀態動態：

  • #3245（09-19 16:20 更新，未合入）：把不受支援的 GEMM 資料型別組合在進入 CUDA 程式碼生成之前攔下，延續「把靜默錯誤前移為顯式失敗」的取向。
  • #3215（09-20 01:37 關閉，未合入）：Metal 側「執行時可變的 GEMM 行數」在評審九天後關閉，未產生合入。
  • #3247（上一期重點，CUDA Tile IR 執行後端）：當前為草稿狀態且視窗內無任何更新，最近一次活動停在 09-18 晚間；本期只作狀態說明，不再展開。

判讀：主倉評審佇列的實質增量已由 ROCm 模型運算元接棒（見今日重點），既有大改動在本視窗推進停滯。

1.5 TileOPs：FP8 批矩陣乘轉置核心合入，H200 上最高 4.66 倍提速（09-19）

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

09-19 09:55 合入，作者 michaelwithu，7 個檔案、+308/-51，2 筆提交。該 PR 在前一視窗以新開狀態出現過（當時 5 個用例裡 4 個輸給對照實現，最差一檔 0.34 倍），本視窗合入。

內容：把 FP8 B 運算元的 [B, K, N] → [B, N, K] 具體化換成一個合併訪存的 TileLang 轉置核心；複製路徑改由 b 的步幅決定（不再只看 trans_b），K 最內層輸入在兩種引數下都跳過複製；佈局警告只在真的發生轉置時發出；補 FP8 轉置核心的直接覆蓋（含瓦片尾部），並把可選的對照實現基準行與 fp32 參考對齊校驗。

結果（H200、CUDA 13.2、torch 2.13.0）：五個用例相對主線提速 2.30 至 4.66 倍——MoE 預填充 0.8741 → 0.1874 毫秒（4.66 倍）、MHA 解碼 PV 0.0605 → 0.0131 毫秒（4.62 倍）、方陣 4 批 1K 0.0355 → 0.0137 毫秒（2.59 倍）；相對對照實現的比值由落後轉為反超（如方陣 8 批 2K 由 1.81 倍升至 4.16 倍）；trans_b=True 路徑不變，保持 1.03 至 1.20 倍。

判讀：這是 #2130（GEMM 元任務）下的分支收口——批矩陣乘在標準形狀已經立住，FP8 與佈局邊角是最後的短板，本筆把其中最大的一塊補齊。

1.6 TileOPs：GEMM 核心按服務區域重新命名併合並 GEMV 兩帶（09-19）

日期：2026-09-19　來源：TileOPs #2156 核心按服務區域重新命名，合併兩個 GEMV 帶

09-19 23:11 合入，作者 lcy-seso，19 個檔案、+421/-274。

內容：每個稠密 GEMM / BMM 核心類改為按「它與兄弟類的分野」命名——主迴圈結構（Tma、CpAsync、Persistent）、輸入形狀（Gemv）或縮放粒度（TensorScale、BlockScale）。SmallBatchGemmKernel 併入 GemvKernel：兩者本共用同一構建器，只差認領區域與配置規則；合併後一個類帶三個帶，帶由 band_for 判定並進入構造引數、快取標識、預設配置與調優網格。分派不變（三帶的並集等於原兩區域），核心體、配置規則與調優網格均未動；w4a16_decode.py 跟隨類名改為 w4a16_gemv.py。

破壞性變更：kernel_map= 的鍵隨類名遷移（7 個鍵，例如 gemm_kernel → gemm_tma_kernel、gemm_basic_kernel → gemm_cp_async_kernel）；舊鍵此前會被靜默丟棄並落到出廠實現，現在會在構造階段直接報錯。

判讀：改名不是審美問題——核心數量增長後，名字要能直接回答「為什麼該選它」；順帶把「傳錯鍵靜默兜底」改成顯式失敗，與主倉那條「靜默錯誤前移」是同一條紀律。

1.7 TileOPs 新開：分組 GEMM 尾塊分塊，正面追趕 CUTLASS 分組核心（09-19）

日期：2026-09-19　來源：TileOPs #2157 分塊分組 GEMM 尾塊，並允許呼叫方宣告填充行佈局

09-19 22:12 新開（未合入），作者 michaelwithu，10 個檔案、+297/-110。

內容：分組 GEMM 的四個工作負載裡只有 nt bf16 有真正的對手（fp16 下 torch 的分組矩陣乘退化為 16 次單獨呼叫，只有 bf16 走到 CUTLASS 的分組核心），而它落後 6.4%。兩處根因：128x256 瓦片把整個輸出瓦片（64 KiB）放在共享記憶體裡，主迴圈只排得下三級流水（對照為四級）；能把該緩衝換成第四級流水的 epilogue_stage_n 機制此前只對稠密與批矩陣乘開放。直接把機制靜默放開又不行：緊分組的最後一瓦片是殘塊，這些行按行掩碼儲存而非一整片寫出，分塊反而多付一輪暫存——在 MoE 真實路由下（每組最小 1 行、最大 663 行，55% 瓦片為殘塊）代價 3% 至 5.5%。殘塊比例是路由的性質而非形狀的性質，選擇器無法區分，所以讓呼叫方能宣告「我手裡是哪種」。

判讀：把「是否分塊」的決定權從形狀推斷改為呼叫方宣告，是分組 GEMM 逼近 CUTLASS 的關鍵一步；是否影響預設路徑，待合入後看夜間迴歸。

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

視窗總覽：四家既有後端加 Sunrise 均無提交；唯一動態是昇騰的每日迴歸報告。

2.1 昇騰：每日迴歸 1936 項全透過，連續第二日（09-20）

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

昇騰側每日定時測試於 09-20 05:30（北京時間）出報告：1936 項全部透過，失敗 0 項，透過率 100%。對照前一日（09-19 的 1936 項），用例數與結果均持平；倉內視窗內無新提交。

判讀：主倉本視窗的三筆合入分別落在 Metal、CUDA 與測試，均未觸及昇騰路徑，迴歸持平屬預期。用例數連續兩日停在 1936，說明視窗內上游沒有給昇騰側帶來新的用例面；其多裝置測試分片（#1812）在視窗內無更新。

2.2 沐曦、海光、摩爾執行緒、Sunrise：視窗內無新提交（09-17/09-18）

日期：2026-09-17 至 2026-09-18（各自最近一次推送）　來源：tilelang-metax／tilelang-hygon／tilelang-musa／tilelang-sunrise

四倉在 24 小時視窗內均無提交：沐曦與海光的最近推送為 09-17（17:38 與 20:25），摩爾執行緒為 09-17 上午，Sunrise 為 09-18 上午——均為上一期已報內容。版本狀態：沐曦、海光無釋出，摩爾執行緒最新為 v0.1.14+musa.1（09-11），Sunrise 候選分支停在 0.1.14+sunrise.1.1.0，各倉標籤視窗內均未更新。

判讀：上一視窗 Sunrise 進候選的活躍沒有延續，四家適配倉同步進入靜默；單日靜默不構成趨勢（採用方側此前已有「脈衝式更新」的先例），但可作為觀察點——下一視窗若繼續靜默，則說明各廠商適配的評審均按批次節奏在走。

三、生態與採用方

3.1 夜間快照：基準 1040 項與正確性 1118 項零失敗（09-19）

日期：2026-09-19　來源：TileOPs-nightly 快照分支／快照環境後設資料

夜間流水線在視窗內為 TileOPs 的 917590ba（即 #2154：從快照倉庫重建效能歷史視窗的合入）生成快照（09-19 16:19 提交）。解析基準與正確性兩份結果檔案：正確性 1118 項，失敗 0，跳過 2；基準 1040 個用例，失敗 0，跳過 3——與前一快照的用例數持平、全部透過。

環境後設資料與上一期一致：H200、CUDA 13.2、驅動 595.71.05、功耗上限 700 瓦、SM 時鐘 1500 兆赫茲（上限 1980）、記憶體時鐘 3201 兆赫茲、MIG 關閉、重複時長 100 毫秒、預熱 25 毫秒、映象按其內容標識記錄、TileLang 0.1.11 加代號版本、PyTorch 2.13.0。

3.2 基準可信度治理：8 行頻寬異常與同日三筆修復（09-19/09-20）

日期：2026-09-19 至 2026-09-20　來源：#2155 按路由選中的專家計價／#1996 位元組審計只看讀側／#2154 從快照倉庫重建效能歷史視窗

本視窗 TileOPs 最密集的工程投入不在運算元，而在「讓基準判定本身可信」，一天之內三筆：

  • #2155（09-19 21:24 合入）：3.1 中的夜間執行報出 8 行頻寬異常（IndexedExpertMLPFwdOp 的全部解碼工作負載，fp16 與 bf16 各半），讀數最高 132.4 TB/s，而 H200 的物理上限約 4.8。定位結果是公式錯誤：位元組數按全部專家計費，而路由型 MoE 只讀被 topk_ids 選中的專家。修復後讀數回落——deepseek-v3-decode-1 由 132.43 降至 3.62（活躍專家 7/256）、decode-32 由 6.97 降至 4.47（164/256）、decode-64 由 5.06 降至 4.47（226/256）、qwen3-235b-decode-32 由 4.92 降至 4.42（115/128）。附帶發現：FusedMoEExpertsFwdOp 用同一公式卻一直透過，只因工作負載從 512 token 起步、所有專家都活躍——是「按形狀透過」而非「按正確性透過」；FusedMoeSharedExpertFwdOp 則從未把共享輸出的寫計入。
  • #1996（09-20 06:50 合入）：把位元組審計的判據改為只看讀側。髒 L2 行在核結束後才寫回，落在剖析區間之外，測得的寫位元組天然小於演算法最小量，拿它判失敗會把正確行誤殺（首次執行即誤判三行）。同時修掉 add_fwd/sub_fwd 對預設 alpha 乘法的無條件計價（每元素按 2 FLOP 計而規範是 1），並給審計補了 CI 入口與按族執行的方式。
  • #2154（09-19 15:36 合入）：把 14 天效能基線視窗從「可變工件」遷到快照分支（每次執行一個提交、永不過期）：此前每個執行讀上一次的工件再覆寫，某次 API 502 曾讓一個執行只發布了自己一條記錄（對比鄰居的 14、15、19 條）。

判讀：三筆分別解決「公式對語義負責」「測量對物理原理負責」「資料對溯源負責」——運算元庫的夜間基線是它作為上游依賴的信用基礎，先讓結論可信，再談快慢。

3.3 採用方：TileKernels 與 FlashQLA 視窗內無推送（09-18）

日期：2026-09-18（最近一次推送）　來源：TileKernels／FlashQLA

視窗內兩家採用方均無推送：TileKernels 最近推送仍停在 04-23；FlashQLA 的最近推送為 09-18 15:53（上一期已報的三筆合入）。組織內 TileRT 同樣無推送（最近 08-13，已連續七週靜止）。

3.4 遷移線：稠密 Gated DeltaNet 預填充遷移 PR 更新（09-19）

日期：2026-09-19　來源：TileOPs #2144 遷移稠密 Gated DeltaNet 預填充

視窗內更新的遷移類 PR：把稠密 Gated DeltaNet 預填充遷入既有核心組織（建立於 09-16，09-19 23:11 更新，未合入）。作者為社群成員，與前一視窗報道的 TileSight 文件倉為同一賬號。這一筆與 1.6 的重新命名、#2130 的 GEMM 元任務屬於同一背景——運算元庫在數量增長後的結構整理：線性注意力、GEMM、分頁快取幾條線都在向統一的類與清單組織收斂。

四、社群、教程與活動

4.1 文件站：TileOPs 文件站一次站點部署，站點內容未變（09-19）

日期：2026-09-19　來源：TileOPs.github.io 文件站倉庫

TileOPs 文件站在視窗內有一次站點部署記錄（gh-pages 分支 09-19 08:01 的部署提交，對應構建 09-17 的主分支內容），其預設分支無新提交（最近內容更新仍為 09-17 的 #51）。屬部署類動作而非內容更新；主倉文件站視窗內無推送。

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

日期：2026-09-20　來源：Google News RSS（走代理）／Hacker News／arXiv

主題的 Google News RSS 中英文多組查詢（9 組，含元件名、國產加速器與運算元核心組合詞）在視窗內零新增；Hacker News 近五日無主題命中；arXiv 全文檢索的 9 條主題結果全部早於本視窗（最新一篇為 07-24 的效能建模論文，已在前一期報道）；組織無新建倉庫。

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

日期：2026-09-02（最近一次釋出）　來源：主倉 v0.1.14 釋出

主倉最新標籤仍為 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 起已 18 天未發版，而評審佇列與合入都在繼續——發版節奏與開發節奏的落差在擴大。

五、趨勢觀察

5.1 ROCm 線：從「後端可用」到「新模型原生運算元成鏈」

前一期的判讀「AMD 側推進已轉向具體模型的具體運算元」，本視窗得到加強：四個 PR 以堆疊鍊形式一次提交，覆蓋 GLM-5.3 稀疏注意力 k 池的全部環節，且直接繫結已釋出模型的配置契約（2048 token 預算、512 池、四 token 池粒度）。這說明 ROCm 側的工作面已經按「模型交付」組織，而不是按「後端能力補齊」組織——新模型釋出後，其特有運算元在 AMD 通路上的到位速度，正在成為衡量該後端成熟度的直接指標。

5.2 TileOPs 把一天投向度量體系：先讓判定可信，再談快慢

#2154、#2155、#1996 三筆全部落在基準與審計的判定邏輯上，加上視窗內的夜間快照全綠，說明維護層正把「夜間結論是否正確」看得和「核心是否更快」同等重要。這類治理的訊號價值在於：只有當測量體系可信，效能對比（如 1.5 的 4.66 倍、1.7 的 6.4% 差距）才具備決策意義。反過來說，本視窗暴露出的「同一錯誤公式長時間未被發現」，也提示其判定邏輯的覆蓋面仍有盲區。

5.3 主倉本視窗的三筆合入全是補課型，增量在評審佇列

補能力（Metal 原子加）、修適用面（256 位訪存回退）、提測試質量（減 509 行補參考實現）——三筆都指向欠賬清理而非新能力擴張。真正的新增量在評審佇列：ROCm 模型運算元四筆；而上一期的大改動（Tile IR 後端）轉入草稿停滯。主倉當前呈現「合入謹慎、探索留檔」的雙軌：大的路線級改動以草稿形態沉澱，日常以小步收口推進。

5.4 後端矩陣的靜默面擴大：僅昇騰保持日更迴歸

上一視窗還有 Sunrise 進候選的活躍，本視窗四家適配倉加 Sunrise 全部靜默，唯一動態是昇騰的每日迴歸（1936 項全透過）。需要避免把單日靜默解讀為停滯（採用方的脈衝式節奏已有先例），但這個對比本身給出了一個讀數：在多後端格局裡，只有昇騰維持著「每日可見」的工程節奏，其餘各家的活躍度需要按周甚至按月來觀察。

5.5 空白與風險點

三點需要標註：其一，四筆 GLM-5.3 PR 全部未合入，堆疊依賴意味著需要連環評審，任何一筆卡住都會拖住整條鏈的落地；其二，本視窗修復的 8 行頻寬異常與位元組審計誤殺（3.2）說明夜間判定邏輯曾錯誤執行了一段（異常讀數最高虛高到物理上限的 27 倍），修復後的判據穩定性需要在後續快照中持續觀察；其三，主倉發版停滯已達 18 天，評審佇列持續累積，而視窗內又關閉了一筆執行九天的 Metal PR（#3215）——佇列的吞吐與積壓之間的平衡是後續觀察點。

附：素材與核查說明

信源核查表

信源 核查結果
tile-ai 組織（28 倉庫） 視窗內 3 個倉庫有推送：tilelang、TileOPs、TileOPs-nightly；TileOPs.github.io 另有一次站點部署提交
主倉 tilelang 預設分支 3 筆合入（#3211、#3248、#3252）；視窗內新開 5 個 PR（#3251 至 #3255）；#3247 為草稿狀態且無更新
TileOPs 5 筆合入（#2153、#2154、#2155、#2156、#1996）；新開 1 個（#2157）；#2144 有更新
TileOPs-nightly 為提交 917590ba 生成快照（基準與正確性結果檔案、環境後設資料），結果已全量解析
昇騰 每日迴歸報告 1936 項全透過（連續第二日）；倉內視窗內無提交
其餘國產後端與 Sunrise 沐曦、海光、摩爾執行緒、Sunrise 視窗內均無提交，標籤未更新
採用方 TileKernels、FlashQLA 視窗內無推送；組織內 TileRT 同樣無推送
Google News RSS（中英多組，走代理） 視窗內零新增
Hacker News 近五日無主題命中
arXiv 主題檢索最新一篇為 07-24，視窗內無新預印本
文件站 TileOPs 文件站一次站點部署（內容未變）；主倉文件站無推送

完整信源清單

.io>