調査期間：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。

本期インデックス

  • 本日の重点：メインリポジトリの5ビットコンパイラ正確性修正が同日に着地、昇騰側では5ビット逆方向と再帰オペレータを補完、TileOPs は SM90 で3つの foundry アテンションオペレータを warp 特化プログラムに換装（10-20）
    1. コアプロジェクト進捗
      • 1.1 メインリポジトリ：ベクトル化分析に非ゼロループ下限を導入、unit-step ループと混合精度 guard を修正（#3579）（10-21）
      • 1.2 メインリポジトリ：共有メモリのクロススレッド WAW 検出を2スレッドインスタンスに変更、漏れていたバリアを補完（#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）
    1. マルチバックエンド適配（昇騰 / 沐曦 / 海光 / 摩尔線程）
      • 2.1 昇騰メインリポジトリ：L0 ローカルコピーが明示的 pitch をサポート、1つの 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 パーティションと分散の2件が審査中（#26 / #19）（10-20）
      • 2.9 沐曦 / 摩尔線程 / MLIR-Ascend：調査期間内に新規プッシュなし、3ラインは既存バージョンで停止（10-20）
    1. エコシステムと採用側（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 キャッシュとチューニング契約の修正3件（#2662 / #2663 / #2664）（10-20）
      • 3.8 TileOPs 審査中11件：SM89 の NSA top-k、ページド DSA、W4A16 ナロ우 tile の3ラインが並行進行（10-20）
      • 3.9 TileFoundry：0.0.3 アナウンスを README に記載、テストリファクタでコンパイルキャッシュを再利用（#247 / #246）（10-20）
      • 3.10 採用側：TileKernels と FlashQLA は調査期間内にプッシュなし（10-20）
    1. コミュニティ、チュートリアルとイベント
      • 4.1 コミュニティリポジトリ：中国語体系チュートリアル tilelang-tutorial を開設、オペレータ、コンパイル期と2大バックエンドをカバー（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 ドキュメント

バージョン：ドキュメントサイトが4回自動更新、メインリポジトリの VERSION は依然 0.1.15（10-21）

    1. トレンド観察

今日の重点

本調査期間に26件がマージされた（tilelang 9、TileOPs 9、tilelang-ascend 5、TileFoundry 2、tilelang-hygon 1）。新規リリースはない。三つの系統が同時に進行している。メインリポジトリは一日の大半のマージをコンパイラの正確性に充てており（ベクトル化ループの下限、共有メモリのクロススレッド WAW、MMA tile の K アトム、fragment reduce の保留次元、TIR 述語のビット幅昇格への追従）、これは「サイレントエラー」の一掃であり機能拡張ではない。昇騰側では5件のマージすべてが訓練側と再帰オペレータ（DSA スパース微調整の逆伝播、SiTU-GLU の逆伝播、LSTM、GRU）に落ち、さらに2.1万行の PTO ベクトル化フレームワークがレビュー中で、PTO は AscendC に次ぐ第二の実行パスになりつつある。TileOPs は SM90 でページド GQA フォワード、FP8 lightning indexer、MLA デコードという3つの foundry オペレータを同日に warp 特化プログラムへと換装し、併せてテンソルコア性能上限の校正基準をオペランド集合エンベロープに変更して、夜間バッチ実行における105%の偽超過を修正した。

1. コアプロジェクトの進展

1.1 メインリポジトリ：ベクトル化解析に非ゼロループ下限を導入（#3579）

10-21 00:27 にマージ、10ファイル +818/-198。#2819 の guard 修正を引き継ぎ、同時に #2669、#2616 の2件の問題をクローズ。従来の実装は f(i) と f(floor(i / W) * W) を比較して各式が各ベクトルグループ内で同値かどうかを判定しており、これはループが0から始まることを暗黙に仮定していた。ループ下限が非ゼロの場合、unit-step ベクトル化は異なるレーンのアドレスを同一グループとして計算してしまい、ブロードキャストロードやグループ全体での共有条件の証明が無効になる。新しい判定ではループの最小値を解析に取り込み、混合精度変換の移送時にネストした 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] は単一スレッドにとっては2つのアドレスだが、異なるスレッドの書き込みは重なり得る。従来の WAW 検査は2回のアクセスで同一のスレッド変数を再利用していたため、判定漏れやバリア挿入漏れが生じていた。修正方法は、同一イテレーションの WAW では2つの異なるスレッドインスタンスを用い、それぞれの 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 書き換え、アクセススコープ、ベクトル端点、競合昇格の 5 種類のテストを新規追加。

出典：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 の 2 回の CUDA CI 失敗の原因である。修正方法は、1 次元・2 次元 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 と約 7 倍の差があり、FP64 パスも大幅に削減されているため、すべてのベンチマークが存在しない回帰を報告することになる。現在、pr-regression タスクには h100 ラベルが必須であり、作業開始前に割り当てられたカードが確かに H100 であることを検証し、ラベルが誤っていれば誤解を招く数値を公開するのではなく即座に失敗する。

出典：https://github.com/tile-ai/tilelang/pull/3569

2. マルチバックエンド対応（昇騰 / 沐曦 / 海光 / 摩尔線程）

2.1 昇騰メインリポジトリ：L0 ローカルコピーの明示的 pitch 対応（#3511）

10-20 14:16 にマージ、24 ファイル +1458/-187 で、本調査期間の昇騰方向で最大の変更。従来、1 つの GEMM tile は単一の L1→L0A/L0B コピーでのみ填充でき、非ゼロのターゲット原点は拒否され、各コピーは自分の領域からコンパクト pitch を推測していたため、別々に搬送された 2 つの半分を結合してターゲットの全体ブロックにすることができなかった。MajorK/MajorMN 転置ロードも制限されていた。新たに昇騰専用パラメータ 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 の 3 つのステップとしてそれぞれ実行する。ビルドが成功しワークフローがキャンセルされていない場合、あるスイートが失敗しても残りのスイートを続行し、最終的には全体として失敗と判定する。CANN 変数は GITHUB_ENV 経由で渡す。

出典：https://github.com/tile-ai/tilelang/pull/3564

2.3 昇騰リポジトリ：DSA スパース微調整逆方向オペレータ indexer_bwd（#1887）

10-20 15:26 にマージ、2 ファイル +1294。Ascend NPU 向けに indexer_bwd を追加し、DSA スパース微調整にサービスを提供、同時に AscendC と PTO の 2 バックエンドをサポート。オペレータは lightning-indexer KL 微調整損失の dIndexQ、dWeights、dIndexK に対する勾配を計算し、可変長パックシーケンスをサポート。実装は 3 段階に分かれる：持続化 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）

2 件が同日マージされ、それぞれ +2304 と +2267。LSTM は i/f/g/o の 4 ゲートと cell state の時系列再帰をカバーし、多層スタック（numLayers ≤ 8）、双方向、batchFirst レイアウト、投影次元削減（projSize > 0、LSTMP）とオプションの bias をサポート、重みは「各層各方向に 1 tensor」の TensorList で渡し、出力は (y, hn, cn)、実装は 12 個の @tilelang.jit kernel；主力は融合 seq パスで、各（層、方向）ごとに 1 回 launch し、カーネル内で T.serial(S) に従い時間ステップごとに双 GEMM、bias ブロードキャスト、ゲーティングと状態更新を完了し、再帰と無関係な x 側ゲート寄与は独立した xgemm で全時間ステップ並列に事前計算する。GRU は 8 個の kernel で、z/r/n の 3 ゲート合一 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 を新規追加し、最適化パスの 8 ステップ、内部性能比較、CANN 比較、既知の制限とテストカバレッジを完全に翻訳し、英語版の上部に言語切り替えリンクを追加。純粋なドキュメント変更。

ソース：https://github.com/tile-ai/tilelang-ascend/pull/1801

2.7 昇騰審査中：PTO ベクトル化フレームワーク、tvm_ffi バックエンドと DeepGEMM アライメント

3本の主要ラインが同時にレビュー中。#3512（50ファイル +21022/-72）は、ユーザーが T.SimdVF(lanes=L) 内でスカラー並列の T.Parallel プログラム（要素ごと、制御フロー、リダクション）を記述できるようにし、コンパイラがPTO VMI命令へベクトル化、PTOASでコンパイル後にAscend 950上で実行する。完全な機能は複数のPRで着地し、本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の構成選択とエピローグを補完し、密・バッチ・グループ化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テストに回帰カバレッジを追加。海光リポジトリではウィンドウ内レビュー中が3件：#26 はfp4 MLSのwarpパーティション（14ファイル +261/-144）、#18 はレジスタパイプラインとwarp-divergeサポートの追加、#19 は分散関連の変更。

出典：https://github.com/tile-ai/tilelang-hygon/pull/25

2.9 沐曦 / 摩尔線程 / MLIR-Ascend：ウィンドウ内に新規プッシュなし

3ラインとも本ウィンドウにコミットなし。沐曦リポジトリの最新は09-29の0.1.15バージョン準備、摩尔線程リポジトリは09-30の0.1.15公開リリース準備で停止、MLIR-Ascendの最新は10-19のTVM隔離修正（本ウィンドウ外）。3リポジトリのレビュー中PR数はゼロで、新規ブランチ活動も見られない。

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

3. エコシステムと採用側（TileOPs / TileFoundry / オペレータライブラリ）

3.1 TileOPs：ページドGQAフォワードをpaged warp特化プログラムに換装（#2668）

10-20 22:41にマージ、8ファイル +901/-103。新規の GQAPrefillPagedWSKernel（SM90）が GQAPrefillPagedWithKVCacheFwdOp を引き継ぐ：1回のappend launchでchunkをページドに書き込み（keyは融合RoPE下で回転、両方ともFP8プール上で量子化）しクエリを回転、その後GQAPagedFwdOpのwarp特化プログラムが拡張されたキャッシュ上でアテンションを行う。このプログラムはhead dim 256（単一クエリスロット）と単一KV head上の16ヘッドより広いクエリグループ（(T * H, D) のクエリを行に平坦化）に対応する。FP8プログラムがカバーしない次元64と256のプールは、ページの16ビットミラー経由で読み取り、1回の上限は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。元の実装は 1 つの warpgroup が 64-key tile を乗算し、その後で積と等長の epilogue を実行していた（各 head が key scale を乗算、FMUL と FADD は別々）。さらに、2.5 TB/s でウィンドウ外に -inf を書き込むクリーンスキャンが 1 回あった——コミット説明によれば、これは chunk-prefill-kscale の 472 マイクロ秒のうち 425 マイクロ秒を占めている。デコード呼び出しでは単一 query が 1 つの CTA を占めて 16384 個の key を処理し、289 マイクロ秒を要した。新しい FP8LightningIndexerWSKernel（SM90）は TMA warp で 64-key tile をストリーミングし、2 つの consumer warpgroup に交互に処理させる。各 tile につき 1 回の m64n256 FP8 WGMMA を行い、consumer の 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 に移され、ページドと密集の 2 つのエントリを提供する。MLAPagedFwdOp の分割構築は従来と同じストレージを生成する。1 つのリクエストの 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 側の 3 つの失敗を修正。第一に、torch_musa は PrivateUse1 を改名するため、test_backend.py と test_kernel_dispatch.py で "privateuseone" により登録された reader が読み取れなくなる。そこで torch.device("privateuseone").type を使用する。第二に、torch_musa はインポート時に内容を出力するため、stdout 全体を比較するインポートチェックが失敗する。新たに tests/fresh_interpreter.py を追加し、マーカー付きの結果を 1 行だけ読むようにし、この種のチェック 7 箇所を統一的に切り替えた。第三に、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 に開放する。左オペランドが単一行で転置重みを伴う場合と、右オペランドが単一列で非転置の場合の 2 つのケースが同じ kernel body を再利用し、2 行の交差点は引き続き SM90 でキャリブレーションされる。同時に、選択されたデバイスの共有メモリ予算に応じてチューニング候補をフィルタリングする。受け入れられる最大の staged ring は 96 KiB で、実際に生成されたプログラムは最大 192 バイトのリダクション一時領域を別途宣言する。単一行/単一列の入力が非整列要素オフセットから連続ストレージを開始する場合は、既存のアラインメント helper を再利用して処理する。

出典：https://github.com/tile-ai/TileOPs/pull/2660

3.7 TileOPs：builder キャッシュとチューニング契約の修正 3 件（#2662 / #2663 / #2664）

3件とも 10-20 13:16 にマージされた。#2662 は SM89 FP8 grouped GEMM builder に 32 項目の LRU キャッシュを追加し、既存の SM90 builder およびリポジトリの規約に合わせ、4 つの形状パラメータが同一の重複呼び出しで JIT ファクトリを再利用する。#2663 は密集 GLA subchunk prefill の 2 つの builder にも同様に 32 項目の LRU を追加し、キャッシュキーは形状、scale、アクティベーション dtype、gate dtype を保持し、launch スレッド設定は内層ファクトリのパラメータとして残す。#2664 はページド GQA 通常チューニング supplier の 12 入力契約を復元する——以前は 8 入力を期待していたが 9 入力を返しており、3 つの query/key/value scale が欠けており、さらにサポートされていない num_split 候補キーを削除した。3 件ともデバイス側の性能主張はなく、計算本体は不変と宣言している。

出典：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 ナロータイル（#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 の項目を 3 件追加した：0.0.3 リリース、Qwen3.8-27B プレフィル例（#229 / #236）、Apple AMX プレフィル例（#244）。さらに 08/2026 の 2 項目を折りたたまれた Earlier リストへ移動し、最新 5 件を維持する。コミット説明は、README が PyPI の長い説明そのものである（pyproject.toml の readme = "README.md"）ため、告知は tag を打つ前に反映させる必要があると指摘している。#246 は 51 ファイル +655/-366 のテスト再構築である：ローカルと CI で ccache と torch extension キャッシュを再利用し（PR 間でキャッシュを分離し、job ごとに統計）、2 箇所のテストをホスト側でコンパイルした 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. コミュニティ、チュートリアル、イベント

4.1 コミュニティリポジトリ：中国語体系チュートリアル tilelang-tutorial がリポジトリ作成

huandu/tilelang-tutorial は 10-20 にリポジトリを作成してプッシュされ、「ゼロから一までの TileLang 中国語体系チュートリアル」と位置づけられ、対象範囲はオペレータ作成、コンパイル期の仕組み、NVIDIA と昇騰の 2 つのバックエンドを含む。これまで中国語資料は単編ブログと公式ドキュメント翻訳が中心であり、体系的なチュートリアルリポジトリの登場は初めてである。

出典：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 ドキュメントとバージョン：ドキュメントサイトが4回自動更新、VERSION は依然 0.1.15

tilelang.github.io は調査期間内に4回自動更新され（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

5. トレンド観察

コンパイラの正確性が今調査期間の主線となっており、機能拡張ではない。 メインリポジトリの9件のマージのうち5件はサイレントエラーの整理である：ベクトル化がループのゼロ起点を仮定（#3579）、共有メモリの WAW 見落とし（#2821）、MMA emitter が K 原子をサイレントに縮小（#2818）、fragment reduce の保留次元クラッシュ（#2815）、インデックスのビット幅拡張後に述語が追従しない（#3550）。これらの欠陥に共通するのは、エラーを報告せず、誤った結果やバリア漏れだけを生じる点であり、ユーザーが本番で最も特定しにくい類に属する。同日 TileOPs の #2661 も「性能上限の基準」を修正しており、プロジェクトが「数値の信頼性」を「速く動くこと」と同レベルのエンジニアリング目標と見なしていることを示す。

昇腾ラインはサンプル補完から訓練側へ移行。 5件のマージのうち3件は逆方向または再帰オペレータ（indexer_bwd、situ_glu_grad、LSTM/GRU）であり、situ_glu_grad は Kimi K3 Stable LatentMoE のゲート活性化に直接整合し、910B3 上で aclnn とのクロス検証データを提示している。#3577 による DeepGEMM-Ascend の設定選択と epilogue の整合と合わせ、昇腾側の対象範囲は推論フォワードから訓練バックワード、状態再帰、大規模モデル MoE ゲートへと拡大しつつある。

PTO は AscendC に次ぐ第2の実行パスになりつつある。 審査中の #3512 は 2.1 万行のベクトル化フレームワーク（T.Parallel → PTO VMI、ターゲットは Ascend 950）であり、#3516 は tvm_ffi を pto ターゲットのデフォルト実行バックエンドに設定する予定で、さらに #3530、#3573、#3581、#3582 というコピーと述語の修正群を加えると、PTO ラインの工数は明らかに単発パッチの量級を超えている。メインリポジトリは同時に #3511 で AscendC 側の L0 ローカルコピー機能を補完しており、2つのパスは置き換え関係ではなく並行して推進されている。

ツールチェーンが独立リポジトリへ溢出。 1日のうちに3つの新規リポジトリ（中国語チュートリアル、CANN コミュニティオペレータリポジトリ、Hexagon バックエンド実験）と1セットの VS Code 拡張が出現し、メインリポジトリはさらに lower trace 全体を devkit へ移行した（#3583、4390行削除）。コミュニティ側の拡張速度はすでにメインリポジトリのモジュール分割よりも速く、これは7月の「マルチバックエンド言語方言」リファクタリングの方向と一致している。すなわち、メインリポジトリはセマンティクスと IR に収斂し、ツールとバックエンド実験は外部化される。

CI 口径の明示化は留意に値する。 #3569 は性能回帰を H100 に固定し誤ラベルのカードに対して即座に失敗させ、これにより Ascend のビルドとテストを同一 check の段階に分割し、#2661 はオペランド集合の包絡でテンソルコア上限を再ラベル付けする。3件はいずれも「数値を比較可能にする」ものであり、後続 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 はタグ打ち待ち
tile-ai/tilelang-metax（dev）/ musa / mlir-ascend 3リポジトリとも調査期間内にコミットなし
tile-ai/TileRT / tilescale / DeepStack 3リポジトリとも調査期間内にコミットなし（最新はそれぞれ 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 前後に集中している。そのうち3件を抽出したところ、該当時刻にコメント、レビュー、ブランチプッシュのイベントはなく、プラットフォーム側の一括再計算と判定し、開発活動には計上していない。審査中の件数は各リポジトリの is:open カウントに準拠する。

完全な情報源リスト

2658 バックエンドテストと torch-compile ベースラインが CUDA を離脱 — https://github.com/tile-ai/TileOPs/pull/2658