ComfyUI-AMDMonitor

VRAM monitoring, crash early-warning and per-run analytics for AMD / ROCm GPUs in ComfyUI — the numbers NVML-based monitors can never show you.

MITNo extra installs AMD / ROCmWindows & Linuxv…
Install Source Registry

Why NVML monitors show nothing

It isn't that the data is missing. It's that nobody was reading it.

Crystools and most resource monitors read GPU statistics through pynvml, NVIDIA's management library. There is no AMD equivalent to fall back on, so on a Radeon card the GPU section simply stays empty — CPU and RAM, nothing else.

But ComfyUI's own /system_stats endpoint reports AMD VRAM correctly, because it goes through PyTorch's HIP backend rather than NVML. Every ComfyUI crash report on an AMD machine already contains it:

Name: cuda:0 AMD Radeon RX 9070 XT
VRAM Total: 17095983104
VRAM Free:  16937648128

This extension displays what was always there — and then goes considerably further.

What it does

A draggable, resizable panel with 21 independently switchable rows.

Panel at idle Panel during a run Panel under load

VRAM per GPU

Works on ROCm, multi-GPU aware. Integrated GPUs hidden by default — their “VRAM” is shared system RAM and reads 100% for reasons unrelated to ComfyUI.

Peak VRAM per run

The high-water mark, colour-coded, reset at the start of every job. The number that predicts a crash.

VRAM graph

A sparkline of the run with guides at the warning thresholds — load spikes and decode plateaus become visible.

Partial-load warning

Watches ComfyUI's own log and warns the instant a model loads partially, which on ROCm is the last thing you see before the process aborts.

Alerts survive crashes

Critical warnings are written to disk and shown again after a restart — the explanation outlives the crash it was warning about.

Progress + ETA

Step k of n with a live estimate, plus the name of the node currently executing.

Time by node

A measured breakdown of where a run's time actually went, so a slow generation points at its own bottleneck.

Run history

Model, LoRAs, size, sampler, steps, seed, outputs, errors, load state and peak usage — persisted, exportable as CSV.

System vitals

Swap, CPU, output-disk free space and disk/network throughput, via psutil.

Peak VRAM: the number that matters

On a card without headroom, ComfyUI doesn't fail politely.

A model that doesn't fit gets partially offloaded to system RAM, and ROCm then aborts the entire process:

loaded partially; 9008.59 MB usable, 8420.02 MB loaded, 8896.00 MB offloaded
Fatal Python error: Aborted

No traceback. No out-of-memory error. ComfyUI simply dies. Watching the peak tells you a workflow is unsafe before it takes the process down.

Bar colourPeakMeaning
green< 80%comfortable
amber80–92%tight; a larger model or resolution won't fit
red ⚠> 92%offload risk — expect a crash

Measured on a 16 GB RX 9070 XT

ModelSizeLoadResult
Krea212.5 GBcompletelyworks
Z-Image Turbo11.7 GBcompletelyworks
Flux2 Klein fp88.78 GBcompletely4.6 s/step
Flux2 Klein bf1616.9 GBpartiallyaborts
The margin is tighter than you'd think. Across repeated runs of the same 16.9 GB model, the process survived at 7200 MB offloaded and aborted at 7553 MB and 8100 MB. A few hundred megabytes decides it — which is exactly why clearing VRAM appears to “sometimes fix” the problem.
ComfyUI reserves more than you expect. On that card usable consistently reports 9.8–10.6 GB, never the full 15.9 GB. The difference is headroom for activations. The practical weight budget is roughly 10 GB, not the sticker figure.

Where did the time go?

Measured from ComfyUI's node transitions — never inferred from log text.

Every run records a breakdown. Click any row in H → Runs to see it:

SamplerCustomAdvanced       6:58   89%
RemoteTextEncoderSwitch      28s    6%
UNETLoader                   11s    2%
VAEDecode                     8s    2%
SaveImage                     1s    0%

Nodes that execute more than once are summed and marked ×2. Seconds-per-step is reported as a median, so a single stall doesn't distort the figure. Timings are the one thing that has to be trustworthy, so they are measured rather than parsed.

Install

ComfyUI Manager

Search for AMD Monitor and install, or:

comfy node install comfyui-amdmonitor

Manual

cd ComfyUI/custom_nodes
git clone https://github.com/the-Macro-Man/ComfyUI-AMDMonitor

Restart ComfyUI. A panel appears top-right — drag it anywhere, drag its right edge to resize, click to collapse. Position, width and every setting persist.

Notifications need permission. Click the gear once and your browser will ask — permission can only be requested from a click, so it won't prompt on its own. Test Alert confirms sound and permissions.

Data, and where it goes

Nothing leaves your machine.

What it reads

SourceProvides
/system_statsVRAM per device, system RAM
websocket eventsprogress, node transitions, queue, run start/end
/queuethe executing node's real name, run settings
/internal/logs/rawpartial-load and OOM detection
/amdmonitor/statsswap, CPU, disk, network — via psutil

What it writes

Run records and per-run logs go to ComfyUI/user/amdmonitor/ — never the extension folder, which ComfyUI Manager replaces on update:

user/amdmonitor/
  runs.csv                                one row per run
  runs/2026-08-24_1147_<promptid>.json    full record
  runs/2026-08-24_1147_<promptid>.log     ComfyUI's log for that run
  alerts.log

The log is appended as the run progresses and flushed every line. That is the whole point: when ROCm aborts there is no clean shutdown, so anything buffered is lost. Writing as it happens leaves a file ending at the exact moment things went wrong.

The last 50 runs are kept; older ones are pruned. One toggle disables disk writing entirely, and history still works in the browser.

No telemetry, ever. Nothing is sent anywhere. The only network calls are to ComfyUI's own endpoints on localhost.

Explained errors & AI analysis

Explained errors shipped v1.5.0

ComfyUI's errors are precise and unhelpful. A built-in pattern table turns the common ones into plain English, using the context already recorded for that run — no network, no configuration, works for everyone:

RuntimeError: mat1 and mat2 shapes cannot be multiplied (512x30720 and 12288x4096)

becomes

Text encoder doesn't match the model. Your encoder produced Krea2 conditioning (30720 features per token), but the model expects flux2 (12288). Set the text encoder to flux2.

AI run analysis shipped v1.5.0

An optional layer over a local Ollama endpoint, or an API provider such as OpenRouter. It interprets the measurements — it never produces them:

Open H → Runs and expand any row:

ButtonWhereWhat it does
Analyse this runexpanded row, successful runs where the time went, memory- or compute-bound
Explain this failureexpanded row, failed runs the cause in plain language, and the fix
Compare with previousexpanded row, when another run of the same model exists what changed and what it cost
Session summarybottom of the Runs tab trends, grouped per model, failures excluded
ProviderEndpointKey
Ollama (local / LAN)http://192.168.1.182:11434none
LM Studiohttp://localhost:1234/v1none
OpenRouterhttps://openrouter.ai/api/v1required
OpenAIhttps://api.openai.com/v1required

Sent: model, size, steps, sampler, LoRAs, durations, per-node timings, peak VRAM and RAM, load state, and the error if there was one — plus up to six previous successful runs of the same model. Prompt text is excluded unless you opt in. The API key is stored server-side and never reaches the browser.

Off by default, and explicit about what it sends. There is no bundled endpoint and no default key. Prompt text is excluded unless you opt in. Local endpoints keep everything on your own network; a remote provider does not, and the interface says so before each call.