StFist - VRAM Optimizer

Let's be straight about the name: this node does not "optimize" your VRAM the way the title suggests. It does not make Flux fit on a card that couldn't hold it, and it doesn't beat ComfyUI's built-in model management. What it actually does is call torch.cuda.empty_cache() on a schedule you control. The pack's own tooltip admits as much: "Executes 'torch.cuda.empty_cache()'." Once you know that, you can decide honestly whether it's for you.

What it actually does

The core is a tiny cleanup routine. Standard mode calls torch.cuda.empty_cache() plus torch.cuda.ipc_collect(). Aggressive mode adds gc.collect() and torch.cuda.synchronize() on top. If that sounds like a modest amount of machinery for a "VRAM Optimizer," that's because it is - though it's wired in more cleverly than you'd expect.

The node registers a hook into ComfyUI's own execution.PromptExecutor.execute, monkeypatching it so cleanup runs before the queue, after it, or both, depending on run_timing. It's a singleton, so if you drop several copies on the canvas they share one instance instead of stacking redundant cleaners. And because it's an output node whose IS_CHANGED always returns a fresh timestamp, it re-executes on every queue run - that's why the terminal fills up with its strawberry emoji status lines, which is expected noise, not a bug.

What it genuinely helps with

empty_cache() doesn't free live models or tensors - it frees the unused blocks PyTorch's caching allocator is holding for reuse. ComfyUI already unloads models when VRAM pressure demands it, so this is a complement to that, not a replacement. Where it earns its keep:

• Long queue sessions where VRAM creeps up between jobs and you want the allocator to hand memory back.
• Reclaiming memory for other apps - browsers, OBS, a second ComfyUI instance - when the box idles between generations.
• After a heavy run (a video model or a big upscale) before you start the next one, so it starts from a clean slate.

The honest take: if you run one image and stop, you don't need this. If you babysit long queues on a mid-size card, it's a convenient, mostly-harmless habit.

Inputs that matter

• run_timing - Before Queue, After Queue, or Both. "After Queue" is the sensible default; cleaning before a run means every job starts from a cold allocator, which is where you'd feel a slowdown.
• auto_clean - Every Time, or Only When High. This is the one to care about: "Every Time" empties the cache after every single generation, so the next image has to reallocate its tensors from scratch - a small per-run cost that adds up. "Only When High" (the code's cutoff is a hardcoded 70% VRAM usage) only cleans when you're actually near the edge. That's the mode I'd leave it on.
• clear_mode - Standard or Aggressive. Aggressive adds a Python garbage-collect and a CUDA sync, which blocks until the GPU catches up. Fine to try; Standard usually does the job.
• force_run - a manual trigger. Change the number and it cleans right now, regardless of schedule. Also handy for verifying the node is actually alive.
• enabled - the master switch, default On.

Output and how to place it

It has one output: status (STRING), a human-readable line like VRAM cleanup completed! Freed: 512.3MB that you can pipe into a Show Text node. But the README is explicit that you don't need to wire it to anything - drop it in a corner of the canvas, leave it disconnected, and it hooks the queue all on its own. That's the whole design: passive background cleanup with terminal logging.

Installing and troubleshooting

ComfyUI Manager → search "StrawberryFist VRAM Optimizer" → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/strawberryPunch/vram_optimizer

Then restart. The only dependency is GPUtil>=1.4.0, which auto-installs on first run - no models, no heavy downloads.

If nothing happens, check in this order: is enabled On, is CUDA actually available (torch.cuda.is_available()), and does nvidia-smi work? The "GPU not found" failure path is real and it's what you get when the monitor can't see a GPU to report on. And if you never see cleanup lines in the terminal, the hook registration may have failed silently - the code logs the failure but keeps going, so the node can look alive while doing nothing. In that case force_run will still trigger a direct cleanup, which is your manual bypass.

Worth having? It's free, it's tiny, and on long queues it scratches a real itch. Just don't expect it to work miracles - it's a janitor, not a memory upgrade.