調査期間：2026-09-05 10:18 ~ 2026-09-06 10:18 北京時間 情報源：GitHub（org: flagos-ai 52 リポジトリ + commit search 21 件全量 + デフォルトブランチ per-repo 検証 + tags/releases 日付検証）、Google News RSS（中英文 13 組クエリ、プロキシ経路正常）、HN Algolia、Tavily 検索、智源コミュニティ hub.baai.ac.cn、FlagOS CSDN 公式コミュニティアカウント（詳細は付録）

インデックス

    1. オープンソースプロジェクト進展（GitHub 動向）
      • 1.1 FlagSparse「more backends」：バックエンドマトリクスを5社に拡大——MetaX 実装、摩尔線程/昇騰を登録、デバイス抽象化を269箇所移行（09-05）
      • 1.2 build-infra：vLLM デリバリーライン——燧原デュアル SDK ライン/寒武紀イメージ tag 一括登録、wheel ビルドを host-side パッチ機構に変更、天数智芯が FlagGems attention パスを注入（09-05/09-06）
      • 1.3 build-infra：寒武紀 0.20.2 コールド初回実行文字化けの根本原因を特定——flag_gems copy_ が MLU デバイス状態を汚染、ブラックリスト修正後に真のデリバリー（09-05）
      • 1.4 build-infra：sglang 0.5.18 コールドスタート治理——タイムアウト調整ノブ/レディネスゲーティング/watchdog を実装、摩尔線程 0.5.18 デリバリー記録が完備（09-05/09-06）
    1. ニュース報道とエコシステム
      • 2.1 コンポーネント級ニュースは4期連続の平穏な調査期間、検索による期間内ヒットはゼロ（09-05~09-06）
      • 2.2 エコシステム参考：智源コミュニティが SGLang ラウンドテーブル対談を転載——「検証可能性が次のボトルネック」（09-05）
    1. メンバー機関の深掘り
      • 3.1 メンバー機関に期間内の新規動向なし（09-05~09-06）
      • 3.2 FlagSparse 共同構築チームの背景：中国科学院計算技術研究所系 AlphaSparse のデュアルチャネルが継続的にマージ（09-05）
    1. まとめ
  • 付録：完全な情報源リスト

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

期間総覧：org 内52リポジトリのうち7つが期間内にプッシュあり、commit search は期間内コミット21件にヒット（build-infra 17件、FlagSparse 4件）；tags/releases 検証では期間内に新規 tag なし、新規 release なし（FlagSparse v0.3.0-rc0.post1 は 09-01 リリースで期間前、vllm-plugin-FL v0.3.0-rc0 は 08-24 リリース、FlagGems v5.4.0.dev0、FlagTree v0.4.0 シリーズ、build-infra v2.1.1 はいずれもそれ以前）；docs、release-info、sglang-plugin-FL、vllm-plugin-FL、FlagTree の pushed_at 変化はデフォルトブランチ commits 検証によりいずれも非デフォルトブランチ（PR ブランチ）の動作であり、期間内の実質的マージなし——2.2 のリリース安定期が継続。本期間の主線：一、FlagSparse（スパースオペレータライブラリ）のバックエンドマトリクスが CUDA/DCU の2バックエンドから5バックエンドに拡大——「more backends」（PR #51）がデバイス抽象化移行を完了（269箇所の CUDA-specific 呼び出しを抽象化）、MetaX（沐曦 MACA/曦雲 C550）バックエンドが「CUDA からの移植 + 模擬検証」形態で実装され spsv v0.1 を走通、摩尔線程（MUSA）と昇騰（CANN）は provisional バックエンドとして登録；二、build-infra の vLLM デリバリーラインが「コールドスタート意味論検証とデリバリー監査」段階に突入——寒武紀 0.20.2 コールド初回実行の文字化け根本原因が完全に特定され（flag_gems copy_ が MLU デバイス状態を汚染）、ブラックリストの反復修正により真のデリバリーを実現（08-26 の意味論ゲートなしの偽陽性グリーン判定を覆した）；三、天数智芯のデリバリーパスが F パス（FlagGems）優先に確定——0.20.2 旧メンテナンスライン有効化 + VLLM_FL_USE_FLAGGEMS_ATTN=1 注入 + symm-mem インポート guard パッチにより、09-04 の「T パスはデリバリー不可」判定と閉ループを形成。

1.1 FlagSparse「more backends」：バックエンドマトリクスを5社に拡大——MetaX 実装、摩尔線程/昇騰を登録、デバイス抽象化を269箇所移行（09-05）

情報源：FlagSparse PR #51（dc076010b2）、commit 41c7c102（spsv on metax v0.1）、docs/METAX_TESTING.md、README バックエンドマトリクス

  • 09-05 10:59～12:18、FlagSparse デフォルトブランチに連続 4 件のコミット（直接プッシュ 41c7c102/7f41348d + 上流マージ 0cad7f78 + PR #51「more backends」が 12:18 にマージ、計 23 ファイル）、すべて外部疎計算チーム NCIA-AlphaSparse（コミットメールドメイン ict.ac.cn、中国科学院計算所の背景；NCIC-AlphaSparse はその上流 org ミラー、3.2 参照）によるもの。これは昨日のレポートで収集漏れとなっていた 09-04 11:11 のコミット fb18e881「metax musa ascend added, need to check」（調査期間直前の開始）の着地版である。
  • バックエンドマトリクスとデバイス抽象化の移行：README に 5 バックエンドの表を新規追加——CUDA / DCU(ROCm) / MetaX(MACA、曦雲 C550) / Moore Threads(MUSA) / Ascend(CANN 910B)；sparse_operations/ 配下の 269 箇所の CUDA-specific 呼び出しを抽象化完了（189 箇所を _ACCEL.* に + 82 箇所を _is_accel_tensor() に変更）。CUDA/ROCm/MACA の三者の _ACCEL はいずれも torch.cuda に解決され、バイト単位で等価、kernel はゼロ変更；Moore Threads と Ascend は torch.musa/torch.npu が CUDA-compatible でないデバイス型のため、暫定的に torch.sparse にフォールバック（provisional と注記）。
  • MetaX 検出メカニズム：MACA は CUDA とソース互換（マシン上で torch.version.cuda に値があり、torch.version.hip は None）、既存の ROCm 判定基準では MetaX と NVIDIA を区別できない——検出は FLAGSPARSE_BACKEND 環境変数 → MetaX 専用 torch.version 属性 → MACA SDK 環境（MACA_PATH/HOME）→ デバイス名/C550 型番文字列の順に段階的に判定し、ドキュメントでは実機で明示的に pin することを推奨（FLAGSPARSE_BACKEND=metax、FLAGSPARSE_MACA_MODEL=c550）。
  • MetaX 実装状態（正直な声明）：09-05 10:59「spsv on metax v0.1」——疎三角求解（spsv）が MetaX バックエンドで初版を走通せた（spsv.py とテストドキュメントの変更）；ただし新規追加された 274 行のドキュメント METAX_TESTING.md には明確にこう書かれている：MetaX パスは「一行も実機で走らせていない」、コードは CUDA パスから移行したもので、インポート/構文/ディスパッチパスのチェックのみ実施（NVIDIA マシン上で FLAGSPARSE_BACKEND=metax により模擬）、ドキュメントの目的は実機で走らせ、チューニングパラメータを実測値に置き換えることである。

解読：FlagSparse は 2.2 サイクル内でいち早く RC tag（v0.3.0-rc0.post1、09-01）を完了した後、急速にバックエンドマトリクスを補完——8/20 以降、同一の外部チームがマージした DCU サポート（cuda/dcu merge → dcu tests → dcu bsr spmv/spmm）が一路、MetaX/MUSA/Ascend の 5 バックエンドまで拡張された。注目すべき点は三つ：一つ目は デバイス抽象化層（_ACCEL パターン）により「新規バックエンド追加」がオペレータの変更から検出とディスパッチの変更へと変わったこと、これは疎ライブラリのマルチチップ化における重要なアーキテクチャ決定である；二つ目は MetaX が「CUDA 移行 + 模擬検証」を先行させ、実機検証をドキュメント化してフォローするという、FlagGems/build-infra の「先に登録、後に検証」というエンジニアリングリズムと一致しており、明瞭に注記された provisional リリースであって誇大な宣称ではない；三つ目は 疎ライブラリが FlagTree（清微 DSA、09-04）、build-infra（イメージマトリクス）と同期してマルチチップ化を推進しており、FlagOS 2.2 サイクルの「バックエンド拡囲」がコンポーネント層で全面的に展開されていることである。

1.2 build-infra：vLLM デリバリーライン——燧原デュアル SDK ライン／寒武紀イメージ tag 一括登録、wheel ビルドを host-side パッチ機構に変更、天数智芯が FlagGems attention パスを注入（09-05/09-06）

情報源：#742（e810bc2362）、#743（d8e6dba980）、#744（6c8dddab33）、#745（546d46e5ad）、#750（0b8f6205ce）、#753（f64f4af640）

  • アプリケーションイメージ tag の一括登録：09-05 21:24/21:29 に #742/#743 が燧原 enflame-tops1.10.6 と tops1.9.10 の 2 つの SDK ラインに対して同時に vllm app イメージ tag 2.1.2-0.2.1_gc2e496d.d20260905 を登録（同一プラグインソースフィンガープリントが燧原の 2 つのツールチェーンラインを跨ぐ）；22:01 に #744 が寒武紀 cambricon-neuware4.4.3 の tag 2.1.2-0.2.1_gcab2270.d20260905 を登録——このイメージは 1.3 で述べた文字化け修復版のデリバリーである（plugin wheel 0.2.1+gcab2270）。
  • #745（22:08）：vLLM wheel ビルドを host-side source patch 機構に変更——ソース tarball はホストマシンでダウンロード／展開／パッチ適用を完了し、ビルドコンテナはパッチ適用済みのソースツリーのみを消費して empty wheel ビルドと repack を行う（イメージの packaging/sglang 既存機構；制約は明確：コンテナ内ではパッチを当てず、変更はビルド監査面内に留める；パッチ hunk が無効化された場合は loud fail とし、未パッチの wheel 流出を防止）。併せて 2026-08-23 以降 nvidia も empty（ソースビルド）モードに統一され、公式 wheel の pip ダウンロードモードは廃止されたことを確認。最初のパッチ 0001：vllm/distributed/parallel_state.py の torch.distributed._symmetric_memory トップレベル副作用インポートに try/except guard を追加——vendor torch が 2.8 未満（iluvatar corex 2.7.x）ではこのモジュールが存在せず、モジュールレベルのインポートがプラグインの guard が効く前にエンジン起動を中止してしまう；symm-mem は明示的な opt-in 時のみ vLLM に使用される（デプロイ時はデフォルト無効）ため、guard は安全かつ汎用的である。
  • 天数智芯（iluvatar）デリバリー形態の確定：#750（23:32）が corex4.4.0 の vllm 0.20.2 旧メンテナンスライン app を有効化；#753（09-06 09:44）が corex4.4.0 の vllm app env に VLLM_FL_USE_FLAGGEMS_ATTN=1 を注入（FlagGems attention を強制使用）。

解釈：09-04 #722 の「iluvatar 0.24.0 T パスはデリバリー不可」判定と併せて見ると、build-infra は数日のうちに天数智芯のために完全な F パス優先デリバリー形態を敷設した：旧メンテナンスライン（0.20.2）app の有効化＋FlagGems attention の強制注入により、アテンションとサンプリング計算がベンダー Triton パスの apply_top_k_top_p 欠陥を回避できる；#745 の symm-mem guard はさらに vendor torch 2.7.x のモジュール欠落によるエンジン起動即クラッシュを解決する。これらの回避はいずれも wheel レベル（パッチをビルドに焼き込み）と環境レベル（env 注入）で行われており、T パス自体の修復は依然としてプラグイン側の TODO である——「F はデリバリー可能、T は修復待ち」という分化の記録は蓄積を続けている。

1.3 build-infra：寒武紀 0.20.2 コールド初回実行の文字化け根本原因特定——flag_gems copy_ が MLU デバイス状態を汚染、ブラックリスト修復後に真のデリバリ（09-05）

情報源：build-infra #748（caccf829a3）（cambricon.md に再検証記録を追加）、vllm-plugin-FL PR #411

  • 事象の起点：cambricon-neuware4.4.3 の vLLM 0.20.2 デリバリは 08-26 に「E2E 通過」とマークされていた——しかし当時は意味論ゲートがなく、マトリクスの緑ラベルは実際には偽陽性であった。09-05 に「コールド初回実行の意味論アンカー」（既知の答えを持つプロンプトでコールド状態の意味論照合を行う）でリリース版 app イメージを再検証した際に文字化けが露呈し、修復後に初めて真のデリバリとなった。
  • 根本原因：flag_gems 5.3.5 の libentry.py LibTuner.run() は config DB cache-miss 分岐で生きたデコードテンソルに対してオンライン計時 bench（triton do_bench の reset-cache ストーム）を実行する → MLU デバイス状態を汚染 → コールド初回実行（空の config DB）で出力が文字化け（再現文字列 “enim enim enim…”）；ウォーム DB（cache ヒット）はクリーン。0.20.2 特有——同じ runtime 底層スタックの 0.24.0 はクリーン；かつ argmax 問題ではない（ブラックリストで argmax を除外しても依然文字化け）。
  • 修復路線（ユーザー裁定）：リポジトリ既存のブラックリスト反復法（汚染オペレータを一つずつ torch_mlu に戻す）を採用し、libentry bench の挙動は変更しない——ある反復でオンライン bench を単発の非計時 launch（等価な「最初にコンパイル可能な config」路線）に置き換えることを試み、実測で文字化けは解消したがユーザーに否決された（上流の tuning 意味論を変更しない）。
  • 判定チェーン（コールド = 毎回 flag_gems config DB を削除して空にする）：index のみブラックリスト → 依然文字化け；copy_+to_copy を除去 → 文字化けを逐字再現；copy_ を戻す → クリーン；copy_ 単独 / copy_+index → クリーン。最小汚染集合 = flag_gems copy_；to_copy/fill/add/sub/fused-norm はリクエスト中で通常通り bench されるが無害。
  • コミットとデリバリ：vllm-plugin-FL PR #411（amend）で cambricon.yaml の flagos_blacklist を [index] から [index, copy_] に拡張 → head cab2270 → plugin wheel 0.2.1+gcab2270.d20260905；copy_ を torch_mlu に戻すことは 4.7.2/0.24.0 に対して意味論的に等価（config 共有、下流で監査済み）、初回リクエストのスループット約 1.3 tok/s で実質的な損失なし。最終デリバリ app イメージ 2.1.2-0.2.1_gcab2270.d20260905（config 内蔵形態、ブラックリスト env なし）；全コールド状態で再検証（serve 前に ~/.flaggems と ~/.triton を削除）：初回リクエスト 200/168 秒（shape ごとのコンパイルを含む）で出力クリーン、ホットリクエスト 200/2 秒/7.75 tok/s；当該バックエンドは T-only 形態（4.4.3 に FlagTree なし）。
  • 付随する知見：4.4.3 以降 serve は /dev/cambricon_devN を直接マウントする必要があり、MLU_VISIBLE_DEVICES=N env 形態ではデバイスが見えず早期終了する；コールド初回実行の意味論アンカーは libentry オンライン bench 汚染の唯一の信頼できる判定基準であり、ウォームリクエストでは露呈できない；根本原因側（libentry は生きたテンソル上で計時 bench を行うべきでない）は上流 flag_gems の修復待ちで、ブラックリストは暫定策。

解読：これは build-infra が「検証」を緑ラベル/マトリクス記録からコールド状態の意味論検証へ格上げした画期的な記録である——08-26 の意味論ゲートなしの偽陽性を公に認め、再現可能な判定チェーン（c1-c7 の逐字再現）を示し、修復の境界を明確に引いた（ブラックリストは暫定、上流意味論は変更せず、根本原因は flag_gems に委ねる）。この種の「ネガティブ記録＋再検証プロセス」こそマルチチップデリバリの信頼性の基盤であり、09-04 の天数智芯 T パス非デリバリ可能記録（#722）と同様、2.2 サイクルのエンジニアリング監査の主線に属する。

1.4 build-infra：sglang 0.5.18 コールドスタート治理——タイムアウトノブ/レディネスゲーティング/watchdog の落地、摩尔線程 0.5.18 デリバリ記録が完了（09-05/09-06）

情報源：#737（6dd6e454d4）、#738（c89a8e5e32）、#739（db50808507）、#740（11f18b8401）、#741（a0df0db9b6）、#747（5ce0796cc2）、#749（1569ce4057）、#751（e46627a1fa）、#754（b353ca3181）、#755（f9de45819c）

  • コールドスタート（cold-start）検証のエンジニアリング化（09-05 12:28~18:15、#737-741）：背景には、sglang 0.5.18 アプリケーション環境が 09-04 に寒武紀/燧原へ展開された後、コールド初回実行（空キャッシュ）の起動/レディ状態のタイミングが不安定になり、検証スクリプトが「まだ warmup 中」と「すでにハングしている」を区別できなくなったことがある。調査期間内に順次展開：#737 検証スクリプトにコールドスタートタイムアウトの調整つまみを追加 → #738 寒武紀 app verify の実際の引数受け渡し → #739 レディゲートは warmup 後の最初の行の出力のみを認識 → #740 cold-start watchdog を寒武紀 sglang app イメージに直接焼き込み（コンテナ内で自己修復し、外部スクリプトに依存しない）→ #741 寒武紀/燧原のコールドスタートの実態を記録。
  • 摩尔線程（mthreads）sglang 0.5.18 デリバリの収尾：#747（22:32）musa5.2.0 の sglang deps_app で compressed-tensors のバージョンを固定；#749（23:30）mthreads-musa5.2.0 の sglang app イメージタグ 2.1.2-0.1.dev1_g607b9672c を登録；#751（23:49）mthreads 0.5.18 デリバリを記録（摩尔線程は寒武紀/燧原/沐曦/昇騰に続き、sglang 0.5.18 デリバリ記録が完備されたさらに一社となる）；#755（09-06 10:05）musa4.3.6 の旧ラインについても同様に compressed-tensors を固定。
  • #754（09-06 09:54）：寒武紀 neuware4.4.3 向けに sglang app config を追加（0.5.18 ラインが 4.4.3 ツールチェーン上で展開を継続）。

解説：sglang のマルチベンダー矩阵は 09-03 以降の「登録-検証-修正」の流動状態から、本調査期間でさらに前進した——cold-start セマンティクスが検証スクリプトとイメージ自体に組み込まれた（調整つまみ + ゲート + 内蔵 watchdog の三層）。これは 1.3 の「コールド初回実行セマンティクスのアンカー」と同じ方法論のアップグレードに属する：マルチチップ推論デリバリの検証は「起動できる」から「コールド状態での初回リクエストのセマンティクスが正しい」へと移行しつつある。compressed-tensors を mthreads の二つのツールチェーンライン（5.2.0/4.3.6）で同時に固定したことは、典型的な依存関係ガバナンスの細部である。

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

2.1 コンポーネントレベルのニュースは連続四回目の平穏な調査期間、検索による調査期間内ヒットはゼロ（09-05~09-06）

  • gnews 中英語 13 組のクエリ（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/智源研究院/智源オープンソース/BAAI など、when:7d-14d）ゼロでウィンドウ内に直接ヒット；唯一繰り返し出現するのは 09-01 智源コミュニティの Day0 記事（千問/GLM/混元が四日間に三度 Day0）の各チャネルでの転載——新規内容ではなく、既に報道済み。「智源研究院 when:7d」のギャンブル SEO テンプレート汚染が持続（体壇/格隆匯などのアグリゲートソース、タイトルは「葡超スコア結果/米楽m6オンライン公式サイト/愛贏プレイヤー首選サイト」などの置換語テンプレート、710B/GPT-4o 逼近などの記述は 2024 年の旧文の残片であり、すでに一括排除済み）。
  • Tavily 検索：ウィンドウ内に FlagOS 関連の報道なし；FlagOS CSDN 公式コミュニティアカウント（flagos.csdn.net）の最新内容は 09-01 の GLM-5.3-Flash Day0 九チップ適応記事と 09-03 のライブ配信リプレイで、いずれもウィンドウ前且つ智源コミュニティと同源。
  • HN Algolia：FlagOS/FlagGems/FlagSparse/FlagTree のクエリでゼロ関連ヒット（feature-flag 系のノイズが主）、前日までと一致。

2.2 エコシステム参考：智源コミュニティが SGLang 円卓対談を転載——「検証可能が次のボトルネック」（09-05）

情報源：智源コミュニティ（原載 極客公園/Founder Park）

  • 09-05 智源コミュニティが極客公園整理の AGI Playground 2026 円卓実録を転載：Axiom Math（共同創業者兼 CTO Shubho Sangupta）、Radixark（核心技術メンバー鮑科、オープンソースフレームワーク SGLang を核とする推論インフラ企業）、SoTALab（共同創業者 于林希） が「検証可能 AI」を対談——長タスクエージェント（タスクチェーンが 50 歩を超えると成功率が断崖的に下落）には段階的検証と細粒度報酬（Lean 定理証明器式フィードバック）が必要で、推論インフラにはプロダクションレベルのアップグレード（初回トークン遅延、トークン間隔 SLO、ストレステスト）が必要、検証可能は AI 発展の次の真のボトルネックかもしれない。

解読：FlagOS とは弱関連（SGLang は sglang-plugin-FL の上流フレームワーク）だが、エコシステム背景として収録——1.3/1.4 の「コールドスタート意味論アンカー検証」と併せて見ると、「検証」が同時に推論フレームワークコミュニティと FlagOS デリバリーエンジニアリングのキーワードになりつつある、方向は一致（検証可能、追跡可能、信頼できるデリバリー）、ただ粒度が異なる（前者は結果層、後者はデプロイ層）。

3. メンバー単位の深掘り

3.1 メンバー単位にウィンドウ内の新規動態なし（09-05~09-06）

  • 昨日（09-04/09-05 レポート）で既報のメンバー単位の主軸——燧原の起行価格決定と収益化タイムテーブル、摩尔線程の「廬山」GPU と H1 業績/趨境 PD 協力、沐曦と天数智芯の帳簿上の黒字転換の分解、寒武紀のソフトウェア人材募集——本ウィンドウではいずれも後続の新規報道なし。ニュース側の検索（メンバー単位キーワードの中英語クエリ含む）はゼロヒット。
  • コンポーネント側のメンバー単位動態（本レポート 1 章で詳述済み）：寒武紀（0.20.2/0.24.0/sglang 0.5.18 検証と文字化け修正デリバリー）、天数智芯（0.20.2 旧ライン有効化 + FlagGems attention 注入）、燧原（tops1.10.6/tops1.9.10 デュアル SDK ラインイメージ登録）、摩尔線程（sglang 0.5.18 デリバリー + compressed-tensors ロック）、沐曦（FlagSparse MetaX バックエンド登録、1.1 参照）いずれもコミット級の動態あり——メンバー単位の「真の動態」は build-infra デリバリーマトリクスとオペレータライブラリバックエンドに集中、ニュース面の平穏と対照をなす。

3.2 FlagSparse 共同構築チームの背景：中国科学院計算所系 AlphaSparse のデュアルチャネルで継続合入（09-05）

  • ウィンドウ内の FlagSparse 全 4 件のコミットは外部スパース計算チームによる：コミットアカウント NCIA-AlphaSparse、メールドメイン ict.ac.cn（中国科学院計算所）、その org NCIC-AlphaSparse が上流ミラーとして（PR #51 は NCIC-AlphaSparse/main から合入）、チームは同時に flagos-ai/FlagSparse への直接プッシュ権限を有する——「上流ミラー合入 + リポジトリ直接プッシュ」のデュアルチャネル共同構築。
  • タイムライン：8/20 「cuda and dcu merge」→ 8/22 dcu tests（PR #45）→ 8/24 dcu bsr spmv/spmm → 8/27 spsv/spmm 構造統合 → 9/1 v0.3.0-rc0.post1 → 9/4-9/5 metax/musa/ascend バックエンド——DCU 以降のあらゆるバックエンド能力が同チームによる、FlagOS の「メンバー単位 + 科研機関の衆智共同構築」のスパース計算方向における代表事例（従来のデイリーレポートでその DCU 貢献は記録済み、本ウィンドウでチーム背景を補完：メールドメイン ict.ac.cn が中国科学院計算所を指す）。

4. まとめ

本ウィンドウ（09-05 10:18 ~ 09-06 10:18）はニュース側が4 期連続の平穏なウィンドウ（gnews/Tavily/HN はウィンドウ内ヒットゼロ、SEO テンプレート汚染と旧記事の転載のみ）であったが、GitHub 側は 2.2 周期のエンジニアリング推進を継続し、三つの主要ラインがある：

  1. FlagSparse バックエンドマトリクスが 5 社に拡大（PR #51、09-05）：デバイス抽象化の移行 269 箇所、MetaX（沐曦 MACA/C550）は「CUDA 移植 + シミュレーション検証」で実装し spsv v0.1 を走通し、摩尔線程/昇騰は provisional バックエンドとして登記——疎オペレータライブラリのマルチチップ化と外部キュー（中国科学院計算所系 AlphaSparse）が引き続きコンポーネントバージョンのリズムをリード（2.2 最初の RC tag 保持者）。

  2. build-infra のデリバリエンジニアリングが「コールドセマンティクス検証」にアップグレード：寒武紀 0.20.2 のコールド初回実行文字化けが根本原因を特定（flag_gems copy_ の汚染、ブラックリスト [index, copy_] で暫定対応、アップストリーム修正は TODO）、08-26 のセマンティクスゲートなしの偽陽性を公に覆した；sglang 0.5.18 ラインではタイムアウトノブ/レディネスゲート/組み込み watchdog の三層コールドスタート治理を実装。

  3. 天数智芯のデリバリパスは F パス優先に確定：0.20.2 旧ライン + VLLM_FL_USE_FLAGGEMS_ATTN=1 + symm-mem guard、T パス（ベンダー Triton）の修正はプラグイン側に留保。

予測は昨日と一致：2.2 rc0 周期は「検証-tag 付け-記録」の中段にあり、次のリリースシグナルは依然として community リストリポジトリの動きと build-infra の version bump にかかっている；コンポーネントニュース面の次の可能なノードは 2.2 正式 rc の切り替えまたは次の Day0 モデル対応である。

付録：完全な情報源リスト

情報源 確認結果
GitHub org repos API（flagos-ai、52 リポジトリ） 7 リポジトリがウィンドウ内でプッシュ；docs/release-info/sglang-plugin-FL/vllm-plugin-FL/FlagTree はデフォルトブランチの commits 検証により PR ブランチのアクションと確認
GitHub commit search（org 全量、21 件） build-infra 17、FlagSparse 4；committer 時間と内容を逐条検証済み
GitHub tags API + 日付検証 ウィンドウ内に新規 tag なし（FlagSparse v0.3.0-rc0.post1 は 09-01 前、FlagTree v0.4.0 シリーズは 2026-01、build-infra v2.1.1 は 08-03 等）
GitHub releases API ウィンドウ内に新規 release なし（FlagSparse v0.3.0-rc0.post1 は 09-01 02:02 CST にリリース、ウィンドウ前）
FlagSparse PR #51 / commits / METAX_TESTING.md バックエンドマトリクス、デバイス抽象化移行、MetaX 実装状態と検出機構（patch 全文を検証済み）
build-infra commits #737-755 17 件を逐条検証（vllm/sglang 双ラインのデリバリ記録と修正）
vllm-plugin-FL PR #411 cambricon ブラックリスト [index, copy_] を登録（クロスリポジトリ参照で検証）
Google News RSS（中英 13 組、プロキシ経由） ウィンドウ内ヒットゼロ；ギャンブル SEO テンプレート汚染はバッチ全体を除外；09-01 Day0 旧記事の転載は新規内容ではない
HN Algolia（4 組クエリ） 関連ヒットゼロ
Tavily web 検索（4 組） ウィンドウ内の FlagOS 報道なし；flagos.csdn.net の最新は 09-01/09-03 の内容
智源コミュニティ hub.baai.ac.cn 09-05 に極客公園 SGLang 円卓を転載（エコシステム参考、弱関連）