LMS Load Model

Here's a problem nobody warns you about when you put a local LLM in a ComfyUI graph: the LLM isn't ComfyUI's business. It lives in LM Studio, it holds VRAM whether or not you're generating, and if the model you want isn't loaded when the prompt node fires, you get a failure - or worse, LM Studio quietly loads it and now you're juggling memory with the diffusion model that's mid-sample.

LF_LMSLoadModel turns model residency into a graph step. You wire it in front of whatever needs the LLM, and the load happens in order, before the work that depends on it.

One thing up front: it does not download models. It loads a model you already have in LM Studio, by its exact key.

How it works

It hits LM Studio's native REST API rather than the OpenAI-compatible shim - you give it the chat URL (http://127.0.0.1:1234/api/v1/chat by default) and it derives the matching models/load route from it. Before loading, it checks what's already resident: if your requested key has exactly one loaded instance, it reuses that instead of loading a second copy. That's the behavior you want when you're queueing the same workflow five times.

It fails loudly on the cases that would otherwise be silent misbehaviour - multiple instances of that key, a key that isn't downloaded, or an embedding model (those go through a different LM Studio endpoint and aren't LLMs you can chat with).

If LM Studio requires auth, the transport reads LM_API_TOKEN or LM_API_TOKEN_FILE from the ComfyUI server environment. That's worth knowing because it's a server-side variable, not a node widget - the token never ends up saved in your workflow JSON.

The inputs and outputs that matter

Three inputs, and honestly one of them is the whole node:

• model - the exact downloaded model key as LM Studio names it. Not "Qwen3.5" - the full identifier. Get it from LM Studio's model list and paste it.
• url - the native chat endpoint. Must match the endpoint your prompt node uses.
• timeout (optional, 120s default) - loading a large model off a cold disk is not fast. Raise this before you conclude the node is broken.

Output: instance_id. It's a STRING and it's the point of the node - wire it to your prompt maker's model input, and to LF_LMSUnloadModel's instance_id so the release targets the exact instance that was loaded. Guessing at model names for the unload is how you end up unloading your diffusion model, or nothing.

The node also opts out of ComfyUI's input cache deliberately, so a queued run always re-checks actual residency on the server rather than trusting a cached "I already did this". External state isn't something Comfy's cache knows about, and the author handles that rather than letting you discover it.

How to install it

ComfyUI Manager → search LF Nodes → install → restart, or:

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

Pip with ComfyUI's interpreter. The pack's requirements include openai, requests and transformers, so the transport works out of the box; no local model files are needed on the ComfyUI side at all. And as with every node in this suite: lucafoscili/comfyui-lf is the archived predecessor repo, lf-nodes is current.

Separately, install and run LM Studio, download the model, and leave its server enabled. Nothing in ComfyUI can conjure the model.

Common issues & troubleshooting

"Multiple instances" error. You have the same model loaded more than once - usually because you clicked load twice, or you're running two workflows against one server. Unload the extras in LM Studio's UI, then re-run.

Fails on a model name that looks right. Model keys are exact, including quantization suffixes. Copy it out of LM Studio rather than typing it.

Timeout on the first run. Cold-loading a 30B model off an SSD can take a while. Bump timeout to 300 and try again before suspecting anything else.

Authentication errors. Set LM_API_TOKEN (or LM_API_TOKEN_FILE) in the environment of the process running ComfyUI and restart it. Editing the node won't help; the token isn't a widget.

It loads, then your generation OOMs. Expected if you're running a big LLM and a big diffusion model on one card. That's what the paired unload node exists for - and note the honest limitation there: a failed or cancelled prompt does not run the unload, so a crashed run can leave the writer resident. Reuse it on the next run, or unload by hand.

It doesn't download anything. Correct. Downloading is LM Studio's job.