ROCMSamplerPerformanceMonitor
A performance monitor that reads your model, not a benchmark
- model
- DEVICE_INFO
- PERFORMANCE_TIPS
- OPTIMAL_SETTINGS
The name oversells it a little. This node doesn't benchmark anything - it analyzes. You connect a loaded model, it inspects your GPU architecture and the model's type (flow-matching vs. standard, latent channels, memory footprint), and hands back three text reports telling you what sampler and settings to use. It's the pack's version of a wise old friend squinting at your setup and saying "euler, sgm_uniform, don't fight it." If you're new to AMD + ComfyUI and tired of copying NVIDIA-tuned settings that run like treacle on your card, that's genuinely worth having.
What it tells you
Two inputs: model (the MODEL object from your loader) and test_steps (default 20) - which is not a benchmark step count, just a hint the recommendations use. Three STRING outputs, each meant for a Show Text node:
- DEVICE_INFO - GPU, architecture, model device/dtype, sampling type, latent channels, and the model's memory factor.
- PERFORMANCE_TIPS - the model-type-aware advice. This is the useful one: for a flow-matching model (LTX, z-image, ideogram4-class) it recommends the euler/dpmpp_sde + sgm_uniform combo that those models actually want, which is not the same settings an SDXL tutorial will tell you.
- OPTIMAL_SETTINGS - architecture-aware recommended samplers, schedulers, and precision.
The node auto-detects a lot of this - the source reads the model's sampling type and latent channel count, detects whether you're on an APU (unified memory changes the advice), and tailors recommendations. It's the same detection logic the pack's samplers use, surfaced as plain text instead of buried in console logs.
The honest framing
Its value is as a decoder ring for your own hardware. The readouts demystify why a workflow is slow: it'll tell you "flow-matching model, high memory factor" and point at the right sampler family, which is more than most troubleshooting threads do in ten paragraphs. But it doesn't measure actual speeds, and it won't tell you which of two samplers is faster on your exact card. If you want real numbers, that's what the pack's Flux Benchmark node is for (with its caveats); this is for the "what should I be using" question.
Install
It 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, and it's under ROCm Ninodes → Sampling. Dependencies are the pack's light standard (numpy, Pillow, psutil, gguf, safetensors); no model downloads. Wire the three outputs to Show Text nodes and run once - the reports appear in the UI.
Where it fits
Honestly, it's a utility you run a few times, not a fixture. Keep it in a scratch workflow, read the DEVICE_INFO and TIPS outputs after you set up a new model, apply the recommended settings, then delete it. The one real trap: don't treat its "recommended" sampler list as binding - samplers are partly a taste thing, and the node is opinionated but not authoritative. And remember the pack's own bias: it's tuned and tested on gfx1151 / Strix Halo, so on other AMD chips treat the suggestions as a strong starting point rather than the final word.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | Model to analyze | |
| test_steps | INT | 201–100 | Number of test steps for benchmarking |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| DEVICE_INFO | STRING | — |
| PERFORMANCE_TIPS | STRING | — |
| OPTIMAL_SETTINGS | STRING | — |