我们将MiniMax H3-Image带到NVIDIA Vera Rubin上，借助 vLLM-Omni。在四块 GPU 上，原生 4096×4096 生成在我们的短提示词服务基准测试中达到中位数 0.87 秒。另一套吞吐量配置可提供6,115 张图像/小时，推算为146,755 张图像/天。
按每张图像 0.06879 美元计算，采用MiniMax 官方 Standard 4K API 定价示例（以发布前折扣作为假设售价），峰值吞吐量在全额可计费利用率下推算为每 GPU 每小时 105.16 美元的总收入，或在每 GPU 每小时 78.87 美元（75% 利用率下）。这些估算未计入运营成本；每日容量是基于实测速率的推算。
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 秒. A4K 图像编辑，使用一张参考图平均值1.77 秒. 单张 RTX 5090 配合 CPU 逐层卸载需要52.29 秒以及61.45 秒来处理这些相同的请求。每次计时都包含完整的 PNG 响应。
对于2K 文生图，一张单张 H200平均1.49 秒使用 BF16 和常驻权重。
对于此处使用的详细咖啡产品提示词，Rubin 平均1.09 秒在 4K 下。那个0.87 秒头条数字来自 Rubin Bringup 中一个单独的短提示词服务基准测试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 输出在 VAE 解码之前，跨六个去噪步骤贡献16,384 个目标图像 token。参考图会增加编码工作和条件 token。这给我们三个实际目标：DiT 计算、解码开销和模型内存。参见模型架构。
更快的 DiT
在 Blackwell 和 Rubin 上，MXFP8 GEMM加速符合条件的 DiT 线性层，同时减少其权重占用。Ulysses SP4将序列工作分布到四块 GPU 上；DiT TP1 保持权重复制。AdaLN 缓存在其输入和权重匹配时复用精确的条件投影。全部六个去噪步骤仍会运行。编码器和 VAE 保持其配置的精度；Hopper 和 Ampere 使用 BF16。
更快的解码
VAE 解码独立的图像瓦片。我们将这些瓦片分布到各 GPU 上，然后合并使用多个 CUDA 流的 CUDA Graph 重放在每个 GPU 上：重放减少了重复的启动开销，而流允许瓦片重叠。
在四块 GB300 GPU 上单独进行的 BF16 对照实验说明了这一点为何重要。VAE 解码从2.635 s 降至 0.213 s，使端到端延迟从大约4.0 s 降至 1.6 s，即快了 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 上。回归检查确认重复请求均已完成，且解码像素未发生变化。
随后我们使用现有的 VAE CUDA Graph 和 AdaLN 缓存路径，比较了 SP4、SP2×DP2 和 SP1×DP4。四块 GPU 在 SP4 下达到了0.87 秒的响应时间，即6,115 张图像/小时使用四个副本。以下扫描固定原生 4K 文生图、无参考图、六步和 MXFP8 DiT 线性层，并在每个并发点使用单独的 160 请求提示词–种子语料库：20 个短提示词，每个 122–160 个字符，跨八个种子。上述跨硬件咖啡产品请求使用 1,292 个字符的提示词，并报告三个种子的均值。
延迟
在并发 1 下使用 SP4 时，中位延迟为0.866 秒（p950.944 秒）：比 GB200 快 2.21×并且比 GB300 快 1.64×。所有三种延迟配置均使用四个 GPU、SP4 和 MXFP8。
吞吐量
四个单 GPU 副本（SP1×DP4）达到6,115 张图像/小时在并发 8 下，具有4.411 秒中位延迟。SP4 达到4,407 张图像/小时在并发 2 下，具有1.421 秒中位数。副本增加38.7% 吞吐量；亚秒级和峰值吞吐量头条是单独的工作点。
在跨平台固定 SP4 的情况下，Rubin 提供2.20× GB200和1.60× GB300峰值吞吐量。每个绘制点包含 160 个预热请求；副本提供独立图像，而不将它们合并为 DiT 批次。
经济性
6,115 张图像/小时预计为146,755 张 4K 图像/天每四 GPU Rubin 系统。我们使用每张图像 0.06879 美元，即MiniMax 官方 API 定价示例用于标准 4K 文生图且无参考图，在发布折扣之前。按该假定售价，预计总收入为105.16 美元/GPU/小时在 100% 可计费利用率下，或78.87 美元/GPU/小时在 75% 下。
收入 = 图像/小时 × 价格/图像 × 可计费利用率 ÷ 4 个 GPU。实际托管 API 费用随文本 token 用量而变化。收入数字为运营成本之前；每日容量外推测量速率，而非 24 小时负载测试。
其他硬件
H3-Image 也支持在AMD Instinct、Intel Arc Pro、Huawei Ascend 和 Moore Threads硬件上，通过以下实现和配方。这些社区验证使用它们自己的工作负载和配置；上述匹配的性能数据涵盖我们的 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 配置使用 1、2 或 4 个 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 集成方面的工作。