Set Reserved VRAM(GB) ⚙️

If you've ever launched ComfyUI with --reserve-vram 4 to stop it OOMing on a big video model, this node is that flag, except you can flip it per-workflow without restarting. That's the whole pitch, and it's a genuinely good one.

Why you'd want this

Here's the problem it solves. ComfyUI tries to use as much of your card as it can, then offloads the rest to system RAM. That mostly works - until it doesn't. On some models (LTX-2 and WAN are the usual suspects) ComfyUI mis-guesses how much VRAM it needs, fills the card to the brim, and either OOMs outright or spills into Windows "shared GPU memory," which is just system RAM wearing a disguise. When that happens your iterations drop from a couple seconds to five minutes each and Windows gets sluggish. The community fix has always been the --reserve-vram launch flag: tell ComfyUI to keep a few GB free so there's breathing room and it stops the runaway offload. One r/comfyui poster with a 24GB card put it plainly - set reserve to about 3-4GB and LTX-2 goes from locking the system up to running fine.

The catch with the launch flag is that it's global and static. A reservation that saves LTX-2 will cause OOMs on WAN at resolutions that used to work, because now you've walled off VRAM that model actually wanted. So you end up restarting ComfyUI with different flags for different workflows. Annoying.

This node makes the reservation a graph value instead. Drop it into a workflow, set the number, and it applies at runtime - different workflows, different reservations, no restart.

How it works

On ComfyUI builds that expose model_management.set_extra_reserved_vram(), the node calls that runtime API directly. On older builds it sets the EXTRA_RESERVED_VRAM environment variable and, if you're running DynamicVRAM / comfy-aimdo, syncs its headroom too. Either way you're nudging the same knob the launch flag controls - just live.

Worth knowing: this is a tradeoff, not free performance. Our own notes have an A/B where the real 2x speedup came from removing --reserve-vram, not adding it. Cards that "barely fit" a model lose the most to reserving VRAM they actually need. So reserve when you're OOMing or offloading, not by reflex.

The inputs that matter

There are five inputs but you'll really touch two or three:

• reserved (default 0.6 GB) - how much VRAM to hold back. The README's method: run your workflow, watch Windows Task Manager for how much "shared GPU memory" overflows, and reserve roughly that much (a touch more is fine). Can go negative, which only makes sense paired with auto mode.
• mode - manual sets exactly your number. auto reads how much VRAM is already in use and stacks your value on top, which is the one to use if you've got other processes (a second ComfyUI, a browser, a game) fighting for the card.
• auto_max_reserved - a ceiling for auto mode so it can't reserve something absurd. 0 means no cap. Only relevant in auto.

The other two: clean_gpu_before (default on) purges VRAM before applying, so the node doubles as a cleanup step; and seed - set it to a changing value and the node re-checks and re-applies the strategy every single run, instead of caching. Leave it if you want the reservation evaluated fresh each time.

There's also an optional anything passthrough input. Since this is an output node it fires whether or not you wire it, but if you feed something through anything → the output you can splice it inline early in the graph and force it to run before the heavy nodes. That's the intended placement: near the front. The other two outputs, SEED and Reserved(GB), just report back what it used - handy for wiring into a display node so you can see the value it landed on.

Installing it

ComfyUI Manager is the easy path: open Manager, search ComfyUI-ReservedVRAM, install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/Windecay/ComfyUI-ReservedVRAM

then restart ComfyUI. No models, no pip dependencies, no build step - it's pure Python poking at ComfyUI's own memory management.

Where people get tripped up

The big one is expecting it to be a magic OOM cure. It isn't. Reserving VRAM helps when the problem is runaway offload / shared-memory spillover; it does nothing for a workflow that genuinely needs more VRAM than the card has, and it'll actively hurt a model that was already fitting snugly. If reserving made things worse, reserve less (or zero) - that's the signal you didn't need it. And if you're on Windows and want the underlying spillover gone at the source, set NVIDIA Control Panel's "CUDA - Sysmem Fallback Policy" to "Prefer No Sysmem Fallback"; this node and that setting solve the same headache from different ends.