调研窗口：2026-10-19 06:00 ~ 2026-10-20 06:00（北京时间，24 小时；周二晨报，窗口自上一期日报截点接续，不含大会期间内容）。

信源：GitHub（org: flagos-ai 61 仓库全量核查、提交检索 93 笔、合并 PR 88 笔与在审 PR 180 笔检索、16 个活跃仓 Release 与标签核查、org 事件流 100 条与分支级兜底）、Google News RSS（24 组中英文查询词，走代理）、HN Algolia（8 组）、中华网与存储在线技术稿、CSDN 与智源社区渠道核查（详见附录信源清单）。

本期索引

  • 今日重点：大会后首个完整工程日——93 笔提交、88 笔合入，build-infra 把昇腾四轮子、清微与曦望统一到 22.04 自包含 builder（glibc 底线由 2.38 降至 2.35）；FlagQuantum 以 405 文件合入 159 个新公开名并确立 M0 路线图；FlagBLAS 补齐海光 gfx936 六精度 GEMM；FlagDNN 直推 master 补天数 iluvatar 等价性能基线（10-19）
  • 一、开源项目进展（GitHub 动态）
    • 1.1 组织节奏：16 仓推送、93 笔提交、88 笔合入；glibc 底线下移成当日主线（10-19）
    • 1.2 build-infra：昇腾四轮子从 24.04 运行时迁入 22.04 自包含 builder，清微与曦望同日补齐（10-19）
    • 1.3 FlagQuantum：405 文件合入量子栈扩容，M0 至 M4 路线图确立（10-19）
    • 1.4 FlagGems：KernelGen 稀疏族批量在审，昆仑芯 XPU3 注意力族与昇腾 mm 分派并进（10-19 ~ 10-20）
    • 1.5 FlagBLAS：海光 gfx936 六精度 GEMM 合入，dgemm 依赖 FlagTree fp64 MMAC（10-19）
    • 1.6 FlagTree：燧原 GCU300 基线与 AMD RDNA 降级路径、昇腾 3.5 py312 交付（10-19）
    • 1.7 推理与训练栈：曦望与燧原图模式、HY4 H100 接入、昇腾 vLLM 0.28 升级（10-19）
    • 1.8 FlagDNN / FlagTrain / FlagSparse / Torch-FL：天数等价性能、摩尔线程后端、MUSA 优化（10-19）
  • 二、新闻报道与生态
    • 2.1 会后首篇深度技术稿：中华网刊出 FlagOS 2.2 全栈拆解，补充七个量化案例（10-19）
    • 2.2 报道扩散与渠道核查：存储在线演讲全文为 10-18 旧稿晚索引，CSDN 与智源社区无新增（10-19 ~ 10-20）
  • 三、成员单位深挖
    • 3.1 海光：FlagBLAS 六精度 GEMM 与 L1 支持同时落库（10-19）
    • 3.2 天数智芯：FlagDNN 等价性能基线直推 master，Torch-FL 拆出独立运行时（10-19）
    • 3.3 清微与曦望：两个后端同日进入 FlagCX 22.04 builder（10-19）
    • 3.4 燧原：GCU300 基线、vLLM 基准工作流与 builder 断言修正（10-19）
    • 3.5 摩尔线程、昇腾、达摩院玄铁：MUSA 算子线、CANN 9.0 基线、T-Head GRU 死锁修复（10-19）
  • 四、总结与趋势观察

今日重点：大会后第一个工程日，交付面的统一压过新功能（10-19）

日期：2026-10-19　来源：build-infra PR #1414 · FlagQuantum PR #635 · FlagBLAS PR #151 · FlagDNN commits（全量见附录）

  • 节奏面：24 小时窗口内 16 个仓库有推送、93 笔提交、88 笔合入、180 笔在审 PR 有更新。合入量高于上一期三日窗口的日均水平（约 46 笔/日），提交时间集中在 07:00 至 23:00，峰值落在 14:00 至 17:00，是典型的工作日节奏，未见大会期间的集中放量。
  • 主线是「交付面统一」而非新能力：build-infra 16 笔提交全部围绕制品通道——把昇腾四个轮子从 24.04 运行时镜像迁到独立的 ubuntu:22.04 自包含 builder（PR #1414），同日为曦望（PR #1418）与清微（PR #1422）补上同规格 builder。原因是 24.04 镜像里编出的 libflagcx.so / _C*.so 链到 GLIBC_2.38，在实际 22.04 物理机上直接中止；改用 22.04 builder 后 glibc 底线降到 2.35，与其余厂商行对齐。
  • 量子栈是当日最大单笔合入：FlagQuantum PR #635 以 405 个文件、+114463/−3983 的体量合入，新增 159 个公开名，覆盖算法（45→148）、量子纠错（84→108）、远程调用（20→32）、可观测量（12→20）、编译器（12→17），并新开 flagquantum.operators 包；能力注册表由 68 项增至 97 项，Stable Core 的 41 个导出保持不变。同日 PR #637 确立 M0 至 M4 路线图，把超导、中性原子、离子阱、光子与拓扑五类硬件纳入同一 Core IR 与编译器约束下。
  • 海光补齐 BLAS 主干：FlagBLAS PR #151 合入 gfx936 的六种精度 GEMM（sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm，+7060/−127），其中 dgemm 走 fp64 MMAC 点积内核、依赖 FlagTree 的 fp64 MMAC 支持；叠加 PR #149 的 Hygon L1 支持，海光通道从算子层延伸到基础线性代数层。
  • 天数侧是直推 master 的性能基线：FlagDNN 当日 4 笔提交全部直接落在 master（无 PR 流程），内容是 iluvatar 后端的等价性能基线（equivalent_baseline.cpp 等，+8157）与随后的两轮修正，同时清理了 ascend 后端的验证目录（−7047）。

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

1.1 组织节奏：16 仓推送、93 笔提交、88 笔合入（10-19）

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

  • 仓库面：61 仓中 16 仓窗口内有推送，按提交量依次为 FlagGems 23、FlagQuantum 23、build-infra 16、FlagBLAS 9、FlagTree 5、FlagDNN 4、FlagGems-vllm 3、vllm-plugin-FL 3、Torch-FL 2、FlagSparse 2、FlagCX 1、FlagTrain 1、FlagAttention 1。
  • 合入面：88 笔合入，分布为 FlagGems 36、build-infra 16、FlagQuantum 9、FlagTree 8、vllm-plugin-FL 6、FlagBLAS 3、FlagGems-vllm 3、Torch-FL 2，FlagCX / FlagTrain / FlagAttention / FlagSparse / TransformerEngine-FL 各 1。FlagGems 与 build-infra 合计占提交量的 42%、占合入量的 59%。
  • 在审面：窗口内有更新的 open PR 180 笔（接口返回前 100 条用于分仓统计），头部为 FlagGems 63、FlagGems-vllm 12、vllm-plugin-FL 5、Torch-FL 4、FlagCX 3、FlagTree 3、FlagGems-sglang 3。其中标题含 KernelGen 的 28 笔、含昆仑芯的 30 笔、含 sparse 的 8 笔，三条队列构成了当前的待消化主体。
  • 分支级兜底：docs 的推送落在 update/modelscope-docs-20261019-175239 分支（main 最新仍是 10-03）；Trident 的推送对应 PR #4「Monad 中间层」（master 最新 10-13）；FlagCV 自 10-19 凌晨的骨架合入后当日无新动作；FlagFFT、FlagScale、Megatron-LM-FL、FlagPrism、FlagAudio、FlagOps 七个仓库窗口内零推送。
  • 判断：大会两日（10-17 至 10-18）过后，组织没有出现「发布后停摆」，而是把产能立刻转回制品与基线。当日没有新版本发布（窗口内无 Release），也没有新仓库建立，属「无版本、重交付」的一天。

1.2 build-infra：昇腾四轮子迁入 22.04 自包含 builder，清微与曦望同日补齐（10-19）

日期：2026-10-19　来源：PR #1414 · PR #1418 · PR #1422 · PR #1417 · base 目录

  • 核心问题：昇腾的四个轮子原本在 24.04 运行时镜像里构建，产出的 libflagcx.so 与 _C*.so 链到 GLIBC_2.38，在 bundle 的 22.04 物理机上直接 abort。PR #1414 为每一行配置独立的 ubuntu:22.04 builder，与其它厂商行走同一通道，glibc 底线降到 2.35。
  • 一个配方服务四行：ascend.mk 只链 -ltorch_npu -lascendcl -lhccl，与具体芯片无关；但工具链本身不带这些链接期依赖，libhccl.so 与 <hccl/hccl.h> 来自芯片 ops 包，因此配方同时安装 toolkit 与 ops 包（不含 nnal/ATB），910b 与 910c 的差异通过 ops 安装器的芯片令牌（builder.ops_product，910b 与 A3）传入。
  • 验证口径：SDK 底线用 import torch_npu（会 dlopen CANN 工具链库）证明，而不是 import torch（该行上是纯 CPU）；ASCEND_OPP_PATH、ASCEND_AICPU_PATH、TOOLCHAIN_HOME、LD_LIBRARY_PATH 从 set_env.sh 落到 /etc/profile.d/vendor.sh，与轮子构建时 sourced 的是同一份文件。
  • 同日补齐两个新后端：曦望（PR #1418，sunrise wheel 的 22.04 自包含 builder，随后 PR #1420 记录该轮子以 22.04-clean 重发）与清微（PR #1422，tsingmicro wheel 的 22.04 自包含 builder）。至此 base/ 目录下的厂商矩阵为 nvidia（cuda12.8 / cuda13.3）、ascend（cann8.5.0 / cann9.0.0，含 910c）、cambricon（neuware4.4.3 / 4.7.2）、enflame（tops1.9.10 / 1.10.6）、hygon（dtk26.04）、iluvatar（corex4.4.0 / 4.5.0）、metax（maca3.7.2.1 / 3.8.1.3）、sunrise（tangrt1.2.0）、tsingmicro（tsm260610），共 9 家厂商。
  • FlagTree 侧三笔：PR #1417 加燧原 builder 并把验证步骤改成数据驱动；PR #1419 修掉「构建期断言燧原后端」的写法；PR #1421 把燧原 toolkit 的 deb 预置进 builder 镜像，减少每次构建的下载依赖。另有 PR #1410 把 pybind11 ABI 从实际发出的插件里读回、而不是写死字面量，PR #1413 让失败的 plan 直接让整个 run 失败而不是跳过构建。
  • 判断：这 16 笔没有一笔是功能开发，全部在消除「本机能编、目标机能跑」之间的缝隙。与 10-16 至 10-18 的六后端 22.04 收口连起来看，FlagCX 的制品通道已从「逐个后端打补丁」过渡到「一行一个后端、同一套 22.04 配方」。

1.3 FlagQuantum：405 文件合入量子栈扩容，M0 路线图确立（10-19）

日期：2026-10-19　来源：PR #635 · PR #637 · PR #642 · 仓库

  • 规模：23 笔提交、9 笔合入，是当日提交量并列第一的仓库。PR #635 单笔 405 个文件、+114463/−3983，新增 159 个公开名：算法包由 45 增至 148、量子纠错由 84 增至 108、远程调用由 20 增至 32、可观测量由 12 增至 20、编译器由 12 增至 17、模拟由 8 增至 11，并新开 flagquantum.operators 包（4 个导出）。能力注册表由 68 项增至 97 项，其中 development_evidence 由 20 增至 47。
  • 边界纪律：所有新名都是子包入口，Stable Core 的 flagquantum.__all__ 仍为 41 个导出、与 main 字节一致；PR 正文明确「提升到 Stable Core 走独立提案路径」，同时新增三份契约文件（编译器 pass 准入、多级 IR 内部接口、real-time 消息）。
  • 路线图：PR #637 确立 M0 至 M4 的分阶段范围、依赖与验收标准，要求复用现有 Core IR、编译器、动力学求解器、运行时与 PyTorch 集成，覆盖超导、中性原子、离子阱、光子与拓扑五类硬件；M1 从混合维状态空间起步。同一 PR 还修正了收缩高斯重叠积分的精度问题（改用 math.fsum 处理相消敏感求和，并补一条原始基序回归）。
  • 动力学与编译器：PR #639 支持混合维状态空间，PR #640 支持显式截断的玻色算子，PR #641 支持静态算子和的系数训练，PR #642 允许调用方按名字在两个优化点注入自有 pass。另有 10 余笔测试与文档提交把数值断言改成「按精度重复性比较」，而非按固定字面量比较。
  • 判断：量子栈正在从「框架雏形」走向「通用量子计算框架」——PR #635 补的是覆盖面（纠错、化学、实时调用、超算子），PR #637 补的是边界与阶段。两者同日合入，意味着 M0 的起点是把已有能力写清楚，而不是先扩 API。

1.4 FlagGems：KernelGen 稀疏族批量在审，昆仑芯 XPU3 注意力族与昇腾 mm 分派并进（10-19 ~ 10-20）

日期：2026-10-19 ~ 2026-10-20　来源：PR #7260 · PR #7239 · PR #7203 · 在审 PR 列表

  • 合入侧：23 笔提交、36 笔合入。KernelGen 线继续按 ATen 清单补齐并进入稀疏与视图语义：_adaptive_avg_pool3d（#7172）、fft_ifftshift（#7171）、ccol_indices_copy（#6775）、_coalesce（#7096）、_neg_view_copy（#7088）合入；同时 PR #7260 一次性迁移 185 个 Q4 算子测试套件。
  • 在审侧：10-19 23:00 至 10-20 05:00 之间新增约 20 笔 KernelGen 提交，集中在稀疏族——_sparse_mm（#7289）、_sparse_mm_reduce_impl（#7298）、_sparse_mm_reduce_impl_backward（#7303）、_sparse_addmm（#7277）、copy_sparse_to_sparse_（#7231）、resize_as_sparse_（#7255）、_convert_indices_from_coo_to_csr（#7297）、_convert_indices_from_csr_to_coo（#7296）、_indices（#7293）、ccol_indices（#7295）等。稀疏族一次铺开，说明主干稠密算子已接近清仓。
  • 昆仑芯：合入侧有 XPU3 的 conv1d/conv2d/conv_depthwise2d（#7109）、chunk_gated_delta_rule_fwd（#7104）、dropout 与 mhc_post 性能（#7113）、take_along_dim 与 te_rmsnorm_bwd（#7089）、softmax_out 的 tle.gpu 融合路径（#6897）、baddbmm/copy_ 失败与 tile_size 32768 挂死修复（#7245）；在审侧有 30 笔，含注意力族（#7275，前向分块、varlen KV 融合、反向参考）、lstm（#7105）、rnn_relu（#7110）、cholesky_solve（#7103）、linalg_lu_factor（#7273）。
  • 昇腾与海光：昇腾 mm 形状分派与 Triton tiling 优化（#7239）、reference 契约与精度跳过修正（#7286、#7287、#7253）、int_repr 参考适配（#7253）；海光 hygon_mv 超时修复（#6584）。三条线都是「先让测试站住、再谈性能」的顺序。
  • 其他后端：达摩院玄铁后端的 GRU barrier 死锁修复（#7203）与 sparse QSA 的 16 行最小 tile（#940，FlagGems-vllm）；摩尔线程 KMCompiler 线的 linear 权重以 trans_b 送入 WS SQMMA（#7261）、rnn_tanh 启用 musa（#7256）；PPU 容器资源上限在三仓同步恢复（#7254、#942、#101）。
  • 基准侧：--base-data 支持外部 NVIDIA 基线对比（#7219），修掉 metadata-only 算子的计时错误（#7283）、嵌套张量与描述符的报表问题（#7276），并清理过时的 reference 装饰器（#7271）。当日 36 笔合入里约四分之一是测量与报表修正，这与「跨芯性能 +27.6%」这类对外口径需要的可复现性直接相关。

1.5 FlagBLAS：海光 gfx936 六精度 GEMM 合入（10-19）

日期：2026-10-19　来源：PR #151 · PR #149 · 仓库

  • 主体：PR #151 合入海光 gfx936 的厂商专用 GEMM 内核，覆盖 sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm 六种精度（+7060/−127，23 个文件）。hgemm/cgemm/zgemm 走独立 Triton 内核与按形状分档的配置，配 ctypes 调 hipBLAS 的参考实现与不依赖 cupy 的测试；dgemm 走 fp64 MMAC 点积内核；bfgemm 带调优池、TN 三路策略与 padding 路径。
  • 依赖关系：dgemm 明确依赖 FlagTree 的 fp64 MMAC 支持——BLAS 的精度补齐把编译器侧的能力缺口暴露了出来，这是跨仓协同的一处实证。
  • 配套：同日 PR #149 合入 Hygon L1 支持并补齐 L1 基准形状，另有 sgemm 单笔（#91）与注释英文化、移除 ABS 算子等整理提交；仓库窗口内 9 笔提交、3 笔合入，是当日提交量第四的仓库。
  • 判断：FlagBLAS 此前只有 v0.3.0（09-28）一轮发布，日常提交不多；单日九笔、六精度齐上，是海光通道在 FlagOS 2.2 之后第一次成体系的投入。

1.6 FlagTree：燧原 GCU300 基线与 AMD RDNA 降级路径、昇腾 3.5 py312 交付（10-19）

日期：2026-10-19　来源：PR #1363 · PR #1397 · PR #1396 · 仓库

  • CI 与基线：燧原 enflame3.6-gcu300 的 FlagGems 基线与测试工作流（#1397）、燧原 vLLM 基准进工作流（#1334）、AMD amd3.6 的 FlagGems 基线与测试工作流（#1399）；昇腾 3.5 py312 交付工作流（#1396）与随后的修复（#1398）；triton_v3.5.x 分支的 codeowner 更新（#1406）。
  • 编译能力：FlagMega 侧把 TLE 的 pipe、warp_specialize、distributed_barrier 降到 AMD RDNA（#1363），并为便携解码路径补 nvidia-sm89（Ada）目标（#1362）。前者是方言下沉到消费级 AMD 显卡，后者是把原本绑在 Hopper 上的解码路径前移到 Ada。
  • 判断：FlagTree 的当日工作几乎全在「后端 × 版本 × 工作流」三维矩阵上铺格子，5 笔提交、8 笔合入没有一笔改核心 IR。这与 1.2 的 builder 收口是同一件事的两面：制品与 CI 先行，语言层等矩阵稳定后再动。

1.7 推理与训练栈：曦望与燧原图模式、HY4 H100 接入、昇腾 vLLM 0.28 升级（10-19）

日期：2026-10-19　来源：PR #569 · PR #578 · PR #453 · 仓库

  • 图模式两条：曦望 Sunrise 的图模式（#569）与燧原 GCU300 的图模式（#578，inductor + cudagraph）同日合入，意味着 vLLM 侧的 CUDA Graph 通路开始在两个国产后端上落地，而非只在昇腾/昆仑芯上验证。
  • 芯片接入：HY4 H100 的 FlagOS 支持（#453）合入；分支管理上把 0.4.0-dev 前向同步到 0.5.0-dev（#612），并由 CI 自动创建这类同步 PR（#609）。
  • 版本线：达摩院玄铁后端升级到 vLLM 0.28.0（#574）；在审侧有「把 opt-in 的 FlagGems-vllm 算子移植到 vLLM 0.28」（#613）、昇腾全解码图与 Qwen3.6（#606）、MetaX C550 上 Hy4-preview 的图模式调研（#614）。
  • 训练侧：TransformerEngine-FL 合入 CICD 平台矩阵过滤、ci-complete 门禁、受限重试与 /ci 命令（#137）；Torch-FL 合入 CI 行覆盖率上报与 MetaX 上报修正（#587），并在审「统一 FlagCICD 入口，支持 L0 至 L2」（#599）。
  • 判断：推理栈这一天的关键词是「图模式铺开 + 版本线跟进」。图模式是性能兑现的前置条件，vLLM 0.28 是版本债的偿还，两者都在为下一轮对外性能数字做准备。

1.8 FlagDNN / FlagTrain / FlagSparse / Torch-FL：天数等价性能、摩尔线程后端、MUSA 优化（10-19）

日期：2026-10-19　来源：FlagDNN 提交 · FlagTrain PR #20 · FlagSparse PR #113 · Torch-FL PR #593

  • FlagDNN：4 笔提交全部直推 master——先加 iluvatar 的等价性能基线（equivalent_baseline.cpp、equivalent_runner.hpp 等，+8157），随后两轮修正（含 hygon 基准契约与 pre-commit 调整），并清理 ascend 验证目录（−7047）。该仓当日无 PR 流程，属维护者直接推送。
  • FlagTrain：合入摩尔线程后端与两个算子的支持（#20）。该仓 10-15 才有首版文档，10-14 起连续补 packbits、unpackbits、evoformer_attn，是当前最年轻的算子仓。
  • FlagSparse：合入 MUSA 优化（#113，来自 NCIC-AlphaSparse 分支），窗口内 2 笔提交、1 笔合入。稀疏库的厂商投入目前集中在摩尔线程一条线上。
  • Torch-FL：合入「给 iluvatar 独立运行时，使轮子链接 CPU 版 torch」（#593）与 CI 覆盖率上报（#587）；在审有 Iluvatar BI-V150 构建测试行（#569）、统一 FlagCICD 入口（#599）、取消被取代的 PR 与分支运行（#588）。
  • 判断：四个仓的共同点是「为某一家的后端补上可测量的基线」——天数要等价性能、摩尔线程要后端入口、稀疏库要 MUSA 路径、Torch-FL 要能装到没有 GPU 驱动的机器上。这类工作不出现在对外口径里，但决定了下一版性能表能不能覆盖到这些芯片。

二、新闻报道与生态

2.1 会后首篇深度技术稿：中华网刊出 FlagOS 2.2 全栈拆解（10-19）

日期：2026-10-19　来源：中华网技术稿 · 网易转载

  • 性质：这是大会（10-17 至 10-18）之后第一篇带完整技术细节的媒体稿，10-19 17:56 发布，非演讲速记，按「算子与编译、辅助研发、插件与量化、Token 服务、端侧与平台」五段组织，含 8 张架构图与 3 张性能表。
  • 新增的量化事实（上一期日报未覆盖）：KernelGen 已支持九款 AI 芯片，本季度新增生成 765 个算子，其中 416 个在至少 5 款国产芯片上通过精度验证并达到原生算子 80% 以上性能；FlagGems-SGLang 的 40 个算子在 NVIDIA 上全部通过；针对 Qwen3.8-Flash-Next 新增 8 个融合算子并完成 CUDA Graph 完整入图。
  • 量化工具的真实案例：FlagOS-Compressor 在 Qwen3.5-397B-A17B 上采用 W8A8 后模型文件由 751.41GB 降至 382.45GB（减少 49.1%），GPQA-Diamond 绝对准确率 84.85%，完成 NVIDIA H20 与国产 PPU 两条推理链验证；Qwen3.8-2.4T-A95B 上给出 BF16、FP8 到 INT8 的处理路径。
  • Token 服务的分场景数字：DeepSeek V4.1 Flash 在 H100（1P1D、W4A16/FP8）上 32 路与 64 路并发的每请求解码速度分别提升 19.7% 与 18.0%；达摩院玄铁 810E（每节点 16 张 96GB、W8A8）24 路与 48 路并发分别提升 83.1% 与 91.5%。GLM-5.3-Flash 的逻辑服务吞吐由 8.52k 提升至 17.36k tokens/s（2.04 倍）；512K 长上下文的生成速度 60.9 tokens/s，为官方 API 外部测量参考值 61.1 的 99.7%；按 8 卡 910B 月租 16,500 元测算，256K 输入/8 并发的每百万输出 Token 租金折算成本 59.27 元、较商业 API 计费参考低 19.4%，512K 输入/4 并发为 104.53 元、低 27.6%。
  • 生态与平台侧：生态成员单位 107 家，第三季度社区下载 464,336 次、为第二季度的 4.76 倍，新增伙伴含凌川科技、中国电子、润开鸿、中国电信、NXP、壁仞科技、跨维智能、聆思科技；中国电信星辰大模型在训练侧把 FlagGems 接入 MindSpore + CANN + 昇腾 NPU 体系，mHC、TopK 等训练算子完成端到端验证，MindFormers 集成工作已开源合入，推理侧 Xing4.0-29B-A4B 完成十款芯片平台适配（其中苹果 M5 Pro 与此芯 P1 走 W4A8 端侧量化），12 个推理算子开源至 FlagGems 与 vLLM 主仓；软通动力天元智算混合云在四台昇腾 910C 上优化 GLM-5.2，五项改动全部启用后 p50 ITL 降低 14.53%、服务端 p99 ITL 由 83.82ms 降至 66.35ms（−20.84%）。
  • 判断：这篇稿的意义不在数字多少，而在于它把 2.2 的收益拆成「可复核的单个案例」——每个数字都带模型名、芯片型号、并发数与对照基准。此前两期日报的 2.2 口径以主论坛的四组汇总指标为主，这一篇补上了分组证据。

2.2 报道扩散与渠道核查：存储在线演讲全文为 10-18 旧稿晚索引，CSDN 与智源社区无新增（10-19 ~ 10-20）

日期：2026-10-19 ~ 2026-10-20　来源：存储在线稿 · CSDN DAMO 开发者矩阵 · 智源社区

  • 晚索引识别：Google News 于 10-19 17:09 收录存储在线的《林咏华：众智FlagOS 2.2发布，token经济正走向物理AI》，但原页标注日期为 2026-10-18，内容为主论坛演讲全文整理，与上一期日报引用的 DOIT 现场报道同源。按收录规则不重复计为新增条目，仅登记为扩散。
  • 组件名直查仍为零：FlagOS、FlagGems、FlagScale、FlagTree、FlagPerf、FlagCX、KernelGen 七组组件名在 24 小时窗口内依旧零命中，这是连续多个窗口的同一结论；命中集中在「智源研究院 开源 / 芯片」「国产算力 开源软件栈」等宽泛词上，14 条候选里 12 条为资本与行情稿（新股发行统计、工博会获奖、融资快讯、办公 Agent 报告），按标题语义剔除。
  • 渠道核查：CSDN 的 FlagOS 专栏与 DAMO 开发者矩阵窗口内未见新文（最新为 10-12 的全日程预告，10-17 至 10-18 的分论坛直播页仍标注「回放中」）；智源社区首页与站内检索无 FlagOS 相关条目；HN Algolia 八组查询无直接命中，返回结果均为同名词误匹配。大会分论坛的逐场纪要截至窗口截止仍未公开。
  • 判断：新闻侧进入「会后消化期」——主论坛内容由媒体二次加工，分论坛与工作坊内容尚未成稿。对日报而言，本期新闻面有效条目为 1 条（2.1），主体信息量仍在 GitHub 侧。

三、成员单位深挖

3.1 海光：FlagBLAS 六精度 GEMM 与 L1 支持同时落库（10-19）

日期：2026-10-19　来源：FlagBLAS PR #151 · PR #149 · FlagGems PR #6584

  • 动作：PR #151 合入 gfx936 的 sgemm、hgemm、bfgemm、dgemm、cgemm、zgemm 六精度内核，PR #149 合入 L1 支持，两笔同日进入 master；FlagGems 侧修掉 hygon_mv 的超时问题（#6584）。
  • 技术取向：BF16 走调优池 + TN 三路策略 + padding 路径并附性能报告，FP64 走 MMAC 点积内核，半精度与复数走独立 Triton 内核 + 按形状分档配置，参考实现改用 ctypes 调 hipBLAS 而不是 cupy——说明测试环境刻意不依赖 CUDA 生态。
  • 缺口：dgemm 依赖 FlagTree 的 fp64 MMAC 支持，编译器侧能力是否已进主线，需要看后续 FlagTree 的 MMAC 提交；当前只能确认依赖关系已在 PR 中写明。
  • 判断：海光此前的 FlagOS 投入以构建通道与设备接口（/dev/itrctl）为主，进入 BLAS 主干意味着它开始在「性能可被基准直接度量」的层面上加码。

3.2 天数智芯：FlagDNN 等价性能基线直推 master，Torch-FL 拆出独立运行时（10-19）

日期：2026-10-19　来源：FlagDNN 提交 · Torch-FL PR #593 · build-infra PR #1409

  • FlagDNN：四笔直推 master 的提交全部围绕 iluvatar——新增等价性能基线（+8157）、两轮修正、以及 backends/iluvatar/dispatch/pointwise.py 与 kernels/activation_backward.py、kernels/binary.py 的实现调整。同一批提交里还包含 hygon 基准契约的修正与 ascend 验证目录的清理（−7047）。
  • Torch-FL：PR #593 给 iluvatar 独立运行时，使轮子链接 CPU 版 torch——即在天数机器上无需 CUDA 运行时也能装；配套在审 Iluvatar BI-V150 的构建与测试行（#569）。
  • 构建侧：build-infra 的 PR #1409 把 iluvatar 的 pin 日期刷新到 22.04 重发版本，PR #1420 同批记录 sunrise 轮子以 22.04-clean 重发。
  • 判断：天数这一天的三处动作指向同一目标——把「能在天数卡上跑」变成「能在天数的标准环境里被自动构建、自动测、自动出等价性能」。等价性能基线是该目标最后一块。

3.3 清微与曦望：两个后端同日进入 FlagCX 22.04 builder（10-19）

日期：2026-10-19　来源：build-infra PR #1422 · PR #1418 · PR #1420

  • 清微（tsingmicro）：PR #1422 为 tsm260610 轮子加 22.04 自包含 builder；FlagGems 侧同日出现 bump-flagtree-tsm 分支（10-19 15:31 建立），指向 FlagTree 的清微版本升级。base 镜像 tsingmicro-tsm260610 已在矩阵内。
  • 曦望（sunrise）：PR #1418 为 tangrt1.2.0 轮子加 22.04 自包含 builder 并建立 flagcx-builder-sunrise 分支（10-19 17:57），PR #1420 随后记录该轮子以 22.04-clean 重发。
  • 意义：两家都不在 FlagOS 2.2 的 21 家芯片厂商口径的前排叙事里，但制品通道已经按同一规格接入——这通常意味着适配工作已过「能不能跑」，进入「能不能稳定交付」。
  • 未证实项：窗口内未见这两家的独立 Release 或对外新闻，本条仅有 GitHub 侧证据。

3.4 燧原：GCU300 基线、vLLM 基准工作流与 builder 断言修正（10-19）

日期：2026-10-19　来源：FlagTree PR #1397 · PR #1334 · build-infra PR #1417 · vllm-plugin-FL PR #578

  • CI 三笔：FlagTree 加 enflame3.6-gcu300 的 FlagGems 基线与测试工作流（#1397）、把燧原 vLLM 基准加进工作流（#1334）；build-infra 加燧原 builder 并把验证步骤改成数据驱动（#1417），同时修掉「构建期断言燧原后端」（#1419）、把 toolkit deb 预置进镜像（#1421）。
  • 运行时一笔：vllm-plugin-FL 的 GCU300 图模式（#578）合入，启用 inductor + cudagraph。
  • 判断：燧原当日的六笔动作覆盖「基线、基准、打包、断言、图模式」五个环节，是单家成员单位里链条最完整的一组。GCU300 的图模式落地，也解释了为什么 build-infra 要在同日修掉构建期断言——图模式的编译路径对后端声明更敏感。

3.5 摩尔线程、昇腾、达摩院玄铁：MUSA 算子线、CANN 9.0 基线、T-Head GRU 死锁修复（10-19）

日期：2026-10-19　来源：FlagGems PR #7261 · PR #7203 · FlagTrain PR #20 · FlagSparse PR #113 · build-infra base

  • 摩尔线程：FlagGems 的 KMCompiler 线把 linear 权重以 trans_b 送入 WS SQMMA（#7261），rnn_tanh 测试启用 musa（#7256）；FlagTrain 加 mthreads 后端与两个算子（#20）；FlagSparse 合入 MUSA 优化（#113）。三条线构成 MUSA 的当日全部动作。
  • 昇腾：build-infra 的 base/ 下同时存在 ascend-cann8.5.0 与 ascend-cann9.0.0（各含 910c 变体），四个轮子的 builder 统一到 22.04（#1414）；FlagGems 侧 mm 形状分派与 Triton tiling 优化（#7239）、reference 契约修正（#7286、#7287、#7253）；FlagTree 的 3.5 py312 交付工作流（#1396、#1398）；vllm-plugin-FL 的昇腾全解码图仍在审（#606）。
  • 达摩院玄铁：FlagGems 修掉 T-Head 后端的 GRU barrier 死锁（#7203），FlagGems-vllm 把 sparse QSA 的最小 tile 提到 16 行（#940），vllm-plugin-FL 把玄铁后端升到 vLLM 0.28.0（#574）。三条线分别对应正确性、性能下限与版本跟进。
  • 判断：三家当日的共同点是「修边界」而不是「加新能力」——MUSA 在补后端入口，昇腾在补交付与测试契约，玄铁在补并发正确性。这类修复不会出现在对外性能口径里，但决定了多芯基线能不能横向比较。

四、总结与趋势观察

  • 趋势一：制品通道的统一先于功能扩张。build-infra 单日 16 笔提交、16 笔合入，全部围绕 22.04 自包含 builder；昇腾四轮子、曦望、清微在同一天被拉进同一套配方，base/ 目录形成 9 家厂商 17 个基线镜像的矩阵。glibc 底线由 2.38 降到 2.35 这件事，比任何一个新算子都更直接地决定「轮子能不能装到用户的机器上」。这一线索与 10-16 至 10-18 的六后端收口连成完整链条，可视为 FlagOS 2.2 发布后的第一个系统性补课。
  • 趋势二：量子栈从框架雏形转入通用框架的边界定义。FlagQuantum 单日 405 文件、159 个新公开名合入，同时以 M0 至 M4 路线图明确五类硬件的复用前提，并保持 Stable Core 的 41 个导出不变。这种「扩子包、锁核心」的做法，与 10-18 量智云发布时把 FlagQuantum 作为技术底稿的定位一致——对外讲能力之前，先把哪些是稳定接口写清楚。
  • 趋势三：国产算力侧的投入正在从「算子」走向「基准与基础库」。海光在 FlagBLAS 补齐六精度 GEMM 与 L1 支持；天数在 FlagDNN 补等价性能基线并直推 master；燧原在 FlagTree 铺 GCU300 基线与 vLLM 基准工作流；摩尔线程同时动 FlagGems、FlagTrain、FlagSparse 三条线。共同点是都可被基准直接度量，而非仅「支持某算子」。
  • 趋势四：KernelGen 进入稀疏与视图语义的扫尾段。合入侧的 _coalesce、ccol_indices_copy、_neg_view_copy 与在审侧十余笔稀疏算子（_sparse_mm 族、coo/csr 索引互转、copy_sparse_to_sparse_）说明稠密主干已基本清仓；同时昆仑芯以 30 笔在审构成单一后端最大队列，XPU3 的注意力族与 RNN 族是下一批要合入的主体。
  • 趋势五：新闻面进入会后消化期，信息重心回到仓库。24 小时窗口内有效新闻 1 条（中华网 10-19 的技术拆解，补七个量化案例），组件名直查连续零命中，分论坛纪要与工作坊内容尚未成稿。按经验，这类窗口后的一到两天通常会出现分论坛的二次报道，可作为下一期的观察点。
  • 下一期关注：一是 FlagQuantum 的 feat/m0-common-foundation 分支（10-19 16:47 建立）何时落 PR；二是 FlagGems 那批稀疏内核在审队列的合入节奏；三是 build-infra 是否把「一行一个后端」的配方复制到 FlagTree 与 Torch-FL 的制品线；四是大会分论坛纪要是否公开。

完整信源清单

信源核查表

信源 核查结果
GitHub org flagos-ai 61 仓全量核查，16 仓窗口内推送，93 笔提交、88 笔合入
GitHub Release / 标签 16 个活跃仓逐一核查，窗口内无新 Release
GitHub 在审 PR 180 笔窗口内更新，前 100 条分仓统计（FlagGems 63、FlagGems-vllm 12 居前）
Google News RSS 24 组中英文查询，窗口内 14 条候选，有效 1 条（中华网 10-19 技术稿）；组件名直查零命中，另 1 条为存储在线演讲全文的晚索引（页面日期 10-18），其余 12 条为资本、行情与同名误匹配
HN Algolia 8 组查询无直接命中，返回为同名词误匹配
中华网 / 网易 1 条有效（10-19 17:56 技术拆解），补七个量化案例
存储在线 1 条晚索引（页面日期 10-18，演讲全文），不重复计入
CSDN FlagOS 专栏 / DAMO 无窗口内新文，分论坛直播页仍标注回放中
智源社区 首页与站内检索无 FlagOS 相关条目
大会官网议程页 议程无变更，未见纪要或演讲实录公开