MiniMax H3 ref2va with the 4-step Turbo LoRA: 16.1 min to 3.8 min at 1344x768

NaoVerde · 2026-08-18

Standard 20 steps

964 s (16.1 min) / 17,316 MiB

Turbo 4 steps

231 s (3.8 min) / 18,882 MiB

Speedup

4.17x at 1344x768

Per 50-min session

3 clips → 12 clips

The LoRA is for ref2va, not fl2va

I am Nao Verde. I run evaluations on ComfyPods so that ComfyLTS stays usable as video models keep changing. We previously measured MiniMax H3 ref2va at 16 minutes for a 5-second clip at 1344x768. That is fine for a final render, but not for iteration — one bad prompt costs sixteen minutes. lightx2v released a 4-step Turbo LoRA for ref2va, so we reran the benchmark. Turbo LoRAs for MiniMax H3 have existed for a while, but they targeted fl2va, the first-frame-to-video model. fl2va and ref2va are different models, and an fl2va LoRA applied to ref2va does not error out — it degrades quietly. We already had the fl2v file in our loras folder from earlier work, which makes the mistake easy to walk into. The file you want has ref2v in the name, and comfyui.

Five changes, not one

Adding the LoRA and dropping steps from 20 to 4 is not enough. There are five changes. Add LoraLoaderModelOnly at strength 1.0. Add MiniMaxH3SigmaShift with video 12 and audio 3. Steps 20 to 4. Sampler res_multistep to euler. Rewire as UNETLoader to LoRA to SigmaShift to BasicGuider. Without the sigma shift you are not running a 4-step schedule — you are running a 20-step schedule that stops early. The image breaks and it looks like the LoRA is bad. If your Turbo output is a mess, check the sigma shift before you blame the weights. This wiring is documented in a prior benchmark by kamimoto, who measured 4.74x on an RTX 4070 at 384x672 and published the workflows.

4.17x, and the speedup survives higher resolution

Everything except Turbo was held constant: reference image, prompt, seed, resolution, clip length, quantization. Sampler and steps moved because they are part of Turbo. The one thing we deliberately changed from the prior benchmark is resolution — kamimoto measured at 384x672, we ran at 1344x768, which is 3.9 times the pixels. The question was whether the speedup survives. Standard was 964 seconds, Turbo was 231 seconds: 4.17x, against 4.74x at the smaller resolution. Close enough that we would not plan around the difference. For a service the number that matters is throughput per session: three 5-second clips per 50 minutes becomes twelve. Three means waiting for a good one. Twelve means iterating.

Turbo costs VRAM

The name suggests something lighter. It is not. Standard peaked at 17,316 MiB, which is 84.6% of a 20 GB card. Turbo peaked at 18,882 MiB, 92.2%. That is 1,566 MiB more — the LoRA itself, 1.82 GB of weights held in memory. Steps dropped to one fifth; memory went up. Turbo is not saving memory to buy speed, it is spending memory to buy speed. On a shared service that matters. We are at 92% with 1.6 GB of headroom. It does not OOM, but there is not much room to run anything alongside it.

The same seed does not give you the same shot

This surprised us, and it changes how you use Turbo. The sigma shift changes the path from noise to image, so the same seed and the same prompt produce a different scene — not a lower-quality version of the same scene. In our pair, the standard render put bicycles against a shuttered storefront; the Turbo render put a railing and different signage. Turbo did not fail to draw the bicycles; the bicycles were never in that render. This means you cannot use Turbo to find a good seed and then re-run it at 20 steps to get the same shot in higher quality. You will get a different shot.

What changes in the image, and how we use it

Given that caveat, we compared rendering character rather than pixels. Colour is denser and more anime-leaning, with stronger shadows and harder purples. Fine structure drops: the standard render draws bicycle spokes, the characters on signs, the ribbing on a shutter, while Turbo handles those as light and mass — signage becomes glow rather than glyphs. It reads as a different drawing approach more than as damage. Audio level differs too: -19.0 dB standard against -16.7 dB Turbo. We heard no artifacts in this pair, but the prior benchmark reported audio weakness with Turbo, so for clips where singing or dialogue carries the piece, compare against the standard render first. We use Turbo for iterating on prompts, testing motion and framing, and short trial sessions. We keep the standard render for final work, for anything where voice matters, and for fast action. The workflow is not draft-then-render, because the seed does not carry over. It is find the direction in Turbo, then shoot it again at 20 steps.

Why the videos are not shown on this page (2026-09-15)

This article originally embedded the side-by-side video and a zoomed still, both produced by MiniMax H3 running on our own hardware. We have removed them from the English edition. The MiniMax H3 Community License limits the licence to an Applicable Territory defined as "worldwide, excluding the Excluded Territories", and names the Excluded Territories as the European Union, the United Kingdom, the Republic of Korea and the United States of America (§I.3, §I.5). §III.4 then says you may not "use, reproduce, modify, distribute, or display the MiniMax H3 Works or any of their Outputs or results outside the Applicable Territory". This page is our English edition and is read from those places, so displaying the outputs here is not authorised by that licence. The measurements stay — 16.1 minutes to 3.8 minutes is our own timing, not an output of the model. We read the licence text itself before acting: https://huggingface.co/MiniMaxAI/MiniMax-H3/raw/main/LICENSE If you want to see the clips, the Japanese edition still carries them: https://aicu.jp/comfy/blog/2026-08-18-h3-turbo-lora

Related

• Is FLUX really non-commercial? We counted 312 car and train LoRAs
• "This green won't key" was wrong — measure green strength, not hue

MiniMax H3 Turbo LoRA benchmark ComfyPods ComfyLTS