調査期間：2026-10-28 07:00 ~ 2026-10-29 07:00（北京時間、24時間）。

情報源：GitHub tile-ai 組織のリポジトリ別検査（tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / ドキュメントサイト）+ マージ済み・審査中真値検索（マージ済み 24 件、審査中更新 48 件）+ 新規 issue 全件確認（6 件）+ コミットレベル diff とファイルリスト検査 + リリースページと tag 検査 + サードパーティバックエンドリポジトリ検査 + Google News 中英語 6 グループクエリ（プロキシ経由）+ Hacker News + arXiv。

本期インデックス

  • 本日の重点：昇騰 910 A2/A3 の NPUIR バックエンドが mlir-ascend 主干に統合され、504 項目のセルフテストが全通過。TileOPs セレクタはビジー時間基準のキャリブレーションに変更され、manifest のリグレットが 5.79% から 0.48% に低下。24 時間で 24 件がマージ、48 件がレビュー中に更新、新規 issue 6 件
    1. コアプロジェクトの進展
      • 1.1 メインリポジトリ：スカラー読み取りのインデックス係数がレーン数に混入しなくなり、行幅 32768 以上のコンパイルクラッシュをクローズ（#3453）（10-28）
      • 1.2 メインリポジトリ：バルク all-reduce がスカラーブランチでスレッド区間を解析し、batch>1 時に 2048 個の出力が全て誤る問題を修正（#3341）（10-28）
      • 1.3 メインリポジトリ：SIMT アトミック領域の形状チェックを追加し、範囲外領域をコンパイル時に拒否（#3465）（10-28）
      • 1.4 メインリポジトリ：スパース MMA の K テールブロックが暗黙にスキップされなくなった（#3367）（10-28）
      • 1.5 メインリポジトリ：atomic_addx4 の対象 dtype を float* に絞り込み（#3369）（10-28）
      • 1.6 メインリポジトリ：非 restrict パラメータの handle サフィックスが切り捨てられなくなった（#3366）（10-28）
      • 1.7 メインリポジトリ：TMA ディスクリプタは検証済みの名前のみを記録（#3484）（10-28）
      • 1.8 メインリポジトリ：profiler 出力インデックスを統一的に検証し、スカラー形式とリスト形式で同一の境界ルールを適用（#3486）（10-28）
      • 1.9 メインリポジトリ：T.Parallel の coalesced_width を統一的に IntImm へ変換（#3374）（10-28）
      • 1.10 メインリポジトリ：テスト基盤で cache 敏感な用例を without_kernel_cache 経由に変更（#3695 / #3696）（10-28）
      • 1.11 新規欠陥 3 件：SM120 で 13 例のサンプルが失敗、IfStmtBinding の指数関数的コンパイル、without_kernel_cache が再コンパイルを強制しない（#3701 / #3700 / #3699）（10-28）
    1. マルチバックエンド対応（昇騰 / 海光 / ROCm）
      • 2.1 昇騰：910 A2/A3 の NPUIR バックエンドを mlir-ascend 主干に統合、504 項目のセルフテストが全て通過、72 例のサンプルのうち環境起因の失敗は 1 例のみ（#207）（10-28）
      • 2.2 昇騰メインリポジトリ：Bisheng のビルド識別情報をバイナリキャッシュキーに追加（#3691）（10-28）
      • 2.3 昇騰メインリポジトリ：手書きパイプラインで設定レジスタのフェーズを保持（#3624）（10-28）
      • 2.4 昇騰リポジトリ レビュー中：W4A4 int4×int4 GEMM の結果誤りの根本原因と修正方法（#1731）（10-28）
      • 2.5 昇騰リポジトリ レビュー中：a2a3 スケジューラの移行、100 ファイル 18453 行（#1951）（10-28）
      • 2.6 昇騰リポジトリ レビュー中：Carver が選択された SDK に応じて A3 リソース予算を読み取り（#1955）（10-28）
      • 2.7 昇騰リポジトリ レビュー中：AI Core Exception Dump の依存を CANN 9.2.0 に引き下げ（#1956）（10-28）
      • 2.8 昇騰リポジトリ レビュー中：ドキュメントを T.Tensor に変更し、T.Buffer DSL インターフェースを非推奨化（#1957）（10-28）
      • 2.9 海光：HCU 通常コピーの LDS swizzle 機能ブランチ、18 ファイルに 5 つの新規テストを含む（#30）（10-28）
      • 2.10 ROCm：pip 版 SDK の ROCm 10 サポートをマージ、MI355X が gfx900 と誤判定されなくなった（#3549）（10-28）
    1. エコシステムと採用側（TileOPs / TileFoundry）
      • 3.1 TileOPs：セレクタをビジー時間基準のキャリブレーションに変更、manifest のリグレットが 5.79% から 0.48% に低下（#2784）（10-28）
      • 3.2 TileOPs：非 NT レイアウトを転置永続カーネル経由に変更、2112×7168×4096 TN が 195.3 から 175.3 マイクロ秒に低下（#2789）（10-28）
      • 3.3 TileOPs：cumsum の長行を 2 段階シードスキャンに変更、(8,65536) が 12.75 から 5.18 マイクロ秒に低下（#2790）（10-28）
      • 3.4 TileOPs：extrema リダクションを PTX の max.NaN に変更、NaN 伝播は不変でリグレッションが解消（#2792）（10-28）
      • 3.5 TileOPs：並列 cumsum の有効行タイル、GDN 狭プリフィルの分割の 2 件（#2788 / #2786）（10-28）
      • 3.6 TileOPs 新規議題：連続呼び出し時に大規模 GEMM の行が最速ベースラインに劣後（#2791）（10-28）
      • 3.7 TileFoundry：ring フェーズバインディングとコンパイルフローを統一、70 ファイル（#277）（10-28）
      • 3.8 TileOPs レビュー中：リリースイメージで TileOPs 0.1.0 と TileFoundry 0.0.3 を同梱（#2793）（10-28）
    1. コミュニティ、チュートリアル、イベント
      • 4.1 ドキュメントサイトの自動更新 2 件（10-28）
      • 4.2 昇騰リポジトリのドキュメントファクトチェックとインストール修正を一括レビュー中、7 件を同一バッチで推進（10-28）
      • 4.3 昇騰リポジトリの新規オペレータサンプルがレビュー中：GroupNorm と fla

_チャンク 2つのオペレータ（#1607 / #1953 / #1952）（10-28）

  • 4.4 サードパーティ：コミュニティの自動チューニングエージェントが中国語説明を更新（#74）、Hexagon バックエンドリポジトリのメインブランチでは調査期間内に新規コミットなし（10-28）
  • 4.5 ニュース側：Google News の中国語・英語6組のクエリ、Hacker News および arXiv のいずれも調査期間内に実質的なヒットなし（10-28）
    1. トレンド観察
  • 付録、素材と検証説明

本日の重点

本日調査期間の重心は昇騰側にある。tilelang-mlir-ascend は Ascend 910（A2/A3）の NPUIR バックエンド全体をメインブランチに統合した。1コミットで55ファイル、21490行の追加となる。Python 側は tilelang/ascend910 パッケージ（backend / adapter / codegen / compiler / execution_backend / jit / pipeline / runtime / target に加え、language 配下の kernel、copy、gemm、npuir 方言面）、C++ 側は src/ascend910/target 配下の開発者向けとエキスパート向けの2系統のエミッタ、op 層と LowerNpuirBlock、NpuLoopVectorize、RewriteFDivToMul の3つのパス、ランタイムには npu_launcher.h と npu_utils を追加し、インストールは install_npuir.sh を使用、target 別名は ascend910 / ascend-910 / a2 / a3 / npuir を受け付ける。作者が提示した受け入れ基準はリポジトリ同梱の2組のテストケースである。pytest testing/npuir の504項目が全通過、examples の72例中71例が通過し、タイムアウト0件・エラー0件。唯一失敗した deepseek_v32/fp8_lighting_indexer.py は旧バックエンドでも同一マシンで同様に失敗しており、環境と許容誤差の問題である。2件目のコミットは旧バックエンドとの挙動差異を項目ごとに整合させるもので、重点は bf16 の適正化（HIVM は bf16 オペランドを受け付けないため、fp32 で計算後に明示的に変換）と動的 extent のコピー沈み込みにある。

TileOPs は本日7件をマージし、2本の主線はいずれも性能側にある。セレクタはもはや manifest に密着したフィッティングを行わず、ビジー時間（device_busy_ms）上で160個の稠密 shape、60個の m 9–32 の shape、264個の m≤8 の shape で再キャリブレーションし、softmin 期待対数後悔による座標降下を用いる。エンドツーエンドのビジー時間後悔はホールドアウト manifest 上で5.79%から0.48%に低下し、m≤8 のホールドアウト集合では14.18%から1.79%に低下した。GEMM 側では coop2_swap を新規追加した。非 NT レイアウトを転置した永続カーネルに置き換え、2つのコンシューマ warpgroup がそれぞれ128行を保持し、テール書き込みは stmatrix.trans と TMA 転置を経て書き戻し、広幅・狭幅 tile の混在配置（例えば 2112 = 13×160 + 32 を160幅 tile と128狭幅 tile に分割）にも対応する。2112×7168×4096 TN は195.3マイクロ秒から175.3マイクロ秒に短縮され、同一マシン上の別の H200 では174.3から158.5マイクロ秒となり、いずれも QuACK の187.9および167.0マイクロ秒を上回った。

リダクション側は同日にまず壊れてから修正された。午前中に #2787 が int32 キーによる extrema リダクションの NaN 伝播を実装し、#2788 が並列 cumsum の行 tile を変更、いずれも07時前後に着地した。その後 #2790 と #2792 がそれぞれ2つのリグレッションを収束させた。cumsum はシードによる分割と2回の発射に変更し（(8,65536) float32 は12.75マイクロ秒から5.18マイクロ秒に短縮、同時にメインブランチの65535 tile 超での発射失敗も修正）、extrema は PTX の max.NaN / min.NaN を使用し、16バイト単位でないベクトルの行では別カーネルを通すようにした（amax (2048,4096) bf16 は8.352マイクロ秒から6.976マイクロ秒に戻り、FlagGems より高速）。この「同日中に導入して修正する」というリズムは、TileOPs の夜間ベンチマークがリグレッションを当日中に食い止めていることを示している。

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

1.1 メインリポジトリ：スカラー読みのインデックス係数が lane 数に混入しなくなり、行幅32768以上のコンパイルクラッシュをクローズ（#3453）

10-28 11:06 にマージ、単一ファイル +8/-5。ベクトル化方式で行全体を読みつつ、同時にインデックスでその行の単一要素を読む kernel が、行幅を 65536 で剰余した結果が 32768 以上になるとコンパイル時に InternalError: Can’t fetch the lanes of a scalable vector を報告する。根本原因は VectorTypeAccessChecker::OnArrayAccess にある。これはスカラー読みを access_dtype.with_lanes(me->coeff) として記録するが、me->coeff はインデックス読みの剰余係数であり、x[row, 0] では行幅に等しい。DataType の lane 数は 16 ビットしかなく int16 として読み戻されるため、32768 から 65535 はスケーラブルベクトルと見なされ、lanes() が get_preferred_dtype 内で直接例外を投げ、さらに広い倍数では静かにラップアラウンドする。修正方法は、係数を別途 int64_t に格納し、互換性判断ではこれを用いて剰余を取り、スカラー読みの dtype には要素型のみを保持する。この欠陥の元のトリガー場景は TileOPs の GroupNorm である。Stable Diffusion の 40960 と 163840 の 2 つのグループ幅がいずれも該当する。検証は 2 回の wheel ビルド比較で行った。主干は 32768 と 40960 の 2 つの幅でコンパイルに失敗し、本コミットはすべてのテスト幅でビルドできる。

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

1.2 メインリポジトリ：バッチ all-reduce がスカラーブランチに従ってスレッド区間を解析し、batch>1 で 2048 個の出力がすべて誤る問題を修正（#3341）

10-28 05:46 にマージ、2 ファイル +170/-8。スカラー all-reduce ブランチは発射呼び出しの前に参加スレッドの区間を解析する（reducing_threads が 32 より大きく、ターゲットが名前付きフェンスをサポートする場合は ResolveAllReduceThreadRange を通る）が、バッチブランチはブロック境界をそのままオフセットとフェンス幅として取る。帰約スレッドが [32, 96) のような 0 から始まらない局所区間である場合、バッチ呼び出しは 0 番スレッドからインデックスし、ブロック全体で等しくフェンスし、非参加スレッドの未初期化レジスタが帰約に折り込まれる。batch=1 は正しく、batch=2 では同一 kernel 上で 2048 個の出力要素がすべて誤り、最大絶対誤差は 1083 で、いかなる診断もない。修正方法は、バッチブランチとスカラーブランチを同じ解析にし、解析されたオフセットと範囲を MakeBatchAllReduce に渡し、ワークスペース stride はブロックサイズを維持する。新規テストは同一 kernel 上で batch=1 と batch=2 を実行し、torch リファレンスと比較する。

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

1.3 メインリポジトリ：SIMT アトミック領域の形状検証を補完し、範囲外領域をコンパイル時に拒否（#3465）

10-28 08:14 にマージ。SIMT アトミック操作はこれまで渡された領域の形状を検証せず、形状の不一致した記述は codegen まで到達して誤った結果やクラッシュを引き起こしていた。本コミットは CUDA と ROCm の 2 つの経路で領域形状検証を補完し、不正な領域をコンパイル時に拒否する。

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

1.4 メインリポジトリ：スパース MMA の K 末尾ブロックが静かに見逃されなくなる（#3367）

10-28 16:01 にマージ。スパース MMA は K 方向に未処理の末尾ブロックがある場合、これまでエラーを出さずにブロック全体の搬送・計算パラメータを流用し、数値が静かにずれていた。本コミットはこのような K 末尾ブロックを明示的に拒否し、問題をコンパイル時に移す。

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

1.5 メインリポジトリ：atomic_addx4 のターゲット dtype を float* に絞る（#3369）

10-28 16:08 にマージ、3 ファイル +27/-9。CUDA の atomic_addx4 と atomic_addx4_ret の汎用実装はこれまで任意のターゲットポインタを受け付け、int32 や int64 ターゲットは float セマンティクスに落ちて誤って計算されていた。本コミットは 2 つの汎用オーバーロードを float* ターゲットに限定し、fp16 と bf16 の既存特化は変更しない。Python 側 API は型中立を維持し、CPU バックエンドの整数ターゲットは影響を受けない。CUDA 側に整数ターゲットのコンパイル失敗回帰ケースを追加し、CPU C バックエンドに 2 種の整数幅の累加正確性ケースを追加する。

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

1.6 メインリポジトリ：非 restrict パラメータの handle サフィックスが切り捨てられなくなる（#3366）

10-28 13:19 にマージ。パラメータの重複排除時に _handle サフィックスを除いた名前で比較していたため、同一カーネル内の A と A_handle という 2 つの異なるパラメータが同じものと見なされ、コード生成が 1 份しか出力しなかった。修正方法は正確な名前と変数アイデンティティによる重複排除に変更し、CUDA 側に A と A_handle が併存する回帰ケースを追加する。

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

1.7 メインリポジトリ：TMA デスクリプタは検証済みの名前のみを記録する（#3484）

10-28 17:12 にマージ。TMA 記述子の登録はこれまで検証の前に行われており、検証に失敗した記述子名がテーブルに残り、後続の同名の正当な記述子が重複と誤判定されていた。本コミットでは登録を検証の後ろに移動した。

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

1.8 メインリポジトリ：profiler 出力インデックスの検証を統一、スカラー形式とリスト形式で同一の境界ルール（#3486）

10-28 19:24 にマージ、2 ファイル +15/-9、#2884 を修正。profiler と adapter の両側でこれまで result_idx の扱いが不一致だった。スカラー形式は境界チェックを行っていたがリスト形式は行っておらず、負のインデックスも正規化されていなかった。本コミットで BaseKernelAdapter と Profiler が同一のルールを共有するようにし、None、整数、整数リストを受け付け、-len(params) から len(params)-1 で判定し、正当な負のインデックスは正規化し、範囲外および非整数要素は ValueError を送出する。CPU 側の回帰テストを 28 項目追加し、スカラー形式とリスト形式の両方の経路をカバーした。

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

1.9 メインリポジトリ：T.Parallel の coalesced_width を一律に IntImm へ変換（#3374）

10-28 16:27 にマージ。coalesced_width に Python の整数を渡すと、一部の経路ではネイティブ整数のまま pass に進入し、後続の変換で型アサーションが失敗していた。本コミットでは言語層で一律に IntImm へ変換し、記述方法の差異による失敗を解消した。

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

1.10 メインリポジトリ：テスト基盤でキャッシュに敏感なケースを without_kernel_cache 経由に変更（#3695 / #3696）

10-28 01:59 と 09:19 にマージ。昨日記録した issue #3694（カーネルキャッシュのヒットがコールドコンパイルを前提とするテストを破壊する）を引き継ぎ、2 つのコミットでコンパイル成果物、ソースコード、診断情報を検査するケースを without_kernel_cache() または明示的な .compile(…) 経由に変更し、アサーションがプロセス内キャッシュにある旧カーネルではなく今回のビルド結果を参照するようにした。

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

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

1.11 新規欠陥 3 件：SM120 で 13 のサンプルが失敗、IfStmtBinding の指数関数的コンパイル、without_kernel_cache が再コンパイルを強制しない（#3701 / #3700 / #3699）

3 件の新規 issue はテストとコンパイル時間を指摘している。第一に、#3701 は RTX PRO 6000 Blackwell（sm_120、動的共有メモリ上限 99 KiB）で完全な examples スイートを実行し、CUDA と CuTeDSL の両バックエンドで 13 失敗 199 通過 27 スキップとなり、失敗セットは完全に同一だった。7 例はサンプルが非 –tune 経路で Hopper サイズの tile をハードコードしていること（例えば attention_sink は 163840 バイト、deepseek_mla デコードは 231424 バイトが必要）、4 例は参照実装の flash-attn 2.5.8 に sm_12x カーネルがないこと、残りの 2 例はそれぞれ ReduceOp の沈み込みと ThreadSync がスレッド範囲を証明できないことである。第二に、#3700 はループ内で x = x + x を繰り返し書き、i < N のガードを加えた場合、tl.LayoutInference が 0.087 秒から 118.5 秒に増加し、replayable bind のインライン化を無効にすると 0.100 秒に戻ることを報告している。第三に、#3699 は without_kernel_cache() が CacheState（ディスクキャッシュの読み取りにのみ使用）を反転させるだけで、@tilelang.jit ラッパーは JITImpl.compile() の前にプロセス内の _call_form_cache と _kernel_cache も参照するため、このブロック内での通常の呼び出しは再コンパイルを保証しないことを指摘している。

出典：https://github.com/tile-ai/tilelang/issues/3701

出典：https://github.com/tile-ai/tilelang/issues/3700

出典：https://github.com/tile-ai/tilelang/issues/3699

2. マルチバックエンド対応（昇騰 / 海光 / ROCm）

2.1 昇騰：910 A2/A3 の NPUIR バックエンドを mlir-ascend 主干に統合、セルフテスト 504 項目すべて通過、72 サンプル中 1 例のみ環境起因の失敗（#207）

10-28 08:04 にマージ、55 ファイル +21490/-1、作者 CeleNewYear、v0.1.15 ベースの a35f8ddf、2 つのコミットがそれぞれバックエンドの実装と動作の整合を担当。バックエンド面には tilelang/ascend910 配下の backend、adapter、codegen、compiler、execution_backend、jit、pipeline、runtime、target、および language 配下の kernel、copy、gemm、npuir 方言面を含む。C++ 側は src/ascend910/target の開発者向けと専門家向けの 2 系統のエミッタ、src/ascend910/op オペレータ層、src/ascend910/transform の LowerNpuirBlock、NpuLoopVectorize、RewriteFDivToMul。ランタイムは npu_launcher.h、npu_utils.cpp、npu_utils.py が torch 互換の起動ラッパーを生成し、*_infer_workspace_shape_function に従って各ブロックの scratch を見積もる。ビルド側は CMakeLists に接続し、install_npuir.sh に –bishengir-path オプションを追加。target 別名は ascend910、ascend-910、a2、a3、npuir を受け付け、モードスイッチ TILELANG_ASCEND_MODE は expert または developer を取り、デフォルトは expert。受け入れデータ：pytest testing/npuir は 504 合格 0 失敗。examples/run_all.py –sequential は 72 例中 71 合格 1 失敗、0 タイムアウト 0 エラー。唯一失敗した deepseek_v32/fp8_lighting_indexer.py は旧バックエンドでも同一マシンで同様に失敗。2 つ目のコミットが整合させた差分には、bf16 の合法化（HIVM が bf16 オペランドを拒否するため、fp32 で計算した後に明示的に変換）と動的 extent 領域のコピー沈下が含まれる。

出典：https://github.com/tile-ai/tilelang-mlir-ascend/pull/207

2.2 昇騰メインリポジトリ：Bisheng のビルド識別情報をバイナリキャッシュキーに追加（#3691）

10-28 10:26 にマージ。昇騰側のバイナリキャッシュはこれまでカーネルと target のみをキーとしており、Bisheng ツールチェーンのバージョンを変えても古いバイナリがヒットしていた。本コミットはビルド識別情報をキャッシュキーに組み込み、ツールチェーンが変われば無効化して再コンパイルする。

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

2.3 昇騰メインリポジトリ：手書きパイプラインで設定レジスタのフェーズを保持（#3624）

10-28 09:57 にマージ。手動パイプラインは書き換え段階で設定レジスタのフェーズ情報を失い、同じ設定が正しい拍で有効にならなかった。本コミットは書き換え中にフェーズを保持し、自動パイプラインと一致するタイミングセマンティクスを回復する。

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

2.4 昇騰リポジトリ審査中：W4A4 int4×int4 GEMM 結果誤りの根本原因と修正方法（#1731）

審査中、7 ファイル +634/-24、#438 を修正。根本原因は、C++ テンプレートスタック全体が sizeof(AscendC::int4b_t) == 1 でフラクタル幾何を推測していたことにある。int4b_t は半バイトパック型であり、32 バイトの C0 ブロックの正しい要素数は 32 ではなく 64 であるため、すべてのコピー stride、repeat 回数、バイト数が 2 倍ずれる。3 層が重なる：L1 から L0A/L0B への LoadData パラメータはこの定数から導出され、データが誤った位置に積まれる。B オペランドの zN から nZ への転置は s4 専用命令 load_cbuf_to_cb_s4 で黙って無効化され、LoadDataWithTranspose から load_cbuf_to_cb_transpose_s4 に切り替える必要があるが、そのパラメータセマンティクスは CANN ヘッダにドキュメントがなく、作者はプローブカーネルを使ってデバイス上でリバースエンジニアリングするしかなかった（正しいパラメータは repeatTimes = N/64、srcStride = roundUp16(K)/64、dstGap = 3、かつ s4 版はドキュメントの 512 バイト fractal ではなく 2048 バイトブロックで動作する）。UB から GM へのバイト長は 1 要素 1 バイトで計算され、各行が 2 倍搬送されて隣接行が混入する。mad_s4 命令自体は正しく、症状は 99.6% の不一致、出力 -501/627 で正解は 641/1785。

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

2.5 昇騰リポジトリ審査中：a2a3 スケジューラ移行、100 ファイル 18453 行（#1951）

審査中、100 ファイル +18453/-666、作者 erhsh。A2/A3 のスケジューラを新アーキテクチャに移行するもので、調査期間内で最大の審査中変更。PR 説明の表は未記入で、具体的な境界はファイル一覧に基づいて確認する必要がある。

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

2.6 昇腾リポジトリ審査中：Carver が選択 SDK に応じて A3 リソース予算を読み取り（#1955）

審査中、3 ファイル +203/-27。Ascend910_9392 上で Carver が Ascend910A にフォールバックし、256×256 の FP32 アキュムレータを 256 KiB の L0C 予算に配置するが、選択された SDK は 128 KiB しか提供しない。修正方法は 9392 と 9382 の 2 つの具体的な SKU を識別し、既存の ASCEND_HOME を用いて各プラットフォームの INI を読み取り（クロスコンパイル用に明示的なファイルオプションも別途用意）、SDK 容量を現在のバックエンド arena にトリミングしつつ、元の容量、設定識別子、BF16 サポート、コア数、L2 属性を保持する。6 つの的を絞ったテストケースがデバイス、target、明示的なチップ検出、超過および合法な L0 tile、さらに 9382 で BF16 を無効化した独立構成をカバーする。著者による回帰結果は、ネイティブ昇腾 CI メインスイート 1352 パス・3 スキップ、サンプルスイート 153 パス。

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

2.7 昇腾リポジトリ審査中：AI Core Exception Dump の依存を CANN 9.2.0 に引き下げ（#1956）

審査中、5 ファイル +49/-32。この機能は以前 CANN 9.3.0 への依存を宣言していたが、著者は 9.2.0 上で動作を検証し、2 箇所の互換性を修正した。acldumpTensorInfo に addrType=ACL_DUMP_ADDR_RAW、placement、shapeNum、originShapeNum の 4 つの必須フィールドを補完し（9.2.0 の acldumpSaveExceptionInfo は addrType を厳格に検証し、元の実装では calloc により ACL_DUMP_ADDR_PTR にゼロ初期化されて拒否されていた）、NULL アドレスまたはサイズ 0 の tensor をスキップする。登録インターフェースは非推奨の aclrtSetExceptionInfoCallback から aclrtExceptionInfoCallbackRegister に変更。解析側は msaicerr.py の 2 種類の生成物（9.2.0 は .npy、旧版は .bin）に対応し、ドキュメントのバージョン要件も CANN 9.2.0 以上に同期して変更された。

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

2.8 昇腾リポジトリ審査中：ドキュメントを T.Tensor に変更し、T.Buffer DSL インターフェースを非推奨化（#1957）

審査中、単一ファイル +124/-122。プログラミングガイド 3.1 節の kernel パラメータ定義を上流 API に合わせ、テキストとサンプルを統一して T.Tensor を使用し、T.Buffer(…) と T.Buffer[…] の非推奨は TileLang DSL インターフェースのみを対象とし、基盤となる TVM の Buffer 型と概念は非推奨ではない旨の一文を追加。根拠は ascendc_pto ブランチの tilelang/language/proxy.py にある @deprecated デコレータ。

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

2.9 海光：HCU 通常コピーの LDS swizzle 機能ブランチ、18 ファイルに 5 つの新規テストを含む（#30）

審査中、18 ファイル +2000/-84、ブランチ Feat/hcu plain copy lds swizzle は 10-28 13:59 にプッシュ。変更は新規追加の gemm_lds_strategy_utils（+148/-0 と +29/-0）、annotate_mls_gemm_dep.cc（+332/-45）、ds_read_format.cc（+61/-22）に集中し、copy と merge_shared_memory_allocations に付随する小規模な変更がある。テスト側では test_hcu_plain_copy_lds_swizzle（396 行）、_formula（237）、_formula_b8（220）、fp8（200）、_b8_write_phases（80）を一度に追加。方向性は通常コピーパスの LDS 書き込みフェーズと swizzle 戦略であり、b8/fp8 の 2 種類のデータ幅に対応する。

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

2.10 ROCm：pip 版 SDK の ROCm 10 サポートがマージされ、MI355X が gfx900 と誤判定されなくなる（#3549）

10-28 07:38 にマージ、2 ファイル +106/-19。ROCm 10.x の rocm/pytorch イメージは ROCm を Python wheel 形式（rocm-sdk と _rocm_sdk_devel）でリリースしており、/opt/rocm ディレクトリツリーも rocm-* の apt パッケージも存在しない。get_rocm_arch() は以前 /opt/rocm プレフィックスをハードコードしており、パスが存在しない場合は gfx900 にフォールバックしていたため、MI355X（gfx950）上で rocwmma の静的アサーションが直接失敗していた。ROCM_PATH を設定しても無効であった。TVM の tvm_callback_rocm_get_arch がデフォルトプレフィックスでこの関数を呼び出すためである。修正方法は、呼び出し元のプレフィックス、find_rocm_path()、torch の gcnArchName、gfx900 フォールバックの順に解決し、各 rocminfo プローブに 10 秒のタイムアウトを追加する。さらに docker/Dockerfile.rocm10 を新規追加し、rocm/pytorch:rocm10.1.0_ubuntu24.04_py3.12 をベースに、rocm-* の apt インストールを削除し、ROCM_PATH を rocm-sdk path –root にポイントし、ベースイメージの torch ビルドを保持して import の自己チェックを追加した。著者は MI355X 上でアーキテクチャ検出が gfx900 から gfx950 に変わることを実測し、testing/python/amd スイートは正しいアーキテクチャでビルドされパスした。

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

3. エコシステムと採用側（TileOPs / TileFoundry）

3.1 TileOPs：セレクタをビジー時間基準のキャリブレーションに変更、manifest のリグレットが 5.79% から 0.48% に低下（#2784）

10-28 10:51 にマージ、4 ファイル +259/-203。稠密セレクタのスコアリングを tensor_core_tflops に構造因子を乗じたものに変更した。以前は構造の差異が単一の max() にしか反映されず、メモリ制約のある shape では basic、simple、coop2 が同点になっていた。launch_us 項は削除（ビジー時間上でフィットすると 0 になる）。m≤8 の NT バンドは手動測定のしきい値をストリーミングモデルに置き換えた。各 CTA のレートは min(ns·rows·bk·2/latency, cta_gbps) を取り、ウェーブは SMEM 制約の常駐数で計算し、さらに DRAM 下限 n·k·2/dram_tbps と split-K のリダクション項を加える。TN/TT の永続カーネルパスを開通（A/B の SMEM tile はストレージレイアウトに従い、transpose_A/B）、176/192 幅、ナロータイル、ping-pong、split-K は引き続き NT に限定。キャリブレーションはビジー時間上で行い、3 組のグリッド 160/60/264 個の shape、7 ラウンドのインターリーブ CUPTI で中央値を取得し、softmin 期待対数リグレットを座標降下で、tau 0.1→0.05→0.02 とアニーリングした。エンドツーエンドの結果：ホールドアウト manifest は 5.79% から 0.48%、キャリブレーショングリッドは 9.28% から 2.65%、m 9–32 は 3.13% から 2.09%、m≤8 は 11.20% から 1.17%、m≤8 ホールドアウトセットは 14.18% から 1.79%。

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

3.2 TileOPs：非 NT レイアウトを転置永続カーネルに変更、2112×7168×4096 TN が 195.3 から 175.3 マイクロ秒に（#2789）

10-28 21:06 にマージ、4 ファイル +620/-15、#2785 を解決。coop2_swap を新規追加：TN/TT/NN に対して Cᵀ = op(B)ᵀ·op(A)ᵀ を計算し、256×block_n の tile で永続カーネルを実行、2 つのコンシューマ warpgroup がそれぞれ 128 行を保持し、テール書き込みは stmatrix.trans と TMA 転置で書き戻す。混在タイル幅（narrow_n と row_mix）により M がパディングで無駄にならないようにする。例えば 2112 = 13×160 + 32 を幅 160 とナロー 128 に分割し、広いものを先に実行し、狭いもので締める。分割点は coop2 ナロータイルの _busiest_cta 指標を踏襲する。セレクタは NT 以外に coop2_swap の block_n 128 と 160、構造因子 1.2 を列挙し、ビジー時間で再フィットする。H200 ビジー時間：2112×7168×4096 TN は 195.3 から 175.3 マイクロ秒（QuACK 187.9）、24576×1536×4096 TN は 421.9 から 416.4 マイクロ秒。別の H200 ではそれぞれ 174.3 から 158.5（QuACK 167.0）と 384–402 マイクロ秒の範囲。行グループ規則を固定 4 から 16 に変更し、24 個の TN/TT/NN キャリブレーション shape で group 4 との差は 0.989–1.022 倍であった。さらに 9 個の TN shape で混在タイルは均一な coop2_swap より 3.6% から 11% 高速であった。

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

3.3 TileOPs：cumsum の長行を2段式シードスキャンに変更、(8,65536) が 12.75 から 5.18 マイクロ秒へ（#2790）

10-28 20:45 にマージ、4ファイル +255/-246。少数の長行の cumsum をシード分段スキャンに切り替え、発行回数を3回から2回に削減。これにより #2788 がもたらしたリグレッションを解消するとともに、そのレイアウト失敗も修正した。ルールは、行が 64 KiB 以上かつ行数が多くない場合は分段スキャンを行い、cumprod は変更しない。また、メインライン上で行数が 65535 タイルを超える場合（例 (1, 2**24) float32）の発行失敗も修正した。H200 @1500 MHz ビジー時：(8,65536) float32 12.75 から 5.18 マイクロ秒、(16,65536) 19.14 から 7.01 マイクロ秒、(1,65536) bf16 9.03 から 3.45 マイクロ秒、(3,8193) fp16 7.52 から 3.29 マイクロ秒。384 シェイプのスキャンで #2788 以前より遅くなった項目はなく、CumsumFwdOp と CumprodFwdOp の manifest 行はいずれも最速の対照実装より高速。新規の few-long-seq 負荷（8×65536 float32）は 5.20 マイクロ秒で FlagGems の 6.30 マイクロ秒に対抗。

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

3.4 TileOPs：extrema リダクションを PTX の max.NaN に変更、NaN 伝播は不変でリグレッション消失（#2792）

10-28 23:31 にマージ、4ファイル +346/-119。amax/amin を fp32 上で PTX の max.NaN と min.NaN を使うよう変更し、#2787 の int32 キー方式を廃止。NaN 伝播のセマンティクスは不変のまま、同日朝のリグレッションを解消した。16 バイトベクトル単位でない行は別の extrema 行カーネルを通す。T.reduce_max は fp32 で NaN を落とすためである。H200 @1500 MHz：amax (2048,4096) bf16 は #2787 以前が 7.008 マイクロ秒、メインライン 8.352、本コミット 6.976；fp16 は 7.008 から 7.775 から 6.944；amax (64,32768) bf16 は 3.552 から 4.544 から 3.520；amin 同形は 3.552 から 4.224 から 3.520。

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

3.5 TileOPs：並列 cumsum の有効行タイル、GDN 狭プリフィル分割の2件（#2788 / #2786）

#2788 は 10-28 07:13 にマージされ、並列 cumsum が有効な行タイルのみを処理するようにした。調査期間内で最も早いコミットであり、その後 #2790 により問題経路が2段式スキャンに置き換えられた。#2786 は 07:09 にマージ、2ファイル +30/-2。SM89 上で 32 列の GDN プリフィル計画を既存の融合出力付き状態スキャンに切り替え、全体ブロック分割と末尾ブロックを分けて処理し、準備段階・出力・最終状態の3インターフェースを保持する。採用条件は、稠密入力、batch 1、16 個の value head、状態幅 128、key major、シーケンス長が 16384 超かつ 65536 以下。H=4 のとき中央値デバイス実行時間は TileOPs ベースライン比で 13.65% から 18.31% 低下、デバイス活動スパンは 13.48% から 17.07% 低下。FLA と交互比較した4ラウンドのうち H=16、長さ 65536、BF16 のスパン差は -2.57% から +1.77% の間にあり、著者自身はこの行が測定変動の範囲内と述べている。

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

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

3.6 TileOPs 新規イシュー：バックツーバック呼び出しで大 GEMM 行が最速ベースラインに劣後（#2791）

新規起票。#2133 と #2789 を引き継ぐ。bench_gemm は1回につき1呼び出しを読み、間に L2 フラッシュと同期があり、呼び出しが電力上限以下から始まるためエネルギーコストが隠蔽される。トレーニングにおけるバックツーバックの連続呼び出しに変更すると、10 個の manifest 大行のうち6件が最速ベースラインに劣後する。典型例：prefill-o-proj 4096×7168×16384 NT は本実装 1412.7 マイクロ秒、QuACK 1371.1、cuBLAS 1360.1、DeepGEMM 1359.2、比 0.962。方法はシングルカード H200、クロック解除、1秒ウォームアップ後 1.5 秒計測、4ラウンド交互の中央値。

出典：https://github.com/tile-ai/TileOPs/issues/2791

3.7 TileFoundry：ring ステージバインディングとコンパイルフローの統一、70ファイル（#277）

10-28 16:55 に統合、70 ファイル +1567/-1298、#276 を置換。動機は二点：未バインドの ring ビューと段階選択が SSA 名を持たないビューを伴って CUDA オペランドに到達してしまうこと；三つのコンパイル入口がそれぞれ異なる pass リストを組み立てていること。修正方法は、ring 段階をバインド済みの TensorView の集合として保存し、各消費スコープで一度だけバインドし、default_pipeline を finalize、compile、scaffold の三箇所で共用させ、核心ホスト入口 pass を Target.resolve で解決し、CUDA が @bind 実装を提供する形にした；Module.entry がホスト起点となり、解析された共有メモリピークがホスト起動に持ち込まれる；呼び出しチェーン上のすべての CPU ホストがリンクに参加し、ルートホストが先頭に置かれる。契約の変更：link_program から entries を削除、ローダーは最初にリンクされたホストをバインドし、build は CPU ホストルートの存在を要求する。残存リスクは PR に記載：#278 が Broadcast レイアウト正規化を追跡、#255 が SymbolRef と関数参照を追跡。

出典：https://github.com/tile-ai/TileFoundry/pull/277

3.8 TileOPs 審査中：リリースイメージで TileOPs 0.1.0 と TileFoundry 0.0.3 を同梱（#2793）

審査中、9 ファイル +120/-44。.github/runner/Dockerfile に release ターゲットを新設し、開発イメージの上に tileops と tilefoundry の PyPI リリース版をインストール、イメージ名は TILEOPS_VERSION と TILEFOUNDRY_VERSION で命名し、ghcr.io/tile-ai/tileops-release:tileops0.1.0-tilefoundry0.0.3-cuda13.2-torch2.13-tilelang0.1.12 としてプッシュされる；付随する scripts/verify_release_image.sh がイメージをプルした後 GPU 上でスタックとベースライン検査、パッケージングテストと指定の –bench ファイルを実行し、テストケースはイメージ内の tileops バージョンに対応する git tag から取得する（wheel にはテストとベンチマークが含まれない）。同時に sgl-kernel ベースラインを削除：どのイメージももはやこれをインストールせず、bench_moe_permute_align はこれをずっとスキップしていた。

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

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

4.1 ドキュメントサイトに自動更新二件（10-28）

tilelang.github.io では 10-28 08:20 と 13:31 にそれぞれ github-actions による Update docs のコミットがあり、内容はドキュメントビルド成果物の主干への同期で、独立した内容変更はない。

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

4.2 昇騰リポジトリのドキュメントファクトチェックとインストール修正が一括審査中、七件を同批で推進（10-28）

tilelang-ascend のドキュメントファクトチェックパイプラインは調査期間内に七件を更新：T.tile.bitwise_lshift、bitwise_or、bitwise_and、fill、clear の五つの API のチェック、clamp が PTO 上で有効になることとドキュメントの照合（#1620）、さらに axpy の docstring とテスト強化（#1600）。ほかに #1943 が SHMEM インストールをビルド失敗時に停止するよう変更し、#1942 のスナップショットアナライザ検証と同じくボットによるコミットである。

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

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

4.3 昇騰リポジトリに新規オペレータサンプルが審査中：GroupNorm と fla_chunk の二オペレータ（#1607 / #1953 / #1952）

三件のサンプル系 PR が調査期間内に更新：#1607 は GroupNorm に 20 個の cann-bench ケースを追加、#1953 は fla_chunk_o オペレータとテストを追加、#1952 は fla_chunk_intra_token_parallel オペレータとテストを追加。これが 1.1 のスカラー読み込みクラッシュ欠陥の元のシナリオの出所でもある（GroupNorm が各行の先頭要素を読む）。

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

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

4.4 サードパーティ：コミュニティ自動チューニングエージェントが中国語説明を更新（#74）、Hexagon バックエンドリポジトリの主ブランチは調査期間内に新規コミットなし（10-28）

コミュニティリポジトリ cc-c122/TileLang-Remote-Autotuning-Agent は 10-28 09:21 に #74 をマージし、現在の V2 ワークフローに従って中国語 README を更新した。このリポジトリでは此前 10-24 にもベースラインキャンセル状態と mcprofiler 帰属に関するマージが一度行われている。もう一つのサードパーティバックエンドリポジトリ xwhzz/tilelang-hexagon の組織ビューでは 10-29 06:56 にプッシュのタイムスタンプが表示されているが、メインブランチの最新コミットは 08-24（CI 依存関係のアップグレード）で止まっており、調査期間内にメインブランチへのコードコミットはなく、昨日の 15 件はフィーチャーブランチの活動に属するため、本条は新規内容として計上しない。

出典：https://github.com/cc-c122/TileLang-Remote-Autotuning-Agent/pull/74

出典：https://github.com/xwhzz/tilelang-hexagon

4.5 ニュース側：Google News の6組の中英語クエリ、Hacker News と arXiv はいずれも調査期間内に実質的なヒットなし（10-28）

6組のクエリは、TileLang の完全一致語＋2日、中国語オペレータ語＋7日、英語 GPU kernel DSL＋3日、組織名＋7日、中国語ベンダー語（昇騰 / 沐曦 / 海光）＋7日、オペレータライブラリ語＋2日を含む。返却結果のうち TileLang に関連し調査期間内に該当するのは転載記事1本のみ（昇騰 950PR マトリクス演算力比較。二次的な市場評論に属し、一次データがないため収録しない）で、残りは DeepSeek の資金調達や技術に関する一般的な報道であり、タイトルの意味に TileLang 関連の内容は含まれていない。英語クエリはすべて空の返却であった。Hacker News の当日の項目は Vu という新言語のリリースで、TileLang とは無関係である。arXiv には調査期間内に新規追加された tilelang または tiled DSL の論文はない。ニュース側と GitHub 側のシグナル強度の差は本日も拡大を続けており、デイリーレポートの主体は引き続きリポジトリに基づく。

出典：https://news.google.com/

5. トレンド観察

昇騰側の進め方はこの二日間で既に明らかである。メインリポジトリは時間単位で小規模な修正（キャッシュキー、レジスタフェーズ）をマージし、専用リポジトリ mlir-ascend は一度の2万行のマージで 910 の NPUIR パスをフィーチャーブランチから主干線に移し、tilelang-ascend は PTO と AscendC のデュアルバックエンドという既定のリズムでドキュメントとオペレータの補完を行っている。三箇所のリズムは異なるが、指し示すものは同じである。910 のコンパイラパスは「動く」から「受け入れ可能」へと転換しつつあり、504 項の自己テストと 71/72 のサンプルが今回示された受け入れ基準である。注目すべきは審査待ちキューにおいて a2a3 のスケジューラ移行が 100 ファイルを占めていることで、次の段階の変動量がオペレータ層ではなくスケジューリング層にあることを示している。

性能側の看点は測定基準そのものにある。TileOPs のこの2件はセレクタと GEMM の結論をいずれもビジー時（device_busy_ms）に移し、同一の PR 内で単一呼び出しとバックツーバック呼び出しの差異を示した。単一読み取り方式では本実装が QuACK をリードするが、バックツーバックかつ電力上限付きのトレーニングシナリオでは10の大行のうち6行が後れを取る。これは「ある行が何マイクロ秒速くなったか」よりも重要なシグナルである。なぜならトレーニングの実際はバックツーバックだからである。#2791 はこのことを独立した項目とし、チームが基準の問題を製品の問題として扱い、ベンチマークの偏りとして粉飾していないことを示している。

エンジニアリング衛生面で本日記録すべきは3点ある。第一に、同一バッチ内の自傷と自修（#2787/#2788 は午前にマージ、#2790/#2792 は午後に撤回）で、夜間ベンチマークのフォールバックが機能していることを示すが、同時に帰約这套代码の意味的境界が依然として脆いことも示している。第二に、without_kernel_cache() の意味的欠陥（#3699）が移行過程から摘出されたことである。プロセス内の2層キャッシュが CacheState を消費せず、テストは冷間コンパイルだと思い込んで実際には古い kernel を取得している。この種の欠陥は「我々のテストはすべて通った」を無意味にする。第三に、SM120 上で13のサンプルが失敗したこと（#3701）が、サンプルが Hopper のサイズをハードコードしている問題を露呈したことである。Blackwell の搭載量が上がると、この種の「サンプルは製品ではない」という負債は繰り返し計上されるだろう。

付、素材と検証説明

情報源検証表

情報源 検証結果
GitHub tile-ai 組織リポジトリ別（tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / ドキュメントサイト） 調査期間内にプッシュあり：tilelang、TileOPs、TileFoundry、tilelang-mlir-ascend、tilelang-hygon、tilelang.github.io；tilelang-metax、tilelang-musa、TileRT、tilescale、DeepStack、tilelang-puzzles は調査期間内にメインブランチへのコミットなし
マージ済み真値検索（is:pr is:merged） 24 件：tilelang 15、TileOPs 7、TileFoundry 1、tilelang-mlir-ascend 1
審査中真値検索（is:pr is:open updated） 48 件、昇騰リポジトリのドキュメント検証バッチと a2a3 移行を含む
新規 issue 照合 6 件、うち 1 件は昇騰リポジトリのデイリーテストボット
メインブランチコミットレベル検証 tilelang 15 件、TileOPs 7 件、TileFoundry 1 件、ドキュメントサイト 2 件；マージ数とメインブランチコミット数は一致
リリースページと tag tilelang の最新は依然 v0.1.15（09-30 リリース）、調査期間内に新バージョンなし；TileOPs の最新は v0.1.0
サードパーティバックエンドリポジトリ Hexagon バックエンドのメインブランチ最新コミットは 08-24 で停止、調査期間内に新規コミットなし；自動チューニングエージェントのマージ済み中国語説明を更新；沐曦リポジトリの6ブランチは調査期間内にコミットなし
Google News（中英6組） 中古転載記事1件のみ関連、原データなし、収録せず
Hacker News 当日 TileLang 関連エントリなし
arXiv 調査期間内に tilelang または tiled DSL 論文の新規追加なし

完全情報源リスト