{"slug": "h3-image-day-0-support-4k-in-0-87s-with-vera-rubin", "title": "H3-Image Day-0 Support: 4K in 0.87s with Vera Rubin", "summary": "MiniMax H3-Image, an open-weight text-to-image and image-editing model, reached 0.87 seconds median for native 4096×4096 generation on four NVIDIA Vera Rubin GPUs using vLLM-Omni, according to a day-0 support benchmark published by the serving team. A separate throughput configuration delivered 6,115 images/hour, projecting to 146,755 images/day, and at MiniMax's official Standard 4K API price of USD 0.06879 per image the team projected USD 105.16/GPU/hour in gross revenue at full billable utilization and USD 78.87/GPU/hour at 75%, before operating costs. The same 4K text-to-image request averaged 1.48 seconds on four GB300 GPUs and 52.29 seconds on a single RTX 5090 with CPU layerwise offload, while 2K text-to-image averaged 1.49 seconds on a single H200 in BF16.", "body_md": "# H3-Image Day-0 Support: 4K in 0.87s with Vera Rubin\n\nWe brought [MiniMax H3-Image](https://huggingface.co/MiniMaxAI/MiniMax-H3-Image)\nto **NVIDIA Vera Rubin** with vLLM-Omni. On four GPUs, native 4096×4096 generation\nreaches **0.87 seconds median** in our short-prompt serving benchmark. A separate\nthroughput configuration delivers **6,115 images/hour**, projecting to\n**146,755 images/day**.\n\nAt **USD 0.06879 per image**, using\n[MiniMax’s official Standard 4K API pricing example](https://platform.minimax.io/docs/pricing/overview)\nbefore launch discounts as an assumed sale price, peak throughput projects to\n**USD 105.16/GPU/hour in gross revenue** at full billable utilization, or\n**USD 78.87/GPU/hour** at 75%. These estimates are before operating costs;\nthe daily capacity is an extrapolation of the measured rate.\n\nH3-Image is an open-weight model for text-to-image generation and image editing. One checkpoint handles both tasks in six sampling steps, generates native high-resolution images without an upscaler, and supports up to 16 reference images.\n\nWe bring H3-Image to **consumer and data-center GPUs**, spanning **NVIDIA, AMD,\nIntel and Moore Threads (MUSA)**, as well as **Huawei Ascend NPUs**.\n\n- **Single- and multi-GPU serving.** Run on a single RTX GPU or distribute\ngeneration across multiple data-center GPUs, with configurations for different\nmemory capacities.\n- **Measured across 10 NVIDIA hardware types.** Compare latency for text-to-image\ngeneration and editing across output resolutions and reference-image counts.\n\n## Quality\n\nOil-paint strokes, a multi-view camera drawing, Japanese poster lettering and\ntiny words on a rice grain reveal what a smaller image can lose. A game\nenvironment adds weathered stone and reflected light. Each uses one H3-Image-generated\n**4K** image, resized to **1K** and **2K** with its aspect ratio preserved,\nso composition stays fixed.\n\n## Performance\n\nThe two API modes are straightforward: **Text-to-Image** takes a prompt;\n**Image Edit** takes a prompt and one or more reference images. Our main\ncomparisons use **2K (2048×2048)** and **4K (4096×4096)** output, with one\nimage returned per request. The prompts and reference files stay fixed across\nmachines. See MiniMax’s [API guide](https://platform.minimax.io/docs/guides/image-generation)\nfor the request parameters.\n\nChoose **Text-to-image** or **Image Edit** below. For editing, select\n**1, 2, 4, 8 or 16 reference images**; output sizes reflect the measured cases.\n\nFor **4K text-to-image**, four GB300 GPUs average **1.48 seconds**. A **4K\nimage edit with one reference** averages **1.77 seconds**. A single RTX 5090\nwith CPU layerwise offload takes **52.29 seconds** and **61.45 seconds** for\nthose same requests. Each timing includes the complete PNG response.\n\nFor **2K text-to-image**, a **single H200** averages **1.49 seconds** with\nBF16 and resident weights.\n\nFor the detailed coffee-product prompt used here, Rubin averages **1.09 seconds**\nat 4K. The **0.87-second** headline comes from a separate short-prompt serving\nbenchmark in **Rubin Bringup**, not this request. Both use four GPUs, SP4 and\nMXFP8; the request corpus, HTTP client and summary statistic differ.\n\nEvery result shows its GPU count. **Test setup** lists the exact GPU model,\nCUDA-visible VRAM per GPU, interconnect, power limit and serving configuration.\nGPU count, precision and memory placement vary, so these figures compare deployed\nsystems rather than isolate GPU architecture. The 1K checks\nreturn 1024×1024 images; with the local model’s default minimum canvas,\nthey are generated at 2048×2048 and resized. They therefore do not represent\nnative 1K diffusion compute. Some 1K and 2K runs also use different allocator\nsettings, shown in Test setup.\n\n[Benchmark data](https://vllm-project.github.io/assets/figures/minimax-h3-image-rubin/api-workload-results.csv).\nBars show three-seed means after warmup, with min–max ranges. Configurations,\ntiming scope and the 10-minute request limit are documented in **Test setup**.\n\n## Inference Optimizations\n\nH3-Image pairs a **Qwen3-VL encoder** with a **33.1B dense DiT** and an image\nVAE. A native 4096×4096 output contributes **16,384 target-image tokens** across\nsix denoising steps, before VAE decoding. References add encoding work and\nconditioning tokens. This gives us three practical targets: DiT compute,\ndecoding overhead and model memory. See the\n[model architecture](https://huggingface.co/MiniMaxAI/MiniMax-H3-Image#model-architecture).\n\n### Faster DiT\n\nOn Blackwell and Rubin, **MXFP8 GEMMs** accelerate eligible DiT linears while\nreducing their weight footprint. **Ulysses SP4** distributes sequence work across\nfour GPUs; DiT TP1 keeps the weights replicated. **AdaLN caching** reuses exact\nconditioning projections when their inputs and weights match. All six denoising\nsteps still run. The encoder and VAE keep their configured precision; Hopper\nand Ampere use BF16.\n\n### Faster Decoding\n\nThe VAE decodes independent image tiles. We distribute those tiles across GPUs,\nthen combine **CUDA Graph replay with multiple CUDA streams** on each GPU:\nreplay reduces repeated launch overhead, while streams allow tiles to overlap.\n\nA separate BF16 control on four GB300 GPUs shows why this matters. VAE decoding\nfell from **2.635 s to 0.213 s**, bringing end-to-end latency from approximately\n**4.0 s to 1.6 s**, or **2.5× faster**. Both paths already distribute tiles across\nfour GPUs; this is the combined graph-and-stream gain.\n[Control measurements](https://vllm-project.github.io/assets/figures/minimax-h3-image-rubin/vae-decoding-control.json).\n\n### Fitting Smaller GPUs\n\n**Layerwise CPU offload** trades weight-transfer time for GPU memory. RTX 5090\nand RTX 5080 offload the DiT and text encoder and decode the VAE eagerly.\nRTX 6000D and RTX PRO 6000 keep the DiT resident, offload the encoder and use\nVAE CUDA Graph. This enables single-GPU deployment while explaining part of\nthe latency gap with resident data-center configurations.\n\n## Rubin Bringup\n\nOur starting point was vLLM-Omni’s H3-Image implementation and\n[vLLM’s Rubin support](https://vllm.ai/blog/2026-10-09-vera-rubin-preview),\nusing a CUDA 13.4 runtime. H3-Image adds a dense diffusion workload to that\nfoundation: a native 4096×4096 image contributes 16,384 target-image tokens\nacross six denoising steps, followed by VAE decoding. We tested how this path\ntranslates Rubin’s capabilities into interactive latency and serving throughput.\n\nWe made two changes for these runs:\n\n- **MXFP8 integration.** We connected Omni’s diffusion linears to vLLM’s online\nMXFP8 loading and kernel selection. On Rubin, eligible DiT linears use**FlashInfer CuTe-DSL MXFP8 GEMM** ; attention uses**`TRTLLM_ATTN`** . These are\nexisting library kernels. The text encoder and VAE retain native precision.\n- **Reliable 4K output.** Repeated 4K requests exposed a stall in the output\ntransfer path. We moved the final image-layout conversion to the CPU, after\ntransferring the decoded uint8 tensor. Regression checks confirmed repeated\nrequests completed and decoded pixels were unchanged.\n\nWe then compared SP4, SP2×DP2 and SP1×DP4, using the existing VAE CUDA Graph and\nAdaLN caching paths. Four GPUs reached **0.87-second responses** with SP4, or\n**6,115 images/hour** with four replicas. The following sweep fixes native 4K\ntext-to-image, no references, six steps and MXFP8 DiT linears, with a separate\n160-request prompt–seed corpus at each concurrency point: 20 short prompts,\neach 122–160 characters, across eight seeds. The cross-hardware coffee-product\nrequest above uses a 1,292-character prompt and reports a three-seed mean.\n\n### Latency\n\nWith SP4 at concurrency 1, median latency is **0.866 seconds** (p95 **0.944\nseconds**): **2.21× faster than GB200** and **1.64× faster than GB300**. All\nthree latency configurations use four GPUs, SP4 and MXFP8.\n\n### Throughput\n\nFour single-GPU replicas (**SP1×DP4**) reach **6,115 images/hour** at concurrency\n8, with **4.411-second median latency**. SP4 reaches **4,407 images/hour** at\nconcurrency 2 with a **1.421-second median**. Replicas add **38.7% throughput**;\nthe subsecond and peak-throughput headlines are separate operating points.\n\nWith SP4 fixed across platforms, Rubin delivers **2.20× GB200** and\n**1.60× GB300** peak throughput. Each plotted point contains 160 warm requests;\nreplicas serve independent images without combining them into a DiT batch.\n\n### Economics\n\n**6,115 images/hour** projects to **146,755 4K images/day** per four-GPU\nRubin system. We use **USD 0.06879 per image**, the\n[MiniMax official API pricing example](https://platform.minimax.io/docs/pricing/overview)\nfor **Standard 4K text-to-image with no references, before launch discounts**.\nAt that assumed sale price, projected gross revenue is **USD 105.16/GPU/hour**\nat 100% billable utilization, or **USD 78.87/GPU/hour** at 75%.\n\nRevenue = images/hour × price/image × billable utilization ÷ 4 GPUs. Actual hosted-API charges vary with text-token usage. Revenue figures are before operating costs; daily capacity extrapolates the measured rate, rather than a 24-hour load test.\n\n## Other Hardware\n\nH3-Image is also supported on **AMD Instinct, Intel Arc Pro, Huawei Ascend and\nMoore Threads** hardware through the implementations and recipes below. These\ncommunity validations use their own workloads and configurations; the matched\nperformance figures above cover our NVIDIA runs.\n\n**AMD Instinct.** The [AMD recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/MiniMaxAI/MiniMax-H3-Image-AMD.md)\nincludes text-to-image and editing measurements on **MI325X and MI350X**, from\none to eight GPUs, using BF16 and `FLASH_ATTN`. It covers Ulysses sequence\nparallelism and tensor parallelism. ROCm uses a single VAE graph replica to\navoid the hangs observed with concurrent graph replays.\n\n**Intel Arc Pro B70.** The [XPU recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/MiniMaxAI/MiniMax-H3-Image-XPU.md)\ndocuments measured one-, two- and four-GPU deployments. Its recommended\nfour-card layout uses **DiT TP4 with text-encoder layerwise offload** to fit\n32 GB cards. The smaller layouts also offload DiT weights; VAE decoding runs\neagerly on XPU.\n\n**Huawei Ascend.** The [NPU recipe](https://github.com/vllm-project/vllm-omni/blob/main/recipes/MiniMaxAI/MiniMax-H3-Image-NPU.md)\ncovers **Atlas 800I A2, Atlas 800T A3 and Atlas 350 (A5)**. Measured A2 and A5\nprofiles use one, two or four NPUs with BF16 and eager execution. Four-NPU\nconfigurations use **DiT TP4 on A2** and **Ulysses SP4 with text-encoder TP4 on A5**;\nsmaller configurations use layerwise offload.\n\n**Moore Threads MTT S5000.** H3-Image is supported through the\n[MUSA implementation](https://github.com/vllm-project/vllm-omni/pull/10139),\nwhich enables VAE graph decoding and includes a\n[model-specific recipe](https://github.com/vllm-project/vllm-omni/blob/5b757b77c05db3562239b19707f059d282de7a62/recipes/MiniMaxAI/MiniMax-H3-Image-MUSA.md)\nwith measured **TP2 and TP4** layouts on 80 GB S5000 cards. The graph tests\ncheck bitwise agreement with eager decoding.\n\n## OpenDirector\n\n[OpenDirector](https://github.com/ThinkFlowLab/OpenDirector) is an agent-driven\nplatform for creators, started by vLLM-Omni committers to make vLLM-Omni easier\nto use in creative workflows.\n\nIts Day-0 H3-Image integration currently uses **MiniMax’s hosted image API**.\nCreators can generate and edit images through the canvas or agent, then use the\noutputs as references for the next edit. We plan to expand support for\n**locally deployed H3-Image workflows powered by vLLM-Omni**.\n\n## Acknowledgements\n\nWe thank MiniMax for releasing H3-Image and its model weights; the NVIDIA team and the vLLM community for their work on Vera Rubin support; and the vLLM-Omni and FlashInfer contributors for the serving and kernel infrastructure used in this work.\n\nWe also thank the OpenDirector contributors for their work on H3-Image integration in creative workflows.", "url": "https://wpnews.pro/news/h3-image-day-0-support-4k-in-0-87s-with-vera-rubin", "canonical_source": "https://vllm-project.github.io/2026/11/12/minimax-h3-image-rubin.html", "published_at": "2026-11-12 00:00:00+00:00", "updated_at": "2026-11-12 08:21:15.591749+00:00", "lang": "en", "topics": ["generative-ai", "ai-infrastructure", "ai-chips", "ai-tools"], "entities": ["MiniMax", "H3-Image", "NVIDIA Vera Rubin", "vLLM-Omni", "RTX 5090", "H200", "GB300", "Moore Threads"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/h3-image-day-0-support-4k-in-0-87s-with-vera-rubin", "markdown": "https://wpnews.pro/news/h3-image-day-0-support-4k-in-0-87s-with-vera-rubin.md", "text": "https://wpnews.pro/news/h3-image-day-0-support-4k-in-0-87s-with-vera-rubin.txt", "jsonld": "https://wpnews.pro/news/h3-image-day-0-support-4k-in-0-87s-with-vera-rubin.jsonld"}}