Nodes/ComfyUI-Free-GPU/Free GPU Memory
ComfyUI Node

Free GPU Memory

A manual VRAM/RAM flush you can wire into your graph

By CY-CHENYUE·Created about a year ago·Updated about a year ago· 22
Free GPU Memory
  • anything
  • status
clear_cachetrue
clear_modelstrue
protocolhttp
api_host127.0.0.1
api_port8188

If you've ever chained a big SDXL or Flux pass into a Wan video pass in the same ComfyUI session and watched your VRAM slowly fill up until something OOMs, this node is aimed squarely at you. It releases GPU and CPU memory, unloads whatever models ComfyUI is holding onto, and clears the execution cache - a manual "clean slate" button you can drop right into your workflow graph.

Worth saying up front: ComfyUI's own memory management is already pretty automatic - it swaps models in and out reasonably well on its own - so most of the time you don't need this. Where it earns its keep is the messier cases: a workflow that loads several large checkpoints back to back, switching between wildly different model families in one session, or a long-running batch where VRAM creeps up and never quite comes back down. And when this node showed up on r/comfyui, the top reply was basically "there's already like three nodes that do this" - fair, it's a crowded little niche (ComfyUI itself even has a built-in "Unload Models and Execution Cache" hotkey buried in Settings). What this pack adds over the hotkey is that it's a node: you can wire it into automated pipelines so the flush happens at a specific point in the graph, not just when you remember to mash a keyboard shortcut.

How it actually works

This is the part worth understanding, because it explains every input on the node. Under the hood it doesn't do anything exotic - it just fires an HTTP call to your own running ComfyUI server's built-in /free management endpoint, the same route the native Manager UI uses. clear_cache and clear_models map straight onto that endpoint's free_memory and unload_models flags. protocol, api_host, and api_port exist purely so the node knows where to send that request - defaults of http / 127.0.0.1 / 8188 cover the vast majority of local installs, and you'd only touch them if you're running ComfyUI on a nonstandard port, in Docker, or behind a reverse proxy.

The inputs and outputs that matter

  • anything (required, accepts basically any type - STRING, IMAGE, LATENT, MODEL, VAE, CLIP, CONDITIONING) - this isn't data the node actually uses. It's a wildcard passthrough whose only job is to force execution order. Wire your pipeline's last real output into it - your final SaveImage's image, say - so ComfyUI's dependency graph won't let this node fire until that step is actually done. Skip this and, since the node is also flagged as an output node (always runs, output or no), you risk it firing too early, before the memory you actually want freed is even in use.
  • clear_cache / clear_models (both booleans, default True) - the two switches you'll actually think about. Leave both on for a full flush; the pack doesn't really give you a reason to run a partial one.

The single output is status, a string report of what the /free call did. There's nothing downstream to wire it into - it's there to read in the console/log, not to feed another node.

Installing it

Easiest path: open ComfyUI Manager, search ComfyUI-Free-GPU, install, restart. Manually, it's the usual clone-and-restart with no extra dependencies or model downloads:

cd ComfyUI/custom_nodes
git clone https://github.com/CY-CHENYUE/ComfyUI-Free-GPU

Where people get burned

The author's own FAQ nails the two complaints you'll actually run into. First: VRAM doesn't drop as much as expected after running it. That's normal - some memory is reserved by the system or other processes and a soft free won't touch it; a full ComfyUI restart is the only guaranteed reset. Second: the next run after a flush feels sluggish. Also normal - you just told it to drop the loaded models, so the following queue has to reload them from disk before it can generate anything. That's the trade you're making, not a bug. Because of that reload cost, don't wire this after every single generation - use it between distinct batches of work, or when you're deliberately switching model families, not as a per-run habit.

CategoryFree-Gpu

Inputs (6)

NameTypeDefaultDescription
anythingSTRING,IMAGE,LATENT,MODEL,VAE,CLIP,CONDITIONING
clear_cacheBOOLEANtrue
clear_modelsBOOLEANtrue
protocolCOMBOhttp2 options: http, https
api_hostSTRING127.0.0.1
api_portINT81881–65535

Outputs (1)

NameTypeDescription
statusSTRING