调研窗口：2026-09-07 10:18 ~ 2026-09-08 10:18 北京时间 信源：GitHub（org: flagos-ai 52 仓 pushed_at + commit search 91 条全量按 committer-date 核验 + 默认分支 per-repo 复核 + tags/releases/PR 详情）、Google News RSS（中英 14 组查询，走代理）、HN Algolia、Tavily/web 检索、FlagOS CSDN 官方号（详见附录）

索引

  • 一、开源项目进展（GitHub 动态）
    • 1.1 FlagOS 2.2 RC1 收口：community 发布 RC1 manifest，25 个清单条目随首轮 rc1.post1 验证 tag 集中打出（09-07）
    • 1.2 FlagScale 三连：KERV 具身投机解码训练/推理集成、Megatron-LM v0.18.2 升级、CICD 聚焦训练（09-07）
    • 1.3 FlagGems-Experimental：KernelGen 跨后端算子批量同步入库 + sync-to-kernelgen CI 落地（09-07）
    • 1.4 FlagGems 主仓：海光/天数修复、QC fp8、外部贡献者与回滚（09-07）
    • 1.5 FlagGems-vllm：达摩院玄铁 PPU 与海光专用 fused-MoE 后端（09-08）
    • 1.6 FlagBLAS：Ascend L2 例程连续合入（CHER/CHER2/SSYR/CSYR）（09-07/09-08）
    • 1.7 FlagTree/FlagPrism：TLE 多字段 pipe、CI/CD 修复与调试/剖析组件合入（09-07）
    • 1.8 vllm-plugin-FL 与 FlagScale-Agent：FlagCX 指标连接器、Agent 可靠性重构（09-07/09-08）
  • 二、新闻报道与生态
    • 2.1 FlagOS 社区”开放 AI 计算”论坛在上海 KubeCon + PyTorch Conference China 同场举办（09-07）
    • 2.2 组件级新闻第六个连续平静窗口（09-07~09-08）
  • 三、成员单位深挖
    • 3.1 清微（tsingmicro）：vllm-plugin-FL 新增 txda 后端线，随 vLLM 0.24.0 主线合入（09-07）
    • 3.2 天数智芯（iluvatar）：0.20.2 确定性技术路线定案——flag_gems GEMM 族整族黑名单（09-07）
    • 3.3 沐曦（metax）与寒武纪（cambricon）：sglang 0.5.18 交付线扩围（09-07/09-08）
    • 3.4 外部生态：昇腾验证记录与 from-scratch 修复、昆仑芯 KernelGen 算子、sunrise 新后端接线（09-07/09-08）
  • 四、总结
  • 附录：完整信源清单

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

窗口总览：org 内 52 个仓库中 30 个在窗口内有推送，commit search 命中 91 条窗口内提交，默认分支实质合入集中在 community、FlagScale、FlagGems、FlagGems-vllm、FlagGems-Experimental、FlagBLAS、FlagTree、FlagPrism、FlagCX、Megatron-LM-FL、TransformerEngine-FL、vllm-plugin-FL、build-infra、FlagScale-Agent 等 14 仓，为近期活跃度最高的窗口之一。本窗口头号事件是 FlagOS 2.2 RC1 正式切线：09-07 11:11 community 合入 release/2.2/release-2.2-rc1.yaml（+252 行、25 个清单条目），随后 11:22~11:33 间至少 12 个仓库集中推送首轮 rc1.post1 验证 tag——昨日报告”下一发布信号仍看 community 清单仓库动作”的预判在窗口内兑现，且动作比预期更大：不是 version bump，而是 RC0→RC1 的发布管线切换。组件代码侧延续 2.2 测试稳定期特征：FlagGems 系算子矩阵（fused-MoE 新后端、Ascend L2、KernelGen 批量同步）、FlagScale 训练栈（Megatron v0.18.2、KERV）、编译器与插件层的验证性修复。

1.1 FlagOS 2.2 RC1 收口：community 发布 RC1 manifest，25 个清单条目随首轮 rc1.post1 验证 tag 集中打出（09-07）

来源：community PR #107（703ea2184c，wbavon，09-07 11:11 合入）、release-2.2-rc1.yaml、FlagSparse v0.3.0-rc1.post1 release（09-07 11:27 发布）、2.2 时间表 schedule_CN.md

  • manifest 合入：09-07 11:11，community 仓合入 #107，新增 release/2.2/release-2.2-rc1.yaml（252 行）并把 .github/workflows/release-branch-tag.yml 的默认清单从 2.2/release-2.2-rc0.yaml 切到 release-2.2-rc1.yaml。manifest 采用 vcstool 格式，覆盖 L0 基础设施（flagtree×3 条 Triton 线、flagcx）→ L1 计算库（flaggems/flagfft/flagsparse/flagdnn/flagblas/flagtensor/flagaudio/flagattention/flaggems-vllm/flaggems-sglang）→ L2 框架适配（torch-fl、vllm-plugin-fl×2、sglang-plugin-fl、transformerengine-fl、megatron-lm-fl、flagos-compressor）→ L3 应用工具（flagscale、kernelgen、kernelgenbench、flagrelease），共 25 个条目、22 个仓库。
  • 关键版本锚点：flagcx v0.14.0-rc1.post1、flaggems v5.4.0-rc1.post1、flagscale v2.1.0-rc1.post1、kernelgen v2.2.0-rc1.post1、flagtree 三线统一 0.7.0rc1.post1+triton{3.6|3.5|3.3}、vllm-plugin-fl 拆两条线（main 跟 vLLM 0.24.0 → v0.3.0-rc1.post1；release/0.2 跟 vLLM 0.20.2 → v0.2.2-rc1.post1）。注释同步记录了 rc0→rc1 的工程演进：FlagGems master 已合入 setuptools_scm only-version（上游 #5885），post tag 落在 master 不再触发构建失败，rc1 无需再做 rc0 那次的 cherry-pick/挪 tag 补救。
  • rc1.post1 tag 波：11:11 manifest 合入后，11 分钟内至少 12 个仓库集中推送（FlagCX 11:22、FlagFFT 11:23、FlagSparse 11:27 发布 release、FlagTensor/FlagAttention/FlagGems-sglang/FlagAudio 11:28、Torch-FL 11:29、FlagOS-Compressor 11:31、KernelGen 11:32、KernelGenBench/FlagRelease 11:33），与 manifest 各条目一一对应；这些仓库默认分支在窗口内均无实质代码合入（tags API 复核 rc1.post1 均存在），即纯 tag 波。manifest 头注释写明版本演进规则：每轮验证通过打递增 tag（rc1.post1 → rc1.post2 → …）并回写 version 字段，.post1 即”首轮验证通过”标记。

解读：这是 FlagOS 2.2 发布周期的第三个里程碑信号——08-31 特性冻结（FEP 门关闭）、09-01 进入测试稳定期（只收 bug 修复）、09-07 以 RC1 manifest + 首轮验证 tag 波宣告 rc0 集成段的验证结果被固化为 rc1 基线。时间表显示 09-01~09-24 为多芯片矩阵测试窗口、09-28 GA，RC1 切线比 rc0 晚 7 天，符合”特性冻结→约一周集成验证→rc1 固化”的节奏预期。值得注意的两点：一是 manifest 的条目粒度与 rc0 相比更细（FlagTree 三条 Triton 线、vllm-plugin 两条 vLLM 线分列），说明 2.2 的交付矩阵确实覆盖多编译器/多框架版本组合；二是 FlagGems 上游对 post-tag 构建问题的根治（only-version），把 rc 周期的构建噪声从流程里消掉了——RC1 之后的 post2/post3 迭代会更快。对后续观察的意义：下一信号是各组件 rc1.postN 的递增（对应多芯片矩阵验证的逐轮通过）与 09-24 前后的 RC-final/GA 切线；RC1 期间组件默认分支仍可合入 bug 修复，社区挑战赛等外部贡献流不受影响。

1.2 FlagScale 三连：KERV 具身投机解码训练/推理集成、Megatron-LM v0.18.2 升级、CICD 聚焦训练（09-07）

来源：FlagScale PR #1278（zhengzihaoPKU，09-07 14:24 合入）、#1284（b5741d04，22:00）、#1283（b3708f0f，10:34）、Megatron-LM-FL #109（e15cb692，21:57）

  • KERV 集成（#1278，09-07 14:24）：FlagScale 合入 KERV 具身投机解码（embodied speculative decoding）的训练与推理集成——新增 OpenVLA verifier 的 LoRA/全参训练配置、KERV draft 数据生成与 drafter 训练、LIBERO 推理配置；进程内适配 KERV/OpenVLA 公开 Python 入口（FlagScale 统一编排、不产生嵌套 launcher）；自带 KERV 控制运行时（批候选生成、验证树构建、宽松接受、动态阈值调整、Kalman 补全）；BF16 推理 profile 直接选用公开 runtime_opt 包中的 14 个 KERV 算子；附 33 个与模型无关的单测（CI 不下载 checkpoint、不启 MuJoCo/LIBERO）。
  • Megatron v0.18.2 升级（#1284 + Megatron-LM-FL #109，09-07 晚间）：FlagScale 22:00 升级上游依赖至 Megatron-LM v0.18.2；配套的 Megatron-LM-FL 插件仓 21:57 同步升到同一基线（#109）。两个训练栈仓库在同晚对齐版本，属协同升级。Megatron-LM-FL 另两条 CICD 提交：#140（18:29）为 TE-FL prepare checkout 加重试、#128（15:01）做 TE-FL 增量构建与运行时集成。
  • CICD 聚焦训练（#1283，10:34）：FlagScale 移除 inference 与 serve 两条 CI 流水线，”focus on training”——训练框架的交付边界收窄，推理侧由 vllm-plugin-FL/sglang-plugin-FL 承担的分工进一步显式化。

解读：三条提交分别对应 FlagScale 的三个方向信号。KERV 是最值得注意的一条：FlagOS 训练栈开始覆盖具身/机器人策略的投机解码——KERV 是面向机器人 VLA 部署的投机解码框架（OpenVLA 作 verifier、draft 模型先行、验证树+Kalman 补全控制接受率），FlagScale 把它做成”可训练（verifier/drafter）+ 可推理（LIBERO）+ 可评测”的一等公民。这与 FlagOS-Robo 的具身智能工具链定位呼应，也与 2.2 测试期内”只收 bug 修复、不进新特性”的冻结规则形成对照——KERV PR 于 08-30 创建、09-07 合入，正好踩在特性冻结（08-31）边缘并已提前实现，属冻结前进入的存量特性收尾而非冻结后新开。Megatron v0.18.2 双仓同晚对齐则说明 2.2 RC1 基线里训练栈的依赖版本已被钉死；CICD 聚焦训练是把”FlagScale=训练、vllm/sglang 插件=推理”的分工写进工程流水线。

1.3 FlagGems-Experimental：KernelGen 跨后端算子批量同步入库 + sync-to-kernelgen CI 落地（09-07）

来源：FlagGems-Experimental commits（14:31 CICD 3 条 + 16:27~16:58 批量 60+ 条）、CICD sync-to-kernelgen（4973e875）

  • CI 先行（14:31）：103yiran 合入 CICD(.github): add sync to kernelgen、docs: add ci doc 与 .github 调整——FlagGems-Experimental 与 KernelGen 仓库之间建立了自动化同步工作流。
  • 16:58 批量入库：同一秒戳（16:58:04~05）落库 60+ 条提交，全部为 [KernelGen][厂商] 前缀的算子提交，跨后端覆盖：Kunlunxin（digamma、arctan minimax 优化、bernoulli）、Metax（linalg_cholesky/log_normal_/erfinv/gcd_/lgamma 等专用数学算子 + adaptive_max_pool3d_backward + special_shifted_chebyshev_polynomial_w + 注册名修复）、Iluvatar（addmm_、nonzero_numpy 混合两遍 kernel 优化）、Hygon（amp_foreach_non_finite_check_and_unscale）、thead（lcm/lcm_ 厂商专用化）、MThreads（linalg_cholesky）、Nvidia（special_i0/softmax/xlog1py/shifted_chebyshev_t/spherical_bessel_j0/split_with_sizes/grid_sampler_3d 等新算子），另有上游 FlagGems 同步过来的历史提交（Apache 2.0 头补齐、CI 修复、FlagTune topk 配置、ENFLAME 更新等，PR 编号 #3540/#4646/#4829/#4873 等指向 FlagGems 上游）。贡献者含 yzw1128（FlagGems-sglang 赛事战队的同一账号）、chx7514、ZhiwenDeng、KK、Dingxingdi、bwbwzzz 等。

解读：FlagGems-Experimental 是 KernelGen 算子流的中转/实验仓，本窗口”CI 同步工作流 + 一次性大批量合入”的组合说明：KernelGen 的跨厂商算子产出正在以”批次同步”方式从实验仓流向 KernelGen 主仓（sync-to-kernelgen 即管道本身）。这批算子的语义分布很能说明 KernelGen 当前的主攻面——special 函数族（i0/softmax/xlog1py/贝塞尔/切比雪夫多项式等）在 Nvidia/Metax 后端密集出现，说明数学函数算子的自动生成覆盖面在扩；而 Kunlunxin/Iluvatar/Hygon/thead/MThreads 的条目多为”厂商专用化”（把通用 kernel 针对具体工具链/指令重写），对应多芯片适配的最后一公里。值得注意 thead（达摩院玄铁）条目与 lcm 这类整数算子——玄铁侧的 KernelGen 支持仍在持续加码。yzw1128 同时活跃于赛事 PR 与 KernelGen 算子，说明外部贡献者已同时在赛事通道与 KernelGen 通道产出。

1.4 FlagGems 主仓：海光/天数修复、QC fp8、外部贡献者与回滚（09-07）

来源：FlagGems commits 11:34~20:39、#6040 hygon BLOCK_M fix、#6043 revert FlagTune、#5341 SiliconFlow cauchy

  • 海光修复（15:23 #6040）：修复 Hygon 后端 flash attention 在跑 ViT encoder 推理时 KeyError: 'BLOCK_M'——量化配置取块大小的路径在特定形状下取空。
  • 天数优化（17:27 #5341）：[SiliconFlow] Optimize cauchy on Iluvatar——硅基流动（SiliconFlow）署名参与，在 Iluvatar 上优化 cauchy 算子（SSM 系卷积），并顺带修复跨后端测试。
  • QC fp8（14:04，与 Experimental 同 commit c9bd738d）：[QC] Optimize GEMM(fp8)——fp8 GEMM 优化同时落在主仓与实验仓。
  • 工程面：18:07~18:09 三条 CI/测试提交（approved operator tests 别名、and_scalar pytest 标记）；17:37 AddMM 公共 API 测试（上游 beta-zero 修复后）；18:09 修复 bucketize kernel 越界读 input 尾（#5231，Truong Vu）；20:39 更新 Hygon linalg_solve_triangular（#5943）。
  • 回滚（15:54 #6043）：Revert 前日合入的 [FlagTune] Add multi-platform Mul cost model support (#5762)——FlagTune 多平台乘法成本模型被整体回退。

解读：主仓窗口内 11 条提交呈现典型的”测试稳定期”形态：无新架构级特性，全部是后端正确性修复（Hygon ViT 场景 BLOCK_M、bucketize 越界）、单算子性能优化（QC fp8、Iluvatar cauchy、Hygon linalg）与 CI/测试基建。硅基流动署名优化 Iluvatar cauchy 值得标记——这是继中科院 AlphaSparse 团队（FlagSparse）之后又一家外部公司直接向 FlagGems 贡献厂商算子，生态共建的”外部贡献”名单在变长。FlagTune 成本模型被 revert 说明调优器侧的改动在 RC 期会被从严把关：不合验收标准宁可回退，与 2.2”只收 bug 修复”的冻结纪律一致。

1.5 FlagGems-vllm：达摩院玄铁 PPU 与海光专用 fused-MoE 后端（09-08）

来源：FlagGems-vllm PR #696（09-08 09:54 合入）、#746（09:56）、#747（10:05）

  • #696 达摩院玄铁 PPU 后端：新增 _thead 后端，为 T-Head PPU（ZW810E，compute_89 / AIU MMA 指令）实现纯 Triton fused-MoE（fused_experts_impl），建模自既有 _metax/_mthreads 厂商后端：thead 版 moe_align_block_size、转置缓存权重（复用自 FlagGems 同步的 permute_copy）、per-tile moe_sum 归约，生产路径不依赖 deep_gemm；大 M GEMM 风格 kernel 按 token 数分档（MOE_GEMM_TUNING_MIN_TOKENS，gemm1/gemm2 分段）。
  • #746 海光专用 fused-MoE：为 Hygon DCU（gfx936）实现专用 fused_experts_impl，在真实 Qwen3.6-35B-A3B 形状上对 vLLM-HCU Triton 基线调优：完整 fused_moe 流水（moe_align→GEMM1→SiLU→GEMM2→moe_sum），Hygon 专用 align 路径（3-kernel 小批变体，避开 HCU 后端编不了的 TLE 协作 kernel）；按 M 分档（M≤16 非融合单遍、TP4 BK=64、mid-M BK128、TP4 大 M num_warps=16、TP1 M≥8192 非融合等）。
  • #747 KMCompiler：persistent_topk 的测试/benchmark 改为在无 vLLM native op 环境下可运行（KMCompiler 生成路径脱离 vLLM 依赖自测）。

解读：两条 fused-MoE 厂商后端同日合入（间隔 2 分钟），都是”为具体芯片指令集手写调度”的深度适配：玄铁 PPU-ZW810E 走 AIU MMA（compute_89 级），海光 DCU 走 gfx936 专用分档且刻意绕开 HCU 编不了的 TLE kernel——后一条与 KernelGen/FlagGems 系对”TLE 协作 kernel 在部分国产工具链不可编译”的已知边界一致。海光 fused-MoE 以真实 Qwen3.6-35B-A3B 形状调优并直接对标 vLLM-HCU Triton 基线，说明该后端面向真实 35B 级 MoE 推理负载。fused-MoE 是当前推理吞吐的关键算子，vllm 插件层对它的逐芯片专用化是 2.2 测试期”算子级性能打磨”的最直观样本。

1.6 FlagBLAS：Ascend L2 例程连续合入（CHER/CHER2/SSYR/CSYR）（09-07/09-08）

来源：FlagBLAS PR #96（16:35）、#93（17:16）、#97（18:05）、#98（19:31）、#99（09-08 10:16）

  • 窗口内 FlagBLAS 默认分支 9 条提交，主线是 Ascend 后端 L2 例程扩展：Ybanana252 依次提交 CHER（复数 Hermitian rank-1 更新，#97 18:05）、CHER2（rank-2，#98 19:31）、SSYR/CSYR（实/复对称 rank-1 更新，#99 于 09-08 10:16 合入）以及 L2 三角（#93 17:16 合入的 l2-triangular 分支），每条都带 Ascend 输入构造的测试文档（test(her2): document Ascend input construction）。
  • CI 修复两条（#96，16:35 合入，bin913）：nvidia 线 flagtree 对齐 0.6.1（与 FlagGems 同版）并改用 uv pip 安装以保证 triton 可用。

解读：FlagBLAS 的 Ascend L2 覆盖在快速闭合——CHER/CHER2/SSYR/CSYR 都是 rank-1/rank-2 更新类例程，与 09-05 报告录得的 DCU/L2 主线形成”逐例程补齐”的节奏（此前 ascend 的 L2 三角族也已合入）。连续三个傍晚 + 次日清晨各合一批，说明 Ascend 的 L2 验收是批量流水式的。CI 侧把 nvidia flagtree 钉到 0.6.1（与 FlagGems 一致）则是多仓依赖对齐的常规动作。按 manifest，flagblas 属 L1 计算库，RC1 后仍可合 bug 修复与新例程——这条 Ascend 例程补强线大概率会持续到 GA。

1.7 FlagTree/FlagPrism：TLE 多字段 pipe、CI/CD 修复与调试/剖析组件合入（09-07）

来源：FlagTree #1110（12:29）、#1104（15:31）、#1115（15:41）、FlagPrism PR #8（10:47 合入）、FlagPrism README

  • FlagTree（默认分支自 09-04 后首次实质合入）：12:29 #1110 [BUILD][CD] 修复 DEPENDS IncGen 与 nvidia3.7 交付工作流；15:31 #1104 [TLE][MTHREADS] 支持多字段 pipe 与多角色 ws（TLE 在摩尔线程后端的通信/流水抽象扩展）；15:41 #1115 [CI][Nvidia] 优化 nvidia3.6 工作流的并发分组。09-08 09:58 的推送为 PR 分支动作。
  • FlagPrism（新仓库推进）：10:47 合入 #8 “Add profiler and debugger support”。FlagPrism 是集中维护 FlagTree 可选调试与剖析组件的仓库：flagtree.debugger（调试器编译器插件链入 libtriton，运行时传输/解码在独立 _native 扩展）与 flagtree.profiler（Python 包 + 原生运行时 + CLI）；flagtree-debugger/flagtree-profiler 不再单独发 wheel，FlagTree 以 third_party/FlagPrism submodule 方式消费，pip wheel . 一次构建出含 Debugger/Profiler 的单一 FlagTree wheel。

解读：FlagTree 在 rc0 验证期（09-04 清微后端合入后）默认分支静默了 3 天，本窗口的合入集中在构建/交付工作流修复与 TLE 后端能力——nvidia3.7 交付流、IncGen 依赖、摩尔线程 TLE 多字段 pipe 都是”让多芯片 CI/CD 矩阵跑稳”的工程。FlagPrism 的合入是组件架构事件：FlagTree 的调试器/剖析器从”独立包”收敛为”主仓 submodule + 单 wheel”，RC1 manifest 里 flagtree 三线版本一致（0.7.0rc1.post1+tritonX），Prism 的 #8 若在冻结前进入即随 2.2 发布，调试/剖析能力将内建在 FlagTree 单一 wheel 中——对算子开发者是实打实的体验改进（debugger 的编译插件在 libtriton 内、剖析器 CLI 一站式可用）。

1.8 vllm-plugin-FL 与 FlagScale-Agent：FlagCX 指标连接器、Agent 可靠性重构（09-07/09-08）

来源：vllm-plugin-FL #418（489d22d5，14:28）、FlagScale-Agent commit 9e308807（09-08 09:12）

  • vllm-plugin-FL #418（09-07 14:28）：feat(flagcx connector): Prometheus KV-transfer metrics + port #315 from release/0.2——vLLM 插件与 FlagCX 的连接器新增 Prometheus 可观测指标（KV 传输），并把 release/0.2 分支的 #315 修复移植回主线。
  • FlagScale-Agent（09-08 09:12，caozhou）：feat: agent reliability overhaul——为 FlagScale-Agent 加入运行时思考预算上限（runtime thinking cap）、感知推理的重试（reasoning-aware retries）、时间预算感知（time-budget awareness）与健康监控（health monitoring）。FlagScale-Agent 是面向大模型训练编排的智能体组件，本次是整体可靠性重构。

解读：两条都是”让 FlagOS 上层工具更适合无人值守长跑”的工程：FlagCX 连接器的 Prometheus 指标把多卡 KV 传输状态暴露给运维（vLLM 0.20.2 线 #315 修复同步回主线，保持双线一致）；FlagScale-Agent 的”思考预算/重试/时间预算/健康监控”四件套是典型的 agent 工程化加固——防止长时训练编排中 agent 循环失控或静默挂死。考虑到 2.2 测试期的多芯片矩阵跑测对”可观测 + 可自愈”的编排层需求上升，这类加固正当其时。

二、新闻报道与生态

2.1 FlagOS 社区”开放 AI 计算”论坛在上海 KubeCon + PyTorch Conference China 同场举办（09-07）

来源：FlagOS CSDN 官方号公告（2026-09-07 09:57 发布）

  • 09-07 下午，由众智 FlagOS 社区主办的《开放 AI 计算：面向多元异构硬件打造开源软件新生态》论坛在上海 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 大会同场举办；嘉宾来自北京智源人工智能研究院、上海人工智能实验室、PyTorch 基金会、SGLang 社区等，议题围绕开放 AI 系统软件栈的技术路线与协作模式。CSDN 官方号页面提供直播/回放。
  • 该公告发布于 09-07 09:57（紧邻上一窗口终点），论坛本身于当日下午（本窗口内）举行；昨日报告曾记 CSDN 官方号无更新，此条为补录的窗口内生态事件。

解读：把论坛办进 PyTorch Conference China / KubeCon China 的上海会场，是 FlagOS 在”开源社区横向协作”上的连续性动作——与 PyTorch 基金会、SGLang 社区同台，议题直指”多芯片统一软件栈”这一 FlagOS 主张的核心。此类活动本身不产生组件代码动态，但说明 RC1 切线同期社区层在借国际性大会放大开放计算叙事；后续可留意该论坛是否有公开的路线图/白皮书类产出。

2.2 组件级新闻第六个连续平静窗口（09-07~09-08）

来源：Google News RSS（中英 14 组，走代理）、HN Algolia、Tavily/web 检索（详见附录）

  • gnews 中英组合（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/KernelGen/FlagOS 2.2 when:3d~30d 等）窗口内零命中；唯一 FlagGems 命中为 09-01 智源社区 Day0 旧文转载（已报道）。智源研究院 when:7d 命中 58 条，全为智源社区博客转载（姚期智开学典礼讲话、AI 编程杂谈等）与博彩 SEO 模板噪音，无 FlagOS 内容，整批剔除。天数智芯/沐曦查询命中以中报、股价、港股异动等商业新闻为主（与 FlagOS 软件生态无直接关联，不收录）。
  • HN Algolia（FlagOS/FlagGems/flagos-ai/BAAI）无相关命中；Tavily 检索到的新内容仅 2.1 论坛公告。
  • 近 3 天趋势（GitHub org pushed 佐证，工程侧极不平静）：09-07 11:11 FlagOS 2.2 RC1 manifest 切线 + 首轮 rc1.post1 tag 波（本日 1.1）；09-07 FlagScale KERV 具身投机解码集成与 Megatron v0.18.2 双仓对齐（1.2）；09-07/09-08 build-infra 连续 13 条交付记录（天数智芯 0.20.2 确定性定案、沐曦/寒武纪/昇腾 sglang 0.5.18 线，见三）；09-07 晚间 FlagBLAS Ascend L2 例程批量合入（1.6）；09-08 上午 FlagGems-vllm 玄铁/海光 fused-MoE 后端合入（1.5）。

三、成员单位深挖

3.1 清微（tsingmicro）：vllm-plugin-FL 新增 txda 后端线，随 vLLM 0.24.0 主线合入（09-07）

来源：vllm-plugin-FL PR #447（tsingmicro-public-e，09-07 16:58 合入，base: main）

  • PR #447 由清微官方账号 tsingmicro-public-e 提交并合入（PR Category: Vendor）：为 vllm-plugin-FL 增加 txda 厂商代码、支持 vLLM==0.24.0（main 线），并修复 txda 相关 bug。合并时间 09-07 16:58，与 RC1 manifest 中 vllm-plugin-fl main 线钉 vLLM 0.24.0 的设定一致。
  • build-infra runner 侧清微线已具备（tsingmicro-tsm260610: [self-hosted, tsingmicro]，本窗口前已登记）。

解读：清微此前已进入 FlagTree 后端矩阵（09-05 报告：300 文件规模接入、TLE-DSA 数据流架构），本次是推理插件侧的第一块版图——vllm-plugin-FL 的厂商后端名单新增 txda（vLLM 0.24.0 线）。清微作为 FlagOS 成员单位中较新的芯片厂商，其适配路径呈现清晰的”编译器（FlagTree）先行、推理框架（vLLM 插件）跟上”顺序；txda 后端的合入方式（厂商自己提 PR、自己维护）也是成员单位深度参与的正面样本。

3.2 天数智芯（iluvatar）：0.20.2 确定性技术路线定案——flag_gems GEMM 族整族黑名单（09-07）

来源：build-infra #776/#777（19:23/19:24，镜像 tag 登记）、#779（20:21，docs 定案）、vllm-plugin-FL PR #450（在途，09-07 16:59 更新）

  • 镜像登记（#776/#777，09-07 19:23/19:24）：iluvatar-corex4.4.0 与 corex4.5.0 同日登记 vllm 0.20.2 app 镜像 tag 2.1.2-0.2.1_g16e8655.d20260907（plugin 源码指纹 g16e8655，两栈同 tag）——相对前日 g71b9482.d20260906 指纹更新，对应确定性方案迭代后的新交付。
  • 技术路线定案（#779 docs，20:21）：iluvatar 0.20.2 的最终确定性路线是 flag_gems GEMM 族整族黑名单（linear/mm/mm.out/addmm/addmm_/addmm.out/bmm/bmm.out → 回落 native corex ixblas）。根因叙述很完整：vllm_fl 的 flag_gems.enable() 会把 aten::linear 等劫持到 flag_gems triton linear_kernel；该 kernel 被 flagtree 编译后在 live 引擎内逐 launch 非确定（~1-2 bf16 ulp，offline 确定，temp=0 长程解码在近并列采样带翻转），而同源 kernel 用厂商 corex triton 编译则 bitwise 确定（== native）。黑名单必须整族排（native linear 会降级 addmm，只排 linear 仍被劫持）。GEMM 走 native 后 F/T 双路径均 30/30 temp=0 确定，且吞吐反超（F 14.0 tok/s vs flag_gems linear 12.3，native ixblas 快于 flagtree 编译的 flag_gems kernel）；silu_and_mul 保持 flagos（GEMM native 下不再翻转）。编译器差异是分水岭：同一 flag_gems 源 kernel，flagtree 编译非确定、corex triton 编译确定——上游交接已开 FlagGems #6054-6057（linear/mm/addmm/bmm）。4.4.0 T 路径仍需 VLLM_FL_USE_FLAGGEMS_ATTN=1（corex triton 3.1 编不了 vLLM 原生 attention）；4.5.0 T（corex triton 3.2）无需 env；已知非阻塞限制为 4.5.0 T 冷引擎首请求翻转。
  • PR #450 仍在途：iluvatar 0.20.2 的插件侧补丁（symm-mem stub guard、PyTorch sampler 回退，base release/0.2）09-07 16:59 更新后仍未合入。

解读：这条线是 09-05 以来天数智芯交付叙事的第三次转向收敛：09-05 env 注入方案 → 09-06 晚 revert、改插件配置 silu_and_mul 黑名单（#450）→ 09-07 晚以 30/30 实测定案 GEMM 族整族黑名单，且这次是”确定性 + 性能”双赢（排掉 flagtree 编译路径反而更快）。文档把根因落在编译器分水岭——同一 kernel 源码由 flagtree 编译逐 launch 非确定、由厂商 triton 编译 bitwise 确定，这是一个比”哪个算子”更深的结论：在 flagtree 的 live 编译确定性被根治（FlagGems #6054-6057 交接给上游）之前，国产芯片上 flag_gems 算子的确定性交付都要靠黑名单/回落机制兜底。这对 FlagOS 的”flag_gems 全量替换”叙事是重要的诚实注脚；对天数智芯而言，corex4.4.0/4.5.0 双栈 0.20.2 的确定性交付路径自此有据可查。

3.3 沐曦（metax）与寒武纪（cambricon）：sglang 0.5.18 交付线扩围（09-07/09-08）

来源：build-infra #781（09-07 22:49）、#783（09-08 07:18）、#784（07:27）、#773（09-07 13:10）

  • 沐曦 metax-maca3.7.2.1 sglang 0.5.18 线开通：22:49 #781 新增 maca3.7.2.1 的 sglang app 配置（deps_app/app env）；09-08 07:18 #783 登记 app 镜像 tag 2.1.2-0.1.dev1_ga73b27b60；07:27 #784 docs 记录 maca3.7.2.1 的 sglang 0.5.18 F/T 双路径 E2E 通过，并把插件侧 PR #86 写进验证矩阵。runner 配置里 maca3.8.1.3 线也已具备。
  • 寒武纪 cambricon-neuware4.4.3：09-07 13:10 #773 docs 记录 neuware4.4.3 的 sglang 0.5.18 交付（承接前日 0.20.2 侧记录节奏）。

解读：sglang 0.5.18 的交付矩阵在 RC1 切线后继续右移——沐曦 maca3.7.2.1 以”F/T 双路径 E2E 通过 + 插件 PR #86 关联”完成闭环，寒武纪 neuware4.4.3 补齐交付记录。结合前日燧原 tops1.9.10/摩尔线程 musa4.3.6 的 sglang 0.5.18 记录，“vLLM 0.20.2 与 sglang 0.5.18 双推理框架 × 多厂商 SDK 线”的交付矩阵已基本铺开，每条线的登记都带镜像 tag 指纹与插件 commit 关联——这正是 RC1 manifest 里 vllm-plugin/sglang-plugin 双条目（各自 rc1.post1）背后的工程事实。

3.4 外部生态：昇腾验证记录与 from-scratch 修复、昆仑芯 KernelGen 算子、sunrise 新后端接线（09-07/09-08）

来源：build-infra #772（sunrise env）、#775/#780/#782（昇腾）、#778（外部黑名单 lead）、FlagGems-Experimental KernelGen Kunlunxin 算子

  • 昇腾（ascend）sglang 0.5.18 验证与修复：#780（22:10）登记 cann8.5.0 sglang app 镜像 tag 2.1.2-0.1.dev1_g0f98ddc20；#782（09-08 07:16）docs 记录 cann8.5.0 的 sglang 0.5.18 验证；#775（19:46）修复 ascend 从零构建场景下 sglang serve 的 env 注入（USE_FLAGGEMS=0 分支）；#778（20:19）记录 ascend index_select 需要外部黑名单的线索（与 3.2 同族的确定性排查外溢到昇腾）。
  • 昆仑芯（kunlunxin）：FlagGems-Experimental KernelGen 批量合入 Kunlunxin digamma/arctan（minimax 多项式 kernel）/bernoulli 三个算子（1.3，ZhiwenDeng）。
  • sunrise 新后端接线（#772，12:49）：build-infra 为 runner 配置新增 sunrise 厂商的设备可见性 env（TANG_VISIBLE_DEVICES=all，sunrise 工具链线 tangrt1.2.0 此前已列于 runner 清单）。sunrise 尚未出现在已公开的成员单位名单中，按工具链命名（TANG RT）推测为以 TANG 为前缀的加速器运行时；本窗口动作是把其容器启动参数补全，属接入早期阶段。

解读：外部生态三条线分别对应”深度适配厂商”（昇腾——已与成员单位同级，sglang 验证+确定性排查外溢）、”算子众智”（昆仑芯——KernelGen 数学函数算子）、”新后端储备”（sunrise——runner 配置先行，尚无组件合入）。昇腾的 index_select 外部黑名单线索值得跟踪：3.2 的”编译器分水岭”结论如果同样适用于昇腾的 flagtree 路径，说明确定性问题是 flagtree 编译路径的系统性课题而非 iluvatar 个案。

四、总结

本窗口（09-07 10:18 ~ 09-08 10:18）GitHub 侧 91 条窗口内提交、30 仓推送，为近期最活跃窗口之一；新闻侧组件级检索六连平静，但生态侧出现窗口内事件（上海论坛）。四条主线：

  1. FlagOS 2.2 RC1 正式切线（09-07 11:11 起）：community 合入 release-2.2-rc1.yaml（25 个清单条目/22 仓库，+252 行），release-branch-tag 工作流默认切 rc1，随后 11 分钟内至少 12 仓集中打出首轮 rc1.post1 验证 tag（FlagSparse 于 11:27 发布 rc1.post1 release）——昨日”看 community 清单仓库动作”的预判兑现，RC0→RC1 发布管线切换完成。版本锚点：flaggems v5.4.0、flagscale v2.1.0、kernelgen v2.2.0、flagcx v0.14.0、flagtree 0.7.0（triton 3.6/3.5/3.3 三线）；按时间表 09-01~09-24 为多芯片矩阵测试期、09-28 GA。后续信号：rc1.postN 递增节奏与 09-24 前后 RC-final。
  2. FlagScale 训练栈三事件：KERV 具身投机解码训练/推理集成合入（#1278，OpenVLA verifier + LIBERO 推理 + 14 算子 + 33 单测，训练栈首次覆盖具身策略投机解码）；Megatron-LM-FL 与 FlagScale 同晚对齐 Megatron-LM v0.18.2；CICD 移除 inference/serve 管道、聚焦训练（推理职责进一步归 vllm/sglang 插件）。
  3. 确定性课题浮出”编译器分水岭”：天数智芯 0.20.2 最终定案为 flag_gems GEMM 族整族黑名单回落 corex ixblas（#779，F/T 30/30 确定且吞吐反超 14.0 vs 12.3 tok/s）；根因是同一 flag_gems kernel 由 flagtree 引擎内编译逐 launch 非确定、厂商 triton 编译 bitwise 确定，上游交接 FlagGems #6054-6057；昇腾侧出现同类外部黑名单线索。同日 corex4.4.0/4.5.0 双栈以 g16e8655 指纹登记 0.20.2 新交付。
  4. 多芯片交付矩阵与算子矩阵持续右移：sglang 0.5.18 线沐曦（maca3.7.2.1，F/T E2E 通过）、寒武纪（neuware4.4.3）、昇腾（cann8.5.0）记录闭环；清微 txda 后端以厂商自有 PR 合入 vllm-plugin-FL main 线（vLLM 0.24.0）；FlagGems-vllm 同日合入达摩院玄铁 PPU-ZW810E 与海光 DCU 两个专用 fused-MoE 后端；FlagBLAS Ascend L2 例程（CHER/CHER2/SSYR/CSYR）批量补齐；FlagGems-Experimental 建 sync-to-kernelgen CI 并批量同步跨后端 KernelGen 算子。

预判：RC1 已切线，组件默认分支进入”只收 bug 修复”的测试稳定期，未来两周 GitHub 侧看点从”新特性合入”转向rc1.postN 验证 tag 的递增节奏与交付记录密度（build-infra 的记录频率是 RC 进度的最佳代理指标）；FlagGems #6054-6057 的编译器确定性交接值得跟踪（若根治，国产芯片上”flag_gems 全量替换”才真正无后顾之忧）；FlagTree 单 wheel（含 Prism debugger/profiler）与 KERV 具身训练链路是 2.2 GA 时值得验证的两个新能力点；清微（FlagTree 后端 + vLLM txda 线）与外部新后端（sunrise）的接入进度可作成员单位生态扩张的观察项。

附录：完整信源清单

信源 核查结果
GitHub org repos API（flagos-ai，52 仓） 30 仓窗口内推送；社区/FlagScale/FlagGems 等 14 仓默认分支实质合入；FlagSparse/FlagDNN/sglang-plugin-FL/release-info/docs/FlagTree(09-08) 等经默认分支 commits 核验为 PR 分支或标签动作
GitHub commit search（org 全量 91 条，sort=committer-date） 逐条核验 committer 时间与归属仓库；覆盖全部默认分支实质合入
GitHub PR/commit 详情（community #107、FlagScale #1278、FlagGems-vllm #696/#746、vllm-plugin-FL #447/#450、build-infra #779/#772 等） 提供 manifest 内容、KERV 范围、fused-MoE 细节、txda 归属、确定性路线全文
GitHub tags/releases API + 日期核验 FlagSparse v0.3.0-rc1.post1 release 09-07 11:27 发布；FlagCX/FlagGems-sglang/vllm-plugin-FL rc1.post1 tag 存在；12 仓 11:22~11:33 集中推送（RC1 tag 波）
community release/2.2 目录（raw） release-2.2-rc1.yaml 全文 25 条目；schedule_CN.md（08-31 冻结/09-28 GA）；release-branch-tag.yml 默认 rc1
Google News RSS（中英 14 组，走代理） 组件词窗口内零命中；智源研究院词 58 条为社区博客+博彩 SEO 噪音整批剔除；天数/沐曦命中为商业新闻不收录
HN Algolia（FlagOS/FlagGems/flagos-ai/BAAI） 零相关命中
Tavily/web 检索 仅命中 FlagOS 社区上海论坛（CSDN 官方号）一条窗口内生态事件
FlagOS CSDN 官方号（flagos.csdn.net） 论坛公告 09-07 09:57 发布（6a9e1a10…）；最新内容确认无其他窗口内更新