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

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

图 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。

MiniMax-H3 model-card 样例

vLLM-Omni 基线

借助无损优化，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：时延与显存的帕累托前沿。<em>r</em> 为常驻 DiT block 数。实心点为非受支配的测量值，空心点为被支配的测量值。在 <em>r</em> = 35 时，DLO 以 5.1% 的时延代价把上报的 HBM 降低 37.5%；<em>r</em> = 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。

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

TRTLLM Baseline

SAGE

Skip-Softmax

SAGE+Skip-Softmax

上面测量所用的 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：

FASTH3_REV=bcf40ca6f457ed66f8badf13514943e390205fcaFASTH3_DIR=/models/FastH3-LoRAhf 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-back
来源：机器之心