MiniMax H3: 15 s image-to-video at about 1 MP, with audio (low-memory)
An image-to-video workflow for MiniMax H3 that renders about 15 seconds (357 frames) at roughly 1 megapixel, with audio. It uses the LayerStream: H3 Chunking node to keep activation memory in check on long clips.
Why the chunking node
On long or large H3 clips the model's activations, not the weights, can fill the VRAM. They grow with the number of tokens (frames × resolution). The node runs the same transformer math in slices instead of one big pass. In my tests, PyTorch's own allocations stayed under a hard 8 GB cap for this 15 s, 1 MP clip.
Does it change the picture?
No. Output was bit-identical to the stock run in my tests. I compared the chunked and stock results frame by frame at 6 steps, on a 124-frame clip and on a full 15 s clip, and they matched exactly. The node doesn't approximate anything.
Two honest caveats:
Audio was compared byte for byte only on a short clip (56 frames). I haven't run that comparison on the full 15 s yet.
Chunking is slower. About 10 % in my test.
What's in the workflow
Start image → H3 image-to-video, 6 steps with the 8-step turbo LoRA,
res_multistepsamplerMegapixel Size node: sets width and height from your start image (about 1.05 MP, multiple of 32, so a square image gives 1024×1024)
Audio VAE decode, so the video has sound
Saved as a video with audio
A tip I learned the hard way: use 6 steps, not 2. At 2 steps this turbo LoRA gives artifacts (for example a distorted nose in motion). That happens with or without my node.
Requirements
ComfyUI 0.39.0 or newer
The osiworx-pack custom node pack. Install it from ComfyUI-Manager or from https://github.com/osi1880vr/osiworx-pack
MiniMax H3 files: diffusion model (hybrid int8), text encoder, video VAE, audio VAE (fp32), and the 8-step turbo LoRA. The file names in the loader nodes are from my machine, so pick your own.
Tested on
Windows, RTX 4090 (24 GB), ComfyUI 0.39.0. I haven't tested cards below 24 GB or other operating systems. On my 24 GB card, a launch flag (--vram-headroom) already solved the memory problem on its own. The node mainly lowers the memory floor and keeps usage predictable.
Limits
The node patches parts of ComfyUI's H3 code, so a future ComfyUI update could break it. Tell me if it does.
The lowest activation memory I measured for H3 is about 4.2 GiB. Below that it needs more work.
Model files are not included.
Details, measurements and what I haven't tested are in the README: https://github.com/osi1880vr/osiworx-pack
Description
FAQ
Comments (6)
I tried this workflow and this is my result. Image stayed fairly consitent throughout 15 second video. However, I use a 12GB 3080Ti card with 64GB Ram and the generation took 34min 35sec total. A 10 second video took 17min 40sec. I saw your comment saying untested on under 24GB VRAM, so I decided to post my results for under 24.
Thats great, thank you, we can not expect this trick to help in speed. It helps in accessability, so a smaller card can do it. In my case only with this trick I was able to do 15 sec on my 4090, as with the krea2 workflow to run the bf16 models at 4MP, that did work on simulated 4GB alone running a 23GB model... again slow as a snail but it gives you access which was my main idea.
One final result. I added "Model Attention Backend" node and selected Comfy Kitchen. 10 second video generation time was reduced to 11min 33sec. Node was added after lora loader and before LayerStream.
Oh great, you gained 20 minutes by that, thats a good thing to add then. I had mixed results. but after this I might give it a try again then :D 20 minutes, man thats 2 more videos in the same time of 1 before :D
And what was the resolution of generated video?
@voayer2003587 its the exact video on the workflow here, the video thats shown is the one. it is 15s 1 mega pixels