報告週期：2026 年 10 月 26 日（週一）至 10 月 30 日（週五），共 5 個工作日。

素材來源：本刊每日 FlagOS 動態報告 5 期（10-26 / 10-27 / 10-28 / 10-29 / 10-30，週期內無缺期）。其中 10-26 期為週一晨報，調研視窗自上一期截點 10-23 06:00 起算，為 72 小時，覆蓋 10-24 與 10-25 週末；10-27 至 10-30 四期為 24 小時視窗，首尾相接，末期末班截至 10-29 06:00 至 10-30 06:00。因此本報告的事實區間為 10-23 至 10-29，10-23 至 10-25 部分按原始日期標註。

編制說明：按版本與釋出、元件與程式碼共建、成員單位與廠商適配、生態與社群、趨勢觀察五個維度組織。五期日報按各自視窗累加為提交 1187 筆、合入 755 筆；若只取四個完整的 24 小時視窗（10-27 至 10-30），為提交 575 筆、合入 481 筆。單期有推送的倉庫數依次為 16、18、20、23、21 個，組織倉庫總數為 61 個。版本與標籤以各元件倉庫的標籤與 Release 原子源獨立複核，10-31 複核結果：build-infra 最新標籤仍為 v2.2.0，community 倉 release/2.3 目錄下仍只有中英文排期表，未見釋出清單。

一、本週要聞

  • 2.3.0 走完從執行時到應用層的整條管道，標籤與釋出清單仍未落地（10-25 ~ 10-30）：10-25 授權 2.3.0 執行時按版本重建；10-26 授權二十個 vllm0.24.0 應用映象在新執行時上重建，並把標籤從「按後端加字尾」收斂成統一的 2.3.0-0.3.0；10-27 06:54 至 13:25 連續二十筆機器人提交，把二十個後端鍵的應用映象標籤逐一落賬；10-28 至 10-29 changelog 上站到站點頁與 Harbor。截至 10-30 晨，build-infra 最新標籤仍是 8 月 3 日的 v2.2.0，community/release/2.3 仍未建立 release 清單。按排期，11-13 為 FEP 合入截止、11-30 特性凍結並拉 rc0、12-07 拉 rc1、12-14 拉 rc2、12-25 封板、12-30 釋出。

  • MiniMax-M3.1-Flash 九芯 W8A8 同日交付，Day-0 進入「統一格式批次複製」階段（10-23）：MiniMax 開源當日，FlagOS 把九家晶片的 W8A8 版本上架 ModelScope 與 Hugging Face，九倉在 10-23 14:06 至 14:39 半小時內集中建立。九家為達摩院玄鐵（真武）、英偉達、沐曦、海光、華為昇騰、摩爾執行緒、天數智芯、崑崙芯、清微，其中英偉達、昇騰、崑崙芯與達摩院玄鐵四家為 Express 版。技術路徑是把模型原有的 QAT NVFP4 權重重轉為跨芯統一的 W8A8 格式，原始碼部署示例以達摩院玄鐵為基準（vLLM 0.24.0、vllm-plugin-FL 0.3.0、FlagGems 5.4.0、張量並行 8 卡）。這是繼 GLM-5.3-Flash 九芯之後一週內第二次「模型開源當日九芯齊發」，區別在於上一輪是 BF16 與多精度並行、本輪統一收斂到 W8A8 單一路徑。

  • 地平線 BPU 首次成為可逐運算元執行的 PrivateUse1 後端，新平臺從「設計上不可用」變為可用（10-28）：Torch-FL #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 比對零差異。收尾三筆分別修分發日誌名、CUDA 複製核心守衛與廠商名到平臺 id 的對映。侷限同樣明確：卷積等主幹運算元仍靠 torch.compile 整圖路徑。

  • FEP-0140 改為 0.32 單發、0.28 跳過、AMD 入列，規則面一次性壓掉追版成本（10-27 ~ 10-28）：community 倉兩個改寫（#157、#158）把 vLLM 外掛的多版本相容策略定為「0.32 成為唯一發布版本且覆蓋全部晶片」，原「按 Day-0 需求選五家」的範圍擴為完整矩陣（2.2 週期的十家廠商加英偉達與 AMD）；0.28 不再作為釋出版本，連矩陣列與相關 PR 段落一併刪除，已合入的 0.28 適配只留作升級基線。10-28 再補剖析範圍與驗證計劃（#159），並把狀態轉為 Implementable、Owner 設為 @ceci3（#160）；FEP-0141 收窄到 SGLang 0.5.18 與沐曦、清微的基礎功能（#161）。代價被明確寫出：0.28 上合入的適配需在 0.32 上重走驗收，這部分工作量尚未在任何 PR 中體現。

  • 達摩院玄鐵一週內連補兩塊底盤：BLAS1 十五組運算元落庫與 PPU 稀疏注意力（10-26 / 10-28）：10-26 FlagBLAS #154 一次性補齊 AMAX、AMIN、ASUM、AXPY、COPY、DOT、DOTC、DOTU、NRM2、ROT、ROTG、ROTM、ROTMG、SCAL、SWAP 十五組一級基礎線性代數運算元，改動 17 個檔案、新增 16,168 行；此前該後端在 FlagOS 裡的存在感集中在推理路徑，數值庫是空檔。10-28 FlagAttention #111 又為真武 PPU 補上 MiniMax 稀疏注意力推理運算元（6 檔案，加 4644 行），支援分頁 KV 快取、因果掩碼與強制塊選擇，prefill 21/21 透過、幾何均值 2.299 倍，decode 18/18 透過、幾何均值 1.354 倍，合計 39/39、幾何均值 1.800 倍。按「能跑推理、能跑訓練、數值庫自洽」三段衡量，本週跨到第三段的第一級臺階。

  • 沐曦把 135 個特化運算元的驗收證據搬進可審狀態，一小時內開出 135 筆 PR（10-27）：FlagGems-Experimental 在 17:43 至 17:59 之間新開 #744 至 #878，標題統一為「Add MetaX support for 運算元名」，每筆單檔案、約 200 行增刪。PR 正文說明本輪為沐曦特化運算元複測（1027 批次），150 個運算元參測、135 個透過三輪複測後逐一提交，未透過的 15 個留在批次外；驗收口徑為精度 29 個用例全透過、效能幾何均值 1.008 倍（門檻 0.8），環境為 torch 2.8.0 加 metax3.7.2.0、flagtree 0.6.1、八卡 C550。當日組織在審 PR 由 225 升至 401，其中 135 筆來自這一次批次提交。

  • 測試基建 ref-as-candidate 在雙倉落地，「測什麼」從有沒有運算元變成參考與實現是否一致（10-29）：FlagGems #7630（9 檔案）讓正確性測試與基準可以把顯式宣告的參考實現當作候選來跑，不再依賴外部候選檔案，缺參考、參考不可呼叫、測試體未實際呼叫候選都會顯式失敗。同日 FlagGems-sglang 以 #239 至 #249 十一筆把全部正確性套件改到 get_candidate，並新增每日 master 到 kernelgen-dev 的自動同步 PR（#242，當日已產生兩筆）；單日另有 57 筆由同一作者的測試修復合入，覆蓋昇騰、沐曦、燧原、崑崙芯與英偉達的跳過條件與參考 ABI。這條線不產出運算元數量，但決定後續所有後端對齊是否可信。

  • MiniCPM-OCR 雙模型 Day0 覆蓋 12 平臺，首次給出可比較的歸一化口徑（10-29）：面壁智慧與 OpenBMB 開源的 MiniCPM-OCR 1.0（1.3B）與 MiniCPM-OCR Jev（2B）完成跨芯適配，覆蓋達摩院玄鐵、英偉達、華為昇騰、海光、崑崙芯、沐曦、摩爾執行緒、清微智慧、天數智芯、曦望、Mac（ARM）與此芯科技 12 個平臺。效能口徑分開陳述：Jev 在達摩院玄鐵上平均 63.56 毫秒，實際計算吞吐達英偉達 H100 原生的 98.7%；OCR 1.0 按峰值算力歸一化後，單文件 P50 吞吐為原生的 169.3%、批次場景 137.1%，並寫明 169.3% 的前提是低峰值算力平臺利用率更高而非單卡更快；端側 M5 CPU 上 Jev 平均單次頁面塊判別 1.2 秒、中位 895 毫秒。

二、版本與釋出動態

本週標籤與 Release 清單（北京時間）

時間 元件 標籤 / 版本 說明
10-26 10:13 FlagTree 0.7.1a1+mthreads3.6 摩爾執行緒 3.6 專用構建線，純 Tag，Releases 列表無對應正文
10-28 17:25 FlagCX v0.14.1 指向 #668「按介面卡生成裝置位碼」，只有 git tag、無 Release 正文
10-29 10:55 FlagCX v0.14.1（標籤指向更新） 複核時標籤已移到 #683 的合入提交（崑崙芯 cstddef 回摘），仍無正文
10-29 11:09 FlagTree 0.7.1a1+tsingmicro3.6 清微 3.6 專用構建線，純 Tag，無對應正文
  • 三個標籤、兩個元件，無一為正式版本：本週期沒有任何元件釋出正式版本。FlagGems 仍是 5.4.0（09-28）為正式線，5.5.0.dev0 於 10-12 開線後無新標籤；FlagQuantum 以 v0.3.1（10-16）為量子棧基線；FlagScale、FlagBLAS、FlagDNN、FlagFFT、FlagTensor、FlagAttention、vllm-plugin-FL、sglang-plugin-FL 等仍停在 09-28 那一批。這是 2.2 釋出之後、2.3 於 12-30 GA 之前的典型空檔：對外版本靜默，製品線與構建線活躍。
  • 兩個標籤缺釋出正文，是本週唯一可復發的流程問題：FlagCX v0.14.1 只建 git tag、未建 GitHub Release，與 v0.14.0「正文指向 FlagOS 2.2 釋出清單」的做法不一致；FlagTree 的 3.6 線以「每廠商一個標籤」推進，0.7.1a1 本身沒有統一發布說明，下游只能從標籤名反推後端與 Triton 版本。

2.3.0：管道從頭到尾跑通，只差標籤與釋出清單

  • 執行時層（10-25 ~ 10-26）：10-25 授權 2.3.0 執行時按版本請求重建，隨後兩筆修掉 OCI 標籤構建引數引號與廠商 SDK 環境變數丟失 venv 字首的問題；容器新增啟動期版本引數，可用 FLAGTREE_VERSION=latest 裝當日構建、用 FLAGGEMS_VERSION 指定 FlagGems 版本，版本從「燒進映象」變成「啟動時選擇」，並刪除 -build 變體。
  • 應用層（10-26 ~ 10-27）：10-26 #1488 為二十個 vllm0.24.0 應用映象補 changelog 待發布條目以滿足門禁，同時把原生外掛標籤移出映象標籤、改由統一解析器決定，使 2.3.0-0.3.0 這個不帶後端字尾的統一標籤成立。10-27 二十筆機器人提交把二十個後端鍵的標籤逐一落賬：昇騰 cann8.5.0、cann8.5.0-910c、cann9.0.0、cann9.0.0-910c；寒武紀 neuware4.4.3、neuware4.7.2；燧原 tops1.9.10、tops1.10.6；摩爾執行緒 musa4.3.6、musa5.2.0；沐曦 maca3.7.2.1、maca3.8.1.3；天數 corex4.4.0、corex4.5.0；英偉達 cuda12.8、cuda13.3；以及崑崙芯 xre5.37.1、海光 dtk26.04、清微 tsm260610、曦望 tangrt1.2.0。
  • 留痕與門禁（10-28 ~ 10-29）：每映象 changelog 現在同時出現在站點頁面末尾與 Harbor 倉庫描述（#1545，455 檔案，加 19080 行），原因欄位做成中英雙語（#1542）；應用頁一致性檢查接進 pre-commit 與 CI（#1549），改一個 image_tag 或 changelog 原因後必須先重建 images.yaml 再比對。
  • 未完成項：版本標籤未打、釋出清單未建。10-30 日報以「community 倉的 release/2.3/release-2.3.yaml 仍為 404」記錄該狀態，10-31 複核目錄內容仍只有中英文排期表、行為準則、治理與維護者文件，無釋出清單。

AMD ROCm 7.2.4：本週期唯一新增後端

  • 基礎映象（10-26）：以 ubuntu 24.04 加 repo.radeon.com 直裝 ROCm 7.2.4，只裝 28 個精幹包、apt 解析執行時依賴後合計 94 個，明確排除 MIOpen、MIGraphX、rocm-gdb、rocprofiler-sdk 與 opencl；在乾淨容器內演練透過，並用本地映象驗證八張 W7900 直通。演練中發現兩條必須寫進 Containerfile 的事實：節點到不了 archive.ubuntu.com，必須在 ca-certificates 存在之前就切國內 HTTP 映象（走 HTTPS 會握手失敗）；pin 檔案不是版本偏好而是必需項。
  • 配置與打包（10-27）：新增 vendors.amd.rocm7.2.4，棧為 torch 2.11.0+rocm7.2、triton-rocm 3.6.0、flagtree 0.7.0+amd3.6，硬體標註 Radeon PRO W7900（gfx1100、RDNA3）、驅動 6.16.13、Python 3.12；連續五筆補 hipsolver、hipfft、miopen-hip 開發包，開啟 FlagCX 的 AMD wheel 行與廠商 PyPI，並在本地十六卡 gfx1100 上驗證。同期 native deb 與 native rpm 兩條線加上 arm64 維度。
  • 執行時連通（10-29）：FlagCX #679 在 ROCm 上把 SGLang 張量並行跑通——補 eventElapsedTime 實現、把 torch.bool 對映到 flagcxUint8、加 USE_AMD 測試構建分支；R9700 雙卡上 AllReduce、ReduceScatter、AllGather、Broadcast、Send/Recv 與圖捕獲的 AllReduce 結果正確，Qwen3.5-9B 與 Qwen3.6-35B-A3B-FP8 在 TP=2 下可服務。
  • 構建器補課（10-29）：在 7.2.4 執行時上構建的 FlagCX wheel 連結 GLIBC_2.38，被 wheel 線的 22.04 門禁拒絕，遂為該行配自足的 22.04 構建器（jammy 套件加 deadsnakes 的 Python 3.12、pin 住的 torch），glibc 下限回到 2.35。
  • 邊界：FlagGems 尚無 ROCm/HIP 的 C++ 後端，AMD 短期只走 Triton 路徑。這是本週期後端矩陣仍在擴張而非收斂的直接證據。

FlagCX：從標籤走向發行包

  • 裝置位碼改為按介面卡生成（#668，10-18 合入，本週成為 v0.14.1 的內容）：把 setup.py 位碼步驟裡硬編碼的 bindings/ir/nvidia 換成按介面卡查表，每個介面卡宣告自己的 Makefile 與架構變數。此前任何非英偉達介面卡都會拋 RuntimeError 或靜默不出位碼，FlagTree 的 iluvatar 後端只能複製 FlagCX 原始碼自行重編。
  • rpm 線從三個後端擴到六個（#673，10 檔案，加 295 行減 8 行）：新增 libflagcx-tsm（清微）、libflagcx-sunrise（曦望）、libflagcx-du（海光 DCU）。三家都不需要廠商基礎映象——SDK 解包到 /opt 或 /usr/local、不呼叫包管理器，openEuler 映象加檔案倉即完整構建環境；廠商 soname 按昇騰已有口徑統一過濾。
  • 交付面轉 wheel 線（10-29）：build-infra 機器人記錄 flagcx wheel 釋出（#1553），人工補齊五條空殼描述並加入 flagcx==0.14.1+rocm7.2.4（#1556），再把 hygon-dtk26.10 釘到 flagcx==0.14.1+dtk2610（#1563）。至此 0.14.1 的交付面覆蓋 cuda12.8、cuda13.3、corex4.4.0、corex4.5.0、xre5.37.1、rocm7.2.4 與新增的 dtk2610。
  • 0.14 系列仍在支援視窗：在審的 #683 把崑崙芯 cstddef 修復回摘到 0.14.0-rc2 線，說明 0.14 的補丁線未凍結。

FlagTree：3.6 線按廠商切片

  • 兩條專號標籤：10-26 的 0.7.1a1+mthreads3.6 與 10-29 的 0.7.1a1+tsingmicro3.6 屬同一條「按廠商切分的 3.6 預釋出線」，均無 Release 正文。清微那個標籤與同日合入的 #1459（清微後端同步內部 Triton 3.6 開發線，27 檔案，加 2264 行減 407 行）一一對應。
  • 能力增量集中在編譯器：摩爾執行緒的 [MThreads][TLE] 常駐 GEMM 流水線與 SPMC 同步進主線（#1294，63 檔案，加 6192 行減 403 行），把原先分別服務 addmm/baddbmm 與 bmm 的兩套編譯器合成一套超集，支援動態迴圈裡的 stage 與 phase 推進、一生產者對多消費者、命名讀與隱式讀、分段完成與消費者紀元推導，以及單發、融合消費者與 16 warp 常駐路徑；昇騰接上 TensorView 訪問路徑（#1426，32 檔案，加 4901 行）；AMD 為 Qwen3-1.7B bf16 做 batch-1 解碼最佳化（#1439，44 檔案），R9700 在上下文 1 時 154 tok/s、8K 時 125，W7900 分別為 167 與 136，實測頻寬 530 至 597 GB/s，達該卡實測流式上限的 82% 至 87%。
  • IR 層動作：flir 新增 TensorView 方言（#83，25 檔案，加 1396 行減 13 行），把 Triton 指標變成攜帶 shape、stride 與訪問編碼的 tensor_view，提供分割槽、跨步、gather/scatter 三類編碼，並接入 CommonIR 的 tile.load 與 tile.store，位於 Triton tt 方言與 HIVM、昇騰 NPU IR 之間，與 TileIR 平行。
  • 在審側：SpaceMiT 的 vmt4d 後端（#1455）、崑崙芯分散式 TLE 後端（#1436）、海光 TLE 通訊原語適配（#1441）、昇騰 rpm 線改為消費已釋出 wheel（#1461，首條無需廠商 SDK 與硬體的行）、英偉達 Hopper 四項軟體流水缺陷修復（#1460）。

三、元件與程式碼共建

組織節奏：五期累加 1187 筆提交、755 筆合入

期次 視窗（北京時間） 推送倉庫 提交 合入 在審（視窗內更新） 新開
10-26 10-23 06:00 ~ 10-26 06:00（72 小時） 16 612 274 253 141
10-27 10-26 06:00 ~ 10-27 06:00 18 185 133 225 74
10-28 10-27 06:00 ~ 10-28 06:00 20 102 98 401 269
10-29 10-28 06:00 ~ 10-29 06:00 23 99 67 288 101
10-30 10-29 06:00 ~ 10-30 06:00 21 189 183 253 84
合計 — — 1187 755 — 669
  • 合入分倉累加（各期日報披露口徑）：FlagQuantum 226 筆（佔 29.9%）、FlagGems 224（29.7%）、build-infra 75（9.9%）、FlagGems-sglang 59（7.8%）、Torch-FL 33（4.4%）、FlagGems-vllm 29（3.8%）、FlagTree 24（3.2%）、vllm-plugin-FL 16（2.1%）、optest 12、FlagTrain 10、FlagCX 10、FlagAttention 9、sglang-plugin-FL 5、community 5、FlagQAI 4，FlagBLAS、FlagScale、FlagOps、TransformerEngine-FL 各 2，FlagCV、FlagSparse、FlagPrism、flir、Trident、FlagTensor 各 1。
  • 雙引擎佔比回落到七成以內：FlagQuantum 與 FlagGems 合計 450 筆、佔 59.6%，加 build-infra 後三倉佔 69.5%——上一期同樣的兩倉佔 56.3%、四倉佔 79%，本週期 build-infra 的比重因 2.3 映象落賬而升到近一成。
  • 周內形態是「兩峰一谷一再起」：週一（72 小時視窗）量子棧與 FlagGems 雙高，週二量子棧繼續上衝而 FlagGems 承接，週三轉為 build-infra 記賬為主（36 筆，其中二十筆是映象標籤機器人提交），週四回落到 67 筆為全周最低，週五以 183 筆反彈、為周內最高（FlagGems 一家 92 筆）。
  • 在審的兩次脈衝都與批次提交有關：10-28 的在審 401 筆中 135 筆來自沐曦運算元批次 PR、269 筆為新開；10-29 回落至 288 筆後，10-30 進一步降到 253 筆。剔除批次提交看，評審佇列的實際水位在 220 至 290 筆之間波動，中樞比上一期（154 至 239 筆）更高。

FlagGems（合入 224 筆）：自動化供給與正確性修復並行

  • 運算元供給已由 KernelGen 承接：10-26 合入 16 筆 KernelGen 加英偉達字首的運算元（稀疏與結構化、量化、特殊函式、張量元資訊各一類）；10-29 單日 22 筆自動生成運算元（稀疏張量的不安全構造與重置、nnpack 空間卷積、thnn 卷積、分數最大池化反向、cholesky、frobenius 範數、chain_matmul 與一批邊角運算元），同日又新開五筆，佇列仍在延續。人工投入不在寫運算元，而在發射引數與測試可執行性兩處。
  • 正確性主線是本週最有價值的一類提交：index_put 與 _index_put_impl_ 共用核心的地址算術改為寬型別（#6892，兩檔案，加 112 行減 4 行）——此前在達摩院玄鐵 PPU-ZW810E 上，int32 索引配合大 stride 張量會靜默寫錯地址，目標行不變而同分配區內的守衛字首被改寫；根因是索引乘 stride 在 int32 內求值並先迴繞，事後只轉最終偏移已來不及。昇騰側把 flagtree 從 0.7.0 升到 0.7.1a1 並新增執行時校驗指令碼（#7837，五檔案，加 291 行），因為執行時映象把 flagtree 烤在虛擬環境之外的 /opt/flagtree，pip 裝的 pin 覆蓋不了。崑崙芯後端在當前 master 上直接匯入失敗的問題也一併修掉（#7803，90 行）。
  • 後端調優以崑崙芯最密：八個出位標量鏈運算元改融合核心（#7617，275 行），小形狀單次發射、把所有指標作為核心引數帶入，輸出一次分配加 unbind 得到，相對耗時從 0.083 至 0.126 提到 0.813 至 0.934，約七到十倍；batch-norm 推理與 QKV 變換改連續段核心（#7600），聚合指標分別從 0.228 提到 1.357、從 0.260 提到 5.062；masked_fill 的整數檢視快路徑改寫為 f32 形式後 P800 上從 0.577 提到 0.829（#7850，594 個用例透過）。
  • 其他後端：天數 conv_transpose2d 換成按資料型別、核大小、步長與輸出通道數索引的七套硬體調優檔位（#7036，加 1886 行），並按輸出是否放得進 L2 在直掃與相位專用兩個變體間切換；conv3d 去掉每次呼叫的通道補零（#7061），輸出逐位一致；沐曦新增 INT8 與 FP8 的 grouped_mm_w8a8（#6950，7 檔案，加 1220 行），基準形態來自 GLM-5.2 在 PPU SGLang TP=8 上採集的真實呼叫回放，28 條場景、26 組唯一幾何、324 萬次呼叫、257 個專家。
  • 在審結構：10-28 新開 53 筆多數為燧原參考實現修復（#7890 至 #7908 連號，涉及 Kaiser 與 inplace ldexp、aminmax、special_round、LU、vander 與 slogdet、median 與 stacking、Adagrad、batch-norm ABI），另有 AMD 的一行修復——廠商描述符把裝置名設成 cuda 且未給 triton_extra_name，導致 pow、tanh、exp、rsqrt、erf、gelu 等全部走 __nv_* 被 AMD 後端拒絕。10-29 視窗 FlagGems 在審 181 筆、佔組織六成，說明多後端驗收的瓶頸在參考實現與測試口徑，而不是運算元供應。

FlagQuantum（合入 226 筆）：從結構重整轉入場景鋪開

  • 周初是一次目錄手術：10-23 至 10-26 三日 505 筆提交、148 筆合入，單倉佔組織 82.5% 提交與 54% 合入。QEC 包重組連做九筆（#735 至 #749），先審計包邊界與相容基線，再依次隔離碼矩陣與噪聲掃描、拆分碼族與所有權、分離儲存宣告與執行組裝、拆出探測器誤差模型、分離解碼演算法與可選介面卡、定稿包佈局與安裝指引，最後一體化併入主幹——以「可安裝性」為目標的目錄手術。
  • 外部依賴成形：Quafu SDK 生命週期整體切換分六筆完成（#852 至 #866），發現流程、邏輯任務、物理程式提交、拓撲解析、孿生生命週期依次改走 SDK，最後退役舊執行生命週期；舊路徑是刪除而非保留別名，屬硬切換。同期 Rydberg presence 從立契約（#854）到拒絕無條件組裝中的觀察（#865）、編碼單次 presence 觀察（#869）、驗證有界相干分支參考（#873），最後提出有限動態相干參考（#876）。
  • 中期轉向物理場景：10-27 十筆合入含張量網路下 Module 哈密頓量的期望值收縮（#939）、固定 shots 的糾錯記憶實驗（#932）、固定兩位元門覆蓋補齊（#935）；10-28 六筆中，把「分片後的 MPS 與不分片是否等價」做成兩臂可執行證據（#945，max_bond 64 加精確梯度只變佈局、max_bond 2 加近似梯度讓佈局與截斷一起變，用兩臂之差把兩種貢獻拆開）。
  • 週末收束到合成流水線：10-29 六十筆提交、十五筆合入，全部集中在量子電路合成（CS 系列），倉庫內已按 FQ-SYNTH-CS01..CS07-20261029 歸檔十份規格與交付文件：CS-01 定義相干整數構造的語義邊界與驗證，CS-02 用純算術核心降低相干加法，CS-03 處理乘法與相干多項式，CS-04 打通受限 Python 工作流，CS-05 加生命週期與工作區排程，CS-06 分三段落地，CS-07 進入暫存器語義與程式准入；同日加入可移植 .fqx 實驗檔案存載（#960）與 fq.run 的受檢程式執行（#964）。
  • 判斷：量子棧的作業方式是「設計稿、契約稿、可執行示例、驗收記錄」四段留證，成本高、可核查性好，也解釋了它為什麼長期佔組織三成以上提交但合入率只有三成左右。它與多芯適配無關，是 2.x 週期裡唯一一條與硬體解耦的軟體棧主線。

build-infra（合入 75 筆）：映象矩陣與撤回

  • 映象矩陣落賬：10-27 二十筆機器人提交把二十個後端鍵的 vllm 應用映象標籤統一記為 2.3.0-0.3.0，是本週期單日合入最高的一天（36 筆）。隨後 base 層的逐映象 changelog 與推送門禁補齊，三段映象記錄迴圈合併為一個指令碼。
  • 海光 DTK 26.10 八筆全鏈（10-29）：首版容器與配置（#1554、#1555）落地後映象仍不可構建也不可排程——base/hygon-dtk26.10 把 /opt/dtk 指向 dtk-26.04 而 SDK 實際解到 /opt/dtk-26.10，構建矩陣缺該條目的 runner 覆蓋會落回預設值（#1558）；torch 2.13.0+dtk2610 的全域性依賴直接鏈 libmpi.so.40 與 libibverbs.so.1，而 26.04 的 wheel 把這兩個 soname 雜湊進包內，因此基礎映象補 libopenmpi3t64（#1564）、構建器補 libopenmpi3（#1565）；同一執行時釘 python 3.12，使既有 cp310 的 hcu wheel 無法解析，遂以 deadsnakes 3.12 重建 cp312 構建器（#1562）並把 hcu-dtk2610 加進 wheel 釋出線（#1566）。八筆裡沒有一筆改核心，硬體代際切換的成本幾乎全部落在打包與依賴解析上。
  • 撤回兩筆從未推送的映象（10-28）：Harbor 裡沒有 megatron_training0.18.2-cambricon-neuware4.7.2 與對應的 megatron_rl 倉，但狀態矩陣記了 image_tag: 2.2.0-0.3.0，文件流水線為兩個不存在的映象發了啟動頁、readme 與 changelog，此後每次 pubdoc-app 都在這兩個倉上 404。根因在 0.18.2 的 wheel 裡 platform_register 沒有 MLU 平臺，torch_mlu 的 gpu_migration 把 CUDA 表面別名到 MLU 後選中的是 PlatformCUDA，流水線並行組始終未初始化，而 MLU 註冊只落在 release/0.2。處置是撤回主張而不是硬湊：去掉 image_tag、置 launch_docs: false、刪掉兩份 changelog，使「changelog 檔案集等於已釋出集合」重新成立。
  • 其它：native deb 與 rpm 增 arm64 維度（#1537）；昇騰 rpm 目標（#1557，首條不依賴廠商 SDK 與硬體的 rpm 線）；vllm 重打包依賴改讀 PEP 503 簡單索引（#1543，替代每個依賴起一個子程序的做法）。

Torch-FL（合入 33 筆）：抽象層換名與新平臺接入

  • 命名重構一輪到底：把箱化槽位從 Backend::kCuda 改為 Backend::kBoxing，給每個平臺加廠商名，按廠商重新命名原始碼與 CI 目錄、配置與標記與打包目錄、後端列舉與英偉達路由鍵，最後修掉重新命名留下的查表失配（六筆在 13:38 至 15:59 完成）。同期明確「不得從預設配置路由箱化」，並新增僅箱化的 day-0 配置——把「某平臺缺運算元時回落到打包路徑」從隱式行為改成顯式宣告。
  • 地平線 BPU 接入：見本週要聞第一條，此處不重複。
  • 兩處「能跑但跑錯」的硬修：海光 DCU 的 runtime_dir 原先指向只放 ABI 墊片的目錄，導致執行時庫由 32 個樁連結而成，構建能過但一 import 就報未定義符號（#654，71 檔案、1.1 萬行）；天數 bf16 GEMM 退回主機執行——2048 見方的 bf16 mm 實測 0.41 TFLOPS，低於同機 CPU 的 0.54，而同運算元 fp16 為 80.2、廠商自帶 torch 為 84.6，根因是支援判斷未納入 bf16 且 mm 與 addmm 在主機側複製了轉置權重（#660），修完後走廠商 BLAS。
  • 其它：MPS 側保留 MPSGraph 廣播形狀、給線性運算元用例配 CPU 參考與可讀差異、讓 Qwen3.5 視覺工廠與插值留在 MPS；昇騰遵循 FP32 matmul 精度並保持梯度駐留（#683）；按 conf 鍵路由解碼後的 soft-lowp 組合（#665）；MUSA tuner 貫通各策略子類（#666）；構建記錄裡廠商名與平臺 id 不一致（hygon/dcu、mthreads/musa、enflame/gcu、nvidia/cuda）一併修正（#673）。

推理棧：vllm-plugin-FL（16）、sglang-plugin-FL（5）、FlagGems-vllm（29）、FlagGems-sglang（59）

  • 三個新模型在同一周內進外掛：MiniMax-M3.1 支援與推理示例（#631，10-24 合入）、GLM-5.3-Flash 純公開運算元實現（#454，90 檔案，加 19140 行減 280 行）、Qwen3.8-Flash-Next 與 Qwen4 的檢查點載入與模型整合（#455，65 檔案，加 11226 行減 109 行，含 HC、PLE、QSA 與多模態接線）。FP8 一律採用能力門控：平臺原生支援則保留原生核心，不支援時回落到 BF16 線性與 MoE 路徑並強制 --dtype bfloat16。
  • 上游大版本的兩條線同時推進：原生 CUDA 的 vLLM 0.32 適配（#615，57 檔案，加 3408 行減 1044 行）把棧釘在 vLLM 0.32.0 加 cu129、PyTorch 2.13.0 加 cu129、CUDA 12.9 與 python 3.12.3 上，現有英偉達 CI 六項推理與三項服務全過；同時 0.28 的存量適配繼續合併（燧原 S60 #582、清微 TXDA #642 在審），與 FEP-0140 的「0.32 單發、0.28 跳過」形成一段並行期。
  • 圖模式落到第三、第四個國產後端：清微 TXDA 在 vLLM 外掛中獲得 FULL_DECODE_ONLY 的圖捕獲與回放（#649，八檔案，加 487 行），修掉捕獲域內核心啟動被拒（錯誤碼 0x47000003）與裝置守衛造成的流改道兩個根因，非 TXDA 路徑保持與上游逐位元組一致；AMD 側由 SGLang 在 R9700（gfx1201）上跑通 FlagOS（#157 在審）。
  • 運算元庫側的重點從新增轉向確定性：融合全歸約 RMSNorm 進 FlagGems-vllm（#773，6 檔案，加 3191 行），all-reduce 加殘差相加加 RMSNorm、可選 FP8 靜態量化、SM100+ 支援 NVFP4、TP2/4/8 的 FP16 與 BF16 均可；ihc_pre 的 stage1 合併把 tl.atomic_add 換成按 split 槽位寫（#1017），因為原子加使結果依賴塊到達順序、重複發射不逐位一致。沐曦側修 FlashAttention 的快取安全與圖捕獲並最佳化 TP2/TP4（#998），沐曦 TP2 packed decode 做 Split-KV 排程與計算 tile 重排（#1025）；fused_q_kv_rmsnorm 同時在昇騰（#872）與達摩院玄鐵（#888）落地。
  • FlagGems-sglang 是本週期合入效率最高的倉：34 筆競賽賽道運算元在兩小時出頭連合（10-23 15:47 至 18:02，其中 16:21 至 16:31 十分鐘內九筆），供給來自多名外部貢獻者，覆蓋 MLA 緩衝讀寫、排布重排、Top-K 取樣、MoE 零專家、快取定位與軟池化；工程側新增 Debian 與 RPM 打包（#191），說明該倉已從運算元集合轉向可安裝發行物。燧原的 core_shapes.yaml 加了一週沒生效——倉內沒有任何載入點、基準只認硬編碼的 kunlunxin 分支（#229 加檔案、#232 修載入），修完把查詢泛化到任意廠商並順帶修掉 FileNotFoundError；AMD 側為 RDNA3 補三個 Mamba 運算元的 gfx1100 版本（#231，578 行，與通用核心逐位一致）。

FlagCX（合入 10 筆）與通訊層

  • 裝置層：崑崙芯 XPU 的裝置位碼構建（#676），用 Makefile 把共享的裝置 API 封裝編成 xpu3 的 LLVM 位碼，從 XDK 解除安裝包裡抽出裝置模組、保留公共符號後最佳化，產出 libflagcx_device.bc 與消費側標頭檔案，通訊 traits 走 XSHMEM；隨後增加 XPU 的裝置 IR 入口以支援 FlagTree 連結（#678）。
  • 語義修正：天數的 Device API 補上 Atomic::load 的獲取語義（#681，3 檔案，加 359 行減 37 行）——此前 load(..., Acquire) 與 load(..., Relaxed) 發射同一條指令，觀察者在看到標誌後沒有失效屏障，本筆改為先讀後柵欄、按作用域選強度；系統作用域仍未實現，因為 ivcore11 沒有對應的記憶體屏障指令。
  • 打包與適配：清微 TSM 支援（#674，10 檔案，加 886 行減 80 行）同時修分組 P2P 清理、非法 peer 拒絕與非同步流事件處理；AMD 適配改用 CUDAStreamGuard（#680）；崑崙芯平臺 traits 把 cstddef 移到守衛之外（#682）。

訓練棧：FlagTrain（10）、FlagScale（2）、TransformerEngine-FL（2）、Megatron-LM-FL（在審 10）

  • FlagTrain 這一支的寫法固定：單筆 PR 標題裡直接列出後端清單，一個運算元按後端矩陣一次鋪開。合入的有 fused_indices_to_multihot（#29，英偉達與昇騰，H20 有基準）、基線對照機制移植（#30，按裝置瓶頸單位的峰值縮放係數歸一化速度比、輸出 vs Base 列、缺基線時記錄原因而不失敗）、multi_tensor_adam（#35，6 檔案，加 1093 行，覆蓋英偉達、海光、沐曦、PPU 與天數，一次 Triton 發射批次完成多張量 Adam 更新，H20 上 fp32 65536 元素相對 DeepSpeed CUDA 基線 2.24 倍、1024 元素小檔位反而 0.76 倍）。在審側 fused_proj_rms 前反向（#38）、fast_gelu（#33）、fp8_gemm（#18）、mixed_gemm（#10）與 multi_tensor_adam 的後續批次同時在列。
  • FlagScale 轉向測試紀律：統一測試策略、受影響路由與執行證據門（#1315）；離線訓練運算元畫像（#1310，4 檔案，加 1474 行），訓練側只匯出各 rank 的 Chrome 時間線，離線抽取器做外部 ID 歸因、通訊記賬與多 rank 聚合，按與推理剖析一致的列式產物輸出。在審可見 DeepSeek-V4 向上遊同步的 [1/N]（#202）與 [2/N]（#211，為打包序列補連續上下文並行），以及 HF 與 MCore 的 DCP 輕量互轉（#1319）。
  • TransformerEngine-FL 兩筆：實現 FlagCICD v1，引入 L0 至 L4 測試分級與計劃驅動執行（#142）；把 3rdparty/ 三個子模組回滾到上游 v2.17 的驗證基線（#150）——此前誤把 cutlass 前推 240 個提交（涉及 4000 多個檔案）、cudnn-frontend 從 v1.25.0 推到未釋出快照、googletest 推到 master 頭。
  • Megatron-LM-FL 值得單獨記一筆：在審 PR 十筆、為近兩週首次成規模更新（10-30 視窗），但本週期未見合入。這條訓練棧在 10 月中旬後一度停擺，是否真正恢復推送需要下一期確認。

數值庫、注意力與新方向

  • FlagBLAS（2 筆）：達摩院玄鐵 BLAS1 十五組運算元整批落庫（#154）與其後的 L1 命名與引用對齊（#155）。BLAS1 是上層 BLAS2、BLAS3 與 LAPACK 求解器的前置依賴，缺一層就無法自底向上自洽，這也是本週最容易被低估的一筆。
  • FlagAttention（9 筆）：除 PPU 的 MiniMax 稀疏注意力（#111）外，還有昇騰 Parallax 注意力三段實現（#103，10 檔案，加 2738 行，覆蓋因果掩碼、滑窗、GQA 與變長輸入，相較 FLA 在多數訓練形狀上為 1.0 至 8.74 倍）、燧原 MiniMax M3 稀疏注意力的 prefill 與 decode 最佳化（#104，2 檔案，加 2873 行減 2516 行）、沐曦 C550 上的 Triton 融合 AttnRes 前向（#108，3 檔案，加 268 行，D=7168 與 BF16 下從 0.075 毫秒到 1.496 毫秒，作者註明 FLA 不可用故不宣稱加速比）、海光移除 FP8 MSA 路徑（#109）。注意力層的碎片化在加劇，尚未出現跨廠商的統一下沉實現。
  • FlagCV（1 筆）首次說清自己是什麼：合入首份 About 與 README（#2），定位為「以 Triton 實現的高效能運算機視覺庫」，在 OpenCV 形狀的介面下提供色彩轉換、濾波、幾何變換與算術運算，以 OpenCV 的 CUDA 基線為對標，構建在 FlagTree 之上、後端可插拔。時間線是 10-14 建倉、10-18 落骨架並撤掉運算元實現改為即時模式骨架、10-26 補定位說明——程式碼骨架在前、定位說明在後。目前沒有任何基準或非 GPU 後端資料，真正的檢驗點是訪存密集運算元在 NPU 與 DSA 上的表現。
  • FlagQAI（4 筆）與 FlagQuantum 的邊界仍待說清：10-27 首次匯入命令列原始碼快照，首輪 CI 在夾具清單一步失敗（#1 在審）；10-29 加入本地量子工作臺網頁與原生 Agent 整合（#3）、重新整理後保留跟隨偏好的修復（#4）。README 明確把「由意圖合成電路」列為產品方向而非已完成能力，當前核驗範圍只有本地電路模擬與一條固定擬設的兩位元變分路線。
  • 其餘：FlagDNN 兩筆均為海光修正（GPU 名與效能）；FlagFFT 的推送落在 codex/musa-shortfall 特性分支、預設分支最新提交仍在 10-15；FlagTensor 昇騰常駐網格逐元素核心與廠商調優（#32，24 檔案，加 1128 行減 139 行）；Trident 支援 Python 3.10（#5），Monad 中間層（#4）仍在審；flir 的昇騰 split 與 join 及靜態置換降低（#86）在審。

測試與釋出工程：optest（12）、FlagOps（2）、community（5）

  • optest 把十三支廠商指令碼收成一條命令：flagos-gpu-check 按「廠商專有裝置節點優先、SMI 命令二次確認」的順序自動探測，保留各廠商原有的逐卡表格、超時與重試引數，並寫明兩條衝突規則——海光先於 AMD（兩者都有 kfd，只有海光有 mkfd）、玄鐵先於英偉達。隨後把輸出重做為單份文字摘要或單份可解析的 JSON 與 YAML（19 檔案，加 2947 行），新增 device、driver、runtime、runtime_version、device_count、memory_unit 等歸一欄位，並把執行時與主機驅動分開表述。燧原 S60 本週期接進 FlagGems-vllm 與 FlagGems-sglang 的變體 CI。
  • community 的五筆全是規則：FEP-0140 的兩個改寫、剖析範圍與驗證計劃、狀態轉 Implementable、FEP-0141 收窄。口徑澄清也寫進正文——DeepSeek-V4-Flash 與 Pro 仍是初始 W8A8 候選，「相對英偉達吞吐提升 10%」是最佳化目標而非固定驗收門檻。
  • FlagOps 兩筆都在穩定性：穩健檢出清掉硬殺 fetch 留下的陳舊 git 鎖（#18）；預設連線超時從 30 秒抬到 300 秒（#17）。

四、成員單位與廠商適配

  • 海光：本週期工程密度最高的廠商之一。DTK 26.10 在單日內走完八筆合入，從容器、可用性修復、cp312 構建器、FlagCX wheel 線到兩個 soname 依賴補齊，形成一條可複用的「新 SDK 接入排查路徑」；容器層首次落地時明確「FlagCX 尚未構建，故本階段不納入」。另有 build-infra 補發 libglog.so.1 解決原生外掛在 DTK 映象上載入失敗（#1524）、Torch-FL 修 DCU 執行時構建源（#654）、FlagAttention 移除 FP8 MSA 路徑（#109）、FlagTrain 把海光列為一等後端（#35），以及在審的 DCU 硬體健康取樣（FlagScale #1299）與 GLA 實現（FlagAttention #117）。
  • 沐曦：投入集中在運算元驗收與推理效能兩端。135 個特化運算元批次提 PR 是本週期組織在審數激增的主因；grouped_mm_w8a8 的 INT8 與 FP8 雙路徑以真實呼叫回放為基準；FlagGems-vllm 側修 FlashAttention 快取安全與圖捕獲並最佳化 TP2/TP4、按階段區分融合 MoE 調優、TP2 packed decode 做 Split-KV 排程；sglang-plugin-FL 的 MetaX 與 MACA 後端整包（31 檔案，加 3364 行）補齊了推理框架側的廠商矩陣。生態側 RLinf 全棧適配合入官方主線（見第五節）。
  • 崑崙芯：最早接入、覆蓋最廣，因此也最早進入長尾調優期。本週十餘筆合入幾乎全是「已有路徑做快做穩」——標量鏈融合約七到十倍、連續段核心把 batch-norm 推理與 QKV 變換聚合指標從 0.228 與 0.260 提到 1.357 與 5.062、masked_fill 從 0.577 提到 0.829、slice_scatter 與 vstack 重寫路徑並借 sym_numel 找回被註冊邏輯漏掉的廠商運算元表。位碼構建（FlagCX #676）長期價值高於單運算元提速，它把崑崙芯接進了統一裝置抽象。
  • 清微智慧：把內部 Triton 3.6 開發線直接同步進開源後端（27 檔案，加 2264 行減 407 行），並打出 3.6 專號標籤；TXDA 在 vLLM 外掛中獲得圖捕獲與回放；FlagCX 的 TSM 支援與 rpm 打包同日落地。代價是每次同步體量大、評審需按廠商 SDK 語義逐項核對，好處是 FlagGems 與 FlagTree 的介面約定能隨廠商內部進度前移。生態側 Open3D-PIMC 的推廣繼續（見第五節），但兩條線目前沒有在程式碼上交匯。
  • 華為昇騰：四個後端鍵（cann8.5.0、cann8.5.0-910c、cann9.0.0、cann9.0.0-910c）全部跟到 2.3.0-0.3.0；編譯器從安裝期固定推進到執行期強制固定（#7837），因為映象把 flagtree 烤在 /opt/flagtree、pip pin 覆蓋不了；FlagTree 接上 TensorView 訪問路徑（32 檔案，加 4901 行），在 CommonIR 到 HIVM 之間按索引模式選擇按索引載荷 DMA 或逐元素帶補零搬運；FlagAttention 新增 Parallax 注意力三段實現。vLLM 側的原生 decode 圖與 ModelSlim 動態 W8A8 量化仍在審。
  • 燧原：形狀表、工具鏈、推理三條線各補一處。core_shapes.yaml 加了一週沒生效的根因是倉內沒有載入點，修復把查詢泛化到任意廠商；FlagPrism 的剖析器與偵錯程式擴到燧原並預設開啟（#1239，5 檔案），帶除錯的核心發射改走閘道器；Qwen3.5 FP8 的 W8A8 塊標定推理上 GCU（#358，20 檔案，加 3367 行），圍繞 GCU300 與 GCU400 的硬體限制重做核心補丁，使 FP8 MoE 在 eager 與整圖兩種模式下都能跑通。在審側有大批參考實現修復（#7890 至 #7908 連號）尚未收口。
  • 天數智芯：卷積族三條線同時最佳化——conv_transpose2d 的七套工況檔位、conv3d 去掉通道補零、conv2d 快取打包權重並融合 channels_last 通道變換；FlagCX 補上 Atomic::load 的獲取語義，這是通訊正確性而非效能問題。硬體側天垓 300 首次實機演示對外（見第五節），軟體側的適配仍按 Device API、SGLang 0.5.18、訓練運算元三處逐項補齊。
  • 達摩院玄鐵：連續三個視窗保持「一次一個整塊」的節奏——推理（真武 Express 版與 PPU 稀疏 MLA 前向）、注意力（PPU 上的 MiniMax 稀疏注意力，幾何均值 1.800 倍）、數值庫（BLAS1 十五組運算元）。此外 fused_q_kv_rmsnorm 在 10-29 落到該平臺、FlagTrain 的 multi_tensor_adam 與 fp8_gemm 都把它

列為後端之一，optest 的廠商衝突規則把它排在英偉達之前。下一步看 BLAS2 與 BLAS3 是否跟進，以及 CPU 側是否與加速卡側共用同一套檢查指令碼。

  • 摩爾執行緒：投入重心在編譯器而非運算元數量。常駐 GEMM 與 SPMC 合成一套超集（63 檔案，加 6192 行減 403 行）是讓 addmm、baddbmm、bmm 一類主幹運算元在 MUSA 上跑到可用效能的前提，這條能力同時被昇騰與沐曦的 TLE 線複用；SDK 升到 v0.7.1 與 3.6 專號標籤對齊。生態側開源 Megatron-MUSA-Titan（見第五節），與本棧的交集仍是運算元與外掛層，而非訓練框架層。
  • 地平線：本週唯一一次「新平臺從不可用變為可用」的接入（Torch-FL #674）。價值在打通路徑而不是效能——40 個逐元素運算元是起點，卷積等主幹運算元仍靠整圖編譯；作者同時記錄兩條否定結論：libhbtl.so 只是 CPU 參考實現，動態形狀在 HBRT 4.7.5 上不可執行（載入器把該軸宣告成 stride 0，任務校驗要求不小於 64）。
  • 寒武紀：本週期在組織內無專屬倉庫推送與合入，僅在 build-infra 留有兩處痕跡——兩筆 neuware 版本（4.4.3 與 4.7.2）的 changelog 記賬，以及兩筆從未推送的 megatron 映象被撤回。上一期週報已把這家標為缺口，本週期延續，建議在下一期作為風險項單列。
  • 曦望：tangrt1.2.0 首次進入應用映象矩陣，libflagcx-sunrise 進入 rpm 線（SDK 經 tangtk --toolkit 與 pccl 落到 /usr/local），vLLM 0.28 執行時適配與共享 Gate CI 仍在審（#647）。
  • AMD（新增後端）：本週期從一張基礎映象長成完整後端，配置、打包、wheel 行、執行時驗證與構建器補課五步齊全；SGLang 在 R9700 上跑通張量並行。FlagGems 側尚無 HIP 的 C++ 後端，且其廠商描述符有把裝置名設成 cuda 的問題（修復在審 #7908），說明 AMD 這條線目前仍以 Triton 路徑為主。
  • 進迭時空與此芯、ARM：進迭時空在 FlagTree 的 vmt4d 後端仍在審（#1455），是 RISC-V AI 方向本週的唯一動作；MiniCPM-OCR 的端側覆蓋把此芯科技與 Mac（ARM）納入，M5 CPU 上以 SME2 矩陣指令加速主要線性層、透過 Triton TLE Raw 接入運算元執行路徑，平均單次頁面塊判別 1.2 秒。

五、生態與社群

  • InfoQ 給出 2.2 之後最完整的一篇中文技術覆盤（10-24）：截至第三季度，FlagOS 生態成員單位 107 家、季度社群下載 464,336 次（為第二季度的 4.76 倍）、程式碼貢獻者 264 位（較上一版增 55%）；從 2.1 到 2.2，合併 PR 由 1,890 增至 4,890、程式碼提交由 5,100 增至 9,730、新建 Issue 由 420 增至 1,423；九大運算元庫合計 1,454 個運算元、較上一版增 890 個，上千運算元、10 款晶片範圍內跨芯整體效能提升約 27%；GLM-5.3-Flash 在存量昇騰 910B 上邏輯服務吞吐由 8.52k 升至 17.36k tokens/s（2.04 倍）、512K 長上下文生成 60.9 tokens/s。成本項為按每臺 8 卡 910B 月租 16,500 元、3P1D 部署、93% 快取命中率測算，256K 輸入 8 併發場景每百萬輸出 Token 折算 59.27 元、512K 輸入 4 併發 104.53 元，分別較對應商業 API 低 19.4% 與 27.6%——屬租金折算的測算而非同負載實測對照，引用時應保留這一限定。
  • MiniCPM-OCR 的適配說明把三類數字分開陳述（10-29）：實際吞吐比（Jev 在達摩院玄鐵上達英偉達 H100 原生 98.7%）、按峰值算力歸一化的吞吐比（OCR 1.0 單文件 P50 169.3%、批次 137.1%）與端側時延（M5 CPU 平均 1.2 秒、中位 895 毫秒）各自標註前提，並寫明 169.3% 的成立前提是低峰值算力平臺的利用率更高而非單卡更快。這是本棧近期第一份把「追上原生」與「利用率更高」分開陳述的材料，比單一倍數更有參考價值。
  • 社群內容節奏從釋出會式宣講轉向按外掛拆解的單點技術直播（10-29）：19:00 開播的一場以 sglang-plugin-FL 的跨晶片推理適配為題，講 ATen 運算元替換、融合運算元排程、統一通訊抽象、PD 分離下的 KV Cache 傳輸與 Empty 模式的依賴拆分，口徑稱已適配昇騰、海光、崑崙芯等十款晶片平臺；與程式碼側的進度方向一致（該倉本週 6 筆在審 PR 更新，含昇騰與天數的 0.5.18 Empty 執行時適配）。本場與 10-22 的高校圓桌、10-15 的運算元賞金挑戰賽構成一條連續的技術傳播線。
  • 清微把 Open3D-PIMC 從開源首發帶到三十國師資課堂（10-26）：該專案由清微智慧與北京智源人工智慧研究院聯合開發，是面向 3D 算力晶片的程式設計模型與開源軟體框架，9 月在中國算力大會正式開源，被定位為眾智 FlagOS 面向下一代 3D 晶片的主要解決方案之一；開發者只描述資料分佈與任務劃分，框架自動完成圖編譯與即時執行的劃分與呼叫，推理側原生對接 vLLM 與 SGLang，各廠商私有指令集與微架構能力以外掛形式接入。本期報道聚焦生態推廣而非程式碼：全球 AI 開放計算師資發展計劃把清微工程師送進課堂，學員為來自三十多個國家的近五十位高校骨幹教師。文中「已適配 20 家晶片廠商、30 餘款 AI 晶片」為報道方口徑，與 10 月開放計算大會上官方給出的 21 廠商、35 晶片不完全一致，引用時需區分歸屬。
  • 沐曦把具身智慧的強化學習框架接進上游主線（10-26）：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）。此事不屬 FlagOS 元件釋出，但方向值得注意——它與 FlagOS-Robo、FlagScale 在場景上重疊，未來是否出現「成員單位先合入上游框架、再由 FlagOS 收口統一後端」的接力，是值得跟的線索。
  • 摩爾執行緒開源訓練基礎設施，程式碼與敘事要分開看（10-28）：Megatron-MUSA-Titan 面向萬卡級叢集的萬億引數 MoE 訓練，覆蓋預訓練與強化學習，支援 blockwise FP8、結合 DeepEP 與 ACE 非同步通訊做專家並行與計算重疊，可與 slime、miles 協同（Megatron 訓練加 SGLang 取樣）。倉庫存在但本視窗內無推送、最後推送為 10-16，屬「宣佈開源、程式碼未動」，與新聞稿的「開源」表述要在時間上分開看。同日釋出的還有三季度報告（營收 15.5 億元、同比增長 1773.9%，前三季度營收 32.89 億元、歸母淨利潤 3769.73 萬元，

並推進港股二次上市），財報不改變技術判斷，但解釋了其開源節奏的投入能力。

  • 天數天垓 300 首次實機演示，硬體口徑仍缺可複核條件（10-28）：公司在上海媒體開放日首次實機展示天垓 300 通用 GPU，稱其為首款實測效能達到英偉達 H200 水平的國產通用 GPU，第三方測試換算後單卡整體吞吐為 H200 的 1.05 倍，並在文生圖、文生影片等複雜多模態任務上超過 H200。該數字為公司口徑，測試方法、所用模型與工作負載條件均未公佈，無法複核。軟體棧側的對應動作是持續的——FlagCX 補 Device API 獲取語義、SGLang 0.5.18 的 Empty 執行時適配在審、multi_tensor_adam 已把天數列為支援後端。
  • 渠道核查：新聞面連續四個視窗只有成員單位通稿（10-23 ~ 10-29）。五期日報共做 120 組中英文查詢（每期 24 組），元件名直查（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）中英文合計持續零命中。五期合計有效條目八條：Google News 側六條——InfoQ 的 2.2 覆盤（10-24）、沐曦與摩爾執行緒的 MiniMax M3.1 Flash Day-0 通稿（10-23）、清微 Open3D-PIMC（10-26）、沐曦 RLinf（10-26）、摩爾執行緒 Megatron-MUSA-Titan（10-28）；社群自有渠道兩條——MiniCPM-OCR 雙模型 Day0 適配文章（10-29 11:19）與 sglang-plugin-FL 技術直播（10-29 19:00）。CSDN FlagOS 專欄自 10-22 停更後於 10-29 恢復；HN Algolia 八組查詢四天視窗內零條直接命中；智源社群搜尋頁為客戶端渲染，僅得框架頁；八家成員單位官網七日巡檢僅有四條（摩爾執行緒 4K 後期製作網、三季度報告圖解，沐曦 CNCC 2026 分論壇回顧，以及一條與軟體棧無關的行業落地稿）；待收錄佇列本週期無 FlagOS 條目。

六、趨勢觀察

  • 2.3 的瓶頸已經不在程式碼，而在「釋出能否自證」：本週期最密集的一批工作不是新運算元，而是門禁、留痕、撤回與一致性檢查——changelog 從「人工記憶」變成推送門禁、上站到站點頁與 Harbor，應用頁一致性檢查接進 pre-commit，兩筆從未推送的映象被撤回以使「changelog 檔案集等於已釋出集合」。這些動作不產出能力，但直接決定 12-30 之前那份釋出清單能否被外部核對。當前狀態是構建面已在按 2.3.0 記賬、釋出清單仍為空，11-13 的 FEP 截止與 11-30 的 rc0 會壓縮整個 rc 期。
  • 後端矩陣在 2.3 週期繼續擴張，而不是收斂：AMD ROCm 7.2.4 從一張基礎映象長成完整後端，地平線 BPU 從「設計上不能 eager」變成可逐運算元執行。兩件事的共同點是「接進來之後才需要做」的後續工作極重——AMD 要補構建器與 wheel 行，BPU 要補分發日誌、複製核心守衛與廠商名對映，且新後端的第一道坎始終是「能跑」而不是「更快」。
  • Day-0 交付已從「能不能跑」進入「按統一格式批次複製」，下一步的勝負手是口徑：一週內兩次九芯齊發，本輪統一收斂到 W8A8 單一路徑並把四家做成 Express 版，說明發布流水線已模板化。MiniCPM-OCR 的說明更進一步，把實際吞吐比、按峰值歸一化的吞吐比與端側時延分開陳述並寫明前提——這比單一倍數更有參考價值，也更容易在下一輪被同行按同一口徑比較。
  • 運算元供給自動化之後，人工投入全部轉向正確性與契約：KernelGen 單日 22 個運算元、單週多批自動生成已是常態；與之相對，本週最有價值的一批提交是 index_put 的 int32 偏移溢位、天數 bf16 GEMM 退回主機、海光 DCU 執行時由樁連結而成、燧原形狀表載入點缺失、崑崙芯後端無法匯入這類「測試裡不報錯、上線後才炸」的問題。ref-as-candidate 在雙倉落地與 57 筆測試修復，是把「測什麼」從有沒有運算元改成參考與實現是否一致的分水嶺。
  • 規則收斂的代價被推遲到 0.32 上兌現：0.28 跳過看起來壓掉了追小版本的成本，但 0.28 上已經合入的適配（燧原 S60、天數、沐曦、清微、崑崙芯）需要在 0.32 上重走驗收，這部分返工量目前沒有任何 PR 承載。同期 0.32 的第一份落地證據是原生 CUDA 的 vLLM 0.32 適配（釘 vLLM 0.32.0 加 cu129、PyTorch 2.13.0、Python 3.12.3），國產後端尚未開始。
  • 量子棧與多芯適配徹底解耦，成為獨立主線：FlagQuantum 一週合入 226 筆、佔組織三成，且從結構重整（QEC 包拆分、Quafu SDK 硬切換）轉入場景鋪開（糾錯碼、中性原子、熱浴），再收束到 CS-01 至 CS-07 的電路合成流水線；FlagQAI 同步做本地工作臺。它的作業方式是四段留證，成本高、可核查性好，也是唯一一條不依賴任何晶片廠商進度的軟體棧主線。
  • 三個風險項需要在下一期確認：其一，標籤缺釋出正文已成慣例——FlagCX v0.14.1 與 FlagTree 的兩條 3.6 專號都只有標籤，下游只能從名字反推後端與 Triton 版本，2.3 若按此線交付會增加核對成本；其二，寒武紀連續兩週在組織內無專屬推送，僅在 build-infra 留有撤回記錄，若下一期延續應單列；其三，訓練棧的恢復仍不確定——Megatron-LM-FL 在審十筆但本週期零合入，FlagScale 的 DeepSeek-V4 上游同步只開到 [2/N]，訓練側進度落後於推理側。
  • 下一觀察點：2.3.0 標籤何時打出、release-2.3.yaml 何時建立；0.32 單發規則下第一家國產後端（昇騰或海光）何時在 0.32 上完成驗收；BPU 路徑是否從逐元素運算元擴到卷積等主幹運算元；FlagCV 何時給出第一組基準與非 GPU 後端資料；Megatron-MUSA-Titan 的程式碼是否真正開始推送並與 Megatron-LM-FL 形成複用。

附錄：素材與核查

  • 素材：2026-10-26、10-27、10-28、10-29、10-30 五期 FlagOS 日報，視窗分別為 10-23 06:00 至 10-26 06:00（72 小時）、10-26 06:00 至 10-27 06:00、10-27 06:00 至 10-28 06:00、10-28 06:00 至 10-29 06:00、10-29 06:00 至 10-30 06:00，週期內無缺期。10-24 與 10-25 為週末，無獨立日報，其內容包含在 10-26 期的 72 小時視窗內。
  • GitHub 核查方法：對組織 flagos-ai 全部 61 個倉庫逐日核查推送狀態；合入以 is:merged 加 merged:>=視窗起點 檢索為真值，在審以 is:open 加 updated:>=視窗起點 檢索；主分支新增用 commits?sha=<分支>&since=<UTC> 複核；非預設分支推送由 org 事件流與 commits.atom 兜底分辨（本週期涉及 docs、release-info、FlagFFT、FlagSparse、FlagGems-Experimental、TransformerEngine-FL 等倉）。分倉合入數為各期日報披露口徑的累加，逐期分倉合計與各期合入總數完全一致，累計 755 筆。
  • 版本與標籤核查：以各元件倉庫的標籤與 Release 原子源逐一複核，10-31 複核結果為——FlagTree 0.7.1a1+mthreads3.6 的 tagger 時間為 10-26 10:13、0.7.1a1+tsingmicro3.6 為 10-29 11:09，兩者均無 Release 正文；FlagCX v0.14.1 為輕量標籤，指向 10-29 10:55 的合入提交（崑崙芯 cstddef 回摘），Releases 列表最近一條仍為 9-28 的 v0.14.0；build-infra 標籤列表最新仍為 v2.2.0；community 倉 release/2.3 目錄下無 release-2.3.yaml。FlagGems、FlagQuantum、FlagScale、FlagBLAS、FlagDNN、FlagFFT、FlagTensor、FlagAttention、vllm-plugin-FL、sglang-plugin-FL、FlagGems-sglang、TransformerEngine-FL 本週期無新 Release。
  • 新聞側核查：Google News RSS 24 組中英文查詢詞（元件名取 14 天、成員與產業詞取 7 天）逐期執行，五期合計 120 組查詢；HN Algolia 八組；CSDN FlagOS 專欄逐條核時；智源社群與八家成員單位官網每日巡檢。有效條目按「原站優先」引用；舊聞重發（燧原「今日上市」類稿，該公司科創板上市日為 9-11）、越窗稿（清微「年度科創先鋒」原文為 10-22）、會後傳播稿（輝羲智慧參會稿，指向 10-17 至 10-18 大會）與行情與財報類稿件按規則剔除，未計入條目。
  • 口徑說明：日期與時間均為北京時間。週一的 72 小時視窗覆蓋 10-24 與 10-25 週末，其內容按原始日期標註，與上一期週報（覆蓋 10-19 至 10-23）在 10-23 當日存在重疊，重疊部分的標籤與合入已在上一期列明，本期不重複計數。「合入」指 GitHub 檢索的合併時間落在視窗內的 PR，與日報逐日視窗計數存在一天左右的錯位，本報告統一採用合併日期口徑；提交檢索為 search 的 total_count 口徑，個別倉庫因壓縮合並與索引延遲會出現合入數高於提交檢索數的情況（如 10-27 期 FlagGems 49 筆合入對 28 筆提交），報告內以合入數為準。廠商通稿中的「Day-0」「無需改程式碼」「對齊或超過論文」等表述為公司口徑，未取得第三方復現；天垓 300 的 1.05 倍 H200 與 InfoQ 的成本測算均已註明限定條件。
  • 侷限：分支級活動（FlagTree 的 triton_v3.5.x 與 feature/flagmega 分支、FlagGems 的 kernelgen-dev 與 fix/* 臨時分支、FlagFFT 的 codex/musa-shortfall）無法以預設分支口徑完整列舉，按預設分支統計會低估實際工作量；FlagQuantum 的提交數含合併提交與分支同步提交，不等同於功能改動數；FlagGems-Experimental 的 135 筆批次 PR 截至本週期末全部處於在審狀態，是否批次合入、合入後是否迴流主倉運算元表仍待觀察；訓練側 Megatron-LM-FL 與 FlagScale 的動作稀疏，相關判斷的置信度低於推理棧。

參考文獻

//github.com/flagos-ai/FlagCX/pull/673> · https://github.com/flagos-ai/build-infra/pull/1556 · https://github.com/flagos-ai/build-infra/pull/1563

· https://github.com/flagos-ai/FlagGems/pull/7061 · https://github.com/flagos-ai/FlagGems/pull/6950

** FlagQuantum 包重組與 Quafu 切換 — https://github.com/flagos-ai/FlagQuantum/pull/749 · https://github.com/flagos-ai/FlagQuantum/pull/832 · https://github.com/flagos-ai/FlagQuantum/pull/866 · https://github.com/flagos-ai/FlagQuantum/pull/876

tp://stock.10jqka.com.cn/20261026/c681090455.shtml> · https://www.metax-tech.com/