調査期間：2026-10-26 06:00 ~ 2026-10-27 06:00（北京時間、24 時間；火曜日朝報、期間は前回デイリーレポートの締め切り時点から継続）。

情報源：GitHub（org: flagos-ai 61 リポジトリ全量核查、コミット検索 185 件、マージ済み PR 133 件と審査中 PR 225 件の検索、org イベントストリーム 100 条、31 リポジトリの Release/Tag 原子核查、2 リポジトリの Atom フォールバック、主要 PR 本文とファイル規模の核查）、Google News RSS（24 組の中英語クエリ語、プロキシ経由）、HN Algolia（8 組）、CSDN FlagOS コラム、智源コミュニティ（詳細は付録情報源リスト参照）。

本期インデックス

  • 今日の重点：2.3.0 ランタイムがアプリケーション再構築へ；玄鉄 BLAS1 が一括でリポジトリに格納；FlagCV が初めて公開で位置づけ（10-26）
    1. オープンソースプロジェクトの進捗（GitHub 動態）
      • 1.1 組織のリズム：18 リポジトリがプッシュ、185 件のコミット、133 件がマージ済み、審査中のバックログが 225 件に上昇（10-26 ~ 10-27）
      • 1.2 ランタイム 2.3.0：vllm アプリが再構築の承認を取得、統一タグが確定、AMD ROCm 7.2.4 ベースイメージを新規追加（10-26）
      • 1.3 達摩院玄鉄：FlagBLAS が 15 組の BLAS1 オペレータを一括で補完、一万六千行をリポジトリに格納（10-26）
      • 1.4 FlagGems：49 件がマージ済み、KernelGen オペレータバッチと昆侖芯 XPU3 融合の高速化が並行（10-26）
      • 1.5 FlagQuantum：109 件のコミット、47 件がマージ済み、Quafu SDK 切り替えの収尾と固定 shots 契約（10-26）
      • 1.6 FlagCV：最初の位置づけ説明がマージ済み、Triton 視覚オペレータライブラリが対外的に形成（10-26）
      • 1.7 FlagTrain：KMCompiler の一支が七つのバックエンドに展開、五件が審査中（10-26）
      • 1.8 その他のリポジトリ：FlagTree が MThreads 専用タグを打ち、optest が十三支のベンダーチェックスクリプトをマージ（10-26）
    1. ニュース報道とエコシステム
      • 2.1 清微智能：Open3D-PIMC がオープンソース初公開から三十国の教員研修教室へ（10-26）
      • 2.2 沐曦：RLinf フルスタック適応が公式メインラインにマージ済み、千カードで SFT から RL 後訓練の検証を完了（10-26）
      • 2.3 チャネル核查：12 条の候補中 2 条が有効、CSDN コラムと HN はいずれも新規ヒットなし（10-27）
    1. メンバー単位とバックエンドベンダーの深掘り
      • 3.1 達摩院玄鉄：BLAS1 が一括でリポジトリに格納、fp8 GEMM の玄鉄ブランチは依然審査中（10-26）
      • 3.2 昆侖芯：XPU3 側で三件の foreach 融合、原地 GEMM とビットコード構築（10-26）
      • 3.3 沐曦：SGLang プラグインに MetaX バックエンドの完全パッケージを新規追加、vLLM 側で三条のモデル適応が審査中（10-26）
      • 3.4 清微：TXDA バックエンドが vLLM 0.28.0 に伴いアップグレード、FlagCX パッケージングに清微を組み入れ（10-26）
      • 3.5 燧原、海光、天数、摩尔線程：四つのバックエンドにそれぞれ一件の構造的変更（10-26）
    1. まとめとトレンド観察
  • 付録：情報源核查表と完全情報源リスト

今日の重点：2.3.0 ランタイムがアプリケーション再構築へ；玄鉄 BLAS1 が一括でリポジトリに格納；FlagCV が初めて公開で位置づけ（10-26）

日付：2026-10-26 ~ 2026-10-27　来源：build-infra PR #1488 · FlagBLAS PR #154 · FlagCV · FlagGems PR #7688（全量は付録参照）

  • バージョン面：build-infra は 10-26 20:10 に、20 個の vllm0.24.0 アプリケーションイメージを 2.3.0 ランタイム上で再ビルドすることを承認し、その後タグを「バックエンドごとにサフィックスを付与」から統一タグ 2.3.0-0.3.0 に収束させた。同日 23:05 に AMD ROCm 7.2.4 ベースイメージを追加。バックエンドキーは amd-rocm7.2.4 で、クリーンな ubuntu:24.04 コンテナ内で演習を通過し、ローカルの gfx1100 イメージで 8 枚の W7900 のパススルーを検証した。2.3.0 は「ランタイム更新済み」から「アプリケーション層がバージョン追従を開始」へと進んだが、タグ自体はまだ打たれていない。
  • オペレータ面：FlagBLAS が達摩院玄鉄の L1 サポートをマージし、AMAX、AMIN、ASUM、AXPY、COPY、DOT、DOTC、DOTU、NRM2、ROT、ROTG、ROTM、ROTMG、SCAL、SWAP の 15 組の基礎線形代数オペレータを一括で補完した。変更は 17 ファイル、16,168 行を新規追加。当該 PR は前回のデイリーレポートでは審査中であったが、本調査期間でマージが完了した。これは玄鉄がバックエンドマトリクスにおいて「推論が動く」から「数値ライブラリを補完する」へと向かう一歩である。
  • 方向面：FlagCV が最初の About 説明をマージし、リポジトリの位置づけを「Triton で実装された高性能コンピュータビジョンライブラリ」と記載した。外部には OpenCV 形状の画像処理プリミティブインターフェース（色変換、フィルタリング、幾何変換、算術演算）を提供し、OpenCV の CUDA ベースラインをベンチマークとし、FlagTree の上に構築され、バックエンドはプラグイン可能である。これは組織がビジョン方向で初めてリポジトリを明確に説明したものであり、此前 10-14 のリポジトリ作成、10-18 のスケルトン配置時にはプレースホルダコードのみであった。
  • エコシステム面：沐曦は具身智能向け強化学習フレームワーク RLinf のフルスタック適応を公式メインラインにマージしたと発表した。曦雲 C シリーズ GPU に基づき 512 カードと 1024 カードの 2 段階の SFT、および多シナリオ RL ポストトレーニング検証を完了し、4 組のタスク成功率は論文報告値に一致または超過、うち 1 組は 8.8 ポイント高い。マルチノード拡張の線形度は 97% 以上を維持している。これは FlagOS コンポーネントのリリースではないが、「アップストリーム優先」路線と同源である。
  • リズム面：24 時間の調査期間で 18 リポジトリがプッシュ、185 コミット、133 マージ、225 審査中（新規 74 件）。前回の 24 時間調査期間（10-22：16 リポジトリ、135 コミット、163 マージ、183 審査中、90 新規）と比較して、コミットは 37% 増、審査中は 23% 増、マージと新規はそれぞれ 18% 減——開発は蓄積し、レビューのスループットは低下している。
  • 判断：本期は新バージョンのリリースもなく、モデルの Day-0 同時リリースもなく、内容の重心は「バックエンドの填補」に戻っている。玄鉄は数値ライブラリを補完し、AMD はベースイメージを追加し、清微と沐曦は推論プラグインのバックエンドを補完し、昆侖芯はビットコードと融合オペレータを補完した。こうした作業は見出しにはならないが、2.3 が統一イメージで各社に展開できるかどうかを決定する。2.3.0 の観察点は依然としてタグと全バックエンド changelog が同期して補完されるかどうかである。

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

1.1 組織のリズム：18 リポジトリがプッシュ、185 コミット、133 マージ、審査中の積み残しが 225 件に増加（10-26 ~ 10-27）

日付：2026-10-26 ~ 2026-10-27　情報源：flagos-ai 組織リポジトリ · コミット検索 · マージ済み PR 検索

  • リポジトリ面：61 リポジトリのうち 18 リポジトリが調査期間内にプッシュがあり、数は直近一週間で最多。コミット数順に FlagQuantum 109、FlagGems 28、FlagGems-sglang 14、FlagSparse 7、FlagGems-vllm 5、Torch-FL 5、build-infra 5、vllm-plugin-FL 2、FlagTrain 2、FlagCV 2、残りの FlagBLAS、sglang-plugin-FL、optest、FlagCX、FlagPrism、FlagTree は各 1 件。
  • マージ面：マージされた PR は 133 件、リポジトリ別では FlagGems 49、FlagQuantum 47、FlagGems-sglang 6、Torch-FL 5、build-infra 5、FlagGems-vllm 5、FlagTree 4、sglang-plugin-FL 2、vllm-plugin-FL 2、FlagTrain 2、FlagCV、FlagSparse、FlagBLAS、FlagCX、FlagPrism、optest は各 1 件。
  • 審査中面：調査期間内に更新のあった open PR は 225 件、うち新規作成は 74 件。新規作成の分布は FlagGems 36、FlagTree 8、FlagQuantum 7、vllm-plugin-FL 5、FlagTrain 4、FlagGems-vllm、FlagAttention、FlagGems-sglang は各 3 件。
  • 日次平均対比：調査期間 24 時間で、コミット 185 件（直前の 24 時間期間は 135 件、37% 増）、マージ 133 件（163 件、18% 減）、審査中 225 件（183 件、23% 増）、新規作成 74 件（90 件、18% 減）、プッシュありリポジトリ 18 個（16 個）。
  • リリース面：31 リポジトリの Release と Tag を原子的に核查、FlagTree のみ新規タグ 0.7.1a1+mthreads3.6（10-26 10:13）が追加され、releases リストに対応する Release エントリはなく、純粋な Tag イベントに属する。その他のリポジトリは新規ゼロ。
  • イベント面：org イベントストリーム 100 件、PR イベント 49、プッシュ 20、ブランチ作成 10、ブランチ削除 7、レビュー 3、コメント 9、フォロー 1、Issue 1。
  • 判断：コミット増、マージ減、審査中増の三者が同方向を示しており、キューが滞留しているのであって消化しているのではない。滞留は主に FlagGems（マージ 49 件、同時に審査中 52 件）と FlagTree（マージ 4 件、審査中 9 件）に由来する——この二つのリポジトリはいずれも 2.3 のコンパイラとオペレータ版の準備を進めており、レビュー帯域が現在のボトルネックとなっている。

1.2 ランタイム 2.3.0：vllm アプリが再ビルド認可を取得、統一タグが確定、AMD ROCm 7.2.4 ベースイメージを新規追加（10-26）

日付：2026-10-26　情報源：build-infra PR #1488 · PR #1504 · PR #1502 · PR #1505

  • 再構築承認（#1488）：20 個の vllm0.24.0 アプリケーションに changelog の未リリース項目（原因を含み、日付は空欄）を追加し、プッシュ時の changelog ゲートを満たした後にのみアプリケーションイメージの再構築を許可する。原因は、ランタイムが 10-25 に 2.3.0 スタックへ更新され、その上で構築されたアプリケーションイメージがすべて陳腐化したことである。項目ごとに、アプリケーションイメージが現在何を携帯するかを説明する：ランタイムの 2 つのコンテナ起動パラメータ、バックエンドごとにバージョンを固定した flagcx 0.14.0、そして venv プレフィックス。
  • タグ収束：同一 PR の 2 番目のコミットで、ネイティブプラグインタグをイメージタグから外し、統一されたリゾルバが決定するように変更した。これにより、バックエンド接尾辞のない統一タグ 2.3.0-0.3.0 が成立する。3 番目のコミットでは、changelog と schema ヘッダで reason フィールドを markdown で公開することを宣言し、複数の変更をリストとして読めるようにした。
  • 新規バックエンド（#1504）：AMD ROCm 7.2.4 ベースイメージが着地。バックエンドキーは amd-rocm7.2.4、ベースは Ubuntu 24.04 に repo.radeon.com から直接インストールした ROCm 7.2.4 で、ファイルリポジトリは使用しない。わずか 28 個の精鋭パッケージのみをインストールし、apt がランタイム依存を解決した後の合計は 94 個。MIOpen、MIGraphX、rocm-gdb、rocprofiler-sdk、opencl は明確に除外。演習で Containerfile に必ず書き込むべき 2 つの事実が判明した：amd ノードは archive.ubuntu.com に到達できないため、ca-certificates が存在する前に阿里雲 HTTP ミラーに切り替える必要がある（HTTPS ではハンドシェイクが失敗する）。pin ファイルはバージョン嗜好ではなく必須項目である。
  • 障害除去 2 件：22:27 の #1502 でネイティブプラグインゲートが同一インタプリタ内で完走するようになり、22:45 の #1503 で vllm プラグインタグを sglang のドキュメントページから外し、 #1505 でバックエンドタグではなくタグが実際に携帯するプラグイン pin を出力するように変更した。
  • 判断：今回の一連の動作はすべて「リリース可能性」に集中している——ゲート、痕跡、タグ形態、ベースイメージ。10-25 のランタイム再構築承認と合わせて見ると、2.3.0 のパイプラインはすでに端から端まで一度走り切っており、あとは正式なタグ付けと全バックエンドイメージの一括再出力のみである。AMD バックエンドの追加は、バックエンドマトリクスが 2.3 サイクルでもなお拡大しており、収束していないことを意味する。

1.3 達摩院玄鉄：FlagBLAS が 15 組の BLAS1 オペレータを一挙に補完、1 万 6 千行をリポジトリに投入（10-26）

日付：2026-10-26　情報源：FlagBLAS PR #154 · FlagBLAS コミット

  • 規模：単一 PR で 17 ファイルを変更、16,168 行を追加、9 行を削除、マージ時刻は 10-26 08:57。当日の非量子リポジトリの中で最大規模の一件である。
  • カバレッジ：BLAS 第 1 層の 15 組のオペレータを一度に補完——ベクトル最大値と合計（AMAX、AMIN、ASUM）、ベクトル加算とコピー（AXPY、COPY）、3 種類の内積（DOT、DOTC、DOTU）、ユークリッドノルム（NRM2）、4 種類の平面回転（ROT、ROTG、ROTM、ROTMG）、ベクトルスケーリングと交換（SCAL、SWAP）。
  • レイヤ：これは数値ライブラリ層の補完であり、推論オペレータの補完ではない。BLAS1 は上位の BLAS2 と BLAS3、および LAPACK ソルバの前提依存であり、1 層欠けるとボトムアップで自己整合できない。玄鉄にとって、これまで FlagOS での存在感は推論パス（真武 Express 版、疎注意）に集中しており、数値ライブラリは空白であった。
  • チェーン：当該 PR は前回のデイリーレポートではまだレビュー中と記録されていたが、本調査期間でマージが完了し、「レビュー中」から「リポジトリ投入」まで 1 ウィンドウを跨いだ。
  • 判断：あるバックエンドの FlagOS における成熟度は、通常「推論が動く、訓練が動く、数値ライブラリが自己整合する」の 3 段階で測る。玄鉄は本調査期間で第 3 段階の第一歩を踏み出した。今後は BLAS2 と BLAS3 が追随するか、および FP8 パス（FlagTrain 側でレビュー中の fp8 GEMM に玄鉄ブランチがある）が同一の数値ライブラリを共用できるかを見る必要がある。

1.4 FlagGems：49 件マージ、KernelGen オペレータバッチと昆仑芯 XPU3 融合高速化が並行（10-26）

日付：2026-10-26　情報源：FlagGems コミット · PR #7676 · PR #7635 · PR #7669

  • 総量：28 件のコミット、49 件のマージ。コミット量は全組織で2位、マージ量は1位。マージ数がコミット検索数より多いのは、マージコミットと圧縮コミットの集計基準の違いによるもので、マージ数を基準とする。
  • KernelGen バッチ：KernelGen と Nvidia をプレフィックスとするオペレータのマージが16件、10:41〜10:43、18:17〜18:20、23:05〜23:06 の3つの時間帯に集中：スパース・構造化関連（_sparse_semi_structured_tile、_sparse_mm_reduce_impl、sparse_compressed_tensor）、量子化関連（choose_qparams_per_tensor、make_per_tensor_quantized_tensor）、特殊関数（special_psi、special_scaled_modified_bessel_k0）、テンソルメタ情報（_version、_nested_compute_contiguous_strides_offsets、ravel、new_zeros）、さらに _foreach オペレータファミリの受け入れ高速化が1件。
  • 昆仑芯高速化：XPU3 側の変更5件——addmm_ は GEMM をインプレースのターゲットに直接書き込み（#7676）、less_equal は NaN に安全な比較に変更（#7688）、isfinite カーネル最適化（#7631）、および foreach の3件（三項スカラー融合、div はより高速な List カーネルへ、log はマスク除去を融合）。このグループは典型的なバックエンドチューニングであり、変更は小さく、効果は局所的。
  • 欠陥修正：QC 側で FP8 TopK の TLE scatter アドレッシングを修正（#7669）、昆仑芯側で logical_and と登録エラーを修正（#7666、#7670）。
  • テスト側：同一の貢献者が20件余りのテスト契約修正をバッチマージ（候補エントリポイント、ネイティブ参照注入、オーバーロード選択、foreach の事前失敗）。「テスト自体が壊れた」大量のケースを失敗から取り除いた。
  • 判断：オペレータの供給は依然として KernelGen の自動生成バッチが主体であり、人手の介入は主にバックエンドチューニングとテスト契約の両側で発生している。この構造から導かれる品質リスクは「オペレータの書き間違い」ではなく、「テストカバレッジは一見揃っているが、実は参照実装が欠けている」ことである——今回の調査期間における20件余りのテスト修正は、まさにこのリスクが顕在化したものである。

1.5 FlagQuantum：109 件のコミット、47 件のマージ、Quafu SDK 切り替えの収尾と固定 shots 契約（10-26）

日付：2026-10-26　情報源：FlagQuantum コミット · PR #874 · PR #919 · PR #924

  • 総量：109 件のコミット、47 件のマージ。コミットは全組織の58.9%、マージは35.3%を占め、依然として最も活発なリポジトリだが、前回（72時間で505件）と比べて日平均は約3分の1にまで低下した。
  • Quafu 切り替えの収尾：読み取り専用 SDK の切り替えを完了（#874）、動的 mock を Quafu SDK に収束（#880）、動的フォーマットのアクティベーションとソース監査を提案（#881、#883）、さらにサンプル側でリモート実行の mock をすべて改道。これは前回の「ライフサイクル全体の切り替え」の収尾段階である。
  • Rydberg 路線：シード付き presence 計画の実行（#879）、選択された Rydberg 分支の進化（#875）、受け入れ記録のドキュメント化（#882）により、契約から実行可能なパスへと移行。
  • 誤り訂正符号（QEC）：固定 shots 実験の設計稿と契約稿が相次いでマージ（#912、#924）、チャネル構築テンプレートの再利用による高速化（#877）、原生生産段階の引き継ぎと独立失敗クローズドループの記録（#917）、AI デコード納品進捗の2回の整合（#890、#895）。
  • API とサンプル：iSWAP ゲート対を追加（#919）、Circuit と DynamicCircuit のゲートチェーンを型付きの流暢なインターフェースに変更（#913）、ゲートカバレッジ Batch A 提案（#915）、吸収式光子計数サンプルに受け入れを追加（#921）、固定熱浴における spin-mode モデルフィッティングサンプル（#897）、Twin 候補と手動ゲーティング進化周期（#923、#926）。
  • 判断：量子スタックのリズムは「構造再編」から「物理シナリオの展開」へと移行した——誤り訂正符号、中性原子、熱浴の3種類のシナリオが同時に進行し、いずれも「設計稿、契約稿、実行可能サンプル、受け入れ記録」の4段階で証跡を残す。この作業方式はコストが高いが検証可能性に優れ、それが長期的に大部分のコミット量を占める理由でもある。

1.6 FlagCV：初の位置付け説明がマージ、Triton 視覚オペレータライブラリが対外的に成形（10-26）

日付：2026-10-26　ソース：FlagCV · FlagCV PR #2

  • 位置づけ：FlagCV は自らを「Triton で実装された高性能コンピュータビジョンライブラリ」と位置づけ、OpenCV 形式のインターフェースの下で一般的な画像処理プリミティブ——色変換、フィルタリング、幾何変換、算術演算——を提供し、OpenCV の CUDA ベースラインをベンチマーク対象として、多様な GPU アーキテクチャ上でリファレンス級の正確性と競争力のある性能を達成することを目標としている。
  • 依存関係：FlagTree（FlagOS が保守する Triton ブランチで、マルチハードウェアバックエンドをサポート）の上に構築され、外部にはベンダー非依存のオペレータインターフェースを提供し、バックエンドはプラグイン可能である。
  • タイムライン：リポジトリは 10-14 に作成され（当時はプレースホルダのみ）、10-18 にスケルトンを落とし込むとともにオペレータ実装を撤去して「即時モードスケルトン」へ変更、10-26 に About と README の説明をマージした。すなわちコードスケルトンが先行し、位置づけの説明が後から続いた形であり、本調査期間で補われたのは「このリポジトリが結局何をするのか」である。
  • 判断：ビジョンは FlagOS 体系の中で従来最も薄い部分であった——既存の FlagDNN、FlagSparse、FlagFFT、FlagBLAS はあるが、画像処理プリミティブ層がなかった。FlagCV はビジョンを別のコンパイラを立ち上げるのではなく FlagTree に接続しており、方向性は「一度の開発、マルチチップでの実行」と一致している。真の検証点は色変換や幾何変換といったメモリアクセス集約型オペレータが非 GPU バックエンド（NPU、DSA）上でどう振る舞うかであり、現時点で性能データはまだない。

1.7 FlagTrain：KMCompiler の一支が七つのバックエンドに展開、五件がレビュー中（10-26）

日付：2026-10-26　ソース：FlagTrain PR #29 · PR #30 · PR #35 · PR #18

  • マージ済み二件：#29 は fused_indices_to_multihot の Triton 実装を追加し、NVIDIA と昇騰をカバー、H20 上でベンチマーク記録あり。#30 は FlagGems-vllm のベースライン対照メカニズムを移植し、デバイスのボトルネック単位のピークスケーリング係数で速度比を正規化し、「vs Base」列を出力、ベースライン欠如時は理由を記録して失敗させず、さらに lamb ベースラインとオペレータ別集計ツールを追加した。
  • レビュー中五件：#34 tanh_soft_clamp（NVIDIA、昇騰、海光、玄鉄、沐曦、天数）、#35 multi_tensor_adam（NVIDIA、海光、沐曦、地平線 PPU、天数）、#18 fp8_gemm（NVIDIA、昇騰、玄鉄、沐曦）、#10 mixed_gemm（NVIDIA）、#28 fused_proj_rms_compute_h_fwd（NVIDIA）。
  • 構造的特徴：単一 PR のタイトルにバックエンド一覧を直接列挙するのは、FlagTrain のこの一支の定型的な書き方である——一つのオペレータをバックエンドマトリクスに沿って一度に展開し、バックエンドごとに個別にコミットするのではない。七つのバックエンド（NVIDIA、昇騰、海光、玄鉄、沐曦、天数、地平線）が同一批次の PR に現れている。
  • 判断：FlagTrain は 2.3 サイクルで明らかに加速しており、訓練側のオプティマイザ、MoE、量子化 GEMM の三種のオペレータに集中している。これは FlagGems（推論オペレータ）と分業を成しており、両者とも KernelGen で Triton 実装を生成し、バックエンドごとに補完している。違いは FlagTrain がクロスバックエンドの一貫性により依存するため、その PR の受け入れ基準もより高く、五件が同時にレビュー中であることも不思議ではない。

1.8 その他のリポジトリ：FlagTree が MThreads 専用タグを打ち、optest が十三社のベンダーチェックスクリプトをマージ（10-26）

日付：2026-10-26　ソース：FlagTree tags · FlagTree PR #1410 · optest PR #11 · FlagGems-sglang PR #227

  • FlagTree：10-26 10:13 にタグ 0.7.1a1+mthreads3.6 を打った。0.7.x ラインの MThreads 専用ビルドを指すが、releases リストに対応する Release エントリはなく、純粋な Tag イベントである。バックエンド側の実質的な変更は 10-23 の #1416（MTHREADS バックエンドが上流コミットに追従）に由来する。調査期間内に4件をマージした：FlagMega が Qwen3 vLLM profile のスライス型を再推論（#1373）、HCU バックエンドが set_layout をサポート（#1410）、ROCm が HIP ホスト登録インターフェース経由で source-rdata をロード（#1403）、プーリング ABI の bank 行インデックスを tl 値で渡す（#1404）。
  • optest：ベンダーごとに分かれていた13本の GPU チェックスクリプトを単一の flagos-gpu-check コマンドに統合（#11）。「ベンダー専有デバイスノードを優先し、SMI コマンドで二次確認する」順序で自動検出し、各ベンダー固有のカード別テーブル、タイムアウト、リトライパラメータを保持する。ベンダー衝突ルールには「海光は AMD より先（両方とも kfd を持つが、mkfd を持つのは海光のみ）」「玄鉄は英偉達より先」と明記されている。
  • FlagGems-sglang：6件をマージ。競賽トラックのオペレータ2件（add3、create_chunked_prefix_cache_kv_indices）、batch8 オペレータ群、クラッシュするグループ化カーネルの除去2件、インポート時にデバイス情報を読む問題の修正を含む。#227 ではディレクトリに登録漏れのあった16個のオペレータを operators.yaml に追加した。
  • FlagSparse、FlagPrism、FlagCX：FlagSparse は7件をコミットし、外部組織からの一括最適化をマージ（#114）。FlagPrism は燧原側の tops ヘッダファイルとライブラリ依存解決をマージ（#17、2,126 行）。FlagCX は昆仑芯 XPU デバイスビットコードのビルドをマージ（#676）。
  • 判断：このグループで最も記録に値するのは optest のマージである——テスト施設が「ベンダーごとに1本のスクリプト」から「1本の自動検出コマンド」へと変わったのは、マルチバックエンドの規模拡大後に必然的に行き着く一歩だ。ベンダー順序における2つの衝突ルール（海光対 AMD、玄鉄対英偉達）は、デバイス検出が異種環境において単一シグナルでは判断できなくなったことを示している。

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

2.1 清微智能：Open3D-PIMC がオープンソース初公開から30カ国の教員養成教室へ（10-26）

日付：2026-10-26　情報源：金融界（搜狐転載）：技術大会から30カ国の教室へ · 新華網：Open3D-PIMC が国産算力ソフトウェアエコシステムの鍵となるピースを補完

  • プロジェクト：Open3D-PIMC は清微智能と北京智源人工智能研究院が共同開発した、3D 算力チップ向けのプログラミングモデル兼オープンソースソフトウェアフレームワークである。9月に中国算力大会で正式にオープンソース化され、衆智 FlagOS の次世代 3D チップ向け主要ソリューションの一つと位置づけられている。
  • 技術的アプローチ：開発者はデータ分布とタスク分割のみを記述し、フレームワークがグラフコンパイルと即時実行の分割・呼び出しを自動で行い、モデルをハードウェアへ適合させる。PyTorch など主流エコシステム上に育ち、推論側は vLLM と SGLang にネイティブ接続する。Flash Decoding、MoE のような強い動的オペレータには手書き最適化の入口を残す。各ベンダーの専有命令セットとマイクロアーキテクチャ能力はプラグイン形式で接続する。
  • ハードウェア背景：清微の第2世代高性能クラウド AI チップは、3D 存算一体とマルチチップレット合封により記憶と計算を立体的に積層し、データ移動距離をミリメートル級からマイクロメートル級へ圧縮する。遅延は集中型アーキテクチャの非決定的で衝突しやすい性質から、近存側の予測可能で決定的な性質へと変わる。
  • 本期進展：10-26 の報道はコードではなくエコシステム普及に焦点を当てている——世界「AI オープンコンピューティング教員発展計画」により清微のエンジニアが教室に入り、受講者は30カ国以上から集まった約50名の大学骨干教員（アフリカ20余名、アジア10余名、残りは欧州と南米から）である。
  • 口径説明：文中の「FlagOS は既に20社のチップベンダー、30余款の AI チップに適応」は報道側の口径であり、10月の開放計算大会で公式に示された21社、35チップとは完全には一致しない。引用時は前者を報道に帰属し、後者を大会に帰属させるのが適切である。
  • 判断：この記事の価値は「また一つのオープンソースリリース」にあるのではなく、FlagOS エコシステムの新たなパスを示している点にある——まずメンバー単位が新たなハードウェア形態（3D 積層）向けのプログラミングモデルを主導して作り、それを FlagOS にソリューションとして接続する。「モデルの Day-0 適応」と比べ、これは「ハードウェア形態が先行する」もう一つの拡張類型である。

2.2 沐曦：RLinf のフルスタック適応が公式メインラインにマージ、千カードで SFT から RL 後訓練検証を完了（10-26）

日付：2026-10-26　情報源：同花順財経による沐曦股份公式微信転載 · 沐曦公式サイトニュースセンター

  • 事象：沐曦股份が具身智能向け大規模強化学習フレームワーク RLinf のフルスタック適応を完了し、適応方案が RLinf 公式メインラインにマージされた。開発者はコードを変更せずに沐曦 GPU 上で RLinf のトレーニングタスクを実行できる。
  • フレームワーク背景：RLinf は清華大学と無問芯穹が北京中関村学院などの機関と共同で発表したもので、「模倣・訓練・推論一体型」として具身智能向けでは初の大規模強化学習フレームワークと位置付けられ、その成果は OSDI、RSS、NeurIPS などの会議に採録されている。
  • 検証規模：曦雲 C シリーズ GPU クラスタに基づき、512 カードと 1024 カード（128 ノード×8 カード）の二段階の SFT を完了し、Pi0.5 モデルを RoboTwin データセット上で訓練した。四組のタスク成功率はすべて論文報告値に一致または超過し、うち一組は 8.8 ポイント高かった。マルチマシン拡張の線形性は 97% 以上を維持している。
  • 接続方式：プラグインモードによる四層の整合——アクセラレータ抽象層にデバイスマネージャを追加し RLinf レジストリに登録、環境変数でマルチカードの可視性を制御し Ray スケジューリングと協調、通信はデフォルトで沐曦集合通信ライブラリ MCCL を使用、ソフトウェアスタックは MXMACA ベースの PyTorch と FlashAttention で BF16 と FSDP をサポート。
  • ロードマップ説明：沐曦はこれを「上流優先」戦略の継続と位置付けており、これまでに LMCache と ms-swift の公式メインラインにもマージ済みである。
  • 判断：本件は FlagOS コンポーネントのリリースには該当せず、メンバー単位のオープンソースエコシステムの動きとして記録すべきである。注目すべきは方向性である——具身智能の強化学習トレーニングスタックは、FlagOS 側の FlagOS-Robo、FlagScale 訓練ツールとシーンが重複しており、将来「メンバー単位が先に上流フレームワークへマージし、その後 FlagOS がバックエンドを統一して収束させる」というリレーが発生するかどうかは、追跡に値する手がかりである。

2.3 チャネル核查：12 件の候補中 2 件が有効、CSDN コラムと HN はいずれも新規ヒットなし（10-27）

日付：2026-10-27　情報源：Google News RSS · CSDN FlagOS コラム · HN Algolia

  • ニュース側：24 組の中英クエリ語について調査期間内に合計 12 件の候補があり、2 件が有効（清微 Open3D-PIMC、沐曦 RLinf）。コンポーネント名クエリ（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）はすべてゼロヒットで、直近二週間の常態と一致している。
  • 除外明細：燧原科技関連の 4 件は融資・証券貸借、朝報、上場回顧類の稿件（同社は実際には 9 月 11 日に科創板へ上場済みであり、10-26 の「本日上場」という見出しは転載稿のため採用しない）。摩尔線程の 1 件は株価と出来高。智源と北京日報社の GEOInflow 2 件はメディア技術協力に属し FlagOS とは無関係。国産算力廠商全景復盤の 1 件は業界綜述。
  • HN 側：8 組のクエリ（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）で 4 日間の調査期間内に合計 34 件のヒットがあったが、タイトルが直接一致するものはない。
  • CSDN 側：コラムページには 51 件の記事リンクがあり、最新の資訊稿は依然として 8 月下旬（GLM-5.3-Flash 九芯、Qwen3.8-Flash-Next 八芯、LightX2V 接続）である。調査期間内で唯一の新しい日付は 10-22 の高校円卓ライブページであり、新稿はない。
  • 智源コミュニティ：検索ページはクライアントレンダリングのため、フレームページのみ取得でき、今回は採用しなかった。
  • 判断：ニュース面では連続三回目の調査期間がメンバー単位のプレスリリースのみであった。FlagOS 自身の对外発信のリズムとコードのリズムは明らかに同期しておらず——コードはバックエンドを埋めており、発信は次のモデルまたはバージョンの節点を待っている。

3. メンバー単位とバックエンド廠商の深掘り

3.1 達摩院玄鉄：BLAS1 が一括でリポジトリに格納、fp8 GEMM の玄鉄ブランチはなお審査中（10-26）

日付：2026-10-26　情報源：FlagBLAS PR #154 · FlagTrain PR #18 · optest PR #11

  • FlagBLAS：15組のBLAS1オペレータを一度にマージ、17ファイル、16,168行。玄鉄によるFlagOS数値ライブラリ層での初の組織的なコミットである。
  • FlagTrain：審査中のfp8_gemmはNVIDIA、昇騰、玄鉄、沐曦の4社をカバーし、玄鉄はその中で唯一のRISC-Vベクトル路線である。同じく審査中のtanh_soft_clampにも玄鉄が含まれる。
  • テスト施設：optestのベンダー競合ルールは玄鉄をNVIDIAより前に配置する。理由は両者のデバイスノード探索が衝突する可能性があるため。このルール自体が、玄鉄が既にCIの実機プール内にいることを示している。
  • 経緯：10-23から10-25の調査期間で、玄鉄は真武Express版の納品とPPU疎注意力の審査中を完了した。当期間は数値ライブラリへと軸足を移した。
  • 判断：玄鉄のFlagOSにおける動きは既に3期間連続で「一度に1つの整塊」のリズムを保っている——推論、注意力、数値ライブラリ。次はBLAS2とBLAS3、そしてCPU側（optestのtheadベンダーキー）がアクセラレータカード側と同一の検査スクリプトを共用するかどうかを見る。

3.2 昆侖芯：XPU3側のforeach融合3件、原地GEMMとビットコード構築（10-26）

日付：2026-10-26　情報源：FlagGems PR #7676 · PR #7635 · FlagCX PR #676 · FlagCX PR #677

  • オペレータ側：XPU3上の6件の変更。addmm_はGEMMを直接原地ターゲットに書き込むことで一度の中継を省略、less_equalはNaNに安全な比較交換でオペランドを操作、isfiniteカーネル最適化、foreach融合3件（三項スカラー、divのListカーネル、logのマスク除去）。
  • 通信側：FlagCXが昆侖芯XPUのデバイスビットコード構築をマージ（#676）——Makefileで共有デバイスAPIラッパーをxpu3のLLVMビットコードにコンパイルし、XTDKアンロードパッケージからデバイスモジュールを抽出、共通シンボルを保持して最適化、libflagcx_device.bcと消費側ヘッダーファイルを生成、通信traitsはXSHMEM経由。審査中の#677は1万未満のバージョンコードに対するflagcxGetVersionのデコードを修正。
  • 修正面：FlagGemsはlogical_andと登録エラーの2件を修正。審査中4件（cholesky_solveの複素数パスと上三角修正の2件、foreach_divの_result_dtypeローカライズ、バッチオペレータがFlagTree当日ビルドに依存）。
  • 判断：昆侖芯の今期の全動作は「既存パスの高速化と安定化」であり、新機能はない。これは過去2週間の形態と一致する——接続が最も早く、カバレッジが最も広いため、ロングテール最適化段階に入るのも最も早い。ビットコード構築は例外で、昆侖芯をFlagCXの統一デバイス抽象に接続するもので、長期的価値は単一オペレータの高速化を上回る。

3.3 沐曦：SGLangプラグインにMetaXバックエンドの一式を新規追加、vLLM側ではモデル適応3件が審査中（10-26）

日付：2026-10-26　情報源：sglang-plugin-FL PR #50 · vllm-plugin-FL PR #642 · FlagGems-vllm PR #998

  • SGLang バックエンド：31 ファイルをマージし、3,364 行を新規追加した MetaX と MACA のバックエンドパッケージ。可用性検出、CUDA 互換実装の再利用と沐曦側ラッパー（silu_and_mul、rms_norm、rotary_embedding、topk、fused_moe、FLA ゲート付き delta ルールなど）を含み、さらに SGLang 内部にランタイムパッチ（FlashInfer アテンションバックエンド互換、MCCL が支える PyNCCL ラッパー、サンプリングバックエンドの挙動、torchvision JPEG デコードのフォールバック）を追加し、併せて metax.yaml のディスパッチ設定と Qwen3 27B、35B-A3B のサンプルスクリプトを補完。
  • vLLM 側は審査中：#642 で TXDA 以外のスケジューリング経路を vLLM 0.28.0（清微）に調整、#635 で Qwen3.8-Flash-Next の BF16 ベースラインを追加、#636 で BGE-M3 の初期適配を追加。
  • オペレータライブラリ：#998 は審査中で FlashAttention の精度とグラフキャプチャの問題を修正し、TP2 と TP4 の性能を最適化；#1000 は審査中でインプレース MoE アラインメントで未サポートの TLE をスキップ。
  • エコシステム側：RLinf メインラインをマージ（2.2 参照）。これは具身智能方向における「アップストリーム優先」の着地である。
  • 判断：沐曦の今回の重心は推論プラグインから SGLang バックエンドのパッケージ全体とアップストリームフレームワークのマージという 2 つのラインに移っている。SGLang プラグインは従来、昇騰、海光、天数など数社のみだったが、MetaX の参加により推論フレームワーク側のベンダーマトリクスはほぼ補完された。今後は vLLM 0.28 のアップグレードが SGLang 0.5.18 のリズムと整合するかを見極める必要がある。

3.4 清微：TXDA バックエンドは vLLM 0.28.0 アップグレードに追随、FlagCX のパッケージングに清微を組み込み（10-26）

日付：2026-10-26　情報源：vllm-plugin-FL PR #642 · FlagCX PR #673 · 金融界転載：Open3D-PIMC エコシステム推進

  • プラグイン側：審査中の #642 で TXDA バックエンドを vLLM 0.28.0 に適配。2.3 サイクルにおける「プラグインがアップストリームのメジャーバージョンに追随する」一連の作業に属する。
  • パッケージング側：審査中の FlagCX #673 で RPM パッケージングを清微、曦望、海光の 3 バックエンドに拡張。清微はそのうちの 1 つ。
  • ビルド側：10-22 に清微 TX8 を FlagTree ビルダーに接続しデイリービルド行に追加、6 番目のバックエンドとなった。今回の調査期間に新たなビルド変更はなし。
  • エコシステム側：Open3D-PIMC の対外展開を継続的に推進（2.1 参照）。FlagOS が次世代 3D チップ向けに提供する主要ソリューションとして明確に位置づけられている。
  • 判断：清微の形態は他のメンバーと異なる——FlagOS においてバックエンド（TX8、TXDA）であると同時に、新ハードウェア形態（3D スタッキング、Open3D-PIMC）の牽引役でもある。2 つのラインは現時点でコード上では交差していない。将来 Open3D-PIMC のバックエンドが FlagTree の TX8 経路を直接再利用するようになれば、真の合流となる。

3.5 燧原、海光、天数、摩尔線程：4 つのバックエンドにそれぞれ構造的変更が 1 件（10-26）

日付：2026-10-26　情報源：FlagPrism PR #17 · Torch-FL PR #654 · Torch-FL PR #660 · FlagTree tags

  • 燧原：FlagPrism に tops ヘッダーファイルとライブラリ依存関係の解析をマージ（#17、16 ファイル、2,126 行）。燧原 SDK のヘッダーファイルとライブラリ検索を暗黙から明示に変更。FlagAttention には燧原側の融合アテンションオペレータ（fused_attnres）が審査中。
  • 海光：Torch-FL が DCU ランタイムのビルドソースを修正（#654）——DCU の runtime_dir が元々 ABI シムのみを置くディレクトリを指していたため、ランタイムライブラリが 32 個のスタブからリンクされ、ビルドは通るが import すると未定義シンボルでエラーになっていた。変更は 71 ファイル、1.1 万行。同日審査中の #627 はボックス化を有効にした DCU ビルドに実際のストリームを接続。
  • 天数：Torch-FL #660 が Iluvatar 上の bf16 GEMM がホスト実行にフォールバックする問題を修正——2048 平方の bf16 mm は実測 0.41 TFLOPS で、同機 CPU の 0.54 を下回り、同オペレータの fp16 は 80.2、ベンダー製 torch は 84.6 であった。根本原因はサポート判定に bf16 が含まれておらず、mm と addmm がホスト側で転置重みをコピーしていたこと。修正後はベンダー BLAS を使用。
  • 摩尔線程：FlagTree が MThreads 専用タグ（0.7.1a1+mthreads3.6）を打ち、FlagGems-vllm が chunk_kda の MThreads 最適化をマージ（#990）。MUSA バックエンドの TLE キャッシュ永続化変更は先週すでに反映済み。
  • 判断：4 社に共通するのは「動くが遅い、あるいは途中で落ちる」問題の修正であり、新規オペレータの追加ではない。こうした欠陥は外部での再現が最も難しく、バックエンドマトリックスの実完成度を最もよく示す。ベンダー側のコミットは依然として自社プラットフォームの正確性と性能が中心で、クロスプラットフォームの統一セマンティクスの作業は引き続き FlagOS 主干が推進している。

4. 総括とトレンド观察

  • 2.3.0 は完全なパイプラインを一通り走完了したが、タグは依然として未打：ランタイムのゲート、changelog、再ビルド授权、バージョンパラメータ化は 10-23 から 10-25 に整備され、10-26 にアプリケーション層の再ビルドを授权しタグを 2.3.0-0.3.0 に収束させた。「ランタイム刷新」から「アプリケーション追随」へのこの段階は通常正式リリースに直結するため、今週も重要な観察ウィンドウである。
  • バックエンドマトリックスは収束ではなく拡張中：AMD ROCm 7.2.4 ベースイメージが新規追加され、2.3 サイクルがまだプラットフォームを追加していることを示す。これに対応して、玄鉄が BLAS1 を補完、清微が RPM パッケージングに接続、昆仑芯がデバイスビットコードを補完——4 件は数値ライブラリ、パッケージング、通信の 3 層に分属し、いずれも「接続後に初めて必要になる」作業である。
  • 数値ライブラリと学習スタックが新たな戦場に：FlagBLAS が一度に 15 組の BLAS1 オペレータを補完、FlagTrain が一批のオペレータを 7 社のバックエンドに展開、両ラインとも 2.3 サイクルで加速中。推論オペレータの限界収益は低下しており（FlagGems 本期は KernelGen 自動生成バッチとバックエンドチューニングが中心）、学習と数値ライブラリのギャップがより顕著である。
  • ビジョン方向が初めて形を成すが、性能証拠を欠く：FlagCV は位置づけを「Triton 実装の OpenCV 形状ビジョンオペレータライブラリ、OpenCV CUDA ベースラインに対標」とし、FlagTree に接続。現時点では説明と骨格のみで、ベンチマークや非 GPU バックエンドのデータは一切なく、その価値を判断するには尚早である。
  • レビュー帯域がボトルネックに：コミット増 37%、審査中増 23%、マージ減 18%、新規開設減 18%。開発側は蓄積し、レビュー側は消化している。FlagGems と FlagTree の 2 リポジトリの審査中量（52 と 9）とマージ量（49 と 4）の落差が最も顕著で、この 2 リポジトリはまさに 2.3 のコンパイラとオペレータバージョンの供給元である。
  • 量子スタックがシナリオ展開期に：誤り訂正符号、中性原子、熱浴の 3 類の物理シナリオが同時期に推進され、依然として 4 段階の証拠留下作業に従っている。全組織のコミットの近 6 割を引き続き占めるが、前回比の日平均は既に 3 分の 2 に回落している。
  • 情報面は連続 3 番目のウィンドウで成員単位の通稿のみ：12 件の候補中 2 件が有効、FlagOS 自身はリリースなし、新規リポジトリなし、対外公告なし。内容の主体は依然として GitHub からのもので、典型的な「コードがバックエンドを埋め、伝播がノードを待つ」ウィンドウである。
  • 局限性の説明：コミット検索は GitHub search の total_count 基準（185 件）で、マージ PR 検索（133 件）とは圧縮マージとインデックス遅延により基準差があり、FlagGems でマージ数（49）がコミット検索数（28）を上回るのはこの類であり、報告内ではマージ数を基準とする；FlagQuantum の 109 件はマージとブランチ同期コミットを含み、109 件の機能変更と同義ではない；FlagTree の 0.7.1a1+mthreads3.6 は Release リストと Tag インターフェースの双方向照合により純 Tag と確認され、Release 説明はない；ベンダー通稿中の「コード変更不要」「論文に匹敵または超過」等の表現は会社側の口径であり、第三者による再現は取得していない；清微稿件中の「20 社、30 余款チップ」は大会口径の 21 社、35 チップと不一致であり、本文中に帰属を注記済み。

付録：情報源核查表と完全情報源リスト

情報源核查表

情報源 検証結果
GitHub 組織リポジトリ API 61 リポジトリ全量返却、18 リポジトリが24時間枠内にプッシュあり
GitHub コミット検索 185 件、URL により16 リポジトリに帰属
GitHub マージ済み PR 検索 133 件が枠内にマージ、最多は FlagGems の49 件
GitHub 審査中 PR 検索 225 件が枠内に更新、うち新規オープン74 件
GitHub org イベントストリーム 100 条、PR 49、プッシュ 20、ブランチ作成 10、ブランチ削除 7、コメント 9
Release と Tag の原子的検証 31 リポジトリ中 FlagTree のみ新規タグ1件追加、Release エントリなし
Tag と Release のクロスチェック 0.7.1a1+mthreads3.6 は releases リストと git ref インターフェースの双方向で純粋な Tag であることを確認
Atom フォールバック docs、release-info の2リポジトリを補査、メインブランチに枠内コミットなし、プッシュは非デフォルトブランチに着地
主要 PR 本文検証 15 件を1件ずつタイトル、変更行数、マージ時刻を照合
Google News RSS 24 組の中英語クエリで12 件の候補、有効2 件（プロキシ経由）
HN Algolia 8 組のクエリで4日間34 件ヒット、タイトル直接一致なし
CSDN FlagOS コラム 51 件のリンク、最新のニュース稿は8月下旬、枠内に新稿なし
智源コミュニティ 検索ページはクライアントサイドレンダリングのためフレームページのみ取得、今回は未使用
メンバー企業プレスリリース 清微、沐曦の2社の原稿本文を取得し日付と表現を照合
収録待ちキュー 当日に本テーマのファイルなし、未アーカイブファイルのスキャンにも FlagOS セクションなし

完全な情報源リスト

[22] FlagQuantum PR #924（固定 shots 実験契約） — https://github.com/flagos-ai/FlagQuantum/pull/924

hub.com/flagos-ai/vllm-plugin-FL/pull/642>