调研窗口：过去 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 文档站一次站点部署（内容未变）；主仓文档站无推送

完整信源清单