調査期間：2026-11-05 06:00 ~ 2026-11-06 06:00（北京時間、24時間；前回デイリーレポートの締め切り時点から継続）。

情報源：GitHub（org: flagos-ai 61リポジトリ全件核查、期間内123コミット、94マージ済みPR、期間内更新の審査中PR 255件（うち87件新規作成）、21リポジトリへのプッシュ、31リポジトリのReleaseと8リポジトリのTagの原子的核查）、Google News RSS（24組の中英語検索語、プロキシ経由）、HN Algolia（8組）、CSDN FlagOSコラム（各記事の時刻を個別確認）、智源コミュニティ（詳細は付録の情報源リストを参照）。

本期インデックス

  • 今日の重点：寒武紀がTorch-FLで融合アテンションの順伝播と逆伝播を接続し、Qwen3学習ステップのCPUフォールバックが190回からゼロに；コミュニティが1日で7件のFEP（0163–0170）を提出；燧原のGCU300向け改写25件を一括で清算、FlagGemsの7つのバックエンドキーをバージョン化命名に変更（11-05）
    1. オープンソースプロジェクトの進展（GitHub動向）
      • 1.1 組織のリズム：21リポジトリへのプッシュ、123コミット、94マージ、審査中255件（11-05）
      • 1.2 コミュニティガバナンス：1時間以内に7件のFEPがレビュー入り、FlagMega v0.1とTLE Rawの5バックエンドを登録（11-05）
      • 1.3 バージョン面：2.3.0にnvidia-cuda13.3を記録、cuda12.8を凍結、torchを2.13へアップグレード（11-05）
      • 1.4 FlagGems：33件のマージのうち25件が燧原、7つのバックエンドキーをバージョン化命名に変更（11-05）
      • 1.5 FlagTree：海光がTLE-Rawを接続、ptxasリソース使用量をコンパイラメタデータへ（11-05）
      • 1.6 Torch-FL：寒武紀の融合アテンション順逆伝播を補完、学習ステップのCPUフォールバックがゼロに（11-05）
      • 1.7 FlagQuantum：27コミットでCI容量を再編、フォールトトレラントコンパイラの大規模ブランチが統合へ（11-05）
      • 1.8 視覚・学習側：FlagCVがSGLang評価契約に整合、FlagTrainがKMCompilerオペレータを接続（11-05）
      • 1.9 関連基盤：docsのモデルリストボットが起票、optestとOpenCourseが小幅に推進（11-05）
    1. 報道とエコシステム
      • 2.1 FlagOS 2.2産業事例：中国電信のmHC学習損失を25%から12%へ削減（11-05）
      • 2.2 端末側特集：ARM CPUで大規模モデルを21%–25%高速化、マルチチップ適配が35種のチップをカバー（11-05）
      • 2.3 チャネル核查：コンポーネント単位でゼロヒット、燧原のタイトルは核查の結果、上場回顧記事と判明（11-05）
    1. メンバー単位とバックエンドベンダーの深掘り
      • 3.1 寒武紀：CNNL融合アテンション順伝播と逆伝播、190回のフォールバックをゼロに（11-05）
      • 3.2 燧原：GCU300が一夜で25件を清算、NVIDIA外部シンボルを逐一ローカル実装へ置換（11-05）
      • 3.3 海光：HCUのTLE-RawとBF16エキスパートGEMMの2路線を並行推进（11-05）
      • 3.4 昇腾：Flash AttentionのUBオーバーフローを修正、varlen順伝播とD=256を補完（11-05）
      • 3.5 摩尔線程、天数、沐曦、昆侖芯、清微と玄鉄：行列乗算とレイアウトを分批で推進（11-05）
    1. まとめとトレンド観察

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

1.1 組織のリズム：21リポジトリへのプッシュ、123コミット、94マージ、審査中255件（11-05）

日付：2026-11-05　出典：flagos-ai 組織リポジトリ · コミット検索（期間内） · マージ済みPR検索（期間内） · 審査中PR検索（期間内）

  • 総量：61 個のリポジトリのうち 21 個が調査期間内にプッシュされ；メインブランチの新規コミットは 123 件で、12 個のリポジトリに分布；マージ済み PR は 94 件で、14 個のリポジトリ、32 名の作者による。
  • コミット分布：FlagGems 33、FlagQuantum 27、Torch-FL 12、build-infra 12 の四リポジトリで合計 84 件、68.3% を占める；以下は FlagGems-sglang 8、FlagCV 8、FlagTrain 7。
  • マージ分布：FlagGems 33、build-infra 12、Torch-FL 12 が上位三；FlagTrain 7、FlagGems-sglang 6、FlagQuantum 5、FlagTree 5、FlagGems-vllm 5、FlagCV 4。
  • 人員分布：youseeyouonedayday 25 件（すべて燧原 KernelGen ライン）、lvyufeng 12 件（Torch-FL）、lukatao 9 件（FlagCV、FlagGems-sglang、FlagTrain）、tengqm 6 件（build-infra）、FlagQuantum ボット 5 件、github-actions 5 件。
  • 審査中：255 件が調査期間内に更新され、うち 87 件が新規作成；FlagGems 84、FlagTree 71 の二リポジトリで合計 155 件、60.8% を占める。
  • バージョン面：31 個のリポジトリの Release 原子源と 8 個のリポジトリの Tag 原子源は調査期間内に新規ゼロで、直近は依然として FlagCX v0.14.1（11-01）。
  • 前回比較：コミット 238→123、マージ 167→94、プッシュリポジトリ 26→21。数量は通常範囲に回帰したが、同日に 7 件の FEP と一連のバージョンエンジニアリング作業が着地しており、「収束日」であって「拡大日」ではない。

1.2 コミュニティガバナンス：1 時間以内に 7 件の FEP がレビュー入り、FlagMega v0.1 と TLE Raw 五バックエンドが登録（11-05）

日付：2026-11-05　情報源：FEP-0163 · FEP-0164 · FEP-0165 · FEP-0166 · FEP-0167 · FEP-0168 · FEP-0170 · 2.3 リリーススケジュール

  • アクション：08:29 から 08:32（北京時間）の四分区間に六件、09:31 までに計七件の FEP が起票され、提出者はすべて wbavon、各件単一ファイル、篇幅 104 から 207 行、ステータスは一律 Provisional Draft と記載。
  • リスト：FEP-0163 FlagMega v0.1（モデルコンパイル、vLLM 統合、マルチカードデコード）、FEP-0164 TLE 分散融合と自動チューニング、FEP-0165 TLE Raw が五つのアクセラレータバックエンドをカバー、FEP-0166 FLIR の昇騰および GPGPU 向け最適化、FEP-0167 二十のオペレータ—デバイスペアのコンパイラ最適化、FEP-0168 FlagTree マルチプラットフォーム対応と Triton API 互換、FEP-0170 FlagPrism v0.2 マルチバックエンドデバッグとプロファイリング。
  • 最も実質的な一件：FEP-0163 は五項目の目標と受け入れ証拠のマッピングを示す——Qwen3.8 / GLM5.3 Flash の model-to-MegaKernel コンパイル、BS=1 デコード、vLLM 統合、NVIDIA / AMD / 天数 CoreX 5.0 の三者対応、四枚 H800 上で GLM5.3 Flash のデコードスループットが vLLM より 5% 以上高い；同時に CoreX 5.0、リリースマトリクス、GLM checkpoint の再現が未完了であることを明記。
  • 共通点：七件の本文はいずれも「GPU またはモデルの受け入れは未実施」と明記し、「範囲宣言」と「完了宣言」を分けている。これはマルチバックエンド能力マトリクスを受け入れ可能な項目として記述する手法であり、リリースリストではない。
  • 時間関係：2.3 スケジュールによれば、FEP マージ締切は 11-13、rc0 は 11-30。この一批は締切の八日前に現れ、まさに「範囲補完」のウィンドウに収まっている。
  • 同批ブランチ：community リポジトリには別途四本の codex/fep23-* ブランチが調査期間内にプッシュされており、FEP 起草とブランチ準備が同一パイプラインであることを示す。

1.3 バージョン面：2.3.0 に nvidia-cuda13.3 を記録、cuda12.8 は凍結、torch は 2.13 へアップグレード（11-05）

日付：2026-11-05　情報源：build-infra #1649 · build-infra #1652 · build-infra #1653 · build-infra #1654 · build-infra #1655 · build-infra #1647 · build-infra #1650

  • バージョン記録：#1649 は base ドキュメントに 2.3.0 を記録し、イメージ記述を更新；#1653 は runtime 側の 2.3.0 changelog の日付を補完し、対象は nvidia-cuda13.3。これは cuda13.3 のラインが初めて 2.3.0 のカバレッジに入ったことを意味する。
  • アップグレード内容：#1652 は cuda13.3 を torch 2.13 に追従——torch 2.13.0+cu130、torchvision 0.28.0+cu130、triton 3.7.1；torchaudio は 2.11.0+cu130 を維持、FlagTree は 0.7.0 を維持（両者は torch バージョンと切り離されている）。
  • 凍結方法：torch 2.13 は cu128 wheel を公開しなくなった（当該トラックは 2.11.0 で終了）。そのため cuda12.8 は追従できない。対応として configs.yaml に enabled: フィールドを追加し false に設定——削除ではなく凍結：仕様、イメージ、ドキュメントは残し、イメージは最後にビルドしたフラットタグのまま停止する。
  • 監査可能性：スクリプト backend_enabled.py が唯一のパーサーとなり、generate_matrix.py、2 つのステータスレポート、flagcx と vllm-plugin のレジストリがこれを共用することで、「凍結」がいかなるビルドマトリクスにも入り込めず、消費者が凍結をドリフトと誤認することもなくなる。
  • 関連修正：#1655 は torch-2.13 による flagcx の再ビルドを cuda13.3 の依存チェーンに書き込み；#1654 は flagtree の HCU ビルド向けに 2 セットの LLVM ツリーを同時に敷設し、libzstd-dev を補完。
  • リリースフロー：#1647 と #1650 で vllm wheel リリースを 2 回記録；#1346 は共用の upload-nexus 再利用可能ワークフローを撤去し、アップロード経路を収束。

1.4 FlagGems：33 件のマージのうち 25 件が燧原、7 つのバックエンドキーをバージョン付き命名に変更（11-05）

日付：2026-11-05　情報源：FlagGems #8446 · FlagGems #8287 · FlagGems #8028 · FlagGems #8393 · FlagGems #7581 · FlagGems #7246 · FlagGems #6706

  • マージ構造：33 筆のうち 25 筆は KernelGen と Enflame のプレフィックス付き（3.2 参照）、3 筆は崑崙芯、2 筆は摩尔線程、1 筆は昇騰、1 筆は清微、残りは CI と汎用修正。
  • バックエンドキーのバージョン化：#8446 は 12 ファイルを変更、39 行追加・38 行削除で、backends.yaml 内の 7 つの裸のベンダー名を pyproject.toml と一致するバージョンキーに変更——hygon-dtk2604、iluvatar-corex450、kunlunxin-xre5371、spacemit-xxx、sunrise-tangrt120、thead-ppu210、tsingmicro-tsm260610。
  • 記録に値する理由：旧来の書き方では uv pip install ".[tsingmicro]" がどの extra にもサイレントにマッチせず、torch も flagtree もインストールされず、setup.sh の FlagTree 検証が直接 ModuleNotFoundError: No module named 'torch' を投げていた。キー名を揃えたことで、チップコード名とソフトウェアスタックのバージョンが初めて同じ場所に書かれ、バージョンを間違えてインストールするとサイレントにスキップされるのではなく失敗するようになった。
  • 清微：#8287 は tsingmicro バックエンドを 1103 に更新、190 ファイル、23195 行追加・914 行削除で、本調査期間で単一最大のバックエンド同期。
  • 崑崙芯：#8028 は 4 つのオペレータ入口を dtype 等権 Gems Speedup 閾値以上に最適化、3 回のコールドキャッシュ平均値はそれぞれ upsample_nearest2d 1.202、unique_consecutive 1.053、fake_quantize_per_tensor_affine 0.827、foreach_clamp_max_scalar 0.967；#8393 は cholesky 求解ヘルパーなどの XPU カバレッジを補完。
  • 審査中：FlagGems は調査期間内に 84 筆更新（うち 15 筆はトップページ統計で新規開設）、依然として組織全体で最大のレビュープール。

1.5 FlagTree：海光が TLE-Raw を開通、ptxas リソース使用量をコンパイラメタデータへ（11-05）

日付：2026-11-05　情報源：FlagTree #1508 · FlagTree #1530 · FlagTree #1568 · FlagTree #1573 · FlagTree #1572 · FlagTree #1574 · FlagTree #1576

  • マージ：5 筆。#1508 は海光 HCU に tle.raw パスを追加、53 ファイル、5106 行追加・17 行削除；#1530 は ptxas 診断におけるレジスタ、スピル、スタック、共有メモリの使用量を解析；#1568 は CI 失敗時に飛書で担当者を名指し；#1573 は vllm 起動スクリプトの stderr リダイレクト順序を修正。
  • HCU の詳細：#1508 は同時に eager と deferred の 2 モード、HIP と MLIR の 2 ソース（LLVM IR にコンパイル後に Triton IR へ埋め込み）をサポートし、DUSHMEM ストリーミング集合通信を接続；併せて ring shift、allgather GEMM、GEMM allreduce の 3 チュートリアルを添付。サンプルでは sort の HIP パスが torch 比 1.29 倍。
  • 可観測性：#1530 はリソース使用量を TLE コンパイラメタデータに書き込み、パーサと起動・通信動作を分離；リポジトリ側の集約検証では 154 の TLE MLIR テストと 11 の新規 C++ 単体テストが全て通過、H800 上では 57 の精密フィル、ループパイプライン、scatter ケースが全て通過。
  • 新規：3 筆。#1572 は摩尔線程が dot 変換で明示的 blocked レイアウトを保持できるように；#1574 は再配列ループロードに展開境界と前倒し前提距離を追加；#1576 は燧原 TLE の SoC レベル分散強化。
  • 審査中：調査期間内に 17 筆更新、TLE 明示レイアウト、Iluvatar native 再現ケース、FlagPrism / MetaX と PPU の set_layout に集中。

1.6 Torch-FL：寒武紀の融合アテンション順伝播・逆伝播を補完、学習ステップの CPU フォールバックをゼロに（11-05）

日付：2026-11-05　ソース：Torch-FL #748 · Torch-FL #749 · Torch-FL #757 · Torch-FL #754 · Torch-FL #745 · Torch-FL #756

  • マージ：12 件、すべて lvyufeng によるコミット。主軸は寒武紀 MLU のオペレータ収束と Iluvatar のパス解放。
  • 融合アテンション：#748 で cnnlFlashAttentionForward_v2 を SDPA の複合カバレッジに接続し、「3 つのリーフオペレータへの分解」という歴史に終止符——バッチ 2、4 ヘッド、シーケンス 4096 の場合、その B×H×S×S スコア行列は約 256 MB で、従来は HBM に書き込んでから読み戻す必要があった。#749 は cnnlFlashAttentionBackward_v2 で逆方向を補い、順方向とともに C++ autograd Function にパッケージ化。
  • フォールバックゼロ化：#757 はまず完全な Qwen3 因果言語モデル訓練ステップの全面調査を行い、残存する 190 回の cpu_fallback がわずか 2 つのオペレータに由来することを発見——aten::mul.out が 188 回、aten::embedding_dense_backward が 2 回。両者を CNNL 経由で MLU 上で実行するよう変更した後、同一ステップでオペレータフォールバックゼロを報告。登録は引き続きコードジェネレータが生成し、設定ファイルと登録ファイルが食い違うことはない。
  • 同側修正：#754 で寒武紀の mul オペランドをデバイス上に留め、ランタイムキューを共有させる；#750 と #755 は argmax が NaN を含むスライス上で軸長を返す欠陥、およびグラフが自身にマッチングマーカーがないことに回答する欠陥を修正。
  • 天数側：#745 で Iluvatar のオペレータ上限を解放し、mul.Tensor が FlagGems に到達できるようにする；#746 は mean の差距が空リダクションパスに由来することを記録。
  • CI：#756 で崑崙芯 3.2 GB の FlagTree wheel を pip キャッシュの外に追い出す；#760 は push トリガーのみがキャッシュを書き込むよう限定。
  • レビュー中：調査期間内に 6 件更新。含まれるものは #752 が集合通信を持たない内層バックエンド向けに合成マージ式 all-gather / reduce-scatter、#753 と #762 が ixblas axpy で Iluvatar の add ファミリーを担う、#759 の沐曦 DTensor と FSDP2 マルチカード検証スクリプト。

1.7 FlagQuantum：27 件のコミットで CI 容量を再編、フォールトトレラントコンパイラの大型ブランチが統合フェーズへ（11-05）

日付：2026-11-05　ソース：FlagQuantum #1089 · FlagQuantum #1093 · FlagQuantum #1094 · FlagQuantum #1084 · FlagQuantum #1087 · FlagQuantum #1092

  • マージ：5 件、うち3件は CI：#1089 で CPU 容量とマネージドキュー、SDK ダウンロードを分離；#1093 でコア環境を事前にロックしてマネージド容量を解放；#1094 では割り当て済み CPU 容量と完全カバレッジパーティションを組み合わせる。残り2件は責務に応じたコンパイラモジュールの再編成とフォールトトレランステスト W1-B。
  • 27 コミットの主線：すべて CI 品質ゲートを巡るもの——イメージキャッシュの資格を限定してからコアスイートを移行、置き換えられた実行は失敗ゲートをスキップしない、必須マージゲートではキャンセルされた依存を拒否、リアルタイム Qiskit 依存の発見をマネージド runner に残す、SDK キューを分離、アーティファクトアップロードに有界リトライ、計時されていない大規模テストモジュールを有界バッチに分散、適格なオフライン A800 環境でコアスイートを実行、品質のために容量を確保し8つのマネージドスロットを均衡、キャンセルされたジョブのコンテナをクリーンアップ。
  • フォールトトレラントコンパイルブランチ：feat/ftqc-native-integration は調査期間内に約 20 コミット、内容は QVR の位相勾配、スケーリング加算、測定随伴と Hamming 重み位相を段階的に移植するもの；メイン統合単 #1084 はすでにドラフトとしてオープン、276 ファイル、31011 行追加・92 行削除、後続モジュールを独立コミットで補完してから正式レビューを依頼する旨を明記。
  • 誤り訂正作業：#1087 で Stim と PyMatching の実験ワークフローを接続；#1092 で行列定義の重み付きマッチングをサポート；#1085 で有界 W2/W3/W6 准入にテストを追加。
  • 判断：この日の 27 件のうち量子アルゴリズム自体は1件もなく、すべてテストを信頼できるものにし、runner を再現可能にするためのもの。フォールトトレラントコンパイルを走らせるプロジェクトにとって、この勘定を先に払うのは合理的だ。

1.8 視覚と訓練側：FlagCV が SGLang 評価契約に整合、FlagTrain が KMCompiler オペレータを接続（11-05）

日付：2026-11-05　情報源：FlagCV #4 · FlagCV #5 · FlagCV #6 · FlagCV #7 · FlagTrain #56 · FlagTrain #57 · FlagGems-vllm #1048 · FlagGems-sglang #294 · FlagSparse #117

  • FlagCV：8 コミット、4 マージ。この10-14に作成されたリポジトリの位置づけは、Tritonで書かれたコンピュータビジョン・オペレータライブラリで、インターフェース形状はOpenCVに合わせ、ベースラインはOpenCV CUDAと比較している。#5で独立したOpenCV CUDA add参考アダプタを追加、#6でaddの評価をFlagGems-sglangのpytest契約に合わせ（正確性記録に候補の実測呼び出しを伴い、dummy走査は単独レポート化し、参考検証は候補を回避するケースを拒否）、#7でGEMS_VENDORを使ってデバイスを選択するよう統一。
  • FlagTrain：7マージ、KMCompiler路線でオペレータを引き続き整備。#56で融合したh_post bdaの順伝播・逆伝播を追加、実測でnvidia 1.190倍と1.702倍、PPU 6.714倍と3.568倍、MC550 6.057倍と2.590倍、天数 7.087倍と3.500倍；#57でscaled_masked_softmaxを昇騰、沐曦、摩尔線程、天数に同時接続；#50でquick_gegluのTritonカーネルを追加；#54でオペレータ命名とテスト仕様を統一。
  • FlagGems-vllm：5マージ。#1048で昇騰上でTLEを用いてfused_indexer_weight_scaleを実装、2段パイプライン、4096要素ブロック、UB割り当てとコピーをTLE経由で行い、形状はGLM-5.3-Flashの実呼び出しから取得；#1077、#1080、#1085でXCSマーカーを3箇所連続修正；#1071でsetup.shにFlagGemsをインストールさせる。
  • FlagGems-sglang：8コミット、6マージ。#294で明示的なデバイス選択をGEMS_VENDORに統一、DNN_VENDORは残すがFutureWarningを発し譲位；#289と#290でAMD gfx1100の残余丸めとオペレータ幅を修正。
  • FlagSparse：#117がNCIC-AlphaSparse上流によりマージ、62ファイル、+4809行 -280行、主体はMUSA上のq4と40の最適化の仕上げ。
  • vllm-plugin-FL：#698で0.4.0-devの前向き同期を0.5.0-devへ、0.5.0-devブランチは11-05 10:27にプッシュあり；レビュー中20件。

1.9 周辺基盤：docsのモデル一覧ボットが起票、optestとOpenCourseは小刻みに前進（11-05）

日付：2026-11-05　情報源：docs #575 · optest #39 · OpenCourse #7 · FlagCX #694 · FlagBLAS #159

  • docs：19:01にボットがModelScopeドキュメント更新チケット（#575）を起票、payloadは当日のモデル一覧同期；#542のaihuanxinモデル一覧チケットは引き続きレビュー中。
  • optest：調査期間内に主ブランチへの新規コミットなし（直近は11-04 16:10のNVベースラインスクリプトで停止）、fix_workflow_1104ブランチのプッシュのみ；#39のイメージ問題修正はレビュー中。
  • OpenCourse：#7でHarness Lab資料更新をマージ、2コミット。
  • FlagCX：#694でDefaultBackendに共有Net providerディスパッチを追加；#692のPALでAscendCL / DCMIフォールバック時にPCIトポロジを有効化する件は引き続きレビュー中。
  • FlagBLAS：21:24にnew_ascend_gemmブランチをプッシュ；#159でAscend cgemmを最適化し、アーカイブ済みH100ベースラインに対してスコアリング、引き続きレビュー中。
  • Trident：02:03にプッシュありだが主ブランチへの新規コミットなし、対応する#4のMonad中間層チケットが02:03に更新。

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

2.1 FlagOS 2.2産業事例：中国電信mHCの訓練ロスを25%から12%へ削減（11-05）

日付：2026-11-05　情報源：CSDN FlagOSコラム：一基の計算力カードも遊ばせない

  • リリース：11:23:59 にリリース。タイトルは「一つの計算力カードも遊ばせない：産業パートナーが FlagOS に基づき、多元計算力の実業務への進出を加速」。文中の数字は 2026 人工知能開放計算大会兼衆智 FlagOS 技術大会から取得。
  • 2.2 の一群の数字：九大オペレータライブラリの合計 1454 個のオペレータ；FlagTree は単一リポジトリで 20 社のチップバックエンドをカバー；10 種類のチップ、千個以上のオペレータに跨る全体性能が 27.6% 向上；新モデルの Day0 適配が 12 種類のチップ；コミュニティメンバー 107 社；四半期ダウンロード数 46 万回で、前四半期の 4.76 倍。
  • 中国電信：9 月 17 日にオープンソース化した星辰 Xing4.0-29B-A4B（総パラメータ 29B、活性 4B）は全工程を昇騰 910C クラスタで訓練を完了し、リリース当日に 10 種類の国産チップの精度整合とデプロイ検証を完了した。急所は多チャネル残差オペレータ mHC：N カード公式実装自体が約 10% の速度低下、昇騰の初版は 50% 低下、チームの自研は長期にわたり 25% で停滞していた。FlagOS チームと協力して FlagGems の専項最適化オペレータを MindSpore + CANN + 昇騰 NPU 訓練チェーンに登録した後、クラスタの速度低下は 25% から 12% に抑えられ、当該適配はすでにオープンソース化され MindFormers にマージ済み。
  • 連鎖効果：Agent シーンは平均 prompt 70K、最大 200K。FlagOS に基づき 12 個の長序列オペレータを書き直した後、初回 token 時延が 19.87% 低下、デコード速度が 2 割以上向上；ホットライン音声前処理チェーンは Spectrum 系オペレータを集約して書き直し、華為、摩尔、天数の 3 種類のチップで 10 倍の高速化。
  • 軟通動力：天元智算プラットフォームは token 決済。GLM-5.2 は 4 台の昇騰 910C 上で単一 token 生成 17.79 ミリ秒、一方モデル側が公布した API 准入ラインは 16.13 ミリ秒。FlagOS 接続後に PD 分離（Prefill と Decode が各 2 台のサーバを占有）を有効化し両側最適化を行い、時延を准入ライン内に抑え込んだ。
  • その他のパートナー：輝羲智能、奕行智能、澎峰科技が同場で共有。文章の落点は「国産 AI インフラの成熟度を判断するには、何種類のチップをサポートするかを見るのではなく、新モデルリリース当日に設定を変えるだけで納品可能なスループットを出せるかどうかを見る」。

2.2 端側専場：ARM CPU で大モデルを 21%–25% 高速化、マルチチップ適配が 35 種類のチップをカバー（11-05）

日付：2026-11-05　情報源：CSDN FlagOS コラム：クラウドから端末まで、AI のラストワンマイル

  • リリース：14:10:28 にリリース。端側 AI 向けのインタビューとライブ配信予告で、ゲストは北京智源人工智能研究院の性能最適化エンジニア趙帥。
  • 四つの見どころ：端側 AI がなぜ今落地できるのか（モデルの小型化、計算力の強化、ソフトウェアの成熟）；端、辺、雲の分業、電源接続機器と非接続機器の取捨選択；GPU と NPU に頼らず、純 ARM CPU で MiniCPM、Qwen を百級 token/s で動作、実測口径は SME2 と I8MM、性能向上 21%–25%；FlagOS マルチチップ適配は「一度の最適化、複数デバイスでの再利用」で、21 社のチップメーカー、35 種類のチップをカバー。
  • 口径の違い：ここでの 21 社 / 35 種類は端側とデバイス側の適配統計であり、2.2 大会が公布した 107 社のコミュニティメンバー、12 種類の Day0 チップとは同一の次元ではないため、引用時に混用すべきではない。
  • 判断：端側を単独で取り上げて語ることは、FlagOS の物語が「訓練と推論の雲側マルチチップ」から「デバイス側マルチチップ」へ拡張したことを意味する。これはリポジトリ側で Torch-FL が以前に Apple Silicon MPS パスを補完した方向と一致する。

2.3 チャネル核查：コンポーネント級ゼロヒット、燧原タイトルは核査の結果、上場回顧稿と判明（11-05）

日付：2026-11-05　情報源：Google News RSS · HN Algolia · 智源コミュニティ

  • Google News：24組の中英クエリを24時間の調査期間内で実行し、合計8件の候補が返された。7つのコンポーネント名（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）は中国語クエリではすべてゼロヒット、英語側でもBAAI FlagOSとflagos-aiは同様にゼロだった。
  • メンバー語のヒット：4件は「智源研究院 オープンソース / チップ」クエリから得られ、内容は智源コミュニティが転載した論文解説、イベント報道、他者によるモデル評価であり、FlagOSとは直接関係しない。1件は「燧原科技」の見出し『燧原科技がA株に上場 科創板がDSAアーキテクチャの演算力ピースを補強』で、精査の結果、燧原が9月11日に科創板へ上場（688801）した際の回顧記事であり、調査期間内の新規イベントには該当しないため、このバッチ全体から除外した。
  • HN Algolia：FlagOSとFlagGemsはそれぞれ8件と3件の広範一致が返されたが、直接ヒットはゼロ。BAAIの30件にもFlagOS関連の見出しはなかった。
  • 智源コミュニティ：トップページと検索ページに調査期間内のFlagOS新規投稿はない。検索ページは依然としてクライアントサイドレンダリングのためエントリ一覧を取得できず、トップページによる確認のみを基準とする。
  • 結論：ニュース側では当日、CSDNコラムの2件の新規記事のみ収集可能で、その他のチャネルは増分ゼロ。これは前号の「コンポーネント単位でゼロヒット」という結論と一致し、常態である。

3. メンバー企業とバックエンドベンダーの深掘り

3.1 寒武紀：CNNLがアテンションの順伝播と逆伝播を融合、190回のフォールバックをゼロに（11-05）

日付：2026-11-05　情報源：Torch-FL #748 · Torch-FL #749 · Torch-FL #757 · Torch-FL #754

  • 根本原因：SDPAが寒武紀バックエンドで3つのリーフオペレータに分解されていた。原因はcambriconが複合カバレッジから除外されていたためであり、その結果、アテンションのたびにB×H×S×Sのスコア行列をHBMに書き込んで読み戻す必要があった。#748はCNNLの融合順伝播をカバレッジに戻し、8ファイル、315行追加・27行削除。
  • 順伝播の後に逆伝播を補完：#749はCNNLの融合逆伝播で勾配経路を補い、順伝播とともにC++ autograd Functionに包み、1回の学習呼び出しで前後両パスが融合カーネルを通るようにした。3ファイル、342行追加・112行削除。
  • 網羅的調査による収尾：#757は単一オペレータを見るのではなく、まず完全なQwen3因果言語モデルの学習ステップに対してフォールバックの網羅的調査を行い、残った2つのフォールバックポイント——aten::mul.out 188回とaten::embedding_dense_backward 2回、合計190回——を特定した。両者をMLU上でCNNL経由で実行するよう変更したところ、同一ステップでCPUへのオペレータフォールバックがゼロと報告された。
  • 工程詳細：寒武紀コード生成器にこれら2つのオペレータを追加し、gen_vendor_confs.pyでルーティングを再導出することで、出荷時設定と登録ファイルが互いに矛盾できないようにした。#754はmulのオペランドをデバイス上に留め、ランタイムキューを共用することで、中間結果のホスト往復を回避する。
  • 作者とツール：これら3件のPR本文はいずれもAI agent情報セクションを含み、ツールはdsh（DeepSeek Harness）と別のコーディングエージェント、モデルはdeepseek-v4.1-flashとgpt-6.1-solと記載され、人手レビューは同一メンテナに統一されている。
  • 判断：「動作する」から「ゼロフォールバック」へは学習可用性の分水嶺である。190回のフォールバックのうち188回が同一オペレータ由来であり、この種の収尾は推測ではなく網羅的調査に依存することを示している。

3.2 燧原：GCU300が一夜で25件を清算、NVIDIA外部シンボルを逐次ローカル実装に置換（11-05）

日付：2026-11-05　情報源：FlagGems #8443 · FlagGems #8442 · FlagGems #8441 · FlagGems #8429 · FlagGems #8426 · FlagGems #8417 · FlagTree #1576

  • 規模：25 件のマージ、すべてに KernelGen と Enflame のプレフィックスが付き、署名は同一作者。前号で新規開設された 41 件の GCU300 カバレッジ単はここからバッチ適用が始まる。
  • 修正方法1：外部シンボルの分離。多くの単の主題は「NVIDIA なしの __nv_* 外部シンボルでも動作する」こと——__nv_nearbyintf、__nv_y0f / __nv_y1f、__nv_j0f、normcdfinv などを個別にローカル実装へ置き換え、対応する choose_qparams_optimized、special_bessel_y0/y1、special_bessel_j0、special_ndtri などのオペレータに対応させる。
  • 修正方法2：アルゴリズム経路の変更。special_chebyshev_polynomial_t は専用カーネルに変更；linalg_householder_product は単一パスの反射スキャンを使用；linalg_inv_ex は単一カーネルの Gauss-Jordan を使用；compute_linear_combination は外積を tl.dot に置き換え；mixed_dtypes_linear はパッキングとブロッキングを書き換え。
  • 修正方法3：不適合なコンパイル時機能の除去。renorm_ の自動チューニングは本バックエンドのコンパイラを直接中止させるため、セクション全体を破棄；fake_quantize シリーズは magic-add 丸めに変更し、extern 依存を回避；adaptive_avg_pool3d_backward、cholesky_inverse、linalg_tensorinv の起動パラメータはホスト側で計画するよう変更。
  • 修正方法4：起動ジオメトリの修正。special_i1e、special_modified_bessel_k0 の launch geometry を個別に修正し、linalg_householder_product の batch-norm 機能カーネルジオメトリも併せて修正。
  • コンパイラ側：#1576 新規開設、TLE の SoC レベルでの分散強化を行い、オペレータレベルの書き換えをコンパイラ能力へ一歩移行させる。
  • 判断：この路線の方法は「上流の書き方」を「本バックエンドがサポートする書き方」に翻訳し、個別に清算すること。代償は PR 数が多く単件の変更が小さいこと；利点はカバレッジが2週間で数十のオペレータから千以上に拡大できること。

3.3 海光：HCU の TLE-Raw と BF16 エキスパート GEMM の2路線が並行（11-05）

日付：2026-11-05　情報源：FlagTree #1508 · build-infra #1654 · TransformerEngine-FL #153 · FlagAttention #123 · FlagGems #8446

  • コンパイラ側：#1508 で HCU が tle.raw をサポート、53 ファイル、5106 行追加；HIP と MLIR の両ソース、eager と deferred の両モードをサポートし、DUSHMEM のストリーミング集合通信に接続、3つのチュートリアル（ring shift、allgather GEMM、GEMM allreduce）を添付。
  • ビルド側：#1654 で build-infra 内の flagtree の HCU ビルドに2つの LLVM ツリーを同時に敷設し libzstd-dev を補完、HCU の LLVM バージョンが単一ツリーに収束していないことを示す。
  • トレーニング側：TransformerEngine-FL #153 新規開設、Qwen3.5-35B にオプションの BF16 エキスパート GEMM 経路を追加（opt-in、デフォルト動作は変更しない）。
  • アテンション側：FlagAttention #123 の AttnRes バックエンドは審査中、海光アテンションの新オペレータ方向に属する。
  • 命名：FlagGems #8446 で海光のバックエンドキーを hygon-dtk2604 に決定、DTK 26.04 とバインド；前号で記録した 2.3.0 カバレッジには DTK 26.10 の路線も存在。
  • 判断：海光の当日の2つの動きは異なるレベルに属する——TLE-Raw はコンパイラをベンダーの手書きカーネルに開放し、BF16 エキスパート GEMM はトレーニング性能を押し下げる。前者は一回性の投入が大きく、後者は直接モデルに対応する。

3.4 昇騰：Flash Attention の UB オーバーフロー修正、varlen 前方と D=256 を補完（11-05）

日付：2026-11-05　情報源：FlagGems #7581 · FlagGems-vllm #1048 · FlagGems-vllm #1077 · FlagBLAS #159 · FlagCX #692 · FlagTree #1507

  • Flash Attention：#7581 はフォワードとバックワードの UB オーバーフローおよびバックワードのコンパイル問題を修正し、5 ファイル、1865 行追加、286 行削除。手法はフォワードとバックワードのタイル分割とバッファに上限を設け、dQ と dK/dV を別々にコンパイルしつつ、FP32 累積、テール処理、GQA 勾配リダクションを維持する。
  • 2 項目の機能を補完：昇腾の varlen フォワードを新規追加して登録；dense D=256 に対して、まず連続した [N, D] 順で K をロードしてから転置して QK を計算し、フォワードの KV タイルを拡大、さらに dQ の query タイルのみを拡大し、dK/dV は引き続きバッファ上限内に保つ。
  • 境界アラインメント：causal の全マスクとマスク領域を KV タイル境界にアラインメントし、BLOCK_N が BLOCK_M より大きい場合のタイル重複を回避する。
  • 回帰：CPU リファレンスのフォワード回帰を追加し、FP16 と BF16、causal と非 causal、パディング付きヘッド次元、シーケンステール、GQA をカバーする。
  • 推論側：#1048 は TLE で融合された indexer 重みスケーリングオペレータを実装し、2 段パイプライン、4096 要素タイル、UB 割り当ては TLE を経由し、FP32 出力を維持；形状は GLM-5.3-Flash から取得。同日の 3 件の XCS マーク修正で perf 入力とマークをアラインメントした。
  • その他：#159 は Ascend cgemm を最適化し、アーカイブされた H100 ベースラインに対してスコアリング（審査中）；#692 は PAL が AscendCL と DCMI フォールバック下で PCI トポロジを有効化（審査中）；#1507 は昇腾 3.5 コンパイラが triton_key をエクスポート（審査中）。

3.5 摩尔線程、天数、沐曦、昆仑芯、清微と玄鉄：行列積とレイアウトをバッチで推進（11-05）

日付：2026-11-05　情報源：FlagGems #7246 · FlagGems #6706 · FlagGems #8028 · FlagGems #8287 · Torch-FL #745 · FlagAttention #127 · FlagAttention #119

  • 摩尔線程：#7246 で MP31 上の mm を書き換え、単一ファイルで 2472 行追加・146 行削除——dtype、規模、NN/NT レイアウトに応じて GEMV、split-K、TME/SQMMA パイプライン、persistent パスの間で経路を選択。FP32 はベクトル×行列専用パス、TF32x3 ブロック GEMM と split-K へ、FP16/BF16 は TME 転送と SQMMA 計算による warp specialization へと進み、TMECachePolicy でキャッシュ常駐ヒントを設定。#6706 では bmm と bmm.out に形状認識型の TLE/SQMMA 実装を追加（9 ファイル、2369 行追加）。これには FlagTree のセグメント化 SPMC パイプライン v2 が配套として必要。#1572 では FlagTree 側で dot 変換が明示的な blocked レイアウトを保持するようにした。
  • 天数：#745 で Iluvatar のオペレータ上限を開放し、mul.Tensor が FlagGems に載るようにした。#753 と #762 はレビュー中で、ixblas axpy で add ファミリーを統一的に受け持つ。CI 側では FlagScale #1322 と Megatron-LM-FL #213 がともに Iluvatar パイプラインを補完中。
  • 沐曦：#57 の scaled_masked_softmax が沐曦をカバー。FlagGems 側では #8414 の layernorm、#6811 の C550 行列積、#6807 の addmm/router GEMM が引き続きレビュー中。FlagTree #1496 で FlagPrism に最小限の MetaX 統合を追加、#1471 で CommonIR set_layout とレイアウト自動チューニングを補完。FlagAttention #119 で Parallax の prefill と decode を追加。
  • 崑崙芯：#8028 で 4 つのオペレータが 0.8 以上の Gems Speedup しきい値に到達、#8393 で cholesky 求解ヘルパーなど XPU カバレッジを補完。Torch-FL #756 で 3.2 GB の FlagTree wheel を pip キャッシュの外に追い出した。
  • 清微：#8287 でバックエンドを 1103 に更新、190 ファイル、23195 行追加・914 行削除で、当日最大の単一バックエンド同期。バックエンドキーは tsingmicro-tsm260610 に確定。
  • 玄鉄：FlagAttention #127 を新規作成し、PPU-ZW810E 向けに Wall Attention を追加・最適化。FlagGems #8446 のバックエンドキーは thead-ppu210 に確定。#8489 を新規作成し、昇騰、摩尔線程、玄鉄の三者向けに convolution_backward を修正・最適化。
  • 地平線：本調査期間内にコミットなし。BPU ラインは前回（11-04）にチェーン実行とオペレータライブラリの修正を完了したばかりで、今回は新規なし。

4. 総括とトレンド観察

日付：2026-11-05 ~ 2026-11-06　情報源：flagos-ai 組織 · 本期各項目の PR リンク（付録参照）

  • 一言で言うと：この日の主軸は「収束」だった——燧原が25件のGCU300書き換えチケットを一気に片付け、寒武紀が融合アテンションの順伝播・逆伝播を補完し訓練ステップのロールバックをゼロに戻し、コミュニティは7件のFEPをレビューに送り出し、2.3の11-13締切に向けた準備を進めた。
  • 観察1：ペースは落ちたが、方向はむしろ明確に。コミットは238→123、マージは167→94だが、具体的なリポジトリに落とすとどれも「最後の一段を補完する」ものだ：Torch-FLは逆伝播を補完し、FlagGemsは清算し、FlagTreeはベンダー手書きカーネルの口を開けた。量を積み上げる段階が終わった後の収束日であり、産出は少なく見えるが、可用性の前進はより直接的だ。
  • 観察2：FEPバッチは2.3スコープの実際の境界。7件の新FEPは同じ一件事を指し示す——「マルチバックエンド能力」を検収可能な項目として書き出すこと：FlagMega v0.1のMegaKernelコンパイル、TLE Rawの5バックエンド、FlagPrism v0.2のマルチバックエンドデバッグ、FLIRの昇騰とGPGPU上での最適化。すべてProvisional Draftであり、GPU検収を未実施と明記していることは、これがスコープ宣言であり完成宣言ではないことを示す。実際のハード境界は11-13のマージ締切だ。
  • 観察3：バージョンエンジニアリングが「監査可能な退役」を始めた。cuda12.8はtorch 2.13がcu128 wheelを出さなくなったため凍結され、その方法はenabledフィールドを追加してfalseに設定し、仕様とドキュメントを保持し、唯一のリゾルバにそれを全マトリクスから除外させるというものだ。凍結は削除でも放任でもない——この書き方は他のバックエンド退役にも再利用する価値がある。
  • 観察4：CI容量がFlagQuantumの主要な作業になった。27件のコミットに量子アルゴリズムは一つもなく、すべてはホスト型ランナーの容量、イメージ資格、カバレッジパーティション、キャンセルセマンティクスを整理するものだ。耐障害コンパイルブランチには既に276ファイル、3.1万行の統合チケットがあり、テスト基盤が追いつかなければ空回りするだけだ。
  • 観察5：AI agentが主なコミッターであり、ボトルネックはレビュー。94件のマージのうち25件が同一agentセッションによるもので、PR本文にはツール、モデル、人的レビューのフィールドが付いている。レビュー側の審査中プールには依然255件、新規87件があり、FlagGemsとFlagTreeの2リポジトリで6割を占める——書くことはもはやボトルネックではない。
  • 要観察：7件のFEPが11-13までに取り込めるか；FlagGemsの審査中プールが燧原の清算とともに減るか；FlagQuantumの耐障害コンパイル統合チケットがいつ草稿から正式レビューに移るか；cuda13.3のラインが2.3.0 rc0（11-30）前に再びtorchバージョンを動かすか。

付録：情報源検証表と完全な情報源リスト

情報源検証表

情報源 検証結果
flagos-ai組織リポジトリ（61リポジトリ） 21リポジトリが調査期間内にプッシュ；メインブランチの新規コミットはFlagGems、FlagQuantum、Torch-FL、build-infraの4リポジトリに集中
コミット検索（committer-dateウィンドウ） 123件ヒット、12リポジトリに分布；FlagGems 33、FlagQuantum 27の2リポジトリで48.8%
マージPR検索（mergedウィンドウ） 94件ヒット、14リポジトリ、32名の作者から；FlagGems 33、build-infra 12、Torch-FL 12が上位3位
審査中PR検索（updatedウィンドウ） 255件ヒット、うち新規87件；FlagGems 84、FlagTree 71の2リポジトリで60.8%
Release / Tag原子検証（31リポジトリ + 8リポジトリ） ウィンドウ内の新規はゼロ；直近は依然FlagCX v0.14.1（11-01）
Google News RSS（24組の中英語クエリ） コンポーネント名7組はすべてゼロヒット；メンバー語8件の候補は検証の結果コミュニティ転載、イベント記事、上場回顧記事と判明し、バッチ全体を除外
HN Algolia（8組のクエリ） FlagOS 8件、FlagGems 3件の曖昧マッチ、直接ヒットはゼロ
CSDN FlagOSコラム トップページ15記事を逐次時間確認：2記事の新着がウィンドウ内（11-05 11:23と14:10）、残りは8月から10月の旧記事
智源コミュニティ 検索ページはクライアントレンダリングで取得不可；トップページのウィンドウ内にFlagOS関連の新規投稿なし
2.3リリースリスト（community release/2.3） ディレクトリにはリリースタイムテーブルのみ；リストファイルは計画通り11-30の機能凍結時に生成

完全な情報源リスト

[22] FlagGems #8287（清微バックエンド 1103 へ更新） — https://github.com/flagos-ai/FlagGems/pull/8287

） — https://github.com/flagos-ai/Torch-FL/pull/748

** FlagGems-vllm #1071（setup.sh で FlagGems をインストール） — https://github.com/flagos-ai/FlagGems-vllm/pull/1071