Qwen-Image-2.1 on RTX 4060 Ti 8GB: What Fits, What Streams per Step, Which 4-Bit DiTs Run

What You'll Build

A ComfyUI graph on one RTX 4060 Ti 8GB that turns a prompt into a 1024×1024 image — with a real alpha channel if you ask for one — using Qwen-Image-2.1, a 7B single-stream diffusion transformer (DiT) behind a Qwen3-VL-8B text encoder and a 64-channel RGBA autoencoder, released 2026-09-20 with support in ComfyUI core. Editing from reference images works too, with the caveats under Running.

Nothing on this page was measured on an RTX 4060 Ti 8GB by this site, and no timing of this model on one turned up in the searches listed under Results (reports from the 16 GB RTX 4060 Ti did, and are not figures for this card: with twice the memory, far less has to stream). Every VRAM figure below is arithmetic over byte counts from the Hugging Face tree API, over rules read from ComfyUI's source at tag v0.37.0, and over the capacity owners of this card see in public ComfyUI startup logs. Each one is labelled as derived.

The short version of that arithmetic: on 8 GB the question is not whether it runs — ComfyUI's default loader keeps whatever does not fit in system RAM and pages it in as needed — but what has to cross this card's eight PCIe lanes, and when. Swap the template's text encoder for the smallest one in the repack and the encode stage fits. The official int8 DiT is then borderline: on Windows it leaves 0.738 GiB of the 7.996 GiB the card reports, before the CUDA context, the desktop and sampling's own working memory; whatever of it does not fit is re-sent over the link on every sampling step, 1.704 s of link time per GiB per 25-step image at a PCIe 4.0 board's raw rate. The fix on this model's Blackwell 8 GB page, an NVFP4 DiT, does not carry over: Ada has no FP4 hardware. What Ada does have is ComfyUI's native 4-bit integer kernels, and two community 4-bit DiTs of 3.4–3.9 GiB use them. Neither has a published run on a named NVIDIA card in the searches listed under Results, and the evidence on their quality is thin — which is why they are offered below as options, not as the default.

⚠️ Read the licence before you download 14.24 GB. Qwen-Image-2.1 ships under a non-commercial licence. The Qwen Research License Agreement defines Non-Commercial in §1.i as "for research or evaluation purposes only" and grants its rights in §2.a "FOR NON-COMMERCIAL PURPOSES ONLY"; §2.b routes commercial use to a separate licence request. There is no territory clause — the grant in §2.a is worldwide, and §4.a is an export-controls reminder rather than a geographic exclusion. §4.b reaches past the weights: 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". The Comfy-Org repack and every community quantisation below inherit these terms. This is a reader's summary of the text, not legal advice.

Hardware data: RTX 4060 Ti 8GB (8GB VRAM, AD106, compute capability 8.9, PCIe 4.0 x8; ComfyUI reports 8,188 MiB = 7.996 GiB on Windows) · largest resident stage of the recommended setup: the int8 DiT while sampling, 7.258 GiB under ComfyUI's default loader on Windows, 0.738 GiB left, derived, not measured · See benchmark data

Requirements

The card, from primary sources

Only the specifications that change this recipe are listed: the memory the driver actually hands out, and the host link weights cross when they do not fit.

• Compute capability 8.9, 8 GB GDDR6 on a 128-bit bus, "PCI Express Gen 4". Compute capability from NVIDIA's CUDA GPUs table; memory and host interface from NVIDIA's RTX 4060 family spec page, which lists the RTX 4060 Ti with 16 GB or 8 GB and publishes no lane count.
• AD106, the same die as the 16 GB board. The PCI ID registry lists device 10de:2803 as AD106 [GeForce RTX 4060 Ti] and the 16 GB board as 10de:2805, AD106 [GeForce RTX 4060 Ti 16GB]; a third entry, 10de:2788, is AD104 [GeForce RTX 4060 Ti] (pci.ids). Nothing on this page depends on the die: capacity, bus width, host link and compute capability decide it.
• Eight lanes. The lane count comes from the card itself. Of 100 lspci -vv dumps of device 10de:2803 in the Linux Hardware Project's LsPCI collection (sampled from 126 that a code search returned), the 51 device entries that include the link registers all give the card's link capability as Width x8, even where the slot above it is x16 — for example on a B550 board (Speed 16GT/s, Width x8 under a PCIe 4.0 x16 root port) and a Raptor Lake board (under a PCIe 5.0 x16 root port). The one 10de:2788 dump with link registers reads x8 as well. TechPowerUp's database, the usual reference for this, answers automated requests with a CAPTCHA and was not used.
• At PCIe 3.0 speed on an older board, and worse in a chipset slot. On a Z370 board, whose root port is PCIe 3.0 x16, the card's own capability register reads Speed 8GT/s, Width x8: eight lanes at third-generation speed, half the rate. On an Intel 9-series board, where it sits behind a chipset root port that is itself Speed 5GT/s, Width x4, it links at Speed 5GT/s, Width x4 (downgraded): half the lanes at second-generation speed. Which slot the card is in matters as much as the board.
• What ComfyUI sees. This page read the startup logs naming an RTX 4060 Ti in 165 ComfyUI tracker issues returned by searches for the card's name next to the log's Total VRAM line. The device line does not say which board it is, so the total tells them apart: 14 excerpts in 10 issues read 8,187–8,188 MB (the 8 GB board), and all whose OS can be told from their paths or Python build are Windows. The newest is from 2026-07-29 (#15137: ComfyUI 0.29.0, PyTorch 2.13.0+cu130, DynamicVRAM support detected and enabled, comfy-aimdo initialised at VRAM: 8187 MB), and a system-stats block from a Windows portable (#5061) gives the unrounded total, 8,585,216,000 B = 7.996 GiB. ComfyUI's "MB" there is MiB, so the Windows figure is 8,188 MiB = 7.996 GiB. No Linux log for the 8 GB board turned up. The 16 GB board's Linux logs in the same set read 15,916–16,081 MiB against 16,380 on Windows, and the only Linux log for an 8 GB Ada chip found is from an RTX 4060 Laptop GPU: Total VRAM 7834 MB (#16144, 2026-09-06), 354 MiB below the Windows figure. The Linux columns below use that laptop reading, labelled, as an indication of how much less a Linux driver hands out — not as a reading of this card.

The files

Byte-exact from the Comfy-Org repack at revision ace0edeb3791a594ddfa36ed5f41a178a394e921 (its head has since moved to 9a44dbdb with README changes only; every weight file's size and LFS hash is unchanged) and from the community repositories this page discusses:

Comfy-Org ships no fp8, NVFP4 or 4-bit build of the diffusion model: the repack's recursive tree lists exactly two files under diffusion_models/, the bf16 and the int8 above.

The arithmetic, stage by stage — and which loader it describes

A single-image run is three stages — encode, sample, decode — that take turns on the card rather than sharing it. How much room each one needs depends on which of ComfyUI's two loaders is managing it.

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 the comfy-aimdo package initialises; the startup log then prints DynamicVRAM support detected and enabled. Weights are staged from system RAM (or the model file), loaded on demand and evicted when an allocation needs the room. comfy-aimdo 0.5.5, the version v0.37.0 pins, keeps a live headroom free: on Linux VRAM_HEADROOM, 256 MiB, against cuMemGetInfo (src/plat.h#L145-L146); on Windows 512 MiB below the budget WDDM grants the process — which can sit below physical VRAM — and, with NVML pressure on (the default), 512 MiB of free VRAM by NVML (src-win/shmem-detect.c#L105-L107). So 0.500 GiB on Windows and 0.250 GiB on Linux. ComfyUI's own reserve and per-model estimates do not decide residency here: the comment on the estimate says that when every model is dynamic "this is ignored and its all done dynamically." (comfy/model_patcher.py#L1840-L1843).

Legacy estimate-based loading is what you get with --disable-dynamic-vram (or --highvram, --gpu-only, --novram, --cpu). It also governs a GGUF DiT in either mode, because city96's GGUFModelPatcher subclasses ComfyUI's plain ModelPatcher, which reports itself as non-dynamic (nodes.py#L35). Its reserve is minimum_inference_memory() in comfy/model_management.py: 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 GiB, so not to this card) — 1.191 GiB on Linux, 1.386 GiB on Windows. load_models_gpu() compares two different figures against free VRAM. The residency threshold — weights plus the larger of that reserve and the stage's batch-1 estimate plus EXTRA_RESERVED_VRAM — decides whether the model being loaded goes on whole. A model that fails it is loaded partly: on NVIDIA MIN_WEIGHT_MEMORY_RATIO is 0, so it keeps free VRAM minus the larger of those two figures on the card (model_management.py#L1021-L1025, #L458-L460), and the rest is re-sent every step. The unload request — 1.1 × the incoming weights plus the larger of the reserve and ComfyUI's doubled estimate plus EXTRA_RESERVED_VRAM (comfy/sampler_helpers.py) — decides how much of the other models free_memory() pushes off the card first.

Windows (7.996 GiB)          weights  DynamicVRAM (+0.500)        legacy (+1.386)
encode  qwen3vl_8b_w4a8        5.879   6.379   1.617 left          7.265   0.732 left
encode  qwen3vl_8b_int8_conv   8.709   weights alone exceed the card — part streams under either loader
sample  int8_convrot DiT       6.758   7.258   0.738 left, borderline  8.144   0.148 short → streams
sample  W4A8 DiT (NidAll)      3.915   4.415   3.581 left          5.301   2.695 left
sample  INT4 ConvRot DiT       3.415   3.915   4.081 left          4.801   3.195 left
sample  GGUF Q6_K              5.473   —  (GGUF is always legacy)    6.859   1.137 left
decode  VAE, 1024²             0.629   + ComfyUI's decode estimate 1.758 = 2.387

Linux, laptop reading (7.650 GiB) — an indication, see above
encode  qwen3vl_8b_w4a8        5.879   6.129   1.522 left          7.069   0.581 left
sample  int8_convrot DiT       6.758   7.008   0.642 left, borderline  7.949   0.299 short → streams
sample  W4A8 DiT (NidAll)      3.915   4.165   3.486 left          5.105   2.545 left
sample  INT4 ConvRot DiT       3.415   3.665   3.986 left          4.605   3.045 left

Both loaders measure against free VRAM, not capacity. comfy-aimdo polls the live figure; the legacy loader's get_free_memory() reads torch.cuda.mem_get_info(). Either way the CUDA context and any display this card drives have already taken their share, and nothing on this page knows how large that share is on your machine. Every "left" figure above is before it.

That is why the int8 DiT is marked borderline rather than streaming. Under DynamicVRAM, 6.758 GiB of weights plus aimdo's 0.500 GiB leaves 0.738 GiB of the Windows figure for the CUDA context, the desktop and sampling's working memory. Whether that is enough for the whole model to stay on the card is not established either way — no one has published a run on a desktop 8 GB Ada card. Under the legacy loader the answer is settled: the threshold is 0.148 GiB over the Windows figure before anything else is on the card, so at least that much of the DiT is re-sent every step, plus whatever the CUDA context and the desktop take.

The encoder and the DiT never share the card. int8 DiT plus w4a8 encoder is 13,568,888,428 B = 12.637 GiB of weights; even with the 4-bit DiTs the pair is 9.293 GiB (INT4 ConvRot) or 9.793 GiB (W4A8). Under DynamicVRAM, free_memory() deliberately does not unload one dynamic model for another (comfy/model_management.py#L912-L916); comfy-aimdo evicts pages as allocations need the room. Under the legacy loader, the int8 DiT's unload request at 1024² is 1.1 × 6.758 + 1.546 = 8.980 GiB on Windows, more than the card, so every other model leaves the card before sampling. The issue #16437 reporter describes the same exchange on a 16 GB AMD card, where the int8 pair "cannot co-reside" either.

The decode estimate is ComfyUI's, and it is conservative. For this VAE, comfy/sd.py budgets memory_used_decode = 900 × h × w × 256 × dtype_size over the latent grid: 64 × 64 at 1024² gives 1,887,436,800 B = 1.758 GiB in bf16. Under the legacy loader ComfyUI frees that much before decoding, unloading part of the DiT if it must. Under DynamicVRAM the VAE is itself a dynamic model and the estimate only sizes the decode batch; DiT pages are evicted only if the decode's real allocations need the room.

Activations are small at 1024² and not at 2048². The largest single intermediate in a block is the fused MLP's gate_up output, 24,576 features wide (read from the INT4 build's safetensors header, where transformer_blocks.0.img_mlp.gate_up.weight has 24,576 rows): 4,096 image tokens × 24,576 × 2 bytes = 0.1875 GiB at 1024², 0.75 GiB at 2048² with 16,384 tokens. That is one tensor, not a peak — but at 2048² it alone is more than the 0.738 GiB the int8 DiT leaves on Windows, so at 2K the int8 build streams. Attention adds little: build_sequence gives only text segments a causal mask, and image segments reach attention with mask=None, so no sequence-squared mask is built.

What crosses the x8 link, and when

This is arithmetic at the link's raw rate, not a measurement. The Linux kernel converts a PCIe 4.0 link speed to usable bits as 16000*128/130 Mb/s per lane (drivers/pci/pci.h, v6.12, the line code folded in), which for eight lanes is 15.754 GB/s per direction on a PCIe 4.0 board and 7.877 GB/s on a PCIe 3.0 board. Real copies are slower, so every time below is a lower bound — and it only costs wall-clock time where it does not hide behind compute.

Per sampling step: whatever part of the DiT is not resident. Under DynamicVRAM a model's weights sit in a virtual address range split into 32 MiB pages. When VRAM is short, comfy-aimdo lowers the lowest-priority model's watermark and frees its pages from the top down (src/model-vbar.c, vbars_free); a later fault above the watermark is refused, and ComfyUI then copies that layer's weights into a transfer buffer for that one use (comfy/ops.py). So the resident part stays resident, and the part above the watermark crosses once per model call — once per step at cfg 1. The legacy loader does the same with a fixed split (above). Every GiB of the DiT that does not fit costs:

For scale, if none of the int8 DiT stayed resident, 25 steps would move 181,419,576,600 B = 168.960 GiB: 11.516 s on PCIe 4.0 x8 and 23.032 s on PCIe 3.0 x8. With a 4-bit DiT that fits, this row is zero.

Per prompt change: the encoder, then the DiT again. Re-queue with only the seed changed and nothing crosses for the encoder — ComfyUI caches the encoded prompt. Change the prompt and the encoder comes back onto the card, and the DiT pages it displaced come back after it. The pair is 12.637 GiB against the 7.496 GiB pool left under DynamicVRAM on Windows, so at least 5.141 GiB has to cross whatever the loader keeps; at most both models in full do. That is 0.350–0.861 s on PCIe 4.0 x8 and 0.701–1.723 s on PCIe 3.0 x8. With a 4-bit DiT the ceiling drops to 0.633 s (INT4 ConvRot) or 0.667 s (W4A8) on PCIe 4.0 x8. On the legacy loader every unload is also a copy back to system RAM, so the full re-read case is a round trip: 1.723 s on PCIe 4.0 x8 for the official pair. With the template's int8 encoder the encode stage itself does not fit, and the part that does not fit crosses on each encoder pass — twice per prompt change, because the node encodes the unused negative prompt too.

The other end of the copy may be the disk. v0.37.0 classifies each model's drive (on Linux, an NVMe link of at least PCIe 3.0 x4 counts as fast; comfy/storage.py) and prints Model storage policy: fast_disk=…. On a fast disk it uses what cli_args.py calls "disk-backed dynamic loading and offload over unpinned RAM": evicted weights are read back from the model file, which means from the operating system's file cache if it still holds them and from the drive if it does not. With 16 GB of RAM the cache cannot hold a 13.27 GiB file set beside everything else, so on a prompt change the drive, not the link, is likely the limit — an inference, not a measurement. Issue #16498 (opened 2026-09-23, no reply when read) asks why an evicted encoder is not kept in RAM under this policy; its screenshot names no files; it is of a 12 GB RTX 4070, not this card, and shows a 6.8 GB DiT, by its size the int8 file, fully resident beside an 8.7 GB encoder, by its size the int8 encoder, with 640 MB of it on the card and 8.1 GB "unloaded", and 0 KB pinned. --disable-fast-disk switches the policy off.

What else DynamicVRAM changes on an 8 GB card

• --lowvram does nothing here. Its help text in comfy/cli_args.py says "Doesn't do anything if dynamic vram is enabled."
• The text encoder runs on the GPU. text_encoder_device() returns the GPU whenever DynamicVRAM is on (PR #16374, in v0.37.0). If you would rather it never touched the card, the CLIPLoader node's advanced device input accepts cpu — expect a slow encode.
• Running out of margin is designed to cost time, not the image. A tight stage means more of it streams; neither loader refuses a model for being larger than free VRAM.

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-19T22:44Z — and tag v0.37.0 (commit 73c9bad4) is its floor. The v0.37.0 release, published 2026-09-21T07:35Z, carries Windows portable builds, including ComfyUI_windows_portable_nvidia.7z, which the v0.37.0 README describes as shipping Python 3.13 and PyTorch built for CUDA 13.0. It was still the latest release when this page was written (2026-09-23 16:22Z). Tag v0.37.1 (commit 3f767e7f, 2026-09-22) has no release object; none of its three commits changes this model's code or any of the three 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.

This page installs the v0.37.0 tag, and every ComfyUI code reference on it is to that tag. master carries PR #16430, which compiles the transformer blocks and whose 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 this card's situation if the int8 DiT does not fit. Nobody has timed it on this card. master also carries the code path of an open hard crash on image editing, #16443 (Troubleshooting), so v0.37.0 is the safer default.

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 int8 DiT and both 4-bit DiTs are formats that backend accelerates on this card (step 3), 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 v0.37.0 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, 9). 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 silently installing into the system Python or downloading to /models.

2. 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"

The repack's folder layout matches ComfyUI's, so the three files land in models/vae/, models/text_encoders/ and models/diffusion_models/. The template's own encoder, qwen3vl_8b_int8_convrot, is left out on purpose: at 8.709 GiB it is larger than the card, so it could only ever stream.

Why the smallest encoder costs you nothing in speed: at v0.37.0 every quantised text encoder is dequantised matrix by matrix for encoding — the text-encoder layers are built with mixed_precision_ops(..., full_precision_mm=True) in comfy/sd1_clip.py, and the context that switches quantised matmul back on is used only for text generation, not for conditioning. So the encoder's format is a memory choice, not a compute choice. On this card comfy-kitchen dequantises the w4a8 layers on its CUDA backend, which registers that dequantiser from compute capability 8.0 (backends/cuda/__init__.py, the commit tagged v0.2.35).

A note on encoder identity, because it explains why swapping is safe. The bf16 encoder in this repack has the same LFS sha256 (68bdc82b…) as the file of the same name in Comfy-Org/Qwen3-VL, uploaded there three months before Qwen-Image-2.1's weights existed, and two users on the model's discussion #5 report comparing tensors against stock Qwen3-VL-8B-Instruct and finding no retraining. ComfyUI picks the Qwen-Image-2.1 encoder path from the tensors present, not from the filename — it keys on the vision tower's DeepStack weights (comfy/sd.py#L1707-L1708) and then on type: qwen_image (#L1955-L1958). No side-by-side comparison of the w4a8 and int8 encoders' output turned up.

3. What Ada gets from these files

Read from ComfyUI v0.37.0 and comfy-kitchen 0.2.35, for compute capability 8.9. For the diffusion model, ComfyUI decides per device which formats run natively in get_disabled_quant_formats() (comfy/ops.py#L1710-L1724) and prints the result when it loads a quantised model. On compute capability 8.9 the NVFP4 and MXFP8 checks fail (they want major 10), the FP8 and INT8 checks pass, and the INT8 check also covers the two 4-bit integer formats. The log line is the same on any 8.9 card. An RTX 4060 Laptop GPU's log (#16144, ComfyUI 0.34.0, PyTorch 2.13.0+cu130) prints Native ops: convrot_w4a4, float8_e5m2, asym_w4a8_int8, int8_tensorwise, float8_e4m3fn , emulated ops: nvfp4, mxfp8, and an RTX 4070 SUPER's (#15528, 0.32.0, 2.13.0+cu130) the same names in another order. Both logs also show comfy-kitchen's CUDA backend with 'disabled': False and, among its capabilities, int8_linear, w4a8_int8_linear and convrot_w4a4_linear.

• The official int8 DiT runs on a native kernel with cu130. comfy-kitchen registers its CUDA int8_linear from compute capability 7.5, takes the CUTLASS INT8 path from major 8 (backends/cuda/__init__.py), and its default build targets include 89 on Windows and Linux (setup.py). Whether int8 beats bf16 on Ada was not measured in any source the searches listed under Results turned up: none of them compares the int8 and bf16 files on one Ada card in ComfyUI. In those searches the bf16 transformer was timed on Ada only in other runtimes: on an RTX 4060 Laptop GPU through DiffSynth-Studio with disk offload (Anchen0823/qwen-image-studio, whose README gives about 8 minutes for an early 512×512, 40-step test), and on an RTX 4090 48GB as the bf16 baseline of ModelsLab's Nunchaku 4-bit build, a diffusers pipeline whose card gives only the ratio (step 4). The int8-versus-bf16 comparisons they found are on Blackwell cards, among them BennyDaBall's RTX 5090 validation. On this card bf16 cannot be resident anyway.
• INT4 ConvRot (convrot_w4a4) takes a native 4-bit path, activations included, on Ampere and Ada (compute capability major 8) and, above the smallest batch sizes, on Turing RTX 20 cards; Hopper and Blackwell quantise the activations to int8 instead. On major 8, _cuda_device_supports_native_int4_mma() is true, and its comment says the kernel emits the "sm80+ integer MMA shape": convrot_w4a4_linear quantises the activations to 4 bits as well and multiplies with 4-bit integer MMA, on every call. A Turing RTX 20 card (not a GTX 16) does the same through a separate kernel, _int4_linear_turing, documented as using "Turing's native m8n8k32 INT4 tensor cores", when a call has more than eight rows. The 4-bit activations are the file's default, not a property of the format: ComfyUI v0.37.0 takes each layer's linear_dtype from the file's metadata and defaults it to int4 (comfy/ops.py#L1236-L1249), and comfy-kitchen's COMFY_KITCHEN_FORCE_INT4_INT8_FALLBACK=1 forces the int8 path on any card. toxicdog's file (step 4) sets no linear_dtype, so at default settings it runs with 4-bit activations on this card and with 8-bit ones on an RTX 50-series card — the precise meaning of "native" here. comfy-kitchen's author put it plainly when the format landed (PR #65, comfyanonymous, a repository member, merged 2026-07-09): "Should work on 30 and 40 series. 50 series doesn't have int4 ops so it will use int8 ops."
• W4A8 (asym_w4a8_int8) keeps 8-bit activations. Its CUDA w4a8_int8_linear is registered from compute capability 8.0: 4-bit weights, activations quantised to int8, an INT8 GEMM.
• NVFP4 is emulated. supports_nvfp4_compute() wants compute capability 10, so an NVFP4 DiT such as BennyDaBall's loads and its layers are expanded to bf16 for every matmul: the memory saving survives, the kernel does not. That is why the NVFP4 swap on this model's RTX 5060 page does not carry over.
• FP8 hardware sits idle. float8_e4m3fn is native at 8.9, but the three Qwen-Image-2.1 repositories on Hugging Face whose names offer an FP8 diffusion model are not ComfyUI-format: unsloth/Qwen-Image-2.1-FP8's file, read over a range request, carries neither comfy_quant markers, _quantization_metadata nor a scaled_fp8 key, and Rin247/Qwen-Image-2.1-FP8 and HangGlidersRule/Darkstar-Qwen-Image-2.1-Base-ModelOpt-FP8 are diffusers folders. An fp8 DiT would in any case be as large as the int8 one.

4. Optional — a 4-bit DiT that stays on the card

The default here is the official int8 DiT from step 2. Two community builds bring the diffusion model under 4 GiB, and on this card both run on native kernels. Of the 20 Qwen-Image-2.1 repositories on Hugging Face whose names mark a 4-bit or mixed-precision build (int4, W4A4 or W4A8, Nunchaku, 4bit, mixed; read 2026-09-23), these two and a byte-identical copy of one of them are the only ComfyUI-format diffusion models; the rest are diffusers folders (bitsandbytes, SDNQ, ModelOpt, Nunchaku), MLX or MNN conversions for Apple and mobile runtimes, or text encoders. Two ComfyUI-format NVFP4 DiTs, BennyDaBall's (in the table above) and pottokao's, whose header declares nvfp4 for 192 layers, are 4-bit as well, but on this card they run emulated (step 3). Neither the W4A8 nor the INT4 ConvRot build has been run on any named NVIDIA card by anyone who published the result, both inherit the research licence, and both are three days old. What either buys, by the arithmetic above: the whole DiT stays resident at 1024² and at 2048² (3.6–4.1 GiB left on Windows), nothing crosses the link per step, and there is room for an edit cache on the card (Editing). What it costs is the part nobody has measured on this card: output quality, and whether the per-step savings are visible at all next to this card's compute time.

W4A8 — NidAll's Mixed Balanced (4,203,397,480 B = 3.915 GiB). Converted with the author's comfyui-native-quantizer from the bf16 DiT. Read over an HTTP range request, its safetensors header quantises 192 layers as {"convrot": true, "convrot_groupsize": 256, "format": "asym_w4a8_int8", "group_size": 16} and keeps 73 tensors unquantised. That is the same format, with the same flags, as the w4a8 encoder Comfy-Org ships in the repack (whose per-layer markers read {"format": "asym_w4a8_int8", "group_size": 16, "convrot": true, "convrot_groupsize": 256}), and ComfyUI v0.37.0 reads it from the file's _quantization_metadata through the same branch in comfy/ops.py — a reading of the loader code, not a run. On this card it keeps 8-bit activations. Its card calls it experimental and says "Initial testing shows very strong retention compared with the official INT8 ConvRot model, including typography-heavy generations." — the author's own assessment, with two example images, no metric and no hardware named. The file's own header records its quality validation level as unverified and its calibration as calibration-free. If you want the DiT resident on this card, this is the build to try first, for the activations reason alone.

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"

INT4 ConvRot — toxicdog's build (3,666,512,184 B = 3.415 GiB). Its header quantises 193 layers as {"convrot_groupsize": 256, "format": "convrot_w4a4", "quant_group_size": 64} in the file's _quantization_metadata, which v0.37.0's convert_old_quants turns into the per-layer markers UNETLoader needs, so the stock loader takes it — again from the code, not a run. It is the smallest ComfyUI-native DiT found, and on this card it is the most aggressive: 4-bit weights and 4-bit activations (step 3). The repository's README says it was converted "for testing in Radiant Canvas for fast macOS inference"; the one comment on its discussion tab, from a user who names no card or runtime, is titled "INT4 seems to yield poor output quality. Could we perhaps try quantizing it to W4A8 format?" chfm/Qwen-Image-2.1-INT4ConvRot-ComfyUI is a byte-identical copy (every LFS hash matches), and the same DiT, by LFS hash, also sits in toxicdog's own Qwen-Image-2.1 repository. Its INT4 encoder, 6,880,836,952 B, is larger than the w4a8 one and is dequantised for encoding anyway, so skip it.

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  hf download toxicdog/Qwen-Image-2.1-INT4ConvRot-ComfyUI \
    diffusion_models/qwen_image_2.1_int4_convrot.safetensors \
    --revision 24bc7ee4fa04a19a013df8d53f66d22f6e61dc0c --local-dir "$COMFY/models"

Not for ComfyUI core: the Nunchaku/SVDQuant builds. ModelsLab/Qwen-Image-2.1-W4A4-int4 is an SVDQuant W4A4 transformer packed for Nunchaku's fused kernel; its card names nunchaku==1.3.0.dev20260306+cu13.0torch2.12, a diffusers pipeline, and a loader module (nunchaku_io) from a GitHub repository, ModelsLab/qwen-image-2-1-server, that returned 404 when read. Its one Ada figure is from a card it lists as an RTX 4090 48GB, not this one, with the 16.3 GB bf16 encoder resident beside the transformer. BlazeMCworld/Qwen-Image-2.1-nunchaku-lite-int4 needs diffusers installed from main, per its card. catplusplus/nunchaku-qwen-image-2.1 is an NVFP4 build. ComfyUI v0.37.0 has no SVDQuant format in its loader table (comfy/quant_ops.py); Nunchaku's newest release is dated 2026-03-06 and its ComfyUI node's repository was last pushed on 2026-09-06, both before this model's release. So none of these is a ComfyUI path on this card today.

GGUF (any NVIDIA architecture). Abiray's files are made for city96's ComfyUI-GGUF, which dequantises each weight on the fly — so a GGUF DiT gives up the integer kernels above. Because that node's patcher is non-dynamic, the legacy column applies: Q6_K leaves 1.137 GiB of the Windows figure; Q8_0 (7,591,579,808 B = 7.070 GiB) does not fit. Resident does not mean faster. ComfyUI's own startup warning, printed when you pass --disable-dynamic-vram, advises GGUF users to keep it on 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) — the ComfyUI team's general claim, not a measurement of this model.

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_Q6_K.gguf \
    --revision c9dd12108f53974cd1e0abd708df042d6df0ca8d --local-dir "$COMFY/models/unet"

Why these files and not leejet's or unsloth's: read over an HTTP range request, Abiray's GGUF header declares general.architecture = qwen_image, which is in city96's IMG_ARCH_LIST. leejet's and unsloth's Q4 headers carry no metadata keys at all; city96's loader then guesses the architecture from tensor names and knows no Qwen-Image-2.1 layout, so they need leejet's fork, which added 2.1 detection on 2026-09-20 and qwen_image21 to its architecture list on 2026-09-21. City96's PR #483, which would add the same detection, was open and unmerged on 2026-09-23. The GGUF route still needs the Comfy-Org w4a8 encoder from step 2: an official Qwen3-VL GGUF encoder has its vision tower in a separate mmproj file, and city96's text-encoder loader grafts an mmproj only for qwen2vl files (loader.py#L501); PR #485, which would extend that to qwen3vl, was also open and unmerged.

Windows: the v0.37.0 portable

The v0.37.0 release's ComfyUI_windows_portable_nvidia.7z 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 2):

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 DiT:

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

Optional (step 4), the INT4 ConvRot DiT:

python_embeded\python.exe -s -m huggingface_hub.cli.hf download toxicdog/Qwen-Image-2.1-INT4ConvRot-ComfyUI diffusion_models/qwen_image_2.1_int4_convrot.safetensors --revision 24bc7ee4fa04a19a013df8d53f66d22f6e61dc0c --local-dir ComfyUI\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.

Running

Start ComfyUI and read the log

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. No --lowvram (it does nothing here) and no --disable-dynamic-vram. On this card the first screen of the log should show:

• Device: cuda:0 NVIDIA GeForce RTX 4060 Ti : cudaMallocAsync. The name does not say 8GB, so read the next line.
• Total VRAM 8188 MB on Windows. A figure near 16,380 means the 16 GB board, whose own page installs the template unchanged.
• pytorch version: ending in +cu130, and no cu130 warning.
• Found comfy_kitchen backend cuda: with 'disabled': False — not merely 'available': True, because the cu130 gate calls registry.disable("cuda"), which comfy-kitchen's registry reports as 'disabled': True while 'available' can stay True.
• DynamicVRAM support detected and enabled, and ComfyUI version: 0.37.0 or higher.

When the DiT loads, Native ops: must list int8_tensorwise, asym_w4a8_int8 and convrot_w4a4 on the native side and nvfp4, mxfp8 on the emulated side (step 3). That line reports ComfyUI's device check, not the kernel backend, so a cu128 install prints the same line while running everything through comfy-kitchen's slower pure-PyTorch fallback. The cu130 warning is the one that tells you.

While a generation is running, check the link — at idle it drops to its slowest speed to save power, so an idle reading means nothing:

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 8. Width 8 is this card's design, not a fault. Generation 3 means the slot or the board is PCIe 3.0, and every link time on this page doubles; width 4 means a slot with only four lanes, often a chipset slot (Requirements), and it doubles again.

Text to image

Open the Templates panel and load Qwen Image 2.1: Text to Image (under Image). The bundled template is image_qwen_image_2_1_t2i.json from workflow templates v0.11.66, the version v0.37.0's requirements.txt pins, unchanged since commit 371a7b7171. 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 one of the step 4 files if you downloaded it;
• keep the template's defaults: 25 steps, cfg 1, euler, simple, 1024×1024 from the ResolutionSelector.

The template's own notes say the official pipeline uses 40–50 Euler steps and that the negative prompt is unused while cfg is 1. One user on Comfy-Org's discussion #11, Xenodermus, reported faint banding on skin, fabric and fur at the template's 25 steps (2026-09-22 16:00Z), with the int8 and bf16 files alike, and at 1024×1024 wrote "Artifact disappeared completely at 40". At 22:11Z the same user wrote that another user's workflow combined with a toned-down prompt showed no streaks, and a third user (2026-09-23 01:15Z) advises "Use 40 steps and choose 2k quality". So the thread reports two remedies, 40 steps or a milder prompt with that workflow, from users, with no Comfy-Org reply as of 2026-09-23. On this card more steps cost more link time only if the DiT streams — the per-step row in Requirements. For the GGUF build, load Abiray's included Qwen_Image_2.1_GGUF_Text2Image.json instead, or unpack the subgraph and replace UNETLoader with Unet Loader (GGUF).

Transparent images. The vendor's GitHub README gives this prompt format, and the template saves 8-bit PNG so the alpha channel survives:

This is an RGBA image with transparency. <your description>. The image has alpha channel and the background is transparent.

2048×2048 on this card is unmeasured. Set the ResolutionSelector to 1:1 and 4 megapixels. With the int8 DiT, 2K is where borderline turns into streaming: the 0.75 GiB gate_up intermediate alone exceeds the 0.738 GiB the default loader leaves on Windows, and under the legacy loader the 2048² sampling threshold (9.264 GiB on Windows) is 1.268 GiB over the card. With either 4-bit DiT the sampling stage fits on paper under both loaders — the INT4 build's legacy threshold at 2048² is 5.921 GiB on Windows, the W4A8 build's 6.421 GiB. ComfyUI's decode estimate at a 128 × 128 latent is 7.031 GiB, more than the card; if the real decode does not fit, comfy/sd.py catches the out-of-memory error, logs Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding. and finishes tiled.

Editing

Load Qwen Image 2.1: Image Edit from the same panel, set its clip_name to the w4a8 encoder as above, and mention references in the prompt as <image1>, <image2> and so on. Three things to know on this card:

• Set resolution to 1056. The shipped edit template sets the encoder's resolution to 0 on its outer node — its note says "This template starts at 0: no resize beyond a multiple of 32." Issue #16435 holds two community reports of broken edits with the VAE connected at particular reference grids, and they disagree on which: the original reporter (Apple MPS and CPU) sees broadband noise at a 64 × 64 grid, a second commenter (comment; RTX 5070 Ti, v0.37.0, cu130) sees a 1536×1024 reference broken and concludes that "the trigger is the resolved grid, not the parameter value or the code path that produced it". The setups differ in backend, OS, build, encoder precision and step count, so neither report isolates a cause. 512 and 1056 were clean in both; 512 shrinks the reference, so use 1056. PR #16444 was closed without merging on 2026-09-22 by kijai; no fix is linked to #16435, which was open and unchanged since 2026-09-21 when read on 2026-09-23.

• The prefix K/V cache decides whether the link is in the loop, or whether the prefix is recomputed. Edits cache the text-and-reference K/V across steps; per model.py and its cache_bytes line (L327), that is 2 × 32 blocks × prefix tokens × 4,096 × 2 bytes, or 524,288 B per token. The template's two 896×1152 references at resolution 1056 become 928×1184 each, 8,584 tokens, so the cache is at least 4.191 GiB at the default dtype, 2.096 GiB at int8 and 1.048 GiB at int4 — at least, because the prompt's own text tokens are part of the prefix too. At v0.37.0, auto puts it on the GPU only if more than four times that is free there, then in system RAM under the same rule, and otherwise recomputes the prefix on every step; device gpu or device cpu asks for twice the size free on that device and recomputes if it is not. System RAM's "free" is the operating system's available memory (comfy/system_memory.py). The Qwen Image 2.1 Cache node sets both (comfy_extras/nodes_qwen.py). What follows is a reading of that code, not a run on this card:

  • With the int8 DiT the GPU leg never passes for these references, at any dtype. At the default dtype auto then needs more than 16.766 GiB of available RAM, more than a 16 GB machine has, so there it recomputes the prefix on every step: nothing crosses the link for the cache, but the reference tokens go through all 32 blocks again at each step. At int8 it needs more than 8.383 GiB available, at int4 more than 4.191 GiB, which depends on what else holds RAM, the model files included.
  • When the cache does sit in system RAM — device cpu, or auto with that much available — it crosses the link to the card once per cached step, 24 times per run, plus one fill copy the other way on the first step: 0.286 s per copy at the default dtype, 0.143 s at int8, 0.071 s at int4 on PCIe 4.0 x8, so 7.142, 3.571 and 1.785 s per run, doubled on PCIe 3.0 — raw-rate lower bounds that cost time only where a block's copy outlasts its compute. device cpu needs 8.383 GiB of available RAM at the default dtype and 4.191 GiB at int8.
  • With a 4-bit DiT resident the GPU test turns on a figure this page does not know. It reads the driver's free VRAM plus memory PyTorch has reserved but is not using (model_management.py#L1815-L1820), so comfy-aimdo's headroom counts as free: with the DiT alone on the card it can see up to 4.581 GiB on Windows beside the INT4 DiT and 4.081 GiB beside the W4A8 DiT, less the CUDA context, the desktop and any other model's pages still on the card. For these two references, device gpu with dtype int4 needs 2.096 GiB (twice 1.048), which fits on paper beside either 4-bit DiT and takes the link out of the loop; the node's tooltip says int4 "quarters it but roughly doubles the per-step error." device gpu with dtype int8 needs 4.191 GiB: never beside the W4A8 DiT, and beside the INT4 DiT only if those other claims come to less than 0.390 GiB, which is not established. auto needs more than 4.191 GiB even at int4, with the same result: never beside the W4A8 DiT, not established beside the INT4 DiT. With one of the template's references alone (4,292 tokens at 1056), auto at int4 needs more than 2.096 GiB and can take the GPU beside either 4-bit DiT, on paper.

  None of these settings has been run on this card.

• Quantised caches (int8, int4) failed with an aimdo error in two community reports, one on master and one on an unidentified build — see Troubleshooting before relying on them.

Qwen also ships two prompt-enhancer models beside this one; they rewrite prompts in a separate LLM step and are not text encoders, so do not load them in CLIPLoader.

Results

• Speed: omitted. No timing of Qwen-Image-2.1 on an RTX 4060 Ti 8GB turned up. Timings on the 16 GB RTX 4060 Ti do exist — one user's approximate figures on the vendor's discussion #35, and two personal install repositories (xukecheng/Dockerfile, T8mars/Comfyui-Qwen-Image-2.1-BlockCache-T8) — but that board holds twice the memory, so its encoder and DiT stream far less, and none of them is a figure for this card. Where I looked, on 2026-09-23: the 28 ComfyUI tracker threads about Qwen-Image-2.1 opened since 2026-09-18, with all 172 of their comments, plus a tracker search for "4060" since that date (one hit, #16441, whose 4060 Ti is the 16 GB board); all 62 discussions on Qwen/Qwen-Image-2.1, Comfy-Org/Qwen-Image-2.1 and Comfy-Org/Qwen3-VL (#35 is the only one naming a 4060 Ti, the 16 GB one; #5 is an 8 GB RTX 5050 laptop owner asking for NVFP4); the model cards of all 181 Hugging Face repositories whose names match Qwen-Image-2.1 (158 have a README; the ones that mention 8 GB or the 4060 are recommendation tables, not runs); the 196 comments of the Hacker News launch thread (one asks whether 8 GB works, with no reply); the READMEs of the 137 GitHub repositories matching the model's name pushed since 2026-09-19 (134 have one) plus a GitHub code search for the model's name with "4060" (56 hits); comfy-kitchen's tracker (no issue about a 4060); and a web search. The only 8 GB 4060-class timings are from the RTX 4060 Laptop GPU, a different chip at lower power: the duc-minh-droid/backlot, jiang585/huajing and Anchen0823/qwen-image-studio READMEs time their own apps on one, and spotco/qwen_image_dev reports this page's exact file set completing on one (with --reserve-vram 1.0 and two async offload streams, no timing). None is used as a figure here. Reddit refused every request from this session, including a control request to a subreddit's front page, so it is not covered. If you time a run, /contribute it with the DiT file, your resolution, and the link reading from the log section.
• VRAM usage: derived, not measured by this site, and loader-dependent. Under ComfyUI's default DynamicVRAM loader on Windows the largest stage of the recommended setup is sampling with the int8 DiT, 7.258 GiB (6.758 GiB of weights plus comfy-aimdo's 0.500 GiB) against the 7.996 GiB the card reports, 0.738 GiB left before the CUDA context and the desktop; the w4a8 encode is 6.379 GiB; with a 4-bit DiT, sampling is 3.915 GiB (INT4 ConvRot) or 4.415 GiB (W4A8). Under the legacy loader the int8 DiT's residency threshold, 8.144 GiB, is over the card, so part of it streams. The vendor publishes no VRAM figure: neither the Hugging Face card nor the GitHub README gives one beyond suggesting enable_model_cpu_offload(), and the ComfyUI docs page lists the int8 and bf16 files with no memory figure and does not mention the w4a8 encoder. The live figure, once someone submits one, is at /check/qwen-image-2-1/rtx-4060-ti-8gb.
• Quality notes: no independent comparison of the W4A8, INT4 ConvRot, GGUF or int8 DiTs' output against each other, or of the w4a8 and int8 encoders, turned up; the W4A8 build's author reports strong retention and one user reports poor quality from the INT4 ConvRot build (step 4). On this card those two differ in a way that may matter for quality — 8-bit versus 4-bit activations — but no comparison shows it. 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 appeared 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:54Z found no conversion of v0.2, and nothing on this page was run with any of them. Two reports about Qwen-Image-2.1 with a LoRA turned up in the tracker threads listed above, 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 — v0.1, the only version then — naming no GPU or build, before closing it.

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

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 DiT's quantised layers run through its pure-PyTorch fallback — nothing fails, it is just slow. Reinstall the cu130 stack into the page's venv, not the system Python, and check the version print again:

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)"

A ComfyUI maintainer says the same: replying on issue #16470 to an RTX 5060 Ti user on 2.10.0+cu128 whose int8 file ran slower than a GGUF Q8_0, kijai (a repository collaborator) wrote "You need pytorch with cu130 for int8 models to work properly."

A generation is slow and the GPU is not busy

Something is crossing the link, or coming off the disk. In order: check the link reading during a generation (Running) — generation 3 halves every link time, and a chipset slot can cut the lanes as well (Requirements); check Model storage policy: fast_disk= in the log — with True evicted weights are re-read from the model file; close whatever else holds VRAM (a browser with hardware acceleration counts), since every MiB it takes comes out of the int8 DiT's 0.738 GiB; iterate on the seed with a fixed prompt, which moves no encoder weights; and if sampling itself is what streams, a 4-bit DiT (Installation, step 4) is the one change that takes the per-step traffic away. Do not reach for --lowvram or --enable-dynamic-vram: the first does nothing and the second is already the default.

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

That is city96's ComfyUI-GGUF refusing a GGUF with no general.architecture key, which is what leejet's stable-diffusion.cpp conversions and unsloth's files are. The same error appears on Abiray's discussion #1. Use Abiray's files with city96's node, or leejet's files with leejet's fork — not a mix.

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 GGUF of the encoder lands here by another route (step 4 explains why ComfyUI assigns it a different encoder class). The prompt-enhancer checkpoints fail differently: users on discussion #4 report garbled images rather than an error when one is loaded as the encoder. Use one of the Comfy-Org qwen3vl_8b_* safetensors with type: qwen_image.

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

Check the file before anything else. On issue #16472 the template's int8 encoder failed to load with this error; kijai (a repository collaborator) replied "This is most likely a corrupt/incomplete model file.", the reporter confirmed that downloading it again fixed it, and kijai closed the issue as completed on 2026-09-22 at 23:06Z. Compare the file's sha256 (sha256sum <file>, or certutil -hashfile <file> SHA256 on Windows) with the SHA256 its Hugging Face file page shows, and download it again if they differ.

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

Issue #16435 under Editing: certain reference grids break the VAE-reference path, and the two reports disagree on which. Set resolution to 1056 — clean in both reports, as was 512, which shrinks the reference — or disconnect vae from TextEncodeQwenImage21 and accept weaker reference adherence.

RuntimeError: aimdo memory compile error when editing with a quantised cache

Two community reports tie this error to QwenImage21Cache with a quantised dtype. The duc-minh-droid/backlot app's README, measured on an RTX 4060 Laptop GPU, reports device cpu / dtype int8 failing with it while cpu / default completed. Its install, per its root README, clones ComfyUI's default branch, master, installs a cu128 PyTorch (so comfy-kitchen's CUDA backend is off; see the cu130 entry above), and runs leejet's Q4_K GGUF DiT with --lowvram. kuraneko1/qwen21-fast-comfyui, on an RTX 4070 12 GB, reports both int8 and int4 failing with it; its install script gives the tested version as ComfyUI 0.37.0, which master also reports (its comfyui_version.py still reads 0.37.0 on 2026-09-23), so that build is not identified either way. At v0.37.0 this model's sampling does not run under the code that raises the error. The message comes only from comfy-aimdo's malloc-graph recorder (comfy_aimdo/malloc_graph.py), inside a recording or when one fails to start (could not start recording, #16342's wording), and at the tag nothing on the Qwen-Image-2.1 path starts one: comfy/ldm/qwen_image21/model.py and the cache's comfy/ldm/wan/model_animate2.py never import comfy.model_prefetch, whose malloc_graph_begin() starts it. On master, PR #16430 wraps the transformer's block loop in that recording (see #16443 below). So no path to this error is known at the tag; that is a reading of the code, and nobody has reported running a quantised cache at the tag. Of the three ComfyUI tracker threads containing the error on 2026-09-23, none is about this model: one is MiniMax H3 on a single RTX 5090 (#16342, v0.35.2), whose reporter writes that --disable-comfy-compiler made the same graph run. If you hit the error, use dtype default (and the free RAM it needs) or device off, which recomputes the prefix every step. On master, where this model's sampling records, --disable-comfy-compiler switches the recorder off (malloc_graph_enabled() checks it; the flag exists at the tag too, where it has nothing to switch off on this path); nobody has tried it with this cache.

A fine diamond grid on faces at high resolution

A community report on the model's discussion #12 attributes it to the VAE: "It's more noticeable when you generate a high-resolution image that has people with light skin tones and zoom in on their faces." Posters there reproduce it with a bare encode–decode round trip and point to workarounds (a post-processing node, or re-encoding through a different VAE); no fix has landed upstream, no one from Qwen had replied when read on 2026-09-23, and no hardware is named.

Green, channel-swapped output after changing the prompt

Issue #16437 documents 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 only; the reporter writes "I don't have an NVIDIA card to test whether this is ROCm-specific." and "Removing --enable-dynamic-vram fixes it completely." No NVIDIA report surfaced. If you see it, restart ComfyUI, then try --disable-dynamic-vram and report the result on that issue.

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. Its description names both the int8 and the ConvRot W4A4 layout (TensorWiseINT8Layout / TensorCoreConvRotW4A4Layout) and puts the cause in how any quantized tensor subclass becomes a parameter under inference mode, so by its account the error is not specific to the int8 layout; nobody has reported it with the 4-bit files in step 4. 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 — for the int8 file or for the 4-bit ones. That is a reading of the code, not a report, and no report of the error at the tag turned up. If you hit it after adding or removing a LoRA, such as the turbo conversion under Results, restart ComfyUI.

Fatal Python error: Aborted after the second image's sampling

PR #16481, opened on 2026-09-22 by sqz269, reports this hard crash on Windows 11 with an RTX 5090, torch 2.13.0+cu130, the template's int8 diffusion model and encoder, DynamicVRAM on and QwenImage21Cache at auto: the first image completed and the second aborted during the sampler's cleanup, with text-to-image and edit workflows alike. The PR attributes it to the prefix cache's pinned system-RAM slots being unpinned while a copy may still be reading them. The report says ComfyUI 0.37.0, but its stack's line numbers (qwen_image21/model.py 238, model_base.py 2678, model_patcher.py 1318) are those of master after the tag; at v0.37.0 and v0.37.1 the same lines are 236, 2674 and 1316. The code the PR patches, PoseBranchCache._free_slot calling unpin_memory (model_animate2.py), is the same at the tag this page installs, so the tag is not a known fix. No report of this crash on the tag turned up on the ComfyUI tracker on 2026-09-23, which is an absence of reports, not a finding that the tag is unaffected. The PR says it is a different crash site from #16443, and that with its change six consecutive generations completed. On 2026-09-23 it was open and unmerged, with no maintainer review. When the edit cache sits in system RAM on this card — device cpu, or auto with enough available RAM (Editing) — it is on the pinned path the PR describes.

On master: Fatal Python error: Aborted when editing

Issue #16443, open when read on 2026-09-23 (four comments, none from a maintainer), reports a hard abort in the prefix-cache copy path on image editing. Both reports are from RTX 5060 Ti 16 GB owners, on image editing, and both describe it as intermittent and tied to larger input images; on 2026-09-22 the reporter wrote "I also tested launching ComfyUI with --cuda-device 0 to force a single GPU, but the same crash still occurs." PR #16450 (open, unmerged, no maintainer review) blames the allocation-recording wrapper that #16430 put around the block loop — code that exists only on master, runs whenever DynamicVRAM is on with CUDA, and is reached when the edit cache sits in system RAM. The placement rule under Editing is the tag's; master, where this crash lives, decides differently: PR #16429, merged after the tag, makes auto count the card's resident model pages as free and, when that test fails, use pinned RAM if ComfyUI's pin budget allows, so there the template's default-dtype cache goes to system RAM or is recomputed, while an int4 cache can go to the GPU. If you hit this on master, go back to v0.37.0 (git checkout v0.37.0).

Everything is slow, and the disk light stays on

System RAM is short. The official set is 13.27 GiB and ComfyUI keeps what is not on the card in RAM — or, under the fast-disk policy, re-reads it from the model files — and with 16 GB installed the operating system can end up paging. Close other applications, use a 4-bit DiT (9.92–10.42 GiB for the set), or add RAM.

---

See also: the RTX 4060 Ti 16GB page for the same AD106 die and the same eight lanes with twice the memory, where the template's own files are the install and, for text-to-image, a prompt change is the link's main cost; this model's RTX 5060 page for the same 8 GB install on Blackwell, where the swap is NVFP4 instead. The 2025 Qwen-Image (20B) is a different model from the same team, not a quantised or cut-down version of this one.