LMS Unload Model

LF_LMSUnloadModel has the strangest interface of anything in this pack, and once you see why, it's obvious. It takes a prompt as a required input and gives the same prompt back as its output. There's no trigger socket, no "execute now" checkbox. That's not laziness - it's the only way to sequence the thing.

Dropping an unload node on the canvas does nothing. ComfyUI executes what's connected to what it needs, not what's drawn. The prompt wire is the dependency: the unload can't run until the prompt exists, and anything downstream of the returned prompt can't run until the unload has finished. You get an ordering guarantee for free, using data flow instead of a control-flow hack.

That's the entire design, and it's the right one. The frame gets released before your video render starts hogging the card.

How it works

It takes the instance_id from LF_LMSLoadModel, hits the same LM Studio native API you gave the loader (it derives the unload route from the chat URL), and releases that exact instance - not "the LLM", not whatever's loaded, that one. That precision is why the loader bothers to return an ID at all.

The prompt you get back is unchanged, and it's only available after the unload has completed or the model has been confirmed already gone. So the wire itself is the handshake. If the unload errors, the downstream branch stops - which is the correct failure mode for "free VRAM before rendering".

Like the loader, it rechecks external residency on every queued execution rather than trusting ComfyUI's cache, since Comfy has no idea what's loaded in another process.

The inputs and outputs that matter

• prompt - the completed prompt, force-input. Typically from a prompt-writing LLM node. Required because it's the scheduling mechanism.
• instance_id - the exact ID from LMS Load Model, force-input. Same value that went to your prompt maker.
• url - must match the loader's URL, or you'll be asking a different server to release a model it's never heard of.
• timeout (optional, 120s default).

Output: prompt - the same string, unchanged. Wire it into your sampler, your H3 node, your save, whatever needs the LLM out of the way first.

The canonical wiring, from the pack's own docs:

LMS Load Model.instance_id -> Prompt Maker.model
LMS Load Model.instance_id -> LMS Unload Model.instance_id
Prompt Maker.prompt        -> LMS Unload Model.prompt
LMS Unload Model.prompt    -> downstream generation

How to install it

Same as the rest of the pack - ComfyUI Manager, search LF Nodes, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/lucafoscili/lf-nodes
python -m pip install -r lf-nodes/requirements.txt

Use ComfyUI's interpreter for the pip line. Note the archived-repo trap: lucafoscili/comfyui-lf is retired (October 2025), lf-nodes is the live repo - older tutorials still link the dead one. LM Studio itself is a separate install, and the node can't unload a model that isn't loaded.

Common issues & troubleshooting

The model stays loaded. Two likely causes. First, the node isn't actually on the prompt path - you drew it but didn't wire its output anywhere, so nothing depended on it. Second, your run failed or was cancelled upstream: the pack's own docs are explicit that a failed prompt-maker branch does not execute the downstream unload, so the writer can stay resident until you reuse or unload it by hand.

It released something you wanted kept. If your ComfyUI graph is the thing that loaded the model, an unload is fair game - including for an instance LM Studio had loaded before your run. Only use this node when this workflow owns that model's residency. If you're sharing an LM Studio instance with your editor, your notes app, or another person, don't put this in the graph.

It unloads too early. The order in the graph is the order of execution: every consumer of the model has to finish before the unload, and to guarantee that, each one needs to sit on the prompt path. A second LLM branch wired directly to the sampler, bypassing the unload, can still be running when the unload fires.

Timeout, but the model actually unloaded. Releasing a large model takes time while the server frees VRAM, and the request can time out after the server already did the work. Retry, or check LM Studio's inventory before assuming failure.

Nothing downstream runs at all. That's the design - an unload error stops that branch rather than letting the render proceed against a resident model. Fix the LM Studio side, then re-queue.