Model Recall
The other half of the VRAM juggling act
- trigger_value
- model
- *
- *
If Model Offload is the "get this model out of VRAM" button, Model Recall is the "bring it back" button - and on its own it's the more interesting node. Same pack, same input structure, opposite direction: when it executes, it moves a model from CPU back to its preferred GPU device, so the next sampler finds it warmed up and ready.
You almost always see it paired with Offload around a memory-hungry section: offload after sampling, let a big VAE decode or a second model run, recall before the next generation. But there's a second, subtler use: delaying a load. ComfyUI's loader will happily pull a model into VRAM the moment the graph says it's needed. Recall lets you be the one who decides when - keep a giant transformer sitting on CPU through the cheap parts of your workflow, then force it back to cuda right before the KSampler that actually needs it. If you're running a 12GB-class model on an 8GB card, that kind of explicit timing is often the difference between working and a hard crash.
How it works
The node rescans the model you hand it, walks the same ModelPatcher / GGUFModelPatcher handling as its sibling, and moves weights to the target device. For patched models (the kind LoRAs ride on) it's careful: eject, unpatch, move, then re-patch - so your LoRA state survives the trip and isn't left half-applied. It then verifies the model actually landed where requested and logs if it didn't.
There's a tell in the source that this is a tool the author uses on himself: Recall runs a garbage-collector scan for "dangling clones" of GGUFModelPatcher before moving anything. That's a leak hunt - leftover references to a model can keep it pinned in VRAM even after you think it's gone, which is exactly the kind of thing that makes manual offload feel like it "doesn't work."
Inputs and outputs
- trigger_value (required, any type) - makes the node fire in sequence; passed through untouched.
- model (optional, any type) - the model to pull back onto the GPU.
- device (default
auto, choicesauto/cpu/your GPUs) -autosends it back to the device the loader originally chose. - enable (default on) - off makes it a pure passthrough, handy for comparing.
- on_error (
raise/ignore) - Nunchaku models always error here too; set toignoreif you don't care.
Outputs are two pass-throughs: the trigger value and the model, so the graph keeps flowing.
Install
Part of comfyui-better-flow - install once for the whole pack. Via ComfyUI Manager, search "comfyui-better-flow", or:
cd ComfyUI/custom_nodes
git clone https://github.com/lokinou/comfyui-better-flow.git
Restart ComfyUI completely afterwards. No extra pip installs - the pack is dependency-free, and there are no model files to download. If you still have the old comfyui-offload-models pack installed, delete it; the README calls it out because it only handled .safetensor models and will fight you for control.
Gotchas
Recall doesn't load a model that was never loaded - it moves an existing object. If your loader hasn't executed yet, you'll get a "not supported" path through the node. And recall on a model you just offloaded is instant win only if nothing else claimed the VRAM in between; if another node filled the card, the move can still succeed but you're back to fighting over headroom. That's the nature of manual VRAM management - the whole point is that you, not ComfyUI, are holding the steering wheel.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| trigger_value | * | — | |
| modelopt | * | — | |
| deviceopt | COMBO | auto | Select the device to recall the model to. |
| on_erroropt | COMBO | raise | What to do on error: ignore or raise an exception. |
| enableopt | BOOLEAN | true | Enable recall of the model to the preferred device. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| * | * | — |
| * | * | — |