Nodes/ControlFlowUtils/❌ Unload Models
ComfyUI Node

❌ Unload Models

Kick models out of VRAM when ComfyUI won't

By VykosX·Created 2 years ago·Updated 2 years ago· 147
❌ Unload Models
  • Passthrough
  • Output
ForceUnloadfalse

❌ Unload Models is the cleanup crew for your VRAM. You drop it into a workflow, it evicts every loaded model from memory, and anything you pass through it comes out the other side untouched. ComfyUI's automatic memory management is genuinely good most of the time - but "most of the time" is doing a lot of work in that sentence, and the failure modes are ugly: models paging into shared memory and grinding generation to a crawl, or an out-of-memory error on a workflow that should fit.

This node exists for those failures and for one very specific, very common setup: workflows that use different models at different stages and don't need them resident at the same time. Think Flux for a first pass, then something else for the next. If both stay pinned in VRAM, you're either OOM or you're paying for offloading you didn't ask for. Unload Models lets you say, "done with that stage - clear it, now."

How it works

The node is a passthrough with a lever. Its Passthrough input (any type) gets forwarded to Output after the cleanup, so you can chain it mid-workflow without breaking your data flow. The behavior depends on ForceUnload:

  • Off (default) - "request" mode. The node sends a message to the frontend that does exactly what clicking Unload Models in ComfyUI's menu does: it hits the /free API endpoint with unload_models: true. ComfyUI handles the unloading at its convenience. Gentle, safe, mostly invisible.
  • On - "force" mode. The node calls ComfyUI's memory manager directly - unload_all_models() plus a soft cache empty. Models are gone now, synchronously, before your workflow continues.

That distinction matters. Forced unloading is aggressive and can break things if a pending node still needs the model you just evicted - the model will just be reloaded, but a half-queued operation can error out. Request mode is the polite version and is what you'll want 90% of the time. The README frames this exactly: force it when you're paging to shared memory and need the VRAM right now; request it otherwise.

The inputs

  • Passthrough (required, *) - the data to forward. If you have nothing to forward, wire in a Null Output so the node still runs in the right spot.
  • ForceUnload (required, BOOLEAN, default False) - instant vs. on-demand, as above.
  • Output: Output (*) - your passthrough data, after cleanup.

That's the whole surface. It's a tiny node; the skill is placement.

Where it actually helps

The community has effectively road-tested this for you. In a r/comfyui thread about a batch workflow that kept running out of memory, the working recipe people landed on was Unload Models followed immediately by the pack's Garbage Collector, run back to back - one user confirmed "that combo works" after trying half a dozen VRAM-clearing nodes from other packs. Same thread's pattern: someone wanted models released on a timer, and the answer was this node paired with the pack's Wait (Delay Execution) node.

One honest caveat from that same discussion: this clears the models, not ComfyUI's execution cache. If your problem is stale cached results, you want ComfyUI's own "Clear Cache" / execution cache function, not this node. And no, you shouldn't slap it into every workflow - unloading costs you a reload on the next use, so in a single-model linear workflow it's pure overhead. Reach for it when models would otherwise coexist, or when you can see generation speed collapse from shared-memory paging.

Install and gotchas

No dependencies beyond the pack - it's pure Python plus a small frontend hook:

cd ComfyUI/custom_nodes
git clone https://github.com/VykosX/ControlFlowUtils

or ComfyUI Manager → search ControlFlowUtils → install → restart.

Two things to keep in your head. First, when the pack's own README talks about memory tools, it pairs this with the Garbage Collector for RAM exhaustion and points out that VRAM issues are this node's job - if you're OOM on system RAM, this isn't the node you want alone. Second, the pack is early-alpha (v0.0.6) and these flow-control tools are where most of the rough edges live; test the node's placement in a copy of your workflow before running a long overnight batch on it.

Category🐺 VykosX-ControlFlowUtils

Inputs (2)

NameTypeDefaultDescription
Passthrough*Data to forward to other nodes after cleaning the VRAM
ForceUnloadBOOLEANfalseSpecifies how the models should be unloaded. Instantly or On-Demand

Outputs (1)

NameTypeDescription
Output*Data that will be forwarded to other nodes after cleaning the VRAM