调研窗口：2026-09-11 10:18 ~ 2026-09-14 10:18 北京时间（周一窗口，过去 3 天，覆盖周末） 信源：GitHub（org: flagos-ai，53 个仓库 pushed_at + 单次 commit search 150 条按 committer-date 全量核验 + per-repo commits 复核 + commit 详情与补丁 + 仓库树 API）、community 仓库 2.2 发布清单与时间表（raw 直取）、Google News RSS（中英文 18 组查询词，走代理）、HN Algolia、FlagOS 官方社区站（版本与直播列表）、Tavily/web 检索、财联社/证券时报/IT之家/新浪财经等产业报道（详见附录）

索引

  • 一、开源项目进展（GitHub 动态）
    • 1.1 2.2 RC1 清单进入 rc1.postN 迭代：FlagGems 升到 v5.4.0-rc1.post2（09-11）
    • 1.2 FlagCX 交付化：libflagcx 从”源码自编”走向”按后端打 .deb + 按发行版发布 apt 仓库”（09-11/09-12）
    • 1.3 FlagCX 内核面：net adaptor 重构 6601 行，PAL 默认 device API 后端补齐（09-11/09-13）
    • 1.4 build-infra sglang 线：昆仑芯 xre5.37.1 与天数智芯 corex4.4.0 两条应用线落地（09-12）
    • 1.5 build-infra vllm 线：清微打开 0.20.2，天数智芯 0.24.0 收敛到统一 plugin wheel（09-13）
    • 1.6 FlagTree：0.7.0rc1 之后的基准与后端同步——昆仑芯集群 +17604 行、天数智芯基准入 CI（09-11/09-13）
    • 1.7 FlagGems：KMCompiler 昇腾代数补齐、KernelGen 多厂商入库、昆仑芯 copy 家族迁 TLE（09-11/09-14）
    • 1.8 推理与训练插件线：海光 vLLM 0.24.0 工作流开启，SGLang 侧四条竞赛分支合入（09-11/09-12）
    • 1.9 科学计算与领域算子库：海光与沐曦两批算子集中补齐，FlagBLAS 天数智芯 L2、FlagSparse 双后端（09-11）
    • 1.10 FlagQuantum：vNext 架构合并 + 0.2.0 发行件校验 + QPU 数字孪生（09-11/09-13）
    • 1.11 训练框架与工具面：Megatron-LM-FL 剥离 CUDA 硬依赖，FlagScale/FlagPrism/TransformerEngine-FL 各有推进（09-11/09-14）
  • 二、新闻报道与生态
    • 2.1 组件级检索第十个连续平静窗口：技术信息面全部来自代码仓库（09-11~09-14）
    • 2.2 产业侧三件事：移动云异构推理系统发布、燧原上市首日收官、沐曦解禁窗口临近（09-11~09-13）
    • 2.3 社区活动与竞赛：SGLang 跨芯片算子优化赛与算子赏金赛分享会，竞赛产出开始进入主仓（09-11~09-12）
  • 三、成员单位深挖
    • 3.1 燧原科技：科创板敲钟收官”国产 GPU 四小龙”资本化，技术面同步修 enflame 设备适配（09-11）
    • 3.2 天数智芯：进入移动云异构推理系统，同时在 FlagOS 内五条工作面并行（09-11~09-13）
    • 3.3 清微智能：vLLM 0.20.2 应用线打开，端到端验证与镜像 tag 闭环（09-13）
    • 3.4 海光信息：通信库 deb 后端打通、vLLM 工作流开启、算子批量补齐三线齐动（09-11/09-12）
    • 3.5 摩尔线程与沐曦：生成算子与后端算子两批落地，产业侧资本节奏分化（09-11~09-13）
    • 3.6 昆仑芯（外部生态方）：编译器侧大幅同步，但通信库被记录为”不可交付”（09-11/09-12）
    • 3.7 智源（牵头方）：2.2 测试期纪律与 RC1 清单维护，GA 定在 09-28（09-11）
  • 四、总结
  • 附录：完整信源清单

一、开源项目进展（GitHub 动态）

窗口总览：org 内 53 个仓库中 21 个在窗口内有推送；commit search 命中 150 条窗口内提交（5 页全量，committer-date 降序），经 per-repo commits 复核另补入 23 条，合计 173 条，分布于 18 个仓库：FlagGems-Experimental 54、build-infra 33、FlagGems 21、FlagQuantum 15、FlagCX 7、FlagGems-vllm 6、Megatron-LM-FL 5、FlagTree 4、FlagBLAS 4、FlagGems-sglang 4、FlagDNN 4、FlagSparse 10（其中 8 条来自 per-repo 复核）、FlagScale 1、FlagPrism 1、vllm-plugin-FL 1、TransformerEngine-FL 1、FlagOS-Compressor 1、community 1。另有 sglang-plugin-FL、docs、release-info 三仓 pushed_at 落在窗口内，但默认分支与分支 API 复核均无窗口内新提交（属分支或标签推送）。无新仓库、无新 GitHub Release 条目。

本窗口形态 = RC 测试期的”交付面成型 + 外部后端加码”双线：治理侧把 2.2 RC1 清单推进到第二轮验证（flagems 升 rc1.post2）；交付侧最重的一条线是 FlagCX 的 .deb 打包与 apt 仓库发布被完整走通（从”用户自己对着厂商 SDK 编译”变成 apt-get install）；编译器与算子侧则由昆仑芯、天数智芯、清微、海光四家把各自的应用线、基准线与算子面同时往前推。上一窗口预判的”2.2 GA 前 rc1.postN 递增节奏”在本窗口兑现，同时出现了第一条被明确记录为”不可交付”的后端（昆仑芯通信库），工程的边界开始被写清楚而不只是被推进。

1.1 2.2 RC1 清单进入 rc1.postN 迭代：FlagGems 升到 v5.4.0-rc1.post2（09-11）

来源：community #108（09-11 11:45）（清单文件 release/2.2/release-2.2-rc1.yaml 的窗口内唯一改动）

  • 第二轮验证落库：清单中 flaggems 条目由 v5.4.0-rc1.post1 更新为 v5.4.0-rc1.post2，tag 指向 rc1 分支头部 270bebe1，post1 之后累计 4 项修复——回退 FlagTune 的 Mul cost model、天数智芯 randperm/sort 修复、index int64 偏移溢出修复、缺失的 DSA __init__.py 打包修复。
  • RC1 清单现状（25 条组件快照）：L0 层为 FlagTree 三条线 0.7.0rc1.post1+triton3.3/3.5/3.6、FlagCX v0.14.0-rc1.post1；算子与领域库为 FlagGems v5.4.0-rc1.post2、FlagGems-vllm v0.2.0-rc1.post1、FlagGems-sglang v0.1.0-rc1.post1、FlagAttention v0.4.0-rc1.post1、FlagFFT v0.2.0-rc1.post1、FlagSparse v0.3.0-rc1.post1、FlagBLAS/FlagDNN/FlagTensor/FlagAudio 均为 v0.3.0-rc1.post1；框架接入为 vLLM-plugin-FL v0.3.0-rc1.post1（另有 0.2 线 v0.2.2-rc1.post1）、SGLang-plugin-FL v0.2.0-rc1.post1、Torch-FL v0.2.0-rc1.post1、TransformerEngine-FL / Megatron-LM-FL v0.3.0-rc1.post1；训练与工具为 FlagScale v2.1.0-rc1.post1、KernelGen v2.2.0-rc1.post1、KernelGenBench v0.2.0-rc1.post1、FlagRelease v0.3.0-rc1.post1、FlagOS-Compressor v0.1.0-rc1.post1。
  • 时间表口径：2.2 周期为特性冻结 08-31 → 测试与稳定期 09-01 至 09-24（只收 bug 修复、不进新特性）→ GA 09-28；毕业标准要求每个 FEP 的 Test Plan（命令 + 环境 + 期望结果、覆盖多芯片）在测试期内验收通过，未过部分单独挂验收 issue。

解读：清单的 25 条快照和”rc1.postN 递增”机制合起来说明一件事——2.2 的发布面已经不再由功能清单定义，而由”哪一轮验证通过”定义。windows 内唯一清单改动是把 FlagGems 推到 post2，且 4 项修复全部是数值/打包类缺陷（cost model 回退、randperm 排序、int64 偏移、子包缺失），这正是测试期纪律的直接投影：冻结之后版本号只由修复推动，不由特性推动。

1.2 FlagCX 交付化：libflagcx 从”源码自编”走向”按后端打 .deb + 按发行版发布 apt 仓库”（09-11/09-12）

来源：build-infra #847（09-11 18:02）、#849（09-11 18:50）、#851（09-11 19:18）、#853（09-11 21:37）、#854（09-11 22:00）、#855（09-11 22:06）、#856（09-12 11:20）、#865（09-12 17:20）、#866（09-12 18:25）、#868（09-12 21:08）

  • 为什么要打包（#847，+2449 行）：commit 说明写明 FlagCX 以源码形态分发，下游用户必须先对着自己的厂商 SDK 编译才能链接任何东西；在厂商自己的 base 镜像里构建 .deb 可以把 soname、-dev 头文件与 glibc 下限全部在构建期固定，用户侧只剩”装包”一步。实现上由 backends.yaml 承载打包事实（make flag、apt 依赖、证明厂商 SDK 存在的 assert），deb-config.py 与 generate_matrix.py --runtime 合并，--check 作为两者漂移报警；构建在 base/<backend> 内以固定 ref 克隆 FlagCX 树，规范 SONAME 并剥离 rpath，把运行库与头文件拆包；verify 阶段仅凭文件安装——在 base 镜像内证明可解析可加载，在纯净 Ubuntu 上证明 Depends 不会把厂商 SDK 拖进用户机器。
  • 发布到 apt 仓库（#851）：发布按 dispatch 可选（publish 默认 false），落到以构建所用 Ubuntu 版本命名的仓库（flagos-apt-ubuntu24.04 / flagos-apt-ubuntu22.04），arch 不作为地址的一部分由 apt 自行分流；发布步骤放在 verify 作业内而非后置 publisher，理由是”到用户 apt-get install 路径上的文件必须是刚被验证的那个文件”；publish 不带 verify 在 set-matrix 阶段即被拒，非 tag ref 也被拒（版本号取自克隆的 tags）。
  • 六个后端一次性启用（#865）：iluvatar-corex4.4.0/4.5.0、mthreads-musa4.3.6/5.2.0、sunrise-tangrt1.2.0、tsingmicro-tsm260610 各自补上容器内探测确定的 assert 与 vendor_lib_dirs。该提交同时修掉一个隐蔽缺陷：Makefile 只 glob flagcx/adaptor/*.cc，导致 flagcx_device.cc 对 devApiBackend 的硬引用在厂商 .mk 未提供 PLATFORM_EXTRA_SRCS 时符号未定义，而 -shared 容忍未定义符号、只有 dlopen(RTLD_NOW) 会报出来——cambricon 已有覆盖，iluvatar/sunrise/tsm 需要补齐。
  • 海光 DTK 后端打通（#866）：探测结论落地——DTK 完全不导出 CUDA_PATH，du.mk 的 DEVICE_HOME ?=/CCL_HOME ?= 捕获空值，两条路径被固定到 /opt/dtk/cuda/cuda-12；DTK 上 -lnccl 实际解析到 RCCL，因此产物 NEEDED 项是 librccl.so.1，nccl 拼写在 debian/rules 的 shlibs 循环里匹配不到；DTK 的库未注册 ldconfig、LD_LIBRARY_PATH 来自仅 bash 生效的 profile 脚本，dpkg-shlibdeps 必须显式列出两个目录。同提交修掉 verify 的 ldd 门禁被镜像自身环境影响的问题（基镜像把 BASH_ENV 指向一个会重导 LD_LIBRARY_PATH 的钩子，ldd 是 bash 脚本因而先执行了该钩子）。
  • 首条”不可交付”记录（#868）：昆仑芯 xre5.37.1 的 deb 条目保持禁用，原因被写进 backends.yaml 探测注记——CCL 库不在 .deb 构建所用的镜像里（base Containerfile 不装 CCL 包、XRE 5.37.1.0 安装载荷不含 xccl/bkcl，栈内唯一的 libbkcl.so 是厂商 torch wheel 内的运行时产物），即便找到也无法绑定（该库导出 C++ mangled 符号、没有纯 C 的 bkcl_* 入口）。DESIGN.md 的 triage 由”1 项探测待定”变为”19 项就绪 + 1 项已记录原因”。
  • 配套工程动作：#853 让流水线”以用户的方式”读回已发布 apt 仓库；#854 让某一行失败时仍验证已构建成功的行；#855 让 .deb 派发接受后端列表；#856 用构建它的工具链去读取 .deb；#859 把节点代理转发进 verify 容器。

解读：这条线是本期最具产品含义的变化。此前 FlagCX 的可用性等于”用户能不能自己把通信库编出来”，对一个要同时覆盖十余家厂商私有工具链的软件栈而言，这是规模化交付的最后一道手工门槛。把 .deb 放进按发行版切分的 apt 仓库，意味着 FlagCX 的安装面第一次与 vLLM/SGLang 插件的 pip install 处在同一层级；而”发布必须与刚验证的文件同一份”“publish 不得绕过 verify”“非 tag ref 不许发布”三条约束，说明这一层是带着审计意识建的。昆仑芯被明确记为不可交付而非含糊搁置，也让”19 就绪 / 1 有因”成为可对外陈述的交付面。

1.3 FlagCX 内核面：net adaptor 重构 6601 行，PAL 默认 device API 后端补齐（09-11/09-13）

来源：FlagCX #578（09-13 23:24）、#582（09-13 01:18）、#584（09-13 01:20）、#585（09-13 01:20）、#586（09-13 01:21）、#588（09-12 23:56）、#580（09-11 17:02）

  • 网络适配器重构（#578，+5309/-1292）：FlagCX 主仓本窗口最大单笔改动，规模超过其余六条之和。PAL（平台抽象层）方向的网络适配器被重写，是”通信库把平台差异收进抽象层”这条主线的延续。
  • 设备 API 后端接线（#582）：为剩余平台链接默认 device API 后端，与 build-infra 侧 #865 说的”厂商 .mk 留空导致 devApiBackend 未定义”是同一个问题的两边——主仓补链接、交付侧补字段。
  • 可用性与文档面：#586 在 FLAGCX_PATH 未设时回退到系统 FlagCX 库而不是直接失败；#584 在 getting_started 中列全缺失的后端（让”支持哪些平台”变成文档事实）；#585 固定 format 钩子所用的 clang-format 版本。
  • 供应链加固（#588）：把海光 CI 镜像固定到 SHCA 之前的 digest，避免上游镜像变更静默改变构建环境。
  • 厂商适配修补（#580）：修正燧原（enflame）设备适配器里 topsDeviceProp 的类型名。

解读：FlagCX 在本窗口同时做了三件性质不同的事——内核面重构（#578）、平台接线补漏（#582/#580）、交付与 CI 加固（#584/#585/#586/#588）。结合 1.2 的打包线，通信库正从”能连起来的库”变成”能装、能定位、能复现构建的库”。对多芯片软件栈来说，通信库恰恰是最容易在不同厂商 SDK 之间积压特例的组件（海光的 RCCL/ldconfig、昆仑芯缺失的纯 C 入口、燧原的类型名），本窗口的动作说明这些特例正在被逐条收敛进可测试的抽象层，而不是留在各厂商分支上。

1.4 build-infra sglang 线：昆仑芯 xre5.37.1 与天数智芯 corex4.4.0 两条应用线落地（09-12）

来源：build-infra #857（09-12 11:35）、#860（09-12 12:27）、#861（09-12 12:28）、#862（09-12 13:00）、#863（09-12 14:42）、#864（09-12 13:14）、#867（09-12 18:57）、#869（09-12 19:05）、#870（09-12 21:09）、#871（09-12 19:28）

  • 昆仑芯 sglang 线闭环（#857→#864）：先让 kunlunxin-xre5.37.1 “可构建、可驱动”，随后记录 F/T（功能与性能）验证结果、落库 sglang0.5.18-kunlunxin-xre5.37.1 changelog、记录应用镜像 tag 2.1.2-0.1.dev1_g7fb22a0c2、并把昆仑芯应用镜像写入 status matrix。同一批次修掉 vllm-plugin-wheel 解析 plugin_ref 时因 SIGPIPE 中止的问题（#860）。
  • 天数智芯 corex4.4.0 应用线（#867→#871）：补齐并校验 corex4.4.0 的应用配置，落库 sglang0.5.18-iluvatar-corex4.4.0 changelog 与镜像 tag 2.1.2-0.1.dev1_g4d44a24cd。
  • 910C 线收尾：#848 恢复昇腾 910C 重建的待发布 changelog 条目，#850（09-11 19:19） 记录 CANN 8.5.0-910c 的镜像 tag 2.1.2-0.2.0_gf31b199.d20260911，#835 记录 910C 端到端结果与已交付的 cann8.5.0 T 路径修复，#852（09-11 20:55） 把”应用镜像陈旧”背后的 docker 层缓存陷阱写成文档。

解读：sglang 侧的动作形态已经标准化为五步闭环——让某后端可构建、跑 F/T 验证、落 changelog、记镜像 tag、进 status matrix。昆仑芯与天数智芯在同一窗口各自走完一遍，说明这条闭环路径（上一窗口由昇腾与清微分别验证过）现在是可复制的例行工序，而不是每家后端一次性的攻关。对 2.2 GA 而言，真正决定发布范围的是 status matrix 上”已验证”的格子数，本窗口新增了昆仑芯与天数智芯 corex4.4.0 两格。

1.5 build-infra vllm 线：清微打开 0.20.2，天数智芯 0.24.0 收敛到统一 plugin wheel（09-13）

来源：build-infra #872（09-12 21:09）、#873（09-13 10:27）、#874（09-13 20:10）、#875（09-13 22:38）、#876、#877（09-13 22:49）、#878（09-13 22:56）

  • 清微 tsm260610 打开 vLLM 0.20.2（#873）：应用矩阵成员资格由 configs.yaml 中每后端的 deps_app 键决定，清微此前只有 vllm0.24.0，导致 generate_matrix.py --app vllm0.20.2 输出空 include 列表、构建作业在运行前即被跳过。本次补上 vllm0.20.2: []（0.20.2 插件 wheel 不需要额外厂商包），并附上待发布条目，镜像 tag 记为 2.1.2-0.2.1_g90ffdf0.d20260912（#874），插件 pin 到 F/T 端到端验证所对的 VPF #489 头部（#872 记录了该轮 0.20.2 的 F/T 结果）。
  • 天数智芯 0.24.0 收敛（#875→#878）：两条 corex 应用镜像改为从单一提交的 vllm-plugin-FL 头部（symm_mem stub）重建，使 corex4.4.0 与 4.5.0 收敛到同一个 vllm_fl 版本，不再各自 pin VPF #434 与 g07063fd 的变体 wheel；镜像 tag 记为 2.1.2-0.2.1_gc9e2573.d20260913。同一提交还明确否决了”在同一 wheel 里修 corex4.4.0 T 路径”的计划——该修复从未合入、探测补丁只能让 serve 输出垃圾，而共用天数智芯后端模块意味着带上它会把已验证的 corex4.5.0 T 路径置于风险中，最终在 14.4 节记录而非硬推。

解读：两条动作指向同一工程取向——矩阵要”能被枚举出来”，后端要”收敛到同一份插件”。清微的问题不是芯片不可用，而是应用矩阵的键没写全，构建作业被静默跳过；这类”看起来什么都没发生”的缺位在 RC 期最难发现，也最能说明 configs.yaml 已经变成发布面的真实清单。天数智芯那边则是一次典型的取舍记录：放弃一个会污染共用模块的修复，换取 corex4.5.0 已验证路径的确定性——RC 测试期”只进修复、不进特性”的纪律在具体提交里体现为”宁可不修，也不破坏已验证的格子”。

1.6 FlagTree：0.7.0rc1 之后的基准与后端同步——昆仑芯集群 +17604 行、天数智芯基准入 CI（09-11/09-13）

来源：FlagTree #1150（09-11 19:55）、#1153（09-13 22:28）、#1155（09-11 17:55）、#1157（09-11 17:24）

  • 昆仑芯 XPU 集群同步（#1155，+17604/-1775）：从内部 5a664566 同步 cluster 分析与 pass —— 引入 Scalar/Tile/Vectorizability 分析以及 XPU 专属 pass（Normalize、AsyncLoadSchedule、TLELegalize、LoopInvariantStaging、LegalizeExternEW），新增 stage_sm / load_scalar_indexed 算子与 GM2SM lowering，保留手写 OffsetAnalysis 属性、并把 budget-tiling 与 loop-invariant-staging 默认关闭；同时引入 P-TLE raw 前端（tle.raw）、修 size-one make range 的下沉，并让 compiler.py 传递 UnrollControl 预算旋钮（pin_unroll_num=-1 使 vector-add 走既有 unroll 路径）。来源标注为 baidu/xpu/triton 6848085b..5a664566。
  • 天数智芯基准进 CI（#1153）：把 iluvatar 的 vLLM benchmark 加入工作流，与上一窗口 PPU 线的做法一致。
  • PPU 基准刷新（#1157）：更新 890P 上的 PPU vLLM benchmark 结果（33 行数据）。
  • Triton 上游同步（#1150）：从上游 triton 引入 warp layout broadcast。

解读：0.7.0 的版本号收敛（上一窗口）之后，编译器的动作重心转向”后端基准化 + 集群同步”。两条基准线（天数智芯 vLLM benchmark 入 CI、PPU 890P 结果刷新）说明性能数据开始按后端进入持续记录；昆仑芯 +17604 行的集群同步则说明 XPU 线仍以”内部分支 → 开源集群”的方式推进，且伴随”哪些 pass 默认关闭”的保守设定——基准与 pass 的开关同样是被管理对象。

1.7 FlagGems：KMCompiler 昇腾代数补齐、KernelGen 多厂商入库、昆仑芯 copy 家族迁 TLE（09-11/09-14）

来源：#6093（09-11 18:59）、#6136（09-11 17:48）、#6161（09-11 17:13）、#6201（09-14 09:44）、#6203（09-11 17:16）、#6205（09-11 17:51）、#6209（09-14 09:48）、#5671（09-14 10:12）、#6183（09-11 17:33）、#6192（09-11 18:37）、#6213（09-13 20:15）、#5642（09-14 09:09）

  • KMCompiler 的昇腾代数继续补齐：窗口内合入昇腾后端的 matrix_rank（#6161）、igammac（#6136）、gru（#6201）、adaptive_max_pool3d（#5671，NVIDIA 与昇腾共用 Triton kernel）、linalg_solve_triangular 的昇腾基线路径跳过（#6209）以及依赖声明（#6205）。
  • KernelGen 生成算子多厂商入库：NVIDIA 侧补 split_with_sizes（#5590）与 convolution_overrideable（#5642，带 Triton kernel）；摩尔线程侧一次性入库 conv_transpose1d（#6174）、upsample_linear1d_backward（#6175）、fmod_（#6170）、matmuladd（#6180）四个专用算子。
  • 昆仑芯 copy 家族迁到 TLE（#6093）：把 copy 家族算子从常规路径迁到 TLE（Triton Language Extension）实现，与 FlagTree 侧的 TLE 推进对应。
  • 正确性与工程面：[k] 前缀的三批类别修复——索引与排序类（#5971）、nn 类（#5969）、数学类（#5967）；自动调优缓存启用 SQLite WAL 模式与 busy_timeout 以修 “database is locked”（#6203）；CI 修复 sort_exports 在双 __all__ 时误删 import（#6213）；更新昆仑芯/天数智芯的 FlagTree CI docker 镜像（#6192）。
  • 基准：新增独立的 FP8 矩阵乘性能测试，并以 vLLM 作为基线（#6183）；fused_marlin_moe 文档补齐”权重布局并非 vLLM Marlin 布局”的说明（#6204）。

解读：FlagGems 本窗口 21 条提交的结构很清楚——昇腾由 KMCompiler 路线按算子逐个补齐（一个算子一笔提交），NVIDIA 与摩尔线程由 KernelGen 路线批量入库，昆仑芯则进入 TLE 化改造。三条路径并行的意义在于：同一个算子库同时承载”编译器自动生成”“生成器批量产出”“手写 TLE 优化”三种产能，且各自对应不同成熟度的后端。工程面上最值得一提的是自动调优缓存的 SQLite WAL 修复——多芯片大规模跑基准时缓存的并发写是典型的长尾故障，这类修复通常只在大规模并行验证中才暴露，属 RC 测试期的真实产出。

1.8 推理与训练插件线：海光 vLLM 0.24.0 工作流开启，SGLang 侧四条竞赛分支合入（09-11/09-12）

来源：vllm-plugin-FL #436（09-11 10:54）、FlagGems-vllm #756（09-12 12:08）、#768（09-11 17:29）、#769（09-11 17:09）、#771（09-11 18:07）、#775（09-12 13:03）、#753（09-11 17:30）、FlagGems-sglang #45（09-12 11:43）、#47（09-12 12:16）、#58（09-12 12:21）、#61（09-12 11:44）

  • 海光进入 vLLM 0.24.0 工作流（vllm-plugin-FL #436）：为 vLLM 0.24.0 启用海光工作流，是插件层”新芯片/新版本先开工作流、再谈交付”路径的又一次执行。
  • FlagGems-vllm 的算子与测试面：海光侧补 persistent_topk 实现并通过 fused __init__ 接线（#756）；昇腾侧补 per_token_group_quant_fp8（#775）；沐曦侧优化 GDN chunk kernel（#771）；新增 fp8_einsum 及测试与 vLLM 基准（#769）；把跨后端 FP8 序列算子测试打开（#768）；把 combine_topk_swa_indices 的测试与基准改为厂商无关（#753）。
  • FlagGems-sglang 四条竞赛分支合入（09-12）：add-chunk-local-cumsum-vec（#45）、add-context-attention（#47）、qkv-lora-b（#58）、chunk-state-varlen-v2（#61）四条以 competition/ 与个人分支命名的 PR 在 40 分钟内陆续合入 master。

解读：插件线的两件事合起来看很有意思。一方面 fp8_einsum、combine_topk_swa_indices 这类改动是在把”某厂商专用测试”改写为厂商无关（vendor-agnostic），这与 build-infra 侧”后端收敛到统一 plugin wheel”是同一个方向——减少每厂商一套的变体。另一方面 FlagGems-sglang 的四条合入来自竞赛分支，说明社区竞赛的产出已经进入主仓而非停在排行榜上；对 2.2 而言，这些算子会随 flaggems-sglang v0.1.0-rc1.postN 进入发布清单。

1.9 科学计算与领域算子库：海光与沐曦两批算子集中补齐，FlagBLAS 天数智芯 L2、FlagSparse 双后端（09-11）

来源：FlagGems-Experimental #586（09-11 18:50）、#567、#606（09-11 16:56）、#415（09-11 17:25）、#427（09-11 17:14）、FlagBLAS #115（09-12 17:31）、FlagSparse #57（09-11 02:56）、#58（09-11 07:44）、FlagDNN #10（09-11 06:25）

  • FlagGems-Experimental：海光算子批量入库：一次补入 reflection_pad1d_backward（#567）、embedding_bag_dense_backward（#575）、upsample_nearest_exact2d_backward（#576）、lift_fresh（#585）、mse_loss_backward（#574）、binary_cross_entropy_backward（#577）、special_round（#582）、special_chebyshev_polynomial_u（#583）、amp_foreach_non_finite_check_and_unscale_（#559）、addmv_（#572）、diagonal_scatter（#570）、special_shifted_chebyshev_polynomial_v（#584）、baddbmm_（#586）等一批反向与特函数算子；同时新增达摩院玄铁的 linear 专用算子（#606，KernelGen 路线）。
  • FlagGems-Experimental：沐曦批次同步进退：约 35 条 MetaX 相关提交，一半是”Add MetaX support”（weight_int8pack_mm #415、unsafe_masked_index_put_accumulate #413、max_pool3d_with_indices_backward #402、cholesky_inverse #390、cudnn_convolution #392 等），一半是”Fix MetaX implementation”（special_gammaln #427、special_bessel_j0 #426、linear_backward #425、linalg_cholesky #423、histc #418、gcd_ #417、erfinv #416 等）。两条流同日交错，说明该后端进入”补实现 + 修实现”的密集校准阶段。
  • FlagBLAS：天数智芯 L2 支持（#115，+5325 行）：为 iluvatar 增加 L2（矩阵-向量）级别支持并与 master 合并。
  • FlagSparse：沐曦与昇腾加入 + SPMM 校准：窗口内 metax ascend added、ascend multi datatype、spmm bell out of metax test 及 CI 检查，PR #57/#58 由外部贡献方（NCIC-AlphaSparse）合入主仓。
  • FlagDNN：达摩院玄铁后端更新 + 厂商 README：更新 thead 后端（#10），补摩尔线程与昇腾的 README。

解读：领域库这一层的信息量在于”补齐的粒度”——单窗口内 54 条实验算子库提交 + FlagBLAS 的 L2 级别支持 + FlagSparse 的双后端加入，说明 2.2 的六大 AI for Science 库正从”能跑通”走向”覆盖面完整”。沐曦批次的形态尤其值得注意：Add 与 Fix 交错出现，是后端从”算子存在”迈向”算子正确”的典型信号，这类校准工作通常无法靠单一芯片验证发现，只能靠多家后端比对暴露。

1.10 FlagQuantum：vNext 架构合并 + 0.2.0 发行件校验 + QPU 数字孪生（09-11/09-13）

来源：FlagQuantum #15（09-11 18:26）、#16、#17（09-11 18:56）、#18、#19（09-11 20:31）、#20（09-11 22:11）、#23（09-13 15:06）、#24（09-13 18:29）、#25（09-13 19:33）、#26（09-13 20:05）

  • vNext 架构合并进主线（#15）：vNext 发表历史接入上游 main，架构重构分支合入。
  • 0.2.0 发行件校验（#17）：把 Python 包的 Homepage/Repository/Issues 元数据指向 flagos-ai/FlagQuantum 并与已发布上游仓库对齐；提交说明记录了验证口径——wheel 与 sdist 通过发行内容检查与严格 Twine 检查，两类安装产物均通过 API 执行、两步 PyTorch 训练循环、算子剖面加载与 Double-Single 数值一致性验证。
  • 量子后端与服务侧能力：#16 明确 Quafu 的 QSteed 插件安装方式；#18 提供 CUDA 与 QSteed 开发容器；#19 支持把 Quafu 电路提交到服务侧编译；#20 增加可续跑的 Quafu 与原生九鼎作业。
  • QPU 数字孪生（#24/#25/#26）：在 fq.twin 暴露厂商中立的 QPU 数字孪生，支持离线加载已验证的 Twin 证据并完成证据持久化；#23 在保持向后兼容的前提下迁移公开量子比特关键字。

解读：量子线在本窗口呈现的是一条完整的”产品化”轨迹——架构合并（vNext）、发行件与元数据对齐（0.2.0）、开发容器与服务侧提交、再到数字孪生与证据持久化。若说 6 月在”科学智能基座”发布时 FlagQuantum 还处在”量智融合的第一步”叙事里，本窗口的动作已经是标准开源项目的发布工序（distribution content check、Twine strict、PyTorch 训练循环冒烟、数值一致性）。对 FlagOS 的版图而言，量子计算这条线一旦进入独立的版本节奏，其组件治理方式（FEP、rc1 分支、release manifest）也会与其余 25 条组件并轨。

1.11 训练框架与工具面：Megatron-LM-FL 剥离 CUDA 硬依赖，FlagScale/FlagPrism/TransformerEngine-FL 各有推进（09-11/09-14）

来源：Megatron-LM-FL #149（09-11 10:41）、#150（09-11 14:04）、#151（09-11 19:04）、#154（09-12 18:06）、#156（09-14 09:00）、TransformerEngine-FL #118（09-11 14:10）、FlagScale #1291（09-11 19:01）、FlagPrism #10（09-11 21:24）、FlagOS-Compressor #7（09-11 14:27）

  • Megatron-LM-FL 的非 CUDA 化（五条提交）：#156 把硬编码的 CUDA 设备操作替换为平台感知 API，覆盖优化器、初始化、训练与工具路径，DDP 流创建与同步改用当前平台实现，并更新设备放置、张量创建、可用性检查与运行时初始化——提交说明明确目标是”防止非 CUDA 平台在训练初始化与执行中误用 CUDA 或 Musa 专用 API”；#154 让 rerun 状态机使用平台设备；#151 修插件侧平台名与设备名；#149 让专家数据并行使用进程组 world size；#150 去掉流水线并行的重复 P2P 通信器 stage 属性。
  • TransformerEngine-FL #118：让注意力路径遵守”禁用 flash attention”的开关（此前该标志未被尊重）。
  • FlagScale #1291：新增 KERV 优化运行时算子。
  • FlagPrism #10：为摩尔线程加入 profiler 与 debugger 支持并更新文档（对应 FEP 中”FlagTree DevTools”的落地）。
  • FlagOS-Compressor #7：合入逐选择器量化（per-selector quantization）特性分支。

解读：Megatron-LM-FL 的五条提交构成一条清晰主线：把”CUDA 或 Musa 专用 API”从训练主链路里剥离出来。对以多芯片为目标的重型训练框架，这类改造是接入新加速器的前置条件——只要初始化、DDP、设备放置任一处仍假设 CUDA，非 CUDA 平台就只能靠分支补丁活着。#156 与上一窗口的同类动作合并来看，训练框架侧正在把”平台差异”从分散的 if 分支收进统一平台 API；这与 FlagCX 收 PAL 抽象、FlagTree 收后端抽象是同一套工程语汇在不同层次上的重复出现。

二、新闻报道与生态

2.1 组件级检索第十个连续平静窗口：技术信息面全部来自代码仓库（09-11~09-14）

来源：Google News RSS 中英文 18 组查询词（走代理）、HN Algolia（FlagOS / FlagGems / FlagScale / FlagTree 四组）、FlagOS 官方社区站版本与直播列表、Tavily/web 检索

  • 组件级查询全部零命中：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagAttention、FlagCX、KernelGen、FlagOS-Robo、FlagQuantum（when:7d~14d，中英双语）、BAAI open source 在窗口内均无有效命中，构成为组件级检索的第十个连续平静窗口（上一窗口为第九个）。
  • HN 侧无有效条目：四组查询在窗口内返回的条目为通用技术讨论（GrapheneOS 投稿被 flag、DietPi v10.7、若干 Show HN 项目），与 FlagOS 组件无关联，按既有口径全部剔除。
  • 成员单位词命中以资本市场内容为主：燧原 when:2d（46 条）、沐曦 when:2d（27 条）、摩尔线程 when:2d（23 条）、海光 when:2d（11 条）、智源研究院 开源 when:7d（7 条）、天数智芯 when:2d（6 条）、地平线 开源 when:2d（1 条）；其中资本市场与转载类占绝大多数，智源社区文章（AI 大会、开源模型解读等）与 FlagOS 技术栈无直接关联，含”体育/登录/入口/官网/下载/博彩”字样的 SEO 稿件整批剔除。经筛选保留的产业条目见 2.2。
  • 官方社区站无窗口内新版本：FlagOS 官方社区站的最新图文发布仍为 08-28（GLM-5.3-Flash Day0 适配 9 款芯片），窗口内新增的仅为直播/活动条目，与代码仓库侧的密集动作形成对比。

解读：第十个连续平静窗口本身是一条信息——FlagOS 的对外可见度仍主要由代码与版本节奏构成，行业报道尚未形成对组件的持续跟踪。对使用者而言，这意味着”组件是否在动”的答案必须从仓库而不是从新闻里读；本期 173 条提交与零新闻的落差，也说明 2.2 GA（09-28）之前社区把注意力留在交付面而非宣讲面。

2.2 产业侧三件事：移动云异构推理系统发布、燧原上市首日收官、沐曦解禁窗口临近（09-11~09-13）

来源：IT之家（09-13）、财联社/科创板日报（09-13）、证券时报（09-11 12:22）、财联社（09-11 21:00）、新浪财经（09-13/09-14）

  • 国内首个”国产 GPU + 类脑芯片”大模型异构混合推理系统发布（09-13 报道，09-11~13 发布）：在河北廊坊举行的 2026 中国算力大会上，移动云公司联合中国电子科技南湖研究院、北京灵汐科技、上海天数智芯、清华大学、北京大学发布该系统。技术路径是对 Transformer 做 PD/AF 分离——Prefill 与 Attention 交给国产 GPU，FFN（MoE 专家）等延时敏感模块交给类脑芯片，利用其存算一体与片上大容量 SRAM 的带宽优势；团队自研模型编译器、高速互联协议与统一推理引擎完成任务拆解、协同调度与结果聚合，方案对标英伟达下一代 Vera Rubin with Groq 异构推理架构。实测为 3 台天数智芯 GPU 服务器搭配 3 台类脑机柜运行 DeepSeek V4 Flash，相较同等投入规模的纯 GPU 集群，推理输出与推理能效均提升一倍以上、业务运营成本下降 40% 以上；项目累计 15 项授权发明专利、6 项软件著作权，目前已进入小批量试产。
  • 燧原科技登陆科创板，首日收盘涨 179%（09-11）：发行价 142.18 元/股、发行 4303.52 万股、募资总额约 61.2 亿元；开盘 410 元（较发行价 +188.37%）、盘中最高 475 元、收盘 397 元（+179%），全天市值约 1709 亿元、换手率 76%；网上有效申购倍数 6109 倍、中签率 0.0246%。公司尚未盈利，依规纳入科创成长层；2023 至 2025 年营收 3.01/7.22/9.90 亿元，2026 上半年营收 11.20 亿元、同比增长 279.08%；其为四家国产 GPU 企业中唯一押注 DSA 专用架构、不兼容 CUDA 生态的一家。随着燧原挂牌，”国产 GPU 四小龙”（摩尔线程、沐曦、燧原、壁仞）全部完成资本化。
  • 沐曦解禁窗口临近（09-13 预告，09-17 生效）：沐曦股份 1396.6 万股限售股将于 9 月 17 日解禁，对应市值约 68.29 亿元，规模约占流通盘的 75%；同期报道称其 9 月股价跌近 30%、较高点已跌超 50%。背景数据（08-30 半年报，非本窗口）：2026 上半年营收 13.24 亿元、同比增长 44.67%，归母净利润 6.12 亿元实现扭亏（扣非仍为 -0.49 亿元），其中二季度净利 7.11 亿元；公司已于 2026-06-12 公告拟发行 H 股，启动 A+H 双平台布局。

解读：三件事分别处在不同层面——移动云的异构推理系统是技术路线层面的信号（GPU 不再被视为唯一算力形态，类脑芯片以”带宽敏感模块”的定位进入推理链路，且天数智芯是这套系统里的 GPU 提供方）；燧原与沐曦则是资本层面的信号（四小龙全部资本化后，市场关注点从”能不能做出来”转向规模交付与盈利兑现，沐曦的解禁窗口则是这一转向的直接压力测试）。对 FlagOS 的关联意义在于：这两类信号都在抬高”多芯片统一软件栈”的实际价值——异构推理系统需要编译器与统一推理引擎来调度两类算力，而国产 GPU 进入规模化交付后，其软件栈的迁移成本直接决定订单能否落地。

2.3 社区活动与竞赛：SGLang 跨芯片算子优化赛与算子赏金赛分享会，竞赛产出开始进入主仓（09-11~09-12）

来源：FlagOS 官方社区站（活动与直播列表）、FlagGems-sglang 仓库窗口内合入记录

  • SGLang 跨芯片算子优化赛：由众智 FlagOS 与 IEEE 联合主办、SGLang 协办，赛道一为 SGLang 框架算子多芯性能优化，设 200 余道真实推理算子题，参赛者自由选题、分批开放，使用 Triton / Triton-TLE 开发，多款芯片平台统一验证、统一测加速比，配实时排行榜与”全域攻占奖/攻克突破奖/单题极致性能奖”三类奖项。
  • 算子赏金挑战赛冠军分享会：官方社区站记录了 09-10 19:00 的获奖选手分享直播（心路历程、关键决策、避坑方法、实战技巧与互动答疑），为持续性赛事系列的一环。
  • 竞赛产出进入主仓：FlagGems-sglang 在 09-12 的 40 分钟内合入四条来自 competition/ 与参赛者个人分支的 PR（add-chunk-local-cumsum-vec、add-context-attention、qkv-lora-b、chunk-state-varlen-v2），全部指向 SGLang 推理链路上的 chunked attention 与 LoRA 相关算子。
  • 生态活动：众智 FlagOS 社区主办的《开放 AI 计算：面向多元异构硬件打造开源软件新生态》论坛于 09-07 在上海 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大会同场举办（智源、上海人工智能实验室、PyTorch 基金会、SGLang 等参与）。

解读：竞赛产出以 PR 形式进入 FlagGems-sglang 主仓，是本期最容易被低估的一条。社区竞赛常见的问题是”排行榜上很热闹、主仓里没变化”，而四条 competition/ 分支在同一上午合入 master，说明题源、验证环境与主仓之间已经接通——竞赛事实上成了算子产能的一条外部供给线，而这些算子会随下一个 rc1.postN 进入 2.2 发布清单。这也解释了 1.8 中”插件层把测试改为厂商无关”的动作：要统一测加速比，测试与基准就必须先做到跨厂商可比。

三、成员单位深挖

3.1 燧原科技：科创板敲钟收官”国产 GPU 四小龙”资本化，技术面同步修 enflame 设备适配（09-11）

来源：证券时报（09-11）、财联社（09-11）、FlagCX #580（09-11 17:02）

  • 资本面：09-11 登陆科创板（688801），发行价 142.18 元/股，开盘 410 元、收盘 397 元（+179%），市值约 1709 亿元；四家国产 GPU 企业全部完成资本化，”最后一块拼图”到位。招股与财报口径显示其 2026 上半年营收 11.20 亿元、同比增长 279.08%，2023 至 2025 年累计研发投入 36.76 亿元，截至 2025 年末研发人员 643 人（占员工 76.73%），承担 12 项国家及地方科技攻关项目、参与 58 项 AI 芯片与智算系统关键国家及行业标准制定。
  • 技术面（窗口内）：FlagCX #580 修正燧原（enflame）设备适配器中 topsDeviceProp 的类型名，属通信库平台抽象层的厂商适配修补。
  • FlagOS 内位置：燧原在 build-infra 的应用矩阵中仍以 enflame-tops1.9.10 与 enflame-tops1.10.6 两条 sglang 线路存在，在 FlagCX 的 .deb 后端清单中为已启用的探测通过项之一。

解读：燧原是四小龙中唯一走 DSA 专用架构与自研软件栈路线的企业，这也决定了它与 FlagOS 的关系更偏”软件栈自持 + 选择性接入”——其 enflame-tops 两条应用线在 FlagOS 矩阵内长期存在，但本窗口的技术动作只有一条类型名修正，属维护性而非扩张性。相比之下，同窗口天数智芯、清微、海光在后端与应用线上都有实质推进。资本化完成后，燧原的下一道关是研发变现与订单兑现，这一点会直接反映在其是否继续扩大在多芯片软件栈内的投入。

3.2 天数智芯：进入移动云异构推理系统，同时在 FlagOS 内五条工作面并行（09-11~09-13）

来源：IT之家（09-13）、FlagBLAS #115（09-12 17:31）、build-infra #867/#869/#870/#871（09-12）、build-infra #875/#877/#878（09-13）、FlagTree #1153（09-13 22:28）

  • 产业面：移动云牵头发布的”国产 GPU + 类脑芯片”异构混合推理系统中，天数智芯是 GPU 提供方（3 台天数智芯 GPU 服务器 + 3 台类脑机柜，运行 DeepSeek V4 Flash），承担 Prefill 与 Attention 计算。
  • FlagOS 内五条工作面：其一，FlagBLAS 的 L2 级别支持合入 master（+5325 行）；其二，build-infra 的 sglang 应用线新增 sglang0.5.18-iluvatar-corex4.4.0（配置校验 + changelog + 镜像 tag）；其三，vllm 侧把 0.24.0 的 corex4.4.0/4.5.0 收敛到统一 plugin wheel；其四，FlagTree 把 iluvatar 的 vLLM benchmark 加入 CI 工作流；其五，FlagCX 的 .deb 后端清单中 iluvatar-corex4.4.0/4.5.0 同时启用。

解读：天数智芯是本期出现频率最高的成员单位，且技术线与产业线互不重叠——产业侧是”作为国产 GPU 进入异构推理系统”，FlagOS 侧是”基础库 + 应用线 + 基准 + 打包”四层同时推进。这两件事在逻辑上是互补的：异构推理系统对带宽敏感模块的切分，最终要靠算子库、编译器与通信库来落地调度，而 FlagOS 正是这类系统最直接的软件底座候选。值得注意的是 FlagTree 侧把基准写进 CI，意味着天数智芯的性能数据此后会以持续记录而非一次性报告的方式存在。

3.3 清微智能：vLLM 0.20.2 应用线打开，端到端验证与镜像 tag 闭环（09-13）

来源：build-infra #872（09-12 21:09）、#873（09-13 10:27）、#874（09-13 20:10）

  • 应用矩阵补键：清微后端 tsingmicro-tsm260610 此前只带 vllm0.24.0，导致 --app vllm0.20.2 的输出为空、构建作业静默跳过；#873 补上 vllm0.20.2: [] 后该行进入构建矩阵，并附 changelog 与待发布条目。
  • 验证闭环：#872 记录 0.20.2 的 F/T 端到端结果，#874 记录镜像 tag 2.1.2-0.2.1_g90ffdf0.d20260912，插件 pin 到验证所对的 VPF #489 头部；FlagCX .deb 后端清单中 tsingmicro-tsm260610 亦为已启用项。
  • 延续面：上一窗口建立的 tsingmicro3.6 build-and-test 与 delivery 两条工作流（FlagTree 侧）在本窗口无新增，属常规交付线运行状态。

解读：清微这条线的价值不在新增能力，而在暴露了一类系统性风险——应用矩阵的缺键会让构建静默跳过。在一个覆盖十余家厂商、每家有多个版本组合的矩阵里，”没有报错但什么也没构建”比构建失败更难察觉。补上这一行之后，清微在 vLLM 侧同时具备 0.20.2 与 0.24.0 两条线，加上 FlagTree 的双工作流与 FlagCX 的 deb 后端，其接入深度已与最早一批成员单位相当。

3.4 海光信息：通信库 deb 后端打通、vLLM 工作流开启、算子批量补齐三线齐动（09-11/09-12）

来源：vllm-plugin-FL #436（09-11 10:54）、build-infra #866（09-12 18:25）、FlagCX #588（09-12 23:56）、FlagGems-vllm #756（09-12 12:08）、FlagGems-Experimental #586（09-11 18:50）

  • 通信库 .deb 后端打通（#866）：海光 DTK 后端从”探测待定”进入已启用状态，其间解决三类环境问题——DTK 不导出 CUDA_PATH 导致 DEVICE_HOME/CCL_HOME 为空、-lnccl 实际解析到 RCCL（产物 NEEDED 为 librccl.so.1）、以及 DTK 镜像的 BASH_ENV 钩子污染 verify 的 ldd 环境。
  • 插件与 CI：#436 为 vLLM 0.24.0 启用海光工作流；#588 把海光 CI 镜像固定到 SHCA 之前的 digest，避免上游镜像漂移。
  • 算子面：FlagGems-vllm 补 persistent_topk 并接入 fused __init__；FlagGems-Experimental 一次性补入十余个海光反向与特函数算子（reflection_pad1d_backward、embedding_bag_dense_backward、mse_loss_backward、binary_cross_entropy_backward、lift_fresh、baddbmm_ 等）。

解读：海光本窗口的动作密度在成员单位中最高，且三线性质互补——通信库侧解决的是”能不能装得上”（DTK 的路径、RCCL 命名、ldconfig 三个特例都是厂商工具链的真实摩擦点，且都被写进提交说明而不是留在某人的机器上），插件侧解决的是”能不能跑起来”，算子侧解决的是”覆盖面够不够”。一个值得留意的细节是把 CI 镜像固定到 digest：在多厂商流水线里，构建环境的确定性往往比代码本身更容易被忽视，海光线在此主动加固。

3.5 摩尔线程与沐曦：生成算子与后端算子两批落地，产业侧资本节奏分化（09-11~09-13）

来源：FlagGems #6174、#6175、#6170、#6180（09-11 18:17~18:21）、FlagPrism #10（09-11 21:24）、FlagGems-vllm #771（09-11 18:07）、FlagSparse #58（09-11 07:44）、新浪财经（09-13/09-14）

  • 摩尔线程：KernelGen 路线批量入库四个专用算子（conv_transpose1d、upsample_linear1d_backward、fmod_、matmuladd）；FlagPrism 为其加入 profiler 与 debugger 支持并更新文档；FlagDNN 补摩尔线程 README；FlagCX 的 .deb 后端清单中启用 mthreads-musa4.3.6 与 mthreads-musa5.2.0 两条；产业侧京东云十万卡集群的消息延续（原事件 09-09，已在前一期收录，本窗口内为转载与分析稿，不重复计入）。
  • 沐曦：FlagGems-vllm 优化 GDN chunk kernel（#771）；FlagGems-Experimental 约 35 条 MetaX 相关提交（新增支持与修复实现交错）；FlagSparse 加入 metax 支持；FlagCX .deb 后端清单中沐曦对应线未在本窗口启用。
  • 产业侧分化：沐曦 09-17 将迎来 1396.6 万股解禁（约 68.29 亿元），窗口内多篇报道聚焦其股价回落与解禁压力；摩尔线程窗口内新增”MT Lambda”商标注册申请的公开记录。

解读：两家在技术面上都处于”算子批量补齐”阶段，但产能来源不同——摩尔线程的四个算子来自 KernelGen 生成路线，沐曦的批次则集中在 FlagGems-Experimental 的手写实现与修复。产业侧的分化同样清晰：沐曦进入解禁与股价承压周期，摩尔线程则处在十万卡级订单叙事的上升段。对 FlagOS 而言，两家的技术投入节奏并未随资本市场波动而减速，本窗口各自的提交量都在成员单位中位居前列。

3.6 昆仑芯（外部生态方）：编译器侧大幅同步，但通信库被记录为”不可交付”（09-11/09-12）

来源：FlagTree #1155（09-11 17:55）、FlagGems #6093（09-11 18:59）、build-infra #857/#861/#862/#864（09-12）、build-infra #868（09-12 21:08）

  • 编译器侧：FlagTree 的 XPU 集群同步是本期最大单笔提交（+17604/-1775），引入整套分析框架与 XPU 专属 pass、P-TLE raw 前端与 UnrollControl 预算传递。
  • 算子侧：FlagGems 把昆仑芯的 copy 家族算子迁到 TLE 实现（#6093），与编译器侧的 TLE 推进呼应。
  • 应用线：build-infra 让 kunlunxin-xre5.37.1 在 sglang 线可构建可驱动，并完成 F/T 验证、changelog、镜像 tag 与 status matrix 记录。
  • 边界记录：FlagCX 把 kunlunxin-xre5.37.1 明确记为”不可交付”——CCL 库不在 .deb 构建所用镜像内（base 镜像不装 CCL 包、XRE 5.37.1.0 载荷不含 xccl/bkcl，唯一的 libbkcl.so 位于厂商 torch wheel 内且导出 C++ mangled 符号、无纯 C 入口）。

解读：昆仑芯在本窗口同时呈现”推进”与”限制”两面。编译器侧的 +17604 行说明其内部分支与开源集群的同步力度在加大；应用侧走通了 sglang 的完整闭环；但通信库这一层被判定为当前不可交付，原因写得非常具体（库不在构建镜像内、且即便找到也无法绑定）。这种”能编能跑、但通信库打不了包”的边界，正是多芯片软件栈最需要被显式管理的状态——它决定了该后端能支持单机推理还是能支持多机通信密集场景。

3.7 智源（牵头方）：2.2 测试期纪律与 RC1 清单维护，GA 定在 09-28（09-11）

来源：community #108（09-11 11:45）、community 仓库 2.2 时间表与 RC1 清单（raw 直取）

  • 测试期治理：2.2 周期为特性冻结 08-31 → 测试与稳定期 09-01 至 09-24（只收 bug 修复、不进新特性）→ GA 09-28；FEP 毕业标准要求覆盖多芯片场景的 Test Plan 在测试期内验收通过，未过部分单独开验收 issue 挂在 milestone 上。
  • 清单维护：窗口内唯一清单改动是把 FlagGems 由 v5.4.0-rc1.post1 推进到 v5.4.0-rc1.post2，并把四类修复（cost model 回退、randperm 排序、int64 溢出、子包打包）写进提交说明。
  • 版本面：FlagTree 三条 triton 线在清单中的记录为 0.7.0rc1.post1+triton3.x，FlagCX 为 v0.14.0-rc1.post1，全清单 25 条组件快照。

解读：牵头方在本窗口的动作全部是治理型的——维护清单、执行冻结纪律、把验收标准写成可核查的 Test Plan。这类工作在对外报道里不可见，但它决定了 09-28 那天能否给出一个”每个组件都有 tag、每个 tag 都经过多芯片验证”的交付面。与工程侧（FlagCX 打包、各厂商应用线）的动作合起来看，2.2 的核心问题已经不是”支持多少芯片”，而是”这些支持能否被复现、被安装、被审计”。

四、总结

  1. 交付面成为本窗口主线，通信库是第一个被彻底工程化的组件（最重要变化）：FlagCX 走通了”在厂商 base 镜像内按后端打 .deb → 发布到按 Ubuntu 版本切分的 apt 仓库 → 以用户的方式读回验证”的完整链路，并一次性启用六个后端；配套约束（发布件必须与刚验证的文件同一份、publish 不得绕过 verify、非 tag ref 不许发布）表明这一层是带审计意识建设的。此前 FlagCX 的可用性等于”用户能否自己对着厂商 SDK 编出来”，此后等于一条 apt-get install。

  2. 2.2 进入测试期后半段，版本推进完全由修复驱动：RC1 清单 25 条组件快照就位，窗口内唯一清单改动是把 FlagGems 推到 v5.4.0-rc1.post2（四项修复：cost model 回退、randperm 排序、int64 偏移溢出、子包打包缺失）；天数智芯 0.24.0 明确放弃一个会污染共用模块的 T 路径修复以保住已验证的 4.5.0 路径——”宁可不修，也不破坏已验证的格子”是 RC 纪律在代码里的直接形态。GA 定在 09-28，测试期 09-01 至 09-24。

  3. 应用矩阵的”闭环五步”成为可复制工序，缺键风险被暴露：让后端可构建 → 跑 F/T 验证 → 落 changelog → 记镜像 tag → 进 status matrix，本窗口由昆仑芯（sglang xre5.37.1）与天数智芯（sglang corex4.4.0）各走完一遍；清微的问题（deps_app 未写全导致构建被静默跳过）则提示这一矩阵已具备”没报错但什么都没构建”的失效模式，配置完整性本身就是发布面的一部分。

  4. 外部后端继续加码，且首次出现被显式记录的交付边界：昆仑芯 XPU 集群同步（+17604 行）、天数智芯 L2 库与基准入 CI、清微打开 vLLM 0.20.2、海光 DTK deb 后端打通——四条线同时推进；与此同时昆仑芯通信库被记为”不可交付”并写明原因（CCL 库不在构建镜像内、无纯 C 入口）。软件栈的价值不再只由”支持几家芯片”衡量，也由”每家支持到什么程度”的可陈述边界衡量。

  5. 算子产能呈三路并进，竞赛开始成为外部供给线：FlagGems 21 条提交中，昇腾走 KMCompiler 逐个补齐、NVIDIA 与摩尔线程走 KernelGen 批量入库、昆仑芯走 TLE 改造；FlagGems-Experimental 的 54 条里，海光一次性补入十余个反向与特函数算子、沐曦约 35 条”新增 + 修复”交错。更具长期意义的是 FlagGems-sglang 在 09-12 上午 40 分钟内合入四条来自跨芯片算子竞赛的 competition/ 分支 PR——竞赛产出首次以主仓提交的形式落进发布清单。

  6. 产业侧两条线索抬高多芯片软件栈的实际权重：移动云联合灵汐科技、天数智芯等发布国内首个”国产 GPU + 类脑芯片”异构混合推理系统（PD/AF 分离，3 台天数智芯 GPU 服务器 + 3 台类脑机柜跑 DeepSeek V4 Flash，性能与能效提升一倍以上、成本降 40% 以上），说明异构算力调度已进入工程化阶段；燧原登陆科创板首日收涨 179%、四小龙全部资本化，沐曦则面临 09-17 的 68 亿元解禁窗口——国产 GPU 的关注点从”做出来”转向规模交付与盈利兑现，而迁移成本与集群稳定性正是这一转向中最依赖系统软件栈的两个变量。

预判：后续观察面四点——其一，09-28 GA 前 rc1.postN 的递增节奏与清单中还有哪些条目会再迭代一轮；其二，FlagTree 在清单中的记录（0.7.0rc1.post1+triton3.x）是否会推进到正式 release tag，以及 build-infra 的 NVIDIA 线 pin 值是否从 0.6.1 跟上主线（上一窗口指出的版本错位仍在）；其三，FlagCX 的 apt 仓库是否出现首批真实用户安装反馈、以及沐曦等未启用后端何时补齐；其四，昆仑芯通信库的”不可交付”状态是否会被反转（例如 XRE 后续版本携带 CCL 并暴露纯 C 入口），以及移动云异构推理系统的规模化试产是否会带出对 FlagOS 算子/编译器层的具体需求。

附录：完整信源清单

信源 窗口内核查结果
GitHub org repos API（flagos-ai，53 仓） 21 仓窗口内推送：FlagGems、build-infra、FlagGems-Experimental、FlagQuantum、FlagCX、FlagGems-vllm、Megatron-LM-FL、FlagTree、FlagBLAS、FlagGems-sglang、FlagDNN、FlagSparse、FlagScale、FlagPrism、vllm-plugin-FL、TransformerEngine-FL、FlagOS-Compressor、community、sglang-plugin-FL、docs、release-info；无新仓库；GitHub Releases 无窗口内新条目
GitHub commit search（org 全量 150 条，5 页，sort=committer-date） 11 仓默认分支实质合入：FlagGems-Experimental 54 / build-infra 33 / FlagGems 21 / FlagQuantum 15 / FlagCX 7 / FlagGems-vllm 6 / FlagTree 4 / FlagBLAS 4 / FlagGems-sglang 4 / FlagPrism 1 / FlagScale 1
per-repo commits 复核（活跃但未入 search 的仓库） 补入 23 条：FlagSparse 10、Megatron-LM-FL 5、FlagDNN 4、vllm-plugin-FL 1、FlagOS-Compressor 1、TransformerEngine-FL 1、community 1；sglang-plugin-FL、docs、release-info 三仓默认分支无窗口内新提交（分支/标签推送）
GitHub commit 详情与补丁 #847（+2449 行，.deb 打包与 verify 口径）；#851（+85/-25，apt 仓库发布与 publish/verify 约束）；#865（+147/-75，六后端启用与 devApiBackend 未定义符号）；#866（+32/-19，DTK 路径/RCCL/BASH_ENV）；#868（+30/-11，昆仑芯不可交付原因）；#873（+46，deps_app 缺键与 0.20.2 打开）；#875（+20/-6，统一 plugin wheel 与放弃 T 路径修复）；#1155（+17604/-1775，XPU 集群同步与内部来源 5a664566）；#156（+103/-54，平台感知设备 API）；FlagCX #578（+5309/-1292，net adaptor 重构）
community 仓库 2.2 发布材料（raw 直取） release/2.2/release-2.2-rc1.yaml 共 25 条组件快照；release/2.2/schedule_CN.md 写明特性冻结 08-31、测试与稳定期 09-01~09-24、GA 09-28、FEP 毕业标准与 [URGENT] 例外通道；清单文件窗口内唯一改动为 #108（FlagGems → v5.4.0-rc1.post2，tag 指向 rc1 分支头 270bebe1，含四项修复）
Google News RSS（中英文 18 组查询词，走代理） 组件级查询（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/KernelGen/FlagOS-Robo/FlagQuantum/BAAI open source）全部零命中，第十个连续平静窗口；成员单位词命中中，保留移动云异构推理系统、燧原上市、沐曦解禁三类条目；智源社区常规文章与博彩类 SEO 稿件整批剔除
HN Algolia（FlagOS / FlagGems / FlagScale / FlagTree） 窗口内返回条目为通用技术讨论（GrapheneOS、DietPi v10.7、Show HN 系列），与 FlagOS 组件无关联，全部剔除
FlagOS 官方社区站（版本与活动列表） 最新图文发布仍为 08-28（GLM-5.3-Flash Day0 适配 9 款芯片），窗口内无新版本；窗口内新增为活动条目：SGLang 跨芯片算子优化赛（众智 FlagOS × IEEE 主办）、09-10 算子赏金挑战赛冠军分享会、09-07 KubeCon 上海《开放 AI 计算》论坛
Tavily/web 检索（原站核日期） 移动云异构推理系统：IT之家 09-13、财联社/科创板日报 09-13（3 台天数智芯 GPU 服务器 + 3 台类脑机柜、DeepSeek V4 Flash、性能与能效提升一倍以上、成本降 40% 以上、15 项专利 + 6 项软著、小批量试产）；燧原上市：证券时报 09-11、财联社 09-11（发行价 142.18 元、开盘 410 元、收盘 397 元、市值约 1709 亿元、换手 76%、中签率 0.0246%、2026H1 营收 11.20 亿元 +279.08%）；沐曦解禁：新浪财经 09-13/09-14（1396.6 万股、68.29 亿元、约占流通盘 75%）
已核实但不重复计入的条目 京东云与摩尔线程十万卡集群（原事件 09-09，已在前一期收录，窗口内为转载与分析稿）；沐曦 2026 半年报（08-30 披露，仅作背景数据）

局限性说明：本期技术信息面仍以代码仓库为准，产业报道仅用于成员单位资本与产品动态的对照；Google News RSS 经代理访问，命中量与覆盖度受聚合源收录节奏影响，组件级查询连续零命中已连续十个窗口。FlagOS 官方社区站图文更新滞后于仓库动作（最新图文 08-28），社区活动信息取自其站内活动列表。企业财务与市场数据来自公开报道，未做进一步交叉验证。