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

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

本期索引

  • 今日重點：AMD ROCm 線從構建到運算元三處並進；量子合成編譯器單日 21 筆合入，UP-01 與 AO/PF 驗收線並行；玄鐵 13 個專用運算元 43 分鐘內批次合入（11-02）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：16 倉推送、272 筆提交、162 筆合入，在審 311 筆（11-02 ~ 11-03）
    • 1.2 版本面：2.3.0 執行時映象按後端推送，AMD ROCm 構建線首次建立（11-02）
    • 1.3 FlagQuantum：合成線單日 21 筆合入，UP-01 與 AO/PF 三條驗收線並行（11-02 ~ 11-03）
    • 1.4 FlagGems：玄鐵 13 個專用運算元 43 分鐘內合入（11-02）
    • 1.5 FlagGems：崑崙芯 XPU3 修復靜默錯誤形狀，十四筆效能與契約收口（11-02）
    • 1.6 FlagGems-sglang：競賽 17 筆 Triton 運算元批次合入，AMD gfx1100 兩條效能線（11-02）
    • 1.7 FlagTree 與 FlagGems-vllm：Hopper 誤編譯修復、玄鐵 MM 模型包 v1.1.0（11-02）
    • 1.8 FlagTrain 與 FlagBLAS：KMCompiler 八筆運算元，MUSA L1 BLAS 落地（11-02）
  • 二、新聞報道與生態
    • 2.1 渠道核查：24 組查詢零元件級命中，CSDN 與 HN 視窗內無新文（11-03）
    • 2.2 生態觀察：烏鎮峰會開幕，開源主題生態體驗館展至 11-05（11-02）
    • 2.3 周邊生態：九源聯合體釋出飛騰、TileLang、商湯三項聯合成果（11-02 覆盤稿）
  • 三、成員單位與後端廠商深挖
    • 3.1 達摩院玄鐵：專用運算元、MM 成本模型、chunk_kda 三線同日推進（11-02）
    • 3.2 崑崙芯：XPU3 foreach 契約修復與十四筆效能收口（11-02）
    • 3.3 昇騰與海光：W8A8 INT8 的 GEMM 與 BMM 兩條實現（11-02）
    • 3.4 摩爾執行緒：Conv1D 真一維 GEMM 把 26 個基準例全部拉過 0.8 倍線（11-02）
    • 3.5 沐曦、天數、清微、燧原與地平線：一側補運算元，一側補契約（11-02）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表、完整信源清單

今日重點：AMD ROCm 線三處並進；量子合成編譯器單日 21 筆合入；玄鐵 13 個專用運算元批次落地（11-02）

日期：2026-11-02　來源：build-infra PR #1589 · build-infra PR #1608 · FlagGems-sglang PR #271 · FlagQuantum PR #1004 · FlagGems PR #8240（全量見附錄）

  • AMD 面：build-infra #1589 為 FlagTree 的 amd 後端新建一條打包線（bare-ubuntu 22.04 構建機、backends.yaml 行、verify_stage 步驟與 wheel 目標），動機不是 glibc 下限而是溯源——廠商 0.7.0+amd3.6 的 wheel 本身即 22.04 構建，但不附帶 Source-Commit。該線在 amd-rocm7.2.4 執行時節點上做了 A/B：運算元掃描與 torch.compile 結果一致（maxdiff 1.526e-05，9/9），182 個廠商獨有檔案按設計全部對賬。同日 #1599 把 rocm7.2.4 的 torch 閉包對齊到 vLLM 0.32 的釘固組合；FlagGems-sglang #271 為 gfx1100 補 decode_attention、decode_grouped_attention、extend_attention 與 log_scaling_tau 四個運算元。構建、執行時、運算元三層在一個視窗內同向推進，AMD 線正從「能跑」走向「可追溯、可復現」。
  • 量子面：FlagQuantum 單日 21 筆合入、122 筆提交，落在三條驗收線上——UP-01 把 Python qfunc 程式做成公共前臺（#1004），AO-00/01/02 依次建立算術基線、純表示式歸一化與受保護算術實現（#1006、#1010、#1013），PF-00/01 建立 Python 編譯時延與程序記憶體賬本、再複用已校驗計劃欄位（#1018、#1021）。同期 QEC 側補噪聲 surface memory 組合、相干匹配糾正與分塊排程（#1012、#1015、#1019），執行時側改用規範化 IR 複用 Module 訓練並降低診斷快照開銷（#1017、#1014）。
  • 玄鐵面：FlagGems 在 16:03 至 16:46 的 43 分鐘內合入 13 個玄鐵專用運算元，覆蓋 Chebyshev 多項式、igamma、conv_transpose3d、quantized_lstm、nuclear_norm、fused_rms_norm_backward、_adaptive_avg_pool3d_backward 等長尾條目，均走 KernelGen 的玄鐵產線。這是繼運算元庫總量擴充之後，單後端專用運算元第一次以「批次」形態進入主幹。
  • 判斷：三條線共同指向同一件事——FlagOS 的能力擴張已從「榜單式補齊運算元數量」轉入「按後端成批交付 + 按驗收單元記賬」。AMD 有了自己的構建溯源線，量子棧把語義、算術、效能拆成可獨立驗收的小步，玄鐵則以分鐘級節奏批次併入。真正的瓶頸仍不在開發而在合入與釋出：本視窗合入 162 筆、新開 192 筆，佇列繼續擴張，2.3.0 也仍停在「映象先行、清單未凍結」。

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

1.1 組織節奏：16 倉推送、272 筆提交、162 筆合入，在審 311 筆（11-02 ~ 11-03）

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

  • 倉庫面：61 倉中 16 倉視窗內有推送，按推送時間從近到遠為 FlagQuantum、FlagQAI、FlagTensor、release-info、build-infra、FlagTree、FlagGems、FlagGems-vllm、FlagTrain、docs、FlagGems-sglang、optest、FlagDNN、vllm-plugin-FL、Torch-FL、FlagBLAS。其中 release-info 的三次推送全在 gh-pages 自動部署（分別對應 build-infra 的 1727064、672f77b、3c54d7e 三筆），docs 與 FlagTensor 的預設分支最新提交分別停在 10-03 與 10-28，二者 pushed_at 的重新整理來自非預設分支或標籤動作，均無視窗內預設分支新提交。
  • 提交面：提交檢索命中 272 筆，分倉為 FlagQuantum 122、FlagGems 52、FlagGems-sglang 24、FlagQAI 23、build-infra 18、FlagTrain 8、FlagGems-vllm 7、FlagTree 6、Torch-FL 5、optest 3、FlagBLAS 2，vllm-plugin-FL 與 FlagDNN 各 1。量子棧一倉佔去 44.9%，較上一期（三日視窗占比 58%）繼續回落，非量子側回到 55% 以上。
  • 合入面：合併 PR 162 筆，來自 12 倉：FlagGems 55、FlagGems-sglang 27、FlagQuantum 21、build-infra 18、FlagQAI 9、FlagTrain 8、FlagGems-vllm 7、FlagTree 6、Torch-FL 5、optest 4，vllm-plugin-FL 與 FlagBLAS 各 1。
  • 在審面：視窗內有更新的在審 PR 311 筆，新開 192 筆。分倉為 FlagGems 210（新開 148）、FlagTree 28（13）、FlagGems-vllm 19（6）、vllm-plugin-FL 14（5）、sglang-plugin-FL 7（2）、Torch-FL 5（1）、FlagGems-sglang 4（3）、FlagTrain 4（1）、flir 3（2）、FlagAttention 3（1）、FlagCX 3（1）、FlagQuantum 2（2）、FlagScale 2（2），FlagTensor、FlagTree-AscendNPU-IR、docs、optest、TransformerEngine-FL、FlagCV、Megatron-LM-FL 各 1。
  • 事件與分支面：org 事件流 100 條，構成為 PR 事件 31、推送 22、刪分支 17、建分支 16、議題評論 7、議題事件 3、評審評論 2、評審 1、fork 1。建分支與刪分支合計 33 條，幾乎全部落在 FlagQuantum 的 feat/synth-* 系列，說明量子合成線仍以短分支快進快出為主。
  • 對比：與上一 24 小時視窗（合入 183 筆、新開 84 筆）相比，合入量下降 11.5%，新開量上升 128.6%；與三日視窗的日均（合入 38 筆、新開 47 筆）相比，本視窗的合入與新開均明顯放大。合入與新開同步處於高位，且新開接近合入的 1.2 倍，是典型的工作日「產線開足、評審吃緊」形態。

1.2 版本面：2.3.0 執行時映象按後端推送，AMD ROCm 構建線首次建立（11-02）

日期：2026-11-02　來源：build-infra PR #1589 · build-infra PR #1595 · build-infra PR #1599 · build-infra PR #1606 · build-infra PR #1607 · build-infra PR #1608 · community 2.2 釋出清單

  • 新增構建線：#1589 為 FlagTree 的 amd 後端建立獨立打包線與 wheel 產線，加 backends.yaml 行、verify_stage 步驟與 wheel 工作流目標。PR 自述動機是溯源而非相容——廠商同版本 wheel 不帶 Source-Commit，故以自家 22.04 構建機重出，並在 amd-rocm7.2.4 執行時上做運算元掃描與 torch.compile 的 A/B 對賬（maxdiff 1.526e-05，9/9 透過，182 個廠商獨有檔案按設計計入）。該線每日構建開關暫為關閉。
  • 執行時收口：#1599 把 rocm7.2.4 的 torch 閉包改為與 vLLM 0.32 的釘固組合一致，避免同一執行時內出現兩套 torch 版本假設；#1606 把 flagcx 的「預裝 wheel」判定從可匯入性改為按後設資料識別，避免路徑上殘留的同名包被誤判；#1607 讓 wheel 清單收集支援任意深度的目錄層級。
  • 版本標記：#1595 與 #1608 兩筆機器人提交記錄 2.3.0 的映象描述與 changelog 日期。據 #1608 正文，執行時映象工作流已按後端推送 2.3.0，並把各後端待寫的 changelog 條目按 registry push_time 落日期，本條對應 amd-rocm7.2.4 層。至此 base 層與寒武紀 neuware 4.4.3、沐曦 maca 3.8.1.3、海光 dtk26.10、AMD rocm7.2.4 四層均已在 2.3.0 名下完成日期回填。
  • 釋出態核查：31 倉 Release 與 8 倉 Tag 原子核查，視窗內沒有新的 Release 物件；社群倉庫 release/2.3 下的清單檔案仍返回 404，release/2.2 清單在架。即映象已按後端逐一推送，但清單凍結與站點上線兩步仍未發生，與上一期判斷一致。
  • 待觀：18 筆合入裡，文件與知識層 9 筆、AMD 構建與執行時 4 筆、wheel 與打包 3 筆、機器人 changelog 2 筆。開發側的 2.3.0 工作已基本轉為「記錄既成事實」，若本工作周仍不凍結清單，2.3.0 的釋出視窗會被下一個版本規劃擠壓。

1.3 FlagQuantum：合成線單日 21 筆合入，UP-01 與 AO/PF 三條驗收線並行（11-02 ~ 11-03）

日期：2026-11-02 ~ 2026-11-03　來源：FlagQuantum PR #1002 · FlagQuantum PR #1004 · FlagQuantum PR #1006 · FlagQuantum PR #1010 · FlagQuantum PR #1013 · FlagQuantum PR #1018 · FlagQuantum PR #1021

  • 語義線（UP）：#1002 先讓原始常量角度的 PHASE 門走通既有 CoreIR；#1003 確立 UP-00 的語義邊界並保留 Qmod 的 RZ 相容；#1004 把 UP-01 的 Python 程式名稱空間接到前臺——@synth.qfunc 裝飾的函式可直接書寫分配、門與輸出，編譯器側捕獲帶型別的 qfunc 準備與算術組合，執行時側以全新埠執行程式內準備。PR 正文給出可復算示例：一個含兩個量子位分配、Hadamard 變換與 result |= x*x+y 的程式，可在同一公共工作流裡編譯與執行。
  • 算術線（AO）：#1006 建立 AO-00 的算術基線與獨立 oracle，並把「驗證範圍不得誇大」寫成校驗器規則；#1010 落地 AO-01，對純表示式做帶保護的公共子表示式消除與可靠的位事實歸一化；#1013 落地 AO-02，補齊受保護的平方、常量與終端 XOR 實現。三筆按 AO-00 到 AO-02 的順序遞進，每一步都保留前一步的資源基線與驗收證據。
  • 效能線（PF）：#1018 建立 PF-00 的 Python 編譯時延與作業系統 RSS 基線，把計時、記憶體與診斷佇列做成隔離觀測，不改生產程式碼也不替換既有資源基線；#1021 以 PF-01 複用已校驗的計劃欄位，減少 Services 側重複校驗與物件重建。兩筆合起來把「合成一次要多久、佔多少記憶體」變成可復算的數字，而不是單次觀察。
  • 旁線同步：QEC 側 #1012 驗證噪聲 surface memory 實驗的組合正確性、#1015 保留相干匹配的糾正記錄、#1019 驗證分塊排程與晚期記憶體失效；執行時側 #1017 讓 Module 訓練複用規範化 IR、#1014 降低預設診斷快照開銷、#1020 把惰性 Torch 編譯邊界寫成經批准的契約。視窗末另有 #1022、#1023 兩筆在 00:21 與 01:19 開出，方向仍是合成線與執行時。
  • 判斷：這 21 筆的共同特徵是把「一個大功能」拆成「可獨立驗收的單元」——語義、算術、效能各自有基線、oracle 與失敗即紅的證據。對量子棧而言，這比單點效能數字更重要：它讓後續任何一次暫存器分配或門合成改動，都能被既有賬目立刻測出代價。

1.4 FlagGems：玄鐵 13 個專用運算元 43 分鐘內合入（11-02）

日期：2026-11-02　來源：FlagGems PR #8240 · FlagGems PR #8229 · FlagGems PR #8237 · FlagGems PR #8239 · FlagGems PR #8232 · FlagGems PR #8231

  • 批次構成：13 筆均標註 KernelGen 玄鐵產線，自 16:03 的線性組合運算元起，到 16:46 的 poisson_nll_loss 止。覆蓋範圍分四類：特殊函式（Chebyshev 多項式、igamma）、卷積族（三維卷積、轉置卷積、時間卷積反向）、量化與歸一化（量化 LSTM、RMSNorm 反向融合）、矩陣與池化（矩陣範數、三維自適應池化反向、分數最大池化反向、Lanczos 上取樣）。全部為新增專用實現，不改動其他後端與公共入口。
  • 形態特徵：條目集中在長尾——特殊函式（Chebyshev、igamma）、三維卷積與轉置卷積、量化 LSTM、矩陣範數、池化反向。這些正是通用 Triton 實現效能最差、專用化收益最大的一類，也與上一視窗玄鐵側「先補主幹」的節奏形成接續。
  • 節奏：43 分鐘 13 筆，平均 3.3 分鐘一筆，且與崑崙芯、摩爾執行緒、昇騰、海光四家的同日後端條目交織在同一時間帶。說明 FlagGems 的評審已能按後端並行消化批次運算元單，而不是序列排隊。
  • 對照：上一視窗 FlagGems 的玄鐵條目為零；本視窗 13 筆，佔 FlagGems 當日 55 筆合入的 23.6%。同一倉庫另有崑崙芯 14 筆、摩爾執行緒 5 筆、NVIDIA 側 KernelGen 2 筆、沐曦 2 筆，後端分佈比過去更均衡。
  • 待觀：這批運算元目前只落在玄鐵專用產線，尚無跨後端複用或與 FlagGems-vllm 推理路徑的對接記錄。下一步要看的，是它們能否被上層模型（尤其量化 LSTM 與池化反向）真正呼叫，而不是隻增加覆蓋率計數。

1.5 FlagGems：崑崙芯 XPU3 修復靜默錯誤形狀，十四筆效能與契約收口（11-02）

日期：2026-11-02　來源：FlagGems PR #8038 · FlagGems PR #8034 · FlagGems PR #7976 · FlagGems PR #8123 · FlagGems PR #8245 · FlagGems PR #8049

  • 正確性修復：#8038 是當日最值得讀的一筆。foreach 系列的 out-of-place 標量過載在「同 dtype、同裝置、同元素數」時走快路徑，輸出統一按第一個張量的形狀分配再切檢視，而快路徑的准入條件比較的是元素數而非形狀——於是形狀不同但元素數相同的列表會全部繼承首個張量的形狀，產生靜默錯誤結果。修復把准入改為按完整形狀判定，另兩筆把十六個標量輸出改為單基址定址、把列表輸出合併為一塊平坦緩衝。
  • 契約修復：#7976 把 foreach 點號取槽位的索引改為取自 program_id(0)；#8034 在提交 JIT 之前先求值自動調優的網格，避免以未求值的網格啟動；#7956 解包標量解析的三元返回值，修正快步路徑的取值。
  • 效能收口：#8056 為 triu_、resolve_neg、le 與位右移補快路徑；#8245 為 flip、ge、lerp 補點態快路徑並撤掉上一版 BF16 一維 tile 重構；#8108 融合 pool3d 反向的精確路徑、對小乘法跳過點態管線；#8107 在每通道度數一致時展開 Chebyshev 的 t/w；#8030 加速 choose_qparams_optimized、kl_div 與兩個 Bessel 核；#8111 把 Jacobi 掃描分塊，使 nuclear_norm 只需 nb 次啟動而非 k 次；#8049 為 linspace 做單公式快路徑；#8248 另有一組運算元特化效能修正。
  • 回滾訊號：#8123 撤回「崑崙芯 BF16 點態效能最佳化」，理由是引入迴歸；同日 #8245 以不同方案重做並明確「撤掉 #8052 的 BF16 一維 tile 重構」。一撤一補同視窗發生，說明 XPU3 側的點態最佳化仍在試驗期，合併前缺少足夠的形狀覆蓋。
  • 判斷：崑崙芯這一組的關鍵詞是「契約」——形狀、槽位、網格、返回值四個層面的隱式約定各修一處。這類問題的共同後果是靜默錯誤而非崩潰，比效能回退更值得在日報裡留痕。

1.6 FlagGems-sglang：競賽 17 筆 Triton 運算元批次合入，AMD gfx1100 兩條效能線（11-02）

日期：2026-11-02　來源：FlagGems-sglang PR #207 · FlagGems-sglang PR #220 · FlagGems-sglang PR #256 · FlagGems-sglang PR #270 · FlagGems-sglang PR #271 · FlagGems-sglang PR #275

  • 競賽批次：10:22 至 10:55 的半小時內，17 筆標註 FlagOS 競賽 Track1 的 Triton 運算元 PR 集中合入，含 Hadamard 變換、Gemma 融合加 RMSNorm、專家並行的 scatter 與 gather、scatter-to-padded、單趟 RMSNorm、RMSNorm 縮放與縮放偏移、QK 頭 LayerNorm、QK-Gemma-RMSNorm-RoPE 融合、QK 逆 RMS、LayerNorm 調製等。提交者集中在兩位競賽參與者，評審以批次批次合入。
  • AMD 效能線一：#256 為 RDNA3（gfx1100）補 chunked_sgmv_expand、gate_up_lora_b、sgemm_lora_b、per_group_transpose、silu_and_mul 與 fused_rmsnorm，在 Radeon PRO W7900D 上調優並測試；除 fused_rmsnorm 外輸出與通用實現逐位一致。LoRA 側把 16 位輸入的訪存從 2 位元組提到 16 位元組，fp32 時把秩迴圈改為小 tile 上的 FMA，規避通用核的暫存器溢位。
  • AMD 效能線二：#271 為同一架構補 decode_attention、decode_grouped_attention、extend_attention 與 log_scaling_tau。前兩者共用分塊 KV 核：一個 program 負責某序列的一組查詢頭與一段 KV 快取，再由第二個核按 log-sum-exp 合併分片；頭塊大小取「仍能填滿 96 個計算單元」的最大值，僅當網格會留下空閒單元時才切分序列。
  • 配套整理：#270 的批次合入把第 9 批運算元併入主線；#263 新增跨後端驗證的可複用技能文件；#274、#275 移除運算元套件裡的模型品牌命名並統一加 sglang_fl_ 字首；#272 修正基準輸入函式與運算元簽名不一致；#276、#278 收緊遠端任務產物的清理規則。
  • 判斷：這個倉庫本視窗承擔了兩個角色——白天是競賽運算元的吞吐口，下午轉入 AMD 工作站的效能補齊。競賽批次帶來覆蓋率，gfx1100 批次帶來真實硬體上的可執行性，兩者互補；但競賽 PR 的評審深度（多為批次合入）與 AMD 側的逐位一致性要求，形成了明顯的質量梯度。

1.7 FlagTree 與 FlagGems-vllm：Hopper 誤編譯修復、玄鐵 MM 模型包 v1.1.0（11-02）

日期：2026-11-02　來源：FlagTree PR #1236 · FlagTree PR #1460 · FlagTree PR #1451 · FlagTree PR #1314 · FlagGems-vllm PR #1030 · FlagGems-vllm PR #1042 · FlagGems-vllm PR #1038

  • 玄鐵成本模型：#1236 支援玄鐵 ZW810E 的 MM/MV 成本模型包 1.1.0，在 FlagTune 模型目錄裡新增條目，並讓模型契約接受有序的 configs 列表——逐個候選校驗引數名與合法取值，拒絕同時宣告 config_space 的契約。該包含 8 個 BF16 的 flaggems/mm 變體（含與 mv 共用的 gemv_ppu）與 2 個沿用 1.0.0 的 flaggems/mul 模型。
  • Hopper 誤編譯：#1460 修 TritonGPU 的流水化 cp.async 降級與 WGMMA 運算元緩衝複用問題，屬會算錯而非報錯的型別；#1451 把 WGMMA 的 warp 選擇與上游 MMAv3 對齊，覆蓋 NVIDIA 與摩爾執行緒兩側；#1314 在兩次非同步 TME 複製之間跳過 membar 屏障，屬摩爾執行緒側的路徑最佳化。
  • FlagGems-vllm 運算元：#1030 補 mrope 的運算元清單入口；#1042 修 PPU 側 FP8 量化輸出處理與逆 RoPE 的 epsilon 語義；#1038 為天數與玄鐵最佳化 chunk_kda；#1019 針對 GLM-5.2 的形態最佳化 grouped_topk；#959 修 qwen4 的 int64 偏移與 PLE 狀態原地更新同步；#1035 把 fused_q_kv_rmsnorm 的基準呼叫遷到新 API；#1047 修迴圈 GDN 的原生基線准入。
  • 判斷：FlagTree 這一組全是「編譯器正確性」而非新功能——誤編譯、warp 對齊、屏障冗餘，三項分別對應算錯、結果漂移與多餘同步。對統一編譯器而言，這類修復比新增後端更能決定下游敢不敢開最佳化。

1.8 FlagTrain 與 FlagBLAS：KMCompiler 八筆運算元，MUSA L1 BLAS 落地（11-02）

日期：2026-11-02　來源：FlagTrain PR #32 · FlagTrain PR #40 · FlagTrain PR #36 · FlagTrain PR #39 · FlagTrain PR #47 · FlagBLAS PR #157

  • FlagTrain 運算元：八筆合入集中在 KMCompiler 的 NVIDIA 線——weighted_squared_relu_impl（含 Ascend 標註）、fused_h_aggregate 前反向、bias_swiglu_impl、scaled_masked_softmax_cuda 前反向、fused_proj_rms_compute_h。均以 Triton 核實現，按訓練常用融合點成組補齊。
  • 依賴與流程：#45 修 uv 管理下的映象執行時保留問題；#43 修正 compared_speedup 與 speedup 的統計口徑；#47 修後端運算元特化實現的迴圈呼叫異常，屬路由層的分派缺陷。
  • FlagBLAS：#157 為 MUSA 補 L1 BLAS 後端與 muBLAS 的正確性、效能參照，覆蓋 AMAX、AMIN、ASUM、AXPY、COPY、DOT/DOTC/DOTU、NRM2、ROT/ROTG/ROTM/ROTMG、SCAL 與 SWAP。至此 BLAS 的 L1 層在摩爾執行緒側有了可對照的實現。
  • optest 配套：#26 增加運算元排除列表、#27 增加運算元結果彙總統計、#25 強制百分之百覆蓋率、#24 加 Python 質量檢查——測試設施本身開始被當作產品維護。
  • 判斷：訓練側與大模型推理側的分工更清楚了：FlagTrain 承接訓練融合運算元，FlagGems-vllm 承接推理路徑，FlagBLAS 補基礎線性代數。三者共用同一套測試與質量門，這比各自擴運算元更能降低跨倉迴歸。

二、新聞報道與生態

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

日期：2026-11-02 ~ 2026-11-03　來源：Google News FlagOS 檢索 · CSDN FlagOS 專欄 · Hacker News 檢索 · 智源社群

  • 中文查詢：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen 七組在 14 天視窗內零命中；智源研究院 開源、智源研究院 晶片、智源 大模型 開源棧、清微智慧、摩爾執行緒 開源、沐曦 開源、燧原科技、國產算力 開源軟體棧等 8 組在 7 天視窗內共 17 條，逐條核題後全部為社會、財經、活動類稿件，無一條指向 FlagOS 元件。
  • 英文查詢：FlagOS、FlagGems、BAAI FlagOS、flagos-ai、BAAI open source AI system stack、Tsingmicro、Moore Threads open source 七組在視窗內均為零命中。
  • 專欄核查：CSDN FlagOS 專欄首頁 52 個文章連結，逐篇核時後最新一篇仍為 10-29 的「大模型推理救星——一個外掛搞定多晶片適配」，視窗內無新文；頁面出現的 11-03 日期屬頁面側當日標記，非文章時間。
  • 社群與 HN：智源社群搜尋頁為客戶端渲染，抓取僅得框架頁，無可取條目，以首頁核查為準；HN Algolia 八組查詢（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）在 5 天視窗內零直命中。
  • 成員官網：九家成員單位官網新聞頁在 11-02 至 11-03 無日期命中；地平線新聞頁抓取失敗，海光與智源首頁為指令碼渲染的短頁，均無法取到條目列表。
  • 結論：新聞側零元件級新增屬平靜視窗，與上一期一致。本報告正文以 GitHub 事實為主，新聞側只保留生態背景兩條，均明確標註為周邊事件。

2.2 生態觀察：烏鎮峰會開幕，開源主題生態體驗館展至 11-05（11-02）

日期：2026-11-02　來源：新華社報道（東方財富轉載） · 新華網浙江

  • 會期：2026 年世界網際網路大會烏鎮峰會於 11-02 至 11-05 在浙江烏鎮舉行，濮院設分會場，觀眾預約平臺已開放。
  • 開源主線：峰會重點配套的「開源主題生態體驗館」自 11-01 在烏鎮世界網際網路科技館開放，展陳覆蓋一至三層，首次集中展出人工智慧開源開放重大科技成果與國家人工智慧應用中試基地建設成果；一樓設兩大主題特展與開源體驗區，三樓為開源會客廳，會期舉辦「烏鎮 Talk·開源青年說」「科創之夜」等活動。
  • 與 FlagOS 的關係：視窗內的公開報道未出現 FlagOS 或其元件，本條僅作開源議題的外部環境記錄，不作歸因。若 FlagOS 側有展出或釋出，需以官方渠道另行核實。
  • 待觀：開源議題被提升為國家級峰會的獨立展館，說明「開源開放」在政策敘事中的位置繼續上移；對 FlagOS 這類統一軟體棧而言，這既是敘事紅利，也意味著與魔搭等模型社群的展示位競爭會更直接。

2.3 周邊生態：九源聯合體釋出飛騰、TileLang、商湯三項聯合成果（11-02 覆盤稿）

日期：2026-11-02（會期 10-31）　來源：鳳凰網海南產經報道 · 新浪轉載大會開幕報道

  • 事件：2026 GAI+C 人工智慧+大會的「智慧計算系統創新與開放生態」分論壇於 10-31 在京舉行，覆盤稿在 11-02 見網。論壇由九源智慧計算系統生態聯合體與北京市人工智慧協會主辦，現場釋出「九源×飛騰」「九源×TileLang」「九源×商湯多模態大模型訓推套件」三項聯合成果，並啟動 2026 秋季啟元人工智慧大賽。
  • 敘事：中國工程院院士鄭緯民在大會主旨報告中直指國產算力「有卡難用、煙囪式適配」，提出以統一軟體棧支撐「一套程式碼、無需修改」跨平臺執行。這與 FlagOS 的技術主張高度同構，但主體是另一條生態線（九源聯合體、啟元實驗室）。
  • 與 FlagOS 的關係：報道未提及 FlagOS，本條作為並行生態動作記錄，用於觀察國產統一軟體棧的競爭格局，不計入 FlagOS 專案進展。
  • 待觀：九源選擇與 TileLang 聯合釋出，說明編譯器層正成為各生態聯盟的結盟點；FlagOS 側的對應資產是 FlagTree 與 TLE 語言擴充套件。兩條線在「統一編譯器」這一層的路線差異，值得在後續視窗繼續跟蹤。

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

3.1 達摩院玄鐵：專用運算元、MM 成本模型、chunk_kda 三線同日推進（11-02）

日期：2026-11-02　來源：FlagGems PR #8240 · FlagTree PR #1236 · FlagGems-vllm PR #1038

  • 運算元層：13 個玄鐵專用運算元在 43 分鐘內合入 FlagGems，覆蓋特殊函式、三維卷積、量化 LSTM、矩陣範數與池化反向。這批條目的共同點是通用 Triton 實現在玄鐵上收益偏低，專用化後可直接進運算元庫預設分派。
  • 編譯層：#1236 把玄鐵 ZW810E 的 MM/MV 成本模型包升到 1.1.0，納入 FlagTune 模型目錄，並讓自動調優契約接受顯式 configs 列表——按引數名與合法取值逐個校驗，拒絕與 config_space 並存的寫法。該包 8 個 BF16 mm 變體加 2 個 mul 模型，是自動調優在玄鐵上的第一份完整成本模型。
  • 推理層：#1038 為 chunk_kda 補天數與玄鐵兩個後端的最佳化，屬 FlagGems-vllm 的長序列路徑。
  • 判斷：玄鐵這一天的動作分佈在運算元、編譯、推理三層，且都指向「專用化」而非「通用相容」。這與玄鐵作為 RISC-V 高效能核的定位一致：先把長尾運算元的專用實現補齊，再讓成本模型驅動自動調優，最後在推理框架裡兌現。

3.2 崑崙芯：XPU3 foreach 契約修復與十四筆效能收口（11-02）

日期：2026-11-02　來源：FlagGems PR #8038 · FlagGems PR #8034 · FlagGems PR #8123 · FlagGems PR #8245

  • 靜默錯誤：#8038 指出 foreach 的快路徑只比較元素數、不比較形狀，形狀不同而元素數相同的張量列表會全部繼承首個張量的形狀，輸出既不報錯也不越界。修復按完整形狀判定準入，並把十六個標量輸出改為單基址定址、列表輸出合併為平坦緩衝。
  • 網格與槽位：#8034 在提交 JIT 前先求值自動調優網格；#7976 改從 program_id(0) 取 foreach 的槽位索引；#7956 修標量解析三元返回值的解包。
  • 效能補丁：#8056、#8245、#8108、#8107、#8030、#8105、#8111、#8049、#8248 共九筆，覆蓋點態快路徑、pool3d 反向融合、Chebyshev 展開、Jacobi 分塊與 linspace 單公式。
  • 回滾：#8123 撤回 BF16 點態最佳化，理由為迴歸；#8245 以另一方案重做並撤掉 #8052 的一維 tile 重構。一撤一補說明該路徑仍在試錯。
  • 判斷：崑崙芯當日的價值不在效能數字，而在修掉了一個會靜默算錯的形狀契約。對多後端運算元庫而言，這類缺陷比慢十倍更危險——它不會被基準發現，只會被下游模型以「精度異常」的形式撞上。

3.3 昇騰與海光：W8A8 INT8 的 GEMM 與 BMM 兩條實現（11-02）

日期：2026-11-02　來源：FlagGems PR #6060 · FlagGems PR #7741 · FlagGems PR #7774 · FlagGems PR #7760

  • 昇騰 GEMM：#6060 為 mm_w8a8_int8 與 mm_w8a8_int8_out 增加昇騰後端，走公開入口分派。運算元接預量化 INT8 的 A 與 B、FP32 的標量或逐行逐列 scale、可選 bias，整數乘加後應用兩側 scale 與 bias，輸出 BF16、FP16 或 FP32；小 M 窄 N 走向量乘加核，每段 FP32 歸約不超過 1024 個 INT8 乘積以保證整數部分精確。不支援非對稱零點。
  • 海光 BMM：#7741 為海光補通道級 bmm_w8a8，複用既有 scaled-MM 核與 tile 選擇，把 INT8 矩陣乘、FP32 通道縮放與輸出轉換融合在一個核內。
  • 精度修：#7774 在昇騰側先提升兩個運算元再做 CANN libdevice 的 pow，避免混合精度下的下溢與精度損失。
  • Hopper 效能：#7760 用 TMA 流水線最佳化 FP8 W8A8 的 BMM，屬 NVIDIA 側的對應最佳化。
  • 判斷：兩家在同一個視窗各補一條 W8A8 路徑——昇騰選 GEMM 的完整語義（含逐行逐列 scale、三種輸出 dtype），海光選 BMM 的通道級縮放複用。差別在語義覆蓋廣度與實現複用的取捨，也反映各自下游模型對量化形態的不同需求。

3.4 摩爾執行緒：Conv1D 真一維 GEMM 把 26 個基準例全部拉過 0.8 倍線（11-02）

日期：2026-11-02　來源：FlagGems PR #6754 · FlagGems PR #7428 · FlagGems PR #6903 · FlagBLAS PR #157 · FlagTree PR #1314

  • Conv1D 結果：#6754 為 MTT S5000 增加 conv1d 後端覆蓋，把官方 conv1d_padding 基準從 18/26 例達標提到 26/26 例不低於 0.80 倍 torch；此前所有 FP32 K3/K5 padding 例只有 0.41 至 0.53 倍。
  • 三層改法：其一，conv1d 原先無 MTHREADS 覆蓋、全部走通用 conv2d，小分組形狀會實體化 padding、W=1 形狀只命中單條有效 OW 通道；改路由後去掉冗餘 padding 與 bias 分配並修退化寬度分派。其二，新增專用 Triton-MUSA Conv1D 核，按 M 等於 N 乘 Lout 做三維網格切分，輸出通道不再做除法取模。其三，權重預打包為按核寬、輸入通道、輸出通道排列，配合帶精度補償的 SQMMA。
  • 配套：#7428 最佳化 S5000 上 one_hot 的校驗與推理；#6903 把空索引視為 index_add 的空操作；#157 補 MUSA 的 L1 BLAS；#1314 在兩次非同步 TME 複製間跳過 membar。
  • 判斷：這是本視窗少見的「把基準全部拉過線」的完整案例——路由、專用核、權重佈局、指令級精度補償四層同時改，且給出前後對照。對其他後端是一個可複製的模板。

3.5 沐曦、天數、清微、燧原與地平線：一側補運算元，一側補契約（11-02）

日期：2026-11-02　來源：FlagGems PR #7590 · FlagGems PR #7015 · Torch-FL PR #704 · Torch-FL PR #702 · FlagGems-vllm PR #1038 · FlagDNN 提交

  • 沐曦：#7590 最佳化 triangular_solve 的預設與 out 路徑；#7015 新增 cudnn_batch_norm 的前向與 out，並修正成對反向；Torch-FL #702 修正 MetaX SDPA 用例的跳過理由——原先歸因於 fp32，實際原因另有其他，屬於測試可信度修復。
  • 天數：#1038 為 chunk_kda 補天數後端最佳化；FlagDNN 修 iluvatar 的 GPU 名稱登記（單筆提交）；FlagGems #7664 把 apply_repetition_penalties 的基準開進 Iluvatar。
  • 清微：Torch-FL #704 把 tsingmicro 納入 conf 與註冊集一致性檢查，此前該平臺被排除在六個平臺之外，配置與註冊集不一致無法被 CI 捕獲。這是一筆純測試改動，但補上了清微側的契約缺口。
  • 燧原：視窗內僅一筆在審 PR，為 KernelGen 的 Enflame 側修四個運算元的 CUDA 專用裝置守衛（#8104），尚無合入。
  • 地平線：本視窗無新增提交或在審 PR；上一視窗的 BPU 卷積與池化路徑未在本視窗繼續推進。
  • 判斷：五家的動作分兩類——沐曦與天數在補運算元與基準，清微在補測試契約，燧原與地平線處於靜默期。對成員單位而言，能不能持續出現在每日合入列表裡，本身就是投入強度的直接指標。

四、總結與趨勢觀察

日期：2026-11-02 ~ 2026-11-03　來源：flagos-ai 組織倉庫 · build-infra PR #1589 · FlagQuantum PR #1004 · FlagGems PR #8240

  • AMD 線在一個視窗內補齊三層：構建側新增 FlagTree 的 amd 打包線並以 A/B 對賬證明等價（maxdiff 1.526e-05，9/9）；執行時側把 rocm7.2.4 的 torch 閉包對齊到 vLLM 0.32 的釘固組合；運算元側為 gfx1100 補 LoRA 與注意力共十個運算元。三者合起來，AMD 從「有後端」變成「有可追溯的構建、可復現的執行時、可調優的運算元」。
  • 量子棧進入「按驗收單元交付」階段：單日 21 筆合入分佈在 UP（語義）、AO（算術）、PF（效能）三條線，每條都有獨立基線、oracle 與失敗即紅的證據。這種拆法讓量子編譯器的每次改動都能被既有賬目測出代價，比追求單點加速比更能支撐長期演進。
  • 玄鐵把專用運算元做成了批次：13 個專用運算元 43 分鐘內合入，平均 3.3 分鐘一筆，集中在特殊函式、三維卷積、量化 LSTM 與池化反向等長尾條目。這說明 KernelGen 的玄鐵產線已具備批次供給能力，評審也能按後端並行消化。
  • 評審吞吐是當前真正的瓶頸：本視窗合入 162 筆、新開 192 筆，在審總量 311 筆，其中 FlagGems 一倉 210 筆（新開 148）。合入量較上一 24 小時視窗下降 11.5%，新開量卻上升 128.6%——產線開足、評審吃緊的結構沒有改變。
  • 2.3.0 仍停在映象先行：base 層與寒武紀、沐曦、海光、AMD 四層都已在 2.3.0 名下回填 changelog 日期，執行時映象也按後端推送，但 community 的 release/2.3 清單仍為 404、GitHub Release 零新增。與上一期相比沒有實質推進，若本工作周仍不凍結清單，釋出視窗會被下一版規劃擠壓。
  • 新聞側連續第二個平靜視窗：24 組中英文查詢零元件級命中，CSDN 專欄最新文仍為 10-29，HN 零直命中。生態背景兩條（烏鎮開源展館、九源聯合體三項聯合釋出）均明確標註為周邊事件，未計入專案進展。

信源核查表

信源 核查結果
GitHub org flagos-ai（61 倉） 16 倉視窗內推送，272 筆提交、162 筆合入、311 筆在審（新開 192）
GitHub Release / Tag 原子核查（31 倉 / 8 倉） 視窗內零新增；FlagCX v0.14.1（11-01 00:10）與 FlagTree 0.7.1a1+tsingmicro3.6（10-29）均在視窗外
community 釋出清單 release/2.3 下清單檔案返回 404，release/2.2 在架
release-info 站點 視窗內三次 gh-pages 自動部署，均對應 build-infra 提交，無獨立釋出動作
Google News（24 組中英文查詢） 17 條候選全部為社會、財經、活動類稿件，零元件級命中
CSDN FlagOS 專欄 52 個文章連結，最新仍為 10-29，視窗內無新文
HN Algolia（8 組） 零直命中
智源社群 hub.baai.ac.cn 搜尋頁客戶端渲染，僅得框架頁，無條目
成員單位官網（9 家） 無 11-02 至 11-03 日期命中；地平線抓取失敗，海光與智源首頁為指令碼渲染短頁

完整信源清單

[21] FlagQuantum PR #1018（PF-00 時延與 RSS 基線） — https://github.com/flagos-ai/FlagQuantum/pull/1018

ng PR #220（競賽 Hadamard 變換） — https://github.com/flagos-ai/FlagGems-sglang/pull/220

ccdb9>