FlagOS デイリーレポート (2026-09-11)

調査期間：2026-09-10 10:18 ~ 2026-09-11 10:18 北京時間 情報源：GitHub（org: flagos-ai、53 個のリポジトリの pushed_at + 単一 commit search 60 件を committer-date で全量検証 + per-repo commits 再確認 + ブランチ API + commit 詳細とパッチ）、Google News RSS（中英文 13 組のクエリ語、プロキシ経由）、HN Algolia、Tavily/web 検索、FlagOS 公式 CSDN アカウント、智源コミュニティ（詳細は付録）

インデックス

1. オープンソースプロジェクトの進展（GitHub 動向）
  - 1.1 FlagTree バージョンが 0.7.0 に収束：29 件のベンダー納品ワークフローを一括切り替え（09-10/09-11）
  - 1.2 build-infra：昇騰 910C アプリケーション層が正式開放、vLLM の 2 バージョン 4 イメージがマトリクスに参入（09-10）
  - 1.3 build-infra：sglang0.5.18 の起動ドキュメントを全マトリクス生成、sglang が一等アプリケーションラインに昇格（09-10）
  - 1.4 build-infra：パッケージングチャネル政策を成文化、インストールチャネルの境界が固定化（09-10）
  - 1.5 FlagTensor：海光 DCU と昆侖芯 XPU のデュアルバックエンドをメインラインにマージ、インストールスクリプトを収束（09-10）
  - 1.6 vllm-plugin-FL：曦望 Sunrise アテンションバックエンドを vLLM 0.24.0 に移植、達磨院玄鉄の静的グラフを復旧（09-10）
  - 1.7 FlagGems：KMCompiler の Ascend/MetaX 二路線推進とインストール面の欠陥修正（09-10）
  - 1.8 ドメインライブラリとツールチェーン：FlagGems-vllm 海光オペレータ、FlagDNN バックエンドドキュメント、FlagCX MUSA、Torch-FL DCU ルーティング（09-10）
  - 1.9 FlagTree エンジニアリング面：清微 CI/CD が組織的に整備、TLE NVIDIA レイアウト最適化は当日マージ・当日ロールバック（09-10）
1. ニュース報道とエコシステム
  - 2.1 コンポーネント級ニュースは 9 回連続の平穏な期間、情報面はすべてコードリポジトリ由来（09-10）
1. メンバー単位の深掘り
  - 3.1 清微智能：コンパイラ線が「バックエンドがコンパイル可能」から「パイプラインの自走」へ（09-10）
  - 3.2 海光信息：オペレータ、テンソルライブラリ、ドメインライブラリドキュメント、ランタイムルーティングの 4 線を同時推進（09-10）
  - 3.3 昆侖芯：FlagTensor XPU バックエンドをマージ、4 層の作業面を並行（09-10）
  - 3.4 曦望芯科と達磨院玄鉄：外部推論 GPU と PPU バックエンドを同一期間に加碼（09-10）
  - 3.5 智源（主導者）：納品パイプラインのバージョン統一とパッケージング政策の 2 件のガバナンスアクション（09-10）
1. まとめ
付録：完全な情報源リスト

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

期間概観：org 内の 53 個のリポジトリのうち 13 個が期間内にプッシュあり；commit search は期間内コミット 60 件をヒット（単一ページ全量、committer-date 降順）、per-repo commits の再確認により Megatron-LM-FL を 1 件追加（search インデックスの遅延により未収録）、合計 61 件、12 個のリポジトリに分布：build-infra 24、FlagGems 10、FlagTree 8、FlagTensor 5、vllm-plugin-FL 3、FlagDNN 3、FlagGems-vllm 2、Torch-FL 2、flir 1、FlagFFT 1、FlagCX 1、Megatron-LM-FL 1。新規リポジトリなし、新規コンポーネントリリース項目なし。

本期間の形態 = RC テスト期の「バージョン収束 + チップマトリクス拡張」の二路線：コンパイラ側では FlagTree が 0.7.0 のバージョン番号収束を完了し、29 件のベンダー納品パイプラインを一括で 0.7.0 に切り替え；納品側では build-infra が昇騰 910C を「base/runtime の骨組みのみ」からアプリケーション層開放へと推進し、sglang を vllm と並ぶ一等アプリケーションラインとした；外部エコシステム側では曦望 Sunrise のコンポーネント級バックエンドの着地と FlagTensor の海光 DCU、昆侖芯 XPU のデュアルバックエンドマージが出現。前期間の「910C はいつ deps_app を補完して app ビルドマトリクスに入るか」という予測が本期間で実現した。

1.1 FlagTree バージョンが 0.7.0 に収束：29 件のベンダー納品ワークフローを一括切り替え（09-10/09-11）

來源：FlagTree #1144（09-10 23:38）、#1151（09-11 02:31）

メインバージョンを 0.7.0 に更新（#1144）：バージョン関数を "0.7.0+" + flagtree_backend + コミットハッシュ に変更（バックエンド接尾辞がない場合は 0.7.0 + ハッシュを返す）。このコミット内で並行して6項目の付随対応を実施——PPU/HCU の qwen3.6 benchmark 性能ベースラインの更新、README への tsingmicro3.6 説明の追加、wheel 内への LICENSE 追加、TileIR の third_party ダウンロード修正、Iluvatar ワークフローのライブラリパス修正。README のベンダー/バックエンド表も「Installation」から「User Guide」へ変更し拡充。
29 本のベンダー納品ワークフローを一斉に 0.7.0 へ切り替え（#1151）：*_delivery.yml 内のバージョン入力パラメータのデフォルト値を '0.6.0' から一括で '0.7.0' に変更し、同時に ppu3.6 コアテストワークフローも更新。対象の29ラインは以下の通り：nvidia3.3/3.5/3.6/3.7/3.8、tileir3.6、amd3.6、ascend3.2/3.5、enflame3.5-gcu400/3.6-gcu400、iluvatar3.1/3.6、metax3.0/3.6、mthreads3.1/3.2/3.6、tsingmicro3.3/3.6、sunrise3.4、xpu3.0/3.6、hcu3.1/3.6、aipu3.3、thrive3.6、ppu3.6。
ブランチ側の状態：0.7.0-rc0-triton3.3/3.5/3.6 の3ラインのヘッドはそれぞれ 08-11、08-27、08-31 で停止。0.7.0-rc1-triton3.3/3.5/3.6 は 09-01、09-04、09-04 で、うち rc1-triton3.6 のヘッドコミットは [Tsingmicro] Add Tsingmicro backend integration (Triton 3.6)（#1071）。
正式リリースはまだ出現していない：GitHub Releases 上の FlagTree の最新エントリは依然として 0.6.0+triton3.x（2026-06-24）。今回の調査期間の動きは「納品パイプラインが先行し、バージョン番号が収束する」段階であり、正式タグは未発行。

解釈：0.7.0 の進め方は RC 期の規律を明確に示している——コードの路線は変更せず、バージョン番号と納品エントリの収束のみを行う。まず main でパッケージバージョンを 0.6.0 から 0.7.0 に引き上げ、次に全29本のベンダー納品パイプラインを一斉に 0.7.0 に向けることで、RC1 リストにある「flagtree 3ライン統一 0.7.0rc1.post1」のアンカーを正式バージョンへと押し進める。追跡に値する一つのずれは、build-infra の configs.yaml において NVIDIA ラインが依然として flagtree==0.6.1 に pin されている点である。すなわち「納品済みイメージが固定しているコンパイラバージョン」と「コンパイラメインラインバージョン」の間に1バージョン分の進展差が存在し、これこそが GA 前に埋めるべき隙間である。

1.2 build-infra：昇騰 910C アプリケーション層が正式開放、vLLM 2バージョン4イメージがマトリクス入り（09-10）

情報源：build-infra #816（09-10 18:36）、#813（15:07）、#808（11:00）、#818/#819、#823/#824、#820、#825、#826、#828、#833、#834

アプリケーション層の開放（#816、+257/-16）：コミット説明には「910C の runtime イメージがビルド・プッシュ済みのため、vllm アプリケーションラインは 2 本の 910C ライン（ascend-cann8.5.0-910c / ascend-cann9.0.0-910c）で開放可能」と記載されている。同時に 4 件の changelog を新規追加——vllm0.20.2 と vllm0.24.0 がそれぞれ CANN 8.5.0 と 9.0.0 に対応；変更は vllm-app-image.yml、app/vllm/Containerfile、configs.yaml、docs/status-matrix.md、2 本の status_matrix.vllm*.yaml とレンダリングスクリプトに及ぶ。
910C アプリケーションイメージ tag の登録開始：#818/#819 は CANN 8.5.0-910c の 2.1.2-0.2.0_g2b6b635.d20260824 と 2.1.2-0.2.0_gcf8998c.d20260818 を記録し、#823/#824 は CANN 9.0.0-910c の対応 tag を記録。
開放に向けた安定化：#808 は 910C base イメージ内の apt Post-Invoke フックを除去；#813 は昇騰起動テンプレートで die ペア全体を公開（同一 die 内の 2 カードがペアで可視化）；#820 は ascend の verify 失敗を自己診断可能に；#825 は runner プロキシを verify インストール手順へ転送；#826 は ruamel.yaml を import できる runner python を選択；#828 は verify Step 2 のクォートエスケープを修正；#833 は対象 ref に stub が含まれる場合のみ flashinfer stub をビルド；#834 は cell のプラグイン pin を vllm アプリケーションイメージビルドへ引き渡し。

解説：これは前の調査期間で予測した内容が正確に実現したものである。09-10 レポートの観察点は、910C が「910B ラインのチップと同構変体方式で接続し、deps_app の欠如により app マトリクスの外に阻止されている」というもので、当時は「app 成果物が生成され検証された後に開放する」と予測していた。本調査期間の #816 はまさにそのゲートが開かれたことを示している：910C の提供形態が「base/runtime 利用可能」から「アプリケーション利用可能」へとアップグレードされ、かつ一度に 2 つの CANN × 2 つの vLLM バージョン = 4 つのアプリケーションイメージ項目が提示された。付随する 9 項目の verify/テンプレート/イメージ修復は、まさに「新規対応は進められるが、新機能は入れない」という規律の下での収尾工程である——まず verify の自己診断、プロキシ転送、依存選択といった環境問題がパイプラインを遮断しないようにし、その後でマトリクスを開放する。

1.3 build-infra：sglang0.5.18 起動ドキュメント全マトリクス生成、sglang が一級アプリケーションラインに昇格（09-10）

出典：build-infra #831（09-10 21:38）、#817（19:13）、#821（19:20）、#829（20:42）、#830（20:55）

#831 生成器のフィルタリングロジックを修正（+2862/-34）：コミット説明によると、生成器が a in APP_IMAGE_DEFAULTS or a.startswith("vllm") で deps_app キーをフィルタリングしていたため、sglang0.5.18 がレンダラーに入る前に破棄されており、これまで sglang アプリケーションイメージのいずれも起動ページを持っていなかった。修正後、すべての sglang アプリケーションイメージに対して中英二言語の起動ドキュメントが生成されるようになった。
カバーされる sglang アプリケーションライン：ascend-cann8.5.0 / ascend-cann9.0.0（昇騰）、cambricon-neuware4.4.3 / 4.7.2（寒武紀）、enflame-tops1.9.10 / 1.10.6（燧原）、hygon-dtk26.04（海光）、iluvatar-corex4.5.0（天数智芯）、metax-maca3.7.2.1 / 3.8.1.3（沐曦）など。
付随項目：#817 で iluvatar-corex4.5.0 を sglang 0.5.18 ラインに引き上げ；#821 で sglang0.5.18-iluvatar-corex4.5.0 changelog を追加；#829 で changelog 内の余分な image キーを修正；#830 で app image tag 2.1.2-0.1.dev1_g201484665 を記録。
同期間のイメージ説明更新：#810 と #814 でそれぞれ base と runtime イメージの 2.1.2 説明文を更新、#815 で flaggems-release の runtime:v1 イメージ tag を configs.yaml から導出するようにした。

解説：これは表面的に見える以上に重要である。vllm と sglang は FlagOS が対外的に推論能力を提供する 2 本のメインフレームワークラインであり、これまでマトリクスの実際の形状は「vllm は全量、sglang は散発的」であった。本調査期間の動きにより、sglang0.5.18 が少なくとも 10 のチップラインで起動ドキュメントと changelog を整備したことは、sglang が提供口径においてすでに vllm と並列したことを意味する；これは本調査期間の FlagGems-sglang 賽事ライン、09-07 レポートに記録された「KubeCon 開放 AI 計算フォーラム」と呼応している——推論フレームワークのカバレッジの広さが、コミュニティの対外展示における主要な次元になりつつある。

1.4 build-infra：パッケージングチャネル政策が成文化、インストールチャネルの境界が固定化（09-10）

出典：build-infra #812（09-10 21:45）

docs/content/en/usage/packaging-channels.md（122 行）と docs/content/zh-cn/usage/packaging-channels.md（97 行）を新規追加し、前期に議論した結論をポリシーとして固定化：deb/rpm チャネルは純粋な Python パッケージとネイティブライブラリを担当し（ターゲットディストリビューションごとに1リポジトリ1ソース）、各ベンダーのプライベート PyPI インデックスはベンダー側の依存関係を担当するという両者の境界が明示的に記述された。

解釈：これは 2.2 GA 前のガバナンス型コミットであり、前の調査期間の 60 個の app イメージ changelog ベースライン + push ゲートと同一の文脈にある。まず「成果物がどこから来るか」を説明でき、次に「依存関係をどこからインストールするか」を説明する。10 社以上のチップベンダーのプライベートツールチェーンをカバーしようとするソフトウェアスタックにとって、インストールチャネルのポリシー化はマルチベンダー配布が規模化できるかの前提条件である。

1.5 FlagTensor：海光 DCU と昆布芯 XPU のデュアルバックエンドがメインラインにマージ、インストールスクリプトを収束（09-10）

情報源：FlagTensor #5153939 / #1be84f2（09-10 10:37 各1件）、#81c6214（10:39）、#2f895c1（10:47）、#efed2c4（10:48）

2つの新バックエンドをマージ：feat: merge Hygon DCU + Kunlunxin XPU backend support は海光ブランチ（FlagTensor-haiguang の対応成果を含む）を main にマージし、統計は +4225/-168（4393 行）、変更の主体は benchmark とバックエンド対応層である。同じ分に別途 add Hygon DCU and Kunlunxin XPU backend support がある。
インストールとドキュメント面の収束：#2f895c1 は setup_muxi.sh を統一 setup.sh --backend metax の1ブランチにマージした；#efed2c4 は独立スクリプトを削除した；#81c6214 は沐曦専用性能レポート PERF_REPORT_metax.md を削除した。

解釈：「バックエンド数 +2、メンテナンス面 -1 セットの専用スクリプト」という方向性は一貫している。一方で海光 DCU と昆布芯 XPU という2種類の新ハードウェアをテンソルライブラリに取り込み、他方でベンダー専用のインストールパスを統一エントリに収束させ、ベンダー数の増加に伴って線形に膨張するスクリプトメンテナンスコストを回避する。FlagTensor は 6 月の「科学智能基座」リリースにおける六大領域ライブラリの一つであり、そのマルチバックエンド拡張は科学計算ライブラリが依然として「一度開発すれば、複数チップで動作する」目標に沿って展開されていることを示している。

1.6 vllm-plugin-FL：曦望 Sunrise アテンションバックエンドを vLLM 0.24.0 に移植、達摩院玄鉄の静的グラフを復旧（09-10）

情報源：vllm-plugin-FL #391（09-10 20:01）、#472（10:33）、#480（18:22）

#391（+37/-1）：タイトルは「Sunrise バックエンドを vLLM 0.24.0 に移植する」であり、コミット説明には対象が Sunrise（曦望 TANGRT 1.2.0） であると明記されている。2箇所の変更はいずれも sunrise vendor パス配下にある——attention.py は CUSTOM モードでアテンションバックエンドを登録し、patch.py は ptpu の memory_stats 互換層を追加している。
#472：達摩院玄鉄（thead）バックエンドの静的グラフサポートを復旧（前期コミットに起因する回帰修正）。
#480：PR に /rerun-failed-ci と /cancel-ci の2つのコメントコマンドを追加；リポジトリ README のチップベンダー表は既に Sunrise を Supported として記載している。

解説：これは本調査期間における外部エコシステムで最も実質的な一歩である。09-07/09-08 の調査期間で記録された曦望の進展は「runner 環境設定が先行、コンポーネントのマージはまだ」というものだったが、本調査期間ではコンポーネントレベルの実装が完了した——曦望のツールチェーンバージョン（TANGRT 1.2.0）を vLLM 0.24.0 の接続前哨プラグインに組み込んだのである。FlagOS にとって、これは「新チップ接続」の標準パス（まず統一環境で runner を立ち上げ、次に vllm-plugin-FL で vendor バックエンドを実装する）が一通り走り切ったことを意味し、再利用可能な接続テンプレートである。#480 の 2 つの CI 運用コマンドと build-infra の verify 自己診断は、いずれも「マルチベンダー CI の維持コスト」のエンジニアリングコスト削減に属する。

1.7 FlagGems：KMCompiler の Ascend/MetaX 二本立て推進とインストール面の欠陥修正（09-10）

情報源：#6138、#5821、#6155、#6160、#6156、#6157、#6146、#6087、#6147、#6131

KMCompiler 生成パス：[KMCompiler][Ascend] Opt replication pad2d backward（#6138）、[KMCompiler][Ascend] Add ascend backend for linalg_solve_triangular（#5821）、[KMCompiler][MetaX] Fix gru bug（#6155）——「一度の開発で複数バックエンドに展開」するオペレータ追加方式を継続。
ベンダー CI ラインの縮小：fix(.github): remove metax-maca3720 info（#6160）、前期の CI エントリ削除に続き残存情報をクリーンアップ。
インストールと実行の正確性修正：#6146 で欠落していた DSA/__init__.py を補い、非編集インストールでも当該サブパッケージを含めるようにする（下流プラグインのインストール完全性に直結）；#6087 でインデックスオペレータの pid_p を int64 に変換し、int32 オフセットオーバーフローを修正；#6147 で adaptive_avg_pool3d_backward のスケジューリング指定ミスを修正；#6131 で irshift の benchmark 命名を修正。
エンジニアリング面：#6157 で init exports チェックを拡張；#6156 でサードパーティファイルに誤って付与された Apache 2.0 ヘッダをクリーンアップ。

解説：前調査期間が「39 件、KernelGen の大量トラフィックオペレータの取り込みが中心」だったのに対し、本調査期間ではメインリポジトリのコミット数が 10 件に減少し、構造も「量の拡大」から「カバレッジと基盤固め」へと転換している：生成器パスは引き続き昇騰、沐曦へバックエンドを補完し、その他はインストール完全性と数値正確性に集中している。なかでも #6146 のような「サブパッケージがインストールされない」欠陥は下流への影響が最も大きい——vllm/sglang プラグインはいずれもオペレータライブラリの完全なインストール面に依存しており、この種の修正こそが RC 期に「動く」を「インストールでき、正しく動く」に変える典型的なアクションである。

1.8 ドメインライブラリとツールチェーン：FlagGems-vllm 海光オペレータ、FlagDNN バックエンドドキュメント、FlagCX MUSA、Torch-FL DCU ルーティング（09-10）

出所：FlagGems-vllm #736、#704、Torch-FL #270、#247、FlagCX #576、FlagDNN、FlagFFT、Megatron-LM-FL #148

FlagGems-vllm：#736 [AdvancedCompiler] add hygon fused_add_rms_norm、海光専用オペレータ実装325行を新規追加し _hygon バックエンドに登録、同時に旧版 Triton 向けに TensorDescriptor インポート保護を追加；#704 は moe_sum に pair-load 高速パスを追加。
Torch-FL：#270 perf: restore fused SDPA on the boxing route via a composite override（+658 行）、根本原因はコミットと添付ドキュメント（docs/bench_qwen3_dcu_route_perf.md）に記載——aten::scaled_dot_product_attention は composite op であり、融合バックエンドの選択は composite 内部で行われるため、leaf ごとに分解されて融合パスが失われ、composite 層のオーバーライドで復元した；この作業は明確に DCU ルートを対象としている。また #247 は transformers テストの自動トリアージパイプラインを追加。
FlagCX：#576 [PAL] Link default device API backend for MUSA platform、摩尔線程 MUSA プラットフォーム向けにデフォルト device API バックエンドを接続（makefiles/musa.mk）。
FlagDNN：連続3件のバックエンドドキュメントコミット——海光 readme 新規追加、海光 readme 修正、天数智芯 readme 新規追加。
FlagFFT：README のバックエンドサポート説明を更新し依存関係を明確化。
Megatron-LM-FL：#148 fix(platform): prefer native accelerator detection、プラットフォーム検出でネイティブアクセラレータ識別を優先。

解読：このグループは「領域ライブラリと訓練/推論ツールチェーン」の横断的な広がりである：海光（オペレータ＋テンソルライブラリ＋領域ライブラリドキュメント＋ランタイムルーティング）、摩尔線程（通信ライブラリのプラットフォーム接続）、天数智芯（ドキュメント）が同一調査期間にそれぞれ動きを見せている。Torch-FL の成果物には独立したベンチマークドキュメントと stub ソースコードがあり、稀な「性能問題に完全な証拠チェーンが付随する」コミットであり、訓練/推論ルートにおける性能回帰が通常のトラッキングに組み込まれたことを示している。

1.9 FlagTree 工程面：清微 CI/CD が組織的に整備、TLE NVIDIA レイアウト最適化が当日マージ・当日ロールバック（09-10）

出典：FlagTree #1118、flir #69、#1047、#1139（revert）、#1075、#1074、#1143

清微側のコンパイラ基盤（#1118、+344/-10）：tsingmicro バックエンドと FLIR の合同ビルドを修正し、2 本のワークフローを新規追加——tsingmicro3.6-build-and-test.yml（115 行）と tsingmicro3.6-delivery.yml（191 行）。CMake 側には FlagTreeOptions スイッチを追加し、third_party/tsingmicro の Tx81 ランタイムとサンプルテストも同時に修正。コミットは清微側のパッチとコミュニティボットの共同署名によるもの。FLIR 側の対応コミット #69 では、LLVM 22 をサポートするため清微の FLIR パッチを同期（FLIR は FlagTree の IR 中間層であり、triton-shared から fork したもの）。
TLE NVIDIA レイアウト最適化は当日マージ・当日ロールバック：#1047 は 12:35 に「shuffle による同 warp 内 layout 変換の下放」をマージしたが、13:47 に #1139 でロールバックされた。同一調査期間の MTHREADS 側では 2 件の実質的なマージが維持された：#1074（SQMMA 構成において純粋な M-split を選択するよう傾向付け）、#1075（PH1 の swizzled 共有メモリアクセスを LinearLayout 経由で下放）。
その他：#1143 は燧原パスにおける of 名前空間の gcc7 コンパイルエラーを修正。

解釈：清微のこの一連の動きは、コミュニティに配線を待つのではなく、自らビルドとデリバリのワークフローを備える能力があることを示している——これまで FlagTree において Triton 3.3 バックエンド形態でのみ存在していたベンダーにとって、これはかなり完備された一歩である。逆に、TLE NVIDIA の当日ロールバックはエンジニアリングのリズムを示す注釈として注目に値する：RC 凍結期間中、性能最適化がリグレッションを引き起こした場合、問題を抱えたまま進めるのではなく当日にロールバックするという処理は、「新規対応は可、新規特性は不可」という規律と一致している。

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

2.1 コンポーネントレベルのニュースは 9 回連続の平静な調査期間、情報面はすべてコードリポジトリ由来（09-10）

出典：Google News RSS 中国語・英語 13 組のクエリ（09-10 10:18 ~ 09-11 10:18、プロキシ経由）、HN Algolia、FlagOS 公式 CSDN アカウント、智源コミュニティ

コンポーネント単位のクエリはすべてゼロヒット：FlagOS when:2d、FlagOS when:14d、FlagGems when:3d/14d、FlagScale when:3d、FlagTree when:7d、FlagCX when:14d、FlagAttention OR FlagPerf when:14d、KernelGen when:7d、BAAI open source when:2d、沐曦开源算子 when:2d など中国語・英語のクエリはいずれもヒットせず、コンポーネント単位検索における9回連続の平穏な調査期間を構成している。
メンバー機関の語はノイズまたは資本市場関連の内容：摩尔线程智源 when:2d は12件ヒットし、主体は京東雲の10万カードクラスタに関する転載と株価関連報道（09-09の調査期間で既に記録済みの内容の継続）、およびギャンブル系SEO記事である；智源研究院オープンソース when:2d は9件ヒットし、智源コミュニティの通常記事とギャンブルSEO（具身智能系のコミュニティ記事、AI紛争裁判などを含む）であり、FlagOS技術スタックとは直接の関連がなく、既存の基準に従い一括で除外する。
HN Algoliaのヒットは部分文字列の誤マッチ：FlagOS/FlagGems/FlagTree/FlagScale/BAAIの5組のクエリのタイトルはいずれもflags/flagship系の無関係な項目（「15x10 Pixel Flags」、Show HNシリーズなど）であり、本技術スタックを指すものは一件もなく、一括で除外する。
公式コンテンツチャネルに新規リリースなし：FlagOS公式CSDNアカウントは調査期間内に新規記事がなく、最新は依然として08-28のGLM-5.3-Flash Day0の9款チップ適合である；09-07のKubeCon同会場フォーラムとオペレータチューニングのテーマページは継続して掲載されており、リリース時点の更新はない。智源コミュニティと公式サイトも調査期間内にFlagOS関連の新規リリースはない。

解読：ニュース側とコード側の分化は本調査期間で最近最大に達した——61件のコミットにはバージョン収束、昇騰910Cアプリケーション層の開放、sglang全マトリクスドキュメント、2つの新バックエンドのマージなど実質的な進展が含まれる一方、外部報道はゼロである。これはFlagOSの現在の対外的な声量がエンジニアリングの進捗と同期していないことを示しており、コミュニティの情報発信は依然として「モデルDay0適合」と「大会フォーラム」の2種類のノードに集中している；本調査期間の進展はデリバリーとコンパイラの主線から読み取る必要があり、この判断は追跡のリズムに直接影響する。

3. メンバー機関の深掘り

3.1 清微智能：コンパイラ線が「バックエンドがコンパイルできる」から「パイプラインの自持」へ（09-10）

情報源：FlagTree #1118、flir #69

調査期間内の3つのアクションは同じ事柄を指している：FlagTreeにtsingmicro3.6のbuild-and-testとdeliveryの2つのワークフローを新規追加し、FLIRとの联合ビルドを修正した；FLIRは同期して清微パッチをクリアしLLVM 22をサポートした；FlagTree README変更ログに「2026/09/10 清微バックエンドをTriton 3.6にアップグレードしCI/CDを追加」と記録されている。
デリバリー面：tsingmicro3.3とtsingmicro3.6の2つのラインはいずれも本調査期間の0.7.0統一切り替えリスト内にある。

解読：清微はこれまでFlagTreeにおいて「Triton 3.3ベースのバックエンド統合」という形態であったが、本調査期間後は「自前のビルド/デリバリーワークフローを持ち、LLVM 22とTriton 3.6に整合した通常のデリバリーライン」に変わった。メンバーに対する判断価値は以下の点にある：コンパイラ層の新世代へのサポートがもはやコミュニティの代行に依存していないことは、清微側のコンパイラチームが独立した保守能力を備えていることを示す；2つの製品ラインが同時にデリバリーマトリクスに参入したことも、その世代切り替えがFlagOSの通常のバージョンリズムに組み込まれたことを示す。

3.2 海光信息：オペレータ、テンソルライブラリ、ドメインライブラリドキュメント、ランタイムルーティングの4ラインが同時に推進（09-10）

情報源：FlagTensor #1be84f2、FlagGems-vllm #736、Torch-FL #270、FlagDNN、build-infra #831

本調査期間において海光は分散しているが同じ方向を向いた四つの動きを示した：FlagTensor が DCU バックエンドをマージ（+4225 行）；FlagGems-vllm が海光専用の fused_add_rms_norm を新規追加（325 行）；FlagDNN が海光バックエンドドキュメントを新規追加；Torch-FL が DCU ルーティング向けに融合 SDPA を復元しベンチマークドキュメントを残した。デリバリ側では別途 sglang0.5.18-hygon-dtk26.04 の起動ドキュメントが全マトリクスに入った。
09-09 ウィンドウで記録された「海光 Token 経営デュアルチップ加速方案」と合わせると、海光のソフトウェアスタック内での動きは初期のオペレータ専用化からテンソルライブラリバックエンド、ドメインライブラリドキュメント、ランタイム性能ルーティングへと拡大している。

解読：海光は現在 FlagOS 内で最も作業面が広いメンバー単位の一つである——オペレータライブラリ、テンソルライブラリ、ドメインライブラリドキュメント、推論プラグイン（sglang アプリケーションライン）、そして Torch-FL のランタイムルーティングまで、いずれも進行中の作業がある。その商業ナラティブ（Token 工場）とソフトウェアスタックのカバレッジが同時に推進されていることは、海光 DCU の FlagOS における位置づけが「対応されるチップ」から「深度共創メンバー」へと移行しつつあることを意味する。

3.3 昆仑芯：FlagTensor XPU バックエンドがマージ、四層の作業面が並行（09-10）

情報源：FlagTensor #1be84f2、FlagTree デリバリライン一覧

本調査期間において FlagTensor は昆仑芯 XPU バックエンドと海光 DCU をまとめてメインラインにマージした；デリバリ側では xpu3.0 と xpu3.6 の二本のワークフローが 0.7.0 統一切り替えに組み込まれた。
前期の記録と繋げて見ると：09-02 ウィンドウの FlagGems では昆仑芯バックエンドの slice_scatter 境界外修正があり、09-08 ウィンドウの FlagScale では昆仑芯 P800 の訓練 CI とランタイムサポートがあり、09-09 ウィンドウでは FlagGems-Experimental の昆仑芯 KernelGen オペレータのバッチマージが記録されている。

解読：昆仑芯は現在「テンソルライブラリ（FlagTensor）、オペレータライブラリ（FlagGems）、訓練フレームワーク（FlagScale）、コンパイラデリバリ（FlagTree xpu 二本のライン）」の四層すべてに進行中の作業面を持ち、形態としてはすでに深度対応ベンダーに近づいている。昆仑芯がコミュニティ公開のメンバー単位名簿に含まれていないことを考慮すると、その投入強度は外部エコシステム拡張のサンプルとして継続的に追跡する価値がある。

3.4 曦望芯科と達磨院玄鉄：外部推論 GPU と PPU バックエンドが同一ウィンドウで積み増し（09-10）

情報源：vllm-plugin-FL #391、#472、FlagTree #1144

曦望芯科（Sunrise）：vllm-plugin-FL が同社のアテンションバックエンドを vLLM 0.24.0 に移植（対象は同社の TANGRT 1.2.0 ツールチェーン）し、「runner 環境のみ」から「コンポーネント級バックエンド」への飛躍を完了。デリバリ側では sunrise3.4 を 0.7.0 切り替えに組み込み、公式チップベンダー表に Sunrise が掲載済み。
達摩院玄鉄（T-Head）：vllm-plugin-FL #472 が同社バックエンドの静的グラフサポートを復旧。デリバリ側では ppu3.6 を 0.7.0 切り替えに組み込み、FlagTree #1144 が PPU の qwen3.6 benchmark 性能ベースラインを同時に更新。

解説：両社とも「非メンバー組織の推論側投入」に属する。曦望は推論 GPU に特化した中国国内ベンダーであり（製品ライン S1/S2/S3 は推論シナリオ向け）、上流を追随するプラグインラインである vLLM 0.24.0 で実装を選んだことは、インターネット／クラウド側の推論デプロイ経路が中国国内チップベンダーにとって依然として魅力的であり続けていることを示す。達摩院玄鉄の静的グラフ修正と PPU デリバリラインの 0.7.0 への統合は、RISC-V 文脈で最も代表的な算力バックエンドとして、FlagOS のデリバリマトリクスにおいて通常の位置の更新リズムを維持していることを示している。

3.5 智源（主導機関）：デリバリパイプラインのバージョン統一とパッケージング政策の二つのガバナンスアクション（09-10）

情報源：FlagTree #1151、build-infra #812、release-info

主導機関の本調査期間のアクションは機能ではなくガバナンスに集中：FlagTree の 29 本のベンダーデリバリワークフローのバージョン番号を統一（コミュニティ側メンテナがコミット）、パッケージングチャネルの境界を中英二言語ドキュメントポリシーとして明文化。
リリースマニフェストリポジトリ release-info は調査期間内に内容更新なし（依然として初期 README のみ）で、2.2 の正式リリースマニフェストがまだ確定していないことを示す。

解説：三つの情報を合わせて見ると、2.2 GA（スケジュールは 09-28）に向けた準備の重心は「機能と対応」から「デリバリの口径とインストールチャネル」へ移っている：バージョン番号は十数社のベンダーデリバリラインを揃える必要があり、依存ソースには依拠できる政策が必要であり、リリースマニフェストは全成果物を一度に説明できなければならない。この種の作業は外部からは見えないが、GA 当日に再現可能なデリバリ面を提示できるかを直接左右する。

4. まとめ

本調査期間（09-10 10:18 ~ 09-11 10:18）の GitHub 側は 調査期間内コミット 61 件、プッシュのあったリポジトリ 13 件で、エンジニアリング側は高い活発度を維持。ニュース側のコンポーネント級検索は9 回連続の平穏な調査期間となり、外部報道はゼロで、すべての情報はコードリポジトリ由来。四つの主線：

FlagTree 0.7.0 がデリバリ収束期に入る（本調査期間で最も重要な変化）：メインラインバージョン番号が 0.6.0 から 0.7.0 に引き上げられ、29 本のベンダーデリバリワークフローのバージョン入力パラメータが一括で 0.7.0 に切り替えられ、NVIDIA の六本の triton ライン（TileIR と特殊形態を含む）、AMD、昇騰、燧原、天数智芯、沐曦、摩尔線程、清微、曦望、昆仑芯 XPU、HCU、AIPU、Thrive、PPU などをカバー；rc0/rc1 の三級ブランチ（triton 3.3/3.5/3.6）は以前から整備済みで、正式 release tag はまだ未発行。これは 2.2 RC 期のバージョン収束が最終段階に達したことを意味する。
昇騰 910C が「base → app」の二級落地を完了、sglang が一等アプリケーションラインに昇格：910C の runtime イメージビルドプッシュ後、vllm アプリケーションラインが CANN 8.5.0 と 9.0.0 の二本の 910C ラインで開放（vLLM 0.20.2 と 0.24.0 の四個のアプリケーションエントリをカバー）され、九項目の verify／テンプレート／依存安定化修正を補完；同時に少なくとも 10 本のチップライン向けに sglang0.5.18 の起動ドキュメントと changelog を生成し、推論フレームワークマトリクスは「vllm 全量、sglang 散発」から二線並重へ変化。
外部および非メンバーベンダーが引き続き加碼：曦望 Sunrise がコンポーネント級バックエンド落地を完了（runner 環境から vLLM 0.24.0 の vendor バックエンドへ推進）、昆仑芯 XPU と海光 DCU のデュアルバックエンドが FlagTensor にマージ、清微が tsingmicro3.6 の双方向 CI/CD を新規追加し LLVM 22 と Triton 3.6 に整合——新チップ接続の標準経路（環境先行 → プラグインバックエンド → デリバリライン統合）が複製可能であることが実証された。
RC 期の規律がエンジニアリングの細部に繰り返し現れる：TLE NVIDIA のレイアウト最適化が当日マージ・当日ロールバック、FlagGems が沐曦の残存 CI エントリを削除、インストールサブパッケージ完全性修正、パッケージングチャネル政策の成文化——フリーズ期のアクションは「正確性と口径を修正し、新機能は入れない」であり、同日ロールバックとインストール面の修正はこの規律の最も直接的な証拠である。

予測：今後の観察ポイントは四点——其一、910C の最初の app image tag がいつ registry 記録に入り、status matrix の「検証済み」列に現れるか（これが 910C のデリバリー可用化の最終的な指標である）；其二、FlagTree 0.7.0 の正式 release tag と build-infra の flagtree pin がいつ追随するか（現在 NVIDIA ラインは依然として 0.6.1 に pin されており、一バージョンのずれが存在する）；其三、2.2 GA（09-28）前の rc1.postN の増分ペースと community/release-info リストの動き；其四、曦望の接続経路が vllm から sglang ラインへ拡大するかどうか、および昆仑芯が公開メンバー名簿に組み入れられるかどうか。

限界に関する説明：本調査期間の全項目は GitHub のコミット、ワークフローファイル、パッチ内容に由来する；ニュース側は九回連続の平穏な調査期間であり、独立してクロス検証可能な第三者報道は存在しないため、「バージョン収束」「デリバリー可用化」といった類の判断はすべてコミット本文とファイル変更に基づくものとし、第三者の伝聞は採用していない。Google News の中国語・英語 13 組のクエリはゼロヒット、HN のヒットは部分文字列の誤マッチであり、いずれもありのままに付録へ記録した。

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

情報源	検証結果
GitHub org repos API（flagos-ai、53 リポジトリ、pushed 順）	13 リポジトリがウィンドウ内でプッシュ：build-infra（09-11 10:06）、FlagTree（09-11 10:05）、FlagBLAS（09-11 10:14、デフォルトブランチにウィンドウ内コミットなし、ブランチ操作と判定）、vllm-plugin-FL、FlagGems、FlagGems-vllm、FlagDNN、Torch-FL、flir、FlagFFT、FlagCX、FlagTensor、Megatron-LM-FL；新規リポジトリなし（最新作成リポジトリは 08-15）
GitHub commit search（org 全量、committer-date > 2026-09-10T02:18Z、単一ページ 60 件全量）	committer 時間とリポジトリ帰属を逐条検証：build-infra 24 / FlagGems 10 / FlagTree 8 / FlagTensor 5 / vllm-plugin-FL 3 / FlagDNN 3 / FlagGems-vllm 2 / Torch-FL 2 / flir 1 / FlagFFT 1 / FlagCX 1
GitHub per-repo commits 再確認（Megatron-LM-FL、FlagBLAS、FlagGems-Experimental）	Megatron-LM-FL #148（09-10 10:47）がウィンドウ内に入り、search インデックスの遅延により未収録、追加済み；FlagBLAS デフォルトブランチの最新コミットは 09-09（ウィンドウ外）、ウィンドウ内プッシュはブランチ由来；FlagGems-Experimental 最新コミット 09-10 09:11（ウィンドウ外）
GitHub ブランチ API（FlagTree）	0.7.0-rc0-triton3.3/3.5/3.6 ヘッド時間 08-11 / 08-27 / 08-31；0.7.0-rc1-triton3.3/3.5/3.6 は 09-01 / 09-04 / 09-04（rc1-triton3.6 ヘッドは清微バックエンド統合 #1071）
GitHub commit 詳細とパッチ	#1151 は計 29 のデリバリーワークフローファイル、デフォルトバージョン ‘0.6.0’ → ‘0.7.0’（コミッター zhengyang@baai.ac.cn）；#816（273 行、4 つの 910C vllm changelog + status matrix）；#831（2896 行、sglang0.5.18 起動ドキュメントマトリクス）；#1118（354 行、清微 build-and-test + delivery）；FlagTensor バックエンド統合（4225 行 / 4393 行）；vllm-plugin-FL #391（sunrise、対象は TANGRT 1.2.0）；FlagGems-vllm #736（海光 op 325 行）；Torch-FL #270（658 行、DCU ルーティングベンチマークドキュメントを含む）；FlagCX #576（MUSA PAL）
GitHub tags / releases API	本ウィンドウに新規 release なし。最新アンカー：FlagGems v5.4.0-rc1.post1、FlagTree 0.6.0+triton3.x（Releases）/ デリバリーラインは既に 0.7.0 に切替、FlagCX v0.14.0-rc1.post1、FlagGems-vllm v0.2.0-rc1.post1、vllm-plugin-FL v0.3.0-rc1.post1、FlagBLAS v0.3.0-rc1.post1、FlagTensor v0.3.0-rc1.post1、FlagDNN v0.3.0-rc1.post1、FlagFFT v0.2.0-rc1.post1、Torch-FL v0.2.0-rc1.post1、FlagOS-Robo v0.1.0
raw.githubusercontent（FlagTree / vllm-plugin-FL / build-infra / flir の README と configs.yaml）	FlagTree ベンダー表に NVIDIA（TileIR 含む）、AMD、燧原、天数智芯、海光、摩尔線程、達摩院、輝羲智算、沐曦、曦望、崑崙芯、達摩院玄鉄（T-Head）、進畳時空、清微智能を含む；vllm-plugin-FL ベンダー表に Sunrise（Supported）を含む；build-infra configs.yaml の NVIDIA ラインは依然 flagtree==0.6.1 を pin、sunrise / tsingmicro / kunlun / hygon / mthreads / iluvatar / cambricon / metax / enflame キーを含む；flir は FlagTree IR 中間層（triton-shared からの fork）
Google News RSS（中英文 13 組クエリ語、プロキシ経由）	コンポーネント級クエリはすべてゼロヒット（9 回連続の平穏ウィンドウ）；メンバー機関語のヒットは京東雲十万カードクラスタ

転載、株価/ロックアップ解除類およびギャンブル SEO 記事は、既存の基準により技術項目には含めない
	HN Algolia（FlagOS / FlagGems / FlagTree / FlagScale / BAAI）	すべて flags/flagship/flocked の部分文字列の誤マッチによる無関係な項目であり、バッチ全体を除外
	FlagOS 公式 CSDN アカウント（flagos.csdn.net）	調査期間内に新規記事なし。最新は依然として 08-28 の GLM-5.3-Flash Day0 の 9 チップ対応。09-07 KubeCon 同会場フォーラムページとオペレータチューニング特集ページに公開時点の更新なし
	智源コミュニティ（hub.baai.ac.cn）	調査期間内のヒットはコミュニティの通常コンテンツ（エンボディド AI、AI ガバナンス等）で、FlagOS 技術スタックとは直接の関連なし
	Tavily / web 検索	曦望芯科の背景検証（公式サイト、量子位、钛媒体の3情報源）。FlagOS バージョンリズムの歴史的アンカーの検証（衆智 FlagOS 1.6 / 1.5 公式プレスリリース）