The Short Answer: Which MiniMax H3 Workflow To Run First
Run the text-to-video template first. It is the only MiniMax H3 workflow that needs nothing except a prompt, so it proves your model paths, your memory budget, and the audio chain in a single pass, before you lose an evening to a reference render that was never going to fit.
MiniMax H3 ships three official templates: text-to-video, image-to-video, and reference-to-video. They share a text encoder and two VAEs, but they are not interchangeable. Two things decide which MiniMax H3 workflow you should actually be running: the source material you already have, and the VRAM sitting in the machine.
Most setup guides answer the first question and ignore the second. That is why so many first attempts end at the sampler with an out-of-memory error and forty-odd gigabytes of weights already on disk. The order below is deliberate: choose the mode, size the hardware, then download, then render small.
Three Modes, One Model, Two Checkpoints
Every MiniMax H3 workflow generates picture and native stereo audio together in one forward pass, rather than scoring a silent clip afterwards. What changes across the three MiniMax H3 ComfyUI templates is how much control you get, and how much memory that control costs.
Text-to-video
T2V builds the clip from a written brief alone. Scene, action, camera move, dialogue, sound effects, and music all belong in one prompt block, and twenty steps is the working default. This is the cheapest mode to run and the right place to start.
Image-to-video
I2V animates a still. First-frame and last-frame inputs are both optional, and when you supply both, the model generates the motion between them. Pick this mode when composition, product detail, or brand elements are already locked and only the movement is missing.
Reference-to-video
R2V is the control-heavy option: up to nine reference images, three reference videos, and three standalone audio clips in one generation. References are read in the order they are connected, and assigning each one an explicit job, whether that is identity, style, motion, camera, or voice, works far better than leaving the model to infer it.
The trap sits in the checkpoint. T2V and I2V run on the FL2VA diffusion model; the reference MiniMax H3 workflow needs a separate Ref2VA file of similar size. Loading the wrong one is the most common reason a ComfyUI MiniMax H3 template errors out while the template beside it runs perfectly.
Write The Brief Before You Touch The Graph
The prompt is where most local runs quietly go wrong, because a MiniMax H3 workflow expects a production brief rather than a caption. The pattern that holds up is to state the whole scene first, meaning where you are, who is in it, and what is happening, and only then break it into timed shots.
Audio belongs in the same block. Dialogue, effects, and music are generated with the picture, so leaving sound out of the prompt does not hand you a clean silent plate. It hands you whatever the model decides the scene should sound like. Say what you want to hear in the same breath as what you want to see.
Two smaller details are worth knowing. Spelled-out words and brand elements render more cleanly here than on most video models, so a sign or a label is a reasonable request rather than a gamble. And in a reference MiniMax H3 workflow, every asset should be addressed by tag in the exact order it was connected, with a stated role: this image is the character, that clip is the camera move, that audio is the voice. Vague reference prompts are the main reason R2V output drifts away from the brief.
Size The Hardware Before You Download Anything
Text-to-video and image-to-video together come to roughly 42 GB of weights. Reference-to-video adds about 21 GB more. Pulling all of that before checking whether the machine can hold it is the most expensive mistake in a local minimax h3 comfyui build.
| VRAM | Realistic status | What that means in practice |
|---|---|---|
| 8 GB | Outside the official templates | The only reported successes use a heavily offloaded four-bit path in other tooling, not the shipped graph |
| 12 GB | Possible, slow | A 3060-class card has completed a 480p, twenty-step run, but only with 32 GB of system memory and a fast drive beneath it |
| 16 GB | Workable | A 16 GB laptop card has been measured at roughly three minutes for a five-second clip near 960 by 540 with faster attention enabled |
| 24 GB and up | Comfortable | Room for the pruned checkpoint and a larger canvas without constant swapping |
Two numbers matter nearly as much as VRAM. System memory below 32 GB turns offloading into host-memory exhaustion, and a slow disk turns every weight swap into dead time. Nobody publishes a hard minimum for a MiniMax H3 workflow, because the honest answer depends on your offload configuration as much as on your card.
Faster attention kernels are the usual first optimisation and can roughly double throughput, but install them only after a plain MiniMax H3 workflow has completed once. A mismatched wheel produces import errors that look exactly like a broken model install, and untangling both at the same time costs far more than the minutes the kernel was meant to save.
What The Install Actually Needs On Disk
MiniMax H3 ComfyUI support arrived natively in version 0.30.0, so anything older will not show the templates at all. Four files cover text-to-video and image-to-video, and each has exactly one correct destination. Opening a ComfyUI MiniMax H3 template prompts for those downloads directly, which is the safer route, because the filenames have to match what the loaders expect.
| File | Folder | Approximate size |
|---|---|---|
| minimax_h3_fl2va_pruned_int8_convrot.safetensors | diffusion_models | 20 GB |
| qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors | text_encoders | 15 GB |
| minimax_h3_video_vae_fp16.safetensors | vae | 5 GB |
| minimax_h3_audio_vae_fp32.safetensors | vae | 0.6 GB |
The reference MiniMax H3 workflow adds minimax_h3_ref2va_pruned_int8_convrot.safetensors to the same diffusion folder. An optional turbo LoRA drops the base templates from twenty steps to eight, and the reference turbo LoRA runs at four, both trading a little motion and audio quality for speed.
If a loader dropdown comes up empty, the file landed in the wrong folder or the name changed during download. Restart after moving anything, because the model list is read at startup.
First-Run Settings For A MiniMax H3 Workflow That Finishes
Do not start at full quality. A useful first pass through any MiniMax H3 workflow looks deliberately small:
- Resolution around 0.4 megapixels, which lands near 864 by 480 at 16:9
- Duration of five seconds
- Twenty steps, with the res_multistep sampler and the simple scheduler
- Batch size of one
Those numbers are chosen to fail fast, not to look good. If that run completes with sound, the MiniMax H3 ComfyUI install is correct, and every problem after it is a settings or memory question rather than a broken chain.
For full local quality, the target canvas is a 768-pixel short edge, roughly 1344 by 768 at 16:9, which works out near 0.98 megapixels. Setting the resolution selector to a tidy 1.0 megapixel is a known trap: it computes 1376 by 768 and overshoots the model's pixel-area cap. Below about fifteen steps, quality falls off visibly, while twenty-five steps buys a little detail for a lot of time.
Four Constraints That Quietly Break A First Render
Duration snaps to a frame grid
Clip length is not continuous. Frames land on a seventeen-per-block grid at 24 fps, so a five-second request resolves to 124 frames, about 5.17 seconds. Nothing is broken when the output runs slightly long, but it will not drop cleanly into a timeline cut planned to the frame.
The short edge is capped
Every MiniMax H3 workflow rounds dimensions to a multiple of 32 and works from a 768-pixel short edge. Asking for more does not produce a bigger native frame; it produces an error or a wasted queue slot. Very small canvases fail too, so treat roughly 384p as the floor for a smoke test.
Audio has its own decode path
A silent file is almost never a model failure. Both VAEs must load, and the audio latents need their own decode node feeding the same save node as the frames. Leave that branch disconnected and the render still succeeds, just mute.
Reference size multiplies cost
In reference-to-video, one setting decides whether references are scaled to the generation resolution or held at up to a 2048-pixel short edge. The larger option buys identity fidelity and costs a great deal of speed. On a 16 GB card that single choice often separates a run that finishes from one that does not.
Verify The Render Before You Trust The Settings
A MiniMax H3 workflow can complete and still be wrong. Check four things before scaling anything up.
- The file carries an audio track, not just frames
- The frame count matches the grid, so a slight overshoot is expected rather than alarming
- The exported dimensions match what the resolution selector computed, not what you typed
- The sound belongs to the scene rather than arriving as generic ambience
Only when all four hold should you raise resolution or duration, and only one variable at a time. Changing canvas size and clip length together is how a working MiniMax H3 workflow turns into an unexplained out-of-memory error with no obvious cause.
Quantized Builds Are A Fit Decision, Not An Upgrade
Community conversions cover GGUF from roughly Q3 to Q5, mixed four-bit and eight-bit formats, and NVFP4 for the newest NVIDIA architecture. The shape of the advice is consistent: 16 GB cards look at Q3 or Q4 class weights with a matching quantized text encoder, while 24 GB cards can hold Q5 or the pruned eight-bit path that sits closest to full quality.
Two cautions are worth repeating. Quantized ComfyUI MiniMax H3 builds are community conversions rather than official releases, so loader compatibility is something you verify rather than assume. And a smaller file is a compromise, not a free win. If your MiniMax H3 workflow already runs, dropping a quant level to buy speed usually costs more in detail and audio stability than the minutes it hands back.
Where The Local Path Stops
Two limits deserve attention before a weekend disappears into this. The open weights cover the base model, while the stages that carry output to full 2K remain hosted, so a local render is not the same product as the flagship demo. And commercial use of locally generated output runs through a separate MiniMax licence rather than arriving with the weights.
There is also a plainer limit. If you need one clip this afternoon, a 42 GB download, a quantization decision, and an attention-kernel install are not the path to it. A local MiniMax H3 workflow earns its setup cost when you will run the model repeatedly, want reference control that hosted tiers do not expose, or need to keep material on your own machine. The ComfyUI MiniMax API nodes and browser tools exist precisely because that is not everyone's situation.
Start With The Smallest Test That Tells You Something
Whichever route you take, the first useful result is a five-second clip with sound that proves the brief was understood. Build that before you optimise anything, and let the result decide whether the full local stack is worth the disk.
If hardware is the blocker, or you simply want to test prompt structure before committing to an install, you can run the same text-to-video brief through a minimax h3 workflow style hosted pass in the browser. Write one scene description with camera and audio included, generate, and judge the output against the job it has to do. That answers the question a spec sheet cannot: whether this model suits your work at all.
