MiniMax H3 的服务是一个系统级问题。一个请求要经过一个庞大的 Qwen3-VL 编码器、一个长序列的音视频 DiT（Diffusion Transformer，扩散变换器）、相互独立的视频与音频 VAE（Variational Autoencoder，变分自编码器）、设备与进程的边界，最后还要完成 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。]
图 1：文本走 H3/Qwen3-VL 编码器；视觉与音频条件还会分别经过各自的 VAE。条件潜变量与带噪的目标潜变量组成一条打包序列，进行联合的音视频去噪，之后再分别解码并构建 MP4。
已发布的 checkpoint 覆盖三种服务任务：
| 任务 | 输入 | 典型用途 |
|---|---|---|
| T2VA | 文本 | 创意生成与合成媒体 |
| FL2VA | 文本加首帧/尾帧图像 | 受控转场与图像动画化 |
| Ref2VA | 混合的图像、视频与音频参考 | 一致性编辑与参考引导生成 |
DiT 主导了基础调度，但它并不是唯一的瓶颈。编码器的常驻会影响容量；去噪被缩短之后，VAE 解码就会显现出来；而原始帧仍然必须跨越进程边界并被封装成 MP4。这就是为什么这个故事要从系统级优化讲起。
2. 基准测试口径与证据边界
本文把两条证据线严格分开：
| 证据线 | 目的 |
|---|---|
| 基础 H3：Diffusers 与 vLLM-Omni 对照 | 在 50 点稠密 BF16 调度下衡量系统级的运行时优化 |
| FastH3 时长扫描 | 在 4 次 DiT 前向下衡量绝对低时延与完整响应的实时表现 |
两条线各自都是有效且已冻结的实验，但它们并不共用同一个源码 SHA、prompt、seed 与产物。因此我们不推导从基础版到 FastH3 的加速比。本文只报告 FastH3 的绝对时延，直到有一组严格对齐的 A/B 实验为止。
2.1 冻结的控制变量
| 控制项 | 基础 H3 系统线 | FastH3 线 |
|---|---|---|
| 硬件 | 8x NVIDIA B300 | 8x NVIDIA B300 |
| 任务 | 经 FL2VA partition 的 T2VA | 仅 Dense/Data-Free T2VA |
| 分辨率 / 帧率 | 1344x768 / 24 FPS | 1344x768 / 24 FPS |
| 源码 | vLLM-Omni b81aeb7 |
vLLM-Omni 86b85c07 |
| 模型 | MiniMax H3 42ed227e |
同一基础模型加上固定版本的 FastH3 产物 |
| Prompt / seed | 官方 case-T2VA 扩展 prompt，SHA-256 98f36b...f06；seed 0 |
固定的 FastH3 prompt；seed 1101 |
| 调度 | 50 个 sigma 点 / 49 次 DiT 前向 | 5 个 sigma 点 / 4 次 DiT 前向 |
| 拓扑 | 编码器 TP8；DiT USP8、Ring1；VAE PP8 tile | 单副本；编码器 TP8；DiT USP8、Ring1；VAE PP8 tile |
| 注意力 | 稠密 BF16 TRTLLM_ATTN，Fast Ulysses |
稠密 TRTLLM_ATTN，Fast Ulysses |
| 重复次数 | 一次不计入的全形状预热，随后为计入的请求 | 每种形状一次不计入的可行性请求，随后每个时长两次交叉运行 |
两条线都从同步提交请求开始计时，到收到完整 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 之前，一个请求还不算完成。优化后的路径让每一次转换都只做一遍：
- GPU 输出准备把解码得到的 FP32 BCTHW 帧转换为连续的 uint8 BTHWC，在传输前把视频负载减少 75%。
- 由 pinned D2H 与 worker 到 engine 的 IPC 传输这份紧凑负载。
- 直接的 planar 编码、常驻的并行转换器，以及对传输后 strided RGB 平面的支持，让 H.264 直接取用数据，无需再构建一份完整的交错 RGB 缓冲区。
FP32 BCTHW -> uint8 BTHWC -> pinned D2H/IPC -> planar frames -> H.264/AAC MP43.5 基础 H3 的实测结果
两个运行时都使用八张 B300、相同的 prompt 与 seed、50 个 sigma 点，以及相同的完整 MP4 边界。Diffusers 使用复制权重加原生上下文并行；vLLM-Omni 使用编码器 TP8、带 Fast Ulysses 的 DiT USP8/Ring1、VAE PP8 tile 解码，以及 TRTLLM_ATTN。
| 运行时 | 模型执行（s） | Prompt（s） | DiT 合计 / 每次前向（s） | 视频 / 音频 VAE（s） | MP4（s） |
|---|---|---|---|---|---|
| Diffusers | - | - | - | - | - |
| vLLM-Omni | 54.246 | 0.057 | 51.800 / 1.057 | 0.952 / 0.055 | 1.528 |
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（High Bandwidth Memory，高带宽显存）中保留一个有界的 DiT 层窗口，其余部分从主机内存流式取用。AllGather 模式从主机侧分片集体重建活跃层；rank 本地模式则流式取用各 rank 常规 loader 产生的张量。选哪一种取决于互连、主机带宽、内存、常驻层数与请求并发度。
![图 2：DLO 在当前层计算的同时准备下一层。机制与部署权衡见 DLO 专文。]
图 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 是显存最小的端点。]
图 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：编码器容量与扩散容量可以独立扩展。已合并的单机 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 两篇解读。]
图 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 封装。
| 权重 | Stage generation（均值，n=3） | E2E（均值，n=3） | 每 rank 峰值 HBM | 结果 |
|---|---|---|---|---|
| BF16 | 52.572 s | 53.118 s | 87.16 GiB | 无损基线 |
| 在线 FP8 | 49.769 s | 50.331 s | 53.27 GiB | stage 时间低 5.3%；峰值 HBM 低 38.9% |
每一次计入的请求都返回了 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。]
图 6：SAGE 把 Q、K、P、V 量化到 FP8 用于 Q×K 与 P×V，而 Skip-Softmax 依据 BLASST 的 tile 级判定，绕过选中的 Softmax 与 P×V tile。
下表以稠密、未量化的注意力为基线，对比视频质量与加速比：
| 注意力策略 | SAGE 配置 | Skip-Softmax 配置 | 模型执行 | 加速比 | 相对稠密的 LPIPS | 样例 |
|---|---|---|---|---|---|---|
| TRTLLM 基线 | 关 | 关 | 54.246 s | 1.000x | 视频 | |
| SAGE FP8 | dtype_qk=fp8_e4m3, q_block_size=1, k_block_size=16 |
关 | 44.787 s | 1.211x | 0.3697 | 视频 |
| Skip-Softmax | 关 | 阈值 0.05；至 0.97 前禁用 | 50.029 s | 1.084x | 0.0917 | 视频 |
| SAGE + Skip-Softmax | dtype_qk=fp8_e4m3, q_block_size=1, k_block_size=16 |
阈值 0.05；至 0.97 前禁用 | 43.867 s | 1.237x | 0.3750 | 视频 |
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 + DLO | 通过已维护的 H3 recipe 支持；所选拓扑需在本地认证 |
| 基础 H3 + DLO + 在线 FP8 | 支持，包括经 #6279 的 AllGather 路径；性能与质量仍需本地认证 |
| 基础 H3 + 编码器分离 | 已合并的单机路径 |
| FastH3 + DLO | 不支持：FastH3 的融合发生在 load_weights() 中，而 offload 会安装另一条主机侧权重路径 |
| FastH3 + VSA | 在 CUDA 上支持，需匹配的 VSA 产物、fastvideo-kernel、FASTVIDEO_VSA，以及本地或纯 Ulysses 注意力；Ring 与 AllGather SP 会被拒绝 |
| FastH3 + 编码器分离 | 尚未认证；本文报告的 FastH3 结果没有使用它 |
按步执行补充说明。H3 可以在去噪步之间接纳与中止请求（#5810），但现有的共批测试并没有改善时延。在 issue #5700 中研究取消与回收机制以及小规模低利用率负载期间，请求模式仍是推荐做法。