本期覆盖 2026/10/14—10/20（UTC）。论文机制见同期《AIGC 论文一周》；这里按代码实际合并或版本发布日期记录，不把旧论文、模型库时间戳和框架新增支持混成一次“模型发布”。

H3 本周的主要进展来自运行时：FP32 AdaLN 表终于走融合路径，A100 有了适合自身加载方式的稀疏 attention，TaoMate-H3 接入实时会话。LTX 则有明确的官方 1.5.0 Release，既改多卡同步，也改 VAE 解码和空间细化路径。两者都说明，模型权重不变，执行链路仍有不少可改的地方。

项目 本期状态 日期（UTC） 阅读重点
Lightricks LTX-2 正式版 1.5.0，e98f6d9 10/18 多卡同步、DFR、DiffVAE 与输出差异
FlashInfer 正式版 0.7.2，d84335d 10/15 MegaMoE、融合 GEMM、低比特 MLA
vLLM 正式版 0.32.0，5df63a7 10/18 KV 精度、执行器与升级兼容性
SGLang 正式版 0.5.22，baa9bef 10/19 模型适配、diffusion、CPU/Apple 平台
vLLM-Omni 候选版 0.32.0rc1，da572cd 10/19 实时视频、音频与 FP8 attention
ComfyUI 正式版 0.42.0 / 0.42.1 10/18、19 MOSS-Image 原生支持与修复
Transformers 正式版 5.20.0—5.20.2 10/15—19 新模型与 expert-parallel 正确性修复

以下 PR 均已在本期合并；是否包含于某个 wheel，应以该版本的 changelog 和 tag 为准。性能结果只代表列出的模型、设备、精度与输入，不把单 kernel 的提升扩写成全模型提升。

LTX 与 H3：先分清组件和执行路径

1 LTX 1.5.0：多卡文本编码不再与等待线程争 GPU

10 月 18 日，官方 Release。 LTX 的 Accelerate-sharded Gemma 在多卡上编码 prompt 时，其他 ranks 过去可能已经进入 NCCL receive，占着 Gemma 仍需使用的 GPU。1.5.0 改为在 host 等 source rank 完成所有 GPU 上的文本编码，再进入广播；每个 rank 默认把 CPU intra-op 线程限制为八个，减少多核主机上的小算子开销。

另一组变化落在去噪和解码：sampler 去掉逐步 CPU 同步，视频 VAE 解码与 MP4 编码流式衔接，warm registry 降低后续请求的准备成本。DFR 在 --spatial-upscalings 2 路径调整空间 tile，符合条件的 GPU（compute capability 8.9+）对长视频投影采用 FP8 GEMM。官方明确说明输出不再与旧版 bit-identical，主要差异来自新 tile 与 FP8 路径；多卡 audio cross-attention 也不再读取 video padding tokens。

精度与开关需要分别看：--quantization fp8-cast 针对 transformer linear 权重存储，fp8-scaled-mm 才选择 FP8 scaled matmul；这不等于 Gemma 和 VAE 全部 FP8。官方 split 模型列表仍分别标注 BF16 transformer、BF16 video VAE，Gemma 采用模型配套版本，不能随意换成通用 Gemma checkpoint。--compile 默认关闭；DiffVAE 的 blackwell_dsl 面向数据中心 Blackwell，不包含 SM120 消费卡。普通 decode 的 NATTEN/Triton/eager 后端与带 keyframe 的后端选择也不同。

本版还修复了长视频 RMSNorm 索引溢出导致的灰尾帧，以及 Blackwell fused stage-5 attention 的 barrier 死锁。升级不只关乎速度，也涉及长片与重复请求的正确性。模型仓库文件历史本次读取受限，因此这里确认的是官方代码 1.5.0，不据此宣称 LTX-2.5 发布了新权重。Release · 该版本优化文档

2 LTX-2.5 在 vLLM-Omni 中新增纯音频入口

10 月 17 日，PR #6489 合并，a091098。 新注册的 LTX2TextToAudioPipeline 接通 checkpoint 加载、音频 conditioning/connector、离线推理与 /v1/audio/generate，输出 48 kHz 立体声。它不是先生成完整视频再丢掉画面，而是单独的 audio-only pipeline。

贡献者测试使用 RTX PRO 6000 Blackwell Server Edition 96 GB、BF16 权重和 cuDNN attention，覆盖多种时长的 30 步 eager 请求。与固定官方实现比对时，tokenization、Gemma hidden states、connector 和去噪检查点在相同设置下逐位一致；最终波形因 decoder 实现不同仍有小误差，不能写成音频逐位一致。

当前 recipe 的边界很明确：单请求、TP/SP 为一，不支持 Cache-DiT。对应的 VAE/音频 decoder 仍属于原生解码链路，并非低比特音频模型发布。PR 内有早于本周的测试日期，本期收录依据是代码在本周合并，测试证据保留原日期。PR 与测试条件

3 H3 的 FP32 AdaLN 融合：INT8 checkpoint 也可能卡在高精度小算子

10 月 18 日，SGLang PR #44180，1fd46dd。 部分序列化 INT8 H3 checkpoint 的 AdaLN shift/scale/gate 表保留 FP32，原融合 kernel 只接受 BF16，于是每次 gate 都退回 index_select、乘、加、cast 多段 eager 操作。DiT 权重已经量化，并不意味着这些辅助路径也优化好了。

新增 kernel 按表 dtype 分发，检查列连续性，并保留 eager 的舍入顺序：乘法先舍入，避免与后续加法缩成 FMA，最后才存成 BF16。VAE、文本编码器和 attention backend 没有因此换精度；完整 BF16 H3 checkpoint 也不会命中这条 FP32 表路径。

贡献者用 H3 pruned INT8、SGLD ComfyUI、四步、三个 seeds、comfy_kitchen 后端测试，480p 下报告了约 4.5%—5.5% 的稳态模型执行性能改善，覆盖 RTX 4090、RTX 5090 和 H200；更高分辨率收益更小。原表称为“model-time gain”，未列出该组测试的帧数或时长，也不是含加载与编码的完整请求计时，不适合直接与别处的端到端倍率比较。对应配置的整模型输出逐位一致是贡献者测试结论，本站未复现。PR

4 VSA-H3 支持 A100：换加载方式，也保留稀疏化的质量账本

10 月 17 日，SGLang PR #43823，465ddf9。 原 Triton VSA-H3 使用 TensorDescriptor；A100 没有 Hopper 的 TMA，降级加载难以形成有效预取。新路径通过 raw pointers 加载 Q/K/V/O，使 SM80 的流水线可以使用 cp.async；SM90 及以上保留原 descriptor 路径，SM100 专用 kernel 改为按需导入。

贡献者在 A100 80 GB、FastH3 四步、1344×768、五秒生成中，报告稀疏路径约 59.6 秒，dense fa 约 85.0 秒。必须区分两个比较：pointer 与原 sparse kernel 可逐位一致；90% 稀疏路径与 dense attention 不一致，报告中相对 dense 的 PSNR 为 14.6 dB、音频相关系数约 0.60。

因此 dense fa 仍是默认，video_sparse_attn_h3 是需要主动选择并验证质量的方案。独立 kernel 对照采用 BF16；上述整模型计时没有逐项列出 DiT、VAE 和文本编码器精度，不能据此推定为全管线 BF16，更不提供这些组件的低比特收益。没有 A100 上游 CI runner，硬件结果来自贡献者独立测试。PR

5 SM120 FP8 attention：相同数值，换成 block-scaled MMA 编码

10 月 19 日，SGLang PR #43390，10ec53a。 fp8_fa_sm120 原来用普通 E4M3×E4M3、FP32 累加指令。新实现在支持的 SM120/SM121 编译目标上改用 block-scaled MMA，但把 scale 固定为一，Q/K/P/V 的数据、softmax 和准备流程不变。

这不是又做了一次不同尺度的动态量化，而是利用另一种指令编码执行同一个乘积。scale 保存在寄存器，不新增全局读写；公开 API 不变，也没有需要用户调节的质量档位。

RTX 5080 上，H=56、D=128，五次运行取中位数，序列长度 20,440 和 30,272 时，包含 prep 的完整 attention 调用约加速 1.47 倍。这里的“完整调用”仍只是一层 attention backend，不是完整视频生成。贡献者的旧、新 FP8 路径逐位一致测试，也不等于 FP8 与 BF16 attention 完全相同。PR

少做重复工作：host、VAE 与条件复用

6 Triton launch replay：缓存的是启动准备，不是模型输出

10 月 14 日，SGLang PR #43859，1617627。 小 Triton kernel 有时 GPU 执行只需几微秒，Python wrapper 的形状检查、stride 计算、device guard 与 JIT dispatch 却更久。新 decorator 首次按输入签名记录 kernel、grid 和参数，后续同签名直接调用编译后的 launcher。

签名包含 shape、stride、dtype、device、地址对齐与非 tensor 参数；读 tensor 值、使用无法映射的临时张量等情况不进入 replay。torch.compile 下走原 wrapper 保持可追踪，旧 Triton 也回退；设置 SGLANG_DIFFUSION_TRITON_FAST_LAUNCH=0 可关闭。它不跨去噪步复用数值，所以和 TeaCache 的近似误差问题不同。

收益取决于 host 是否成为瓶颈。贡献者在 GB300 的 Z-Image-Turbo、FLUX、Qwen-Image 等 eager 配置观察到改善，但 H200 上 GPU-bound 的 Z-Image 基本不变。不要把 wrapper host time 减半宣传为生成速度翻倍；当前也没有覆盖所有 JIT CUDA wrapper。PR

7 Qwen-Image 2.1 VAE：默认融合与高速度档位分别验证

10 月 14 日，SGLang PR #41340，5e90312。 本次优化瞄准 VAE decoder 的布局转换、channel RMSNorm、SiLU 与 conv bias。默认路径保留原有舍入顺序；extra-high 档进一步采用 channels-last、NHWC norm 和上采样折叠，会产生数值差异。

贡献者在一张 73 GB、350 W 限功耗的 SM120 GPU 上，以 BF16、1024²、40 步、torch_sdpa、预热后三个请求均值测量：VAE decode 从 186.0 ms 降到默认档的 159.8 ms，extra-high 为 100.4 ms。后者相对默认输出的 PSNR 约 59.4 dB；这些是 VAE 阶段数据，不能把 46% 的 decode 降幅当成整图请求降幅。

PR 中 HTTP 计时还包含另一项 attention 改动，因此不用于归因当前 VAE patch。DiT 与文本编码器没有被统一量化；选择高速度档前仍需检查透明通道、细节与所用 GPU 的数值行为。PR

8 Qwen-Image 2.1 Turbo：四卡 B300 的精确复用与融合

10 月 14 日，vLLM-Omni PR #8739，910b8f0。 优化包括有限容量的条件复用、请求拥有的几何状态、共享 modulation 准备、BF16 舍入一致的残差/SiLU 与 QK norm/RoPE 融合。请求完成、失败或中断都会释放相应状态，避免跨请求误用；对称内存交换是显式 opt-in，默认仍用原 all-to-all。

性能证据绑定于 PR 的测试 revision d57480f5，而不是最终 merge SHA。测试模型是 Qwen-Image-2.1-Turbo，四张 B300，BF16、1280×704、原生八步、CFG 1、Ulysses4、eager、FlashAttention、untiled VAE，无量化、offload 或近似缓存。每种配置五轮独立启动，每轮六次预热、三次计时，取五轮均值的中位数。重复 prompt、完整 JSON/base64 PNG 下载的暖请求，从 381.9 ms 到默认配置的 279.8 ms；两侧都开启 symmem 时，从 374.6 ms 到 264.2 ms。

跨配置的 30.82% 降幅包含通信设置变化；同配置代码收益分别为 26.73% 与 29.48%。后续 revision 补了正确性与生命周期验证，未重新声称一轮正式延迟测试。新 RoPE 路径限定已验证的 SM103/CUDA PyTorch 2.13，其他架构保留参考实现，不能把 B300 结果外推到 H200。PR 与版本化证据

9 TaoMate-H3：实时视频接入统一的 KV 与 LoRA 生命周期

10 月 19 日，vLLM-Omni PR #8268，21ef5b4。 TaoMate-H3 是基于 H3 的派生实时生成方案，不是 MiniMax 官方新基础权重。本次接入 /v1/realtime/video，提供 USP2 的 FP8 DiT linear/CUDA Graph 配置与 USP4 的 BF16 配置，允许运行中更新 prompt。

AR-Diffusion 负责 clean KV 和请求调度，TaoMate 自己定义 sink/recent history、音频 reset 与增量 VAE 状态。LoRA 由统一 manager 管理，teacher/student 切换不原地覆盖已捕获的 teacher 权重；关闭时先使 graph 失效，再释放权重 bank 和 wrapper。等待交互时不再靠无意义的 denoise step 维持会话。

默认精确 AdaLN 投影缓存与可选 decode overlap 是两件事；DiT FP8 也不意味着 VAE、文本编码器和 LoRA 全部 FP8。该 PR 的主要验证是成对 checkpoint 运行、prompt 切换、取消与重启的一致性，以及不回退的延迟门槛，不应包装成新的大幅加速。当前 max_num_seqs=1，MP4 传输是 video-only，同步音视频传输不在本次范围内。PR

10 Omni 的 FA3 FP8：名叫 KV cache dtype，实际量化 attention 计算

10 月 18 日，PR #8965，d790c53。 --diffusion-kv-cache-dtype fp8 的名字容易误导：这条路径动态量化本次 attention 的 Q/K/V，调用 FA3 后返回原输入精度；持久 KV 的存储 dtype 没有随之改变，也不同于上游 vLLM 的 --kv-cache-dtype。

CUDA 路径要求 SM90 上的 FA3，head dimension 可被 16 整除且不超过 256；可通过 step/layer exclusion 保留敏感位置，未设置或 auto 时保持原生 dtype。量化前的 Q/K 变换、归约、FP8 转换和额外 launch 都要算入代价。

贡献者用 L20X（SM90）、Wan2.2-TI2V-5B、BF16 权重、1280×736、81 帧、60 步、batch 1、eager 测试；四个计时请求中，生成阶段均值从 70.774 秒到 64.433 秒，排除加载和视频编码。self-attention 全部启用 FP8，cross-attention 保持 BF16，未保护特殊层或步。样本范围很小，且缺少广泛质量评估，不构成对所有视频任务默认启用的建议。PR

MoE、GEMM 与服务框架

11 FlashInfer 0.7.2：专家计算和通信后端进一步解耦

10 月 15 日，正式版本。 本版将 cuDNN Frost 的 grouped-GEMM 专家后端接入 MoELayer，覆盖 BF16、MXFP8、NVFP4 及 MXFP8 activation/MXFP4 weight 等配置；SM107 路径对 PyTorch 与 CUDA assembler 有明确版本要求，不能只更新 Python 包而忽略底层工具链。

更贴近现有设备的是 H100 的 BF16 expert-parallel MoE，以及 SM120 的 W4A8 MegaMoE。前者把 dispatch、SwiGLU 与 pre-reduced BF16 combine 接起来，后者支持 CUDA Graph replay 与 ranks 间不等 token 数。SplitConfig(comm=..., kernel=...) 允许通信实现与专家 kernel 分别选择，减少一套 kernel 绑定一种传输栈的限制。

dense GEMM 也增加 FP8/NVFP4 的 SwiGLU、QKV+QK-norm+RoPE epilogue 融合，部分 NVFP4 tactic 可选择 TMEM overlap。这些是特定精度、shape、GPU 与依赖组合的能力；Release 没给出可直接套给任意 MoE 的统一端到端倍率。本周较晚的 0.7.2rc5 标签是预发布，不能仅凭时间更晚就替代正式版身份。正式版说明

12 FlashInfer 的低比特 MLA：缓存布局与自动选路要分别检查

同属 0.7.2。 DeepSeek-V4 的 NVFP4 sparse-MLA decode 扩展到 B200/B300；SM120 提供相应 decode/prefill 路径，另有 DeepSeek-V4.1 的混合 FP8/FP4 cache 支持。这些通过明确的 backend="cake" 等配置选择，并非所有 auto 路径都会自动切换。

另一项自动选路针对推测解码验证：在 B200/B300、FP16/BF16、head dimension 128 的 GQA 配置中，分页 decode 每请求有二至四个 query token 时，auto 可选择 cuDNN。单 token decode 和启用显式确定性控制的运行仍留在 FA2；FLASHINFER_DECODE_AUTO_CUDNN=0 可禁用自动切换。

这是把真实 workload 区分到 verify 与普通 decode 的实现选择，不是笼统的“attention 全面提速”。升级还需匹配 nvidia-cudnn-frontend[cutedsl]，并刷新预编译 kernel/cache 包。KV 精度、模型布局和 backend 必须一起核对。版本说明与入口

13 vLLM 0.32.0：低精度 KV 覆盖扩大，也有默认行为变化

10 月 18 日，正式版本。 本版扩展 NVFP4 KV cache 到更多架构，并增加 ROCm 的四位 cache 路径；GLM-5.x 在 SM100 上的默认 FP8 KV 是需要特别注意的行为变化。显存更省并不自动意味着 TTFT 更短，Release 自己保留了吞吐与首 token 延迟之间的取舍。

Model Runner V2 增加 GPU n-gram draft、Elastic EP 与部分 PP/PCP 组合；启动侧提供 download-kernels 与预热 autotune 表，减少首次运行准备成本。GLM、DeepSeek-V4/V4.1、Qwen3.8、Kimi-K3 和 MiniMax-M3 的更新分布在索引复用、投机解码、缓存布局及多模态预处理，不能合并成一个跨模型性能结论。MiniMax-M3 也不应与本期视频模型 H3 混称。

升级前应核对 Python 3.10 移除、CORS 默认限制以及依赖范围。尤其本版要求 transformers>=5.16.1,<5.20.0，与本周 Transformers 5.20.x 并非随意混装关系；部分旧编译/缓存选项也被移除。服务端还包含多项资源耗尽与输入处理修复。Release

14 SGLang 0.5.22：热门模型适配之外，留意平台与状态正确性

10 月 19 日，正式版本。 新增/扩展模型支持包括 Clef、PPLX-Decider、EmbeddingGemma 2、LLaDA2.2，以及 HunyuanImage-3.0-Instruct、Kandinsky 6、Wan-Animate-2、SANA-Video 2.0、LLaDA-Image 等生成路径。这里确认的是框架适配，不能据此判断这些模型都在本周首次开放权重。

H3 与 Qwen-Image 2.1 的 ComfyUI 集成、社区 GGUF/LoRA 加载，是把 diffusion runtime 接入工作流的进展；具体 dtype、VAE 和 attention 仍取决于加载 recipe。服务侧的 HiSparse 与 speculative decoding、decode context parallelism 与 MTP，需要成套配置，不能默认任意组合可用。

平台新增标准 PyTorch 的 Apple Silicon 路径，与 MLX 是不同实现；CUDA kernel 的数字不适用于 Mac。正确性方面，本版修复了 speculative decoding 与 structured output 同时使用时混合线性模型恢复错误 Mamba state 的问题。Python 最低版本升到 3.11。本文前面几项细粒度 PR 给出的条件，比一个版本总加速数字更适合判断是否升级。Release

图像与多模态生态

15 ComfyUI 0.42：MOSS-Image 原生加载，别把 5B 当成整条管线大小

10 月 18 日发布 0.42.0，19 日发布 0.42.1。 MOSS-Image 的原生支持来自 PR #17095。它的 5B 指的是 single-stream DiT，使用 FLUX.2 latent 空间与 Qwen3.5-9B 文本编码器；显存预算还要加上文本编码器、VAE 和中间激活。

加载器识别 checkpoint 中可选的 fused QKV，LoRA 的独立 Q/K/V 键会映射到融合权重切片，计算接入现有 RMS/RoPE/AdaLN kernel。官方 Python 示例采用默认 BF16、VAE FP32，而不是全管线一种 dtype；ComfyUI 的转换文件与作者原始权重也应区分。0.42.1 进一步修复部分用户执行 MOSS image template 时的崩溃。

本期确认的是官方项目及 ComfyUI 已落地的支持。社区八步蒸馏、FP16 修正版和 Spectrum 缓存各有独立维护者，本文不把它们当作作者默认配置，也不合并它们的质量或性能承诺。该版本还明确处理 CPU 不支持 FP8/NVFP4/MXFP8/INT8 路径的情况，避免加载格式与实际执行设备不匹配。ComfyUI 0.42.0 · 0.42.1 · MOSS-Image 官方项目

16 Transformers 5.20：新模型可加载，分布式训练修复同样重要

10 月 15—19 日。 5.20.0 增加 Muse Spark Open、Ling 3.0 Flash、Kolibri 1、MiniCPM-V 4.7、Unlimited OCR、UltraBERT 与 MOSS-Transcribe-Diarize 等支持；5.20.1 又加入 Beam。值得分别看架构差异：Ling 的 KDA/MLA 混合层、MiniCPM-V 的 canvas M-RoPE，以及 OCR 的固定容量解码缓存，都要求相应实现，不能仅靠替换模型名运行旧路径。

两个 patch 版还有直接影响结果的修复：5.20.1 处理 DeepGEMM MegaMoE 在 expert parallelism 下的问题及旧 PyTorch 加载兼容；5.20.2 修复 BF16、ep_size < fsdp_size 组合下专家梯度为零，以及 generate 内输入字典类型转换影响多模态模型的问题。

这类更新首先属于正确性与兼容性，不宜写成“新增某模型支持就自动提速”。部署应使用消费框架认可的依赖组合；上文 vLLM 0.32.0 的版本上界尤其需要保留。5.20.0 · 5.20.1 · 5.20.2

升级时最值得保留的几条记录

先记录各组件精度与 backend，再测固定 prompt、seed 和生成长度下的分阶段时间。H3 的 FP32 表融合、Qwen 的 VAE 融合属于不同热点；LTX 的新 tile、稀疏 attention 和 FP8 attention 则可能改变输出。把 model time、VAE decode、完整 HTTP 请求分别记账，才能知道优化是否覆盖自己的瓶颈。

本期未发现 MiniMax 官方 H3 模型库在窗口内的新权重提交；本文报道的 H3 进展来自框架合并与派生模型适配。vLLM-Omni 0.32.0rc1 仍是候选版，其 Release 不承诺全平台 nightly 全绿，也不意味着所有模型第一天都有完整验证。候选版状态