VLM Runtime Diagnostics

Every custom-node pack fails the same way: something loads wrong, you paste the error, and the maintainer's first reply is "what's your environment?" VLM Runtime Diagnostics is the pack's pre-emptive answer to that - one node that dumps a complete, zero-download report of your runtime so you can skip the back-and-forth and file a useful bug report the first time.

gokayfem's README is blunt about it: "Run VLM Runtime Diagnostics before reporting a bug." This node is the pack's front door for support, and it's also genuinely useful as a plain sanity check when a node silently misbehaves.

How it works

It takes no inputs. Run it and it produces a JSON report covering: OS, Python version, PyTorch version, the active device and backend (CUDA / ROCm / Metal / XPU / CPU), dtype capability, and which optional packages are installed - including whether llama.cpp is present and what it reports for its own compiled backend, GPU-offload, mmap, and mlock capabilities. Zero network access, zero model downloads; it's pure introspection.

The node is marked as an output node, so its runtime_report STRING output is designed to be the end of a branch - wire it into any text viewer, or just read it in place. The report is JSON, which makes it trivial to paste into a GitHub issue in full.

Inputs and outputs

• Inputs: none.
• Output: runtime_report (STRING) - the JSON diagnostic.

Installing this pack

Same install as every node here. ComfyUI Manager: search VLM_nodes. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/gokayfem/ComfyUI_VLM_nodes
cd ComfyUI_VLM_nodes
python -m pip install -r requirements.txt

Run pip with ComfyUI's Python. Nothing downloads, no models involved.

Common issues

The typical mistake is running it after the fact, from a broken environment, and getting an incomplete picture. Diagnostics reflect the environment at run time - if you've already broken something (say, a pip conflict from another pack), run this before you touch anything, then fix, then run again to compare. The report is also where you'll see the useful distinction the pack draws between backends: it tells you whether your torch build actually supports the dtype path a model wants, which explains most "model won't load at bf16" mysteries. If you're reporting a bug, the report plus the exact node and error text is basically everything a maintainer needs.