AIGC 开源一周：MiniMax-H3 的多后端适配，和热门模型的基础设施更新

统计窗口：2026/8/24—2026/9/2（UTC）
本期主线：MiniMax-H3、DeepSeek-V4、Kimi K3、Qwen3/3.8、Qwen4-Exp、GLM-5.3-Flash、Step-3.7-Flash、LTX、Wan、Gemma4

本周的更新分散在多个项目里，但指向的是同一件事：热门模型的适配已经从“能不能加载”延伸到 attention kernel、MoE、KV cache、量化、图编译、视频工作流和消费级 offload。MiniMax-H3 尤其明显，除了模型仓库本身，SGLang、vLLM-Omni、Diffusers、ComfyUI、AMD ROCm、B200/B300 FP8 和 RTX 级 INT8/offload 都出现了对应路径。

1. 版本速览：稳定版和预览版分开看

项目	本窗口版本/时间	主要看点	稳定性判断
FlashInfer	v0.6.18，8/29	Rubin SM107；Hopper EP MoE；DeepSeek-V4/Kimi K3 decode；Blackwell 低精度 MoE	稳定版，可作为本期重点升级对象
Transformers	v5.16.0/v5.16.1，8/26	Qwen4-Exp、Step-3.7-Flash、GLM-5.3-Flash、KV/cache/量化支持	稳定版，仍需按模型做回归
TensorRT-LLM	v1.3.0rc25，8/31	KV Cache Manager V2 默认覆盖多种热门模型	RC，适合验证，不建议无条件生产切换
FlashAttention 4	beta29，9/2	加速 SM100 scalar mask compilation	Beta，偏开发和基准验证
vLLM	v0.28.1rc0，8/27；v0.29.0rc1，9/2	sweep/recipe 改进；CUTLASS MoE padded routes 修复	RC，重点关注 MoE 和工具链兼容性
ComfyUI	v0.34.0—v0.34.3，8/26—9/2	MiniMax-H3、Seedance 2.5、Minimax Music、Gemma4	快速迭代，工作流用户先做节点回归
DeepSpeed	v0.19.6，8/27	DeepCompile、ZeRO-3、Ulysses、AutoTP、NVMe/offload 修复	Patch，训练/推理基础设施可关注
CUTLASS	v4.7.1，8/26	CuTe DSL、compile cache、TVM-FFI、FlashInfer/FA 兼容性	稳定版，适合 kernel 开发环境
MLX	v0.32.2，8/25	GQA decode 读带宽、NAX head_dim 256、fused SDPA	稳定版，Apple Silicon/边缘推理相关

补充边界：vLLM v0.28.0 和 ComfyUI v0.33.4 在 8/24 附近发布，前期周报已经覆盖，本期只承接后续 RC 与 v0.34 系列。SGLang v0.5.18 实际发布于 8/22，所以不计入本窗口版本统计；但它的 MiniMax-H3 cookbook 仍是本期重要的模型适配资料。

2. MiniMax-H3：从模型仓库到多后端执行

2.1 官方结构：视频和音频一起生成

MiniMax-H3 的官方仓库将它定位为多模态视频生成系统：输入可以包含文本、图像、视频和音频，输出为视频与立体声音频；默认视频为 768p、24 FPS，音频为 32kHz stereo。仓库提供 FL2VA、Ref2VA 等任务路径，并配套 H3-Context-IR、H3-Base 和 Regenerate-2K 等组件。

它的工程特点包括：

将多模态输入打包到同一 sequence，由 H3-Omni-Transformer 联合预测视频和音频 latent。
H3-Encoder 使用 Qwen3-VL-32B 的第 50 层 hidden states 作为条件表征。
VisualVAE 使用 f16t4d24，空间压缩 16×、时间压缩 4×；经过 1×2×2 patchify 后，有效空间压缩达到 32×。
音频从 32kHz 映射到约 40Hz token rate，避免让音频采样率直接成为 Transformer 序列长度。
架构原生支持 sparse-attention training/inference，但目前公开的初始实现主要是 full attention；不要把“架构支持”误写成“当前开源 checkpoint 已默认启用稀疏注意力”。

官方仓库：https://github.com/MiniMax-AI/MiniMax-H3

2.2 SGLang：质量档位、Cache-DiT、FP8 和 24GB 显卡

SGLang 的 H3 cookbook 把质量档位和加速路径分开写清楚：

lossless：默认精确路径，作为质量基线。
extra-high：更激进但仍需按工作负载验证。
high：针对审计过的 H200 workload 的加速路径，不保证与 lossless bit-identical。

在 4×H200、1344×768、124 frames、24 FPS、50 steps、3 prompts 的 T2VA 设置中，cookbook 给出的 lossless 为 75.10 秒，high 为 53.70 秒，约 1.40×；同时报告 SSIM 0.931、PSNR 28.16 dB。这只是该组工作负载的项目方结果，不能直接外推到其他分辨率、帧数或 GPU。

文档列出了几条具体路径：

Cache-DiT：跳过选定 block 的重复计算；这是近似算法，必须和视频、音频一起做质量回归。
Layerwise offload：与显存受限场景兼容，但会增加 CPU/GPU 交换成本。
FP8：B200/B300 上对部分 DiT 计算启用在线 FP8，视频/音频 projection、timestep MLP 和 final heads 保持 FP32；文档明确提示这是 approximate path。
kitchen_int8：24GB 卡使用 data-free online INT8，针对 DiT block 内四类 GEMM，并配合 layerwise offload；不能把外部预量化 INT8 checkpoint 当成同一路径直接加载。
并行：Ulysses 已在 H100/H200/B200 以及部分 AMD MI300X/MI355X 组合上验证；Ring 路径覆盖多节点 H200；消费级路径可以走单卡 CPU/layerwise offload，但吞吐和质量要单独测。

SGLang H3 cookbook：https://github.com/sgl-project/sglang/blob/main/docs/cookbook/diffusion/MiniMax/MiniMax-H3.mdx

2.3 vLLM-Omni：AMD ROCm 和服务化接口

vLLM-Omni 的 MiniMax-H3 recipe 提供了另一条实现路径：

AMD ROCm gfx942/gfx950 支持。
FLASH_ATTN attention backend。
单 GPU CPU offload，以及 4 GPU Ulysses/USP。
VAE tile mode，降低高分辨率视频解码时的显存峰值。
HTTP API 形式的 FL2VA/T2VA 调用。

项目方在 4×MI300X、1344×768、209 frames、50 steps 上给出 client E2E：T2VA 267.42 秒，FL2VA 287.07 秒；在单 gfx950、832×480、约 4 秒、40 steps 的设置下约 55 秒。前者更接近多卡服务基准，后者主要用于说明路径可用，不能当成生产性能指标。

vLLM-Omni recipe：https://github.com/vllm-project/vllm-omni/blob/main/recipes/MiniMaxAI/MiniMax-H3.md

2.4 ComfyUI：把 H3 的控制条件放进工作流

ComfyUI v0.34.0—v0.34.3 的更新把 H3 的控制条件带到了节点工作流：

MiniMaxH3AddGuide 可以把 image/audio guide 锚定到任意 frame。
支持普通 Empty Latent 的 H3 工作流。
暴露 per-token video/audio latent noise masks。
支持 prompt embeddings。
修复非 dynamic VRAM 下的 Minimax Music 问题，并补充 Seedance 2.5 task type。
Gemma4 text generation 有速度优化。

对使用者来说，H3 的优化不只是更换 attention backend，还涉及 guide 条件的时间对齐、音视频 latent 的噪声控制和显存模式选择。对平台开发者来说，节点参数最好明确哪些是质量基线、哪些是近似加速，避免把工作流之间的画质差异都归因于模型随机性。

ComfyUI v0.34.0：https://github.com/comfyanonymous/ComfyUI/releases/tag/v0.34.0

3. DeepSeek、Kimi、Qwen、GLM：模型差异落到 kernel 和 cache

3.1 FlashInfer v0.6.18：一次覆盖多条模型专用路径的更新

FlashInfer v0.6.18 是本窗口内容最集中的稳定版本之一，官方 release highlights 包含：

完整的 NVIDIA Rubin SM107 支持。
Hopper 上的 whole-layer expert parallel MoE，面向 DeepSeek 类 384-expert 几何，项目方报告约 562 TFLOPS/rank，并通过 CUDA Graph push backend 减少约 1 GiB/rank activation buffer。
DeepSeek-V4 sparse attention 的 HCA decode path 和 top-k varlen 支持。
Kimi K3 的 fused KDA decode，把 width-four depthwise causal convolution、SiLU、recurrent Kimi Delta Attention 和 gated RMSNorm 合进一次 SM100 launch。
Blackwell RTX PRO/DGX Spark 上的 MXFP4 MoE，以及 B200/B300 上的 W4A16 低精度 MoE。
Gemma 4 asymmetric VO-split NVFP4 paged prefill。

这次更新说明，框架已经不再只围绕“标准 MHA + dense GEMM”做优化，而是开始为不同模型的 attention、state 和 router 形态提供专用路径。对 DeepSeek-V4、Kimi K3、Gemma4 和 Qwen 系列来说，硬件利用率会越来越依赖后端是否真正理解模型结构。

FlashInfer v0.6.18：https://github.com/flashinfer-ai/flashinfer/releases/tag/v0.6.18

3.2 TensorRT-LLM RC25：KV Cache Manager V2 覆盖热门模型，但仍是 RC

TensorRT-LLM v1.3.0rc25 将 KV Cache Manager V2 默认扩展到一批热门模型，包括：

DeepSeek V3/R1/V3 Lite/V3.2/V4。
GLM-5。
GPT-OSS、Mistral Large 3。
Kimi K2/K2.5/K3。
MiniMax M2/M3。
Nemotron H/Puzzle。
Qwen3-Next、Qwen3.5、Qwen3.8。
Gemma3/4。

这份列表说明 KV Cache 已经成为多个热门模型共享的基础设施。不过该版本仍是 RC，release note 同时列出 disaggregated serving hang、Gemma4 generation hang、B200 OOM/crash、DeepSeek R1 FP4 MTP 等已知问题。升级前应在目标模型、GPU、TP/PP/EP 配置和真实上下文分布上做回归，再决定是否切换生产默认。

TensorRT-LLM v1.3.0rc25：https://github.com/NVIDIA/TensorRT-LLM/releases/tag/v1.3.0rc25

3.3 Transformers v5.16：Qwen4-Exp、Step-3.7-Flash 和 GLM 进入统一模型接口

Transformers v5.16.0/v5.16.1 的模型层变化较多：

Qwen4-Exp：GatedResidual + Qwen Sparse Attention + Per-Layer Embedding；QSA 对压缩 key block 打分并选取连续 token block，配合 GDN 做长上下文。
Step-3.7-Flash：198B sparse MoE VLM，top-8/288 routed experts，MTP 支持 speculative decoding，动态 image tiling。
GLM-5.3-Flash：release note 标注 320B 总参数、18B active，采用 sparse + linear attention 和 mHC。
Qwen3-VL：加入 per-frame cap，避免长视频输入把视觉 token 无限制推高。
Qwen3-Omni/Qwen2.5-Omni-MoE：cache 可编译性和 sliding cache 继续修复。
compressed-tensors：支持只加载 KV-cache 相关量化信息。
NVFP4 通过 HF kernels 接入，项目方描述为约 50% memory reduction；仍需按 kernel、GPU 和 batch 验证实际 latency。

Transformers v5.16.0：https://github.com/huggingface/transformers/releases/tag/v5.16.0
Transformers v5.16.1：https://github.com/huggingface/transformers/releases/tag/v5.16.1

4. vLLM、FlashAttention、CUTLASS：把底层路径做稳

4.1 vLLM RC：从 recipe 到 CUTLASS MoE permutation

vLLM v0.28.1rc0 的改动偏向 tools/recipes，包括 sweep recommendations 和 short-alias parsing；v0.29.0rc1 则修复 CUTLASS MoE permutations 中的 padded routes。这个修复看似局部，但对 sparse MoE 很关键：padding、route token 数和 permutation layout 一旦不一致，错误结果、无效 token 计算等问题可能只在特定 batch 下出现。

使用 vLLM 时，不能只看主版本号，还要把具体模型的 recipe、attention backend、MoE backend 和 quantization backend 一起固定。DeepSeek、Kimi、Qwen MoE 升级后，至少要覆盖 padded route、empty expert、不同 batch、CUDA Graph 和 TP/EP 组合。

vLLM v0.28.1rc0：https://github.com/vllm-project/vllm/releases/tag/v0.28.1rc0
vLLM v0.29.0rc1：https://github.com/vllm-project/vllm/releases/tag/v0.29.0rc1

4.2 FlashAttention 4 beta29：SM100 mask compilation 优化

FlashAttention 4 beta29 于 9/2 发布，重点是加速 SM100 scalar mask compilation。它没有新增模型支持，但会直接影响 Blackwell 上 attention kernel 的编译迭代速度。

MiniMax-H3、Kimi K3、DeepSeek-V4 等模型需要自定义 mask、稀疏模式或长上下文 layout 时，编译时间会影响 benchmark 调参效率。compile latency 降下来后，更多 shape、mask 和 head 配置可以进入自动回归。

FlashAttention 4 beta29：https://github.com/Dao-AILab/flash-attention/releases/tag/fa4-v4.0.0.beta29

4.3 CUTLASS 4.7.1：CuTe DSL 的工程修复

CUTLASS 4.7.1 修复了多类 CuTe DSL 和集成问题：

warp-specialized + setmaxnreg 的编译失败。
jit/kernel decorator 泄漏。
cutlass.jax tensor aliasing 和 optional tensors。
compile cache miss。
protobuf 依赖从 6.30 收紧到 4.21。
import time 写入 CUTE_DSL_LIBS。
dynamic shape header 中 i64 input 对应的 i32 output。
TVM-FFI stream detection 和 byte-offset bug。

官方 release 还列出对 FlashAttention main、Quack main、FlashInfer main、cuDNN frontend dev 和 PyTorch main 的测试。这些修复并不针对某一个模型，价值在于让 FlashInfer、FA4、MoE 和自定义 kernel 更容易共享同一套 DSL 和编译基础。

CUTLASS 4.7.1：https://github.com/NVIDIA/cutlass/releases/tag/v4.7.1

5. DeepSpeed 与 MLX：训练基础设施和本地推理

5.1 DeepSpeed v0.19.6

DeepSpeed v0.19.6 虽然是 patch release，改动主要集中在容易影响稳定性的边界：

Ulysses checkpoint rank selection。
elastic batch size bound。
DeepCompile ZeRO-3 frozen parameters。
AutoTP compiler pass。
configurable sum gradient reduction。
native DeepNVMe host pinning 和 activation offload pin memory。
Triton grouped GEMM expert offset 的 int32 overflow。
backend timeout 从 30 分钟调整到 10 分钟。

对 DeepSeek、Qwen、GLM 这类 MoE 或长上下文模型来说，checkpoint、offload、expert GEMM 和 TP 的边界条件往往比单次 benchmark 更容易暴露问题。升级时可以优先回归 frozen parameter、NVMe offload 和大 expert offset。

DeepSpeed v0.19.6：https://github.com/microsoft/DeepSpeed/releases/tag/v0.19.6

5.2 MLX v0.32.2：Apple Silicon 上继续压低 GQA decode 的带宽浪费

MLX v0.32.2 的变化主要与边缘和本地推理有关：

GQA-8 decode attention 中每个 K/V byte 只读一次，减少重复带宽。
NAX 上支持 head_dim 256 的 fused full-attention path。
增加 fused SDPA 的 force_fused 选项。
修复 subnormal float 转 bool 的保留问题和 GGUF metadata bound。

对 Qwen、Llama、Mistral 等本地模型来说，影响更可能出现在小 batch、长上下文和内存带宽受限的场景。实际测试应比较 decode token/s、功耗、上下文长度，并确认是否真正触发 fused path。

MLX v0.32.2：https://github.com/ml-explore/mlx/releases/tag/v0.32.2

6. 本周热门模型适配矩阵

模型	官方/主流开源入口	本周可关注的优化	需要警惕的边界
MiniMax-H3	MiniMax-H3、SGLang、vLLM-Omni、ComfyUI	full/sparse attention、Cache-DiT、FP8、INT8、Ulysses、offload、VAE tile	high/FP8/Cache-DiT 是近似路径，质量和音频要一起测
DeepSeek-V4/V3	FlashInfer、TensorRT-LLM、vLLM	sparse attention、EP MoE、paged prefill、KV V2	padded routes、FP4/MTP、CUDA Graph 组合回归
Kimi K3/K2	FlashInfer、TensorRT-LLM	fused KDA decode、低精度 MoE、KV manager	recurrent state 不等于传统 KV，需验证 state 生命周期
Qwen3/3.8/4-Exp	Transformers、TensorRT-LLM、MLX	GDN/QSA、NVFP4、per-frame cap、hybrid cache	hybrid attention 需要 backend 真正识别结构
GLM-5/5.3-Flash	Transformers、TensorRT-LLM	sparse+linear attention、mHC、KV V2	release note 中的性能/价格属于项目方报告
Step-3.7-Flash	Transformers	top-8/288 MoE、MTP、dynamic image tiling	VLM 的视觉 token 和 expert route 一起压测
LTX-2/LTX-2.5	TurboDiffusion 相关实现	W8A8、fused op、少步采样、模态 sparse attention	generator-only 不等于完整 E2E
Wan2.2	Diffusion/DiT 生态	refinement、BaryCache、少步蒸馏	质量提升可能伴随额外 ODE/评估器开销
Gemma4	Transformers、FlashInfer、TensorRT-LLM、ComfyUI	asymmetric NVFP4、GQA/fused attention、generation 修复	RC/快速迭代版本需做长上下文和多轮回归

7. 如果要升级，建议这样验证

如果准备把这些版本放进实际环境，可以分三步做：

第一步：先测稳定版底座。 验证 FlashInfer v0.6.18、Transformers v5.16.1、DeepSpeed v0.19.6、CUTLASS v4.7.1、MLX v0.32.2。先固定 CUDA、驱动、GPU、模型权重和 tokenizer，建立可重复的基线。

第二步：再测模型专用路径。 对 MiniMax-H3 分别跑 SGLang lossless/high、Cache-DiT、B200/B300 FP8、24GB kitchen_int8、单卡 offload 和 4 卡 Ulysses；同时跑 vLLM-Omni 的 NVIDIA 和 AMD recipe。记录视频 SSIM/PSNR、音频质量、首帧、完整 E2E、显存峰值以及 CPU/GPU 时间。

第三步：最后再看 RC/Beta。 vLLM v0.28.1rc0/v0.29.0rc1、TensorRT-LLM v1.3.0rc25、FlashAttention 4 beta29 适合先放在 nightly 或预发布环境。重点覆盖 DeepSeek、Kimi、Qwen、Gemma 的 MoE route、KV manager、mask compilation、CUDA Graph、paged prefill 和异常恢复。

8. 结论

MiniMax-H3 的优化已经覆盖多层。 从 VisualVAE、音频 token，到 Cache-DiT、FP8/INT8、Ulysses、ROCm、ComfyUI 节点和服务化 API，模型本体之外的配套正在快速完善。
DeepSeek、Kimi、Qwen、GLM 的差异已经落到 backend。 它们虽然都使用 attention 或 MoE，但实际需要的 tile、state、route、quantization 和 graph 策略并不相同。
稳定版、RC 和 Beta 要分开验证。 FlashInfer、Transformers、CUTLASS 等可以先进入基线；TensorRT-LLM RC、vLLM RC 和 FA4 beta 则应按模型和硬件逐项测试。
记录“支持”还不够。 至少要写清 GPU、卡数、分辨率或上下文、batch、是否近似、音视频是否一致、是否出现 OOM/hang，以及指标是不是完整 E2E。

AIGC 开源一周｜MiniMax-H3 的多后端适配，和热门模型的基础设施更新