LLM Config (Step 1 & 3)

The Chat (Ollama) node is happy out of the box, but "out of the box" means exactly one thing: local Ollama at http://127.0.0.1:11434 with a model called llama3. The moment you want a different model, a different provider, a temperature that isn't the default, or a cloud API instead of your own GPU - that's what LLM Config is for. It's the pack's control panel, and it's the node that makes "Chat (Ollama)" a bad name for the family.

It's also the node you'll barely look at after you set it up, which is the point.

What it does (and doesn't)

LLM Config is a pure pass-through: it takes a pile of settings and hands them back as a single LLM_CONFIG struct. No network calls happen here, nothing is executed. You wire its one output (llm_config) into the Chat node's llm_config input, and the Chat node reads everything - provider, model, url, sampling, keys - from the struct. When it's connected, the Chat node's own base_url and model_name widgets grey out, because the config now owns them. One config node can drive several Chat nodes, which is the real reason to use it instead of retyping the same base_url into every chat node.

The fields that actually matter

Nine inputs, and which ones you touch depends entirely on provider:

• provider - the six-way switch: ollama, huggingface, openai, deepseek, qwen, claude. Pick your backend first; the rest of the config is provider-specific.
• base_url - defaults to http://127.0.0.1:11434 for Ollama. For OpenAI-compatible providers (including DeepSeek and Qwen) it points at their /chat/completions endpoint; for Claude it's the /v1/messages base.
• model_name - the model id for whatever provider you chose. llama3 is the default.
• temperature (default 0.5, capped at 1.0 here) and top_p (default 0.9) - the sampling dials, passed through to every provider.
• max_new_tokens (default 256, up to 8192) - how long a reply can be. On Ollama this becomes num_predict under the hood.
• hf_token - required for most Hugging Face models, because the HF Inference API still gates most public models behind a token.
• hf_api_url - an optional override if you're running your own inference endpoint instead of api-inference.huggingface.co.
• api_key - the bearer key for OpenAI-compatible and Claude providers.

The rule of thumb worth remembering: Ollama → base_url + model_name. Cloud → base_url + api_key + model_name. HF → model_name + hf_token (and if a model refuses to cooperate, check that you actually set a token - the README is explicit that many public models need one).

Gotchas worth knowing

The keys are the catch. api_key and hf_token are plain-text widgets, which means they get saved into your workflow JSON. Don't share that workflow file with a live key in it - strip it first, or stick to an Ollama-only setup. Second, because this is a pass-through with no validation, a wrong base_url fails at the Chat node, not here; the error shows up as a [chat error] line in your transcript. Third, temperature is hard-capped at 1.0 by the widget, so if you're one of those people who runs 1.2 for creative work, this node will politely refuse.

Install

Same pack as the other two: ComfyUI Manager → search ComfyUI_LLM_Embeder, or git clone https://github.com/RCAKangle/ComfyUI_LLM_Embeder into ComfyUI/custom_nodes/ and restart. No requirements.txt, no extra pip installs - the pack only uses requests, which ComfyUI already has. If new fields don't appear after an update, restart ComfyUI and re-add the node.

Verdict

A boring config node, and that's a compliment. It's the piece that turns a one-provider toy into a real chat backend for your prompt chain, and it keeps provider details out of your workflow graph. Set it once, wire it to every Chat node, forget it exists.