ComfyUI on AMD ROCm: What Works, What Doesn't

The honest answer to "does ComfyUI run on AMD" changed in the last few months, and most of what you'll find searching for it is stale. AMD now publishes an official ComfyUI Docker image built for ROCm, which didn't exist a year ago when the community was building install scripts by hand. That's real progress. It doesn't mean every custom node, every attention backend, or every torch.compile path behaves the same as it does on CUDA — and pretending otherwise on a 192GB MI300X box is a bad way to lose an afternoon. Here's what I could verify, checked August 20, 2026.

TL;DR: PyTorch ships official stable wheels for ROCm 7.2, and AMD's compatibility matrix explicitly lists MI300X (gfx942) as supported on that line. AMD now maintains an official rocm/comfyui Docker image and install docs. What doesn't carry over cleanly: torch.compile's reduce-overhead mode (CUDAGraph-based) is broken on ROCm, xformers ROCm support is community/experimental rather than official, and there's a currently-open ComfyUI issue where an NVIDIA-only module hard-crashes AMD installs on a specific recent commit. Test your actual node graph before you commit to a long-running job.

What's officially supported

PyTorch. Current stable PyTorch wheels are published for ROCm 7.2 (pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm7.2), with nightlies also tracking newer ROCm builds. AMD's own ROCm compatibility matrix (current line: ROCm 7.14.0, dated July 16, 2026) explicitly lists AMD Instinct MI300X (gfx942) as supported, alongside MI300A and MI325X, across Ubuntu 24.04/26.04, RHEL 9/10, Debian 13, and SLES 15.7. If your MI300X box runs one of those, you're on a documented, first-class configuration.

ComfyUI. ComfyUI's own README documents the AMD install path directly — install the ROCm PyTorch wheels above, then ComfyUI itself. More significantly, AMD now maintains its own official ComfyUI-on-ROCm documentation at rocm.docs.amd.com's ComfyUI project pages, targeting ROCm 7.2.0/7.1.0 and explicitly listing MI300X, MI325X, and MI355X as supported hardware. The recommended path is AMD's published Docker image:

docker pull rocm/comfyui:comfyui-0.18.2.amd0_rocm7.2.0_ubuntu24.04
docker run -it --privileged --rm \
  --device=/dev/kfd --device=/dev/dri \
  --group-add video --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined --ipc=host \
  -p 8188:8188 rocm/comfyui:comfyui-0.18.2.amd0_rocm7.2.0_ubuntu24.04

This is a meaningfully different situation than a year ago, when the only route was a community-maintained install script and a lot of trial and error. An AMD-badged, versioned image with a documented install path is a real signal that the vendor is investing here, not just tolerating it.

What's a real cost or a live risk

torch.compile on ROCm has a known broken mode. torch.compile itself works, but its reduce-overhead mode relies on CUDAGraph capture, which is reported broken on ROCm — some users report slowdowns of tens of times or outright hangs when it's enabled. Use the default compile mode instead of reduce-overhead until you've confirmed otherwise on your specific ROCm/PyTorch build. torch.distributed support is also reported as incomplete on ROCm, which can matter if a custom node or an accelerate-based pipeline reaches for multi-GPU distribution code paths — verify this against your own stack rather than assuming CUDA parity, since I found this from a single community source and couldn't cross-confirm it against a second first-party one.

xformers is not an official ROCm deliverable. Community analysis as of 2026 classifies xformers' ROCm support as experimental, and getting it working typically means pinning an older release and applying patches rather than a clean pip install. If a custom node hard-depends on xformers for memory-efficient attention, check that dependency specifically before assuming it'll just work.

flash-attention on ROCm is a community fork, not an AMD product. ROCm/flash-attention is hosted under the ROCm GitHub organization but is a fork of Dao-AILab's original repo, not a first-party AMD deliverable in the way the ComfyUI image is. It documents support for MI300X via its Composable Kernel backend (with a Triton backend as an alternative), and requires ROCm 6.0+. Separately, Dao-AILab/flash-attention#1269 reports a build failure specifically on MI300X (gfx942) under ROCm 6.2.2 — I could not confirm whether that specific issue is resolved on current ROCm 7.x, so treat it as a "check before you build from source" flag rather than a settled fact either way.

There's a currently open ComfyUI/AMD-breaking issue. Comfy-Org/ComfyUI#13182 reports a regression on AMD GPUs introduced by a commit that hard-imports a module (comfy_aimdo) that's NVIDIA-only, producing a ModuleNotFoundError on AMD installs. As of this writing it's open and unresolved. If you're pulling ComfyUI from source rather than AMD's pinned Docker image, this is exactly the kind of breakage that a moving main branch can introduce between the day you read this post and the day you deploy — pin to a known-working commit or use AMD's versioned image rather than tracking main.

Custom nodes: no blanket answer. I could not find a reliable, current source cataloguing which popular custom-node packs (ControlNet, IPAdapter, AnimateDiff, and the rest) work on ROCm out of the box versus which break. Don't take silence on this as a green light — the honest position is that this is untested territory per-node, and the fastest way to find out is to load your actual workflow on a rented box before committing to a longer run.

What this means in practice

If your ComfyUI workflow is a standard SDXL or Flux pipeline using the AMD-maintained Docker image and stock attention (not xformers, not a custom torch.compile mode), you're on the best-supported path that's existed for AMD so far. If your workflow leans on xformers for memory efficiency, a specific flash-attention build, or a custom node you haven't tested on ROCm, budget time to verify it rather than assume CUDA parity — and do that verification on an hourly rental before you commit to anything longer.

GPU monitoring on AMD boxes

If you're renting MI300X for any serious workload, being able to actually see GPU utilization, memory, temperature, and power while a job runs matters — and this is worth being specific about, because AMD monitoring has historically been the kind of thing that silently doesn't work. On Aquanode's own infrastructure, GPU vendor detection is done by probing the actual hardware (kernel device nodes / PCI vendor ID) rather than trusting whether an nvidia-smi-named binary happens to be on the box's PATH — a real failure mode on some AMD hosts that ship a stub NVIDIA tool for compatibility reasons. Metrics on AMD boxes are collected through ROCm-SMI (utilization, memory use, temperature, power, clocks), the same way NVIDIA boxes use DCGM. This is current, shipped behavior in our monitoring agent, not a roadmap item.

When the extra setup work is worth it

Rent the MI300X and use AMD's official image when you need the 192GB for a model that doesn't fit comfortably on an H100, or when the H100/H200 supply in your region is tight and MI300X capacity is available now. Budget real verification time — not zero, not a rewrite — when your pipeline is built around xformers, a specific flash-attention build, or custom nodes you haven't tested on ROCm.

And whichever GPU you land on, the setup itself — the pinned PyTorch/ROCm versions, the working custom-node set, the models already on disk — is worth protecting once you've built it. We cover the general version of that problem in restoring a ComfyUI Manager setup on a new box and running ComfyUI on any cloud GPU. For the hardware and pricing side of the MI300X decision, see renting an MI300X, and for how it actually performs on inference workloads, MI300X vs H100 vs H200.

FAQ

Does ComfyUI officially support AMD GPUs now? Yes, more directly than it used to. AMD maintains its own ComfyUI-on-ROCm documentation and a versioned Docker image (rocm/comfyui) targeting ROCm 7.1/7.2, explicitly listing MI300X as supported hardware.

Does PyTorch support the MI300X? Yes. Stable PyTorch wheels are published for ROCm 7.2, and AMD's compatibility matrix lists MI300X (gfx942) as supported on that ROCm line.

Does xformers work on ROCm? Only as an experimental, community-maintained path — not an official AMD deliverable. If a custom node depends on it, verify separately rather than assuming it installs cleanly.

Is flash-attention available on ROCm? A community fork exists under the ROCm GitHub organization with MI300X support via its Composable Kernel backend, but it's not a first-party AMD product, and at least one build-failure issue has been reported specifically on MI300X. Check the current status against your ROCm version before building from source.

Can I monitor GPU utilization and temperature on an AMD box? Yes, on Aquanode's boxes, current AMD monitoring runs through ROCm-SMI and reports the same utilization/memory/temperature/power metrics DCGM reports on NVIDIA hardware, with hardware-based vendor detection rather than a PATH-based check.

What's the biggest current gotcha? An open ComfyUI GitHub issue where a recent commit hard-imports an NVIDIA-only module and breaks AMD installs pulling from main. Use AMD's pinned Docker image rather than tracking the latest commit if you want to avoid that class of breakage.

Sources

• AMD ROCm compatibility matrix, checked August 20, 2026. ROCm 7.14.0 line; MI300X (gfx942), MI300A, MI325X listed as supported.
• AMD ComfyUI-on-ROCm install docs, checked August 20, 2026. rocm/comfyui Docker image, ROCm 7.1.0/7.2.0, MI300X/MI325X/MI355X.
• ComfyUI GitHub repo, checked August 20, 2026. AMD install instructions via ROCm PyTorch wheels.
• Comfy-Org/ComfyUI#13182, checked August 20, 2026 — open, unresolved AMD-breaking regression.
• ROCm/flash-attention, checked August 20, 2026 — community fork, Composable Kernel backend, MI300X support documented.
• Dao-AILab/flash-attention#1269 — MI300X (gfx942) build failure report under ROCm 6.2.2, resolution status on current ROCm not confirmed.