調査期間：過去24時間（2026-09-16 19:23 ~ 2026-09-17 19:23、北京時間；本タスクは毎日07:00定時の初回試運用であり、判定は当日夕方に実行、期間は依然として24時間で取得） 情報源：GitHub（tile-ai組織28リポジトリのpushed_atを全量確認、期間内に9リポジトリでプッシュあり；tilelang、tilelang-ascend、tilelang-metax、tilelang-hygon、TileOPsなどのリポジトリで期間内のコミットを逐条再確認、主要PRの説明とベンチマークデータを照合；ブランチとタグのメタデータを交叉検証）、サードパーティ対応・採用側リポジトリ（tilelang-mlir-ascend、tilelang-musa、TileFoundry、TileRT、deepseek-ai/TileKernels、QwenLM/FlashQLA）、Google News RSSの中国語・英語複数クエリ（プロキシ経由）、Hacker News、arXiv、華為全聯接大会2026の現場報道（詳細は付録の情報源リスト参照）

本期インデックス

  • 今日の重点：T.gemm_blockscaledがメインリポジトリに進入——ブロック量子化GEMMに統一エントリが誕生（09-17）
    1. 中核プロジェクトの進展
      • 1.1 メインリポジトリにT.gemm_blockscaledとバックエンドセレクタを新規追加、ブロック量子化がサイレント降級しなくなる（09-17）
      • 1.2 アトミックベクトル幅がデスティネーションアドレス計画で決定されるように変更、埋め込み逆伝播などのカーネルが1.4倍から2.5倍高速化（09-17）
      • 1.3 アトミック加算が非連続デスティネーションアドレス上でスカラーを保持、サイレントな誤書き込みとアドレス未整列クラッシュの一種を修正（09-17）
      • 1.4 JITがuint64パラメータ型マッピングを補完、CythonとNVRTCホストラッパーが整合（09-17）
      • 1.5 TileOPs：MoEインデックス小規模ルーティングエキスパートパス、H200上でvLLMに対して全面的に優位（09-17）
      • 1.6 TileOPs：カーネル選択とビルドディスパッチを再構築、4箇所のオペレータパラメータをコンストラクタに移行（09-16/09-17）
    1. マルチバックエンド対応（昇騰 / 沐曦 / 海光 / 摩尔線程）
      • 2.1 昇騰：NSAフォワードとその可変長版が同日にマージ、910B3上で20マイクロ秒台に到達（09-17）
      • 2.2 昇騰：動的量子化、RMSNorm融合とRoPEサンプルでオペレータ面を補完（09-16/09-17）
      • 2.3 沐曦：MACA非同期コピーGEMMサポートがマージ（09-17）
      • 2.4 海光：HCUバックエンドがマルチレベルストレージとバッファストレージをrebase、パイプラインがprefer_asyncに移行（09-17）
      • 2.5 摩尔線程：MUSA 5.3.0ドキュメントにバックポートブランチを追記（09-17）
      • 2.6 産業側：華為全聯接大会2026で昇騰960とAtlas 960超節点の進展を公表（09-17）
    1. エコシステムと採用側
      • 3.1 tilelang-mlir-ascend：TileOPsマルチヘッドアテンションオペレータと適応型LayerNormがマージ（09-16）
      • 3.2 採用側リポジトリは期間内静か：TileKernels、FlashQLA、TileRTいずれもプッシュなし
      • 3.3 サードパーティ：TileSight性能分析技術ロードマップドキュメントが公開（09-17）
    1. コミュニティ、チュートリアルとイベント
      • 4.1 ドキュメントサイトがメインリポジトリと継続的に同期（09-17）
      • 4.2 学術・チュートリアル線：ICLR 2026論文とHugging Faceカーネルチュートリアル（背景、期間外）
    1. トレンド観察
      • 5.1 国産4社のバックエンドが同日並行進化、対応が一方通行の追随から同期推進へ
      • 5.2 メインリポジトリの2ライン並行：新ハードウェアのブロック量子化能力と既存カーネルの性能回補
      • 5.3 TileOPsの立ち位置はオペレータライブラリから推論エンジンと対表できるプロダクションレベルオペレータ層へ移行中
      • 5.4 本期間の空白とリスク点

今日の重点：T.gemm_blockscaledがメインリポジトリに進入——ブロック量子化GEMMに統一エントリが誕生

日付：2026-09-17　出典：tilelang #3237 ブロック量子化GEMMセマンティクスとバックエンドディスパッチ

本期間のメインリポジトリで最も重い変更は、「ブロック量子化GEMM」（block-scaled GEMM、すなわちMXFP8/MXFP4のようなブロック単位でスケーリングファクターを共有する低位幅行列乗算）を、各バックエンドに散在する特例から、言語層の正式なオペレータへと格上げしたことである。変更はGemmBlockScaledNode（src/op/gemm_blockscaled.{h,cc}に実装）と言語側のT.gemm_blockscaledを導入し、セマンティクスはC (+)= (A * SFA) @ (B * SFB)と記述される。すなわちスケーリングファクターをオペレータの一級入力とし、呼び出し側が外部で手動換算することを不要にした。

これと同時に、以前は静かにエラーを起こしていた二つの経路も修正される：一つ目は、SM100 上の単一 CTA ブロック分塊量子化 GEMM が、本来 SM120 だけが通るべき命令選択分岐に命中する可能性があること；二つ目は、ブロック分塊量子化能力を持たないバックエンドがそれを密 GEMM として降格実行し、スケーリングファクターがそのまま破棄されてしまうこと——結果は走り切るが、精度は間違っている。現在、ディスパッチは専用のバックエンドセレクタに切り替わり、cuda.tcgen05.blockscaled（SM100 ライン）と cuda.mma.blockscaled（SM120 ライン）の二つの実装に落ち着き、mbar、use_2cta、sf_layout などのパラメータ入口も保持されている。作者は SM100 級デバイス（sm_103）上でローカル検証し、1D1D レイアウトの MXFP8 分塊量子化サンプルと tcgen05 INT8 GEMM アサーションをカバーし、SM120 側の実行経路はローカル検証していないことを明示している。

同日にマージされた #3238 は別ラインの対偶アクションである：新しい能力を追加するのではなく、以前の一回の変更で導入された性能後退を取り戻す——詳細は 1.2 を参照。二つを並べて読むと、メインリポジトリの現在のリズムは「新ハードウェア経路の追加」と「既存カーネル性能の補修」を同時に推進していることにある。

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

調査期間総覧：tile-ai 組織の 28 リポジトリのうち、調査期間内にプッシュがあったのは 9 個：コアリポジトリ tilelang、国産バックエンド tilelang-ascend、tilelang-metax、tilelang-hygon、tilelang-musa、オペレータライブラリ TileOPs とそのサイト TileOPs.github.io、TileOPs-nightly、およびドキュメントサイト tilelang.github.io。調査期間内のコミット数で見ると、tilelang-ascend が 6 件で最多、tilelang が 4 件、TileOPs が 3 件、tilelang-metax が 2 件、tilelang-hygon が 1 件；tilelang-musa のプッシュはバックポートブランチに落ちておりデフォルトブランチではないため、デフォルトブランチ上には調査期間内のコミットがない。

1.1 メインリポジトリに T.gemm_blockscaled とバックエンドセレクタを追加、分塊量子化が静かに降格しなくなる（09-17）

日付：2026-09-17　情報源：tilelang #3237

詳細は「今日の重点」を参照。実装側の細部を二点補足する：一つ目は、分塊量子化 GEMM が GemmImpl から分離され、バックエンドごとに個別登録されるようになったこと。密 GEMM と分塊量子化 GEMM はそれぞれ別の実装スロットを通り、「あるバックエンドがそれを密オペレータとして扱う」という経路混同の再発を避ける；二つ目は、tl.gemm.infer_layout と tl.gemm.lower の二つの共有入口が厳密に 13 個の位置引数を受け取るよう要求され、新規オペレータはデフォルト値でごまかすのではなく完全なインターフェースを明示的に宣言しなければならなくなったこと。この PR のタイトルには「Do not review」接頭辞が付き、コアメンテナ自身によってセルフマージされ、マージ時には 19 個のコミットを伴っていた。

1.2 原子ベクトル幅が目的アドレスによって計画されるようになり、埋め込み逆伝播などのカーネルが 1.4 倍から 2.5 倍高速化（09-17）

日付：2026-09-16 から 2026-09-17　情報源：tilelang #3238

動的形状はレーンインデックスの外側に int64 変換を導入するが、以前のベクトル化判定は未簡約の Ramp 形式しか認めず、「ブロードキャスト基底アドレスに int64 レーンオフセットを加えた」ような等価な書き方に遭遇するとループ全体をスカラー化してしまう——明らかに四つのアラインメントされた連続要素にアクセスしているのに、要素ごとの実行に退化していた。修正では判定を目的アドレスに基づくよう変更し（elem_offset、IndicesCanVectorize、AtomicTargetIsContiguous の三箇所が協調）、c6ece48 をベースラインとして同一カードでの三回測定の中間値比較を示している：埋め込み逆伝播 N=8192/H=4096/V=129280 は 97.90 マイクロ秒から 56.01 マイクロ秒へ、N=196608/H=256/V=3000000 は 146.87 マイクロ秒から 82.70 マイクロ秒へ、もう一档は 86.62 マイクロ秒から 49.87 マイクロ秒へ、シーケンス補助カウントとサムは 18.40 マイクロ秒から 12.17 マイクロ秒へ；回帰ベンチマークでは example_gqa_bwd_tma_reduce_varlen が約 27% の相対的改善を獲得し、残りの用例の変動は 0.5% から 1.5% の間である。これは典型的な「コンパイラの書き換えルールが実際の推論性能に影響する」事例である——影響を受けた埋め込み逆伝播と可変長アテンション逆伝播はいずれも大語彙推論の常駐カーネルである。

1.3 原子加算が非連続目的アドレス上でスカラーを維持し、一種の静かな誤書き込みとアドレス未アラインメントによるクラッシュを修正（09-17）

日付：2026-09-16　情報源：tilelang #3219

1.2 と同源のもう一つのベクトル化欠陥：T.atomic_add の目的アドレスがベクトル境界内で不変な式（例えば i を 2 で割ったインデックス、または定数添字）の場合、旧ロジックはデータ型だけを見て幅を選び、「全レーンが同じセルに書き込む」というセマンティクスを 1 本の幅広いアトミック加算にコンパイルしてしまい、その結果、隣接要素がサイレントに破壊される。基底アドレスが奇数の場合はアドレス未整列で直接クラッシュする。修正では CanVectorizeAtomicTarget の事前判定を新設し、address_of、tl.access_ptr、tvm_access_ptr の 3 種類の目的アドレス形態をカバーし、非連続または未整列の場合は一律でスカラーにフォールバックする。この欠陥の影響範囲は小さくない——T.Parallel と T.atomic_add の組み合わせは GEMM split-K、アテンション逆伝播、層正規化の定番の書き方であり、かつ既存テストは N がスレッド数に等しい構成でちょうどこれを回避していた。

1.4 JIT が uint64 引数型マッピングを補完、Cython と NVRTC のホストラッパーを揃える（09-17）

日付：2026-09-17　出典：tilelang #3229

ホスト側ラッパーには以前 uint64 の型マッピングが欠けており、この型の引数に遭遇すると直接「サポートされていない dtype」を報告していた。修正後は Cython と NVRTC の両ホスト経路で uint64 実引数を処理でき、デバイス側の uint64_t 宣言と整合する。小さな穴ではあるが、補わなければ大整数インデックスとビット演算系カーネルで直接壁にぶつかる。

1.5 TileOPs：MoE インデックス小路由エキスパートパス、H200 上で vLLM に対して全面的にリード（09-17）

日付：2026-09-17　出典：TileOPs #2141

オペレータライブラリ側で本調査期間中最も重要な一件。変更は共有融合 MoE にインデックス式の小路由エキスパートパスを追加した：路由グループが疎で、単一エキスパートが実際に受け取る token が非常に少ない場合、インデックスによる集約型の実行方式に切り替え、大グループ下の非効率なパスを回避する。公開インターフェースは不変で、サポートされないデバイスと形状、大路由グループ、および未検証の活性化とレイアウトの組み合わせは一律で既存のフォールバックを維持する。作者は H200 上で BF16、top-8 sigmoid 路由と修正バイアス、CUPTI デバイス占有率タイミングおよび L2 フラッシュを行い、vLLM と 3 モデルを比較：GLM-4.5 は 4096 token の区分で 25.85% リード、DeepSeek-V3 は同区分で 16.03% リード、Kimi K2 は 8.65% リードし、小 token 区分でも概ね優位に立った。ベンチマーク自体も再構築され（以前のベースラインは信頼できなかった）、FusedTopK が少なくとも 49.3%、PermuteAlign が少なくとも 59.6% のセット全体の向上を示した；対照データは路由が固定シードの合成路由であり実際の checkpoint 軌跡ではないことを説明しており、正直な開示である。

1.6 TileOPs：カーネル選択と構築ディスパッチをリファクタリング、4 箇所のオペレータ引数をコンストラクタへ移行（09-16/09-17）

日付：2026-09-16 から 2026-09-17　出典：TileOPs #2146、TileOPs #2145

構造と 1.5 の性能変更は同日に発生し、同一の内部整理に属する。一つ目はディスパッチモデルを「まずカーネルを選び、次にどう構築するかを尋ねる」（Op.kernel_for / Op.entry_for）に変更し、GEMM ファミリはすべて選択されたクラスのディスパッチを通し、呼び出し側では判断しなくなった；二つ目は元々呼び出しごとに引数を渡していた 4 箇所のオペレータが引数を構築段階へ移し、うち MHP 前向きは外部ターゲットがある場合の初回呼び出しで直接属性エラーを投げ、ページドプレフィルオペレータは構築時に一度も代入されなかったシーケンス長フィールドを保持しており、いずれも実在する欠陥である；さらに 6 つのオペレータの出力型引数を統一して out_dtype に改名し、FP8 GEMM とそのバッチ版は文字列ではなく torch データ型を受け取るように変更した。作者は今回カーネル本体と生成コードを変更していないと明言しているため、性能的主張は行わず、価値は「選択時に一つのデバイスのアーキテクチャを読み、構築時に別のデバイスを読む」といったドリフトを排除することにある。

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

本調査期間の形態は 4 社の国産バックエンドが同日に在場することである：昇騰 6 コミット、沐曦 2 コミット、海光 1 コミット、摩尔線程 1 コミット（バックポートブランチ文書）。これは本デイリーレポートの自社収集において珍しい密度である——4 社が同じ日に実質的な動作を行い、それぞれ時間をずらしているのではなかった。

2.1 昇騰：NSA 前向きとその可変長版が同日にコミット、910B3 上で 20 マイクロ秒オーダーに到達（09-17）

日付：2026-09-17　出典：tilelang-ascend #1699、tilelang-ascend #1700

両方とも昇騰専用リポジトリの ascendc_pto ブランチに着地し、4分以内に相次いでマージされた（北京時間 11:44 と 11:49）。#1699 はネイティブ疎注意力（NSA）フォワードオペレータ：開発者モードのハイブリッド記法で実装され、コンパイラが Cube と Vector のスコープを自動分割し、クロスコア同期フラグを自動挿入するため、グローバルバリア、スコープ宣言、手動フラグビットの記述が不要；黄金配置下でのタスク所要時間は 19.62 マイクロ秒、精度階層テスト 27 例すべて合格、最大絶対誤差 1.95e-03。#1700 は可変長シーケンス対応を追加し、単一カーネルフォワード、永続化グリッド、4段パイプラインで、910B3 上のテスト配置所要時間は 20.34 マイクロ秒、21 例の階層テストすべて合格、許容誤差の二重ゲート標準口径で一致比率 1.0000 を示した。両者を合わせて見ると、昇騰側の DeepSeek 系疎注意力構造に対するカバレッジは「実装あり」から「可変長とテスト階層付き」へと進んだ。

2.2 昇騰：動的量子化、RMSNorm 融合と RoPE サンプルでオペレータ面を補完（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：tilelang-ascend #1688、tilelang-ascend #1673、tilelang-ascend #1580

3件のサンプル層の変更は、昇騰が「推論チェーン上の通常オペレータ」を補完していることを同時に示している：動的量子化オペレータ（#1688）は CANN ベンチマークとオンライン評価を経て、20 例の精度すべて合格、平均加速比 0.78 倍——すなわち精度は使用可能だが性能は依然としてベンダー基準に劣り、これは勝利の記録ではなくありのままの記録である；RMSNorm を重ねた動的量子化融合オペレータ（#1673）と回転位置エンコーディングオペレータ（#1580、半回転とインターリーブの2種類のレイアウトをカバーし、ベンチマークスクリプトと torch_npu との比較精度テストを添付）は、大規模モデル推論の前処理と位置エンコーディングという2つの環節を補完した。さらに #1603 は T.tile.merge_sort にインターフェースドキュメントとテストケースを追加した。

2.3 沐曦：MACA 非同期コピー GEMM サポートがリポジトリ入り（09-17）

日付：2026-09-17　情報源：tilelang-metax #156

沐曦側は MACA プラットフォームに非同期コピー GEMM パスを追加し、非同期メモリコピープリミティブ、バリア命令、非同期コピー完了カウントの3つのエントリを扱い、行列積のデータ移動が非同期パイプラインを通れるようにした；同日、別途テストケースの不具合修正が1件（#157）。沐曦にとってこれは「動く」から「速く動く」への一歩である。なぜなら非同期コピーこそが GEMM パイプライン重畳の前提だからである。

2.4 海光：HCU バックエンドが多段ストレージとバッファストレージを rebase、パイプラインを prefer_async に変更（09-17）

日付：2026-09-17　情報源：tilelang-hygon コミット 36db42e1

海光側の1コミットは19ファイルに及び、その動作は多段ストレージ（MLS）とバッファストレージの書き込みパスを rebase し、パイプラインのコピースケジューリングを prefer_async に変更することである。新たに追加されたバッファオフセット依存チェッカーは「ブロックインデックス関連」と「スレッドインデックス関連」の2種類でそれぞれ判定し、さらに構文指向の方法でブロックベースアドレスと残余オフセットを分離する——コメントにはこの境界が明記されている：バッファ注釈は呼び出し側の安全契約であり、コンパイラは範囲証明を行わない。この点は沐曦のものと同じ方向性である：両社とも同期移動を非同期パイプラインに置き換えつつある。

2.5 摩尔線程：MUSA 5.3.0 ドキュメントをバックポートブランチに追加（09-17）

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

摩尔線程リポジトリの調査期間内のプッシュは v0.1.12+musa.1 というバックポートブランチに着地し、内容は MUSA 5.3.0 のドキュメントを旧バージョンラインに追加するもので、デフォルトブランチには調査期間内のコミットはない。このシグナルはやや弱い：メインラインの直近の実質的コミットは 09-11 の公開リリース準備と 09-10 の一連のランタイム機能（対称 IPC 割り当て、IPC とオプションの仮想メモリ管理ランタイム、DLPack デバイス互換、システムレベルフェンス）であり、MUSA 側は当期は新機能ではなく保守的な動作である。

2.6 産業側：華為コネクト 2026 で昇騰 960 と Atlas 960 超ノードの進展を発表（09-17）

日付：2026-09-17　情報源：華為コネクト 2026 現地レポート（毎経、星島環球網転載）、昇騰 960 が 2027 年第1四半期に確定（網易転載）

昇騰はTileLangの国産バックエンドの中で最も活発な一支であり、そのハードウェアルートマップはオペレータとカーネルの適応テンポに直接影響を与えるため、産業側の動向を一件挙げる。9月17日に上海で開催された華為コネクト大会2026において、華為副董事長・輪番董事長の汪涛氏は、昇騰960DTを2027年第1四半期に前倒しでリリース、昇騰960PRを2027年第3四半期に前倒しすると発表した。Atlas 960超ノードは単体で4096個のNPUを高速相互接続でき、霊衢アーキテクチャとHi-ONE光エンジンに依拠し、往復遅延は最低2マイクロ秒、さらに初めて近接配置光学（NPO）光エンジンを適用し、液冷版は2027年第3四半期に投入予定。会議では他に、超ノードの累計導入が1000セットを超え、370社以上の顧客にサービスを提供していると述べた。

背景として（本調査期間内ではない）：9月8日のPyTorch Conference China 2026で、昇騰側はPyTorchが公式サポートする最初の中国ハードウェアになったと述べ、PyTorchと共に超ノード向けのネイティブソフトウェアスタックを構築する計画である。両者を合わせて見ると、昇騰のソフトウェアエコシステム上の位置づけは向上しており、オペレータDSL層（TileLang昇騰バックエンドを含む）にとっては追い風である。

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

3.1 tilelang-mlir-ascend：TileOPsマルチヘッドアテンションオペレータと適応型LayerNormがマージ（09-16）

日付：2026-09-16　情報源：tilelang-mlir-ascend コミット一覧

当該リポジトリは09-16夕方（本調査期間の前端に近い）に「TileOPsのマルチヘッドアテンションオペレータを接続する」変更をマージし、そのベンチマークスクリプトの欠陥を修正した。その前日には適応型LayerNormカーネルを補完済み。当該リポジトリは同時にCIを昇騰A3デバイスのrunnerタグに切り替えた——昇騰側はオペレータを書くだけでなく、検証を実デバイスパイプラインに移していることを示す。

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

日付：2026-09-17（確認）　情報源：deepseek-ai/TileKernels、QwenLM/FlashQLA、tile-ai/TileRT

本デイリーレポートの確認リストによると、採用側と推論側の3リポジトリはいずれも調査期間内にプッシュなし：TileKernelsの直近のプッシュは2026-04-23、FlashQLAは2026-08-26、TileRTは2026-08-13。TileRTは既に5週連続で更新がなく、現在のリストの中で最も静かな期間が長いものとなっている。これは否定的な結論を構成しないが、引き続き追跡する価値がある——TileRTが対象とするのは低遅延推論ランタイムであり、長期間の停止は「TileLangエコシステムが既に生産デプロイ段階に入った」というナラティブにエンジニアリング側の新たな証拠を欠かせることになる。

3.3 サードパーティ：TileSight性能分析技術ロードマップ文書が公開（09-17）

日付：2026-09-17　情報源：tilelang4tilesight-doc リポジトリ

サードパーティ開発者が、TileLangプログラムとTileSight性能分析ツールを接続する技術文書を公開した。内容はPythonと高レベル中間表現からの意味、ワークロード、依存の抽出、キャッシュとパイプライン分析への接続、ランタイム観測による独立レポートと連合予測の生成を含む。文書は性能問題をパイプラインのボトルネック、階層間転送異常、キャッシュ利用異常、計算とメモリアクセスのオーバーラップ失敗、負荷不均衡、モデル予測偏差の6種類に分類し、モデル予測、ランタイム観測、証拠不足の3種の結論強度を明確に区別しており、主に議論するプラットフォームはH200。価値は、TileLang側の観測とチューニングのツールチェーンが外部によって補完されつつある点にある。

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

4.1 ドキュメントサイトがメインリポジトリとともに継続的に同期（09-17）

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

ドキュメントサイトは調査期間内に自動同期コミットが1件あり（09-17 18:37 北京時間）、その前の09-16、09-15、09-12にもそれぞれ1件あり、テンポはメインリポジトリのマージとほぼ一致している。サイトの現在のバージョンは0.1.14で、ツール区にはコンパイルツール、性能アナライザー、レイアウト可視化、自動インクリメンタルデバッグ、中間表現下降トレース、オペレータプロファイリングなどの項目が既に含まれている。ドキュメントサイトの同期はボットによるコミットであり、本レポートはテンポの記録のみを行う。

4.2 学術とチュートリアルのライン：ICLR 2026論文とHugging Faceカーネルチュートリアル（背景、調査期間外）

日付：2026-04-23 から 2026-05-31（ウィンドウ外の背景）　出典：ICLR 2026 ポスターページ、TileLang 論文（arXiv:2504.17577）、Hugging Face チュートリアル「Writing High-Performance Kernels in TileLang」

本調査期間内に arXiv、Hacker News、および中英文ニュース検索のいずれにおいても TileLang 関連の新規内容は出現しなかったため、ここでは調査期間外に既に存在する学術・チュートリアル資産のみを列挙し、読者の対照に供する：論文は H100 上で最大 Triton 比 5 倍の高速化、融合アテンションカーネルのコード量を最大 90% 削減したと主張している；Hugging Face 上のチュートリアルは GEMM からマルチヘッド潜在アテンションまでの完全な記述方法を示し、さらに一つの実収益事例を記録している——それまで高速パスのなかったあるモデル設定が、TileLang で書かれたプラグアンドプレイカーネルに置き換えたことで「直接エラー」から「本番投入可能」へと変わった。

5. トレンド觀察

5.1 國産4社のバックエンドが同日並行進化、対応は一方向の追従から同期推進へ

昇騰、沐曦、海光、摩尔線程が同一の 24 時間ウィンドウ内でいずれも着地動作を行い、しかも方向性が高度に収斂している：いずれも非同期転送とパイプラインを補完し（沐曦の非同期コピー GEMM、海光の prefer_async、昇騰の多段パイプライン）、いずれも推論チェーンの通常オペレータを補完している（動的量子化、RMSNorm 融合、位置エンコーディング）。これは國産バックエンドの対応がもはや「上流が機能を出してから追従する」ものではなく、同一ラウンド内で各自が同一組の能力を補完していることを示している。

5.2 メインリポジトリの2本のラインが並行：新ハードウェアのブロック量子化能力と既存カーネルの性能回復

メインリポジトリの本ウィンドウにおける2件の大型変更は性質が相反しながらも同日にマージされた：一方では Blackwell 世代のブロック量子化 GEMM に統一エントリと専用ディスパッチを構築し（降格とパスの混同を回避）、他方では以前の書き換えによって生じたベクトル化の退行を修正した（埋め込み逆伝播がほぼ倍速に）。ブロック量子化が対応するのは MXFP8/MXFP4 といった低位幅フォーマットの推論側での普及であり、性能回復が対応するのは大語彙推論の常駐カーネルである——両者はいずれも「新規オペレータ」型の拡張ではなく、コンパイラ層の安定性と効率の作業であり、通常は点的なオペレータよりもプロジェクトが工程成熟期に入ったことをよく示す。

5.3 TileOPs の位置づけはオペレータライブラリから推論エンジンと対表可能なプロダクションレベルオペレータ層へ移行中

本ウィンドウで TileOPs は同時に二つのことを行った：一つは vLLM に対標する全表性能データを示し（GLM-4.5 4096 token 帯で 25.85% リード、DeepSeek-V3 同帯で 16.03%）、二つ目はカーネル選択とビルドディスパッチをクリーンに再構築し、不整合なインターフェースパラメータを一括で収束させた。vLLM との帯別対比を公開し、かつベンチマークが以前は信頼できなかったことを同時に認めることは、その検収基準がプロダクション可用へ近づいていることを示している；昇騰側の mlir リポジトリが直接 TileOPs オペレータを接続し始めたことは、この基準がクロスバックエンドで再利用され始めたシグナルである。

5.4 本ウィンドウの空白とリスクポイント

四点の空白を正直に指摘する必要がある：その一、ニュース側では 24 時間以内に中英文チャネルのいずれにおいても TileLang 本体のヒットがなく、検索で見つかった同名ノイズ（データベース製品の Tile.ai への改名、無関係な 2048 強化学習リポジトリ）は動態とは見なさない；その二、採用側リポジトリ（TileKernels、FlashQLA）と推論ランタイム TileRT はすべて静かであり、うち TileRT は既に5週間更新停止している；その三、学術側ではウィンドウ内に新論文なし；その四、昇騰のブロック量子化以外の國産バックエンドは依然として「通常能力の補完」が主体であり、対標ベンダーのベースラインに勝つ性能データはまだなく、昇騰の動的量子化オペレータの 0.78 倍の加速比がその一例である——精度は通過するが性能は劣後しており、後続ウィンドウで収斂するかどうかを引き続き追跡する必要がある。

付録：素材と検証説明

照合方式：すべての項目はリポジトリのコミット時間（committer 時間）を基準とし、リポジトリのプッシュ時間とコミット時間をそれぞれ照合した；本ウィンドウ内に新規追加されたコミットは一件ずつタイトルと PR 説明を読み、重要な変更については別途本文中の検証基準とベンチマークデータを読んだ；ブランチプッシュのリポジトリ（摩尔線程）については具体的なブランチまで追認し、デフォルトブランチにウィンドウ内コミットがないことを確認した；本文を取得できない第三者リンク（一部のメディアページを含む）については存在性の引用のみとし、その性質を本文中に明記した。

限界說明：その一、GitHub インターフェースは本機での収集過程で未認証レート制限（毎時 60 回）に抵触したことがあり、ウィンドウ末期のドキュメントサイト、mlir リポジトリ、TileFoundry、TileRT の検証はリポジトリコミットによるものに切り替え、カバーするリポジトリ数は若干の取捨があり、各ステップの検証方式は本文中に注記した；その二、昇騰と沐曦の実測データはコミット説明と PR 本文の自己申告によるものであり、本機に対応ハードウェアがなく、独立した再現は行っていない；その三、産業側の動態は公開報道によるものであり、ベンダーの一次公告原文は取得していない。

情報源検証表

情報源 検証結果
tile-ai 組織（28 リポジトリ） 調査期間内に 9 リポジトリでプッシュあり
コミット明細の再確認 tilelang 4 件、tilelang-ascend 6 件、TileOPs 3 件、tilelang-metax 2 件、tilelang-hygon 1 件
tilelang-musa デフォルトブランチに調査期間内のコミットなし、プッシュはバックポートブランチ v0.1.12+musa.1 に発生
tilelang-mlir-ascend 調査期間内にプッシュなし、直近は 09-16 夕方（調査期間の前境界の1時間前）
TileFoundry / DeepStack / tilescale 調査期間内にプッシュなし、直近はそれぞれ 09-15 / 09-15 / 08-25
TileRT 調査期間内にプッシュなし、直近は 2026-08-13、5週連続で更新なし
採用側リポジトリ TileKernels / FlashQLA 調査期間内にプッシュなし、直近はそれぞれ 2026-04-23 / 2026-08-26
Google News RSS（中英語の複数クエリ） 主題語とコンポーネント名は調査期間内でヒットゼロ；ヒットした TileDB 改名と 2048 強化学習リポジトリは同名ノイズであり、除外済み
産業ニュースチャネル 華為全聯接大会 2026 の現地レポート2件が利用可能、1件を収録済み
Hacker News 調査期間内に TileLang 関連の議論なし
arXiv 調査期間内に新規論文なし、主論文は既存バージョン v2

完全な情報源リスト