本期窗口为 2026/9/16—9/22（UTC）。按正式版本发布日期、项目公告或本周实质更新收录；版本中包含的 PR 可能更早合入，下文不把它们重新算作本周首次实现。

vLLM 0.30、SGLang 0.5.20、ComfyUI 0.37 和 FlashInfer 0.7 都在本周发布。值得翻一翻各自的模型专用路径：DeepSeek 的缓存记录按 GPU 架构选择，Kimi 减少了混合 batch 的数据搬运，GLM 的 KDA prefill 换用新内核，Qwen 文本编码器也补上了 CUDA Graph 和 MTP 的执行细节。

视频生成方面，VDN-H3 值得接着跟进。它不是本周才第一次放出代码，本周的新内容是论文、参考图任务进展，以及 SGLang 新正式版里的交付。

本周版本速查

项目 本期正式版本 日期 升级前最值得确认的事
SGLang 0.5.20 9/18 CUDA 12 构建退场；Responses 状态存储改为显式开启
ComfyUI 0.37.0 9/21 Qwen 编码器执行路径、动态显存与 fast-disk 行为
vLLM 0.30.0 9/22 模型专用后端和缓存格式；GPTQ activation ordering 移除
FlashInfer 0.7.0 9/22 从上期 RC 进入正式版；核对 SM、形状与上层框架版本

版本事实来源：SGLang、ComfyUI、vLLM、FlashInfer。

1. MiniMax-H3：VDN 的本周增量是参考图任务与正式版集成

OpenVDN 项目在 9 月 17 日更新论文和 Ref2VA-like 参考图生成能力，复用现有 checkpoint 的 FL2VA 权重。本月 6 日代码与权重已发布，14 日已有 SGLang 部署说明，因此本期不再把“VDN 开源”当作新消息。

VDN-H3 将视频局部 Softmax 与线性记忆结合，再做八步蒸馏。落到实际使用，checkpoint 不只是一个通用加速 LoRA：还需要线性分支、gate 和匹配的混合 Attention backend。SGLang 的集成 PR 为它设置了专用 pipeline，并在该实现中限制不兼容的 backend 和执行选项；随手换回 dense Attention，不能视作等价运行。

三个常见数字对应不同记录：论文报告八张 B200、约 14.3 秒 768p 视频的 DiT 去噪为 6.70 秒；当前项目 README 给出约 6.9 秒去噪、9.0 秒端到端；SGLang 集成 PR 的当时测试则为 7.45 秒去噪、9.3 秒预热后请求。它们的修订与配置不同，本期不挑其中最快的一项替所有路径背书。

试用时可以先选一段熟悉的参考素材，观察人物、长动作是否稳定，并记录从文本编码到音视频解码的完整等待时间。代码仓库的 Apache-2.0 与模型卡标注的 MiniMax-H3 community license 也要分开读，不能把代码许可自动套到基础模型与衍生权重上。

来源：项目与更新记录、模型卡、SGLang 集成 #37903。

2. vLLM 0.30：DeepSeek、Kimi 和 GLM 的收益各有出处

9 月 22 日发布的 vLLM 0.30 正式纳入 DeepSeek-V4.1-Flash、GLM-5.3-Flash 等支持与优化。新增模型列表很长，但下面几处变化更能帮助判断自己是否该升级。

DeepSeek-V4.1：MXFP8 记录不是论文 FP4 缓存的同义词

V4.1 在 SM100 的 FlashMLA 路径改用专用 MXFP8 KV 记录，连 RoPE 维度一起量化。对应 PR 中，每条记录从 584 bytes 减至 528 bytes，scale 的分组也由 64 维改成 32 维；页对齐还减少了一部分 padding。

这个 528 bytes 是后端记录布局的计量，不是论文中跨层汇总的全局缓存 890 bytes/token，二者不能直接作除法。PR 也明确将新路径限制在 SM100：SM90、ROCm 与 FlashInfer 的 SM120 路径仍保留另一种记录。启动参数里同样写着 fp8，不代表底层缓存布局完全一样。

来源：KV 记录变更 #56893。

Kimi K3：少做八次搬运，比再加一个抽象层更直接

本版收录的 KDA mixed-batch 优化，利用普通 decode 与推测 decode 在 packed batch 中的连续布局，直接取切片，输出也写入最终缓冲区。原来每层六次 index_select 和两次 index_copy_ 因而被省掉。

PR 标题报告 5.2%—7.7% 端到端吞吐提升，测试绑定 TP8、DSpark 和指定工作负载。这类优化没有改变模型能力，主要节省 gather/scatter、临时张量和 launch 成本；若实际流量没有对应的混合 batch，不能照搬这个收益区间。

来源：Kimi K3 数据搬运优化 #56159。

GLM-5.3-Flash：KDA prefill 的加速，不等于整个请求同倍变快

GLM 的新路径用 FlashKDA 替换原来的 Triton chunk 实现。PR 在 GB300、指定每层形状上给出 1.7—3.8 倍提升，选择条件包括 BF16、head dimension 128、bounded gate 和受支持架构；需要时仍可切回 Triton。

这是 KDA 分块 prefill 的算子比较。推测解码涉及回滚状态，走法并不相同；模型还有其他层和调度开销。评估升级收益时，短 prompt 的 decode 服务与长 prompt 的 prefill 服务最好拆成两组。

来源：FlashKDA 接入 #55737。

v0.30 还带来 GPU 权重缓存式 Fast Start、稀疏 MLA 的主机 KV 层和更多量化配置。它们适合在上述模型正确性回归通过后再逐项打开。尤其使用 GPTQ g_idx 的旧部署，应先读 breaking changes，而不是只替换镜像标签。

3. Qwen3.8-2.4T：PD 部署报告最有价值的是显存账单

vLLM 9 月 21 日的工程报告给出了 Qwen3.8-2.4T 在 GB300 NVL72 上的 prefill/decode 分离配置。8K 输入、1K 输出负载下，报告的两端成绩约为 5000 total tokens/s/GPU 与 180 generated tokens/s/user。前者包含输入、输出 token，后者是单用户生成速率；它们是吞吐—延迟曲线上的不同点，不是同一个配置同时达到的两个指标。

调参从显存开始：全 Attention 状态随 token 数增长，GDN 状态则主要按请求保存。权重之后，还要扣除峰值激活、NCCL、CUDA context、CUDA Graph 预留等，才能估计 KV 容量和并发上限。

另一个容易踩坑的细节是，prefill 与 decode 会各自计算 block size，而状态传输要求两边匹配。理论上还能放下多少请求，也未必等于打开 MTP 后的真实上限，因为推测 token 还会占槽位。

这份材料适合当作超大混合模型的容量估算示例。若换成别的卡数、上下文长度或专家精度，应重新算账，不能只复制最高吞吐对应的参数。

来源：PD Serving of Qwen3.8-2.4T。

4. SGLang 的 NVFP4 KV：先省缓存带宽，算子精度另看实现

9 月 16 日的 NVFP4 KV 工程报告是上期未展开的一项补充。每 16 个值的打包数据占 8 bytes，再加 1 byte block scale，合计约为同数量 FP8 数据的 56%。这比简单说“4-bit 就是 FP8 的一半”更接近实际存储。

低比特存储也不意味着所有 Attention 矩阵乘都使用 FP4。报告的 SM120 decode 实现将数据在内核中解包到 BF16，再进行矩阵运算；prefill 和带缓存前缀的 extend 又有不同的 workspace 路径。

在单张 RTX PRO 6000 Blackwell Server Edition、Qwen3.8-27B、固定并发的长上下文实验里，峰值 batch 的 decode 吞吐提升约 26%—30%。增加驻留并发后收益还能更大，但那同时包含容量收益。报告中的百万上下文属于显式越过原生 262K 限制的性能实验，不能据此宣称百万上下文质量已验证。

准确率也不是完全不变：Qwen3.8-27B 的 SWE-bench Verified 从 FP8 KV 的 77.8% 变为 NVFP4 KV 的 76.2%。当前支持标为实验性，适合按任务回归后评估；不要只看能容纳更多请求，就默认输出质量一致。

来源：NVFP4 KV 实现、测试与限制。

5. SGLang 0.5.20：模型增多，也有需要主动迁移的默认行为

9 月 18 日的正式版包含 GLM-5.3-Flash、Hy4-Preview、Qwen3.8-Flash-Next、K2 Horizon、Nanbeige4.2，以及视频侧 FastH3、VDN-H3 等集成。这是本期的版本交付，不代表每个模型都在本周首发。

升级影响更大的可能是基础行为。CUDA 12 的 wheel 与镜像路径退休，0.5.19 是最后一个提供该构建通道的版本；旧 prefill context parallelism v1 被移除。依赖旧环境或旧参数的部署应先核对启动方式。

Responses API 的状态保存也变为显式 opt-in。没有 --enable-response-store 时，结果检索、previous_response_id 串接和后台请求等依赖状态的功能会被拒绝；PD 部署不能开启该存储能力。

对应 PR 解释了原因：原来的内存字典没有 TTL 或淘汰，PD 两侧的状态读取又无法自然对齐。它是为了避免内存增长和续接失败，不是简单删掉一个兼容开关。客户端若依赖服务器替自己保存会话，应先用完整的多轮请求做回归。

来源：0.5.20 发布记录、Responses 状态存储变更 #39122。

6. ComfyUI 0.37：Qwen 编码器加速之外，还有两项实用修复

9 月 21 日发布的 0.37.0，纳入 Qwen3/3.5/3.8 的 CUDA Graph 与 W4A8 GEMV 支持。相关 PR 还整理了 Qwen3.5/3.8 的 MTP 路径：checkpoint 的 MTP head 起草若干 token，随后批量验证，缓存支持快照与回滚。

固定容量的 Attention cache 和设备侧写位置，使 decode 更适合 graph replay；可用时调用 comfy-kitchen 的融合 DeltaNet kernel，否则保留 eager fallback。这里优化的是相应文本编码器执行路径，不宜写成所有 Qwen 工作流都能自动获得同样速度。

还有两项修复值得检查自己的工作流是否受影响：

  • Wan 的峰值显存：使用 comfy-kitchen Attention 时降低峰值占用。实际节省量应在同一分辨率、帧数和工作流下测量，发布记录未给出通用比例。
  • MiniMax Music 3 的噪声输出：CUDA Graph 打开时，AR 编码器原先可能重放失效输入地址，最终音频出现 NaN。修复改用固定 decode buffers；作者在 RTX 5090、指定模板和固定种子下验证，输出与关闭 graph 的参考一致。这是正确性修复，不是 H3 视频模型的更新。

此外，版本加入 Qwen-image 2.1、MoGe 3，并调整 fast-disk 自动检测与动态显存下文本编码器的放置。Partner Nodes 中的 GPT Image 2 透明背景、Meshy 7.1 等则是外部服务接入，不能归为可本地运行的开放权重。

来源：Qwen 编码器优化 #15623、Wan 显存修复 #16418、Music 3 修复 #16428、0.37.0 完整变更。

7. FlashInfer 0.7：上期的 RC 进入正式版，先核对架构分支

FlashInfer 9 月 22 日发布 0.7.0，上期介绍的 RC 由此进入正式版。下面列的是本版累计交付的能力，部分实现更早已合入主分支。

与热门模型有关的内容包括 KDA/GDN 的状态和 prefill 路径、Blackwell MiniMax sparse attention source kernels、SM100 BF16 MegaMoE、SM120 NVFP4 Attention 与 SVDQuant GEMM，以及 FP8 量化 producer 等。这些组件服务于不同模型和阶段，安装一个新版本不会自动让上层模型切到全部新路径。

SVDQuant 的 SM120/SM121 实现尤其需要看清数据类型：残差主支走 NVFP4，低秩修正中的相关计算仍使用 BF16；它融合部分低秩修正与主 GEMM，并保留 unfused 路径作为正确性对照。PR 的性能表来自 RTX PRO 6000、rank 32、CUDA Graph、warm-L2 条件，不是所有矩阵形状、所有 50 系显卡的统一结论。

实际升级时应把框架 pin 的 FlashInfer、CuTe DSL、CUDA 与驱动视作一组依赖。先确认模型真的调用了新 kernel，再比较延迟；仅从包版本推断已经用上 NVFP4 或新的 KDA backend，很容易看错。

来源：0.7.0 发布记录、SM120 SVDQuant 实现 #4420。

8. 视频理解的另一种瓶颈：GPU 在等 CPU 解码视频

vLLM 9 月 18 日介绍 PyNvVideoCodec/NVDEC 接入。这里的“视频解码”是将压缩视频展开成帧，不是语言模型逐 token decode，也不是视频生成模型的 VAE decode。

短输出的视频描述任务，可能只生成 100—200 个 token，CPU 上的 OpenCV/FFmpeg 却要先处理输入视频。增加 GPU 副本后，这一段前处理容易先饱和。新路径将它交给 GPU 的硬件视频解码单元，并通过多模态处理进程与推理服务配合。

报告使用 Qwen3-VL-8B-Instruct，一卡一个 vLLM 副本，通过代理分发请求；八张 H100 的实验里，吞吐超过 CPU 解码方案的两倍。这是多副本处理视频的结果，不是把同一个模型做 TP8。

硬件解码需要额外显存 workspace。模型和 KV 已经挤满显存时，要把这块预留算进去；也应同时记录 CPU 利用率与送帧速度，确认瓶颈确实在前处理，而不是 Attention 或存储读取。

来源：PyNvVideoCodec 与多 GPU 视频描述。

9. Qwen 的多模态工具：开源的是执行框架，模型调用仍有边界

Qwen-Live-Harness 在 9 月 21 日发布 v1.0.0，围绕 Qwen Omni Realtime API 提供实时音视频交互、后台任务委派与长期记忆。完整桌面体验当前面向 macOS 12+，支持 Apple Silicon 与 Intel；它需要 DashScope 网络服务和相应 API 权限，不要求本地模型权重或 GPU。

配套 Qwen-MM-Plugins 的本周更新包括：16 日将演示视频转成可复用技能的 omni-skill-creator，20 日新增面向物理硬件操作的 MHS 与视频空间推理 video-spatio。项目中有些几何工具可以本地执行，但模型感知与云端推理是另一层依赖。

试用这类框架，可以特意打断一次长任务，检查它如何恢复；再观察后台结果怎样回到当前对话、长视频记忆能否定位原片段。源码让这些执行细节更容易检查，模型 API 的权限与费用则仍需另行安排。

来源：Live Harness 与版本说明、MM Plugins 更新记录。

10. 两个值得单独建实验环境的项目：分阶段量化与桌面出图

Disaggregated Quantization：训练、运行时与 prefiller 权重一起看

与 9 月 22 日论文配套的项目公开了分阶段量化训练、评测和定制 llama.cpp 路径。一个现成的低比特 GGUF decoder 保持不变，额外训练 NVFP4 prefiller；本地运行时再将后者按层从 SSD 读入。

它适合研究长 prompt 的 TTFT 与低比特准确率，但不是上游 llama.cpp 的通用稳定开关。准确率评估所用后端与本地 GGUF 时延路径也不同，README 已专门说明这一点。复现时需要分别记录训练后的 checkpoint、推理分支和权重格式，避免把一条路径的精度与另一条路径的内存占用拼在一起。

截至本次检查，研究仓库根目录未见独立 LICENSE 文件；代码可访问，但授权还需向维护者确认。本文将它列为研究源码入口，不标作许可已经明确的成熟软件包。

来源：训练与评测仓库、定制 llama.cpp。

DIN Deploy：把 FLUX.2 的端侧推理拆成可运行组件

9 月 18 日论文关联的 NVIDIA DIN Deploy 提供 ONNX Runtime 本地推理示例，包含 FLUX.2 图像生成、ASR 与 SAM2 等路径。图像生成研究用小文本编码器加 translator，配合量化和权重 streaming，降低桌面端运行门槛。

论文在 RTX PRO 6000 Blackwell 上的亚秒级结果，不应写成仓库所有后端、所有消费卡的现成功能保证。首先确认示例支持的导出路径、execution provider、精度和缓存编译方式，再测自己的冷启动与热运行。仓库代码采用 Apache-2.0，第三方依赖和模型另有许可说明。

来源：DIN Deploy、相关论文。

升级顺序：先确认结果正确，再追速度

这周的更新不太适合一口气全部装进同一个环境。比较稳妥的做法是保留旧镜像和 checkpoint，按实际任务各挑一条路径：

  1. H3 用户先核对 VDN 专用 backend 与参考图任务，再分开记录去噪和完整请求时间。
  2. Kimi、GLM、DeepSeek 服务先回归长短 prompt、混合 batch、缓存恢复与工具调用，再逐项开启新内核。
  3. ComfyUI 工作流先检查图像、音频是否正确，尤其是 CUDA Graph、低显存和第三方节点组合。
  4. FlashInfer、NVFP4 KV 与分阶段量化单独建对照环境，保存软件修订、真实 dispatch 路径和评测集。

对模型服务，升级后的峰值速度只是其中一项。第一次请求、恢复会话、显存接近上限、用户中途取消时还能否正常工作，同样值得留一组测试。

配套阅读：AIGC 论文一周：9/16—9/22。