ROCMMemoryOptimizer

Here's a node with no inputs and three text outputs that exists to stop you running out of memory. It won't generate anything, it won't make your image prettier - but on an AMD card that keeps OOM-ing mid-workflow, it's the closest thing to a pressure-relief valve this pack ships. You drop it into your graph, wire its three STRING outputs to Show Text nodes so you can actually see what it reports, and let it tell you what your VRAM is doing and clean it up on a schedule.

How it works

The mechanism is boring on purpose, and that's a compliment. It reads current GPU memory stats (torch.cuda-style allocated/reserved/free numbers - on ROCm the same API works through the HIP backend), and then, on a cadence you set, it runs Python garbage collection and clears the GPU cache. That's it. No model surgery, no voodoo. What makes it useful is that you control when it acts:

• optimization_level - conservative, balanced (default), or aggressive. How hard it leans on cleanup between operations.
• enable_gc (default on) - Python garbage collection.
• clear_cache (default on) - empties the GPU memory cache.
• cleanup_frequency (default 10) - it only actually does the cleanup every N times the node runs, so it doesn't slow down every single graph step for the sake of one clean sweep.

The three outputs are MEMORY_STATUS (allocated/reserved/free/total), OPTIMIZATION_LOG (what it actually did), and RECOMMENDATIONS (suggestions based on what it saw). Connect all three to Show Text nodes and run the workflow; you'll see exactly where memory is going.

Where to put it

The README's suggested use cases are sensible: park it after a heavy operation to see memory pressure, use it inside a loop so each iteration starts clean, or check it before starting a big job so you know whether to bother. In practice the "check before a big job" use is the honest best one - the aggressive auto-cleaners in other packs can cause more fragmentation than they cure on mature ROCm drivers, and this pack's own philosophy (stated repeatedly in its loaders and samplers) is gentle cleanup. This node is the manual, visible version of that.

A real gotcha from the source: if torch.cuda reports nothing (CPU-only or a driver hiccup), you get "CUDA not available - no GPU memory to optimize" out of every output. On ROCm, torch.cuda still works (HIP mirrors the CUDA API), so that's usually a sign your PyTorch build isn't the ROCm one - a stack problem, not a node problem.

Install

It's part of the ROCm Ninodes pack, so one install covers it and the whole family: ComfyUI Manager → search "ROCm Ninodes," or

cd ComfyUI/custom_nodes
git clone https://github.com/iGavroche/rocm-ninodes.git

Restart and find it under ROCm Ninodes → Memory. Light dependencies (numpy, Pillow, psutil, gguf, safetensors), zero model downloads - a memory monitor doesn't need weights. The README also nudges you to set TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1 for mature ROCm drivers, and on Windows suggests the PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True,max_split_size_mb:512 environment variables for the notorious pagination error 1455.

The honest take

Is this node essential? No. On a stable ROCm setup with a properly sized model, you won't need it. But when a long WAN or LTX run keeps dying on OOM, a memory monitor that tells you where the pressure is beats randomly flipping settings. Treat it as a diagnostic you keep in a few workflows, not a permanent fixture in every graph - the pack's own samplers already do gentle cleanup internally, so this is for the cases where "internally" isn't enough.