調査期間:2026-10-16 06:00 ~ 2026-10-19 06:00(北京時間、約72時間;月曜朝報、期間は週末をカバーし、前回デイリーレポート(10-16)の締め切り時点から起算、10-17から10-18の「2026 人工知能開放計算大会暨衆智 FlagOS 技術大会」全日程を含む)。

情報源:GitHub(org: flagos-ai 61リポジトリ全量核查、コミット検索147件のページング検証、マージ済みPR 139件と審査中PR 239件の検索、31リポジトリのReleaseと8リポジトリのタグのアトミック核查、orgイベントストリーム100件とブランチレベルのフォールバック)、Google News RSS(24組の中英語クエリ語、プロキシ経由)、HN Algolia(8組)、CSDN FlagOSコラムと智源コミュニティ、大会公式アジェンダページとDOIT現場レポート(詳細は付録の情報源リストを参照)。


本期インデックス

  • 今日の重点:2026 開放計算大会二日間の全日程——2.2 メインフォーラムの口径(21社35チップ / 1454オペレータ / クロスチップ +27.6% / 264名の貢献者)と量智雲の発表;GitHub側は16リポジトリ147件のコミット、139件のマージ、新規リポジトリ FlagCV の骨格がリポジトリに登録、FlagQuantum 0.3.1 と FlagCX 0.15.0.dev0 のリリース、build-infra 六バックエンド22.04 builder の収束(10-16 ~ 10-19)
    1. オープンソースプロジェクトの進展(GitHub 動向)
      • 1.1 組織のリズム:16リポジトリのプッシュ、147件のコミット、139件のマージ、239件の審査中;FlagCV が初めてコミット面に登場(10-16 ~ 10-19)
      • 1.2 新規リポジトリ FlagCV:OpenCV インターフェースに整合するマルチバックエンド画像オペレータライブラリの骨格がマージ(10-18 ~ 10-19)
      • 1.3 build-infra:FlagCX 六バックエンド22.04自己完結型 builder の収束;FlagTree のバックエンド別 builder と毎日のホイールマトリクスが成型(10-16 ~ 10-18)
      • 1.4 FlagGems:KernelGen の NVIDIA オペレータ30余条を一括登録;昆侖芯最適化の波20余件;216テストケースを Protocol v6 へ移行(10-16 ~ 10-17)
      • 1.5 FlagTree:SpaceMiT RISC-V バックエンドに smt_rvisa ベアメタル eDSL を新規追加、独自 TLE 方言を廃止(10-16)
      • 1.6 通信と量子:FlagCX v0.15.0.dev0 と Hygon UIL の2件;FlagQuantum 0.3.0 / 0.3.1 の2バージョン(10-16 ~ 10-18)
      • 1.7 推論と訓練スタック:GLM-5.3 / Qwen4 オペレータが FlagGems-vllm へ;vllm-plugin-FL 昇騰全デコードグラフ;Torch-FL MPS と FlagCICD(10-16 ~ 10-19)
      • 1.8 オペレータライブラリと審査面:FlagBLAS 達摩院玄鉄 PPU GEMM;FlagTensor 16オペレータスイート;チャレンジ27件が審査中(10-16 ~ 10-18)
    1. 報道とエコシステム
      • 2.1 大会メインフォーラム:FlagOS 2.2 の六組の数字と四層アーキテクチャ(10-18)
      • 2.2 量智雲 Quantum-AI Cloud の発表:FlagOS Execution Stack が FlagQuantum を下支え(10-18)
      • 2.3 大会のその他版塊とチャネル核查:分科会ライブページが公開、各セッションの議事録は未公開(10-17 ~ 10-19)
    1. メンバー企業の深掘り
      • 3.1 摩尔線程:S5000 の大会口径、MThreads オペレータと MUSA ライン(10-16 ~ 10-19)
      • 3.2 沐曦:C550 上の MiniMax M3 と Kimi K3 二段階最適化が審査中、metax ホイールが毎日ラインへ(10-18 ~ 10-19)
      • 3.3 天数智芯 / 燧原 / 寒武紀 / 海光 / 清微 / 曦望 / 達摩院玄鉄:六バックエンド22.04とオペレータライン(10-16 ~ 10-18)
    1. まとめとトレンド観察

今日の重点:大会二日間の全日程が確定、2.2 の「規模口径」とエンジニアリング側の「再現可能な納品面」が同時に実現(10-16 ~ 10-19)

日付:2026-10-16 ~ 2026-10-19 出典:DOIT メインフォーラム報道 · 大会アジェンダページ · FlagCV · build-infra(全量は付録を参照)

  • 大会(10-17 ~ 10-18)は今期の絶対的なメインライン:メインフォーラム 09:10 の枠で、智源研究院副院長兼チーフエンジニアの林詠華氏が「衆智 FlagOS 2.2:token 経済から物理 AI へ」と題して登壇し、2.2 の規模感を初めて集中的に披露した——21 社のチップメーカーによる 35 種のチップ、9 大オペレータライブラリ 1454 個のオペレータ(前版比 +890)、チップ横断オペレータ性能 +27.6%(10 種のチップをカバー)、264 名のコードコントリビューター(前期比 +55%)。あわせて FlagPrism チップ横断デバッグツールと FlagOS-Compressor 統一量子化ツールをリリース(詳細は 2.1 を参照)。
  • 量智雲(Quantum-AI Cloud)10-18 リリース:智源研究院と北京量子信息科学研究院が共同で発表したもので、FlagOS Execution Stack を介して FlagQuantum を支え、「九鼎」AI 算力システムと「QUAFU」量子コンピュータに接続し、量子と古典の混合作業スケジューリングを実現——GitHub 側の FlagQuantum v0.3.0 のリリースノート(九鼎 / Quafu タスクの復旧可能、Quafu マルチ回路の順序付き結果)と対外的な説明が互いに裏付けとなっている(詳細は 2.2 / 1.6 を参照)。
  • エンジニアリング側は同時期に三本柱が並行して進行:build-infra は 45 件のコミット、41 件のマージで、FlagCX の nvidia / hygon / cambricon / metax / enflame / iluvatar の六バックエンド builder を 22.04 の自己完結形態に統一し、さらに FlagTree の builder とデイリー wheel を「backends.yaml に 1 行 1 バックエンド」のマトリクスへと変更(詳細は 1.3 を参照);FlagGems は 48 件のコミット、52 件のマージ(KernelGen によるオペレータのバッチ投入と崑崙芯最適化の波、詳細は 1.4 を参照);Torch-FL は 20 件のコミット、21 件のマージ(MPS ネイティブオペレータと FlagCICD 報告、詳細は 1.7 を参照)。
  • 組織に新たな「オペレータドメイン拡張」のシグナルが追加:10-14 に作成された FlagCV が 10-18 深夜に初コミットを行い、10-19 01:38 に PR #1「Init project skeleton」をマージ——インターフェースは OpenCV に準拠、マルチバックエンド構造は FlagDNN を踏襲、カーネルは Triton で記述し、まず骨組みを落としてオペレータはまだ実装していない(詳細は 1.2 を参照)。
  • バージョン面:FlagQuantum 0.3.0(10-16 13:34)と 0.3.1(10-16 19:20)が同日にダブルリリース;FlagCX は v0.15.0.dev0(10-18 10:36)を打ち出した。期間内に 2.2 リスト内のその他コンポーネントの正式バージョン変更はない。

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

1.1 組織のリズム:16 リポジトリのプッシュ、147 件のコミット、139 件のマージ、239 件がレビュー中;FlagCV が初めてコミット面に登場(10-16 ~ 10-19)

日付:2026-10-16 ~ 2026-10-19 情報源:org リポジトリ一覧 · FlagGems · build-infra(全量は付録を参照)

  • リポジトリ面:61 リポジトリのうち 16 リポジトリで期間内にプッシュあり——docs、FlagTree、FlagCV、Torch-FL、Trident、build-infra、FlagFFT、FlagCX、FlagQuantum、FlagGems、FlagGems-Experimental、FlagDNN、FlagGems-vllm、vllm-plugin-FL、FlagBLAS、FlagTensor。うち FlagDNN / FlagFFT / Trident / docs の 4 リポジトリのプッシュは非デフォルトブランチにあり(デフォルトブランチの最新コミットはそれぞれ 10-15 17:16 / 10-15 15:58 / 10-13 22:19 / 10-03 11:12)、メインラインに新規追加はない。
  • コミットとマージ:コミット検索で 147 件ヒット、12 リポジトリをカバー——FlagGems 48、build-infra 45、Torch-FL 20、FlagQuantum 11、FlagGems-vllm 6、FlagTree / FlagGems-Experimental / FlagCX / FlagCV / FlagTensor 各 3、FlagBLAS / vllm-plugin-FL 各 1;マージ済み PR 139 件、11 リポジトリをカバー(FlagGems 52、build-infra 41、Torch-FL 21、FlagGems-vllm 6、FlagTree 4、FlagQuantum 4、FlagCX 3、FlagGems-Experimental 3、vllm-plugin-FL 3、FlagCV 1、FlagBLAS 1)。
  • 審査中面:期間内に更新のあったオープン PR は 239 件、23 リポジトリをカバー。上位は FlagGems 104、FlagGems-sglang 31、vllm-plugin-FL 27、Torch-FL 14、FlagTree 12、FlagGems-vllm 11;うち 27 件に「FlagOS Competition-Track1」ラベルが付与され、すべて FlagGems-sglang 宛て(詳細は 1.8)。
  • 判断:3 日間の期間におけるマージ密度(1 日平均約 46 件)は 10-15 単日(107 件 / 24 時間)の平常水準を上回るが、構造は変わっていない——FlagGems と build-infra の 2 リポジトリでコミット量の 63%、マージ量の 67% を占め、依然として「オペレータライブラリ + ビルド基盤」の二重エンジン駆動である;学習側(Megatron-LM-FL / TransformerEngine-FL / FlagScale)は期間内にプッシュゼロで、大会前後の静穏期にある。

1.2 新規リポジトリ FlagCV:OpenCV インターフェースに合わせたマルチバックエンド画像オペレータライブラリの骨組みがマージ(10-18 ~ 10-19)

日付:2026-10-18 ~ 2026-10-19 情報源:FlagCV · PR #1 · コミット履歴

  • 事実:10-14 に建倉された FlagCV は 10-18 23:14 に最初のコミット「Add project skeleton and bitwise_and operator」を落とし、10-19 01:24 に「Restructure as an immediate-mode skeleton without operators」を追加、10-19 01:38 に PR #1(作者 zhangjieBaai)をマージした。PR 説明には三つの設計方針が明記されている:インターフェースは OpenCV に整合(include/flagcv/ 下の core / imgproc / gpumat / handle / types の五つのヘッダファイルで、opencv2 の core と imgproc に対応)、マルチバックエンド構造は FlagDNN を踏襲、カーネルは Triton で記述;本 PR は骨格のみで、オペレータは含まない。
  • 構造:リポジトリの 81 パスのうち、backends/ は既に nvidia / thead / ascend / hygon / iluvatar / mthreads の六バックエンドを一気に展開済み(各々 CMakeLists、backend.cpp、compiler.py と kernels/registry.json を含む);src/ は core、imgproc、image、lowering、runtime の五ブロックに分かれる;compiler/flagcv_codegen はコード生成の入口;docs/ には architecture、numerical-tolerance、operator-development の三篇が既にある。
  • 判断:これは FlagOS のオペレータ版図が初めて「大規模モデル / 科学計算」から画像処理へと伸びたことを意味する——従来 FlagCV 類のギャップは FlagDNN(深層学習オペレータ)と各ベンダー自家の CV ライブラリが分担していたが、現在は OpenCV 互換インターフェースで独立にリポジトリを立てている。六バックエンドのディレクトリを一つずつ追加するのではなく一気に展開したことは、チームが既存の FlagDNN のマルチバックエンドパラダイムをそのまま再利用する意図を示す;numerical-tolerance ドキュメントがオペレータより先に出現したことも、FlagOS が KernelGen ラインで「まず受け入れ基準を定め、その後オペレータをバッチで落とす」という既存のリズムに合致する。リスクは、画像処理オペレータ(補間、色空間、モルフォロジー)と Triton の表現能力のマッチングが未検証であり、かつリポジトリにはまだ実行可能なオペレータがないため、短期的にそのカバレッジについて結論を下すべきではないことだ。

1.3 build-infra:FlagCX 六バックエンド 22.04 セルフコンテインド builder の収束;FlagTree バックエンド別 builder と日次ホイールマトリクスの形成(10-16 ~ 10-18)

日付:2026-10-16 ~ 2026-10-18 情報源:build-infra #1369 · #1371 · #1372 · #1380 · #1389 · #1394 · #1398 · #1399 · #1403 · #1404 · #1407

  • FlagCX ライン:24時間以内に6つのバックエンドそれぞれに「22.04 自己完結型 builder」を1枚ずつ投入——nvidia(#1372)、hygon(#1380)、cambricon 4.7.2(#1389、pandas 依存を補完する #1391 を伴う)、metax(#1394)、enflame(#1398)、iluvatar(#1403)。各 builder は ubuntu:22.04 を glibc の下限とし、ベンダー SDK をイメージにプリセットした上で wheel を出力し、wheel-info に記録を残す(#1375 / #1395 / #1400)。#1407 では dispatch レベルの --no-bitcode スイッチを追加:v0.14.0 タグは FlagCX #668 の bindings/ir Makefile より前のため、iluvatar の 0.14.0+corex4.4.0 / corex4.5.0 という2つの pin を再リリースする際にデバイス bitcode を生成せず、非 nvidia adaptor で setup.py が直接エラーを投げるのを回避する。
  • FlagTree ライン:builder は「2つのワークフローで1つのことをする」構成から1つのマトリクスへ統合され、backends.yaml の1行が Containerfile、イメージリポジトリ、runner ラベル、ディスク予算、受け入れアサーションを運ぶ(#1369)。日次 wheel も同様にバックエンドごとに1行とし、plan が行ごとにバージョンとファイル名を計算する(#1371)。metax は日次ラインへ(#1377)、iluvatar はターゲットと日次行へ(#1390 / #1393)、sunrise は builder と wheel を単一ファイルにまとめて日次行を有効化(#1399 / #1402)、ascend の一対のバックエンドは2段階 builder へ(#1404 / #1405、ビルド環境がすなわちデリバリ環境であり、CANN を読み、それに基づいて AscendNPU-IR を pin する)。#1397 は FlagCX を iluvatar の FlagTree wheel から明確に除外し、2つの成果物の境界を画定する。
  • パッケージングライン:wheel アップロードは runner ローカルの python から uploader イメージ内での実行へ変更(#1381 / #1382 / #1388)。リリース系ワークフローは pull/<N> を ref として受け付け(#1347)、PR ブランチでリリース経路を先に一巡できるようにする。FlagGems-sglang は noarch deb/rpm と flaglibs wheel の2ラインへ(#1387)。bundle の深層スモークテストは実機 device + コンパイラ JIT/実行へ変更(#1365)、さらに bundle の glibc 下限(22.04)上で検証を実行(#1376)。
  • 判断:この一連は散発的な修补ではなく、「N 個のバックエンド × M 種類の成果物」を「1枚のマトリクス + 1つの backends.yaml」へ圧縮するものだ——新規バックエンドの追加は「ワークフローをもう1本書く」から「1行加える」へ変わる。22.04 への統一は同じ論理の裏面である:ビルド環境とデリバリ環境の glibc 下限を固定して初めて、クロスディストリビューションの wheel は「1つの成果物を複数箇所でインストール可能」と言える。これはまさにメインフォーラムの言う「35 種のチップ」に対応する——チップ数は再現可能なデリバリ面で支えられなければ、規模は単なる名簿にすぎない。

1.4 FlagGems:KernelGen の30余りの NVIDIA オペレータを一括登録;昆仑芯最適化の波20余件;216 テストケースを Protocol v6 へ移行(10-16 ~ 10-17)

日付:2026-10-16 ~ 2026-10-17 情報源:FlagGems #6989 · #7215 · #7213 · #6985 · #7124(全量は付録を参照)

  • KernelGen(NVIDIA)によるオペレータの一括投入:10-16 14:06 ~ 14:50 および 16:11 前後にかけて、三十余件の「[KernelGen][Nvidia] Add <オペレータ> operator with Triton kernel」が集中的にマージされ、`slow_conv_transpose2d/3d`、`_slow_conv2d_backward`、`convolution`、`fft_rfft`、`linalg_cholesky_ex / eigvalsh / inv / tensorsolve`、`lstm_cell / gru_cell / rnn_tanh_cell / rnn_relu_cell`、`coalesce / col_indices_copy / values_copy`、`diagflat / gradient / dense_dim / _dim_arange / _dimV / _has_same_storage_numel / _sparse_broadcast_to` などをカバー。FlagGems-Experimental には別途 3 件(`dstack` とチャネル単位量子化テンソルファクトリオペレータなど)を投入。
  • テスト方式の移行:#7215 により 216 個のオペレータテストケースが Protocol v6 の三種セット構成(tests/test_<op>.py + benchmark/test_<op>.py + definitions/<op>.json)へ移行され、由来リスト 220 個の正確な ID のうち 216 件を移行、3 件は再審査により除外(tensor_split などのアンブレラ行)、1 件は保留(clone に現実装なし)と説明。併せて philox_normal_ にバージョンゲート付きの Philox 登録を追加。
  • 昆仑芯の最適化ラッシュ:二十余件が XPU バックエンドに集中——amax / mv / i0 / cauchy、euclidean_dist / normed_cumsum、batch_norm_backward / layer_norm_backward、masked_scatter / nonzero / addr / logit、foreach_copy / foreach_pow_list / foreach_tan、float_power_ / gather_backward / scatter_add_ / to_copy、tril_ / arange、le_scalar_ / one_hot / mhc_pre、index_select_backward;うち #7213 は cumsum の行スキャンをプレフィックス和の行列積へ書き換え、#7144 / #7218 は int16 dtype と精度修正を追加。
  • その他のライン:MThreads は moe_load_balance_loss オペレータを新規追加(#6985、MUSA 特化を含む:アキュムレータ sem="relaxed"、tl.histogram による program ごとのヒストグラムでスカラーアトミックを代替、単一 scratch 割り当て、さらに C++ wrapper と gtest を同梱);昇騰は adaptive_max_pool3d のグリッド上限とブロック発射オフセットを修正(#7124);海光は審査中 #7242 で split-KV の BLOCK_M 上限を 16 に押さえ 64KB LDS を守る。
  • 判断:KernelGen の成果はすでに「ATen リストに沿った補完」の最終段階に入っている——今回補完されたのは _dim_arange、values_copy、_has_same_storage_numel といった周辺オペレータが多く、主要オペレータのカバレッジがほぼ完了し、エイリアス/ビュー/スパースなどの境界意味論の処理に着手したことを示す。昆仑芯の二十余件の密度は特筆に値する:これは単一の国産バックエンドが三日間の調査期間内に行った最も集中的な最適化投入である。

1.5 FlagTree:SpaceMiT RISC-V バックエンドに smt_rvisa ベアメタル eDSL を新規追加、私有 TLE 方言を廃止(10-16)

日付:2026-10-16 情報源:FlagTree #1381 · #1394

  • 事実:#1381(作者 alex-spacemit)が SpaceMiT RISC-V(K3)バックエンドを更新し、三つのことを同時に行った——smt_rvisa を新規追加。これはベアカーネル(raw-kernel)eDSLであり、作者が SEW / VL / ブロッキング / 命令選択を明示的に指定し、スケジューラに決定を委ねない;カーネルは C++ builder API 経由で降下し(MLIR テキストを生成しない)、別途 LLVM 直出路線があり、MLIR Python bindings を用いて直接 llvm.func を生成し spine-opt を丸ごとスキップする;バックエンドは私有 TLE 方言のコピーを保有せず、汎用の third_party/tle を消費するよう変更;同時にベア経路が露呈したポインタ / メモリ空間降下の欠陥を修正した。
  • 付随:#1394 が昇騰 CI の py311 / py312 と ascend3.5 ワークフローを更新;審査中の #1395([SPEC][XPU] core analysis を再利用し TritonTypes.td にルーティング)、#1396(Ascend3.5 py312 デリバリーワークフロー)は XPU と昇騰の二路線の規格化が依然進行中であることを示す;#1387 は tle.gpu.alloc 別名のテストを enflame 上でスキップした。
  • 判断:RISC-V バックエンドはこれまで FlagTree 内で「コンパイルでき、実行できる」段階だったが、本期で初めてベクトルユニット向けの手書き入口が登場した——SEW / VL を明示的に制御できるということは、RVV のベクトル長とブロッキング戦略をカーネルに書き込めることを意味し、自動スケジューリングの推論に依存しない。私有 TLE コピーの廃止はガバナンス上の措置である:複数バックエンドが一つの TLE 方言を共有することで、「バックエンドごとに一套のセマンティクス」という事態を避けられる。RISC-V AI チップ(進畳時空 K3 ライン)にとって、これは「モデルを動かせる」から「性能を引き出せる」への一歩である。

1.6 通信と量子:FlagCX v0.15.0.dev0 と Hygon UIL の二件;FlagQuantum 0.3.0 / 0.3.1 の二バージョン(10-16 ~ 10-18)

日付:2026-10-16 ~ 2026-10-18 情報源:FlagCX v0.15.0.dev0 · FlagCX #643 · #668 · #663 · FlagQuantum v0.3.0 · v0.3.1

  • FlagCX:10-18 10:36 に v0.15.0.dev0(開発線タグ)を打ち出し;コード側では三件をマージ——#643 は Hygon Device API と統一 IR の HIP バックエンドを有効化し、海光の UIL(統一インターフェース層)上のデバイスチャネルを補完;#668 はデバイス bitcode をハードコードされた nvidia ではなくアダプタごとに生成するようにし、これは異種通信ライブラリが「一社専属」から「複数社同構」へ向かう鍵となる変更;#663 は CI を四卡に収束させプラットフォーム設定を統一した。
  • FlagQuantum 0.3.0(10-16 13:34):0.3 線が安定パッケージに転換し、Python 3.10–3.12 の stable-ABI wheel(Linux x86_64 / macOS arm64 / Windows amd64)を提供;九鼎と Quafu のタスクが復旧可能(opt-in 回执)となり、Quafu のマルチ回路結果は順序を保持;パッケージには FlagOS 2026 ワークショップ六講の英語版と中国語版を同梱。
  • FlagQuantum 0.3.1(10-16 19:20):0.3.0 のビルド後にマージされたローカル科研能力サービスを補充——flagquantum.services は制限付き能力の発見と記述、型付きリクエストの検証と見積もり、ローカル CPU 実行と構造化証拠検証を含み、二比特 Pauli-sum 基底状態 VQE 経路とバージョン番号付き証拠パッケージを備える;リリースノートは同時に境界を画定する:化学仕様から分子ハミルトニアンを構築することはせず、量子ハードウェア上では実行せず、MCP server や agent runtime を含まない(MCP アダプタは独立パッケージ)。
  • 判断:二つの路線は同一の期間内に「能力—製品」の整合を完了した——FlagCX の UIL 化(Hygon チャネル + アダプタごとの bitcode)は通信層のマルチベンダー化を収束させる措置;FlagQuantum のリリースノートは「できること / できないこと」を大多数のプロジェクトより明確に記述しており、0.3.0 における九鼎 / Quafu のタスク復旧能力は、まさに翌日の量智雲対外発表の技術的な下書きである(詳細は 2.2 を参照)。

1.7 推論と学習スタック:GLM-5.3 / Qwen4 オペレータが FlagGems-vllm に進出;vllm-plugin-FL 昇騰全デコードグラフ;Torch-FL MPS と FlagCICD(10-16 ~ 10-19)

日付:2026-10-16 ~ 2026-10-19 情報源:FlagGems-vllm #900 · #896 · vllm-plugin-FL #409 · #607 · Torch-FL #560 · #565 · #542

  • FlagGems-vllm(6 件マージ):#900 はフレームワーク側 PR 454 に GLM-5.3 Flash 公開オペレータを追加;#896 は Qwen4 の HC / PLE / sparse QSA の3種類のオペレータをプラグイン統合向けに提供;#924 は thead の W8A8 MoE 整数累加を修正し GEMM2 を再利用;#934 は MUSA の vLLM ベースライン起動を修正;#937 は FP8 varlen 精度マトリクスを359ケースに圧縮。
  • vllm-plugin-FL:#409 は昇騰向けに汎用全デコードグラフモード(generic full-decode graph)を有効化;#598 は H20 上で無効化された NVLS 初期化を停止;#593 はオペレータ profile に eager 参照実装を追加。審査中2件は沐曦 C550 を指向:#540 は2ノード TP16 の MiniMax M3 BF16 最適化版(09-18 起票、10-18 も更新中)、#607 は4ノード TP8 / PP4 の Kimi K3 MXFP4/BF16 実装(10-19 01:58 新規起票、vLLM 0.28 互換の 0.4.0-dev ブランチ上で動作)。
  • Torch-FL(20 件コミット / 21 件マージ):MPS ライン3件——ネイティブ mm / bmm を MPSGraph gemm クラスへ(#560)、softmax と要素ごとの neg / pow をネイティブ化(#565)、コンパイル済み MPSGraph プランキャッシュとスケジューリング(#545);昇騰ライン5件(PrivateUse1 上の bitwise_*_.Scalar、SDPA で dropout 時にフォールバック、cumsum を aclnn 経由、flip を aclnn 経由、FlagTree 0.7.0 の autotuning パラメータ改名のブリッジ);GCU 3件(rsub ネイティブ、conv と layer_norm をオペランドデバイスでゲート、Qwen-Image 回転テーブルのメモ化);清微1件(metadata-only ビューオペレータをベンダースロットへルーティング);CI 側は新たに昆仑芯 P800 の 2.9 安定ブランチライン(#273)、プラットフォーム pytest レポートを FlagCICD へ上报(#542 / #577)、MUSA ランタイムカバレッジを共有統合リストへ統合(#574)、CUDA ラインを FlagGems 主導のデフォルトホイール実行へ変更(#530)。
  • 判断:推論側の動きは「あるチップへの適配」から「あるモデルの新構造への適配」へと移行した——GLM-5.3 Flash と Qwen4 の HC / PLE / QSA はいずれも10月に登場した新しいアーキテクチャ用語であり、オペレータがモデル公開に先行して着地している。学習側 Torch-FL の重点は MPS(Apple プラットフォーム)と FlagCICD 上报にある:前者は FlagOS の「マルチチップ」が端末側 / ワークステーションを取り込んだことを示し、後者はマルチプラットフォームの pytest 結果を集中化するガバナンス施策である。

1.8 オペレータライブラリと審査面:FlagBLAS 達摩院玄鉄 PPU GEMM;FlagTensor 16 オペレータスイート;チャレンジ 27 件審査中(10-16 ~ 10-18)

日付:2026-10-16 ~ 2026-10-19 情報源:FlagBLAS #148 · FlagTensor · FlagGems-sglang PR リスト

  • FlagBLAS:#148 は達磨院玄鉄真武(Zhenwu)PPU の thead バックエンドのために GEMM を補完——sgemm / hgemm / bfgemm / dgemm の四つの Triton カーネルで、それぞれ NN / TN / NT / TT の四種類のレイアウト変体を備える;cgemm / zgemm はプレースホルダのみを残し flag_blas.ops.level3 へ転調(真武には原生の複素数 GEMM がない)。PR は同時に thead の精度・性能スイートがこれまで動作しなかった問題(cublasGemmEx の計算型パラメータなど)を修正し、thead ベンダのみに影響するよう限定した。
  • FlagTensor:三つのコミットで非 NVIDIA ベンダを固定の 16 オペレータテストスイートへ統一し、各プラットフォームガイドを同期更新(10-16 11:01 ~ 11:26)——すなわち「各バックエンドが個別にテストする」を「同一の 16 オペレータ群、同一の判定」へ変更した。
  • レビュー面:審査中の 239 件の PR のうち、27 件が「FlagOS Competition-Track1」ラベルを持ち、すべて FlagGems-sglang に投入されている(同リポジトリは審査中 31 件)。内容は SGLang に Triton カーネルを補完するもので——ワイド行 softmax、MLA 吸収式 Q 連結、DCP の LSE マージ、QKV-ZBA 分割再配列、投機サンプリング付加項収集など(カーネル名は付録 PR リスト参照)、提出者は主に競賽チームアカウントである。
  • 審査要点(その他):FlagGems #7246 摩尔線程 mm 最適化(+3501/-72);#7239 昇騰 mm 形状ディスパッチと Triton ブロッキング;#7243 昇騰 index_put を原生 ATen へ差し戻し MLIR pass クラッシュを回避;#7203 達磨院玄鉄バックエンド GRU barrier デッドロック修正;FlagTree #1395 XPU 仕様再利用、#1396 昇騰 py312 デリバリフロー。
  • 判断:三つのオペレータライブラリはそれぞれ同じことの異なる層を担っている——FlagBLAS はハードウェアバックエンドの基礎線形代数を補い、FlagTensor は受入基準を統一し、FlagGems は競賽と KernelGen のオペレータ流入を受け持つ。競賽の審査中件数(27 件)はコミュニティ供給が依然あることを示すが、sglang の一本の線に集中しており、カバレッジは 9 月首批 16 件のバッチ收口より狭い。

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

2.1 大会メインフォーラム:FlagOS 2.2 の六組の数字と四層アーキテクチャ(10-18)

日付:2026-10-18 情報源:DOIT「林咏華:衆智 FlagOS 2.2 発表、token 経済はフィジカル AI へ向かう」 · 大会议程ページ

  • 規模基準:21 社の AI チップメーカー、35 種のチップをカバー;9 大オペレータライブラリ合計 1454 オペレータ(前版比 890 増);マルチチップ間オペレータ性能 27.6% 向上(10 種のチップをカバー);コードコントリビューター 264 名(前月比 +55%)。コミュニティ面ではさらに:アクティブコントリビューター 730+、メンバー組織 100+、30 カ国以上をカバー、開発者 55,800+;2.1 から 2.2 へのマージ PR は 1890 から 4890 に増加、新規 issue は 420 から 1423 に増加、コミットは 5100 から 9730 に増加。報道によると 2.2 は 9 月 30 日にリリース;GitHub 側の 2.2 リスト 24 項目は実際には 09-28 ~ 09-29 にリポジトリへ反映済み(09-29 / 09-30 デイリーレポート参照)。対外基準とリポジトリ反映日には 2 日間のずれがあり、リポジトリを基準とする。
  • コンパイルとチューニング:FlagTree 単一リポジトリで 20 社のベンダーバックエンドをカバーし、NVIDIA TileIR、AMD、達摩院玄鉄、進畳時空、輝羲、ARM64 CPU バックエンドを新たに追加、main ブランチは Triton 3.6 にアップグレード;FlagOSTune は行列積などのオペレータの探索効率を最大 298 倍向上。エンドツーエンド実測:NVIDIA 上で DSV4-flash スループット +12.63%、初回トークン遅延 −20.22%;摩尔線程 S5000 上で Qwen3.6-35B-A3B が H100 換算スループットの 82.29% ~ 89.83% に達し、ベンダー純正を 4% ~ 19% 上回る。マルチチップ全体 +27.6% のうち、崑崙芯 P800 は加速比 191.2% 向上、昇騰 910B は 160.7% 向上。
  • ツールチェーン:FlagPrism を新規リリース(マルチチップ横断デバッグと性能分析、数値偏差をステートメントレベルまで特定可能、昇騰、天数智芯、摩尔線程、英偉達、燧原をすでにサポート);統一プラグインシステムにより「N×M」の組み合わせを「N+M」の分離に変更し、推論(vLLM / SGLang)、学習(Megatron-LM / TransformerEngine)、強化学習(VeRL)、基盤フレームワーク(Torch-FL)をカバー;FlagOS-Compressor は初めてマルチチップ横断の統一量子化を提供し、397B MoE を W8A8 化するとサイズ 49.1% 削減、GPQA-Diamond は 84.85% を維持、H20 と国産 PPU で検証済み;Day0 能力により新モデルを 1 日以内に最大 12 種のチップへ適応し、HuggingFace、魔搭、騰訊雲、煥新コミュニティ、国家超算インターネットへ同時配信。
  • トークンとモデル事例:DeepSeek V4.1 Flash は H100 上で推論性能 18% ~ 20% 向上、64 路並列の総スループット約 9190 tok/s;達摩院玄鉄 810E は 77% ~ 82% 向上、16 路並列で利用可能に;FP4 インデックススコアリングは平均 2.75 倍加速、FP8 Dense GEMM は 1.41 倍。GLM-5.3-Flash は昇騰 910B 上でスループット 2.04 倍向上、長コンテキストのコールド TTFT は 8.1% 低下、フルロード時 ITL は 16.6% 低下、性能は公式 API の 99.7% に達し、コストパフォーマンスは 19.4% ~ 27.6% 高い。
  • エンボディド、端末側、国際化:エンボディド側では VLM 加速約 2.3 倍(MFU 33%)、Tx2V 約 1.9 倍(MFU 36%)、Action 約 2.0 倍(MFU 35%)、学習 MFU 33% ~ 36%、比較対象の Cosmos3-Nano は 23%、Cosmos3-Super は 30%;端末側では Arm CPU 上で CPU のみで MiniCPM5-2B を実行し、プリフィル 1135 tokens/s、生成 90 tokens/s、FlagTree-CPU と SME2 / NEON I8MM の協調により完全モデルの Prefill がさらに 21% ~ 25% 向上、Mac M5 Pro 上で Xing4.0 29B-A4B は vLLM 純正比 252.09% 向上;国際側では 9-28 に国連「開放計算作業部会」が承認され、2 週間以内に 300 社以上のグローバル機関が登録、初回会合は 11 月の APEC 期間中に開催予定。
  • 判断:この基準の価値は個々の数字ではなく、「規模」を検証可能な 4 層——チップ数(35)、オペレータ数(1454)、性能向上(+27.6%、かつ 10 種のチップの内訳を提示)、コントリビューター数(264)——に分解した点にある。2.1 期の「何種のチップをサポートするか」と比較し、2.2 の語りはすでに「同一チップ群上の共有最適化が累積可能かどうか」へ転換している;FlagPrism と FlagOS-Compressor という 2 つの新ツールは、まさにこの言葉をツール化した表現である。

2.2 量智雲 Quantum-AI Cloud リリース:FlagOS Execution Stack が FlagQuantum を支える(10-18)

日付:2026-10-18 情報源:DOIT メインフォーラム報道(量智雲セクション) · 正式議程(量智雲プラットフォーム発表 10:05–10:15) · FlagQuantum v0.3.0

  • 事実:10-18 午前の量智融合分科会に「量智雲プラットフォーム発表」セッションを設置(議程 10:05–10:15)。メインフォーラムの報道によると、量智雲(Quantum-AI Cloud)は智源研究院と北京量子信息科学研究院(BAQIS)が共同で発表し、FlagOS Execution Stack が FlagQuantum 量子フレームワークを支える形で、「九鼎」AI 算力系統と「QUAFU」量子コンピュータに接続し、量子と古典の混合作業スケジューリングを実現する。
  • コード側の裏付け:FlagQuantum v0.3.0 のリリースノート(10-16)にはすでに「九鼎と Quafu のタスクが復旧可能(opt-in 回執)」「Quafu の複数回路結果の順序保証」が明記され、v0.3.1 ではさらにローカル科研能力サービスとバージョン付き証拠パッケージを追加している——量智雲の発表時点で、量子側のタスクコミット、回執、結果順序保証の経路がパッケージ内にすでに備わっており、単なるフレームワーク層のインターフェースではなかったことを示す。
  • 判断:これは FlagOS が「AI 訓練推論」から「量子-古典混合」へ跨る最初のクラウドサービス形態の成果物である。注目すべき境界:v0.3.0 / 0.3.1 の説明では量子ハードウェア上では実行せず、MCP server と agent runtime を含まず、ハードウェア実行は九鼎と QUAFU 側が担うことが明確にされている——役割分担は「FlagOS がスケジューリングと実行スタックを担当し、量子研究院がハードウェアとクラウドを担当する」。今後の観察点は、量智雲がいつ外部公開されるか、そして FlagQuantum のマルチチップバックエンド(海光 / 摩尔線程)がクラウド側スケジューリングに組み込まれるかどうかである。

2.3 大会のその他版塊とチャネル核查:分科会ライブページ公開、逐次紀要は未公開(10-17 ~ 10-19)

日付:2026-10-17 ~ 2026-10-19 情報源:CSDN FlagOS コラム · AI 系統分科会ライブページ · 量智融合分科会ライブページ · AI Agent 分科会ライブページ

  • 版塊構成:大会は 1 メインフォーラム + 6 分科会 + 1 終日ワークショップで、分科会には開放計算 AI 系統、車載智能、量智融合、具身智能、AI Agent、国際 AI 計算協力が含まれる。10-18 終日ワークショップは五つ(KernelGen オペレータ生成、端側推論、Triton-TLE 注意力オペレータ、量智融合量子プログラミング、FlagScale-Agent アーキテクチャ)。議程の詳細は 10-12 / 10-13 デイリーレポートに収録済みのため、本期では繰り返さない。
  • 核查可能な増分:CSDN FlagOS コラムは 10-17 / 10-18 に AI 系統、量智融合、AI Agent の三分科会のライブページを公開(「回放中」と表示);調査期間の締切時点で、逐次紀要や講演実録は検索されていない。メインフォーラムの内容は依然として DOIT の一現場報道が主要情報源である。智源コミュニティ(hub.baai.ac.cn)では調査期間内に FlagOS 関連の項目は検出されなかった。
  • ニュース検索の結論:Google News RSS の 24 組の中国語・英語クエリで 34 件ヒット、コンポーネント名直查(FlagOS / FlagGems / FlagScale / FlagTree / FlagPerf / FlagCX / KernelGen)は調査期間内で依然ゼロヒット、唯一の実質的ヒットは 10-18 のメインフォーラム報道(2.1 参照);HN Algolia の 8 組クエリでも直接ヒットなし。その他のヒットはメンバー単位の企業稿と市況稿——摩尔線程 Step 5 Preview Day-0(10-15、前号収録済み)、沐曦曦索 X302 工博会展受賞(10-12 以降複数サイト転載、収録済み)、燧原「A 株上場」(核查の結果 09-11 の旧聞再発)、「7 日で千億大モデル適配完了」(東方算芯 DF1000、FlagOS 非関連)、藍芯算力 RISC-V 湾芯展稿(FlagOS 非関連)であり、一括して除外した。

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

3.1 摩尔線程:S5000 の大会口径、MThreads オペレータと MUSA 線(10-16 ~ 10-19)

日付:2026-10-16 ~ 2026-10-19 情報源:DOIT メインフォーラム報道 · FlagGems #6985 · #7246 · FlagGems-vllm #934 · build-infra #1399

  • 大会公式見解:メインフォーラムは摩尔線程に関連する2組の数字を示した——S5000 上で Qwen3.6-35B-A3B が H100 相当スループットの 82.29% ~ 89.83% に達し、ベンダー純正を 4% ~ 19% 上回る。エンドツーエンド比較では DSV4-flash の NVIDIA 上での向上(+12.63%)と国産側の比較項目が並べて提示され、S5000 が 2.2 の性能ベンチマーク対象に組み込まれていることを示す。
  • コード側:FlagGems は moe_load_balance_loss(MUSA 特化、#6985)をマージ、審査中の #7246 は mm 最適化(+3501/-72、10-19 00:06 新規作成)。FlagGems-vllm #934 は MUSA の vLLM ベースライン起動を修正、#937 は FP8 varlen 精度マトリクスを収束。build-infra の sunrise(曦望)builder は本項とは無関係で、摩尔線程自身は FlagTree の mthreads ホイール行(既存)に対応する。
  • 補足:摩尔線程の 10-15 Step 5 Preview Day-0(MTT S5000 + MUSA + SGLang-MUSA、ハイブリッドスライディングウィンドウ/CSA スパースアテンション、FP8 DeepGEMM、MTP3 投機的デコード)は自社 MUSA ソフトウェアスタックを採用しており、FlagOS プラグイン経路ではない。当該イベントは前号で既に収録済みのため、本号では FlagOS エコシステム項目として重複計上しない。

3.2 沐曦:C550 上の MiniMax M3 と Kimi K3 二段階最適化が審査中、metax ホイールがデイリービルドラインに参入(10-18 ~ 10-19)

日付:2026-10-18 ~ 2026-10-19 情報源:vllm-plugin-FL #540 · #607 · build-infra #1377 · #1394

  • モデル適配(審査中):#540 は2ノード MetaX C550、TP16 の MiniMax M3 BF16 最適化版(09-18 作成、10-18 21:54 時点でも更新中。スパースアテンション、小バッチ Linear/MoE、通信最適化を含む)。#607 は4ノード C550、TP8 / PP4 / DP1(EP、SP 無効)の Kimi K3 MXFP4/BF16 実装で、vLLM 0.28 互換の 0.4.0-dev ブランチ上で動作し、モデル適配、TP/head パッキング、shape 選択、PP ランタイム編成のすべてを FL 側に保持(10-19 01:58 新規作成)。
  • ビルド側:build-infra は metax を FlagTree のデイリーホイールラインに組み込み(#1377)、metax 向けに自己完結型 22.04 FlagCX builder を整備(#1394、SDK バージョン変数名と deb 解包パスの2点を修正)、さらに 10-18 09:21 に metax ホイールの再発行を記録。
  • 判断:沐曦の FlagOS 内での役割は「適配されるチップ」から「性能段階の貢献者」へと転換しつつある——審査中の2件の PR はいずれも対をなすデプロイ方案(ノード数、並列度、量子化形式、コンテキスト)であり、単一オペレータのパッチではない。この種の PR はレビューコストが高いが、マージされれば再利用可能な参照構成となる。

3.3 天数智芯 / 燧原 / 寒武紀 / 海光 / 清微 / 曦望 / 達摩院玄鉄:六バックエンド 22.04 とオペレータライン(10-16 ~ 10-18)

日付:2026-10-16 ~ 2026-10-18 情報源:build-infra #1380 · #1389 · #1398 · #1403 · FlagCX #643 · FlagBLAS #148(全量は付録参照)

  • 天数智芯(iluvatar):FlagCX 22.04 builder と v0.14.0 の 2 つの corex pin の再発行(#1403 / #1407、22.04-clean、デバイス bitcode なし);FlagTree の iluvatar 行を「単独のワークフロー」からマトリクスに統合し、デイリーホイールを有効化(#1390 / #1393 / #1397);Torch-FL は FlagGems ファクトリ内の複素数 dtype を DCU 上で再ルーティング(#548);FlagGems #7220 の conv2d 重みキャッシュと channels_last 融合最適化が審査中。
  • 燧原(enflame):FlagCX 22.04 builder(#1398 / #1401、enflame ホイールの再発行を記録);FlagTree 側で tle.gpu.alloc エイリアステストが enflame 上で誤実行される問題を修正(#1387);FlagGems-vllm #900 の GLM-5.3 Flash 公開オペレータはベンダー間共有であり、enflame 専用ではない。
  • 寒武紀(cambricon):FlagCX 4.7.2 の 22.04 builder(#1389、torch_mlu インポート問題 #1391 を解決するため pandas を補完)、10-17 21:39 に neuware 4.7.2 の 22.04-clean 再発行を記録(#1392)。
  • 海光(hygon):FlagCX は Hygon Device API と統一 IR の HIP バックエンドを有効化(#643)、さらに 22.04 builder とホイール再発行記録を投入(#1380 / #1383);FlagGems 審査中 #7242 は split-KV の BLOCK_M 上限を 16 に抑えて 64KB LDS を守る;Torch-FL の DCU 複素数 dtype 再ルーティングは #548 と同じ。
  • 清微(tsingmicro):Torch-FL は metadata-only ビューオペレータをベンダースロットにルーティング(#550)、2.2 サイクル内の清微バックエンド「まず骨組みを立て、次にセマンティクスを補う」経路を継続。
  • 曦望(sunrise):FlagTree の builder と wheel を単一ファイルにまとめ(22.04 ツールチェーンで公開・再利用可能、pybind11 を 3.1.0 に固定)、共有 builder マトリクスに追加し、デイリーホイール行を有効化(#1399 / #1402)。
  • 達摩院玄鉄(thead):FlagBLAS に真武 PPU の 4 種精度 GEMM を追加(NN/TN/NT/TT 変体を含む、#148);FlagGems-vllm は W8A8 MoE の整数累加を修正し GEMM2 を再利用(#924);FlagGems 審査中 #7203 はバックエンド GRU barrier デッドロックを修正、#7209 シリーズの thead 精度スイートも同時に実行中。
  • 地平線(D-Robotics):調査期間内にコミット、PR、ニュースの動きは検出されず。

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

  • ナラティブとエンジニアリングが初めて同調:メインフォーラムでは2.2を「規模化共有最適化」(21社35チップ、1454オペレータ、+27.6%、264貢献者)として語ったが、同じ期間のGitHub側で最も重い一手はちょうどbuild-infraの6バックエンド22.04 builderとバックエンド別日次ホイールマトリクスだった——両者が答えるのは同じ問いである。チップ名簿は再現可能なデリバリー面で支えられなければならない。これは本期で最も記録に値する対応関係だ。
  • オペレータ領域は拡大しているが、拡大の方向は見極める必要がある:KernelGenは3日間で30余りのNVIDIAオペレータを落としたが、その多くは_dim_arange、values_copy、_has_same_storage_numelといった境界オペレータであり、幹のカバレッジがほぼ完了し、別名とビュー意味論の仕上げに入ったことを示す。一方、国産バックエンドの増分は依然として昆仑芯(20余筆の最適化)と達摩院玄鉄(GEMM補完)に集中しており、バックエンド間のカバレッジ格差は縮まっていない。FlagCVのリポジトリ立ち上げはもう一つの方向の拡大だ——LLMと科学計算からOpenCV式画像処理へと進み、6バックエンドのディレクトリを一気に展開したが、リポジトリにはまだ実行可能なオペレータがなく、短期的に過大評価すべきではない。
  • 量子ラインに製品形態が出現:FlagQuantum 0.3.0 / 0.3.1の双発 + 量智雲の対外発表により、「九鼎 / QUAFU タスク回復可能」といったエンジニアリング能力をリリースノートに書き込み、同時にハードウェア上では実行せず、agent runtimeを含まないことを明記した。分業は「FlagOSが実行スタックとスケジューリング、量子院がハードウェアとクラウド」であり、これは曖昧な「量智融合」スローガンよりも境界をよく説明している。
  • RISC-V側の動きはコンパイラの深部にある:SpaceMiTのsmt_rvisaは作者にSEW / VL / 命令選択を明示的に制御させ、私有TLEコピーを退役させた——こうした変更はどの対外口径にも現れないが、RVVバックエンドが「動く」から「性能を押さえ込む」へ進めるかを決める。
  • 要観察:1つ目は、大会分科会とワークショップの逐次議事録がまだ公開されておらず、メインフォーラム以外の技戦術的内容(統一IR、Token工場、端側デプロイ)は現時点で議題口径のみであること。2つ目は、量智雲がいつ対外開放されるか。3つ目は、FlagCVがいつ最初の実行可能オペレータを落とすか。4つ目は、訓練側(Megatron-LM-FL / TransformerEngine-FL / FlagScale)が3日間ゼロプッシュであり、大会前後の正常な静寂なのか2.3周期の起点なのかは、次期で確認する必要がある。

付録:情報源核查表

情報源 核查方式 結論
GitHub orgリポジトリ全量(61リポジトリ) 16リポジトリが期間内にプッシュ;FlagDNN / FlagFFT / Trident / docsの4リポジトリはブランチプッシュであり、デフォルトブランチの最新コミットはいずれも期間外
GitHub コミット検索(ページング) 147筆、12リポジトリ;2ページで取得(100 + 47)、さらにorgイベントストリーム100件と4リポジトリのcommits.atomで兜底
GitHub マージ済みPR検索 139筆、11リポジトリ(2ページ:100 + 39)、is:merged + merged:>=を真値とする
GitHub 審査中PR検索 239筆、23リポジトリ(3ページ:100 + 100 + 39)、うち27筆はイベントタグ
GitHub Release / タグ原子核查 31ライブラリのreleases.atom + 8ライブラリのtags.atom:FlagQuantum v0.3.0 / v0.3.1、FlagCX v0.15.0.dev0が期間内;FlagOps v2.0.5 / v2.0.6は10-15(期間外だが近接)
ニュース Google News RSS(24組中英文、プロキシ経由) 34件ヒット;実質収録は1イベント(10-18メインフォーラム)、残りはメンバー企業稿、旧聞再発、非FlagOS稿
ニュース HN Algolia(8組) 直接ヒットなし
ニュース DOIT現場報道 メインフォーラム内容を逐段検証(2.1 / 2.2 / 3.1);報道の「9月30日リリース」とリポジトリ落庫日(09-28 ~ 09-29)が不一致であり、本文で注記済み
公式チャネル CSDN FlagOSコラム 期間内に3つの分科会ライブページを追加(10-17 / 10-18);新規長文はなし
公式チャネル 智源コミュニティ hub.baai.ac.cn 期間内のFlagOS項目は検出されず
歴史対照 10-16デイリーレポート(前号) 重複排除核查:前号の截点は10-16 06:00;Step 5 Preview Day-0、沐曦チャレンジ戦、天数智芯 MiniCPM-V 4.7はいずれも収録済みであり、本号では重複しない

完全情報源リスト

gos-ai/build-infra/pull/1395> · https://github.com/flagos-ai/build-infra/pull/1400

ai/Torch-FL/pull/567> · https://github.com/flagos-ai/Torch-FL/pull/273 · https://github.com/flagos-ai/Torch-FL/pull/530 · https://github.com/flagos-ai/Torch-FL/pull/542 · https://github.com/flagos-ai/Torch-FL/pull/568 · https://github.com/flagos-ai/Torch-FL/pull/574 · https://github.com/flagos-ai/Torch-FL/pull/577 · https://github.com/flagos-ai/Torch-FL/pull/584 · https://github.com/flagos-ai/Torch-FL/pull/357