調査期間：2026-10-29 06:00 ~ 2026-10-30 06:00（北京時間、24 時間；金曜朝報、期間は前回デイリーレポートの締め切り時点から継続）。

情報源：GitHub（org: flagos-ai 61 リポジトリ全量核查、コミット検索 189 件、マージ済み PR 183 件と審査中 PR 253 件の検索、org イベントストリーム 100 件、31 リポジトリの Release/Tag 原子核查、5 リポジトリの原子補核とブランチ照合、主要 PR 本文と成果物規模の核查）、Google News RSS（24 組の中英文クエリ語、プロキシ経由）、HN Algolia（8 組）、CSDN FlagOS コラム（記事とライブ配信項目をページごとに時刻確認）、智源コミュニティ、八社のメンバー企業公式サイト（詳細は付録の情報源リストを参照）。

本期インデックス

  • 今日の重点：海光 DTK 26.10 の三系統接続（コンテナ、コンパイル、通信）；MiniCPM-OCR 双モデル Day0 で 12 プラットフォームをカバー；テスト基盤 ref-as-candidate の双リポジトリ実装（10-29）
    1. オープンソースプロジェクトの進展（GitHub 動向）
      • 1.1 組織のリズム：21 リポジトリでプッシュ、189 コミット、183 マージ済み、審査中 253 件（10-29 ~ 10-30）
      • 1.2 バージョン面：FlagTree が清微 3.6 専用番号を発行、FlagCX v0.14.1 がタグから wheel ラインへ（10-29）
      • 1.3 FlagGems：KernelGen が 1 日で 22 オペレータをマージ、昆仑芯 XPU3 foreach 融合が完了（10-29）
      • 1.4 テスト基盤：ref-as-candidate の双リポジトリ実装、1 日で 57 件のテスト PR を収束（10-29）
      • 1.5 推論と訓練スタック：GLM-5.3-Flash と Qwen3.8-Flash の双モデルがプラグインに進出（10-29）
      • 1.6 コンパイルと通信：摩尔線程の常駐 GEMM と SPMC がメインラインに進出、FlagCX が二社のデバイスインターフェースを補完（10-29）
      • 1.7 ビルドとリリース：海光 DTK 26.10 の八件マージ、昇騰 rpm ターゲットと 2.3.0 イメージ説明（10-29）
      • 1.8 量子ライン：FlagQuantum の六十件コミット、CS-01 から CS-07 の合成パイプラインが貫通（10-29）
      • 1.9 その他のリポジトリ：OpenCourse 教材の再編、FlagScale と TransformerEngine-FL の CI 収束（10-29）
    1. 報道とエコシステム
      • 2.1 MiniCPM-OCR 双モデル Day0 が 12 プラットフォームに適合、達摩院玄鉄のスループットがネイティブの 98.7% に到達（10-29）
      • 2.2 CSDN 技術ライブ配信：1 つのプラグインで十種のチップの推論適合を貫通（10-29）
      • 2.3 チャネル核查：HN と智源コミュニティに新規ヒットなし、CSDN コラムに記事 1 本とライブ配信 1 本を追加（10-29）
    1. メンバー企業とバックエンドベンダーの深掘り
      • 3.1 海光：DTK 26.10 のコンテナから wheel までの全チェーン実装（10-29）
      • 3.2 清微：Triton 3.6 バックエンドを同期マージし専用タグを発行（10-29）
      • 3.3 昆仑芯：XPU3 の foreach 融合チェーンと定数グリッドの収尾（10-29）
      • 3.4 沐曦：グループ化 GEMM の INT8 と FP8 パス、TP2 デコードスケジューリング（10-29）
      • 3.5 摩尔線程：TLE 常駐 GEMM と SPMC を同期してメインラインに進出（10-29）
      • 3.6 燧原、昇騰、達摩院玄鉄：注意力と正規化オペレータの四本のライン（10-29）
      • 3.7 天数：天垓 300 の初回実機デモを对外公開、単カードスループットは H200 の 1.05 倍と宣称（10-28）
    1. まとめとトレンド観察
  • 付録：情報源核查表と完全な情報源リスト

今日の重点：海光 DTK 26.10 の三系統接続（コンテナ、コンパイル、通信）；MiniCPM-OCR 双モデル Day0 で 12 プラットフォームをカバー；テスト基盤 ref-as-candidate の双リポジトリ実装（10-29）

日付：2026-10-29　出典：build-infra PR #1554 · build-infra PR #1562 · build-infra PR #1563 · MiniCPM-OCR Day0 適合 · FlagGems PR #7630 · FlagGems-sglang PR #249（全量は付録を参照）

  • ビルド面：海光 DTK 26.10 が1日で8件のマージを完了した——ベースコンテナ（#1554、78行追加）、ランタイム設定（#1555、21行追加）、可用性修正（#1558、/opt/dtk を dtk-26.10 に指向させ runner カバレッジを補完）、FlagTree の cp312 hcu ビルダー（#1562、4ファイル342行追加）、FlagCX の dtk2610 wheel ライン（#1563、3ファイル185行追加）、ベースイメージへの libopenmpi3t64 追加（#1564）、ビルダーへの libopenmpi3 追加（#1565）、hcu-dtk2610 を FlagTree wheel リリースラインへ追加（#1566）。これは本スタックが新バージョンのベンダー SDK 向けにコンテナ、コンパイラビルダー、通信ライブラリパッケージングの3ラインを同時に改修した初のケースである。理由は DTK 26.10 がランタイムを python 3.12 と torch==2.13.0+dtk2610（cp312 のみ）に固定しており、既存の cp310 の hcu wheel はこのランタイムではまったく解決できないからである。
  • ニュース面：衆智 FlagOS コミュニティが面壁智能と OpenBMB がオープンソース化した MiniCPM-OCR 1.0（1.3B）と MiniCPM-OCR Jev（2B）向けに Day0 クロスチップ適配を実施し、達摩院玄鉄、英偉達、華為昇騰、海光、崑崙芯、沐曦、摩尔線程、清微智能、天数智芯、曦望、Mac（ARM）、此芯科技の計12プラットフォームをカバーした。評価の指標はハードウェアピーク演算力に正規化したスループットである：Jev は達摩院玄鉄上での実計算スループットが英偉達ネイティブの98.7%に達し、OCR 1.0 の単位ピーク演算力あたり P50 スループットは単一ドキュメント場面で英偉達ネイティブの169.3%、バッチ場面で137.1%に達した。
  • テスト面：FlagGems の --ref-as-candidate と明示的な get_candidate 選択がメインラインに入った（#7630、9ファイル）。FlagGems-sglang は同日 #239 から #249 までの11件で全正確性スイートを get_candidate に移行し、毎日 master から kernelgen-dev への自動同期 PR を追加した。両リポジトリを合わせた効果は次のとおりである：参照実装が外部候補ファイルなしでそのまま候補として実行できるようになり、テストは「オペレータがあるか否か」のスイッチではなく「参照と実装が一致するか」の比較になった。
  • 所見：3つのラインは同じことを指している——ソフトウェアスタックのボトルネックは「オペレータを書き出す」ことから、「新 SDK のビルド前提、参照実装の実行パス、モデルのクロスチップ比較可能性」という3種類のエンジニアリング規律を固定することへ移りつつある。DTK 26.10 の8件のマージは、ハードウェア世代切り替えのコストがほぼすべてパッケージングと依存解決に落ちており、カーネル自体にはないことを示している。MiniCPM-OCR の評価は初めて、正規化スループットと端側レイテンシという2組の比較可能な数値を提示した。

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

1.1 組織のリズム：21リポジトリへのプッシュ、189コミット、183マージ、レビュー中253件（10-29 ~ 10-30）

日付：2026-10-29 ~ 2026-10-30　情報源：flagos-ai 組織リポジトリ · コミット検索 · マージ済み PR 検索 · レビュー中 PR 検索

  • リポジトリ面：61 リポジトリのうち 21 リポジトリが期間内にプッシュあり（前回 23 リポジトリ）。プッシュ時刻が近い順に FlagGems、Torch-FL、FlagGems-sglang、FlagQuantum、vllm-plugin-FL、FlagQAI、FlagTree、FlagScale、OpenCourse、build-infra、FlagCX、FlagGems-vllm、FlagSparse、release-info、docs、optest、FlagTrain、FlagOps、FlagFFT、FlagAttention、TransformerEngine-FL。
  • コミット面：コミット検索ヒット 189 件、直近 2 週間で最高（前回 99 件）。リポジトリ別では FlagQuantum 60、FlagGems 43、build-infra 15、FlagGems-sglang 14、FlagQAI 11、FlagGems-vllm 9、FlagAttention 8、Torch-FL 6、FlagTree 5、FlagTrain 4、vllm-plugin-FL、FlagCX、OpenCourse 各 3、optest、FlagOps 各 2、FlagScale 1。FlagQuantum と FlagGems の 2 リポジトリで 103 件を占めた。
  • マージ面：マージ PR 183 件（前回 67 件、1.7 倍増）。リポジトリ別では FlagGems 92、build-infra 16、FlagQuantum 15、FlagGems-sglang 11、FlagGems-vllm 9、FlagAttention 8、Torch-FL 6、FlagTree 5、vllm-plugin-FL 4、FlagQAI 4、FlagCX 4、FlagTrain 4、optest 2、FlagScale、FlagOps、TransformerEngine-FL 各 1。
  • レビュー中面：期間内に更新のあったレビュー中 PR 253 件（前回 288 件）、新規 84 件（前回 101 件）。FlagGems 129、FlagTree 22、FlagGems-vllm 15、vllm-plugin-FL 10、Megatron-LM-FL 10、FlagTrain 9、FlagAttention 8、FlagScale 7、sglang-plugin-FL 6、Torch-FL 5、FlagGems-sglang 5、flir 5、FlagCX 4、docs 4、その他各リポジトリ 1 から 2 件。
  • ペース比較：前回の 24 時間ウィンドウ（23 リポジトリ、99 件コミット、67 件マージ、288 件レビュー中）と比較すると、プッシュリポジトリは 2 減、コミットは 91% 増、マージは 173% 増、レビュー中は 12% 減、新規は 17% 減。マージ量の跳ね上がりは主に FlagGems のオペレータ増量（92 件）と FlagQuantum の合成パイプライン（15 件）によるもので、レビュー基準の緩和ではない——同期間のレビュー中総量は依然として減少している。
  • リリースとイベント面：31 リポジトリの Release と Tag を原子的に核查、期間内に新規タグ 1 件（FlagTree の清微 3.6 専号、10-29 11:09）。FlagCX v0.14.1 のアーカイブ時刻が 10-29 10:55 に前倒しされ、#683 の 0.14.0-rc2 へのバックポートのマージ時刻と同時刻。org イベントストリーム 100 件：PR レビューコメント 34、PR イベント 34、プッシュ 13、ブランチ作成 8、イシューコメント 9、ブランチ削除 1、fork 1。構成比は前回（プッシュ 51、ブランチ作成 32）から明らかにレビュー活動へと転換しており、マージ量の上昇と一致する。
  • ブランチ面：コミット検索がカバーしなかった 5 つのプッシュリポジトリを原子的に補核——TransformerEngine-FL は期間内にコミット 1 件（#142 の FlagCICD v1、10-29 09:51）。FlagFFT のプッシュは codex/musa-shortfall フィーチャーブランチに該当（10-28 に複数回プッシュ、デフォルトブランチの最新コミットは依然 10-15）。release-info のプッシュは gh-pages ブランチ（リリースサイトの自動公開）。docs と FlagSparse は PR ブランチとイシューコメントの活動であり、デフォルトブランチに新規コミットはない。

1.2 リリース面：FlagTree が清微 3.6 専号を打ち出し、FlagCX v0.14.1 はタグから wheel ラインへ（10-29）

日付：2026-10-29　情報源：FlagTree 清微 3.6 専用タグ · FlagTree PR #1459 · build-infra PR #1553 · build-infra PR #1556 · build-infra PR #1563

  • FlagTree タグ：10-29 11:09 に清微 3.6 専用タグが作成され、10-26 の摩尔線程 3.6 専用タグと同じ「ベンダー別に分割された 3.6 プレリリース線」に属する。このタグは Releases API にリリース本文を持たない（404 を返す）ため、説明付きの Release ではなくタグアーカイブであることがわかる。同日マージされた #1459 は、まさに清微バックエンドを内部 Triton 3.6 開発線へ同期するコミットである。
  • FlagCX のデリバリー面：v0.14.1 は前回の調査期間に git タグとして出現し（Release 本文なし）、今回の調査期間に正式に build-infra の wheel ディレクトリへ登録された——ボットがリリースを記録し（#1553）、人手で五つの空の説明を補完して flagcx==0.14.1+rocm7.2.4 という AMD 行を追加し（#1556、10 ファイルで 28 行追加・16 行削除）、さらに hygon-dtk26.10 のラインを flagcx==0.14.1+dtk2610 に固定した（#1563）。これにより 0.14.1 のデリバリー面は cuda12.8、cuda13.3、corex4.4.0、corex4.5.0、xre5.37.1、rocm7.2.4 と新規追加の dtk2610 をカバーする。
  • Issue 駆動の修正：FlagTree #1481 は議題 #1473 に対応して Metax 上の CompiledKernel のメタデータチェックを修正し（1 ファイル、2 行追加・1 行削除）；FlagGems #7989 は昇騰の cat オペレータを修正し（57 行追加・36 行削除）；FlagTree #1468 と #1470 は燧原向けに CI と TLE 単体テストを追加した。
  • 要観察：FlagTree の 3.6 ラインは「ベンダーごとに一つのタグ」という方式で進められており、0.7.1a1 には統一されたリリースノートがまだない。もし 2.3 周期がこのラインに沿ってデリバリーされるなら、下流はタグ名からバックエンドと Triton のバージョンを逆算する必要があり、FlagCX v0.14.1 に本文が欠けているのと同じ種類の問題である。

1.3 FlagGems：KernelGen が 1 日で 22 個のオペレータをマージ、昆仑芯 XPU3 foreach 融合が完了（10-29）

日付：2026-10-29　情報源：FlagGems PR リスト · PR #7116 · PR #6950 · PR #6530 · PR #7989

  • KernelGen面：92件のマージのうち22件は[KernelGen][Nvidia]で自動生成されたオペレータであり、疎テンソル（sparse_csc_tensor_unsafe、sparse_bsc_tensor_unsafe、sparse_resize_）、畳み込みとプーリング（nnpack_spatial_convolution、thnn_conv2d、fractional_max_pool3d_backward、mkldnn_reorder_conv2d_weight）、線形代数（cholesky、frobenius_norm、chain_matmul）、そして一群の細かいオペレータ（argwhere、_indices、make_dual_copy、flatten_dense_tensors、combinations、empty_per_channel_affine_quantized）をカバーしている。単日でのバッチ処理はこのラインで最近最も密な回であり、同日にはさらに#8009から#8013の5件が新規に開かれ、キューはなお継続している。
  • 昆仑芯面：XPU3のforeach融合チェーンが1日で収束した——cos/exp/sin/addcdiv/lerpのListエグゼキュータ（#7116）、ceilのマスクなし融合カーネル（#7604）、tanh/expm1のインプレース融合カーネル（#7608）。続いて4件の正確性修正：fminを定数発射グリッドに変更（#7966）、t_copyの一次元パスも同様に定数グリッドに変更（#7973）、foreachスカラーdtype分岐を相互排他に変更（#7974）、foreach addのリストスロットをprogram_id(0)から取得するよう変更（#7968）。euclidean_dist、is_same_size、layer_norm_backwardもXPU最適化を行った（#7907）。
  • 沐曦面：INT8とFP8のgrouped_mm_w8a8を新規追加（#6950、7ファイルに1220行追加）。ベンチマークはGLM-5.2をPPU SGLang TP=8上で収集した実際の呼び出し形態をMetaX C550に再生して実施——28件のシーン記録、26組のユニークな(M,N,K,E)幾何、324万回の呼び出し、257個のエキスパート。
  • その他：AMD W7900（gfx1100）のオペレータ精度修正（#6530）、昇騰log_グリッド充填再実行のベンダーローカル実装を5.4.0-rc2に再マージ（#6586）、CI側でインポート順序の修正（#7951）、リリースビルドを削除されたcp38からcp310に変更（#7975）、ベンダー名をランタイムバージョンに追随させるよう変更（#7961）、FP8 MMテストを登録済みバックエンドに応じてスキップするよう変更（#7812）。
  • 判断：オペレータの物量はすでにKernelGenが担っており、人手の投入は二種類の事柄に集中している——新バックエンドの発射パラメータの正確性（昆仑芯の4件）とテストの実行可能性（1.4参照）。これが92件のマージの中で主干の意味的変更がほとんどない理由である。

1.4 テスト基盤：ref-as-candidateのデュアルリポジトリが実現、単日57件のテストPRが収束（10-29）

日付：2026-10-29　情報源：FlagGems PR #7630 · FlagGems-sglang PR #239 · FlagGems-sglang PR #241 · FlagGems-sglang PR #249 · FlagGems-sglang PR #242

  • メカニズム：--ref-as-candidate により、正確性テストとベンチマークは明示的に宣言された参照実装を候補として実行できる（get_candidate("negative", reference=torch.negative)）。外部候補ファイルに依存しなくなる。参照欠落、参照が呼び出し不可、テスト本体が実際に候補を呼び出していない場合は明示的に失敗する。スキップと xfail は契約エラーを隠蔽できず、全スキップは有効な実行として計上されない。検証は 26 項目のホスト回帰に加え、master と PR マージプレビューに対する 32 項目のチェックで構成される。
  • 適用範囲：FlagGems-sglang は同日 11 件で全正確性スイートを get_candidate に変更し（#241）、参照宣言を補完し（#240、#244）、ベンチマークケースの列挙とリプレイを追加し（#239）、definitions ディレクトリと silu_and_mul の例を追加し（#245）、mrotary_embedding の候補比較と可搬参照およびクロスデバイスネイティブ検証を補完した（#247、#249）。
  • 規模：単日 57 件が同一作者によりコミットされたテスト修正がマージされた（多くは各バックエンドの参照契約、フィクスチャ、ベンチマークエントリの修正）。昇騰、沐曦（MUSA）、燧原、昆仑芯、英偉達のスキップ条件と参照 ABI をカバーする。
  • 自動化：毎日 master から kernelgen-dev への自動同期 PR を新設し（#242）、当日ボットは既に 2 件の同期を生成した（#243、#246）。このチェーンにより「上流メインライン」と「KernelGen 開発ライン」の乖離は、手動 rebase から毎日 1 回の監査可能なマージへと変わった。
  • 判断：テストが「通る」から「比較可能」へ移行した後、テスト自体が参照実装の契約を必要とし始めた。これこそが本日 57 件の修正の実質的な内容であり、テストを補うのではなく参照を補うことである。

1.5 推論と訓練スタック：GLM-5.3-Flash と Qwen3.8-Flash のデュアルモデルがプラグインへ（10-29）

日付：2026-10-29 ~ 2026-10-30　情報源：vllm-plugin-FL PR #455 · vllm-plugin-FL PR #454 · vllm-plugin-FL PR #615 · FlagTrain PR #35 · FlagGems-vllm PR #1025

  • Qwen3.8-Flash：vllm-plugin-FL に Qwen3.8-Flash-Next と Qwen4 のチェックポイント読み込みとモデル統合を追加（#455、65 ファイル 11226 行追加 109 行削除）。HC、PLE、QSA とマルチモーダル配線を含み、数値オペレータは FlagGems-vllm を使用。FP8 は能力ゲーティングを採用：プラットフォームがネイティブ対応ならネイティブカーネルを維持（NVIDIA は計算能力 8.9 以上を要求、AMD は vLLM の ROCm 実装の判断に委ねる）、非対応時は BF16 線形と MoE パスにフォールバックし --dtype bfloat16 を強制。
  • GLM-5.3-Flash：翌日未明に純公開オペレータの実装をマージ（#454、90 ファイル 19140 行追加 280 行削除）。インデクサ精度はキャッシュ割り当てより先に選定：NVIDIA SM89 以上、摩尔線程 MP31 以上と GCU capability 4 以上は FP8 を維持し、その他のベンダーと未知の能力は BF16 を使用；BF16 の沐曦と昆仑芯は対応する radix コンパイルパスが降格できないため、既存の Torch TopK、scatter、sort パスに切り替え。
  • 実行面：ネイティブ CUDA の vLLM 0.32 適配（#615、57 ファイル 3408 行追加 1044 行削除）はスタックを vLLM 0.32.0+cu129、PyTorch 2.13.0+cu129、CUDA 12.9、python 3.12.3 に固定し、FlagGems は 5.4.0 開発コミット、FlagTree は 0.7.0 開発コミット（Triton 3.6 を提供）を使用；既存の NVIDIA CI は推論 6 項目とサービング 3 項目すべて合格。
  • 訓練面：FlagTrain に multi_tensor_adam を追加（#35、6 ファイル 1093 行追加）。1 回の Triton 起動で複数テンソルの Adam 更新をバッチ完了し、バックエンドは NVIDIA、海光、沐曦、PPU（達磨院玄鉄）と天数をカバー；同一調査期間に fused_proj_rms の前方・後方（#38）、fast_gelu（#33）、deepspeed 依存（#42）も存在。元の H20 ベンチマークでは、fp32 65536 要素の档位は DeepSpeed CUDA ベースラインに対して 2.24 倍、1024 要素の小档位は逆に 0.76 倍まで遅くなる。
  • 推論最適化：FlagGems-vllm 側では、沐曦 TP2 packed decode の Split-KV スケジューリングと計算 tile 再配置（#1025）；FP8 W8A16 のゲーティング増分ネットワークと動的状態量子化（#988）；MUSA の FP8 可変長アテンションを現在の CI コンパイラに合わせて再調整（#970）；fused_q_kv_rmsnorm は昇騰（#872）と達磨院玄鉄（#888）で同時に実装。

1.6 コンパイルと通信：摩尔線程の常駐 GEMM と SPMC がメインライン入り、FlagCX が 2 社のデバイスインターフェースを補完（10-29）

日付：2026-10-29　情報源：FlagTree PR #1294 · FlagTree PR #1459 · FlagCX PR #678 · FlagCX PR #681 · FlagCX PR #679

  • 摩尔線程：[MThreads][TLE] の常駐 GEMM パイプラインと SPMC 同期をメインラインに進めた（#1294、63 ファイルで 6192 行追加・403 行削除）。このコミットは古いファイルの移行ではなく、現在の main の pipe、warp specialize、SQMMA 表現に基づく再移行であり、従来 2 系統に分かれていたコンパイラ（公共版は addmm/baddbmm、SPMC 版は bmm を提供）を 1 つのスーパーセットに統合した。動的ループ内の stage と phase の推進、1 プロデューサ対多コンシューマ、名前付き読み取りと暗黙読み取り、セグメント完了とコンシューマエポック導出、さらに単発発行、融合コンシューマ、16 warp 常駐パスをサポートする。
  • 清微：バックエンドを内部 Triton 3.6 開発ラインに同期（#1459、27 ファイルで 2264 行追加・407 行削除）。third_party/tsingmicro/ のみを変更し、FlagGems 側のベンダーオペレータ配信に必要な発行単位の精度インターフェース、外部 CoreIR エントリ、ランタイムアダプタを補完し、Tx81 のコード生成と DMA、RDMA、WDMA の CRT 欠陥を修正した。
  • 昆仑芯：FlagCX に XPU のデバイス IR エントリを追加し FlagTree リンクをサポート（#678、5 ファイルで 178 行追加・21 行削除）。
  • 天数：FlagCX の Device API バックエンドに Atomic::load の取得セマンティクスを補完（#681、3 ファイルで 359 行追加・37 行削除）。従来は load(..., Acquire) と load(..., Relaxed) が同一の命令を発行しており、オブザーバがフラグを観測した後に無効化バリアが存在しなかった。本コミットでは読み取り後フェンスに変更し、スコープに応じて強度を選択し、launchKernel のアドレス空間記号と getLastError スロットを補完した。システムスコープは未実装のままで、ivcore11 に対応するメモリバリア命令が存在しないためである。
  • AMD：ROCm 上で SGLang のテンソル並列を動作させた（#679、6 ファイルで 77 行追加・19 行削除）。eventElapsedTime 実装を補完し、torch.bool を flagcxUint8 にマッピングし、USE_AMD テストビルド分岐を追加した。R9700 デュアルカード上で AllReduce、ReduceScatter、AllGather、Broadcast、Send/Recv およびグラフキャプチャの AllReduce 結果が正確であり、Qwen3.5-9B と Qwen3.6-35B-A3B-FP8 が TP=2 でサービス提供可能である。

1.7 ビルドとリリース：海光 DTK 26.10 の 8 コミット合入、昇騰 rpm ターゲットと 2.3.0 イメージ記述（10-29）

日付：2026-10-29　情報源：build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1565 · build-infra PR #1566 · build-infra PR #1557 · build-infra PR #1560

  • DTK 26.10 全チェーン：8件のマージの順序自体が1本のトラブルシューティングチェーンである。初版コンテナと設定の着地後（#1554、#1555）、イメージは依然としてビルドもスケジューリングもできなかった：#1558 は base/hygon-dtk26.10 が依然として /opt/dtk を dtk-26.04 に指しており、かつ .github/build-config.yml に当該エントリの runner オーバーライドがなければ h20 のデフォルト値にフォールバックすることを指摘した。その後 torch 2.13.0+dtk2610 の libtorch_global_deps.so が libmpi.so.40 と libibverbs.so.1 を直接リンクしたが、26.04 の wheel はこれら2つの soname をパッケージ内にハッシュ化していた。そのためこのラインではベースイメージに libopenmpi3t64 の追加が必要となり（#1564）、ビルダーに libopenmpi3 の追加が必要となった（#1565）。
  • バージョンライン：同一ランタイムが python 3.12 に固定されているため、既存の cp310 の hcu wheel が解決できなくなった；#1562 で deadsnakes 3.12 により cp312 の hcu ビルダーを再構築し、DTK 26.10 の Ubuntu22.04 SDK を組み込んだ；#1566 でさらに hcu-dtk2610 を wheel リリースラインのターゲットオプションに追加し、flagtree==0.7.0+hcu3.6 が通常の flagtree として海光源にリリースできるようにした。
  • 昇騰 rpm：FlagTree の昇騰 rpm ターゲットを新規追加（#1557、44行追加・4行削除）。コンパイル対象は昇騰デリバリーパイプラインが生成する cp311 と aarch64 wheel であり、まさに openEuler 24.03 の aarch64 に対応するため、1行のみの有効化となる。これもベンダー SDK とハードウェアに依存しない初の rpm ラインである。
  • 2.3.0 の兆候：ランタイムイメージの記述が 09:44 と 18:26 の2回更新され（#1552、#1561）、changelog の日付は hygon-dtk26.10 で記帳された（#1560）。しかし community リポジトリの release/2.3/release-2.3.yaml は依然として 404 であり、2.3 のリリースマニフェストがまだ確立されておらず、現在の進捗はビルド面で止まっていることを示している。
  • リリース効率：その他、vllm 再パッケージ依存を PEP 503 ページ解析に切り替え（#1543）、actions/setup-python を 7.0.0 から 7.1.0 にアップグレードした（#1550）。

1.8 量子ライン：FlagQuantum 六十筆のコミット、CS-01 から CS-07 の合成パイプラインが貫通（10-29）

日付：2026-10-29　情報源：FlagQuantum リポジトリ · FlagQuantum PR #960 · FlagQuantum PR #964 · FlagQuantum PR #966 · FlagQuantum PR #967 · FlagQAI リポジトリ

  • 規模：FlagQuantum は1日で60件のコミット、15件のマージを行い、すべてが同一のライン、すなわち量子回路合成（CS シリーズ）に集中している。リポジトリ内の docs/roadmap/ と docs/api-changes/ は FQ-SYNTH-CS01..CS07-20261029 に従って10件の仕様書と納品ドキュメントをアーカイブ済みである。
  • パイプライン：CS-01 はコヒーレント整数構築の意味境界と検証を定義し、CS-02 は純粋な算術カーネルでコヒーレント加算を削減し、CS-03 は乗算とコヒーレント多項式を扱い、CS-04 は制限付き Python ワークフローを貫通させ、CS-05 はライフサイクルとワークスペーススケジューリングを追加し、CS-06 は3段階（実行契約、候補コスト選択、単一ユーザーワークフロー）で実装し、CS-07 はレジスタ意味論とプログラム准入に進んだ。同日にはポータブルな .fqx 実験ファイルの保存・読み込み（#960）と fq.run による検査済みプログラム実行（#964）も追加された。
  • 審査中：CS07-C の制限付きネイティブ Qmod フロントエンド（#967）が17:30に開かれ、単一の出力のみを含む符号なし main を既存コンパイラのレジスタと式モデルへ翻訳する。テキストは実行せず、Python 呼び出し可能オブジェクトも生成せず、バックエンドも選択しない。
  • 併設 FlagQAI：同源の FlagQAI（10-10 リポジトリ作成）は1日で11件のコミット、4件のマージを行い、ローカル量子ワークベンチ Web ページとネイティブ Agent 統合（#3）、リフレッシュ後もフォロー設定を保持する修正（#4）を追加した。リポジトリ内の README は「意図から回路を合成する」ことを製品方向として明記しており、完了済み能力としては挙げていない。現在の検証範囲はローカル回路シミュレーションと、固定アンザッツ1本の2ビット変分パスのみである。
  • 判断：このラインは本スタックの中で独立度が最も高い——マルチチップ適応は行わず、「科学問題を実行可能な回路へ翻訳する」中間層のみを担う。その価値は、2.x 周期にチップ非依存のソフトウェアスタック用例を提供することにある。

1.9 その他のリポジトリ：OpenCourse 教材再編、FlagScale と TransformerEngine-FL が CI を収束（10-29）

日付：2026-10-29　情報源：OpenCourse コミット · FlagScale PR #1315 · TransformerEngine-FL PR #142 · optest PR #18 · FlagOps PR #18

  • OpenCourse：3件のコミットで課程リソースの再編（17:07、19:59）と师资発展版ディレクトリの改名（21:53）を行い、実験メインライン（lab mainline）を追加した。これはコミュニティが継続的に推進するグローバル师资発展計画と同一バッチである。
  • FlagScale：テスト戦略、影響を受けるルート、実行証拠ゲートを1セットに統一した（#1315）。審査中側では新たな訓練スタックの動きが見える。DeepSeek-V4 を上流へ同期する [1/N]（#202）と [2/N]（#211、パッケージ化シーケンス向けに連続コンテキスト並列を補完）、および HF と MCore の DCP 軽量相互変換（#1319）である。
  • TransformerEngine-FL：FlagCICD v1 を実装し、L0 から L4 のテスト分级と計画駆動実行を導入した（#142）。
  • optest と FlagOps：optest は CI のターゲット参照とオペレータテスト診断情報を修正し（#18）、README を書き直した（#17）。FlagOps の堅牢なチェックアウトは、ハードキルされた fetch が残した陳腐な git ロックを除去する（#18）。

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

2.1 MiniCPM-OCR デュアルモデルが Day0 で12プラットフォームに適応、達摩院玄鉄のスループットがネイティブの98.7%に到達（10-29）

日付：2026-10-29　情報源：FlagOS Day0 適配 MiniCPM-OCR & Jev · FlagRelease モデルカード入口 · vllm-plugin-FL ドキュメント · Torch-FL ドキュメント

  • モデル：面壁智能がOpenBMBと共同でMiniCPM-OCRシリーズをオープンソース化——1.3BのMiniCPM-OCR 1.0はスキャン、撮影、湾曲、再撮影などの実ドキュメントシーンに対応し、文字、数式、複雑な表の解析とキー情報抽出をサポート。公式評価ではReal5-OmniDocBenchで93.68点を獲得し、DSparkデコード加速を導入することでエンドツーエンド効率が55%向上。2BのMiniCPM-OCR Jevは「AI品質検査員」として解析結果の信頼性スコアリングを担い、異なるOCRモデルを接続可能。JevOCRBenchでの総合AUROCは0.936で、Qwen3.5-397B-A17Bの0.938に迫る。
  • プラットフォームとパス：達摩院玄鉄、NVIDIA、Huawei昇騰、海光、昆仑芯、沐曦、摩尔線程、清微智能、天数智芯、曦望、Mac（ARM）、此芯科技の12プラットフォームをカバー。JevはTorch-FL経由で接続し、OCR 1.0は推論フレームワークプラグイン（vLLM-plugin-FLまたはSGLang-plugin-FL）経由で接続。基盤はいずれもFlagGemsのオペレータ実装とFlagTreeのコンパイルサポートを使用。バージョンの基準はvLLM v0.24.0、vllm-plugin-FL v0.3.0、FlagGems v5.4.0。
  • 性能の基準：JevはNVIDIA上でTorch-FL + FlagGems + FlagTreeを使用し、12サンプル、batch 1、シングルカードBF16で平均判別76.2ミリ秒、ネイティブ62.7ミリ秒、実計算スループットはネイティブの82.3%。達摩院玄鉄上では平均63.56ミリ秒、スループットはNVIDIA H100ネイティブの98.7%に達する。OCR 1.0は達摩院玄鉄上でvLLM-plugin-FL + FlagGems + FlagTreeを使用し、双方ともシングルカードBF16（ピーク算力は989 TFLOPSと123 TFLOPSで計算）、ピーク正規化後の単一ドキュメントP50スループットはネイティブの169.3%、バッチシナリオでは137.1%。
  • 端末側：ARM側はMacと此芯科技をカバー。JevはM5 CPUのみを使用し、12サンプルで平均1回のページブロック判別に1.2秒、中央値895ミリ秒（前段の全ページOCR解析は含まず）。実装ではBF16の重みと判別ヘッドを保持し、SME2マトリクス命令で主要な線形層を加速し、Triton TLE Raw経由でオペレータ実行パスに接続。
  • 所見：これは最近で初めて「クロスチップスループット」と「端末側レイテンシ」を同一基準で示した適合説明である——98.7%は実スループット比、169.3%はピーク算力で正規化した比率であり、両者は互いに代替できない。記事はまた、169.3%の成立前提が単一カードの高速化ではなく、低ピーク算力プラットフォームの利用率がより高いことにあると明記している。

2.2 CSDN技術ライブ配信：1つのプラグインで10種のチップの推論適合を実現（10-29）

日付：2026-10-29　情報源：ライブ配信ページ：大模型推論の救世主——1つのプラグインでマルチチップ適合を実現

  • 事実：FlagOSコミュニティは10-29 16:25に公開、19:00に技術ライブ配信を開始した。テーマはsglang-plugin-FLのクロスチップ推論適合。このプラグインはSGLang上に構築され、カーネルソースコードに侵襲しないout-of-tree外部推論プラグインである。
  • 技術要点（ページ要約）：ATenオペレータ置換、融合オペレータスケジューリング、統一通信抽象、PD分離下のKV Cache転送、Emptyモードの依存分割などのメカニズムを通じて異なるハードウェアに接続。紹介では昇騰、海光、昆仑芯など10種のチッププラットフォームに適合済みとしている。
  • 対応するコード面：本調査期間内にsglang-plugin-FLには6件の審査中PR更新があり、昇騰と天数のSGLang 0.5.18上のEmptyランタイム適合（#160、#139）、昆仑芯の0.5.18へのアップグレード（#155）、およびネイティブMooncake PD制御を再利用した汎用FlagCX転送（#142）が含まれる。ライブ配信の内容とコードの進捗方向は一致している。
  • 所見：コミュニティ側のコンテンツリズムは「発表会型講演」から「プラグイン単位で分解した単点技術ライブ配信」へと移行しており、本配信は10-22の大学円卓、10-15のオペレータバウンティチャレンジとともに連続した技術発信ラインを形成している。

2.3 チャネル核查：HNと智源コミュニティに新規ヒットなし、CSDNコラムに新稿1件とライブ1件を追加（10-29）

日付：2026-10-29　情報源：HN Algolia · 智源コミュニティ · CSDN FlagOSコラム

  • CSDN コラム：ページ上の15件の項目をページごとに確認した結果、調査期間内の新規追加は2件——10-29 11:19 公開の MiniCPM-OCR および Jev による Day0 適配記事（2.1 参照）、ならびに 10-29 16:25 公開、19:00 配信開始の sglang-plugin-FL ライブ配信（2.2 参照）。ページ上位に表示される GLM-5.3-Flash（8-28）、Qwen3.8-Flash-Next（8-27）と LightX2V 接続の3稿は8月下旬の旧記事であり、調査期間には計上しない。
  • HN：8組のクエリ（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）は4日間の調査期間内に6〜30件ヒットしたが、タイトルと本文の直接一致によるものは0件で、同名词の誤ヒットである。
  • 智源コミュニティ：トップページと検索ページのいずれにも調査期間内のソフトウェアスタック関連の新規項目はない。検索ページはクライアントサイドレンダリングのため項目リストを取得できず、トップページでの確認を基準とする。
  • gnews：24組の中国語・英語クエリで調査期間内に計30件ヒットし、タイトルと本文で1件ずつ筛选した結果、FlagOS に関連するのは1件のみ——具身之家 10-29 の輝羲智能参賀稿で、内容は 10-17 から 10-18 の 2026 人工智能開放計算大会暨衆智 FlagOS 技術大会を指し、会後の広報稿であって調査期間内の新規イベントではなく、項目として単独計上しない。その他は科創板行情、董事会決議、園区招商、基金保有稿であり、タイトルのキーワードにより一括除外した。
  • メンバー公式サイト：8社の巡回のうち、沐曦公式サイトには 10-29 の新規項目《Token 効率からオープンソース協作へ、AI Infra の次の十年へ｜沐曦股份 CNCC 2026 分科会回顧》があり、会議回顧でありソフトウェアスタックの変動には触れていない。摩尔線程公式サイトの最新は 10-28 の第3四半期報告図解である。天数、海光、寒武紀、燧原、清微の5社のリストには 10-29 から 10-30 の新規項目はない。地平線は取得に失敗し、リスト上の可視内容を基準とする。

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

3.1 海光：DTK 26.10 のコンテナから wheel までの全チェーン実装（10-29）

日付：2026-10-29　情報源：build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1562 · build-infra PR #1563 · build-infra PR #1565 · FlagAttention PR #109 · FlagTrain PR #35

  • コンテナ層：DTK 26.10 の基本コンテナとランタイム設定を新規追加（#1554 で78行追加、#1555 で21行追加）。初回導入時に「FlagCX はまだビルドされていないため、本段階では対象外とする」と明記。修正コミット #1558 は二つのブロッカーを一括解決：base/hygon-dtk26.10 が /opt/dtk を dtk-26.04 に指しているのに SDK は実際には /opt/dtk-26.10 に展開される問題、およびビルドマトリクスに該当項目の runner カバレッジがなく h20 にフォールバックする問題。
  • 依存層：torch 2.13.0+dtk2610 のグローバル依存が直接 libmpi.so.40 にリンクするが、24.04 基本イメージにはこれを提供するパッケージが存在しないため、libopenmpi3t64 を追加（#1564）。FlagCX のビルダーは 22.04 の自己完結環境を使用し、パッケージ名は libopenmpi-dev のため別途追加（#1565）。同じコミットでは、26.04 の wheel が libmpi と libibverbs をパッケージ内にハッシュ化して取り込むため、旧ビルダーではこれら二つのシステムライブラリが不要だったことも指摘——これはバージョン間のビルド前提の変化を示す直接的な証拠である。
  • コンパイルと通信層：FlagTree に cp312 の hcu ビルダーを追加し DTK 26.10 SDK をインストール（#1562）、hcu-dtk2610 を wheel リリース対象に追加（#1566）。FlagCX の dtk2610 wheel ラインは flagcx==0.14.1+dtk2610 で開始（#1563）。
  • オペレータ側：FlagAttention は海光上の FP8 MSA パスを削除しテストインポートを修正（#109）。FlagTrain の multi_tensor_adam は海光をファーストクラスバックエンドとして位置づけ（#35）。審査中のものとして、FlagCX に海光の bitcode ビルド（#667）、FlagScale に DCU のハードウェアヘルスサンプリング（#1299）がある。
  • 判断：海光のこのラインの価値は新機能ではなく、「新 SDK がもたらす soname とインタプリタバージョンの変化」を一日でコンテナ、ビルダー、wheel の三箇所で修正し、再利用可能な調査手順を残したことにある（#1558 と #1565 の本文がその手順の記録である）。

3.2 清微：Triton 3.6 バックエンドを同期合入し専用タグを発行（10-29）

日付：2026-10-29　情報源：FlagTree PR #1459 · FlagTree タグ · FlagTree PR #1468 · vllm-plugin-FL PR #642

  • 合入内容：清微バックエンドを内部 Triton 3.6 開発ラインと同期（#1459、27ファイルで2264行追加・407行削除）。変更は third_party/tsingmicro/ のみ：ベンダーオペレータディスパッチに必要な逐発射精度 API（precision.py）、外部 CoreIR エントリとランタイムアダプタを復元し、Tx81 のコード生成問題を数件修正し、DMA、RDMA、WDMA、gather-scatter および算術関連の CRT 不具合を修正。
  • バージョン動作：同日 11:09 に清微 3.6 専用タグを発行。10-26 の摩尔線程 3.6 タグと同期間のシリーズを構成する。
  • 審査中とエコシステム：vllm-plugin-FL の審査中 #642 は清微の eager TXDA バックエンドを vLLM 0.28.0 に適合させる。FlagGems 側の清微リファレンス実装には 10-29 にテストフィクスチャ修正が複数ある（1.4 参照）。
  • 判断：清微は「内部開発ライン」を直接オープンソースバックエンドに同期する数少ないベンダーである。代償は同期ごとに規模が大きいこと（今回は27ファイル）で、レビューにはベンダー SDK のセマンティクスに沿った確認が必要となる。利点は FlagGems と FlagTree のインターフェース取り決めをベンダー内部の進捗に合わせて前倒しできることにある。

3.3 崑崙芯：XPU3 の foreach 融合チェーンと定数グリッドの仕上げ（10-29）

日付：2026-10-29　情報源：FlagGems PR #7116 · FlagGems PR #7968 · FlagGems PR #7973 · FlagGems PR #7974 · FlagCX PR #678 · FlagGems-sglang PR #248

  • 融合カーネル：foreach ファミリーが XPU3 上で「オペレータごとの個別実装」から「List エグゼキュータ」への収束を完了——cos/exp/sin/addcdiv/lerp は統一エグゼキュータ（#7116）、ceil はマスクなし融合カーネル（#7604）、tanh/expm1 はインプレース融合カーネル（#7608）を採用。
  • 起動の正確性：その後 4 件の修正は起動パラメータに集中——fmin と t_copy の一次元パスは定数起動グリッドに変更（#7966、#7973）、foreach のスカラー dtype 分岐は排他的に変更（#7974）、foreach add のリストスロットは program_id(0) から導出するように変更（#7968）。これらは性能最適化ではなく、「同一オペレータが複数分岐下で誤ったスロットを取得する」ことに対する正確性の修正である。
  • インターフェース面：FlagCX は FlagTree がリンクするための XPU デバイス IR エントリを追加（#678）。FlagGems-sglang の fill_bonus_tokens は新しい tle.raw 方言 API に適応（#248）。
  • レビュー中：vllm-plugin-FL の P800 における vLLM 0.28.0 への適応（#585）、sglang-plugin-FL の昆仑芯の 0.5.18 へのアップグレード（#155）、および FlagGems 側の一連の P800 正確性に関する議題。

3.4 沐曦：グループ GEMM の INT8 と FP8 パス、TP2 デコードスケジューリング（10-29）

日付：2026-10-29　情報源：FlagGems PR #6950 · FlagGems-vllm PR #1025 · FlagAttention PR #108 · FlagTree PR #1481 · FlagTree PR #1471

  • グループGEMM：grouped_mm_w8a8 は INT8 と FP8 の両方をサポート（#6950、7ファイルに1220行追加）。ベンチマークの形態は GLM-5.2 が PPU SGLang TP=8 上で収集した実際の呼び出しリプレイに由来し、288万回から324万回の呼び出しの2組の形状で、計26組の一意なジオメトリ、257個のエキスパート。ベースラインはベンダーライブラリの ContinuousGroupedGEMM で、両側とも同じ INT8 入力、FP32 スケーリング、エキスパートグループを受信する。
  • デコードスケジューリング：FlagGems-vllm 側では TP2 packed decode の Split-KV スケジューリングと計算タイルの再配置（#1025）を行い、目標は狭いタイル下でのデコードスループット。
  • アテンション：FlagAttention に C550 上の Triton 融合 AttnRes フォワードを追加（#108、3ファイルに268行追加）。FP16 と BF16、オプションの出力 RMSNorm とアテンション重みをサポートし、RMS スコアリング、オンライン softmax、残差集約を融合し、TLE に依存しない。D=7168、BF16 で (2,1) の0.075ミリ秒から (9,8192) の1.496ミリ秒まで。著者は FLA が利用不可のため加速比を主張しないと注記している。
  • コンパイラ：FlagTree は Metax 上の CompiledKernel のメタデータチェックを修正（#1481、対応議題 #1473）。審査中の #1471 は MetaX の CommonIR に set_layout とレイアウト自動チューニングを追加する。
  • ベンダー側：沐曦公式サイトは10-29に CNCC 2026 分科会の振り返り《Token 効率からオープンソース協働へ、AI Infra の次の10年へ》を公開。会議側の内容に属する。

3.5 摩尔線程：TLE 常駐 GEMM と SPMC 同期がメインラインへ（10-29）

日付：2026-10-29　情報源：FlagTree PR #1294 · FlagGems-vllm PR #970 · FlagTree PR #1451 · vllm-plugin-FL PR #575

  • コンパイラ：[MThreads][TLE] の常駐 GEMM パイプラインと SPMC 同期がメインラインへ（#1294、63ファイルに6192行追加、403行削除）。従来 addmm/baddbmm と bmm にそれぞれ対応していた2套のコンパイラを1套のスーパーセットに統合。機能には動的ループ内の stage と phase の推進、1プロデューサー多コンシューマー、名前付き読み取りと暗黙読み取り、セグメント化とグループ化完了、コンシューマーエポック導出、および単発、融合コンシューマー、16 warp 常駐パスが含まれる。PR 本文は今回の変更がコンパイラ、フロントエンド、テストのみを含み、FlagGems オペレータコードを含まないことを明記している。
  • 推論：FlagGems-vllm 側では現在の CI コンパイラに合わせて MUSA の FP8 可変長アテンションを再調整（#970）。
  • 審査中：FlagTree の #1451 は WGMMA の warp 選択を上流の MMAv3 に整合させる。vllm-plugin-FL の #575 は MUSA を vLLM 0.28.0 に適合させる。また MUSA の短形状フォールバックブランチ（FlagFFT の codex/musa-shortfall）がフィーチャーブランチ上で進行中。
  • 判断：摩尔線程の投入重心はオペレータ数ではなくコンパイラ側にある——常駐 GEMM と SPMC は addmm/bmm といった基幹オペレータを MUSA 上で実用的な性能まで引き上げる前提であり、この能力は昇騰と沐曦の TLE ラインでも同時に再利用されている。

3.6 燧原、昇騰、達摩院玄鉄：アテンションと正規化オペレータの4本のライン（10-29）

日付：2026-10-29　ソース：FlagAttention PR #104 · FlagAttention PR #106 · FlagAttention PR #116 · FlagAttention PR #103 · FlagGems PR #6586 · Torch-FL PR #683 · FlagGems-vllm PR #888

  • 燧原：FlagAttention に同日3件がマージ——MiniMax M3 スパースアテンションの prefill と decode 最適化（#104、2ファイルで2873行追加・2516行削除）、chunk KDA オペレータ最適化（#106）、融合アテンション残差オペレータ（#116）。FlagTree 側では燧原 CI（#1468）と TLE 単体テスト（#1470）を追加し、レビュー中の #1405 で swiglu の精度誤差を修正。
  • 昇騰：Parallax アテンションの三段実装（prefill、decode、kvcache、#103、10ファイルで2738行追加）を新規追加。因果マスク、スライディングウィンドウ、GQA、可変長入力をカバーし、FLA と比較して多くの訓練形状で1.0〜8.74倍の高速化を実現。FlagGems は cat（#7989）と log_ のグリッドパディング再実行（#6586、5.4.0-rc2 バックポート）を修正。FlagGems-vllm は fused_q_kv_rmsnorm を昇騰に移植し（#872）、lightning-indexer のカスタムオペレータを tle_raw.call に改名（#944）。Torch-FL は昇騰が FP32 matmul 精度に従い勾配を常駐させるようにした（#683）。
  • 達摩院玄鉄：fused_q_kv_rmsnorm は同様に達摩院玄鉄プラットフォームにも移植（#888、17:07 マージ）。PPU 側では 10-29 に FlagTrain の multi_tensor_adam 全バックエンド対応（#35、PPU はファーストクラスバックエンド）があり、レビュー中の PPU GLA 最適化（FlagAttention #117 は海光、PPU は別ブランチ）もある。MiniCPM-OCR の Day0 適応により、達摩院玄鉄のスループットは NVIDIA ネイティブの 98.7% に到達（2.1 参照）。
  • 判断：3社は同じ日にそれぞれ1つのアテンションパスを選択——燧原はスパースと KDA、昇騰は Parallax と融合 RMSNorm、達摩院玄鉄は融合 RMSNorm と端側デコード。アテンション層の細分化は依然として加速しており、ベンダー横断の統一的な低レイヤ実装はまだ出現していない。

3.7 天数：天垓 300 が初の実機デモを公開、単カードスループットは H200 の 1.05 倍と主張（10-28）

日付：2026-10-28（デモ）/ 2026-10-29（報道）　ソース：Pandaily 報道 · 南華早報報道 · FlagCX PR #681 · sglang-plugin-FL PR #139

  • デモ事実：天数智芯は10-28の上海メディア開放日に天垓300汎用GPUを初めて実機展示した。これまで同社によるこのチップの公開資料はアーキテクチャとロードマップが中心で、稼働するシステムはなかった。
  • 主張と表現：同社は天垓300を、実測性能が英偉達（NVIDIA）H200水準に達した初の国産汎用GPUと称し、第三者テストの換算で単カード全体スループットがH200の1.05倍となり、テキストtoイメージやテキストtoビデオなどの複雑なマルチモーダルタスクでH200を上回るとしている。この数字は同社の表現であり、テスト方法、使用モデル、ワークロード条件はいずれも公表されておらず、検証できない。
  • スタック側の対応：FlagCXは同日、天数向けにDevice APIの取得セマンティクスを補完した（#681、1.6参照）。審査中のsglang-plugin-FLの#139は天数をSGLang 0.5.18のEmptyランタイムに適合させる。FlagTrainのmulti_tensor_adamは天数をサポートバックエンドに追加済み（#35）。
  • 判断：ハードウェア表現の対外発表とソフトウェアスタックの適合は、ペースの異なる2本の線である。前者は発表会1回で完了するが、後者はDevice APIのメモリオーダーから推論フレームワークのランタイム適合までを一筋に補う必要がある。本調査期間に見えたのは後者が継続的に補完されていることであり、前者の数字は依然として検証可能な条件を欠いている。

4. まとめとトレンド観察

  • ハードウェア世代切り替えのコストはビルド面に集中：DTK 26.10の8件のマージのうち、カーネルを変更したものは1件もなく、すべてコンテナパス、インタプリタバージョン、runnerのオーバーライド、soname依存である。python 3.12とtorch 2.13.0+dtk2610は既存のcp310ビルダーを全面的に無効化し、26.04から26.10の間でlibmpiとlibibverbsは「wheelにハッシュで同梱」から「実行時リンク」へと変わった。こうした変化はノードごとの実測でしか発見できない。
  • モデルDay0の語りは比較可能な数字へ：MiniCPM-OCRの適合説明は、実スループット比（98.7%）、ピーク正規化スループット比（169.3%）、端側レイテンシ（M5で1.2秒、中央値895ミリ秒）を同時に示し、それぞれの前提を明記している。これは本スタックにおいて最近出た初めての「ネイティブに追いつく」と「利用率がより高い」を分けて述べた資料であり、単一の倍率より参考価値が高い。
  • テスト基盤が独立した主線に：ref-as-candidateがFlagGemsとFlagGems-sglangの両リポジトリで実装され、同日の57件のテスト修正とkernelgen-devの毎日自動同期を伴い、テストは「オペレータがあるか」から「参照と実装が一致するか」へと変わった。この線の成果はオペレータ数には現れないが、以降のすべてのバックエンド整合の信頼性を決める。
  • 量子線は独自体系：FlagQuantumは1日で60コミットを重ね、CS-01からCS-07までの回路合成仕様と納品ドキュメントを体系的にアーカイブし、FlagQAIは並行してローカルワークベンチを整備した。これはマルチチップ適合とは無関係であり、2.xサイクルで唯一ハードウェアから切り離されたソフトウェアスタックの主線である。
  • 注視すべき3点：第一に、communityリポジトリのrelease/2.3マニフェストがまだ作成されていないのにビルド面は2.3.0で記帳しており、リリースノートが補完されるかどうか。第二に、FlagCX v0.14.1とFlagTreeのベンダー別3.6タグはいずれもRelease本文がなく、下流はタグ名から内容を逆推するしかないこと。第三に、Megatron-LM-FLのDeepSeek-V4上流同期が[1/N]と[2/N]を出しており、2週間停止していたこの訓練スタックが本当にプッシュを再開したかどうか。

情報源チェック表

情報源 調査結果
GitHub org 全量（61 リポジトリ） 21 リポジトリが調査期間内にプッシュ；16 リポジトリにコミットあり；5 リポジトリは原子補核済み（1 リポジトリにコミットあり、1 リポジトリは gh-pages、1 リポジトリはフィーチャーブランチ、2 リポジトリは PR ブランチとイシュー活動）
コミット検索 189 件；FlagQuantum 60、FlagGems 43 が二大勢力
マージ済み PR 検索 183 件；FlagGems 92、build-infra 16、FlagQuantum 15
審査中 PR 検索 253 件に更新あり、新規作成 84 件；Megatron-LM-FL の 10 件はここ 2 週間で初のまとまった更新
Release / Tag 原子核查 31 リポジトリ；調査期間内に新規タグ 1 個（FlagTree 清微 3.6 専用番号、リリース本文なし）；FlagCX v0.14.1 のアーカイブ時刻が 10-29 10:55 に更新
org イベントストリーム 100 件：PR レビューコメント 34、PR イベント 34、プッシュ 13、イシューコメント 9、ブランチ作成 8、ブランチ削除 1、fork 1
Google News RSS（24 組の中英語） ヒット 30 件、有効 1 件（輝羲智能の参会稿、10-17 から 10-18 の大会を指す、会後伝播稿に属し、単独掲載せず）
HN Algolia（8 組） 4 日間の調査期間でヒット 6 から 30 件、タイトルと本文が直接一致するもの 0 件
CSDN FlagOS コラム 新規記事 1 本（MiniCPM-OCR Day0、10-29 11:19）、ライブ配信 1 回（10-29 19:00）；関連性の高い旧稿 3 本は確認時刻が 8 月下旬であり、計上せず
智源コミュニティ トップページに調査期間内のソフトウェアスタック項目なし；検索ページはクライアントレンダリングのため、リストを取得できず
メンバー単位公式サイト（8 社） 沐曦は 10-29 に会議振り返り 1 件；摩尔線程の最新は 10-28 の決算図解；天数、海光、寒武紀、燧原、清微に新規項目なし；地平線は取得失敗

完全情報源リスト

[21] FlagTree PR #1481（Metax メタデータチェック） — https://github.com/flagos-ai/FlagTree/pull/1481

lagos.csdn.net/6ae2bb2740858c2d8817187c.html>