本期窗口：2026/9/3—9/9；资料截止北京时间 9 月 9 日 10:20。 日期核对采用项目发布与 Git 提交记录的 UTC 时间。
这一周值得关注的更新，大多能落到具体部署问题上：FastH3 接上稀疏注意力后究竟省了哪段时间；GLM-5.3 的 KV 放不下时，能否继续 decode；一张消费卡跑 H3，瓶颈到底在显存、主机内存还是 SSD；量化权重存在了，推理框架有没有真正走到对应内核。
本文先展开热门模型，再补底层库。需要提前说明：SGLang 0.5.19 在本周发布，包含此前数周累计合并的工作。 下文会把这些内容写为“本周版本收录”，不把 8 月的 PR 重新包装成本周首次出现的优化。开发分支和正式版本也单独标注。
一、MiniMax-H3 / FastH3：这次把稀疏 Attention 的条件讲清楚
1.1 FastH3 新增 VSA 对照：10 秒视频的服务端耗时降到 7.278 秒
vLLM-Omni 的 H3 工程文章最初发表于 9 月 1 日，本期关注的是 9 月 9 日追加的 VSA 测试与适配说明，而不是把整篇旧文算作新发布。
FastH3 是 FastVideo 基于 H3 蒸馏的四步学生模型。此次更新区分 Dense/Data-Free 与 VSA/Data-Free 两种产物，后者需要匹配的模型文件和 FASTVIDEO_VSA 后端，不是给普通 H3 随便切一个 Attention 名称。
项目在 8×B300、1344×768、24 FPS、四次 Transformer 前向、pure Ulysses 8 上给出对照。Dense 使用 TRTLLM_ATTN，VSA 使用 top-k 64 的 Triton 路径；各设置丢弃一次 warmup，然后每个时长测量一个请求。
| 目标视频时长 | Dense 服务端 E2E，含 MP4 | VSA 服务端 E2E，含 MP4 | 相对加速 |
|---|---|---|---|
| 10 秒 | 9.838 秒 | 7.278 秒 | 1.35× |
| 15 秒 | 14.199 秒 | 10.800 秒 | 1.31× |
在这组测试中，完整 MP4 的生成耗时低于视频播放时长；用户等到的仍是完整成片，并非逐帧流式输出。每个配置只测一个请求，也不足以估计 P95/P99。文章里的 client E2E 使用不同源码版本与计时范围，需与本表分开阅读。
来源：9 月 9 日的精确更新、VSA 与 Ulysses 适配 PR、官方工程文章。
1.2 Base、Turbo、FastH3 不是三个可随意替换的速度档
三条路径的接口约束不同。Base H3 覆盖文本生成音视频、首尾帧条件生成和参考条件生成；Turbo 支持请求级 adapter 切换；FastH3 则在加载时把变更融合进专用学生模型，再进行分片。
当前 FastH3 只接受 T2VA，必须遵守四次前向及 checkpoint 对应的 flow shift，不能再叠加一个请求级 LoRA。VSA 还要求 CUDA、外部 fastvideo-kernel 包，以及 local 或 pure Ulysses Attention；Ring 与 AllGather 的稀疏 Attention 组合被明确拒绝。
分层卸载也有冲突：FastH3 的融合发生在 load_weights()，Distributed Layerwise Offload 安装的是另一套主机权重路径，当前不能组合。若希望靠 CPU offload 把模型塞进更小显存，应检查 Base H3 的部署方案，而不是照搬 FastH3 的最快配置再加一个 offload 开关。
所以“能跑”“任务覆盖完整”和“最低延迟”需要分开选。仅服务文本到音视频，可以评估专用 FastH3；还要首尾帧、参考条件或动态 adapter，就要保留其他服务配置。
来源：当前 H3 部署配方、FastH3 集成、VSA 集成。
1.3 SGLang 本周版本收录的消费卡配方：24 GB 卡要给桌面留余量
SGLang 0.5.19 收录了 H3 的消费卡部署文档。相关修改在 8 月 22—25 日已合并，值得在正式版本节点重新说明，因为它修正了一个常见测量漏洞。
在真实桌面 4090 上，用满“24 GB 预算”并不安全。配方先前用 set_per_process_memory_fraction 做限制，但在 24 GiB 卡上设置 24 GiB 等于没有留下桌面空间。更新按 22 GiB 重新测量，预留约 2 GiB；在 VAE decoder 改成 FP16 驻留、传输能够重叠之后，保留 10、6、4 层 DiT 的时间分别为 8.41、8.48、8.51 秒/步。
因此桌面配方选择 --dit-layerwise-resident-layers 6：相比保留 10 层，节省约 2.4 GiB，单步代价不到 1%。这些是项目指定配置的测量值，不能脱离分辨率、帧数和主机内存直接当成任意 4090 的速度。
另一个容易忽略的资源是主机 RAM。文档讨论的未裁剪部署权重合计约 108 GB，12 GB 显存加 32 GB 主机内存时需要依赖映射文件重读，NVMe 带宽会直接进入每步耗时。只报“最低显存 12 GB”会漏掉真正的部署成本。
DGX Spark 配方则利用统一内存，但该 H3 文档中的对应档位标为推导、未实测。不能把它与已经测量过的消费卡行放在一起，称为全部完成验证。
来源：24 GB 桌面安全配方、消费级 GPU 与主机内存说明。
1.4 Ascend H3：适配不只是把 CUDA device 改成 NPU
本周版本也收录了 8 月已合并的 Ascend H3 支持。H3 会把真实多模态 token 与序列并行对齐所需 padding 打包，Laser Attention 路径只计算真实 token，保持外部形状，并将 padding 输出补零。
实现还处理 BF16 激活进入 FP16 Laser 内核时的缩放补偿；H3 Transformer 走 laser_attn 时，Qwen3-VL 文本编码器仍使用 torch_sdpa。随机数、autocast、驻留逻辑及 FFmpeg 输出也做了平台适配。
这些细节意味着，“H3 支持 Ascend”不是所有 CUDA 加速组件同时可用的承诺。复现应从对应拓扑和 cookbook 起步，再逐项验证 Cache-DiT、精度和媒体输出。
来源：Ascend H3 完整适配说明。
二、GLM-5.3：Hybrid HiSparse 让部分 KV 卸载后仍能继续 decode
9 月 8 日，vLLM 发布 GLM-5.3 Hybrid HiSparse 工程报告。它面向长上下文、多轮 Agent 请求造成的 KV 压力：抢占请求后重算前缀很贵；传统卸载虽然保存了数据，但完整 Attention 要运行时，仍需把所需历史搬回 GPU。
Sparse-MLA 的不同之处在于，indexer 每步只选 top-k token。Hybrid HiSparse 利用这一点，在显存充足时保留完整 GPU 驻留，出现压力后才把冷页交给 CPU，并在 GPU 保留被选中的热点行。热缓冲与普通 KV 页共享同一分配池，不另外硬切一块显存出来。
实现区分三种状态：全部驻留、部分驻留，以及复用 CPU 前缀时的无完整页驻留。已在 GPU 的 token 原地读取，热缓冲命中则复用，缺失才从 pinned host memory 搬回对应行。这样请求可以在历史 KV 仅部分驻留时继续解码。
需要保留两条限制。第一，indexer KV 不由 HiSparse 本身压缩成固定大小，仍有随上下文增长的 GPU 成本；第二，MTP 验证会增加热缓冲需求，不能只按一次 decode 的 top-k 估显存。
项目报告覆盖单机 8×H200，并给出指定源码提交的复现方式。其 OpenHands 对照使用 TP8、MTP3、FP8 KV、142K admission limit；普通卸载使用 512 GiB 主机池，混合方案分配 384 GiB HiSparse 加 128 GiB 普通卸载。两者总主机预算保持一致，比只报“显存更省”更有说服力。
这里最该注意的是发布状态：团队计划在 vLLM v0.30 广泛提供该能力，本期复现需使用文中固定的 e8ef1e07bd checkout，不能理解为 pip install -U vllm 已经默认具备。文中的百万上下文容量声明，也不要与 142K 配置的吞吐对照混为同一次测试。
三、SGLang 0.5.19：Qwen、DeepSeek、Kimi 的变化分别落在哪里
9 月 5 日发布的 SGLang 0.5.19 是本期主要稳定版本更新。以下按模型与执行路径挑选，介绍的是该版本收录的能力，不意味着对应模型或 PR 均在本周首次发布。
3.1 Qwen3.8：模型支持之外，草稿模型和内存预算也要匹配
版本列出 Qwen3.8 2.4T-A95B、Qwen3.8-27B 等支持，同时收录对 27B 的消费卡配方重新测量。这个配方将安装基线固定到同一源码和镜像，避免普通推理与 DFlash2 使用不同 build。
RTX 5090 上，DFlash2 BF16 路径需要把 chunked prefill 调为 1024；某些 FP32 草稿路径因内存不够被禁用，而不是给出一个容易 OOM 的参数。DGX Spark 的静态内存比例从 0.85 下调至 0.80，原因是统一内存还要供操作系统使用，原配置会触发 earlyoom。
该次 NVFP4 测试使用的是 RadixArk 的带 BF16 LM head 导出，不是把所有叫“Qwen3.8-27B-NVFP4”的仓库视为同一权重。较大的 LM head 会改变剩余内存，也影响能否加载 draft model。
如果只想复现速度，仍需锁定 checkpoint、draft、state dtype 和 prefill chunk；一个模型名加一张 GPU 型号，信息还不够。
来源：SGLang 0.5.19、Qwen3.8-27B 重新测量与配置。
3.2 DeepSeek-V4：Hopper W4A8 是明确的 SM90 路径
在 Hopper 上，MXFP4 专家可以配合动态 FP8 激活执行 MoE。SGLang 为这条路径增加显式选择：
--moe-runner-backend flashinfer_mxfp4
--flashinfer-mxfp4-moe-precision fp8
该集成要求 FlashInfer 0.6.18 或更新的正确接口。权重预处理会折叠块缩放，并为本地专家保存残余缩放；运行时再按 TP/EP 的专家映射使用它们。早先短暂出现过的旧 ABI 不在支持范围内。
项目报告 W4A8 MoE 内核相对 W4A16 快 1.63—2.08 倍，DeepSeek-V4-Flash 的输出吞吐提高约 11.7%。两组数字的差距很正常：MoE GEMM 只是整条服务路径的一部分。GSM8K 在该次对照中未下降，也不等于所有任务质量无损。
更关键的是架构门槛：这个 fp8 选项针对 SM90，PR 对 SM100、SM120 明确拒绝，避免与它们已有的其他激活路径混淆。H100、B200 与 RTX 5090 不能因为都“支持低精度”就共用同一组选项。
来源：SM90 W4A8 集成与测试、FlashInfer 混合精度 MoE 实现。
3.3 Kimi：MXFP4 checkpoint、线性注意力与专家通信是三件事
版本收录了 Kimi-K2.7-Code 的 AMD MXFP4 配方，使用 amd/Kimi-K2.7-Code-MXFP4，验证平台为 MI350X/MI355X，配方包含 TP4 与 FP8 KV。它是 AMD 提供的量化 checkpoint，不应写成所有 Kimi 模型都原生采用这一格式。
Kimi Linear 相关更新则在 MTP verify/commit 状态推进路径上融合操作，项目报告特定 KDA 形状下耗时下降 45%—63%，输出逐 bit 相同。这里加速的是验证与提交状态的局部步骤，不是整个生成请求快 63%。
Kimi K3 还涉及特定 MoE runner 自动选择、Mooncake 通信路径及多模态预处理修复。部署时要按具体模型架构核对：K2.7-Code 的 AMD 权重配方、Kimi Linear 的状态内核和 K3 的专家并行路径，不能合并成一句“升级后 Kimi 全面提速”。
来源：K2.7-Code AMD 配方、KDA 融合状态提交、K3 Mooncake 路径修复。
3.4 DeepEP v2：先满足量化和模型约束，再谈 CUDA Graph
新 deepep_v2 后端使用 ElasticBuffer。固定容量的通信形状让跨节点 decode 也可以进入 CUDA Graph，prefill 与 decode 分别使用适合自己的布局。
本次集成范围明确限定于 DeepSeek-V3/V4、Qwen3MoE 对应架构，动态 blockwise FP8 专家和 deep_gemm runner。BF16 专家、其他量化契约、部分新架构和 draft worker 组合不属于这次支持范围；PR 特别指出，不能把 Qwen3.8 当成 Qwen3MoeForCausalLM 直接套入。
direct 与 hybrid 是 ElasticBuffer 的拓扑模式，也不是旧版 low_latency、normal 的别名。项目报告性能与旧后端相当，当前价值首先是通信形状与执行路径的改进，而不是宣称任何 MoE 都立刻更快。
四、服务端的其他改动：缓存、AMD 调度与扩散请求隔离
4.1 AMD Lean Attention：解决长短请求混在一起时的空转
SGLang 本周版本收录的 Lean Attention 使用持久化网格，按设备 CU 数安排工作，再根据 KV tile 分布拆分长序列。目标是减少固定 SplitK 网格下的空闲，以及不规则 batch 中少数长请求拖住整个 step 的情况。
项目在 MI355X 上报告，部分不规则负载的吞吐最高改善 1.52 倍、ITL 最高降至原来的约 1/3.62。实现带有保守的自动选择条件，不是强制替代所有 Attention；SGLANG_DISABLE_LEAN_ATTENTION=1 可以关闭。
这类优化的测试集应保留长短请求混合和低 batch 长上下文。只跑长度整齐的大 batch，可能完全看不出作者试图解决的问题。
4.2 Unified Radix Tree 与分层缓存：升级后要测恢复，不只测命中率
0.5.19 将 Unified Radix Tree 作为默认缓存路径；相关变化还包括 SWA 混合模型在 P/D 分离部署下的 decode 前缀复用、运行时挂接或卸下 L3 存储，以及 PP 与 HiCache L3 的一致性修复。
这些改动会影响缓存生命周期。已有服务最好补一组“先命中、再逐出、再恢复”的用例，并覆盖请求取消、跨 rank 恢复和后端重连。单次请求能够成功，并不能覆盖缓存树变化后的状态管理。
来源：统一缓存默认值、L3 动态挂接、PP/HiCache 一致性。
4.3 Cache-DiT 与 CFG 开始按请求配置，避免上一条请求影响下一条
扩散服务过去有不少进程级开关：一旦打开 Cache-DiT、CFG gating 或近似 Attention，同一服务的其他请求也会继承。0.5.19 收录的改动将这些加速选择移入请求参数，并参与动态 batch 的配置匹配。
例如 enable_cache_dit=False 是明确的关闭请求，可以覆盖服务器默认值；不同请求切换时会卸载、重建对应 hook。PR 同时修正了 LTX-2 图像条件请求继承此前文本请求缓存 hook 的问题。
这对 H3 服务很实用：同一个部署可以为需要质量对照的请求关闭近似加速，为另一些请求启用加速，但仍需验证参数切换和 batch 组合。请求级开关提供了控制能力，并不等于近似算法变成了无损算法。
五、LLaDA-Image：Base、Turbo 和 FP8 权重已发布，训练代码仍待开放
inclusionAI 在 9 月 4 日发布 LLaDA-Image Base、Turbo 的权重和推理代码。该模型家族用 6B DiT 做图像生成与指令编辑，理解侧接入基于 LLaDA 的模块，支持中文、英文文本相关生成。
官方模型入口区分 Base 与 Turbo，各有 BF16、FP8 版本。仓库推荐 Base 使用 50 步、Turbo 使用 4 步；论文讨论的 2—4 步区间，不代表所有部署都推荐直接压到两步。
上手时有三个细节值得先看：
- 推理通过仓库的
src.LLaDAImagePipeline，虽然基于 Diffusers，不应假定任意已安装版本的通用 pipeline 都能直接加载。 - 参考环境列出 Python 3.11、PyTorch 2.8、Transformers 4.57.6、Diffusers 0.39.0。复现先固定环境，再做升级对照。
- 9 月 7 日仓库增加社区 ComfyUI 适配入口，提供方是 Rebel AI。官方权重、社区转换和界面适配应分别记录，不能把社区包的所有行为算作官方验证。
开放计划里，推理与权重已勾选，训练代码仍是 coming soon。因此现在适合评估生成、编辑与 Turbo 的质量—速度取舍，还不能称为拿到仓库就能完整复刻训练。
来源：官方仓库、发布日期与开放计划、官方 Base 权重、官方 Turbo 权重、社区 ComfyUI 入口。
六、DSAQuant：Wan 的 W4A4 部署已有明确入口
本周 DSAQuant 论文链接的官方推理实现，当前入口覆盖 Wan2.1 T2V 1.3B、14B，以及 Wan2.2 5B 的 T2V 路径。它提供 packed checkpoint 加载、动态 A4 激活量化、W4 权重、融合 QKV，以及用于对照的 FP16 路径。
这里的“4 bit”需要看具体文件和内核。部署使用 vdm_w4a4_packed_v1 格式的 .pt 文件；对应路径不再先加载完整 base Transformer 再在启动时重新打包量化权重。模型其他组件仍要按说明准备，只有 packed Transformer 文件并不足以构成完整生成管线。
推理后半程可以通过 CFG-drop 设置降低量化伪影，但这与训练阶段的量化感知优化是一套配方，不能理解为给任意 Wan 加上相同 flag 都会获得论文质量。
兼容性上，仓库列出 CUDA JIT 的 sm86、sm89 目标和 CUDA 12.6 测试环境；不要据此宣称 Blackwell 已完成同等验证。论文覆盖 W3A3 的质量实验，仓库面向实用部署的主要路径则是 W4A4。
代码仓库不包含训练基础设施或训练数据；量化 checkpoint 通过另列的 Hugging Face 模型页分发。对于准备复现的读者，先确认拿到的是 packed 推理权重，再检查实际是否启用了 W4A4 kernel，避免只降低权重存储、计算仍走高精度 fallback。
七、Diffusers：Wan2.2 VACE、调度器同步与 offload 修复
Diffusers 本周的几项相关变更已合入主分支。下面给出对应提交；使用稳定包的读者需要另查所装版本是否已经包含。
Wan2.2 VACE 的模块化管线。 9 月 5 日合入的改动增加 Wan22VaceBlocks 和 Wan22VaceModularPipeline，将条件编码、去噪前处理、主循环和解码接进 modular pipeline。代码复用已有 Wan2.2 loop denoiser，减少另外维护一套 VACE 循环的负担。这更利于局部替换与调试，但旧的自定义组件仍需要检查输入输出契约。提交与代码。
FlowMatch scheduler 减少 DtoH 同步。 9 月 8 日的提交为剩余相关 pipeline 设置 scheduler begin index，避免在相应路径中把 GPU 上的信息取回 CPU 才确定步位置。它优化的是执行依赖，不是减少采样步数，不能替代整个 pipeline 的 profiling。提交。
Group offloading 的模块外参数。 Stable unCLIP 的 PriorTransformer 把 clip_mean、clip_std 放在模型自身，生命周期不完全落在子模块 forward 内；9 月 3 日修复针对这类 offloading 后处理访问。它提醒实现者：参数在哪个对象上，与它在哪个阶段使用，同样决定 hook 是否可靠。修复提交。
这些改动不像模型发布那样显眼，却直接影响视频服务的可组合性、CPU/GPU 同步和 offload 正确性。升级后应复测自己真正用到的 pipeline，而不是只确认 import 成功。
八、MLX：Attention 的 shape 门槛，以及低比特矩阵乘的缩放
MLX 这里介绍的两项更新也来自主分支，复现时可直接锁定文末链接中的提交。
8.1 D72/D80 通过 padding 进入 NAX Attention
9 月 8 日的提交将 head dimension 72、80 补零到 96，以使用 NAX Attention，再把输出裁回原尺寸。代码保留调用者传入的 scale，不能因为补到 96 就改成另一套归一化系数。
默认启用条件很具体：Q、K 序列长度都至少 512，FP16 或 BF16，无 causal、mask、sinks，且设备实际具备 NAX。增加的填充与复制有成本，长序列才更可能摊薄这些开销。
因此这不是“所有 Mac 上所有 Attention 都更快”。做模型接入时可以直接对照 shape 和 dtype，确认 dispatch 是否进入该路径；旧硬件即使安装了新源码，也不会因此获得缺失的硬件能力。
来源：完整实现与测试。
8.2 QMM 的 global scale：别混淆 affine INT4 与浮点量化
同日另一个提交把 global scale 接入 Metal 的浮点量化矩阵乘相关路径，涉及 Python/C++ 参数、dispatch、JIT 与 NAX kernel。代码明确区分 affine 模式与浮点量化模式，并非给所有 4-bit 表示附加同一种缩放规则。
这与模型转换直接相关：packed 权重、块级 scale 和全局 scale 是否都被正确传递，会决定结果，而不能只检查权重文件体积变小。该提交中的 CUDA GatherQMM 对相关 global-scale 用法仍明确报错，不能把 Metal 支持外推为所有后端支持。
九、更新前，先按自己真正使用的路径做一轮回归
| 你在部署什么 | 本周可以重点看 | 先核对的条件 |
|---|---|---|
| 专用 H3 文本到音视频服务 | FastH3 VSA | 匹配的学生权重、CUDA、pure Ulysses；不能叠加 DLO |
| 消费卡 H3 | SGLang 0.5.19 收录的配方 | 桌面显存余量、主机 RAM、NVMe 与实测/推导标记 |
| 长上下文 GLM-5.3 | Hybrid HiSparse | 固定源码分支、主机池、indexer KV、MTP 热缓冲 |
| Hopper DeepSeek-V4 | W4A8 MoE | SM90、FlashInfer 0.6.18+、正确量化 ABI |
| Qwen3.8-27B 本地服务 | 重测后的推测解码配方 | checkpoint 导出、LM head、draft、state dtype 与 chunk |
| Wan 低比特生成 | DSAQuant W4A4 | packed 文件、真实内核路径、CUDA 目标与质量对照 |
| Apple GPU 推理 | MLX Attention / QMM 提交 | NAX 可用性、head dim、mask、量化模式与 scale |
SGLang 升级还要留意接口行为变化：Unified Radix Tree 已成为默认；扩散加速参数开始转为请求级；Hunyuan VAE 默认 tiled decode；超出 stop string / regex 数量或长度限制的请求会返回 HTTP 400。若网关会自动拼接大量 stop 条件，建议纳入接口回归，而不是等上线后再排查。升级说明。
以上性能数据均来自项目方。实际复现时，建议保留未加速对照，并记录权重 revision、源码 commit、冷/热启动、分辨率或上下文长度，以及完整请求耗时。尤其是 H3 这类多组件管线，单步 denoise 变快之后，文本编码、VAE 或 MP4 输出仍可能决定最终等待时间。
如果更关心这些优化背后的方法，见同期论文一周：其中展开了 FP4 Attention、MoE 专家裁剪、KV 驱逐、LeanGRPO 和视频量化的实验依据。