調査期間：過去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時間以内にチェーン化、4件合計約9.8千行の追加（09-19/09-20）
    1. コアプロジェクトの進展
      • 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 の2バンドを統合（09-19）
      • 1.7 TileOPs 新規：グループ GEMM のテールブロック分割、CUTLASS グループカーネルを正面から追い上げ（09-19）
    1. マルチバックエンド適応（昇騰 / Sunrise / 沐曦 / 海光 / 摩尔線程）
      • 2.1 昇騰：日次回帰1936項目すべて通過、2日連続（09-20）
      • 2.2 沐曦、海光、摩尔線程、Sunrise：期間内に新規コミットなし（09-17/09-18）
    1. エコシステムと採用側
      • 3.1 夜間スナップショット：ベンチマーク1040項目と正確性1118項目がゼロ失敗（09-19）
      • 3.2 ベンチマーク信頼性ガバナンス：8行の帯域異常と同日3件の修正（09-19/09-20）
      • 3.3 採用側：TileKernels と FlashQLA は期間内にプッシュなし（09-18）
      • 3.4 移行ライン：稠密 Gated DeltaNet プリフィル移行 PR 更新（09-19）
    1. コミュニティ、チュートリアル、イベント
      • 4.1 ドキュメントサイト：TileOPs ドキュメントサイトの一度のサイトデプロイ、サイト内容は変化なし（09-19）
      • 4.2 メディアと学術側：期間内に新規ゼロ（09-20）
      • 4.3 バージョンリズム：主リポジトリは依然 v0.1.14、各適応リポジトリのタグは未変更（09-02）
    1. トレンド観察
      • 5.1 ROCm ライン：「バックエンドが使える」から「新モデルネイティブオペレータがチェーン化」へ
      • 5.2 TileOPs は一日を計測体系に投じる：まず判定を信頼できるものにし、それから速さ遅さを語る
      • 5.3 主リポジトリの本期間の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 プール圧縮とキャッシュ書き込みを行った。本期間、同一の作者が同じ日に4件を連続起票し、このチェーンをデコードテールメンテナンスから融合選択まで一気に補完、4件合計で約9767行を追加、40ファイルを変更（各件7、9、11、13ファイル）。4件はいずれもスタック依存（stacked）と標記され、そのうち #3255 は自ら「#3250 から #3254 のコミットを含み、それぞれがマージされるまで」と述べている——作者は一つの完全なデリバリチェーンとしてレビューを組織している。期間終了時点で、4件はいずれも未マージである。

このチェーンがサービスする対象は、リリース済み構成の 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 の組織方式を採用し、疎注意パス全体を一つの納品物として推し進めている。

1. 核心プロジェクトの進展

ウィンドウ総覧：メインリポジトリのデフォルトブランチに 3 コミット合入、すべて補課型（能力補充、適用面修正、テスト冗長削減）；レビューキューに新規 5 PR、うち 4 つは本日の重点である ROCm シリーズ。TileOPs は二日連続で単日 5 コミット合入し、さらに性能 PR を 1 つ新規作成；その夜間ベンチマークはウィンドウ内でスナップショットを出す。

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 実行バックエンド

既存 3 件の PR のステータス動向：

  • #3245（09-19 16:20 更新、未マージ）：未サポートの GEMM データ型組み合わせを CUDA コード生成に入る前に阻止するもので、「静かなエラーを明示的な失敗へ前倒しする」取向を継続している。
  • #3215（09-20 01:37 クローズ、未マージ）：Metal 側の「ランタイム可変の GEMM 行数」はレビュー 9 日後にクローズされ、マージには至らなかった。
  • #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）：5 用例はメインラインに対して 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 の2バンドを統合（09-19）

日付：2026-09-19　ソース：TileOPs #2156 カーネルをサービス領域ごとに改名、2つの GEMV バンドを統合

09-19 23:11 マージ、作者 lcy-seso、19 ファイル、+421/-274。

内容：各密な GEMM / BMM カーネルクラスは「兄弟クラスとの分かれ目」で命名するよう変更——メインループ構造（Tma、CpAsync、Persistent）、入力形状（Gemv）、またはスケーリング粒度（TensorScale、BlockScale）。SmallBatchGemmKernel は GemvKernel に統合：両者は本来同一のビルダーを共有し、違いは担当領域と構成ルールのみ；統合後は1クラスが3つのバンドを持ち、バンドは band_for で判定され、構築パラメータ、キャッシュ識別子、デフォルト構成、チューニンググリッドに入る。ディスパッチは不変（3バンドの和集合は元の2領域に等しい）、カーネル本体、構成ルール、チューニンググリッドはいずれも変更なし；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 の4つのワークロードのうち nt bf16 のみが真の対戦相手を持つ（fp16 では torch のグループ行列積は16回の個別呼び出しに退化し、bf16 のみが CUTLASS のグループカーネルに到達する）、そしてそれは 6.4% 遅れている。2つの根本原因：128x256 タイルは出力タイル全体（64 KiB）を共有メモリに置き、メインループは3段のパイプラインしか組めない（対照は4段）；このバッファを4段目のパイプラインに替えられる epilogue_stage_n メカニズムはこれまで密とバッチ行列積にしか開放されていなかった。メカニズムをそのままサイレントに開放するのも不可：密なグループの最終タイルは残ブロックであり、これらの行は行マスクで格納され1枚として書き出されないため、ブロック分割はかえって1往復分のステージングを余分に支払う——MoE の実際のルーティング下（各グループ最小 1 行、最大 663 行、55% のタイルが残ブロック）では 3% から 5.5% のコスト。残ブロック比率は形状の性質ではなくルーティングの性質であり選択器では区別できないため、呼び出し元が「自分が持っているのはどちらか」を宣言できるようにする。

判定：「ブロック分割するか否か」の決定権を形状推論から呼び出し元の宣言に変えることは、グループ GEMM が CUTLASS に逼近する鍵となる一歩；デフォルトパスに影響するかは、マージ後の夜間回帰を待つ。

2. マルチバックエンド適配（昇腾 / Sunrise / 沐曦 / 海光 / 摩尔線程）

期間概観：既存4社のバックエンドに Sunrise を加えていずれもコミットなし；唯一の動きは昇腾の日次回帰レポート。

2.1 昇腾：日次回帰 1936 項全通過、2日連続（09-20）

日付：2026-09-20　ソース：tilelang-ascend 日次テストレポート #1814

昇腾側の日次定時テストが 09-20 05:30（北京時間）にレポートを出力：1936 項すべて通過、失敗 0 項、通過率 100%。前日（09-19 の 1936 項）と対照し、用例数と結果はいずれも横ばい；リポジトリ内の期間中に新規コミットなし。

判定：主リポジトリの本期間の3件のマージはそれぞれ Metal、CUDA、テストに落ち、いずれも昇腾パスに触れておらず、回帰の横ばいは想定どおり。用例数が2日連続で 1936 に留まることは、期間中に上流が昇腾側に新たな用例面をもたらさなかったことを示す；そのマルチデバイステストシャーディング（#1812）は期間中に更新なし。

2.2 沐曦、海光、摩尔線程、Sunrise：期間中に新規コミットなし（09-17/09-18）

日付：2026-09-17 から 2026-09-18（各自の直近のプッシュ）　ソース：tilelang-metax／tilelang-hygon／tilelang-musa／tilelang-sunrise

4リポジトリはいずれも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が候補へ進んだ活発さは継続せず、4社の適応リポジトリは同期して静默に入った。単日の静默は傾向を構成しない（採用側には以前から「パルス状更新」の先例がある）が、観察点とはなり得る——次の調査期間も静默が続けば、各メーカーの適応のレビューはいずれもバッチのリズムで進んでいることを示す。

3. エコシステムと採用側

3.1 夜間スナップショット：ベンチマーク1040項目と正確性1118項目がゼロ失敗（09-19）

日付：2026-09-19　ソース：TileOPs-nightly スナップショットブランチ／スナップショット環境メタデータ

夜間パイプラインは調査期間内に、TileOPsの 917590ba（すなわち #2154：スナップショットリポジトリから性能履歴ウィンドウを再構築するマージ）のスナップショットを生成した（09-19 16:19 コミット）。ベンチマークと正確性の2つの結果ファイルを解析：正確性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行の帯域異常と同日3件の修正（09-19/09-20）

日付：2026-09-19 から 2026-09-20　ソース：#2155 ルーティングで選択されたエキスパートの課金／#1996 バイト監査は読み取り側のみを見る／#2154 スナップショットリポジトリから性能履歴ウィンドウを再構築

本調査期間でTileOPsの最も密なエンジニアリング投入はオペレータではなく、「ベンチマーク判定そのものを信頼できるようにする」ことにあり、1日のうちに3件：

  • #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 行はカーネル終了後に書き戻されるため、プロファイル区間の外に落ち、測定される書き込みバイトはアルゴリズム上の最小量より本質的に小さくなり、それで失敗と判定すると正しい行を誤って殺してしまう（初回実行で 3 行を誤判定）。同時に add_fwd/sub_fwd がデフォルトの alpha 乗算に対して無条件に計上していた問題（各要素を 2 FLOP で計上するが、仕様は 1）も修正し、監査に CI 入口とファミリー別実行の方法を追加した。
  • #2154（09-19 15:36 マージ）：14 日間の性能ベースラインウィンドウを「可変成果物」からスナップショットブランチ（実行ごとに 1 コミット、期限切れなし）へ移行。これまでは各実行が前回の成果物を読んでから上書きしており、あるとき API 502 によってある実行が自分自身の 1 件の記録しか公開しなかった（隣接は 14、15、19 件だったのと対照的）。

判読：3 件はそれぞれ「数式が意味に対して責任を負う」「測定が物理原理に対して責任を負う」「データが来歴に対して責任を負う」を解決する——オペレータライブラリの夜間ベースラインは上流依存としての信用の基盤であり、まず結論を信頼できるものにしてから、速い遅いを語る。

3.3 採用側：TileKernels と FlashQLA は調査期間内にプッシュなし（09-18）

日付：2026-09-18（直近のプッシュ）　情報源：TileKernels／FlashQLA

調査期間内に両採用側ともプッシュなし：TileKernels の直近プッシュは依然 04-23 で停止。FlashQLA の直近プッシュは 09-18 15:53（前号で既報の 3 件のマージ）。組織内の TileRT も同様にプッシュなし（直近 08-13、すでに 7 週連続で静止）。

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 件は 1.6 のリネーム、#2130 の GEMM メタタスクと同じ背景に属する——オペレータライブラリが数量増加後に構造を整理するもの：線形注意力、GEMM、ページキャッシュの各ラインが統一されたクラスとマニフェスト組織へ収束しつつある。

4. コミュニティ、チュートリアルとイベント

4.1 ドキュメントサイト：TileOPs ドキュメントサイトに 1 回のサイトデプロイ、サイト内容に変化なし（09-19）

日付：2026-09-19　情報源：TileOPs.github.io ドキュメントサイトリポジトリ

TileOPs ドキュメントサイトは調査期間内に 1 回のサイトデプロイ記録あり（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 は直近 5 日で主題のヒットなし；arXiv 全文検索の 9 件の主題結果はすべて本調査期間より前（最新の 1 篇は 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. トレンド観察

5.1 ROCm ライン：「バックエンドが使える」から「新モデルのネイティブオペレータがチェーン化」へ

前号の判断「AMD 側の推進は具体的なモデルの具体的なオペレータへと移行した」は、今調査期間でさらに強まった：4 本の PR がスタックチェーンの形で一度にコミットされ、GLM-5.3 疎注意 k プールの全段階をカバーし、かつリリース済みモデルの設定契約（2048 token 予算、512 プール、4 token プール粒度）に直接紐づいている。これは ROCm 側の作業面が「バックエンド能力の補完」ではなく「モデル納品」によって組織されていることを示す——新モデルリリース後、その固有オペレータが AMD 通路上でどれだけ速く揃うかが、当該バックエンドの成熟度を測る直接的な指標になりつつある。

5.2 TileOPs は一日を度量体系に投じる：まず判定を信頼できるものにし、それから速さを語る

#2154、#2155、#1996 の三件はすべてベンチマークと監査の判定ロジックに該当し、加えて調査期間内の夜間スナップショットはオールグリーンであり、メンテナンス層が「夜間の結論が正しいかどうか」を「カーネルがより速いかどうか」と同等に重要視していることを示す。この種のガバナンスのシグナル価値は次にある：測定体系が信頼できて初めて、性能比較（例えば 1.5 の 4.66 倍、1.7 の 6.4% 差）が意思決定上の意味を持つ。逆に言えば、今調査期間で露呈した「同一の誤った計算式が長時間発見されなかった」ことは、その判定ロジックのカバレッジに依然として盲点があることを示唆している。

5.3 主リポジトリの今調査期間のマージ 3 件はすべて補習型、増分はレビューキューにあり

能力の補完（Metal アトミック加算）、適用範囲の修正（256 ビットメモリアクセスのフォールバック）、テスト品質の向上（509 行削減し参照実装を補完）——3 件はいずれも負債の清算を指向し、新能力の拡張ではない。真の新しい増分はレビューキューにある：ROCm モデルオペレータが 4 件；一方、前号の大きな変更（Tile IR バックエンド）はドラフトへ移行し停滞している。主リポジトリは現在「マージは慎重に、探索は記録として保存」の二本立てを呈している：大きな路線レベルの変更はドラフト形態で沈殿させ、日常は小さな歩みで収束を進める。

5.4 バックエンドマトリクスの静黙面が拡大：日次回帰を維持するのは昇騰のみ

前調査期間には Sunrise が候補入りする動きがあったが、今調査期間は 4 社の適応リポジトリに Sunrise を加えたすべてが静黙で、唯一の動態は昇騰の毎日回帰（1936 項目すべて通過）である。単日の静黙を停滞と解釈することは避ける必要がある（採用側のパルス的なリズムには先例がある）が、この対比自体が一つの読みを与える：マルチバックエンドの格局において、「毎日可視」のエンジニアリングリズムを維持しているのは昇騰のみであり、その他の各社の活発度は週単位、あるいは月単位で観察する必要がある。

5.5 空白とリスク点

三点を指摘する必要がある：第一に、4 本の GLM-5.3 PR はすべて未マージであり、スタック依存は連鎖的なレビューを意味し、どれか一本が詰まればチェーン全体の着地を引きずる；第二に、今調査期間に修正された 8 行の帯域異常とバイト監査の誤殺（3.2）は、夜間判定ロジックが一時的に誤って動作していたこと（異常読数は最大で物理上限の 27 倍まで過大に振れた）を示し、修正後の判定基準の安定性は今後のスナップショットで継続観察が必要である；第三に、主リポジトリのリリース停滞はすでに 18 日に達し、レビューキューは継続的に蓄積し、しかも調査期間内に 9 日間稼働した 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 項目すべて通過（連続 2 日目）；リポジトリ内に調査期間内のコミットなし
その他の国産バックエンドと Sunrise 沐曦、海光、摩尔線程、Sunrise は調査期間内にいずれもコミットなし、タグ未更新
採用側 TileKernels、FlashQLA は調査期間内にプッシュなし；組織内の TileRT も同様にプッシュなし
Google News RSS（中英複数組、プロキシ経由） 調査期間内に新規ゼロ
Hacker News 直近五日間にトピックのヒットなし
arXiv トピック検索の最新一篇は 07-24、調査期間内に新規プレプリントなし
ドキュメントサイト TileOPs ドキュメントサイトに一度サイトデプロイ（内容は不変）；主リポジトリのドキュメントサイトにプッシュなし

完全な情報源リスト