Qwen-Image-2.1 on RTX 3080 Ti: int8 template, 12 GB budget from owner logs, 2K and editing

What You'll Build

A local Qwen-Image-2.1 setup on a 12 GB RTX 3080 Ti in ComfyUI, using the int8 files ComfyUI's own templates load: text-to-image at 1024×1024 and at the model's native 2048×2048, RGBA output with a real alpha channel, and instruction-based editing with reference images. Qwen-Image-2.1 is a 7B single-stream diffusion transformer (32 layers, per the repo's transformer/config.json) behind a Qwen3-VL-8B text encoder and a 64-channel RGBA VAE, released 2026-09-20. On this card the transformer is not the hard part, at 6.758 GiB in int8. The text encoder is: at 8.709 GiB it is the larger file, and its stage comes closest to the card's capacity.

What this page adds for this card is where its numbers come from. The VRAM budget is set against what RTX 3080 Ti owners' own ComfyUI startup logs report: the card's capacity, per OS, and the VRAM left free on one owner's Windows machine. The page also collects what owners of this card have reported about comfy-kitchen, the library the int8 files run on. The int8 path itself is the one every compute-capability 8.6 card gets, and the page says how to confirm it from the log.

⚠️ 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". The grant is worldwide and there is no clause excluding any territory (section 4.a only reminds you that export controls may apply, and section 8 sets Chinese law and the courts of Hangzhou for disputes). The restriction is on purpose, not on place. Section 4.b reaches outputs in one specific case: "If you use the Materials or any outputs or results therefrom to create, train, fine-tune, or improve an AI model that is distributed or made available, you shall prominently display “Built with Qwen” or “Improved using Qwen” in the related product documentation." Every repack on this page, Comfy-Org's int8 files included, is a derivative and carries the same terms. Section 2.b gives an address for a commercial licence; a reader reports in the vendor's discussion #7 that mail to it bounces. This is a reader's summary of the text, not legal advice.

Hardware data: RTX 3080 Ti (12 GB VRAM, GA102, compute capability 8.6) · not measured on this card by this site · int8 DiT 6.758 GiB + int8 text encoder 8.709 GiB = 15.467 GiB, more than the 11.999 GiB this card reports, so the two take turns · See benchmark data

ℹ️ Nothing on this page was measured on an RTX 3080 Ti by this site. Every VRAM figure below is arithmetic from byte counts, from ComfyUI's source at tag v0.37.0 and from other people's public startup logs of this card, added up unrounded and rounded once. No timed run or memory reading of Qwen-Image-2.1 on an RTX 3080 Ti, or on the RTX 3080 12GB (the other 12 GB GA102 card), turned up on 2026-09-23 in these places: all 80 threads opened on the ComfyUI tracker since 2026-09-19, the 57 discussions on Qwen/Qwen-Image-2.1, Comfy-Org/Qwen-Image-2.1 and Comfy-Org/Qwen3-VL, the 36 discussions on the 67 community quantisation and distillation repos published since the release, the 196 comments of the Hacker News launch thread, the vendor's 11 GitHub issues, and one web search. Reddit refused this session. If you run it, post your numbers.

ℹ️ The two places this page uses measurements from this site, both from a different card. The site's operator ran the template on one RTX 5060 Ti 16GB (Blackwell), in two sessions published as raw data. This page uses two facts from them, and names the card and links the sessions at every use: (1) the int8 template took 21.4 s cold on a cu130 build against 69.4 s on a cu128 build (Installation, step 2, and the Troubleshooting entry on the cu130 WARNING); (2) on that card int8 was faster than bf16 on cu130 and slower on cu128, cited in step 2 only to say it does not transfer to this card. One rig, one operator, unreplicated, and neither is an estimate for this card.

Requirements

min_vram_gb is 12, the same as this install's floor on this model's RTX 3060 page: 12 GB is the smallest card size in this catalogue on which every stage keeps its weights whole under both of ComfyUI's loaders. The tables below re-derive it for this card.

The card, from primary sources

• Ampere, compute capability 8.6, 12 GB GDDR6X on a 384-bit bus, 10,240 CUDA cores, "PCI Express Gen 4". Those are the values on NVIDIA's own spec page, which prints CUDA Capability 8.6 for this card. The number that matters is 8.6: Ampere has INT8 tensor cores and no FP8 or FP4 ones, and ComfyUI decides per device which weight formats run natively from exactly that.
• GA102. The PCI ID registry lists device 10de:2208 as GA102 [GeForce RTX 3080 Ti] (pci.ids). The same file lists 10de:220a as GA102 [GeForce RTX 3080 12GB], and NVIDIA's page gives that card 12 GB GDDR6X on the same 384-bit bus. That makes the RTX 3080 12GB the one other consumer card with this die and this capacity; the RTX 3090 and 3090 Ti are GA102 too, but 24 GB. The RTX 3080 12GB is not in this site's catalogue, and nothing for it turned up either.
• What ComfyUI sees on this card. Among the 21 ComfyUI tracker threads that a search for "Total VRAM" "3080 Ti" returns, 14 users posted 15 startup readings from a desktop RTX 3080 Ti: 13 Total VRAM log lines, all reading 12,287 or 12,288 MB, and two system-information blocks that agree with them. 14 of the 15 come from Windows (Windows paths, an MSC-built Python, the portable's python_embeded, or comfy-aimdo's Windows source path); one gives no OS; none comes from Linux. The two system-information blocks give the exact byte figure: 12,884,246,528 B = 11.999 GiB (#10525) and 12,884,377,600 B (#7983). The five logs from an RTX 3080 Ti Laptop GPU in the same search read 16 GB; that is a different card, and they are left out. This page budgets on the lower exact figure, 12,884,246,528 B.
• What is left for ComfyUI on one Windows machine. #10525's snapshot, taken with ComfyUI running and PyTorch holding nothing (Torch VRAM Total: 0), shows 11,609,833,472 B = 10.812 GiB free. The desktop, the CUDA context and whatever else was running took 1,274,413,056 B = 1.187 GiB there. That is one owner's machine, with whatever display they had attached, not a promise about yours. The Windows columns below use it as a realistic usable pool.
• Linux. No Linux startup log of this card was found, so the Linux columns use the Windows capacity and subtract nothing for a desktop: read them as upper bounds. For scale, Linux can report less than Windows on a 12 GB Ampere card. The lowest Linux figure the RTX 3060 12 GB logs in the same tracker is 12,478,906,368 B = 11.622 GiB (#12774), 405,340,160 B = 0.378 GiB under this card's Windows figure. That is a different card, used here only to size the uncertainty.

The three files

Byte-exact from the Comfy-Org repack's tree API at revision ace0edeb. The repo's head moved to 5dc5850e on 2026-09-22 with a README change only: every weight file's size and LFS hash is the same at both revisions (read 2026-09-23).

The same repo holds a bf16 DiT (14,230,280,616 B = 13.253 GiB, past this card on its own), a bf16 encoder (17,534,334,616 B = 16.330 GiB), a w4a8 encoder (6,312,105,364 B = 5.879 GiB, the one alternative that matters here), and two qwen3.5_9b_…_pe_… files, which are prompt enhancers, not encoders. Its recursive tree lists ten files, and its two DiT builds are bf16 and int8; there is no fp8 or nvfp4 DiT in it, and none of the other five Comfy-Org/Qwen-Image* repos holds a file with 2.1 in its name.

The ComfyUI docs page for this model now agrees with the templates. Since a docs commit at 07:39Z on 2026-09-22 (source) it says "All of them use the int8 versions of the diffusion model and the text encoder by default." It lists the int8 encoder as the one the templates load and the bf16 encoder as the higher-memory alternative. On this card the bf16 encoder cannot be resident at all.

What actually gates this card

ComfyUI has two loaders, and they budget VRAM differently. The default is DynamicVRAM: main.py at v0.37.0 enables it on any NVIDIA device once PyTorch is 2.8 or newer and comfy-aimdo initialises. You land on the legacy estimate-based loader instead if you pass --disable-dynamic-vram (or --highvram, --gpu-only, --novram, --cpu), or if the startup log says Falling back to legacy ModelPatcher. Both views come from ComfyUI's source at tag v0.37.0 (comfy/model_management.py, comfy/model_base.py, comfy/sampler_helpers.py, comfy/sd.py, comfy/model_patcher.py), from comfy-aimdo v0.5.5 (the version requirements.txt pins) and from the byte counts above.

DynamicVRAM (the default). ComfyUI's own memory estimates do not govern this loader. load_models_gpu() still computes a reserve and passes it down, but ModelPatcherDynamic.partially_load() accepts that extra_memory argument and never uses it, and free_memory() does not unload one dynamic model to make room for another; the comment there says "don't actually unload dynamic models for the sake of other dynamic models". The floor is comfy-aimdo's, and it differs by OS. On Linux, src/plat.h defines VRAM_HEADROOM (256 * 1024 * 1024), 0.25 GiB, kept free against the card's live free VRAM, i.e. after whatever the desktop and the CUDA context already hold. The Windows build uses src-win/shmem-detect.c instead, which keeps 512 MiB (0.5 GiB) free against both the WDDM budget and NVML's free-VRAM reading. --reserve-vram N only raises a second, capacity-based term (comfy-aimdo's own control.py says a value below 256 MB changes nothing), and --vram-headroom N adds N GiB on top of both. Weights are loaded on demand and evicted when an allocation needs the room: the comfy-aimdo README describes "on-demand offloading of model weights when the primary pytorch VRAM allocator comes under pressure". So a stage never fails for want of room for its weights. What the table tells you is whether its weights can stay resident for the whole stage.

Every row is weights plus headroom only. On this loader the real activations, the encoder's working memory and the decode's working memory come out of the "left" column, and nothing sizes them in advance. For scale, ComfyUI's legacy planning figures are 0.960 GiB of sampling activations at 1024² and 3.840 GiB at 2048² (both at double batch, below), and 1.758 GiB and 7.031 GiB for the VAE decode; on this loader those figures decide nothing.

Legacy loader (only if you are on it). Here ComfyUI's reserve and estimates are real, and they come from comfy/model_management.py L877-L891. minimum_inference_memory() is 0.8 GiB plus EXTRA_RESERVED_VRAM. That reserve is 400 MiB on Linux; on Windows it is 600 MiB, and a further 100 MiB is added only when total VRAM exceeds 15×1024 MiB, which this card does not. So the reserve is 1.191 GiB on Linux and 1.386 GiB on Windows. Two estimates feed it:

• The sampler's activations: area × dtype_size × 0.01 × memory_usage_factor MiB, with memory_usage_factor = 6.0 for this model and area the latent grid (64×64 = 4,096 tokens at 1024², 128×128 = 16,384 at 2048²; the VAE downsamples 16× and the transformer uses patch size 1). comfy/sampler_helpers.py L177 computes the estimate at double batch, even at cfg 1: 0.960 GiB at 1024² and 3.840 GiB at 2048². It also computes a batch-1 minimum, 0.480 GiB and 1.920 GiB. The formula carries its own comment, "this needs to be tweaked".
• The VAE decode: 900 × h × w × 256 × dtype_size bytes over the latent grid in comfy/sd.py: 1.758 GiB at 1024², 7.031 GiB at 2048². On this loader the VAE is an ordinary model and this is its reserve.

The loader keeps a model whole only if its weights fit in the free memory minus the larger of the reserve and "batch-1 minimum + EXTRA_RESERVED_VRAM". Those totals are its residency thresholds:

Before loading, the same function asks free_memory() for 1.1 × the model's weights plus the larger of the reserve and "double-batch estimate + EXTRA_RESERVED_VRAM", and unloads other models until that much is free or nothing is left to unload. That request only decides how much else is unloaded; if it cannot be met, the threshold above decides residency. It is the stricter figure: at 2048² sampling the request is 11.665 GiB on Linux and 11.860 GiB on Windows, and for the int8 encoder it is 10.770 GiB and 10.965 GiB, 0.153 GiB more than the one Windows machine has free. On that machine the loader therefore unloads everything else before the encode and then keeps the encoder whole, with 0.718 GiB to spare.

The encoder and the DiT never sit on the card whole at the same time. Together they are 16,607,581,424 B = 15.467 GiB, 3,723,334,896 B = 3.468 GiB more than the card's whole capacity, before any headroom, a desktop or a CUDA context. Even with the w4a8 encoder the pair is 13,568,888,428 B = 12.637 GiB, 684,641,900 B = 0.638 GiB over. So on this card they take turns under either loader. On the default loader comfy-aimdo evicts weights as allocations need the room; on the legacy loader free_memory() unloads the other model. A new prompt re-runs the encoder, so its weights come back onto the card, and the DiT's come back when sampling starts; a seed-only change reuses the cached conditioning. That order is an inference from the arithmetic and the code, not a measurement.

The encoder stage is the binding one in both views: 9.209 GiB of weights and headroom on Windows under DynamicVRAM, 10.095 GiB under the legacy loader, against 10.812 GiB free on the one Windows machine. Neither loader budgets for the encoder's own activations, so an edit with several large reference images, which all pass through the encoder's vision tower, has an unestimated working set on top.

Why 12 GB is the floor. On 12 GB every stage keeps its weights whole under both loaders, as the two tables show. On 8 GB the template's int8 encoder cannot stay on the card: 8.709 GiB of weights alone exceeds it, so DynamicVRAM would evict and re-read it part-way through every encode, which nobody has measured. The RTX 5060 page in this series documents the install aimed at 8 GB (the w4a8 encoder).

At 2K the two loaders part ways. On the legacy loader the 2048² decode reserve is 7.031 GiB, and with the DiT resident the decode would need 15,901,470,352 B = 14.809 GiB on Linux, over the whole card, so free_memory() unloads DiT weights before the decode, copying them back to system RAM (legacy partially_unload moves each module with .to()). On the default loader the VAE is a dynamic model too: its branch in comfy/sd.py never sets disable_offload, so it is built with the patcher DynamicVRAM swaps in. There free_memory(for_dynamic=True) does not unload the DiT for it, and the decode reserve only sizes the decode batch (comfy/sd.py L1260-L1265). Whether any DiT weights leave the card at 2K therefore depends on the decode's real working memory, which nobody has measured on this card; if they do, comfy-aimdo frees those pages without copying them anywhere. ComfyUI also keeps a fallback for a decode that runs out anyway: it logs "Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding." and tiles it. So 2K should complete; whether it completes in one pass on this card is exactly what nobody has measured.

Installation

1. ComfyUI v0.37.0 or newer, on a cu130 PyTorch

Support landed in ComfyUI core with PR #16400 (author kijai, merged 2026-09-19), and tag v0.37.0 contains it: the compare view shows the tag eight commits ahead of that merge and none behind. The v0.37.0 release was published at 07:35 UTC on 2026-09-21 with Windows portable builds, and it was still the latest release when this page was written (2026-09-23, 06:09Z). A tag v0.37.1 (commit 3f767e7f67) was cut at 19:12Z on 2026-09-22 with no release object or portable build. Its three commits are Hunyuan Image 3.5 partner nodes, a workflow-templates pin moved from 0.11.66 to 0.11.68, and the version bump. None of them changes the model's code or any of the three Qwen-Image-2.1 workflow files. The backport pull request for it, PR #16467, was closed without merging.

Windows portable. Take ComfyUI_windows_portable_nvidia.7z from that release. The ComfyUI README at the tag says "The portable above currently comes with python 3.13 and pytorch cuda 13.0.", which is the build this card needs. Do not take ComfyUI_windows_portable_nvidia_cu126.7z: the README labels it for 10-series and older cards, adding "DO NOT USE THIS ON NEWER 20 SERIES AND ABOVE GPUS", and on this card a CUDA 12 build switches off the fast int8 kernels (step 2).

Git (Linux; on Windows use the portable, or swap the activation line as noted in the block). Install PyTorch from the cu130 index first, then the requirements. The torch line in requirements.txt is unpinned, so the order decides which build you get:

git clone https://github.com/Comfy-Org/ComfyUI
cd ComfyUI
git checkout v0.37.0
python -m venv venv
source venv/bin/activate    # Windows cmd/PowerShell: venv\Scripts\activate
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.get_device_capability())"
git describe --tags

The print must show a +cu130 torch, 13.0 and (8, 6) (the cu130 index carries builds from torch 2.9.0 to 2.14.0), and git describe must read v0.37.0. The README states the requirement as policy, "Using a cu130 or above version of pytorch is required on Nvidia 20 series and above.", and a CUDA 13 build needs an NVIDIA driver from the 580 branch or newer, the minimum NVIDIA's CUDA release notes give for CUDA 13.x. A ComfyUI maintainer put the same policy plainly on 2026-09-21, in a thread from a user whose NAS driver stops at CUDA 12.9 (#16449, on an sm_86 card with 12 GB): "We only offer minimal support for cuda 12 on older GPUs that don't support cuda 13. We do not support using cuda 12 on newer GPUs." requirements.txt at the tag pins comfy-kitchen==0.2.35, comfy-aimdo==0.5.5 and comfyui-workflow-templates==0.11.66; the last is the templates release that switched the Qwen-Image-2.1 templates to the int8 encoder. Leave this shell open with the venv active: step 3 runs in it.

Tag or master? Stay on the tag. Among the changes that merged into master after it, three touch the 2.1 transformer file: PR #16429, which changes where the edit path's K/V cache is placed (see Editing), PR #16430, which adds ComfyUI's memory compiler to the 2.1 transformer blocks, and PR #16419, which lets a model file choose the attention per block. master also carries the code path of two open hard crashes (Troubleshooting): issue #16443 on image editing, and the one PR #16481 describes on the second generation. The tag has neither fix, and it is not known to be immune to the second one (see its entry). Nothing on this page needs master.

2. What Ampere gets from the int8 files, and what it does not

Read this before choosing an encoder, because the file names invite the wrong choice. Both int8 files carry, per layer, the quantisation format int8_tensorwise with convrot: true and a group size of 256 (read from each file's safetensors header). What happens to those weights differs between the two models.

For the diffusion model, the formats run natively here. ComfyUI decides per device in get_disabled_quant_formats() in comfy/ops.py, from checks in model_management.py. For compute capability 8.6 they resolve like this: supports_fp8_compute() is False (major 8, minor below 9), supports_nvfp4_compute() and supports_mxfp8_compute() are False (major below 10), and supports_int8_compute() is True; it has no compute-capability test and excludes only MPS, Intel XPU, DirectML and ixuca. ComfyUI prints the result when it loads the model. The line an RTX 3080 Ti owner posted in #15591 (ComfyUI 0.33.0, torch 2.11.0+cu130, Windows portable) is the one to expect:

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

v0.37.0 defines the same seven formats in comfy/quant_ops.py and gates them with the same functions; the order varies because the line prints a set. An emulated layer's weight is dequantised to bf16 for the matmul.

With a cu130 PyTorch, comfy-kitchen runs them on its CUDA kernels. At v0.2.35 (pinned by commit, backends/cuda/__init__.py), int8_linear is registered for compute capability 7.5 and up; the activations are rotated and quantised in a fused kernel, and the GEMM goes through its CUTLASS INT8 path, which the source enables for compute-capability major 8 and above. The default build targets in setup.py include 80-real, and NVIDIA's Ampere compatibility guide says a cubin runs on any GPU with the same major and the same or a higher minor compute capability, which covers this card's 8.6. #15591's log shows the result on this card: Found comfy_kitchen backend cuda: {'available': True, 'disabled': False, ...}.

The kernel's tile choice is not tuned per chip; in the one sweep found in comfy-kitchen's tracker, measured on an RTX A6000, this model's attention shapes lose about 1%. comfy-kitchen 0.2.35 picks the CUTLASS INT8 tile configuration from one decision tree for every device (cutlass_gemm_int8.cu). An open community pull request, comfy-kitchen #142 (unmerged), adds a branch for compute capability 8.6, i.e. every 8.6 card, the RTX 3060 included, fitted from a sweep on an RTX A6000 (a workstation card on this card's GA102 die). The PR says that on its worst shapes the current pick loses 44–50% to a better tile, and its summary table lists speedups from 1.06× to 1.90× (the largest at 274×2048×2048); its rows are taken from LTX 2.5 and MiniMax H3. Its committed table also holds the shapes of this model's attention projections on cached steps, where only the image's latent tokens run: 4096×4096×4096 at 1024² and 16384×4096×4096 at 2048² (to_q, to_k, to_v and to_out, four of the six quantised linears per block). By this page's reading of the shipped tree against those A6000 timings, its pick is 1.0% slower than the table's best at the first shape and 0% at the second; these are A6000 timings, not a figure for this card. The two MLP shapes are not in the table. This is a small, unmeasured question about speed, and the same on every 8.6 card.

Without cu130 nothing breaks for the diffusion model; it runs the slow way. The gate is in comfy/quant_ops.py: below CUDA 13 it calls ck.registry.disable("cuda") and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." comfy-kitchen then falls through to its eager int8_linear, which applies the rotation as ordinary torch ops and still runs an integer GEMM through torch._int_mm. That is a working INT8 path with the fusion gone, not a dequantisation to bf16. The Native ops line will not warn you, because it reflects the hardware, not which backend is alive; the tells are the WARNING and 'disabled': True on the backend line. How much slower that is on this card is not measured. On a different card, the site operator's RTX 5060 Ti 16GB (Blackwell), the template's 1024×1024 image took 21.4 s cold on a cu130 build against 69.4 s on a cu128 build that printed the warning (cu130 session, cu128 session; one rig, one operator, unreplicated, and the two installs also differ in ComfyUI build and Python). It shows the gate is worth checking, not what it costs here. On that same RTX 5060 Ti, int8 was faster than bf16 on the cu130 build and slower on the cu128 one (cu130 session, cu128 session; one rig, one operator, unreplicated). That is a Blackwell result, and no comparison of the two files on an Ampere card turned up in the places listed at the top. One more path does break without cu130: #16449 reports that on v0.37.0 with a cu128 build and a driver older than 580, any node that generates text with a Qwen3-VL encoder (the prompt enhancers' TextGenerate path, which this page does not install) fails on its first decode step with CUDA driver version is insufficient for CUDA runtime version. Text encoding for image generation was unaffected.

For the text encoder the table above does not apply. At v0.37.0 every quantised encoder is built with mixed_precision_ops(..., full_precision_mm=True) in comfy/sd1_clip.py, so each weight is dequantised for its matmul on every card. The one call that switches quantised matmuls back on, use_quantized_matmul, wraps only generate(), i.e. LLM text generation, not the conditioning encode this model uses. The encoder's file format is therefore a memory choice, not a speed choice:

• The int8 DiT is the right file here, not a compromise. Its matmuls run as INT8 GEMMs on this card's INT8 tensor cores. One dissent turned up in the places listed at the top: on the repack's discussion #13 a user writes that "Int8 ConvRot is significantly slower on non blackwell or enterprise GPUs", with no numbers and no card named. Their follow-up points to two reports: a Turing RTX 2080 Super owner on discussion #8, and #16470, an RTX 5060 Ti on a cu128 build. In both, the reply pointed to the cu130 requirement. No int8-against-GGUF or int8-against-bf16 comparison on an Ampere card with a cu130 build turned up in the places listed at the top.
• For the encoder, pick by size. Comfy-Org's encoder repo Comfy-Org/Qwen3-VL (revision 02f0d3ee) also holds qwen3vl_8b_fp8_scaled.safetensors (10,588,637,512 B = 9.861 GiB) and qwen3vl_8b_nvfp4.safetensors (6,305,221,764 B = 5.872 GiB). Both carry the DeepStack key and the 4096-wide merger that comfy/sd.py uses to identify Qwen3-VL-8B, so under type: qwen_image they would be routed to the 2.1 encoder class. No report of either being used with 2.1 turned up in the 57 discussions or the 80 tracker threads listed at the top; a June thread on that repo says the nvfp4 file did not work with Krea 2, a different model. The fp8 file is 1.153 GiB larger than the int8 one, and the nvfp4 file is within 7 MB of the w4a8 encoder that ships beside the int8 one. If the encoder stage is what you need to shrink, take w4a8: it saves memory, not time.

Why the encoder identity is worth a paragraph: Comfy-Org's qwen3vl_8b_bf16.safetensors in the 2.1 repo carries the same LFS sha256 (68bdc82b…) as the file of that name in Comfy-Org/Qwen3-VL, uploaded there months before the 2.1 weights were public to a repo whose card lists Qwen/Qwen3-VL-8B-Instruct as a base model. Two readers who compared the tensors reached the same answer on the vendor's discussion #5: "我比较过 tensor 数值 原版 instruct 没有增量训练" (FIT17, community: compared the tensor values, the original Instruct, no incremental training), and a second reply reports a tensor-by-tensor comparison with identical hashes. The encoder is the stock model, which is why encoder quants from the older repo are interchangeable in principle.

3. Download the weights

The repo's folder names match ComfyUI's models/ layout, so --local-dir models lands each file where the loaders look. On a git install, run this from inside the ComfyUI folder with the venv active, the shell step 1 left you in. The revision pin is the one whose byte counts are in the table above:

pip install -U huggingface_hub
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

On the Windows portable there is no pip or hf on PATH. Use the Python the portable ships, python_embeded\python.exe, the same interpreter its run_nvidia_gpu.bat starts ComfyUI with and its updater runs pip through, from the portable's top folder (the one holding python_embeded and ComfyUI):

python_embeded\python.exe -s -m pip install -U huggingface_hub
python_embeded\python.exe -s -m huggingface_hub.cli.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 ComfyUI\models

(-m huggingface_hub.cli.hf is the module behind the hf command; it runs directly because cli/hf.py ends in a __main__ guard.)

Then check the bytes against the LFS hashes. On 17 GB this is worth doing, and it is the first thing to try for a load error (Troubleshooting). On Windows, certutil -hashfile <file> SHA256 prints the same hash.

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

If you settle on the smaller encoder, the fourth file is text_encoders/qwen3vl_8b_w4a8.safetensors from the same repo; select it in the template's CLIP loader. Do not confuse it with the two qwen3.5_9b_qwen_image_2.1_pe_*.int8_convrot.safetensors files beside it: those are Qwen3.5-9B prompt-rewriting models for an optional LLM stage, and a reader on the repack's discussion #4 who swapped one in as the text encoder got garbled images. As another reader put it in the same thread, "The PE models only for PE." (Landsharkbaby, community). At 9,471,072,252 B each they are another encoder-sized load on a card that already cannot hold one beside the DiT; skip them here.

Running

Start ComfyUI normally, with no --lowvram, no --reserve-vram, nothing: python main.py in the same shell, or run_nvidia_gpu.bat on the portable. On this card the first screen of the log should show:

• Device: cuda:0 NVIDIA GeForce RTX 3080 Ti : cudaMallocAsync. If it says Laptop GPU, you have the 16 GB laptop chip, and the budget on this page is not yours.
• Total VRAM 12288 MB (or 12287) on Windows, as in all 14 Windows logs above.
• pytorch version: ending in +cu130, and no line starting "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations."
• Found comfy_kitchen backend cuda: {'available': True, 'disabled': False, ...}. The cu130 gate leaves the backend available and sets disabled, so checking available alone proves nothing.
• DynamicVRAM support detected and enabled and ComfyUI version: 0.37.0.

On the first generation, Using mixed precision operations is followed by the Native ops line from step 2.

--lowvram is documented in comfy/cli_args.py as "Doesn't do anything if dynamic vram is enabled.", so adding it out of 12 GB habit changes nothing. You do not need a flag for the desktop: comfy-aimdo's live check keeps 0.25 GiB free on Linux (0.5 GiB on Windows) after whatever the desktop already holds, though the desktop still comes out of the card's capacity. If you want more kept free anyway, use --vram-headroom N, which adds N GiB on top of both of comfy-aimdo's checks.

Text-to-image

Open the Template Library and load Qwen Image 2.1: Text to Image (image_qwen_image_2_1_t2i.json, read at workflow-templates v0.11.66, the version v0.37.0 pins, and unchanged in 0.11.68). The values that govern it sit on the outer subgraph node: UNETLoader → qwen_image_2.1_int8_convrot.safetensors, CLIPLoader → qwen3vl_8b_int8_convrot.safetensors with type qwen_image, VAELoader → qwen_image_2.1_vae_bf16.safetensors, 25 steps, cfg 1, euler / simple, 1024×1024. The template's own note explains the setting people change first: "negative_prompt: unused while cfg is 1." At cfg 1 ComfyUI skips the negative pass entirely; raising cfg adds a second model pass on every step. The vendor's diffusers example runs 40 steps; the template's 25 is ComfyUI's choice, not Qwen's.

On the repack's discussion #11, one user reported faint banding on skin, fabric and fur at the template's 25 steps at 1024×1024, with both the int8 and the bf16 files and both schedulers they tried; they wrote that the "Artifact disappeared completely at 40" steps. Later the same day, after trying another user's posted workflow and toning down a prompt they called too "high definition", the same poster wrote that they "see no streaks". A third user advised 40 steps on 2026-09-23. So two remedies are reported, from a handful of users, with no maintainer reply (read 2026-09-23). More steps cost time in proportion.

A step-distilled option for 2.1 appeared on 2026-09-22: Viggle/Qwen-Image-2.1-viggle-turbo, a third-party 4-step distillation by Viggle, shipped as a rank-64 LoRA and as a full bf16 transformer and labelled a v0.1 preview. Its card says the release "still falls short of the base model": text-to-image at 4 steps is usable, complicated edits are clearly worse. The card documents diffusers only, with its own scheduler setting, and names no ComfyUI workflow; nothing on this page was run with it. Since 22:57Z that day, realrebelai/Viggle_Qwen-Image-2.1-Turbo_GGUFs holds GGUF conversions of that full transformer, Q2_K to Q8_0, for ComfyUI-GGUF; its own card says that, in the uploader's testing, even a BF16-equivalent GGUF conversion, before any lower-bit quantisation, did not reproduce the upstream transformer's output exactly.

For native 2K the template note says "For native 2K, set 1:1 and 4 megapixels". The sampling schedule does not follow the resolution: ComfyUI fixes this model's shift at 0.69 at every size, while the vendor's scheduler shifts dynamically. Issue #16447 (open) reports the mismatch, and a ComfyUI maintainer replied: "This is kind of on purpose, the higher the shift the more you see a grid pattern". A second user answered that the fixed shift makes images far noisier than they should be.

For a transparent image, wrap the prompt the way the model card does, This is an RGBA image with transparency. <your subject>. The image has alpha channel and the background is transparent., and keep the template's SaveImageAdvanced at PNG, 8-bit, sRGB, which keeps the alpha channel.

Editing with reference images

Load Qwen Image 2.1: Image Edit (image_qwen_image_2_1_image_edit.json, same release). Same three loaders, plus a TextEncodeQwenImage21 node with the VAE connected and resolution 0, and a QwenImage21Cache node at auto / default. The template's note says why the resolution is 0: "This template starts at 0: no resize beyond a multiple of 32." Reference images are seen by the encoder's vision tower and, because the VAE is connected, spliced into the sequence as latents. The text and reference tokens are the same on every step, so their attention K/V are computed once and cached; PR #16400 puts the gain at about 1.7× on edits. The cache node's tooltip in comfy_extras/nodes_qwen.py on where that cache goes: "auto uses spare VRAM, then RAM. cpu (RAM) is prefetched behind compute and costs little speed."

On 12 GB, where the cache lands decides the speed. The cache costs 2 × 32 layers × 4096 × 2 bytes = 524,288 B per cached token in bf16, half that with the node's dtype int8 (comfy/ldm/qwen_image21/model.py). At v0.37.0, auto places it on the GPU only if four times its size is free there, then in system RAM under the same rule, and otherwise recomputes the prefix on every step. An explicit device skips that test and asks for twice the size free. The template's two reference images are 896×1152 each. If the DiT's 6.758 GiB are on the card when the check runs, the GPU has at most 4.054 GiB free on the one Windows machine above (5.241 GiB on Linux, before any desktop), and:

So for the template edit auto cannot choose the GPU on this card: even the int8 cache at resolution 0 would need 7.875 GiB free beside the DiT, more than the card has. It chooses RAM only if four times the cache is free there (15.750 GiB for the default-dtype cache at resolution 0), and otherwise recomputes. device gpu with dtype int8 fits on paper at resolution 512, and at resolution 0 by 0.117 GiB on the one Windows machine, before the prompt's own tokens. At 1056 it misses that machine's free VRAM by 0.137 GiB, and the node then recomputes, which is the slowest case. device cpu needs twice the cache free in RAM and copies it to the card on each cached step; the tooltip says that costs little speed, and nobody has timed it on this card. None of this has been run on this card. The author of PR #16429, which reworks this check on master only, lists as one of its problems: "It requires the VRAM to be free at the time of the check to use VRAM mode which gets disrupted by smart memory + dyn vram". On that PR's own test machine, an RTX 5080 with 32 GB RAM (a newer and faster card than this one), an edit with two references went from the full-recompute fallback at 4.01 s/it to 1.02 it/s. The tooltip for dtype says int8 halves the cache at about bf16 accuracy.

Set resolution to 1056 or 512 if edits come out speckled. Issue #16435 (open, read 2026-09-23) reports broken edits with the VAE connected at particular reference grids, and its two reports disagree on which. The original reporter (Apple MPS and CPU, bf16 DiT) got broadband noise whenever the reference resolved to a 64×64 latent grid, a 1024×1024 reference at resolution=0 or resolution=1024, while 512, 992 and 1056 were clean. A second reporter on CUDA (an RTX 5070 Ti, v0.37.0, torch 2.13.0+cu130, the official edit graph with a bf16 DiT) found that grid clean, but a 1536×1024 reference (grid 96×64) broken, over-sharpened and with the edit instruction ignored, at both resolution=0 and resolution=1248; 512, 1024, 1056 and 2048 were clean there. 512 and 1056 are clean in both reports. The template's own 896×1152 references resolve to neither failing grid at resolution 0. The two setups differ in backend, encoder precision, reference image, OS and ComfyUI build, so neither report isolates a cause, and nobody has reported on an RTX 3080 Ti or any Ampere card. A proposed fix, PR #16444, was closed without merging on 2026-09-22 by kijai; no fix is linked to #16435 now.

Smaller builds: what they change on 12 GB

The binding stage on this card is the text encoder, so a smaller transformer does not move the ceiling; the encoder is the lever (w4a8, above). What a smaller DiT could change is 2K on the legacy loader, where a DiT small enough to stay beside the 2048² decode is not unloaded and re-read for every image. That needs its weights to fit beside the decode's free_memory() request, 1.1 × 0.629 GiB of VAE + 7.031 GiB + EXTRA_RESERVED_VRAM: that leaves 3.885 GiB on Linux (upper bound) and 2.503 GiB on the one Windows machine. On the default loader the decode reserve decides nothing, so the arithmetic cannot say.

The Windows column already has one desktop subtracted; the Linux one has none, and whatever is left there must also hold the CUDA context and any desktop. In practice, then, only the Q2 class stays beside a legacy 2K decode on a Windows desktop, and barely. That is a lot of quality to give up to save one reload per 2K image. None of these builds has a published run on a named 12 GB or Ampere card: the cards named in the 36 discussions on the 67 quantisation repos include an RTX 3060, a 3090 Ti, a 4070, a 4070 SUPER, a 5070 Ti and an AMD RX 9070, each for a different build or an error, and no RTX 3080 Ti.

• GGUF, and which loader reads it. Abiray/Qwen-Image-2.1-GGUF (Q8_0 7,591,579,808 B = 7.070 GiB down to Q3_K_M) and realrebelai's files declare general.architecture = qwen_image in their headers (read over HTTP range requests), which city96's loader.py accepts. leejet/Qwen-Image-2.1-GGUF and unsloth/Qwen-Image-2.1-GGUF carry no metadata keys at all, which sends city96's loader to a key-detection table with no 2.1 entry. City96's repository has had no commit since 2026-01-12; PR #483, which would add that entry, has been open since 2026-09-21 with no comments. leejet's fork reads them. ComfyUI-GGUF dequantises each weight to the compute dtype before the matmul, so Q8_0 saves nothing against the int8 file and gives up the INT8 GEMM.
• INT4 ConvRot (W4A4). toxicdog/Qwen-Image-2.1-INT4ConvRot-ComfyUI ships a DiT whose 193 quantised layers declare convrot_w4a4, native on this card by the table in step 2, and comfy-kitchen's convrot_w4a4_linear takes its native 4-bit MMA path on compute-capability major 8, which covers Ampere and Ada. chfm/Qwen-Image-2.1-INT4ConvRot-ComfyUI holds the same file (same LFS hash). The same repos' INT4 encoder (6,880,836,952 B = 6.408 GiB) is larger than w4a8. Quality at 4-bit activations is the open question.
• The mixed w4a8 build. NidAll's file declares asym_w4a8_int8 on its 192 quantised layers, also native here, and comfy-kitchen registers w4a8_int8_linear for compute capability 8.0 and up. It keeps a native matmul too.
• Not for this card: NVFP4 and FP4. The NVFP4 DiT builds load, but supports_nvfp4_compute() wants major ≥ 10, so on Ampere they are emulated: the memory saving survives and the kernel does not. catplusplus/nunchaku-qwen-image-2.1 ships only FP4 (svdq-fp4_r32) files, a format this card has no hardware for.

Results

• Speed: omitted. No timing of Qwen-Image-2.1 on an RTX 3080 Ti or an RTX 3080 12GB was found in the places listed at the top, and no other card is a stand-in for this page: the RTX 3090 and 3090 Ti share the die but have 24 GB and keep more resident. The figures that exist name other cards: an RTX 4090 (a Hacker News comment on the launch thread), an RTX 4060 Ti 16GB (vendor discussion #35), an RTX 5080 (PR #16429) and an RTX 5090 (PR #16430). If you time a run, with steps, resolution, seconds per image and whether the decode fell back to tiled, post it; it becomes the first datapoint on /check/qwen-image-2-1/rtx-3080-ti.
• VRAM usage: derived, not measured by this site. The binding stage is the text encoder. Under DynamicVRAM, the default: 8.709 GiB of weights plus comfy-aimdo's headroom, 9.209 GiB on Windows, which leaves 1.604 GiB of the 10.812 GiB free on one owner's machine, for the encoder's activations and anything else; on Linux 8.959 GiB, with at most 3.041 GiB left of the card before any desktop. Under the legacy loader: 8.709 GiB plus its reserve, 10.095 GiB on Windows (0.718 GiB left on that machine) and 9.899 GiB on Linux (at most 2.100 GiB left). Sampling needs the DiT's 6.758 GiB, plus on the legacy loader 1.386 GiB kept free at 1024² and 2.506 GiB at 2048² on Windows (1.191 and 2.311 GiB on Linux). At 2048² the legacy loader moves DiT weights off the card for the decode; on the default loader that depends on the decode's real working memory. No VRAM reading at native 2K on any 12 GB card was found in the places listed at the top.
• Quality notes: the VAE has a reported grid artifact. The vendor's discussion #12, titled "Diamond grid pattern caused by VAE", says "It's more noticeable when you generate a high-resolution image that has people with light skin tones and zoom in on their faces." (Rkss, community), and that a plain encode–decode round trip shows it. A reply lists mitigations (a GLSL post-process node, a node pack, or re-encoding through the Flux VAE), none of them a fix and none tied to a resolution or a card. Asked whether the VAE or the transformer is responsible, the thread's author answered that it is the VAE; a later comment reports a 16-pixel stripe pattern on a different model's fine-tune that came from its diffusion model instead, so treat the cause as the thread's reading, not settled. No one from Qwen has replied (read 2026-09-23). Inspect native-2K portraits at 100%. The banding at 25 steps above is a separate report.

For the full benchmark data, see /check/qwen-image-2-1/rtx-3080-ti.

Troubleshooting

TextEncodeQwenImage21 or QwenImage21Cache missing when the template loads

You are below v0.37.0. Take the v0.37.0 portable, or on a git install update to a tag rather than with a bare git pull, which lands on master (see Tag or master?): git fetch --tags && git checkout v0.37.0 && pip install -r requirements.txt, then restart and check the version line. The ComfyUI docs page lists not running the latest version as the first reason nodes go missing, and nodes that failed to import at startup as the second.

The startup log prints the cu130 WARNING, or 'disabled': True

That is the quant_ops.py gate from step 2: your PyTorch was built against CUDA 12.x, on Windows usually the cu126 portable. The diffusion model still runs, on the eager INT8 path. Reinstall PyTorch from the cu130 index (or switch to the nvidia portable), make sure the driver is from the 580 branch or newer, and confirm torch.version.cuda prints 13.0. How much the eager path costs on this card is unmeasured; on the operator's RTX 5060 Ti 16GB (a different card) the template image took 69.4 s on cu128 against 21.4 s on cu130 (cu128 session, cu130 session; one rig, one operator, unreplicated). One more report points the same way on that other card: on an RTX 5060 Ti with a cu128 build, issue #16470 found the int8 file slower than a Q8_0 GGUF at 1760×2368, and kijai, a ComfyUI collaborator and the author of the core support, replied there on 2026-09-22: "You need pytorch with cu130 for int8 models to work properly." A different line, Failed to import comfy_kitchen, is worse: the int8 formats these files use are defined by that package, so fix the import (pip install -r requirements.txt in the ComfyUI venv restores the pinned 0.2.35) before you debug anything else.

The whole system freezes or resets during generation, without a Python error

Not reported with this model, but reported on this card with the same kernel library. Issue #14719 (open, no maintainer reply) comes from an RTX 3080 Ti 12 GB owner running LTX 2.3 video workflows on ComfyUI 0.26 (comfy-kitchen 0.2.10) and 0.27 (comfy-kitchen 0.2.16) with torch 2.10.0+cu130, on Windows 11 and on CachyOS. Repeated runs froze the whole machine, hard resets with no driver error logged, and in the reporter's A/B only disabling comfy-kitchen's CUDA backend stopped it. That included an int8 ConvRot model whose log showed int8_tensorwise running natively, the same kernel path this page's DiT uses. The reporter later wrote that an update of the installer they use (ComfyUI Easy Install 3.10.0) fixed it, and a month later that a clean install runs fine for them with --disable-dynamic-vram --disable-pinned-memory; a later commenter, with no card named, says --disable-pinned-memory ended their freezes, which they saw with MiniMax H3. A second RTX 3080 Ti owner's report, #15591 (open, no replies), describes CUDA error: an illegal memory access was encountered during a DynamicVRAM load of MiniMax H3 with comfy-kitchen 0.2.31 on ComfyUI 0.33.0, fixed for the reporter by going back to comfy-kitchen 0.2.30. v0.37.0 pins newer versions of both libraries (comfy-kitchen 0.2.35, comfy-aimdo 0.5.5), and whether either fault survives in them is not established. If you hit a freeze, try --disable-pinned-memory first, then --disable-dynamic-vram, which puts you on the legacy loader and its budget in Requirements.

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

Issue #16472 reported this for qwen3vl_8b_int8_convrot.safetensors from the edit template. kijai replied on 2026-09-22: "This is most likely a corrupt/incomplete model file." The reporter re-downloaded the file, it loaded, and the issue was closed that evening. Check the file's sha256 against step 3 and re-download it if it differs.

Edit output is over-sharpened and speckled, or ignores the edit; text-to-image is clean

Issue #16435, under Editing: set resolution to 1056 (or 512, which shrinks the references). Disconnecting the VAE from TextEncodeQwenImage21 also removed the artifact in the original report, at the cost of reference adherence (on CUDA the requested edit was no longer performed at all).

Edits are far slower than text-to-image

Most likely the K/V cache found no room and fell back to recomputing the prefix every step; see the table under Editing. At the template's resolution 0, set QwenImage21Cache to device gpu and dtype int8; at 1056, or with more or larger references, device cpu is the setting that avoids the recompute on this card, if twice the cache is free in RAM. device off makes the recompute permanent; the node's tooltip calls that the way to rule the cache out.

On master: Fatal Python error: Aborted, at 0/25 when editing or at the end of the second generation

Two open reports, both on master code, both from other cards:

• At 0/25, on image editing. Issue #16443, open, read in full on 2026-09-23 (last comment 2026-09-22T14:08Z). The reporter corrected the description to image editing: "I have not confirmed this crash with pure text-to-image generation." Two users report it, each with an RTX 5060 Ti 16 GB in a two-GPU machine; the second also has an RTX 3060 12 GB and does not say which card ran it. On 2026-09-22 both said the crash is intermittent and seems tied to larger input images: one saw it only once the resolution went above 1 megapixel, the other with two inputs of about 1500×1000 and not, so far, with smaller ones. The reporter also started ComfyUI with --cuda-device 0 "to force a single GPU, but the same crash still occurs". The stack ends in the prefix cache's take at qwen_image21/model.py line 353, which runs on every step on master and only on cached steps at the tag. PR #16450 (open, no maintainer review) blames the allocation-recording wrapper that PR #16430 put around the block loop, code that exists only on master.
• At the end of the second generation. PR #16481 (opened 2026-09-22T21:24Z, open, no maintainer review) reports an abort during sampler cleanup on the second generation, text-to-image and edit alike, on Windows 11 with an RTX 5090, torch 2.13.0+cu130, the template's int8 files, DynamicVRAM on and QwenImage21Cache at auto. The report says "ComfyUI 0.37.0", but the line numbers in its stack (qwen_image21/model.py line 238, model_base.py line 2678) are those of post-tag master; at v0.37.0 and v0.37.1 the same calls sit at lines 236 and 2674. The same cleanup code exists at the tag, and no report of the crash at the tag was found. So the tag is not known to be immune.

If you hit either on master, go back to a tag: git checkout v0.37.0 on a git install. On the portable, update_comfyui_stable.bat checks out the highest v* tag, which since 2026-09-22 is v0.37.1, so the startup log will read 0.37.1; its three commits change neither the model's code nor its workflow files (Installation, step 1). If the second one happens at the tag, report it on the PR with your commit.

Shape errors from the text encoder: [1, 338, 5120] or [1, 512, 12288]

[1, 338, 5120]: the CLIP loader was given something other than the 4096-wide Qwen3-VL-8B. The reporter of the repack's discussion #2 saw exactly this error while trying the w4a8 encoder, then closed the thread as having loaded the wrong encoder. Load qwen3vl_8b_int8_convrot.safetensors or qwen3vl_8b_w4a8.safetensors, not a qwen3.5_9b_…_pe_… file.

Given normalized_shape=[4096], expected input with shape [*, 4096], but got input of size [1, 512, 12288]: a Qwen3-VL GGUF encoder in city96's CLIPLoaderGGUF. That loader attaches the vision tower only for qwen2vl (loader.py, pinned above), so ComfyUI builds the wrong encoder. PR #485 (opened 2026-09-23, open) would load it for qwen3vl too. Use one of Comfy-Org's safetensors encoders instead.

2K runs but the log says it retried the VAE decode tiled

That is the fallback working as designed. The decode is slower, and the image should be unchanged. On the legacy loader the 7.031 GiB decode reserve at 2048² is the largest figure on this page, and the loader already moves DiT weights off the card for it. On the default loader that figure only sizes the decode batch and comfy-aimdo pages DiT weights as the decode's real allocations need room. Either way a smaller DiT cannot remove the tiling; what removes it is more free VRAM, so close what else is using the card (a browser with hardware acceleration counts), or render at 2 megapixels first.

Every generation reloads models

Expected when the prompt changes, for the turn-taking reason under Requirements; a seed-only change should not. If a seed-only change also reloads, something upstream of the sampler changes on every run.

Those reloads are the trigger of an open defect. Issue #16437, titled "Qwen-Image 2.1: --enable-dynamic-vram silently corrupts output after any model reload (channel slice offset, ROCm gfx1201)", reports that on an RX 9070 XT the first image after a server start is correct, and every image after the first reload (a prompt change is enough) comes back with its channels in a [B, A, B, A] pattern, subjects rendering bright green, until the server is restarted. Removing --enable-dynamic-vram fixed it for the reporter, who adds "I don't have an NVIDIA card to test whether this is ROCm-specific." No report of it on NVIDIA was found in the 80 tracker threads listed at the top, and the one other commenter was running a different model on another AMD card. If your images turn green or wrong-coloured after a prompt change, restart ComfyUI; if it keeps happening, start it with --disable-dynamic-vram, which puts you on the legacy loader and its budget in Requirements.

GGUF: This model is not currently supported - (Unknown model architecture!)

A metadata-free GGUF (leejet's, unsloth's) in city96's loader; see the GGUF item under Smaller builds. Take a file that declares its architecture, or leejet's fork, or wait for city96 PR #483.

See also: the 2025 20B predecessor has its own page for this card, on a GGUF Q3 path that the much smaller 2.1 no longer needs: Qwen-Image on RTX 3080 Ti. Those are the reports found for this model on 2026-09-23; the tracker moves by the hour in launch week. Report problems, or better a timed run on this card with its log, via the submission form.