調研視窗：2026-09-11 10:18 ~ 2026-09-14 10:18 北京時間（週一視窗，過去 3 天，覆蓋週末） 信源：GitHub（org: flagos-ai，53 個倉庫 pushed_at + 單次 commit search 150 條按 committer-date 全量核驗 + per-repo commits 複核 + commit 詳情與補丁 + 倉庫樹 API）、community 倉庫 2.2 釋出清單與時間表（raw 直取）、Google News RSS（中英文 18 組查詢詞，走代理）、HN Algolia、FlagOS 官方社群站（版本與直播列表）、Tavily/web 檢索、財聯社/證券時報/IT之家/新浪財經等產業報道（詳見附錄）

索引

  • 一、開源專案進展（GitHub 動態）
    • 1.1 2.2 RC1 清單進入 rc1.postN 迭代：FlagGems 升到 v5.4.0-rc1.post2（09-11）
    • 1.2 FlagCX 交付化：libflagcx 從”原始碼自編”走向”按後端打 .deb + 按發行版釋出 apt 倉庫”（09-11/09-12）
    • 1.3 FlagCX 核心面：net adaptor 重構 6601 行，PAL 預設 device API 後端補齊（09-11/09-13）
    • 1.4 build-infra sglang 線：崑崙芯 xre5.37.1 與天數智芯 corex4.4.0 兩條應用線落地（09-12）
    • 1.5 build-infra vllm 線：清微開啟 0.20.2，天數智芯 0.24.0 收斂到統一 plugin wheel（09-13）
    • 1.6 FlagTree：0.7.0rc1 之後的基準與後端同步——崑崙芯叢集 +17604 行、天數智芯基準入 CI（09-11/09-13）
    • 1.7 FlagGems：KMCompiler 昇騰代數補齊、KernelGen 多廠商入庫、崑崙芯 copy 家族遷 TLE（09-11/09-14）
    • 1.8 推理與訓練外掛線：海光 vLLM 0.24.0 工作流開啟，SGLang 側四條競賽分支合入（09-11/09-12）
    • 1.9 科學計算與領域運算元庫：海光與沐曦兩批運算元集中補齊，FlagBLAS 天數智芯 L2、FlagSparse 雙後端（09-11）
    • 1.10 FlagQuantum：vNext 架構合併 + 0.2.0 發行件校驗 + QPU 數字孿生（09-11/09-13）
    • 1.11 訓練框架與工具面：Megatron-LM-FL 剝離 CUDA 硬依賴，FlagScale/FlagPrism/TransformerEngine-FL 各有推進（09-11/09-14）
  • 二、新聞報道與生態
    • 2.1 元件級檢索第十個連續平靜視窗：技術資訊面全部來自程式碼倉庫（09-11~09-14）
    • 2.2 產業側三件事：移動雲異構推理系統釋出、燧原上市首日收官、沐曦解禁視窗臨近（09-11~09-13）
    • 2.3 社群活動與競賽：SGLang 跨晶片運算元最佳化賽與運算元賞金賽分享會，競賽產出開始進入主倉（09-11~09-12）
  • 三、成員單位深挖
    • 3.1 燧原科技：科創板敲鐘收官”國產 GPU 四小龍”資本化，技術面同步修 enflame 裝置適配（09-11）
    • 3.2 天數智芯：進入移動雲異構推理系統，同時在 FlagOS 內五條工作面並行（09-11~09-13）
    • 3.3 清微智慧：vLLM 0.20.2 應用線開啟，端到端驗證與映象 tag 閉環（09-13）
    • 3.4 海光資訊：通訊庫 deb 後端打通、vLLM 工作流開啟、運算元批次補齊三線齊動（09-11/09-12）
    • 3.5 摩爾執行緒與沐曦：生成運算元與後端運算元兩批落地，產業側資本節奏分化（09-11~09-13）
    • 3.6 崑崙芯（外部生態方）：編譯器側大幅同步，但通訊庫被記錄為”不可交付”（09-11/09-12）
    • 3.7 智源（牽頭方）：2.2 測試期紀律與 RC1 清單維護，GA 定在 09-28（09-11）
  • 四、總結
  • 附錄：完整信源清單

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

視窗總覽：org 內 53 個倉庫中 21 個在視窗內有推送；commit search 命中 150 條視窗內提交（5 頁全量，committer-date 降序），經 per-repo commits 複核另補入 23 條，合計 173 條，分佈於 18 個倉庫：FlagGems-Experimental 54、build-infra 33、FlagGems 21、FlagQuantum 15、FlagCX 7、FlagGems-vllm 6、Megatron-LM-FL 5、FlagTree 4、FlagBLAS 4、FlagGems-sglang 4、FlagDNN 4、FlagSparse 10（其中 8 條來自 per-repo 複核）、FlagScale 1、FlagPrism 1、vllm-plugin-FL 1、TransformerEngine-FL 1、FlagOS-Compressor 1、community 1。另有 sglang-plugin-FL、docs、release-info 三倉 pushed_at 落在視窗內，但預設分支與分支 API 複核均無視窗內新提交（屬分支或標籤推送）。無新倉庫、無新 GitHub Release 條目。

本視窗形態 = RC 測試期的”交付面成型 + 外部後端加碼”雙線：治理側把 2.2 RC1 清單推進到第二輪驗證（flagems 升 rc1.post2）；交付側最重的一條線是 FlagCX 的 .deb 打包與 apt 倉庫釋出被完整走通（從”使用者自己對著廠商 SDK 編譯”變成 apt-get install）；編譯器與運算元側則由崑崙芯、天數智芯、清微、海光四家把各自的應用線、基準線與運算元面同時往前推。上一視窗預判的”2.2 GA 前 rc1.postN 遞增節奏”在本視窗兌現，同時出現了第一條被明確記錄為”不可交付”的後端（崑崙芯通訊庫），工程的邊界開始被寫清楚而不只是被推進。

1.1 2.2 RC1 清單進入 rc1.postN 迭代：FlagGems 升到 v5.4.0-rc1.post2（09-11）

來源：community #108（09-11 11:45）（清單檔案 release/2.2/release-2.2-rc1.yaml 的視窗內唯一改動）

  • 第二輪驗證落庫：清單中 flaggems 條目由 v5.4.0-rc1.post1 更新為 v5.4.0-rc1.post2，tag 指向 rc1 分支頭部 270bebe1，post1 之後累計 4 項修復——回退 FlagTune 的 Mul cost model、天數智芯 randperm/sort 修復、index int64 偏移溢位修復、缺失的 DSA __init__.py 打包修復。
  • RC1 清單現狀（25 條元件快照）：L0 層為 FlagTree 三條線 0.7.0rc1.post1+triton3.3/3.5/3.6、FlagCX v0.14.0-rc1.post1；運算元與領域庫為 FlagGems v5.4.0-rc1.post2、FlagGems-vllm v0.2.0-rc1.post1、FlagGems-sglang v0.1.0-rc1.post1、FlagAttention v0.4.0-rc1.post1、FlagFFT v0.2.0-rc1.post1、FlagSparse v0.3.0-rc1.post1、FlagBLAS/FlagDNN/FlagTensor/FlagAudio 均為 v0.3.0-rc1.post1；框架接入為 vLLM-plugin-FL v0.3.0-rc1.post1（另有 0.2 線 v0.2.2-rc1.post1）、SGLang-plugin-FL v0.2.0-rc1.post1、Torch-FL v0.2.0-rc1.post1、TransformerEngine-FL / Megatron-LM-FL v0.3.0-rc1.post1；訓練與工具為 FlagScale v2.1.0-rc1.post1、KernelGen v2.2.0-rc1.post1、KernelGenBench v0.2.0-rc1.post1、FlagRelease v0.3.0-rc1.post1、FlagOS-Compressor v0.1.0-rc1.post1。
  • 時間表口徑：2.2 週期為特性凍結 08-31 → 測試與穩定期 09-01 至 09-24（只收 bug 修復、不進新特性）→ GA 09-28；畢業標準要求每個 FEP 的 Test Plan（命令 + 環境 + 期望結果、覆蓋多晶片）在測試期內驗收透過，未過部分單獨掛驗收 issue。

解讀：清單的 25 條快照和”rc1.postN 遞增”機制合起來說明一件事——2.2 的釋出面已經不再由功能清單定義，而由”哪一輪驗證透過”定義。windows 內唯一清單改動是把 FlagGems 推到 post2，且 4 項修復全部是數值/打包類缺陷（cost model 回退、randperm 排序、int64 偏移、子包缺失），這正是測試期紀律的直接投影：凍結之後版本號只由修復推動，不由特性推動。

1.2 FlagCX 交付化：libflagcx 從”原始碼自編”走向”按後端打 .deb + 按發行版釋出 apt 倉庫”（09-11/09-12）

來源：build-infra #847（09-11 18:02）、#849（09-11 18:50）、#851（09-11 19:18）、#853（09-11 21:37）、#854（09-11 22:00）、#855（09-11 22:06）、#856（09-12 11:20）、#865（09-12 17:20）、#866（09-12 18:25）、#868（09-12 21:08）

  • 為什麼要打包（#847，+2449 行）：commit 說明寫明 FlagCX 以原始碼形態分發，下游使用者必須先對著自己的廠商 SDK 編譯才能連結任何東西；在廠商自己的 base 映象裡構建 .deb 可以把 soname、-dev 標頭檔案與 glibc 下限全部在構建期固定，使用者側只剩”裝包”一步。實現上由 backends.yaml 承載打包事實（make flag、apt 依賴、證明廠商 SDK 存在的 assert），deb-config.py 與 generate_matrix.py --runtime 合併，--check 作為兩者漂移報警；構建在 base/<backend> 內以固定 ref 克隆 FlagCX 樹，規範 SONAME 並剝離 rpath，把執行庫與標頭檔案拆包；verify 階段僅憑檔案安裝——在 base 映象內證明可解析可載入，在純淨 Ubuntu 上證明 Depends 不會把廠商 SDK 拖進使用者機器。
  • 釋出到 apt 倉庫（#851）：釋出按 dispatch 可選（publish 預設 false），落到以構建所用 Ubuntu 版本命名的倉庫（flagos-apt-ubuntu24.04 / flagos-apt-ubuntu22.04），arch 不作為地址的一部分由 apt 自行分流；釋出步驟放在 verify 作業內而非後置 publisher，理由是”到使用者 apt-get install 路徑上的檔案必須是剛被驗證的那個檔案”；publish 不帶 verify 在 set-matrix 階段即被拒，非 tag ref 也被拒（版本號取自克隆的 tags）。
  • 六個後端一次性啟用（#865）：iluvatar-corex4.4.0/4.5.0、mthreads-musa4.3.6/5.2.0、sunrise-tangrt1.2.0、tsingmicro-tsm260610 各自補上容器內探測確定的 assert 與 vendor_lib_dirs。該提交同時修掉一個隱蔽缺陷：Makefile 只 glob flagcx/adaptor/*.cc，導致 flagcx_device.cc 對 devApiBackend 的硬引用在廠商 .mk 未提供 PLATFORM_EXTRA_SRCS 時符號未定義，而 -shared 容忍未定義符號、只有 dlopen(RTLD_NOW) 會報出來——cambricon 已有覆蓋，iluvatar/sunrise/tsm 需要補齊。
  • 海光 DTK 後端打通（#866）：探測結論落地——DTK 完全不匯出 CUDA_PATH，du.mk 的 DEVICE_HOME ?=/CCL_HOME ?= 捕獲空值，兩條路徑被固定到 /opt/dtk/cuda/cuda-12；DTK 上 -lnccl 實際解析到 RCCL，因此產物 NEEDED 項是 librccl.so.1，nccl 拼寫在 debian/rules 的 shlibs 迴圈裡匹配不到；DTK 的庫未註冊 ldconfig、LD_LIBRARY_PATH 來自僅 bash 生效的 profile 指令碼，dpkg-shlibdeps 必須顯式列出兩個目錄。同提交修掉 verify 的 ldd 門禁被映象自身環境影響的問題（基映象把 BASH_ENV 指向一個會重導 LD_LIBRARY_PATH 的鉤子，ldd 是 bash 指令碼因而先執行了該鉤子）。
  • 首條”不可交付”記錄（#868）：崑崙芯 xre5.37.1 的 deb 條目保持禁用，原因被寫進 backends.yaml 探測註記——CCL 庫不在 .deb 構建所用的映象裡（base Containerfile 不裝 CCL 包、XRE 5.37.1.0 安裝載荷不含 xccl/bkcl，棧內唯一的 libbkcl.so 是廠商 torch wheel 內的執行時產物），即便找到也無法繫結（該庫匯出 C++ mangled 符號、沒有純 C 的 bkcl_* 入口）。DESIGN.md 的 triage 由”1 項探測待定”變為”19 項就緒 + 1 項已記錄原因”。
  • 配套工程動作：#853 讓流水線”以使用者的方式”讀回已釋出 apt 倉庫；#854 讓某一行失敗時仍驗證已構建成功的行；#855 讓 .deb 派發接受後端列表；#856 用構建它的工具鏈去讀取 .deb；#859 把節點代理轉發進 verify 容器。

解讀：這條線是本期最具產品含義的變化。此前 FlagCX 的可用性等於”使用者能不能自己把通訊庫編出來”，對一個要同時覆蓋十餘家廠商私有工具鏈的軟體棧而言，這是規模化交付的最後一道手工門檻。把 .deb 放進按發行版切分的 apt 倉庫，意味著 FlagCX 的安裝面第一次與 vLLM/SGLang 外掛的 pip install 處在同一層級；而”釋出必須與剛驗證的檔案同一份”“publish 不得繞過 verify”“非 tag ref 不許釋出”三條約束，說明這一層是帶著審計意識建的。崑崙芯被明確記為不可交付而非含糊擱置，也讓”19 就緒 / 1 有因”成為可對外陳述的交付面。

1.3 FlagCX 核心面：net adaptor 重構 6601 行，PAL 預設 device API 後端補齊（09-11/09-13）

來源：FlagCX #578（09-13 23:24）、#582（09-13 01:18）、#584（09-13 01:20）、#585（09-13 01:20）、#586（09-13 01:21）、#588（09-12 23:56）、#580（09-11 17:02）

  • 網路介面卡重構（#578，+5309/-1292）：FlagCX 主倉本視窗最大單筆改動，規模超過其餘六條之和。PAL（平臺抽象層）方向的網路介面卡被重寫，是”通訊庫把平臺差異收進抽象層”這條主線的延續。
  • 裝置 API 後端接線（#582）：為剩餘平臺連結預設 device API 後端，與 build-infra 側 #865 說的”廠商 .mk 留空導致 devApiBackend 未定義”是同一個問題的兩邊——主倉補連結、交付側補欄位。
  • 可用性與文件面：#586 在 FLAGCX_PATH 未設時回退到系統 FlagCX 庫而不是直接失敗；#584 在 getting_started 中列全缺失的後端（讓”支援哪些平臺”變成文件事實）；#585 固定 format 鉤子所用的 clang-format 版本。
  • 供應鏈加固（#588）：把海光 CI 映象固定到 SHCA 之前的 digest，避免上游映象變更靜默改變構建環境。
  • 廠商適配修補（#580）：修正燧原（enflame）裝置介面卡裡 topsDeviceProp 的型別名。

解讀：FlagCX 在本視窗同時做了三件性質不同的事——核心面重構（#578）、平臺接線補漏（#582/#580）、交付與 CI 加固（#584/#585/#586/#588）。結合 1.2 的打包線，通訊庫正從”能連起來的庫”變成”能裝、能定位、能復現構建的庫”。對多晶片軟體棧來說，通訊庫恰恰是最容易在不同廠商 SDK 之間積壓特例的元件（海光的 RCCL/ldconfig、崑崙芯缺失的純 C 入口、燧原的型別名），本視窗的動作說明這些特例正在被逐條收斂進可測試的抽象層，而不是留在各廠商分支上。

1.4 build-infra sglang 線：崑崙芯 xre5.37.1 與天數智芯 corex4.4.0 兩條應用線落地（09-12）

來源：build-infra #857（09-12 11:35）、#860（09-12 12:27）、#861（09-12 12:28）、#862（09-12 13:00）、#863（09-12 14:42）、#864（09-12 13:14）、#867（09-12 18:57）、#869（09-12 19:05）、#870（09-12 21:09）、#871（09-12 19:28）

  • 崑崙芯 sglang 線閉環（#857→#864）：先讓 kunlunxin-xre5.37.1 “可構建、可驅動”，隨後記錄 F/T（功能與效能）驗證結果、落庫 sglang0.5.18-kunlunxin-xre5.37.1 changelog、記錄應用映象 tag 2.1.2-0.1.dev1_g7fb22a0c2、並把崑崙芯應用映象寫入 status matrix。同一批次修掉 vllm-plugin-wheel 解析 plugin_ref 時因 SIGPIPE 中止的問題（#860）。
  • 天數智芯 corex4.4.0 應用線（#867→#871）：補齊並校驗 corex4.4.0 的應用配置，落庫 sglang0.5.18-iluvatar-corex4.4.0 changelog 與映象 tag 2.1.2-0.1.dev1_g4d44a24cd。
  • 910C 線收尾：#848 恢復昇騰 910C 重建的待發布 changelog 條目，#850（09-11 19:19） 記錄 CANN 8.5.0-910c 的映象 tag 2.1.2-0.2.0_gf31b199.d20260911，#835 記錄 910C 端到端結果與已交付的 cann8.5.0 T 路徑修復，#852（09-11 20:55） 把”應用映象陳舊”背後的 docker 層快取陷阱寫成文件。

解讀：sglang 側的動作形態已經標準化為五步閉環——讓某後端可構建、跑 F/T 驗證、落 changelog、記映象 tag、進 status matrix。崑崙芯與天數智芯在同一視窗各自走完一遍，說明這條閉環路徑（上一視窗由昇騰與清微分別驗證過）現在是可複製的例行工序，而不是每家後端一次性的攻關。對 2.2 GA 而言，真正決定釋出範圍的是 status matrix 上”已驗證”的格子數，本視窗新增了崑崙芯與天數智芯 corex4.4.0 兩格。

1.5 build-infra vllm 線：清微開啟 0.20.2，天數智芯 0.24.0 收斂到統一 plugin wheel（09-13）

來源：build-infra #872（09-12 21:09）、#873（09-13 10:27）、#874（09-13 20:10）、#875（09-13 22:38）、#876、#877（09-13 22:49）、#878（09-13 22:56）

  • 清微 tsm260610 開啟 vLLM 0.20.2（#873）：應用矩陣成員資格由 configs.yaml 中每後端的 deps_app 鍵決定，清微此前只有 vllm0.24.0，導致 generate_matrix.py --app vllm0.20.2 輸出空 include 列表、構建作業在執行前即被跳過。本次補上 vllm0.20.2: []（0.20.2 外掛 wheel 不需要額外廠商包），並附上待發布條目，映象 tag 記為 2.1.2-0.2.1_g90ffdf0.d20260912（#874），外掛 pin 到 F/T 端到端驗證所對的 VPF #489 頭部（#872 記錄了該輪 0.20.2 的 F/T 結果）。
  • 天數智芯 0.24.0 收斂（#875→#878）：兩條 corex 應用映象改為從單一提交的 vllm-plugin-FL 頭部（symm_mem stub）重建，使 corex4.4.0 與 4.5.0 收斂到同一個 vllm_fl 版本，不再各自 pin VPF #434 與 g07063fd 的變體 wheel；映象 tag 記為 2.1.2-0.2.1_gc9e2573.d20260913。同一提交還明確否決了”在同一 wheel 裡修 corex4.4.0 T 路徑”的計劃——該修復從未合入、探測補丁只能讓 serve 輸出垃圾，而共用天數智芯後端模組意味著帶上它會把已驗證的 corex4.5.0 T 路徑置於風險中，最終在 14.4 節記錄而非硬推。

解讀：兩條動作指向同一工程取向——矩陣要”能被列舉出來”，後端要”收斂到同一份外掛”。清微的問題不是晶片不可用，而是應用矩陣的鍵沒寫全，構建作業被靜默跳過；這類”看起來什麼都沒發生”的缺位在 RC 期最難發現，也最能說明 configs.yaml 已經變成釋出面的真實清單。天數智芯那邊則是一次典型的取捨記錄：放棄一個會汙染共用模組的修復，換取 corex4.5.0 已驗證路徑的確定性——RC 測試期”只進修復、不進特性”的紀律在具體提交裡體現為”寧可不修，也不破壞已驗證的格子”。

1.6 FlagTree：0.7.0rc1 之後的基準與後端同步——崑崙芯叢集 +17604 行、天數智芯基準入 CI（09-11/09-13）

來源：FlagTree #1150（09-11 19:55）、#1153（09-13 22:28）、#1155（09-11 17:55）、#1157（09-11 17:24）

  • 崑崙芯 XPU 叢集同步（#1155，+17604/-1775）：從內部 5a664566 同步 cluster 分析與 pass —— 引入 Scalar/Tile/Vectorizability 分析以及 XPU 專屬 pass（Normalize、AsyncLoadSchedule、TLELegalize、LoopInvariantStaging、LegalizeExternEW），新增 stage_sm / load_scalar_indexed 運算元與 GM2SM lowering，保留手寫 OffsetAnalysis 屬性、並把 budget-tiling 與 loop-invariant-staging 預設關閉；同時引入 P-TLE raw 前端（tle.raw）、修 size-one make range 的下沉，並讓 compiler.py 傳遞 UnrollControl 預算旋鈕（pin_unroll_num=-1 使 vector-add 走既有 unroll 路徑）。來源標註為 baidu/xpu/triton 6848085b..5a664566。
  • 天數智芯基準進 CI（#1153）：把 iluvatar 的 vLLM benchmark 加入工作流，與上一視窗 PPU 線的做法一致。
  • PPU 基準重新整理（#1157）：更新 890P 上的 PPU vLLM benchmark 結果（33 行資料）。
  • Triton 上游同步（#1150）：從上游 triton 引入 warp layout broadcast。

解讀：0.7.0 的版本號收斂（上一視窗）之後，編譯器的動作重心轉向”後端基準化 + 叢集同步”。兩條基準線（天數智芯 vLLM benchmark 入 CI、PPU 890P 結果重新整理）說明效能資料開始按後端進入持續記錄；崑崙芯 +17604 行的叢集同步則說明 XPU 線仍以”內部分支 → 開源叢集”的方式推進，且伴隨”哪些 pass 預設關閉”的保守設定——基準與 pass 的開關同樣是被管理物件。

1.7 FlagGems：KMCompiler 昇騰代數補齊、KernelGen 多廠商入庫、崑崙芯 copy 家族遷 TLE（09-11/09-14）

來源：#6093（09-11 18:59）、#6136（09-11 17:48）、#6161（09-11 17:13）、#6201（09-14 09:44）、#6203（09-11 17:16）、#6205（09-11 17:51）、#6209（09-14 09:48）、#5671（09-14 10:12）、#6183（09-11 17:33）、#6192（09-11 18:37）、#6213（09-13 20:15）、#5642（09-14 09:09）

  • KMCompiler 的昇騰代數繼續補齊：視窗內合入昇騰後端的 matrix_rank（#6161）、igammac（#6136）、gru（#6201）、adaptive_max_pool3d（#5671，NVIDIA 與昇騰共用 Triton kernel）、linalg_solve_triangular 的昇騰基線路徑跳過（#6209）以及依賴宣告（#6205）。
  • KernelGen 生成運算元多廠商入庫：NVIDIA 側補 split_with_sizes（#5590）與 convolution_overrideable（#5642，帶 Triton kernel）；摩爾執行緒側一次性入庫 conv_transpose1d（#6174）、upsample_linear1d_backward（#6175）、fmod_（#6170）、matmuladd（#6180）四個專用運算元。
  • 崑崙芯 copy 家族遷到 TLE（#6093）：把 copy 家族運算元從常規路徑遷到 TLE（Triton Language Extension）實現，與 FlagTree 側的 TLE 推進對應。
  • 正確性與工程面：[k] 字首的三批類別修復——索引與排序類（#5971）、nn 類（#5969）、數學類（#5967）；自動調優快取啟用 SQLite WAL 模式與 busy_timeout 以修 “database is locked”（#6203）；CI 修復 sort_exports 在雙 __all__ 時誤刪 import（#6213）；更新崑崙芯/天數智芯的 FlagTree CI docker 映象（#6192）。
  • 基準：新增獨立的 FP8 矩陣乘效能測試，並以 vLLM 作為基線（#6183）；fused_marlin_moe 文件補齊”權重佈局並非 vLLM Marlin 佈局”的說明（#6204）。

解讀：FlagGems 本視窗 21 條提交的結構很清楚——昇騰由 KMCompiler 路線按運算元逐個補齊（一個運算元一筆提交），NVIDIA 與摩爾執行緒由 KernelGen 路線批次入庫，崑崙芯則進入 TLE 化改造。三條路徑並行的意義在於：同一個運算元庫同時承載”編譯器自動生成”“生成器批次產出”“手寫 TLE 最佳化”三種產能，且各自對應不同成熟度的後端。工程面上最值得一提的是自動調優快取的 SQLite WAL 修復——多晶片大規模跑基準時快取的併發寫是典型的長尾故障，這類修復通常只在大規模並行驗證中才暴露，屬 RC 測試期的真實產出。

1.8 推理與訓練外掛線：海光 vLLM 0.24.0 工作流開啟，SGLang 側四條競賽分支合入（09-11/09-12）

來源：vllm-plugin-FL #436（09-11 10:54）、FlagGems-vllm #756（09-12 12:08）、#768（09-11 17:29）、#769（09-11 17:09）、#771（09-11 18:07）、#775（09-12 13:03）、#753（09-11 17:30）、FlagGems-sglang #45（09-12 11:43）、#47（09-12 12:16）、#58（09-12 12:21）、#61（09-12 11:44）

  • 海光進入 vLLM 0.24.0 工作流（vllm-plugin-FL #436）：為 vLLM 0.24.0 啟用海光工作流，是外掛層”新晶片/新版本先開工作流、再談交付”路徑的又一次執行。
  • FlagGems-vllm 的運算元與測試面：海光側補 persistent_topk 實現並透過 fused __init__ 接線（#756）；昇騰側補 per_token_group_quant_fp8（#775）；沐曦側最佳化 GDN chunk kernel（#771）；新增 fp8_einsum 及測試與 vLLM 基準（#769）；把跨後端 FP8 序列運算元測試開啟（#768）；把 combine_topk_swa_indices 的測試與基準改為廠商無關（#753）。
  • FlagGems-sglang 四條競賽分支合入（09-12）：add-chunk-local-cumsum-vec（#45）、add-context-attention（#47）、qkv-lora-b（#58）、chunk-state-varlen-v2（#61）四條以 competition/ 與個人分支命名的 PR 在 40 分鐘內陸續合入 master。

解讀：外掛線的兩件事合起來看很有意思。一方面 fp8_einsum、combine_topk_swa_indices 這類改動是在把”某廠商專用測試”改寫為廠商無關（vendor-agnostic），這與 build-infra 側”後端收斂到統一 plugin wheel”是同一個方向——減少每廠商一套的變體。另一方面 FlagGems-sglang 的四條合入來自競賽分支，說明社群競賽的產出已經進入主倉而非停在排行榜上；對 2.2 而言，這些運算元會隨 flaggems-sglang v0.1.0-rc1.postN 進入釋出清單。

1.9 科學計算與領域運算元庫：海光與沐曦兩批運算元集中補齊，FlagBLAS 天數智芯 L2、FlagSparse 雙後端（09-11）

來源：FlagGems-Experimental #586（09-11 18:50）、#567、#606（09-11 16:56）、#415（09-11 17:25）、#427（09-11 17:14）、FlagBLAS #115（09-12 17:31）、FlagSparse #57（09-11 02:56）、#58（09-11 07:44）、FlagDNN #10（09-11 06:25）

  • FlagGems-Experimental：海光運算元批次入庫：一次補入 reflection_pad1d_backward（#567）、embedding_bag_dense_backward（#575）、upsample_nearest_exact2d_backward（#576）、lift_fresh（#585）、mse_loss_backward（#574）、binary_cross_entropy_backward（#577）、special_round（#582）、special_chebyshev_polynomial_u（#583）、amp_foreach_non_finite_check_and_unscale_（#559）、addmv_（#572）、diagonal_scatter（#570）、special_shifted_chebyshev_polynomial_v（#584）、baddbmm_（#586）等一批反向與特函式運算元；同時新增達摩院玄鐵的 linear 專用運算元（#606，KernelGen 路線）。
  • FlagGems-Experimental：沐曦批次同步進退：約 35 條 MetaX 相關提交，一半是”Add MetaX support”（weight_int8pack_mm #415、unsafe_masked_index_put_accumulate #413、max_pool3d_with_indices_backward #402、cholesky_inverse #390、cudnn_convolution #392 等），一半是”Fix MetaX implementation”（special_gammaln #427、special_bessel_j0 #426、linear_backward #425、linalg_cholesky #423、histc #418、gcd_ #417、erfinv #416 等）。兩條流同日交錯，說明該後端進入”補實現 + 修實現”的密集校準階段。
  • FlagBLAS：天數智芯 L2 支援（#115，+5325 行）：為 iluvatar 增加 L2（矩陣-向量）級別支援並與 master 合併。
  • FlagSparse：沐曦與昇騰加入 + SPMM 校準：視窗內 metax ascend added、ascend multi datatype、spmm bell out of metax test 及 CI 檢查，PR #57/#58 由外部貢獻方（NCIC-AlphaSparse）合入主倉。
  • FlagDNN：達摩院玄鐵後端更新 + 廠商 README：更新 thead 後端（#10），補摩爾執行緒與昇騰的 README。

解讀：領域庫這一層的資訊量在於”補齊的粒度”——單視窗內 54 條實驗運算元庫提交 + FlagBLAS 的 L2 級別支援 + FlagSparse 的雙後端加入，說明 2.2 的六大 AI for Science 庫正從”能跑通”走向”覆蓋面完整”。沐曦批次的形態尤其值得注意：Add 與 Fix 交錯出現，是後端從”運算元存在”邁向”運算元正確”的典型訊號，這類校準工作通常無法靠單一晶片驗證發現，只能靠多家後端比對暴露。

1.10 FlagQuantum：vNext 架構合併 + 0.2.0 發行件校驗 + QPU 數字孿生（09-11/09-13）

來源：FlagQuantum #15（09-11 18:26）、#16、#17（09-11 18:56）、#18、#19（09-11 20:31）、#20（09-11 22:11）、#23（09-13 15:06）、#24（09-13 18:29）、#25（09-13 19:33）、#26（09-13 20:05）

  • vNext 架構合併進主線（#15）：vNext 發表歷史接入上游 main，架構重構分支合入。
  • 0.2.0 發行件校驗（#17）：把 Python 包的 Homepage/Repository/Issues 後設資料指向 flagos-ai/FlagQuantum 並與已釋出上游倉庫對齊；提交說明記錄了驗證口徑——wheel 與 sdist 透過發行內容檢查與嚴格 Twine 檢查，兩類安裝產物均透過 API 執行、兩步 PyTorch 訓練迴圈、運算元剖面載入與 Double-Single 數值一致性驗證。
  • 量子後端與服務側能力：#16 明確 Quafu 的 QSteed 外掛安裝方式；#18 提供 CUDA 與 QSteed 開發容器；#19 支援把 Quafu 電路提交到服務側編譯；#20 增加可續跑的 Quafu 與原生九鼎作業。
  • QPU 數字孿生（#24/#25/#26）：在 fq.twin 暴露廠商中立的 QPU 數字孿生，支援離線載入已驗證的 Twin 證據並完成證據持久化；#23 在保持向後相容的前提下遷移公開量子位元關鍵字。

解讀：量子線在本視窗呈現的是一條完整的”產品化”軌跡——架構合併（vNext）、發行件與後設資料對齊（0.2.0）、開發容器與服務側提交、再到數字孿生與證據持久化。若說 6 月在”科學智慧基座”釋出時 FlagQuantum 還處在”量智融合的第一步”敘事裡，本視窗的動作已經是標準開源專案的釋出工序（distribution content check、Twine strict、PyTorch 訓練迴圈冒煙、數值一致性）。對 FlagOS 的版圖而言，量子計算這條線一旦進入獨立的版本節奏，其元件治理方式（FEP、rc1 分支、release manifest）也會與其餘 25 條元件並軌。

1.11 訓練框架與工具面：Megatron-LM-FL 剝離 CUDA 硬依賴，FlagScale/FlagPrism/TransformerEngine-FL 各有推進（09-11/09-14）

來源：Megatron-LM-FL #149（09-11 10:41）、#150（09-11 14:04）、#151（09-11 19:04）、#154（09-12 18:06）、#156（09-14 09:00）、TransformerEngine-FL #118（09-11 14:10）、FlagScale #1291（09-11 19:01）、FlagPrism #10（09-11 21:24）、FlagOS-Compressor #7（09-11 14:27）

  • Megatron-LM-FL 的非 CUDA 化（五條提交）：#156 把硬編碼的 CUDA 裝置操作替換為平臺感知 API，覆蓋最佳化器、初始化、訓練與工具路徑，DDP 流建立與同步改用當前平臺實現，並更新裝置放置、張量建立、可用性檢查與執行時初始化——提交說明明確目標是”防止非 CUDA 平臺在訓練初始化與執行中誤用 CUDA 或 Musa 專用 API”；#154 讓 rerun 狀態機使用平臺裝置；#151 修外掛側平臺名與裝置名；#149 讓專家資料並行使用程序組 world size；#150 去掉流水線並行的重複 P2P 通訊器 stage 屬性。
  • TransformerEngine-FL #118：讓注意力路徑遵守”禁用 flash attention”的開關（此前該標誌未被尊重）。
  • FlagScale #1291：新增 KERV 最佳化執行時運算元。
  • FlagPrism #10：為摩爾執行緒加入 profiler 與 debugger 支援並更新文件（對應 FEP 中”FlagTree DevTools”的落地）。
  • FlagOS-Compressor #7：合入逐選擇器量化（per-selector quantization）特性分支。

解讀：Megatron-LM-FL 的五條提交構成一條清晰主線：把”CUDA 或 Musa 專用 API”從訓練主鏈路裡剝離出來。對以多晶片為目標的重型訓練框架，這類改造是接入新加速器的前置條件——只要初始化、DDP、裝置放置任一處仍假設 CUDA，非 CUDA 平臺就只能靠分支補丁活著。#156 與上一視窗的同類動作合併來看，訓練框架側正在把”平臺差異”從分散的 if 分支收進統一平臺 API；這與 FlagCX 收 PAL 抽象、FlagTree 收後端抽象是同一套工程語彙在不同層次上的重複出現。

二、新聞報道與生態

2.1 元件級檢索第十個連續平靜視窗：技術資訊面全部來自程式碼倉庫（09-11~09-14）

來源：Google News RSS 中英文 18 組查詢詞（走代理）、HN Algolia（FlagOS / FlagGems / FlagScale / FlagTree 四組）、FlagOS 官方社群站版本與直播列表、Tavily/web 檢索

  • 元件級查詢全部零命中：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen、FlagOS-Robo、FlagQuantum（when:7d~14d，中英雙語）、BAAI open source 在視窗內均無有效命中，構成為元件級檢索的第十個連續平靜視窗（上一視窗為第九個）。
  • HN 側無有效條目：四組查詢在視窗內返回的條目為通用技術討論（GrapheneOS 投稿被 flag、DietPi v10.7、若干 Show HN 專案），與 FlagOS 元件無關聯，按既有口徑全部剔除。
  • 成員單位詞命中以資本市場內容為主：燧原 when:2d（46 條）、沐曦 when:2d（27 條）、摩爾執行緒 when:2d（23 條）、海光 when:2d（11 條）、智源研究院 開源 when:7d（7 條）、天數智芯 when:2d（6 條）、地平線 開源 when:2d（1 條）；其中資本市場與轉載類佔絕大多數，智源社群文章（AI 大會、開源模型解讀等）與 FlagOS 技術棧無直接關聯，含”體育/登入/入口/官網/下載/博彩”字樣的 SEO 稿件整批剔除。經篩選保留的產業條目見 2.2。
  • 官方社群站無視窗內新版本：FlagOS 官方社群站的最新圖文釋出仍為 08-28（GLM-5.3-Flash Day0 適配 9 款晶片），視窗內新增的僅為直播/活動條目，與程式碼倉庫側的密集動作形成對比。

解讀：第十個連續平靜視窗本身是一條資訊——FlagOS 的對外可見度仍主要由程式碼與版本節奏構成，行業報道尚未形成對元件的持續跟蹤。對使用者而言，這意味著”元件是否在動”的答案必須從倉庫而不是從新聞裡讀；本期 173 條提交與零新聞的落差，也說明 2.2 GA（09-28）之前社群把注意力留在交付面而非宣講面。

2.2 產業側三件事：移動雲異構推理系統釋出、燧原上市首日收官、沐曦解禁視窗臨近（09-11~09-13）

來源：IT之家（09-13）、財聯社/科創板日報（09-13）、證券時報（09-11 12:22）、財聯社（09-11 21:00）、新浪財經（09-13/09-14）

  • 國內首個”國產 GPU + 類腦晶片”大模型異構混合推理系統釋出（09-13 報道，09-11~13 釋出）：在河北廊坊舉行的 2026 中國算力大會上，移動雲公司聯合中國電子科技南湖研究院、北京靈汐科技、上海天數智芯、清華大學、北京大學釋出該系統。技術路徑是對 Transformer 做 PD/AF 分離——Prefill 與 Attention 交給國產 GPU，FFN（MoE 專家）等延時敏感模組交給類腦晶片，利用其存算一體與片上大容量 SRAM 的頻寬優勢；團隊自研模型編譯器、高速互聯協議與統一推理引擎完成任務拆解、協同排程與結果聚合，方案對標英偉達下一代 Vera Rubin with Groq 異構推理架構。實測為 3 臺天數智芯 GPU 伺服器搭配 3 臺類腦機櫃執行 DeepSeek V4 Flash，相較同等投入規模的純 GPU 叢集，推理輸出與推理能效均提升一倍以上、業務運營成本下降 40% 以上；專案累計 15 項授權發明專利、6 項軟體著作權，目前已進入小批次試產。
  • 燧原科技登陸科創板，首日收盤漲 179%（09-11）：發行價 142.18 元/股、發行 4303.52 萬股、募資總額約 61.2 億元；開盤 410 元（較發行價 +188.37%）、盤中最高 475 元、收盤 397 元（+179%），全天市值約 1709 億元、換手率 76%；網上有效申購倍數 6109 倍、中籤率 0.0246%。公司尚未盈利，依規納入科創成長層；2023 至 2025 年營收 3.01/7.22/9.90 億元，2026 上半年營收 11.20 億元、同比增長 279.08%；其為四家國產 GPU 企業中唯一押注 DSA 專用架構、不相容 CUDA 生態的一家。隨著燧原掛牌，”國產 GPU 四小龍”（摩爾執行緒、沐曦、燧原、壁仞）全部完成資本化。
  • 沐曦解禁視窗臨近（09-13 預告，09-17 生效）：沐曦股份 1396.6 萬股限售股將於 9 月 17 日解禁，對應市值約 68.29 億元，規模約佔流通盤的 75%；同期報道稱其 9 月股價跌近 30%、較高點已跌超 50%。背景資料（08-30 半年報，非本視窗）：2026 上半年營收 13.24 億元、同比增長 44.67%，歸母淨利潤 6.12 億元實現扭虧（扣非仍為 -0.49 億元），其中二季度淨利 7.11 億元；公司已於 2026-06-12 公告擬發行 H 股，啟動 A+H 雙平臺佈局。

解讀：三件事分別處在不同層面——移動雲的異構推理系統是技術路線層面的訊號（GPU 不再被視為唯一算力形態，類腦晶片以”頻寬敏感模組”的定位進入推理鏈路，且天數智芯是這套系統裡的 GPU 提供方）；燧原與沐曦則是資本層面的訊號（四小龍全部資本化後，市場關注點從”能不能做出來”轉向規模交付與盈利兌現，沐曦的解禁視窗則是這一轉向的直接壓力測試）。對 FlagOS 的關聯意義在於：這兩類訊號都在抬高”多晶片統一軟體棧”的實際價值——異構推理系統需要編譯器與統一推理引擎來排程兩類算力，而國產 GPU 進入規模化交付後，其軟體棧的遷移成本直接決定訂單能否落地。

2.3 社群活動與競賽：SGLang 跨晶片運算元最佳化賽與運算元賞金賽分享會，競賽產出開始進入主倉（09-11~09-12）

來源：FlagOS 官方社群站（活動與直播列表）、FlagGems-sglang 倉庫視窗內合入記錄

  • SGLang 跨晶片運算元最佳化賽：由眾智 FlagOS 與 IEEE 聯合主辦、SGLang 協辦，賽道一為 SGLang 框架運算元多芯效能最佳化，設 200 餘道真實推理運算元題，參賽者自由選題、分批開放，使用 Triton / Triton-TLE 開發，多款晶片平臺統一驗證、統一測加速比，配實時排行榜與”全域攻佔獎/攻克突破獎/單題極致效能獎”三類獎項。
  • 運算元賞金挑戰賽冠軍分享會：官方社群站記錄了 09-10 19:00 的獲獎選手分享直播（心路歷程、關鍵決策、避坑方法、實戰技巧與互動答疑），為持續性賽事系列的一環。
  • 競賽產出進入主倉：FlagGems-sglang 在 09-12 的 40 分鐘內合入四條來自 competition/ 與參賽者個人分支的 PR（add-chunk-local-cumsum-vec、add-context-attention、qkv-lora-b、chunk-state-varlen-v2），全部指向 SGLang 推理鏈路上的 chunked attention 與 LoRA 相關運算元。
  • 生態活動：眾智 FlagOS 社群主辦的《開放 AI 計算：面向多元異構硬體打造開源軟體新生態》論壇於 09-07 在上海 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大會同場舉辦（智源、上海人工智慧實驗室、PyTorch 基金會、SGLang 等參與）。

解讀：競賽產出以 PR 形式進入 FlagGems-sglang 主倉，是本期最容易被低估的一條。社群競賽常見的問題是”排行榜上很熱鬧、主倉裡沒變化”，而四條 competition/ 分支在同一上午合入 master，說明題源、驗證環境與主倉之間已經接通——競賽事實上成了運算元產能的一條外部供給線，而這些運算元會隨下一個 rc1.postN 進入 2.2 釋出清單。這也解釋了 1.8 中”外掛層把測試改為廠商無關”的動作：要統一測加速比，測試與基準就必須先做到跨廠商可比。

三、成員單位深挖

3.1 燧原科技：科創板敲鐘收官”國產 GPU 四小龍”資本化，技術面同步修 enflame 裝置適配（09-11）

來源：證券時報（09-11）、財聯社（09-11）、FlagCX #580（09-11 17:02）

  • 資本面：09-11 登陸科創板（688801），發行價 142.18 元/股，開盤 410 元、收盤 397 元（+179%），市值約 1709 億元；四家國產 GPU 企業全部完成資本化，”最後一塊拼圖”到位。招股與財報口徑顯示其 2026 上半年營收 11.20 億元、同比增長 279.08%，2023 至 2025 年累計研發投入 36.76 億元，截至 2025 年末研發人員 643 人（佔員工 76.73%），承擔 12 項國家及地方科技攻關專案、參與 58 項 AI 晶片與智算系統關鍵國家及行業標準制定。
  • 技術面（視窗內）：FlagCX #580 修正燧原（enflame）裝置介面卡中 topsDeviceProp 的型別名，屬通訊庫平臺抽象層的廠商適配修補。
  • FlagOS 內位置：燧原在 build-infra 的應用矩陣中仍以 enflame-tops1.9.10 與 enflame-tops1.10.6 兩條 sglang 線路存在，在 FlagCX 的 .deb 後端清單中為已啟用的探測透過項之一。

解讀：燧原是四小龍中唯一走 DSA 專用架構與自研軟體棧路線的企業，這也決定了它與 FlagOS 的關係更偏”軟體棧自持 + 選擇性接入”——其 enflame-tops 兩條應用線在 FlagOS 矩陣內長期存在，但本視窗的技術動作只有一條型別名修正，屬維護性而非擴張性。相比之下，同視窗天數智芯、清微、海光在後端與應用線上都有實質推進。資本化完成後，燧原的下一道關是研發變現與訂單兌現，這一點會直接反映在其是否繼續擴大在多晶片軟體棧內的投入。

3.2 天數智芯：進入移動雲異構推理系統，同時在 FlagOS 內五條工作面並行（09-11~09-13）

來源：IT之家（09-13）、FlagBLAS #115（09-12 17:31）、build-infra #867/#869/#870/#871（09-12）、build-infra #875/#877/#878（09-13）、FlagTree #1153（09-13 22:28）

  • 產業面：移動雲牽頭髮布的”國產 GPU + 類腦晶片”異構混合推理系統中，天數智芯是 GPU 提供方（3 臺天數智芯 GPU 伺服器 + 3 臺類腦機櫃，執行 DeepSeek V4 Flash），承擔 Prefill 與 Attention 計算。
  • FlagOS 內五條工作面：其一，FlagBLAS 的 L2 級別支援合入 master（+5325 行）；其二，build-infra 的 sglang 應用線新增 sglang0.5.18-iluvatar-corex4.4.0（配置校驗 + changelog + 映象 tag）；其三，vllm 側把 0.24.0 的 corex4.4.0/4.5.0 收斂到統一 plugin wheel；其四，FlagTree 把 iluvatar 的 vLLM benchmark 加入 CI 工作流；其五，FlagCX 的 .deb 後端清單中 iluvatar-corex4.4.0/4.5.0 同時啟用。

解讀：天數智芯是本期出現頻率最高的成員單位，且技術線與產業線互不重疊——產業側是”作為國產 GPU 進入異構推理系統”，FlagOS 側是”基礎庫 + 應用線 + 基準 + 打包”四層同時推進。這兩件事在邏輯上是互補的：異構推理系統對頻寬敏感模組的切分，最終要靠運算元庫、編譯器與通訊庫來落地排程，而 FlagOS 正是這類系統最直接的軟體底座候選。值得注意的是 FlagTree 側把基準寫進 CI，意味著天數智芯的效能資料此後會以持續記錄而非一次性報告的方式存在。

3.3 清微智慧：vLLM 0.20.2 應用線開啟，端到端驗證與映象 tag 閉環（09-13）

來源：build-infra #872（09-12 21:09）、#873（09-13 10:27）、#874（09-13 20:10）

  • 應用矩陣補鍵：清微後端 tsingmicro-tsm260610 此前只帶 vllm0.24.0，導致 --app vllm0.20.2 的輸出為空、構建作業靜默跳過；#873 補上 vllm0.20.2: [] 後該行進入構建矩陣，並附 changelog 與待發布條目。
  • 驗證閉環：#872 記錄 0.20.2 的 F/T 端到端結果，#874 記錄映象 tag 2.1.2-0.2.1_g90ffdf0.d20260912，外掛 pin 到驗證所對的 VPF #489 頭部；FlagCX .deb 後端清單中 tsingmicro-tsm260610 亦為已啟用項。
  • 延續面：上一視窗建立的 tsingmicro3.6 build-and-test 與 delivery 兩條工作流（FlagTree 側）在本視窗無新增，屬常規交付線執行狀態。

解讀：清微這條線的價值不在新增能力，而在暴露了一類系統性風險——應用矩陣的缺鍵會讓構建靜默跳過。在一個覆蓋十餘家廠商、每家有多個版本組合的矩陣裡，”沒有報錯但什麼也沒構建”比構建失敗更難察覺。補上這一行之後，清微在 vLLM 側同時具備 0.20.2 與 0.24.0 兩條線，加上 FlagTree 的雙工作流與 FlagCX 的 deb 後端，其接入深度已與最早一批成員單位相當。

3.4 海光資訊：通訊庫 deb 後端打通、vLLM 工作流開啟、運算元批次補齊三線齊動（09-11/09-12）

來源：vllm-plugin-FL #436（09-11 10:54）、build-infra #866（09-12 18:25）、FlagCX #588（09-12 23:56）、FlagGems-vllm #756（09-12 12:08）、FlagGems-Experimental #586（09-11 18:50）

  • 通訊庫 .deb 後端打通（#866）：海光 DTK 後端從”探測待定”進入已啟用狀態，其間解決三類環境問題——DTK 不匯出 CUDA_PATH 導致 DEVICE_HOME/CCL_HOME 為空、-lnccl 實際解析到 RCCL（產物 NEEDED 為 librccl.so.1）、以及 DTK 映象的 BASH_ENV 鉤子汙染 verify 的 ldd 環境。
  • 外掛與 CI：#436 為 vLLM 0.24.0 啟用海光工作流；#588 把海光 CI 映象固定到 SHCA 之前的 digest，避免上游映象漂移。
  • 運算元面：FlagGems-vllm 補 persistent_topk 並接入 fused __init__；FlagGems-Experimental 一次性補入十餘個海光反向與特函式運算元（reflection_pad1d_backward、embedding_bag_dense_backward、mse_loss_backward、binary_cross_entropy_backward、lift_fresh、baddbmm_ 等）。

解讀：海光本視窗的動作密度在成員單位中最高，且三線性質互補——通訊庫側解決的是”能不能裝得上”（DTK 的路徑、RCCL 命名、ldconfig 三個特例都是廠商工具鏈的真實摩擦點，且都被寫進提交說明而不是留在某人的機器上），外掛側解決的是”能不能跑起來”，運算元側解決的是”覆蓋面夠不夠”。一個值得留意的細節是把 CI 映象固定到 digest：在多廠商流水線裡，構建環境的確定性往往比程式碼本身更容易被忽視，海光線在此主動加固。

3.5 摩爾執行緒與沐曦：生成運算元與後端運算元兩批落地，產業側資本節奏分化（09-11~09-13）

來源：FlagGems #6174、#6175、#6170、#6180（09-11 18:17~18:21）、FlagPrism #10（09-11 21:24）、FlagGems-vllm #771（09-11 18:07）、FlagSparse #58（09-11 07:44）、新浪財經（09-13/09-14）

  • 摩爾執行緒：KernelGen 路線批次入庫四個專用運算元（conv_transpose1d、upsample_linear1d_backward、fmod_、matmuladd）；FlagPrism 為其加入 profiler 與 debugger 支援並更新文件；FlagDNN 補摩爾執行緒 README；FlagCX 的 .deb 後端清單中啟用 mthreads-musa4.3.6 與 mthreads-musa5.2.0 兩條；產業側京東雲十萬卡叢集的訊息延續（原事件 09-09，已在前一期收錄，本視窗內為轉載與分析稿，不重複計入）。
  • 沐曦：FlagGems-vllm 最佳化 GDN chunk kernel（#771）；FlagGems-Experimental 約 35 條 MetaX 相關提交（新增支援與修復實現交錯）；FlagSparse 加入 metax 支援；FlagCX .deb 後端清單中沐曦對應線未在本視窗啟用。
  • 產業側分化：沐曦 09-17 將迎來 1396.6 萬股解禁（約 68.29 億元），視窗內多篇報道聚焦其股價回落與解禁壓力；摩爾執行緒視窗內新增”MT Lambda”商標註冊申請的公開記錄。

解讀：兩家在技術面上都處於”運算元批次補齊”階段，但產能來源不同——摩爾執行緒的四個運算元來自 KernelGen 生成路線，沐曦的批次則集中在 FlagGems-Experimental 的手寫實現與修復。產業側的分化同樣清晰：沐曦進入解禁與股價承壓週期，摩爾執行緒則處在十萬卡級訂單敘事的上升段。對 FlagOS 而言，兩家的技術投入節奏並未隨資本市場波動而減速，本視窗各自的提交量都在成員單位中位居前列。

3.6 崑崙芯（外部生態方）：編譯器側大幅同步，但通訊庫被記錄為”不可交付”（09-11/09-12）

來源：FlagTree #1155（09-11 17:55）、FlagGems #6093（09-11 18:59）、build-infra #857/#861/#862/#864（09-12）、build-infra #868（09-12 21:08）

  • 編譯器側：FlagTree 的 XPU 叢集同步是本期最大單筆提交（+17604/-1775），引入整套分析框架與 XPU 專屬 pass、P-TLE raw 前端與 UnrollControl 預算傳遞。
  • 運算元側：FlagGems 把崑崙芯的 copy 家族運算元遷到 TLE 實現（#6093），與編譯器側的 TLE 推進呼應。
  • 應用線：build-infra 讓 kunlunxin-xre5.37.1 在 sglang 線可構建可驅動，並完成 F/T 驗證、changelog、映象 tag 與 status matrix 記錄。
  • 邊界記錄：FlagCX 把 kunlunxin-xre5.37.1 明確記為”不可交付”——CCL 庫不在 .deb 構建所用映象內（base 映象不裝 CCL 包、XRE 5.37.1.0 載荷不含 xccl/bkcl，唯一的 libbkcl.so 位於廠商 torch wheel 內且匯出 C++ mangled 符號、無純 C 入口）。

解讀：崑崙芯在本視窗同時呈現”推進”與”限制”兩面。編譯器側的 +17604 行說明其內部分支與開源叢集的同步力度在加大；應用側走通了 sglang 的完整閉環；但通訊庫這一層被判定為當前不可交付，原因寫得非常具體（庫不在構建映象內、且即便找到也無法繫結）。這種”能編能跑、但通訊庫打不了包”的邊界，正是多晶片軟體棧最需要被顯式管理的狀態——它決定了該後端能支援單機推理還是能支援多機通訊密集場景。

3.7 智源（牽頭方）：2.2 測試期紀律與 RC1 清單維護，GA 定在 09-28（09-11）

來源：community #108（09-11 11:45）、community 倉庫 2.2 時間表與 RC1 清單（raw 直取）

  • 測試期治理：2.2 週期為特性凍結 08-31 → 測試與穩定期 09-01 至 09-24（只收 bug 修復、不進新特性）→ GA 09-28；FEP 畢業標準要求覆蓋多晶片場景的 Test Plan 在測試期內驗收透過，未過部分單獨開驗收 issue 掛在 milestone 上。
  • 清單維護：視窗內唯一清單改動是把 FlagGems 由 v5.4.0-rc1.post1 推進到 v5.4.0-rc1.post2，並把四類修復（cost model 回退、randperm 排序、int64 溢位、子包打包）寫進提交說明。
  • 版本面：FlagTree 三條 triton 線在清單中的記錄為 0.7.0rc1.post1+triton3.x，FlagCX 為 v0.14.0-rc1.post1，全清單 25 條元件快照。

解讀：牽頭方在本視窗的動作全部是治理型的——維護清單、執行凍結紀律、把驗收標準寫成可核查的 Test Plan。這類工作在對外報道里不可見，但它決定了 09-28 那天能否給出一個”每個元件都有 tag、每個 tag 都經過多晶片驗證”的交付面。與工程側（FlagCX 打包、各廠商應用線）的動作合起來看，2.2 的核心問題已經不是”支援多少晶片”，而是”這些支援能否被複現、被安裝、被審計”。

四、總結

  1. 交付面成為本視窗主線，通訊庫是第一個被徹底工程化的元件（最重要變化）：FlagCX 走通了”在廠商 base 映象內按後端打 .deb → 釋出到按 Ubuntu 版本切分的 apt 倉庫 → 以使用者的方式讀回驗證”的完整鏈路，並一次性啟用六個後端；配套約束（釋出件必須與剛驗證的檔案同一份、publish 不得繞過 verify、非 tag ref 不許釋出）表明這一層是帶審計意識建設的。此前 FlagCX 的可用性等於”使用者能否自己對著廠商 SDK 編出來”，此後等於一條 apt-get install。

  2. 2.2 進入測試期後半段，版本推進完全由修復驅動：RC1 清單 25 條元件快照就位，視窗內唯一清單改動是把 FlagGems 推到 v5.4.0-rc1.post2（四項修復：cost model 回退、randperm 排序、int64 偏移溢位、子包打包缺失）；天數智芯 0.24.0 明確放棄一個會汙染共用模組的 T 路徑修復以保住已驗證的 4.5.0 路徑——”寧可不修，也不破壞已驗證的格子”是 RC 紀律在程式碼裡的直接形態。GA 定在 09-28，測試期 09-01 至 09-24。

  3. 應用矩陣的”閉環五步”成為可複製工序，缺鍵風險被暴露：讓後端可構建 → 跑 F/T 驗證 → 落 changelog → 記映象 tag → 進 status matrix，本視窗由崑崙芯（sglang xre5.37.1）與天數智芯（sglang corex4.4.0）各走完一遍；清微的問題（deps_app 未寫全導致構建被靜默跳過）則提示這一矩陣已具備”沒報錯但什麼都沒構建”的失效模式，配置完整性本身就是釋出面的一部分。

  4. 外部後端繼續加碼，且首次出現被顯式記錄的交付邊界：崑崙芯 XPU 叢集同步（+17604 行）、天數智芯 L2 庫與基準入 CI、清微開啟 vLLM 0.20.2、海光 DTK deb 後端打通——四條線同時推進；與此同時崑崙芯通訊庫被記為”不可交付”並寫明原因（CCL 庫不在構建映象內、無純 C 入口）。軟體棧的價值不再只由”支援幾家晶片”衡量，也由”每家支援到什麼程度”的可陳述邊界衡量。

  5. 運算元產能呈三路並進，競賽開始成為外部供給線：FlagGems 21 條提交中，昇騰走 KMCompiler 逐個補齊、NVIDIA 與摩爾執行緒走 KernelGen 批次入庫、崑崙芯走 TLE 改造；FlagGems-Experimental 的 54 條裡，海光一次性補入十餘個反向與特函式運算元、沐曦約 35 條”新增 + 修復”交錯。更具長期意義的是 FlagGems-sglang 在 09-12 上午 40 分鐘內合入四條來自跨晶片運算元競賽的 competition/ 分支 PR——競賽產出首次以主倉提交的形式落進發布清單。

  6. 產業側兩條線索抬高多晶片軟體棧的實際權重：移動雲聯合靈汐科技、天數智芯等釋出國內首個”國產 GPU + 類腦晶片”異構混合推理系統（PD/AF 分離，3 臺天數智芯 GPU 伺服器 + 3 臺類腦機櫃跑 DeepSeek V4 Flash，效能與能效提升一倍以上、成本降 40% 以上），說明異構算力排程已進入工程化階段；燧原登陸科創板首日收漲 179%、四小龍全部資本化，沐曦則面臨 09-17 的 68 億元解禁視窗——國產 GPU 的關注點從”做出來”轉向規模交付與盈利兌現，而遷移成本與叢集穩定性正是這一轉向中最依賴系統軟體棧的兩個變數。

預判：後續觀察面四點——其一，09-28 GA 前 rc1.postN 的遞增節奏與清單中還有哪些條目會再迭代一輪；其二，FlagTree 在清單中的記錄（0.7.0rc1.post1+triton3.x）是否會推進到正式 release tag，以及 build-infra 的 NVIDIA 線 pin 值是否從 0.6.1 跟上主線（上一視窗指出的版本錯位仍在）；其三，FlagCX 的 apt 倉庫是否出現首批真實使用者安裝反饋、以及沐曦等未啟用後端何時補齊；其四，崑崙芯通訊庫的”不可交付”狀態是否會被反轉（例如 XRE 後續版本攜帶 CCL 並暴露純 C 入口），以及移動雲異構推理系統的規模化試產是否會帶出對 FlagOS 運算元/編譯器層的具體需求。

附錄：完整信源清單

信源 視窗核心查結果
GitHub org repos API（flagos-ai，53 倉） 21 倉視窗內推送：FlagGems、build-infra、FlagGems-Experimental、FlagQuantum、FlagCX、FlagGems-vllm、Megatron-LM-FL、FlagTree、FlagBLAS、FlagGems-sglang、FlagDNN、FlagSparse、FlagScale、FlagPrism、vllm-plugin-FL、TransformerEngine-FL、FlagOS-Compressor、community、sglang-plugin-FL、docs、release-info；無新倉庫；GitHub Releases 無視窗內新條目
GitHub commit search（org 全量 150 條，5 頁，sort=committer-date） 11 倉預設分支實質合入：FlagGems-Experimental 54 / build-infra 33 / FlagGems 21 / FlagQuantum 15 / FlagCX 7 / FlagGems-vllm 6 / FlagTree 4 / FlagBLAS 4 / FlagGems-sglang 4 / FlagPrism 1 / FlagScale 1
per-repo commits 複核（活躍但未入 search 的倉庫） 補入 23 條：FlagSparse 10、Megatron-LM-FL 5、FlagDNN 4、vllm-plugin-FL 1、FlagOS-Compressor 1、TransformerEngine-FL 1、community 1；sglang-plugin-FL、docs、release-info 三倉預設分支無視窗內新提交（分支/標籤推送）
GitHub commit 詳情與補丁 #847（+2449 行，.deb 打包與 verify 口徑）；#851（+85/-25，apt 倉庫釋出與 publish/verify 約束）；#865（+147/-75，六後端啟用與 devApiBackend 未定義符號）；#866（+32/-19，DTK 路徑/RCCL/BASH_ENV）；#868（+30/-11，崑崙芯不可交付原因）；#873（+46，deps_app 缺鍵與 0.20.2 開啟）；#875（+20/-6，統一 plugin wheel 與放棄 T 路徑修復）；#1155（+17604/-1775，XPU 叢集同步與內部來源 5a664566）；#156（+103/-54，平臺感知裝置 API）；FlagCX #578（+5309/-1292，net adaptor 重構）
community 倉庫 2.2 釋出材料（raw 直取） release/2.2/release-2.2-rc1.yaml 共 25 條元件快照；release/2.2/schedule_CN.md 寫明特性凍結 08-31、測試與穩定期 09-01~09-24、GA 09-28、FEP 畢業標準與 [URGENT] 例外通道；清單檔案視窗內唯一改動為 #108（FlagGems → v5.4.0-rc1.post2，tag 指向 rc1 分支頭 270bebe1，含四項修復）
Google News RSS（中英文 18 組查詢詞，走代理） 元件級查詢（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/KernelGen/FlagOS-Robo/FlagQuantum/BAAI open source）全部零命中，第十個連續平靜視窗；成員單位詞命中中，保留移動雲異構推理系統、燧原上市、沐曦解禁三類條目；智源社群常規文章與博彩類 SEO 稿件整批剔除
HN Algolia（FlagOS / FlagGems / FlagScale / FlagTree） 視窗內返回條目為通用技術討論（GrapheneOS、DietPi v10.7、Show HN 系列），與 FlagOS 元件無關聯，全部剔除
FlagOS 官方社群站（版本與活動列表） 最新圖文釋出仍為 08-28（GLM-5.3-Flash Day0 適配 9 款晶片），視窗內無新版本；視窗內新增為活動條目：SGLang 跨晶片運算元最佳化賽（眾智 FlagOS × IEEE 主辦）、09-10 運算元賞金挑戰賽冠軍分享會、09-07 KubeCon 上海《開放 AI 計算》論壇
Tavily/web 檢索（原站核日期） 移動雲異構推理系統：IT之家 09-13、財聯社/科創板日報 09-13（3 臺天數智芯 GPU 伺服器 + 3 臺類腦機櫃、DeepSeek V4 Flash、效能與能效提升一倍以上、成本降 40% 以上、15 項專利 + 6 項軟著、小批次試產）；燧原上市：證券時報 09-11、財聯社
09-11（發行價 142.18 元、開盤 410 元、收盤 397 元、市值約 1709 億元、換手 76%、中籤率 0.0246%、2026H1 營收 11.20 億元 +279.08%）；沐曦解禁：新浪財經 09-13/09-14（1396.6 萬股、68.29 億元、約佔流通盤 75%）    
  已核實但不重複計入的條目 京東雲與摩爾執行緒十萬卡叢集（原事件 09-09，已在前一期收錄，視窗內為轉載與分析稿）；沐曦 2026 半年報（08-30 披露，僅作背景資料）

侷限性說明：本期技術資訊面仍以程式碼倉庫為準，產業報道僅用於成員單位資本與產品動態的對照；Google News RSS 經代理訪問，命中量與覆蓋度受聚合源收錄節奏影響，元件級查詢連續零命中已連續十個視窗。FlagOS 官方社群站圖文更新滯後於倉庫動作（最新圖文 08-28），社群活動資訊取自其站內活動列表。企業財務與市場資料來自公開報道，未做進一步交叉驗證。