調査期間：2026-10-19 06:00 ～ 2026-10-20 06:00（北京時間、24時間；火曜朝報、期間は前回デイリーレポートの締め切り時点から継続し、大会期間中の内容は含まない）。

情報源：GitHub（org: flagos-ai 61リポジトリ全量核查、コミット検索 93件、マージ済み PR 88件と審査中 PR 180件の検索、16の活発なリポジトリの Release とタグ核查、org イベントストリーム 100件とブランチレベルのフォールバック）、Google News RSS（24組の中英語検索語、プロキシ経由）、HN Algolia（8組）、中華網と存儲在線の技術記事、CSDN と智源コミュニティのチャネル核查（詳細は付録情報源リスト）。

本期インデックス

  • 今日の注目：大会後最初の完全な工程日——93件のコミット、88件のマージ、build-infra が昇騰四輪子、清微と曦望を 22.04 自己完結 builder に統一（glibc の下限を 2.38 から 2.35 へ引き下げ）；FlagQuantum が 405ファイルをマージし 159の新規公開名を確立し M0 ロードマップを策定；FlagBLAS が海光 gfx936 六精度 GEMM を補完；FlagDNN が master に直接プッシュし天数 iluvatar 等価性能ベースラインを補完（10-19）
    1. オープンソースプロジェクトの進展（GitHub 動向）
      • 1.1 組織のリズム：16リポジトリのプッシュ、93件のコミット、88件のマージ；glibc の下限引き下げが当日の主線に（10-19）
      • 1.2 build-infra：昇騰四輪子を 24.04 ランタイムから 22.04 自己完結 builder へ移行、清微と曦望が同日に補完（10-19）
      • 1.3 FlagQuantum：405ファイルをマージし量子スタックを拡容、M0 から M4 のロードマップを確立（10-19）
      • 1.4 FlagGems：KernelGen スパースファミリをバッチ審査中、昆仑芯 XPU3 アテンションファミリと昇騰 mm 分派が並行（10-19 ～ 10-20）
      • 1.5 FlagBLAS：海光 gfx936 六精度 GEMM をマージ、dgemm は FlagTree fp64 MMAC に依存（10-19）
      • 1.6 FlagTree：燧原 GCU300 ベースラインと AMD RDNA 降級経路、昇騰 3.5 py312 納品（10-19）
      • 1.7 推論と訓練スタック：曦望と燧原のグラフモード、HY4 H100 接続、昇騰 vLLM 0.28 アップグレード（10-19）
      • 1.8 FlagDNN / FlagTrain / FlagSparse / Torch-FL：天数等価性能、摩尔線程バックエンド、MUSA 最適化（10-19）
    1. 報道とエコシステム
      • 2.1 大会後初の詳細技術記事：中華網が FlagOS 2.2 フルスタック分解を掲載、七つの量子化事例を補足（10-19）
      • 2.2 報道の拡散とチャネル核查：存儲在線の講演全文は 10-18 の旧稿の遅延インデックス、CSDN と智源コミュニティに新規なし（10-19 ～ 10-20）
    1. メンバー企業の深掘り
      • 3.1 海光：FlagBLAS 六精度 GEMM と L1 サポートが同時にリポジトリへ（10-19）
      • 3.2 天数智芯：FlagDNN 等価性能ベースラインを master に直接プッシュ、Torch-FL が独立ランタイムを分離（10-19）
      • 3.3 清微と曦望：二つのバックエンドが同日 FlagCX 22.04 builder に参加（10-19）
      • 3.4 燧原：GCU300 ベースライン、vLLM ベンチマークワークフローと builder アサーション修正（10-19）
      • 3.5 摩尔線程、昇騰、達摩院玄鉄：MUSA オペレータ線、CANN 9.0 ベースライン、T-Head GRU デッドロック修正（10-19）
    1. まとめとトレンド観察

今日の注目：大会後最初の工程日、納品面の統一が新機能を上回る（10-19）

日付：2026-10-19　出典：build-infra PR #1414 · FlagQuantum PR #635 · FlagBLAS PR #151 · FlagDNN commits（詳細は付録）

  • リズム面：24時間の調査期間内に16のリポジトリでプッシュがあり、93件のコミット、88件のマージ、180件の審査中PRが更新された。マージ量は前回の3日間調査期間の1日平均水準（約46件/日）を上回り、コミット時間は07:00から23:00に集中し、ピークは14:00から17:00にあり、典型的な平日のリズムであり、カンファレンス期間中の集中的な大量放出は見られなかった。
  • 主线は「デリバリー面の統一」であり新機能ではない：build-infraの16件のコミットはすべて成果物チャネルを巡るもので、昇騰の4つのホイールを24.04ランタイムイメージから独立したubuntu:22.04の自己完結型builderへ移行し（PR #1414）、同日に曦望（PR #1418）と清微（PR #1422）にも同仕様のbuilderを追加した。原因は24.04イメージ内でビルドされたlibflagcx.so / _C*.soがGLIBC_2.38にリンクされ、実際の22.04物理マシン上で直接中止されるためである。22.04 builderに変更後、glibcの下限は2.35に下がり、他のベンダー行と揃った。
  • 量子スタックは当日最大の単一マージ：FlagQuantum PR #635が405ファイル、+114463/−3983の規模でマージされ、159の公開名を新規追加し、アルゴリズム（45→148）、量子誤り訂正（84→108）、リモート呼び出し（20→32）、可観測量（12→20）、コンパイラ（12→17）をカバーし、新たにflagquantum.operatorsパッケージを開設した。機能登録表は68項目から97項目に増加し、Stable Coreの41のエクスポートは変更されていない。同日PR #637でM0からM4のロードマップを確立し、超伝導、中性原子、イオントラップ、光子、トポロジーの5種類のハードウェアを同一のCore IRとコンパイラ制約下に組み入れた。
  • 海光がBLAS主幹を補完：FlagBLAS PR #151がgfx936の6種類の精度GEMM（sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm、+7060/−127）をマージし、うちdgemmはfp64 MMACドット積カーネルを経由し、FlagTreeのfp64 MMACサポートに依存する。PR #149のHygon L1サポートと重なり、海光チャネルはオペレータ層から基礎線形代数層へと延伸した。
  • 天数側はmasterへ直接プッシュする性能ベースライン：FlagDNNの当日の4件のコミットはすべて直接masterに着地し（PRフローなし）、内容はiluvatarバックエンドの等価性能ベースライン（equivalent_baseline.cppなど、+8157）とそれに続く2回の修正であり、同時にascendバックエンドの検証ディレクトリを整理した（−7047）。

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

1.1 組織リズム：16リポジトリのプッシュ、93件のコミット、88件のマージ（10-19）

日付：2026-10-19　情報源：flagos-ai 組織リポジトリ · コミット検索 · マージPR検索

  • リポジトリ面：61 リポジトリのうち 16 リポジトリが調査期間内にプッシュがあり、コミット数順に FlagGems 23、FlagQuantum 23、build-infra 16、FlagBLAS 9、FlagTree 5、FlagDNN 4、FlagGems-vllm 3、vllm-plugin-FL 3、Torch-FL 2、FlagSparse 2、FlagCX 1、FlagTrain 1、FlagAttention 1。
  • マージ面：88 件のマージがあり、内訳は FlagGems 36、build-infra 16、FlagQuantum 9、FlagTree 8、vllm-plugin-FL 6、FlagBLAS 3、FlagGems-vllm 3、Torch-FL 2、FlagCX / FlagTrain / FlagAttention / FlagSparse / TransformerEngine-FL 各 1。FlagGems と build-infra の合計がコミット数の 42%、マージ数の 59% を占める。
  • レビュー中面：調査期間内に更新のあった open PR は 180 件（API が返す先頭 100 件をリポジトリ別集計に使用）、上位は FlagGems 63、FlagGems-vllm 12、vllm-plugin-FL 5、Torch-FL 4、FlagCX 3、FlagTree 3、FlagGems-sglang 3。うちタイトルに KernelGen を含むもの 28 件、昆仑芯を含むもの 30 件、sparse を含むもの 8 件で、この 3 つのキューが現在の消化待ちの主体を構成している。
  • ブランチ単位のフォールバック：docs のプッシュは update/modelscope-docs-20261019-175239 ブランチに着地（main の最新は依然 10-03）；Trident のプッシュは PR #4「Monad 中間層」に対応（master の最新は 10-13）；FlagCV は 10-19 未明のスケルトン合入以降、当日の新規動作なし；FlagFFT、FlagScale、Megatron-LM-FL、FlagPrism、FlagAudio、FlagOps の 7 リポジトリは調査期間内にプッシュゼロ。
  • 判断：大会の 2 日間（10-17 から 10-18）を経て、組織に「リリース後の停滞」は見られず、むしろ生産能力を即座に成果物とベースラインへ戻している。当日は新バージョンのリリース（調査期間内に Release なし）も、新リポジトリの設立もなく、「バージョンなし、デリバリー重視」の一日であった。

1.2 build-infra：昇騰四輪駆動の 22.04 セルフコンテインド builder への移行、清微と曦望が同日に補完（10-19）

日付：2026-10-19　情報源：PR #1414 · PR #1418 · PR #1422 · PR #1417 · base ディレクトリ

  • 核心問題：昇騰の4つのホイールは元々 24.04 ランタイムイメージ内でビルドされており、生成された libflagcx.so と _C*.so は GLIBC_2.38 にリンクされ、bundle の 22.04 物理マシン上で直接 abort する。PR #1414 は各行ごとに独立した ubuntu:22.04 builder を設定し、他のベンダー行と同一チャネルを通し、glibc の下限を 2.35 に引き下げた。
  • 1つのレシピで4行をサービス：ascend.mk は -ltorch_npu -lascendcl -lhccl のみをリンクし、特定のチップとは無関係である。ただしツールチェーン自体はこれらのリンク時依存を含まず、libhccl.so と <hccl/hccl.h> はチップ ops パッケージに由来するため、レシピは同時に toolkit と ops パッケージをインストールする（nnal/ATB を含まない）。910b と 910c の差異は ops インストーラのチップトークン（builder.ops_product、910b と A3）を介して渡される。
  • 検証基準：SDK の下限は import torch_npu（CANN ツールチェーンライブラリを dlopen する）で証明し、import torch（この行では純粋な CPU）ではない。ASCEND_OPP_PATH、ASCEND_AICPU_PATH、TOOLCHAIN_HOME、LD_LIBRARY_PATH は set_env.sh から /etc/profile.d/vendor.sh に落とし込まれ、ホイールビルド時に source されたものと同一のファイルである。
  • 同日に2つの新バックエンドを补齐：曦望（PR #1418、sunrise wheel の 22.04 自己完結 builder、その後 PR #1420 で当該ホイールを 22.04-clean で再リリースしたことを記録）と清微（PR #1422、tsingmicro wheel の 22.04 自己完結 builder）。これにより base/ ディレクトリ下のベンダーマトリクスは nvidia（cuda12.8 / cuda13.3）、ascend（cann8.5.0 / cann9.0.0、910c を含む）、cambricon（neuware4.4.3 / 4.7.2）、enflame（tops1.9.10 / 1.10.6）、hygon（dtk26.04）、iluvatar（corex4.4.0 / 4.5.0）、metax（maca3.7.2.1 / 3.8.1.3）、sunrise（tangrt1.2.0）、tsingmicro（tsm260610）となり、計9ベンダーとなる。
  • FlagTree 側の3件：PR #1417 は燧原 builder を追加し検証ステップをデータドリブンに変更した。PR #1419 は「ビルド期に燧原バックエンドを断言する」記述を修正した。PR #1421 は燧原 toolkit の deb を builder イメージにプリセットし、ビルドごとのダウンロード依存を削減した。さらに PR #1410 は pybind11 ABI を実際に出力されたプラグインから読み戻すようにし、リテラルをハードコードしないようにした。PR #1413 は失敗した plan がビルドをスキップするのではなく、run 全体を直接失敗させるようにした。
  • 判断：この16件はいずれも機能開発ではなく、すべて「ローカルでビルドでき、ターゲット機で動作する」間の隙間を解消するものである。10-16 から 10-18 の6バックエンド 22.04 収束と合わせて見ると、FlagCX の成果物チャネルは「バックエンドごとにパッチを当てる」から「1行1バックエンド、同一の 22.04 レシピ」へと移行した。

1.3 FlagQuantum：405 ファイルを量子スタック拡張に合入、M0 ロードマップを確立（10-19）

日付：2026-10-19　情報源：PR #635 · PR #637 · PR #642 · リポジトリ

  • 規模：23 件のコミット、9 件のマージ。当日のコミット数で並列1位のリポジトリ。PR #635 は単一で405ファイル、+114463/−3983、新規公開名159件：アルゴリズムパッケージが45から148へ、量子誤り訂正が84から108へ、リモート呼び出しが20から32へ、可観測量が12から20へ、コンパイラが12から17へ、シミュレーションが8から11へ増加し、新たに flagquantum.operators パッケージ（4つのエクスポート）を開設。能力レジストリは68項目から97項目に増加、うち development_evidence は20から47に増加。
  • 境界規律：すべての新規名はサブパッケージの入口であり、Stable Core の flagquantum.__all__ は依然として41のエクスポートで、main とバイト単位で一致。PR 本文は「Stable Core への昇格は独立した提案経路を経る」と明記し、同時に3つの契約ファイル（コンパイラ pass 准入、多段 IR 内部インターフェース、real-time メッセージ）を新規追加。
  • ロードマップ：PR #637 は M0 から M4 までの段階的範囲、依存関係、受け入れ基準を確立し、既存の Core IR、コンパイラ、動力学ソルバー、ランタイム、PyTorch 統合の再利用を要求し、超伝導、中性原子、イオントラップ、光子、トポロジカルの5類のハードウェアをカバー。M1 は混合次元状態空間から着手する。同一 PR はさらに、収縮ガウス重なり積分の精度問題を修正（相殺に敏感な総和を math.fsum で処理するよう変更し、原始基底系列の回帰を1件追加）。
  • 動力学とコンパイラ：PR #639 は混合次元状態空間をサポート、PR #640 は明示的截断のボソンオペレータをサポート、PR #641 は静的オペレータ和の係数訓練をサポート、PR #642 は呼び出し側が名前で2つの最適化ポイントに独自 pass を注入できるようにする。他に10件余りのテストとドキュメントのコミットがあり、数値アサーションを固定リテラル比較ではなく「精度に基づく再現性比較」に変更。
  • 判断：量子スタックは「フレームワークの雛形」から「汎用量子計算フレームワーク」へと進みつつある——PR #635 が補うのはカバレッジ（誤り訂正、化学、リアルタイム呼び出し、超オペレータ）であり、PR #637 が補うのは境界と段階である。両者が同日にマージされたことは、M0 の起点が API を先に拡張することではなく、既存能力を明確に記述することにあることを意味する。

1.4 FlagGems：KernelGen スパース系の一括審査中、崑崙芯 XPU3 アテンション系と昇騰 mm ディスパッチが並行進行（10-19 ~ 10-20）

日付：2026-10-19 ~ 2026-10-20　情報源：PR #7260 · PR #7239 · PR #7203 · 審査中 PR リスト

  • マージ側：23 件のコミット、36 件のマージ。KernelGen ラインは引き続き ATen リストに従って補完し、疎行列とビューセマンティクスに進んだ：_adaptive_avg_pool3d（#7172）、fft_ifftshift（#7171）、ccol_indices_copy（#6775）、_coalesce（#7096）、_neg_view_copy（#7088）がマージされた。同時に PR #7260 で 185 個の Q4 オペレータテストスイートを一括移行した。
  • 審査中側：10-19 23:00 から 10-20 05:00 の間に約 20 件の KernelGen コミットが新規追加され、疎行列ファミリーに集中している——_sparse_mm（#7289）、_sparse_mm_reduce_impl（#7298）、_sparse_mm_reduce_impl_backward（#7303）、_sparse_addmm（#7277）、copy_sparse_to_sparse_（#7231）、resize_as_sparse_（#7255）、_convert_indices_from_coo_to_csr（#7297）、_convert_indices_from_csr_to_coo（#7296）、_indices（#7293）、ccol_indices（#7295）など。疎行列ファミリーが一気に展開されたことは、基幹の稠密オペレータがほぼ片付いたことを示している。
  • 昆仑芯：マージ側には XPU3 の conv1d/conv2d/conv_depthwise2d（#7109）、chunk_gated_delta_rule_fwd（#7104）、dropout と mhc_post の性能（#7113）、take_along_dim と te_rmsnorm_bwd（#7089）、softmax_out の tle.gpu 融合パス（#6897）、baddbmm/copy_ の失敗と tile_size 32768 のハング修正（#7245）がある。審査中側には 30 件があり、アテンションファミリー（#7275、順伝播ブロック分割、varlen KV 融合、逆伝播リファレンス）、lstm（#7105）、rnn_relu（#7110）、cholesky_solve（#7103）、linalg_lu_factor（#7273）を含む。
  • 昇騰と海光：昇騰の mm 形状ディスパッチと Triton tiling 最適化（#7239）、reference 契約と精度スキップ修正（#7286、#7287、#7253）、int_repr リファレンス適応（#7253）、海光の hygon_mv タイムアウト修正（#6584）。3 ラインはいずれも「まずテストを通し、それから性能を語る」順序である。
  • その他バックエンド：達摩院玄鉄バックエンドの GRU barrier デッドロック修正（#7203）と sparse QSA の 16 行最小 tile（#940、FlagGems-vllm）、摩尔線程 KMCompiler ラインの linear 重みを trans_b で WS SQMMA に送る（#7261）、rnn_tanh で musa を有効化（#7256）、PPU コンテナリソース上限を 3 リポジトリで同期復旧（#7254、#942、#101）。
  • ベンチマーク側：--base-data が外部 NVIDIA ベースライン比較をサポート（#7219）、metadata-only オペレータの計時エラー（#7283）、ネストテンソルと記述子のレポート問題（#7276）を修正し、古い reference デコレータを整理した（#7271）。当日 36 件のマージのうち約 4 分の 1 は計測とレポートの修正であり、これは「クロスチップ性能 +27.6%」といった対外的な数値に必要な再現性と直接関係している。

1.5 FlagBLAS：海光 gfx936 六精度 GEMM マージ（10-19）

日付：2026-10-19　情報源：PR #151 · PR #149 · リポジトリ

  • 主体：PR #151 が海光 gfx936 のベンダー専用 GEMM カーネルをマージ。sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm の六種精度をカバー（+7060/−127、23 ファイル）。hgemm/cgemm/zgemm は独立した Triton カーネルと形状別段階設定を採用し、ctypes で hipBLAS を呼ぶ参照実装と cupy 非依存のテストを配置。dgemm は fp64 MMAC ドット積カーネルを採用。bfgemm はチューニングプール、TN 三路戦略、パディング経路を備える。
  • 依存関係：dgemm は FlagTree の fp64 MMAC サポートに明確に依存——BLAS の精度補完がコンパイラ側の能力ギャップを露呈させたもので、クロスリポジトリ連携の一実証である。
  • 付随対応：同日 PR #149 が Hygon L1 サポートをマージし L1 ベンチマーク形状を補完。ほかに sgemm 単発（#91）やコメントの英語化、ABS オペレータ削除などの整理コミットがある。リポジトリの調査期間内で 9 コミット、3 マージとなり、当日コミット量第 4 位のリポジトリである。
  • 判断：FlagBLAS はこれまで v0.3.0（09-28）の一回のリリースのみで、日常的なコミットは多くない。単日九筆、六精度が揃って投入されたのは、海光チャネルが FlagOS 2.2 以降で初めて体系的に取り組んだ事例である。

1.6 FlagTree：燧原 GCU300 ベースラインと AMD RDNA 降級経路、昇騰 3.5 py312 デリバリ（10-19）

日付：2026-10-19　情報源：PR #1363 · PR #1397 · PR #1396 · リポジトリ

  • CI とベースライン：燧原 enflame3.6-gcu300 の FlagGems ベースラインとテストワークフロー（#1397）、燧原 vLLM ベンチマークのワークフロー化（#1334）、AMD amd3.6 の FlagGems ベースラインとテストワークフロー（#1399）、昇騰 3.5 py312 デリバリワークフロー（#1396）とその後の修正（#1398）、triton_v3.5.x ブランチの codeowner 更新（#1406）。
  • コンパイル能力：FlagMega 側で TLE の pipe、warp_specialize、distributed_barrier を AMD RDNA へ降級（#1363）し、ポータブルデコード経路向けに nvidia-sm89（Ada）ターゲットを補完（#1362）。前者は方言をコンシューマ向け AMD グラフィックスへ沈み込ませるもので、後者は本来 Hopper に縛られていたデコード経路を Ada へ前倒しするものである。
  • 判断：FlagTree の当日作業はほぼすべて「バックエンド × バージョン × ワークフロー」の三次元マトリクス上に格子を敷くもので、5 コミット、8 マージのいずれもコア IR を変更していない。これは 1.2 の builder 収束と同じ事象の両面である。成果物と CI が先行し、言語層はマトリクスが安定してから動く。

1.7 推論と訓練スタック：曦望と燧原のグラフモード、HY4 H100 接続、昇騰 vLLM 0.28 アップグレード（10-19）

日付：2026-10-19　情報源：PR #569 · PR #578 · PR #453 · リポジトリ

  • グラフモード2件：曦望 Sunrise のグラフモード（#569）と燧原 GCU300 のグラフモード（#578、inductor + cudagraph）が同日にマージされた。これは、vLLM 側の CUDA Graph 経路が昇腾/昆仑芯上での検証にとどまらず、2つの国産バックエンド上でも実装され始めたことを意味する。
  • チップ接続：HY4 H100 の FlagOS サポート（#453）がマージされた。ブランチ管理では 0.4.0-dev を 0.5.0-dev へ前方同期し（#612）、CI がこの種の同期 PR を自動生成するようにした（#609）。
  • バージョンライン：達摩院玄鉄バックエンドが vLLM 0.28.0 にアップグレード（#574）。審査側では「opt-in の FlagGems-vllm オペレータを vLLM 0.28 に移植」（#613）、昇腾全デコードグラフと Qwen3.6（#606）、MetaX C550 上の Hy4-preview のグラフモード調査（#614）がある。
  • 学習側：TransformerEngine-FL に CICD プラットフォームマトリックスフィルタ、ci-complete ゲート、制限付きリトライと /ci コマンドをマージ（#137）。Torch-FL に CI 行カバレッジ報告と MetaX 報告の修正をマージ（#587）、さらに審査中に「FlagCICD エントリを統一し、L0 から L2 をサポート」（#599）がある。
  • 判断：推論スタックにおけるこの日のキーワードは「グラフモードの展開 + バージョンラインの追随」である。グラフモードは性能実現の前提条件であり、vLLM 0.28 はバージョン負債の返済であり、両者とも次回の対外性能数値に向けた準備である。

1.8 FlagDNN / FlagTrain / FlagSparse / Torch-FL：天数等価性能、摩尔線程バックエンド、MUSA 最適化（10-19）

日付：2026-10-19　情報源：FlagDNN コミット · FlagTrain PR #20 · FlagSparse PR #113 · Torch-FL PR #593

  • FlagDNN：4件のコミットがすべて master に直接プッシュされた。まず iluvatar の等価性能ベースライン（equivalent_baseline.cpp、equivalent_runner.hpp など、+8157）を追加し、その後2回の修正（hygon ベンチマーク契約と pre-commit 調整を含む）を行い、ascend 検証ディレクトリを整理した（−7047）。当該リポジトリには当日 PR フローがなく、メンテナによる直接プッシュである。
  • FlagTrain：摩尔線程バックエンドと2つのオペレータのサポートをマージ（#20）。当該リポジトリは 10-15 に初版ドキュメントができたばかりで、10-14 から packbits、unpackbits、evoformer_attn を連続して補充しており、現在最も若いオペレータリポジトリである。
  • FlagSparse：MUSA 最適化をマージ（#113、NCIC-AlphaSparse ブランチから）。調査期間内に2件のコミット、1件のマージ。スパースライブラリへのベンダー投資は現在摩尔線程の1ラインに集中している。
  • Torch-FL：「iluvatar に独立ランタイムを提供し、ホイールが CPU 版 torch にリンクするようにする」（#593）と CI カバレッジ報告（#587）をマージ。審査中には Iluvatar BI-V150 ビルドテスト行（#569）、FlagCICD エントリの統一（#599）、置き換えられた PR とブランチ実行のキャンセル（#588）がある。
  • 判断：4つのリポジトリに共通するのは「あるベンダーのバックエンドに測定可能なベースラインを補充する」ことである——天数は等価性能、摩尔線程はバックエンドエントリ、スパースライブラリは MUSA 経路、Torch-FL は GPU ドライバのないマシンにインストールできること。こうした作業は対外情報には現れないが、次版の性能表がこれらのチップをカバーできるかどうかを決める。

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

2.1 会議後初の深掘り技術記事：中華網が FlagOS 2.2 のフルスタック分解を掲載（10-19）

日付：2026-10-19　情報源：中華網技術記事 · 網易転載

  • 性質：これは大会（10-17 から 10-18）後に出た、完全な技術的詳細を伴う最初のメディア記事であり、10-19 17:56 に公開された。講演の速記ではなく、「オペレータとコンパイル、補助研發、プラグインと量子化、Token サービス、端側とプラットフォーム」の5段で構成され、8枚のアーキテクチャ図と3枚の性能表を含む。
  • 新たに追加された定量的事実（前回のデイリーレポートでは未網羅）：KernelGen はすでに9種類の AI チップをサポートし、今四半期に新たに765個のオペレータを生成、うち416個は少なくとも5種類の国産チップで精度検証に合格し、ネイティブオペレータの80%以上の性能に達した。FlagGems-SGLang の40個のオペレータは NVIDIA 上ですべて合格した。Qwen3.8-Flash-Next 向けに8個の融合オペレータを新たに追加し、CUDA Graph への完全なグラフ化を完了した。
  • 量子化ツールの実例：FlagOS-Compressor は Qwen3.5-397B-A17B で W8A8 を採用後、モデルファイルが751.41GBから382.45GBに減少（49.1%減）、GPQA-Diamond の絶対精度は84.85%、NVIDIA H20 と国産 PPU の2つの推論チェーンで検証を完了した。Qwen3.8-2.4T-A95B では BF16、FP8 から INT8 への処理パスを示した。
  • Token サービスのシナリオ別数値：DeepSeek V4.1 Flash は H100（1P1D、W4A16/FP8）上で32路と64路の並列時に、リクエストごとのデコード速度がそれぞれ19.7%と18.0%向上した。達摩院玄鉄 810E（各ノード16枚の96GB、W8A8）では24路と48路の並列時にそれぞれ83.1%と91.5%向上した。GLM-5.3-Flash の論理サービススループットは8.52kから17.36k tokens/sに向上（2.04倍）。512K 長コンテキストの生成速度は60.9 tokens/sで、公式 API の外部測定参考値61.1の99.7%に相当する。8カード910Bの月額レンタル16,500元で試算すると、256K入力/8並列の100万出力 Token あたりのレンタル換算コストは59.27元で、商業 API の課金参考値より19.4%低く、512K入力/4並列では104.53元で27.6%低い。
  • エコシステムとプラットフォーム側：エコシステムメンバー単位は107社、第3四半期のコミュニティダウンロードは464,336回で第2四半期の4.76倍、新規パートナーには凌川科技、中国電子、潤開鴻、中国電信、NXP、壁仞科技、跨維智能、聆思科技が含まれる。中国電信星辰大モデルは訓練側で FlagGems を MindSpore + CANN + 昇騰 NPU 体系に接続し、mHC、TopK などの訓練オペレータはエンドツーエンド検証を完了、MindFormers 統合作業はすでにオープンソースでマージ済み。推論側では Xing4.0-29B-A4B が10種のチッププラットフォームへの適配を完了（うち Apple M5 Pro と此芯 P1 は W4A8 端側量子化を採用）、12個の推論オペレータを FlagGems と vLLM メインリポジトリにオープンソース化した。軟通動力天元智算ハイブリッドクラウドは4台の昇騰 910C 上で GLM-5.2 を最適化し、5項目の変更をすべて有効化した後、p50 ITL が14.53%低下、サーバー側 p99 ITL が83.82msから66.35msに低下（−20.84%）。
  • 判断：この記事の意義は数字の多寡ではなく、2.2の収益を「再検証可能な個別ケース」に分解した点にある——各数字にはモデル名、チップ型番、並列数、対照基準が付されている。これまでの2回のデイリーレポートの2.2の口径はメインフォーラムの4組の集計指標が中心だったが、この記事はグループ別の証拠を補った。

2.2 報道の拡散とチャネル核查：存储在線の講演全文は10-18の旧稿の遅延インデックス、CSDN と智源コミュニティに新規なし（10-19 ~ 10-20）

日付：2026-10-19 ~ 2026-10-20　情報源：存储在線稿 · CSDN DAMO 開発者マトリックス · 智源コミュニティ

  • 夜間インデックス識別：Google News は 10-19 17:09 に儲存在線の『林咏華：衆智FlagOS 2.2リリース、token経済は物理AIへ向かっている』を収録したが、原ページの日付表記は 2026-10-18 であり、内容はメインフォーラム講演の全文整理で、前号デイリーレポートが引用した DOIT 現場報道と同源である。収録規則により新規項目として重複計上せず、拡散としてのみ登録する。
  • コンポーネント名の直接検索は依然ゼロ：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen の七組のコンポーネント名は 24 時間の調査期間内で依然としてヒットゼロであり、これは複数の調査期間にわたって同一の結論である。ヒットは「智源研究院 オープンソース / チップ」「国産算力 オープンソースソフトウェアスタック」などの広範な語に集中しており、14 件の候補のうち 12 件は資本・市況関連稿（新株発行統計、工博会展受賞、融資速報、オフィス Agent レポート）であり、タイトルの意味に基づき除外した。
  • チャネル核查：CSDN の FlagOS コラムと DAMO 開発者マトリクスは調査期間内に新規記事が見られなかった（最新は 10-12 の全日程予告であり、10-17 から 10-18 の分科会ライブページは依然として「再生中」と表記されている）。智源コミュニティのトップページとサイト内検索に FlagOS 関連の項目はない。HN Algolia の八組のクエリに直接のヒットはなく、返却結果はすべて同名語の誤マッチであった。大会分科会の各回議事録は調査期間の締め切りまでに依然として公開されていない。
  • 判断：ニュース側は「会後消化期」に入った——メインフォーラムの内容はメディアによる二次加工であり、分科会とワークショップの内容はまだ記事化されていない。デイリーレポートにとって、今号のニュース面の有効項目は 1 件（2.1）であり、主体情報量は依然として GitHub 側にある。

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

3.1 海光：FlagBLAS 六精度 GEMM と L1 サポートが同時にリポジトリへ（10-19）

日付：2026-10-19　情報源：FlagBLAS PR #151 · PR #149 · FlagGems PR #6584

  • アクション：PR #151 が gfx936 の sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm 六精度カーネルをマージし、PR #149 が L1 サポートをマージ、二件が同日に master へ入った。FlagGems 側では hygon_mv のタイムアウト問題を修正した（#6584）。
  • 技術的取向：BF16 はチューニングプール + TN 三路戦略 + padding パスを採用し性能レポートを添付、FP64 は MMAC ドット積カーネルを採用、半精度と複素数は独立 Triton カーネル + 形状別段階設定を採用、参照実装は cupy ではなく ctypes で hipBLAS を呼び出すよう変更——テスト環境が意図的に CUDA エコシステムに依存しないことを示している。
  • ギャップ：dgemm は FlagTree の fp64 MMAC サポートに依存しており、コンパイラ側の能力が既にメインラインに入っているかは、今後の FlagTree の MMAC コミットを確認する必要がある。現時点では依存関係が PR に明記されていることのみ確認できる。
  • 判断：海光のこれまでの FlagOS 投入はビルドチャネルとデバイスインターフェース（/dev/itrctl）が中心であったが、BLAS 幹線への参入は、「性能がベンチマークで直接測定できる」レイヤーでの強化を開始したことを意味する。

3.2 天数智芯：FlagDNN 等価性能ベースラインを直接 master へプッシュ、Torch-FL は独立ランタイムを分離（10-19）

日付：2026-10-19　情報源：FlagDNN コミット · Torch-FL PR #593 · build-infra PR #1409

  • FlagDNN：master への直接プッシュ4件はすべて iluvatar を中心に展開——等価性能ベースラインの新規追加（+8157）、2回の修正、および backends/iluvatar/dispatch/pointwise.py と kernels/activation_backward.py、kernels/binary.py の実装調整。同一バッチのコミットには hygon ベンチマーク契約の修正と ascend 検証ディレクトリの整理（−7047）も含まれる。
  • Torch-FL：PR #593 で iluvatar に独立ランタイムを提供し、ホイールが CPU 版 torch をリンクするように——つまり天数のマシン上で CUDA ランタイムなしでもインストール可能；併せて審査中の Iluvatar BI-V150 のビルド・テスト行（#569）がある。
  • ビルド側：build-infra の PR #1409 で iluvatar の pin 日付を 22.04 再リリース版に更新、PR #1420 で同じバッチとして sunrise ホイールを 22.04-clean で再リリースしたことを記録。
  • 判断：天数のこの日の3つの動きは同一目標を指す——「天数カード上で動く」を「天数の標準環境で自動ビルドされ、自動テストされ、等価性能が自動生成される」に変えること。等価性能ベースラインはその目標の最後のピースである。

3.3 清微と曦望：2つのバックエンドが同日に FlagCX 22.04 builder へ参入（10-19）

日付：2026-10-19　情報源：build-infra PR #1422 · PR #1418 · PR #1420

  • 清微（tsingmicro）：PR #1422 で tsm260610 ホイールに 22.04 自己完結 builder を追加；FlagGems 側では同日 bump-flagtree-tsm ブランチが出現（10-19 15:31 作成）、FlagTree の清微版アップグレードを指す。base イメージ tsingmicro-tsm260610 は既にマトリクス内にある。
  • 曦望（sunrise）：PR #1418 で tangrt1.2.0 ホイールに 22.04 自己完結 builder を追加し flagcx-builder-sunrise ブランチを作成（10-19 17:57）、PR #1420 で続いて当該ホイールを 22.04-clean で再リリースしたことを記録。
  • 意義：両社とも FlagOS 2.2 の21社のチップメーカー口径の前列ナラティブにはないが、成果物チャネルは既に同一仕様で接続済み——これは通常、適配作業が「動くかどうか」を越え、「安定的に交付できるかどうか」に入ったことを意味する。
  • 未確認項目：調査期間内に这两社の独立した Release や対外ニュースは見られず、本項は GitHub 側の証拠のみである。

3.4 燧原：GCU300 ベースライン、vLLM ベンチマークワークフローと builder アサーション修正（10-19）

日付：2026-10-19　情報源：FlagTree PR #1397 · PR #1334 · build-infra PR #1417 · vllm-plugin-FL PR #578

  • CI 3件：FlagTree に enflame3.6-gcu300 の FlagGems ベースラインとテストワークフローを追加（#1397）、燧原 vLLM ベンチマークをワークフローに追加（#1334）；build-infra に燧原 builder を追加し検証ステップをデータ駆動に変更（#1417）、同時に「ビルド期に燧原バックエンドをアサート」を修正（#1419）、toolkit deb をイメージにプリセット（#1421）。
  • ランタイム1件：vllm-plugin-FL の GCU300 グラフモード（#578）をマージ、inductor + cudagraph を有効化。
  • 判断：燧原の当日の6件の動きは「ベースライン、ベンチマーク、パッケージング、アサーション、グラフモード」の5段階をカバーし、単一メンバー単位の中で最もチェーンが完整な組である。GCU300 のグラフモード落地は、build-infra が同日ビルド期アサーションを修正した理由も説明する——グラフモードのコンパイル経路はバックエンド宣言に対してより敏感である。

3.5 摩尔線程、昇騰、達摩院玄鉄：MUSA オペレータライン、CANN 9.0 ベースライン、T-Head GRU デッドロック修正（10-19）

日付：2026-10-19　情報源：FlagGems PR #7261 · PR #7203 · FlagTrain PR #20 · FlagSparse PR #113 · build-infra base

  • 摩尔線程：FlagGems の KMCompiler 線は linear 重みを trans_b で WS SQMMA に送り込み（#7261）、rnn_tanh テストで musa を有効化（#7256）。FlagTrain は mthreads バックエンドと2つのオペレータを追加（#20）。FlagSparse は MUSA 最適化をマージ（#113）。3つの線が MUSA に関する当日の全アクションを構成している。
  • 昇騰：build-infra の base/ 下には ascend-cann8.5.0 と ascend-cann9.0.0 が同時に存在し（各々 910c 変種を含む）、4つの wheel の builder を 22.04 に統一（#1414）。FlagGems 側では mm 形状ディスパッチと Triton tiling 最適化（#7239）、reference 契約の修正（#7286、#7287、#7253）。FlagTree の 3.5 py312 デリバリーワークフロー（#1396、#1398）。vllm-plugin-FL の昇騰フルデコードグラフは依然レビュー中（#606）。
  • 達摩院玄鉄：FlagGems は T-Head バックエンドの GRU barrier デッドロックを修正（#7203）。FlagGems-vllm は sparse QSA の最小タイルを 16 行に引き上げ（#940）。vllm-plugin-FL は玄鉄バックエンドを vLLM 0.28.0 に更新（#574）。3つの線はそれぞれ正確性、性能下限、バージョン追従に対応する。
  • 判断：3社の当日の共通点は「新機能の追加」ではなく「境界の修正」である——MUSA はバックエンド入口を補い、昇騰はデリバリーとテスト契約を補い、玄鉄は並行正確性を補っている。この種の修正は対外的な性能指標には現れないが、マルチチップベースラインを横比較できるかどうかを決定づける。

4. 総括とトレンド観察

  • トレンド1：成果物チャネルの統一が機能拡張に先行。build-infraは1日で16件のコミット、16件のマージを記録し、そのすべてが22.04の自己完結型builderをめぐるものだった。昇騰四輪子、曦望、清微が同じ日に同じレシピへ組み込まれ、base/ディレクトリは9社・17のベースラインイメージのマトリクスを形成した。glibcの下限を2.38から2.35へ引き下げたことは、どの新規オペレータよりも直接的に「ホイールをユーザーのマシンにインストールできるかどうか」を決定づける。この手がかりは10-16から10-18の6バックエンド集約と連なり完全なチェーンを成しており、FlagOS 2.2リリース後初の体系的な補習と見なせる。
  • トレンド2：量子スタックがフレームワークの雛形から汎用フレームワークの境界定義へ移行。FlagQuantumは1日で405ファイル、159の新規公開名をマージし、同時にM0からM4までのロードマップで5類のハードウェアの再利用前提を明確化し、Stable Coreの41のエクスポートを不変に保った。この「サブパッケージを拡張し、コアをロックする」手法は、10-18の量智雲リリース時にFlagQuantumを技術底稿として位置づけたことと一致する——対外的に能力を語る前に、どれが安定インターフェースかをまず明確に書き記すのである。
  • トレンド3：国産計算力側の投入が「オペレータ」から「ベンチマークと基礎ライブラリ」へ移行中。海光はFlagBLASで6精度GEMMとL1サポートを補完し、天数はFlagDNNで等価性能ベースラインを補いmasterへ直送、燧原はFlagTreeでGCU300ベースラインとvLLMベンチマークワークフローを敷設、摩尔線程はFlagGems、FlagTrain、FlagSparseの3ラインを同時に動かしている。共通点は、いずれもベンチマークで直接測定可能であり、単に「某オペレータをサポート」するだけではないことだ。
  • トレンド4：KernelGenは疎とビュー意味論の掃討段階へ。マージ側の_coalesce、ccol_indices_copy、_neg_view_copyと審査中側の十数件の疎オペレータ（_sparse_mm族、coo/csrインデックス相互変換、copy_sparse_to_sparse_）は、稠密幹線がほぼ在庫一掃されたことを示している。同時に昆仑芯は30件の審査中で単一バックエンド最大のキューを構成し、XPU3のアテンション族とRNN族が次批のマージ主体である。
  • トレンド5：ニュース面は会後の消化期に入り、情報の重心はリポジトリへ回帰。24時間枠内の有効ニュースは1件（中華網10-19の技術分解、7つの量子化案例を補足）、コンポーネント名直查は連続ゼロヒット、分科会紀要とワークショップ内容は未成稿。経験則では、こうした枠の後1〜2日で分科会の二次報道が現れることが多く、次期の観察点となりうる。
  • 次期注目：1つはFlagQuantumのfeat/m0-common-foundationブランチ（10-19 16:47作成）がいつPRを出すか、2つはFlagGemsの疎カーネル審査中キューのマージペース、3つはbuild-infraが「1行1バックエンド」レシピをFlagTreeとTorch-FLの成果物ラインへ複製するか、4つは大会分科会紀要が公開されるかである。

完全な情報源リスト

6 昇騰 3.5 py312 デリバリー — https://github.com/flagos-ai/FlagTree/pull/1396

情報源検証表

情報源 核查結果
GitHub org flagos-ai 61 リポジトリを全量核查、16 リポジトリが調査期間内にプッシュ、93 コミット、88 マージ
GitHub Release / タグ 16 のアクティブリポジトリを逐一核查、調査期間内に新規 Release なし
GitHub 審査中 PR 180 件が調査期間内に更新、上位 100 件をリポジトリ別に集計（FlagGems 63、FlagGems-vllm 12 が上位）
Google News RSS 24 組の中英語クエリ、調査期間内に 14 件の候補、有効 0 件（コンポーネント名直接検索はゼロヒット、広範語でヒットした 12 件は資本・市況記事、2 件は旧記事の遅延インデックス）
HN Algolia 8 組のクエリで直接ヒットなし、返却は同名語の誤マッチ
中華網 / 網易 1 件有効（10-19 17:56 技術分解）、7 つの定量案例を補足
ストレージオンライン 1 件遅延インデックス（ページ日付 10-18、講演全文）、重複計上せず
CSDN FlagOS コラム / DAMO 調査期間内の新着記事なし、分科会ライブページは依然としてリプレイ表示中
智源コミュニティ トップページとサイト内検索に FlagOS 関連項目なし
大会公式サイト議程ページ 議程に変更なし、議事録や講演実録の公開は見られず