Unload llama.cpp Models

Your GPU is running two full-time jobs, and one of them won't let go

Here's the situation that makes you google this node: you run a local LLM - an uncensored 8B prompt enhancer, a JoyCaption-style captioner, a Qwen worker - and you run ComfyUI, and they share one card. The LLM is what the VRAM-poor among us call "a problem." It loads into VRAM, generation finishes, and the weights sit there eating memory until the next diffusion job OOMs. The standing community fix is automatic unload/reload (thread 1r770u2), but if your LLM is an external llama.cpp server, nothing inside ComfyUI could reach over and tell it to drop its weights.

This node is that missing remote control. Unload llama.cpp Models talks to a running llama.cpp server's HTTP API and tells it to unload every loaded model, freeing their VRAM for your image gen. That's the whole job, and it does it well.

How it actually works

First, the reassuring part: the name is a slight lie in your favor. This node doesn't call any cloud API, needs no key, and doesn't touch ComfyUI's own models - it's a plain HTTP client to your llama.cpp server. It GETs /models, picks out every model whose status is loaded, and POSTs to /models/unload with {"model": "<id>"} for each. Those are the exact endpoints llama-server exposes, so anything recent with its HTTP API enabled works.

Two details from the source are worth knowing. It sets a verify=False on requests (fine for a local HTTP server, irrelevant once you point it at 127.0.0.1). And it fakes a unique input fingerprint every run, which forces the node to actually execute each time instead of being cached as a no-op output node. A new pack doing that right is a good sign.

The inputs and outputs that matter

There are only two inputs, and you'll set both once:

• llama_api - the base URL of your llama.cpp server. The default is http://host.docker.internal:8081, which is the Docker-host alias: it works if llama.cpp runs in a container (or on the host, with ComfyUI in Docker). If you run llama.cpp as a plain local process, point this at http://127.0.0.1:8081 (or whatever --port you gave it).
• exclude_models - multiline list of model IDs to skip, one per line or comma-separated. Handy when you keep a small model resident on purpose and only want the big one evicted.

Outputs: success (Boolean, true even when nothing was loaded, false on error) and result (String, a per-model 'model' → OK summary that also shows as inline preview text in the node). Wire result into a text display if you want the report visible in your saved workflow.

Installing it

One tiny dependency (requests), no model downloads - this is the easy kind of install:

cd ComfyUI/custom_nodes
git clone https://github.com/schroldgames/ComfyUI-llamacpp-Unloader.git
cd ComfyUI-llamacpp-Unloader
pip install -r requirements.txt

Or skip all that: ComfyUI Manager → search ComfyUI-llamacpp-Unloader → Install → restart. Note it's built against ComfyUI's newer nodes API, so keep ComfyUI itself reasonably current or the node won't register.

The gotcha that will bite you

ComfyUI doesn't guarantee execution order between parallel branches. Wire this node anywhere and it may fire before your generation, unloading the LLM you just wanted to use. The README's fix is the correct one: drop a Reroute into the graph, run your generation chain's last node into it, and run the Reroute into this node. That forces the unload to happen after generation finishes. You're using a "legibility" node as an ordering constraint, which is not what it's for, but it's the standard trick and it works.

Other traps: an unreachable server returns success: false with a message instead of crashing the workflow (good behavior - check result before you trust the unload happened), and since llama.cpp serves without auth by default, don't expose that port past localhost if it's the only thing keeping your machine from OOMing.

When to reach for it

If your LLM runs as a separate llama.cpp server and you share one card between chat and diffusion, this is the node you'd want in your API workflow - the external-server pattern that most local-LLM ComfyUI users end up on. If you run your GGUF through an in-graph loader instead, it manages its own VRAM and this node is pointless. Know which pattern you're on, and this becomes a genuinely useful 15 minutes of setup.