MiniMax H3 上线 vLLM-Omni：集成 FastVideo FastH3 实现实时音视频生成

一个两阶段优化故事：首先降低整个 MiniMax H3 服务栈的开销，然后集成 FastVideo 的四步 FastH3，实现比播放速度更快的完整 MP4 生成。

MiniMax H3 服务是一个系统性问题。一个请求要经过大型 Qwen3-VL 编码器、长序列音视频 DiT、独立的视频和音频 VAE、设备与进程边界，最后还要进行 H.264/AAC 构建。只优化 DiT 会在其他地方留下大量延迟。

vLLM-Omni 因此从完整的常驻流水线入手：注意力和通信、融合 DiT 算子、并行 VAE 解码、紧凑输出传输以及并行 MP4 构建。FastVideo 的 FastH3 随后针对剩余的主要耗时项，将 49 次 DiT 前向替换为 4 次。

在实测的八卡 B300 配置上，FastH3 在 8.678-8.710 秒内生成了完整的 10.125 秒 MP4。在本文中，实时意味着完整响应比其播放时长更快就绪。它并不意味着流式传输或首帧时间。

1. 为什么 MiniMax H3 服务是一个系统级问题

MiniMax H3 从文本、图像、视频和音频参考中联合生成视频和同步音频。其各组件具有不同的计算、内存和部署要求：

request -> encoder -> joint audio/video DiT -> video + audio VAEs
        -> GPU output preparation -> D2H/IPC -> H.264/AAC MP4

图 1：文本使用 H3/Qwen3-VL 编码器；视觉和音频条件也使用各自的 VAE。条件潜变量和带噪目标潜变量组成一个打包序列，用于联合音视频去噪，随后进行独立解码和 MP4 构建。来源：MiniMax H3 模型卡、vLLM-Omni 配方 和 Diffusers 流水线。

发布的检查点涵盖三种服务任务：

DiT 在基础调度中占主导地位，但它并不是唯一的瓶颈。编码器常驻影响容量；去噪缩短后 VAE 解码变得明显；原始帧仍然必须跨越进程边界并成为 MP4。这就是为什么故事从系统级优化开始。

2. 基准测试契约与证据边界

本文保持两条证据线相互独立：

这两条证据线使用有效、冻结的实验，但并非相同的源 SHA、提示词、种子和产物。因此我们不推导基础到 FastH3 的加速比。在获得匹配的 A/B 之前，本文报告 FastH3 的绝对延迟。

2.1 冻结控制项

两条路径均从同步请求提交计时至收到完整的 MP4。下载、启动、编译以及被排除的预热均在该时间区间之外。每个被接受的输出必须能解码为 H.264 视频加立体声 32 kHz AAC，包含预期的帧数和 FPS，具有非零的视频方差和音频 RMS，并通过提示词遵循度审查。

对于 FastH3，保留已验证的视频和音频流时长，并定义 T_media = max(T_video, T_audio)，即有效的完整 MP4 播放时长：

RTF_client = T_client / T_media

RTF_client <= 1.0 是完整响应的实时性标准。媒体检查失败、缺少音频、OOM、加速器错误或意外回退都会在重复测量之前终止该配置。

其他硬件有意作为配方覆盖而非另一个结果矩阵：H200 和数据中心 CUDA、RTX PRO 5000、RTX 4090、RTX 5090、GB10 以及 ROCm。

3. 使用 vLLM-Omni 进行系统级优化

基础 H3 路径保留已发布的 BF16 权重、50 个 sigma 点以及稠密注意力覆盖。这些优化遵循执行路径而非功能目录。

3.1 长序列注意力与通信

H3 将文本、音频和视频 token 作为一条长打包序列进行去噪。对于典型工作负载，58,758 个有效 token 占用 58,816 token 的对齐缓冲区。vLLM-Omni 在三个边界处降低开销：

• TRTLLM_ATTN 接收有效序列长度，打包序列精化移除结构性后缀填充。
• Rank 本地边界仅构造本地 embedding/RoPE 行，并收集紧凑的 128 通道投影，而非 5,376 通道的隐藏状态。
• Fast Ulysses 使用 NCCL SymmetricMemory 以注意力所需的布局交换分片，消除了 all-to-all 周围单独的重新布局。

3.2 融合 DiT 算子

49 次前向循环在其矩阵乘法周围反复应用小操作。vLLM-Omni 将 Q/K RMSNorm 与 RoPE 融合（#5990），合并 FP32 调制、归一化和残差工作（#6281、#6878），并用融合 SwiGLU 替换单独的 SiLU 和乘法启动（#6283）。

3.3 并行与融合 VAE 解码

去噪之后，H3 独立解码视频和音频。VAE patch 并行将分块视频解码器分布到八块 GPU 上。精确 VAE 算子路径加速解码器块物化、融合 Q/K 归一化和 RoPE、融合 SwiGLU 以及缩放残差更新，并为不支持的布局提供 eager 回退。

3.4 GPU 输出准备、传输与 MP4

只有当数百帧离开 GPU 后，请求才算完成。优化路径对每种转换只执行一次：

1. GPU 输出准备将解码后的 FP32 BCTHW 帧转换为连续的 uint8 BTHWC，在传输前将视频负载减少 75%。
2. Pinned D2H 和 worker 到引擎的 IPC 传输紧凑负载。
3. 直接平面编码、持久并行转换器以及对传输的跨步 RGB 平面的支持，无需再构造另一个完整的交错 RGB 缓冲区即可馈入 H.264。

FP32 BCTHW -> uint8 BTHWC -> pinned D2H/IPC -> planar frames -> H.264/AAC MP4

3.5 实测基础 H3 结果

两个运行时都使用八块 B300 GPU、相同的提示词和种子、50 个 sigma 点，以及相同的完整 MP4 边界。Diffusers 使用复制权重和原生上下文并行；vLLM-Omni 使用编码器 TP8、DiT USP8/Ring1 配合 Fast Ulysses、VAE PP8 分块解码，以及 TRTLLM_ATTN。

使用无损优化，vLLM-Omni 将完整响应延迟相比 Diffusers 降低了 30.8%，即 1.445 倍加速。这里的无损意味着该加速不依赖量化、稀疏注意力、缓存复用或减少去噪步数。它并不意味着输出逐位相同：不同的内核实现和浮点归约顺序仍可能扰动扩散轨迹。

这些改进减少了去噪周边的开销。FastH3 通过将去噪循环本身从 49 次前向减少到四次，来攻克剩余的主导项。

4. 扩展通用 H3 服务架构

通用 H3 路线结合了两种不同的生产控制手段。DLO 和分离式编码改变容量与放置；可选的量化权重和近似注意力以数值保真度换取内存或延迟。这些路径说明了如何适配、扩展和加速更广泛的架构。它们并未产生第 6 节中的 FastH3 数据。

4.1 分布式逐层卸载

DLO 在 HBM 中保留一个有界的 DiT 层窗口，同时从主机内存流式传输其余部分。AllGather 模式从主机分片集体重建活动层；rank-local 模式流式传输每个 rank 的正常加载器产生的张量。正确的选择取决于互连、主机带宽、内存、常驻层数和请求并发度。

图 2：DLO 在当前层计算时准备下一层。有关机制和部署权衡，请参阅专门的 DLO 文章。

8× B300 BF16 DLO 帕累托前沿

在官方 BF16 MiniMax-H3 FL2VA 检查点（5.175 秒，1344×768，SP8/Ulysses8/Ring1/DP1/TP1，AllGather，CUDNN 注意力）上，第一个请求因惰性 CUDA/cuDNN/JIT 工作而被排除，其余两个请求取平均值。生成的视频和音频具有预期的输出形状。

图 3：延迟–内存帕累托前沿。r 是常驻 DiT 块的数量。实心点是非支配测量值；空心点是被支配的。在 r = 35 时，DLO 将报告的 HBM 降低了 37.5%，代价是 5.1% 的延迟；r = 0 是最小内存端点。

4.2 分离式编码

H3 以 BF16 保留约 51.5 GB 的 Qwen3-VL 编码器权重。分离式编码器路径将该一次性编码器移入独立的 vLLM 阶段，拥有自己的放置、张量并行、副本、队列、内核和前缀缓存。编排器在 DiT/VAE 阶段之前，将其第 50 层隐藏状态和 token 角色标签与原始媒体合并。

图 4：编码器和扩散容量独立扩展。合并的单节点方案通过编排器返回条件，并保持扩散阶段内联；它不配置 OmniConnector。SHM/RDMA 仍是 RFC #5707 中未来的跨节点选项。

4.3 可选量化与注意力加速

第 3 节有意使用密集 BF16 注意力和已发布检查点精度。通用 H3 部署可以选择以下额外路径，但每一条都是独立的质量-性能配置，而非无损的运行时收益。

权重与激活量化

• 在线 FP8。合并后的全局 FP8 路径从 BF16 检查点出发，在加载时对符合条件的 DiT 和 Qwen3-VL 文本解码器线性层进行量化。嵌入、归一化、RoPE、视觉塔、两个 VAE 以及对精度敏感的投影保持其声明的精度。
• SVDQuant NVFP4 W4A4。合并后的离线加载器将 NVFP4 W4A4 基础 GEMM 与 BF16 低秩校正相结合。当前证据确立了检查点与正确性兼容性；原生融合残差 GEMM 性能路径仍属未来工作。

图 5：在线 FP8 在加载时创建 FP8 权重和缩放因子，然后在线量化符合条件的激活。离线 SVDQuant 将 NVFP4 W4A4 基础分支与 BF16 低秩校正相结合。来源：vLLM-Omni #5910 和 #6162，以及 cookbook 的在线 FP8和 SVDQuant 说明。

量化配置必须报告峰值 HBM、启动主机 RAM、检查点存储、延迟以及同种子视频/音频质量。容量收益并不自动等于延迟收益，加载器正确性也不是融合内核收益的证据。

B300 在线 FP8 容量与延迟

以下密集常驻结果将在线 FP8 与已发布的 BF16 检查点隔离对比。两行均使用 8 块 B300 GPU、Ulysses8/Ring1 配合 Fast Ulysses、编码器 TP8、VAE PP8 分块解码、CUDNN 注意力，以及 10 秒 1344×768 / 24 FPS 请求，包含 50 个请求的 sigma 点（49 次 DiT 前向）。排除一次预热；每个值为三次测量请求的均值。“阶段生成”为原生扩散阶段计时器；E2E 为离线客户端墙钟时间，直至返回视频和音频张量，不包括 MP4 封装。

每个测量请求均返回 243 帧 RGB，分辨率为 1344×768，以及 32 kHz 立体声音频。三次重复使用不同种子，确立了输出形状和成功生成，而非与 BF16 的逐像素等价性。

TRTLLM_ATTN 中的量化与稀疏注意力

TRTLLM_ATTN 提供两种可选的有损加速模式：

• SAGE 量化将 QK 和 PV 两条路径均量化为 FP8。
• Skip-Softmax利用 QK 结果动态跳过不重要的 Softmax 和 P×V 计算。

图 6：SAGE 将 Q、K、P、V 量化为 FP8 以进行 Q×K 和 P×V，而 Skip-Softmax 使用 BLASST 瓦片级决策来跳过选定的 Softmax 和 P×V 瓦片。

下表将视频质量与加速比与密集、未量化注意力基线进行对比：

实测的 Skip-Softmax 配置在保持视频质量方面是保守的。 用户可以选择更高的阈值或启用 Skip-Softmax 以进行更多去噪步骤，从而以质量换取额外速度。 TRTLLM attention guide 记录了这些控制项。

Cache-DiT

Cache-DiT 是一种请求级缓存策略，而非注意力后端。对于 H3， quality=high 启用动态逐步复用，而 quality=lossless 恢复参考路径。其命中/未命中行为取决于部署环境，因此需要独立的延迟和质量验证，未包含在上文的注意力 A/B 中。

4.4 兼容性边界

步骤执行侧边栏。 H3 可以在去噪步骤之间接纳和中止请求（#5810），但现有的协同批处理测试并未改善延迟。在 issue #5700 中调查取消/回收和小型未充分利用工作负载期间，仍建议使用请求模式。

5. 从系统优化到 FastH3

FastH3 是 FastVideo 的 MiniMax H3 四步 DMD2 学生模型。它复用 H3 编码器、视频 VAE、音频 VAE、分词器和调度器，但将去噪循环减少为在五个 sigma 位置上的四次 transformer 前向。vLLM-Omni 同时支持 Dense/Data-Free 工件和推荐的 VSA/Data-Free 工件。

该集成是跨两个层面的协作：

• FastVideo 开发和发布蒸馏学生模型及适配器工件。
• vLLM-Omni 验证工件，在检查点流式传入时进行融合，对融合后的权重进行分片，并通过优化的注意力、VAE、传输和 MP4 路径提供服务。

FastH3 不是普通的可请求切换的 LoRA。除了低秩因子外，其工件还携带普通 LoRA 层无法表示的全秩增量和替换权重。因此，vLLM-Omni 在分片之前融合工件，而不是按请求激活它。

图 7：Turbo 保持基础权重不变，并应用请求选择的 A/B 附属组件。FastH3 在分片之前将低秩和全秩变更融合到专用学生模型中。来源：Turbo #6476、 DLO 支持 #6550 以及 FastH3 集成 #6714， 其中 VSA 和 Ulysses 支持见 #6909。

FastH3 v1 仅接受 T2VA，要求其四前向调度和检查点 流偏移，拒绝卸载，且不能接受另一个请求时 LoRA。其 VSA 变体还额外要求 CUDA、外部 FastVideo 内核包， 以及本地或纯 Ulysses 序列并行。这些是服务契约， 而非调优建议。

6. 在 B300 上实时 FastH3 服务

本节报告 vLLM-Omni 86b85c07 上的绝对 FastH3 结果。它 不除以来自不同来源/提示/种子的基础 H3 结果。

6.1 固定产物

所测量的 Dense/Data-Free 产物固定到 Hugging Face 修订版 bcf40ca6f457ed66f8badf13514943e390205fca：

FASTH3_REV=bcf40ca6f457ed66f8badf13514943e390205fca
FASTH3_DIR=/models/FastH3-LoRA
 
hf download FastVideo/FastVideo-FastH3-4-step-Preview-v1-LoRA \
  dense-datafree/adapter_model.safetensors \
  --revision "$FASTH3_REV" \
  --local-dir "$FASTH3_DIR"
 
echo "4ce198c83132251b7fd0de2503823aa49c53983f068318f66cb19eaefb7fcc12  $FASTH3_DIR/dense-datafree/adapter_model.safetensors" \
  | sha256sum -c -

该适配器为 1,485,626,152 字节。同时固定仓库修订版和文件 校验和；仓库名称仍包含 Preview-v1，而匹配的 vLLM-Omni 集成已合并。

6.2 服务与请求

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 \
VLLM_WORKER_MULTIPROC_METHOD=spawn \
VLLM_OMNI_VIDEO_SYNC_TIMEOUT=1800 \
vllm serve "$H3_MODEL" --omni \
  --host 127.0.0.1 --port 8095 --trust-remote-code \
  --task-type fl2va --served-model-name MiniMaxAI/MiniMax-H3 \
  --num-gpus 8 --usp 8 --ring 1 --ulysses-a2a-permute \
  --text-encoder-tp-size 8 \
  --vae-patch-parallel-size 8 --vae-parallel-mode tile --vae-use-tiling \
  --diffusion-attention-backend TRTLLM_ATTN \
  --lora-path "$FASTH3_DIR/dense-datafree/adapter_model.safetensors"

curl -sS -X POST http://127.0.0.1:8095/v1/videos/sync \
  -F 'prompt=In a snowy blue-purple forest, Ori carefully walks past a sleeping giant; footsteps crunch in the snow while the creature breathes and softly snorts.' \
  -F 'width=1344' -F 'height=768' -F 'aspect_ratio=16:9' -F 'fps=24' \
  -F 'num_inference_steps=4' -F 'seed=1101' \
  -F 'extra_params={"task":"t2va","duration":10.0,"flow_shift":12.0,"audio_flow_shift":3.0}' \
  -o fasth3_10s.mp4

该服务使用一个 FastH3 副本、编码器 TP8、DiT DP1 x TP1 x USP8，搭配 Ring1 和 Fast Ulysses、VAE PP8 分块解码、TRTLLM_ATTN，以及 标准紧凑输出/MP4 路径。

6.3 十秒关键路径

Profiler 计时器来自单独的插桩运行；干净的 E2E 承载 延迟声明。

原始基准测试包——待发布门禁。 稳定包尚未 发布。在发布之前，此 证据交接要求 必须替换为包含原始干净/Profiler 样本、日志、 环境清单、媒体元数据和哈希，以及关键路径行和时长扫描的拓扑证据的包 URL。

6.4 五秒、十秒和十五秒扫描

该扫描保持提示、种子、分辨率、产物、调度、拓扑、 注意力、VAE、输出路径和 CPU 亲和性固定。H3 将请求的 时长对齐到 124、243 和 362 帧。

所有六个测量请求均满足 RTF_client <= 1.0：对于每个测试时长， 完整 MP4 生成都比播放更快。

FastH3 Dense 与 VSA

一项单独的匹配研究在 #6909 中 比较了 Dense/Data-Free 产物与推荐的 VSA/Data-Free 产物，在 8×B300 上以 1344×768 和 24 FPS 进行。两者均使用四次 transformer 前向、纯 Ulysses 8，以及一次丢弃的预热；下面每个结果均为每个后端和时长的一次测量请求。 Dense 使用 TRTLLM_ATTN；VSA 使用 FASTVIDEO_VSA、top-k 64 和 Triton 内核路径。

这些服务器端测量确立了匹配的 VSA 加速比；它们使用的 源修订版和计时边界与上述客户端 E2E 时长 扫描不同。有关 VSA 安装、启动命令和回退检查，请参阅维护中的 MiniMax H3 配方。

6.5 代表性输出与质量边界

这些提供的 FastH3 输出覆盖相同的 5/10/15 秒时长类别。 它们是 1280x736 的代表性示例，而非第 6.4 节中使用的 1344x768 计时产物。

这些片段是演示示例。发布级别的计时和 媒体证据仍受第 6.3 节中原始数据包门禁的约束。

减少去噪暴露出新的尾部：在 10 秒配置上，组合的 VAE、派生传输和 CPU MP4 在插桩路径中约占三秒。RFC #6872 提出重叠 VAE 分块、D2H/IPC 和编码，而非孤立地优化 这些阶段。对于此 B300 配置，其乐观上限为：当传输与 编码重叠时约 0.87 秒（约 10% E2E），当同时重叠增量 VAE 解码时约 1.75 秒（约 20% E2E）；相应的 go/no-go 目标为至少 5% 和 10% E2E。 相关草案 PR #6885 报告在四卡 L20X 可行性运行中 VAE 到完整 MP4 减少 0.8847 秒（26.57%）， 媒体完全一致，但并非 B300 生产服务结果。

7. 生产指导与限制

部署选择现在很具体：

FastH3 VSA 仅在其匹配产物、CUDA 内核包、 FASTVIDEO_VSA 以及本地或纯 Ulysses 注意力下受支持。请勿将任一 FastH3 配置与 DLO、量化、缓存策略、Ring/AllGather 稀疏 注意力或编码器分离组合，除非进行新的正确性、质量、 内存和延迟验证。实时 功能兼容性跟踪器 记录跨功能工作，但可能滞后于已合并的实现。在选择生产组合之前，请验证 链接的 PR 和维护的配方。

MiniMax H3 使用 MiniMax H3 社区许可协议。 商业和托管服务运营者应与其法律顾问一起审查其当前的领土、 署名、收入、可接受使用和安全保障要求。

对于后训练，vLLM-Omni 还可以在 VeRL-Omni 中服务 H3 rollout；训练属于生态系统 覆盖范围，而非本服务基准的一部分。

8. 结论与重点未来工作

系统级优化使完整的 H3 流水线高效。FastVideo 的 四前向学生模型随后将专用 T2VA 配置在测量的 B300 系统上 推进到快于播放的完整响应生成。

剩余工作直接源于这一进展：

• 在目标 Blackwell 系统上对原生 FastVideo SM100a VSA kernel 进行验证，并集成原生融合 NVFP4 kernel；
• 在目标 Blackwell 平台和多随机种子工作负载上集成并验证 Sol-Attn 即时稀疏注意力后端；
• 完成匹配的 base/FastH3 多随机种子质量评估；
• 实现 chunkwise VAE-to-transport-to-MP4 pipeline 并验证 GPU 编码器；
• 增强 MiniMax H3 在 VeRL-Omni、UniRL 和 RLinf 中的后训练集成，支持可扩展的 rollout serving、显式资源放置和端到端训练验证；以及
• 验证 FastH3 与编码器解耦或其他扩展特性的组合，而不是推断兼容性。

致谢

本工作建立在 vLLM、vLLM-Omni、VeRL-Omni、MiniMax H3、FastVideo、FastH3、Diffusers 和 NVIDIA 的贡献之上。我们特别感谢 FastVideo 团队开源 FastH3，并与 vLLM-Omni 社区合作完成合并的 serving 集成。

我们感谢 @Isotr0py 提供 base H3 支持；@lishunyang12、@evanchueng、@Gaohan123 和 @david6666666 在 DLO、基础集成和 online-FP8 方面的工作；@gcanlin 和 @yuanwu2017 在编码器解耦方面的工作；@bobboli、@fan2956、@mo-ke-ke、@mglyn、@MosCloud 和 @ultism 在注意力、融合 kernel、量化、VAE、transport 和媒体路径方面的工作；@princepride 在 FastH3 集成、B300 验证和 VSA/Ulysses 支持方面的工作；以及 @NancyFyong 和 @mengchengTang 在 VeRL-Omni 集成方面的工作。

特别感谢 Hongsheng Liu 和 Roger Wang 的总体支持与博客准备工作。

附录 A. 可复现性

A.1 计时层级

vLLM-Omni 的测量是嵌套的；父级和子级数值不得相加：

每次前向的去噪时间除以实际 DiT 前向次数，而不是请求的 sigma 位置数。Profiler 数值来自单独的诊断请求，不能替代未进行 profiler 分析的客户端延迟。

A.2 Base H3 vLLM-Omni 复现

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 \
VLLM_WORKER_MULTIPROC_METHOD=spawn \
VLLM_OMNI_VIDEO_SYNC_TIMEOUT=1800 \
vllm serve "$H3_MODEL" --omni \
  --host 127.0.0.1 --port 8093 --trust-remote-code \
  --task-type fl2va --num-gpus 8 --usp 8 --ring 1 \
  --ulysses-a2a-permute --text-encoder-tp-size 8 \
  --vae-patch-parallel-size 8 --vae-parallel-mode tile --vae-use-tiling \
  --diffusion-attention-backend TRTLLM_ATTN

规范请求使用第 2 节中的 prompt 和 seed、50 个请求的 sigma 点、flow shift 12、audio flow shift 3 和 10 秒目标。

参考文献

• vLLM-Omni 仓库
• FastVideo 仓库
• FastH3 技术概览
• FastH3 四步适配器
• FastH3 VSA 和 Ulysses 集成
• MiniMax H3 模型
• Diffusers MiniMax H3 pipeline
• MiniMax H3 serving 配方
• Distributed Layerwise Offload
• 特性兼容性跟踪器
• Chunkwise 输出 pipeline RFC
• VeRL-Omni 仓库
• UniRL 仓库
• RLinf 仓库