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

情報源：GitHub（org: flagos-ai 61 リポジトリ全量核查、コミット検索 99 件、マージ済み PR 67 件と審査中 PR 288 件の検索、org イベントストリーム 100 件、31 リポジトリの Release/Tag 原子核查、7 リポジトリの原子補核、主要 PR 本文と成果物規模の核查）、Google News RSS（24 組の中英語クエリ語、プロキシ経由）、HN Algolia（8 組）、CSDN FlagOS コラム、智源コミュニティ、8 社のメンバー企業公式サイト（詳細は付録の情報源リストを参照）。

本期インデックス

  • 今日の重点：地平線 BPU を eager オペレータバックエンドとして接続；FlagCX が v0.14.1 タグを打ち三家の rpm バックエンドを補完；摩尔線程が Megatron-MUSA-Titan をオープンソース化（10-28）
    1. オープンソースプロジェクト進展（GitHub 動向）
      • 1.1 組織リズム：23 リポジトリプッシュ、99 コミット、67 マージ、審査中は 288 件に回落（10-28 ~ 10-29）
      • 1.2 バージョン面：FlagCX が v0.14.1 を打ち、デバイスビットコードをアダプタごとに生成する方式に変更（10-28）
      • 1.3 FlagGems：崑崙芯のスカラーチェーン融合で十倍高速化、燧原の参照実装で一括修正が審査中（10-28）
      • 1.4 FlagGems-sglang：AMD gfx1100 に Mamba オペレータを補完、燧原の core_shapes が実際に有効化（10-28）
      • 1.5 コンパイラ：FlagPrism が燧原に接入、昇騰 TensorView の取得・保存を削減、FlagMega が RDNA デコードを高速化（10-28）
      • 1.6 推論・学習スタック：燧原 Qwen3.5 FP8 を GCU 上で、融合全帰約 RMSNorm が FlagGems-vllm に（10-28）
      • 1.7 ビルドとリリース：changelog のサイト掲載と Harbor、未プッシュの寒武紀イメージ 2 件を撤回（10-28）
      • 1.8 ルール面：FEP-0140 を Implementable に移行、FEP-0141 は SGLang 0.5.18 に絞り込み（10-28）
      • 1.9 その他リポジトリ：optest が燧原 CI に接入、FlagTensor 昇騰常駐グリッド、FlagQuantum 置位一致性（10-28）
    1. 報道とエコシステム
      • 2.1 報道面：摩尔線程が Megatron-MUSA-Titan をオープンソース化、24 組のクエリで有効なのはこの 1 件のみ（10-28）
      • 2.2 チャネルと公式サイト：CSDN は依然 10-22 で停止、HN と智源コミュニティに新規ヒットなし（10-28）
    1. メンバー企業とバックエンドベンダーの深掘り
      • 3.1 地平線：BPU が初めてオペレータ単位で実行可能な PrivateUse1 バックエンドに（10-28）
      • 3.2 崑崙芯：スカラーチェーン融合と連続セグメントカーネル、P800 上の 3 か所の高速化（10-28）
      • 3.3 天数：畳み込みが工况档位表を経由、conv3d はチャネルゼロ埋めを除去（10-28）
      • 3.4 燧原：Qwen3.5 FP8 を GCU 上で、core_shapes の落帳、FlagPrism 初回接入（10-28）
      • 3.5 達摩院玄鉄：PPU 上の MiniMax 疎注意力、幾何平均 1.8 倍（10-28）
      • 3.6 清微、曦望、海光：FlagCX の rpm パッケージで三家のバックエンドを補完（10-28）
      • 3.7 摩尔線程：Megatron-MUSA-Titan のオープンソース化と第三四半期報告が同日（10-28）
    1. まとめとトレンド観察
  • 付録：情報源核查表と完全な情報源リスト

今日の重点：地平線 BPU を eager オペレータバックエンドとして接続；FlagCX が v0.14.1 タグを打ち三家の rpm バックエンドを補完；摩尔線程が Megatron-MUSA-Titan をオープンソース化（10-28）

日付：2026-10-28　出典：Torch-FL PR #674 · FlagCX tag v0.14.1 · FlagCX PR #673 · IT之家報道 · Megatron-MUSA-Titan リポジトリ（全量は付録を参照）

  • 新バックエンド面：Torch-FL が地平線 BPU の演算子単位実行層をマージ（#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 と比較して差異ゼロを確認。
  • バージョン面：FlagCX が 10-28 17:25 に v0.14.1 タグを打った（commit 7ed4a82、タイトルは「アダプタごとにデバイスビットコードを生成、NVIDIA をハードコードしない」、すなわち 10-18 にマージされた #668）。このタグは git tag のみで GitHub Release 本文はなく、前版 v0.14.0 の正式 Release は 9-28 で止まっている。同じアーカイブには v0.15.0.dev0 タグも見える（本調査期間より前）。同期間に 0.14.0-rc2 ライン向けの花開きパッチ（#683、審査中）。
  • パッケージ面：FlagCX の rpm ラインが 3 バックエンドから 6 に拡大（#673、10ファイル、+295行/-8行）。新規追加の libflagcx-tsm（清微）、libflagcx-sunrise（曦望）、libflagcx-du（海光 DCU）の 3 社はいずれもベンダー基礎イメージを必要としない——SDK を /opt または /usr/local に展開し、パッケージマネージャを呼び出さないため、openEuler イメージにファイルリポジトリを加えるだけで完全なビルド環境となる。ベンダー soname は昇騰の既存基準に合わせて統一フィルタリング。
  • ニュース面：摩尔線程が 10-28 に大規模モデル訓練基盤 Megatron-MUSA-Titan のオープンソース化を発表。万カード級クラスタの兆パラメータ MoE 訓練に焦点を当て、事前訓練と強化学習をカバー；すでに同社の万カードクラスタの事前訓練で継続使用されており、blockwise FP8 をサポートし、DeepEP と ACE 非同期通信を組み合わせてエキスパート並列と計算オーバーラップを実現、slime、miles 強化学習フレームワークと協調可能。リポジトリ MooreThreads/Megatron-MUSA-Titan は GitHub 上に存在するが、本調査期間内にプッシュはなく（最終プッシュ 10-16）、「オープンソースを発表、コードは未稼働」の状態。
  • 判断：3 つのラインがそれぞれ一層ずつ前進——新チップを eager パスに接続（BPU）、通信ライブラリのデリバリー面をソースツリーからタグと配布パッケージへ（FlagCX）、訓練スタックのオープンソースナラティブを FlagOS からメンバー単位の自社研究プロジェクトへ拡大（Megatron-MUSA-Titan）。本スタックに直接関連するのは前 2 つ；3 つ目はそのコードが FlagOS で再利用可能な訓練コンポーネントとして還流するかどうかを観察する必要がある。

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

1.1 組織のリズム：23 リポジトリのプッシュ、99 コミット、67 マージ、審査中は 288 に減少（10-28 ~ 10-29）

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

  • リポジトリ面：61 リポジトリのうち 23 リポジトリに期間内のプッシュがあり、直近2週間で最多（前回 20 リポジトリ）。プッシュ時刻の新しい順に docs、Trident、FlagQAI、Torch-FL、build-infra、FlagGems、FlagCX、FlagTree、release-info、FlagFFT、FlagGems-sglang、FlagQuantum、optest、FlagDNN、vllm-plugin-FL、FlagTrain、community、FlagGems-vllm、FlagAttention、sglang-plugin-FL、TransformerEngine-FL、FlagTensor、FlagGems-Experimental。
  • コミット面：コミット検索のヒットは 99 件、リポジトリ別では FlagQuantum 33、FlagGems-sglang 17、FlagGems 10、build-infra 6、optest 5、FlagGems-vllm 5、Torch-FL 4、FlagTree 4、FlagCX 3、community 3、FlagTensor 3、FlagDNN 2、sglang-plugin-FL、vllm-plugin-FL、FlagTrain、FlagAttention が各 1。
  • マージ面：マージ済み PR は 67 件、リポジトリ別では FlagGems 13、FlagGems-sglang 8、FlagTree 7、build-infra 6、FlagQuantum 6、optest 5、FlagGems-vllm 5、Torch-FL 4、FlagCX 3、community 3、vllm-plugin-FL 2、FlagTrain、FlagAttention、sglang-plugin-FL、TransformerEngine-FL、FlagTensor が各 1。
  • レビュー中面：期間内に更新のあったレビュー中 PR は 288 件、新規作成は 101 件。FlagGems 181 件（新規 53）、FlagTree 21 件（新規 9）、FlagGems-vllm 20 件（新規 9）、vllm-plugin-FL 12（4）、FlagCX 8（2）、FlagTrain 7（2）、Torch-FL 6（5）、sglang-plugin-FL 5（2）、Trident 3（3）、flir 3（1）、FlagAttention 3（1）、Megatron-LM-FL 3（0）、FlagGems-sglang 3（3）、TransformerEngine-FL 3（1）、その他の各リポジトリは 1 から 2 件。
  • ペース比較：直前の 24 時間期間（20 リポジトリ、102 コミット、98 マージ、401 レビュー中、269 新規）と比べ、プッシュされたリポジトリは 3 増、コミットはほぼ横ばい、マージは 32% 減、レビュー中は 28% 減、新規は 62% 減。前回のレビュー中の急増は FlagGems-Experimental の一度に 135 件のバッチコミットによるもので、今回は同リポジトリに新規もマージもなく、レビュー中は通常の範囲に戻った。
  • リリースとイベント面：31 リポジトリの Release と Tag をアトミックに照合し、期間内に追加されたタグは 1 件（FlagCX v0.14.1）。build-infra の最新タグは依然として 8 月 3 日の v2.2.0。org イベントストリームは 100 件：プッシュ 51、ブランチ作成 32、ブランチ削除 9、PR レビューとレビューコメント 8、PR の作成・クローズイベントはなし——イベント構成はブランチ活動が主体で、FlagGems 側の多数の fix/suiyuan-*、fix/blocked581-* 一時ブランチの作成と削除と一致する。
  • ブランチ面：コミット検索がカバーしていない 7 つのプッシュ済みリポジトリはアトミックに追加照合が必要。TransformerEngine-FL は commits.atom により期間内のコミット 1 件（#150、10-28 16:33）を確認。FlagFFT と release-info は非デフォルトブランチへのプッシュ（FlagFFT 側は codex/musa-shortfall、codex/cuda-2d3d-opt）。FlagGems-Experimental のプッシュは dependabot ブランチから。docs、FlagQAI、Trident の 3 リポジトリのプッシュはいずれもフィーチャーブランチ上で、デフォルトブランチに新規コミットはない。

1.2 リリース面：FlagCX が v0.14.1 を打出、デバイスビットコードをアダプタごとの生成に変更（10-28）

日付：2026-10-28　情報源：FlagCX tags · FlagCX v0.14.1 タグ · FlagCX PR #668 · FlagCX PR #683 · build-infra PR #1546

  • タグの事実：v0.14.1 は 10-28 17:25 に打たれ、commit 7ed4a82 を指し、コミットタイトルは「アダプタごとにデバイスビットコードを生成し、NVIDIA をハードコードしない」（#668、10-18 マージ）。Releases API でこのタグを検索すると 404 が返り、単なる git タグであって GitHub Release は作成されていないため、リリースノート本文は存在しない。前版 v0.14.0 の正式 Release は依然 9-28 にあり、本文は FlagOS 2.2 リリースリストを指している。
  • 内容面：#668 は setup.py のビットコード手順でハードコードされていた bindings/ir/nvidia を、アダプタごとのテーブル参照（BITCODE_MAKEFILES）に置き換え、各アダプタが自身の Makefile とアーキテクチャ変数を宣言するようにした。従来は非 NVIDIA アダプタでは RuntimeError が発生するか、ビットコードが無言で出力されず、FlagTree の iluvatar バックエンドは FlagCX のソースをコピーして独自に再ビルドするしかなく、FlagCX が本来生成すべきビットコードを利用できなかった。
  • 付随面：build-infra ではボットが flagcx wheel のリリースを記録し（#1546）、wheel の配布とタグ、パッケージングラインを一本につないだ。同じ調査期間に開かれた #683 は昆仑芯の cstddef 修正を 0.14.0-rc2 ラインにバックポートしており（レビュー中）、0.14 シリーズが依然サポート期間内にあることを示している。
  • 要注意：v0.14.1 には Release 本文がなく、v0.14.0 の「本文がリリースリストを指す」やり方と一致していない。今後の 2.3 サイクルが v0.14.x で配布される場合、下流がタグだけから内容を推測することを避けるため、説明を補足することを推奨する。

1.3 FlagGems：昆仑芯スカラーチェーン融合が10倍高速化、燧原参考実装の一括修正がレビュー中（10-28）

日付：2026-10-28　情報源：FlagGems PR #7617 · FlagGems PR #7600 · FlagGems PR #7850 · FlagGems PR #7803 · FlagGems PR #7036 · FlagGems PR #7061 · FlagGems PR #7223

  • 融合カーネル：昆仑芯 XPU3 側では8つの出位スカラーチェーン・オペレータにバックエンド特化を追加（#7617、275行）。同構の float リストは1つの融合カーネルを通る：小形状は単一回発射、すべてのポインタをカーネル引数として持ち込み、大形状はストリーミング分割。出力は1回のアロケーションと unbind から得られ、テンソルごとにアロケータを呼ぶのではない。8つのオペレータの相対所要時間は 0.083~0.126 から 0.813~0.934 に向上、すなわち約7~10倍。
  • 連続セグメント・カーネル：batch-norm 推論と QKV 変換の2つのオペレータを「各 (n,c) スライスごとに1 program」から「各 program が連続する BLOCK 要素の1セグメントを処理し、平坦インデックスからチャネルまたはパッキング行を逆算」へ変更（#7600）。集計指標はそれぞれ 0.228 から 1.357、0.260 から 5.062 に向上；fp32 単精度のセルは依然 0.8 未満で、著者は集計口径で判定し、本文に明記している。
  • ベクトル化修正：masked_fill の整数ビューのファストパスは arith.extsi にベクトル形式がないためカーネル全体がスカラーのまま（fp16 0.34、fp32 0.50）。x*(1-m)+V*m の f32 形式に書き換えた後、P800 上で 0.577 から 0.829 に向上し、masked_fill_、masked_fill_scalar も同時に恩恵を受け、594 のテストケースが通過（#7850）。
  • インポートとエグゼキュータ：昆仑芯バックエンドは master の最新コミット上で直接インポートに失敗——_result_dtype ヘルパーは #7561 で共有エグゼキュータから削除済みだが、バックエンドがまだ参照していた（#7803、90行）；インポート修正後、共有エグゼキュータが operand #0 does not dominate this use を報告し、本コミットで併せて修正。
  • オペレータカバレッジ：KernelGen が _indices_copy を補完（#7223、250行、H20 で検証）、ただし性能は torch の 0.21 倍のみ——カバレッジ補完の産物であり、短期的に加速項目とは見なせない。lighting_indexer の参照実装をヘッドごとの累積に変更し、ピークメモリを約 8.6 GiB から低減、40 GiB カード上の OOM を修正（#5852）。
  • レビュー側：本調査期間に新規 53 件、多くは lukatao の燧原参照実装修正（#7890 から #7908 連番）で、Kaiser/inplace ldexp、aminmax、special_round、LU、vander/slogdet、median/stacking/Lanczos、Adagrad、batch-norm ABI などに関わる；ほかに AMD 側の1行修正（#7908）——AMD のベンダー記述子がデバイス名を cuda に設定し triton_extra_name を付与していないため、pow、tanh、exp、rsqrt、erf、gelu などがすべて __nv_* を通り AMD バックエンドに拒否される。

1.4 FlagGems-sglang：AMD gfx1100 に Mamba オペレータを補完、燧原 core_shapes が実効化（10-28）

日付：2026-10-28　情報源：FlagGems-sglang PR #231 · PR #232 · PR #229 · PR #233 · PR #237 · PR #236

  • AMD 側：RDNA3 向けに causal_conv1d_fn、chunk_state_varlen、bmm_chunk の 3 つの gfx1100 バージョンを追加（#231、578 行）し、Radeon PRO W7900D 上でチューニングとテストを実施。3 つとも発射パラメータのみを変更し、出力は汎用カーネルとビット単位で一致。タイムスライスは最長シーケンスに追従し、固定の 128 token×4 チャネルではなく、dstate 128 以上ではより小さなタイルと 16 token の K ステップに変更。
  • 燧原側：#229 で _enflame/core_shapes.yaml を追加したが、リポジトリ内にこれを読み込むコードが存在しない——init_user_config() にはハードコードされた kunlunxin 分岐しかない（#232 の根本原因分析）。#232 では形状ファイルの検索を「vendor_name から _<vendor>/core_shapes.yaml を導出し、存在すれば使用、なければ共有デフォルトにフォールバック」に汎化し、併せて kunlunxin パスが無条件に設定され、ファイルが存在しないと FileNotFound になる潜伏問題も修正。
  • テスト基盤：候補注入を正確性テストとベンチマーク間で統一（#233、9 ファイル）。独立ベンチマークセッションはこれまで --override を登録しておらず、候補専用モードは存在しないレジストリメソッドを呼び出していた。get_override() は実際の候補を公開し、通常の計時、プリチェック、プロファイリングが同じパーサーを共有。さらにケースごとの dummy 候補呼び出し検証（#237）とパッケージレベルのインポート修正（#236、sys.modules の衝突を回避）を追加。
  • ケース列挙：silu ベンチマークがテンソルなしでのケース列挙と正確なリプレイに対応（#234）。--list-cases はページングで 238 件のマージ收尾まで対応。
  • 判断：このリポジトリは本調査期間で 17 コミット、8 マージであり、すべてが「ベンダー形状テーブルと候補注入をマルチバックエンド下で同じ言葉で語らせる」ことを中心としており、テスト口径の収束であって新規オペレータではない。

1.5 コンパイラ：FlagPrism が燧原に接続、昇騰 TensorView のロード/ストア削減、FlagMega が RDNA デコードを高速化（10-28）

日付：2026-10-28　情報源：FlagTree PR #1239 · FlagTree PR #1426 · FlagTree PR #1439 · FlagTree PR #1456 · FlagTree PR #1454 · flir PR #86

  • 分析とデバッグ：FlagPrism のデバッガとプロファイラを燧原バックエンドへ拡張（#1239、5ファイル、119行追加・31行削除）。CMake と Python 側で燧原をサポートリストに追加してデフォルトで有効化し、明示的な無効化項目と Proton との相互排他を維持。実行時はデバッグ付きカーネル発射を FlagPrism ゲートウェイ経由に変更し、メタデータ取得と隠蔽された制御バッファ引数を分けて処理、通常実行は依然として直接発射パスを通る。
  • IR とロード/ストア：昇騰バックエンドに TensorView アクセスパスを接続（#1426、32ファイル、4901行追加、triton_v3.5.x ブランチへマージ）。カーネルは3種の明示的コンストラクタでベースポインタ上にエンコードビューを構築し、インデックスに従ってブロック単位でロード/ストア。範囲外チャネルは zero/nan/inf/-inf で補完するか破棄し、バックエンドは CommonIR から HIVM の間でインデックスパターンに基づき「インデックス別ペイロード DMA」または「要素ごとのゼロ補完転送」を選択する。
  • AMD デコード：FlagMega 側で Qwen3-1.7B bf16 の batch-1 デコードを最適化（#1439、44ファイル、feature/flagmega ブランチへマージ）。R9700（gfx1201）はコンテキスト1で154 tok/s、1Kで150、4Kで139、8Kで125。W7900（gfx1100）はそれぞれ167、162、149、136 tok/s、実測帯域530~597 GB/sで、同カードの実測ストリーミング上限の82%~87%に達する。
  • 正確性：AMD バックエンドの CanonicalizePointers はアサートを廃止し、arith.select の fat-pointer 属性をマージするよう変更（#1456）。RLC 側はレイアウト変更が不正または安全でない producer に再ラベル付けしなくなった（#1454）。
  • CI とレビュー中：FlagGems の CI 資産を FlagTree へ移設（#1443、#1447）。レビュー中は新規9件、うち清微バックエンドを内部 Triton 3.6 開発ラインへ同期（#1459、27ファイル、2264行追加、発射ごとの精度 API と CoreIR エントリを含む）、rpm ラインを公開済み wheel を消費して昇騰パッケージを構築するよう変更（#1461、初のベンダー SDK とハードウェア不要のライン）、NVIDIA Hopper 上のソフトウェアパイプライン4件の欠陥修正（#1460、cp.async にエビクション戦略を付けると ptxas 12.8~13.1 で未定義アドレス記述子が残る）、昇騰の構造化置換と常駐ループ性能（#1466）、P800 SDNN の一次元モジュロロード（#1465）、flir の昇騰 split/join と静的置換の低減（#86）。

1.6 推論と学習スタック：燧原 Qwen3.5 FP8 を GCU 上で、融合全帰約 RMSNorm を FlagGems-vllm へ（10-28）

日付：2026-10-28　情報源：vllm-plugin-FL PR #358 · PR #525 · FlagGems-vllm PR #773 · PR #1017 · TransformerEngine-FL PR #150

  • 燧原推理：GCU バックエンドに Qwen3.5 FP8 サポートを追加（#358、20 ファイルで 3367 行追加、release/0.2 をベース）。W8A8 ブロックキャリブレーション FP8 推論を導入し、GCU300/GCU400 のハードウェア制約に合わせてカーネルパッチを作り直すことで、FP8 MoE モデルを eager と 全グラフの両モードで実行可能にした。
  • 通信配線：vLLM プラグインを、インストール済みパッケージから FlagCX を取得するよう変更（#525、11 ファイル）。flagcx wheel は ctypes ファサードを flagcx.api としてインストールし、libflagcx.so をパッケージ内の lib/ に配置する。wheel のみをインストールした環境には FLAGCX_PATH が指すソースツリーが存在しないため、本コミットでは flagcx.api を優先インポートとし、FLAGCX_PATH ラッパーをフォールバックとする。呼び出し箇所 3 箇所（flagcx.py、flagcx_connector.py、sunrise/patch.py）を同時に変更。
  • オペレータ面：FlagGems-vllm に融合全リデュース RMSNorm を追加（#773、6 ファイルで 3191 行追加）：all-reduce + 残差加算 + RMSNorm、オプションの静的量子化（FP8、SM100+ は NVFP4 をサポート）、TP2/TP4/TP8 の FP16/BF16 をサポートし、vLLM FlashInfer 実装との比較ベンチマークと GLM-5.2 の代表形状を添付。ihc_pre の stage1 統合では tl.atomic_add を split スロット単位の書き込みに置き換え（#1017）——アトミック加算は結果がブロックの到着順に依存し、重複発射時にビット単位で一致しないため、変更後に決定性が回復。
  • 依存関係とリグレッション：TransformerEngine-FL は 3rdparty/ の 3 つのサブモジュールを上流 v2.17 の検証ベースラインにロールバック（#150）：#129 が誤って cutlass を 240 コミット分前進させ（4000+ ファイルに影響）、cudnn-frontend を v1.25.0 から未リリースのスナップショットに進め、googletest を v1.14.0 から master ヘッドに進めていた。
  • 訓練側：FlagTrain に FlagOS テストスイートの KMCompiler 設定を追加（#37）。審査中の 7 件は依然として各ベンダーの KMCompiler オペレータ（scaled_masked_softmax、fused_proj_rms 順伝播・逆伝播、bias_swiglu、fast_gelu、moe_gemm、tanh_soft_clamp）。

1.7 ビルドとリリース：changelog の公開と Harbor、未プッシュの寒武紀イメージ 2 件を撤回（10-28）

日付：2026-10-28　情報源：build-infra PR #1545 · PR #1547 · PR #1548 · PR #1549 · PR #1542 · PR #1543

  • 変更履歴の公開：各ミラーの changelog がサイトページ末尾に表示されるようになり、Harbor リポジトリの説明としても三層リリース（#1545、455 ファイル、19080 行追加）に含まれるようになった。従来 changelog はリポジトリ内にのみ書かれ、消費者がいなかったため、サイトページ、リポジトリ内 readme、Harbor 説明のいずれもこの部分を欠いており、アプリケーション層には説明行すらなかった。ブロックは「本文に随時レンダリングするのではなく再計算する」方式で実装：ページ本文にはそれぞれ生成器とリズムがあり、本文に随時出力されるブロックは最終行で上書きされ、途中に書かれた理由が失われる。空の保留項目と upstream_prs は公開しない。同じ調査期間内にまず理由を中英二言語化（#1542）。
  • 存在しないミラーの撤回：Harbor には megatron_training0.18.2-cambricon-neuware4.7.2 と megatron_rl0.18.2-cambricon-neuware4.7.2 の二つのリポジトリが存在しないが、0.18.2 の二つの状態マトリクスはいずれも image_tag: 2.2.0-0.3.0 を記録していた（#1547、13 ファイル、29 行追加、496 行削除）。このタグはマトリクスを初めて構築したコミットに由来し、記録ステップで書かれたものではない。そのためドキュメントパイプラインが二つの存在しないミラー向けに起動ページ、readme、changelog を生成し、以後 pubdoc-app のたびにこの二つのリポジトリで 404 が発生した（残り 107 個は説明の PUT を受け入れた）。
  • ミラーをプッシュできなかった根本原因：0.18.2 の wheel では platform_register に MLU プラットフォームがなく、torch_mlu の gpu_migration が CUDA サーフェスを MLU にエイリアスした後、選択されるのは PlatformCUDA であり、パイプライン並列グループが初期化されなかった。MLU 登録（MLF #125、#188/#190/#191 を含む）は release/0.2 にのみ存在し、v0.3.0、0.3.0-rc2、main には当該ファイルもなく、移植作業も進行中ではなかった。対応は主張を撤回することであり、無理に埋め合わせることではない：二つのバックエンドの image_tag を削除し、launch_docs: false とし、同時にこれら二つの changelog を削除し、「changelog ファイル集合 == 公開済み集合」を再成立させた（当該集合は全 151 份、このブロックのみが未提供）。
  • ビルダーの補完：amd-rocm7.2.4 ランタイムミラーは ubuntu 24.04 をベースとしており、そこでビルドされた FlagCX wheel は GLIBC_2.38 にリンクし、wheel ラインの 22.04 ゲートに拒否された（22.04-incompatible symbols: GLIBC_2.38、GLIBCXX_3.4.32、__isoc23_）。本件では当該行に自己完結型の 22.04 ビルダーを割り当て、glibc 下限を 2.35 に戻した：ROCm 7.2.4 を導入する jammy 套件（rccl/hip-dev と torch が必要とする hipsolver/hipfft/miopen-hip ヘッダ、graphics リポジトリの amdgpu-core）、deadsnakes の Python 3.12、ピン留めされた torch 2.11.0+rocm7.2（#1548、204 行）。
  • ゲートの前倒し：アプリケーション層ページには従来整合性チェックがなかった——image_tag や changelog の理由を変更しても、ページと Harbor 向け readme は古い内容のままであった（#1549、6 ファイル）。現在 gen_descriptions.py --app-only --check を .githooks/pre-commit と CI に組み込み、状態マトリクス、アプリケーション changelog、アプリケーションページ或いはアプリケーション readme にヒットした場合、まず images.yaml を再構築してから比較する。
  • 審査中：リパッケージラインの依存解決を PEP 503 シンプルインデックスを直接読む方式に変更（#1543）——従来の実装では各依存ごとに pip index versions 子プロセスを起動し、JSON API はアリクラウドミラーで 404 となり、0.28/0.32 のリパッケージには約二時間を要し、300MB の triton wheel を無駄にダウンロードしていた。

1.8 ルール面：FEP-0140 を Implementable に、FEP-0141 を SGLang 0.5.18 に絞り込み（10-28）

日付：2026-10-28　情報源：community PR #159 · PR #160 · PR #161 · 2.3 スケジュール

  • FEP-0140：まずオペレータ分析の範囲と検証計画を補足し（#159）、その後ステータスをドラフトから Implementable に変更、Owner を @ceci3（呂夢思）に設定（#160、メタデータ2フィールドのみ変更）。提案は引き続きリリース受け入れ制約を受け、追跡 issue #151 はオープンのまま維持。
  • FEP-0141：SGLang 0.5.18、残りの Empty 統合と沐曦／清微の基本機能に絞り込み、Owner を @yixiaodapeng に設定（#161、33行追加・144行削除）。詳細なプラットフォーム進捗は #152 に残す。実行可能な回帰、オペレータカバレッジ、性能・安定性チェックと wheel ビルドコマンドを保持。過去バージョンのマトリクスと重複するデプロイ説明を削除。
  • 口径の明確化：DeepSeek-V4-Flash/Pro は引き続き初期 W8A8 候補である。NVIDIA に対するスループット向上 10% は最適化目標であり、固定の受け入れ閾値ではない。これらの限定詞は明示的に保持され、後続で目標が閾値と読み違えられるのを防ぐ。
  • スケジュール確認：community/release/2.3 ディレクトリには依然として中英語のスケジュール表のみで、リリースリストはない。2.2 ディレクトリには rc0/rc1/rc2 と正式リストの4点がある。スケジュールによれば、11-13 が FEP マージ締切、11-30 に rc0 を取得する。

1.9 その他のリポジトリ：optest が燧原 CI に接続、FlagTensor 昇騰常駐グリッド、FlagQuantum 置位一貫性（10-28）

日付：2026-10-28　情報源：optest PR #14 · optest PR #15 · FlagTensor PR #32 · FlagQuantum PR #945 · FlagQuantum PR #914 · FlagDNN リポジトリ

  • optest：5件マージ。燧原 S60 を FlagGems-vllm と FlagGems-sglang のバリアント CI に接続する一方、オペレータリストは FlagGems 本体にのみ有効（#14）。flagos-gpu-check を単一のテキストサマリまたは単一の解析可能な JSON/YAML に作り直し（#15、19ファイル・2947行追加）、device、driver、runtime、runtime_version、device_count、memory_unit などの正規化フィールドを新設。テキストラベルは Device:、Driver:、GPUs Usage: に固定し、ランタイムとホストドライバを分けて記述（#16 ではさらにアクセラレータメタデータをテストサマリに持ち込む）。
  • FlagTensor：昇騰側の常駐グリッド要素ごとカーネルとベンダ関連チューニングをマージ（#32、24ファイル・1128行追加・139行削除）、その後 Ascend ランタイムヘルパーを flagtensor.runtime に統合（#33、#32 シリーズのコミット）。
  • FlagQuantum：6件マージ、33コミットで、依然として組織全体でコミット数第1位。核心は「シャーディング後の MPS と非シャーディングが等価かどうか」を実行可能な証拠にする（#945）：同一プログラムを2アームで実行——max_bond 64 と正確梯度（レイアウトのみ変更）および max_bond 2 と近似梯度（レイアウトとトランケーションが同時に変化）——、2アームの差で2つの寄与を分離する。他に公開 Module の学習高速化と宣言された JAX バッチ VJP の補完（#914）、非有限バインド角度の拒否（#944）、pytest 9.2 による2スイートの復旧（#946）、状態と梯度の一致グリッド（#947）、失敗の導入変更への帰属（#948）。
  • その他：FlagDNN の2件はいずれも海光修正（GPU 名と性能）。FlagAttention は達磨院玄鉄 PPU の MiniMax スパースアテンションをマージ（#111、6ファイル・4644行追加）。FlagCX は AMD アダプタのストリームガード（#680）と昆侖芯プラットフォーム traits の cstddef（#682）を修正。FlagQAI の #1 は依然審査中。docs の2件はいずれもボット（魔搭モデルリスト #545、#567）。Trident は3件審査中（昇騰 LLVM 適配 #7、ユーザ持参 LLVM_ROOT #6、新旧 TVM FFI ヘッダレイアウト #8）。

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

2.1 報道面：摩尔線程が Megatron-MUSA-Titan をオープンソース化、24組のクエリで有効なのはこの1件のみ（10-28）

日付：2026-10-28　情報源：IT之家報道 · 新浪科技転載 · Megatron-MUSA-Titan リポジトリ · Google News RSS 検索

  • 事象：摩尔線程は10-28、大規模モデル訓練基盤プロジェクト Megatron-MUSA-Titan をオープンソース化すると発表した。同社のフル機能 GPU をベースとし、万卡級クラスタでの兆パラメータ MoE 訓練を対象に、事前訓練と強化学習の2つのシナリオをカバーし、MUSA プラットフォーム向けの訓練適配とシステム最適化を提供する。
  • 技術ポイント：すでに万卡クラスタの兆パラメータ MoE 事前訓練で継続的に使用されており、高い MFU と長期間安定した訓練を備えると自述している。blockwise FP8 訓練をサポート。DeepEP と ACE 非同期通信エンジンを組み合わせて MoE の Token ディスパッチと結果マージを加速し、エキスパート並列と計算のオーバーラップを実現。slime、miles 強化学習フレームワークと協働でき、Megatron で訓練し、SGLang でサンプルを生成する形で、事前訓練と強化学習をつなぐ。
  • コード状態：リポジトリ MooreThreads/Megatron-MUSA-Titan は存在し、README には万卡クラスタ上の 1T+ パラメータモデルの事前訓練と強化学習基盤向けと自述されており、最終プッシュは 10-16、本調査期間にコミットはなし——「オープンソース化を発表、コードは未動」に該当し、プレスリリースの「オープンソース」という表現とは時間的に切り分けて見る必要がある。
  • 候補面：二十四組の中英語クエリ語で調査期間内に49件の候補が返り、1件（前条）を採用。コンポーネント名クエリ（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）は中英語合計十二組が引き続きすべてゼロヒット。
  • 除外項目：摩尔線程の第三四半期業績稿十余件（売上高15.5億元、前年同期比1773.9%増、単四半期の非経常損益が黒字転換、香港株発行予定）は決算・相場関連の内容で、3.7 でメンバー単位の背景としてのみ言及。智源側の「源創計画」初回実施、AREX-2、SoulAgent の3件はモデル・コミュニティ関連の内容で、ソフトウェアスタックと直接の関係はない。燧原関連の二十余件は株式相場、取締役会決議、ETF 稿。清微の「産投28計画」周年稿はオープンソーススタックと無関係。

2.2 チャネルと公式サイト：CSDN は依然10-22で停止、HN と智源コミュニティに新規ヒットなし（10-28）

日付：2026-10-28　情報源：CSDN FlagOS コラム · HN Algolia 検索 · 智源コミュニティ · 摩尔線程ニュースセンター

  • CSDN：コラムページの記事リンク51件、最新の確認可能な日付は依然10-22（開放計算大会分科会の再配信と大学円卓会議）。以前の高関連稿3件（GLM-5.3-Flash Day0 で9種チップに適配、Qwen3.8-Flash-Next 初日に8種チップに適配、LightX2V が FlagOS に接続）はページ単位で時刻を確認したところいずれも8月下旬で、調査期間内の内容ではない。
  • HN Algolia：八組のクエリで四日間の調査期間内のヒット数は FlagOS 5、BAAI 30、FlagGems 1、タイトルと本文のキーワードで厳密にマッチングした結果、直接ヒットは0件。
  • 智源コミュニティ：検索ページとトップページはアクセス可能で、FlagOS 関連の新稿はなし。トップページに本スタックコンポーネントの更新は出現していない。
  • メンバー公式サイト：八社の巡回調査で、摩尔線程に調査期間内の新規項目あり——10-28「一図で読み解く摩尔線程2026年第三四半期報告」、決算図解に該当し、ソフトウェアスタックの変動には触れておらず、収録基準により本文条目には含めない（背景は3.7参照）。沐曦、天数、寒武紀、燧原、清微の五社の一覧に10-28から10-29の新規項目はなし。海光のページは静的ページ、地平線は取得失敗、一覧で可視の内容を基準とする。
  • 判断：ニュース側は連続して二番目の調査期間で実質条目がわずか1件、しかもその1件はメンバー単位の自社開発訓練スタックであり本スタックコンポーネントではない。今期の主体は依然としてコードとリリースエンジニアリングである。

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

3.1 地平線：BPU が初めてオペレータ単位で実行可能な PrivateUse1 バックエンドに（10-28）

日付：2026-10-28　情報源：Torch-FL PR #674 · PR #676 · PR #678 · PR #673

  • 接続方式：BPU の実行単位は hbdk4 が生成する .hbm 成果物であり、hbdk4 は x86 上でしか動作しない。ボード上ではコンパイルもできず、リポジトリに同梱された成果物もない。これまでの結論は「設計上 eager は不可」だったが、今回これを三層に分解した。ボード外で単一オペレータの .hbm ライブラリをコンパイルし、これらの成果物を投入する C++ カーネルを生成し、drobotics conf のルーティングを追加する、というものである。
  • カバレッジと検証：40 個の要素単位オペレータ、11 個の形状バケットについて、RDK S600 上で 440 個の成果物すべてが NumPy との比較でゼロ差分となり、flagos テンソル上の aten 呼び出しが実際に BPU に到達することを確認した。著者は同時に二つの否定的結論も記録している。libhbtl.so は CPU リファレンス実装に過ぎず（ldd では libc/libstdc++/libm のみが見え、hbtl::ucp::Add の cpu/wall は 1.00）、動的形状は HBRT 4.7.5 上では実行不可能である（ローダが当該軸を stride 0 と宣言し、タスク検証が 64 以上を要求するため）。
  • 収尾の三件：#676 は kDrobotics に dispatcher.h の二箇所の switch を補完した。これまで BPU ビルドのディスパッチログ名は一律 unknown と表示され、KernelSetOf は BPU 自身のカーネルライブラリを無所属と報告していた。#678 は三箇所の copy 分岐が無条件に CUDA へ box される問題を修正した。デフォルトの FlagGems が主導する NVIDIA と達摩院玄鉄 PPU wheel は意図的に CPU のみの pip torch にリンクしており、CUDA コピーカーネルの DispatchStub は空で、初回呼び出しで missing kernel for cuda となる。#673 はビルド記録におけるベンダー名とプラットフォーム id の不一致（hygon/dcu、mthreads/musa、enflame/gcu、nvidia/cuda）を修正した。これは海光 DCU レーンの八件の単体テスト失敗の根本原因である。
  • 審査中：#672 は soft-lowp 行列オペレータの claim 粒度を統一し（conf キー単位で宣言、ファミリ単位でデコード）、#677 はキーワード引数の FlagGems 呼び出しをアクティブバックエンド経由にし、#680 はビルド記録が保持するベンダーに基づいてデバイスエイリアスを再定義し、#681 はインターフェース対象ではなく torch プレフィックスから libtorch_cuda プローブを読み取る。
  • 判断：これは本調査期間で唯一の「新プラットフォームが利用不可から利用可能になった」接続であり、価値はパフォーマンスではなく経路の打通にある。40 個の要素単位オペレータは起点であり、畳み込みなどの基幹オペレータは依然として torch.compile の全体グラフ経路に依存している。

3.2 崑崙芯：スカラーチェーン融合と連続セグメントカーネル、P800 上の三箇所の高速化（10-28）

日付：2026-10-28　情報源：FlagGems PR #7617 · PR #7600 · PR #7850 · PR #7803 · FlagCX PR #682

  • スカラーチェーン：8つの出位スカラーチェーンオペレータの融合カーネルにより、相対所要時間が0.08〜0.13から0.81〜0.93に向上（#7617）。収益の主な源はホスト側にある。出力の一括割り当てとunbindにより、テンソルごとのアロケータ呼び出しを置き換える。小形状の単一発射では、すべてのポインタをパラメータとして渡す。
  • 連続セグメント：batch-norm推論とQKV変換を連続セグメントカーネルに変更後、集約指標は0.228→1.357および0.260→5.062（#7600）。元の実装は(n,c)スライスまたは2次元タイルで編成され、読み書きが不連続であった。新しい実装では各プログラムが連続要素のセグメントをカバーし、フラットインデックスからチャネルまたはパッキング行を逆算する。
  • マスク填充：masked_fillはP800上で0.577から0.829に向上（#7850）。手法は、整数マスクの符号拡張をsitofp後の0/1浮動小数点乗算に変更し、カーネル全体をベクトル化可能にすることである。精度面ではmがちょうど0/1であり、結果はビット単位で一致する。
  • 保守性：#7803は、現在のmaster上で昆仑芯バックエンドがインポートできない問題（共有エグゼキュータが_result_dtypeヘルパーを削除した）を修正し、さらに共有エグゼキュータのuni_sram上の支配関係コンパイルエラーを修正した。修正しない場合、いかなる昆仑芯テストも起動できない。
  • 通信側：FlagCXの昆仑芯プラットフォームtraitsはcstddefを__xpu__ガードの外に移動した（#682）。以前はcomm_traits.hからの解析時にsize_tがまだ可視でなく、公共デバイスAPIのホスト側コンパイルが直接失敗していた。

3.3 天数：畳み込みは工况档位表を採用、conv3dはチャネルゼロ埋めを除去（10-28）

日付：2026-10-28　情報源：FlagGems PR #7036 · FlagGems PR #7061

  • conv_transpose2d：汎用実装の単一デフォルトスケジューリング(64,32,32,4)に3x3/stride2の特例を加えたものを、データ型・カーネルサイズ・ストライド・出力チャネル数でインデックスされる7套のハードウェアチューニング档位（BLOCK_NHW/CI/CO、num_warps、num_stages）に置き換え、出力がL2に収まるかどうかで2つのカーネル変体を切り替える——直掃変体はL2内でより高速、位相専用変体は出力がL2を超えた後により安定（#7036、1886行追加）。
  • conv3d：天数側のBLOCK_CIはすでに16以上であり、FlagTreeのAABSも縮小されたタイルを16x16x16の下限に引き戻す。したがって汎用パスがweight_cを16にゼロ埋めするのは、毎回の呼び出しでの割り当てとコピーのオーバーヘッドに過ぎず、除去後も出力はビット単位で一致する。さらにBLOCK_NI_DO_HO_WOを32と64の2档の小空間タイルとして補い、小体積形状でもデバイスを満たせるようにした（#7061）。
  • 判断：両方ともロングテールチューニングに属し、方向は一致している——「汎用的だが遅い」パスをローカライズされたスケジューリングに置き換え、同時にゼロ埋めのような無収益オーバーヘッドを削除する。

3.4 燧原：Qwen3.5 FP8がGCU上で、core_shapesが落账、FlagPrismが初接入（10-28）

日付：2026-10-28　情報源：vllm-plugin-FL PR #358 · FlagGems-sglang PR #232 · FlagTree PR #1239 · optest PR #14

  • 推論：GCU バックエンドに Qwen3.5 FP8 の W8A8 ブロックキャリブレーション推論を追加し、GCU300/GCU400 の制限に合わせてカーネルパッチを作り直すことで、FP8 MoE を eager と全体グラフの両モードで利用可能にした（#358、20 ファイル）。
  • 形状テーブル：燧原の core_shapes.yaml は追加後一週間効力がなかった——リポジトリ内にロード箇所が一切なく、ベンチマークはハードコードされた kunlunxin 分岐しか認識していなかった（#229 でファイル追加、#232 でロード修正）。修正により検索を任意のベンダーに汎化し、併せて kunlunxin パスが無条件に設定されることで発生していた FileNotFoundError も修正した。
  • ツールチェーン：FlagPrism のプロファイラとデバッガを燧原まで拡張しデフォルトで有効化（#1239）。デバッグ付きカーネル発射はゲートウェイ経由に変更し、L2 キャプチャに必要なコンパイラ処理は燧原バックエンド内部に残した。optest は S60 を FlagGems の 2 バリアントの CI に接続した（#14）。
  • 審査中：vLLM 0.28 の TXDA eager バックエンドアップグレード（#642）、TransformerEngine の燧原 profiler と runner（審査中）、および FlagGems 側の大量の参考実装修正（1.3 参照）。

3.5 達摩院玄鉄：PPU 上の MiniMax 疎注意力、幾何平均 1.8 倍（10-28）

日付：2026-10-28　情報源：FlagAttention PR #111 · FlagAttention リポジトリ

  • 内容：達摩院玄鉄 PPU バックエンドに MiniMax 疎注意力（MSA）推論オペレータを追加。インデックススコアリング、top-k ブロック選択、疎注意力本体をカバーし、prefill と decode の両パスを実装（6 ファイル、4644 行追加）。
  • 能力：ページド KV キャッシュ、因果マスク、強制ブロック選択をサポート。810E 向けに行列計算レイアウトとカーネル発射を適合。prefill のインデックススコアリングは KV ページ単位で並列化し、query 側の並列度不足を緩和。FP8 入力は BF16 計算に変換し、ネイティブ FP8 行列積は未使用。
  • 性能：SGLang 汎用 Triton 実装をベースラインとして、810E 上で prefill は 21/21 通過、幾何平均 2.299 倍（最低 1.965、最高 5.434）、decode は 18/18 通過、幾何平均 1.354 倍（1.289~1.485）。合計 39/39、幾何平均 1.800 倍。
  • 判断：これは PPU 上の最初の疎注意力パスであり、同じ調査期間の Torch-FL の BPU 接続と対照をなす——一方は基幹オペレータのカバレッジを補い、もう一方は新モデル構造の特殊オペレータを補う。

3.6 清微、曦望、海光：FlagCX の rpm パッケージングで 3 社のバックエンドを補完（10-28）

日付：2026-10-28　情報源：FlagCX PR #673 · FlagCX PR #681 · FlagTree PR #1459 · FlagDNN リポジトリ · FlagAttention PR #117

  • 清微：libflagcx-tsm が rpm ラインに進み、SDK は 2 つの makeself インストーラで、/usr/local/kuiper に展開される（#673）。FlagTree 側で審査中の #1459 は清微バックエンドを内部 Triton 3.6 開発ラインに同期する（27 ファイル、発射ごとの精度 API、外部 CoreIR 入口とランタイムアダプタを含み、Tx81 のコード生成と DMA/RDMA/WDMA の CRT 欠陥を修正）。
  • 曦望：libflagcx-sunrise が rpm ラインに進み、SDK は tangtk --toolkit と pccl を経て /usr/local に配置される。此前曦望は vllm-plugin-FL 側で 0.28 適配が審査中。
  • 海光：libflagcx-du が rpm ラインに進み、DTK tarball は /opt/dtk に展開される。FlagDNN の 2 件は海光の GPU 名と性能を修正する。FlagAttention で審査中の #117 は海光 BW3000（gfx936）向けに純 Triton の GLA 実装を追加し、ゲート付き累加和とループ状態スキャンを 1 本のパイプラインに統合し、サポートされる推論負荷のみ特化パスを通す。
  • パッケージング方針：3 社はいずれもベンダー基礎イメージを必要とせず、openEuler イメージにファイルリポジトリを加えるだけで完全な環境となる。ベンダー soname は昇騰の既存手法に従い統一的にフィルタリングする（これらの SDK は決して RPM ではなく、どのリポジトリも提供できない）。

3.7 摩尔線程：Megatron-MUSA-Titan オープンソースと第 3 四半期報告が同日（10-28）

日付：2026-10-28　情報源：IT之家報道 · Megatron-MUSA-Titan リポジトリ · 摩尔線程ニュースセンター · sglang-plugin-FL PR #158

  • トレーニングスタック：Megatron-MUSA-Titan は万卡クラスタ向けの兆パラメータ MoE を対象とし、事前学習と強化学習をカバーする。blockwise FP8、DeepEP と ACE 非同期通信、エキスパート並列と計算オーバーラップをサポートし、slime、miles と協調できる（Megatron トレーニング + SGLang サンプリング）。これはメンバー単位で自研した Megatron 系トレーニングスタックであり、本スタックの Megatron-LM-FL とは同源別支で、コード還流の兆候はまだない（リポジトリの最終プッシュは 10-16）。
  • 財務背景：同日に第 3 四半期報告を発表し、売上高 15.5 億元、前年同期比 1773.9% 増、単四半期の非経常損益控除後利益を実現、前三半期売上高 32.89 億元、親会社株主帰属純利益 3769.73 万元、さらに香港株二次上場を推進する。財報は本スタックの技術判断を変えないが、そのオープンソースのリズムに対する投入能力を説明する。
  • 推論側：sglang-plugin-FL で審査中の #158 は MUSA に MiniMax-M3 サポートを追加し、#125 は Qwen3.6 の S5000 上での Triton と YAML チューニングである。FlagGems-sglang 側では本調査期間に MUSA の変更はない。
  • 判断：摩尔線程の直近 2 週間の動きは「トレーニング + 推論の両スタック自研オープンソース」に集中しており、本スタックとの交点は依然としてオペレータとプラグイン層（FlagGems、sglang-plugin-FL）であり、トレーニングフレームワーク層ではない。

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

  • 新たな経路を開通：地平線 BPU は「設計上 eager 不可」から、オペレータごとに実行可能な PrivateUse1 バックエンドへと変貌（40 の要素単位オペレータ、440 の成果物で差異ゼロ）。併せてディスパッチログの命名と CUDA コピーカーネルのガードを修正。これは当調査期間で最も構造的に意味のある接続だが、要素単位オペレータのみをカバーし、主干は依然としてグラフ全体コンパイルに依存している。
  • 通信層がタグと配布パッケージ段階へ：FlagCX が v0.14.1 を打ち出し（アダプタごとにデバイスビットコードを生成）、rpm ラインは 3 バックエンドから 6 バックエンドへ拡大、wheel リリースも build-infra で記帳される。なお、このタグには Release 本文がなく、v0.14.0 のやり方と一致していない点に注意が必要。
  • リリースエンジニアリングが補習中：changelog のサイト掲載と Harbor、未プッシュの寒武紀 megatron イメージ 2 件の撤回、アプリケーションページの一貫性チェックを pre-commit と CI へ、AMD 7.2.4 に 22.04 ビルダーを追加。これらは新能力を生まないが、2.3 のリリース一覧が自己証明できるかどうかを直接左右する。
  • 審査中の構造変化：審査中は 401 から 288 へ、新規オープンは 269 から 101 へ減少。前号の FlagGems-Experimental の 135 件の一括コミットは合入も新規追加もなし。現在の審査中主体は FlagGems の 181 件で、うち新規オープン 53 件の多くが燧原参考実装の修正——マルチバックエンド検収のボトルネックが参考実装とテスト基準にあり、オペレータ供給ではないことを示す。
  • マルチブランチは基準の区別が必要：FlagGems は master と kernelgen-dev の両方で合入（#7905、#7934）、FlagTree の合入は triton_v3.5.x と feature/flagmega ブランチに分散、FlagGems-Experimental のデフォルトブランチは infra-ci。デフォルトブランチで集計すると実作業量を過小評価し、コミット検索では原子補核のリポジトリを取りこぼす。
  • 要観察の 3 点：第一に、v0.14.1 の後に Release 説明が補われ 2.3 一覧に入るか。第二に、BPU 経路が要素単位オペレータから畳み込みなど主干オペレータへ拡大するか。第三に、Megatron-MUSA-Titan のコードが調査期間後に本当にプッシュ開始されるか、そして Megatron-LM-FL との再利用が形成されるか。

情報源核查表

情報源 核查結果
GitHub 組織リポジトリ 61 リポジトリを全量核查、23 リポジトリが調査期間内にプッシュ（前号 20 リポジトリ）
GitHub コミット検索 99 件ヒット；検索インデックスは当日合入に遅延があるため、合入量と並列で提示
GitHub マージ済み PR 検索 67 件、16 リポジトリ
GitHub 審査中 PR 検索 288 件（新規オープン 101）、FlagGems 181 件が六割を占める
Release / Tag 原子核查 31 リポジトリ；調査期間内に新規タグ 1 個（FlagCX v0.14.1、Release 本文なし）
org イベントストリーム 100 件：プッシュ 51、ブランチ作成 32、ブランチ削除 9、PR レビュー 8、PR 開閉イベントなし
バージョン日程 community/release/2.3 は依然として中英文日程表のみ；build-infra 最新タグは依然 v2.2.0
Google News RSS 24 組クエリ、49 件候補、採用 1 件（Megatron-MUSA-Titan）
HN Algolia 8 組クエリ、四日間の調査期間内で直接ヒット 0 件
CSDN FlagOS コラム 最新核查可能記事は 10-22 で停止、調査期間内に新稿なし
智源コミュニティ 調査期間内の新稿なし、トップページに本スタック関連更新なし
メンバー機関公式サイト 8 社巡検；摩尔線程 10-28 に三季度報告図解 1 件；地平線取得失敗；その他更新なし

完全情報源リスト

FlagGems PR #7600（昆仑芯連続段カーネル） — https://github.com/flagos-ai/FlagGems/pull/7600

<github.com/flagos-ai/FlagTree/pull/1459>

infra/tags>

[92] 清微智能公式サイトニュース — https://www.tsingmicro.com/news