LLM Server Control

LLM Server Control is the off switch for Kinburg-Nodes' Local LLM Server - the node that keeps a chat model's VRAM under ComfyUI's control so one GPU can host both your SillyTavern-style chat and your image generation. It has almost no configuration of its own, generates nothing, and holds no prompt. What it does is give you an explicit, ordered moment where the loaded model is thrown out of VRAM.

You'd think that's trivially what "unload the model" means, but the ordering is the whole trick. ComfyUI runs a graph by walking backwards from output nodes and firing anything whose inputs changed - it does not promise to visit your nodes in canvas order. If the "free the LLM's VRAM" step runs after the sampler that needs that VRAM, you've done nothing. The Control node's fix is its passthrough input: an untyped * socket that takes any value and returns it unchanged. Wire anything at all through it - a seed, an image, a lazy string - and now the sampler downstream of that wire has a data dependency on this node, so ComfyUI is forced to run the unload before whatever the wire feeds. That's the mechanism, and it's worth knowing because it's easy to delete the passthrough wire and wonder why your VRAM is still full.

What it does

One required input, action, with four choices:

• free vram (unload the model) - the default. Kills the loaded model but keeps the gateway listening, so the next chat message just loads it again.
• load the model - pull it back now instead of waiting for the first request.
• stop the gateway - closes the port entirely, model and all.
• status only - no side effects, just report.

Under the hood it calls into the same gateway object Local LLM Server starts: stop the model, force a load, or shut the whole thing down, and its IS_CHANGED returns NaN so it always fires when the graph reaches it rather than getting cache-skipped. Outputs are passthrough (your wire, untouched) and status, a string you can pipe to a text preview to see what it actually did.

The setup you need first

Control is a control, not a server - it does nothing useful until Local LLM Server has run once in the same ComfyUI instance and started the gateway. The intended shape is a one-node workflow you queue once to boot the server, then little Control nodes dropped into every image workflow that shares the card. Drop Control into a workflow cold and its status output will tell you the gateway isn't there yet.

A few honest cautions, because the interplay is subtle:

• "free vram" here does not disarm the safety net. If you left free_on_prompt on in the Server node, any queued prompt that doesn't itself want the model up unloads it as it's queued - including image workflows you forgot to touch. A Control node set to free vram is just an early, redundant unload in those, and one set to load the model won't keep the net off either. The only graphs spared are ones that actually contain the Server node or a Control set to load/status.
• The passthrough wire is the point. If you're only reading the status, the node may run at a different point in the execution order than you assume. Pass something through it and the order is guaranteed.

Install and the shared pack

Same as the rest of the pack - clone into custom_nodes or install "Kinburg-Nodes" via ComfyUI Manager, then restart. It's the classic tiny but genuinely useful utility: nothing fancy to learn, but once you're running a local chat model on the same card as your diffusion, it's the difference between "image generation OOMs whenever I've been chatting" and a workflow that just works.