llama.cpp Unload Model

Load Model's mirror image, and just as precise. Unload Model takes one exact router model and removes it from memory - and waits until the router reports it in a terminal nonresident state before declaring success. It's the surgical version of VRAM management: it frees one model's weights without disturbing the other resident models or the router process itself.

The pack draws a careful line between three tools that all touch VRAM, and it's worth knowing which is which: Unload Model removes one exact model from a router; Release llama.cpp VRAM unloads all resident router models (or stops a direct server); Stop llama.cpp Server kills the whole process tree. Unload is the middle option - the one that says "drop just this one."

How it works

You pick the model, and the node tells the router to unload it, then polls until the model reaches a terminal unloaded state. success only goes true when that state is confirmed. Same contract as Load Model, inverted: HTTP acceptance isn't completion; the terminal state is.

The realistic use case is a workflow that needs different models at different stages. You ran a big 14B model to caption your dataset, and now you're switching to a small 3B for quick prompt rewriting - and you'd rather not have both sitting in VRAM. Sequence the unload after the big model's last generation, then load the small one, keeping models_max and your VRAM happy.

Inputs

• model_name - the exact model to unload, from the router catalog. As with Load Model, the "No models found" placeholder means the router has no catalog to draw from, and the tooltip's advice stands: confirm the authoritative ID with List Models.
• trigger - sequence the unload after the generation that needs the model finishes.
• operation_timeout - how long to wait for the terminal unloaded state.

Outputs: success (Boolean) and message (STRING with the result or failure detail).

Issues to expect

• Unloading a model that's mid-generation - the router won't unload a busy model; the node waits, so this becomes a timeout rather than a crash. Sequence it properly with trigger and it won't happen.
• Model already unloaded - reports success; a no-op.
• Router won't reach nonresident state - a hung router again means a hung node, the same determinism tradeoff as Load Model. Check Server Status before blaming the node.

The other way to empty the router entirely is Comfy's native Unload Models action, which the pack bridges into its own lifecycle coordinator - it unloads all resident models and keeps the router when the barriers succeed. Unload Model is the version where you get to choose which model goes.