調査期間：2026-08-27 10:18 ~ 2026-08-28 10:18 北京時間 情報源：GitHub（org: flagos-ai 52 リポジトリ + commit search + PR/Release API）、Google News RSS（中英文複数クエリ、プロキシ経路正常）、HN Algolia、Tavily/web クロス検証（詳細は付録）

インデックス

    1. オープンソースプロジェクトの進展（GitHub 動向）
      • 1.1 Qwen4 スパースアテンションカーネル五バックエンドバッチ、Qwen3.8-Flash-Next リリースと同タイミング（08-27）
      • 1.2 Torch-FL：TileOPs オプションオペレータライブラリ統合、Apex オプティマイザのゼロコピービュー有効化（08-28）
      • 1.3 FlagCX：燧原 Enflame collective flow クローズドループ（08-27）
      • 1.4 FlagScale：Qwen3.6 LLM Backbone と重み変換サポート（08-27）
      • 1.5 vllm-plugin-FL：W8A8 推論が vLLM 0.24 に適合、main ライン CI 移行開始（08-27/08-28）
      • 1.6 build-infra：metax sgl-kernel wheel が CUDA 依存なしを実証、CANN 8.5.0 依存、verl 接続計画の詳細化（08-27/08-28）
      • 1.7 コンパイラスタック：flir Common IR POC、FlagTree TLE 全バックエンドプリミティブ（08-27）
      • 1.8 その他リポジトリの動向（FlagGems、FlagSparse、docs）（08-27/08-28）
    1. ニュース報道とエコシステム
      • 2.1 トップニュース：摩尔線程が智源 FlagOS と共同で Qwen3.8-Flash-Next Day-0 対応を完了（08-26/08-27）
      • 2.2 コンポーネント級キーワード：九日ぶりにゼロヒットを打破
      • 2.3 エコシステム側の観察と除外項目
    1. メンバー企業の深掘り
      • 3.1 摩尔線程：Day-0 デュアルトラック対応と sgl-kernel の CUDA 非依存実証（08-26/08-27）
      • 3.2 燧原：FlagCX 通信フローのクローズドループ（08-27）
      • 3.3 海光/昇腾/天数/沐曦：Qwen4 カーネル五バックエンドカバレッジ（08-27）
      • 3.4 AI Agent による FlagOS 開発参画：Claude Code がコミットした Apex 修正（08-28）
    1. まとめ
  • 付録：完全な情報源リスト

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

期間総覧：org 内 52 リポジトリのうち 12 が期間内にプッシュあり。commit search は期間内コミット 42 件をヒット（build-infra 12、FlagGems-vllm 5、FlagSparse 4、Torch-FL 4、FlagGems 3、docs 2、vllm-plugin-FL 2、FlagTree 2、flir/FlagScale/FlagCX 各 1）。本期間の主線：一、Qwen4 アーキテクチャ向けオペレータの備蓄——FlagGems-vllm が単日で 5 つの Qwen4 スパースアテンション（QSA）カーネルをマージし、五社のチップバックエンドをカバー。アリババが Qwen4 アーキテクチャベースの Qwen3.8-Flash-Next をリリース（8/26）したのと同タイミング；二、フレームワーク層のアーキテクチャ突破——Torch-FL が TileOPs オペレータライブラリを統合（60 件のコード生成ルート、「アダプタは手書き必須」という旧結論を是正）、Apex オプティマイザが flagos デバイスで有効化；三、メンバー企業の縦深——燧原 FlagCX 通信フローのクローズドループ、build-infra が摩尔線程 MACA ツールチェーンで sgl-kernel をコンパイルし CUDA 非依存を証明；四、ニュース側では九日ぶりにコンポーネント級ゼロヒットを打破：摩尔線程が FlagOS と共同で Qwen3.8-Flash-Next Day-0 対応を完了。

1.1 Qwen4 スパースアテンションカーネル五バックエンドバッチ、Qwen3.8-Flash-Next リリースと同タイミング（08-27）

来源：FlagGems-vllm #715、#716、#717、#718、#719

  • 8/27 13:52～23:06、liuhycs が 5 つの Qwen4 カーネル PR を連続マージ：qwen4_compress_norm_mrope_store_groups（圧縮正規化と mrope グループストア）、qwen4_qsa_mqa_paged_dot（QSA MQA ページ化ドット積）、qwen4_ple_state_scatter（PLE 状態スキャッタ）、qwen4_hc_inject_combine（HC 注入結合）、qwen4_store_qsa_kv_rows（QSA KV 行ストア）。
  • 各カーネルはいずれも昇騰910、海光 DCU、天数智芯 Iluvatar、沐曦 MetaX、摩尔線程 Mthreads の 5 バックエンド向けベンダー最適化版 Triton 実装を提供（例：昇騰 2D grid 単一 warp、海光 3D grid 4 warp など、チップのメモリ特性に応じてチューニング）。
  • 8/26 にマージされた Qwen4 自社開発 Triton カーネルおよびベンダーベースライン（#713/#681）と合わせ、「自社開発 + ベンダー最適化」の二本柱を形成。

解読：Qwen4 アーキテクチャの中核的特徴は疎注意（QSA）である——アリババ公式の予告では Qwen3.8-Flash-Next が Qwen4 アーキテクチャに基づく（ModelScope ページに明記）。FlagOS はモデルが正式に利用可能になる前に、QSA 全链路カーネル（KV ストア、圧縮正規化、ページドット積）の 5 バックエンド対応を完了しており、「モデル未到来、オペレータ先行」の Day-0 前哨備蓄である。2.1 のトップ記事と合わせると、Qwen4 アーキテクチャの FlagOS 対応チェーン（カーネル→推論→デプロイ）はほぼ整備済みである。

1.2 Torch-FL：TileOPs オプションオペレータライブラリ統合、Apex オプティマイザゼロコピービュー有効化（08-28）

情報源：Torch-FL #44、#216、#212、#211

  • #44（8/28 09:23 マージ、lvyufeng）：TileOPs をオプションの SM90 専用オペレータライブラリとして統合し、TileOPs manifest によるコード生成（手書きではなく）で aten に整列した 60 件のルーティングをカバー。重要な結論の修正：従来の調査では「アダプタはオペレータごとに手書きが必要」とされていたが、実際には構築パラメータが aten 呼び出し点から機械的に導出可能であることが判明（102 件の整列のうち 68 件が自動導出可能）。
  • #216（8/28 09:22 マージ、lvyufeng）：Apex の MultiTensorApply エントリで flagos テンソルをゼロコピー CUDA ビューに変換することで、NVIDIA Apex FusedAdam/SGD/LAMB オプティマイザを有効化。特筆すべきは、この PR が Claude Code CLI（Claude Opus 5）により作成され、人間がレビューしたことである（3.4 参照）。
  • #212/#211（8/27 13:10～14:47）：PrivateUse1 上の aten::narrow の autograd を復元；各バックエンドの copy パスは lazy conj/neg の数学的ビットに準拠。

解読：Torch-FL の路線は「オペレータごとの対応」から「manifest によるコード生成 + 上流オペレータライブラリの再利用」へ転換し、新バックエンドのオペレータカバレッジコストを大幅に低減する。Apex オプティマイザの有効化により、flagos デバイスの学習側におけるオプティマイザエコシステムの空白が埋まった。

1.3 FlagCX：燧原 Enflame collective flow クローズドループ（08-27）

情報源：FlagCX #554（8/27 11:05 マージ、lvyufeng）

  • #546 で導入された FLAGCX_TORCH_BACKEND=flagos 燧原 GCU パスを完成：FlagOS 中間テンソル割り当てと list-collective の flatten/unflatten コピーがすべて FlagCX を経由し、かつ torch_gcu を import/link しないことで、PAL（ポータブル抽象化レイヤ）アーキテクチャの純粋性を維持。

解読：燧原の FlagOS における通信層対応は「骨組み」から「クローズドループ」へと進んだ。昨日の FlagCX openEuler 24.03 RPM ビルドマトリクス、海光 DCU 対応と合わせ、FlagCX のマルチベンダー collective カバレッジ（昇騰/燧原/海光/英偉達）は拡大を続けている。

1.4 FlagScale：Qwen3.6 LLM Backbone と重み変換サポート（08-27）

情報源：FlagScale #1273（8/27 14:24 マージ、lxd-cumt）

  • Qwen3.6 LLM Backbone（vit モジュール無効化）のサポートを新規追加し、checkpoint 変換ロジックを整備。

解読：FlagScale の訓練側は引き続き Qwen シリーズのイテレーションに追随（従来は Qwen3.5/3.8 シリーズ）。Qwen3.6 backbone のマージにより、マルチチップ訓練に統一エントリを提供。

1.5 vllm-plugin-FL：W8A8 推論が vLLM 0.24 に対応、main ライン CI 移行を開始（08-27/08-28）

情報源：vllm-plugin-FL #336（8/27 21:26 マージ）、#415、#414、#412

  • #336（rdzhu225）：compressed-tensors の W8A8 推論を vLLM 0.24 プラグインラインに適応——v0.3.0-dev 上で直接再構築（#335 の 0.20.2 向け実装を置換）：vLLM 0.24 ネイティブの INT8 scaled-mm 候補を再利用し、per-token INT8 MoE を vLLM の functional Triton experts パスへルーティング。
  • オープン PR の新動向：#415（8/28）で CI 関連コードを release/0.2 から main へ移行——0.2 メンテナンスラインが収束を開始し、リソースを main/v0.3.0 に集中；#414 vLLM 0.24 バッチ MTP xGrammar masks の性能最適化；#412 摩尔線程 GDN packed decode launch のチューニング。

解読：v0.3.0 は依然 rc 段階（rc0 は 8/24 リリース）だが、W8A8 量子化適応や CI 移行などのマージはいずれも v0.3.0 正式版の接近を示す；低ビット（W4A16/W8A8）の二重精度パスは main ラインで並行して進行。

1.6 build-infra：metax sgl-kernel wheel が CUDA 非依存を実証、CANN 8.5.0 依存、verl 導入計画を細分化（08-27/08-28）

情報源：build-infra #598、#597、#596、#595、#594、#593、#591

  • #598（8/28 07:57 マージ、tengqm）：摩尔線程の mxcc（MACA）ツールチェーンで sgl-kernel の 10 オペレータサブセットをコンパイルし、sgl_kernel 0.4.1+flagos（cp312, linux_x86_64）としてパッケージ化——sgl-kernel が CUDA に依存しないことを実証；sglang 0.5.10 は metax 上で flagtree / vendor triton の両コンパイルパスを経て serve sampling E2E に合格。
  • #597（8/27 21:38）：昇騰 CANN 8.5.0 ランタイム依存（decorator/attrs/psutil）を補完——昇騰検証ラインが CANN 8.5 に追随。
  • #596（8/27 21:32）：フルスタックで numpy==1.26.4 を固定（全バックエンド）——numpy 2.x の互換性ドリフトを排除。
  • verl 計画の細分化（#591/#593/#594/#595）：sglang 調査ドキュメントを自己完結型に変更；verl app image 計画は Path B が vllm 0.20.2 fork ブランチラインを採用することを明確化、TE-FL wheel の実現可能性を記録、FlagCX を非ハード依存として注記、verl は依存とともにインストールし megatron-core ベース wheel で着地。

解説：build-infra 今サイクルのテーマは「検証とパッケージングを再現可能なエンジニアリングにする」である。sgl-kernel の metax コンパイル実証は、推論カーネル層がもはや CUDA に縛られないことを意味し、「統一スタック・マルチチップ」というナラティブのパッケージング側における直接的な証拠である。verl の統合（RL フレームワーク）も引き続き推進され、フレームワークの版図はまもなく補完される。

1.7 コンパイラスタック：flir Common IR POC、FlagTree TLE 全バックエンドプリミティブ（08-27）

情報源：flir #68、community #95、FlagTree #1054、#1053

  • flir #68（8/27 16:38 マージ、zhongsanming）：[KMCompiler][TLE] Common IR POC（Triton 3.5）——TTIR を補完する新しい Common IR を導入し、オペレータ層により低レベルの抽象を公開することでさらなる最適化機会を解放する。環境要件は CANN 9.1.0+、昇騰 910B/910C。関連する community #95 FEP(sig-compiler)：Common IR は統一 IR（DSA/GPGPU）の入力受け取り層として、TLE のデータ表現と pipeline 制御の抽象を強化する。
  • FlagTree #1054（8/27 20:43）：[TLE] 各バックエンドに supported TLE primitives リストを追加；#1053（8/27 14:11）[XPU] Discrete offset チェーンのラップアラウンド問題を修正。

解説：FlagOS コンパイラスタック（FlagTree/flir/KMCompiler）は「IR 抽象層設計」段階に入った——Common IR 提案は DSA（専用アクセラレータ）と GPGPU の統一コンパイルに向けた前瞻的な設計であり、TLE プリミティブリストの全バックエンド化はコンパイラフロントエンドの一貫性を高める。

1.8 その他リポジトリの動向（08-27/08-28）

  • FlagGems：#5800（8/28 10:11 マージ、tspyc072）conj_physical_ オペレータを追加（複素テンソル contiguous-view Triton カーネル、実テンソルは発射不要）；#5787 CI rule-check 第一期・第二期（gavin0x01）；#5777 dead ATen 登録と非標準登録名を整理。オープン PR ラッシュ（8/27-28 新規 15+）：KernelGen 批量 Nvidia オペレータ（ldeexp/masked_select_backward/cudnn_rnn/_thnn_fused*cell シリーズ/_fused_adagrad/histogramdd など 9 個）、海光 FlashAttention 前向・後向修正（#5822）、崑崙芯 slice_scatter 越界修正（#5816）、摩尔線程 channel_shuffle block-copy 最適化（#5814）、QC FP8 W8A8 FlashAttention-2（#5817）、KMCompiler 昇騰 linalg_solve_triangular（#5821）。
  • FlagSparse：#48（8/27 18:50 マージ、zyq1105331849）spmm BELL フォーマットと spsv SELL フォーマットを更新——疎行列カーネルを継続的に補完。
  • docs：#476/#477（8/27 10:33 マージ、github-actions ボット）ModelScope モデル README（17 ファイル追加）とモデルリストを同期——FlagRelease モデルリポジトリは新規対応に伴い継続的に更新。

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

2.1 トップニュース：摩尔線程が智源 FlagOS と連携し Qwen3.8-Flash-Next Day-0 対応を完了（08-26/08-27）

情報源：新浪財経転載北京商報（8/27）、東方財富（8/27 収録、北京商報 8/26 21:57 発稿）、ModelScope Qwen3.8-Flash-Next 公式ページ

  • アリババ千問は先日、マルチモーダル MoE モデル Qwen3.8-Flash-Next をオープンソース化した（Qwen4 アーキテクチャに基づき、新型のスパースアテンションを含む。公式は 8/26 15:00 UTC のリリースを予告）。
  • 摩尔線程は 8/27 に文章を発表：全エコシステム互換能力に依拠し、Triton に基づいて MTT S5000 上でこのモデルの Day-0 独立対応を迅速に完了した。同時に衆智 FlagOS コミュニティと連合して Day-0 対応、精度アライメントとデプロイ検証を同期完了し、初批として BF16 精度版を提供、すでに魔搭（ModelScope）及び HuggingFace にオープンソース化しており、開発者はすぐに使えるソリューションを直接取得できる。
  • ModelScope の FlagRelease（FlagOS 公式）アカウント下にはすでに Qwen3.8 シリーズのマルチチップ量子化イメージ（例：Qwen3.8-2.4T-A95B-INT8-metax-FlagOS）があり、今回の BF16 版もこのリリースチャネルを引き続き使用する。

解読：これは FlagOS 側の連続 2 回目の Qwen3.8 シリーズ Day-0である（8/13 は Qwen3.8-2.4T 九チップ Day0、8/17 は Qwen3.8-27B 十一チップ）。今回は摩尔線程が主導し、「独立対応 + 連合 FlagOS」の双軌形式で提示された。「モデルリリース当日にマルチチップ対応を完了する」というリズムはすでに特例から常態へと変わった。Qwen4 アーキテクチャの新特性（スパースアテンション）と、これまでの FlagGems-vllm の Qwen4 カーネル備蓄（1.1）は互いに裏付け合っている——対応速度の背後には数ヶ月前からのカーネルエンジニアリングがある。

2.2 コンポーネント級キーワード：九日ぶりに初のゼロヒット脱却

gnews の中国語・英語複数組クエリ（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/KernelGen/FlagOS-Robo/FlagQuantum/FlagPrism when:7d/14d）において、FlagOS キーワードは 8/27 に 1 件ヒットした（2.1 トップニュース、北京商報/新浪財経/東方財富による転載）。これにより、それ以前の連続八日間のコンポーネント級ゼロヒット記録を打破した。その他のコンポーネント名（FlagGems/FlagScale/FlagTree など）は依然としてゼロヒットである。HN Algolia（FlagOS/FlagGems）は無関係な誤マッチのみ。Tavily のクロス検証により、このニュースが調査期間内で唯一のコンポーネント級報道であることが確認された。ニュース側の「GitHub 動態を主とし、メディア露出は稀疏」という全体的な格局は変わっていないが、モデル Day-0 対応類ニュースの伝播チェーン（ベンダー公式→財経メディア→財経プラットフォーム）はすでに安定的に形成されている。

2.3 エコシステム側の観察と除外項目

  • 智源コミュニティ 8/26：『中国 AI 突破「造芯方法論」！Agent 軍団がチップ設計全流程を接管』——AI Agent をチップ設計に用いる方法論の報道であり、FlagOS コンポーネントの動態ではなく、また調査期間内でもないため、本文には含めない（3.4 の Claude Code 開発 PR と興味深い呼応シグナルを形成している）。
  • 智源コミュニティ 8/28 08:30（北京時間）：智譜 GLM-5.3-Flash リリース（「神秘牛来モデル」の正体公開）——国産モデル側の動態であり、FlagOS の対応報道はまだ見られず、観察項目に追加。
  • 智源コミュニティ 8/22：FlagEval-Robo 正式リリース（「シミュレーション＋実機」双軌評価、具身知能に真の能力基準を確立）——調査期間外の背景項目。智源の具身評価ツールチェーンと FlagOS-Robo の方向性は呼応しており、今月のレポートで追跡してきた具身エンドツーエンドデータパイプラインの方向性には引き続きエコシステムシグナルがある。
  • その他の智源コミュニティ記事（HuggingFace 買収噂、Opus 5.1、OpenAI 自研チップなど）はすべて業界マクロ動態であり、除外する。

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

3.1 摩尔線程：Day-0 双軌対応と sgl-kernel の CUDA レス実証（08-26/08-27）

情報源：新浪財経、build-infra #598、FlagGems-vllm #715/#719

  • 摩尔線程は調査期間内に三線並行で前進した：ニュース側では Qwen3.8-Flash-Next の MTT S5000 Day-0 独立対応＋連合 FlagOS 同期対応（BF16 オープンソース魔搭/HF）を主導。オペレータ側では FlagGems-vllm に Qwen4 QSA シリーズカーネルの mthreads 最適化実装をコミット。パッケージ側では mxcc/MACA ツールチェーンで sgl-kernel 10 オペレータサブセットをコンパイルし、sglang 0.5.10 の双コンパイルパス E2E を完了、推論カーネルが CUDA から離脱可能であることを実証した。
  • 昨日のレポート（Megatron 双 MUSA 版全链路検証がグリーンに転じた）と連携：摩尔線程の FlagOS への参加は、検証、オペレータ、カーネルパッケージ、モデル対応の四層にまたがっている。

3.2 燧原：FlagCX 通信フロー閉ループ（08-27）

情報源：FlagCX #554

  • 燧原 GCU の FlagCX collective パス（FLAGCX_TORCH_BACKEND=flagos）がクローズドループを完成：中間テンソル割り当てと list-collective コピーはすべて FlagCX 経由でルーティングされ、torch_gcu 依存を導入しない。燧原は昨日の vllm-plugin-FL 昇騰/寒武紀マルチバックエンド保守への参加に続き、通信層の対応がさらに前進した。

3.3 海光/昇騰/天数/沐曦：Qwen4 カーネル五バックエンドカバレッジ（08-27）

情報源：FlagGems-vllm #715-#719、Torch-FL #212、build-infra #597

  • FlagGems-vllm の 5 つの Qwen4 カーネルはすべて昇騰910、海光 DCU、天数 Iluvatar、沐曦 MetaX、摩尔線程の五バックエンド（ベンダー最適化版）をカバーする。うち海光には別途 FlagGems オープン PR の FlashAttention 修正（#5822）がある。昇騰側では build-infra が CANN 8.5.0 ランタイム依存を補完し、検証ラインが新バージョンソフトウェアスタックに追随する。複数ベンダーが「同日同一バッチのカーネル」方式でマージすることは、Day-0 能力の基盤となるエンジニアリング保障である。

3.4 AI Agent による FlagOS 開発参加：Claude Code がコミットした Apex 修正（08-28）

情報源：Torch-FL #216

  • Torch-FL #216（Apex FusedAdam/SGD/LAMB 有効化）の PR 説明には、Claude Code CLI（Claude Opus 5、1M コンテキスト）が作成し、@lvyufeng が人手でレビューしたと明記されており、「flagos デバイス上での Apex の失敗を調査 → MultiTensorApply エントリポイントを特定 → ゼロコピー CUDA ビュー方案 → 修正」という全プロセスを AI Agent が完了した。
  • 解釈：これは FlagOS リポジトリにおいて、AI Agent が全程作成したと明示的に注記された初のマージ PR である（従来 AiMOS などのリポジトリにボットによるコミット慣行はあったが、これは LLM プログラミング Agent である）。智源コミュニティの 8/26「Agent 軍団がチップ設計を引き継ぐ」報道と相互に裏付け合う——オープンソースシステムソフトウェアスタック開発は、AI プログラミングツールの早期高価値シナリオになりつつある。このモデルは FlagOS の「統一スタックによるマルチチップ対応の人件費削減」というナラティブに対する追加のレバレッジである。

4. まとめ

調査期間の主線：1、Qwen4 アーキテクチャ備蓄と Day-0 対応が同頻共振——FlagGems-vllm が単日で 5 つの Qwen4 疎注意カーネル（QSA KV ストレージ/圧縮正規化/page ドット積など）をマージし、昇騰/海光/天数/沐曦/摩尔線程の五バックエンドをカバー。同日、摩尔線程が FlagOS と共同で Qwen3.8-Flash-Next（Qwen4 アーキテクチャベース）の Day-0 対応完了を発表、BF16 版を魔搭と HuggingFace にオープンソース化し、コンポーネント級ニュースの八日間ゼロヒットを打破した。2、フレームワーク層アーキテクチャアップグレード——Torch-FL が TileOPs コード生成オペレータライブラリ（60 条の aten ルーティング）を統合し Apex 最適化器を有効化、FlagScale に Qwen3.6 backbone を新規追加。3、「CUDA 依存なし」の実証——build-infra が摩尔線程 MACA ツールチェーンで sgl-kernel をコンパイルし、デュアルコンパイルパスが E2E で通過、推論カーネル層の CUDA バインド除去に再現可能な証拠を取得。4、会員単位の縦深——燧原 FlagCX 通信フローのクローズドループ、昇騰 CANN 8.5.0 追随、vllm-plugin-FL 0.2 保守ラインの収束と main 移行。5、AI Agent 開発モデルの FlagOS への出現——Claude Code が全程作成した Apex 修正 PR がマージ。

次の観察点：vllm-plugin-FL v0.3.0 正式版（rc0 が出ており、W8A8 0.24 対応と CI 移行は main ラインにマージ済み）；Qwen3.8-Flash-Next の BF16 イメージの魔搭 FlagRelease アカウントでの落地とマルチチップ拡張；Qwen4 QSA カーネルの vllm 側での開箱検証；FlagScale Qwen3.6 訓練検証；flir Common IR の SIG 推進（community #95）；FlagGems 5.3.5 全バックエンド再検収の収尾；OASIS-AI 募集締切 8/31。

限界に関する説明：コミット数とマージ時間は commit search および repos/commits API に基づく（検索インデックスはやや遅延する可能性がある。flagtree-cpu の調査期間内のプッシュは PR ブランチへのプッシュであり、メインブランチへの新規マージはないことを検証済み）。Qwen3.8-Flash-Next の報道された公開時間は北京商報 8/26 21:57、gnews の収録は 8/27 08:08 であり、調査期間の起点（8/27 10:18）の_edge_に位置し、昨日のレポート収集時にはまだ収録されていなかったため、今回は調査期間内のニュースとして収録した。「Claude Code 執筆」は PR 説明の自己申告に基づく。ModelScope FlagRelease アカウントの BF16 ミラーリンクは直接検証していない（魔搭の検索ページでは INT8 などの過去のミラーのみ確認できる）ため、公式報道の表現に準拠する。

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

番号 イベント 情報源リンク
1 摩尔線程が智源FlagOSと共同でQwen3.8-Flash-Nextの対応を完了（北京商報/新浪財経） https://finance.sina.com.cn/jjxw/2026-08-27/doc-inipuqhs0655624.shtml
2 同一テーマの報道（東方財富） https://wap.eastmoney.com/a/202608273856909629.html
3 Qwen3.8-Flash-Next 公式ページ（ModelScope、Qwen4アーキテクチャ説明） https://modelscope.cn/models/Qwen/Qwen3.8-Flash-Next
4 FlagGems-vllm Qwen4 compress_norm_mrope_store_groups（#719） https://github.com/flagos-ai/FlagGems-vllm/pull/719
5 FlagGems-vllm Qwen4 qsa_mqa_paged_dot（#718） https://github.com/flagos-ai/FlagGems-vllm/pull/718
6 FlagGems-vllm Qwen4 ple_state_scatter（#717） https://github.com/flagos-ai/FlagGems-vllm/pull/717
7 FlagGems-vllm Qwen4 hc_inject_combine（#716） https://github.com/flagos-ai/FlagGems-vllm/pull/716
8 FlagGems-vllm Qwen4 store_qsa_kv_rows（#715） https://github.com/flagos-ai/FlagGems-vllm/pull/715
9 Torch-FL TileOPs 統合（#44） https://github.com/flagos-ai/Torch-FL/pull/44
10 Torch-FL Apex オプティマイザのゼロコピービュー（#216、Claude Code による作成） https://github.com/flagos-ai/Torch-FL/pull/216
11 Torch-FL aten::narrow autograd 復元（#212） https://github.com/flagos-ai/Torch-FL/pull/212
12 FlagCX 燧原 Enflame collective flow（#554） https://github.com/flagos-ai/FlagCX/pull/554
13 FlagScale Qwen36 backbone + CKPT 変換（#1273） https://github.com/flagos-ai/FlagScale/pull/1273
14 vllm-plugin-FL W8A8 が vLLM 0.24 に対応（#336） https://github.com/flagos-ai/vllm-plugin-FL/pull/336
15 vllm-plugin-FL CI を main へ移行（#415） https://github.com/flagos-ai/vllm-plugin-FL/pull/415
16 build-infra metax sgl-kernel wheel（#598） https://github.com/flagos-ai/build-infra/pull/598
17 build-infra cann8.5.0 runtime deps（#597） https://github.com/flagos-ai/build-infra/pull/597
18 build-infra numpy 1.26.4 フルスタック固定（#596） https://github.com/flagos-ai/build-infra/pull/596
19 build-infra verl Path B 計画（#595） https://github.com/flagos-ai/build-infra/pull/595
20 flir KMCompiler Common IR POC（#68） https://github.com/flagos-ai/flir/pull/68
21 community FEP sig-compiler Common IR（#95） https://github.com/flagos-ai/community/pull/95
22 FlagTree TLE 全バックエンド primitives（#1054） https:/
/github.com/flagos-ai/FlagTree/pull/1054      
  23 FlagSparse spmm/sp sv 更新（#48） https://github.com/flagos-ai/FlagSparse/pull/48
  24 FlagGems conj_physical_ オペレータ（#5800） https://github.com/flagos-ai/FlagGems/pull/5800
  25 FlagGems CI rule-check 一/二期（#5787） https://github.com/flagos-ai/FlagGems/pull/5787
  26 docs ModelScope モデルリスト同期（#476/#477） https://github.com/flagos-ai/docs/pull/477
  27 org repos 総覧（52 リポジトリ、12 リポジトリが調査期間内に活発） https://api.github.com/orgs/flagos-ai/repos?per_page=100&sort=updated
  28 commit search（調査期間内 42 件のユニークコミット） https://api.github.com/search/commits?q=org:flagos-ai+committer-date:%3E2026-08-27T02:18:00Z
  29 gnews コンポーネント単位クエリ（FlagOS 1 件ヒット、その他はゼロヒット） https://news.google.com/rss/search?q=FlagOS+when%3A7d&hl=zh-CN&gl=CN&ceid=CN%3Azh-Hans
  30 HN Algolia（無関係の誤マッチ） https://hn.algolia.com/api/v1/search_by_date?query=FlagOS
  31 FlagEval-Robo リリース（智源コミュニティ 8/22、背景項目） https://hub.baai.ac.cn
  32 GLM-5.3-Flash リリース（智源コミュニティ 8/28、観察項目） https://hub.baai.ac.cn