調査期間：過去24時間（2026-09-16 10:18 ~ 2026-09-17 11:40、北京時間） 情報源：GitHub（org: flagos-ai、54個のリポジトリのpushed_at全量核查 + 単一commit search 150件をcommitter-dateで検証 + 重点リポジトリのデフォルトブランチコミット再確認 + tags/releasesメタデータ + community公開リストと公開タイムテーブルのraw直接取得 + 重要コミットのパッチとファイルリスト詳細）、Google News RSS（中国語・英語33組のクエリ語、プロキシ経由）、HN Algolia、投資界、智源コミュニティ、新浪財経、雷峰網、集微網など（詳細は付録の情報源リスト参照）

本期インデックス

  • 今日の重点：build-infraがバージョンフィールドを2.1.2から2.2.0へ引き上げ——2.2 GA前の最後のグローバルスイッチが切り替わる（09-17）
    1. オープンソースプロジェクトの進展（GitHub動向）
      • 1.1 build-infra：baseバージョンを2.1.2から2.2.0へ、FlagGemsは5.4.0-rc2.post2にロック（09-17）
      • 1.2 FlagTrain新リポジトリが配置：訓練側に空のプレースホルダーリポジトリが出現（09-16）
      • 1.3 FlagFFT：36個のFFTオペレータを一括検収、NumPyによる独立検証とランタイム計画を用意（09-16）
      • 1.4 FlagGemsオペレータ拡充：KernelGenの18個のNvidiaオペレータがリポジトリ入り（09-16/09-17）
      • 1.5 FlagGems量子化オペレータライン：摩尔線程ネイティブFP8 W8A8 MM、沐曦W8A16 RMSNorm（09-16/09-17）
      • 1.6 FlagGems-vllm：Marling MoE融合とFP8可変長FlashAttention-2（09-16/09-17）
      • 1.7 Torch-FL：「ルーティング切り替え」から「切り替え後の後始末修正」へ（09-16/09-17）
      • 1.8 FlagTree：FlagTune管理Manifestとiluvatar3.6ベースラインワークフロー（09-16/09-17）
      • 1.9 FlagQuantum：JAXテストを導入、カバレッジ下限を60%へ引き上げ（09-17）
      • 1.10 FlagCXとvllm-plugin-FL：PTDログのストリーミング化、T-Head PPU CIの導入（09-16/09-17）
      • 1.11 その他の動向：community、FlagGems-Experimental、flir、FlagScale-Agent、イメージタグ記録（09-16/09-17）
    1. 報道とエコシステム
      • 2.1 コンポーネント単位検索は13回連続の平穏な調査期間：24時間以内にゼロヒット（09-16~09-17）
      • 2.2 FlagOS 2.2タイムテーブルとRC2リストの再確認：GAは09-28に確定（09-17 検証）
      • 2.3 地平線体系：地瓜機器人が4億ドルCラウンドの資金調達を完了（09-17）
      • 2.4 メンバー企業の資本面：沐曦の中間決算が黒字転換、燧原は上場初日に時価総額1000億突破、国産GPU中間決算（09-16~09-17）
    1. メンバー企業の深掘り
      • 3.1 海光：linalgとdtypeセマンティクスの両端を同時に補完（09-16）
      • 3.2 昇騰：MoEと線形注意機構に必要なオペレータが最も集中するライン（09-16/09-17）
      • 3.3 達摩院玄鉄：推論プラグインがPPU CIに接続、MM/MVがNN/NTレイアウトをサポート（09-16/09-17）
      • 3.4 摩尔線程：ネイティブFP8 W8A8 MMとMUSA回転位置エンコーディングをデバイス側へ（09-16/09-17）
      • 3.5 沐曦：W8A16 RMSNormと3箇所のルーティング迂回（09-16/09-17）
      • 3.6 昆侖芯：xCCLをベースイメージに組み込み、オペレータ修正バッチが着地（09-17）
      • 3.7 天数智芯：/dev/itrctlとiluvatar3.6ベースラインワークフロー（09-17）
      • 3.8 燧原：GCU300を0.24.0レポートと2つのイメージタグに記録（09-16）
      • 3.9 智源（牽頭者）：ガバナンス自動化とバージョン番号の引き上げ（09-16/09-17）
    1. まとめとトレンド観察
  • 付録：情報源検証表
  • 付録：完全な情報源リスト

今日の重点：build-infraがバージョンフィールドを2.1.2から2.2.0へ引き上げ——2.2 GA前の最後のグローバルスイッチ

日付：2026-09-17　出典：build-infra #916 バージョン引き上げ、build-infra configs.yaml、FlagOS 2.2 リリーススケジュール

09-17 08:49、build-infra はわずか2行の変更からなるコミット Bump base version to 2.2.0 (#916) を受け取った。configs.yaml 内の version が 2.1.2 から 2.2.0 に、同じ箇所の flaggems が 5.3.5 から 5.4.0-rc2.post2 に変更された。

この2行の重みは、このファイル自体の位置づけに由来する。ファイル冒頭には「すべてのベンダー/バックエンド依存とビルド設定の唯一の信頼できる情報源（single source of truth）」と明記されており、scripts/build_base.py と scripts/build_runtime.py から読み込まれる。version フィールドはすべてのベースイメージとアプリケーションイメージにタグを付ける役割を担い（flagos-base-{ベンダー}-{バックエンド}:{バージョン} と flagos-runtime-{ベンダー}-{バックエンド}:{バージョン}）、コメントにはリリース作業を3ステップで記している。すなわち、この2つのフィールドを更新し、v<バージョン> タグを打ち、完了とする。つまり、前日に各モジュールが rc タグを打ったのは候補バージョンを検証位置へ押し出したにすぎず、今回の引き上げによってイメージライン全体が 2.2.0 を指すことになり、2.2 GA 前における org 内唯一のグローバルスイッチとなる。

他の証拠と照らし合わせると、リズムは一致している。community の 2.2 リリーススケジュールでは、機能凍結を 08-31、テストと安定化期間を 09-01 から 09-24、GA を 2026-09-28 と定めており、milestone「FlagOS 2.2」は現在7つの issue がいずれも未クローズで、期限も同じく 09-28 である。RC2 リストの24モジュールエントリのうち、FlagGems だけが v5.4.0-rc2.post2 に達しており、残りは依然として rc2.post1 である。build-infra リポジトリ自身の最新タグは依然として v2.2.0 以前の v2.1.1 であり、イメージタグがまだ打たれていないことを示している。GA まで残り11日、マルチチップ検収に残された時間枠は狭まりつつある。

注目すべきは同期性である。同じ日、build-infra は昆仑芯ベースイメージへの xCCL インストール（#917）と containerfile 修正（#918）もコミットしており、いずれも 2.2 イメージライン凍結前にベンダー依存を補斉するもので、典型的な「リリース前一キロ」の動きである。

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

期間総覧：org 内54リポジトリのうち 19 が期間内にプッシュあり。単一の commit search で期間内コミット 150件 がヒット（2ページ、committer-date 降順、全量取得済み）、15リポジトリに分布：FlagGems 71、build-infra 18、Torch-FL 17、FlagGems-sglang 10、FlagTree 8、FlagFFT 7、FlagGems-Experimental 5、FlagGems-vllm 4、FlagQuantum 2、vllm-plugin-FL 2、community 2、および FlagCX、FlagTrain、FlagScale-Agent、flir が各1。ほかに docs、release-info、sglang-plugin-FL、TransformerEngine-FL の4リポジトリが期間内にプッシュされているが、デフォルトブランチ上に期間内の新規コミットはない（サイドブランチまたはタグプッシュに属し、うち docs と release-info はリリース成果物とドキュメントサイトの同期を担う）。

本期間の形態 = 「リリース成果物凍結」+「切り替え影響修正」の2ライン：ガバナンス側では build-infra がバージョン番号を引き上げ、community がリリース優先度を同期して 2.2 を収束させる。エンジニアリング側の関心は「オペレータライブラリにオペレータを追加する」ことから2種類の収尾作業へ移っている。第一に、新たに取り込まれたオペレータを規範へ登録すること（エクスポート検査、テストマーカー、ベンチマーク整合）。第二に、先週のルーティング切り替えが各チッププラットフォームで露呈させた具体的な問題を受け止めること（MetaX のスライスオペレータ、MUSA の複素数回転位置エンコーディングと乱数ブリッジ、CUDA の FlagTune 欠如）。FlagTrain は本期唯一の新規リポジトリだが、現時点ではプレースホルダーにすぎない。

1.1 build-infra：base バージョン 2.1.2 から 2.2.0、FlagGems は 5.4.0-rc2.post2 に固定（09-17）

日付：2026-09-17　出所：build-infra #916、build-infra configs.yaml

詳細は「今日の重点」を参照。補足として一箇所、対照価値のある点：flaggems フィールドは 5.3.5 から直接 5.4.0-rc2.post2 へと飛び、一つのマイナーバージョンと二回の rc を跨いでいる。これは 2.1.2 イメージラインが以前に固定していたオペレータライブラリと 2.2 候補との間に、すでにかなり長い検証距離があることを示している。一方、build-infra リポジトリの最新タグは依然として v2.1.1 に留まり、v2.2.0 タグはまだ出現していない。これは今後のデイリーレポートにおける観察ポイントとなり得る。

1.2 FlagTrain 新規リポジトリの配置：訓練側に空のプレースホルダリポジトリが出現（09-16）

日付：2026-09-16　出所：FlagTrain リポジトリ

09-16 15:02、org 内に新規リポジトリ FlagTrain が追加された。リポジトリ作成と唯一のコミット（Initial commit）の間隔は 1 秒未満、リポジトリ規模は 5 KB、説明なし、言語統計なし、README は一行のタイトルのみ——典型的なプレースホルダ作成である。命名からして、これは FlagOS の訓練側に位置する。この方向には既に FlagScale（訓練フレームワークのエントリポイント）、Megatron-LM-FL と TransformerEngine-FL（訓練カーネルと並列オペレータ）、FlagScale-Agent（自動チューニング）が存在する。新規リポジトリの位置づけは README とディレクトリが埋まってからでなければ判断できないが、「訓練側からさらに一塊が切り出された」という動き自体は記録に値する。org の慣例（FlagSparse、Open3D-PIMC はいずれも先にリポジトリを作成し、後からバッチで実装を落としている）に従えば、コードの配置は通常、リポジトリ作成後数日から数週間のうちに行われる。

1.3 FlagFFT：36 個の FFT オペレータを一括検収、NumPy による独立検証とランタイム計画を併備（09-16）

日付：2026-09-16　出所：FlagFFT オペレータ検収コミット、FlagFFT リポジトリ

09-16 15:38、FlagFFT は +2151/-2298 のコミット feat: accept 36 FFT operators with NumPy validation and runtime plans を受け取った。一度に 36 個の FFT オペレータを検収状態へ移行するもので、変更は 8 ファイルに及ぶ：オペレータ一覧とテストマトリックスの二つの設定、ビルド宣言、検収テストランナー、そして独立検証専用の一対の参照実装ツール（C++ 側がベンチマーク出力のキャプチャを担当し、Python 側がオペレータごとの比較を行う）。その後二時間以内に、さらに二件の付随コミットが追加された：test: enforce complete acceptance coverage and update CI reporting（15:44）は検収カバレッジを必須項目として書き込み、CI 報告の基準を変更し、fix: preserve report compatibility and test interruption handling（15:58）は報告の互換性と中断処理を修正した。

三件を並べて読むと、FlagFFT の今回の実質的な変化は「36 個のオペレータが増えた」ことではなく、検収基準のアップグレードである：独立にキャプチャした NumPy 出力を参照実装として用い、ランタイム計画（runtime plans）と組み合わせて一件ずつ比較するのであって、自己証明式の単体テストではない。RC2 リストにおいて FlagFFT の候補バージョンは v0.2.0-rc2.post1 であり、この検収ラインこそが rc から GA へ向かう根拠である。

1.4 FlagGems オペレータ拡充：KernelGen の十八個の Nvidia オペレータが取り込み（09-16/09-17）

日付：2026-09-16 から 2026-09-17　出所：FlagGems リポジトリコミット、FlagGems #6135 histogramdd、FlagGems #5961 slice_copy

ウィンドウ内のKernelGenラインは毎日十余件のペースで主リポジトリにNvidiaオペレータを注ぎ込み続けており、Tritonカーネルを伴う新規登録オペレータは計18個で、四類型をカバーしている。形状・インデックス類（次元削減、スライスコピー、チャネルシャッフル、同形状判定、次元指定による値取得）、線形代数・特殊関数類（テンソル逆行列、行列式対数、Sobol系列、指数関数）、訓練・逆伝播類（トレース逆伝播、マスク付きソフトマックス逆伝播、スパース埋め込み逆伝播、ランダムドロップアウト）、そしてプーリング・サンプリング類（分数次元3Dプーリング、最近傍3Dアップサンプリング逆伝播）である。類型分布は前ウィンドウと一致しており、線形代数、特殊関数、訓練用逆伝播オペレータがそれぞれ一段を占めている。

真にエンジニアリング量を体現しているのは、それに伴う登録とテスト規範の3条である。1条はオペレータ導出にソートと一貫性チェックを追加し、1条は「FlagGemsでATenを置き換える」チェックを今回の新規行のみに限定し、過去のコードの干渉を避け、もう1条は命名規則に従ってアンダースコア付きオペレータのテストマークを自動導出する。また別に [Test] Align MM tests and parallel FP8 benchmark with scaled-MM API（#6329）がテスト側でスケーリング行列積のインターフェースを整備している。バッチ登録の副作用は「登録コスト」の上昇であり、これらの条項はまさにそのコストをCIに固定化しようとしている。

1.5 FlagGems 量子化オペレータライン：摩尔線程ネイティブFP8 W8A8 MM、沐曦W8A16 RMSNorm（09-16/09-17）

日付：2026-09-16 至 2026-09-17　情報源：FlagGems #6211 摩尔線程 FP8 W8A8、FlagGems #6326 沐曦 W8A16 RMSNorm、FlagGems #4412 FP8 topk

摩尔線程ラインはネイティブFP8 W8A8行列積バックエンドを新規追加（#6211、5ファイル、+1100/-80）。摩尔線程バックエンドの量子化行列積ディレクトリの下にベンダーネイティブパスを実装し、Nvidia Hopper版と並列に存在させ、ベンチマークスクリプトとテストも整備している。これはこのパスが「汎用カーネル＋フォールバック」ではなく「ハードウェアに近いネイティブ実装」として提供されることを示している。沐曦ラインはW8A16 RMSNormを新規追加（#6326）、量子化範囲を行列積から正規化層へ拡大した。同期間にはFP8 topkのパス選択も最適化（#4412）。さらにテスト側のスケーリング行列積APIの整備と fix ops bugs（#6259）の一括修正を加えると、本ウィンドウで量子化に直接関連するコミットは計7条。総合すると、W8A8/W8A16のカバレッジは「行列積1層」から正規化、サンプリングなどの隣接オペレータへ拡散しつつあり、2.2で量子化オペレータを拡容量の主線と位置づけた方針に合致している。

1.6 FlagGems-vllm：融合Marlin MoEとFP8可変長FlashAttention-2（09-16/09-17）

日付：2026-09-16 至 2026-09-17　情報源：FlagGems-vllm #750 融合Marlin MoE、FlagGems-vllm #749 FP8可変長アテンション

二つの大型変更は同じ思路で推論オペレータ層に着地している。其一 [QC] Add INT8 and FP8 W8A16 fused Marlin MoE（#750、7ファイル、+3118/-46）はINT8とFP8の2種類のW8A16重みの融合Marlin MoEオペレータを新規追加し、2本のベンチマークスクリプト、1本のテスト、Nvidiaバックエンドのチューニング設定 tune_configs.yaml を添付し、オペレータ選択ツールも更新した。其二 [QC] Add FP8 W8A8 variable-length FlashAttention-2（#749、5ファイル、+4710）は可変長シーケンスのFP8 FlashAttention-2を補完し、プレフィル段階で最も一般的な形状をカバーし、同時に conf/operators.yaml に登録した。

両オペレータは同じ種類のギャップを指し示している。推論側の量子化オペレータはこれまで固定形状と稠密パスに集中していたが、実際のサービスでは可変長バッチとMoEスパース活性化こそが主流形態である。この種のオペレータは検収基準もより高く、2本のベンチマークとチューニング設定が同時にリポジトリに入ることは、それらが「動けばよい」ではなく「チューニング可能で再現可能」という基準で提供されていることを意味する。

1.7 Torch-FL：「ルーティング切り替え」から「切り替え後の修復」へ（09-16/09-17）

日付：2026-09-16 から 2026-09-17　出典：Torch-FL #306 MetaX バイパス、Torch-FL #316 MUSA 回転位置エンコーディング、Torch-FL #310 FlagGems master へのピン留め

前の調査期間の主な動きは、6つのプラットフォームのオペレータディスパッチを「FlagGems 優先」へ切り替えることだったが、今回の調査期間の17件のコミットはほぼこの切り替えの反響であり、処理方法によって3つに分類できる。

第一類は名前付きバイパス：MetaX では slice.Tensor を FlagGems のルーティングから外し、これによって Qwen-Image-2512 の手動テストフローを通した（#306）；MUSA では複数形の回転位置エンコーディングオペレータをデバイス側で実行させた（#316、8ファイル、+99/-7、csrc/aten/backends/musa/ 配下の生成コードと codegen_mudnn.py の生成規則を含む）。同時にベンダーオペレータモジュール上の乱数ブリッジを再バインドした（#298）。第二類は明示的スイッチ：上流の FlagGems master でリグレッションが発生したため、CI を一時的に直近の使用可能なコミットへピン留めした（#310）；CUDA 線上では FlagTree が FlagTune を導入する前に USE_FLAGTUNE=0 を設定した（#311）；ビルド時のアクセラレータ設定を wheel に書き込み（#314、単体テストを含む）、インストール後にビルドターゲットを知る事態を回避した。第三類はゲート構築：オペレータテストゲートで PPU を明示的に検出し（#309）、PPU テストマニフェストを埋め込み JSON ではなく ppu.yml から読み取るように変更し（#305）、プラットフォームパイプラインをプラットフォーム非依存のチェックの後に統一的に配置し（#304）、さらに CI の全プラットフォームで FlagGems master を追跡した（#301）。

3つを合わせて見ると、これは再利用可能な対応パターンである：修正できるものはルーティングバイパスで回避しテストを残す。修正できないものは明示的スイッチで遮断する。最後に判断根拠をゲートに据える。「1つのオペレータライブラリを複数チップで再利用する」という命題にとって、バイパスリストの長さ自体が可用性の測定基準である。

1.8 FlagTree：FlagTune マニフェスト管理と iluvatar3.6 ベースラインワークフロー（09-16/09-17）

日付：2026-09-16 から 2026-09-17　出典：FlagTree #1103 FlagTune マニフェスト管理、FlagTree #1197 天数ベースラインワークフロー、FlagTree #1190 PPU ベンチマーク結果

主な変更は FlagTune（自動チューニングサブシステム）の大型改修である（#1103、17ファイル、+687/-153）：マニフェスト管理によるデフォルト値と実行時互換処理を新規追加し、変更範囲は契約層（オペレータパターンと式定義）、探索層（遺伝的アルゴリズム探索とインターフェース規約）、実行層（自動チューナー、ベンチマークプロトコル、デバイス抽象化とエラー定義）に及び、4組のテスト（ベンチマークプロトコル、モデルアーカイブ、モデルソース、実行時エラー）を備えた。いわゆるマニフェスト管理によるデフォルト値とは、チューニング設定のデフォルトがローカル生成に依存せず、統一的な一箇所から提供されることを意味し、これはマルチチップ、マルチ Triton バージョンの組み合わせにおいて特に重要である。

付随するエンジニアリングラインも同日に推進された：天数智芯向けに iluvatar3.6 の FlagGems ベースラインとテストワークフローを追加し（#1197）、PPU ベンチマーク結果を更新し（#1190）、FlagGems テストテンプレートのバックエンド初期化を統一インターフェースに抽出し（#1192）、hcu ラインのベンチマークスクリプトをサーキットブレーカープロセスをクリーンアップするスクリプトに変更し（#1188）、さらに偶発的に失敗する昇騰 TLE テストケースに無視を追加した（#1185）。

1.9 FlagQuantum：JAX テストを導入、カバレッジ下限を60%に引き上げ（09-17）

日付：2026-09-17　出典：FlagQuantum #48 JAX テストとカバレッジ下限

09-17 11:05、FlagQuantum は +429/-5 のコミットを受け取り、JAX テストを正式に継続的インテグレーションへ導入した：ハイブリッドフロントエンドテスト1件と単体テスト5件（バッチプルバック、MPS カーネル、状態ベクトルカーネル、テンソルネットワーク収縮、テンソルネットワークカーネル）を新規追加し、継続的インテグレーションワークフローとテスト設定を同期更新し、カバレッジ下限60%を契約ディレクトリ配下のカバレッジポリシーファイルに明記した——すなわち品質閾値をワークフローパラメータではなく契約ファイルの形式で固定した。このリポジトリは「PyTorch 優先の量子 AI フレームワーク」と位置づけられており、JAX を導入したことは、第2のフロントエンドを同等の受け入れ基準に組み込むことを意味し、これは FlagOS の各モジュールに広く見られる「まず契約を定め、次に実装を補う」というアプローチと一致する。

1.10 FlagCX と vllm-plugin-FL：PTD ログのストリーミング化、T-Head PPU CI 接続（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：FlagCX #601 PTD ログのストリーミング化、vllm-plugin-FL #518 達摩院玄鉄 PPU CI、vllm-plugin-FL #528 崑崙芯修正

FlagCX の変更は小さくかつ重要である。チップ間通信ライブラリのパフォーマンスツール PTD は、ログを OpenMetrics に変換する際にログ全体を一度にメモリへ読み込んでおり、prepare 段階で大規模実行時にメモリ枯渇により終了してしまう。 #601 はその変換をストリーミング処理に改めた（tools/PTD/src/prom2openmetrics.py、+68/-29）。代償は状態機械が一段増えることだが、利点はツール自体が負荷テスト規模のボトルネックにならなくなることである。

推論プラグイン関連は二件。達摩院玄鉄 PPU の CI が正式に接続され（#518、9 ファイル）、新たにプラットフォーム設定 configs/thead.yml、環境準備とチェックスクリプト、イメージ docker/thead/Dockerfile、プラットフォームテスト一覧 tests/platforms/thead.yaml を追加し、併せて MetaX プラットフォーム一覧の修正とツールの整理を行った。崑崙芯側では FlashAttention モジュールのインポート失敗後に残る状態汚染を修正した（#528）。PPU CI の接続と本レポート 1.7 における Torch-FL の PPU に対する明示的な検出を併せて読むと、達摩院玄鉄ラインは本調査期間において自建テストのカバレッジが明らかに強化されている。

1.11 その他の動向：community、FlagGems-Experimental、flir、FlagScale-Agent、イメージタグ記録（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：community 2.2 プロジェクト同期、FlagGems-Experimental MetaX index_select、flir #74、build-infra 崑崙芯 xCCL

  • community：リリース優先度をプロジェクトビューへ同期し（ワークフロー .github/workflows/flagos-2.2-project-sync.yml、+60/-1）、2.2 の項目がリリース期間中継続的に可視となることを保証した。ガバナンス操作がバージョン引き上げと同日に行われたことは、2.2 収束の付随措置に属する。
  • FlagGems-Experimental：MetaX の index_select 実装を修正し（#419）、conv_depthwise2d に MetaX サポートを追加し（#391）、dense_dim オペレータを補充した（#639）——当該リポジトリは引き続き「バックエンド対応を先に実装し、検証後に本リポジトリへ入れる」試験場の役割を担っている。
  • flir：tile.to_tensor の Pure マークを外し、上流の bufferization セマンティクスに合わせた（#74）。変更は昇騰 TLE ラインに関連する。
  • FlagScale-Agent：ドキュメント中のクローンアドレスが自身のリポジトリを指すよう修正した（#42）。
  • build-infra イメージライン：崑崙芯ベースイメージに xCCL を導入し（#917）、その containerfile を修正した（#918）。併せて六件の vLLM アプリケーションイメージタグ（摩尔線程 musa5.2.0 と musa4.3.6、燧原 tops1.9.10 と tops1.10.6 が各二件）を記録し、崑崙芯 0.24.0 の期限切れリリース待ち変更履歴を整理した（#911）。

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

2.1 コンポーネントレベル検索は13回連続の平穏な調査期間：24時間以内にゼロヒット（09-16~09-17）

日付：2026-09-16 から 2026-09-17　情報源：Google News RSS（中国語・英語 33 組の検索キーワード、調査期間内はゼロヒット）

本期は FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、FlagAttention および「智源研究院 オープンソース」「BAAI open source」「衆智 FlagOS」などのキーワードで中国語と英語を半分ずつ組み合わせた 33 組の検索を実施したが、24 時間ウィンドウ内でヒットゼロであり、コンポーネント名に関連する直近の報道は依然として 09-15 10:16 の Open3D-PIMC オープンソースに関する英語稿と 09-14 の中国語ハードウェア稿である。これで連続 13 回目の静穏なウィンドウとなる。

既存の観察によれば、FlagOS の対外的な可視性は「月次リズム」を示す。すなわち、リリース、業界カンファレンス、チップ対応 Day0 の 3 種類のイベントのみが報道のピークをもたらし、リリース前のテスト期間はまさに静黙期にあたる。今サイクルの可視性ピークは 09-28 GA 前後に来ると予測される。HN Algolia の同期間クエリ（FlagOS / FlagGems / FlagScale / FlagTree）も同様に空であった。

2.2 FlagOS 2.2 タイムテーブルと RC2 リストの再確認：GA は 09-28 に確定（09-17 検証）

日付：2026-09-17（検証日）　情報源：2.2 リリーススケジュール、2.2 RC2 ソースコードリスト、milestone FlagOS 2.2

リリース成果物について完全な照合を行った。タイムテーブル：機能凍結 08-31、テストと安定化期間 09-01 から 09-24、GA 09-28。凍結ルールには例外チャネル（セキュリティパッチ、重大欠陥、CI ブロッカーは迅速チャネルを利用可能、TSC の承認が必要）が明記され、また卒業基準——実行可能なテスト計画がテスト期間内に通過した場合にのみ、FEP ステータスが「実装可能」から「実装済み」に移行する——も記載されている。

リスト：RC2 の 24 モジュール項目は L0 インフラ層（FlagTree は Triton 3.6 / 3.5 / 3.3 で 3 本に分割、FlagCX）、オペレータ層（FlagGems、FlagFFT、FlagSparse、FlagDNN、FlagBLAS、FlagTensor、FlagAudio、FlagAttention）、推論プラグイン層（FlagGems-vllm、FlagGems-sglang、Torch-FL、vllm-plugin-FL、sglang-plugin-FL）、学習層（TransformerEngine-FL、Megatron-LM-FL、FlagScale）、リリースとツール層（KernelGen、KernelGenBench、FlagRelease、圧縮器）をカバーする。バージョンでは FlagGems のみが rc2.post2 に到達し、その他は rc2.post1 である。FlagTree は 0.7.0rc2.post1+triton3.x という独自命名形式を踏襲している。

マイルストーン側：2.2 の 7 件の issue は現在すべて未クローズであり、期限日は 09-28 で、タイムテーブルと一致している。総合的に見ると、2.2 は「コード凍結、受け入れ最終段階」にあり、延期のシグナルは見られない。

2.3 地平線体系：地瓜機器人（D-Robotics）が 4 億ドルの C ラウンド資金調達を完了（09-17）

日付：2026-09-17　情報源：投資界報道

09-17、地瓜機器人（英語名 D-Robotics、地平線が孵化し、2024 年に独立したロボットソフトウェア・ハードウェア基盤企業）は 4 億ドルの C ラウンド資金調達を完了したと発表した。本ラウンドは未来資産がリードし、美団戦投、合肥国投、南山戦新投、璟泉資本などの産業・政府投資プラットフォーム、および凱輝基金、華美国際、広発信徳、超越摩尔、啓航投資傘下の芯創二期基金などの機関が共同でフォローオン参加した。既存株主の高瓴創投、五源資本、線性資本、黄浦江資本、テマセク傘下の Vertex Growth、Prosperity7、和暄資本、雲鋒基金、美団龍珠、九合創投などが継続的に追加出資した。

資金使途は具体的に記されている：旭日チップの全算力セグメント製品レイアウトを強化し、「データ収集—モデル訓練—シミュレーション検証—推論デプロイ」を貫く全チェーンソフトウェアプラットフォームを構築する。付随する運営データも情報量豊富である：2026 年上半期の売上高は前年同期比で数倍増加し、旭日シリーズチップの累計出荷は 800 万個を超え、エンボディドインテリジェンス事業は量産級出荷に突入し、フラッグシップ S600 は半年以内に 20 社以上のトップ顧客に採用され、エンボディドインテリジェンス顧客カバー率は 50% を超えた。

本レポートのテーマにとっての意義はソフトウェアスタック側の位置づけにある：地平線（そのロボット体系を含む）は FlagOS のメンバー単位の一つであり、そのチップとエッジプラットフォームは FlagOS のエッジ側およびエンボディドインテリジェンス方向の落点である。「全チェーンソフトウェアプラットフォーム」の建設方針は、FlagOS-Robo がロボット側で解決しようとする問題と高度に重なっており、今後そのソフトウェアプラットフォームが FlagOS コンポーネントを導入するかどうかに注目できる。

2.4 メンバー単位の資本面：沐曦中報が黒字転換、燧原上場初日に時価総額 1000 億突破、国産 GPU 半年報（09-16~09-17）

日付：2026-09-16 から 2026-09-17　出典：虎嗅 沐曦中報、新浪財経 燧原上場初日、雷峰網 国産 GPU 半期報告解読

メンバー機関の対外ナラティブは今期、資本側に集中しており、三点ある。沐曦の 2026 年半期報告が赤字から黒字に転換したが、本業は依然として投資段階にある（09-16）。燧原科技は上場初日の時価総額が千億元を突破し、09-17 の解読はその「市場化 GP プラス地方国有企業 LP」という株式構造に移った。雷峰網は 09-17 に国産 GPU 4 社の半期報告を総括し、その着地点は二級市場のバリュエーション耐性にある。同日の相場側では、摩尔線程、沐曦、寒武紀がいずれも大きく変動したが、これは市場情報であり生態系の動態ではないため、本レポートでは項目として収録しない。

明確にすべきは基準の境界である。上記の三条はいずれも FlagOS プロジェクトの進展の証拠とはなり得ず、これらはメンバー機関の経営と資金調達の状態の傍証にすぎない。今期の FlagOS に関連する技術的な動きは依然として GitHub 上にのみ現れており、これは連続する複数の調査期間に共通する特徴でもある。

3. メンバー機関の深掘り

3.1 海光：linalg と dtype の意味論の両端を同時に補完（09-16）

日付：2026-09-16　出典：FlagGems #5390 linalg_lstsq、FlagGems #5959 linalg_matrix_power、FlagGems #6351 nansum dtype

海光は今期、単一の大きな動きはなく、三本の並行した補完を行った。その一、linalg_lstsq が一度に三つのバックエンド（海光、沐曦、天数）をサポートしたことは、最小二乗法のような線形代数オペレータのマルチチップ実装がグループ単位で推進され始めたことを示す。その二、linalg_matrix_power が海光と天数をサポートし、行列関数シリーズに属する。その三、nansum の整型 dtype 昇格の修正が Nvidia、昇騰、沐曦、海光を同時にカバーし、int8/uint8 のテストケースを追加した。これは意味論の一貫性の性質の作業であり、修正したのは性能ではなく「同一のオペレータが異なるバックエンドで異なる型を返す」問題である。前の調査期間における海光の重点はツールチェーンとパッケージング環境の対応（gflags ヘッダーファイル、TLE ホワイトリスト、イメージ）にあったが、今期はオペレータと意味論に移り、方向の切り替えはその基礎環境の問題がほぼ収束したことを示している。

3.2 昇騰：MoE と線形アテンションに必要なオペレータが最も密な一本の線（09-16/09-17）

日付：2026-09-16 から 2026-09-17　出典：FlagGems #6324 swiglu、FlagGems #6325 grouped_matmul、FlagGems-vllm #789 compressor、FlagGems-vllm #788 chunk_gated_delta_rule_fwd

昇騰ラインは今期のコミットが最も密で、しかも現在の大規模モデル構造における二つのホットスポットに集中している。MoE 方向：swiglu 活性化（#6324）と grouped_matmul グループ化行列乗算（#6325）——前者は MoE 前向きフィードフォワードネットワークの活性化関数、後者はエキスパート並列の中核オペレータであり、この二つが揃うことで一層の完全な MoE 計算がオペレータライブラリ内でクローズドループを形成できることを意味する。線形アテンション方向：compressor（#789）と chunk_gated_delta_rule_fwd（#788）の二つの融合オペレータが推論プラグインリポジトリに入り、GDN 系線形アテンションのチャンク化前向き計算に対応する。あわせて flir における tile.to_tensor の意味論的整合（#74、昇騰 TLE ラインに関与）、および linalg_norm（#6355）、linalg_matrix_norm（#5670）の二つのノルム実装により、昇騰はオペレータ側において今期最もカバレッジが広い一家となっている。

3.3 達摩院玄鉄：推論プラグインが PPU CI に接続、MM/MV が NN/NT レイアウトをサポート（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：vllm-plugin-FL #518 PPU CI、FlagGems #6302 MM/MV レイアウト最適化、FlagTree #1190 PPU ベンチマーク

達摩院玄鉄（PPU）ラインは今期「テスト基盤 + 性能」の二本柱となっている。テスト側：vllm-plugin-FL は PPU を継続的インテグレーションに接続し（#518、新規プラットフォーム設定、環境準備スクリプト、イメージとプラットフォームテストリストを追加）、Torch-FL はオペレータテストゲートにおいてデフォルトブランチに依存せず PPU を明示的に検出し（#309）、PPU のテストリストは ppu.yml から読み込むように変更された（#305）。性能側：FlagGems は行列乗算と行列ベクトル乗算に対して NN と NT の二つのレイアウトのサポートと最適化を行い（#6302）、FlagTree は PPU ベンチマーク結果を更新し（#1190）、PPU と沐曦における tl.load/tl.dot の挙動を修正した（#1191）。あるプラットフォームを「オペレータが動く」から「CI 内で継続的に検証される」へと押し上げることは、可用性が個別事例から常態へと移行する分水嶺である。

3.4 摩尔線程：ネイティブ FP8 W8A8 MM と MUSA 回転位置エンコーディングがデバイス側へ回帰（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：FlagGems #6211 ネイティブ FP8 W8A8、Torch-FL #316 MUSA 回転位置エンコーディング、Torch-FL #298 RNG ブリッジ

三つの動きは同一の目標を指し示している——MUSA バックエンドを量子化推論と長コンテキストモデルにおいてフォールバックを減らすことである。オペレータ側ではネイティブ FP8 W8A8 行列乗算バックエンドを新規追加し（#6211）、対応側では複素数形式の回転位置エンコーディングオペレータをデバイス側で実行させ（#316）、従来発生し得た要素単位のホストへのフォールバックを回避した。安定性側ではベンダーオペレータモジュール上の乱数ブリッジを再バインドし（#298）、シードとストリームの一貫性を修正している。イメージ側では、build-infra が MUSA 5.2.0 と 4.3.6 の二つのアプリケーションイメージタグを記録し、0.24.0 rc2 の再ビルド用に未リリース変更ログを補完した（#913/#914/#915）。回転位置エンコーディングと乱数ブリッジのこの二項目は「目立たないが必ず通る」閾値項目に属し、クロスチップ推論精度が整合できるかどうかの一般的な分水嶺でもある。

3.5 沐曦：W8A16 RMSNorm と三箇所のルーティング回避（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：FlagGems #6326 W8A16 RMSNorm、FlagGems-Experimental #419 index_select、Torch-FL #306 slice.Tensor 回避

沐曦線の本期は「オペレータを1つ補い、3か所の経路を迂回する」を主とした。オペレータ側では W8A16 RMSNorm（#6326）を新規追加し、量子化精度を正規化層まで拡張した。試験リポジトリでは index_select の実装問題を修正し（#419）、depthwise 畳み込みのサポートを追加した（#391）。ルーティング側では3か所の迂回を行った。Torch-FL は slice.Tensor を FlagGems ルーティングから外して Qwen-Image-2512 の手動テストフローを通し（#306）、行列積を一部のシナリオで FlagGems ルーティングから迂回させ（1.7 のゲートと連動）、さらに FlagTree 側で linalg_solve_triangular のテスト参照実装を修正した（#6341）。迂回項目それ自体は成果ではないが、これらが1件ずつ名指しで記録されることで、後続バージョンの収束に根拠を持たせることができる。

3.6 昆仑芯：xCCL をベースイメージに組み込み、オペレータ修正バッチを投入（09-17）

日付：2026-09-17　情報源：build-infra #917 xCCL、FlagGems #6328 オペレータ修正、FlagGems #4540 topk_softmax スタブ

昆仑芯線の本期は3種類のアクションから構成される。イメージ側：ベースイメージに xCCL を組み込み（#917）、その containerfile を修正した（#918）——ベンダー通信ライブラリをベースイメージにプリセットすることは、クロスチップ通信がそのプラットフォーム上で実行時の外部アドオンに依存しなくなることを意味し、本レポート 1.10 における FlagCX ツールチェーンの改善方向と一致する。オペレータ側：一群の修正が同時に投入され、masked_fill、sinh、mish、hardswish、index_fill の5つのオペレータをカバーした（#6328）。topk_softmax には C++ ランチャー用のカーネルスタブを追加し（#4540）、解決済みの softmax_backward 次元スキップロジックを削除した（#4539）。エンジニアリング側：テストをコンテナ内で実行するように変更し（#6343）、推論プラグインで FlashAttention モジュールのインポート失敗後に残る状態を修正した（#528）。総合すると「テスト環境と依存関係を一度に整合させる」整備アクションである。

3.7 天数智芯：/dev/itrctl と iluvatar3.6 ベースラインワークフロー（09-17）

日付：2026-09-17　情報源：FlagGems #6376 /dev/itrctl、FlagTree #1197 iluvatar3.6 ベースライン、FlagGems #5390 linalg_lstsq

天数智芯線の本期は2件のインフラ変更に加え、オペレータを1件補完した。FlagGems の CI/CD 設定に /dev/itrctl デバイスノードを組み込み、パッケージング設定を更新した（#6376）。これはそのテスト環境がデバイス制御インターフェースにアクセスする必要があることを示している。FlagTree は iluvatar3.6 に FlagGems ベースラインとテストワークフローを追加した（#1197）。すなわち、当該バックエンドに比較可能な性能と正確性のベースラインを確立するものである。オペレータ側では海光、沐曦と linalg_lstsq のマルチバックエンド実装を共用している（#5390）。さらに build-infra は corex clang を破壊する古い環境変数を修正した（#901）。3件を併せて読むと、天数智芯の現在の段階は「CI ベースラインを立ち上げる」ことにある。

3.8 燧原：GCU300 を 0.24.0 レポートに記録し、2件のイメージ tag（09-16）

日付：2026-09-16　情報源：build-infra #910 GCU300 記録、build-infra #900 ゲートケース、FlagTree #1185 TLE テスト

燧原線は今期すべて構築と検証側に集中した。GCU300 の実行記録を vLLM 0.24.0 レポートに書き込み（#910）、ゲート禁止用例の実行結果とグラフモード下のブロッカーを記録し（#900）、tops1.9.10 と tops1.10.6 の2つのツールチェーンにそれぞれアプリケーションイメージ tag を1件ずつ記録した（#906/#907）。また FlagTree 側では、昇騰 TLE 線で散発的に失敗する融合 softmax 用例に ignore を追加した（#1185）——この種の「散発的失敗」はマルチチップ CI では通常、論理欠陥ではなく環境差異を意味するため、修正ではなくマークするのが現段階の合理的な選択である。燧原の資本面の動き（09-15 上場、09-16 初日で千億突破）はその工程上の重点を変えず、技術線は依然として GCU プラットフォームをマルチチップ検証マトリクスに組み込むことを主軸としている。

3.9 智源（牵头方）：ガバナンス自動化とバージョン番号の引き上げ（09-16/09-17）

日付：2026-09-16 から 2026-09-17　情報源：community 2.2 プロジェクト同期、build-infra #916

牵头方として、智源の今期の作業はコード成果物ではなくガバナンスに集中した。community はリリース優先度をプロジェクトビューに同期し、2.2 のエントリがリリース期間中継続的に可視化されることを保証した。build-infra はバージョン番号を引き上げ、イメージライン全体を 2.2.0 に向けた。2.2 タイムテーブルにおける「Release Manager がトラッキング issue でテストマトリクスを維持し、リリースプロセスに従って Go/No-Go を組織する」という役割定義と合わせて見ると、リリース機制は人手による突き合わせから「プロジェクトビュー + トラッキング issue + マニフェストファイル」の三種の神器駆動へと移行していることがわかる。GA まで 11 日、智源側の次の観察可能なシグナルは Go/No-Go の結論と各 FEP の受け入れ状態の遷移である。

四、総括とトレンド観察

  • 2.2 はリリース成果物凍結段階に入った：build-infra がバージョンフィールドを 2.2.0 に引き上げたことは、org 内で唯一のグローバルリリーススイッチである。以降、各モジュールの rc タグ付けは候補スナップショットに影響するのみで、バージョン番号を変更することはない。GA は 09-28 に確定し、テスト期間は残り約1週間である。
  • 工程品質線の比重が上昇：150 件のコミットのうち CI、テスト、修正類は合計で約四分の一（ci、test、fix で始まるコミットだけでも 23 件）。KernelGen の一括取り込みはエクスポート検査、テストマーク、基準アライメントなどの規範の定着を迫っている——拡容のボトルネックは「カーネルを書くこと」から「登記と受け入れ」へと移行しつつある。
  • マルチチップ可用性は「ルーティングと回避リスト」で推進：Torch-FL と vllm-plugin-FL の今期の主要な成果物は新機能ではなく回避エントリとゲートである。ベンダーカーネルが引き受けるオペレータにはすでに具名リストがある（MetaX のスライスオペレータ、MUSA の複素数回転位置エンコーディング、CUDA の FlagTune 欠位）。このリストの長さはマルチチップ再利用率の逆指標である。
  • 2つのオペレータ拡容の主線が明確：一つは量子化（W8A8、W8A16、FP8）で、行列積から正規化とサンプリングへ拡大。代表的なコミットは摩尔線程のネイティブ FP8 W8A8 MM と融合 Marlin MoE である。もう一つは MoE と線形アテンション（グループ行列積、swiglu、compressor、ブロックゲーティング Delta 規則前向き）で、昇騰線に集中している。
  • テスト基盤はプラットフォーム化へ収斂：達磨院玄鉄 PPU の推論プラグイン CI への接続、天数智芯の iluvatar3.6 ベースライン確立、FlagTree の統一バックエンド初期化インターフェースの抽出——三家の異なる形態の動きは同じ目標を指し示している。すなわち、各バックエンドが人手で通すのではなく、CI で継続的に検証できるようにすることである。
  • ニュース側は継続的に静寂、技術側はすべてコード上：これは連続13回目の平穏な調査期間であり、メンバー単位の対外的可視度は主に資本面（地瓜机器人 4 億ドル C ラウンド、沐曦中報、燧原上場）から来ている。次の報道ピークは 09-28 のリリースウィンドウと予想される。

付録：情報源チェック表

情報源 検証結果
GitHub org リポジトリ pushed_at（54 リポジトリ） 19 リポジトリがウィンドウ内にプッシュあり、すべて検証済み
GitHub commit search（committer-date） 150 件のウィンドウ内コミット、2ページで全量を取得、15 リポジトリに分布
GitHub 重点リポジトリのデフォルトブランチコミット FlagGems / build-infra / Torch-FL / FlagTree などを逐条再確認
GitHub tags と releases 各モジュールの最新タグはいずれも rc2.post1（FlagGems は rc2.post2）、新規リリースなし
community リリース一覧とタイムテーブル RC2 一覧 24 項目、2.2 タイムテーブルとマイルストーン状態を再確認済み
build-infra configs.yaml バージョンフィールドが 2.2.0 に引き上げ、パッチとファイル全文を取得済み
Google News RSS（33 組の中英語クエリ） ウィンドウ内ゼロヒット、直近のヒットは 09-15
HN Algolia ウィンドウ内ゼロヒット
智源社区（hub.baai.ac.cn） ウィンドウ内に FlagOS 関連の新規記事なし
投資界 / 智源社区 / 新浪財経 / 雷峰網 / 集微網 地瓜機器人 C ラウンドなどメンバー単位の項目を取得

完全な情報源リスト

**[23] FlagGems-vllm #749 FP8 可変長 FlashAttention-2 — https://github.com/flagos-ai/FlagGems-vllm/pull/749

4]** 雷峰網 国産GPU 4社の中間報告書解説 — https://news.google.com/rss/articles/CBMibkFVX3lxTE5UbVdtRXlOaHJHdGdBSkZ5SUVWbmJuUG84QWtOaWx3U0xjcmpXSW9hUFVLQ3BkdnljbGJBbUV2aVhPUEpnb1lDZmxyU3VVXzUxd