調研視窗：過去 24 小時（2026-09-15 10:18 ~ 2026-09-16 10:18，北京時間） 信源：GitHub（org: flagos-ai，53 個倉庫 pushed_at 全量核查 + 單次 commit search 119 條按 committer-date 核驗 + 重點倉庫預設分支提交複核 + 各倉庫 releases/tags 後設資料 + community 釋出清單與釋出時間表 raw 直取 + 關鍵提交補丁詳情）、Google News RSS（中英文 24 組查詢詞，走代理）、HN Algolia、沐曦官網、觀點網、新浪財經、21 財經、財聯社、量子位、新華網、智源社群、CSDN FlagOS 社群等（詳見附錄信源清單）

本期索引

  • 今日重點：Torch-FL 六平臺轉向 FlagGems-first——PPU 路由條目從 11 條擴到 435 條（09-15/09-16）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 2.2 RC2 第二輪：FlagGems 升到 v5.4.0-rc2.post2，清單條目換版（09-15）
    • 1.2 Open3D-PIMC 首次程式碼落地：單次提交 662 個檔案，編譯層與執行時到齊（09-16）
    • 1.3 Torch-FL：六個平臺一起轉向 FlagGems-first（09-15/09-16）
    • 1.4 FlagAttention：SageAttention 與 GDN2 同日入庫，昇騰版單獨實現（09-15）
    • 1.5 FlagGems 量化運算元線：海光 W8A8 INT8 GEMM、摩爾執行緒 W8A16 FP8 RMSNorm（09-15）
    • 1.6 FlagGems KernelGen 批次入庫：二十個 Nvidia 運算元與崑崙芯 tle.gpu 遷移（09-15/09-16）
    • 1.7 推理外掛線：昇騰 SparseAttnSharedKV、persistent_topk 與 vLLM 0.24 適配（09-15/09-16）
    • 1.8 build-infra：FlagCX wheel 打包線開通，六條 vLLM 應用映象 tag 記錄（09-15）
    • 1.9 community：2.2 釋出治理自動化，狀態改由關聯 PR 推導（09-15/09-16）
    • 1.10 FlagSparse：外部分支合入主倉，昇騰精度收尾（09-15）
    • 1.11 FlagQuantum：Twin 證據按電路拓撲定級（09-15）
    • 1.12 其餘動態：FlagTree、flir、FlagDNN、FlagCX（09-15/09-16）
  • 二、新聞報道與生態
    • 2.1 元件級檢索第十二個連續平靜視窗：命中集中在成員單位而非元件（09-15~09-16）
    • 2.2 沐曦完成上海人工智慧實驗室 ATRIA Dawn Preview 的 Day0 適配（09-15）
    • 2.3 燧原科技科創板上市：資本側口徑與生態位的兩條讀法（09-15）
    • 2.4 Open3D-PIMC 從釋出到程式碼：媒體側與程式碼側的 48 小時時差（09-14~09-16）
  • 三、成員單位深挖
    • 3.1 清微智慧：Open3D-PIMC 程式碼落地與 3D 可重構路線的合流（09-16）
    • 3.2 海光：量化運算元、CI 映象與 FlagCX wheel 三線並行（09-15）
    • 3.3 摩爾執行緒：W8A16 FP8 RMSNorm 與 MUSA 路由雙向調整（09-15）
    • 3.4 沐曦：metax rc2 重建映象記錄與 Day0 適配敘事（09-15）
    • 3.5 燧原科技：S60 進 vLLM 0.24 線與 GCU CI 管線（09-15）
    • 3.6 天數智芯：iluvatar3.6 後端與 FlagTree 0.6.1 繫結（09-15）
    • 3.7 崑崙芯：sum 遷往 tle.gpu 與 paged-KV 約定修復（09-15）
    • 3.8 智源（牽頭方）：RC2 治理自動化與 2.2 進度對賬（09-15/09-16）
  • 四、總結與趨勢觀察
  • 附錄：完整信源清單

今日重點：Torch-FL 六平臺轉向 FlagGems-first——PPU 路由條目從 11 條擴到 435 條

日期：2026-09-15 至 2026-09-16　來源：Torch-FL #290 PPU 路由、Torch-FL #276 CUDA FlagGems-first、Torch-FL 運算元支援文件

本視窗最集中的工程動作發生在 Torch-FL：這個負責把 PyTorch 運算元呼叫分派到各晶片後端的適配層，在 24 小時內收到 12 次提交，把六個平臺一起推向「FlagGems 優先」。其中 PPU（達摩院玄鐵）一家的路由表變化最劇烈——FlagGems 路由條目從 11 條擴到 478 條，467 個過載從 cuda 移入 flaggems，沒有一條反向移動；隨後經過一次可執行性普查、兩輪 CI 暴露的路由相關失敗、以及一次原始碼級審計，落定為 435 條 FlagGems / 1601 條 cuda，即 482 個被 FlagGems 覆蓋的運算元中有 47 個被留在廠商核心上（33 個普查測出的路由相關失敗、mm/bmm 家族、五個 addmm 過載、_conj、四個反射填充路由）。

這次改動還順手堵掉一個結構性問題：PPU 的運算元全集原先是從 backends_cuda.conf 裡讀回來的，而 codegen_ops.py 會重寫這個檔案，等於讓 PPU 的運算元宇宙成為另一個平臺路由表的函式；現在改為讀 csrc/aten/generated/register.inc——CUDA 線與 PPU 線共同編譯的那份登錄檔，改完重生成九個 conf 全部位元組一致，證明是純溯源替換。倉庫同時把 47 個留下的運算元逐個寫進 BOXING_TRITON_GAPS 並附失敗描述，配置檔案的 SHA-256 也被記錄以保證可復現。

其餘五個平臺是同一方向的不同切面：CUDA 線（#276，18 個檔案、+1660/-533）改為在作業內安裝 FlagTree 0.6.2a2 與 FlagGems master 並承擔 FlagGems C++ 運算元的編譯，工作流超時相應從 60 分鐘提到 120 分鐘；DCU（#277）預設啟用 FlagTree 與 FlagGems；GCU（#285）走 FlagGems 加廠商回退；昇騰（#288）把流水線切到 FlagTree 並保留 dtype 回退；MUSA（#286）把四個原先判定為填隙的條目重新升回 FlagGems 路由。

把這條線放回 FlagOS 的命題看，它比任何單點運算元入庫都更接近核心目標：FlagOS 的立論是「一套運算元庫跨晶片複用」，而決定這一立論成立與否的正是分派層——有多少運算元真的走了 FlagGems 而不是悄悄落回廠商核心。本視窗給出的答案是：廠商核心仍在承接大頭（PPU 上 1601 對 435），但趨勢明確、且每一處例外都有具名理由。

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

視窗總覽：org 內 53 個倉庫中 20 個在視窗內有推送；單次 commit search 命中 119 條視窗內提交（4 頁，committer-date 降序），分佈於 17 個倉庫：FlagGems 43、build-infra 14、community 13、Torch-FL 12、FlagSparse 11、FlagGems-vllm 5、FlagGems-sglang 4、FlagQuantum 3、FlagAttention 3、sglang-plugin-FL 2、vllm-plugin-FL 2、FlagTree 2，以及 flir、FlagGems-Experimental、FlagCX、Open3D-PIMC、FlagDNN 各 1。另有 docs、release-info、FlagBLAS 三倉在視窗內有推送，但預設分支上無視窗內新提交（屬標籤或側分支推送，其中 docs 與 release-info 承擔釋出件站點同步）。

本視窗形態 = 「分派層重構」+「量化與注意力運算元加碼」兩條線並行：治理側由 FlagGems 的第二次 RC2 打標與 community 的釋出專案自動化推進 2.2 收口；工程側的重點從「往裡補運算元」轉向「讓運算元真的被走」——Torch-FL 的六平臺 FlagGems-first 是主幹，FlagGems 的量化運算元（W8A8 / W8A16）與 FlagAttention 的 SageAttention、GDN2 是新增產能。此外 Open3D-PIMC 在視窗末尾完成首次程式碼落地，是本期唯一的新增程式碼庫動作。

1.1 2.2 RC2 第二輪：FlagGems 升到 v5.4.0-rc2.post2，清單條目換版（09-15）

日期：2026-09-15　來源：community 提交 #110、FlagGems v5.4.0-rc2.post2

09-15 11:21，Release Manager 提交 release(2.2-rc2): bump flaggems to v5.4.0-rc2.post2 (#110)，清單中僅一行變化：FlagGems 由 v5.4.0-rc2.post1 換為 v5.4.0-rc2.post2。提交說明寫明瞭推動換版的兩處修復——flash_attention_backward 相容（#6253）與在 flagtree/3.5 線上給 tl.map_elementwise 加門控（#6236），新標籤指向分支頭 88acc0f7d。核對標籤時間線：rc2.post1 與 rc2.post2 均為該分支上的驗證快照，清單內其餘 24 個條目仍指 rc2.post1。這是 2.2 RC2 的第二次打標，距 09-28 GA 還有 13 天。

1.2 Open3D-PIMC 首次程式碼落地：單次提交 662 個檔案，編譯層與執行時到齊（09-16）

日期：2026-09-16　來源：Open3D-PIMC 首次提交、專案 README

09-16 09:30，org 內 08-15 建立後一直為空的 Open3D-PIMC 倉庫收到唯一一條根提交，一次性帶進 662 個條目。目錄結構顯示這不是提案文件而是可用工程：source/raisa-inductor/ 是編譯層（compiler.py、graph_manager.py、graph_executor.py，以及 passes/ 下的通訊運算元、融合、子圖三類 pass 與 utils/_graph_hash.py 的編譯快取鍵），runtime/rcs2/ 是 C++ 執行時（engine.cpp、l1_workspace.cpp、CMake 與 kernel.cmake），另帶 demo/test_compiler.py、envsetup.sh 與兩張架構圖。README 把專案的四個待補缺口寫得很清楚：記憶體層級的表達力、分片與拓撲的脫節、動態推理與整圖編譯的衝突、編譯產物的複用；對應解法是把分層分片、3D-DRAM 資料駐留、物件生命週期與 Graph/Eager 邊界提升為可驗證、可變換、可最佳化的 IR 語義。這承接 09-14 中國算力大會的開源釋出，完成了從「宣佈開源」到「程式碼上線」的落地。

1.3 Torch-FL：六個平臺一起轉向 FlagGems-first（09-15/09-16）

日期：2026-09-15 至 2026-09-16　來源：Torch-FL #290、Torch-FL #276、Torch-FL #285

詳見「今日重點」。補充兩點細節：其一是 PPU 作業的環境可復現性被徹底改寫——原先它靠執行器 pod 上的 /workspace/FlagGems 宿主掛載匯入 FlagGems，pod 一旦不帶該掛載，set_env_ppu.sh 就在環境準備階段以「FlagGems source is not available」退出、作業根本走不到運算元步驟；現在改為從 FlagOS 索引裝 FlagTree（0.6.2a2+ppu3.6）與從 git 裝 FlagGems master，環境只依賴映象加兩個索引。其二是 mm/bmm 仍被釘在廠商核心上，原因是 FlagGems 的 _hygon 核心會給 Triton 的 mm_kernel 傳 num_ldmatrixes 關鍵字而 PPU 版 Triton 不認，已作為 FlagGems #6225 上報。

1.4 FlagAttention：SageAttention 與 GDN2 同日入庫，昇騰版單獨實現（09-15）

日期：2026-09-15　來源：FlagAttention #43 SageAttention、FlagAttention #44 GDN2、FlagAttention #62 昇騰版

一天之內合入兩個新版運算元。#43 引入 SageAttention 的 Triton 實現（10 個檔案、+862/-7）：QK 走 INT8 逐塊量化、PV 走 FP16 前向，QK 量化與注意力前向兩個核心都使用 triton.experimental.tle.language，附帶覆蓋 1K 至 32K 序列長度的基準指令碼與對標逐頭參考實現的精度測試。#44 是最佳化後的 GDN2 運算元——線性注意力方向的當前熱點。#62 則為昇騰單獨實現 GDN2 與 SageAttention：入口按 torch.npu.is_available() 自動路由到 _ascend 後端，通用路徑再轉指該實現，避免兩處程式碼漂移；昇騰基準指令碼對照 AscendC 運算元測同一組形狀。這三條放在一起，說明 FlagAttention 已從「補齊注意力變體」轉向「跟隨最新推理模型的結構熱點」。

1.5 FlagGems 量化運算元線：海光 W8A8 INT8 GEMM、摩爾執行緒 W8A16 FP8 RMSNorm（09-15）

日期：2026-09-15　來源：FlagGems #6185 海光 W8A8、FlagGems #6210 摩爾執行緒 W8A16

海光線新增 mm_w8a8_int8 與 mm_w8a8_int8_out 兩個非 ATen 量化矩陣乘運算元（5 個檔案、+871）：輸入為已量化的 INT8 矩陣，配標量或按行/列縮放的 FP32 scale 與可選 bias，量化本身在運算元外完成，核心實現重點是 INT8 點積下的長 K 規約溢位保護；同時按 conf/operators.yaml 的規範補了運算元登記，stage 標為 5.4，與當前 RC 分支對齊。摩爾執行緒線則最佳化了 W8A16 FP8 RMSNorm 路徑（#6210）。此外 fix: enable TLE for Hygon（#6247）把海光加入 TLE 啟用名單，說明其後端開始使用 Triton 的語言擴充套件。三條合看，量化（W8A8 / W8A16）正在成為本輪運算元擴容的主線。

1.6 FlagGems KernelGen 批次入庫：二十個 Nvidia 運算元與崑崙芯 tle.gpu 遷移（09-15/09-16）

日期：2026-09-15 至 2026-09-16　來源：FlagGems #5722、FlagGems #6311 崑崙芯、FlagGems #6188 backends.yaml

KernelGen 產出的 Nvidia 運算元在本視窗成批進主倉，粗略計約二十個，覆蓋三類：線性代數類（cond、solve、eigvals、vander、multi_dot、powsum 等 linalg 系列）、特殊函式類（entr、切比雪夫多項式等）、以及注意力與訓練相關類（原生多頭注意力、量化 GRU、grid_sampler 二維取樣、三維上取樣反向、多處偽量化與嵌入袋稀疏反向、批歸一化反向規約等）。KMCompiler 線另補了 unsafe_index_put（Nvidia 與昇騰）、rnn_tanh 效能最佳化與 _dim_arange。崑崙芯側把 sum 與 sum_dim 遷移到 tle.gpu（#6311），並新增一個勒讓德多項式運算元。質量面上修掉了 linalg_svd 的 16×16 掛死（#6301）、addmv 標量 bias 的 dtype 不匹配（#6149）與 CI 容器的 shm/ipc 選項並更新了海光映象（#6304）；backends.yaml 也把 iluvatar 後端更新到 flagtree==0.6.1+iluvatar3.6（#6188）。

1.7 推理外掛線：昇騰 SparseAttnSharedKV、persistent_topk 與 vLLM 0.24 適配（09-15/09-16）

日期：2026-09-15 至 2026-09-16　來源：FlagGems-vllm #792 SparseAttnSharedKV、vllm-plugin-FL #464、sglang-plugin-FL #75 Hygon DCU CI

本視窗單筆最大的程式碼量來自昇騰的 SparseAttnSharedKV（#792，5 個檔案、+9637）：這是 DeepSeek-V4 稀疏注意力共享 KV 結構在昇騰上的 Triton 實現，固定驗證六個形狀——三個 decode 案例 KV 長度 8193、三個 prefill 案例 Q=KV=8192，常量集中在 64 個 Q 頭、1 個 KV 頭、頭維 512、頁大小 128，精度閾值 2e-2，測速以同裝置 AscendC 運算元為基準（5 次預熱、20 次取樣）並只作記錄不作斷言——即以精度作為驗收口徑。同線還補了昇騰 persistent_topk（segment-sort 加 merge 兩路）並把廠商 fused_moe / persistent_topk 收納到 ops/ 下，同時把 pre-commit 配置切到 gitcode 映象以適配國內網路。外掛側兩條升級：vllm-plugin-FL 把燧原 S60 適配到 vLLM 0.24 線（#464）並把崑崙芯升到 vLLM 0.24.0（#516）；sglang-plugin-FL 則為海光 DCU（BW1000）與燧原 GCU（S60）各建了 CI 管線（#75/#88），其中海光線用 AMD adaptor 構建 FlagCX v0.13.0（DCU 屬 HIP 譜系，DTK 自帶 librccl），e2e 用例矩陣與昇騰、MUSA 對齊。FlagGems-sglang 側把上游 FlagGems 的測試工具與 conftest 內建進倉（#76）。

1.8 build-infra：FlagCX wheel 打包線開通，六條 vLLM 應用映象 tag 記錄（09-15）

日期：2026-09-15　來源：build-infra #886、build-infra #895、build-infra #888

視窗內 build-infra 以 14 條提交成為第二活躍倉庫，主體是兩件事。第一件是新開 FlagCX wheel 打包線（#886 新增構建、校驗、釋出三步，#896 pin scm 節點寬度並給 MACA 配 cu-bridge 的 CUDA_PATH，#897 回退過度註釋，#899 讓 vllm-plugin wheel 構建保留 wheel 作為 run artifact）；其中 #895 記錄了一處環境坑：torch 的已安裝標頭檔案強制要求 gflags——torch/headeronly/macros/cmake_macros.h 直接定義了 C10_USE_GFLAGS，於是 c10/util/Flags.h 對每個消費者都 include <gflags/gflags.h>，而任何執行時映象都不帶該標頭檔案（在海光執行時映象上實測無 /usr/include/gflags），海光構建因此在編譯 backend_flagcx.cpp 時掛掉，故在構建映象內加裝 libgflags-dev 與 libgoogle-glog-dev。第二件是把六條 vLLM 應用映象 tag 入賬，統一為 2.1.2-0.2.2rc2.post1_gdb28502.d20260915，分別對應 metax-maca3.8.1.3、metax-maca3.7.2.1、ascend-cann9.0.0、ascend-cann8.5.0 及兩條 910c 變體（#888 至 #893），另補了 metax/ascend 0.20.2 rc2 重建的 changelog（#887）與崑崙芯 paged-KV 約定修復的記錄（#898）。

1.9 community：2.2 釋出治理自動化，狀態改由關聯 PR 推導（09-15/09-16）

日期：2026-09-15 至 2026-09-16　來源：community 2.2 專案同步工作流、community 提交 29a04c6e

在清單與打標之外，community 倉庫本視窗的 13 條提交幾乎全部用於把 2.2 的釋出狀態從人工看板搬進自動化。新增的 flagos-2.2-project-sync.yml 每 15 分鐘執行一次，把帶 flagos2.2-rc0/rc1/rc2 標籤的 issue（不分開關狀態）同步到組織的 GitHub Project #9，因預設的 Actions 令牌與舊的組織的令牌都缺 Projects 許可權，工作流顯式要求一個帶 project scope 的專用令牌。隨後一天的提交沿同一條鏈修：同步 issue、用關聯 PR 推導釋出狀態、把狀態與關聯 PR 對齊、加固對賬、保留被人工延期的 issue、把已指派的 triage issue 提升、規範排程週期、驗證 Actions 排程心跳、並補一條說明寫明 RC 的驗證規則。把這條鏈與 RC2 兩次打標並讀，能看出 2.2 的 Go/No-Go 正在從「人看清單」變成「由 issue 與 PR 狀態推導」，這也解釋了為什麼本視窗清單的每一次換版都能在半小時內落到標籤上。

1.10 FlagSparse：外部分支合入主倉，昇騰精度收尾（09-15）

日期：2026-09-15　來源：FlagSparse 提交列表

FlagSparse 本視窗的 11 條提交全部來自一條外部協作線：主倉以合併提交方式引入 NCIC-AlphaSparse/main 分支（#60），內容為昇騰精度調整（ascend accuracy refine、ascend refines）、CI 細化（兩輪 ci refine）、wrapper 與文件更新，以及多次跨倉同步合併。這說明稀疏運算元庫的推進由外部團隊主導、主倉承接，與 FlagAttention 由 org 內主線推進形成分工對照。

1.11 FlagQuantum：Twin 證據按電路拓撲定級（09-15）

日期：2026-09-15　來源：FlagQuantum #45、FlagQuantum #46

承接上一視窗的 Twin API 凍結，FlagQuantum 本視窗提交三次：跨電路比較 Twin 候選（#44）、按電路拓撲對 Twin 證據定級（#45）、組合相鄰的連通 Twin 區域（#46）。三步合起來是把量子處理器數字孿生的等價性判定從「單電路比對」推進到「按拓撲組織證據集」，屬歷史序列管理之後的方法學補齊。

1.12 其餘動態：FlagTree、flir、FlagDNN、FlagCX（09-15/09-16）

日期：2026-09-15 至 2026-09-16　來源：FlagTree #1178、FlagTree #1169、flir #75、FlagCX #599

FlagTree 兩筆：fix(hcu): allow extract_tile in the TLE whitelist（#1169）把海光線上的 extract_tile 放入 TLE 白名單，與 FlagGems 側「為海光啟用 TLE」同向；[Triton] Use triton version instead of llvm22 version（#1178）統一了版本標識口徑。同一改動也落在 flir（FlagTree IR，源自 microsoft/triton-shared）上（#75）。FlagDNN 修復了 Nvidia 後端的運算元實現。FlagCX 的 #599 修正了效能報告口徑：KV 等價吞吐不再用固定文字框數值，改為由實測的每請求 KV 位元組數計算。

二、新聞報道與生態

2.1 元件級檢索第十二個連續平靜視窗：命中集中在成員單位而非元件（09-15~09-16）

日期：2026-09-15 至 2026-09-16　來源：Google News RSS

以 FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、Open3D-PIMC 及 BAAI 側詞的中英文組合共 24 組查詢（中文 17 組、英文 7 組，when:7d 與 when:14d 兩檔）檢索，元件名查詢在視窗內全部零命中；放寬到成員單位與產業詞後共得 13 條視窗內結果，其中僅沐曦的 Day0 適配與燧原的上市行情與生態相關，其餘為股市行情、金融稿或無關內容。HN Algolia 對 FlagOS、FlagGems、FlagScale、BAAI 的查詢亦無有效技術討論。這是元件級新聞檢索連續第十二個平靜視窗，本期技術資訊面仍基本全部來自程式碼倉庫，並首次由 Torch-FL 的分派層改動提供了一條可獨立成篇的技術敘事。

2.2 沐曦完成上海人工智慧實驗室 ATRIA Dawn Preview 的 Day0 適配（09-15）

日期：2026-09-15　來源：沐曦官網、觀點網

09-14 上海人工智慧實驗室開源 ATRIA Dawn Preview 模型，沐曦同日宣佈憑藉自研通用 GPU 與 MXMACA 軟體棧率先完成該模型的 Day0 適配。公司口徑給出兩條累積資料：自 2025 年 12 月以來已完成 37 個主流旗艦模型的 Day0 適配，覆蓋智譜、阿里千問、MiniMax、DeepSeek、階躍星辰、騰訊混元等；MXMACA 軟體棧相容 40 餘種 AI 框架、1000 多款模型，適配超 6000 個開源專案測試，全量支援 PyTorch 2.8 的 2410 個 GPU 運算元。需要區分的是：這條適配走的是廠商自有軟體棧，與 FlagOS 裡 metax 後端（Torch-FL 的 metax 路由、FlagGems 的 metax 後端）是兩條並行路徑；把兩者並讀，才能看出成員單位在「自有棧爭 Day0」與「共建統一棧」上的雙線投入。

2.3 燧原科技科創板上市：資本側口徑與生態位的兩條讀法（09-15）

日期：2026-09-15　來源：21 財經、同花順、財聯社

燧原科技 09-11 登陸科創板後，相關解讀在視窗內持續發酵：發行價 142.18 元，上市首日開盤 410 元、開盤漲幅 188.37%，盤中最高 475 元，收盤 397 元、漲幅 179.22%，對應市值 1708.5 億元，募資 61.4 億元；2023 至 2025 年營收 3.01 億、7.22 億、9.90 億元，2026 上半年 11.20 億元、同比增長 279.08%，三年歸母淨虧損合計逾 43 億元，未彌補虧損 44.41 億元，公司自估 2026 或 2027 年有望盈利。作為 FlagOS 成員單位，燧原在生態側的對應動作是程式碼而非行情：本視窗其 enflame 後端同時出現在 FlagGems 運算元線、vLLM 0.24 適配線與 sglang 的 GCU CI 上。資本敘事回答的是「能不能持續投入」，程式碼提交回答的是「投入落到哪裡」，兩者本期都指向雲端推理。

2.4 Open3D-PIMC 從釋出到程式碼：媒體側與程式碼側的 48 小時時差（09-14~09-16）

日期：2026-09-14 至 2026-09-16　來源：新華網、倉庫首次提交

09-14 中國算力大會宣佈 Open3D-PIMC 開源釋出時，倉庫內並無程式碼；到 09-16 09:30 才出現唯一一條根提交，一次性帶進 662 個條目（編譯層、C++ 執行時、示例與架構圖）。媒體側的表述是「程式碼已上線開源社群」「今年四季度將在全球科技頂會發布面向 3D 晶片算力的最新最佳化成果」，程式碼側的時間戳則顯示上線發生在釋出後約 44 小時。這不構成矛盾，但提示了一種讀法：面向新一代晶片形態的專案，其「釋出」是路線宣告，真正的可用性要看倉庫後續的提交節奏——本報告此後會把它納入常規巡檢。

三、成員單位深挖

3.1 清微智慧：Open3D-PIMC 程式碼落地與 3D 可重構路線的合流（09-16）

日期：2026-09-16　來源：Open3D-PIMC README、清華大學官網

清微智慧本期在 org 內的動作是 Open3D-PIMC 首次程式碼提交。從落地內容看，其技術主張與公司的可重構路線是同一條線：README 把 3D-DRAM 堆疊後的核心問題定位為「資料住在哪一層記憶體、張量如何在 Chiplet/Die/Tile 間分佈、計算與通訊能否在正確的時間點協同排程」，而不再是單運算元吞吐；提出的解法是把分層分片、N3D 資料駐留、物件生命週期與 Graph/Eager 邊界寫進 IR，並允許廠商以外掛形式提供成本模型、排程器與程式碼生成，保持前端、IR 與執行時 ABI 相容。raisa-inductor 這一命名與 runtime/rcs2 的 C++ 引擎，說明落地的是自研編譯與執行時棧的對外開源版本。結合公開資訊給出的路線圖（第二代 3D 可重構晶片即將量產流片、累計算力卡訂單超 3 萬張、十餘省區千卡級智算中心落地），清微在 FlagOS 生態中的定位仍是一致的：不做補齊型運算元貢獻者，而在下一代晶片形態上爭取軟體定義權。

3.2 海光：量化運算元、CI 映象與 FlagCX wheel 三線並行（09-15）

日期：2026-09-15　來源：FlagGems #6185、FlagGems #6247、build-infra #895

海光是本視窗工程量最分散但也最完整的一家：運算元側加入 W8A8 INT8 量化矩陣乘（含 _out 變體）並把海光納入 TLE 啟用名單；FlagTree 側為海光線放行 extract_tile 的白名單；CI 側恢復容器的 shm/ipc 選項並更新映象；打包側則因海光構建在編譯 backend_flagcx.cpp 時缺 gflags 標頭檔案而把 libgflags-dev 加進 FlagCX 的 wheel 構建映象；此外 Torch-FL 的 DCU 線也把 FlagTree 與 FlagGems 設為預設啟用。把五處並讀，海光當前的瓶頸不在「缺運算元」，而在工具鏈與打包環境的適配——這類問題數量多、單點價值低，但正是跨晶片可用性的實際門檻。

3.3 摩爾執行緒：W8A16 FP8 RMSNorm 與 MUSA 路由雙向調整（09-15）

日期：2026-09-15　來源：FlagGems #6210、Torch-FL #286

摩爾執行緒本期兩處動作方向相反但邏輯一致：一是 FlagGems 側最佳化 W8A16 FP8 的 RMSNorm 路徑，屬於把已有運算元做深；二是 Torch-FL 側把四個此前被判定為「MUSA 填隙」的條目重新升回 FlagGems 路由，即把原先讓給廠商核心的運算元收回來。前者是產能，後者是覆蓋面，兩者合起來說明 MUSA 後端已越過「能跑」階段，開始處理分派層的例外清單。

3.4 沐曦：metax rc2 重建映象記錄與 Day0 適配敘事（09-15）

日期：2026-09-15　來源：build-infra #888、build-infra #887、沐曦官網

沐曦本期在 org 內的動作集中在釋出件：build-infra 為 metax-maca3.8.1.3 與 metax-maca3.7.2.1 兩個執行時組合各記錄了一條應用映象 tag，並補了 metax/ascend 0.20.2 rc2 重建的 changelog 條目——兩條 MACA 版本線並列入賬，說明其驅動棧的支援寬度被明確保留。四天前其 vllm-plugin-FL 的 metax CI 與 vLLM 0.24.0 升級也屬同一條推理棧努力。對外一側則是 2.2 條所述的 Day0 適配，走的是自有 MXMACA 棧。對 FlagOS 而言更關鍵的是前一條：映象 tag 的入賬使 metax 側的多晶片驗收具備可復現的基準。

3.5 燧原科技：S60 進 vLLM 0.24 線與 GCU CI 管線（09-15）

日期：2026-09-15　來源：vllm-plugin-FL #464、sglang-plugin-FL #88

燧原本期兩筆均為適配動作：vllm-plugin-FL 把 Enflame S60 適配到 vLLM 0.24 線，sglang-plugin-FL 則為 GCU（S60）建立 CI 管線。兩條一起看，S60 在 FlagOS 內的推理路徑覆蓋從 vLLM 擴到 sglang，且兩者都帶了 CI——這與本視窗的整體節奏一致：成員單位的新晶片接入不再止於運算元入庫，而要同時提供可執行的端到端流水線。結合 2.3 的資本側資訊，其研發投入的落點可以從這類提交裡直接讀到。

3.6 天數智芯：iluvatar3.6 後端與 FlagTree 0.6.1 繫結（09-15）

日期：2026-09-15　來源：FlagGems #6188

天數智芯本期的動作是一條 CI 配置提交：FlagGems 的 backends.yaml 將其後端更新為 flagtree==0.6.1+iluvatar3.6，把 iluvatar 後端與 FlagTree 的指定構建版本繫結。單筆提交的資訊量不大，但它是理解 2.2 驗收矩陣的一條線索——各廠商後端的可用性實際上取決於「FlagGems 版本 + FlagTree 構建變體 + 廠商驅動」三者組合，而這類組合正被逐個寫進配置以保證可復現。

3.7 崑崙芯：sum 遷往 tle.gpu 與 paged-KV 約定修復（09-15）

日期：2026-09-15　來源：FlagGems #6311、build-infra #898、vllm-plugin-FL #516

崑崙芯本期三條動作方向一致：FlagGems 側把 sum 與 sum_dim 遷移到 tle.gpu 路徑，新增 special_legendre_polynomial_p 運算元；推理側把 vllm-plugin-FL 升級到 vLLM 0.24.0；build-infra 則記錄了其 paged-KV 約定的修復。sum 這類基礎規約運算元從通用實現遷到 TLE 路徑，意味著崑崙芯後端已進入「用語言擴充套件壓效能」的階段，而非僅追求可用。

3.8 智源（牽頭方）：RC2 治理自動化與 2.2 進度對賬（09-15/09-16）

日期：2026-09-15 至 2026-09-16　來源：community 提交列表、2.2 釋出時間表

牽頭方本視窗的動作全部落在治理面：先是 FlagGems 的 RC2 第二輪換版（清單一行、標籤一次，半小時內完成），隨後是 13 條 community 提交把 2.2 的釋出狀態同步搬進 GitHub Project 並由關聯 PR 推導。對照時間表，當前仍處測試與穩定期（09-01 至 09-24），GA 定在 09-28，畢業標準是各 FEP 的可執行 Test Plan 在多晶片矩陣上驗收透過。值得記下的是本次治理改造的一個細節：工作流顯式宣告需要帶 project scope 的專用令牌，因為預設令牌與舊組織令牌都不具備 Projects 許可權——這類「把流程寫進程式碼」的改動不會出現在任何釋出說明裡，但決定了 RC 期間 25 個條目能否被逐項追蹤。

四、總結與趨勢觀察

  • 分派層成為本期主戰場：Torch-FL 一天內把六個平臺推向 FlagGems-first，PPU 從 11 條路由擴到 435 條並逐條記錄留在廠商核心上的 47 個運算元及原因。FlagOS 的核心承諾是「一套運算元庫跨晶片複用」，而分派層正是這句承諾的兌現處；本期首次出現了對這一層的完整、可審計的量化口徑。
  • 量化運算元與注意力變體是新增產能的兩端：FlagGems 側海光的 W8A8 INT8 GEMM 與摩爾執行緒的 W8A16 FP8 RMSNorm，FlagAttention 側 SageAttention（QK INT8 逐塊量化）與 GDN2，昇騰側的 SparseAttnSharedKV（DeepSeek-V4 稀疏注意力、頭維 512）。這些運算元的共同點是直接對應當前推理模型的真實結構，而非測試套件的覆蓋率。
  • 釋出治理從清單走向自動化：RC2 的第二次打標只改了一行清單，隨即由 new 工作流把 issue 狀態與關聯 PR 對齊；Go/No-Go 的依據正在從「人看清單」轉為「狀態可推導」。距 09-28 GA 還有 13 天，值得觀察這條鏈在最後一週是否穩定。
  • 生態側從「適配晶片」走向「定義硬體形態」的第二步：Open3D-PIMC 在釋出 44 小時後完成程式碼落地，帶進面向 3D-DRAM 近存計算的分層 IR、編譯層與 C++ 執行時。它不進 2.2 的驗收範圍，但決定了 FlagOS 在下一代晶片形態上的位置。
  • 新聞面連續第十二個平靜視窗：元件級檢索零命中，成員單位側的可見新聞集中在資本市場與自有棧的 Day0 適配。技術進展的觀察視窗已完全落在程式碼倉庫，這也意味著日報的價值正在從「彙總報道」轉為「解讀提交」。

附錄：信源核查表

信源 核查結果
GitHub org flagos-ai 53 個倉庫全量核查 pushed_at，20 個在視窗內有推送；commit search 命中 119 條視窗內提交，分佈 17 個倉庫
GitHub releases / tags 核對 FlagGems、FlagTree、FlagCX、FlagAttention、vllm-plugin-FL、FlagSparse、FlagScale、KernelGen、Torch-FL、FlagQuantum、build-infra、community 十二個倉庫；視窗內新增標籤為 FlagGems v5.4.0-rc2.post2；無新 GitHub Release
community 釋出清單 2.2 RC2 清單 25 條目（L0~L3 四層），FlagGems 換版為 rc2.post2，其餘仍指 rc2.post1；時間表 GA 為 09-28
Google News RSS（中文 17 組） 元件名查詢零命中；成員單位與產業詞得 13 條視窗內結果，剔除行情與無關稿後保留 2 條
Google News RSS（英文 7 組） FlagOS、FlagGems、BAAI FlagOS、flagos-ai 等查詢視窗內零命中
HN Algolia FlagOS、FlagGems、FlagScale、BAAI 查詢無視窗內有效技術討論
智源社群（hub.baai.ac.cn） 直連可用，檢索與首頁均無 FlagOS 相關視窗內條目
CSDN FlagOS 社群 直連可用，最新文章日期止於 09-10，視窗內無更新
沐曦官網 / 觀點網 / 新浪財經 確認 ATRIA Dawn Preview 的 Day0 適配（事件 09-14，報道 09-15 11:17 在視窗內）
21 財經 / 同花順 / 財聯社 / 杭州網 確認燧原科技科創板上市首日資料（事件 09-11，解讀稿在視窗內持續）
新華網 確認 Open3D-PIMC 於中國算力大會開源釋出（09-14），與 09-16 程式碼落地形成對照

完整信源清單

[22] FlagGems #6149（修復 addmv dtype 不匹配） — https://github.com/flagos-ai/FlagGems/pull/6149

s-ai/FlagQuantum/pull/45>