調研視窗：2026-11-03 06:00 ~ 2026-11-04 06:00（北京時間，24 小時；接續上一期日報截點）。

信源：GitHub（org: flagos-ai 61 倉庫全量核查、228 筆提交、177 筆合併 PR、271 筆視窗內更新在審 PR、117 筆新開、24 倉推送、31 倉 Release 與 8 倉 Tag 原子核查）、Google News RSS（24 組中英文查詢詞，走代理）、HN Algolia（8 組）、CSDN FlagOS 專欄（逐篇核時）、智源社群（詳見附錄信源清單）。

本期索引

  • 今日重點：vLLM 0.28 線四後端同日收口；FlagGems 兩分鐘 23 筆基準遷移；2.3.0 補上 CANN 9.2.1 第五層（11-03）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：24 倉推送、228 筆提交、177 筆合入，全組織在審 1602 筆（11-03 ~ 11-04）
    • 1.2 版本面：2.3.0 補上第五層 CANN 9.2.1，base 映象刻意不帶 FlagTree（11-03）
    • 1.3 vLLM 0.28 線四後端同日收口：清微、沐曦 C550、摩爾執行緒 MUSA、昇騰解碼圖（11-03）
    • 1.4 FlagGems 基準參考：兩分鐘 23 筆合入，H800 參考讀入統一到單一 JSON（11-03）
    • 1.5 FlagGems KernelGen：天數 BI-V150 十分鐘十筆，英偉達十二筆，崑崙芯與燧原各補一段（11-03）
    • 1.6 FlagQuantum：布林暫存器選擇進入 qfunc/Qmod 前臺，Pauli SELECT 降到門級（11-03）
    • 1.7 訓練與運算元庫：TransformerEngine 新增壁仞 SUPA 後端，FlagTensor 補 MUSA，Megatron 接 DSv4（11-03）
    • 1.8 融合通訊運算元：RS+add+RMSNorm+AG 環形核進入 FlagGems 與 SGLang 外掛（11-03）
    • 1.9 配套基建：optest 飛書通知帶測試摘要，FlagTree CI 遷飛書多維表，FlagQAI 收緊 macOS 沙箱（11-03）
  • 二、新聞報道與生態
    • 2.1 渠道核查：24 組查詢零元件級命中，CSDN 與 HN 視窗內無新文（11-04）
    • 2.2 產業側：成員單位在烏鎮峰會獲傑出貢獻獎，燧原科技登陸 A 股（11-03）
  • 三、成員單位與後端廠商深挖
    • 3.1 清微智慧：TXDA 在 0.28 上只做 eager，把圖模式明確拒掉（11-03）
    • 3.2 沐曦：C550 的 0.28 是「空適配」，改動全部留在外掛內（11-03）
    • 3.3 摩爾執行緒：MUSA 0.28 一次帶進原生 MCCL 與分段圖（11-03）
    • 3.4 昇騰：0.28 解碼圖、CANN 9.2.1 base、INT8 BMM、910C CI 四處並進（11-03）
    • 3.5 天數、崑崙芯、燧原、玄鐵、海光與地平線：一側批次補運算元，一側繼續調優（11-03）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表、完整信源清單

今日重點：vLLM 0.28 線四後端同日收口；FlagGems 兩分鐘 23 筆基準遷移；2.3.0 補上 CANN 9.2.1 第五層（11-03）

日期：2026-11-03　來源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #554 · vllm-plugin-FL PR #575 · vllm-plugin-FL PR #646 · FlagGems PR #8294 · build-infra PR #1614（全量見附錄）

  • 推理線：vLLM 0.28.0 在一天之內被清微、沐曦、摩爾執行緒、昇騰四條後端同時收口，合計加 17051 行減 789 行、150 個檔案。四筆的形態各不相同：清微把圖模式整體撤掉只留 eager，沐曦在沒有任何廠商 0.28 路徑的前提下做「空適配」，摩爾執行緒把原生 MCCL 與分段圖一併帶進來，昇騰補的是解碼專用圖。同一個上游版本，四種落地策略，說明 FlagOS 的多晶片適配已經進入「按後端算賬」而非「照模板複製」的階段。
  • 運算元線：FlagGems 在 16:41 與 16:42 兩分鐘內合入 23 筆，其中 21 筆由同一作者提交、全部是把各後端基準的參考資料讀入從散落的 reader 遷到統一 JSON。這不是功能開發，而是評測可比性的基礎設施——只有參考值來自同一份資料，跨後端的分數才有意義。同日 FlagGems 合計合入 76 筆，佔全組織 177 筆的 42.9%。
  • 版本線：build-infra #1614 為 2.3.0 補上第五層 base 映象 CANN 9.2.1（僅 910B、python 3.12、torch 2.13 與 triton_ascend 3.6.0），#1615 隨即把該層的 changelog 日期按 registry 推送時間回填。映象層面 2.3.0 已覆蓋 base、寒武紀 neuware 4.4.3、沐曦 maca 3.8.1.3、海光 dtk26.10、AMD rocm7.2.4 與昇騰 CANN 9.2.1，但 community 的 release/2.3 清單仍返回 404，釋出仍未跨過清單凍結這一步。
  • 判斷：當日 177 筆合入、117 筆新開、271 筆視窗內更新在審，全組織在審存量 1602 筆。與上一視窗（162 筆合入、192 筆新開）相比，合入升 9.3%、新開降 39.1%，評審端首次出現「消化快於生產」的跡象。但新開量的回落主要來自 FlagGems 單倉（77 筆，其中 59 筆出自同一作者），並不代表整體需求降溫。

一、開源專案進展（GitHub 動態）

1.1 組織節奏：24 倉推送、228 筆提交、177 筆合入，全組織在審 1602 筆（11-03 ~ 11-04）

日期：2026-11-03 ~ 2026-11-04　來源：flagos-ai 組織倉庫 · 提交檢索 · 合併 PR 檢索 · 在審 PR 檢索

  • 倉庫面：61 倉中 24 倉視窗內有推送，為近兩週最高。按推送時間從近到遠為 vllm-plugin-FL、FlagTree、FlagQuantum、FlagTensor、FlagGems、TransformerEngine-FL、release-info、build-infra、Trident、docs、optest、Megatron-LM-FL、FlagDNN、FlagGems-vllm、FlagTrain、Torch-FL、FlagGems-sglang、FlagCX、FlagAttention、FlagSparse、FlagQAI、sglang-plugin-FL、OpenCourse、flir。其中 release-info 的推送仍是 gh-pages 自動部署，無原始碼變更。
  • 提交面：提交檢索命中 228 筆，分倉為 FlagQuantum 108、FlagGems 47、FlagQAI 12、FlagGems-sglang 9、FlagSparse 8、FlagGems-vllm 8、optest 7、build-infra 5、FlagTensor 5、FlagDNN 4、FlagCX 3、FlagTree 3、FlagTrain 3、Torch-FL 2、FlagAttention 2、flir 1、sglang-plugin-FL 1。量子棧一倉佔 47.4%，較上一期的 44.9% 略有回升。
  • 合入面：合併 PR 177 筆，來自 19 倉：FlagGems 76、FlagQuantum 28、vllm-plugin-FL 14、FlagGems-sglang 9、FlagGems-vllm 8、FlagTree 8、optest 7、FlagQAI 6、build-infra 5、FlagTrain 3、FlagCX 3、Torch-FL 2、FlagAttention 2，FlagTensor、Megatron-LM-FL、TransformerEngine-FL、FlagSparse、sglang-plugin-FL、flir 各 1。這是近期後端與元件覆蓋最寬的一次合入分佈。
  • 在審面：視窗內有更新的在審 PR 271 筆，新開 117 筆。分倉為 FlagGems 146（新開 77）、FlagGems-vllm 30（9）、FlagTree 28（5）、vllm-plugin-FL 17（8）、sglang-plugin-FL 8（3）、Torch-FL 7（1）、FlagTrain 6（3）、FlagAttention 4、flir 3（1）、FlagQuantum 3（3）、FlagCX 3（2）、FlagScale 3、docs 3（1）、Trident 2、FlagDNN 2（1）、Megatron-LM-FL 1（1）、TransformerEngine-FL 1、optest 1（1）、build-infra 1、FlagQAI 1（1）、FlagTree-AscendNPU-IR 1。按當前檢索口徑，全組織在審 PR 存量 1602 筆，合入與在審之比約 1 比 9。
  • 作者面：合入側 FlagQuantum（機器人賬號）36 筆、lukatao 33 筆、youseeyouonedayday 12 筆、xuanzhengdu-eng 10 筆、wuwentao 8 筆、physics31415926 6 筆、github-actions 機器人 6 筆。新開側 youseeyouonedayday 一人 59 筆，佔當日新開的 50.4%，其餘為 SeddonShen 4、tonyh168 4、FlagQuantum 4、lukatao 3、Kaiwen1024 3。
  • 對比：上一視窗（11-02 06:00 ~ 11-03 06:00）為 162 筆合入、192 筆新開、311 筆視窗內更新在審。本視窗合入升 9.3%、新開降 39.1%、視窗內更新在審降 12.9%。三項合起來指向同一件事：評審端在加速消化存量，而新增開發單的絕對量由 FlagGems 一家主導。

1.2 版本面：2.3.0 補上第五層 CANN 9.2.1，base 映象刻意不帶 FlagTree（11-03）

日期：2026-11-03　來源：build-infra PR #1614 · build-infra PR #1615 · build-infra PR #1613 · community 2.2 釋出清單

  • 新增 base 層：#1614 新增 base/ascend-cann9.2.1（aarch64 + ubuntu 24.04，僅 910B），帶 CANN 9.2.1 toolkit、910B ops 包、NNAL 與既有的 /etc/profile.d/vendor.sh 環境捕獲，並補 configs.yaml 行、cann921 runner 覆蓋與 verify 節點別名。加 198 行、5 個檔案。
  • 為什麼是 python 3.12：PR 正文寫明兩條硬約束——flagos-pypi-ascend 上 torch 2.13、torch-npu 2.13、torchvision 0.28、torchaudio 2.11 的 wheel 只有 cp312；CANN 的 set_env.sh 會把它自帶的 python 樹塞進 PYTHONPATH，base 直譯器必須與執行時 venv 完全一致，否則匯入會串版本。配套把 triton 釘在 3.6.0 併疊加 triton_ascend 3.6.0，numpy 釘 1.26.4。
  • 為什麼刻意不帶 FlagTree 與 FlagCX：FlagTree 尚無 CANN 9.2.x 的版本釘固，9.2.1 也沒有對應的 flagcx wheel，因此這一層把 flagtree、flagcx、env.app、deps_app 全部留空，構建順序改為 base → 不帶 FlagTree 的 runtime → FlagTree builder → FlagTree wheel → 重新整理 runtime。預設 flagtree 時編譯器回落到 triton。
  • 版本標記：#1615 是機器人提交，把 2.3.0 標籤下各後端待寫的 changelog 條目按 registry push_time 落日期，本條對應 ascend-cann9.2.1 層，加 305 行減 5 行、4 個檔案，不改任何映象內容。另 #1613 讓執行時的 FlagTree 版本請求支援顯式 --index-url，為上述「多次構建」鏈路留出口。
  • 釋出態核查：31 倉 Release 與 8 倉 Tag 原子核查，視窗內沒有新的 Release 物件。community 側 release/2.3/release-2.3.yaml 仍返回 404，release/2.2 清單在架。映象已覆蓋六層，清單凍結與站點上線兩步仍未發生，與上一期判斷一致。
  • 待觀：base 層從四層擴到六層而清單未動，2.3.0 的「映象先行」特徵進一步強化。若本週仍不凍結清單，實際釋出的版本內容將與 2.3.0 規劃產生偏離。

1.3 vLLM 0.28 線四後端同日收口：清微、沐曦 C550、摩爾執行緒 MUSA、昇騰解碼圖（11-03）

日期：2026-11-03　來源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #554 · vllm-plugin-FL PR #575 · vllm-plugin-FL PR #646 · vllm-plugin-FL PR #676

  • 清微 TXDA：#642 把 TXDA 後端適配到 vLLM 0.28.0，明確「只做 eager」。圖模式不是壞了而是被主動放棄——分段原生圖在 TP8 下已透過兩個模型的完整門禁（快照 R10 / R6d），但 Dense TP1 的正確性始終未解決，於是 PR 刪掉 TXDA 的圖捕獲與切分實現，在配置階段直接拒絕圖與編譯配置並提示 --enforce-eager。MLA、稀疏注意力、投機解碼與上下文並行同樣按具體不支援路徑逐項拒絕，而不是一刀切。加 3067 行減 146 行、29 個檔案。
  • 沐曦 C550：#554 在廠商側還沒有 0.28 路徑的前提下做「0.28-empty」適配——所有改動留在 vllm_fl/ 與 MetaX CI 指令碼內，後端行為以 vendor_name == "metax" 或 MetaX 執行時為門。按既有生命週期約定，早期 import 修復從外掛入口裝，kernel 與 backend 替換放 vendor patch 包，不寫 site-packages 的 .pth，並在 setup.sh 裡清掉 15 個歷史 zz_fl_*.pth 鉤子。加 2838 行減 70 行、36 個檔案。
  • 摩爾執行緒 MUSA：#575 把 MUSA 升到 0.28.0，帶原生 MCCL、FX/eager 編譯與分段原生圖，加 7804 行減 233 行、46 個檔案。執行基線為四張 S5000、BF16、TP=4，TorchMUSA 2.9.0 與 MUSA SDK 4.3.5；編譯側 RMSNorm、SiLU、rotary 走顯式 MUSA 運算元邊界，參考 RMSNorm 保留目標端的 FP32 累加契約；圖處理集中在 dispatch/backends/vendor/musa/graph.py，並刪掉 MUSA 編譯子包與可執行快取。
  • 昇騰解碼圖：#646 在 0.4.0-dev 上開 FULL_DECODE_ONLY 的原生圖捕獲與回放，覆蓋 Qwen3.6-27B 與 Qwen3.6-35B-A3B，解碼走 torch.npu.NPUGraph，prefill、視覺編碼與取樣留在圖外。加 3342 行減 340 行、39 個檔案，是 #606 與 #619 的向前移植。
  • 雙線並行：與 0.28 收口同時，0.32 的適配正在評審佇列裡推進——vllm-plugin-FL 有 #675（燧原 S60）、#674（天數）、#659（AMD ROCm gfx1100）、#693（沐曦 C550）、#667（統一 FL 執行並適配燧原）五筆在審。0.28 是維護線、0.32 是目標線，兩條線同時跑已成常態。
  • 同步機制：0.4.0-dev 向 0.5.0-dev 的 forward-sync 本視窗合入 #676、#678、#688、#689 四筆，從「整分支合併」改為「按審閱增量重放並保留源提交」，衝突以草稿 PR 公開。

1.4 FlagGems 基準參考：兩分鐘 23 筆合入，H800 參考讀入統一到單一 JSON（11-03）

日期：2026-11-03　來源：FlagGems PR #8293 · FlagGems PR #8294 · FlagGems PR #8295 · FlagGems PR #8296 · FlagGems PR #8318

  • 批次規模：16:41 與 16:42 兩個合併分鐘內落地 23 筆，其中 FlagGems 21 筆、vllm-plugin-FL 2 筆，21 筆出自 lukatao。該視窗 FlagGems 共合入 76 筆，lukatao 一人 33 筆，接近半數。
  • 統一 JSON：核心是 #8293 至 #8296 四筆，分別把注意力與池化、歸約與線性代數、點態、稀疏與張量佈局四類運算元的 H800 參考讀入遷到統一 JSON。此前每類運算元各有一套 reader，參考值的來源、單位與舍入約定分散在程式碼裡；遷移後四類共用一份資料入口。
  • 後端參考修復：其餘二十餘筆按後端修參考實現——昇騰側補 tensorinv、orgqr、weight norm 反向、Cholesky solve 與分數最大池化反向的原生 H800 基線；燧原側修 baddbmm、nanquantile、masked scale 與 FlashAttention 參考；崑崙芯側保留 FloatPower 原地參考覆蓋；MUSA 側補 LDL 與四個線性代數參考；PPU 側修部分 LU 參考與重建精度。
  • 配套文件：#8318 新增「本地後端運算元測試修復」技能文件，把「先對齊參考、再判斷候選」的流程寫成可複用的操作說明；#8275 至 #8277、#5858 另修 as_strided_scatter 用例、昇騰 CTC 輸出 dtype、二項分佈 out 過載與 cumsum 精度檢查的 dtype 推導。
  • 判斷：這一批的價值不在覆蓋率，而在「可比」。跨後端分數只有在參考值同源、單位一致、舍入規則明確時才可比較。把 reader 收斂成單一 JSON 是評測體系從「各寫各的」走向「同一把尺子」的前置條件，也解釋了為什麼它能以分鐘級批次合入——改動機械、邊界清晰、不觸碰運算元實現。

1.5 FlagGems KernelGen：天數 BI-V150 十分鐘十筆，英偉達十二筆，崑崙芯與燧原各補一段（11-03）

日期：2026-11-03　來源：FlagGems PR #8093 · FlagGems PR #8085 · FlagGems PR #8124 · FlagGems PR #8255 · FlagGems PR #8265 · FlagGems PR #8110 · FlagGems PR #6501

  • 天數 BI-V150：16:04 至 16:10 的六分鐘內合入 10 筆，全部標註 KernelGen 天數產線——三類特殊多項式（shifted Chebyshev、Hermite、以及 Chebyshev 的 out 變體）、兩個上取樣與填充反向、量化最大池化、矩陣乘 smm、not_equal 與池化索引反向。這是天數的單日後端條目峰值，也重新整理了「一個後端十分鐘十筆」的節奏紀錄。
  • 英偉達長尾十二筆：稀疏與結構化四筆（_to_sparse_semi_structured、sparse_coo_tensor、crow_indices、flatten_dense_tensors）、cudnn 族兩筆（cudnn_convolution_relu、cudnn_grid_sampler_backward）、檢視與形狀兩筆（squeeze、combinations）、量化與型別兩筆（make_per_channel_quantized_tensor、_cast_Char）、線性代數一筆（lu_solve），另有 _foreach 族在非英偉達後端相容性的修復一筆。全部為 KernelGen 產線生成後人工收口。
  • 崑崙芯十一筆：#8273 一處打包三項效能改動（int cumsum 行掃描、mean 縮放摺疊、nanmedian 向量化）；#8250 讓 inner 在 XPU 上真正參與編譯並重調 tile；#8252 把 Hermite h 改走後端點態執行器；#8253 降 poisson_nll_loss 的暫存器壓力並修尾部越讀；#8262 用展開的歐幾里得演算法最佳化 lcm；#8263 最佳化 special_chebyshev_polynomial_u；#8257 補 native_batch_norm_legit_functional 的後端特化。另有 #8255 用廠商 min.o 的 SIMD 載荷與分段寬行並行加速 argmin，#8281 把 bitwise_left_shift 的非原地入口路由到調優變體，#8290 與 #8319 修 foreach 系列在 XPU 上的失敗。
  • 燧原 GCU300 四筆：#8265 修 cat/concatenate 複製核丟行尾的問題；#8259 把 silu_backward 的 div_rn 換成 tl.fdiv，修 GCU300 上的錯誤取值；#8251 讓 uniform_ 的取樣嚴格落在 [from, to)；#8254 修 clip/clip_ 在 GCU300 覆蓋層裡的關鍵字名。
  • 昇騰與 SiliconFlow：昇騰側 #8110 新增通道級 INT8 BMM（bmm_w8a8，加 519 行減 3 行），#8286 補 910C 與 950DT 的 SKU 文件；SiliconFlow 側 #6501 一次性補進 _embedding_bag、_embedding_bag_forward_only、_embedding_bag_backward 三個運算元，支援 SUM/MEAN/MAX、加權、padding 排除、空袋與終止偏移，加 7494 行減 222 行、24 個檔案。
  • 判斷：當日後端條目的分佈發生位移——天數以 10 筆領跑，英偉達以 12 筆繼續補長尾，崑崙芯 11 筆以調優為主，燧原 4 筆全部是正確性修復，玄鐵在 FlagGems 側零合入（其動作落在 PPU 編譯與外掛側，見 3.5）。這說明 KernelGen 產線已經能按廠商分別排產，而不是所有後端共用一個佇列。

1.6 FlagQuantum：布林暫存器選擇進入 qfunc/Qmod 前臺，Pauli SELECT 降到門級（11-03）

日期：2026-11-03　來源：FlagQuantum PR #1027 · FlagQuantum PR #1028 · FlagQuantum PR #1038 · FlagQuantum PR #1047 · FlagQuantum PR #1048 · FlagQuantum PR #1049

  • 布林選擇線：#1027 建立有界布林值候選的構建，#1028 按目標代價選擇布林暫存器候選，#1029 用公共工作流驗證這些候選，#1038 把有界布林選擇接到原生 qfunc 與 Qmod 前臺。四筆連起來，把「布林暫存器分配」從一個內部搜尋變成使用者程式可直接受益的編譯能力。
  • 演算法與降級：#1035 新增 SelectedMajoranaFermion，#1037 新增 SelectPauliLCU，#1036 把 Majorana 的降級推遲到編譯期，#1047 把 Pauli SELECT 降到門級。配合 #1030（經典條件 Pauli 門上的量子控制）與 #1043（繫結操作的 append），演算法層的表達力與後端可執行性之間的橋被分段建起來。
  • 語義與視覺化：#1039 捕獲原生單位元相位呼叫，#1041 暴露精確加權與全域性程式相位，#1042 捕獲有界的 within/apply 作用域，#1045 暴露受檢的清理作用域與伴隨呼叫，#1031 讓繪圖器在 TeX 裡渲染混合量子控制與經典反饋，#1044 與 #1032 補兩類可執行示例。
  • CI 複用：#1048 在 MetaX 的 CPU Core 通道試點只讀的主機本地依賴環境——當 Python 補丁版本與 pyproject 的 SHA-256 完全一致時掛載只讀依賴，否則走原安裝路徑。同一 runner 賬號、Python 3.11.17、同一 checkout 的對照結果為：環境與 Torch 準備從 23 秒降到 1 秒以內，四段合計從 122 秒降到 101 秒，四項冒煙測試結果一致。#1049 把該機制擴到 16 個 A800 runner 註冊，並要求顯式只讀繫結掛載。
  • 判斷：28 筆合入分佈在語義、演算法、降級、視覺化、CI 五條線上，沒有單點大改。這種「每條線每天推進一小段」的節奏，使量子棧的驗收單元始終可獨立復算——對一門仍在快速變動的技術而言，賬目清晰比功能多少更重要。

1.7 訓練與運算元庫：TransformerEngine 新增壁仞 SUPA 後端，FlagTensor 補 MUSA，Megatron 接 DSv4（11-03）

日期：2026-11-03　來源：TransformerEngine-FL PR #143 · FlagTensor PR #14 · Megatron-LM-FL PR #202 · FlagTrain PR #49 · FlagGems-vllm PR #1055

  • 壁仞進棧：TransformerEngine-FL #143 新增 Biren SUPA 廠商後端，加 3608 行、7 個檔案，是壁仞第一次以獨立後端形態出現在 FlagOS 的訓練元件裡。PR 正文只寫了「Add BIREN SUPA vendor」，未附硬體驗證記錄，屬於骨架先行。
  • FlagTensor 補 MUSA：#14 為 FlagTensor 註冊 MThreads/MUSA 後端並給出一小組已驗證的逐元素運算元，加 300 行減 5 行、14 個檔案。要點是為 ACOS、ACOSH、ASIN、ASINH、ATAN、ATANH、TAN 七個超越函式加 MThreads 專用重寫，繞開 MUSA Triton JIT 不支援的 libdevice 路徑；NVIDIA 與昇騰的預設重寫選擇保持不變。同日該倉另有 PPU 直啟快路徑、host 側迴圈計時與崑崙芯 tile 調優三筆提交，併合入昇騰 PR #32。
  • Megatron 接 DSv4：#202 是「DeepSeek-V4 向上遊同步」系列的第 1 筆，加 3356 行減 775 行、26 個檔案。核心是在 Float16Module 轉換模型時保住精度敏感引數——新增可選 FP32 引數標記並應用於 attention sink/APE、mHC 的 mapping 與 gates、殘差流輸出頭；把壓縮機與索引器的部分投影留在 FP8 上下文之外並對私有儲存做逆 RoPE；讓延遲的權重梯度穿過可選注意力子模組；mHC 的 Sinkhorn 迭代預設值從 10 提到 20。
  • 訓練與推理運算元：FlagTrain 三筆，含 runtime 後端目錄按後端歸併、補其他後端映象、以及上三角掩碼 softmax 前向的 Triton 實現（英偉達與昇騰）。FlagGems-vllm 八筆，含 MiniMax M3 稀疏注意力 shim 複用 FlagAttention、MiniMax TP8 的 INT8 W8A8 MoE、fused_marlin_moe 的 W8A16 多級流水、W8A8 INT8 與 FP8 的 C++ 運算元後設資料登記。
  • 判斷：新晶片進入 FlagOS 有兩條路徑——一條是從訓練元件起（TransformerEngine 加後端、FlagTensor 加後端），一條是從運算元產線起（KernelGen 逐運算元補齊）。壁仞走的是第一條且停在骨架，摩爾執行緒則在兩條路徑上同時有落地，差距在驗證深度而不在接入速度。

1.8 融合通訊運算元：RS+add+RMSNorm+AG 環形核進入 FlagGems 與 SGLang 外掛（11-03）

日期：2026-11-03　來源：FlagGems PR #8317 · sglang-plugin-FL PR #166 · FlagGems-sglang PR #279 · FlagGems PR #8347

  • 核的設計：FlagGems #8317 新增兩個融合「通訊 + 歸一化」的 Triton 核（在審，加 1403 行、3 個檔案）。fused_rs_add_rms_norm_ag 用單個環形核替代 all_reduce(x) 加 fused_add_rms_norm(x, residual)，一次完成 reduce-scatter、殘差相加、RMSNorm 與 all-gather；秩 r 只擁有 [r*chunk, min(T,(r+1)*chunk)) 的行，歸一化只在這些行上執行，殘差保持分散狀態。gather=False 時在 owner 步之後停止，只做 RS 加 add 加 RMSNorm。配套的 fused_qkv_norm_ag 處理另一端：對分散的 qkv 輸出分別歸一化 q 與 kv，rest（k_pe）原樣透傳，只跑環的 AG 一半。
  • 環的實現：資料在 C 個通道上併發搬運，通道 c 是秩上的一個環；在 PPU 810E 上直接複用 pccl 28 通道圖的環，使每一跳都走 ICN 鏈路。每次傳送後在後繼上做一次標誌自增，接收方等 flag >= base + step；標誌只增不減、緩衝奇偶每次呼叫翻轉，因此前驅跑進第 n+1 次呼叫時不會碰到第 n 次仍在讀的資料。
  • 上層接入：sglang-plugin-FL #166 在玄鐵側把這組 RS + norm + AG 融合核做成 pure TP prefill 的可選項（在審）；FlagGems-sglang #279 則把 6 個模型級運算元（sglang 融合原地 RoPE、topk_softmax、fused_moe、chunk_gated_delta_rule_fwd、融合迴圈門控 delta 規則及其打包解碼版）連同各平臺 vendor 覆蓋一起合入，加 13061 行減 79 行、85 個檔案，其中 rms_norm 與既有 one_pass_rms_norm 數學與 ABI 一致，故以 _mthreads、_thead、_hygon 覆蓋形式併入而非新增運算元。
  • 配套清理：玄鐵側 #8347 在審，內容是移除 PPU 上 NT GEMM 的 K 對齊回退；FlagTree #1348 合入，保留顯式 swizzled 的 TLE 佈局並避免複製的鏈式 dot warp 佈局。
  • 判斷：把通訊折進運算元是 TP 推理降延遲的常見手段，但它要求運算元庫同時掌握通訊原語與數值契約。FlagGems 這一批先由 PPU 與 SGLang 兩條線試點，說明該能力仍繫結具體硬體拓撲，尚未抽象成跨後端通用件。

1.9 配套基建：optest 飛書通知帶測試摘要，FlagTree CI 遷飛書多維表，FlagQAI 收緊 macOS 沙箱（11-03）

日期：2026-11-03　來源：optest PR #28 · optest PR #34 · FlagTree PR #1513 · FlagTree PR #1516 · FlagCX PR #669 · FlagQAI PR #30

  • optest 七筆：飛書通知加入測試摘要並把 Trigger 欄位移到末尾、Commit 緊跟 Ref（#28）；探測 FlagTrain 的執行時後設資料（#29）；運算元命令超時可配置（#30）並按倉庫分別配置超時（#32）；收窄 op-monitor 的上傳重試（#31）；簡化後端 GPU 配置（#33）；補中文 README（#34）。七筆全部圍繞「讓多後端測試結果可讀、可追、可復跑」。
  • FlagTree 八筆：功能側修昇騰 XCS 的 lightning-indexer UB 溢位、swiglu 精度與 tl.where 接受指標運算元，PPU 側保留顯式 swizzled 的 TLE 佈局；CI 側讓 FlagGems 的 CI 指令碼經 GITHUB_ACTION_PATH 跨分支共享，把結果報進飛書多維表，轉發飛書金鑰並在憑據缺失時告警，同時刪除 enflame3.5-guc400 的 CI/CD 工作流。
  • FlagCX 三筆：新增昇騰 910C 的 CI 流水線並統一單元測試編排（加 1559 行減 664 行、41 個檔案），把 Torch Python 覆蓋跑到四個平臺並清掉重複的 CUDA 效能測試，另修昇騰裝置完成狀態的追蹤與張量保留。
  • FlagQAI 六筆：在 macOS 上把本地 Python 作業、headless 會話的 workspace 讀取、原生 shell 讀取、搜尋目標與搜尋子程序逐個收進沙箱邊界，並在 Agent 提交前檢查 SDK 就緒狀態。六筆是同一輪安全收斂的連續切片。
  • FlagAttention 與其餘：FlagAttention 補 TMA prefill 在非 2 的冪 head 維度上的修復，並改用 uv pip 安裝廠商依賴；FlagSparse 合入 q4 相關整理；FlagDNN 四筆把打包映象指向已釋出的 FlagOS 倉庫並把打包工作流改為只驗證。
  • 判斷：本視窗有 26 筆落在 CI、評測與工具側，佔全部合入的 14.7%。對一個要同時維護九家以上後端的專案，這部分投入不產生新運算元，卻決定了「哪個後端在哪個版本上退化了」能否被及時看見。FlagTree 刪除 GCU400 工作流、新增 CANN 9.2.1 與 910C 流水線，也說明 CI 名單本身正在隨硬體世代更替。

二、新聞報道與生態

2.1 渠道核查：24 組查詢零元件級命中，CSDN 與 HN 視窗內無新文（11-04）

日期：2026-11-04　來源：Google News RSS（FlagOS 查詢） · CSDN FlagOS 專欄 · HN Algolia（FlagOS）

  • Google News：24 組中英文查詢詞中，FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、flagos-ai 及 BAAI 相關英文組合全部零命中；命中集中在成員單位與產業詞（智源研究院 開源 4 條、智源研究院 晶片 4 條、燧原科技 7 條、國產算力 開源軟體棧 7 條、摩爾執行緒 3 條、沐曦 1 條、清微 1 條），共 28 條，逐條核題後無一條涉及元件版本、晶片適配或 FlagOS 技術棧。這是元件級查詢連續第二個視窗為零。
  • CSDN 專欄：頁面 52 條連結逐條核時，最新一篇為 10-29 11:19 的 MiniCPM-OCR 與 Jev 的 Day0 適配文章，其後是 10-29 16:25 上架的 sglang-plugin-FL 直播。頁面頭部排在前列的 GLM-5.3-Flash、Qwen3.8-Flash-Next 與 LightX2V 三稿分別為 8-28、8-27、8-27 舊文，不計入視窗。
  • HN 與智源社群：HN 八組查詢中 FlagOS 命中 7 條、BAAI 30 條，按標題與正文直配均為 0；智源社群首頁無 FlagOS 條目，搜尋頁為客戶端渲染，抓不到可核時的列表。
  • 判斷：連續第二個視窗的新聞側空白，與 GitHub 側 24 倉推送、177 筆合入形成鮮明反差。FlagOS 的對外敘事仍高度依賴官方渠道（CSDN 專欄、智源社群、大會），第三方媒體對元件級進展的覆蓋尚未形成。

2.2 產業側：成員單位在烏鎮峰會獲傑出貢獻獎，燧原科技登陸 A 股（11-03）

日期：2026-11-03　來源：世界浙商網（沐曦獲獎） · 電子工程世界（摩爾執行緒獲獎） · 財聯社（燧原上市）

  • 獲獎：沐曦股份與摩爾執行緒在 2026 年世界網際網路大會烏鎮峰會上同獲「傑出貢獻獎」。沐曦側的報道強調全棧創新與國產 GPU 成長潛力，摩爾執行緒側的報道由電子工程世界給出，兩家均為 FlagOS 成員單位。
  • 上市：燧原科技登陸 A 股科創板，報道將其定位為科創板補強 DSA 架構算力拼圖。燧原的 S60 後端已在 10-28 合入 vLLM 0.28 適配，0.32 適配（#675）在審。
  • 對照：三家在視窗內的 FlagOS 側動作並不相同——沐曦 C550 的 0.28 適配當日合入（見 1.3），摩爾執行緒 MUSA 0.28 同日合入（見 1.3），燧原在 FlagGems GCU300 有四筆正確性修復（見 1.5）。資本與榮譽層面的進展沒有改變其技術投入的節奏。
  • 說明：本條為企業側動態，與 FlagOS 技術棧無直接關聯，僅作生態背景記錄；信源為 Google News 聚合連結，未取得釋出方原站地址。

三、成員單位與後端廠商深挖

3.1 清微智慧：TXDA 在 0.28 上只做 eager，把圖模式明確拒掉（11-03）

日期：2026-11-03　來源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #641 · FlagGems PR #8279

  • 取捨：#642 的正文值得逐字讀。分段原生圖已經實現，並在 TP8 下對兩個模型透過完整門禁（快照 R10 與 R6d），但 Dense TP1 的正確性始終沒有解決。作者沒有選擇「只在部分並行度可用的圖模式」，而是刪掉圖捕獲與切分實現，在配置階段拒絕圖與編譯配置，把使用者直接指向 --enforce-eager。
  • 拒絕面：MLA、稀疏注意力、投機解碼與上下文並行按各自不支援的具體路徑逐項拒絕，而不是籠統禁用。這種寫法讓錯誤資訊能指到具體能力，而不是讓使用者在執行到一半時才失敗。
  • 驗證環境：8 張 TX8110 64G，映象內 vLLM 為 0.28.0+empty——用上游 tag 提交 2cf0a69 以 VLLM_TARGET_DEVICE=empty 構建，不帶 vllm._C 擴充套件，所有 kernel 來自外掛或 FlagGems。這等於把「外掛是否真的自足」變成了硬約束。
  • 規模：加 3067 行減 146 行、29 個檔案，配套 docs/usage/tsingmicro.md 部署指南。
  • 判斷：這是當日最值得留痕的一次工程取捨。多後端適配最常見的失敗模式，是讓一個只在特定並行度成立的模式上線，然後在使用者現場以數值錯誤的形式暴露。#642 用「少一個模式」換「不出現只在某些配置下錯的模式」，代價明確、邊界清晰。

3.2 沐曦：C550 的 0.28 是「空適配」，改動全部留在外掛內（11-03）

日期：2026-11-03　來源：vllm-plugin-FL PR #554 · vllm-plugin-FL PR #693 · FlagGems-vllm PR #1050 · FlagGems-vllm PR #1054

  • 空適配的含義：廠商側 MetaX-MACA/vLLM-metax 還沒有 0.28 路徑，因此 #554 是在「上游無對應分支」的前提下做的適配——所有改動留在 vllm_fl/ 與 MetaX CI 指令碼內，後端行為以廠商名或執行時判定為門，不影響其他廠商。加 2838 行減 70 行、36 個檔案。
  • 安裝形態：早期 import 修復從外掛入口裝，kernel 與 backend 替換放 vendor patch 包；刪除獨立的 site-packages 引導安裝器與 vllm_fl/_fl_boot_shims/，setup.sh 清掉 15 個歷史 zz_fl_*.pth 鉤子。評審明確否決了「往 site-packages 寫啟動鉤子」的方案，這條否決本身對後續所有廠商都有效。
  • 雙線狀態：0.28 合入的同一天，0.32 的 C550 適配（#693）在 02:23 開出；FlagGems-vllm 側另有 #1050 把稀疏 QSA 的 dot tile 下限提到 16、#1054 讓 GLM5.3 的因果卷積與稀疏 MLA 核在 C550 上可執行（在審），以及 gdn_w8a16、fused_indexer_weight_scale、layernorm 三個運算元最佳化在審。
  • 判斷：沐曦這一視窗的形態是「0.28 收口、0.32 預跑、運算元上補長尾」，三條線同時有動作但互不阻塞。值得注意的是 0.28 的落地方式——在上游沒有分支時靠外掛自足，這決定了下一次上游升級時它的遷移成本會更低。

3.3 摩爾執行緒：MUSA 0.28 一次帶進原生 MCCL 與分段圖（11-03）

日期：2026-11-03　來源：vllm-plugin-FL PR #575 · FlagTensor PR #14 · FlagGems PR #8097

  • 適配內容：#575 把 MUSA 升到 vLLM 0.28.0，同時帶進普通 wheel 安裝、原生 MCCL、FX/eager 編譯與分段原生圖，加 7804 行減 233 行、46 個檔案。執行基線為四張 S5000、BF16、TP=4，Python 3.10、TorchMUSA 2.9.0、MUSA SDK 4.3.5。
  • 數值契約：編譯側 RMSNorm、SiLU 與 rotary 走顯式 MUSA 運算元邊界；參考 RMSNorm 保留目標端的 FP32 累加契約。這一點很關鍵——把「參考實現按誰的累加精度」寫清楚，跨後端比對才有意義。
  • 圖與快取：圖處理集中在 MUSA 廠商補丁目錄的 graph.py，同時刪掉 MUSA 編譯子包、可執行快取與載入器。與清微的「撤掉圖」相反，摩爾執行緒是「把圖收進一個檔案」。
  • 第二條線：FlagTensor #14 為張量庫註冊 MUSA 後端並給七個超越函式加專用重寫，同日該倉還有 PPU 直啟快路徑與崑崙芯 tile 調優提交。FlagGems 側 #8097（在審）用轉置 dot 與 GEMV tile 最佳化瘦長 FP8 矩陣乘。
  • 判斷：摩爾執行緒是當日唯一同時在「推理外掛」與「張量庫」兩條線上有落地的廠商。兩條線的分工也清楚：外掛解決後端可用性，張量庫解決底層運算元形態。

3.4 昇騰：0.28 解碼圖、CANN 9.2.1 base、INT8 BMM、910C CI 四處並進（11-03）

日期：2026-11-03　來源：vllm-plugin-FL PR #646 · build-infra PR #1614 · FlagGems PR #8110 · FlagCX PR #669 · FlagTree PR #1413

  • 執行模式：#646 在 0.4.0-dev 上開 FULL_DECODE_ONLY 的原生圖捕獲與回放，覆蓋 Qwen3.6-27B 與 Qwen3.6-35B-A3B，解碼走 torch.npu.NPUGraph，prefill、視覺編碼與取樣留在圖外。加 3342 行減 340 行、39 個檔案，是主分支 #606 與 #619 的向前移植。
  • 執行時版本：#1614 新增 CANN 9.2.1 的 base 層，僅 910B、python 3.12、torch 2.13 與 triton_ascend 3.6.0，並刻意留空 FlagTree 與 FlagCX（詳見 1.2）。#1615 把 2.3.0 下該層的 changelog 日期回填。
  • 運算元：#8110 新增通道級 INT8 BMM（bmm_w8a8），加 519 行減 3 行；#8286 補 910C 與 950DT 的 SKU 文件。FlagTree 側修 lightning-indexer 的 UB 溢位、swiglu 精度與 tl.where 接受指標運算元，flir #84 是同源修復。
  • CI：FlagCX #669 新增昇騰 910C 流水線並統一單元測試編排，加 1559 行減 664 行、41 個檔案；Torch-FL #690 補原生昇騰量子數值與無損 FP64 集合通訊。
  • 判斷：昇騰在「執行時版本、執行模式、運算元、CI」四層同日推進，是當日層次最完整的一條廠商線。CANN 9.2.1 base 留空 FlagTree 的選擇也說明版本推進存在明確的先後依賴，而非一次性整體升級。

3.5 天數、崑崙芯、燧原、玄鐵、海光與地平線：一側批次補運算元，一側繼續調優（11-03）

日期：2026-11-03　來源：FlagGems PR #8093 · FlagGems PR #8357 · FlagGems PR #8374 · FlagGems-vllm PR #1049 · sglang-plugin-FL PR #166 · FlagAttention PR #123

  • 天數：BI-V150 在 16:04 至 16:10 六分鐘內合入 10 筆專用運算元，覆蓋 padding 反向、上取樣反向、三類特殊多項式、量化池化、矩陣乘 smm、not_equal 與池化索引反向（清單見 1.5）。這是天數在 FlagGems 的單日峰值，且全部為新增實現。
  • 崑崙芯：合入側 11 筆以調優為主——argmin 走廠商 min.o 的 SIMD 載荷與分段寬行並行、lcm 用展開歐幾里得、poisson_nll_loss 降暫存器壓力、inner 在 XPU 上真正參與編譯並重調 tile。新開側有一批集中在凌晨的修復：sum_dim 回退、fake_quantize 系列、lstm/gru 的 pipeline event 溢位、linalg_matmul 與 linalg_lu_solve 的 tt.gather 降級、avg_pool1d 讓程序中止等。該視窗他一人新開 59 筆（燧原 31、崑崙芯 25、英偉達 3），其中 33 筆落在 00:07 至 05:43。
  • 燧原：GCU300 四筆正確性修復（cat 行尾、silu_backward 的除法語義、uniform_ 區間、clip 關鍵字），新開側另有 #8374 讓通用核在非 CUDA 後端執行、#8375 讓修正 Bessel 核跑在非 CUDA 後端。FlagTree 同期刪除 enflame3.5-guc400 的 CI/CD 工作流，屬 CI 名單隨硬體世代更替，不宜解讀為產品線終止。
  • 玄鐵：FlagGems 側零合入，動作落在編譯與外掛側——FlagTree #1348 合入保留顯式 swizzled 的 TLE 佈局；#8347（在審）移除 PPU 上 NT GEMM 的 K 對齊回退；sglang-plugin-FL #166（在審）把 RS+norm+AG 融合核做成 pure TP prefill 選項；FlagGems-vllm #1049（在審）為 thead 補 flash_mla_sparse_fwd。上一視窗的 13 筆專用運算元批次之後，本視窗轉入編譯與通訊層。
  • 海光：新開 #8357 最佳化面向科學模型負載的 FP32 矩陣乘；FlagGems-sglang #279 以 _hygon 覆蓋承接 BW1000；FlagAttention #123 與 #117（均在審）分別補 AttnRes 後端與最佳化 GLA；FlagTrain #10（在審）的 mixed_gemm 覆蓋海光。
  • 地平線與寒武紀：兩家本視窗在 FlagOS 各倉庫無提交。寒武紀的 neuware 4.4.3 層已在 2.3.0 名下完成 changelog 日期回填（見 1.2），屬映象側存量工作。
  • 判斷：後端條目正在從「補齊能跑」轉向「按晶片調優」——崑崙芯的 argmin SIMD 化、海光的 FP32 矩陣乘最佳化、燧原的非 CUDA 通用核回退，三者都不是新增覆蓋率，而是讓既有實現在特定負載上更快或更穩。這類工作不出現在覆蓋率數字裡，卻決定實際可用性。

四、總結與趨勢觀察

日期：2026-11-03 ~ 2026-11-04　來源：flagos-ai 組織倉庫 · 合併 PR 檢索

  • 合入端加速、生產端集中：177 筆合入較上一視窗增 9.3%，新開 117 筆降 39.1%，視窗內更新在審 271 筆降 12.9%。但新開的回落幾乎全部來自 FlagGems 單倉的節奏變化，其中 59 筆出自同一作者、集中在崑崙芯與燧原產線。全組織在審存量仍有 1602 筆，合入與在審之比約 1 比 9，評審壓力並未實質緩解。
  • 0.28 收口與 0.32 開局同時發生：清微、沐曦、摩爾執行緒、昇騰四條後端在同一天把 vLLM 0.28.0 收口，合計 150 個檔案、17051 行新增；與此同時 0.32 的五筆適配在評審佇列裡推進。維護線與目標線並行已常態化，廠商需要同時維持兩套驗證環境，這是多晶片適配的隱性成本。
  • 評測可比性成為新的基礎設施：FlagGems 兩分鐘 23 筆的基準遷移把四類運算元的 H800 參考讀入收斂到統一 JSON，配合 optest 的飛書測試摘要、FlagTree 的飛書多維表與 FlagCX 的四平臺覆蓋，評測鏈路正在從「各寫各的」變成「同一把尺子」。本視窗 26 筆落在 CI 與評測側，佔合入的 14.7%。
  • 新晶片接入的兩條路徑都已跑通：壁仞以 SUPA 後端進入 TransformerEngine-FL（骨架先行、無硬體驗證記錄），摩爾執行緒同時在推理外掛與張量庫兩條線落地，天數則以一天十筆專用運算元走運算元產線。接入速度已不是瓶頸，驗證深度才是——壁仞的後端目前只有骨架，尚無與清微、沐曦同等級的硬體門禁記錄。
  • 2.3.0 仍在映象先行：base 層已擴到六層（含 CANN 9.2.1），執行時映象按後端推送，changelog 日期逐層回填，但 community 的 release/2.3 清單仍返回 404。連續三個視窗未見清單凍結動作，版本釋出的實際內容與規劃之間正在積累偏離。
  • 待觀察的三件事：其一，release/2.3 清單何時出現，決定 2.3.0 能否在本月內釋出；其二，0.32 的五筆適配何時合入，決定目標線是否會再次推遲；其三，融合通訊運算元（RS+add+RMSNorm+AG）能否從 PPU 與 SGLang 的試點抽象為跨後端通用件。

附錄

信源核查表

信源 核查結果
GitHub 組織倉庫（61 倉） 24 倉視窗內推送，228 筆提交，177 筆合併 PR，19 倉有合入
GitHub 在審 PR 視窗內更新 271 筆，新開 117 筆，全組織在審存量 1602 筆
GitHub Release / Tag（31 倉 / 8 倉） 視窗內零新增；FlagCX v0.14.1（11-01 00:10）在視窗外
community 釋出清單 release/2.3/release-2.3.yaml 返回 404，release/2.2 在架
Google News RSS（24 組中英文） 元件級查詢全部零命中；成員單位與產業詞 28 條，均為企業側或財經稿
HN Algolia（8 組） FlagOS 7 條、BAAI 30 條，標題與正文直配 0 條
CSDN FlagOS 專欄 52 條連結逐條核時，最新一篇 10-29 11:19，視窗內無新文
智源社群 首頁無 FlagOS 條目；搜尋頁為客戶端渲染，無可核時列表
成員單位 GitHub 側核查 沐曦、摩爾執行緒、清微、天數、燧原、海光有 FlagOS 側動作；寒武紀、地平線本視窗零提交

完整信源清單

ithub.com/flagos-ai/FlagGems-vllm/pull/1054>

agAttention/pull/123>