vLLM-Omni 上的 MiniMax H3：从系统级优化到基于 FastVideo FastH3 的实时服务

MiniMax H3 的服务是一个系统问题。一个请求要经过一个庞大的 Qwen3-VL 编码器、一个长序列的音视频 DiT、相互独立的视频与音频 VAE、设备与进程的边界，最后还要完成 H.264/AAC 的封装。只优化 DiT，其余环节的时延依然留在那里。

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

在实测的八卡 B300 配置上，FastH3 产出一个 10.125 秒的完整 MP4 用时8.678 至 8.710 秒。本文中的实时指完整响应的就绪时间快于其播放时长，并不指流式交付或首帧时间。

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

MiniMax H3 以文本、图像、视频和音频作为输入，联合生成视频与同步音频。它的各个组件在算力、显存和放置上的要求各不相同：

图 1：文本走 H3/Qwen3-VL 编码器；视觉与音频条件还会分别经过各自的 VAE。条件潜变量与带噪的目标潜变量组成一条打包序列，进行联合的音视频去噪，之后再分别解码并构建 MP4。

已发布的 checkpoint 覆盖三种服务任务：

DiT 主导了基础调度，但它并不是唯一的瓶颈。编码器的常驻会影响容量；去噪被缩短之后，VAE 解码就会显现出来；而原始帧仍然必须跨越进程边界并被封装成 MP4。这就是为什么这个故事要从系统级优化讲起。

2. 基准测试口径与证据边界

本文把两条证据线严格分开：

两条线各自都是有效且已冻结的实验，但它们并不共用同一个源码 SHA、prompt、seed 与产物。因此我们不推导从基础版到 FastH3 的加速比。本文只报告 FastH3 的绝对时延，直到有一组严格对齐的 A/B 实验为止。

2.1 冻结的控制变量

两条线都从同步提交请求开始计时，到收到完整 MP4 为止。下载、启动、编译以及被排除的预热都在这段区间之外。每一个被接受的输出都必须能解码为 H.264 视频加 32 kHz 立体声 AAC，包含预期的帧数与帧率，视频方差与音频 RMS 非零，并通过 prompt 一致性的人工检查。

对 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 接收有效序列长度，打包序列的进一步处理 去掉了结构性的尾部 padding。
• rank 本地边界 只构建本地的 embedding/RoPE 行，并 gather 紧凑的 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 与乘法两次 launch（#6283）。

3.3 并行且融合的 VAE 解码

去噪之后，H3 分别解码视频与音频。VAE patch 并行把 tile 化的视频解码器分布到八张 GPU 上。精确的 VAE 算子路径 加速了解码块的物化、融合的 Q/K 归一化与 RoPE、融合的 SwiGLU，以及带缩放的残差更新，并为不受支持的布局保留 eager 回退。

3.4 GPU 输出准备、传输与 MP4

在数百帧离开 GPU 之前，一个请求还不算完成。优化后的路径让每一次转换都只做一遍：

1. GPU 输出准备 把解码得到的 FP32 BCTHW 帧转换为连续的 uint8 BTHWC，在传输前把视频负载减少 75%。

2. 由 pinned D2H 与 worker 到 engine 的 IPC 传输这份紧凑负载。

3. 直接的 planar 编码、常驻的并行转换器，以及对传输后 strided RGB 平面的支持，让 H.264 直接取用数据，无需再构建一份完整的交错 RGB 缓冲区。

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

3.5 基础 H3 的实测结果

两个运行时都使用八张 B300、相同的 prompt 与 seed、50 个 sigma 点，以及相同的完整 MP4 边界。Diffusers 使用复制权重加原生上下文并行；vLLM-Omni 使用编码器 TP8、带 Fast Ulysses 的 DiT USP8/Ring1、VAE PP8 tile 解码，以及 TRTLLM_ATTN。

视频链接：https://mp.weixin.qq.com/s/Ue4Uiv_VATM1i3Essqs4rA

借助无损优化，vLLM-Omni 把完整响应的时延相对 Diffusers 降低了30.8%，相当于1.445 倍的加速。这里的无损指加速不依赖量化、稀疏注意力、缓存复用或减少去噪步数。它并不意味着输出逐位一致：不同的 kernel 实现与浮点归约顺序仍可能扰动扩散轨迹。

这些改进压掉的是去噪周边的开销。FastH3 处理的是剩下的主导项，把去噪循环本身从 49 次前向降到 4 次。

4. 扩展通用的 H3 服务架构

通用 H3 这条线包含两类不同的生产控制手段。DLO 与编码器分离改变的是容量与放置；可选的量化权重与近似注意力则是用数值保真度换显存或时延。这些路径解释的是如何装得下、如何扩展、如何加速更广义的架构。它们没有参与第 6 节 FastH3 数字的产生。

4.1 分布式逐层卸载

DLO（Distributed Layerwise Offload，分布式逐层卸载）在 HBM 中保留一个有界的 DiT 层窗口，其余部分从主机内存流式取用。AllGather 模式从主机侧分片集体重建活跃层；rank 本地模式则流式取用各 rank 常规 loader 产生的张量。选哪一种取决于互连、主机带宽、内存、常驻层数与请求并发度。

图 2：DLO 在当前层计算的同时准备下一层。机制与部署权衡见 DLO 专文。

8× B300 BF16 DLO 帕累托前沿

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

图 3：时延与显存的帕累托前沿。r 为常驻 DiT block 数。实心点为非受支配的测量值，空心点为被支配的测量值。在 r = 35 时，DLO 以 5.1% 的时延代价把上报的 HBM 降低 37.5%；r = 0 是显存最小的端点。

4.2 编码器分离

H3 在 BF16 下需要常驻约 51.5 GB 的 Qwen3-VL 编码器权重。编码器分离路径 把这个一次性的编码器移入一个独立的 vLLM 阶段，它拥有自己的放置、张量并行、副本、队列、kernel 与 prefix cache。编排器把它输出的第 50 层隐藏状态与 token 角色标签，与原始媒体一起交给 DiT/VAE 阶段。

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

4.3 可选的量化与注意力加速

第 3 节刻意使用稠密 BF16 注意力与已发布 checkpoint 的精度。通用的 H3 部署可以另外选择以下路径，但每一条都是一种独立的质量与性能画像，而不是无损的运行时收益。

权重与激活量化

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

图 5：在线 FP8 在加载时创建 FP8 权重与缩放因子，随后在线量化符合条件的激活。离线 SVDQuant 把 NVFP4 W4A4 的基础分支与一个 BF16 低秩修正结合起来。来源：vLLM-Omni #5910 与 #6162，以及 cookbook 中的在线 FP8 与 SVDQuant 两篇解读。

一个量化画像必须报告峰值 HBM、启动期主机内存、checkpoint 存储、时延，以及同 seed 下的视频与音频质量。容量上的收益并不自动等于时延上的收益，loader 的正确性也不构成融合 kernel 有收益的证据。

B300 上的在线 FP8：容量与时延

下面这组稠密、全常驻的结果把在线 FP8 与已发布的 BF16 checkpoint 隔离开来比较。两行都使用 8 张 B300、带 Fast Ulysses 的 Ulysses8/Ring1、编码器 TP8、VAE PP8 tile 解码、CUDNN 注意力，以及 10 秒 1344×768 / 24 FPS、请求 50 个 sigma 点（49 次 DiT 前向）的负载。一次预热被排除，每个数值取三次计入请求的均值。“Stage generation” 是原生的扩散阶段计时器；E2E 是离线客户端从提交到拿回视频与音频张量的墙钟时间，不含 MP4 封装。

每一次计入的请求都返回了 243 帧 1344×768 的 RGB 图像与 32 kHz 立体声音频。三次重复使用了不同的 seed，因此它们确立的是输出形状与生成成功，而不是与 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 的 tile 级判定，绕过选中的 Softmax 与 P×V tile。

下表以稠密、未量化的注意力为基线，对比视频质量与加速比：

视频链接：https://mp.weixin.qq.com/s/Ue4Uiv_VATM1i3Essqs4rA

上面测量所用的 Skip-Softmax 配置在保持视频质量方面是保守的。使用者可以选择更高的阈值，或在更多去噪步上启用 Skip-Softmax，以质量换取更多速度。TRTLLM 注意力指南 记录了这些控制项。

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、tokenizer 与调度器，但把去噪循环缩减为 5 个 sigma 位置上的 4 次 transformer 前向。vLLM-Omni 同时支持 Dense/Data-Free 产物与推荐的 VSA/Data-Free 产物。

这次集成是跨两个层次的协作：

• FastVideo开发并发布蒸馏出的学生模型与适配器产物。
• vLLM-Omni验证该产物，在 checkpoint 流式载入的同时完成融合，对融合后的权重分片，并通过已优化的注意力、VAE、传输与 MP4 路径提供服务。

FastH3 不是一个可按请求切换的普通 LoRA。除低秩因子外，它的产物还携带满秩的 delta 与替换权重，这是普通 LoRA 层无法表达的。因此 vLLM-Omni 选择在分片之前先融合这份产物，而不是按请求激活它。

图 7：Turbo 保持基础权重不变，并施加按请求选择的 A/B 旁路。FastH3 则在分片之前把低秩与满秩的改动融合进一个专用的学生模型。来源：Turbo#6476、DLO 支持#6550与 FastH3 集成#6714→ Turbo#6476、DLO 支持#6550、FastH3 集成#6714，以及#6909中的VSA 与 Ulysses 支持

FastH3 v1 只接受 T2VA，要求使用它自己的四步调度与 checkpoint 的 flow shift，拒绝 offload，并且不能再接纳另一个请求时的 LoRA。它的 VSA 变体还额外要求 CUDA、外部的 FastVideo kernel 包，以及本地或纯 Ulysses 序列并行。这些是服务契约，不是调优建议。

6. B300 上的 FastH3 实时服务

本节报告 vLLM-Omni 86b85c07 上 FastH3 的绝对结果。它不会去除以来自不同源码、prompt 与 seed 的基础 H3 结果。

6.1 固定产物版本

本次测量的 Dense/Data-Free 产物固定在 Hugging Face 修订版 bcf40ca6f457ed66f8badf13514943e390205fca：

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

6.2 部署与请求

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

6.3 十秒的关键路径

Profiler 的计时来自一次单独的插桩运行；承载时延主张的是干净的 E2E。

原始基准测试数据包：待发布前置条件。 稳定版数据包尚未发布。在发布之前，这条证据交接要求 必须被替换为一个数据包 URL，其中包含原始的干净样本与 profiler 样本、日志、环境清单、媒体元数据与哈希，以及关键路径行与时长扫描两者的拓扑证据。

6.4 五秒、十秒与十五秒的扫描

这次扫描固定了 prompt、seed、分辨率、产物、调度、拓扑、注意力、VAE、输出路径与 CPU 亲和性。H3 把请求的时长对齐到 124、243 与 362 帧。

全部六次计入的请求都满足 RTF_client <= 1.0：在测试过的每一个时长上，完整 MP4 的生成都快于播放。

FastH3 Dense 与 VSA 对比

#6909 中另有一组配置对齐的研究，在 8×B300、1344×768、24 FPS 下比较 Dense/Data-Free 产物与推荐的 VSA/Data-Free 产物。两者都使用 4 次 transformer 前向、纯 Ulysses 8 与一次被排除的预热；下表每个结果都是每种后端与时长各一次计入的请求。Dense 使用 TRTLLM_ATTN；VSA 使用 FASTVIDEO_VSA、top-k 64 与 Triton kernel 路径。

这些服务端测量确立了配置对齐下的 VSA 加速比；它们所用的源码修订版与计时边界，与上面客户端 E2E 时长扫描的不同。VSA 的安装、起服命令与回退检查，见持续维护的 MiniMax H3 recipe[63]。

6.5 代表性输出与质量边界

下列由 FastVideo 提供的 FastH3 输出覆盖同样的 5 / 10 / 15 秒时长档。它们是 1280x736 的代表性样例，不是 6.4 节用于计时的 1344x768 产物。

视频链接：https://mp.weixin.qq.com/s/Ue4Uiv_VATM1i3Essqs4rA

上面的链接是展示用样例。可用于发布的计时与媒体证据仍受 6.3 节原始数据包前置条件的约束。

去噪被压缩之后，新的尾部开销显现出来：在 10 秒这一档上，插桩路径中合并的 VAE、推导的传输与 CPU MP4 合计约占三秒。RFC #6872 提议把 VAE 分块、D2H/IPC 与编码重叠起来，而不是孤立地优化这些阶段。对这套 B300 配置，它的乐观上限约为 0.87 秒（约占 E2E 的 10%，仅重叠传输与编码）与 1.75 秒（约占 20%，再叠加增量式 VAE 解码）；对应的 go/no-go 目标分别是至少 5% 与 10% 的 E2E。相关的草稿 PR #6885 报告了在四卡 L20X 可行性运行上，VAE 到完整 MP4 环节减少 0.8847 秒（26.57%）且媒体精确一致，这不是 B300 上的生产服务结果。

7. 生产建议与限制

现在部署选择已经很具体：

astH3 VSA 只在搭配与之匹配的产物、CUDA kernel 包、FASTVIDEO_VSA，以及本地或纯 Ulysses 注意力时受支持。不要在没有经过新的正确性、质量、显存与时延认证的情况下，任一 FastH3 画像与 DLO、量化、缓存策略、Ring/AllGather 稀疏注意力或编码器分离组合使用。持续更新的特性兼容性追踪 记录了跨特性的工作，但它可能落后于已合并的实现。在选定生产组合之前，请核实相关的 PR 与已维护的 recipe。

MiniMax H3 使用 MiniMax H3 Community License Agreement。商业与托管服务的运营方应与法务一起审阅其当前的地域、署名、营收、可接受使用与安全保障要求。

在后训练方面，vLLM-Omni 也可以在 VeRL-Omni 中为 H3 提供 rollout 服务；训练属于生态覆盖，不属于本次服务基准测试的一部分。

8. 结论与聚焦的后续工作

系统级优化让完整的 H3 流水线变得高效。随后，FastVideo 的四步前向学生模型把专用的 T2VA 画像推进到了完整响应快于播放的区间，在实测的 B300 系统上成立。

余下的工作直接沿着这条推进路线展开：

• 在目标 Blackwell 系统上认证原生的 FastVideo SM100a VSA kernel，并集成原生融合的 NVFP4 kernel；
• 在目标 Blackwell 平台与多 seed 负载上，集成并认证 Sol-Attn 这一即时稀疏注意力后端；
• 完成基础版与 FastH3 对齐的多 seed 质量评估；
• 实现分块的 VAE 到传输到 MP4 流水线，并认证一个 GPU 编码器；
• 在 VeRL-Omni、UniRL 与 RLinf 中增强 MiniMax H3 的后训练集成，包括可扩展的 rollout 服务、显式的资源放置与端到端训练验证；以及
• 认证 FastH3 与编码器分离或其他扩展特性的组合，而不是靠推断得出兼容性结论。

致谢

这项工作建立在 vLLM、vLLM-Omni、VeRL-Omni、MiniMax H3、FastVideo、FastH3、Diffusers 与 NVIDIA 的诸多贡献之上。我们特别感谢 FastVideo 团队开源 FastH3，并与 vLLM-Omni 社区协作完成了已合并的服务集成。

我们感谢 @Isotr0py 完成基础 H3 支持；感谢 @lishunyang12、@evanchueng、@Gaohan123 与 @david6666666 在 DLO、基础集成与在线 FP8 上的工作；感谢 @gcanlin 与 @yuanwu2017 完成编码器分离；感谢 @bobboli、@fan2956、@mo-ke-ke、@mglyn、@MosCloud 与 @ultism 在注意力、融合 kernel、量化、VAE、传输与媒体路径上的工作；感谢 @princepride 完成 FastH3 集成与 VSA/Ulysses 支持；感谢 @NancyFyong 与 @mengchengTang 完成 VeRL-Omni 集成。

特别感谢 Hongsheng Liu 与 Roger Wang 在总体支持与博客准备上的付出。

• vLLM-Omni 仓库 — github.com/vllm-project/vllm-omni
• FastVideo 仓库 — github.com/hao-ai-lab/FastVideo
• vLLM 官方博客 — vllm.ai/blog/2026-09-01-minimax-h3-production-serving