Ares Smart VRAM Reservation

ComfyUI nodes usually touch pixels. This one changes a number. Ares Smart VRAM Reservation (ReservedMemorySetter) writes into model_management.EXTRA_RESERVED_VRAM - the same global ComfyUI's --reserve-vram N launch flag sets at startup. Same knob, different hand.

What the reservation actually does

That global taxes the allocator's arithmetic: ComfyUI subtracts it from the free VRAM it thinks it has, so it offloads model blocks to system RAM earlier instead of filling the card to the last byte. The honest use case is leaving headroom for Windows and your browser, and stopping a full card from freezing the machine. The flag, though, is a restart-time decision: change it, kill ComfyUI, reload everything. This node sets it mid-graph, per prompt.

One thing to internalize: it's a global, not a node setting, and the last writer wins for the whole session. Launch with --reserve-vram 4, then run a workflow with this node at 1.5, and you're on 1.5 afterwards.

The three modes, and the defaults that bite you

The arithmetic is in the source. manual reserves the larger of reserved_amount and min_safe_reserve, capped at 90% of total. auto is current usage plus reserved_amount as a buffer, capped at 85%. smart watches the free/total ratio: under 20% free it reserves at least 80% of the card, 20–40% free it uses usage + buffer, above 40% free it keeps min_safe_reserve as a floor.

Now the trap. It ships as mode: manual, reserved_amount: 4.0, min_safe_reserve: 4.0. Drop the node in and run it, and you have just reserved 4GB - half of an 8GB card, on purpose. The pack's own README recommends smart with reserved_amount 1.0–2.0 and min_safe_reserve 2.0. Take that advice.

The sockets and the widgets

input is a wildcard * socket, and output hands back whatever you put in, untouched - a pass-through you can thread through a graph without breaking a wire. It's an output node (OUTPUT_NODE = True), so it runs on every queue even when nothing downstream uses it.

Don't over-trust the ordering, though: nodes execute in dependency order, so unless you feed this one something cheap and early (a primitive, your prompt string) it can fire after your checkpoint is already on the card. If you need the reservation in place before anything loads, that's the launch flag's job.

The rest: reserved_amount in GB (0.6–32), min_safe_reserve (0.5–8), gpu_index (0–7). clear_vram (on by default) runs empty-cache, a synchronize and gc.collect(), then reports what was freed by sampling pynvml before and after. show_gpu_info (on) prints model, VRAM, temperature and utilization, and is the piece that needs nvidia-ml-py.

Then the odd one: occupy_vram, with occupy_amount (1–4GB), occupy_delay (default 5s) and occupy_hold (default 10s). Toggle it and the node spawns a separate Python process that allocates torch.zeros() of that size on your GPU and sleeps for an hour; the parent kills it when the hold expires. That isn't more VRAM, it's the opposite - you hold memory hostage so something else keeps headroom. It also costs slightly more than advertised, since the child imports torch again and carries its own CUDA context.

Install

ComfyUI Manager: search the pack title ARES_GPU_Manager. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/SuperWJ062/ComfyUI-ares_gpu_manager
pip install nvidia-ml-py

Restart. The real requirements.txt is one line - nvidia-ml-py>=12.0.0 - with torch and comfy commented out as already present. No models, no build step, GPL-3.0, two Python files. Skip the pip install and the reservation still works; only the readout degrades. Watch for [ARES GPU Memory Manager] v2.2.0 loaded in the console: v2.2's changelog says it fixed the reservation silently not applying (EXTRA_RESERVED_MEMORY → EXTRA_RESERVED_VRAM), so on 2.0 or 2.1 you're debugging a no-op.

Where people get burned

Raising the reservation can cause OOMs, not fix them. Not a paradox - you took memory away and told the allocator to offload earlier. The trap has been written up: --reserve-vram 4 stops LTX-2 from OOMing, works fine, then WAN starts OOMing at resolutions that were previously fine and are fine again once the flag comes off. Same global here, so if raising the number makes things worse, lower it. If a model genuinely doesn't fit, the lever is quantization - fp8, GGUF at Q4–Q8, INT8-ConvRot on 30-series - and on modern models the text encoder is a second budget that often decides what fits. Reservation doesn't make anything smaller; it picks slow-but-alive over fast-but-dead.

Two smaller ones. A stray occupy process: the module registers an atexit cleanup, but that never runs if ComfyUI is hard-killed from Task Manager, so check nvidia-smi for a leftover python sitting on your VRAM. And no GPU info at all usually just means nvidia-ml-py isn't installed in the environment ComfyUI actually runs in.

Reach for it when different workflows want different headroom. If one setting suits everything, put --reserve-vram N in your launch arguments and skip the node.