Running MiniMax H3 Locally on 8GB of VRAM

MiniMax H3 is an open-weight video model that generates picture and synchronized stereo audio together. Its first-and-last-frame model accepts zero, one, or two input images, while its reference model can work from images, video, and audio. The official release targets 24 fps, 32 kHz stereo audio, and clips up to 15 seconds.

That is a lot of model for an RTX 4060 with 8GB of VRAM. My test machine also has 96GB of system RAM, which helps enormously, but this is still an awkward hardware match. The card cannot hold the full working set, and the machine only becomes viable after pruning, quantization, and aggressive offloading.

I was not trying to get real-time generation or 4K output. I wanted to answer a narrower question: could this consumer GPU produce video worth keeping, and could the workflow become reliable enough to use as a production backend rather than a one-off experiment?

The answer was yes, with caveats. The current setup generates 480p video with synchronized audio without sending the prompt or source media to a cloud GPU. A later 15-second run took about 15 minutes, so nobody will mistake it for an interactive tool. Still, the output crossed the threshold from “the model technically ran” to “I would actually bring this into a desktop editor app.”

Why I Wanted to Try It

Hosted video APIs are easier to build around. I use services such as OpenRouter and ElevenLabs in part because their interfaces are documented, predictable, and designed for application developers. A local stack built from community checkpoints and runtime-specific optimizations is much messier.

The appeal is control. A hosted provider can change a model, remove a parameter, reject an input, or adjust pricing. Local inference gives me the weights, the settings, and the entire execution path. The cost is that I also inherit the integration work.

H3 is especially interesting because audio is part of the generation rather than a separate post-production step. A clip can contain motion, dialogue, ambience, and stereo placement from the same pass. Its frame-conditioning and reference workflows also fit the way Studio already treats generated media: an asset has visible inputs, reproducible settings, frame locks, and a place on a timeline.

The Test Machine

The GPU is ordinary by current generative-video standards, but the amount of system RAM gives me a slight advantage:

• NVIDIA RTX 4060 with 8GB of VRAM
• 96GB of system RAM
• Windows host with Ubuntu under WSL
• WanGP v12.434
• Python 3.11.14
• PyTorch 2.10 with CUDA 13
• Triton 3.6 and SageAttention 2.2

These results describe the version I tested, not every newer WanGP build. WanGP moves quickly, and its H3 support already includes multiple low-VRAM paths, accelerator profiles, and step-skipping options.

For this setup, system RAM was the binding resource. WanGP kept most of the model in host memory and moved the blocks needed for each stage through the GPU. The CPU mattered much less than having enough RAM to keep the offloaded weights resident.

How the Model Fit

A Pruned, Quantized Transformer

I used the FL2VA Pruned 20B checkpoint in INT8 ConvRot format from the WanGP H3 model collection. FL2VA retains the workflow I wanted to test: text-to-video, image-to-video, first- and last-frame conditioning, continuation, and native audio.

Pruning reduces the transformer, and INT8 storage reduces the weight footprint again. Neither turns H3 into an 8GB model. The setup works because WanGP only needs the active part of the model on the GPU at any given moment.

A Heavily Quantized Text Encoder

H3 also depends on a large Qwen3-VL text encoder. I selected the Q2_K GGUF build rather than Q4_K_M. That saves several gigabytes of system RAM, although the more aggressive quantization may cost some prompt interpretation quality. WanGP’s llama.cpp CUDA kernels were active during my tests, so prompt encoding still used the GPU path.

High-RAM, Low-VRAM Offloading

The setting that made the run possible was WanGP’s High-RAM/Low-VRAM profile. At load time, the runtime pinned roughly 20GB of transformer weights and another 8GB of text-encoder weights in system RAM. The Python process eventually settled near 48GB of resident memory.

WanGP kept a small base on the card and moved recurrent blocks through as they were needed. The setup trades VRAM pressure for system-RAM use, PCIe traffic, and time. The active layer set fits on the 4060; the whole model does not.

SageAttention and Conservative Settings

SageAttention 2 handled the main attention path. I kept WanGP on its lower-VRAM priority, used guidance 1.0, and skipped experimental compilation. The Windows host was already using the High Performance power plan.

Closing GPU-heavy desktop applications created a little extra room, but housekeeping was not the breakthrough. The memory profile was.

Installing and Launching WanGP

WanGP lives in the Ubuntu filesystem at ~/Wan2GP, inside its own uv-managed Python environment. Keeping the repository and model files inside WSL avoids running the active workflow through a Windows-mounted or cloud-synchronized directory.

Launching it is intentionally boring:

cd ~/Wan2GP
bash scripts/run.sh

The script activates env_uv, starts the Gradio server on port 7860, and exposes the interface at localhost. In the UI, I selected:

• MiniMax H3
• FL2VA Pruned 20B
• Q2_K text encoder
• SageAttention 2
• High-RAM/Low-VRAM profile

My first stable run used the following settings:

The total includes model preparation and decoding, which is why it is noticeably longer than the denoising stage by itself.

The First Result Worth Keeping

The prompt described ocean waves striking black volcanic rocks at golden hour. The output had coherent motion, convincing spray, and an audio track that matched the scene. It did not feel like a diagnostic clip. It looked like footage I could use.

A later 640 × 800 test used 141 frames and 25 steps. If you treat pixel count × frame count × evaluated steps as a rough work estimate, that run was about 2.1 times heavier than the first. Denoising took a little over twice as long. Two runs are not a benchmark suite, but the result was reassuring: I did not hit a mysterious performance cliff. I had simply asked the machine to do roughly twice the work.

Keeping the model loaded also changes the experience. WanGP retains it in system RAM between jobs, so a batch does not pay the full loading cost for every prompt. When I am generating several shots, I queue them together and release the process after the batch finishes.

Where the Workflow Still Breaks

Text remains the most obvious failure. In a reporter shot, the main headline looked plausible, but the smaller copy on screens behind the subject quickly turned into nonsense. More VRAM would not solve that. The model is being asked to preserve several exact text regions while everything around them moves, and it still cannot do that reliably.

The better approach is to control more of the shot. A designed first frame, last frame, or both gives H3 fixed visual targets. Logos, interface screens, headlines, and other exact elements should be authored as assets and passed into the model. Hoping they appear correctly from prose is not a production workflow.

Throughput is the other hard limit. This machine can run H3, but it cannot make H3 feel interactive. The right interface is a queue with persistent settings, visible progress, useful errors, and a durable result at the end. Pretending the wait does not exist would only make the tool more frustrating.

Adding the Turbo LoRA

Once the 20-step workflow was stable, I added the MiniMax H3 Turbo LoRA. WanGP v12.434 included an accelerator profile that translated the LoRA for the pruned checkpoint. The profile I tested used the ckpt850 EMA weights, a 0.5 multiplier, four inference steps, guidance 1.0, and no additional step cache.

Turbo changes the economics of the setup. The base model generally wants around 15 to 20 steps. The Turbo LoRA targets four to eight, with six to eight giving motion and fine detail more room to develop. Its current upstream guidance recommends the newer v4_step600_ema checkpoint for most work, while the older ckpt850 can still be useful for heavy motion at four steps.

I am keeping Turbo as a separate experimental preset rather than replacing the 20-step baseline. It should cut the expensive transformer passes substantially, but fewer passes are only useful if the output survives.

Turbo, Spectrum, and first-block caching all skip or approximate work. Combining them without testing can remove too much computation. A fair comparison holds the prompt, seed, resolution, and frame count constant, then checks motion, audio, faces, text, and fine detail across profiles.

This is also the least glamorous part of local model work: sometimes the correct methodology is sitting there for an hour while nearly identical clips render.

What This Could Add to Studio

The local experiment is useful on its own, but I am more interested in what it suggests for Studio. Studio already has a provider-oriented generation layer. A model reports its capabilities, the app translates project settings into a request, and the finished media returns to the same project and timeline.

A local runtime should follow the same contract. The adapter would:

• discover the models and controls a runtime supports;
• show only settings that are valid for the selected workflow;
• submit and monitor a queued job;
• surface progress and useful errors;
• import the finished asset with its prompt, seed, frame inputs, model, and runtime settings attached.

WanGP can then be one backend instead of a special case threaded through the application. A Studio project could send a quick experiment to a hosted provider, route a controlled shot to a local H3 machine, and keep both results in the same project with enough metadata to reproduce or revise them.

That is the part I want to build around. Local and hosted generation do not need separate creative workflows. They need adapters that are honest about their capabilities and return assets in a consistent form.

What I’m Testing Next

• Benchmark four-, six-, and eight-step Turbo runs against the same 20-step seed.
• Record peak VRAM, resident system memory, GPU utilization, denoising time, and total wall time.
• Compare Q2_K with Q4_K_M for prompt adherence.
• Test designed first and last frames on shots containing screens, logos, headlines, and continuity-sensitive composition.
• Expose WanGP through a capability-driven Studio adapter with queue state and automatic asset import.

The Takeaway

An 8GB RTX 4060 is not secretly an H100. This setup makes a large video model possible by spending other resources: roughly 48GB of active system memory, repeated transfers across PCIe, and a lot of time.

For me, that is a worthwhile trade. The result is a private and inspectable video-generation pipeline on a consumer GPU. It produces usable video with synchronized audio, accepts controlled frame inputs, and stays loaded well enough to handle a queue of shots.

The interesting result is not that H3 completed one run. It is that the workflow became stable enough to treat as infrastructure.