The scope of this repository is to document how to run Comfy UI with ROCm acceleration with a AMD 7900XTX under Windows.
Nvidia and CUDA works better. But Nvidia makes you pay a significant premium for VRAM, and VRAM is critical to machine learning.
When choosing how to upgrade in 2025-01 my choices were
- AMD 7900XTX 24GB: 940€
- Nvidia 3090 24GB 4 years old used: 750€
- Nvidia 4090 24GB: 2500 €
- Nvidia 5090 32GB: 3500 €
In my region the 7900XTX still goes for 850€ to 950€ at the time of update 2025-12-09, and in my opinion this is amazing value to accelerate ComfyUI generation and local LLMs.
16GB cards are more affordable, but those 8GB extra go a long way in inference.
- AMD RX 7900 XTX 24GB <--- The GOAT
- Intel 13700F
- DDR5 4x16GB 64GB 6400 CL32
ComfyUI has a portable release ROCm 7.1.
Building it pip works better for me, as I can build with ROCm 7.2. Read the script and what it does.
The achille's heel of AMD card, is the stack. It's bad. As of ROCm has windows binaries for pytorch that works to an extent with decent performance with ComfyUI.
AMD ROCm is Linux first, and barely even works under windows.
ROCm barely even works, if you have access to Vulkan accelerated runtimes they work a lot better, it'll be often faster than the ROCm runtimes because the Adrenaline team knows what they are doing and are windows first.
The first Windows binaries were released in 2026-01-25, before that, windows required WSL to do Linux emulation of the drivers with passthrough and catastrophic penalties
First windows binaries in Driver 26.1.1 Make sure you install Pytorch option in the AI tab of adrenaline.
To underscore how incompetent and unfit for duty ROCm is, my new Intel laptop with 358H and B390 with LPCAMM2 100GB/s can pull 1/3 of the speed of my 7900XTX ROCm, despite having 1/9 of compute and bandwidth. It's an humiliating difference, especially considering Intel is much newer to the whole AI stack, and it has much more competent binaries and painless installation.
Multiple times I regret not spending 4X the price to get a Nvidia card that would just work painlessly.
You CAN get models to accelerate. Some things will work out of the box, if they are older, and the binaries happens to accelerate them vaguely well. It's just you need to be prepared for the Linux experience of having to be a degree of developer to get it to work. it is Linux first, and this include the typical Linux thing of having a deep understanding of the underlying substrate to get it to work.
ROCm does not and cannot handle memory properly, you need to test and add mitigations to get it to run twice in a row 2026-07-26 testing
ROCm is useless at Conv3D, which makes a big difference on the VAE Decode stages. An operation that is nearly instant under CUDA, will take time and crash the driver for OOM without proper flags
--windows-standalone-build core flag to make ROCm work
--disable-api-nodes remove the useless node that need cloud APIs to work
--enable-dynamic-vram weird interaction with ROCm, on big models cause timeouts
--enable-manager core flag to enable the manager. can omit it to load somewhat faster
--use-pytorch-cross-attention ??? I think it's not needed as it's already inside
--disable-smart-memory Important, ComfyUI crashes on repeated executions without it
Before 2026, AMD didn't even have pytorch binaries for windows.
It was barely possible to run ComfyUI using WSL Linux emulation, it took months of effort to configure it.
Zluda had a fork to do a translation layer that lost half performance on top of ROCm and AMD performance losses.
It was incredibly brittle, with extreme limitations. I advise against using it.
In 2026-01-25 released the first binaries for pytorch. They are bad, lots of primitives still crash the drivers and are incredibly slow, lots of optimization and libraries aren't there, and never will be. But it's possible to build a pytorch environment that gets something running at some performance
This installation requires:
- setting up a UV Python
- installing the PIP ROCm packages
- the ComfyUI dependencies
At some point AMD took ComfyUI somewhat more seriously, and contributes to make a portable version.
This is fairly easy to run, download the zip, expand it, and run the scripts and it will start and diffuse.
You still need to do some work to install the manager, and add extensions to the scripts since the defaults will make the driver crash if you vaguely push it. ROCm is still brittle and incompetently made it needs care to run without crashing the driver or run multiple times.
It is convenient to move the models outside the ComfyUI folder, so that when I rebuild, the models are all there. This also allows multiple local env to all access models without duplication.
It is convenient to remap checkpoints, diffusion_models and unet to a single folder, and clip, text_encoders to clip, so you don't need to find what folders the node needs.
extra_model_paths.yaml
comfyui:
# Go up to the parent folder, and look for the model folder there
base_path: ..\..\ComfyUI-Models
# Model Folder
checkpoints: models\
clip: clip\
clip_vision: clip_vision\
text_encoders: clip\
configs: configs\
controlnet: controlnet\
diffusion_models: models\
embeddings: embeddings\
loras: loras\
upscale_models: upscale_models\
vae: vae\
background_removal: background_removal\
unet: models\
# custom vibevoice node dumps here
vibevoice: vibevoice\Have two scripts, one to launch ComfyUI without manager, one with.
The manager lets you install missing nodes and look for nodes conveniently
Follow the instruction in the appropriate readme to make the two scripts that will launch ComfyUI with the performance flags and manager
Diffusion have two dimensions, first the model, then the type of workflow
Think of VAE as image compression, it's an auto encoder.
The VAE encode will translate a RGB(A) image into a latent image.
The VAE decode will reverse translate a latent image into RGB(A).
VAE can be fine tuned to have different color palette, or resolve the latents with more or less sharpness and so on.
The diffusion model works on the latent image, some models may have separated diffusion and refiner stages.
Model that takes care of translating text into latent coordinates
This is the simplest workflow.
It works by having a CLIP translate a text into a latent coordinates.
After that, a ksampler will load the diffusion model, take an empty latent image, and diffuse using the coordinates as guidance
The resulting latent image is reverse translated into RGB by the VAE decode stage
CLIP models can reverse translate image into a description of the image
Newer models just use LLMs like Qwen 3 VL
It is possible to feed input images to diffusion and have them be modified, images can be fed at several points in the pipeline
You feed an input image through a VAE Encode
The model starts from the existing latent image, and will diffuse through a new image. Denoise controls how much of the original image is preserved.
Stronger models use LLM that support input images in the toikenizer stage.
You feed the image to the CLIP
Some models support control nets, that allow to guide the diffusion according to a control net
- control net depth: feed a depth map of the image
- control net pose: feed poses, the model will try to diffuse characters complying with the pose
VAE Decode stage is hideously bugged under ROCm Windows on the 7900XTX. This is a convenient workflow to test it and debug which flags can let you run it at all.
It's a small model native to ComfyUI now, doesn't need third party packages
It's a workflow to upscale and split an image in four tiles and remerge the tiles. It's meant to allow diffusion models to do diffusion upscale.
| MODEL | SIZE |
|---|---|
| qwen_3_4b.safetensors | |
| Zimage Q4 GGUF | |
| ae.safetensors |
| MODEL | CLIP | VAE | First Load [s] | Second Repeat [s] | Third Change Prompt [s] |
|---|---|---|---|---|---|
| Q4 GGUF | Q4 GGUF | SAFETENSOR | 30s | 16s | 18s |
| INT8 CONVROT SAFETENSOR | INT8 CONVROT SAFETENSOR | SAFETENSOR | N.A. | N.A. | N.A. |
Editing models are great at complying with editing instructions.
Qwen Edit 2511 Relies on an older Qwen 2.5 LLM as CLIP
| FP32 Saferensor | BF16 Safetensor | INT8 SAFETENSOR | Q8 GGUF | Q4 GGUF | |
|---|---|---|---|---|---|
| Diffusion Model | Qwen Image Edit 2511 | ||||
| Turbo Lora | 4 Step Turbo Lora BF16 | ||||
| CLIP | Qwen 2.5 VL 7B | Qwen 2.5 V -7B | |||
| VAE | Qwen Image VAE |
.jpg)
| FP32 Saferensor | BF16 Safetensor | FP8 Saferensor | INT8 Safetensor | Q8 GGUF | Q2 GGUF | |
|---|---|---|---|---|---|---|
| Model | . | . | Krea Turbo FP8 12.8 GB | . | . | Krea 2 Turbo 4.55 GB |
| CLIP | . | . | Qwen 3 VL 4B 5.1 GB | . | . | . |
| VAE | Wan 2.1 VAE 508 MB | Qwen Image VAE 254 MB | . | . | . | . |
- txt2img:
- clip-img2img
.jpg)
| FP32 Safetensor | BF16 Safetensor | FP8 Saferensor | INT8 Safetensor | Q8 GGUF | Q4 GGUF | |
|---|---|---|---|---|---|---|
| CLIP | . | . | Qwen3VL 8B (10.4GB) | . | . | . |
| Model 1 | . | . | Ideogram4 (9.1GB) | . | . | . |
| Model 2 | . | . | Ideogram4U (9.1GB) | . | . | . |
| VAE | Flux2 FP32 (336MB) | . | . | . | . | . |
Sample
Performance
xxx| FP32 Safetensor | BF16 Safetensor | FP8 Saferensor | INT8 Safetensor | Q8 GGUF | Q4 GGUF | |
|---|---|---|---|---|---|---|
| Model | . | . | . | . | . | . |
| CLIP | . | . | . | . | . | . |
| VAE | . | . | . | . | . | . |