🎲 LLM Server Config

Every node in the LLM Wildcard Manager pack needs to talk to a language model, and none of them want to be told three times where it is. LLM Server Config is the single knob panel: you set up the backend here once, wire its one server output into the Manager and the Resolver, and you're done. It never calls the model itself - it just builds a LLM_SERVER bundle that the other nodes read.

The name is a small lie in your favor: "server config" doesn't mean this node runs a server. It points at one that already exists. If that concept is new, the short version is that an LLM in the graph is a separate thing from the LLM encoder baked into your checkpoint - it's a tool you bolted on, running on your own GPU or through an API (llm-in-comfyui.md). This node is the address book for that tool.

What you actually set

Four fields carry the real work, plus one master switch:

• backend - one of ollama, llamacpp, or openai_compatible. Defaults to ollama, which is the right place to start if you don't already have an API habit.
• endpoint - where the model speaks HTTP. Ollama wants http://localhost:11434. A llama.cpp server wants http://localhost:8080/v1. For openai_compatible - OpenAI, LM Studio, vLLM, OpenRouter - point it at the base URL ending in /v1 and it just works.
• model - llama3.1 by default. Any model you've pulled into Ollama, or whatever your OpenAI-compatible provider names. llama.cpp lets you leave it blank.
• api_key - blank for local backends, required for hosted ones.
• temperature - 0.9 default. Leave it alone until you have a reason; the Manager and Resolver pass it straight through to every LLM call.
• llm_enabled - the interesting one, a master switch. Flip it OFF and the whole pipeline runs without the LLM server: the Manager reuses its last generated template and the Resolver fills wildcards only from what's already on disk. That's a genuinely useful trick when you want to batch-render with your server stopped, or just to check the wildcard files are healthy.

The one gotcha that bites everyone

If ComfyUI runs in Docker and your model server runs in Docker too, localhost inside the ComfyUI container points at itself, not at the other container. The README's fix: use http://host.docker.internal:8080/v1 (Docker Desktop, or Linux with --add-host=host.docker.internal:host-gateway), or put both on a shared user-defined network and use the container name.

A quick sanity check from your terminal before you fight the node at all:

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"local-model","messages":[{"role":"user","content":"say hi"}]}'

If that returns JSON with choices[0].message.content, the pack will work. If it hangs or 404s, fix the server before touching ComfyUI - the nodes are just an HTTP client, so a working curl is a working node.

Installing it

Same story as the whole pack: ComfyUI Manager, search LLM Wildcard Manager, install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/pclshm/comfyui-llm-wildcard-manager

Restart ComfyUI and the nodes land under prompt → wildcards. No Python dependencies - the pack uses only the stdlib urllib, and there's no model to download because the model lives in your Ollama/llama.cpp/API. One heads-up: version 0.3 reorganized the pack, so if you're upgrading from 0.2.x the old LLMWildcardPromptConfig node is gone and saved workflows need re-wiring. The starter workflow in example_workflows/llm_wildcard_basic.json is the fastest way back.

The usual LLM-node caution applies (comfyui-ecosystem.md): a custom node is arbitrary Python with full OS access, so install from the actual repo, not a fork. Beyond that, this is one of the least surprising nodes in the pack - it doesn't even make a network call on its own.