ROCm Sampler Performance Monitor
A sampler settings adviser that reads your model first
- model
- DEVICE_INFO
- PERFORMANCE_TIPS
- OPTIMAL_SETTINGS
ROCm Sampler Performance Monitor is a text box that tells you what your sampler settings probably should be. It takes your MODEL, pokes at your GPU and your model's architecture, and returns three STRING outputs - device info, performance tips, and recommended settings - which you wire into Show Text nodes. That's the entire job, and it does it without running a single sampling step.
It lives in ROCm Ninodes/Sampling and is best understood as a settings adviser, not a benchmark. The name oversells the "performance monitor" part; nothing gets measured.
How it works
The node reuses the pack's shared detection utilities: detect_architecture() to figure out what GPU you're on (gfx1151/RDNA 3.5 APU, RDNA 3, RDNA 2, CDNA, or CPU), and detect_model_sampling_type() to classify the model you've wired in - flow-matching, pixel-space, standard eps, or v-prediction - along with its latent channels and memory factor.
From that it builds advice:
- DEVICE_INFO - architecture, APU mode, GPU name, model device/dtype, sampling type, latent channels, memory factor. A quick, honest snapshot of what's actually loaded.
- PERFORMANCE_TIPS - model-type-specific guidance. Flow-matching models get told to use euler/dpmpp_sde/dpmpp_2m with the sgm_uniform scheduler; pixel-space models get the reminder that no VAE decode is needed downstream; 128-channel latents get a "make sure you have enough memory" nudge.
- OPTIMAL_SETTINGS - architecture-aware recommendations: precision (fp16 for RDNA, bf16 for CDNA), recommended samplers, schedulers.
The test_steps input (default 20) is, per the README, "just for recommendations, not actual testing" - nothing is timed against it.
The inputs that matter
Just model and test_steps, and the latter barely matters. Wire model from your checkpoint or diffusion loader and read the outputs. If you have multiple models, swap them through to compare what the adviser recommends for a Flux checkpoint versus an LTX one - that contrast is genuinely instructive.
Installing it
Part of ROCm Ninodes - ComfyUI Manager, search rocm-ninodes, or:
cd ComfyUI/custom_nodes
git clone https://github.com/iGavroche/rocm-ninodes.git
then restart. v1.x upgraders run uv run python tools/upgrade_to_v2.py once. Dependencies are the pack's usual light set (numpy, Pillow, psutil, gguf, safetensors) on a ROCm PyTorch build.
The honest version
This node is at its best as a learning tool. If you've ever stared at a workflow someone posted for LTX and wondered why sgm_uniform keeps appearing, this node will tell you why - it reads the model and explains the choice. As a tuning tool it's shallower than it looks: the tips are rule-of-thumb heuristics baked into the code, not measurements from your machine, and the "optimal settings" are starting points you should feel free to ignore. The genuinely underrated output is DEVICE_INFO - it's the fastest way to confirm what ComfyUI thinks your hardware and model actually are, which is step one of half of all AMD debugging.
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 | — |