調査期間：2026-11-03 06:00 ~ 2026-11-04 06:00（北京時間、24 時間；前回デイリーレポートの区切りから継続）。

情報源：GitHub（org: flagos-ai 61 リポジトリ全量核查、228 コミット、177 マージ済み PR、271 件の期間内更新審査中 PR、117 件の新規オープン、24 リポジトリへのプッシュ、31 リポジトリの Release と 8 リポジトリの Tag 原子核查）、Google News RSS（24 組の中英語検索語、プロキシ経由）、HN Algolia（8 組）、CSDN FlagOS コラム（各記事の時刻を個別核查）、智源コミュニティ（詳細は付録情報源リストを参照）。

本期インデックス

  • 今日の重点：vLLM 0.28 ラインの四バックエンドが同日収束；FlagGems が 2 分で 23 件のベンチマーク移行；2.3.0 が CANN 9.2.1 第五層を追加（11-03）
    1. オープンソースプロジェクトの進展（GitHub 動向）
      • 1.1 組織のリズム：24 リポジトリへのプッシュ、228 コミット、177 マージ、組織全体の審査中 1602 件（11-03 ~ 11-04）
      • 1.2 リリース面：2.3.0 が第五層 CANN 9.2.1 を追加、base イメージは意図的に FlagTree を含めず（11-03）
      • 1.3 vLLM 0.28 ラインの四バックエンドが同日収束：清微、沐曦 C550、摩尔線程 MUSA、昇騰デコードグラフ（11-03）
      • 1.4 FlagGems ベンチマーク参考：2 分で 23 件マージ、H800 参考読み込みを単一 JSON に統一（11-03）
      • 1.5 FlagGems KernelGen：天数 BI-V150 が 10 分で 10 件、NVIDIA が 12 件、昆侖芯と燧原がそれぞれ一段を補完（11-03）
      • 1.6 FlagQuantum：ブールレジスタ選択が qfunc/Qmod フロントエンドに進出、Pauli SELECT をゲートレベルに降格（11-03）
      • 1.7 訓練とオペレータライブラリ：TransformerEngine が壁仞 SUPA バックエンドを新規追加、FlagTensor が MUSA を補完、Megatron が DSv4 に接続（11-03）
      • 1.8 融合通信オペレータ：RS+add+RMSNorm+AG リングカーネルが FlagGems と SGLang プラグインに進出（11-03）
      • 1.9 関連インフラ：optest の飞书通知にテストサマリを付与、FlagTree CI が飞书多次元テーブルへ移行、FlagQAI が macOS サンドボックスを厳格化（11-03）
    1. ニュース報道とエコシステム
      • 2.1 チャネル核查：24 組の検索でコンポーネント級のヒットゼロ、CSDN と HN は期間内に新記事なし（11-04）
      • 2.2 産業側：メンバー機関が烏鎮サミットで傑出貢献賞を受賞、燧原科技が A 株上場（11-03）
    1. メンバー機関とバックエンドベンダーの深掘り
      • 3.1 清微智能：TXDA は 0.28 上で eager のみを実行し、グラフモードを明確に拒否（11-03）
      • 3.2 沐曦：C550 の 0.28 は「空適配」、変更はすべてプラグイン内に留める（11-03）
      • 3.3 摩尔線程：MUSA 0.28 でネイティブ MCCL とセグメント化グラフを一括導入（11-03）
      • 3.4 昇騰：0.28 デコードグラフ、CANN 9.2.1 base、INT8 BMM、910C CI の四方面を並行推進（11-03）
      • 3.5 天数、昆侖芯、燧原、玄鉄、海光と地平線：一方でバッチ的にオペレータを補完、他方でチューニングを継続（11-03）
    1. まとめとトレンド観察
  • 付録：情報源核查表、完全情報源リスト

今日の重点：vLLM 0.28 ラインの四バックエンドが同日収束；FlagGems が 2 分で 23 件のベンチマーク移行；2.3.0 が CANN 9.2.1 第五層を追加（11-03）

日付：2026-11-03　出典：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #554 · vllm-plugin-FL PR #575 · vllm-plugin-FL PR #646 · FlagGems PR #8294 · build-infra PR #1614（全量は付録を参照）

  • 推論ライン：vLLM 0.28.0 は一日のうちに清微、沐曦、摩尔線程、昇騰の4つのバックエンドで同時に収束し、合計で17051行追加・789行削除、150ファイルに及んだ。4件の形態はそれぞれ異なる。清微はグラフモードを全面的に撤廃してeagerのみを残し、沐曦はベンダー製の0.28パスが一切ない前提で「空適配」を行い、摩尔線程はネイティブMCCLとセグメント化グラフを同時に持ち込み、昇騰はデコード専用グラフを補完した。同一の上流バージョンに対して4つの実装戦略が存在することは、FlagOSのマルチチップ適配が「テンプレートのコピー」ではなく「バックエンドごとの勘定」の段階に入ったことを示している。
  • オペレータライン：FlagGemsは16:41と16:42の2分間に23件をマージし、うち21件は同一作者によるコミットで、すべて各バックエンド基準の参照データ読み込みを散在するreaderから統一JSONへ移行するものだった。これは機能開発ではなく、評価の比較可能性を支える基盤整備である——参照値が同一のデータ由来であってこそ、バックエンド間のスコアに意味が生まれる。同日FlagGemsは合計76件をマージし、組織全体177件の42.9%を占めた。
  • バージョンライン：build-infra #1614は2.3.0に第五層baseイメージCANN 9.2.1（910B、python 3.12、torch 2.13、triton_ascend 3.6.0のみ）を追加し、#1615が直ちに当該層のchangelog日付をregistryプッシュ時刻に基づいて遡って補填した。イメージ層面では2.3.0はbase、寒武紀 neuware 4.4.3、沐曦 maca 3.8.1.3、海光 dtk26.10、AMD rocm7.2.4、昇騰 CANN 9.2.1をカバー済みだが、communityのrelease/2.3マニフェストは依然として404を返し、リリースはマニフェスト凍結の段階をまだ越えられていない。
  • 判断：当日177件マージ、117件新規オープン、271件が調査期間内に更新され審査中、組織全体の審査中ストックは1602件。前回の調査期間（162件マージ、192件新規オープン）と比べ、マージは9.3%増、新規オープンは39.1%減となり、レビュー側で初めて「消化が生産より速い」兆候が現れた。ただし新規オープン量の落ち込みは主にFlagGems単一リポジトリ（77件、うち59件が同一作者）によるものであり、全体の需要が冷え込んだことを意味するものではない。

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

1.1 組織のリズム：24リポジトリプッシュ、228コミット、177マージ、組織全体の審査中1602件（11-03 ~ 11-04）

日付：2026-11-03 ~ 2026-11-04　情報源：flagos-ai 組織リポジトリ · コミット検索 · マージ済みPR検索 · 審査中PR検索

  • リポジトリ面：61 リポジトリ中 24 リポジトリが調査期間内にプッシュがあり、過去2週間で最高となった。プッシュ時刻の近い順から遠い順に vllm-plugin-FL、FlagTree、FlagQuantum、FlagTensor、FlagGems、TransformerEngine-FL、release-info、build-infra、Trident、docs、optest、Megatron-LM-FL、FlagDNN、FlagGems-vllm、FlagTrain、Torch-FL、FlagGems-sglang、FlagCX、FlagAttention、FlagSparse、FlagQAI、sglang-plugin-FL、OpenCourse、flir である。うち release-info のプッシュは依然として gh-pages の自動デプロイであり、ソースコードの変更はない。
  • コミット面：コミット検索のヒットは 228 件で、リポジトリ別では FlagQuantum 108、FlagGems 47、FlagQAI 12、FlagGems-sglang 9、FlagSparse 8、FlagGems-vllm 8、optest 7、build-infra 5、FlagTensor 5、FlagDNN 4、FlagCX 3、FlagTree 3、FlagTrain 3、Torch-FL 2、FlagAttention 2、flir 1、sglang-plugin-FL 1 であった。量子スタックの1リポジトリが 47.4% を占め、前回の 44.9% からやや回升した。
  • マージ面：マージされた PR は 177 件で、19 リポジトリからである：FlagGems 76、FlagQuantum 28、vllm-plugin-FL 14、FlagGems-sglang 9、FlagGems-vllm 8、FlagTree 8、optest 7、FlagQAI 6、build-infra 5、FlagTrain 3、FlagCX 3、Torch-FL 2、FlagAttention 2、FlagTensor、Megatron-LM-FL、TransformerEngine-FL、FlagSparse、sglang-plugin-FL、flir が各 1。これは近頃でバックエンドとコンポーネントのカバレッジが最も広いマージ分布である。
  • レビュー中面：調査期間内に更新のあったレビュー中 PR は 271 件で、新規オープンは 117 件。リポジトリ別では FlagGems 146（新規オープン 77）、FlagGems-vllm 30（9）、FlagTree 28（5）、vllm-plugin-FL 17（8）、sglang-plugin-FL 8（3）、Torch-FL 7（1）、FlagTrain 6（3）、FlagAttention 4、flir 3（1）、FlagQuantum 3（3）、FlagCX 3（2）、FlagScale 3、docs 3（1）、Trident 2、FlagDNN 2（1）、Megatron-LM-FL 1（1）、TransformerEngine-FL 1、optest 1（1）、build-infra 1、FlagQAI 1（1）、FlagTree-AscendNPU-IR 1 であった。現在の検索基準によると、全組織のレビュー中 PR のストックは 1602 件で、マージとレビュー中の比率は約 1 対 9 である。
  • 作者面：マージ側は FlagQuantum（ボットアカウント）36 件、lukatao 33 件、youseeyouonedayday 12 件、xuanzhengdu-eng 10 件、wuwentao 8 件、physics31415926 6 件、github-actions ボット 6 件。新規オープン側は youseeyouonedayday 一人で 59 件、当日の新規オープンの 50.4% を占め、残りは SeddonShen 4、tonyh168 4、FlagQuantum 4、lukatao 3、Kaiwen1024 3 である。
  • 比較：前回の調査期間（11-02 06:00 ~ 11-03 06:00）は 162 件のマージ、192 件の新規オープン、311 件の調査期間内更新のレビュー中であった。今回の調査期間はマージが 9.3% 増、新規オープンが 39.1% 減、調査期間内更新のレビュー中が 12.9% 減となった。三項目を合わせると同じ事実を指し示している：レビュー側はストックの消化を加速しており、新規開発チケットの絶対量は FlagGems 一社が主導している。

1.2 リリース面：2.3.0 に第五層 CANN 9.2.1 を追加、base イメージには意図的に FlagTree を含めず（11-03）

日付：2026-11-03　情報源：build-infra PR #1614 · build-infra PR #1615 · build-infra PR #1613 · community 2.2 リリースリスト

  • base レイヤーを新規追加：#1614 で base/ascend-cann9.2.1（aarch64 + ubuntu 24.04、910B のみ）を新規追加。CANN 9.2.1 toolkit、910B ops パッケージ、NNAL、および既存の /etc/profile.d/vendor.sh 環境キャプチャを備え、さらに configs.yaml の行、cann921 runner オーバーライド、verify ノードのエイリアスを補完。198 行追加、5 ファイル。
  • なぜ python 3.12 なのか：PR 本文には 2 つの厳格な制約が明記されている。flagos-pypi-ascend 上の torch 2.13、torch-npu 2.13、torchvision 0.28、torchaudio 2.11 の wheel は cp312 のみ。CANN の set_env.sh は自身が持つ python ツリーを PYTHONPATH に押し込むため、base インタプリタは実行時の venv と完全に一致していなければならず、そうでなければインポート時にバージョンが混線する。併せて triton を 3.6.0 に固定し triton_ascend 3.6.0 を重ね、numpy を 1.26.4 に固定。
  • なぜ意図的に FlagTree と FlagCX を含めないのか：FlagTree にはまだ CANN 9.2.x のバージョン固定がなく、9.2.1 にも対応する flagcx wheel がない。そのためこのレイヤーでは flagtree、flagcx、env.app、deps_app をすべて空にし、ビルド順を base → FlagTree なしの runtime → FlagTree builder → FlagTree wheel → runtime 更新に変更。flagtree が欠省のときコンパイラは triton にフォールバックする。
  • バージョン標記：#1615 はボットによるコミットで、2.3.0 タグ下の各バックエンドの未執筆 changelog エントリを registry push_time に従って日付付けしたもの。本件は ascend-cann9.2.1 レイヤーに対応し、305 行追加、5 行削除、4 ファイル、イメージ内容は一切変更しない。また #1613 は実行時の FlagTree バージョンリクエストに明示的な --index-url をサポートさせ、上記「複数回ビルド」チェーンの出口を用意。
  • リリース状態の確認：31 リポジトリの Release と 8 リポジトリの Tag をアトミックに確認、調査期間内に新規 Release オブジェクトはなし。community 側の release/2.3/release-2.3.yaml は依然 404 を返し、release/2.2 マニフェストは現役。イメージは既に 6 レイヤーをカバーしているが、マニフェスト凍結とサイト公開の 2 ステップはまだ発生しておらず、前回の判断と一致。
  • 要注意：base レイヤーが 4 層から 6 層に拡大したのにマニフェストは動いておらず、2.3.0 の「イメージ先行」特徴がさらに強化された。今週もマニフェストを凍結しない場合、実際にリリースされるバージョン内容は 2.3.0 計画から乖離するだろう。

1.3 vLLM 0.28 ライン 4 バックエンドが同日収束：清微、沐曦 C550、摩尔線程 MUSA、昇騰デコードグラフ（11-03）

日付：2026-11-03　情報源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #554 · vllm-plugin-FL PR #575 · vllm-plugin-FL PR #646 · vllm-plugin-FL PR #676

  • 清微 TXDA：#642 で TXDA バックエンドを vLLM 0.28.0 に適合させ、「eager のみ」を明確化。グラフモードは壊れたのではなく積極的に放棄された——セグメントネイティブグラフは TP8 で既に 2 モデルの完全なゲート（スナップショット R10 / R6d）を通過しているが、Dense TP1 の正確性は未解決のままであるため、PR は TXDA のグラフキャプチャと分割実装を削除し、設定段階でグラフとコンパイル設定を直接拒否して --enforce-eager を提示する。MLA、スパースアテンション、投機的デコード、コンテキスト並列も同様に、一律ではなく具体的な非サポートパスごとに個別に拒否する。3067 行追加、146 行削除、29 ファイル。
  • 沐曦 C550：#554 でベンダー側にまだ 0.28 パスが存在しない前提で「0.28-empty」適応を実施——すべての変更は vllm_fl/ と MetaX CI スクリプト内に留め、バックエンドの動作は vendor_name == "metax" または MetaX ランタイムをゲートとする。既存のライフサイクル規約に従い、初期 import 修正はプラグイン入口からインストールし、kernel と backend の置換は vendor patch パッケージに置き、site-packages の .pth には書き込まず、setup.sh で 15 個の履歴 zz_fl_*.pth フックをクリアする。2838 行追加、70 行削除、36 ファイル。
  • 摩尔線程 MUSA：#575 で MUSA を 0.28.0 にアップグレードし、ネイティブ MCCL、FX/eager コンパイル、セグメントネイティブグラフを導入、7804 行追加、233 行削除、46 ファイル。実行ベースラインは 4 枚の S5000、BF16、TP=4、TorchMUSA 2.9.0 と MUSA SDK 4.3.5。コンパイル側では RMSNorm、SiLU、rotary が明示的な MUSA オペレータ境界を通り、参照 RMSNorm はターゲット側の FP32 累加契約を保持する。グラフ処理は dispatch/backends/vendor/musa/graph.py に集中し、MUSA コンパイルサブパッケージと実行可能キャッシュを削除する。
  • 昇騰デコードグラフ：#646 で 0.4.0-dev 上に FULL_DECODE_ONLY のネイティブグラフキャプチャとリプレイを開き、Qwen3.6-27B と Qwen3.6-35B-A3B をカバー、デコードは torch.npu.NPUGraph を通し、prefill、視覚エンコード、サンプリングはグラフ外に留める。3342 行追加、340 行削除、39 ファイルで、#606 と #619 のフォワードポートである。
  • 二線並行：0.28 の収束と同時に、0.32 の適応がレビューキューで進行中——vllm-plugin-FL には #675（燧原 S60）、#674（天数）、#659（AMD ROCm gfx1100）、#693（沐曦 C550）、#667（統一 FL 実行と燧原適応）の 5 件がレビュー中。0.28 はメンテナンス線、0.32 はターゲット線であり、二線同時実行が常態化している。
  • 同期メカニズム：0.4.0-dev から 0.5.0-dev への forward-sync は当調査期間に #676、#678、#688、#689 の 4 件をマージし、「ブランチ全体のマージ」から「レビュー単位のインクリメンタルリプレイとソースコミットの保持」に変更し、競合はドラフト PR で公開する。

1.4 FlagGems ベンチマーク参照：2 分で 23 件マージ、H800 参照読み込みを単一 JSON に統一（11-03）

日付：2026-11-03　情報源：FlagGems PR #8293 · FlagGems PR #8294 · FlagGems PR #8295 · FlagGems PR #8296 · FlagGems PR #8318

  • バッチ規模：16:41 と 16:42 の2つのマージ分内に23件が着地、うち FlagGems 21件、vllm-plugin-FL 2件、21件は lukatao によるもの。当該期間に FlagGems は計76件をマージし、lukatao 一人で33件と半数近くを占めた。
  • 統一 JSON：核心は #8293 から #8296 の4件で、それぞれアテンションとプーリング、リダクションと線形代数、ポイントワイズ、スパースとテンソルレイアウトの4類オペレータの H800 参照読み込みを統一 JSON へ移行した。従来は各類オペレータがそれぞれリーダーを持ち、参照値のソース・単位・丸め規約がコード内に分散していた。移行後は4類が1つのデータ入口を共有する。
  • バックエンド参照修正：残り二十数件はバックエンド別に参照実装を修正——昇騰側は tensorinv、orgqr、weight norm 逆伝播、Cholesky solve、分数最大プーリング逆伝播のネイティブ H800 ベースラインを補完；燧原側は baddbmm、nanquantile、masked scale、FlashAttention の参照を修正；崑崙芯側は FloatPower の原地参照カバレッジを維持；MUSA 側は LDL と4つの線形代数参照を補完；PPU 側は一部 LU 参照と再構築精度を修正。
  • 付随ドキュメント：#8318 で「ローカルバックエンドオペレータテスト修正」スキルドキュメントを新規追加し、「まず参照を揃え、次に候補を判定する」フローを再利用可能な操作説明として記述；#8275 から #8277、#5858 では別途 as_strided_scatter 用例、昇騰 CTC 出力 dtype、二項分布 out オーバーロード、cumsum 精度チェックの dtype 推論を修正。
  • 判断：このバッチの価値はカバレッジではなく「比較可能性」にある。クロスバックエンドのスコアは参照値が同源で単位が一致し丸め規則が明確な場合にのみ比較可能となる。リーダーを単一 JSON に収斂させることは、評価体系が「各々書き各々」から「同一の物差し」へ向かう前提条件であり、なぜ分単位のバッチマージが可能かを説明する——変更は機械的で境界は明確、オペレータ実装に触れない。

1.5 FlagGems KernelGen：天数 BI-V150 十分で十件、英偉達十二件、崑崙芯と燧原がそれぞれ一段を補完（11-03）

日付：2026-11-03　情報源：FlagGems PR #8093 · FlagGems PR #8085 · FlagGems PR #8124 · FlagGems PR #8255 · FlagGems PR #8265 · FlagGems PR #8110 · FlagGems PR #6501

  • 天数 BI-V150：16:04 から 16:10 までの 6 分間に 10 件をマージ、すべて KernelGen 天数生産ラインと表示——三種類の特殊多項式（shifted Chebyshev、Hermite、および Chebyshev の out 変体）、2 つのアップサンプリングとパディング逆伝播、量子化最大プーリング、行列積 smm、not_equal とプーリングインデックス逆伝播。これは天数の単日バックエンド項目のピークであり、「1 つのバックエンドが 10 分間に 10 件」というペース記録も更新した。
  • NVIDIA ロングテール 12 件：疎と構造化 4 件（_to_sparse_semi_structured、sparse_coo_tensor、crow_indices、flatten_dense_tensors）、cudnn 系 2 件（cudnn_convolution_relu、cudnn_grid_sampler_backward）、ビューと形状 2 件（squeeze、combinations）、量子化と型 2 件（make_per_channel_quantized_tensor、_cast_Char）、線形代数 1 件（lu_solve）、さらに _foreach 系の非 NVIDIA バックエンド互換性修正 1 件。すべて KernelGen 生産ラインで生成後に人手で收口。
  • 昆仑芯 11 件：#8273 は 1 箇所で 3 つの性能変更をパッケージ（int cumsum 行スキャン、mean スケーリング折り畳み、nanmedian ベクトル化）；#8250 は inner を XPU 上で実際にコンパイルに参加させ tile を再調整；#8252 は Hermite h をバックエンド状態実行器経由に変更；#8253 は poisson_nll_loss のレジスタプレッシャーを低減しテールの越読みを修正；#8262 は展開ユークリッドアルゴリズムで lcm を最適化；#8263 は special_chebyshev_polynomial_u を最適化；#8257 は native_batch_norm_legit_functional のバックエンド特化を追加。さらに #8255 はベンダー min.o の SIMD ロードとセグメントワイド行並列で argmin を加速、#8281 は bitwise_left_shift の非原地入口をチューニング変体にルーティング、#8290 と #8319 は foreach シリーズの XPU 上での失敗を修正。
  • 燧原 GCU300 4 件：#8265 は cat/concatenate コピーカーネルの行末欠落を修正；#8259 は silu_backward の div_rn を tl.fdiv に置換し GCU300 上の誤った値取得を修正；#8251 は uniform_ のサンプリングが厳密に [from, to) に収まるように；#8254 は clip/clip_ の GCU300 オーバーレイ内のキーワード名を修正。
  • 昇騰と SiliconFlow：昇騰側 #8110 はチャネル級 INT8 BMM（bmm_w8a8、519 行追加 3 行削除）を新規追加、#8286 は 910C と 950DT の SKU ドキュメントを補充；SiliconFlow 側 #6501 は _embedding_bag、_embedding_bag_forward_only、_embedding_bag_backward の 3 オペレータを一括追加、SUM/MEAN/MAX、重み付き、padding 除外、空袋と終端オフセットをサポート、7494 行追加 222 行削除、24 ファイル。
  • 判断：当日のバックエンド項目の分布に移動が発生——天数が 10 件で先頭、NVIDIA が 12 件でロングテールを補完継続、昆仑芯が 11 件でチューニング主体、燧原が 4 件すべて正確性修正、玄鉄は FlagGems 側でゼロマージ（その動作は PPU コンパイルとプラグイン側にあり、3.5 参照）。これは KernelGen 生産ラインがすでにベンダー別に生産計画を立てられることを示しており、すべてのバックエンドが 1 つのキューを共有しているわけではない。

1.6 FlagQuantum：ブールレジスタ選択が qfunc/Qmod フロントエンドに進出、Pauli SELECT がゲートレベルに降下（11-03）

日付：2026-11-03　情報源：FlagQuantum PR #1027 · FlagQuantum PR #1028 · FlagQuantum PR #1038 · FlagQuantum PR #1047 · FlagQuantum PR #1048 · FlagQuantum PR #1049

  • ブール選択線：#1027 有界ブール値候補の構築を確立し、#1028 目標コストに従ってブールレジスタ候補を選択し、#1029 共通ワークフローでこれらの候補を検証し、#1038 有界ブール選択をネイティブ qfunc と Qmod フロントエンドに接続した。この4件を合わせることで、「ブールレジスタ割り当て」を内部探索からユーザープログラムが直接恩恵を受けられるコンパイル機能へと変えた。
  • アルゴリズムと降格：#1035 に SelectedMajoranaFermion を新規追加し、#1037 に SelectPauliLCU を新規追加し、#1036 Majorana の降格をコンパイル期まで延期し、#1047 Pauli SELECT をゲートレベルまで降格した。#1030（古典的条件付き Pauli ゲート上の量子制御）と #1043（バインド操作の append）と相まって、アルゴリズム層の表現力とバックエンド実行可能性の間の橋が段階的に架けられた。
  • セマンティクスと可視化：#1039 ネイティブ単一ビット位相呼び出しを捕捉し、#1041 精密な重み付き位相とグローバルプログラム位相を公開し、#1042 有界の within/apply スコープを捕捉し、#1045 検査済みのクリーンアップスコープと随伴呼び出しを公開し、#1031 描画器が TeX 内で混合量子制御と古典フィードバックをレンダリングできるようにし、#1044 と #1032 で2種類の実行可能なサンプルを補完した。
  • CI 再利用：#1048 MetaX の CPU Core チャネルで読み取り専用のホストローカル依存環境を試験導入——Python パッチバージョンと pyproject の SHA-256 が完全に一致する場合に読み取り専用依存をマウントし、そうでなければ元のインストール経路をたどる。同一 runner アカウント、Python 3.11.17、同一 checkout での対照結果は：環境と Torch の準備が 23 秒から 1 秒未満に短縮され、4 セグメント合計が 122 秒から 101 秒に短縮され、4 項目のスモークテスト結果は一致した。#1049 このメカニズムを 16 個の A800 runner 登録に拡大し、明示的な読み取り専用バインドマウントを要求した。
  • 判断：28 件のマージはセマンティクス、アルゴリズム、降格、可視化、CI の 5 本の線に分布し、単一の大規模変更はない。この「各線が毎日一小段ずつ前進する」リズムにより、量子スタックの検収単位は常に独立して再計算可能である——なお急速に変化し続ける技術にとって、明瞭な帳簿は機能の多寡よりも重要である。

1.7 トレーニングとオペレータライブラリ：TransformerEngine に壁仞 SUPA バックエンドを新規追加、FlagTensor は MUSA を補完、Megatron は DSv4 に接続（11-03）

日付：2026-11-03　情報源：TransformerEngine-FL PR #143 · FlagTensor PR #14 · Megatron-LM-FL PR #202 · FlagTrain PR #49 · FlagGems-vllm PR #1055

  • 壁仞のスタック参入：TransformerEngine-FL #143 に Biren SUPA ベンダーバックエンドを新規追加、3608 行追加、7 ファイル。壁仞が独立バックエンド形態として FlagOS のトレーニングコンポーネントに現れるのは初めて。PR 本文には「Add BIREN SUPA vendor」とだけ書かれ、ハードウェア検証記録は添付されておらず、骨組み先行の段階にある。
  • FlagTensor の MUSA 補完：#14 で FlagTensor に MThreads/MUSA バックエンドを登録し、検証済みの一連の要素単位オペレータを提供、300 行追加、5 行削除、14 ファイル。要点は ACOS、ACOSH、ASIN、ASINH、ATAN、ATANH、TAN の 7 つの超越関数に MThreads 専用の書き換えを追加し、MUSA Triton JIT がサポートしない libdevice パスを回避すること。NVIDIA と昇騰のデフォルト書き換え選択は変更なし。同日このリポジトリには PPU 直接起動の高速パス、host 側ループ計時、崑崙芯 tile チューニングの 3 コミットがあり、昇騰 PR #32 もマージされた。
  • Megatron の DSv4 対応：#202 は「DeepSeek-V4 上流同期」シリーズの第 1 弾で、3356 行追加、775 行削除、26 ファイル。核心は Float16Module がモデルを変換する際に精度敏感パラメータを保護すること——オプションの FP32 パラメータマーカーを新設し、attention sink/APE、mHC の mapping と gates、残差ストリーム出力ヘッドに適用；コンプレッサとインデクサの一部投影を FP8 コンテキスト外に残し、プライベートストレージに逆 RoPE を適用；遅延された重み勾配をオプションの注意力サブモジュールに通過させる；mHC の Sinkhorn 反復デフォルト値を 10 から 20 に引き上げ。
  • 訓練・推論オペレータ：FlagTrain 3 件、runtime バックエンドディレクトリのバックエンド別統合、他バックエンドイメージの補完、上三角マスク softmax フォワードの Triton 実装（NVIDIA と昇騰）を含む。FlagGems-vllm 8 件、MiniMax M3 スパース注意力 shim による FlagAttention 再利用、MiniMax TP8 の INT8 W8A8 MoE、fused_marlin_moe の W8A16 マルチレベルパイプライン、W8A8 INT8 と FP8 の C++ オペレータメタデータ登録を含む。
  • 判断：新チップが FlagOS に入るには 2 つの経路がある——1 つはトレーニングコンポーネントから始めるもの（TransformerEngine にバックエンド追加、FlagTensor にバックエンド追加）、もう 1 つはオペレータ生産ラインから始めるもの（KernelGen でオペレータを逐次補完）。壁仞は前者を選び骨組みで止まっているが、摩尔線程は両方の経路で同時に実装があり、差は検証の深さにあり参入速度にはない。

1.8 融合通信オペレータ：RS+add+RMSNorm+AG リングカーネルが FlagGems と SGLang プラグインに参入（11-03）

日付：2026-11-03　情報源：FlagGems PR #8317 · sglang-plugin-FL PR #166 · FlagGems-sglang PR #279 · FlagGems PR #8347

  • カーネルの設計：FlagGems #8317 に「通信 + 正規化」を融合した 2 つの Triton カーネルを新規追加（審査中、1403 行追加、3 ファイル）。fused_rs_add_rms_norm_ag は単一のリングカーネルで all_reduce(x) と fused_add_rms_norm(x, residual) を置き換え、reduce-scatter、残差加算、RMSNorm、all-gather を一度に完了する。ランク r は [r*chunk, min(T,(r+1)*chunk)) の行のみを所有し、正規化はこれらの行上でのみ実行され、残差は分散状態を維持する。gather=False の場合は owner ステップの後に停止し、RS + add + RMSNorm のみを実行する。付随する fused_qkv_norm_ag はもう一端を処理する。分散した qkv 出力に対して q と kv をそれぞれ正規化し、rest（k_pe）はそのまま透過させ、リングの AG 半分のみを実行する。
  • リングの実装：データは C 個のチャネル上で並行して転送され、チャネル c はランク上の 1 つのリングである。PPU 810E 上では pccl 28 チャネルグラフのリングを直接再利用し、各ホップが ICN リンクを経由するようにする。送信ごとに後続でフラグを 1 回インクリメントし、受信側は flag >= base + step を待つ。フラグは増加のみで減少せず、バッファの偶奇は呼び出しごとに反転するため、先行者が n+1 回目の呼び出しに進んでも、n 回目でまだ読み取り中のデータに触れることはない。
  • 上位層の接続：sglang-plugin-FL #166 は玄鉄側でこの RS + norm + AG 融合カーネルのセットを pure TP prefill のオプションとして提供（審査中）。FlagGems-sglang #279 は 6 つのモデルレベルオペレータ（sglang 融合インプレース RoPE、topk_softmax、fused_moe、chunk_gated_delta_rule_fwd、融合循環ゲート付き delta ルールおよびそのパック済みデコード版）を各プラットフォームの vendor カバレッジとともにマージし、13061 行追加、79 行削除、85 ファイル。このうち rms_norm は既存の one_pass_rms_norm と数学および ABI が一致するため、新規オペレータではなく _mthreads、_thead、_hygon のオーバーライド形式で統合された。
  • 付随するクリーンアップ：玄鉄側 #8347 は審査中で、PPU 上の NT GEMM の K アラインメントフォールバックを削除する内容。FlagTree #1348 はマージ済みで、明示的 swizzled の TLE レイアウトを保持し、コピーされるチェーン型 dot warp レイアウトを回避する。
  • 判断：通信をオペレータに折り込むことは TP 推論のレイテンシ削減の一般的な手段だが、オペレータライブラリが通信プリミティブと数値契約の両方を掌握することを要求する。FlagGems のこの一批はまず PPU と SGLang の 2 路線で試験運用され、この能力が依然として特定のハードウェアトポロジに束縛されており、クロスバックエンドの汎用部品として抽象化されていないことを示している。

1.9 付随インフラ：optest の飛書通知にテストサマリを付与、FlagTree CI を飛書多次元表へ移行、FlagQAI が macOS サンドボックスを厳格化（11-03）

日付：2026-11-03　情報源：optest PR #28 · optest PR #34 · FlagTree PR #1513 · FlagTree PR #1516 · FlagCX PR #669 · FlagQAI PR #30

  • optest 7件：飛書通知にテストサマリーを追加し、Trigger フィールドを末尾に移動、Commit を Ref の直後に配置（#28）。FlagTrain のランタイムメタデータを検出（#29）。オペレータコマンドのタイムアウトを設定可能にし（#30）、リポジトリごとにタイムアウトを設定（#32）。op-monitor のアップロードリトライを絞り込み（#31）。バックエンド GPU 設定を簡素化（#33）。中国語 README を追加（#34）。7件すべてが「マルチバックエンドのテスト結果を可読・追跡可能・再実行可能にする」ことを中心としている。
  • FlagTree 8件：機能側では昇騰 XCS の lightning-indexer UB オーバーフロー、swiglu 精度、tl.where がポインタオペランドを受け入れるよう修正し、PPU 側では明示的 swizzled の TLE レイアウトを保持。CI 側では FlagGems の CI スクリプトを GITHUB_ACTION_PATH 経由でブランチ間共有し、結果を飛書多次元表に報告、飛書キーを転送し認証情報欠如時に警告、同時に enflame3.5-guc400 の CI/CD ワークフローを削除。
  • FlagCX 3件：昇騰 910C の CI パイプラインを新規追加し単体テストのオーケストレーションを統一（+1559 行 -664 行、41 ファイル）。Torch Python カバレッジを4プラットフォームで実行し重複する CUDA 性能テストを削除。さらに昇騰デバイスの完了状態追跡とテンソル保持を修正。
  • FlagQAI 6件：macOS 上でローカル Python ジョブ、headless セッションの workspace 読み取り、ネイティブ shell 読み取り、検索ターゲット、検索サブプロセスを順にサンドボックス境界に取り込み、Agent コミット前に SDK レディ状態をチェック。6件は同一のセキュリティ収束の連続的なスライスである。
  • FlagAttention とその他：FlagAttention は非2の冪 head 次元における TMA prefill の修正を追加し、ベンダー依存のインストールに uv pip へ変更。FlagSparse は q4 関連の整理をマージ。FlagDNN 4件はパッケージイメージをリリース済み FlagOS リポジトリに向け、パッケージングワークフローを検証のみに変更。
  • 判断：本調査期間には 26 件が CI、評価、ツール側に該当し、全マージの 14.7% を占める。9社以上のバックエンドを同時に保守するプロジェクトにとって、この部分への投資は新規オペレータを生まないが、「どのバックエンドがどのバージョンで退行したか」をタイムリーに可視化できるかどうかを決定する。FlagTree が GCU400 ワークフローを削除し、CANN 9.2.1 と 910C パイプラインを追加したことも、CI リスト自体がハードウェア世代の交代に伴い更新されていることを示している。

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

2.1 チャネル確認：24組のクエリでコンポーネント級のヒットゼロ、CSDN と HN は期間内に新着記事なし（11-04）

日付：2026-11-04　情報源：Google News RSS（FlagOS クエリ） · CSDN FlagOS コラム · HN Algolia（FlagOS）

  • Google News：24組の中国語・英語クエリのうち、FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、flagos-ai および BAAI 関連の英語組み合わせはすべてゼロヒット。ヒットはメンバー機関と産業用語に集中（智源研究院 オープンソース 4件、智源研究院 チップ 4件、燧原科技 7件、国産算力 オープンソースソフトウェアスタック 7件、摩尔線程 3件、沐曦 1件、清微 1件）、計 28 件。逐条タイトルを確認したが、コンポーネントのバージョン、チップ適配、FlagOS 技術スタックに関わるものは一件もなかった。コンポーネント級クエリが連続2期間ゼロとなった。
  • CSDN コラム：ページ上の 52 リンクを逐条確認したところ、最新は 10-29 11:19 の MiniCPM-OCR と Jev の Day0 適配記事であり、その次は 10-29 16:25 公開の sglang-plugin-FL ライブ配信。ページ上部に並ぶ GLM-5.3-Flash、Qwen3.8-Flash-Next、LightX2V の3稿はそれぞれ 8-28、8-27、8-27 の旧記事であり、期間内には計上しない。
  • HN と智源コミュニティ：HN の8組のクエリのうち FlagOS は 7件、BAAI は 30件ヒットしたが、タイトルと本文の直接一致は 0。智源コミュニティのトップページに FlagOS 項目はなく、検索ページはクライアントサイドレンダリングのため、時刻確認可能なリストを取得できない。
  • 判断：連続2期間のニュース側の空白は、GitHub 側の 24 リポジトリへのプッシュ、177 件のマージと鮮明な対照をなす。FlagOS の対外ナラティブは依然として公式チャネル（CSDN コラム、智源コミュニティ、カンファレンス）に高度に依存しており、第三者メディアによるコンポーネント級の進展報道はまだ形成されていない。

2.2 産業側：メンバー機関が烏鎮サミットで傑出貢献賞を受賞、燧原科技が A 株上場（11-03）

日付：2026-11-03　情報源：世界浙商網（沐曦受賞） · 電子工程世界（摩尔線程受賞） · 財聯社（燧原上場）

  • 受賞：沐曦股分と摩尔線程は、2026年世界インターネット大会烏鎮サミットでそろって「傑出貢献賞」を受賞した。沐曦側の報道はフルスタックのイノベーションと国産GPUの成長ポテンシャルを強調し、摩尔線程側の報道は電子工程世界が伝えた。両社はいずれもFlagOSのメンバー機関である。
  • 上場：燧原科技がA株科創板に上場した。報道はこれを科創板のDSAアーキテクチャ算力ピースを補強するものと位置づけている。燧原のS60バックエンドは10-28にvLLM 0.28適応がマージ済みで、0.32適応（#675）は審査中である。
  • 対照：3社の調査期間内におけるFlagOS側の動きは同一ではない——沐曦C550の0.28適応は当日マージされ（1.3参照）、摩尔線程MUSA 0.28も同日マージされ（1.3参照）、燧原はFlagGems GCU300で4件の正確性修正を行った（1.5参照）。資本と栄誉の面での進展は、その技術投入のリズムを変えていない。
  • 説明：本項は企業側の動向であり、FlagOS技術スタックとは直接の関連はなく、エコシステムの背景として記録するものである。情報源はGoogle Newsの集約リンクであり、発信元のオリジナルサイトのアドレスは取得していない。

3. メンバー機関とバックエンドベンダーの深掘り

3.1 清微智能：TXDAは0.28でeagerのみを実装し、グラフモードを明確に拒否（11-03）

日付：2026-11-03　情報源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #641 · FlagGems PR #8279

  • 取捨選択：#642の本文は逐語で読む価値がある。セグメント化ネイティブグラフはすでに実装され、TP8下で2つのモデルに対して完全なゲート（スナップショットR10とR6d）を通過したが、Dense TP1の正確性は最後まで解決しなかった。作者は「一部の並列度でのみ使用可能なグラフモード」を選ぶのではなく、グラフキャプチャと分割の実装を削除し、設定段階でグラフとコンパイル設定を拒否し、ユーザーを直接 --enforce-eager へ誘導した。
  • 拒否面：MLA、スパース注意力、投機的デコード、コンテキスト並列は、それぞれがサポートしない具体的なパスごとに個別に拒否されており、包括的に無効化しているわけではない。この書き方により、エラーメッセージは具体的な機能を指し示すことができ、ユーザーが実行の途中で初めて失敗する事態を避けられる。
  • 検証環境：TX8110 64Gを8枚、イメージ内のvLLMは 0.28.0+empty——上流タグのコミット 2cf0a69 を VLLM_TARGET_DEVICE=empty でビルドしたもので、vllm._C 拡張を含まず、すべてのkernelはプラグインまたはFlagGemsに由来する。これは「プラグインが本当に自己完結しているか」を厳格な制約に変えることに等しい。
  • 規模：3067行追加、146行削除、29ファイル、併せて docs/usage/tsingmicro.md デプロイガイドを用意。
  • 判断：これは当日最も記録に値するエンジニアリング上の取捨選択である。マルチバックエンド適応で最もよくある失敗パターンは、特定の並列度でのみ成立するモードをリリースし、その後ユーザーの現場で数値エラーとして露呈させることだ。#642は「モードを1つ減らす」ことで「一部の設定でのみ誤るモードが存在しない」状態を選んでおり、コストは明確で、境界も明瞭である。

3.2 沐曦：C550の0.28は「空適応」で、変更はすべてプラグイン内に留まる（11-03）

日付：2026-11-03　情報源：vllm-plugin-FL PR #554 · vllm-plugin-FL PR #693 · FlagGems-vllm PR #1050 · FlagGems-vllm PR #1054

  • 空適配の意味：ベンダー側の MetaX-MACA/vLLM-metax にはまだ 0.28 のパスが存在しないため、#554 は「上流に対応するブランチがない」という前提で行った適配である——すべての変更は vllm_fl/ と MetaX CI スクリプト内に留め、バックエンドの挙動はベンダー名または実行時判定をゲートとし、他のベンダーには影響しない。2838 行追加、70 行削除、36 ファイル。
  • インストール形態：初期の import 修正はプラグイン入口からインストールし、kernel と backend の置換は vendor patch パッケージに配置；独立した site-packages ブートストラップインストーラと vllm_fl/_fl_boot_shims/ を削除し、setup.sh は 15 個の過去の zz_fl_*.pth フックをクリアした。レビューでは「site-packages に起動フックを書き込む」案が明確に否決され、この否決自体が後続のすべてのベンダーに対して有効である。
  • 二線の状態：0.28 がマージされた同じ日、0.32 の C550 適配（#693）が 02:23 にオープンされた；FlagGems-vllm 側では別途 #1050 が疎 QSA の dot tile 下限を 16 に引き上げ、#1054 が GLM5.3 の因果畳み込みと疎 MLA カーネルを C550 上で実行可能にし（審査中）、さらに gdn_w8a16、fused_indexer_weight_scale、layernorm の三つのオペレータ最適化が審査中である。
  • 判断：沐曦のこの調査期間の形態は「0.28 の収束、0.32 の先行実行、オペレータでのロングテール補完」であり、三つの線が同時に動きつつ互いにブロックしない。注目すべきは 0.28 の着地方式である——上流にブランチがないときにプラグインで自足するこの方式が、次回の上流昇級時の移行コストをより低くすることを決定づける。

3.3 摩尔線程：MUSA 0.28 でネイティブ MCCL とセグメント化グラフを一度に導入（11-03）

日付：2026-11-03　情報源：vllm-plugin-FL PR #575 · FlagTensor PR #14 · FlagGems PR #8097

  • 適配内容：#575 は MUSA を vLLM 0.28.0 に引き上げ、同時に通常の wheel インストール、ネイティブ MCCL、FX/eager コンパイル、セグメント化ネイティブグラフを導入し、7804 行追加、233 行削除、46 ファイル。実行ベースラインは S5000 四枚、BF16、TP=4、Python 3.10、TorchMUSA 2.9.0、MUSA SDK 4.3.5。
  • 数値契約：コンパイル側では RMSNorm、SiLU、rotary が明示的な MUSA オペレータ境界を通る；参照 RMSNorm はターゲット側の FP32 累加契約を保持する。この点は極めて重要である——「参照実装が谁的累加精度に従うか」を明確に書くことで、クロスバックエンド比較に意味が生まれる。
  • グラフとキャッシュ：グラフ処理は MUSA ベンダーパッチディレクトリの graph.py に集中し、同時に MUSA コンパイルサブパッケージ、実行可能キャッシュ、ローダーを削除した。清微の「グラフを撤去する」とは逆に、摩尔線程は「グラフを一つのファイルに収める」方式である。
  • 第二の線：FlagTensor #14 はテンソルライブラリに MUSA バックエンドを登録し、七つの超越関数に専用の書き換えを追加した。同日このリポジトリには PPU 直接起動ファストパスと昆仑芯 tile チューニングのコミットもある。FlagGems 側の #8097（審査中）は転置 dot と GEMV tile 最適化で細長い FP8 行列乗算をスリム化する。
  • 判断：摩尔線程は当日唯一「推論プラグイン」と「テンソルライブラリ」の二線で同時に着地したベンダーである。二線の分担も明確である：プラグインはバックエンドの可用性を解決し、テンソルライブラリは下層オペレータの形態を解決する。

3.4 昇騰：0.28 デコードグラフ、CANN 9.2.1 base、INT8 BMM、910C CI の四方面同時進行（11-03）

日付：2026-11-03　情報源：vllm-plugin-FL PR #646 · build-infra PR #1614 · FlagGems PR #8110 · FlagCX PR #669 · FlagTree PR #1413

  • 実行モード：#646 は 0.4.0-dev 上で FULL_DECODE_ONLY のネイティブグラフキャプチャとリプレイを開き、Qwen3.6-27B と Qwen3.6-35B-A3B をカバーし、デコードは torch.npu.NPUGraph を経由し、prefill、視覚エンコード、サンプリングはグラフ外に残す。3342 行追加、340 行削除、39 ファイル。メインブランチ #606 と #619 のフォワードポート。
  • ランタイムバージョン：#1614 は CANN 9.2.1 の base レイヤを新規追加し、910B、python 3.12、torch 2.13 と triton_ascend 3.6.0 のみに対応し、FlagTree と FlagCX を意図的に空欄にしている（詳細は 1.2）。#1615 は 2.3.0 配下の当該レイヤの changelog 日付を遡って埋めた。
  • オペレータ：#8110 はチャネル級 INT8 BMM（bmm_w8a8）を新規追加し、519 行追加、3 行削除。#8286 は 910C と 950DT の SKU ドキュメントを補完。FlagTree 側では lightning-indexer の UB オーバーフロー、swiglu の精度、および tl.where がポインタオペランドを受け入れる問題を修正し、flir #84 は同源の修正。
  • CI：FlagCX #669 は昇騰 910C パイプラインを新規追加し単体テストの編成を統一、1559 行追加、664 行削除、41 ファイル。Torch-FL #690 はネイティブ昇騰の量子数値および無損 FP64 集合通信を補完。
  • 判断：昇騰は「ランタイムバージョン、実行モード、オペレータ、CI」の 4 レイヤで同日に推進しており、当日で最もレイヤが揃ったベンダーラインである。CANN 9.2.1 base で FlagTree を空欄にした選択は、バージョン推進に明確な先行依存関係が存在し、一度に全体をアップグレードするのではないことを示している。

3.5 天数、昆仑芯、燧原、玄鉄、海光と地平線：一方はオペレータをバッチ補完、一方は継続的にチューニング（11-03）

日付：2026-11-03　情報源：FlagGems PR #8093 · FlagGems PR #8357 · FlagGems PR #8374 · FlagGems-vllm PR #1049 · sglang-plugin-FL PR #166 · FlagAttention PR #123

  • 天数：BI-V150 は 16:04 から 16:10 までの 6 分間に 10 本の専用オペレータをマージした。padding 逆伝播、アップサンプリング逆伝播、3 種類の特殊多項式、量子化プーリング、行列積 smm、not_equal、プーリングインデックス逆伝播をカバーする（リストは 1.5 を参照）。これは天数にとって FlagGems における単日ピークであり、しかもすべてが新規実装である。
  • 昆仑芯：マージ側の 11 本は主にチューニングである——argmin はベンダーの min.o の SIMD ペイロードとセグメント化されたワイド行並列を使用し、lcm は展開ユークリッド法、poisson_nll_loss はレジスタプレッシャーを低減し、inner は XPU 上で実際にコンパイルに参加して tile を再調整した。新規オープン側には未明に集中した一連の修正がある：sum_dim のフォールバック、fake_quantize シリーズ、lstm/gru の pipeline event オーバーフロー、linalg_matmul と linalg_lu_solve の tt.gather 降格、avg_pool1d によるプロセス中止など。当該期間に彼一人で 59 本を新規オープンし（燧原 31、昆仑芯 25、英偉達 3）、うち 33 本は 00:07 から 05:43 に集中している。
  • 燧原：GCU300 の正確性修正 4 本（cat の行末、silu_backward の除算セマンティクス、uniform_ の区間、clip のキーワード）。新規オープン側には他に #8374 で汎用カーネルを非 CUDA バックエンドで実行させ、#8375 で修正 Bessel カーネルを非 CUDA バックエンドで実行させるものがある。FlagTree は同期間に enflame3.5-guc400 の CI/CD ワークフローを削除しており、これはハードウェア世代の交代に伴う CI 名簿の変更であり、製品ラインの終了と解釈すべきではない。
  • 玄鉄：FlagGems 側はマージゼロで、動きはコンパイルとプラグイン側にある——FlagTree #1348 は明示的 swizzled を保持する TLE レイアウトをマージし、#8347（審査中）は PPU 上の NT GEMM の K アライメントフォールバックを削除し、sglang-plugin-FL #166（審査中）は RS+norm+AG 融合カーネルを pure TP prefill オプションにし、FlagGems-vllm #1049（審査中）は thead に flash_mla_sparse_fwd を追加する。前回調査期間の 13 本の専用オペレータバッチの後、今回の調査期間はコンパイルと通信層に移行した。
  • 海光：新規オープン #8357 は科学モデル負荷向けの FP32 行列積を最適化し、FlagGems-sglang #279 は _hygon オーバーライドで BW1000 をカバーし、FlagAttention #123 と #117（ともに審査中）はそれぞれ AttnRes バックエンドと GLA の最適化を追加し、FlagTrain #10（審査中）の mixed_gemm は海光をカバーする。
  • 地平線と寒武紀：両社は今回の調査期間に FlagOS の各リポジトリでコミットはない。寒武紀の neuware 4.4.3 層は 2.3.0 名義で changelog の日付補填が完了しており（1.2 を参照）、ミラー側の既存作業に属する。
  • 判断：バックエンド項目は「動作可能な状態の補完」から「チップごとのチューニング」へと移行しつつある——昆仑芯の argmin SIMD 化、海光の FP32 行列積最適化、燧原の非 CUDA 汎用カーネルフォールバックは、いずれもカバレッジの新規追加ではなく、既存実装を特定の負荷でより速く、より安定させるものである。こうした作業はカバレッジの数字には現れないが、実際の可用性を左右する。

4. まとめとトレンド観察

日付：2026-11-03 ~ 2026-11-04　情報源：flagos-ai 組織リポジトリ · マージ済み PR 検索

  • マージ側の加速、生産側の集中：マージ177件は前回の調査期間より9.3%増、新規作成117件は39.1%減、期間内更新のレビュー中271件は12.9%減。ただし新規作成の落ち込みはほぼすべてFlagGems単一リポジトリのリズム変化に由来し、うち59件は同一作者によるもので、昆仑芯と燧原の生産ラインに集中している。組織全体のレビュー中在庫は依然1602件、マージとレビュー中の比率は約1対9で、レビュー負荷は実質的に緩和されていない。
  • 0.28の収束と0.32の開始が同時進行：清微、沐曦、摩尔線程、昇騰の4バックエンドが同一日にvLLM 0.28.0を収束させ、合計150ファイル、17051行の追加となった。同時に0.32の5件の適配がレビューキューで進行中。維持ラインと目標ラインの並行は常態化しており、ベンダーは2セットの検証環境を同時に維持する必要がある。これがマルチチップ適配の隠れたコストである。
  • 評価の比較可能性が新たなインフラに：FlagGemsの2分間23件のベンチマーク移行により、4種類のオペレータのH800参照読み込みが統一JSONに収束し、optestの飛書テストサマリ、FlagTreeの飛書多次元表、FlagCXの4プラットフォームカバレッジと相まって、評価チェーンは「各自が各自で書く」から「同一の物差し」へと変わりつつある。当期は26件がCIと評価側に該当し、マージの14.7%を占める。
  • 新チップ接続の2つの経路がともに開通：壁仞はSUPAバックエンドでTransformerEngine-FLに参入し（骨格先行、ハードウェア検証記録なし）、摩尔線程は推論プラグインとテンソルライブラリの2ラインで同時に着地、天数は1日10件の専用オペレータでオペレータ生産ラインを走る。接続速度はもはやボトルネックではなく、検証の深さこそが課題である——壁仞のバックエンドは現在骨格のみで、清微、沐曦と同等級のハードウェアゲート記録はまだない。
  • 2.3.0は依然イメージ先行：base層は6層（CANN 9.2.1を含む）に拡張済み、ランタイムイメージはバックエンドごとにプッシュ、changelogの日付は層ごとに遡って埋められているが、communityのrelease/2.3マニフェストは依然404を返す。3期連続でマニフェスト凍結の動きは見られず、リリースの実内容と計画の間に乖離が蓄積しつつある。
  • 注視すべき3点：第一に、release/2.3マニフェストがいつ出現するか。これが2.3.0を今月中にリリースできるかを決める。第二に、0.32の5件の適配がいつマージされるか。これが目標ラインが再び延期されるかを決める。第三に、融合通信オペレータ（RS+add+RMSNorm+AG）がPPUとSGLangの試行からクロスバックエンドの汎用部品へと抽象化できるかどうか。

付録

情報源検証表

情報源 検証結果
GitHub組織リポジトリ（61リポジトリ） 24リポジトリが期間内にプッシュ、228件のコミット、177件のマージPR、19リポジトリにマージあり
GitHubレビュー中PR 期間内更新271件、新規作成117件、組織全体のレビュー中在庫1602件
GitHub Release / Tag（31リポジトリ / 8リポジトリ） 期間内の新規ゼロ；FlagCX v0.14.1（11-01 00:10）は期間外
communityリリースマニフェスト release/2.3/release-2.3.yamlは404を返す、release/2.2は掲載中
Google News RSS（中英文24組） コンポーネント級クエリはすべてゼロヒット；メンバー単位と産業語は28件、いずれも企業側またはファイナンス記事
HN Algolia（8組） FlagOS 7件、BAAI 30件、タイトルと本文の直一致は0件
CSDN FlagOSコラム 52件のリンクを逐次時刻確認、最新記事は10-29 11:19、期間内の新規記事なし
智源コミュニティ トップページにFlagOS項目なし；検索ページはクライアントレンダリングで、時刻確認可能なリストなし
メンバー単位GitHub側検証 沐曦、摩尔線程、清微、天数、燧原、海光にFlagOS側の動きあり；寒武紀、地平線は当期間ゼロコミット

完全情報源リスト

agAttention/pull/123>