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

信源：GitHub（org: flagos-ai 61 倉庫全量核查、提交檢索 185 筆、合併 PR 133 筆與在審 PR 225 筆檢索、org 事件流 100 條、31 倉 Release/Tag 原子核查、2 倉 Atom 兜底、關鍵 PR 正文與檔案規模核查）、Google News RSS（24 組中英文查詢詞，走代理）、HN Algolia（8 組）、CSDN FlagOS 專欄、智源社群（詳見附錄信源清單）。

本期索引

  • 今日重點：2.3.0 執行時進入應用重建；玄鐵 BLAS1 整批落庫；FlagCV 首次公開定位（10-26）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：18 倉推送、185 筆提交、133 筆合入，在審積壓升至 225 筆（10-26 ~ 10-27）
    • 1.2 執行時 2.3.0：vllm 應用獲重建授權、統一標籤落定，新增 AMD ROCm 7.2.4 基礎映象（10-26）
    • 1.3 達摩院玄鐵：FlagBLAS 一次性補齊 15 組 BLAS1 運算元，一萬六千行落庫（10-26）
    • 1.4 FlagGems：49 筆合入，KernelGen 運算元批次與崑崙芯 XPU3 融合提速並行（10-26）
    • 1.5 FlagQuantum：109 筆提交、47 筆合入，Quafu SDK 切換收尾與固定 shots 契約（10-26）
    • 1.6 FlagCV：首個定位說明合入，Triton 視覺運算元庫對外成形（10-26）
    • 1.7 FlagTrain：KMCompiler 一支鋪到七家後端，五筆在審（10-26）
    • 1.8 其餘倉庫：FlagTree 打 MThreads 專用標籤，optest 合併十三支廠商檢查指令碼（10-26）
  • 二、新聞報道與生態
    • 2.1 清微智慧：Open3D-PIMC 從開源首發走到三十國師資課堂（10-26）
    • 2.2 沐曦：RLinf 全棧適配合入官方主線，千卡完成 SFT 到 RL 後訓練驗證（10-26）
    • 2.3 渠道核查：12 條候選 2 條有效，CSDN 專欄與 HN 均無新命中（10-27）
  • 三、成員單位與後端廠商深挖
    • 3.1 達摩院玄鐵：BLAS1 整批落庫，fp8 GEMM 的玄鐵分支仍在審（10-26）
    • 3.2 崑崙芯：XPU3 側三筆 foreach 融合、原地 GEMM 與位碼構建（10-26）
    • 3.3 沐曦：SGLang 外掛新增 MetaX 後端整包，vLLM 側三條模型適配在審（10-26）
    • 3.4 清微：TXDA 後端隨 vLLM 0.28.0 升級，FlagCX 打包納入清微（10-26）
    • 3.5 燧原、海光、天數、摩爾執行緒：四條後端各有一筆結構性改動（10-26）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表與完整信源清單

今日重點：2.3.0 執行時進入應用重建；玄鐵 BLAS1 整批落庫；FlagCV 首次公開定位（10-26）

日期：2026-10-26 ~ 2026-10-27　來源：build-infra PR #1488 · FlagBLAS PR #154 · FlagCV · FlagGems PR #7688（全量見附錄）

  • 版本面：build-infra 在 10-26 20:10 授權把二十個 vllm0.24.0 應用映象在 2.3.0 執行時上重建，隨後把標籤從「按後端加字尾」收斂成統一標籤 2.3.0-0.3.0。同日 23:05 新增 AMD ROCm 7.2.4 基礎映象，後端鍵為 amd-rocm7.2.4，在乾淨的 ubuntu:24.04 容器內演練透過，並用本地 gfx1100 映象驗證八張 W7900 的直通。2.3.0 從「執行時已重新整理」推進到「應用層開始跟版」，標籤本身仍未打出。
  • 運算元面：FlagBLAS 合入達摩院玄鐵的 L1 支援，一次性補齊 AMAX、AMIN、ASUM、AXPY、COPY、DOT、DOTC、DOTU、NRM2、ROT、ROTG、ROTM、ROTMG、SCAL、SWAP 十五組基礎線性代數運算元，改動 17 個檔案、新增 16,168 行。該 PR 在上一期日報中還處於在審狀態，本視窗完成合入，是玄鐵在後端矩陣裡從「能跑推理」走向「補齊數值庫」的一步。
  • 方向面：FlagCV 合入首份 About 說明，把倉庫定位寫成「以 Triton 實現的高效能運算機視覺庫」——對外提供 OpenCV 形狀的影象處理原語介面（色彩轉換、濾波、幾何變換、算術運算），以 OpenCV 的 CUDA 基線為對標，構建在 FlagTree 之上，後端可插拔。這是組織在視覺方向第一次把倉說清楚，此前 10-14 建倉、10-18 落骨架時只有佔位程式碼。
  • 生態面：沐曦宣佈面向具身智慧的強化學習框架 RLinf 全棧適配合入其官方主線，基於曦雲 C 系列 GPU 完成 512 卡與 1024 卡兩檔 SFT，以及多場景 RL 後訓練驗證，四組任務成功率對齊或超過論文報告值，其中一組高 8.8 個百分點，多機擴充套件線性度保持在 97% 以上。此事不屬 FlagOS 元件釋出，但與其「上游優先」路線同源。
  • 節奏面：24 小時視窗 18 倉推送、185 筆提交、133 筆合入、225 筆在審（新開 74 筆）。與上一個 24 小時視窗（10-22：16 倉、135 筆提交、163 筆合入、183 筆在審、90 筆新開）相比，提交增 37%、在審增 23%，合入與新開各降 18%——開發在積累，評審吞吐在回落。
  • 判斷：本期沒有新版本釋出，也沒有模型 Day-0 齊發，內容重心回到「填平後端」：玄鐵補數值庫、AMD 新增基礎映象、清微與沐曦補推理外掛後端、崑崙芯補位碼與融合運算元。這類工作不出標題，但決定 2.3 能不能按統一映象鋪到各家。2.3.0 的觀察點仍是標籤與全後端 changelog 是否同步補齊。

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

1.1 組織節奏：18 倉推送、185 筆提交、133 筆合入，在審積壓升至 225 筆（10-26 ~ 10-27）

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

  • 倉庫面：61 倉中 18 倉視窗內有推送，數量為近一週最多。按提交量依次為 FlagQuantum 109、FlagGems 28、FlagGems-sglang 14、FlagSparse 7、FlagGems-vllm 5、Torch-FL 5、build-infra 5、vllm-plugin-FL 2、FlagTrain 2、FlagCV 2，其餘 FlagBLAS、sglang-plugin-FL、optest、FlagCX、FlagPrism、FlagTree 各 1 筆。
  • 合入面：合併 PR 133 筆，分倉為 FlagGems 49、FlagQuantum 47、FlagGems-sglang 6、Torch-FL 5、build-infra 5、FlagGems-vllm 5、FlagTree 4、sglang-plugin-FL 2、vllm-plugin-FL 2、FlagTrain 2，FlagCV、FlagSparse、FlagBLAS、FlagCX、FlagPrism、optest 各 1 筆。
  • 在審面：視窗內有更新的 open PR 225 筆，其中新開 74 筆；新開分佈為 FlagGems 36、FlagTree 8、FlagQuantum 7、vllm-plugin-FL 5、FlagTrain 4，FlagGems-vllm、FlagAttention、FlagGems-sglang 各 3 筆。
  • 日均對比：視窗 24 小時，提交 185 筆（上一 24 小時視窗 135 筆，增 37%）、合入 133 筆（163 筆，降 18%）、在審 225 筆（183 筆，增 23%）、新開 74 筆（90 筆，降 18%）、推送倉庫 18 個（16 個）。
  • 版本面：31 倉 Release 與 Tag 原子核查，僅 FlagTree 新增一個標籤 0.7.1a1+mthreads3.6（10-26 10:13），releases 列表無對應 Release 條目，屬純 Tag 事件；其餘倉庫零新增。
  • 事件面：org 事件流 100 條，PR 事件 49、推送 20、建分支 10、刪分支 7、評審 3、評論 9、關注 1、Issue 1。
  • 判斷：提交增、合入減、在審增，三者同向說明佇列在積壓而非在清。積壓主要來自 FlagGems（49 筆合入，同時 52 筆在審）與 FlagTree（4 筆合入，9 筆在審）——這兩個倉庫都在為 2.3 的編譯器與運算元版本做準備，評審頻寬成為當前瓶頸。

1.2 執行時 2.3.0：vllm 應用獲重建授權、統一標籤落定，新增 AMD ROCm 7.2.4 基礎映象（10-26）

日期：2026-10-26　來源：build-infra PR #1488 · PR #1504 · PR #1502 · PR #1505

  • 重建授權（#1488）：為二十個 vllm0.24.0 應用 changelog 補上待發布條目（含原因、日期留空），滿足推送時 changelog 門禁後才允許重建應用映象。原因是執行時已於 10-25 重新整理到 2.3.0 棧，其上構建的應用映象全部過期。條目逐條說明應用映象現在攜帶什麼：執行時的兩個容器啟動引數、按後端釘住版本的 flagcx 0.14.0、以及 venv 字首。
  • 標籤收斂：同一 PR 的第二個提交把原生外掛標籤從映象標籤裡移出，改由一個統一的解析器決定，從而讓 2.3.0-0.3.0 這個不帶後端字尾的統一標籤成立；第三個提交在 changelog 與 schema 頭裡宣告 reason 欄位按 markdown 釋出，多條變更可按列表讀。
  • 新增後端（#1504）：AMD ROCm 7.2.4 基礎映象落地，後端鍵 amd-rocm7.2.4，底座為 Ubuntu 24.04 加 repo.radeon.com 直裝的 ROCm 7.2.4，不走檔案倉。只裝 28 個精幹包，apt 解析執行時依賴後合計 94 個；MIOpen、MIGraphX、rocm-gdb、rocprofiler-sdk、opencl 明確排除。演練中發現兩個必須寫進 Containerfile 的事實：amd 節點到不了 archive.ubuntu.com，必須在 ca-certificates 存在之前就切阿里雲 HTTP 映象（走 HTTPS 會握手失敗）；pin 檔案不是版本偏好而是必需項。
  • 清障兩筆：22:27 的 #1502 讓原生外掛門禁在同一直譯器內跑完，22:45 的 #1503 把 vllm 外掛標籤從 sglang 的文件頁裡移出，#1505 改成列印標籤實際攜帶的外掛 pin 而不是後端標籤。
  • 判斷：這一輪的動作全部落在「可釋出性」上——門禁、留痕、標籤形態、基礎映象。與 10-25 的執行時重建授權連起來看，2.3.0 的管道已經從頭到尾跑通一遍，只差正式打標籤與全後端映象批次重出。AMD 後端新增意味著後端矩陣在 2.3 週期還在擴張，而不是收斂。

1.3 達摩院玄鐵：FlagBLAS 一次性補齊 15 組 BLAS1 運算元，一萬六千行落庫（10-26）

日期：2026-10-26　來源：FlagBLAS PR #154 · FlagBLAS 提交

  • 規模：單筆 PR 改動 17 個檔案、新增 16,168 行、刪除 9 行，合入時間為 10-26 08:57，是當日非量子倉裡體量最大的一筆。
  • 覆蓋：一次補齊 BLAS 第一層十五組運算元——向量最值與求和（AMAX、AMIN、ASUM）、向量累加與複製（AXPY、COPY）、點積三類（DOT、DOTC、DOTU）、歐氏範數（NRM2）、平面旋轉四類（ROT、ROTG、ROTM、ROTMG）、向量縮放與交換（SCAL、SWAP）。
  • 層面：這是數值庫層面的補齊而非推理運算元補齊。BLAS1 是上層 BLAS2 與 BLAS3、以及 LAPACK 求解器的前置依賴，缺一層就無法自底向上自洽；對玄鐵而言，此前在 FlagOS 裡的存在感集中在推理路徑（真武 Express 版、稀疏注意力），數值庫是空檔。
  • 鏈路：該 PR 在上一期日報中仍記為在審，本視窗完成合入，從「在審」到「落庫」跨了一個視窗。
  • 判斷：一家後端在 FlagOS 裡的成熟度，通常按「能跑推理、能跑訓練、數值庫自洽」三段衡量。玄鐵本視窗跨到第三段的第一級臺階，後續看 BLAS2 與 BLAS3 是否跟進，以及 FP8 路徑（FlagTrain 側在審的 fp8 GEMM 有玄鐵分支）能否共用同一套數值庫。

1.4 FlagGems：49 筆合入，KernelGen 運算元批次與崑崙芯 XPU3 融合提速並行（10-26）

日期：2026-10-26　來源：FlagGems 提交 · PR #7676 · PR #7635 · PR #7669

  • 總量：28 筆提交、49 筆合入，提交量居全組織第二，合入量居第一。合入數高於提交檢索數，原因是合併提交與壓縮提交的口徑差異，以合入數為準。
  • KernelGen 批次：以 KernelGen 加 Nvidia 為字首的運算元合入 16 筆，集中在 10:41 至 10:43、18:17 至 18:20、23:05 至 23:06 三個時段：稀疏與結構化相關（_sparse_semi_structured_tile、_sparse_mm_reduce_impl、sparse_compressed_tensor）、量化相關（choose_qparams_per_tensor、make_per_tensor_quantized_tensor）、特殊函式（special_psi、special_scaled_modified_bessel_k0）、張量元資訊（_version、_nested_compute_contiguous_strides_offsets、ravel、new_zeros），另有 _foreach 運算元族的驗收提速一筆。
  • 崑崙芯提速：XPU3 側改動五筆——addmm_ 把 GEMM 直寫進原地目標（#7676）、less_equal 改用對 NaN 安全的比較（#7688）、isfinite 核心最佳化（#7631），以及 foreach 三筆（三元標量融合、div 走更快的 List 核心、log 融合去掩碼）。這一組是典型的後端調優，改動小、收益區域性。
  • 缺陷修復：QC 側修 FP8 TopK 的 TLE scatter 定址（#7669），崑崙芯側修 logical_and 與註冊錯誤（#7666、#7670）。
  • 測試側：同一貢獻者批次合入二十餘筆測試契約修復（候選入口點、原生參考注入、過載選擇、foreach 前置失敗），把大量「測試自己壞掉」的用例從失敗裡摘出來。
  • 判斷：運算元供給仍以 KernelGen 自動生成的批次為主，人工介入主要發生在後端調優與測試契約兩側。這種結構推匯出的質量風險不是「運算元寫錯」，而是「測試覆蓋看似齊全、實則參考實現缺失」——本視窗二十餘筆測試修復正是這個風險的顯性化。

1.5 FlagQuantum：109 筆提交、47 筆合入，Quafu SDK 切換收尾與固定 shots 契約（10-26）

日期：2026-10-26　來源：FlagQuantum 提交 · PR #874 · PR #919 · PR #924

  • 總量：109 筆提交、47 筆合入，提交佔全組織 58.9%、合入佔 35.3%，仍是第一活躍倉，但相對上一期（72 小時 505 筆）日均已回落至約三分之一。
  • Quafu 切換收尾：完成只讀 SDK 切換（#874）、把動態 mock 收斂到 Quafu SDK（#880）、提出動態格式啟用與來源審計（#881、#883），並在示例側把遠端執行的 mock 全部改道。這是上一期「生命週期整體切換」的收尾段。
  • Rydberg 路線：以受種子的 presence 計劃執行（#879）、演化選定的 Rydberg 分支（#875）、驗收記錄落文件（#882），從契約轉為可執行路徑。
  • 糾錯碼（QEC）：固定 shots 實驗的設計稿與契約稿先後合入（#912、#924），通道構造模板複用提速（#877），原生產階段交接與獨立失敗閉環留痕（#917），AI 解碼交付進度兩次對齊（#890、#895）。
  • API 與示例：iSWAP 門對加入（#919），Circuit 與 DynamicCircuit 的門鏈改為帶型別的流暢介面（#913），門覆蓋 Batch A 提案（#915），吸收式光子計數示例加驗收（#921），固定熱浴中的 spin-mode 模型擬合示例（#897），Twin 候選與人工門控演化週期（#923、#926）。
  • 判斷：量子棧的節奏從「結構重整」轉入「物理場景鋪開」——糾錯碼、中性原子、熱浴三類場景同期推進，每類都按「設計稿、契約稿、可執行示例、驗收記錄」四段留證。這種作業方式成本高、可核查性好，也解釋了它為什麼長期佔據大部分提交量。

1.6 FlagCV：首個定位說明合入，Triton 視覺運算元庫對外成形（10-26）

日期：2026-10-26　來源：FlagCV · FlagCV PR #2

  • 定位：FlagCV 自述為「以 Triton 實現的高效能運算機視覺庫」，在 OpenCV 形狀的介面下提供常用影象處理原語——色彩轉換、濾波、幾何變換、算術運算，並以 OpenCV 的 CUDA 基線為對標，目標是在多種 GPU 架構上達到參考級正確性與有競爭力的效能。
  • 依賴關係：構建在 FlagTree 之上（FlagOS 維護的 Triton 分支，支援多硬體後端），對外提供與廠商無關的運算元介面，後端可插拔。
  • 時間線：倉庫於 10-14 建立（當時僅有佔位），10-18 落骨架並撤掉運算元實現改為「即時模式骨架」，10-26 合入 About 與 README 說明。即程式碼骨架在前、定位說明在後，本視窗補的是「這個倉到底做什麼」。
  • 判斷：視覺是 FlagOS 體系裡原先最薄的一塊——既有 FlagDNN、FlagSparse、FlagFFT、FlagBLAS，但沒有影象處理原語層。FlagCV 把視覺接在 FlagTree 而非另起一套編譯器上，方向與「一次開發、多芯執行」一致；真正的檢驗點是色彩轉換與幾何變換這類訪存密集運算元在非 GPU 後端（NPU、DSA）上的表現，目前尚無效能資料。

1.7 FlagTrain：KMCompiler 一支鋪到七家後端，五筆在審（10-26）

日期：2026-10-26　來源：FlagTrain PR #29 · PR #30 · PR #35 · PR #18

  • 合入兩筆：#29 加入 fused_indices_to_multihot 的 Triton 實現，覆蓋英偉達與昇騰，H20 上有基準記錄；#30 把 FlagGems-vllm 的基線對照機制移植過來，按裝置瓶頸單位的峰值縮放係數歸一化速度比，輸出「vs Base」列，缺基線時記錄原因而不失敗，並新增 lamb 基線與逐運算元彙總工具。
  • 在審五筆：#34 tanh_soft_clamp（英偉達、昇騰、海光、玄鐵、沐曦、天數）、#35 multi_tensor_adam（英偉達、海光、沐曦、地平線 PPU、天數）、#18 fp8_gemm（英偉達、昇騰、玄鐵、沐曦）、#10 mixed_gemm（英偉達）、#28 fused_proj_rms_compute_h_fwd（英偉達）。
  • 結構特徵：單筆 PR 的標題裡直接列出後端清單，是 FlagTrain 這一支的固定寫法——一個運算元按後端矩陣一次鋪開，而不是按後端逐個提交。七家後端（英偉達、昇騰、海光、玄鐵、沐曦、天數、地平線）在同一批 PR 裡出現。
  • 判斷：FlagTrain 在 2.3 週期明顯加速，且集中在訓練側的最佳化器、MoE 與量化 GEMM 三類運算元。它與 FlagGems（推理運算元）形成分工，兩家都在用 KernelGen 生成 Triton 實現、再按後端補齊；差別是 FlagTrain 更依賴跨後端一致性，因此其 PR 的驗收門檻也更高，五筆同時在審並不意外。

1.8 其餘倉庫：FlagTree 打 MThreads 專用標籤，optest 合併十三支廠商檢查指令碼（10-26）

日期：2026-10-26　來源：FlagTree tags · FlagTree PR #1410 · optest PR #11 · FlagGems-sglang PR #227

  • FlagTree：10-26 10:13 打出標籤 0.7.1a1+mthreads3.6，指向 0.7.x 線的 MThreads 專用構建，releases 列表無對應 Release 條目，屬純 Tag 事件；後端側的實質改動來自 10-23 的 #1416（MTHREADS 後端跟到上游提交）。視窗內合入四筆：FlagMega 重新推斷 Qwen3 vLLM profile 的切片型別（#1373）、HCU 後端支援 set_layout（#1410）、ROCm 經 HIP 主機註冊介面載入 source-rdata（#1403）、池化 ABI 的 bank 行索引按 tl 值傳遞（#1404）。
  • optest：合入把十三支按廠商分開的 GPU 檢查指令碼統一成一條 flagos-gpu-check 命令（#11），按「廠商專有裝置節點優先、SMI 命令二次確認」的順序自動探測，並保留各廠商原有的逐卡表格、超時與重試引數；廠商衝突規則寫明「海光先於 AMD（兩者都有 kfd，只有海光有 mkfd）」「玄鐵先於英偉達」。
  • FlagGems-sglang：6 筆合入，含競賽賽道運算元兩筆（add3、create_chunked_prefix_cache_kv_indices）、一批 batch8 運算元、去掉崩潰的分組核心兩筆、匯入期讀裝置資訊的修復；#227 把目錄裡缺登記的 16 個運算元補進 operators.yaml。
  • FlagSparse、FlagPrism、FlagCX：FlagSparse 7 筆提交併合入來自外部組織的整批最佳化（#114）；FlagPrism 合入燧原側 tops 標頭檔案與庫依賴解析（#17，2,126 行）；FlagCX 合入崑崙芯 XPU 裝置位碼構建（#676）。
  • 判斷：這一組裡最值得記的是 optest 的合併——測試設施從「每家一段指令碼」變成「一條自動探測命令」，是多後端規模化之後必然會走到的一步。廠商順序裡的兩條衝突規則（海光對 AMD、玄鐵對英偉達）說明裝置探測這件事在異構環境裡已不能靠單一訊號判斷。

二、新聞報道與生態

2.1 清微智慧：Open3D-PIMC 從開源首發走到三十國師資課堂（10-26）

日期：2026-10-26　來源：金融界（搜狐轉載）：從技術大會到 30 國課堂 · 新華網：Open3D-PIMC 補齊國產算力軟體生態關鍵拼圖

  • 專案：Open3D-PIMC 由清微智慧與北京智源人工智慧研究院聯合開發，是面向 3D 算力晶片的程式設計模型與開源軟體框架，9 月在中國算力大會正式開源，被定位為眾智 FlagOS 面向下一代 3D 晶片的主要解決方案之一。
  • 技術路徑：開發者只描述資料分佈與任務劃分，框架自動完成圖編譯與即時執行的劃分和呼叫，進而把模型適配到硬體；生長在 PyTorch 等主流生態上，推理側原生對接 vLLM 與 SGLang；Flash Decoding、MoE 這類強動態運算元保留手寫最佳化入口；各廠商私有指令集與微架構能力以外掛形式接入。
  • 硬體背景：清微第二代高效能雲端 AI 晶片以 3D 存算一體與多芯粒合封把儲存與計算立體堆疊，資料搬運距離從毫米級壓到微米級，延遲從集中式架構的非確定、易衝突變為近存側的可預期、確定性。
  • 本期進展：10-26 的報道聚焦生態推廣而非程式碼——全球「AI 開放計算師資發展計劃」把清微工程師送進課堂，學員為來自三十多個國家的近五十位高校骨幹教師（非洲二十餘位、亞洲十有餘位，其餘來自歐洲與南美）。
  • 口徑說明：文中「FlagOS 已適配 20 家晶片廠商、30 餘款 AI 晶片」為報道方口徑，與 10 月開放計算大會上官方給出的 21 廠商、35 晶片不完全一致，引用時以前者歸屬報道、後者歸屬大會為宜。
  • 判斷：這條的價值不在「又一個開源釋出」，而在它展示了 FlagOS 生態的一條新路徑——先由一個成員單位牽頭做出面向新硬體形態（3D 堆疊）的程式設計模型，再掛進 FlagOS 作為解決方案。與「模型 Day-0 適配」相比，這是「硬體形態先行」的另一類擴張。

2.2 沐曦：RLinf 全棧適配合入官方主線，千卡完成 SFT 到 RL 後訓練驗證（10-26）

日期：2026-10-26　來源：同花順財經轉載沐曦股份官微 · 沐曦官網新聞中心

  • 事件：沐曦股份完成面向具身智慧的大規模強化學習框架 RLinf 的全棧適配，適配方案合入 RLinf 官方主線，開發者無需改程式碼即可在沐曦 GPU 上執行 RLinf 的訓練任務。
  • 框架背景：RLinf 由清華大學與無問芯穹聯合北京中關村學院等機構推出，定位為首個面向具身智慧的「仿訓推一體化」大規模強化學習框架，成果被 OSDI、RSS、NeurIPS 等會議收錄。
  • 驗證規模：基於曦雲 C 系列 GPU 叢集，完成 512 卡與 1024 卡（128 節點乘 8 卡）兩檔 SFT，Pi0.5 模型在 RoboTwin 資料集上訓練；四組任務成功率全部對齊或超過論文報告值，其中一組高 8.8 個百分點；多機擴充套件線性度保持在 97% 以上。
  • 接入方式：按外掛模式四層對齊——加速器抽象層新增裝置管理器並註冊進 RLinf 登錄檔、用環境變數控制多卡可見性並與 Ray 排程協同、通訊預設走沐曦集合通訊庫 MCCL、軟體棧基於 MXMACA 的 PyTorch 與 FlashAttention 支援 BF16 與 FSDP。
  • 路線說明：沐曦稱此為「上游優先」戰略的延續，此前已合入 LMCache 與 ms-swift 的官方主線。
  • 判斷：此事不屬 FlagOS 元件釋出，應記作成員單位的開源生態動作。值得注意的是方向——具身智慧的強化學習訓練棧，與 FlagOS 側的 FlagOS-Robo、FlagScale 訓練工具在場景上重疊，未來是否出現「成員單位先合入上游框架、再由 FlagOS 收口統一後端」的接力，是值得跟的線索。

2.3 渠道核查：12 條候選 2 條有效，CSDN 專欄與 HN 均無新命中（10-27）

日期：2026-10-27　來源：Google News RSS · CSDN FlagOS 專欄 · HN Algolia

  • 新聞側：24 組中英文查詢詞視窗內共 12 條候選，2 條有效（清微 Open3D-PIMC、沐曦 RLinf）。元件名查詢（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）全部零命中，與近兩週常態一致。
  • 剔除明細：燧原科技相關 4 條為融資融券、早報與上市回顧類稿件（該公司實際於 9 月 11 日已在科創板掛牌，10-26 的「今日上市」標題屬轉載稿，不予採用）；摩爾執行緒 1 條為股價與成交額；智源與北京日報社 GEOInflow 2 條屬媒體技術合作，與 FlagOS 無關；國產算力廠商全景覆盤 1 條為行業綜述。
  • HN 側：8 組查詢（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）4 天視窗內共 34 條命中，無標題直接匹配。
  • CSDN 側：專欄頁 51 條文章連結，最新資訊稿仍是 8 月下旬（GLM-5.3-Flash 九芯、Qwen3.8-Flash-Next 八芯、LightX2V 接入），視窗內唯一的新日期是 10-22 的高校圓桌直播頁，無新稿。
  • 智源社群：搜尋頁為客戶端渲染，僅得框架頁，本期未取用。
  • 判斷：新聞面連續第三個視窗只有成員單位通稿。FlagOS 自身對外發聲的節奏與程式碼節奏明顯不同步——程式碼在填後端，傳播在等下一個模型或版本節點。

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

3.1 達摩院玄鐵：BLAS1 整批落庫，fp8 GEMM 的玄鐵分支仍在審（10-26）

日期：2026-10-26　來源：FlagBLAS PR #154 · FlagTrain PR #18 · optest PR #11

  • FlagBLAS：十五組 BLAS1 運算元一次合入，17 檔案、16,168 行，是玄鐵在 FlagOS 數值庫層面的首次成建制提交。
  • FlagTrain：在審的 fp8_gemm 覆蓋英偉達、昇騰、玄鐵、沐曦四家，玄鐵是其中唯一的 RISC-V 向量路線；同批在審的 tanh_soft_clamp 也含玄鐵。
  • 測試設施：optest 的廠商衝突規則把玄鐵排在英偉達之前，理由是兩者裝置節點探測可能撞車；這條規則本身說明玄鐵已在 CI 的真實機器池裡。
  • 前情：10-23 至 10-25 視窗，玄鐵完成了真武 Express 版交付與 PPU 稀疏注意力在審；本視窗轉向數值庫。
  • 判斷：玄鐵在 FlagOS 裡的動作已連續三個視窗保持「一次一個整塊」的節奏——推理、注意力、數值庫。下一步看 BLAS2 與 BLAS3，以及 CPU 側（optest 的 thead 廠商鍵）是否與加速卡側共用同一套檢查指令碼。

3.2 崑崙芯：XPU3 側三筆 foreach 融合、原地 GEMM 與位碼構建（10-26）

日期：2026-10-26　來源：FlagGems PR #7676 · PR #7635 · FlagCX PR #676 · FlagCX PR #677

  • 運算元側：XPU3 上六筆改動，addmm_ 把 GEMM 直接寫進原地目標免掉一次中轉、less_equal 用對 NaN 安全的比較交換運算元、isfinite 核心最佳化、foreach 三筆融合（三元標量、div 的 List 核心、log 去掩碼）。
  • 通訊側：FlagCX 合入崑崙芯 XPU 的裝置位碼構建（#676）——用 Makefile 把共享的裝置 API 封裝編成 xpu3 的 LLVM 位碼，從 XTDK 解除安裝包裡抽出裝置模組、保留公共符號後最佳化，產出 libflagcx_device.bc 與消費側標頭檔案，通訊 traits 走 XSHMEM。在審的 #677 修 flagcxGetVersion 對小於一萬的版本碼解碼。
  • 修復面：FlagGems 修 logical_and 與註冊錯誤兩筆；在審四筆（cholesky_solve 的複數路徑與上三角修復兩筆、foreach_div 的 _result_dtype 本地化、批次運算元依賴 FlagTree 當日構建）。
  • 判斷：崑崙芯本期全部動作都在「把已有路徑做快做穩」，沒有新特性。這與它此前兩週的形態一致——接入最早、覆蓋最廣，因此進入長尾調優階段也最早。位碼構建是個例外，它把崑崙芯接進了 FlagCX 的統一裝置抽象，長期價值高於單運算元提速。

3.3 沐曦：SGLang 外掛新增 MetaX 後端整包，vLLM 側三條模型適配在審（10-26）

日期：2026-10-26　來源：sglang-plugin-FL PR #50 · vllm-plugin-FL PR #642 · FlagGems-vllm PR #998

  • SGLang 後端：合入 31 檔案、新增 3,364 行的 MetaX 與 MACA 後端包，含可用性探測、複用 CUDA 相容實現並加沐曦側包裝（silu_and_mul、rms_norm、rotary_embedding、topk、fused_moe、FLA 門控 delta 規則等），併為 SGLang 內部加執行時補丁（FlashInfer 注意力後端相容、MCCL 支撐的 PyNCCL 包裝、取樣後端行為、torchvision JPEG 解碼回退），同時補 metax.yaml 派發配置與 Qwen3 27B、35B-A3B 示例指令碼。
  • vLLM 側在審：#642 把 TXDA 之外的排程路徑調整到 vLLM 0.28.0（清微）、#635 加 Qwen3.8-Flash-Next 的 BF16 基線、#636 加 BGE-M3 初步適配。
  • 運算元庫：#998 在審修 FlashAttention 精度與圖捕獲問題並最佳化 TP2 與 TP4 效能；#1000 在審跳過原地 MoE 對齊中不支援的 TLE。
  • 生態側：RLinf 主線合入（見 2.2），是其在具身智慧方向的「上游優先」落地。
  • 判斷：沐曦本期的重心從推理外掛搬到 SGLang 後端整包與上游框架合入兩條線上。SGLang 外掛原先只有昇騰、海光、天數等幾家，MetaX 加入後，推理框架側的廠商矩陣基本補齊；接下來看 vLLM 0.28 升級是否與 SGLang 0.5.18 的節奏對齊。

3.4 清微：TXDA 後端隨 vLLM 0.28.0 升級，FlagCX 打包納入清微（10-26）

日期：2026-10-26　來源：vllm-plugin-FL PR #642 · FlagCX PR #673 · 金融界轉載：Open3D-PIMC 生態推進

  • 外掛側：在審的 #642 把 TXDA 後端適配到 vLLM 0.28.0，屬 2.3 週期裡「外掛隨上游大版本走」的一批工作。
  • 打包側：在審的 FlagCX #673 把 RPM 打包擴充套件到清微、曦望與海光三個後端，清微是其中之一。
  • 構建側：10-22 已把清微 TX8 接進 FlagTree 構建器並掛上日常構建行，成為第六個後端；本視窗無新增構建改動。
  • 生態側：Open3D-PIMC 的對外推廣持續推進（見 2.1），並明確作為 FlagOS 面向下一代 3D 晶片的主要解決方案。
  • 判斷：清微的形態與其他成員不同——它在 FlagOS 裡既是後端（TX8、TXDA），又是新硬體形態的牽頭方（3D 堆疊、Open3D-PIMC）。兩條線目前沒有在程式碼上交匯，若未來 Open3D-PIMC 的後端直接複用 FlagTree 的 TX8 路徑，才算真正合流。

3.5 燧原、海光、天數、摩爾執行緒：四條後端各有一筆結構性改動（10-26）

日期：2026-10-26　來源：FlagPrism PR #17 · Torch-FL PR #654 · Torch-FL PR #660 · FlagTree tags

  • 燧原：FlagPrism 合入 tops 標頭檔案與庫依賴解析（#17，16 檔案、2,126 行），把燧原 SDK 的標頭檔案與庫查詢從隱式改為顯式；FlagAttention 有一條燧原側的融合注意力運算元（fused_attnres）在審。
  • 海光：Torch-FL 修 DCU 執行時的構建源（#654）——DCU 的 runtime_dir 原先指向只放 ABI 墊片的目錄，導致執行時庫由 32 個樁連結而成，構建能過但一 import 就報未定義符號，改動 71 檔案、1.1 萬行；同日在審的 #627 為開啟裝箱的 DCU 構建接上真實流。
  • 天數：Torch-FL #660 修 Iluvatar 上 bf16 GEMM 退回主機執行的問題——2048 見方的 bf16 mm 實測 0.41 TFLOPS，低於同機 CPU 的 0.54，而同運算元 fp16 為 80.2、廠商自帶 torch 為 84.6；根因是支援判斷未納入 bf16 且 mm 與 addmm 在主機側複製了轉置權重。修完後走廠商 BLAS。
  • 摩爾執行緒：FlagTree 打出 MThreads 專用標籤（0.7.1a1+mthreads3.6），FlagGems-vllm 合入 chunk_kda 的 MThreads 最佳化（#990），MUSA 後端的 TLE 快取持久化改動上週已落。
  • 判斷：四家的共同點是「修能跑但跑得慢或跑一半炸」的問題，而不是加新運算元。這類缺陷最難在外部復現，也最能說明後端矩陣的真實完成度——廠商側提交的仍以自家平臺的正確性與效能為主，跨平臺統一語義的工作仍靠 FlagOS 主幹推動。

四、總結與趨勢觀察

  • 2.3.0 已走完一遍完整管道，標籤仍未打出：執行時的門禁、changelog、重建授權、版本引數化在 10-23 至 10-25 就位，10-26 授權應用層重建並把標籤收斂成 2.3.0-0.3.0。從「執行時重新整理」到「應用跟版」這一步通常緊跟正式釋出，本週仍是關鍵觀察窗。
  • 後端矩陣在擴張而非收斂：AMD ROCm 7.2.4 基礎映象新增，說明 2.3 週期還在加平臺。與之對應，玄鐵補 BLAS1、清微接 RPM 打包、崑崙芯補裝置位碼——四件事分屬數值庫、打包、通訊三個層面，都是「接進來之後才需要做」的工作。
  • 數值庫與訓練棧成為新戰場：FlagBLAS 一次性補十五組 BLAS1 運算元、FlagTrain 一批運算元鋪到七家後端，兩條線都在 2.3 週期加速。推理運算元的邊際收益在下降（FlagGems 本期以 KernelGen 自動生成批次與後端調優為主），訓練與數值庫的缺口更明顯。
  • 視覺方向首次成形，但缺效能證據：FlagCV 把定位寫成「Triton 實現的 OpenCV 形狀視覺運算元庫，對標 OpenCV CUDA 基線」，接在 FlagTree 上。目前只有說明與骨架，沒有任何基準或非 GPU 後端資料，判斷其價值為時尚早。
  • 評審頻寬成為瓶頸：提交增 37%、在審增 23%、合入降 18%、新開降 18%。開發側在積累，評審側在消化。FlagGems 與 FlagTree 兩個倉的在審量（52 與 9）與合入量（49 與 4）的落差最明顯，而這兩倉恰好是 2.3 的編譯器與運算元版本來源。
  • 量子棧進入場景鋪開期：糾錯碼、中性原子、熱浴三類物理場景同期推進，仍按四段留證作業。它繼續佔據全組織近六成提交，但相對上一期的日均已回落三分之二。
  • 資訊面連續第三個視窗只有成員單位通稿：12 條候選 2 條有效，FlagOS 自身無版本釋出、無新倉、無對外公告。內容主體仍來自 GitHub，屬典型「程式碼在填後端、傳播在等節點」的視窗。
  • 侷限說明：提交檢索為 GitHub search 的 total_count 口徑（185 筆），與合併 PR 檢索（133 筆）因壓縮合並與索引延遲存在口徑差，FlagGems 出現合入數（49）高於提交檢索數（28）即屬此類，報告內以合入數為準；FlagQuantum 的 109 筆含合併與分支同步提交，不等同於 109 個功能改動；FlagTree 的 0.7.1a1+mthreads3.6 經 Release 列表與 Tag 介面雙向核對為純 Tag，無 Release 說明；廠商通稿中的「無需改程式碼」「對齊或超過論文」等表述為公司口徑，未取得第三方復現；清微稿件中「20 家廠商、30 餘款晶片」與大會口徑的 21 廠商、35 晶片不一致，已在正文標註歸屬。

附錄：信源核查表與完整信源清單

信源核查表

信源 核查結果
GitHub 組織倉庫 API 61 倉全量返回，18 倉 24 小時視窗內有推送
GitHub 提交檢索 185 筆，按 URL 歸倉 16 倉
GitHub 合併 PR 檢索 133 筆視窗內合入，最強為 FlagGems 49 筆
GitHub 在審 PR 檢索 225 筆視窗內更新，其中新開 74 筆
GitHub org 事件流 100 條，PR 49、推送 20、建分支 10、刪分支 7、評論 9
Release 與 Tag 原子核查 31 倉中僅 FlagTree 新增一個標籤，無 Release 條目
Tag 與 Release 交叉核對 0.7.1a1+mthreads3.6 經 releases 列表與 git ref 介面雙向確認為純 Tag
Atom 兜底 docs、release-info 兩倉補查，主分支無視窗內提交，推送落在非預設分支
關鍵 PR 正文核查 15 筆逐筆核對標題、改動行數與合併時間
Google News RSS 24 組中英文查詢 12 條候選，2 條有效（走代理）
HN Algolia 8 組查詢 4 天 34 條命中，無標題直接匹配
CSDN FlagOS 專欄 51 條連結，最新資訊稿為 8 月下旬，視窗內無新稿
智源社群 搜尋頁客戶端渲染，僅得框架頁，本期未取用
成員單位通稿 清微、沐曦兩家原稿取正文核對日期與口徑
待收錄佇列 當日無本主題檔案，未歸檔檔案掃描亦無 FlagOS 小節

完整信源清單

[22] FlagQuantum PR #924（固定 shots 實驗契約） — https://github.com/flagos-ai/FlagQuantum/pull/924

hub.com/flagos-ai/vllm-plugin-FL/pull/642>