調研視窗：過去 24 小時（2026-09-22 07:00 ~ 2026-09-23 07:00，北京時間）。本期為常規日更視窗，與上一期無重疊。 信源：GitHub（tile-ai 組織 28 個倉庫推送核查，視窗內 7 個倉庫有推送；主倉 1 筆合入與 1 筆新開、評審佇列多條更新；TileOPs 1 筆合入與 5 筆新開、4 筆關閉；TileFoundry 兩筆合入；MLIR 昇騰 Mamba 大筆合入；海光雙分支推進含示例支援 PR 更新；社群 TPU 後端倉 BM1690 多核驗證；昇騰每日測試工作流級失敗與 A5 硬體路徑缺陷上報；夜間快照基準 1046 項零失敗、正確性 1141 項恢復釋出）、Google News RSS 中英文多組查詢（走代理，零命中）、Hacker News、arXiv、第三方生態倉

本期索引

  • 今日重點：FP4 到 FP8 的精確轉換被融合進主倉——DeepSeek V4.1 專家 GEMM 提速最高 5.4 倍（09-22）
  • 一、核心專案進展
    • 1.1 主倉評審佇列：並行迴圈修復新開，TileIR 後端追加 8 個提交（09-22）
    • 1.2 TileOPs 治理收口：清單條目與求值器的最後旁路被拆除（09-22）
    • 1.3 TileOPs 效能衝刺一：Engram 解碼拆分為投影與歸約兩段核心（09-22）
    • 1.4 TileOPs 效能衝刺二：GEMM 乒乓主迴圈隱藏稠密尾聲，176 瓦片入列（09-22）
    • 1.5 TileOPs 效能衝刺三：GLA 推理運算元入列，MoE 超額路由分組（09-22）
    • 1.6 TileOPs：roofline 合成失敗轉為可報告，佇列三筆更新（09-22）
    • 1.7 TileFoundry：記憶體後設資料與流量歸一化兩筆合入（09-22）
    • 1.8 夜間快照：基準 1046 項零失敗，正確性 1141 項恢復釋出（09-23）
  • 二、多後端適配（昇騰 / 海光 / 沐曦 / 摩爾執行緒等）
    • 2.1 昇騰：每日測試再現工作流級失敗，三筆新缺陷單指向 A5 硬體路徑與自動同步（09-22 至 09-23）
    • 2.2 MLIR 昇騰：Mamba SSD chunk scan 運算元大筆合入，調優與整合流程同時完善（09-22）
    • 2.3 海光：FP32 MMAC K 提交擴充套件重做；示例支援 PR 新增 32 檔案（09-22）
    • 2.4 沐曦與摩爾執行緒：視窗內無推送（09-23 核查）
    • 2.5 社群後端：TileLang-TPU 推進算能 BM1690 多核驗證與效能矩陣（09-22）
  • 三、生態與採用方
    • 3.1 採用方：TileKernels 與 FlashQLA 視窗內無推送（09-23 核查）
    • 3.2 社群專案：沐曦 C500 多正規化運算元開發實戰營材料持續提交（09-22）
  • 四、社群、教程與活動
    • 4.1 文件站：TileOPs 文件站一次版本化部署（09-22）
    • 4.2 媒體與學術側：Google News 零命中，arXiv 無新論文（09-23 核查）
    • 4.3 版本節奏：無新發布，主倉 v0.1.14 已滿 21 天（09-23）
  • 五、趨勢觀察
    • 5.1 轉換運算元成為一等公民
    • 5.2 TileOPs 從治理季轉向效能季
    • 5.3 昇騰的紅綠交替與 A5 的真實硬體檢驗
    • 5.4 空白與風險點
  • 附：素材與核查說明

今日重點：FP4 到 FP8 的精確轉換被融合進主倉——DeepSeek V4.1 專家 GEMM 提速最高 5.4 倍

日期：2026-09-22　來源：tilelang #3204

19:36 合入（09-11 開出，11 天打磨）。這筆記賬的起點是一段看似不起眼的轉換鏈：DeepSeek V4.1 的專家 GEMM 在每個 K 瓦片上，都要把 E2M1（FP4）權重經 FP32 中轉轉成 E4M3（FP8）。作者注意到一個編碼事實——E2M1 的全部取值，包括帶符號零，在 E4M3 裡都有精確對應的編碼，因此這條「先展開到 FP32 再壓縮」的預設投射鏈本可不經過 FP32。

實現上，把這段未標註的 CUDA 轉換鏈融合為每四個元素兩條 __byte_perm 指令；覆蓋標量與 2、4、8、16、32 五種向量寬度；顯式寫了轉換標註的程式碼保持原有降低路徑；整個轉換在暫存器內完成，不新增全域性或共享記憶體分配。

驗證分四層：源生成測試覆蓋兩種 E4M3 拼寫與全部寬度；執行時用例對每個打包四半位元組字與獨立編碼表逐字比對；抽取出的 GEMM 在全部配置下輸出與基線逐位一致（另有獨立取樣的 CPU 參考）；CUDA、ROCm、Metal、CuTeDSL 的當前頭 CI 均透過。

H100 效能（同卡、同輸入、每個圖形 100 次呼叫的中位數，節選四行）：

M N K 基線（微秒） 本筆（微秒）
1 2,304 5,120 547.94 108.65
512 2,304 5,120 717.30 224.21
1 5,120 2,304 245.17 45.85
2,048 5,120 2,304 1,760.22 591.92

十二個配置的提速區間為 2.97 倍至 5.38 倍；暫存器佔用從 128 升至 156，無溢位。作者註明的邊界：Blackwell 執行與整模型服務兩項尚未驗證。

判讀：一筆只有 161 行新增的「微轉換」換來最高 5.4 倍的端到端收益，說明在專家 GEMM 這種權重逐瓦片反覆讀取的場景裡，轉換鏈的成本被放在放大鏡下不是小題大做；它也再次顯示，TileLang 主線的最佳化物件正從「大結構」進入「每一層指令的賬本」。

一、核心專案進展

1.1 主倉評審佇列：並行迴圈修復新開，TileIR 後端追加 8 個提交（09-22）

日期：2026-09-22 至 2026-09-23　來源：#3269／#3247 等四單（完整清單見附錄）

  • #3269（09-23 01:48 新開）：禁用 let 內聯時並行迴圈的降低修復——調整 PartitionLoop 中迴圈變數替換的順序、替換前先化簡緩衝索引，併為並行迴圈配迴歸測試，另補 CUDA/HIP 下條件並行迴圈執行覆蓋。同一作者本視窗的第二筆修復（前一筆為 NVRTC 線）。
  • #3247（13:56 追加 8 個提交）：CUDA Tile IR 執行後端（tileir 目標，降低到 NVIDIA CUDA Tile IR，經 cuTile 執行時發射 cubin；含 JIT、快取、自動調優與 DeepSeek V4 稀疏注意力調優核心）在暫停數日後恢復推進，本視窗一次性追加 8 個提交，仍處評審。
  • #3267（09-23 01:05 更新）：tl.LowerMagicDiv 魔法除法（動態形狀除數的主機側預計算）繼續評審，覆蓋 CUDA/ROCm/CPU C 與主機程式碼生成。
  • #3265（13:54 更新）：啟動不變數整數運算下沉到主機側，覆蓋 Cython 與 NVRTC 兩條啟動路徑的拒絕邏輯。
  • #3241 至 #3244（18:16 至 18:20 各一次活動）：CuTeDSL 的 FP4 轉換與儲存降低修復、RNG 初始化三連（預設序列、void 繫結拒絕、缺初始化診斷）四條修復單保持開啟，未見合入動作。

佇列觀察：本視窗主倉僅 1 筆合入（#3204，見今日重點），評審側進入「加提交、不蓋章」狀態——TileIR 與魔法除法兩條大線都在攢料。

1.2 TileOPs 治理收口：清單條目與求值器的最後旁路被拆除（09-22）

日期：2026-09-22　來源：TileOPs #2167

10:24 合入（09-21 22:34 開出，約半日完成）。承接 #2158 的清單公式合龍，本筆把「函式對定義了求值方法的條目靜默讓位」這一機制從安裝點拆除：刪除兩個阻塞統一路徑的 GQA 覆寫，改用「把呼叫期負載疊加到屬性之上」的同一寫法；同時給兩類誤用補上明確報錯——負載為 None（呼叫方時序問題）與負載非對映（作者接線錯誤）。背景資料來自對照單 #2175 的覆盤：在 09-19 的某個提交點上，175 個已實現條目中有 19 個公式合成失敗，#2158 與本筆前後修完，但當時沒有任何一層會報告「下一個失敗的是誰」。

1.3 TileOPs 效能衝刺一：Engram 解碼拆分為投影與歸約兩段核心（09-22）

日期：2026-09-22　來源：TileOPs #2173

16:50 新開（1 檔案 +265/-108）。舊實現每個批行一個執行緒塊，兩次投影在序列迴圈裡做鏈式標量載入，權重不對任何塊共享——H200 上只跑出 4.8 TB/s 裝置頻寬的 6 至 34 GB/s，且在全部清單工作負載上慢於 torch.compile 基線。新結構分兩段：投影改為按 d 維分塊、用矩陣乘讀一次權重即服務整批（B 不大於 16 可進單個 MMA 瓦片）並順帶完成快取移位；其餘步驟（三個 RMSNorm、門控、空洞卷積、SiLU）因全部沿 d 歸約，跟進為第二段發射、每批行一個塊。另有一處發現寫進說明：兩個矩陣乘同處一個流水體內時，某些瓦片形狀會靜默讀錯流水級——掃過 3 形狀乘 30 種瓦片/級陣列合後改為兩塊走網格軸，單塊單鏈在全部 30 種組合下精確。

實測（H200 裝置忙碌時間）：批 1 從 28.1 微秒降至 6.0 微秒（4.7 倍，對 torch.compile 由 0.40 倍反差為 1.90 倍）；批 4 從 67.9 降至 8.3（8.2 倍，2.57 倍）；批 8 從 28.1 降至 5.6（5.0 倍，3.16 倍）。

1.4 TileOPs 效能衝刺二：GEMM 乒乓主迴圈隱藏稠密尾聲，176 瓦片入列（09-22）

日期：2026-09-22　來源：TileOPs #2172

16:21 新開（5 檔案 +465/-42）。把稠密 GEMM 的尾聲（epilogue）藏進對面消費者的主迴圈：一個生產者加兩個消費者 warpgroup，在交替的持久迴圈瓦片上工作，主迴圈透過有序 mbarrier 交接，使一個消費者的尾聲在另一個的主迴圈下執行。賬是這樣算的——雙消費者結構裡尾聲期張量核空轉，每個瓦片固定約 3.1 千周期（塊寬 176 時 5.2 千），佔 32 輪主迴圈的 9% 至 18%，正是與 cuBLASLt 的 176x128 核心在 DeepSeek-V3 預填充行上的全部差距。配套：尾聲改為兩個暫存瓦片輪轉（此前最後一塊未被隱藏的尾聲序列化十一次寫回、每次發射多花 2.9 千周期）、M/N 尾部走 TMA 邊界裁剪、176 桶寬入列（2112 = 12 乘 176，末波 91% 滿，優於 192 的 67%）。176 需要 tilelang 不低於 0.1.14（依賴 select_wgmma_inst_n），pyproject.toml 加上版本下限並在安裝指令碼里強制執行。測試：H200 上 86 項透過，六個形狀與 torch.matmul 逐位一致，新增 9 項測試。

1.5 TileOPs 效能衝刺三：GLA 推理運算元入列，MoE 超額路由分組（09-22）

日期：2026-09-22　來源：#2174／#2169／#1931

  • #2174（17:07 新開，15 檔案 +1384/-2，草稿標註未列）：GLA 推理運算元（GLAInferenceFwdOp，BTHD 佈局的 Q/K/V/G，可選 FP32 初始狀態，返回輸出與 FP32 終態）。用 16 令牌的張量核瓦片取代序列分塊內打分；長序列路徑吸收自 #1931 的分割槽摘要/掃描/重放思路，僅在序列長不小於 16384 時啟用。H200 實測（批 2、長 16384、頭 4、Dk=Dv=64）：舊分塊路徑 472.1 微秒，分割槽路徑 348.5 微秒，參考實現 443.5 微秒；清單基準獨立測得 TileOps 392.0 對參考 531.5 微秒。短序列保留原路徑。
  • #2169（12:58 新開）：MoE 索引路徑在單個專家收到超過 16 條路由時的分組最佳化——按路由密度而非令牌數在索引與連續執行間選擇；H200 實測 64 令牌檔：DeepSeek-V3 由 0.80 升至 0.990（相對 vLLM，數值大於 1 為更快）、Kimi-K2 由 0.83 升至 0.993、GLM-4.5 至 0.995；32 令牌檔升至 1.0 附近。同題重複單 #2171 開出三分鐘後關閉。
  • 關閉三筆：W4A16 GEMV 加速（#2159）、W4A16 網格 K 切分（#2170）兩筆效能探索關閉；08-17 開出的 GLA 預填充管線（#1931）關閉，其分割槽掃描思路已被 #2174 吸收。

一天內三筆效能單（Engram、GEMM、GLA）加一筆 MoE 最佳化同時在場，是 TileOPs 近期最密集的效能提交日。

1.6 TileOPs：roofline 合成失敗轉為可報告，佇列三筆更新（09-22）

日期：2026-09-22　來源：TileOPs #2175

19:47 新開（8 檔案 +473/-160）。把「公式合成失敗卻報不出來」的問題正面解決：此前一個求值無法合成的條目只顯示佔位提示，真正指出非法名字或構造的訊息由程式碼生成層丟擲後無人接收；程式碼生成層自己也不對每個條目給判定（非對映的簽名丟擲裸異常、模組級屬性服務的情況更是拋什麼都算）；且合成過程為了繫結一個名字而匯入輸出 dtype 解析器，連帶整個張量庫——檢查公式名與形式本不該需要 torch。本筆讓程式碼生成層的門變成全量判定（每個畸形條目都是點名運算元的明確錯誤）、判定只讀條目自身（175 個已實現條目在無 torch 環境下全部可合成）、並新增逐條合成檢查，以 schema 級錯誤報出其失敗原因。同時修正設計文件中六處與程式碼不符的陳述。

佇列更新：#2168（W4A16 預打包權重序，23:55 更新）保持開啟；#2163（DeltaNet 推理運算元，23:36 更新）與 #2160（變長 GQA 遷移，23:19 更新）均有推進。

1.7 TileFoundry：記憶體後設資料與流量歸一化兩筆合入（09-22）

日期：2026-09-22　來源：TileFoundry #175／#176／#168

  • #175（12:09 合入）：分析支援依賴單位的迴圈起點——上界與步長帶單位語義時不再假設起點為零，分析口徑與硬體執行的迴圈語義對齊。
  • #176（15:22 合入，兩筆提交）：記憶體後設資料與流量歸一化——重寫分析的記憶體與後設資料模組，觸及流量記賬、roofline 與分析規範文件（分析規範單檔案改動了 263 行），並同步教程與檢查器。為 09-21 兩筆新開的當日合入（間隔一天內完成）。
  • 關聯單：#171、#173 關閉；#168（不變數運算元的重複讀取應計入流量總量）保持討論。

1.8 夜間快照：基準 1046 項零失敗，正確性 1141 項恢復釋出（09-23）

日期：2026-09-23　來源：快照提交 81946098／快照環境後設資料

02:38 為 b07a259f（#2167 合入點）生成：基準 1046 項、失敗 0、跳過 3（仍為 GQA 分頁三項），用例數與上一份持平；正確性結果檔案本次恢復釋出——1141 項、失敗 0、跳過 2，前兩份快照缺檔案的疑點（09-21 快照僅隨帶基準檔案）就此消除。環境與上期一致：H200、CUDA 13.2、驅動 595.71.05、TileLang 0.1.11 加代號版本、torch 2.13.0，映象代號 afcebed1 第二版。

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

2.1 昇騰：每日測試再現工作流級失敗，三筆新缺陷單指向 A5 硬體路徑與自動同步（09-22 至 09-23）

日期：2026-09-22 至 2026-09-23　來源：每日測試 #1831／#1830／#1824／#1825

  • 每日測試再現失敗（#1831，09-23 06:29 自動開出）：跑批作業耗時約一個半小時後以失敗收場（工作流級失敗，非用例級）；對照 09-22 06:35 的快照式為 2448/2448 全綠。近三日呈紅綠交替（09-21 工作流失敗、09-22 全綠、09-23 失敗），穩定性問題值得持續觀察。程式碼分支本視窗無推送。
  • #1830（09-23 00:47 開出）：A5 裝置路徑的架構標號缺陷——真實 Ascend 950（dav-3510）上，裝置路徑以固定標號 dav-2201（屬 910B 代）編譯，核心啟動即報裝置異常 507015；改標號後核心可啟動，但靜默算出錯誤數值（官方量化示例的縮放因子出錯）。作者指認根因在構建程式碼中硬編碼的架構標號，並指出 README 的驗證矩陣恰好雙向繞開了該標號（真機 A2/A3 本就是 910B 代、A5 只走模擬），因此未被發現。
  • #1824 / #1825（09-22 09:58 開出，同一位報告者）：自動同步的兩處邊界——條件分支內的同步狀態被錯誤合併，分支未執行時後續讀取可能缺屏障（含最小復現）；自動跨核同步應對「組合開關關閉導致開關靜默失效」與「自動/手寫兩套同步混用」兩種配置在編譯期直接拒絕。後者點名倉庫內示例本身就有此類配置。

2.2 MLIR 昇騰：Mamba SSD chunk scan 運算元大筆合入，調優與整合流程同時完善（09-22）

日期：2026-09-22　來源：tilelang-mlir-ascend #191

18:57 合入（15:18 開出，約 3.5 小時完成，42 檔案 +4204/-1568）。中文標題即改動說明，三塊內容：其一，Mamba-2 的狀態空間對偶（SSD）分塊掃描 NPU 專家核心最佳化並接入包裝層——提升前態裝載、L0C 雙緩衝計算、向量分支資料複用，同步更新預設配置、設計文件與調優日誌；其二，完善運算元流程——修正最佳化任務的負載分發與基準用例選擇，從基準生成負載清單，按實際測試的核心檔案記錄效能結果，並在門禁中校驗最終檔案、測試覆蓋與報告資料；其三，新增 TileOPs 報告自動生成與校驗，整合時自動設定模式變數，並把 SSD 重跑、二輪調優的結論沉澱進模式庫、案例與待辦記錄。本筆與同一視窗內昇騰適配倉的 Mamba 線、以及社群 TPU 倉的分塊掃描工作形成呼應（見 2.5）。

2.3 海光：FP32 MMAC K 提交擴充套件重做；示例支援 PR 新增 32 檔案（09-22）

日期：2026-09-22　來源：分支提交 e4dc1053／示例支援 PR #11

  • 特性分支重做（15:27 推送）：feat/hcu-ds-read-fp32-mmac-k 分支上的修復被擴充套件重做——原三檔案版（共享 FP32 MMAC K 與片段打包）擴充套件為五檔案版（+54/-86）：新增移除 GEMM 的 LDS 策略推導中對資料型別的 FP16/BF16 限定（拓寬策略適用範圍，為 FP8 路徑掃清前置），並清理 tvm_ffi 介面卡裡的 FP8 匯出變通程式碼（刪 53 行、增 4 行；原用於繞開 torch FP8 無法經 DLPack 匯出的限制）；提交日期 09-21 晚、推送落地於本視窗。該分支仍無對應 PR。
  • 示例支援 PR #11 擴充套件（14:44 追加提交，32 檔案 +1086/-121）：為 TileLang 上游示例打通海光支援——新增 HCU 專屬快閃記憶體注意力示例（前向 258 行、反向 603 行）與其測試；批次適配上游的注意力（多頭前反向、GQA 解碼與變長、塊稀疏）、MoE 分塊狀態、GEMM（自動調優、持久化、內聯原語）、GEMV、分組矩陣乘等示例；CI 工作流與迴歸指令碼同步更新，並引入來自國產源鏡的 flash-attn 預編譯輪子。

2.4 沐曦與摩爾執行緒：視窗內無推送（09-23 核查）

日期：2026-09-23（核查）　來源：tilelang-metax／tilelang-musa

沐曦最近推送仍為 09-21（上游同步），摩爾執行緒最近推送為 09-17；兩倉本視窗無新動作。沐曦側的生態溫度另有一處體現：社群訓練營以 C500 加 TileLang 為教學載體持續提交材料（見 3.2）。

2.5 社群後端：TileLang-TPU 推進算能 BM1690 多核驗證與效能矩陣（09-22）

日期：2026-09-22　來源：社群倉庫 TileLang-TPU

一個面向算能加速器的社群 TileLang 擴充套件倉庫本視窗連推三筆：多核分塊掃描的 S3 與 P6 驗證（14:27）、P10 效能矩陣（16:05）、P10 主機側原始碼校驗修復（16:13）。該倉定位為「把 TileLang 程式設計模型帶到算能 TPU 目標」——保留 TileLang 的 Python 前端，增加 TPU 降低、程式碼生成與 JIT 執行時整合，提供 target="tpu" 目標、PCIe 與模擬兩種執行模式、TPU 專屬原語（複製、矩陣乘、歸約、倒數平方根、旋轉位置編碼等），並以 BM1690 為主線，自 09-20 起進入硬體驗證與逐級調優（單核、多核、效能路線圖 P8 至 P10）。倉庫處於活躍開發，宣告歡迎提交。這是 TileLang 社群裡出現的第一條公開 TPU 後端路徑；與同視窗 MLIR 昇騰的 Mamba 分塊掃描合入相對照，同一演算法家族在同一天出現在兩套非英偉達目標上。

三、生態與採用方

3.1 採用方：TileKernels 與 FlashQLA 視窗內無推送（09-23 核查）

日期：2026-09-23（核查）　來源：TileKernels／FlashQLA

視窗內兩家採用方無推送：TileKernels 最近推送停在 04-23；FlashQLA 上次推送為 09-18。值得注意的是，本視窗主倉合入的 FP4 到 FP8 融合正是以 DeepSeek V4.1 的專家 GEMM 為物件——採用方未動程式碼，但其推理程式碼中的轉換模式直接驅動了上游最佳化。

3.2 社群專案：沐曦 C500 多正規化運算元開發實戰營材料持續提交（09-22）

日期：2026-09-22　來源：社群訓練營材料倉

本視窗兩筆提交：完成第二講「向量加法」的 TileLang 與九齒雙實現對照練習（10:29）、為遠端例項工作流補充操作代理技能配置（10:32）。該材料倉以沐曦 C500 算力為底座（映象內含 TileLang 0.1.9、特定版本工具鏈），練習序列為：裝置與算力環境、TileLang 與九齒的加法對照（分塊與尾塊）、Softmax 與 GEMM 的歸約與數值穩定性、AI 智慧體輔助運算元開發與驗證，之後進入 Llama 運算元階段（接入、正確性、效能、端到端）。倉庫歷史可見與社群算力計劃的上游分支合併痕跡，屬社群教學方向的持續投入。

四、社群、教程與活動

4.1 文件站：TileOPs 文件站一次版本化部署（09-22）

日期：2026-09-22　來源：TileOPs 文件站

08:40 一次自動化部署（靜態站生成器 1.6.1 版本化提交），站點內容未見實質變化；主倉文件站本視窗無部署動作。

4.2 媒體與學術側：Google News 零命中，arXiv 無新論文（09-23 核查）

日期：2026-09-23（核查）　來源：Google News RSS（多箇中英文查詢，走代理）／Hacker News／arXiv

Google News 中英文多組查詢視窗內零命中；Hacker News 相關查詢僅有無關聯條目（電路板佈線、桌面雲臺等字樣巧合）；arXiv 主題檢索最新一篇仍為 07-24 的效能模型論文，視窗內無新預印本。媒體側連續第二個平靜視窗。

4.3 版本節奏：無新發布，主倉 v0.1.14 已滿 21 天（09-23）

日期：2026-09-23　來源：tilelang v0.1.14

視窗內各倉均無新版本釋出。主倉最新發布仍為 09-02 的 v0.1.14（已滿 21 天）；各適配線版本未動：昇騰 v0.1.2.000（09-09）、MLIR 昇騰 v0.1.2.020（09-09）、摩爾執行緒 v0.1.14+musa.1（09-11）、沐曦 v0.1.14（09-17）、Sunrise 0.1.14+sunrise.1.1.0（09-21）。另注：#2172 起，TileOPs 對 tilelang 版本下限提出 0.1.14 的硬要求，發版節奏與下游採納視窗的關係值得留意。

五、趨勢觀察

5.1 轉換運算元成為一等公民

一筆只管「FP4 怎麼變成 FP8」的 161 行改動換來 2.97 至 5.38 倍端到端提速，前提是它出現在被反覆讀取的權重路徑上。與此平行，TileOPs 的效能三筆（Engram 拆分、GEMM 搬運隱藏、GLA 分塊）也都在最佳化「同一塊資料被讀幾次、在哪一級快取裡流轉」。當運算元級結構漸趨穩定，收益持續向資料搬運與格式轉換遷移——這也解釋了為什麼主倉會把一筆精確編碼轉換當作正經條目合入，而非區域性微調。

5.2 TileOPs 從治理季轉向效能季

上週的關鍵詞是「把錯的改對」（公式、物理、溯源），本視窗一天之內三筆效能單加一筆路由最佳化同時在場，且新開單普遍自帶對照基準（torch.compile、cuBLASLt、參考實現、vLLM）與逐位一致宣告。治理留下的賬本正在變成效能工作的信用資產：每筆效能單都能被清單與基準獨立複核。

5.3 昇騰的紅綠交替與 A5 的真實硬體檢驗

每日測試三日內的紅綠交替說明跑批環境的穩定性仍未收口；而 #1830 暴露的問題更具代表性——驗證矩陣用真機覆蓋 910B 代、用模擬覆蓋 950 代，恰好兩側都繞開了裝置路徑的架構標號，導致缺陷在真實 950 上以「啟動即崩、改標號後靜默算錯」兩種形態暴露。跨代硬體的適配深度，正從「能編譯」進入「敢用真機校準」的階段。

5.4 空白與風險點

四點：其一，主倉合入節奏本視窗僅一筆，TileIR 與魔法除法兩條大線均處於「加料未蓋章」狀態，評審頻寬是否成為瓶頸值得觀察；其二，發版停滯已滿 21 天，而下游（TileOPs）已開始宣告對 0.1.14 及以上的硬依賴，版本視窗與生態採納之間的節拍需要協同；其三，昇騰 A5 的輸出正確性問題（改標號後靜默錯誤）尚無修復單，若屬實將影響 950 代的可信度敘事；其四，海光特性分支仍無 PR、昇騰被回退的大合入未見返工排期，兩條國產線的「落地在途」狀態延續。

附：素材與核查說明

信源核查表

信源 核查結果
tile-ai 組織（28 倉庫） 視窗內 7 個倉庫有推送：tilelang、TileOPs、TileOPs-nightly、TileFoundry、tilelang-mlir-ascend、tilelang-hygon、TileOPs.github.io
主倉 tilelang 預設分支 1 筆合入（#3204）；1 筆新開（#3269）；#3247、#3267、#3265、#3241 至 #3244 視窗內各有更新；視窗內新開與關閉 issue 均為 0 筆
TileOPs 1 筆合入（#2167）；新開 #2169、#2172、#2173、#2174、#2175（另 #2171 同題重複當場關閉）；關閉 #2159、#2170、#1931；#2168、#2163、#2160 更新
TileOPs-nightly 1 份快照（81946098，對應 b07a259f 即 #2167 合入點）：基準 1046 項零失敗；正確性 1141 項恢復隨快照發布
TileFoundry 2 筆合入（#175、#176）；#171、#173 關閉；#168 保持討論
tilelang-mlir-ascend 1 筆合入（#191，Mamba SSD chunk scan 最佳化，42 檔案）
tilelang-hygon 2 條分支有推送：特性分支提交擴充套件重做、示例支援 PR #11 追加 32 檔案提交
tilelang-ascend 程式碼分支無推送；每日測試工作流級失敗（#1831）；新開缺陷單 3 筆（#1830、#1824、#1825）
其餘 tile-ai 倉庫（TileRT、tilescale、DeepStack、tilelang-puzzles、metax、musa 等） 視窗內無推送
採用方（TileKernels、FlashQLA） 視窗內無推送
第三方發現 社群 TPU 擴充套件倉（BM1690 多核驗證 3 筆提交）；社群訓練營材料倉（2 筆提交）
Google News / Hacker News / arXiv 中英文多組查詢零命中；HN 無關聯條目；arXiv 無新預印本

完整信源清單

海光特性分支提交（e4dc1053） — https://github.com/tile-ai/tilelang-hygon/commit/e4dc1053