調査期間：2026-11-05 07:00 ~ 2026-11-06 07:00（北京時間、24時間；前回の締め切りは11-05 07:00）。

情報源：GitHub tile-ai組織のリポジトリ別調査（29リポジトリ、期間内プッシュ10件）＋マージ済み・審査中真値検索（期間内マージ18件、審査中更新57件）＋新規issue 5件＋メインブランチのコミット別調査（tilelang 5、TileOPs 9、TileFoundry 1、tilelang-ascend 2、tilelang-musa 1）＋非デフォルトブランチ調査（tilelang-hygonのfeat/hcu-scaled-castブランチ3件）＋リリースページ調査（tilelang / TileOPs / TileFoundryの3リポジトリ、期間内に新バージョンなし）＋採用側2リポジトリ＋ドキュメントサイトとナイトリービルドリポジトリ調査＋Google News中英文4組クエリ（プロキシ経由）＋Hacker News＋arXiv。RISC-V 4ソース特別巡回は本期間変化なし。

本期インデックス

  • 今日の重点：TileOPsが1日9件のマージで、「ブロードキャストのインプレース読み取り、単一波起動、タイル選択」の3つを同時に推進；メインリポジトリの5件マージに加え、0.1.12以来存在するサイレントエラーCUDA不具合が報告された；昇騰はセグメンテーション違反を修正した一方、threads=2でsin/cosが97.1%の要素で誤計算となることを指摘された
    1. コアプロジェクト進捗
      • 1.1 メインライン：TF32変換がround-to-nearest-evenをサポート、SM90とSM100を分けて診断（#3714）（11-05）
      • 1.2 メインライン：host-mappedバッファを明示的にアノテーション可能に、CPUテンソルがデバイスチェックで拒否されなくなる（#3802）（11-05）
      • 1.3 メインライン：スカラー条件内のcastがデータベクトル幅を制限しなくなる（#3759）（11-05）
      • 1.4 メインライン：Z3のrlimitをkernelごとに設定可能に、デフォルトは引き続き10万（#3752、tile-ai/tvm #91に依存）（11-05）
      • 1.5 メインライン：ネストしたT.macroが変換テンプレートを再利用、フロントエンドの重複コンパイルオーバーヘッドを収束（#3760）（11-05）
      • 1.6 新規issue：条件スカラー化後に__syncthreadsが欠落、0.1.12から0.1.15までサイレントに誤ったCUDAを生成（#3808）（11-05）
      • 1.7 新規issue：warp specializationなしの場合、T.Pipelinedがtcgen05待機前にstageを再ロード（#3800）（11-05）
      • 1.8 審査中：ネイティブApache TIRxへの完全移行草案（#3803）；共有転置をldmatrix/stmatrix経由に変更（#3809）（11-05）
    1. マルチバックエンド対応
      • 2.1 昇騰：bitwise_rshiftの64ビットdtypeを明示的エラーに変更、セグメンテーション違反を解消（#1954）（11-05）
      • 2.2 昇騰：A2/A3性能スキルをAscend950ワークフローに整合（#1932）（11-05）
      • 2.3 昇騰：threads=2でtmp workspaceが無条件に半減、sin/cosが間接アドレッシングtile上で97.1%の要素を誤計算（#1991 / #1992）（11-05）
      • 2.4 海光：ブランチでLDS位相修正3件、初めて2つのPRを提出（#33 / #34）（11-05）
      • 2.5 摩尔線程：READMEドキュメント更新、09-30以来のサイレント状態を終了（11-05）
      • 2.6 沐曦とmlir-ascend：沐曦は3期連続プッシュなし；mlir-ascendは3件のTLIRオペレータを審査中（11-05）
    1. エコシステムと採用側
      • 3.1 TileOPs：9件マージ、ブロードキャストオペランドのインプレース読み取り、GEMM単一波充填、reductionレイアウトキャッシュ（11-05）
      • 3.2 TileOPs：roofline課金ルールを書き換え、不可能だった3つの帯域幅行が妥当な範囲に復帰（#2830）（11-05）
      • 3.3 TileOPs：2件のマージが2.5分差でmainのGPU Smokeが失敗、当日修正（#2837）（11-05）
      • 3.4 TileOPs審査中：3段階タイルファクタ、TN単一要素縮小、FP8グループGEMMのTMAスケーリングロード（#2836 / #2838 / #2839）（11-05）
      • 3.5 TileFoundry：WGMMA同期計画をマージ（#286）、部分リダクションの完了セマンティクスを審査中（#288）（11-05）
      • 3.6 TileSight：H20のWGMMA機能宣言を修正、リポジトリ初のPR（#1）（11-05）
      • 3.7 採用側とサードパーティ：TileKernels、FlashQLAはプッシュなし；新たなサードパーティリポジトリ2つが出現（11-05）
    1. コミュニティ、チュートリアルとイベント
      • 4.1 ドキュメントサイト3回更新；ナイトリービルドリポジトリにメインブランチコミットなし；昇騰デイリーテスト3030項目全通過（11-05）
      • 4.2 ニュース側：4組クエリ、Hacker News、arXivいずれも期間内ヒットなし（11-05）
    1. トレンド観察
  • 付、素材と調査説明

今日の重点

この日最も集中的な成果はコンパイラではなくオペレータライブラリから生まれた。TileOPs は 21:06 から 22:46 までの1時間余りで6件を連続マージし、さらに 14:01 と 21:31 の2件を加えて、1日で9件、すべて perf、fix、ci タグであった。三つの事柄が同時に進んだ：一つ目はブロードキャストオペランドのオンザフライ読み込みで、lerp、where、clamp、masked_fill の5種類のオペレータは stride 0 のブロードキャストテンソルをまず出力形状に展開しなくなり、実測でブロードキャスト行の所要時間がメインラインの 0.13 から 0.44 倍に低下した（#2832）；二つ目は単一ウェーブ起動で、一元要素ごと演算が「本体内部で最大2つの安価な命令、読み書き総量が L2 の4分の3以下」の場合に 256 スレッドの1ウェーブに縮小され、ついでに ReLU が NaN に対して 0 を返す従来の問題も修正された（#2829）；三つ目はタイルセレクタで、小さい M 向けの NT GEMM に幅が1ウェーブを埋め尽くせるネイティブ幅タイルを作り、decode-down が後れから最速比較対象を 3% リードする形に変わった（#2834）。三つの共通点は「より速い」ことではなく、各件が再現可能な A/B 表を伴い、依然として後れを取っている行を自ら明示していることである。

第二条は信頼性の問題であり、しかも二つのリポジトリにまたがる。メインリポジトリで新たに issue #3808 が報告された：0.1.12 から 0.1.15 にかけて、条件関連のスカラー化の後、共有メモリ epilogue で __syncthreads() が一つ欠落し、コンパイラはエラーを出さず、生成される CUDA が誤っている；報告者は完全な再現スクリプトと4つのバージョン番号を提示しており、「サイレントな誤コード」であって性能劣化ではない。同一期間に #3800 が報告しているのは別種のサイレントエラーである：warp specialization を有効にしない場合、T.Pipelined が T.tcgen05_gemm の barrier 待機の前に次の stage を再ロードするため、MMA が読む operand がすでに上書きされている。これら2件とメインリポジトリ当日マージの #3759 はちょうど対照をなす——#3759 が修正するのは「スカラー条件内の int64 cast がデータベクトル幅を 16 lane から 4 lane に押し下げる」問題であり、同じスカラー化/ベクトル化の境界で、一方は幅を修正し、一方は同期を漏らしている。

第三条は昇騰側である。tilelang-ascend は #1954 をマージし、T.tile.bitwise_rshift の int64/uint64 におけるコンパイル時セグメンテーション違反を明示的な ValueError に改め、int16/uint16/int32/uint32 のみを許可した；これは 64 ビット右シフトサポートの新規追加ではなく、「コンパイラがクラッシュする」を「コンパイラが拒否する」に変えたものである。同一リポジトリで当日同題の issue が2件新規作成された（#1991、#1992）。報告によれば 910_9362 / CANN 9.0.0、threads=2（C:V=1:2）において、AscendVidReduction が kernel 内のすべての UB 割り当てを無条件に半減し、注入された tmp workspace すら半減するため、sin/cos が間接アドレッシングの skip-set buffer に作用する際に 3978/4096（97.1%）の要素が誤って計算され、sigmoid/round では AscendC の calCount <= tmp 契約に違反し、範囲外書き込みがレイアウト後方の scratch に落ちる。これと並置されるのが同日 #1988 のデイリーテストレポートである：3030 項目全通過、通過率 100%。この二組の数字を並べると一つのことが分かる——既存のテストは「threads=2 と間接アドレッシング」の組み合わせをカバーできておらず、通過率を正しさの代替指標にはできない。

第四条はエコシステム面の動きである。海光リポジトリは「機能ブランチに4件蓄積、PR 未作成」から正式にレビュー入りへと変わり、feat/hcu-scaled-cast ブランチは当日さらに3件の LDS 位相修正（デフォルト swizzle の 64 bank 対応、MN スライス消費側での swizzle 計画復元、K パーティションのレイアウト認識読み込み）を落とし、#33（scaled cast）と #34（reduction の lane swap と制約伝播）の2つの PR を開いた。摩尔線程は 09-30 以来の完全な沈黙を終え、メインブランチに README のインストールとオペレータ開発説明の更新を1件落とした。さらに TileSight リポジトリに最初の PR（H20 の WGMMA 能力宣言の修正）が現れ、メインリポジトリ #3803 の TIRx 移行草案と合わせて、組織レベルで三つの線が同時に展開していることが見て取れる：国産バックエンドが独自ブランチから公共レビューへ、性能モデリングが論文からリポジトリへ、コンパイラ基盤が vendored TVM の置き換えを準備している。

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

1.1 メインライン：TF32 変換が round-to-nearest-even をサポート、SM90 と SM100 を分けて診断（#3714）

12:09 にマージ。これまで T.cast から tfloat32 へはデフォルトの TF32 最近接丸め経路しかなく、ties-to-even が必要なら自分で CUDA helper をインポートする必要があった。このコミットは round="rn" にネイティブ lowering を追加した。非飽和形式は cvt.rn.tf32.f32、飽和形式は cvt.rn.satfinite.tf32.f32 を発行し、デフォルトの TF32 丸めコンストラクタを回避して変換後のビットパターンを直接保持する。スカラーとベクトルの両経路をカバーし、TF32 の lane アクセスはパック済みキャリアを通る。アーキテクチャ診断は形式ごとに分かれる。非飽和形式は SM90 以上、飽和形式は SM100 以上を要求し、満たさなければコンパイル時にエラーを出す。rounding を明示指定しない cast の動作は変わらない。報告者は #3713 をクローズした要求元であり、「ユーザーがもはや helper を自前で持つ必要がない」という類のインターフェース収束に属する。

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

1.2 メインライン：host-mapped バッファを明示的に注釈可能に、CPU テンソルがデバイスチェックで拒否されなくなる（#3802）

当日作成、当日マージ（12:08 コミット、16:02 マージ）。CUDA kernel は GPU アドレス空間にマップされた host メモリへ直接アクセスできるが、TileLang の既存のデバイスチェックはテンソル引数がすべてターゲットデバイス上にあると仮定していたため、こうした CPU テンソルは起動前に拒否されていた。新設の T.annotate_host_mapped_buffers(*buffers) は注釈された引数のインデックスを PrimFunc の tl.host_mapped_params 属性に書き込み、複数バッファに対応し、重複宣言をマージし、IR シリアライズと kernel キャッシュ復元を通過できる。Cython と TVM-FFI の 2 つの launcher は注釈された引数に対して CPU テンソルを受け入れ、その他の dtype、形状、ランク、ストライドのチェックは従来通り。デバイス側引数のチェックは現在の実行デバイスに引き続き整合し、host テンソルには CUDA デバイス番号を提供しない。ランタイムにはネイティブ helper が追加され、cuMemHostGetFlags で登録状態を検証し、cuMemHostGetDevicePointer でデバイスから見えるアドレスを解決する。通常のページャブルメモリは引き続き拒否される。

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

1.3 メインライン：スカラー条件内の cast がデータベクトル幅を制限しなくなる（#3759）

19:27 にマージ、ラベルに ascend を含む。発端は #3734 が DecoupleTypeCast の後でデータ cast の幅制限を正しく厳格化したが、条件内の cast もそれに含めてしまったことにある。T.assume(n % 16 == 0) で保護された BF16 コピーが、条件内に T.Cast("int64", ...) があるために b5cb02633 上で 16 lane から 4 lane に押し下げられた。条件が 16 lane 上で一致していてもである。修正は planner 既存の条件一貫性解析を再利用し、cast 幅の免除をバッファインデックスから条件へ拡張する。if 文、tirx.if_then_else、スカラ述語の Select の条件は個別にアクセスし、分岐は引き続き制限される。lane レベルのベクトル述語のターゲットでは条件 cast の制約が引き続き保持される。stochastic rounding の rbits グループ化も幅制約をスキップする際に保持される。このコミットと期間内の 2 つの新規 issue は同じ領域にあり、スカラー化とベクトル化の境界が現在の欠陥の高発地带であることを示している。

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

1.4 メインライン：Z3 の rlimit を kernel ごとに設定可能に、デフォルトは依然 10 万（#3752、tile-ai/tvm #91 に依存）

23:05 にマージ、前提は fork 内の tvm #91（23:03 マージ）。変更は Z3 ソルバの rlimit をハードコードされた 100,000 から kernel ごとにカスタマイズ可能にする。設定しない場合は従来のデフォルト値を維持する。著者の表現は率直で、「これにより Z3 証明器に関連する多くの問題が間接的に修正される」。この類の変更の意義は、「証明が予算超過する」を調整不能な環境挙動から調整可能なコンパイルパラメータへ変えることにあり、昨日の昇騰側で AutoSchedule の周期下限を厳格化した（Z3 求解時間を 10.04% 削減）のと同一方向の 2 つの手法である。一つは探索起点を変え、一つは探索予算を変える。

出典：https://github.com/tile-ai/tilelang/pull/3752、https://github.com/tile-ai/tvm/pull/91

1.5 メインライン：ネストした T.macro が変換テンプレートを再利用、フロントエンドの重複コンパイルオーバーヘッドが収束（#3760）

23:38 に一致。問題は、外側の関数が実行されるたびに、ネストされた T.macro 定義がソース解析、AST 書き換え、Python コンパイルを毎回やり直してしまうことにある。たとえ kernel 自体がすでにキャッシュにヒットしていてもだ。修正方法は、有界なプロセス内キャッシュを導入し、コンテキストに依存しない変換結果（未バインドのコードと書き換え後のソース）だけを保存し、各マクロインスタンスが現在の globals とクロージャ値をバインドするようにする。コンテキスト依存の変換は元の経路を通し、ラップされた関数はキャッシュを迂回する。マクロ呼び出し箇所と kernel キャッシュはどちらも変わらない。回帰テストは新しいクロージャ、globals、キャプチャしたバッファ、アノテーション、コンテキスト依存のフォールバック、クロージャのライフサイクルをカバーする。CPU 側のフロントエンドチェックは通過し、GPU 実行はローカルでは未検証——作者はこの境界を明確に書き記している。

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

1.6 新規 issue：条件付きスカラー化後に __syncthreads が欠落、0.1.12 から 0.1.15 まで誤った CUDA を無警告で生成（#3808）

21:14 に作成され、本調査期間で最も重大な欠陥報告である。再現は共有メモリ epilogue の kernel で、0.1.12、0.1.13、0.1.14、0.1.15 の 4 バージョンすべてが、条件に関連するスカラー化の後に __syncthreads() を 1 回欠落させ、コンパイラは一切エラーを出さず、生成された CUDA は直接誤った計算結果を出す。報告者は完全に実行可能な Python 再現スクリプトと環境（Python 3.14.9、CUDA 2.15.0+cu134）を提供している。この種の問題の破壊力は、4 つのリリースバージョンにまたがりながら一切の警告がない点にある——共有メモリをフェーズ間の受け渡しに依存する kernel はすべて踏む可能性があり、ユーザー側に見えるのは「結果がおかしい」だけである。

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

1.7 新規 issue：warp specialization なしの場合、T.Pipelined が tcgen05 ウェイト前に stage を再ロード（#3800）

08:44 に作成。トリガー条件は warp specialization を無効化（tl.disable_warp_specialized=True）した上で T.Pipelined と T.tcgen05_gemm のループを実行すること：stage が mbarrier_wait_parity の前に次のラウンドのコピーで上書きされ、MMA は書き換えられた operand を読んでしまう。報告者は lowering された kernel ソースを貼り付け、As の書き込みと tcgen05mma_ss の読みの間に順序制約が欠けていることを指摘している。#3808 と同じく「生成されたコードは問題なさそうに見えるが、実際には成立しない」という類であり、違いはこちらが Blackwell の tensor memory 経路上で発生する点である。

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

1.8 レビュー中：ネイティブ Apache TIRx への完全移行草案（#3803）、共有転置は ldmatrix/stmatrix 経由に変更（#3809）

#3803 は今号で最も重要なレビュー中項目である：vendored の TVM コンパイラを独立した Apache TIRx に置き換え、フロントエンド、IR 変換、コード生成、JIT 適応、パッケージングをすべてネイティブのオブジェクトモデルに移行し、apache/tvm-tirx の 7e49a148 と apache/tvm-ffi の 3e906bc6 という 2 つの上流コミットを pin し、依存ツリーはクリーンな上流を保ち、パッチを注入しない。作者はこれを draft と標記しており、それ自体が「基盤の世代交代」の公開準備である。

#3809（01:27 提出）は別の具体的な問題を扱う：T.transpose は 2 つの共有バッファ間でずっと汎用 SIMT ループを通しており、8 ビットと 16 ビットのタイルは共有メモリ帯域を活かせず、examples/deepseek_v32 の FP8 疎 MLA は 16x16 のレジスタ一時退避を手書きして回避するしかなかった；同時に T.Pipelined がソース領域に stage 軸を 1 次元追加すると、ランクの不一致で MakeIndices が直接失敗する。修正方法は、stmatrix をサポートするターゲット（SM90 以上、CuTeDSL を除く）でまず warp-matrix lowering を試すことである：16 ビットタイルは各 8x8 ブロックで ldmatrix 1 回と stmatrix.trans 1 回を使い、8 ビットタイルは 16x16 バイトブロックごとに ldmatrix.trans 2 回と __byte_perm 選択で 4 行を組み立て、残りの領域は元の SIMT 経路にフォールバックする。

出典：https://github.com/tile-ai/tilelang/pull/3803、https://github.com/tile-ai/tilelang/pull/3809

2. マルチバックエンド適応

2.1 昇騰：bitwise_rshift の 64 ビット dtype を明示的エラーに変更、セグメンテーションフォルトを廃止（#1954）

16:36 にマージ（ascendc_pto ブランチ）。A2/A3 上で公開 API T.tile.bitwise_rshift に int64/uint64 オペランドを渡すと、コンパイラは OptimizeForTarget 段階で直接セグメンテーション違反を起こす。修正方法は、intrinsic を構築する前に dst と src0 の dtype をチェックし、int16/uint16/int32/uint32 のみを許可し、それ以外は実際の dtype とサポートリストを含む ValueError を投げる；シフト量 scalarValue は式の dtype を制限しない；Buffer と BufferRegion は統一的に _underlying_buffer() を通す。直接 API の診断テストとサブプロセスクラッシュの回帰テストを追加。作者は境界を明記している：今回は 64 ビット右シフトのサポートを追加せず、低レベル intrinsic を直接構築する経路も変更しない。関連 #1720。

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

2.2 昇騰：A2/A3 性能スキルを Ascend950 ワークフローに整合（#1932）

15:36 にマージ。純粋なスキルとプロセスのリファクタリング：A2/A3 の性能チューニングスキルを A5（Ascend950）ワークフロー構造に整合・統一し、チップ種別識別とチップ情報検索の二つのスキルを新規追加。単体では機能的な価値はないが、性能チューニングの「操作マニュアル」がチップ世代ごとに分岐し始めたことを意味する——同じ skill セットが自分がどの世代上で動いているかを識別できなければ、チューニング提案は世代を跨いで誤用される。

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

2.3 昇騰：threads=2 で tmp workspace が無条件に半減され、sin/cos が間接アドレッシング tile 上で 97.1% の要素が誤計算（#1991 / #1992）

17:03 と 17:25 に同題の issue が連続して二件オープン。タイトルと本文は一致（内容的には同一のものが二回提交されたと見なせる）。報告環境は 910_9362 / CANN 9.0.0、threads=2（C:V=1:2）。根本原因は AscendVidReduction にある：カーネル内のすべての UB 割り当てを無条件に半減しており、これには InjectTmpBuffer が注入する tmpspace も含まれるが、skip-set buffer（GM インデックスに UB load を含む間接アドレッシング、例えば T.copy(KV[b_i, idx_ub[bi_i], g_i, :D], kv_ub)）の形状はブロック全体を保持し、本来 vid の半減には参加しない。影響は二段階：sin/cos は直接誤計算（upstream HEAD 上で 3978/4096 個の要素が誤り、97.1%）；sigmoid/round は AscendC の calCount <= tmp 契約に違反し、数値は偶然正しいが越境書き込みがレイアウト後方の scratch に落ち、レイアウトが変われば静かなデータ汚染となる。報告者はこれが #1897 のレビュー時に発見されたもので、#1897 の修正は count 側のセマンティクス（HasModifiedBuffer が workspace スロットをスキップ）のみをカバーし、workspace 側は未処理であると説明している。

出典：https://github.com/tile-ai/tilelang-ascend/issues/1991、https://github.com/tile-ai/tilelang-ascend/issues/1992

2.4 海光：ブランチに三件の LDS 位相修正、初めて二つの PR をオープン（#33 / #34）

メインブランチは依然 11-02 のままで、当日の三件はすべて feat/hcu-scaled-cast ブランチにあり、作者は海光側（コミットドメイン hygon.cn）：

  • 10:06 fix(hcu): adapt default LDS swizzle to 64-bank phases
  • 14:04 fix(hcu): restore LDS swizzle planning for MN slice consumers
  • 19:49 fix(hcu): support K-partitioned layout-aware LDS reads

さらに重要なのはレビュー状態の変化：09:08 に PR #33（scaled cast、すなわちブランチ本体）をオープン、19:52 に PR #34（reduction の XOR shuffle を DPP と lane swap で最適化、加えて「レイアウト推論は既知の制約を先に伝播してから自由候補を割り当てる」修正）をオープン。前回のレポートでは「四件とも機能ブランチ上にあり、まだ PR は未オープン」と書いたが、今調査期間のこの二つの PR が海光を独自ブランチから公共レビューへと進めた。国産バックエンドの中でこの経路を完走した最初のものである。

出典：https://github.com/tile-ai/tilelang-hygon/pull/33、https://github.com/tile-ai/tilelang-hygon/pull/34、https://github.com/tile-ai/tilelang-hygon/commit/07451160e5aa758419201adb598725cbef70e3a4

2.5 摩尔線程：README ドキュメント更新、09-30 以来の沈黙を終了（11-05）

19:46 にメインブランチへ docs: update README installation and operator development references がマージされ、当リポジトリにとって 09-30 以来の初コミットとなった。同時期に 6 件の遺留 PR（#1 から #7 のうち依存関係アップグレード、TileOPs サブモジュール、MUSA 統合の証拠基準ドキュメント）のタイムスタンプが一括で更新されたが、内容は依然として 04 月から 08 月の古い提案であり、本調査期間にコード変更はない。判断としては保守的に見るべきである。ドキュメントのコミットはリポジトリが誰かによって維持されていることを示すが、バックエンド開発の再開を証明するには不十分であり、真のシグナルはその後オペレータや lowering のコミットが現れるかどうかで判断する必要がある。

出典：https://github.com/tile-ai/tilelang-musa/commit/4cac45b859108a86ac9a0b1cbfdeb33da7711697

2.6 沐曦と mlir-ascend：沐曦は 3 期連続でプッシュなし、mlir-ascend は 3 件の TLIR オペレータが審査中（11-05）

tile-ai/tilelang-metax の最終プッシュは依然として 10-26 であり、3 期連続で沈黙している。tile-ai/tilelang-mlir-ascend のメインブランチに新規コミットはないが、TLIR 方言に基づく 3 件のオペレータ PR が進行中である：#203 は TLIR に tl.sub/mul/div/max/min を追加し、TL から HIVM への lowering を補完するもので、01:42 に更新された；#211 は tl.shl を追加し、#212 は tl.shr を追加するもので、それぞれ 19:44 と 20:58 に相次いでコミットされた。このラインが取り組んでいるのは、TileLang のセマンティクスを一層ずつ MLIR 方言へ落とし込むことであり、ペースは遅いが方向は一貫している。

出典：https://github.com/tile-ai/tilelang-metax、https://github.com/tile-ai/tilelang-mlir-ascend/pull/203、https://github.com/tile-ai/tilelang-mlir-ascend/pull/211、https://github.com/tile-ai/tilelang-mlir-ascend/pull/212

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

3.1 TileOPs：9 件マージ、ブロードキャストオペランドのインプレース読み取り、GEMM 単一波次充填、reduction レイアウトキャッシュ（11-05）

9 件は 14:01 と 21:06 から 22:46 の 2 つの時間帯に集中しており、1 件ずつ主干を見ていく：

  • #2832 ブロードキャストオペランドのインプレース読み取り：LerpTensorFwdOp、WhereFwdOp、ClampTensorFwdOp、MaskedFillScalarFwdOp、MaskedFillTensorFwdOp の五種類のオペレータは、stride 0 のブロードキャストテンソルをまず出力形状に展開せず、一つの kernel 内で stride 0 のまま直接読み取る。共有 builder 一つが五種類すべてにサービスし、オペランド形状は一つのループネストに統合され、16 バイト以内のベクトルは一行の内側ループに留まり、各オペレータは自身の要素ごとの本体のみを記述する。ブロードキャスト行の所要時間はメインラインの 0.13 から 0.44 倍で、torch-compile と同等かそれ以上。残りの要素ごとの行はメインラインとバイト単位で一致する。
  • #2829 単項要素ごとの単一ウェーブ：本体内で最大二つの操作がそれぞれ一命令に降格され、読み書き総量が L2 の四分の三を超えず、結果とオペランドが同幅である場合、256 スレッドの一波に縮小される。併せて ReLU が NaN に対して 0 を返す問題を修正（NaN を返すよう変更、16 ビットは torch ビットパターン、float32 は正規 NaN を使用）。H200 上で 327 項目の GPU リグレッションが全て通過し、13 項目の新規ケースが Compute Sanitizer memcheck を通過した。
  • #2834 小 M NT GEMM のネイティブ幅タイル：ds-v3-decode-down（128x7168x2048、NT）はメインライン上で 132 個の SM のうち 112 個しか使用せず、112 幅のタイルは 0.1.12 で七つの n16 WGMMA に分割されていた。16 個の K ごとにタイル自身の幅の WGMMA を発行するように変更した後、decode-down は最速比較項目を 3% リードし、gate-up-b32 はメインラインより 1.4% 高速（依然として cuBLAS に 0.5 から 1% 劣る）。新規の fill タイルは 96 < M <= 128 かつ N が 8 で割り切れる形状にのみ有効化され、構造因子 0.58 を別途フィッティングした。
  • #2835 reduction レイアウトキャッシュ：リダクション kernel は呼び出しごとに軸置換と出力形状を再構築していたが、ReduceCall は固定である。各 kernel インスタンスで一度だけ計算し、既存のテンソルアダプタと純粋な形状 helper を共有するように変更し、グローバルキャッシュは導入しない。六組の FP32/BF16 VarMeanFwdOp 設定の完全なホットコール所要時間が 4.33% から 6.17% 低下し、生成される CUDA とホストソースは完全に一致——削減されたのは呼び出し準備コストであり、GPU 時間ではない。
  • #2833 CI 修正：GitHub が runner 2.336.0 を廃止した後、gpu-smoke が全てキューに滞留し、entrypoint.sh が --disableupdate を伴い自己アップグレードできなかったため、RUNNER_VERSION を 2.336.0 から 2.338.2 に引き上げた。

出典：https://github.com/tile-ai/TileOPs/pull/2832、https://github.com/tile-ai/TileOPs/pull/2829、https://github.com/tile-ai/TileOPs/pull/2834、https://github.com/tile-ai/TileOPs/pull/2835、https://github.com/tile-ai/TileOPs/pull/2833

3.2 TileOPs：roofline 計価ルールを書き換え、物理的に不可能な三つの帯域行が妥当な区間に復帰（#2830）

夜間タスク 41873301494 が物理的に不可能な roofline の三行を検出した：GQAVarlenFwdOp の二つの gpt-oss-serve-window 設定が 7.48 と 7.50 TB/s、GroupedGEMMFwdOp の qwen3-30b-ep8-empty が 5.30 TB/s を記録した。本コミットは計価ルールを「今回の呼び出しが実際にどれだけ読んだか」に基づいて書き換える：GQA の稠密、varlen、ページング前向きは「query が見える key 行」に対してのみ K/V を計上し、「key が見える query 行」に対して q を計上し、key が実際に到達する切り詰め位置に対して RoPE 表を計上し、key が見えるリクエストに対して FP8 スケーリングを計上する；GroupedGEMM は新規の grouped_gemm_roofline により batch_sizes に基づいてある行のグループを計価する；NSA 圧縮、NSA スパース、DSA decode、MHA ページング、FP8 lightning indexer はいずれも実際に読み取る位置でのみ課金し、DSA はさらに is_causal=False を認識する。修正後、三行は 0.62、0.62、2.65 TB/s になった。副次的な利益として、空の K/V ストレージと空のページングプールのゼロ除算も修正された。テストノードを 16 追加。

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

3.3 TileOPs：2 件のマージが 2.5 分間隔だったため main の GPU Smoke が失敗、当日補修（#2837）

22:46 にマージされたこのコミット自体が1件の規律記録である。#2824 は 21:06 のマージ時に grouped GEMM の roofline 行を、sizes を必ず宣言しそこから G を導出する形に変更した。#2830 は 21:08 にマージされ、依然として G のみで sizes がない内容だった。2件は約 2.5 分差で、それぞれの CI はグリーンだったが、マージ後の main の GPU Smoke が直ちに RowError: row misses ['sizes'] を報告した。修正方法は _grouped の G: 2 を sizes: [1, 0] に置き換えることで、断言されるバイト数（24、32）は変わらない。この種の事故の原因は誰かが書き間違えたことではなく、並行マージに post-merge ゲートがないことにある。単一コミットの CI 通過では「2件の意味が交差する」状況をカバーできず、マージ直後に全量を実行するしかない。

出典：https://github.com/tile-ai/TileOPs/pull/2837、https://github.com/tile-ai/TileOPs/pull/2824、https://github.com/tile-ai/TileOPs/pull/2830

3.4 TileOPs 審査中：三階段タイル因子、TN 単一要素縮約、FP8 グループ GEMM の TMA スケール読み込み（#2836 / #2838 / #2839）

#2836 は coop2_swap の三階段タイルに单独のフィッティング因子（1.36）を与える。FLOP で計算すると四階段より速くはないが、バイト数と K ステップ数では約 10% 過大評価され、その結果 160 幅のタイルが押し出され、夜間成績が 1.005～1.011 倍から 0.985～0.995 倍 QuACK に落ちていた。因子はその 42 個の off-manifest 形状のみでフィッティングされ（プラトー領域 1.344～1.392）、44 形状スキャン上でセレクタの regret は幾何平均 0.89% から 0.06% に、最大は 5.04% から 0.99% に下がった。#2838 はディスパッチャが K を連続次元とみなし、TN レイアウト K=1 の正当な呼び出しを却下していた問題を修正する（A=[1,64]、B=[1,64] で AᵀB を求めるのは本来 cp.async 内核で計算できる）。両側オペランドの物理連続次元がそれぞれ少なくとも 4 バイトの行幅を持つかをフォールバックで確認する形に変更し、24 個のテストノードを追加した。#2839（00:56 コミット）は FP8 グループ GEMM で TMA を使って A のスケールを読み込み（各ボックス 4 つの K ステップ、stage_scales 2、3 行でキャリブレーション）、K <= 1536 の非融合タイトグループ BF16/FP16 GEMM には 64x256 の ping-pong タイルを適用する。FP8 qwen3-30b-ep8-skew-up は 0.973 から 1.015 倍 DeepGEMM に、BF16 skew-down は 0.962 から 1.099 倍 QuACK に向上した。#2840（06:51 コミット）は SM89 の prefill sinks を補い、sink の有無をコンパイルインスタンスの同一性に含める。

出典：https://github.com/tile-ai/TileOPs/pull/2836、https://github.com/tile-ai/TileOPs/pull/2838、https://github.com/tile-ai/TileOPs/pull/2839、https://github.com/tile-ai/TileOPs/pull/2840

3.5 TileFoundry：WGMMA 同期計画マージ（#286）、部分縮約の完了セマンティクス審査中（#288）

13:40 にマージされた #286 は前号で審査中だった項目で、WGMMA の非同期性を扱う。命令発行後も共有メモリとレジスタの読み取りが続くため、後続のアクセスはその効果の後に並べる必要がある。方法は各オペランド効果に完了条件を宣言し、fence、commit、wait を必要とする HIR ノードに紐づけ、lowering が命令発行点でこれらのステップを消費する。後続スコープに集合待機を収められない場合は発行スコープ内で完了させる。同時にレジスタ Reshard の別名を修正し、各要素がコピーを保持する各スレッド上で同じレジスタに留まるようにし、このストレージ同一性でレジスタ依存を追跡する。SM90 では sm_90a で個別にコンパイルし WGMMA グループステップを発行する CUDA ユニットを生成する。著者は 2 つのリスク宣言を残している。行列命令エミッタはまだ接続されておらず、このコミットは実行正確性を証明せず性能も与えない。TMA の完了セマンティクスは別途扱う。20:12 に別途 #288 を開き、「完了した部分縮約」の分析における計価を扱う。

出典：https://github.com/tile-ai/TileFoundry/pull/286、https://github.com/tile-ai/TileFoundry/pull/288

3.6 TileSight：H20 の WGMMA 能力宣言を修正、リポジトリ初の PR（#1）

14:37 コミット、17:26 更新、これは tile-ai/TileSight（24 星）の最初の PR。このリポジトリは 07-24 の arXiv 論文「TileSight: A First-Principles Tile-Centric Analytical GPU Performance Model from Cores to Clusters」のオープンソース実装である。タイル形状、データ移動、ソフトウェアパイプライン、ハードウェアプロファイルから出発し、CPU 上でオペレータのコスト、キャッシュトラフィック、実行時間を見積もり、CUDA/HIP プローブが対象 GPU を個別に測定する。この変更は小さいが方向性は明確である。H20 は Hopper/GH100 であり、requires_arch=("wgmma",) を持つ計画は、アーキテクチャプロファイルが WGMMA サポートを宣言していなかったため従来は UnsupportedError を投げていたが、今回 support_wgmma=True とし、明示的に support_utcmma=False を維持することで、こうした計画は受け入れられ、tcgen05 と Tensor Memory の要件は引き続き拒否される。著者は同時に、容量は SKU ごとに分けて扱う必要があると指摘している（NVIDIA は H20 の 96 GB と 141 GB を同時に掲載している）。今回は能力メタデータのみを変更し、容量、帯域幅、周波数、スループット、使用率の数値はすべて変わらない。検証は CPU 上で 847 項目すべて合格であり、「GPU 性能の検証ではない」と明確に宣言している。

出典：https://github.com/tile-ai/TileSight/pull/1、https://arxiv.org/abs/2607.22432

3.7 採用者とサードパーティ：TileKernels、FlashQLA はプッシュなし；新たなサードパーティリポジトリが 2 つ出現（11-05）

deepseek-ai/TileKernels は依然 10-14 のまま、QwenLM/FlashQLA は 10-30 のまま、今調査期間はいずれもコミットがなく、FlashQLA の最新リリースは依然 09-30 の v0.1.3 である。サードパーティ側では新たに小さなリポジトリが 2 つ出現した。Tianchen-ai/tilelang-weft-bench（「TileLang-Weft full CPU operator benchmarks using the shared Weft Bench engine」、0 星、CPU 側オペレータベンチマークの統一エンジンを構築）、flytiger-eco/tilelang-wrapper-for-sail（0 星、説明なし）。いずれも非常に初期段階であり、まずウォッチリストに記載し、技術的進展として扱うべきではない。

出典：https://github.com/deepseek-ai/TileKernels、https://github.com/QwenLM/FlashQLA、https://github.com/Tianchen-ai/tilelang-weft-bench、https://github.com/flytiger-eco/tilelang-wrapper-for-sail

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

4.1 ドキュメントサイトが 3 回更新；ナイトリポジトリはメインブランチにコミットなし；昇騰の毎日テスト 3030 項目すべて合格（11-05）

tile-ai/tilelang.github.io は 16:07、19:33、23:43 にそれぞれ Update docs をプッシュし、メインリポジトリ当日のインターフェース変更（host-mapped アノテーション、TF32 rounding、Z3 設定）に対応している。TileOPs-nightly はブランチのプッシュのみで、メインブランチに新規コミットはない。TileOPs.github.io は 09:02 に 1 回プッシュがあった。昇騰リポジトリの毎日テスト issue #1988 には、11-05 08:16 の 1 ラウンドで 3030 項目すべて合格、合格率 100% と記録されており、同日に新規作成された #1991/#1992 と対照をなしている（2.3 を参照）。

出典：https://github.com/tile-ai/tilelang.github.io、https://github.com/tile-ai/tilelang-ascend/issues/1988

4.2 ニュース側：4 組のクエリ、Hacker News と arXiv はいずれも調査期間内にヒットなし（11-05）

Google News の4組のクエリ（英語 "TileLang" OR "tile-lang"、TileLang GPU kernel、中国語 TileLang 算子、TileLang 编译器）の中で、最新のヒットは376時間前のSemiAnalysis「The Huawei-DeepSeek Symbiosis」で、残りは09-30の「DeepSeek オープンソース昇騰版 TileLang、DeepGEMM、DeepEP」に関する報道（約880時間前）に集中しており、いずれも本調査期間より前である。Hacker News を tilelang で検索すると24時間以内は0件で、取得された3件の Show HN はターミナルデータビューア、ワークフローエンジン、macOS ファイルマネージャーであり、テーマとは無関係である。arXiv の all:tilelang の最新ヒットは11-03の「Beyond Compression Ratio: High-Throughput KV Compression for Disaggregated LLM Serving」（調査期間外、TileLang を引用する研究）で、さらに遡ると07-24の TileSight 本体である。したがってレポート本体は引き続きすべてコード側からのものである。

情報源：https://news.google.com/、https://news.ycombinator.com/、https://arxiv.org/

5. トレンド観察

第一に、オペレータライブラリの競争点は「オペレータの数」から完全に「セレクタと準備コスト」へ移った。本日の TileOPs の9件のうち、実際に GPU kernel を変更したのは #2832（ブロードキャスト就地読み）と #2834（ネイティブ幅タイル）のみで、#2835 が節約するのは呼び出し準備（4.33% から 6.17%、生成ソースコードは不変）、#2836 が変更するのは1つのフィッティング因子で、regret は 0.89% から 0.06% に低下した。これは、性能差の残された余地が主に「どう計算するか」ではなく「どのタイルを選ぶか、どの準備作業を減らすか」にあることを示している。この道を突き詰めると、手調整パラメータの山ではなく、キャリブレーション契約で記述されたコストモデルに到達する——本日の #2836 の「単独フィッティング、定数を1つだけ動かす」はまさにその形態の雛形である。

第二に、コンパイラ側の現在の主要な欠陥タイプは「静かに誤ったコードを生成する」ことであり、コンパイル失敗や性能不足ではない。#3808 は 0.1.12 から 0.1.15 の4バージョンにわたり __syncthreads() を1つ欠いており、#3800 は Blackwell パスで MMA が上書きされた operand を読んでしまい、#1991/#1992 は昇騰 threads=2 の下で sin/cos が97.1%の要素を誤計算する——3件ともエラーを出さず、通常のテストを通過し、的を絞った再現を人手で書かなければ捕捉できない。この種の欠陥はユーザーへの損害が最大である。なぜなら「コンパイラは正しいか」という前提を、検証を要する仮説に変えてしまうからだ。これに対応するエンジニアリング上のアクションは、ユニットテストの数を増やすことではなく、形状組み合わせの差分テスト（対照群は reference 実装による要素ごとの比較）を拡大することであるべきだ。

第三に、昇騰側のリズムは「アーキテクチャ変更後のリグレッション一掃」から「正確性境界の一掃」へ移っている。#3512 のような構造的変更がもたらした4種類のリグレッションを前の調査期間でちょうど一掃し終えたところで、本調査期間の2件のマージ（セグメンテーション違反をエラー報告に変更、性能スキルの世代分け）と2件の新規 issue（tmp workspace の半減、calCount <= tmp の違約）はいずれも境界の収束に属する。注目すべきは、#1991 の報告者が #1897 のレビュー側であり、#1897 の修正方法は count 側のみをカバーしていたことだ——同一のレイアウトロジックの別の側面が2週間後に指摘されたことは、昇騰バックエンドのレイアウト不変条件がまだ検査可能な書面契約として形成されていないことを示している。

第四に、国産バックエンドの「公共化」が加速している。海光は独自開発ブランチから2つの正式 PR へと進み、摩尔線程はドキュメント保守を再開し、mlir-ascend は3つの小さな PR で算術オペレータを1つずつ TLIR 方言へ移している。3つのラインの共通点は、いずれも「大きなバックエンドを一括でマージする」のを待つのではなく、レビュー可能な最小単位を公共リポジトリへ押し出していることだ。これは上流にとって良いことである。レビュー担当者が3万行の一括マージ時に初めて見るのではなく、早い段階でレイアウトと lowering の設計に意見を述べられるからだ。

最後のリスク面：主リポジトリ #3803 の TIRx 移行が推進されれば、3rdparty/tvm の vendored 構造は2つの pin された上流コミットに置き換えられ、その時点で TVM 内部 API に依存するすべてのバックエンド（昇騰、海光、mlir-ascend のグルーレイヤー）が追随して変更を迫られる。草案には「依存パッチを注入しない」と明記されており、これは約束であると同時に制約でもある——本日 mlir-ascend が BishengIR アダプタを contrib へ移し、昇騰が性能スキルをチップ世代ごとに分岐させたことは、いずれもこの種の基盤切り替えに備えて用意された交換可能な面と見なせる。

付、素材と検証説明

情報源検証表

情報源 調査結果
tile-ai 組織（29 リポジトリ） 調査期間内に 10 リポジトリへプッシュ
メインリポジトリ tilelang メインブランチに 5 件マージ；新規 issue 2 件（#3808、#3800）；審査中の更新はスカラー化、CuTeDSL、Profiler、Ascend の 4 クラスタが主
TileOPs メインブランチに 9 件マージ；審査中 4 件の新規または更新；新規 issue なし
TileFoundry メインブランチに 1 件マージ（#286）；審査中 1 件（#288）
TileSight 初の PR（#1）、メインブランチへのコミットなし
tilelang-ascend デフォルトブランチ ascendc_pto に 2 件マージ（#1932、#1954）；新規 issue 3 件（#1991、#1992 は同題、#1988 はデイリーテストレポート）
tilelang-mlir-ascend メインブランチに新規コミットなし；#203、#211、#212 の 3 件の TLIR オペレータ PR が進行
tilelang-hygon メインブランチに新規コミットなし（11-02 で停止）；feat/hcu-scaled-cast ブランチに 3 件；新規 PR #33、#34
tilelang-musa メインブランチに 1 件のドキュメントコミット（09-30 以来初）；6 件の遺留 PR のタイムスタンプを更新、内容は不変
tilelang-metax 調査期間内にプッシュなし（連続 3 期目）
TileOPs-nightly / TileOPs.github.io / tilelang.github.io ナイトリポジトリのメインブランチにコミットなし；TileOPs ドキュメントサイトに 1 回プッシュ；tilelang ドキュメントサイトに 3 回 Update docs
リリースページ（tilelang / TileOPs / TileFoundry） 調査期間内に新バージョンなし；tilelang の最新は依然 09-30 の v0.1.15、TileOPs は 10-27 の v0.1.0、TileFoundry は 10-25 の v0.0.4rc1
TileKernels / FlashQLA 調査期間内にプッシュなし
TileLang×RISC-V 四源巡検 変化なし（4 つの上流の引用と PR 状態は前回スナップショットと一致）
Google News（中英文 4 組）/ Hacker News / arXiv 調査期間内に実質的なヒットなし、最新ヒットは 376 時間前

完全な情報源リスト

検証説明

本期のすべてのマージ済み、レビュー中、issue、コミット数は GitHub検索と原子ソースの実測出力に由来する：マージ済みとレビュー中はsearch APIを使用（マージ済み18件、レビュー中更新57件、新規issue 5件）、コミットタイトルは各ブランチのcommits atomを使用（12ブランチ、21件が調査期間内）、リリースはreleases atomを使用。組織レベルの匿名APIは収集後半に時間制限に達したため、メインブランチ以外の組織リストはウェブとatomソースのクロスチェックで対応し、推定値は使用していない。#1991と#1992の2件のissueはタイトルと本文が一致しているため、「同題2件」として記録し、1件に統合していない。海光の3件と摩尔線程の1件は未マージのコミットであり、ブランチレベルの動向として記述しており、メインラインにマージ済みであることを意味しない。TileSightとTileFoundryのWGMMA関連の変更はいずれも作者自身が能力メタデータまたは同期計画に限定しており、実行の正確性や性能を主張していないため、レポートはその限定に従っている。Google News、Hacker News、arXivの3つのニュースチャネルは本調査期間においていずれもヒットなし。