調査期間：過去24時間（2026-09-14 10:18 ～ 2026-09-15 10:18、北京時間） 情報源：GitHub（org: flagos-ai、53 リポジトリの pushed_at 全件確認 + 単一 commit search 97 件を committer-date で検証 + per-repo commits 再確認で 1 件補完 + 各リポジトリの releases/tags メタデータ + community リポジトリの 2.2 リリース一覧とリリーススケジュール raw 直接取得 + コミットパッチ詳細）、Google News RSS（中英語 21 組のクエリ語、プロキシ経由）、HN Algolia、新華網、観点網、新浪財経、財聯社、科創板日報、環球網などの産業報道、および Tavily 検索による補足（詳細は付録の情報源一覧を参照）

本期インデックス

  • 今日の重点：FlagOS 2.2 RC2 全スタック同時タグ付け——25 項目の一覧が版を切り替え、25 個の rc2.post1 tag が 10 分以内に着地（09-14）
      1. オープンソースプロジェクトの進展（GitHub 動向）
    • 1.1 2.2 RC2 一覧コミット：25 項目が L0～L3 の四層をカバー、バージョンは一律 rc0/rc1 に整合（09-14）
    • 1.2 23 個のコンポーネントが 10 分以内に rc2.post1 を打刻：今回のリリースサイクルにおける二度目の全スタックスナップショット（09-14）
    • 1.3 初の rc2.post1 Release：FlagGems v5.4.0 と FlagSparse v0.3.0（09-14）
    • 1.4 FlagTree：AMD 分離コンパイル、XPU 修正、xpu3.6 専用タグを新規追加（09-14/09-15）
    • 1.5 FlagCX：libflagcx.so が wheel 入り、T-Head PPU バックエンドと CI が双方向で開通（09-14/09-15）
    • 1.6 FlagAttention v0.4.0：燧原、海光、沐曦、摩尔線程の四バックエンドを一度に実装（09-14）
    • 1.7 FlagGems-Experimental：海光 17 オペレータを一括登録、摩尔線程 4 個、昆侖芯 1 個（09-14）
    • 1.8 FlagGems メインライン：燧原 enflame 同期、Triton 3.5 互換と GitCode ミラー（09-14/09-15）
    • 1.9 FlagGems-vllm と推論プラグインライン：moe_sum デュアルバックエンド、MTT S5000 topk、vLLM 0.24.0（09-14/09-15）
    • 1.10 FlagQuantum：Twin API 凍結、QPU デジタルツインが履歴シーケンス管理へ移行（09-14）
    • 1.11 フレームワークとツール面：FlagScale 統一 CI、Torch-FL バックエンドルーティング整合、TE-FL 海光インターフェース（09-14/09-15）
    • 1.12 FlagGems-sglang：競技成果を一括マージ、10 個の PR が同日にメインリポジトリへ（09-14）
    • 1.13 build-infra：海光 vLLM rc2.post1 デュアルイメージ tag を記録し再検証（09-14）
    • 1.14 docs と release-info：ドキュメントラインが CICD 改修に統合、リリース物サイトを同期（09-15）
    1. 報道とエコシステム
      • 2.1 華夏芯光 Open3D-PIMC が中国算力大会でオープンソース発表：清微智能と智源が共同開発、3D 算力チップコンパイルスタックを補完（09-14）
      • 2.2 コンポーネント単位検索で 11 回連続の平穏な調査期間：核心的なヒットは智源側の報道に集中（09-14～09-15）
      • 2.3 産業側三会議ライン：服貿会、外灘大会、中国算力大会における国産算力の物語（09-09～09-14）
    1. メンバー企業の深掘り
      • 3.1 清微智能：Open3D-PIMC とリコンフィギュラブル算力 5000P の二本立ての物語（09-14）
      • 3.2 海光信息：17 オペレータから rc2.post1 イメージ再検証まで、今期間でエンジニアリング量首位（09-14）
      • 3.3 摩尔線程：アテンションバックエンド、profiler 統合と服貿会のシェア口径（09-14）
      • 3.4 沐曦：metax CI と vLLM 0.24.0、曦雲 C700 がテープアウト前夜へ（09-14）
      • 3.5 燧原科技：enflame バックエンドが引き続き登録、IPO 後の時価総額と顧客構造の物語（09-14）
      • 3.6 天数智芯：iluvatar バックエンドの命名統一、資本市場はロックアップ解除前の窓へ（09-14）
      • 3.7 昆侖芯と達摩院玄鉄（外部エコシステム関係者）：XPU タグと PPU の二線接入（09-14/09-15）
      • 3.8 智源（主導者）：RC2 ガバナンス規律と Open3D-PIMC のルール定義権に関する表現（09-14）
    1. まとめとトレンド観察
  • 付録：完全な情報源一覧

今日の重点：FlagOS 2.2 RC2 全スタック同時タグ付け——25 項目の一覧が版を切り替え、25 個の rc2.post1 tag が 10 分以内に着地

日付：2026-09-14　出典：community コミット #109（2.2 RC2 マニフェスト）、2.2 リリーススケジュール、FlagGems v5.4.0-rc2.post1

本調査期間で最も重要な出来事は、ある協調的な動きだった。09-14 10:35、community リポジトリに release/2.2/release-2.2-rc2.yaml がマージされ（251 行追加、Release Manager によるコミット）、2.2 サイクルの第 2 回候補版 RC2 マニフェストの形成が宣言された。続いて 10:45 から 10:54 までの 10 分間に、org 内の 23 のコンポーネントリポジトリが相次いで v{X}-rc2.post1 タグまたは Release を打ち、12:18 から 12:19 にかけて FlagTree の 3 つの Triton バリアントのタグが補完され、19:59 には FlagTree がさらに xpu3.6 タグを 1 つ追加した。これに vllm-plugin-FL のデュアルバージョンラインを加えると、調査期間内には合計 26 回のタグ付け動作が記録され、22 のリポジトリをカバーしている。

RC2 マニフェストは 4 層で構成される。L0 インフラ層（FlagTree の triton3.6/3.5/3.3 の 3 条目、FlagCX）、L1 計算ライブラリ層（FlagGems、FlagFFT、FlagSparse、FlagDNN、FlagBLAS、FlagTensor、FlagAudio、FlagAttention、FlagGems-vllm、FlagGems-sglang）、L2 フレームワーク層（Torch-FL、vllm-plugin-FL と vllm-plugin-fl-0.2、sglang-plugin-FL、TransformerEngine-FL、Megatron-LM-FL、FlagOS-Compressor）、L3 アプリケーション層（FlagScale、KernelGen、KernelGenBench、FlagRelease）。合計 25 条目で、すべて rc2.post1 の検証済みスナップショットを指している。

RC1 と比較すると、今回の変化の性質は「構造は不変、スナップショットの世代交代」である。モジュールのバージョン番号は rc0/rc1 と一致したままで、.postN のイテレーション位置のみが進んでいる——FlagGems は v5.4.0-rc1.post2 から v5.4.0-rc2.post1 へ、FlagCX は v0.14.0-rc1.post2 から v0.14.0-rc2.post1 へ、FlagAttention は v0.4.0 ラインに固定、FlagTree は 0.7.0rc1.post1 から 0.7.0rc2.post1 へ。マニフェストの先頭ではワークフローが実行可能なルールとして記述されている。各モジュールのベースラインブランチから rc2 統合ブランチを分岐させ、検証通過後に増分タグ（rc2.post1 → rc2.post2）を打ち、前回のタグを条目コメントの rc1 欄に記録する。ブランチ: と ベースラインブランチ: の 2 つのフィールドは manage-release.py が直接読み込むため、同一リポジトリを複数条目に分割しそれぞれ異なる上流ラインを追う場合（FlagTree、vllm-plugin-FL）、およびデフォルトブランチではなくリリースブランチから分岐させる必要がある場合（flagos-compressor）には、明示的に記載しなければならない。

スケジュールに戻して見ると、今回のタグ付けは「テスト・安定化期間（09-01 ~ 09-24）」の中盤に発生し、09-28 の 2.2 GA まで残り 14 日である。RC2 の意義は新機能の追加にはない——機能凍結はすでに 08-31 に閉じられている——むしろ、テスト期間中に蓄積された修正を、再現可能で一括取得可能なロック済みバージョンの一群として固め、マルチチップ受け入れマトリクスに統一された比較ベースラインを与えることにある。

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

ウィンドウ概要：org 内の 53 リポジトリのうち 29 個がウィンドウ内にプッシュあり。単一の commit search でウィンドウ内コミット 97 件がヒット（4 ページ、committer-date 降順）、per-repo commits の再確認でさらに 1 件（TransformerEngine-FL）を補完し、合計 98 件、17 リポジトリに分布：FlagQuantum 17、FlagGems-Experimental 20、FlagGems 12、FlagGems-sglang 10、FlagTree 6、FlagCX 5、FlagGems-vllm 5、build-infra 5、FlagAttention 4、docs 4、Torch-FL 2、sglang-plugin-FL 2、vllm-plugin-FL 2、FlagScale 1、FlagPrism 1、community 1、TransformerEngine-FL 1。ほかに Megatron-LM-FL、KernelGen、FlagBLAS、FlagSparse、FlagDNN、FlagOS-Compressor、FlagFFT、FlagTensor、KernelGenBench、FlagRelease、FlagAudio、release-info などのリポジトリもウィンドウ内にプッシュがあるが、ウィンドウ内の新規コミットはタグまたは非デフォルトブランチ上にあり（その大部分は後述の 1.2 の rc2.post1 タグ付け）。新規リポジトリなし。

本ウィンドウの形態 = 「フルスタック・スナップショットの世代交代」+「外部バックエンドの積み増し」の二本立てが同時進行：ガバナンス側は一度のマニフェストコミットと一度の十分間の集団タグ付けで、2.2 を第二回候補へと押し進めた。エンジニアリング側では海光、摩尔線程、沐曦、燧原、昆仑芯、達磨院玄鉄がオペレータ、アテンションバックエンド、通信ライブラリ、コンパイラの四面で同時に積み増し、なかでも海光の 17 オペレータの一括取り込みと FlagAttention の四社バックエンドの同日着地が、本ウィンドウで最も集中した二つのエンジニアリング量である。

1.1 2.2 RC2 マニフェストコミット：25 条目が L0~L3 の四層をカバー、バージョンは一律 rc0/rc1 に整合（09-14）

日付：2026-09-14　情報源：community #109

Release Manager は 09-14 10:35 に release/2.2/release-2.2-rc2.yaml を新規追加（+251 行）。コミット説明には「各モジュールのベースラインブランチから rc2 ブランチを切り出し、マニフェスト先頭のワークフローに従って v{X}-rc2.post1 を打つ；バージョンは rc0/rc1 と一致させ、各条目の rc1 コメントには前回検証済みの tag を記録する」とある。マニフェストは L0 インフラ、L1 計算ライブラリ、L2 フレームワーク、L3 アプリケーションの四層で構成され、計 25 条目。FlagGems、FlagGems-sglang、FlagDNN、FlagBLAS のデフォルトブランチが main ではなく master である点も注記されている。これは rc1 に続く二度目のマニフェストスナップショットであり、2.2 GA（09-28）前の唯一の中間候補でもある。

1.2 23 個のコンポーネントが 10 分以内に rc2.post1 を打刻：今回のリリースサイクルにおける二度目のフルスタック・スナップショット（09-14）

日付：2026-09-14　情報源：FlagCX v0.14.0-rc2.post1

タグ付けのリズムは高度に集中している：10:45 に FlagCX、FlagGems、FlagFFT の三家が先行；10:47 に FlagDNN、FlagBLAS；10:48 に FlagTensor、FlagSparse、FlagAudio、FlagAttention、FlagGems-vllm、FlagGems-sglang、Torch-FL の七家が連発；10:49 に vllm-plugin-FL（0.3.0 と 0.2.2 の二ライン）、sglang-plugin-FL、TransformerEngine-FL；10:51 に Megatron-LM-FL、FlagOS-Compressor；10:53 に FlagScale、KernelGen、KernelGenBench；10:54 に FlagRelease。FlagTree の triton3.5/3.6/3.3 三条目は 12:18 から 12:19 にかけて補完された。十分以内に 23 個のコンポーネントのタグ付けを完了したことは、この「マニフェスト先行、スクリプト実行」というリリース工程がすでに安定的に再利用可能であることを示している。

1.3 初の rc2.post1 Release：FlagGems v5.4.0 と FlagSparse v0.3.0（09-14）

日付：2026-09-14　情報源：FlagSparse v0.3.0-rc2.post1

26 回のタグ付けのうち、大半は tag 形式で着地し、FlagGems（v5.4.0-rc2.post1）と FlagSparse（v0.3.0-rc2.post1）のみがリリースノート付きの GitHub Release を生成し、両者はいずれも 09-14 10:45 から 10:48 の間にリリースされた。FlagGems の過去のリズムと対照すると、v5.4.0-rc0.post1（09-01）、v5.4.0-rc1.post1（09-07）、v5.4.0-rc1.post2（09-11）、v5.4.0-rc2.post1（09-14）、安定版 v5.3.6 は 09-11 で止まっており、5.4.0 の候補イテレーションが週 2 ラウンド以上の密度に達していることがわかる。

1.4 FlagTree：AMD の分離コンパイル、XPU 修正、xpu3.6 専用タグを新規追加（09-14/09-15）

日付：2026-09-14 ~ 09-15　情報源：FlagTree #1163（AMD 独立コンパイル）

FlagTree は調査期間内に 6 件のコミットと 4 つのタグを新規追加した。エンジニアリング側は 4 つのライン：第一に、[Build][AMD] Decouple amd for independent compilation v2（#1163）が AMD バックエンドを統一ビルドから分離し、独立コンパイルを可能にした；第二に、XPU ラインで XPUDriver のデバイス取得パスを修正し、cuda-graph capture が err -900 を報告する問題を解決した（#1168）；第三に、CI 側で nvidia3.6 の FlagGems ベースラインとテストタスクにリモートの再利用可能ワークフローを接続し（#1172、09-15 10:04）、あわせて USE_FLAGCX 変数をワークフローから削除した（#1167）；第四に、FlagPrism の profiler と debugger をコンパイラチェーンに統合した（#1106、摩尔線程方向）。タグ側では 3 つの rc2.post1 に加え、19:59 に 0.7.0rc2+xpu3.6 を新規追加した——これは同リポジトリのタグ体系において初めて非 Triton のアクセラレータサフィックスが登場したもので（従来は +triton3.x 形態のみ）、昆仑芯 XPU ラインがデリバリワークフローとは別に単独でタグを持つことに対応している。

1.5 FlagCX：libflagcx.so が wheel に収録、T-Head PPU バックエンドと CI が双方向で疎通（09-14/09-15）

日付：2026-09-14 ~ 09-15　情報源：FlagCX #596（PPU torch プラグインと CI）

通信ライブラリは本調査期間に 5 件のコミットがあり、2 つのグループに分けられる。デリバリ面：[UIL] Place libflagcx.so into the flagcx wheel package（#570）が共有ライブラリを wheel に同梱し、前調査期間の「ソースからの自前ビルドからインストール可能へ」という方向性を継続している；[UIL] Rename the iluvatar_corex build key to iluvatar（#583）が天数智芯のビルドキーを厂商名に統一し、バックエンド命名上の特例を削減した；ほかに dependabot によるアップグレードが 1 件（#572）。新バックエンド面：[CICD] Add T-Head PPU CI workflow（#592）でまず CI を構築し、続いて [UIL] Add PPU torch plugin support and extend PPU CI workflow（#596、09-15 00:49）で torch プラグインサポートを補いワークフローを拡張するという、2 段階の接続方法は従来の各ベンダーバックエンドと一致している。注目すべきは PPU の接続対象が達摩院玄铁（T-Head）であり、既存のメンバー単位リストには含まれず、外部エコシステムからの新規追加である点だ。

1.6 FlagAttention v0.4.0：燧原、海光、沐曦、摩尔線程の 4 バックエンドが一度に着地（09-14）

日付：2026-09-14　情報源：FlagAttention #61（mthread バックエンド）

FlagAttention は 14:29 から 14:30 の 2 分間に 4 件の同構コミットをマージし、アテンションオペレータに順に燧原（enflame、#58）、海光（hygon、#59）、沐曦（metax、#60）、摩尔線程（mthread、#61）の 4 バックエンドを追加した。4 社が同一バッチ、同一分内に同一モジュールへ入ったことは、アテンションオペレータのバックエンド接続がバッチ複製可能なテンプレートへと抽象化されたことを示している——これは同リポジトリのバージョンラインが本調査期間に v0.4.0-rc2.post1 へ跳んだことと相互に裏付けられ、アテンションオペレータが「単一プラットフォーム実装」から「マルチベンダー並行メンテナンス」段階へ移行したことを示している。

1.7 FlagGems-Experimental：海光 17 オペレータを一括登録、摩尔線程 4 個、昆仑芯 1 個（09-14）

日付：2026-09-14　出典：FlagGems-Experimental #557（Hygon ormqr）

当期間の単一リポジトリのコミット数は第1位（20件）。海光ラインは17:51から18:54の1時間で17個のオペレータを連続マージし、特殊関数（special_legendre_polynomial_p、special_hermite_polynomial_h、special_round_out）、線形代数（linalg_ldl_factor、ormqr）、数値とインデックス（norm_scalaropt_dim、masked_scale、scalar_tensor、gcd_、addmm_、as_strided_scatter、scatter_add、feature_dropout、conv_depthwise2d、beam_search_score、thnn_fused_lstm_cell）をカバーし、さらにHygonの_scaled関連修正を1件添付した。摩尔線程ラインはcholesky_inverse、linalg_ldl_solve、ormqrと線形オペレータ特化を補完し、昆仑芯ラインはmvlgamma特化を補完した（#605）。このように密集して補完する形態は、これらのオペレータが従来対応プラットフォームで欠落していたことを示しており、検収マトリクスが露呈したギャップを埋めているものである。

1.8 FlagGems メインライン：燧原 enflame 同期、Triton 3.5 互換と GitCode ミラー（09-14/09-15）

日付：2026-09-14 ~ 09-15　出典：FlagGems #6200（enflame 同期）

メインラインの12件のコミットのうち、最も記録に値する3件：一是 enflame to flagos 20260911（#6200）、燧原が自社ブランチの変更をまとめてメインラインに同期したもので、メンバー単位のブランチと上流メインラインの周期的なマージの実例である；二是 fix: add Triton 3.5 compatibility for flash_attention_backward（#6252、対応issue #6235）、アテンション逆方向オペレータの新しいTritonでの互換性を補完したもので、FlagTreeの複数Tritonバージョン並行戦略と呼応している；三是 [User Experience] pre commit config use gitcode mirror（#6231）、pre-commitの依存ソースをGitCodeミラーに切り替えたもので、国内開発者向けのインフラ適応に属する。残りは欠陥修正（fft res_out、boolean slice views、batch_norm ベンチマーク命名）とKernelGen側のオペレータ登録（Nvidia __iand__、摩尔線程 linear、昇騰 master_scatter_backward）、KernelGenテスト発見とalias_copy.out登録修正（09-15 09:19/09:20）である。

1.9 FlagGems-vllm と推論プラグインライン：moe_sum デュアルバックエンド、MTT S5000 topk、vLLM 0.24.0（09-14/09-15）

日付：2026-09-14 ~ 09-15　出典：FlagGems-vllm #758（MTT S5000 persistent_topk）

推論側の当期間の動きは「あるバックエンドを使えるようにする」という層に集中している。FlagGems-vllm：海光がmoe_sumを補完（#745）、達摩院玄鉄が同日moe_sum変体を補完（#772）、両者は同一オペレータの異なるプラットフォームでの対照実装を構成している；KMCompilerラインはtop_k_per_rowのprefill/decodeをFlagGemsスイートに切り替え、2つのベンダー阻塞欠陥を修正し、1つのMTT prefillを補完した後、摩尔線程MTT S5000用にpersistent_topkバックエンドを追加（#758、09-15 09:56）。プラグイン側：vllm-plugin-FLはmetax CIを有効化しvLLMを0.24.0に引き上げ（#488）、さらに一連の適応准入ケースを追加（#492）；sglang-plugin-FLはdispatch単体テストとプラットフォーム設定を分離し（#94）、プラグインのプリロードにベンチマークを追加（#96）。

1.10 FlagQuantum：Twin API 凍結、QPU デジタルツインが履歴シーケンス管理へ（09-14）

日付：2026-09-14　情報源：FlagQuantum #31（Twin v1 API 凍結）

コミット数が2番目に多いリポジトリ（17件）。すべてが1日以内に10:29から22:34へと進み、目的のはっきりした一方向のチェーンとなっている。まずアイデンティティ紐付きのTwin証拠を生成し（#27）、次に重複検証集約を行い（#28）、続いて検証シーケンスを記録し（#29）、#30でAPI凍結を準備、#31で正式にTwin v1 APIを凍結、その後収束を完了し（#32）、コミットを復元し（#33）、QPUデジタルツインを永続化し（#34）、さらに順にキャリブレーションドリフトを比較し（#35）、キャリブレーション履歴を構築し（#36/#37）、検証履歴を構築し（#38/#39）、履歴の延長と整列を行い（#40/#41）、候補を比較し（#42）、候補コミットを復元する（#43）。1日以内に「インターフェース凍結＋履歴シーケンス構築」の組み合わせを完成させたことは、量子方向が2.2サイクル内で初めてツインデータ管理を再現可能なプロセスにしたことを意味する。

1.11 フレームワークとツール面：FlagScale 統一 CI、Torch-FL バックエンドルーティング整合、TE-FL 海光インターフェース（09-14/09-15）

日付：2026-09-14 ~ 09-15　情報源：FlagScale #1285（クロスアクセラレータ CI 統一）

FlagScale の [CICD] Unify dependency-coupled CI across accelerator platforms（#1285、09-15 09:28）は、各アクセラレータプラットフォーム上で互いに結合した CI 依存関係を統一的に集約したもので、トレーニングフレームワーク側が「1つの変更をマルチプラットフォームで実行しなければならない」というコスト問題への対応である。Torch-FL は2件：ci: align backend routing with platform FlagGems availability（#272）はバックエンドルーティングをプラットフォーム上の FlagGems の実際の可用性と整合させ、fix: restore MUSA FlagGems routing and fall back the ops it cannot run（#275）は沐曦 MUSA の FlagGems ルーティングを復元し、実行できないオペレータにフォールバックパスを追加した——このパッチは「ルーティングは存在するがオペレータカバレッジが不完全」というのが現在のマルチチップスタックの現実的な制約であることを如実に示している。TransformerEngine-FLは1件：海光の2種類の multi-tensor scale インターフェースをサポート（#122）。FlagPrismは1件：摩尔線程に profiler と debugger のサポートを追加しドキュメントを更新（#11）。

1.12 FlagGems-sglang：コンペ成果の一括マージ、10 件の PR が同日メインリポジトリへ（09-14）

日付：2026-09-14　情報源：FlagGems-sglang #59（fused rmsnorm warp2）

11:58から13:31までの1時間半の間に、10件のPRが順にメインリポジトリへマージされた。コミッターとブランチ名はクロスチップオペレータ最適化コンペの参加タスクを明確に指し示している：competition/bmm-chunk、competition/decode-attention、competition/decode-grouped-attention、competition/embedding-lora-a、competition/mamba-layernorm-gated、competition/sgemm-lora-b、competition/fused-rmsnorm-warp2、および flagos-task19、flagos-task21-moe-sum-reduce などのタスクブランチ。コンペ成果がこのような一括形式でメインリポジトリに入ることは、このリポジトリが「コンペ成果の実装チャネル」の役割を担い始めたことを意味しており、前の調査期間には同じリポジトリで散発的なマージしかなかった。

1.13 build-infra：海光 vLLM rc2.post1 デュアルイメージ tag の記録と再検証（09-14）

日付：2026-09-14　情報源：build-infra #883（海光再検証記録）

構築側の5件のコミットはすべて海光 vLLM ラインを中心としている。まず hygon プラグインの rc2 再構築に向けて未発行の changelog を補完し（#879）、続けて2つのアプリケーションイメージ tag を連続記録した——2.1.2-0.3.0rc2.post1_gc9bbcf0.d20260914 と 2.1.2-0.2.2rc2.post1_g52949b6.d20260914（いずれも hygon-dtk26.04 に対応し、それぞれ vllm-plugin-FL の2つのバージョンラインに対応）、その後 upstream_prs フィールドをマージ待ち PR 追跡リストとして再定義し（#882）、最後に上記の rc2.post1 タグ上で完了した海光の再検証を記録した（#883）。イメージ tag とバージョンタグがペアで出現することは、各バックエンドが 2.2 納品範囲に入れるかどうかの直接的な証拠となる。

1.14 docs と release-info：ドキュメントラインを CICD 改修に統合、リリース物件サイトを同期（09-15）

日付：2026-09-15　情報源：docs #502 マージ

docs リポジトリは 09-15 09:12 から 09:28 の間に4件のコミットがあり、すべて new/flagcicd ブランチと main のマージ（#501、#502 および2回の merge）であり、ドキュメントラインは今回の CICD 改修に統合された。release-info リポジトリは調査期間内にプッシュがあったが（09-14 12:42）、デフォルトブランチとブランチ API のいずれにも調査期間内の新規コミットは見られず、既存の判定に従いリリース物件サイト/タグ同期に分類し、本文は確認不可とした。そのリポジトリ説明は「FlagOS スタックのリリース物件情報を公開するためだけのプレースホルダーサイト」である。

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

2.1 Open3D-PIMC が中国算力大会でオープンソース公開：清微智能と智源が共同開発、3D 算力チップコンパイルスタックを補完（09-14）

日付：2026-09-14　情報源：新華網「ハードウェアを骨とし、オープンソースを脈とする：Open3D-PIMC が国産算力ソフトウェアエコシステムの重要なピースを補完」

河北廊坊で開催された 2026 中国算力大会において、世界初の 3D 算力チップ向けプログラミングモデルおよびオープンソースソフトウェアフレームワーク Open3D-PIMC が正式にオープンソース公開された。北京清微智能科技と北京智源人工智能研究院が共同開発し、コードはすでにオープンソースコミュニティに公開されており、国産 AI ソフトウェアスタック衆智 FlagOS の次世代 3D 算力チップに向けた主要ソリューションの一つとして位置づけられている。智源の AI システム研究責任者である門春雷氏の判断は次のとおりである。3D チップの鍵となる技術はまさに突破しつつあり、量産チップがまもなく続々と登場する見込みであるが、対応するコンパイラが欠如すれば「先進ハードウェア、低効率ソフトウェア」という困境を招く。本プロジェクトの目標は、産業界の力を結集して 3D チップコンパイラのグローバル標準を形成することにある。報道は同時に FlagOS の全体的な説明として、すでに 20 社のチップメーカーの 30 種類以上の AI チップに対応し、GPU、NPU、GPGPU、DSA、RISC-V AI、ARM などのアーキテクチャをカバーしていることを引用している。2026 年 8 月にアリババが Qwen3.8-2.4T-A95B を発表した当日、FlagOS コミュニティは華為昇騰、沐曦、清微智能など9社のチップで対応検証を完了した。プロジェクトチームによれば、今年の第4四半期に世界のトップ科技会議で 3D チップ算力向けの最新最適化成果を発表する予定である。

2.2 コンポーネントレベル検索の11回連続の平穏な調査期間：コアなヒットは智源側の報道に集中（09-14~09-15）

日付：2026-09-14 ~ 09-15　情報源：Google News 検索（FlagOS およびコンポーネント名）

FlagOS および FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen、FlagQuantum、FlagPrism、FlagBLAS、FlagOS-Robo などのコンポーネント名をキーワードとした中英語検索（when:7d と when:14d の調査期間を含む）では、24時間以内に強く関連する中国語報道は1件のみヒットし（すなわち 2.1 の Open3D-PIMC）、英語側ではヒットがなかった。HN Algolia による FlagOS、FlagGems などの語のクエリも調査期間内に有効な技術議論はなかった。これはコンポーネントレベルニュース検索が11回連続で平穏な調査期間となったものであり、今回の調査期間の技術情報面はほぼすべてコードリポジトリに由来している。注意すべきは、メインワードが依然として金融市況記事に埋もれていることである。メンバー企業名で検索された数百件の中国語結果のうち、绝大多数は株価、ロックアップ解除、新規公開の含み益、ファンド保有銘柄に関する内容であり、タイトルの意味に基づき一括除外した。

2.3 産業側の3つの会議ライン：服貿会、外灘大会、中国算力大会における国産算力の語り（09-09~09-14）

日付：2026-09-09 ~ 09-14　情報源：観点網「摩尔線程 CFO 薛岩松：エヌビディアの中国 AI チップシェアが8%未満に低下」

調査期間内の国産算力の産業的表現は3つの会議から来ている。北京服貿会（摩尔線程のCFO薛岩松氏が、NVIDIAの中国AIチップシェアが95%から8%未満に下落し、国産アクセラレータカードのシェアが60%を突破したとの見方を示し、国家級実験室と協力して12000枚超のカードクラスタで2360億パラメータの科学大モデルの事前学習を完了し、現在は兆パラメータに取り組んでいること、また北京大学チームがS5000クラスタに基づくワールドモデルでスタンフォードのトラックランキング首位を47日超維持していることを開示）；上海外灘大会（09-09から09-12、清微智能がアントグループとのチューニング後の大モデル推論性能が10倍に跳ね上がったこと、テンセントクラウドとの戦略的協力とToken工場の布局を展示）；廊坊中国算力大会（Open3D-PIMCの初公開、およびメンバー単位の異種推論方向における複数のリリース）。3つの会議ラインに共通するナラティブは「使える段階から使いやすい段階へ」であり、FlagOS側の2.2テスト期間の作業の重心と一致している。

3. メンバー単位の深掘り

3.1 清微智能：Open3D-PIMCと再構築可能な算力5000Pの二本立てナラティブ（09-14）

日付：2026-09-14　情報源：新浪財経（環球網）「AIが対話から生産へ移行する中、清微智能は再構築可能な算力でインターネット算力の新需要を解読する」

清微は本調査期間においてGitHub側では専用のコミットはなく、動きはニュース側に集中しており、2本が並行している。1つ目は2.1のOpen3D-PIMCである。このプロジェクトは清微と智源が共同で開発したもので、清微のソフトウェア担当副社長である李彬氏は中国算力大会の基調講演で、同社の8年間の歩みを「アーキテクチャでプロセスを補い、集積で制程を超え、システムで算力を集め、オープンソースでエコシステムを創る」と総括し、全国ですでに配備済みおよび建設中の再構築可能な算力規模が5000Pを超えるとの見方を示した。2つ目は外灘大会への出展である。2025年下半期からアントグループと深くチューニングし、大モデル推論性能が10倍に跳ね上がり、2026年にはテンセントクラウドなどのインターネット顧客と戦略的協力に合意し、Token工場の布局を推進している。両者を併せて読むと、清微の現在のFlagOSエコシステムにおける役割はオペレータを補うことではなく、「次世代チップ形態のソフトウェア定義者」という方向へポジションを占めることである——3Dチップコンパイルスタックと再構築可能な算力システムは同一ナラティブの上流と下流である。

3.2 海光信息：17のオペレータからrc2.post1イメージ再検証まで、本調査期間で工程量第1位（09-14）

日付：2026-09-14　情報源：FlagGems-Experimental #568（Hygon conv_depthwise2d）

海光は本調査期間で工程量が最も大きいメンバー単位であり、4つの作業面を同時に推進している。オペレータ面（FlagGems-Experimentalの17のHygonオペレータが17:51から18:54に一括で格納）；推論面（FlagGems-vllmにmoe_sumを追加）；フレームワーク面（TransformerEngine-FLが2種類のmulti-tensor scaleインターフェースをサポート）；ビルドとデリバリ面（build-infraが2つのhygon-dtk26.04のrc2.post1アプリケーションイメージtagを記録し再検証を完了、1.13参照）。ニュース側では、海光信息が09-09の中国聯通パートナー大会で初公開した「トークン経営向けデュアルチップ加速ソリューション」（CPUをインテリジェントスケジューリングの中枢とし、DCUを加速計算エンジンとして、トークンの生産からリピート購入・拡張までの業務クローズドループを打通し、算力、相互接続、セキュリティ、ソフトウェアスタックの4次元で開放）が、調査期間内でも産業メディアによって継続的に伝えられており、算力の販売をトークン経営に換算するプロダクト化の表現である。オペレータの一括補充＋イメージ再検証＋バージョンタグの3者が揃ったことは、海光ラインがデリバリ可能な状態に入ったことを示している。

3.3 摩尔線程：アテンションバックエンド、profiler統合と服貿会のシェア見方（09-14）

日付：2026-09-14　情報源：FlagPrism #11（mthreads profiler/debugger）

摩尔線程の調査期間内の技術的動きは4つのモジュールに分布している。FlagAttentionにmthreadアテンションバックエンドを追加（#61）；FlagGemsとFlagGems-Experimentalにそれぞれ摩尔線程特化オペレータを追加（linear、cholesky_inverse、linalg_ldl_solve、ormqr）；FlagGems-vllmにMTT S5000のpersistent_topkバックエンドを追加（#758）；FlagPrismにprofilerとdebuggerサポートを追加（#11）、同時にFlagTreeにも統合された（#1106）。4つを繋げて見ると、摩尔線程がこのラウンドで補ったのは「可観測性」と「推論ホットオペレータのプラットフォーム特化」であり、単にオペレータの数を敷き詰めることではない。産業側ではすなわち2.3の服貿会のシェア見方と12000枚カードクラスタ、S5000ワールドモデルなどのデータであり、メンバー単位の中で対外的表現が最も積極的な企業である。

3.4 沐曦：metax CIとvLLM 0.24.0、曦雲C700が流片前夜に（09-14）

日付：2026-09-14　出典：vllm-plugin-FL #488（metax CI と vLLM 0.24.0）

ソフトウェア側は2件：FlagAttention が metax アテンションバックエンドを追加（#60）；vllm-plugin-FL が metax CI を有効化し vLLM を 0.24.0 に引き上げ（#488）、build-infra に記録されたバージョンラインと同期；さらに Torch-FL が MUSA の FlagGems ルーティングを復元し、実行不可能なオペレータにフォールバックを追加（#275）。このパッチの価値は「ルーティングの整合後もなおオペレータのギャップが存在する」という現実を認めた点にある。ハードウェア側では、複数メディアが 09-14 に集中して沐曦の半期業績説明会（09-07）での発言を報道した：次世代フラッグシップ GPU 曦雲 C700 はコア設計と機能検証がほぼ完了し、次段階でテープアウト、ソフトウェア適合、顧客テスト、量産導入を推進、FP4 などの低精度サポートを新たに追加、全体性能はエヌビディア H100 に対標、サプライチェーンはファウンドリ、パッケージング、大容量メモリの各环節で国産化方案を有する；前世代 C600 はすでに 2026 年 5 月に量産済みで、144GB HBM3e、FP8 演算性能約 1000TFLOPS を搭載。機関予測では C700 は 2027 年下半期に量産。

3.5 燧原科技：enflame バックエンドが繼續的にリポジトリ入り、IPO 後の時価総額と顧客構造のナラティブ（09-14）

日付：2026-09-14　出典：FlagGems #6200（enflame 同期）

技術側は2件：FlagAttention が enflame アテンションバックエンドを追加（#58）；FlagGems メインラインに燧原ブランチの一括同期をマージ（#6200、enflame to flagos 20260911）、ベンダーブランチの変更をアップストリームに統合。産業側は IPO 後の連続報道：09-14 に時価総額が 1800 億元超、上場初日の株価が 179% 急騰、調達額 9.12 億ドル、1 口当たり利益約 13 万元、公募の新規株式応募の含み益約 35.59 億元との報道；同時に疑問視する報道もあり、売上高は 2.8 倍に成長したが損失は拡大、単一顧客テンセントへの依存度は 83% に達すると指摘。FlagOS にとって記録に値するのは：燧原は本調査期間において「新バックエンドが継続的にリポジトリ入りする」側であると同時に、メンバー機関の中で資本ナラティブと経営への疑問が最も同時に集中した一社でもある。

3.6 天数智芯：iluvatar バックエンドの命名統一、資本市場はロックアップ解除前の窓口に入る（09-14）

日付：2026-09-14　出典：FlagCX #583（iluvatar ビルドキー統一）

FlagOS 内の動きは FlagCX のビルドキーを iluvatar_corex から iluvatar に改名すること（#583）で、バックエンド命名の収束に属し、同一ベンダーがツールチェーン内で2種類の識別子を持つ状況を減少させる。産業側では本調査期間に重大な技術リリースはなく、主に香港株と A 株の半導体セクターの相場記事に現れる（例：09-15 寄り付き後の半導体株上昇、関連銘柄は 3% 超上昇）。慣例により技術動向としては収録せず、記録のみとする。

3.7 崑崙芯と達摩院玄鉄（外部エコシステム側）：XPU タグと PPU 二路線での接続（09-14/09-15）

日付：2026-09-14 ~ 09-15　出典：FlagCX #592（T-Head PPU CI）

メンバー機関リストにない2社が本調査期間に同時に参与を深め、いずれも「ワークフローの提供」から「通信とオペレータ層」へとさらに一歩進んだ。崑崙芯ライン：FlagTree が XPU デバイスクエリと cuda-graph capture のエラーを修正（#1168）、さらに 0.7.0rc2+xpu3.6 タグを新規追加（初の非 Triton サフィックスのアクセラレータタグ）；オペレータ面では mvlgamma バックエンド特化を補充（FlagGems-Experimental #605）。達摩院玄鉄（T-Head）ライン：FlagCX がまず PPU CI ワークフローを追加（#592）、次に PPU torch プラグインサポートを補充しワークフローを拡張（#596、09-15 00:49）。これは通信ライブラリ層として初の PPU 接続となる；FlagGems-vllm は同日 moe_sum の T-Head 変体を補充（#772）。両社はいずれも「まず CI を接続、次にオペレータを補充、最後にリスト入り」という経路を踏襲しており、FlagOS の新チップ接続がすでに流程化していることを示す。

3.8 智源（牽頭側）：RC2 ガバナンス規律と Open3D-PIMC のルール定義権の表述（09-14）

日付：2026-09-14　出典：community 2.2 リリーススケジュール

主導側は本調査期間にリポジトリ操作を一度しか行っていないが、それはリリースチェーン全体を統制するものだった。09:35 の RC2 リストのコミット後、10 分以内に 23 のコンポーネントが一斉にタグ付けされた。リスト、スケジュール、コミット説明を併読すると、このガバナンスのいくつかの明確な制約が見えてくる——機能凍結（08-31）とリリース（09-28）の間のテスト期間はバグ修正と受け入れテストのみを受け付け、GA は「FEP の Test Plan がマルチチップマトリクス上で受け入れ合格すること」を卒業基準とし、バージョン反復は .postN のインクリメントで行いモジュールのバージョン番号は変更しない。対外的な表現について、新華網の報道は Open3D-PIMC の意義を「ルールの能動的定義」に置いている。すなわち、次世代ハードウェア向けのプログラミングモデルとオープンソースエコシステムを先に構築した者が、技術ロードマップを定義する主導権を握る。これは FlagOS が一貫して掲げる「一度の開発でマルチチップ動作」という位置づけと一致している。

四、まとめとトレンド観察

本調査期間は 2.2 リリースサイクルにおいて情報密度が最も高い一日であり、三つの層から総括できる：

  • リリース側：2.2 が RC2 に入り、フルスタックスナップショットの世代交代が完了。 リストが先行し、スクリプトが実行され、10 分以内に 23 のコンポーネントが一斉にタグ付けされ、テスト期間中に蓄積された修正が一括取得可能なロック版の集合として固定された。09-28 の GA まで残り 14 日であり、今後は rc2.postN のインクリメントのペースと Go/No-Go の結論に注目すべきである。
  • エンジニアリング側：受け入れの欠落が逐条埋められており、かつ明確なベンダー分業を伴う。 海光は 17 のオペレータを補完しイメージの再検証を完了、摩尔線程は profiler と推論ホットオペレータを追加、沐曦は vLLM 0.24.0 と metax CI を接続、燧原はベンダーブランチをメインラインにマージ、昆仑芯と達摩院玄鉄は「CI → オペレータ → リスト」の経路で接続した。2.2 のデリバリ範囲を判断する直接的な根拠は、依然として build-infra に対で現れるイメージタグとバージョンラベルである。
  • エコシステム側：「チップへの対応」から「ハードウェア形態の定義」へ。 Open3D-PIMC は清微と智源が共同でオープンソース化し、FlagOS の境界をマルチチップソフトウェアスタックから 3D 演算チップ向けのプログラミングモデルとコンパイルスタックへと押し広げ、かつ第四四半期に世界のトップテック会議で最適化成果を発表すると明言している。この種の動きの収益は当該期のオペレータ数ではなく、次世代チップの設計参考権にある。
  • 要注意項目： 第一に、FlagTree で初めて +xpu3.6 形態のアクセラレータ専用ラベルが出現したが、これが各バックエンドの標準デリバリ形態に普及するかどうか。第二に、Torch-FL が実行不能なオペレータにフォールバック経路を追加したことは、「ルーティングは整合済みだがオペレータカバレッジが不完全」が依然としてマルチチップスタックの常態的制約であることを示しており、2.2 の受け入れマトリクスがこうした欠落をカバーできるかは追跡に値する。第三に、PPU（達摩院玄鉄）と XPU（昆仑芯）の二社の外部エコシステム参画者の接続速度は明らかに通常のベンダーより速く、これが正式メンバーへの移行につながるかどうか。

限界に関する説明：本レポートの技術的事実はすべて公開コードリポジトリと公式リリース資料に由来し、うちリリースのペース、リスト構造、バージョン番号は community リポジトリのファイルを基準とする。産業側の情報は報道に由来し、会議の場でのベンダー単独の口径（チップ市場シェア、演算配備規模、モデルランキング成績など）を含み、独立した検証は行っておらず、引用時には出典を明記している。コンポーネントレベルのニュース検索は既に十一の調査期間連続で有効なヒットがなく、そのため技術面の結論は報道ではなくコードの証拠に依存している。メンバー単位に関連する数百件の検索結果のうち大多数は資本市場関連の内容であり、意味的に除外済みだが、相場記事に埋もれた少数の技術ニュースを見落としている可能性がある。

完全な情報源リスト

https://github.com/flagos-ai/FlagAttention/commit/ad0292fafc1999e7e1788a175711c9fa66db15a5

sglang-plugin-FL コミット #96（プラグインプリロードベンチマーク） — https://github.com/flagos-ai/sglang-plugin-FL/commit/2155c1e0cdb5d912f2075c9a3360d54a46daef42

光 重量級発表 Token 経営「双芯」加速ソリューション（09-09 联通パートナー大会） — https://finance.sina.com.cn/tech/roll/2026-09-09/doc-inirfivw3765495.shtml