调研窗口：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 计数为准。

完整信源清单