調研視窗：2026-10-28 06:00 ~ 2026-10-29 06:00（北京時間，24 小時；週四晨報，視窗自上一期日報截點接續）。

信源：GitHub（org: flagos-ai 61 倉庫全量核查、提交檢索 99 筆、合併 PR 67 筆與在審 PR 288 筆檢索、org 事件流 100 條、31 倉 Release/Tag 原子核查、7 倉原子補核、關鍵 PR 正文與產物規模核查）、Google News RSS（24 組中英文查詢詞，走代理）、HN Algolia（8 組）、CSDN FlagOS 專欄、智源社群、八家成員單位官網（詳見附錄信源清單）。

本期索引

  • 今日重點：地平線 BPU 接成 eager 運算元後端；FlagCX 打出 v0.14.1 標籤並補齊三家 rpm 後端；摩爾執行緒開源 Megatron-MUSA-Titan（10-28）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：23 倉推送、99 筆提交、67 筆合入，在審回落至 288 筆（10-28 ~ 10-29）
    • 1.2 版本面：FlagCX 打出 v0.14.1，裝置位碼改為按介面卡生成（10-28）
    • 1.3 FlagGems：崑崙芯標量鏈融合提速十倍，燧原參考實現批次修復在審（10-28）
    • 1.4 FlagGems-sglang：AMD gfx1100 補 Mamba 運算元，燧原 core_shapes 真正生效（10-28）
    • 1.5 編譯器：FlagPrism 接入燧原，昇騰 TensorView 取存降低，FlagMega 提速 RDNA 解碼（10-28）
    • 1.6 推理與訓練棧：燧原 Qwen3.5 FP8 上 GCU，融合全歸約 RMSNorm 進 FlagGems-vllm（10-28）
    • 1.7 構建與釋出：changelog 上站與 Harbor，撤回兩筆從未推送的寒武紀映象（10-28）
    • 1.8 規則面：FEP-0140 轉 Implementable，FEP-0141 收窄到 SGLang 0.5.18（10-28）
    • 1.9 其餘倉庫：optest 接入燧原 CI，FlagTensor 昇騰常駐網格，FlagQuantum 置位一致性（10-28）
  • 二、新聞報道與生態
    • 2.1 報道面：摩爾執行緒開源 Megatron-MUSA-Titan，24 組查詢僅此一條有效（10-28）
    • 2.2 渠道與官網：CSDN 仍停 10-22，HN 與智源社群無新命中（10-28）
  • 三、成員單位與後端廠商深挖
    • 3.1 地平線：BPU 首次成為可逐運算元執行的 PrivateUse1 後端（10-28）
    • 3.2 崑崙芯：標量鏈融合與連續段核心，P800 上的三處提速（10-28）
    • 3.3 天數：卷積走工況檔位表，conv3d 去掉通道補零（10-28）
    • 3.4 燧原：Qwen3.5 FP8 上 GCU、core_shapes 落賬、FlagPrism 首次接入（10-28）
    • 3.5 達摩院玄鐵：PPU 上的 MiniMax 稀疏注意力，幾何均值 1.8 倍（10-28）
    • 3.6 清微、曦望、海光：FlagCX 的 rpm 打包補齊三家後端（10-28）
    • 3.7 摩爾執行緒：Megatron-MUSA-Titan 開源與三季度報告同日（10-28）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表與完整信源清單

今日重點：地平線 BPU 接成 eager 運算元後端；FlagCX 打出 v0.14.1 標籤並補齊三家 rpm 後端；摩爾執行緒開源 Megatron-MUSA-Titan（10-28）

日期：2026-10-28　來源：Torch-FL PR #674 · FlagCX tag v0.14.1 · FlagCX PR #673 · IT之家報道 · Megatron-MUSA-Titan 倉庫（全量見附錄）

  • 新後端面：Torch-FL 合入地平線 BPU 的逐運算元執行層（#674，31 檔案加 5698 行減 145 行）。此前 BPU 在 PrivateUse1 上不註冊任何計算運算元——hbDNNInferV2 只接受整張已編譯圖，於是每個 aten 呼叫都落到 cpu_fallback，backends_bpu.conf 是空的。本筆補上缺失的中間層：板上之外的 x86 側用 hbdk4 編出單運算元 .hbm 產物庫、生成提交這些產物的 C++ 核心、再加一條 drobotics conf 路由。覆蓋 40 個逐元素運算元（32 個一元、8 個二元）、11 個形狀分桶，RDK S600 上 440 個產物逐一對 NumPy 比對零差異。
  • 版本面：FlagCX 在 10-28 17:25 打出 v0.14.1 標籤（commit 7ed4a82，標題為「按介面卡生成裝置位碼，不再硬編碼英偉達」，即 10-18 合入的 #668）。該標籤只有 git tag、沒有 GitHub Release 正文，前一版 v0.14.0 的正式 Release 停在 9-28。同一檔案還可見 v0.15.0.dev0 標籤（早於本視窗）。同視窗為 0.14.0-rc2 線開花式補丁（#683，在審）。
  • 打包面：FlagCX 的 rpm 線從三個後端擴到六個（#673，10 檔案加 295 行減 8 行）。新增的 libflagcx-tsm（清微）、libflagcx-sunrise（曦望）、libflagcx-du（海光 DCU）三家都不需要廠商基礎映象——SDK 解包到 /opt 或 /usr/local、不呼叫包管理器，因此 openEuler 映象加檔案倉就是完整構建環境；廠商 soname 按昇騰已有口徑統一過濾。
  • 新聞面：摩爾執行緒 10-28 宣佈開源大模型訓練基礎設施 Megatron-MUSA-Titan，聚焦萬卡級叢集的萬億引數 MoE 訓練，覆蓋預訓練與強化學習；已在其萬卡叢集的預訓練中持續使用，支援 blockwise FP8、結合 DeepEP 與 ACE 非同步通訊做專家並行與計算重疊，可與 slime、miles 強化學習框架協同。倉庫 MooreThreads/Megatron-MUSA-Titan 在 GitHub 上存在，但本視窗內無推送（最後推送 10-16），屬「宣佈開源、程式碼未動」的狀態。
  • 判斷：三條線各自推進一層——把新晶片接進 eager 路徑（BPU）、把通訊庫的交付面從原始碼樹推向標籤與發行包（FlagCX）、把訓練棧的開源敘事從 FlagOS 擴到成員單位自研專案（Megatron-MUSA-Titan）。與本棧直接相關的是前兩條；第三條要觀察其程式碼是否迴流為 FlagOS 可複用的訓練元件。

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

1.1 組織節奏：23 倉推送、99 筆提交、67 筆合入，在審回落至 288 筆（10-28 ~ 10-29）

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

  • 倉庫面：61 倉中 23 倉視窗內有推送，為近兩週最多（上一期 20 倉）。按推送時間從近到遠為 docs、Trident、FlagQAI、Torch-FL、build-infra、FlagGems、FlagCX、FlagTree、release-info、FlagFFT、FlagGems-sglang、FlagQuantum、optest、FlagDNN、vllm-plugin-FL、FlagTrain、community、FlagGems-vllm、FlagAttention、sglang-plugin-FL、TransformerEngine-FL、FlagTensor、FlagGems-Experimental。
  • 提交面：提交檢索命中 99 筆，按倉為 FlagQuantum 33、FlagGems-sglang 17、FlagGems 10、build-infra 6、optest 5、FlagGems-vllm 5、Torch-FL 4、FlagTree 4、FlagCX 3、community 3、FlagTensor 3、FlagDNN 2，sglang-plugin-FL、vllm-plugin-FL、FlagTrain、FlagAttention 各 1。
  • 合入面：合併 PR 67 筆，分倉為 FlagGems 13、FlagGems-sglang 8、FlagTree 7、build-infra 6、FlagQuantum 6、optest 5、FlagGems-vllm 5、Torch-FL 4、FlagCX 3、community 3、vllm-plugin-FL 2，FlagTrain、FlagAttention、sglang-plugin-FL、TransformerEngine-FL、FlagTensor 各 1。
  • 在審面：視窗內有更新的在審 PR 288 筆，新開 101 筆。FlagGems 181 筆（新開 53）、FlagTree 21 筆（新開 9）、FlagGems-vllm 20 筆（新開 9）、vllm-plugin-FL 12（4）、FlagCX 8（2）、FlagTrain 7（2）、Torch-FL 6（5）、sglang-plugin-FL 5（2）、Trident 3（3）、flir 3（1）、FlagAttention 3（1）、Megatron-LM-FL 3（0）、FlagGems-sglang 3（3）、TransformerEngine-FL 3（1），其餘各倉 1 至 2 筆。
  • 節奏對比：與上一 24 小時視窗（20 倉、102 筆提交、98 筆合入、401 筆在審、269 筆新開）相比，推送倉增 3 個、提交基本持平、合入降 32%、在審降 28%、新開降 62%。上一期在審的激增來自 FlagGems-Experimental 一次性 135 筆批次提交，本期該倉無新增、也無合入，在審回落到常態區間。
  • 版本與事件面：31 倉 Release 與 Tag 原子核查，視窗內新增標籤一個（FlagCX v0.14.1）；build-infra 最新標籤仍是 8 月 3 日的 v2.2.0。org 事件流 100 條：推送 51、建分支 32、刪分支 9、PR 評審與評審評論 8，無 PR 開合事件——事件構成以分支活動為主，與 FlagGems 側大量 fix/suiyuan-*、fix/blocked581-* 臨時分支的建立與刪除吻合。
  • 分支面：提交檢索未覆蓋的 7 個推送倉需原子補核。TransformerEngine-FL 經 commits.atom 核實有視窗內提交一筆（#150，10-28 16:33）；FlagFFT 與 release-info 屬非預設分支推送（FlagFFT 側為 codex/musa-shortfall、codex/cuda-2d3d-opt）；FlagGems-Experimental 的推送來自 dependabot 分支；docs、FlagQAI、Trident 三倉的推送均在特性分支上，預設分支無新提交。

1.2 版本面：FlagCX 打出 v0.14.1，裝置位碼改為按介面卡生成（10-28）

日期：2026-10-28　來源：FlagCX tags · FlagCX v0.14.1 標籤 · FlagCX PR #668 · FlagCX PR #683 · build-infra PR #1546

  • 標籤事實：v0.14.1 於 10-28 17:25 打出，指向 commit 7ed4a82，提交標題為「按介面卡生成裝置位碼，不再硬編碼英偉達」（#668，10-18 合入）。檢索 Releases API 對該標籤返回 404，說明它只是 git 標籤、未建 GitHub Release，因此沒有釋出說明正文；上一版 v0.14.0 的正式 Release 仍在 9-28，正文指向 FlagOS 2.2 釋出清單。
  • 內容面：#668 把 setup.py 位碼步驟裡硬編碼的 bindings/ir/nvidia 換成按介面卡查表（BITCODE_MAKEFILES），每個介面卡宣告自己的 Makefile 與架構變數。此前任何非英偉達介面卡都會拋 RuntimeError，或靜默不出位碼，FlagTree 的 iluvatar 後端只能複製 FlagCX 原始碼自行重編，無法消費 FlagCX 本應產出的位碼。
  • 配套面：build-infra 由機器人記錄 flagcx wheel 的釋出（#1546），把 wheel 交付與標籤、打包線連成一條；同視窗開的 #683 把崑崙芯的 cstddef 修復回摘到 0.14.0-rc2 線（在審），說明 0.14 系列仍在受支援視窗內。
  • 待觀：v0.14.1 無 Release 正文，與 v0.14.0「正文指向釋出清單」的做法不一致；若後續 2.3 週期按 v0.14.x 交付，建議補一份說明，避免下游只靠 tag 猜內容。

1.3 FlagGems：崑崙芯標量鏈融合提速十倍，燧原參考實現批次修復在審（10-28）

日期：2026-10-28　來源：FlagGems PR #7617 · FlagGems PR #7600 · FlagGems PR #7850 · FlagGems PR #7803 · FlagGems PR #7036 · FlagGems PR #7061 · FlagGems PR #7223

  • 融合核心：崑崙芯 XPU3 側為八個出位標量鏈運算元加後端特化（#7617，275 行）。同構 float 列表走一個融合核心：小形狀單次發射、把所有指標作為核心引數帶進去，大形狀走流式分塊；輸出從一次分配加 unbind 得到，而非每張量一次分配器呼叫。八個運算元的相對耗時從 0.083~0.126 提到 0.813~0.934，即約七到十倍。
  • 連續段核心：batch-norm 推理與 QKV 變換兩個運算元由「每 (n,c) 切片一個 program」改為「每 program 處理一段連續 BLOCK 元素、由平坦索引反推通道或打包行」（#7600）。聚合指標分別從 0.228 提到 1.357、從 0.260 提到 5.062；fp32 單精度那格仍低於 0.8，作者按聚合口徑判定，並在正文裡寫明。
  • 向量化修復：masked_fill 的整數檢視快路徑因 arith.extsi 無向量形式整核停留在標量（fp16 0.34、fp32 0.50），改寫為 x*(1-m)+V*m 的 f32 形式後 P800 上從 0.577 提到 0.829，masked_fill_、masked_fill_scalar 同步受益，594 個用例透過（#7850）。
  • 匯入與執行器：崑崙芯後端在 master 最新提交上直接匯入失敗——_result_dtype 助手已隨 #7561 從共享執行器移除，而後端仍在引用（#7803，90 行）；修掉匯入後，共享執行器又報 operand #0 does not dominate this use，本筆一併修。
  • 運算元覆蓋：KernelGen 補 _indices_copy（#7223，250 行，H20 驗證），但效能只有 torch 的 0.21 倍——屬補齊覆蓋率的產物，短期不能當加速項看。lighting_indexer 的參考實現改為逐頭累加，峰值記憶體從約 8.6 GiB 降下來，修掉 40 GiB 卡上的 OOM（#5852）。
  • 在審側：本視窗新開 53 筆，多數是 lukatao 的燧原參考實現修復（#7890 至 #7908 連號），涉及 Kaiser/inplace ldexp、aminmax、special_round、LU、vander/slogdet、median/stacking/Lanczos、Adagrad、batch-norm ABI 等；另有 AMD 側一行修復（#7908）——AMD 的廠商描述符把裝置名設成 cuda 且未給 triton_extra_name，導致 pow、tanh、exp、rsqrt、erf、gelu 等全部走 __nv_* 被 AMD 後端拒絕。

1.4 FlagGems-sglang：AMD gfx1100 補 Mamba 運算元，燧原 core_shapes 真正生效（10-28）

日期：2026-10-28　來源：FlagGems-sglang PR #231 · PR #232 · PR #229 · PR #233 · PR #237 · PR #236

  • AMD 側：為 RDNA3 檔補上 causal_conv1d_fn、chunk_state_varlen、bmm_chunk 三個 gfx1100 版本（#231，578 行），在 Radeon PRO W7900D 上調優並測試；三者只改發射引數、輸出與通用核心逐位一致。時間片跟隨最長序列而非固定 128 token×4 通道，dstate 128 以上改用更小的 tile 與 16 token 的 K 步。
  • 燧原側：#229 加了 _enflame/core_shapes.yaml，但倉內沒有任何程式碼載入它——init_user_config() 只有硬編碼的 kunlunxin 分支（#232 的根因分析）。#232 把形狀檔案查詢泛化為「由 vendor_name 推出 _<vendor>/core_shapes.yaml，存在則用、否則回退共享預設」，並順帶修掉 kunlunxin 路徑被無條件設定、檔案不存在就 FileNotFound 的潛伏問題。
  • 測試基建：候選注入在正確性測試與基準之間統一（#233，9 檔案），獨立基準會話此前不註冊 --override、候選專用模式又呼叫不存在的登錄檔方法；get_override() 暴露實際候選，普通計時、預檢與畫像共用同一個解析器。另加逐用例的 dummy 候選呼叫校驗（#237）與包級匯入修復（#236，避免 sys.modules 衝突）。
  • 用例列舉：silu 基準支援不帶張量列舉用例並精確回放（#234），--list-cases 分頁到 238 筆合入的收尾。
  • 判斷：這一倉本視窗 17 筆提交、8 筆合入，全部圍繞「讓廠商形狀表與候選注入在多後端下說同一套話」，屬測試口徑收斂而非新運算元。

1.5 編譯器：FlagPrism 接入燧原，昇騰 TensorView 取存降低，FlagMega 提速 RDNA 解碼（10-28）

日期：2026-10-28　來源：FlagTree PR #1239 · FlagTree PR #1426 · FlagTree PR #1439 · FlagTree PR #1456 · FlagTree PR #1454 · flir PR #86

  • 剖析與除錯：FlagPrism 的偵錯程式與剖析器擴到燧原後端（#1239，5 檔案加 119 行減 31 行）。CMake 與 Python 側把燧原加入支援列表並預設開啟，保留顯式關閉項與與 Proton 的互斥；執行時把帶除錯的核心發射改走 FlagPrism 閘道器，後設資料捕獲與隱藏的控制緩衝引數分開處理，普通執行仍走直髮路徑。
  • IR 與取存：昇騰後端接上 TensorView 訪問路徑（#1426，32 檔案加 4901 行，合入 triton_v3.5.x 分支）。核心用三種顯式構造器在基指標上建編碼檢視，再按索引整塊取存；越界通道按 zero/nan/inf/-inf 補值或丟棄，後端在 CommonIR 到 HIVM 之間依據索引模式選擇「按索引載荷 DMA」或「逐元素帶補零搬運」。
  • AMD 解碼：FlagMega 側為 Qwen3-1.7B bf16 做 batch-1 解碼最佳化（#1439，44 檔案，合入 feature/flagmega 分支）。R9700（gfx1201）在上下文 1 時 154 tok/s、1K 時 150、4K 時 139、8K 時 125；W7900（gfx1100）分別為 167、162、149、136 tok/s，實測頻寬 530~597 GB/s，達該卡實測流式上限的 82%~87%。
  • 正確性：AMD 後端的 CanonicalizePointers 不再斷言，改為合併 arith.select 的 fat-pointer 屬性（#1456）；RLC 側不再給佈局變更不合法或不安全的 producer 重新打標（#1454）。
  • CI 與在審：FlagGems 的 CI 資產搬進 FlagTree（#1443、#1447）；在審 9 筆新開，含清微後端同步到內部 Triton 3.6 開發線（#1459，27 檔案加 2264 行，含逐發射精度 API 與 CoreIR 入口）、rpm 線改為消費已釋出 wheel 構建昇騰包（#1461，首個無需廠商 SDK 與硬體的行）、英偉達 Hopper 上四項軟體流水缺陷修復（#1460，cp.async 帶驅逐策略在 ptxas 12.8~13.1 上會留下未定義地址描述符）、昇騰結構化置換與常駐迴圈效能（#1466）、P800 SDNN 的一維取模載入（#1465）、flir 的昇騰 split/join 與靜態置換降低（#86）。

1.6 推理與訓練棧：燧原 Qwen3.5 FP8 上 GCU，融合全歸約 RMSNorm 進 FlagGems-vllm（10-28）

日期：2026-10-28　來源：vllm-plugin-FL PR #358 · PR #525 · FlagGems-vllm PR #773 · PR #1017 · TransformerEngine-FL PR #150

  • 燧原推理：GCU 後端加上 Qwen3.5 FP8 支援（#358，20 檔案加 3367 行，基於 release/0.2）。引入 W8A8 塊標定 FP8 推理，並圍繞 GCU300/GCU400 的硬體限制重做核心補丁，使 FP8 MoE 模型在 eager 與整圖兩種模式下都能跑通。
  • 通訊接線：vLLM 外掛改為從已安裝包取 FlagCX（#525，11 檔案）。flagcx wheel 把 ctypes 門面裝成 flagcx.api、libflagcx.so 放在包內 lib/，僅裝 wheel 的環境沒有原始碼樹可供 FLAGCX_PATH 指向；本筆以 flagcx.api 為首選匯入、FLAGCX_PATH 包裝器作回退，呼叫點三處（flagcx.py、flagcx_connector.py、sunrise/patch.py）同步改。
  • 運算元面：FlagGems-vllm 加融合全歸約 RMSNorm（#773，6 檔案加 3191 行）：all-reduce + 殘差相加 + RMSNorm，可選靜態量化（FP8，SM100+ 支援 NVFP4），支援 TP2/TP4/TP8 的 FP16/BF16，附與 vLLM FlashInfer 實現的對比基準與 GLM-5.2 代表形狀。ihc_pre 的 stage1 合併把 tl.atomic_add 換成按 split 槽位寫（#1017）——原子加使結果依賴塊到達順序、重複發射不逐位一致，改後確定性恢復。
  • 依賴與迴歸：TransformerEngine-FL 把 3rdparty/ 三個子模組回滾到上游 v2.17 的驗證基線（#150）：#129 誤把 cutlass 前推 240 個提交（涉及 4000+ 檔案）、cudnn-frontend 從 v1.25.0 推到未釋出快照、googletest 從 v1.14.0 推到 master 頭。
  • 訓練側：FlagTrain 加 FlagOS 測試套件的 KMCompiler 配置（#37）；在審七筆仍是各廠商 KMCompiler 運算元（scaled_masked_softmax、fused_proj_rms 前後向、bias_swiglu、fast_gelu、moe_gemm、tanh_soft_clamp）。

1.7 構建與釋出：changelog 上站與 Harbor，撤回兩筆從未推送的寒武紀映象（10-28）

日期：2026-10-28　來源：build-infra PR #1545 · PR #1547 · PR #1548 · PR #1549 · PR #1542 · PR #1543

  • 變更記錄上站：每映象的 changelog 現在既出現在站點頁面末尾，也作為 Harbor 倉庫描述對三層釋出（#1545，455 檔案加 19080 行）。此前 changelog 只寫在倉內、沒有消費者，站點頁、倉內 readme 與 Harbor 描述都缺這一段，應用層連描述行都沒有。區塊按「重算而非隨正文渲染」實現：頁面正文各有生成器與節奏，隨正文出的區塊會被最後一行覆蓋而丟掉中間寫下的原因。空的待定條目與 upstream_prs 不釋出；同視窗先把原因做成中英雙語（#1542）。
  • 撤回不存在的映象：Harbor 裡沒有 megatron_training0.18.2-cambricon-neuware4.7.2 與 megatron_rl0.18.2-cambricon-neuware4.7.2 兩個倉庫，但 0.18.2 的兩張狀態矩陣都記了 image_tag: 2.2.0-0.3.0（#1547，13 檔案加 29 行減 496 行）。這個標籤來自首次建矩陣的提交，不是記錄步驟寫下的，於是文件流水線為兩個不存在的映象發了啟動頁、readme 與 changelog，此後每次 pubdoc-app 都在這兩個倉上 404（其餘 107 個接受描述 PUT）。
  • 映象沒推成的根因：0.18.2 的 wheel 裡 platform_register 沒有 MLU 平臺，torch_mlu 的 gpu_migration 把 CUDA 表面別名到 MLU 之後選中的是 PlatformCUDA，流水線並行組始終未初始化；MLU 註冊（MLF #125，含 #188/#190/#191）只落在 release/0.2，v0.3.0、0.3.0-rc2 與 main 都沒有該檔案、也沒有在途移植。處置是撤回主張而不是硬湊：兩個後端去掉 image_tag、置 launch_docs: false，同時刪掉這兩份 changelog，使「changelog 檔案集 == 已釋出集合」重新成立（該集合共 151 份，只有這一塊是從未交付的）。
  • 構建器補齊：amd-rocm7.2.4 執行時映象基於 ubuntu 24.04，在其中構建的 FlagCX wheel 連結 GLIBC_2.38，被 wheel 線的 22.04 門禁拒絕（22.04-incompatible symbols: GLIBC_2.38、GLIBCXX_3.4.32、__isoc23_）。本筆給該行配自足的 22.04 構建器，glibc 下限回到 2.35：裝 ROCm 7.2.4 的 jammy 套件（rccl/hip-dev 與 torch 所需的 hipsolver/hipfft/miopen-hip 標頭檔案、graphics 倉的 amdgpu-core）、deadsnakes 的 Python 3.12、pin 住的 torch 2.11.0+rocm7.2（#1548，204 行）。
  • 門禁前移：應用層頁面此前沒有一致性校驗——改一個 image_tag 或 changelog 原因後，頁面與面向 Harbor 的 readme 一直停在舊內容（#1549，6 檔案）。現在把 gen_descriptions.py --app-only --check 接到 .githooks/pre-commit 與 CI，命中狀態矩陣、應用 changelog、應用頁或應用 readme 時先重建 images.yaml 再比對。
  • 在審：重打包線的依賴解析改為直接讀 PEP 503 簡單索引（#1543）——原實現每個依賴起一個 pip index versions 子程序、JSON API 在阿里雲映象 404，0.28/0.32 的重打包要跑約兩小時並白下一個 300MB 的 triton wheel。

1.8 規則面：FEP-0140 轉 Implementable，FEP-0141 收窄到 SGLang 0.5.18（10-28）

日期：2026-10-28　來源：community PR #159 · PR #160 · PR #161 · 2.3 排期

  • FEP-0140：先補運算元剖析的範圍與驗證計劃（#159），再把狀態從草案改為 Implementable、Owner 設為 @ceci3（呂夢思）（#160，僅改兩個後設資料欄位）。提案仍受釋出驗收約束，跟蹤 issue #151 保持開啟。
  • FEP-0141：收窄到 SGLang 0.5.18、剩餘的 Empty 整合與沐曦／清微的基礎功能，Owner 設為 @yixiaodapeng（#161，加 33 行減 144 行）。詳細平臺進展留在 #152；保留可執行的迴歸、運算元覆蓋、效能與穩定性檢查與 wheel 構建命令；刪掉歷史版本矩陣與重複部署說明。
  • 口徑澄清：DeepSeek-V4-Flash/Pro 仍是初始 W8A8 候選；相對英偉達吞吐提升 10% 是最佳化目標，不是固定驗收門檻。這些限定詞被明確保留，避免後續把目標讀成門檻。
  • 排期核對：community/release/2.3 目錄下仍只有中英文排期表，沒有 release 清單；2.2 目錄有 rc0/rc1/rc2 與正式清單四份。按排期，11-13 為 FEP 合入截止、11-30 拉 rc0。

1.9 其餘倉庫：optest 接入燧原 CI，FlagTensor 昇騰常駐網格，FlagQuantum 置位一致性（10-28）

日期：2026-10-28　來源：optest PR #14 · optest PR #15 · FlagTensor PR #32 · FlagQuantum PR #945 · FlagQuantum PR #914 · FlagDNN 倉庫

  • optest：五筆合入。燧原 S60 接進 FlagGems-vllm 與 FlagGems-sglang 的變體 CI，而運算元清單隻對 FlagGems 本體生效（#14）；flagos-gpu-check 重做為單份文字摘要或單份可解析 JSON/YAML（#15，19 檔案加 2947 行），新增 device、driver、runtime、runtime_version、device_count、memory_unit 等歸一欄位，文字標籤固定為 Device:、Driver:、GPUs Usage:，並把執行時與主機驅動分開表述（#16 再把加速器後設資料帶進測試摘要）。
  • FlagTensor：昇騰側的常駐網格逐元素核心與廠商相關調優合入（#32，24 檔案加 1128 行減 139 行），隨後把 Ascend 執行時助手摺進 flagtensor.runtime（#33、#32 系列提交）。
  • FlagQuantum：六筆合入、33 筆提交，仍是全組織提交量第一。核心是把「分片後的 MPS 與不分片是否等價」做成可執行證據（#945）：同一程式跑兩臂——max_bond 64 加精確梯度（只變佈局）與 max_bond 2 加近似梯度（佈局與截斷一起變），用兩臂之差把兩種貢獻拆開；另有公開 Module 訓練提速並補齊宣告的 JAX 批次 VJP（#914）、非有限繫結角度拒答（#944）、pytest 9.2 造成的兩套件恢復（#946）、狀態與梯度一致性網格（#947）、失敗歸因到引入變更（#948）。
  • 其餘：FlagDNN 兩筆均為海光修正（GPU 名與效能）；FlagAttention 合入達摩院玄鐵 PPU 的 MiniMax 稀疏注意力（#111，6 檔案加 4644 行）；FlagCX 修 AMD 介面卡的流守衛（#680）與崑崙芯平臺 traits 的 cstddef（#682）；FlagQAI 的 #1 仍在審；docs 兩筆均為機器人（魔搭模型清單 #545、#567）；Trident 三筆在審（昇騰 LLVM 適配 #7、使用者自帶 LLVM_ROOT #6、新舊 TVM FFI 頭佈局 #8）。

二、新聞報道與生態

2.1 報道面：摩爾執行緒開源 Megatron-MUSA-Titan，24 組查詢僅此一條有效（10-28）

日期：2026-10-28　來源：IT之家報道 · 新浪科技轉載 · Megatron-MUSA-Titan 倉庫 · Google News RSS 檢索

  • 事件：摩爾執行緒 10-28 宣佈開源大模型訓練基礎設施專案 Megatron-MUSA-Titan，基於其全功能 GPU，面向萬卡級叢集的萬億引數 MoE 訓練，覆蓋預訓練與強化學習兩個場景，提供 MUSA 平臺的訓練適配與系統最佳化。
  • 技術點：已在萬卡叢集的萬億引數 MoE 預訓練中持續使用，自述具備較高 MFU 與長穩訓練；支援 blockwise FP8 訓練；結合 DeepEP 與 ACE 非同步通訊引擎加速 MoE 的 Token 分發與結果合併，實現專家並行與計算重疊；可與 slime、miles 強化學習框架協同，用 Megatron 訓練、SGLang 生成樣本，串起預訓練與強化學習。
  • 程式碼狀態：倉庫 MooreThreads/Megatron-MUSA-Titan 存在，README 自述面向萬卡叢集上的 1T+ 引數模型預訓練與強化學習基礎設施，最後推送為 10-16，本視窗無提交——屬「宣佈開源、程式碼未動」，與新聞稿的「開源」表述要在時間上分開看。
  • 候選面：二十四組中英文查詢詞視窗內返回 49 條候選，採納 1 條（上條）。元件名查詢（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）中英文合計十二條繼續全部零命中。
  • 剔除項：摩爾執行緒三季度業績稿十餘條（營收 15.5 億元、同比增 1773.9%、單季扣非轉正、擬發港股）屬財報與行情內容，僅在 3.7 作成員單位背景提及；智源側「源創計劃」首期落地、AREX-2、SoulAgent 三條為模型與社群內容，與軟體棧無直接關係；燧原相關的二十餘條為股票行情、董事會決議與 ETF 稿；清微「產投 28 計劃」週年稿與開源棧無關。

2.2 渠道與官網：CSDN 仍停 10-22，HN 與智源社群無新命中（10-28）

日期：2026-10-28　來源：CSDN FlagOS 專欄 · HN Algolia 檢索 · 智源社群 · 摩爾執行緒新聞中心

  • CSDN：專欄頁 51 條文章連結，最新可核日期仍為 10-22（開放計算大會分論壇回放與高校圓桌）；此前三條高相關稿（GLM-5.3-Flash Day0 適配 9 款晶片、Qwen3.8-Flash-Next 首日適配 8 款晶片、LightX2V 接入 FlagOS）經逐頁核時均為 8 月下旬，非視窗內容。
  • HN Algolia：八組查詢在四天視窗內命中數為 FlagOS 5、BAAI 30、FlagGems 1，按標題與正文關鍵詞嚴格匹配後直接命中 0 條。
  • 智源社群：搜尋頁與首頁可訪問，無 FlagOS 相關新稿；首頁未出現本棧元件更新。
  • 成員官網：八家巡檢中摩爾執行緒有視窗內新條目——10-28《一圖讀懂摩爾執行緒 2026 年第三季度報告》，屬財報圖解，未涉軟體棧變動，按收錄標準不入正文條目（背景見 3.7）；沐曦、天數、寒武紀、燧原、清微五家列表無 10-28 至 10-29 新條目；海光頁面為靜態頁，地平線抓取失敗，以列表可見內容為準。
  • 判斷：新聞側連續第二個視窗只有一條實質條目，且該條來自成員單位的自研訓練棧而非本棧元件；本期主體仍是程式碼與釋出工程。

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

3.1 地平線：BPU 首次成為可逐運算元執行的 PrivateUse1 後端（10-28）

日期：2026-10-28　來源：Torch-FL PR #674 · PR #676 · PR #678 · PR #673

  • 接入方式：BPU 的執行單位是 hbdk4 產出的 .hbm 產物，而 hbdk4 只能在 x86 上跑；板上既不能編譯，也沒有隨倉交付的產物。此前的結論是「設計上不能 eager」，本筆把它拆成三層：板上之外編出單運算元 .hbm 庫、生成 C++ 核心提交這些產物、加 drobotics conf 路由。
  • 覆蓋與驗證：40 個逐元素運算元、11 個形狀分桶，RDK S600 上 440 個產物全部與 NumPy 比對零差異，flagos 張量上的 aten 呼叫確實落到 BPU。作者同時記錄了兩條否定結論：libhbtl.so 只是 CPU 參考實現（ldd 只見 libc/libstdc++/libm，hbtl::ucp::Add 的 cpu/wall 為 1.00），以及動態形狀在 HBRT 4.7.5 上不可執行（載入器把該軸宣告成 stride 0，任務校驗要求不小於 64）。
  • 收尾三筆：#676 給 kDrobotics 補上 dispatcher.h 兩處 switch，此前 BPU 構建的分發日誌名一律列印 unknown、KernelSetOf 把 BPU 自己的核心庫報成無歸屬；#678 修三處 copy 分支無條件 box 到 CUDA 的問題——預設 FlagGems 主導的英偉達與達摩院玄鐵 PPU wheel 有意連結僅 CPU 的 pip torch，CUDA 複製核心的 DispatchStub 是空的，首次呼叫即 missing kernel for cuda。#673 修構建記錄裡廠商名與平臺 id 不一致（hygon/dcu、mthreads/musa、enflame/gcu、nvidia/cuda），這是海光 DCU 車道上八條單測失敗的根因。
  • 在審：#672 統一 soft-lowp 矩陣運算元的 claim 粒度（按 conf 鍵宣告、按家族解碼），#677 讓關鍵字引數的 FlagGems 呼叫走活躍後端，#680 按構建記錄持有的廠商重定裝置別名，#681 從 torch 字首而非介面目標讀取 libtorch_cuda 探針。
  • 判斷：這是本視窗唯一一次「新平臺從不可用變為可用」的接入，價值在打通路徑而不是效能——40 個逐元素運算元是起點，卷積等主幹運算元仍靠 torch.compile 整圖路徑。

3.2 崑崙芯：標量鏈融合與連續段核心，P800 上的三處提速（10-28）

日期：2026-10-28　來源：FlagGems PR #7617 · PR #7600 · PR #7850 · PR #7803 · FlagCX PR #682

  • 標量鏈：八個出位標量鏈運算元的融合核心把相對耗時從 0.08~0.13 抬到 0.81~0.93（#7617）。收益主要來自主機側：輸出一次分配加 unbind，替代每張量一次分配器呼叫；小形狀單次發射把所有指標當引數傳進去。
  • 連續段：batch-norm 推理與 QKV 變換改連續段核心後，聚合指標 0.228→1.357 與 0.260→5.062（#7600）。原實現按 (n,c) 切片或二維 tile 組織，讀寫不連續；新實現每個 program 覆蓋一段連續元素、由平坦索引反推通道或打包行。
  • 掩碼填充：masked_fill 在 P800 上從 0.577 提到 0.829（#7850），做法是把整數掩碼的符號擴充套件改成取 sitofp 後的 0/1 浮點乘法，使整個核心可向量化；精度上 m 恰為 0/1，結果逐位一致。
  • 可維護性：#7803 修掉崑崙芯後端在當前 master 上無法匯入的問題（共享執行器移除了 _result_dtype 助手），並修共享執行器在 uni_sram 上的支配關係編譯錯誤——不修則任何崑崙芯測試都起不來。
  • 通訊側：FlagCX 的崑崙芯平臺 traits 把 cstddef 移到 __xpu__ 守衛之外（#682），此前從 comm_traits.h 解析時 size_t 尚未可見，公共裝置 API 的宿主側編譯直接失敗。

3.3 天數：卷積走工況檔位表，conv3d 去掉通道補零（10-28）

日期：2026-10-28　來源：FlagGems PR #7036 · FlagGems PR #7061

  • conv_transpose2d：把通用實現的單一預設排程 (64,32,32,4) 加一個 3x3/stride2 特例，換成按資料型別、核大小、步長與輸出通道數索引的七套硬體調優檔位（BLOCK_NHW/CI/CO、num_warps、num_stages），並按輸出是否放得進 L2 在兩個核心變體間切換——直掃變體在 L2 內更快，相位專用變體在輸出超出 L2 後更穩（#7036，加 1886 行）。
  • conv3d：天數側 BLOCK_CI 已不小於 16，FlagTree 的 AABS 也會把被縮小的 tile 拉回 16x16x16 下限，因此通用路徑把 weight_c 補到 16 的通道補零純屬每次呼叫的分配與複製開銷，去掉後輸出逐位一致；另補 BLOCK_NI_DO_HO_WO 為 32 與 64 兩檔小空間 tile，讓小體積形狀也能填滿裝置（#7061）。
  • 判斷：兩條都屬長尾調優，方向一致——把「通用正確但慢」的路徑換成本地化排程，同時把補零這類無收益開銷刪掉。

3.4 燧原：Qwen3.5 FP8 上 GCU、core_shapes 落賬、FlagPrism 首次接入（10-28）

日期：2026-10-28　來源：vllm-plugin-FL PR #358 · FlagGems-sglang PR #232 · FlagTree PR #1239 · optest PR #14

  • 推理：GCU 後端加上 Qwen3.5 FP8 的 W8A8 塊標定推理，並圍繞 GCU300/GCU400 限制重做核心補丁，使 FP8 MoE 在 eager 與整圖兩種模式下都可用（#358，20 檔案）。
  • 形狀表：燧原的 core_shapes.yaml 加了一週沒生效——倉內沒有任何載入點，基準只認硬編碼的 kunlunxin 分支（#229 加檔案、#232 修載入）。修復把查詢泛化到任意廠商，順帶修掉 kunlunxin 路徑被無條件設定導致的 FileNotFoundError。
  • 工具鏈：FlagPrism 的剖析器與偵錯程式擴到燧原並預設開啟（#1239），帶除錯的核心發射改走閘道器，L2 捕獲所需的編譯器處理留在燧原後端內部；optest 把 S60 接進 FlagGems 兩個變體的 CI（#14）。
  • 在審：vLLM 0.28 的 TXDA eager 後端升級（#642）、TransformerEngine 的燧原 profiler 與 runner（在審），以及 FlagGems 側大批參考實現修復（見 1.3）。

3.5 達摩院玄鐵：PPU 上的 MiniMax 稀疏注意力，幾何均值 1.8 倍（10-28）

日期：2026-10-28　來源：FlagAttention PR #111 · FlagAttention 倉庫

  • 內容：為達摩院玄鐵 PPU 後端加 MiniMax 稀疏注意力（MSA）推理運算元，覆蓋索引打分、top-k 塊選擇與稀疏注意力本身，prefill 與 decode 兩條路徑都實現（6 檔案加 4644 行）。
  • 能力：支援分頁 KV 快取、因果掩碼與強制塊選擇；針對 810E 適配矩陣計算佈局與核心發射；prefill 的索引打分按 KV 頁並行，緩解 query 側並行度不足；FP8 輸入轉 BF16 計算，未使用原生 FP8 矩陣乘。
  • 效能：以 SGLang 通用 Triton 實現為基線，810E 上 prefill 21/21 透過、幾何均值 2.299 倍（最低 1.965、最高 5.434），decode 18/18 透過、幾何均值 1.354 倍（1.289~1.485），合計 39/39、幾何均值 1.800 倍。
  • 判斷：這是 PPU 上第一條稀疏注意力路徑，與同視窗 Torch-FL 的 BPU 接入形成對照——一邊補主幹運算元的覆蓋率，一邊補新模型結構的特殊運算元。

3.6 清微、曦望、海光：FlagCX 的 rpm 打包補齊三家後端（10-28）

日期：2026-10-28　來源：FlagCX PR #673 · FlagCX PR #681 · FlagTree PR #1459 · FlagDNN 倉庫 · FlagAttention PR #117

  • 清微：libflagcx-tsm 進 rpm 線，SDK 是兩個 makeself 安裝器、解到 /usr/local/kuiper（#673）；FlagTree 側在審的 #1459 把清微後端同步到內部 Triton 3.6 開發線（27 檔案，含逐發射精度 API、外部 CoreIR 入口與執行時介面卡，並修 Tx81 程式碼生成與 DMA/RDMA/WDMA 的 CRT 缺陷）。
  • 曦望：libflagcx-sunrise 進 rpm 線，SDK 經 tangtk --toolkit 與 pccl 落到 /usr/local；此前曦望在 vllm-plugin-FL 側有 0.28 適配在審。
  • 海光：libflagcx-du 進 rpm 線，DTK tarball 解到 /opt/dtk；FlagDNN 兩筆修海光的 GPU 名與效能；FlagAttention 在審的 #117 為海光 BW3000（gfx936）加純 Triton 的 GLA 實現，把門控累加和與迴圈狀態掃描合到一條流水線，只對受支援的推理負載走特化路徑。
  • 打包口徑：三家都不需要廠商基礎映象，openEuler 映象加檔案倉即完整環境；廠商 soname 按昇騰已有做法統一過濾（這些 SDK 從不是 RPM，任何倉庫都無法提供）。

3.7 摩爾執行緒：Megatron-MUSA-Titan 開源與三季度報告同日（10-28）

日期：2026-10-28　來源：IT之家報道 · Megatron-MUSA-Titan 倉庫 · 摩爾執行緒新聞中心 · sglang-plugin-FL PR #158

  • 訓練棧：Megatron-MUSA-Titan 面向萬卡叢集的萬億引數 MoE，覆蓋預訓練與強化學習；支援 blockwise FP8、DeepEP 與 ACE 非同步通訊、專家並行與計算重疊，可與 slime、miles 協同（Megatron 訓練 + SGLang 取樣）。這是成員單位自研的 Megatron 系訓練棧，與本棧的 Megatron-LM-FL 同源不同支，尚無程式碼迴流跡象（倉庫最後推送 10-16）。
  • 財務背景：同日釋出三季度報告，營收 15.5 億元、同比增長 1773.9%，實現單季度扣非盈利，前三季度營收 32.89 億元、歸母淨利潤 3769.73 萬元，並推進港股二次上市。財報不改變本棧的技術判斷，但解釋了其開源節奏的投入能力。
  • 推理側：sglang-plugin-FL 在審的 #158 為 MUSA 加 MiniMax-M3 支援，#125 是 Qwen3.6 在 S5000 上的 Triton 與 YAML 調優；FlagGems-sglang 側本視窗無 MUSA 變更。
  • 判斷：摩爾執行緒近兩週的動作集中在「訓練 + 推理雙棧自研開源」，與本棧的交集仍是運算元與外掛層（FlagGems、sglang-plugin-FL），而非訓練框架層。

四、總結與趨勢觀察

  • 一條新路徑打通：地平線 BPU 從「設計上不能 eager」變成可逐運算元執行的 PrivateUse1 後端（40 個逐元素運算元、440 個產物零差異），配套修了分發日誌命名與 CUDA 複製核心守衛。這是本週期內最有結構意義的接入，但它只覆蓋逐元素運算元，主幹仍靠整圖編譯。
  • 通訊層進入標籤與發行包階段：FlagCX 打出 v0.14.1（按介面卡生成裝置位碼），rpm 線從三個後端擴到六個，wheel 釋出也被 build-infra 記賬。需要注意該標籤沒有 Release 正文，與 v0.14.0 的做法不一致。
  • 釋出工程在補課：changelog 上站與 Harbor、撤回兩筆從未推送的寒武紀 megatron 映象、應用頁一致性檢查進 pre-commit 與 CI、AMD 7.2.4 補 22.04 構建器。這些不產出新能力，但直接決定 2.3 的釋出清單能否自證。
  • 在審結構變化：在審從 401 降到 288、新開從 269 降到 101，上一期 FlagGems-Experimental 的 135 筆批次提交既未合入也無新增。當前在審主體是 FlagGems 181 筆，其中 53 筆新開多為燧原參考實現修復——說明多後端驗收的瓶頸在參考實現與測試口徑，而不是運算元供應。
  • 多分支需要區分口徑：FlagGems 同時在 master 與 kernelgen-dev 上合入（#7905、#7934），FlagTree 的合入分散在 triton_v3.5.x 與 feature/flagmega 分支，FlagGems-Experimental 的預設分支是 infra-ci。按預設分支統計會低估實際工作量，按提交檢索又會漏掉原子補核的倉。
  • 待觀察三點：其一，v0.14.1 之後是否補 Release 說明並進入 2.3 清單；其二，BPU 路徑是否從逐元素運算元擴到卷積等主幹運算元；其三，Megatron-MUSA-Titan 的程式碼是否在視窗後真正開始推送，以及是否與 Megatron-LM-FL 形成複用。

信源核查表

信源 核查結果
GitHub 組織倉庫 61 倉全量核查，23 倉視窗內推送（上一期 20 倉）
GitHub 提交檢索 命中 99 筆；搜尋索引對當日合入存在延遲，故與合入量並列呈現
GitHub 合併 PR 檢索 67 筆，16 個倉庫
GitHub 在審 PR 檢索 288 筆（新開 101），FlagGems 181 筆佔六成
Release / Tag 原子核查 31 倉；視窗內新增標籤 1 個（FlagCX v0.14.1，無 Release 正文）
org 事件流 100 條：推送 51、建分支 32、刪分支 9、PR 評審 8，無 PR 開合事件
版本排期 community/release/2.3 仍只有中英文排期表；build-infra 最新標籤仍為 v2.2.0
Google News RSS 24 組查詢，49 條候選，採納 1 條（Megatron-MUSA-Titan）
HN Algolia 8 組查詢，四天視窗內 0 條直接命中
CSDN FlagOS 專欄 最新可核文章停在 10-22，視窗內無新稿
智源社群 無視窗內新稿，首頁無本棧相關更新
成員單位官網 8 家巡檢；摩爾執行緒 10-28 一條三季度報告圖解；地平線抓取失敗；其餘無更新

完整信源清單

FlagGems PR #7600（崑崙芯連續段核心） — https://github.com/flagos-ai/FlagGems/pull/7600

github.com/flagos-ai/FlagTree/pull/1459>

infra/tags>

[92] 清微智慧官網新聞 — https://www.tsingmicro.com/news