Qwen-Image-2.1 on RTX 3090: int8 ComfyUI setup, 24 GB fit per OS, third-party 3090 timings

What You'll Build

A local Qwen-Image-2.1 setup on a 24 GB RTX 3090 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 a 24 GB card the question is not whether it fits. The template's three files are 16.096 GiB, so at 1024² the transformer, the text encoder and the VAE all stay on the card, and a new prompt only re-runs the encoder, which a 12 GB card cannot do. What this page adds for the RTX 3090 is where its numbers come from: the capacity the card reports to ComfyUI on Windows and on Linux, read from RTX 3090 owners' own startup logs, which decides how native 2K goes; and the one set of timed runs of this model on an RTX 3090 that turned up, from a third party's validation record.

⚠️ 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 3090 (24 GB VRAM, GA102, compute capability 8.6) · not measured on this card by this site · the three template files are 16.096 GiB and stay resident at 1024²; 7.179 GiB of the 23.525 GiB a Linux 3090 reports is left after comfy-aimdo's headroom (derived) · timings from one third-party RTX 3090 in Results · See benchmark data

ℹ️ Nothing on this page was measured on an RTX 3090 by this site. The VRAM figures are arithmetic from byte counts, from ComfyUI's source at tag v0.37.0 and from RTX 3090 owners' public startup logs, added up unrounded and rounded once. The timings in Results are a third party's: the validation record of alesha-pro's install package for this model, run on one RTX 3090 with this page's three files. No other timed run of Qwen-Image-2.1 on an RTX 3090 or RTX 3090 Ti turned up on 2026-09-23 in these places: all 85 threads opened on the ComfyUI tracker since 2026-09-19, bodies and every comment; the 62 discussions on Qwen/Qwen-Image-2.1, Comfy-Org/Qwen-Image-2.1 and Comfy-Org/Qwen3-VL; the 56 discussions on the other 150 repositories a Hugging Face search for the model name returns (one has discussions switched off); the 196 comments of the Hacker News launch thread; the vendor's 13 GitHub issues and pull requests; SGLang's Qwen-Image-2.1 cookbook; 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 each use: (1) the template image took 21.4 s cold on a cu130 build against 69.4 s on a cu128 build (Troubleshooting, the entry on the cu130 WARNING); (2) on that card int8 was faster than bf16 on cu130 and slower on cu128 (Running, Optional: the bf16 transformer), cited as a Blackwell result that cannot be assumed to transfer to this card. One rig, one operator, unreplicated, and neither is an estimate for this card.

Requirements

min_vram_gb is 12, the floor this exact install gets 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. It is not this card's number and not a peak. The derivation for 24 GB is below.

The card, from primary sources

• Ampere, compute capability 8.6, 24 GB GDDR6X on a 384-bit bus, 10,496 CUDA cores, 350 W graphics card power for NVIDIA's Founders Edition. Those are the values on NVIDIA's spec page for the RTX 3090 family, 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. The power figure matters once, when you read the one set of timings (Results).

• GA102. The PCI ID registry lists device 10de:2204 as GA102 [GeForce RTX 3090] and 10de:2203 as GA102 [GeForce RTX 3090 Ti] (pci.ids). The RTX 3090 Ti is the one other consumer card with this die and 24 GB; it has its own page in this series.

• What ComfyUI sees on this card. Searches of the ComfyUI tracker for "Total VRAM" "3090" and "VRAM Total" "3090" return 156 threads. 99 of them carry a startup reading from a desktop RTX 3090: 106 posts from 87 accounts, 97 with a Total VRAM log line and 27 with a system-information block (some carry both), counting each post once and leaving out block-quoted copies of someone else's log. Classified from each log's own evidence (Windows paths, an MSC-built Python, the portable's python_embeded or OS: nt, against a GCC-built Python, Linux paths or OS: posix):

  • Windows, 64 users: every line reads 24,575 or 24,576 MB, and the system-information blocks read 25,769,279,488 B or 25,769,148,416 B, just under 24 GiB.
  • Linux, 19 users: 24,090 to 24,268 MB, and 25,296,044,032 B to 25,438,126,080 B in the system-information blocks.
  • The other 7 posts, from six accounts, give no OS evidence, mix both, or come from a Linux Python yet report the Windows figure; they are left out.

  This page budgets on the lower Windows byte figure, 25,769,148,416 B = 23.999 GiB (#5239, #7864), and on the lowest Linux reading, 24,090 MB = 23.525 GiB (#14717; the log rounds to the MiB).

• What is left for ComfyUI on real machines. Ten Windows users' system-information blocks were taken with ComfyUI running and PyTorch holding nothing (Torch VRAM Total: 0). Nine show 22.747 to 22.789 GiB free, so the desktop, the CUDA context and whatever else was running took 1.210 to 1.252 GiB; one shows 22.189 GiB free, 1.810 GiB taken. The Windows columns below use the typical figure, 24,438,112,256 B = 22.760 GiB free (#5239, #7864). Three Linux users' blocks show 23.177 to 23.301 GiB free, 0.258 to 0.514 GiB taken (#10906, #11109, PR #8669). So Linux reports 0.3 to 0.5 GiB less, and on these machines left more of it free than a Windows desktop did. These are other owners' machines, not a promise about yours.

The three files

Byte-exact from the Comfy-Org repack's tree API at revision ace0edeb. The repo's head is now 9a44dbdb (2026-09-23, README changes 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), a bf16 encoder (17,534,334,616 B = 16.330 GiB), a w4a8 encoder (6,312,105,364 B = 5.879 GiB) 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 agrees with the templates since a docs commit on 2026-09-22 (source): "All of them use the int8 versions of the diffusion model and the text encoder by default."

What 24 GB holds, per loader

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/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. ModelPatcherDynamic.partially_load() accepts the reserve load_models_gpu() computes 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; the table says whether everything can stay resident at once.

Every "left" figure must also hold the sampling activations, the encoder's working memory, the decode's working memory and, in the Linux columns, the CUDA context (0.258 to 0.514 GiB on the three idle Linux machines above). Nothing sizes those in advance on this loader. For scale, ComfyUI's legacy planning figures are 0.960 GiB of sampling activations at 1024² and 3.840 GiB at 2048², and 1.758 GiB and 7.031 GiB for the VAE decode.

Legacy loader (only if you are on it). Here the reserve is real: minimum_inference_memory() is 0.8 GiB plus EXTRA_RESERVED_VRAM (comfy/model_management.py L877-L891). That reserve is 400 MiB on Linux; on Windows it is 600 MiB, plus 100 MiB when total VRAM exceeds 15×1024 MiB, which this card does, so 700 MiB. The floor is therefore 1.191 GiB on Linux and 1.484 GiB on Windows. Two figures come out of it for every model the loader loads, and they do different jobs:

• The request. Before loading, load_models_gpu() asks free_memory() for 1.1 × the model's weights plus the larger of the floor and "estimate + EXTRA_RESERVED_VRAM". For the sampler that estimate is at double batch, even at cfg 1 (comfy/sampler_helpers.py L177): 0.960 GiB at 1024², 3.840 GiB at 2048², from memory_usage_factor = 6.0 and 64×64 or 128×128 latent tokens. For the VAE it is the decode estimate, 900 × h × w × 256 × dtype_size over the latent grid in comfy/sd.py with the VAE in bf16 on this card: 1.758 GiB at 1024², 7.031 GiB at 2048². The text encoder has no estimate, so its request uses the floor. If less than the request is free, free_memory() partially unloads resident models by the difference, copying those weights back to system RAM (legacy partially_unload moves modules with .to()), and they are loaded again when next needed.
• The threshold. Whether the model then loads whole is decided by its weights plus the larger of the floor and the batch-1 estimate + EXTRA_RESERVED_VRAM (0.480 GiB and 1.920 GiB for the sampler, L178); for the VAE, its decode estimate + EXTRA_RESERVED_VRAM.

For the template's first image, in the order ComfyUI runs it, with "free" meaning the card's reported capacity minus the weights already resident, before the CUDA context and any desktop:

At 1024² all three stay resident under either loader. Every legacy request is met with more than 4 GiB to spare, and under DynamicVRAM 7.179 GiB is left on Linux (6.164 GiB on the typical Windows machine). A prompt change re-runs the encoder on weights already on the card; a seed-only change reuses the cached conditioning and skips it. That is the practical difference from a 12 GB card, where the encoder and the DiT take turns.

At 2048² the decode is the tight step, and the OS decides by how much. On the legacy loader the decode asks for 8.114 GiB on Linux, while a Linux 3090 has at most 8.058 GiB free with the encoder and DiT resident before its CUDA context: part of one resident model's weights leave the card, at least 0.056 GiB plus whatever the CUDA context holds. On Windows the request is 8.407 GiB against 8.532 GiB before the desktop, but on the typical Windows machine above only 7.293 GiB is free, so 1.114 GiB of weights leave on that machine's figures. Which model gives them up follows ComfyUI's unload order (lower reference count first, then the smaller model); they are copied to system RAM and loaded back for the next image's sampling. The VAE then loads whole, because 8.114 − 7.422 leaves 0.692 GiB for its 0.629 GiB. On the default loader the VAE is itself a dynamic model: free_memory(for_dynamic=True) does not unload the DiT for it, and the decode estimate only sizes the decode batch (comfy/sd.py L1260-L1265). Whether any weights leave the card there depends on the decode's real working memory, which no report listed at the top measures on this card; if they do, comfy-aimdo frees those pages without copying them anywhere. Either way ComfyUI keeps a fallback for a decode that still runs out: it logs "Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding." and tiles it.

The alternative sets in the DynamicVRAM table: the bf16 DiT with the int8 encoder is the only one that comes near co-residence, and it is covered under Running. Anything with the bf16 encoder cannot keep all its weights on this card under either loader.

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, 12:57Z). 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), 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, comfyanonymous, put the same policy plainly on 2026-09-21 in #16449, a thread from a user whose NAS driver stops at CUDA 12.9: "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

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: 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. At v0.37.0 comfy/quant_ops.py defines seven formats with the pinned comfy-kitchen (six unconditionally, and mxfp8 when comfy-kitchen provides its layout, which 0.2.35 does), and ComfyUI prints how they split when it loads the model. Expect this line, which the reporter of #16175 posted; they give their setup as an RTX 3090 Ti on Windows 11 with ComfyUI 0.34, the same die and compute capability as this card:

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

The order varies, because the line prints a set. From an RTX 3090 itself, the log in #14717 (ComfyUI 0.27.0, torch 2.12.1+cu132, Linux) shows int8_tensorwise on the native side and the four float formats emulated; 0.27.0 predates the two 4-bit formats. 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. #14717's log shows the result on an RTX 3090: Found comfy_kitchen backend cuda: {'available': True, 'disabled': False, ...}.

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. One 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 a memory choice, and on 24 GB the int8 encoder is already resident beside everything else. Comfy-Org's encoder repo Comfy-Org/Qwen3-VL also holds qwen3vl_8b_fp8_scaled.safetensors (10,588,637,512 B = 9.861 GiB, larger than the int8 file) and qwen3vl_8b_nvfp4.safetensors (6,305,221,764 B = 5.872 GiB); on this card neither buys speed, and the bf16 encoder breaks co-residence (table above).

Why the int8 DiT, and what is not known about its speed here. The reason this page can give is memory: with the bf16 DiT instead, the three files leave 0.685 GiB of a Linux 3090 under DynamicVRAM before the CUDA context and any activations (table above), so the int8 file is what keeps all three resident. With a cu130 build its matmuls run as INT8 GEMMs on this card's INT8 tensor cores (above). How that compares with bf16 on compute capability 8.6 has open questions, and the numbers that exist are not for this model:

• comfy-kitchen issue #98 (open) timed MiniMax H3 projections on an RTX A6000, a workstation GA102 card, with comfy-kitchen 0.2.26: at 80,661 tokens the QKV projection took 144.3 ms for int8 ConvRot under the automatic CUTLASS configuration, against 148.8 ms in bf16, and roughly 90 ms with configuration 0 forced.
• comfy-kitchen PR #142 (open, unmerged, not in the pinned 0.2.35) adds a tile heuristic for compute capability 8.6. Its A6000 sweep over 21 shapes from LTX 2.5 and MiniMax H3 found the current heuristic, fitted on Ada and Blackwell, losing 44–50% to configuration 0 on the worst shapes.

Both are kernel measurements for other models' shapes, not Qwen-Image-2.1 timings. One dissent about this model 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, and points to two reports (a Turing card on discussion #8, and #16470, an RTX 5060 Ti on a cu128 build) in which the replies pointed to the cu130 requirement. The one same-card pair of runs that turned up points the other way, with caveats: in alesha-pro's two validation records on the same RTX 3090 (Results), both run on Linux on the legacy loader with a 1 GiB reserve (the package's launcher passes --disable-dynamic-vram --reserve-vram 1, install/setup.py L128), the int8 files took 21.823 s for a 1024², 40-step RGBA job and 84.295 s for 2048×1152 at 50 steps, and a Q4_K_M GGUF DiT in leejet's loader took 54.75 s and 153.31 s at the same sizes, steps, sampler and launcher, in a separate session with different seeds and job order. That is int8 against a GGUF, not against bf16. No whole-pipeline int8-against-bf16 comparison of this model on an Ampere card turned up in the places listed at the top or in comfy-kitchen's own tracker (all 191 issues and pull requests, read 2026-09-23).

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 or for images that come out as noise (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

Do not load either qwen3.5_9b_qwen_image_2.1_pe_*.int8_convrot.safetensors file as the text encoder: 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 got garbled images; as another reader put it there, "The PE models only for PE." (Landsharkbaby, community). This page does not install them; if you add that stage, #16449 above is the cu130 caveat that applies to it.

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 3090 : cudaMallocAsync.
• Total VRAM 24576 MB (or 24575) on Windows, or a figure between 24090 and 24268 on Linux, as in the owners' 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.", and on 24 GB there is no reason for it anyway. If you want more kept free for other software, 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 (Xenodermus, 2026-09-22 16:00Z) 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, and wrote that the "Artifact disappeared completely at 40" steps. A second user posted their own workflow at 18:01Z. At 22:11Z the first user wrote that with that workflow, and a prompt they had toned down, they "see no streaks". A third user wrote on 2026-09-23 at 01:15Z: "Use 40 steps and choose 2k quality." So two remedies are reported, by 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. Third-party ComfyUI conversions of it have appeared since (read 2026-09-23): t8star/Qwen-Image-2.1-viggle-turbo-4step-r64-comfy, a ComfyUI-format conversion of the LoRA, and GGUF conversions of the full transformer in Abiray/Qwen-Image-2.1-viggle-4-steps-turbo-GGUF and realrebelai/Viggle_Qwen-Image-2.1-Turbo_GGUFs; nothing on this page was run with any of them. Two reports about Qwen-Image-2.1 with a LoRA turned up in the 85 ComfyUI tracker threads listed at the top, both closed on 2026-09-23: PR #16493, an error on adding or removing a LoRA on a quantized model, reported on master and closed unmerged by its author (Troubleshooting), and issue #16496, in which one user's edits came out shifted to the left, which that user attributed at 13:16Z to Viggle's 4-step LoRA, naming no GPU or build, before closing it.

For native 2K the template note says "For native 2K, set 1:1 and 4 megapixels"; the budget for it is in Requirements. 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 comfyanonymous 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: "auto uses spare VRAM, then RAM. cpu (RAM) is prefetched behind compute and costs little speed."

On 24 GB the cache can stay on the card, but not with the defaults. 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. With all three files resident, at most 7.429 GiB is free on a Linux 3090 before the CUDA context and activations, and 6.664 GiB on the typical Windows machine above. The template's two reference images are 896×1152 each:

So auto does not choose the GPU for the template edit at resolution 0 or 1056 even with dtype int8, and with the default bf16 cache it needs 15.750 GiB of free system RAM at resolution 0 before it chooses RAM, or it recomputes. Set device gpu and dtype int8: the cache then fits beside all three files at resolution 0 and 1056 on both OSes on paper. The tooltip for dtype says int8 halves the cache at about bf16 accuracy. No run of these settings on this card turned up in the places listed at the top, and 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, an edit with two references went from the full-recompute fallback at 4.01 s/it to 1.02 it/s.

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 neither comes from an Ampere card. A proposed fix, PR #16444, was closed without merging on 2026-09-22 by kijai; no fix is linked to #16435 now.

Optional: the bf16 transformer

Swapping UNETLoader to qwen_image_2.1_bf16.safetensors adds 6.495 GiB and costs the co-residence. Under DynamicVRAM the bf16 DiT, the int8 encoder and the VAE come to 22.841 GiB with headroom on Linux, 0.685 GiB under the card before the CUDA context and any activations, and 23.091 GiB on Windows, 0.331 GiB more than the typical Windows machine has free; either way weights get paged while the stages alternate. On the legacy loader, loading the bf16 DiT with the encoder resident asks for 15.929 GiB on Linux against 14.817 GiB free, so at least 1.112 GiB of the encoder leaves the card first, and it comes back on the next prompt. What the swap would buy is reference precision, and its speed on this card is unknown (Installation, step 2). The whole-pipeline comparisons of the two files that turned up, in the places listed at the top, comfy-kitchen's tracker and the Hugging Face cards of the repositories this page cites, are both on Blackwell cards. On the site operator's RTX 5060 Ti 16GB, int8 was faster than bf16 on a cu130 build and slower on a cu128 build (cu130 session, cu128 session; one rig, one operator, unreplicated). On an RTX 5090, BennyDaBall's validation record timed the official BF16 file at 15.629 s and the INT8 ConvRot file at 7.553 s (warm medians, 1024×1024, 40 steps, Windows, torch 2.14.0+cu130, a patched ComfyUI 0.36.0 base). comfy-kitchen's fused INT8 path is built for compute capability 8.0 and up and runs on this card too, but neither comparison was measured on Ampere, so neither says how the two files compare here. Pairing the bf16 DiT with the bf16 encoder needs 30.212 GiB of weights and cannot co-reside on any 24 GB card.

Smaller and other builds: what they change on 24 GB

Very little. Everything already fits at 1024², so a smaller DiT file buys a smaller reload when weights do move (2K, a model switch) and nothing else that is known; on this card the one measured pair above had the Q4_K_M GGUF slower than the int8 file, not faster.

• GGUF, and which loader reads it. Abiray/Qwen-Image-2.1-GGUF (Q8_0 7,591,579,808 B) declares general.architecture = qwen_image in its header, which city96's loader.py accepts. leejet/Qwen-Image-2.1-GGUF (Q8_0 7,687,155,744 B) and unsloth/Qwen-Image-2.1-GGUF (Q8_0 7,640,860,384 B) 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 a GGUF DiT gives up the INT8 GEMM this card has.
• INT4 ConvRot and the mixed w4a8 build (toxicdog/Qwen-Image-2.1-INT4ConvRot-ComfyUI, 3,666,512,184 B, convrot_w4a4; NidAll/Qwen-Image-2.1-Mixed-Balanced, asym_w4a8_int8) are native on this card by the table in step 2 and keep a native matmul; quality at 4 bits is the open question, and on 24 GB there is no memory reason to take it.
• FP8 and NVFP4 builds are emulated here. Third-party FP8 and (NV)FP4 DiT builds of 2.1 exist, among them unsloth/Qwen-Image-2.1-FP8 and BennyDaBall/Qwen-Image-2.1-NVFP4 in the 152 repositories a Hugging Face search for the model name returned on 2026-09-23. On compute capability 8.6 ComfyUI marks both float8 formats and nvfp4 emulated, so their weights are dequantised for every matmul: the memory saving survives and the kernel does not, and at this capacity the memory saving is not needed.

Results

• Speed: our catalogue has no benchmark rows for this pair; /check/qwen-image-2-1/rtx-3090 returns verdict: unknown. The only timed runs of this model on an RTX 3090 found are a third party's: the validation record of alesha-pro's one-GPU install package, dated 2026-09-21. One RTX 3090 on Linux with 128 GB of RAM, driver 610.43.02 and an observed GPU power limit of 290 W, below the 350 W NVIDIA lists for its Founders Edition; ComfyUI at commit 0f74f7fb, which is v0.37.0 plus one commit that only moves the frontend pin; comfy-kitchen 0.2.35 and comfy-aimdo 0.5.5, the versions this page installs, with Torch 2.11.0+cu130 (this page pins no torch build); and this page's three files, SHA-256 checked. The times are ComfyUI's own execution start to success, so they include encoding, sampling, decoding and saving; the record says the jobs ran one after another in this order and that model and cache warmth differ between them:

  Job (euler / simple, cfg 1, batch 1)	Size	Steps	Seconds
  Text-to-image, first job	1024×1024	40	37.581
  Text-to-image	2048×1152	50	84.295
  Edit, one reference	1024×1024	40	37.106
  RGBA text-to-image	1024×1024	40	21.823
  Edit, two references	1024×1024	40	44.554

  What separates them from this page's install: the author's own flat workflows at 40 and 50 steps rather than the template's 25; the package's launcher, whose launch command starts ComfyUI with --disable-dynamic-vram --reserve-vram 1 (install/setup.py), i.e. the legacy loader with a 1 GiB reserve rather than DynamicVRAM (the record itself does not print its launch line); the 290 W limit; and Linux. The author calls the table an acceptance record rather than a controlled comparison. The package's README adds that earlier runs on the author's existing install took 82–96 s at 2048×1152 and 50 steps, some while other GPUs in the same host ran independent jobs. Do not scale these to 25 steps; if you time the template on an RTX 3090, /contribute is where that number belongs.

• VRAM usage: derived, not measured by this site. At 1024² the three template files, 16.096 GiB, stay resident under either loader: under DynamicVRAM 16.346 GiB with comfy-aimdo's headroom against the 23.525 GiB a Linux 3090 reports, and 16.596 GiB on Windows, which leaves 6.164 GiB of the typical Windows machine's 22.760 GiB free. At 2048² the legacy decode request (8.114 GiB on Linux, 8.407 GiB on Windows) exceeds what is free with the encoder and DiT resident, so part of one model's weights leave the card for the decode; under DynamicVRAM that depends on the decode's real working memory. The nearest measured VRAM on an RTX 3090 is in the same author's GGUF validation record: with a Q4_K_M DiT from abenzerps (4,604,557,984 B at the revision that test pinned, 2.470 GiB smaller than this page's int8 file) beside this page's encoder and VAE, on the same launcher, the peak process VRAM that nvidia-smi reported, sampled every 0.5–0.7 s, was 15.39 GiB at 1024² (40 steps), 16.83 GiB at 2048×1152 and 17.15 GiB for a one-reference edit, CUDA context and allocator cache included. That is a different DiT file, so it is not this page's peak. Live data, when it exists, will be at /check/qwen-image-2-1/rtx-3090.

• 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; 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). On the vendor's own tracker, issue #5 (open) comes from an RTX 3090 Ti owner, same die as this card, on Windows with WSL Ubuntu: faint purple vertical streaks on 2048×2048 outputs, stronger on some images than others, unchanged by every decode-side setting they tried; the runtime is not stated, and a second user reports the same on an NVIDIA L4, a different architecture. Inspect native-2K portraits at 100%. The banding at 25 steps under Text-to-image is a separate report.

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

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 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). kijai, a ComfyUI collaborator and the author of the core support, has answered the same symptom twice: on issue #16470, an RTX 5060 Ti whose int8 file ran slower than a Q8_0 GGUF on a cu128 build, "You need pytorch with cu130 for int8 models to work properly."; and on an RTX 3090, below.

Images come out as noise or texture

Check the build and then the files. On issue #15419 (open), a different model, MiniMax H3, produced only noise on an RTX 3090 running a cu128 build, where the int8 layers take the eager path. kijai replied: "Update to cu130 minimum to use the int8 models." A second RTX 3090 owner in the same thread, on cu130, traced their identical noise to corrupt downloads, fixed it by downloading again and verifying the hashes, and wrote: "checksum your checkpoints before anything else." Neither report is about Qwen-Image-2.1; both steps cost a minute here. Compare the three hashes from step 3.

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 downloaded the file again, it loaded, and kijai closed the issue as completed that evening. Check the file's sha256 against step 3 and download it again 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. On this card set QwenImage21Cache to device gpu and dtype int8; with more or larger references than the template's, device cpu avoids the recompute 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; both said the crash is intermittent and seems tied to larger input images. The reporter also started ComfyUI with --cuda-device 0 "to force a single GPU, but the same crash still occurs". 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 in the 85 tracker threads listed at the top. 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 (update.py with --stable), 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.

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

PR #16493, opened and closed unmerged by its author within three minutes on 2026-09-23, reports that adding or removing a LoRA on an already-resident quantized model raises this error on master, with a Qwen-Image-2.1 int8 checkpoint, and that every later generation fails the same way until the server restarts. The same error class is open for MiniMax H3 as #15733, with a fix proposed in PR #15734, open. At v0.37.0 the legacy patcher's unpatch_model restores backed-up weights through comfy.utils.set_attr_param, and that function has the same code as the PR's "before" (comfy/utils.py), so the path the PR reports exists at the tag, on the legacy loader. The default DynamicVRAM loader restores backed-up weights through the same function: ModelPatcherDynamic.load() calls restore_loaded_backups(), which passes every backed-up weight to comfy.utils.set_attr_param (comfy/model_patcher.py). Whether those backups hold quantized weights when a LoRA changes has not been shown either way, so whether the default loader can hit the error is not established. That is a reading of the code, not a report, and no report of the error at the tag turned up in the 85 tracker threads listed at the top. If you hit it after adding or removing a LoRA, such as the turbo conversion above, restart ComfyUI.

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, 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. At 2048² the decode is the one stage that does not fit beside the other two files with room to spare (Requirements), so close what else is using the card (a browser with hardware acceleration counts) before blaming anything else.

Every generation reloads models

At 1024² it should not: all three files stay resident, a prompt change re-runs the encoder in place and a seed-only change skips it. If models reload anyway, something else is taking VRAM, or you are at 2K on the legacy loader, where the decode moves weights.

Reloads are the trigger of one 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 every image after the first reload 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 85 tracker threads listed at the top. If your images turn green or wrong-coloured after a reload, 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 and other 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 path with no FP8: Qwen-Image on RTX 3090. 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 of the template on this card with its log, via the submission form.