調研視窗：2026-10-22 06:00 ~ 2026-10-23 06:00（北京時間，24 小時；週五晨報，視窗自上一期日報截點接續）。

信源：GitHub（org: flagos-ai 61 倉庫全量核查、提交檢索 135 筆、合併 PR 163 筆與在審 PR 183 筆檢索、org 事件流 100 條、31 個倉庫 Release/Tag 原子核查、4 倉 Atom 兜底）、Google News RSS（24 組中英文查詢詞，走代理）、HN Algolia（8 組）、CSDN FlagOS 專欄、智源社群、具身之家與 Pandaily 原稿（詳見附錄信源清單）。

本期索引

  • 今日重點：合入 163 筆創近一週新高；海光的 vLLM 0.28 與 SGLang 0.5.18 雙棧同日合入，FEP-0140 與 FEP-0141 各兌現第一格；FlagQuantum 把 M3 中性原子從設計契約推到可跑的原生 Rydberg 動力學（10-22）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：16 倉推送、135 筆提交、163 筆合入，佇列在清、新增在收（10-22）
    • 1.2 vLLM 0.28 與 SGLang 0.5.18 的海光線同日合入（10-22）
    • 1.3 FlagQuantum：53 筆提交、20 筆合入，原生 Rydberg 從契約變程式碼（10-22）
    • 1.4 FlagQuantum：部署拒絕、供應商退場與終端取樣提案（10-22）
    • 1.5 FlagGems：91 筆合入，KernelGen 39 筆批次落地與崑崙芯 13 筆最佳化並行（10-22）
    • 1.6 FlagGems 測試主線：lukatao 61 筆，連夜開 14 筆批次改「直連候選」（10-22 ~ 10-23）
    • 1.7 build-infra：崑崙芯成為 FlagTree 第七後端，flagcx 0.14.0 釘到全部後端（10-22）
    • 1.8 Torch-FL：清微接上 rocprofiler-sdk，崑崙芯跨卡複製改走 peer 原語（10-22）
    • 1.9 FlagTree：AMD RDNA 補上 prefill 路徑，MUSA 逐複製 TME 快取（10-22）
    • 1.10 其餘倉庫：FlagBLAS 天數與摩爾執行緒 GEMM、賽事通道兩筆、optest 打成 wheel（10-22）
  • 二、新聞報道與生態
    • 2.1 Pandaily 以英文系統轉述 FlagOS 2.2：1454 運算元、約 27% 跨芯提升、KernelGen 765 個新運算元（10-22）
    • 2.2 跨維智慧入選眾智 FlagOS 加速計劃擬立項：FlagOS-Robo 與 AlohaMini 端側示範（10-22）
    • 2.3 渠道核查：17 條候選 2 條有效，CSDN 新增高校圓桌直播，智源社群僅得框架頁（10-22）
  • 三、成員單位與後端廠商深挖
    • 3.1 海光：兩個推理外掛倉同日完成上游版本對齊（10-22）
    • 3.2 崑崙芯：13 筆運算元最佳化，疊加 FlagTree 第七後端（10-22）
    • 3.3 清微：裝置時間線進入 torch.profiler，TX8110 實測（10-22）
    • 3.4 摩爾執行緒與燧原：MUSA 快取持久化、GEMM 與燧原整批更新（10-22）
    • 3.5 昇騰、天數、沐曦與其他：按後端分流的小步，地平線與寒武紀靜默（10-22）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表與完整信源清單

今日重點：163 筆合入創近一週新高；海光雙棧同日對齊，量子棧把 M3 從契約推到可跑（10-22）

日期：2026-10-22　來源：vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · FlagQuantum PR #700 · build-infra PR #1468（全量見附錄）

  • 節奏面：61 倉中 16 倉視窗內有推送，提交檢索 135 筆，合併 PR 163 筆，在審 PR 183 筆視窗內有更新（其中新開 90 筆）。與上一期（10-21：22 倉、164 筆提交、151 筆合入、154 筆在審、64 筆新開）相比，合入增 8%、在審增 19%、新開增 41%，推送倉庫減 27%、提交減 18%——佇列在清，新增開發在收。
  • 版本面第一次兌現：海光的 vLLM 0.28.0 與 SGLang 0.5.18 兩個上游版本適配在同一天合入，這是 10-21 合入的 FEP-0140（vLLM 三版本線）與 FEP-0141（SGLang 0.5.18 十家廠商）之後第一次出現「按 FEP 矩陣逐格落地」的實證。
  • 量子棧跨過設計階段：FlagQuantum 53 筆提交、20 筆合入，Core 側的原生 Rydberg 程式、Simulation 側的 plan 1.7 動力學、Examples 側的移動原子脈衝訓練三塊同日合入，昨天還是兩份設計契約的中性原子路線，今天已有可跑的 CPU 路徑與驗收數字。
  • 構建側第七後端：build-infra 把崑崙芯（XPU）接上 FlagTree 構建線與日常構建行，成為 enflame、hcu、tsingmicro、mthreads 之後的第七個後端，PR 自述為「當前集合的最後一行」；同日把 flagcx 0.14.0 從 nvidia 專屬釘成全部後端的顯式依賴。
  • 測試設施同步改造：optest 由指令碼集合變成可安裝 wheel 與 console commands；FlagGems 側一人 61 筆合入，其中 23:40 至 23:47 一口氣開出 10 筆批次 PR，把用例從包裝函式改成直接調運算元或注入候選。
  • 新聞側本視窗兩條有效稿：英文媒體 Pandaily 系統轉述 2.2；國內出現 FlagOS-Robo 的政府加速計劃立項案例。軟體棧之外的這兩條，是本視窗唯一不來自 GitHub 的資訊增量。

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

1.1 組織節奏：16 倉推送、135 筆提交、163 筆合入，佇列在清、新增在收（10-22）

日期：2026-10-22　來源：flagos-ai 組織倉庫 · 提交檢索 · 合併 PR 檢索

  • 倉庫面：61 倉中 16 倉視窗內有推送，按提交量依次為 FlagQuantum 53、FlagGems 29、build-infra 13、Torch-FL 12、FlagGems-sglang 8、FlagTree 5、FlagGems-vllm 4、FlagBLAS 3、optest 3、FlagTrain 2、FlagOps 2、FlagDNN 1。docs、release-info、sglang-plugin-FL、vllm-plugin-FL 四倉的推送落在非預設分支，主分支無新提交。
  • 合入面：合併 PR 163 筆，分倉為 FlagGems 91、FlagQuantum 20、build-infra 13、Torch-FL 12、FlagTree 6、optest 4、vllm-plugin-FL 4、FlagGems-vllm 4、FlagGems-sglang 3、FlagTrain 2、FlagBLAS 2、FlagOps 1、sglang-plugin-FL 1。FlagGems 與 FlagQuantum 合計佔 68%。
  • 在審面：視窗內有更新的 open PR 183 筆，其中新開 90 筆；倉庫分佈為 FlagGems 86、FlagGems-vllm 18、Torch-FL 13、vllm-plugin-FL 12、FlagTree 11、FlagTrain 6、FlagGems-Experimental 6、sglang-plugin-FL 5。FlagGems-vllm 與 TransformerEngine-FL 的新增量集中在廠商側融合運算元。
  • 產能面：lukatao 在 FlagGems 合入 61 筆（佔該倉 67%），全部為測試與用例契約；FlagQuantum 賬號合入 20 筆；tengqm 包乾 build-infra 13 筆；lvyufeng 在 Torch-FL 合入 11 筆；lvxu2020 在崑崙芯 XPU 線合入 6 筆。
  • 版本面：視窗內無新版本釋出。最近三個標籤仍是 FlagTree 的 0.7.1.dev1 與 0.7.1.dev1+ppu3.6（10-20 20:11）以及 0.7.1a1+ascend3.5（10-19 13:01），均歸入此前各期。
  • 事件面：org 事件流 100 條，其中 PR 事件 43、推送 27、刪分支 12、建分支 9、評論 4、評審 3、關注 2。刪分支 12 與新開批次 PR 同日出現，反映的是「批次分支合併即刪」的流水線習慣，非功能回退。
  • 判斷：合入、在審、新開三項同時上行而提交與推送倉庫下行，是本季度少見的組合。它的含義是評審吞吐在消化前兩日積壓（10-20 至 10-21 合計約 300 筆合入），而開發者當天新建的程式碼量收縮。此類節奏通常出現在里程碑收口前後。

1.2 vLLM 0.28 與 SGLang 0.5.18 的海光線同日合入（10-22）

日期：2026-10-22　來源：vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · vllm-plugin-FL 倉庫 · sglang-plugin-FL 倉庫

  • vLLM 側（#576，19 檔案，+1436/−288）：把海光 BW1000 的外掛升級到 vLLM 0.28.0，發行包標識 0.28.0+empty、模組版本 0.28.0、原始碼基線 2cf0a6915。驗證環境為每卡 64 GiB、容器內普通 wheel 安裝（不使用可編輯安裝）、TP=2、最大模型長度 4096、最大序列數 8、視訊記憶體利用率 0.85，eager 與 FULL_AND_PIECEWISE 兩種圖模式各跑一遍；通訊走廠商 HIP/RCCL，FLAGCX_PATH 未設定。
  • 版本拼圖：PyTorch 用廠商 2.10.0（+das.opt1.dtk2604，DTK 26.04 保留），FlagTree 為 0.6.0+hcu3.6（wheel SHA256 字首 0fd81f0e），Triton 發行版 3.6.0+gitc73250c4.staging，與廠商 Triton 共存；執行時映象 vllm-plugin-fl:v0.28.0-hygon-ci。
  • 可比對性：倉庫對已安裝的 1,944 個 FlagGems 原始檔與包檔案逐檔案比對，全部命中 e12a220 這個提交（僅 CRLF/LF 行尾差異），但安裝後設資料裡的版本仍是 0.1.0——即版本號不可信、內容可核對，這種「以內容代替 VCS 後設資料」的取證方式在近幾期反覆出現。
  • SGLang 側（#138，65 檔案，+4940/−369）：把海光 BW1000 的 empty 後端升到 SGLang 0.5.18（tag 源 71de97b，另加 HCU 專用的 Quark 匯入補丁），適配 attention、FLA 與 MoE 介面，並修掉流水並行下的協同退出問題。驗證含單機 TP2 的 eager 與全解碼圖，以及物理兩節點 TP4/PP1 與 TP2/PP2 的 eager 用例；流水線門禁用 BF16、上下文 4096、最大併發 16、視訊記憶體比例 0.70。
  • 版本拼圖：FlagTree 0.6.1+hcu3.6（Triton 由 FlagTree 提供，不另裝獨立 Triton），FlagGems 5.4.0.dev0，原生 FlagCX 0.13.0，廠商 sglang-kernel 0.4.2.post2、flash-attn 2.8.3；CI 映象 sglang-plugin-fl:0.5.18-hygon-ci-20261015，按 sha256 釘住。
  • 判斷：兩個 PR 都走「empty 執行時 + 廠商棧」路線，驗收物件寫成具體版本號加具體圖模式，而不是「已適配」這類模糊表述。按 FEP-0140，vLLM 0.28 是十一月的主釋出版本、目標是十家廠商；按 FEP-0141，SGLang 0.5.18 覆蓋十家廠商、節點在十二月中前。海光是第一個點亮的格子，不等於其餘九家已到位；接下來的觀察點是同一個 0.28.0 版本在清微、沐曦、燧原、崑崙芯上是否複用同一條安裝路徑。

1.3 FlagQuantum：53 筆提交、20 筆合入，原生 Rydberg 從契約變程式碼（10-22）

日期：2026-10-22　來源：FlagQuantum 提交 · PR #700 · PR #707 · PR #714

  • 總量：53 筆提交、20 筆合入，提交佔全組織 40%，合入居第二。與上一期（84 筆提交、34 筆合入）相比規模減半，但性質變了：上一期是動態電路的 Program IR 與出圖補鏈，本期是中性原子物理從文件落到執行。
  • Core 前端（#700，22 檔案，+2198/−16）：原生 Rydberg 控制不再借用線路適配，而是由 Core 直接在 ProgramRecord 上提供前端。記錄增加型別化的 context 與 control 欄位，既有驗證器只接受一個物理 profile 並複用 CFG/SSA 檢查；連續路徑安全用編碼座標上的精確算術判定，與數值演化解耦；源編碼複用既有標量編解碼器，原生專用的嚴格欄位與規範檢查在任何張量解碼之前就拒絕非法輸入。未引入新的 IR 層級、繫結器、求解器、登錄檔或根匯出。
  • 使用者 API：RydbergProgram 以原子、位點、長度與時間單位、C6、損耗率、最小間距、傳輸通道與驅動通道構造，提供 move、pulse、to_ir 三個動作，示例輸出原子標識 ('a','b')、維度 (3,3)、受控位置 (3.0,0.0) 與存活運算元形狀 (9,9)。PR 明確寫明「受控位置不代表物理存在」。
  • Simulation（#707，19 檔案，+1488/−188）：原生 Rydberg 程式可以走既有的 Lindblad 計劃、執行與初始密度伴隨入口，使用者宣告原子、線性傳輸、脈衝與吸收損耗，Simulation 自行裝配區間矩陣；plan 1.7 密封為恰好七個外層欄位，執行時不重新編譯源。實驗性數值路徑為 CPU-only、一至兩個 g/r/lost 角色，更大規模在指數級記憶體分配前拒絕；幾何是施加線性路徑的區間中點近似，網格收斂證據與求解器精度分開記錄。
  • Examples（#714，3 檔案，+217）：訓練兩個脈衝幅度繫結並讓原子對移動，40 步、128 區間的實測輸出為：無條件 RR 由 0.0431 升至 0.1228，存活條件 RR 0.1500，no-flag 選擇 RR 0.1439，精確數值回放成立。本地預設全量 14,584 透過、167 跳過，約 518 秒；首輪 64 區間曾在 2.28e-10 上失敗一個梯度，細化到 128 區間後透過且未改求解器與斷言。
  • 判斷：一天之內，量子棧把「能宣告原子與脈衝」到「能算動力學」再到「能訓練控制引數」三段接上，且每一段都寫明能力邊界（不宣稱取樣事件、反饋、加熱、量子運動、GPU 或分散式，也不宣稱 M3 完成）。這是本季最有資訊量的單倉推進方式：先把契約寫成可拒絕的實現，再逐塊放開。

1.4 FlagQuantum：部署拒絕、供應商退場與終端取樣提案（10-22）

日期：2026-10-22　來源：PR #701 · PR #705 · PR #716 · PR #720

  • 部署側拒絕（#701，3 檔案，+78/−1）：原生物理程式不是數字線路，包構建器原先從 ProgramRecord 讀線路後設資料會拋 AttributeError，Pauli 包構建器則拋無方向的 TypeError。現在兩個入口都在後端選擇、編譯與發射之前交給 Core 的拒絕邏輯，統一拋 CapabilityError，提示「原生 Rydberg 時間線不能作為線路執行，請用 flagquantum.lindblad」。四個新迴歸在修正前全部失敗，修正後三個 Python 版本各 39 個測試透過。
  • 供應商退場（#705，17 檔案，+159/−621）：通用 NeutralAtomProvider 從來沒有對應的外部服務或任務協議，只解析本地幾何並始終拒絕提交。按提案 082 直接刪除該模組與兩個 Remote 名稱空間的匯出，不留別名、不留空殼介面卡；Core 的幾何、RydbergProgram 與舊計劃/源韌體保持不變。
  • 終端取樣提案（#716，4 檔案，+379）：在 #707 之後提出提案 083，定義 Runtime 的 sample_terminal 原語——消費有序的全空間張量 Kraus 分支，複用 SuperOperator、既有密度校驗、當前 MeasurementResult、Core 張量編碼與 Torch 隨機源。示例給出存在性標籤 ('no_flag','flag') 與機率 0.68/0.32、Fock 數標籤 0/1/2 與機率 0.6/0.3/0.1，末尾明確列印「Framework terminal instrument API: proposed, not implemented」。PR 正文寫明提案 083 尚未批准、尚未實現。
  • 其餘支線：#710 註冊自定義運算元時同步安裝 Circuit 方法；#711 在 Circuit 伴隨中拒絕非酉矩陣；#712 精確保留極小的非零門（不因閾值摺疊成零）；#713 動態線路晉升就緒審計；#720 測量容量隨秩的變化與表示一致性區間；#721 讓控制指令自帶運算元；#722 在注入時鐘下標定引擎排序，消除偶發失敗。
  • 判斷：本期量子棧的一半合入量花在「拒絕」與「刪除」上——拒絕把物理程式當線路打包、刪除沒有外部服務的供應商、凍結未批准的取樣介面。這類動作不增加能力，但決定了後續 M3 的邊界是否可信。

1.5 FlagGems：91 筆合入，KernelGen 39 筆批次落地與崑崙芯 13 筆最佳化並行（10-22）

日期：2026-10-22　來源：FlagGems 提交 · PR #7077 · PR #7107 · PR #7424

  • 總量：29 筆提交、91 筆合入，佔全組織合入的 56%。全組織 163 筆合入按標題關鍵詞計（可重疊）為：測試類 47、KernelGen 39、崑崙芯 13、昇騰或 NPU 9、海光或 DCU 7、燧原或 GCU 5、摩爾執行緒或 MUSA 5、CI 4、沐曦 3；其中落在 FlagGems 倉內的為崑崙芯 10 筆、昇騰 7 筆、摩爾執行緒 4 筆、燧原 2 筆、海光 2 筆。
  • KernelGen 批次落地：14 個 Nvidia 運算元分三批合入，批次內時間戳密度說明是稽核透過後的成組合入，不是逐個評審。
  • 10:43 批：_copy_from_and_resize、ger、sparse_bsc_tensor；
    _nested_tensor_from_tensor_list。
  • 15:23 批：_values_copy、_fw_primal_copy、_shape_as_tensor；
    _nested_tensor_storage_offsets、_convert_indices_from_csr_to_coo。
  • 22:23 批：swapdims、_nnz、moveaxis、_dimI 與 view_as_complex_copy。
  • 燧原整批（#7077，26 檔案，+3520/−511）：廠商 10-13 的整批更新一次性進主幹，標題只寫「update from enflame 20261013」，PR 正文僅標註 Operator 與「缺陷修復與效能最佳化」，沒有逐條明細。這是近一週單筆程式碼量最大的廠商側變更之一。
  • 崑崙芯融合 MoE（#7107，13 檔案，+496/−123）：補齊 XPU3 的 fused_experts_impl、inplace_fused_experts、outplace_fused_experts 三個運算元與 dispatch_fused_moe_kernel，前三個聚合分分別為 1.327、1.329、1.324（bf16 均值 1.346 至 1.351、fp16 均值 1.302 至 1.306）。PR 主動寫明兩點保留：其一，官方契約基線是 vLLM 自身的 fused_experts_impl，該基線在 XPU 棧上無法構建，因此昆芯只對替代的非契約基線（逐專家 index_select 加 matmul）比較，三個數字只能讀作「融合勝非融合」；其二，dispatch_fused_moe_kernel 聚合 0.626 低於 0.8 門檻，不宣稱達標。
  • CI 三筆：#7424 關閉 flagcx 以修 cuda12 依賴錯誤（nvidia133 後端上 mm_w8a8_fp8 失敗）；#7500 修環境變數位置錯誤；#7420 把 robust-checkout 超時提到 60 秒。
  • 判斷：91 筆中真正增加運算元能力的不足兩成，主體是自動化產出（39 筆）與測試契約（47 筆）兩類。崑崙芯那條線已進入「按基準聚合分逐項摳」的階段，且開始主動標註基線的可比性瑕疵——這比數字本身更值得記。

1.6 FlagGems 測試主線：lukatao 61 筆，連夜開 14 筆批次改「直連候選」（10-22 ~ 10-23）

日期：2026-10-22 ~ 2026-10-23　來源：PR #7543 · PR #7552 · PR #7556 · optest 倉庫

  • 規模：lukatao 一人合入 61 筆，佔 FlagGems 當日 67%、全組織 37%；其中 56 筆標題為測試、修復、校驗或同步類，無一筆新增運算元。
  • 批次開單：10-22 23:40 至 23:47 七分鐘內開出 10 筆 PR——foreach 覆寫「直連路由」批次 01 至 09（#7543 至 #7551）加 #7552「把最後九個運算元套件改為走公共候選 API」。這批改動把用例從 use_gems() 包裝改成直接呼叫 flag_gems.* 或注入候選實現，等於把「測哪個實現」從隱式變成顯式。
  • 連夜合入：視窗末四筆稀疏套件移植在凌晨連續落地——#7553（01:00，稀疏 log-softmax 跨後端可移植）、#7554（02:51，稀疏校驗器韌體與直接基準候選呼叫）、#7555（04:38，壓縮稀疏校驗器）、#7556（05:47，公共稀疏塊構造器）。最後兩筆距本報告截點不足半小時。
  • 後端跳過治理：昇騰與摩爾執行緒的跳過被逐條寫明理由並限定輸入域（#7483 linalg_vander 複數輸入、#7485 logdet 複數、#7492 row_stack_out 記憶體格式、#7496 trapz complex32、#7502 orgqr MUSA 零列、#7503 與 #7504 MUSA qint32、#7505 Hygon cuDNN 校驗），海光側 #7460 修 FP8 稀疏求和反向的輸入韌體。
  • 判斷：這條線不產生任何對外能力，卻是 FlagOS 多後端可信度的地基——同一條 PyTorch 用例要在十幾種後端上給出可解釋的透過或跳過，而不是各自維護一份改過的測試。optest 當天也把工具鏈打成可安裝 wheel（#4）、改成 src 佈局（#5）、暴露 console commands（#6），與 FlagGems 的用例改造是同一件事的兩端。

1.7 build-infra：崑崙芯成為 FlagTree 第七後端，flagcx 0.14.0 釘到全部後端（10-22）

日期：2026-10-22　來源：PR #1468 · PR #1471 · PR #1459 · PR #1462

  • 總量：13 筆提交、13 筆合入，全部由 tengqm 完成，是當期平臺面最集中的倉庫。
  • 第七後端（#1468，3 檔案，+428/−9）：packaging/flagtree/kunlunxin 採用與近期後端同形的兩段式 Containerfile——--target builder 是可釋出的構建環境（裸 ubuntu 22.04 加 apt 工具鏈，預編譯輸入暫存進 FlagTree 離線快取），末段在其上構建 wheel。崑崙芯有五處獨有約束：其一，十個預編譯輸入且快取按目錄名匹配，兩個 LLVM 19 包共享 tarball 根 xtdk-llvm19-ubuntu2004_x86_64，落成 xtdk-llvm19 與 xtdk-llvm19-printf，故 filestore 名帶版本字尾，只有 triton 工具包以 .triton/ 為根需 --strip-components；其二，前端由環境變數選擇，LLVM_SYSPATH 必須保持未設，公共 LLVM 是已驗證分支、XTDK 是回退；其三，pybind11 精確釘 3.0.1，3.0.4 改了 internals 構造會讓派發器 SIGSEGV；其四，不用 apt 的 patchelf，改從 PATH 或公共 LLVM 包自帶副本解析，與廠商 CI 同路徑；其五，不加 TRITON_APPEND_CMAKE_ARGS=-DCMAKE_BUILD_TYPE=Release，因為昆芯釋出的廠商 wheel 本身是 rel-with-asserts，對外部編譯器而言最佳化級別不是打包細節。
  • 通訊依賴（#1471，3 檔案，+60/−4）：flagcx==0.14.0 此前只在 nvidia-cuda12.8 與 nvidia-cuda13.3 兩行有 pin，其餘十八個後端仍從 triton/_C 解析。本次給其餘十八個後端加上精確 pin，且標籤取廠商索引實際服務的值而非由後端鍵推導（hygon-dtk26.04 釋出的是 +dtk2604）；spacemit 與 thead-ppu2.0.0 不釘，因為兩者索引裡沒有 flagcx wheel。同一 PR 順手改掉了兩處因此過時的文件描述。
  • 文件線：vllm-plugin-FL、FlagTree、FlagCX、FlagGems、FlagLibs、Megatron、SGLang、verl 八個元件的設計記錄與站點頁在 12:50 至 17:42 之間連續合入（#1462 至 #1470），是本季第一次把「構建設計」寫成可檢索的站點內容。
  • 其他：#1459 刪掉過時的廠商字首 hygon 輪子行；#1461 讓呼叫方可收窄 manifest 下載模式。
  • 判斷：構建器從六後端擴到七後端，並在同一天把通訊庫從「兩家 nvidia 行的特例」改成全部後端的顯式依賴。後者是更實質的變化：它決定了換後端時通訊層是否還走同一條安裝與符號解析路徑。

1.8 Torch-FL：清微接上 rocprofiler-sdk，崑崙芯跨卡複製改走 peer 原語（10-22）

日期：2026-10-22　來源：PR #630 · PR #634 · PR #632 · PR #629

  • 總量：12 筆提交、12 筆合入，跨 MPS、崑崙芯、昇騰/海光/沐曦/PPU、GCU 與清微六個平臺。
  • 清微裝置剖析（#630，15 檔案，+1383/−39）：清微上 torch.profiler 此前只出 CPU 活動——平臺被路由到 unavailable 樁，PrivateUse1 沒註冊裝置剖析器，沒有 kernel 事件、沒有 CPU 到 kernel 的箭頭，self_device_time_total 恆為 0。本 PR 增加基於 rocprofiler-sdk 的 DeviceTracer 與獨立剖析工具 libtorch_fl_profiler.so，把每個 NPU kernel 關聯回發起它的 aten op，按 CUDA trace 的 CPU/device 佈局渲染；同時在 TX8110 上實測，並給清微釘上 FLAGOS_BUILD_VENDOR=ON（廠商目錄裡放的是隨機數核心），補齊安裝與剖析文件。不請求剖析時行為不變。
  • 崑崙芯跨卡複製（#634，3 檔案，+55）：CrossDeviceMemcpy 呼叫的是同卡語義的 xpu_memcpy（XPU_DEVICE_TO_DEVICE 型別），傳入兩張卡上的指標時返回 −801 且目標不被寫入，於是任意 flagos:N → flagos:M 傳輸都靜默無效。改走 SDK 的 peer 原語 xpu_memcpy_peer。問題由 P800 上最後一個 bert 失敗查出，同步呼叫不會掩蓋，說明不是時序問題而是位元組從未寫入。
  • 預載入順序（#632）：liblaunch_shared.so 報 undefined symbol: cudaMemcpy，該符號在 /usr/local/xcudart/lib/libcudart.so.12 中是版本化定義，只有在 Triton 啟動器 dlopen 之後才可解析，因此把昆芯的 CUDA 相容執行時提前載入。
  • 其他：#629 給 cuda/dcu/metax/ppu 補 convolution_overrideable 例外；#626 讓 Qwen3.5 的後設資料檢視留在 MPS；#635 在 FlagGems 主導的 CUDA 構建裡把型別轉換放到裝置上；#631 把 MPS 測試留在 Apple runner；#618 為 GCU 的 capability AssertionError 加臨時診斷說明。
  • 判斷：當日主線不是效能，而是兩個基礎能力的可用性——可觀測性（清微第一次能看裝置時間線）與多卡正確性（崑崙芯跨卡複製此前一直是錯的）。這類修復不會出現在任何基準表裡，但會讓上層所有多卡實驗的結論重算。

1.9 FlagTree：AMD RDNA 補上 prefill 路徑，MUSA 逐複製 TME 快取（10-22）

日期：2026-10-22　來源：PR #1365 · PR #1385 · PR #1278 · PR #1415

  • AMD prefill（#1365，66 檔案，+3163/−260）：在 #1364 的 M=1 解碼路徑之上補 M>1 的預填執行，包括密集 Qwen3 匯入器的預填模式、M>1 渲染程式碼生成（含 WMMA lm_head）、融合 matmul 加 RMS-norm-stats 核心與 gather-reduce 歸一化收尾、每個預填 token 的 KV 寫入獨立快取槽位，以及「預填只輸出最後一個 token 的 logits」——只切 lm_head 之前的位置，不物化全部位置。RDNA 的預填 WMMA GEMM 微核心相對 GEMV 迴圈在 M>1 時提速 10 至 30 倍，並按 M 自動選擇；解碼側 split-K 把 lm_head 從 17.0 降到 14.9 ms/token、逐層寬投影從 14.9 降到 10.5 ms/token。W7900（gfx1100）與 R9700（gfx1201）上全新編譯後預填有限、argmax=241 與 torch 參考一致（最大誤差約 0.5，屬 bf16 近並列），解碼 next_token=25 不變。
  • 其餘五筆：#1278 修跨 outlined helper 呼叫的柵欄錯位；#1385 為 MUSA 增加逐複製的 TME 快取持久化；#1424 因偶發匯流排錯誤在燧原 CI 停用 02-sparse-mla 用例；#1415 修 minimax_m3 index_topk 的 block_size_k；#1427（10-23 00:06）更新燧原 vllm benchmark 引數。
  • 判斷：AMD 路線從「單卡能解碼」推進到「單卡能預填」，且效能數字是每提交口徑（17.0→14.9→10.5 ms/token）而非整模型對比，可核對性較好。這條線仍以 Qwen3 稠密模型為唯一驗證物件，MoE 與長上下文未覆蓋。

1.10 其餘倉庫：FlagBLAS 天數與摩爾執行緒 GEMM、賽事通道兩筆、optest 打成 wheel（10-22）

日期：2026-10-22　來源：FlagBLAS PR #153 · FlagGems-sglang PR #205 · FlagGems-vllm PR #977 · optest PR #4

  • FlagBLAS（2 筆）：#153 最佳化天數（Iluvatar）L1 層運算元；#152 增加摩爾執行緒的 GEMM 實現。兩個 PR 都是廠商側提交、無跨倉改動。
  • FlagGems-sglang（3 筆）：#205 為 AMD RDNA3 架構層（_amd/rdna3/ops/）增加 fused_moe_gemm、fused_moe_router_tensorcore 與 fused_moe_router_cudacore 的 gfx1100 版本，在 W7900D 上調優，3 檔案 +1310；WMMA 核心按 K 塊在 fp32 中累加單點積，因為跨 K 塊用 WMMA 累加器會在 gfx1100 上掉精度。另兩筆是 FlagOS 賽事 Track1 的作品：#204 fused_pack_qkv、#201 fused_sigmoid_mul，均為 Triton 核心，說明賽事產出已開始進主幹而非停在提交物。
  • FlagGems-vllm（4 筆）：#977 給沐曦融合 MoE 加 TP=2 配置（Qwen3.6-35B-A3B 的 w1=(256,512,2048)、w2=(256,2048,256)），C550 上 14 個 M 值平均提速 1.065 倍，並修掉 M≥4096 時選到 98304 位元組共享記憶體配置導致的 OutOfResources；同時接受 vLLM 的 out、workspace13、workspace2 以免整份輸出複製。#936 讓昇騰的分塊門控增量規則前向（chunk gated delta rule）改用 tle.dsa 的切片與同步介面；#929 由 KMCompiler 增加 qwen_qsa_prepare；#777 補 Hopper 上的變長 flash attention。
  • FlagTrain（2 筆）：#16 增加 multi_tensor_lion（Nvidia、Hygon、Metax、Thead 四後端，KMCompiler 字首）；#26 增加 quick_gelu。
  • optest（4 筆）：#4 把工具打成可安裝 wheel、#5 改成 src 佈局、#6 把已安裝工具暴露為 console commands、#2 讓 CI 作業名顯示 <repo> (<backend>)。
  • 在審值得關注：flir #83 增加 TensorView 方言與 tile.load / tile.store 檢視（CommonIR 方向的實質動作）；verl-FL #22 增加壁仞 SUPA 平臺支援；FlagOS-Compressor #13 給 CLI 加多裝置 MSE 量化與 BF16 轉換；sglang-plugin-FL #149 於 23:36 新開海光 eager Qwen3.6 MTP 解碼；TransformerEngine-FL #144 至 #146 三筆同日指向 NPU（get_num_cublas_streams、cuDNN 版本能力查詢、bshd/thd 佈局）。
  • 判斷：這幾個倉都在「加介面」階段——flir 加 IR 方言、verl 加硬體後端、壓縮器加 CLI、編譯運算元往四個後端鋪。它們尚未進入模型驗收主線，但 flir 與壓縮器的動作會在 2.3 週期裡直接決定 FlagTree 與新模型匯入的邊界。

二、新聞報道與生態

2.1 Pandaily 以英文系統轉述 FlagOS 2.2：1454 運算元、約 27% 跨芯提升、KernelGen 765 個新運算元（10-22）

日期：2026-10-22　來源：Pandaily 報道 · FlagOS 文件

  • 事實骨架：2.2 於 9 月 30 日釋出、10 月 17 日在 2026 人工智慧開放計算大會上展示；九個運算元庫合計 1,454 個運算元，FlagGems 及相關庫的公開運算元由 564 增至 1,454（新增 890）；新增 FlagGems-SGLang 庫含 40 個多芯運算元，覆蓋 attention、Mamba 狀態更新、MoE、LoRA、取樣與量化；在 10 類 AI 硬體、上千個運算元上整體提升約 27%。
  • 自動化口徑（本期新增細節）：KernelGen 已支援 9 款 AI 晶片，本季度生成 765 個新運算元，其中 416 個在至少 5 款國產晶片上透過精度檢查並達到原生運算元 80% 以上效能；FlagPrism 打通 Triton 源、編譯器 IR 與裝置執行資料，支援昇騰、天數、摩爾執行緒、NVIDIA 與燧原。
  • 壓縮與部署：FlagOS-Compressor 以 W8A8 處理 Qwen3.5-397B-A17B，模型檔案由 751.41 GB 降至 382.45 GB（−49.1%），GPQA-Diamond 得分 84.85%；配合 vLLM、Megatron-LM、SGLang 等框架外掛，新模型在釋出後一天內最多適配 12 個晶片平臺。
  • 存量算力案例：昇騰 910B 上 GLM-5.3-Flash 的邏輯服務吞吐由 8.52k 升至 17.36k tokens/s（2.04 倍）；中國電信 Xing4.0-29B-A4B 適配 10 個晶片平臺，長輸入測試的首 token 時延較原生運算元下降 19.87%（此數字為首次出現在公開報道中）。
  • 限界：BAAI 自述問題在時序——已部署算力中超過 80% 不是最新一代，而模型換代很快；文中所有數字來自 BAAI 自測，真實服務表現仍取決於負載。
  • 判斷：這是 2.2 的首篇英文系統性轉述，口徑與國內稿一致，實質新增只有 19.87% 這條時延數字與 KernelGen 的季度產出量。對海外讀者的意義大於對社群的資訊增量：它把 2.2 從中文技術圈的一次釋出會，轉成可被外部引用的英文材料。此前 10-20 的報道已把 2.2 的收益拆成可複核案例，本條不再重複數字對照。

2.2 跨維智慧入選眾智 FlagOS 加速計劃擬立項：FlagOS-Robo 與 AlohaMini 端側示範（10-22）

日期：2026-10-22　來源：具身之家報道 · FlagOS-Robo 文件入口

  • 立項事實：9 月，北京市科學技術委員會、中關村科技園區管理委員會發布 2026 年度「中央引導地方」及「新一代資訊通訊技術創新」專項眾智 FlagOS 加速計劃方向擬立項課題公示通知；跨維智慧旗下跨維智心（北京）機器人科技有限公司申報的《基於 FlagOS-Robo 的 AlohaMini 具身智慧機器人端側部署與應用示範》入選公示名單。
  • 專案內容：面向具身智慧機器人開源演算法復現、真實本體部署、國產 AI 晶片端側適配與場景應用驗證，依託 AlohaMini 開源機器人與 FlagOS-Robo 工具鏈，做模型訓練適配、多晶片推理部署、快慢系統一體化執行與多場景示範，目標是形成可復現、可部署、可評測、可推廣的開源方案。
  • 驗收點：模型側做具身模型訓練適配與推理部署，推進國產 AI 晶片在機器人端側應用，並以多晶片推理精度一致性測試驗證跨晶片表現；系統側推動具身模型、運控小腦與本體控制協同，銜接理解、規劃與執行；場景側構建多場景實體評測體系。
  • 前情：跨維智慧在 2.2 的生態口徑裡已是新增夥伴之一，也在 10-13 預告的具身智慧分論壇名單中出現。本條的不同在於它是「政府專項—開源工具鏈—開源本體—評測體系」四件套的立項，而非一次論壇亮相。
  • 判斷：加速計劃把 FlagOS-Robo 與國產晶片端側放進同一份任務書，等於給具身智慧方向設了一個外部驗收方。對社群而言這是第三個帶交付物約束的外部專案（前兩個是 FEP 矩陣與賽事），值得跟蹤後續是否有公開的晶片型號與精度一致性結果。

2.3 渠道核查：17 條候選 2 條有效，CSDN 新增高校圓桌直播，智源社群僅得框架頁（10-22）

日期：2026-10-22　來源：Google News RSS · CSDN FlagOS 專欄 · HN Algolia

  • 查詢面：24 組中英文查詢詞，元件名（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen）取 14 天，成員與產業詞（智源研究院開源、智源研究院晶片、國產算力開源軟體棧、燧原、沐曦、摩爾執行緒、清微、海光等）取 7 天，視窗內共命中 17 條。
  • 有效兩條：Pandaily 的 2.2 英文轉述與具身之家的 FlagOS-Robo 立項稿（見 2.1、2.2）。其餘 15 條為行情、融資與人才稿，包括燧原與清微的個股頁與科創先鋒案例、輝羲智慧融資、摩爾執行緒「跌破發行價」與國產算力業績稿、智源社群轉載的黃仁勳算力叢集稿，無一條涉及元件、版本或晶片適配。
  • 渠道核查：HN Algolia 八組查詢中 FlagOS 命中 4 條、FlagGems 2 條，標題均無直接匹配；CSDN 專欄首頁 51 條連結，最新原創稿仍是 08-28 的 GLM-5.3-Flash Day0 適配稿，但新增一條 10-22 19:00 的高校圓桌直播（「共築開放 AI 教育生態」，10-22 14:24 建立），內容為 FlagOS 全球 AI 開放計算師資發展計劃下多國高校教師的教學落地，屬社群活動而非技術釋出；智源社群搜尋頁為客戶端渲染，僅得框架頁。
  • 缺口說明：本視窗的新聞側由兩條外部稿支撐，其中一條是舊釋出的英文轉述，因此「技術口徑」仍全部來自 GitHub。按採集紀律，這已滿足「不靠新聞側判斷平靜」的要求，但不宜據此認為對外傳播節奏在加快。

三、成員單位與後端廠商深挖

3.1 海光：兩個推理外掛倉同日完成上游版本對齊（10-22）

日期：2026-10-22　來源：vllm-plugin-FL PR #576 · sglang-plugin-FL PR #138 · FlagGems PR #7460 · FlagDNN 提交

  • 雙棧：vLLM 0.28.0 與 SGLang 0.5.18 同日合入，合計 84 檔案、淨增約 5,700 行，是本日程式碼量最大的廠商側投入。兩筆均由 physics31415926 提交，驗證環境同為一卡 64 GiB 的 BW1000 叢集。
  • vLLM 側要點：發行包為 0.28.0+empty，走 ModelRunnerFL 且關閉 V2 model runner；圖模式覆蓋 eager 與 FULL_AND_PIECEWISE；外掛 wheel 由 CI 按 PR merge ref 重建替換映象內舊件。
  • SGLang 側要點：除單機 TP2 外，跑了物理兩節點的 TP4/PP1 與 TP2/PP2，並修流水並行協同退出；FlagGems 5.4.0.dev0 與 FlagCX 0.13.0 為基線，未引入獨立 Triton。
  • 其餘：FlagGems #7460 修海光 FP8 稀疏求和反向的輸入韌體；FlagDNN 一筆「fix for hygon」；build-infra #1459 刪掉過時的廠商字首 hygon 輪子行（說明打包已收斂到統一命名）。
  • 判斷：海光是當期唯一在兩個推理外掛倉同時完成上游版本對齊的廠商，工作量集中在「版本矩陣 + 圖模式 + 多機並行」，而非運算元數量。它的可複用價值在於把 empty 後端的升級流程寫成帶版本表的模板，其餘廠商照此推進即可。

3.2 崑崙芯：13 筆運算元最佳化，疊加 FlagTree 第七後端（10-22）

日期：2026-10-22　來源：FlagGems PR #7107 · FlagGems PR #7462 · build-infra PR #1468 · Torch-FL PR #634

  • 合入量：標題含崑崙芯或 XPU 的合入全組織 13 筆（FlagGems 10、Torch-FL 2、build-infra 1），為廠商中最多的運算元側產出，其中 lvxu2020 一人 6 筆且全部指向 XPU 核心。
  • 運算元最佳化：#7463 最佳化 elu、special_i1e、foreach_erf 與 foreach_zero；#7462 最佳化 tile、dot、index_put；#7452 用融合核心最佳化 isfinite；#7470 增加 kl_div 的 XPU 覆寫並再最佳化 isfinite；#7351 給 less_equal 張量比較加自適應 tile 快路徑；#7406 展開 te_rmsnorm_fwd 未掩碼行核心的列迴圈；#7390 最佳化 isneginf、nan_to_num_ 與 log_sigmoid_backward；#7466 透過放大調優配置的 tile 修 baddbmm 啟動超時。
  • 融合 MoE：#7107 三運算元聚合分 1.324 至 1.329，同時主動宣告基線為替代實現、dispatch_fused_moe_kernel 0.626 不達標（見 1.5）。
  • 構建與執行時：#1468 讓崑崙芯成為 FlagTree 第七後端（五個獨有約束見 1.7）；Torch-FL #634 把跨卡複製改走 xpu_memcpy_peer、#632 修預載入順序。
  • 判斷：崑崙芯當日的動作跨運算元、構建、執行時三層，是唯一在三條線上同時有結構性改動的廠商。真正的風險點也在運算元側：多數改動是「同一運算元的另一種 tile 或融合」，缺少統一的效能門禁，聚合分口徑又因基線替代而不可跨廠商比較。

3.3 清微：裝置時間線進入 torch.profiler，TX8110 實測（10-22）

日期：2026-10-22　來源：Torch-FL PR #630 · build-infra PR #1459

  • 能力補齊：清微（TX8）此前完全沒有裝置側剖析——PrivateUse1 無剖析器註冊，kernel 事件與裝置時間全為空。本 PR 用 rocprofiler-sdk 實現 DeviceTracer 與獨立剖析庫，把 NPU kernel 關聯回 aten op 並以 CUDA 佈局呈現，TX8110 上實測透過；同時給清微釘 FLAGOS_BUILD_VENDOR=ON（廠商目錄含隨機數核心），並把安裝指南與相容矩陣從「僅執行時」更新為含剖析。
  • 影響面自述：flagos_kineto_profiler.cc 的改動影響所有後端的執行時切片位置與裝置行命名，但只在清微硬體上覆驗——這是 PR 自己寫明的剩餘風險。
  • 其餘：FlagGems 側未見清微專屬合入；build-infra 的 flagcx 0.14.0 統一 pin 讓清微後端也拿到顯式通訊依賴。
  • 判斷：清微近三日連續補的是「構建、隨機數、剖析」三塊基礎設施短板，而非運算元覆蓋。這種順序對後來者最有參考價值：先能在 CI 裡構建、再能復現隨機性、再能看效能，最後才談最佳化。

3.4 摩爾執行緒與燧原：MUSA 快取持久化、GEMM 與燧原整批更新（10-22）

日期：2026-10-22　來源：FlagTree PR #1385 · FlagBLAS PR #152 · FlagGems PR #7077 · FlagTree PR #1424

  • 摩爾執行緒：FlagTree #1385 為 MUSA 增加逐複製的 TME 快取持久化，屬編譯側對張量記憶體引擎的增量；FlagBLAS #152 增加 GEMM 實現；FlagGems 側 5 筆標題相關合入集中在 MUSA 的測試跳過與輸入域限定（#7502 至 #7504），說明該後端的失敗面仍以「輸入不支援」為主而非實現錯誤。
  • 燧原：FlagGems #7077 把廠商 10-13 的整批更新（26 檔案、+3520/−511）一次進主幹，是本日單筆最大的廠商側變更；FlagTree #1424 因偶發匯流排錯誤在 CI 停用 02-sparse-mla 用例、#1427 更新 vllm benchmark 引數。兩筆 CI 調整合計說明燧原側的穩定性問題仍在用例層而非產品層。
  • 判斷：兩家當日的產出性質不同——摩爾執行緒在補快取與線性代數這類「可複用能力」，燧原在交付整批更新並處理 CI 噪音。前者可累積，後者需要一次可核對的明細，否則「整批更新」在後續報告中只能記作黑盒。

3.5 昇騰、天數、沐曦與其他：按後端分流的小步，地平線與寒武紀靜默（10-22）

日期：2026-10-22　來源：FlagGems-vllm PR #936 · FlagBLAS PR #153 · FlagGems-vllm PR #977 · FlagGems-vllm PR #777

  • 昇騰：FlagGems-vllm #936 讓昇騰的分塊門控增量規則前向（chunk gated delta rule）改用 tle.dsa 的切片與同步介面；FlagGems 內 7 筆標題含昇騰或 NPU 的改動多為測試跳過與用例同步；TransformerEngine-FL 同日新開三筆 NPU 相關 PR（#144 get_num_cublas_streams、#145 cuDNN 版本能力查詢、#146 bshd/thd 佈局），尚未合入。
  • 天數：FlagBLAS #153 最佳化 L1 層運算元；FlagCX #670 的 Iluvatar CoreX 單測流水線與映象仍在審；sglang-plugin-FL #139 的 0.5.18 empty 執行時適配仍在審（10-15 建立）。
  • 沐曦：FlagGems-vllm #977 補 TP=2 配置（平均 1.065 倍，見 1.10）；FlagGems #7454 的 MetaX 修正在審；build-infra 的 flagcx 統一 pin 覆蓋沐曦後端。
  • 海光之外的 DCU 與 PPU 側：Torch-FL #629 給 cuda/dcu/metax/ppu 四類後端補 convolution_overrideable 例外，屬同一處修復的批次覆蓋。
  • 地平線與寒武紀：當日組織內未見兩家專屬倉庫的推送與合入，連續第二日靜默。
  • 判斷：除海光與崑崙芯外，其餘五家當日都是「一條路徑或一個運算元」的推進，沒有結構性變更。地平線與寒武紀的連續靜默是本期唯一值得提出的缺口——若下週仍無動作，應在週報中作為風險項列出。

四、總結與趨勢觀察

  • 產能結構：FlagGems 一家吃掉 56% 合入，量子棧吃掉 40% 提交，構建與執行時各一成。合入量創近一週新高而提交量下降，說明當日的主旋律是消化積壓而非擴張，這與 10-20、10-21 連續兩日大額合入之後的狀態一致。
  • 2.3 週期的第一格：FEP-0140 與 FEP-0141 在 10-21 合入，10-22 海光就把 vLLM 0.28.0 與 SGLang 0.5.18 兩個版本同時落地。這條鏈路從「把矩陣寫進文件」到「第一條實測透過」只用了一天，是本季最快的需求到證據閉環。剩下的九家與兩條版本線是此後六週的主工作量。
  • 構建層收斂：崑崙芯成為 FlagTree 第七後端、flagcx 0.14.0 釘到二十個後端、optest 變成可安裝包。三者合起來的效果是「換後端時不再改安裝指令碼」，這比任何單點效能提升都更能決定 2.3 的交付速度。
  • 可觀測性成為新短板：清微第一次有裝置時間線，崑崙芯跨卡複製此前一直靜默失敗。這兩件事提示，多後端在「能跑」之後的第一道坎是可觀測與可復現，而不是更快；過去兩週的測試移植與用例契約改造（lukatao 一人 61 筆）正是同一判斷的另一種表達。
  • 風險點一：FlagQuantum 的 20 筆合入全部由單一賬號完成，且新增的原生 Rydberg 路徑只覆蓋 CPU、一至兩個角色。物理語義的驗證依賴同一批人寫測試與實現，外部無法獨立複核；提案 083（終端取樣）尚未批准，若快速推進，會同時改動 Runtime、測量結果與隨機源三處。
  • 風險點二：燧原 #7077 這類「整批更新」缺少可核對明細，26 檔案與 +3520 行無法對應到具體運算元與具體收益；崑崙芯融合 MoE 的三項效能又以替代基線測出。兩者都會讓後續的跨廠商對比失真。
  • 觀察點：vLLM 0.28 的下一個廠商（清微或沐曦）是否複用海光的 empty 後端模板；FlagTree 0.7.1 開發構建（10-20 的 0.7.1.dev1）是否在 2.3 前轉正式版；TransformerEngine-FL 的三筆 NPU PR 能否在週末前合入；地平線與寒武紀的靜默是否延續到下週週報。

附錄：信源核查表與完整信源清單

信源核查表

信源 核查結果
組織倉庫 API 61 倉全量核查，16 倉視窗內有推送
提交檢索 135 筆命中，12 倉分佈，FlagQuantum 與 FlagGems 合計 82 筆
合併 PR 檢索 163 筆視窗內合入，分 13 倉
在審 PR 檢索 183 筆視窗內有更新，其中新開 90 筆
Release 與構建標籤 31 倉逐一核查，視窗內無新版本；最近為 10-20 的 FlagTree 開發構建
org 事件流 100 條，其中 PR 事件 43、推送 27、刪分支 12、建分支 9、評論 4、評審 3、關注 2
分支級兜底 docs、release-info、sglang-plugin-FL、vllm-plugin-FL 四倉為非預設分支推送，主分支無新提交
Google News RSS 24 組中英文查詢，17 條候選，2 條有效
HN Algolia 8 組查詢，FlagOS 4 條、FlagGems 2 條，均無標題直接匹配
CSDN FlagOS 專欄 首頁 51 條連結，最新原創稿為 08-28；新增 10-22 19:00 高校圓桌直播
智源社群 搜尋頁為客戶端渲染，僅得框架頁
英文媒體 Pandaily 一篇 2.2 系統轉述，口徑與國內一致，新增 19.87% 時延數字
國內媒體 具身之家一篇 FlagOS-Robo 立項稿，原始來源為跨維智慧

完整信源清單

flagos-ai/FlagGems/pull/7424>

/pull/977>