🌐 V2 Remote Vision Model Config

Every remote workflow in this pack starts here. V2 Remote Vision Model Config is the node that says "my vision model lives at this address, speaks this protocol, and answers to this name" - and hands that whole bundle to the analysis nodes as a single REMOTE_VISION_MODEL connection. It's a config node, not a runner: it does nothing on its own, but without it, Remote Vision Analysis and the task runners have nothing to talk to.

The "remote" is doing a lot of work, so let's be clear about what it means. This pack's remote mode is OpenAI-compatible protocol, not necessarily a cloud service. The default base_url is http://127.0.0.1:1234 - that's LM Studio on your own machine. The README's whole remote story is "run a local server, point this node at it." No API key required for local servers. This is genuinely the friendlier path for beginners: you get a GUI (LM Studio) managing GGUF models, and ComfyUI just talks to it.

The inputs that matter

• base_url - the server address. Default http://127.0.0.1:1234 (LM Studio), with Ollama on 11434 and Nexa SDK on 8080 noted in the tooltip.
• api_type - LM Studio, Ollama, Nexa SDK, or OpenAI Compatible. All four speak the same OpenAI-compatible format; this just tweaks how the pack builds requests and pings for the model list.
• model - the actual model name served by that server. This is a dropdown with a 🔄 Refresh Models button: the node asks your running server what it has loaded, so the list populates from reality, not from a static file. You must have the server running and the model loaded before you refresh, or the list will be empty.
• system_prompt - optional. Defaults to a "describe images accurately and in detail" assistant persona. Override it when you want the model to behave differently (e.g., a strict JSON-only persona) - and note that this system prompt flows into every downstream analysis, so it's a powerful lever for consistency.

How it works

On configure, the node pings the base_url, maps your api_type to an internal engine key (lmstudio/ollama/nexa/openai), and - here's the nice part - checks whether the service is actually reachable. If it is, the returned config carries service_available: true, which the runners check before they even attempt a request. A dead server produces a clean "service unavailable" message downstream instead of a stack trace. The refresh of the model list is a real request to the server's /v1/models-style endpoint, so a stale list means a stale server state - hit refresh after loading a model.

The one gotcha

The model dropdown is not a free-text field - it's populated by the refresh. If the list is empty, it's because the server wasn't up or didn't report models. This trips people up constantly: they start LM Studio, forget to load a model (or forget to start the server), refresh, see nothing, and assume the node is broken. Load a model in LM Studio/Ollama first, then refresh.

Install

Same as the whole pack:

cd ComfyUI/custom_nodes
git clone https://github.com/walke2019/ComfyUI-GGUF-VLM.git
cd ComfyUI-GGUF-VLM
pip install -r requirements.txt

Restart ComfyUI. It's under GGUF-VLM → v2 → Remote. Only needs requests, which requirements.txt installs.

Troubleshooting

"Service unavailable" means the ping failed - check the port, check the server is actually serving (LM Studio needs the server started, not just the app open), and check for firewall issues on Windows. Empty model list means refresh before you trust it. And if your analysis comes back weird, suspect the system prompt here before anything else: it's silently injected into every downstream request, and a leftover aggressive persona will fight your task prompts.