FreeVideo for MiniMax H3: Local Setup, Memory Planning and ComfyUI

FreeVideo brings a MiniMax H3-derived video workflow to local hardware through ComfyUI and a Linux command line. The project says it can run with as little as 8GB VRAM and 16GB system RAM. That makes it an interesting option for experimentation, but deciding whether it suits your computer requires more than checking the GPU's capacity.

This guide reviews the official repository and execution planner as of October 4, 2026. We have not run a consumer GPU benchmark. The steps below explain how to plan an installation, record a meaningful first run and avoid confusing a capacity claim with a speed guarantee.

Identify the checkpoint before comparing results

The FreeVideo README identifies its foundation as OpenVDN's eight-step VDN-H3 model, derived from MiniMax H3 and using Video DeltaNet hybrid attention. It is a local inference engine around that model lineage. It is not evidence that the stock hosted MiniMax endpoint and this installation use identical weights or sampling behavior.

That distinction affects comparisons. Keep the checkpoint, sampling steps, dimensions, duration and reference inputs attached to every generated clip. A prompt that works through a hosted API remains a useful starting point, but it does not guarantee identical motion, appearance or audio locally.

The project supports text, first and last frames, and image, video and audio references. Start with one input mode. Adding several references immediately makes it harder to tell whether a disappointing result comes from the prompt, model behavior or workflow configuration.

Interpret the 8GB claim as a memory plan

FreeVideo coordinates GPU memory, host RAM and disk instead of loading every component permanently onto the graphics card. Its planner can place transformer blocks in different memory tiers and stream weights as computation progresses. The execution planning documentation explains the placement and measurement process.

The project's reference capacity grid was produced on an NVIDIA H200 with capped VRAM and host-memory limits. Its documented workload uses 1344 × 768 output, 243 frames and eight steps in a single pass. Limiting a server's available memory is useful for studying capacity; it does not reproduce the compute speed or transfer behavior of every 8GB desktop GPU.

Resource	Why it matters	What to record locally
VRAM	Working tensors and resident weights	Available memory before generation
System RAM	Host-resident weights and transfer buffers	Free RAM after other applications load
Storage	Weight files and possible streaming	Free space, drive type and read behavior
GPU architecture	Available precision and attention paths	Selected compute path from the runtime

The planner may use native FP8 computation or FP8 storage with BF16 computation depending on hardware. Those paths have different execution characteristics. A card's VRAM capacity alone does not describe which path will be selected.

Close unrelated GPU workloads before establishing a baseline. FreeVideo remeasures available resources for each request, so a later request can receive a different plan if another application has consumed memory. Preserve both the plan and the result when comparing runs.

Choose the installation path you already use

For an existing ComfyUI installation, the documented custom-node setup is:

cd ComfyUI/custom_nodes
git clone https://github.com/FlashML-org/FreeVideo.git
cd FreeVideo
git checkout 98b3550ae551a70ae3f0a9a463f9dfc9a23b21a7

Restart ComfyUI, then open Workflow → Browse Templates → FreeVideo → FreeVideo-All-in-One and complete the setup in FreeVideo Settings. Reusing an existing installation can avoid duplicating models, but check the paths actually selected by the setup tool.

Windows users also have a launcher linked from the official repository. The reviewed release is labeled windows-preview. It can select an existing ComfyUI folder or install a new one and download missing models. Treat that label as part of the version record when reporting an installation problem.

The Linux route uses the repository setup script:

git clone https://github.com/FlashML-org/FreeVideo.git
cd FreeVideo
git checkout 98b3550ae551a70ae3f0a9a463f9dfc9a23b21a7
./setup.sh

These instructions follow the reviewed revision, rather than silently following future changes on the default branch. The published routes cover Windows and Linux; this guide does not establish support for macOS or Apple GPU hardware.

Plan first, then generate one baseline clip

After setup, inspect a hypothetical low-memory plan without loading model weights:

./freevideo plan --vram-gib 8 --ram-gib 16

That command is a planning operation. A returned plan is not a completed generation or proof that the same settings work on your installed driver stack. Confirm the actual device configuration before proceeding.

Put a simple prompt in prompt.txt, such as a single subject performing one action with a fixed camera. Then use the documented generation entry point:

./freevideo generate --prompt-file prompt.txt --out video.mp4

The runtime writes a companion video.mp4.request.json file containing the measured hardware, execution plan, stage timings and memory peaks. Keep it beside the clip. It provides a much stronger basis for troubleshooting than “the GPU has 8GB.”

Separate initial installation and model loading from generation timing. Then compare a second run at the same settings. Watch for disk streaming: fitting a request into memory can still leave the machine waiting for storage transfers. If the minimum working set cannot fit, the planner can reject the request before loading weights; changing the request dimensions or duration may be more useful than repeatedly restarting.

Add ComfyUI features after the baseline works

The FreeVideo workspace supports two-pass sampling, batches and a generation history. Its node view offers finer workflow control and LoRA integration. Introduce these features one at a time after recording a single-pass baseline.

When adding a reference frame or LoRA, keep the other settings fixed and compare the resulting clip. Check the property you care about: subject consistency, camera movement, action completion or visual artifacts. A longer queue of successful jobs only proves execution; it does not establish usable video quality.

Our MiniMax H3 prompt guide can help structure those comparisons. Keep hosted and local results labeled separately, including their checkpoint and input mode.

Read the weight license before deployment

FreeVideo's code is Apache-2.0, while its model weights use the MiniMax H3 Community License. The reviewed upstream license includes territorial and acceptable-use restrictions. Its defined excluded territories include the EU, UK, Republic of Korea and United States; it describes contacting MiniMax for a separate license in those territories. Commercial use also has additional terms. Read the agreement for the exact assets and deployment rather than treating the code license as unrestricted permission for the weights.

FreeVideo is a promising local experiment when the model terms and hardware fit your project. Start with a recorded baseline, inspect the memory plan and judge the clip against a specific creative task. Only then decide whether local generation's time and storage demands make sense for repeated work.

Frequently asked questions

Will every 8GB GPU generate video at the same speed?

No. The project's minimum-memory claim does not establish a universal runtime. GPU architecture, available RAM, storage transfers and request settings all matter.

Is this exactly the hosted MiniMax H3 model?

FreeVideo identifies an OpenVDN VDN-H3 derivative as its foundation. Keep that lineage explicit when comparing it with hosted results.

Is a successful plan enough to start batch production?

No. Generate and inspect a baseline clip, retain its request record, and check repeated-run timing and output quality before scaling the workload.