調研視窗：2026-09-07 10:18 ~ 2026-09-08 10:18 北京時間 信源：GitHub（org: flagos-ai 52 倉 pushed_at + commit search 91 條全量按 committer-date 核驗 + 預設分支 per-repo 複核 + tags/releases/PR 詳情）、Google News RSS（中英 14 組查詢，走代理）、HN Algolia、Tavily/web 檢索、FlagOS CSDN 官方號（詳見附錄）

索引

  • 一、開源專案進展（GitHub 動態）
    • 1.1 FlagOS 2.2 RC1 收口：community 釋出 RC1 manifest，25 個清單條目隨首輪 rc1.post1 驗證 tag 集中打出（09-07）
    • 1.2 FlagScale 三連：KERV 具身投機解碼訓練/推理整合、Megatron-LM v0.18.2 升級、CICD 聚焦訓練（09-07）
    • 1.3 FlagGems-Experimental：KernelGen 跨後端運算元批次同步入庫 + sync-to-kernelgen CI 落地（09-07）
    • 1.4 FlagGems 主倉：海光/天數修復、QC fp8、外部貢獻者與回滾（09-07）
    • 1.5 FlagGems-vllm：達摩院玄鐵 PPU 與海光專用 fused-MoE 後端（09-08）
    • 1.6 FlagBLAS：Ascend L2 例程連續合入（CHER/CHER2/SSYR/CSYR）（09-07/09-08）
    • 1.7 FlagTree/FlagPrism：TLE 多欄位 pipe、CI/CD 修復與除錯/剖析元件合入（09-07）
    • 1.8 vllm-plugin-FL 與 FlagScale-Agent：FlagCX 指標聯結器、Agent 可靠性重構（09-07/09-08）
  • 二、新聞報道與生態
    • 2.1 FlagOS 社群”開放 AI 計算”論壇在上海 KubeCon + PyTorch Conference China 同場舉辦（09-07）
    • 2.2 元件級新聞第六個連續平靜視窗（09-07~09-08）
  • 三、成員單位深挖
    • 3.1 清微（tsingmicro）：vllm-plugin-FL 新增 txda 後端線，隨 vLLM 0.24.0 主線合入（09-07）
    • 3.2 天數智芯（iluvatar）：0.20.2 確定性技術路線定案——flag_gems GEMM 族整族黑名單（09-07）
    • 3.3 沐曦（metax）與寒武紀（cambricon）：sglang 0.5.18 交付線擴圍（09-07/09-08）
    • 3.4 外部生態：昇騰驗證記錄與 from-scratch 修復、崑崙芯 KernelGen 運算元、sunrise 新後端接線（09-07/09-08）
  • 四、總結
  • 附錄：完整信源清單

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

視窗總覽：org 內 52 個倉庫中 30 個在視窗內有推送，commit search 命中 91 條視窗內提交，預設分支實質合入集中在 community、FlagScale、FlagGems、FlagGems-vllm、FlagGems-Experimental、FlagBLAS、FlagTree、FlagPrism、FlagCX、Megatron-LM-FL、TransformerEngine-FL、vllm-plugin-FL、build-infra、FlagScale-Agent 等 14 倉，為近期活躍度最高的視窗之一。本視窗頭號事件是 FlagOS 2.2 RC1 正式切線：09-07 11:11 community 合入 release/2.2/release-2.2-rc1.yaml（+252 行、25 個清單條目），隨後 11:22~11:33 間至少 12 個倉庫集中推送首輪 rc1.post1 驗證 tag——昨日報告”下一發布訊號仍看 community 清單倉庫動作”的預判在視窗內兌現，且動作比預期更大：不是 version bump，而是 RC0→RC1 的釋出管線切換。元件程式碼側延續 2.2 測試穩定期特徵：FlagGems 系運算元矩陣（fused-MoE 新後端、Ascend L2、KernelGen 批次同步）、FlagScale 訓練棧（Megatron v0.18.2、KERV）、編譯器與外掛層的驗證性修復。

1.1 FlagOS 2.2 RC1 收口：community 釋出 RC1 manifest，25 個清單條目隨首輪 rc1.post1 驗證 tag 集中打出（09-07）

來源：community PR #107（703ea2184c，wbavon，09-07 11:11 合入）、release-2.2-rc1.yaml、FlagSparse v0.3.0-rc1.post1 release（09-07 11:27 釋出）、2.2 時間表 schedule_CN.md

  • manifest 合入：09-07 11:11，community 倉合入 #107，新增 release/2.2/release-2.2-rc1.yaml（252 行）並把 .github/workflows/release-branch-tag.yml 的預設清單從 2.2/release-2.2-rc0.yaml 切到 release-2.2-rc1.yaml。manifest 採用 vcstool 格式，覆蓋 L0 基礎設施（flagtree×3 條 Triton 線、flagcx）→ L1 計算庫（flaggems/flagfft/flagsparse/flagdnn/flagblas/flagtensor/flagaudio/flagattention/flaggems-vllm/flaggems-sglang）→ L2 框架適配（torch-fl、vllm-plugin-fl×2、sglang-plugin-fl、transformerengine-fl、megatron-lm-fl、flagos-compressor）→ L3 應用工具（flagscale、kernelgen、kernelgenbench、flagrelease），共 25 個條目、22 個倉庫。
  • 關鍵版本錨點：flagcx v0.14.0-rc1.post1、flaggems v5.4.0-rc1.post1、flagscale v2.1.0-rc1.post1、kernelgen v2.2.0-rc1.post1、flagtree 三線統一 0.7.0rc1.post1+triton{3.6|3.5|3.3}、vllm-plugin-fl 拆兩條線（main 跟 vLLM 0.24.0 → v0.3.0-rc1.post1；release/0.2 跟 vLLM 0.20.2 → v0.2.2-rc1.post1）。註釋同步記錄了 rc0→rc1 的工程演進：FlagGems master 已合入 setuptools_scm only-version（上游 #5885），post tag 落在 master 不再觸發構建失敗，rc1 無需再做 rc0 那次的 cherry-pick/挪 tag 補救。
  • rc1.post1 tag 波：11:11 manifest 合入後，11 分鐘內至少 12 個倉庫集中推送（FlagCX 11:22、FlagFFT 11:23、FlagSparse 11:27 釋出 release、FlagTensor/FlagAttention/FlagGems-sglang/FlagAudio 11:28、Torch-FL 11:29、FlagOS-Compressor 11:31、KernelGen 11:32、KernelGenBench/FlagRelease 11:33），與 manifest 各條目一一對應；這些倉庫預設分支在視窗內均無實質程式碼合入（tags API 複核 rc1.post1 均存在），即純 tag 波。manifest 頭註釋寫明版本演進規則：每輪驗證透過打遞增 tag（rc1.post1 → rc1.post2 → …）並回寫 version 欄位，.post1 即”首輪驗證透過”標記。

解讀：這是 FlagOS 2.2 釋出週期的第三個里程碑訊號——08-31 特性凍結（FEP 門關閉）、09-01 進入測試穩定期（只收 bug 修復）、09-07 以 RC1 manifest + 首輪驗證 tag 波宣告 rc0 整合段的驗證結果被固化為 rc1 基線。時間表顯示 09-01~09-24 為多晶片矩陣測試視窗、09-28 GA，RC1 切線比 rc0 晚 7 天，符合”特性凍結→約一週整合驗證→rc1 固化”的節奏預期。值得注意的兩點：一是 manifest 的條目粒度與 rc0 相比更細（FlagTree 三條 Triton 線、vllm-plugin 兩條 vLLM 線分列），說明 2.2 的交付矩陣確實覆蓋多編譯器/多框架版本組合；二是 FlagGems 上游對 post-tag 構建問題的根治（only-version），把 rc 週期的構建噪聲從流程裡消掉了——RC1 之後的 post2/post3 迭代會更快。對後續觀察的意義：下一訊號是各元件 rc1.postN 的遞增（對應多晶片矩陣驗證的逐輪透過）與 09-24 前後的 RC-final/GA 切線；RC1 期間元件預設分支仍可合入 bug 修復，社群挑戰賽等外部貢獻流不受影響。

1.2 FlagScale 三連：KERV 具身投機解碼訓練/推理整合、Megatron-LM v0.18.2 升級、CICD 聚焦訓練（09-07）

來源：FlagScale PR #1278（zhengzihaoPKU，09-07 14:24 合入）、#1284（b5741d04，22:00）、#1283（b3708f0f，10:34）、Megatron-LM-FL #109（e15cb692，21:57）

  • KERV 整合（#1278，09-07 14:24）：FlagScale 合入 KERV 具身投機解碼（embodied speculative decoding）的訓練與推理整合——新增 OpenVLA verifier 的 LoRA/全參訓練配置、KERV draft 資料生成與 drafter 訓練、LIBERO 推理配置；程序內適配 KERV/OpenVLA 公開 Python 入口（FlagScale 統一編排、不產生巢狀 launcher）；自帶 KERV 控制執行時（批候選生成、驗證樹構建、寬鬆接受、動態閾值調整、Kalman 補全）；BF16 推理 profile 直接選用公開 runtime_opt 包中的 14 個 KERV 運算元；附 33 個與模型無關的單測（CI 不下載 checkpoint、不啟 MuJoCo/LIBERO）。
  • Megatron v0.18.2 升級（#1284 + Megatron-LM-FL #109，09-07 晚間）：FlagScale 22:00 升級上游依賴至 Megatron-LM v0.18.2；配套的 Megatron-LM-FL 外掛倉 21:57 同步升到同一基線（#109）。兩個訓練棧倉庫在同晚對齊版本，屬協同升級。Megatron-LM-FL 另兩條 CICD 提交：#140（18:29）為 TE-FL prepare checkout 加重試、#128（15:01）做 TE-FL 增量構建與執行時整合。
  • CICD 聚焦訓練（#1283，10:34）：FlagScale 移除 inference 與 serve 兩條 CI 流水線，”focus on training”——訓練框架的交付邊界收窄，推理側由 vllm-plugin-FL/sglang-plugin-FL 承擔的分工進一步顯式化。

解讀：三條提交分別對應 FlagScale 的三個方向訊號。KERV 是最值得注意的一條：FlagOS 訓練棧開始覆蓋具身/機器人策略的投機解碼——KERV 是面向機器人 VLA 部署的投機解碼框架（OpenVLA 作 verifier、draft 模型先行、驗證樹+Kalman 補全控制接受率），FlagScale 把它做成”可訓練（verifier/drafter）+ 可推理（LIBERO）+ 可評測”的一等公民。這與 FlagOS-Robo 的具身智慧工具鏈定位呼應，也與 2.2 測試期內”只收 bug 修復、不進新特性”的凍結規則形成對照——KERV PR 於 08-30 建立、09-07 合入，正好踩在特性凍結（08-31）邊緣並已提前實現，屬凍結前進入的存量特性收尾而非凍結後新開。Megatron v0.18.2 雙倉同晚對齊則說明 2.2 RC1 基線裡訓練棧的依賴版本已被釘死；CICD 聚焦訓練是把”FlagScale=訓練、vllm/sglang 外掛=推理”的分工寫進工程流水線。

1.3 FlagGems-Experimental：KernelGen 跨後端運算元批次同步入庫 + sync-to-kernelgen CI 落地（09-07）

來源：FlagGems-Experimental commits（14:31 CICD 3 條 + 16:27~16:58 批次 60+ 條）、CICD sync-to-kernelgen（4973e875）

  • CI 先行（14:31）：103yiran 合入 CICD(.github): add sync to kernelgen、docs: add ci doc 與 .github 調整——FlagGems-Experimental 與 KernelGen 倉庫之間建立了自動化同步工作流。
  • 16:58 批次入庫：同一秒戳（16:58:04~05）落庫 60+ 條提交，全部為 [KernelGen][廠商] 字首的運算元提交，跨後端覆蓋：Kunlunxin（digamma、arctan minimax 最佳化、bernoulli）、Metax（linalg_cholesky/log_normal_/erfinv/gcd_/lgamma 等專用數學運算元 + adaptive_max_pool3d_backward + special_shifted_chebyshev_polynomial_w + 註冊名修復）、Iluvatar（addmm_、nonzero_numpy 混合兩遍 kernel 最佳化）、Hygon（amp_foreach_non_finite_check_and_unscale）、thead（lcm/lcm_ 廠商專用化）、MThreads（linalg_cholesky）、Nvidia（special_i0/softmax/xlog1py/shifted_chebyshev_t/spherical_bessel_j0/split_with_sizes/grid_sampler_3d 等新運算元），另有上游 FlagGems 同步過來的歷史提交（Apache 2.0 頭補齊、CI 修復、FlagTune topk 配置、ENFLAME 更新等，PR 編號 #3540/#4646/#4829/#4873 等指向 FlagGems 上游）。貢獻者含 yzw1128（FlagGems-sglang 賽事戰隊的同一賬號）、chx7514、ZhiwenDeng、KK、Dingxingdi、bwbwzzz 等。

解讀：FlagGems-Experimental 是 KernelGen 運算元流的中轉/實驗倉，本視窗”CI 同步工作流 + 一次性大批次合入”的組合說明：KernelGen 的跨廠商運算元產出正在以”批次同步”方式從實驗倉流向 KernelGen 主倉（sync-to-kernelgen 即管道本身）。這批運算元的語義分佈很能說明 KernelGen 當前的主攻面——special 函式族（i0/softmax/xlog1py/貝塞爾/切比雪夫多項式等）在 Nvidia/Metax 後端密集出現，說明數學函式運算元的自動生成覆蓋面在擴；而 Kunlunxin/Iluvatar/Hygon/thead/MThreads 的條目多為”廠商專用化”（把通用 kernel 針對具體工具鏈/指令重寫），對應多晶片適配的最後一公里。值得注意 thead（達摩院玄鐵）條目與 lcm 這類整數運算元——玄鐵側的 KernelGen 支援仍在持續加碼。yzw1128 同時活躍於賽事 PR 與 KernelGen 運算元，說明外部貢獻者已同時在賽事通道與 KernelGen 通道產出。

1.4 FlagGems 主倉：海光/天數修復、QC fp8、外部貢獻者與回滾（09-07）

來源：FlagGems commits 11:34~20:39、#6040 hygon BLOCK_M fix、#6043 revert FlagTune、#5341 SiliconFlow cauchy

  • 海光修復（15:23 #6040）：修復 Hygon 後端 flash attention 在跑 ViT encoder 推理時 KeyError: 'BLOCK_M'——量化配置取塊大小的路徑在特定形狀下取空。
  • 天數最佳化（17:27 #5341）：[SiliconFlow] Optimize cauchy on Iluvatar——矽基流動（SiliconFlow）署名參與，在 Iluvatar 上最佳化 cauchy 運算元（SSM 系卷積），並順帶修復跨後端測試。
  • QC fp8（14:04，與 Experimental 同 commit c9bd738d）：[QC] Optimize GEMM(fp8)——fp8 GEMM 最佳化同時落在主倉與實驗倉。
  • 工程面：18:07~18:09 三條 CI/測試提交（approved operator tests 別名、and_scalar pytest 標記）；17:37 AddMM 公共 API 測試（上游 beta-zero 修復後）；18:09 修復 bucketize kernel 越界讀 input 尾（#5231，Truong Vu）；20:39 更新 Hygon linalg_solve_triangular（#5943）。
  • 回滾（15:54 #6043）：Revert 前日合入的 [FlagTune] Add multi-platform Mul cost model support (#5762)——FlagTune 多平臺乘法成本模型被整體回退。

解讀：主倉視窗內 11 條提交呈現典型的”測試穩定期”形態：無新架構級特性，全部是後端正確性修復（Hygon ViT 場景 BLOCK_M、bucketize 越界）、單運算元效能最佳化（QC fp8、Iluvatar cauchy、Hygon linalg）與 CI/測試基建。矽基流動署名最佳化 Iluvatar cauchy 值得標記——這是繼中科院 AlphaSparse 團隊（FlagSparse）之後又一家外部公司直接向 FlagGems 貢獻廠商運算元，生態共建的”外部貢獻”名單在變長。FlagTune 成本模型被 revert 說明調優器側的改動在 RC 期會被從嚴把關：不合驗收標準寧可回退，與 2.2”只收 bug 修復”的凍結紀律一致。

1.5 FlagGems-vllm：達摩院玄鐵 PPU 與海光專用 fused-MoE 後端（09-08）

來源：FlagGems-vllm PR #696（09-08 09:54 合入）、#746（09:56）、#747（10:05）

  • #696 達摩院玄鐵 PPU 後端：新增 _thead 後端，為 T-Head PPU（ZW810E，compute_89 / AIU MMA 指令）實現純 Triton fused-MoE（fused_experts_impl），建模自既有 _metax/_mthreads 廠商後端：thead 版 moe_align_block_size、轉置快取權重（複用自 FlagGems 同步的 permute_copy）、per-tile moe_sum 歸約，生產路徑不依賴 deep_gemm；大 M GEMM 風格 kernel 按 token 數分檔（MOE_GEMM_TUNING_MIN_TOKENS，gemm1/gemm2 分段）。
  • #746 海光專用 fused-MoE：為 Hygon DCU（gfx936）實現專用 fused_experts_impl，在真實 Qwen3.6-35B-A3B 形狀上對 vLLM-HCU Triton 基線調優：完整 fused_moe 流水（moe_align→GEMM1→SiLU→GEMM2→moe_sum），Hygon 專用 align 路徑（3-kernel 小批變體，避開 HCU 後端編不了的 TLE 協作 kernel）；按 M 分檔（M≤16 非融合單遍、TP4 BK=64、mid-M BK128、TP4 大 M num_warps=16、TP1 M≥8192 非融合等）。
  • #747 KMCompiler：persistent_topk 的測試/benchmark 改為在無 vLLM native op 環境下可執行（KMCompiler 生成路徑脫離 vLLM 依賴自測）。

解讀：兩條 fused-MoE 廠商後端同日合入（間隔 2 分鐘），都是”為具體晶片指令集手寫排程”的深度適配：玄鐵 PPU-ZW810E 走 AIU MMA（compute_89 級），海光 DCU 走 gfx936 專用分檔且刻意繞開 HCU 編不了的 TLE kernel——後一條與 KernelGen/FlagGems 系對”TLE 協作 kernel 在部分國產工具鏈不可編譯”的已知邊界一致。海光 fused-MoE 以真實 Qwen3.6-35B-A3B 形狀調優並直接對標 vLLM-HCU Triton 基線，說明該後端面向真實 35B 級 MoE 推理負載。fused-MoE 是當前推理吞吐的關鍵運算元，vllm 外掛層對它的逐晶片專用化是 2.2 測試期”運算元級效能打磨”的最直觀樣本。

1.6 FlagBLAS：Ascend L2 例程連續合入（CHER/CHER2/SSYR/CSYR）（09-07/09-08）

來源：FlagBLAS PR #96（16:35）、#93（17:16）、#97（18:05）、#98（19:31）、#99（09-08 10:16）

  • 視窗內 FlagBLAS 預設分支 9 條提交，主線是 Ascend 後端 L2 例程擴充套件：Ybanana252 依次提交 CHER（複數 Hermitian rank-1 更新，#97 18:05）、CHER2（rank-2，#98 19:31）、SSYR/CSYR（實/復對稱 rank-1 更新，#99 於 09-08 10:16 合入）以及 L2 三角（#93 17:16 合入的 l2-triangular 分支），每條都帶 Ascend 輸入構造的測試文件（test(her2): document Ascend input construction）。
  • CI 修復兩條（#96，16:35 合入，bin913）：nvidia 線 flagtree 對齊 0.6.1（與 FlagGems 同版）並改用 uv pip 安裝以保證 triton 可用。

解讀：FlagBLAS 的 Ascend L2 覆蓋在快速閉合——CHER/CHER2/SSYR/CSYR 都是 rank-1/rank-2 更新類例程，與 09-05 報告錄得的 DCU/L2 主線形成”逐例程補齊”的節奏（此前 ascend 的 L2 三角族也已合入）。連續三個傍晚 + 次日清晨各合一批，說明 Ascend 的 L2 驗收是批次流水式的。CI 側把 nvidia flagtree 釘到 0.6.1（與 FlagGems 一致）則是多倉依賴對齊的常規動作。按 manifest，flagblas 屬 L1 計算庫，RC1 後仍可合 bug 修復與新例程——這條 Ascend 例程補強線大機率會持續到 GA。

1.7 FlagTree/FlagPrism：TLE 多欄位 pipe、CI/CD 修復與除錯/剖析元件合入（09-07）

來源：FlagTree #1110（12:29）、#1104（15:31）、#1115（15:41）、FlagPrism PR #8（10:47 合入）、FlagPrism README

  • FlagTree（預設分支自 09-04 後首次實質合入）：12:29 #1110 [BUILD][CD] 修復 DEPENDS IncGen 與 nvidia3.7 交付工作流；15:31 #1104 [TLE][MTHREADS] 支援多欄位 pipe 與多角色 ws（TLE 在摩爾執行緒後端的通訊/流水抽象擴充套件）；15:41 #1115 [CI][Nvidia] 最佳化 nvidia3.6 工作流的併發分組。09-08 09:58 的推送為 PR 分支動作。
  • FlagPrism（新倉庫推進）：10:47 合入 #8 “Add profiler and debugger support”。FlagPrism 是集中維護 FlagTree 可選除錯與剖析元件的倉庫：flagtree.debugger（偵錯程式編譯器外掛鏈入 libtriton，執行時傳輸/解碼在獨立 _native 擴充套件）與 flagtree.profiler（Python 包 + 原生執行時 + CLI）；flagtree-debugger/flagtree-profiler 不再單獨發 wheel，FlagTree 以 third_party/FlagPrism submodule 方式消費，pip wheel . 一次構建出含 Debugger/Profiler 的單一 FlagTree wheel。

解讀：FlagTree 在 rc0 驗證期（09-04 清微後端合入後）預設分支靜默了 3 天，本視窗的合入集中在構建/交付工作流修復與 TLE 後端能力——nvidia3.7 交付流、IncGen 依賴、摩爾執行緒 TLE 多欄位 pipe 都是”讓多晶片 CI/CD 矩陣跑穩”的工程。FlagPrism 的合入是元件架構事件：FlagTree 的偵錯程式/剖析器從”獨立包”收斂為”主倉 submodule + 單 wheel”，RC1 manifest 裡 flagtree 三線版本一致（0.7.0rc1.post1+tritonX），Prism 的 #8 若在凍結前進入即隨 2.2 釋出，除錯/剖析能力將內建在 FlagTree 單一 wheel 中——對運算元開發者是實打實的體驗改進（debugger 的編譯外掛在 libtriton 內、剖析器 CLI 一站式可用）。

1.8 vllm-plugin-FL 與 FlagScale-Agent：FlagCX 指標聯結器、Agent 可靠性重構（09-07/09-08）

來源：vllm-plugin-FL #418（489d22d5，14:28）、FlagScale-Agent commit 9e308807（09-08 09:12）

  • vllm-plugin-FL #418（09-07 14:28）：feat(flagcx connector): Prometheus KV-transfer metrics + port #315 from release/0.2——vLLM 外掛與 FlagCX 的聯結器新增 Prometheus 可觀測指標（KV 傳輸），並把 release/0.2 分支的 #315 修復移植回主線。
  • FlagScale-Agent（09-08 09:12，caozhou）：feat: agent reliability overhaul——為 FlagScale-Agent 加入執行時思考預算上限（runtime thinking cap）、感知推理的重試（reasoning-aware retries）、時間預算感知（time-budget awareness）與健康監控（health monitoring）。FlagScale-Agent 是面向大模型訓練編排的智慧體元件，本次是整體可靠性重構。

解讀：兩條都是”讓 FlagOS 上層工具更適合無人值守長跑”的工程：FlagCX 聯結器的 Prometheus 指標把多卡 KV 傳輸狀態暴露給運維（vLLM 0.20.2 線 #315 修復同步回主線，保持雙線一致）；FlagScale-Agent 的”思考預算/重試/時間預算/健康監控”四件套是典型的 agent 工程化加固——防止長時訓練編排中 agent 迴圈失控或靜默掛死。考慮到 2.2 測試期的多晶片矩陣跑測對”可觀測 + 可自愈”的編排層需求上升，這類加固正當其時。

二、新聞報道與生態

2.1 FlagOS 社群”開放 AI 計算”論壇在上海 KubeCon + PyTorch Conference China 同場舉辦（09-07）

來源：FlagOS CSDN 官方號公告（2026-09-07 09:57 釋出）

  • 09-07 下午，由眾智 FlagOS 社群主辦的《開放 AI 計算：面向多元異構硬體打造開源軟體新生態》論壇在上海 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大會同場舉辦；嘉賓來自北京智源人工智慧研究院、上海人工智慧實驗室、PyTorch 基金會、SGLang 社群等，議題圍繞開放 AI 系統軟體棧的技術路線與協作模式。CSDN 官方號頁面提供直播/回放。
  • 該公告釋出於 09-07 09:57（緊鄰上一視窗終點），論壇本身於當日下午（本視窗內）舉行；昨日報告曾記 CSDN 官方號無更新，此條為補錄的視窗內生態事件。

解讀：把論壇辦進 PyTorch Conference China / KubeCon China 的上海會場，是 FlagOS 在”開源社群橫向協作”上的連續性動作——與 PyTorch 基金會、SGLang 社群同臺，議題直指”多晶片統一軟體棧”這一 FlagOS 主張的核心。此類活動本身不產生元件程式碼動態，但說明 RC1 切線同期社群層在借國際性大會放大開放計算敘事；後續可留意該論壇是否有公開的路線圖/白皮書類產出。

2.2 元件級新聞第六個連續平靜視窗（09-07~09-08）

來源：Google News RSS（中英 14 組，走代理）、HN Algolia、Tavily/web 檢索（詳見附錄）

  • gnews 中英組合（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/KernelGen/FlagOS 2.2 when:3d~30d 等）視窗內零命中；唯一 FlagGems 命中為 09-01 智源社群 Day0 舊文轉載（已報道）。智源研究院 when:7d 命中 58 條，全為智源社群部落格轉載（姚期智開學典禮講話、AI 程式設計雜談等）與博彩 SEO 模板噪音，無 FlagOS 內容，整批剔除。天數智芯/沐曦查詢命中以中報、股價、港股異動等商業新聞為主（與 FlagOS 軟體生態無直接關聯，不收錄）。
  • HN Algolia（FlagOS/FlagGems/flagos-ai/BAAI）無相關命中；Tavily 檢索到的新內容僅 2.1 論壇公告。
  • 近 3 天趨勢（GitHub org pushed 佐證，工程側極不平靜）：09-07 11:11 FlagOS 2.2 RC1 manifest 切線 + 首輪 rc1.post1 tag 波（本日 1.1）；09-07 FlagScale KERV 具身投機解碼整合與 Megatron v0.18.2 雙倉對齊（1.2）；09-07/09-08 build-infra 連續 13 條交付記錄（天數智芯 0.20.2 確定性定案、沐曦/寒武紀/昇騰 sglang 0.5.18 線，見三）；09-07 晚間 FlagBLAS Ascend L2 例程批次合入（1.6）；09-08 上午 FlagGems-vllm 玄鐵/海光 fused-MoE 後端合入（1.5）。

三、成員單位深挖

3.1 清微（tsingmicro）：vllm-plugin-FL 新增 txda 後端線，隨 vLLM 0.24.0 主線合入（09-07）

來源：vllm-plugin-FL PR #447（tsingmicro-public-e，09-07 16:58 合入，base: main）

  • PR #447 由清微官方賬號 tsingmicro-public-e 提交併合入（PR Category: Vendor）：為 vllm-plugin-FL 增加 txda 廠商程式碼、支援 vLLM==0.24.0（main 線），並修復 txda 相關 bug。合併時間 09-07 16:58，與 RC1 manifest 中 vllm-plugin-fl main 線釘 vLLM 0.24.0 的設定一致。
  • build-infra runner 側清微線已具備（tsingmicro-tsm260610: [self-hosted, tsingmicro]，本視窗前已登記）。

解讀：清微此前已進入 FlagTree 後端矩陣（09-05 報告：300 檔案規模接入、TLE-DSA 資料流架構），本次是推理外掛側的第一塊版圖——vllm-plugin-FL 的廠商後端名單新增 txda（vLLM 0.24.0 線）。清微作為 FlagOS 成員單位中較新的晶片廠商，其適配路徑呈現清晰的”編譯器（FlagTree）先行、推理框架（vLLM 外掛）跟上”順序；txda 後端的合入方式（廠商自己提 PR、自己維護）也是成員單位深度參與的正面樣本。

3.2 天數智芯（iluvatar）：0.20.2 確定性技術路線定案——flag_gems GEMM 族整族黑名單（09-07）

來源：build-infra #776/#777（19:23/19:24，映象 tag 登記）、#779（20:21，docs 定案）、vllm-plugin-FL PR #450（在途，09-07 16:59 更新）

  • 映象登記（#776/#777，09-07 19:23/19:24）：iluvatar-corex4.4.0 與 corex4.5.0 同日登記 vllm 0.20.2 app 映象 tag 2.1.2-0.2.1_g16e8655.d20260907（plugin 原始碼指紋 g16e8655，兩棧同 tag）——相對前日 g71b9482.d20260906 指紋更新，對應確定性方案迭代後的新交付。
  • 技術路線定案（#779 docs，20:21）：iluvatar 0.20.2 的最終確定性路線是 flag_gems GEMM 族整族黑名單（linear/mm/mm.out/addmm/addmm_/addmm.out/bmm/bmm.out → 回落 native corex ixblas）。根因敘述很完整：vllm_fl 的 flag_gems.enable() 會把 aten::linear 等劫持到 flag_gems triton linear_kernel；該 kernel 被 flagtree 編譯後在 live 引擎內逐 launch 非確定（~1-2 bf16 ulp，offline 確定，temp=0 長程解碼在近並列取樣帶翻轉），而同源 kernel 用廠商 corex triton 編譯則 bitwise 確定（== native）。黑名單必須整族排（native linear 會降級 addmm，只排 linear 仍被劫持）。GEMM 走 native 後 F/T 雙路徑均 30/30 temp=0 確定，且吞吐反超（F 14.0 tok/s vs flag_gems linear 12.3，native ixblas 快於 flagtree 編譯的 flag_gems kernel）；silu_and_mul 保持 flagos（GEMM native 下不再翻轉）。編譯器差異是分水嶺：同一 flag_gems 源 kernel，flagtree 編譯非確定、corex triton 編譯確定——上游交接已開 FlagGems #6054-6057（linear/mm/addmm/bmm）。4.4.0 T 路徑仍需 VLLM_FL_USE_FLAGGEMS_ATTN=1（corex triton 3.1 編不了 vLLM 原生 attention）；4.5.0 T（corex triton 3.2）無需 env；已知非阻塞限制為 4.5.0 T 冷引擎首請求翻轉。
  • PR #450 仍在途：iluvatar 0.20.2 的外掛側補丁（symm-mem stub guard、PyTorch sampler 回退，base release/0.2）09-07 16:59 更新後仍未合入。

解讀：這條線是 09-05 以來天數智芯交付敘事的第三次轉向收斂：09-05 env 注入方案 → 09-06 晚 revert、改外掛配置 silu_and_mul 黑名單（#450）→ 09-07 晚以 30/30 實測定案 GEMM 族整族黑名單，且這次是”確定性 + 效能”雙贏（排掉 flagtree 編譯路徑反而更快）。文件把根因落在編譯器分水嶺——同一 kernel 原始碼由 flagtree 編譯逐 launch 非確定、由廠商 triton 編譯 bitwise 確定，這是一個比”哪個運算元”更深的結論：在 flagtree 的 live 編譯確定性被根治（FlagGems #6054-6057 交接給上游）之前，國產晶片上 flag_gems 運算元的確定性交付都要靠黑名單/回落機制兜底。這對 FlagOS 的”flag_gems 全量替換”敘事是重要的誠實註腳；對天數智芯而言，corex4.4.0/4.5.0 雙棧 0.20.2 的確定性交付路徑自此有據可查。

3.3 沐曦（metax）與寒武紀（cambricon）：sglang 0.5.18 交付線擴圍（09-07/09-08）

來源：build-infra #781（09-07 22:49）、#783（09-08 07:18）、#784（07:27）、#773（09-07 13:10）

  • 沐曦 metax-maca3.7.2.1 sglang 0.5.18 線開通：22:49 #781 新增 maca3.7.2.1 的 sglang app 配置（deps_app/app env）；09-08 07:18 #783 登記 app 映象 tag 2.1.2-0.1.dev1_ga73b27b60；07:27 #784 docs 記錄 maca3.7.2.1 的 sglang 0.5.18 F/T 雙路徑 E2E 透過，並把外掛側 PR #86 寫進驗證矩陣。runner 配置裡 maca3.8.1.3 線也已具備。
  • 寒武紀 cambricon-neuware4.4.3：09-07 13:10 #773 docs 記錄 neuware4.4.3 的 sglang 0.5.18 交付（承接前日 0.20.2 側記錄節奏）。

解讀：sglang 0.5.18 的交付矩陣在 RC1 切線後繼續右移——沐曦 maca3.7.2.1 以”F/T 雙路徑 E2E 透過 + 外掛 PR #86 關聯”完成閉環，寒武紀 neuware4.4.3 補齊交付記錄。結合前日燧原 tops1.9.10/摩爾執行緒 musa4.3.6 的 sglang 0.5.18 記錄，“vLLM 0.20.2 與 sglang 0.5.18 雙推理框架 × 多廠商 SDK 線”的交付矩陣已基本鋪開，每條線的登記都帶映象 tag 指紋與外掛 commit 關聯——這正是 RC1 manifest 裡 vllm-plugin/sglang-plugin 雙條目（各自 rc1.post1）背後的工程事實。

3.4 外部生態：昇騰驗證記錄與 from-scratch 修復、崑崙芯 KernelGen 運算元、sunrise 新後端接線（09-07/09-08）

來源：build-infra #772（sunrise env）、#775/#780/#782（昇騰）、#778（外部黑名單 lead）、FlagGems-Experimental KernelGen Kunlunxin 運算元

  • 昇騰（ascend）sglang 0.5.18 驗證與修復：#780（22:10）登記 cann8.5.0 sglang app 映象 tag 2.1.2-0.1.dev1_g0f98ddc20；#782（09-08 07:16）docs 記錄 cann8.5.0 的 sglang 0.5.18 驗證；#775（19:46）修復 ascend 從零構建場景下 sglang serve 的 env 注入（USE_FLAGGEMS=0 分支）；#778（20:19）記錄 ascend index_select 需要外部黑名單的線索（與 3.2 同族的確定性排查外溢到昇騰）。
  • 崑崙芯（kunlunxin）：FlagGems-Experimental KernelGen 批次合入 Kunlunxin digamma/arctan（minimax 多項式 kernel）/bernoulli 三個運算元（1.3，ZhiwenDeng）。
  • sunrise 新後端接線（#772，12:49）：build-infra 為 runner 配置新增 sunrise 廠商的裝置可見性 env（TANG_VISIBLE_DEVICES=all，sunrise 工具鏈線 tangrt1.2.0 此前已列於 runner 清單）。sunrise 尚未出現在已公開的成員單位名單中，按工具鏈命名（TANG RT）推測為以 TANG 為字首的加速器執行時；本視窗動作是把其容器啟動引數補全，屬接入早期階段。

解讀：外部生態三條線分別對應”深度適配廠商”（昇騰——已與成員單位同級，sglang 驗證+確定性排查外溢）、”運算元眾智”（崑崙芯——KernelGen 數學函式運算元）、”新後端儲備”（sunrise——runner 配置先行，尚無元件合入）。昇騰的 index_select 外部黑名單線索值得跟蹤：3.2 的”編譯器分水嶺”結論如果同樣適用於昇騰的 flagtree 路徑，說明確定性問題是 flagtree 編譯路徑的系統性課題而非 iluvatar 個案。

四、總結

本視窗（09-07 10:18 ~ 09-08 10:18）GitHub 側 91 條視窗內提交、30 倉推送，為近期最活躍視窗之一；新聞側元件級檢索六連平靜，但生態側出現視窗內事件（上海論壇）。四條主線：

  1. FlagOS 2.2 RC1 正式切線（09-07 11:11 起）：community 合入 release-2.2-rc1.yaml（25 個清單條目/22 倉庫，+252 行），release-branch-tag 工作流預設切 rc1，隨後 11 分鐘內至少 12 倉集中打出首輪 rc1.post1 驗證 tag（FlagSparse 於 11:27 釋出 rc1.post1 release）——昨日”看 community 清單倉庫動作”的預判兌現，RC0→RC1 釋出管線切換完成。版本錨點：flaggems v5.4.0、flagscale v2.1.0、kernelgen v2.2.0、flagcx v0.14.0、flagtree 0.7.0（triton 3.6/3.5/3.3 三線）；按時間表 09-01~09-24 為多晶片矩陣測試期、09-28 GA。後續訊號：rc1.postN 遞增節奏與 09-24 前後 RC-final。
  2. FlagScale 訓練棧三事件：KERV 具身投機解碼訓練/推理整合合入（#1278，OpenVLA verifier + LIBERO 推理 + 14 運算元 + 33 單測，訓練棧首次覆蓋具身策略投機解碼）；Megatron-LM-FL 與 FlagScale 同晚對齊 Megatron-LM v0.18.2；CICD 移除 inference/serve 管道、聚焦訓練（推理職責進一步歸 vllm/sglang 外掛）。
  3. 確定性課題浮出”編譯器分水嶺”：天數智芯 0.20.2 最終定案為 flag_gems GEMM 族整族黑名單回落 corex ixblas（#779，F/T 30/30 確定且吞吐反超 14.0 vs 12.3 tok/s）；根因是同一 flag_gems kernel 由 flagtree 引擎內編譯逐 launch 非確定、廠商 triton 編譯 bitwise 確定，上游交接 FlagGems #6054-6057；昇騰側出現同類外部黑名單線索。同日 corex4.4.0/4.5.0 雙棧以 g16e8655 指紋登記 0.20.2 新交付。
  4. 多晶片交付矩陣與運算元矩陣持續右移：sglang 0.5.18 線沐曦（maca3.7.2.1，F/T E2E 透過）、寒武紀（neuware4.4.3）、昇騰（cann8.5.0）記錄閉環；清微 txda 後端以廠商自有 PR 合入 vllm-plugin-FL main 線（vLLM 0.24.0）；FlagGems-vllm 同日合入達摩院玄鐵 PPU-ZW810E 與海光 DCU 兩個專用 fused-MoE 後端；FlagBLAS Ascend L2 例程（CHER/CHER2/SSYR/CSYR）批次補齊；FlagGems-Experimental 建 sync-to-kernelgen CI 並批次同步跨後端 KernelGen 運算元。

預判：RC1 已切線，元件預設分支進入”只收 bug 修復”的測試穩定期，未來兩週 GitHub 側看點從”新特性合入”轉向rc1.postN 驗證 tag 的遞增節奏與交付記錄密度（build-infra 的記錄頻率是 RC 進度的最佳代理指標）；FlagGems #6054-6057 的編譯器確定性交接值得跟蹤（若根治，國產晶片上”flag_gems 全量替換”才真正無後顧之憂）；FlagTree 單 wheel（含 Prism debugger/profiler）與 KERV 具身訓練鏈路是 2.2 GA 時值得驗證的兩個新能力點；清微（FlagTree 後端 + vLLM txda 線）與外部新後端（sunrise）的接入進度可作成員單位生態擴張的觀察項。

附錄：完整信源清單

信源 核查結果
GitHub org repos API（flagos-ai，52 倉） 30 倉視窗內推送；社群/FlagScale/FlagGems 等 14 倉預設分支實質合入；FlagSparse/FlagDNN/sglang-plugin-FL/release-info/docs/FlagTree(09-08) 等經預設分支 commits 核驗為 PR 分支或標籤動作
GitHub commit search（org 全量 91 條，sort=committer-date） 逐條核驗 committer 時間與歸屬倉庫；覆蓋全部預設分支實質合入
GitHub PR/commit 詳情（community #107、FlagScale #1278、FlagGems-vllm #696/#746、vllm-plugin-FL #447/#450、build-infra #779/#772 等） 提供 manifest 內容、KERV 範圍、fused-MoE 細節、txda 歸屬、確定性路線全文
GitHub tags/releases API + 日期核驗 FlagSparse v0.3.0-rc1.post1 release 09-07 11:27 釋出；FlagCX/FlagGems-sglang/vllm-plugin-FL rc1.post1 tag 存在；12 倉 11:22~11:33 集中推送（RC1 tag 波）
community release/2.2 目錄（raw） release-2.2-rc1.yaml 全文 25 條目；schedule_CN.md（08-31 凍結/09-28 GA）；release-branch-tag.yml 預設 rc1
Google News RSS（中英 14 組，走代理） 元件詞視窗內零命中；智源研究院詞 58 條為社群部落格+博彩 SEO 噪音整批剔除；天數/沐曦命中為商業新聞不收錄
HN Algolia（FlagOS/FlagGems/flagos-ai/BAAI） 零相關命中
Tavily/web 檢索 僅命中 FlagOS 社群上海論壇（CSDN 官方號）一條視窗內生態事件
FlagOS CSDN 官方號（flagos.csdn.net） 論壇公告 09-07 09:57 釋出（6a9e1a10…）；最新內容確認無其他視窗內更新