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

情報源：GitHub tile-ai 組織のリポジトリ別調査（tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / ドキュメントサイト / ナイトミラーリポジトリ）+ マージ済み・レビュー中真値検索（マージ済み 12 件、レビュー中更新 54 件）+ 新規 issue 全件確認（4 件）+ メインブランチのコミット別確認（tilelang 5、tilelang-ascend 5、TileOPs 1、TileFoundry 1、ドキュメントサイト 5）+ リリースページと tag の確認 + サードパーティバックエンドとエコシステムリポジトリの確認（10 リポジトリ）+ Google News 中国語・英語 6 組のクエリ（プロキシ経由）+ Hacker News + arXiv。

本期インデックス

  • 本日の重点：昇騰リポジトリに5件をマージし、アルゴリズム側オペレータを补齐（GLM-5.3 kpool 圧縮、Chunk Scaled Dot KKT、W4A4 GEMM 修正、depthwise 畳み込みサンプル、性能プロファイリング skill）。メインリポジトリでは全 warp リダクションを redux.sync に切り替え、autotuner の独立設定を並列コンパイルに変更。24時間で12件をマージ、レビュー中更新54件、新規 issue 4件
    1. コアプロジェクトの進展
      • 1.1 メインリポジトリ：全 warp リダクションを redux.sync に切り替え、4つの32 lane FP32 の最大値取得が20本の shuffle から4本のハードウェアリダクションに（#3692）（10-29）
      • 1.2 メインリポジトリ：autotuner の独立 JIT 設定を並列コンパイルに変更、ロックは同一キー候補のみに保持（#3476）（10-29）
      • 1.3 メインリポジトリ：昇騰バッファビューのレイアウトとポインタ単位がエイリアスを跨いで伝播しなくなった（#3623）（10-29）
      • 1.4 メインリポジトリ：GM から L1 へのコピーと範囲外パディングを1つのスケジューリングタスクに統合し、余分な MTE2 フェンスを除去（#3543）（10-29）
      • 1.5 メインリポジトリ：CI が ROCm と Metal タスクを互換性のある PyTorch wheel に戻して固定（#3706）（10-29）
      • 1.6 新規不具合3件：パディング付き共有バッファのバッチコピーで形状不一致を報告、負スケーリング反復グラフが逆インデックスを誤コンパイル、ビュー幅が int32 でオーバーフロー（#3704 / #3705 / #3707）（10-29）
      • 1.7 レビュー中の修正3件：ビット幅を int64 に変更、CPU スカラー GEMM は対象領域のみクリア、キャッシュ無効時は2層のプロセス内キャッシュをバイパス（#3708 / #3709 / #3710）（10-29）
    1. マルチバックエンド対応（昇騰 / 海光 / 摩尔線程 / 沐曦）
      • 2.1 昇騰：GLM-5.3 疎注意力 indexer の kpool 圧縮オペレータをマージ、単一 kernel 純 Vector 路線（#1910）（10-29）
      • 2.2 昇騰：チャンクゲート付き線形注意力の Chunk Scaled Dot KKT フォワードオペレータをマージ、静的4ブロック展開、GM ワークスペース不要（#1803）（10-29）
      • 2.3 昇騰：W4A4 の int4 乗算 int4 GEMM で結果が全て誤りとなる問題の修正をマージ、根本原因は型サイズの虚偽報告と専用転置命令がサイレントに無効化されていたこと（#1731）（10-29）
      • 2.4 昇騰：depthwise_conv_2d サンプルを再提出、マニフェスト化テストチャネルに変更して並列バッチを回避（#1920）（10-29）
      • 2.5 昇騰：オペレータ性能プロファイリング skill を新規追加、msprof op 出力で最適化方針を決定（#1931）（10-29）
      • 2.6 昇騰レビュー中：NPUIR 言語層のビューとブロードキャスト修正3件（#1962 / #1960 / #1961）（10-29）
      • 2.7 昇騰レビュー中：PTO バックエンドのビット単位 XOR の符号なしバイトワークスペースビュー修正（#1959）（10-29）
      • 2.8 海光：HCU のレビュー中2件に更新あり、コミュニティに DCU 融合オペレータリポジトリが出現。摩尔線程と沐曦は調査期間内にプッシュなし（10-29）
    1. エコシステムと採用側（TileOPs / TileFoundry / TileKernels / FlashQLA / サードパーティ）
      • 3.1 TileOPs：リリースイメージをマージ、オペレータライブラリと TileFoundry が初めて同一イメージに同梱（#2793）（10-29）
      • 3.2 TileOPs レビュー中：GEMM を消費電力上限でグリッドグループと常駐ブロック数を再計算、q-b の DRAM 読み込みが 168 MB から 94 MB に削減（#2794）（10-29）
      • 3.3 TileFoundry：AMX ランタイムオペレータを39個の静的 TIR 契約に変更、破壊的変更（#279）（10-29）
      • 3.4 採用側：TileKernels と FlashQLA の main ブランチは調査期間内にプッシュなし（10-29）
      • 3.5 昇騰側に独立したコミュニティオペレータリポジトリ ops-tilelang が出現、調査期間内にプッシュあり（10-29）
      • 3.6 PTO-ISA 関連のデュアルリポジトリが活発：問題集リポジトリが PTOAS 0.70 に移行、ベンチマークリポジトリに SV2 チャンクスケーリングと列単位分析を追加（10-29）
      • 3.7 観察：T-HEAD 名義の tilelang ブランチリポジトリが調査期間内にプッシュあり、ブランチ名は PPU の行列命令レイアウトを指す（10-29）
    1. コミュニティ、チュートリアル、イベント
      • 4.1 ドキュメントサイトが組み込みリダクションの適用範囲を命令ページに記載、redux のマージと同期（10-29）
      • 4.2 開発ツールリポジトリが下流追跡抽出後の3件の仕上げを完了、上流のレビュー中ツール化変更と同方向（10-29）
      • 4.3 新規リポジトリ tilelang-knowledge が1日で4件：33件のオペレータ設計事例、出典付き知識カード20枚、最適化パターン7件（10-29）
      • 4.4 図解講座の関連リポジトリと分散レイアウト実験リポジトリを同日に新規作成（10-29）
      • 4.5 ニュース側：Google News の中国語・英語6組のクエリ、Hacker News と arXiv はいずれも調査期間内に実質的なヒットなし（10-29）
    1. トレンド観察
  • 付録、素材と検証についての説明

本日の重点

本日のマージ量は昨日の 24 件から 12 件に減少したが、構造はより集中的になっている。昇騰専用リポジトリが 5 件、メインリポジトリが 5 件、TileFoundry と TileOPs が各 1 件である。昇騰リポジトリのこの一群はすべてアルゴリズム側のオペレータであり、しかも上流モデルに直接使える類のものである。GLM-5.3-Flash 疎注意 indexer の kpool 圧縮オペレータは、次元ごとの softmax プーリング、BF16 境界、正規化 Hadamard-128 回転、E4M3 量子化を純粋な Vector カーネルに押し込み、各ブロックが 64 個の pool をカバーし、2 つのベクトルサブカーネルがそれぞれ 32 個を担当し、ホスト側の再配置はゼロで、呼び出し元の三次元レイアウトに従って直接ストライド転送を行う。E4M3 符号化は純粋な整数ビット演算で実装され（round-half-even、非正規数を含む、448 で飽和）、FP8 型に依存せず近似も行わない。Chunk Scaled Dot KKT はブロック化ゲート付き線形注意のフォワードにおける A = gate(K K^T) であり、静的 4 ブロック展開、ゼロ GM ワークスペース、ゼロホストオペレータで、L0 と L1 の 3 例の一致率はいずれも 1.0 である。

メインリポジトリの今日のテーマはコンパイルと発射層である。全 warp リダクションは redux.sync に切り替えられた。メインブランチ上の 4 つの独立した 32 レーン FP32 最大値取得は CUDA 13.1、sm_103a 上で 20 条の shuffle に展開されるが、変更後は 4 条の redux.sync.max.f32 となり shuffle を含まない。整数リダクションは SM80 以上でハードウェアリダクションを使い、FP32 の最大値・最小値取得は sm_100a、sm_100f、sm_103a、sm_103f でのみ使用可能で、狭い型（CUTLASS の FP16、BF16 を含む）は FP32 に昇格され、FP64 は依然として shuffle パスに残る。著者はエンドツーエンドの高速化を明示的に主張せず、命令レベルの対照のみを示している。autotuner の並行コンパイルは、全体を保持するコンパイルロックを分割する。各カバレッジ設定は dataclasses で独立した JITImpl を複製し、共有第 1 段階キーを持つ候補のみが直列化され、デバッグ出力の書き込みは依然として直列である。著者が示したクロスバックエンドの検証は、昇騰 1797 項、ROCm 3220 項、Metal 95 項、CUDA 5500 項である。

もう一つ記録に値する詳細がある。本日新たに起票された逆方向インデックスの誤コンパイル欠陥（#3705）は、T-HEAD 名義の tilelang ブランチリポジトリでランタイム再現を行っている。これは、既に組織的なチームがこの上流コードを自社ハードウェアスタックの基盤として追跡しており、単なる外部依存として扱っていないことを示している。

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

1.1 メインリポジトリ：全 warp リダクションを redux.sync に変更、4 つの 32 レーン FP32 最大値取得が 20 条の shuffle から 4 条のハードウェアリダクションに（#3692）

10-29 15:08 にマージ、4 ファイル +337/-35。従来の通常のクロススレッドリダクション（例：T.reduce_max）は、グループ全体が整列されたフル warp であっても shuffle ツリーに展開されていた。メインブランチ 837486a 上の 4 つの独立した 32 レーン FP32 最大値取得は sm_103a と CUDA 13.1 でコンパイルすると 20 条の shuffle、ゼロ条の redux を生成するが、変更後は 4 条の redux.sync.max.f32、ゼロ条の shuffle となる。手法は、スカラーおよびバッチ全リダクションに既存の warp_reduce ヘルパーを再利用することである。呼び出し元はスレッド幾何（warp と整列しているか、単位ストライドか、フル warp か）のみを判定し、アーキテクチャ、データ型、オペレータのディスパッチはヘルパーに委ねる。整数リダクションは SM80 以上でハードウェア redux を使い、より小さい整数は 32 ビットに昇格される。FP32 の最大値・最小値取得は sm_100a、sm_100f、sm_103a、sm_103f でのみ使用可能である。狭い浮動小数点は FP32 に昇格してからヘルパーに入り、FP64 は精度を落とさず shuffle パスに残る。サブ warp、ストライド、パックリダクション、およびサポートされないオペレータとターゲットは一律 shuffle にフォールバックし、クロス warp の共有メモリ交換とフェンスは変わらない。ついでにコンパイル失敗を 1 件修正している。カスタムの符号なし整数 reducer は、インラインディスパッチが空の型を返すために以前はコンパイルできなかったが、現在は shuffle フォールバックに落ちる。PTX 回帰は実際の命令と shuffle の不在をアサートし、ランタイムは符号付き・符号なし境界値、バッチ非ゼロクリア、NVRTC 実行、非有限値、符号付きゼロ、FP64 の正確な結果をカバーする。著者はエンドツーエンドの高速化を明示的に主張していない。既存の遺留問題も 1 件説明で指摘されている。バッチリダクションは batch=4 でスレッドあたり 2 出力、batch=8 でスレッドあたり 4 出力のとき FP16 と BF16 の失敗が存在し、メインブランチの元テンプレートでも同様に再現され、失敗は下沉段階で発生しており、本件とは無関係である。

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

1.2 メインリポジトリ：autotuner の独立 JIT 設定を並行コンパイルに変更、ロックは同一キー候補のみに保持（#3476）

10-29 16:24 にマージ、2 ファイル +54/-46。メインブランチの _make_jit_compile_func はコンパイル期間全体にわたって 1 つのロックを保持し、デフォルトのコンパイルオプションのみを使う構成も直列化されるため、フロントエンド、低下、デバイスコンパイルがすべてキューに入れられていた。修正方法は、各オーバーライド構成に対して dataclasses.replace で候補の JITImpl を構築し、バックエンド、ターゲット、出力選択、ログレベル、コンパイルフラグ、デバッグオプションを元の値に保つこと。デフォルトオプションは引き続き既存の遅延呼び出しパスを通り、そのカーネルキャッシュとオブジェクト同一性を保持する。共有される第 1 段階キー（get_tir で使われる引数バインダーが算出し、位置引数、デフォルト値、テンソル注釈付きファクトリを保持）を持つ候補のみを直列化する。デバッグファイルの共有出力は引き続きコンパイル内部で直列化され、debug_root_path、IR ダンプ設定、レイアウト可視化をオーバーライドする。受け入れデータはクロスバックエンドパイプライン上にある。昇騰タスクは 3be11be6 とメインブランチ c58a86f0 をマージし、Python 3.12.14、torch_npu 2.10.0、CANN 9.3.0 で、1797 項目のチェックが通過、AscendC サンプルは 50 例すべて通過、PTO サンプルは 44 例中 6 例スキップ。ROCm 7.2 タスクは gfx942 上で 3220 項目通過、2765 項目スキップ。Metal タスクは macOS arm64 上で 95 項目通過、5 項目スキップ。CUDA タスクは H100 PCIe、cu130 上で 5500 項目のチェックが通過、491 項目スキップ、サンプルは 76 通過 14 スキップ。CuTeDSL タスクは 75 通過 17 スキップ 2 例が予期せず通過。

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

1.3 メインリポジトリ：昇騰バッファビューのレイアウトとポインタ単位がエイリアスを跨いで伝播しなくなる（#3623）

10-29 13:17 にマージ、23 ファイル +1139/-438。T.view や T.reshape で作られた複数のバッファは同じ記憶域を共有しつつ異なるレイアウトを要求できるが、従来は共有データ変数で一律にレイアウトを解決していたため、誤った Cube マッピングや DMA アドレスが選ばれる可能性があり、古いタイル幾何はバージョンオフセットを失ったり、型付きポインタオフセットを誤った単位で解釈したりしていた。本コミットはレイアウトを個々の Buffer ビューに付着させ、レイアウト推論、フラクタルストレージ正規化、マルチバッファ実体化とコピーおよび行列積の低下を貫く。ビュー同一性はレイアウトマッピングとコンパクトな L0 間隔の適用後まで保持され、生ポインタオフセットはそれぞれの要素単位で再マッピングされる。記憶域を跨ぐエイリアスのレイアウトは伝播しなくなり、各ビューは自身の注釈、オペレータが推論したレイアウト、または通常のアドレッシングを用いる。同一のバージョン付き割り当て上で、Cube ビューは異なる MajorK と MajorMN レイアウトを使えるようになった。条件は論理ストライドが稠密、基底オフセットがゼロ、オペランド型が互換、パディング後の記憶域サイズが等しいこと。マルチバッファエイリアスは 1 つの物理スロットサイズを共有し、インデックスマッピングを伝播せずに各ビューの要素単位で換算する。ビューは既存バイトを再解釈するだけであり、書き込み側は消費側の期待する表現で書き込まなければならず、ビューを内蔵命令に渡す必要がある場合はアクセス・ポインタ・インターフェースを経由できる。

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

1.4 メインリポジトリ：GM から L1 へのコピーと越境パディングを 1 つのスケジューリングタスクに統合し、余分な MTE2 フェンスを削除（#3543）

10-29 11:39 にマージ。グローバルメモリから L1 へのコピーとその越境パディングは同じ L1 データを共に準備するが、従来はパディングが独立したスケジューリングタスクに分割されることがあり、同期挿入がコピーとパディングの間に余分な MTE2 パイプフェンスを追加していた。本コミットは各コピーとそのパディングを同一の昇騰タスクに編み込み、消費側はパディングを含む完全なデータを待つ。FP8 MX の K 末尾パディングも同様に統合され、タスク内の条件付きパディングが保持され、既存の明示的タスクスコープは変更されずネストも導入されない。従来の MX 遅延パディングキューは削除され、各オペランドのパディングは自身のコピーに直ちに続く。47 項目の集中的テストが通過し、通常の越境パディングと MX 末尾ブロックの 2 種類をカバーする。

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

1.5 メインリポジトリ：CI が ROCm と Metal タスクを互換性のある PyTorch wheel に固定（#3706）

10-29 21:38 にマージ。ROCm の CI はインデックス変数を通じて一致する PyTorch ROCm ソースを公開しているが、ワークフローレベルの「不安全な最適マッチ」ポリシーにより、より後発の PyPI 候補が依然として勝っていた。#3534 の ROCm タスクではリゾルバが PyPI の PyTorch 2.15.0（CUDA 13.2）を選択し、利用可能な 2.14.1 と ROCm 7.2 ビルドではなかった。公式はランナー上でこの 2 つの解決結果を直接再現した。同じ 2.15.0 の展開は Metal タスクも中断させた。macOS 26.6.2 の ARM64 ランナー上で、2.15.0 は Metal 2.0 を公開しないため Apple 準仮想 GPU を拒否し、同じイメージ上で前回通過したのは 2.14.1 だった。修正方法は 3 つ。設定済みの安定 ROCm バージョンに従ってバックエンド変数を設定し、uv が PyTorch を ROCm ソース上に留めつつその他の依存は最適マッチを使えるようにする。夜間 PyTorch インストールは先頭インデックスを使用するよう変更し、夜間タスクが設定済みソースから逃げられないようにする。PyTorch が HIP ビルドであり、CUDA ビルドでなく、ランナーの GPU にアクセスできることをテストスイート起動前に確認する、高速失敗の検証ステップを追加する。

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

1.6 新規欠陥3件：パディング付き共有バッファのバッチコピーで形状不一致、負スケーリング反復グラフで逆インデックスを誤コンパイル、ビュー幅が int32 でオーバーフロー（#3704 / #3705 / #3707）

3件の issue はいずれも静的チェックの境界を指摘している。その一、#3704 は、末尾次元が16アラインメントでないグローバルテンソル（例えば K=100）をパディング付き共有バッファ（BK が cdiv(K,16) 掛ける16で112）にコピーする際、このコピーがバッチコピーパスにルーティングされると、下降時に共有ブロックとグローバルブロックの形状不一致（112 対 100）を直接報告し、位置は CUDA コピーのバッチ下降箇所であると報告している。要素単位パスでのパディング付きバッファは正常であり、パディングはまさに行列積のアラインメントを満たす一般的な書き方であるため、バッチコピーと併用するあらゆるカーネルが踏む可能性がある。その二、#3705 は、フラット化バッファの簡約が負スケーリング反復グラフ上で逆インデックスを誤コンパイルすると報告しており、再現環境は v0.1.15 と T-HEAD 名義の tilelang ブランチリポジトリのソースビルドであり、報告では同時に上流メインブランチと対応する TVM リビジョンで影響を受ける分割関数が変わっていないことを確認しており、上流共通パスに属する。その三、#3707 は、ビューとリシェイプがバッファ幅を照合する際に int32 で乗算し、2の31乗を超えると回り込むと報告している：Qwen3.8 の lm_head 重みは 248320 掛ける 2560 バイトの NVFP4 で、合計 5,085,593,600 ビット、幅の積が 790,626,304 に回り込み、その後静的ビュービット数を int32 定数に変換する際にリテラル上限超過をスローする。

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

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

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

1.7 3件の修正が審査中：幅を int64 に変更、CPU スカラー GEMM は対象領域のみクリア、キャッシュ無効時は2層のプロセス内キャッシュをバイパス（#3708 / #3709 / #3710）

上記3件の欠陥と昨日のキャッシュ意味論の議題に対応し、修正は同日に審査入りした。幅の件は、静的次元の積を Python 整数による乗算に変更し、シンボリック次元を int64 に変換し、int32 を超えるリテラルを int64 定数に変換するもので、回帰用例は当該 issue のバッファ（248320 掛ける 5120 のビュー形状）を直接取り、メインブランチではエラー、修正後は通過し、シンボリック次元の同形ビューもカバーする。CPU の件は、スカラー行列積がゼロクリア時に下層バッファ全体をクリアする問題を修正する：4 掛ける 4 の出力バッファを7で初期化した後、1から3行目の列の部分領域を呼び出すと、元の実装は領域外の12要素もゼロにしてしまい、修正法は出力領域自身のオフセットと範囲のみで初期化し、回帰用例はこれに倣って全て1の2 掛ける2を書いた。キャッシュの件は、昨日記録した #3699 を修正する：カーネルキャッシュの無効化はキャッシュ状態を反転させるだけで、jit ラッパーは実際のコンパイル前にさらに2つのプロセス内キャッシュを参照するため、ブロック内の通常呼び出しは同一プロセスで先にコンパイルされたカーネルを取得してしまう；修正法は呼び出し時にキャッシュスイッチを読む（同時に環境変数による無効化もカバー）もので、無効期間中は2層のプロセス内キャッシュをスキップし、ブロック終了後に復元する。テストは修正前の1失敗4通過から5全通過に変わった。

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

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

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

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

2.1 昇騰：GLM-5.3 疎注意 indexer の kpool 圧縮オペレータがマージ、単一 kernel 純 Vector 路線（#1910）

10-29 15:41 にマージ。オペレータは各 pool（pool_size は 4）について、スコアテンソルと位置エンコーディングを加算した後、次元ごとの softmax プーリングを行い、プーリングベクトルを BF16 境界に通し、さらに正規化 Sylvester Hadamard-128 回転（128の平方根で除算）を掛け、最後に各ベクトルの FP32 二次冪絶対最大値スケーリングで E4M3 量子化を行う：E4M3 行とスケーリング因子は連続スクラッチ領域に書き込まれ、ホストアダプタがページキャッシュへ散乱する（キーキャッシュは符号なしバイトで E4M3 を担持し、スケーリングキャッシュは FP32 をその場で書き込む）。実装は単一 kernel 純 Vector 路線で、開発者モードで自動同期、自動ベクトル・行列コア統合、メモリ計画の3スイッチを開き、各ブロックは64 poolをカバーし、2つのベクトルサブコアがそれぞれ32個を独立並列処理する；ホスト側の再配置はゼロで、kernel は呼び出し元の三次元レイアウトに従って直接ストライド読み取りし、位置エンコーディングはプーリングに折り込まれる；E4M3 エンコーディングは純粋な整数ビット演算で、round-half-even、非正規数を含み、448に飽和し、FP8 型を使用せず近似もしない。

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

2.2 昇騰：チャンクゲート付き線形注意の Chunk Scaled Dot KKT 前向きオペレータがマージ、静的4ブロック展開、GM ワークスペースゼロ（#1803）

10-29 15:01 にマージ。ブロック内積のスケーリング付きドット積フォワードを追加：ブロックゲート付き線形注意のフォワード計算 A はゲート付き K と K の転置の積に等しい。単一のコンパイラ装飾カーネルとして実装し、4 つのブロックを静的に展開してオンチップ融合を行い、グローバルメモリワークスペースはゼロ、ホスト側オペレータ呼び出しもゼロ、開発者モードの 4 つのスイッチはすべてオン。テストは L0、L1、L2 と境界の 4 段階に階層化され、コマンドラインで段階を選択可能。L0 は 3 つのケース（ゲートあり、ゲートなし、小規模ゲートあり）をカバーし、精度は PyTorch CPU の FP32 ゴールドスタンダードと比較し、ハイブリッド許容誤差の二重ゲートを採用。レポートに記載された測定形状はバッチ 1、シーケンス長 32768、ヘッド 32、ヘッドあたり次元 128、ブロック 64、ゲート有効、入出力 BF16、累積 FP32。L0 と L1 の各 3 例はすべて合格、一致率 1.0000、最大絶対誤差は 0 から 0.25 の間。

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

2.3 昇騰：W4A4 の int4 乗 int4 GEMM 結果が全滅する問題の修正がマージ、根本原因は型サイズの虚偽報告と専用転置命令が黙って無効化されていたこと（#1731）

昨日もまだ審査中だったこの項目が本日 15:08 にマージ、#438 に対応。根本原因は 3 層の誤りの重積。第一に、フラクタルジオメトリが型サイズ等于 1 で導出されていたが、半バイトパック型は各要素が 4 ビットのみを占め、1 バイトに 2 要素が入る。そのため 32 バイトの C0 ブロックの正しい要素数は 32 ではなく 64 であり、すべてのコピーストライド、繰り返し回数、バイト計算がすべて 1 倍ずれ、データが L0A と L0B の中で誤った位置に積まれていた。第二に、B オペランドの転置ロードが黙って破棄されていた：汎用ロード経路は zN から nZ への変換に転置フラグを設定するが、4 ビット専用命令は転置をハードコードで無効化しこのフラグを無視するため、B は行列乗算命令が期待するレイアウトを永遠に得られない。正しい経路は転置付きの専用ロードであり、これは CANN ヘッダファイルに一切のドキュメントがなく、プローブカーネルでデバイス上実測してパラメータを逆算するしかない（1 回の繰り返しで完全なブロックを転送し、繰り返し回数は N を 64 で割った値、ソースストライドは K を 16 で切り上げてから 64 で割った値、デスティネーションギャップは 3）。しかもこのバージョンは実際には 2048 バイトブロックで動作し、汎用ドキュメントの 512 バイトフラクタル単位とは異なる。第三に、ベクトルとグローバルメモリ間のバイト数も同様に 1 要素あたり 1 バイトではなく 0.5 で計算されるべきところ、1 バイトで計算されていたため、各行のコピー長が 1 倍長くなり隣接行のデータが混入していた。計算命令自体は常に正しく、ただ忠実に誤って配置されたデータを乗算していただけであり、症状は 99.6% の不一致、出力が -501 と 627 で正しい値は 641 と 1785。レポートは同時にグローバルメモリの int4 パック規約も明記している：1 バイトに 2 つの半バイト、低半バイトが偶数要素、高半バイトが奇数要素、第 r 行は r 掛ける N 割る 2 のバイト位置から始まり、CANN 独自形式と一致する。

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

2.4 昇騰：depthwise_conv_2d サンプルを再提出、並行バッチを避けるためマニフェスト化されたテストチャネルに変更（#1920）

10-29 15:43 にマージ。これは #1915 の再提出：元のコミットがマージされた後、夜間の全量 CI が失敗し、#1919 でリバートされた。根本原因は L0 最大形状ケースが 8 路並行のレガシースクリプトバッチ下で未知のエラーを引き起こしたこと。本コミットでは当該ケースを 4 分の 1 に瘦身し、オペレータを継続的インテグレーションのオペレータテストマニフェストに登録して Pytest チャネル経由とし、他 25 の移行済みオペレータと同じ路線で、並行バッチから完全に撤退。カーネル本体は元のコミットとバイト単位で一致。オペレータ自体は fp16、fp32、bf16 および任意のカーネルサイズ、ストライド、パディング、膨張をサポートし、ストライド 1、2、4 はベクトル化領域経路へ、それ以外はスカラー内積フォールバックへ。実装はパディング＋畳み込みのデュアルカーネル＋1 対 1 の高速パス、純粋な Vector 路線で、グリッドはジオメトリに応じて適応しコア数をハードコードしない。レポートにはいくつか実測上の制約が記載されており記録に値する：パディング段階の所要時間はほぼ文の数掛ける 35 ナノ秒に等しく、バイト数には依存しないため、末尾バンドは切り詰めで終了する；共有メモリ側のコピー先オフセットが 32 バイト整列でない場合、ベクトルコアの 0x26 例外が発生する；同期は手書きのチャンピオンモデルを用い（畳み込み段は自動同期オフ）、チャネル間は深さ 1 の隣接転送と計算イベントプロトコルを用い、深さ 2 のプロトコルまたは途中で全フェンスを挿入するとデッドロックする。

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

2.5 昇騰：オペレータ性能プロファイリング skill を追加、msprof op の出力で最適化方向を決定（#1931）

10-29 17:17 にマージ。オペレータ性能プロファイリングの開発フロー資産を追加：性能最適化の前に msprof のオペレータレベルで一通り実行し、出力に基づいて次の最適化方向を判断する。著者は加算要素ごと、リダクション最小サンプル、動的量子化の 3 つのオペレータでフローが使用可能なことを検証済み。この種の資産の価値は「まず計測してから変更する」をフローに組み込むことにあり、毎回プロファイリングの口径を模索し直すことではない。

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

2.6 昇騰審査中：NPUIR 言語層の 3 件のビューとブロードキャスト修正（#1962 / #1960 / #1961）

三件が同日に審査入りし、互いに依存している。第一に、#1962 はローカル統一バッファのビュー記述子を修正する。ブリッジ層は共有データ変数からバッファを検索し、記述子が適用されていない割り当てメモリ参照を返す可能性があり、同一型のオフセット別名は割り当て領域のプレフィックスを読み、異なる型の別名は割り当てられた要素型を伴ってコピー沈下へ進み、同一型のリシェイプも誤った次元でリダクションへ入る可能性がある。修正法は統一的なビュー取得ヘルパーを導入し、同一型の非恒等ビューにはチェック付きの再解釈キャストを用い、多要素型アクセスの割り当てには単一ブロックのバイト割り当てに型付きビュー操作を加えて共通ストレージの同一性を保つ。第二に、#1960 はビューがソースオフセットを失う問題を修正する。ビューがデータ変数からバッファを再構築する際に要素オフセットを失い、オフセット別名がソース先頭要素アドレスではなく割り当てオフセットのゼロから始まっていた。修正法は同一型ではオフセットを保持し、バイト級の型変化時には要素幅で換算して整除可能を要求し、整列不可や未対応の変換は直接拒否し、ストレージやデータコピーは導入しない。第三に、#1961 は単項ベクトルブロードキャストをアクセス領域に基づいて推論するよう変更する。従来は元のバッファ形状でブロードキャスト次元を推論し、8 掛ける 8 のソースを 24 掛ける 8 のターゲットの行 8 から 16 へ書き込むと失敗していた。修正法は生成されたメモリ参照型で推論するよう変更し、アクセス区間の形状と既存の互換性チェックを保持する。三件はいずれも独立したクリーンベースライン構築とビット単位検証の説明を添えている。

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

2.7 昇騰 審査中：PTO バックエンドのビット単位 XOR における符号なしバイトワークスペースビューの修正（#1959）

10-29 16:36 に審査入りし、#1721 をクローズ。PTO バックエンドではビット単位 XOR の一時ワークスペースが、必要な二次元ビューではなく生の一次元バイト領域として命令に渡されていた。生成時に宛先側の二次元形状をワークスペースの形状情報へコピーするがスライスとしてマークしないため、符号なしバイト（ワークスペースは型再解釈を行わない）に対して一次元ブロック記述子が解析され、命令実行時に範囲外の読み書きが発生していた。ワークスペース自体はソース要素数で割り当てられた一次元領域であり、整列された二次元ブロックには容量が足りており、失敗は容量ではなく記述子にある。修正法は宛先形状を継承した後に二次元ビューを強制構築してスライスとしてマークし、テストには符号なしと符号付きバイトの複数組のカバレッジ（二次元自動テンポラリ、明示的一次元テンポラリ、一次元、整列非ゼロオフセットスライス加センチネル、符号付きバイト）を追加し、16 ビットの回帰も保持する。

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

2.8 海光：HCU は審査中 2 件に更新、コミュニティに DCU 融合オペレータリポジトリが出現；摩尔線程と沐曦は調査期間内にプッシュなし（10-29）

海光側は引き続き審査中：通常コピーの共有メモリ縦方向インターリーブ特性ブランチ（#30）と分散版（#19）はいずれも調査期間内に更新があり、メインブランチの最新コミットは依然 10-27 のバッファ区分グループ特性で止まっている。コミュニティ側では同日、DCU 方向のリポジトリが出現し、海光プラットフォームの融合オペレータと TileLang コンパイラへの変更を併せて保持しており、C++ が主体で約 15 MB、履歴コミットにはアテンションオペレータのサポートと可変長サポートが見られ、海光公式ではなく個人の実践リポジトリである。摩尔線程の適配リポジトリ（tilelang-musa）と沐曦の適配リポジトリ（tilelang-metax）は調査期間内にプッシュがなく、最新はそれぞれ 09-30 と 10-26 である。

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

出典：https://github.com/SealSoul117/TileLang_DCU_FuseCmpComm

3. エコシステムと採用側（TileOPs / TileFoundry / TileKernels / FlashQLA / サードパーティ）

3.1 TileOPs：リリースイメージがマージされ、オペレータライブラリと TileFoundry が初めて同一イメージに取り込まれる（#2793）

10-29 11:18 にマージ、9 ファイル +123/-49。ランナーイメージにリリースターゲットを追加：開発イメージの上にオペレータライブラリとスケジューラの PyPI リリース版をインストールし、両者のバージョン番号で命名する。イメージタグは tileops0.1.0 に tilefoundry0.0.3 さらに cuda13.2、torch2.13、tilelang0.1.12 の三段の環境識別子を加えたもので、コンテナイメージレジストリのオペレータライブラリリリースパス下に公開される。付属スクリプトはイメージを取得し GPU 上でスタックチェック、ベースラインチェック、パッケージングテスト、任意のベンチマークファイルを実行する。ホイールにはテストとベンチマークが含まれないため、いずれもイメージ自身のバージョンに対応するタグから取得する。ドキュメントはクイックスタートを更新し、ランナードキュメントにはビルド、検証、プッシュの手順を追記した。同時に sgl-kernel ベースラインを削除した：イメージがこれをインストールすることはなくなり、関連ベンチマークは以前からスキップされ続けていた。

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

3.2 TileOPs 審査中：GEMM が消費電力上限に基づきグリッドグループ分けと常駐ブロック数を再計算、q-b の DRAM 読み取りが 168 MB から 94 MB へ減少（#2794）

10-29 21:44 に審査通過、2 ファイル +35/-12、バックツーバック呼び出しの性能議題を引き継ぐ。変更は二箇所。第一に、A が二次キャッシュの一区画に収まり B が収まらない場合、グリッドグループ化により一つのグループが全行にまたがるため、各 B ブロックは十六行グループごとに一回ではなくメモリから一度だけ読み込まれる。DeepSeek V3 プリフィルの q-b 形状（4096×24576×1536、NT レイアウト）ではメモリ読み込みが 168 MB から 94 MB に減少した。狭いブロックの分割境界は引き続き十六行グループ制約に従い、選択は変わらない。第二に、常駐ブロック数を幅が均一な双協作グループグリッド上で、プロセッサ数ではなくブロック数・総ブロック数・プロセッサ数から切り上げの常駐数を算出するよう変更した。最も忙しいブロックはどのみち同じ数のブロックを実行する必要があり、各ウェーブでより少ない異なるパネルしか読めないためである。ピンポン、狭いブロック、混合幅グリッドは引き続きプロセッサ数を用いる。テストは H200、CUDA 13.2、PyTorch 2.13、TileLang 0.1.12 上でオペレータテストを実行し、212 項通過、24 項スキップ。

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

3.3 TileFoundry：AMX ランタイムオペレータを 39 個の静的 TIR 契約に変更、破壊的変更（#279）

10-29 15:59 にマージ、破壊的変更（コミットタイトルに感嘆符付き）。動機は AMX に明示的で型付きのオペレータ宣言を持たせ、エージェントが同一の計算記述からマッチングと評価を行えるようにすること。手法は 24 個の AMX ランタイムオペレータファミリを 39 個の静的に登録された契約バージョンとして記述し、パラメータ領域、オペランドとレイアウトパターン、副作用集合、M1 から M4 までのターゲット能力を備える。新たに Python 評価器、ゴールドスタンダードとしての原始 C シミュレータを追加し、全 39 個の静的オペレータをカバーする 59 個の代表的な原子ユースケースを補完した。高階・中階中間表現ユースケースは実際の 2、4、8、12 スレッド領域で実行し、候補の受け入れと拒否を検証する。高階候補はオペレータ内のマッチング宣言から発見され、ターゲットに対する能力推論を保持する。命名は AMX 名前空間に統一し、別名は登録エントリが保持し、登録名は統一クエリが提供する。CPU 実行はスレッドトポロジを用い、AMX レジスタ状態を私有ロジックとし、スレッド数は AMX エンジン数ではない。検証は 46 項の集中テストが通過し、57 個の原始 C 結果の比較と二項のライフサイクル検査を含む。

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

3.4 採用側：TileKernels と FlashQLA のメインブランチは調査期間内にプッシュなし（10-29）

既知の採用側二つのメインブランチはいずれも 10-14 で停止し、調査期間内に新規プッシュはなかった。深度求索のオペレータリポジトリ（2018 スター）と通義側の FlashQLA（742 スター）。本日のエコシステム側の新規シグナルは主にコミュニティ自建リポジトリからであり、この二つの内部利用者からではない。

出典：https://github.com/deepseek-ai/TileKernels

出典：https://github.com/QwenLM/FlashQLA

3.5 昇騰側に独立したコミュニティオペレータリポジトリ ops-tilelang が出現、調査期間内にプッシュあり（10-29）

当該リポジトリは 10-20 に設立され、10-29 13:06 にプッシュがあった。昇騰 NPU 向けのコミュニティ高性能オペレータリポジトリとして位置づけられ、kernel 実装、自動化テストケース、標準ワークロードと性能ベースラインを統一的に管理し、オペレータ資産を再利用可能・検証可能・持続的に進化可能にすることを目標とする。昇騰エコシステムのフォーク組織名下にあり tile-ai 組織にはないため、昇騰側のオペレータ供給が公式リポジトリからコミュニティ協作面へと一層外溢していることを示す。公式 tilelang-ascend との関係はなお不明確であり、収録時はエコシステム観察としてのみ扱い、公式の動きとは見なさない。

出典：https://github.com/Atlas-Ascend-Fork/ops-tilelang

3.6 PTO-ISA の配套二リポジトリが活発：題庫リポジトリは PTOAS 0.70 へ移行、ベンチマークリポジトリは SV2 ブロック単位スケーリングと列単位分析を追加（10-29）

PTO-ISA 組織下の二つの配套リポジトリはいずれも調査期間内にコミットがあった。題庫リポジトリは PTO のブロードキャストロードを PTOAS 0.70 へ移行し、前週は量子化スケーリング記号の明確化と題面の「答えではなく自分の解を指す」への改写を行っていた。ベンチマークリポジトリは二筆の分析コミットを追加した。SV2 のブロック単位スケーリングと列単位分析、および一つの根拠（ライブラリ内絶対最大値命令の変体カウントが 31.39、ランタイム命令スループットとルーフライン分析を付し、統一バッファ口径ではないことを明示）。これら二つのリポジトリと公式リポジトリの関係は教学と測定の配套であり、昇騰側方法論の傍証として価値がある。

出典：https://github.com/PTO-ISA/tilelang-puzzles-ascend

出典：https://github.com/PTO-ISA/tilelangGym

3.7 観察：T-HEAD 名下の tilelang ブランチリポジトリが調査期間内にプッシュあり、ブランチ名は PPU の行列命令レイアウトを指す（10-29）

T-HEAD 組織（公式サイトは開発者ポータルのドメイン）名下に tilelang のブランチリポジトリがあり、2026-09-22 に設立され、上流メインリポジトリのブランチである。13 個のブランチを公開しており、メインブランチと v0.1.11 から v0.1.14 のバージョンミラー以外に、PPU マトリックス共有レイアウト修正、PPU language パッケージ、実行時コンパイル機能、およびいくつかの欠陥修正ブランチが見られる。当該リポジトリのメインブランチの最近のコミットは 10-22 で止まっているが、リポジトリのプッシュ時間は 10-29 19:27（北京時間）に更新されている。リポジトリ内には説明ドキュメントもなく、リリース記録もないため、観察の手がかりとしてのみ扱える。すなわち、組織的なチームが TileLang を自社ハードウェアスタックの基盤としてブランチ開発を行っており、その方向性は PPU のマトリックス命令レイアウトに関連している。本日の #3705 欠陥報告はまさに当該リポジトリのソースコードでビルドして再現したものである。

出典：https://github.com/t-head/tilelang-for-sail

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

4.1 ドキュメントサイトが組み込みリダクションの適用境界を命令ページに記載、redux のマージと同期（10-29）

ドキュメントサイトの調査期間内に 5 件の自動更新があり、うち命令ページにリダクション説明が新たに追加され、本日マージされたハードウェアリダクション改造と整合している。CUDA のクロススレッドリダクションでは、warp と整列した単位スレッドストライドの満杯 warp グループを warp リダクションと同源のヘルパーに委譲し、ヘルパーは SM80 以上の整数加算、最大値、最小値、ビット演算でハードウェアリダクション命令を選択し、より小さな整数は 32 ビットに昇格する。スカラー FP32 の最大値・最小値は sm_100a、sm_100f と sm_103a、sm_103f でのみ使用され、スカラー FP16 と BF16 は FP32 に昇格する。同一ルールはより大きなリダクションの最後のセグメントとアンパックされたバッチリダクションにも適用される。サブ warp、ストライド、パック、FP64、およびサポートされない型のオペレータ組み合わせは shuffle 実装を保持し、クロス warp の共有メモリ交換とフェンスは不変である。フォールバック境界をドキュメントに記載することは、「ハードウェアリダクションをサポート」とだけ書くより利用者にとって有用である。

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

4.2 開発ツールリポジトリが下沉トラッキング抽出後の 3 件の仕上げを完了、上流の審査中ツール化変更と同方向（10-29）

独立開発ツールリポジトリは 10-20 にメインリポジトリから抽出した下沉トラッキングを完了した後、調査期間内に 3 件の仕上げを補った。トラッキング有効化時の循環インポートの回避、継続的インテグレーションを計装プラグインをサポートするバージョンへの固定、コア互換エイリアスをロードする前に TileLang を初期化することである。これは上流で審査中の「下沉トラッキングを開発ツールリポジトリに抽出する」変更と同方向であり、ツール化がもはや上流のブランチ実験にとどまらず、独立してリリース可能なパッケージを形成したことを示している。

出典：https://github.com/easy-tilelang/tilelang-devkit

4.3 新規リポジトリ tilelang-knowledge が 1 日で 4 件：33 個のオペレータ設計事例、出典付き知識カード 20 枚、最適化パターン 7 条（10-29）

当該リポジトリは 10-29 に設立され、当日の 4 件のコミットがエージェント向けの知識基盤を構成している。まずリポジトリ構造、続いて 33 個のオペレータ設計事例（各条に出典を固定）を整理し、さらに出典付きプログラミング知識カード 20 枚を補充し、最後に証拠に基づく GPU 最適化パターン 7 条をドキュメント化した。リポジトリの自己記述によると、その用途はエージェントがオペレータに直面したとき、どの経験が適用可能か、コードをどう変更すべきか、どう検証するか、失敗後にどこを探すかを判断できるようにすることである。これは TileFoundry のオペレータ契約、昇騰リポジトリのプロファイリング skill と同じ種類の試みである。すなわち「どう変更し、どう検証するか」を検索可能な資産として書き記すことである。

出典：https://github.com/qiuuuuu622/tilelang-knowledge

4.4 図解講座の配套リポジトリと分散レイアウト実験リポジトリが同日に新規作成（10-29）

2 つの個人リポジトリが同日に設立された。1 つは図解講座の配套リポジトリで、独自のシナリオとアニメーションで各知識点を徹底的に解説し、動画とともに公開すると自己記述している。もう 1 つは分散レイアウト実験リポジトリで、コミット说明は分散型 TileLang レイアウト実験への参加である。本日プッシュのあったモデル移植リポジトリと Hexagon バックエンドリポジトリ（リポジトリのプッシュ時間は 10-30 06:10 に更新、そのメインブランチの最近のコミットは依然 08-24 の依存関係アップグレード）を加えると、コミュニティの教育と方言バックエンドの 2 方向への自発的投入が続いている。

出典：https://github.com/zachshi-ai/tilelang-course

出典：https://github.com/Leewin239/tilelang-distributed-layout

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

6 組のクエリは、精確語＋2 日、中国語＋昇騰、中国語＋オペレータ、組織名＋2 日、英語＋GPU、中国語＋コンパイラ＋7 日をカバーする。中国語＋昇騰のみ 1 件を返し、それは臨床人工知能の進展に関する転載記事でオペレータ言語とは無関係であり、残りはすべて空の返却であった。Hacker News の直近 4 日間の関連ヒットはすべて調査期間外にある（最近のものは 10-02 の昇騰プログラミングスタック転載議論である）。arXiv では TileLang で検索しても新論文はない。ニュース側が連日ゼロヒットであるため、デイリーレポートの主体は引き続きリポジトリとエコシステムリポジトリを基準とする。

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

5. トレンド観察

昇騰側のリズムはすでに「バックエンドの移植」から「オペレータの補充」へと移っている。昨日記録したのは NPUIR バックエンドのメインブランチへの統合で、受け入れ基準は 504 項目の自己テストと 71 対 72 のサンプルであった。本日マージされた 5 件のうち 4 件はオペレータとサンプルであり、しかも上流モデルの需要に沿って並べられている。GLM-5.3 の indexer 圧縮、ブロックゲート付き注意機構の内積、4 ビット量子化の行列積、量子化視覚モデルの深畳み込みである。これらのオペレータに共通する点は、量子化と融合をカーネル本体に書き込んでいること（E4M3 純整数符号化、4 ビットパッキング規約、デュアルカーネル＋1 対 1 高速パス）であり、ホスト側の补救に委ねていないことである。同時に 2 件がついでにエンジニアリング基準を打ち立てている。オペレータ性能プロファイリングのプロセスへの組み込み、並行バッチに起因する不安定なテストケースをリスト化テストチャネルへ移行することである。これは、昇騰側の主要な矛盾が「コンパイルできるかどうか」から「オペレータの数値と性能を安定的に受け入れられるかどうか」へ変わりつつあることを示している。

メインリポジトリ本日の 3 件（ハードウェアリダクション、並行コンパイル、境界外コピーのグループ化）はそれぞれ命令選択、コンパイル遅延、発射品質に対応しており、いずれもコンパイラカーネルの問題であって、言語層の機能ではない。これは昨日の新規欠陥の方向性と一致する。境界外、別名、ビット幅といった静的検査の境界が一つずつ開かれつつある。本日の新規欠陥 3 件のうち 2 件（パディングバッファ付きバルクコピー、ビュー幅オーバーフロー）は実際のモデル形状でトリガーされており、TileLang の利用範囲が境界条件に遭遇する規模まで深まっていることを示している。248320×5120 の NVFP4 重み、K が 16 の整数倍でない注意ヘッド次元である。

エコシステム側で本日最も注目すべきは「fork 化」である。昇騰コミュニティに独立したオペレータリポジトリが出現し、T-HEAD 名下には PPU ブランチ付きの TileLang ブランチリポジトリがあり、PTO-ISA は問題集とベンチマークの両方をセットリポジトリ化し、さらに開発ツールリポジトリが沈み込みトラッキングを独立パッケージ化している。これらの動きに共通する前提は、TileLang を自社ハードウェアスタックの基盤として扱うことである。自社の命令セットに合わせてレイアウトを変更し、自社のテスト体系で受け入れ、自社の知識形態で経験を蓄積する必要がある。ドメイン固有言語にとって、これはスター数よりも硬い採用シグナルであるが、上流が「ブランチと上流をどう同期するか」という長期的コストに直面し始めることも意味する。本日 #3705 の欠陥は、ブランチユーザーが実際のビルドで先に遭遇したものである。

付、素材と検証説明

情報源検証表

情報源 検証結果
GitHub tile-ai 組織の各リポジトリ（tilelang / TileOPs / TileFoundry / tilelang-ascend / tilelang-mlir-ascend / tilelang-hygon / tilelang-metax / tilelang-musa / TileRT / tilescale / DeepStack / ドキュメントサイト / ナイトリーイメージリポジトリ） 調査期間内にプッシュあり：tilelang、TileOPs、TileFoundry、tilelang-ascend、tilelang-hygon、tilelang.github.io、TileOPs.github.io、TileOPs-nightly；tilelang-metax（10-26）、tilelang-musa（09-30）、TileRT、tilescale、DeepStack、tilelang-puzzles は調査期間内にメインブランチへのコミットなし
マージ真値検索（is:pr is:merged） 12 件：tilelang 5、tilelang-ascend 5、TileFoundry 1、TileOPs 1
審査中真値検索（is:pr is:open updated） 54 件。昇騰ドキュメント検証バッチ、NPUIR 3 件のビュー修正、TileOPs の GEMM スケジューリング変更を含む
新規 issue 照合 4 件：#3704、#3705、#3707 の 3 件の欠陥、残り 1 件は昇騰リポジトリの日次テストボット失敗通知
メインブランチコミットレベル検証 tilelang 5 件、tilelang-ascend 5 件、TileOPs 1 件、TileFoundry 1 件、ドキュメントサイト 5 件；tilelang と 2 リポジトリのマージ数が一致
リリースページと tag tilelang の最新は依然 v0.1.15（09-30 リリース）、調査期間内に新バージョンなし；TileOPs の最新は v0.1.0（10-27）；TileFoundry の最新は 0.0.4rc1（10-25）；tilelang-ascend の最新は v0.1.2.000（09-09）
サードパーティ・エコシステムリポジトリ 10 リポジトリを逐一照合：昇騰コミュニティオペレータリポジトリ、PTO-ISA 双リポジトリ、開発ツールリポジトリ、知識リポジトリ、図解講座リポジトリ、分散レイアウトリポジトリ、DCU 融合オペレータリポジトリ、モデル移植リポジトリ、Hexagon バックエンドリポジトリ、T-HEAD ブランチリポジトリはいずれも調査期間内にプッシュあり（Hexagon メインブランチは新規コミットなし、リポジトリのプッシュ時刻のみ更新）
採用側 TileKernels と FlashQLA のメインブランチは 10-14 で停止、調査期間内にプッシュなし
Google News（中英 6 組） 中国語で昇騰を加えた臨床人工知能の転載記事が 1 件のみ、主題と無関係のため収録せず
Hacker News 直近 4 日間の関連ヒットはすべて調査期間外
arXiv TileLang での検索に新規論文なし

完全情報源リスト

tps://github.com/tile-ai/TileOPs/pull/2793>