Unload Model · Tank

A 27B vision-language model is a wonderful thing to have in the graph right up until your sampler needs the VRAM back. Unload Model · Tank is four lines of intent: hand it the backend, it releases the model and tells you it did. No settings worth arguing about, no clever options. It's the least interesting node in TankNodes and the one that keeps you out of an out-of-memory error halfway through a batch.

The problem it solves is a real one. Once Qwen3.8 has loaded, that memory is yours to lose - and ComfyUI's own cache doesn't know your VLM exists, so it will happily leave it resident while you queue twenty generations. This is the VRAM-budgeting tax the KB keeps pointing at: an LLM in the graph doesn't replace your diffusion model, it shares a card with it. If you only ever chat and stop, ignore this node. If your workflow continues into image generation after the model has answered, you want it.

How to use it

Two inputs. backend is required - connect the same VISION_LLM_BACKEND you sent to the chat node. after is optional but is the entire point of the node: connect the chat's response (or raw_response) into it. That connection isn't decorative. It's the execution edge that makes the unload wait until the chat has actually finished; without it the unload has no reason to run after anything in particular, and the model just gets reloaded on the next chat anyway.

Wire it like this:

Qwen38VLLoader.backend ──┬──> VisionChat.backend
                         └──> VisionUnload.backend
VisionChat.response ──────────> VisionUnload.after
VisionUnload.status ──────────> (Show Text, or just leave it)

The single output is status, a human-readable string, and the node is an output node, so the result also shows up as text on the node itself. "Model released · Tank" means it worked. The node deliberately re-executes on every queue - releasing a cached model is a side effect, and the pack marks it as always-changed so a second run actually unloads instead of being skipped by ComfyUI's caching. That's the correct behaviour and it's worth knowing, because it means the node never appears to "do nothing" on a repeat run.

Install

It ships with the pack: ComfyUI Manager → search Tank (registry ID qwen38-vl), or clone into ComfyUI/custom_nodes and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/xzbdqian10nian/ComfyUI-TankNodes.git

No extra dependencies - and no llama-cpp-python requirement of its own, though the backend it unloads will only load if you have a CUDA build. The node lands under TankNodes/Local, next to the loader and the chat node.

Two easier alternatives, honestly

• unload_after on Local Multimodal Chat · Tank - a checkbox that does the same thing at the end of that chat. If your graph is "chat, then generate," this is simpler and you can skip this node entirely.
• free_comfy_vram on the loader - the opposite direction: it unloads your diffusion models before the VLM loads, so the models don't fight during load. Enable both if your card is tight and you're alternating between chatting and generating.

Where the separate node wins is ordering across a longer graph: you decide exactly which chat triggers the release, and you can unload before a heavy stage (upscaling, a video sampler) without giving up the option to keep the model loaded for the earlier part of the run.

When it looks like it did nothing

If the backend is an API backend, there's nothing to release - no weights ever touched your GPU, so the unload is a no-op and you shouldn't expect a VRAM delta. That's the expected result, not a failure.

For a local model, check nvidia-smi before and after rather than trusting vibes; ComfyUI's own memory reporting won't show you what the VLM was holding. And note the pack already does some of this for you: loading a different local config unloads the previous local model automatically, and the loader's __del__ path releases when the backend object goes away. This node exists for the case where you want it to happen now, on purpose, in a specific spot in the graph.

There are no common errors specific to this node - it doesn't touch files, VRAM knobs or network. It either has a local backend to release or it doesn't.