調研視窗：過去 24 小時（2026-09-16 10:18 ~ 2026-09-17 11:40，北京時間） 信源：GitHub（org: flagos-ai，54 個倉庫 pushed_at 全量核查 + 單次 commit search 150 條按 committer-date 核驗 + 重點倉庫預設分支提交複核 + tags/releases 後設資料 + community 釋出清單與釋出時間表 raw 直取 + 關鍵提交補丁與檔案清單詳情）、Google News RSS（中英文 33 組查詢詞，走代理）、HN Algolia、投資界、智源社群、新浪財經、雷峰網、集微網等（詳見附錄信源清單）

本期索引

  • 今日重點：build-infra 把版本欄位從 2.1.2 抬到 2.2.0——2.2 GA 前的最後一個全域性開關被撥動（09-17）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 build-infra：base 版本 2.1.2 到 2.2.0，FlagGems 鎖定 5.4.0-rc2.post2（09-17）
    • 1.2 FlagTrain 新倉庫落位：訓練側出現一個空的佔位倉（09-16）
    • 1.3 FlagFFT：36 個 FFT 運算元一次性驗收，配 NumPy 獨立校驗與執行時計劃（09-16）
    • 1.4 FlagGems 運算元擴容：KernelGen 十八個 Nvidia 運算元入庫（09-16/09-17）
    • 1.5 FlagGems 量化運算元線：摩爾執行緒原生 FP8 W8A8 MM、沐曦 W8A16 RMSNorm（09-16/09-17）
    • 1.6 FlagGems-vllm：融合 Marlin MoE 與 FP8 變長 FlashAttention-2（09-16/09-17）
    • 1.7 Torch-FL：從「路由切換」轉入「切換後果修復」（09-16/09-17）
    • 1.8 FlagTree：FlagTune 託管 Manifest 與 iluvatar3.6 基線工作流（09-16/09-17）
    • 1.9 FlagQuantum：接入 JAX 測試，覆蓋率下限抬到 60%（09-17）
    • 1.10 FlagCX 與 vllm-plugin-FL：PTD 日誌流式化、T-Head PPU CI 接入（09-16/09-17）
    • 1.11 其餘動態：community、FlagGems-Experimental、flir、FlagScale-Agent、映象 tag 記錄（09-16/09-17）
  • 二、新聞報道與生態
    • 2.1 元件級檢索第十三個連續平靜視窗：24 小時內零命中（09-16~09-17）
    • 2.2 FlagOS 2.2 時間表與 RC2 清單複核：GA 定檔 09-28（09-17 核查）
    • 2.3 地平線體系：地瓜機器人完成 4 億美元 C 輪融資（09-17）
    • 2.4 成員單位資本面：沐曦中報扭虧、燧原上市首日市值破千億、國產 GPU 半年報（09-16~09-17）
  • 三、成員單位深挖
    • 3.1 海光：linalg 與 dtype 語義兩端同時補齊（09-16）
    • 3.2 昇騰：MoE 與線性注意力所需運算元最密的一條線（09-16/09-17）
    • 3.3 達摩院玄鐵：推理外掛接入 PPU CI，MM/MV 支援 NN/NT 佈局（09-16/09-17）
    • 3.4 摩爾執行緒：原生 FP8 W8A8 MM 與 MUSA 旋轉位置編碼回裝置側（09-16/09-17）
    • 3.5 沐曦：W8A16 RMSNorm 與三處路由繞行（09-16/09-17）
    • 3.6 崑崙芯：xCCL 裝進基礎映象，運算元修復批次落地（09-17）
    • 3.7 天數智芯：/dev/itrctl 與 iluvatar3.6 基線工作流（09-17）
    • 3.8 燧原：GCU300 記錄進 0.24.0 報告與兩條映象 tag（09-16）
    • 3.9 智源（牽頭方）：治理自動化與版本號抬升（09-16/09-17）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表
  • 附錄：完整信源清單

今日重點：build-infra 把版本欄位從 2.1.2 抬到 2.2.0——2.2 GA 前的最後一個全域性開關

日期：2026-09-17　來源：build-infra #916 版本抬升、build-infra configs.yaml、FlagOS 2.2 釋出時間表

09-17 08:49，build-infra 收到一條只有兩行改動的提交 Bump base version to 2.2.0 (#916)：configs.yaml 裡的 version 由 2.1.2 改為 2.2.0，同一處的 flaggems 由 5.3.5 改為 5.4.0-rc2.post2。

這兩行的分量來自該檔案自身的定位。檔案頭部寫明它是「所以廠商/後端依賴與構建設定的唯一事實來源（single source of truth）」，被 scripts/build_base.py 與 scripts/build_runtime.py 讀取；version 欄位負責給全部基礎映象與應用映象打標籤（flagos-base-{廠商}-{後端}:{版本} 與 flagos-runtime-{廠商}-{後端}:{版本}），註釋裡把釋出動作寫成三步：更新這兩個欄位、打 v<版本> 標籤、結束。也就是說，前一日各模組的 rc 打標只是把候選版本推到驗證位，而這一次抬升把整條映象線指向 2.2.0，是 2.2 GA 之前 org 內唯一的全域性開關。

與其他證據對照，節奏吻合：community 的 2.2 釋出時間表把特性凍結定在 08-31、測試與穩定期定在 09-01 至 09-24、GA 定在 2026-09-28，milestone「FlagOS 2.2」當前 7 個 issue 均未關閉、到期日同樣是 09-28；RC2 清單中 24 個模組條目裡只有 FlagGems 打到 v5.4.0-rc2.post2，其餘仍是 rc2.post1。build-infra 倉庫自身的最新標籤仍是 v2.2.0 之前的 v2.1.1，說明映象標籤尚未落下——距 GA 還有 11 天，留給多晶片驗收的時間窗正在收窄。

值得注意的是同步性：同一天 build-infra 還提交了崑崙芯基礎映象安裝 xCCL（#917）與 containerfile 修正（#918），兩條都是在 2.2 映象線凍結前補齊廠商依賴，屬典型的「釋出前一公里」動作。

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

視窗總覽：org 內 54 個倉庫中 19 個在視窗內有推送；單次 commit search 命中 150 條視窗內提交（兩頁，committer-date 降序，已取全量），分佈於 15 個倉庫：FlagGems 71、build-infra 18、Torch-FL 17、FlagGems-sglang 10、FlagTree 8、FlagFFT 7、FlagGems-Experimental 5、FlagGems-vllm 4、FlagQuantum 2、vllm-plugin-FL 2、community 2，以及 FlagCX、FlagTrain、FlagScale-Agent、flir 各 1。另有 docs、release-info、sglang-plugin-FL、TransformerEngine-FL 四倉在視窗內有推送，但預設分支上無視窗內新提交（屬側分支或標籤推送，其中 docs 與 release-info 承擔釋出件與文件站點同步）。

本視窗形態 = 「釋出件凍結」+「切換後果修復」兩條線：治理側由 build-infra 抬版本號、community 同步釋出優先順序收口 2.2；工程側的注意力從「往運算元庫里加運算元」轉向兩類收尾工作——一是把新入庫的運算元登記進規範（匯出檢查、測試標記、基準對齊），二是接住上週路由切換在各晶片平臺暴露出來的具體問題（MetaX 的切片運算元、MUSA 的複數旋轉位置編碼與隨機數橋、CUDA 缺少 FlagTune）。FlagTrain 是本期唯一的新增倉庫，但目前只是佔位。

1.1 build-infra：base 版本 2.1.2 到 2.2.0，FlagGems 鎖定 5.4.0-rc2.post2（09-17）

日期：2026-09-17　來源：build-infra #916、build-infra configs.yaml

詳見「今日重點」。補充一處對照價值：flaggems 欄位從 5.3.5 直接跨到 5.4.0-rc2.post2，跨越了一個小版本與兩輪 rc，說明 2.1.2 映象線此前繫結的運算元庫與 2.2 候選之間已經隔了較長的驗證距離；而 build-infra 倉庫的最新標籤仍停在 v2.1.1，v2.2.0 標籤尚未出現，可作後續日報的觀察點。

1.2 FlagTrain 新倉庫落位：訓練側出現一個空的佔位倉（09-16）

日期：2026-09-16　來源：FlagTrain 倉庫

09-16 15:02，org 內新增倉庫 FlagTrain，建倉與唯一一條提交（Initial commit）相隔不到一秒，倉庫規模 5 KB、無描述、無語言統計、README 僅一行標題——是典型的佔位建倉。命名上它落在 FlagOS 的訓練側：該方向現有 FlagScale（訓練框架入口）、Megatron-LM-FL 與 TransformerEngine-FL（訓練核心與並行運算元）、FlagScale-Agent（自動化調優），新倉庫的定位要等 README 與目錄填充後才能判斷，但「訓練側又切出一塊」的動作本身值得記錄。按 org 慣例（FlagSparse、Open3D-PIMC 均是先建倉、後批次落地），程式碼落位通常在建倉後數日到數週內發生。

1.3 FlagFFT：36 個 FFT 運算元一次性驗收，配 NumPy 獨立校驗與執行時計劃（09-16）

日期：2026-09-16　來源：FlagFFT 運算元驗收提交、FlagFFT 倉庫

09-16 15:38，FlagFFT 收到一條 +2151/-2298 的提交 feat: accept 36 FFT operators with NumPy validation and runtime plans，一次把 36 個 FFT 運算元轉入驗收態，改動落在 8 個檔案：運算元清單與測試矩陣兩份配置、構建宣告、驗收測試執行器，以及一對專門用於獨立校驗的參考實現工具（C++ 側負責捕獲基準輸出，Python 側做逐運算元比對）。隨後兩小時內又補了兩條配套提交：test: enforce complete acceptance coverage and update CI reporting（15:44）把驗收覆蓋寫成強制項並改 CI 報告口徑，fix: preserve report compatibility and test interruption handling（15:58）修報告相容性與中斷處理。

把三條並讀，FlagFFT 這一輪的實質變化不是「多了 36 個運算元」，而是驗收標準升級：用獨立捕獲的 NumPy 輸出作為參考實現，配合執行時計劃（runtime plans）逐條比對，而不是自證式單測。在 RC2 清單中 FlagFFT 的候選版本是 v0.2.0-rc2.post1，這條驗收線正是它從 rc 走向 GA 的依據。

1.4 FlagGems 運算元擴容：KernelGen 十八個 Nvidia 運算元入庫（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagGems 倉庫提交、FlagGems #6135 histogramdd、FlagGems #5961 slice_copy

視窗內 KernelGen 線以每天十餘條的速度繼續向主倉灌入 Nvidia 運算元，帶 Triton 核心的新入庫運算元共 18 個，覆蓋四類：形狀與索引類（降維、切片複製、通道洗牌、同形狀判定、按維取值）、線性代數與特殊函式類（張量求逆、行列式對數、Sobol 序列、指數函式）、訓練與反向類（跡反向、掩碼軟最大反向、稀疏嵌入反向、隨機丟棄）、以及池化與取樣類（分數階三維池化、最近鄰三維上取樣反向）。型別分佈與前一視窗一致——線性代數、特殊函式、訓練用反向運算元各佔一段。

真正體現工程量的是隨之而來的登記與測試規範三條：一條給運算元匯出加排序與一致性檢查，一條把「使用 FlagGems 替代 ATen」的檢查限縮到本次新增行、避免歷史程式碼干擾，還有一條按命名約定自動推導下劃線運算元的測試標記。另有一條 [Test] Align MM tests and parallel FP8 benchmark with scaled-MM API（#6329）在測試側對齊縮放矩陣乘的介面。批次入庫的副作用是「登記成本」上升，這幾條正是在把成本固化到 CI 裡。

1.5 FlagGems 量化運算元線：摩爾執行緒原生 FP8 W8A8 MM、沐曦 W8A16 RMSNorm（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagGems #6211 摩爾執行緒 FP8 W8A8、FlagGems #6326 沐曦 W8A16 RMSNorm、FlagGems #4412 FP8 topk

摩爾執行緒線新增原生 FP8 W8A8 矩陣乘後端（#6211，5 個檔案、+1100/-80）：在摩爾執行緒後端的量化矩陣乘目錄下實現廠商原生路徑，與 Nvidia Hopper 版並列存在，並配齊基準指令碼與測試，說明該路徑以「貼近硬體的原生實現」而非「通用核心加回退」的方式交付。沐曦線新增 W8A16 RMSNorm（#6326），把量化範圍從矩陣乘擴到歸一化層；同期還最佳化了 FP8 topk 的選路（#4412）。加上測試側對縮放矩陣乘 API 的對齊與 fix ops bugs（#6259）的批次修復，本視窗與量化直接相關的提交共 7 條。合看，W8A8/W8A16 的覆蓋正在從「矩陣乘一層」向歸一化、取樣等相鄰運算元擴散，符合 2.2 把量化運算元作為擴容主線的定位。

1.6 FlagGems-vllm：融合 Marlin MoE 與 FP8 變長 FlashAttention-2（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagGems-vllm #750 融合 Marlin MoE、FlagGems-vllm #749 FP8 變長注意力

兩條大改動用同一個思路落到推理運算元層。其一 [QC] Add INT8 and FP8 W8A16 fused Marlin MoE（#750，7 個檔案、+3118/-46）新增 INT8 與 FP8 兩種 W8A16 權重的融合 Marlin MoE 運算元，附帶兩份基準指令碼、一份測試與 Nvidia 後端的調優配置 tune_configs.yaml，並更新了運算元選擇工具。其二 [QC] Add FP8 W8A8 variable-length FlashAttention-2（#749，5 個檔案、+4710）補上變長序列的 FP8 FlashAttention-2，覆蓋預填充階段最常見的形狀，同時登記進 conf/operators.yaml。

兩個運算元都指向同一類缺口：推理側的量化運算元此前集中在固定形狀與稠密路徑，而實際服務裡變長批與 MoE 稀疏啟用才是主流形態。這類運算元的驗收門檻也更高——兩份基準與調優配置同時入庫，意味著它們是以「可調優、可復現」而非「能跑」的標準交付的。

1.7 Torch-FL：從「路由切換」轉入「切換後果修復」（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：Torch-FL #306 MetaX 繞行、Torch-FL #316 MUSA 旋轉位置編碼、Torch-FL #310 釘回 FlagGems master

前一視窗的主體動作是把六個平臺的運算元分派轉向「FlagGems 優先」，本視窗的 17 條提交幾乎都是這次切換的迴響，按處理方式可分三類。

第一類是具名繞行：MetaX 上把 slice.Tensor 從 FlagGems 路由移出、並藉此打通 Qwen-Image-2512 的手動測試流（#306）；MUSA 上讓複數形式的旋轉位置編碼運算元留在裝置側執行（#316，8 個檔案、+99/-7，含 csrc/aten/backends/musa/ 下的生成程式碼與 codegen_mudnn.py 的生成規則），同時重綁廠商運算元模組上的隨機數橋（#298）。第二類是顯式開關：因上游 FlagGems master 出現迴歸，臨時把 CI 釘回上一個可用提交（#310）；CUDA 線上在 FlagTree 帶出 FlagTune 之前先設 USE_FLAGTUNE=0（#311）；把構建期的加速器配置寫進 wheel（#314，含單元測試），避免安裝後才知道構建目標。第三類是門禁建設：運算元測試門禁裡顯式探測 PPU（#309）、PPU 測試清單改從 ppu.yml 讀取而非內嵌 JSON（#305）、平臺流水線統一掛在平臺無關檢查之後（#304），以及 CI 全平臺跟蹤 FlagGems master（#301）。

三類合看是一套可複用的應對模式：能修的走路由繞行並留下測試，不能修的用顯式開關擋住，最後把判斷依據收進門禁。對「一套運算元庫跨晶片複用」這個命題來說，繞行名單的長度本身就是可用性的度量表。

1.8 FlagTree：FlagTune 託管 Manifest 與 iluvatar3.6 基線工作流（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagTree #1103 FlagTune 託管 Manifest、FlagTree #1197 天數基線工作流、FlagTree #1190 PPU 基準結果

主改動是 FlagTune（自動調優子系統）的一次大修（#1103，17 個檔案、+687/-153）：新增託管 Manifest 預設值與執行時相容處理，改動面覆蓋合約層（運算元模式與表示式定義）、搜尋層（遺傳演算法搜尋與介面約定）、執行層（自動調優器、基準協議、裝置抽象與錯誤定義），並配了四組測試（基準協議、模型檔案、模型來源、執行時錯誤）。所謂託管預設值，意味著調優配置的預設不再依賴本地生成，而是由一處統一提供，這對多晶片、多 Triton 版本的組合尤其重要。

配套的工程線同日推進：為天數智芯加 iluvatar3.6 的 FlagGems 基線與測試工作流（#1197），更新 PPU 基準結果（#1190），把 FlagGems 測試模板的後端初始化抽成統一介面（#1192），給 hcu 線的基準指令碼改用清理熔斷程序的指令碼（#1188），以及對偶發失敗的昇騰 TLE 用例加忽略（#1185）。

1.9 FlagQuantum：接入 JAX 測試，覆蓋率下限抬到 60%（09-17）

日期：2026-09-17　來源：FlagQuantum #48 JAX 測試與覆蓋率下限

09-17 11:05，FlagQuantum 收到 +429/-5 的提交，把 JAX 測試正式接入持續整合：新增一個混合前端測試與五個單元測試（批次拉回、MPS 核心、狀態向量核心、張量網路收縮、張量網路核心），持續整合工作流與測試配置同步更新，並把覆蓋率下限 60% 寫進合約目錄下的覆蓋率策略檔案——即質量閾值以合約檔案而非工作流引數的形式固定下來。該倉庫定位為「PyTorch 優先的量子 AI 框架」，接入 JAX 說明它在把第二個前端納入同等驗收標準，這與 FlagOS 各模組普遍「先定合約、再補實現」的做法一致。

1.10 FlagCX 與 vllm-plugin-FL：PTD 日誌流式化、T-Head PPU CI 接入（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagCX #601 PTD 日誌流式化、vllm-plugin-FL #518 達摩院玄鐵 PPU CI、vllm-plugin-FL #528 崑崙芯修復

FlagCX 的改動小而關鍵：跨晶片通訊庫的效能工具 PTD 在把日誌轉成 OpenMetrics 時一次性把整份日誌讀進記憶體，prepare 階段在大規模執行下會因記憶體耗盡退出；#601 把轉換改成流式處理（tools/PTD/src/prom2openmetrics.py，+68/-29），代價是多一層狀態機，收益是工具本身不再成為壓測規模的瓶頸。

推理外掛線兩筆：達摩院玄鐵 PPU 的 CI 正式接入（#518，9 個檔案），新增平臺配置 configs/thead.yml、環境準備與檢查指令碼、映象 docker/thead/Dockerfile 與平臺測試清單 tests/platforms/thead.yaml，並順帶修正 MetaX 平臺清單與清理工具；崑崙芯側修掉 FlashAttention 模組匯入失敗後殘留的狀態汙染（#528）。把 PPU CI 的接入與本報告 1.7 中 Torch-FL 對 PPU 的顯式探測並讀，達摩院玄鐵線在本視窗的自建測試覆蓋明顯加強。

1.11 其餘動態：community、FlagGems-Experimental、flir、FlagScale-Agent、映象 tag 記錄（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：community 2.2 專案同步、FlagGems-Experimental MetaX index_select、flir #74、build-infra 崑崙芯 xCCL

  • community：把釋出優先順序同步進專案檢視（工作流 .github/workflows/flagos-2.2-project-sync.yml，+60/-1），並保證 2.2 條目在釋出期持續可見；治理動作與版本抬升同日發生，屬 2.2 收口的配套。
  • FlagGems-Experimental：修 MetaX 的 index_select 實現（#419）、為 conv_depthwise2d 加 MetaX 支援（#391）、補 dense_dim 運算元（#639）——該倉繼續扮演「後端適配先落地、驗證後入主倉」的試驗田。
  • flir：去掉 tile.to_tensor 的 Pure 標記以對齊上游的 bufferization 語義（#74），改動與昇騰 TLE 線相關。
  • FlagScale-Agent：修正文件中的克隆地址指向自身倉庫（#42）。
  • build-infra 映象線：崑崙芯基礎映象安裝 xCCL（#917）、修正其 containerfile（#918）；同時記錄六條 vLLM 應用映象 tag（摩爾執行緒 musa5.2.0 與 musa4.3.6、燧原 tops1.9.10 與 tops1.10.6 各兩條），並清理崑崙芯 0.24.0 的過期待發布變更日誌（#911）。

二、新聞報道與生態

2.1 元件級檢索第十三個連續平靜視窗：24 小時內零命中（09-16~09-17）

日期：2026-09-16 至 2026-09-17　來源：Google News RSS（中英文 33 組查詢詞，視窗內零命中）

本期以 FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、FlagAttention 以及「智源研究院 開源」「BAAI open source」「眾智 FlagOS」等關鍵詞做了中英文各半的 33 組檢索，24 小時視窗內零命中，與元件名相關的最近一條報道仍是 09-15 10:16 關於 Open3D-PIMC 開源的英文稿與 09-14 的中文硬體稿。這已是連續第十三個平靜視窗。

按既有觀察，FlagOS 的對外可見度呈現「月節奏」：版本釋出、行業大會、晶片適配 Day0 三類事件才會帶來報道高峰，而版本釋出前的測試期恰好是靜默期。本週期的可見度高峰預計落在 09-28 GA 前後。HN Algolia 同期查詢（FlagOS / FlagGems / FlagScale / FlagTree）同樣為空。

2.2 FlagOS 2.2 時間表與 RC2 清單複核：GA 定檔 09-28（09-17 核查）

日期：2026-09-17（核查日）　來源：2.2 釋出時間表、2.2 RC2 原始碼清單、milestone FlagOS 2.2

對釋出件做了一次完整核對。時間表：特性凍結 08-31，測試與穩定期 09-01 至 09-24，GA 09-28；凍結規則寫明瞭例外通道（安全補丁、嚴重缺陷與 CI 阻塞可走加急通道，需 TSC 批准），以及畢業標準——只有可執行的測試計劃在測試期內透過，FEP 狀態才從「可實現」轉為「已實現」。

清單：RC2 的 24 個模組條目覆蓋 L0 基礎設施層（FlagTree 按 Triton 3.6 / 3.5 / 3.3 拆三條、FlagCX）、運算元層（FlagGems、FlagFFT、FlagSparse、FlagDNN、FlagBLAS、FlagTensor、FlagAudio、FlagAttention）、推理外掛層（FlagGems-vllm、FlagGems-sglang、Torch-FL、vllm-plugin-FL、sglang-plugin-FL）、訓練層（TransformerEngine-FL、Megatron-LM-FL、FlagScale）、釋出與工具層（KernelGen、KernelGenBench、FlagRelease、壓縮器）。版本上僅 FlagGems 打到 rc2.post2，其餘為 rc2.post1；FlagTree 沿用 0.7.0rc2.post1+triton3.x 的自有命名格式。

里程碑側：2.2 的 7 個 issue 當前全部未關閉，到期日 09-28，與時間表一致。綜合看，2.2 處於「程式碼凍結、驗收收尾」階段，未出現延期訊號。

2.3 地平線體系：地瓜機器人完成 4 億美元 C 輪融資（09-17）

日期：2026-09-17　來源：投資界報道

09-17，地瓜機器人（英文名 D-Robotics，由地平線孵化、2024 年獨立的機器人軟硬體底座公司）宣佈完成 4 億美元 C 輪融資。本輪由未來資產領投，美團戰投、合肥國投、南山戰新投、璟泉資本等產業與政府投資平臺，以及凱輝基金、華美國際、廣發信德、超越摩爾、啟航投資旗下芯創二期基金等機構聯合跟投；老股東高瓴創投、五源資本、線性資本、黃浦江資本、淡馬錫旗下 Vertex Growth、Prosperity7、和暄資本、雲鋒基金、美團龍珠、九合創投等持續加碼。

資金用途寫得具體：強化旭日晶片的全算力段產品佈局，並建設貫通「資料採集—模型訓練—模擬驗證—推理部署」的全鏈路軟體平臺。隨附的運營資料同樣有資訊量：2026 年上半年營收較去年同期數倍增長，旭日系列晶片累計出貨超 800 萬片，具身智慧業務進入量產級出貨，旗艦 S600 半年內獲 20 餘家頭部客戶採用、具身智慧客戶覆蓋率超 50%。

對本報告主題的意義在於軟體棧側的位置：地平線（含其機器人體系）是 FlagOS 的成員單位之一，其晶片與端側平臺是 FlagOS 端側與具身智慧方向的落點；「全鏈路軟體平臺」的建設口徑與 FlagOS-Robo 在機器人側要解決的問題高度重疊，後續可關注其軟體平臺是否引入 FlagOS 元件。

2.4 成員單位資本面：沐曦中報扭虧、燧原上市首日市值破千億、國產 GPU 半年報（09-16~09-17）

日期：2026-09-16 至 2026-09-17　來源：虎嗅 沐曦中報、新浪財經 燧原上市首日、雷峰網 國產 GPU 半年報解讀

成員單位的對外敘事本期集中在資本側，三點：沐曦 2026 年中報扭虧為盈、主業仍處投入期（09-16）；燧原科技上市首日市值突破千億元，09-17 的解讀轉到其「市場化 GP 加地方國企 LP」的股權結構；雷峰網 09-17 彙總四家國產 GPU 的半年報，落點是二級市場的估值耐受度。同日行情側，摩爾執行緒、沐曦、寒武紀均有大幅波動，屬市場資訊而非生態動態，本報告不作條目收錄。

需要點明的是口徑邊界：上述三條都無法作為 FlagOS 專案進展的證據，它們只是成員單位經營與融資狀態的旁證。本期與 FlagOS 相關的技術動作仍只出現在 GitHub 上，這也是連續多個視窗的共同特徵。

三、成員單位深挖

3.1 海光：linalg 與 dtype 語義兩端同時補齊（09-16）

日期：2026-09-16　來源：FlagGems #5390 linalg_lstsq、FlagGems #5959 linalg_matrix_power、FlagGems #6351 nansum dtype

海光本期沒有單點大動作，而是三條並行的補齊：其一 linalg_lstsq 一次性支援三個後端（海光、沐曦、天數），說明最小二乘這類線性代數運算元的多晶片實現開始成組推進；其二 linalg_matrix_power 支援海光與天數，屬矩陣函式系列；其三 nansum 的整型 dtype 提升修復同時覆蓋 Nvidia、昇騰、沐曦與海光，並補 int8/uint8 用例——這是語義一致性性質的工作，修的不是效能而是「同一運算元在不同後端給出不同型別」的問題。前一視窗海光的重點在工具鏈與打包環境適配（gflags 標頭檔案、TLE 白名單、映象），本視窗轉到運算元與語義，方向上的切換說明其基礎環境問題已基本收口。

3.2 昇騰：MoE 與線性注意力所需運算元最密的一條線（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagGems #6324 swiglu、FlagGems #6325 grouped_matmul、FlagGems-vllm #789 compressor、FlagGems-vllm #788 chunk_gated_delta_rule_fwd

昇騰線本期提交最密，且集中在當前大模型結構的兩個熱點。MoE 方向：swiglu 啟用（#6324）與 grouped_matmul 分組矩陣乘（#6325）——前者是 MoE 前饋網路的啟用函式，後者是專家並行的核心運算元，兩條湊齊意味著一層完整 MoE 計算可以在運算元庫內閉環。線性注意力方向：compressor（#789）與 chunk_gated_delta_rule_fwd（#788）兩個融合運算元進推理外掛倉，對應 GDN 類線性注意力的分塊前向；配合 flir 中對 tile.to_tensor 的語義對齊（#74，涉昇騰 TLE 線），以及 linalg_norm（#6355）、linalg_matrix_norm（#5670）兩條範數實現，昇騰在運算元側是本期覆蓋面最全的一家。

3.3 達摩院玄鐵：推理外掛接入 PPU CI，MM/MV 支援 NN/NT 佈局（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：vllm-plugin-FL #518 PPU CI、FlagGems #6302 MM/MV 佈局最佳化、FlagTree #1190 PPU 基準

達摩院玄鐵（PPU）線本期是「測試基建 + 效能」雙線。測試側：vllm-plugin-FL 把 PPU 接進持續整合（#518，新增平臺配置、環境準備指令碼、映象與平臺測試清單），Torch-FL 在運算元測試門禁裡顯式探測 PPU 而非依賴預設分支（#309），PPU 的測試清單改從 ppu.yml 讀取（#305）。效能側：FlagGems 對矩陣乘與矩陣向量乘做了 NN 與 NT 兩種佈局的支援與最佳化（#6302），FlagTree 更新 PPU 基準結果（#1190）並修 tl.load/tl.dot 在 PPU 與沐曦上的行為（#1191）。把一個平臺從「能跑運算元」推到「能在 CI 裡被持續驗證」，是可用性從個案走向常態的分界。

3.4 摩爾執行緒：原生 FP8 W8A8 MM 與 MUSA 旋轉位置編碼回裝置側（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagGems #6211 原生 FP8 W8A8、Torch-FL #316 MUSA 旋轉位置編碼、Torch-FL #298 RNG 橋

三筆動作指向同一目標——讓 MUSA 後端在量化推理與長上下文模型上少走回退。運算元側新增原生 FP8 W8A8 矩陣乘後端（#6211）；適配側把複數形式的旋轉位置編碼運算元留在裝置側執行（#316），避免了原先可能的逐元素回退到主機；穩定性側重綁廠商運算元模組上的隨機數橋（#298），修的是種子與流的一致性。映象側，build-infra 記錄了 MUSA 5.2.0 與 4.3.6 兩條應用映象 tag，併為 0.24.0 rc2 重建補了待發布變更日誌（#913/#914/#915）。旋轉位置編碼與隨機數橋這兩項屬「不顯眼但必過」的門檻項，也是跨晶片推理精度能否對齊的常見分界。

3.5 沐曦：W8A16 RMSNorm 與三處路由繞行（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：FlagGems #6326 W8A16 RMSNorm、FlagGems-Experimental #419 index_select、Torch-FL #306 slice.Tensor 繞行

沐曦線本期以「補一個運算元、繞三處路徑」為主。運算元側新增 W8A16 RMSNorm（#6326），把量化精度擴到歸一化層；試驗倉裡修掉 index_select 的實現問題（#419）並補上逐深度卷積支援（#391）。路由側三處繞行：Torch-FL 把 slice.Tensor 移出 FlagGems 路由以打通 Qwen-Image-2512 的手動測試流（#306）、把矩陣乘在部分場景下繞開 FlagGems 路由（與 1.7 中的門禁配套）、以及在 FlagTree 側修 linalg_solve_triangular 的測試參考實現（#6341）。繞行條目本身不是成就，但它們被逐條具名記錄，才能讓後續版本的收斂有據可依。

3.6 崑崙芯：xCCL 裝進基礎映象，運算元修復批次落地（09-17）

日期：2026-09-17　來源：build-infra #917 xCCL、FlagGems #6328 運算元修復、FlagGems #4540 topk_softmax 樁

崑崙芯線本期由三類動作組成。映象側：基礎映象裝入 xCCL（#917）並修正其 containerfile（#918）——把廠商通訊庫預置進基礎映象，意味著跨晶片通訊在其平臺上不再依賴執行時外掛，與本報告 1.10 中 FlagCX 工具鏈的改進方向一致。運算元側：一批修復同時落地，覆蓋 masked_fill、sinh、mish、hardswish、index_fill 五個運算元（#6328）；topk_softmax 補了給 C++ 啟動器用的核心樁（#4540）；去掉一條已被解決的 softmax_backward 維度跳過邏輯（#4539）。工程側：測試改為在容器內執行（#6343），並修掉推理外掛中 FlashAttention 模組匯入失敗後的殘留狀態（#528）。合看是「把測試環境與依賴一次性對齊」的整備動作。

3.7 天數智芯：/dev/itrctl 與 iluvatar3.6 基線工作流（09-17）

日期：2026-09-17　來源：FlagGems #6376 /dev/itrctl、FlagTree #1197 iluvatar3.6 基線、FlagGems #5390 linalg_lstsq

天數智芯線本期兩條基礎設施改動加一條運算元補齊：FlagGems 的 CI/CD 配置掛入 /dev/itrctl 裝置節點並更新打包配置（#6376），說明其測試環境需要訪問裝置控制介面；FlagTree 為 iluvatar3.6 增加 FlagGems 基線與測試工作流（#1197），即給該後端建立可比的效能與正確性基線；運算元側與海光、沐曦共用 linalg_lstsq 的多後端實現（#5390）。此外 build-infra 修掉了一條會破壞 corex clang 的過期環境變數（#901）。三條並讀，天數智芯當前階段是「把 CI 基線立起來」。

3.8 燧原：GCU300 記錄進 0.24.0 報告與兩條映象 tag（09-16）

日期：2026-09-16　來源：build-infra #910 GCU300 記錄、build-infra #900 門禁用例、FlagTree #1185 TLE 測試

燧原線本期全部落在構建與驗證側：把 GCU300 的執行記錄寫入 vLLM 0.24.0 報告（#910），記錄門禁用例的執行結果與圖模式下的阻塞項（#900），併為 tops1.9.10 與 tops1.10.6 兩條工具鏈各記一條應用映象 tag（#906/#907）。另在 FlagTree 側，對昇騰 TLE 線中偶發失敗的融合 softmax 用例加了忽略（#1185）——這類「偶發失敗」在跨晶片 CI 裡通常意味環境差異而非邏輯缺陷，標記而非修補是當前階段的合理選擇。燧原的資本面動作（09-15 上市、09-16 首日破千億）不改變其工程重心，技術線仍以把 GCU 平臺納入多晶片驗證矩陣為主。

3.9 智源（牽頭方）：治理自動化與版本號抬升（09-16/09-17）

日期：2026-09-16 至 2026-09-17　來源：community 2.2 專案同步、build-infra #916

作為牽頭方，智源本期的工作集中在治理而非程式碼產出：community 把釋出優先順序同步進專案檢視並保證 2.2 條目在釋出期持續可見；build-infra 抬升版本號，把整條映象線指向 2.2.0。配合 2.2 時間表中「Release Manager 在追蹤 issue 中維護測試矩陣、按釋出流程組織 Go/No-Go」的角色定義，可以看到釋出機制已從人工對錶轉為「專案檢視 + 追蹤 issue + 清單檔案」三件套驅動。距 GA 11 天，智源側下一步的可觀察訊號是 Go/No-Go 結論與各 FEP 的驗收狀態流轉。

四、總結與趨勢觀察

  • 2.2 進入釋出件凍結階段：build-infra 把版本欄位抬到 2.2.0，是 org 內唯一的全域性釋出開關；此後各模組的 rc 打標隻影響候選快照，不再改變版本號。GA 定檔 09-28，測試期還剩約一週。
  • 工程質量線的比重上升：150 條提交裡 CI、測試與修復類合計約四分之一（單看以 ci、test、fix 開頭的提交即 23 條），KernelGen 的批次入庫正在倒逼匯出檢查、測試標記、基準對齊等規範落地——擴容的瓶頸從「寫核心」轉向「登記與驗收」。
  • 跨晶片可用性靠「路由加繞行名單」推進：Torch-FL 與 vllm-plugin-FL 本期的主要產出是繞行條目與門禁，而非新功能；廠商核心承接的運算元已有具名清單（MetaX 的切片運算元、MUSA 的複數旋轉位置編碼、CUDA 的 FlagTune 缺位），這份清單的長度就是跨晶片複用率的反向指標。
  • 兩條運算元擴容主線清晰：一是量化（W8A8、W8A16、FP8），從矩陣乘擴到歸一化與取樣，代表性提交為摩爾執行緒原生 FP8 W8A8 MM 與融合 Marlin MoE；二是 MoE 與線性注意力（分組矩陣乘、swiglu、compressor、分塊門控 Delta 規則前向），集中在昇騰線。
  • 測試基建向平臺化收斂：達摩院玄鐵 PPU 接入推理外掛 CI、天數智芯建立 iluvatar3.6 基線、FlagTree 抽統一的後端初始化介面——三家不同形態的動作指向同一目標：讓每個後端都能在 CI 裡被持續驗證，而不是靠人工跑通。
  • 新聞側持續靜默、技術側全部在程式碼上：這是連續第十三個平靜視窗，成員單位的對外可見度主要來自資本面（地瓜機器人 4 億美元 C 輪、沐曦中報、燧原上市）。預計下一個報道高峰在 09-28 釋出視窗。

附錄：信源核查表

信源 核查結果
GitHub org 倉庫 pushed_at（54 倉） 19 倉視窗內有推送，已全部核驗
GitHub commit search（committer-date） 150 條視窗內提交，兩頁取全量，分佈於 15 倉
GitHub 重點倉庫預設分支提交 FlagGems / build-infra / Torch-FL / FlagTree 等逐條複核
GitHub tags 與 releases 各模組最新標籤均為 rc2.post1（FlagGems 為 rc2.post2），無新發布
community 釋出清單與時間表 RC2 清單 24 條目、2.2 時間表與里程碑狀態已複核
build-infra configs.yaml 版本欄位抬升至 2.2.0，已取補丁與檔案全文
Google News RSS（33 組中英文查詢） 視窗內零命中，最近命中為 09-15
HN Algolia 視窗內零命中
智源社群（hub.baai.ac.cn） 視窗內無 FlagOS 相關新稿
投資界 / 智源社群 / 新浪財經 / 雷峰網 / 集微網 取到地瓜機器人 C 輪等成員單位條目

完整信源清單

s-vllm/pull/750>

4]** 雷峰網 國產 GPU 四份半年報解讀 — https://news.google.com/rss/articles/CBMibkFVX3lxTE5UbVdtRXlOaHJHdGdBSkZ5SUVWbmJuUG84QWtOaWx3U0xjcmpXSW9hUFVLQ3BkdnljbGJBbUV2aVhPUEpnb1lDZmxyU3VVXzUxd