vLLM-Omni 在 NVIDIA Vera Rubin 上支持 MiniMax H3-Image,4K 生成 0.87 秒
H3-Image Day-0 Support: 4K in 0.87s with Vera Rubin
vLLM-Omni 团队将 MiniMax H3-Image 接入 NVIDIA Vera Rubin,四卡 SP4 配置下原生 4096×4096 文生图短提示词基准中位延迟为 0.87 秒,另一吞吐配置达 6115 张/小时。
原文给出 H3-Image 在 Rubin 上的延迟、吞吐与跨硬件部署配置,可据此判断 4K 文生图的落地成本。

我们借助 vLLM-Omni 将 MiniMax H3-Image 引入 NVIDIA Vera Rubin。在四块 GPU 上,原生 4096×4096 生成在我们的短提示词服务基准测试中达到中位数 0.87 秒。另一套吞吐量配置可达到每小时 6,115 张图像,推算为每天 146,755 张图像。
按MiniMax 官方 Standard 4K API 定价示例的每张图像 0.06879 美元(以发布前折扣前的价格作为假设售价),在完全可计费利用率下,峰值吞吐量推算为每 GPU 每小时 105.16 美元的总收入,在 75% 利用率下为每 GPU 每小时 78.87 美元。这些估算未计入运营成本;每日产能是对实测速率的推算。
H3-Image 是一个用于文本到图像生成和图像编辑的开放权重模型。单个检查点以六步采样处理这两项任务,无需放大器即可生成原生高分辨率图像,并支持最多 16 张参考图像。
我们将 H3-Image 引入消费级和数据中心 GPU,覆盖 NVIDIA、AMD、Intel 和摩尔线程(MUSA),以及华为昇腾 NPU。
- 单 GPU 和多 GPU 服务。可在单块 RTX GPU 上运行,也可将生成分布到多块数据中心 GPU 上,并提供针对不同内存容量的配置。
- 在 10 种 NVIDIA 硬件上实测。比较不同输出分辨率和参考图像数量下的文本到图像生成与编辑延迟。
质量
油画笔触、多视角相机绘图、日文海报字体以及米粒上的微小文字,揭示了较小图像可能丢失的细节。一个游戏场景增加了风化的石头和反射光。每项均使用一张由 H3-Image 生成的 4K 图像,在保持宽高比的情况下调整为 1K 和 2K,因此构图保持不变。
性能
两种 API 模式很直接:文本到图像接收一个提示词;图像编辑接收一个提示词和一张或多张参考图像。我们的主要比较使用 2K(2048×2048)和 4K(4096×4096)输出,每次请求返回一张图像。提示词和参考文件在各机器间保持不变。请求参数请参阅 MiniMax 的API 指南。
在下方选择文本到图像或图像编辑。对于编辑,选择1、2、4、8 或 16 张参考图像;输出尺寸反映实测案例。
对于 4K 文本到图像,四块 GB300 GPU 平均耗时1.48 秒。使用一张参考图像的 4K 图像编辑平均耗时1.77 秒。单块 RTX 5090 配合 CPU 逐层卸载,处理相同请求分别耗时52.29 秒和61.45 秒。每次计时均包含完整的 PNG 响应。
对于 2K 文本到图像,单块 H200 在 BF16 和常驻权重下平均耗时1.49 秒。
对于此处使用的详细咖啡产品提示词,Rubin 在 4K 下平均耗时1.09 秒。0.87 秒的标题数据来自 Rubin Bringup 中另一项独立的短提示词服务基准测试,而非此请求。两者均使用四块 GPU、SP4 和 MXFP8;请求语料、HTTP 客户端和汇总统计量不同。
每个结果都会显示其 GPU 数量。测试设置列出了确切的 GPU 型号、每块 GPU 的 CUDA 可见显存、互连方式、功耗上限和服务配置。GPU 数量、精度和内存放置方式各不相同,因此这些数据比较的是部署系统,而非隔离 GPU 架构。1K 检查返回 1024×1024 图像;在本地模型的默认最小画布下,它们以 2048×2048 生成后再缩放。因此它们不代表原生 1K 扩散计算。部分 1K 和 2K 运行还使用了不同的分配器设置,见测试设置。
基准数据。柱状图显示预热后三次运行的平均值,并附最小–最大范围。配置、计时范围和 10 分钟请求限制记录在测试设置中。
推理优化
H3-Image 将Qwen3-VL 编码器与33.1B 稠密 DiT及图像 VAE 配对。原生 4096×4096 输出在六个去噪步骤中贡献16,384 个目标图像 token,之后才进行 VAE 解码。参考图会增加编码工作和条件 token。这给我们带来三个实际目标:DiT 计算、解码开销和模型内存。参见模型架构。
更快的 DiT
在 Blackwell 和 Rubin 上,MXFP8 GEMM加速符合条件的 DiT 线性层,同时减小其权重占用。Ulysses SP4 将序列工作分布到四块 GPU;DiT TP1 保持权重复制。AdaLN 缓存在输入和权重匹配时复用精确的条件投影。全部六个去噪步骤仍会运行。编码器和 VAE 保持其配置的精度;Hopper 和 Ampere 使用 BF16。
更快的解码
VAE 解码独立的图像分块。我们将这些分块分布到多块 GPU,然后在每块 GPU 上结合CUDA Graph 重放与多个 CUDA 流:重放减少重复的启动开销,而流允许分块重叠执行。
在四块 GB300 GPU 上进行的单独 BF16 对照显示了这一点为何重要。VAE 解码从2.635 秒降至 0.213 秒,使端到端延迟从约4.0 秒降至 1.6 秒,即快 2.5 倍。两条路径都已将分块分布到四块 GPU;这是图与流结合带来的增益。对照测量。
适配更小的 GPU
逐层 CPU 卸载用权重传输时间换取 GPU 内存。RTX 5090 和 RTX 5080 卸载 DiT 和文本编码器,并即时解码 VAE。RTX 6000D 和 RTX PRO 6000 保持 DiT 常驻,卸载编码器并使用 VAE CUDA Graph。这实现了单 GPU 部署,同时解释了与常驻数据中心配置之间部分延迟差距的原因。
Rubin 启动
我们的起点是 vLLM-Omni 的 H3-Image 实现和vLLM 的 Rubin 支持,使用 CUDA 13.4 运行时。H3-Image 在该基础上增加了稠密扩散工作负载:原生 4096×4096 图像在六个去噪步骤中贡献 16,384 个目标图像 token,随后进行 VAE 解码。我们测试了这条路径如何将 Rubin 的能力转化为交互式延迟和服务吞吐量。
我们为这些运行做了两处更改:
- MXFP8 集成。我们将 Omni 的扩散线性层接入 vLLM 的在线
MXFP8 加载与内核选择。在 Rubin 上,符合条件的 DiT 线性层使用
FlashInfer CuTe-DSL MXFP8 GEMM;注意力使用
TRTLLM_ATTN。这些都是 现有的库内核。文本编码器和 VAE 保持原生精度。 - 可靠的 4K 输出。重复的 4K 请求暴露出输出 传输路径中的停滞。我们在传输解码后的 uint8 张量之后,将最终的图像布局转换 移到 CPU 上。回归检查确认重复 请求均已完成,且解码像素未发生变化。
随后我们比较了 SP4、SP2×DP2 和 SP1×DP4,使用现有的 VAE CUDA Graph 和 AdaLN 缓存路径。四块 GPU 在 SP4 下达到 0.87 秒响应,或在四个副本下达到 6,115 张图像/小时。以下扫描固定原生 4K 文生图、无参考图、六步和 MXFP8 DiT 线性层,并在每个并发点使用单独的 160 请求提示词–种子语料库:20 个短提示词, 每个 122–160 个字符,跨八个种子。上述跨硬件的咖啡产品 请求使用 1,292 个字符的提示词,并报告三种子的均值。
延迟
在并发为 1 的 SP4 下,中位延迟为 0.866 秒(p95 0.944 秒):比 GB200 快 2.21×,比 GB300 快 1.64×。所有 三种延迟配置均使用四块 GPU、SP4 和 MXFP8。
吞吐量
四个单 GPU 副本(SP1×DP4)在并发 8 下达到 6,115 张图像/小时,中位延迟 4.411 秒。SP4 在 并发 2 下达到 4,407 张图像/小时,中位延迟 1.421 秒。副本增加 38.7% 吞吐量; 亚秒级和峰值吞吐量头条是独立的运行点。
在跨平台固定 SP4 的情况下,Rubin 的峰值吞吐量达到 GB200 的 2.20× 和 GB300 的 1.60×。每个绘制点包含 160 个预热请求; 副本独立服务图像,不将它们合并为 DiT 批次。
经济性
6,115 张图像/小时 推算为每套四 GPU Rubin 系统 每天 146,755 张 4K 图像。我们使用 每张图像 0.06879 美元,即 MiniMax 官方 API 定价示例 中的 标准 4K 文生图、无参考图、发布折扣前。 按该假定售价,在 100% 可计费利用率下,预计毛收入为 每 GPU 每小时 105.16 美元, 或在 75% 下为 每 GPU 每小时 78.87 美元。
收入 = 图像/小时 × 价格/图像 × 可计费利用率 ÷ 4 块 GPU。 实际托管 API 费用随文本 token 用量变化。收入数字为 运营成本前;每日容量外推自实测速率,而非 24 小时负载测试。
其他硬件
H3-Image 还通过以下实现和配方支持 AMD Instinct、Intel Arc Pro、华为昇腾和 摩尔线程硬件。这些 社区验证使用各自的工作负载和配置;上述匹配的性能数据涵盖我们的 NVIDIA 运行。
AMD Instinct。AMD 方案包含在 MI325X 和 MI350X 上的文生图与编辑测量,覆盖一到八块 GPU,使用 BF16 和 FLASH_ATTN。它涵盖 Ulysses 序列并行和张量并行。ROCm 使用单个 VAE 图副本,以避免并发图重放时观察到的挂起问题。
Intel Arc Pro B70。XPU 方案记录了实测的一卡、两卡和四卡部署。其推荐的四卡布局使用 DiT TP4 配合文本编码器逐层卸载,以适配 32 GB 显卡。较小的布局也会卸载 DiT 权重;VAE 解码在 XPU 上以 eager 模式运行。
华为昇腾。NPU 方案涵盖 Atlas 800I A2、Atlas 800T A3 和 Atlas 350 (A5)。实测的 A2 和 A5 配置使用一、二或四个 NPU,采用 BF16 和 eager 执行。四 NPU 配置在 A2 上使用 DiT TP4,在 A5 上使用 Ulysses SP4 配合文本编码器 TP4;较小的配置使用逐层卸载。
摩尔线程 MTT S5000。H3-Image 通过 MUSA 实现获得支持,该实现启用了 VAE 图解码,并包含一份模型专用方案,在 80 GB S5000 显卡上实测了 TP2 和 TP4 布局。图测试会检查与 eager 解码的逐位一致性。
OpenDirector
OpenDirector 是一个面向创作者的智能体驱动平台,由 vLLM-Omni 提交者发起,旨在让 vLLM-Omni 在创意工作流中更易使用。
其 Day-0 H3-Image 集成目前使用 MiniMax 的托管图像 API。创作者可以通过画布或智能体生成和编辑图像,然后将输出用作下一次编辑的参考。我们计划扩展对由 vLLM-Omni 驱动的本地部署 H3-Image 工作流的支持。
致谢
我们感谢 MiniMax 发布 H3-Image 及其模型权重;感谢 NVIDIA 团队和 vLLM 社区在 Vera Rubin 支持方面的工作;以及感谢 vLLM-Omni 和 FlashInfer 贡献者为这项工作所使用的服务与内核基础设施所做的贡献。
我们还感谢 OpenDirector 贡献者在创意工作流中 H3-Image 集成方面的工作。
来源:vLLM Blog · vllm.ai