調研視窗：2026-10-20 07:00 ~ 2026-10-21 07:00（北京時間，24 小時）。

信源：GitHub tile-ai 組織逐倉核查（Atom 提交流全量，覆蓋 tilelang / TileOPs / TileFoundry / tilelang-ascend〔預設分支 ascendc_pto〕/ tilelang-hygon / tilelang-metax〔dev〕/ tilelang-musa / tilelang-mlir-ascend / TileRT / tilescale / DeepStack）+ 合入與在審真值檢索（is:merged / is:open，按倉庫分組統計）+ 釋出頁與 VERSION 檔案核查 + 統計分支核查 + 文件站提交核查 + 採用方倉核查（TileKernels / FlashQLA）+ 社群新倉檢索 + Google News 中英文多組查詢（走代理）+ Hacker News + arXiv。

本期索引

  • 今日重點：主倉五筆編譯器正確性修復同日落地，昇騰側五筆反向與遞迴運算元補位，TileOPs 在 SM90 把三個 foundry 注意力運算元換裝成 warp 特化程式（10-20）
  • 一、核心專案進展
    • 1.1 主倉：向量化分析納入非零迴圈下界，修 unit-step 迴圈與混合精度 guard（#3579）（10-21）
    • 1.2 主倉：共享記憶體跨執行緒 WAW 檢測改用雙執行緒例項，補回漏掉的屏障（#2821）（10-20）
    • 1.3 主倉：不支援的 MMA tile 要求顯式 K 填充，避免靜默縮 K 與佈局推斷失敗（#2818）（10-20）
    • 1.4 主倉：fragment reduce 支援保留維度目標，修 (64,1) 目標崩潰（#2815）（10-20）
    • 1.5 主倉：TIR 謂詞隨整數位寬提升同步改寫（#3550）（10-20）
    • 1.6 主倉：CuTeDSL scan 補參與執行緒偏移引數，修 cumsum 構造失敗（#3576）（10-20）
    • 1.7 主倉 CI：效能迴歸任務鎖定 H100，H20 機型須 fail-fast 攔截（#3569）（10-20）
  • 二、多後端適配（昇騰 / 沐曦 / 海光 / 摩爾執行緒）
    • 2.1 昇騰主倉：L0 區域性複製支援顯式 pitch，一個 GEMM tile 可由多次複製拼成（#3511）（10-20）
    • 2.2 昇騰主倉 CI：單 check 內拆分構建與測試步驟，失敗後繼續跑其餘套件（#3564）（10-20）
    • 2.3 昇騰倉：DSA 稀疏微調反向運算元 indexer_bwd 落地，AscendC 與 PTO 雙後端（#1887）（10-20）
    • 2.4 昇騰倉：SiTU-GLU 反向運算元進倉，對照 Kimi K3 門控啟用並在 910B3 交叉校驗（#1877）（10-20）
    • 2.5 昇騰倉：cann-bench 補 LSTM 與 GRU，12 / 8 個 jit kernel 覆蓋多層雙向與投影（#1892 / #1902）（10-20）
    • 2.6 昇騰倉：CrossEntropy 基準中文版補齊，en/zh 成對慣例延續（#1801）（10-20）
    • 2.7 昇騰在審：PTO 向量化框架進審（#3512）、tvm_ffi 擬成 pto 預設執行後端（#3516）、DeepGEMM 啟發式對齊（#3577）（10-20）
    • 2.8 海光：MLS 視窗常量 K 原點修復合入（#25），fp4 分割槽與分散式兩筆在審（#26 / #19）（10-20）
    • 2.9 沐曦 / 摩爾執行緒 / MLIR-Ascend：視窗內無新推送，三條線停在既有版本（10-20）
  • 三、生態與採用方（TileOPs / TileFoundry / 運算元庫）
    • 3.1 TileOPs：分頁 GQA 前向換裝 paged warp 特化程式，FP8 池經 16 位頁映象讀取（#2668）（10-20）
    • 3.2 TileOPs：FP8 lightning indexer 改雙 consumer warpgroup 輪流吃 64-key tile（#2666）（10-20）
    • 3.3 TileOPs：MLA 解碼走錯位蹺蹺板程式，keys 按 SM 數切段後 log-sum-exp 合併（#2665）（10-20）
    • 3.4 TileOPs：張量核效能上限改為運算元集合包絡，修夜間跑批 105%/108% 誤報（#2661）（10-20）
    • 3.5 TileOPs：後端測試與 torch-compile 基線可在非 CUDA 裝置執行（#2658）（10-20）
    • 3.6 TileOPs：SM89 單行單列改走向量 GEMM 路徑，候選按共享記憶體預算過濾（#2660）（10-20）
    • 3.7 TileOPs：三筆 builder 快取與調優契約修復（#2662 / #2663 / #2664）（10-20）
    • 3.8 TileOPs 在審 11 筆：SM89 的 NSA top-k、分頁 DSA、W4A16 窄 tile 三條線並進（10-20）
    • 3.9 TileFoundry：0.0.3 公告寫入 README，測試重構複用編譯快取（#247 / #246）（10-20）
    • 3.10 採用方：TileKernels 與 FlashQLA 視窗內無推送（10-20）
  • 四、社群、教程與活動
    • 4.1 社群倉：中文系統教程 tilelang-tutorial 建倉，覆蓋運算元、編譯期與兩大後端（10-20）
    • 4.2 社群倉：CANN 社群 ops-tilelang 建倉，按運算元資產方式管理昇騰實現與基線（10-20）
    • 4.3 工具鏈：devkit 與 VS Code 擴充套件活躍，主倉在審把 lower trace 整體遷出（#3583）（10-20）
    • 4.4 社群倉：tilelangGym 測 PTO lowering 敏感度，Hexagon 後端實驗倉出現（10-20）
    • 4.5 文件

與版本：文件站四次自動更新，主倉 VERSION 仍 0.1.15（10-21）

  • 五、趨勢觀察

今日重點

本視窗合入 26 筆（tilelang 9、TileOPs 9、tilelang-ascend 5、TileFoundry 2、tilelang-hygon 1），無新版本釋出。三條線同時推進：主倉把一天裡的多數合入放在編譯器正確性上（向量化迴圈下界、共享記憶體跨執行緒 WAW、MMA tile 的 K 原子、fragment reduce 保留維、TIR 謂詞隨位寬提升），屬”靜默錯誤”清理而非功能擴張；昇騰側五筆合入全部落在訓練側與遞迴運算元（DSA 稀疏微調反向、SiTU-GLU 反向、LSTM、GRU），並有一筆 2.1 萬行的 PTO 向量化框架在審，PTO 正在成為 AscendC 之外的第二條執行路徑；TileOPs 在 SM90 把分頁 GQA 前向、FP8 lightning indexer、MLA 解碼三個 foundry 運算元同日換裝成 warp 特化程式，同時把張量核效能上限的校準口徑改成運算元集合包絡，修掉夜間跑批裡 105% 的偽超限。

一、核心專案進展

1.1 主倉：向量化分析納入非零迴圈下界（#3579）

合於 10-21 00:27，10 檔案 +818/-198，承接 #2819 的 guard 修復，同時關掉 #2669、#2616 兩個問題。原實現用 f(i) 與 f(floor(i / W) * W) 比較來判斷表示式在每個向量組內是否同值，這隱含假設迴圈從 0 起；迴圈下界非零時，unit-step 向量化會把不同 lane 的地址算成同一組，廣播裝載與整組共享條件的證明隨之失效。新的判定把迴圈最小值納入分析，並在搬運混合精度轉換時保留巢狀 guard。屬會靜默改變數值結果的編譯器缺陷。

來源：https://github.com/tile-ai/tilelang/pull/3579

1.2 主倉：共享記憶體跨執行緒 WAW 檢測（#2821）

合於 10-20 23:41，3 檔案 +153/-19，修 #2698。共享記憶體上 S[tx] 與 S[tx + 10] 對單執行緒是兩個地址，但不同執行緒的寫可以重疊；原 WAW 檢查對兩次訪問複用同一個執行緒變數，因此漏判、漏插屏障。修法是同迭代 WAW 用兩個不同執行緒例項，並重新命名各自的 Bind 定義，複用既有 RAW/WAR 模型，迴圈攜帶的 WAW 維持原處理。測試同時覆蓋”該插”與”不該插”兩種情形，含 guarded 寫、Bind 派生索引、不相交分割槽與 threadIdx.y/z 置換，執行緒同步與 issue 兩套用例 95 項透過。

來源：https://github.com/tile-ai/tilelang/pull/2821

1.3 主倉：不支援的 MMA tile 要求顯式 K 填充（#2818）

合於 10-20 16:41，5 檔案 +57/-14，修 #2715。通用 MMA emitter 可能在構造運算元佈局之前悄悄縮小 K 原子，FP16 K=8 會算出錯誤結果；K=20、K=28 這類不規則尺寸則在共享記憶體佈局推斷階段直接失敗且提示不明。現在在 emitter 初始化時按架構固定的 K 原子校驗 tile 的 K，不整除即拋 ValueError，帶上輸入 dtype、所需整除關係與建議的填充值（如 SM80 上 FP16 K=20 報原子 16、建議補到 K=32 並零填多餘元素）。

來源：https://github.com/tile-ai/tilelang/pull/2818

1.4 主倉：fragment reduce 支援保留維度目標（#2815）

合於 10-20 16:35，8 檔案 +343/-63，修 #2530。T.reduce_sum 等把 (64, 64) 沿 dim=1 歸約到 (64, 1) 時編譯期崩潰（Check failed: vars.size() == InputDim() (2 vs. 1)）。而 reduce_op.py 的文件契約明確同時接受 [X, Y] 與 [X, 1, Y] 兩種輸出形狀並已構造對應期望形狀，因此這是後端缺口而非誤用。修復同時教通兩條 lowering 路徑，並保留無保留維目標的原行為。

來源：https://github.com/tile-ai/tilelang/pull/2815

1.5 主倉：TIR 謂詞隨整數位寬提升同步改寫（#3550）

合於 10-20 09:59，4 檔案 +950/-27。整數索引被提升到更寬位寬後，控制緩衝訪問的邊界檢查仍按舊位寬計算，理論上可放過越界訪問。新增 IndexPredicateRewriter，在 ConfigIndexBitwidth 與 FlattenBuffer 中記錄每次訪問的提升資訊，訪問語句處理完後再重寫相關 guard；匹配限定在等價的加法與乘法形式上，保留無關條件、資料值表示式與定寬邊界。新增索引提升、guard 改寫、訪問作用域、向量端點與衝突提升五類測試。

來源：https://github.com/tile-ai/tilelang/pull/3550

1.6 主倉：CuTeDSL scan 補參與執行緒偏移（#3576）

合於 10-20 12:49，2 檔案 +30/-6。共享記憶體 scan lowering 在 #3536 裡引入了參與執行緒偏移，但 CuTeDSL 側的 helper 仍按舊構造引數生成呼叫，tl.CumSum1D(32, False, 0).run(...) 直接報構造引數錯誤；同批失效的 codegen 斷言也是 #2815 兩次 CUDA CI 失敗的來源。修法是為一維、二維 cumsum/cummax helper 增加可選 thread_offset（預設 0 保持相容），選參與 lane 與 warp 前先減去偏移，並給 CUDA 專屬測試打上 requires_cuda。

來源：https://github.com/tile-ai/tilelang/pull/3576

1.7 主倉 CI：效能迴歸任務鎖定 H100（#3569）

合於 10-20 16:00，1 檔案 +15/-1。PR 迴歸機器人逐 kernel 比對延遲與基線，數字只在基線採集的同型號卡上有意義。組織正在引入自託管 H20 容量機型做常規正確性 CI，其標籤集與既有的 [self-hosted, nvidia] 重合，若不區分會靜默接走基準任務：H20 的 FP16 稠密算力約 148 TFLOPS，對 H100 的約 990 TFLOPS 差約七倍，FP64 通路也被大幅裁剪，每個基準都會報出並不存在的迴歸。現要求 pr-regression 任務必須帶 h100 標籤，並在開工前校驗分配到的卡確實是 H100，標籤寫錯即快速失敗而非釋出誤導數字。

來源：https://github.com/tile-ai/tilelang/pull/3569

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

2.1 昇騰主倉：L0 區域性複製支援顯式 pitch（#3511）

合於 10-20 14:16，24 檔案 +1458/-187，是本視窗昇騰方向最大的一筆。此前一個 GEMM tile 只能由單次 L1→L0A/L0B 複製填充，非零目標原點被拒絕，每次複製又從自己的區域推緊湊 pitch，因此分開搬的兩半拼不成目標整塊；MajorK/MajorMN 轉置裝載也受限。新增 Ascend 專屬引數 T.copy(..., l0_pitch=...)，按 fractal 塊指定 L0 pitch，由呼叫方給出消費方 GEMM 的緊湊 pitch（含動態尾塊），省略該引數則維持緊湊區域的原行為。示例中 64 行 A tile 的兩半均寫 l0_pitch=4。同步處理對齊後的目標偏移 lowering、物理邊界與轉置組校驗、分配與緩衝版本間距。

來源：https://github.com/tile-ai/tilelang/pull/3511

2.2 昇騰主倉 CI：單 check 內拆分構建與測試（#3564）

合於 10-20 12:06，1 檔案 +61/-9。把 Ascend 的構建與測試結果收進同一個 Test for Ascend PR 檢查，用分步呈現失敗階段，並在 workflow summary 裡列出各階段結論。CANN 環境只裝配一次、構建一次，AscendC 示例、PTO 示例與 Ascend 單測作為同一 job 的三個步驟分別執行；構建成功且工作流未被取消時，某套件失敗後仍繼續跑其餘套件，最終整體仍判失敗。CANN 變數經 GITHUB_ENV 傳遞。

來源：https://github.com/tile-ai/tilelang/pull/3564

2.3 昇騰倉：DSA 稀疏微調反向運算元 indexer_bwd（#1887）

合於 10-20 15:26，2 檔案 +1294。為昇騰 NPU 增加 indexer_bwd，服務 DSA 稀疏微調，同時支援 AscendC 與 PTO 兩個後端。運算元計算 lightning-indexer KL 微調損失對 dIndexQ、dWeights、dIndexK 的梯度，支援變長打包序列。實現分三檔：持續化 GEMM 的快速 kernel 面向連續與共享行索引布局，帶流水與更少搬運；通用 kernel 支援任意索引布局，含 -1 非法索引的梯度累加；另設 cast kernel 處理精度轉換。

來源：https://github.com/tile-ai/tilelang-ascend/pull/1887

2.4 昇騰倉：SiTU-GLU 反向運算元（#1877）

合於 10-20 15:22，5 檔案 +854。語義對齊 CANN ops-nn 的 aclnnSituGluGrad，用於 Kimi K3 Stable LatentMoE 的門控啟用反向：t = tanh(gate / beta)、s = sigmoid(gate)、situ_a = beta * t * s，上游分支按 linear_beta 是否為正走 tanh 或直通，輸出 grad_gate 與 grad_up。精度基準是獨立實現的 fp64 PyTorch 參考，並在 910B3 上與官方 aclnn 交叉校驗，最大相對誤差約 3e-3，符合 bf16 舍入預期。

來源：https://github.com/tile-ai/tilelang-ascend/pull/1877

2.5 昇騰倉：cann-bench 補 LSTM 與 GRU（#1892 / #1902）

兩筆同日合入，分別 +2304 與 +2267。LSTM 覆蓋 i/f/g/o 四門與 cell state 時序遞迴，支援多層堆疊（numLayers ≤ 8）、雙向、batchFirst 佈局、投影降維（projSize > 0，LSTMP）與可選 bias，權重按”每層每方向一個 tensor”的 TensorList 傳入，輸出 (y, hn, cn)，實現為 12 個 @tilelang.jit kernel；主力走融合 seq 路徑，每（層、方向）一次 launch，核內按 T.serial(S) 逐時間步完成雙 GEMM、bias 廣播、門控與狀態更新，與遞迴無關的 x 側門控貢獻由獨立 xgemm 全時間步並行預計算。GRU 為 8 個 kernel，z/r/n 三門合一 GEMM 在 Cube、門控與狀態更新在 Vector，跨核資料經 GM workspace 中轉，並手動關掉 AUTO_SYNC——按提交說明，自動模式每時間步約產生 58 個 PipeBarrier。

來源：https://github.com/tile-ai/tilelang-ascend/pull/1892、https://github.com/tile-ai/tilelang-ascend/pull/1902

2.6 昇騰倉：CrossEntropy 基準中文版（#1801）

合於 10-20 15:26，2 檔案 +91。為 #1567 合入的 CrossEntropy benchmark 文件補中文版，參照 FA（bench_mark.md / bench_mark_zh.md）與 SFA（README.md / README_zh.md）的 en/zh 成對慣例：在 examples/cross_entropy_loss/ 下新增 benchmark_summary_zh.md，完整翻譯最佳化路徑八步、內部效能對比、CANN 對比、已知限制與測試覆蓋，英文版頂部加語言切換連結。純文件改動。

來源：https://github.com/tile-ai/tilelang-ascend/pull/1801

2.7 昇騰在審：PTO 向量化框架、tvm_ffi 後端與 DeepGEMM 對齊

三條主線同時進審。#3512（50 檔案 +21022/-72）讓使用者在 T.SimdVF(lanes=L) 裡寫標量並行的 T.Parallel 程式（逐元素、控制流、歸約），由編譯器向量化成 PTO VMI 指令、經 PTOAS 編譯後在 Ascend 950 上執行，完整能力分多筆 PR 落地，本筆是流水線框架與逐元素支援的里程碑。#3516（18 檔案 +1473/-22）讓 target="pto" 配 execution_backend="auto" 解析到 tvm_ffi 並設為預設，主機側走 MakePackedAPI 與 C host 構建，Ascend 執行時經 aclrtLaunchKernelWithHostArgs 啟動 PTODSL 編譯出的 aibin。#3577（29 檔案 +1392/-1036）補齊 DeepGEMM-Ascend 的配置選擇與 epilogue，覆蓋密集、批次與分組 GEMM 的融合 bias、Alpha、BF16 隨機舍入與 FP8 量化。另有 #3530（NZ 緩衝的部分 UB→L1 複製）、#3573 / #3580 / #3581 / #3582 一組 PTO 謂詞、MAD 方向分析與 redux 有符號性修復。

來源：https://github.com/tile-ai/tilelang/pull/3512、https://github.com/tile-ai/tilelang/pull/3516、https://github.com/tile-ai/tilelang/pull/3577

2.8 海光：MLS 視窗常量 K 原點修復（#25）

合於 10-20 09:53，2 檔案 +346。迴圈展開後 MLS 資源提升會丟掉常量視窗偏移，導致後續訪問落到錯誤區間。修法是在選擇單軸更新或前向增量定址之前，先校驗未被更新的那一維，必要時保守地重新初始化視窗；並在既有 MLS 測試上補回歸覆蓋。海光倉視窗內在審三筆：#26 處理 fp4 MLS 的 warp 分割槽（14 檔案 +261/-144）、#18 補暫存器流水線與 warp-diverge 支援、#19 為分散式相關改動。

來源：https://github.com/tile-ai/tilelang-hygon/pull/25

2.9 沐曦 / 摩爾執行緒 / MLIR-Ascend：視窗內無新推送

三條線本視窗均無提交。沐曦倉最近一次為 09-29 的 0.1.15 版本準備，摩爾執行緒倉停在 09-30 的 0.1.15 公開發布準備，MLIR-Ascend 最近一次為 10-19 的 TVM 隔離修復（本視窗外）。三倉在審 PR 數為零，未見新分支活動。

來源：https://github.com/tile-ai/tilelang-metax、https://github.com/tile-ai/tilelang-musa、https://github.com/tile-ai/tilelang-mlir-ascend

三、生態與採用方（TileOPs / TileFoundry / 運算元庫）

3.1 TileOPs：分頁 GQA 前向換裝 paged warp 特化程式（#2668）

合於 10-20 22:41，8 檔案 +901/-103。新增的 GQAPrefillPagedWSKernel（SM90）承接 GQAPrefillPagedWithKVCacheFwdOp：一次 append launch 把 chunk 寫入分頁（key 在融合 RoPE 下旋轉，兩者都在 FP8 池上量化）並旋轉 query，隨後由 GQAPagedFwdOp 的 warp 特化程式在被撐大的快取上做注意力。該程式服務 head dim 256（單 query slot）與單 KV head 上寬於 16 頭的 query 組（把 (T * H, D) 的 query 攤平為行）；FP8 程式未覆蓋的維度 64 與 256 的池，經頁的 16 位映象讀取，單次上限 4 GiB；請求可能拆分時按快取長度排序、最長的先領，最多 128 個請求。

來源：https://github.com/tile-ai/TileOPs/pull/2668

3.2 TileOPs：FP8 lightning indexer 改雙 warpgroup 消費（#2666）

合於 10-20 22:41，6 檔案 +448/-2。原實現一個 warpgroup 乘 64-key tile，隨後跑與乘積等長的 epilogue（每個 head 乘 key scale，FMUL 與 FADD 分開）；另有一次乾淨掃描以 2.5 TB/s 寫視窗外的 -inf——按提交說明，這佔 chunk-prefill-kscale 472 微秒中的 425 微秒；解碼呼叫裡單 query 佔一個 CTA 走完 16384 個 key，耗時 289 微秒。新的 FP8LightningIndexerWSKernel（SM90）用 TMA warp 流式搬 64-key tile 給兩個 consumer warpgroup 輪流處理，每 tile 一次 m64n256 FP8 WGMMA，消費者 epilogue 收斂為 csrc helper。

來源：https://github.com/tile-ai/TileOPs/pull/2666

3.3 TileOPs：MLA 解碼走錯位蹺蹺板程式（#2665）

合於 10-20 22:39，7 檔案 +881/-590。MLADecodeSeesawKernel（SM90，512 + 64 latent，單 KV head）承接 MLADecodeWithKVCacheFwdOp，沿用 MLAPagedFwdOp 的錯位蹺蹺板思路，按請求經 TMA 讀 k 與 k_pe；程式本體遷到 kernels/attention/mla/seesaw.py，提供分頁與密集兩個入口，MLAPagedFwdOp 的拆分構建與原先產出同一份儲存。一個請求的 key 被切成 min(sm_count // blocks, tiles // 2) 段，用 log-sum-exp 合併；密集段按輸出 dtype 留部分結果，16 位輸出經 warpgroup 自有 key 緩衝暫存後由 TMA 落盤。

來源：https://github.com/tile-ai/TileOPs/pull/2665

3.4 TileOPs：張量核上限改為運算元集合包絡（#2661）

合於 10-20 22:27，4 檔案 +125/-82。夜間跑批 39299002056 把 GemmW4A8FwdOp 標到 tensor_core.fp8 上限的 105% 與 108%，核查後是上限本身偏低：原校準取 cuBLAS 在隨機運算元上的速率，而 700 W 功耗上限下運算元取值直接決定時鐘，功耗低於隨機 cuBLAS 的 kernel 可以跑在該速率之上。現在 gemm_throughput.py 同時計時全零運算元，把各運算元集合的最好速率記入 calibration_operands，取其中最大值作為校準值——與 HBM 校準既有的包絡規則一致；h200.yaml 隨之重標。

來源：https://github.com/tile-ai/TileOPs/pull/2661

3.5 TileOPs：後端測試與 torch-compile 基線可在非 CUDA 裝置執行（#2658）

合於 10-20 13:17，10 檔案 +241/-48，修 #2595 裡 MTT S5000 跑批暴露的三處 TileOPs 側失敗。其一，torch_musa 會重新命名 PrivateUse1，test_backend.py 與 test_kernel_dispatch.py 裡按 "privateuseone" 註冊的 reader 因此讀不到，改用 torch.device("privateuseone").type；其二，torch_musa 在匯入時列印內容，導致比對整段 stdout 的匯入檢查失敗，新增 tests/fresh_interpreter.py 只讀一行帶標記的結果，七處此類檢查統一切換；其三，離 CUDA 環境下不帶 Triton 的 torch-compile 路徑恢復可用。

來源：https://github.com/tile-ai/TileOPs/pull/2658

3.6 TileOPs：SM89 單行單列走向量 GEMM（#2660）

合於 10-20 10:35，3 檔案 +87/-11。把既有的 CUDA-core GEMV 實現開到 SM89：左運算元單行配轉置權重、右運算元單列不轉置兩種情形複用同一 kernel body，兩行交叉點仍按 SM90 校準。同時按所選裝置的共享記憶體預算過濾調優候選，被接納的最大 staged ring 為 96 KiB，實測生成的程式另宣告至多 192 位元組歸約暫存；單行/單列的輸入若連續儲存起始於未對齊元素偏移，複用既有對齊 helper 處理。

來源：https://github.com/tile-ai/TileOPs/pull/2660

3.7 TileOPs：三筆 builder 快取與調優契約修復（#2662 / #2663 / #2664）

三筆同在 10-20 13:16 合入。#2662 給 SM89 FP8 grouped GEMM builder 加 32 項 LRU 快取，與既有 SM90 builder 及倉庫約定對齊，四個形狀引數相同的重複呼叫複用 JIT 工廠；#2663 給密集 GLA subchunk prefill 的兩個 builder 同樣加 32 項 LRU，快取鍵保留形狀、scale、啟用 dtype 與 gate dtype，launch 執行緒配置留作內層工廠引數；#2664 恢復分頁 GQA 普通調優 supplier 的 12 輸入契約——此前期待 8 個輸入卻返回 9 個，漏掉三個 query/key/value scale，並移除不受支援的 num_split 候選鍵。三筆均宣告無裝置側效能主張、計算體不變。

來源：https://github.com/tile-ai/TileOPs/pull/2662、https://github.com/tile-ai/TileOPs/pull/2663、https://github.com/tile-ai/TileOPs/pull/2664

3.8 TileOPs 在審 11 筆：SM89 三線並進

視窗內更新的在審 PR 集中在 SM89：NSA 稀疏注意力的 top-k 選擇（#2675 把選擇範圍擴到 2048 chunk、#2674 按 group48 切 tile、#2673 補齊每個請求的 top-k 輸出槽位）、分頁 DSA（#2669 首次支援、#2670 複用 scale 與共享 value）、W4A16 窄 tile（#2671 小 M 用更窄 tile、#2672 把 M64 一併納入）。另有 #2667 剔除超出共享記憶體的 GQA 調優 tile、#2654 減少小 token 數的 W4A8 工作量、#2515 給密集 GQA 加 attention sinks、#2490 擬退役帶 KV cache append 的舊 GQA 前向。

來源：https://github.com/tile-ai/TileOPs/pull/2675、https://github.com/tile-ai/TileOPs/pull/2669、https://github.com/tile-ai/TileOPs/pull/2672

3.9 TileFoundry：0.0.3 公告與測試重構（#247 / #246）

#247 在 README 的 Latest News 增加三條 10/2026 條目：0.0.3 釋出、Qwen3.8-27B 預填充示例（#229 / #236）、Apple AMX 預填充示例（#244），並把兩條 08/2026 條目移入摺疊的 Earlier 列表以保持最新五條。提交說明指出 README 就是 PyPI 長描述（pyproject.toml 裡 readme = "README.md"），因此公告必須在打 tag 之前落地。#246 是 51 檔案 +655/-366 的測試重構：本地與 CI 複用 ccache 與 torch extension 快取（PR 間快取隔離、按 job 統計），兩處測試改用主機側編譯的 CuTe 參考比對 MMA 佈局以替掉手寫參考與數千條引數化用例，torch 改為惰性代理匯入並按需解析 dtype。

來源：https://github.com/tile-ai/TileFoundry/pull/247、https://github.com/tile-ai/TileFoundry/pull/246

3.10 採用方：TileKernels 與 FlashQLA 視窗內無推送

DeepSeek 的 TileKernels 與 Qwen 的 FlashQLA 本視窗均無提交，最近一次分別停在 10-14 的 v2.1.0 釋出合併與 10-14 的 SM120 修復合併。兩倉在審 PR 數為零。

來源：https://github.com/deepseek-ai/TileKernels、https://github.com/QwenLM/FlashQLA

四、社群、教程與活動

4.1 社群倉：中文系統教程 tilelang-tutorial 建倉

huandu/tilelang-tutorial 於 10-20 建倉並推送，定位為”從零到一的 TileLang 中文系統教程”，覆蓋面包括運算元編寫、編譯期機制、NVIDIA 與昇騰兩條後端。此前中文材料以單篇部落格與官方文件譯文為主，成體系的教程倉屬首次出現。

來源：https://github.com/huandu/tilelang-tutorial

4.2 社群倉：CANN 社群 ops-tilelang 建倉

Atlas-Ascend-Fork/ops-tilelang 於 10-20 建倉，定位為 CANN 社群面向昇騰 NPU 的 TileLang 高效能運算元倉，按”統一管理 Kernel 實現、自動化測試用例、標準工作負載與效能基線”的方式沉澱運算元資產，目標是讓昇騰側的 TileLang 運算元可複用、可驗證、可持續演進。這與此前昇騰運算元散落在 examples/ 與 cann-bench 的狀態形成對照。

來源：https://github.com/Atlas-Ascend-Fork/ops-tilelang

4.3 工具鏈：devkit 與 VS Code 擴充套件活躍，lower trace 整體遷出主倉

easy-tilelang/tilelang-devkit（7 月建倉）與 tilelang-devkit-vscode（10-19 建倉，10-20 推送）本視窗均有活動，後者定位為在 VS Code 裡探查 lowering pass、IR 差異與 CPU C JIT 編譯。與之呼應，主倉在審的 #3583（13 檔案 +106/-4390）把 lower trace 實現、專屬環境配置與相關測試從主倉整體抽走，只保留共享的編譯器插樁介面，讓追蹤工具獨立演進。這是主倉 7 月以來”把除錯工具外接”的延續。

來源：https://github.com/easy-tilelang/tilelang-devkit-vscode、https://github.com/tile-ai/tilelang/pull/3583

4.4 社群倉：tilelangGym 與 Hexagon 後端實驗

PTO-ISA/tilelangGym（10-14 建倉，10-20 推送）用於測試不同 benchmark 與微基準在 PTO lowering 下的效能敏感度，與昇騰 PTO 線的推進同步。SoilSoi1/tilelang-hexagon 於 10-20 建倉，是 Hexagon 後端的社群實驗；主倉在審佇列裡對應的正是 #2155 [feat] Add Hexagon HMX backend support（作者 Calaweh，5 月起就”解耦各後端”討論過後續路徑）。此外 sablin39/tilelang-cuda-skills（146 星）視窗內仍在更新，用於編寫與除錯 TileLang 的 CUDA 技能集。

來源：https://github.com/PTO-ISA/tilelangGym、https://github.com/SoilSoi1/tilelang-hexagon、https://github.com/tile-ai/tilelang/pull/2155

4.5 文件與版本：文件站四次自動更新，VERSION 仍 0.1.15

tilelang.github.io 在視窗內自動更新四次（10-20 12:16、13:01、16:08 與 10-21 00:49），均隨主倉合入觸發。主倉 VERSION 仍為 0.1.15，README 的最新里程碑停在 09-30 的 Ascend 950 後端；TileOPs 的統計分支隨最後一筆合入在 10-20 22:42 重新整理，未見新 tag；TileFoundry 的 0.0.3 尚待打 tag。

來源：https://github.com/tile-ai/tilelang.github.io、https://github.com/tile-ai/tilelang

五、趨勢觀察

編譯器正確性成為本視窗的主線，而非功能擴張。 主倉 9 筆合入裡 5 筆是靜默錯誤清理：向量化假定迴圈從零起（#3579）、共享記憶體 WAW 漏判（#2821）、MMA emitter 靜默縮 K 原子（#2818）、fragment reduce 保留維崩潰（#2815）、索引位寬提升後謂詞未跟（#3550）。這些缺陷的共同點是不報錯、只出錯結果或漏屏障，屬於使用者在生產裡最難定位的一類。同日 TileOPs 的 #2661 也在修”效能上限口徑”，說明專案正把”數字可信”當成與”跑得快”同級的工程目標。

昇騰線從補示例轉向訓練側。 五筆合入裡三筆是反向或遞迴運算元（indexer_bwd、situ_glu_grad、LSTM/GRU），且 situ_glu_grad 直接對齊 Kimi K3 Stable LatentMoE 的門控啟用並給出 910B3 上與 aclnn 的交叉校驗資料。配合 #3577 對 DeepGEMM-Ascend 配置選擇與 epilogue 的對齊，昇騰側的覆蓋面正從推理前向擴到訓練反向、狀態遞迴與大模型 MoE 門控。

PTO 正在成為 AscendC 之外的第二條執行路徑。 在審的 #3512 是 2.1 萬行的向量化框架（T.Parallel → PTO VMI，目標 Ascend 950），#3516 擬把 tvm_ffi 設為 pto 目標的預設執行後端，加上 #3530、#3573、#3581、#3582 一組複製與謂詞修復，PTO 線的工程量已明顯超過單點 patch 的量級。主倉同時用 #3511 補 AscendC 側的 L0 區域性複製能力，兩條路徑並行推進而非替換關係。

工具鏈外溢到獨立倉。 一日內出現三個新倉（中文教程、CANN 社群運算元倉、Hexagon 後端實驗）與一套 VS Code 擴充套件，主倉又把 lower trace 整體遷往 devkit（#3583，刪減 4390 行）。社群側的擴充套件速度已經快於主倉的模組劃分，這與 7 月”多後端語言方言”重構的方向一致：主倉收窄為語義與 IR，工具與後端實驗外接。

CI 口徑的顯式化值得留意。 #3569 把效能迴歸鎖到 H100 並對誤標卡快速失敗、#3564 把 Ascend 構建與測試拆進同一 check 的分步、#2661 用運算元集合包絡重標張量核上限——三筆都是”讓數字可比”，直接影響後續 PR 的准入門檻。

附錄：素材與核查說明

信源核查表

信源 核查結果
tile-ai/tilelang（main） 視窗內 8 次提交、9 筆合入；VERSION 仍 0.1.15；在審 167 筆，其中 163 筆視窗內更新
tile-ai/TileOPs（main） 視窗內 9 次提交、9 筆合入；在審 16 筆，11 筆視窗內更新；統計分支 22:42 重新整理
tile-ai/tilelang-ascend（ascendc_pto） 視窗內 5 次提交、5 筆合入；在審 236 筆，7 筆視窗內更新
tile-ai/tilelang-hygon（main） 視窗內 1 次提交、1 筆合入；在審 3 筆
tile-ai/TileFoundry（main） 視窗內 2 次提交、2 筆合入；在審 1 筆；0.0.3 待打 tag
tile-ai/tilelang-metax（dev）/ musa / mlir-ascend 三倉視窗內均無提交
tile-ai/TileRT / tilescale / DeepStack 三倉視窗內均無提交（最新分別 09-24、08-03、10-05）
deepseek-ai/TileKernels / QwenLM/FlashQLA 均無提交，最新均停在 10-14
tilelang.github.io 文件站 視窗內 4 次自動更新
社群與第三方倉 新倉 3 個（tilelang-tutorial、ops-tilelang、tilelang-hexagon），活躍 3 個（devkit、devkit-vscode、tilelangGym）
Google News / Hacker News / arXiv 中英文多組查詢無 TileLang 直接相關報道；arXiv 最新相關論文仍為 2026-07-24

補充說明：搜尋介面對在審佇列給出的 updated_at 有 64 筆同落於 10-20 11:30 前後，抽查其中三筆在對應時刻無評論、無評審、無分支推送事件，判為平臺側批次重算，未計入開發活動；在審數量以各倉 is:open 計數為準。

完整信源清單

2658 後端測試與 torch-compile 基線離開 CUDA — https://github.com/tile-ai/TileOPs/pull/2658