調査期間：2026-09-11 10:18 ～ 2026-09-14 10:18 北京時間（月曜日ウィンドウ、過去3日間、週末を含む） 情報源：GitHub（org: flagos-ai、53個のリポジトリの pushed_at + 単一コミット search 150件を committer-date で全量検証 + per-repo commits 再確認 + コミット詳細とパッチ + リポジトリツリー API）、community リポジトリ 2.2 リリースリストとタイムテーブル（raw 直取得）、Google News RSS（中国語・英語 18組の検索語、プロキシ経由）、HN Algolia、FlagOS 公式コミュニティサイト（バージョンとライブ配信リスト）、Tavily/web 検索、財聯社/証券時報/IT之家/新浪財経などの産業報道（詳細は付録）

インデックス

    1. オープンソースプロジェクト進展（GitHub 動向）
      • 1.1 2.2 RC1 リストが rc1.postN イテレーションへ：FlagGems が v5.4.0-rc1.post2 に昇格（09-11）
      • 1.2 FlagCX のデリバリー化：libflagcx が「ソース自前ビルド」から「バックエンド別 .deb パッケージ + ディストロ別 apt リポジトリ公開」へ（09-11/09-12）
      • 1.3 FlagCX カーネル面：net adaptor を6601行リファクタリング、PAL デフォルト device API バックエンドを補完（09-11/09-13）
      • 1.4 build-infra sglang ライン：昆仑芯 xre5.37.1 と天数智芯 corex4.4.0 の2本のアプリケーションラインが着地（09-12）
      • 1.5 build-infra vllm ライン：清微が 0.20.2 を開始、天数智芯 0.24.0 が統一 plugin wheel に収束（09-13）
      • 1.6 FlagTree：0.7.0rc1 以降のベンチマークとバックエンド同期——昆仑芯クラスタ +17604行、天数智芯ベンチマークが CI に参入（09-11/09-13）
      • 1.7 FlagGems：KMCompiler 昇騰代数を補完、KernelGen マルチベンダー取り込み、昆仑芯 copy ファミリーを TLE へ移行（09-11/09-14）
      • 1.8 推論・訓練プラグインライン：海光 vLLM 0.24.0 ワークフロー開始、SGLang 側で4本のコンペティションブランチをマージ（09-11/09-12）
      • 1.9 科学計算・ドメインオペレータライブラリ：海光と沐曦の2批次オペレータを集中的に補完、FlagBLAS 天数智芯 L2、FlagSparse デュアルバックエンド（09-11）
      • 1.10 FlagQuantum：vNext アーキテクチャマージ + 0.2.0 リリース成果物検証 + QPU デジタルツイン（09-11/09-13）
      • 1.11 訓練フレームワーク・ツール面：Megatron-LM-FL が CUDA ハード依存を剥離、FlagScale/FlagPrism/TransformerEngine-FL がそれぞれ推進（09-11/09-14）
    1. ニュース報道とエコシステム
      • 2.1 コンポーネントレベル検索は10回連続の平穏ウィンドウ：技術情報面はすべてコードリポジトリ由来（09-11～09-14）
      • 2.2 産業側の3件事：移動雲ヘテロジニアス推論システム発表、燧原の上場初日終了、沐曦のロック解除ウィンドウが接近（09-11～09-13）
      • 2.3 コミュニティ活動とコンペティション：SGLang クロスチップオペレータ最適化コンテストとオペレータバウンティコンテストの共有会、コンペティション成果がメインリポジトリへ流入開始（09-11～09-12）
    1. メンバー企業深掘り
      • 3.1 燧原科技：科創板の鐘鳴らしで「国産 GPU 四小龍」の資本化が完了、技術面でも enflame デバイス対応を並行修正（09-11）
      • 3.2 天数智芯：移動雲ヘテロジニアス推論システムに参入、同時に FlagOS 内で5本の作業面を並行（09-11～09-13）
      • 3.3 清微智能：vLLM 0.20.2 アプリケーションラインを開始、エンドツーエンド検証とイメージ tag をクローズドループ化（09-13）
      • 3.4 海光信息：通信ライブラリ deb バックエンドを開通、vLLM ワークフロー開始、オペレータ一括補完の三線が同時始動（09-11/09-12）
      • 3.5 摩尔線程と沐曦：生成オペレータとバックエンドオペレータの2批次が着地、産業側の資本リズムは分化（09-11～09-13）
      • 3.6 昆仑芯（外部エコシステム企業）：コンパイラ側は大幅同期、ただし通信ライブラリは「デリバリー不可」と記録（09-11/09-12）
      • 3.7 智源（主導企業）：2.2 テスト期間の規律と RC1 リスト管理、GA は 09-28 に確定（09-11）
    1. まとめ
  • 付録：完全な情報源リスト

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

ウィンドウ概要：org 内の 53 リポジトリのうち 21 個がウィンドウ内でプッシュあり。commit search で 150 件のウィンドウ内コミットがヒット（5 ページ全量、committer-date 降順）。per-repo commits による再確認でさらに 23 件を補完し、合計 173 件、18 リポジトリに分布：FlagGems-Experimental 54、build-infra 33、FlagGems 21、FlagQuantum 15、FlagCX 7、FlagGems-vllm 6、Megatron-LM-FL 5、FlagTree 4、FlagBLAS 4、FlagGems-sglang 4、FlagDNN 4、FlagSparse 10（うち 8 件は per-repo 再確認由来）、FlagScale 1、FlagPrism 1、vllm-plugin-FL 1、TransformerEngine-FL 1、FlagOS-Compressor 1、community 1。また sglang-plugin-FL、docs、release-info の 3 リポジトリは pushed_at がウィンドウ内に落ちているが、デフォルトブランチおよびブランチ API の再確認ではいずれもウィンドウ内の新規コミットなし（ブランチまたはタグのプッシュに属する）。新規リポジトリなし、新規 GitHub Release エントリなし。

本ウィンドウの形態 = RC テスト期の「デリバリー面の成型 + 外部バックエンドの追加」二本立て：ガバナンス側は 2.2 RC1 リストを第 2 ラウンド検証へ進めた（flagems が rc1.post2 に昇格）；デリバリー側で最も重いラインは FlagCX の .deb パッケージングと apt リポジトリ公開が完全に通ったこと（「ユーザーが自分でベンダー SDK に対してコンパイルする」から apt-get install へ）；コンパイラとオペレータ側では、昆仑芯、天数智芯、清微、海光の 4 社がそれぞれのアプリケーションライン、ベンチマークライン、オペレータ面を同時に前進させた。前ウィンドウで予測した「2.2 GA 前の rc1.postN 増分リズム」は本ウィンドウで実現し、同時に初めて「デリバリー不可」と明示的に記録されたバックエンド（昆仑芯通信ライブラリ）が現れ、エンジニアリングの境界が単に押し進められるだけでなく書き分けられ始めた。

1.1 2.2 RC1 リストが rc1.postN 反復へ：FlagGems が v5.4.0-rc1.post2 に昇格（09-11）

情報源：community #108（09-11 11:45）（リストファイル release/2.2/release-2.2-rc1.yaml のウィンドウ内唯一の変更）

  • 第2回検証の反映：チェックリスト内の flaggems 項目が v5.4.0-rc1.post1 から v5.4.0-rc1.post2 に更新され、tag は rc1 ブランチの先頭 270bebe1 を指し、post1 以降に累計4件の修正が入った――FlagTune の Mul cost model のロールバック、天数智芯の randperm/sort 修正、index int64 オフセットオーバーフローの修正、欠落していた DSA __init__.py のパッケージング修正。
  • RC1 チェックリストの現状（25 コンポーネントのスナップショット）：L0 層は FlagTree の3ライン 0.7.0rc1.post1+triton3.3/3.5/3.6、FlagCX v0.14.0-rc1.post1；オペレータ・ドメインライブラリは FlagGems v5.4.0-rc1.post2、FlagGems-vllm v0.2.0-rc1.post1、FlagGems-sglang v0.1.0-rc1.post1、FlagAttention v0.4.0-rc1.post1、FlagFFT v0.2.0-rc1.post1、FlagSparse v0.3.0-rc1.post1、FlagBLAS/FlagDNN/FlagTensor/FlagAudio はいずれも v0.3.0-rc1.post1；フレームワーク接続は vLLM-plugin-FL v0.3.0-rc1.post1（別途 0.2 ライン v0.2.2-rc1.post1）、SGLang-plugin-FL v0.2.0-rc1.post1、Torch-FL v0.2.0-rc1.post1、TransformerEngine-FL / Megatron-LM-FL v0.3.0-rc1.post1；トレーニング・ツールは FlagScale v2.1.0-rc1.post1、KernelGen v2.2.0-rc1.post1、KernelGenBench v0.2.0-rc1.post1、FlagRelease v0.3.0-rc1.post1、FlagOS-Compressor v0.1.0-rc1.post1。
  • スケジュールの基準：2.2 サイクルは機能凍結 08-31 → テスト・安定化期間 09-01 から 09-24（bug 修正のみ受け入れ、新機能は入れない）→ GA 09-28；卒業基準では各 FEP の Test Plan（コマンド + 環境 + 期待結果、マルチチップ対応）がテスト期間内に検収通過することを要求し、未達部分は個別に検収 issue を立てる。

解釈：チェックリストの 25 件のスナップショットと「rc1.postN のインクリメント」メカニズムを合わせると一つのことが浮かび上がる――2.2 のリリース面はもはや機能リストによって定義されず、「どの検証ラウンドを通過したか」によって定義される。windows 内で唯一のチェックリスト変更は FlagGems を post2 に押し上げることであり、しかも4件の修正はすべて数値・パッケージング系の欠陥（cost model のロールバック、randperm ソート、int64 オフセット、サブパッケージ欠落）である。これこそテスト期間の規律の直接的な投影であり、凍結後はバージョン番号が修正によってのみ進み、機能によって進むことはない。

1.2 FlagCX のデリバリー化：libflagcx が「ソースからの自前ビルド」から「バックエンド別 .deb ビルド + ディストリビューション別 apt リポジトリ公開」へ（09-11/09-12）

情報源：build-infra #847（09-11 18:02）、#849（09-11 18:50）、#851（09-11 19:18）、#853（09-11 21:37）、#854（09-11 22:00）、#855（09-11 22:06）、#856（09-12 11:20）、#865（09-12 17:20）、#866（09-12 18:25）、#868（09-12 21:08）

  • なぜパッケージ化するのか（#847、+2449 行）：コミットメッセージには、FlagCX はソース形態で配布されるため、ダウンストリームのユーザーは自分のベンダー SDK に対してコンパイルしないと何もリンクできないと明記されている。ベンダー自身の base イメージ内で .deb をビルドすれば、soname、-dev ヘッダーファイル、glibc の下限をすべてビルド時に固定でき、ユーザー側は「パッケージをインストールする」の一手間だけになる。実装上は backends.yaml がパッケージ化の事実（make フラグ、apt 依存、ベンダー SDK の存在を証明する assert）を担い、deb-config.py と generate_matrix.py --runtime を統合し、--check が両者のドリフトを警告する。ビルドは base/<backend> 内で固定 ref により FlagCX ツリーをクローンし、SONAME を正規化して rpath を剥離し、ランタイムライブラリとヘッダーファイルを分割パッケージ化する。verify 段階はファイルのインストールのみで——base イメージ内で解決可能かつロード可能であることを証明し、クリーンな Ubuntu 上で Depends がベンダー SDK をユーザーのマシンに引き込まないことを証明する。
  • apt リポジトリへの公開（#851）：公開は dispatch により任意（publish はデフォルト false）で、ビルドに使用した Ubuntu バージョン名のリポジトリ（flagos-apt-ubuntu24.04 / flagos-apt-ubuntu22.04）に格納され、arch はアドレスの一部とはならず apt 自身が振り分ける。公開ステップは後置の publisher ではなく verify ジョブ内に置かれ、その理由は「ユーザーの apt-get install 経路に至るファイルは、まさに検証されたばかりのそのファイルでなければならない」からである。publish が verify を伴わない場合は set-matrix 段階で拒否され、非 tag ref も拒否される（バージョン番号はクローンした tags から取得）。
  • 6 つのバックエンドを一度に有効化（#865）：iluvatar-corex4.4.0/4.5.0、mthreads-musa4.3.6/5.2.0、sunrise-tangrt1.2.0、tsingmicro-tsm260610 はそれぞれ、コンテナ内のプローブで確定した assert と vendor_lib_dirs を補った。このコミットは同時に一つの隠れた欠陥を修正した。Makefile が flagcx/adaptor/*.cc しか glob しないため、flagcx_device.cc の devApiBackend へのハード参照が、ベンダー .mk が PLATFORM_EXTRA_SRCS を提供しない場合にシンボル未定義となり、-shared は未定義シンボルを許容し dlopen(RTLD_NOW) だけがこれを報告する——cambricon は既にカバー済みで、iluvatar/sunrise/tsm は補完が必要だった。
  • 海光 DTK バックエンドの開通（#866）：プローブの結論が形になった——DTK は CUDA_PATH をまったくエクスポートせず、du.mk の DEVICE_HOME ?=/CCL_HOME ?= は空値を捕捉し、2 つのパスは /opt/dtk/cuda/cuda-12 に固定された。DTK 上では -lnccl は実際には RCCL に解決されるため、成果物の NEEDED 項目は librccl.so.1 となり、nccl という綴りは debian/rules の shlibs ループ内でマッチしない。DTK のライブラリは ldconfig に登録されておらず、LD_LIBRARY_PATH は bash のみで有効な profile スクリプト由来であるため、dpkg-shlibdeps は 2 つのディレクトリを明示的に列挙しなければならない。同コミットは verify の ldd ゲートがイメージ自身の環境に影響される問題も修正した（基イメージは BASH_ENV を、LD_LIBRARY_PATH を再エクスポートするフックに向けており、ldd は bash スクリプトであるため先にそのフックが実行されていた）。
  • 初の「納品不可」記録（#868）：昆仑芯 xre5.37.1 の deb エントリは無効のまま維持され、その理由は backends.yaml のプローブ注記に書き込まれた——CCL ライブラリが .deb ビルドに使用するイメージ内に存在しない（base Containerfile は CCL パッケージをインストールせず、XRE 5.37.1.0 のインストールペイロードには xccl/bkcl が含まれず、スタック内で唯一の libbkcl.so はベンダー torch wheel 内のランタイム成果物である）。たとえ見つかってもバインドできない（このライブラリは C++ mangled シンボルをエクスポートし、純粋な C の bkcl_* エントリを持たない）。DESIGN.md の triage は「1 項プローブ保留」から「19 項準備完了＋1 項理由記録済み」に変わった。
  • 付随するエンジニアリング作業：#853 はパイプラインに「ユーザーのやり方で」公開済み apt リポジトリを読み戻させる。#854 はある行が失敗してもビルドに成功した行を検証させる。#855 は .deb ディスパッチにバックエンドリストを受け入れさせる。#856 はそれをビルドしたツールチェーンで .deb を読み取る。#859 はノードプロキシを verify コンテナに転送する。

解説：この線は今期で最も製品含意のある変化である。これまで FlagCX の可用性は「ユーザーが自分で通信ライブラリをビルドできるかどうか」に等しかった。十余りのベンダー私有ツールチェーンを同時にカバーしなければならないソフトウェアスタックにとって、これは規模化デリバリの最後の手作業の敷居であった。.deb をディストリビューション別に分割した apt リポジトリに入れることは、FlagCX のインストール面が初めて vLLM/SGLang プラグインの pip install と同じ階層に置かれたことを意味する。そして「リリースは検証直後のファイルと同一でなければならない」「publish は verify を迂回してはならない」「非 tag ref はリリース不可」という三つの制約は、この層が監査意識をもって構築されたことを示している。昆仑芯が明示的に「デリバリ不可」と記録され、曖昧に棚上げされなかったことも、「19 就緒 / 1 に理由あり」を対外的に説明可能なデリバリ面とした。

1.3 FlagCX カーネル面：net adaptor を 6601 行リファクタリング、PAL デフォルト device API バックエンドを補完（09-11/09-13）

出典：FlagCX #578（09-13 23:24）、#582（09-13 01:18）、#584（09-13 01:20）、#585（09-13 01:20）、#586（09-13 01:21）、#588（09-12 23:56）、#580（09-11 17:02）

  • ネットワークアダプタのリファクタリング（#578、+5309/-1292）：FlagCX メインリポジトリにおける本調査期間最大の単一変更であり、その規模は他の六件の合計を上回る。PAL（プラットフォーム抽象化層）方向のネットワークアダプタが書き直され、「通信ライブラリがプラットフォーム差異を抽象化層に収める」という主線の延長線上にある。
  • device API バックエンドの接続（#582）：残りのプラットフォームにデフォルト device API バックエンドをリンク。build-infra 側の #865 が言う「ベンダーの .mk が空のため devApiBackend が未定義になる」問題と同じ問題の裏表である——メインリポジトリ側でリンクを補い、デリバリ側でフィールドを補う。
  • 可用性とドキュメント面：#586 は FLAGCX_PATH が未設定のとき直接失敗せずシステムの FlagCX ライブラリにフォールバックする。#584 は getting_started に欠落していたバックエンドを網羅的に記載（「どのプラットフォームをサポートするか」をドキュメント上の事実とする）。#585 は format フックで用いる clang-format のバージョンを固定。
  • サプライチェーン強化（#588）：海光 CI イメージを SHCA 以前の digest に固定し、上流イメージの変更がビルド環境を黙って変えるのを防ぐ。
  • ベンダー対応の修正（#580）：燧原（enflame）デバイスアダプタ内の topsDeviceProp の型名を修正。

解説：FlagCX は本調査期間に性質の異なる三つのことを同時に行った——カーネル面のリファクタリング（#578）、プラットフォーム接続の補漏（#582/#580）、デリバリと CI の強化（#584/#585/#586/#588）。1.2 のパッケージング線と合わせると、通信ライブラリは「つなげられるライブラリ」から「インストールでき、位置特定でき、ビルドを再現できるライブラリ」へと変わりつつある。マルチチップのソフトウェアスタックにとって、通信ライブラリはまさに異なるベンダー SDK 間で特例が最も滞留しやすいコンポーネントである（海光の RCCL/ldconfig、昆仑芯に欠ける純 C エントリ、燧原の型名）。本調査期間の動きは、これらの特例が各ベンダーのブランチに残されるのではなく、一つずつテスト可能な抽象化層へと収束されつつあることを示している。

1.4 build-infra sglang 線：昆仑芯 xre5.37.1 と天数智芯 corex4.4.0 の二つのアプリケーション線が着地（09-12）

情報源：build-infra #857（09-12 11:35）、#860（09-12 12:27）、#861（09-12 12:28）、#862（09-12 13:00）、#863（09-12 14:42）、#864（09-12 13:14）、#867（09-12 18:57）、#869（09-12 19:05）、#870（09-12 21:09）、#871（09-12 19:28）

  • 昆仑芯 sglang ラインのクローズドループ（#857→#864）：まず kunlunxin-xre5.37.1 を「ビルド可能・駆動可能」にし、その後 F/T（機能と性能）検証結果を記録、sglang0.5.18-kunlunxin-xre5.37.1 changelog をリポジトリに登録、アプリケーションイメージ tag 2.1.2-0.1.dev1_g7fb22a0c2 を記録、さらに昆仑芯アプリケーションイメージを status matrix に書き込んだ。同一バッチで vllm-plugin-wheel が plugin_ref を解析する際に SIGPIPE で中止される問題も修正した（#860）。
  • 天数智芯 corex4.4.0 アプリケーションライン（#867→#871）：corex4.4.0 のアプリケーション設定を補完・検証し、sglang0.5.18-iluvatar-corex4.4.0 changelog とイメージ tag 2.1.2-0.1.dev1_g4d44a24cd をリポジトリに登録した。
  • 910C ラインの収尾：#848 で昇騰 910C 再ビルドのリリース待ち changelog エントリを復元、#850（09-11 19:19） で CANN 8.5.0-910c のイメージ tag 2.1.2-0.2.0_gf31b199.d20260911 を記録、#835 で 910C のエンドツーエンド結果と納品済みの cann8.5.0 T パス修正を記録、#852（09-11 20:55） で「アプリケーションイメージが陳腐化する」背景にある docker レイヤーキャッシュの罠をドキュメント化した。

解説：sglang 側の動作形態はすでに5ステップのクローズドループとして標準化されている——あるバックエンドをビルド可能にし、F/T 検証を実行し、changelog を記録し、イメージ tag を残し、status matrix に入れる。昆仑芯と天数智芯が同一の調査期間内にそれぞれ一通りを完走したことは、このクローズドループ経路（前の調査期間に昇騰と清微がそれぞれ検証済み）が現在は再現可能な日常的工程であり、各バックエンドごとの一度限りの難関攻略ではないことを示している。2.2 GA にとって、リリース範囲を実際に決めるのは status matrix 上の「検証済み」のマス数であり、今回の調査期間では昆仑芯と天数智芯 corex4.4.0 の2マスが新たに追加された。

1.5 build-infra vllm ライン：清微が 0.20.2 を開放、天数智芯 0.24.0 が統一 plugin wheel に収束（09-13）

情報源：build-infra #872（09-12 21:09）、#873（09-13 10:27）、#874（09-13 20:10）、#875（09-13 22:38）、#876、#877（09-13 22:49）、#878（09-13 22:56）

  • 清微 tsm260610 が vLLM 0.20.2 を開放（#873）：アプリケーションマトリックスのメンバーシップは configs.yaml の各バックエンドの deps_app キーによって決まる。清微は以前 vllm0.24.0 しか持っていなかったため、generate_matrix.py --app vllm0.20.2 の出力は空の include リストとなり、ビルドジョブは実行前にスキップされていた。今回 vllm0.20.2: [] を補い（0.20.2 プラグイン wheel は追加のベンダーパッケージを必要としない）、さらにリリース待ちエントリを付記し、イメージ tag を 2.1.2-0.2.1_g90ffdf0.d20260912 と記録し（#874）、プラグインを F/T エンドツーエンド検証が対象とする VPF #489 のヘッドに pin した（#872 にこのラウンドの 0.20.2 の F/T 結果が記録されている）。
  • 天数智芯 0.24.0 の収束（#875→#878）：2つの corex アプリケーションイメージを、単一コミットの vllm-plugin-FL ヘッド（symm_mem stub）から再ビルドするように変更し、corex4.4.0 と 4.5.0 を同一の vllm_fl バージョンに収束させ、それぞれが VPF #434 と g07063fd のバリアント wheel を pin することをやめた。イメージ tag は 2.1.2-0.2.1_gc9e2573.d20260913 と記録されている。同じコミットではさらに、「同一 wheel 内で corex4.4.0 T パスを修正する」計画を明確に否决している——その修正は決してマージされず、探索的なパッチは serve がゴミを出力するだけであり、天数智芯バックエンドモジュールを共用するということは、それを含めると検証済みの corex4.5.0 T パスをリスクに晒すことを意味するため、最終的に 14.4 節に記録し、強行はしなかった。

解説：2つの動作は同一のエンジニアリング指向を示している——マトリックスは「列挙できる」ものでなければならず、バックエンドは「同一のプラグインに収束」しなければならない。清微の問題はチップが使えないことではなく、アプリケーションマトリックスのキーが書き切られておらず、ビルドジョブがサイレントにスキップされていたことである。この種の「何も起きていないように見える」欠落は RC 期に最も発見しにくく、また configs.yaml がすでにリリース面の真のリストになっていることを最もよく示している。天数智芯の側は典型的なトレードオフの記録である：共用モジュールを汚染する修正を放棄し、corex4.5.0 の検証済みパスの確実性を取る——RC テスト期の「修正のみを取り込み、機能は取り込まない」という規律は、具体的なコミットにおいて「修正しないまでも、検証済みのマスを壊さない」として現れている。

1.6 FlagTree：0.7.0rc1 以降のベンチマークとバックエンド同期——昆仑芯クラスタ +17604 行、天数智芯ベンチマークが CI 入り（09-11/09-13）

情報源：FlagTree #1150（09-11 19:55）、#1153（09-13 22:28）、#1155（09-11 17:55）、#1157（09-11 17:24）

  • 崑崙芯 XPU クラスタ同期（#1155、+17604/-1775）：内部の 5a664566 から cluster 分析と pass を同期 —— Scalar/Tile/Vectorizability 分析ならびに XPU 専用 pass（Normalize、AsyncLoadSchedule、TLELegalize、LoopInvariantStaging、LegalizeExternEW）を導入し、stage_sm / load_scalar_indexed オペレータと GM2SM lowering を新規追加、手書きの OffsetAnalysis 属性を保持し、さらに budget-tiling と loop-invariant-staging をデフォルトで無効化；併せて P-TLE raw フロントエンド（tle.raw）を導入し、size-one make range の下沉を修正、compiler.py に UnrollControl 予算ノブを伝播させる（pin_unroll_num=-1 により vector-add を既存の unroll パスに通す）。ソース表記は baidu/xpu/triton 6848085b..5a664566。
  • 天数智芯ベンチマークの CI 導入（#1153）：iluvatar の vLLM benchmark をワークフローに追加。前ウィンドウの PPU ラインと同様の手法。
  • PPU ベンチマーク更新（#1157）：890P 上の PPU vLLM benchmark 結果を更新（33 行のデータ）。
  • Triton 上流同期（#1150）：上流 triton から warp layout broadcast を導入。

解読：0.7.0 のバージョン番号収束（前ウィンドウ）の後、コンパイラの動作重心は「バックエンドのベンチマーク化 + クラスタ同期」へと移行した。2 本のベンチマークライン（天数智芯 vLLM benchmark の CI 導入、PPU 890P 結果の更新）は、性能データがバックエンドごとに継続記録に入り始めたことを示す；崑崙芯の +17604 行のクラスタ同期は、XPU ラインが依然として「内部分岐 → オープンソースクラスタ」の方式で推進されていることを示し、かつ「どの pass をデフォルトで無効にするか」という保守的設定を伴う——ベンチマークと pass のスイッチは同様に管理対象である。

1.7 FlagGems：KMCompiler 昇騰代数補完、KernelGen マルチベンダー登録、崑崙芯 copy ファミリーの TLE 移行（09-11/09-14）

情報源：#6093（09-11 18:59）、#6136（09-11 17:48）、#6161（09-11 17:13）、#6201（09-14 09:44）、#6203（09-11 17:16）、#6205（09-11 17:51）、#6209（09-14 09:48）、#5671（09-14 10:12）、#6183（09-11 17:33）、#6192（09-11 18:37）、#6213（09-13 20:15）、#5642（09-14 09:09）

  • KMCompilerの昇騰代数を引き続き補完：調査期間内に昇騰バックエンドの matrix_rank（#6161）、igammac（#6136）、gru（#6201）、adaptive_max_pool3d（#5671、NVIDIAと昇騰がTriton kernelを共用）、linalg_solve_triangular の昇騰ベースラインパスのスキップ（#6209）、および依存関係の宣言（#6205）をマージ。
  • KernelGen生成オペレータのマルチベンダー登録：NVIDIA側では split_with_sizes（#5590）と convolution_overrideable（#5642、Triton kernel付き）を補完；摩尔線程側では conv_transpose1d（#6174）、upsample_linear1d_backward（#6175）、fmod_（#6170）、matmuladd（#6180）の4つの専用オペレータを一括登録。
  • 昆仑芯のcopyファミリーをTLEへ移行（#6093）：copyファミリーのオペレータを通常パスからTLE（Triton Language Extension）実装へ移行し、FlagTree側のTLE推進と対応。
  • 正確性とエンジニアリング面：[k] プレフィックス付きの3バッチにわたるカテゴリ修正——インデックスとソート類（#5971）、nn類（#5969）、数学類（#5967）；自動チューニングキャッシュでSQLite WALモードとbusy_timeoutを有効化し「database is locked」を修正（#6203）；CIで二重 __all__ 時に sort_exports がimportを誤削除する問題を修正（#6213）；昆仑芯/天数智芯のFlagTree CI dockerイメージを更新（#6192）。
  • ベンチマーク：独立したFP8行列積性能テストを追加し、vLLMをベースラインとして使用（#6183）；fused_marlin_moe のドキュメントに「重みレイアウトはvLLM Marlinレイアウトではない」という説明を補完（#6204）。

解読：FlagGems の当期間における 21 件のコミットの構造は非常に明確である——昇騰は KMCompiler ルートでオペレータごとに順次補完され（1 オペレータにつき 1 コミット）、NVIDIA と摩尔線程は KernelGen ルートでバッチ登録され、昆仑芯は TLE 化改造に着手している。3 つのパスが並行する意義は、同一のオペレータライブラリが同時に「コンパイラによる自動生成」「ジェネレータによるバッチ産出」「手書き TLE 最適化」という 3 種類の生産能力を担い、かつそれぞれが異なる成熟度のバックエンドに対応している点にある。エンジニアリング面で最も特筆すべきは自動チューニングキャッシュの SQLite WAL 修復である——マルチチップで大規模にベンチマークを実行する際のキャッシュの並行書き込みは典型的なロングテール故障であり、この種の修復は通常、大規模並列検証においてのみ顕在化するため、RC テスト期の真の成果に属する。

1.8 推論・訓練プラグインライン：海光 vLLM 0.24.0 ワークフロー開始、SGLang 側で 4 本の競技ブランチがマージ（09-11/09-12）

情報源：vllm-plugin-FL #436（09-11 10:54）、FlagGems-vllm #756（09-12 12:08）、#768（09-11 17:29）、#769（09-11 17:09）、#771（09-11 18:07）、#775（09-12 13:03）、#753（09-11 17:30）、FlagGems-sglang #45（09-12 11:43）、#47（09-12 12:16）、#58（09-12 12:21）、#61（09-12 11:44）

  • 海光が vLLM 0.24.0 ワークフローに参入（vllm-plugin-FL #436）：vLLM 0.24.0 向けに海光ワークフローを有効化。プラグイン層における「新チップ・新バージョンはまずワークフローを開き、その後デリバリを語る」という道筋の再度の実行である。
  • FlagGems-vllm のオペレータとテスト範囲：海光側で persistent_topk 実装を補完し、fused __init__ への接続を通過（#756）。昇騰側で per_token_group_quant_fp8 を補完（#775）。沐曦側で GDN chunk kernel を最適化（#771）。fp8_einsum およびテストと vLLM ベンチマークを新規追加（#769）。バックエンド横断の FP8 シーケンスオペレータテストを有効化（#768）。combine_topk_swa_indices のテストとベンチマークをベンダー非依存に変更（#753）。
  • FlagGems-sglang の競賽ブランチ4本をマージ（09-12）：add-chunk-local-cumsum-vec（#45）、add-context-attention（#47）、qkv-lora-b（#58）、chunk-state-varlen-v2（#61）の4本が、competition/ と個人ブランチ命名の PR として40分以内に相次いで master へマージされた。

解読：プラグインラインのこの2つの出来事を合わせて見ると興味深い。一方で fp8_einsum、combine_topk_swa_indices といった変更は、「某ベンダー専用テスト」をベンダー非依存（vendor-agnostic）へ書き換えるものであり、これは build-infra 側の「バックエンドを統一 plugin wheel へ収束させる」と同じ方向性である——各ベンダーごとに1セットの変種を減らすことにつながる。他方で FlagGems-sglang の4本のマージは競賽ブランチに由来し、コミュニティ競賽の成果がランキングボード上に留まらず主リポジトリへ入ったことを示している。2.2 にとって、これらのオペレータは flaggems-sglang v0.1.0-rc1.postN とともにリリースリストへ入る。

1.9 科学計算とドメインオペレータライブラリ：海光と沐曦の2バッチのオペレータを集中的に補完、FlagBLAS 天数智芯 L2、FlagSparse デュアルバックエンド（09-11）

情報源：FlagGems-Experimental #586（09-11 18:50）、#567、#606（09-11 16:56）、#415（09-11 17:25）、#427（09-11 17:14）、FlagBLAS #115（09-12 17:31）、FlagSparse #57（09-11 02:56）、#58（09-11 07:44）、FlagDNN #10（09-11 06:25）

  • FlagGems-Experimental：海光オペレータの一括登録：reflection_pad1d_backward（#567）、embedding_bag_dense_backward（#575）、upsample_nearest_exact2d_backward（#576）、lift_fresh（#585）、mse_loss_backward（#574）、binary_cross_entropy_backward（#577）、special_round（#582）、special_chebyshev_polynomial_u（#583）、amp_foreach_non_finite_check_and_unscale_（#559）、addmv_（#572）、diagonal_scatter（#570）、special_shifted_chebyshev_polynomial_v（#584）、baddbmm_（#586）など、逆方向および特殊関数オペレータを一括投入；同時に達摩院玄鉄の linear 専用オペレータを新規追加（#606、KernelGen ルート）。
  • FlagGems-Experimental：沐曦バッチの同時進行：約 35 件の MetaX 関連コミット。半数は「Add MetaX support」（weight_int8pack_mm #415、unsafe_masked_index_put_accumulate #413、max_pool3d_with_indices_backward #402、cholesky_inverse #390、cudnn_convolution #392 など）、半数は「Fix MetaX implementation」（special_gammaln #427、special_bessel_j0 #426、linear_backward #425、linalg_cholesky #423、histc #418、gcd_ #417、erfinv #416 など）。2 つの流れが同日に交錯しており、当該バックエンドが「実装追加＋実装修正」の集中的なキャリブレーション段階に入ったことを示している。
  • FlagBLAS：天数智芯 L2 サポート（#115、+5325 行）：iluvatar に L2（行列-ベクトル）レベルのサポートを追加し、master にマージ。
  • FlagSparse：沐曦と昇騰の参加＋SPMM キャリブレーション：調査期間内に metax ascend added、ascend multi datatype、spmm bell out of metax test および CI チェック。PR #57/#58 が外部貢献者（NCIC-AlphaSparse）によりメインリポジトリへマージ。
  • FlagDNN：達摩院玄鉄バックエンド更新＋ベンダー README：thead バックエンドを更新（#10）、摩尔線程と昇騰の README を追加。

解釈：ドメインライブラリ層の情報量は「補完の粒度」にある——単一調査期間内に実験オペレータライブラリのコミット 54 件＋FlagBLAS の L2 レベルサポート＋FlagSparse のデュアルバックエンド参加は、2.2 の六大 AI for Science ライブラリが「動作する」から「カバレッジの完成」へ向かいつつあることを示している。特に注目すべきは沐曦バッチの形態である：Add と Fix が交錯して出現するのは、バックエンドが「オペレータの存在」から「オペレータの正確性」へ向かう典型的なシグナルであり、この種のキャリブレーション作業は通常、単一チップの検証では発見できず、複数バックエンドの比較によってのみ露見する。

1.10 FlagQuantum：vNext アーキテクチャのマージ＋0.2.0 リリース成果物の検証＋QPU デジタルツイン（09-11/09-13）

ソース：FlagQuantum #15（09-11 18:26）、#16、#17（09-11 18:56）、#18、#19（09-11 20:31）、#20（09-11 22:11）、#23（09-13 15:06）、#24（09-13 18:29）、#25（09-13 19:33）、#26（09-13 20:05）

  • vNext アーキテクチャをメインラインにマージ（#15）：vNext の発表履歴を上流 main に接続し、アーキテクチャ再構築ブランチをマージした。
  • 0.2.0 リリース物の検証（#17）：Python パッケージの Homepage/Repository/Issues メタデータを flagos-ai/FlagQuantum に向け、公開済み上流リポジトリと整合させた。コミットメッセージには検証基準を記録している——wheel と sdist が distribution content check と厳格な Twine チェックを通過し、両インストール成果物が API 実行、2 ステップの PyTorch 訓練ループ、オペレータプロファイルのロード、Double-Single 数値一致検証を通過した。
  • 量子バックエンドとサービス側機能：#16 で Quafu の QSteed プラグインのインストール方法を明確化；#18 で CUDA と QSteed の開発コンテナを提供；#19 で Quafu 回路のサービス側コンパイル投入をサポート；#20 で再開可能な Quafu およびネイティブ九鼎ジョブを追加。
  • QPU デジタルツイン（#24/#25/#26）：fq.twin でベンダー中立の QPU デジタルツインを公開し、検証済み Twin エビデンスのオフラインロードとエビデンス永続化をサポート；#23 で後方互換性を保ちつつ公開量子ビットキーワードを移行。

解釈：量子ラインは本調査期間において、完全な「製品化」の軌跡を示している——アーキテクチャのマージ（vNext）、リリース物とメタデータの整合（0.2.0）、開発コンテナとサービス側コミット、そしてデジタルツインとエビデンス永続化へ。6 月の「科学智能基座」リリース時に FlagQuantum がまだ「量智融合の第一歩」というナラティブの中にあったとすれば、本調査期間の動きはすでに標準的なオープンソースプロジェクトのリリース工程（distribution content check、Twine strict、PyTorch 訓練ループのスモークテスト、数値一致性）である。FlagOS の版図にとって、量子計算のこのラインが独自のバージョンリズムに入れば、そのコンポーネントガバナンス方式（FEP、rc1 ブランチ、release manifest）も残り 25 のコンポーネントと足並みを揃えることになる。

1.11 訓練フレームワークとツール面：Megatron-LM-FL が CUDA ハード依存を剥離、FlagScale/FlagPrism/TransformerEngine-FL がそれぞれ前進（09-11/09-14）

情報源：Megatron-LM-FL #149（09-11 10:41）、#150（09-11 14:04）、#151（09-11 19:04）、#154（09-12 18:06）、#156（09-14 09:00）、TransformerEngine-FL #118（09-11 14:10）、FlagScale #1291（09-11 19:01）、FlagPrism #10（09-11 21:24）、FlagOS-Compressor #7（09-11 14:27）

  • Megatron-LM-FL の非 CUDA 化（5 件のコミット）：#156 はハードコードされた CUDA デバイス操作をプラットフォーム認識 API に置き換え、オプティマイザ、初期化、トレーニング、ツールの経路をカバーし、DDP ストリームの作成と同期を現在のプラットフォーム実装に切り替え、さらにデバイス配置、テンソル作成、可用性チェック、ランタイム初期化を更新した——コミットメッセージは「非 CUDA プラットフォームがトレーニングの初期化と実行において CUDA または Musa 専用 API を誤用するのを防ぐ」ことを明確な目標として掲げている；#154 は rerun ステートマシンにプラットフォームデバイスを使用させ；#151 はプラグイン側のプラットフォーム名とデバイス名を修正し；#149 はエキスパートデータ並列にプロセスグループの world size を使用させ；#150 はパイプライン並列の重複した P2P 通信器 stage 属性を削除した。
  • TransformerEngine-FL #118：アテンション経路が「flash attention を無効化」スイッチに従うようにした（従来このフラグは尊重されていなかった）。
  • FlagScale #1291：KERV 最適化ランタイムオペレータを追加。
  • FlagPrism #10：摩尔線程に profiler と debugger のサポートを追加しドキュメントを更新（FEP における「FlagTree DevTools」の実装に対応）。
  • FlagOS-Compressor #7：per-selector quantization（セレクタ単位の量子化）機能ブランチをマージ。

解釈：Megatron-LM-FL の 5 件のコミットは明確な主線を形成している：「CUDA または Musa 専用 API」をトレーニングのメイン経路から切り離すことである。マルチチップをターゲットとする重量級トレーニングフレームワークにとって、この種の改修は新しいアクセラレータを接続するための前提条件である——初期化、DDP、デバイス配置のいずれか一箇所でも CUDA を仮定していれば、非 CUDA プラットフォームはブランチパッチでしか生き延びられない。#156 を前の調査期間の同種の動きと合わせて見ると、トレーニングフレームワーク側は「プラットフォーム差異」を分散した if 分岐から統一プラットフォーム API へと集約しつつある；これは FlagCX が PAL 抽象を集約し、FlagTree がバックエンド抽象を集約しているのと同じエンジニアリング語彙が、異なる層で繰り返し現れているものである。

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

2.1 コンポーネント単位検索は 10 回連続の平穏な調査期間：技術情報面はすべてコードリポジトリ由来（09-11~09-14）

情報源：Google News RSS の中国語・英語 18 組のクエリ語（プロキシ経由）、HN Algolia（FlagOS / FlagGems / FlagScale / FlagTree の 4 組）、FlagOS 公式コミュニティサイトのバージョンとライブ配信リスト、Tavily/web 検索

  • コンポーネント単位のクエリは全てゼロヒット：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen、FlagOS-Robo、FlagQuantum（when:7d~14d、中英バイリンガル）、BAAI open source はいずれも調査期間内に有効なヒットがなく、コンポーネント単位検索の10回連続の平穏な調査期間を構成した（前回は9回目）。
  • HN側に有効なエントリなし：4組のクエリが調査期間内に返したエントリは汎用的な技術議論（GrapheneOSの投稿がflagされる、DietPi v10.7、いくつかのShow HNプロジェクト）であり、FlagOSコンポーネントとは関連がなく、既存の基準に従い全て除外した。
  • メンバー企業名のヒットは資本市場関連の内容が中心：燧原 when:2d（46件）、沐曦 when:2d（27件）、摩尔線程 when:2d（23件）、海光 when:2d（11件）、智源研究院 オープンソース when:7d（7件）、天数智芯 when:2d（6件）、地平線 オープンソース when:2d（1件）。うち資本市場と転載系が大多数を占め、智源コミュニティの記事（AI大会、オープンソースモデル解説など）はFlagOS技術スタックと直接の関連がなく、「スポーツ/ログイン/入口/公式サイト/ダウンロード/ギャンブル」の文字を含むSEO記事は一括で除外した。スクリーニングの結果保持された産業エントリは2.2を参照。
  • 公式コミュニティサイトに調査期間内の新バージョンなし：FlagOS公式コミュニティサイトの最新の図文公開は依然として08-28（GLM-5.3-Flash Day0が9種のチップに対応）であり、調査期間内に新たに追加されたのはライブ配信/イベントのエントリのみで、コードリポジトリ側の密集した動きと対照をなしている。

解読：10回連続の平穏な調査期間それ自体が一つの情報である——FlagOSの対外的な可視度は依然として主にコードとリリースのリズムによって構成されており、業界報道はまだコンポーネントに対する持続的な追跡を形成していない。利用者にとって、これは「コンポーネントが動いているかどうか」の答えをニュースからではなくリポジトリから読まなければならないことを意味する。今期の173件のコミットとゼロニュースの落差は、2.2 GA（09-28）以前にコミュニティが関心をプレゼン面ではなくデリバリー面に留めていることも示している。

2.2 産業側の三つの出来事：移動雲異構推論システムのリリース、燧原の上場初日終了、沐曦のロック解除ウィンドウが迫る（09-11~09-13）

情報源：IT之家（09-13）、財聯社/科創板日報（09-13）、証券時報（09-11 12:22）、財聯社（09-11 21:00）、新浪財経（09-13/09-14）

  • 国内初の「国産 GPU + 脳型チップ」大規模モデル異種混合推論システムが発表（09-13 報道、09-11～13 発表）：河北廊坊で開催された 2026 中国算力大会において、移動雲（モバイルクラウド）公司は中国電子科技南湖研究院、北京霊汐科技、上海天数智芯、清華大学、北京大学と共同で本システムを発表した。技術的アプローチは Transformer を PD/AF 分離するもので、Prefill と Attention を国産 GPU に、FFN（MoE エキスパート）など遅延に敏感なモジュールを脳型チップに担当させ、その存算一体とオンチップ大容量 SRAM の帯域幅優位性を活用する。チームが自社開発したモデルコンパイラ、高速相互接続プロトコル、統合推論エンジンによりタスク分解、協調スケジューリング、結果集約を実現し、この方式は NVIDIA 次世代の Vera Rubin with Groq 異種推論アーキテクチャに対標する。実測では天数智芯 GPU サーバ 3 台と脳型機櫃 3 台を組み合わせて DeepSeek V4 Flash を稼働させ、同等投入規模の純 GPU クラスタと比較して推論出力と推論エネルギー効率がいずれも 2 倍以上に向上し、業務運営コストは 40% 以上削減された。プロジェクトは累計 15 件の許諾特許発明、6 件のソフトウェア著作権を有し、現在は小ロット試産段階に入っている。
  • 燧原科技が科創板に上場、初日終値 179% 高（09-11）：発行価格 142.18 元/株、発行株数 4303.52 万株、調達総額約 61.2 億元。寄り付き 410 元（発行価格比 +188.37%）、ザラ場最高値 475 元、終値 397 元（+179%）、終日時価総額約 1709 億元、回転率 76%。オンライン有効申込倍率 6109 倍、当選率 0.0246%。同社はまだ黒字化しておらず、規則に従い科創成長層に組み入れられた。2023 年から 2025 年の売上高は 3.01/7.22/9.90 億元、2026 年上期売上高は 11.20 億元で前年同期比 279.08% 増。同社は 4 社の国産 GPU 企業の中で唯一 DSA 専用アーキテクチャに賭け、CUDA エコシステムと互換性を持たない企業である。燧原の上場により、「国産 GPU 四小龍」（摩尔線程、沐曦、燧原、壁仞）はすべて資本化を完了した。
  • 沐曦のロックアップ解除ウィンドウが迫る（09-13 予告、09-17 発効）：沐曦股份の 1396.6 万株の制限株式が 9 月 17 日に解除され、対応時価総額は約 68.29 億元、規模は流通盤の約 75% に相当する。同時期の報道によると、同社の 9 月の株価は 30% 近く下落し、高値からは 50% 超下落している。背景データ（08-30 半期報告、本ウィンドウ外）：2026 年上期売上高 13.24 億元で前年同期比 44.67% 増、親会社帰属純利益 6.12 億元で黒字転換を達成（非経常項目調整後は依然 -0.49 億元）、うち第 2 四半期純利益は 7.11 億元。同社は 2026-06-12 に H 株発行を公告し、A+H 二重プラットフォーム布局を開始している。

解読：三つの出来事はそれぞれ異なるレベルにある。移動雲の異種推論システムは技術路線レベルのシグナルであり（GPU はもはや唯一の算力形態とは見なされず、脳型チップが「帯域幅に敏感なモジュール」という位置づけで推論チェーンに入り、かつ天数智芯はこのシステムにおける GPU 提供者である）、燧原と沐曦は資本レベルのシグナルである（四小龍がすべて資本化した後、市場の関心は「作れるかどうか」から規模交付と利益実現へと移り、沐曦のロックアップ解除ウィンドウはこの転換の直接的なストレステストとなる）。FlagOS との関連意義は以下の点にある。これら二種類のシグナルはいずれも「マルチチップ統一ソフトウェアスタック」の実質的価値を高めている——異種推論システムはコンパイラと統合推論エンジンによって二種類の算力をスケジューリングする必要があり、国産 GPU が規模化交付に入った後、そのソフトウェアスタックの移行コストが受注能否落地を直接左右する。

2.3 コミュニティ活動と競賽：SGLang クロスチップオペレータ最適化競賽とオペレータ賞金競賽共有会、競賽成果がメインリポジトリへ流入開始（09-11～09-12）

情報源：FlagOS 公式コミュニティサイト（活動・ライブ配信リスト）、FlagGems-sglang リポジトリのウィンドウ内マージ記録

  • SGLang クロスチップオペレータ最適化競賽：衆智 FlagOS と IEEE の共同主催、SGLang の協力により開催。トラック 1 は SGLang フレームワークオペレータのマルチチップ性能最適化で、200 余りの実推論オペレータ問題を設け、参加者は自由に問題を選択し、段階的に開放される。Triton / Triton-TLE を用いて開発し、複数のチッププラットフォームで統一検証、統一加速比測定を行い、リアルタイムランキングと「全域攻占賞／攻克突破賞／単題極致性能賞」の三種類の賞を用意している。
  • オペレータ賞金挑戦競賽チャンピオン共有会：公式コミュニティサイトに 09-10 19:00 の受賞者共有ライブ配信（心の道のり、鍵となる決断、落とし穴回避法、実戦テクニックと交流質疑応答）が記録されており、持続的シリーズの一環である。
  • 競賽成果のメインリポジトリ流入：FlagGems-sglang は 09-12 の 40 分以内に competition/ と参加者個人ブランチからの四条の PR（add-chunk-local-cumsum-vec、add-context-attention、qkv-lora-b、chunk-state-varlen-v2）をマージし、いずれも SGLang 推論チェーン上の chunked attention と LoRA 関連オペレータを指向している。
  • エコシステム活動：衆智 FlagOS コミュニティ主催の『開放 AI 計算：多元異種ハードウェアに向けたオープンソースソフトウェア新エコシステムの構築』フォーラムが 09-07 に上海 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大会と同会場で開催された（智源、上海人工知能実験室、PyTorch 基金会、SGLang などが参加）。

解説：コンペティションの成果が PR 形式で FlagGems-sglang 主リポジトリに入ることは、本期で最も過小評価されやすい項目である。コミュニティコンペティションによくある問題は「リーダーボードは賑わっているが、主リポジトリには何の変化もない」というものだが、4 本の competition/ ブランチが同じ午前に master へマージされたことは、出題元、検証環境と主リポジトリの間がすでに接続されたことを示している——コンペティションは事実上、オペレータ生産能力の外部供給ラインとなっており、これらのオペレータは次の rc1.postN に伴って 2.2 リリースリストに入る。これは 1.8 における「プラグイン層がテストをベンダー非依存に変更した」動きの説明にもなる：加速比を統一的に測定するには、テストとベンチマークがまずクロスベンダーで比較可能でなければならない。

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

3.1 燧原科技：科創板の鐘を鳴らして「国産 GPU 四小龍」の資本化が完了、技術面では同時に enflame デバイス対応を修正（09-11）

情報源：証券時報（09-11）、財聯社（09-11）、FlagCX #580（09-11 17:02）

  • 資本面：09-11 に科創板へ上場（688801）、発行価格は 142.18 元/株、寄り付き 410 元、終値 397 元（+179%）、時価総額は約 1709 億元；4 社の国産 GPU 企業がすべて資本化を完了し、「最後のピース」が揃った。招股および決算の口径によると、2026 年上半期の売上高は 11.20 億元、前年同期比 279.08% 増、2023 年から 2025 年までの累計研究開発投入は 36.76 億元、2025 年末時点の研究開発人員は 643 人（従業員の 76.73%）、12 件の国家および地方の科学技術攻略プロジェクトを担い、58 件の AI チップと智算システムの重要国家・業界標準の制定に参加している。
  • 技術面（調査期間内）：FlagCX #580 は燧原（enflame）デバイスアダプタ内の topsDeviceProp の型名を修正したもので、通信ライブラリのプラットフォーム抽象化層におけるベンダー対応の修補に属する。
  • FlagOS 内での位置：燧原は build-infra のアプリケーションマトリクスにおいて依然として enflame-tops1.9.10 と enflame-tops1.10.6 の 2 本の sglang ラインとして存在し、FlagCX の .deb バックエンドリストでは有効化済みの検出通過項目の一つである。

解説：燧原は四小龍の中で唯一 DSA 専用アーキテクチャと自社開発ソフトウェアスタックの路線を歩む企業であり、これが FlagOS との関係をより「ソフトウェアスタック自持 + 選択的接続」に傾けている——その enflame-tops の 2 本のアプリケーションラインは FlagOS マトリクス内に長期的に存在するが、本調査期間の技術的動きは型名修正が 1 件のみで、拡張性ではなく保守性に属する。対照的に、同じ調査期間に天数智芯、清微、海光はいずれもバックエンドとアプリケーションラインで実質的な進展があった。資本化完了後、燧原の次の関門は研究開発の収益化と受注の履行であり、この点はマルチチップソフトウェアスタック内への投入を引き続き拡大するかどうかに直接反映される。

3.2 天数智芯：移動雲ヘテロジニアス推論システムへ参入、同時に FlagOS 内で 5 つの作業面を並行（09-11~09-13）

情報源：IT之家（09-13）、FlagBLAS #115（09-12 17:31）、build-infra #867/#869/#870/#871（09-12）、build-infra #875/#877/#878（09-13）、FlagTree #1153（09-13 22:28）

  • 産業面：移動雲が主導して発表した「国産 GPU + 類脳チップ」異種混成推論システムにおいて、天数智芯は GPU 提供者（天数智芯 GPU サーバ 3 台 + 類脳キャビネット 3 台、DeepSeek V4 Flash を実行）であり、Prefill と Attention 計算を担当する。
  • FlagOS 内の五つの作業面：第一に、FlagBLAS の L2 レベル対応が master にマージ（+5325 行）。第二に、build-infra の sglang アプリケーションラインに sglang0.5.18-iluvatar-corex4.4.0 を新規追加（設定検証 + changelog + イメージ tag）。第三に、vllm 側で 0.24.0 の corex4.4.0/4.5.0 を統一 plugin wheel に収束。第四に、FlagTree で iluvatar の vLLM benchmark を CI ワークフローに追加。第五に、FlagCX の .deb バックエンドリストで iluvatar-corex4.4.0/4.5.0 が同時に有効化。

解読：天数智芯は本期で出現頻度が最も高いメンバー単位であり、かつ技術ラインと産業ラインが互いに重複していない——産業側は「国産 GPU として異種推論システムに参入する」ことであり、FlagOS 側は「基礎ライブラリ + アプリケーションライン + ベンチマーク + パッケージング」の四層を同時に推進することである。この二つの事柄は論理的に相補的である。異種推論システムの帯域に敏感なモジュールの分割は、最終的にはオペレータライブラリ、コンパイラ、通信ライブラリによってスケジューリングを実現する必要があり、FlagOS こそがこうしたシステムにとって最も直接的なソフトウェア基盤の候補である。注目すべきは、FlagTree 側でベンチマークを CI に書き込んだことであり、これは天数智芯の性能データが今後、一回限りのレポートではなく継続的な記録として存在することを意味する。

3.3 清微智能：vLLM 0.20.2 アプリケーションラインが開通、エンドツーエンド検証とイメージ tag がクローズドループ化（09-13）

情報源：build-infra #872（09-12 21:09）、#873（09-13 10:27）、#874（09-13 20:10）

  • アプリケーションマトリックスのキー補完：清微バックエンド tsingmicro-tsm260610 は以前 vllm0.24.0 のみを備えていたため、--app vllm0.20.2 の出力が空となり、ビルドジョブが静かにスキップされていた。#873 で vllm0.20.2: [] を補完したことで当該行がビルドマトリックスに入り、changelog と未リリース項目を添付。
  • 検証クローズドループ：#872 で 0.20.2 の F/T エンドツーエンド結果を記録し、＃874 でイメージ tag 2.1.2-0.2.1_g90ffdf0.d20260912 を記録、プラグインは検証対象である VPF #489 のヘッドに pin。FlagCX .deb バックエンドリストにおいて tsingmicro-tsm260610 も有効化項目である。
  • 継続面：前ウィンドウで確立された tsingmicro3.6 build-and-test と delivery の二つのワークフロー（FlagTree 側）は本ウィンドウでは新規追加なし、通常のデリバリーラインの運行状態にある。

解読：清微のこのラインの価値は新規能力の追加ではなく、ある種のシステム的リスクを露呈したことにある——アプリケーションマトリックスのキー欠落はビルドを静かにスキップさせる。十数社のベンダーをカバーし、各社が複数のバージョン組み合わせを持つマトリックスにおいて、「エラーは出ないが何もビルドされていない」ことはビルド失敗よりも気づきにくい。この行を補完した後、清微は vLLM 側で 0.20.2 と 0.24.0 の二つのラインを同時に備え、さらに FlagTree のデュアルワークフローと FlagCX の deb バックエンドを加えると、その接続深度は最早一批のメンバー単位と同等になっている。

3.4 海光信息：通信ライブラリ deb バックエンド開通、vLLM ワークフロー開始、オペレータ一括補完の三ライン同時始動（09-11/09-12）

情報源：vllm-plugin-FL #436（09-11 10:54）、build-infra #866（09-12 18:25）、FlagCX #588（09-12 23:56）、FlagGems-vllm #756（09-12 12:08）、FlagGems-Experimental #586（09-11 18:50）

  • 通信ライブラリ .deb バックエンドの開通（#866）：海光 DTK バックエンドが「検出保留」から有効化状態へ移行。その間に3種類の環境問題を解決——DTK が CUDA_PATH をエクスポートしないため DEVICE_HOME/CCL_HOME が空になる、-lnccl が実際には RCCL に解決される（成果物の NEEDED が librccl.so.1）、そして DTK イメージの BASH_ENV フックが verify の ldd 環境を汚染する、という問題である。
  • プラグインと CI：#436 は vLLM 0.24.0 向けに海光ワークフローを有効化；#588 は海光 CI イメージを SHCA 以前の digest に固定し、上流イメージのドリフトを回避。
  • オペレータ面：FlagGems-vllm は persistent_topk を補完し fused __init__ に接続；FlagGems-Experimental は十数個の海光逆伝播および特殊関数オペレータ（reflection_pad1d_backward、embedding_bag_dense_backward、mse_loss_backward、binary_cross_entropy_backward、lift_fresh、baddbmm_ など）を一括で追加。

解読：海光の本調査期間における動作密度はメンバー単位の中で最も高く、かつ三系統の性質が相互補完的である——通信ライブラリ側が解決するのは「インストールできるかどうか」（DTK のパス、RCCL の命名、ldconfig という3つの特例はいずれもベンダーツールチェーンの現実の摩擦点であり、しかも誰かのマシン上に留めずコミットメッセージに書き込まれている）、プラグイン側が解決するのは「動かせるかどうか」、オペレータ側が解決するのは「カバレッジが十分かどうか」である。注目に値する細部は CI イメージを digest に固定したことである：マルチベンダーパイプラインにおいて、ビルド環境の決定性はコード本身よりも見落とされやすいことが多く、海光ラインはここで積極的に強化している。

3.5 摩尔線程と沐曦：生成オペレータとバックエンドオペレータの2バッチが着地、産業側の資本リズムは分化（09-11~09-13）

情報源：FlagGems #6174、#6175、#6170、#6180（09-11 18:17~18:21）、FlagPrism #10（09-11 21:24）、FlagGems-vllm #771（09-11 18:07）、FlagSparse #58（09-11 07:44）、新浪財経（09-13/09-14）

  • 摩尔線程：KernelGen 路線で専用オペレータ4件をバッチでリポジトリに取り込み（conv_transpose1d、upsample_linear1d_backward、fmod_、matmuladd）；FlagPrism に profiler と debugger のサポートを追加しドキュメントを更新；FlagDNN に摩尔線程の README を補完；FlagCX の .deb バックエンドリストで mthreads-musa4.3.6 と mthreads-musa5.2.0 の2系統を有効化；産業側では京東雲の10万カードクラスタの話題が継続（元イベントは09-09、既に前号で収録済み。本調査期間内は転載および分析記事であり、重複計上しない）。
  • 沐曦：FlagGems-vllm で GDN chunk kernel を最適化（#771）；FlagGems-Experimental に MetaX 関連のコミット約35件（新規サポートと修正実装が交互に並ぶ）；FlagSparse に metax サポートを追加；FlagCX の .deb バックエンドリストでは沐曦対応の系列は本調査期間内に有効化されなかった。
  • 産業側の分化：沐曦は09-17に1396.6万株のロックアップ解除を迎える（約68.29億元）。調査期間内には同社の株価下落とロックアップ解除圧力に焦点を当てた記事が複数見られた；摩尔線程は調査期間内に「MT Lambda」商標登録出願の公開記録が新たに追加された。

解釈：両社は技術面ではいずれも「オペレータのバッチ補完」段階にあるが、生産能力の源泉は異なる——摩尔線程の4つのオペレータは KernelGen 生成路線に由来し、沐曦のバッチは FlagGems-Experimental における手書き実装と修正に集中している。産業側の分化も同様に明確である：沐曦はロックアップ解除と株価下落圧力の局面に入り、摩尔線程は10万カード級受注のナラティブの上昇段階にある。FlagOS にとって、両社の技術投入のペースは資本市場の変動によって減速しておらず、本調査期間における各社のコミット数はいずれもメンバー単位の中で上位に位置している。

3.6 崑崙芯（外部エコシステム企業）：コンパイラ側は大幅に同期したが、通信ライブラリは「デリバリー不可」と記録（09-11/09-12）

情報源：FlagTree #1155（09-11 17:55）、FlagGems #6093（09-11 18:59）、build-infra #857/#861/#862/#864（09-12）、build-infra #868（09-12 21:08）

  • コンパイラ側：FlagTree の XPU クラスタ同期は当期最大の単一コミット（+17604/-1775）であり、分析フレームワーク一式と XPU 専用 pass、P-TLE raw フロントエンドと UnrollControl の予算伝播を導入した。
  • オペレータ側：FlagGems は昆仑芯の copy ファミリオペレータを TLE 実装へ移行し（#6093）、コンパイラ側の TLE 推進と呼応している。
  • アプリケーションライン：build-infra により kunlunxin-xre5.37.1 が sglang ラインでビルド可能かつ駆動可能になり、F/T 検証、changelog、イメージタグ、status matrix の記録を完了した。
  • 境界の記録：FlagCX は kunlunxin-xre5.37.1 を明確に「デリバリ不可」と記録した——CCL ライブラリが .deb ビルドに使用するイメージ内に存在しない（base イメージに CCL パッケージが入っておらず、XRE 5.37.1.0 のペイロードに xccl/bkcl が含まれず、唯一の libbkcl.so はベンダーの torch wheel 内にあり C++ mangled シンボルをエクスポートしていて純 C エントリが存在しない）。

解読：昆仑芯は本調査期間において「推進」と「制限」の両面を同時に示している。コンパイラ側の +17604 行は、その内部ブランチとオープンソースクラスタとの同期の力度が増していることを物語る。アプリケーション側は sglang の完全なクローズドループを走り切った。しかし通信ライブラリの層は現時点でデリバリ不可と判定され、その理由は極めて具体的に記されている（ライブラリがビルドイメージ内になく、仮に見つけてもバインドできない）。この「ビルドも実行もできるが、通信ライブラリはパッケージ化できない」という境界こそ、マルチチップソフトウェアスタックにおいて最も明示的に管理されるべき状態である——それはこのバックエンドがシングルマシン推論をサポートできるのか、あるいはマルチマシンの通信集約型シナリオをサポートできるのかを決定づける。

3.7 智源（主導者）：2.2 テスト期の規律と RC1 リストの維持、GA は 09-28 に確定（09-11）

情報源：community #108（09-11 11:45）、community リポジトリの 2.2 タイムテーブルと RC1 リスト（raw 直取得）

  • テスト期のガバナンス：2.2 サイクルはフィーチャーフリーズ 08-31 → テスト・安定化期 09-01 から 09-24（bug 修正のみ受け付け、新機能は入れない）→ GA 09-28；FEP 卒業基準はマルチチップシナリオをカバーする Test Plan がテスト期内に検収通過することを要求し、未通過部分は個別に検収 issue を立てて milestone に紐づける。
  • リストの維持：調査期間内で唯一のリスト変更は FlagGems を v5.4.0-rc1.post1 から v5.4.0-rc1.post2 へ進めたことであり、四種類の修正（cost model のロールバック、randperm のソート、int64 オーバーフロー、サブパッケージのパッケージング）をコミットメッセージに記した。
  • バージョン面：FlagTree の三本の triton ラインはリスト上 0.7.0rc1.post1+triton3.x と記録され、FlagCX は v0.14.0-rc1.post1、リスト全体で 25 件のコンポーネントスナップショット。

解読：主導者の本調査期間における動きはすべてガバナンス型である——リストの維持、フリーズ規律の執行、検収基準を検証可能な Test Plan として書き下すこと。こうした作業は対外的な報道では見えないが、09-28 の当日に「すべてのコンポーネントに tag があり、すべての tag がマルチチップ検証を経ている」デリバリ面を示せるかどうかを決定づける。エンジニアリング側（FlagCX のパッケージング、各ベンダーのアプリケーションライン）の動きと合わせて見れば、2.2 の核心的な問題はもはや「何チップをサポートするか」ではなく、「それらのサポートが再現可能で、インストール可能で、監査可能か」である。

4. まとめ

  1. デリバリ面が本調査期間の主線となり、通信ライブラリは完全にエンジニアリング化された最初のコンポーネントとなった（最重要の変化）：FlagCX は「ベンダー base イメージ内でバックエンドごとに .deb をビルド → Ubuntu バージョンで分割した apt リポジトリへ公開 → ユーザーの方法で読み戻して検証」という完全なチェーンを走り切り、六つのバックエンドを一挙に有効化した。付随する制約（公開物は検証直後のファイルと同一でなければならない、publish は verify を迂回してはならない、tag 以外の ref は公開不可）は、この層が監査意識を持って構築されていることを示す。従来の FlagCX の可用性は「ユーザーが自力でベンダー SDK に対してビルドできるか」に等しかったが、以後は apt-get install 一条に等しくなった。

  2. 2.2 はテスト期の後半に入り、バージョン推進は完全に修正駆動となった：RC1 リストの 25 件のコンポーネントスナップショットが整い、調査期間内で唯一のリスト変更は FlagGems を v5.4.0-rc1.post2 へ進めること（四項目の修正：cost model のロールバック、randperm のソート、int64 オフセットのオーバーフロー、サブパッケージのパッケージング欠落）；天数智芯の 0.24.0 は共用モジュールを汚染する T パスの修正を明確に放棄し、検証済みの 4.5.0 パスを守った——「修正しないまでも、検証済みのマス目は壊さない」は RC 規律がコードに現れた直接的な形である。GA は 09-28 に確定、テスト期は 09-01 から 09-24。

  3. 応用マトリクスの「閉ループ五段階」が複製可能な工程となり、欠けた鍵のリスクが露呈：バックエンドをビルド可能にする → F/T 検証を実行 → changelog を記録 → イメージ tag を記録 → status matrix に入れる、という流れを今回の調査期間中に昆仑芯（sglang xre5.37.1）と天数智芯（sglang corex4.4.0）がそれぞれ一通り完走した。一方、清微の問題（deps_app の記述漏れによりビルドがサイレントにスキップされた）は、このマトリクスが「エラーは出ないが何もビルドされていない」という故障モードをすでに備えていることを示しており、設定の完全性そのものがリリース面の一部となっている。

  4. 外部バックエンドがさらに強化され、初めて明示的に記録された納品境界が出現：昆仑芯 XPU クラスタ同期（+17604 行）、天数智芯 L2 ライブラリとベンチマークの CI 投入、清微の vLLM 0.20.2 対応開始、海光 DTK deb バックエンドの開通——四つの線が同時に進展。同時に昆仑芯通信ライブラリは「納品不可」と記録され、その理由（CCL ライブラリがビルドイメージ内にない、純粋な C エントリポイントが存在しない）も明記された。ソフトウェアスタックの価値はもはや「何社のチップをサポートするか」だけで測られるのではなく、「各社をどの程度までサポートするか」という陳述可能な境界によっても測られる。

  5. オペレータ生産能力が三路線で並行して進み、競争が外部供給ラインとなり始める：FlagGems の 21 件のコミットのうち、昇騰は KMCompiler で個別に補完、NVIDIA と摩尔線程は KernelGen でバッチ登録、昆仑芯は TLE 改修を進行。FlagGems-Experimental の 54 件のうち、海光は十数個の逆伝播および特殊関数オペレータを一度に補完、沐曦は約 35 件の「新規追加＋修正」が交錯。より長期的な意義を持つのは、FlagGems-sglang が 09-12 午前の 40 分以内に、クロスチップオペレータ競争からの competition/ ブランチ PR を 4 件マージしたこと——競争の成果が初めてメインリポジトリへのコミットという形でリリースリストに組み込まれた。

  6. 産業側の二つの動向がマルチチップソフトウェアスタックの実質的な重みを押し上げる：移動雲が霊汐科技、天数智芯などと共同で国内初の「国産 GPU＋脳型チップ」異種混合推論システムを発表（PD/AF 分離、天数智芯 GPU サーバー 3 台＋脳型ラック 3 台で DeepSeek V4 Flash を実行、性能とエネルギー効率が 2 倍以上向上、コスト 40% 以上削減）。異種演算リソースのスケジューリングがエンジニアリング段階に入ったことを示す。燧原は科創板上場初日に 179% 上昇で引け、四小龍がすべて資本化。沐曦は 09-17 に 68 億元の解除窓口を迎える——国産 GPU の焦点は「作り出す」から規模納品と収益実現へと移行しつつあり、その転換の中で最もシステムソフトウェアスタックに依存する二つの変数こそ、移行コストとクラスタ安定性である。

予測：今後の観察ポイントは四点——第一に、09-28 GA 前の rc1.postN の増分ペースと、リスト内であとどの項目がもう一巡イテレーションされるか。第二に、FlagTree のリスト内の記録（0.7.0rc1.post1+triton3.x）が正式な release tag へ進むかどうか、および build-infra の NVIDIA 線の pin 値が 0.6.1 からメインラインに追いつくかどうか（前回の調査期間で指摘したバージョンのずれは依然として存在）。第三に、FlagCX の apt リポジトリに最初の実ユーザーからのインストールフィードバックが現れるかどうか、および沐曦など未启用のバックエンドがいつ補完されるか。第四に、昆仑芯通信ライブラリの「納品不可」状態が反転するかどうか（例えば XRE の後続バージョンが CCL を伴い純粋な C エントリポイントを公開するなど）、および移動雲の異種推論システムの規模化試産が FlagOS のオペレータ／コンパイラ層に対する具体的な要件を引き出すかどうか。

付録：完全な情報源リスト

情報源 調査期間内の確認結果
GitHub org repos API（flagos-ai、53 リポジトリ） 21 リポジトリが調査期間内にプッシュ：FlagGems、build-infra、FlagGems-Experimental、FlagQuantum、FlagCX、FlagGems-vllm、Megatron-LM-FL、FlagTree、FlagBLAS、FlagGems-sglang、FlagDNN、FlagSparse、FlagScale、FlagPrism、vllm-plugin-FL、TransformerEngine-FL、FlagOS-Compressor、community、sglang-plugin-FL、docs、release-info；新規リポジトリなし；GitHub Releases に調査期間内の新規エントリなし
GitHub commit search（org 全体 150 件、5 ページ、sort=committer-date） 11 リポジトリのデフォルトブランチに実質マージ：FlagGems-Experimental 54 / build-infra 33 / FlagGems 21 / FlagQuantum 15 / FlagCX 7 / FlagGems-vllm 6 / FlagTree 4 / FlagBLAS 4 / FlagGems-sglang 4 / FlagPrism 1 / FlagScale 1
per-repo commits 再確認（アクティブだが search に未収録のリポジトリ） 23 件を追加：FlagSparse 10、Megatron-LM-FL 5、FlagDNN 4、vllm-plugin-FL 1、FlagOS-Compressor 1、TransformerEngine-FL 1、community 1；sglang-plugin-FL、docs、release-info の3リポジトリはデフォルトブランチに調査期間内の新規コミットなし（ブランチ/タグのプッシュ）
GitHub commit 詳細とパッチ #847（+2449 行、.deb パッケージングと verify の基準）；#851（+85/-25、apt リポジトリのリリースと publish/verify の制約）；#865（+147/-75、6バックエンドの有効化と devApiBackend 未定義シンボル）；#866（+32/-19、DTK パス/RCCL/BASH_ENV）；#868（+30/-11、昆仑芯の納品不可理由）；#873（+46、deps_app のキー欠落と 0.20.2 の公開）；#875（+20/-6、plugin wheel の統一と T パス修正の断念）；#1155（+17604/-1775、XPU クラスタ同期と内部ソース 5a664566）；#156（+103/-54、プラットフォーム認識デバイス API）；FlagCX #578（+5309/-1292、net adaptor リファクタリング）
community リポジトリ 2.2 リリース資料（raw 直接取得） release/2.2/release-2.2-rc1.yaml に計 25 件のコンポーネントスナップショット；release/2.2/schedule_CN.md に機能凍結 08-31、テスト・安定化期間 09-01~09-24、GA 09-28、FEP 卒業基準と [URGENT] 例外チャネルを明記；マニフェストファイルの調査期間内の唯一の変更は #108（FlagGems → v5.4.0-rc1.post2、tag は rc1 ブランチヘッド 270bebe1 を指し、4件の修正を含む）
Google News RSS（中国語・英語 18 組のクエリ語、プロキシ経由） コンポーネント単位のクエリ（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/KernelGen/FlagOS-Robo/FlagQuantum/BAAI open source）はすべてゼロヒット、10期連続の平穏な調査期間；メンバー単位のクエリはヒットし、移動雲異種推論システム、燧原上場、沐曦解禁の3類のエントリを保持；智源コミュニティの通常記事とギャンブル系 SEO 記事は一括除外
HN Algolia（FlagOS / FlagGems / FlagScale / FlagTree） 調査期間内に返されたエントリは一般的な技術討論（GrapheneOS、DietPi v10.7、Show HN シリーズ）であり、FlagOS コンポーネントとは無関係のためすべて除外
FlagOS 公式コミュニティサイト（バージョンとイベント一覧） 最新の図文投稿は依然として 08-28（GLM-5.3-Flash Day0 が 9 種のチップに適合）；調査期間内に新バージョンなし；調査期間内の新規追加はイベントエントリ：SGLang クロスチップオペレータ最適化コンテスト（衆智 FlagOS × IEEE 主催）、09-10 オペレータバウンティチャレンジ優勝者分享会、09-07 KubeCon 上海「開放 AI 計算」フォーラム
Tavily/web 検索（原サイトで日付確認） 移動雲異種推論システム：IT之家 09-13、財聯社/科創板日報 09-13（天数智芯 GPU サーバー3台 + 類脳キャビネット3台、DeepSeek V4 Flash、性能とエネルギー効率が2倍以上向上、コスト40%以上削減、特許15件 + ソフトウェア著作権6件、小ロット試産）；燧原上場：証券時報 09-11、財聯社
09-11（発行価格 142.18 元、寄り付き 410 元、終値 397 元、時価総額約 1709 億元、売買回転率 76%、当選率 0.0246%、2026H1 売上高 11.20 億元 +279.08%）；沐曦の解除：新浪財経 09-13/09-14（1396.6 万株、68.29 億元、流通株式の約 75% に相当）    
  確認済みだが重複計上しない項目 JD Cloud と摩尔線程の10万カードクラスタ（元イベント 09-09、前号で収録済み、調査期間内は転載と分析記事）；沐曦 2026 年半期報告書（08-30 開示、背景データとしてのみ）

局限性説明：本期の技術情報面は依然としてコードリポジトリを基準とし、産業報道は成員単位の資本・製品動向の対照にのみ用いる；Google News RSS はプロキシ経由でアクセスし、ヒット件数とカバレッジはアグリゲーション元の収録ペースの影響を受ける。コンポーネント単位のクエリは連続ゼロヒットが既に十期連続している。FlagOS 公式コミュニティサイトの図文更新はリポジトリの動きより遅れている（最新図文 08-28）。コミュニティ活動情報は同サイト内の活動リストから取得。企業財務・市場データは公開報道に基づくもので、さらなるクロス検証は行っていない。