調査期間：過去24時間（2026-09-15 10:18 ~ 2026-09-16 10:18、北京時間） 情報源：GitHub（org: flagos-ai、53のリポジトリのpushed_at全量確認 + 単一commit search 119件をcommitter-dateで検証 + 重点リポジトリのデフォルトブランチcommit再確認 + 各リポジトリのreleases/tagsメタデータ + communityリリース一覧とリリーススケジュールraw直接取得 + 重要コミットのパッチ詳細）、Google News RSS（中国語・英語24組のクエリ語、プロキシ経由）、HN Algolia、沐曦公式サイト、観点網、新浪財経、21財経、財聯社、量子位、新華網、智源コミュニティ、CSDN FlagOSコミュニティ等（詳細は付録の情報源一覧を参照）

本期インデックス

  • 今日の重点：Torch-FL 六プラットフォームがFlagGems-firstへ転換——PPUルーティング項目が11件から435件に拡大（09-15/09-16）
    1. オープンソースプロジェクト進展（GitHub動向）
      • 1.1 2.2 RC2 第二弾：FlagGemsがv5.4.0-rc2.post2に更新、リスト項目が版替え（09-15）
      • 1.2 Open3D-PIMC 初のコード落地：単一コミットで662ファイル、コンパイル層とランタイムが揃う（09-16）
      • 1.3 Torch-FL：六つのプラットフォームが揃ってFlagGems-firstへ転換（09-15/09-16）
      • 1.4 FlagAttention：SageAttentionとGDN2が同日にマージ、昇騰版は個別実装（09-15）
      • 1.5 FlagGems 量子化オペレータ線：海光 W8A8 INT8 GEMM、摩尔線程 W8A16 FP8 RMSNorm（09-15）
      • 1.6 FlagGems KernelGen 一括マージ：20のNvidiaオペレータと崑崙芯 tle.gpu 移行（09-15/09-16）
      • 1.7 推論プラグイン線：昇騰 SparseAttnSharedKV、persistent_topkとvLLM 0.24対応（09-15/09-16）
      • 1.8 build-infra：FlagCX wheel パッケージングライン開通、6本のvLLMアプリケーションイメージtagを記録（09-15）
      • 1.9 community：2.2リリースガバナンス自動化、ステータスは関連PRから導出に変更（09-15/09-16）
      • 1.10 FlagSparse：外部ブランチを主リポジトリにマージ、昇騰の精度調整を収尾（09-15）
      • 1.11 FlagQuantum：Twinエビデンスを回路トポロジー別に格付け（09-15）
      • 1.12 その他の動向：FlagTree、flir、FlagDNN、FlagCX（09-15/09-16）
    1. 報道とエコシステム
      • 2.1 コンポーネント級検索は12回連続の平穏な調査期間：ヒットはコンポーネントではなくメンバー機関に集中（09-15~09-16）
      • 2.2 沐曦が上海人工智能実験室のATRIA Dawn PreviewのDay0対応を完了（09-15）
      • 2.3 燧原科技の科創板上場：資本側のスタンスとエコシステムポジションの二つの読み方（09-15）
      • 2.4 Open3D-PIMC リリースからコードへ：メディア側とコード側の48時間の時差（09-14~09-16）
    1. メンバー機関の深掘り
      • 3.1 清微智能：Open3D-PIMCのコード落地と3Dリコンフィギュラブル路線の合流（09-16）
      • 3.2 海光：量子化オペレータ、CIイメージ、FlagCX wheelの三線並行（09-15）
      • 3.3 摩尔線程：W8A16 FP8 RMSNormとMUSAルーティングの双方向調整（09-15）
      • 3.4 沐曦：metax rc2 再構築イメージ記録とDay0対応のナラティブ（09-15）
      • 3.5 燧原科技：S60がvLLM 0.24ラインとGCU CIパイプラインへ（09-15）
      • 3.6 天数智芯：iluvatar3.6バックエンドとFlagTree 0.6.1のバインド（09-15）
      • 3.7 崑崙芯：sumのtle.gpuへの移行とpaged-KV規約の修正（09-15）
      • 3.8 智源（主導側）：RC2ガバナンス自動化と2.2進捗の突合（09-15/09-16）
    1. まとめとトレンド観察
  • 付録：完全な情報源一覧

今日の重点：Torch-FL 六プラットフォームがFlagGems-firstへ転換——PPUルーティング項目が11件から435件に拡大

日付：2026-09-15 から 2026-09-16　出典：Torch-FL #290 PPU ルーティング、Torch-FL #276 CUDA FlagGems-first、Torch-FL オペレータサポートドキュメント

このウィンドウで最も集中的な工程アクションが発生したのは Torch-FL である。PyTorch オペレータ呼び出しを各チップバックエンドへディスパッチする対応層を担うこのリポジトリは、24 時間以内に 12 回のコミットを受け取り、6 つのプラットフォームをそろって「FlagGems 優先」へと押し出した。なかでも PPU（達摩院玄鉄）一社のルーティングテーブルの変化が最も激しく、FlagGems ルート項目は 11 件から 478 件へ拡大し、467 個のオーバーロードが cuda から flaggems へ移され、逆方向の移動は一件もなかった。その後、実行可能性の一斉調査、CI が露呈したルーティング関連失敗の 2 巡、そしてソースコードレベルの監査を経て、FlagGems 435 件 / cuda 1601 件に落ち着いた。すなわち、FlagGems がカバーする 482 個のオペレータのうち 47 個がベンダーカーネル上に残された（調査で検出されたルーティング関連失敗 33 件、mm/bmm ファミリー、five addmm オーバーロード、_conj、4 つのリフレクションパディングルート）。

この変更はさらに、ある構造的問題を塞いだ。PPU のオペレータ全体集合はもともと backends_cuda.conf から読み戻されていたが、codegen_ops.py がこのファイルを書き換えるため、PPU のオペレータ宇宙が別プラットフォームのルーティングテーブルの関数になってしまっていた。現在は csrc/aten/generated/register.inc——CUDA ラインと PPU ラインが共同でコンパイルする登録表——を読むように変更され、変更後の再生成で 9 つの conf がすべてバイト単位で一致し、純粋なトレーサビリティ置換であることが証明された。リポジトリは同時に、残された 47 個のオペレータを一つずつ BOXING_TRITON_GAPS に書き込み失敗記述を添付し、設定ファイルの SHA-256 も再現性を保証するために記録した。

残る 5 つのプラットフォームは同一方向の異なる断面である。CUDA ライン（#276、18 ファイル、+1660/-533）はジョブ内で FlagTree 0.6.2a2 と FlagGems master をインストールし FlagGems C++ オペレータのコンパイルを担うよう変更され、ワークフローのタイムアウトはこれに伴い 60 分から 120 分へ引き上げられた。DCU（#277）は FlagTree と FlagGems をデフォルトで有効化、GCU（#285）は FlagGems とベンダーフォールバックを併用、昇騰（#288）はパイプラインを FlagTree へ切り替えつつ dtype フォールバックを保持、MUSA（#286）は当初ギャップ充填と判定された 4 項目を FlagGems ルートへ再昇格させた。

この流れを FlagOS の命題に引き戻して見ると、それはいかなる単点のオペレータ登録よりも核心目標に近い。FlagOS の立論は「一つのオペレータライブラリをチップをまたいで再利用する」ことであり、この立論が成立するか否かを決めるのはまさにディスパッチ層である——どれだけのオペレータが本当に FlagGems を通り、どれだけがそっとベンダーカーネルへ落ち戻っているのか。このウィンドウが出した答えはこうだ。ベンダーカーネルは依然として大部分を引き受けている（PPU 上では 1601 対 435）が、傾向は明確であり、しかもすべての例外には名指しの理由がある。

1. オープンソースプロジェクトの進展（GitHub 動態）

ウィンドウ概観：org 内の 53 リポジトリのうち 20 個がウィンドウ内にプッシュあり。単一の commit search でウィンドウ内コミット 119 件がヒット（4 ページ、committer-date 降順）、17 リポジトリに分布：FlagGems 43、build-infra 14、community 13、Torch-FL 12、FlagSparse 11、FlagGems-vllm 5、FlagGems-sglang 4、FlagQuantum 3、FlagAttention 3、sglang-plugin-FL 2、vllm-plugin-FL 2、FlagTree 2、および flir、FlagGems-Experimental、FlagCX、Open3D-PIMC、FlagDNN が各 1。ほかに docs、release-info、FlagBLAS の 3 リポジトリがウィンドウ内にプッシュありだが、デフォルトブランチ上にウィンドウ内の新規コミットはない（タグまたはサイドブランチのプッシュに属し、うち docs と release-info はリリース成果物のサイト同期を担う）。

本ウィンドウの形態 = 「ディスパッチ層リファクタリング」+「量子化とアテンションオペレータの積み増し」の 2 ライン並行：ガバナンス側は FlagGems の 2 回目の RC2 打標と community のリリースプロジェクト自動化推進による 2.2 の収口で進み、工程側の重点は「中へオペレータを補う」から「オペレータを本当に通す」へ移行——Torch-FL の 6 プラットフォーム FlagGems-first が幹であり、FlagGems の量子化オペレータ（W8A8 / W8A16）と FlagAttention の SageAttention、GDN2 が新規の生産能力である。さらに Open3D-PIMC がウィンドウ末尾に初回のコード着地を果たし、本期唯一の新規コードベースアクションとなった。

1.1 2.2 RC2 第 2 巡：FlagGems が v5.4.0-rc2.post2 へ昇格、マニフェスト項目が版替え（09-15）

日付：2026-09-15　情報源：community コミット #110、FlagGems v5.4.0-rc2.post2

09-15 11:21、Release Manager が release(2.2-rc2): bump flaggems to v5.4.0-rc2.post2 (#110) をコミット。マニフェスト内の変更はわずか1行で、FlagGems を v5.4.0-rc2.post1 から v5.4.0-rc2.post2 へ差し替えたもの。コミットメッセージにはバージョン更新の根拠となる2件の修正——flash_attention_backward の互換性（#6253）と flagtree/3.5 ラインにおける tl.map_elementwise へのゲート付与（#6236）——が明記され、新タグはブランチヘッド 88acc0f7d を指している。タグのタイムラインを確認すると、rc2.post1 と rc2.post2 はいずれも同ブランチ上の検証スナップショットであり、マニフェスト内の残り24項目は依然として rc2.post1 を指したままである。これは 2.2 RC2 の2回目のタグ付けであり、09-28 の GA まであと13日。

1.2 Open3D-PIMC 初のコード落地：単一コミットで662ファイル、コンパイル層とランタイムが揃う（09-16）

日付：2026-09-16　情報源：Open3D-PIMC 初回コミット、プロジェクト README

09-16 09:30、org 内で 08-15 に作成されて以降ずっと空だった Open3D-PIMC リポジトリに唯一のルートコミットが届き、一度に662項目を持ち込んだ。ディレクトリ構造からこれは提案ドキュメントではなく実用的なエンジニアリングであることがうかがえる。source/raisa-inductor/ はコンパイル層（compiler.py、graph_manager.py、graph_executor.py、および passes/ 配下の通信オペレータ・融合・サブグラフの3種パスと utils/_graph_hash.py のコンパイルキャッシュキー）、runtime/rcs2/ は C++ ランタイム（engine.cpp、l1_workspace.cpp、CMake と kernel.cmake）であり、さらに demo/test_compiler.py、envsetup.sh と2枚のアーキテクチャ図を備える。README にはプロジェクトの4つの未解決課題が明確に記されている。すなわち、メモリ階層の表現力、シャーディングとトポロジの乖離、動的推論と全体グラフコンパイルの衝突、コンパイル成果物の再利用である。対応する解決策は、階層型シャーディング、3D-DRAM データ常駐、オブジェクトライフサイクル、Graph/Eager 境界を、検証可能・変換可能・最適化可能な IR セマンティクスへと昇格させることだ。これは 09-14 の中国算力大会でのオープンソース発表を受け継ぎ、「オープンソース宣言」から「コード公開」への落地を完了した。

1.3 Torch-FL：6つのプラットフォームが一斉に FlagGems-first へ転換（09-15/09-16）

日付：2026-09-15 から 2026-09-16　情報源：Torch-FL #290、Torch-FL #276、Torch-FL #285

詳細は「今日の重点」参照。補足を2点挙げる。第一に、PPU ジョブの環境再現性が根本から書き換えられた。従来はランナー pod 上の /workspace/FlagGems ホストマウント経由で FlagGems をインポートしており、pod がこのマウントを持たない場合、set_env_ppu.sh が環境準備段階で「FlagGems source is not available」により終了し、ジョブはオペレータのステップにすら到達できなかった。現在は FlagOS インデックスから FlagTree（0.6.2a2+ppu3.6）を、git から FlagGems master をインストールする方式に変更され、環境はイメージと2つのインデックスのみに依存する。第二に、mm/bmm は依然としてベンダーカーネルに固定されている。原因は FlagGems の _hygon カーネルが Triton の mm_kernel に num_ldmatrixes キーワードを渡すが、PPU 版 Triton がこれを認識しないためで、すでに FlagGems #6225 として報告済みである。

1.4 FlagAttention：SageAttention と GDN2 が同日にマージ、昇騰版は個別実装（09-15）

日付：2026-09-15　情報源：FlagAttention #43 SageAttention、FlagAttention #44 GDN2、FlagAttention #62 昇腾版

1日で2つの新版オペレータがマージされた。#43はSageAttentionのTriton実装を導入（10ファイル、+862/-7）：QKはINT8ブロック単位量子化、PVはFP16フォワード、QK量子化とアテンションフォワードの2つのカーネルはどちらも triton.experimental.tle.language を使用し、1Kから32Kのシーケンス長をカバーするベンチマークスクリプトとヘッド単位のリファレンス実装に対する精度テストを付属。#44は最適化されたGDN2オペレータ——線形アテンション方向の現在のホットスポット。#62は昇腾向けにGDN2とSageAttentionを個別実装：エントリは torch.npu.is_available() に基づいて _ascend バックエンドへ自動ルーティングされ、汎用パスはさらにこの実装を指すことで2箇所のコードドリフトを回避；昇腾ベンチマークスクリプトはAscendCオペレータと同一形状群を比較測定する。この3つを合わせて見ると、FlagAttentionは「アテンションバリアントの補完」から「最新推論モデルの構造的ホットスポットへの追随」へ移行したことがわかる。

1.5 FlagGems 量子化オペレータライン：海光 W8A8 INT8 GEMM、摩尔線程 W8A16 FP8 RMSNorm（09-15）

日付：2026-09-15　情報源：FlagGems #6185 海光 W8A8、FlagGems #6210 摩尔線程 W8A16

海光ラインは mm_w8a8_int8 と mm_w8a8_int8_out の2つの非ATen量子化行列積オペレータを新規追加（5ファイル、+871）：入力は量子化済みのINT8行列で、スカラーまたは行/列単位スケーリングのFP32 scaleとオプションのbiasを伴い、量子化自体はオペレータ外で完了する。カーネル実装の重点はINT8ドット積における長Kリダクションのオーバーフロー保護；同時に conf/operators.yaml の規範に従ってオペレータ登録を補い、stageは5.4と標記され、現在のRCブランチと整合。摩尔線程ラインはW8A16 FP8 RMSNormパスを最適化（#6210）。さらに fix: enable TLE for Hygon（#6247）で海光をTLE有効化リストに追加し、そのバックエンドがTritonの言語拡張を使用し始めたことを示す。3つを合わせて見ると、量子化（W8A8 / W8A16）が今回のオペレータ拡充の主線になりつつある。

1.6 FlagGems KernelGen 一括投入：20のNvidiaオペレータと昆仑芯 tle.gpu 移行（09-15/09-16）

日付：2026-09-15 から 2026-09-16　情報源：FlagGems #5722、FlagGems #6311 昆仑芯、FlagGems #6188 backends.yaml

KernelGenが生成したNvidiaオペレータが本調査期間で本リポジトリにまとめて投入され、概算約20個で、3類型をカバーする：線形代数系（cond、solve、eigvals、vander、multi_dot、powsumなどlinalgシリーズ）、特殊関数系（entr、チェビシェフ多項式など）、およびアテンションと学習関連系（ネイティブマルチヘッドアテンション、量子化GRU、grid_sampler 2次元サンプリング、3次元アップサンプリング逆伝播、複数箇所の擬量子化とembedding bagスパース逆伝播、バッチ正規化逆伝播リダクションなど）。KMCompilerラインはさらに unsafe_index_put（Nvidiaと昇腾）、rnn_tanh 性能最適化と _dim_arange を補完。昆仑芯側は sum と sum_dim を tle.gpu に移行し（#6311）、新たにルジャンドル多項式オペレータを追加。品質面では linalg_svd の16×16ハング（#6301）、addmv のスカラーbiasのdtype不一致（#6149）とCIコンテナのshm/ipcオプションを修正し、海光イメージを更新（#6304）；backends.yaml もiluvatarバックエンドを flagtree==0.6.1+iluvatar3.6 に更新（#6188）。

1.7 推論プラグインライン：昇騰 SparseAttnSharedKV、persistent_topk と vLLM 0.24 対応（09-15/09-16）

日付：2026-09-15 から 2026-09-16　情報源：FlagGems-vllm #792 SparseAttnSharedKV、vllm-plugin-FL #464、sglang-plugin-FL #75 Hygon DCU CI

本調査期間で単一最大のコード量は昇騰の SparseAttnSharedKV（#792、5 ファイル、+9637）によるものである。これは DeepSeek-V4 のスパースアテンション共有 KV 構造を昇騰上に Triton で実装したもので、検証形状は 6 つに固定——3 つの decode ケースは KV 長 8193、3 つの prefill ケースは Q=KV=8192、定数は 64 個の Q ヘッド、1 個の KV ヘッド、ヘッド次元 512、ページサイズ 128 に集中し、精度閾値は 2e-2、速度測定は同一デバイスの AscendC オペレータをベースラインとし（5 回ウォームアップ、20 回サンプリング）、記録のみで断言は行わない——すなわち精度を検収基準とする。同ラインではさらに昇騰 persistent_topk（segment-sort と merge の 2 経路）を補い、ベンダーの fused_moe / persistent_topk を ops/ 以下に収めると同時に、pre-commit 設定を gitcode ミラーに切り替えて国内ネットワークに適応させた。プラグイン側では 2 件のアップグレード：vllm-plugin-FL は燧原 S60 を vLLM 0.24 ラインに対応し（#464）、崑崙芯を vLLM 0.24.0 に引き上げた（#516）。sglang-plugin-FL は海光 DCU（BW1000）と燧原 GCU（S60）それぞれに CI パイプラインを構築し（#75/#88）、うち海光ラインは AMD adaptor を用いて FlagCX v0.13.0 をビルドする（DCU は HIP 系譜に属し、DTK が librccl を同梱）。e2e テストケースマトリクスは昇騰、MUSA と整合させている。FlagGems-sglang 側では上流 FlagGems のテストツールと conftest をリポジトリに内蔵した（#76）。

1.8 build-infra：FlagCX wheel パッケージライン開通、6 本の vLLM アプリケーションイメージ tag 記録（09-15）

日付：2026-09-15　情報源：build-infra #886、build-infra #895、build-infra #888

調査期間内に build-infra は 14 件のコミットで第 2 の活発なリポジトリとなり、主体は 2 つの事項である。第 1 は新規に開設した FlagCX wheel パッケージライン（#886 でビルド、検証、リリースの 3 ステップを新規追加、#896 で scm ノード幅を pin し MACA に cu-bridge の CUDA_PATH を設定、#897 で過剰なコメントを回退、#899 で vllm-plugin wheel ビルドが wheel を run artifact として保持するように変更）。うち #895 はある環境の落とし穴を記録している：torch のインストール済みヘッダファイルが gflags を強制要求する——torch/headeronly/macros/cmake_macros.h が直接 C10_USE_GFLAGS を定義するため、c10/util/Flags.h はすべてのコンシューマに対して <gflags/gflags.h> を include するが、いかなるランタイムイメージにも当該ヘッダファイルは含まれない（海光ランタイムイメージ上で /usr/include/gflags が存在しないことを実測）。海光ビルドはこれにより backend_flagcx.cpp のコンパイル時に失敗したため、ビルドイメージ内に libgflags-dev と libgoogle-glog-dev を追加インストールした。第 2 は 6 本の vLLM アプリケーションイメージ tag を記録したことで、統一して 2.1.2-0.2.2rc2.post1_gdb28502.d20260915 とし、それぞれ metax-maca3.8.1.3、metax-maca3.7.2.1、ascend-cann9.0.0、ascend-cann8.5.0 および 2 本の 910c 変体に対応する（#888 から #893）。さらに metax/ascend 0.20.2 rc2 再ビルドの changelog（#887）と崑崙芯 paged-KV 規約修正の記録（#898）を補った。

1.9 community：2.2 リリースガバナンスの自動化、ステータスは関連 PR から導出する方式に変更（09-15/09-16）

日付：2026-09-15 ～ 2026-09-16　出典：community 2.2 プロジェクト同期ワークフロー、community コミット 29a04c6e

チェックリストとタグ付け以外に、community リポジトリの本調査期間における 13 件のコミットはほぼすべて、2.2 のリリース状態を人手によるダッシュボードから自動化へ移すために使われた。新規追加された flagos-2.2-project-sync.yml は 15 分ごとに実行され、flagos2.2-rc0/rc1/rc2 ラベルが付いた issue（オープン/クローズ状態を問わない）を組織の GitHub Project #9 に同期する。デフォルトの Actions トークンも旧組織トークンも Projects 権限を欠いているため、このワークフローは project scope を持つ専用トークンを明示的に要求する。翌日のコミットは同じチェーンに沿って修正を加えた：issue の同期、関連 PR を用いたリリース状態の導出、状態と関連 PR の整合、照合の強化、人手で延期された issue の保持、アサイン済み triage issue の引き上げ、スケジュール周期の標準化、Actions スケジュールのハートビート検証、そして RC の検証ルールを記した説明の追加である。このチェーンを RC2 の 2 回のタグ付けと併せて読むと、2.2 の Go/No-Go が「人がチェックリストを見る」から「issue と PR の状態から導出する」へ移行しつつあることが分かる。これは本調査期間にチェックリストの各版が更新されるたびに、30 分以内にタグへ反映される理由でもある。

1.10 FlagSparse：外部ブランチを主リポジトリへマージ、Ascend 精度を収束（09-15）

日付：2026-09-15　出典：FlagSparse コミット一覧

FlagSparse の本調査期間における 11 件のコミットはすべて一つの外部協業ラインに由来する：主リポジトリがマージコミット方式で NCIC-AlphaSparse/main ブランチ（#60）を取り込み、内容は Ascend 精度調整（ascend accuracy refine、ascend refines）、CI の細分化（2 回の ci refine）、wrapper とドキュメントの更新、および複数回のクロスリポジトリ同期マージである。これはスパースオペレータライブラリの推進が外部チーム主導で、主リポジトリが受け皿となることを示しており、FlagAttention が org 内のメインラインで推進されるのと対照的な分業構造をなしている。

1.11 FlagQuantum：Twin 証拠を回路トポロジーで格付け（09-15）

日付：2026-09-15　出典：FlagQuantum #45、FlagQuantum #46

前調査期間の Twin API 凍結を受けて、FlagQuantum は本調査期間に 3 回コミットした：回路をまたいだ Twin 候補の比較（#44）、回路トポロジーによる Twin 証拠の格付け（#45）、隣接する連結 Twin 領域の結合（#46）。この 3 ステップを合わせると、量子プロセッサのデジタルツインの等価性判定を「単一回路の比較」から「トポロジーに沿った証拠集合の編成」へ進めるものであり、履歴シーケンス管理に続く方法論の補完にあたる。

1.12 その他の動向：FlagTree、flir、FlagDNN、FlagCX（09-15/09-16）

日付：2026-09-15 ～ 2026-09-16　出典：FlagTree #1178、FlagTree #1169、flir #75、FlagCX #599

FlagTree は 2 件：fix(hcu): allow extract_tile in the TLE whitelist（#1169）は海光向けの extract_tile を TLE ホワイトリストに加えたもので、FlagGems 側の「海光向けに TLE を有効化」と同じ方向性である；[Triton] Use triton version instead of llvm22 version（#1178）はバージョン識別の口径を統一した。同じ変更は flir（FlagTree IR、microsoft/triton-shared 由来）にも適用された（#75）。FlagDNN は Nvidia バックエンドのオペレータ実装を修正した。FlagCX の #599 は性能レポートの口径を修正した：KV 等価スループットはもはや固定のテキストボックス数値ではなく、実測のリクエストあたり KV バイト数から計算される。

2. ニュース報道とエコシステム

2.1 コンポーネント単位検索で12回連続の静穏ウィンドウ：ヒットはコンポーネントではなくメンバー機関に集中（09-15～09-16）

日付：2026-09-15 から 2026-09-16　情報源：Google News RSS

FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、Open3D-PIMC および BAAI 関連語の中英語組み合わせ計24組のクエリ（中国語17組、英語7組、when:7d と when:14d の2段階）で検索したところ、コンポーネント名のクエリはウィンドウ内で全くヒットしなかった。メンバー機関と産業用語に緩和した結果、ウィンドウ内で13件の結果が得られたが、うちエコシステムに関連するのは沐曦の Day0 対応と燧原の上場相場のみで、残りは株式市場の相場、金融記事、または無関係な内容であった。HN Algolia による FlagOS、FlagGems、FlagScale、BAAI のクエリにも有効な技術議論はなかった。これはコンポーネント単位のニュース検索で12回連続の静穏ウィンドウであり、今期の技術情報面は依然としてほぼすべてがコードリポジトリ由来で、初めて Torch-FL のディスパッチ層の変更が独立した技術ナラティブを提供した。

2.2 沐曦が上海人工智能実験室 ATRIA Dawn Preview の Day0 対応を完了（09-15）

日付：2026-09-15　情報源：沐曦公式サイト、観点網

09-14 に上海人工智能実験室が ATRIA Dawn Preview モデルをオープンソース化し、沐曦は同日、自社開発の汎用 GPU と MXMACA ソフトウェアスタックにより同モデルの Day0 対応を率先して完了したと発表した。会社側の説明では2つの累積データが示されている：2025年12月以来、37の主流フラッグシップモデルの Day0 対応を完了し、智譜、阿里千問、MiniMax、DeepSeek、階躍星辰、騰訊混元などをカバーする。MXMACA ソフトウェアスタックは40余種の AI フレームワーク、1000以上のモデルに対応し、6000以上のオープンソースプロジェクトのテストに対応し、PyTorch 2.8 の2410の GPU オペレータを完全サポートする。区別すべき点は：この対応はベンダー独自のソフトウェアスタックを通るもので、FlagOS 内の metax バックエンド（Torch-FL の metax ルーティング、FlagGems の metax バックエンド）とは並行する2つの経路である。両者を併せて読むことで、メンバー機関が「独自スタックで Day0 を争う」路線と「統一スタックを共築する」路線への二重投資を行っていることが見えてくる。

2.3 燧原科技の科創板上場：資本側の見方とエコシステム的位置づけの2つの読み方（09-15）

日付：2026-09-15　情報源：21世紀経済報道、同花順、財聯社

燧原科技が09-11に科創板へ上場して以降、関連する解釈がウィンドウ内で持続的に発酵している：発行価格142.18元、上場初日の寄り付き410元、寄り付き上昇率188.37%、場中最高475元、終値397元、上昇率179.22%、対応時価総額1708.5億元、調達額61.4億元。2023年から2025年の売上高は3.01億、7.22億、9.90億元、2026年上半期は11.20億元で前年同期比279.08%増、3年間の親会社株主帰属純損失合計は43億元超、未補填損失は44.41億元、会社側は2026年または2027年に黒字化の見込みと自己評価している。FlagOS のメンバー機関として、燧原のエコシステム側の対応する動きは相場ではなくコードである：今ウィンドウではその enflame バックエンドが FlagGems オペレータライン、vLLM 0.24 対応ライン、sglang の GCU CI に同時に現れている。資本のナラティブが答えるのは「持続的に投資できるか」であり、コードコミットが答えるのは「投資がどこに落ちるか」であり、両者ともに今期はクラウド推論を指し示している。

2.4 Open3D-PIMC のリリースからコードへ：メディア側とコード側の48時間のタイムラグ（09-14～09-16）

日付：2026-09-14 から 2026-09-16　情報源：新華網、リポジトリ初回コミット

09-14 中国算力大会で Open3D-PIMC のオープンソース化が発表された時点では、リポジトリ内にコードは存在しなかった。09-16 09:30 になってようやく唯一のルートコミットが現れ、一度に 662 のエントリ（コンパイル層、C++ ランタイム、サンプル、アーキテクチャ図）を持ち込んだ。メディア側の表現は「コードはすでにオープンソースコミュニティで公開済み」「今年第 4 四半期に世界のトップテックカンファレンスで 3D チップ算力向けの最新最適化成果を発表する」であり、コード側のタイムスタンプは公開が発表の約 44 時間後に発生したことを示している。これは矛盾を構成しないが、一つの読み方を提示する。すなわち、新世代チップ形態に向けたプロジェクトにおいて、その「リリース」はロードマップの宣言であり、実際の可用性はリポジトリのその後のコミットリズムを見る必要がある——本レポートは今後これを通常の巡回監視に組み込む。

3. メンバー企業の深掘り

3.1 清微智能：Open3D-PIMC のコード着地と 3D 再構成可能路線の合流（09-16）

日付：2026-09-16　情報源：Open3D-PIMC README、清華大学公式サイト

清微智能の今期の org 内での動きは Open3D-PIMC の初回コードコミットである。着地した内容から見ると、その技術的主張と同社の再構成可能路線は同じ線上にある。README は 3D-DRAM 積層後の核心問題を「データがどのメモリ層に住み、テンソルが Chiplet/Die/Tile 間でどのように分布し、計算と通信が正しい時点で協調スケジューリングできるか」と位置づけ、もはや単一オペレータのスループットではない。提案された解法は、階層型シャーディング、N3D データ常駐、オブジェクトライフサイクル、Graph/Eager 境界を IR に書き込み、ベンダーがプラグイン形式でコストモデル、スケジューラ、コード生成を提供できるようにし、フロントエンド、IR、ランタイム ABI の互換性を保つことである。raisa-inductor という命名と runtime/rcs2 の C++ エンジンは、着地したのが自社開発のコンパイルとランタイムスタックの対外オープンソース版であることを示している。公開情報が示すロードマップ（第 2 世代 3D 再構成可能チップがまもなく量産テープアウト、累計算力カード受注は 3 万枚超、10 余りの省・自治区で千カード級インテリジェント算力センターが稼働）と合わせると、清微の FlagOS エコシステムにおける位置づけは依然として一貫している。補完型のオペレータ貢献者にはならず、次世代チップ形態においてソフトウェア定義権を狙う。

3.2 海光：量子化オペレータ、CI イメージ、FlagCX wheel の三本並行（09-15）

日付：2026-09-15　情報源：FlagGems #6185、FlagGems #6247、build-infra #895

海光は本調査期間でエンジニアリング量が最も分散しているが最も完全な企業でもある。オペレータ側では W8A8 INT8 量子化行列積（_out 変種を含む）を追加し、海光を TLE 有効化リストに組み入れた。FlagTree 側では海光ライン向けに extract_tile のホワイトリストを開放した。CI 側ではコンテナの shm/ipc オプションを復旧しイメージを更新した。パッケージング側では、海光ビルドが backend_flagcx.cpp をコンパイルする際に gflags ヘッダファイルを欠いていたため、libgflags-dev を FlagCX の wheel ビルドイメージに追加した。さらに Torch-FL の DCU ラインも FlagTree と FlagGems をデフォルト有効化した。この 5 箇所を併読すると、海光の現在のボトルネックは「オペレータ不足」ではなく、ツールチェーンとパッケージング環境の対応にある——こうした問題は数が多く単点の価値は低いが、まさにクロスチップ可用性の実質的なハードルである。

3.3 摩尔線程：W8A16 FP8 RMSNorm と MUSA ルーティングの双方向調整（09-15）

日付：2026-09-15　情報源：FlagGems #6210、Torch-FL #286

摩尔線程の今期の 2 箇所の動きは方向が逆だが論理は一貫している。一つは FlagGems 側で W8A16 FP8 の RMSNorm パスを最適化し、既存オペレータを深掘りするものである。もう一つは Torch-FL 側で、以前「MUSA の隙間埋め」と判定された 4 つのエントリを再び FlagGems ルーティングに戻す、すなわち従来ベンダーカーネルに譲っていたオペレータを回収するものである。前者は生産能力、後者はカバレッジであり、両者を合わせると MUSA バックエンドがすでに「動く」段階を越え、ディスパッチ層の例外リストを処理し始めたことを示している。

3.4 沐曦：metax rc2 のイメージ再構築記録と Day0 対応の物語（09-15）

日付：2026-09-15　情報源：build-infra #888、build-infra #887、沐曦公式サイト

沐曦の今期の org 内での動きはリリース物に集中している。build-infra は metax-maca3.8.1.3 と metax-maca3.7.2.1 という2つのランタイム組み合わせごとにアプリケーションイメージ tag を1件ずつ記録し、さらに metax/ascend 0.20.2 rc2 再ビルドの changelog エントリを補った——2本の MACA バージョンラインが並んで計上されたことは、そのドライバスタックのサポート幅が明確に維持されていることを示す。4日前の vllm-plugin-FL の metax CI と vLLM 0.24.0 アップグレードも同じ推論スタックへの取り組みに属する。対外側は 2.2 項で述べた Day0 対応であり、独自の MXMACA スタックを辿っている。FlagOS にとってより重要なのは前の項目である。イメージ tag の計上により、metax 側のマルチチップ検収が再現可能な基準を持つことになる。

3.5 燧原科技：S60 が vLLM 0.24 ラインと GCU CI パイプラインへ（09-15）

日付：2026-09-15　情報源：vllm-plugin-FL #464、sglang-plugin-FL #88

燧原の今期2件はいずれも対応の動きである。vllm-plugin-FL は Enflame S60 を vLLM 0.24 ラインに対応し、sglang-plugin-FL は GCU（S60）向けに CI パイプラインを構築した。両者を併せて見ると、S60 の FlagOS 内での推論パスは vLLM から sglang へとカバレッジを広げており、しかも両方とも CI を伴っている——これは本調査期間の全体的なリズムと一致する。成員単位の新チップ接続はもはやオペレータのリポジトリ登録にとどまらず、同時に実行可能なエンドツーエンドパイプラインを提供する必要がある。2.3 の資本側の情報と合わせると、その研究開発投入の着地点はこの種のコミットから直接読み取ることができる。

3.6 天数智芯：iluvatar3.6 バックエンドと FlagTree 0.6.1 のバインド（09-15）

日付：2026-09-15　情報源：FlagGems #6188

天数智芯の今期の動きは1件の CI 設定コミットである。FlagGems の backends.yaml がそのバックエンドを flagtree==0.6.1+iluvatar3.6 に更新し、iluvatar バックエンドを FlagTree の指定ビルドバージョンにバインドした。単一コミットの情報量は多くないが、これは 2.2 の検収マトリクスを理解する一つの手がかりである——各ベンダーのバックエンドの可用性は実際には「FlagGems バージョン + FlagTree ビルドバリアント + ベンダードライバ」の三者構成に依存しており、こうした構成が再現性を保証するために1つずつ設定に書き込まれている。

3.7 昆仑芯：sum の tle.gpu への移行と paged-KV 規約の修正（09-15）

日付：2026-09-15　情報源：FlagGems #6311、build-infra #898、vllm-plugin-FL #516

昆仑芯の今期3件の動きは方向性が一致している。FlagGems 側は sum と sum_dim を tle.gpu パスへ移行し、special_legendre_polynomial_p オペレータを新規追加した。推論側は vllm-plugin-FL を vLLM 0.24.0 へアップグレードし、build-infra はその paged-KV 規約の修正を記録した。sum のような基礎的なリダクションオペレータが汎用実装から TLE パスへ移行したことは、昆仑芯バックエンドがもはや単なる可用性の追求ではなく「言語拡張で性能を押し上げる」段階に入ったことを意味する。

3.8 智源（主導側）：RC2 ガバナンス自動化と 2.2 進捗の突合（09-15/09-16）

日付：2026-09-15 から 2026-09-16　情報源：community コミット一覧、2.2 リリーススケジュール

牽引役の今期間の動きはすべてガバナンス面に集約された。まず FlagGems の RC2 第二回目の版差し替え（リスト一行、タグ一回、30 分以内に完了）、続いて 13 件の community コミットが 2.2 のリリース状態を同期して GitHub Project に移し、関連 PR から導出した。タイムテーブルと照合すると、現在は依然としてテスト・安定化期間中（09-01 から 09-24）であり、GA は 09-28 に設定され、卒業基準は各 FEP の実行可能な Test Plan がマルチチップマトリクス上で検収合格することである。本次ガバナンス改修の一つの細部を記録しておく価値がある。ワークフローは明示的に project スコープを持つ専用トークンを要求している。デフォルトトークンと旧組織トークンのいずれも Projects 権限を持たないためである——この種の「プロセスをコードに書き込む」変更はどのリリースノートにも現れないが、RC 期間中に 25 の項目が逐項追跡可能かどうかを決定づける。

4. 総括とトレンド観察

  • ディスパッチ層が今期の主戦場に：Torch-FL は一日で六つのプラットフォームを FlagGems-first へと推し進め、PPU は 11 のルートから 435 へ拡大し、ベンダーカーネル上に残った 47 のオペレータとその理由を逐条記録した。FlagOS の核心的約束は「一つのオペレータライブラリをチップ間で再利用する」ことであり、ディスパッチ層こそがこの約束が果たされる場所である。今期、この層に対する完全で監査可能な定量的口径が初めて現れた。
  • 量子化オペレータとアテンション変種が新增産能の両端：FlagGems 側では海光の W8A8 INT8 GEMM と摩尔線程の W8A16 FP8 RMSNorm、FlagAttention 側では SageAttention（QK INT8 ブロック単位量子化）と GDN2、昇騰側では SparseAttnSharedKV（DeepSeek-V4 スパースアテンション、ヘッド次元 512）。これらのオペレータに共通する点は、テストスイートのカバレッジではなく、現在の推論モデルの実際の構造に直接対応していることである。
  • リリースガバナンスがリストから自動化へ：RC2 の二回目のタグ付けはリスト一行を変更しただけで、直ちに new ワークフローが issue 状態と関連 PR を整合させた。Go/No-Go の根拠は「人がリストを見る」から「状態が導出可能」へと移りつつある。09-28 の GA まで残り 13 日、このチェーンが最後の一週間で安定するかどうかは注目に値する。
  • エコシステム側が「チップへの対応」から「ハードウェア形態の定義」への第二歩：Open3D-PIMC はリリース 44 時間後にコード実装を完了し、3D-DRAM 近接計算向けの階層 IR、コンパイル層、C++ ランタイムを持ち込んだ。これは 2.2 の検収範囲には入らないが、次世代チップ形態における FlagOS の位置を決定づける。
  • ニュース面は連続十二回目の平穏な期間：コンポーネントレベルの検索はゼロヒット、メンバー単位側の可視ニュースは資本市場と自社スタックの Day0 対応に集中している。技術進展の観察窓は完全にコードリポジトリに移っており、これはデイリーレポートの価値が「まとめ報道」から「コミットの解読」へと移りつつあることを意味する。

付録：情報源検証表

情報源 検証結果
GitHub org flagos-ai 53 のリポジトリの pushed_at を全量検証、20 が期間内にプッシュあり；commit search は期間内コミット 119 件をヒット、分布は 17 のリポジトリ
GitHub releases / tags FlagGems、FlagTree、FlagCX、FlagAttention、vllm-plugin-FL、FlagSparse、FlagScale、KernelGen、Torch-FL、FlagQuantum、build-infra、community の十二のリポジトリを照合；期間内の新規タグは FlagGems v5.4.0-rc2.post2；新規 GitHub Release なし
community リリースリスト 2.2 RC2 リスト 25 項目（L0〜L3 の四層）、FlagGems は rc2.post2 に版差し替え、その他は依然 rc2.post1 を指す；タイムテーブル GA は 09-28
Google News RSS（中国語 17 組） コンポーネント名検索はゼロヒット；メンバー単位と産業語で期間内結果 13 件、行情と無関係稿を除外後 2 件を保持
Google News RSS（英語 7 組） FlagOS、FlagGems、BAAI FlagOS、flagos-ai などの検索は期間内ゼロヒット
HN Algolia FlagOS、FlagGems、FlagScale、BAAI の検索に期間内有効な技術討論なし
智源社区（hub.baai.ac.cn） 直結可能、検索とトップページいずれも FlagOS 関連の期間内エントリなし
CSDN FlagOS 社区 直結可能、最新記事日付は 09-10 で停止、期間内更新なし
沐曦公式サイト / 観点網 / 新浪財経 ATRIA Dawn Preview の Day0 対応を確認（イベント 09-14、報道 09-15 11:17 は期間内）
21 財経 / 同花順 / 財聯社 / 杭州網 燧原科技の科創板上場初日データを確認（イベント 09-11、解説稿は期間内に継続）
新華網 Open3D-PIMC が中国算力大会でオープンソースリリース（09-14）、09-16 のコード実装と対照を形成

完全情報源リスト

[22] FlagGems #6149（addmv dtype の不一致を修正） — https://github.com/flagos-ai/FlagGems/pull/6149