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

信源：GitHub（org: flagos-ai 61 倉庫全量核查、提交檢索 189 筆、合併 PR 183 筆與在審 PR 253 筆檢索、org 事件流 100 條、31 倉 Release/Tag 原子核查、5 倉原子補核與分支核對、關鍵 PR 正文與產物規模核查）、Google News RSS（24 組中英文查詢詞，走代理）、HN Algolia（8 組）、CSDN FlagOS 專欄（文章與直播條目逐頁核時）、智源社群、八家成員單位官網（詳見附錄信源清單）。

本期索引

  • 今日重點：海光 DTK 26.10 三線接入（容器、編譯、通訊）；MiniCPM-OCR 雙模型 Day0 覆蓋 12 平臺；測試基建 ref-as-candidate 雙倉落地（10-29）
  • 一、開源專案進展（GitHub 動態）
    • 1.1 組織節奏：21 倉推送、189 筆提交、183 筆合入，在審 253 筆（10-29 ~ 10-30）
    • 1.2 版本面：FlagTree 打出清微 3.6 專號，FlagCX v0.14.1 由標籤轉 wheel 線（10-29）
    • 1.3 FlagGems：KernelGen 單日合入 22 個運算元，崑崙芯 XPU3 foreach 融合收官（10-29）
    • 1.4 測試基建：ref-as-candidate 雙倉落地，單日 57 筆測試 PR 收口（10-29）
    • 1.5 推理與訓練棧：GLM-5.3-Flash 與 Qwen3.8-Flash 雙模型進外掛（10-29）
    • 1.6 編譯與通訊：摩爾執行緒常駐 GEMM 與 SPMC 進主線，FlagCX 補兩家裝置介面（10-29）
    • 1.7 構建與釋出：海光 DTK 26.10 八筆合入、昇騰 rpm 目標與 2.3.0 映象描述（10-29）
    • 1.8 量子線：FlagQuantum 六十筆提交，CS-01 至 CS-07 合成流水線貫通（10-29）
    • 1.9 其餘倉庫：OpenCourse 教材重組，FlagScale 與 TransformerEngine-FL 收斂 CI（10-29）
  • 二、新聞報道與生態
    • 2.1 MiniCPM-OCR 雙模型 Day0 適配 12 平臺，達摩院玄鐵吞吐達原生 98.7%（10-29）
    • 2.2 CSDN 技術直播：一個外掛打通十款晶片的推理適配（10-29）
    • 2.3 渠道核查：HN 與智源社群無新命中，CSDN 專欄新增一稿一直播（10-29）
  • 三、成員單位與後端廠商深挖
    • 3.1 海光：DTK 26.10 從容器到 wheel 的全鏈落地（10-29）
    • 3.2 清微：Triton 3.6 後端同步合入並打出專用標籤（10-29）
    • 3.3 崑崙芯：XPU3 的 foreach 融合鏈與常量網格收尾（10-29）
    • 3.4 沐曦：分組 GEMM 的 INT8 與 FP8 路徑、TP2 解碼排程（10-29）
    • 3.5 摩爾執行緒：TLE 常駐 GEMM 與 SPMC 同步進主線（10-29）
    • 3.6 燧原、昇騰、達摩院玄鐵：注意力與歸一化運算元的四條線（10-29）
    • 3.7 天數：天垓 300 首次實機演示對外，單卡吞吐宣稱 1.05 倍 H200（10-28）
  • 四、總結與趨勢觀察
  • 附錄：信源核查表與完整信源清單

今日重點：海光 DTK 26.10 三線接入（容器、編譯、通訊）；MiniCPM-OCR 雙模型 Day0 覆蓋 12 平臺；測試基建 ref-as-candidate 雙倉落地（10-29）

日期：2026-10-29　來源：build-infra PR #1554 · build-infra PR #1562 · build-infra PR #1563 · MiniCPM-OCR Day0 適配 · FlagGems PR #7630 · FlagGems-sglang PR #249（全量見附錄）

  • 構建面：海光 DTK 26.10 在單日內走完八筆合入——基礎容器（#1554，加 78 行）、執行時配置（#1555，加 21 行）、可用性修復（#1558，為 /opt/dtk 指向 dtk-26.10 並補 runner 覆蓋）、FlagTree 的 cp312 hcu 構建器（#1562，4 檔案加 342 行）、FlagCX 的 dtk2610 wheel 線（#1563，3 檔案加 185 行）、基礎映象補 libopenmpi3t64（#1564）、構建器補 libopenmpi3（#1565）、把 hcu-dtk2610 加進 FlagTree wheel 釋出線（#1566）。這是本棧首次為新一版廠商 SDK 同時改容器、編譯器構建器與通訊庫打包三條線，原因是 DTK 26.10 把執行時釘在 python 3.12 與 torch==2.13.0+dtk2610（僅 cp312），既有 cp310 的 hcu wheel 在該執行時里根本解析不到。
  • 新聞面：眾智 FlagOS 社群為面壁智慧與 OpenBMB 開源的 MiniCPM-OCR 1.0（1.3B）與 MiniCPM-OCR Jev（2B）做 Day0 跨芯適配，覆蓋達摩院玄鐵、英偉達、華為昇騰、海光、崑崙芯、沐曦、摩爾執行緒、清微智慧、天數智芯、曦望、Mac（ARM）與此芯科技共 12 個平臺。評測給出的口徑是歸一化到硬體峰值算力後的吞吐：Jev 在達摩院玄鐵上的實際計算吞吐達英偉達原生的 98.7%，OCR 1.0 的單位峰值算力 P50 吞吐在單文件場景達英偉達原生的 169.3%、批次場景 137.1%。
  • 測試面：FlagGems 的 --ref-as-candidate 與顯式 get_candidate 選擇進主線（#7630，9 檔案），FlagGems-sglang 同日以 #239 至 #249 十一筆把全部正確性套件改到 get_candidate，並加入每日 master 到 kernelgen-dev 的自動同步 PR。兩倉合起來的效果是：參考實現可以不帶外部候選檔案直接充當候選跑通，測試不再是「有沒有運算元」的開關，而是「參考與實現是否一致」的比較。
  • 判斷：三條線指向同一件事——軟體棧的瓶頸正從「把運算元寫出來」轉到「把新 SDK 的構建假設、把參考實現的執行路徑、把模型的跨芯可比性」這三類工程紀律固定下來。DTK 26.10 的八筆合入說明硬體代際切換的成本幾乎全部落在打包與依賴解析上，而不是核心本身；MiniCPM-OCR 的評測則第一次給出歸一化吞吐與端側時延兩組可比數字。

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

1.1 組織節奏：21 倉推送、189 筆提交、183 筆合入，在審 253 筆（10-29 ~ 10-30）

日期：2026-10-29 ~ 2026-10-30　來源：flagos-ai 組織倉庫 · 提交檢索 · 合併 PR 檢索 · 在審 PR 檢索

  • 倉庫面：61 倉中 21 倉視窗內有推送（上一期 23 倉）。按推送時間從近到遠為 FlagGems、Torch-FL、FlagGems-sglang、FlagQuantum、vllm-plugin-FL、FlagQAI、FlagTree、FlagScale、OpenCourse、build-infra、FlagCX、FlagGems-vllm、FlagSparse、release-info、docs、optest、FlagTrain、FlagOps、FlagFFT、FlagAttention、TransformerEngine-FL。
  • 提交面：提交檢索命中 189 筆，為近兩週最高（上一期 99 筆），分倉為 FlagQuantum 60、FlagGems 43、build-infra 15、FlagGems-sglang 14、FlagQAI 11、FlagGems-vllm 9、FlagAttention 8、Torch-FL 6、FlagTree 5、FlagTrain 4，vllm-plugin-FL、FlagCX、OpenCourse 各 3，optest、FlagOps 各 2，FlagScale 1。FlagQuantum 與 FlagGems 兩倉佔去 103 筆。
  • 合入面：合併 PR 183 筆（上一期 67 筆，增 1.7 倍），分倉為 FlagGems 92、build-infra 16、FlagQuantum 15、FlagGems-sglang 11、FlagGems-vllm 9、FlagAttention 8、Torch-FL 6、FlagTree 5、vllm-plugin-FL 4、FlagQAI 4、FlagCX 4、FlagTrain 4、optest 2，FlagScale、FlagOps、TransformerEngine-FL 各 1。
  • 在審面：視窗內有更新的在審 PR 253 筆（上一期 288 筆），新開 84 筆（上一期 101 筆）。FlagGems 129、FlagTree 22、FlagGems-vllm 15、vllm-plugin-FL 10、Megatron-LM-FL 10、FlagTrain 9、FlagAttention 8、FlagScale 7、sglang-plugin-FL 6、Torch-FL 5、FlagGems-sglang 5、flir 5、FlagCX 4、docs 4，其餘各倉 1 至 2 筆。
  • 節奏對比：與上一 24 小時視窗（23 倉、99 筆提交、67 筆合入、288 筆在審）相比，推送倉減 2 個、提交增 91%、合入增 173%、在審降 12%、新開降 17%。合入量的跳變主要來自 FlagGems 的運算元上量（92 筆）與 FlagQuantum 的合成流水線（15 筆），不是評審口徑放鬆——同期在審總量仍在下降。
  • 版本與事件面：31 倉 Release 與 Tag 原子核查，視窗內新增標籤一個（FlagTree 的清微 3.6 專號，10-29 11:09）；FlagCX v0.14.1 的檔案時間前移到 10-29 10:55，與 #683 回摘到 0.14.0-rc2 的合入時間同刻。org 事件流 100 條：PR 評審評論 34、PR 事件 34、推送 13、建分支 8、議題評論 9、刪除分支 1、fork 1，構成比上一期（推送 51、建分支 32）明顯轉向評審活動，與合入量的上升一致。
  • 分支面：提交檢索未覆蓋的 5 個推送倉經原子補核——TransformerEngine-FL 有視窗內提交一筆（#142 的 FlagCICD v1，10-29 09:51）；FlagFFT 的推送落在 codex/musa-shortfall 特性分支（10-28 多次推送，預設分支最新提交仍在 10-15）；release-info 的推送在 gh-pages 分支（釋出站點自動釋出）；docs 與 FlagSparse 屬 PR 分支與議題評論活動，預設分支無新提交。

1.2 版本面：FlagTree 打出清微 3.6 專號，FlagCX v0.14.1 由標籤轉 wheel 線（10-29）

日期：2026-10-29　來源：FlagTree 清微 3.6 專號標籤 · FlagTree PR #1459 · build-infra PR #1553 · build-infra PR #1556 · build-infra PR #1563

  • FlagTree 標籤：10-29 11:09 打出清微 3.6 專號，與 10-26 的摩爾執行緒 3.6 專號屬同一條「按廠商切分的 3.6 預釋出線」。該標籤在 Releases API 無釋出正文（返回 404），說明它是標籤檔案而非帶說明的 Release；同日合入的 #1459 正是清微後端向內部 Triton 3.6 開發線同步的那一筆。
  • FlagCX 交付面：v0.14.1 在上一視窗以 git 標籤形式出現（無 Release 正文），本視窗被正式登記進 build-infra 的 wheel 目錄——機器人記錄釋出（#1553），人工補齊五條空殼描述並加入 flagcx==0.14.1+rocm7.2.4 這一 AMD 行（#1556，10 檔案加 28 行減 16 行），再把 hygon-dtk26.10 這條線釘到 flagcx==0.14.1+dtk2610（#1563）。至此 0.14.1 的交付面覆蓋 cuda12.8、cuda13.3、corex4.4.0、corex4.5.0、xre5.37.1、rocm7.2.4 與新增的 dtk2610。
  • Issue 驅動的修復：FlagTree #1481 針對議題 #1473 修 Metax 上 CompiledKernel 的後設資料檢查（1 檔案，加 2 行減 1 行）；FlagGems #7989 修昇騰 cat 運算元（加 57 行減 36 行）；FlagTree #1468 與 #1470 為燧原補 CI 與 TLE 單測。
  • 待觀：FlagTree 的 3.6 線以「每廠商一個標籤」的方式推進，0.7.1a1 尚無統一發布說明；若 2.3 週期按此線交付，下游需要從標籤名反推後端與 Triton 版本，和 FlagCX v0.14.1 缺正文是同一類問題。

1.3 FlagGems：KernelGen 單日合入 22 個運算元，崑崙芯 XPU3 foreach 融合收官（10-29）

日期：2026-10-29　來源：FlagGems PR 列表 · PR #7116 · PR #6950 · PR #6530 · PR #7989

  • KernelGen 面：92 筆合入中有 22 筆為 [KernelGen][Nvidia] 自動生成運算元，覆蓋稀疏張量（sparse_csc_tensor_unsafe、sparse_bsc_tensor_unsafe、sparse_resize_）、卷積與池化（nnpack_spatial_convolution、thnn_conv2d、fractional_max_pool3d_backward、mkldnn_reorder_conv2d_weight）、線性代數（cholesky、frobenius_norm、chain_matmul）與一批邊角運算元（argwhere、_indices、make_dual_copy、flatten_dense_tensors、combinations、empty_per_channel_affine_quantized）。單日批次是該線近期最密的一次，同日又新開 #8009 至 #8013 五筆，佇列仍在延續。
  • 崑崙芯面：XPU3 的 foreach 融合鏈在一天內收口——cos/exp/sin/addcdiv/lerp 的 List 執行器（#7116）、ceil 的無掩碼融合核心（#7604）、tanh/expm1 的原地融合核心（#7608）；隨後是四筆正確性修復：fmin 改常量發射網格（#7966）、t_copy 一維路徑同樣改常量網格（#7973）、foreach 標量 dtype 分支改為互斥（#7974）、foreach add 的列表槽位改由 program_id(0) 取（#7968）。euclidean_dist、is_same_size、layer_norm_backward 也做了 XPU 最佳化（#7907）。
  • 沐曦面：新增 INT8 與 FP8 的 grouped_mm_w8a8（#6950，7 檔案加 1220 行）。基準用 GLM-5.2 在 PPU SGLang TP=8 上採集的真實呼叫形態回放到 MetaX C550——28 條場景記錄、26 組唯一 (M,N,K,E) 幾何、324 萬次呼叫、257 個專家。
  • 其餘：AMD W7900（gfx1100）的運算元精度修復（#6530）；昇騰 log_ 網格填充重跑的廠商本地實現回摘到 5.4.0-rc2（#6586）；CI 側修匯入順序（#7951）、釋出構建從被移除的 cp38 換到 cp310（#7975）、廠商名改為隨執行時版本（#7961）、FP8 MM 測試改為按已註冊後端跳過（#7812）。
  • 判斷：運算元上量已由 KernelGen 承擔，人工投入集中在兩類事上——新後端的發射引數正確性（崑崙芯四筆）與測試可執行性（見 1.4）。這解釋了為什麼 92 筆合入裡幾乎沒有主幹語義變更。

1.4 測試基建：ref-as-candidate 雙倉落地，單日 57 筆測試 PR 收口（10-29）

日期：2026-10-29　來源：FlagGems PR #7630 · FlagGems-sglang PR #239 · FlagGems-sglang PR #241 · FlagGems-sglang PR #249 · FlagGems-sglang PR #242

  • 機制：--ref-as-candidate 讓正確性測試與基準可以把顯式宣告的參考實現當作候選來跑（get_candidate("negative", reference=torch.negative)），不再依賴外部候選檔案。缺參考、參考不可呼叫、測試體未實際呼叫候選都會顯式失敗；跳過與 xfail 不能掩蓋契約錯誤，全跳過不計為有效執行。驗證為 26 項宿主迴歸加 32 項針對 master 與 PR 合併預覽的檢查。
  • 落地範圍：FlagGems-sglang 同日 11 筆把全部正確性套件改到 get_candidate（#241）、補齊參考宣告（#240、#244）、加基準用例列舉與回放（#239）、加 definitions 目錄與 silu_and_mul 示例（#245）、補 mrotary_embedding 候選比較與可移植參考及跨裝置原生校驗（#247、#249）。
  • 規模：單日 57 筆由同一作者提交的測試修復合入（多為各後端的引用契約、夾具與基準入口修正），覆蓋昇騰、沐曦（MUSA）、燧原、崑崙芯與英偉達的跳過條件與參考 ABI。
  • 自動化：新增每日 master 到 kernelgen-dev 的自動同步 PR（#242），當日機器人已產生兩筆同步（#243、#246）。這條鏈把「上游主幹」與「KernelGen 開發線」的漂移從人工 rebase 變成每日一次可審計的合併。
  • 判斷：測試從「跑得過」轉向「可比」之後，測試本身開始需要參考實現的契約；這也是本日 57 筆修復的真實內容——不是補測試，而是補參考。

1.5 推理與訓練棧：GLM-5.3-Flash 與 Qwen3.8-Flash 雙模型進外掛（10-29）

日期：2026-10-29 ~ 2026-10-30　來源：vllm-plugin-FL PR #455 · vllm-plugin-FL PR #454 · vllm-plugin-FL PR #615 · FlagTrain PR #35 · FlagGems-vllm PR #1025

  • Qwen3.8-Flash：vllm-plugin-FL 加 Qwen3.8-Flash-Next 與 Qwen4 的檢查點載入與模型整合（#455，65 檔案加 11226 行減 109 行），含 HC、PLE、QSA 與多模態接線，數值運算元走 FlagGems-vllm。FP8 採用能力門控：平臺原生支援則保留原生核心（英偉達要求計算能力 8.9 以上，AMD 交給 vLLM 的 ROCm 實現判斷），不支援時回落到 BF16 線性與 MoE 路徑並強制 --dtype bfloat16。
  • GLM-5.3-Flash：次日凌晨合入純公開運算元的實現（#454，90 檔案加 19140 行減 280 行）。索引器精度先於快取分配選定：英偉達 SM89 以上、摩爾執行緒 MP31 以上與 GCU capability 4 以上保留 FP8，其餘廠商與未知能力用 BF16；BF16 的沐曦與崑崙芯因對應 radix 編譯路徑無法降級，改走既有 Torch TopK、scatter 與 sort 路徑。
  • 執行面：原生 CUDA 的 vLLM 0.32 適配（#615，57 檔案加 3408 行減 1044 行）把棧釘在 vLLM 0.32.0+cu129、PyTorch 2.13.0+cu129、CUDA 12.9 與 python 3.12.3 上，FlagGems 用 5.4.0 開發提交、FlagTree 用 0.7.0 開發提交（提供 Triton 3.6）；現有 NVIDIA CI 6 項推理與 3 項服務全過。
  • 訓練面：FlagTrain 加 multi_tensor_adam（#35，6 檔案加 1093 行），一次 Triton 發射批次完成多張量 Adam 更新，後端覆蓋英偉達、海光、沐曦、PPU（達摩院玄鐵）與天數；同視窗另有 fused_proj_rms 前反向（#38）、fast_gelu（#33）與 deepspeed 依賴（#42）。原始 H20 基準裡，fp32 65536 元素檔位相對 DeepSpeed CUDA 基線為 2.24 倍，1024 元素小檔位反而慢到 0.76 倍。
  • 推理最佳化：FlagGems-vllm 側，沐曦 TP2 packed decode 的 Split-KV 排程與計算 tile 重排（#1025）；FP8 W8A16 的門控增量網路加動態狀態量化（#988）；MUSA 的 FP8 變長注意力按當前 CI 編譯器重調（#970）；fused_q_kv_rmsnorm 同時在昇騰（#872）與達摩院玄鐵（#888）落地。

1.6 編譯與通訊：摩爾執行緒常駐 GEMM 與 SPMC 進主線，FlagCX 補兩家裝置介面（10-29）

日期：2026-10-29　來源：FlagTree PR #1294 · FlagTree PR #1459 · FlagCX PR #678 · FlagCX PR #681 · FlagCX PR #679

  • 摩爾執行緒：[MThreads][TLE] 的常駐 GEMM 流水線與 SPMC 同步進主線（#1294，63 檔案加 6192 行減 403 行）。該筆不是搬舊檔案，而是基於當前 main 的 pipe、warp specialize 與 SQMMA 表示重遷，並把原先分兩套的編譯器（公共版供 addmm/baddbmm，SPMC 版供 bmm）合成一套超集：支援動態迴圈裡的 stage 與 phase 推進、一生產者對多消費者、命名讀與隱式讀、分段完成與消費者紀元推導，以及單發、融合消費者與 16 warp 常駐路徑。
  • 清微：後端同步到內部 Triton 3.6 開發線（#1459，27 檔案加 2264 行減 407 行），只改 third_party/tsingmicro/——補回 FlagGems 側的廠商運算元分發所需的逐發射精度介面、外部 CoreIR 入口與執行時介面卡，並修 Tx81 程式碼生成與 DMA、RDMA、WDMA 的 CRT 缺陷。
  • 崑崙芯：FlagCX 增加 XPU 的裝置 IR 入口以支援 FlagTree 連結（#678，5 檔案加 178 行減 21 行）。
  • 天數：FlagCX 的 Device API 後端補上 Atomic::load 的獲取語義（#681，3 檔案加 359 行減 37 行）。此前 load(..., Acquire) 與 load(..., Relaxed) 發射同一條指令，觀察者在看到標誌後沒有失效屏障；本筆改為先讀後柵欄、按作用域選強度，並補上 launchKernel 的地址空間符號與 getLastError 槽位。系統作用域仍未實現，因為 ivcore11 沒有對應的記憶體屏障指令。
  • AMD：ROCm 上把 SGLang 的張量並行跑通（#679，6 檔案加 77 行減 19 行）——補 eventElapsedTime 實現、把 torch.bool 對映到 flagcxUint8、加 USE_AMD 測試構建分支；R9700 雙卡上 AllReduce、ReduceScatter、AllGather、Broadcast、Send/Recv 與圖捕獲的 AllReduce 結果正確，Qwen3.5-9B 與 Qwen3.6-35B-A3B-FP8 在 TP=2 下可服務。

1.7 構建與釋出：海光 DTK 26.10 八筆合入、昇騰 rpm 目標與 2.3.0 映象描述（10-29）

日期：2026-10-29　來源：build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1565 · build-infra PR #1566 · build-infra PR #1557 · build-infra PR #1560

  • DTK 26.10 全鏈：八筆合入的先後順序本身就是一條排障鏈。首版容器與配置落地後（#1554、#1555），映象仍不可構建也不可排程：#1558 指出 base/hygon-dtk26.10 仍把 /opt/dtk 指向 dtk-26.04，且 .github/build-config.yml 沒有該條目的 runner 覆蓋會落回 h20 預設值。隨後 torch 2.13.0+dtk2610 的 libtorch_global_deps.so 直接鏈 libmpi.so.40 與 libibverbs.so.1，而 26.04 的 wheel 把這兩個 soname 雜湊進了包內，因此這條線需要基礎映象補 libopenmpi3t64（#1564）、構建器補 libopenmpi3（#1565）。
  • 版本線：同一執行時釘 python 3.12，導致既有 cp310 的 hcu wheel 無法解析；#1562 以 deadsnakes 3.12 重建 cp312 的 hcu 構建器並裝入 DTK 26.10 的 Ubuntu22.04 SDK，#1566 再把 hcu-dtk2610 加進 wheel 釋出線的目標選項，使 flagtree==0.7.0+hcu3.6 能以普通 flagtree 釋出到海光源。
  • 昇騰 rpm：新增 FlagTree 的昇騰 rpm 目標（#1557，加 44 行減 4 行），編譯物件是昇騰交付流水線產出的 cp311 與 aarch64 wheel，正好對應 openEuler 24.03 的 aarch64，因此只開一行；這也是首條不依賴廠商 SDK 與硬體的 rpm 線。
  • 2.3.0 跡象：執行時映象描述在 09:44 與 18:26 兩度重新整理（#1552、#1561），changelog 日期按 hygon-dtk26.10 記賬（#1560）。但 community 倉的 release/2.3/release-2.3.yaml 仍為 404，說明 2.3 的釋出清單尚未建立，當前進度停在構建面。
  • 釋出效率：另有 vllm 重打包依賴改走 PEP 503 頁面解析（#1543）與 actions/setup-python 由 7.0.0 升到 7.1.0（#1550）。

1.8 量子線：FlagQuantum 六十筆提交，CS-01 至 CS-07 合成流水線貫通（10-29）

日期：2026-10-29　來源：FlagQuantum 倉庫 · FlagQuantum PR #960 · FlagQuantum PR #964 · FlagQuantum PR #966 · FlagQuantum PR #967 · FlagQAI 倉庫

  • 規模：FlagQuantum 一日 60 筆提交、15 筆合入，全部集中在同一條線上——量子電路合成（CS 系列）。倉庫內 docs/roadmap/ 與 docs/api-changes/ 已按 FQ-SYNTH-CS01..CS07-20261029 歸檔十份規格與交付文件。
  • 流水線：CS-01 定義相干整數構造的語義邊界與驗證，CS-02 用純算術核心降低相干加法，CS-03 處理乘法與相干多項式，CS-04 打通受限 Python 工作流，CS-05 加生命週期與工作區排程，CS-06 分三段（執行契約、候選代價選擇、單使用者工作流）落地，CS-07 進入暫存器語義與程式准入。同日還加入可移植 .fqx 實驗檔案的存載（#960）與 fq.run 的受檢程式執行（#964）。
  • 在審：CS07-C 的受限原生 Qmod 前端（#967）在 17:30 開出，把只含一個輸出的無符號 main 翻譯到既有編譯器的暫存器與表示式模型，不執行文字、不生成 Python 可呼叫物件、不選後端。
  • 配套 FlagQAI：同源的 FlagQAI（10-10 建倉）一日 11 筆提交、4 筆合入，加入本地量子工作臺網頁與原生 Agent 整合（#3）、重新整理後保留跟隨偏好的修復（#4）。倉內 README 明確把「由意圖合成電路」列為產品方向而非已完成能力，當前驗證範圍只有本地電路模擬與一條固定擬設的兩位元變分路徑。
  • 判斷：這條線在本棧裡獨立度最高——不做多芯適配，只做「把科學問題翻譯成可執行電路」的中間層。它的價值在於給 2.x 週期提供一個與晶片無關的軟體棧用例。

1.9 其餘倉庫：OpenCourse 教材重組，FlagScale 與 TransformerEngine-FL 收斂 CI（10-29）

日期：2026-10-29　來源：OpenCourse 提交 · FlagScale PR #1315 · TransformerEngine-FL PR #142 · optest PR #18 · FlagOps PR #18

  • OpenCourse：三筆提交做課程資源重組（17:07、19:59）與師資發展版目錄改名（21:53），並加入實驗主線（lab mainline）。這與社群持續推進的全球師資發展計劃同一批次。
  • FlagScale：把測試策略、受影響路由與執行證據門統一到一套（#1315）。在審側可見新一輪訓練棧動作：DeepSeek-V4 向上遊同步的 [1/N]（#202）與 [2/N]（#211，為打包序列補連續上下文並行），以及 HF 與 MCore 的 DCP 輕量互轉（#1319）。
  • TransformerEngine-FL：實現 FlagCICD v1，引入 L0 至 L4 測試分級與計劃驅動執行（#142）。
  • optest 與 FlagOps：optest 修 CI 的目標引用與運算元測試診斷資訊（#18）、重寫 README（#17）；FlagOps 的穩健檢出清掉硬殺 fetch 留下的陳舊 git 鎖（#18）。

二、新聞報道與生態

2.1 MiniCPM-OCR 雙模型 Day0 適配 12 平臺，達摩院玄鐵吞吐達原生 98.7%（10-29）

日期：2026-10-29　來源：FlagOS Day0 適配 MiniCPM-OCR & Jev · FlagRelease 模型卡入口 · vllm-plugin-FL 文件 · Torch-FL 文件

  • 模型：面壁智慧聯合 OpenBMB 開源 MiniCPM-OCR 系列——1.3B 的 MiniCPM-OCR 1.0 面向掃描、拍照、彎曲、翻拍等真實文件場景，支援文字、公式、複雜表格解析與關鍵資訊抽取，官方評測在 Real5-OmniDocBench 得 93.68 分，引入 DSpark 解碼加速後端到端效率提升 55%；2B 的 MiniCPM-OCR Jev 承擔「AI 質檢員」，對解析結果做可靠性評分並可接入不同 OCR 模型，JevOCRBench 上整體 AUROC 為 0.936，接近 Qwen3.5-397B-A17B 的 0.938。
  • 平臺與路徑：覆蓋達摩院玄鐵、英偉達、華為昇騰、海光、崑崙芯、沐曦、摩爾執行緒、清微智慧、天數智芯、曦望、Mac（ARM）與此芯科技 12 個平臺。Jev 走 Torch-FL 接入，OCR 1.0 走推理框架外掛（vLLM-plugin-FL 或 SGLang-plugin-FL），底層都用 FlagGems 的運算元實現與 FlagTree 的編譯支援；版本口徑為 vLLM v0.24.0、vllm-plugin-FL v0.3.0、FlagGems v5.4.0。
  • 效能口徑：Jev 在英偉達上走 Torch-FL + FlagGems + FlagTree，12 條樣例、batch 1、單卡 BF16 下平均判別 76.2 毫秒，原生 62.7 毫秒，實際計算吞吐為原生的 82.3%；在達摩院玄鐵上平均 63.56 毫秒，吞吐達英偉達 H100 原生的 98.7%。OCR 1.0 在達摩院玄鐵上走 vLLM-plugin-FL + FlagGems + FlagTree，雙方均為單卡 BF16（峰值算力按 989 TFLOPS 與 123 TFLOPS 計），按峰值歸一化後單文件 P50 吞吐為原生的 169.3%、批次場景 137.1%。
  • 端側：ARM 側覆蓋 Mac 與此芯科技。Jev 僅用 M5 CPU，12 條樣例下平均單次頁面塊判別 1.2 秒、中位 895 毫秒，不包含前序整頁 OCR 解析；實現上保留 BF16 權重與判別頭，用 SME2 矩陣指令加速主要線性層，並透過 Triton TLE Raw 接入運算元執行路徑。
  • 觀察：這是近期第一份把「跨芯吞吐」與「端側時延」放在同一口徑下給出的適配說明——98.7% 是實際吞吐比，169.3% 是按峰值算力歸一化後的比值，兩者不可互相替代。文章也如實寫明 169.3% 的成立前提是低峰值算力平臺的利用率更高，而非單卡更快。

2.2 CSDN 技術直播：一個外掛打通十款晶片的推理適配（10-29）

日期：2026-10-29　來源：直播頁：大模型推理救星——一個外掛搞定多晶片適配

  • 事實：FlagOS 社群在 10-29 16:25 上架、19:00 開播一場技術直播，主題為 sglang-plugin-FL 的跨晶片推理適配。該外掛是構建在 SGLang 之上、不侵入核心原始碼的 out-of-tree 外部推理外掛。
  • 技術要點（頁面摘要）：透過 ATen 運算元替換、融合運算元排程、統一通訊抽象、PD 分離下的 KV Cache 傳輸、Empty 模式的依賴拆分等機制對接不同硬體；介紹口徑稱已適配昇騰、海光、崑崙芯等十款晶片平臺。
  • 對應程式碼面：本視窗內 sglang-plugin-FL 有 6 筆在審 PR 更新，包括昇騰與天數在 SGLang 0.5.18 上的 Empty 執行時適配（#160、#139）、崑崙芯升級到 0.5.18（#155）、以及複用原生 Mooncake PD 控制走通用 FlagCX 傳輸（#142）。直播內容與程式碼進度方向一致。
  • 觀察：社群側的內容節奏已從「釋出會式宣講」轉向「按外掛拆解的單點技術直播」，本場與 10-22 的高校圓桌、10-15 的運算元賞金挑戰賽構成一條連續的技術傳播線。

2.3 渠道核查：HN 與智源社群無新命中，CSDN 專欄新增一稿一直播（10-29）

日期：2026-10-29　來源：HN Algolia · 智源社群 · CSDN FlagOS 專欄

  • CSDN 專欄：頁面 15 條條目逐頁核時後確認，視窗內新增兩條——10-29 11:19 釋出的 MiniCPM-OCR 及 Jev 的 Day0 適配文章（見 2.1），以及 10-29 16:25 上架、19:00 開播的 sglang-plugin-FL 直播（見 2.2）。頁面上排在前列的 GLM-5.3-Flash（8-28）、Qwen3.8-Flash-Next（8-27）與 LightX2V 接入三稿為 8 月下旬舊文，不計入視窗。
  • HN：8 組查詢（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）在 4 天視窗內命中 6 至 30 條，但按標題與正文直接匹配均為 0，屬同名詞誤命中。
  • 智源社群：首頁與搜尋頁均無視窗內與軟體棧相關的新條目；搜尋頁為客戶端渲染，抓不到條目列表，以首頁核查為準。
  • gnews：24 組中英文查詢在視窗內共 30 條命中，逐條按標題與正文篩後僅一條與 FlagOS 相關——具身之家 10-29 的輝羲智慧參會稿，內容指向 10-17 至 10-18 的 2026 人工智慧開放計算大會暨眾智 FlagOS 技術大會，屬會後傳播稿，非視窗內新事件，不單列條目。其餘為科創板行情、董事會決議、園區招商與基金持倉稿，按標題關鍵詞整批剔除。
  • 成員官網：八家巡檢中沐曦官網有 10-29 新條目《從 Token 效率到開源協作，共赴 AI Infra 的下一個十年｜沐曦股份 CNCC 2026 分論壇回顧》，屬會議回顧，未涉軟體棧變動；摩爾執行緒官網最新為 10-28 的三季度報告圖解；天數、海光、寒武紀、燧原、清微五家列表無 10-29 至 10-30 新條目；地平線抓取失敗，以列表可見內容為準。

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

3.1 海光：DTK 26.10 從容器到 wheel 的全鏈落地（10-29）

日期：2026-10-29　來源：build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1562 · build-infra PR #1563 · build-infra PR #1565 · FlagAttention PR #109 · FlagTrain PR #35

  • 容器層：新增 DTK 26.10 的基礎容器與執行時配置（#1554 加 78 行、#1555 加 21 行），首次落地時明確「FlagCX 尚未構建，故本階段不納入」。修復筆 #1558 一次解決兩個阻塞：base/hygon-dtk26.10 把 /opt/dtk 指到 dtk-26.04 而 SDK 實際解到 /opt/dtk-26.10，以及構建矩陣缺該條目的 runner 覆蓋會落回 h20。
  • 依賴層：torch 2.13.0+dtk2610 的全域性依賴直接鏈 libmpi.so.40，24.04 基礎映象裡沒有任何包提供它，因此補 libopenmpi3t64（#1564）；FlagCX 的構建器用 22.04 自包含環境，包名為 libopenmpi-dev，單獨補（#1565）。同一筆還指出 26.04 的 wheel 把 libmpi 與 libibverbs 雜湊進包內，因此舊構建器從不需要這兩個系統庫——這是版本間構建假設變化的直接證據。
  • 編譯與通訊層：FlagTree 增 cp312 的 hcu 構建器並裝 DTK 26.10 SDK（#1562），hcu-dtk2610 進入 wheel 釋出目標（#1566）；FlagCX 的 dtk2610 wheel 線以 flagcx==0.14.1+dtk2610 開啟（#1563）。
  • 運算元側：FlagAttention 移除海光上的 FP8 MSA 路徑並修測試匯入（#109）；FlagTrain 的 multi_tensor_adam 把海光列為一等後端（#35）；在審側 FlagCX 有海光的 bitcode 構建（#667）、FlagScale 有 DCU 的硬體健康取樣（#1299）。
  • 判斷：海光這條線的價值不在新能力，而在把「新 SDK 帶來的 soname 與直譯器版本變化」在一天內走完容器、構建器、wheel 三處修正，並留下可複用的排查路徑（#1558 與 #1565 的正文即為該路徑的記錄）。

3.2 清微：Triton 3.6 後端同步合入並打出專用標籤（10-29）

日期：2026-10-29　來源：FlagTree PR #1459 · FlagTree 標籤 · FlagTree PR #1468 · vllm-plugin-FL PR #642

  • 合入內容：清微後端與內部 Triton 3.6 開發線同步（#1459，27 檔案加 2264 行減 407 行），只動 third_party/tsingmicro/：補回廠商運算元分發所需的逐發射精度 API（precision.py）、外部 CoreIR 入口與執行時介面卡，修 Tx81 的若干程式碼生成問題，並修 DMA、RDMA、WDMA、gather-scatter 與算術相關的 CRT 缺陷。
  • 版本動作：同日 11:09 打出清微 3.6 專號標籤，與 10-26 的摩爾執行緒 3.6 標籤構成同期序列。
  • 在審與生態：vllm-plugin-FL 的在審 #642 把清微的 eager TXDA 後端適配到 vLLM 0.28.0；FlagGems 側的清微參考實現在 10-29 有多筆測試夾具修正（見 1.4）。
  • 判斷：清微是少數把「內部開發線」直接同步進開源後端的廠商，代價是每次同步體量大（本次 27 檔案）、評審需要按廠商 SDK 語義核對；好處是 FlagGems 與 FlagTree 的介面約定能隨廠商內部進度前移。

3.3 崑崙芯：XPU3 的 foreach 融合鏈與常量網格收尾（10-29）

日期：2026-10-29　來源：FlagGems PR #7116 · FlagGems PR #7968 · FlagGems PR #7973 · FlagGems PR #7974 · FlagCX PR #678 · FlagGems-sglang PR #248

  • 融合核心：foreach 家族在 XPU3 上完成從「逐個運算元實現」到「List 執行器」的收斂——cos/exp/sin/addcdiv/lerp 走統一執行器（#7116），ceil 走無掩碼融合核心（#7604），tanh/expm1 走原地融合核心（#7608）。
  • 發射正確性：隨後四筆修復集中在發射引數——fmin 與 t_copy 的一維路徑改用常量發射網格（#7966、#7973），foreach 的標量 dtype 分支改為互斥（#7974），foreach add 的列表槽位改由 program_id(0) 推導（#7968）。這些不是效能最佳化，而是「同一運算元在多分支下取錯槽位」的正確性修復。
  • 介面面：FlagCX 增加 XPU 的裝置 IR 入口供 FlagTree 連結（#678）；FlagGems-sglang 的 fill_bonus_tokens 適配新的 tle.raw 方言 API（#248）。
  • 在審：vllm-plugin-FL 的 P800 在 vLLM 0.28.0 上的適配（#585）、sglang-plugin-FL 的崑崙芯升級到 0.5.18（#155），以及 FlagGems 側一批 P800 的正確性議題。

3.4 沐曦：分組 GEMM 的 INT8 與 FP8 路徑、TP2 解碼排程（10-29）

日期：2026-10-29　來源：FlagGems PR #6950 · FlagGems-vllm PR #1025 · FlagAttention PR #108 · FlagTree PR #1481 · FlagTree PR #1471

  • 分組 GEMM：grouped_mm_w8a8 同時支援 INT8 與 FP8（#6950，7 檔案加 1220 行）。基準的形態來自 GLM-5.2 在 PPU SGLang TP=8 上採集的真實呼叫回放，288 萬到 324 萬次呼叫的兩組形狀，共 26 組唯一幾何、257 個專家。基線是廠商庫的 ContinuousGroupedGEMM，兩邊接收相同 INT8 輸入、FP32 縮放與專家分組。
  • 解碼排程：FlagGems-vllm 側把 TP2 packed decode 的 Split-KV 排程與計算 tile 重排（#1025），目標是窄 tile 下的解碼吞吐。
  • 注意力：FlagAttention 新增 C550 上的 Triton 融合 AttnRes 前向（#108，3 檔案加 268 行），支援 FP16 與 BF16、可選輸出 RMSNorm 與注意力權重，融合 RMS 打分、線上 softmax 與殘差聚合，不依賴 TLE；D=7168、BF16 下從 (2,1) 的 0.075 毫秒到 (9,8192) 的 1.496 毫秒，作者註明 FLA 不可用故不宣稱加速比。
  • 編譯器：FlagTree 修 Metax 上 CompiledKernel 的後設資料檢查（#1481，對應議題 #1473）；在審的 #1471 為 MetaX 的 CommonIR 加 set_layout 與佈局自動調優。
  • 廠商側：沐曦官網 10-29 釋出 CNCC 2026 分論壇回顧《從 Token 效率到開源協作，共赴 AI Infra 的下一個十年》，屬會議側內容。

3.5 摩爾執行緒：TLE 常駐 GEMM 與 SPMC 同步進主線（10-29）

日期：2026-10-29　來源：FlagTree PR #1294 · FlagGems-vllm PR #970 · FlagTree PR #1451 · vllm-plugin-FL PR #575

  • 編譯器：[MThreads][TLE] 的常駐 GEMM 流水線與 SPMC 同步進主線（#1294，63 檔案加 6192 行減 403 行），把原先分別服務 addmm/baddbmm 與 bmm 的兩套編譯器合成一套超集，能力包括動態迴圈中的 stage 與 phase 推進、一生產者多消費者、命名讀與隱式讀、分段與分組完成、消費者紀元推導，以及單發、融合消費者與 16 warp 常駐路徑。PR 正文明確本輪改動只含編譯器、前端與測試，不含 FlagGems 運算元程式碼。
  • 推理：FlagGems-vllm 側按當前 CI 編譯器重調 MUSA 的 FP8 變長注意力（#970）。
  • 在審：FlagTree 的 #1451 把 WGMMA 的 warp 選擇對齊上游 MMAv3；vllm-plugin-FL 的 #575 把 MUSA 適配到 vLLM 0.28.0；另有 MUSA 的短形狀回退分支（FlagFFT 的 codex/musa-shortfall）在特性分支上推進。
  • 判斷：摩爾執行緒的投入重心在編譯器側而非運算元數量——常駐 GEMM 與 SPMC 是讓 addmm/bmm 一類主幹運算元在 MUSA 上跑到可用效能的前提，這條能力也同時被昇騰與沐曦的 TLE 線複用。

3.6 燧原、昇騰、達摩院玄鐵：注意力與歸一化運算元的四條線（10-29）

日期：2026-10-29　來源：FlagAttention PR #104 · FlagAttention PR #106 · FlagAttention PR #116 · FlagAttention PR #103 · FlagGems PR #6586 · Torch-FL PR #683 · FlagGems-vllm PR #888

  • 燧原：FlagAttention 上三筆同日合入——MiniMax M3 稀疏注意力的 prefill 與 decode 最佳化（#104，2 檔案加 2873 行減 2516 行）、chunk KDA 運算元最佳化（#106）、融合注意力殘差運算元（#116）；FlagTree 側補燧原 CI（#1468）與 TLE 單測（#1470），並在審 #1405 修 swiglu 的精度誤差。
  • 昇騰：新增 Parallax 注意力的三段實現（prefill、decode、kvcache，#103，10 檔案加 2738 行），覆蓋因果掩碼、滑窗、GQA 與變長輸入，相較 FLA 在多數訓練形狀上為 1.0 至 8.74 倍加速；FlagGems 修 cat（#7989）與 log_ 網格填充重跑（#6586，5.4.0-rc2 回摘）；FlagGems-vllm 把 fused_q_kv_rmsnorm 落到昇騰（#872），並把 lightning-indexer 的自定義運算元改名到 tle_raw.call（#944）；Torch-FL 讓昇騰遵循 FP32 matmul 精度並保持梯度駐留（#683）。
  • 達摩院玄鐵：fused_q_kv_rmsnorm 同樣落到達摩院玄鐵平臺（#888，17:07 合入）；PPU 側 10-29 還有 FlagTrain 的 multi_tensor_adam 全後端支援（#35，PPU 為一等後端），以及在審的 PPU GLA 最佳化（FlagAttention #117 為海光，PPU 另有獨立分支）；MiniCPM-OCR 的 Day0 適配把達摩院玄鐵的吞吐推到英偉達原生的 98.7%（見 2.1）。
  • 判斷：三家在同一天各取一條注意力路徑——燧原做稀疏與 KDA，昇騰做 Parallax 與融合 RMSNorm，達摩院玄鐵做融合 RMSNorm 與端側解碼。注意力層的碎片化仍在加劇，尚未出現跨廠商的統一下沉實現。

3.7 天數：天垓 300 首次實機演示對外，單卡吞吐宣稱 1.05 倍 H200（10-28）

日期：2026-10-28（演示）/ 2026-10-29（報道）　來源：Pandaily 報道 · 南華早報報道 · FlagCX PR #681 · sglang-plugin-FL PR #139

  • 演示事實：天數智芯在 10-28 的上海媒體開放日首次實機展示天垓 300 通用 GPU。此前該公司對這款晶片的公開材料以架構與路線圖為主，沒有可執行系統。
  • 宣稱與口徑：公司稱天垓 300 是首款實測效能達到英偉達 H200 水平的國產通用 GPU，第三方測試換算後單卡整體吞吐為 H200 的 1.05 倍，並在文生圖、文生影片等複雜多模態任務上超過 H200。該數字為公司口徑，測試方法、所用模型與工作負載條件均未公佈，無法複核。
  • 棧側對應：FlagCX 同日為天數補上 Device API 的獲取語義（#681，見 1.6）；sglang-plugin-FL 的在審 #139 把天數適配到 SGLang 0.5.18 的 Empty 執行時；FlagTrain 的 multi_tensor_adam 已把天數列為支援後端（#35）。
  • 判斷：硬體口徑的對外發布與軟體棧的適配是兩條不同節奏的線——前者一次釋出會即可完成，後者要從 Device API 的記憶體序一路補到推理框架的執行時適配。本視窗看到的是後者在持續補齊，而前者的數字仍缺可複核條件。

四、總結與趨勢觀察

  • 硬體代際切換的成本集中在構建面：DTK 26.10 八筆合入裡沒有一筆改核心，全部是容器路徑、直譯器版本、runner 覆蓋與 soname 依賴。python 3.12 與 torch 2.13.0+dtk2610 把既有 cp310 構建器整體作廢，26.04 到 26.10 之間 libmpi 與 libibverbs 從「雜湊進 wheel」變成「執行時連結」，這類變化只能靠逐節點實測發現。
  • 模型 Day0 的敘事轉向可比較的數字：MiniCPM-OCR 的適配說明同時給出實際吞吐比（98.7%）、按峰值歸一化的吞吐比（169.3%）與端側時延（M5 上 1.2 秒、中位 895 毫秒），並寫明各自前提。這是本棧近期第一份把「追上原生」與「利用率更高」分開陳述的材料，比單一倍數更有參考價值。
  • 測試基建成為獨立主線：ref-as-candidate 在 FlagGems 與 FlagGems-sglang 雙倉落地，配合同日 57 筆測試修復與 kernelgen-dev 的每日自動同步，測試從「有沒有運算元」變成「參考與實現是否一致」。這條線的產出不體現在運算元數量上，但決定了後續所有後端對齊的可信度。
  • 量子線自成體系：FlagQuantum 一日 60 筆提交把 CS-01 至 CS-07 的電路合成規格與交付文件成體系歸檔，FlagQAI 同步做本地工作臺。它與多芯適配無關，是 2.x 週期裡唯一一條與硬體解耦的軟體棧主線。
  • 待觀三點：其一，community 倉的 release/2.3 清單尚未建立而構建面已在按 2.3.0 記賬，釋出說明是否會補齊；其二，FlagCX v0.14.1 與 FlagTree 按廠商切分的 3.6 標籤均無 Release 正文，下游只能從標籤名反推內容；其三，Megatron-LM-FL 的 DeepSeek-V4 上游同步已開出 [1/N] 與 [2/N]，這條停擺兩週的訓練棧是否真正恢復推送。

信源核查表

信源 核查結果
GitHub org 全量（61 倉） 21 倉視窗內推送；16 倉有提交；5 倉經原子補核（1 倉有提交、1 倉為 gh-pages、1 倉為特性分支、2 倉為 PR 分支與議題活動）
提交檢索 189 筆；FlagQuantum 60、FlagGems 43 為兩大頭
合併 PR 檢索 183 筆；FlagGems 92、build-infra 16、FlagQuantum 15
在審 PR 檢索 253 筆有更新，新開 84 筆；Megatron-LM-FL 十筆為近兩週首次成規模更新
Release / Tag 原子核查 31 倉；視窗內新增標籤 1 個（FlagTree 清微 3.6 專號，無釋出正文）；FlagCX v0.14.1 檔案時間更新至 10-29 10:55
org 事件流 100 條：PR 評審評論 34、PR 事件 34、推送 13、議題評論 9、建分支 8、刪除分支 1、fork 1
Google News RSS（24 組中英文） 命中 30 條，有效 1 條（輝羲智慧參會稿，指向 10-17 至 10-18 大會，屬會後傳播稿，不單列）
HN Algolia（8 組） 4 天視窗命中 6 至 30 條，標題與正文直接匹配 0 條
CSDN FlagOS 專欄 新增文章 1 篇（MiniCPM-OCR Day0，10-29 11:19）、直播 1 場（10-29 19:00）；三條高相關舊稿核時為 8 月下旬，不計入
智源社群 首頁無視窗內軟體棧條目；搜尋頁為客戶端渲染，抓不到列表
成員單位官網（8 家） 沐曦 10-29 有會議回顧一條；摩爾執行緒最新為 10-28 財報圖解；天數、海光、寒武紀、燧原、清微無新條目；地平線抓取失敗

完整信源清單

[21] FlagTree PR #1481（Metax 後設資料檢查） — https://github.com/flagos-ai/FlagTree/pull/1481

— https://github.com/flagos-ai/FlagGems-vllm/pull/888

lagos.csdn.net/6ae2bb2740858c2d8817187c.html>