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

素材ソース：本誌のFlagOS動態デイリーレポート5期（10-26 / 10-27 / 10-28 / 10-29 / 10-30、期間内に欠号なし）。うち10-26号は月曜朝刊であり、調査期間は前号の締め切り時点である10-23 06:00から起算して72時間、10-24と10-25の週末をカバーする。10-27から10-30までの4期は24時間窓で、首尾が相接し、最終号の最終便は10-29 06:00から10-30 06:00まで。したがって本レポートの事実区間は10-23から10-29までであり、10-23から10-25の部分は元の日付で表記する。

編纂説明：バージョンとリリース、コンポーネントとコード共同構築、メンバー機関とベンダー適配、エコシステムとコミュニティ、トレンド観察の5次元で構成する。5期のデイリーレポートを各窓ごとに累加するとコミット1187件、マージ755件となる。4つの完全な24時間窓（10-27から10-30）のみを取ると、コミット575件、マージ481件となる。単期でプッシュのあったリポジトリ数は順に16、18、20、23、21個であり、組織リポジトリ総数は61個である。バージョンとタグは各コンポーネントリポジトリのタグとReleaseを原子ソースとして独立に再確認し、10-31の再確認結果は次のとおり：build-infraの最新タグは依然としてv2.2.0、communityリポジトリのrelease/2.3ディレクトリ下には依然として中英文のスケジュール表のみで、リリースマニフェストは見当たらない。

1. 今週の要聞

  • 2.3.0がランタイムからアプリケーション層までの一連のパイプラインを完走、タグとリリースマニフェストは依然未着地（10-25 ~ 10-30）：10-25に2.3.0ランタイムをバージョンに基づき再構築することを承認；10-26に20個のvllm0.24.0アプリケーションイメージを新しいランタイム上で再構築することを承認し、タグを「バックエンド別サフィックス付加」から統一的な2.3.0-0.3.0へと収斂させた；10-27 06:54から13:25まで連続20件のボットコミットにより、20個のバックエンドキーのアプリケーションイメージタグを逐一記帳した；10-28から10-29にchangelogがサイトページとHarborに掲載された。10-30朝時点で、build-infraの最新タグは依然として8月3日のv2.2.0であり、community/release/2.3には依然としてreleaseマニフェストが作成されていない。スケジュールによれば、11-13がFEPマージ締め切り、11-30が機能凍結およびrc0の切り出し、12-07がrc1の切り出し、12-14がrc2の切り出し、12-25が封板、12-30がリリースである。

  • MiniMax-M3.1-Flashが9チップW8A8で同日デリバリー、Day-0は「統一フォーマットによる一括複製」段階へ（10-23）：MiniMaxのオープンソース当日、FlagOSは9社のチップのW8A8バージョンをModelScopeとHugging Faceに上架し、9リポジトリが10-23 14:06から14:39の30分以内に集中的に建立された。9社は達摩院玄鉄（真武）、英偉達、沐曦、海光、華為昇騰、摩尔線程、天数智芯、崑崙芯、清微であり、うち英偉達、昇騰、崑崙芯、達摩院玄鉄の4社はExpress版である。技術経路は、モデル原有のQAT NVFP4重みをクロスチップで統一されたW8A8フォーマットへ再変換するものであり、ソースコードデプロイ例は達摩院玄鉄を基準とする（vLLM 0.24.0、vllm-plugin-FL 0.3.0、FlagGems 5.4.0、テンソル並列8カード）。これはGLM-5.3-Flashの9チップに続く1週間内で2度目の「モデルオープンソース当日の9チップ同時リリース」であり、違いは前回がBF16と多精度の並行であったのに対し、今回はW8A8単一経路へ統一的に収斂した点にある。

  • 地平線BPUが初めてオペレータ単位で実行可能なPrivateUse1バックエンドとなり、新プラットフォームが「設計上不可用」から可用へ（10-28）：Torch-FL #674がオペレータ単位実行層を着地させた（31ファイル、5698行追加、145行削除）。これまでBPUはPrivateUse1上で計算オペレータを一切登録せず、hbDNNInferV2はコンパイル済みの全体グラフのみを受け付け、各aten呼び出しはcpu_fallbackに落ち、backends_bpu.confは空であった。本コミットは欠落していた中間層を補う：x86側でhbdk4を用いて単一オペレータの.hbm成果物ライブラリをコンパイルし、これらの成果物を提出するC++カーネルを生成し、さらにdrobotics confルートを追加し、40個の要素ごとオペレータ（32個の単項、8個の二項）、11個の形状バケットをカバーし、RDK S600上で440個の成果物を逐一NumPyと比較してゼロ差異であった。収尾の3コミットはそれぞれ配布ログ名、CUDAコピーカーネルガード、ベンダー名からプラットフォームidへのマッピングを修正した。限界もまた明確である：畳み込みなどの基幹オペレータは依然としてtorch.compileの全体グラフ経路に依存している。

  • FEP-0140 を 0.32 単発、0.28 スキップ、AMD を追加に変更、ルール面でバージョン追従コストを一括で圧縮（10-27 ~ 10-28）：community リポジトリの 2 件の書き換え（#157、#158）により、vLLM プラグインのマルチバージョン互換戦略が「0.32 が唯一のリリースバージョンとなり、全チップをカバーする」と定められ、元の「Day-0 需要に応じて 5 社を選定」という範囲が完全なマトリクス（2.2 サイクルの 10 社メーカーに加え NVIDIA と AMD）に拡大された。0.28 はリリースバージョンとしては扱わなくなり、マトリクスの列と関連 PR 段落も併せて削除され、既にマージ済みの 0.28 適配はアップグレードのベースラインとしてのみ残される。10-28 にはさらに分析範囲と検証計画を補足し（#159）、ステータスを Implementable に、Owner を @ceci3 に設定（#160）；FEP-0141 は SGLang 0.5.18 と沐曦、清微の基本機能に絞り込まれた（#161）。コストは明記されている。0.28 上でマージされた適配は 0.32 上で再検収が必要であり、この作業量はいまだどの PR にも反映されていない。

  • 達摩院玄鉄が一週間で基盤を二つ連続補強：BLAS1 の 15 組オペレータ登録と PPU 疎アテンション（10-26 / 10-28）：10-26 に FlagBLAS #154 が AMAX、AMIN、ASUM、AXPY、COPY、DOT、DOTC、DOTU、NRM2、ROT、ROTG、ROTM、ROTMG、SCAL、SWAP の 15 組の一級基礎線形代数オペレータを一括で補完し、17 ファイルを変更、16,168 行を新規追加した。これまでこのバックエンドの FlagOS における存在感は推論経路に集中しており、数値ライブラリは空白であった。10-28 には FlagAttention #111 が真武 PPU 向けに MiniMax 疎アテンション推論オペレータを追加し（6 ファイル、4,644 行追加）、ページド KV キャッシュ、因果マスク、強制ブロック選択をサポート、prefill は 21/21 通過で幾何平均 2.299 倍、decode は 18/18 通過で幾何平均 1.354 倍、合計 39/39、幾何平均 1.800 倍となった。「推論が動く、訓練が動く、数値ライブラリが自己整合する」という三段階で衡量すると、今週は第三段階の最初のステップに踏み込んだことになる。

  • 沐曦が 135 個の特化オペレータの検収証拠を審査可能な状態に移し、1 時間以内に 135 件の PR を作成（10-27）：FlagGems-Experimental は 17:43 から 17:59 の間に #744 から #878 を新規作成し、タイトルは統一して「Add MetaX support for オペレータ名」、各件は単一ファイルで約 200 行の追加削除。PR 本文には今回が沐曦特化オペレータの再テスト（1027 バッチ）であり、150 個のオペレータが参加、135 個が 3 回の再テストを通過した後に逐一コミットされ、通過しなかった 15 個はバッチ外に残されたと説明されている。検収基準は精度 29 ケース全通過、性能幾何平均 1.008 倍（閾値 0.8）、環境は torch 2.8.0 に metax3.7.2.0、flagtree 0.6.1、8 卡 C550。当日の組織の審査中 PR は 225 から 401 に増加し、うち 135 件がこの一括コミットによるもの。

  • テスト基盤 ref-as-candidate がデュアルリポジトリで展開、「何をテストするか」がオペレータの有無から参考と実装の一致へ（10-29）：FlagGems #7630（9 ファイル）により、正確性テストとベンチマークが明示的に宣言された参考実装を候補として実行できるようになり、外部候補ファイルに依存しなくなった。参考の欠落、参考の呼び出し不可、テスト本体が実際に候補を呼び出していない場合はすべて明示的に失敗する。同日 FlagGems-sglang は #239 から #249 の 11 件で全正確性スイートを get_candidate に変更し、さらに每日の master から kernelgen-dev への自動同期 PR（#242、当日 2 件生成済み）を新設；同日には別に 57 件が同一作者のテスト修正でマージされ、昇騰、沐曦、燧原、崑崙芯、NVIDIA のスキップ条件と参考 ABI をカバーした。このラインはオペレータ数を生まないが、今後の全バックエンドの整合性が信頼できるかを決める。

  • MiniCPM-OCR デュアルモデル Day0 が 12 プラットフォームをカバー、初めて比較可能な正規化基準を提示（10-29）：面壁智能と OpenBMB がオープンソース化した MiniCPM-OCR 1.0（1.3B）と MiniCPM-OCR Jev（2B）がクロスチップ適配を完了し、達摩院玄鉄、NVIDIA、華為昇騰、海光、崑崙芯、沐曦、摩尔線程、清微智能、天数智芯、曦望、Mac（ARM）、此芯科技の 12 プラットフォームをカバーした。性能基準は分けて記述されている。Jev は達摩院玄鉄上で平均 63.56 ミリ秒、実際計算スループットは NVIDIA H100 ネイティブの 98.7% に達する；OCR 1.0 はピーク演算力で正規化後、単一ドキュメント P50 スループットがネイティブの 169.3%、バッチシナリオ 137.1%、そして 169.3% の前提は低ピーク演算力プラットフォームの利用率が高いことであり、単卡がより高速であることではないと明記されている；端側 M5 CPU 上では Jev が平均 1 回のページブロック判別に 1.2 秒、中央値 895 ミリ秒。

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

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

時間 コンポーネント タグ / バージョン 説明
10-26 10:13 FlagTree 0.7.1a1+mthreads3.6 摩尔線程 3.6 専用ビルドライン、純粋な Tag、Releases リストに対応する本文なし
10-28 17:25 FlagCX v0.14.1 #668「アダプタごとのデバイスビットコード生成」を指す、git tag のみで Release 本文なし
10-29 10:55 FlagCX v0.14.1（タグ参照先更新） 再確認時、タグは既に #683 のマージコミット（昆仑芯 cstddef バックポート）に移動、依然として本文なし
10-29 11:09 FlagTree 0.7.1a1+tsingmicro3.6 清微 3.6 専用ビルドライン、純粋な Tag、対応する本文なし
  • 3つのタグ、2つのコンポーネント、いずれも正式バージョンではない：本調査期間中に正式バージョンをリリースしたコンポーネントはない。FlagGems は依然として 5.4.0（09-28）が正式ラインであり、5.5.0.dev0 は 10-12 に開線後、新たなタグはない。FlagQuantum は v0.3.1（10-16）を量子スタックのベースラインとし、FlagScale、FlagBLAS、FlagDNN、FlagFFT、FlagTensor、FlagAttention、vllm-plugin-FL、sglang-plugin-FL などは依然として 09-28 のバッチのままである。これは 2.2 リリース後、2.3 が 12-30 に GA となる前の典型的な空白期間である。対外的なバージョンは静かで、成果物ラインとビルドラインは活発である。
  • 2つのタグにリリース本文が欠けている、これが今週唯一の再発可能なプロセス問題である：FlagCX v0.14.1 は git tag のみを作成し、GitHub Release を作成していない。これは v0.14.0「本文が FlagOS 2.2 リリースリストを指す」というやり方と一致しない。FlagTree の 3.6 ラインは「ベンダーごとに1つのタグ」で推進され、0.7.1a1 自体には統一されたリリースノートがなく、下流はタグ名からバックエンドと Triton バージョンを逆推するしかない。

2.3.0：パイプラインは端から端まで動作、あとはタグとリリースリストだけ

  • ランタイム層（10-25 ~ 10-26）：10-25 に 2.3.0 ランタイムをバージョンリクエストに従って再ビルドすることを承認し、その後2件のコミットで OCI タグビルドパラメータの引用符とベンダー SDK 環境変数の venv プレフィックス喪失の問題を修正した。コンテナに起動期バージョンパラメータを追加し、FLAGTREE_VERSION=latest で当日のビルドをインストールでき、FLAGGEMS_VERSION で FlagGems バージョンを指定できるようになった。バージョンは「イメージに焼き込む」から「起動時に選択する」に変わり、-build バリアントを削除した。
  • アプリケーション層（10-26 ~ 10-27）：10-26 #1488 で20個の vllm0.24.0 アプリケーションイメージに changelog のリリース待ちエントリを追加してゲートを満たし、同時にネイティブプラグインタグをイメージタグから外し、統一リゾルバで決定するように変更した。これにより 2.3.0-0.3.0 というバックエンドサフィックスなしの統一タグが成立した。10-27 に20件のボットコミットが20個のバックエンドキーのタグを逐一記帳した：昇騰 cann8.5.0、cann8.5.0-910c、cann9.0.0、cann9.0.0-910c；寒武紀 neuware4.4.3、neuware4.7.2；燧原科技 tops1.9.10、tops1.10.6；摩尔線程 musa4.3.6、musa5.2.0；沐曦 maca3.7.2.1、maca3.8.1.3；天数智芯 corex4.4.0、corex4.5.0；NVIDIA cuda12.8、cuda13.3；および昆仑芯 xre5.37.1、海光 dtk26.04、清微 tsm260610、曦望 tangrt1.2.0。
  • 記録とゲート（10-28 ~ 10-29）：各イメージの changelog は現在、サイトページ末尾と Harbor リポジトリ説明の両方に表示される（#1545、455ファイル、19080行追加）。理由フィールドは中英二言語対応とした（#1542）。アプリページの一貫性チェックを pre-commit と CI に接続した（#1549）。image_tag または changelog の理由を変更した後は、まず images.yaml を再ビルドしてから比較する必要がある。
  • 未完了項目：バージョンタグ未付与、リリースリスト未作成。10-30 のデイリーレポートは「community リポジトリの release/2.3/release-2.3.yaml が依然として 404」とこの状態を記録し、10-31 の再確認でもディレクトリ内容は中英スケジュール表、行動規範、ガバナンスとメンテナドキュメントのみで、リリースリストはない。

AMD ROCm 7.2.4：本調査期間唯一の新規追加バックエンド

  • ベースイメージ（10-26）：ubuntu 24.04 に repo.radeon.com から ROCm 7.2.4 を直接インストールし、厳選した 28 個のパッケージのみを導入、apt が実行時依存を解決した後に合計 94 個となり、MIOpen、MIGraphX、rocm-gdb、rocprofiler-sdk、opencl を明確に除外した。クリーンなコンテナ内でリハーサルを通過し、ローカルイメージを用いて 8 枚の W7900 のパススルーを検証した。リハーサルで Containerfile に必ず書き込むべき 2 つの事実が判明した。ノードは archive.ubuntu.com に到達できず、ca-certificates が存在する前に国内 HTTP ミラーへ切り替える必要がある（HTTPS ではハンドシェイクが失敗する）。pin ファイルはバージョン選好ではなく必須項目である。
  • 設定とパッケージング（10-27）：vendors.amd.rocm7.2.4 を追加し、スタックは torch 2.11.0+rocm7.2、triton-rocm 3.6.0、flagtree 0.7.0+amd3.6、ハードウェアは Radeon PRO W7900（gfx1100、RDNA3）、ドライバ 6.16.13、Python 3.12 を明記。連続 5 コミットで hipsolver、hipfft、miopen-hip 開発パッケージを補い、FlagCX の AMD wheel 行とベンダー PyPI を有効化し、ローカルの 16 カード gfx1100 上で検証した。同時期に native deb と native rpm の 2 ラインに arm64 次元を追加した。
  • ランタイム疎通（10-29）：FlagCX #679 が ROCm 上で SGLang のテンソル並列を動作させた。eventElapsedTime の実装を補い、torch.bool を flagcxUint8 にマッピングし、USE_AMD テストビルド分岐を追加した。R9700 デュアルカード上で AllReduce、ReduceScatter、AllGather、Broadcast、Send/Recv およびグラフキャプチャの AllReduce 結果が正しく、Qwen3.5-9B と Qwen3.6-35B-A3B-FP8 が TP=2 でサービス提供可能である。
  • ビルダー補習（10-29）：7.2.4 ランタイム上でビルドした FlagCX wheel が GLIBC_2.38 にリンクされ、wheel ラインの 22.04 ゲートに拒否されたため、当該行に自己完結型の 22.04 ビルダー（jammy スイートに deadsnakes の Python 3.12、pin 済み torch）を用意し、glibc 下限を 2.35 に戻した。
  • 境界：FlagGems にはまだ ROCm/HIP の C++ バックエンドがなく、AMD は短期的に Triton パスのみを通る。これは本周期においてバックエンドマトリクスが依然として拡張中であり収束していない直接的な証拠である。

FlagCX：タグからリリースパッケージへ

  • デバイスビットコードをアダプタごとの生成に変更（#668、10-18 マージ、今週 v0.14.1 の内容となる）：setup.py のビットコードステップでハードコードされていた bindings/ir/nvidia をアダプタごとのテーブル参照に置き換え、各アダプタが自身の Makefile とアーキテクチャ変数を宣言する。従来は非 NVIDIA アダプタでは RuntimeError を投げるかビットコードを無音で出力しない状態であり、FlagTree の iluvatar バックエンドは FlagCX ソースをコピーして自行再コンパイルするしかなかった。
  • rpm ラインを 3 バックエンドから 6 に拡張（#673、10 ファイル、+295 行 -8 行）：libflagcx-tsm（清微）、libflagcx-sunrise（曦望）、libflagcx-du（海光 DCU）を追加。3 社ともベンダーベースイメージを必要とせず、SDK を /opt または /usr/local に展開しパッケージマネージャを呼び出さないため、openEuler イメージにファイルリポジトリを加えるだけで完全なビルド環境となる。ベンダー soname は昇騰の既存基準に倣って統一的にフィルタリングする。
  • デリバリー面を wheel ラインへ移行（10-29）：build-infra ボットが flagcx wheel リリースを記録し（#1553）、人手で 5 件の空殻記述を補完して flagcx==0.14.1+rocm7.2.4 を追加し（#1556）、さらに hygon-dtk26.10 を flagcx==0.14.1+dtk2610 にピン留めした（#1563）。これにより 0.14.1 のデリバリー面は cuda12.8、cuda13.3、corex4.4.0、corex4.5.0、xre5.37.1、rocm7.2.4 および新規の dtk2610 をカバーする。
  • 0.14 系列は依然サポート期間内：審査中の #683 は崑崙芯の cstddef 修正を 0.14.0-rc2 ラインにバックポートしており、0.14 のパッチラインが凍結されていないことを示す。

FlagTree：3.6 ラインをベンダー別にスライス

  • 2つの専用タグ：10-26 の 0.7.1a1+mthreads3.6 と 10-29 の 0.7.1a1+tsingmicro3.6 は同じ「ベンダー別に分割された 3.6 プレリリースライン」に属し、いずれも Release 本文はない。清微のタグは同日にマージされた #1459（清微バックエンドが内部 Triton 3.6 開発ラインを同期、27 ファイル、2264 行追加・407 行削除）と一対一で対応する。
  • 能力の増分はコンパイラに集中：摩尔線程の [MThreads][TLE] 常駐 GEMM パイプラインと SPMC 同期がメインラインに進入（#1294、63 ファイル、6192 行追加・403 行削除）。従来 addmm/baddbmm と bmm に別々に対応していた2セットのコンパイラを1セットのスーパーセットに統合し、動的ループ内の stage と phase 推進、1プロデューサ対多コンシューマ、名前付き読み取りと暗黙読み取り、分段完了とコンシューマエポック推論、および単発・融合コンシューマ・16 warp 常駐パスをサポートする。昇騰は TensorView アクセスパスを接続（#1426、32 ファイル、4901 行追加）。AMD は Qwen3-1.7B bf16 向けに batch-1 デコード最適化を実施（#1439、44 ファイル）。R9700 はコンテキスト1で 154 tok/s、8K で 125、W7900 はそれぞれ 167 と 136、実測帯域は 530 から 597 GB/s で、同カードの実測ストリーミング上限の 82% から 87% に達する。
  • IR 層の動作：flir に TensorView 方言を新設（#83、25 ファイル、1396 行追加・13 行削除）。Triton ポインタを shape、stride、アクセスエンコーディングを伴う tensor_view に変換し、パーティション、ストライド、gather/scatter の3種類のエンコーディングを提供。さらに CommonIR の tile.load と tile.store に接続し、Triton tt 方言と HIVM、昇騰 NPU IR の間に位置し、TileIR と並列する。
  • 審査中側：SpaceMiT の vmt4d バックエンド（#1455）、昆仑芯分散 TLE バックエンド（#1436）、海光 TLE 通信プリミティブ対応（#1441）、昇騰 rpm ラインを公開済み wheel の消費に変更（#1461、ベンダー SDK とハードウェアを必要としない初の行）、英偉達 Hopper の4項目のソフトウェアパイプライン欠陥修正（#1460）。

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

組織リズム：5期累計 1187 コミット、755 マージ

期次 調査期間（北京時間） プッシュリポジトリ コミット マージ 審査中（期間内更新） 新規
10-26 10-23 06:00 ~ 10-26 06:00（72 時間） 16 612 274 253 141
10-27 10-26 06:00 ~ 10-27 06:00 18 185 133 225 74
10-28 10-27 06:00 ~ 10-28 06:00 20 102 98 401 269
10-29 10-28 06:00 ~ 10-29 06:00 23 99 67 288 101
10-30 10-29 06:00 ~ 10-30 06:00 21 189 183 253 84
合計 — — 1187 755 — 669
  • マージ後のリポジトリ別累計（各期デイリーレポートの開示基準）：FlagQuantum 226 件（29.9%）、FlagGems 224（29.7%）、build-infra 75（9.9%）、FlagGems-sglang 59（7.8%）、Torch-FL 33（4.4%）、FlagGems-vllm 29（3.8%）、FlagTree 24（3.2%）、vllm-plugin-FL 16（2.1%）、optest 12、FlagTrain 10、FlagCX 10、FlagAttention 9、sglang-plugin-FL 5、community 5、FlagQAI 4、FlagBLAS、FlagScale、FlagOps、TransformerEngine-FL 各 2、FlagCV、FlagSparse、FlagPrism、flir、Trident、FlagTensor 各 1。
  • デュアルエンジン比率は7割以内に低下：FlagQuantum と FlagGems の合計は 450 件、59.6% を占め、build-infra を加えた3リポジトリでは 69.5%——前回同期間の同じ2リポジトリは 56.3%、4リポジトリは 79% であり、今周期は build-infra の比重が 2.3 ミラーの計上により約1割まで上昇した。
  • 週内の形態は「二つの峰、一つの谷、そして再上昇」：月曜（72時間ウィンドウ）は量子スタックと FlagGems がともに高く、火曜は量子スタックがさらに上昇を続け FlagGems が受け止め、水曜は build-infra の計上が主体に転じ（36 件、うち20件はミラータグボットのコミット）、木曜は 67 件まで回落し全週最低、金曜は 183 件で反発し週内最高（FlagGems 単独で 92 件）。
  • 審査中の2回のパルスはいずれも一括コミットに関連：10-28 の審査中 401 件のうち 135 件は沐曦オペレータの一括 PR に由来し、269 件が新規作成；10-29 に 288 件へ回落した後、10-30 にはさらに 253 件へ低下した。一括コミットを除いて見ると、レビューキューの実水準は 220 から 290 件の間で変動し、中心値は前回同期間（154 から 239 件）より高い。

FlagGems（マージ 224 件）：自動供給と正確性修正が並行

  • オペレータ供給はすでに KernelGen が引き継いでいる：10-26 に KernelGen と NVIDIA プレフィックスを付けたオペレータ 16 件をマージ（疎と構造化、量子化、特殊関数、テンソルメタ情報が各 1 種）；10-29 には 1 日で自動生成オペレータ 22 件（疎テンソルの安全でない構築とリセット、nnpack 空間畳み込み、thnn 畳み込み、分数最大プーリング逆伝播、cholesky、frobenius ノルム、chain_matmul および一連の端隅オペレータ）、同日さらに新たに 5 件を起票し、キューはまだ続いている。人手の投入はオペレータの記述ではなく、発射パラメータとテストの実行可能性の 2 点にある。
  • 正確性を主線とする今週最も価値のあるコミット群：index_put と _index_put_impl_ がカーネルを共用するアドレス演算をワイド型に変更（#6892、2 ファイル、112 行追加・4 行削除）——従来は達磨院玄鉄 PPU-ZW810E 上で、int32 インデックスと大きな stride のテンソルの組み合わせが静かに誤ったアドレスへ書き込み、対象行は変わらないが同一アロケーション領域内のガードプレフィックスが書き換えられていた；根本原因はインデックス×stride が int32 内で評価されて先にラップアラウンドし、事後に最終オフセットだけ変換しても間に合わないことにある。昇騰側では flagtree を 0.7.0 から 0.7.1a1 に上げ、実行時検証スクリプトを新設（#7837、5 ファイル、291 行追加）。実行時イメージが flagtree を仮想環境の外の /opt/flagtree に焼き込んでいるため、pip で入れた pin では上書きできないからである。昆崙芯バックエンドが現在の master で直接インポートに失敗する問題も併せて修正した（#7803、90 行）。
  • バックエンドチューニングは昆崙芯が最も密：8 つの出位スカラーチェーンオペレータを融合カーネルに変更（#7617、275 行）、小形状では単一発射、すべてのポインタをカーネルパラメータとして持ち込み、出力は 1 回のアロケーションと unbind で取得、相対所要時間は 0.083〜0.126 から 0.813〜0.934 へ約 7〜10 倍；batch-norm 推論と QKV 変換を連続セグメントカーネルに変更（#7600）、集約指標はそれぞれ 0.228 から 1.357 へ、0.260 から 5.062 へ；masked_fill の整数ビューの高速パスを f32 形式に書き換えた後、P800 上で 0.577 から 0.829 へ（#7850、594 ケースが通過）。
  • その他のバックエンド：天数の conv_transpose2d をデータ型、カーネルサイズ、ストライド、出力チャネル数で索引する 7 套のハードウェアチューニング段位に置き換え（#7036、1886 行追加）、出力が L2 に収まるかどうかで直掃と位相専用の 2 つのバリアントを切り替え；conv3d は呼び出しごとのチャネルゼロ詰めを除去（#7061）、出力はビット単位で一致；沐曦は INT8 と FP8 の grouped_mm_w8a8 を新設（#6950、7 ファイル、1220 行追加）、ベンチマーク形態は GLM-5.2 が PPU SGLang TP=8 上で採取した実呼び出しリプレイに由来し、28 シナリオ、26 組の一意なジオメトリ、324 万回の呼び出し、257 のエキスパート。
  • 審査中の構造：10-28 に新規起票された 53 件の多くは燧原の参照実装修正（#7890 から #7908 の連番、Kaiser と inplace ldexp、aminmax、special_round、LU、vander と slogdet、median と stacking、Adagrad、batch-norm ABI に関わる）、ほかに AMD の 1 行修正——ベンダー記述子がデバイス名を cuda に設定し triton_extra_name を与えていないため、pow、tanh、exp、rsqrt、erf、gelu などがすべて __nv_* を経由して AMD バックエンドに拒否される。10-29 の調査期間中、FlagGems は審査中 181 件、組織の 6 割を占め、マルチバックエンド受け入れのボトルネックがオペレータ供給ではなく参照実装とテスト基準にあることを示している。

FlagQuantum（226 件マージ）：構造再編からシナリオ展開へ

  • 週初はディレクトリ手術：10-23 から 10-26 の三日間で 505 コミット、148 マージ、単一リポジトリが組織の 82.5% のコミットと 54% のマージを占めた。QEC パッケージ再編を九連続で実施（#735 から #749）。まずパッケージ境界と互換ベースラインを監査し、次にコード行列とノイズスキャンを順次隔離、コードファミリと所有権を分割、ストレージ宣言と実行組立を分離、検出器誤差モデルを切り出し、デコードアルゴリズムとオプションアダプタを分離、パッケージレイアウトとインストールガイドを確定し、最後に一体化して主干へマージ——「インストール可能性」を目標としたディレクトリ手術。
  • 外部依存の形成：Quafu SDK ライフサイクル全体の切り替えを六連続で完了（#852 から #866）。発見フロー、論理タスク、物理プログラムコミット、トポロジ解析、ツインライフサイクルを順次 SDK 経由に変更し、最後に旧実行ライフサイクルを退役させた。旧パスは削除であり別名保持ではない、ハードスイッチである。同期間に Rydberg presence は契約策定（#854）から無条件組立における観測の拒否（#865）、単一 presence 観測のエンコード（#869）、有界コヒーレント分岐参照の検証（#873）を経て、最後に有限動的コヒーレント参照（#876）を提案した。
  • 中期は物理シーンへ転換：10-27 の十マージにはテンソルネットワーク下の Module ハミルトニアン期待値収縮（#939）、固定 shots の誤り訂正記憶実験（#932）、固定二ビットゲートカバレッジ補完（#935）が含まれる。10-28 の六マージのうち、「シャーディング後の MPS と非シャーディングが等価かどうか」を両アーム実行可能証拠にした（#945、max_bond 64 に精確勾配はレイアウトのみ変化、max_bond 2 に近似勾配はレイアウトと truncation がともに変化、両アームの差で二種の寄与を分離）。
  • 週末は合成パイプラインへ収束：10-29 は 60 コミット、15 マージ、すべて量子回路合成（CS シリーズ）に集中。リポジトリ内には FQ-SYNTH-CS01..CS07-20261029 で十份の仕様と納品ドキュメントをアーカイブ済み：CS-01 はコヒーレント整数構築のセマンティック境界と検証を定義、CS-02 は純算術カーネルでコヒーレント加算を削減、CS-03 は乗算とコヒーレント多項式を処理、CS-04 は制限付き Python ワークフローを貫通、CS-05 はライフサイクルとワークスペーススケジューリングを追加、CS-06 は三段階で実装、CS-07 はレジスタセマンティクスとプログラム准入へ進む。同日に可搬 .fqx 実験ファイルの保存・ロード（#960）と fq.run の検査付きプログラム実行（#964）を追加。
  • 判断：量子スタックの作業方式は「設計稿、契約稿、実行可能例、受け入れ記録」の四段階で証跡を残すもので、コストは高いが検証可能性が良く、組織の三割以上のコミットを長期的に占めながらマージ率が三割程度にとどまる理由も説明できる。これはマルチチップ適配とは無関係で、2.x 周期において唯一ハードウェアとデカップリングしたソフトウェアスタックの主線である。

build-infra（マージ 75 筆）：イメージマトリクスと撤回

  • ミラー行列の記帳：10-27、20 件のロボットコミットにより、20 のバックエンドキーに対する vllm アプリケーションミラータグが一律 2.3.0-0.3.0 として記録され、これは本周期で 1 日あたりのマージ数が最多の日となった（36 件）。その後、base 層のミラーごとの changelog とプッシュゲートが補完され、三段のミラー記録ループが 1 つのスクリプトに統合された。
  • 海光 DTK 26.10 の 8 件フルチェーン（10-29）：初版のコンテナと設定（#1554、#1555）が着地した後も、ミラーはビルドもスケジュールもできない状態だった——base/hygon-dtk26.10 は /opt/dtk を dtk-26.04 に指しているが、SDK は実際には /opt/dtk-26.10 に展開される。ビルドマトリクスに当該エントリの runner カバレッジがないとデフォルト値にフォールバックする（#1558）。torch 2.13.0+dtk2610 のグローバル依存は直接 libmpi.so.40 と libibverbs.so.1 にリンクするが、26.04 の wheel はこれら 2 つの soname をパッケージ内にハッシュ化して取り込んでいる。そのためベースイメージに libopenmpi3t64 を追加し（#1564）、ビルダーに libopenmpi3 を追加した（#1565）。同一ランタイムで python 3.12 を固定したため、既存の cp310 の hcu wheel が解決できなくなり、deadsnakes 3.12 で cp312 ビルダーを再構築し（#1562）、hcu-dtk2610 を wheel リリースラインに追加した（#1566）。8 件のうちカーネルを変更したものは 1 件もなく、ハードウェア世代切り替えのコストはほぼすべてパッケージングと依存解決に集中した。
  • 一度もプッシュされていないミラー 2 件を撤回（10-28）：Harbor には megatron_training0.18.2-cambricon-neuware4.7.2 と対応する megatron_rl リポジトリが存在しないが、状態マトリクスには image_tag: 2.2.0-0.3.0 が記録されていた。ドキュメントパイプラインは存在しない 2 つのミラーに対して起動ページ、readme、changelog を発行し、以後 pubdoc-app のたびにこれら 2 つのリポジトリで 404 が発生した。根本原因は 0.18.2 の wheel 内で platform_register に MLU プラットフォームがなく、torch_mlu の gpu_migration が CUDA 表面を MLU にエイリアスした後で選択されるのが PlatformCUDA であり、パイプライン並列グループが初期化されないままである一方、MLU 登録が release/0.2 にしか存在しないことだった。処置は主張を撤回することで無理に合わせるのではなく、image_tag を削除し、launch_docs: false に設定し、2 份の changelog を削除することで、「changelog ファイルセットが公開済みセットと等しい」という状態を再び成立させた。
  • その他：native deb と rpm に arm64 ディメンションを追加（#1537）。昇騰 rpm ターゲット（#1557、ベンダー SDK とハードウェアに依存しない初の rpm ライン）。vllm 再パッケージ依存を PEP 503 シンプルインデックス読み取りに変更（#1543、依存ごとにサブプロセスを起動する方式を置き換え）。

Torch-FL（33 件マージ）：抽象層のリネームと新プラットフォーム接続

  • 命名リファクタを一気に完了：ボックス化スロットを Backend::kCuda から Backend::kBoxing に変更し、各プラットフォームにベンダー名を追加。ベンダー別にソースと CI ディレクトリ、設定とマーカーとパッケージングディレクトリ、バックエンド enum と NVIDIA ルーティングキーをリネームし、最後にリネームで残ったテーブル参照の不整合を修正（6 件を 13:38 から 15:59 に完了）。同時期に「デフォルト設定からボックス化へルーティングしてはならない」ことを明確化し、ボックス化のみの day-0 設定を新設——「あるプラットフォームでオペレータが不足した場合にパッケージングパスへフォールバックする」ことを暗黙の動作から明示的な宣言に変更した。
  • 地平線 BPU 接続：本週の重要ニュース第 1 条を参照。ここでは繰り返さない。
  • 「動くが誤動作する」2 箇所のハード修正：海光 DCU の runtime_dir が以前は ABI シムだけを置くディレクトリを指しており、ランタイムライブラリが 32 個のスタブリンクで構成され、ビルドは通るが import すると未定義シンボルでエラーになった（#654、71 ファイル、1.1 万行）。天数 bf16 GEMM がホスト実行にフォールバック——2048 角の bf16 mm は実測 0.41 TFLOPS で、同機 CPU の 0.54 を下回り、同オペレータの fp16 は 80.2、ベンダー付属 torch は 84.6 だった。根本原因はサポート判定に bf16 が含まれておらず、mm と addmm がホスト側で転置重みをコピーしていたこと（#660）。修正後はベンダー BLAS を使用する。
  • その他：MPS 側で MPSGraph のブロードキャスト形状を保持し、線形オペレータのテストケースに CPU リファレンスと読みやすい差分を用意し、Qwen3.5 ビジョンファクトリと補間を MPS に残す。昇騰は FP32 matmul 精度に従い勾配を常駐させる（#683）。conf キーでデコード後の soft-lowp 組み合わせをルーティング（#665）。MUSA tuner を各戦略サブクラスに貫通（#666）。ビルド記録内のベンダー名とプラットフォーム id の不一致（hygon/dcu、mthreads/musa、enflame/gcu、nvidia/cuda）を併せて修正（#673）。

推論スタック：vllm-plugin-FL（16）、sglang-plugin-FL（5）、FlagGems-vllm（29）、FlagGems-sglang（59）

  • 3つの新モデルが同じ週にプラグインへ：MiniMax-M3.1のサポートと推論サンプル（#631、10-24マージ）、GLM-5.3-Flashの純公開オペレータ実装（#454、90ファイル、19140行追加・280行削除）、Qwen3.8-Flash-NextとQwen4のチェックポイント読み込みとモデル統合（#455、65ファイル、11226行追加・109行削除、HC、PLE、QSAとマルチモーダル接続を含む）。FP8は一律に能力ゲーティングを採用：プラットフォームがネイティブサポートする場合はネイティブカーネルを維持し、サポートしない場合はBF16の線形パスとMoEパスへフォールバックし、--dtype bfloat16を強制する。
  • 上流メジャーバージョンの2つのラインを同時に推進：ネイティブCUDAのvLLM 0.32適応（#615、57ファイル、3408行追加・1044行削除）はスタックをvLLM 0.32.0＋cu129、PyTorch 2.13.0＋cu129、CUDA 12.9、python 3.12.3に固定し、既存のNVIDIA CIは6項目の推論と3項目のサービスがすべて通過；同時に0.28の既存適応も引き続きマージ（燧原 S60 #582、清微 TXDA #642は審査中）し、FEP-0140の「0.32単発、0.28スキップ」との並行期を形成している。
  • グラフモードが3番目、4番目の国産バックエンドへ到達：清微 TXDAはvLLMプラグインでFULL_DECODE_ONLYのグラフキャプチャとリプレイを獲得（#649、8ファイル、487行追加）、キャプチャ領域内でのカーネル起動拒否（エラーコード0x47000003）とデバイスガードによるストリーム改道という2つの根本原因を修正し、非TXDAパスは上流とバイト単位で一致を維持；AMD側はSGLangがR9700（gfx1201）上でFlagOSを動作させた（#157は審査中）。
  • オペレータライブラリ側の重点は新規追加から決定性へ：融合全リダクションRMSNormをFlagGems-vllmへ（#773、6ファイル、3191行追加）、all-reduce＋残差加算＋RMSNorm、オプションのFP8静的量子化、SM100+のNVFP4サポート、TP2/4/8のFP16とBF16がすべて可能；ihc_preのstage1マージはtl.atomic_addをsplitスロット単位の書き込みに置き換え（#1017）、アトミック加算は結果がブロック到達順序に依存し、再発射時にビット単位で一致しないため。沐曦側はFlashAttentionのキャッシュ安全性とグラフキャプチャを修正しTP2/TP4を最適化（#998）、沐曦 TP2のpacked decodeでSplit-KVスケジューリングと計算tileの再配置を実施（#1025）；fused_q_kv_rmsnormは同時に昇騰（#872）と達摩院玄鉄（#888）で実装された。
  • FlagGems-sglangは本期間でマージ効率が最も高いリポジトリ：34件の競賽トラックのオペレータが2時間強で連続マージ（10-23 15:47から18:02、うち16:21から16:31の10分間に9件）、供給は複数の外部コントリビューターからで、MLAバッファ読み書き、レイアウト再配置、Top-Kサンプリング、MoEゼロエキスパート、キャッシュ配置とソフトプーリングをカバー；エンジニアリング側ではDebianとRPMのパッケージングを追加（#191）し、このリポジトリがオペレータ集合からインストール可能な配布物へ移行したことを示す。燧原のcore_shapes.yamlは1週間効かなかった——リポジトリ内に読み込み箇所がなく、ベンチマークはハードコードされたkunlunxin分岐しか認識しない（#229でファイル追加、#232で読み込み修正）、修正後は検索を任意のベンダーへ汎化し、併せてFileNotFoundErrorも修正；AMD側はRDNA3向けに3つのMambaオペレータのgfx1100版を追加（#231、578行、汎用カーネルとビット単位で一致）。

FlagCX（10件マージ）と通信層

  • デバイス層：昆仑芯 XPUのデバイスビットコード構築（#676）、Makefileで共有デバイスAPIラッパーをxpu3のLLVMビットコードにコンパイルし、XDKアンインストールパッケージからデバイスモジュールを抽出、公開シンボルを保持して最適化し、libflagcx_device.bcとコンシューマ側ヘッダファイルを生成、通信traitsはXSHMEMを使用；続いてFlagTreeリンクをサポートするXPUのデバイスIRエントリを追加（#678）。
  • セマンティクス修正：天数のDevice APIにAtomic::loadの取得セマンティクスを追加（#681、3ファイル、359行追加・37行削除）——従来はload(..., Acquire)とload(..., Relaxed)が同一命令を発行し、オブザーバがフラグを見た後に無効化バリアがなく、本件は読み取り後にフェンス、スコープに応じて強度を選択するよう変更；システムスコープはivcore11に対応するメモリバリア命令がないため未実装のまま。
  • パッケージングと適応：清微 TSMサポート（#674、10ファイル、886行追加・80行削除）は同時にグループP2Pクリーンアップ、不正peerの拒否、非同期ストリームイベント処理を修正；AMD適応はCUDAStreamGuardに変更（#680）；昆仑芯プラットフォームtraitsはcstddefをガードの外へ移動（#682）。

トレーニングスタック：FlagTrain（10）、FlagScale（2）、TransformerEngine-FL（2）、Megatron-LM-FL（審査中10）

  • FlagTrain のこの系統の書き方は固定：単一 PR のタイトルでバックエンド一覧を直接列挙し、1 つのオペレータをバックエンドマトリクスで一気に展開する。マージされたのは fused_indices_to_multihot（#29、NVIDIA と昇騰、H20 にベンチマークあり）、ベースライン対照メカニズムの移植（#30、デバイスボトルネック単位のピークスケーリング係数で正規化した速度比、出力 vs Base 列、ベースライン欠如時は理由を記録して失敗させない）、multi_tensor_adam（#35、6 ファイル、1093 行追加、NVIDIA、海光、沐曦、PPU と天数をカバー、1 回の Triton 発射でバッチ一括の多テンソル Adam 更新を完了、H20 上で fp32 65536 要素は DeepSpeed CUDA ベースライン比 2.24 倍、1024 要素の小さい段位では逆に 0.76 倍）。審査側では fused_proj_rms の前方・後方（#38）、fast_gelu（#33）、fp8_gemm（#18）、mixed_gemm（#10）と multi_tensor_adam の後続バッチが同時に並んでいる。
  • FlagScale はテスト規律へ転換：統一テスト戦略、影響を受けるルートと実行証跡ゲート（#1315）；オフライン学習オペレータプロファイリング（#1310、4 ファイル、1474 行追加）、学習側は各 rank の Chrome タイムラインのみをエクスポートし、オフライン抽出器が外部 ID 帰属、通信計上とマルチ rank 集約を行い、推論プロファイリングと一致する列指向の成果物として出力。審査中には DeepSeek-V4 の上流同期 [1/N]（#202）と [2/N]（#211、パッキングシーケンスに連続コンテキスト並列を追加）、および HF と MCore の DCP 軽量相互変換（#1319）が見える。
  • TransformerEngine-FL の 2 件：FlagCICD v1 を実装し、L0 から L4 のテスト階層と計画駆動実行を導入（#142）；3rdparty/ の 3 つのサブモジュールを上流 v2.17 の検証ベースラインへロールバック（#150）——以前に誤って cutlass を 240 コミット（4000 以上のファイルに関与）前進させ、cudnn-frontend を v1.25.0 から未リリースのスナップショットへ進め、googletest を master の先頭へ進めていた。
  • Megatron-LM-FL は別途記録に値する：審査中 PR は 10 件、ここ 2 週間で初めてのまとまった規模の更新（10-30 の調査期間）だが、今周期はマージが見られない。この学習スタックは 10 月中旬以降一時停止しており、本当にプッシュが再開されたかは次号で確認する必要がある。

数値ライブラリ、アテンションと新方向

  • FlagBLAS（2 件）：達摩院玄鉄 BLAS1 の十五組オペレータを一括で整批登録（#154）と、その後の L1 命名・引用の整合（#155）。BLAS1 は上位の BLAS2、BLAS3 および LAPACK ソルバの前提依存であり、この層が欠けるとボトムアップで自己整合できなくなる。これが今週最も過小評価されやすい一件である。
  • FlagAttention（9 件）：PPU の MiniMax 疎注意力（#111）のほか、昇騰 Parallax 注意力の三段実装（#103、10 ファイル、2738 行追加、因果マスク、スライディングウィンドウ、GQA、可変長入力をカバーし、FLA と比較して多くの訓練形状で 1.0 から 8.74 倍）、燧原 MiniMax M3 疎注意力の prefill と decode 最適化（#104、2 ファイル、2873 行追加・2516 行削除）、沐曦 C550 上の Triton 融合 AttnRes フォワード（#108、3 ファイル、268 行追加、D=7168 と BF16 で 0.075 ミリ秒から 1.496 ミリ秒、著者は FLA が利用不可のため加速比を主張しないと明記）、海光の FP8 MSA パス削除（#109）。注意力層の断片化は激化しており、ベンダー横断の統一的な下層実装はまだ現れていない。
  • FlagCV（1 件）が初めて自己定義を明示：初版の About と README をマージ（#2）。「Triton で実装された高性能コンピュータビジョンライブラリ」と位置づけ、OpenCV 形状のインターフェースの下で色変換、フィルタリング、幾何変換、算術演算を提供し、OpenCV の CUDA ベースラインをベンチマークとし、FlagTree の上に構築されバックエンドはプラグイン可能。タイムラインは 10-14 にリポジトリ作成、10-18 にスケルトンを登録しオペレータ実装を撤去して即時モードスケルトンに変更、10-26 に位置づけ説明を追加——コードスケルトンが先、位置づけ説明が後。現時点でベンチマークや非 GPU バックエンドのデータはなく、真の検証点はメモリ集約型オペレータの NPU と DSA 上での性能である。
  • FlagQAI（4 件）と FlagQuantum の境界はなお明確化が必要：10-27 に初回のコマンドラインソーススナップショットを導入、初回 CI はフィクスチャリストのステップで失敗（#1 は審査中）。10-29 にローカル量子ワークベンチのウェブページとネイティブ Agent 統合（#3）、リフレッシュ後にフォロー設定を保持する修正（#4）を追加。README は「意図からの回路合成」を製品方向として明記し、完成済み機能とはしていない。現在の検証範囲はローカル回路シミュレーションと、固定アンザッツ一つの二量子ビット変分ルートのみである。
  • その他：FlagDNN の 2 件はいずれも海光の修正（GPU 名と性能）。FlagFFT のプッシュは codex/musa-shortfall フィーチャーブランチにあり、デフォルトブランチの最新コミットは依然 10-15。FlagTensor の昇騰常駐グリッド要素ごとカーネルとベンダーチューニング（#32、24 ファイル、1128 行追加・139 行削除）。Trident は Python 3.10 をサポート（#5）、Monad 中間層（#4）は審査中。flir の昇騰 split と join および静的置換の低減（#86）は審査中。

テストとリリースエンジニアリング：optest（12）、FlagOps（2）、community（5）

  • optest が十三社のベンダースクリプトを 1 コマンドに集約：flagos-gpu-check は「ベンダー専用デバイスノード優先、SMI コマンドで二次確認」の順序で自動検出し、各ベンダー原有のカード単位テーブル、タイムアウト、リトライパラメータを保持し、2 つの競合ルールを明記——海光は AMD より先（両者とも kfd を持つが、mkfd を持つのは海光のみ）、玄鉄は NVIDIA より先。その後、出力を単一のテキストサマリまたは単一の解析可能な JSON と YAML に再構成（19 ファイル、2947 行追加）。device、driver、runtime、runtime_version、device_count、memory_unit などの正規化フィールドを追加し、ランタイムとホストドライバを分けて記述。燧原 S60 は今サイクルで FlagGems-vllm と FlagGems-sglang のバリアント CI に接続。
  • community の 5 件はすべてルール：FEP-0140 の 2 つの書き換え、分析範囲と検証計画、ステータスを Implementable へ移行、FEP-0141 の絞り込み。表現の明確化も本文に記載——DeepSeek-V4-Flash と Pro は依然初期 W8A8 候補であり、「NVIDIA 比でスループット 10% 向上」は最適化目標であって固定の受け入れ基準ではない。
  • FlagOps の 2 件はともに安定性：堅牢な検出でハードキル fetch が残した陳旧 git ロックを除去（#18）。デフォルト接続タイムアウトを 30 秒から 300 秒に引き上げ（#17）。

4. 会員機関とベンダー適配

  • 海光：本周期でエンジニアリング密度が最も高いベンダーの一つ。DTK 26.10 は単一日で8件のマージを完了し、コンテナ、可用性修正、cp312 ビルダー、FlagCX wheel ラインから2つの soname 依存関係の補完まで、再利用可能な「新 SDK 接続調査パス」を形成した。コンテナ層の初回導入時には「FlagCX は未構築のため、本段階では対象外」と明記した。さらに build-infra が libglog.so.1 を補完し、ネイティブプラグインが DTK イメージ上でロード失敗する問題を解決（#1524）、Torch-FL が DCU ランタイムビルドソースを修正（#654）、FlagAttention が FP8 MSA パスを削除（#109）、FlagTrain が海光をファーストクラスバックエンドとしてリスト（#35）、また審査中の DCU ハードウェアヘルスサンプリング（FlagScale #1299）と GLA 実装（FlagAttention #117）がある。
  • 沐曦：投入はオペレータ検収と推論性能の両端に集中。135 個の特化オペレータの一括 PR 提出が本周期の組織審査中件数急増の主因であり、grouped_mm_w8a8 の INT8 と FP8 のデュアルパスは実呼び出しリプレイを基準としている。FlagGems-vllm 側では FlashAttention キャッシュ安全性とグラフキャプチャを修正し、TP2/TP4 を最適化、段階別に融合 MoE チューニングを区分けし、TP2 packed decode で Split-KV スケジューリングを実施。sglang-plugin-FL の MetaX と MACA バックエンドのパッケージ全体（31 ファイル、3364 行追加）が推論フレームワーク側のベンダーマトリクスを補完した。エコシステム側では RLinf のフルスタック適応が公式メインラインにマージされた（第5節参照）。
  • 崑崙芯：最も早く接続し、最も広くカバーしているため、最も早くロングテール最適化期に入っている。今週の十数件のマージはほぼすべて「既存パスを速く安定させる」もので、スカラーチェーン融合は約7～10倍、連続区間カーネルは batch-norm 推論と QKV 変換の集約指標を 0.228 と 0.260 から 1.357 と 5.062 に向上、masked_fill は 0.577 から 0.829 に向上、slice_scatter と vstack はパスを書き換え、sym_numel により登録ロジックが見落としていたベンダーオペレータテーブルを回収した。ビットコードビルド（FlagCX #676）の長期的価値は単一オペレータの高速化よりも高く、崑崙芯を統一デバイス抽象に接続した。
  • 清微智能：内部 Triton 3.6 開発ラインを直接オープンソースバックエンドに同期し（27 ファイル、2264 行追加、407 行削除）、3.6 専用タグを付与。TXDA は vLLM プラグインでグラフキャプチャとリプレイを獲得。FlagCX の TSM サポートと rpm パッケージングが同日に実現した。代償は毎回の同期量が大きく、レビューではベンダー SDK セマンティクスごとに項目別確認が必要なこと。利点は FlagGems と FlagTree のインターフェース取り決めがベンダー内部進捗とともに前倒しできることだ。エコシステム側では Open3D-PIMC の普及が継続しているが（第5節参照）、現時点で両ラインはコード上で交差していない。
  • 華為昇騰：4つのバックエンドキー（cann8.5.0、cann8.5.0-910c、cann9.0.0、cann9.0.0-910c）すべてが 2.3.0-0.3.0 に追随。コンパイラはインストール期固定からランタイム強制固定へ進展（#7837）。イメージが flagtree を /opt/flagtree に焼き込んでおり、pip pin では上書きできないためだ。FlagTree は TensorView アクセスパスを接続し（32 ファイル、4901 行追加）、CommonIR から HIVM の間でインデックスモードに応じてインデックスペイロード DMA または要素ごとのゼロパディング転送を選択する。FlagAttention は Parallax アテンションの三段実装を追加。vLLM 側のネイティブ decode グラフと ModelSlim 動的 W8A8 量子化はなお審査中。
  • 燧原：形状テーブル、ツールチェーン、推論の3ラインで各1箇所を補完。core_shapes.yaml が1週間反映されなかった根本原因はリポジトリ内にロードポイントがなかったことであり、修正により検索を任意のベンダーに汎化した。FlagPrism のプロファイラとデバッガを燧原に拡張しデフォルト有効化（#1239、5 ファイル）、デバッグ付きカーネル起動はゲートウェイ経由に変更。Qwen3.5 FP8 の W8A8 ブロックキャリブレーション推論を GCU に投入（#358、20 ファイル、3367 行追加）、GCU300 と GCU400 のハードウェア制約を中心にカーネルパッチを再作成し、FP8 MoE が eager と全体グラフの両モードで動作可能にした。審査側では大量の参照実装修正（#7890 から #7908 の連番）が未収束。
  • 天数智芯：畳み込みファミリの3ラインを同時最適化——conv_transpose2d の7種工况段階、conv3d のチャネルゼロパディング除去、conv2d の重みパッケージキャッシュと channels_last チャネル変換融合。FlagCX は Atomic::load の取得セマンティクスを補完したが、これは通信正確性の問題であり性能問題ではない。ハードウェア側では天垓 300 が初の実機デモを対外実施（第5節参照）、ソフトウェア側の適応は引き続き Device API、SGLang 0.5.18、訓練オペレータの3箇所で項目別に補完中。
  • 達摩院玄鉄：連続3ウィンドウで「一度に1ブロック」のリズムを維持——推論（真武 Express 版と PPU スパース MLA フォワード）、アテンション（PPU 上の MiniMax スパースアテンション、幾何平均 1.800 倍）、数値ライブラリ（BLAS1 十五組オペレータ）。さらに fused_q_kv_rmsnorm が 10-29 に当該プラットフォームに到達し、FlagTrain の multi_tensor_adam と fp8_gemm がいずれもこれを

バックエンドの一つとして数えられ、optest のベンダー衝突ルールでは NVIDIA より前に配置されている。次は BLAS2 と BLAS3 が追随するか、また CPU 側がアクセラレータカード側と同じ検査スクリプトを共用するかを見る必要がある。

  • 摩尔線程：注力点はオペレータ数ではなくコンパイラにある。常駐の GEMM と SPMC を合成したスーパーセット（63 ファイル、6192 行追加、403 行削除）は、addmm、baddbmm、bmm といった基幹オペレータを MUSA 上で実用性能まで到達させる前提であり、この能力は昇騰と沐曦の TLE ラインでも再利用されている。SDK は v0.7.1 にアップグレードされ、3.6 専用番号タグと整合させた。エコシステム側では Megatron-MUSA-Titan をオープンソース化し（第5節参照）、本スタックとの交点は依然としてオペレータとプラグイン層であり、学習フレームワーク層ではない。
  • 地平線：今週唯一の「新プラットフォームが利用不可から利用可能へ」の接続（Torch-FL #674）。価値は性能ではなく経路の打通にある——40 個の要素単位オペレータは出発点であり、畳み込みなどの基幹オペレータは依然としてグラフ全体のコンパイルに依存している。作者は同時に二つの否定結論を記録している：libhbtl.so は CPU リファレンス実装に過ぎず、動的シェイプは HBRT 4.7.5 上では実行不可（ローダが当該軸を stride 0 として宣言し、タスク検証が 64 以上を要求する）。
  • 寒武紀：本期間、組織内に専用リポジトリのプッシュとマージはなく、build-infra に二箇所の痕跡のみが残る——2 件の neuware バージョン（4.4.3 と 4.7.2）の changelog 記帳、および 2 件の未プッシュの megatron イメージの撤回。前回のウィークリーレポートで既にこの社をギャップとして標記しており、本期間も継続しているため、次回はリスク項目として単独で記載することを推奨する。
  • 曦望：tangrt1.2.0 が初めてアプリケーションイメージマトリクスに進入し、libflagcx-sunrise が rpm ラインに進入（SDK は tangtk --toolkit と pccl を経由して /usr/local に配置）、vLLM 0.28 ランタイム適配と共有 Gate CI は依然審査中（#647）。
  • AMD（新規バックエンド）：本期間、一枚のベースイメージから完全なバックエンドへ成長し、設定、パッケージング、wheel 行、ランタイム検証、ビルダー補習の五ステップが揃った。SGLang は R9700 上でテンソル並列を走通した。FlagGems 側にはまだ HIP の C++ バックエンドがなく、そのベンダー記述子にはデバイス名を cuda に設定する問題がある（修正は審査中 #7908）。これは AMD のラインが現時点では依然として Triton 経路を主体としていることを示す。
  • 進畳時空と此芯、ARM：進畳時空の FlagTree における vmt4d バックエンドは依然審査中（#1455）であり、RISC-V AI 方向における今週唯一の動きである。MiniCPM-OCR の端末側カバレッジは此芯科技と Mac（ARM）を組み込み、M5 CPU 上では SME2 マトリクス命令で主要線形層を加速し、Triton TLE Raw を通じてオペレータ実行経路に接続、平均単一ページブロック判別は 1.2 秒。

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

  • InfoQが2.2以降で最も完全な中国語技術振り返りを公開（10-24）：第3四半期時点で、FlagOSエコシステムのメンバー単位は107社、四半期のコミュニティダウンロードは464,336回（第2四半期の4.76倍）、コード貢献者は264名（前バージョン比55%増）。2.1から2.2にかけて、マージ済みPRは1,890から4,890に、コミットは5,100から9,730に、新規Issueは420から1,423に増加。九大オペレータライブラリの合計は1,454オペレータで、前バージョン比890増、1,000以上のオペレータ、10款のチップ範囲においてチップ横断の総合性能は約27%向上。GLM-5.3-Flashは既存の昇騰910B上で論理サービスのスループットが8.52kから17.36k tokens/sに向上（2.04倍）、512K長コンテキスト生成は60.9 tokens/s。コスト項目は、1台8カード910Bの月額賃料16,500元、3P1D配置、93%のキャッシュヒット率で試算し、256K入力8並列シナリオで出力百万Tokenあたり59.27元、512K入力4並列で104.53元と、それぞれ対応する商用APIより19.4%と27.6%低い——これは賃料換算の試算であり、同一負荷での実測対照ではないため、引用時にはこの限定を保持すべきである。
  • MiniCPM-OCRの適配説明は三種類の数値を分けて陈述（10-29）：実スループット比（Jevは達摩院玄鉄上でNVIDIA H100ネイティブの98.7%に到達）、ピーク算力で正規化したスループット比（OCR 1.0 単一ドキュメントP50 169.3%、バッチ137.1%）、端側レイテンシ（M5 CPU平均1.2秒、中央値895ミリ秒）それぞれに前提を明記し、169.3%の成立前提は低ピーク算力プラットフォームの利用率がより高いことであり、単卡がより速いことではないと明記している。これは本スタック最近で初めて「ネイティブに追いつく」と「利用率がより高い」を分けて陈述した資料であり、単一の倍数より参考価値が高い。
  • コミュニティコンテンツのリズムは発表会式の講演からプラグイン単位で分解する単点技術ライブへ移行（10-29）：19:00開始の回はsglang-plugin-FLのチップ横断推論適配をテーマに、ATenオペレータ置換、融合オペレータスケジューリング、統一通信抽象、PD分離下のKV Cache伝送とEmptyモードの依存分解を解説し、口径では昇騰、海光、崑崙芯など10款のチッププラットフォームに適配済みとしている。コード側の進捗方向とも一致する（当該リポジトリは今週6件の審査中PR更新があり、昇騰と天数の0.5.18 Emptyランタイム適配を含む）。本回は10-22の大学円卓、10-15のオペレータ賞金チャレンジと連続する技術伝播ラインを構成する。
  • 清微はOpen3D-PIMCをオープンソース初公開から30カ国の教員课堂へ（10-26）：本プロジェクトは清微智能と北京智源人工知能研究院が共同開発し、3D算力チップ向けのプログラミングモデルとオープンソースソフトウェアフレームワークであり、9月に中国算力大会で正式にオープンソース化され、衆智FlagOSの次世代3Dチップ向け主要ソリューションの一つと位置づけられている。開発者はデータ分布とタスク分割のみを記述し、フレームワークがグラフコンパイルと即時実行の分割・呼び出しを自動完成し、推論側はvLLMとSGLangにネイティブ接続し、各ベンダーの私有命令セットとマイクロアーキテクチャ能力はプラグイン形式で接入する。本期報道はコードではなくエコシステム普及に焦点を当てる：グローバルAIオープンコンピューティング教員発展計画が清微のエンジニアを课堂に送り込み、受講者は30カ国以上からの約50名の高校骨幹教員である。文中の「20社のチップベンダー、30余款のAIチップに適配済み」は報道側の口径であり、10月のオープンコンピューティング大会で公式に示された21ベンダー、35チップとは完全には一致しないため、引用時には帰属を区別する必要がある。
  • 沐曦は具身知能の強化学習フレームワークを上流メインラインに接続（10-26）：RLinfは清華大学と無問芯穹が北京中関村学院などと共同で発表し、具身知能向け初の模訓推一体型大規模強化学習フレームワークと位置づけられ、成果はOSDI、RSS、NeurIPSなどの会議に採録されている。沐曦は曦雲CシリーズGPUクラスタに基づき512卡と1024卡（128ノード×8卡）の2档のSFTを完成し、Pi0.5モデルをRoboTwinデータセットで訓練、四組のタスク成功率はすべて論文報告値に整合または超過し、うち一組は8.8ポイント高い。マルチマシン拡張の線形性は97%以上を維持。接入方式はプラグインモードで四層整合（アクセラレータ抽象層にデバイスマネージャを追加しRLinfレジストリに登録、環境変数でマルチカード可視性を制御しRayスケジューリングと協調、通信はデフォルトでMCCL、ソフトウェアスタックはMXMACAベースのPyTorchとFlashAttentionでBF16とFSDPをサポート）。本件はFlagOSコンポーネントのリリースではないが、方向性は注目に値する——FlagOS-Robo、FlagScaleとシーン上重複しており、将来「メンバー単位が先に上流フレームワークへ合入し、その後FlagOSがバックエンドを統一収口する」リレーが出現するかは追跡に値する手がかりである。
  • 摩尔線程が訓練基盤をオープンソース化、コードと叙事は分けて見るべき（10-28）：Megatron-MUSA-Titanは万卡級クラスタ向けの万億パラメータMoE訓練を対象とし、事前訓練と強化学習をカバー、blockwise FP8をサポートし、DeepEPとACE非同期通信を組み合わせて専門家並列と計算オーバーラップを行い、slime、milesと協調可能（Megatron訓練+SGLangサンプリング）。リポジトリは存在するが本調査期間内にプッシュはなく、最終プッシュは10-16であり、「オープンソースを宣布、コードは未動」に属し、ニュースリリースの「オープンソース」表現とは時間的に分けて見る必要がある。同日発表されたのはほかに第3四半期報告（売上15.5億元、前年同期比1773.9%増、前三季度売上32.89億元、帰母純利益3769.73万元、

また香港株式市場への二次上場を推進中）、決算は技術的判断を変えないが、そのオープンソースのリズムへの投入能力を説明している。

  • 天数天垓 300 初の実機デモ、ハードウェア仕様は依然として検証可能な条件を欠く（10-28）：同社は上海メディアオープンデーで天垓 300 汎用 GPU を初めて実機展示し、英偉達（NVIDIA）H200 水準の実測性能に達した初の国産汎用 GPU と称し、第三者のテスト換算で単カード全体スループットは H200 の 1.05 倍、さらにテキストtoイメージ、テキストtoビデオなどの複雑なマルチモーダルタスクで H200 を上回った。この数字は同社の主張であり、テスト方法、使用モデル、ワークロード条件はいずれも公表されておらず、検証できない。ソフトウェアスタック側の対応作業は継続中である——FlagCX は Device API の取得セマンティクスを補完し、SGLang 0.5.18 の Empty ランタイム適配は審査中、multi_tensor_adam は既に天数をサポート対象バックエンドとしてリストに挙げている。
  • チャネル検証：ニュース面は連続4調査期間、メンバー単位の通稿のみ（10-23 ~ 10-29）。5期分のデイリーレポートで計120組の中英語クエリ（各期24組）を実施し、コンポーネント名の直接検索（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）は中英語合計で引き続きゼロヒット。5期合計の有効項目は8件：Google News 側6件——InfoQ の2.2振り返り（10-24）、沐曦と摩尔線程の MiniMax M3.1 Flash Day-0 通稿（10-23）、清微 Open3D-PIMC（10-26）、沐曦 RLinf（10-26）、摩尔線程 Megatron-MUSA-Titan（10-28）；コミュニティ独自チャネル2件——MiniCPM-OCR デュアルモデル Day0 適配記事（10-29 11:19）と sglang-plugin-FL 技術ライブ配信（10-29 19:00）。CSDN FlagOS コラムは 10-22 の更新停止後、10-29 に再開；HN Algolia の8組クエリは4日間の調査期間内で直接ヒットゼロ；智源コミュニティ検索ページはクライアントサイドレンダリングのため、フレームページのみ取得；8社のメンバー単位公式サイトの7日間巡回ではわずか4件（摩尔線程 4K ポストプロダクション網、第3四半期報告図解、沐曦 CNCC 2026 分科会振り返り、およびソフトウェアスタックと無関係な業界実装稿1件）；収録待ちキューには本期間 FlagOS 項目なし。

6. トレンド観察

  • 2.3のボトルネックはすでにコードになく、「リリースが自らを証明できるか」にある：今サイクルで最も密集した一連の作業は新しいオペレータではなく、ゲート、痕跡記録、撤回、整合性チェックである——changelogは「人手の記憶」からプッシュゲートへと変わり、サイトページとHarborへ反映され、アプリケーションページの整合性チェックはpre-commitに接続され、一度もプッシュされていない2件のミラーは撤回され「changelogファイル集合が公開済み集合と等しい」状态にされた。これらのアクションは能力を生み出さないが、12-30より前のそのリリース一覧が外部から照合できるかどうかを直接左右する。現状はビルド面がすでに2.3.0で計上しており、リリース一覧はなお空であり、11-13のFEP締切と11-30のrc0がrc期間全体を圧迫する。
  • バックエンドマトリクスは2.3サイクルで収束せず拡張を続ける：AMD ROCm 7.2.4は1枚のベースイメージから完全なバックエンドへと成長し、地平線BPUは「設計上eagerにできない」状態からオペレータごとの実行が可能になった。両者の共通点は「接続してから初めて必要になる」後続作業が極めて重いことだ——AMDはビルダーとwheel行を補う必要があり、BPUは配布ログ、コピーカーネルのガード、ベンダー名マッピングを補う必要があり、新バックエンドの最初のハードルは常に「動くこと」であり「より速いこと」ではない。
  • Day-0デリバリは「動くかどうか」から「統一フォーマットでの一括複製」へと移行し、次の勝負手は基準の統一にある：1週間で2度の9チップ同時リリースがあり、今回はW8A8単一パスへと統一し、4社をExpress版にしたことは、リリースパイプラインがテンプレート化されたことを示す。MiniCPM-OCRの説明はさらに一歩進み、実スループット比、ピークで正規化したスループット比、端側レイテンシを分けて述べ、前提を明記した——これは単一の倍数よりも参考価値が高く、次のラウンドで同業者が同じ基準で比較しやすい。
  • オペレータ供給の自動化後、人手の投入はすべて正確性と契約へ向かう：KernelGenの1日22オペレータ、1週間に複数バッチの自動生成はすでに常態である。これに対し、今週最も価値ある一連のコミットはindex_putのint32オフセット溢れ、天数bf16 GEMMのホストへのフォールバック、海光DCUランタイムがスタブリンクで構成されていること、燧原の形状表ロードポイント欠落、昆仑芯バックエンドがインポートできないといった「テストではエラーが出ず、リリース後に炸裂する」問題である。ref-as-candidateの両リポジトリでの実装と57件のテスト修正は、「何をテストするか」をオペレータの有無から参照と実装の一致へと変える分水嶺である。
  • ルール収束のコストは0.32での実現に先送りされた：0.28スキップは小バージョンを追うコストを一見压し込んだが、0.28ですでにマージされた適配（燧原S60、天数、沐曦、清微、昆仑芯）は0.32で再検収が必要であり、この手戻り量を現在担うPRは存在しない。同期間の0.32の最初の実装証拠はネイティブCUDAのvLLM 0.32適配（vLLM 0.32.0にcu129、PyTorch 2.13.0、Python 3.12.3を固定）であり、国産バックエンドはまだ着手していない。
  • 量子スタックとマルチチップ適配は完全に分離し、独立した主線となる：FlagQuantumは1週間で226件をマージし、組織の3割を占め、構造再編（QECパッケージ分割、Quafu SDKのハードスイッチ）からシナリオ展開（誤り訂正符号、中性原子、熱浴）へ、さらにCS-01からCS-07の回路合成パイプラインへと収束した。FlagQAIは同時にローカルワークベンチを構築。その作業方式は4段階の証跡記録であり、コストは高いが検証可能性が高く、チップベンダーの進捗に依存しない唯一のソフトウェアスタック主線でもある。
  • 3つのリスク項目は次号での確認が必要：第一に、タグにリリース本文が欠けるのが慣例化している——FlagCX v0.14.1とFlagTreeの2つの3.6専号はいずれもタグのみで、下流は名前からバックエンドとTritonバージョンを逆算するしかなく、2.3がこの路線でデリバリされると照合コストが増える。第二に、寒武紀は2週連続で組織内に専用プッシュがなく、build-infraに撤回記録が残るのみであり、次号も続くなら別掲すべきである。第三に、学習スタックの回復はなお不確実である——Megatron-LM-FLは10件を審査中だが今サイクルのマージはゼロ、FlagScaleのDeepSeek-V4上流同期は[2/N]までしか開いておらず、学習側の進捗は推論側に遅れている。
  • 次の観察ポイント：2.3.0タグがいつ打たれるか、release-2.3.yamlがいつ確立されるか；0.32単発ルール下で最初の国産バックエンド（昇騰または海光）がいつ0.32で検収を完了するか；BPUパスが逐次オペレータから畳み込みなどの幹オペレータへ拡大するか；FlagCVがいつ最初のベンチマークと非GPUバックエンドデータを出すか；Megatron-MUSA-Titanのコードが実際にプッシュを開始し、Megatron-LM-FLと再利用関係を形成するか。

付録：素材と照合

  • 素材：2026-10-26、10-27、10-28、10-29、10-30 の5期分のFlagOSデイリーレポート。調査期間はそれぞれ10-23 06:00から10-26 06:00（72時間）、10-26 06:00から10-27 06:00、10-27 06:00から10-28 06:00、10-28 06:00から10-29 06:00、10-29 06:00から10-30 06:00で、期間内に欠落はない。10-24と10-25は週末のため独立したデイリーレポートはなく、その内容は10-26期の72時間ウィンドウに含まれる。
  • GitHub確認方法：組織flagos-aiの全61リポジトリについて日次でプッシュ状況を確認した。マージ済みはis:mergedにmerged:>=窗口起点を付けて検索した結果を真値とし、審査中はis:openにupdated:>=窗口起点を付けて検索した。メインブランチの新規追加はcommits?sha=<分支>&since=<UTC>で再確認した。非デフォルトブランチへのプッシュはorgイベントストリームとcommits.atomで補完的に判別した（本期間はdocs、release-info、FlagFFT、FlagSparse、FlagGems-Experimental、TransformerEngine-FLなどのリポジトリが該当）。リポジトリ別のマージ数は各期デイリーレポートの開示基準の累計であり、各期のリポジトリ別合計と各期のマージ総数は完全に一致し、累計755件であった。
  • バージョンとタグの確認：各コンポーネントリポジトリのタグとReleaseのアトミックソースで逐一再確認した。10-31の再確認結果は次のとおり——FlagTree 0.7.1a1+mthreads3.6のtagger時刻は10-26 10:13、0.7.1a1+tsingmicro3.6は10-29 11:09で、いずれもRelease本文はない。FlagCX v0.14.1は軽量タグで、10-29 10:55のマージコミット（昆仑芯 cstddef 回摘）を指し、Releasesリストの最新項目は依然として9-28のv0.14.0である。build-infraのタグリストの最新は依然としてv2.2.0である。communityリポジトリのrelease/2.3ディレクトリ下にrelease-2.3.yamlはない。FlagGems、FlagQuantum、FlagScale、FlagBLAS、FlagDNN、FlagFFT、FlagTensor、FlagAttention、vllm-plugin-FL、sglang-plugin-FL、FlagGems-sglang、TransformerEngine-FLは本期間に新規Releaseはない。
  • ニュース側の確認：Google News RSSの24組の中英語クエリ語（コンポーネント名は14日、メンバーと産業語は7日）を各期実行し、5期合計で120組のクエリを実施した。HN Algoliaは8組。CSDNのFlagOSコラムは逐条で時刻を確認した。智源コミュニティと8社のメンバー単位の公式サイトを毎日巡回した。有効項目は「原サイト優先」で引用した。旧聞の再掲（燧原の「本日上場」類の記事、同社の科創板上場日は9-11）、期間外の記事（清微の「年度科創先鋒」原文は10-22）、会議後の拡散記事（輝羲智能の参会記事、10-17から10-18の大会を指す）と相場・決算類の記事は規則により除外し、項目に計上していない。
  • 基準の説明：日付と時刻はすべて北京時間である。月曜日の72時間ウィンドウは10-24と10-25の週末をカバーし、その内容は元の日付で标注され、前回のウィークリーレポート（10-19から10-23をカバー）とは10-23当日に重複があり、重複部分のタグとマージは前回で既に列記済みのため、本期では重複計上しない。「マージ」とはGitHub検索のマージ時刻がウィンドウ内に落ちるPRを指し、デイリーレポートの日次ウィンドウ計数とは1日程度のずれがあり、本レポートは統一してマージ日基準を採用する。コミット検索はsearchのtotal_count基準で、一部のリポジトリではスクワッシュマージとインデックス遅延によりマージ数がコミット検索数を上回る場合がある（例：10-27期のFlagGemsは49件のマージに対し28件のコミット）。レポート内ではマージ数を基準とする。ベンダーのプレスリリースにおける「Day-0」「コード変更不要」「論文に匹敵または超過」などの表現は会社側の基準であり、第三者による再現は得られていない。天垓300のH200に対する1.05倍とInfoQのコスト試算はいずれも限定条件を明記している。
  • 限界：ブランチレベルの活動（FlagTreeのtriton_v3.5.xとfeature/flagmegaブランチ、FlagGemsのkernelgen-devとfix/*一時ブランチ、FlagFFTのcodex/musa-shortfall）はデフォルトブランチ基準では完全に列挙できず、デフォルトブランチで統計すると実際の作業量を過小評価する。FlagQuantumのコミット数はマージコミットとブランチ同期コミットを含み、機能変更数とは異なる。FlagGems-Experimentalの135件のバッチPRは本期間末時点ですべて審査中であり、バッチマージされるか、マージ後にメインリポジトリのオペレータ表へ還流するかは依然として観察が必要である。学習側のMegatron-LM-FLとFlagScaleの動きは疎であり、関連する判断の信頼度は推論スタックより低い。

参考文献

//github.com/flagos-ai/FlagCX/pull/673> · https://github.com/flagos-ai/build-infra/pull/1556 · https://github.com/flagos-ai/build-infra/pull/1563

· https://github.com/flagos-ai/FlagGems/pull/7061 · https://github.com/flagos-ai/FlagGems/pull/6950

** FlagQuantum パッケージ再編と Quafu 切り替え — https://github.com/flagos-ai/FlagQuantum/pull/749 · https://github.com/flagos-ai/FlagQuantum/pull/832 · https://github.com/flagos-ai/FlagQuantum/pull/866 · https://github.com/flagos-ai/FlagQuantum/pull/876