调研窗口：过去 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 无新预印本

完整信源清单