Nodes/ValiTools/VWaitForVRAM
ComfyUI Node

VWaitForVRAM

Stop a second ComfyUI run from stomping your VRAM

By vangel76·Created about a month ago·Updated 5 days ago· 0
VWaitForVRAM
  • any_in
  • any_out
  • free_gb
min_free_gb8.0
device_index0
poll_seconds2.0
timeout_seconds0
on_timeoutcontinue
count_own_vramtrue

You've got one GPU and two things that want it. A long batch queue running in one ComfyUI instance, then you open a second one to test a prompt and hit an out-of-memory error mid-run. Or a LoRA training job parked on the same card. VWaitForVRAM is a node that does one thing: it holds execution of whatever sits downstream of it until the GPU has a minimum amount of free VRAM.

The name undersells the mechanism but not the value. This node only waits - it never unloads a model, never frees anything, never negotiates with the other process. It just refuses to let a run proceed until there's room, and passes whatever value you spliced into it straight through once it lets go. Think of it as a traffic light on a wire.

How it works

It reads free VRAM straight from the CUDA driver (torch.cuda.mem_get_info), not from an estimate. Then comes the clever part: by default it counts the VRAM held by this ComfyUI as available (count_own_vram, on by default). That sounds backwards until you remember ComfyUI frees its own models when it needs room - a single instance doesn't squat on all its VRAM forever. What you're really waiting for is other processes letting go.

The changelog tells you exactly why that default exists. In v1.14.1 the node blocked forever from the second render on: the driver's free number collapses once a model is resident, so the node sat there waiting on memory it was holding itself. count_own_vram was the fix. Turn it off and you get a strict driver-only reading - and the tooltip's warning is literal: the node will block forever once a model is loaded.

The wait loop rechecks every poll_seconds (default 2s), is cancellable any time with ComfyUI's stop button, and shows a live free / min GB readout right on the node while it waits. Each run logs the breakdown (driver free / torch pool / ComfyUI's own loaded models) to the console. Under the hood it returns float("NaN") from IS_CHANGED, the always-rerun trick that stops ComfyUI caching it - otherwise a second queued prompt would skip the wait entirely. Without a CUDA device it passes through immediately, so sharing a workflow with a CPU-only friend won't hang.

The inputs that matter

  • min_free_gb (default 8) - the gate. Minimum free VRAM before the run proceeds. This is the only knob you'll really touch.
  • count_own_vram (default on) - leave it on. Off is a footgun, not a feature.
  • timeout_seconds (default 0 = wait forever) with on_timeout (continue / error) - after N seconds, either run anyway or fail the prompt. Set this if a queue runs overnight unattended.
  • poll_seconds (default 2) - how often to re-check. Fine as-is.
  • device_index - which CUDA card to watch, when you have several.

Outputs: any_out is the value you spliced in, untouched, and free_gb gives you the measured free VRAM at release if you want to log or condition on it.

Where to put it and how to install

Splice it into a wire ahead of the memory-hungry part of the graph - the sampler's latent_image or model input is the usual spot. Everything downstream waits; the model load upstream proceeds. It ships in the ValiTools pack from vangel76, alongside VSmartPrompt and friends. Install via ComfyUI Manager (search "comfyui-ValiTools") or:

cd ComfyUI/custom_nodes
git clone https://github.com/vangel76/comfyui-ValiTools

Then restart ComfyUI. No model downloads, no heavy dependencies - the pyproject declares nothing beyond ComfyUI's own torch stack, so this one's a genuinely light add.

Common gotchas

  • It blocks forever - check count_own_vram is on, and remember the one thing it can't do: make the other process release. If a second ComfyUI is sitting on 10GB, you'll just wait until it finishes. This node is a gate, not a negotiator.
  • Timeout 0 with nobody freeing - that's on you. That's what timeout_seconds and the stop button are for.
  • Spliced in too late - putting it after the heavy allocation defeats the point; that's why the README steers you to the sampler's latent/model input.

If you run parallel ComfyUI instances or a trainer on the same card, this is the node that turns "surprise OOM" into "waits politely." Small, honest, and it does exactly one job.

CategoryValiTools

Inputs (7)

NameTypeDefaultDescription
min_free_gbFLOAT8.00–1024Hold execution until at least this much VRAM is free on the device.
device_indexINT00–15CUDA device to watch.
poll_secondsFLOAT2.00.1–60How often the free memory is checked while waiting.
timeout_secondsFLOAT00–86400Give up after this many seconds. 0 = wait forever (cancel with ComfyUI's stop button).
on_timeoutCOMBOcontinueWhat to do when the timeout is reached: run anyway, or fail the prompt.
count_own_vramBOOLEANtrueCount VRAM held by THIS ComfyUI as available (it frees its own models when it needs room). Keep this on to wait only for other processes - turning it off makes the node block forever once a model is resident.
any_inopt*Splice this node into a wire (e.g. the sampler's latent or model input) - it holds back everything DOWNSTREAM of it.

Outputs (2)

NameTypeDescription
any_out*
free_gbFLOAT