調査期間：過去 24 時間（2026-09-17 07:00 ~ 2026-09-18 07:00、北京時間）。前回は試運用で、期間は 09-16 19:23 ~ 09-17 19:23 となり、本期間とは 09-17 の日中部分で重複している。重複部分について本期は状態説明と後続の進展のみを行い、重点は期間内に新規作成・新規マージされた内容に置く。 情報源：GitHub（tile-ai 組織 28 リポジトリのプッシュ時刻を全量核查、期間内に 9 リポジトリでプッシュあり。主リポジトリの期間内に新規作成された PR と欠陥チケットを逐条再確認、RNG 欠陥の分割、GEMM 型ホワイトリスト、CuTeDSL 側 FP4 修正を含む。TileOPs、TileOPs-nightly、tilelang-hygon、tilelang-ascend、tilelang-metax、tilelang-musa のブランチ、コミットとバックポートブランチを逐条照合）、Google News RSS の中国語・英語複数組クエリ（プロキシ経由）、Hacker News、arXiv、メディア報道（NeoTeo による DeepSeek カーネル自動化と TileKernels に関する報道）

本期インデックス

  • 今日の重点：TileOPs のバッチ行列積が共有 GEMM テンプレートに切り替わり、H200 で最高 1.44 倍高速化（09-17）
    1. コアプロジェクトの進展
      • 1.1 主リポジトリ RNG の三箇所の欠陥を分割修正：デフォルト乱数シーケンス、void 結果バインディング、初期化欠如時にエラーを出さない（09-17）
      • 1.2 未対応の GEMM 型の組み合わせを事前にインターセプト、nvcc の型アサーションに落ちなくなる（09-17）
      • 1.3 CuTeDSL バックエンドの FP4 変換と格納を修正、DeepSeek V4 の活性化量子化は依然 FP8 段階で停滞（09-17）
      • 1.4 ブロック量子化 GEMM の API ドキュメントと命令レベル変体が公開（09-17）
      • 1.5 前回既報内容の状態説明（09-17）
    1. マルチバックエンド対応（昇騰 / 沐曦 / 海光 / 摩尔線程）
      • 2.1 昇騰：毎日回帰 1925 項目すべて通過、オペレータ面の推進が継続（09-17/09-18）
      • 2.2 海光：MLS アドレス再ベースと非同期パイプラインが正式にマージされ、バージョンブランチへバックポート（09-17）
      • 2.3 沐曦：非同期コピー GEMM が取り込み後にブランチ保守へ移行（09-17）
      • 2.4 摩尔線程：バックポートブランチが MUSA 5.3.0 ドキュメントを担当、メインブランチは 09-11 以降静止（09-17）
    1. エコシステムと採用側
      • 3.1 TileOPs のマニフェスト化：複合オペレータ、リソースと nullable 出力が manifest に入る（09-17）
      • 3.2 TileOPs ドキュメントサイトが統一ディスパッチと新たなコンパイル境界に追随（09-17）
      • 3.3 夜間ベンチマークと正確性スナップショット：ベンチマーク 1039 項目中 1 項目失敗、正確性 1117 項目すべて通過（09-17）
      • 3.4 メディア：DeepSeek エンジニアが AI によるカーネル記述は 6 〜 12 ヶ月で自身の仕事に並ぶと予測（09-16/09-17）
      • 3.5 採用側リポジトリは期間内静か：TileKernels、FlashQLA、TileRT いずれもプッシュなし
    1. コミュニティ、チュートリアルとイベント
      • 4.1 ドキュメントサイトと API ページがボットにより再生成（09-17）
      • 4.2 学術・コミュニティ側は新規なし：arXiv と Hacker News は期間内ゼロヒット（09-17）
      • 4.3 バージョンリズム：主リポジトリの最新タグは依然 v0.1.14、TileOPs はリリースなし（09-02）
    1. トレンド観察
      • 5.1 主リポジトリの重心が「能力追加」から「サイレントエラーをコンパイル時失敗に変える」へ
      • 5.2 CuTeDSL で初めて上流 CUTLASS DSL バージョン進化との結合傷が出現
      • 5.3 国産バックエンドのリズム分化：昇騰は高頻度反復、海光は収束、沐曦と摩尔線程は保守へ移行
      • 5.4 TileOPs は高速化と契約策定を同時に行い、契約付きオペレータ層へ進化
      • 5.5 本期間の空白とリスク点

今日の重点：TileOPs のバッチ行列積が共有 GEMM テンプレートに切り替わり、H200 で最高 1.44 倍高速化

日付：2026-09-17　出典：TileOPs #2148 バッチ行列積（BMM）が共有 GEMM テンプレートに切り替え

本期間で最も重い変更は言語本体ではなくオペレータライブラリに落ちた：TileOPs はバッチ行列積フォワードオペレータ（BmmFwdOp、torch.bmm に対応）のカーネルを独自実装から共有 GEMM テンプレートのバッチ形態（GemmTemplate(BATCHED) とそれから派生するバッチカーネル）へ入れ替えた。変更は michaelwithu がコミットし、メンテナ lcy-seso がマージ、計 6 コミット。

著者が PR で示した実測データ（環境は NVIDIA H200、CUDA 13.2、PyTorch 2.13.0、TileLang 0.1.12）によると、収益は中・大形状に集中している：

形状（B,M,N,K） 型 旧版（ミリ秒） 新版（ミリ秒） 旧版比 torch-cublas 比 新版演算性能
(8, 2048, 2048, 2048) bfloat16 0.2905 0.2023 1.437 倍 1.007 倍 679.6 TFLOPS
(4, 4096, 4096, 4096) bfloat16 1.0413 0.7451 1.398 倍 1.034 倍 737.9 TFLOPS
(128, 512, 512, 2048) bfloat16 0.2942 0.2110 1.394 倍 1.021 倍 651.3 TFLOPS
(8, 1024, 1024, 1024) float16 0.0410 0.0304 1.351 倍 1.021 倍 566.0 TFLOPS
(16, 512, 512, 512) float16 0.0132 0.0118 1.110 倍 1.008 倍 362.3 TFLOPS
(64, 128, 2048, 128) float16 0.0228 0.0199 1.146 倍 1.063 倍 216.1 TFLOPS
(32, 256, 256, 256) bfloat16 0.0064 0.0065 0.985 倍 1.108 倍 166.1 TFLOPS

読み方には三つのポイントがある。第一に、新バージョンは 15 のユースケースで torch-cublas に対して一切劣っていない（1.007～1.185 倍）。小さい形状（8×128×128×128、32×256×256×256、64×128×128×2048）ではほぼ同等である。第二に、唯一のリグレッション項目は (32, 256, 256, 256) の bfloat16 で 0.985 倍、小さい形状においてテンプレートのオーバーヘッドが吸収しきれていない境界的なケースである。第三に、バッチ処理を共通テンプレートに統一したことで、アテンションとマルチヘッド構造といった共通基盤を一箇所で保守できるようになり、今後のバッチ処理オペレータの最適化は個別にコピーする必要がなくなった。

この高速化と同じバッチで合流したものに、5 つの付随修正がある。いずれも「エラーを構築期または計測期に顕在化させる」という書き方である。MoE ワークスペース検証は構築期の安全性に変更され、バッチ行列積テンプレートは実際に起動された tile 数でカウントし、H200 デバイス判定とデバイス名の大文字小文字を正規化し、アテンションカーネルの grid は手元のデバイスに応じて埋める。こうした付随的な変更は、共通テンプレートが複数のオペレータで再利用されるとき、デバイス判定とリソースカウントの堅牢性が新たな共通課題になることを示している。

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

調査期間総覧：tile-ai 組織の 28 リポジトリのうち、調査期間内にプッシュがあったのは 9 つだが、メインリポジトリのデフォルトブランチの最後のコミットは依然として 09-17 09:57 の分岐パラメータ型マッピング修正である。つまり、調査期間の後半（北京時間 09-17 20:00 以降）にメインリポジトリへの新規合流はなく、活動は「既存 PR のレビューと欠陥の切り分け」に集中している。調査期間内にメインリポジトリで新規に開かれた PR は 6 件、欠陥票は 1 件で、すべて未合流の状態である。

1.1 メインリポジトリ RNG の三箇所の欠陥を切り分けて修正：デフォルト乱数シーケンス、void 結果の束縛、初期化欠如時の無報告（09-17）

日付：2026-09-17　情報源：#3242 デフォルトシーケンスを完全な起動次元から導出するよう変更／#3243 void 結果の束縛を拒否／#3244 未初期化での取り出しを明確な診断に変更

CUDA 側の乱数インターフェースの三箇所の欠陥は、三つの独立した PR に切り分けられた（同一著者によるコミット。前身の #3239 はクローズされ、切り分けに変更）。三箇所はいずれも「型の上ではコンパイルできるが、意味の上では誤っている」というサイレントな問題である。

第一に、乱数状態の初期化はシーケンス番号を指定しない場合、スレッドブロック内の x 次元とグリッドの x 次元のみでデフォルトシーケンスを導出していた。そのため、二次元以上のスレッドブロックでは y/z 座標のみが異なるスレッドが同じ乱数サブシーケンスを共有し、取り出される乱数はバイト単位で完全に同一になる。修正では行優先順で起動済みの全次元をデフォルトシーケンスに折り込むよう変更し、一次元の場合の歴史的な値は変わらない（#3242、付随して 4 つの新テストがあり、二次元スレッドブロック、二次元グリッド、一次元互換、明示的シーケンス番号との対照をカバーする）。

第二に、乱数初期化自体は純粋な副作用のビルトインであるが、フロントエンドは「戻り値がある」ものとして記録する。ドキュメントの書き方に従って結果を束縛すると void state = ; が生成され、意味の誤りが nvcc の「不完全型」コンパイルエラーになってしまう。修正ではフロントエンドで値なし式の束縛を拒否し、レポートで変数名と問題のある式を同時に提示する（#3243）。

第三に、関数内で一度も初期化せずに直接乱数を取り出すと、空の curand 呼び出しが生成され、同様に nvcc の構文エラーという形で現れる。修正では関数レベルの事前スキャンで「初期化済みか」と「乱数ストリームを消費するか」を記録し、どちらか一つでも欠ければ TileLang 自身のエラーを報告する。著者は、チェックは関数レベルであり制御フロー感応ではないと明言している。実行期の分岐内での初期化は依然として初期化済みとみなし、確定代入解析に発展することを避ける（#3244）。

3件をまとめて読むと、メインリポジトリが現在扱っている一类のシステム的な問題が見えてくる。フロントエンド診断の欠如により、意味論的なエラーが下層コンパイラで難解な形で現れるのである。

1.2 サポートされない GEMM 型の組み合わせを事前に遮断し、nvcc の型アサーションに落ちないように（09-17）

日付：2026-09-17　情報源：tilelang #3245 CUDA コード生成前にサポートされない GEMM 型の組み合わせを拒否

一部の行列積オペランド型の組み合わせ（例えば bfloat16 掛ける bfloat16 で float16 を出力）は、以前はフロントエンドで受理され、nvcc 段階になって初めて不透明な静的アサーションで失敗していた。この PR は Ampere/Ada 世代の mma.sync 経路に対して明示的な型ホワイトリストを確立し、フロントエンド入口と C++ 命令選択の2箇所で検証を行い、サポートされない組み合わせはコード生成前に拒否され明確なメッセージを与える。サポートされる組み合わせと非 Ampere ターゲットは影響を受けず、1件のネガティブテストと3件のポジティブ回帰テストが付属する。これは本期メインリポジトリの2本目の「静かなエラーを明示的な失敗へ前倒しする」線である。

1.3 CuTeDSL バックエンドの FP4 変換と格納の修復、DeepSeek V4 の激活量子化は依然として FP8 段階で停滞（09-17）

日付：2026-09-17　情報源：不具合票 #3240／修復 #3241

期間内で最も留意すべきリスク項目は CuTeDSL バックエンド（CUDA コード生成ではなく CUTLASS DSL プリミティブを用いるバックエンド）に現れた。不具合票の記録によれば、DeepSeek V4 サンプル内の激活量子化カーネルがこのバックエンド上で動作しない。根本原因はバージョン結合であり、変換ヘルパー関数が依然として旧式のベクトル要素取得と要素挿入操作を使用している一方、nvidia-cutlass-dsl 4.7 ではこれら2つの操作の名称が変更されたため、すべての FP4 型変換が MLIR 属性エラーを投げる。同一の経路上にはさらに1箇所 FP8 ターゲット型の不一致がある。

修復 PR は FP4 変換を新版 MLIR インターフェースに変更した後、FP4 激活量子化経路は該当バックエンドを指定すればコンパイルおよびパスするようになり、FP8 ターゲット型の不一致も併せて修正された。しかし組み合わせ用例は依然として失敗する。FP8 段階で独立した libNVVM コンパイル失敗に衝突するため、この用例は当分既知失敗リストから削除できない。不具合票には他に記録すべき発見がある。このバックエンドの実際の有効化方法（環境変数によるターゲット指定）はリポジトリ内でサンプルテストのフィクスチャと2箇所のパイプライン断片のみが読み取っており、ライブラリ本体はこの変数を読まない。これはこの経路のテストカバレッジがライブラリ層を迂回して組み立てられていることを示す。

同時に指摘すべきは、本節が対応するのは 09-17 の実際の活動（午前と夕方に集中）であり、前号の時間窓と重複があることである。本号でこれを単独記載するのは、「不具合が記録された」から「不具合が半分修復され、残り部分が明確に画定された」へ進んだためである。

1.4 分塊量子化 GEMM の API ドキュメントと命令レベルのバリアントが公開（09-17）

日付：2026-09-17　情報源：tilelang.github.io コミット Update docs

ドキュメントサイトがボットにより再生成され（387ファイル）、前号でメインリポジトリに統合された分塊量子化 GEMM が公開 API ページに反映された。CUDA 方言下に分塊量子化 GEMM の完全なシグネチャ説明（スケーリングファクターを第一級入力とし、SM100 では完了バリアが要求され、デュアル CTA モードではクラスタ次元の設定が要求され、SM120 はフラグメント累加の同期経路を取る）が新規追加され、さらに3本の命令レベルの明示的バリアント——Hopper の wgmma 明示的非同期版、Blackwell の tcgen05 明示的非同期版、および両者に対応する分塊量子化バージョン——と、スケーリングレイアウト構築の入口が新たに列挙された。ドキュメントは同時に行動規約を「サポートされない組み合わせはコンパイル失敗とし、スケーリングファクターを破棄しない」と明記している。これは 1.2 の志向と一致する。新機能を追加すると同時に失敗モードをドキュメントに書き込むのである。

1.5 前号で既報内容の状態説明（09-17）

以下の内容は前号で既に報道され、期間内に意味論的変化はなく、現在の状態のみを記録する。メインリポジトリの分塊量子化 GEMM とそのバックエンドセレクタ（#3237）、原子ベクトル幅を目的アドレスで計画する性能回補（#3238）、バッチ処理パラメータ型マッピングの補完（#3229）、TileOPs の MoE インデックス小路由エキスパート経路（#2141）とカーネル選択、ビルドディスパッチ再構成（#2146）、昇騰側の NSA 前向と可変長オペレータ、動的量子化と RMSNorm 融合サンプル、沐曦の非同期コピー GEMM（#156）とそのテスト修復（#157）。以上十余項目が本ウィンドウのストック内容を構成し、本号では重複して展開しない。

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

ウィンドウ概覧：4社の国産およびサードパーティバックエンドはいずれもウィンドウ内に動きがあるが、性質は異なる。昇騰は「高頻度オペレータ補完 + 毎日回帰」で最高の活発度を維持し、海光は一度の比較的大きなバックエンド変更のマージとバックポートを完了し、沐曦と摩尔線程の重心は既にバージョンブランチとドキュメントメンテナンスへ移っている。

2.1 昇騰：毎日回帰 1925 項すべて通過、オペレータ面の推進継続（09-17/09-18）

日付：2026-09-18　情報源：tilelang-ascend デイリーテストレポート #1811

昇腾適応リポジトリのデイリー定時テストが 09-18 05:46（北京時間）にレポートを出力：1925 項目のテストが全て合格、失敗 0 項目、添付は 30 日間保持。これは本調査期間内で唯一の日をまたぐデータポイントであり、「上流メインリポジトリが新規オペレータを連続してマージした後も、昇腾側の回帰は全緑を維持している」ことの証拠となる。調査期間内に当該リポジトリには 4 件のコミット（NSA フォワード、NSA フォワード可変長、動的量子化サンプル、RMSNorm 動的量子化融合サンプル）があり、いずれも 09-17 午前にあり、前期に既報の内容である。調査期間後半に当該リポジトリに新規コミットはない。

2.2 海光：MLS アドレスリベースと非同期パイプラインが正式マージ、バージョンブランチへもバックポート（09-17）

日付：2026-09-17　情報源：tilelang-hygon #10 バッファストレージのリベースと非同期コピーパイプラインの引き継ぎ

海光側の 1 件の変更が本調査期間中にメインブランチへ正式マージされた（19 ファイル、+540/-31）。内容は 2 点：第一に、多段ストレージ（MLS）のアドレスリベースの安定化で、バッファ操作のリベース注釈と対応する属性マッピングを追加し、バックエンドコード生成がブロックインデックスに従ってバッファストレージのアドレスをリベースできるようにし、ついでにこれらのパス上のレイアウト推論も高速化した；第二に、非同期優先の並列コピーのコミットとウェイトをソフトウェアパイプラインスケジューラの管理に委ねた。変更はフォーマットチェックも通過した。マージ後、当該リポジトリは 09-17 20:25（北京時間）に同一の変更を v0.1.12 バージョンブランチへバックポートし、さらに三次元スライススコープ下の行列積レイアウトに対する修正も持ち込んだ。新規作成された開発ブランチ feat/hcu-mls-rebase-device-flags にはパイプライン管理とフォーマット仕上げのコミットもある。海光は依然として 4 社の中でバックエンドコードの変更が最も重い一家である。

2.3 沐曦：非同期コピー GEMM がマージ後、ブランチ保守へ移行（09-17）

日付：2026-09-17　情報源：tilelang-metax ブランチ一覧

沐曦側は調査期間内に新規のメインブランチコミットはなく、到達点は依然として 09-17 午前にマージされた MACA 非同期コピー行列積サポートとそのテスト修正（前期既報）である。現在の活動はバージョンブランチとテスト保守に集中しており、4 社の中で変更幅度が最も小さい一家である。

2.4 摩尔線程：バックポートブランチが MUSA 5.3.0 ドキュメントを担い、メインブランチは 09-11 から静止（09-17）

日付：2026-09-17　情報源：tilelang-musa ブランチ一覧

摩尔線程適応リポジトリのメインブランチの最終コミットは 09-11 で、調査期間内のプッシュはバージョンバックポートブランチにあり、内容は当該ブランチが 09-17 午前に確定した MUSA 5.3.0 ドキュメントのコミット（前期既報）である。ブランチ一覧によれば、その保守方式は「1 つの上流マイナーバージョンに対してサフィックス付きのバックポートブランチを 1 つ対応させる」もので、現在は v0.1.12 の一線に留まり、メインリポジトリ v0.1.14 にはまだ追随していない。

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

3.1 TileOPs のマニフェスト化：複合オペレータ、リソース、可空出力が manifest へ（09-17）

日付：2026-09-17　情報源：TileOPs #2147 マニフェストで複合オペレータを表現

TileOPs 側は本調査期間中に最も規模の大きい変更をコミットした（34 ファイル、+2552/-370、未マージ）。これはオペレータマニフェスト（manifest）が複合オペレータの内部構造、リソース、可空出力を記述できるようにし、同時にこれまで散在していた重複した導出ロジックを整理する。作者が挙げた問題リストは、このプロジェクトの成熟度のボトルネックをよく示している：マニフェストは以前、公開オペレータの外部契約しか記述できず、そのため実装済みの 6 つの複合オペレータは自分が複合オペレータであることを宣言する場所がなかった；ある融合エキスパートオペレータは 2 つの一時バッファを通常のシグネチャ入力として宣言しており、ワークスペースに「結果依存の値取得」のセマンティクスを与えているに等しい；共有エキスパートオペレータにはマニフェスト項目がなく、ベンチマークは独自に演算能力とバイト数の計算を備え、クラス名も既定の命名規約に違反している；空値を返す固定出力位置は以前は表現できなかった。これらは性能問題ではなく、インターフェース契約の問題である——本日の重点にあるバッチ行列積のテンプレート再利用と併せて見ると、TileOPs は性能と契約の 2 本の線を同時に補強している。

3.2 TileOPs ドキュメントサイトが統一ディスパッチと新しいコンパイル境界に追随（09-17）

日付：2026-09-17　情報源：TileOPs.github.io #51 統一カーネルディスパッチへの追随

ドキュメントサイトは前期にマージされたオペレータディスパッチのリファクタリングを同期した：カーネル取得エントリの新しいシグネチャ（キーとビルド方法を明示的パラメータとする）、PyTorch カスタムオペレータ登録と仮実装登録の境界、そしてオペレータ仕様タプルから生成されるコンパイル境界の記述方法。中国語・英語の両ドキュメントを同一バッチで修正し、作者は検証章節でインターフェースページ検査スクリプト、ドキュメントサイトビルド、全量テストの実行状況を記録している。オペレータの上流変更後にドキュメントが当日追随したことは、TileOPs のドキュメントフローがリファクタリングに追随できるまで自動化されていることを示している。

3.3 夜間ベンチマークと正確性スナップショット：ベンチマーク1039項目中1項目失敗、正確性1117項目は全通過（09-17）

日付：2026-09-17　情報源：TileOPs-nightly スナップショットコミット／スナップショット記録ファイル

TileOPsの夜間パイプラインは本調査期間、「バッチ行列積テンプレート化」のコミット（まさに本日の重点のマージ結果）に対してスナップショットを生成し、ベンチマーク結果、正確性結果、および1つの環境メタデータを含んでいた。メタデータは再現に必要な要素をすべて固定している：具体的なコミット番号、コンテナイメージはそのダイジェストで記録、GPUモデルと電力上限、SMクロック設定、および全依存関係のバージョン（この記録ではCubeバージョン13.2、PyTorch 2.13.0、TileLang 0.1.11にこのコミットのビルド識別子を加えたもの）。2つの結果の読み値：

  • 正確性：1117項目のテストがすべて通過、2項目スキップ、所要時間は約219秒；
  • ベンチマーク：1039ケース中1項目失敗、失敗項目はGQAプレフィルページングカーネルのsoftcap 50構成でのケースで、エラーは対照ベースライン実装の関数シグネチャの不一致（1つの引数が欠落）に由来し、TileOPs自身のカーネルのエラーではない——この種の失敗はまさに「対照側もリグレッションに入れる必要がある」ことの必要性を示している。

ベンチマークで最も輝いているのはスパースアテンション・デコード系のオペレータである：主流のバッチ構成でTileOPsは1.86ミリ秒、313.98 TFLOPS、対照実装は19.88ミリ秒、30.79 TFLOPS、他の2つの対照（融合アテンション実装5.61ミリ秒、コンパイル版PyTorch 16.64ミリ秒）もその後ろに続く；長コンテキスト低top-k変種は0.50ミリ秒、291.55 TFLOPS、対照は20.36ミリ秒；マルチヘッド潜在アテンション・デコードは4kコンテキスト（半精度）で0.0385ミリ秒、対照は0.3147ミリ秒。

2点の境界を説明しておく必要がある：これらの数字は夜間パイプラインの単一実行の記録にのみ現れるもので、横断評価ではない；うちスパースアテンションの項目の対照実装は素朴な実装（30.79 TFLOPS）に属し、プロダクショングレードのインデックスアテンションとは直接比較できない。

3.4 メディア：DeepSeekエンジニアがAIによるカーネル記述は6〜12ヶ月で自身の仕事に匹敵すると予測（09-16/09-17）

日付：2026-09-17　情報源：NeoTeo：DeepSeek engineer forecasts AI-written GPU kernels could match his work

これは調査期間内に検索された唯一のテーマ関連のメディア報道である。記事はDeepSeekエンジニアのShengyu Liuの公開判断を記録している：約1年の間に、AIのカーネル作業における役割はドキュメントを読む、コードを読む、欠陥を修正するから、低レベルグラフィックスアセンブリを読み、命令ストールを分析しオペレータを最適化するへと進んだ；彼は6〜12ヶ月以内にAIが記述するカーネルが自身の水準に達するか超えると予測し、人間の役割は目標の定義、性能プロファイリング結果の解釈、産出の評価へと移るとする。記事は同時にTileLangエコシステムを背景として整理している：TileKernelsは純粋にTileLangで書かれたカーネルライブラリで、ゲーティング、混合エキスパートルーティング、量子化、転置、および2種類の接続オペレータをカバーし、環境要件は2世代のHopper/Blackwell級GPU、Python 3.10以上、PyTorch 2.10以上、TileLang 0.1.9以上、CUDA 13.1以上；そしてNVIDIAが以前に推論モデルでアテンションカーネルを生成した検証器クローズドループ実験（1級数値正確率100%、2級96%、単一クローズドループ約15分）を「限られた条件下で既に走通している」対照として引用している。

位置づけとして明確にしておく必要がある：これは予測的な報道とエコシステム概説に属し、TileLang本体のいかなる変更も含まず、上記能力の独立した検証も構成しない；収録の理由は、これが本調査期間内で唯一TileLangを産業人材構造の文脈に置いて議論した公開資料であり、採用側（TileKernels）のナラティブに直接関連するからである。

3.5 採用側リポジトリは調査期間内静か：TileKernels、FlashQLA、TileRTいずれもプッシュなし

調査期間内、深度求索のTileKernels（最後のプッシュ04-23）、通義千問のFlashQLA（08-26）、および同じくtile-ai組織下のTileRT（08-13）はいずれもコミットがなかった。TileRTは既に5週連続で更新がない。採用側の静止状態は本調査期間ではリスクシグナルを構成しないが、今日の動きは完全に上流の言語とオペレータライブラリ側によって提供されていることを意味する。

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

4.1 ドキュメントサイトとAPIページがボットによって再生成（09-17）

日付：2026-09-17　情報源：tilelang.github.io コミットリスト

メインリポジトリのドキュメントサイトは当日、ロボットにより上流コードに基づいて再生成された（387 ファイル）。目に見える内容の変化は行列積関連の API ページに集中している（詳細は 1.4 を参照）。この「上流マージ、ドキュメントサイトが当日追随」というチェーンは本調査期間において正常に稼働しており、ドキュメントとコードの乖離は発生していない。

4.2 学術・コミュニティ側は新規なし：arXiv と Hacker News は調査期間内ゼロヒット（09-17）

本調査期間内に arXiv で TileLang を検索しても新規論文はなく、直近の一篇は 2026-07-24 の性能モデリング方向の論文（TileSight）で、背景資料に属する。Hacker News は直近五日間、主題に関するディスカッションのヒットなし。コミュニティ側も調査期間内にチュートリアル、チュートリアル型リポジトリ、イベント告知類の内容はなく、本期は増分項目を設けない。

4.3 バージョンリズム：メインリポジトリの最新タグは依然 v0.1.14、TileOPs はリリースなし（09-02）

メインリポジトリの最新タグは依然 v0.1.14（09-02 リリース）で、調査期間内に新規タグはない。TileOPs はこれまでリリース記録とタグがなく、その対外的な状態はドキュメントサイトと夜間スナップショットが担っている。

5. 趨勢観察

5.1 メインリポジトリの重心は「能力の追加」から「サイレントエラーをコンパイル時失敗に変える」へ

本調査期間にメインリポジトリで新規作成された 6 件の PR のうち、5 件は同じ族に属する。乱数のデフォルトシーケンスエラー、void 結果のバインド、初期化欠落がエラー報告されない、型の組み合わせが満たされていないのに下位コンパイラでクラッシュする、そしてサブバイト浮動小数点変換のインターフェースが旧式である、というものだ。共通点は、以前はいずれもコンパイルが通り結果も出るが、結果が誤っているか、エラーメッセージが無関係な層を指していたことである。加えてディスパッチ再構築により「能力を持たないバックエンドのサイレント降格」がコンパイル失敗に変更されたことから、メインリポジトリの現在の優先事項は、エラー境界を言語層に設けることであり、オペレータ面を拡大し続けることではないと判断できる。

5.2 CuTeDSL に初めて上流 CUTLASS DSL バージョン進化との結合障害が出現

CuTeDSL バックエンドは本調査期間において、上流のバージョン改名により打ち抜かれた問題が初めて露呈し、かつ修正後も FP8 段階が libNVVM でスタックしている。これは構造的リスクを示唆する。サードパーティ DSL を土台とするバックエンドの安定性は上流インターフェースの安定性に依存するが、こうしたバックエンドは現在、ライブラリ層で可読な有効化方式と通常の回帰カバレッジを欠いている。この経路に依存する採用側（特に DeepSeek 系量子化オペレータに関心を持つチーム）にとって、本調査期間の進展は追跡に値する。

5.3 国産バックエンドのリズム分化：昇騰は高頻度迭代、海光は収束、沐曦と摩尔線程はメンテナンスへ

四社の差異は本調査期間において特に明確である。昇騰は毎日 1925 項目の回帰とオペレータ補完で推進を維持。海光はコード生成とパイプラインに関わるやや大きめの変更を完了し、直ちにバージョンブランチへバックポートしており、「マージと収束」に属する。沐曦は非同期コピー GEMM の取り込み後、テストとブランチメンテナンスへ移行。摩尔線程のバックポートブランチは v0.1.12 のラインで止まっており、メインリポジトリの v0.1.14 にはまだ追随していない。これから見ると、国産対応の全体リズムは依然健全だが、上流の最新言語能力をどこまで追随できるかで、各社の差はすでに開いている。

5.4 TileOPs は一方で高速化し一方で契約を立て、契約付きオペレータ層へ進化

本日の重点であるバッチ行列積の高速化（最高 1.44 倍、公式ライブラリに遅れを取らない）とチェックリスト化された変更（複合オペレータ、リソースセマンティクス、nullable 出力）が同日に推進され、加えて夜間パイプラインが各コミットに再現可能なスナップショット（コミット番号、イメージダイジェスト、クロック設定）を残すことで、TileOPs の位置づけは「一群のオペレータ実装」から「契約付きで再現可能な対照が可能な一群のオペレータ」へ移行しつつある。これは下流の推論エンジン統合にとって良いことだ。契約が明確であることはオペレータの数よりも接入コストを低減できる。

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

空白面：メインリポジトリのデフォルトブランチは調査期間の後半に新規マージなし。採用側リポジトリ（TileKernels、FlashQLA、TileRT）はすべて静止。学術・コミュニティ側はゼロヒット。新バージョンリリースなし。リスク面は二条ある。其一、CuTeDSL 上の DeepSeek V4 激活量子化の FP8 段階は依然として打通しておらず、組み合わせ用例はまだ既知の失敗リストにある。其二、本調査期間に新規作成された 6 件のメインリポジトリ PR はすべて未マージで、乱数の三欠陥と型ホワイトリストはいずれもレビュー待ち行列にあり、修正の着地時期は不確定である——この三点は次期に重点的に照合すべき対象である。

付録：素材と核查説明

情報源核查表

情報源 検証結果
GitHub 組織プッシュ検証 tile-ai 組織 28 個のリポジトリのプッシュ時間を全量検証、調査期間内に 9 個のリポジトリでプッシュあり：メインリポジトリ、オペレータライブラリとそのサイトおよび夜間データリポジトリ、昇騰、沐曦、海光、摩尔線程、ドキュメントサイト
メインリポジトリコミット明細 デフォルトブランチの調査期間内 2 件（いずれも前号で既報の内容）、最終コミット時間は 09-17 09:57；調査期間内に新規 PR 6 個、欠陥票 1 個、いずれも未マージ
TileOPs 調査期間内に 3 件マージ（うち 2 件は前号で既報）、新規 PR 1 個；夜間データリポジトリは最新コミットのスナップショットを生成
TileOPs-nightly snapshots ブランチの調査期間内に 1 回プッシュ；ベンチマーク 1039 項目中 1 項目失敗（対照実装のシグネチャ問題）、正確性 1117 項目は全通過
tilelang-ascend 調査期間内に 4 件コミット（前号で既報）に加えデイリーテストレポート 1 部（1925 項目全通過）
tilelang-hygon メインブランチ 1 件マージ、バックポートブランチ 2 件、開発ブランチ 1 件；変更にはアドレスリベースと非同期パイプライン引き継ぎを含む
tilelang-metax デフォルトブランチの調査期間内 2 件（前号で既報）、新規コミットなし
tilelang-musa デフォルトブランチに調査期間内のコミットなし、プッシュは v0.1.12 バックポートブランチに発生；メインブランチの最終コミットは 09-11
tilelang-mlir-ascend / TileFoundry / DeepStack / tilescale 調査期間内はいずれもプッシュなし、直近はそれぞれ 09-16 / 09-15 / 09-15 / 08-25
TileRT 調査期間内にプッシュなし、直近は 2026-08-13、5 週連続で更新なし
採用側リポジトリ TileKernels / FlashQLA 調査期間内にプッシュなし、直近はそれぞれ 2026-04-23 / 2026-08-26
Google News RSS（中英文複数クエリ） 主題語、コンポーネント名とチーム語の組み合わせクエリ後、調査期間内に利用可能なヒットは 1 件のみ（NeoTeo 報道）、残りは同名ノイズと株価行情記事であり、除外済み
Hacker News 直近 5 日間で主題語のヒットゼロ、ヒット項目はいずれも同名エントリ
arXiv 調査期間内に新規論文なし、直近 1 篇は 2026-07-24 の性能モデリング論文
ドキュメントサイトとタグ ドキュメントサイトは当日再生成（387 ファイル）；メインリポジトリの最新タグは依然 v0.1.14（09-02）、TileOPs はタグとリリースなし

完全な情報源リスト