調研視窗：2026-09-10 10:18 ~ 2026-09-11 10:18 北京時間 信源：GitHub（org: flagos-ai，53 個倉庫 pushed_at + 單次 commit search 60 條按 committer-date 全量核驗 + per-repo commits 複核 + 分支 API + commit 詳情與補丁）、Google News RSS（中英文 13 組查詢詞，走代理）、HN Algolia、Tavily/web 檢索、FlagOS 官方 CSDN 號、智源社群（詳見附錄）

索引

  • 一、開源專案進展（GitHub 動態）
    • 1.1 FlagTree 版本收斂至 0.7.0：29 條廠商交付工作流一次性切換（09-10/09-11）
    • 1.2 build-infra：昇騰 910C 應用層正式開放，vLLM 雙版本四映象進入矩陣（09-10）
    • 1.3 build-infra：sglang0.5.18 啟動文件全矩陣生成，sglang 升為一等應用線（09-10）
    • 1.4 build-infra：打包通道政策成文，安裝渠道邊界被固化（09-10）
    • 1.5 FlagTensor：海光 DCU 與崑崙芯 XPU 雙後端合入主線，安裝指令碼收斂（09-10）
    • 1.6 vllm-plugin-FL：曦望 Sunrise 注意力後端移植 vLLM 0.24.0，達摩院玄鐵靜態圖恢復（09-10）
    • 1.7 FlagGems：KMCompiler 的 Ascend/MetaX 雙線推進與安裝面缺陷修復（09-10）
    • 1.8 領域庫與工具鏈：FlagGems-vllm 海光運算元、FlagDNN 後端文件、FlagCX MUSA、Torch-FL DCU 路由（09-10）
    • 1.9 FlagTree 工程面：清微 CI/CD 成建制，TLE NVIDIA 佈局最佳化當日合入當日回退（09-10）
  • 二、新聞報道與生態
    • 2.1 元件級新聞第九個連續平靜視窗，資訊面全部來自程式碼倉庫（09-10）
  • 三、成員單位深挖
    • 3.1 清微智慧：編譯器線從”後端能編”進入”流水線自持”（09-10）
    • 3.2 海光資訊：運算元、張量庫、領域庫文件、執行時路由四條線同時推進（09-10）
    • 3.3 崑崙芯：FlagTensor XPU 後端合入，四層工作面並行（09-10）
    • 3.4 曦望芯科與達摩院玄鐵：外部推理 GPU 與 PPU 後端同視窗加碼（09-10）
    • 3.5 智源（牽頭方）：交付流水線版本統一與打包政策兩項治理動作（09-10）
  • 四、總結
  • 附錄：完整信源清單

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

視窗總覽：org 內 53 個倉庫中 13 個在視窗內有推送；commit search 命中 60 條視窗內提交（單頁全量，committer-date 降序），經 per-repo commits 複核另補入 Megatron-LM-FL 1 條（search 索引滯後未收錄），合計 61 條，分佈於 12 個倉庫：build-infra 24、FlagGems 10、FlagTree 8、FlagTensor 5、vllm-plugin-FL 3、FlagDNN 3、FlagGems-vllm 2、Torch-FL 2、flir 1、FlagFFT 1、FlagCX 1、Megatron-LM-FL 1。無新倉庫、無新元件 release 條目。

本視窗形態 = RC 測試期的”版本收斂 + 晶片矩陣擴張”雙線：編譯器側 FlagTree 完成 0.7.0 的版本號收斂並把 29 條廠商交付流水線一次性切到 0.7.0；交付側 build-infra 把昇騰 910C 從”隻立 base/runtime 骨架”推進到應用層開放，並讓 sglang 成為與 vllm 並列的一等應用線；外部生態側出現曦望 Sunrise 的元件級後端落地與 FlagTensor 的海光 DCU、崑崙芯 XPU 雙後端合入。前一視窗”910C 何時補 deps_app 進入 app 構建矩陣”的預判在本視窗兌現。

1.1 FlagTree 版本收斂至 0.7.0：29 條廠商交付工作流一次性切換（09-10/09-11）

來源：FlagTree #1144（09-10 23:38）、#1151（09-11 02:31）

  • 主線版本號升到 0.7.0（#1144）：版本函式改為 "0.7.0+" + flagtree_backend + 提交雜湊（無後端字尾時返回 0.7.0 + 雜湊），提交內並行落地六項配套——PPU/HCU 的 qwen3.6 benchmark 效能基線重新整理、README 增加 tsingmicro3.6 說明、wheel 內補 LICENSE、TileIR 的 third_party 下載修復、Iluvatar 工作流的庫路徑修復；README 的廠商/後端表也由 “Installation” 改為 “User Guide” 並擴充。
  • 29 條廠商交付工作流統一切到 0.7.0（#1151）：*_delivery.yml 中的版本入參預設值由 '0.6.0' 一次性改為 '0.7.0'，同時更新 ppu3.6 核心測試工作流。涉及的 29 條線為：nvidia3.3/3.5/3.6/3.7/3.8、tileir3.6、amd3.6、ascend3.2/3.5、enflame3.5-gcu400/3.6-gcu400、iluvatar3.1/3.6、metax3.0/3.6、mthreads3.1/3.2/3.6、tsingmicro3.3/3.6、sunrise3.4、xpu3.0/3.6、hcu3.1/3.6、aipu3.3、thrive3.6、ppu3.6。
  • 分支側狀態：0.7.0-rc0-triton3.3/3.5/3.6 三線頭部分別停在 08-11、08-27、08-31；0.7.0-rc1-triton3.3/3.5/3.6 為 09-01、09-04、09-04，其中 rc1-triton3.6 的頭部提交即 [Tsingmicro] Add Tsingmicro backend integration (Triton 3.6)（#1071）。
  • 正式 release 尚未出現：GitHub Releases 上 FlagTree 最新條目仍為 0.6.0+triton3.x（2026-06-24），本視窗動作屬於”交付流水線先行、版本號收斂”，正式 tag 待發。

解讀：0.7.0 的推進方式很清楚地體現了 RC 期的紀律——不改程式碼路線，只做版本號與交付入口的收斂：先在 main 把包版本從 0.6.0 提到 0.7.0，再讓全部 29 條廠商交付流水線統一指向 0.7.0，從而把 RC1 清單裡”flagtree 三線統一 0.7.0rc1.post1”的錨點推向正式版本。一個值得跟蹤的錯位是：build-infra 的 configs.yaml 中 NVIDIA 線仍 pin 在 flagtree==0.6.1，即”已交付映象所鎖定的編譯器版本”與”編譯器主線版本”之間存在一個版本的推進差，這正是 GA 前需要抹平的縫隙。

1.2 build-infra：昇騰 910C 應用層正式開放，vLLM 雙版本四映象進入矩陣（09-10）

來源：build-infra #816（09-10 18:36）、#813（15:07）、#808（11:00）、#818/#819、#823/#824、#820、#825、#826、#828、#833、#834

  • 應用層開閘（#816，+257/-16）：提交說明寫明”910C 的 runtime 映象已構建並推送，因此 vllm 應用線可以在兩條 910C 線路（ascend-cann8.5.0-910c / ascend-cann9.0.0-910c）上開放”。同步新增 4 個 changelog——vllm0.20.2 與 vllm0.24.0 各自對應 CANN 8.5.0 與 9.0.0；改動覆蓋 vllm-app-image.yml、app/vllm/Containerfile、configs.yaml、docs/status-matrix.md、兩條 status_matrix.vllm*.yaml 與渲染指令碼。
  • 910C 應用映象 tag 開始落庫：#818/#819 記錄 CANN 8.5.0-910c 的 2.1.2-0.2.0_g2b6b635.d20260824 與 2.1.2-0.2.0_gcf8998c.d20260818，#823/#824 記錄 CANN 9.0.0-910c 的對應 tag。
  • 為開閘做準備的穩定化：#808 去掉 910C base 映象裡的 apt Post-Invoke 鉤子；#813 讓昇騰啟動模板暴露整對 die（同 die 內兩卡成對可見）；#820 讓 ascend 的 verify 失敗自診斷；#825 把 runner 代理轉發進 verify 安裝步驟；#826 選擇能 import ruamel.yaml 的 runner python；#828 修 verify Step 2 的引號轉義；#833 僅在目標 ref 含 stub 時構建 flashinfer stub；#834 把 cell 的外掛 pin 前遞給 vllm 應用映象構建。

解讀：這是前一視窗預判的精確兌現。09-10 報告的觀察點是 910C”以 910B 線晶片同構變體方式接入、用 deps_app 缺位攔在 app 矩陣之外”，當時預判”待 app 製品產出並驗證後再放開”。本視窗的 #816 就是那道門控被開啟：910C 交付形態從”base/runtime 可用”升級為”應用可用”，且一次性給出 2 條 CANN × 2 個 vLLM 版本 = 四個應用映象條目。配套的九條 verify/模板/映象修復說明這正是”可進新適配、不進新特性”紀律下的收尾工程——先讓 verify 自診斷、代理轉發、依賴選擇這類環境問題不再阻斷流水線，再放開矩陣。

1.3 build-infra：sglang0.5.18 啟動文件全矩陣生成，sglang 升為一等應用線（09-10）

來源：build-infra #831（09-10 21:38）、#817（19:13）、#821（19:20）、#829（20:42）、#830（20:55）

  • #831 修掉生成器過濾邏輯（+2862/-34）：提交說明指出生成器用 a in APP_IMAGE_DEFAULTS or a.startswith("vllm") 過濾 deps_app 鍵，導致 sglang0.5.18 在進入渲染器之前就被丟棄，此前沒有任何 sglang 應用映象具備啟動頁；修復後為全部 sglang 應用映象生成中英雙語啟動文件。
  • 覆蓋的 sglang 應用線：ascend-cann8.5.0 / ascend-cann9.0.0（昇騰）、cambricon-neuware4.4.3 / 4.7.2（寒武紀）、enflame-tops1.9.10 / 1.10.6（燧原）、hygon-dtk26.04（海光）、iluvatar-corex4.5.0（天數智芯）、metax-maca3.7.2.1 / 3.8.1.3（沐曦）等。
  • 配套：#817 把 iluvatar-corex4.5.0 拉到 sglang 0.5.18 線；#821 新增 sglang0.5.18-iluvatar-corex4.5.0 changelog；#829 修 changelog 中多餘的 image 鍵；#830 記錄 app image tag 2.1.2-0.1.dev1_g201484665。
  • 同期映象說明重新整理：#810 與 #814 分別重新整理 base 與 runtime 映象的 2.1.2 說明文案，#815 讓 flaggems-release 的 runtime:v1 映象 tag 從 configs.yaml 推導。

解讀：這條比表面看起來重要。vllm 與 sglang 是 FlagOS 對外交付推理能力的兩條主框架線，此前矩陣的實際形狀是”vllm 全量、sglang 零散”。本視窗的動作把 sglang0.5.18 在至少 10 條晶片線上補齊了啟動文件與 changelog，意味著 sglang 在交付口徑上已與 vllm 並列；這與本視窗 FlagGems-sglang 賽事線、09-07 報告記錄的”KubeCon 開放 AI 計算論壇”形成呼應——推理框架的覆蓋廣度正在成為社群對外展示的主要維度。

1.4 build-infra：打包通道政策成文，安裝渠道邊界被固化（09-10）

來源：build-infra #812（09-10 21:45）

  • 新增 docs/content/en/usage/packaging-channels.md（122 行）與 docs/content/zh-cn/usage/packaging-channels.md（97 行），把前期討論的結論固化為政策：deb/rpm 通道負責純 Python 包與原生庫（按目標發行版一倉一源），各廠商私有 PyPI 索引負責廠商側依賴，兩者的邊界被明確寫出。

解讀：這是 2.2 GA 前的治理型提交，與上一視窗的 60 個 app 映象 changelog 基線 + push 門控是同一脈絡：先能說清”製品從哪來”，再說清”依賴從哪裝”。對一個要覆蓋十餘家晶片廠商私有工具鏈的軟體棧而言，安裝渠道的政策化是多廠商分發能否規模化的前置條件。

1.5 FlagTensor：海光 DCU 與崑崙芯 XPU 雙後端合入主線，安裝指令碼收斂（09-10）

來源：FlagTensor #5153939 / #1be84f2（09-10 10:37 各一條）、#81c6214（10:39）、#2f895c1（10:47）、#efed2c4（10:48）

  • 兩條新後端合入：feat: merge Hygon DCU + Kunlunxin XPU backend support 把海光分支（含 FlagTensor-haiguang 的適配成果）合併進 main，統計為 +4225/-168（4393 行），改動主體是 benchmark 與後端適配層；同一分鐘另有一條 add Hygon DCU and Kunlunxin XPU backend support。
  • 安裝與文件面收斂：#2f895c1 把 setup_muxi.sh 合併為統一 setup.sh --backend metax 的一個分支；#efed2c4 刪除獨立指令碼；#81c6214 移除沐曦專用效能報告 PERF_REPORT_metax.md。

解讀：”後端數量 +2、維護面 -1 套專用指令碼”，方向一致：一方面把海光 DCU 與崑崙芯 XPU 兩類新硬體納入張量庫，另一方面把廠商專用安裝路徑收斂成統一入口，避免隨廠商數增長而線性膨脹的指令碼維護成本。FlagTensor 屬於 6 月”科學智慧基座”釋出的六大領域庫之一，其多後端擴張說明科學計算庫仍在按”一次開發、多芯執行”的目標鋪開。

1.6 vllm-plugin-FL：曦望 Sunrise 注意力後端移植 vLLM 0.24.0，達摩院玄鐵靜態圖恢復（09-10）

來源：vllm-plugin-FL #391（09-10 20:01）、#472（10:33）、#480（18:22）

  • #391（+37/-1）：標題為”把 Sunrise 後端移植到 vLLM 0.24.0”，提交說明寫明物件是 Sunrise（曦望 TANGRT 1.2.0），兩處改動都在 sunrise vendor 路徑下——attention.py 採用 CUSTOM 模式做注意力後端註冊，patch.py 增加 ptpu 的 memory_stats 相容層。
  • #472：恢復達摩院玄鐵（thead）後端的靜態圖支援（源自前期提交的迴歸修復）。
  • #480：為 PR 增加 /rerun-failed-ci 與 /cancel-ci 兩條評論命令；倉庫 README 的晶片廠商表已把 Sunrise 列為 Supported。

解讀：這是本視窗外部生態最實質的一步。09-07/09-08 視窗記錄到曦望的進展僅是”runner 環境配置先行、尚無元件合入”，本視窗則完成元件級落地——把曦望的工具鏈版本（TANGRT 1.2.0）接進 vLLM 0.24.0 的接入前哨外掛。對 FlagOS 而言，這說明”新晶片接入”的標準路徑（先用統一環境立 runner，再在 vllm-plugin-FL 落 vendor 後端）已經跑通一遍，是可複用的接入模板；#480 的兩條 CI 運維命令與 build-infra 的 verify 自診斷同屬”多廠商 CI 維護成本”的工程降本。

1.7 FlagGems：KMCompiler 的 Ascend/MetaX 雙線推進與安裝面缺陷修復（09-10）

來源：#6138、#5821、#6155、#6160、#6156、#6157、#6146、#6087、#6147、#6131

  • KMCompiler 生成路徑：[KMCompiler][Ascend] Opt replication pad2d backward（#6138）、[KMCompiler][Ascend] Add ascend backend for linalg_solve_triangular（#5821）、[KMCompiler][MetaX] Fix gru bug（#6155）——延續”一次開發、多後端落地”的運算元上新方式。
  • 廠商 CI 線收縮：fix(.github): remove metax-maca3720 info（#6160），繼前期移除 CI 條目後清理殘留資訊。
  • 安裝與執行正確性修復：#6146 補上缺失的 DSA/__init__.py，使非可編輯安裝包含該子包（直接關係下游外掛的安裝完整性）；#6087 把索引運算元的 pid_p 轉 int64，修 int32 偏移溢位；#6147 修 adaptive_avg_pool3d_backward 的排程指向錯誤；#6131 修 irshift 的 benchmark 命名。
  • 工程面：#6157 擴充套件 init exports 檢查；#6156 清理第三方檔案上誤加的 Apache 2.0 頭。

解讀：與上一視窗”39 條以 KernelGen 大流量運算元入庫為主”相比，本視窗主倉提交量降到 10 條，且結構由”上量”轉為”覆蓋與夯實”：生成器路徑繼續向昇騰、沐曦補後端，其餘則集中在安裝完整性與數值正確性。其中 #6146 這類”子包未被安裝”的缺陷對下游影響最大——vllm/sglang 外掛都依賴運算元庫的完整安裝面，這類修復正是 RC 期把”能跑”變成”裝得上、跑得對”的典型動作。

1.8 領域庫與工具鏈：FlagGems-vllm 海光運算元、FlagDNN 後端文件、FlagCX MUSA、Torch-FL DCU 路由（09-10）

來源：FlagGems-vllm #736、#704、Torch-FL #270、#247、FlagCX #576、FlagDNN、FlagFFT、Megatron-LM-FL #148

  • FlagGems-vllm：#736 [AdvancedCompiler] add hygon fused_add_rms_norm，新增 325 行海光專用運算元實現並註冊進 _hygon 後端，同時為舊版 Triton 加 TensorDescriptor 匯入保護；#704 為 moe_sum 增加 pair-load 快路徑。
  • Torch-FL：#270 perf: restore fused SDPA on the boxing route via a composite override（+658 行），根因寫在提交與隨附文件（docs/bench_qwen3_dcu_route_perf.md）中——aten::scaled_dot_product_attention 是 composite op，融合後端的挑選發生在 composite 內部，逐 leaf 被打散導致融合路徑丟失，改用 composite 層覆寫恢復；該工作明確針對 DCU 路由。另 #247 增加 transformers 測試的自動分診流水線。
  • FlagCX：#576 [PAL] Link default device API backend for MUSA platform，為摩爾執行緒 MUSA 平臺接線預設 device API 後端（makefiles/musa.mk）。
  • FlagDNN：連續三條後端文件提交——新增海光 readme、修正海光 readme、新增天數智芯 readme。
  • FlagFFT：更新 README 的後端支援說明並澄清依賴關係。
  • Megatron-LM-FL：#148 fix(platform): prefer native accelerator detection，平臺探測優先使用原生加速器識別。

解讀：這一組是”領域庫與訓練/推理工具鏈”的橫向鋪開：海光（運算元 + 張量庫 + 領域庫文件 + 執行時路由）、摩爾執行緒（通訊庫平臺接線）、天數智芯（文件）在同視窗各有動作。Torch-FL 的交付物有獨立基準文件與 stub 原始碼，屬於少見的”效能問題帶完整證據鏈”的提交，說明訓練/推理路線上的效能迴歸已被納入常規跟蹤。

1.9 FlagTree 工程面：清微 CI/CD 成建制，TLE NVIDIA 佈局最佳化當日合入當日回退（09-10）

來源：FlagTree #1118、flir #69、#1047、#1139（revert）、#1075、#1074、#1143

  • 清微側的編譯器基建（#1118，+344/-10）：修復 tsingmicro 後端與 FLIR 的聯合構建，並新增兩條工作流——tsingmicro3.6-build-and-test.yml（115 行）與 tsingmicro3.6-delivery.yml（191 行）；CMake 側新增 FlagTreeOptions 開關，third_party/tsingmicro 的 Tx81 執行時與示例測試同步修正；提交由清微側補丁與社群機器人共同署名。FLIR 側對應提交 #69 把清微的 FLIR 補丁同步以支援 LLVM 22（FLIR 是 FlagTree 的 IR 中間層，fork 自 triton-shared）。
  • TLE NVIDIA 佈局最佳化當日合入當日回退：#1047 於 12:35 合入”以 shuffle 下放同 warp 內的 layout 轉換”，13:47 即被 #1139 回退。同視窗的 MTHREADS 側保留兩條實質合入：#1074（SQMMA 配置在選擇中傾向純 M-split）、#1075（PH1 的 swizzled 共享訪存經 LinearLayout 下放）。
  • 其他：#1143 修燧原路徑下 of 名稱空間的 gcc7 編譯錯誤。

解讀：清微的這條線說明其已具備”自己帶構建與交付工作流”的能力，而不是等社群替其接線——對一個此前在 FlagTree 中只以 Triton 3.3 後端形態存在的廠商，這是相當完整的一步。相反，TLE NVIDIA 的當日回退值得作為工程節奏的註腳：在 RC 凍結期，效能最佳化如果引入迴歸，處理方式是當天回退而不是帶著問題推進，與”可進新適配、不進新特性”的紀律一致。

二、新聞報道與生態

2.1 元件級新聞第九個連續平靜視窗，資訊面全部來自程式碼倉庫（09-10）

來源：Google News RSS 中英文 13 組查詢（09-10 10:18 ~ 09-11 10:18，走代理）、HN Algolia、FlagOS 官方 CSDN 號、智源社群

  • 元件級查詢全部零命中：FlagOS when:2d、FlagOS when:14d、FlagGems when:3d/14d、FlagScale when:3d、FlagTree when:7d、FlagCX when:14d、FlagAttention OR FlagPerf when:14d、KernelGen when:7d、BAAI open source when:2d、沐曦 開源 運算元 when:2d 等中英文查詢均無命中，構成為元件級檢索的第九個連續平靜視窗。
  • 成員單位詞為噪音或資本市場內容：摩爾執行緒 智源 when:2d 命中 12 條，主體是京東雲十萬卡叢集的轉載與股價類報道（延續 09-09 視窗已錄內容）、以及博彩類 SEO 稿件；智源研究院 開源 when:2d 命中 9 條，為智源社群常規文章與博彩 SEO（含具身智慧類社群文章、AI 糾紛裁判等），與 FlagOS 技術棧無直接關聯，按既有口徑整批剔除。
  • HN Algolia 命中為子串誤匹配：FlagOS/FlagGems/FlagTree/FlagScale/BAAI 五組查詢的標題均為 flags/flagship 類無關條目（如”15x10 Pixel Flags”、Show HN 系列），無一條指向本技術棧，整批剔除。
  • 官方內容渠道無新發布：FlagOS 官方 CSDN 號視窗內無新文章，最新仍為 08-28 的 GLM-5.3-Flash Day0 適配 9 款晶片；09-07 的 KubeCon 同場論壇與運算元調優主題頁持續掛載、無釋出時點更新。智源社群與官網在視窗內亦無 FlagOS 相關新發布。

解讀：新聞側與程式碼側的分化在本視窗達到近期最大——61 條提交裡包含版本收斂、昇騰 910C 應用層開閘、sglang 全矩陣文件、兩條新後端合入等實質進展，而外部報道為零。這說明 FlagOS 當前的對外聲量並不隨工程進度同步，社群的資訊釋出仍集中在”模型 Day0 適配”與”大會論壇”兩類節點上；本視窗的進展要從交付與編譯器主線讀取，這一判斷對跟蹤節奏有直接影響。

三、成員單位深挖

3.1 清微智慧：編譯器線從”後端能編”進入”流水線自持”（09-10）

來源：FlagTree #1118、flir #69

  • 視窗內三條動作指向同一件事：FlagTree 新增 tsingmicro3.6 的 build-and-test 與 delivery 兩條工作流、修好與 FLIR 的聯合構建；FLIR 同步清微補丁以支援 LLVM 22；FlagTree README 變更日誌記錄”2026/09/10 清微後端升級到 Triton 3.6 並加入 CI/CD”。
  • 交付面：tsingmicro3.3 與 tsingmicro3.6 兩條線均在本視窗的 0.7.0 統一切換清單內。

解讀：清微此前在 FlagTree 中的形態是”基於 Triton 3.3 的後端整合”，本視窗後變成”自帶構建/交付工作流、對齊 LLVM 22 與 Triton 3.6 的常規交付線”。對成員的判斷價值在於：編譯器層面對新代際的支援已不依賴社群代工，說明清微側的編譯器團隊具備獨立維護能力；兩條產品線同時進入交付矩陣，也說明其代際切換已納入 FlagOS 的常規版本節奏。

3.2 海光資訊：運算元、張量庫、領域庫文件、執行時路由四條線同時推進（09-10）

來源：FlagTensor #1be84f2、FlagGems-vllm #736、Torch-FL #270、FlagDNN、build-infra #831

  • 本視窗海光出現四條分散但同向的動作：FlagTensor 合入 DCU 後端（+4225 行）；FlagGems-vllm 新增海光專用 fused_add_rms_norm（325 行）；FlagDNN 新增海光後端文件；Torch-FL 針對 DCU 路由恢復融合 SDPA 並留下基準文件。交付側另有 sglang0.5.18-hygon-dtk26.04 的啟動文件進入全矩陣。
  • 結合 09-09 視窗記錄的”海光 Token 經營雙芯加速方案”，海光在軟體棧內的動作已從早期的運算元專用化擴充套件到張量庫後端、領域庫文件與執行時效能路由。

解讀：海光是當前在 FlagOS 內工作面最寬的成員單位之一——運算元庫、張量庫、領域庫文件、推理外掛（sglang 應用線）、以及 Torch-FL 的執行時路由都有在跑的工作。其商業敘事（Token 工廠）與軟體棧覆蓋同步推進，意味著海光 DCU 在 FlagOS 中的定位正在從”被適配的晶片”轉向”深度共建成員”。

3.3 崑崙芯：FlagTensor XPU 後端合入，四層工作面並行（09-10）

來源：FlagTensor #1be84f2、FlagTree 交付線清單

  • 本視窗 FlagTensor 把崑崙芯 XPU 後端與海光 DCU 一併合入主線；交付側 xpu3.0 與 xpu3.6 兩條工作流納入 0.7.0 統一切換。
  • 與前期記錄串起來看：09-02 視窗 FlagGems 有崑崙芯後端 slice_scatter 越界修復，09-08 視窗 FlagScale 有崑崙芯 P800 的訓練 CI 與執行時支援，09-09 視窗記錄了 FlagGems-Experimental 的崑崙芯 KernelGen 運算元批次合入。

解讀：崑崙芯當前在”張量庫（FlagTensor）、運算元庫（FlagGems）、訓練框架（FlagScale）、編譯器交付（FlagTree xpu 兩條線）”四層都有在跑的工作面，形態上已接近深度適配廠商。考慮到崑崙芯並不在社群公開的成員單位名單裡，其投入強度值得作為外部生態擴張的樣本持續跟蹤。

3.4 曦望芯科與達摩院玄鐵：外部推理 GPU 與 PPU 後端同視窗加碼（09-10）

來源：vllm-plugin-FL #391、#472、FlagTree #1144

  • 曦望芯科（Sunrise）：vllm-plugin-FL 把其注意力後端移植到 vLLM 0.24.0（物件為其 TANGRT 1.2.0 工具鏈），完成從”僅 runner 環境”到”元件級後端”的跨越；交付側 sunrise3.4 納入 0.7.0 切換；官方晶片廠商表已列 Sunrise。
  • 達摩院玄鐵（T-Head）：vllm-plugin-FL #472 恢復其後端靜態圖支援；交付側 ppu3.6 納入 0.7.0 切換，FlagTree #1144 同步重新整理 PPU 的 qwen3.6 benchmark 效能基線。

解讀：兩家都屬”非成員單位的推理側投入”。曦望是專注推理 GPU 的國產廠商（其產品線 S1/S2/S3 面向推理場景），選擇在 vLLM 0.24.0 這條跟隨上游的外掛線上落地，說明網際網路/雲側推理部署路徑對國產晶片廠商的吸引力仍在上升；達摩院玄鐵的靜態圖修復與 PPU 交付線併入 0.7.0，則顯示其作為 RISC-V 語境下最有代表性的算力後端，在 FlagOS 的交付矩陣中保持著常規位置的更新節奏。

3.5 智源（牽頭方）：交付流水線版本統一與打包政策兩項治理動作（09-10）

來源：FlagTree #1151、build-infra #812、release-info

  • 牽頭方本視窗的動作集中在治理而非功能：把 FlagTree 的 29 條廠商交付工作流版本號統一（由社群側維護者提交）、把打包通道邊界寫成中英雙語文件政策。
  • 釋出清單倉庫 release-info 視窗內無內容更新（仍只有初始 README），說明 2.2 的正式釋出清單尚未定稿。

解讀：三條資訊合起來看，2.2 GA（時間表為 09-28）前的準備重心已從”功能與適配”轉到”交付口徑與安裝渠道”：版本號要讓十幾家廠商的交付線對齊、依賴來源要有政策可依、釋出清單要能一次說清全部製品。這類工作對外不可見，但直接決定 GA 當天能否給出可復現的交付面。

四、總結

本視窗（09-10 10:18 ~ 09-11 10:18）GitHub 側 61 條視窗內提交、13 個倉庫有推送，工程側維持高位活躍；新聞側元件級檢索為第九個連續平靜視窗，外部報道為零，全部資訊來自程式碼倉庫。四條主線：

  1. FlagTree 0.7.0 進入交付收斂期（本視窗最重要變化）：主線版本號由 0.6.0 提升到 0.7.0，並把 29 條廠商交付工作流的版本入參一次性切到 0.7.0，覆蓋 NVIDIA 六條 triton 線（含 TileIR 與特殊形態）、AMD、昇騰、燧原、天數智芯、沐曦、摩爾執行緒、清微、曦望、崑崙芯 XPU、HCU、AIPU、Thrive、PPU 等；rc0/rc1 三級分支（triton 3.3/3.5/3.6）此前已就位，正式 release tag 尚未釋出。這意味著 2.2 RC 期的版本收斂已到最後一步。
  2. 昇騰 910C 完成”base → app”兩級落地，sglang 升為一等應用線：910C 的 runtime 映象構建推送後，vllm 應用線在 CANN 8.5.0 與 9.0.0 兩條 910C 線路上開放（覆蓋 vLLM 0.20.2 與 0.24.0 四個應用條目），並補齊九項 verify/模板/依賴穩定化修復；同時為至少 10 條晶片線的 sglang0.5.18 生成啟動文件與 changelog，推理框架矩陣由”vllm 全量、sglang 零散”變為兩線並重。
  3. 外部與非成員廠商繼續加碼：曦望 Sunrise 完成元件級後端落地（從 runner 環境推進到 vLLM 0.24.0 的 vendor 後端），崑崙芯 XPU 與海光 DCU 雙後端合入 FlagTensor，清微新增 tsingmicro3.6 雙向 CI/CD 並對齊 LLVM 22 與 Triton 3.6——新晶片接入的標準路徑（環境先行 → 外掛後端 → 交付線併入）已被驗證可複製。
  4. RC 期紀律在工程細節中反覆出現：TLE NVIDIA 的佈局最佳化當日合入當日回退、FlagGems 移除沐曦殘留 CI 條目、安裝子包完整性修復、打包通道政策成文——凍結期的動作是”修正確性與口徑，不進新特性”，同日回退與安裝面修復是這一紀律最直接的證據。

預判：後續觀察面四點——其一，910C 的首個 app image tag 何時進入 registry 記錄並出現在 status matrix 的”已驗證”列（這是 910C 交付可用的最終標誌）；其二，FlagTree 0.7.0 的正式 release tag 與 build-infra 的 flagtree pin 何時跟進（當前 NVIDIA 線仍 pin 在 0.6.1，存在一個版本的錯位）；其三，2.2 GA（09-28）前的 rc1.postN 遞增節奏與 community/release-info 清單動作；其四，曦望的接入路徑是否會從 vllm 擴到 sglang 線，以及崑崙芯是否會被納入公開成員名單。

侷限性說明：本視窗全部條目來自 GitHub 提交、工作流檔案與補丁內容；新聞側為第九個連續平靜視窗，無可獨立交叉驗證的第三方報道，故”版本收斂”“交付可用化”類判斷均以提交正文與檔案改動為準，未採信第三方轉述。Google News 中英文 13 組查詢零命中，HN 命中為子串誤匹配，均如實記錄於附錄。

附錄：完整信源清單

信源 核查結果
GitHub org repos API（flagos-ai，53 倉，按 pushed 排序） 13 倉視窗內推送：build-infra（09-11 10:06）、FlagTree（09-11 10:05）、FlagBLAS（09-11 10:14，預設分支無視窗內提交，判定為分支動作）、vllm-plugin-FL、FlagGems、FlagGems-vllm、FlagDNN、Torch-FL、flir、FlagFFT、FlagCX、FlagTensor、Megatron-LM-FL；無新倉庫（最新建立倉庫為 08-15）
GitHub commit search（org 全量，committer-date > 2026-09-10T02:18Z，單頁 60 條全量） 逐條核驗 committer 時間與倉庫歸屬：build-infra 24 / FlagGems 10 / FlagTree 8 / FlagTensor 5 / vllm-plugin-FL 3 / FlagDNN 3 / FlagGems-vllm 2 / Torch-FL 2 / flir 1 / FlagFFT 1 / FlagCX 1
GitHub per-repo commits 複核（Megatron-LM-FL、FlagBLAS、FlagGems-Experimental） Megatron-LM-FL #148（09-10 10:47）落入視窗，search 索引滯後未收錄，已補入；FlagBLAS 預設分支最新提交為 09-09（視窗外），視窗內推送來自分支；FlagGems-Experimental 最新提交 09-10 09:11（視窗外）
GitHub 分支 API（FlagTree） 0.7.0-rc0-triton3.3/3.5/3.6 頭部時間 08-11 / 08-27 / 08-31；0.7.0-rc1-triton3.3/3.5/3.6 為 09-01 / 09-04 / 09-04（rc1-triton3.6 頭部即清微後端整合 #1071）
GitHub commit 詳情與補丁 #1151 共 29 個交付工作流檔案，預設版本 ‘0.6.0’ → ‘0.7.0’（提交者 zhengyang@baai.ac.cn）；#816（273 行，4 個 910C vllm changelog + status matrix）；#831（2896 行，sglang0.5.18 啟動文件矩陣）；#1118（354 行，清微 build-and-test + delivery）；FlagTensor 後端合併（4225 行 / 4393 行）；vllm-plugin-FL #391（sunrise，物件為 TANGRT 1.2.0）；FlagGems-vllm #736（海光 op 325 行）；Torch-FL #270（658 行，含 DCU 路由基準文件）；FlagCX #576（MUSA PAL）
GitHub tags / releases API 本視窗無新 release。最新錨點：FlagGems v5.4.0-rc1.post1、FlagTree 0.6.0+triton3.x（Releases）/ 交付線已切 0.7.0、FlagCX v0.14.0-rc1.post1、FlagGems-vllm v0.2.0-rc1.post1、vllm-plugin-FL v0.3.0-rc1.post1、FlagBLAS v0.3.0-rc1.post1、FlagTensor v0.3.0-rc1.post1、FlagDNN v0.3.0-rc1.post1、FlagFFT v0.2.0-rc1.post1、Torch-FL v0.2.0-rc1.post1、FlagOS-Robo v0.1.0
raw.githubusercontent（FlagTree / vllm-plugin-FL / build-infra / flir 的 README 與 configs.yaml） FlagTree 廠商表含 NVIDIA（含 TileIR）、AMD、燧原、天數智芯、海光、摩爾執行緒、達摩院、輝羲智慧、沐曦、曦望、崑崙芯、達摩院玄鐵（T-Head）、進迭時空、清微智慧；vllm-plugin-FL 廠商表含 Sunrise（Supported）；build-infra configs.yaml 的 NVIDIA 線仍 pin flagtree==0.6.1，含 sunrise / tsingmicro / kunlun / hygon / mthreads / iluvatar / cambricon / metax / enflame 鍵；flir 為 FlagTree IR 中間層（fork 自 triton-shared）
Google News RSS（中英文 13 組查詢詞，走代理） 元件級查詢全部零命中（第九個連續平靜視窗）；成員單位詞命中為京東雲十萬卡叢集
轉載、股價/解禁類與博彩 SEO 稿件，按既有口徑不納入技術條目    
  HN Algolia（FlagOS / FlagGems / FlagTree / FlagScale / BAAI） 全部為 flags/flagship/flocked 子串誤匹配的無關條目，整批剔除
  FlagOS 官方 CSDN 號（flagos.csdn.net） 視窗內無新文章，最新仍為 08-28 的 GLM-5.3-Flash Day0 適配 9 款晶片；09-07 KubeCon 同場論壇頁與運算元調優主題頁無釋出時點更新
  智源社群（hub.baai.ac.cn） 視窗內命中為社群常規內容（具身智慧、AI 治理等），與 FlagOS 技術棧無直接關聯
  Tavily / web 檢索 曦望芯科背景核驗（官網、量子位、鈦媒體三源）；FlagOS 版本節奏歷史錨點核驗（眾智 FlagOS 1.6 / 1.5 官方通稿）