Nodes/RocM Ninodes/ROCMSamplerCustomAdvancedBenchmark
ComfyUI Node

ROCMSamplerCustomAdvancedBenchmark

Stock vs. ROCm-optimized, side by side

By iGavroche·Created 11 months ago·Updated 4 days ago· 43
ROCMSamplerCustomAdvancedBenchmark
  • noise
  • guider
  • sampler
  • sigmas
  • latent_image
  • LATENT
  • BENCHMARK_REPORT

Here's the rare node that answers its own marketing question. The pack claims its SamplerCustomAdvanced drop-in is faster and friendlier to AMD memory than the stock one. This node is how you'd verify that on your own hardware: it runs the stock sampler and the ROCm-optimized one on identical inputs, then hands you a comparison report with timings and peak memory. No guessing, no trusting a README benchmark that ran on someone else's Strix Halo.

What it does

Same five inputs as SamplerCustomAdvanced - noise, guider, sampler, sigmas, latent_image - no extra knobs. It runs the stock path, then the ROCm path, on the same inputs. Two outputs:

  • LATENT - the result from the ROCm-optimized run, so you can just... use it. It's a working sampler too, not a pure test harness.
  • BENCHMARK_REPORT - a STRING with the comparison: stock time and peak memory, ROCm time and peak memory, speedup percentage, memory delta, step count, model type, and GPU name. Wire it to a Show Text node to read it.

The pack's docs show what the report looks like - a clean block like "Stock: 42.35s, 5840MB peak / ROCm: 41.12s, 5720MB peak / Speed: +3.0%". On a flow-matching video model with a big latent (LTX territory, memory factor 5.5x), that's exactly the comparison you want before you commit to swapping samplers in your main workflow.

The honest catch

Read the methodology before you treat a number as gospel. The two runs happen back-to-back on the same machine, which is good for control but means the second run benefits from warm caches - so expect a small inherent bias toward the second (ROCm) run. It's also one sample each, no repetition for variance, so treat single-digit speedup numbers as noise until you see the same direction twice. And it benchmarks the sampler node, not your whole workflow - VAE decode and loader costs aren't in the report. Still, for its actual question - "is the ROCm drop-in meaningfully faster on my card?" - it's the right tool, and on a genuinely AMD-tuned setup the memory-delta figure is often more interesting than the speed one.

Install

Ships in the ROCm Ninodes pack: ComfyUI Manager → search "ROCm Ninodes," or

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

Restart, under ROCm Ninodes → Sampling. Light deps (numpy, Pillow, psutil, gguf, safetensors), no model files. Works anywhere the pack's sampler works - a functioning ROCm PyTorch install.

The practical play

If you're on NVIDIA, this node is a curiosity at best (the ROCm path is a no-op there). On AMD, the smart move is: run it once on your heaviest video workflow, read the report, and let the numbers decide whether the ROCm SamplerCustomAdvanced earns a permanent place. If the speedup is in the noise but peak memory dropped meaningfully - which is this pack's more consistent claim - the swap is still worth it on a tight card. It doubles your generation time while testing (two full runs), so don't make it a habit; make it a one-time baseline. Same caution as every node in this pack: it's a niche tool for a niche platform, and the numbers it produces are datapoints about your machine, not verdicts about the pack.

CategoryROCm Ninodes/Sampling

Inputs (5)

NameTypeDefaultDescription
noiseNOISE
guiderGUIDER
samplerSAMPLER
sigmasSIGMAS
latent_imageLATENT

Outputs (2)

NameTypeDescription
LATENTLATENT
BENCHMARK_REPORTSTRING