Nodes/comfyui-memory-manager/🚦 Memory Budget Gate
ComfyUI Node

🚦 Memory Budget Gate

The 'gate' that never actually stops anything

By darshd9941Β·Created 4 months agoΒ·Updated 4 months agoΒ· 1
🚦 Memory Budget Gate
  • model
  • model
  • status
β—„required_mb2000β–Ί

Memory Budget Gate is supposed to keep you from OOM-crashing by checking how much VRAM is free before a heavy stage proceeds. That's the promise. The reality, verified in the source, is that the name overpromises: when the check fails it prints "BLOCKED" and the workflow just keeps going anyway. I'll get to why in a moment, because once you know that, the node is still useful - just not as a gate.

What it does

You set one number - required_mb, how much free VRAM the next stage needs - and optionally pass a model through it. On run:

  1. It queries current VRAM (free = total minus reserved, same math as πŸ“Š VRAM Monitor).
  2. If free β‰₯ required_mb, you get OK - 7284MB available (need 4000MB).
  3. If not, it runs a cleanup (🧹 Force Cleanup's gc.collect() + empty_cache() + synchronize()), re-checks, and either reports Cleaned - 7284MB now available or BLOCKED - only 1200MB free, need 4000MB.

So it's really a check-and-clean node wearing a traffic light's costume. The cleanup-on-shortage behavior is genuinely handy: it buys you a retry before the expensive stage runs, which is the same reason people love cleanup nodes.

The trap, stated plainly

Read the return statement: when the check fails, it still returns your model unchanged alongside the "BLOCKED" string. ComfyUI sees a normal execution and carries on - no exception, no halt, no conditional reroute. If you were hoping it would protect a 6GB card from a Flux load, it will not stop anything; the next node runs anyway and OOMs exactly as it would have.

This matters because the README frames the node as a way to "prevent OOM by gating expensive operations." It doesn't. What it can do is tell you - in a string you can read or route - that you're about to run out, and trigger a cleanup on its own. That's a diagnostic and an opportunistic tidy-up, not a safety mechanism. Want actual gating? You'd need something that raises on failure, or a router node that branches on the status string. This pack doesn't ship one.

Inputs and output

  • required_mb (INT, default 2000, range 100–24000, step 100): the only input you'll set. Make it a bit larger than the next model's footprint - SDXL roughly doubles a 12GB card's needs while running, and the number here is available memory, not model size. When in doubt, overestimate.
  • model (any, optional): pure passthrough. Wire your checkpoint or conditioning in and out; the gate reads VRAM, shrugs, and hands it through either way.
  • Outputs: model (whatever you passed in) and status (the OK/Cleaned/BLOCKED string). Route status into a text-display node to actually see it.

Installation

Part of the comfyui-memory-manager pack, five nodes, one install:

cd ComfyUI/custom_nodes
git clone https://github.com/darshd9941/comfyui-memory-manager.git
cd comfyui-memory-manager
pip install -r requirements.txt   # torch>=2.0 - already installed

Or in ComfyUI Manager: search comfyui-memory-manager, install, restart.

Troubleshooting

  • It says BLOCKED but everything keeps running: not a bug - that's the design, and now you know. Treat the status as a warning light, not a breaker.
  • The model output is empty: the model output echoes whatever you fed in; if you didn't wire an input, don't expect an output.
  • It reports OK but the next stage still OOMs: free here is unreserved memory, and it doesn't account for the model you're about to load. Set required_mb above the next model's size, not at the current free amount.

Bottom line: add it before a heavy stage to get a free "are we okay?" check plus an automatic cleanup. Just don't bet your GPU's safety on it.

Categorymemory/management

Inputs (2)

NameTypeDefaultDescription
required_mbINT2000100–24000β€”
modelopt*β€”

Outputs (2)

NameTypeDescription
model*β€”
status*β€”