ROCm Flux Benchmark

ROCm Flux Benchmark promises a "comprehensive Flux workflow benchmark for AMD GPUs." Worth knowing before you queue it up: despite the name, the shipped code doesn't run a Flux diffusion pass. It generates a random latent at each test resolution and times the VAE decode - so what you're actually benchmarking is how fast your box turns latents into pixels. That's a useful number, just not the number the name suggests. Don't read the results as "how fast does Flux generate."

It lives in ROCm Ninodes/Benchmark, and like the other monitor nodes it's a text box, not a visual one: all four outputs are strings you wire into Show Text nodes to actually see anything.

How it works

The node takes your loaded MODEL, VAE and CLIP, parses a comma-separated list of resolutions (256x320,512x512,1024x1024 by default) and CFG values, then for each combination it makes a 1×4×H/8×W/8 random tensor and calls vae.decode() on it, recording wall time and peak memory. Since decode doesn't depend on CFG at all, the test_cfg_values list effectively just repeats the same decode with a different label - a few extra data points, not a real CFG sweep. test_steps is accepted but never used in the loop, because nothing is being sampled. The README is at least upfront that "it will decode test latents and measure performance," which is exactly what happens.

At the end it also hands you a hardcoded list of recommendations that flips on whether you're on an AMD device: fp32 precision and Euler/Heun samplers if you are, fp16/bf16 and DPM++ 2M if you aren't. Treat those as starting points, not gospel - they're baked into the code, not measured from your run.

Inputs that matter

• test_resolutions - the only input worth editing. Keep 1024x1024 in the list; that's the resolution where decode memory really shows.
• test_steps / test_cfg_values - defaults are fine, and as noted, steps don't do anything here.
• test_hipblas (on) and generate_report (on) - accepted, but the shipped code doesn't branch on them in a way you'll notice.

Reading the outputs

Wire each output to a Show Text node:

• BENCHMARK_RESULTS - per-resolution average decode time and peak GB.
• PERFORMANCE_CHART - the raw timing list per resolution.
• OPTIMIZATION_RECOMMENDATIONS - the baked-in tips above.
• MEMORY_ANALYSIS - total VRAM and current usage.

A healthy decode of 1024×1024 is a couple of seconds; if that number is alarming, your VAE or your ROCm stack is the problem, not your sampler.

Installing it

Part of the ROCm Ninodes pack - install via ComfyUI Manager (search rocm-ninodes) or:

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

then restart. If upgrading from v1.x, run uv run python tools/upgrade_to_v2.py once first. Dependencies are numpy, Pillow, psutil, gguf and safetensors; the real prerequisite is a ROCm PyTorch build (the README covers the gfx1151 nightly install).

The honest version

This is a decode-throughput and memory probe wearing a "workflow benchmark" label, and it's still worth a run - VAE decode is a real bottleneck on AMD APUs, and the per-resolution peak-memory column tells you where your ceiling is before you blow through it on a real job. Just calibrate expectations: it measures the tail of the pipeline, not Flux itself.