調研視窗：2026-10-19 06:00 ~ 2026-10-20 06:00（北京時間，24 小時；週二晨報，視窗自上一期日報截點接續，不含大會期間內容）。

信源：GitHub（org: flagos-ai 61 倉庫全量核查、提交檢索 93 筆、合併 PR 88 筆與在審 PR 180 筆檢索、16 個活躍倉 Release 與標籤核查、org 事件流 100 條與分支級兜底）、Google News RSS（24 組中英文查詢詞，走代理）、HN Algolia（8 組）、中華網與儲存線上技術稿、CSDN 與智源社群渠道核查（詳見附錄信源清單）。

本期索引

  • 今日重點：大會後首個完整工程日——93 筆提交、88 筆合入，build-infra 把昇騰四輪子、清微與曦望統一到 22.04 自包含 builder（glibc 底線由 2.38 降至 2.35）；FlagQuantum 以 405 檔案合入 159 個新公開名並確立 M0 路線圖；FlagBLAS 補齊海光 gfx936 六精度 GEMM；FlagDNN 直推 master 補天數 iluvatar 等價效能基線（10-19）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：16 倉推送、93 筆提交、88 筆合入；glibc 底線下移成當日主線（10-19）
    • 1.2 build-infra：昇騰四輪子從 24.04 執行時遷入 22.04 自包含 builder，清微與曦望同日補齊（10-19）
    • 1.3 FlagQuantum：405 檔案合入量子棧擴容，M0 至 M4 路線圖確立（10-19）
    • 1.4 FlagGems：KernelGen 稀疏族批次在審，崑崙芯 XPU3 注意力族與昇騰 mm 分派並進（10-19 ~ 10-20）
    • 1.5 FlagBLAS：海光 gfx936 六精度 GEMM 合入，dgemm 依賴 FlagTree fp64 MMAC（10-19）
    • 1.6 FlagTree：燧原 GCU300 基線與 AMD RDNA 降級路徑、昇騰 3.5 py312 交付（10-19）
    • 1.7 推理與訓練棧：曦望與燧原圖模式、HY4 H100 接入、昇騰 vLLM 0.28 升級（10-19）
    • 1.8 FlagDNN / FlagTrain / FlagSparse / Torch-FL：天數等價效能、摩爾執行緒後端、MUSA 最佳化（10-19）
  • 二、新聞報道與生態
    • 2.1 會後首篇深度技術稿：中華網刊出 FlagOS 2.2 全棧拆解，補充七個量化案例（10-19）
    • 2.2 報道擴散與渠道核查：儲存線上演講全文為 10-18 舊稿晚索引，CSDN 與智源社群無新增（10-19 ~ 10-20）
  • 三、成員單位深挖
    • 3.1 海光：FlagBLAS 六精度 GEMM 與 L1 支援同時落庫（10-19）
    • 3.2 天數智芯：FlagDNN 等價效能基線直推 master，Torch-FL 拆出獨立執行時（10-19）
    • 3.3 清微與曦望：兩個後端同日進入 FlagCX 22.04 builder（10-19）
    • 3.4 燧原：GCU300 基線、vLLM 基準工作流與 builder 斷言修正（10-19）
    • 3.5 摩爾執行緒、昇騰、達摩院玄鐵：MUSA 運算元線、CANN 9.0 基線、T-Head GRU 死鎖修復（10-19）
  • 四、總結與趨勢觀察

今日重點：大會後第一個工程日，交付面的統一壓過新功能（10-19）

日期：2026-10-19　來源：build-infra PR #1414 · FlagQuantum PR #635 · FlagBLAS PR #151 · FlagDNN commits（全量見附錄）

  • 節奏面：24 小時視窗內 16 個倉庫有推送、93 筆提交、88 筆合入、180 筆在審 PR 有更新。合入量高於上一期三日視窗的日均水平（約 46 筆/日），提交時間集中在 07:00 至 23:00，峰值落在 14:00 至 17:00，是典型的工作日節奏，未見大會期間的集中放量。
  • 主線是「交付面統一」而非新能力：build-infra 16 筆提交全部圍繞製品通道——把昇騰四個輪子從 24.04 執行時映象遷到獨立的 ubuntu:22.04 自包含 builder（PR #1414），同日為曦望（PR #1418）與清微（PR #1422）補上同規格 builder。原因是 24.04 映象裡編出的 libflagcx.so / _C*.so 鏈到 GLIBC_2.38，在實際 22.04 物理機上直接中止；改用 22.04 builder 後 glibc 底線降到 2.35，與其餘廠商行對齊。
  • 量子棧是當日最大單筆合入：FlagQuantum PR #635 以 405 個檔案、+114463/−3983 的體量合入，新增 159 個公開名，覆蓋演算法（45→148）、量子糾錯（84→108）、遠端呼叫（20→32）、可觀測量（12→20）、編譯器（12→17），並新開 flagquantum.operators 包；能力登錄檔由 68 項增至 97 項，Stable Core 的 41 個匯出保持不變。同日 PR #637 確立 M0 至 M4 路線圖，把超導、中性原子、離子阱、光子與拓撲五類硬體納入同一 Core IR 與編譯器約束下。
  • 海光補齊 BLAS 主幹：FlagBLAS PR #151 合入 gfx936 的六種精度 GEMM（sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm，+7060/−127），其中 dgemm 走 fp64 MMAC 點積核心、依賴 FlagTree 的 fp64 MMAC 支援；疊加 PR #149 的 Hygon L1 支援，海光通道從運算元層延伸到基礎線性代數層。
  • 天數側是直推 master 的效能基線：FlagDNN 當日 4 筆提交全部直接落在 master（無 PR 流程），內容是 iluvatar 後端的等價效能基線（equivalent_baseline.cpp 等，+8157）與隨後的兩輪修正，同時清理了 ascend 後端的驗證目錄（−7047）。

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

1.1 組織節奏：16 倉推送、93 筆提交、88 筆合入（10-19）

日期：2026-10-19　來源：flagos-ai 組織倉庫 · 提交檢索 · 合併 PR 檢索

  • 倉庫面：61 倉中 16 倉視窗內有推送，按提交量依次為 FlagGems 23、FlagQuantum 23、build-infra 16、FlagBLAS 9、FlagTree 5、FlagDNN 4、FlagGems-vllm 3、vllm-plugin-FL 3、Torch-FL 2、FlagSparse 2、FlagCX 1、FlagTrain 1、FlagAttention 1。
  • 合入面：88 筆合入，分佈為 FlagGems 36、build-infra 16、FlagQuantum 9、FlagTree 8、vllm-plugin-FL 6、FlagBLAS 3、FlagGems-vllm 3、Torch-FL 2，FlagCX / FlagTrain / FlagAttention / FlagSparse / TransformerEngine-FL 各 1。FlagGems 與 build-infra 合計佔提交量的 42%、佔合入量的 59%。
  • 在審面：視窗內有更新的 open PR 180 筆（介面返回前 100 條用於分倉統計），頭部為 FlagGems 63、FlagGems-vllm 12、vllm-plugin-FL 5、Torch-FL 4、FlagCX 3、FlagTree 3、FlagGems-sglang 3。其中標題含 KernelGen 的 28 筆、含崑崙芯的 30 筆、含 sparse 的 8 筆，三條佇列構成了當前的待消化主體。
  • 分支級兜底：docs 的推送落在 update/modelscope-docs-20261019-175239 分支（main 最新仍是 10-03）；Trident 的推送對應 PR #4「Monad 中間層」（master 最新 10-13）；FlagCV 自 10-19 凌晨的骨架合入後當日無新動作；FlagFFT、FlagScale、Megatron-LM-FL、FlagPrism、FlagAudio、FlagOps 七個倉庫視窗內零推送。
  • 判斷：大會兩日（10-17 至 10-18）過後，組織沒有出現「釋出後停擺」，而是把產能立刻轉回製品與基線。當日沒有新版本釋出（視窗內無 Release），也沒有新倉庫建立，屬「無版本、重交付」的一天。

1.2 build-infra：昇騰四輪子遷入 22.04 自包含 builder，清微與曦望同日補齊（10-19）

日期：2026-10-19　來源：PR #1414 · PR #1418 · PR #1422 · PR #1417 · base 目錄

  • 核心問題：昇騰的四個輪子原本在 24.04 執行時映象裡構建，產出的 libflagcx.so 與 _C*.so 鏈到 GLIBC_2.38，在 bundle 的 22.04 物理機上直接 abort。PR #1414 為每一行配置獨立的 ubuntu:22.04 builder，與其它廠商行走同一通道，glibc 底線降到 2.35。
  • 一個配方服務四行：ascend.mk 只鏈 -ltorch_npu -lascendcl -lhccl，與具體晶片無關；但工具鏈本身不帶這些連結期依賴，libhccl.so 與 <hccl/hccl.h> 來自晶片 ops 包，因此配方同時安裝 toolkit 與 ops 包（不含 nnal/ATB），910b 與 910c 的差異透過 ops 安裝器的晶片令牌（builder.ops_product，910b 與 A3）傳入。
  • 驗證口徑：SDK 底線用 import torch_npu（會 dlopen CANN 工具鏈庫）證明，而不是 import torch（該行上是純 CPU）；ASCEND_OPP_PATH、ASCEND_AICPU_PATH、TOOLCHAIN_HOME、LD_LIBRARY_PATH 從 set_env.sh 落到 /etc/profile.d/vendor.sh，與輪子構建時 sourced 的是同一份檔案。
  • 同日補齊兩個新後端：曦望（PR #1418，sunrise wheel 的 22.04 自包含 builder，隨後 PR #1420 記錄該輪子以 22.04-clean 重發）與清微（PR #1422，tsingmicro wheel 的 22.04 自包含 builder）。至此 base/ 目錄下的廠商矩陣為 nvidia（cuda12.8 / cuda13.3）、ascend（cann8.5.0 / cann9.0.0，含 910c）、cambricon（neuware4.4.3 / 4.7.2）、enflame（tops1.9.10 / 1.10.6）、hygon（dtk26.04）、iluvatar（corex4.4.0 / 4.5.0）、metax（maca3.7.2.1 / 3.8.1.3）、sunrise（tangrt1.2.0）、tsingmicro（tsm260610），共 9 家廠商。
  • FlagTree 側三筆：PR #1417 加燧原 builder 並把驗證步驟改成資料驅動；PR #1419 修掉「構建期斷言燧原後端」的寫法；PR #1421 把燧原 toolkit 的 deb 預置進 builder 映象，減少每次構建的下載依賴。另有 PR #1410 把 pybind11 ABI 從實際發出的外掛裡讀回、而不是寫死字面量，PR #1413 讓失敗的 plan 直接讓整個 run 失敗而不是跳過構建。
  • 判斷：這 16 筆沒有一筆是功能開發，全部在消除「本機能編、目標機能跑」之間的縫隙。與 10-16 至 10-18 的六後端 22.04 收口連起來看，FlagCX 的製品通道已從「逐個後端打補丁」過渡到「一行一個後端、同一套 22.04 配方」。

1.3 FlagQuantum：405 檔案合入量子棧擴容，M0 路線圖確立（10-19）

日期：2026-10-19　來源：PR #635 · PR #637 · PR #642 · 倉庫

  • 規模：23 筆提交、9 筆合入，是當日提交量並列第一的倉庫。PR #635 單筆 405 個檔案、+114463/−3983，新增 159 個公開名：演算法包由 45 增至 148、量子糾錯由 84 增至 108、遠端呼叫由 20 增至 32、可觀測量由 12 增至 20、編譯器由 12 增至 17、模擬由 8 增至 11，並新開 flagquantum.operators 包（4 個匯出）。能力登錄檔由 68 項增至 97 項，其中 development_evidence 由 20 增至 47。
  • 邊界紀律：所有新名都是子包入口，Stable Core 的 flagquantum.__all__ 仍為 41 個匯出、與 main 位元組一致；PR 正文明確「提升到 Stable Core 走獨立提案路徑」，同時新增三份契約檔案（編譯器 pass 准入、多級 IR 內部介面、real-time 訊息）。
  • 路線圖：PR #637 確立 M0 至 M4 的分階段範圍、依賴與驗收標準，要求複用現有 Core IR、編譯器、動力學求解器、執行時與 PyTorch 整合，覆蓋超導、中性原子、離子阱、光子與拓撲五類硬體；M1 從混合維狀態空間起步。同一 PR 還修正了收縮高斯重疊積分的精度問題（改用 math.fsum 處理相消敏感求和，並補一條原始基序迴歸）。
  • 動力學與編譯器：PR #639 支援混合維狀態空間，PR #640 支援顯式截斷的玻色運算元，PR #641 支援靜態運算元和的係數訓練，PR #642 允許呼叫方按名字在兩個最佳化點注入自有 pass。另有 10 餘筆測試與文件提交把數值斷言改成「按精度重複性比較」，而非按固定字面量比較。
  • 判斷：量子棧正在從「框架雛形」走向「通用量子計算框架」——PR #635 補的是覆蓋面（糾錯、化學、實時呼叫、超運算元），PR #637 補的是邊界與階段。兩者同日合入，意味著 M0 的起點是把已有能力寫清楚，而不是先擴 API。

1.4 FlagGems：KernelGen 稀疏族批次在審，崑崙芯 XPU3 注意力族與昇騰 mm 分派並進（10-19 ~ 10-20）

日期：2026-10-19 ~ 2026-10-20　來源：PR #7260 · PR #7239 · PR #7203 · 在審 PR 列表

  • 合入側：23 筆提交、36 筆合入。KernelGen 線繼續按 ATen 清單補齊並進入稀疏與檢視語義：_adaptive_avg_pool3d（#7172）、fft_ifftshift（#7171）、ccol_indices_copy（#6775）、_coalesce（#7096）、_neg_view_copy（#7088）合入；同時 PR #7260 一次性遷移 185 個 Q4 運算元測試套件。
  • 在審側：10-19 23:00 至 10-20 05:00 之間新增約 20 筆 KernelGen 提交，集中在稀疏族——_sparse_mm（#7289）、_sparse_mm_reduce_impl（#7298）、_sparse_mm_reduce_impl_backward（#7303）、_sparse_addmm（#7277）、copy_sparse_to_sparse_（#7231）、resize_as_sparse_（#7255）、_convert_indices_from_coo_to_csr（#7297）、_convert_indices_from_csr_to_coo（#7296）、_indices（#7293）、ccol_indices（#7295）等。稀疏族一次鋪開，說明主幹稠密運算元已接近清倉。
  • 崑崙芯：合入側有 XPU3 的 conv1d/conv2d/conv_depthwise2d（#7109）、chunk_gated_delta_rule_fwd（#7104）、dropout 與 mhc_post 效能（#7113）、take_along_dim 與 te_rmsnorm_bwd（#7089）、softmax_out 的 tle.gpu 融合路徑（#6897）、baddbmm/copy_ 失敗與 tile_size 32768 掛死修復（#7245）；在審側有 30 筆，含注意力族（#7275，前向分塊、varlen KV 融合、反向參考）、lstm（#7105）、rnn_relu（#7110）、cholesky_solve（#7103）、linalg_lu_factor（#7273）。
  • 昇騰與海光：昇騰 mm 形狀分派與 Triton tiling 最佳化（#7239）、reference 契約與精度跳過修正（#7286、#7287、#7253）、int_repr 參考適配（#7253）；海光 hygon_mv 超時修復（#6584）。三條線都是「先讓測試站住、再談效能」的順序。
  • 其他後端：達摩院玄鐵後端的 GRU barrier 死鎖修復（#7203）與 sparse QSA 的 16 行最小 tile（#940，FlagGems-vllm）；摩爾執行緒 KMCompiler 線的 linear 權重以 trans_b 送入 WS SQMMA（#7261）、rnn_tanh 啟用 musa（#7256）；PPU 容器資源上限在三倉同步恢復（#7254、#942、#101）。
  • 基準側：--base-data 支援外部 NVIDIA 基線對比（#7219），修掉 metadata-only 運算元的計時錯誤（#7283）、巢狀張量與描述符的報表問題（#7276），並清理過時的 reference 裝飾器（#7271）。當日 36 筆合入里約四分之一是測量與報表修正，這與「跨芯效能 +27.6%」這類對外口徑需要的可復現性直接相關。

1.5 FlagBLAS：海光 gfx936 六精度 GEMM 合入（10-19）

日期：2026-10-19　來源：PR #151 · PR #149 · 倉庫

  • 主體：PR #151 合入海光 gfx936 的廠商專用 GEMM 核心，覆蓋 sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm 六種精度（+7060/−127，23 個檔案）。hgemm/cgemm/zgemm 走獨立 Triton 核心與按形狀分檔的配置，配 ctypes 調 hipBLAS 的參考實現與不依賴 cupy 的測試；dgemm 走 fp64 MMAC 點積核心；bfgemm 帶調優池、TN 三路策略與 padding 路徑。
  • 依賴關係：dgemm 明確依賴 FlagTree 的 fp64 MMAC 支援——BLAS 的精度補齊把編譯器側的能力缺口暴露了出來，這是跨倉協同的一處實證。
  • 配套：同日 PR #149 合入 Hygon L1 支援並補齊 L1 基準形狀，另有 sgemm 單筆（#91）與註釋英文化、移除 ABS 運算元等整理提交；倉庫視窗內 9 筆提交、3 筆合入，是當日提交量第四的倉庫。
  • 判斷：FlagBLAS 此前只有 v0.3.0（09-28）一輪發布，日常提交不多；單日九筆、六精度齊上，是海光通道在 FlagOS 2.2 之後第一次成體系的投入。

1.6 FlagTree：燧原 GCU300 基線與 AMD RDNA 降級路徑、昇騰 3.5 py312 交付（10-19）

日期：2026-10-19　來源：PR #1363 · PR #1397 · PR #1396 · 倉庫

  • CI 與基線：燧原 enflame3.6-gcu300 的 FlagGems 基線與測試工作流（#1397）、燧原 vLLM 基準進工作流（#1334）、AMD amd3.6 的 FlagGems 基線與測試工作流（#1399）；昇騰 3.5 py312 交付工作流（#1396）與隨後的修復（#1398）；triton_v3.5.x 分支的 codeowner 更新（#1406）。
  • 編譯能力：FlagMega 側把 TLE 的 pipe、warp_specialize、distributed_barrier 降到 AMD RDNA（#1363），併為便攜解碼路徑補 nvidia-sm89（Ada）目標（#1362）。前者是方言下沉到消費級 AMD 顯示卡，後者是把原本綁在 Hopper 上的解碼路徑前移到 Ada。
  • 判斷：FlagTree 的當日工作幾乎全在「後端 × 版本 × 工作流」三維矩陣上鋪格子，5 筆提交、8 筆合入沒有一筆改核心 IR。這與 1.2 的 builder 收口是同一件事的兩面：製品與 CI 先行，語言層等矩陣穩定後再動。

1.7 推理與訓練棧：曦望與燧原圖模式、HY4 H100 接入、昇騰 vLLM 0.28 升級（10-19）

日期：2026-10-19　來源：PR #569 · PR #578 · PR #453 · 倉庫

  • 圖模式兩條：曦望 Sunrise 的圖模式（#569）與燧原 GCU300 的圖模式（#578，inductor + cudagraph）同日合入，意味著 vLLM 側的 CUDA Graph 通路開始在兩個國產後端上落地，而非只在昇騰/崑崙芯上驗證。
  • 晶片接入：HY4 H100 的 FlagOS 支援（#453）合入；分支管理上把 0.4.0-dev 前向同步到 0.5.0-dev（#612），並由 CI 自動建立這類同步 PR（#609）。
  • 版本線：達摩院玄鐵後端升級到 vLLM 0.28.0（#574）；在審側有「把 opt-in 的 FlagGems-vllm 運算元移植到 vLLM 0.28」（#613）、昇騰全解碼圖與 Qwen3.6（#606）、MetaX C550 上 Hy4-preview 的圖模式調研（#614）。
  • 訓練側：TransformerEngine-FL 合入 CICD 平臺矩陣過濾、ci-complete 門禁、受限重試與 /ci 命令（#137）；Torch-FL 合入 CI 行覆蓋率上報與 MetaX 上報修正（#587），並在審「統一 FlagCICD 入口，支援 L0 至 L2」（#599）。
  • 判斷：推理棧這一天的關鍵詞是「圖模式鋪開 + 版本線跟進」。圖模式是效能兌現的前置條件，vLLM 0.28 是版本債的償還，兩者都在為下一輪對外效能數字做準備。

1.8 FlagDNN / FlagTrain / FlagSparse / Torch-FL：天數等價效能、摩爾執行緒後端、MUSA 最佳化（10-19）

日期：2026-10-19　來源：FlagDNN 提交 · FlagTrain PR #20 · FlagSparse PR #113 · Torch-FL PR #593

  • FlagDNN：4 筆提交全部直推 master——先加 iluvatar 的等價效能基線（equivalent_baseline.cpp、equivalent_runner.hpp 等，+8157），隨後兩輪修正（含 hygon 基準契約與 pre-commit 調整），並清理 ascend 驗證目錄（−7047）。該倉當日無 PR 流程，屬維護者直接推送。
  • FlagTrain：合入摩爾執行緒後端與兩個運算元的支援（#20）。該倉 10-15 才有首版文件，10-14 起連續補 packbits、unpackbits、evoformer_attn，是當前最年輕的運算元倉。
  • FlagSparse：合入 MUSA 最佳化（#113，來自 NCIC-AlphaSparse 分支），視窗內 2 筆提交、1 筆合入。稀疏庫的廠商投入目前集中在摩爾執行緒一條線上。
  • Torch-FL：合入「給 iluvatar 獨立執行時，使輪子連結 CPU 版 torch」（#593）與 CI 覆蓋率上報（#587）；在審有 Iluvatar BI-V150 構建測試行（#569）、統一 FlagCICD 入口（#599）、取消被取代的 PR 與分支執行（#588）。
  • 判斷：四個倉的共同點是「為某一家的後端補上可測量的基線」——天數要等價效能、摩爾執行緒要後端入口、稀疏庫要 MUSA 路徑、Torch-FL 要能裝到沒有 GPU 驅動的機器上。這類工作不出現在對外口徑裡，但決定了下一版效能表能不能覆蓋到這些晶片。

二、新聞報道與生態

2.1 會後首篇深度技術稿：中華網刊出 FlagOS 2.2 全棧拆解（10-19）

日期：2026-10-19　來源：中華網技術稿 · 網易轉載

  • 性質：這是大會（10-17 至 10-18）之後第一篇帶完整技術細節的媒體稿，10-19 17:56 釋出，非演講速記，按「運算元與編譯、輔助研發、外掛與量化、Token 服務、端側與平臺」五段組織，含 8 張架構圖與 3 張效能表。
  • 新增的量化事實（上一期日報未覆蓋）：KernelGen 已支援九款 AI 晶片，本季度新增生成 765 個運算元，其中 416 個在至少 5 款國產晶片上透過精度驗證並達到原生運算元 80% 以上效能；FlagGems-SGLang 的 40 個運算元在 NVIDIA 上全部透過；針對 Qwen3.8-Flash-Next 新增 8 個融合運算元並完成 CUDA Graph 完整入圖。
  • 量化工具的真實案例：FlagOS-Compressor 在 Qwen3.5-397B-A17B 上採用 W8A8 後模型檔案由 751.41GB 降至 382.45GB（減少 49.1%），GPQA-Diamond 絕對準確率 84.85%，完成 NVIDIA H20 與國產 PPU 兩條推理鏈驗證；Qwen3.8-2.4T-A95B 上給出 BF16、FP8 到 INT8 的處理路徑。
  • Token 服務的分場景數字：DeepSeek V4.1 Flash 在 H100（1P1D、W4A16/FP8）上 32 路與 64 路併發的每請求解碼速度分別提升 19.7% 與 18.0%；達摩院玄鐵 810E（每節點 16 張 96GB、W8A8）24 路與 48 路併發分別提升 83.1% 與 91.5%。GLM-5.3-Flash 的邏輯服務吞吐由 8.52k 提升至 17.36k tokens/s（2.04 倍）；512K 長上下文的生成速度 60.9 tokens/s，為官方 API 外部測量參考值 61.1 的 99.7%；按 8 卡 910B 月租 16,500 元測算，256K 輸入/8 併發的每百萬輸出 Token 租金折算成本 59.27 元、較商業 API 計費參考低 19.4%，512K 輸入/4 併發為 104.53 元、低 27.6%。
  • 生態與平臺側：生態成員單位 107 家，第三季度社群下載 464,336 次、為第二季度的 4.76 倍，新增夥伴含凌川科技、中國電子、潤開鴻、中國電信、NXP、壁仞科技、跨維智慧、聆思科技；中國電信星辰大模型在訓練側把 FlagGems 接入 MindSpore + CANN + 昇騰 NPU 體系，mHC、TopK 等訓練運算元完成端到端驗證，MindFormers 整合工作已開源合入，推理側 Xing4.0-29B-A4B 完成十款晶片平臺適配（其中蘋果 M5 Pro 與此芯 P1 走 W4A8 端側量化），12 個推理運算元開源至 FlagGems 與 vLLM 主倉；軟通動力天元智算混合雲在四臺昇騰 910C 上最佳化 GLM-5.2，五項改動全部啟用後 p50 ITL 降低 14.53%、服務端 p99 ITL 由 83.82ms 降至 66.35ms（−20.84%）。
  • 判斷：這篇稿的意義不在數字多少，而在於它把 2.2 的收益拆成「可複核的單個案例」——每個數字都帶模型名、晶片型號、併發數與對照基準。此前兩期日報的 2.2 口徑以主論壇的四組彙總指標為主，這一篇補上了分組證據。

2.2 報道擴散與渠道核查：儲存線上演講全文為 10-18 舊稿晚索引，CSDN 與智源社群無新增（10-19 ~ 10-20）

日期：2026-10-19 ~ 2026-10-20　來源：儲存線上稿 · CSDN DAMO 開發者矩陣 · 智源社群

  • 晚索引識別：Google News 於 10-19 17:09 收錄儲存線上的《林詠華：眾智FlagOS 2.2釋出，token經濟正走向物理AI》，但原頁標註日期為 2026-10-18，內容為主論壇演講全文整理，與上一期日報引用的 DOIT 現場報道同源。按收錄規則不重複計為新增條目，僅登記為擴散。
  • 元件名直查仍為零：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen 七組元件名在 24 小時視窗內依舊零命中，這是連續多個視窗的同一結論；命中集中在「智源研究院 開源 / 晶片」「國產算力 開源軟體棧」等寬泛詞上，14 條候選裡 12 條為資本與行情稿（新股發行統計、工博會獲獎、融資快訊、辦公 Agent 報告），按標題語義剔除。
  • 渠道核查：CSDN 的 FlagOS 專欄與 DAMO 開發者矩陣視窗內未見新文（最新為 10-12 的全日程預告，10-17 至 10-18 的分論壇直播頁仍標註「回放中」）；智源社群首頁與站內檢索無 FlagOS 相關條目；HN Algolia 八組查詢無直接命中，返回結果均為同名詞誤匹配。大會分論壇的逐場紀要截至視窗截止仍未公開。
  • 判斷：新聞側進入「會後消化期」——主論壇內容由媒體二次加工，分論壇與工作坊內容尚未成稿。對日報而言，本期新聞面有效條目為 1 條（2.1），主體資訊量仍在 GitHub 側。

三、成員單位深挖

3.1 海光：FlagBLAS 六精度 GEMM 與 L1 支援同時落庫（10-19）

日期：2026-10-19　來源：FlagBLAS PR #151 · PR #149 · FlagGems PR #6584

  • 動作：PR #151 合入 gfx936 的 sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm 六精度核心，PR #149 合入 L1 支援，兩筆同日進入 master；FlagGems 側修掉 hygon_mv 的超時問題（#6584）。
  • 技術取向：BF16 走調優池 + TN 三路策略 + padding 路徑並附效能報告，FP64 走 MMAC 點積核心，半精度與複數走獨立 Triton 核心 + 按形狀分檔配置，參考實現改用 ctypes 調 hipBLAS 而不是 cupy——說明測試環境刻意不依賴 CUDA 生態。
  • 缺口：dgemm 依賴 FlagTree 的 fp64 MMAC 支援，編譯器側能力是否已進主線，需要看後續 FlagTree 的 MMAC 提交；當前只能確認依賴關係已在 PR 中寫明。
  • 判斷：海光此前的 FlagOS 投入以構建通道與裝置介面（/dev/itrctl）為主，進入 BLAS 主幹意味著它開始在「效能可被基準直接度量」的層面上加碼。

3.2 天數智芯：FlagDNN 等價效能基線直推 master，Torch-FL 拆出獨立執行時（10-19）

日期：2026-10-19　來源：FlagDNN 提交 · Torch-FL PR #593 · build-infra PR #1409

  • FlagDNN：四筆直推 master 的提交全部圍繞 iluvatar——新增等價效能基線（+8157）、兩輪修正、以及 backends/iluvatar/dispatch/pointwise.py 與 kernels/activation_backward.py、kernels/binary.py 的實現調整。同一批提交裡還包含 hygon 基準契約的修正與 ascend 驗證目錄的清理（−7047）。
  • Torch-FL：PR #593 給 iluvatar 獨立執行時，使輪子連結 CPU 版 torch——即在天數機器上無需 CUDA 執行時也能裝；配套在審 Iluvatar BI-V150 的構建與測試行（#569）。
  • 構建側：build-infra 的 PR #1409 把 iluvatar 的 pin 日期重新整理到 22.04 重發版本，PR #1420 同批記錄 sunrise 輪子以 22.04-clean 重發。
  • 判斷：天數這一天的三處動作指向同一目標——把「能在天數卡上跑」變成「能在天數的標準環境裡被自動構建、自動測、自動出等價效能」。等價效能基線是該目標最後一塊。

3.3 清微與曦望：兩個後端同日進入 FlagCX 22.04 builder（10-19）

日期：2026-10-19　來源：build-infra PR #1422 · PR #1418 · PR #1420

  • 清微（tsingmicro）：PR #1422 為 tsm260610 輪子加 22.04 自包含 builder；FlagGems 側同日出現 bump-flagtree-tsm 分支（10-19 15:31 建立），指向 FlagTree 的清微版本升級。base 映象 tsingmicro-tsm260610 已在矩陣內。
  • 曦望（sunrise）：PR #1418 為 tangrt1.2.0 輪子加 22.04 自包含 builder 並建立 flagcx-builder-sunrise 分支（10-19 17:57），PR #1420 隨後記錄該輪子以 22.04-clean 重發。
  • 意義：兩家都不在 FlagOS 2.2 的 21 家晶片廠商口徑的前排敘事裡，但製品通道已經按同一規格接入——這通常意味著適配工作已過「能不能跑」，進入「能不能穩定交付」。
  • 未證實項：視窗內未見這兩家的獨立 Release 或對外新聞，本條僅有 GitHub 側證據。

3.4 燧原：GCU300 基線、vLLM 基準工作流與 builder 斷言修正（10-19）

日期：2026-10-19　來源：FlagTree PR #1397 · PR #1334 · build-infra PR #1417 · vllm-plugin-FL PR #578

  • CI 三筆：FlagTree 加 enflame3.6-gcu300 的 FlagGems 基線與測試工作流（#1397）、把燧原 vLLM 基準加進工作流（#1334）；build-infra 加燧原 builder 並把驗證步驟改成資料驅動（#1417），同時修掉「構建期斷言燧原後端」（#1419）、把 toolkit deb 預置進映象（#1421）。
  • 執行時一筆：vllm-plugin-FL 的 GCU300 圖模式（#578）合入，啟用 inductor + cudagraph。
  • 判斷：燧原當日的六筆動作覆蓋「基線、基準、打包、斷言、圖模式」五個環節，是單家成員單位裡鏈條最完整的一組。GCU300 的圖模式落地，也解釋了為什麼 build-infra 要在同日修掉構建期斷言——圖模式的編譯路徑對後端宣告更敏感。

3.5 摩爾執行緒、昇騰、達摩院玄鐵：MUSA 運算元線、CANN 9.0 基線、T-Head GRU 死鎖修復（10-19）

日期：2026-10-19　來源：FlagGems PR #7261 · PR #7203 · FlagTrain PR #20 · FlagSparse PR #113 · build-infra base

  • 摩爾執行緒：FlagGems 的 KMCompiler 線把 linear 權重以 trans_b 送入 WS SQMMA（#7261），rnn_tanh 測試啟用 musa（#7256）；FlagTrain 加 mthreads 後端與兩個運算元（#20）；FlagSparse 合入 MUSA 最佳化（#113）。三條線構成 MUSA 的當日全部動作。
  • 昇騰：build-infra 的 base/ 下同時存在 ascend-cann8.5.0 與 ascend-cann9.0.0（各含 910c 變體），四個輪子的 builder 統一到 22.04（#1414）；FlagGems 側 mm 形狀分派與 Triton tiling 最佳化（#7239）、reference 契約修正（#7286、#7287、#7253）；FlagTree 的 3.5 py312 交付工作流（#1396、#1398）；vllm-plugin-FL 的昇騰全解碼圖仍在審（#606）。
  • 達摩院玄鐵：FlagGems 修掉 T-Head 後端的 GRU barrier 死鎖（#7203），FlagGems-vllm 把 sparse QSA 的最小 tile 提到 16 行（#940），vllm-plugin-FL 把玄鐵後端升到 vLLM 0.28.0（#574）。三條線分別對應正確性、效能下限與版本跟進。
  • 判斷：三家當日的共同點是「修邊界」而不是「加新能力」——MUSA 在補後端入口，昇騰在補交付與測試契約，玄鐵在補併發正確性。這類修復不會出現在對外效能口徑裡，但決定了多芯基線能不能橫向比較。

四、總結與趨勢觀察

  • 趨勢一：製品通道的統一先於功能擴張。build-infra 單日 16 筆提交、16 筆合入，全部圍繞 22.04 自包含 builder；昇騰四輪子、曦望、清微在同一天被拉進同一套配方，base/ 目錄形成 9 家廠商 17 個基線映象的矩陣。glibc 底線由 2.38 降到 2.35 這件事，比任何一個新運算元都更直接地決定「輪子能不能裝到使用者的機器上」。這一線索與 10-16 至 10-18 的六後端收口連成完整鏈條，可視為 FlagOS 2.2 釋出後的第一個系統性補課。
  • 趨勢二：量子棧從框架雛形轉入通用框架的邊界定義。FlagQuantum 單日 405 檔案、159 個新公開名合入，同時以 M0 至 M4 路線圖明確五類硬體的複用前提，並保持 Stable Core 的 41 個匯出不變。這種「擴子包、鎖核心」的做法，與 10-18 量智雲釋出時把 FlagQuantum 作為技術底稿的定位一致——對外講能力之前，先把哪些是穩定介面寫清楚。
  • 趨勢三：國產算力側的投入正在從「運算元」走向「基準與基礎庫」。海光在 FlagBLAS 補齊六精度 GEMM 與 L1 支援；天數在 FlagDNN 補等價效能基線並直推 master；燧原在 FlagTree 鋪 GCU300 基線與 vLLM 基準工作流；摩爾執行緒同時動 FlagGems、FlagTrain、FlagSparse 三條線。共同點是都可被基準直接度量，而非僅「支援某運算元」。
  • 趨勢四：KernelGen 進入稀疏與檢視語義的掃尾段。合入側的 _coalesce、ccol_indices_copy、_neg_view_copy 與在審側十餘筆稀疏運算元（_sparse_mm 族、coo/csr 索引互轉、copy_sparse_to_sparse_）說明稠密主幹已基本清倉；同時崑崙芯以 30 筆在審構成單一後端最大佇列，XPU3 的注意力族與 RNN 族是下一批要合入的主體。
  • 趨勢五：新聞面進入會後消化期，資訊重心回到倉庫。24 小時視窗內有效新聞 1 條（中華網 10-19 的技術拆解，補七個量化案例），元件名直查連續零命中，分論壇紀要與工作坊內容尚未成稿。按經驗，這類視窗後的一到兩天通常會出現分論壇的二次報道，可作為下一期的觀察點。
  • 下一期關注：一是 FlagQuantum 的 feat/m0-common-foundation 分支（10-19 16:47 建立）何時落 PR；二是 FlagGems 那批稀疏核心在審佇列的合入節奏；三是 build-infra 是否把「一行一個後端」的配方複製到 FlagTree 與 Torch-FL 的製品線；四是大會分論壇紀要是否公開。

完整信源清單

6 昇騰 3.5 py312 交付 — https://github.com/flagos-ai/FlagTree/pull/1396

信源核查表

信源 核查結果
GitHub org flagos-ai 61 倉全量核查，16 倉視窗內推送，93 筆提交、88 筆合入
GitHub Release / 標籤 16 個活躍倉逐一核查，視窗內無新 Release
GitHub 在審 PR 180 筆視窗內更新，前 100 條分倉統計（FlagGems 63、FlagGems-vllm 12 居前）
Google News RSS 24 組中英文查詢，視窗內 14 條候選，有效 0 條（元件名直查零命中，寬泛詞命中的 12 條為資本與行情稿，2 條為舊稿晚索引）
HN Algolia 8 組查詢無直接命中，返回為同名詞誤匹配
中華網 / 網易 1 條有效（10-19 17:56 技術拆解），補七個量化案例
儲存線上 1 條晚索引（頁面日期 10-18，演講全文），不重複計入
CSDN FlagOS 專欄 / DAMO 無視窗內新文，分論壇直播頁仍標註回放中
智源社群 首頁與站內檢索無 FlagOS 相關條目
大會官網議程頁 議程無變更，未見紀要或演講實錄公開