MiniMax H3-Image Specs: 33.1B DiT, 6-Step Sampling

The official model card is the most complete spec source for H3-Image: architecture numbers, the size table, sampling rules and API behavior are all in there. Read through it and one judgment emerges — this is a model built with extreme trade-offs for speed: six sampling steps, no guidance, locked parameters, in exchange for 4K generation speed; the price is that users have almost no knobs to turn.

Architecture: H3-Base without the audio branch

H3-Image's DiT base is H3-Base — the base model of MiniMax's July video model H3 — with the audio branch removed, specialized for still images. The 33.1B figure is the dense diffusion transformer's size: 50 layers, hidden 5,376, 56 attention heads, FFN 14,336, 3D multimodal RoPE. Note that this counts the DiT only — the text encoder is separate and not included in 33.1B. Weights are BF16, with the embedding, timestep and output layers in FP32.

The text encoder is H3's full Qwen3-VL encoder, unchanged, with the DiT reading the hidden states of its 50th layer. It is not in the H3-Image repo: for local deployment it must be downloaded separately from the MiniMax-H3 repo, 66.7 GB. The image VAE is a CNN encoder plus a 24-layer 2D ViT decoder, 16× spatial downsampling, 24 latent channels; the DiT patchifies the latent with a 2×2 patch, so each token covers 32×32 pixels — one reason 4K token counts don't scale linearly with area, and why the price list charges only about 3.2× more for 4K than 1K.

Sampling: 6 steps, no guidance, locked parameters

H3-Image is distilled to 6 sampling steps (6 NFEs) with no classifier-free guidance (CFG). This isn't a default — it's a hard lock: num_inference_steps can only be omitted or 6, guidance_scale can only be omitted or 1, and other values return HTTP 400; negative prompts are not supported. In other words, the traditional diffusion workflow of tuning step counts, guidance strength and negative prompts simply doesn't exist on H3-Image.

The logic of the trade-off is clear: six unguided steps sit in a different compute class from a thirty-step guided sampler — OrcaRouter notes this is exactly why "4K in 10 seconds" is architecturally plausible. But "plausible" is not "proven": the model card states no generation time anywhere, and the only speed evidence is the comparison chart in the official blog, whose 4K medians are 16.0 seconds (Standard) and 10.3 seconds (Highspeed). See our 10-second claim fact-check.

Output sizes: native about 16MP at all aspect ratios

The working range is about 4–20MP, best around 16MP; the API accepts custom sizes of 655,360–20,000,000 pixels, aspect ratios 1:3–3:1, and "never scales or rounds" — you get exactly the size you ask for. Presets are 1K/2K/4K, with 4K the default. Each request returns 1–10 images, in JPEG (default), PNG or WebP. The key point: native 16MP means 4K is generated directly at 4K resolution, not drawn small and upscaled.

Reference editing: up to 16 images, positional references

Editing supports 1–16 reference images, addressed in the prompt as "Picture 1" through "Picture 16" in upload order. Reference formats: JPG/PNG/WebP/HEIC/HEIF, 128–8,192 pixels per side. Two boundaries to note: vLLM-Omni's day-one recipe only exercises 9 images per request — 16 is the model limit, 9 is what that framework's recipe measured; and the official chart's editing timings stop at 3 reference images, so there is no data for a full 16-reference load.

Unsupported items are stated explicitly in the API guide: masked edits, transparent backgrounds, preview images. Prompt rewriting is always on for edits and can't be disabled — the API rewrites the prompt before generating; local deployments can use the PE model for the same expansion.

Prompts: detailed English descriptions of the whole image

The model card is explicit: the model is designed for "detailed English prompts describing the whole image." The API expands short prompts in any language into detailed English via H3-Image-Context-IR before generating; local deployments can use the optional PE model (MiniMax-H3-Image-PE, 17.9 GB NVFP4, fine-tuned from Qwen3.8-27B) for the same expansion, though MiniMax doesn't guarantee it matches the API exactly. PE is not a small variant of H3-Image, just a prompt expander — the model runs without it. Prompts are capped at 32,000 characters, with only about the first 4,096 tokens taking effect.

API behavior: three easy traps

First, neither endpoint is idempotent: if the client times out or disconnects, the server still finishes generation and charges, and the guide advises turning off automatic retries — one retry is one extra charge. Second, the server waits up to 600 seconds. Third, prompt rewriting is on by default (can be off for text-to-image, always on for edits). Response format: PNG in data[0].b64_json. Endpoints: text-to-image /v1/images/generations (JSON), editing /v1/images/edits (multipart form).

Local deployment size: 68.65 GB for the model itself (transformer 66.28 GB + VAE 2.34 GB + per-step output heads 12 MB + tokenizer 23 MB), plus a 66.7 GB text encoder, about 135 GB total; PE is an optional 17.9 GB. MiniMax publishes no VRAM guidance — file size is not VRAM, so don't estimate graphics cards from 135 GB. For deployment paths, see our local deployment article.