调研窗口：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 官方通稿）