レポート期間：2026 年 10 月 19 日（月）から 10 月 23 日（金）まで、計 5 営業日。

素材出所：本誌の毎日 FlagOS 動向レポート 5 期（10-19 / 10-20 / 10-21 / 10-22 / 10-23、欠号なし）。うち 10-19 期は月曜朝報であり、調査期間は前号の締め切り時点 10-16 06:00 から起算する（約 72 時間、10-17 から 10-18 の「2026 人工知能オープンコンピューティング大会暨衆智 FlagOS 技術大会」全日程と量智雲発表を含む）；10-20 から 10-23 の四期は 24 時間ウィンドウで、首尾が相接し、末期末班は 10-22 06:00 から 10-23 06:00 までである。したがって本レポートの事実区間は 10-16 から 10-22 であり、10-16 から 10-18 の部分は原日付で标注する。

編成説明：バージョンとリリース、コンポーネントとコード共同構築、メンバー機関とベンダー適配、エコシステムとコミュニティ、トレンド観察の五つの次元をカバーする。五期のデイリーレポートをそれぞれのウィンドウで累加するとコミット 654 筆、マージ 661 筆となる；四つの完全な 24 時間ウィンドウのみを取る場合（10-19 から 10-22 の合併日）、コミット 507 筆、マージ 522 筆となる。単期でプッシュのあったリポジトリ数は順に 16、16、19、22、16 個であり、組織リポジトリ総数は 61 個である。バージョンとタグは各コンポーネントリポジトリの原子源（releases.atom）で独立に再確認し、デイリーレポートの口径と一致する。

1. 今週の要聞

  • 大会二日間が確定し、2.2 の規模口径が初めて検証可能な四層に分解された（10-17 ~ 10-18）：メインフォーラムで智源研究院副院長兼総工程師の林咏華が「衆智 FlagOS 2.2：token 経済から物理 AI へ」と題して披露——21 社のチップベンダー 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 に増加。同日、クロスチップデバッグと性能分析ツール FlagPrism および統一量子化ツール FlagOS-Compressor をリリース。報道では 2.2 は 9 月 30 日にリリースされたとされるが、リポジトリ清单の実際の落庫は 09-28 から 09-29 であり、両日の差は本文ではリポジトリ口径で処理する。

  • 量智雲が対外リリースされ、FlagOS の実行スタックが量子と古典の混合スケジューリングに跨った（10-18）：量智融合分フォーラムに「量智雲プラットフォームリリース」环节を設け、量智雲（Quantum-AI Cloud）は智源研究院と北京量子信息科学研究院が共同で推出し、FlagOS Execution Stack を通じて FlagQuantum を支え、「九鼎」AI 算力システムと「QUAFU」量子コンピュータに接続し、量子と古典の混合作業スケジューリングを実現。コード側も相互に裏付け：FlagQuantum v0.3.0 のリリース説明にはすでに九鼎と Quafu タスクの復旧可能、Quafu マルチ回路結果の順序保持が明記されており、リリース時にタスク提交、回執と結果順序保持の链路がパッケージ内にあったことを示しており、フレームワークインターフェースのみではない。境界も同様に明確——量子ハードウェア上では実行せず、MCP server と agent runtime を含まず、ハードウェア実行は九鼎と QUAFU 側が承接する。

  • 2.3 周期で初めて「需要から証拠へ」の当日閉環が出現（10-21 ~ 10-22）：10-21 に二份の FEP をマージ——FEP-0140 は vllm-plugin-FL に三つのバージョンラインを定義（0.24 で五社を補全、0.28 は十一月メインリリースとして十社を支持、0.32 で五社に導入）、FEP-0141 は SGLang 0.5.18 の十社ベンダーマトリクスと DeepSeek-V4 W8A8 目標を固定；10-22 に海光がすなわち vllm-plugin-FL と sglang-plugin-FL の両リポジトリで同日に vLLM 0.28.0 と SGLang 0.5.18 の対齊を完了（合計 84 ファイル、純増約 5700 行）。「マトリクスをドキュメントに書き込む」から「最初の実測通過」までわずか一日で、今季最速の需要から証拠への閉環である。

  • 交付面は同一週内に六バックエンドから七バックエンドへの収口を完了し、通信ライブラリを特例から通例に変更（10-16 ~ 10-22）：build-infra はまず FlagCX の nvidia、hygon、cambricon、metax、enflame、iluvatar 六バックエンドにそれぞれ 22.04 自包含 builder を落とし、glibc 下限を 2.38 から 2.35 に引き下げ；10-19 に昇騰四個の wheel を 24.04 ランタイムから同一形態に移行し清微と曦望を補齊；10-21 に清微と摩尔線程を接入し FlagTree 第五、第六バックエンドに；10-22 に昆仑芯が第七バックエンドに。同日 flagcx==0.14.0 を二條の nvidia 行のみに固定していた状態から全二十バックエンドに拡大し、新たにワンクリックインストールスクリプトを追加してマルチリポジトリ依存を一コマンドに収めた。

  • インフラの四つの課題が同日に补齐、組織の生産能力は「どう測るか、どう導入するか、どう共有するか」へ転換（10-20）：optest はリポジトリ作成以来初の実質的なコミット（PR #1、38ファイル）を迎え、12件のバックエンド設定と13社のハードウェアプローブを含む。FlagOps は FlagGems の五つの CI action を組織レベルの共有として取り上げ；build-infra はワンクリックインストールスクリプトを新規追加（1ファイル +308）；Torch-FL と TransformerEngine-FL は同日に FlagCICD 統一エントリを導入し L0 から L2 の段階的サポートを実現、FlagScale は選択的プラットフォーム CI を补齐。テスト、action、インストール、CI エントリの四つのラインが同一の調査期間内にそれぞれ一度の構造的なマージを完了した。

  • 量子スタックは設計契約から実行可能な経路へ（10-21 ~ 10-22）：10-21 に FlagQuantum は84件のコミット、34件のマージを行い、動的回路を「後続量子ビットにブール SSA 結果を加える」へ降級し Program IR に落とし込み、さらに正確な降級と復元をデプロイの強制前提とした；10-22 にはさらに53件のコミット、20件のマージで M3 中性原子を二つの設計ドキュメントから実行可能な経路へと仕上げた——Core 側のネイティブ Rydberg フロントエンド（PR #700）、Simulation 側の plan 1.7 動力学（#707）、Examples 側の移動原子パルス訓練（#714、40ステップ128区間の実測で無条件 RR が 0.0431 から 0.1228 へ上昇）。

  • マージ量は週内で新高を記録したが、増分の主体はオペレータではなくテスト契約（10-22）：当日の163件のマージは直近一週間で最高であり、うち FlagGems が91件と全組織の56%を占めた；一方でコミット量は18%減少、プッシュされたリポジトリは27%減少し、拡張ではなく滞留の消化である。テストの主線は lukatao 一人が61件（当該リポジトリの67%を占める）を担当し、23:40 から 23:47 の七分間に10件のバッチ PR を開き、テストケースをラッパー関数からオペレータの直接呼び出しまたは候補注入へと変更した。全週で KernelGen の新規オペレータは三つのバッチマージと疎族の掃尾に集中し、真に新規能力を追加した割合は二割に満たない。

  • エコシステム側ではリポジトリに由来しない三つの情報増分が現れた（10-19 ~ 10-22）：中華網が会後初のフルスタック技術分解記事を掲載（七つの量子化事例とグループ別証拠を補足）；新京報と北京日報クライアントが産業版の二次拡散を行い、新たに引用可能な口径として「新モデルが一日以内に12種類のチップ適配を完了」が加わった；Pandaily は英語でシステム全体を2.2として転述し、海外読者向けの初の完全原稿となった。他に北京市科委、中関村管委会の2026年度衆智 FlagOS 加速計画の擬宜立項公示があり、跨維智心「FlagOS-Robo に基づく AlohaMini 具身知能ロボット端側デプロイと応用実証」が入選し、具身方向で初めて成果物制約を伴う外部立項が出現した。

2. バージョンとリリース動向

今週のタグと Release リスト（北京時間）

時間 コンポーネント タグ / バージョン 説明
10-18 10:36 FlagCX v0.15.0.dev0 開発線タグ；同窓で Hygon UIL と adaptor ごとの bitcode をマージ
10-19 13:01 FlagTree 0.7.1a1+ascend3.5 昇騰 3.5 ビルド線、0.7.1 系初の alpha
10-20 20:11 FlagTree 0.7.1.dev1 基礎線が a1 から dev1 へ移行、ナイトリービルド成果物
10-20 20:12 FlagTree 0.7.1.dev1+ppu3.6 PPU 3.6 ビルド線、前項と一分差
  • 四つのタグ、三つのコンポーネント、いずれも正式版ではない：今週の調査期間内のすべてのタグは開発線またはハードウェアビルド線に属する。上記三つのコンポーネントを除き、FlagGems、FlagBLAS、FlagDNN、Torch-FL、vllm-plugin-FL、sglang-plugin-FL、FlagOps、FlagScale、FlagAttention、FlagSparse などのリポジトリは期間内に新規 Release がない。これは 2.2 が9月30日にリリースされて以降、2.3 が12月30日に GA となる前の典型的な空白期間である——対外バージョンは静かで、成果物ラインは活発である。
  • 前号を承接：FlagQuantum v0.3.0（10-16 13:34）と v0.3.1（10-16 19:20）は前号ウィークリーレポートのタグ表に既に記載済みであり、今号では量子スタックのベースラインバージョンとして踏襲し、重複計上しない。

FlagTree：リリースリズムはハードウェアバージョンごとにスライス

  • 4本のビルドラインが並存：0.7.1ラインには現在 ascend3.5、iluvatar3.6、xpu3.6、ppu3.6 の4本のハードウェアビルドブランチがあり、ベースラインは a1 から dev1 へ移行した。リリースノートには「pypi にバージョン番号を追加」としか書かれておらず、これは自動化されたナイトビルドであり機能リリースではない。リリースの有無を判断するには、バージョン番号の意味ではなくビルド行を見る必要がある。
  • バックエンドマトリクスは今週7行に拡大：清微 TX8（10-21、5番目）、摩尔線程 MUSA（10-21、6番目）、昆侖芯 XPU（10-22、7番目）が相次いで FlagTree ビルドラインと日常ビルド行に接続された。昆侖芯の行には5つの独自制約があり、10個のプリコンパイル済み入力、ディレクトリ名でマッチするキャッシュと2つの共有 tarball ルートを持つ LLVM 19 パッケージ、フロントエンドを環境変数で選択、pybind11 を正確に 3.0.1 に固定（3.0.4 ではディスパッチャが SIGSEGV を起こす）、そして Release ビルドパラメータを追加しない（ベンダー wheel 自体が rel-with-asserts である）ことが含まれる。
  • コンパイラ側の機能増分は少なく集中している：AMD RDNA は 10-21 に単一協調大規模コアデコード（M=1）からプリフィル（M>1、PR #1365、66ファイル）へ進み、RDNA プリフィル WMMA GEMM マイクロカーネルは GEMV ループと比較して M>1 時に10〜30倍高速化し、デコード側の split-K は lm_head を 17.0 から 14.9 ms/token に、層ごとのワイドプロジェクションを 14.9 から 10.5 ms/token に低減した。MUSA はコピーごとの TME キャッシュ永続化を追加（#1385）。SpaceMiT RISC-V バックエンドは新たに smt_rvisa ベアメタル eDSL を追加し、プライベート TLE 方言を廃止した（#1381、10-16、月曜周期の調査期間に属する）。

FlagGems：5.4 が正式ライン、5.5 開発ラインに新規追加なし

  • 正式ラインの基準は変わらず：5.4 は引き続き現在の正式ライン（09-28 リリース）であり、5.5.0.dev0 は 10-12 に開線後、今週新たなタグはなく、パッケージバージョンメタデータは依然として 0.1.0 を示している——海光 vLLM 0.28 の受け入れ記録では「インストール済みの1944個のソースファイルを e12a220 コミットまでファイルごとに照合し、メタデータバージョンは信頼できない」という方法で証拠を取っており、このコンテンツで VCS メタデータを代替する手法が今週も再び現れた。
  • オペレータカバレッジは最終段階へ：今週 KernelGen は3バッチに分けて14個の Nvidia オペレータをマージし、いずれもエイリアス、ビュー、スパースセマンティクスの境界オペレータである。10:43 のバッチはコピー、スパース構築、ネストテンソルテーブル構築（ger、sparse_bsc_tensor）。15:23 のバッチは値と形状のビューで、ネストテンソルのストレージオフセットとスパースインデックスの csr から coo への相互変換を補完（_values_copy、_shape_as_tensor）。22:23 のバッチは次元再配列と複素数ビュー（swapdims、moveaxis、view_as_complex_copy）。審査側では 10-19 の夜に約20件のスパースファミリー（_sparse_mm シリーズ、copy_sparse_to_sparse_、coo と csr インデックスの相互変換など）が一括で起票された。
  • バージョンリリースの先行シグナルは build-infra にあり：vllm-plugin-native の wheel は 10-21 に nvidia、metax、kunlunxin、hygon の4種類のバックエンドを補完してリリース登録され、10-22 には全バックエンドに対して flagcx==0.14.0 を統一して固定した。これらはすべて 2.3 正式リリース前の成果物準備である。

3. コンポーネントとコード共同構築

組織のリズム：5期累計で654コミット、661マージ

期 調査期間（北京時間） プッシュリポジトリ コミット マージ 審査中（期間内更新）
10-19 10-16 06:00 ~ 10-19 06:00（72時間） 16 147 139 239
10-20 10-19 06:00 ~ 10-20 06:00 16 93 88 180
10-21 10-20 06:00 ~ 10-21 06:00 19 115 120 195
10-22 10-21 06:00 ~ 10-22 06:00 22 164 151 154
10-23 10-22 06:00 ~ 10-23 06:00 16 135 163 183
合計 — — 654 661 —
  • マージされたリポジトリ別累計（各期デイリーレポートの開示基準）：FlagGems 290 件（43.9%）、build-infra 96 件（14.5%）、FlagQuantum 82 件（12.4%）、Torch-FL 53 件（8.0%）、FlagTree 25 件、FlagGems-vllm 21 件、vllm-plugin-FL 18 件、FlagGems-sglang 15 件、FlagBLAS 6 件、FlagCX 5 件、optest 5 件、FlagTrain 5 件、FlagGems-Experimental 3 件、sglang-plugin-FL 3 件、FlagOps 2 件、FlagAttention 2 件、community 2 件、FlagOS-Compressor 2 件、FlagSparse と TransformerEngine-FL は各 1 件；ほかに FlagCV、Trident、.github、flir が各 1 件。一部の期次は上位 100 件のマージ済み PR のみをリポジトリ別に集計しているため、リポジトリに帰属可能な合計は 641 件となり、差額の 20 件は展開されていない末尾のリポジトリ分である。
  • デュアルエンジン構造は不変：FlagGems と FlagQuantum の合計がマージ量の 56.3% を占め、build-infra と Torch-FL を加えた上位 4 リポジトリで 79% となる。週内の形態は「月曜から水曜は基盤と量子スタックが上昇し、木曜から金曜は FlagGems が集中的に消化する」というものだった。
  • 個人の生産量が高度に集中：lukatao は FlagGems でマージ日別に合計 119 件（10-20 が 23 件、10-21 が 35 件、10-22 が 61 件）を担当し、すべてテストと参照実装の修正だった；tengqm は build-infra の 35 件（10-20 が 7 件、10-21 が 15 件、10-22 が 13 件）を一手に引き受けた；lvyufeng は Torch-FL の MPS とプラットフォーム側を担当した；FlagQuantum のマージはすべて同一アカウントが完了した。

FlagGems（マージ 290 件）：テスト契約が第一の主線に

  • 3 回のロールバックと再構築：10-20 の PR #7361 はまず以前の共有テスト基盤の変更（17 ファイル +599/−1040）をロールバックし、互換性処理を各オペレータ自身のテストに移管した。その後 22 件の修正はすべてこの方向に沿って行われた——CPU 参照値モードでの入力スナップショット、テンソルビューの幾何、複素数と半精度の値比較、スパース構築と変換、生成ケースの実行可能性、アサーション境界、pytest マーカーの統一。これは「共有案では通用しないとまず認め、次にオペレータごとに補完する」というエンジニアリング上の修正である。
  • lukatao のケース改造 3 連続：10-21 の 35 件は生成式ケースをバックエンド横断で実行可能にした（split と squeeze、adjoint と mH と mT、as_strided、moveaxis と reshape_as と swapaxes、permutation ビュー、整数型と半精度の変換）。うち #7425 から #7440 は連続 16 件；10-22 はさらに 61 件で foreach オーバーライドを「直結ルーティング」バッチ 01 から 09 に変更し、最後の 9 つのオペレータスイートを共通候補 API 経由に変更した。すなわち「どの実装をテストするか」を暗黙から明示に変えたのである。
  • バックエンドスキップの治理が理由明記へ：昇騰と摩尔線程のスキップは入力領域ごとに個別に限定され（linalg_vander の複素数入力、logdet の複素数、row_stack_out のメモリフォーマット、trapz の complex32、orgqr の MUSA 零列、qint32 系列、Hygon cuDNN 検証）、さらに 10-23 未明にスパーススイート移植を 4 件連続でマージした（スパース log-softmax のバックエンド横断移植性、スパース検証器ファームウェアと直接ベンチマーク候補呼び出し、圧縮スパース検証器、共通スパースブロック構築器）。
  • ベンダー側の大型コミット 2 件：燧原の一括更新 #7077（26 ファイル +3520/−511、タイトルは「update from enflame 20261013」のみで個別明細なし）；昆仑芯融合 MoE #7107（13 ファイル）は 3 つの fused_experts バリアントと dispatch_fused_moe_kernel を補完し、集約スコアは 1.324 から 1.329 に向上、さらにベースラインが代替実装であることと dispatch_fused_moe_kernel の 0.626 が基準未達であることを自ら申告した。
  • 昆仑芯最適化ライン：10-20 が 9 件、10-21 が 17 件、10-22 が 13 件で、実装の補完から精度と形状に応じたゲート設定へ移行——w8a8_block_fp8_matmul に FP8 能力ゲートを追加、fp64 と grouped-MM は能力に応じてスキップし理由を明記、単層 GRU ユニットをフラットな 1 次元 kernel に変更して集約スコアを 0.4217 から 0.8253 に向上、sgn の大 numel 経路を安価な本体と設定可能な 1 次元 tile に変更。

FlagQuantum（マージ 82 件）：契約からコードへ、そしてコードから拒否へ

  • 動的回路の IR 化（10-21）：PR #681 は型付き動的 Program IR 契約を定義；#683 は中回路測定を「後続量子ビットとブール SSA 結果」へ、reset を明示的な後続量子ビットへ降格し、合接と選言をアクティブなブール値上の正規 DNF にマッピングし、降格結果が完全な関数グラフと逐語的に一致する場合にのみ復元する；#694 は正確な降格と復元を動的デプロイの必須前提とし、検証されていないプログラムは任意の provider を呼び出す前に停止する。
  • M3 中性原子を契約から実行可能へ（10-22）：Core 側の #700 はネイティブ Rydberg 制御を ProgramRecord 上で直接提供するフロントエンドを実現（RydbergProgram は move、pulse、to_ir の三つのアクションを提供し、「制御された位置は物理的存在を意味しない」ことを明示）；Simulation 側の #707 はネイティブ Rydberg プログラムを既存の Lindblad 計画に通し、plan 1.7 をちょうど七つの外層フィールドとして密封；Examples 側の #714 は二つのパルス振幅を訓練し原子対を移動させ、40 ステップ 128 区間の実測で無条件 RR が 0.0431 から 0.1228 へ上昇、生存条件 RR 0.1500、no-flag 選択 RR 0.1439。
  • 合入量の半分は拒否と削除に費やされる：10-22 の #701 はネイティブ物理プログラムのパッケージ時に AttributeError ではなく一律 CapabilityError を送出；#705 は提案 082 に従い、外部サービスが一度も対応しなかった NeutralAtomProvider と二つの Remote エクスポートを直接削除し、エイリアスも空シェルも残さない；#716 は提案 083 を提出し Runtime の sample_terminal プリミティブを定義し、サンプル末尾に「proposed, not implemented」と出力。こうした動作は能力を増やさないが、M3 の境界が信頼できるかどうかを決定する。
  • 作図と引用可能性のチェーン補完：10-21 の #668 は遅延 LaTeX バックエンドと「エンコーダ—回路—測定ヘッド」ハイブリッドモデルビューを追加（43 ファイル +14311）、Notebook は SVG を優先表示；#684 は CITATION.cff を追加（バージョン 0.3.1、リリース日 2026-10-16、Apache-2.0）；#687 は中性原子の再利用可能な能力と欠落契約を棚卸しし、物理生存 0.8187、無条件 RR 0.4094、生存条件 RR 0.5 の独立数値参照を提示。
  • 計算力の拡張：10-20 の #653 と #661 は CPU スイートを八台の A800 runner に移行し GPU テストを自動トリガー、長時間タスクを並列化——推進方式はこれ以降、機能展開ではなく大規模な一貫性検証となる。

build-infra（合入 96 筆）：「N 個のバックエンド × M 類の成果物」を一行に圧縮

  • builder マトリックスの形成：base/ ディレクトリは今週、六社から九社十七のベースラインイメージへ拡張——nvidia（cuda12.8 / 13.3）、ascend（cann8.5.0 / 9.0.0、910c 含む）、cambricon（neuware4.4.3 / 4.7.2）、enflame（tops1.9.10 / 1.10.6）、hygon（dtk26.04）、iluvatar（corex4.4.0 / 4.5.0）、metax（maca3.7.2.1 / 3.8.1.3）、sunrise（tangrt1.2.0）、tsingmicro（tsm260610）。
  • FlagCX の 22.04 収束：10-16 から 10-18 にかけて六バックエンドそれぞれに自己完結型 builder を一つずつ配置し、各 builder は ubuntu:22.04 を glibc の下限とし、ベンダー SDK をイメージにプリセットし、wheel-info に痕跡を残す；#1407 は dispatch レベルの --no-bitcode スイッチを追加し、v0.14.0 タグが bindings/ir より先行する場合に非 nvidia adaptor 上で直接エラーを送出するのを回避。
  • FlagTree ビルド行：builder を「二つのワークフローで一つのことをする」から単一マトリックスへ統合し、backends.yaml の一行が Containerfile、イメージリポジトリ、runner ラベル、ディスク予算、受け入れアサーションを携帯。清微、摩尔線程、昆仑芯の三行は同一テンプレートで着地し、差異はプリコンパイルツリーとツールチェーン解決パスのみ。
  • インストールパスの収束：10-20 の #1425 はワンクリックインストールスクリプトを追加（1 ファイル +308）、初めて「複数リポジトリ、複数依存セット」のインストール過程を単一コマンドに収束；#1435 は CUDA ディストリビューションバックエンドの vllm ネイティブ拡張ホイールを復元し、PEP 440 がビルドタグを無視すること、短いピン留めが誤ったバックエンドにインストールされる落とし穴を指摘。
  • ビルドドキュメントのサイト化：10-22 の十二筆のコミット（#1462 から #1470）は vllm-plugin-FL、FlagTree、FlagCX、FlagGems、FlagLibs、Megatron、SGLang、verl の八コンポーネントの設計記録とサイトページを五時間以内に連続合入、今季初めてビルド設計を検索可能なコンテンツとして書き出した。

Torch-FL（合入 53 筆）：プラットフォーム面の拡張後に項目別補完へ移行

  • MPS ラインが主体を完了：10-19 から 10-21 の三日間で MPS 関連のマージは計 8 件——ネイティブ mm と bmm の MPSGraph gemm クラスへの組み込み、softmax と要素ごとの neg と pow のネイティブ化、コンパイル後の MPSGraph プランキャッシュ、キュー内ワークのキープアライブとネイティブ masked_fill、Qwen3.5 のネイティブ MPSGraph カーネル、Metal 上の高度なインデックス収集；10-20 の #566 は 69 ファイル +22929/−236 でリポジトリに反映され、CI は GitHub ホストの Apple Silicon arm64 runner を使用し、「x86_64 の macOS runner には Metal デバイスがなく、環境チェックの失敗は想定通りの結果である」と明示的に宣言している。
  • 清微の三連：torch.compile が TX8 に到達（#541、14 ファイル、作者はデバイス属性クエリがハードウェアの実測値ではなく定数しか返せないことを明示）、ホスト側乱数カーネル（#604）、デバイスタイムラインの torch.profiler への組み込み（#630、rocprofiler-sdk ベースの DeviceTracer、TX8110 で実測）。
  • マルチカード正確性の 2 件のハード修正：昆仑芯の CrossDeviceMemcpy はこれまで同カードセマンティクスの xpu_memcpy を呼び出しており、2 枚のカードのポインタを渡すと −801 を返しターゲットが書き込まれず、任意のカード間コピーがサイレントに無効となっていた。10-22 に xpu_memcpy_peer へ切替（#634）；liblaunch_shared.so の undefined symbol: cudaMemcpy は Triton ランチャーの dlopen 後にしか解決できないため、昆芯の CUDA 互換ランタイムを事前ロードするよう変更（#632）。この 2 件はパフォーマンス数値を一切生まないが、これまでのすべてのマルチカード実験の結論は再計算が必要になる。
  • CI とプラットフォーム行：BI-V150 共有 CI 行（#569、24 ファイル、初期実行では既知の失敗を残して bring-up を完了させることを許可）、FlagCICD 統一エントリと L0〜L2 の段階分け（#599）、AGENTS.md を唯一のエージェントガイドとして確定（#601）、昆仑芯 P800 の 2.9 安定ブランチライン（#273）、プラットフォームの pytest 結果を FlagCICD へ報告（#542 と #577）。

FlagTree（マージ 25 件）：行列のマス埋め、言語レイヤーは安定待ち

  • 今週の FlagTree のマージはほぼすべて「バックエンド×バージョン×ワークフロー」の三次元マトリクス上にある：燧原 enflame3.6-gcu300 の FlagGems ベースラインとテストワークフロー、燧原 vLLM ベンチマークのワークフローへの組み込み、AMD amd3.6 のベースラインとテスト、昇騰 3.5 py312 のデリバリと修正、triton_v3.5.x ブランチの codeowner 更新、XPU3.6 の vllm ベンチマークワークフロー。
  • 唯一の構造的変更は AMD プレフィル：10-21 の #1364 は FlagMega に amd-gfx1100（W7900）と amd-gfx1201（R9700）の 2 ターゲットを追加し、bf16 の Qwen3-1.7B が RDNA 上で単一の協調大型コアによりデコードを完了できるようにし、128 個のワークグループが共駐できずフェンスデッドロックとなるのを避けるため、計算 warp の上限を 4 に抑制；10-22 の #1365 ではさらに M>1 のプレフィルと「プレフィルは最後のトークンの logits のみ出力する」を補完。
  • RISC-V とのインターフェース：smt_rvisa により作者は SEW、VL、タイル分割、命令選択を明示的に指定でき、カーネルは C++ builder API 経由で下降し、別途 LLVM 直出路線では spine-opt を丸ごとスキップ；バックエンドは私有の TLE 方言コピーを保持せず、汎用の third_party/tle を消費するよう変更。こうした変更は対外的な説明には一切現れないが、RVV バックエンドが「動く」から「性能を出せる」へ進めるかを左右する。

推論スタック：vllm-plugin-FL（18）、FlagGems-vllm（21）、FlagGems-sglang（15）、sglang-plugin-FL（3）

  • バージョンアライメントが今週の主軸：vllm-plugin-FL側は10-19に達摩院玄鉄バックエンドをvLLM 0.28.0へ昇格、10-22に海光が0.28.0を着地（配布パッケージ0.28.0+empty、eagerとFULL_AND_PIECEWISEの2種類のグラフモードをそれぞれ実行、TP=2、最大モデル長4096、VRAM利用率0.85）；sglang-plugin-FL側は10-21に昇騰910Cを0.5.18へ独立適応（67ファイル、受け入れには4カード整機イメージゲートを含む）、10-22に海光BW1000を0.5.18へ昇格（65ファイル、単機TP2と物理2ノードTP4/PP1、TP2/PP2を含む）。沐曦、清微、燧原、崑崙芯の同バージョン項目は依然として審査中または未着手。
  • グラフモードが2つの国産バックエンドへ展開：曦望Sunriseと燧原GCU300のグラフモード（10-19、inductorにcudagraphを追加）が同日にマージされ、vLLM側のCUDA Graph経路はもはや昇騰と崑崙芯でのみ検証されるものではなくなった；10-21に昇騰がデコードグラフ実行を補完し、Qwen3.6-27Bと35B-A3Bのテキストおよび画像推論へ適応（26ファイル +2513）。
  • モデル側が公開リリースに先行：FlagGems-vllmのGLM-5.3 Flash公開オペレータ（#900）とQwen4のHC / PLE / sparse QSAの3種類のオペレータ（#896）はいずれも10月に初めて登場した新アーキテクチャ用語であり、オペレータがモデル公開に先んじて着地した；続いて#977が沐曦融合MoE向けにTP=2設定を補充し、C550上で14個のM値の平均速度が1.065倍向上。
  • 競技が初めてメインリポジトリの供給源に：FlagGems-sglangは10-20に10件の競技マージがすべて40分以内に同一メンテナによってマージ（トラック1 tiny-k-gemm、pack-topk-ids、moe-topk-sum、indexed-scale-shiftなど）、併せて#163の単一+28940のベンチマークスナップショット；10-22の#204 fused_pack_qkvと#201 fused_sigmoid_mulは、競技の成果がコミット物に留まらずメイントランクへ入ったことを示す。

その他のコンポーネントと統合基盤

  • FlagBLAS（6 件）：海光 gfx936 六精度 GEMM（#151、sgemm から zgemm まで、+7060/−127、dgemm は fp64 MMAC ドット積を使用し FlagTree の fp64 MMAC サポートに依存）と L1 サポート（#149）。10-22 に天数 L1 最適化（#153）と摩尔線程 GEMM（#152）を追加。BLAS の精度補完によりコンパイラ側の機能ギャップが露呈し、今週のクロスリポジトリ連携の実証例となった。
  • FlagCX（5 件）：Hygon Device API と統一 IR の HIP バックエンドを有効化（#643）、デバイス bitcode を nvidia のハードコードではなく adaptor ごとに生成（#668）、v0.15.0.dev0 タグ、マルチセグメント VMM ウィンドウ（#658、42 ファイル +7667、CUDA、海光 DU、沐曦、PPU それぞれにマルチセグメントコールバックを追加し、有界ディスクリプタでセグメントファイルディスクリプタを交換、集合通信成功後にのみウィンドウを公開）、プラットフォームルーティングと CI の統一（#665）。
  • FlagTrain（5 件）：摩尔線程バックエンドと 2 つのオペレータ（#20）、KMCompiler の Megatron と TransformerEngine サポート（#22）、blocked_flash（天数）と mixed_moe_gemm（#23、#24）、multi_tensor_lion（4 バックエンド）と quick_gelu（#16、#26）。このリポジトリは 10-15 に初版ドキュメントが出たばかりで、現在最も若いオペレータリポジトリである。
  • 疎行列、アテンション、量子化：FlagSparse が MUSA 最適化をマージ（#113、外部コントリビュータ NCIC-AlphaSparse ブランチより）；FlagAttention は kv-outer の MiniMax M3 疎アテンション prefill における約 40 個のホスト側小オペレータと .item() 同期を 2 つの Triton カーネルに置き換え、ビルドが 1.5 から 2.5 倍高速化し、同期なしスケジューリングと全パスグラフキャプチャを実現（#107）；FlagOS-Compressor が DeepSeek V4.1 と MiMo V2.5 の linear のみ INT8 エクスポート（#10）と MXFP8、NVFP4 ソースチェックポイント変換（#11、143 テスト合格）をサポート。
  • optest（5 件）と FlagOps（2 件）：optest はスクリプト集合からインストール可能な wheel に変わり（#4）、src レイアウトに変更（#5）、console commands を公開（#6）、CI ジョブ名をリポジトリ + バックエンドで表示（#2）；FlagOps が FlagGems の 5 つの action を引き継いだ後（#15）、FlagGems 側でローカル action から共有 action への移行を同時に完了（#7346、#7416）。
  • 新規リポジトリと実験リポジトリ：FlagCV（10-14 リポジトリ作成）は 10-18 深夜に初コミット、10-19 未明に PR #1 の骨格をマージ——インターフェースは OpenCV に整合（core と imgproc の 2 組のヘッダファイル）、マルチバックエンド構造は FlagDNN を踏襲、カーネルは Triton で記述、backends/ に nvidia、thead、ascend、hygon、iluvatar、mthreads の 6 バックエンドを一挙に展開したが、実行可能なオペレータはまだない；Trident は 10-12 に作成された実験的ブリッジレイヤー（Triton または Torch スタイルの Python 関数を MLIR と LLVM にコンパイルし tvm_ffi 経由で実行）で、今週 #3 で複数の ATen オペレータテストを補完；flir はレビュー中の #83 で TensorView 方言と tile.load および tile.store ビューを追加、CommonIR 方向の実質的な動きである。

4. 会員単位とベンダー適配

  • 昆仑芯：今週エンジニアリング密度が最も高いバックエンドであり、公開メンバー単位のリストには含まれていない。帰属可能なマージは約40件（マージ日10-20が9件、10-21が18件、10-22が13件、10-19は調査期間内で単独計上なし）。内容はオペレータ、ビルド、ランタイムの3層に跨る。オペレータ側は実装の補充から精度と形状によるゲート設定へ移行（FP8能力ゲート、fp64とgrouped-MMを能力に応じてスキップ、GRUのフラット一次元kernel集約スコア0.4217から0.8253、融合MoE三オペレータ1.324から1.329）。ビルド側はFlagTreeの第7バックエンドに。ランタイム側はクロスカードコピーのサイレント故障とプリロード順序という2つのハード缺陷を修正。リスクはオペレータ側にあり、多くの変更は同一オペレータの別tileまたは融合であり、統一的な性能ゲートが欠けており、集約スコアもベースライン代替によりベンダー間比較ができない。
  • 海光：今週、2つの推論プラグインリポジトリで同時に上流バージョン整合を完了した唯一のベンダー。vLLM 0.28.0とSGLang 0.5.18が同日マージ（合計84ファイル、純増約5700行）。検証環境は1カード64 GiBのBW1000クラスタ。vLLM側は配布パッケージ0.28.0+empty、SGLang側は物理2ノードTP4/PP1とTP2/PP2でパイプライン並列の協調終了も修正。併せてFlagBLASの6精度GEMMとL1、FlagGemsのFP8疎和反向ファームウェア、FlagDNNのhygon修正1件。その再利用価値は、emptyバックエンドのアップグレード手順をバージョン表付きテンプレートとして書き残した点にある。
  • 清微智能：今週補完したのはオペレータカバレッジではなくインフラの弱点ばかり——torch.compileのTX8対応（#541、デバイス属性は定数しか返せない）、ホスト側乱数カーネル（#604）、デバイスタイムラインのtorch.profilerへの組み込み（#630、TX8110実測、同時にベンダービルドスイッチを固定）、FlagTreeビルド行の接続と日次ラインへの登録（#1436、#1440）。順序は記録に値する。まずCIでビルドでき、次に乱数性を再現でき、さらに性能が見え、最後に最適化を語る。
  • 昇騰：今週の主線は2つのプラグインリポジトリのバージョンとグラフ実行——vLLM 0.24全デコードグラフ実行にQwen3.6-27Bと35B-A3Bのテキストと画像推論（#606）、SGLang 0.5.18の910C独立適配（#131）、W8A16 FP8 TopK（#6030）、SoCごとのfp32能力によるmatmulゲート（#616）、4つのホイールを22.04 builderへ移行（build-infra #1414、glibc下限2.38を2.35へ）。テスト側の十余件はFP8入力構築、tile blockエラー、参考ドキュメントであり、依然として修正が中心。
  • 摩尔線程：MUSAがFlagTreeの第6バックエンドとなり日常行に参加（#1449、#1456）、ローカルバイナリはref変化に応じて明示指定が必要。FlagTreeにコピーごとのTMEキャッシュ永続化を追加（#1385）。FlagBLASにGEMM実装を追加（#152）。FlagGems側は複素数cholesky_solveの入力をCPU構築に変更、moe_load_balance_lossのMUSA特化をマージ。5件のテストスキップはこのバックエンドの入力域制限に集中しており、失敗面は依然として「入力非対応」が主で実装エラーではないことを示す。
  • 燧原：今週の動きはベースライン、ベンチマーク、パッケージング、アサーション、グラフモードの5環節をカバー——enflame3.6-gcu300ベースラインとテストワークフロー、vLLMベンチマークのワークフロー化、builder検証をデータ駆動へ変更、toolkit debをイメージへプリセット、GCU300グラフモードのマージ。FlagGemsのベンダー一括更新#7077（26ファイル+3520/−511）は一気に主干へ入ったが、タイトルには日付のみで逐条明細がない。FlagTree側は偶発的なバスエラーにより02-sparse-mlaケースを無効化し、vllm benchmarkパラメータを更新。安定性問題は依然としてケース層にある。
  • 天数智芯：CIとビルドの両側が揃う——BI-V150共有CI行のマージ（#569、CoreX 4.5.0）、iluvatar独立ランタイムによりホイールがCPU版torchにリンク可能（#593）、build-infraのpinを22.04へ更新し再リリース。コード側は依然としてmasterへの直接プッシュが主（FlagDNN4件に3件、PRフローなし）。等価性能ベースライン（equivalent_baseline.cppなど+8157）が当該リポジトリ今週最も実質的な成果。プロセス規範化はTorch-FLとFlagQuantumに後れを取っている。
  • 沐曦：今週の投入は性能档と審査中の対になるデプロイ方案に集中——2ノードC550、TP16のMiniMax M3 BF16最適化档（#540、09-18に起票、10-18も依然更新中）と4ノードC550、TP8とPP4のKimi K3 MXFP4とBF16実装（#607、10-19新規起票、vLLM 0.28互換ブランチで実行）。マージ済みはFlagGems-vllmの融合MoE TP=2設定（#977、C550上で14のM値平均1.065倍、M≥4096時の共有メモリ設定越界も修正）とbuild-infraのmetaxネイティブホイールをプラットフォームごとに如実に表示。
  • 達摩院玄鉄（真武PPUを含む）：FlagBLASに真武PPUの4精度GEMMを追加し

NN/TN/NT/TT の4種類のレイアウト変種を追加（#148、複数 GEMM 転調 level3）。FlagGems はバックエンド GRU barrier デッドロックを修正（#7203）。FlagGems-vllm は W8A8 block INT8 行列乗算を新規追加（#954、9ファイル +1493、チューニング設定と自動チューニング接続を含む）し、W8A8 MoE の整数累加を修正。vllm-plugin-FL は vLLM 0.28.0 にアップグレード（#574）。4つのラインはそれぞれ基盤ライブラリ、並行正確性、量子化オペレータ、バージョン追随に対応する。

  • 曦望と進畳時空：曦望（sunrise）は10-19に22.04自己完結型 builder をリリースし、ホイールを記録して22.04-clean で再リリース、10-19にグラフモードをマージ（#569）、プローブは optest 統一施設に進入。進畳時空（SpaceMiT）の smt_rvisa（FlagTree #1381）は RISC-V AI 方向で初めてコンパイラ言語層拡張に進入し、FlagGems の同一バックエンド審査中項目とともに RISC-V ラインの今週の全動作を構成する。
  • 地平線と寒武紀：今週、両社は組織内で専用リポジトリのプッシュとマージがなく、うち10-21、10-22の連続2調査期間は静穏であった。デイリーレポートは既に連続2日これをギャップとして标注している。来週も動作がなければ、リスク項目として単独で記載すべきである。

5. エコシステムとコミュニティ

  • カンファレンスと事後報道が三段階の拡散を形成（10-17 ~ 10-22）：10-18 のメインフォーラムは DOIT の現場レポートが最初に報じた。10-19 には中華網が事後初のフルスタック技術解説を掲載し、「オペレータとコンパイル、補助研發、プラグインと量子化、Token サービス、端側とプラットフォーム」の五段構成で、これまで未カバーだった量子化の事実を補った——KernelGen は既に九つのチップをサポートし、今四半期に新たに 765 個のオペレータを生成、うち 416 個が少なくとも五つの国産チップ上で精度検証に合格し、ネイティブオペレータの 80% 以上の性能に達した。FlagGems-SGLang の 40 個のオペレータは NVIDIA 上で全て合格し、Qwen3.5-397B-A17B を W8A8 にするとモデルファイルは 751.41GB から 382.45GB に減少（49.1% 減）し、GPQA-Diamond は 84.85% を維持した。10-20 には新京報と北京日報クライアントが産業版の二次拡散を行い、新たに引用可能な口径として「新モデルが 1 日以内に 12 款のチップ適配を完了」が加わった。10-22 には Pandaily が英語で体系的に伝え、中国電信 Xing4.0-29B-A4B の長入力初回トークン遅延がネイティブオペレータ比で 19.87% 低下したことを初めて公開した。
  • 量智雲の境界は多くの宣伝より明確に書かれている：FlagOS は実行スタックとスケジューリングを担い、量子院はハードウェアとクラウドを担う。v0.3.0 と 0.3.1 は量子ハードウェア上では動作せず、MCP server と agent runtime を含まないことを明示している（MCP アダプタは独立パッケージ）。外部からの観察点は、量智雲がいつ対外開放されるか、そして FlagQuantum の海光と摩尔線程バックエンドがクラウドスケジューリングに組み込まれるかどうかである。
  • ガバナンス面で初めて 2.3 の受け入れ対象が固定された：FEP-0140（vLLM 三バージョンライン）と FEP-0141（SGLang 0.5.18 十社ベンダー）が 10-21 にマージされ、テストは 2.2 ワークフローを再利用し、ベンダーまたは FlagOS イメージ内で必要に応じてソースから目標プラグインバージョンをインストールする。受け入れにはインストール、稠密・MoE のテキストと画像推論、性能、並行性、24 時間安定性が含まれる。同時期に .github は組織ホームページの中国語・英語両版に Slack 招待入口を追加し、新規開発者が既存の招待を見つけられない問題を解決した。
  • 具身方向で初の成果物付き外部プロジェクトが登場（10-22）：北京市科委、中関村管委会の 2026 年度「中央引導地方」および「新一代信息通信技術革新」専項衆智 FlagOS 加速計画方向の擬立項公示で、跨維智心《FlagOS-Robo に基づく AlohaMini 具身智能ロボット端側配置と応用示範》が選定された。受け入れには具身モデルの訓練適配と推論配置、国産チップ端側応用、マルチチップ推論精度一致性テスト、および具身モデル・運動制御小脳・本体制御の協同が含まれる。これは FEP マトリクスとコンテストに続く三つ目の成果物制約付き外部プロジェクトである。
  • コミュニティ影響力イベント（10-19、回顧稿は 10-21 公開）：Triton Developer Conference 2026 がサンノゼで開催され、来場開発者は 500 人を超えた。FlagOS チームの KernelGen は会場で唯一「マルチチップオペレータ自動生成 Agent」を体系的に展示したプロジェクトであり、FlagTree コンパイル基盤の上に構築されている。2.2 口径では 8 款のチップ上で自動生成されたオペレータ数は 77 から 551 個、性能比較区間は 2.58 倍から 38.33 倍（原文注記：各講演者のテスト条件であり、プロジェクト間で外挿すべきではない）。
  • コンテストと開発者運営：CSDN FlagOS サイトに掲載された SGLang クロスチップオペレータ最適化コンテストのトラック 1 は既にメインリポジトリへマージ可能な成果を産出し始めたが、リズムは依然としてバッチ式であり分散型ではない。10-22 には高校円卓ライブ配信が新たに追加された（グローバル AI オープンコンピューティング教員発展計画下の教学落地）。これはコミュニティ活動であり技術リリースではない。
  • チャネル核查結論：24 組の中英語検索語を五つの期間で調べたところ、コンポーネント名（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen）の直接検索は持続的にゼロヒットだった。有効な項目はすべて成員単位の稿、産業メディア、コミュニティ自有チャネルからのものである。CSDN FlagOS コラムトップページの最新オリジナル稿は依然として 08-28 の Day0 適配稿で止まっており、智源コミュニティ検索ページはクライアントレンダリングのためフレームページのみ取得可能、HN Algolia の八組の検索にタイトル直接一致はなかった。生態構築の核查可能な進展は依然としてリポジトリを基準とする。

六、トレンド観察

  • 機能拡張より先に納品面の統一：今週最も比重の大きい作業は新しいオペレータではなく、glibcの下限、builderの形態、通信依存、インストールコマンドであった——22.04の自己完結型builderは六バックエンドから七バックエンドへ収束し、flagcx==0.14.0は二行のnvidia行から二十のバックエンドへ拡大し、ワンクリックインストールスクリプトは複数リポジトリの依存を一つのコマンドにまとめ、optestはテスト基盤をインストール可能なwheelに変えた。これらの動きに共通する効果は「バックエンドを替えてもインストールスクリプトを変更しなくてよい」ことであり、これはどの単点的な性能向上よりも2.3の納品速度を直接左右する。
  • 要求から証拠への閉ループが今週は一日に圧縮された：10-21に二本のFEPがマージされバージョン×ベンダーが行列として書かれ、10-22には海光が最初のマスを点灯した。同様に、10-20のoptestとFlagCICDの着地後、10-22のFlagGemsケース改造は即座に「直結候補」へと向かった。2.3の残り九社と二本のバージョン線が今後六週間の主な作業量であり、観察点は同じ0.28.0が清微、沐曦、燧原、昆仑芯で海光のemptyバックエンドテンプレートを再利用するかどうかである。
  • 量より質を優先する姿勢はすでに定着した：全週661件のマージのうち、実際にオペレータ能力を新たに追加したものは二割に満たず、主体はテスト契約（少なくとも119件が単独の人物によるもの）、自動化による成果物（KernelGenの三バッチ14オペレータとスパース系が審査中）、そしてビルド基盤である。これは2.2リリース後の「まず既存能力を正確に測る」という姿勢と一致し、代償としてオペレータ数の伸びが鈍化し、対外的な性能数値の更新も鈍化する。
  • 量子スタックは再現可能な推進方式を形成した：まず契約を拒否可能な実装として書き、その後ブロックごとに開放する：サブパッケージを拡張しつつコアをロックし（159の新規公開名がサブパッケージに入り、Stable Coreの41エクスポートは不変）、デプロイ前検証を強制ゲートとして書き、外部サービスを持たないベンダーを削除し、未承認のサンプリングインターフェースを凍結した。今週のマージ量の半分は拒否と削除に費やされ、これがM3以降の境界が信頼できるかどうかを決める。リスクは20から34件のマージがすべて単一アカウントで完了しており、物理意味の検証が同じ人々によるテスト作成と実装に依存し、外部から独立して再検証できないことである。
  • 可観測性とマルチカードの正確性がマルチバックエンドの新たな弱点となった：清微では初めてデバイスタイムラインが存在し、昆仑芯のクロスカードコピーはこれまでずっと誤っていた（バイトが一度も書き込まれず、同期呼び出しでは隠蔽されない）。これら二件はいずれも「動く」ようになった後に起きた。過去二週間のテスト移植とケース契約の改造、今週のoptest集中化は、本質的に同じ判断の異なる表現である——マルチバックエンドが動くようになった後の最初の関門は再現性であり、より速いことではない。
  • 三つのリスク項目は次号で確認が必要：一つ目は「一括更新」系のコミットに照合可能な明細が欠けていること（燧原の26ファイル+3520/−511が具体的なオペレータと収益に対応できない）、昆仑芯の融合MoEは代替ベースラインで測定されており、いずれも後続のクロスベンダー比較を歪める。二つ目は地平線と寒武紀が二日連続で沈黙していることで、来週も続くならウィークリーレポートで別掲すべきである。三つ目は訓練側（Megatron-LM-FL、FlagScale）の今週のプッシュが乏しく、TransformerEngine-FLの三件のNPU PRがまだマージされておらず、2.3サイクルの訓練スタックの進捗が推論スタックに後れを取っていることである。
  • 次の観察点：FlagTree 0.7.1の開発ビルドが2.3前に正式版へ移行するか；vLLM 0.28の二社目（清微または沐曦）が海光テンプレートを再利用するか；FlagCVがいつ最初の実行可能なオペレータを着地させるか；大会分科会とワークショップの逐次議事録が公開されるか；量智云がいつ外部公開されるか。

付録：素材と検証

  • 素材：2026-10-19、10-20、10-21、10-22、10-23 の5期 FlagOS デイリーレポート。調査期間はそれぞれ 10-16 06:00 から 10-19 06:00（72時間）、10-19 06:00 から 10-20 06:00、10-20 06:00 から 10-21 06:00、10-21 06:00 から 10-22 06:00、10-22 06:00 から 10-23 06:00 で、期間内に欠号はない。
  • GitHub 核查方法：組織 flagos-ai の全61リポジトリについて日次でプッシュ状態を核查した。マージ済みは is:merged に merged:>=ウィンドウ起点 を加えた検索を真値とし、審査中は is:open に updated:>=ウィンドウ起点 を加えて検索した。メインブランチの新規追加は commits?sha=<ブランチ>&since=<UTC> で再確認し、非デフォルトブランチへのプッシュは org イベントストリームと commits.atom で補完的に判別した。リポジトリ別のマージ数は各期デイリーレポートの開示基準の累計であり、一部の期は先頭100件のマージ済み PR のみを集計している。リポジトリに帰属可能な合計は641件で、差額20件は展開されていない末尾のリポジトリ分である。
  • バージョンとタグの核查：コンポーネントリポジトリの releases.atom アトムソースで逐一再確認したところ、今週のウィンドウ内で4つのタグ（FlagCX v0.15.0.dev0、FlagTree 0.7.1a1+ascend3.5、0.7.1.dev1、0.7.1.dev1+ppu3.6）を検出した。FlagGems、FlagScale、FlagBLAS、FlagDNN、Torch-FL、vllm-plugin-FL、sglang-plugin-FL、build-infra、FlagAttention、FlagSparse、FlagOps などのリポジトリには新規 Release はなく、デイリーレポートの記載と一致している。
  • ニュース側の核查：Google News RSS の24組の中国語・英語クエリ語（コンポーネント名は14日、メンバーと産業語は7日）、HN Algolia の8組、CSDN FlagOS コラム、智源コミュニティとメンバー単位の原稿を逐一クロス検証した。有効な項目は「原サイト優先」で引用し、遅延インデックスや旧聞の再配信（例えば火绒性質の相場稿、工博会展の受賞旧聞など）は規則に従って除外し、項目に計上していない。
  • 基準説明：日付と時刻はすべて北京時間である。月曜期は72時間をカバーし、その 10-16 から 10-18 の内容は元の日付で标注しており、前回のウィークリーレポート（10-12 から 10-16 をカバー）とは境界日に重複が存在する。重複部分のタグと FEP は前回で既に列挙済みのため、今回は重複計上しない。「マージ済み」とは GitHub 検索のマージ時刻がウィンドウ内に落ちる PR を指し、デイリーレポートの日次ウィンドウ集計とは約1日のずれがある。本レポートは統一してマージ日基準を採用する。
  • 限界：ブランチレベルの活動（例えば FlagPrism の燧原デバッグブランチ、FlagGems の bump-flagtree-tsm ブランチ）はデフォルトブランチ基準では完全に列挙できない。学習側の Megatron-LM-FL と FlagScale はウィンドウ内の動作が疎であり、関連する判断の信頼度は推論スタックより低い。コンポーネント名はニュース側で継続的にゼロヒットであり、エコシステムの内容は主にメンバー単位と産業メディアから来ている。FlagOS 公式公告ではない部分は本文中で情報源の性質を标注済みである。

参考文献

g/0.7.1.dev1%2Bppu3.6>

n.net/> · https://hub.baai.ac.cn/ · https://hn.algolia.com/api · https://news.google.com/