調査期間：過去 24 時間（2026-09-17 10:18 ~ 2026-09-18 10:18、北京時間） 情報源：GitHub（org: flagos-ai、54 個のリポジトリ pushed_at 全量核查 + 単一 commit search 147 件を committer-date で検証し全量取得 + 重点リポジトリのデフォルトブランチコミット再確認 + tags/releases メタデータ + community の FEP ディレクトリと 2.2 リリース一覧/タイムテーブル raw 直接取得 + build-infra の重要 PR パッチとファイル一覧 + git ls-remote 全量 ref 検証による rc2 ブランチ）、Google News RSS（中国語・英語 33 組の検索語、プロキシ経由）、HN Algolia、智源コミュニティ、集微網、電子工程専輯など（詳細は付録の情報源一覧を参照）

本期インデックス

  • 今日の重点：community が 20 件の FEP を一度にマージ、FlagOS 2.2 の特性一覧とリリース境界が同時に確定（09-17）
      1. オープンソースプロジェクトの進展（GitHub 動向）
    • 1.1 community：20 件の FEP を一括マージ、2.2 特性一覧が確定（09-17）
    • 1.2 RC2 一覧と統合ブランチ：24 のモジュール項目、十倉が同期して rc2 ブランチを切り出し（09-17）
    • 1.3 build-infra が連続 2 回バージョン引き上げ：FlagGems が rc2.post3、摩尔線程 FlagTree が 0.7.0rc2（09-18）
    • 1.4 build-infra：昇騰 FlagTree wheel アップロード経路が初めて開通（09-17）
    • 1.5 FlagGems：KernelGen が単日でさらに十数個の Nvidia オペレータを登録、AMD W7900D が週次テスト入り（09-17/09-18）
    • 1.6 FlagTree：DEB パッケージングと Nexus リリースが build-infra 共有ワークフローに統合（09-17/09-18）
    • 1.7 Torch-FL：環境変数の面を FLAGOS の一組の接頭辞に収束（09-17/09-18）
    • 1.8 FlagQuantum：カバレッジ下限を二段階引き上げ、量子誤り訂正レコード層が着地（09-17/09-18）
    • 1.9 FlagFFT：MUSA と MACA のポータブル三次元転置検証記録、依存を統一的にピン留め（09-17）
    • 1.10 FlagCX：lane mask ABI を 64 ビットに拡張、Fedora 43 が RPM マトリクス入り（09-18）
    • 1.11 FlagAudio：オーディオオペレータライブラリ最初の 3 件の PR をマージ（09-17）
    • 1.12 その他の動向：FlagDNN、FlagGems-vllm、FlagGems-sglang、flir、FlagScale（09-17/09-18）
    1. ニュース報道とエコシステム
      • 2.1 コンポーネント級検索は 14 回連続の平穏な調査期間：24 時間以内にゼロヒット（09-17~09-18）
      • 2.2 紫東太初 ZDTaichu5.0-9B のオープンソース化は智源コミュニティ経由：FlagOS スタックとインターフェースがなく、本期は収録せず（09-16~09-17）
      • 2.3 メンバー機関の資本面：沐曦の株価異動と機関の減持、燧原 IPO 稿（09-17）
    1. メンバー機関の深掘り
      • 3.1 海光：融合 rrelu バックエンドカーネルを登録、DCU wheel を分離して Qwen-Image を修正（09-17/09-18）
      • 3.2 摩尔線程：MUSA ライン FlagTree が飛び級で 0.7.0rc2 へ、vLLM 0.20.2 イメージに初めてプラグインを導入（09-18）
      • 3.3 崑崙芯：0.6.1+xpu3.6 のピン留めと tle.raw ファストパスのロールバック（09-17）
      • 3.4 沐曦：MACA ポータブル三次元転置検証と依存の統一ピン留め（09-17）
      • 3.5 天数智芯：FlagDNN のプラットフォームアーキテクチャ再編（09-17）
      • 3.6 昇騰：CommonIR 概念検証を実装済みとマーク、grouped_topk が tle.dsa.raw チューニングへ（09-17）
      • 3.7 達磨院玄鉄：T-Head が FlagTree 2.2 のマルチバックエンド計画入り、PPU ラインの CI を展開（09-17 核查）
      • 3.8 清微智能：分散プリミティブをバックエンドで有効化、2.2 の TLE 分散路線と合流（09-17）
      • 3.9 智源（牵头機関）：FEP ガバナンスの着地と RC2 一覧の維持（09-17）
    1. まとめとトレンド観察
  • 付録：情報源核查表
  • 付録：完全な情報源一覧

今日の重点：community が 20 件の FEP を一度にマージ、FlagOS 2.2 の特性一覧とリリース境界が同時に確定

日付：2026-09-17　出典：community FEP ディレクトリ、FEP-0099 オペレータライブラリ、FlagOS 2.2 リリーススケジュール

09-17 23:55 から 23:56 の 1 分間に、community リポジトリへ 20 件のコミットが連続して着地した。すべて FEP(sig-...) をプレフィックスとし、番号は 0085 から 0100 まで並び、オペレータ、コンパイラ、フレームワーク、トレーニング、ネットワーク、端側、科学知能の 7 方向に属する。この一連の文書は「2.2 で何をデリバリするか」を会議の合意事項から、リポジトリ内で一件ずつ照合可能なファイルへと変えた。

内容面で最も記録に値するのは、各 FEP が「Release Boundary and Evidence」節を備えていることだ。すなわち当該方向の 2.1 におけるベースライン版、2.2 候補（RC2 リスト）における版、および開発ウィンドウを記し、末尾でどの部分にコードが対応し、どれが依然としてロードマップにすぎないかを明示している。オペレータライブラリを例にとると、FEP-0099 は 2.2 の演算目標を 4 項目にまとめている。オペレータ総量を 635 個まで押し上げ（うち 301 個は KernelGen ワークフローが産出）、注意系オペレータを英偉達の先進水準に揃えて 5 社以上の国産チップ上で動作させ、Triton 言語拡張（TLE）に基づくキーオペレータ、そして低位幅や融合大カーネルなどの汎用最適化手法である。2.1 ベースラインとして FlagGems v5.3.0 など 6 項目を、2.2 候補として FlagGems v5.4.0-rc2.post1 などを列挙し、開発ウィンドウを 06-01 から 08-31 と明確にしている。

同一バッチの文書では状態の差異も明確に記されている。コンパイラ側で汎用中間表現（Common IR）を導入する FEP-0095 は実装済みとマークされているが、本文はその範囲を「昇騰 910B/910C の Triton 3.5 ライン上での概念実証」に限定し、FlagTree #974（08-13 開始、08-27 マージ）へリンクし、これがハードウェアファミリを跨ぐプロダクション級の統一パスに等しくないと宣言している。一方 KernelGen 能力の FEP-0100 は自発的にドラフト止まりとし、本文に「公開 release タグに対応する実装または実装 PR が見つからない」と直接明記し、ロードマップをデリバリとして扱っていない。このように「同一バッチの文書に実装済みも明確な未実装も併存する」書き方は、本バッチ FEP の最も実用的な点である。

タイムライン上、本バッチの文書はテスト・安定化期間の中段に位置する。リリーススケジュールはフィーチャーフリーズを 08-31、テスト期間を 09-01 から 09-24、GA を 2026-09-28 と定め、フリーズ規則には「FEP とフィーチャーコードの二つの扉が同時に閉じ、逃せば次バージョンへ順延」と明記している。したがって本バッチの文書の機能は、凍結済みの範囲の登録を補完することであり、2.2 に新たなものを加えることではない——GA まで残り 10 日である。

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

ウィンドウ概観：org 内 54 リポジトリのうち 28 個がウィンドウ内にプッシュあり（前一期は 19 個、明らかに増量）；単一 commit search でウィンドウ内コミット 147 件がヒット（2 ページで全量取得、committer-date 降順）、14 リポジトリに分布：FlagGems 40、FlagFFT 21、community 19、FlagQuantum 17、Torch-FL 15、build-infra 7、FlagTree 7、FlagGems-sglang 7、FlagDNN 3、FlagCX 3、FlagAudio 3、FlagGems-vllm 3、FlagScale 1、flir 1。ほかに 14 リポジトリがウィンドウ内にプッシュありながらデフォルトブランチに新規コミットなし（FlagBLAS、FlagTensor、KernelGen、KernelGenBench、Megatron-LM-FL、TransformerEngine-FL、FlagRelease、sglang-plugin-FL、FlagOS-Compressor、FlagAttention、FlagSparse など）。09-17 23:29 から 23:33 の同一分区间に集中し、git ls-remote で検証したところ rc2 統合ブランチの作成プッシュである——詳細は 1.2 を参照。

本ウィンドウの形態 ＝「リリース登録」＋「パッケージングとリリース物」の 2 本線：ガバナンス側は一度に全套の FEP 文書を補完し 2.2 リリース境界を固定；エンジニアリング側の注意力は明らかに機能開発からリリース物そのものへ移行している——DEB パッケージング、wheel アップロード経路、Nexus 成果物同期、カバレッジゲート、環境変数の収束、いずれも「インストールできるか、リリースできるか、インストール後に正しいか」というレベルの作業である。

1.1 community：20 件の FEP を一括マージ、2.2 フィーチャーリスト確定（09-17）

日付：2026-09-17　出典：community FEP ディレクトリ、FEP 説明とバージョン追跡

詳細は「本日の重点」を参照。ディレクトリ側の事実を二点補足する。第一に、FEP は SIG ごとにディレクトリを分けて格納され、今回追加された文書は sig-operator（0099）、sig-compiler（0095 から 0098）、sig-framework（0086 から 0091）、sig-training（0092）、sig-kernelgen（0093、0100）、sig-network（0085）、sig-edge（0082 から 0084）、sig-ai4s（0081）に落ちており、一度にすべてのアクティブ SIG を埋め尽くしている。第二に、端側方向の FEP は文書を書くだけでなく、実行可能なスクリプトディレクトリ（fep/sig-edge/scripts/ 配下の Triton 3.7 と arm64 推論の二套）も伴っており、本レポートで観察された端側路線と一致している。

1.2 RC2 マニフェストと統合ブランチ：24 のモジュール項目、十倉が同期して rc2 ブランチを切り出し（09-17）

日付：2026-09-17　出典：release-2.2-rc2.yaml、release-branch-tag ワークフロー

09-17 23:29 から 23:33 にかけて、十のモジュールリポジトリが同一分の区間にプッシュされたがデフォルトブランチに新しいコミットはなかった。git ls-remote で全 ref を取得して検証したところ、これらのリポジトリにはすでに 0.3.0-rc2 / 0.2.0-rc2 / 0.1.0-rc2 / 2.2.0-rc2 形式の統合ブランチが存在し、対応する v*-rc2.post1 タグも打たれていることを確認した。FlagGems と FlagCX はさらに先を行き、タグはすでに rc2.post3 と rc2.post2 の段階に達している。community 内の release-branch-tag.yml がこの動作チェーンの実行者であり、release マニフェストに従って manage-release.py を呼び出し、release bot の身分でブランチとタグを一括作成・プッシュする。

マニフェスト自体もアップグレードされた。RC2 版は 24 のモジュール項目を列挙し、RC1 と項目ごとに照合するとバージョンラインが全体として一格前進していることがわかる（例えば FlagGems は rc1.post2 から rc2.post2 へ、FlagAttention は 0.4.0-rc1.post1 から 0.4.0-rc2.post1 へ）。また冒頭には「同一リポジトリを複数項目に分割し、それぞれ異なる上流ラインに追随させる」書き方の説明が補足された。記録に値する細部が二点ある。FlagTree は Triton バージョンごとに項目を分割しているため、tag 形式は全体の v プレフィックス規則を適用しない。FlagScale の 2.2 マニフェストにおけるバージョン番号は v2.1.0-rc2.post1 であり、すでに 2.0 ラインから飛び出している。

1.3 build-infra が連続二回バージョン引き上げ：FlagGems は rc2.post3 へ、摩尔線程 FlagTree は 0.7.0rc2 へ（09-18）

日付：2026-09-18　出典：build-infra #925、build-infra #926、configs.yaml

前日に base バージョンを 2.2.0 に引き上げた動作に続き、build-infra は 09-18 07:32 と 08:35 にさらに二件のバージョン引き上げコミットを落とし、いずれも configs.yaml のみを変更している。第一件（#925）は flaggems フィールドを 5.4.0-rc2.post2 から 5.4.0-rc2.post3 に変更し、第二件（#926）は摩尔線程バックエンドの flagtree ピン留めバージョンを 0.6.1+mthreads3.6 から 0.7.0rc2+mthreads3.6 に変更した。同一ファイルの冒頭にはリリース動作が三ステップ——フィールド更新、v<バージョン> タグ打ち、終了——として記述されているため、この二行の変更は 2.2 イメージライン上のオペレータライブラリと摩尔線程コンパイル基盤が同時に一巡新しい候補へ切り替わったことを意味する。

この二件を並べて見ると、オペレータライブラリとコンパイラ基盤はいずれも rc2 のイテレーション位置（post3 / 0.7.0rc2）へ向かって進んでおり、一方マニフェスト内のデフォルトの version フィールドは依然として 2.2.0 に留まっている——リリース物はまだ組み立て中であり、正式なタグ打ちはなされていない。

1.4 build-infra：昇騰 FlagTree wheel アップロード経路が初めて開通（09-17）

日付：2026-09-17　出典：build-infra #923、build-infra #924

#923 は昇騰 FlagTree のパッケージングを修正した。それ以前は二つの昇騰ターゲットのいずれも wheel を生成できず（昇騰 3.5 は FlagPrism の Metric.h で uint64_t が宣言されていないため失敗）、原因はパッケージングスクリプトが初回にマージされた後、すべての修正が別のブランチにコミットされ、マージは別のブランチを通っていたことであった。本 PR では併せて両ターゲットのファイルを CANN バージョンに従ってリネームし、cann8.5.0 ターゲットを新規追加した。#924 はその後、「アップロード経路は未検証」という懸案を実測による答えに置き換えた：09-17 に二つの wheel はどちらも flagos-pypi-ascend 成果物リポジトリに到達しており、それぞれ flagtree-0.7.0rc2+ascend3.5 と flagtree-0.6.0+ascend3.2 である。ドキュメントには同時に昇騰ノードのビルド所要時間（26 分と 14 分、その大部分は MAX_JOBS=32 下での AscendNPU-IR と triton のコンパイルに費やされる）と、一つの環境制約が記録されている：CANN ノード上の pip バージョンが --break-system-packages に必要なバージョンより古い。

1.5 FlagGems：KernelGen が単日でさらに十数個の Nvidia オペレータを登録、AMD W7900D が週次テストに参加（09-17/09-18）

日付：2026-09-17、2026-09-18　出典：FlagGems #5846 分位オペレータ、FlagGems #6312 AMD 週次テスト、FlagGems #5731

FlagGems の今期 40 件のコミットは org 内で最も密度の高いラインであり、その大半は KernelGen ワークフローから産出された Nvidia オペレータの登録で、単日で十数個が新規追加された：分位と平均値系（nanquantile、nanmean）、行列式対数（logdet）、極分解（linalg_polar）、リカレントネットワーク逆方向カーネル（GRU / LSTM セルおよびその逆方向）、アップサンプリング逆方向（Lanczos アンチエイリアス）、疎行列積、特徴量 Dropout、パック線形層など、さらに二つの要素ごと組み合わせオペレータ（and_tensor、and_scalar）と set_ の全テンソルオーバーロードがある。

バックエンドとツール側の三件：[CI] Add AMD W7900D backend to weekly test workflow は AMD の W7900D を週次テストマトリクスに追加し、比較的新しく登場した非国産バックエンドのラインである。SiliconFlow バックエンドはゼロコピー real オペレータを新規追加し、スケジューリングキーによる登録に変更した。続くコミットは七つのバックエンドサブパッケージの __init__.py を補完し、「新規追加されたバックエンドパッケージがインポートチェーンに拾われない」という構造的欠陥を修正した。他にいくつかのゲート修正（オペレータエクスポートチェック、KernelGen テストマーカーは PR 新規追加行のみをスキャン）がある。

1.6 FlagTree：DEB パッケージングと Nexus リリースが build-infra 共有ワークフローに統合（09-17/09-18）

日付：2026-09-17、2026-09-18　出典：FlagTree #1063、FlagTree #1066、FlagTree #1082、FlagTree #1170

FlagTree の今期 7 件のコミットのうち 3 件はリリース成果物のエンジニアリングである：リリースパッケージを build-infra の共有ワークフローを使って FlagOS Nexus 成果物リポジトリへプッシュする（#1063）、DEB パッケージングマトリクスに ubuntu22.04 / python3.12 の行を追加して ABI の組み合わせをカバーする（#1066）、そして DEB パッケージ内で libtriton と libproton のデバッグ情報を削除し dh_dwz をスキップする（#1076）。翌日の Bump packaging baseline to 0.6.1 and plumb the wheel version はパッケージングベースラインと wheel バージョン番号を連通させ（#1082）、成果物のバージョンが手動保守されなくなった。

コンパイラ側の1件は2.2のTLEルートに直接関連する：tle.signal / tle.signal_waitフロントエンドが同期範囲とメモリオーダーを明示的パラメータとして露出する（#1170）。これはFEP-0096の「分散プリミティブと通信計算の融合」に必要な意味論インターフェースに対応する。

1.7 Torch-FL：環境変数面をFLAGOS単一プレフィックスに収束（09-17/09-18）

日付：2026-09-17、2026-09-18　情報源：Torch-FL #341、Torch-FL #337、Torch-FL #320

Torch-FLの本期15件のコミットは一連の連続したリファクタリングである：取り込み式ビルドスイッチのみを残し、ボクシングとネイティブモード変数を除去し（#336）、SDK検出ロジックを統一してPPU専用のアクセラレータ識別子を付与し（#337）、ベンダーネイティブSDK環境変数のみを受け入れ（#338）、ランタイムとルーティングの環境変数テーブルをコードと一致するよう変更し（#339）、最終的にFLAGOS_プレフィックスの単一変数面に統一した（#341）。同期間のCIコミット1件で旧FlagGemsスイッチを完全に退場させた（#320）。このラインは前回の「ルーティング切替後の後遺症修復」とは異なり、インターフェース面の収束である——複数の歴史的スイッチを単一の契約に統合することであり、リリース前に外部可視面を確定させることに属する。

プラットフォーム側には別途2件の実質的修正がある：分離されたDCU wheel上でtorch.cudaを利用可能にし（#332）、および若干の昇騰意味論パッチ（ブールSDPAマスク、ブールマスクインデックス、最近傍アップサンプリングをデバイス側に留める）。

1.8 FlagQuantum：カバレッジ下限を二段階で引き上げ、量子誤り訂正記録層が着地（09-17/09-18）

日付：2026-09-17、2026-09-18　情報源：FlagQuantum #64、FlagQuantum #55、FlagQuantum #52

FlagQuantumの本期17件のコミットはほぼすべてがエンジニアリング品質基準の確立に充てられている：グローバルカバレッジ下限を60%から75%に引き上げ、各パッケージに個別下限を設定し（#55）、パッケージ全体を厳格な型チェックに組み込み（#52）、lintゲートをモダンな型注釈と欠陥カテゴリ規則にまで拡張し、各テストファイルをいずれかのティアマーカーに分類し、これまでスキップされていたJAXテストをCIに接続してカバレッジ向上に紐付けた。機能側の1件は量子誤り訂正（QEC）記録層の第一段階であり（#64）、実装を具体的な符号化方式から分離している。リファクタリング側では9箇所の双子ライターを単一実装に統合し、11箇所のネスト関数がループ変数を遅延バインドする欠陥を修正した。

FEP-0081がFlagQuantumを科学知能方向に位置づけているのに対し、本期の重心は「まずエンジニアリングベースラインを確立させる」ことであり、アルゴリズム規模の拡張にはまだ入っていない。

1.9 FlagFFT：MUSAとMACAのポータブル三次元転置検証記録、依存を統一提版（09-17）

日付：2026-09-17　情報源：FlagFFT コミット記録、FlagFFT リポジトリ

FlagFFTの本期21件のコミットはハードウェア適応ブランチのマージと検証記録が中心である：ハードウェアプロファイルブランチをそれぞれMUSA（摩尔線程）、MACA（沐曦）およびCUDAの3本のフィーチャーブランチとマージし、3本それぞれに検証記録ドキュメントを残した。うちMACA側は2件連続のコミットでポータブルレジスタブロッキング三次元転置を有効化している（まずプラットフォーム検証、その後正式有効化）。性能側の1件は大規模複素リーフノードを単一の共有バッファ経由で一時保存するよう変更し、ついでにネイティブ精度収集のメモリ上限とファイルキャッシュ解放の2箇所の問題を修正した。締めくくりの1件はTriton JITランタイム依存を統合バックエンドリビジョンに固定し、FlagTree側のバージョン収束と同じ方向性である。

1.10 FlagCX：lane mask ABIを64ビットに拡張、Fedora 43がRPMマトリクスに参入（09-18）

日付：2026-09-18　情報源：FlagCX #607、FlagCX #561、FlagCX #562

通信ライブラリ側の3件のコミットはいずれも09-18午前に集中的にマージされた：lane maskのバイナリインターフェースを32ビットから64ビットに拡張し（#607、チップ規模の拡大に伴い必須となるABI拡張）、独立したNexusアップロードフローをbuild-infraの共有ワークフローに置き換え（#561、FlagTreeと歩調を合わせる）、そしてFedora 43をNVIDIA RPMビルドマトリクスに追加した（#562）。3件を合わせて見ると、通信ライブラリの今期は「インターフェース容量 + 成果物生産ライン」の2点に取り組んでおり、新しい通信アルゴリズムではない。

1.11 FlagAudio：音声オペレータライブラリ初の3件のPRがマージ（09-17）

日付：2026-09-17　情報源：FlagAudio #5 スペクトログラムオペレータ、FlagAudio #4、FlagAudio #2 パッケージング

FlagAudioは同じ午前に3件のPRをマージした。このリポジトリでは珍しい機能的な動きである：1件はTritonでスペクトログラムオペレータを実装しテストを添付、1件はゲイン恒等チェックを修正しtorchaudioのインポートを遅延ロードに変更、1件はパッケージングを仕上げた（依存関係とライセンス表明）。3件はいずれも外部コントリビューターのブランチからのもので、このリポジトリにリポジトリ外の開発者が参入し始めたことを示している。FEPリストでFlagAudioが既にオペレータ層の24モジュール項目に列挙されていることと合わせると、プレースホルダー状態から実際の成果物を伴うモジュールへと移行しつつある。

1.12 その他の動向：FlagDNN、FlagGems-vllm、FlagGems-sglang、flir、FlagScale（09-17/09-18）

日付：2026-09-17、2026-09-18　情報源：FlagDNN、FlagGems-vllm #776、FlagGems-sglang #84、flir #73

FlagDNNの3件のコミットはそれぞれ天数智芯と海光の2プラットフォームの実装アーキテクチャを再編成し、新たにテキスト総和オペレータ（psum_text）を追加した。これは同リポジトリのプラットフォーム別に実装を敷き詰める手法の延長である。FlagGems-vllmの3件はいずれも国産チップ上の推論オペレータである：昇騰上でグループ化Top-KをTLEのDSA生インターフェースで性能最適化し、分塊ゲート付きDelta則フォワードオペレータを新規追加し、さらにFP8可変長アテンション。FlagGems-sglangは3件のPRをマージし、マルチモーダル回転位置エンコーディングの融合オペレータを導入してパッケージ名前空間によるオペレータ参照に変更し、併せてバッチ2ブランチのプリコミットチェックを修正した。flirは1件でメモリ効果マーカーを修正し、汎用中間表現路線の延長である。FlagScaleは1件でforkリポジトリPRの依存成果物をアップロードするよう変更しキャッシュ分離を回避した——CI可用性の修正である。

2. 報道とエコシステム

2.1 コンポーネント単位検索は14回連続の平穏な調査期間：24時間以内にゼロヒット（09-17~09-18）

日付：2026-09-17 ~ 2026-09-18　情報源：Google News RSS（中国語・英語の33組のクエリ語、プロキシ経由）

今期はFlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGenならびに「智源研究院 開源」「智源研究院 チップ」「国産算力 オープンソースソフトウェアスタック」「BAAI open source AI system stack」などのキーワードで中国語・英語を半分ずつ組み合わせた33組の検索を行ったが、24時間の調査期間内でコンポーネント名はゼロヒットであり、コンポーネント名に直接関連する直近の報道は依然として09-15のOpen3D-PIMCオープンソースに関する英語記事である。これで14回連続の平穏な調査期間となる。ヒットした15件のうち約13件は株式市況と機関レーティング記事（沐曦股份の株価異動、機関の売り、燧原IPO関連）であり、タイトルの意味に基づき一括で除外し、本文には計上していない。

2.2 紫東太初 ZDTaichu5.0-9Bのオープンソースは智源コミュニティ経由で中継：FlagOSスタックとのインターフェースがなく、今期は収録せず（09-16~09-17）

日付：2026-09-16、2026-09-17　情報源：智源コミュニティ転載、量子位報道

智源コミュニティは09-17、紫東太初のオープンソース汎用マルチモーダルモデル ZDTaichu5.0-9B に関する報道を転載した。モデル本体は09-15にリリースされ、重みとデータ生産方案も同時に公開された。この項目は検索で「智源研究院 オープンソース」クエリ語にヒットしたが、照合の結果：モデルは紫東太初チームが発表し、言語バックボーンは通義千問 3.5 系列であり、FlagOS のコンパイラ、オペレータライブラリ、プラグインの各層といずれもインターフェースを持たず、智源コミュニティプラットフォーム上の第三者コンテンツであって FlagOS の動向ではないことが確認された。「BAAI モデルに泛く言及するだけのニュースを除外する」基準により収録しない。ここでは当該検証のみを記録し、後続の重複判断を避ける。

2.3 メンバー単位の資本面：沐曦の株価異動と機関減持、燧原 IPO 稿（09-17）

日付：2026-09-17　情報源：財聯社、集微網

メンバー単位の資本側の消息は09-17に集中した：沐曦の株価は当日14.44%急騰し、計算力チップセクターを牽引した。同時に複数の稿が5機関合計で23億元超を売却したと報道し、別の報道ではその万卡クラスタが既に生産投入されたと伝えた。燧原科技については、その IPO 背後にある「市場化 GP プラス地方国企 LP」構造を論じる業界稿が現れた。これらは資本市場の動向に属し、FlagOS のコード面とは直接関連せず、メンバー単位の背景記録としてのみ扱い、技術項目には計上しない。

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

3.1 海光：融合 rrelu バックエンドカーネルをマージ、DCU wheel を分離して Qwen-Image を修正（09-17/09-18）

日付：2026-09-18　情報源：FlagGems #6379、Torch-FL #332、FlagDNN

海光の本期の実質的な動きは2件。オペレータ側では、FlagGems がノイズ付きランダム ReLU の融合バックエンドカーネルを追加し（#6379）、KernelGen コンパイル経路を通り、当該活性化関数のバックエンド実装を補完した。フレームワーク側では、Torch-FL が分離 DCU wheel 上で torch.cuda が利用不可となる問題を修正した（#332）。シナリオは Qwen-Image 画像生成モデルの実行である——分離 wheel とはベンダー完全ランタイムをバンドルしないビルド方式を指し、以前は cuda 名前空間を経由する必要があるモデルで直接失敗していた。FlagDNN は同時に海光プラットフォーム実装を再編成した（1.12 参照）。

3.2 摩尔線程：MUSA 線の FlagTree を 0.7.0rc2 へ跳級、vLLM 0.20.2 イメージに初めてプラグインを搭載（09-18）

日付：2026-09-18　情報源：build-infra #926、build-infra #922

摩尔線程は本期で改動面が最も完全なメンバー単位である。コンパイル基盤では、build-infra が MUSA バックエンドの FlagTree ピン版を 0.6.1+mthreads3.6 から 0.7.0rc2+mthreads3.6 へ引き上げ（#926）、直接 2.2 の候補線へ跨いだ。推論プラグインでは、#922 が2つの 0.20.2 版アプリケーションイメージをプラグインリポジトリの v0.2.2-rc2.post1 タグ上で再ビルドしたことを記録する：以前の 2.1.2 タグイメージにはプラグインが全くインストールされておらず、したがってこれは摩尔線程のリリース線上初の vLLM プラグイン付き 0.20.2 イメージであり、イメージに伴い MUSA 関連のアテンションバックエンドレジストリとデバイスインターフェース対応が付属する。FlagFFT 側には同期間、MUSA の3次元転置プラットフォーム検証記録が存在する（1.9）。

3.3 昆仑芯：0.6.1+xpu3.6 ピン版と tle.raw 高速パスフォールバック（09-17）

日付：2026-09-17　情報源：FlagGems #6393、FlagGems #6409、FlagGems #6328

昆侖芯は今回、修正が中心である。まず FlagGems 依存内の FlagTree を 0.6.1+xpu3.6 にアップグレードし（#6393）、その後、以前の tle.raw スカラー比較のファストパスをロールバックした（#6409）。これは能動的な否定であり、当該ファストパスが昆侖芯上で安定した収益をもたらさなかったことを示している。同じバッチには、マスクフィル、双曲線正弦、活性化、インデックスフィルなどのオペレータの修正も含まれる（#6328）。ベースイメージ側では、build-infra が調査期間の前日に昆侖芯の containerfile を修正しており、今回は新たな動きはない。

3.4 沐曦：MACA ポータブル三次元転置の検証と依存統一ピン留め版（09-17）

日付：2026-09-17　情報源：FlagFFT コミット記録、FlagFFT ハードウェアプロファイルブランチ記録

沐曦ラインは今回 FlagFFT に集中している。ハードウェアプロファイルブランチと MACA 特性ブランチのマージ後、2 件の検証記録を残し、ポータブルレジスタブロッキング三次元転置を正式に有効化した。まずプラットフォーム検証を行い、その後有効化するという、このコードにおける一貫した二段階の進め方である。締めくくりとして Triton JIT ランタイム依存を統合バックエンドリビジョンにピン留めし、MACA 側とメインラインの依存ドリフトを回避した。さらに RC2 マニフェスト内の沐曦関連プラグイン項目（vLLM プラグイン 0.2 ライン、0.3 ライン各 1 件）はいずれも rc2 ブランチに切り出されており、1.2 の自動化作業に属する。

3.5 天数智芯：FlagDNN プラットフォームアーキテクチャ再編（09-17）

日付：2026-09-17　情報源：FlagDNN コミット記録

天数智芯の今回の実質的なアクションは 1 件、FlagDNN のプラットフォーム実装アーキテクチャ再編である（1.12 参照）。前回を振り返ると、当該プラットフォームは FlagGems 側で /dev/itrctl デバイスインターフェースサポートを取得し、FlagTree 側で iluvatar3.6 のベースラインワークフローを有していた。今回は引き続きオペレータライブラリ層で構造整理を行い、新規オペレータの追加ではない。これは FEP-0099 のオペレータ層 4 目標のうち「汎用最適化手法」の記述と合致する。

3.6 昇腾：CommonIR 概念実証が実装済みとマーク、grouped_topk は tle.dsa.raw でチューニング（09-17）

日付：2026-09-17　情報源：FEP-0095 Common IR、FlagGems-vllm #776、FlagGems #6354

昇腾は今回、ドキュメントとコードの両側で明確な進展があったラインである。ドキュメント側では、FEP-0095 は今回の 20 件のドキュメントの中で少数の実装済みとマークされたものの一つであり、その範囲は昇腾 910B/910C の Triton 3.5 ラインにおける概念実証に明確に限定されている。FlagTree #974（08-27 マージ）にリンクし、経路は TLE の DSA インターフェースが汎用中間表現を経て linalg に降り、さらに npubin に入るというものである。コード側では、FlagGems-vllm が昇腾上で TLE の DSA 生インターフェースを用いてグループ化 Top-K の性能最適化を行い（#776）、FlagGems 側では Top-K オペレータを新規追加した（#6354）。成果物側では、昇腾 FlagTree wheel のアップロード経路が今回初めて通った（1.4）。

3.7 達摩院玄鉄：T-Head が FlagTree 2.2 マルチバックエンド計画に参入、PPU ライン CI を展開（09-17 確認）

日付：2026-09-17　情報源：FEP-0098 FlagTree マルチバックエンドアーキテクチャ、vllm-plugin-FL #518、Torch-FL #337

本期追加ドキュメントでは、達摩院玄鉄の T-Head バックエンドを FlagTree 2.2 のマルチバックエンドアーキテクチャ計画（FEP-0098）に書き込み、NVIDIA TileIR、燧原、摩尔線程の3本と並列し、目標 Triton ラインを 3.6 とした。エンジニアリング側では PPU ラインの接続が継続的に推進されている。推論プラグインは調査期間前日に PPU の CI サポートを追加し（#518）、Torch-FL は本期のリファクタリングで PPU に個別のアクセラレータ識別子を割り当て（#337）、オペレータテストゲートで PPU を明示的に検出している（#309）。このラインの特徴はインフラがオペレータに先行することだ。CI、識別子、ゲートを先に敷き、オペレータが後から続く。

3.8 清微智能：分散プリミティブをバックエンドで有効化、2.2 の TLE 分散路線と合流（09-17）

日付：2026-09-17　出典：FlagTree #1141、FEP-0096 TLE 大カーネルと分散、flir コミット履歴

清微智能の本期の重要なコミット1件が、リモートアクセスと分散バリアの2つの TLE プリミティブをそのバックエンド上で有効化した（FlagTree #1141）。これを FEP-0096 と対照すると意図が見える。同 FEP は 2.2 で TLE の分散インターフェースを FlagCX の上に降ろし、通信と計算を同一の Triton カーネル内で融合することを計画しており、清微はこの路線で最も早くバックエンド側に着地したベンダーの一つである。上流側では、清微による汎用中間表現リポジトリ flir へのパッチ同期（LLVM22 サポート）がそれ以前の数週間から継続している。

3.9 智源（主導者）：FEP ガバナンスの着地と RC2 マニフェストの保守（09-17）

日付：2026-09-17　出典：FEP 説明とバージョン追跡、release ディレクトリ

主導者の本期のアクションはすべてガバナンス層にある。20 件の FEP ドキュメントを一度にマージしバージョン追跡を同期更新（詳細は「今日の重点」）；RC2 リリースマニフェストと git レベルのブランチタグ自動化を保守（1.2）；リリースプロセスドキュメントで FEP ライフサイクルを「参入した時点でカウント、卒業は別カウント」の2段階と記載し、フリーズに間に合わなかった FEP は破棄ではなく順延とすることを規定。組織レベルでもう一点記録に値する記述がある。端側と RISC-V が独立方向として単列化され（端側 SIG が活発、RISC-V とオペレーティングシステムのパッケージングの2項目が計画中に入る）、2.2 以降のブランチ意図がガバナンスドキュメントにすでに書き込まれていることを示している。

4. 総括とトレンド観察

一言で：FlagOS 2.2 は「バグ修正のみ受け付け」のテスト期末盤に入り、本期の真の主役はリリース物とドキュメントである。20 件の FEP が機能リストを補完し、24 モジュールすべてが rc2 ブランチを切り出してタグ付けし、イメージライン上のオペレータライブラリとコンパイル基盤は引き続きより新しい候補位置へ切り替わっている。

追跡可能な3本のライン：

第一に、リリース物エンジニアリングが主要な作業面となっている。本期 org 内の 28 リポジトリにプッシュがあり、147 件のコミットがあるが、内容別に分類すると、その比率は明らかにパッケージング、成果物、ゲート、環境変数に偏っている。FlagTree の DEB と Nexus リリースが共有ワークフローへ移行、FlagCX が独立アップロードプロセスを置換、昇騰 wheel アップロード経路が開通、Torch-FL が環境変数面を一套のプレフィックスに収束、FlagQuantum がカバレッジ下限を 75% へ引き上げ。これはリリーススケジュールにおける 09-01 から 09-24 はバグ修正のみ受け付けという規定に合致し、09-28 GA 前の残存リスクが主に「インストールできるか、正しく動くか」にあり機能欠落ではないことを意味する。

第二に、マルチバックエンド適応のフロンティアは依然拡大しているが、形態は分化している。同一週内に、摩尔線程は FlagTree 0.7.0rc2 の飛び級と初のプラグイン付き 0.20.2 イメージを取得、沐曦と摩尔線程は FlagFFT 上でそれぞれ三次元転置検証を行い、昇騰は初めて wheel アップロードを走通し、清微は分散プリミティブを有効化し、一方で昆仑芯は収益の得られなかった高速パスを自発的にロールバックした。「上へ行く」（バージョンと成果物）もあれば、「後戻りする」（無効な最適化の否定）もあり、後者の出現は通常プラットフォーム適応が安定期に入ったシグナルである。

第三に、次版の輪郭がすでにドキュメントに現れ始めている。RISC-V 実験的サポート、オペレーティングシステムのパッケージングとディストリビューション統合、端側 SDK、具身智能と科学智能の2つのワーキンググループが、いずれも FEP 説明の「計画中／インキュベーション中」テーブルに位置を得ている。FEP-0098 も T-Head、燧原、摩尔線程の新バックエンドをアーキテクチャ計画にすでに列挙している。09-28 GA の後、これらの方向がおそらく 2.2 の主線撤退後の注目を引き継ぐだろう。

経過観察：（1）build-infra の version フィールドがいつ 2.2.0 からタグ付けの段階に進むか、および configs.yaml 内のその他のバックエンドのバージョンにさらなる引き上げがあるか；（2）2.2 GA 前後の FEP 状態がドラフトから実装に移行する割合、特にあえてドラフトに留まっている KernelGen 能力項目；（3）FlagAudio、FlagTensor、FlagSparse など従来比較的静かだったモジュールが rc2 ライン内で検収アクションを持つか。

付録：情報源検証表

情報源 検証結果
GitHub org（54 リポジトリ） 28 リポジトリが調査期間内にプッシュあり；14 リポジトリは rc2 ブランチ作成で、デフォルトブランチに新規コミットなし
GitHub commit search 調査期間内のコミット 147 件がヒット（2 ページで全量取得）、14 のリポジトリに分布
git ls-remote（全量 ref） 10 モジュールの rc2 統合ブランチと v*-rc2.post1/post2/post3 タグの実在を検証
community FEP ディレクトリ 本バッチで新規ドキュメント 20 件、番号 0085 から 0100、7 つの SIG をカバー
community 2.2 リリースリスト RC2 リストは 24 モジュール項目；RC1 と RC2 の逐条バージョン対照は完了
community リリーススケジュール 機能凍結 08-31、テスト期間 09-01 から 09-24、GA 09-28
build-infra PR パッチ #922 から #926 まで逐条でファイルリストとバージョンフィールドの変更を照合
Google News RSS（33 組のクエリ語） コンポーネント名は 24 時間ウィンドウでゼロヒット；15 件のヒットのうち約 13 件は株式市場記事で、除外済み
HN Algolia（FlagOS / FlagGems） 調査期間内に関連エントリなし
智源コミュニティ（hub.baai.ac.cn） 紫東太初モデルの転載記事 1 件、検証の結果 FlagOS スタックとのインターフェースがなく、収録せず

完全な情報源リスト