Ollama Running Models

Ollama Running Models answers one boring, essential question: what is actually sitting in your VRAM right now? It's the ollama ps command, exposed as a node. One input (a URL), two text outputs, no model downloads, no inference. This is the least glamorous node in the pack and, if you juggle Ollama models with diffusion, one of the most useful for debugging.

Here's why it matters. Ollama keeps a model resident in VRAM after a call for its keep-alive window - five minutes by default - so it's warm for the next request. But when you're running an LLM and a diffusion checkpoint on the same card, "warm" means "stealing VRAM from your sampler." A model you used once can sit there for five minutes while your image generation starts OOM-ing or falling back to slow partial offload, and you won't know why unless you check. This node is the check, and it doubles as a cheap diagnostic on any workflow that touches the Ollama server.

How it works

It calls client.ps() - the same data ollama ps prints in a terminal - and formats it. For each loaded model you get a line with the model name, how much VRAM it's holding (size_vram, shown in GB), and when it expires (its keep-alive deadline). The second output is the same list of names as a plain comma-separated string.

The inputs and outputs

• url - your Ollama server. Defaults to http://127.0.0.1:11434, which is the only input. Nothing else to set; this node is deliberately dumb.

Outputs:

• summary - one line per loaded model: name | VRAM: X.XX GB | expires: <timestamp>. If nothing's resident, you get "No models currently loaded in VRAM." If the server is unreachable, you get an error string starting with Error: - which, usefully, doesn't crash the graph.
• model_names - a comma-separated list of the loaded model names. This one's handy if you want to act on what's loaded, e.g. feed names into logic that decides whether to unload something.

What you'd actually do with it

The honest use is diagnosis, not a routine part of a happy path. You'd drop it in when VRAM behavior is suspicious - your render suddenly got slow, or Ollama and the sampler are fighting. See llama3.2 holding 4 GB with a 5-minute expiry? That's your thief.

To free it, this pack pairs it with Ollama Unload Model (or the auto-unload flag on the Connectivity node, which force-unloads after generation via a keep_alive=0 call - the only way to actually release VRAM). The two together give you a pattern: check what's loaded, drop what you don't need, keep your sampler's budget intact.

Install

Part of ComfyUI-OllamaOmni, same as the rest of the pack. ComfyUI Manager → search "OllamaOmni", or:

cd ComfyUI/custom_nodes
git clone https://github.com/ckinpdx/ComfyUI-OllamaOmni
pip install -r ComfyUI-OllamaOmni/requirements.txt

Restart ComfyUI. No model pulls, no extra deps beyond the single ollama package.

One thing to know: the node is only as fresh as the last time it ran. It's a snapshot, not a live monitor - re-run the workflow (or make it part of a debug group you trigger when something's wrong) to see current state. And like any node, it's arbitrary Python on import, so stick to the official repo and a quick skim of the source before you trust it in your default setup.