LLM Unload

Here's the problem it solves: you run Ollama, vLLM, or llama.cpp on the same GPU as ComfyUI, an LLM node generated your prompt text, and now the model is sitting in VRAM eating eight gigabytes that your diffusion model needs. LLM Unload exists to kick it out. It sends an unload signal to the LLM server - the separate process, not ComfyUI - and waits for the model to actually disappear from memory.

The name is a little misleading, so let's get that out of the way. It doesn't free ComfyUI's own GPU memory. It's an HTTP client that talks to whatever LLM server you already run and tells it to release a model. No model runs inside this node, no API key is required here, and if you're not running an external LLM server at all, it does nothing. It's a companion to the same pack's LLM Text Generator node, which is the thing that actually generates text - and which already has an "Unload After Gen" option for the auto version of this. Think of this node as the manual override you can drop anywhere in the graph.

How it works

Everything it needs comes from a config preset saved by the LLM Text Generator node (stored in presets/llm_text_generator_presets.json). Pick the preset, and it reads base_url, api_key, model, server_type, and unload_endpoint from it. It picks a server adapter by type - auto, openai, vllm, llama.cpp, or ollama - and sends the server-appropriate unload request: a keep_alive: 0 call to Ollama's /api/generate, a POST /models/unload for llama.cpp, a POST /v1/models/unload for vLLM. Hosted OpenAI has no unload endpoint, so there's nothing to send there.

The part that's actually well thought out: it sends the request synchronously, then polls /v1/models until the model name stops appearing in the list. Some servers (vLLM especially) acknowledge the unload immediately but finish releasing in the background. If the workflow plows ahead before that completes, your next node - the big model load - can OOM. The poll is bounded by a short timeout so the node never hangs your graph forever, and if a server doesn't expose /v1/models, it just times out and moves on. In auto mode, if probing failed and no request got built, it fires at every known endpoint as a fallback; the 404s are harmless. Errors are caught and logged, never fatal.

The inputs that matter

• Config Preset (config_select) - the one that matters. This decides which saved preset supplies the server address, key, and unload endpoint.
• Model Select / Model - the dropdown fills the free-text field. Leave the field empty and it unloads the preset's model; type or pick something else and it unloads that one instead.
• Any Input / Any Output - pure passthrough. Wire anything in and it comes out unchanged, which means you can insert the node mid-workflow without breaking the data flow, or just leave it unconnected. It runs either way.

Installing it

ComfyUI Manager, search "ComfyUI-zyd232-Nodes", or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/zyd232/ComfyUI-zyd232-Nodes.git

Restart ComfyUI and the nodes appear under the "zyd232 Nodes" category. The requirements.txt is just torch, numpy, and Pillow - all things ComfyUI already ships, so there's nothing extra to install. No model downloads, nothing heavy.

Gotchas

The author's own warning, and it's the real one: first confirm that the LLM Text Generator's "Unload After Gen" runs clean with your server. This node inherits that exact config, so if auto-unload is broken there, this will be broken here - the preset is the whole interface. If the preset is missing base_url or a model, the node logs a warning and passes through without doing anything. And remember the scope: it can only unload a model on a server reachable at the preset's base_url. If you're trying to reclaim ComfyUI's own VRAM for the diffusion model, that's the LLM Text Generator's clean_comfy_vram_before_gen side of things - a different job. Handy when it fits, genuinely a two-node chore to get there.