FlagOS デイリーレポート (2026-10-26)
調査期間:2026-10-23 06:00 ~ 2026-10-26 06:00(北京時間、72時間;月曜朝報、期間は前回デイリーレポートの締め切り時点から継続し、土曜と日曜の2日間をカバー)。
情報源:GitHub(org: flagos-ai 61リポジトリ全量核查、コミット検索612件(第6〜第8ページ補完を含む)、マージ済みPR 274件と審査中PR 253件の検索、orgイベントストリーム99件、31リポジトリのRelease/Tag原子的核查、5リポジトリのAtomフォールバック)、FlagReleaseモデルリポジトリ(Hugging Face組織下60モデルリポジトリの最近更新核查)、Google News RSS(24組の中英語クエリ語、プロキシ経由)、HN Algolia(8組)、CSDN FlagOSコラム、智源コミュニティ、InfoQとメンバー機関のプレスリリース(詳細は付録情報源リストを参照)。
本期インデックス
- 今日の重点:MiniMax-M3.1-Flash 九芯 W8A8 同日納品;ランタイム 2.3.0 が再構築認可段階に入る;FlagQuantum 三日間505件のコミット(10-23 ~ 10-26)
-
- オープンソースプロジェクト進展(GitHub動向)
- 1.1 組織リズム:16リポジトリのプッシュ、612件のコミット、274件のマージ、FlagQuantumがコミットの八成を独占(10-23 ~ 10-26)
- 1.2 FlagRelease:MiniMax-M3.1-Flash 九芯 W8A8 が同日上架、四社がExpress版を使用(10-23)
- 1.3 ランタイム 2.3.0:2件のchangelog日付が確定、再構築が認可され、コンテナは起動パラメータでFlagGemsとFlagTreeのバージョンを選択可能(10-23 ~ 10-25)
- 1.4 FlagQuantum:三日間505件のコミット、148件のマージ、QECパッケージ再編とFTQC Stage A試行が並行(10-23 ~ 10-26)
- 1.5 FlagQuantum:Quafu SDKライフサイクル全体の切り替え、Rydberg presence契約が成立(10-25 ~ 10-26)
- 1.6 FlagGems:50件のマージ、昆仑芯の欠陥修復とKernelGenオペレータのバッチ実装が並行(10-23 ~ 10-24)
- 1.7 FlagGems-sglang:34件の競賽トラックオペレータのマージ、初のDebianとRPMパッケージング追加(10-23 ~ 10-25)
- 1.8 Torch-FL:ベンダー命名の再構築を一気に完了、2日間で16件のマージ(10-23 ~ 10-25)
- 1.9 推論プラグイン:vllm-plugin-FLがMiniMax-M3.1に接続、sglang-plugin-FLが海光Qwen3.6 MTPデコードを補完(10-23 ~ 10-24)
- 1.10 その他のリポジトリ:FlagTreeがMTHREADSバックエンドに追従、FlagTrainが融合オペレータを追加、optestのコマンドラインが三改一退(10-23 ~ 10-25)
- オープンソースプロジェクト進展(GitHub動向)
-
- 報道とエコシステム
- 2.1 InfoQの長文がFlagOS 2.2を回顧:メンバー機関107社、四半期ダウンロード46.4万回(10-24)
- 2.2 沐曦と摩尔線程が同日にMiniMax M3.1 Flash Day-0適配を発表(10-23)
- 2.3 チャネル核查:44件の候補のうち3件が有効、CSDNコラムは期間内に新稿なし(10-26)
- 報道とエコシステム
-
- メンバー機関とバックエンドベンダーの深掘り
- 3.1 海光:九芯のうちW8A8版以外に、MiniCPM-V 4.7のデュアルバージョンが同日リポジトリに格納(10-23)
- 3.2 昆仑芯:FlagGems側で十余件の修正と速度向上、XPU3パスを集中的に収束(10-23)
- 3.3 達摩院玄鉄:真武Express版を納品、PPUスパースアテンションは審査中(10-23 ~ 10-25)
- 3.4 清微、天数、摩尔線程、沐曦:四社がオペレータライブラリ側でそれぞれ一批のコミット(10-23 ~ 10-25)
- メンバー機関とバックエンドベンダーの深掘り
-
- まとめとトレンド観察
- 付録:情報源核查表と完全情報源リスト
今日の重点:MiniMax-M3.1-Flash 九芯 W8A8 同日納品;ランタイム 2.3.0 が再構築認可段階に入る;FlagQuantum 三日間505件のコミット(10-23 ~ 10-26)
日付:2026-10-23 ~ 2026-10-26 出典:FlagOS マルチチップサポート説明(MiniMax-M3.1-Flash) · FlagRelease モデル組織 · build-infra PR #1484 · FlagQuantum コミット(詳細は付録を参照)
- デリバリー面:MiniMax は 10-23 に M3.1 Flash をオープンソース化し、FlagOS コミュニティは同日、9 社のチップ向け W8A8 バージョンを ModelScope と Hugging Face に公開した:達摩院玄鉄(真武)、NVIDIA、沐曦、海光、ファーウェイ昇騰、摩尔線程、天数智芯、昆侖芯、清微。9 つのリポジトリは 10-23 14:06 から 14:39 の間に集中的に作成され、さらに 2 社の動画モデルリポジトリと海光 MiniCPM-V 4.7 のデュアルバージョンが同日に追随した。
- 技術面:FlagOS はモデル本来の QAT NVFP4 重みをクロスチップ統一の W8A8 形式に再変換し、NVIDIA、昇騰、昆侖芯、達摩院玄鉄の 4 社が Express 版(モデル名に
-FlagOS-Express付き)を提供、残り 5 社が標準版となる。ソースコードパスは達摩院玄鉄の例を示し、構成は vLLM 0.24.0 に vllm-plugin-FL 0.3.0、FlagGems 5.4.0 を加えたもので、テンソル並列 8 カード。 - バージョン面:build-infra は 10-23 と 10-25 にそれぞれ 2.3.0 の changelog 日付を記録し(寒武紀 neuware 4.4.3、沐曦 maca 3.8.1.3)、10-25 に 2.3.0 ランタイムの再ビルドを承認した。コンテナには起動期バージョンパラメータが追加され、FlagGems バージョンの指定や FlagTree に当日ビルドをインストールさせることが可能になった。2.3.0 はまだタグ付けされていない。
- 開発面:調査期間内に 612 コミット、274 マージがあり、うち FlagQuantum 単一リポジトリで 505 コミット(82.5%)、148 マージ(54%)を占めた。組織レベルのアクティビティはすでに量子スタックに高度に集中しており、その他のリポジトリは主に修正とテスト契約が中心となっている。
- 判断:これは GLM-5.3-Flash の 9 チップに続き、一週間内で 2 度目となる「モデルオープンソース当日に 9 チップ同時リリース」である。違いはデリバリー物の形態にある:前回は BF16 とマルチ精度の並行だったが、今回は W8A8 単一パスに統一して収束させ、4 社の常用プラットフォームを Express 版とした——これは Day-0 デリバリーが「動くかどうか」から「統一フォーマットでバッチ複製」の段階に入ったことを示している。
1. オープンソースプロジェクトの進展(GitHub 動態)
1.1 組織のリズム:16 リポジトリのプッシュ、612 コミット、274 マージ、FlagQuantum がコミットの 8 割を独占(10-23 ~ 10-26)
日付:2026-10-23 ~ 2026-10-26 情報源:flagos-ai 組織リポジトリ · コミット検索 · マージ PR 検索
- リポジトリ面:61 リポジトリのうち 16 リポジトリが調査期間内にプッシュがあり、コミット量順に FlagQuantum 505、FlagGems-sglang 39、FlagGems 27、Torch-FL 16、build-infra 12、optest 4、FlagGems-vllm 4、vllm-plugin-FL 2、sglang-plugin-FL 1、FlagTree 1、FlagTrain 1。docs、release-info、FlagSparse、Trident、FlagBLAS の 5 リポジトリのプッシュは非デフォルトブランチに該当し、主ブランチには新規コミットなし。
- マージ面:マージ PR 274 件、リポジトリ別では FlagQuantum 148、FlagGems 50、FlagGems-sglang 34、Torch-FL 16、build-infra 12、FlagGems-vllm 4、optest 4、vllm-plugin-FL 2、sglang-plugin-FL 2、FlagTree 1、FlagTrain 1。
- 審査面:調査期間内に更新のあった open PR 253 件、うち新規オープン 141 件。リポジトリ分布は FlagGems 144(新規オープン 84)、FlagGems-vllm 20、vllm-plugin-FL 14、FlagTree 14、FlagGems-sglang 14、docs 6、FlagTrain 6、sglang-plugin-FL 6、Torch-FL 5、FlagQuantum 4、FlagAttention 4、FlagScale 4。
- 日平均比較:調査期間は 72 時間、日平均換算でコミット 204 件(前回 24 時間調査期間は 135 件)、日平均マージ 91 件(前回 163 件)、日平均新規オープン 47 件(前回 90 件)。すなわち開発側の投入は増加し、レビューのスループットは低下——前回は「キューを消化中」、今回は「新規コードが滞留」に転じた。
- リリース面:調査期間内に 31 リポジトリの Release と Tag の原子的核查はいずれも新規ゼロ、4 日間の調査期間内に正式リリースは皆無。build-infra の最新タグは依然 v2.2.0 で、2.3.0 再構築の承認と「承認済み・未リリース」の宙吊り状態を形成している。
- イベント面:org イベントストリーム 99 件、うち PR イベント 50、プッシュ 20、ブランチ削除 15、ブランチ作成 8、フォロー 3、レビュー 2、コメント 1。ブランチ削除 15 と新規作成 8 が併存し、依然として「バッチブランチはマージ即削除」のパイプライン習慣である。
- 判断:コミットとマージの落差は FlagQuantum に集中(505 コミット対 148 マージ、マージ率 29%)、一方 FlagGems-sglang は逆方向(39 コミット対 34 マージ、マージ率 87%)——前者は長周期の科学計算エビデンスチェーンを構築し、後者は競技系オペレータをバッチで取り込んでいる。二つのリズムが同時に存在するのが、本調査期間の最も明瞭な構造的特徴である。
1.2 FlagRelease:MiniMax-M3.1-Flash が 9 チップ W8A8 で同日上架、4 社が Express 版を使用(10-23)
日付:2026-10-23 情報源:FlagOS マルチチップ対応説明 · FlagRelease 組織モデル · vllm-plugin-FL PR #631
- 対応範囲:9社のプラットフォームは達摩院玄鉄(真武)、NVIDIA、沐曦、海光、Huawei Ascend、摩尔線程、天数智芯、昆仑芯、清微であり、すべてが W8A8 バージョンを提供する。モデルリポジトリは FlagRelease 組織の下に統一され、ModelScope と Hugging Face のデュアルチャネルでリリースされる。
- 量子化パス:FlagOS は MiniMax ネイティブの QAT NVFP4 重みをクロスチップ汎用の W8A8 デプロイバージョンに変換し、ローカルでは再トレーニングを行わない。NVIDIA、Ascend、昆仑芯、達摩院玄鉄の4社が Express 版で、命名規則は
MiniMax-M3.1-Flash-W8A8-<platform>-FlagOS-Express、残りの5社は標準版となる。 - モデル仕様:M3.1 Flash は総パラメータ 428B、活性化 23B、1M コンテキストと画像・動画入力をサポートし、調整可能な思考深度パラメータを新規追加。公式の見解では、オンライン推論速度が前世代比で約3倍向上し、Agent シナリオの総合 Token コストが70%削減される。
- デプロイパス:ドキュメントでは2つの方法が示されている——FlagRelease イメージを直接使用することを推奨(チップごとにリポジトリを選択し、モデルカードに従ってドライバとコンテナをインストール)、またはソースからインストールする。達摩院玄鉄の例では vLLM 0.24.0、vllm-plugin-FL 0.3.0、FlagGems 5.4.0 を使用し、必要に応じて FlagTree と FlagCX を追加し、
tensor_parallel_size=8でサービスを起動する。 - コード側の配套:vllm-plugin-FL は 10-24 08:25 に「add MiniMax-M3.1 support and inference example」(#631)をマージし、モデル接続と推論例を一并して主干に取り込んだ。FlagGems-vllm は 10-23 17:19 に PPU 側の
flash_mla_sparse_fwd(#975)をマージし、M3.1 の疎な MLA パスに対応した。 - 判断:9つのリポジトリが30分以内に集中して建立されたことは、リリースパイプラインがテンプレート化されていることを示す。真の差異はモデルカード内のランタイムマトリクス(フレームワークバージョン、プラグインブランチ、FlagGems コミット、FlagCX の要否)にあり、これが「真正适配かどうか」を判断する検証可能な根拠となる。
1.3 ランタイム 2.3.0:2件の changelog の日付が確定、再構築が承認され、コンテナは起動パラメータで FlagGems と FlagTree のバージョンを選択可能(10-23 ~ 10-25)
日付:2026-10-23 ~ 2026-10-25 情報源:build-infra PR #1472 · PR #1475 · PR #1480 · PR #1482 · PR #1484 · PR #1487
- プロセス改造(#1472):ランタイムイメージのプッシュには今後 changelog の添付と日付の記録が必須となり、そうでなければパイプラインはプッシュを拒否する。#1478 ではさらに、各 changelog に FlagTree のバージョン上書き値を記録することが要求される。リリースの痕跡管理が「人手の記憶」から「ゲート」へと変わった。
- バージョン痕跡:10-23 14:40 にボットが 2.3.0 の changelog 日付(寒武紀 neuware 4.4.3)をコミットし、10-25 18:26 にさらに1件(沐曦 maca 3.8.1.3)をコミットした。いずれも github-actions により自動生成されており、対応するベンダーのバックエンド組み合わせがビルドリストに列入したことを示す。
- 再構築承認(#1484):10-25 10:03 に 2.3.0 ランタイムのバージョンリクエストによる再構築が承認され、直後の #1485 で OCI タグビルドパラメータの引用符問題が修正され、#1486 でベンダー SDK 環境変数の venv プレフィックス欠落問題が修正された——いずれも再構築の障害を取り除くためのもの。
- パラメータ化(#1480、#1482):コンテナは
FLAGTREE_VERSIONを latest に設定して当日ビルドをインストールでき、FLAGGEMS_VERSIONで FlagGems バージョンを指定できる。バージョンは「イメージに焼き込む」ものから「起動時に選択する」ものへと変わった。#1477 では同時に-buildバリアントが削除され、ランタイムイメージがそのまま成果物であることが明確化された。 - 判断:2.3.0 の準備作業は新機能ではなく「再現性」に集中している——ゲート、痕跡、承認、パラメータ化の4つが揃い、あとはタグ付けを残すのみ。build-infra の既存のリズムに従えば、タグ付けの後は通常、全バックエンドイメージの一括再出が行われる。その際には各ベンダーの changelog が9社分揃っているかを確認する価値がある。
1.4 FlagQuantum:3日間で505件のコミット、148件をマージ、QEC パッケージ再編と FTQC Stage A 試行が並行(10-23 ~ 10-26)
日付:2026-10-23 ~ 2026-10-26 ソース:FlagQuantum コミット · PR #749 · PR #832 · PR #868
- 総量:505 コミット、148 件マージ、いずれも組織全体で第 1 位。コミットが 82.5%、マージが 54%。3 日連続作業で、最も遅いマージは 10-26 01:08 に発生。
- QEC パッケージ再編(#735 ~ #749 の連続 9 件):誤り訂正符号を単一実装から境界を持つパッケージへ分割——まずパッケージ境界と互換ベースラインを監査し(#735)、続いて符号行列とノイズスキャンを順次分離し(#737)、符号ファミリと所有権を分割し(#739)、ストレージ宣言と実行アセンブリを分離し(#740)、検出器誤差モデルを切り出し(#744)、デコードアルゴリズムとオプションアダプタを分離し(#746)、パッケージレイアウトとインストールガイドを確定し(#748)、最後に一体化的に主干へマージ(#749)。これは「インストール可能性」を目標としたディレクトリ手術である。
- FTQC Stage A パイロット(#832 以降):10-25 02:12 に有界規模パイロットのリソースと観察記録をマージし、続いて混合回線戦略研究(#846)、7 点継続実行方案(#860)、混合パイロット台帳の確定(#868)、チェックポイントを継続した物理評価(#847)。経路の特徴は「予算—観察—結論」の 3 段階で証跡を残すことであり、一度に走り切ることではない。
- Ising 支線:10-25 08:55 からシード付き Ising 電荷軌跡実行を提供し、10-25 13:02 から測定記録による固定検出器レイアウトの検証を開始。サンプリング計画(#838)と契約ベースラインは同日マージ。
- CI 側:MC550 バッチ実行を追加し(#742)、A800 の CPU 容量を拡張して手動検証ルートを調整(#743、#745)。審査中 PR #762 では R300 の PR スケジューリングを一時停止し、プール資格を手動に変更することを提案。
- 判断:量子スタックは 3 日間で構造的な再編を一度完了した——パッケージ境界、誤差モデル、デコーダがそれぞれ独立し、後続で M3 のサンプリングと端末計器インターフェースを接続するためのクリーンな位置を空けた。マージ率はわずか 29% で、大量のコミットが依然として提案と証拠チェーンの上を進んでいることを示しており、短期的には「機能デリバリ」の口径で解釈すべきではない。
1.5 FlagQuantum:Quafu SDK ライフサイクル全体の切り替え、Rydberg presence 契約が成立(10-25 ~ 10-26)
日付:2026-10-25 ~ 2026-10-26 ソース:PR #852 · PR #855 · PR #856 · PR #862 · PR #866 · PR #876
- Quafu 移行(10-25 18:23 ~ 23:26 の 6 件連続):検出フローを SDK 経由に変更し(#852)、論理タスクを移行し(#855)、QSteed 物理プログラムを SDK からのコミットに変更し(#856)、トポロジ解析を SDK 経由にし(#858)、ツインライフサイクルを移行し(#862)、最後に旧実行ライフサイクルを退役させた(#866)。旧パスはエイリアスを残さず削除するハード切り替えである。
- 審査中の収尾:PR #857 はライフサイクル移行の残り部分を完了し、#874 は読み取り専用 SDK 切り替えを実施、いずれも審査中。切り替えが段階的に進められ、ロールバック可能な粒度で分割されていることを示す。
- Rydberg presence 契約(10-25 16:35 ~ 10-26 01:08):まず契約ベースラインを立て(#854)、次に無条件 Rydberg アセンブリでの観察出現を拒否し(#865)、続いて単一 presence 観察を符号化し(#869)、有界コヒーレント分岐整合性を提案し(#870)、有界コヒーレント分岐参照を検証し(#873)、最後に有限動的コヒーレント参照を提案(#876、10-26 01:08 マージ)。
- 判断:両ラインはいずれも「まず契約を定め、次に実装を開放する」収口を行っている。Quafu が自研実行ライフサイクルからベンダー SDK へ切り替えたことは、量子ハードウェア側の外部依存が正式に形成されたことを意味する。Rydberg presence は「宣言できるか」から「観察できるか」へと進み、中性原子路線が M3 閾値を越える前の最後の区間である。
1.6 FlagGems:50 件マージ、崑崙芯欠陥修復と KernelGen オペレータ一括投入が並行(10-23 ~ 10-24)
日付:2026-10-23 ~ 2026-10-24 ソース:FlagGems コミット · PR #7095 · PR #7274 · PR #6623 · PR #7199
- 総量:50 件のマージ、27 件のメインブランチへのコミットで、組織内でマージ数が2番目に多いリポジトリ;KernelGen と昆仑芯の2つのラインが交互に着地。
- 昆仑芯(XPU3)集中修正:
addmv_outに M=0、beta=0、N=0 の境界を追加(#7095);log_softmaxのフォワードを整数キーによる最大値取得に変更し、N==1 の高速パスを追加(#7523);special_log1pのスカラー入力を0次元テンソルに戻す(#7457);rnn_reluに融合カーネルを追加し自動微分に対応(#7110);scaled_grouped_mmでバックエンドに FP8 E4M3 デコードを実装(#7274);その他 frexp、conj_physical_、unsqueeze、upsample_linear1d の逆伝播など一連の修正と高速化(#7610、#7599、#7560、#7595、#7349、#7354)。 - KernelGen バッチ:疎 BSR オペレータを追加(#7076)、foreach 系テストを候補への直接注入方式に変更しバッチ 01 から 09 を連続投入(#7543 から #7551)、
einsumの定義と注入可能スイート(#7637)、ベンチマーク結果 JSON の保持優先度(#7615)、7プラットフォーム横断の参照監査後に正確な OOM スキップを追加(#7662)。 - その他のバックエンド:摩尔線程は FP8 行列積を TLE warp 特化に変更(#6623);昇騰は addmm のチューニング候補を mm から分離(#7575);沐曦側は scaled_mm のテストケース収集とバックエンド能力チェックを修正し、
andモードを修正(#7248、#7454)、さらにconvolution_backwardの2オペレータを追加(#7016);英偉達は Hopper FP8 の小さい M 形状を最適化(#7068)。 - クリーンアップ:最初のバッチで誤って移植された CPU オペレータを削除(#7199)。初期のクロスチップ複製型移植に対する撤回に該当。
- 判断:本期は新しいオペレータライブラリ級の大きな動きはなく、重心は「既存オペレータを各バックエンドで使える状態に修正する」ことにある。#7199 の撤回と #7662 の OOM 監査は同じ事柄の両面である。まず歴史的な移植に負債があることを認め、次にテスト契約で一件ずつ清算する。
1.7 FlagGems-sglang:34 件の競賽トラックオペレータをマージ、初めて Debian と RPM パッケージングを追加(10-23 ~ 10-25)
日付:2026-10-23 ~ 2026-10-25 ソース:FlagGems-sglang コミット · PR #210 · PR #191 · PR #196
- 総量:34 件マージ、39 件コミット、マージ率 87% で、組織内でマージ効率が最も高いリポジトリである。
- 競賽トラックの供給:マージの大半に
[FlagOS Competition-Track1]プレフィックスが付き、yzw1128、c2flowDS、SweetDeathh、love530love、xuanzhengdu-eng、liangkw16、sinpeyw、goldenfox2025、hangglider5 などの外部コントリビューターから提供され、MLA バッファ読み書き、レイアウト再配列、Top-K サンプリング、MoE ゼロエキスパート、キャッシュ位置特定、ソフトプーリングなど SGLang 推論チェーンのオペレータをカバーしている。 - ペース:10-23 15:47 から 18:02 までの2時間余りで33件を連続マージし、うち 16:21 から 16:31 の10分間に9件をマージ;10-25 22:37 に
memcpy_triton(#196)を追加マージし、バッチの締めくくりとした。 - エンジニアリング側:Debian と RPM のパッケージングを新規追加し(#191)、SQLAlchemy 1.4 互換性も修正(#190)。このリポジトリが単なるオペレータ集合にとどまらず、インストール可能な配布物の役割を担い始めたことを示している。
- 審査中:新規オープンの PR 13 件は依然として競賽トラックのオペレータが中心(#207 から #220)で、ほかにデバイスメタデータ初期化の修正がある。
- 判断:競賽が安定したオペレータ供給チャネルとなっており、2週間でこのリポジトリは散発的なコミットからリリースパッケージを持つプロジェクトへと変わった。リスクも明らかである——審査負荷が1つのリポジトリに集中し、1人1日で十余件をマージでき、契約の一貫性は事後のテストバッチ補充に依存している。
1.8 Torch-FL:ベンダー命名リファクタリングを一気に完遂、2日間で16件マージ(10-23 ~ 10-25)
日付:2026-10-23 ~ 2026-10-25 ソース:Torch-FL コミット · PR #643 · PR #649 · PR #653 · PR #639
- 総量:16 件マージ、16 件メインブランチコミット、すべて lvyufeng が主導。
- 命名リファクタリング(#645 ~ #650):ボックス化スロットを
Backend::kCudaからBackend::kBoxingに変更し(#645)、各プラットフォームにベンダー名を付与し(#646)、ベンダー別にソースと CI ディレクトリ(#647)、設定とマーカーとパッケージングディレクトリ(#648)、バックエンド列挙と NVIDIA ルーティングキー(#649)をリネームし、最後にリネームで残ったテーブル参照の不整合を修正した(#650)。6件は 13:38 から 15:59 の間に行われた。 - セマンティクス修正(#643):「デフォルト設定からのボックス化ルーティングを行ってはならない」ことを明確化し、ボックス化専用の day-0 設定を新設——これは「あるプラットフォームでオペレータが欠けるとパッケージングパスにフォールバックする」という暗黙の動作を明示的な宣言に変えるものである。
- プラットフォーム修正:MPS 側では MPSGraph のブロードキャスト形状を維持し(#640)、線形オペレータのテストケースに CPU リファレンスと可読な差分を追加し(#606)、Qwen3.5 のビジョンファクトリと補間を MPS に残した(#639);CUDA 側ではオペレータを空スロットではなく FlagGems にルーティングした(#638);#653 は MPS wheel のプラットフォーム命名とプレフィックス事前チェックを修正。
- 審査中:新規オープン4件、うち DCU ランタイムを CUDA ソースからビルドするよう変更(#654)、CMake のプラットフォーム解析が2種の綴りに対応(#651)、天数の非内側リダクションでマスク行ブロックを回避(#644);ほかに #603 の FlagCICD 契約化オーケストレーションが依然審査中。
- 判断:6つの PR にまたがる命名リファクタリングを1午後で完了できたことは、Torch-FL のベンダー抽象化レイヤーが依然薄く、結合が制御可能であることを示す;ボックス化動作の明示化は「サイレントフォールバック」という最も追跡困難な問題への正面からの対処である。
1.9 推論プラグイン:vllm-plugin-FL が MiniMax-M3.1 に接続、sglang-plugin-FL が海光 Qwen3.6 MTP デコードを補完(10-23 ~ 10-24)
日付:2026-10-23 ~ 2026-10-24 ソース:vllm-plugin-FL PR #631 · sglang-plugin-FL PR #149 · FlagGems-vllm PR #975 · FlagGems-vllm PR #991
- vLLM 側:10-24 08:25 に MiniMax-M3.1 サポートと推論サンプルをマージ(#631)。これは九芯交付のコード側における整合動作である。10-23 10:24 には別途、FlagGems-vllm の数学 shim の修正を CI に固定するコミットがある(#610)。
- SGLang 側:海光が eager モードでの Qwen3.6 の MTP デコードを実装(#149、10-23 15:23)。同日、サポートモデルとチップのリストを更新(#151)。
- オペレータ側:FlagGems-vllm は 10-23 に PPU の
flash_mla_sparse_fwdをマージし(#975)、摩尔線程のtop_k_per_row_prefillの狭い値帯での順序誤りを修正し(#831)、PH1 のブロックスケーリング FP8 bmm を最適化し(#893)、persistent_topk にサンプリングパスを追加した(#991)。 - 審査中:vllm-plugin-FL 14 件、sglang-plugin-FL 6 件が調査期間内に更新。うち sglang-plugin-FL #153 は昇騰の混合視覚言語バッチ処理と決定性リダクションを修正し、#139 は天数 SGLang 0.5.18 の empty ランタイム適応を補完する。
- 判断:2 つのプラグインリポジトリは 1 件あたりのマージ量は多くないが、各件が各ベンダーの実際の推論チェーンに対応している。九芯交付のソフトウェア側の証拠は、最終的にこれらの PR のモデルカードバージョンマトリクスに落ち着く。
1.10 その他のリポジトリ:FlagTree が MTHREADS バックエンドを追従、FlagTrain が融合オペレータを追加、optest がコマンドラインを三改一 revert(10-23 ~ 10-25)
日付:2026-10-23 ~ 2026-10-25 情報源:FlagTree PR #1416 · FlagTree PR #1436 · FlagTrain PR #15 · optest PR #10 · FlagBLAS PR #154
- FlagTree:メインブランチは 1 件のみ——摩尔線程バックエンドを上流
0842829c1に追従(#1416)。審査中 14 件、重点は昆仑芯の分散 TLE バックエンド(#1436、10-25 新規)、tle.gpu.copyへの pad_value 追加(#1429)、明示的 tile コピー範囲(#1433)、昇騰tl.whereのポインタオペランド受け入れ(#1430)、バックエンド別の deb パッケージング(#1417)。 - FlagTrain:
wf6af16_linear融合オペレータをマージ(#15)。英偉達、昇騰、天数、沐曦の 4 社の Triton 実装をカバー。審査中にはmoe_gemm(#31)、fp8_gemm(#18)、mixed_gemm(#10)があり、訓練側のオペレータ供給を補完中。 - optest:1 日で三改一 revert——現在と明示的プロジェクトディレクトリをサポート(#7)、遺留 root profile を削除(#8)、レポートコマンドをデフォルト作業ディレクトリに変更(#9)、その後 #8 を revert(#10)。revert は profile 方案の保持が必要であることを示し、試験的な収束である。
- FlagBLAS:10-24 に新規 PR #154「Add T-Head L1 support」をオープン。達摩院玄鉄の L1 オペレータを BLAS ライブラリに接続。デフォルトブランチに新規コミットなし。
- Trident と FlagSparse:Trident の
feature/monadブランチは 10-24 から 10-25 に 5 回プッシュされ、PR #4 で Monad 中間層を導入して計算合成を実施。FlagSparse はzyq_sparseブランチのみプッシュがあり、メインブランチは静穏。 - docs と release-info:docs はボットがモデルリストブランチを 3 回プッシュ(ModelScope、愛幻芯、Hugging Face 各 1 回)、対応する PR は依然審査中。release-info の gh-pages は 3 回更新されたが、31 リポジトリの原子核查では新規 Tag や Release は見られない。
2. ニュース報道とエコシステム
2.1 InfoQ 長文が FlagOS 2.2 を振り返る:メンバー単位 107 社、四半期ダウンロード 46.4 万回(10-24)
日付:2026-10-24 情報源:InfoQ:智源衆智 FlagOS 2.2 がフロンティアモデルと多元算力の協調進化を可能に
- エコシステム口径:第3四半期時点で、FlagOS エコシステムのメンバー単位は107社、四半期コミュニティダウンロード数は464,336回で、第2四半期の4.76倍。コード貢献者は264名で、前バージョン比55%増。
- 開発量口径:2.1から2.2にかけて、マージされた PR は1,890から4,890に増加、コードコミットは5,100から9,730に増加、新規 Issue は420から1,423に増加。
- 技術口径:九大オペレータライブラリの合計は1,454オペレータで、前バージョン比890増。千以上のオペレータ、10款のチップ範囲におけるクロスチップ全体性能は約27%向上。GLM-5.3-Flash は既存の昇騰 910B 上で論理サービススループットが8.52kから17.36k tokens/sに向上(2.04倍)、512K 長コンテキスト生成は60.9 tokens/s。
- コスト口径:1台8カード 910B の月額レンタル16,500元、3P1D デプロイ、93%キャッシュヒット率で試算すると、256K 入力8並列シナリオでは百万出力 Token あたり59.27元、512K 入力4並列では104.53元となり、それぞれ対応する商用 API 課金参考値より19.4%と27.6%低い。
- 判断:これは2.2リリース後で最も完全な中文技術振り返りであり、その価値は性能数字だけでなく、比較可能なコミュニティ指標(ダウンロード数、貢献者、PR 数)を示している点にある。コスト項目は「レンタル料按分」による試算であり、同一負荷での実測対照ではない点に注意が必要で、引用時にはこの限定を保持すべきである。
2.2 沐曦と摩尔線程が同日に MiniMax M3.1 Flash Day-0 適配を発表(10-23)
日付:2026-10-23 情報源:新浪科技:沐曦曦雲 C シリーズ Day 0 で MiniMax M3.1 Flash を走通 · 界面新聞:摩尔線程が MiniMax M3.1 Flash 適配を完了
- 沐曦:10-23のオープンソース当日、曦雲 C シリーズが Day 0 深層適配を完了。公式は MXMACA フルスタックソフトウェアスタック(ドライバ、MXCC コンパイラ、オペレータライブラリ、推論フレームワーク適配)に依拠すると説明。2025年12月以来、45個のフラッグシップモデルの Day-0 適配を完了しており、これは MiniMax フラッグシップへの4回目の追随となる。
- 摩尔線程:同日、フラッグシップ訓推カード MTT S5000 と MUSA ソフトウェアスタックにより適配を完了。表現は「Day-0」ではなく「適配を完了」。
- 口径の辨析:両社の通稿が強調するのは自社ソフトウェアスタック(MXMACA と MUSA)の能力である。FlagOS 側の成果物は FlagRelease の九芯 W8A8 リポジトリと vllm-plugin-FL、sglang-plugin-FL の2つのプラグインである。両者は同時に真であり得るが、同一の事柄ではない——ベンダー口径は単一チップの初日可用性を見るのに適し、FlagOS 口径はクロスチップの統一フォーマットとバッチ複製能力を見るのに適する。
- 判断:Day-0 はすでに国産チップベンダーの標準的なマーケティング节点となっており、メディアの「首発」「率先」といった表現はもはや珍しくない。真に区別度があるのは、成果物がダウンロード可能か、バージョンマトリクスが明記されているかであり、この点で今回の FlagOS と両社はいずれも検証可能な材料を提供している。
2.3 チャネル核查:44件の候補中3件が有効、CSDN コラムは調査期間内に新稿なし(10-26)
日付:2026-10-26 情報源:Google News RSS(プロキシ経由) · CSDN FlagOS コラム · HN Algolia
- Google News:24組の中英クエリ語のうち計44件が調査期間内に該当し、タイトルの意味ごとに1件ずつフィルタリングした結果、有効だったのは3件——InfoQの2.2振り返り、沐曦と摩尔線程のDay-0通稿。その他は株式市場の相場、燧原と清微の株価関連記事、智源コミュニティのAI研究系投稿であり、いずれもFlagOSソフトウェアスタックとは直接関係しない。
- ノイズパターン:
燧原科技 when:7dは15件がほぼ全て科創板の相場と資金調達データ;摩尔線程 オープンソース when:7dは14件がMiniMaxのオープンソース稿で埋め尽くされ;清微智能 when:7dは自媒体のタイトル釣り記事が1件ヒット。この種のクエリは今後、タイトルに「FlagOS/オペレータ/ソフトウェアスタック/チップ適配」を含む項目のみを残すようにできる。 - CSDNコラム:最新の1本は10-22 19:00の高校円卓ライブ配信予告であり、調査期間内に新しい投稿はない;コラムの現在のトップ記事は依然としてGLM-5.3-Flash九芯Day0とQwen3.8-Flash-Next八芯適配であり、いずれも以前の各号に属する。M3.1九芯のコラム稿は本調査期間の末日時点でまだ公開されていない。
- HN Algolia:8組のクエリで4日間に計36件がヒットし、
FlagOS、FlagGemsはそれぞれ3件だがタイトルが直接一致するものはなく、BAAIの30件は全てモデルと研究の議論であり、FlagOS関連はない。 - 智源コミュニティ:検索ページはクライアントサイドレンダリングであり、取得できたのはフレームページのみで、項目の情報源として利用できない;今号はこのチャネルから内容を取得していない。
3. メンバー単位とバックエンドベンダーの深掘り
3.1 海光:九芯のうちW8A8版以外に、MiniCPM-V 4.7のデュアルバージョンが同日リポジトリに格納(10-23)
日付:2026-10-23 情報源:FlagRelease モデル組織 · sglang-plugin-FL PR #149 · FlagScale PR #1299
- モデル納品:MiniMax-M3.1-Flashの
W8A8-hygon-FlagOS標準版がリポジトリに格納された;同日17:47から17:48にかけてさらに2つのMiniCPM-V 4.7リポジトリが公開された(1B BF16と35B-A3B BF16)。これは海光の視覚モデルラインにおける補完である。 - 推論チェーン:sglang-plugin-FLはeagerモードでのQwen3.6 MTPデコードをマージし(#149)、投機的デコード経路を海光に開放した;同日に対応モデルとチップのリストを更新した(#151)。
- オペレータとアテンション:FlagAttentionには2件が審査中——FP8 MSA経路の削除とテストインポートの修正(#109)、HY3バックエンドサポートの追加(#112、10-25に新規開設)。
- 訓練側:FlagScaleの審査中PR #1299はDCUハードウェアのヘルスサンプリングを追加するもので、長期審査項目に属する(9-18から)。
- 判断:海光の本調査期間における動きは「モデルラインの展開、推論ラインのMTP補完、アテンションラインの新バックエンド開設」であり、3ラインを同時に推進しているが、いずれもExpress版ではなく標準版で納品されており、FlagOS九芯におけるその位置づけと一致している。
3.2 昆仑芯:FlagGems側で十数件の修正と高速化、XPU3経路を集中的に収束(10-23)
日付:2026-10-23 情報源:FlagGems PR #7095 · PR #7110 · PR #7274 · FlagTree PR #1436
- オペレータ修正量:FlagGems の調査期間内で昆仑芯ラベル付きのマージは約 15 件、addmv、log_softmax、rnn_relu、scaled_grouped_mm、frexp、conj_physical_、unsqueeze、upsample_linear1d 逆伝播、batch ops などをカバーし、その大半に
[KunlunXin][XPU3]が付与されている。 - 性能面:
log_softmax順伝播に N==1 の高速パスを追加、unsqueezeとupsample_linear1d_backwardの高速化、foreach と or_scalar の性能修正があり、これは新機能ではなく安定化施策である。 - コンパイル面:FlagTree の審査中 #1436 で昆仑芯の分散 TLE バックエンドが提案されている(10-25 新規起票)。マージされれば昆仑芯にとって TLE 層における初の分散機能となる。
- デリバリー:九芯のうち昆仑芯は Express 版(
W8A8-kunlunxin-FlagOS-Express)であり、NVIDIA、昇騰、達摩院玄鉄と同列に並ぶ。 - 判断:昆仑芯は今期のオペレータ側修正密度が最も高いバックエンドであり、ほぼすべてが「既存オペレータが動作しない、または遅い」という種類の問題に集中している。これは前号でちょうど FlagTree の第 7 バックエンドになったタイミングと符合する——バックエンド接続後には必然的に長尾の修补期間が続く。
3.3 達摩院玄鉄:真武 Express 版をデリバリー、PPU 疎注意機構が審査中(10-23 ~ 10-25)
日付:2026-10-23 ~ 2026-10-25 情報源:FlagRelease モデル組織 · FlagGems-vllm PR #975 · FlagAttention PR #111 · FlagBLAS PR #154
- モデルデリバリー:MiniMax-M3.1-Flash の
W8A8-zhenwu-FlagOS-Expressが 10-23 にリポジトリへ格納され、4 社の Express 版の一つとなった。モデルカードに記載されたソースコードデプロイ例は達摩院玄鉄を基準プラットフォームとしている(vLLM 0.24.0、vllm-plugin-FL 0.3.0、FlagGems 5.4.0、TP=8)。 - 疎注意機構:FlagGems-vllm が PPU 側の
flash_mla_sparse_fwdをマージ(#975、10-23 17:19)、M3.1 の MLA 疎パスに対応する。FlagAttention の審査中 #111 はさらに MiniMax 疎注意機構サポートを PPU へ開放する(10-24 新規起票)。 - オペレータライブラリ拡張:FlagBLAS の審査中 #154「Add T-Head L1 support」(10-24 新規起票)は、L1 級オペレータを跨芯 BLAS に取り込む。
- 判断:達摩院玄鉄は同時に「モデルデリバリーの基準プラットフォーム」と「オペレータライブラリの新規バックエンド」の両側に現れており、FlagOS 内部において初期検証プラットフォームであると同時にオペレータカバレッジの補完対象でもあることを示す。Express 版と標準版の差異(プリセットランタイムを伴うかどうか)は今後確認する価値がある。
3.4 清微、天数、摩尔線程、沐曦:4 社がオペレータライブラリ側でそれぞれ一批のコミット(10-23 ~ 10-25)
日付:2026-10-23 ~ 10-25 情報源:FlagGems PR #6623 · FlagGems PR #7454 · FlagGems-vllm PR #893 · TransformerEngine-FL PR #148
- 清微:九芯の
W8A8-tsingmicro-FlagOS標準版が10-23 14:39にリポジトリへ格納;コード側では当該期間内に本リポジトリ専用のマージはなく、引き続きモデル納品が主体。 - 天数(Iluvatar):九芯標準版を格納;Torch-FLは審査中 #644 で非内層リダクションがマスク行ブロックを回避するよう修正(10-23 新規);sglang-plugin-FLは審査中 #139 で SGLang 0.5.18 の empty ランタイム適配を補完。
- 摩尔線程:FlagGems が FP8 行列積の TLE warp 特化をマージ(#6623)、FlagGems-vllm が
top_k_per_row_prefillの狭値帯の順序誤りを修正し PH1 の FP8 bmm を最適化(#831、#893);FlagTree は審査中 #1401 で PH1 上の混合 FP8/BF16 SQMMA パイプラインを提案。 - 沐曦:FlagGems が scaled_mm の用例収集と
andモードを修正し、convolution 逆伝播を補完(#7248、#7454、#7016);build-infra の 2.3.0 changelog は maca 3.8.1.3 をビルド名簿に記入。 - その他:TransformerEngine-FL は審査中 #148 で
generic_gemmの alpha 消失、beta 無視、3D 転置復元エラーを修正(10-23);FlagScale は審査中 #1315 で L0 から L4 の能力計画と全量夜間実行のテストルーティングを提案。 - 判断:4社に共通する特徴は「モデルリポジトリが先行し、オペレータ修正が後続する」ことで、昆仑芯、海光の経路と一致する。九芯納品の真のハードルはモデルリポジトリの公開ではなく、各社のランタイムマトリクスが今後数週間にわたり継続して維持できるかにある。
4. 総括とトレンド観察
- Day-0 納品がバッチ化段階へ:一週間内に GLM-5.3-Flash 九芯と MiniMax-M3.1-Flash 九芯が連続して同日同時リリースされ、今回は W8A8 単一経路、4社の Express 版に統一。納品の再現性は確立され、次の観察点は「同一フォーマットが異なるモデル上で安定するか」およびモデルカードのバージョンマトリクスが上流のアップグレードに同期して更新されるかにある。
- 2.3.0 は「認可済み、未リリース」の懸置期にある:build-infra のゲート、changelog、再ビルド認可、バージョンパラメータ化の4項目がすべて整い、タグはまだ打たれていない。2.2 リリース前と異なるのは、今回「コンテナ起動時にコンポーネントバージョンを選択する」ことを正式な機能とした点で、ランタイムとオペレータライブラリ、コンパイラのバージョン分離を意味し、長期的には適配と検証の粒度を変えることになる。
- 組織のアクティビティが量子スタックに高度集中:FlagQuantum 単一リポジトリでコミットの82.5%、マージの54%を占める。この集中は急速な構造再編(QEC パッケージ分割、Quafu SDK 切り替え)をもたらす一方、組織レベルでの「非量子側」のスループットを明らかに低下させた——1日平均マージは163件から91件へ減少し、主な差分は FlagGems と FlagGems-sglang の落ち込みによる。
- 競賽トラックがオペレータ供給の主チャネルに:FlagGems-sglang の34件のマージのうち大半が外部コントリビュータの
Competition-Track1に由来し、2時間以内に30件をマージ可能。供給が速く審査が集中するため、テスト契約の補完は事後バッチに依存しており、このチャネルの長期的品質は欠陥回帰率を観察する必要がある。 - ベンダー側修正がロングテール期に:昆仑芯、昇腾、沐曦、摩尔線程の本期の動きは「既存オペレータを使える状態に修正する」が中心で、他に CPU オペレータの誤移植の巻き戻しが1件。これはバックエンド接続後の必然的な段階であり、2.2 の1,454オペレータ清单が実チップ上で依然としてカバレッジと精度のギャップを持つことを示す。
- 情報面は比較的平穏:44件のニュース候補のうち有効はわずか3件、新バージョンリリースなし、新リポジトリ作成なし(新規リポジトリはいずれも10-13から10-14に作成)。本期の内容主体は GitHub 発であり、典型的な「コード活発、リリース静穏」の期間に属する。
- 限界説明:本期のコミット検索は GitHub search の total_count 基準(612件)であり、コミット URL で重複排除後に逐条リポジトリへ帰属させたが、一部リポジトリではページ跨ぎの重複により±1の誤差が生じる可能性がある;FlagQuantum の505件はマージコミットとブランチ同期コミットを含み、505件の機能変更と同一視できない;FlagRelease のタイムスタンプは Hugging Face の UTC 記録であり、北京時間に換算済み;ベンダー通稿の「Day-0」「率先」等の表現は会社側の口径であり、第三者検証は得ていない;InfoQ のコスト数値は賃料換算による試算であり、実測対照ではない。
付録:情報源核查表と完全な情報源リスト
情報源核查表
| 情報源 | 検証結果 |
|---|---|
| GitHub 組織リポジトリ API | 61 リポジトリ全量返却、16 リポジトリが 72 時間の調査期間内にプッシュあり |
| GitHub コミット検索 | 612 件(5 ページ上限後に第 6 から第 8 ページを補充)、URL で重複排除し 11 リポジトリに帰属 |
| GitHub マージ済み PR 検索 | 274 件が調査期間内にマージ、最多は FlagQuantum の 148 件 |
| GitHub レビュー中 PR 検索 | 253 件が調査期間内に更新、うち新規オープン 141 件 |
| GitHub org イベントストリーム | 99 件、PR 50、プッシュ 20、ブランチ削除 15、ブランチ作成 8 |
| リリースとタグの原子的検証 | 31 リポジトリすべてで新規ゼロ、4 日間の調査期間内に正式リリースなし |
| Atom フォールバック | docs、FlagBLAS、FlagSparse、Trident、release-info の 5 リポジトリを補足調査、いずれも非デフォルトブランチに該当 |
| FlagRelease モデル組織 | 60 リポジトリの最終更新を検証、調査期間内に MiniMax-M3.1 リポジトリ 9 件と MiniCPM-V 4.7 リポジトリ 2 件が新規追加 |
| Hugging Face モデルカード | MiniMax-M3.1-Flash のマルチチップ説明ドキュメントがリポジトリ初日にリリース、9 チップリストと Express ルールを検証可能 |
| Google News RSS | 中英語 24 組のクエリで 44 件の候補、有効 3 件(プロキシ経由) |
| HN Algolia | 8 組のクエリで 4 日間 36 件ヒット、タイトル直接一致なし |
| CSDN FlagOS コラム | 最新稿は 10-22 のライブ配信予告、調査期間内に新規稿なし |
| 智源コミュニティ | 検索ページがクライアントサイドレンダリングのためフレームページのみ取得、今期は未採用 |
| 収録待ちキュー | 当日ファイルには RISC-V 項目のみ含まれ既に消費済み、本テーマに指定項目なし |
完全な情報源リスト
- [1] FlagOS 組織リポジトリ — https://github.com/orgs/flagos-ai/repositories
- [2] FlagOS コミット検索(org:flagos-ai) — https://github.com/search?q=org%3Aflagos-ai+committer-date%3A%3E2026-10-22T22%3A00%3A00Z&type=commits
- [3] FlagOS マージ済み PR 検索 — https://github.com/search?q=org%3Aflagos-ai+is%3Apr+is%3Amerged+merged%3A%3E%3D2026-10-22T22%3A00%3A00Z&type=pullrequests
- [4] MiniMax-M3.1-Flash の FlagOS マルチチップ対応説明 — https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash/blob/main/docs/FlagOS-Multi-Chip-Support-and-Downloads.md
- [5] FlagRelease モデル組織 — https://huggingface.co/FlagRelease
- [6] build-infra PR #1472(changelog ゲート) — https://github.com/flagos-ai/build-infra/pull/1472
- [7] build-infra PR #1475(2.3.0 changelog 日付、寒武紀) — https://github.com/flagos-ai/build-infra/pull/1475
- [8] build-infra PR #1480(FLAGTREE_VERSION=latest) — https://github.com/flagos-ai/build-infra/pull/1480
- [9] build-infra PR #1482(FLAGGEMS_VERSION 起動時選択) — https://github.com/flagos-ai/build-infra/pull/1482
- [10] build-infra PR #1484(2.3.0 再ビルドを承認) — https://github.com/flagos-ai/build-infra/pull/1484
- [11] build-infra PR #1487(2.3.0 changelog 日付、沐曦) — https://github.com/flagos-ai/build-infra/pull/1487
- [12] FlagQuantum コミット — https://github.com/flagos-ai/FlagQuantum/commits/main
- [13] FlagQuantum PR #749(QEC パッケージ再編を主干へ統合) — https://github.com/flagos-ai/FlagQuantum/pull/749
- [14] FlagQuantum PR #832(FTQC Stage A パイロット) — https://github.com/flagos-ai/FlagQuantum/pull/832
- [15] FlagQuantum PR #862(Quafu ツインライフサイクル移行) — https://github.com/flagos-ai/FlagQuantum/pull/862
- [16] FlagQuantum PR #866(旧 Quafu 実行ライフサイクルの廃止) — https://github.com/flagos-ai/FlagQuantum/pull/866
- [17] FlagQuantum PR #876(有限動的コヒーレンス参照) — https://github.com/flagos-ai/FlagQuantum/pull/876
- [18] FlagGems コミット — https://github.com/flagos-ai/FlagGems/commits/master
- [19] FlagGems PR #7095(addmv_out 境界) — https://github.com/flagos-ai/FlagGems/pull/7095
- [20] FlagGems PR #7274(scaled_grouped_mm FP8 デコード) — https://github.com/flagos-ai/FlagGems/pull/7274
-
[21] FlagGems PR #6623(摩尔線程 FP8 warp 特化) — https://github.com/flagos-ai/FlagGems/pull/6623
[22] FlagGems PR #7199(誤って移植された CPU オペレータの撤回) — https://github.com/flagos-ai/FlagGems/pull/7199
- [23] FlagGems-sglang コミット — https://github.com/flagos-ai/FlagGems-sglang/commits/master
- [24] FlagGems-sglang PR #210(batch7 オペレータ) — https://github.com/flagos-ai/FlagGems-sglang/pull/210
- [25] FlagGems-sglang PR #191(Debian と RPM パッケージング) — https://github.com/flagos-ai/FlagGems-sglang/pull/191
- [26] FlagGems-sglang PR #196(memcpy_triton) — https://github.com/flagos-ai/FlagGems-sglang/pull/196
- [27] Torch-FL コミット — https://github.com/flagos-ai/Torch-FL/commits/main
- [28] Torch-FL PR #643(デフォルト設定のルーティングボックス化を禁止) — https://github.com/flagos-ai/Torch-FL/pull/643
- [29] Torch-FL PR #649(バックエンド列挙をベンダー命名に変更) — https://github.com/flagos-ai/Torch-FL/pull/649
- [30] Torch-FL PR #653(MPS wheel プラットフォーム命名) — https://github.com/flagos-ai/Torch-FL/pull/653
- [31] Torch-FL PR #639(Qwen3.5 ビジョン on MPS) — https://github.com/flagos-ai/Torch-FL/pull/639
- [32] vllm-plugin-FL PR #631(MiniMax-M3.1 サポート) — https://github.com/flagos-ai/vllm-plugin-FL/pull/631
- [33] sglang-plugin-FL PR #149(海光 Qwen3.6 MTP) — https://github.com/flagos-ai/sglang-plugin-FL/pull/149
- [34] FlagGems-vllm PR #975(PPU スパース MLA フォワード) — https://github.com/flagos-ai/FlagGems-vllm/pull/975
- [35] FlagGems-vllm PR #991(persistent_topk サンプリングパス) — https://github.com/flagos-ai/FlagGems-vllm/pull/991
- [36] FlagTree PR #1416(MTHREADS バックエンドのバージョン追従) — https://github.com/flagos-ai/FlagTree/pull/1416
- [37] FlagTree PR #1436(昆仑芯分散 TLE バックエンド、レビュー中) — https://github.com/flagos-ai/FlagTree/pull/1436
- [38] FlagTrain PR #15(wf6af16_linear 融合オペレータ) — https://github.com/flagos-ai/FlagTrain/pull/15
- [39] optest PR #10(root profile のロールバック) — https://github.com/flagos-ai/optest/pull/10
- [40] FlagBLAS PR #154(達摩院玄鉄 L1 サポート、レビュー中) — https://github.com/flagos-ai/FlagBLAS/pull/154
- [41] FlagAttention PR #111(PPU 上の MiniMax スパースアテンション、レビュー中) — https://github.com/flagos-ai/FlagAttention/pull/111
- [42] TransformerEngine-FL PR #148(generic_gemm 修正、レビュー中) — https://github.com/flagos-ai/TransformerEngine-FL/pull/148
- [43] FlagScale PR #1299(海光 DCU ヘルスサンプリング、レビュー中) — <https://github.com/flagos-ai/FlagScale/pu
ll/1299>
- [44] InfoQ:FlagOS 2.2 技術振り返り — https://www.infoq.cn/article/mhdJwMMzYFedMFHKfHWs
- [45] 新浪科技:沐曦曦雲 C シリーズ Day 0 で MiniMax M3.1 Flash に適合 — https://finance.sina.com.cn/tech/roll/2026-10-23/doc-iniweyws1962961.shtml
- [46] 界面新聞:摩尔線程が MiniMax M3.1 Flash への適合を完了 — https://m.sohu.com/a/1091492646_313745
- [47] CSDN FlagOS コラム — https://flagos.csdn.net/
- [48] HN Algolia 検索 — https://hn.algolia.com/api/v1/search_by_date?query=FlagOS&tags=story