調査期間：過去24時間（2026-09-18 07:00 ~ 2026-09-19 07:00、北京時間）。本期は通常のデイリー更新期間であり、前回との重複はない。 情報源：GitHub（tile-ai 組織の28リポジトリのプッシュ時刻を全量核查、期間内に6リポジトリでプッシュあり；メインリポジトリの2件のマージと5件の新規PRを逐一再確認、PR本文・変更ファイル数・追加削除行数を含む；TileOPsの5件のマージと1件の新規PR；昇騰リポジトリの日次回帰レポート、CI変更、2件のコミット；TileOPs-nightlyの夜間スナップショットのベンチマークと正確性XMLを全量解析；Sunriseバックエンドリリースリポジトリとブランチの核查）、Google News RSSの中英語複数クエリ（プロキシ経由）、Hacker News、arXiv、採用側リポジトリ（TileKernels / FlashQLA）

本期インデックス

  • 今日の重点：メインリポジトリで新規CUDA Tile IR実行バックエンドを公開、134ファイル、約3.6万行追加（09-18）
    1. コアプロジェクトの進展
      • 1.1 シンボリックループレイアウトの単射性証明を復元、静的と動的の混在T.Parallel回帰を修正（09-18）
      • 1.2 ROCm CIにポータブルサンプル検証を接続、ROCm経路が収束期に入ったことを逆証明（09-18）
      • 1.3 期間内にメインリポジトリで5件の新規PR：Tile IRバックエンド、コピー幅クランプ、SM100以降の256ビットメモリアクセス、GLM-5.3とKDAサンプル（09-18/09-19）
      • 1.4 TileOPsが1日で5件マージ：ディスパッチとカーネルの分離、SM90形状の補完、ページドKVヘルパーの外部移設、スパースMLAの境界越え封じ込め、マニフェスト複合オペレータ（09-18）
      • 1.5 TileOPsがFP8バッチ行列乗算転置カーネルを新規公開、対照実装を正面から追い上げ（09-18）
    1. マルチバックエンド対応（昇騰 / Sunrise / 沐曦 / 海光 / 摩尔線程）
      • 2.1 昇騰：日次回帰1936項目が全通過、マルチデバイステストシャーディングを導入（09-18/09-19）
      • 2.2 昇騰：比較オペレータドキュメントでdtypeカバレッジを補完、ベンチマークスクリプトのバッファライフサイクルを修正（09-18）
      • 2.3 Sunriseバックエンドリリース：S2アクセラレータ向けTANGバックエンドが0.1.14候補に（09-16/09-18）
      • 2.4 沐曦、海光、摩尔線程：期間内に新規コミットなし、バージョンブランチのメンテナンスを維持（09-17）
    1. エコシステムと採用側
      • 3.1 FlashQLAが静寂を終了：同日に3件マージ、SM120逆方向融合カーネルを含む（09-18）
      • 3.2 TileOPs夜間ベンチマーク1040項目がゼロ失敗、正確性1118項目が全通過（09-18）
      • 3.3 TileKernelsとTileRTは期間内にプッシュなし（04-23、08-13）
      • 3.4 コミュニティツール：TileSight性能分析ドキュメントリポジトリが公開、対応するarXiv性能モデル論文（09-18）
    1. コミュニティ、チュートリアル、イベント
      • 4.1 組織ドキュメントサイトで期間内に1回のサイトデプロイ、デフォルトブランチに内容変更なし（09-18）
      • 4.2 メディアと学術側は期間内に新規ゼロ（09-19）
      • 4.3 バージョンリズム：メインリポジトリは依然v0.1.14、各対応リポジトリのタグは未変更（09-11）
    1. トレンド観察
      • 5.1 第2のNVIDIA側実行経路が形成：CUDAソースコード生成からCUDA Tile IRへ
      • 5.2 メインリポジトリは静かな意味エラーをコンパイル時失敗へ前倒しし続ける
      • 5.3 TileOPsは性能と契約を二軸並行、夜間ベンチマークが緑に転換
      • 5.4 採用側が回暖、FlashQLAは1日で3件マージ
      • 5.5 バックエンドマトリックスの拡張：昇騰一極から複数バックエンドリリースの併存へ
  • 付：素材と核查説明

今日の重点：メインリポジトリで新規CUDA Tile IR実行バックエンドを公開、1コミットで134ファイル

日付：2026-09-18　出典：tilelang #3247 新增 CUDA Tile IR 実行バックエンド

本期間で最も重い内容はメインリポジトリのレビューキューに現れた：tileirという名前の実行バックエンドがPRとして提出され、変更規模は134ファイル、約35829行追加、111行削除、0xtaruhiによるコミット、北京時間09-18 20:40に作成され、期間内に継続更新された。

これはTileLangプログラムをNVIDIAのCUDA Tile IRに下沉させ、cuTileランタイム経由でアセンブリ成果物をロードして起動するもので、ターゲットバージョンの組み合わせはCUDA Tile IR 13.4バインディング、tileiras 13.4、cuTile 1.5。既存のCUDAバックエンド（C/CUDAソースコードを直接生成してnvccに渡す）と比較すると、これは意味層がより上位の新しい経路である：TileLangの動作が直接Tile IRに落ち、コンパイルと最適化はNVIDIA自身のタイルレベル中間表現に委ねられる。

付随する変更も同様に体系的で、これがプロトタイプではなく製品化基準で書かれていることを示している：

  • バックエンドに JIT コンパイル、カーネルキャッシュ、自動チューニングの 3 箇所を接続し、tilelang/jit/adapter/tileir、tilelang/cache、tilelang/autotuner にいずれも変更あり；型付き IR、下沈と pass の中核は tilelang/tileir に配置；
  • pass 設定項目を 1 つ追加し、Tile IR の実体化を起動する前（キャッシュからの復元経路を含む）に、既存のソース言語意味論チェックをなお実行し、設定可能な無効化スイッチも保持；
  • 新しいツールチェーン下での完全なサンプルカバレッジを復元し、そのうちの 1 つの具体的な作業は、手書きのホスト側 pybind バインディングを nvcc と分離し、拡張ヘッダーファイルが CUDA 13.4 下でクリーンにコンパイルできるようにすること；
  • 2 篇のドキュメント（コンパイラ内部とプログラミングガイドを各 1 篇）と、固定バージョン TileIR バインディングを専門にビルドする CI ジョブを 1 つ追加。

著者が提示したテスト計画は、単体テストと下沈用例、JIT とキャッシュとチューニングの経路、および全サンプルの回帰をカバーしている。説明しておく必要があるのは、この PR が調査期間終了時点でなお未マージ状態にあり、変更規模が大きく、対象ツールチェーンのバージョンが新しいため、最終的にメインラインに取り込まれるかどうかはレビュー次第であるという点だ。今号でこれを重点に挙げた根拠は、これが調査期間内で最大の実質的なエンジニアリング内容を提供しており、かつ TileLang のバックエンド路線選択を指し示していることにある。

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

調査期間総覧：メインリポジトリのデフォルトブランチでは調査期間内にマージが 2 件のみ（09-18 14:56 と 09-19 01:56 に各 1 件）だが、レビューキューは活発——調査期間内に新規で 5 件の PR が開設され、いずれも未マージ状態にある。つまり、メインリポジトリの今調査期間の重心は「新規経路のコミット + 防御的修正のコミット」にあり、マージのペースはやや遅い。TileOPs 側は逆で、単日で 5 件をマージした。

1.1 シンボリックループレイアウトの単射性証明の復元、静的と動的が混在する T.Parallel の回帰修正（09-18）

日付：2026-09-18　情報源：tilelang #3233 シンボリックループレイアウトの単射性証明の復元／関連欠陥票 #2906

メインリポジトリの今調査期間で唯一の意味論修正であり、v0.1.12 からメインラインまでの間の回帰を修正したもの。sepcnt がコミットし、4 ファイル、+198/-13、09-18 14:56（北京時間）にマージ。

トリガーとなるシナリオは非常に具体的だ。T.Parallel のイテレーション空間が静的と動的の混在形態（例えば (16, n) で n が T.dynamic を取る）である場合、レイアウトはパディングで埋められた末尾を持ち、そのループレイアウトは単射だが全単射ではなく、定義域を列挙できない。従来この経路上の判定は「チェックしない」に後退していたが、途中のある変更で実際に証明を試みるようになり、しかもシンボリックなストライドを扱えなかったため、この種のカーネルはメインラインで直接「利用可能なレイアウトが見つからない」と報告されるようになった——v0.1.12 では動作していた。

修正はシンボリックなパディング付きループレイアウトの単射性証明を復元した。検査対象のイテレーションマッピングから逆写像の構築を試み、次に定義域上で往復の等価性を証明する。著者は PR 内で 2 種類の判定手段の盲点の差異を呼び出し箇所に明記しており、両方とも保持されている——これは単純に旧来の挙動へ戻したのではなく、正当性の論証を補ったことを意味する。

第 2 の独立した部分は、シンボリックな共有メモリタイルにレイアウトを付加することを拒否するもので、前の部分と同一バッチでコミットされ、同一著者がレビュー中にスコープを再画定した結果に属する。

1.2 ROCm CI にポータブルサンプル検証を接続、ROCm 経路が収束期に入ったことを逆証（09-18）

日付：2026-09-19　情報源：tilelang #3165 CI でポータブルサンプル検証を実行

09-19 01:56（北京時間）にマージ。内容は ROCm CI ジョブに小規模なホワイトリストを追加し、テストディレクトリ下に重複した用例一式を維持するのではなく、サンプル自身の正当性経路を直接実行するというもの。ホワイトリストは 4 種類をカバーする：Seer アテンション、汎用 Top-K、スパースマルチヘッド潜在アテンション前向き、テンソルベースのグループ行列積。

この変更の意義は、カバレッジの來源の変化にある。従来 AMD 側の検証は専用に維持されたテストコピーが担っていたが、現在は「サンプル即テスト」である。あるバックエンドがサンプル自体を回帰資産として使い始めるのは、通常そのバックエンドのサンプルがベンチマークとして使えるほど安定し、メンテナがそのために別途テスト一式を敷く必要がなくなったことを示す。

1.3 調査期間内にメインリポジトリで新規 5 件の PR：Tile IR バックエンド、コピー幅クランプ、SM100 以降の 256 ビットメモリアクセス、GLM-5.3 と KDA サンプル（09-18/09-19）

日付：2026-09-18 から 2026-09-19　情報源：#3246 コピー幅クランプ／#3247 Tile IR バックエンド／#3248 256 ビットメモリアクセス／#3249 KDA デコードサンプル／#3250 GLM-5.3 圧縮

今日重点紹介した Tile IR バックエンドのほか、調査期間内に新規に開かれた項目が 4 件あり、作成時間順に並べると次のとおりです。

その一、#3246（09-18 15:39）は T.copy と T.async_copy の結合幅の上限を実際に到達可能なベクトル幅にクランプし、従来の致命的ログを置き換えます。従来は未対応の幅を渡すと LOG(FATAL) で直接プロセスを終了していましたが、変更後は利用可能な値にクランプしてコンパイルを継続します。これは前号の「静黙なエラーを明示的な失敗へ前倒しする」方向とは逆ですが補完的です——ここでは「直接クラッシュする」を「降格して継続する」に変えており、判定基準は幅の上限が能力の制約であってユーザーの意味的な誤りではないという点にあります。

その二、#3248（09-19 01:35）は 256 ビットのグローバルアクセスの適用対象を修正します。SM100 以降のアーキテクチャかつ CUDA 12.9 以上でのみこの幅を発行し、旧アーキテクチャでは 128 ビット経路に戻し、旧アーキテクチャでのネガティブテストも追加しました。この項目は前号のアトミックなベクトル幅の計画と同じ種類の作業であり、いずれも新しい広いベクトル能力に関して従属条件を補完するものです。

その三とその四はいずれも ROCm 方向です：#3249（09-19 02:23）は安全ゲート付きの KDA デコード例を新規追加し、TileLang でパックデコードカーネルを書き、スロットインデックスでインデックスされる循環状態プールをその場で更新し、出力と状態の一致性、マルチステップ、空状態インデックス、順序が乱れたスロット、構成可能な境界などの正確性カバレッジを補いました；#3250（09-19 06:42）は GLM-5.3 の k プール圧縮とキャッシュ書き込みを新規追加し、次元ごとの softmax プーリング、正規化 Hadamard-128 変換、ベクトルごとの FP8 量子化を含み、FP8 の K 値と FP32 スケーリングを呼び出し側が保持するページドキャッシュに書き込みます。

注目すべきは、これら ROCm 方向の新しい内容がいずれも具体的なモデル向けの具体的なオペレータ（GLM-5.3 の圧縮アテンション、KDA ゲート付き線形アテンションのデコード状態）であり、包括的なバックエンド能力の補完ではないという点です。これは AMD 側の推進が「バックエンドが使える」から「新しいモデルのネイティブオペレータもここで必要だ」へと移ったことを示しています。

1.4 TileOPs は一日で 5 件をマージ：分派とチューニングの分離、SM90 形状の補完、ページド KV ヘルパーの外部移設、疎な MLA の越界収束、マニフェスト複合オペレータ（09-18）

日付：2026-09-18　情報源：#2147 マニフェスト複合オペレータ／#2149 疎な MLA の越界／#2150 ページド KV ヘルパーの外部移設／#2151 SM90 形状の補完／#2152 分派とチューニングの分離

TileOPs は調査期間内に 5 件をマージし、その性質は 3 種類に分かれます：

契約類——#2147（08:36 マージ）はオペレータマニフェストが複合オペレータを記述できるようにします。これは前号で未マージの状態で報道した項目であり、調査期間内に着地しました。同時に、以前は複数箇所に散在していた重複する導出ロジックを収束し、nullable 出力をサポートします。前号でその問題リストはすでに詳しく展開したので、ここでは繰り返しません。

分派の正確性——#2152（19:27 マージ）は「チューニング要求」と「実装選択」を分離します。従来、tune というパラメータはカーネルの構築方法にのみ影響すべきでしたが、2 つの特殊化実装が分派条件として使用していたため、同じ形状でも呼び出し側がチューニングを要求しただけで異なる実装が選ばれ、そのうちバッチ行列積テンプレートはチューニング要求を直接拒否していました。修正後はセレクタカーネルがチューニングと無関係になります。

盲点の補完——#2151（15:42 マージ）は SM90 上で誰も担当していない形状区間を補います：基本 GEMM カーネルは SM90 全体を除外し、汎用 GEMM カーネルは TMA がアドレッシングできる呼び出しのみを扱い、両者を差し引くと空きが残ります。具体的にはオペランドが半精度で K が 8 の倍数でなく、かつ M が 2 より大きい場合です。修正により基本カーネルがこの部分を引き受けます。

正確性の収束——#2149（13:02 マージ）は 2 箇所を修正します：疎なマルチヘッド潜在アテンションのデコードのギャザー操作は従来因果上界のみをチェックしており、top-k スロットが系列長または -1 で埋められるとキャッシュが保持していない行を読んでしまうため、修正は上界を系列長マイナス 1 にクランプし、各インデックスに対して非負チェックを行います；もう一箇所は断片化レイアウト下でのページドアテンションの計時を信頼できるものにします。

構造的リファクタリング——#2150（13:22 マージ）は 5 つのページド KV キャッシュヘルパー関数をグループ化クエリアテンションモジュールから移設します。これら 5 つの関数（インターリーブブロックテーブル構築、断片ブロックテーブル構築、ページドキャッシュの行取得、論理系列に応じたページドキャッシュの充填、単位キャッシュスケーリング構築）はいずれもグループ化クエリアテンション専属ではなく、従来はマルチヘッドアテンションモジュールが逆依存せざるを得ませんでしたが、現在は独立した層になります。

5 件のマージに共通する点は：TileOPs の現在の主要なエンジニアリング量は「新規オペレータの追加」ではなく、オペレータが増えた後に露呈した分派の一致性、モジュール境界、メモリ安全性にあるということです。

1.5 TileOPs が FP8 バッチ行列積転置カーネルを新規開設、正面から参照実装を追随（09-18）

日付：2026-09-18　情報源：TileOPs #2153 結合アクセスカーネルで FP8 の B オペランドを転置

ウィンドウ内でTileOPsで唯一新規に開かれたPR（09-18 16:18更新、未マージ）。背景は非常に率直に書かれている。FP8バッチ行列積フォワードオペレータはtrans_b=Falseの5つのユースケースのうち4つで対照実装に敗れ、最悪の一档では0.34倍まで後れを取った。作者はまず対照実装とfp32リファレンスの一致性を再確認し、対照がカンニングしていないことを確認したうえで、Bオペランドの転置をマージアクセスのカーネルで行う方式に変更し、共有テンプレートへのパッチを続けることを選ばなかった。

この項目は前号のバッチ行列積高速化（共有GEMMテンプレートへの変更、H200で最大1.44倍）と同じ戦線の延長線上にある。バッチ行列積は標準形状ですでに対照に追いつき、あるいは逆転しているが、残る短板はデータ型のバリアント（FP8）とレイアウトのバリアント（Bの転置が必要）といった辺角に集中している。共有テンプレートの汎用性に影響するかどうかは、マージ後に夜間ベンチマークの回帰結果を見る必要がある。

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

ウィンドウ総覧：本ウィンドウの国産およびサードパーティバックエンドの格局に構造的変化が現れた——既存の昇騰、海光、沐曦、摩尔線程の4社に加えて、tile-ai組織の下に新しい加速器向けのバックエンドディストリビューションリポジトリ（Sunrise）がすでに存在し、候補リリースブランチまで進んでいる。既存4社のバックエンドのうち、ウィンドウ内でコミットがあったのは昇騰のみである。

2.1 昇騰：デイリー回帰1936項目が全て通過、マルチデバイステストシャーディングを導入（09-18/09-19）

日付：2026-09-19　情報源：tilelang-ascend デイリーテストレポート #1813／CI マルチデバイステストシャーディング #1812

昇騰側のデイリー定時テストは北京時間09-19 05:52にレポートを出力：1936項目が全て通過、失敗0項目、通過率100%。前日（09-18 05:46の1925項目）とその前日（09-17の1919項目）と対照すると、ユースケース総数は2日間で純増17項目となり、全緑を維持している——これは「上流が継続的に新能力を統合し、昇騰側の回帰は依然として破綻しない」ことの直接的な証拠である。

同じウィンドウ内で、同リポジトリは別途CI変更（#1812、タイトルは汎用マルチデバイステストシャーディングの追加）を開いた。09-18 16:31作成、当日19:22時点でも更新中、未マージ。ユースケース数が持続的に増加し、単機の回帰時間がそれに伴い長くなるため、シャーディングは流れに沿った対応である。

2.2 昇騰：比較オペレータドキュメントでdtypeカバレッジを補完、ベンチマークスクリプトのバッファライフサイクルを修正（09-18）

日付：2026-09-18　情報源：tilelang-ascend #1602 比較オペレータドキュメントの更新とdtypeカバレッジの補完／#1779 ベンチマークスクリプトのバッファ返却トークンのライフサイクルを修正

ウィンドウ内の昇騰リポジトリの2件のコミットはともに09-18 15:10と15:31（北京時間）に着地した。1件は比較オペレータのドキュメント文字列を更新し、データ型カバレッジテストとAPIドキュメントを補完。もう1件はbench_sfa内のアキュムレータと出力一時バッファの返却トークンのライフサイクルを修正し、バッファが使用完了前に回収されることを防いだ。いずれもオペレータ能力の拡張ではなく、既存オペレータのドキュメント、テストカバレッジ、ベンチマークスクリプトの堅牢性を補完するものである——2.1の回帰規模の増加と併せて見ると、昇騰側は現在「能力はすでに展開済み、重点は品質と保守性に移行」という段階にある。

2.3 Sunrise バックエンドディストリビューション：S2加速器向けTANGバックエンドが0.1.14候補に（09-16/09-18）

日付：2026-09-18　情報源：tile-ai/tilelang-sunrise リポジトリ

tile-ai組織の下に、これまで本デイリーレポートが取り上げていなかったリポジトリがウィンドウ内のプッシュリストに入った：tilelang-sunrise、2026-08-26にリポジトリ作成。その自述の位置づけはTileLangのSunrise S2/TANGバックエンドディストリビューションである——Sunrise S2は大規模モデル推論向けの国産GPGPU、TANGはそのコンパイル・ランタイムスタック（リポジトリはTANG Runtimeと付随するtorchバックエンドパッケージ、マッチするTritonパッケージを要求する）。提供されるオペレータ例は行列積、逆量子化行列積、FlashAttention、Flash線形注意力、Flashマルチヘッド潜在注意力デコード、原生疎注意力をカバーし、すなわち主リポジトリと同じセットの示例面を維持している。

進捗状況：リポジトリはウィンドウ内にプッシュがあった（09-18 11:03）が、デフォルトブランチの最終コミットは09-04で止まっている。リリース準備を担う候補ブランチ上では、最新のコミットは09-16のバージョン更新で、バージョン番号を0.1.14+sunrise.1.1.0に押し上げ、すなわち主リポジトリのv0.1.14ラインまで追随済みである。リポジトリには別途、処理待ちの依存関係アップグレードPRが一批と1本のCIブランチがある。

読み取りのポイント：これは「バックエンドディストリビューション」であり「パッチブランチ」の形態ではない——独立したリポジトリ、独立したリリース番号（メインリポジトリのバージョン番号に接尾辞を付加）、独立した CI。これは海光の feat/hcu-... ブランチ、摩尔線程の接尾辞付きバックポートブランチと合わせて、三種類の異なる対応組織方式を構成している。当該リポジトリの自己記述と例がメインリポジトリと同構であることから、TileLang が NVIDIA/AMD/昇騰以外に、さらにもう一つの推論アクセラレータ経路がリリース可能な状態に入りつつあると見なせる。

2.4 沐曦、海光、摩尔線程：調査期間内に新規コミットなし、バージョンブランチのメンテナンスを維持（09-17）

日付：2026-09-17　情報源：tilelang-metax／tilelang-hygon／tilelang-musa

三社の対応リポジトリは 24 時間の調査期間内にいずれもコミットがなく、直近のプッシュはそれぞれ 09-17 17:38、09-17 20:25、09-17 03:47（北京時間）で、いずれも調査期間より前であり、前回既報の内容に属する：沐曦の非同期コピー行列積とそのテスト修正、海光の多段ストレージアドレスリベースと非同期パイプラインのマージ、摩尔線程の MUSA 5.3.0 ドキュメント。三社のバージョンタグはいずれも調査期間内に更新されておらず、最新タグはそれぞれ沐曦はリリースなし、海光はリリースなし、摩尔線程は v0.1.14+musa.1（09-11）のままである。

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

3.1 FlashQLA が静寂を終える：同日に三件をマージ、SM120 逆方向融合カーネルを含む（09-18）

日付：2026-09-18　情報源：FlashQLA #34 SM120/121 逆方向融合カーネル／#41 SM100 KKT ソルバ占有率／#44 可変長テールブロックの非同期パイプライン

前回のレポートでは、「採用側の調査期間内は静か」において FlashQLA にプッシュがないことを明記していたが、本調査期間では同日に三件をマージし、しかも時刻が北京時間 09-18 15:51 から 15:53 に高度に集中しており、一度の一括収束である。

三件の内容はそれぞれ以下のとおり：

  • 新規ハードウェアサポート（#34）：ブロック単位のゲート付きデルタ則に SM120/SM121 の逆方向融合カーネルを追加。実装は概ね以前 Hopper 上のパイプラインを踏襲しており、主な差異は共有メモリのリダクション戦略——SM120 の共有メモリ上限が低いため、リダクションはこの制約に沿って再設計する必要がある。
  • 占有率チューニング（#41）：固定長と可変長の二種類の KKT ソルバカーネルに、ストリームあたりの最小マルチプロセッサ常駐ブロック数の注記を追加。目標は各ストリームマルチプロセッサ上に 128 スレッドのスレッドブロックを八個常駐させることであり、KT 数学、レイアウト、起動グリッド、公開インターフェースはいずれも不変。
  • 正確性修正（#44）：可変長パッキングシナリオにおいて、最後の 64 行未満のタイルが以前は次のシーケンスへ越読していた。修正では完全なタイルの直接メモリアクセスのファストパスを保持し、不完全なテールブロックには述語付きのゼロ埋め非同期コピーを使用し、テールブロックの一時退避を複数のチャネルに分割した。

これら二種類の変更は同じ事柄を指し示している：FlashQLA（通義千問側の TileLang ベースのゲート付き線形注意機構実装）のエンジニアリング上の重心は、「新アーキテクチャ対応」から「同一アーキテクチャ上の占有率と境界の正確性」へと移りつつある。三件の集中的なマージは、そのメンテナンスリズムが逐次マージではなくバッチレビューであることも示している。

3.2 TileOPs 夜間ベンチマーク 1040 項目で失敗ゼロ、正確性 1118 項目すべて通過（09-18）

日付：2026-09-18　情報源：TileOPs-nightly スナップショットコミット／スナップショット環境メタデータ

夜間パイプラインは本調査期間において TileOPs の 4c5b441f（すなわち 1.4 の「ディスパッチとチューニングの分離」のマージ分）に対してスナップショットを生成し、ベンチマーク結果、正確性結果、環境メタデータの三件を含んでいた。二つの結果ファイルを解析して得られた読み取り値：

  • 正確性：1118 項目、失敗 0、スキップ 2；
  • ベンチマーク：1040 用例、失敗 0、スキップ 3。

前日のスナップショット（正確性 1117 項目すべて通過、ベンチマーク 1039 項目中 1 項目失敗）と比較すると、用例数はそれぞれ 1 増加し、しかも昨日唯一のベンチマーク失敗はすでに消えている——昨日失敗したのはグループ化クエリ注意機構プレフィルページングカーネルの softcap 50 設定下の用例で、エラーは対照ベースライン実装の関数シグネチャ不一致（引数欠落）に由来し、TileOPs 自身のカーネルのエラーではなかった。本日緑に転じたことは、当該対照側の問題がすでに処理されたことを示している。

環境メタデータは再現可能な要素をかなり完全に固定している。H200、CUDA 13.2、ドライバ 595.71.05、消費電力上限 700 ワット、単一ストリーム多処理プロセッサクロック 1500 メガヘルツ（上限 1980）、メモリクロック 3201 メガヘルツ、イメージはその内容識別子で記録、および全依存バージョン（うち TileLang は当該コミットでビルドされた 0.1.11 にコードネームを加えたバージョン、PyTorch 2.13.0）。ベンチマーク用例面はデコード系オペレータ（疎注意力デコード、マルチヘッド潜在注意力デコード、グループ化クエリ注意力変種）と 27 項のバッチ行列積用例をカバーし、後者こそが 1.5 で対照実装が追い越された戦場である。

3.3 TileKernels と TileRT は調査期間内にプッシュなし（04-23、08-13）

調査期間内、深度求索の TileKernels と tile-ai 組織下の TileRT はどちらもコミットがなく、最近のプッシュ時間はそれぞれ 2026-04-23 と 2026-08-13 のままである。TileRT は既に六週連続で静止している。採用側の本調査期間の動きはすべて FlashQLA に由来する。

3.4 コミュニティツール：TileSight 性能分析ドキュメントリポジトリ公開、対応する arXiv 性能モデル論文（09-18）

日付：2026-09-18　情報源：tilelang4tilesight-doc リポジトリ／arXiv 2607.22432 TileSight

調査期間内にコミュニティメンバーが新規作成したドキュメントリポジトリが出現した。テーマは TileLang の性能分析を TileSight ツールチェーンに接続することである。Python と高レベル TIR から意味、ワークロード、依存情報を抽出し、TileSight のキャッシュとパイプライン分析インターフェースに接続し、さらに実行時観測を用いて独立レポートと連合予測を生成する。リポジトリは四篇の中国語ドキュメントの閲読順序（モデルと実行時の二経路の全体方案、TileSight の段階とフロントエンドインターフェースとパイプライン分析、キャッシュモジュール、性能分析機能とプロトコル対照インデックス）を示し、性能問題を六類に分類している。パイプラインのボトルネック、階層間転送の異常、キャッシュ利用の異常、計算とメモリアクセスの重畳失敗、負荷不均衡などである。ドキュメントはレポートが「モデル予測」「実行時観測」「証拠不足」の三種の結論強度を区別することを明確に要求している。

これに対応する学術側の背景は arXiv 上の 2026-07-24 の性能モデリング論文（コアからクラスタまでのタイル級分析式 GPU 性能モデル）であり、TileLang テーマ下で最近のプレプリントである。二つの材料を合わせると、TileLang を巡る性能の解釈可能性が言語本体とオペレータライブラリから独立した第三のコミュニティの手がかりを形成しつつあることが分かる。当該リポジトリは個人プロジェクトであり、スターはまだない。収録根拠は、本調査期間内にコミュニティ側で唯一の実質的新規追加であることによる。

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

4.1 組織ドキュメントサイトは調査期間内に一度サイトデプロイ、デフォルトブランチに内容変更なし（09-18）

日付：2026-09-18　情報源：TileOPs.github.io リポジトリ

TileOPs ドキュメントサイトは調査期間内にプッシュ記録がある（09-18 08:00）が、そのデフォルトブランチには調査期間内に新しいコミットがなく、サイトデプロイ類の動作であり内容更新ではないと判断する。主リポジトリのドキュメントサイトは本調査期間にプッシュがなく、前日のボット再生成（387 個のファイル）と対照をなす——ドキュメントサイトが上流コードに追随するリズムはもともとパルス的である。

4.2 メディアと学術側は調査期間内に新規ゼロ（09-19）

テーマの Google News RSS の中国語・英語複数組のクエリは本調査期間内にヒットゼロである。英語側は直近 7 日でテーマと強く関連する報道がわずか一件、すなわち前号で既に収録した DeepSeek エンジニアが AI のカーネル記述能力を評価したあの記事であり、その公開時間は前一調査期間内であるため、本期は重複しない。中国語側はコンポーネント名、国産アクセラレータとオペレータカーネルの組み合わせクエリがすべて調査期間内の結果なし。Hacker News 側は直近五日にテーマ討論のヒットなし（検索された TileOPs、tile 類のキーワードヒット項目はいずれも無関係な話題）。arXiv 側は調査期間内に新規プレプリントなし。

4.3 バージョンリズム：主リポジトリは依然 v0.1.14、各適応リポジトリのタグは動かず（09-11）

主リポジトリの最新タグは依然 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 の線に留まり、まだ本流に追随して新バージョンへ進んでいない。

5. トレンド観察

5.1 第二の NVIDIA 側実行経路が成形：CUDA ソースコード生成から CUDA Tile IR へ

本期最值得追跡するのは #3247 の開出である。TileLang の従来の NVIDIA 経路は「タイルセマンティクスを持つ中間表現へ降ろし、CUDA ソースコードを生成し、最後に nvcc に渡す」であったが、新経路は「CUDA Tile IR へ降ろし、NVIDIA のタイル級ツールチェーンでコンパイル最適化し、cuTile ランタイム経由でロードする」に変更された。二つの経路が併存する意味は次の通りである。第一に、TileLang の抽象レベルと NVIDIA 独自のタイル級抽象が正面から接壤し始め、スケジューリングとレイアウトの意思決定をどちらが担うかが長期的な議題になる。第二に、Tile IR 経路が成熟すれば、TileLang の NVIDIA プラットフォームにおける価値提案は「より良いコード生成」から部分的に「より完全なプログラム表現とクロスバックエンドの一貫性」へ移行する。この PR の規模（一つのバックエンドがコンパイルからキャッシュ、チューニング、さらにドキュメントと CI まで揃っている）も、これが実験的ブランチではないことを示している。

5.2 メインリポジトリは引き続き暗黙のセマンティクスエラーをコンパイル期の失敗へ前倒しする

前回の観察を引き継ぐと、本調査期間のメインリポジトリの 2 件のマージのうち明確な 1 件（1.1 のレイアウト証明回復）は「密かなエラーを明確なエラー報告に変える」に属し、さらに前 3 期累計の乱数診断、非対応型組合せの遮断、スパースメタデータ形状の拒否を加えると、「コンパイル期失敗優先」はメインリポジトリの安定したエンジニアリング指向になっている。本期新增の情報はこの原則の境界である。1.3 でコピー幅の致命的ログをクランプによる降格に変えたことは、メンテナが「ユーザーのセマンティクスエラー」（失敗すべき）と「能力制約」（降格すべき）を区別していることを示す——これは原則の緩和ではなく、判断基準を明確にしたのである。

5.3 TileOPs は性能と契約を両線並行、夜間ベンチマークがグリーンに転換

TileOPs の本調査期間の 5 件のマージのうち、3 件はディスパッチ、モジュール境界、メモリ安全性であり、1 件はマニフェスト契約、純粋な性能は 1 件（新規の FP8 バッチ行列積）のみである。夜間ベンチマークが「1 項失敗」から「ゼロ失敗」に転じたことと併せて見ると、その現在の状態は次の通りである。性能ベースラインは安定し、既に対照実装の主要な形状を圧倒できているため、エンジニアリングリソースは複数オペレータ共存後の一貫性と契約へ移行している。これはオペレータライブラリ成熟期の典型的なシグナルである——オペレータが増えるほど、ディスパッチとマニフェストの正しさが上位層にとってより重要になる。

5.4 採用側が回復、FlashQLA は 1 日で 3 件マージ

前回の「採用側が静か」という判断は本期覆された。FlashQLA は同日に 3 件をマージし、新アーキテクチャ（SM120/SM121 逆方向融合カーネル）、占有率チューニング、可変長テールブロックの正しさをカバーした。これは採用側リポジトリの更新がパルス的であることを示唆する——レビューの滞留が一定量に達するとバッチでマージされ、1 日か数日の静寂はトレンドを構成しない。デイリーレポートのレベルでは、単期の静寂を採用停滞と解釈することを避ける必要がある。

5.5 バックエンドマトリックスの拡張：昇騰一極から複数バックエンドディストリビューションの併存へ

本調査期間で発見された Sunrise バックエンドディストリビューションは、新しい格局の読みを与える。TileLang のバックエンドエコシステムはもはや「メインリポジトリ内蔵のバックエンド」と「ベンダーが組織内で開いた対応リポジトリ」の二形態に留まらず、独立したバージョン番号と CI を持つバックエンドディストリビューションも出現した。現在までに識別された対応形態は合計 3 類である——昇騰の独立対応リポジトリ（マルチブランチ、毎日回帰を含む）、海光のフィーチャーブランチと接尾辞付きバックポートブランチ、摩尔線程のバージョン整合バックポートブランチ、そして Sunrise の独立ディストリビューション。形態の差異自体が各ベンダーの TileLang への投入深度と製品化程度を反映しており、国産アクセラレータの TileLang エコシステムへの依存度を判断するための利用可能な指標である。

5.6 本調査期間の空白とリスク点

三点を注記する必要がある。第一に、メインリポジトリの調査期間内のマージは 2 件のみで、うち 1 件は回退型修正（v0.1.12 の挙動回復）であり、メインラインの純増能力は限定的である。第二に、#3247 のような超大規模変更が一旦マージされると、既存の CUDA 経路とキャッシュ形式への回帰面について追加観察が必要であり、本期はまだ証拠がない。第三に、本調査期間では新タグもリリースも見られず、メインリポジトリは 09-02 の v0.1.14 以降、2 週間以上にわたってリリースがなく、レビューキューが継続的に蓄積している。

付：素材と検証説明

情報源検証表

情報源 検証結果
tile-ai 組織（28 リポジトリ） 調査期間内に 6 リポジトリでプッシュあり：tilelang、TileOPs、TileOPs-nightly、tilelang-ascend、tilelang-sunrise、TileOPs.github.io
メインリポジトリ tilelang デフォルトブランチ 2 件マージ（#3233、#3165）、新規 5 件の PR（#3246 から #3250）、新タグなし
メインリポジトリ夜間/組織リポジトリ TileOPs-nightly は TileOPs コミットのスナップショットを生成；TileRT、TileFoundry、tilescale、DeepStack、tilelang-puzzles は調査期間内にプッシュなし
国産バックエンド 4 社 昇騰のみ調査期間内にコミットと回帰報告あり；沐曦、海光、摩尔線程の最近のプッシュは調査期間より前
サードパーティ/新規バックエンド Sunrise バックエンドディストリビューションリポジトリは調査期間内にプッシュあり、候補ブランチバージョンは 0.1.14+sunrise.1.1.0 に到達
採用側 FlashQLA は 3 件マージ；TileKernels はプッシュなし
Google News RSS（中英複数クエリ、プロキシ経由） 調査期間内の新規ゼロ；コンポーネント名と技術語の組合せクエリも同様に調査期間内の結果なし
Hacker News 調査期間内にトピックのヒットなし、キーワードノイズは除去済み
arXiv 調査期間内に新規プレプリントなし、最近の 1 篇は 2026-07-24 の性能モデリング論文
ドキュメントサイト TileOPs ドキュメントサイトにサイトデプロイの動作あり、デフォルトブランチに内容変更なし

完全な情報源リスト