MiniMax H3: Open Video With Sound in One Pass

MiniMax open-sourced H3 on 3 August. The specifications that will get quoted are 2K resolution and 24fps, and those are not the interesting part.

The interesting part is that the sound comes out of the same forward pass as the picture. Voice, sound effects and music are generated jointly with the video rather than dubbed onto it afterwards. Every open video model before this treated audio as a separate stage, and anyone who has assembled that pipeline knows where the time goes — not in generating the audio, but in getting it to land on the right frame.

The second thing worth noting is that it fits. The full footprint is around 123.6GB; quantised variants bring that down to roughly 42.5GB, a 66 percent reduction, and ComfyUI reports the smallest variants running on an RTX 3060. A 2K video model that runs on a consumer card is a different category of thing from one that needs a rented H100.

Executive summary

• MiniMax H3, open-weighted 3 August 2026, ~33B parameters, on Hugging Face as MiniMaxAI/MiniMax-H3.
• Omni-modal input — text, image, video and audio in one context. Output: up to 2K, 24fps, ~5–15 second clips.
• Video and stereo audio are generated jointly in a single forward pass. This is the release’s actual contribution.
• Memory footprint 123.6GB → 42.5GB via quantisation; smallest variants reported running on an RTX 3060. NVFP4, BF16, FP8, INT8 and INT4 shipped.
• Day-zero ComfyUI support — merged PR adding four nodes and six official workflow templates.
• Hard limit: ~15 second clips. This is a shot generator. Longer output means stitching, with no continuity guarantee.
• Very little community evidence yet. Download counts were in the low thousands shortly after release.

Why joint generation is the whole story

Consider what it takes to put a sound on a video with a two-stage pipeline.

You generate the clip. You describe the audio you want and generate it separately. Then you align them — and alignment is where the work is, because the audio model had no idea when the door closed, when the foot hit the ground, or when the mouth opened. You nudge the waveform until the impact sound sits on the impact frame. You do this per event. If you regenerate the video, you do all of it again.

The failure is structural, not a quality problem in either model. The two stages cannot agree on timing because neither one can see the other’s output while producing its own.

Joint generation removes the coordination problem by removing the second stage. The model produces one artefact in which the sound and the picture were decided together, so a door closing produces its sound at the frame the door closes — not because the alignment was corrected, but because there was never a moment when the two were separate things to align.

This is the same category of improvement as end-to-end speech recognition replacing separate acoustic and language models, or single-stage object detection replacing region proposal followed by classification. In each case the win did not come from either component getting better. It came from deleting the seam between them.

The memory number deserves attention too

A 66 percent footprint reduction — 123.6GB to 42.5GB — is the difference between a model you read about and a model you run.

The five quantisation formats shipped at launch (NVFP4, BF16, FP8, INT8, INT4) matter more than the headline reduction, because they make the trade-off a dial rather than a decision. A team can start at BF16 to establish a quality baseline, then walk down the precision ladder until output degrades visibly, and stop one step above that. Nobody has to guess.

The RTX 3060 claim is the one to treat carefully. It comes from ComfyUI’s release notes and refers to the smallest variants, which means the most aggressive quantisation. “Runs” and “produces output you would ship” are different thresholds, and there is not yet enough community reporting to know where the second one sits. What is safe to say is that the accessible hardware floor for open video generation dropped sharply this week.

Day-zero ComfyUI support is a distribution strategy

H3 landed in ComfyUI the same day it was released, through a merged pull request adding four nodes and six official workflow templates — text-to-video, image-to-video with optional frame control, and reference-driven generation combining images, video and audio.

This is worth naming as a deliberate move rather than a convenience. ComfyUI is where open generative video actually gets used. A model that arrives with working node graphs is one an experimenter can evaluate in an evening; a model that arrives as weights and a README is one they get to next month, or never. The gap between those two outcomes is most of the difference between a model that builds an ecosystem and one that gets a star and is forgotten.

It also fits a pattern visible across this week’s releases: the labs shipping open weights are increasingly shipping the integration alongside them rather than waiting for the community to build it. That is a competitive response to the convenience of closed APIs, and it is working.

The limitations, stated plainly

Fifteen seconds is a hard ceiling. H3 generates shots, not scenes. Anything longer requires generating multiple clips and stitching them, and nothing in the model guarantees that a character, lighting setup or camera position survives the boundary between two independent generations. For short-form social content that constraint is invisible. For anything narrative it is the dominant constraint.

The evidence base is nearly empty. Download counts were in the low thousands shortly after release. Nobody yet knows how prompt-sensitive it is, how the audio holds up across languages and voice types, what its characteristic failure modes look like, or how far the aggressive quantisations degrade output in practice. Launch demos are best cases selected by the people who built the model. Wait for the community’s worst cases before planning around it.

Open weights is not open source. The weights are downloadable; the training data and training code are not part of the release. For most practical purposes — run it locally, quantise it, build a product on it, no per-generation bill — the distinction does not change what you can do. It does mean you cannot audit what went into it.

Who this is for

The clearest fit is short-form video with sound where the content cannot leave your infrastructure. Unreleased product footage, client material under NDA, anything with a regulatory constraint on third-party processing — these are cases where an API is not a cheaper option but a disallowed one, and until now the open alternatives could not produce synchronised audio at all.

The second fit is anyone building video tooling. The ComfyUI nodes exist, which means the integration surface is already defined and there is something concrete to build against today.

If you need clips longer than fifteen seconds, broadcast-grade output, or a track record of production use, this is not the release for you yet.

The verdict

The resolution number is the least interesting thing in this launch. 2K at 24fps is table stakes and will be matched within a month.

What will take longer to match is a model that decides the sound and the picture at the same time, ships in a size a consumer GPU can hold, and arrives with working node graphs on day one. Those three things together move open video generation from a demo category into a usable one — for short clips, with the caveats above, evaluated on your own footage rather than the launch reel.

For a release that most coverage will file under “another video model,” that is a substantially better week’s work than it appears.