Local LLM Settings

Here's the situation this node exists for. You have a Local LLM Generate node doing a job, and you want a different model or a tighter temperature for one branch of the workflow. Without this node you'd go into the server panel and change global settings, which breaks every other node. With it, the workflow owns its own LLM configuration and carries it down a single wire.

That's the pattern our plumbing notes call a context object - one bundle travelling one connection instead of a dozen values dragged across the canvas. LOCAL_LLM_SETTINGS is the type. Generate and Prompt Enhancer both accept it, and neither one wants more than one of them.

How it works

The node exposes the pack's complete runtime surface as widgets, then build() freezes the relevant subset into a dict and hands it downstream. Consuming nodes treat it as request-local overrides: model, sampler, vision limits and memory knobs all travel with the wire.

The one thing it deliberately does not carry is the seed, which stays on the consuming node so Control After Generate keeps behaving normally. If you're hunting for a seed widget here, it isn't there.

Settings come from one of three places, chosen by settings_preset: Current Server (whatever the LLM side panel is set to right now, re-read live), Custom, or a saved Complete Settings Preset from ComfyUI/models/LLM/local_LLM_presets/settings/. A complete preset bundles model + mmproj + model behaviour + sampling + memory/KV/offload/speculative config, and intentionally excludes API keys, startup mode and logging.

Note the direction of travel: this node can load presets, never create or delete them. Preset creation lives only in the server panel's Presets tab, so a shared workflow can't mutate your preset library.

The inputs you'll actually set

There are a lot of widgets here, and most of them you'll leave alone.

settings_preset first, every time. Pick Current Server to inherit the panel config, or load a saved preset. Now the small print: editing any field flips this to Custom, and with a named preset loaded, the preset file is authoritative for its own fields. Change one value and you've left the preset - expected, just don't be confused when the dropdown doesn't say what you picked.

model and vision_model - the GGUF and its mmproj. vision_model defaults to None/Auto (matching mmproj); leave it auto unless you've got several projectors in ComfyUI/models/llm and it guesses wrong.

model_preset is a big dropdown of per-family behaviour - thinking and non-thinking flavours of Qwen3.x, GPT-OSS 20B, a generic chat entry, and Auto (Detected). It applies sampling and chat-template behaviour only and deliberately does not touch max_tokens. If your output is full of leaked thinking tags, this is the dial that fixes it, not the temperature.

Then the standard sampler set: temperature (0.7), top_p (0.9), top_k (40), min_p, repeat_penalty, presence_penalty / frequency_penalty. Leave these alone until a specific job misbehaves - a prompt rewriter wants low temperature, a brainstorm wants higher.

The memory half is where the real decisions are: context_size (32768 default, and the KV cache scales with it), kv_cache_k / kv_cache_v (q8_0 / q5_0 - a real VRAM lever at a small quality cost), kv_cache_location, gpu_layers (-1 meaning as many as fit), flash_attention, the two batch sizes, use_mmap / use_mlock, and vram_policy. On a box that also runs diffusion or video, Auto Yield to ComfyUI is the pick.

Vision limits sit between the two: vision_max_images (4), vision_max_frames (24), vision_max_edge (1536). These aren't just performance caps - the video-planner nodes error rather than silently hide references that exceed them, so a too-low limit is a visible failure, not a quiet one.

There's also a speculative-decoding block (speculative_mode, off by default, with ngram_*/mtp_* tuning) and a multi-GPU set (split_mode, main_gpu, tensor_split) that defaults to one card. Ignore both on a single GPU.

The output, and the trap

One output: settings, which goes into the settings input on Local LLM Generate or Local LLM Prompt Enhancer.

The trap is the generic cost of context objects: when config travels as one opaque bundle, what's inside it becomes invisible. The plumbing notes put it well - with forty wires you can see the LoRA output isn't feeding the sampler; with one bus you can't, because the connection is there and the contents are wrong. So if a Generate node behaves like it's using the wrong model, expand the Settings node and read its widgets before hunting elsewhere.

One thing that works better than you'd expect: change tracking. IS_CHANGED follows the live server config under Current Server, and the preset file's modification time when a named preset is selected. Edit the preset in the panel and downstream nodes re-run - no reselecting required.

Installing it

Same pack, same install - nothing extra for this node:

cd ComfyUI/custom_nodes
git clone https://github.com/Solid-Code/ComfyUI-Local-GGUF-LLM
pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cu124

The second line is on you, not the pack: requirements.txt deliberately installs nothing, so a Manager-run pip install can't replace your GPU build with a CPU-only wheel. Models go under ComfyUI/models/llm/, then start the model from the LLM side panel.

And the honest recommendation: most people don't need this node. If you run one LLM configuration, leave settings disconnected on Generate - it uses the live server config, and you've skipped a node and a class of stale-config bugs. Reach for Local LLM Settings when two workflows need different models, or when a shared workflow should carry its config instead of depending on the recipient's panel.