調査期間：2026-09-07 10:18 ～ 2026-09-08 10:18 北京時間 情報源：GitHub（org: flagos-ai 52 リポジトリの pushed_at + commit search 91 件全量を committer-date で検証 + デフォルトブランチの per-repo 再確認 + tags/releases/PR 詳細）、Google News RSS（中英 14 組のクエリ、プロキシ経由）、HN Algolia、Tavily/web 検索、FlagOS CSDN 公式アカウント（詳細は付録）

インデックス

    1. オープンソースプロジェクトの進展（GitHub 動向）
      • 1.1 FlagOS 2.2 RC1 収束：community が RC1 manifest をリリース、25 個のマニフェスト項目が初回 rc1.post1 検証 tag とともに集中的に打たれる（09-07）
      • 1.2 FlagScale 三連：KERV 具身投機的デコーディングの訓練/推論統合、Megatron-LM v0.18.2 アップグレード、CICD の訓練への集中（09-07）
      • 1.3 FlagGems-Experimental：KernelGen クロスバックエンドオペレータの一括同期取り込み + sync-to-kernelgen CI の実装（09-07）
      • 1.4 FlagGems メインリポジトリ：海光/天数の修正、QC fp8、外部コントリビュータとロールバック（09-07）
      • 1.5 FlagGems-vllm：達摩院玄鉄 PPU と海光専用 fused-MoE バックエンド（09-08）
      • 1.6 FlagBLAS：Ascend L2 ルーチンの連続マージ（CHER/CHER2/SSYR/CSYR）（09-07/09-08）
      • 1.7 FlagTree/FlagPrism：TLE マルチフィールド pipe、CI/CD 修正とデバッグ/プロファイリングコンポーネントのマージ（09-07）
      • 1.8 vllm-plugin-FL と FlagScale-Agent：FlagCX メトリクスコネクタ、Agent 信頼性リファクタリング（09-07/09-08）
    1. ニュース報道とエコシステム
      • 2.1 FlagOS コミュニティ「オープン AI コンピューティング」フォーラムが上海 KubeCon + PyTorch Conference China と同会場で開催（09-07）
      • 2.2 コンポーネントレベルニュースは 6 回連続の平穏な調査期間（09-07～09-08）
    1. メンバー企業の深掘り
      • 3.1 清微（tsingmicro）：vllm-plugin-FL に txda バックエンドラインを新設、vLLM 0.24.0 メインラインとともにマージ（09-07）
      • 3.2 天数智芯（iluvatar）：0.20.2 決定性技術路線の確定——flag_gems GEMM ファミリ全体のブラックリスト（09-07）
      • 3.3 沐曦（metax）と寒武紀（cambricon）：sglang 0.5.18 デリバリーラインの拡大（09-07/09-08）
      • 3.4 外部エコシステム：昇騰の検証記録と from-scratch 修正、崑崙芯 KernelGen オペレータ、sunrise 新バックエンドの接続（09-07/09-08）
    1. まとめ
  • 付録：完全な情報源リスト

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

調査期間総覧：org 内 52 リポジトリのうち 30 が調査期間内にプッシュがあり、commit search は調査期間内のコミット 91 件を検出。デフォルトブランチへの実質的なマージは community、FlagScale、FlagGems、FlagGems-vllm、FlagGems-Experimental、FlagBLAS、FlagTree、FlagPrism、FlagCX、Megatron-LM-FL、TransformerEngine-FL、vllm-plugin-FL、build-infra、FlagScale-Agent など 14 リポジトリに集中し、最近で最も活発な調査期間の一つとなった。本調査期間の最大の出来事は FlagOS 2.2 RC1 の正式なブランチ切りである：09-07 11:11 に community が release/2.2/release-2.2-rc1.yaml をマージ（+252 行、25 個のマニフェスト項目）、その後 11:22～11:33 の間に少なくとも 12 リポジトリが初回 rc1.post1 検証 tag を集中的にプッシュした——昨日のレポートで「次のリリースシグナルは依然として community マニフェストリポジトリの動きに注目」という予測が調査期間内に的中し、しかも動きは予想以上に大きかった：version bump ではなく、RC0→RC1 のリリースパイプライン切り替えである。コンポーネントコード側は 2.2 テスト安定期間の特徴を継続：FlagGems 系オペレータマトリクス（fused-MoE 新バックエンド、Ascend L2、KernelGen 一括同期）、FlagScale 訓練スタック（Megatron v0.18.2、KERV）、コンパイラとプラグイン層の検証的修正。

1.1 FlagOS 2.2 RC1 収束：community が RC1 manifest をリリース、25 個のマニフェスト項目が初回 rc1.post1 検証 tag とともに集中的に打たれる（09-07）

情報源：community PR #107（703ea2184c、wbavon、09-07 11:11 マージ）、release-2.2-rc1.yaml、FlagSparse v0.3.0-rc1.post1 release（09-07 11:27 公開）、2.2 タイムテーブル schedule_CN.md

  • manifest マージ：09-07 11:11、community リポジトリに #107 がマージされ、release/2.2/release-2.2-rc1.yaml（252 行）を追加するとともに、.github/workflows/release-branch-tag.yml のデフォルトマニフェストを 2.2/release-2.2-rc0.yaml から release-2.2-rc1.yaml に切り替えた。manifest は vcstool 形式を採用し、L0 基盤（flagtree×3 本の Triton ライン、flagcx）→ L1 計算ライブラリ（flaggems/flagfft/flagsparse/flagdnn/flagblas/flagtensor/flagaudio/flagattention/flaggems-vllm/flaggems-sglang）→ L2 フレームワーク対応（torch-fl、vllm-plugin-fl×2、sglang-plugin-fl、transformerengine-fl、megatron-lm-fl、flagos-compressor）→ L3 アプリケーションツール（flagscale、kernelgen、kernelgenbench、flagrelease）をカバーし、全 25 エントリ、22 リポジトリ。
  • 主要バージョンアンカー：flagcx v0.14.0-rc1.post1、flaggems v5.4.0-rc1.post1、flagscale v2.1.0-rc1.post1、kernelgen v2.2.0-rc1.post1、flagtree は 3 ライン統一で 0.7.0rc1.post1+triton{3.6|3.5|3.3}、vllm-plugin-fl は 2 ラインに分割（main は vLLM 0.24.0 に追随 → v0.3.0-rc1.post1、release/0.2 は vLLM 0.20.2 に追随 → v0.2.2-rc1.post1）。コメントには rc0→rc1 のエンジニアリング上の進展も記録されている。FlagGems master は setuptools_scm only-version（上流 #5885）をマージ済みで、post tag が master に載ってもビルド失敗を引き起こさなくなったため、rc1 では rc0 のときのような cherry-pick／tag 移動による緊急対応は不要となった。
  • rc1.post1 tag の波：11:11 の manifest マージ後、11 分以内に少なくとも 12 のリポジトリが集中的にプッシュ（FlagCX 11:22、FlagFFT 11:23、FlagSparse 11:27 に release 公開、FlagTensor/FlagAttention/FlagGems-sglang/FlagAudio 11:28、Torch-FL 11:29、FlagOS-Compressor 11:31、KernelGen 11:32、KernelGenBench/FlagRelease 11:33）し、manifest の各エントリと一対一で対応している。これらのリポジトリのデフォルトブランチはいずれも調査期間内に実質的なコードのマージはなく（tags API で rc1.post1 の存在を再確認済み）、すなわち純粋な tag の波である。manifest 冒頭のコメントにはバージョン進化のルールが明記されている。各ラウンドの検証通過ごとに増分 tag を打ち（rc1.post1 → rc1.post2 → …）、version フィールドに書き戻す。.post1 は「初回ラウンド検証通過」の印である。

解説：これは FlagOS 2.2 リリースサイクルの3番目のマイルストーン指標である——08-31 の機能凍結（FEP ゲート閉鎖）、09-01 のテスト安定化期間への移行（バグ修正のみ受け入れ）、09-07 の RC1 manifest + 初回検証 tag 波による、rc0 統合段階の検証結果が rc1 ベースラインとして固定化されたことの宣言。タイムテーブルは 09-01～09-24 がマルチチップマトリクステスト期間、09-28 GA を示しており、RC1 の切れ目は rc0 より7日遅く、「機能凍結→約1週間の統合検証→rc1 固定化」というリズムの想定に合致している。注目すべき点は2つ：第一に、manifest のエントリ粒度が rc0 と比べてより細かくなっていること（FlagTree の3本の Triton ライン、vllm-plugin の2本の vLLM ラインが個別に記載）、これは 2.2 のデリバリマトリクスが確かにマルチコンパイラ／マルチフレームワークバージョンの組み合わせをカバーしていることを示す；第二に、FlagGems 上流による post-tag ビルド問題の根本的解決（only-version）が、rc サイクルのビルドノイズをプロセスから排除したこと——RC1 以降の post2/post3 イテレーションはより速くなるだろう。今後の観察にとっての意味：次のシグナルは各コンポーネントの rc1.postN のインクリメント（マルチチップマトリクス検証のラウンドごとの通過に対応）と 09-24 前後の RC-final/GA の切れ目である；RC1 期間中もコンポーネントのデフォルトブランチにはバグ修正をマージ可能であり、コミュニティチャレンジコンテストなどの外部コントリビューションフローは影響を受けない。

1.2 FlagScale 三連：KERV 具身投機的デコーディングの訓練／推論統合、Megatron-LM v0.18.2 アップグレード、CICD の訓練への集中（09-07）

情報源：FlagScale PR #1278（zhengzihaoPKU、09-07 14:24 マージ）、#1284（b5741d04、22:00）、#1283（b3708f0f、10:34）、Megatron-LM-FL #109（e15cb692、21:57）

  • KERV 統合（#1278、09-07 14:24）：FlagScale が KERV 具身投機的デコーディング（embodied speculative decoding）の訓練・推論統合をマージ——OpenVLA verifier の LoRA／全パラメータ訓練設定、KERV draft データ生成と drafter 訓練、LIBERO 推論設定を新規追加；プロセス内で KERV/OpenVLA の公開 Python エントリに適合（FlagScale が統合オーケストレーション、ネストされたランチャーを生成しない）；KERV 制御ランタイムを内蔵（バッチ候補生成、検証ツリー構築、寛容な受理、動的閾値調整、Kalman 補完）；BF16 推論 profile は公開 runtime_opt パッケージ内の14個の KERV オペレータを直接採用；モデル非依存の単体テスト33個を添付（CI は checkpoint をダウンロードせず、MuJoCo/LIBERO を起動しない）。
  • Megatron v0.18.2 アップグレード（#1284 + Megatron-LM-FL #109、09-07 夜）：FlagScale は 22:00 に上流依存を Megatron-LM v0.18.2 へアップグレード；対応する Megatron-LM-FL プラグインリポジトリも 21:57 に同一ベースラインへ同期アップグレード（#109）。2つの訓練スタックリポジトリが同じ夜にバージョンを揃えた、協調アップグレードである。Megatron-LM-FL には他に2件の CICD コミット：#140（18:29）は TE-FL prepare checkout にリトライを追加、#128（15:01）は TE-FL の増分ビルドとランタイム統合を実施。
  • CICD の訓練への集中（#1283、10:34）：FlagScale は inference と serve の2本の CI パイプラインを削除し、「focus on training」——訓練フレームワークのデリバリ境界が狭まり、推論側を vllm-plugin-FL/sglang-plugin-FL が担うという分業がさらに明示化された。

解読：3 件のコミットはそれぞれ FlagScale の 3 方向のシグナルに対応する。KERV が最も注目に値する 1 件である：FlagOS 訓練スタックが具身／ロボティクス戦略の投機的デコードをカバーし始めた——KERV はロボット VLA デプロイ向けの投機的デコードフレームワークであり（OpenVLA を verifier とし、draft モデルが先行し、検証ツリー＋Kalman で制御の受理率を補完する）、FlagScale はこれを「訓練可能（verifier/drafter）＋推論可能（LIBERO）＋評価可能」な一級市民とした。これは FlagOS-Robo の具身知能ツールチェーンとしての位置づけと呼応し、また 2.2 テスト期間中の「バグ修正のみ受け入れ、新機能は入れない」という凍結ルールと対照をなす——KERV PR は 08-30 に作成され、09-07 にマージされており、ちょうど機能凍結（08-31）の際に踏み込み、すでに先行実装されていた。これは凍結前に進入した存量機能の收尾であり、凍結後に新規で開かれたものではない。Megatron v0.18.2 の両リポジトリが同じ夜に同期したことは、2.2 RC1 ベースラインにおいて訓練スタックの依存バージョンがすでに固定されたことを示す；CICD が訓練にフォーカスすることは、「FlagScale＝訓練、vllm/sglang プラグイン＝推論」という分業をエンジニアリングパイプラインに書き込むことである。

1.3 FlagGems-Experimental：KernelGen クロスバックエンドオペレータの一括同期取り込み＋sync-to-kernelgen CI の落地（09-07）

情報源：FlagGems-Experimental commits（14:31 CICD 3 件＋16:27~16:58 一括 60+ 件）、CICD sync-to-kernelgen（4973e875）

  • CI 先行（14:31）：103yiran が CICD(.github): add sync to kernelgen、docs: add ci doc および .github の調整をマージ——FlagGems-Experimental と KernelGen リポジトリ間に自動同期ワークフローが構築された。
  • 16:58 一括取り込み：同一秒タイムスタンプ（16:58:04~05）で 60+ 件のコミットが着庫し、すべて [KernelGen][ベンダー] プレフィックスのオペレータコミットであり、クロスバックエンドでカバーする：Kunlunxin（digamma、arctan minimax 最適化、bernoulli）、Metax（linalg_cholesky/log_normal_/erfinv/gcd_/lgamma などの専用数学オペレータ＋adaptive_max_pool3d_backward＋special_shifted_chebyshev_polynomial_w＋登録名修正）、Iluvatar（addmm_、nonzero_numpy 混合二遍 kernel 最適化）、Hygon（amp_foreach_non_finite_check_and_unscale）、thead（lcm/lcm_ ベンダー専用化）、MThreads（linalg_cholesky）、Nvidia（special_i0/softmax/xlog1py/shifted_chebyshev_t/spherical_bessel_j0/split_with_sizes/grid_sampler_3d などの新オペレータ）、さらに上流 FlagGems から同期された履歴コミット（Apache 2.0 ヘッダ補完、CI 修正、FlagTune topk 設定、ENFLAME 更新など、PR 番号 #3540/#4646/#4829/#4873 などは FlagGems 上流を指す）。貢献者には yzw1128（FlagGems-sglang 賽事戦隊の同一アカウント）、chx7514、ZhiwenDeng、KK、Dingxingdi、bwbwzzz などが含まれる。

解説：FlagGems-Experimental は KernelGen オペレータフローの中継/実験リポジトリであり、本期間の「CI 同期ワークフロー + 一時的な大量一括マージ」の組み合わせは、KernelGen のクロスベンダーオペレータ産出が「バッチ同期」方式で実験リポジトリから KernelGen メインリポジトリへ流れていることを示している（sync-to-kernelgen がパイプラインそのもの）。このバッチのオペレータのセマンティック分布は、KernelGen の現在の主攻面をよく示している——special 関数群（i0/softmax/xlog1py/ベッセル/チェビシェフ多項式など）が Nvidia/Metax バックエンドで密集して出現しており、数学関数オペレータの自動生成のカバレッジが拡大していることを示す。一方、Kunlunxin/Iluvatar/Hygon/thead/MThreads の項目は主に「ベンダー専用化」（汎用 kernel を特定のツールチェーン/命令セット向けに書き直す）であり、マルチチップ適応のラストワンマイルに対応する。注目すべきは thead（達摩院玄鉄）の項目と lcm のような整数オペレータ——玄鉄側の KernelGen サポートは引き続き強化され続けている。yzw1128 は同時に競技 PR と KernelGen オペレータの両方で活躍しており、外部コントリビュータがすでに競技チャネルと KernelGen チャネルの両方で産出していることを示している。

1.4 FlagGems メインリポジトリ：海光/天数の修正、QC fp8、外部コントリビュータとロールバック（09-07）

情報源：FlagGems commits 11:34~20:39、#6040 hygon BLOCK_M fix、#6043 revert FlagTune、#5341 SiliconFlow cauchy

  • 海光修正（15:23 #6040）：Hygon バックエンドの flash attention が ViT encoder 推論を実行する際の KeyError: 'BLOCK_M' を修正——量子化設定がブロックサイズを取得するパスが特定の形状で空になる問題。
  • 天数最適化（17:27 #5341）：[SiliconFlow] Optimize cauchy on Iluvatar——SiliconFlow（シリコンフロー）名義で参加し、Iluvatar 上で cauchy オペレータ（SSM 系畳み込み）を最適化し、併せてクロスバックエンドテストを修正。
  • QC fp8（14:04、Experimental と同一 commit c9bd738d）：[QC] Optimize GEMM(fp8)——fp8 GEMM 最適化がメインリポジトリと実験リポジトリの両方に適用。
  • エンジニアリング面：18:07~18:09 に CI/テストのコミット 3 件（approved operator tests の別名、and_scalar pytest マーカー）；17:37 AddMM 公共 API テスト（上流の beta-zero 修正後）；18:09 bucketize kernel が input 末尾を越えて読み取る境界外問題を修正（#5231、Truong Vu）；20:39 Hygon linalg_solve_triangular を更新（#5943）。
  • ロールバック（15:54 #6043）：前日にマージされた [FlagTune] Add multi-platform Mul cost model support (#5762) を Revert——FlagTune のマルチプラットフォーム乗算コストモデルが全体として巻き戻された。

解説：メインリポジトリの期間内 11 件のコミットは典型的な「テスト安定期」の形態を示している：新規アーキテクチャ級の機能はなく、すべてバックエンドの正確性修正（Hygon ViT シナリオの BLOCK_M、bucketize の境界外）、単一オペレータの性能最適化（QC fp8、Iluvatar cauchy、Hygon linalg）と CI/テスト基盤である。SiliconFlow 名義の Iluvatar cauchy 最適化はマークに値する——これは中国科学院 AlphaSparse チーム（FlagSparse）に続き、さらに一社の外部企業が直接 FlagGems にベンダーオペレータを貢献したものであり、エコシステム共築の「外部贡献」リストが長くなりつつある。FlagTune のコストモデルが revert されたことは、チューナー側の変更が RC 期には厳格に審査されることを示している：受け入れ基準に合わなければむしろロールバックするという、2.2 の「bug 修正のみ受け入れ」という凍結規律と一致する。

1.5 FlagGems-vllm：達摩院玄鉄 PPU と海光専用 fused-MoE バックエンド（09-08）

出典：FlagGems-vllm PR #696（09-08 09:54 マージ）、#746（09:56）、#747（10:05）

  • #696 達摩院玄鉄 PPU バックエンド：_thead バックエンドを新規追加。T-Head PPU（ZW810E、compute_89 / AIU MMA 命令）向けに純 Triton の fused-MoE（fused_experts_impl）を実装。既存の _metax/_mthreads ベンダーバックエンドをモデリング：thead 版 moe_align_block_size、転置キャッシュ重み（FlagGems から同期した permute_copy を再利用）、per-tile moe_sum リダクション。本番パスは deep_gemm に依存しない。大 M GEMM スタイルの kernel はトークン数で段階分け（MOE_GEMM_TUNING_MIN_TOKENS、gemm1/gemm2 でセグメント化）。
  • #746 海光専用 fused-MoE：Hygon DCU（gfx936）向けに専用の fused_experts_impl を実装。実機の Qwen3.6-35B-A3B 形状で vLLM-HCU Triton ベースラインに対してチューニング：完全な fused_moe パイプライン（moe_align→GEMM1→SiLU→GEMM2→moe_sum）、Hygon 専用 align パス（3-kernel の小バッチ変種で、HCU バックエンドがコンパイルできない TLE 協調 kernel を回避）。M による段階分け（M≤16 は非融合シングルパス、TP4 BK=64、mid-M は BK128、TP4 大 M は num_warps=16、TP1 の M≥8192 は非融合など）。
  • #747 KMCompiler：persistent_topk のテスト/ベンチマークを vLLM native op 非依存環境で実行可能に変更（KMCompiler 生成パスが vLLM 依存から脱して自テスト可能に）。

解読：2 つの fused-MoE ベンダーバックエンドが同日にマージされた（間隔 2 分）。いずれも「特定チップの命令セット向けにスケジューリングを手書きする」深度適応である。玄鉄 PPU-ZW810E は AIU MMA（compute_89 級）で、海光 DCU は gfx936 専用の段階分けを用い、かつ HCU がコンパイルできない TLE kernel を意図的に回避している——後者は KernelGen/FlagGems 系における「TLE 協調 kernel が一部の国産ツールチェーンではコンパイル不可」という既知の境界と一致する。海光の fused-MoE は実機の Qwen3.6-35B-A3B 形状でチューニングし、vLLM-HCU Triton ベースラインに直接対標していることから、このバックエンドが実運用の 35B 級 MoE 推論負荷を指向していることが分かる。fused-MoE は現在の推論スループットの鍵となるオペレータであり、vllm プラグイン層におけるそのチップ単位の専用化は、2.2 テスト期間の「オペレータレベルの性能磨き込み」を最も直感的に示すサンプルである。

1.6 FlagBLAS：Ascend L2 ルーチンを連続マージ（CHER/CHER2/SSYR/CSYR）（09-07/09-08）

出典：FlagBLAS PR #96（16:35）、#93（17:16）、#97（18:05）、#98（19:31）、#99（09-08 10:16）

  • 調査期間内に FlagBLAS のデフォルトブランチで 9 件のコミット。主線は Ascend バックエンドの L2 ルーチン拡張：Ybanana252 が順に CHER（複素 Hermitian rank-1 更新、#97 18:05）、CHER2（rank-2、#98 19:31）、SSYR/CSYR（実/複素対称 rank-1 更新、#99 は 09-08 10:16 にマージ）、および L2 三角（#93 が 17:16 にマージした l2-triangular ブランチ）をコミット。いずれも Ascend 入力構築のテストドキュメント（test(her2): document Ascend input construction）を伴う。
  • CI 修正 2 件（#96、16:35 マージ、bin913）：nvidia ラインの flagtree を 0.6.1 に揃え（FlagGems と同バージョン）、uv pip インストールに切り替えて triton が利用可能であることを保証。

解説：FlagBLAS の Ascend L2 カバーは急速に閉じつつある——CHER/CHER2/SSYR/CSYR はいずれも rank-1/rank-2 更新系ルーチンであり、09-05 レポートで記録された DCU/L2 主線と「ルーチンごとに補完する」リズムを形成している（これ以前に ascend の L2 三角族もマージ済み）。3 日連続の夕方＋翌朝にそれぞれ一批ずつマージされていることは、Ascend の L2 受け入れがバッチ・パイプライン方式であることを示している。CI 側で nvidia flagtree を 0.6.1 にピン留めしたこと（FlagGems と一致）は、複数リポジトリ間の依存関係を揃える通常の作業である。manifest によれば、flagblas は L1 計算ライブラリに属し、RC1 後もバグ修正と新規ルーチンをマージ可能である——この Ascend ルーチン補強ラインは GA まで継続する可能性が高い。

1.7 FlagTree/FlagPrism：TLE マルチフィールド pipe、CI/CD 修正とデバッグ/プロファイリングコンポーネントのマージ（09-07）

情報源：FlagTree #1110（12:29）、#1104（15:31）、#1115（15:41）、FlagPrism PR #8（10:47 マージ）、FlagPrism README

  • FlagTree（デフォルトブランチへの 09-04 以降初の実質的マージ）：12:29 #1110 [BUILD][CD] が DEPENDS IncGen と nvidia3.7 デリバリワークフローを修正；15:31 #1104 [TLE][MTHREADS] がマルチフィールド pipe とマルチロール ws をサポート（TLE の摩尔線程バックエンドにおける通信/パイプライン抽象化の拡張）；15:41 #1115 [CI][Nvidia] が nvidia3.6 ワークフローの並行グループを最適化。09-08 09:58 のプッシュは PR ブランチのアクション。
  • FlagPrism（新規リポジトリの推進）：10:47 に #8「Add profiler and debugger support」をマージ。FlagPrism は FlagTree のオプションのデバッグ・プロファイリングコンポーネントを集中的に維持管理するリポジトリである：flagtree.debugger（デバッガコンパイラプラグインが libtriton にリンクされ、実行時の転送/デコードは独立した _native 拡張で行われる）と flagtree.profiler（Python パッケージ＋ネイティブランタイム＋CLI）；flagtree-debugger/flagtree-profiler は個別に wheel をリリースしなくなり、FlagTree は third_party/FlagPrism submodule 方式で消費し、pip wheel . で Debugger/Profiler を含む単一の FlagTree wheel を一度にビルドする。

解説：FlagTree は rc0 検証期間中（09-04 の清微バックエンドマージ後）、デフォルトブランチが 3 日間静かであり、本調査期間のマージはビルド/デリバリワークフローの修正と TLE バックエンド能力に集中している——nvidia3.7 デリバリフロー、IncGen 依存関係、摩尔線程 TLE マルチフィールド pipe はいずれも「マルチチップ CI/CD マトリクスを安定して走らせる」ためのエンジニアリングである。FlagPrism のマージはコンポーネントアーキテクチャ上のイベントである：FlagTree のデバッガ/プロファイラは「独立パッケージ」から「メインリポジトリ submodule＋単一 wheel」へと収束し、RC1 manifest では flagtree の三線バージョンが一致しており（0.7.0rc1.post1+tritonX）、Prism の #8 がフリーズ前に取り込まれれば 2.2 リリースに伴って、デバッグ/プロファイリング能力は FlagTree 単一 wheel に内蔵される——オペレータ開発者にとっては実質的な体験改善である（デバッガのコンパイルプラグインは libtriton 内にあり、プロファイラ CLI はワンストップで利用可能）。

1.8 vllm-plugin-FL と FlagScale-Agent：FlagCX メトリクスコネクタ、Agent 信頼性リファクタリング（09-07/09-08）

情報源：vllm-plugin-FL #418（489d22d5、14:28）、FlagScale-Agent commit 9e308807（09-08 09:12）

  • vllm-plugin-FL #418（09-07 14:28）：feat(flagcx connector): Prometheus KV-transfer metrics + port #315 from release/0.2——vLLM プラグインと FlagCX のコネクタに Prometheus の可観測指標（KV 転送）を新規追加し、release/0.2 ブランチの #315 修正をメインラインへバックポート。
  • FlagScale-Agent（09-08 09:12、caozhou）：feat: agent reliability overhaul——FlagScale-Agent に実行時思考予算上限（runtime thinking cap）、推論認識リトライ（reasoning-aware retries）、時間予算認識（time-budget awareness）、ヘルスモニタリング（health monitoring）を追加。FlagScale-Agent は大規模モデル訓練オーケストレーション向けのエージェントコンポーネントであり、今回は全体的な信頼性の再構築である。

解読：いずれも「FlagOS の上位ツールを無人長時間運用により適したものにする」エンジニアリングである。FlagCX コネクタの Prometheus 指標はマルチカード KV 転送の状態を運用担当者に可視化する（vLLM 0.20.2 ラインの #315 修正をメインラインへ同期し、両ラインの一貫性を維持）。FlagScale-Agent の「思考予算／リトライ／時間予算／ヘルスモニタリング」の四点セットは典型的なエージェントのエンジニアリング強化であり、長時間訓練オーケストレーションにおいてエージェントループが制御不能になったりサイレントにハングしたりするのを防ぐ。2.2 テスト期間のマルチチップマトリクス走行テストにより「可観測＋自己修復可能」なオーケストレーション層への需要が高まっていることを踏まえると、こうした強化はまさに時宜にかなっている。

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

2.1 FlagOS コミュニティ「開放 AI 計算」フォーラムが上海 KubeCon + PyTorch Conference China と同会場で開催（09-07）

情報源：FlagOS CSDN 公式アカウント公告（2026-09-07 09:57 公開）

  • 09-07 午後、衆智 FlagOS コミュニティ主催の『開放 AI 計算：多元異種ハードウェアに向けたオープンソースソフトウェア新エコシステムの構築』フォーラムが上海 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大会と同会場で開催された。登壇者は北京智源人工智能研究院、上海人工智能実験室、PyTorch 基金会、SGLang コミュニティなどから集まり、議題は開放 AI システムソフトウェアスタックの技術路線と協業モデルを中心とした。CSDN 公式アカウントのページではライブ配信／アーカイブを提供している。
  • 当該公告は 09-07 09:57（前回調査期間の終端に近接）に公開され、フォーラム自体は同日午後（今回の調査期間内）に開催された。昨日のレポートでは CSDN 公式アカウントに更新なしと記録していたが、本項目は調査期間内のエコシステムイベントとして追記するものである。

解読：フォーラムを PyTorch Conference China / KubeCon China の上海会場で開催することは、「オープンソースコミュニティの横断的協業」における FlagOS の継続的な動きである。PyTorch 基金会、SGLang コミュニティと同席し、議題は FlagOS の主張の中核である「マルチチップ統一ソフトウェアスタック」を直接指し示している。こうしたイベント自体はコンポーネントのコード動向を生み出さないが、RC1 ブランチ分岐の時期にコミュニティ層が国際的な大会を借りて開放計算のナラティブを増幅していることを示している。今後、このフォーラムから公開のロードマップやホワイトペーパー類の成果物が出るかどうかに注目したい。

2.2 コンポーネントレベルのニュースは 6 期連続で平穏な調査期間（09-07〜09-08）

情報源：Google News RSS（中英 14 組、プロキシ経由）、HN Algolia、Tavily/web 検索（詳細は付録）

  • gnews 中英組み合わせ（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/KernelGen/FlagOS 2.2 when:3d~30d など）期間内ヒットゼロ；唯一の FlagGems ヒットは 09-01 智源コミュニティの Day0 旧記事転載（既報）。智源研究院 when:7d は 58 件ヒット、すべて智源コミュニティブログ転載（姚期智氏の入学式挨拶、AI プログラミング雑談など）とギャンブル SEO テンプレートノイズで、FlagOS 関連内容はなく、バッチ全体を除外。天数智芯/沐曦の検索ヒットは中間決算、株価、香港株の異動など商業ニュースが中心（FlagOS ソフトウェアエコシステムと直接の関連なし、収録せず）。
  • HN Algolia（FlagOS/FlagGems/flagos-ai/BAAI）関連ヒットなし；Tavily で検索された新規内容は 2.1 フォーラム告知のみ。
  • 直近 3 日のトレンド（GitHub org pushed の裏付け、エンジニアリング側は極めて活発）：09-07 11:11 FlagOS 2.2 RC1 manifest ブランチ分岐 + 初回 rc1.post1 tag 波（本日 1.1）；09-07 FlagScale KERV 具身投機デコーディング統合と Megatron v0.18.2 両リポジトリ整合（1.2）；09-07/09-08 build-infra 連続 13 件のデリバリ記録（天数智芯 0.20.2 确定性確定、沐曦/寒武纪/昇腾 sglang 0.5.18 ライン、三参照）；09-07 夜 FlagBLAS Ascend L2 ルーチン一括マージ（1.6）；09-08 午前 FlagGems-vllm 玄鉄/海光 fused-MoE バックエンドマージ（1.5）。

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

3.1 清微（tsingmicro）：vllm-plugin-FL に txda バックエンドラインを新規追加、vLLM 0.24.0 メインラインに合わせてマージ（09-07）

情報源：vllm-plugin-FL PR #447（tsingmicro-public-e、09-07 16:58 マージ、base: main）

  • PR #447 は清微公式アカウント tsingmicro-public-e によりコミット・マージ（PR Category: Vendor）：vllm-plugin-FL に txda ベンダーコード、vLLM==0.24.0 対応（main ライン）を追加し、txda 関連バグを修正。マージ時刻 09-07 16:58、RC1 manifest における vllm-plugin-fl main ラインの vLLM 0.24.0 ピン設定と一致。
  • build-infra runner 側の清微ラインは既に整備済み（tsingmicro-tsm260610: [self-hosted, tsingmicro]、本調査期間前に登録済み）。

解釈：清微はこれまでに FlagTree バックエンドマトリクスへ参入済み（09-05 レポート：300 ファイル規模の接続、TLE-DSA データフローアーキテクチャ）。今回は推論プラグイン側の最初の版図——vllm-plugin-FL のベンダーバックエンド名簿に txda（vLLM 0.24.0 ライン）が新規追加。清微は FlagOS メンバー単位の中でも比較的新しいチップベンダーであり、その適応経路は明確な「コンパイラ（FlagTree）先行、推論フレームワーク（vLLM プラグイン）追随」という順序を示している。txda バックエンドのマージ方式（ベンダー自身が PR を提出し、自ら保守）もメンバー単位の深い関与の好例である。

3.2 天数智芯（iluvatar）：0.20.2 确定性技術路線が確定——flag_gems GEMM ファミリ全体をブラックリスト化（09-07）

情報源：build-infra #776/#777（19:23/19:24、イメージ tag 登録）、#779（20:21、docs 確定）、vllm-plugin-FL PR #450（進行中、09-07 16:59 更新）

  • イメージ登録（#776/#777、09-07 19:23/19:24）：iluvatar-corex4.4.0 と corex4.5.0 が同日に vllm 0.20.2 app イメージ tag 2.1.2-0.2.1_g16e8655.d20260907 を登録（plugin ソース指紋 g16e8655、両スタック同一 tag）——前日 g71b9482.d20260906 指紋からの更新で、決定論的ソリューションのイテレーション後の新規デリバリに対応。
  • 技術路線の確定（#779 docs、20:21）：iluvatar 0.20.2 の最終的な決定論的路線は flag_gems GEMM ファミリ全体のブラックリスト（linear/mm/mm.out/addmm/addmm_/addmm.out/bmm/bmm.out → native corex ixblas へフォールバック）。根因の記述は非常に完全：vllm_fl の flag_gems.enable() は aten::linear などを flag_gems triton linear_kernel にハイジャックする；当該 kernel は flagtree でコンパイルされると live エンジン内で launch ごとに非決定（~1-2 bf16 ulp、offline では決定、temp=0 の長距離デコードでほぼ並列のサンプリング帯で反転）、一方同一ソースの kernel をベンダー corex triton でコンパイルすると bitwise 決定（== native）。ブラックリストはファミリ全体で除外する必要がある（native linear は addmm に降格するため、linear だけ除外しても依然ハイジャックされる）。GEMM を native に通した後、F/T 両パスとも 30/30 temp=0 で決定、しかもスループットは逆転（F 14.0 tok/s vs flag_gems linear 12.3、native ixblas は flagtree コンパイルの flag_gems kernel より高速）；silu_and_mul は flagos を維持（GEMM native 下ではもはや反転しない）。コンパイラ差異が分水嶺：同一の flag_gems ソース kernel で、flagtree コンパイルは非決定、corex triton コンパイルは決定——上流への引き継ぎとして FlagGems #6054-6057 を起票済み（linear/mm/addmm/bmm）。4.4.0 T パスは依然 VLLM_FL_USE_FLAGGEMS_ATTN=1 が必要（corex triton 3.1 は vLLM ネイティブ attention をコンパイル不可）；4.5.0 T（corex triton 3.2）は env 不要；既知の非ブロッキング制限は 4.5.0 T のコールドエンジン初回リクエストでの反転。
  • PR #450 は依然進行中：iluvatar 0.20.2 の plugin 側パッチ（symm-mem stub guard、PyTorch sampler フォールバック、base release/0.2）は 09-07 16:59 の更新後も未マージ。

解釈：この路線は 09-05 以降の天数智芯デリバリ叙事の三度目の転換収束である：09-05 env 注入方案 → 09-06 夜 revert、plugin 設定 silu_and_mul ブラックリストに変更（#450）→ 09-07 夜に 30/30 の実測で GEMM ファミリ全体のブラックリストに確定、しかも今回は「決定性 + 性能」のダブルウィン（flagtree コンパイル路径を除外した方がむしろ高速）。ドキュメントは根因をコンパイラ分水嶺に置いている——同一 kernel ソースが flagtree コンパイルでは launch ごとに非決定、ベンダー triton コンパイルでは bitwise 決定という、これは「どのオペレータか」より深い結論である：flagtree の live コンパイル決定性が根治される（FlagGems #6054-6057 を上流に引き継ぎ）まで、国産チップ上の flag_gems オペレータの決定論的デリバリはブラックリスト/フォールバック機構でカバーする必要がある。これは FlagOS の「flag_gems 全量置換」叙事にとって重要な誠実な注釈である；天数智芯にとっては、corex4.4.0/4.5.0 デュアルスタック 0.20.2 の決定論的デリバリ路径がこれで記録に基づき辿れるようになった。

3.3 沐曦（metax）と寒武紀（cambricon）：sglang 0.5.18 デリバリラインの拡大（09-07/09-08）

情報源：build-infra #781（09-07 22:49）、#783（09-08 07:18）、#784（07:27）、#773（09-07 13:10）

  • 沐曦 metax-maca3.7.2.1 sglang 0.5.18 ライン開通：22:49 #781 にて maca3.7.2.1 の sglang app 設定（deps_app/app env）を追加；09-08 07:18 #783 にて app イメージタグ 2.1.2-0.1.dev1_ga73b27b60 を登録；07:27 #784 にて docs に maca3.7.2.1 の sglang 0.5.18 F/T デュアルパス E2E 通過を記録し、プラグイン側 PR #86 を検証マトリクスに記載。runner 設定には maca3.8.1.3 ラインも既に具備。
  • 寒武紀 cambricon-neuware4.4.3：09-07 13:10 #773 にて docs に neuware4.4.3 の sglang 0.5.18 納品を記録（前日 0.20.2 側の記録リズムを継承）。

解釈：sglang 0.5.18 の納品マトリクスは RC1 ブランチ分岐後も右へ移動し続けている——沐曦 maca3.7.2.1 は「F/T デュアルパス E2E 通過 + プラグイン PR #86 関連付け」でクローズドループを完成させ、寒武紀 neuware4.4.3 は納品記録を補充。前日の燧原 tops1.9.10/摩尔線程 musa4.3.6 の sglang 0.5.18 記録と合わせ、「vLLM 0.20.2 と sglang 0.5.18 のデュアル推論フレームワーク × マルチベンダー SDK ライン」の納品マトリクスはほぼ展開済みであり、各ラインの登録にはイメージタグのフィンガープリントとプラグイン commit の関連付けが伴う——これこそが RC1 manifest における vllm-plugin/sglang-plugin のデュアルエントリ（それぞれ rc1.post1）の背後にあるエンジニアリング上の事実である。

3.4 外部エコシステム：昇騰の検証記録と from-scratch 修正、昆仑芯 KernelGen オペレータ、sunrise 新バックエンド接続（09-07/09-08）

情報源：build-infra #772（sunrise env）、#775/#780/#782（昇騰）、#778（外部ブラックリスト lead）、FlagGems-Experimental KernelGen Kunlunxin オペレータ

  • 昇騰（ascend）sglang 0.5.18 の検証と修正：#780（22:10）にて cann8.5.0 sglang app イメージタグ 2.1.2-0.1.dev1_g0f98ddc20 を登録；#782（09-08 07:16）にて docs に cann8.5.0 の sglang 0.5.18 検証を記録；#775（19:46）にて ascend のゼロからのビルドシナリオにおける sglang serve の env 注入を修正（USE_FLAGGEMS=0 分岐）；#778（20:19）にて ascend index_select に外部ブラックリストが必要な手がかりを記録（3.2 と同族の決定性調査が昇騰へ溢出）。
  • 昆仑芯（kunlunxin）：FlagGems-Experimental KernelGen が Kunlunxin digamma/arctan（minimax 多項式 kernel）/bernoulli の 3 オペレータをバッチでマージ（1.3、ZhiwenDeng）。
  • sunrise 新バックエンド接続（#772、12:49）：build-infra が runner 設定に sunrise ベンダーのデバイス可視性 env（TANG_VISIBLE_DEVICES=all、sunrise ツールチェーンライン tangrt1.2.0 は従来より runner マニフェストに記載済み）を追加。sunrise はまだ公開されているメンバー機関リストに現れていないが、ツールチェーン命名（TANG RT）から TANG をプレフィックスとするアクセラレータランタイムと推測される；本調査期間のアクションはそのコンテナ起動パラメータの補完であり、接続の初期段階に属する。

解釈：外部エコシステムの 3 ラインはそれぞれ「深層対応ベンダー」（昇騰——既にメンバー機関と同級、sglang 検証＋決定性調査の溢出）、「オペレータ衆智」（昆仑芯——KernelGen 数学関数オペレータ）、「新バックエンド備蓄」（sunrise——runner 設定が先行、コンポーネントのマージはまだなし）に対応する。昇騰の index_select 外部ブラックリストの手がかりは追跡に値する：3.2 の「コンパイラ分水嶺」結論が同様に昇騰の flagtree パスにも当てはまるなら、決定性問題は iluvatar の個別事例ではなく flagtree コンパイルパスの系統的課題であることを示す。

4. まとめ

本調査期間（09-07 10:18 ~ 09-08 10:18）は GitHub 側で期間内コミット 91 件、30 リポジトリへのプッシュがあり、最近で最も活発な期間の一つ；ニュース側はコンポーネントレベルの検索が六連続で平静だったが、エコシステム側では期間内イベント（上海フォーラム）が出現。4 本の主軸：

  1. FlagOS 2.2 RC1 正式ブランチカット（09-07 11:11 以降）：community が release-2.2-rc1.yaml をマージ（25 のマニフェスト項目/22 リポジトリ、+252 行）、release-branch-tag ワークフローはデフォルトで rc1 に切り替わり、その後 11 分以内に少なくとも 12 リポジトリが集中的に初回の rc1.post1 検証 tag を打った（FlagSparse は 11:27 に rc1.post1 リリースを公開）——昨日の「community マニフェストのリポジトリ動作を見る」という予測が的中し、RC0→RC1 のリリースパイプライン切り替えが完了。バージョンアンカー：flaggems v5.4.0、flagscale v2.1.0、kernelgen v2.2.0、flagcx v0.14.0、flagtree 0.7.0（triton 3.6/3.5/3.3 の三系統）；スケジュールでは 09-01〜09-24 がマルチチップマトリクステスト期間、09-28 が GA。今後のシグナル：rc1.postN の増分ペースと 09-24 前後の RC-final。
  2. FlagScale トレーニングスタックの三イベント：KERV エンボディド投機的デコーディングのトレーニング/推論統合がマージ（#1278、OpenVLA verifier + LIBERO 推論 + 14 オペレータ + 33 単体テスト、トレーニングスタックが初めてエンボディド戦略の投機的デコーディングをカバー）；Megatron-LM-FL と FlagScale が同じ夜に Megatron-LM v0.18.2 にアライン；CICD が inference/serve パイプラインを削除しトレーニングに集中（推論の責務はさらに vllm/sglang プラグインへ）。
  3. 決定性課題に「コンパイラ分水嶺」が浮上：天数智芯 0.20.2 の最終確定は flag_gems GEMM ファミリ全体をブラックリスト化して corex ixblas へフォールバック（#779、F/T 30/30 確定かつスループットは逆転 14.0 vs 12.3 tok/s）；根本原因は同一の flag_gems kernel が flagtree エンジン内コンパイルでは launch ごとに非決定、ベンダー triton コンパイルでは bitwise 決定であること、上流への引き継ぎは FlagGems #6054-6057；昇騰側にも同種の外部ブラックリストの手がかりが出現。同日 corex4.4.0/4.5.0 のデュアルスタックが g16e8655 フィンガープリントで 0.20.2 の新規デリバリとして登録。
  4. マルチチップデリバリマトリクスとオペレータマトリクスは右へシフト継続：sglang 0.5.18 ラインで沐曦（maca3.7.2.1、F/T E2E 通過）、寒武紀（neuware4.4.3）、昇騰（cann8.5.0）の記録がクローズ；清微 txda バックエンドがベンダー自前の PR で vllm-plugin-FL main ラインにマージ（vLLM 0.24.0）；FlagGems-vllm は同日、達摩院玄鉄 PPU-ZW810E と海光 DCU の二つの専用 fused-MoE バックエンドをマージ；FlagBLAS Ascend L2 ルーチン（CHER/CHER2/SSYR/CSYR）を一括補完；FlagGems-Experimental が sync-to-kernelgen CI を構築し、クロスバックエンドの KernelGen オペレータを一括同期。

予測：RC1 はすでにブランチカット済みで、コンポーネントのデフォルトブランチは「バグ修正のみ受け付ける」テスト安定化期間に入り、今後二週間の GitHub 側の注目点は「新機能のマージ」からrc1.postN 検証 tag の増分ペースとデリバリ記録の密度へ移る（build-infra の記録頻度は RC 進捗の最良の代理指標）；FlagGems #6054-6057 のコンパイラ決定性の引き継ぎは追跡に値する（根本解決すれば、国産チップ上での「flag_gems 全量置換」が真に後顧の憂いなくなる）；FlagTree 単一 wheel（Prism debugger/profiler 含む）と KERV エンボディドトレーニング経路は 2.2 GA 時に検証に値する二つの新能力ポイント；清微（FlagTree バックエンド + vLLM txda ライン）と外部新バックエンド（sunrise）の接続進捗はメンバー単位のエコシステム拡大の観察項目となり得る。

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

情報源 検証結果
GitHub org repos API（flagos-ai、52 リポジトリ） 30 リポジトリが調査期間内にプッシュ；コミュニティ/FlagScale/FlagGems など 14 リポジトリのデフォルトブランチに実質マージ；FlagSparse/FlagDNN/sglang-plugin-FL/release-info/docs/FlagTree(09-08) などはデフォルトブランチのコミット検証により PR ブランチまたはタグ操作と確認
GitHub commit search（org 全量 91 件、sort=committer-date） committer 時間と所属リポジトリを逐一検証；全デフォルトブランチの実質マージを網羅
GitHub PR/commit 詳細（community #107、FlagScale #1278、FlagGems-vllm #696/#746、vllm-plugin-FL #447/#450、build-infra #779/#772 など） manifest 内容、KERV 範囲、fused-MoE 詳細、txda 帰属、決定論的ロードマップ全文を提供
GitHub tags/releases API + 日付検証 FlagSparse v0.3.0-rc1.post1 release 09-07 11:27 リリース；FlagCX/FlagGems-sglang/vllm-plugin-FL rc1.post1 tag 存在；12 リポジトリが 11:22~11:33 に集中プッシュ（RC1 tag 波）
community release/2.2 ディレクトリ（raw） release-2.2-rc1.yaml 全文 25 条目；schedule_CN.md（08-31 凍結/09-28 GA）；release-branch-tag.yml デフォルト rc1
Google News RSS（中英 14 組、プロキシ経由） コンポーネント語は調査期間内ゼロヒット；智源研究院語の 58 件はコミュニティブログ+ギャンブル SEO ノイズとして一括除外；天数/沐曦のヒットは商業ニュースのため不収録
HN Algolia（FlagOS/FlagGems/flagos-ai/BAAI） 関連ヒットゼロ
Tavily/web 検索 FlagOS コミュニティ上海フォーラム（CSDN 公式アカウント）一件のみ調査期間内のエコシステムイベントとしてヒット
FlagOS CSDN 公式アカウント（flagos.csdn.net） フォーラム告知 09-07 09:57 公開（6a9e1a10…）；最新内容に他調査期間内の更新なしを確認