8 月 18 日到 25 日，AIGC 开源栈的变化集中在同一个方向：运行时开始把“模型支持、硬件后端、量化格式、缓存布局和动态调度”当作一组联合交付物。vLLM 和 SGLang 继续推进 speculative decoding、MLA、MoE 与多模态模型支持；FlashInfer 和 FlashAttention 4 保持高频 RC/beta 节奏；Megatron Core 把 MoE 路由分析、量化 checkpoint 流式加载和 CUDA Graph offload 放进同一个基础设施版本；Diffusers 与 ComfyUI 则继续扩大视频、音频和模块化扩散工作流的覆盖面。

本文统计窗口为 2026 年 8 月 18 日 00:00 至 8 月 25 日 23:59（UTC），以各项目官方 GitHub Release 的公开时间为准。稳定版、RC、beta 和 nightly 明确区分；版本说明中的性能、硬件和兼容性结论均来自项目方公开信息，不代表 AIGCage 独立复测。

一、本周结论：开源推理栈进入“版本组合”阶段

  • Serving 不再只是加载模型。 speculative decoding、MLA、MoE、量化和 CUDA Graph 需要同时命中后端能力与硬件路径。
  • 稳定版之外，RC/beta 的发布密度仍然很高。 FlashInfer、FlashAttention 4 和 TensorRT-LLM 的版本状态必须在部署清单里单独标注。
  • 模型支持正在进入视频和音频。 SGLang v0.5.18 与 Diffusers 0.40.0 都把新的视频/音频模型和模块化 pipeline 作为重要发布内容。
  • 基础设施开始暴露更多运行时状态。 Megatron Core 的路由 trace、专家可预测性、激活 offload 和流式量化加载，都是为了让训练/推理调度可以被观测和回归。
  • 硬件特化没有消失，而是下沉到后端。 SM12x/Blackwell、FP4/NVFP4、MLA、DeepEP、CuTeDSL、cuDNN 和 P2P layout 共同决定一个版本是否真正可用。

二、Serving：vLLM 与 SGLang 同时推进模型覆盖和执行路径

vLLM：v0.28.0 稳定版与两个 RC 在同一窗口内连续出现

vLLM v0.28.0 在 8 月 24 日进入公开 release 页面；本次发布标题是 Pin Cython below 3.3 for arm64 tilelang sdist，直接指向 arm64/Triton-TileLang 构建链兼容性，而不是单一模型功能。窗口内还出现 v0.28.0rc1 和 v0.28.0rc2，后者的发布标题指向 DFlash2 的 local convolution 与 candidate selector。

这组版本值得关注的地方是发布节奏：同一个 minor 版本同时经历 RC 和稳定版，说明 speculative decoding、构建依赖和多硬件路径仍需要快速收敛。已经运行 v0.27 系列的团队，升级前应把 arm64 安装、DFlash2 draft/verify、首请求编译、量化 checkpoint 和不同 batch 形态纳入回归；不能仅凭主模型能加载就判断升级安全。

SGLang v0.5.18：模型覆盖、启动权重加载和后端融合一起升级

SGLang v0.5.18 于 8 月 22 日发布，release notes 标注本版包含 710 个 PR、212 位贡献者。新增模型覆盖 Muse Glimmer、Intern-S2-Mobius、SANA-Video、LingBot-Video-MoE、LTX-2.5、Cosmos3 Edge/Distilled 和 LongCat-Image 等。

对 serving 最有工程含义的变化包括：

  • checkpoint staging 可以在 CUDA Graph capture 期间和存储读取重叠；官方在 Qwen3-32B/H100 上报告启动时间比串行 prefetch 更快，并给出 35.6s 对 84.8s 的默认路径对比；
  • TP LMHead 的 allgather + scatter 合并成 pure-DP dp-attention 下的单次 all-to-all，DeepSeek-V4-Pro/B200 decode 的 LMHead 时间从 320 μs 降至 169 μs，TPOT 从 36.97 ms 降至 35.67 ms；
  • FlashInfer MNNVL 用于 pure allreduce，小 batch Blackwell decode 官方报告最高 6.9% 增益；
  • AMD 上支持 NVFP4 checkpoint 的加载路径，不保留完整精度副本；
  • Kimi K3 的 MLA verify、AITER prefill 和 gfx950 decode 路径分别给出吞吐、ITL 和长上下文优化数据；
  • SGLANG_CACHE_DIR 统一收纳 Triton、FlashInfer、Inductor、DeepGEMM 与 CUDA driver cache，升级后第一次启动会重新编译一次。

v0.5.18 更像一个“运行时组合版本”：模型支持、权重 staging、TP 通信、FlashInfer、量化和 cache 目录同时变化。部署时应把首次启动和稳定运行后的性能分开测量。

三、Kernel 与量化：RC/beta 发布仍然围绕硬件边界快速修正

FlashInfer：v0.6.18rc4 到 rc8 连续推进，nightly 仍然存在

FlashInfer 在本窗口内连续发布 v0.6.18rc4、rc5、rc6、rc7 和 rc8，同时出现 8 月 18 日、19 日的 nightly builds。这不是稳定版 v0.6.18，而是候选版本持续修正阶段。

对使用 FlashInfer 的上层项目来说，最重要的不是“版本号更大”，而是依赖组合的稳定性：vLLM/SGLang 的 attention、MLA、MoE 和量化路径可能绑定特定的 FlashInfer API 与编译缓存。建议锁定完整矩阵：CUDA、PyTorch、FlashInfer、上层 serving、GPU 架构、dtype 和模型 checkpoint；不要在生产环境直接跟随 nightly。

FlashAttention 4 beta27：一行变更也可能改变构建边界

FlashAttention 4 beta27 于 8 月 19 日发布，页面明确标注为 Pre-release。本版公开变更只有一项：Relax CUTLASS DSL requirement。

这类版本不适合只看 changelog 数量。FA4 的构建、CuTe/CUTLASS DSL、CUDA 版本和 SM 目标存在耦合，放宽 DSL 要求可能改善安装范围，也可能改变编译时约束。升级验证至少应覆盖固定/动态 shape、varlen、不同 SM、前向/反向和编译缓存命中，并保留 beta26 或稳定后端作为回退。

TensorRT-LLM：v1.3.0rc22.post1 与 rc23.post1 属于发布流水线修复

TensorRT-LLM 在 8 月 18 日出现 v1.3.0rc22.post1 和 v1.3.0rc23.post1。两个版本都属于 RC post release，其中 rc23.post1 的公开标题是恢复必要的 CI release stages。

这类版本的重点不一定是新增算子，而是发布产物是否可构建、可测试、可被下游消费。依赖 TensorRT-LLM 的镜像流水线应同时核对 wheel/container 来源、CUDA/TensorRT 版本、插件编译和 engine 生成；RC post release 不应与稳定版混写在同一个部署标签里。

四、训练与并行基础设施：Megatron Core 把路由、offload 和量化加载公开出来

NVIDIA Megatron Core 0.19.0：MoE 的“可观察性”成为版本能力

NVIDIA Megatron Core 0.19.0 于 8 月 19 日发布。MoE 方向新增 quantile balancing router，以每专家路由偏置做无 auxiliary-loss 的负载均衡；支持 fused shared-expert MLP、THD packed-sequence MoE dispatch，以及训练/推理 routing trace、专家集中度和 one-layer-ahead predictability 分析工具。

模型和并行路径包括 HybridModel、DeepSeek Sparse Attention 的 backend-neutral CP/THD 支持、MLA 层、NCCL EP dispatcher 和 per-sequence AlltoAll 融合。性能与显存侧则加入 CUDA Graph-compatible activation offloading，以及对 FP8、MXFP8、blockwise-FP8 和 NVFP4 checkpoint 的 streaming quantized loading，避免为整个模型一次性申请 BF16 scratch space。

这组变化说明 MoE 基础设施正在从“能把 token 发给专家”走向“能解释路由、预测集中度、流式搬运权重并在 graph capture 中控制激活”。对于训练/推理团队，路由 trace 和 offload telemetry 应该进入日常回归，而不是只在性能异常后临时打开。

五、生成工作流：Diffusers 和 ComfyUI 把视频、音频与模块化 pipeline 推向常规路径

Diffusers 0.40.0：MiniMax-H3、音频 pipeline 与 tensor parallel support

Diffusers 0.40.0 于 8 月 20 日发布。官方说明本版新增多条 pipeline，包括 LTX2.5、MiniMax H3 和 Wan Animate 2，并将 Modular Diffusers 从 experimental 阶段推进到 stable support，同时加入 minimal tensor-parallel support。

MiniMax-H3 的集成把文本条件、媒体条件、视频和音频 latent 放进同一个 packed sequence，由单一 transformer 进行去噪，没有独立 vocoder 或后处理音频 pass。版本同时引入 MiniMax Music 3 和 Stable Audio 3 路径。对工程团队而言，重点是 pipeline 不再只是“图像生成 + 一个 VAE”，而是包括多模态条件、音频采样率、模块化 checkpoint 分片、任务级下载和并行策略；升级时要测整条数据流，而不是只测 import。

ComfyUI v0.33.3 与 v0.33.4：小版本连续发布，工作流兼容仍在收敛

ComfyUI 在本窗口内发布 v0.33.3 和 v0.33.4。两版都是短周期维护发布，公开页面没有把它们包装成新的大版本能力；对生产工作流来说，更重要的是 custom nodes、模型权重、PyTorch/CUDA 和视频/音频节点的组合是否仍能复现。

建议把 ComfyUI 版本、Python 依赖、模型/VAE、custom nodes、采样参数和输出编码器一起固化成 manifest。连续小版本可以先在复制工作流中验证，再切换主环境；尤其要保留低显存、长视频、多帧 latent 和中途恢复测试。

六、从版本活动看下一阶段的工程接口

1. “支持一个模型”正在变成后端依赖图

SGLang 的 Kimi K3、DeepSeek-V4、LTX-2.5 和视频模型支持，同时涉及 MLA geometry、FlashInfer、DeepEP、量化、CUDA Graph、cache 和通信。模型类只是入口，真正的可用性取决于后端组合是否匹配。

2. RC/beta/nightly 必须进入发布治理，而不是被当作稳定版

FlashInfer 的 rc4—rc8、FlashAttention 4 beta27、TensorRT-LLM 的 RC post release 和 vLLM 的 RC/稳定版切换，都说明底层栈的发布节奏快于业务系统的升级节奏。版本清单应包含状态、发布时间、回退版本和已验证硬件。

3. 首请求和持续吞吐需要分开验收

SGLang 的 checkpoint staging、统一 cache 目录、CUDA Graph capture 和首次重新编译，都会让 first-start 指标与 steady-state 指标不同。发布评估至少要分出安装/构建时间、首请求、warmup 后吞吐、尾延迟、显存峰值和异常回退。

4. 量化已经成为跨组件契约

FP4/NVFP4、MXFP4、FP8、scale、checkpoint loader、MoE route packing 和 Graph capture 互相影响。一个版本支持某种 dtype，不代表完整路径从加载、转换、Kernel 到结果校验都已经闭合。

本周开源栈留下的实操清单是：为每个模型保存 runtime/backend/硬件/dtype/cache 的组合矩阵；把 RC、beta、nightly 与 stable 分开部署；在升级后同时回归首请求、warmup、长上下文、MoE、量化、动态 shape 和异常路径。这样才能把“发布说明里的支持”转化为真实服务中的可重复行为。

本期开源变更

整理说明：本文依据项目官方 GitHub Release 与公开文档整理。版本状态、硬件验证范围和性能数字均为项目方报告，不代表 AIGCage 独立复测；稳定版、RC、beta、nightly 与连续小版本不应视为同等生产承诺。