Mpi Clear Vram End
The Node That Hands Your VRAM Back — Once the Branch Is Actually Done
- trigger
You know the ritual: a heavy generation finishes, you stare at the card, and the next run either works or dies with an out-of-memory error because the last model is still sitting in VRAM. ComfyUI caches models by default - speed beats RAM - and right-clicking "free VRAM" between prompts gets old fast. MpiClearVramEnd is the version of that right-click you can hang off the end of a graph and forget about. It offloads every loaded model from VRAM back to RAM, empties the GPU cache, and runs garbage collection, as a terminal node with no output. The models just reload themselves on the next run.
This comes from ComfyUi-MpiNodes by Mad Pony Interactive, the same shop behind the free, open-source Cubric Vision desktop app (which installs ComfyUI, the models, and this pack for you - if you found the pack through a Cubric workflow, that's where it lives). It's a 100+ node kitchen-sink utility pack, and it's pure Python on top of ComfyUI's own API: no model downloads, no compiled dependencies.
What makes this one different
Its sibling MpiClearVram does the same clearing but passes a value through, which means it has to be spliced into a branch - you have to move an existing link to insert it. That's annoying when you have three sinks (a latent, a decoded image, a decoded audio) and just want each branch cleaned up after itself. MpiClearVramEnd hangs off the end of a branch and changes nothing downstream, because there is no downstream. It's flagged as an output node, so ComfyUI treats it as a natural stopping point.
Under the hood it's exactly what you'd hope: gc.collect(), unload_all_models(), soft_empty_cache(), plus torch.cuda.empty_cache() and ipc_collect() when CUDA is present. Nothing clever, nothing fragile.
The one input that matters
There's a single input, and it isn't a value:
- trigger (
*, wire-only) - its tooltip says it all: "Connect the last value on the branch. Its only job is ordering: the clear runs once that branch is done." It's required and exists purely to place the node in execution order. An unconnected sink would run at an arbitrary point, and a VRAM clear must never run at an arbitrary point.
So you wire the last real output of a branch into it - a saved image, a decoded latent, or MpiSaveVideo's video_path output (which exists partly so a clear can be ordered after the mp4 actually exists, instead of costing time mid-export). It has no outputs, by design.
Install
Grab the pack once and you have both Mpi VRAM nodes:
- ComfyUI Manager: search "ComfyUi-MpiNodes" and install.
- Or manually, then restart ComfyUI:
cd ComfyUI/custom_nodes && git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes
No extra Python packages, no model files. Note the licence if you build on it: AGPL-3.0 from v1.2.7 onward (versions up to 1.2.6 are MIT).
Where people get burned
- One per terminal branch - not one per graph. A clear only runs on branches that actually execute. Hang a single one off the preview branch and every other branch leaves its models resident; you'll see
0 models unloadedin the log and the OOM shows up later in the graph, looking like a memory problem when it's a wiring one. - It doesn't make a card bigger. If you're OOMing during sampling, a post-branch clear won't save you - this is for freeing memory between heavy passes and long queues, not for shrinking a render that won't fit.
- Don't reach for it if you never need it. ComfyUI manages offloading between prompts on its own when it has to (and flags like
--lowvramchange that behaviour). If nothing is dying between runs, this node adds nothing but a branch to babysit. But on the day a 33B video model refuses to share the card with the next job, you'll be glad it's in your node list.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| trigger | * | Connect the last value on the branch. Its only job is ordering: the clear runs once that branch is done. |
Outputs (0)
No outputs