vLLM-Omni 与 FastH3 助力 MiniMax H3 迈入实时服务时代

MiniMax 旗下的联合音视频生成模型 MiniMax H3 的服务落地，长期面临全链路延迟的行业难题。不同于仅需优化单一推理模块的文本大模型，H3 的每一次生成请求需要依次经过庞大的 Qwen3-VL 文本编码器、长序列音视频 DiT（扩散Transformer）推理模块、相互独立的视频与音频 VAE（变分自编码器）解码环节、跨设备与进程的数据传输边界，最终还要完成 H.264/AAC 的媒体封装，任何一个环节的延迟瓶颈都会拉长整体响应时间，仅优化 DiT 核心模块无法解决实际问题。

全链路系统优化打底，破解H3服务延迟难题

针对这一系统级难题，vLLM-Omni 从完整的常驻服务流水线入手展开全链路优化，核心覆盖五大环节：

• 融合注意力计算与通信逻辑，降低跨设备数据传输开销；
• 优化融合 DiT 算子，提升核心推理模块的执行效率；
• 实现并行 VAE 解码，并行处理音视频潜空间的解码任务；
• 优化输出传输路径，采用紧凑的数据传输格式降低带宽占用；
• 搭建并行 MP4 构建流程，加速最终媒体文件的封装产出。
  在 8 卡 NVIDIA B300 的实测配置下，经过全链路优化后，H3 的完整响应延迟相比 Diffusers 基准方案下降了 30.8%，为后续的实时化改造打下了基础。

FastH3蒸馏模型入场，49步去噪缩减为4次前向

仅靠系统级优化仍无法突破推理速度的物理上限，FastVideo 基于 MiniMax H3 蒸馏推出的 FastH3 模型成为关键突破点。FastH3 是采用 DMD2 蒸馏技术训练出的四步学生模型，完整复用了 H3 的文本编码器、视频 VAE、音频 VAE、tokenizer 与调度器，仅将原本需要 49 次 transformer 前向的去噪循环，缩减为 5 个 sigma 位置上的 4 次前向计算，大幅降低了核心推理环节的计算量。
vLLM-Omni 同时支持 FastH3 的 Dense/Data-Free 产物与官方推荐的 VSA/Data-Free 产物，融合逻辑在 checkpoint 流式加载时完成，随后对融合后的权重进行分片，通过已优化的注意力、VAE、传输与媒体路径提供服务。需要注意的是，FastH3 携带全秩增量，无法通过 LoRA 层表达，因此融合是在加载时完成而非按请求动态切换，仅标识为 FastH3 的产物会被自动融合，其他第三方适配器仍会走动态 LoRA 路线。

实测8卡B300跑出实时生成，10秒视频生成仅需8.7秒

在 8 卡 B300 的实测环境中，FastH3 产出一个时长为 10.125 秒的完整 MP4 音视频文件，总耗时仅为 8.678 至 8.710 秒，完整响应的就绪时间短于视频本身的播放时长，正式实现实时生成服务。本次定义的“实时”指完整响应的就绪时间快于内容播放时长，不等同于流式交付或首帧生成时间。
当前 FastH3 已支持文本到音视频（t2va）、文生视频（fl2va）、参考生视频（ref2va）等主流任务，可通过 ComfyUI 的自定义节点直接调用，该路径与原生 ComfyUI 的 MiniMax-H3 实现互补：原生 ComfyUI 目前支持更