ZView Space2026-10-23 09:00:00

MiniMax H3 Render Time: Real Numbers from a ComfyUI Worker

Data window: render times logged by the ZView Space queue up to 19 October 2026. Hardware is one ComfyUI worker; numbers are not a general benchmark.

MiniMax H3ComfyUIrender timeAI videobenchmark
MiniMax H3 Render Time: Real Numbers from a ComfyUI Worker

Data window: render times logged by the ZView Space queue up to 19 October 2026. Hardware is one ComfyUI worker; numbers are not a general benchmark.

How long does MiniMax H3 take to render a clip? The launch coverage talks about 2K output and 15-second clips, but almost no one publishes how many minutes a real job takes. Our queue records the wall-clock render time of every H3 job per profile, so here are the actual numbers from one worker, plus how to read them.

What H3 is, in one paragraph

MiniMax H3 is an omni-modal video model released on 3 August 2026. According to the ComfyUI launch post, it supports text-to-video, image-to-video, first-and-last-frame control and reference-to-video, generates stereo audio in the same pass as the video, and produces up to 15 seconds per clip at up to 2K. The same post says it needs ComfyUI 0.30.0 or later and that the full-precision weights take 123.6 GB while the smallest variant takes 42.5 GB. Those are the vendor-side figures. What follows is what we measured.

How we measured

  • Source: the render-time samples our queue stores for every finished H3 job, per workflow profile.
  • Hardware: one ComfyUI worker. We do not break results down by GPU model here.
  • What a "sample" is: wall-clock seconds from the moment the worker picks up the job until the finished file is ready. That includes the render itself and the post-processing we run on every job (the H.264 delivery encode, plus any scene stitching for chained profiles). Queue waiting time is not included.
  • Retention: the queue keeps only the most recent 100 samples per profile, so these are recent runs, not a full history. Profiles with fewer than five samples are left out of the table.

Measured render time per profile

| Profile | What it renders | Samples | Median | Range | | --- | --- | ---: | ---: | ---: | | `high_5s` | one 5-second clip at 1.0 MP | 100 | 197 s (3 min 17 s) | 194 – 301 s | | `standard_15s` | one 15-second clip at 0.5 MP | 14 | 315 s (5 min 15 s) | 310 – 644 s | | `high_10s` | one 10-second clip at 1.0 MP | 15 | 463 s (7 min 43 s) | 462 – 550 s | | `ig_vlog_20s` | two 10-second shots chained | 100 | 957 s (about 16 min) | 207 – 1,532 s | | `ig_vlog_30s` | three 10-second shots chained | 8 | 1,610 s (about 27 min) | 1,608 – 1,622 s | | `ig_vlog_40s` | four 10-second shots chained | 7 | 1,972 s (about 33 min) | 1,965 – 2,137 s |

The 20-second profile has a much wider range than the others (207 to 1,532 seconds). We did not isolate the cause, so use its median rather than its minimum when planning.

What the numbers tell you

1. Resolution matters more than it looks. In our profiles, a 15-second clip at 0.5 MP finished in a median 315 seconds, while a 10-second clip at 1.0 MP took 463 seconds. Fewer seconds but more pixels cost more time. If turnaround matters, lowering the render size looks like the biggest lever, and you can upscale afterwards.

2. Cost scales with duration, but not linearly. The 5-second clip took 197 seconds and the 10-second clip took 463 seconds at the same 1.0 MP size, about 2.35 times longer for twice the duration. Two 5-second clips (about 394 seconds together) cost less than one 10-second clip (463 seconds), so planning a video as several short shots can be cheaper than asking for one long one.

3. Chained videos cost roughly one render per shot. The two-, three- and four-shot profiles work out to about 479, 537 and 493 seconds per 10-second shot, close to the 463 seconds of a single 10-second render. Chaining adds very little overhead of its own; the time is the sum of the shots.

4. Plan in tens of minutes, not seconds. Even the shortest profile took over three minutes end to end. A one-minute video made from several shots will occupy a single worker for the better part of an hour, which is why we run H3 through a queue and show an estimated wait instead of a progress bar.

Caveats

  • These are numbers for our worker, workflow and quantisation. A different GPU, a different VRAM budget or a different precision will move every figure.
  • Medians of 7 to 15 samples (the 10-second, 15-second, 30-second and 40-second rows) are rough. We show the range so you can see the spread.
  • The ComfyUI team says H3 can run locally on a GPU such as an RTX 3060 using dynamic VRAM offloading, but its post gives no timing for that setup, and we have not tested it. Our numbers say nothing about consumer cards.
  • H3 weights are distributed under the MiniMax H3 Community License. Press coverage and MiniMax's local deployment guide describe regional conditions, including an application requirement for some countries. Read the licence text yourself before commercial use.

How we use this

We budget render time per shot, use the 5-second and 10-second profiles for anything that needs to come back quickly, and reserve the chained profiles for work that can wait. If you plan a video workflow around H3, the practical question is not "how good is a single clip" but "how many shots can my worker finish per hour", and the table above gives you a starting estimate.

Method note: values were read directly from the queue's per-profile render-time lists on 19 October 2026; medians were computed over the stored samples. Profiles with fewer than five samples are not shown.