VRAM Shared Memory
Hey Joey,
Thanks for all your hard work on this!
I am certainly not an expert, so I am not sure if it is your work or something to do with Minimax H3. When running workflows with other LTX models I can routinely use up to around 80gb of what my system sees as gpu memory. 31.5gb on the card and then another 50 or so of the 95gb of shared gpu memory without my machine going off into the main memory pool. That allows most workflows to generate 15 seconds at 1080p.
Looking at the log it seems it may be Minimax H3 but any ideas how to force some of this off into shared gpu memory? I think in an ideal scenario the cached shots would go off into shared and the model merge could live in dedicated. Even forcing the main merge into shared memory would still allow my machine to continue medium to high resolution generations at half decent speed.
And yes I know someone smarter or more talented actually deserves my machine more than me.
Thanks again!
Missed this, sorry!
I think the answer is the opposite of what you're hoping for: what you're describing is already happening, and it's the thing making it slow.
When ComfyUI reports loaded partially; 15029 MB loaded, 5766 MB offloaded, that is the model spilling out of dedicated VRAM. It doesn't OOM, it streams the missing weights over PCIe every step. That's the "shared GPU memory" path, and it works — it just costs you. I measured it on a 32 GB card tonight: shot 1 fits entirely and runs 39 s/it; later shots in the same chain carry extra conditioning, no longer fit, offload 5.7 GB, and run 57 s/it. Same model, same settings, ~45% slower purely from spilling. So pushing more into shared would make it worse, not better.
The other half — "cached shots go to shared" — is already done. Decoded frames and audio are moved to system RAM the moment each shot finishes, precisely so the accumulating timeline doesn't eat VRAM. The GPU only ever holds the current shot. So there's no cache sitting there to relocate; what's competing for the card is the DiT plus the activation pool, and neither can live on the far side of PCIe without paying per step.
That other LTX models reach ~80 GB is real, but it's the driver's sysmem fallback absorbing whatever doesn't fit rather than a design that benefits from it. Those runs are paying the same PCIe tax; it's just less visible when the alternative is not running at all.
What will actually get you 15s at 1080p: make the model fit. With 31.5 GB dedicated you want the DiT small enough that the weights and the activation pool sit on the card together. Q8_0 is ~20 GB and leaves too little once chained-shot conditioning is resident. Try the nvfp4 at 11.67GB (https://civitai.com/models/2857809/minimax-h3-comfy-native-w4a8-nvfp4-int8-mxfp8-stock-comfyui-032](https://civitai.com/api/download/models/3227890?fileId=3110300)— which leaves roughly 10 GB of headroom instead of a deficit. Also watch the [H3AutoReserve] lines: they tell you the measured activation pool for your exact shape, so you can see how much room the DiT actually has rather than guessing.
I'm releasing new workflows every day to help even more with memory management as well, so keep a look out. 2.2.5 coming in the next hour.
Amazing how quickly you and a few others turn things around. I was just going to say I can't believe I missed NVFP4 as I usually search for those straight away and then I realized it was only published a few hours ago. Thanks getting ready to give it a spin now.
FYI 736x960 10 steps at 277frames
Block Cache enabled, shot 1 13.10, shot 2 18.43 total run time 434
Block Cache bypassed, shot 1 12.57, shot 2 17.95 total run time 420