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

信源：GitHub（org: flagos-ai 61 仓库全量核查、提交检索 189 笔、合并 PR 183 笔与在审 PR 253 笔检索、org 事件流 100 条、31 仓 Release/Tag 原子核查、5 仓原子补核与分支核对、关键 PR 正文与产物规模核查）、Google News RSS（24 组中英文查询词，走代理）、HN Algolia（8 组）、CSDN FlagOS 专栏（文章与直播条目逐页核时）、智源社区、八家成员单位官网（详见附录信源清单）。

本期索引

  • 今日重点：海光 DTK 26.10 三线接入（容器、编译、通信）；MiniCPM-OCR 双模型 Day0 覆盖 12 平台；测试基建 ref-as-candidate 双仓落地（10-29）
  • 一、开源项目进展（GitHub 动态）
    • 1.1 组织节奏：21 仓推送、189 笔提交、183 笔合入，在审 253 笔（10-29 ~ 10-30）
    • 1.2 版本面：FlagTree 打出清微 3.6 专号，FlagCX v0.14.1 由标签转 wheel 线（10-29）
    • 1.3 FlagGems：KernelGen 单日合入 22 个算子，昆仑芯 XPU3 foreach 融合收官（10-29）
    • 1.4 测试基建：ref-as-candidate 双仓落地，单日 57 笔测试 PR 收口（10-29）
    • 1.5 推理与训练栈：GLM-5.3-Flash 与 Qwen3.8-Flash 双模型进插件（10-29）
    • 1.6 编译与通信：摩尔线程常驻 GEMM 与 SPMC 进主线，FlagCX 补两家设备接口（10-29）
    • 1.7 构建与发布：海光 DTK 26.10 八笔合入、昇腾 rpm 目标与 2.3.0 镜像描述（10-29）
    • 1.8 量子线：FlagQuantum 六十笔提交，CS-01 至 CS-07 合成流水线贯通（10-29）
    • 1.9 其余仓库：OpenCourse 教材重组，FlagScale 与 TransformerEngine-FL 收敛 CI（10-29）
  • 二、新闻报道与生态
    • 2.1 MiniCPM-OCR 双模型 Day0 适配 12 平台，达摩院玄铁吞吐达原生 98.7%（10-29）
    • 2.2 CSDN 技术直播：一个插件打通十款芯片的推理适配（10-29）
    • 2.3 渠道核查：HN 与智源社区无新命中，CSDN 专栏新增一稿一直播（10-29）
  • 三、成员单位与后端厂商深挖
    • 3.1 海光：DTK 26.10 从容器到 wheel 的全链落地（10-29）
    • 3.2 清微：Triton 3.6 后端同步合入并打出专用标签（10-29）
    • 3.3 昆仑芯：XPU3 的 foreach 融合链与常量网格收尾（10-29）
    • 3.4 沐曦：分组 GEMM 的 INT8 与 FP8 路径、TP2 解码调度（10-29）
    • 3.5 摩尔线程：TLE 常驻 GEMM 与 SPMC 同步进主线（10-29）
    • 3.6 燧原、昇腾、达摩院玄铁：注意力与归一化算子的四条线（10-29）
    • 3.7 天数：天垓 300 首次实机演示对外，单卡吞吐宣称 1.05 倍 H200（10-28）
  • 四、总结与趋势观察
  • 附录：信源核查表与完整信源清单

今日重点：海光 DTK 26.10 三线接入（容器、编译、通信）；MiniCPM-OCR 双模型 Day0 覆盖 12 平台；测试基建 ref-as-candidate 双仓落地（10-29）

日期：2026-10-29　来源：build-infra PR #1554 · build-infra PR #1562 · build-infra PR #1563 · MiniCPM-OCR Day0 适配 · FlagGems PR #7630 · FlagGems-sglang PR #249（全量见附录）

  • 构建面：海光 DTK 26.10 在单日内走完八笔合入——基础容器（#1554，加 78 行）、运行时配置（#1555，加 21 行）、可用性修复（#1558，为 /opt/dtk 指向 dtk-26.10 并补 runner 覆盖）、FlagTree 的 cp312 hcu 构建器（#1562，4 文件加 342 行）、FlagCX 的 dtk2610 wheel 线（#1563，3 文件加 185 行）、基础镜像补 libopenmpi3t64（#1564）、构建器补 libopenmpi3（#1565）、把 hcu-dtk2610 加进 FlagTree wheel 发布线（#1566）。这是本栈首次为新一版厂商 SDK 同时改容器、编译器构建器与通信库打包三条线，原因是 DTK 26.10 把运行时钉在 python 3.12 与 torch==2.13.0+dtk2610（仅 cp312），既有 cp310 的 hcu wheel 在该运行时里根本解析不到。
  • 新闻面：众智 FlagOS 社区为面壁智能与 OpenBMB 开源的 MiniCPM-OCR 1.0（1.3B）与 MiniCPM-OCR Jev（2B）做 Day0 跨芯适配，覆盖达摩院玄铁、英伟达、华为昇腾、海光、昆仑芯、沐曦、摩尔线程、清微智能、天数智芯、曦望、Mac（ARM）与此芯科技共 12 个平台。评测给出的口径是归一化到硬件峰值算力后的吞吐：Jev 在达摩院玄铁上的实际计算吞吐达英伟达原生的 98.7%，OCR 1.0 的单位峰值算力 P50 吞吐在单文档场景达英伟达原生的 169.3%、批量场景 137.1%。
  • 测试面：FlagGems 的 --ref-as-candidate 与显式 get_candidate 选择进主线（#7630，9 文件），FlagGems-sglang 同日以 #239 至 #249 十一笔把全部正确性套件改到 get_candidate，并加入每日 master 到 kernelgen-dev 的自动同步 PR。两仓合起来的效果是：参考实现可以不带外部候选文件直接充当候选跑通，测试不再是「有没有算子」的开关，而是「参考与实现是否一致」的比较。
  • 判断：三条线指向同一件事——软件栈的瓶颈正从「把算子写出来」转到「把新 SDK 的构建假设、把参考实现的执行路径、把模型的跨芯可比性」这三类工程纪律固定下来。DTK 26.10 的八笔合入说明硬件代际切换的成本几乎全部落在打包与依赖解析上，而不是内核本身；MiniCPM-OCR 的评测则第一次给出归一化吞吐与端侧时延两组可比数字。

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

1.1 组织节奏：21 仓推送、189 笔提交、183 笔合入，在审 253 笔（10-29 ~ 10-30）

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

  • 仓库面：61 仓中 21 仓窗口内有推送（上一期 23 仓）。按推送时间从近到远为 FlagGems、Torch-FL、FlagGems-sglang、FlagQuantum、vllm-plugin-FL、FlagQAI、FlagTree、FlagScale、OpenCourse、build-infra、FlagCX、FlagGems-vllm、FlagSparse、release-info、docs、optest、FlagTrain、FlagOps、FlagFFT、FlagAttention、TransformerEngine-FL。
  • 提交面：提交检索命中 189 笔，为近两周最高（上一期 99 笔），分仓为 FlagQuantum 60、FlagGems 43、build-infra 15、FlagGems-sglang 14、FlagQAI 11、FlagGems-vllm 9、FlagAttention 8、Torch-FL 6、FlagTree 5、FlagTrain 4，vllm-plugin-FL、FlagCX、OpenCourse 各 3，optest、FlagOps 各 2，FlagScale 1。FlagQuantum 与 FlagGems 两仓占去 103 笔。
  • 合入面：合并 PR 183 笔（上一期 67 笔，增 1.7 倍），分仓为 FlagGems 92、build-infra 16、FlagQuantum 15、FlagGems-sglang 11、FlagGems-vllm 9、FlagAttention 8、Torch-FL 6、FlagTree 5、vllm-plugin-FL 4、FlagQAI 4、FlagCX 4、FlagTrain 4、optest 2，FlagScale、FlagOps、TransformerEngine-FL 各 1。
  • 在审面：窗口内有更新的在审 PR 253 笔（上一期 288 笔），新开 84 笔（上一期 101 笔）。FlagGems 129、FlagTree 22、FlagGems-vllm 15、vllm-plugin-FL 10、Megatron-LM-FL 10、FlagTrain 9、FlagAttention 8、FlagScale 7、sglang-plugin-FL 6、Torch-FL 5、FlagGems-sglang 5、flir 5、FlagCX 4、docs 4，其余各仓 1 至 2 笔。
  • 节奏对比：与上一 24 小时窗口（23 仓、99 笔提交、67 笔合入、288 笔在审）相比，推送仓减 2 个、提交增 91%、合入增 173%、在审降 12%、新开降 17%。合入量的跳变主要来自 FlagGems 的算子上量（92 笔）与 FlagQuantum 的合成流水线（15 笔），不是评审口径放松——同期在审总量仍在下降。
  • 版本与事件面：31 仓 Release 与 Tag 原子核查，窗口内新增标签一个（FlagTree 的清微 3.6 专号，10-29 11:09）；FlagCX v0.14.1 的档案时间前移到 10-29 10:55，与 #683 回摘到 0.14.0-rc2 的合入时间同刻。org 事件流 100 条：PR 评审评论 34、PR 事件 34、推送 13、建分支 8、议题评论 9、删除分支 1、fork 1，构成比上一期（推送 51、建分支 32）明显转向评审活动，与合入量的上升一致。
  • 分支面：提交检索未覆盖的 5 个推送仓经原子补核——TransformerEngine-FL 有窗口内提交一笔（#142 的 FlagCICD v1，10-29 09:51）；FlagFFT 的推送落在 codex/musa-shortfall 特性分支（10-28 多次推送，默认分支最新提交仍在 10-15）；release-info 的推送在 gh-pages 分支（发布站点自动发布）；docs 与 FlagSparse 属 PR 分支与议题评论活动，默认分支无新提交。

1.2 版本面：FlagTree 打出清微 3.6 专号，FlagCX v0.14.1 由标签转 wheel 线（10-29）

日期：2026-10-29　来源：FlagTree 清微 3.6 专号标签 · FlagTree PR #1459 · build-infra PR #1553 · build-infra PR #1556 · build-infra PR #1563

  • FlagTree 标签：10-29 11:09 打出清微 3.6 专号，与 10-26 的摩尔线程 3.6 专号属同一条「按厂商切分的 3.6 预发布线」。该标签在 Releases API 无发布正文（返回 404），说明它是标签档案而非带说明的 Release；同日合入的 #1459 正是清微后端向内部 Triton 3.6 开发线同步的那一笔。
  • FlagCX 交付面：v0.14.1 在上一窗口以 git 标签形式出现（无 Release 正文），本窗口被正式登记进 build-infra 的 wheel 目录——机器人记录发布（#1553），人工补齐五条空壳描述并加入 flagcx==0.14.1+rocm7.2.4 这一 AMD 行（#1556，10 文件加 28 行减 16 行），再把 hygon-dtk26.10 这条线钉到 flagcx==0.14.1+dtk2610（#1563）。至此 0.14.1 的交付面覆盖 cuda12.8、cuda13.3、corex4.4.0、corex4.5.0、xre5.37.1、rocm7.2.4 与新增的 dtk2610。
  • Issue 驱动的修复：FlagTree #1481 针对议题 #1473 修 Metax 上 CompiledKernel 的元数据检查（1 文件，加 2 行减 1 行）；FlagGems #7989 修昇腾 cat 算子（加 57 行减 36 行）；FlagTree #1468 与 #1470 为燧原补 CI 与 TLE 单测。
  • 待观：FlagTree 的 3.6 线以「每厂商一个标签」的方式推进，0.7.1a1 尚无统一发布说明；若 2.3 周期按此线交付，下游需要从标签名反推后端与 Triton 版本，和 FlagCX v0.14.1 缺正文是同一类问题。

1.3 FlagGems：KernelGen 单日合入 22 个算子，昆仑芯 XPU3 foreach 融合收官（10-29）

日期：2026-10-29　来源：FlagGems PR 列表 · PR #7116 · PR #6950 · PR #6530 · PR #7989

  • KernelGen 面：92 笔合入中有 22 笔为 [KernelGen][Nvidia] 自动生成算子，覆盖稀疏张量（sparse_csc_tensor_unsafe、sparse_bsc_tensor_unsafe、sparse_resize_）、卷积与池化（nnpack_spatial_convolution、thnn_conv2d、fractional_max_pool3d_backward、mkldnn_reorder_conv2d_weight）、线性代数（cholesky、frobenius_norm、chain_matmul）与一批边角算子（argwhere、_indices、make_dual_copy、flatten_dense_tensors、combinations、empty_per_channel_affine_quantized）。单日批量是该线近期最密的一次，同日又新开 #8009 至 #8013 五笔，队列仍在延续。
  • 昆仑芯面：XPU3 的 foreach 融合链在一天内收口——cos/exp/sin/addcdiv/lerp 的 List 执行器（#7116）、ceil 的无掩码融合内核（#7604）、tanh/expm1 的原地融合内核（#7608）；随后是四笔正确性修复：fmin 改常量发射网格（#7966）、t_copy 一维路径同样改常量网格（#7973）、foreach 标量 dtype 分支改为互斥（#7974）、foreach add 的列表槽位改由 program_id(0) 取（#7968）。euclidean_dist、is_same_size、layer_norm_backward 也做了 XPU 优化（#7907）。
  • 沐曦面：新增 INT8 与 FP8 的 grouped_mm_w8a8（#6950，7 文件加 1220 行）。基准用 GLM-5.2 在 PPU SGLang TP=8 上采集的真实调用形态回放到 MetaX C550——28 条场景记录、26 组唯一 (M,N,K,E) 几何、324 万次调用、257 个专家。
  • 其余：AMD W7900（gfx1100）的算子精度修复（#6530）；昇腾 log_ 网格填充重跑的厂商本地实现回摘到 5.4.0-rc2（#6586）；CI 侧修导入顺序（#7951）、发布构建从被移除的 cp38 换到 cp310（#7975）、厂商名改为随运行时版本（#7961）、FP8 MM 测试改为按已注册后端跳过（#7812）。
  • 判断：算子上量已由 KernelGen 承担，人工投入集中在两类事上——新后端的发射参数正确性（昆仑芯四笔）与测试可执行性（见 1.4）。这解释了为什么 92 笔合入里几乎没有主干语义变更。

1.4 测试基建：ref-as-candidate 双仓落地，单日 57 笔测试 PR 收口（10-29）

日期：2026-10-29　来源：FlagGems PR #7630 · FlagGems-sglang PR #239 · FlagGems-sglang PR #241 · FlagGems-sglang PR #249 · FlagGems-sglang PR #242

  • 机制：--ref-as-candidate 让正确性测试与基准可以把显式声明的参考实现当作候选来跑（get_candidate("negative", reference=torch.negative)），不再依赖外部候选文件。缺参考、参考不可调用、测试体未实际调用候选都会显式失败；跳过与 xfail 不能掩盖契约错误，全跳过不计为有效执行。验证为 26 项宿主回归加 32 项针对 master 与 PR 合并预览的检查。
  • 落地范围：FlagGems-sglang 同日 11 笔把全部正确性套件改到 get_candidate（#241）、补齐参考声明（#240、#244）、加基准用例列举与回放（#239）、加 definitions 目录与 silu_and_mul 示例（#245）、补 mrotary_embedding 候选比较与可移植参考及跨设备原生校验（#247、#249）。
  • 规模：单日 57 笔由同一作者提交的测试修复合入（多为各后端的引用契约、夹具与基准入口修正），覆盖昇腾、沐曦（MUSA）、燧原、昆仑芯与英伟达的跳过条件与参考 ABI。
  • 自动化：新增每日 master 到 kernelgen-dev 的自动同步 PR（#242），当日机器人已产生两笔同步（#243、#246）。这条链把「上游主干」与「KernelGen 开发线」的漂移从人工 rebase 变成每日一次可审计的合并。
  • 判断：测试从「跑得过」转向「可比」之后，测试本身开始需要参考实现的契约；这也是本日 57 笔修复的真实内容——不是补测试，而是补参考。

1.5 推理与训练栈：GLM-5.3-Flash 与 Qwen3.8-Flash 双模型进插件（10-29）

日期：2026-10-29 ~ 2026-10-30　来源：vllm-plugin-FL PR #455 · vllm-plugin-FL PR #454 · vllm-plugin-FL PR #615 · FlagTrain PR #35 · FlagGems-vllm PR #1025

  • Qwen3.8-Flash：vllm-plugin-FL 加 Qwen3.8-Flash-Next 与 Qwen4 的检查点加载与模型集成（#455，65 文件加 11226 行减 109 行），含 HC、PLE、QSA 与多模态接线，数值算子走 FlagGems-vllm。FP8 采用能力门控：平台原生支持则保留原生内核（英伟达要求计算能力 8.9 以上，AMD 交给 vLLM 的 ROCm 实现判断），不支持时回落到 BF16 线性与 MoE 路径并强制 --dtype bfloat16。
  • GLM-5.3-Flash：次日凌晨合入纯公开算子的实现（#454，90 文件加 19140 行减 280 行）。索引器精度先于缓存分配选定：英伟达 SM89 以上、摩尔线程 MP31 以上与 GCU capability 4 以上保留 FP8，其余厂商与未知能力用 BF16；BF16 的沐曦与昆仑芯因对应 radix 编译路径无法降级，改走既有 Torch TopK、scatter 与 sort 路径。
  • 运行面：原生 CUDA 的 vLLM 0.32 适配（#615，57 文件加 3408 行减 1044 行）把栈钉在 vLLM 0.32.0+cu129、PyTorch 2.13.0+cu129、CUDA 12.9 与 python 3.12.3 上，FlagGems 用 5.4.0 开发提交、FlagTree 用 0.7.0 开发提交（提供 Triton 3.6）；现有 NVIDIA CI 6 项推理与 3 项服务全过。
  • 训练面：FlagTrain 加 multi_tensor_adam（#35，6 文件加 1093 行），一次 Triton 发射批量完成多张量 Adam 更新，后端覆盖英伟达、海光、沐曦、PPU（达摩院玄铁）与天数；同窗口另有 fused_proj_rms 前反向（#38）、fast_gelu（#33）与 deepspeed 依赖（#42）。原始 H20 基准里，fp32 65536 元素档位相对 DeepSpeed CUDA 基线为 2.24 倍，1024 元素小档位反而慢到 0.76 倍。
  • 推理优化：FlagGems-vllm 侧，沐曦 TP2 packed decode 的 Split-KV 调度与计算 tile 重排（#1025）；FP8 W8A16 的门控增量网络加动态状态量化（#988）；MUSA 的 FP8 变长注意力按当前 CI 编译器重调（#970）；fused_q_kv_rmsnorm 同时在昇腾（#872）与达摩院玄铁（#888）落地。

1.6 编译与通信：摩尔线程常驻 GEMM 与 SPMC 进主线，FlagCX 补两家设备接口（10-29）

日期：2026-10-29　来源：FlagTree PR #1294 · FlagTree PR #1459 · FlagCX PR #678 · FlagCX PR #681 · FlagCX PR #679

  • 摩尔线程：[MThreads][TLE] 的常驻 GEMM 流水线与 SPMC 同步进主线（#1294，63 文件加 6192 行减 403 行）。该笔不是搬旧文件，而是基于当前 main 的 pipe、warp specialize 与 SQMMA 表示重迁，并把原先分两套的编译器（公共版供 addmm/baddbmm，SPMC 版供 bmm）合成一套超集：支持动态循环里的 stage 与 phase 推进、一生产者对多消费者、命名读与隐式读、分段完成与消费者纪元推导，以及单发、融合消费者与 16 warp 常驻路径。
  • 清微：后端同步到内部 Triton 3.6 开发线（#1459，27 文件加 2264 行减 407 行），只改 third_party/tsingmicro/——补回 FlagGems 侧的厂商算子分发所需的逐发射精度接口、外部 CoreIR 入口与运行时适配器，并修 Tx81 代码生成与 DMA、RDMA、WDMA 的 CRT 缺陷。
  • 昆仑芯：FlagCX 增加 XPU 的设备 IR 入口以支持 FlagTree 链接（#678，5 文件加 178 行减 21 行）。
  • 天数：FlagCX 的 Device API 后端补上 Atomic::load 的获取语义（#681，3 文件加 359 行减 37 行）。此前 load(..., Acquire) 与 load(..., Relaxed) 发射同一条指令，观察者在看到标志后没有失效屏障；本笔改为先读后栅栏、按作用域选强度，并补上 launchKernel 的地址空间符号与 getLastError 槽位。系统作用域仍未实现，因为 ivcore11 没有对应的内存屏障指令。
  • AMD：ROCm 上把 SGLang 的张量并行跑通（#679，6 文件加 77 行减 19 行）——补 eventElapsedTime 实现、把 torch.bool 映射到 flagcxUint8、加 USE_AMD 测试构建分支；R9700 双卡上 AllReduce、ReduceScatter、AllGather、Broadcast、Send/Recv 与图捕获的 AllReduce 结果正确，Qwen3.5-9B 与 Qwen3.6-35B-A3B-FP8 在 TP=2 下可服务。

1.7 构建与发布：海光 DTK 26.10 八笔合入、昇腾 rpm 目标与 2.3.0 镜像描述（10-29）

日期：2026-10-29　来源：build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1565 · build-infra PR #1566 · build-infra PR #1557 · build-infra PR #1560

  • DTK 26.10 全链：八笔合入的先后顺序本身就是一条排障链。首版容器与配置落地后（#1554、#1555），镜像仍不可构建也不可调度：#1558 指出 base/hygon-dtk26.10 仍把 /opt/dtk 指向 dtk-26.04，且 .github/build-config.yml 没有该条目的 runner 覆盖会落回 h20 默认值。随后 torch 2.13.0+dtk2610 的 libtorch_global_deps.so 直接链 libmpi.so.40 与 libibverbs.so.1，而 26.04 的 wheel 把这两个 soname 哈希进了包内，因此这条线需要基础镜像补 libopenmpi3t64（#1564）、构建器补 libopenmpi3（#1565）。
  • 版本线：同一运行时钉 python 3.12，导致既有 cp310 的 hcu wheel 无法解析；#1562 以 deadsnakes 3.12 重建 cp312 的 hcu 构建器并装入 DTK 26.10 的 Ubuntu22.04 SDK，#1566 再把 hcu-dtk2610 加进 wheel 发布线的目标选项，使 flagtree==0.7.0+hcu3.6 能以普通 flagtree 发布到海光源。
  • 昇腾 rpm：新增 FlagTree 的昇腾 rpm 目标（#1557，加 44 行减 4 行），编译对象是昇腾交付流水线产出的 cp311 与 aarch64 wheel，正好对应 openEuler 24.03 的 aarch64，因此只开一行；这也是首条不依赖厂商 SDK 与硬件的 rpm 线。
  • 2.3.0 迹象：运行时镜像描述在 09:44 与 18:26 两度刷新（#1552、#1561），changelog 日期按 hygon-dtk26.10 记账（#1560）。但 community 仓的 release/2.3/release-2.3.yaml 仍为 404，说明 2.3 的发布清单尚未建立，当前进度停在构建面。
  • 发布效率：另有 vllm 重打包依赖改走 PEP 503 页面解析（#1543）与 actions/setup-python 由 7.0.0 升到 7.1.0（#1550）。

1.8 量子线：FlagQuantum 六十笔提交，CS-01 至 CS-07 合成流水线贯通（10-29）

日期：2026-10-29　来源：FlagQuantum 仓库 · FlagQuantum PR #960 · FlagQuantum PR #964 · FlagQuantum PR #966 · FlagQuantum PR #967 · FlagQAI 仓库

  • 规模：FlagQuantum 一日 60 笔提交、15 笔合入，全部集中在同一条线上——量子电路合成（CS 系列）。仓库内 docs/roadmap/ 与 docs/api-changes/ 已按 FQ-SYNTH-CS01..CS07-20261029 归档十份规格与交付文档。
  • 流水线：CS-01 定义相干整数构造的语义边界与验证，CS-02 用纯算术内核降低相干加法，CS-03 处理乘法与相干多项式，CS-04 打通受限 Python 工作流，CS-05 加生命周期与工作区调度，CS-06 分三段（执行契约、候选代价选择、单用户工作流）落地，CS-07 进入寄存器语义与程序准入。同日还加入可移植 .fqx 实验文件的存载（#960）与 fq.run 的受检程序执行（#964）。
  • 在审：CS07-C 的受限原生 Qmod 前端（#967）在 17:30 开出，把只含一个输出的无符号 main 翻译到既有编译器的寄存器与表达式模型，不执行文本、不生成 Python 可调用对象、不选后端。
  • 配套 FlagQAI：同源的 FlagQAI（10-10 建仓）一日 11 笔提交、4 笔合入，加入本地量子工作台网页与原生 Agent 集成（#3）、刷新后保留跟随偏好的修复（#4）。仓内 README 明确把「由意图合成电路」列为产品方向而非已完成能力，当前验证范围只有本地电路模拟与一条固定拟设的两比特变分路径。
  • 判断：这条线在本栈里独立度最高——不做多芯适配，只做「把科学问题翻译成可执行电路」的中间层。它的价值在于给 2.x 周期提供一个与芯片无关的软件栈用例。

1.9 其余仓库：OpenCourse 教材重组，FlagScale 与 TransformerEngine-FL 收敛 CI（10-29）

日期：2026-10-29　来源：OpenCourse 提交 · FlagScale PR #1315 · TransformerEngine-FL PR #142 · optest PR #18 · FlagOps PR #18

  • OpenCourse：三笔提交做课程资源重组（17:07、19:59）与师资发展版目录改名（21:53），并加入实验主线（lab mainline）。这与社区持续推进的全球师资发展计划同一批次。
  • FlagScale：把测试策略、受影响路由与执行证据门统一到一套（#1315）。在审侧可见新一轮训练栈动作：DeepSeek-V4 向上游同步的 [1/N]（#202）与 [2/N]（#211，为打包序列补连续上下文并行），以及 HF 与 MCore 的 DCP 轻量互转（#1319）。
  • TransformerEngine-FL：实现 FlagCICD v1，引入 L0 至 L4 测试分级与计划驱动执行（#142）。
  • optest 与 FlagOps：optest 修 CI 的目标引用与算子测试诊断信息（#18）、重写 README（#17）；FlagOps 的稳健检出清掉硬杀 fetch 留下的陈旧 git 锁（#18）。

二、新闻报道与生态

2.1 MiniCPM-OCR 双模型 Day0 适配 12 平台，达摩院玄铁吞吐达原生 98.7%（10-29）

日期：2026-10-29　来源：FlagOS Day0 适配 MiniCPM-OCR & Jev · FlagRelease 模型卡入口 · vllm-plugin-FL 文档 · Torch-FL 文档

  • 模型：面壁智能联合 OpenBMB 开源 MiniCPM-OCR 系列——1.3B 的 MiniCPM-OCR 1.0 面向扫描、拍照、弯曲、翻拍等真实文档场景，支持文字、公式、复杂表格解析与关键信息抽取，官方评测在 Real5-OmniDocBench 得 93.68 分，引入 DSpark 解码加速后端到端效率提升 55%；2B 的 MiniCPM-OCR Jev 承担「AI 质检员」，对解析结果做可靠性评分并可接入不同 OCR 模型，JevOCRBench 上整体 AUROC 为 0.936，接近 Qwen3.5-397B-A17B 的 0.938。
  • 平台与路径：覆盖达摩院玄铁、英伟达、华为昇腾、海光、昆仑芯、沐曦、摩尔线程、清微智能、天数智芯、曦望、Mac（ARM）与此芯科技 12 个平台。Jev 走 Torch-FL 接入，OCR 1.0 走推理框架插件（vLLM-plugin-FL 或 SGLang-plugin-FL），底层都用 FlagGems 的算子实现与 FlagTree 的编译支持；版本口径为 vLLM v0.24.0、vllm-plugin-FL v0.3.0、FlagGems v5.4.0。
  • 性能口径：Jev 在英伟达上走 Torch-FL + FlagGems + FlagTree，12 条样例、batch 1、单卡 BF16 下平均判别 76.2 毫秒，原生 62.7 毫秒，实际计算吞吐为原生的 82.3%；在达摩院玄铁上平均 63.56 毫秒，吞吐达英伟达 H100 原生的 98.7%。OCR 1.0 在达摩院玄铁上走 vLLM-plugin-FL + FlagGems + FlagTree，双方均为单卡 BF16（峰值算力按 989 TFLOPS 与 123 TFLOPS 计），按峰值归一化后单文档 P50 吞吐为原生的 169.3%、批量场景 137.1%。
  • 端侧：ARM 侧覆盖 Mac 与此芯科技。Jev 仅用 M5 CPU，12 条样例下平均单次页面块判别 1.2 秒、中位 895 毫秒，不包含前序整页 OCR 解析；实现上保留 BF16 权重与判别头，用 SME2 矩阵指令加速主要线性层，并通过 Triton TLE Raw 接入算子执行路径。
  • 观察：这是近期第一份把「跨芯吞吐」与「端侧时延」放在同一口径下给出的适配说明——98.7% 是实际吞吐比，169.3% 是按峰值算力归一化后的比值，两者不可互相替代。文章也如实写明 169.3% 的成立前提是低峰值算力平台的利用率更高，而非单卡更快。

2.2 CSDN 技术直播：一个插件打通十款芯片的推理适配（10-29）

日期：2026-10-29　来源：直播页：大模型推理救星——一个插件搞定多芯片适配

  • 事实：FlagOS 社区在 10-29 16:25 上架、19:00 开播一场技术直播，主题为 sglang-plugin-FL 的跨芯片推理适配。该插件是构建在 SGLang 之上、不侵入内核源码的 out-of-tree 外部推理插件。
  • 技术要点（页面摘要）：通过 ATen 算子替换、融合算子调度、统一通信抽象、PD 分离下的 KV Cache 传输、Empty 模式的依赖拆分等机制对接不同硬件；介绍口径称已适配昇腾、海光、昆仑芯等十款芯片平台。
  • 对应代码面：本窗口内 sglang-plugin-FL 有 6 笔在审 PR 更新，包括昇腾与天数在 SGLang 0.5.18 上的 Empty 运行时适配（#160、#139）、昆仑芯升级到 0.5.18（#155）、以及复用原生 Mooncake PD 控制走通用 FlagCX 传输（#142）。直播内容与代码进度方向一致。
  • 观察：社区侧的内容节奏已从「发布会式宣讲」转向「按插件拆解的单点技术直播」，本场与 10-22 的高校圆桌、10-15 的算子赏金挑战赛构成一条连续的技术传播线。

2.3 渠道核查：HN 与智源社区无新命中，CSDN 专栏新增一稿一直播（10-29）

日期：2026-10-29　来源：HN Algolia · 智源社区 · CSDN FlagOS 专栏

  • CSDN 专栏：页面 15 条条目逐页核时后确认，窗口内新增两条——10-29 11:19 发布的 MiniCPM-OCR 及 Jev 的 Day0 适配文章（见 2.1），以及 10-29 16:25 上架、19:00 开播的 sglang-plugin-FL 直播（见 2.2）。页面上排在前列的 GLM-5.3-Flash（8-28）、Qwen3.8-Flash-Next（8-27）与 LightX2V 接入三稿为 8 月下旬旧文，不计入窗口。
  • HN：8 组查询（FlagOS、FlagGems、FlagScale、FlagTree、BAAI、FlagQuantum、FlagSparse、flagos-ai）在 4 天窗口内命中 6 至 30 条，但按标题与正文直接匹配均为 0，属同名词误命中。
  • 智源社区：首页与搜索页均无窗口内与软件栈相关的新条目；搜索页为客户端渲染，抓不到条目列表，以首页核查为准。
  • gnews：24 组中英文查询在窗口内共 30 条命中，逐条按标题与正文筛后仅一条与 FlagOS 相关——具身之家 10-29 的辉羲智能参会稿，内容指向 10-17 至 10-18 的 2026 人工智能开放计算大会暨众智 FlagOS 技术大会，属会后传播稿，非窗口内新事件，不单列条目。其余为科创板行情、董事会决议、园区招商与基金持仓稿，按标题关键词整批剔除。
  • 成员官网：八家巡检中沐曦官网有 10-29 新条目《从 Token 效率到开源协作，共赴 AI Infra 的下一个十年｜沐曦股份 CNCC 2026 分论坛回顾》，属会议回顾，未涉软件栈变动；摩尔线程官网最新为 10-28 的三季度报告图解；天数、海光、寒武纪、燧原、清微五家列表无 10-29 至 10-30 新条目；地平线抓取失败，以列表可见内容为准。

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

3.1 海光：DTK 26.10 从容器到 wheel 的全链落地（10-29）

日期：2026-10-29　来源：build-infra PR #1554 · build-infra PR #1558 · build-infra PR #1562 · build-infra PR #1563 · build-infra PR #1565 · FlagAttention PR #109 · FlagTrain PR #35

  • 容器层：新增 DTK 26.10 的基础容器与运行时配置（#1554 加 78 行、#1555 加 21 行），首次落地时明确「FlagCX 尚未构建，故本阶段不纳入」。修复笔 #1558 一次解决两个阻塞：base/hygon-dtk26.10 把 /opt/dtk 指到 dtk-26.04 而 SDK 实际解到 /opt/dtk-26.10，以及构建矩阵缺该条目的 runner 覆盖会落回 h20。
  • 依赖层：torch 2.13.0+dtk2610 的全局依赖直接链 libmpi.so.40，24.04 基础镜像里没有任何包提供它，因此补 libopenmpi3t64（#1564）；FlagCX 的构建器用 22.04 自包含环境，包名为 libopenmpi-dev，单独补（#1565）。同一笔还指出 26.04 的 wheel 把 libmpi 与 libibverbs 哈希进包内，因此旧构建器从不需要这两个系统库——这是版本间构建假设变化的直接证据。
  • 编译与通信层：FlagTree 增 cp312 的 hcu 构建器并装 DTK 26.10 SDK（#1562），hcu-dtk2610 进入 wheel 发布目标（#1566）；FlagCX 的 dtk2610 wheel 线以 flagcx==0.14.1+dtk2610 开启（#1563）。
  • 算子侧：FlagAttention 移除海光上的 FP8 MSA 路径并修测试导入（#109）；FlagTrain 的 multi_tensor_adam 把海光列为一等后端（#35）；在审侧 FlagCX 有海光的 bitcode 构建（#667）、FlagScale 有 DCU 的硬件健康采样（#1299）。
  • 判断：海光这条线的价值不在新能力，而在把「新 SDK 带来的 soname 与解释器版本变化」在一天内走完容器、构建器、wheel 三处修正，并留下可复用的排查路径（#1558 与 #1565 的正文即为该路径的记录）。

3.2 清微：Triton 3.6 后端同步合入并打出专用标签（10-29）

日期：2026-10-29　来源：FlagTree PR #1459 · FlagTree 标签 · FlagTree PR #1468 · vllm-plugin-FL PR #642

  • 合入内容：清微后端与内部 Triton 3.6 开发线同步（#1459，27 文件加 2264 行减 407 行），只动 third_party/tsingmicro/：补回厂商算子分发所需的逐发射精度 API（precision.py）、外部 CoreIR 入口与运行时适配器，修 Tx81 的若干代码生成问题，并修 DMA、RDMA、WDMA、gather-scatter 与算术相关的 CRT 缺陷。
  • 版本动作：同日 11:09 打出清微 3.6 专号标签，与 10-26 的摩尔线程 3.6 标签构成同期序列。
  • 在审与生态：vllm-plugin-FL 的在审 #642 把清微的 eager TXDA 后端适配到 vLLM 0.28.0；FlagGems 侧的清微参考实现在 10-29 有多笔测试夹具修正（见 1.4）。
  • 判断：清微是少数把「内部开发线」直接同步进开源后端的厂商，代价是每次同步体量大（本次 27 文件）、评审需要按厂商 SDK 语义核对；好处是 FlagGems 与 FlagTree 的接口约定能随厂商内部进度前移。

3.3 昆仑芯：XPU3 的 foreach 融合链与常量网格收尾（10-29）

日期：2026-10-29　来源：FlagGems PR #7116 · FlagGems PR #7968 · FlagGems PR #7973 · FlagGems PR #7974 · FlagCX PR #678 · FlagGems-sglang PR #248

  • 融合内核：foreach 家族在 XPU3 上完成从「逐个算子实现」到「List 执行器」的收敛——cos/exp/sin/addcdiv/lerp 走统一执行器（#7116），ceil 走无掩码融合内核（#7604），tanh/expm1 走原地融合内核（#7608）。
  • 发射正确性：随后四笔修复集中在发射参数——fmin 与 t_copy 的一维路径改用常量发射网格（#7966、#7973），foreach 的标量 dtype 分支改为互斥（#7974），foreach add 的列表槽位改由 program_id(0) 推导（#7968）。这些不是性能优化，而是「同一算子在多分支下取错槽位」的正确性修复。
  • 接口面：FlagCX 增加 XPU 的设备 IR 入口供 FlagTree 链接（#678）；FlagGems-sglang 的 fill_bonus_tokens 适配新的 tle.raw 方言 API（#248）。
  • 在审：vllm-plugin-FL 的 P800 在 vLLM 0.28.0 上的适配（#585）、sglang-plugin-FL 的昆仑芯升级到 0.5.18（#155），以及 FlagGems 侧一批 P800 的正确性议题。

3.4 沐曦：分组 GEMM 的 INT8 与 FP8 路径、TP2 解码调度（10-29）

日期：2026-10-29　来源：FlagGems PR #6950 · FlagGems-vllm PR #1025 · FlagAttention PR #108 · FlagTree PR #1481 · FlagTree PR #1471

  • 分组 GEMM：grouped_mm_w8a8 同时支持 INT8 与 FP8（#6950，7 文件加 1220 行）。基准的形态来自 GLM-5.2 在 PPU SGLang TP=8 上采集的真实调用回放，288 万到 324 万次调用的两组形状，共 26 组唯一几何、257 个专家。基线是厂商库的 ContinuousGroupedGEMM，两边接收相同 INT8 输入、FP32 缩放与专家分组。
  • 解码调度：FlagGems-vllm 侧把 TP2 packed decode 的 Split-KV 调度与计算 tile 重排（#1025），目标是窄 tile 下的解码吞吐。
  • 注意力：FlagAttention 新增 C550 上的 Triton 融合 AttnRes 前向（#108，3 文件加 268 行），支持 FP16 与 BF16、可选输出 RMSNorm 与注意力权重，融合 RMS 打分、在线 softmax 与残差聚合，不依赖 TLE；D=7168、BF16 下从 (2,1) 的 0.075 毫秒到 (9,8192) 的 1.496 毫秒，作者注明 FLA 不可用故不宣称加速比。
  • 编译器：FlagTree 修 Metax 上 CompiledKernel 的元数据检查（#1481，对应议题 #1473）；在审的 #1471 为 MetaX 的 CommonIR 加 set_layout 与布局自动调优。
  • 厂商侧：沐曦官网 10-29 发布 CNCC 2026 分论坛回顾《从 Token 效率到开源协作，共赴 AI Infra 的下一个十年》，属会议侧内容。

3.5 摩尔线程：TLE 常驻 GEMM 与 SPMC 同步进主线（10-29）

日期：2026-10-29　来源：FlagTree PR #1294 · FlagGems-vllm PR #970 · FlagTree PR #1451 · vllm-plugin-FL PR #575

  • 编译器：[MThreads][TLE] 的常驻 GEMM 流水线与 SPMC 同步进主线（#1294，63 文件加 6192 行减 403 行），把原先分别服务 addmm/baddbmm 与 bmm 的两套编译器合成一套超集，能力包括动态循环中的 stage 与 phase 推进、一生产者多消费者、命名读与隐式读、分段与分组完成、消费者纪元推导，以及单发、融合消费者与 16 warp 常驻路径。PR 正文明确本轮改动只含编译器、前端与测试，不含 FlagGems 算子代码。
  • 推理：FlagGems-vllm 侧按当前 CI 编译器重调 MUSA 的 FP8 变长注意力（#970）。
  • 在审：FlagTree 的 #1451 把 WGMMA 的 warp 选择对齐上游 MMAv3；vllm-plugin-FL 的 #575 把 MUSA 适配到 vLLM 0.28.0；另有 MUSA 的短形状回退分支（FlagFFT 的 codex/musa-shortfall）在特性分支上推进。
  • 判断：摩尔线程的投入重心在编译器侧而非算子数量——常驻 GEMM 与 SPMC 是让 addmm/bmm 一类主干算子在 MUSA 上跑到可用性能的前提，这条能力也同时被昇腾与沐曦的 TLE 线复用。

3.6 燧原、昇腾、达摩院玄铁：注意力与归一化算子的四条线（10-29）

日期：2026-10-29　来源：FlagAttention PR #104 · FlagAttention PR #106 · FlagAttention PR #116 · FlagAttention PR #103 · FlagGems PR #6586 · Torch-FL PR #683 · FlagGems-vllm PR #888

  • 燧原：FlagAttention 上三笔同日合入——MiniMax M3 稀疏注意力的 prefill 与 decode 优化（#104，2 文件加 2873 行减 2516 行）、chunk KDA 算子优化（#106）、融合注意力残差算子（#116）；FlagTree 侧补燧原 CI（#1468）与 TLE 单测（#1470），并在审 #1405 修 swiglu 的精度误差。
  • 昇腾：新增 Parallax 注意力的三段实现（prefill、decode、kvcache，#103，10 文件加 2738 行），覆盖因果掩码、滑窗、GQA 与变长输入，相较 FLA 在多数训练形状上为 1.0 至 8.74 倍加速；FlagGems 修 cat（#7989）与 log_ 网格填充重跑（#6586，5.4.0-rc2 回摘）；FlagGems-vllm 把 fused_q_kv_rmsnorm 落到昇腾（#872），并把 lightning-indexer 的自定义算子改名到 tle_raw.call（#944）；Torch-FL 让昇腾遵循 FP32 matmul 精度并保持梯度驻留（#683）。
  • 达摩院玄铁：fused_q_kv_rmsnorm 同样落到达摩院玄铁平台（#888，17:07 合入）；PPU 侧 10-29 还有 FlagTrain 的 multi_tensor_adam 全后端支持（#35，PPU 为一等后端），以及在审的 PPU GLA 优化（FlagAttention #117 为海光，PPU 另有独立分支）；MiniCPM-OCR 的 Day0 适配把达摩院玄铁的吞吐推到英伟达原生的 98.7%（见 2.1）。
  • 判断：三家在同一天各取一条注意力路径——燧原做稀疏与 KDA，昇腾做 Parallax 与融合 RMSNorm，达摩院玄铁做融合 RMSNorm 与端侧解码。注意力层的碎片化仍在加剧，尚未出现跨厂商的统一下沉实现。

3.7 天数：天垓 300 首次实机演示对外，单卡吞吐宣称 1.05 倍 H200（10-28）

日期：2026-10-28（演示）/ 2026-10-29（报道）　来源：Pandaily 报道 · 南华早报报道 · FlagCX PR #681 · sglang-plugin-FL PR #139

  • 演示事实：天数智芯在 10-28 的上海媒体开放日首次实机展示天垓 300 通用 GPU。此前该公司对这款芯片的公开材料以架构与路线图为主，没有可运行系统。
  • 宣称与口径：公司称天垓 300 是首款实测性能达到英伟达 H200 水平的国产通用 GPU，第三方测试换算后单卡整体吞吐为 H200 的 1.05 倍，并在文生图、文生视频等复杂多模态任务上超过 H200。该数字为公司口径，测试方法、所用模型与工作负载条件均未公布，无法复核。
  • 栈侧对应：FlagCX 同日为天数补上 Device API 的获取语义（#681，见 1.6）；sglang-plugin-FL 的在审 #139 把天数适配到 SGLang 0.5.18 的 Empty 运行时；FlagTrain 的 multi_tensor_adam 已把天数列为支持后端（#35）。
  • 判断：硬件口径的对外发布与软件栈的适配是两条不同节奏的线——前者一次发布会即可完成，后者要从 Device API 的内存序一路补到推理框架的运行时适配。本窗口看到的是后者在持续补齐，而前者的数字仍缺可复核条件。

四、总结与趋势观察

  • 硬件代际切换的成本集中在构建面：DTK 26.10 八笔合入里没有一笔改内核，全部是容器路径、解释器版本、runner 覆盖与 soname 依赖。python 3.12 与 torch 2.13.0+dtk2610 把既有 cp310 构建器整体作废，26.04 到 26.10 之间 libmpi 与 libibverbs 从「哈希进 wheel」变成「运行时链接」，这类变化只能靠逐节点实测发现。
  • 模型 Day0 的叙事转向可比较的数字：MiniCPM-OCR 的适配说明同时给出实际吞吐比（98.7%）、按峰值归一化的吞吐比（169.3%）与端侧时延（M5 上 1.2 秒、中位 895 毫秒），并写明各自前提。这是本栈近期第一份把「追上原生」与「利用率更高」分开陈述的材料，比单一倍数更有参考价值。
  • 测试基建成为独立主线：ref-as-candidate 在 FlagGems 与 FlagGems-sglang 双仓落地，配合同日 57 笔测试修复与 kernelgen-dev 的每日自动同步，测试从「有没有算子」变成「参考与实现是否一致」。这条线的产出不体现在算子数量上，但决定了后续所有后端对齐的可信度。
  • 量子线自成体系：FlagQuantum 一日 60 笔提交把 CS-01 至 CS-07 的电路合成规格与交付文档成体系归档，FlagQAI 同步做本地工作台。它与多芯适配无关，是 2.x 周期里唯一一条与硬件解耦的软件栈主线。
  • 待观三点：其一，community 仓的 release/2.3 清单尚未建立而构建面已在按 2.3.0 记账，发布说明是否会补齐；其二，FlagCX v0.14.1 与 FlagTree 按厂商切分的 3.6 标签均无 Release 正文，下游只能从标签名反推内容；其三，Megatron-LM-FL 的 DeepSeek-V4 上游同步已开出 [1/N] 与 [2/N]，这条停摆两周的训练栈是否真正恢复推送。

信源核查表

信源 核查结果
GitHub org 全量（61 仓） 21 仓窗口内推送；16 仓有提交；5 仓经原子补核（1 仓有提交、1 仓为 gh-pages、1 仓为特性分支、2 仓为 PR 分支与议题活动）
提交检索 189 笔；FlagQuantum 60、FlagGems 43 为两大头
合并 PR 检索 183 笔；FlagGems 92、build-infra 16、FlagQuantum 15
在审 PR 检索 253 笔有更新，新开 84 笔；Megatron-LM-FL 十笔为近两周首次成规模更新
Release / Tag 原子核查 31 仓；窗口内新增标签 1 个（FlagTree 清微 3.6 专号，无发布正文）；FlagCX v0.14.1 档案时间更新至 10-29 10:55
org 事件流 100 条：PR 评审评论 34、PR 事件 34、推送 13、议题评论 9、建分支 8、删除分支 1、fork 1
Google News RSS（24 组中英文） 命中 30 条，有效 1 条（辉羲智能参会稿，指向 10-17 至 10-18 大会，属会后传播稿，不单列）
HN Algolia（8 组） 4 天窗口命中 6 至 30 条，标题与正文直接匹配 0 条
CSDN FlagOS 专栏 新增文章 1 篇（MiniCPM-OCR Day0，10-29 11:19）、直播 1 场（10-29 19:00）；三条高相关旧稿核时为 8 月下旬，不计入
智源社区 首页无窗口内软件栈条目；搜索页为客户端渲染，抓不到列表
成员单位官网（8 家） 沐曦 10-29 有会议回顾一条；摩尔线程最新为 10-28 财报图解；天数、海光、寒武纪、燧原、清微无新条目；地平线抓取失败

完整信源清单