调研窗口：2026-10-26 06:00 ~ 2026-10-27 06:00（北京时间，24 小时；周二晨报，窗口自上一期日报截点接续）。

信源：GitHub（org: flagos-ai 61 仓库全量核查、提交检索 185 笔、合并 PR 133 笔与在审 PR 225 笔检索、org 事件流 100 条、31 仓 Release/Tag 原子核查、2 仓 Atom 兜底、关键 PR 正文与文件规模核查）、Google News RSS（24 组中英文查询词，走代理）、HN Algolia（8 组）、CSDN FlagOS 专栏、智源社区（详见附录信源清单）。

本期索引

  • 今日重点：2.3.0 运行时进入应用重建；玄铁 BLAS1 整批落库；FlagCV 首次公开定位（10-26）
  • 一、开源项目进展（GitHub 动态）
    • 1.1 组织节奏：18 仓推送、185 笔提交、133 笔合入，在审积压升至 225 笔（10-26 ~ 10-27）
    • 1.2 运行时 2.3.0：vllm 应用获重建授权、统一标签落定，新增 AMD ROCm 7.2.4 基础镜像（10-26）
    • 1.3 达摩院玄铁：FlagBLAS 一次性补齐 15 组 BLAS1 算子，一万六千行落库（10-26）
    • 1.4 FlagGems：49 笔合入，KernelGen 算子批次与昆仑芯 XPU3 融合提速并行（10-26）
    • 1.5 FlagQuantum：109 笔提交、47 笔合入，Quafu SDK 切换收尾与固定 shots 契约（10-26）
    • 1.6 FlagCV：首个定位说明合入，Triton 视觉算子库对外成形（10-26）
    • 1.7 FlagTrain：KMCompiler 一支铺到七家后端，五笔在审（10-26）
    • 1.8 其余仓库：FlagTree 打 MThreads 专用标签，optest 合并十三支厂商检查脚本（10-26）
  • 二、新闻报道与生态
    • 2.1 清微智能：Open3D-PIMC 从开源首发走到三十国师资课堂（10-26）
    • 2.2 沐曦：RLinf 全栈适配合入官方主线，千卡完成 SFT 到 RL 后训练验证（10-26）
    • 2.3 渠道核查：12 条候选 2 条有效，CSDN 专栏与 HN 均无新命中（10-27）
  • 三、成员单位与后端厂商深挖
    • 3.1 达摩院玄铁：BLAS1 整批落库，fp8 GEMM 的玄铁分支仍在审（10-26）
    • 3.2 昆仑芯：XPU3 侧三笔 foreach 融合、原地 GEMM 与位码构建（10-26）
    • 3.3 沐曦：SGLang 插件新增 MetaX 后端整包，vLLM 侧三条模型适配在审（10-26）
    • 3.4 清微：TXDA 后端随 vLLM 0.28.0 升级，FlagCX 打包纳入清微（10-26）
    • 3.5 燧原、海光、天数、摩尔线程：四条后端各有一笔结构性改动（10-26）
  • 四、总结与趋势观察
  • 附录：信源核查表与完整信源清单

今日重点：2.3.0 运行时进入应用重建；玄铁 BLAS1 整批落库；FlagCV 首次公开定位（10-26）

日期：2026-10-26 ~ 2026-10-27　来源：build-infra PR #1488 · FlagBLAS PR #154 · FlagCV · FlagGems PR #7688（全量见附录）

  • 版本面：build-infra 在 10-26 20:10 授权把二十个 vllm0.24.0 应用镜像在 2.3.0 运行时上重建，随后把标签从「按后端加后缀」收敛成统一标签 2.3.0-0.3.0。同日 23:05 新增 AMD ROCm 7.2.4 基础镜像，后端键为 amd-rocm7.2.4，在干净的 ubuntu:24.04 容器内演练通过，并用本地 gfx1100 镜像验证八张 W7900 的直通。2.3.0 从「运行时已刷新」推进到「应用层开始跟版」，标签本身仍未打出。
  • 算子面：FlagBLAS 合入达摩院玄铁的 L1 支持，一次性补齐 AMAX、AMIN、ASUM、AXPY、COPY、DOT、DOTC、DOTU、NRM2、ROT、ROTG、ROTM、ROTMG、SCAL、SWAP 十五组基础线性代数算子，改动 17 个文件、新增 16,168 行。该 PR 在上一期日报中还处于在审状态，本窗口完成合入，是玄铁在后端矩阵里从「能跑推理」走向「补齐数值库」的一步。
  • 方向面：FlagCV 合入首份 About 说明，把仓库定位写成「以 Triton 实现的高性能计算机视觉库」——对外提供 OpenCV 形状的图像处理原语接口（色彩转换、滤波、几何变换、算术运算），以 OpenCV 的 CUDA 基线为对标，构建在 FlagTree 之上，后端可插拔。这是组织在视觉方向第一次把仓说清楚，此前 10-14 建仓、10-18 落骨架时只有占位代码。
  • 生态面：沐曦宣布面向具身智能的强化学习框架 RLinf 全栈适配合入其官方主线，基于曦云 C 系列 GPU 完成 512 卡与 1024 卡两档 SFT，以及多场景 RL 后训练验证，四组任务成功率对齐或超过论文报告值，其中一组高 8.8 个百分点，多机扩展线性度保持在 97% 以上。此事不属 FlagOS 组件发布，但与其「上游优先」路线同源。
  • 节奏面：24 小时窗口 18 仓推送、185 笔提交、133 笔合入、225 笔在审（新开 74 笔）。与上一个 24 小时窗口（10-22：16 仓、135 笔提交、163 笔合入、183 笔在审、90 笔新开）相比，提交增 37%、在审增 23%，合入与新开各降 18%——开发在积累，评审吞吐在回落。
  • 判断：本期没有新版本发布，也没有模型 Day-0 齐发，内容重心回到「填平后端」：玄铁补数值库、AMD 新增基础镜像、清微与沐曦补推理插件后端、昆仑芯补位码与融合算子。这类工作不出标题，但决定 2.3 能不能按统一镜像铺到各家。2.3.0 的观察点仍是标签与全后端 changelog 是否同步补齐。

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

1.1 组织节奏：18 仓推送、185 笔提交、133 笔合入，在审积压升至 225 笔（10-26 ~ 10-27）

日期：2026-10-26 ~ 2026-10-27　来源：flagos-ai 组织仓库 · 提交检索 · 合并 PR 检索

  • 仓库面：61 仓中 18 仓窗口内有推送，数量为近一周最多。按提交量依次为 FlagQuantum 109、FlagGems 28、FlagGems-sglang 14、FlagSparse 7、FlagGems-vllm 5、Torch-FL 5、build-infra 5、vllm-plugin-FL 2、FlagTrain 2、FlagCV 2，其余 FlagBLAS、sglang-plugin-FL、optest、FlagCX、FlagPrism、FlagTree 各 1 笔。
  • 合入面：合并 PR 133 笔，分仓为 FlagGems 49、FlagQuantum 47、FlagGems-sglang 6、Torch-FL 5、build-infra 5、FlagGems-vllm 5、FlagTree 4、sglang-plugin-FL 2、vllm-plugin-FL 2、FlagTrain 2，FlagCV、FlagSparse、FlagBLAS、FlagCX、FlagPrism、optest 各 1 笔。
  • 在审面：窗口内有更新的 open PR 225 笔，其中新开 74 笔；新开分布为 FlagGems 36、FlagTree 8、FlagQuantum 7、vllm-plugin-FL 5、FlagTrain 4，FlagGems-vllm、FlagAttention、FlagGems-sglang 各 3 笔。
  • 日均对比：窗口 24 小时，提交 185 笔（上一 24 小时窗口 135 笔，增 37%）、合入 133 笔（163 笔，降 18%）、在审 225 笔（183 笔，增 23%）、新开 74 笔（90 笔，降 18%）、推送仓库 18 个（16 个）。
  • 版本面：31 仓 Release 与 Tag 原子核查，仅 FlagTree 新增一个标签 0.7.1a1+mthreads3.6（10-26 10:13），releases 列表无对应 Release 条目，属纯 Tag 事件；其余仓库零新增。
  • 事件面：org 事件流 100 条，PR 事件 49、推送 20、建分支 10、删分支 7、评审 3、评论 9、关注 1、Issue 1。
  • 判断：提交增、合入减、在审增，三者同向说明队列在积压而非在清。积压主要来自 FlagGems（49 笔合入，同时 52 笔在审）与 FlagTree（4 笔合入，9 笔在审）——这两个仓库都在为 2.3 的编译器与算子版本做准备，评审带宽成为当前瓶颈。

1.2 运行时 2.3.0：vllm 应用获重建授权、统一标签落定，新增 AMD ROCm 7.2.4 基础镜像（10-26）

日期：2026-10-26　来源：build-infra PR #1488 · PR #1504 · PR #1502 · PR #1505

  • 重建授权（#1488）：为二十个 vllm0.24.0 应用 changelog 补上待发布条目（含原因、日期留空），满足推送时 changelog 门禁后才允许重建应用镜像。原因是运行时已于 10-25 刷新到 2.3.0 栈，其上构建的应用镜像全部过期。条目逐条说明应用镜像现在携带什么：运行时的两个容器启动参数、按后端钉住版本的 flagcx 0.14.0、以及 venv 前缀。
  • 标签收敛：同一 PR 的第二个提交把原生插件标签从镜像标签里移出，改由一个统一的解析器决定，从而让 2.3.0-0.3.0 这个不带后端后缀的统一标签成立；第三个提交在 changelog 与 schema 头里声明 reason 字段按 markdown 发布，多条变更可按列表读。
  • 新增后端（#1504）：AMD ROCm 7.2.4 基础镜像落地，后端键 amd-rocm7.2.4，底座为 Ubuntu 24.04 加 repo.radeon.com 直装的 ROCm 7.2.4，不走文件仓。只装 28 个精干包，apt 解析运行时依赖后合计 94 个；MIOpen、MIGraphX、rocm-gdb、rocprofiler-sdk、opencl 明确排除。演练中发现两个必须写进 Containerfile 的事实：amd 节点到不了 archive.ubuntu.com，必须在 ca-certificates 存在之前就切阿里云 HTTP 镜像（走 HTTPS 会握手失败）；pin 文件不是版本偏好而是必需项。
  • 清障两笔：22:27 的 #1502 让原生插件门禁在同一解释器内跑完，22:45 的 #1503 把 vllm 插件标签从 sglang 的文档页里移出，#1505 改成打印标签实际携带的插件 pin 而不是后端标签。
  • 判断：这一轮的动作全部落在「可发布性」上——门禁、留痕、标签形态、基础镜像。与 10-25 的运行时重建授权连起来看，2.3.0 的管道已经从头到尾跑通一遍，只差正式打标签与全后端镜像批量重出。AMD 后端新增意味着后端矩阵在 2.3 周期还在扩张，而不是收敛。

1.3 达摩院玄铁：FlagBLAS 一次性补齐 15 组 BLAS1 算子，一万六千行落库（10-26）

日期：2026-10-26　来源：FlagBLAS PR #154 · FlagBLAS 提交

  • 规模：单笔 PR 改动 17 个文件、新增 16,168 行、删除 9 行，合入时间为 10-26 08:57，是当日非量子仓里体量最大的一笔。
  • 覆盖：一次补齐 BLAS 第一层十五组算子——向量最值与求和（AMAX、AMIN、ASUM）、向量累加与拷贝（AXPY、COPY）、点积三类（DOT、DOTC、DOTU）、欧氏范数（NRM2）、平面旋转四类（ROT、ROTG、ROTM、ROTMG）、向量缩放与交换（SCAL、SWAP）。
  • 层面：这是数值库层面的补齐而非推理算子补齐。BLAS1 是上层 BLAS2 与 BLAS3、以及 LAPACK 求解器的前置依赖，缺一层就无法自底向上自洽；对玄铁而言，此前在 FlagOS 里的存在感集中在推理路径（真武 Express 版、稀疏注意力），数值库是空档。
  • 链路：该 PR 在上一期日报中仍记为在审，本窗口完成合入，从「在审」到「落库」跨了一个窗口。
  • 判断：一家后端在 FlagOS 里的成熟度，通常按「能跑推理、能跑训练、数值库自洽」三段衡量。玄铁本窗口跨到第三段的第一级台阶，后续看 BLAS2 与 BLAS3 是否跟进，以及 FP8 路径（FlagTrain 侧在审的 fp8 GEMM 有玄铁分支）能否共用同一套数值库。

1.4 FlagGems：49 笔合入，KernelGen 算子批次与昆仑芯 XPU3 融合提速并行（10-26）

日期：2026-10-26　来源：FlagGems 提交 · PR #7676 · PR #7635 · PR #7669

  • 总量：28 笔提交、49 笔合入，提交量居全组织第二，合入量居第一。合入数高于提交检索数，原因是合并提交与压缩提交的口径差异，以合入数为准。
  • KernelGen 批次：以 KernelGen 加 Nvidia 为前缀的算子合入 16 笔，集中在 10:41 至 10:43、18:17 至 18:20、23:05 至 23:06 三个时段：稀疏与结构化相关（_sparse_semi_structured_tile、_sparse_mm_reduce_impl、sparse_compressed_tensor）、量化相关（choose_qparams_per_tensor、make_per_tensor_quantized_tensor）、特殊函数（special_psi、special_scaled_modified_bessel_k0）、张量元信息（_version、_nested_compute_contiguous_strides_offsets、ravel、new_zeros），另有 _foreach 算子族的验收提速一笔。
  • 昆仑芯提速：XPU3 侧改动五笔——addmm_ 把 GEMM 直写进原地目标（#7676）、less_equal 改用对 NaN 安全的比较（#7688）、isfinite 内核优化（#7631），以及 foreach 三笔（三元标量融合、div 走更快的 List 内核、log 融合去掩码）。这一组是典型的后端调优，改动小、收益局部。
  • 缺陷修复：QC 侧修 FP8 TopK 的 TLE scatter 寻址（#7669），昆仑芯侧修 logical_and 与注册错误（#7666、#7670）。
  • 测试侧：同一贡献者批量合入二十余笔测试契约修复（候选入口点、原生参考注入、重载选择、foreach 前置失败），把大量「测试自己坏掉」的用例从失败里摘出来。
  • 判断：算子供给仍以 KernelGen 自动生成的批次为主，人工介入主要发生在后端调优与测试契约两侧。这种结构推导出的质量风险不是「算子写错」，而是「测试覆盖看似齐全、实则参考实现缺失」——本窗口二十余笔测试修复正是这个风险的显性化。

1.5 FlagQuantum：109 笔提交、47 笔合入，Quafu SDK 切换收尾与固定 shots 契约（10-26）

日期：2026-10-26　来源：FlagQuantum 提交 · PR #874 · PR #919 · PR #924

  • 总量：109 笔提交、47 笔合入，提交占全组织 58.9%、合入占 35.3%，仍是第一活跃仓，但相对上一期（72 小时 505 笔）日均已回落至约三分之一。
  • Quafu 切换收尾：完成只读 SDK 切换（#874）、把动态 mock 收敛到 Quafu SDK（#880）、提出动态格式激活与来源审计（#881、#883），并在示例侧把远程执行的 mock 全部改道。这是上一期「生命周期整体切换」的收尾段。
  • Rydberg 路线：以受种子的 presence 计划执行（#879）、演化选定的 Rydberg 分支（#875）、验收记录落文档（#882），从契约转为可运行路径。
  • 纠错码（QEC）：固定 shots 实验的设计稿与契约稿先后合入（#912、#924），通道构造模板复用提速（#877），原生产阶段交接与独立失败闭环留痕（#917），AI 解码交付进度两次对齐（#890、#895）。
  • API 与示例：iSWAP 门对加入（#919），Circuit 与 DynamicCircuit 的门链改为带类型的流畅接口（#913），门覆盖 Batch A 提案（#915），吸收式光子计数示例加验收（#921），固定热浴中的 spin-mode 模型拟合示例（#897），Twin 候选与人工门控演化周期（#923、#926）。
  • 判断：量子栈的节奏从「结构重整」转入「物理场景铺开」——纠错码、中性原子、热浴三类场景同期推进，每类都按「设计稿、契约稿、可运行示例、验收记录」四段留证。这种作业方式成本高、可核查性好，也解释了它为什么长期占据大部分提交量。

1.6 FlagCV：首个定位说明合入，Triton 视觉算子库对外成形（10-26）

日期：2026-10-26　来源：FlagCV · FlagCV PR #2

  • 定位：FlagCV 自述为「以 Triton 实现的高性能计算机视觉库」，在 OpenCV 形状的接口下提供常用图像处理原语——色彩转换、滤波、几何变换、算术运算，并以 OpenCV 的 CUDA 基线为对标，目标是在多种 GPU 架构上达到参考级正确性与有竞争力的性能。
  • 依赖关系：构建在 FlagTree 之上（FlagOS 维护的 Triton 分支，支持多硬件后端），对外提供与厂商无关的算子接口，后端可插拔。
  • 时间线：仓库于 10-14 建立（当时仅有占位），10-18 落骨架并撤掉算子实现改为「即时模式骨架」，10-26 合入 About 与 README 说明。即代码骨架在前、定位说明在后，本窗口补的是「这个仓到底做什么」。
  • 判断：视觉是 FlagOS 体系里原先最薄的一块——既有 FlagDNN、FlagSparse、FlagFFT、FlagBLAS，但没有图像处理原语层。FlagCV 把视觉接在 FlagTree 而非另起一套编译器上，方向与「一次开发、多芯运行」一致；真正的检验点是色彩转换与几何变换这类访存密集算子在非 GPU 后端（NPU、DSA）上的表现，目前尚无性能数据。

1.7 FlagTrain：KMCompiler 一支铺到七家后端，五笔在审（10-26）

日期：2026-10-26　来源：FlagTrain PR #29 · PR #30 · PR #35 · PR #18

  • 合入两笔：#29 加入 fused_indices_to_multihot 的 Triton 实现，覆盖英伟达与昇腾，H20 上有基准记录；#30 把 FlagGems-vllm 的基线对照机制移植过来，按设备瓶颈单位的峰值缩放系数归一化速度比，输出「vs Base」列，缺基线时记录原因而不失败，并新增 lamb 基线与逐算子汇总工具。
  • 在审五笔：#34 tanh_soft_clamp（英伟达、昇腾、海光、玄铁、沐曦、天数）、#35 multi_tensor_adam（英伟达、海光、沐曦、地平线 PPU、天数）、#18 fp8_gemm（英伟达、昇腾、玄铁、沐曦）、#10 mixed_gemm（英伟达）、#28 fused_proj_rms_compute_h_fwd（英伟达）。
  • 结构特征：单笔 PR 的标题里直接列出后端清单，是 FlagTrain 这一支的固定写法——一个算子按后端矩阵一次铺开，而不是按后端逐个提交。七家后端（英伟达、昇腾、海光、玄铁、沐曦、天数、地平线）在同一批 PR 里出现。
  • 判断：FlagTrain 在 2.3 周期明显加速，且集中在训练侧的优化器、MoE 与量化 GEMM 三类算子。它与 FlagGems（推理算子）形成分工，两家都在用 KernelGen 生成 Triton 实现、再按后端补齐；差别是 FlagTrain 更依赖跨后端一致性，因此其 PR 的验收门槛也更高，五笔同时在审并不意外。

1.8 其余仓库：FlagTree 打 MThreads 专用标签，optest 合并十三支厂商检查脚本（10-26）

日期：2026-10-26　来源：FlagTree tags · FlagTree PR #1410 · optest PR #11 · FlagGems-sglang PR #227

  • FlagTree：10-26 10:13 打出标签 0.7.1a1+mthreads3.6，指向 0.7.x 线的 MThreads 专用构建，releases 列表无对应 Release 条目，属纯 Tag 事件；后端侧的实质改动来自 10-23 的 #1416（MTHREADS 后端跟到上游提交）。窗口内合入四笔：FlagMega 重新推断 Qwen3 vLLM profile 的切片类型（#1373）、HCU 后端支持 set_layout（#1410）、ROCm 经 HIP 主机注册接口加载 source-rdata（#1403）、池化 ABI 的 bank 行索引按 tl 值传递（#1404）。
  • optest：合入把十三支按厂商分开的 GPU 检查脚本统一成一条 flagos-gpu-check 命令（#11），按「厂商专有设备节点优先、SMI 命令二次确认」的顺序自动探测，并保留各厂商原有的逐卡表格、超时与重试参数；厂商冲突规则写明「海光先于 AMD（两者都有 kfd，只有海光有 mkfd）」「玄铁先于英伟达」。
  • FlagGems-sglang：6 笔合入，含竞赛赛道算子两笔（add3、create_chunked_prefix_cache_kv_indices）、一批 batch8 算子、去掉崩溃的分组内核两笔、导入期读设备信息的修复；#227 把目录里缺登记的 16 个算子补进 operators.yaml。
  • FlagSparse、FlagPrism、FlagCX：FlagSparse 7 笔提交并合入来自外部组织的整批优化（#114）；FlagPrism 合入燧原侧 tops 头文件与库依赖解析（#17，2,126 行）；FlagCX 合入昆仑芯 XPU 设备位码构建（#676）。
  • 判断：这一组里最值得记的是 optest 的合并——测试设施从「每家一段脚本」变成「一条自动探测命令」，是多后端规模化之后必然会走到的一步。厂商顺序里的两条冲突规则（海光对 AMD、玄铁对英伟达）说明设备探测这件事在异构环境里已不能靠单一信号判断。

二、新闻报道与生态

2.1 清微智能：Open3D-PIMC 从开源首发走到三十国师资课堂（10-26）

日期：2026-10-26　来源：金融界（搜狐转载）：从技术大会到 30 国课堂 · 新华网：Open3D-PIMC 补齐国产算力软件生态关键拼图

  • 项目：Open3D-PIMC 由清微智能与北京智源人工智能研究院联合开发，是面向 3D 算力芯片的编程模型与开源软件框架，9 月在中国算力大会正式开源，被定位为众智 FlagOS 面向下一代 3D 芯片的主要解决方案之一。
  • 技术路径：开发者只描述数据分布与任务划分，框架自动完成图编译与即时执行的划分和调用，进而把模型适配到硬件；生长在 PyTorch 等主流生态上，推理侧原生对接 vLLM 与 SGLang；Flash Decoding、MoE 这类强动态算子保留手写优化入口；各厂商私有指令集与微架构能力以插件形式接入。
  • 硬件背景：清微第二代高性能云端 AI 芯片以 3D 存算一体与多芯粒合封把存储与计算立体堆叠，数据搬运距离从毫米级压到微米级，延迟从集中式架构的非确定、易冲突变为近存侧的可预期、确定性。
  • 本期进展：10-26 的报道聚焦生态推广而非代码——全球「AI 开放计算师资发展计划」把清微工程师送进课堂，学员为来自三十多个国家的近五十位高校骨干教师（非洲二十余位、亚洲十有余位，其余来自欧洲与南美）。
  • 口径说明：文中「FlagOS 已适配 20 家芯片厂商、30 余款 AI 芯片」为报道方口径，与 10 月开放计算大会上官方给出的 21 厂商、35 芯片不完全一致，引用时以前者归属报道、后者归属大会为宜。
  • 判断：这条的价值不在「又一个开源发布」，而在它展示了 FlagOS 生态的一条新路径——先由一个成员单位牵头做出面向新硬件形态（3D 堆叠）的编程模型，再挂进 FlagOS 作为解决方案。与「模型 Day-0 适配」相比，这是「硬件形态先行」的另一类扩张。

2.2 沐曦：RLinf 全栈适配合入官方主线，千卡完成 SFT 到 RL 后训练验证（10-26）

日期：2026-10-26　来源：同花顺财经转载沐曦股份官微 · 沐曦官网新闻中心

  • 事件：沐曦股份完成面向具身智能的大规模强化学习框架 RLinf 的全栈适配，适配方案合入 RLinf 官方主线，开发者无需改代码即可在沐曦 GPU 上运行 RLinf 的训练任务。
  • 框架背景：RLinf 由清华大学与无问芯穹联合北京中关村学院等机构推出，定位为首个面向具身智能的「仿训推一体化」大规模强化学习框架，成果被 OSDI、RSS、NeurIPS 等会议收录。
  • 验证规模：基于曦云 C 系列 GPU 集群，完成 512 卡与 1024 卡（128 节点乘 8 卡）两档 SFT，Pi0.5 模型在 RoboTwin 数据集上训练；四组任务成功率全部对齐或超过论文报告值，其中一组高 8.8 个百分点；多机扩展线性度保持在 97% 以上。
  • 接入方式：按插件模式四层对齐——加速器抽象层新增设备管理器并注册进 RLinf 注册表、用环境变量控制多卡可见性并与 Ray 调度协同、通信默认走沐曦集合通信库 MCCL、软件栈基于 MXMACA 的 PyTorch 与 FlashAttention 支持 BF16 与 FSDP。
  • 路线说明：沐曦称此为「上游优先」战略的延续，此前已合入 LMCache 与 ms-swift 的官方主线。
  • 判断：此事不属 FlagOS 组件发布，应记作成员单位的开源生态动作。值得注意的是方向——具身智能的强化学习训练栈，与 FlagOS 侧的 FlagOS-Robo、FlagScale 训练工具在场景上重叠，未来是否出现「成员单位先合入上游框架、再由 FlagOS 收口统一后端」的接力，是值得跟的线索。

2.3 渠道核查：12 条候选 2 条有效，CSDN 专栏与 HN 均无新命中（10-27）

日期：2026-10-27　来源：Google News RSS · CSDN FlagOS 专栏 · HN Algolia

  • 新闻侧：24 组中英文查询词窗口内共 12 条候选，2 条有效（清微 Open3D-PIMC、沐曦 RLinf）。组件名查询（FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen）全部零命中，与近两周常态一致。
  • 剔除明细：燧原科技相关 4 条为融资融券、早报与上市回顾类稿件（该公司实际于 9 月 11 日已在科创板挂牌，10-26 的「今日上市」标题属转载稿，不予采用）；摩尔线程 1 条为股价与成交额；智源与北京日报社 GEOInflow 2 条属媒体技术合作，与 FlagOS 无关；国产算力厂商全景复盘 1 条为行业综述。
  • HN 侧：8 组查询（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）4 天窗口内共 34 条命中，无标题直接匹配。
  • CSDN 侧：专栏页 51 条文章链接，最新资讯稿仍是 8 月下旬（GLM-5.3-Flash 九芯、Qwen3.8-Flash-Next 八芯、LightX2V 接入），窗口内唯一的新日期是 10-22 的高校圆桌直播页，无新稿。
  • 智源社区：搜索页为客户端渲染，仅得框架页，本期未取用。
  • 判断：新闻面连续第三个窗口只有成员单位通稿。FlagOS 自身对外发声的节奏与代码节奏明显不同步——代码在填后端，传播在等下一个模型或版本节点。

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

3.1 达摩院玄铁：BLAS1 整批落库，fp8 GEMM 的玄铁分支仍在审（10-26）

日期：2026-10-26　来源：FlagBLAS PR #154 · FlagTrain PR #18 · optest PR #11

  • FlagBLAS：十五组 BLAS1 算子一次合入，17 文件、16,168 行，是玄铁在 FlagOS 数值库层面的首次成建制提交。
  • FlagTrain：在审的 fp8_gemm 覆盖英伟达、昇腾、玄铁、沐曦四家，玄铁是其中唯一的 RISC-V 向量路线；同批在审的 tanh_soft_clamp 也含玄铁。
  • 测试设施：optest 的厂商冲突规则把玄铁排在英伟达之前，理由是两者设备节点探测可能撞车；这条规则本身说明玄铁已在 CI 的真实机器池里。
  • 前情：10-23 至 10-25 窗口，玄铁完成了真武 Express 版交付与 PPU 稀疏注意力在审；本窗口转向数值库。
  • 判断：玄铁在 FlagOS 里的动作已连续三个窗口保持「一次一个整块」的节奏——推理、注意力、数值库。下一步看 BLAS2 与 BLAS3，以及 CPU 侧（optest 的 thead 厂商键）是否与加速卡侧共用同一套检查脚本。

3.2 昆仑芯：XPU3 侧三笔 foreach 融合、原地 GEMM 与位码构建（10-26）

日期：2026-10-26　来源：FlagGems PR #7676 · PR #7635 · FlagCX PR #676 · FlagCX PR #677

  • 算子侧：XPU3 上六笔改动，addmm_ 把 GEMM 直接写进原地目标免掉一次中转、less_equal 用对 NaN 安全的比较交换操作数、isfinite 内核优化、foreach 三笔融合（三元标量、div 的 List 内核、log 去掩码）。
  • 通信侧：FlagCX 合入昆仑芯 XPU 的设备位码构建（#676）——用 Makefile 把共享的设备 API 封装编成 xpu3 的 LLVM 位码，从 XTDK 卸载包里抽出设备模块、保留公共符号后优化，产出 libflagcx_device.bc 与消费侧头文件，通信 traits 走 XSHMEM。在审的 #677 修 flagcxGetVersion 对小于一万的版本码解码。
  • 修复面：FlagGems 修 logical_and 与注册错误两笔；在审四笔（cholesky_solve 的复数路径与上三角修复两笔、foreach_div 的 _result_dtype 本地化、批量算子依赖 FlagTree 当日构建）。
  • 判断：昆仑芯本期全部动作都在「把已有路径做快做稳」，没有新特性。这与它此前两周的形态一致——接入最早、覆盖最广，因此进入长尾调优阶段也最早。位码构建是个例外，它把昆仑芯接进了 FlagCX 的统一设备抽象，长期价值高于单算子提速。

3.3 沐曦：SGLang 插件新增 MetaX 后端整包，vLLM 侧三条模型适配在审（10-26）

日期：2026-10-26　来源：sglang-plugin-FL PR #50 · vllm-plugin-FL PR #642 · FlagGems-vllm PR #998

  • SGLang 后端：合入 31 文件、新增 3,364 行的 MetaX 与 MACA 后端包，含可用性探测、复用 CUDA 兼容实现并加沐曦侧包装（silu_and_mul、rms_norm、rotary_embedding、topk、fused_moe、FLA 门控 delta 规则等），并为 SGLang 内部加运行时补丁（FlashInfer 注意力后端兼容、MCCL 支撑的 PyNCCL 包装、采样后端行为、torchvision JPEG 解码回退），同时补 metax.yaml 派发配置与 Qwen3 27B、35B-A3B 示例脚本。
  • vLLM 侧在审：#642 把 TXDA 之外的调度路径调整到 vLLM 0.28.0（清微）、#635 加 Qwen3.8-Flash-Next 的 BF16 基线、#636 加 BGE-M3 初步适配。
  • 算子库：#998 在审修 FlashAttention 精度与图捕获问题并优化 TP2 与 TP4 性能；#1000 在审跳过原地 MoE 对齐中不支持的 TLE。
  • 生态侧：RLinf 主线合入（见 2.2），是其在具身智能方向的「上游优先」落地。
  • 判断：沐曦本期的重心从推理插件搬到 SGLang 后端整包与上游框架合入两条线上。SGLang 插件原先只有昇腾、海光、天数等几家，MetaX 加入后，推理框架侧的厂商矩阵基本补齐；接下来看 vLLM 0.28 升级是否与 SGLang 0.5.18 的节奏对齐。

3.4 清微：TXDA 后端随 vLLM 0.28.0 升级，FlagCX 打包纳入清微（10-26）

日期：2026-10-26　来源：vllm-plugin-FL PR #642 · FlagCX PR #673 · 金融界转载：Open3D-PIMC 生态推进

  • 插件侧：在审的 #642 把 TXDA 后端适配到 vLLM 0.28.0，属 2.3 周期里「插件随上游大版本走」的一批工作。
  • 打包侧：在审的 FlagCX #673 把 RPM 打包扩展到清微、曦望与海光三个后端，清微是其中之一。
  • 构建侧：10-22 已把清微 TX8 接进 FlagTree 构建器并挂上日常构建行，成为第六个后端；本窗口无新增构建改动。
  • 生态侧：Open3D-PIMC 的对外推广持续推进（见 2.1），并明确作为 FlagOS 面向下一代 3D 芯片的主要解决方案。
  • 判断：清微的形态与其他成员不同——它在 FlagOS 里既是后端（TX8、TXDA），又是新硬件形态的牵头方（3D 堆叠、Open3D-PIMC）。两条线目前没有在代码上交汇，若未来 Open3D-PIMC 的后端直接复用 FlagTree 的 TX8 路径，才算真正合流。

3.5 燧原、海光、天数、摩尔线程：四条后端各有一笔结构性改动（10-26）

日期：2026-10-26　来源：FlagPrism PR #17 · Torch-FL PR #654 · Torch-FL PR #660 · FlagTree tags

  • 燧原：FlagPrism 合入 tops 头文件与库依赖解析（#17，16 文件、2,126 行），把燧原 SDK 的头文件与库查找从隐式改为显式；FlagAttention 有一条燧原侧的融合注意力算子（fused_attnres）在审。
  • 海光：Torch-FL 修 DCU 运行时的构建源（#654）——DCU 的 runtime_dir 原先指向只放 ABI 垫片的目录，导致运行时库由 32 个桩链接而成，构建能过但一 import 就报未定义符号，改动 71 文件、1.1 万行；同日在审的 #627 为开启装箱的 DCU 构建接上真实流。
  • 天数：Torch-FL #660 修 Iluvatar 上 bf16 GEMM 退回主机执行的问题——2048 见方的 bf16 mm 实测 0.41 TFLOPS，低于同机 CPU 的 0.54，而同算子 fp16 为 80.2、厂商自带 torch 为 84.6；根因是支持判断未纳入 bf16 且 mm 与 addmm 在主机侧复制了转置权重。修完后走厂商 BLAS。
  • 摩尔线程：FlagTree 打出 MThreads 专用标签（0.7.1a1+mthreads3.6），FlagGems-vllm 合入 chunk_kda 的 MThreads 优化（#990），MUSA 后端的 TLE 缓存持久化改动上周已落。
  • 判断：四家的共同点是「修能跑但跑得慢或跑一半炸」的问题，而不是加新算子。这类缺陷最难在外部复现，也最能说明后端矩阵的真实完成度——厂商侧提交的仍以自家平台的正确性与性能为主，跨平台统一语义的工作仍靠 FlagOS 主干推动。

四、总结与趋势观察

  • 2.3.0 已走完一遍完整管道，标签仍未打出：运行时的门禁、changelog、重建授权、版本参数化在 10-23 至 10-25 就位，10-26 授权应用层重建并把标签收敛成 2.3.0-0.3.0。从「运行时刷新」到「应用跟版」这一步通常紧跟正式发布，本周仍是关键观察窗。
  • 后端矩阵在扩张而非收敛：AMD ROCm 7.2.4 基础镜像新增，说明 2.3 周期还在加平台。与之对应，玄铁补 BLAS1、清微接 RPM 打包、昆仑芯补设备位码——四件事分属数值库、打包、通信三个层面，都是「接进来之后才需要做」的工作。
  • 数值库与训练栈成为新战场：FlagBLAS 一次性补十五组 BLAS1 算子、FlagTrain 一批算子铺到七家后端，两条线都在 2.3 周期加速。推理算子的边际收益在下降（FlagGems 本期以 KernelGen 自动生成批次与后端调优为主），训练与数值库的缺口更明显。
  • 视觉方向首次成形，但缺性能证据：FlagCV 把定位写成「Triton 实现的 OpenCV 形状视觉算子库，对标 OpenCV CUDA 基线」，接在 FlagTree 上。目前只有说明与骨架，没有任何基准或非 GPU 后端数据，判断其价值为时尚早。
  • 评审带宽成为瓶颈：提交增 37%、在审增 23%、合入降 18%、新开降 18%。开发侧在积累，评审侧在消化。FlagGems 与 FlagTree 两个仓的在审量（52 与 9）与合入量（49 与 4）的落差最明显，而这两仓恰好是 2.3 的编译器与算子版本来源。
  • 量子栈进入场景铺开期：纠错码、中性原子、热浴三类物理场景同期推进，仍按四段留证作业。它继续占据全组织近六成提交，但相对上一期的日均已回落三分之二。
  • 信息面连续第三个窗口只有成员单位通稿：12 条候选 2 条有效，FlagOS 自身无版本发布、无新仓、无对外公告。内容主体仍来自 GitHub，属典型「代码在填后端、传播在等节点」的窗口。
  • 局限说明：提交检索为 GitHub search 的 total_count 口径（185 笔），与合并 PR 检索（133 笔）因压缩合并与索引延迟存在口径差，FlagGems 出现合入数（49）高于提交检索数（28）即属此类，报告内以合入数为准；FlagQuantum 的 109 笔含合并与分支同步提交，不等同于 109 个功能改动；FlagTree 的 0.7.1a1+mthreads3.6 经 Release 列表与 Tag 接口双向核对为纯 Tag，无 Release 说明；厂商通稿中的「无需改代码」「对齐或超过论文」等表述为公司口径，未取得第三方复现；清微稿件中「20 家厂商、30 余款芯片」与大会口径的 21 厂商、35 芯片不一致，已在正文标注归属。

附录：信源核查表与完整信源清单

信源核查表

信源 核查结果
GitHub 组织仓库 API 61 仓全量返回，18 仓 24 小时窗口内有推送
GitHub 提交检索 185 笔，按 URL 归仓 16 仓
GitHub 合并 PR 检索 133 笔窗口内合入，最强为 FlagGems 49 笔
GitHub 在审 PR 检索 225 笔窗口内更新，其中新开 74 笔
GitHub org 事件流 100 条，PR 49、推送 20、建分支 10、删分支 7、评论 9
Release 与 Tag 原子核查 31 仓中仅 FlagTree 新增一个标签，无 Release 条目
Tag 与 Release 交叉核对 0.7.1a1+mthreads3.6 经 releases 列表与 git ref 接口双向确认为纯 Tag
Atom 兜底 docs、release-info 两仓补查，主分支无窗口内提交，推送落在非默认分支
关键 PR 正文核查 15 笔逐笔核对标题、改动行数与合并时间
Google News RSS 24 组中英文查询 12 条候选，2 条有效（走代理）
HN Algolia 8 组查询 4 天 34 条命中，无标题直接匹配
CSDN FlagOS 专栏 51 条链接，最新资讯稿为 8 月下旬，窗口内无新稿
智源社区 搜索页客户端渲染，仅得框架页，本期未取用
成员单位通稿 清微、沐曦两家原稿取正文核对日期与口径
待收录队列 当日无本主题文件，未归档文件扫描亦无 FlagOS 小节

完整信源清单