8 月 3 日到 10 日，AIGC 开源社区最重要的变化，是模型发布和运行时支持开始在同一周内完成闭环：SGLang 先把 Kimi K3 和 MiniMax-H3 接入服务路径，vLLM 随后在 v0.27.0 中交付 Kimi K3 的完整栈，Transformers 5.15.0 则把新的多模态模型、线性注意力和 cache 接口一起推进。与此同时，FlashAttention、ComfyUI 和 Transformer Engine 继续补齐 Kernel、视频工作流和量化训练的工程细节。

这已经不是“某个仓库新增一个模型类”的节奏。对 2.8T 级 MoE、混合注意力、视频扩散和长上下文模型来说，模型文件、tokenizer、前后端、Kernel、KV Cache、CUDA Graph、量化和 OpenAI 兼容接口必须同时到位，用户才能真正启动服务。

本文统计窗口为 2026 年 8 月 3 日 00:00 至 8 月 10 日 23:59（UTC），以各项目 GitHub Release 的公开时间为准。北京时间会将 vLLM v0.27.0 显示在 8 月 11 日清晨，因此这里不按本地自然日截断。文中的性能数字均为项目方在特定模型、硬件和参数下公开的结果，不代表 AIGCage 独立复测。

一、本周结论

  • Kimi K3 成为运行时的共同压力测试：SGLang v0.5.17 和 vLLM v0.27.0 都交付了 day-0 支持，涉及 KDA、MLA、MoE、MXFP4、DSpark、DCP、HiCache、DeepGEMM、LoRA 和多模态前处理。
  • Serving 正在从 Python 单体向分层执行栈演进：SGLang 加入 Rust 前端，vLLM 强化 Rust gRPC 控制面；请求入口、tokenizer、调度器、KV 事件和 GPU 执行开始分层。
  • 缓存和状态管理比单纯降 dtype 更重要：vLLM 的多层 KV offload、SGLang 的 session-aware Radix Cache、FlashAttention 的 SM100/稀疏 MLA 修改，都在处理状态的存放、恢复与复用。
  • 视频工具链继续变成系统工程：ComfyUI 0.30/0.31 同时处理 MiniMax-H3、Wan-Animate2、视频音频采样、VAE offload、显存 pinning 和安全边界。
  • 版本升级会带来环境与行为变化：Transformers 5.15.0 引入线性注意力 Kernel opt-in、cache crop API 变化和 PyTorch 2.13/CUDA 13 CI 迁移，升级后要重新跑兼容性和性能回归。

二、Kimi K3：开放模型把 serving 栈的缺口一次暴露出来

SGLang v0.5.17：从 day-0 模型支持到 Rust Server

SGLang v0.5.17 在 8 月 8 日发布，官方列出 582 个 PR、194 位贡献者。它对 Kimi K3 的支持不是单一 modeling 文件：包括 2.8T 参数、多模态 LatentMoE、896 个专家、top-16 路由、1M token 上下文、69 层 KDA 线性注意力与 24 层 MLA，并接入 DCP、DSpark、chunked-prefill、DCP decode、KDA-aware prefix cache、HiCache L2、量化权重 LoRA 和 OpenAI 兼容服务。

同一版本还加入 MiniMax-H3 的 day-0 支持，覆盖文生视频音频、首尾帧条件和参考视频/图像/音频条件三类任务；并加入 EmbeddingGemma、LFM2.5 等模型。项目方给出的硬件验证范围包括 GB300、B200、H100、AMD MI300X/MI355X 和双 RTX 5090，但这些是 SGLang 发布说明中的验证范围，不等于每种组合都具备相同性能或生产稳定性。

更值得关注的是 Rust Server 初始支持：网络入口、请求校验、tokenizer manager、egress 和 OpenAI API 等前半段开始从 Python 迁移到多线程 Rust，GPU scheduler 之前的路径被单独抽出来。对高并发推理来说，这条路线的目标是降低 host-side 开销和扩展控制面，而不是简单把 CUDA Kernel 换成 Rust。

SGLang 还加入 session-reference-aware Unified Radix Cache，允许 Agent 或 RL rollout 携带稳定的 session_id，让 eviction 知道哪些前缀仍被活跃会话引用。这比按纯 LRU 做前缀淘汰更接近长任务服务的实际生命周期。

vLLM v0.27.0：完整支持栈和大规模服务能力同时落地

vLLM v0.27.0 在本窗口末发布，官方列出 561 个 commit、242 位贡献者。它把 Kimi K3 的支持拆成模型文件、Kernel、Python/Rust frontend、AttnRes kernel、DeepGEMM、compressed-tensors、DSpark AR fusion 和 shared expert sharding，而不是把“支持模型”停留在加载阶段。

这一版本还交付了几条对推理工程更重要的路径：

  • KV offload 变成多层状态管理：支持 P2P secondary tier、按请求的 tier filter、可插拔 eviction policy、self-describing KV event，以及跨并行方式的 canonical KV page mapping。
  • 混合模型的 P/D 解耦继续推进：NIXL 支持 MLA+SSM 混合模型的 prefill/decode，支持异构 P/D block size，并加入 MoRIIO 的异构 TP↔DP 路由。
  • 首请求启动成本被显式处理：JIT warmup、runner-owned Triton warmup 和 renderer warmup 用于避免第一次请求承担编译和初始化停顿。
  • Model Runner V2 扩展到非生成任务：加入 encoder-only attention、embedding/classification pooling、token classification、token embedding 和多模态 CPU 路径。
  • DeepSeek-V4 获得一组端到端优化：发布说明列出跳过空 c128 launch、减少 topk/router、workspace reuse、移除冗余 full kernel 等改动，部分项目方结果达到个位数 E2E TTFT 改善或更高的局部 Kernel 加速。

v0.27.0 同时把 PyTorch 升级到 2.13.0、torchvision 0.28.0 和 Triton 3.7.1。对现有部署来说，这不是普通的小版本升级，容器、编译器、CUDA、FlashInfer 和自定义 Kernel 都需要重新确认。8 月 11 日 UTC 发布的 v0.27.1 不在本期统计窗口内，留给下一期。

三、底层 Kernel 与量化：从算子速度转向状态和首请求成本

FlashAttention 4 beta25：处理 SM100 调度和稀疏 MLA 边界

FlashAttention 4 beta25 在 8 月 5 日发布。本版改动不多但很底层：加入 CuTe/SM100 的 varlen dynamic persistent scheduler 和 metadata，修正 ROCm CK varlen forward 的 binding 参数不匹配，并修复 sparse MLA backward 在 -1 sentinel index 上错误 scatter dK/dV 的问题。

它仍然是 beta 版本。对 SM100、变长输入、稀疏 MLA 和 ROCm 路径来说，升级时应保留固定输入的正确性、数值误差和 kernel launch 配置对比，不能只看 pip 包版本是否安装成功。

Transformer Engine 2.17.1：小修复也会影响量化 checkpoint 安全

Transformer Engine 2.17.1 是 8 月 7 日的 patch release，修复了无状态 quantization recipe 下 checkpoint “extra state” 被反序列化的问题，并增加显式环境变量 guard 来控制有状态 recipe 的 extra state 加载。

这类改动看起来不像性能优化，但它直接影响量化 checkpoint 的加载行为和安全边界。训练平台升级时，应把 checkpoint load、resume、量化 recipe 和多进程启动一起加入回归，而不是只测 forward。

Transformers 5.15.0：模型接口、cache API 和 Kernel 默认值一起变化

Transformers v5.15.0 在 8 月 10 日发布，加入 Meta Muse Glimmer、GraniteMoeSWA/GraniteSWA、A.X-K1/K2 和 Cosmos3 Edge 等模型支持，也修复和优化了 MLA cache compression、视觉模型 Flash Attention 变长路径、线性注意力模型和多模态预处理。

对推理服务最需要留意的是行为变化：

  • Mamba、GDN 和 Conv-only 等线性注意力模型的 Kernel 改为 opt-in，依赖自动 Kernel 选择的部署要显式打开；
  • cache cropping API 只接受负的相对偏移，不再接受绝对大小；
  • sliding-window cache layer 可以回滚并与 speculative decoding 配合；
  • Qwen2.5/3-Omni 增加 batched audio generation；
  • static cache 不再作为 generate() 的属性保存，以减少跨调用的意外内存占用；
  • FSDP plans 扩展到 94 个 ForCausalLM 类，并增加端到端 FSDP 测试。

这说明上层模型库正在承担越来越多的系统职责：attention backend、cache 生命周期、Kernel 下载和并行计划都会改变下游 serving 的行为。

四、ComfyUI：视频生成工作流开始暴露真实的内存和失败路径

0.30.0：把模型支持和主机内存管理放在一起

ComfyUI v0.30.0 在 8 月 3 日发布，加入了基于 pinning infrastructure 的 MRU 主机内存权重加载策略、可配置 DETAIL 日志旁路、PrunaVAED、LTX2.3 相关修复、数据集目录隔离和更严格的路径检查。

视频方向的改动包括 MiniMax-H3 Partner Node、MiniMax-H3 原生支持、H3 的 768P 分辨率，以及音频 latent 缺失时的 LTXAV 修复。这里的重点不是节点数量，而是当视频、音频、VAE 和模型权重同时进入工作流时，显存、主机内存、缓存和采样失败会互相影响。

0.31.0：继续补齐 H3、Wan-Animate2 和视频音频采样

ComfyUI v0.31.0 在 8 月 8 日发布，修复 MiniMax-H3 VAE 的设备转换、noise mask sampling、audio VAE full offload 和 EasyCache 音频损坏，并加入 Wan-Animate2、FLUX 3 video、Topaz Bloom 2/Wonder 3.5、SeeDance 2.5 等支持或 Partner Node 更新。

这两个版本连续出现，说明视频工作流的“可用”不是一个模型能否被导入，而是要同时覆盖采样器、音频 VAE、offload、缓存、参考条件和输出编码。对生产工作流，升级后至少应该复测：长视频峰值内存、音频时长、首帧/尾帧条件、VAE offload 和异常恢复。

五、本周判断

  1. 模型支持已经变成跨仓库协议。 Kimi K3 的真正支持需要模型结构、MoE 路由、KDA/MLA Kernel、量化 checkpoint、KV Cache、speculative decoding 和 OpenAI API 同时工作。
  2. Serving 前端正在独立成层。 SGLang 的 Rust Server 和 vLLM 的 Rust gRPC 控制面，都在把 ingress、tokenizer、控制、KV 事件与 GPU scheduler 分离，未来 benchmark 需要记录 host path，而不只是 GPU 型号。
  3. 缓存优化不再只是压缩。 session reference、KV tier、eviction policy、warmup 和 canonical page mapping 共同决定长上下文与 Agent 服务的实际性能。
  4. 多模态工作流的瓶颈正在外溢。 视频生成的性能不只由 denoiser 决定，音频 VAE、主机内存、offload、编码、Partner Node 和失败恢复都会进入端到端时间。
  5. 升级验证要从“能启动”扩展到“路径命中”。 需要确认 attention backend、quantization recipe、cache policy、CUDA Graph、warmup、offload 和 fallback 是否真的按预期生效。

对工程团队来说，本周最值得复用的工作方式是：把“模型版本—运行时版本—Kernel 版本—硬件—精度—cache policy—启动参数”作为一个完整 manifest 保存下来。只有这样，开放社区的快速发布才不会变成无法解释的性能漂移。

本期开源变更

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