AREX Feed Article
vLLM 官宣：MiniMax H3 成片 10.1 秒、8.7 秒渲染完成，生成快于播放
于北京时间 9 月 2 日凌晨发布公告：通过 vLLM-Omni 推理栈集成 FastVideo 团队开源的 4 步蒸馏 FastH3，服务 MiniMax H3 时，一段 10.1 秒的完整 MP4（视频与同步音频）在 8.7 秒内渲染完成，生成快于播放。vLLM 官网 9 月 1 日刊出合作博客《》，给出测量口径与分项耗时。
这一成绩是 vLLM 团队的实测口径：8× NVIDIA B300、1344×768、24 FPS、纯文本到视频与音频（T2VA）任务下，10.125 秒的成片端到端耗时 8.678～8.710 秒。公告对「实时」的定义是完整响应（包括封装好的 MP4）快于播放时长，不是流式输出或首帧时间。
画面来自 vLLM 合作博客配发的 （1280×736、24 FPS，H.264 视频与 32 kHz 立体声 AAC；计时成绩所用成片为 1344×768）。
三档时长，六次测量全部达标
vLLM 博客给出 5/10/15 秒三档的完整测量，固定提示词、种子、分辨率与配置：
| 请求时长 | 成片时长（视频/音频） | 端到端耗时 | 实时系数 RTF |
|---|---|---|---|
| 5 秒（124 帧） | 5.167 / 5.175 秒 | 4.602 / 4.396 秒 | 0.889 / 0.849 |
| 10 秒（243 帧） | 10.125 / 10.125 秒 | 8.678 / 8.710 秒 | 0.857 / 0.860 |
| 15 秒（362 帧） | 15.083 / 15.083 秒 | 14.177 / 14.059 秒 | 0.940 / 0.932 |
RTF 是端到端耗时除以成片播放时长，小于等于 1 即「完整响应快于播放」。六次测量全部达标，10 秒档的生成速度约为播放速度的 1.16～1.17 倍。
10 秒档的分项耗时（profiler 口径）：文本编码 0.052 秒，DiT 去噪共 5.532 秒（4 次前向、每次 1.383 秒），视频与音频 VAE 共 1.247 秒，传输 0.881 秒，CPU 端 H.264/AAC 封装 0.868 秒，单卡峰值显存 94.1 GiB。
五项优化：从长序列注意力到并行 MP4 封装
把 H3 服务当作系统工程：一次请求要依次经过大型 Qwen3-VL 文本编码器、长序列音视频 DiT、分离的视频与音频 VAE、设备到主机（D2H）传输，最后在 CPU 封装成 H.264/AAC 的 MP4。只优化 DiT，会留下大量其他环节的延迟。
- 长上下文注意力与 Fast Ulysses 通信。H3 把文本、音频、视频 token 拼成一条打包长序列，典型请求含 58,758 个有效 token（对齐到 58,816）。vLLM-Omni 让注意力后端拿到有效序列长度并去掉结构填充，各 rank 只构造本地 embedding/RoPE 行、只搬运 128 通道的投影而非 5,376 通道的隐藏状态；Fast Ulysses 用 NCCL SymmetricMemory 直接交换注意力所需布局的分片，省去 all-to-all 前后的重排。
- 全融合 DiT 算子。Q/K 的 RMSNorm 与 RoPE 合并、FP32 modulation 与归一化/残差合并、SwiGLU 的 SiLU 与乘法合并成单次 kernel 调用。
- 跨 8 GPU 并行视频/音频 VAE 解码。视频 VAE 以 tile 为单位的 patch parallelism 分布到 8 张 GPU，decoder 块算子路径一并融合。
- D2H 前削减 75% 载荷。解码出的 FP32 BCTHW 帧先转为连续的 uint8 BTHWC，再走 pinned 内存传输与 worker-to-engine IPC；H.264 编码直接消费平面帧，不再构造整幅交错 RGB 缓冲，H.264/AAC 并行封装。
- FastH3 的 4 步蒸馏消灭剩余瓶颈（见下节）。
系统优化本身的收益，vLLM 用基座 H3 对照：同样 8× B300、同一提示词与种子、50 个 sigma 点、同一「完整 MP4」边界下，Diffusers 端到端 82.239 秒，vLLM-Omni 56.917 秒，延迟降低 30.8%（1.445 倍）。vLLM 注明这是匹配部署下的结果，不是像素级一致声明。
49 次 DiT 前向压成 4 次：FastH3 的集成方式
FastH3 是 FastVideo 团队（加州大学圣迭戈分校 Hao AI Lab 的，与 Nuva Lab、NVIDIA FastGen 团队合作）对 MiniMax H3 做的 4 步 DMD2 蒸馏：去噪循环从 50 个 sigma 点、49 次 DiT 前向降到 5 个 sigma 点、4 次前向，同时复用 H3 的文本编码器、视频/音频 VAE、tokenizer 与 scheduler。8 月 27 日，FastVideo 开源 FastH3 Preview v1（推荐 4 步 VSA/Data-Free checkpoint，附全量权重与预提取 LoRA），其称 8× B200 上 15 秒 768p 视频可在 13 秒内生成，单张 Blackwell GPU 最高 14 倍加速。
画面来自 FastVideo 团队 （1344×768、24 FPS），卡通猫在白板前展示 "FASTVIDEO x FastH3" 字样。
vLLM-Omni 的集成不是普通 LoRA 热切换：FastH3 产物除低秩因子外还带全秩 delta 与替换权重，普通 LoRA 层装不下，因此 vLLM-Omni 在权重加载时先融合、再分片，而不是按请求激活。请求侧走标准同步接口，示例提示词为 "In a snowy blue-purple forest, Ori carefully walks past a sleeping giant..."（一只叫 Ori 的角色在蓝紫色雪林中小心走过沉睡的巨人，脚步踩雪作响，巨人呼吸并轻鼾），4 步、seed 1101；服务端配置为 encoder TP8、DiT USP8/Ring1 + Fast Ulysses、VAE PP8 tile、dense TRTLLM_ATTN，单副本部署。
只接 T2VA：FastH3 v1 的边界与待补的证据
vLLM 把 FastH3 v1 的适用范围写得很具体：只支持 T2VA，不接受 DLO 卸载与 VSA 稀疏注意力变体，不叠加请求时 LoRA；也不能与 DLO、VSA、量化、缓存策略、其他 Ulysses 传输或 encoder 分离随意组合，这些组合需重新做正确性、质量、显存与延迟评估。MiniMax H3 本身覆盖 T2VA、FL2VA（首尾帧条件）与 Ref2VA（参考条件）三类任务，需要完整任务覆盖的部署仍走基座 H3 或 Turbo 适配器路线。
证据层面还有未兑现部分：vLLM 说明基座 H3 与 FastH3 两条证据线使用了不同代码版本、提示词与种子，因此不推导「基座到 FastH3 的加速比」，只报告绝对延迟；同 seed 重复输出字节级一致，但基座与 FastH3 的多 seed 质量对比尚未完成，官方不作质量等价声明；原始 benchmark 数据包（原始计时样本、日志、环境清单、媒体哈希）也未发布。另外，MiniMax H3 采用 Community License，商用与托管服务需自行审查其地域、署名、收入与用途条款。
“拿去，跑得更快”：模型方与开源方的回应
公告特别致谢 MiniMax 发布 H3、FastVideo 团队开源 FastH3 并协助服务集成、NVIDIA 的持续赞助与联合优化。模型发布方 引用公告称，这套方案基于 vLLM-Omni 与 FastH3、NVIDIA 硬件支持，全部公开：「实时生成让交互式视频成为可能，开放的基线让每个人都能改进它。拿去，跑得更快。」并在评论区回复「干得漂亮！」。
引用推文称「这就是开源的力量！我们必须赢！」，感谢 vLLM 的持续支持与赞助；团队成员 Will Lin（Hao AI Lab 博士生、FastVideo 开发者）在中说「很高兴看到我们稀疏蒸馏的 MiniMax H3 被开源社区支持和使用，更多更新即将到来」；FastVideo 工程师 Aryan 在中称「比你能看完它的速度还快」，并在中预告「今天晚些时候我们还会发布更多 FastH3 内容」。在评论区以鼓掌表情回复。vLLM-Omni 贡献者 称「生成比播放还快的视频，到现在仍让我觉得不真实」；前 Hugging Face 亚太生态负责人 评价「vLLM-Omni 正在成为视频领域的 vLLM-realtime」。社区用户 则点出这次成绩的关键在同步音频：「越过实时线的是完整 MP4，而不只是视频帧管线」。
vLLM 博客列出的下一步包括集成 FastH3 的 VSA 变体与 NVFP4 融合核、完成基座与 FastH3 的多 seed 质量评估，以及把 VAE 解码、D2H 传输、MP4 封装三段重叠执行的 chunkwise 管线：其乐观估算是端到端还能再省约 0.87～1.75 秒（约占端到端的 10%～20%）。在原始数据包与质量对比结果落地前，这项成绩仍只有 vLLM 自己的测量背书。