调研窗口：2026-11-03 06:00 ~ 2026-11-04 06:00（北京时间，24 小时；接续上一期日报截点）。

信源：GitHub（org: flagos-ai 61 仓库全量核查、228 笔提交、177 笔合并 PR、271 笔窗口内更新在审 PR、117 笔新开、24 仓推送、31 仓 Release 与 8 仓 Tag 原子核查）、Google News RSS（24 组中英文查询词，走代理）、HN Algolia（8 组）、CSDN FlagOS 专栏（逐篇核时）、智源社区（详见附录信源清单）。

本期索引

  • 今日重点：vLLM 0.28 线四后端同日收口；FlagGems 两分钟 23 笔基准迁移；2.3.0 补上 CANN 9.2.1 第五层（11-03）
  • 一、开源项目进展（GitHub 动态）
    • 1.1 组织节奏：24 仓推送、228 笔提交、177 笔合入，全组织在审 1602 笔（11-03 ~ 11-04）
    • 1.2 版本面：2.3.0 补上第五层 CANN 9.2.1，base 镜像刻意不带 FlagTree（11-03）
    • 1.3 vLLM 0.28 线四后端同日收口：清微、沐曦 C550、摩尔线程 MUSA、昇腾解码图（11-03）
    • 1.4 FlagGems 基准参考：两分钟 23 笔合入，H800 参考读入统一到单一 JSON（11-03）
    • 1.5 FlagGems KernelGen：天数 BI-V150 十分钟十笔，英伟达十二笔，昆仑芯与燧原各补一段（11-03）
    • 1.6 FlagQuantum：布尔寄存器选择进入 qfunc/Qmod 前台，Pauli SELECT 降到门级（11-03）
    • 1.7 训练与算子库：TransformerEngine 新增壁仞 SUPA 后端，FlagTensor 补 MUSA，Megatron 接 DSv4（11-03）
    • 1.8 融合通信算子：RS+add+RMSNorm+AG 环形核进入 FlagGems 与 SGLang 插件（11-03）
    • 1.9 配套基建：optest 飞书通知带测试摘要，FlagTree CI 迁飞书多维表，FlagQAI 收紧 macOS 沙箱（11-03）
  • 二、新闻报道与生态
    • 2.1 渠道核查：24 组查询零组件级命中，CSDN 与 HN 窗口内无新文（11-04）
    • 2.2 产业侧：成员单位在乌镇峰会获杰出贡献奖，燧原科技登陆 A 股（11-03）
  • 三、成员单位与后端厂商深挖
    • 3.1 清微智能：TXDA 在 0.28 上只做 eager，把图模式明确拒掉（11-03）
    • 3.2 沐曦：C550 的 0.28 是「空适配」，改动全部留在插件内（11-03）
    • 3.3 摩尔线程：MUSA 0.28 一次带进原生 MCCL 与分段图（11-03）
    • 3.4 昇腾：0.28 解码图、CANN 9.2.1 base、INT8 BMM、910C CI 四处并进（11-03）
    • 3.5 天数、昆仑芯、燧原、玄铁、海光与地平线：一侧批量补算子，一侧继续调优（11-03）
  • 四、总结与趋势观察
  • 附录：信源核查表、完整信源清单

今日重点：vLLM 0.28 线四后端同日收口；FlagGems 两分钟 23 笔基准迁移；2.3.0 补上 CANN 9.2.1 第五层（11-03）

日期：2026-11-03　来源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #554 · vllm-plugin-FL PR #575 · vllm-plugin-FL PR #646 · FlagGems PR #8294 · build-infra PR #1614（全量见附录）

  • 推理线：vLLM 0.28.0 在一天之内被清微、沐曦、摩尔线程、昇腾四条后端同时收口，合计加 17051 行减 789 行、150 个文件。四笔的形态各不相同：清微把图模式整体撤掉只留 eager，沐曦在没有任何厂商 0.28 路径的前提下做「空适配」，摩尔线程把原生 MCCL 与分段图一并带进来，昇腾补的是解码专用图。同一个上游版本，四种落地策略，说明 FlagOS 的多芯片适配已经进入「按后端算账」而非「照模板复制」的阶段。
  • 算子线：FlagGems 在 16:41 与 16:42 两分钟内合入 23 笔，其中 21 笔由同一作者提交、全部是把各后端基准的参考数据读入从散落的 reader 迁到统一 JSON。这不是功能开发，而是评测可比性的基础设施——只有参考值来自同一份数据，跨后端的分数才有意义。同日 FlagGems 合计合入 76 笔，占全组织 177 笔的 42.9%。
  • 版本线：build-infra #1614 为 2.3.0 补上第五层 base 镜像 CANN 9.2.1（仅 910B、python 3.12、torch 2.13 与 triton_ascend 3.6.0），#1615 随即把该层的 changelog 日期按 registry 推送时间回填。镜像层面 2.3.0 已覆盖 base、寒武纪 neuware 4.4.3、沐曦 maca 3.8.1.3、海光 dtk26.10、AMD rocm7.2.4 与昇腾 CANN 9.2.1，但 community 的 release/2.3 清单仍返回 404，发布仍未跨过清单冻结这一步。
  • 判断：当日 177 笔合入、117 笔新开、271 笔窗口内更新在审，全组织在审存量 1602 笔。与上一窗口（162 笔合入、192 笔新开）相比，合入升 9.3%、新开降 39.1%，评审端首次出现「消化快于生产」的迹象。但新开量的回落主要来自 FlagGems 单仓（77 笔，其中 59 笔出自同一作者），并不代表整体需求降温。

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

1.1 组织节奏：24 仓推送、228 笔提交、177 笔合入，全组织在审 1602 笔（11-03 ~ 11-04）

日期：2026-11-03 ~ 2026-11-04　来源：flagos-ai 组织仓库 · 提交检索 · 合并 PR 检索 · 在审 PR 检索

  • 仓库面：61 仓中 24 仓窗口内有推送，为近两周最高。按推送时间从近到远为 vllm-plugin-FL、FlagTree、FlagQuantum、FlagTensor、FlagGems、TransformerEngine-FL、release-info、build-infra、Trident、docs、optest、Megatron-LM-FL、FlagDNN、FlagGems-vllm、FlagTrain、Torch-FL、FlagGems-sglang、FlagCX、FlagAttention、FlagSparse、FlagQAI、sglang-plugin-FL、OpenCourse、flir。其中 release-info 的推送仍是 gh-pages 自动部署，无源码变更。
  • 提交面：提交检索命中 228 笔，分仓为 FlagQuantum 108、FlagGems 47、FlagQAI 12、FlagGems-sglang 9、FlagSparse 8、FlagGems-vllm 8、optest 7、build-infra 5、FlagTensor 5、FlagDNN 4、FlagCX 3、FlagTree 3、FlagTrain 3、Torch-FL 2、FlagAttention 2、flir 1、sglang-plugin-FL 1。量子栈一仓占 47.4%，较上一期的 44.9% 略有回升。
  • 合入面：合并 PR 177 笔，来自 19 仓：FlagGems 76、FlagQuantum 28、vllm-plugin-FL 14、FlagGems-sglang 9、FlagGems-vllm 8、FlagTree 8、optest 7、FlagQAI 6、build-infra 5、FlagTrain 3、FlagCX 3、Torch-FL 2、FlagAttention 2，FlagTensor、Megatron-LM-FL、TransformerEngine-FL、FlagSparse、sglang-plugin-FL、flir 各 1。这是近期后端与组件覆盖最宽的一次合入分布。
  • 在审面：窗口内有更新的在审 PR 271 笔，新开 117 笔。分仓为 FlagGems 146（新开 77）、FlagGems-vllm 30（9）、FlagTree 28（5）、vllm-plugin-FL 17（8）、sglang-plugin-FL 8（3）、Torch-FL 7（1）、FlagTrain 6（3）、FlagAttention 4、flir 3（1）、FlagQuantum 3（3）、FlagCX 3（2）、FlagScale 3、docs 3（1）、Trident 2、FlagDNN 2（1）、Megatron-LM-FL 1（1）、TransformerEngine-FL 1、optest 1（1）、build-infra 1、FlagQAI 1（1）、FlagTree-AscendNPU-IR 1。按当前检索口径，全组织在审 PR 存量 1602 笔，合入与在审之比约 1 比 9。
  • 作者面：合入侧 FlagQuantum（机器人账号）36 笔、lukatao 33 笔、youseeyouonedayday 12 笔、xuanzhengdu-eng 10 笔、wuwentao 8 笔、physics31415926 6 笔、github-actions 机器人 6 笔。新开侧 youseeyouonedayday 一人 59 笔，占当日新开的 50.4%，其余为 SeddonShen 4、tonyh168 4、FlagQuantum 4、lukatao 3、Kaiwen1024 3。
  • 对比：上一窗口（11-02 06:00 ~ 11-03 06:00）为 162 笔合入、192 笔新开、311 笔窗口内更新在审。本窗口合入升 9.3%、新开降 39.1%、窗口内更新在审降 12.9%。三项合起来指向同一件事：评审端在加速消化存量，而新增开发单的绝对量由 FlagGems 一家主导。

1.2 版本面：2.3.0 补上第五层 CANN 9.2.1，base 镜像刻意不带 FlagTree（11-03）

日期：2026-11-03　来源：build-infra PR #1614 · build-infra PR #1615 · build-infra PR #1613 · community 2.2 发布清单

  • 新增 base 层：#1614 新增 base/ascend-cann9.2.1（aarch64 + ubuntu 24.04，仅 910B），带 CANN 9.2.1 toolkit、910B ops 包、NNAL 与既有的 /etc/profile.d/vendor.sh 环境捕获，并补 configs.yaml 行、cann921 runner 覆盖与 verify 节点别名。加 198 行、5 个文件。
  • 为什么是 python 3.12：PR 正文写明两条硬约束——flagos-pypi-ascend 上 torch 2.13、torch-npu 2.13、torchvision 0.28、torchaudio 2.11 的 wheel 只有 cp312；CANN 的 set_env.sh 会把它自带的 python 树塞进 PYTHONPATH，base 解释器必须与运行时 venv 完全一致，否则导入会串版本。配套把 triton 钉在 3.6.0 并叠加 triton_ascend 3.6.0，numpy 钉 1.26.4。
  • 为什么刻意不带 FlagTree 与 FlagCX：FlagTree 尚无 CANN 9.2.x 的版本钉固，9.2.1 也没有对应的 flagcx wheel，因此这一层把 flagtree、flagcx、env.app、deps_app 全部留空，构建顺序改为 base → 不带 FlagTree 的 runtime → FlagTree builder → FlagTree wheel → 刷新 runtime。缺省 flagtree 时编译器回落到 triton。
  • 版本标记：#1615 是机器人提交，把 2.3.0 标签下各后端待写的 changelog 条目按 registry push_time 落日期，本条对应 ascend-cann9.2.1 层，加 305 行减 5 行、4 个文件，不改任何镜像内容。另 #1613 让运行时的 FlagTree 版本请求支持显式 --index-url，为上述「多次构建」链路留出口。
  • 发布态核查：31 仓 Release 与 8 仓 Tag 原子核查，窗口内没有新的 Release 对象。community 侧 release/2.3/release-2.3.yaml 仍返回 404，release/2.2 清单在架。镜像已覆盖六层，清单冻结与站点上线两步仍未发生，与上一期判断一致。
  • 待观：base 层从四层扩到六层而清单未动，2.3.0 的「镜像先行」特征进一步强化。若本周仍不冻结清单，实际发布的版本内容将与 2.3.0 规划产生偏离。

1.3 vLLM 0.28 线四后端同日收口：清微、沐曦 C550、摩尔线程 MUSA、昇腾解码图（11-03）

日期：2026-11-03　来源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #554 · vllm-plugin-FL PR #575 · vllm-plugin-FL PR #646 · vllm-plugin-FL PR #676

  • 清微 TXDA：#642 把 TXDA 后端适配到 vLLM 0.28.0，明确「只做 eager」。图模式不是坏了而是被主动放弃——分段原生图在 TP8 下已通过两个模型的完整门禁（快照 R10 / R6d），但 Dense TP1 的正确性始终未解决，于是 PR 删掉 TXDA 的图捕获与切分实现，在配置阶段直接拒绝图与编译配置并提示 --enforce-eager。MLA、稀疏注意力、投机解码与上下文并行同样按具体不支持路径逐项拒绝，而不是一刀切。加 3067 行减 146 行、29 个文件。
  • 沐曦 C550：#554 在厂商侧还没有 0.28 路径的前提下做「0.28-empty」适配——所有改动留在 vllm_fl/ 与 MetaX CI 脚本内，后端行为以 vendor_name == "metax" 或 MetaX 运行时为门。按既有生命周期约定，早期 import 修复从插件入口装，kernel 与 backend 替换放 vendor patch 包，不写 site-packages 的 .pth，并在 setup.sh 里清掉 15 个历史 zz_fl_*.pth 钩子。加 2838 行减 70 行、36 个文件。
  • 摩尔线程 MUSA：#575 把 MUSA 升到 0.28.0，带原生 MCCL、FX/eager 编译与分段原生图，加 7804 行减 233 行、46 个文件。运行基线为四张 S5000、BF16、TP=4，TorchMUSA 2.9.0 与 MUSA SDK 4.3.5；编译侧 RMSNorm、SiLU、rotary 走显式 MUSA 算子边界，参考 RMSNorm 保留目标端的 FP32 累加契约；图处理集中在 dispatch/backends/vendor/musa/graph.py，并删掉 MUSA 编译子包与可执行缓存。
  • 昇腾解码图：#646 在 0.4.0-dev 上开 FULL_DECODE_ONLY 的原生图捕获与回放，覆盖 Qwen3.6-27B 与 Qwen3.6-35B-A3B，解码走 torch.npu.NPUGraph，prefill、视觉编码与采样留在图外。加 3342 行减 340 行、39 个文件，是 #606 与 #619 的向前移植。
  • 双线并行：与 0.28 收口同时，0.32 的适配正在评审队列里推进——vllm-plugin-FL 有 #675（燧原 S60）、#674（天数）、#659（AMD ROCm gfx1100）、#693（沐曦 C550）、#667（统一 FL 执行并适配燧原）五笔在审。0.28 是维护线、0.32 是目标线，两条线同时跑已成常态。
  • 同步机制：0.4.0-dev 向 0.5.0-dev 的 forward-sync 本窗口合入 #676、#678、#688、#689 四笔，从「整分支合并」改为「按审阅增量重放并保留源提交」，冲突以草稿 PR 公开。

1.4 FlagGems 基准参考：两分钟 23 笔合入，H800 参考读入统一到单一 JSON（11-03）

日期：2026-11-03　来源：FlagGems PR #8293 · FlagGems PR #8294 · FlagGems PR #8295 · FlagGems PR #8296 · FlagGems PR #8318

  • 批次规模：16:41 与 16:42 两个合并分钟内落地 23 笔，其中 FlagGems 21 笔、vllm-plugin-FL 2 笔，21 笔出自 lukatao。该窗口 FlagGems 共合入 76 笔，lukatao 一人 33 笔，接近半数。
  • 统一 JSON：核心是 #8293 至 #8296 四笔，分别把注意力与池化、归约与线性代数、点态、稀疏与张量布局四类算子的 H800 参考读入迁到统一 JSON。此前每类算子各有一套 reader，参考值的来源、单位与舍入约定分散在代码里；迁移后四类共用一份数据入口。
  • 后端参考修复：其余二十余笔按后端修参考实现——昇腾侧补 tensorinv、orgqr、weight norm 反向、Cholesky solve 与分数最大池化反向的原生 H800 基线；燧原侧修 baddbmm、nanquantile、masked scale 与 FlashAttention 参考；昆仑芯侧保留 FloatPower 原地参考覆盖；MUSA 侧补 LDL 与四个线性代数参考；PPU 侧修部分 LU 参考与重建精度。
  • 配套文档：#8318 新增「本地后端算子测试修复」技能文档，把「先对齐参考、再判断候选」的流程写成可复用的操作说明；#8275 至 #8277、#5858 另修 as_strided_scatter 用例、昇腾 CTC 输出 dtype、二项分布 out 重载与 cumsum 精度检查的 dtype 推导。
  • 判断：这一批的价值不在覆盖率，而在「可比」。跨后端分数只有在参考值同源、单位一致、舍入规则明确时才可比较。把 reader 收敛成单一 JSON 是评测体系从「各写各的」走向「同一把尺子」的前置条件，也解释了为什么它能以分钟级批量合入——改动机械、边界清晰、不触碰算子实现。

1.5 FlagGems KernelGen：天数 BI-V150 十分钟十笔，英伟达十二笔，昆仑芯与燧原各补一段（11-03）

日期：2026-11-03　来源：FlagGems PR #8093 · FlagGems PR #8085 · FlagGems PR #8124 · FlagGems PR #8255 · FlagGems PR #8265 · FlagGems PR #8110 · FlagGems PR #6501

  • 天数 BI-V150：16:04 至 16:10 的六分钟内合入 10 笔，全部标注 KernelGen 天数产线——三类特殊多项式（shifted Chebyshev、Hermite、以及 Chebyshev 的 out 变体）、两个上采样与填充反向、量化最大池化、矩阵乘 smm、not_equal 与池化索引反向。这是天数的单日后端条目峰值，也刷新了「一个后端十分钟十笔」的节奏纪录。
  • 英伟达长尾十二笔：稀疏与结构化四笔（_to_sparse_semi_structured、sparse_coo_tensor、crow_indices、flatten_dense_tensors）、cudnn 族两笔（cudnn_convolution_relu、cudnn_grid_sampler_backward）、视图与形状两笔（squeeze、combinations）、量化与类型两笔（make_per_channel_quantized_tensor、_cast_Char）、线性代数一笔（lu_solve），另有 _foreach 族在非英伟达后端兼容性的修复一笔。全部为 KernelGen 产线生成后人工收口。
  • 昆仑芯十一笔：#8273 一处打包三项性能改动（int cumsum 行扫描、mean 缩放折叠、nanmedian 向量化）；#8250 让 inner 在 XPU 上真正参与编译并重调 tile；#8252 把 Hermite h 改走后端点态执行器；#8253 降 poisson_nll_loss 的寄存器压力并修尾部越读；#8262 用展开的欧几里得算法优化 lcm；#8263 优化 special_chebyshev_polynomial_u；#8257 补 native_batch_norm_legit_functional 的后端特化。另有 #8255 用厂商 min.o 的 SIMD 载荷与分段宽行并行加速 argmin，#8281 把 bitwise_left_shift 的非原地入口路由到调优变体，#8290 与 #8319 修 foreach 系列在 XPU 上的失败。
  • 燧原 GCU300 四笔：#8265 修 cat/concatenate 拷贝核丢行尾的问题；#8259 把 silu_backward 的 div_rn 换成 tl.fdiv，修 GCU300 上的错误取值；#8251 让 uniform_ 的采样严格落在 [from, to)；#8254 修 clip/clip_ 在 GCU300 覆盖层里的关键字名。
  • 昇腾与 SiliconFlow：昇腾侧 #8110 新增通道级 INT8 BMM（bmm_w8a8，加 519 行减 3 行），#8286 补 910C 与 950DT 的 SKU 文档；SiliconFlow 侧 #6501 一次性补进 _embedding_bag、_embedding_bag_forward_only、_embedding_bag_backward 三个算子，支持 SUM/MEAN/MAX、加权、padding 排除、空袋与终止偏移，加 7494 行减 222 行、24 个文件。
  • 判断：当日后端条目的分布发生位移——天数以 10 笔领跑，英伟达以 12 笔继续补长尾，昆仑芯 11 笔以调优为主，燧原 4 笔全部是正确性修复，玄铁在 FlagGems 侧零合入（其动作落在 PPU 编译与插件侧，见 3.5）。这说明 KernelGen 产线已经能按厂商分别排产，而不是所有后端共用一个队列。

1.6 FlagQuantum：布尔寄存器选择进入 qfunc/Qmod 前台，Pauli SELECT 降到门级（11-03）

日期：2026-11-03　来源：FlagQuantum PR #1027 · FlagQuantum PR #1028 · FlagQuantum PR #1038 · FlagQuantum PR #1047 · FlagQuantum PR #1048 · FlagQuantum PR #1049

  • 布尔选择线：#1027 建立有界布尔值候选的构建，#1028 按目标代价选择布尔寄存器候选，#1029 用公共工作流验证这些候选，#1038 把有界布尔选择接到原生 qfunc 与 Qmod 前台。四笔连起来，把「布尔寄存器分配」从一个内部搜索变成用户程序可直接受益的编译能力。
  • 算法与降级：#1035 新增 SelectedMajoranaFermion，#1037 新增 SelectPauliLCU，#1036 把 Majorana 的降级推迟到编译期，#1047 把 Pauli SELECT 降到门级。配合 #1030（经典条件 Pauli 门上的量子控制）与 #1043（绑定操作的 append），算法层的表达力与后端可执行性之间的桥被分段建起来。
  • 语义与可视化：#1039 捕获原生单比特相位调用，#1041 暴露精确加权与全局程序相位，#1042 捕获有界的 within/apply 作用域，#1045 暴露受检的清理作用域与伴随调用，#1031 让绘图器在 TeX 里渲染混合量子控制与经典反馈，#1044 与 #1032 补两类可运行示例。
  • CI 复用：#1048 在 MetaX 的 CPU Core 通道试点只读的主机本地依赖环境——当 Python 补丁版本与 pyproject 的 SHA-256 完全一致时挂载只读依赖，否则走原安装路径。同一 runner 账号、Python 3.11.17、同一 checkout 的对照结果为：环境与 Torch 准备从 23 秒降到 1 秒以内，四段合计从 122 秒降到 101 秒，四项冒烟测试结果一致。#1049 把该机制扩到 16 个 A800 runner 注册，并要求显式只读绑定挂载。
  • 判断：28 笔合入分布在语义、算法、降级、可视化、CI 五条线上，没有单点大改。这种「每条线每天推进一小段」的节奏，使量子栈的验收单元始终可独立复算——对一门仍在快速变动的技术而言，账目清晰比功能多少更重要。

1.7 训练与算子库：TransformerEngine 新增壁仞 SUPA 后端，FlagTensor 补 MUSA，Megatron 接 DSv4（11-03）

日期：2026-11-03　来源：TransformerEngine-FL PR #143 · FlagTensor PR #14 · Megatron-LM-FL PR #202 · FlagTrain PR #49 · FlagGems-vllm PR #1055

  • 壁仞进栈：TransformerEngine-FL #143 新增 Biren SUPA 厂商后端，加 3608 行、7 个文件，是壁仞第一次以独立后端形态出现在 FlagOS 的训练组件里。PR 正文只写了「Add BIREN SUPA vendor」，未附硬件验证记录，属于骨架先行。
  • FlagTensor 补 MUSA：#14 为 FlagTensor 注册 MThreads/MUSA 后端并给出一小组已验证的逐元素算子，加 300 行减 5 行、14 个文件。要点是为 ACOS、ACOSH、ASIN、ASINH、ATAN、ATANH、TAN 七个超越函数加 MThreads 专用重写，绕开 MUSA Triton JIT 不支持的 libdevice 路径；NVIDIA 与昇腾的默认重写选择保持不变。同日该仓另有 PPU 直启快路径、host 侧循环计时与昆仑芯 tile 调优三笔提交，并合入昇腾 PR #32。
  • Megatron 接 DSv4：#202 是「DeepSeek-V4 向上游同步」系列的第 1 笔，加 3356 行减 775 行、26 个文件。核心是在 Float16Module 转换模型时保住精度敏感参数——新增可选 FP32 参数标记并应用于 attention sink/APE、mHC 的 mapping 与 gates、残差流输出头；把压缩机与索引器的部分投影留在 FP8 上下文之外并对私有存储做逆 RoPE；让延迟的权重梯度穿过可选注意力子模块；mHC 的 Sinkhorn 迭代默认值从 10 提到 20。
  • 训练与推理算子：FlagTrain 三笔，含 runtime 后端目录按后端归并、补其他后端镜像、以及上三角掩码 softmax 前向的 Triton 实现（英伟达与昇腾）。FlagGems-vllm 八笔，含 MiniMax M3 稀疏注意力 shim 复用 FlagAttention、MiniMax TP8 的 INT8 W8A8 MoE、fused_marlin_moe 的 W8A16 多级流水、W8A8 INT8 与 FP8 的 C++ 算子元数据登记。
  • 判断：新芯片进入 FlagOS 有两条路径——一条是从训练组件起（TransformerEngine 加后端、FlagTensor 加后端），一条是从算子产线起（KernelGen 逐算子补齐）。壁仞走的是第一条且停在骨架，摩尔线程则在两条路径上同时有落地，差距在验证深度而不在接入速度。

1.8 融合通信算子：RS+add+RMSNorm+AG 环形核进入 FlagGems 与 SGLang 插件（11-03）

日期：2026-11-03　来源：FlagGems PR #8317 · sglang-plugin-FL PR #166 · FlagGems-sglang PR #279 · FlagGems PR #8347

  • 核的设计：FlagGems #8317 新增两个融合「通信 + 归一化」的 Triton 核（在审，加 1403 行、3 个文件）。fused_rs_add_rms_norm_ag 用单个环形核替代 all_reduce(x) 加 fused_add_rms_norm(x, residual)，一次完成 reduce-scatter、残差相加、RMSNorm 与 all-gather；秩 r 只拥有 [r*chunk, min(T,(r+1)*chunk)) 的行，归一化只在这些行上执行，残差保持分散状态。gather=False 时在 owner 步之后停止，只做 RS 加 add 加 RMSNorm。配套的 fused_qkv_norm_ag 处理另一端：对分散的 qkv 输出分别归一化 q 与 kv，rest（k_pe）原样透传，只跑环的 AG 一半。
  • 环的实现：数据在 C 个通道上并发搬运，通道 c 是秩上的一个环；在 PPU 810E 上直接复用 pccl 28 通道图的环，使每一跳都走 ICN 链路。每次发送后在后继上做一次标志自增，接收方等 flag >= base + step；标志只增不减、缓冲奇偶每次调用翻转，因此前驱跑进第 n+1 次调用时不会碰到第 n 次仍在读的数据。
  • 上层接入：sglang-plugin-FL #166 在玄铁侧把这组 RS + norm + AG 融合核做成 pure TP prefill 的可选项（在审）；FlagGems-sglang #279 则把 6 个模型级算子（sglang 融合原地 RoPE、topk_softmax、fused_moe、chunk_gated_delta_rule_fwd、融合循环门控 delta 规则及其打包解码版）连同各平台 vendor 覆盖一起合入，加 13061 行减 79 行、85 个文件，其中 rms_norm 与既有 one_pass_rms_norm 数学与 ABI 一致，故以 _mthreads、_thead、_hygon 覆盖形式并入而非新增算子。
  • 配套清理：玄铁侧 #8347 在审，内容是移除 PPU 上 NT GEMM 的 K 对齐回退；FlagTree #1348 合入，保留显式 swizzled 的 TLE 布局并避免复制的链式 dot warp 布局。
  • 判断：把通信折进算子是 TP 推理降延迟的常见手段，但它要求算子库同时掌握通信原语与数值契约。FlagGems 这一批先由 PPU 与 SGLang 两条线试点，说明该能力仍绑定具体硬件拓扑，尚未抽象成跨后端通用件。

1.9 配套基建：optest 飞书通知带测试摘要，FlagTree CI 迁飞书多维表，FlagQAI 收紧 macOS 沙箱（11-03）

日期：2026-11-03　来源：optest PR #28 · optest PR #34 · FlagTree PR #1513 · FlagTree PR #1516 · FlagCX PR #669 · FlagQAI PR #30

  • optest 七笔：飞书通知加入测试摘要并把 Trigger 字段移到末尾、Commit 紧跟 Ref（#28）；探测 FlagTrain 的运行时元数据（#29）；算子命令超时可配置（#30）并按仓库分别配置超时（#32）；收窄 op-monitor 的上传重试（#31）；简化后端 GPU 配置（#33）；补中文 README（#34）。七笔全部围绕「让多后端测试结果可读、可追、可复跑」。
  • FlagTree 八笔：功能侧修昇腾 XCS 的 lightning-indexer UB 溢出、swiglu 精度与 tl.where 接受指针操作数，PPU 侧保留显式 swizzled 的 TLE 布局；CI 侧让 FlagGems 的 CI 脚本经 GITHUB_ACTION_PATH 跨分支共享，把结果报进飞书多维表，转发飞书密钥并在凭据缺失时告警，同时删除 enflame3.5-guc400 的 CI/CD 工作流。
  • FlagCX 三笔：新增昇腾 910C 的 CI 流水线并统一单元测试编排（加 1559 行减 664 行、41 个文件），把 Torch Python 覆盖跑到四个平台并清掉重复的 CUDA 性能测试，另修昇腾设备完成状态的追踪与张量保留。
  • FlagQAI 六笔：在 macOS 上把本地 Python 作业、headless 会话的 workspace 读取、原生 shell 读取、搜索目标与搜索子进程逐个收进沙箱边界，并在 Agent 提交前检查 SDK 就绪状态。六笔是同一轮安全收敛的连续切片。
  • FlagAttention 与其余：FlagAttention 补 TMA prefill 在非 2 的幂 head 维度上的修复，并改用 uv pip 安装厂商依赖；FlagSparse 合入 q4 相关整理；FlagDNN 四笔把打包镜像指向已发布的 FlagOS 仓库并把打包工作流改为只验证。
  • 判断：本窗口有 26 笔落在 CI、评测与工具侧，占全部合入的 14.7%。对一个要同时维护九家以上后端的项目，这部分投入不产生新算子，却决定了「哪个后端在哪个版本上退化了」能否被及时看见。FlagTree 删除 GCU400 工作流、新增 CANN 9.2.1 与 910C 流水线，也说明 CI 名单本身正在随硬件世代更替。

二、新闻报道与生态

2.1 渠道核查：24 组查询零组件级命中，CSDN 与 HN 窗口内无新文（11-04）

日期：2026-11-04　来源：Google News RSS（FlagOS 查询） · CSDN FlagOS 专栏 · HN Algolia（FlagOS）

  • Google News：24 组中英文查询词中，FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen、flagos-ai 及 BAAI 相关英文组合全部零命中；命中集中在成员单位与产业词（智源研究院 开源 4 条、智源研究院 芯片 4 条、燧原科技 7 条、国产算力 开源软件栈 7 条、摩尔线程 3 条、沐曦 1 条、清微 1 条），共 28 条，逐条核题后无一条涉及组件版本、芯片适配或 FlagOS 技术栈。这是组件级查询连续第二个窗口为零。
  • CSDN 专栏：页面 52 条链接逐条核时，最新一篇为 10-29 11:19 的 MiniCPM-OCR 与 Jev 的 Day0 适配文章，其后是 10-29 16:25 上架的 sglang-plugin-FL 直播。页面头部排在前列的 GLM-5.3-Flash、Qwen3.8-Flash-Next 与 LightX2V 三稿分别为 8-28、8-27、8-27 旧文，不计入窗口。
  • HN 与智源社区：HN 八组查询中 FlagOS 命中 7 条、BAAI 30 条，按标题与正文直配均为 0；智源社区首页无 FlagOS 条目，搜索页为客户端渲染，抓不到可核时的列表。
  • 判断：连续第二个窗口的新闻侧空白，与 GitHub 侧 24 仓推送、177 笔合入形成鲜明反差。FlagOS 的对外叙事仍高度依赖官方渠道（CSDN 专栏、智源社区、大会），第三方媒体对组件级进展的覆盖尚未形成。

2.2 产业侧：成员单位在乌镇峰会获杰出贡献奖，燧原科技登陆 A 股（11-03）

日期：2026-11-03　来源：世界浙商网（沐曦获奖） · 电子工程世界（摩尔线程获奖） · 财联社（燧原上市）

  • 获奖：沐曦股份与摩尔线程在 2026 年世界互联网大会乌镇峰会上同获「杰出贡献奖」。沐曦侧的报道强调全栈创新与国产 GPU 成长潜力，摩尔线程侧的报道由电子工程世界给出，两家均为 FlagOS 成员单位。
  • 上市：燧原科技登陆 A 股科创板，报道将其定位为科创板补强 DSA 架构算力拼图。燧原的 S60 后端已在 10-28 合入 vLLM 0.28 适配，0.32 适配（#675）在审。
  • 对照：三家在窗口内的 FlagOS 侧动作并不相同——沐曦 C550 的 0.28 适配当日合入（见 1.3），摩尔线程 MUSA 0.28 同日合入（见 1.3），燧原在 FlagGems GCU300 有四笔正确性修复（见 1.5）。资本与荣誉层面的进展没有改变其技术投入的节奏。
  • 说明：本条为企业侧动态，与 FlagOS 技术栈无直接关联，仅作生态背景记录；信源为 Google News 聚合链接，未取得发布方原站地址。

三、成员单位与后端厂商深挖

3.1 清微智能：TXDA 在 0.28 上只做 eager，把图模式明确拒掉（11-03）

日期：2026-11-03　来源：vllm-plugin-FL PR #642 · vllm-plugin-FL PR #641 · FlagGems PR #8279

  • 取舍：#642 的正文值得逐字读。分段原生图已经实现，并在 TP8 下对两个模型通过完整门禁（快照 R10 与 R6d），但 Dense TP1 的正确性始终没有解决。作者没有选择「只在部分并行度可用的图模式」，而是删掉图捕获与切分实现，在配置阶段拒绝图与编译配置，把用户直接指向 --enforce-eager。
  • 拒绝面：MLA、稀疏注意力、投机解码与上下文并行按各自不支持的具体路径逐项拒绝，而不是笼统禁用。这种写法让错误信息能指到具体能力，而不是让用户在运行到一半时才失败。
  • 验证环境：8 张 TX8110 64G，镜像内 vLLM 为 0.28.0+empty——用上游 tag 提交 2cf0a69 以 VLLM_TARGET_DEVICE=empty 构建，不带 vllm._C 扩展，所有 kernel 来自插件或 FlagGems。这等于把「插件是否真的自足」变成了硬约束。
  • 规模：加 3067 行减 146 行、29 个文件，配套 docs/usage/tsingmicro.md 部署指南。
  • 判断：这是当日最值得留痕的一次工程取舍。多后端适配最常见的失败模式，是让一个只在特定并行度成立的模式上线，然后在用户现场以数值错误的形式暴露。#642 用「少一个模式」换「不出现只在某些配置下错的模式」，代价明确、边界清晰。

3.2 沐曦：C550 的 0.28 是「空适配」，改动全部留在插件内（11-03）

日期：2026-11-03　来源：vllm-plugin-FL PR #554 · vllm-plugin-FL PR #693 · FlagGems-vllm PR #1050 · FlagGems-vllm PR #1054

  • 空适配的含义：厂商侧 MetaX-MACA/vLLM-metax 还没有 0.28 路径，因此 #554 是在「上游无对应分支」的前提下做的适配——所有改动留在 vllm_fl/ 与 MetaX CI 脚本内，后端行为以厂商名或运行时判定为门，不影响其他厂商。加 2838 行减 70 行、36 个文件。
  • 安装形态：早期 import 修复从插件入口装，kernel 与 backend 替换放 vendor patch 包；删除独立的 site-packages 引导安装器与 vllm_fl/_fl_boot_shims/，setup.sh 清掉 15 个历史 zz_fl_*.pth 钩子。评审明确否决了「往 site-packages 写启动钩子」的方案，这条否决本身对后续所有厂商都有效。
  • 双线状态：0.28 合入的同一天，0.32 的 C550 适配（#693）在 02:23 开出；FlagGems-vllm 侧另有 #1050 把稀疏 QSA 的 dot tile 下限提到 16、#1054 让 GLM5.3 的因果卷积与稀疏 MLA 核在 C550 上可运行（在审），以及 gdn_w8a16、fused_indexer_weight_scale、layernorm 三个算子优化在审。
  • 判断：沐曦这一窗口的形态是「0.28 收口、0.32 预跑、算子上补长尾」，三条线同时有动作但互不阻塞。值得注意的是 0.28 的落地方式——在上游没有分支时靠插件自足，这决定了下一次上游升级时它的迁移成本会更低。

3.3 摩尔线程：MUSA 0.28 一次带进原生 MCCL 与分段图（11-03）

日期：2026-11-03　来源：vllm-plugin-FL PR #575 · FlagTensor PR #14 · FlagGems PR #8097

  • 适配内容：#575 把 MUSA 升到 vLLM 0.28.0，同时带进普通 wheel 安装、原生 MCCL、FX/eager 编译与分段原生图，加 7804 行减 233 行、46 个文件。运行基线为四张 S5000、BF16、TP=4，Python 3.10、TorchMUSA 2.9.0、MUSA SDK 4.3.5。
  • 数值契约：编译侧 RMSNorm、SiLU 与 rotary 走显式 MUSA 算子边界；参考 RMSNorm 保留目标端的 FP32 累加契约。这一点很关键——把「参考实现按谁的累加精度」写清楚，跨后端比对才有意义。
  • 图与缓存：图处理集中在 MUSA 厂商补丁目录的 graph.py，同时删掉 MUSA 编译子包、可执行缓存与加载器。与清微的「撤掉图」相反，摩尔线程是「把图收进一个文件」。
  • 第二条线：FlagTensor #14 为张量库注册 MUSA 后端并给七个超越函数加专用重写，同日该仓还有 PPU 直启快路径与昆仑芯 tile 调优提交。FlagGems 侧 #8097（在审）用转置 dot 与 GEMV tile 优化瘦长 FP8 矩阵乘。
  • 判断：摩尔线程是当日唯一同时在「推理插件」与「张量库」两条线上有落地的厂商。两条线的分工也清楚：插件解决后端可用性，张量库解决底层算子形态。

3.4 昇腾：0.28 解码图、CANN 9.2.1 base、INT8 BMM、910C CI 四处并进（11-03）

日期：2026-11-03　来源：vllm-plugin-FL PR #646 · build-infra PR #1614 · FlagGems PR #8110 · FlagCX PR #669 · FlagTree PR #1413

  • 执行模式：#646 在 0.4.0-dev 上开 FULL_DECODE_ONLY 的原生图捕获与回放，覆盖 Qwen3.6-27B 与 Qwen3.6-35B-A3B，解码走 torch.npu.NPUGraph，prefill、视觉编码与采样留在图外。加 3342 行减 340 行、39 个文件，是主分支 #606 与 #619 的向前移植。
  • 运行时版本：#1614 新增 CANN 9.2.1 的 base 层，仅 910B、python 3.12、torch 2.13 与 triton_ascend 3.6.0，并刻意留空 FlagTree 与 FlagCX（详见 1.2）。#1615 把 2.3.0 下该层的 changelog 日期回填。
  • 算子：#8110 新增通道级 INT8 BMM（bmm_w8a8），加 519 行减 3 行；#8286 补 910C 与 950DT 的 SKU 文档。FlagTree 侧修 lightning-indexer 的 UB 溢出、swiglu 精度与 tl.where 接受指针操作数，flir #84 是同源修复。
  • CI：FlagCX #669 新增昇腾 910C 流水线并统一单元测试编排，加 1559 行减 664 行、41 个文件；Torch-FL #690 补原生昇腾量子数值与无损 FP64 集合通信。
  • 判断：昇腾在「运行时版本、执行模式、算子、CI」四层同日推进，是当日层次最完整的一条厂商线。CANN 9.2.1 base 留空 FlagTree 的选择也说明版本推进存在明确的先后依赖，而非一次性整体升级。

3.5 天数、昆仑芯、燧原、玄铁、海光与地平线：一侧批量补算子，一侧继续调优（11-03）

日期：2026-11-03　来源：FlagGems PR #8093 · FlagGems PR #8357 · FlagGems PR #8374 · FlagGems-vllm PR #1049 · sglang-plugin-FL PR #166 · FlagAttention PR #123

  • 天数：BI-V150 在 16:04 至 16:10 六分钟内合入 10 笔专用算子，覆盖 padding 反向、上采样反向、三类特殊多项式、量化池化、矩阵乘 smm、not_equal 与池化索引反向（清单见 1.5）。这是天数在 FlagGems 的单日峰值，且全部为新增实现。
  • 昆仑芯：合入侧 11 笔以调优为主——argmin 走厂商 min.o 的 SIMD 载荷与分段宽行并行、lcm 用展开欧几里得、poisson_nll_loss 降寄存器压力、inner 在 XPU 上真正参与编译并重调 tile。新开侧有一批集中在凌晨的修复：sum_dim 回退、fake_quantize 系列、lstm/gru 的 pipeline event 溢出、linalg_matmul 与 linalg_lu_solve 的 tt.gather 降级、avg_pool1d 让进程中止等。该窗口他一人新开 59 笔（燧原 31、昆仑芯 25、英伟达 3），其中 33 笔落在 00:07 至 05:43。
  • 燧原：GCU300 四笔正确性修复（cat 行尾、silu_backward 的除法语义、uniform_ 区间、clip 关键字），新开侧另有 #8374 让通用核在非 CUDA 后端运行、#8375 让修正 Bessel 核跑在非 CUDA 后端。FlagTree 同期删除 enflame3.5-guc400 的 CI/CD 工作流，属 CI 名单随硬件世代更替，不宜解读为产品线终止。
  • 玄铁：FlagGems 侧零合入，动作落在编译与插件侧——FlagTree #1348 合入保留显式 swizzled 的 TLE 布局；#8347（在审）移除 PPU 上 NT GEMM 的 K 对齐回退；sglang-plugin-FL #166（在审）把 RS+norm+AG 融合核做成 pure TP prefill 选项；FlagGems-vllm #1049（在审）为 thead 补 flash_mla_sparse_fwd。上一窗口的 13 笔专用算子批次之后，本窗口转入编译与通信层。
  • 海光：新开 #8357 优化面向科学模型负载的 FP32 矩阵乘；FlagGems-sglang #279 以 _hygon 覆盖承接 BW1000；FlagAttention #123 与 #117（均在审）分别补 AttnRes 后端与优化 GLA；FlagTrain #10（在审）的 mixed_gemm 覆盖海光。
  • 地平线与寒武纪：两家本窗口在 FlagOS 各仓库无提交。寒武纪的 neuware 4.4.3 层已在 2.3.0 名下完成 changelog 日期回填（见 1.2），属镜像侧存量工作。
  • 判断：后端条目正在从「补齐能跑」转向「按芯片调优」——昆仑芯的 argmin SIMD 化、海光的 FP32 矩阵乘优化、燧原的非 CUDA 通用核回退，三者都不是新增覆盖率，而是让既有实现在特定负载上更快或更稳。这类工作不出现在覆盖率数字里，却决定实际可用性。

四、总结与趋势观察

日期：2026-11-03 ~ 2026-11-04　来源：flagos-ai 组织仓库 · 合并 PR 检索

  • 合入端加速、生产端集中：177 笔合入较上一窗口增 9.3%，新开 117 笔降 39.1%，窗口内更新在审 271 笔降 12.9%。但新开的回落几乎全部来自 FlagGems 单仓的节奏变化，其中 59 笔出自同一作者、集中在昆仑芯与燧原产线。全组织在审存量仍有 1602 笔，合入与在审之比约 1 比 9，评审压力并未实质缓解。
  • 0.28 收口与 0.32 开局同时发生：清微、沐曦、摩尔线程、昇腾四条后端在同一天把 vLLM 0.28.0 收口，合计 150 个文件、17051 行新增；与此同时 0.32 的五笔适配在评审队列里推进。维护线与目标线并行已常态化，厂商需要同时维持两套验证环境，这是多芯片适配的隐性成本。
  • 评测可比性成为新的基础设施：FlagGems 两分钟 23 笔的基准迁移把四类算子的 H800 参考读入收敛到统一 JSON，配合 optest 的飞书测试摘要、FlagTree 的飞书多维表与 FlagCX 的四平台覆盖，评测链路正在从「各写各的」变成「同一把尺子」。本窗口 26 笔落在 CI 与评测侧，占合入的 14.7%。
  • 新芯片接入的两条路径都已跑通：壁仞以 SUPA 后端进入 TransformerEngine-FL（骨架先行、无硬件验证记录），摩尔线程同时在推理插件与张量库两条线落地，天数则以一天十笔专用算子走算子产线。接入速度已不是瓶颈，验证深度才是——壁仞的后端目前只有骨架，尚无与清微、沐曦同等级的硬件门禁记录。
  • 2.3.0 仍在镜像先行：base 层已扩到六层（含 CANN 9.2.1），运行时镜像按后端推送，changelog 日期逐层回填，但 community 的 release/2.3 清单仍返回 404。连续三个窗口未见清单冻结动作，版本发布的实际内容与规划之间正在积累偏离。
  • 待观察的三件事：其一，release/2.3 清单何时出现，决定 2.3.0 能否在本月内发布；其二，0.32 的五笔适配何时合入，决定目标线是否会再次推迟；其三，融合通信算子（RS+add+RMSNorm+AG）能否从 PPU 与 SGLang 的试点抽象为跨后端通用件。

附录

信源核查表

信源 核查结果
GitHub 组织仓库（61 仓） 24 仓窗口内推送，228 笔提交，177 笔合并 PR，19 仓有合入
GitHub 在审 PR 窗口内更新 271 笔，新开 117 笔，全组织在审存量 1602 笔
GitHub Release / Tag（31 仓 / 8 仓） 窗口内零新增；FlagCX v0.14.1（11-01 00:10）在窗口外
community 发布清单 release/2.3/release-2.3.yaml 返回 404，release/2.2 在架
Google News RSS（24 组中英文） 组件级查询全部零命中；成员单位与产业词 28 条，均为企业侧或财经稿
HN Algolia（8 组） FlagOS 7 条、BAAI 30 条，标题与正文直配 0 条
CSDN FlagOS 专栏 52 条链接逐条核时，最新一篇 10-29 11:19，窗口内无新文
智源社区 首页无 FlagOS 条目；搜索页为客户端渲染，无可核时列表
成员单位 GitHub 侧核查 沐曦、摩尔线程、清微、天数、燧原、海光有 FlagOS 侧动作；寒武纪、地平线本窗口零提交

完整信源清单