調査期間：2026-10-22 06:00 ~ 2026-10-23 06:00（北京時間、24時間；金曜朝報、期間は前回デイリーレポートの区切りから継続）。

情報源：GitHub（org: flagos-ai 61リポジトリ全量核查、コミット検索135件、マージ済みPR 163件と審査中PR 183件の検索、orgイベントストリーム100件、31リポジトリのRelease/Tag原子核查、4リポジトリのAtomフォールバック）、Google News RSS（24組の中英語クエリ語、プロキシ経由）、HN Algolia（8組）、CSDN FlagOSコラム、智源コミュニティ、具身之家とPandaily原稿（詳細は付録の情報源リストを参照）。

本期インデックス

  • 今日の重点：マージ163件で直近1週間の新高値を記録；海光のvLLM 0.28とSGLang 0.5.18のデュアルスタックが同日マージ、FEP-0140とFEP-0141がそれぞれ第一枠を達成；FlagQuantumがM3中性原子を設計契約から実行可能なネイティブRydberg動力学へ押し上げ（10-22）
    1. オープンソースプロジェクトの進展（GitHub動向）
      • 1.1 組織のリズム：16リポジトリでプッシュ、135件のコミット、163件のマージ、キューは消化中、新規は収束中（10-22）
      • 1.2 vLLM 0.28とSGLang 0.5.18の海光線が同日マージ（10-22）
      • 1.3 FlagQuantum：53件のコミット、20件のマージ、ネイティブRydbergが契約からコードへ（10-22）
      • 1.4 FlagQuantum：デプロイ拒否、ベンダー退場と终端サンプリング提案（10-22）
      • 1.5 FlagGems：91件のマージ、KernelGen 39件のバッチ実装と昆仑芯13件の最適化が並行（10-22）
      • 1.6 FlagGemsテスト主線：lukatao 61件、夜通しで14件のバッチを開き「直連候補」に変更（10-22 ~ 10-23）
      • 1.7 build-infra：昆仑芯がFlagTree第七バックエンドに、flagcx 0.14.0を全バックエンドにピン留め（10-22）
      • 1.8 Torch-FL：清微がrocprofiler-sdkに接続、昆仑芯のクロスカードコピーをpeerプリミティブ経由に変更（10-22）
      • 1.9 FlagTree：AMD RDNAにprefillパスを補完、MUSAはコピーごとにTMEキャッシュ（10-22）
      • 1.10 その他のリポジトリ：FlagBLAS天数と摩尔線程GEMM、賽事通道2件、optestをwheelにパッケージ（10-22）
    1. ニュース報道とエコシステム
      • 2.1 Pandailyが英語で系統的にFlagOS 2.2を伝える：1454オペレータ、約27%のクロスチップ向上、KernelGen 765の新規オペレータ（10-22）
      • 2.2 跨維智能が衆智FlagOS加速計画の擬立項に選出：FlagOS-RoboとAlohaMiniの端側デモ（10-22）
      • 2.3 チャネル核查：17件の候補のうち2件が有効、CSDNに高校円卓ライブを追加、智源コミュニティはフレームページのみ取得（10-22）
    1. メンバー単位とバックエンドベンダーの深掘り
      • 3.1 海光：2つの推論プラグインリポジトリが同日に上流バージョン整合を完了（10-22）
      • 3.2 昆仑芯：13件のオペレータ最適化、FlagTree第七バックエンドを追加（10-22）
      • 3.3 清微：デバイスタイムラインがtorch.profilerに入り、TX8110で実測（10-22）
      • 3.4 摩尔線程と燧原：MUSAキャッシュ永続化、GEMMと燧原の一括更新（10-22）
      • 3.5 昇騰、天数、沐曦その他：バックエンド別に分流した小刻みな歩み、地平線と寒武紀は静穏（10-22）
    1. まとめとトレンド観察
  • 付録：情報源核查表と完全な情報源リスト

今日の重点：マージ163件で直近1週間の新高値；海光デュアルスタックが同日整合、量子スタックがM3を契約から実行可能へ（10-22）

日付：2026-10-22　出典：vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · FlagQuantum PR #700 · build-infra PR #1468（全量は付録を参照）

  • リズム面：61リポジトリ中16リポジトリで期間内にプッシュがあり、コミット検索135件、マージ済みPR 163件、レビュー中PR 183件が期間内に更新（うち新規作成90件）。前回（10-21：22リポジトリ、164件のコミット、151件のマージ、154件のレビュー中、64件の新規作成）と比較して、マージは8%増、レビュー中は19%増、新規作成は41%増、プッシュのあったリポジトリは27%減、コミットは18%減——キューは消化が進み、新規開発は収束しつつある。
  • バージョン面で初めての実現：海光のvLLM 0.28.0とSGLang 0.5.18という2つの上流バージョン適配が同じ日にマージされた。これは10-21にマージされたFEP-0140（vLLM三バージョンライン）とFEP-0141（SGLang 0.5.18 十社ベンダー）以降、初めて「FEPマトリクスに沿って一マスずつ着地」した実証例である。
  • 量子スタックが設計段階を通過：FlagQuantumは53件のコミット、20件のマージ。Core側のネイティブRydbergプログラム、Simulation側のplan 1.7ダイナミクス、Examples側の移動原子パルス訓練の3ブロックが同日にマージされた。昨日はまだ2つの設計契約であった中性原子路線が、今日はすでに実行可能なCPU経路と検収数字を持つに至っている。
  • ビルド側の第7バックエンド：build-infraが崑崙芯（XPU）をFlagTreeビルドラインと日常ビルド行に接続し、enflame、hcu、tsingmicro、mthreadsに次ぐ第7のバックエンドとなった。PRの自述は「現在の集合の最後の行」である。同日、flagcx 0.14.0をnvidia専属から全バックエンドの明示的依存に固定した。
  • テスト施設の同時改修：optestはスクリプト集合からインストール可能なwheelとconsole commandsに変わった。FlagGems側では一人で61件をマージし、そのうち23:40から23:47にかけて一気に10件のバッチPRを作成し、テストケースをラッパー関数からオペレータ直接呼び出しまたは候補注入に変更した。
  • ニュース側では本期間に2件の有効な稿：英語メディアPandailyが2.2を体系的に転述。国内ではFlagOS-Roboの政府加速計画プロジェクト認定事例が現れた。ソフトウェアスタック以外のこの2件は、本期間で唯一GitHub以外からの情報增量である。

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

1.1 組織リズム：16リポジトリでプッシュ、135件のコミット、163件のマージ、キューは消化、新規は収束（10-22）

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

  • リポジトリ面：61 リポジトリ中 16 リポジトリが調査期間内にプッシュがあり、コミット数順に FlagQuantum 53、FlagGems 29、build-infra 13、Torch-FL 12、FlagGems-sglang 8、FlagTree 5、FlagGems-vllm 4、FlagBLAS 3、optest 3、FlagTrain 2、FlagOps 2、FlagDNN 1。docs、release-info、sglang-plugin-FL、vllm-plugin-FL の 4 リポジトリのプッシュは非デフォルトブランチにあり、メインブランチには新規コミットなし。
  • マージ面：マージ PR 163 件、リポジトリ別に FlagGems 91、FlagQuantum 20、build-infra 13、Torch-FL 12、FlagTree 6、optest 4、vllm-plugin-FL 4、FlagGems-vllm 4、FlagGems-sglang 3、FlagTrain 2、FlagBLAS 2、FlagOps 1、sglang-plugin-FL 1。FlagGems と FlagQuantum で合計 68% を占める。
  • 審査中面：調査期間内に更新のあった open PR 183 件、うち新規開設 90 件。リポジトリ分布は FlagGems 86、FlagGems-vllm 18、Torch-FL 13、vllm-plugin-FL 12、FlagTree 11、FlagTrain 6、FlagGems-Experimental 6、sglang-plugin-FL 5。FlagGems-vllm と TransformerEngine-FL の新規增量はベンダー側の融合オペレータに集中している。
  • 生産面：lukatao は FlagGems で 61 件をマージ（同リポジトリの 67% を占める）、すべてテストと用例契約；FlagQuantum アカウントは 20 件をマージ；tengqm は build-infra 13 件を担当；lvyufeng は Torch-FL で 11 件をマージ；lvxu2020 は崑崙芯 XPU ラインで 6 件をマージ。
  • バージョン面：調査期間内に新規リリースなし。直近 3 つのタグは依然として FlagTree の 0.7.1.dev1 と 0.7.1.dev1+ppu3.6（10-20 20:11）および 0.7.1a1+ascend3.5（10-19 13:01）であり、いずれも従前の各期に帰属する。
  • イベント面：org イベントストリーム 100 件、うち PR イベント 43、プッシュ 27、ブランチ削除 12、ブランチ作成 9、コメント 4、レビュー 3、フォロー 2。ブランチ削除 12 は新規開設バッチ PR と同日に出現しており、「バッチブランチはマージ即削除」というパイプライン習慣を反映したもので、機能のロールバックではない。
  • 判断：マージ、審査中、新規開設の 3 項目が同時に上行する一方でコミットとプッシュのリポジトリが下行するのは、今四半期では珍しい組み合わせである。その意味は、レビューのスループットが前 2 日間の滞留（10-20 から 10-21 の合計約 300 件のマージ）を消化している一方で、開発者が当日新規に作成したコード量が縮小していることにある。このようなリズムは通常、マイルストーンの収束前後に現れる。

1.2 vLLM 0.28 と SGLang 0.5.18 の海光ラインが同日マージ（10-22）

日付：2026-10-22　情報源：vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · vllm-plugin-FL リポジトリ · sglang-plugin-FL リポジトリ

  • vLLM 側（#576、19 ファイル、+1436/−288）：海光 BW1000 のプラグインを vLLM 0.28.0 にアップグレードし、リリースパッケージ識別子は 0.28.0+empty、モジュールバージョンは 0.28.0、ソースベースラインは 2cf0a6915。検証環境は各カード 64 GiB、コンテナ内での通常の wheel インストール（編集可能インストールは不使用）、TP=2、最大モデル長 4096、最大シーケンス数 8、VRAM 使用率 0.85 で、eager と FULL_AND_PIECEWISE の 2 つのグラフモードをそれぞれ実行。通信はベンダーの HIP/RCCL 経由で、FLAGCX_PATH は未設定。
  • バージョンパズル：PyTorch はベンダーの 2.10.0（+das.opt1.dtk2604、DTK 26.04 を保持）、FlagTree は 0.6.0+hcu3.6（wheel SHA256 プレフィックス 0fd81f0e）、Triton リリース版は 3.6.0+gitc73250c4.staging で、ベンダーの Triton と共存。ランタイムイメージは vllm-plugin-fl:v0.28.0-hygon-ci。
  • 比較可能精度：リポジトリはインストール済みの 1,944 個の FlagGems ソースファイルとパッケージファイルを 1 ファイルずつ比較し、すべて e12a220 というコミットに一致（CRLF/LF の行末差分のみ）。ただしインストールメタデータ内のバージョンは依然として 0.1.0——つまりバージョン番号は信頼できず、内容は照合可能であり、この「VCS メタデータの代わりに内容を用いる」フォレンジック手法はここ数期に繰り返し登場している。
  • SGLang 側（#138、65 ファイル、+4940/−369）：海光 BW1000 の empty バックエンドを SGLang 0.5.18（tag ソース 71de97b、さらに HCU 専用の Quark インポートパッチを追加）にアップグレードし、attention、FLA、MoE インターフェースに適合させ、パイプライン並列下の協調終了問題を修正。検証にはシングルノード TP2 の eager と全デコードグラフ、および物理 2 ノードの TP4/PP1 と TP2/PP2 の eager ケースを含む。パイプラインゲートでは BF16、コンテキスト 4096、最大並行数 16、VRAM 比率 0.70 を使用。
  • バージョンパズル：FlagTree 0.6.1+hcu3.6（Triton は FlagTree が提供し、独立した Triton は別途インストールしない）、FlagGems 5.4.0.dev0、ネイティブ FlagCX 0.13.0、ベンダーの sglang-kernel 0.4.2.post2、flash-attn 2.8.3。CI イメージ sglang-plugin-fl:0.5.18-hygon-ci-20261015 は sha256 で固定。
  • 判断：両 PR はいずれも「empty ランタイム + ベンダースタック」路線を採り、受け入れ対象を具体的なバージョン番号と具体的なグラフモードとして記述しており、「適合済み」のような曖昧な表現は用いていない。FEP-0140 によれば、vLLM 0.28 は 11 月のメジャーリリースバージョンであり、目標は 10 社のベンダー。FEP-0141 によれば、SGLang 0.5.18 は 10 社のベンダーをカバーし、ノードは 12 月中旬まで。海光は最初に点灯したマス目であり、残り 9 社がすでに整ったことを意味しない。今後の観察ポイントは、同じ 0.28.0 バージョンが清微、沐曦、燧原、崑崙芯上で同じインストールパスを再利用するかどうかである。

1.3 FlagQuantum：53 件のコミット、20 件のマージ、ネイティブ Rydberg が契約からコードへ（10-22）

日付：2026-10-22　情報源：FlagQuantum コミット · PR #700 · PR #707 · PR #714

  • 総量：53 件のコミット、20 件のマージ。コミットは組織全体の 40% を占め、マージ数は第 2 位。前回（84 件のコミット、34 件のマージ）と比べて規模は半減したが、性質が変わった。前回は動的回路の Program IR と図出力の補完チェーンであったのに対し、今回は中性原子物理がドキュメントから実行へと落ちてきた。
  • Core フロントエンド（#700、22 ファイル、+2198/−16）：ネイティブ Rydberg 制御はもはや回路アダプタを借用せず、Core が ProgramRecord 上で直接フロントエンドを提供する。レコードには型付きの context と control フィールドが追加され、既存のバリデータは単一の物理 profile のみを受け入れ、CFG/SSA 検査を再利用する。連続パスの安全性は符号化座標上の厳密な算術で判定され、数値解法と分離されている。ソース符号化は既存のスカラーコーデックを再利用し、ネイティブ専用の厳密なフィールドと規範検査は、あらゆるテンソルデコードの前に不正入力を拒否する。新しい IR 階層、バインダ、ソルバ、レジストリ、ルートエクスポートは導入されていない。
  • ユーザー API：RydbergProgram は原子、サイト、長さと時間の単位、C6、損失率、最小間隔、輸送チャネルと駆動チャネルで構築され、move、pulse、to_ir の 3 つのアクションを提供する。サンプル出力は原子識別子 ('a','b')、次元 (3,3)、制御位置 (3.0,0.0)、生存オペレータ形状 (9,9)。PR には「制御位置は物理的存在を表さない」と明記されている。
  • Simulation（#707、19 ファイル、+1488/−188）：ネイティブ Rydberg プログラムは既存の Lindblad 計画、実行、初期密度随伴の入口を利用でき、ユーザーが原子、線形輸送、パルス、吸収損失を宣言すると、Simulation が区間行列を自ら組み立てる。plan 1.7 はちょうど 7 つの外層フィールドで密封され、実行時にソースを再コンパイルしない。実験的な数値パスは CPU-only で、1〜2 個の g/r/lost ロールを持ち、より大規模なものは指数的なメモリ割り当ての前に拒否される。幾何は線形パスを適用した区間中点近似であり、グリッド収束の証拠とソルバ精度は別々に記録される。
  • Examples（#714、3 ファイル、+217）：2 つのパルス振幅バインディングを訓練し、原子対を移動させる。40 ステップ、128 区間の実測出力は次のとおり：無条件 RR は 0.0431 から 0.1228 へ上昇、生存条件 RR 0.1500、no-flag 選択 RR 0.1439、厳密数値リプレイは成立。ローカルのデフォルト全量は 14,584 通過、167 スキップ、約 518 秒。初回の 64 区間では 2.28e-10 で 1 つの勾配が失敗し、128 区間へ細分化した後に通過し、ソルバとアサーションは変更されていない。
  • 判断：1 日のうちに、量子スタックは「原子とパルスを宣言できる」から「動力学を計算できる」、さらに「制御パラメータを訓練できる」へと 3 段階をつなぎ、しかも各段階で能力の境界を明記している（サンプリングイベント、フィードバック、加熱、量子運動、GPU や分散を主張せず、M3 の完了も主張しない）。これは今シーズンで最も情報量の多い単一リポジトリの推進方法である。まず契約を拒否可能な実装として書き、その後でブロックごとに開放していく。

1.4 FlagQuantum：デプロイ拒否、ベンダー退場、終端サンプリング提案（10-22）

日付：2026-10-22　情報源：PR #701 · PR #705 · PR #716 · PR #720

  • デプロイ側拒否（#701、3ファイル、+78/−1）：原生物理プログラムはデジタル回路ではなく、パッケージビルダーが従来 ProgramRecord から回路メタデータを読み取ると AttributeError をスローし、Pauli パッケージビルダーは方向のない TypeError をスローしていた。現在、両方のエントリポイントはバックエンド選択、コンパイル、発射の前に Core の拒否ロジックに委ねられ、統一して CapabilityError をスローし、「原生 Rydberg タイムラインは回路として実行できません。flagquantum.lindblad を使用してください」と通知する。4つの新しい回帰は修正前にすべて失敗し、修正後は3つの Python バージョンそれぞれで39のテストが通過した。
  • ベンダー退場（#705、17ファイル、+159/−621）：汎用 NeutralAtomProvider には対応する外部サービスやタスクプロトコルが存在せず、ローカルジオメトリを解析するだけで常にコミットを拒否していた。提案 082 に従い、このモジュールと2つの Remote 名前空間のエクスポートを直接削除し、エイリアスも空のシェルアダプタも残さない。Core のジオメトリ、RydbergProgram、および旧計画/ソースファームウェアは変更しない。
  • 終端サンプリング提案（#716、4ファイル、+379）：#707 に続き提案 083 を提出し、Runtime の sample_terminal プリミティブを定義する——順序付けられた全空間テンソル Kraus 分岐を消費し、SuperOperator、既存の密度検証、現在の MeasurementResult、Core テンソルエンコーディング、Torch 乱数源を再利用する。例では存在性ラベル ('no_flag','flag') と確率 0.68/0.32、Fock 数ラベル 0/1/2 と確率 0.6/0.3/0.1 を示し、末尾に「Framework terminal instrument API: proposed, not implemented」と明記して出力する。PR 本文には提案 083 が未承認・未実装であることを明記する。
  • その他の支線：#710 カスタムオペレータ登録時に Circuit メソッドを同期インストールする；#711 Circuit 随伴で非ユニタリ行列を拒否する；#712 極小の非ゼロゲートを正確に保持する（しきい値でゼロに折り畳まない）；#713 動的回路昇格準備状況監査；#720 測定容量のランクに伴う変化と表現整合性区間；#721 制御命令にオペランドを自带させる；#722 注入クロック下でエンジン順序を較正し、偶発的失敗を解消する。
  • 判断：今期の量子スタックの合入量の半分は「拒否」と「削除」に費やされた——物理プログラムを回路としてパッケージングすることを拒否し、外部サービスのないベンダーを削除し、未承認のサンプリングインターフェースを凍結する。こうした動作は能力を増加させないが、後続の M3 の境界が信頼できるかどうかを決定する。

1.5 FlagGems：91件の合入、KernelGen 39件のバッチ展開と昆仑芯 13件の最適化が並行（10-22）

日付：2026-10-22　情報源：FlagGems コミット · PR #7077 · PR #7107 · PR #7424

  • 総量：29 件のコミット、91 件のマージ。全組織のマージの 56% を占める。全組織 163 件のマージをタイトルキーワードで集計（重複可）すると：テスト系 47、KernelGen 39、昆仑芯 13、昇腾または NPU 9、海光または DCU 7、燧原または GCU 5、摩尔線程または MUSA 5、CI 4、沐曦 3。このうち FlagGems リポジトリ内に該当するのは昆仑芯 10 件、昇腾 7 件、摩尔線程 4 件、燧原 2 件、海光 2 件。
  • KernelGen のバッチ反映：14 個の Nvidia オペレータが 3 バッチに分けてマージされた。バッチ内のタイムスタンプ密度から、個別レビューではなく審核通過後のまとめてマージであることが分かる。
  • 10:43 バッチ：_copy_from_and_resize、ger、sparse_bsc_tensor；
    _nested_tensor_from_tensor_list。
  • 15:23 バッチ：_values_copy、_fw_primal_copy、_shape_as_tensor；
    _nested_tensor_storage_offsets、_convert_indices_from_csr_to_coo。
  • 22:23 バッチ：swapdims、_nnz、moveaxis、_dimI と view_as_complex_copy。
  • 燧原の一括（#7077、26 ファイル、+3520/−511）：ベンダー 10-13 の一括更新が一度に主干へ入った。タイトルは「update from enflame 20261013」のみ、PR 本文も Operator と「欠陥修復と性能最適化」の注記のみで、項目ごとの明細はない。これは直近 1 週間で単一コミットのコード量が最大級のベンダー側変更の一つである。
  • 昆仑芯の融合 MoE（#7107、13 ファイル、+496/−123）：XPU3 の fused_experts_impl、inplace_fused_experts、outplace_fused_experts の 3 オペレータと dispatch_fused_moe_kernel を補完。前半 3 つの集約スコアはそれぞれ 1.327、1.329、1.324（bf16 平均 1.346 から 1.351、fp16 平均 1.302 から 1.306）。PR は積極的に 2 点の留保を明記している。第一に、公式契約のベースラインは vLLM 自身の fused_experts_impl であり、このベースラインは XPU スタック上でビルドできないため、昆芯は代替の非契約ベースライン（エキスパートごとの index_select と matmul）とのみ比較しており、3 つの数値は「融合が非融合に勝る」としか読めない。第二に、dispatch_fused_moe_kernel の集約 0.626 は 0.8 の閾値を下回るため、達成を主張していない。
  • CI の 3 件：#7424 は flagcx を無効化して cuda12 の依存エラーを修正（nvidia133 バックエンドで mm_w8a8_fp8 が失敗）；#7500 は環境変数の位置エラーを修正；#7420 は robust-checkout のタイムアウトを 60 秒に延長。
  • 判断：91 件のうち実際にオペレータ能力を増やしたものは 2 割未満で、主体は自動化産出（39 件）とテスト契約（47 件）の 2 種類である。昆仑芯の路線はすでに「ベンチマーク集約スコアで項目ごとに詰める」段階に入っており、さらにベースラインの比較可能性の瑕疵を積極的に注記し始めた——これは数値そのものより記録に値する。

1.6 FlagGems テスト主線：lukatao 61 件、夜通しで 14 件のバッチを開き「直結候補」に変更（10-22 ~ 10-23）

日付：2026-10-22 ~ 2026-10-23　情報源：PR #7543 · PR #7552 · PR #7556 · optest リポジトリ

  • 規模：lukatao 一人で 61 件をマージし、FlagGems 当日の 67%、全組織の 37% を占めた。うち 56 件のタイトルはテスト、修正、検証、同期の類であり、新規オペレータの追加は一件もなかった。
  • バッチ起票：10-22 23:40 から 23:47 までの七分間に 10 件の PR を起票——foreach オーバーライド「直連ルーティング」バッチ 01 から 09（#7543 から #7551）に加え #7552「最後の九つのオペレータスイートを公共候補 API 経由に変更」。この一連の変更は、テストケースを use_gems() ラッパーから直接 flag_gems.* を呼び出すか候補実装を注入する形に変え、「どの実装をテストするか」を暗黙から明示へと変えるものだ。
  • 連夜のマージ：調査期間末の四件の疎スイート移植が未明に連続して着地——#7553（01:00、疎 log-softmax のクロスバックエンド可搬性）、#7554（02:51、疎バリデータファームウェアと直接ベンチマーク候補呼び出し）、#7555（04:38、圧縮疎バリデータ）、#7556（05:47、公共疎ブロックコンストラクタ）。最後の二件は本レポートの締め切り時点から三十分未満である。
  • バックエンドスキップのガバナンス：昇騰と摩尔線程のスキップは一件ごとに理由を明記し入力域を限定した（#7483 linalg_vander 複素数入力、#7485 logdet 複素数、#7492 row_stack_out メモリフォーマット、#7496 trapz complex32、#7502 orgqr MUSA ゼロ列、#7503 と #7504 MUSA qint32、#7505 Hygon cuDNN 検証）。海光側では #7460 が FP8 疎総和逆方向の入力ファームウェアを修正した。
  • 判断：このラインは対外的な能力を一切生み出さないが、FlagOS のマルチバックエンド信頼性の基盤である——同一の PyTorch テストケースが十数種のバックエンド上で説明可能な合格またはスキップを与える必要があり、それぞれが改変済みのテストを維持するのではない。optest も同日、ツールチェーンをインストール可能な wheel にまとめ（#4）、src レイアウトに変更し（#5）、console commands を公開した（#6）。これは FlagGems のテストケース改造と同じ事柄の両端である。

1.7 build-infra：昆仑芯が FlagTree の第七バックエンドに、flagcx 0.14.0 を全バックエンドに固定（10-22）

日付：2026-10-22　情報源：PR #1468 · PR #1471 · PR #1459 · PR #1462

  • 総量：13 件のコミット、13 件のマージ、すべて tengqm が完了。当期のプラットフォーム面で最も集中したリポジトリ。
  • 第七バックエンド（#1468、3 ファイル、+428/−9）：packaging/flagtree/kunlunxin は最近のバックエンドと同形の二段式 Containerfile を採用——--target builder はリリース可能なビルド環境（素の ubuntu 22.04 に apt ツールチェーンを加え、事前ビルド入力は FlagTree オフラインキャッシュにステージング）、最終段でその上に wheel をビルドする。昆仑芯には五つの独自制約がある：第一に、十個の事前ビルド入力がありキャッシュはディレクトリ名でマッチングされ、二つの LLVM 19 パッケージは tarball ルート xtdk-llvm19-ubuntu2004_x86_64 を共有し、xtdk-llvm19 と xtdk-llvm19-printf として展開されるため、filestore 名にバージョン接尾辞が付き、triton ツールパッケージのみ .triton/ をルートとするため --strip-components が必要；第二に、フロントエンドは環境変数で選択され、LLVM_SYSPATH は未設定のまま維持する必要があり、公共 LLVM が検証済みブランチ、XTDK がフォールバック；第三に、pybind11 は正確に 3.0.1 に固定、3.0.4 は internals の構築を変更しディスパッチャが SIGSEGV を起こす；第四に、apt の patchelf は使わず、PATH または公共 LLVM パッケージ付属のコピーから解決し、ベンダー CI と同じパス；第五に、TRITON_APPEND_CMAKE_ARGS=-DCMAKE_BUILD_TYPE=Release を追加しない。昆芯がリリースするベンダー wheel 自体が rel-with-asserts であり、外部コンパイラにとって最適化レベルはパッケージの詳細ではないからである。
  • 通信依存（#1471、3 ファイル、+60/−4）：flagcx==0.14.0 はこれまで nvidia-cuda12.8 と nvidia-cuda13.3 の二行にのみ pin があり、残り十八個のバックエンドは依然として triton/_C から解決していた。今回、残り十八個のバックエンドに正確な pin を追加し、タグはバックエンドキーから導出せずベンダーインデックスが実際に提供する値を採用（hygon-dtk26.04 がリリースするのは +dtk2604）；spacemit と thead-ppu2.0.0 は pin しない。両者のインデックスに flagcx wheel が存在しないためである。同一 PR でついでに、これにより古くなった二箇所のドキュメント記述を修正した。
  • ドキュメント線：vllm-plugin-FL、FlagTree、FlagCX、FlagGems、FlagLibs、Megatron、SGLang、verl 八個のコンポーネントの設計記録とサイトページが 12:50 から 17:42 の間に連続してマージされた（#1462 から #1470）。今季初めて「ビルド設計」を検索可能なサイトコンテンツとして書き記したものである。
  • その他：#1459 は古くなったベンダープレフィックス hygon の wheel 行を削除；#1461 は呼び出し側が manifest ダウンロードモードを絞り込めるようにした。
  • 判断：ビルダーは六バックエンドから七バックエンドに拡張され、同日に通信ライブラリを「二社の nvidia 行の特例」から全バックエンドの明示的依存に変更した。後者がより実質的な変化である：バックエンドを切り替えた際に通信層が同じインストールとシンボル解決のパスを辿るかどうかを決めるからである。

1.8 Torch-FL：清微が rocprofiler-sdk に接続、昆仑芯のクロスカードコピーが peer プリミティブ経由に変更（10-22）

日付：2026-10-22　情報源：PR #630 · PR #634 · PR #632 · PR #629

  • 総量：12 件のコミット、12 件のマージ。MPS、昆仑芯、昇騰/海光/沐曦/PPU、GCU、清微の6プラットフォームに跨る。
  • 清微デバイスプロファイリング（#630、15ファイル、+1383/−39）：清微上ではこれまで torch.profiler が CPU アクティビティしか出力しなかった——プラットフォームが unavailable スタブにルーティングされ、PrivateUse1 にデバイスプロファイラが登録されておらず、kernel イベントも CPU から kernel への矢印もなく、self_device_time_total は常に 0 だった。本 PR は rocprofiler-sdk ベースの DeviceTracer と独立プロファイリングツール libtorch_fl_profiler.so を追加し、各 NPU kernel をそれを起動した aten op に関連付け、CUDA trace の CPU/device レイアウトに従ってレンダリングする。同時に TX8110 上で実測し、清微に FLAGOS_BUILD_VENDOR=ON を固定（ベンダーディレクトリに置かれているのは乱数カーネル）、インストールとプロファイリングのドキュメントを補完した。プロファイリングを要求しない場合の動作は変わらない。
  • 昆仑芯クロスカードコピー（#634、3ファイル、+55）：CrossDeviceMemcpy が呼び出していたのは同一カードセマンティクスの xpu_memcpy（XPU_DEVICE_TO_DEVICE 型）であり、2枚のカード上のポインタを渡すと −801 を返しターゲットは書き込まれず、任意の flagos:N → flagos:M 転送がサイレントに無効化されていた。SDK の peer プリミティブ xpu_memcpy_peer に切り替えた。問題は P800 上の最後の bert 失敗で判明し、同期呼び出しでも隠蔽されないことから、タイミング問題ではなくバイトが一度も書き込まれていなかったことを示す。
  • プリロード順序（#632）：liblaunch_shared.so が undefined symbol: cudaMemcpy を報告。このシンボルは /usr/local/xcudart/lib/libcudart.so.12 ではバージョン付き定義であり、Triton ランチャーの dlopen 後にのみ解決可能なため、昆芯の CUDA 互換ランタイムを前倒しでロードするようにした。
  • その他：#629 で cuda/dcu/metax/ppu に convolution_overrideable の例外を追加；#626 で Qwen3.5 のメタデータビューを MPS に留める；#635 で FlagGems 主導の CUDA ビルドにおいて型変換をデバイス上で行う；#631 で MPS テストを Apple runner に残す；#618 で GCU の capability AssertionError に一時的な診断説明を追加。
  • 判断：当日の主線は性能ではなく、2つの基本能力の可用性——可観測性（清微が初めてデバイスタイムラインを見られるようになった）とマルチカードの正確性（昆仑芯のクロスカードコピーはこれまでずっと誤っていた）である。この種の修正はどのベンチマーク表にも現れないが、上位層のすべてのマルチカード実験の結論を再計算させることになる。

1.9 FlagTree：AMD RDNA に prefill 経路を追加、MUSA はコピーごとに TME キャッシュ（10-22）

日付：2026-10-22　情報源：PR #1365 · PR #1385 · PR #1278 · PR #1415

  • AMD prefill（#1365、66 ファイル、+3163/−260）：#1364 の M=1 デコード経路の上に M>1 のプレフィル実行を追加した。密な Qwen3 インポータのプレフィルモード、M>1 レンダリングコード生成（WMMA lm_head を含む）、融合 matmul と RMS-norm-stats カーネルおよび gather-reduce 正規化の締めくくり、プレフィルトークンごとの KV 書き込みを独立したキャッシュスロットに格納すること、さらに「プレフィルは最後のトークンの logits のみを出力する」——すなわち lm_head より前の位置のみを切り出し、全位置を実体化しない。RDNA のプレフィル WMMA GEMM マイクロカーネルは GEMV ループと比較して M>1 のとき 10～30 倍高速化し、M に応じて自動選択される。デコード側の split-K は lm_head を 17.0 から 14.9 ms/token に、層ごとのワイド投影を 14.9 から 10.5 ms/token に短縮した。W7900（gfx1100）と R9700（gfx1201）で新規コンパイル後のプレフィルは有限であり、argmax=241 は torch リファレンスと一致（最大誤差は約 0.5、bf16 のほぼ並列に属する）、デコードの next_token=25 は変わらない。
  • 残り五件：#1278 は outlined helper をまたぐ呼び出しのフェンス位置ずれを修正。#1385 は MUSA にコピーごとの TME キャッシュ永続化を追加。#1424 は偶発的なバスエラーにより燧原 CI で 02-sparse-mla テストケースを無効化。#1415 は minimax_m3 index_topk の block_size_k を修正。#1427（10-23 00:06）は燧原 vllm benchmark のパラメータを更新。
  • 判断：AMD 路線は「シングルカードでデコード可能」から「シングルカードでプレフィル可能」へと前進し、性能数値はコミットごとの計測基準（17.0→14.9→10.5 ms/token）でありモデル全体の比較ではないため、検証可能性は比較的良好である。この路線は依然として Qwen3 の稠密モデルのみを唯一の検証対象としており、MoE と長コンテキストは未カバーである。

1.10 その他のリポジトリ：FlagBLAS の天数と摩尔線程 GEMM、大会チャネル二件、optest の wheel 化（10-22）

日付：2026-10-22　情報源：FlagBLAS PR #153 · FlagGems-sglang PR #205 · FlagGems-vllm PR #977 · optest PR #4

  • FlagBLAS（2 件）：#153 天数（Iluvatar）L1 層オペレータの最適化；#152 摩尔線程の GEMM 実装追加。いずれの PR もベンダー側からのコミットで、クロスリポジトリの変更はない。
  • FlagGems-sglang（3 件）：#205 で AMD RDNA3 アーキテクチャ層（_amd/rdna3/ops/）に fused_moe_gemm、fused_moe_router_tensorcore、fused_moe_router_cudacore の gfx1100 バージョンを追加し、W7900D 上でチューニング、3 ファイル +1310；WMMA カーネルは K ブロックごとに fp32 で単一ドット積を累積する。K ブロックをまたいで WMMA アキュムレータを使うと gfx1100 で精度が落ちるためである。残り 2 件は FlagOS コンテスト Track1 の成果物：#204 fused_pack_qkv、#201 fused_sigmoid_mul で、いずれも Triton カーネルであり、コンテストの成果物が提出物止まりでなく主干に入り始めたことを示す。
  • FlagGems-vllm（4 件）：#977 で沐曦融合 MoE に TP=2 構成を追加（Qwen3.6-35B-A3B の w1=(256,512,2048)、w2=(256,2048,256)）、C550 上で 14 個の M 値で平均 1.065 倍高速化し、M≥4096 時に 98304 バイトの共有メモリ構成が選ばれて OutOfResources になる問題も修正；同時に vLLM の out、workspace13、workspace2 を受け入れて出力全体のコピーを回避。#936 で昇騰のチャンクゲート付きデルタルール順伝播（chunk gated delta rule）を tle.dsa のスライス・同期インターフェースに変更；#929 で KMCompiler により qwen_qsa_prepare を追加；#777 で Hopper 上の可変長 flash attention を補完。
  • FlagTrain（2 件）：#16 で multi_tensor_lion を追加（Nvidia、Hygon、Metax、Thead の 4 バックエンド、KMCompiler プレフィックス）；#26 で quick_gelu を追加。
  • optest（4 件）：#4 でツールをインストール可能な wheel にパッケージ化、#5 で src レイアウトに変更、#6 でインストール済みツールを console commands として公開、#2 で CI ジョブ名を <repo> (<backend>) と表示。
  • 審査中で注目すべきもの：flir #83 で TensorView 方言と tile.load / tile.store ビューを追加（CommonIR 方向の実質的な動き）；verl-FL #22 で壁仞 SUPA プラットフォーム対応を追加；FlagOS-Compressor #13 で CLI にマルチデバイス MSE 量子化と BF16 変換を追加；sglang-plugin-FL #149 で 23:36 に海光 eager Qwen3.6 MTP デコードを新規オープン；TransformerEngine-FL #144 から #146 の 3 件が同日に NPU を指向（get_num_cublas_streams、cuDNN バージョン機能クエリ、bshd/thd レイアウト）。
  • 判断：これらのリポジトリはいずれも「インターフェース追加」段階にある——flir は IR 方言を追加、verl はハードウェアバックエンドを追加、圧縮器は CLI を追加、コンパイラオペレータは 4 バックエンドへ展開。まだモデル受け入れの本線には入っていないが、flir と圧縮器の動きは 2.3 サイクルにおいて FlagTree と新モデル導入の境界を直接左右する。

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

2.1 Pandaily が英語で FlagOS 2.2 を体系的に伝える：1454 オペレータ、クロスチップで約 27% 向上、KernelGen で 765 個の新規オペレータ（10-22）

日付：2026-10-22　情報源：Pandaily 報道 · FlagOS ドキュメント

  • 事実の骨格：2.2 は 9 月 30 日にリリースされ、10 月 17 日に 2026 人工知能オープンコンピューティング大会で展示された。9 つのオペレータライブラリの合計は 1,454 個のオペレータで、FlagGems および関連ライブラリの公開オペレータは 564 から 1,454 に増加（890 個新增）。新增の FlagGems-SGLang ライブラリは 40 個のマルチチップオペレータを含み、attention、Mamba 状態更新、MoE、LoRA、サンプリングと量子化をカバーする。10 種類の AI ハードウェア、数千のオペレータで全体として約 27% 向上した。
  • 自動化の口径（本期新增の詳細）：KernelGen はすでに 9 種類の AI チップをサポートし、今四半期に 765 個の新規オペレータを生成した。そのうち 416 個は少なくとも 5 種類の国産チップで精度検査に合格し、ネイティブオペレータの 80% 以上の性能に達した。FlagPrism は Triton ソース、コンパイラ IR、デバイス実行データを打通し、昇騰、天数、摩尔線程、NVIDIA、燧原をサポートする。
  • 圧縮とデプロイ：FlagOS-Compressor は W8A8 で Qwen3.5-397B-A17B を処理し、モデルファイルは 751.41 GB から 382.45 GB に減少（−49.1%）、GPQA-Diamond スコアは 84.85% となった。vLLM、Megatron-LM、SGLang などのフレームワークプラグインと組み合わせることで、新モデルはリリース後 1 日以内に最大 12 のチッププラットフォームに適配できる。
  • 既存算力のケース：昇騰 910B 上の GLM-5.3-Flash の論理サービススループットは 8.52k から 17.36k tokens/s に向上（2.04 倍）。中国電信 Xing4.0-29B-A4B は 10 のチッププラットフォームに適配し、長入力テストの初回トークン遅延はネイティブオペレータ比で 19.87% 低下した（この数字は公開報道で初めて登場した）。
  • 限界：BAAI 自述の問題はタイミングにある——既にデプロイされた算力のうち 80% 以上は最新世代ではなく、モデルの世代交代は速い。文中のすべての数字は BAAI の自己測定によるもので、実際のサービス性能はなお負荷に依存する。
  • 判断：これは 2.2 の初の英文による体系的転述であり、口径は国内稿と一致しており、実質的な新增は 19.87% という遅延数字と KernelGen の四半期産出量のみである。海外読者にとっての意義はコミュニティへの情報增量よりも大きい：それは 2.2 を中国語技術圏の一回の発表会から、外部から引用可能な英文資料へと変えた。以前の 10-20 の報道はすでに 2.2 の收益を検証可能なケースに分解しており、本条では数字の対照を繰り返さない。

2.2 跨維智能が衆智 FlagOS 加速計画の擬立項に選定：FlagOS-Robo と AlohaMini の端側デモ（10-22）

日付：2026-10-22　情報源：具身之家報道 · FlagOS-Robo ドキュメント入口

  • 立項の事実：9 月、北京市科学技術委員会、中関村科技園区管理委員会は 2026 年度「中央引導地方」および「新世代情報通信技術革新」専項衆智 FlagOS 加速計画方向の擬立項課題公示通知を発表した。跨維智能傘下の跨維智心（北京）機器人科技有限公司が申請した《FlagOS-Robo に基づく AlohaMini 具身智能ロボット端側デプロイと応用示範》が公示リストに選定された。
  • プロジェクト内容：具身智能ロボットのオープンソースアルゴリズム再現、実機デプロイ、国産 AI チップの端側適配とシーン応用検証に向け、AlohaMini オープンソースロボットと FlagOS-Robo ツールチェーンを依托し、モデル訓練適配、マルチチップ推論デプロイ、スローファストシステム一体運用とマルチシーン示範を行い、目標は再現可能、デプロイ可能、評価可能、普及可能なオープンソース方案を形成することである。
  • 検収点：モデル側では具身モデル訓練適配と推論デプロイを行い、国産 AI チップのロボット端側応用を推進し、マルチチップ推論精度一致性テストでチップ間性能を検証する。システム側では具身モデル、運動制御小脳と本体制御の協調を推進し、理解、計画と実行を接続する。シーン側ではマルチシーン実体評価体系を構築する。
  • 前情：跨維智能は 2.2 のエコシステム口径で既に新增パートナーの一つであり、10-13 予告の具身智能分科フォーラム名簿にも登場している。本条の違いは「政府専項—オープンソースツールチェーン—オープンソース本体—評価体系」の四件セットの立項であり、フォーラムでの登場ではない点にある。
  • 判断：加速計画は FlagOS-Robo と国産チップ端側を同一の任務書に入れたことで、具身智能方向に外部検収者を設けたに等しい。コミュニティにとってこれは交付物制約を伴う三番目の外部プロジェクトである（前二つは FEP マトリクスと賽事）。今後、公開されたチップ型番と精度一致性結果があるかどうかを追跡する価値がある。

2.3 チャネル核查：17 条の候補中 2 条が有効、CSDN は高校円卓ライブ配信を新增、智源コミュニティはフレームページのみ取得（10-22）

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

  • クエリ面：24組の中英クエリ語。コンポーネント名（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen）は14日間、メンバーと産業語（智源研究院オープンソース、智源研究院チップ、国産演算力オープンソースソフトウェアスタック、燧原、沐曦、摩尔線程、清微、海光など）は7日間とし、調査期間内で合計17件がヒットした。
  • 有効2件：Pandailyの2.2英語転述と具身之家のFlagOS-Robo立案稿（2.1、2.2参照）。残り15件は相場、資金調達、人材稿で、燧原と清微の個別株ページと科創先鋒事例、輝羲智能の資金調達、摩尔線程の「公開価格割れ」と国産演算力業績稿、智源コミュニティが転載した黄仁勲演算力クラスタ稿を含み、コンポーネント、バージョン、チップ適配に関わるものは1件もなかった。
  • チャネル検証：HN Algoliaの8組クエリでFlagOSが4件、FlagGemsが2件ヒットしたが、タイトルに直接一致するものはなかった。CSDNコラムトップページの51リンクのうち、最新のオリジナル稿は依然として08-28のGLM-5.3-Flash Day0適配稿だが、新たに10-22 19:00の高校座談会ライブ（「共築開放AI教育生態」、10-22 14:24作成）が追加された。内容はFlagOSグローバルAIオープンコンピューティング教員発展計画の下で多国高校教員の教学実装であり、コミュニティ活動であって技術リリースではない。智源コミュニティ検索ページはクライアントレンダリングのため、フレームページのみ取得できた。
  • ギャップ説明：本期間のニュース側は2件の外部稿に支えられ、うち1件は旧リリースの英語転述であるため、「技術口径」は依然としてすべてGitHub由来である。収集規律に従えば、これは「ニュース側に頼らず平静を判断しない」という要件を満たしているが、これをもって対外発信のペースが加速していると見なすべきではない。

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

3.1 海光：2つの推論プラグインリポジトリが同日に上流バージョン整合を完了（10-22）

日付：2026-10-22　情報源：vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · FlagGems PR #7460 · FlagDNNコミット

  • デュアルスタック：vLLM 0.28.0とSGLang 0.5.18が同日にマージされ、合計84ファイル、純増約5,700行で、当日のコード量最大のベンダー側投入である。いずれもphysics31415926がコミットし、検証環境は同じく1カード64 GiBのBW1000クラスタ。
  • vLLM側の要点：配布パッケージは0.28.0+emptyで、ModelRunnerFLを使用しV2 model runnerを無効化。グラフモードはeagerとFULL_AND_PIECEWISEをカバー。プラグインwheelはCIがPR merge refに基づき再構築し、イメージ内の旧品を置換。
  • SGLang側の要点：単機TP2のほか、物理2ノードのTP4/PP1とTP2/PP2を実行し、パイプライン並列の協調終了を修正。FlagGems 5.4.0.dev0とFlagCX 0.13.0をベースラインとし、独立Tritonは導入していない。
  • その他：FlagGems #7460は海光FP8スパースサム逆伝播の入力ファームウェアを修正。FlagDNNに1件の「fix for hygon」。build-infra #1459は古いベンダープレフィックスhygonのwheel行を削除（パッケージングが統一命名に収束したことを示す）。
  • 判断：海光は当期唯一、2つの推論プラグインリポジトリで同時に上流バージョン整合を完了したベンダーであり、作業量は「バージョンマトリクス＋グラフモード＋マルチマシン並列」に集中しており、オペレータ数ではない。その再利用価値は、emptyバックエンドのアップグレードフローをバージョン表付きテンプレートとして書き出した点にあり、他のベンダーはこれに倣って推進すればよい。

3.2 昆仑芯：13件のオペレータ最適化にFlagTree第7バックエンドを追加（10-22）

日付：2026-10-22　情報源：FlagGems PR #7107 · FlagGems PR #7462 · build-infra PR #1468 · Torch-FL PR #634

  • マージ量：タイトルに昆仑芯または XPU を含むマージは全組織で 13 件（FlagGems 10、Torch-FL 2、build-infra 1）で、ベンダー中最も多いオペレータ側の成果であり、うち lvxu2020 一人で 6 件、すべて XPU カーネルを指向している。
  • オペレータ最適化：#7463 は elu、special_i1e、foreach_erf、foreach_zero を最適化；#7462 は tile、dot、index_put を最適化；#7452 は融合カーネルで isfinite を最適化；#7470 は kl_div の XPU 上書きを追加し、さらに isfinite を再最適化；#7351 は less_equal のテンソル比較に適応型 tile 高速パスを追加；#7406 は te_rmsnorm_fwd の非マスク行カーネルの列ループを展開；#7390 は isneginf、nan_to_num_、log_sigmoid_backward を最適化；#7466 はチューニング設定の tile を拡大して baddbmm の起動タイムアウトを修正。
  • 融合 MoE：#7107 は三オペレータの集約スコアを 1.324 から 1.329 へ引き上げたが、同時にベースラインが代替実装であること、dispatch_fused_moe_kernel の 0.626 が基準未達であることを自ら明示している（1.5 参照）。
  • ビルドとランタイム：#1468 で昆仑芯が FlagTree の第 7 バックエンドに（5 つの固有制約は 1.7 参照）；Torch-FL #634 はクロスカードコピーを xpu_memcpy_peer 経由に変更し、#632 はプリロード順序を修正。
  • 判断：昆仑芯の当日の動きはオペレータ、ビルド、ランタイムの三層にわたり、三つのラインで同時に構造的変更を行った唯一のベンダーである。真のリスクポイントもオペレータ側にある。多くの変更は「同一オペレータの別 tile または融合」であり、統一された性能ゲートが欠けており、集約スコアの口径もベースライン代替によりベンダー間比較が不可能である。

3.3 清微：デバイスタイムラインが torch.profiler に入り、TX8110 で実測（10-22）

日付：2026-10-22　出典：Torch-FL PR #630 · build-infra PR #1459

  • 機能補完：清微（TX8）はこれまでデバイス側プロファイリングが皆無であった——PrivateUse1 にプロファイラ登録がなく、kernel イベントとデバイス時間はすべて空であった。本 PR は rocprofiler-sdk で DeviceTracer と独立プロファイリングライブラリを実装し、NPU kernel を aten op に関連付けて CUDA レイアウトで提示し、TX8110 で実測通過；同時に清微に FLAGOS_BUILD_VENDOR=ON を固定し（ベンダーディレクトリに乱数カーネルを含む）、インストールガイドと互換性マトリクスを「ランタイムのみ」からプロファイリングを含む内容に更新。
  • 影響範囲の自己申告：flagos_kineto_profiler.cc の変更は全バックエンドのランタイムスライス位置とデバイス行命名に影響するが、清微ハードウェアでのみ再検証している——これは PR 自身が明記した残存リスクである。
  • その他：FlagGems 側に清微専用のマージは見られない；build-infra の flagcx 0.14.0 統一 pin により清微バックエンドも明示的な通信依存を取得。
  • 判断：清微が直近三日間で連続して補ったのは「ビルド、乱数、プロファイリング」の三つの基盤的短板であり、オペレータカバレッジではない。この順序は後発者にとって最も参考価値がある：まず CI でビルドでき、次に乱数性を再現でき、さらに性能を見ることができ、最後にようやく最適化を語れる。

3.4 摩尔線程と燧原：MUSA キャッシュ永続化、GEMM と燧原の一括更新（10-22）

日付：2026-10-22　出典：FlagTree PR #1385 · FlagBLAS PR #152 · FlagGems PR #7077 · FlagTree PR #1424

  • 摩尔線程：FlagTree #1385 は MUSA にコピー単位の TME キャッシュ永続化を追加し、コンパイル側でのテンソルメモリエンジンへの増分に属する。FlagBLAS #152 は GEMM 実装を追加。FlagGems 側ではタイトル関連の 5 件のマージが MUSA のテストスキップと入力ドメイン限定（#7502 から #7504）に集中しており、このバックエンドの失敗面がいまだ「入力非対応」を主とし、実装エラーではないことを示している。
  • 燧原：FlagGems #7077 はベンダー 10-13 の一括更新（26 ファイル、+3520/−511）を一度に主干へ投入し、本日単一で最大のベンダー側変更である。FlagTree #1424 は偶発的なバスエラーにより CI で 02-sparse-mla ケースを無効化し、#1427 は vllm benchmark パラメータを更新。これら 2 件の CI 調整を合計すると、燧原側の安定性問題がいまだケース層にあり、製品層ではないことが示される。
  • 判断：両社の当日の産出は性質が異なる——摩尔線程はキャッシュと線形代数という「再利用可能な能力」を補い、燧原は一括更新を納品し CI ノイズを処理している。前者は蓄積可能だが、後者は一度検証可能な明細を必要とする。さもなければ「一括更新」は後続レポートでブラックボックスとしてしか記録できない。

3.5 昇騰、天数、沐曦その他：バックエンド別に分流した小さな歩み、地平線と寒武紀は静默（10-22）

日付：2026-10-22　情報源：FlagGems-vllm PR #936 · FlagBLAS PR #153 · FlagGems-vllm PR #977 · FlagGems-vllm PR #777

  • 昇騰：FlagGems-vllm #936 は昇騰のチャンクゲート付きデルタルール順伝播（chunk gated delta rule）を tle.dsa のスライスと同期インターフェースに切り替えさせた。FlagGems 内でタイトルに昇騰または NPU を含む 7 件の変更は大半がテストスキップとケース同期。TransformerEngine-FL は同日、NPU 関連の PR を 3 件新規作成（#144 get_num_cublas_streams、#145 cuDNN バージョン能力クエリ、#146 bshd/thd レイアウト）し、まだマージされていない。
  • 天数：FlagBLAS #153 は L1 層オペレータを最適化。FlagCX #670 の Iluvatar CoreX 単体テストパイプラインとイメージは依然審査中。sglang-plugin-FL #139 の 0.5.18 empty ランタイム適配は依然審査中（10-15 作成）。
  • 沐曦：FlagGems-vllm #977 は TP=2 構成を補完（平均 1.065 倍、1.10 参照）。FlagGems #7454 の MetaX 修正は審査中。build-infra の flagcx 統一 pin が沐曦バックエンドをカバー。
  • 海光以外の DCU と PPU 側：Torch-FL #629 は cuda/dcu/metax/ppu の四類バックエンドに convolution_overrideable 例外を補い、同一箇所の修正の一括カバーに属する。
  • 地平線と寒武紀：当日、組織内で両社専属リポジトリのプッシュとマージは見られず、連続 2 日目の静默となった。
  • 判断：海光と崑崙芯を除き、残り五社は当日すべて「一経路または一オペレータ」の推進であり、構造的変更はない。地平線と寒武紀の連続静默は本期唯一提起に値する缺口である——来週も動作がなければ、ウィークリーレポートでリスク項目として列挙すべきである。

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

  • 生産能力構造：FlagGems 一社でマージの 56% を占め、量子スタックがコミットの 40% を占め、ビルドとランタイムがそれぞれ 1 割ずつ。マージ量は直近 1 週間の新高値を更新した一方でコミット量は減少しており、当日の主旋律が拡張ではなく滞留分の消化であったことを示す。これは 10-20、10-21 と 2 日連続で大口マージがあった後の状態と一致する。
  • 2.3 周期の第 1 マス：FEP-0140 と FEP-0141 が 10-21 にマージされ、10-22 には海光が vLLM 0.28.0 と SGLang 0.5.18 の 2 バージョンを同時にリリースした。この連鎖は「マトリクスを文書に書き込む」から「最初の実測合格」までわずか 1 日であり、今四半期最速の要件から証拠までのクローズドループである。残る 9 社と 2 本のバージョンラインが、その後 6 週間の主な作業量となる。
  • ビルド層の収束：昆侖芯が FlagTree の第 7 バックエンドとなり、flagcx 0.14.0 が 20 バックエンドに固定され、optest がインストール可能なパッケージになった。三者を合わせた効果は「バックエンドを交換する際にインストールスクリプトを変更する必要がなくなる」ことであり、これは単点の性能向上よりも 2.3 のデリバリー速度を大きく左右する。
  • 可観測性が新たな弱点に：清微は初めてデバイスタイムラインを持ち、昆侖芯のクロスカードコピーはこれまでずっとサイレント失敗していた。この 2 つの出来事は、マルチバックエンドが「動く」ようになった後の最初のハードルが可観測性と再現性であり、より高速ではないことを示唆している。過去 2 週間のテスト移植とユースケース契約の改修（lukatao 一人で 61 件）は、まさに同じ判断の別の表現である。
  • リスク点 1：FlagQuantum の 20 件のマージはすべて単一アカウントによって完了しており、新規追加されたネイティブ Rydberg パスは CPU と 1〜2 ロールのみをカバーしている。物理セマンティクスの検証は同一の人々がテストと実装を書くことに依存しており、外部から独立して再確認できない。提案 083（終端サンプリング）はまだ承認されておらず、急速に推進されれば Runtime、測定結果、乱数源の 3 箇所を同時に変更することになる。
  • リスク点 2：燧原 #7077 のような「一括更新」は照合可能な明細を欠いており、26 ファイルと +3520 行を具体的なオペレータと具体的な収益に対応付けられない。昆侖芯の融合 MoE の 3 項目の性能も代替ベースラインで測定されている。両者とも、今後のクロスベンダー比較を歪めることになる。
  • 観察点：vLLM 0.28 の次のベンダー（清微または沐曦）が海光の empty バックエンドテンプレートを再利用するか；FlagTree 0.7.1 開発ビルド（10-20 の 0.7.1.dev1）が 2.3 前に正式版へ移行するか；TransformerEngine-FL の 3 件の NPU PR が週末前にマージできるか；地平線と寒武紀の沈黙が来週のウィークリーレポートまで続くか。

付録：情報源チェック表と完全情報源リスト

情報源チェック表

情報源 チェック結果
組織リポジトリ API 61 リポジトリを全量チェック、16 リポジトリに期間内プッシュあり
コミット検索 135 件ヒット、12 リポジトリに分布、FlagQuantum と FlagGems で合計 82 件
マージ PR 検索 163 件が期間内にマージ、13 リポジトリに分かれる
審査中 PR 検索 183 件が期間内に更新、うち新規オープン 90 件
Release とビルドタグ 31 リポジトリを逐一チェック、期間内に新バージョンなし；直近は 10-20 の FlagTree 開発ビルド
org イベントストリーム 100 件、うち PR イベント 43、プッシュ 27、ブランチ削除 12、ブランチ作成 9、コメント 4、レビュー 3、フォロー 2
ブランチレベル兜底 docs、release-info、sglang-plugin-FL、vllm-plugin-FL の 4 リポジトリが非デフォルトブランチへのプッシュ、メインブランチに新規コミットなし
Google News RSS 24 組の中英語クエリ、17 件の候補、2 件が有効
HN Algolia 8 組のクエリ、FlagOS 4 件、FlagGems 2 件、いずれもタイトル直接一致なし
CSDN FlagOS コラム トップページ 51 リンク、最新オリジナル稿は 08-28；新規に 10-22 19:00 高校円卓ライブ配信を追加
智源コミュニティ 検索ページはクライアントレンダリングのため、フレームページのみ取得
英語メディア Pandaily に 2.2 システムの転述 1 件、論調は国内と一致、19.87% の遅延数値を新規追加
国内メディア 具身之家に FlagOS-Robo 立項稿 1 件、原初情報源は跨維智能

完全情報源リスト

/pull/977>