Nodes/ComfyUI_EmAySee_CustomNodes/EmAySee Model VRAM Tracker
ComfyUI Node

EmAySee Model VRAM Tracker

Ask ComfyUI what models are actually sitting in VRAM right now

By EmAySee·Created about a year ago·Updated 4 months ago· 2
EmAySee Model VRAM Tracker
  • anything
  • model_list
  • debug_dump
  • count

EmAySee Model VRAM Tracker is a diagnostic node: it asks ComfyUI what models are currently loaded in VRAM and reports back. You plug anything into it - the input is a wildcard, so any wire works - and it walks ComfyUI's list of currently-loaded models, extracts whatever identifying info it can, and hands you three outputs: a plain list, a full debug dump, and a count.

Who needs this? People who've ever hit the "out of memory, but I only have one model loaded... or do I?" moment. ComfyUI keeps unloaded models around in its cache, and with a big workflow running a checkpoint, a VAE, an IP-Adapter, and a ControlNet, the question "what is eating my VRAM" is genuinely hard to answer from the outside. This node answers it mid-graph. Drop it in, run, and read the list. It's the kind of node you keep around for debugging sessions rather than leave in a production workflow - and that's fine, diagnostic tools don't need to earn their place in the final graph.

How it works

It reads comfy.model_management.current_loaded_models directly - the same internal list the memory manager uses - and for each entry tries to figure out a name. It checks a handful of common attributes on the model object (model_name, name, architecture, sam_model, and so on), falls back to the config class name, then the inner model class, then the wrapper class, in that order. So you'll get something like UNETModel or a checkpoint's config name when the attribute hunt fails, and an actual friendly name when it succeeds.

Beyond the list, the debug_dump output is a full JSON dump per model - class names, wrapper, inner model, model config, and every simple attribute it could read. That's the "I need to know more than the name" escape hatch. And count is just the number of loaded models, which is handy for a conditional or a display.

Three return values worth memorizing:

  • model_list - a STRING, one model name per line. This is the one you'll read.
  • debug_dump - a STRING, verbose JSON per model. Only when you need detail.
  • count - an INT, how many models were in the list.

If nothing is loaded, you get the strings "No models in VRAM" and "VRAM Empty" and a count of 0, rather than a crash.

Installing it

Part of the EmAySee pack:

# ComfyUI Manager: search "ComfyUI_EmAySee_CustomNodes" and install
# or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes

Restart ComfyUI. No requirements.txt - it only needs the comfy internals already present in ComfyUI.

Common issues

The honest caveat: this node reads a private ComfyUI internal (current_loaded_models), which is exactly the kind of API that changes between versions. It works today, and it's a small enough read that the risk is limited, but if a ComfyUI update ever breaks it, that's why. Also, it reports what ComfyUI's cache thinks is loaded - the "loaded" state doesn't always match free-VRAM numbers you'd get from nvidia-smi, because the cache holds things it could evict at any moment. If you want actual GPU memory accounting, pair this with a proper VRAM monitor; this node answers "which models," not "how many gigabytes."

CategoryEmAySee/Utils

Inputs (1)

NameTypeDefaultDescription
anything*

Outputs (3)

NameTypeDescription
model_listSTRING
debug_dumpSTRING
countINT