MiniMax H3 Runs on Two 16 GB Consumer Cards. Your System RAM Is the Part That Breaks.

A 33B video-plus-audio model now fits on a pair of RTX 5070 Tis. The interesting numbers in the release are not on the GPUs at all.

Two numbers sit a few paragraphs apart in the same model card, and the gap between them is the whole story.

The first: the transformer, quantized to mixed NVFP4 and split across two cards, occupies about 6.7 GB per GPU. That is comfortable. You could run it on a 12 GB card if the kernels allowed it.

The second: during generation, the host working set peaks somewhere between 40 and 58 GB. Not video memory. Ordinary system RAM, the kind in the DIMM slots, the kind most people building a two-GPU box treat as an afterthought. The card states that a 32 GB machine with 8 GB of swap was tested and gets OOM-killed mid-generation with exit code -9.

So the release that puts a datacenter-class video model on consumer graphics cards is, read carefully, not really about graphics cards.

What actually changed

pottokao/minimax-h3-2x16gb went up on September 8. It serves MiniMax H3, the 33B omni-modal transformer that generates video with synchronized stereo audio, on two 16 GB Blackwell cards through a patched vLLM-Omni engine, tensor-parallel across the pair.

For scale, MiniMax's own deployment section in the H3 model card gives you this as the reference command:

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, and the implied class of GPU is not an RTX 5070 Ti. The published BF16 checkpoint is large enough that a separate Mac port catalogs it at roughly 144 GB on disk. Getting from there to a pair of gaming cards is a real piece of work, and this release ships it as a finished artifact rather than a recipe: patched engine, quantized weights and the generation pipeline all bundled together, weights baked into the repo at about 51 GB.

That matters because the gap between "someone proved this is possible" and "you can run this tonight" is usually where local AI goes to die. This one closes it.

The GPU side is the boring part

The quantization is mixed and specific. Attention projections and the first MLP layer run W4A4 NVFP4, the second MLP layer runs W4A16, group size 16. The text encoder is a separate W4A16-NVFP4 quantization of Qwen3-VL-32B at about 15 GB, also tensor-parallel across both cards. Kernels are sm120, so the card says Blackwell only. It does not name any excluded card, but sm120 is the Blackwell target and a 4090 is Ada at sm89, so read that as a hard no for the 40 series.

Two tiers ship side by side. turbo4p does four denoising steps at roughly 73 seconds per five-second segment. turbo8p does eight steps for about double the denoise time and the same memory footprint. Output is 1344×768 with audio.

One design choice deserves applause: the step count is pinned by the distilled checkpoint, and passing any other value is rejected outright. Most inference stacks let you set steps to whatever you like on a distilled model and hand you back a mess. This one refuses. That is the correct behavior and almost nobody does it.

None of that will be what stops you.

The memory table is the real document

Read this part of the card before you read anything else:

Host RAM	Swap needed	Behavior
48 GB	near zero	Working set stays resident
32 GB	16 to 26 GB required	Works, generation phase spills to swap
32 GB with 8 GB swap		Fails, OOMs mid-generation, verified
under 32 GB		Not supported

Idle footprint is 13.6 GB, which looks fine and is a trap. The peak comes from the text encoder reload, the transformer and the VAE decode stacking up during generation. If you provision RAM by watching the idle number, you will build a machine that boots the model cleanly and dies four minutes into your first render.

The card gives you the fix as copy-paste, which tells you the author hit this himself:

sudo fallocate -l 24G /swapfile && sudo chmod 600 /swapfile && \
  sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

On a 32 GB host you also want MINIMAX_H3_DLO_PIN_CPU=0, which makes host copies pageable so they can actually swap, plus MINIMAX_H3_TE_FREE_RELOAD=1 and MINIMAX_H3_VAE_LAZY=1 to shave the peak. Seven environment flags are documented, each with a stated purpose. Six of them trade speed for headroom.

I want to be blunt about why this section matters more than the benchmark. Anyone shopping for a local video setup right now is thinking in VRAM, because that is the number every model card leads with and every forum thread argues about. This release inverts that without making a fuss about it, and if you buy two 16 GB cards for a 32 GB box, the component you were actually missing turns out to be a swap file.

The flag whose failure mode is silence

MINIMAX_H3_TE_EMBED_DEQUANT defaults to 1. It dequantizes the FP8 embed_tokens tensor at scale 0.002145. The card calls it "Required for prompt conditioning," and describes the consequence of turning it off in seven words: "every prompt collapses to the same output."

Sit with that failure shape. The pipeline does not crash. It does not warn. It renders a video, at the right resolution, with audio, in the expected time. It has simply stopped reading your prompt.

That is the worst possible bug in a creative tool, because there is no error to search for. You would spend a day rewriting prompts, blaming the quantization, blaming the distillation, concluding the model is bad at instruction following. The author found it and wrote it down as a default. Whether you keep that default is not the point. The point is that this class of bug exists in every hand-built inference stack, and most of them do not tell you.

The component nobody is measuring

Here is the part of this release that will get the least attention and deserves the most.

The text encoder is not a compressed version of MiniMax's text encoder. It is a different model. The card says so plainly: "Text encoder is an abliterated (uncensored) NVFP4 quantization of Qwen3-VL-32B."

Two facts have to meet for that to land.

First, from MiniMax's own architecture section: "The H3-Encoder uses the full pretrained weights of Qwen3-VL-32B and provides the hidden states from its 50th layer to the H3-Omni-Transformer." Your prompt does not reach the video model as text. It reaches it as a specific tensor read out of layer 50 of a specific vision-language model.

Second, from the standard reference on abliteration: the permanent form of the technique is weight orthogonalization, which modifies the matrices that write to the residual stream so they cannot write to a chosen direction at all. In the worked implementation that means the embedding matrix, every block's attention output projection, and every block's MLP down projection. Every layer. Including all fifty that sit between your prompt and the tensor H3 consumes.

So the hidden states arriving at the transformer are, by construction, not the hidden states MiniMax's pipeline produces. That is not a compression artifact you can bound with an SNR figure. It is a different function.

Does it degrade video? Nobody has published a number, including this card. What we do know is that the same abliteration article measured its own result and found "a performance drop in the ablated version across all benchmarks," severe enough that the author ran a DPO pass afterward specifically to heal it. That was a text model judged on text benchmarks. Whether a similar drop shows up in the semantic richness of a prompt embedding, and whether a video transformer is more or less sensitive to it than a language head, is an open question with no data on either side.

I am not saying the build is broken. I ran nothing that suggests it is, and the author is not hiding the substitution. I am saying that when the release is discussed, it will be discussed as a quantization achievement, and one of its components is a replacement rather than a compression. Those deserve different amounts of suspicion.

Put this into practice

The smallest real thing you can do in the next ten minutes is check whether your machine qualifies, which is a two-line answer, not a download.

1. Check the GPU generation first. You need two Blackwell cards, sm120, 16 GB each. 5070 Ti, 5080 and 5060 Ti 16 GB are named. nvidia-smi --query-gpu=name,memory.total --format=csv settles it. If you are on Ada or older, stop here; the NVFP4 kernels will not build.
2. Check host RAM and swap. free -h. If total RAM is under 32 GB, this build is not for you. If it is exactly 32 GB, create the 24 GB swap file from the snippet above before you download anything, because you will otherwise spend an hour on a 51 GB pull and then fail on your first render.
3. Clear 60 GB of disk. The repo carries its weights, and the Docker build lands around 62 GB on top.
4. Clone with LFS enabled. git lfs install first, then git clone https://huggingface.co/pottokao/minimax-h3-2x16gb. Without the first command you get a directory of pointer files and a confusing error later.
5. Take the no-Docker path if you already have a Python setup. The pre-patched engine ships in the repo, so it is pip install -r patches/omni_freeze.txt then pip install -e engine/vllm-omni. No upstream clone, no patch step.
6. Start with four steps. bash serve_turbo4p.sh. Wait for "Application startup complete," then send one request and confirm you get a file back before you touch the long-video pipeline. --ipc=host is required if you went the Docker route, because the two tensor-parallel workers need shared memory.
7. Test that prompt conditioning works. Generate two clips with very different prompts and the same seed. If they look the same, your MINIMAX_H3_TE_EMBED_DEQUANT is off. This takes three minutes and saves a day.

Only then go near the long-video pipeline. It runs a montage pass to establish mutually consistent keyframes, then generates between each adjacent pair with both endpoints pinned, then stitches. Edit pipeline/prompts.json and run STEPS=4 bash pipeline/story_long.sh. The published example is seven segments: a 107-second montage plus seven 73-second segments, about 619 seconds of compute for a 36-second clip.

Honest limitations

Audio does not survive the stitch. Each segment generates its own audio track. Video is continuous because neighbouring segments share a keyframe; audio is not, because nothing conditions one segment's soundtrack on the last one. You get an audible discontinuity at every seam. The card is upfront about this and offers two workarounds, a separately rendered track muxed over the top or a roughly 0.1 second crossfade at each join, and lists joint audio conditioning as roadmap rather than shipped. If your work is dialogue or music, this is the wall.

You are running one third of the system MiniMax built. The complete H3 pipeline is three modules. H3-Context-IR turns your messy input into a structured intermediate representation, and MiniMax's own card says it is "critical to the quality of the final output." It depends on multiple hosted models and services, so it is not in the open release at all. H3-Regenerate-2K, which produces the 2K output, is worded differently: "not yet open-sourced. We will release it once it is ready." One is a permanent hosted dependency, the other is a promise. Local H3 today is H3-Base alone, at 768p, driven by whatever prompt structure you write yourself. Read MiniMax's prompt writing guides before concluding the model is worse than the demos.

Thirty-six seconds is outside the model's spec. H3's published output duration is 4 to 15 seconds. Stitched long-form is a pipeline trick built on top of first-last conditioning, not a supported mode, and the fidelity of a stitch is not something anyone has benchmarked.

Four-bit has a ceiling. The card names it: 4/8-step distilled plus W4A4 plus 768p caps out, and higher fidelity needs more VRAM than 2×16 GB provides. Nobody has published a quality comparison against the BF16 reference on this build.

Blackwell or nothing. No AMD path, no Apple Silicon path, no Ada fallback. If you own a 4090, the Mac and the multi-card Ampere routes both exist elsewhere but not here.

Check the base license against where you live. H3 ships under the MiniMax H3 Community License, and MiniMax hosts a separate application form specifically for the USA, EU, UK and South Korea. Read it before you put output in a client deliverable.

What I would actually watch

The thing I keep turning over is not whether this build is good. It is that three separate people shipped three incompatible ways to run this one model inside two days, and none of them is the path its publisher documented. That is either the healthiest sign in local generative video or the beginning of a support nightmare, and I think it might be both.

If you run this, the measurement I want to see is the one nobody has taken: the same prompt, the same seed, through the official text encoder and through the abliterated one, on a build where nothing else differs. Not a vibes comparison. Two files and a difference. Someone has the hardware to do that this week, and the result would tell us something real about how much of a video model's obedience lives in its text encoder.

If that someone is you, I would like to see what came out.

---

Sources: pottokao/minimax-h3-2x16gb · MiniMaxAI/MiniMax-H3 · Uncensor any LLM with abliteration

---

Medium metadata

Kicker for social: The transformer needs 6.7 GB per card. The generation phase needs 40 to 58 GB of system RAM. Guess which number the coverage will lead with.