Qwen-Image-2.1 on RTX 3060 Ti 8 GB: what streams per OS, and 4-bit DiTs Ampere runs natively

What You'll Build

A ComfyUI graph on one RTX 3060 Ti 8GB that turns a prompt into a 1024×1024 image, with a real alpha channel if you ask for one, and edits images from references, using Qwen-Image-2.1: a 7B single-stream diffusion transformer (DiT) behind a Qwen3-VL-8B text encoder and a 64-channel RGBA VAE, released 2026-09-20 with support in ComfyUI core.

On 8 GB the question is not whether it runs. ComfyUI's default loader keeps whatever does not fit in system RAM or on disk and pages it in as it is needed, so a tight stage costs time, not the image. The question is which files keep each stage on the card, and on this card the answer depends on the operating system, which is where this page starts: RTX 3060 Ti owners' own ComfyUI startup logs say how much of the card is left once Windows or Linux has taken its share.

The short version of the arithmetic below. Take the smallest text encoder in Comfy-Org's repack instead of the template's, and the encode stage fits on both systems. The official int8 diffusion model is then borderline on Linux, 0.648 GiB under the card's reported capacity once ComfyUI's default loader keeps its own headroom, before the CUDA context, any desktop and sampling's working memory; on the Windows machines whose logs were read it does not fit, and at least 0.299 GiB of it streams on every step. The RTX 5060 page in this series swaps in an NVFP4 build, which this card has no hardware for; what Ampere has instead is integer tensor cores. Two community 4-bit builds of the diffusion model run natively here: one (INT4 W4A4) on INT4 tensor cores, which comfy-kitchen uses on Turing RTX 20, Ampere and Ada cards but not on Blackwell, and the other, a W4A8 file, offered below as the swap that stays on the card with room.

⚠️ Read the licence before you download 14 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). Section 4.b reaches outputs in one case: if you train or fine-tune a model you distribute on this model's outputs, "you shall prominently display “Built with Qwen” or “Improved using Qwen” in the related product documentation". Comfy-Org's repack and every community quantisation on this page are derivatives and carry the same terms. This is a reader's summary of the text, not legal advice.

Hardware data: RTX 3060 Ti (8GB VRAM, GA104, compute capability 8.6, PCIe 4.0 x16) · not measured on this card by this site · the int8 DiT with comfy-aimdo's headroom is 7.008 GiB on Linux, 0.648 GiB under the lowest capacity a Linux 3060 Ti reports, and on the logged Windows machines it streams; the W4A8 DiT swap is 3.915 GiB (derived) · See benchmark data

ℹ️ Nothing on this page was measured on an RTX 3060 Ti by this site, and no measurement of Qwen-Image-2.1 on an RTX 3060 Ti, RTX 3070 or RTX 3070 Ti (8 GB cards on the same die) turned up on 2026-09-23 in these places: all 90 threads opened on the ComfyUI tracker since 2026-09-19, every body and comment; all 134 discussions on the 176 Hugging Face repositories returned by name searches for the model, its other spellings and INT4ConvRot, plus Comfy-Org/Qwen3-VL (one has discussions switched off), and those repositories' cards; the READMEs of the 154 GitHub repositories a search for the model returns; the 196 comments of the Hacker News launch thread; the vendor's 13 GitHub issues and pull requests; and one web search. Reddit refused this session, including a control request to a subreddit's front page. Every VRAM figure below is arithmetic from byte counts, from ComfyUI's source at tag v0.37.0 and from RTX 3060 Ti owners' public startup logs, added up unrounded and rounded once. If you run it, post your numbers.

ℹ️ The one place this page uses a measurement from this site, 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 one fact from them, in Troubleshooting under the cu130 WARNING: the template image took 21.4 s cold on a cu130 build against 69.4 s on a cu128 build (cu130 session, cu128 session). One rig, one operator, unreplicated, and not an estimate for this card.

Requirements

min_vram_gb is 8: the install on this page runs on an 8 GB card, with the stage-by-stage caveats below. It is not a peak.

The card, from primary sources

• Ampere, compute capability 8.6, 8 GB, "PCI Express Gen 4". Those are the values on NVIDIA's spec page for the RTX 3060 family, which prints CUDA Capability 8.6 for this card. The number that matters is 8.6: Ampere's tensor cores take INT8 and INT4 inputs (step 2) and have no FP8 or FP4 path, and ComfyUI decides per device which weight formats run natively from exactly that.
• GA104, and on some boards GA103. The PCI ID registry (pci.ids) lists 10de:2486 and 10de:248e as GA104 [GeForce RTX 3060 Ti], 10de:2489 as its Lite Hash Rate version, 10de:24c9 as GA104 [GeForce RTX 3060 Ti GDDR6X] and 10de:2414 as GA103 [GeForce RTX 3060 Ti]. All of them are compute capability 8.6, so nothing on this page changes between them. The same file lists the RTX 3070 and RTX 3070 Ti on GA104 (it also lists a GA102 RTX 3070 Ti, 10de:2207, and an "RTX 3070 16GB" board); NVIDIA's spec page for that family gives both 8 GB. No Qwen-Image-2.1 report from either turned up either.
• Sixteen lanes, PCIe 4.0. In the 15 lspci -vv dumps uploaded to the Linux Hardware Project that were read for this page (found by searching its dumps for the card's name, and for the name beside 16GT/s) and print the card's link capability, every one gives its width as x16; 14 read Speed 16GT/s, Width x16, among them a GA103 board, a Lite Hash Rate board and a GDDR6X board, and one, on an older MSI board, reads Speed 8GT/s. What the link actually runs at is the slower of the card and the slot: one of those dumps shows the card linked at Width x8 (downgraded). On 8 GB the link matters, because stages take turns and weights cross it (see What crosses the link).
• What ComfyUI sees on Windows. Searches of the ComfyUI tracker for "Total VRAM" "3060 Ti" and its variants return 29 threads. 22 posts from 21 accounts carry a startup reading from an RTX 3060 Ti with Windows evidence (Windows paths, an MSC-built Python, the portable's python_embeded); one more gives no OS and is left out. Every Total VRAM line reads 8,191 or 8,192 MB, and the system-information blocks read 8,589,279,232 B or 8,589,410,304 B. This page budgets on the lower one, 8,589,279,232 B = 7.999 GiB (#10367). Seven of those blocks were taken with ComfyUI running and PyTorch holding nothing (Torch VRAM Total: 0), and they show 6.959 to 6.973 GiB free: the desktop, the CUDA context and whatever else was running took 1.027 to 1.041 GiB. The Windows columns below use the lowest, 7,472,152,576 B = 6.959 GiB (#11044, #11445). Those are other owners' machines, not a promise about yours.
• What ComfyUI sees on Linux. No Linux reading of this card turned up in the ComfyUI tracker, so the search was widened to the 161 GitHub issues, in any repository, that a search for "3060 Ti" beside "Total VRAM" in their text returns. Four accounts posted a Linux reading (a GCC-built Python or Linux paths): Total VRAM 7840 MB from ComfyUI 0.33.0 on torch 2.13.0+cu130 (ComfyUI-Easy-Install #291), 7,841 MB (aiohttp #11113), 7,842 MB from Forge on NixOS (stable-diffusion-webui-nix #7) and 7,960 MB, whose system-information block gives 8,346,271,744 B = 7.773 GiB (ComfyUI-Riffusion #5). This page budgets on the lowest, 7,840 MiB = 7.656 GiB (the log rounds to the MiB): 0.343 GiB less than Windows reports. No idle Linux free-memory reading of this card turned up, so the Linux columns subtract nothing for the CUDA context or a desktop, and read as upper bounds.

The 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 community files are read from each repository's tree API at the revision given.

The repack's two DiT builds are bf16 and int8; there is no fp8, nvfp4 or int4 DiT in it. The ComfyUI docs page 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." It lists the int8 and bf16 encoders, not the w4a8 one this page uses.

The arithmetic, stage by stage, per loader and per OS

A single image is three stages, encode, sample and decode, that take turns on the card rather than sharing it. How much room each needs depends on which of ComfyUI's two loaders manages it. 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 v0.37.0 pins) and from the byte counts above.

DynamicVRAM, the default on this card. At v0.37.0, main.py turns it on whenever the device is NVIDIA, PyTorch is 2.8 or newer and comfy-aimdo initialises; the log then prints DynamicVRAM support detected and enabled. ComfyUI's own reserve and estimates do not decide residency here: ModelPatcherDynamic.partially_load() never uses the budget it is handed, and the comment on its estimate says that when every model is dynamic "this is ignored and its all done dynamically." (comfy/model_patcher.py#L1840-L1843). The floor is comfy-aimdo's, and it differs by OS. On Linux it keeps VRAM_HEADROOM, 256 MiB = 0.250 GiB, free against the card's live free VRAM (src/plat.h#L145-L146); on Windows it keeps 512 MiB below the budget WDDM grants the process and, with NVML pressure on (the default), 512 MiB of free VRAM by NVML (src-win/shmem-detect.c#L105-L107). Weights that do not fit are evicted and paged back as they are used; the comfy-aimdo README describes "on-demand offloading of model weights when the primary pytorch VRAM allocator comes under pressure". The table says whether a stage's weights can stay whole:

All figures in GiB. Every "left" figure must also hold that stage's working memory, and on Linux the CUDA context and any desktop; nothing sizes those in advance on this loader.

Why the int8 DiT is borderline on Linux and streams on Windows. On Linux, 6.758 GiB of weights plus 0.250 GiB of headroom leave 0.648 GiB of the reported capacity for the CUDA context, the display and sampling's activations. The largest single intermediate in a block is the fused MLP's gate_up output, 24,576 features wide (read from the GGUF header's tensor shapes): 4,096 image tokens × 24,576 × 2 bytes = 0.1875 GiB at 1024², 0.75 GiB at 2048². Whether the rest fits is not established either way. On the seven logged Windows machines the arithmetic settles it: 6.959 GiB free less aimdo's 0.500 GiB leaves 6.459 GiB, 0.299 GiB less than the DiT's 6.758 GiB before any activation, so at least that much is paged in from outside the card on every step. On paper both 4-bit DiTs, and the w4a8 encoder, stay whole on both systems; the template's int8 encoder cannot stay on the card at all.

Legacy estimate-based loading is what you get with --disable-dynamic-vram (or --highvram, --gpu-only, --novram, --cpu), and it always governs a GGUF DiT, because city96's GGUFModelPatcher subclasses ComfyUI's plain ModelPatcher (nodes.py#L35). Here the reserve is real: minimum_inference_memory() in comfy/model_management.py is 0.8 GiB plus EXTRA_RESERVED_VRAM, which is 400 MiB on Linux and 600 MiB on Windows (the extra 100 MiB in that block applies only above 15×1024 MiB, not to this card): 1.191 GiB on Linux, 1.386 GiB on Windows. A model loads whole only if its weights fit beside the larger of that reserve and its batch-1 estimate plus EXTRA_RESERVED_VRAM. For the sampler that estimate is area × dtype_size × 0.01 × memory_usage_factor MiB with memory_usage_factor = 6.0: 0.480 GiB at 1024² (below the reserve) and 1.920 GiB at 2048². (The separate estimate that sets how much it asks to be freed doubles the batch even at cfg 1, per comfy/sampler_helpers.py; it decides what is unloaded, not what stays whole.) For the VAE it is ComfyUI's decode estimate, 900 × h × w × 256 × dtype_size over the latent grid (comfy/sd.py#L834-L844): 1.758 GiB at 1024², 7.031 GiB at 2048².

All figures in GiB. On the legacy loader the int8 DiT streams part of itself on both systems, and on the logged Windows machines so does the w4a8 encoder. Every 4-bit DiT in the table stays whole at 1024² and at 2048² on paper. The 2048² decode estimate, 7.031 GiB, is more than either system has; if the real decode runs out, comfy/sd.py catches it and logs "Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding."

No DiT co-resides with the encoder. The int8 DiT plus the w4a8 encoder is 13,568,888,428 B = 12.637 GiB; the W4A8 DiT plus the same encoder is 10,515,502,844 B = 9.793 GiB, still over the card. Under DynamicVRAM, free_memory() deliberately does not unload one dynamic model for another; the comment there says "don't actually unload dynamic models for the sake of other dynamic models" (comfy/model_management.py). On a prompt change the encoder's weights are paged in as encoding needs them and the DiT's are evicted as that needs the room, then the reverse. Under the legacy loader the same exchange happens as partial unloads. Re-running with only the seed changed skips it, because the conditioning is cached. That order is an inference from the arithmetic and the code, not a measurement.

What crosses the link, and where it comes back from

An 8 GB card re-reads weights over PCIe as a matter of course, so the link's rate and the source of those reads are part of the budget. Two facts first, then the arithmetic.

• Where evicted weights come back from depends on the disk. At v0.37.0 ComfyUI decides per model file whether its offloaded weights are staged in pinned system RAM or read back from the file itself: comfy/storage.py chooses the file on Linux when every model file sits on an NVMe drive linked at PCIe 3.0 ×4 or better, asks comfy-aimdo on Windows, and logs Model storage policy: fast_disk=… paths=… when a model loads. --disable-fast-disk forces system RAM and --fast-disk forces the file (comfy/cli_args.py). On the RAM side, ComfyUI pins at most 40% of installed RAM on Windows (comfy/model_management.py#L1613-L1621). One user's screenshot on issue #16498 (opened 2026-09-23, no replies when read), from a different, 12 GB card, an RTX 4070 by the panel's label, shows a text encoder of 8.7 GB (by its size, the template's int8 file) with 640 MB on the card and 8.1 GB "unloaded", while the process holds 0 KB of pinned or loaded RAM. No log is posted, so the storage policy it ran under is not shown; the reporter only asks whether that is expected of the fast-disk feature. Which source is faster on a 3060 Ti is not measured.
• The link's rate. The Linux kernel counts a PCIe link as 16000*128/130 Mb/s per lane at 16 GT/s and 8000*128/130 at 8 GT/s (drivers/pci/pci.h, v6.12). Sixteen lanes give 31.508 GB/s per direction on a PCIe 4.0 board and 15.754 GB/s on a PCIe 3.0 board. Those are raw rates; nothing on this page measured what this card achieves, and when the source is a file the disk can be the slower end.

Below, every time is bytes divided by the raw rate: a floor, not a prediction.

Which of the two int8 rows is closer depends on the order in which comfy-aimdo evicts pages while a step runs, which this page did not establish. On the legacy loader every unload is also a copy back to system RAM (partially_unload moves each module with .to()), so a re-read is a round trip and the prompt-change rows double. Edits add a per-step copy of their own; see Editing.

System RAM. The recommended set is 13.266 GiB and the W4A8 set 10.422 GiB, and on this card most of it is off the card at any moment. With 16 GB of RAM installed, those files, the operating system, the browser and ComfyUI itself compete for it; 32 GB is advised on that arithmetic, not on a measured minimum.

Installation

1. ComfyUI v0.37.0 or newer, on a CUDA 13 PyTorch

Qwen-Image-2.1 support is in ComfyUI core: PR #16400 by kijai, merged 2026-09-19, is in tag v0.37.0 (commit 73c9bad4). The v0.37.0 release was published 2026-09-21T07:35Z with Windows portable builds and was still the latest release when this page was written (2026-09-23, 16:10Z). A tag v0.37.1 (commit 3f767e7f67) was cut 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, and none of them changes the model's code or any of the three Qwen-Image-2.1 workflow files. A second tag, v0.37.2 (commit 830232b8), followed on 2026-09-23 at 18:34Z, also with no release object; its six commits add a system_prompt input and a separate thinking output to TextGenerate, partner-API nodes and workflow templates 0.11.69; the one change on this model's path is an optional system_prompt argument to the Qwen3-VL tokenizer, which the 2.1 nodes never pass, and the three 2.1 workflow files are unchanged.

Tag or master? This page installs the tag, and every ComfyUI code reference on it is to the tag. master carries two changes that bear on this card. PR #16430 compiles the transformer blocks, and its author, rattus128, a repository contributor, writes that "Some users in specific conditions (slow PCIe bus, disk offload) will have considerable speedup when offload is the bottleneck.", which is the int8 DiT's situation here; PR #16429 changes where the edit path's K/V cache may live (see Editing). Neither has been timed on an 8 GB card. master also carries the code path of two open hard crashes (Troubleshooting): issue #16443 on image editing, which PR #16450 blames on a wrapper that exists only on master and is reached when the edit cache sits in system RAM, which is where this card puts it; and the one PR #16481 describes on the second generation. Stay on the tag unless you want to test those changes.

The CUDA version is a hard gate in comfy/quant_ops.py: below CUDA 13 it disables comfy-kitchen's CUDA backend and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." The ComfyUI README at the tag states the 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. So install the cu130 stack last, after requirements.txt, so nothing resolves a different wheel over it.

The shell blocks on this page are for Linux (bash or zsh). Windows users should take the portable and follow the separate Windows block after step 4.

export COMFY="$HOME/ComfyUI"    # absolute path; in any new shell, run this line again first
git clone https://github.com/Comfy-Org/ComfyUI.git "$COMFY" && cd "$COMFY" && \
  git checkout v0.37.0 && \
  python3 -m venv .venv && source .venv/bin/activate && \
  pip install -r requirements.txt && \
  pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
    torch torchvision torchaudio && \
  python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.get_device_capability())"

The last line must print a CUDA version starting 13 and (8, 6). If ~/ComfyUI already exists, git clone fails and nothing after it runs: either point COMFY at a new folder, or replace git clone https://github.com/Comfy-Org/ComfyUI.git "$COMFY" && cd "$COMFY" && with cd "$COMFY" && git fetch --tags && and run the rest of the chain unchanged. Every later block starts with cd "${COMFY:?…}" && source .venv/bin/activate && … as one chained command: if COMFY is unset the whole block stops with a message instead of installing into the system Python or downloading to /models.

On Windows, take ComfyUI_windows_portable_nvidia.7z from the release. The README at the tag says "The portable above currently comes with python 3.13 and pytorch cuda 13.0." 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". A ComfyUI maintainer, comfyanonymous, put the same policy plainly in #16449: "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."

2. What Ampere gets from each file

The diffusion model's formats run natively here. ComfyUI decides per device in get_disabled_quant_formats() in comfy/ops.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, which leaves all three integer formats native: int8_tensorwise (the official int8 files), asym_w4a8_int8 (W4A8, the w4a8 encoder and NidAll's DiT) and convrot_w4a4 (INT4 W4A4, toxicdog's DiT). No RTX 3060 Ti log printing the resulting line turned up in the tracker; this is the one the reporter of #16175 posted from an RTX 3090 Ti on Windows 11, the same compute capability:

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. An emulated layer's weight is dequantised to bf16 for the matmul, so FP8 and NVFP4 builds save memory here and nothing else.

With a cu130 PyTorch, comfy-kitchen runs them on its CUDA kernels. At v0.2.35, the version v0.37.0 pins (backends/cuda/__init__.py):

• int8 goes through its CUTLASS INT8 path, which the source enables for compute-capability major 8 and above.
• W4A8 is registered for compute capability 8.0 and up: the 4-bit weights are decoded to int8 in chunks and multiplied on the tuned INT8 GEMM, so the activations stay 8-bit.
• INT4 W4A4 takes the sm80 4-bit MMA path where _cuda_device_supports_native_int4_mma() returns major == 8; the source comment says the kernel emits the m16n8k64 s4 MMA, sm80's integer shape. Compute capability 8.6 is major 8, so this card gets it with 4-bit activations. comfy-kitchen has a separate native INT4 kernel for Turing RTX 20 cards (not GTX 16), used above a small batch of rows; Hopper and Blackwell take the INT8 fallback.

setup.py's default build targets 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 8.6. How the two 4-bit paths compare with int8 for speed on this card is not measured anywhere found.

Without cu130 nothing breaks for the diffusion model; it runs the slow way. comfy-kitchen falls through to its eager backend. For int8 that still runs an integer GEMM through torch._int_mm, per its eager int8_linear. For INT4 W4A4 the eager path unpacks both sides to the compute dtype and runs an ordinary floating-point matmul, so the 4-bit arithmetic is gone. 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 (see Running).

The text encoder is a different case. 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, and the context that switches quantised matmuls back on wraps only text generation, not the conditioning this model uses. The encoder's format is a memory choice, not a speed choice, and on 8 GB memory is the choice that matters: the w4a8 file is the smallest encoder in the repack. No side-by-side comparison of the w4a8 and int8 encoders' output turned up in the places listed at the top.

3. Download the official files, with the smaller encoder

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  pip install -U huggingface_hub && \
  hf download Comfy-Org/Qwen-Image-2.1 \
    vae/qwen_image_2.1_vae_bf16.safetensors \
    text_encoders/qwen3vl_8b_w4a8.safetensors \
    diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
    --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir "$COMFY/models" && \
  sha256sum "$COMFY/models/diffusion_models/qwen_image_2.1_int8_convrot.safetensors" \
    "$COMFY/models/text_encoders/qwen3vl_8b_w4a8.safetensors" \
    "$COMFY/models/vae/qwen_image_2.1_vae_bf16.safetensors"

The repack's folder layout matches ComfyUI's, so the files land in models/diffusion_models/, models/text_encoders/ and models/vae/. The hashes must read cb74113cb03faecd79611b01fd7fd642f0aa60d6f0b95086abee214d75eaa57d, 7754425e55e7bea2bfde4dde59a4cc236cb44e5ee9c215ea66ef8d47012824eb and bb21f7473051e1ac368515dd3f2e15cd44d7a11748ee8823e1ddca3e4876b7c9, the LFS hashes at the pinned revision. The template's own encoder, qwen3vl_8b_int8_convrot, is left out on purpose: at 8.709 GiB it is larger than the card. Do not load either qwen3.5_9b_qwen_image_2.1_pe_*.int8_convrot.safetensors file as the text encoder: those are prompt-rewriting models for an optional LLM stage, and as a reader on the repack's discussion #4 put it, "The PE models only for PE."

4. Optional: a 4-bit diffusion model that stays on the card

The INT4 half of this step does not carry over to Blackwell; the W4A8 build runs natively on any card of compute capability 8.0 or newer. Every build below is a community file a few days old, inherits the research licence, and has not been run on a named NVIDIA card by anyone who published the result in the places listed at the top. Staying on the card is not the same as being faster, and no timing of either 4-bit path against the int8 file, on any card, turned up in those places.

Offered: NidAll's W4A8 build. NidAll/Qwen-Image-2.1-Mixed-Balanced holds one file, 4,203,397,480 B = 3.915 GiB. Read over an HTTP range request, its header's _quantization_metadata gives all 192 quantised layers the format asym_w4a8_int8 with a 16-wide group and ConvRot, and each layer carries the weight_s_rel, weight_s_channel and weight_codebook tensors ComfyUI's loader reads for that format (comfy/ops.py). Those 192 layers are the same set Comfy-Org's own int8 file quantises; the rest, including the modulation projection, stay at source precision. Stock UNETLoader reads this kind of header: load_diffusion_model_state_dict() passes the file's metadata to convert_old_quants(), which turns _quantization_metadata into per-layer markers (comfy/utils.py). That is a reading of the code, not a run. Its per-layer settings (asym_w4a8_int8, group 16, ConvRot 256) are the ones Comfy-Org's own w4a8 encoder carries on its transformer layers (read from that file's comfy_quant entries), and that is the reason this is the build offered: its weights are 4-bit, its activations stay 8-bit, and it keeps the layers the official recipe keeps. On quality there is only the uploader's word, with two example images: "Initial testing shows very strong retention compared with the official INT8 ConvRot model" (README). The same README calls the checkpoint experimental, and the file's own header records its quality validation level as unverified, calibration-free, with quality gates that used weight-only reconstruction error. The card names no GPU, and the repository has no discussions.

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  hf download NidAll/Qwen-Image-2.1-Mixed-Balanced qwen_image_2.1_mixed_balanced.safetensors \
    --revision fa3fb50283df2f9c2854afaa198b5fc09f84835a --local-dir "$COMFY/models/diffusion_models" && \
  sha256sum "$COMFY/models/diffusion_models/qwen_image_2.1_mixed_balanced.safetensors"

The hash must read 1dd28b380224f3b8387fa62c58dbbbf345b43616575ae872cd1ebbe84e44859d.

Native here, not offered: toxicdog's INT4 W4A4 build. toxicdog/Qwen-Image-2.1-INT4ConvRot-ComfyUI holds the smallest DiT of the lot, 3,666,512,184 B = 3.415 GiB, whose header marks 193 layers convrot_w4a4 with a 64-wide quantisation group. It is the one format on this page that comfy-kitchen runs as 4-bit tensor-core arithmetic here and through its INT8 fallback on Blackwell, and on paper it stays whole with the most room. It is not offered, for three reasons that each come from the file or its repository:

• One quality report, and nothing on the other side. The repository's only discussion (#1, 2026-09-20, no reply when read) says "INT4 seems to yield poor output quality.", with no images and no card. No other statement about its output turned up.
• It quantises more than the official recipe. Its 193 layers are Comfy-Org's 192 plus modulation.1, the model-wide modulation projection the official int8 file keeps in bf16 (compared header against header). Its activations are also 4-bit, where W4A8 keeps them at 8.
• It was made for something else. Its README says it was "converted for testing in Radiant Canvas for fast macOS inference" (README), and its header names the Star Ultimate Model Converter, whose INT4 path at its last commit before the upload hands each weight to comfy-kitchen's own TensorCoreConvRotW4A4Layout.quantize(). So the packing should be the one ComfyUI decodes; that is a reading of the converter's code, not a run.

chfm/Qwen-Image-2.1-INT4ConvRot-ComfyUI (created 2026-09-22) is a copy: every file in it has the same LFS hash as toxicdog's. If you try the INT4 file anyway, it goes in models/diffusion_models/ like the W4A8 one, and a comparison against the int8 file at the same seed would be the first published.

The rest of the 4-bit candidates are not a ComfyUI path on this card:

• Nunchaku / SVDQuant builds. ComfyUI v0.37.0 has no SVDQuant format in QUANT_ALGOS (comfy/quant_ops.py), and the ComfyUI-nunchaku node pack's tree holds Qwen-Image files and none for 2.1; its last push was 2026-09-06, before the model's release. ModelsLab/Qwen-Image-2.1-W4A4-int4 (4,655,346,432 B) is packed for a pinned Nunchaku development build and loaded through diffusers with the uploader's own loader; its timing table names an RTX 4090 48GB and an RTX PRO 6000, not an 8 GB card. BlazeMCworld/Qwen-Image-2.1-nunchaku-lite-int4, uploaded on 2026-09-23, needs diffusers installed from source. catplusplus/nunchaku-qwen-image-2.1 ships only NVFP4 (FP4) files, a format this card has no hardware for.
• Rin247/Qwen-Image-2.1-INT4 is a diffusers-layout package whose transformer header carries neither comfy_quant markers nor _quantization_metadata, the two ways ComfyUI v0.37.0 recognises a quantised layer, and its card names no loader.

GGUF (city96's ComfyUI-GGUF). Abiray's files are made for city96's node, which dequantises each weight on the fly, so a GGUF DiT gives up the integer matmul this card has, and it is always on the legacy loader. Read over an HTTP range request, Abiray's header declares general.architecture = qwen_image, which is in city96's IMG_ARCH_LIST. leejet's and unsloth's GGUFs carry no metadata keys, so city96's loader falls back to a key table with no 2.1 entry; PR #483, which would add one, has been open since 2026-09-21 with no comments, and city96's repository has had no commit since 2026-01-12. leejet's fork reads them. In the legacy table, Q4_K_M stays whole at 1024² and 2048² on both systems; Q5_K_M (5,007,397,024 B = 4.664 GiB) leaves 0.910 GiB at 1024² on the logged Windows machines and does not stay whole at 2048² there. ComfyUI's own startup warning, printed when you pass --disable-dynamic-vram, advises GGUF users to keep DynamicVRAM and use native formats, because "ComfyUI native formats like fp8, int8 and w4a8 will be faster even if they are larger than your memory." (main.py#L569-L576). That is the ComfyUI team's general claim. No same-card int8-against-GGUF pair on an Ampere card turned up in the places listed at the top; the one this series knows of, found for the RTX 3090 page, is on a 24 GB card and on the legacy loader: in alesha-pro's validation records on one RTX 3090 on Linux, whose 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 a Q4_K_M GGUF DiT from abenzerps/Qwen-Image-2.1-Uncensored-GGUF (4,604,557,984 B, not Abiray's file; named in the record's model manifest) in leejet's loader took 54.75 s (int8 record, GGUF record), in separate sessions with different seeds and job order. On 24 GB the int8 file is fully resident; on this card it is not, so that pair does not settle the question here. The GGUF record also carries an artificial 8 GiB-budget profile on that same RTX 3090: the legacy loader with --lowvram --reserve-vram 16 and the text encoder on the CPU, where a 512² image took 111.75 s and a 1024² one 145.90 s, both at 40 steps. The two are not comparable with each other: the 512² run was a cold start, and both include text encoding on the CPU. The record itself says this does not replace testing on an actual 8 GiB card, and it is not a figure for this one: a 24 GB card with a reserve flag is not a card with 8 GB.

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  git clone https://github.com/city96/ComfyUI-GGUF custom_nodes/ComfyUI-GGUF && \
  pip install -r custom_nodes/ComfyUI-GGUF/requirements.txt && \
  hf download Abiray/Qwen-Image-2.1-GGUF qwen_image_2.1_Q4_K_M.gguf \
    --revision c9dd12108f53974cd1e0abd708df042d6df0ca8d --local-dir "$COMFY/models/unet"

The GGUF route still needs the w4a8 encoder from step 3.

Windows: the v0.37.0 portable

The portable already carries a cu130 PyTorch, so step 1 does not apply. There is no .venv and no hf on the PATH: use the interpreter the portable ships, python_embeded\python.exe, the same one its run_nvidia_gpu.bat starts ComfyUI with, and run these in Command Prompt (cmd.exe, not PowerShell) from the portable's top folder, the one that holds python_embeded and ComfyUI. The official files (step 3):

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 vae/qwen_image_2.1_vae_bf16.safetensors text_encoders/qwen3vl_8b_w4a8.safetensors diffusion_models/qwen_image_2.1_int8_convrot.safetensors --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir ComfyUI\models

Optional (step 4), the W4A8 diffusion model:

python_embeded\python.exe -s -m huggingface_hub.cli.hf download NidAll/Qwen-Image-2.1-Mixed-Balanced qwen_image_2.1_mixed_balanced.safetensors --revision fa3fb50283df2f9c2854afaa198b5fc09f84835a --local-dir ComfyUI\models\diffusion_models

-m huggingface_hub.cli.hf is the module behind the hf command, and it runs directly because cli/hf.py ends in a __main__ guard. certutil -hashfile <file> SHA256 prints the hashes to compare with the ones above.

Running

Start ComfyUI with no memory flags:

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && python main.py

On the Windows portable, double-click run_nvidia_gpu.bat. Before loading anything, read the first screen of the log:

• Device: cuda:0 NVIDIA GeForce RTX 3060 Ti : cudaMallocAsync.
• Total VRAM 8192 MB (or 8191) on Windows, or a figure between 7840 and 7960 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: showing 'disabled': False. The cu130 gate calls registry.disable("cuda"), which comfy-kitchen's registry reports as 'disabled': True while 'available' can stay True, so checking available alone proves nothing.
• DynamicVRAM support detected and enabled and ComfyUI version: 0.37.0.

When a model loads you will also see Model storage policy: fast_disk=… (see What crosses the link) and, for the DiT, the Native ops line from step 2.

--lowvram does nothing here; its help text in comfy/cli_args.py says "Doesn't do anything if dynamic vram is enabled." The flag that does something is --vram-headroom N, which makes DynamicVRAM keep N GiB more free. One RTX 3060 Ti owner's report bears on it: in issue #15666 (2026-08-20), a user on Windows 10 with ComfyUI v0.33.0-29-g5ab2f7a2 (29 commits past that tag), torch 2.13.0 on CUDA 13.0, 16 GB of RAM and the card in a PCIe 3.0 x16 slot ran a MiniMax H3 workflow, a different and larger model, with one int8 file (minimax_h3_ref2va_int8_convrot) and a turbo LoRA (minimax_h3_turbo_v4_step600_ema, 779,849,816 B as published in larryvrh/MiniMax-H3-Turbo-Lora), and reported that without the flag generation was extremely slow and seemed bottlenecked on PCIe, while --vram-headroom 1 and --vram-headroom 5 both gave good results. Another user in the same thread, on an RTX 5090, reported that the flag did not hold VRAM use down the way they wanted and made their frontend glitch. No report of it with Qwen-Image-2.1 on this card turned up in the places listed at the top; if the int8 DiT crawls on Windows, it is the cheap thing to test.

Text to image

Open the Templates panel 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 since). Its subgraph node exposes unet_name, clip_name and vae_name directly:

• set clip_name to qwen3vl_8b_w4a8.safetensors, the one change this card needs;
• leave unet_name on qwen_image_2.1_int8_convrot.safetensors, or pick qwen_image_2.1_mixed_balanced.safetensors if you downloaded it;
• keep the template's defaults: 25 steps, cfg 1, euler, simple, 1024×1024 from the ResolutionSelector.

The template's own note reads "negative_prompt: unused while cfg is 1.", and says the official pipeline uses 40–50 Euler steps where the template starts at 25. 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 the int8 and bf16 files alike 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 from "high definition", 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. For the GGUF build, unpack the subgraph and replace UNETLoader with Unet Loader (GGUF).

Transparent images. 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, which keeps the alpha channel.

2048×2048 is unmeasured on this card. The template note says "For native 2K, set 1:1 and 4 megapixels". With a 4-bit DiT the sampling stage stays whole on paper under either loader (the tables above), with a gate_up intermediate of 0.75 GiB; with the int8 DiT, 2K is where borderline turns into streaming on Linux too. The decode estimate at 2048² is 7.031 GiB, more than the card has; if the real decode does not fit, ComfyUI retries it tiled (Troubleshooting). ComfyUI also fixes this model's sampling shift at 0.69 at every size: issue #16447 (open) reports the mismatch with the vendor's dynamic shift, and comfyanonymous replied "This is kind of on purpose, the higher the shift the more you see a grid pattern".

A step-distilled option for 2.1 exists: Viggle/Qwen-Image-2.1-viggle-turbo, a third-party distillation by Viggle. Its first release on 2026-09-22 (labelled v0.1) was a 4-step rank-64 LoRA and a full bf16 transformer; on 2026-09-23 Viggle added v0.2, a 5-step rank-256 LoRA that the card now says to use, and kept the v0.1 files for reproducibility. The card calls v0.2 a preview that "still falls short of the base model" on complicated editing, documents diffusers only (from a pinned git commit, with its own five-step sigma schedule), and names no ComfyUI workflow; nothing on this page was run with either version. Third-party ComfyUI conversions of the v0.1 files exist, all published before v0.2 (read 2026-09-23): t8star/Qwen-Image-2.1-viggle-turbo-4step-r64-comfy, a ComfyUI-format conversion of the v0.1 LoRA, and GGUF conversions of the v0.1 full transformer in Abiray/Qwen-Image-2.1-viggle-4-steps-turbo-GGUF and realrebelai/Viggle_Qwen-Image-2.1-Turbo_GGUFs; a Hugging Face search for "viggle" at 18:58Z found no conversion of v0.2, and nothing on this page was run with any of them. Two reports among the 90 tracker threads listed at the top tie a problem to a LoRA on this model, both closed on 2026-09-23: PR #16493 (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, i.e. v0.1, naming no GPU or build, before closing it.

Editing

Load Qwen Image 2.1: Image Edit (image_qwen_image_2_1_image_edit.json, same release), set its clip_name to the w4a8 encoder as above, and mention references in the prompt as <image1>, <image2> and so on. The template sets the encoder's resolution to 0; its note says "This template starts at 0: no resize beyond a multiple of 32." References go through the encoder's vision tower and, because the VAE is connected, into the sequence as latents, whose attention K/V are computed once and cached across steps by the QwenImage21Cache node.

Where that cache goes decides the speed, and on 8 GB the default cannot put it on the card. The cache costs 2 × 32 layers × 4,096 × 2 bytes = 524,288 B per cached token in bf16 (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 asks for twice the size free. The node's dtype input shrinks it, and its tooltip (comfy_extras/nodes_qwen.py) says int8 halves the cache at about bf16 accuracy and "int4 quarters it but roughly doubles the per-step error." The template's two references are 896×1152 each. The cached prefix is the prompt's text tokens plus the references' latent tokens (prefix_len in the same file, L309 and L327); the table counts the references only, so every cache size, RAM threshold and transfer time in it and below is a lower bound: a bf16 cache is low by 524,288 B per prompt token (int8 by half that, int4 by a quarter), and a RAM threshold, at two or four times the cache, by two or four times as much:

With the int8 DiT resident, at most 0.898 GiB is free on a Linux card before the CUDA context, and 0.201 GiB on the logged Windows machines, so no setting puts the template's cache on the card. Use device cpu with dtype int8: it needs twice the cache free in RAM, at least 3.938 GiB at resolution 0, and the tooltip says "auto uses spare VRAM, then RAM. cpu (RAM) is prefetched behind compute and costs little speed." That tooltip does not mean auto simply falls back to RAM. In the code (select_prefix_cache, linked above; a reading of the code, not a run), auto takes a device only if its free memory is more than four times the cache, the comment there says for cond and uncond, and RAM's free memory is what the operating system reports as available. When neither the card nor RAM passes, it does not settle for less: it recomputes the prefix on every step. At resolution 0 the RAM test needs more than 15.750 GiB available in bf16, 7.875 GiB in int8 and 3.938 GiB in int4. A 16 GB machine cannot pass the bf16 test in practice: 15.750 GiB is nearly all of its 16 GiB, and the test counts only memory still available with the operating system and ComfyUI running; on a 32 GB machine it passes only if more than 15.750 GiB is available at that moment, and this page's model files (13.266 GiB for the recommended set), which are held in RAM when they are off the card unless the fast-disk policy reads them back from disk, compete for the same memory. That is why this page sets the device explicitly: an explicit device cpu skips the four-times test and recomputes only if less than twice the cache is available. With the W4A8 DiT, 3.742 GiB is free on Linux and 3.044 GiB on the logged Windows machines, so device gpu with dtype int4 fits on paper at resolution 0 and 1056, with room on the logged Windows machines for about 3,900 prompt tokens at 1056, at the cost the tooltip names. A cache in RAM crosses the link on every cached step, 24 of 25: at resolution 0 in int8 that is at least 1.610 s per edit at PCIe 4.0 x16's raw rate and 3.220 s at PCIe 3.0 x16. 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".

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 (follow-up). A second reporter on CUDA (comment; an RTX 5070 Ti, v0.37.0, torch 2.13.0+cu130) found that grid clean but a 1536×1024 reference (grid 96×64) broken, over-sharpened and with the edit instruction ignored, at resolution=0 and at 1248; 512, 1024, 1056 and 2048 were clean there. Its conclusion is that "the trigger is the resolved grid, not the parameter value or the code path that produced it". 512 and 1056 are clean in both reports, and the two setups differ in too many ways for either to isolate a cause; 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, and a maintainer's only comment on it asks for before-and-after images.

Results

• Speed: omitted. No timing of Qwen-Image-2.1 on an RTX 3060 Ti, or on an RTX 3070 or RTX 3070 Ti (8 GB cards on the same die), turned up in the places listed at the top, and a card with more VRAM is not a stand-in: on 8 GB the weights move and on larger cards they do not. The named-card timings that do exist are on other cards, among them an RTX 3090 in alesha-pro's validation record and an RTX 4090 in a Hacker News comment on the launch thread. The one 8 GB question in that thread ("is it possible to run on 8gb ?") has no reply. If you time a run, /contribute it with the DiT file, the loader, your OS, your resolution and steps: it becomes the first datapoint on /check/qwen-image-2-1/rtx-3060-ti.
• VRAM usage: derived, not measured by this site, and loader- and OS-dependent. Under ComfyUI's default DynamicVRAM loader, the recommended setup's largest stage is sampling with the int8 DiT: 6.758 GiB of weights plus comfy-aimdo's 0.250 GiB headroom, 7.008 GiB, which leaves 0.648 GiB of the 7.656 GiB a Linux 3060 Ti reports for the CUDA context, any desktop and activations. On the logged Windows machines the same DiT plus the 0.500 GiB Windows headroom is 0.299 GiB more than is free, so part of it streams on every step. The w4a8 encode is 6.129 GiB on Linux and 6.379 GiB on Windows. The W4A8 DiT swap is 4.165 GiB on Linux and 4.415 GiB on Windows, and stays whole on both. The vendor publishes no VRAM figure: neither the Hugging Face card nor the GitHub README gives one, and issue #4 on the vendor repository, asking for minimum and recommended hardware, has no answer from the team. The live figure, once someone submits one, is at /check/qwen-image-2-1/rtx-3060-ti.
• Quality notes: no comparison of the W4A8, INT4 or GGUF builds' output against the int8 file by anyone but the W4A8 uploader turned up. The VAE has a reported grid artifact: the vendor's discussion #12 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); posters there reproduce it with a bare encode–decode round trip and point to workarounds, none of them a fix, and no one from Qwen has replied (read 2026-09-23). Inspect native-2K portraits at 100%.

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

Troubleshooting

WARNING: You need pytorch with cu130 or higher… at startup

PyTorch is older than CUDA 13, so comfy-kitchen's CUDA backend is disabled and the diffusion model's quantised layers run on its eager fallback (step 2); nothing fails, it is slow. Reinstall the cu130 stack into the page's venv, not the system Python, make sure the driver is from the 580 branch or newer, and check the version print again (the Windows portable already ships cu130):

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
    torch torchvision torchaudio && \
  python -c "import torch; print(torch.__version__, torch.version.cuda)"

How much the eager path costs on this card is unmeasured. On the site operator's RTX 5060 Ti 16GB, a different card, the template image took 69.4 s on a cu128 build against 21.4 s on cu130 (cu128 session, cu130 session; one rig, one operator, unreplicated). On issue #16470, an RTX 5060 Ti on 2.10.0+cu128 whose int8 file ran slower than a GGUF Q8_0, kijai (a repository collaborator) replied "You need pytorch with cu130 for int8 models to work properly."

Everything is slow, and the disk or the PCIe link stays busy

Something that should stay on the card is being re-read. Check, in order: that the text encoder is the w4a8 file and not the template's int8 one; the Model storage policy line (a model on a slow disk with fast_disk=True, or too little RAM with False); and, with the int8 DiT on Windows, --vram-headroom 1 (see Running). The W4A8 DiT (step 4) is the swap that removes the per-step re-read. While a generation runs, check the link too; at idle it drops to its slowest speed to save power:

nvidia-smi --query-gpu=name,pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current,pcie.link.width.max --format=csv

Under load you want generation 4 and width 16. Generation 3 means the slot or the board is PCIe 3.0, and every link time on this page doubles.

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

Not reported with this model, and not on this card, but reported on another compute-capability 8.6 card with the same kernel library. Issue #14719 (open, no maintainer reply) comes from an RTX 3080 Ti owner running LTX 2.3 workflows on ComfyUI 0.26 and 0.27 with torch 2.10.0+cu130: repeated runs froze the whole machine, and in the reporter's A/B only disabling comfy-kitchen's CUDA backend stopped it. The reporter later wrote that a clean install runs fine for them with --disable-dynamic-vram --disable-pinned-memory. v0.37.0 pins newer versions of both libraries, and whether the 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 table in Requirements.

JSONDecodeError: Expecting value: line 1 column 1 (char 0) when the text encoder loads

Check the file first. On issue #16472 the template's int8 encoder failed to load with this error; kijai replied "This is most likely a corrupt/incomplete model file.", the reporter confirmed on 2026-09-22 that downloading it again fixed it, and kijai closed the issue as completed that evening. Compare the file's sha256 with step 3 and download it again if it differs.

Edit output over-sharpened or speckled, or the edit ignored

Issue #16435 under Editing: set resolution to 1056 (or 512, which shrinks the references). Disconnecting vae from TextEncodeQwenImage21 also avoided it in both reports, at the cost of much weaker adherence to the reference.

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. With the int8 DiT set QwenImage21Cache to device cpu and dtype int8, which still recomputes if less than twice the cache (at least 3.938 GiB at resolution 0) is available in RAM; with the W4A8 DiT, device gpu and dtype int4 is the setting that keeps it on the card. 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 (four comments, none from a maintainer; last 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 say it is intermittent and seems tied to larger input images, and 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 and is reached when the edit cache sits in system RAM, which on this card it does.
• At the end of the second generation. PR #16481 (opened 2026-09-22T21:24Z, open, no maintainer review when read on 2026-09-23) 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 90 tracker threads listed at the top, which is an absence of reports, not a finding that the tag is unaffected.

If you hit either on master, go back to the 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-23 (18:34Z) is v0.37.2, so the startup log will read 0.37.2; neither tag after v0.37.0 changes what this model runs or its workflow files (Installation, step 1).

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 quantised model raises this error on master, with a Qwen-Image-2.1 int8/convrot checkpoint (it names both the int8 and the ConvRot W4A4 layouts), and that every later generation fails the same way until the server restarts. At v0.37.0 the legacy patcher's unpatch_model restores backed-up weights through comfy.utils.set_attr_param, which has the same code as the PR's "before", 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 quantised 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. If you hit it after adding or removing a LoRA, such as the turbo conversion above, restart ComfyUI.

Given normalized_shape=[4096], expected input with shape [*4096]

The file in CLIPLoader is not the Qwen-Image-2.1 encoder. On the repack's discussion #2 the same error, with conditioning of width 5120, was the reporter loading the wrong file. A Qwen3-VL GGUF encoder in city96's CLIPLoaderGGUF fails this way too, with width 12288: that loader attaches the vision tower only for qwen2vl (loader.py#L501), and PR #485 (opened 2026-09-23, open) would load it for qwen3vl. Use one of Comfy-Org's qwen3vl_8b_* safetensors with type: qwen_image.

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 paragraph in step 4. Use Abiray's files with city96's node, or leejet's files with leejet's fork, not a mix.

Green, channel-swapped output after changing the prompt

Issue #16437, titled "Qwen-Image 2.1: --enable-dynamic-vram silently corrupts output after any model reload (channel slice offset, ROCm gfx1201)", reports output whose channels come back as [B, A, B, A] after any model reload with DynamicVRAM on, and an 8 GB card reloads on every prompt change. It is reported on AMD cards only; the reporter writes "I don't have an NVIDIA card to test whether this is ROCm-specific." and the one other commenter was on another AMD card with a different model. No NVIDIA report surfaced in the 90 tracker threads listed at the top. If you see it, restart ComfyUI, then try --disable-dynamic-vram and report the result on that issue.

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

That is the fallback working as designed: "Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding." The decode is slower and the image should be unchanged. At 2048² ComfyUI's decode estimate, 7.031 GiB, is more than this card has, so on 8 GB that fallback is the expected path whenever the real decode needs that much; close what else is using the card (a browser with hardware acceleration counts) before blaming anything else.

---

See also: the RTX 5060 page for the same 8 GB budget on Blackwell, where the swap is an NVFP4 build instead, and the RTX 3060 page for the same Ampere path with 12 GB, where the template's int8 files fit whole. Report problems, or better a timed run on this card with its log, via the submission form.