MiniMax H3 for local video

Video generation has been a cloud-only game since the first diffusion model produced a wobbly five-second clip: the weights sat behind APIs, and local runs meant toy checkpoints or melted GPUs for results that looked worse than the cloud version. MiniMax H3 changes that math, but not in the way the headlines suggest.

The short version

Four facts decide whether H3 earns its GPU hours:

• The open release is H3-Base only: 768p video with native stereo audio, servable through SGLang, vLLM, diffusers, and ComfyUI.
• Two of the three system modules stay hosted: H3-Context-IR (input understanding) and H3-Regenerate-2K (2K via in-context regeneration).
• The BF16 weight footprint is roughly 104 GB before activations: a 33B transformer with a cacheable 13B branch, plus a full 32B text encoder. The hardware math is the first gate, before any prompt.
• The shape most production setups end up with is hybrid: generate 768p locally, pay the API only for the final 2K pass.

What H3 does that earlier open models did not

Most open video models that came before H3 stop at 2 to 5 seconds of silent output. H3 produces 4 to 15 seconds at 24 frames per second with synchronized stereo audio at 32 kHz, in one joint pass rather than video with a stitched-in track. It generates from text alone, from a first and last frame image, or from up to 9 reference images, 3 video clips, and 3 audio clips.

The architecture is worth knowing because it decides the hardware bill. Text passes through an encoder built on the full Qwen3-VL-32B weights. Visual inputs go through a temporally causal VAE with 16x spatial and 4x temporal compression. Audio gets its own VAE. Everything packs into a unified multimodal sequence with RoPE handling spatial and temporal position, and a 33B-parameter dense transformer predicts video and audio latents together. About 13B of those parameters live in AdaLN modulation branches that can be precomputed and cached, so an inference-only deployment does not need to load them.

One caveat the launch coverage skips: the model card advertises native sparse attention, but the initial open-source release serves full attention only. The sparse implementation is promised in a future update. For long 15-second prompts with heavy reference material, context cost is higher today than the paper-side claims imply.

The 768p output is competitive with cloud-only video APIs as of mid-2026. The 2K output, produced by a separate regeneration module that feeds the 768p result back through the base model with the original context, pushes past them. That module is where the local story stops, and we get to that below.

The hardware reality

MiniMax recommends SGLang, and the model card's deployment guide shows a four-GPU command with tensor parallelism:

sglang serve \
  --model-path MiniMaxAI/MiniMax-H3 \
  --num-gpus 4 \
  --ulysses-degree 4 \
  --performance-mode speed \
  --host 0.0.0.0 \
  --port 30010 \
  --model-variant fl2va

Four GPUs is the official recipe, and there is no official smaller one. The reason it needs that many is clearer than the marketing makes it: the checkpoint is a bigger system than "33B model" suggests.

Sizing a rig is arithmetic, not magic. The model card publishes parameter counts, and BF16 is 2 bytes per parameter:

• H3-Omni-Transformer: 33B params, 66 GB in BF16. Inference-only can skip the ~13B AdaLN branch because its outputs are precomputable, bringing the transformer load to roughly 40 GB.
• Text encoder: a full Qwen3-VL-32B, 32B params, 64 GB. It ships inside the checkpoint and must be loaded.
• Static weights total roughly 104 GB before activations, latents, and the KV cache for a 15-second clip.

BF16 weight size per H3 component, computed from the model card's parameter counts at 2 bytes per parameter. The AdaLN 26 GB is cacheable, so an inference-only transformer load is closer to 40 GB; the encoder's 64 GB is unavoidable. Source: MiniMax H3 model card, sizes computed, not benchmarked.

These numbers are computed from the model card, not benchmarked, and MiniMax publishes no sub-4-GPU recipe; verify against a live deployment. The community is the path below 100 GB: the Hugging Face model tree already lists 43 quantizations and 49 finetunes, and smaller LoRA adapters keep appearing. Quantization quality for video latents is community-reported, so treat those as volatile.

The two modules that stayed in the cloud

The open weights cover H3-Base, the core generation module. Two other pieces remain behind MiniMax's API.

H3-Context-IR is a hosted preprocessing and orchestration system that interprets free-form multimodal inputs: text, images, audio, reference videos. It parses instructions, links cross-modal references, understands temporal structure, and serializes everything into a structured representation the base model accepts. MiniMax is direct about how much it matters: "We strongly recommend incorporating it into your generation pipeline." The release includes prompting guides so you can build your own preprocessing instead. The open question is whether handwritten prompts will match a hosted system that runs multiple models in sequence.

H3-Regenerate-2K takes the 768p output and regenerates it at 2K by feeding the low-res result and the original context back through the base model. MiniMax frames this as in-context regeneration, not super-resolution: the 2K pass reuses what H3 already knew, so small text and fine details survive instead of being guessed by an upscaler. The model card says the module is "not yet open-sourced. We will release it once it is ready," with no timeline.

The H3 pipeline: open weights cover H3-Base, while Context-IR and Regenerate-2K stay behind the API (source: MiniMax H3 model card).

The practical shape for most builders is the hybrid workflow the model card's Full 2K Workflow documents: serve H3-Base locally through SGLang, call the API for Context-IR when an input needs careful handling, and call Regenerate-2K only when a clip is final. The API cost lands once per finished clip instead of once per iteration, which is where the economics work.

Where this fits in a builder's stack

The split architecture is not a dealbreaker; it is a decision. The base model does the heavy compute, the part that is expensive to rent at scale, and the hosted modules handle the parts that are cheaper per call and harder to replicate.

Two more things before you commit GPU hours. The license is the MiniMax H3 Community License Agreement, not an OSI open-source license: it has usage restrictions, and the application form references the US, EU, UK, and South Korea, which suggests regional constraints. Read it before building a commercial product on H3.

And the landscape is moving. ByteDance's Seedance 2.5 and others ship open weights in the same category, and the gap between what is open and what is closed is closing, the same pattern we saw when Qwen3.8 Max landed. H3 is the most complete release with native audio and the broadest framework support right now, but it also makes the split explicit rather than hiding it, which is exactly what you want when choosing a foundation.

What ships and what stays

H3-Base ships. Context-IR stays. Regenerate-2K stays, for now. The hardware math decides whether the open part is viable for you, the license decides whether it is legal for your product, and the community decides how far below 100 GB it can go.

Running models locally is one part of the equation. Building something people pay for with those models is a different skill, and it is the one most technical content skips. The Handbook covers the end-to-end workflow: deploying on your own infrastructure, handling payments, and operating a thing real users depend on.