調査期間：2026-11-02 06:00 ~ 2026-11-03 06:00（北京時間、24時間；前回デイリーレポートの締め切り時点から継続）。

情報源：GitHub（org: flagos-ai 61リポジトリ全量核查、コミット検索272件、マージ済みPR 162件、審査中PR 311件、orgイベントストリーム100件、31リポジトリのReleaseと8リポジトリのTagの原子的核查、5リポジトリの原子的補核と主要PR本文の核查）、Google News RSS（24組の中英語検索語、プロキシ経由）、HN Algolia（8組）、CSDN FlagOSコラム（各記事の時刻核查）、智源コミュニティ、9社の成員機関公式サイト（詳細は付録の情報源リストを参照）。

本期インデックス

  • 今日の重点：AMD ROCmラインがビルドからオペレータまで3箇所で同時進行；量子合成コンパイラが単日21件マージ、UP-01とAO/PF受け入れラインが並行；玄鉄13個の専用オペレータが43分以内に一括マージ（11-02）
    1. オープンソースプロジェクトの進展（GitHub動向）
      • 1.1 組織のリズム：16リポジトリへのプッシュ、272件のコミット、162件のマージ、審査中311件（11-02 ~ 11-03）
      • 1.2 バージョン面：2.3.0ランタイムイメージをバックエンド別にプッシュ、AMD ROCmビルドラインを初めて構築（11-02）
      • 1.3 FlagQuantum：合成ラインが単日21件マージ、UP-01とAO/PFの3本の受け入れラインが並行（11-02 ~ 11-03）
      • 1.4 FlagGems：玄鉄13個の専用オペレータが43分以内にマージ（11-02）
      • 1.5 FlagGems：昆仑芯XPU3がサイレントエラーの形状を修正、14件の性能と契約の収束（11-02）
      • 1.6 FlagGems-sglang：コンペティションのTritonオペレータ17件が一括マージ、AMD gfx1100の2本の性能ライン（11-02）
      • 1.7 FlagTreeとFlagGems-vllm：Hopperの誤コンパイル修正、玄鉄MMモデルパッケージv1.1.0（11-02）
      • 1.8 FlagTrainとFlagBLAS：KMCompilerの8件のオペレータ、MUSA L1 BLASが実装（11-02）
    1. 報道とエコシステム
      • 2.1 チャネル核查：24組のクエリでコンポーネント級のヒットゼロ、CSDNとHNは期間内に新記事なし（11-03）
      • 2.2 エコシステム観察：烏鎮サミット開幕、オープンソースをテーマにしたエコシステム体験館は11-05まで開催（11-02）
      • 2.3 周辺エコシステム：九源連合体が飛騰、TileLang、商湯の3つの連合成果を発表（11-02振り返り稿）
    1. 成員機関とバックエンドベンダーの深掘り
      • 3.1 達摩院玄鉄：専用オペレータ、MMコストモデル、chunk_kdaの3ラインが同日進行（11-02）
      • 3.2 昆仑芯：XPU3 foreach契約の修正と14件の性能収束（11-02）
      • 3.3 昇騰と海光：W8A8 INT8のGEMMとBMMの2つの実装（11-02）
      • 3.4 摩尔線程：Conv1D真の一次元GEMMが26個のベンチマーク例すべてを0.8倍ライン超えに（11-02）
      • 3.5 沐曦、天数、清微、燧原と地平線：一方でオペレータを補い、一方で契約を補う（11-02）
    1. まとめとトレンド観察
  • 付録：情報源核查表、完全な情報源リスト

今日の重点：AMD ROCmラインが3箇所で同時進行；量子合成コンパイラが単日21件マージ；玄鉄13個の専用オペレータが一括実装（11-02）

日付：2026-11-02　出典：build-infra PR #1589 · build-infra PR #1608 · FlagGems-sglang PR #271 · FlagQuantum PR #1004 · FlagGems PR #8240（全量は付録を参照）

  • AMD面：build-infra #1589 は FlagTree の amd バックエンド向けに新たなパッケージングラインを構築（bare-ubuntu 22.04 ビルドマシン、backends.yaml 行、verify_stage ステップと wheel ターゲット）。動機は glibc の下限ではなくトレーサビリティ——ベンダー 0.7.0+amd3.6 の wheel 自体は 22.04 ビルドだが、Source-Commit が付属しない。このラインは amd-rocm7.2.4 ランタイムノード上で A/B を実施：オペレータスキャンと torch.compile の結果は一致（maxdiff 1.526e-05、9/9）、182 個のベンダー固有ファイルは設計どおりすべて照合された。同日 #1599 は rocm7.2.4 の torch クロージャを vLLM 0.32 の固定組み合わせに整合；FlagGems-sglang #271 は gfx1100 向けに decode_attention、decode_grouped_attention、extend_attention、log_scaling_tau の4オペレータを追加。ビルド、ランタイム、オペレータの3層が同一ウィンドウ内で同方向に進み、AMD ラインは「動く」から「トレース可能・再現可能」へと向かっている。
  • 量子面：FlagQuantum は単日で21件のマージ、122件のコミットがあり、3つの受け入れラインに沿って進んだ——UP-01 は Python qfunc プログラムを共通フロントエンド化（#1004）、AO-00/01/02 は順に算術ベースライン、純粋式正規化、保護付き算術実装を確立（#1006、#1010、#1013）、PF-00/01 は Python コンパイル時延とプロセスメモリの台帳を確立し、検証済み計画フィールドを再利用（#1018、#1021）。同期間、QEC 側ではノイズ付き surface memory の組み合わせ、コヒーレントマッチング訂正、ブロック分割スケジューリングを補完（#1012、#1015、#1019）、ランタイム側では正規化 IR に切り替えて Module 訓練を再利用し、診断スナップショットのオーバーヘッドを削減（#1017、#1014）。
  • 玄鉄面：FlagGems は 16:03 から 16:46 の43分間に13個の玄鉄専用オペレータをマージ。Chebyshev 多項式、igamma、conv_transpose3d、quantized_lstm、nuclear_norm、fused_rms_norm_backward、_adaptive_avg_pool3d_backward などのロングテール項目をカバーし、いずれも KernelGen の玄鉄ラインを経由。これはオペレータライブラリの総量拡充に続き、単一バックエンド専用オペレータが初めて「バッチ」形態で主干に入ったものである。
  • 判断：3つのラインは同じ一事を指し示す——FlagOS の能力拡張はすでに「ランキング式のオペレータ数埋め合わせ」から「バックエンド別のバッチ納品＋受け入れユニット別の記帳」へと移行した。AMD は自前のビルドトレーサビリティラインを持ち、量子スタックは意味論・算術・性能を独立に受け入れ可能な小ステップに分割し、玄鉄は分単位のリズムでバッチ統合する。真のボトルネックは依然として開発ではなくマージとリリースにある：本ウィンドウは162件のマージ、192件の新規オープンで、キューは拡大を続け、2.3.0 も依然として「イメージ先行、マニフェスト未凍結」の状態にある。

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

1.1 組織のリズム：16リポジトリへのプッシュ、272件のコミット、162件のマージ、レビュー中311件（11-02 ~ 11-03）

日付：2026-11-02 ~ 2026-11-03　情報源：flagos-ai 組織リポジトリ · コミット検索 · マージ済み PR 検索 · レビュー中 PR 検索

  • リポジトリ面：61 リポジトリ中 16 リポジトリに期間内のプッシュがあり、プッシュ時間の近い順に FlagQuantum、FlagQAI、FlagTensor、release-info、build-infra、FlagTree、FlagGems、FlagGems-vllm、FlagTrain、docs、FlagGems-sglang、optest、FlagDNN、vllm-plugin-FL、Torch-FL、FlagBLAS。うち release-info の 3 回のプッシュはすべて gh-pages の自動デプロイ（それぞれ build-infra の 1727064、672f77b、3c54d7e の 3 コミットに対応）、docs と FlagTensor のデフォルトブランチの最新コミットはそれぞれ 10-03 と 10-28 で停止しており、両者の pushed_at の更新は非デフォルトブランチまたはタグ操作によるもので、いずれも期間内のデフォルトブランチへの新規コミットはない。
  • コミット面：コミット検索のヒットは 272 件、リポジトリ別では FlagQuantum 122、FlagGems 52、FlagGems-sglang 24、FlagQAI 23、build-infra 18、FlagTrain 8、FlagGems-vllm 7、FlagTree 6、Torch-FL 5、optest 3、FlagBLAS 2、vllm-plugin-FL と FlagDNN が各 1。量子スタックの 1 リポジトリが 44.9% を占め、前回（3 日間期間のシェア 58%）から引き続き低下し、非量子側は 55% 以上に戻った。
  • マージ面：マージ PR は 162 件、12 リポジトリから：FlagGems 55、FlagGems-sglang 27、FlagQuantum 21、build-infra 18、FlagQAI 9、FlagTrain 8、FlagGems-vllm 7、FlagTree 6、Torch-FL 5、optest 4、vllm-plugin-FL と FlagBLAS が各 1。
  • 審査中面：期間内に更新のあった審査中 PR は 311 件、新規作成は 192 件。リポジトリ別では FlagGems 210（新規 148）、FlagTree 28（13）、FlagGems-vllm 19（6）、vllm-plugin-FL 14（5）、sglang-plugin-FL 7（2）、Torch-FL 5（1）、FlagGems-sglang 4（3）、FlagTrain 4（1）、flir 3（2）、FlagAttention 3（1）、FlagCX 3（1）、FlagQuantum 2（2）、FlagScale 2（2）、FlagTensor、FlagTree-AscendNPU-IR、docs、optest、TransformerEngine-FL、FlagCV、Megatron-LM-FL が各 1。
  • イベントとブランチ面：org イベントストリームは 100 件、構成は PR イベント 31、プッシュ 22、ブランチ削除 17、ブランチ作成 16、イシューコメント 7、イシューイベント 3、レビューコメント 2、レビュー 1、fork 1。ブランチ作成と削除は合計 33 件で、ほぼすべてが FlagQuantum の feat/synth-* シリーズに集中しており、量子合成ラインが依然として短命ブランチの素早い作成・削除を中心としていることを示す。
  • 比較：前回の 24 時間期間（マージ 183 件、新規 84 件）と比べ、マージ量は 11.5% 減少、新規量は 128.6% 増加；3 日間期間の日平均（マージ 38 件、新規 47 件）と比べ、本期間のマージと新規はいずれも明らかに拡大。マージと新規が同時に高水準にあり、かつ新規がマージの約 1.2 倍に達しているのは、典型的な平日の「生産ライン全開、レビュー逼迫」の形態である。

1.2 リリース面：2.3.0 ランタイムイメージをバックエンド別にプッシュ、AMD ROCm ビルドラインを初構築（11-02）

日付：2026-11-02　情報源：build-infra PR #1589 · build-infra PR #1595 · build-infra PR #1599 · build-infra PR #1606 · build-infra PR #1607 · build-infra PR #1608 · community 2.2 リリース一覧

  • 新規ビルドライン：#1589 は FlagTree の amd バックエンドに独立したパッケージングラインと wheel 産線を構築し、backends.yaml の行、verify_stage ステップ、wheel ワークフローのターゲットを追加した。PR の自述による動機は互換性ではなく溯源であり、ベンダー同一バージョンの wheel には Source-Commit が付属しないため、自社の 22.04 ビルドマシンで再リリースし、amd-rocm7.2.4 ランタイム上でオペレータスキャンと torch.compile の A/B 照合を行った（maxdiff 1.526e-05、9/9 通過、182 個のベンダー固有ファイルは設計通りに計上）。このラインの毎日ビルドスイッチは当面オフである。
  • ランタイム収束：#1599 は rocm7.2.4 の torch 閉包を vLLM 0.32 の固定組み合わせと一致させ、同一ランタイム内で 2 セットの torch バージョン仮定が生じるのを回避した；#1606 は flagcx の「プリインストール wheel」判定をインポート可能性からメタデータによる識別に変更し、パス上に残留する同名パッケージの誤判定を回避した；#1607 は wheel マニフェスト収集が任意の深さのディレクトリ階層をサポートするようにした。
  • バージョン表記：#1595 と #1608 の 2 件のボットコミットが 2.3.0 のイメージ記述と changelog 日付を記録した。#1608 の本文によると、ランタイムイメージワークフローはバックエンドごとに 2.3.0 をプッシュ済みで、各バックエンドの未執筆の changelog エントリに registry push_time に基づく日付を付与しており、本件は amd-rocm7.2.4 レイヤーに対応する。これにより base レイヤーと寒武紀 neuware 4.4.3、沐曦 maca 3.8.1.3、海光 dtk26.10、AMD rocm7.2.4 の 4 レイヤーがすべて 2.3.0 の下で日付の埋め戻しを完了した。
  • リリース状態の検査：31 リポジトリの Release と 8 リポジトリの Tag をアトミックに検査し、調査期間内に新たな Release オブジェクトはなかった；コミュニティリポジトリ release/2.3 配下のマニフェストファイルは依然として 404 を返し、release/2.2 のマニフェストは掲載中である。すなわちイメージはバックエンドごとにプッシュ済みだが、マニフェストの凍結とサイト公開の 2 ステップは依然として発生しておらず、前回の判断と一致する。
  • 要観察：18 件のマージのうち、ドキュメントとナレッジ層 9 件、AMD ビルドとランタイム 4 件、wheel とパッケージング 3 件、ボット changelog 2 件。開発側の 2.3.0 作業はほぼ「既成事実の記録」に転じており、本作業週にマニフェストを凍結しなければ、2.3.0 のリリースウィンドウは次のバージョン計画に圧迫される。

1.3 FlagQuantum：合成ラインが単日 21 件マージ、UP-01 と AO/PF の 3 本の受け入れラインが並行（11-02 ~ 11-03）

日付：2026-11-02 ~ 2026-11-03　情報源：FlagQuantum PR #1002 · FlagQuantum PR #1004 · FlagQuantum PR #1006 · FlagQuantum PR #1010 · FlagQuantum PR #1013 · FlagQuantum PR #1018 · FlagQuantum PR #1021

  • セマンティクスライン（UP）：#1002 まず原始定数角度の PHASE ゲートを既存の CoreIR で通す；#1003 UP-00 のセマンティクス境界を確立し、Qmod の RZ 互換を保持する；#1004 UP-01 の Python プログラム名前空間をフロントエンドに接続する——@synth.qfunc デコレートされた関数は割り当て、ゲート、出力を直接記述でき、コンパイラ側は型付き qfunc 準備と算術合成をキャプチャし、ランタイム側は全新ポートでプログラム内準備を実行する。PR 本文には再計算可能な例が示されている：2 つの量子ビット割り当て、Hadamard 変換、result |= x*x+y を含むプログラムを、同一の共通ワークフローでコンパイルと実行が可能。
  • 算術ライン（AO）：#1006 AO-00 の算術ベースラインと独立 oracle を確立し、「検証範囲を誇張してはならない」をバリデータルールとして記述する；#1010 AO-01 を着地させ、純粋式に対する保護付き共通部分式除去と信頼性のあるビット事実正規化を行う；#1013 AO-02 を着地させ、保護された平方、定数、終端 XOR 実装を補完する。3 件は AO-00 から AO-02 の順に漸進し、各ステップで前ステップのリソースベースラインと受け入れ証拠を保持する。
  • 性能ライン（PF）：#1018 PF-00 の Python コンパイル時延と OS RSS ベースラインを確立し、計時、メモリ、診断キューを分離観測として、本番コードを変更せず既存リソースベースラインも置換しない；#1021 PF-01 で検証済みプランフィールドを再利用し、Services 側の重複検証とオブジェクト再構築を削減する。2 件を合わせて「合成 1 回にどれだけ時間がかかり、どれだけメモリを占めるか」を単発観測ではなく再計算可能な数字にする。
  • サイドライン同期：QEC 側 #1012 はノイズ surface memory 実験の組み合わせ正確性を検証し、#1015 はコヒーレントマッチングの訂正記録を保持し、#1019 はブロック分割スケジューリングと後期メモリ無効化を検証する；ランタイム側 #1017 は Module トレーニングが正規化 IR を再利用できるようにし、#1014 はデフォルト診断スナップショットのオーバーヘッドを低減し、#1020 は遅延 Torch コンパイル境界を承認済み契約として記述する。ウィンドウ末尾にはさらに #1022、#1023 の 2 件が 00:21 と 01:19 に開かれ、方向は依然として合成ラインとランタイムである。
  • 判断：これら 21 件の共通特徴は「1 つの大きな機能」を「独立して受け入れ可能なユニット」に分割すること——セマンティクス、算術、性能がそれぞれベースライン、oracle、失敗即赤の証拠を持つ。量子スタックにとって、これは単点の性能数字よりも重要である：後続のあらゆるレジスタ割り当てやゲート合成の変更が、既存の帳簿で直ちにコストを測定できるようになる。

1.4 FlagGems：玄鉄 13 個の専用オペレータが 43 分以内にマージ（11-02）

日付：2026-11-02　情報源：FlagGems PR #8240 · FlagGems PR #8229 · FlagGems PR #8237 · FlagGems PR #8239 · FlagGems PR #8232 · FlagGems PR #8231

  • バッチ構成：13 件はすべて KernelGen 玄鉄産線と标注され、16:03 の線形結合オペレータから 16:46 の poisson_nll_loss まで。カバー範囲は 4 類に分かれる：特殊関数（Chebyshev 多項式、igamma）、畳み込み族（3 次元畳み込み、転置畳み込み、時間畳み込み逆伝播）、量子化と正規化（量子化 LSTM、RMSNorm 逆伝播融合）、行列とプーリング（行列ノルム、3 次元適応プーリング逆伝播、分数最大プーリング逆伝播、Lanczos アップサンプリング）。すべて新規専用実装であり、他のバックエンドと公共エントリを変更しない。
  • 形態特徴：項目はロングテールに集中——特殊関数（Chebyshev、igamma）、3 次元畳み込みと転置畳み込み、量子化 LSTM、行列ノルム、プーリング逆伝播。これらはまさに汎用 Triton 実装の性能が最も悪く、専用化の収益が最大となる類であり、前ウィンドウの玄鉄側「まず幹を補う」リズムとの接続も形成している。
  • リズム：43 分で 13 件、平均 3.3 分に 1 件、しかも昆仑芯、摩尔線程、昇腾、海光の 4 社の同日バックエンド項目と同じ時間帯に交织している。FlagGems のレビューがすでにバックエンドごとに並列でバッチオペレータ単を消化でき、直列待ちではないことを示す。
  • 対照：前ウィンドウの FlagGems の玄鉄項目はゼロ；本ウィンドウは 13 件で、FlagGems 当日 55 件マージの 23.6% を占める。同一リポジトリには他に昆仑芯 14 件、摩尔線程 5 件、NVIDIA 側 KernelGen 2 件、沐曦 2 件があり、バックエンド分布は過去より均衡している。
  • 観察待ち：このバッチのオペレータは現在玄鉄専用産線にのみ存在し、クロスバックエンド再利用や FlagGems-vllm 推論パスとの接続記録はまだない。次に見るべきは、これらが上層モデル（特に量子化 LSTM とプーリング逆伝播）から実際に呼び出されるかどうかであり、カバレッジカウントを増やすだけではないことだ。

1.5 FlagGems：昆仑芯 XPU3 が静かな誤り形状を修正、14 件の性能と契約の収束（11-02）

日付：2026-11-02　情報源：FlagGems PR #8038 · FlagGems PR #8034 · FlagGems PR #7976 · FlagGems PR #8123 · FlagGems PR #8245 · FlagGems PR #8049

  • 正確性修正：#8038 は当日最も読む価値のあるコミット。foreach 系の out-of-place スカラーオーバーロードは「同一 dtype、同一デバイス、同一要素数」の場合に高速パスを通り、出力は一律で最初のテンソルの形状で確保してからビューを切るが、高速パスの准入条件は要素数を比較しており形状は比較していない——そのため形状は異なるが要素数が同じリストはすべて最初のテンソルの形状を継承し、静かな誤った結果を生む。修正では准入を完全な形状による判定に変更し、さらに別の 2 件で 16 個のスカラー出力を単一ベースアドレス指定に変更し、リスト出力を 1 ブロックの平坦バッファに統合した。
  • 契約修正：#7976 は foreach のドット記法によるスロット取得のインデックスを program_id(0) から取るように変更；#8034 は JIT をコミットする前に自動チューニングのグリッドを評価し、未評価のグリッドで起動することを回避；#7956 はスカラー解析の三値返り値をアンパックし、高速パスの値取得を修正。
  • 性能収束：#8056 は triu_、resolve_neg、le とビット右シフトに高速パスを追加；#8245 は flip、ge、lerp に点態高速パスを追加し、前版の BF16 一次元 tile 再構築を撤回；#8108 は pool3d 逆伝播の正確パスを融合し、小さな乗算では点態パイプラインをスキップ；#8107 はチャネルごとの次数が一致する場合に Chebyshev の t/w を展開；#8030 は choose_qparams_optimized、kl_div と 2 つの Bessel カーネルを高速化；#8111 は Jacobi スキャンをブロック化し、nuclear_norm が k 回ではなく nb 回の起動で済むように；#8049 は linspace に単一式の高速パスを実装；#8248 にはさらに一群のオペレータ特化性能修正がある。
  • ロールバックのシグナル：#8123 は「昆仑芯 BF16 点態性能最適化」を撤回、理由はリグレッションの混入；同日 #8245 は別の方案でやり直し、明確に「#8052 の BF16 一次元 tile 再構築を撤回」と述べた。撤回と補完が同一期間に発生したことは、XPU3 側の点態最適化がまだ試験期間中であり、マージ前に十分な形状カバレッジが欠けていることを示す。
  • 判断：昆仑芯のこの一群のキーワードは「契約」——形状、スロット、グリッド、返り値という 4 つの層の暗黙の約定をそれぞれ 1 箇所ずつ修正した。この種の問題の共通の帰結はクラッシュではなく静かな誤りであり、性能リグレッションよりもデイリーレポートに記録する価値がある。

1.6 FlagGems-sglang：コンペ 17 件の Triton オペレータを一括マージ、AMD gfx1100 の 2 本の性能ライン（11-02）

日付：2026-11-02　情報源：FlagGems-sglang PR #207 · FlagGems-sglang PR #220 · FlagGems-sglang PR #256 · FlagGems-sglang PR #270 · FlagGems-sglang PR #271 · FlagGems-sglang PR #275

  • 競賽バッチ：10:22 から 10:55 の30分間に、FlagOS 競賽 Track1 と標注された Triton オペレータ PR 17件が集中マージされた。Hadamard 変換、Gemma 融合加算 RMSNorm、エキスパート並列の scatter と gather、scatter-to-padded、シングルパス RMSNorm、RMSNorm スケーリングとスケーリングオフセット、QK ヘッド LayerNorm、QK-Gemma-RMSNorm-RoPE 融合、QK 逆 RMS、LayerNorm 変調などを含む。コミット者は2名の競賽参加者に集中しており、レビューはバッチ単位のマージで行われた。
  • AMD 性能ライン 1：#256 は RDNA3（gfx1100）向けに chunked_sgmv_expand、gate_up_lora_b、sgemm_lora_b、per_group_transpose、silu_and_mul、fused_rmsnorm を追加し、Radeon PRO W7900D でチューニングとテストを実施。fused_rmsnorm を除き、出力は汎用実装とビット単位で一致する。LoRA 側では16ビット入力のメモリアクセスを2バイトから16バイトに引き上げ、fp32 時はランクループを小タイル上の FMA に変更し、汎用カーネルのレジスタスピルを回避した。
  • AMD 性能ライン 2：#271 は同一アーキテクチャ向けに decode_attention、decode_grouped_attention、extend_attention、log_scaling_tau を追加。前者2つは分割 KV カーネルを共有する。1つの program が某シーケンスのクエリヘッド群と KV キャッシュの1区間を担当し、2つ目のカーネルが log-sum-exp で分割結果をマージする。ヘッドブロックサイズは「96個の計算ユニットを埋められる」最大値を取り、グリッドがアイドルユニットを残す場合にのみシーケンスを分割する。
  • 付随整理：#270 のバッチマージで第9バッチのオペレータをメインラインに統合；#263 はクロスバックエンド検証の再利用可能なスキルドキュメントを追加；#274、#275 はオペレータスイート内のモデルブランド命名を削除し、sglang_fl_ プレフィックスに統一；#272 はベンチマーク入力関数とオペレータシグネチャの不一致を修正；#276、#278 はリモートタスク成果物のクリーンアップルールを厳格化。
  • 判断：このリポジトリは本調査期間に2つの役割を担った。日中は競賽オペレータのスループット口であり、午後は AMD ワークステーションの性能補完に移行した。競賽バッチはカバレッジをもたらし、gfx1100 バッチは実ハードウェア上の実行可能性をもたらす。両者は補完的である。ただし、競賽 PR のレビュー深度（多くはバッチマージ）と AMD 側のビット単位一致要求は、明らかな品質勾配を形成している。

1.7 FlagTree と FlagGems-vllm：Hopper 誤コンパイル修正、玄鉄 MM モデルパッケージ v1.1.0（11-02）

日付：2026-11-02　情報源：FlagTree PR #1236 · FlagTree PR #1460 · FlagTree PR #1451 · FlagTree PR #1314 · FlagGems-vllm PR #1030 · FlagGems-vllm PR #1042 · FlagGems-vllm PR #1038

  • 玄鉄コストモデル：#1236 玄鉄 ZW810E の MM/MV コストモデルパッケージ 1.1.0 をサポートし、FlagTune モデルディレクトリに新規エントリを追加するとともに、モデル契約が順序付き configs リストを受け入れるようにした——候補ごとにパラメータ名と有効値を検証し、config_space を同時に宣言する契約を拒否する。このパッケージには 8 個の BF16 の flaggems/mm バリアント（mv と共用する gemv_ppu を含む）と、1.0.0 を踏襲する 2 個の flaggems/mul モデルが含まれる。
  • Hopper 誤コンパイル：#1460 TritonGPU のパイプライン化 cp.async 降級と WGMMA オペランドバッファ再利用の問題を修正。エラーではなく誤った計算結果となる類型である；#1451 WGMMA の warp 選択を上流 MMAv3 に整合させ、NVIDIA と摩尔線程の両側をカバー；#1314 2 回の非同期 TME コピーの間に membar バリアをスキップ、摩尔線程側のパス最適化である。
  • FlagGems-vllm オペレータ：#1030 mrope のオペレータ一覧エントリを追加；#1042 PPU 側の FP8 量子化出力処理と逆 RoPE の epsilon セマンティクスを修正；#1038 天数と玄鉄向けに chunk_kda を最適化；#1019 GLM-5.2 の形態向けに grouped_topk を最適化；#959 qwen4 の int64 オフセットと PLE 状態のインプレース更新同期を修正；#1035 fused_q_kv_rmsnorm のベンチマーク呼び出しを新 API へ移行；#1047 循環 GDN のネイティブベースライン准入を修正。
  • 判断：FlagTree のこの一群はすべて「コンパイラの正確性」であり新機能ではない——誤コンパイル、warp 整合、バリア冗長の 3 項目はそれぞれ誤計算、結果ドリフト、余分な同期に対応する。統一コンパイラにとって、この種の修正は新規バックエンドの追加よりも下流が最適化を有効にできるかどうかを左右する。

1.8 FlagTrain と FlagBLAS：KMCompiler 八筆のオペレータ、MUSA L1 BLAS が着地（11-02）

日付：2026-11-02　情報源：FlagTrain PR #32 · FlagTrain PR #40 · FlagTrain PR #36 · FlagTrain PR #39 · FlagTrain PR #47 · FlagBLAS PR #157

  • FlagTrain オペレータ：マージされた八筆は KMCompiler の NVIDIA ラインに集中——weighted_squared_relu_impl（Ascend 注記を含む）、fused_h_aggregate の順伝播・逆伝播、bias_swiglu_impl、scaled_masked_softmax_cuda の順伝播・逆伝播、fused_proj_rms_compute_h。いずれも Triton カーネルで実装され、訓練で常用される融合点ごとにグループで補完された。
  • 依存関係とプロセス：#45 uv 管理下のイメージ実行時保持の問題を修正；#43 compared_speedup と speedup の統計基準を修正；#47 バックエンドオペレータ特化実装の循環呼び出し異常を修正、ルーティング層のディスパッチ欠陥である。
  • FlagBLAS：#157 MUSA 向けに L1 BLAS バックエンドと muBLAS の正確性・性能参照を追加し、AMAX、AMIN、ASUM、AXPY、COPY、DOT/DOTC/DOTU、NRM2、ROT/ROTG/ROTM/ROTMG、SCAL、SWAP をカバー。これで BLAS の L1 層は摩尔線程側で対照可能な実装を持つことになった。
  • optest の整備：#26 オペレータ除外リストを追加、#27 オペレータ結果集計統計を追加、#25 100% カバレッジを強制、#24 Python 品質チェックを追加——テスト基盤自体が製品として保守され始めた。
  • 判断：訓練側と大規模モデル推論側の分業がより明確になった：FlagTrain は訓練融合オペレータを、FlagGems-vllm は推論パスを、FlagBLAS は基礎線形代数を担う。三者は同一のテストと品質ゲートを共有しており、これは各々がオペレータを拡張するよりもクロスリポジトリのリグレッションを低減できる。

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

2.1 チャネル核查：24 組のクエリでコンポーネント級のヒットゼロ、CSDN と HN は期間内に新記事なし（11-03）

日付：2026-11-02 ~ 2026-11-03　情報源：Google News FlagOS 検索 · CSDN FlagOS コラム · Hacker News 検索 · 智源コミュニティ

  • 中国語クエリ：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen の7組は14日間の調査期間内でゼロヒット。智源研究院 オープンソース、智源研究院 チップ、智源 大規模モデル オープンソーススタック、清微智能、摩尔線程 オープンソース、沐曦 オープンソース、燧原科技、国産算力 オープンソースソフトウェアスタックなど8組は7日間の期間内で計17件、各項目の見出しを確認した結果、すべて社会・金融・イベント系の記事であり、FlagOS コンポーネントを指すものは1件もなかった。
  • 英語クエリ：FlagOS、FlagGems、BAAI FlagOS、flagos-ai、BAAI open source AI system stack、Tsingmicro、Moore Threads open source の7組はいずれも期間内でゼロヒット。
  • コラム確認：CSDN FlagOS コラムのトップページにある52件の記事リンクについて、各記事の日時を確認したところ、最新の記事は依然是10-29の「大規模モデル推論の救世主——1つのプラグインでマルチチップ適応を実現」であり、期間内に新規記事はなかった。ページに表示される11-03の日付はページ側の当日マークであり、記事の日時ではない。
  • コミュニティと HN：智源コミュニティの検索ページはクライアントサイドレンダリングのため、取得できたのはフレームページのみで有効な項目はなく、トップページでの確認を基準とした。HN Algolia の8組のクエリ（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）は5日間の期間内で直接ヒットはゼロ。
  • メンバー公式サイト：9社のメンバー企業公式サイトのニュースページでは、11-02から11-03の日付のヒットはなかった。地平線のニュースページは取得に失敗し、海光と智源のトップページはスクリプトレンダリングの短いページのため、いずれも項目リストを取得できなかった。
  • 結論：ニュース側でコンポーネントレベルの新規項目がゼロであることは平穏な期間であり、前回と一致する。本レポート本文は GitHub の事実を主とし、ニュース側はエコシステム背景の2件のみを残し、いずれも周辺イベントとして明記する。

2.2 エコシステム観察：烏鎮サミット開幕、オープンソーステーマのエコシステム体験館は11-05まで展示（11-02）

日付：2026-11-02　情報源：新華社報道（東方財富転載） · 新華網浙江

  • 会期：2026年世界インターネット大会烏鎮サミットは11-02から11-05まで浙江省烏鎮で開催され、濮院に分科会場が設けられ、観客予約プラットフォームはすでに開放されている。
  • オープンソースの主线：サミットの重点併設企画である「オープンソーステーマエコシステム体験館」は11-01から烏鎮世界インターネット科技館で開放され、展示は1階から3階にわたり、人工知能オープンソース・オープン化の重大科技成果と国家人工知能応用中試拠点の建設成果を初めて集中的に展示する。1階には2大テーマ特別展とオープンソース体験エリア、3階にはオープンソース会客厅が設けられ、会期中に「烏鎮 Talk·オープンソース青年説」「科创之夜」などのイベントが開催される。
  • FlagOS との関係：期間内の公開報道に FlagOS やそのコンポーネントは登場しておらず、本項目はオープンソース議題の外部環境の記録にとどめ、帰因はしない。FlagOS 側で展示やリリースがあれば、公式チャネルで別途確認する必要がある。
  • 注目点：オープンソース議題が国家級サミットの独立した展示館に格上げされたことは、「オープンソース・オープン化」の政策叙事における位置が引き続き上昇していることを示す。FlagOS のような統一ソフトウェアスタックにとって、これは叙事上の追い風であると同時に、魔搭などのモデルコミュニティとの展示枠の競争がより直接的になることを意味する。

2.3 周辺エコシステム：九源連合体が飛騰、TileLang、商湯の3項の連合成果を発表（11-02 振り返り稿）

日付：2026-11-02（会期 10-31）　情報源：鳳凰網海南産経報道 · 新浪転載 大会開幕報道

  • 事件：2026 GAI+C 人工知能+大会の「智能計算系統イノベーションとオープンエコシステム」分科会が10-31に北京で開催され、振り返り記事が11-02にネット上で公開された。分科会は九源智能計算系統生態連合体と北京市人工知能協会が主催し、会場で「九源×飛騰」「九源×TileLang」「九源×商湯マルチモーダル大規模モデル学習推論スイート」の3つの共同成果を発表するとともに、2026秋季啓元人工知能大賽を始動した。
  • ナラティブ：中国工程院院士の鄭緯民氏は大会基調報告で、国産算力の「カードはあるが使いにくい、煙突型適配」という問題を直接指摘し、統一ソフトウェアスタックによって「1つのコード、修正不要」のクロスプラットフォーム実行を支えることを提唱した。これはFlagOSの技術的主張と高度に同構だが、主体は別のエコシステムライン（九源連合体、啓元実験室）である。
  • FlagOSとの関係：報道ではFlagOSに言及していない。本項は並行するエコシステムの動きとして記録し、国産統一ソフトウェアスタックの競争格局を観察するために用いるもので、FlagOSプロジェクトの進展には計上しない。
  • 要観察：九源がTileLangとの共同発表を選んだことは、コンパイラ層が各エコシステム連盟の結盟点になりつつあることを示す。FlagOS側の対応資産はFlagTreeとTLE言語拡張である。両ラインの「統一コンパイラ」という層における路線差異は、後続の調査期間で引き続き追跡する価値がある。

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

3.1 達摩院玄鉄：専用オペレータ、MMコストモデル、chunk_kdaの三線を同日に推進（11-02）

日付：2026-11-02　情報源：FlagGems PR #8240 · FlagTree PR #1236 · FlagGems-vllm PR #1038

  • オペレータ層：13個の玄鉄専用オペレータが43分でFlagGemsにマージされ、特殊関数、3次元畳み込み、量子化LSTM、行列ノルム、プーリング逆伝播をカバーした。これらの項目に共通するのは、汎用Triton実装では玄鉄での収益が低く、専用化後はオペレータライブラリのデフォルト分派に直接組み込める点である。
  • コンパイル層：#1236は玄鉄ZW810EのMM/MVコストモデルパッケージを1.1.0に上げ、FlagTuneモデルディレクトリに組み込み、自動チューニング契約が明示的なconfigsリストを受け入れるようにした——パラメータ名と正当な取值ごとに検証し、config_spaceとの併存記法を拒否する。このパッケージは8個のBF16 mm変体と2個のmulモデルからなり、玄鉄における自動チューニングの最初の完全なコストモデルである。
  • 推論層：#1038はchunk_kdaに天数と玄鉄の2つのバックエンドの最適化を補完するもので、FlagGems-vllmの長系列パスに属する。
  • 判断：玄鉄のこの日の動きはオペレータ、コンパイル、推論の3層に分布し、いずれも「専用化」を指向しており「汎用互換」ではない。これはRISC-V高性能コアとしての玄鉄の位置づけと一致する：まずロングテールオペレータの専用実装を補完し、次にコストモデルが自動チューニングを駆動し、最後に推論フレームワークで実現する。

3.2 昆侖芯：XPU3 foreach契約修復と14件の性能収束（11-02）

日付：2026-11-02　情報源：FlagGems PR #8038 · FlagGems PR #8034 · FlagGems PR #8123 · FlagGems PR #8245

  • サイレントエラー：#8038はforeachのファストパスが要素数のみを比較し形状を比較しないため、形状が異なり要素数が同じテンソルリストがすべて先頭テンソルの形状を継承し、出力はエラーも報告せず境界超過も起きないことを指摘した。修復は完全な形状による准入判定とし、16個のスカラー出力を単一基底アドレッシングに、リスト出力をフラットバッファに統合した。
  • グリッドとスロット：#8034はコミットJITの前に自動チューニンググリッドを先に評価する；#7976はprogram_id(0)からforeachのスロットインデックスを取るように変更する；#7956はスカラー解析の三値戻り値のアンパックを修復する。
  • 性能パッチ：#8056、#8245、#8108、#8107、#8030、#8105、#8111、#8049、#8248の計9件で、点態ファストパス、pool3d逆伝播融合、Chebyshev展開、Jacobiブロック化、linspace単一公式をカバーする。
  • ロールバック：#8123はBF16点態最適化を回帰を理由に撤回する；#8245は別案でやり直し、#8052の一次元tile再構築を撤回する。一撤一補は当該パスが依然試行錯誤中であることを示す。
  • 判断：昆侖芯の当日の価値は性能数値になく、サイレントに計算を誤る形状契約を修復した点にある。マルチバックエンドオペレータライブラリにとって、この種の欠陥は10倍遅いことよりも危険である——ベンチマークでは発見されず、下流モデルが「精度異常」の形で遭遇するだけである。

3.3 昇騰と海光：W8A8 INT8 の GEMM と BMM の二つの実装（11-02）

日付：2026-11-02　情報源：FlagGems PR #6060 · FlagGems PR #7741 · FlagGems PR #7774 · FlagGems PR #7760

  • 昇騰 GEMM：#6060 は mm_w8a8_int8 と mm_w8a8_int8_out に昇騰バックエンドを追加し、公開入口のディスパッチを通す。オペレータは事前量子化された INT8 の A と B、FP32 のスカラーまたは行ごと列ごとの scale、オプションの bias を受け取り、整数乗加算後に両側の scale と bias を適用し、BF16、FP16 または FP32 を出力する。小さい M と狭い N ではベクトル乗加算カーネルに進み、各セグメントの FP32 縮約は 1024 個の INT8 積を超えないようにして整数部分の精度を保証する。非対称ゼロポイントはサポートしない。
  • 海光 BMM：#7741 は海光にチャネル級 bmm_w8a8 を補い、既存の scaled-MM カーネルと tile 選択を再利用し、INT8 行列乗算、FP32 チャネルスケーリング、出力変換を一つのカーネル内に融合する。
  • 精度修正：#7774 は昇騰側で二つのオペランドを先に昇格してから CANN libdevice の pow を実行し、混合精度下でのアンダーフローと精度損失を回避する。
  • Hopper 性能：#7760 は TMA パイプラインで FP8 W8A8 の BMM を最適化し、NVIDIA 側の対応する最適化である。
  • 判断：両社は同じ調査期間にそれぞれ W8A8 パスを一つ補った——昇騰は GEMM の完全なセマンティクス（行ごと列ごとの scale、三種類の出力 dtype を含む）を選び、海光は BMM のチャネル級スケーリング再利用を選んだ。違いはセマンティクスカバレッジの広さと実装再利用のトレードオフにあり、各社の下流モデルが量子化形態に求める異なるニーズも反映している。

3.4 摩尔線程：Conv1D 真の一次元 GEMM が 26 個のベンチマーク例すべてを 0.8 倍ライン超えに（11-02）

日付：2026-11-02　情報源：FlagGems PR #6754 · FlagGems PR #7428 · FlagGems PR #6903 · FlagBLAS PR #157 · FlagTree PR #1314

  • Conv1D の結果：#6754 は MTT S5000 に conv1d バックエンドカバレッジを追加し、公式 conv1d_padding ベンチマークを 18/26 例達成から 26/26 例が 0.80 倍 torch 以上に引き上げた。以前はすべての FP32 K3/K5 padding 例が 0.41 から 0.53 倍にとどまっていた。
  • 三層の改法：第一に、conv1d は元々 MTHREADS カバレッジがなく全て汎用 conv2d を通り、小グループ形状では padding が実体化され、W=1 形状では単一の有効 OW チャネルしかヒットしなかった。ルーティング変更後は冗長な padding と bias 割り当てを除去し、退化した幅のディスパッチを修正した。第二に、専用の Triton-MUSA Conv1D カーネルを新設し、M が N 掛ける Lout に等しいとして三次元グリッド分割を行い、出力チャネルは除算剰余を行わなくなった。第三に、重みをカーネル幅、入力チャネル、出力チャネル順に事前パッケージし、精度補償付きの SQMMA と組み合わせた。
  • 付随対応：#7428 は S5000 上の one_hot の検証と推論を最適化し、#6903 は空インデックスを index_add の空操作とみなし、#157 は MUSA の L1 BLAS を補い、#1314 は二回の非同期 TME コピー間で membar をスキップする。
  • 判断：これは本調査期間で珍しい「ベンチマークをすべてライン超えさせた」完全な事例である——ルーティング、専用カーネル、重みレイアウト、命令級精度補償の四層を同時に改め、前後の対照を示した。他のバックエンドにとって複製可能なテンプレートとなる。

3.5 沐曦、天数、清微、燧原と地平線：片側はオペレータを補い、片側は契約を補う（11-02）

日付：2026-11-02　情報源：FlagGems PR #7590 · FlagGems PR #7015 · Torch-FL PR #704 · Torch-FL PR #702 · FlagGems-vllm PR #1038 · FlagDNN コミット

  • 沐曦：#7590 で triangular_solve のデフォルトパスと out パスを最適化；#7015 で cudnn_batch_norm のフォワードと out を追加し、対になる逆方向を修正；Torch-FL #702 で MetaX SDPA テストケースのスキップ理由を修正——従来は fp32 に帰因していたが、実際の原因は別にあり、テスト信頼性の修復に属する。
  • 天数：#1038 で chunk_kda に天数バックエンドの最適化を追加；FlagDNN で iluvatar の GPU 名登録を修正（単一コミット）；FlagGems #7664 で apply_repetition_penalties のベンチマークを Iluvatar に導入。
  • 清微：Torch-FL #704 で tsingmicro を conf と登録セットの一貫性チェックに組み入れ、これまで同プラットフォームは6プラットフォームの対象外とされ、設定と登録セットの不一致を CI が捕捉できなかった。純粋なテスト変更ではあるが、清微側の契約上の欠落を補った。
  • 燧原：調査期間内は審査中の PR がわずか1件のみで、KernelGen の Enflame 側で4オペレータの CUDA 専用デバイスガードを修正するもの（#8104）であり、まだマージされていない。
  • 地平線：本調査期間に新規コミットや審査中の PR はなし；前調査期間の BPU 畳み込みとプーリングのパスは本調査期間では継続されなかった。
  • 判断：5社の動きは2種類に分類される——沐曦と天数はオペレータとベンチマークを補充し、清微はテスト契約を補充し、燧原と地平線は静穏期にある。メンバー企業にとって、毎日のマージ一覧に継続的に現れるかどうか自体が、投入強度の直接的な指標である。

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

日付：2026-11-02 ~ 2026-11-03　情報源：flagos-ai 組織リポジトリ · build-infra PR #1589 · FlagQuantum PR #1004 · FlagGems PR #8240

  • AMD ラインは一つのウィンドウ内で三層を補完：ビルド側では FlagTree の amd パッケージングラインを新設し、A/B 照合で等価性を証明（maxdiff 1.526e-05、9/9）。ランタイム側では rocm7.2.4 の torch クロージャを vLLM 0.32 の固定組み合わせに整合。オペレータ側では gfx1100 向けに LoRA とアテンションを合わせて十個のオペレータを追加。三者を合わせることで、AMD は「バックエンドがある」から「追跡可能なビルド、再現可能なランタイム、チューニング可能なオペレータがある」へと変わった。
  • 量子スタックは「検収単位での納品」段階へ：単日 21 件のマージが UP（セマンティクス）、AO（算術）、PF（性能）の三ラインに分布し、各ラインに独立したベースライン、oracle、失敗即赤の証拠を備える。この分割により、量子コンパイラの各変更が既存の帳簿でコストを測定でき、単点の加速比を追求するよりも長期的な進化を支えられる。
  • 玄鉄は専用オペレータをバッチ化：13 個の専用オペレータを 43 分以内にマージ、平均 3.3 分/件、特殊関数、三次元畳み込み、量子化 LSTM、プーリング逆伝播などロングテール項目に集中。これは KernelGen の玄鉄ラインがバッチ供給能力を備え、レビューもバックエンドごとに並行消化できることを示す。
  • レビュー吞吐量が現在の真のボトルネック：本ウィンドウのマージ 162 件、新規 192 件、審査中総量 311 件、うち FlagGems 一リポジトリで 210 件（新規 148）。マージ量は直前の 24 時間ウィンドウ比 11.5% 減、新規量は 128.6% 増——ラインはフル稼働、レビューは逼迫という構造は変わっていない。
  • 2.3.0 は依然イメージ先行で停滞：base 層と寒武紀、沐曦、海光、AMD の四層はいずれも 2.3.0 名義で changelog 日付を回填し、ランタイムイメージもバックエンド別にプッシュ済みだが、community の release/2.3 マニフェストは依然 404、GitHub Release はゼロ新增。前回比で実質的進展はなく、本作業週でマニフェストをフリーズしなければ、リリースウィンドウは次版計画に圧迫される。
  • ニュース側は連続二度目の平穏なウィンドウ：24 組の中英クエリでコンポーネント級のヒットゼロ、CSDN コラムの最新記事は依然 10-29、HN は直ヒットゼロ。エコシステム背景の二件（烏鎮オープンソース展館、九源連合体の三件共同発表）はいずれも周辺イベントと明記され、プロジェクト進展には計上されていない。

情報源核查表

情報源 核查結果
GitHub org flagos-ai（61 リポジトリ） 16 リポジトリがウィンドウ内でプッシュ、272 コミット、162 マージ、311 審査中（新規 192）
GitHub Release / Tag 原子核查（31 リポジトリ / 8 リポジトリ） ウィンドウ内ゼロ新增；FlagCX v0.14.1（11-01 00:10）と FlagTree 0.7.1a1+tsingmicro3.6（10-29）はいずれもウィンドウ外
community リリースマニフェスト release/2.3 下のマニフェストファイルは 404 を返却、release/2.2 は掲載中
release-info サイト ウィンドウ内に三回の gh-pages 自動デプロイ、いずれも build-infra コミットに対応、独立したリリース動作なし
Google News（24 組中英クエリ） 17 件の候補はすべて社会、財経、イベント系記事、コンポーネント級ヒットゼロ
CSDN FlagOS コラム 52 記事リンク、最新は依然 10-29、ウィンドウ内に新記事なし
HN Algolia（8 組） 直ヒットゼロ
智源コミュニティ hub.baai.ac.cn 検索ページはクライアントレンダリング、フレームページのみ取得、条目なし
メンバー機関公式サイト（9 社） 11-02 から 11-03 の日付ヒットなし；地平線は取得失敗、海光と智源のトップページはスクリプトレンダリングの短ページ

完全情報源リスト

[21] FlagQuantum PR #1018（PF-00 レイテンシとRSSベースライン） — https://github.com/flagos-ai/FlagQuantum/pull/1018