Qwen-Image-2.1 on RTX 4060 Ti 16GB: the x8 PCIe link, per prompt change and per edit step

What You'll Build

A ComfyUI graph on one RTX 4060 Ti 16GB that turns a prompt into a 1024×1024 or native 2048×2048 image, with a real alpha channel when you ask for one, and a second graph that edits an image from reference pictures. The model is Qwen-Image-2.1: a 7B single-stream diffusion transformer, a Qwen3-VL-8B text encoder and a four-channel (RGBA) autoencoder, released on 2026-09-20 with support in ComfyUI core from day one. The install is the one ComfyUI itself ships: its official template's int8 files.

The question this page adds for this card is not about capacity. It is about the host link. The AD106 chip behind it has eight PCIe lanes, read from the card's own link registers (Requirements), and on a PCIe 3.0 motherboard those eight lanes also run at third-generation speed, half the rate. On a 16 GB card the text encoder and the diffusion model cannot both stay on the card, so weights cross that link every time you change the prompt. This page works out what that costs from the byte counts and the link's rate. The short version: on text-to-image it is small. On ComfyUI's default loader, even if both models are re-read in full, a prompt change moves 1.054 s of traffic at the link's raw rate on a PCIe 4.0 board, and 2.108 s on a PCIe 3.0 board. The edit path is where the link sits inside the sampling loop, and there is a setting that takes it back out.

Hardware data: RTX 4060 Ti 16GB (16GB VRAM, AD106, compute capability 8.9, PCIe 4.0 x8) · not measured on this card by this site · the three template files total 16.096 GiB, more than the 15.996 GiB the card reports to ComfyUI on Windows, so the encoder and the diffusion model take turns · See benchmark data

ℹ️ Nothing on this page was measured on an RTX 4060 Ti 16GB by this site. Every budget and every time below is arithmetic unless it is attributed to someone's run. The arithmetic uses byte counts from the Hugging Face tree API, rules read from ComfyUI's source at tag v0.37.0, and the link rates the Linux kernel uses, added up unrounded and rounded once. The attributed figures are one user's approximate times and memory readings on this card, under Results, and a few facts and timings from a different card, the site operator's RTX 5060 Ti 16GB (Blackwell). Each is labelled where it appears; among the latter are that the cu130 build matters and that 2048×2048 completed on a 16 GB card. That card's timings are not an estimate for this one. One rig, one operator, unreplicated; the raw sessions are public (cu130, cu128). A timed run on this card with its log is the most useful thing this page is missing (the one user report found, under Results, records its settings in its images but gives no log): /contribute.

⚠️ Read the licence before you download 17.3 GB. Qwen-Image-2.1 is not Apache-2.0 like its predecessor. Its Qwen Research License Agreement (release date printed in the file: September 20, 2026) defines Non-Commercial in §1.i as something that "shall mean for research or evaluation purposes only" and grants its rights in §2.a "FOR NON-COMMERCIAL PURPOSES ONLY"; §2.b sends commercial use to a separate licence requested by email. The §2.a grant is worldwide. The file has no territory restriction: §4.a is a reminder about export controls and §8 sets Chinese law and the courts of Hangzhou for disputes. §4.b also reaches models you train on the outputs, which must be labelled "Built with Qwen" or "Improved using Qwen". The Comfy-Org repack installed below points back at the same licence. This is a reader's summary, not legal advice.

ℹ️ Two prompt-enhancer models ship beside this one, Qwen/Qwen-Image-2.1-PE-T2I and -PE-I2I. They rewrite prompts in an optional LLM stage and are not text encoders. This page does not install them. If you add one through the TextGenerate node, know that issue #16441 (open) reports a hard abort when one node execution generates text twice, and a commenter reproduced it on an RTX 4060 Ti 16GB, on a checkout they give as v0.37.0's commit.

If you ran the 20B predecessor on this card, see Qwen-Image on RTX 4060 Ti 16GB: same family, different generation, and that one needed a GGUF to fit at all. For a model on this card where the link really is in the inner loop because the transformer is bigger than the card, see MiniMax H3 on RTX 4060 Ti 16GB.

Requirements

The three files the official text-to-image template loads, byte-exact from the Comfy-Org repack at revision ace0edeb (2026-09-20T16:14Z). The repo's head moved to 5dc5850e on 2026-09-22 with a README change only; every weight file's size and LFS hash is the same at both revisions, and this page pins ace0edeb.

The same repo also carries a bf16 diffusion model (14,230,280,616 B = 13.253 GiB), a bf16 encoder (17,534,334,616 B = 16.330 GiB), a w4a8 encoder (6,312,105,364 B = 5.879 GiB) and the two prompt enhancers. Its recursive tree lists exactly two diffusion-model files, bf16 and int8_convrot, at both revisions: there is no Comfy-Org fp8 or nvfp4 diffusion model for 2.1 in that repository.

min_vram_gb is 12. That is the smallest card size in this catalogue on which every stage of this install keeps its weights whole under both of ComfyUI's loaders, a derivation done on this model's RTX 3060 page. One install, one filter floor.

The card, from primary sources

• Compute capability 8.9, 128-bit, 16 GB GDDR6, "PCI Express Gen 4". Those are the values on NVIDIA's own spec page. It publishes no lane count.
• AD106. The PCI ID registry lists device 10de:2805 as AD106 [GeForce RTX 4060 Ti 16GB] (pci.ids).
• Eight lanes. The lane count comes from the card itself. In lspci -vv dumps uploaded to the Linux Hardware Project, device 10de:2805 gives its link capability as Width x8 on all five boards sampled, and as Speed 16GT/s, Width x8, PCIe 4.0 speed, on four of them. Examples: an X670E board, whose slot above it is x16, and a B550 board. TechPowerUp's database, the usual reference for this, answered every automated request with a CAPTCHA or a 403.
• At PCIe 3.0 speed on an older board. In a dump from a Z170 board, whose CPU slot is PCIe 3.0 x16 (Speed 8GT/s, Width x16), the same card links at Speed 8GT/s (downgraded), Width x8. Eight lanes, third-generation speed.
• What ComfyUI sees. Two public ComfyUI startup logs from this card: Total VRAM 16380 MB on a Windows portable (issue #15199), and Total VRAM 15946 MB on a Linux git install (issue #12872). Their system-stats snapshots, taken with ComfyUI running and no model loaded, show 15,975,055,360 B (14.878 GiB) and 15,669,592,064 B (14.593 GiB) free. A third owner of this card, in #16441, gives the same Windows total and the link: "RTX 4060 Ti 16GB (16380 MB), driver 591.86 / CUDA 13.1, PCIe 4.0 ×8". Those free figures are other people's machines, with whatever display they had attached. They are what the arithmetic below uses as the card's usable pool, not a promise about yours.

Installation

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

Support is in ComfyUI core, not a custom node: PR #16400 by kijai, merged 2026-09-19T22:44Z as commit 6bfaacc67c. The TextEncodeQwenImage21 node is absent from tag v0.36.0 and present in v0.37.0 (commit 73c9bad4). The template index lists minComfyUIVersion 0.37.0 for all three Qwen-Image-2.1 templates. The v0.37.0 release, with Windows portable builds, was published on 2026-09-21T07:35Z. It was still the latest release, with a release object and portable builds, when this page was last checked (2026-09-22, 20:43Z). The tag v0.37.1 (commit 3f767e7f) was cut at 19:12Z that day, with no release object or portable build yet. Against v0.37.0 it has three commits: Hunyuan Image 3.5 partner nodes, a workflow-templates pin moved to 0.11.68, and the version bump. In templates 0.11.68 all three Qwen-Image-2.1 template files are byte-identical to 0.11.66's, and nothing in the tag touches this model. The tag carries the two commits of backport PR #16467, which was itself closed without merging.

Two related changes landed on master after the tag: PR #16429, which changes where the edit cache is kept, and PR #16430, which compiles the transformer blocks. The second one is written for exactly this card's kind of link. Its author, a repository contributor, says "Some users in specific conditions (slow PCIe bus, disk offload) will have considerable speedup when offload is the bottleneck." Nobody has timed it on this card. master also carries the code path of an open hard crash on image editing, #16443 (Troubleshooting). v0.37.0 is the safer default, and nothing on this page needs master.

Windows, the short route. Download ComfyUI_windows_portable_nvidia.7z from the v0.37.0 release and extract it. The ComfyUI README at the tag says "The portable above currently comes with python 3.13 and pytorch cuda 13.0." Do not take the nvidia_cu126 build: the README marks it for 10-series and older cards. The portable has no virtual environment to activate. Everything runs through its own python_embeded\python.exe, which is how its run_nvidia_gpu.bat starts ComfyUI.

Linux, or a git install anywhere. The same README says "Using a cu130 or above version of pytorch is required on Nvidia 20 series and above." The 40 series is included.

git clone https://github.com/Comfy-Org/ComfyUI
cd ComfyUI
git checkout v0.37.0          # the floor and the safer default
python3 -m venv .venv && source .venv/bin/activate
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.get_device_capability())"
# expect a +cu130 build, 13.0, and (8, 9)

requirements.txt at the tag pins comfy-kitchen==0.2.35, comfy-aimdo==0.5.5 and comfyui-workflow-templates==0.11.66. Leave this shell open with .venv active: step 2 runs in it.

2. Download the three files

Pinned to the revision whose byte counts are in the table above. --local-dir models reproduces the repo's folder layout, so run it from the ComfyUI folder with .venv active.

# only if this is a new shell: cd path/to/ComfyUI && source .venv/bin/activate
pip install -U huggingface_hub
hf download Comfy-Org/Qwen-Image-2.1 \
  diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
  text_encoders/qwen3vl_8b_int8_convrot.safetensors \
  vae/qwen_image_2.1_vae_bf16.safetensors \
  --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir models

On the Windows portable, run the same download from the ComfyUI_windows_portable folder through its embedded Python:

.\python_embeded\python.exe -s -m pip install -U huggingface_hub
.\python_embeded\python.exe -s -m huggingface_hub.cli.hf download Comfy-Org/Qwen-Image-2.1 diffusion_models/qwen_image_2.1_int8_convrot.safetensors text_encoders/qwen3vl_8b_int8_convrot.safetensors vae/qwen_image_2.1_vae_bf16.safetensors --revision ace0edeb3791a594ddfa36ed5f41a178a394e921 --local-dir ComfyUI\models

Then check the bytes against the LFS hashes in the tree. This is worth doing on 17 GB, and it is the first thing to try for one of the load errors under Troubleshooting. On Windows, certutil -hashfile <file> SHA256 prints the same hash.

sha256sum models/diffusion_models/qwen_image_2.1_int8_convrot.safetensors
# cb74113cb03faecd79611b01fd7fd642f0aa60d6f0b95086abee214d75eaa57d
sha256sum models/text_encoders/qwen3vl_8b_int8_convrot.safetensors
# 8bfd0f6e12abf2d2d697ecc888e5e90b0d6741d6708f05799f53afa560452e8f
sha256sum models/vae/qwen_image_2.1_vae_bf16.safetensors
# bb21f7473051e1ac368515dd3f2e15cd44d7a11748ee8823e1ddca3e4876b7c9

3. Start ComfyUI and read the log, on this card

In the same shell, python main.py; on the portable, run_nvidia_gpu.bat. On this card, the first screen of the log should show:

• Device: cuda:0 NVIDIA GeForce RTX 4060 Ti : cudaMallocAsync. The device name does not say 16GB, so read the next line.
• Total VRAM 16380 MB on Windows, as in #15199's log and #16441's report. The one Linux log shows 15946 MB. Anything near 8 GB means you have the 8 GB card.
• pytorch version: ending in +cu130, and no line that starts "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations."
• Found comfy_kitchen backend cuda: {'available': True, 'disabled': False, ...}. The cu130 gate in comfy/quant_ops.py calls registry.disable("cuda"), which in comfy-kitchen's registry leaves the backend registered and sets 'disabled': True. Checking available alone proves nothing.
• DynamicVRAM support detected and enabled and ComfyUI version: 0.37.0 or higher.

On the first generation, Using mixed precision operations is followed by a Native ops: … , emulated ops: … line. On this card int8_tensorwise must be on the native side, and nvfp4 and mxfp8 on the emulated side (the list order varies). Why is under "What Ada changes" below.

While a generation is running, check the link too. At idle it drops to its slowest speed to save power: the dumps above show 2.5GT/s (downgraded) at idle.

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 time on this page that involves the link doubles.

4. Open the official template

The workflow ships with ComfyUI. Open the template browser and pick Qwen Image 2.1: Text to Image. Its file is image_qwen_image_2_1_t2i.json, templates package 0.11.66, unchanged since commit 371a7b7171 on 2026-09-20. Read from that JSON, its loaders are UNETLoader qwen_image_2.1_int8_convrot.safetensors, CLIPLoader qwen3vl_8b_int8_convrot.safetensors with type qwen_image, and VAELoader qwen_image_2.1_vae_bf16.safetensors. It samples with KSampler at 25 steps, cfg 1, euler, simple, denoise 1, at 1024×1024 from a ResolutionSelector set to 1:1 and 1 megapixel, and saves an 8-bit sRGB PNG. The int8 files are ComfyUI's own default, not a low-VRAM workaround. The package also ships Qwen Image 2.1: Image Edit and a background-removal template.

The docs.comfy.org tutorial used to list only the bf16 encoder. Since a docs commit at 07:39Z on 2026-09-22 (source) it agrees with the template: "All of them use the int8 versions of the diffusion model and the text encoder by default." It lists the bf16 files as the higher-memory alternative. On this card the bf16 encoder alone (16.330 GiB) is bigger than the card.

Running

Queue the template unchanged once and watch the log. The byte counts decide the order of events:

1. The text encoder (8.709 GiB) loads and encodes the prompt. The node encodes the negative prompt too, even though cfg 1 never uses it.
2. The diffusion model (6.758 GiB) loads. The two do not fit together (next section), so the encoder gives up its place. v0.37.0 runs its dynamic VRAM loader by default on any NVIDIA card with PyTorch 2.8 or newer (main.py). What does not fit stays off the card and is brought in when needed, instead of the load failing. Its log line, Model QwenImage21 prepared for dynamic VRAM loading. … MB Staged, gives the weights' size in MiB (6920 for this file), not a peak.
3. 25 steps at 1024×1024, then the VAE decodes and the PNG lands in output/.

Re-queue with only the seed changed and step 1 does not repeat, because ComfyUI caches the encoded prompt. Nothing crosses the link then. Change the prompt and the encoder has to come back onto the card, and whatever it displaced has to come back after it.

What a prompt change moves across eight lanes

This is arithmetic, not a measurement. No run found times a prompt change on this card separately; the one user report, under Results, gives one approximate figure per task.

The link's rate. The Linux kernel converts a PCIe link speed to usable bits with the line code folded in. At 16 GT/s (PCIe 4.0) that is 16000*128/130 Mb/s per lane, and at 8 GT/s (PCIe 3.0) 8000*128/130 (drivers/pci/pci.h, v6.12). Eight lanes give:

Those are raw rates before packet overhead. A real copy runs slower, so every time below is a lower bound.

What has to cross. The encoder and the diffusion model together are 16,607,581,424 B = 15.467 GiB. With ComfyUI running and no model loaded, the snapshots above show 14.878 GiB (Windows) and 14.593 GiB (Linux) free. The loader keeps a live headroom on top of that: 512 MiB on Windows and 256 MiB on Linux (comfy-aimdo 0.5.5, under Results). That leaves 15,438,184,448 B = 14.378 GiB and 15,401,156,608 B = 14.343 GiB for weights and working memory. So whatever the loader decides to keep, a prompt change has to bring back at least the difference, 1,169,396,976 B = 1.089 GiB (Windows) or 1,206,424,816 B = 1.124 GiB (Linux). That floor ignores the VAE and all activations. At the other end, if the loader re-reads both models in full, that is 15.467 GiB.

This is the default (dynamic) loader's case. The pool above subtracts its headroom, and it drops evicted pages without copying them out, so each byte crosses once, card-bound.

What that means. On text-to-image, the link's share of a prompt change runs from 0.074 s to 1.054 s on a PCIe 4.0 board, and from 0.148 s to 2.108 s on a PCIe 3.0 board, at the raw rate. Compared on the same board with a sixteen-lane card, the lane count alone adds at most 0.527 s per prompt change on PCIe 4.0 and 1.054 s on PCIe 3.0, even if both models are re-read in full. The board's generation is a separate cost. This card on a PCIe 3.0 board against a sixteen-lane card on a PCIe 4.0 board is 1.581 s, lanes and generation together. On the legacy loader (--disable-dynamic-vram) every unload is also a copy back to system RAM, so the full re-read case is a round trip: 2.108 s on PCIe 4.0 x8 and 4.217 s on PCIe 3.0 x8, against 1.054 s and 2.108 s for a sixteen-lane card on the same board. A seed change costs nothing. The sampling steps themselves involve no link traffic as long as the diffusion model stays on the card. At 1024×1024 its weights and the VAE's take 7.388 GiB of the pool (Results). The narrower pipe can be the other end of the copy. v0.37.0 classifies each model's drive, and on one it treats as fast it uses what cli_args.py calls "disk-backed dynamic loading and offload over unpinned RAM": offloaded weights are read back from the model file. That is the OS file cache if it still holds them, otherwise the drive, which is then likely the limit rather than the link. On other drives the offload uses pinned RAM instead. The log line Model storage policy: fast_disk=… says which you got. Neither case has been timed on this card.

Why the one measured rig does not settle it. The operator's RTX 5060 Ti session spent about 6 s of each cold template run outside sampling. That covers loading all three models from scratch, encoding and decoding, not a prompt change. Its session.json also records the link only at idle: pcie.link.width.current 8, pcie.link.gen.max 5, pcie.link.gen.current 1. So it does not say at which speed its loads ran, and that number cannot be scaled to this card.

If you want no traffic on a prompt change. The w4a8 encoder from the same repo and revision (text_encoders/qwen3vl_8b_w4a8.safetensors, 5.879 GiB) brings the three files to 14,244,398,116 B = 13.266 GiB. The weights fit under the usable pool above with 1.112 GiB (Windows) or 1.077 GiB (Linux) to spare. Whether that spare covers the job is something this arithmetic cannot settle:

• On the default loader, nothing sizes the real activations or the VAE decode in advance, and the loader pages whatever does not fit. For scale, ComfyUI's own decode reserve at 1024×1024 is 1.758 GiB, more than that spare.
• On the legacy loader (which has no comfy-aimdo headroom, so compare against the plain free snapshots) its sampling request with all three resident is 15,694,620,667 B = 14.617 GiB on Linux. That is over the free memory by 25,028,603 B on Linux and 34,138,107 B on Windows (where its reserve is larger), a close call on other people's snapshots. On the first sampling load after an encode, load_models_gpu's 1.1× weight factor puts it over by 750,706,909 B on Linux and 759,816,413 B on Windows. Expect it to unload something.

So the swap can shrink what a prompt change moves, possibly to nothing, but that is not established. It is Comfy-Org's own file, and only the CLIPLoader file name changes. It is not the template's default, and its effect on output quality is not evaluated here. By the table above it cannot save more than the full re-read case: 1.054 s per prompt change on a PCIe 4.0 board on the default loader, 2.108 s on the legacy loader. That is a small reason to change files.

Native 2K

The template note says "For native 2K, set 1:1 and 4 megapixels". The sampling schedule does not follow the resolution. ComfyUI fixes Qwen-Image-2.1's shift at 0.69, the value its own comment gives for 1024×1024, at every size (supported_models.py). The vendor's scheduler_config.json turns on dynamic shifting instead, which at 2048×2048 gives 1.313. Issue #16447 (open) reports the mismatch. A ComfyUI maintainer replied: "This is kind of on purpose, the higher the shift the more you see a grid pattern". A second user answered the same day that the fixed shift makes images far noisier than they should be.

On memory, the two loaders part ways at 2K:

• On the legacy loader (--disable-dynamic-vram), two estimates grow. Activations quadruple to 3.840 GiB, and the VAE decode reserve for this VAE reaches 7.031 GiB. Its decode request with the diffusion model resident, 14.809 GiB on Linux and 15.102 GiB on Windows, is over the free memory in both snapshots (14.593 and 14.878 GiB), by 0.216 GiB on Linux and 0.224 GiB on Windows, so that loader unloads part of the diffusion model for the decode (Results).
• On the default dynamic loader neither estimate decides anything. The VAE is a dynamic model too: the operator's published log stages it as Model WanVAE prepared for dynamic VRAM loading. 644MB Staged. When the decode calls load_models_gpu, free_memory(..., for_dynamic=True) does not unload one dynamic model to make room for another (model_management.py), and the reserve only sizes the decode batch (comfy/sd.py). Whether any of the diffusion model leaves the card at 2K therefore depends on the decode's real working memory, which nobody has measured on this card. The arithmetic cannot say; the loader pages what does not fit.

What that can cost on the link differs by loader too, because the two unload differently (model_patcher.py):

• The default loader drops the pages it evicts without copying them anywhere (ModelPatcherDynamic.partially_unload), so only the return crosses. For the whole 6.758 GiB file that is an upper bound of 0.461 s per image on PCIe 4.0 x8 and 0.921 s on PCIe 3.0 x8.
• The legacy loader copies what it unloads back to system RAM first (partially_unload moves each module with .to()), so the weights cross twice: an upper bound of 0.921 s per image on PCIe 4.0 x8 and 1.843 s on PCIe 3.0 x8.

All at the raw rate. On an actual out-of-memory the decode retries in tiles. On a different 16 GB card, the operator's RTX 5060 Ti, 2048×2048 completed on these files under the default loader with a monitor attached, with no out-of-memory and no tiled-decode line in the log. No run on this card that states a 2K resolution was found.

Transparent output

The vendor README's recommended prompt form is "This is an RGBA image with transparency. A cute cartoon dragon sticker. The image has alpha channel and the background is transparent." Replace the middle sentence with your subject. The template saves PNG, which keeps the alpha. Anything that saves JPEG throws it away.

cfg and steps

The template note is explicit: "cfg: keep 1 for the Qwen Image 2.1 official path. Raise it only if you use a negative prompt." The vendor's diffusers example runs 40 steps with no guidance setting; the template starts at 25. On the repack's discussion #11, one user reports faint banding on skin, fabric and fur at the template's 25 steps at 1024×1024. It appeared with both the int8 and the bf16 files, and they write that it "disappeared completely at 40". A reply at 18:01Z posts five images and states no settings. At 22:11Z the original poster wrote that after reproducing that reply's workflow and toning down the prompt, "I see no streaks", and on 2026-09-23 at 01:15Z a third user advised 40 steps. So the thread reports two remedies, 40 steps or that workflow with a milder prompt. It is one thread, and no Comfy-Org member had replied when this page read it on 2026-09-23. A step-distilled option for 2.1 appeared on 2026-09-22: Viggle/Qwen-Image-2.1-viggle-turbo, a third-party 4-step distillation by Viggle, shipped as a rank-64 LoRA and as a full bf16 transformer and labelled a v0.1 preview. Its card says the release "still falls short of the base model": text-to-image at 4 steps is usable, complicated edits are clearly worse. The card documents diffusers only, with its own scheduler setting, and names no ComfyUI workflow; nothing on this page was run with it.

Editing: where the link is inside the loop

Load Qwen Image 2.1: Image Edit (image_qwen_image_2_1_image_edit.json). It uses the same three files, plus TextEncodeQwenImage21 with the VAE connected and resolution set to 0, and a QwenImage21Cache node at device auto, dtype default. The template's own note says "This template starts at 0: no resize beyond a multiple of 32." The cache holds the text-and-reference prefix's attention keys and values, which do not change between steps, so they are computed once per run instead of 25 times.

The code sizes that cache as 2 × 32 layers × prefix tokens × 4096 × 2 bytes (comfy/ldm/qwen_image21/model.py), which is 524,288 B per token. The template's two reference images are 896×1152. At the resolution 1056 this page recommends below, the node resizes each to 928×1184, which gives 2 × 58 × 74 = 8,584 tokens: 4,500,488,192 B = 4.191 GiB, or 2,250,244,096 B = 2.096 GiB with dtype int8, before the prompt's own tokens.

Where the cache lives decides whether the link is in the loop. When the cache sits in system RAM, each cached step copies every block's keys and values to the card. The copy is queued on a side stream ahead of the compute it overlaps (comfy/ldm/wan/model_animate2.py, PoseBranchCache.prefetch), and int8 entries travel as int8. So the whole cache crosses eight lanes to the card once per cached step, 24 times per run. It also crosses once the other way: the first step computes it on the card and PoseBranchCache.put copies it out to RAM.

Add the one fill copy to RAM on the first step: 0.286 s (dtype default) or 0.143 s (int8) on PCIe 4.0 x8, and 0.571 s or 0.286 s on PCIe 3.0 x8. These are raw-rate lower bounds, and the per-step copies only cost time where a block's copy takes longer than that block's compute. How long this card's compute takes per block is not measured, so whether the copies hide is open. The node's tooltip describes the intent: "auto uses spare VRAM, then RAM. cpu (RAM) is prefetched behind compute and costs little speed."

Keeping it on the card. At v0.37.0 the auto setting puts the cache on the GPU only if four times its size is free at the moment of the check, then tries system RAM under the same rule, and otherwise recomputes the prefix on every step. With the diffusion model's 6.758 GiB on the card, the arithmetic above leaves at most 7.620 GiB (Windows) or 7.585 GiB (Linux) free. That is under the 8.383 GiB that four times the int8 cache needs, so on this arithmetic auto does not choose the GPU here, even at int8. device gpu skips that test and asks for only twice the size free. With dtype int8 that is 4.191 GiB, which fits on paper, and then nothing crosses the link per step. With dtype default twice the size is 8.383 GiB, which does not fit, so the node recomputes instead, which is the slowest case. So on this card, for the template edit, set device gpu and dtype int8 together. The tooltip for the second says "int8 halves the cache at about bf16 accuracy". Two cautions. The free-memory reading the check uses is not necessarily the arithmetic above. The author of PR #16429 lists this among the tag check's 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". And this setting has not been run on this card. More or larger references add 262,144 B per token at int8. A 1-megapixel reference is 4,096 tokens, 1.000 GiB at int8, so twice that must be free for each one you add. If the GPU check then fails, device cpu puts the cache back on the link and auto may recompute.

One edit caveat is an open bug, not a setting. Set resolution to 1056 before you edit. Issue #16435 reports broken edits with the VAE connected at particular reference grids, and its two reports disagree on which grids:

• The original reporter (Apple MPS and CPU) finds broadband speckle when the grid comes out at exactly 1024, with 512, 992 and 1056 clean. The reporter's follow-up adds that the template's resolution 0 reaches that grid with any 1024×1024 first reference.
• A second commenter (RTX 5070 Ti, v0.37.0, cu130, the bf16 diffusion model) finds a 1024×1024 reference clean, but a 1536×1024 one broken at both resolution 0 and 1248, with the edit instruction ignored. 512, 1024, 1056 and 2048 are clean on that setup.

512 and 1056 are clean in both reports. 512 shrinks each reference to a quarter-megapixel budget, so use 1056, which is also the value the cache figures above are for. The output then comes out about 1056×1056 pixels in the first reference's aspect ratio. The issue was still open on 2026-09-22 (read at 15:44Z), and its last comment is a maintainer asking for images. PR #16444, a community fix that chunked the attention, was closed without merging on 2026-09-22 by kijai; no fix is linked to #16435 now.

What Ada changes, and what it does not

Read from ComfyUI v0.37.0 and comfy-kitchen 0.2.35, for compute capability 8.9:

• The int8 files run on a native kernel here, with cu130. supports_int8_compute() in comfy/model_management.py is true on any CUDA card. Below it, comfy-kitchen's CUDA int8_linear is registered for compute capability 7.5 and up (backend). Its default build targets are 75-real;80-real;89;120f on Windows and include 89 on Linux (setup.py), which covers this card natively. All 192 quantised layers in the diffusion model and all 254 in the encoder declare {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} (read from the files' headers over HTTP range requests).
• Below cu130 they still run, slower. The gate switches the CUDA backend off and comfy-kitchen falls through to its eager int8_linear. That path rotates and quantises activations in plain PyTorch and multiplies with torch.int8_mm where it exists, otherwise torch._int_mm. How much slower that is on Ada is not measured. On a different card, the operator's RTX 5060 Ti, the template's image took 21.4 s cold on a cu130 build against 69.4 s on a cu128 build that printed the warning. Those two installs also differed in core and Python, and it was one rig, unreplicated. It shows the gate is worth checking, not what it costs here.
• Whether int8 beats bf16 on this card is also unmeasured. On that same Blackwell card with cu130, the int8 file was faster per step than bf16. That result belongs to that card and that build. Nobody has compared the two files on Ada.
• FP8 hardware sits idle. supports_fp8_compute() is true at 8.9, so the Native ops line lists the float8 formats as native. But Comfy-Org ships no fp8 diffusion model for 2.1. Text encoders are built with full_precision_mm=True in comfy/sd1_clip.py, so a quantised encoder is expanded for every matmul on any card. Its format is a memory choice, not a speed choice. Comfy-Org's qwen3vl_8b_fp8_scaled (10,588,637,512 B, in Comfy-Org/Qwen3-VL) would load: it carries the DeepStack tensors comfy/sd.py keys the 8B encoder on. But it is 1.153 GiB bigger than the int8 file, which on this card means more to move per prompt change for nothing. No report of it, or of the nvfp4 8B file, being used with 2.1 turned up in the tracker threads or the discussion tabs listed under Results.
• NVFP4 and MXFP8 are emulated. Both need compute capability 10 or higher, so community NVFP4 diffusion models are expanded to bf16 on this card. The community INT4 ConvRot (convrot_w4a4) build is a different case. ComfyUI treats that format as native on any CUDA card, and comfy-kitchen's W4A4 kernel takes its native 4-bit path only on compute capability 8.x, which includes this card. No run of it on a named Ada card was found.

For the Ada story at 24 GB, see this model's RTX 4090 page.

Results

• Speed: not measured by this site on this card. One user report names it. On the vendor's discussion #35, opened 2026-09-22T16:01Z, TheTechnoX (not a Qwen organisation member) reports the same three files in ComfyUI on an RTX 4060 Ti 16GB: the int8 ConvRot diffusion model, the int8 Qwen3-VL-8B encoder and the bf16 VAE. The post says: "image generation took around 20 seconds for me and the more complicated editing generations took around 1 minute." Its summary list gives the same figures as "~20 seconds" and "~60 seconds". The post gives them as approximations and does not say how they were timed. Its text states no settings, but the five output images attached to it embed their ComfyUI graphs. These were read from the PNGs' metadata over HTTP range requests, for example the first image. All five load the template's three files and sample at 25 steps, cfg 1, euler, simple, with the resolution selector at 1:1 and 1 megapixel. The outputs are 1024×1024, except one edit at 1024×576. The two text-to-image graphs have the pinned template's node ids, node types and default values. The three edit graphs keep resolution 0 but set QwenImage21Cache to device gpu, dtype default, where the pinned edit template ships device auto. So the ~60 s edit figure comes from runs with the cache forced onto the GPU, the setting discussed under Editing. With the poster's own reference images, the graphs do not record whether that cache fitted on the card. The graphs also record frontend version 1.52.7, the frontend version that v0.37.0's requirements.txt pins (v0.37.1's pins the same), so it does not identify the core build. Still unknown: the ComfyUI core version, the PyTorch build, any log, whether loading is included, how many runs the figures cover, and which image the ~20 s belongs to. It also says there was no CPU or disk offloading, without saying how that was established. By this page's arithmetic, the three files cannot all be on the card at once (below). Treat it as one person's order of magnitude for this card, not as a timed benchmark: for text-to-image at the template's defaults, and for editing with the cache forced to the GPU. Apart from that post, nothing turned up on 2026-09-22 in the following. All 21 ComfyUI tracker threads that mention Qwen Image 2.1, with comments: a tracker search for "4060 Ti" since release finds only #16441, which is about the prompt enhancer. All 54 discussions on Qwen/Qwen-Image-2.1, Comfy-Org/Qwen-Image-2.1 and Comfy-Org/Qwen3-VL, re-read at 17:05Z, where #35 is the only one that mentions a 4060. The 194 comments of the Hacker News launch thread, 99 Civitai listings for "Qwen Image 2.1", and a web search. The one web result that gives a 4060 Ti time per step is a 2025 post about the 20B predecessor with fp8 files, not this model. Reddit refused this session. The catalogue's only other card on this chip is the 8 GB version, and nothing turned up for it either. A run of the template on this card, with the log's Prompt executed in line and the link reading from step 3, belongs at /contribute.
• VRAM usage: derived, not measured by this site, and loader by loader below. The same #35 post also gives memory for this card: "vram peaked at around 15gb and usually stayed around 13-14gb during generation." It does not say how it read VRAM (Task Manager, nvidia-smi or ComfyUI), whether GB means GiB, or which workload the peak belongs to. If it is a whole-card reading, then on the default loader it shows how full the loader chose to make the card, not what the job needs, so it is not a floor. It is compatible with the 15.996 GiB the card reports. Neither Qwen nor Comfy-Org publishes a figure: the vendor's HF card and GitHub README give enable_model_cpu_offload() as their only memory advice.

The loader you get: dynamic VRAM. On this path ComfyUI's memory estimates do not govern. memory_required() in model_patcher.py is ignored when every model is dynamic, partially_load() never reads the budget it is handed, and free_memory() does not unload one dynamic model to make room for another, because that works on demand. What governs is comfy-aimdo 0.5.5's budget (plat.h). The live part keeps VRAM free against what is actually free, so the desktop and other programs count. On Linux it is 256 MiB (VRAM_HEADROOM). On Windows the DLL polls shmem-detect.c instead, which keeps 512 MiB under the WDDM video-memory budget and 512 MiB of NVML free VRAM, and takes the stricter of the two. --reserve-vram only raises a second, capacity-based term. --vram-headroom X adds X GiB on top of whichever term wins.

Every row is weights only. On this loader the real activations and decode memory come out of the spare, and nothing sizes them in advance.

The last row is why the bf16 diffusion model is a poor fit for this card, before any question of quality or speed. With under half a GiB to spare it has little margin even at 1024×1024. At 2K, ComfyUI's own activation estimate is 3.840 GiB. If the real figure is anywhere near that, part of a 13.253 GiB model would have to leave the card during sampling, which could put the link inside every step, not once per prompt. The real figure on this loader is unmeasured, and nobody has run bf16 on this card.

The legacy loader (--disable-dynamic-vram), for comparison. This path is estimate-based, and its activation formula carries its own comment, "this needs to be tweaked" (model_base.py). Each stage asks for the model's weights plus the larger of a fixed minimum (0.8 GiB + the OS reserve) and its own estimate + the OS reserve. The OS reserve is 400 MiB on Linux and 700 MiB on this card on Windows, where EXTRA_RESERVED_VRAM adds 100 MiB above 15 GiB of total VRAM. The sampling estimate is always computed at twice the batch (sampler_helpers.py), even at cfg 1.

On Windows each row is 0.293 GiB higher (encode 10.192 GiB). The decode reserve is 900 × h × w × 256 × 2 bytes over the latent grid in comfy/sd.py. These are planning figures, not physical peaks, and they understate the request slightly. When load_models_gpu() frees memory for a model it asks for 1.1 × that model's weights plus the extra memory. With that factor, the Linux encode request is 11,564,302,055 B = 10.770 GiB and the 1024² sampling request is 9,432,683,921 B = 8.785 GiB. That request is what it unloads weights to reach, not the test of whether a model fits. Whether the model then goes on the card whole or in part is judged against its weights plus the batch-1 estimate and the reserve, never less than the fixed minimum. For the encode and decode rows that is the row's own figure; for sampling it is smaller: 8,535,206,923 B = 7.949 GiB at 1024² (the batch-1 estimate plus the reserve is below the fixed minimum) and 9,737,797,766 B = 9.069 GiB at 2048², on Linux. Every conclusion below only gets stronger with the factor. On this card, the legacy encode stage plus the resident diffusion model (16.658 GiB) is over the card, as it is by weights alone on the default loader. And the 2K decode with the diffusion model resident (14.809 GiB) is over the free memory in both snapshots (by 0.216 GiB on Linux, 0.224 GiB on Windows; this loader keeps no comfy-aimdo headroom, so the plain free figures are the comparison), which is why the legacy loader unloads part of the model for a 2K decode. On the default loader that estimate does not govern (Native 2K, under Running).

• Quality notes: the VAE leaves a visible grid at high resolution. On the vendor's discussion #12 a user writes "It's more noticeable when you generate a high-resolution image that has people with light skin tones and zoom in on their faces." and attributes it to the VAE, reproducible with a plain encode-and-decode. The mitigations named there are third-party post-processing or re-encoding through another VAE. A later comment in the thread reports a 16-pixel stripe pattern on a different model's fine-tune that turned out to come from its diffusion model, not the VAE, so treat the cause as the thread's reading, not settled. No one from Qwen has replied (2026-09-22). The artifact that thread describes is not a settings problem and not specific to this card.

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

Troubleshooting

TextEncodeQwenImage21 or QwenImage21Cache is missing when the template loads

Your ComfyUI core is older than v0.37.0. Take the v0.37.0 portable. On a git install, update to a tag rather than with a bare git pull, which lands on master (#16443) and fails on the detached checkout step 1 creates: git fetch --tags && git checkout v0.37.0 && pip install -r requirements.txt, then restart.

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

Your PyTorch is older than CUDA 13, and the int8 layers are running on comfy-kitchen's eager path (What Ada changes). The fix is the torch line in step 1, or the v0.37.0 portable, which ships the cu130 build. How much it costs on this card is unmeasured. One more report points the same way on a different card: on an RTX 5060 Ti with a cu128 build, issue #16470 found the int8 file slower than a Q8_0 GGUF at 1760×2368. That run used sage attention and two --fast options, from a drive ComfyUI did not classify as fast. kijai, a ComfyUI collaborator and the author of the core support, replied there on 2026-09-22: "You need pytorch with cu130 for int8 models to work properly."

A prompt change is slow

Consequence of the turn-taking under Running, not a fault. In order:

1. Check the link during a generation with the nvidia-smi line in step 3. Generation 3 halves the link rate and doubles every link time on this page. The card's eight lanes are normal. If the card is in a chipset slot, a CPU-attached slot may be faster.
2. Check Model storage policy: fast_disk= in the log. With True, offloaded weights are re-read from the model file, so the drive can be the limit, not the link.
3. Iterate on the seed with a fixed prompt, which reuses the cached conditioning and moves nothing.
4. The w4a8 encoder swap under Running may keep all three models resident, though that is not established. By the arithmetic, its saving is bounded by the full re-read case: 1.054 s per prompt change on a PCIe 4.0 board on the default loader, 2.108 s on the legacy loader.

Do not reach for --enable-dynamic-vram: the dynamic loader is already the default on NVIDIA at this version.

Edits run many times slower than text-to-image

Either the cache fell back to recomputing the prefix on every step, or it is in system RAM and its per-step copies are not hiding behind compute. That is the table under Editing, and it doubles on a PCIe 3.0 board. On v0.37.0, set QwenImage21Cache to device gpu and dtype int8 for the template's references. With more or bigger references, check the twice-the-size rule under Editing first. device off makes the recompute permanent. The node's tooltip calls that the one way to rule the cache out.

Edit output is speckled or ignores the instruction, text-to-image is clean

Issue #16435, under Editing. Set resolution to 1056. Disconnecting the VAE from TextEncodeQwenImage21 also removed the speckle in the first report, at the price of much weaker adherence to the reference.

On master: Fatal Python error: Aborted at 0/25 when editing

Issue #16443, open, as read on 2026-09-22 at 14:40Z. The reporter corrected the original description to image editing: "I have not confirmed this crash with pure text-to-image generation." Two users now report it, each with an RTX 5060 Ti 16 GB in a two-GPU machine. On 2026-09-22 both said the crash is intermittent and seems tied to larger input images. One saw it only once the resolution went above 1 megapixel. The other saw it with two inputs of about 1500×1000 and not, so far, with smaller ones. The reporter also started ComfyUI with --cuda-device 0 "to force a single GPU, but the same crash still occurs", so forcing one card did not avoid it. Neither report gives a ComfyUI commit. The stack ends in the prefix cache's take at qwen_image21/model.py line 353. That line is cache.take on master, where it runs on every step. At v0.37.0 the call runs only on cached steps. PR #16450 (open, unmerged, no maintainer review) blames staging buffers allocated while the cache spills to host RAM. If you hit this on master, go back to v0.37.0 (git checkout v0.37.0, or update_comfyui_stable.bat on the portable). By that PR's reading, device gpu under Editing would also keep the cache out of host RAM. That is an inference from an unreviewed PR, not a tested workaround.

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

PR #16481, opened on 2026-09-22 by sqz269, reports a different hard crash. On Windows 11 with an RTX 5090, torch 2.13.0+cu130, the template's int8 diffusion model and encoder, dynamic VRAM 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 v0.37.0 tag this page installs, so going back to 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; its one review was an automated bot's, and no maintainer had reviewed it.

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

Issue #16472 reported this for the edit template's qwen3vl_8b_int8_convrot.safetensors on an AMD integrated GPU. PR #16474 attributes it to an empty per-layer quantisation marker in the file. That does not describe Comfy-Org's published file. Read over HTTP range requests at both revisions' shared LFS object, all 254 of its comfy_quant markers are 72 bytes of valid JSON, the embedding table's included. So check the file's sha256 against step 2 first: a damaged or partial download is the likelier cause. kijai replied on the issue on 2026-09-22: "This is most likely a corrupt/incomplete model file." On the PR, kijai asked which model file reproduces the error. The reporter then re-downloaded the file and wrote that it now loads correctly, and kijai closed the issue as completed that evening (23:06Z).

Unusable images, or Given normalized_shape=[4096] … got input of size [1,338,5120]

The wrong file is in the CLIPLoader. The repack's discussion #2 shows that shape error, closed by its reporter as a wrong-encoder mistake, and loading a prompt enhancer in that slot gives unusable images instead (discussion #4). Load a qwen3vl_8b_* file with type qwen_image.

Stall or out-of-memory during the VAE decode at 2K

On the legacy loader ComfyUI asks for 7.031 GiB for decoding at 2048×2048. On the default loader that figure only sizes the decode batch, and the loader pages weights as the real allocations need room (Native 2K, under Running). On an actual out-of-memory it logs a warning that it ran out of memory during regular VAE decoding, retries with tiled decoding and carries on, so the usual symptom is a slow decode rather than a crash. For more margin for other software, add --vram-headroom 1, which keeps an extra GiB free on top of the default loader's budget. Closing whatever else holds VRAM (a browser with hardware acceleration counts) is worth more than any flag. Or render at 2 megapixels first.

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

Not the lead path here, since the int8 file already fits. But several publishers have GGUFs, and which loader reads them depends on the file:

• city96's ComfyUI-GGUF has had no commit since 2026-01-12. It passes a file whose general.architecture is qwen_image to ComfyUI core. A file with no metadata goes to a key-matching fallback that has no 2.1 entry.
• Abiray/Qwen-Image-2.1-GGUF's Q8_0 declares qwen_image.
• leejet/Qwen-Image-2.1-GGUF's and unsloth/Qwen-Image-2.1-GGUF's Q8_0 carry no metadata at all. Their tensor names are the same once unsloth's model.diffusion_model. prefix is stripped, and city96's fallback rejects them with this error. The same test on a metadata-free Flux GGUF matches Flux, so the test itself works.
• leejet's fork added qwen_image21 to its architecture list on 2026-09-21. That came on top of an earlier commit (2026-09-20) that added 2.1 detection to its converter's architecture checks.

The one end-to-end report found is #16470: a Q8_0 file named like unsloth's, run in leejet's fork on v0.37.0, on an RTX 5060 Ti. Nobody has published a GGUF run on this card. If you need one, take a file that declares its architecture, or leejet's fork, and report back via /contribute.

Those are the reports found for this model on 2026-09-22; the tracker moves by the hour in launch week. Report problems, or better a timed run on this card with its link reading, via the submission form.