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

栏目：互联网 | 来源：机器之心Pro | 2026-09-13 17:17

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 在总体支持与博客准备上的付出。