Nodes/comfyui-memory-manager/πŸ“Š VRAM Monitor
ComfyUI Node

πŸ“Š VRAM Monitor

The cheapest way to find out if it's actually memory killing your workflow

By darshd9941Β·Created 4 months agoΒ·Updated 4 months agoΒ· 1
πŸ“Š VRAM Monitor
  • trigger
  • vram_info

ComfyUI hordes VRAM until something crashes, and half the time you can't tell whether it's the model, the resolution, or a leak. VRAM Monitor drops a live readout into your graph so you stop guessing. Drag it in, hit run, and it prints current numbers to its output:

VRAM: 8234MB / 16384MB (50.2%)
Reserved: 9100MB | Free: 7284MB

That's a surprisingly complete picture for a node with essentially no setup. Allocated versus total tells you how much of the card is genuinely busy; Reserved tells you how much ComfyUI's CUDA allocator is squatting on; Free is your headroom for the next thing you load.

How it works

Under the hood it's a direct query of torch.cuda: total comes from the device properties, then torch.cuda.memory_reserved(), torch.cuda.memory_allocated(), and a free figure computed as total - reserved. Utilization is allocated / total. No tricks, no external calls, no key. If you're running CPU-only it just hands you the string "No CUDA GPU available" - which is genuinely useful as a smoke test, because it means ComfyUI can't see your GPU at all.

One honest caveat about that "Free" number: it's unreserved memory, not truly-free memory. ComfyUI's allocator reserves big slabs ahead of need, so Free can look low even when there's plenty of reclaimable slack in the Reserved pool. Treat it as a lower bound on headroom, and cross-check against nvidia-smi if you want the driver's version of the truth.

Inputs and output

There's exactly one optional input, and it's worth understanding:

  • trigger (any type): the node has no required inputs, so on its own it just runs whenever the queue executes and samples then. Wire any previous node's output into trigger and you pin the sample to that exact moment in the graph - read memory right after a KSampler finishes, or right before a second model loads.
  • Output: vram_info (STRING). Feed it into a text-display node to see it on the canvas, or read the value from the node itself.

The classic use is placing two of them around a heavy stage - one before, one after - so you can see the memory hump in the saved output and decide whether that stage is what's blowing up your 8GB card. It also pairs cleanly with 🧹 Force Cleanup: monitor, clean, monitor again, and you've measured exactly what the cleanup reclaimed.

Installation

This is one of five nodes in the comfyui-memory-manager pack, and they all install together:

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 present with ComfyUI

Or use ComfyUI Manager: search comfyui-memory-manager, install, restart. No model files, no heavy dependencies - the pack is tiny and single-purpose.

Troubleshooting

  • Output says "No CUDA GPU available": you're on CPU, or PyTorch can't see the card. Check nvidia-smi, and confirm ComfyUI itself loaded with CUDA enabled.
  • Free looks scarily low even when nothing is running: that's the allocator's reserved pool, not a leak. Do a cleanup and watch the number jump.
  • You want to actually free memory, not just watch it: the readout is only the instrument. Force Cleanup is the button, and ComfyUI's own Unload Models and Execution Cache menu item (under Edit) is the stronger tool for unloading loaded checkpoints.

One last thing worth saying: the community has been burned by over-managing ComfyUI's memory manually - the more aggressively you fight it, the less its own automatic management does. Use this node to diagnose, not to babysit.

Categorymemory/monitor

Inputs (1)

NameTypeDefaultDescription
triggeropt*β€”

Outputs (1)

NameTypeDescription
vram_infoSTRINGβ€”