Make a video follow a reference clip, on 8 GB

Take a 10-second clip. Keep its camera work and its cuts. Change the time of day, the place and the person, and add someone who was never there.

The worked example ships the source clip, the two reference images, the prompt and the graph. It does not ship the generated video — see License.

Peak VRAM 7,130–7,669 MiB across four variants — ComfyUI and the desktop together — against an 8,188 MiB ceiling. No swap. 0.02–0.04 GiB written to disk.

Measured on an RTX 5070 Ti with scripts/vram_sidecar.py holding all but 8,188 MiB, so the ceiling binds the hardware and not just ComfyUI's accounting; RAM capped at 32 GB with the mem=32GB kernel parameter — about 2 GB of that goes to this board's integrated GPU and kernel reserve, leaving 29.4 GiB usable. The monitor was driven from the card under measurement, not from the motherboard, so every VRAM figure here includes the desktop's own share. No physical 8 GB card was used.

The ceiling should have been 8,192 MiB, which is 8 GiB. 8,188 is an arithmetic slip that was kept once the runs were done, and every figure here was taken under the lower number.

This is a guide about fitting, not about speed. ComfyUI added H3 in 0.30.0 and 0.30.2 followed within days; any timing here will date. What does not date is what these settings were aiming at: keeping an 8 GB card from running out of memory.

---

Does this apply to your machine?

Your setup	Status
Anywhere	MiniMax H3 has its own license, with territorial provisions. Read it before you use the model — see License
NVIDIA Blackwell, 8 GB VRAM, 32 GB RAM, Linux	Your case. The 8 GB figures were taken under an 8,188 MiB ceiling held on a larger card; no 8 GB card was used. Timings will not transfer — see below. The More VRAM figures come from unconstrained 16 GB runs
NVIDIA Blackwell, more VRAM	This graph was only ever run under the 8 GB cap. See More VRAM
NVIDIA Ada / Ampere / older	Not run here. nvfp4 compute is unavailable below Blackwell — see Below Blackwell, two paragraphs below this table
AMD, Intel	This graph will most likely not run. Reading the attention node's source, it raises RuntimeError rather than falling back when it cannot determine a CUDA architecture. That is from the source, not from a run. The prompt wording carries nothing hardware-specific
Windows	Never run. It page-locks 40 % of RAM instead of 90 % and offloads differently

Timings here will not transfer to a real 8 GB card. The sidecar caps capacity and nothing else. An 8 GB Blackwell has fewer SMs and a narrower memory bus and host link than the 5070 Ti these numbers came off, and this workload re-reads the weights from disk on every sampling step. Expect slower; nobody has measured how much.

Below Blackwell, supports_nvfp4_compute returns false. ComfyUI expands the nvfp4 weights at runtime, so you get none of the speed. Whether RAM use rises was not measured.

Whether the int8 encoder (~27 GB, total ~53.9 GB) is the better answer is not clear. The one report of both on a 3080 Ti found nvfp4 faster anyway, because the smaller file offloads less — which matters on 32 GB of RAM. That report also found the two encoders give noticeably different output at the same seed, so the worked example will not reproduce exactly with the encoder swapped. Neither was tried here.

---

The method

Vendor-independent — nothing in this section depends on your hardware.

MiniMax documents a six-section format for H3's reference path; it is the intermediate representation the model's own preprocessing stage emits. Free text on this path was not tried here. The six sections, in this order, each on its own line:

subject_definitions:   who and what the labels <Subject N> / <Video N> refer to
summary:               one paragraph, opening with the task type in [brackets]
retention_analysis:    one line per label, what is kept from it
detailed_description:  the shots themselves, in order
overall_soundscape:    ambient and physical sound
non_diegetic_music:    score the characters cannot hear

examples/prompt.txt is a complete one. Step 2 below lands in summary, steps 3 and 4 in detailed_description, step 5 in both summary and retention_analysis. subject_definitions has no step of its own: write one line per <Subject N> / <Video N> label before you start. The model card carries this format; the full upstream guide is in MiniMax-AI/MiniMax-H3/skills.

1. Find where your source cuts.

git clone https://github.com/Tomiigo/minimax-h3-16gb
cd minimax-h3-16gb
python3 -m venv .venv && source .venv/bin/activate
pip install av opencv-python numpy
python scripts/cut_detect.py your_clip.mp4

The virtual environment is not optional on Debian or Ubuntu. Since 24.04 those systems mark the system interpreter externally managed, and a pip install outside a venv stops with error: externally-managed-environment.

This step does not need ComfyUI and can be taken before Install. If you already have the ComfyUI venv from that section, use it instead: it carries all three (av and numpy from ComfyUI's requirements, cv2 from KJNodes'), and neither the venv nor the pip install line is needed.

It prints the frame count, the duration and the cut times — the example's source is 240f 10.00s, cutting at 2.17 s and 6.21 s. You need the frame count again in step 6 of this section, where you compute length.

Your source must be 24 fps. The node treats reference frames as 24 fps unconditionally, and the shot timestamps you are about to write sit on that timeline. CreateVideo's fps is a widget you can change, but changing it only moves the output off that timeline. If your frame count and duration do not divide to 24, convert first and detect the cuts on the converted file. Untested; the one source used here was 24 fps.

ffmpeg -i in.mp4 -r 24 -fps_mode cfr src24.mp4   # separate install; needs ffmpeg >= 5.1
                                                 # on 5.0 and earlier use -vsync cfr

2. Declare the task as an edit. Open the summary with exactly this:

[video editing] The target video is an edited version of <Video 1>.

3. Write your source's cut times in as shot headers:

[Shot 1] ...
[Shot 2] At 00:02.170, ...
[Shot 3] At 00:06.210, ...

4. In every shot, say to keep the camera. These are the two forms that were run, from Shot 1 and Shot 2 of examples/prompt.txt:

Keeping the camera of the first shot of <Video 1> exactly, ...
At 00:02.170, the cut falls exactly where it falls in <Video 1>, and the camera of the
second shot of <Video 1> is kept exactly. ...

Whether the two forms are interchangeable was not tested.

5. Name what changes, and give retention_analysis a line for each label saying what must be kept. Whether unnamed elements are preserved by default was not tested, and naming an element is not sufficient either — see What did not follow the prompt.

6. Match your output length to your source.

length = ((source_frames - 5) // 17) * 17 + 5

240 frames gives 226. The node rounds output length up to that grid and the reference down to it, so computing it yourself keeps them aligned. It also means the model only ever sees the first 226 frames of a 240-frame source — the last 0.58 s cannot reach it at any length.

How "the camera came through" was judged: one person watched the output. No measurement here can decide it.

Steps 2 and 3 were never isolated cleanly. A run with [video editing] and no shot timestamps gave one continuous shot: no cuts, one of the source's three shots, arriving about 5 s late, by one person watching. An earlier reference generation run with shot timestamps put cuts at the right times and left the source's camera behind. Both runs differed from this one in other ways too, and neither carried the per-shot camera clause from step 4.

---

Install

ComfyUI 0.30.1, and KJNodes is the only custom-node pack you need. Versions after 0.30.1 were not tried. What that pins down, and the two extra commits the measured checkout carried, is under Model files below.

Before the model files:

git clone --branch v0.30.1 https://github.com/comfyanonymous/ComfyUI
cd ComfyUI && python3 -m venv venv && source venv/bin/activate
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt
git clone https://github.com/kijai/ComfyUI-KJNodes custom_nodes/ComfyUI-KJNodes
pip install -r custom_nodes/ComfyUI-KJNodes/requirements.txt   # the graph runs without these; step 1's cut_detect.py needs the cv2 they install

torchaudio is not optional — the H3 nodes import it at load. requirements.txt pins comfy-kitchen==0.2.26, which supplies the int8 kernels the 21 GB weight file needs; without it the KJNodes attention node raises RuntimeError and this graph does not run at all. comfy/quant_ops.py logs Failed to import comfy_kitchen if that happens.

The same file disables comfy-kitchen's CUDA backend below CUDA 13 and logs WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations. — which is why the torch line above pins cu130. Third-party reports put a cu12 build at roughly half the speed on the int8 convrot path; that figure was not verified here.

Model files

From Comfy-Org/MiniMax-H3.

File	Size	Put it in
minimax_h3_ref2va_pruned_int8_convrot.safetensors	21.0 GB	models/diffusion_models/
qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors	15.7 GB	models/text_encoders/
minimax_h3_video_vae_fp16.safetensors	5.2 GB	models/vae/
minimax_h3_audio_vae_fp32.safetensors	0.6 GB	models/vae/

42.5 GB in total. Also required:

• What "0.30.1 and KJNodes" rests on. The figures below were measured on a 0.30.1 checkout with two extra commits and seven packs loaded. Re-run on a clean 0.30.1 with KJNodes as the only pack, the graph produced video and audio pixel- and sample-identical to that run, in 195 s, under the same 8 GB cap and 32 GB RAM.

  This graph leaves the reference video's own audio track unconnected, and wiring it up was not tried here. Expect trouble if you do: in comfy/ldm/minimax/audio_vae.py, the register_buffer'd filter is cast by dtype alone, so a device mismatch on that path is likely on a clean 0.30.1. One of the two extra commits above is a local fix for it, and it is not published anywhere you can fetch it; the other is upstream PR #15268.

• KJNodes — the graph uses its MiniMaxH3MemoryEfficientSageAttentionPatch, which KJNodes marks experimental. The clone above is unpinned; these figures came off 1.4.9 (6edfa76, 2026-08-05). Later versions were not tried, and an experimental node is free to change.

• sageattention v2, built from source. pip install sageattention gives you 1.0.6 from PyPI as of 2026-08-12, the pure-Python v1, which does not contain the sageattention.core int8/fp8 kernels this node imports — the node then raises RuntimeError and the graph will not run. No v2 wheel is published for Linux, so building from source is the only route:

  pip install ninja packaging

  Those two are build tools, not runtime dependencies: the CUDA kernels are compiled on your machine, and without them the build either fails or falls back to a much slower compile. Then, with your CUDA toolkit's path:

  CUDA_HOME=/usr/local/cuda-13.2 PATH=/usr/local/cuda-13.2/bin:$PATH \
  TORCH_CUDA_ARCH_LIST=12.0 MAX_JOBS=8 \
  pip install --no-build-isolation "git+https://github.com/thu-ml/SageAttention.git"

  --no-build-isolation is not optional; without it pip re-downloads torch. Set TORCH_CUDA_ARCH_LIST to your own architecture — 12.0 is Blackwell. That clone is unpinned too; it produced sageattention 2.2.0 here, which is what every figure on this page was measured against.

  With TORCH_CUDA_ARCH_LIST=12.0, sageattention.core._qattn_sm89 does not import; KJNodes falls back to sm89_compile and the graph runs. Nothing is printed, so the log will not tell you either way. This is the one machine-specific step; expect to adjust paths. You need the CUDA toolkit (nvcc) installed — a pip-installed torch does not supply one — and the build must go into the same venv ComfyUI runs from. Lower MAX_JOBS if the build exhausts your RAM.

Upscale Image, EasyCache and the MiniMax H3 nodes ship with ComfyUI.

---

8 GB

1. Put the material in place. Copy ref_motion2.mp4, ref_front.png and ref_back.png from examples/ into ComfyUI/input/. If the server is already running, reload the browser tab — Load Video rebuilds its file list on every /object_info request.

2. Launch:

cd ComfyUI
source venv/bin/activate
python main.py --disable-pinned-memory --reserve-vram 1.5

--disable-pinned-memory — ComfyUI page-locks up to 90 % of RAM by default. This run wrote 0.02 GiB and never touched swap. A separate measurement with the flag off wrote 5.0–6.7 GiB across three runs; the one also capped at 8 GB consumed the whole 7.45 GiB swap. The flag also adds about a fifth to the runtime on 8 GB — 180 s against 150 s on one earlier job — because the weights are re-read from disk every step instead of staying in pinned RAM. The trade is speed for not filling your swap.

If you have more than 8 GB and want to reproduce these numbers rather than just run the graph, hold the ceiling in hardware from a second terminal, before launching ComfyUI:

python scripts/vram_sidecar.py --card-size 8188

It occupies everything above that figure, so torch.cuda.mem_get_info reports the smaller card to ComfyUI. Leave it running for the whole session. On an 8 GB card you do not need it.

--reserve-vram 1.5 — leaves room for the desktop, which is on the same card. It is an accounting limit, not a hardware one — in one calibration run at a different setting it overshot the intended budget by 975 MiB. Figures here were taken with a sidecar holding the ceiling in hardware.

3. Load the graph. examples/workflow_api.json is the graph that produced the measurements below. Load it, then swap in your own material.

4. Run it. Press Run in the toolbar; with the legacy menu enabled the same button reads Queue Prompt. Both labels are from the frontend 0.30.1 ships, 1.47.12 — other versions may word it differently. The finished video appears in the Save Video node and at ComfyUI/output/video/h3_edit_00001_.mp4 — the graph's filename_prefix is video/h3_edit, so it lands in a video/ subfolder, not directly in output/.

5. The settings that were measured:

Setting	Value
Output	640×384, length 226
Sampler	res_multistep, scheduler simple, 20 steps
Seed	868518237154239
ref_image_size	match — the tooltip says the other option, max, can be several times slower
Reference video	scaled to 320×192 with Upscale Image, lanczos
EasyCache	reuse_threshold 0.30, start_percent 0.20, end_percent 0.90

Width and height must be multiples of 32. No 16:9 pair exists near this width — 640×384 is 5:3, and the 1280×720 source is squeezed into it. The reference is squeezed the same way. 512×288 and 1024×576 are 16:9 on the grid; neither was tried. Whether the reference's aspect must match the output's was not tested.

These figures are for 640×384 at length 226. Nothing here measures what any other resolution or length costs. The node's tooltip puts its trained range at roughly 124–362 frames, about 5 to 15 seconds.

The reference video's own audio track is not connected; the output's audio is generated from the prompt's overall_soundscape.

The reference video is VAE-encoded whole and its latent rides through every sampling step. An earlier configuration at the same 8 GB cap, passing the reference at 1280×720, failed with torch.OutOfMemoryError (Free (according to CUDA): 53.88 MiB). That configuration also differed in output size and length, so the reference resolution is not isolated. Removing the node from this graph was not tried.

6. What you get:

Measurement	Result
Time	190 s
VRAM, ComfyUI and desktop together	7,444 MiB of 8,188
Disk written	0.02 GiB
Swap	never used

That 7,444 MiB is ComfyUI plus everything the desktop was already holding. In a separate run under the same ceiling, the desktop's own share came to about 1,440 MiB — a GNOME session, a browser and a desktop app. Yours will be its own number, and it comes out of the same 8 GB.

Disk read was measured on an earlier run at the same cap, without the reference images and with an earlier prompt: 270 GiB read, 0.04 GiB written, 165 s. On 8 GB the weights cannot stay resident, so they stream off the drive on every sampling step. That figure was taken once, on an NVMe drive; no other storage was tried.

Across four variants — reference video alone, plus two reference images, plus an added character, plus a rewritten prop — peak VRAM stayed between 7,130 and 7,669 MiB, and time went 165 s → 175 s → 190 s → 190 s. Each variant was run once. Adding the images also forced a prompt change, since the person then had to be named as <Subject 1>.

Times were read at 5-second polling resolution, with the weights already staged by a previous run. Expect the first run of a session to be longer.

Freeing VRAM. Check what is already taken:

nvidia-smi          # the process table lists graphics clients too: compositor, browser

--query-compute-apps will not show them; it lists CUDA compute contexts only. Whatever your desktop session and browser hold comes out of your 8 GB. Driving the monitor from integrated graphics, or logging out and running ComfyUI from a text console, frees the most. None of these were measured here. If the desktop stutters mid-generation, raising --reserve-vram is the lever; it shrinks ComfyUI's budget in exchange, and was not tried.

---

More VRAM

This graph was only ever run under the 8 GB cap. Dropping Upscale Image from it was not tried.

Four earlier runs, all unconstrained on a 16 GB card. A full-resolution/downscaled pair with two reference images at length 243: 1,027 s at full resolution against 170 s downscaled, peaking at 14,471 and 15,638 MiB. Unconstrained peaks say how much ComfyUI took, not how much it needs. Full resolution was preferred there, but not blind. Two more without reference images, at length 226 and with different prompts: 895 s and 955 s, peaking at 15,758 and 14,455 MiB. Both of those passed the reference at full resolution too. A later blind A/B at two further seeds split 1-1, so nothing here shows full resolution is systematically better. These four peaks are ComfyUI and desktop together, the same as the 8 GB figures.

If you want to know what your card can do, cap it with scripts/vram_sidecar.py and find out.

---

Speed nodes in the graph

The graph carries two nodes that exist for speed and memory: MiniMaxH3MemoryEfficientSageAttentionPatch from KJNodes, which KJNodes describes as reducing peak VRAM, and EasyCache. Every 8 GB timing and VRAM figure on this page was measured with both in place; nothing here prices this graph without them.

Issue #15326, open as of 2026-08-12, reports that EasyCache degrades H3's audio. reuse_threshold is how much drift the node tolerates before it reuses a cached step instead of computing one: the higher the number, the more steps it skips, and the further the result can move. The issue's measurements are at 0.20; this graph runs 0.30, so it skips more, not fewer. Whether the audio suffers at 0.30 was not judged here. Listen to your own output and decide; the node can be removed from the graph.

---

What did not follow the prompt

The output is not shipped (see License), so nothing in this section is checkable from this repository. Generate it and judge for yourself.

The rod the woman holds. The prompt asked for raised relief and verdigris; the output has a smooth rod with neither, and it is not the source's plain stick either.

Camera, framing, the person, the world, and a character added from nothing all came through, judged by one person watching.

The cut times were written into the prompt, so where they landed says the shot headers were obeyed, not that the camera transferred. The first landed 0.08 s from the source's; the second 0.50 s early, which the shipped detector scores as a miss at its default ±0.3 s tolerance. The unconstrained full-resolution run scored 2/2 on the same detector — 0.08 s and 0.00 s. Those runs differ in more than reference resolution.

Two generations touched this prop. In the second its description was rewritten, and it came out different again but still not the one described. Nothing here says how prop descriptions behave in general.

---

Not tested

• More than 8 GB, with this graph. Nothing here measures what full resolution needs.
• 64 GB RAM. 32 GB and 125 GB were measured. Both work.
• Any source but the one shipped here. One clip, one seed, one prompt — and that clip is itself AI-generated, not camera footage.

---

Scripts

In scripts/: the cut detector from The method, and the sidecar that holds VRAM so a smaller card can be simulated on a larger one. Three further measurement tools are included. The job runner that produced every timing and VRAM figure on this page is not published, so those figures cannot be re-derived from this repository.

---

License

Code and the prompt (scripts/*.py, examples/workflow_api.json, examples/prompt.txt) are MIT. The documentation, the three reference media files and everything else not listed above are CC BY 4.0 — the media began as Gemini output and were retouched by the author.

This tree contains no MiniMax H3 output. One does survive in the history: examples/output.mp4 in commit cc3e844, removed in 2d91555. It is a leftover of an earlier, withdrawn version of this guide, not the file the graph here produces. A full clone still fetches it.

MiniMax H3 carries its own license, separate from anything here, and it has territorial provisions. Read it before you use the model: MiniMaxAI/MiniMax-H3. Nothing in this repository grants you any right to the model.

See LICENSE. Nothing here licenses the H3 model weights, ComfyUI, KJNodes or sageattention.

---

Corrections welcome. Open an issue.