調査期間：過去24時間（2026-09-22 07:00 ~ 2026-09-23 07:00、北京時間）。本期は通常のデイリー更新期間であり、前回との重複はない。 情報源：GitHub（tile-ai 組織28リポジトリのプッシュ核查、期間内に7リポジトリでプッシュあり；メインリポジトリで1件のマージと1件の新規オープン、レビューキューに複数の更新；TileOPs で1件のマージと5件の新規オープン、4件のクローズ；TileFoundry で2件のマージ；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.1 メインリポジトリのレビューキュー：並列ループ修正が新規オープン、TileIR バックエンドに8コミット追加（09-22）
      • 1.2 TileOPs ガバナンス収束：マニフェスト項目とエバリュエータの最後のバイパスが撤去（09-22）
      • 1.3 TileOPs パフォーマンススプリント一：Engram デコードを射影とリダクションの2段カーネルに分割（09-22）
      • 1.4 TileOPs パフォーマンススプリント二：GEMM ピンポン主ループが稠密エピローグを隠蔽、176タイルがラインアップ（09-22）
      • 1.5 TileOPs パフォーマンススプリント三：GLA 推論オペレータがラインアップ、MoE 超過ルーティングのグループ化（09-22）
      • 1.6 TileOPs：roofline 合成失敗がレポート可能に、キューに3件の更新（09-22）
      • 1.7 TileFoundry：メモリメタデータとトラフィック正規化の2件のマージ（09-22）
      • 1.8 夜間スナップショット：ベンチマーク1046項目で失敗ゼロ、正確性1141項目がリリース復帰（09-23）
    1. マルチバックエンド対応（昇騰 / 海光 / 沐曦 / 摩尔線程など）
      • 2.1 昇騰：デイリーテストでワークフローレベルの失敗が再現、3件の新規欠陥チケットが 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）
    1. エコシステムと採用側
      • 3.1 採用側：TileKernels と FlashQLA は期間内にプッシュなし（09-23 核查）
      • 3.2 コミュニティプロジェクト：沐曦 C500 マルチパラダイムオペレータ開発実戦キャンプの資料を継続提出（09-22）
    1. コミュニティ、チュートリアルとイベント
      • 4.1 ドキュメントサイト：TileOPs ドキュメントサイトが1回のバージョン化デプロイ（09-22）
      • 4.2 メディアと学術側：Google News ヒットゼロ、arXiv に新論文なし（09-23 核查）
      • 4.3 バージョンリズム：新規リリースなし、メインリポジトリ v0.1.14 が21日経過（09-23）
    1. トレンド観察
      • 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 変換チェーンを4要素あたり2本の __byte_perm 命令に融合；スカラーおよび2、4、8、16、32の5種のベクトル幅をカバー；変換注釈が明示されたコードは元の lowering パスを維持；変換全体がレジスタ内で完結し、グローバルまたは共有メモリの新規割り当てを追加しない。

検証は4層：ソース生成テストが2種の E4M3 綴りと全幅をカバー；ランタイムケースが各パック4ニブルワードと独立エンコーディングテーブルを一文字ずつ比較；抽出された GEMM は全構成下で出力がベースラインとビット単位で一致（別途独立サンプリングの CPU リファレンスあり）；CUDA、ROCm、Metal、CuTeDSL の現在ヘッド CI が全て通過。

H100 パフォーマンス（同一カード、同入力、各図形100回呼び出しの中央値、4行抜粋）：

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

12 の構成における高速化幅は 2.97 倍から 5.38 倍、レジスタ使用量は 128 から 156 に増加し、オーバーフローはなし。著者が明記した境界：Blackwell 実行とモデル全体のサービングの 2 項目は未検証。

判読：わずか 161 行の新規追加による「マイクロ変換」が最大 5.4 倍のエンドツーエンドのリターンをもたらしたことは、エキスパート GEMM のように重みをタイルごとに繰り返し読み込む場面では、変換チェーンのコストを拡大鏡で見ることが大げさでないことを示している。また、TileLang 本線の最適化対象が「大きな構造」から「各層の命令の台帳」へと移りつつあることを改めて示している。

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

1.1 メインリポジトリのレビューキュー：並列ループ修正が新規開設、TileIR バックエンドに 8 コミット追加（09-22）

日付：2026-09-22 から 2026-09-23　情報源：#3269／#3247 など 4 件（完全なリストは付録参照）

  • #3269（09-23 01:48 新規開設）：let インラインを無効化した際の並列ループの降下修正——PartitionLoop におけるループ変数置換の順序を調整し、置換前にバッファインデックスを簡約化し、並列ループ用の回帰テストを追加、さらに CUDA/HIP 下の条件付き並列ループ実行カバレッジを補完。同一著者による本調査期間の 2 件目の修正（前件は 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 の 2 つの起動パスの拒否ロジックをカバー。
  • #3241 から #3244（18:16 から 18:20 に各 1 回のアクティビティ）：CuTeDSL の FP4 変換とストア降下の修正、RNG 初期化三部作（デフォルトシーケンス、void バインディング拒否、初期化不足の診断）の 4 件の修正単がオープン状態を維持、マージの動きは見られず。

キューの観察：本調査期間のメインリポジトリは 1 件のみマージ（#3204、本日の重点参照）、レビュー側は「コミットを追加し、承認はしない」状態に——TileIR とマジック除算の 2 大ラインがいずれも材料を蓄積中。

1.2 TileOPs ガバナンスの収束：マニフェスト項目と評価器の最後のバイパスが撤去（09-22）

日付：2026-09-22　情報源：TileOPs #2167

10:24 マージ（09-21 22:34 開設、約半日で完了）。#2158 のマニフェスト公式の合流を引き継ぎ、本件は「関数が定義済みの評価メソッドを持つ項目に対して暗黙的に譲る」というメカニズムをインストールポイントから撤去：統一パスを阻害する 2 つの GQA オーバーライドを削除し、「呼び出し時のペイロードを属性の上に重ねる」という同一の書き方に変更。同時に 2 種類の誤用に明確なエラーを追加——ペイロードが None（呼び出し側のタイミング問題）とペイロードが非マッピング（著者の配線ミス）。背景データは対照単 #2175 の振り返りに由来：09-19 のあるコミットポイントで、実装済み 175 項目のうち 19 の公式合成が失敗し、#2158 と本件の前後で修正完了したが、当時「次に失敗するのは誰か」を報告する層は存在しなかった。

1.3 TileOPs パフォーマンススプリント一：Engram デコードを投影とリダクションの 2 段カーネルに分割（09-22）

日付：2026-09-22　情報源：TileOPs #2173

16:50 新規作成（1ファイル +265/-108）。旧実装はバッチ行ごとに1つのスレッドブロックを持ち、2回の投影を直列ループ内で連鎖的なスカラー積み込みで行い、重みはどのブロックとも共有していなかった——H200上ではデバイス帯域4.8 TB/sのうち6～34 GB/sしか出ず、またすべてのマニフェストワークロードでtorch.compileベースラインより遅かった。新構造は2段構成：投影はd次元でブロック分割し、行列積で重みを1回読むだけでバッチ全体にサービス提供（Bが16以下なら単一のMMAタイルに収まる）し、ついでにキャッシュシフトも完了する形に変更。残りのステップ（3つのRMSNorm、ゲート、空洞畳み込み、SiLU）はすべてd方向に沿ったリダクションのため、第2段として発射し、バッチ行ごとに1ブロックとした。もう1点、説明に書き加えた発見がある：2つの行列積が同一パイプライン本体内にある場合、一部のタイル形状でパイプラインステージが黙って誤読される——3形状×30種のタイル/ステージ数の組み合わせをスキャンした後、2ブロックをグリッド軸に載せる形へ変更し、単一ブロック・単一チェーンは全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のエピローグを対面するコンシューマの主ループに隠す：1つのプロデューサと2つのコンシューマwarpgroupが、交互の永続ループタイル上で動作し、主ループは順序付きmbarrierでハンドオーバーすることで、一方のコンシューマのエピローグが他方の主ループの下で実行される。計算はこうだ——デュアルコンシューマ構造ではエピローグ期間中テンソルコアが空転し、タイルあたり固定で約3.1千サイクル（ブロック幅176の場合は5.2千）、これは32ラウンドの主ループの9%～18%を占め、まさにcuBLASLtの176x128カーネルとのDeepSeek-V3プリフィル行における全差距である。付随対応：エピローグを2つのステージングタイルのローテーションに変更（従来は隠蔽されない最後のブロックで11回の書き戻しを直列化し、1回の発射ごとに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項目が通過、6形状が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は開設3分後にクローズ。
  • 3件クローズ：W4A16 GEMV高速化（#2159）、W4A16グリッドK分割（#2170）の2件のパフォーマンス探索をクローズ；08-17に開設したGLAプリフィルパイプライン（#1931）をクローズ、その分割スキャンの考え方は#2174に吸収済み。

1日で3件のパフォーマンス単（Engram、GEMM、GLA）に加え1件のMoE最適化が同時に在场するのは、TileOPsにとって近年で最も密集したパフォーマンスコミット日である。

1.6 TileOPs：roofline 合成失敗を報告可能に変換、キューに3件の更新（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. マルチバックエンド适配（昇騰 / 海光 / 沐曦 / 摩尔線程など）

2.1 昇騰：毎日テストがワークフローレベルの失敗を再現、三件の新規欠陥チケットが A5 ハードウェア経路と自動同期を指摘（09-22 から 09-23）

日付：2026-09-22 から 2026-09-23　ソース：毎日テスト #1831／#1830／#1824／#1825

  • 每日テスト再現失敗（#1831、09-23 06:29 自動起票）：バッチジョブは約1時間半の実行後に失敗で終了（ワークフローレベル失敗、テストケースレベルではない）。09-22 06:35 のスナップショット方式では 2448/2448 のオールグリーンと対照的。直近3日は赤緑交替（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つの同期を混用する」の2つの設定をコンパイル時に直接拒否すべき。後者はリポジトリ内のサンプル自体にこのような設定があると名指ししている。

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）。中国語タイトルがそのまま変更説明となっており、3つの内容からなる。第一に、Mamba-2 の状態空間双対（SSD）チャンクスキャンの NPU エキスパートカーネル最適化とラッパー層への統合——前状態ロードの向上、L0C ダブルバッファ計算、ベクトル分岐のデータ再利用、デフォルト設定・設計文書・チューニングログの同時更新。第二に、オペレータフローの整備——最適化タスクの負荷分散とベンチマークケース選択の修正、ベンチマークからの負荷リスト生成、実際にテストされたカーネルファイルに基づく性能結果の記録、ゲートで最終ファイル・テストカバレッジ・レポートデータを検証。第三に、TileOPs レポートの自動生成と検証の新增、統合時にモード変数を自動設定、SSD 再実行と2回目チューニングの結論をモードライブラリ・ケース・ToDo 記録に蓄積。本件は同一調査期間内の昇騰適応リポジトリの 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 ブランチ上の修正が拡張再作成された——元の3ファイル版（FP32 MMAC K とフラグメントパッキングの共有）を5ファイル版（+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 拡張リポジトリが本調査期間で3件連続プッシュ：マルチコア分割スキャンの S3 と P6 検証（14:27）、P10 性能マトリクス（16:05）、P10 ホスト側ソースコード検証修正（16:13）。当該リポジトリは「TileLang プログラミングモデルを算能 TPU ターゲットへ持ち込む」ことを位置づけとし——TileLang の Python フロントエンドを保持しつつ、TPU 降下、コード生成、JIT ランタイム統合を追加し、target="tpu" ターゲット、PCIe と仿真の2つの実行モード、TPU 専用プリミティブ（コピー、行列積、縮約、逆平方根、回転位置エンコーディングなど）を提供し、BM1690 を主線として、09-20 からハードウェア検証と段階的チューニング（シングルコア、マルチコア、性能ロードマップ P8 から P10）に入っている。リポジトリは活発に開発中で、コミットを歓迎すると表明している。これは TileLang コミュニティに現れた最初の公開 TPU バックエンド経路である；同調査期間の MLIR 昇腾の Mamba 分割スキャン合流と対照すると、同一アルゴリズムファミリーが同じ日に2つの非 NVIDIA ターゲット上に現れたことになる。

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

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　出典：コミュニティ訓練キャンプ教材リポジトリ

本調査期間で2件のコミット：第二講「ベクトル加算」の TileLang と九齿の双実装対照演習を完成（10:29）、リモートインスタンスワークフロー用に操作エージェントスキル設定を補充（10:32）。当該教材リポジトリは沐曦 C500 算力を基盤とし（イメージ内に TileLang 0.1.9、特定バージョンツールチェーンを包含）、演習シーケンスは：デバイスと算力環境、TileLang と九齿の加算対照（分割と端数ブロック）、Softmax と GEMM の縮約と数値安定性、AI エージェント支援オペレータ開発と検証、その後 Llama オペレータ段階（接続、正確性、性能、エンドツーエンド）へ進む。リポジトリ履歴にはコミュニティ算力計画のアップストリームブランチとのマージ痕跡が見られ、コミュニティ教学方向への継続的投入に属する。

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

4.1 ドキュメントサイト：TileOPs ドキュメントサイトのバージョン化デプロイ1回（09-22）

日付：2026-09-22　出典：TileOPs ドキュメントサイト

08:40 に自動デプロイ1回（静的サイトジェネレータ 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 の性能モデル論文で、期間内に新規プレプリントなし。メディア側は連続2番目の平穏な期間。

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. トレンド観察

5.1 変換オペレータがファーストクラス市民に

「FP4 をどう FP8 に変えるか」だけを担う 161 行の変更が 2.97 から 5.38 倍のエンドツーエンド高速化をもたらした。前提は、それが繰り返し読み込まれる重みパス上に現れることだ。これと並行して、TileOPs の性能に関する 3 件（Engram 拆分、GEMM 搬送隠蔽、GLA 分塊）も、いずれも「同じデータ塊が何回読まれ、どのキャッシュ階層を流れるか」を最適化している。オペレータレベルの構造が次第に安定すると、収益は持続的にデータ搬送とフォーマット変換へ移行する——これはなぜメインリポジトリが精密符号化変換の 1 件を局所的な微調整ではなく正規のエントリとしてマージするのかも説明する。

5.2 TileOPs は治理シーズンから性能シーズンへ

先週のキーワードは「間違いを正す」（公式、物理、溯源）だったが、当調査期間は 1 日以内に性能単 3 件とルーティング最適化 1 件が同時に在场し、しかも新規起票は概ね対照ベンチ（torch.compile、cuBLASLt、参照実装、vLLM）とビット単位一致の宣言を自前で備えている。治理が残した台帳は性能作業の信用資産へと変わりつつある。すなわち、各性能単はチェックリストとベンチによって独立的に再検証できる。

5.3 昇騰の赤緑交替と A5 の実ハードウェア検証

デイリーテストの 3 日間における赤緑の交替は、バッチ実行環境の安定性がまだ収束していないことを示す；一方 #1830 が露呈した問題はより代表的だ——検証マトリクスは実機で 910B 世代をカバーし、仿真で 950 世代をカバーしており、ちょうど両側ともデバイスパスのアーキテクチャ標号を迂回したため、欠陥は実 950 上で「起動即クラッシュ、標号変更後は静かに誤計算」という 2 形態で露呈した。世代を跨ぐハードウェアの適配深度は、いま「コンパイルできる」から「実機で校正する勇気がある」段階へと進んでいる。

5.4 空白とリスク点

4 点：その一、メインリポジトリのマージペースは当調査期間でわずか 1 件、TileIR と魔法除算の 2 大ラインはいずれも「加料未盖章」状態にあり、レビュー帯域がボトルネックになっているかは観察に値する；その二、リリース停滞はすでに 21 日に達し、一方で下流（TileOPs）は 0.1.14 以上へのハード依存を宣言し始めており、バージョンウィンドウとエコシステム採用の間のテンポには協同が必要だ；その三、昇騰 A5 の出力正確性問題（標号変更後の静かな誤り）にはまだ修正単がなく、もし事実なら 950 世代の可信度ナラティブに影響する；その四、海光特性ブランチには依然として PR がなく、昇騰が回退された大型マージにもやり直しのスケジュールが見えず、2 本の国産ラインの「落地在途」状態が継続している。

付：素材と核查説明

情報源核查表

情報源 核查結果
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 に新規プレプリントなし

完全情報源リスト