Qwen-Image-2.1 on RX 7900 XTX: int8 ComfyUI on ROCm 7.2.4, resident in 24 GB, output check

What You'll Build

A local Qwen-Image-2.1 setup on a 24 GB RX 7900 XTX: ComfyUI on Linux, in AMD's own ROCm 7.2.4 / PyTorch 2.10.0 container, running the int8 files ComfyUI's templates load. It covers text-to-image at 1024×1024 and at the model's native 2048×2048, RGBA output, and instruction editing with reference images. Qwen-Image-2.1 is a 7B diffusion transformer behind a Qwen3-VL-8B text encoder and a 64-channel RGBA VAE, released 2026-09-20.

This page is stricter than most about the build, because of how this card fails. On gfx1100, a quantised image or video model can run at full speed with no error in the log and still put out noise, black frames or wrong colours. That has happened with other models on this card (Troubleshooting has the dated reports). So the page pins one torch build, gives the container only the 7900 XTX, keeps ComfyUI's older memory loader switched on, and keeps all three model files on the card at once. Running includes a three-image check that tells you in a few minutes whether your setup produces correct output.

⚠️ Read the licence before you download 17 GB. The weights ship under the Qwen Research License Agreement. Section 1.i defines "Non-Commercial" as the only permitted use: it "shall mean for research or evaluation purposes only." Section 2.a grants the licence "FOR NON-COMMERCIAL PURPOSES ONLY". Every repack on this page, Comfy-Org's int8 files and the GGUF included, is a derivative and carries the same terms. This is a reader's summary, not legal advice.

Hardware data: RX 7900 XTX (24 GB VRAM, gfx1100) · nothing measured on this card by this site · the three template files are 16.096 GiB and stay resident at 1024²; 4.940 GiB of the 23.984 GiB ComfyUI reports on Linux is left after the loader's reserve and the decode estimate (derived) · third-party timings from this card in Results · See benchmark data

ℹ️ What this page rests on. Nothing here was measured by this site. The container, torch build, comfy-kitchen version and the three files are the ones behind a posted, correct image on gfx1100: a 48 GB Radeon PRO W7900D running ComfyUI master at d158420, with its own pinned Python environment and the author's attention-dispatcher node. This page pins the v0.37.0 tag instead, whose text-to-image path, with these files on the older loader, behaves like that commit's except in how the first sampling step computes the text prefix; that equivalence is a reading of the code, not a run of the tag. Correct images from two other installs on an RX 7900 XTX (a GGUF set on Windows and the bf16 set on Linux), and one report from a different runtime that says "correct output" with no image, show that the model can produce correct output on this card. "Correct" means the image was checked against its own prompt, which ComfyUI stores in the PNG; the table under Requirements says what each report is. Every figure is either a third party's, cited where it appears, or arithmetic from byte counts and ComfyUI's source, added up unrounded and rounded once. If you run this install, post your result: a timed run with its startup log is the most useful thing this page lacks.

Requirements

min_vram_gb is 24. This page's safety argument is that all three files stay on the card, and that needs 24 GB (below). There is also no evidence below that: no report of Qwen-Image-2.1 producing a correct image on a discrete RDNA3 card with less than 24 GB (gfx1101, gfx1102, and the 20 GB and 16 GB gfx1100 cards, the RX 7900 XT and GRE) turned up in the searches listed under The runs this install rests on. That includes the 16 GB RX 7800 XT (gfx1101), for which no run of any kind turned up.

The card

• RDNA3, gfx1100, 24 GiB, 96 compute units. Those are the RX 7900 XTX row of AMD's GPU specifications table. AMD's ROCm 7.2.4 system requirements list the card as supported on Ubuntu 24.04.4 and 22.04.5. An officially supported target needs no HSA_OVERRIDE_GFX_VERSION, so leave it unset.
• What ComfyUI sees on Linux. Three Linux startup logs from 7900 XTX owners on the ComfyUI tracker all read Total VRAM 24560 MB, i.e. 23.984 GiB, with AMD arch: gfx1100: #16521 and #15347 from one owner, #16447 from another. That figure is the card's capacity before the HIP runtime and any desktop take their share; no log above states how much those take on this card.
• No FP8 in hardware. comfy-kitchen's HIP backend notes that "RDNA3 has no fp8 WMMA, so it widens fp8 to bf16" (source). ComfyUI's own gate treats the int8 formats as native on AMD and emulates the float8, nvfp4 and mxfp8 ones (Installation, step 4).

The three files

These are byte-exact from the Comfy-Org repack's tree API at revision ace0edeb. The repo's head is 9a44dbdb (2026-09-23), and every weight file's size and LFS hash is the same at both revisions (read 2026-09-24).

The same repo also holds:

• a bf16 DiT: 14,230,280,616 B = 13.253 GiB;
• a bf16 encoder: 17,534,334,616 B = 16.330 GiB;
• a w4a8 encoder: 6,312,105,364 B = 5.879 GiB;
• two qwen3.5_9b_…_pe_… files, which are prompt enhancers, not encoders.

It has no fp8 file.

What 24 GB holds, on the loader this page uses

ComfyUI has two memory loaders. The newer one, DynamicVRAM, is switched on for AMD only when torch.version.hip is 7.14 or newer (main.py L264-L273, the same at v0.37.2). On this page's HIP 7.2 build it is therefore already off. The launch line still passes --disable-dynamic-vram: a later torch upgrade to HIP 7.14 or newer would otherwise switch that loader back on without telling you, and every DynamicVRAM report in Troubleshooting involves it. On the legacy loader the reserve is minimum_inference_memory(): 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux. That makes 1.191 GiB (comfy/model_management.py L877-L891).

Before loading a model, ComfyUI asks for room: 1.1 × the model's weights plus the larger of that reserve and "estimate + 400 MiB". If less is free, it partially unloads resident models. The estimates are the ones this series' reviewed NVIDIA pages use:

• sampling: 0.960 GiB at 1024² and 3.840 GiB at 2048², at double batch. These hold only while ComfyUI runs PyTorch attention (the Using pytorch attention line under Running); otherwise comfy/model_base.py L432-L440 uses a formula that gives 7.2 GiB at 1024², a request of 15.025 GiB against 15.276 GiB free;
• VAE decode: 900 × h × w × 256 × 2 bytes over the latent grid (comfy/sd.py L844), which is 1.758 GiB at 1024² and 7.031 GiB at 2048².

"Free" in the table below is 23.984 GiB minus the weights already resident, before the HIP runtime and any desktop:

• At 1024² nothing leaves the card. Weights plus reserve plus the decode estimate come to 19.045 GiB, which leaves 4.940 GiB for the HIP runtime and sampling activations. The next image loads nothing: a new prompt re-runs the encoder on weights that never left, and a seed-only change skips the encoder entirely. That matters here because every gfx1100 corruption report this page cites involves DynamicVRAM, or a partial unload and reload on ROCm 7.15 / torch 2.13; this install uses neither.
• At 2048² the template's decode is the one stage that can move weights. It asks for 8.114 GiB with 8.517 GiB free, a margin of 0.403 GiB before the HIP runtime and any desktop on this card take their share. If they take more than that, part of a resident model's weights are copied to system RAM and loaded back for the next image. That is exactly the evict-and-reload pattern this page otherwise avoids, and no run of it on this card turned up. VAE Decode (Tiled) asks for one tile's estimate instead: 471,859,200 B = 0.439 GiB at 512 px tiles, so the 1.191 GiB floor governs and nothing moves (Running, Native 2K).
• The bf16 files are covered under Running. In short, the bf16 DiT with the bf16 encoder is 30.212 GiB of weights and cannot stay resident on this card.

The runs this install rests on

These are the reports found, in the ComfyUI and comfy-kitchen trackers, both Hugging Face discussion tabs for the model, a scan of every Hugging Face model card returned for the model's name, and a scan of the READMEs of the 183 GitHub repositories returned for it (2026-09-24, 16:41–17:12Z). For rows 1–3 the image was checked against the workflow embedded in its PNG. None of the four is this page's exact install; the notes under the table say how each one differs.

What the table does and does not show:

• What row 1 shares with this page. The container (by the published image's Dockerfile; the reference arm's record gives no digest), the torch build, comfy-kitchen 0.2.35 by package version, the three files and the legacy loader.

• What it does not. ComfyUI master rather than the tag; a fully pinned Python environment (docker/constraints-runtime.txt: transformers 5.17.0, numpy 2.4.6 and the rest) where this page lets pip resolve everything but torch; the author's dispatcher node; and a 48 GB card.

• What master at d158420 changes on this path. Three post-tag pull requests touch the 2.1 transformer file (compare):

  • #16419, a per-block attention choice, is inert here. A block uses it only when the model file carries a <prefix>config tensor naming comfy_kitchen_int8 (attention.py L82-L95), and neither int8 file has one: their safetensors headers list 649 and 1,258 tensors, none of them a config.
  • #16430 is block compilation and weight prefetch, plus a first-step change. Its prefetch queue and allocation graph are inert on the legacy loader: the queue needs prefetch_dynamic_vbars, which model_base.py sets only for a DynamicVRAM patcher, and its allocation graph needs comfy-aimdo, which starts only with DynamicVRAM (model_prefetch.py L29-L30, L278-L283). Its in-place gated residual is the same arithmetic. The change that applies: the prefix cache is on by default, and text-to-image has a text prefix. At d158420 the first sampling step computes the text prefix as its own pass and the image attends to it through the cache; the tag computes both together while filling the cache. Steps 2–25 run the same code in both.
  • #16429 changes where the prefix cache is kept. On the legacy loader its test for the card reads the same free-memory figure as the tag's (model_patcher.py L418-L426 adds comfy-aimdo's share only when aimdo is enabled), so text-to-image's small text-prefix cache lands on the card either way. It changes auto's fallback to system RAM, which only an edit can reach.

  So row 1 backs the tag's text-to-image path by a reading of the code, not by a run of the tag.

• Row 1's image comes from its reference arm, not its fast one. The repository A/B-tests a pair of patched HIP kernels. Its reference arm runs ComfyUI's own attention: the author's dispatcher sits in reference mode (backend.py).

• Which comfy-kitchen binary row 1's reference arm loaded is not recorded. The patched binary is built from the v0.2.35 source with only int8_attn.hip and rms_rope.hip replaced (rebuild-extension.sh). So the int8 matrix-multiply and ConvRot kernels that this page's files depend on are the stock v0.2.35 source in either case, while the RMSNorm/RoPE kernel in the reference arm was either the stock one or the author's.

• Row 1's "at least 32 GB". The repository's README asks for a gfx1100 GPU "with at least 32 GB available VRAM". That is the author's requirement for their packaged image, which runs their patched kernels, and the repository does not derive it. Its own reference record, taken after the measured request, shows 17,460,887,552 B = 16.262 GiB reserved by torch and 33,547,162,112 B free on the 51,522,830,336 B card (reference_measure_backend.json). That is a snapshot, not a peak. This page's case for 24 GB is the arithmetic above.

• Rows 2 and 3 ran the tag's 2.1 transformer code. The file did not change on master between the model's arrival on 2026-09-19 and 17:30Z on 2026-09-20.

  • Row 2 reported ComfyUI 0.37.0 in a commit made at 17:11Z on 2026-09-20. The 0.37.0 banner first appeared with the tag at 15:27Z, and the 2.1 file first changed at 17:30Z; this is an inference from those times.
  • Row 3's own log places it: banner 0.36.0, i.e. a checkout from before the tag's version bump, and templates 0.11.65. There is also no Comfy model compiler graph breaks line, which #16430's code prints under DynamicVRAM and #16521's log carries.

• What no row covers. No report shows a prompt change on this page's install. Row 1's measured request reused cached conditioning, and row 3 is one job. Row 2's edit followed its text-to-image with a new prompt, in what the guide calls a warm run, but at 512² with the GGUF set. The check under Running is there for that reason.

Installation

1. Host: the kernel driver and Docker (Ubuntu 24.04)

A ROCm container needs AMD's kernel driver, amdgpu-dkms, and Docker Engine on the host (ROCm's Docker guide). These commands are AMD's ROCm 7.2.4 quick start for Ubuntu 24.04, stopping before the ROCm userspace (the container brings its own), plus Docker from AMD's Radeon PyTorch page:

wget https://repo.radeon.com/amdgpu-install/7.2.4/ubuntu/noble/amdgpu-install_7.2.4.70204-1_all.deb
sudo apt install ./amdgpu-install_7.2.4.70204-1_all.deb
sudo apt update
sudo apt install "linux-headers-$(uname -r)" "linux-modules-extra-$(uname -r)"
sudo apt install amdgpu-dkms
sudo usermod -a -G render,video $LOGNAME
sudo apt install docker.io
sudo reboot

2. The container: ROCm 7.2.4 and PyTorch 2.10.0, pinned by digest

The tag rocm/pytorch:rocm7.2.4_ubuntu24.04_py3.12_pytorch_release_2.10.0 resolves to digest sha256:4449f856… on Docker Hub (read 2026-09-24). That is the exact FROM line of row 1's published image (Dockerfile). The image's build history installs ROCm 7.2.4 under /opt/rocm and the following into a virtualenv at /opt/venv, which is first on PATH, all from AMD's rocm-rel-7.2.4 wheel folder:

• torch==2.10.0+rocm7.2.4.lw.git3d3aa833
• torchvision==0.25.0+rocm7.2.4.git82df5f59
• torchaudio==2.10.0+rocm7.2.4.git5047768f
• triton==3.6.0+rocm7.2.4.git4ed88892

The torch wheel's own torch/version.py reads hip = '7.2.53211'. Pulling by digest means a retagged image cannot change what you get.

Give the container the 7900 XTX and nothing else. comfy-kitchen enables its matrix kernels only if every GPU it can see has them (step 4). An RDNA2 integrated GPU (gfx1035 and gfx1036 are both APUs in LLVM's processor table) sitting next to the card would silently switch them off. AMD's Docker guide restricts a container to particular GPUs by passing their individual render nodes instead of all of /dev/dri. The 7900 XTX's PCI ID is 1002:744c (Navi 31 [Radeon RX 7900 XT/7900 XTX/7900 GRE/7900M] in the PCI ID registry), and udev links each card's render node under /dev/dri/by-path/. On the host:

PCI=$(lspci -D -d 1002:744c | head -n1 | cut -d' ' -f1)
RENDER=$(readlink -f "/dev/dri/by-path/pci-$PCI-render")
echo "$PCI $RENDER"

That should print one PCI address and one /dev/dri/renderD… path. If lspci -D -d 1002:744c lists two cards (a 7900 XT or GRE shares the ID), tell them apart by VRAM, which the amdgpu driver reports in bytes in each card's mem_info_vram_total (kernel documentation). List the candidates:

for d in $(lspci -D -d 1002:744c | cut -d' ' -f1); do echo "$d $(cat /sys/bus/pci/devices/$d/mem_info_vram_total)"; done

The 7900 XTX is the one at about 25.8 billion (24 GiB). Set PCI to its address by hand (for example PCI=0000:03:00.0) and re-run the RENDER line.

The rest of the docker run flags are AMD's from its Radeon PyTorch page. The page adds a port for ComfyUI, published on the host's localhost only because ComfyUI has no login, and a folder for your files:

mkdir -p ~/qwen21
sudo docker pull rocm/pytorch@sha256:4449f856653602317e4101a76fce599c7fcd58ccec2e539951fce5f73083179e
sudo docker run -it --name qwen21 \
  --cap-add=SYS_PTRACE --security-opt seccomp=unconfined \
  --device=/dev/kfd --device="$RENDER" --group-add video \
  --ipc=host --shm-size 8G \
  -p 127.0.0.1:8188:8188 -v "$HOME/qwen21:/work" \
  rocm/pytorch@sha256:4449f856653602317e4101a76fce599c7fcd58ccec2e539951fce5f73083179e

You are now in a shell inside the container. Check the build and what it sees:

python -c "import torch; print(torch.__version__, torch.version.hip, torch.cuda.device_count(), torch.cuda.get_device_name(0))"
# expect: 2.10.0+rocm7.2.4.git3d3aa833 7.2.53211 1 AMD Radeon RX 7900 XTX

If the count is not 1 or the name is not the 7900 XTX, leave the container (exit), remove it (sudo docker rm qwen21), and fix RENDER before running it again.

To return later, run sudo docker start -ai qwen21. Do not add --rm to the run line: the packages installed in step 3 live in the container. The container keeps the render-node path it was created with, so after a BIOS or hardware change, re-run the check above inside it.

Why not PyTorch's own ROCm index. ComfyUI's README installs torch for AMD on Linux from download.pytorch.org/whl/rocm7.2. On 2026-09-24 that index served torch up to 2.14.0+rocm7.2, for Python 3.10 to 3.15, so a plain install now resolves to 2.14.0. No Qwen-Image-2.1 run on that build turned up. The build before it, 2.13.0+rocm7.2, is the one on which #15314's reporter got noise from MiniMax H3 on this card. Neither build is known to be bad for this model; this container is simply the build behind row 1's correct image with these files.

3. ComfyUI v0.37.0, with the torch build held in place

Support for the model landed in ComfyUI core with PR #16400 (merged 2026-09-19); tag v0.37.0 contains it. The later tags, v0.37.1 and v0.37.2, change neither the 2.1 model code nor its three workflow files. requirements.txt at the tag leaves torch, torchvision and torchaudio unpinned. A constraints file stops pip from swapping in a build from PyPI; the advice to "Write a constraints file immediately" comes from a 7900 XTX owner's ROCm install notes on #15314. Inside the container:

cd /work
git clone https://github.com/Comfy-Org/ComfyUI
cd ComfyUI
git checkout v0.37.0
printf '%s\n' \
  'torch==2.10.0+rocm7.2.4.lw.git3d3aa833' \
  'torchvision==0.25.0+rocm7.2.4.git82df5f59' \
  'torchaudio==2.10.0+rocm7.2.4.git5047768f' \
  'triton==3.6.0+rocm7.2.4.git4ed88892' > /work/constraints.txt
pip install -r requirements.txt -c /work/constraints.txt
python -c "import torch, torchvision; print(torch.__version__, torchvision.__version__)"
git describe --tags

The print must still show 2.10.0+rocm7.2.4.git3d3aa833 and a +rocm7.2.4 torchvision, and git describe must read v0.37.0. requirements.txt pins comfy-kitchen==0.2.35 and comfy-aimdo==0.5.5. Nothing else it lists requires a torch newer than 2.10.0. Stay on the tag rather than master, for the reasons under Troubleshooting (Fatal Python error: Aborted).

4. Confirm the int8 kernels are the HIP ones

This is the check that matters most on this card. When ComfyUI loads the int8 DiT, its matrix multiplies go to comfy-kitchen's HIP backend. The same backend also runs the model's RoPE and AdaLN kernels in every weight format, including bf16. On AMD, comfy-kitchen tries backends in the order hip, cuda, triton, eager: cuda is disabled because torch.version.cuda is empty, and triton is off by default. So if hip does not load, every one of those ops silently falls through to the pure-PyTorch eager path. That is the same eager path on which the MiniMax H3 reporter in #15314 still got noise on this card.

What the PyPI wheel carries (comfy_kitchen-0.2.35-cp312-abi3-manylinux…x86_64.whl, read 2026-09-24):

• backends/hip/_C.abi3.so, compiled by AMD clang from the roc-7.2.4 toolchain;
• code objects for gfx1030–1036, gfx1100–1103, gfx1150–1153, gfx1200 and gfx1201;
• a link to libamdhip64.so.7 with a runpath of /opt/rocm/lib, where this container keeps ROCm 7.2.4.

The backend's own docstring: "Every matmul is a WMMA kernel compiled from the sources in this directory". So on this build the extension should load. Start ComfyUI once (Running) and find this line near the top of the log:

Found comfy_kitchen backend hip: {'available': True, 'disabled': False, 'unavailable_reason': None, 'capabilities': [..., 'convrot_w4a4_linear', ..., 'int8_linear', ...

Check two things on that line:

• 'available': True. If it says False, read its unavailable_reason before generating anything (Troubleshooting).
• 'int8_linear' and 'convrot_w4a4_linear' in capabilities. 'available': True alone is not enough. When any visible GPU is an RDNA2 one (the manifest's elementwise_only group, gfx1030–gfx1036), its _build_constraints() drops every matrix-multiply op, int8_linear included, and still registers as available (__init__.py L190-L199 and L2710-L2714). The int8 layers then run on eager, with no warning.

Other 7900 XTX owners' logs show both on HIP 7.1 (#16447) and HIP 7.15 (#16521). On the first generation you should then see:

Native ops: convrot_w4a4, int8_tensorwise, asym_w4a8_int8 , emulated ops: float8_e4m3fn, float8_e5m2, nvfp4, mxfp8

That line is from a 7900 XTX log in #16521; the order varies, because the line prints a set. It comes from ComfyUI's own check, which is true on any ROCm device, so it does not show which comfy-kitchen backend runs; the capabilities list does.

What the two int8 files get on this card:

• The DiT's quantised linear layers run as INT8 matrix multiplies on the card's matrix units. Its 192 int8 weights sit next to 73 bf16 tensors (norms, input and output projections, modulation), per the file's safetensors header.
• The text encoder does not. At v0.37.0 every quantised encoder is built with full_precision_mm=True (comfy/sd1_clip.py), so its int8 weights are dequantised for each matmul. That makes the int8 encoder a memory choice.

5. Download the weights

The repo's folder names match ComfyUI's models/ layout. Still inside the container, in /work/ComfyUI:

pip install -U huggingface_hub -c /work/constraints.txt
hf download Comfy-Org/Qwen-Image-2.1 \
  diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
  text_encoders/qwen3vl_8b_int8_convrot.safetensors \
  vae/qwen_image_2.1_vae_bf16.safetensors \
  --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir models
sha256sum models/diffusion_models/qwen_image_2.1_int8_convrot.safetensors
# cb74113cb03faecd79611b01fd7fd642f0aa60d6f0b95086abee214d75eaa57d
sha256sum models/text_encoders/qwen3vl_8b_int8_convrot.safetensors
# 8bfd0f6e12abf2d2d697ecc888e5e90b0d6741d6708f05799f53afa560452e8f
sha256sum models/vae/qwen_image_2.1_vae_bf16.safetensors
# bb21f7473051e1ac368515dd3f2e15cd44d7a11748ee8823e1ddca3e4876b7c9

Those are the files' LFS hashes, and the same three hashes are in row 1's model manifest. A truncated download is a common cause of garbled output. Do not load either qwen3.5_9b_…_pe_… file as the text encoder: those are prompt-rewriting models.

Without Docker: the same build on the host

Nobody in the table above ran it this way. It reproduces the image's environment on the host itself, and it replaces steps 2–5 with the one block below. After step 1, install ROCm 7.2.4 from the same AMD repository (quick start), with Python's venv module and Git, which Ubuntu 24.04 Desktop does not ship, and reboot:

sudo apt install git python3-setuptools python3-wheel python3-venv rocm
sudo reboot

Then, in a new shell, run this block from top to bottom. It installs the four wheels exactly as the image's build does:

export QI="$HOME/qwen21"
mkdir -p "$QI"
cd "$QI"
git clone https://github.com/Comfy-Org/ComfyUI
cd ComfyUI
git checkout v0.37.0
python3 -m venv .venv
source .venv/bin/activate
pip install --find-links https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2.4/ --prefer-binary \
  "torch==2.10.0+rocm7.2.4.lw.git3d3aa833" "torchvision==0.25.0+rocm7.2.4.git82df5f59" \
  "torchaudio==2.10.0+rocm7.2.4.git5047768f" "triton==3.6.0+rocm7.2.4.git4ed88892"
printf '%s\n' \
  'torch==2.10.0+rocm7.2.4.lw.git3d3aa833' \
  'torchvision==0.25.0+rocm7.2.4.git82df5f59' \
  'torchaudio==2.10.0+rocm7.2.4.git5047768f' \
  'triton==3.6.0+rocm7.2.4.git4ed88892' > "$QI/constraints.txt"
pip install -r requirements.txt -c "$QI/constraints.txt"
python -c "import torch; print(torch.__version__, torch.version.hip); [print(i, torch.cuda.get_device_name(i)) for i in range(torch.cuda.device_count())]"
pip install -U huggingface_hub -c "$QI/constraints.txt"
hf download Comfy-Org/Qwen-Image-2.1 \
  diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
  text_encoders/qwen3vl_8b_int8_convrot.safetensors \
  vae/qwen_image_2.1_vae_bf16.safetensors \
  --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir models

Check the downloads with the three sha256sum lines from step 5.

The device list must show the 7900 XTX. If it lists more than one device, hide the others. AMD's GPU isolation page gives HIP_VISIBLE_DEVICES for this: set it to the 7900 XTX's number from that list in every shell that starts ComfyUI, for example export HIP_VISIBLE_DEVICES=1 if the card was listed as 1. The launch block below has the line. The page also warns that environment variables are not an isolation boundary; here they only choose the device.

These lw wheels do not bundle the HIP runtime: their file listing has no libamdhip64, so they use the host's ROCm under /opt/rocm. The image also sets LD_LIBRARY_PATH=/opt/rocm/lib; set it too if import torch cannot find a ROCm library.

To start ComfyUI on the host, from a new shell:

cd "$HOME/qwen21/ComfyUI"
source .venv/bin/activate
# export HIP_VISIBLE_DEVICES=1   # only if the device list showed more than one GPU; use the 7900 XTX's number
python main.py --disable-dynamic-vram

With no --listen, ComfyUI binds to 127.0.0.1, its default (comfy/cli_args.py). Leave it that way: ComfyUI has no login. On this route, every later pip install takes -c "$HOME/qwen21/constraints.txt".

Windows: the one combination with a correct-output report

Only one Windows setup of this model on this card produced a correct image in the places searched: row 2 of the table above. That run used Windows 11, AMD's ROCm 7.2.1 wheels for Windows, ComfyUI 0.37.0, city96's GGUF loader, a Q4_K_M GGUF DiT and the w4a8 encoder, at 512² and 8 steps. Two other routes have no correct-output report on this card in those searches:

• the int8 template on Windows;
• the README's Windows route on ROCm 10.0, whose torch reports HIP 7.15. The one 7900 XTX run on HIP 7.15 (#16521, Linux) completed and did not describe its output.

Driver first. The guide's pitfalls list requires AMD's preview "PyTorch on Windows Edition" driver, installed clean (factory reset), for both of its install options. Its Desktop option names version 25.20.01.17 and adds that regular Adrenalin drivers do not expose ROCm. The environment the guide records for its verified run shows driver 32.0.31041.1004.

The commands below are row 2's install guide, with these changes:

• git checkout v0.37.0. The guide clones master without a checkout; on 2026-09-20 at 17:11Z that was the tag plus a frontend pin. The clone URL is the current Comfy-Org one, which the guide's old comfyanonymous URL redirects to.
• AMD's torchaudio wheel from the same folder, and a constraints file. requirements.txt at v0.37.0 also lists torchaudio, which the guide does not install.
• ComfyUI-GGUF's own requirements (gguf>=0.13.0 among them), which the guide does not install. The guide's ComfyUI-Manager is left out.
• Revision pins on the downloads. The run's embedded workflow names qwen_image_2.1_Q4_K_M.gguf. Of the three GGUF repos read (Abiray, unsloth, leejet), only Abiray's carries a file by that name: 4,189,343,904 B = 3.902 GiB. Its GGUF header declares general.architecture = qwen_image, which city96's loader.py accepts.
• The launch line adds --disable-dynamic-vram and drops the guide's --port 8188 (the default anyway) and --enable-cors-header, which only its own web front end needs. Without --listen, ComfyUI binds to 127.0.0.1.

Run this in cmd.exe:

winget install Python.Python.3.12
git clone https://github.com/Comfy-Org/ComfyUI.git
cd ComfyUI
git checkout v0.37.0
py -3.12 -m venv venv
venv\Scripts\activate.bat
python -m pip install --upgrade pip
pip install --no-cache-dir ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/rocm_sdk_core-7.2.1-py3-none-win_amd64.whl ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/rocm_sdk_devel-7.2.1-py3-none-win_amd64.whl ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/rocm_sdk_libraries_custom-7.2.1-py3-none-win_amd64.whl ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/rocm-7.2.1.tar.gz
pip install --no-cache-dir ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/torch-2.9.1%2Brocm7.2.1-cp312-cp312-win_amd64.whl ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/torchvision-0.24.1%2Brocm7.2.1-cp312-cp312-win_amd64.whl ^
  https://repo.radeon.com/rocm/windows/rocm-rel-7.2.1/torchaudio-2.9.1%2Brocm7.2.1-cp312-cp312-win_amd64.whl
echo torch==2.9.1+rocm7.2.1> constraints.txt
echo torchvision==0.24.1+rocm7.2.1>> constraints.txt
echo torchaudio==2.9.1+rocm7.2.1>> constraints.txt
pip install -r requirements.txt -c constraints.txt
git clone https://github.com/city96/ComfyUI-GGUF.git custom_nodes\ComfyUI-GGUF
pip install -r custom_nodes\ComfyUI-GGUF\requirements.txt -c constraints.txt
pip install -U huggingface_hub -c constraints.txt
hf download Abiray/Qwen-Image-2.1-GGUF qwen_image_2.1_Q4_K_M.gguf --revision c9dd12108f53974cd1e0abd708df042d6df0ca8d --local-dir models\unet
hf download Comfy-Org/Qwen-Image-2.1 text_encoders/qwen3vl_8b_w4a8.safetensors vae/qwen_image_2.1_vae_bf16.safetensors --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir models
python main.py --use-pytorch-cross-attention --disable-dynamic-vram

About the launch line and the graph:

• The flags. --use-pytorch-cross-attention is row 2's own flag. --disable-dynamic-vram changes nothing on HIP 7.2, where the legacy loader is already the default; it is there for the same reason as on Linux.
• The graph to build. Open the text-to-image template (Running), then open its subgraph. Replace UNETLoader with Unet Loader (GGUF) set to qwen_image_2.1_Q4_K_M.gguf, and set CLIPLoader to qwen3vl_8b_w4a8.safetensors with type qwen_image. The three files come to 10.409 GiB, and they all stay on the card.
• What the evidence covers. Row 2's evidence is at 512² and 8 steps. It says nothing about the template's 1024² and 25 steps on this path.
• One GPU. Before launching, list the GPUs with python -c "import torch; [print(i, torch.cuda.get_device_name(i)) for i in range(torch.cuda.device_count())]". If an integrated GPU shows up next to the 7900 XTX, run set HIP_VISIBLE_DEVICES= followed by the 7900 XTX's number in the same cmd.exe window first. AMD's GPU isolation page covers the variable on Windows too.
• What cannot be checked. Row 2 did not post a startup log, so whether comfy-kitchen's HIP backend (whose Windows wheel also carries a HIP binary) served the w4a8 encoder there is not recorded. Check the hip line and its capabilities the same way.

Running

On the Docker route, inside the container, in /work/ComfyUI:

python main.py --listen 0.0.0.0 --port 8188 --disable-dynamic-vram

Then open http://127.0.0.1:8188 in a browser on the host.

• Why --listen 0.0.0.0 here. ComfyUI's default, 127.0.0.1, would be the container's own loopback, which Docker's port mapping cannot reach.
• Why it is still local. The docker run line publishes the port on the host's 127.0.0.1 only. ComfyUI has no authentication, so never change -p 127.0.0.1:8188:8188 to a bare -p 8188:8188.
• On the host route, start ComfyUI as shown under Without Docker, with no --listen.

Everything below applies to both routes.

The first screen of the log should show:

• pytorch version: 2.10.0+rocm7.2.4.git3d3aa833, AMD arch: gfx1100 and ROCm version: (7, 2);
• Total VRAM 24560 MB and Device: cuda:0 AMD Radeon RX 7900 XTX : native;
• Using pytorch attention (at v0.37.0 ComfyUI turns on PyTorch attention for gfx1100 by itself once torch's flash-attention kernels pass a start-up probe; if they do not, it logs Could not run flash attention, disabling it and uses another attention);
• the hip backend line from step 4;
• a warning that starts "Dynamic vram disabled with argument.", and no line reading DynamicVRAM support detected and enabled.

Text-to-image

Open the Template Library and load Qwen Image 2.1: Text to Image (image_qwen_image_2_1_t2i.json, workflow-templates at 371a7b7171; templates 0.11.66 through 0.11.69 carry the same file). Its outer subgraph node sets:

• UNETLoader → qwen_image_2.1_int8_convrot.safetensors;
• CLIPLoader → qwen3vl_8b_int8_convrot.safetensors, type qwen_image;
• VAELoader → qwen_image_2.1_vae_bf16.safetensors;
• 25 steps, cfg 1, euler / simple, 1024×1024.

The template's note: "negative_prompt: unused while cfg is 1." At cfg 1 ComfyUI skips the negative pass; raising cfg doubles the model passes per step. For a transparent image, wrap the prompt as the model card does (This is an RGBA image with transparency. <subject>. The image has alpha channel and the background is transparent.), and keep SaveImageAdvanced at PNG, which keeps the alpha channel.

ComfyUI fixes this model's sampling shift at the 1024² value at every size, while the vendor's scheduler shifts with resolution. #16447 (open) reports that, from this card: its author writes that at 4 megapixels "the image produced through the LTX-scheduler-aligned branch is clearly the better one". comfyanonymous replied "This is kind of on purpose, the higher the shift the more you see a grid pattern".

A step-distilled option exists: Viggle/Qwen-Image-2.1-viggle-turbo. It is a third-party preview, and as read on 2026-09-24 (revision b77064be) its card recommends v0.2.1, a 6-step LoRA, and says the student "still falls short of the base model" on complicated editing. Nothing on this page was run with it. Two reports involving this model and a LoRA turned up in the ComfyUI tracker, both closed on 2026-09-23: PR #16493, an error on adding or removing a LoRA on a quantised model (Troubleshooting), and issue #16496, in which one user's edits came out shifted to the left, which that user attributed to Viggle's first release (v0.1) before closing it. Neither names a GPU.

The output check: three images before you trust the setup

On gfx1100 a broken setup often fails silently, so look before you rely on it:

1. Run the template as loaded.
2. Change the prompt to a different subject and run again. That re-runs the encoder, which is the step a prompt change adds.
3. Load the edit template (below) with resolution 1056 and the cache at device gpu, as Editing sets them. Give it one of your two images and ask for one simple change (a colour, an object).

All three should match what you asked for. The failures reported on this card, and from other RDNA cards, with other models or on other builds, look like this:

• noise or a mosaic "snow" at normal speed. The MiniMax H3 reporter in #15314 described their 7900 XTX (torch 2.13.0+rocm7.2) this way: "it computes, but produces garbage";
• all-black images (NaN). In the same thread a second 7900 XTX owner traced this to weights reloaded after a partial eviction, and on 2026-08-09 put the cause in ROCm 7.15 or PyTorch 2.13, which in their tests corrupted weights on the way back to VRAM while ROCm 7.14 did not;
• wrong colours, subjects bright green, after a model reload with DynamicVRAM on: this model on an RX 9070 XT in #16437.

If any of the three images is wrong, change things in this order:

1. The torch line and the device. Re-run the check from Installation step 2 (or the device list under Without Docker), and the hip line and its capabilities from step 4.
2. The loader. Confirm the "Dynamic vram disabled with argument." warning is in the log.
3. HIP 7.15. Stay off 7.15 builds, which is what the Windows ROCm 10.0 wheels report.

Then check the three hashes. If it still fails, post your log and the images on /contribute or the tracker; that would be the first report of a failure on this setup.

Native 2K

The template's note: "For native 2K, set 1:1 and 4 megapixels". Sampling at 2048² fits with the encoder resident (Requirements). The template's VAE Decode then asks for 8.114 GiB with 8.517 GiB free before the HIP runtime and any desktop, so it may push part of a model to system RAM and load it back next time.

To keep everything resident, open the template's subgraph and replace VAE Decode with VAE Decode (Tiled) (core node, tile_size 512, overlap 64). It asks for 1.883 GiB. Tiled decoding can leave seams that the plain decode does not. No 2K run of the lead install on this card turned up: row 3's 2720×1536 images used the plain decode, but with the bf16 files and DynamicVRAM, a different memory picture.

If you keep the plain decode and it runs out of memory, ComfyUI falls back by itself and logs "Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding."

Editing with reference images

Load Qwen Image 2.1: Image Edit (image_qwen_image_2_1_image_edit.json, same release). It uses the same three loaders, plus two nodes:

• TextEncodeQwenImage21, with the VAE connected and resolution 0: "This template starts at 0: no resize beyond a multiple of 32."
• QwenImage21Cache at auto / default, which stores the text and reference tokens' attention K/V once instead of recomputing them every step. The node's tooltip in comfy_extras/nodes_qwen.py: "auto uses spare VRAM, then RAM. cpu (RAM) is prefetched behind compute and costs little speed."

Two settings to change, both code readings of v0.37.0 with no edit run on this card at these sizes behind them.

1. Set resolution to 1056 when you edit your own images. At resolution 0 each reference keeps its own size, rounded to a multiple of 32, and the output takes the first reference's size (nodes_qwen.py L155-L181). Three of the legacy loader's estimates grow with those sizes:

• the VAE encode of each reference: 600 × H × W × 2 bytes (comfy/sd.py L843);
• the plain decode of the output: 900 × h × w × 256 × 2 bytes over its latent grid (L844);
• sampling: the double-batch estimate over the output's latent plus every reference latent (comfy/model_base.py L2622). The references count once for the positive and once for the negative conditioning, both of which carry them (nodes_qwen.py L179-L180).

With the three files resident, 8,469,935,448 B = 7.888 GiB of the card is free before the HIP runtime. Less the 400 MiB reserve, an estimate above 8,050,505,048 B = 7.498 GiB makes ComfyUI partially unload a resident model and load it back later. That is the evict-and-reload path this page otherwise avoids, and no report covers it on this card. These are the sizes at which each estimate crosses that bound (upper limits; the HIP runtime lowers them):

A 4032×3024 phone photo at resolution 0 becomes 4032×3008, and its decode estimate alone is 21,830,860,800 B = 20.332 GiB.

At resolution 1056 each reference and the output come out at about 1.1 megapixels: 1056×1056 for a square image, 1216×928 for a 4:3 one. For square references:

• the sampling estimate is 2.042, 3.063 or 4.084 GiB for one, two or three references;
• the decode estimate is 1.869 GiB;
• each encode estimate is 1.246 GiB.

All of these are inside the bound. 1056 is also one of the two sizes clean in both of #16435's reports (below). The output check's edit uses a 1024×1024 image from step 1, which becomes 1056×1056 and stays inside.

The text encoder also reads each reference, resized the same way: one vision token per 32×32 pixels (nodes_qwen.py L153), so 1,089 for a square reference at 1056 and 3,267 for three. ComfyUI budgets nothing for them. The 2.1 encoder defines no memory estimate, so the encode stage asks for the same 1.191 GiB margin whatever the images' size (comfy/sd.py L465-L469, model_management.py L943-L944). At 1056 that is a modest addition to the prompt. A 4032×3008 photo at resolution 0 would bring 11,844 per reference, and no report has measured what that costs.

2. Set the cache to device gpu and leave dtype at default. The cache costs 2 × 32 layers × 4096 × 2 bytes = 524,288 B per cached token at the default precision. At v0.37.0 (comfy/ldm/qwen_image21/model.py L240-L262):

• auto places the cache on the GPU only if four times its size is free there;
• failing that, it places it in system RAM under the same test. On AMD that is pinned host memory, which ComfyUI enables there too (comfy/model_management.py L1613-L1621);
• failing both, it recomputes the prefix every step;
• an explicit device asks for twice its size, and otherwise recomputes.

At resolution 1056, with square references and before the prompt's own tokens:

Some specifics:

• The template's own references. Its two 896×1152 images become 928×1184 each at 1056, 8,584 tokens in all, so its edit recomputes too.
• Why not auto. It needs four times the cache free, 8.508 GiB even for one reference here, so it never picks the card at these sizes. It goes to pinned system RAM first, which is the path of PR #16481's crash report (Troubleshooting).
• Why not dtype int8. It would halve the cache, but it quantises the cached K/V through comfy-kitchen's ConvRot quantiser (model_animate2.py L176-L185), a numeric path no report covers on gfx1100. Row 2's edit graph has no cache node, so it ran at auto / default.

An edit adds the cache and the encoder's and VAE's work on the references, but no further model file. So at these sizes the legacy loader has no extra weights to place.

If edits come out over-sharpened and speckled. Issue #16435 (open, read 2026-09-24) reports broken edits at particular reference grids, from Apple MPS and from an NVIDIA card. 512 and 1056 were clean in both reports, so the 1056 above already covers it; 512 is the fallback.

The bf16 files

The bf16 DiT with the bf16 encoder is how row 3 ran, with correct output on this card. It is not this page's lead, for two reasons:

• It forces a reload on every prompt change. Together the two are 30.212 GiB of weights: each fits alone (17.521 GiB with the reserve for the encoder stage, 14.444 GiB for the DiT) but not together. The encoder and DiT therefore swap on and off the card whenever the prompt changes. On the loader row 3 used, DynamicVRAM, that is the setting of #16437's reload corruption; on the legacy loader it is a partial unload and reload, the pattern #15314 tied to corruption on ROCm 7.15 / torch 2.13. Row 3 shows a single first job, which does not test that path.
• The cost. It is a 31.8 GB download, and at 2720×1536 it sampled at 5.14 and 5.17 s/it there (Results).

The bf16 DiT with the w4a8 encoder would keep all three files resident at 1024², with 1.275 GiB left for the HIP runtime and activations (22.709 GiB with reserve and decode). No run of that combination on this card turned up in the places searched.

Results

• Speed: our catalogue has no benchmark rows for this pair; /check/qwen-image-2-1/rx-7900-xtx returns verdict: unknown. These are the only timings of this model on an RX 7900 XTX found, each with its build:

  • Row 2 (Windows 11, torch 2.9.1+rocm7.2.1, Q4_K_M GGUF + w4a8, 512², 8 steps, correct output): 18.1 s cold including about 14 s of model loading, about 0.6 s/step after that, and 16.2 s warm for the edit (guide).
  • #16521 (Linux, torch 2.13.0+rocm10.0.0, HIP 7.15, DynamicVRAM on, --use-flash-attention, the int8 template unchanged, so 1024² and 25 steps): 25 steps in 19 s (1.26 it/s), and "Prompt executed in 26.49 seconds". Two caveats: the report does not describe its output, and HIP 7.15 with DynamicVRAM is not this page's build.
  • Row 3 (Linux, torch 2.12.1+rocm7.1, bf16 DiT + bf16 encoder, 2720×1536, 40 steps, correct output, first job after a restart): sampling at 5.14 and 5.17 s/it for its two images, about 205–206 s each; the two-image job took 493.67 s in all.
  • stable-diffusion.cpp #2015 (Linux, Vulkan, a different runtime, Q8_0 GGUF, 20 steps at cfg 6): 1024² in 139 s. It does not describe its output.

  Row 1's timings come from a 48 GB workstation card and are not this card's. Row 1's repository also ships a pair of patched HIP kernels that its author reports as 1.31× faster end to end on that card; they are not part of this page's install. No run of the lead install on this card turned up, so its speed here is unknown. If you time it, /contribute is where the number belongs.

• VRAM usage: derived, not measured by this site. At 1024² the three files (16.096 GiB) stay resident on the legacy loader, with 4.940 GiB left after the 1.191 GiB reserve and the 1.758 GiB decode estimate. At 2048² only the plain decode is tight (above). Live data, when it exists, will be at /check/qwen-image-2-1/rx-7900-xtx.

• Quality notes: the correctness evidence is the table under Requirements. Row 1, the same container, torch build and files on ComfyUI master, backs this install's text-to-image path by code reading; rows 2 and 3 are other installs on this card; row 4 is another runtime, with no image. Beyond that, the model's own reports apply: the fixed-shift trade-off above, and discussion #12 on the vendor's model repo, opened by a user, on a diamond-grid pattern attributed to the VAE at high resolution. Inspect native-2K portraits at 100%.

For the full benchmark data, see /check/qwen-image-2-1/rx-7900-xtx.

Troubleshooting

The hip backend line says 'available': False

Read its unavailable_reason:

• Failed to load HIP extension: …libamdhip64.so.7… means the ROCm runtime is not on the library path. Inside this container it is at /opt/rocm/lib; on a host install, set LD_LIBRARY_PATH=/opt/rocm/lib as the image does.
• architecture is not in the validated target manifest or could not read the architecture of every visible device means another GPU is visible, such as an integrated one: the backend registers only if every visible device is supported. Give the container only the 7900 XTX's render node (step 2); on the host route, set HIP_VISIBLE_DEVICES (Without Docker). The #15314 reporter hid an integrated GPU the same way, with ROCR_VISIBLE_DEVICES=0.
• disabled by COMFY_KITCHEN_DISABLE_HIP=1 means that variable is set in your environment.

Do not generate with the backend unavailable. Every int8 matrix multiply would run on the eager path, where #15314's MiniMax H3 reporter on this card still got noise.

The hip line says 'available': True, but capabilities has no int8_linear

Another GPU without matrix cores is visible, typically an RDNA2 integrated GPU (gfx1030–gfx1036 are in comfy-kitchen's elementwise_only group). The backend then registers with only its elementwise kernels, and every int8 matrix multiply falls through to eager with no warning (__init__.py L2710-L2714). Fix the device list as in the entry above, restart ComfyUI and check the line again.

Images come out as noise, black or wrong colours

This is the three-image check failing. Work through its order: torch line, loader, HIP version, then file hashes. These are the reports that shaped that order, all open and all read 2026-09-24:

• #15314 (opened 2026-08-05; MiniMax H3, not this model). Noise on a 7900 XTX with torch 2.13.0+rocm7.2, forced DynamicVRAM, and both the HIP and eager backends. Separately, from a second 7900 XTX owner: black frames from weights corrupted on reload under ROCm 7.15 / torch 2.13 (2026-08-09), clean on ROCm 7.14 / torch 2.14, and on 2026-08-21 clean on the ROCm 10.1 nightly: "switching to the ROCm 10.1 nightly line fixes H3 on gfx1100".
• #15452 (other models). On 2026-09-08 a 7900 GRE owner (gfx1100, 2.13.0+rocm10.0.0, HIP 7.15) wrote "I'm also seeing occasional black / bad image output for sdxl workflows when using the default dynamic vram mode." The same owner reports it does not happen with --disable-dynamic-vram.
• #16437 (opened 2026-09-20; this model on an RX 9070 XT, gfx1201). "The first job after a server start is correct." After a reload with --enable-dynamic-vram: "Visually, subjects render bright green." On 2026-09-21 a 7900 XTX owner added, about another model (w4a8 files, ROCm 10.0): "the first few gens are fine (i can even change the prompt and resolution) but after about 3 or 4 it starts outputting garbage."

None of these reports uses this page's build, and that is the point of it.

torch.__version__ no longer ends in +rocm7.2.4…

A pip install without the constraints file replaced torch. Recreate the container from the digest (step 2), or in the container pip install --force-reinstall --no-deps --find-links https://repo.radeon.com/rocm/manylinux/rocm-rel-7.2.4/ -c /work/constraints.txt torch torchvision torchaudio triton; on the host route, the same with -c "$HOME/qwen21/constraints.txt" inside the venv. Always pass the constraints file to later installs, including custom nodes'.

Flash Attention failed, using default SDPA repeated during sampling

This happens only if you added --use-flash-attention. #16521 logged "Flash Attention failed, using default SDPA: Mask must not be set for Flash attention" 32 times on this card: this model passes an attention mask, so every call falls back to PyTorch attention. This page's launch line does not pass the flag, and ComfyUI uses PyTorch attention on gfx1100 by default.

TextEncodeQwenImage21 or QwenImage21Cache missing when the template loads

You are below v0.37.0: git fetch --tags && git checkout v0.37.0, then pip install -r requirements.txt with your constraints file (-c /work/constraints.txt in the container, -c "$HOME/qwen21/constraints.txt" on the host), then restart.

JSONDecodeError: Expecting value: line 1 column 1 (char 0) from the CLIPLoader

A damaged encoder file. On #16472 (a Radeon 890M) kijai replied "This is most likely a corrupt/incomplete model file." A re-download fixed it. Compare the hash from step 5.

Edits are far slower than text-to-image

The K/V cache found no room and is being recomputed every step. Set QwenImage21Cache to device gpu; with two or more references at resolution 1056 the cache does not fit and the recompute is expected (Editing).

Fatal Python error: Aborted, on master

There are two open reports, both on master code and both from NVIDIA cards:

• #16443: an intermittent abort at the start of an edit.
• PR #16481: an abort in sampler cleanup on the second generation, with QwenImage21Cache at auto and the cache in pinned system RAM.

The tag's cleanup code is the same, so the tag is not a known fix for the second one. A cache kept on the card, or recomputed, pins no host memory; device gpu (Editing) does one or the other. If you hit either on master, go back to the tag.

RuntimeError: Cannot set version_counter for inference tensor after adding or removing a LoRA

PR #16493 (closed unmerged by its author) reports this on master, with a Qwen-Image-2.1 int8 checkpoint: adding or removing a LoRA on an already-loaded quantised model. Every later generation fails until a restart. The function it patches is the same at the tag, on the legacy loader this page uses. Restart ComfyUI if you hit it.

See also: Qwen-Image on RX 7900 XTX covers the 2025 20B predecessor on this card. These are the reports found for this model on 2026-09-24; the tracker moves by the hour in launch week. Report problems, or better a timed run of the lead install with its startup log and the three check images, via the submission form.