Qwen-Image-2.1 on RTX 5060 Ti: the int8 ComfyUI template, 2K output and editing in 16 GB

What You'll Build

A ComfyUI graph on one RTX 5060 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.

This page was written the day after release, from public sources only. Nothing on it was run on this card. Every VRAM figure below is arithmetic: byte counts from the Hugging Face tree API plus rules read from ComfyUI's source at tag v0.37.0, added up unrounded and rounded once. Two different loaders live in that source, and each figure says which one it belongs to. The arithmetic settles one thing without a measurement. The three files together are bigger than the card, so the text encoder and the diffusion model take turns, and the encoder is what gives way every time the prompt changes.

Hardware data: RTX 5060 Ti (16GB VRAM, compute capability 12.0) · the three template files total 16.096 GiB against a 16 GiB card, so encoder and diffusion model take turns · no measured peak yet · See benchmark data

⚠️ 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", grants its rights in §2.a "FOR NON-COMMERCIAL PURPOSES ONLY", and in §2.b says "you shall request a license from us at model-business@notice.qwencloud.com" for anything else. There is no territory restriction: the grant in §2.a is worldwide, §4.a is a reminder about export controls, and §8 sets Chinese law and the courts of Hangzhou for disputes. §4.b reaches past the weights to what you build on their outputs: "If you use the Materials or any outputs or results therefrom to create, train, fine-tune, or improve an AI model that is distributed or made available, you shall prominently display “Built with Qwen” or “Improved using Qwen” in the related product documentation." One user reports on discussion #7 that the commercial-licence address bounced. The Comfy-Org repack you install below points back at the same licence. This is a reader's summary of the text, 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: on the repack's discussion #4 a user who put one in the text-encoder slot reports garbled images. This page does not install them.

If you ran the 20B predecessor on this card, see Qwen-Image on RTX 5060 Ti. Same family, different generation: that one needed a GGUF to fit at all, this one runs from Comfy-Org's own int8 files.

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, still the repo's head on 2026-09-21):

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: 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 loaders, a derivation done on this model's RTX 3060 page. This page's own table agrees: the largest legacy stage at 1024×1024 is 9.899 GiB (Results).

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 that commit's parent and from tag v0.36.0, and present from 6bfaacc67c on. The first tag that contains it is v0.37.0 (commit 73c9bad4, 8 commits later), and the template index lists minComfyUIVersion 0.37.0 for all three Qwen-Image-2.1 templates. The v0.37.0 release, with its Windows portable builds, was published on 2026-09-21T07:35Z, so releases/latest now points at it. Until then, users on the repack's discussion #1 reported the portable and Desktop channels still on 0.36. The template's own note says why the Desktop app can lag: "Desktop/Cloud updates follow stable releases, so some nightly-supported models may not be available yet." Which ComfyUI core the current Desktop build installs could not be determined from Comfy-Desktop's release notes.

Two related changes landed after the tag, two and three commits past v0.37.0: PR #16429, which changes where the edit cache is kept, and PR #16430, which compiles the transformer blocks and, per its author, helps most when offloading is the bottleneck. Neither is needed to run the templates. v0.37.0 is the safer default. master buys those two changes, and it also carries the code path in the open crash report #16443 (Troubleshooting). If you will edit, read the edit section under Running before choosing.

Windows, the short route. Download ComfyUI_windows_portable_nvidia.7z from the v0.37.0 release and extract it. The ComfyUI README says that build comes with Python 3.13 and PyTorch for 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 launcher starts ComfyUI. Step 2 gives the command in that form.

Linux, or a git install anywhere. The torch line is the one the README gives for NVIDIA, and the same README says "Using a cu130 or above version of pytorch is required on Nvidia 20 series and above."

git clone https://github.com/Comfy-Org/ComfyUI
cd ComfyUI
git checkout v0.37.0          # the floor and the safer default; `master` (PRs #16429/#16430, see #16443) needs the requirements line re-run
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 (12, 0)

(12, 0) is this card's compute capability per NVIDIA's CUDA GPU list, and it is the number every capability check in ComfyUI reads. The CUDA version matters for a concrete reason in the source: comfy/quant_ops.py at the tag parses torch.version.cuda, and below 13 it switches off comfy-kitchen's CUDA kernels and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." The int8 model still runs without them, on a slower path; Troubleshooting has the details. requirements.txt at the tag pins comfy-kitchen==0.2.35 and comfyui-workflow-templates==0.11.66. master pins a different frontend package (1.53.6 against the tag's 1.52.7), which is why switching to it needs pip install -r requirements.txt again. The wheels of that comfy-kitchen release are built with 120f in their CUDA architecture list (setup.py), which covers this card.

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, which is the layout the repack README asks for, 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. The release workflow installs pip into it, and ComfyUI's own updater calls it this way:

.\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

Optional, and worth it on 17 GB: check the bytes against the LFS hashes in the tree (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

About the encoder. The evidence says it is the stock Qwen3-VL-8B-Instruct, unchanged. On the vendor's discussion #5 a user posting as FIT17 writes "我比较过 tensor 数值 原版 instruct 没有增量训练" (they compared tensor values with the original Instruct: no further training), and a second user, Jianqiao1, reports verifying it tensor by tensor. The bytes agree as far as they were checked for this page. The vendor's own text_encoder folder holds the same 750 tensor names as Qwen/Qwen3-VL-8B-Instruct, and 4 KB slices from the start, middle and end of four tensors (the first and last text layers, the last vision block, the embedding table) are byte-identical between the two repos. That is twelve slices, not a full comparison. Comfy-Org's bf16 file carries the same LFS sha256 (68bdc82b…) in Comfy-Org/Qwen3-VL, where it was uploaded on 2026-06-06, three months before this model existed. The int8 and w4a8 files there were only added on 2026-09-20. Qwen has not said any of this themselves.

The loader picks the encoder class by tensor names, not by file name. comfy/sd.py identifies a Qwen3-VL-8B from its DeepStack merger weights and, when the loader's type is qwen_image, hands it to the 2.1 encoder. The fp8_scaled (10,588,637,512 B) and nvfp4 (6,305,221,764 B) 8B files in Comfy-Org/Qwen3-VL carry those same tensors, so they take the same route by construction. No report of either being used with 2.1 turned up in the fourteen ComfyUI tracker threads that mention Qwen Image 2.1 or in either repo's discussions.

3. Start ComfyUI and read the log

In the same shell, python main.py; on the portable, run_nvidia_gpu.bat. Read the first screen of the log. ComfyUI version: should say 0.37.0 or higher, there should be no cu130 warning, and the line that starts Found comfy_kitchen backend cuda: should read 'available': True, 'disabled': False. 'disabled': True means the CUDA backend is installed and switched off, which is the cu130 gate at work, so checking available alone proves nothing.

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. 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. A ResolutionSelector set to 1:1 and 1 megapixel drives EmptyLatentImage to 1024×1024, and SaveImageAdvanced writes an 8-bit sRGB PNG. The int8 files on this page are ComfyUI's own default, not a low-VRAM workaround. The same package also ships Qwen Image 2.1: Image Edit and a background-removal template.

One drift to know about. The first template commit, at 05:10Z on 2026-09-20 (templates 0.11.65), loaded the bf16 encoder. Commit #1277 at 12:56Z the same day, published as templates 0.11.66, switched it to int8, and v0.37.0 pins 0.11.66. The docs.comfy.org tutorial still lists only qwen3vl_8b_bf16.safetensors under text encoders. If you followed the docs first, you have a 16.330 GiB file the template does not load, bigger than the card. The template is the one to follow.

Running

Queue the template unchanged once and watch the log. On this card 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. They do not both fit (the arithmetic is under Results), so the encoder gives up its place. On any NVIDIA card with PyTorch 2.8 or newer, v0.37.0 uses its dynamic VRAM loader by default (main.py); only --disable-dynamic-vram, --highvram, --gpu-only, --novram or --cpu turn it off (cli_args.py). With the dynamic loader, what does not fit stays in system RAM and is brought in as needed, instead of the load failing. Its log line is Model QwenImage21 prepared for dynamic VRAM loading. … MB Staged, where the number is the size of the model's weights in MiB (close to the file size), 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. Change the prompt and the encoder has to come back, and the diffusion model has to be restaged after it. That round trip is the single behaviour of this card and model worth planning around; Troubleshooting has the options.

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 (base 0.5 at 256 tokens, max 0.9 at 8,192). The vendor's own diffusers pipeline (pipeline_qwenimage21.py) applies that linear formula with no upper clamp. At the README's own 2048×2048 (16,384 tokens) it computes 1.313, and at 1024×1024 it computes 0.69. So at 2K the template samples on a different schedule from the vendor's pipeline. Issue #16447 (open) reports the mismatch. Its reporter, on a 24 GB AMD card, judges the vendor-schedule output better at 4 MP; nobody has confirmed that. The VAE's decode reserve also grows with the pixel count, and at 2048×2048 it becomes the largest single item ComfyUI reserves (Results, item 3).

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 note words the same wrapper slightly differently. 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 own diffusers example runs 40 steps with no guidance setting; the template starts at 25. Nobody has compared the two on this card. There is also no step-distilled ("Lightning"/turbo) LoRA for 2.1 to shorten this. None of the Hugging Face repos whose name contains Qwen-Image-2.1 is one, and neither is any entry in Civitai's LoRA listing for its Qwen 2 base-model category (checked 2026-09-21).

Editing. 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 (each reference is seen by the vision encoder and spliced into the sequence as latents) and resolution set to 0; its note says "This template starts at 0: no resize beyond a multiple of 32." A QwenImage21Cache node sits at device auto, dtype default. That cache is what makes edits fast: the text-and-reference prefix does not change between steps, so its attention keys and values are computed once per run.

Its size is the catch on this card. The code (comfy/ldm/qwen_image21/model.py) sizes it as 2 × 32 layers × prefix tokens × 4096 × 2 bytes. The template's two 896×1152 reference images become 2 × 56 × 72 = 8,064 tokens at the template's resolution 0, so the cache is at least 4,227,858,432 B = 3.938 GiB before the prompt's own tokens. At the resolution 1056 this page recommends below, they resize to 928×1184, so the cache holds 2 × 58 × 74 = 8,584 tokens: 4,500,488,192 B = 4.191 GiB, or 2.096 GiB with dtype int8. At v0.37.0 the auto setting keeps it on the GPU only if four times that is free at the moment of the check, then tries system RAM under the same four-times rule, and otherwise recomputes the prefix on every step. Four times that is 15.750 GiB at resolution 0 and 16.766 GiB at 1056 (8.383 GiB with int8), and every prompt token adds 524,288 B more to the cache. With the diffusion model's 6.758 GiB of weights on the card, no more than 9.242 GiB of it can be free, so the GPU leg fails. The RAM leg is what decides: it needs that much system RAM free, on a machine that is also holding the staged weights. Whether that passes depends on your RAM, not on this card. PR #16429 shows both outcomes on one machine, an RTX 5080 (16 GB, a larger Blackwell card) with 32 GB of RAM, before its change. A two-reference edit (580×1152 and 2048×1024, scaled up 1.3² in area) fell back to full recompute at 4.01 s/it, and ran at 1.02 it/s after the change. The same edit scaled down 0.6² already went to pinned RAM. That PR is on master, not in v0.37.0. On v0.37.0, the safer default, set the cache node's dtype to int8; the node's tooltip says "int8 halves the cache at about bf16 accuracy". Moving to master for #16429 is the other route, with #16443 in mind. On the portable, update\update_comfyui.bat moves you to master and reinstalls its requirements (update.py), and update_comfyui_stable.bat takes you back to the latest tag.

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 the two reports disagree on which grids.

• The original reporter (mpbrewing, Apple MPS and CPU) finds broadband speckle when the grid comes out at exactly 1024: "Composition and identity are correct; only the rendering is degraded." 512, 992 and 1056 are clean. The reporter's follow-up makes the template affected: "the template's 0 is equally affected whenever the first reference image is 1024×1024".
• A second commenter (RTX 5070 Ti, v0.37.0, cu130, the bf16 diffusion model) finds a native 1024×1024 reference clean, but a 1536×1024 one broken at both resolution 0 and 1248, with the edit instruction ignored. resolution 512, 1024, 1056 and 2048 are clean on that setup. The commenter notes that both failing grids are multiples of 2,048 tokens; nobody has confirmed that as the cause. The two setups also differ in encoder precision, reference image, step count, OS, build and attention path, so a difference in backend is one possible explanation, not an established one.

Two values are clean in both reports, 512 and 1056. 512 shrinks each reference to a quarter-megapixel budget, so 1056 is the one to use. It also changes the canvas: the output comes out about 1056×1056 pixels in the first reference's aspect ratio, instead of that reference's own size. The issue was open on 2026-09-21. PR #16444 is a proposed fix by chunking the attention: open, unmerged and currently marked draft, from a first-time contributor who checked it with unit tests only.

If you want no reload at all. Two swaps let the encoder and the diffusion model sit on the card together on paper. Both are unmeasured on this card, and both are yours to judge on quality:

• The w4a8 encoder from the same repo and revision (text_encoders/qwen3vl_8b_w4a8.safetensors, 5.879 GiB): download it and change only the CLIPLoader file name. It is Comfy-Org's own file.
• A community NVFP4 diffusion model, such as BennyDaBall/Qwen-Image-2.1-NVFP4's 4,197,574,664 B file, in place of the int8 one. Its header marks all 192 quantised layers nvfp4 with no full-precision flag, and ComfyUI runs that format natively on compute capability 10 and up. That publisher's PR #16432 reports stock ComfyUI (the master of 2026-09-20) running his files on an RTX 5090, which NVIDIA lists under the same compute capability 12.0 as this card. It is a third-party quantisation of the same research-licensed weights.

Results

• Speed: not given for this card. No published figure names an RTX 5060 Ti. The search covered the ComfyUI tracker, the vendor's and Comfy-Org's Hugging Face discussions, the 176-comment Hacker News launch thread and Civitai's 2.1 listings; Reddit refused this session. Nothing here was timed. For scale only, here are two data points from different workloads on different hardware, neither of them a bound on this card. A Hacker News commenter posting as vunderba writes, of the convrot files, "a 1MP image took around ~5 seconds on an RTX4090" (comment 49776977). It states no step count or runtime, and on a 24 GB card all three files can stay resident, so it never pays the encoder round trip this page is built around. PR #16429's RTX 5080 edit figures under Running come from a larger edit than the template's: from the sizes it states, more than twice the template's 8,064 reference tokens. A measured run on this card is welcome via /contribute.
• VRAM usage: not measured on this card, and neither Qwen nor Comfy-Org publishes a figure. The vendor's HF card and GitHub README give enable_model_cpu_offload() as their memory advice and no number. Comfy's launch post says "At 7B, inference is fast and the weights fit comfortably on consumer cards." with no number. The docs page gives none. A user asking the vendor for hardware specs in issue #4 had no answer from Qwen on 2026-09-21. What follows is derived, loader by loader.

The loader you get: dynamic VRAM. Every NVIDIA reader on PyTorch 2.8 or newer runs ModelPatcherDynamic (Running, step 2), and on that path ComfyUI's memory estimates do not govern:

• memory_required() in model_patcher.py says that when every model is dynamic, the estimate "is ignored and its all done dynamically".
• partially_load() never reads its extra_memory argument.
• free_memory() does not unload one dynamic model to make room for another, because that "works on-demand" (model_management.py).

What does govern is comfy-aimdo's budget (plat.h, comfy-aimdo 0.5.5), which is the larger of two terms. One is a live check against the VRAM actually free, so other software's usage counts, and it differs by platform:

• Linux: keep 256 MiB (VRAM_HEADROOM) free by cuMemGetInfo (control.c).
• Windows: the aimdo DLL takes its budget poll from the Windows-specific source (build workflow). shmem-detect.c runs two separate checks and takes the stricter. One keeps aimdo's usage plus 512 MiB under the operating system's WDDM video-memory budget. The other keeps 512 MiB of NVML free VRAM (96 MiB by cuMemGetInfo if NVML is unavailable).

The other term adds aimdo's own usage to a headroom, 256 MiB by default, and compares the sum with the card's total capacity. --reserve-vram X sets only that second term's headroom; per aimdo's own docstring, raising it above 256 MiB is honoured and lowering it changes nothing. That threshold describes the Linux build; on Windows, where the live floor is 512 MiB, a value up to that changes nothing either. The live check stays either way. --vram-headroom X (default 0) is added on top of whichever term wins. So on this loader the card holds whichever weights are running plus their real activations, and pages the rest in from system RAM. The one fact the arithmetic settles is that 6.758 + 8.709 + 0.629 = 16.096 GiB of template weights cannot all be resident on 16 GiB at once. How much of each model is resident at a given moment, and the true peak, are unmeasured.

The legacy loader (--disable-dynamic-vram), for comparison. This is the estimate-based path. Its numbers are heuristics: the activation formula carries its own comment, "this needs to be tweaked" (model_base.py). They are what load_models_gpu() asks to have free, not a physical requirement. Each stage is the model's weights plus the larger of two amounts: the fixed minimum (0.800 GiB + the OS reserve), or the stage's own estimate + the OS reserve. The OS reserve, EXTRA_RESERVED_VRAM, is 0.391 GiB (400 MiB) on Linux and 700 MiB on a 16 GB card on Windows.

On Windows each row is 0.293 GiB higher (encode 10.192 GiB). Before a full load the legacy loader also asks for 10% headroom on the weights, which the rows leave out. The CUDA context and whatever drives your display come out of the 16 GiB under either loader, and nothing published measures them on this card.

Four consequences, all arithmetic:

1. The int8 encoder and the diffusion model cannot both stay on the card, under either loader. The weights alone are 17,283,091,112 B = 16.096 GiB. On the legacy path, encoding leaves 16 − 9.899 = 6.101 GiB, less than the diffusion model's 6.758, and sampling leaves 7.891 GiB, less than the encoder's 8.709 (8.109 + 8.709 = 16.818 GiB). Issue #16437 reaches the same conclusion from a 16 GB AMD card: "The 7B DiT (6920 MB staged) plus the qwen3vl_8b text encoder (8916 MB staged) cannot co-reside in 16304 MB." That report ran the bundled template at 12 steps on master c194dd0, with --enable-dynamic-vram --fast-disk --disable-pinned-memory --reserve-vram 1.5. Its two figures are the weights' sizes in MiB, which ComfyUI prints when it stages a model, not measured peaks. The output corruption that issue is about is tied to --enable-dynamic-vram on ROCm; its reporter had no NVIDIA card to test, and this page does not carry it over.
2. Everything resident is possible on paper with a swap. The weights come to 14,244,398,116 B = 13.266 GiB with the w4a8 encoder, and 14,223,882,712 B = 13.247 GiB with the NVFP4 diffusion model and the int8 encoder. That leaves 2.734 and 2.753 GiB of the card respectively for activations, the CUDA context and aimdo's floor (256 MiB on Linux, 512 MiB on Windows, so at least 0.25 GiB less there, more if the WDDM-budget check binds first). On the legacy path the sampling stage with everything resident asks for 14.617 and 14.598 GiB respectively. Tight, unmeasured, and on the legacy loader on Windows 0.293 GiB tighter.
3. At native 2K the VAE decode reserve is the biggest item ComfyUI reserves. For this VAE, comfy/sd.py reserves 900 × h × w × 256 × 2 bytes over the latent grid for decoding: 1,887,436,800 B = 1.758 GiB at 1024×1024 (64×64 latents) and 7,549,747,200 B = 7.031 GiB at 2048×2048 (128×128). On the legacy path sampling at 2K grows only to 10.989 GiB, because the activation estimate quadruples to 3.840 GiB. Attention is not the risk: per PR #16400, "blocks stay unmasked on the fast kernels and only text runs carry a mask", so the image tokens do not build a token-by-token mask. A legacy-path 2K decode with the diffusion model still resident asks for 6.758 + 0.629 + 7.031 + 0.391 = 14.809 GiB. On either loader, expect part of the diffusion model to leave the card for the decode and come back for the next image. On an actual out-of-memory, the decode retries with tiled decoding. No peak at 2K on a consumer card has been published. The only 2048×2048 run found, PR #16430's batch of five on an RTX 5090, reports speed and staging, not peak.
4. The bf16 diffusion model is 13.253 GiB of weights on its own. On the legacy path its sampling stage asks for 14.604 GiB, leaving 1.396 GiB, and every prompt change then moves more than 16 GiB of weights through system RAM. The template loads the int8 file by default, and this page follows it.

• Quality notes: (a) The VAE leaves a visible grid at high resolution. On the vendor's discussion #12 a user posting as Rkss 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 reproduces it with a plain encode→decode round trip, with no diffusion model involved. The mitigations named in that thread are a GLSL node, a node pack, or re-encoding through the Flux VAE; the linked Reddit workaround could not be read from this session, and ComfyUI has no fix. The thread names no hardware and does not need to: it is the decoder. (b) int8 against bf16 has not been compared on this card. The int8 files are Comfy-Org's default, and the quality complaints found on 2026-09-21 are about the VAE, not the quantisation.

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

Troubleshooting

TextEncodeQwenImage21 or QwenImage21Cache is missing when the template loads

Your ComfyUI core is older than v0.37.0. That covers a portable from before the 2026-09-21 release, a git checkout from before 2026-09-19, or a Desktop build whose bundled core is older (which core the current Desktop build ships could not be determined). 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 (or a newer tag), then restart. The startup banner should read 0.37.0 or higher.

The startup log prints the cu130 WARNING

Here is what it does on this card, read from the source at v0.37.0. Two separate things are decided in two places. The Native ops: line, printed when the diffusion model loads, comes from get_disabled_quant_formats() in comfy/ops.py, which looks only at the GPU. On compute capability 12.0, supports_int8_compute(), supports_fp8_compute() (major version ≥ 9) and supports_nvfp4_compute() (major ≥ 10) are all true, and so is supports_mxfp8_compute() once PyTorch is 2.10 or newer; below that, mxfp8 alone shows under emulated ops. So a cu128 install still lists int8_tensorwise as native, and that is not a lie: it means ComfyUI routes the layer through the quantised matmul.

Which kernel serves that matmul is decided one layer down, in comfy-kitchen's registry, which tries cuda, then triton (off unless you opt in), then eager. The cu130 gate removes cuda. The eager int8_linear in comfy-kitchen 0.2.35 is neither a failure nor a fallback to bf16. It applies the Hadamard rotation in plain PyTorch, quantises the activations row by row, and multiplies with PyTorch's own INT8 matrix multiply (torch.int8_mm where it exists, otherwise torch._int_mm). It is slower than the fused CUDA kernel and does the same arithmetic. The model's other comfy-kitchen calls (rms_rope, adaln) drop to their eager versions the same way.

The text encoder loses nothing either way. comfy/sd1_clip.py builds text encoders with full_precision_mm=True, so int8 is a storage format there, dequantised for every matmul on any card. At v0.37.0 the only switch back to quantised matmul wraps text generation, not encoding. PR #16432's author describes the same thing for his NVFP4 encoder: "The weights are dequantized for encoding rather than using native NVFP4 matrix multiplication." The shipped files do not opt out of the fast path themselves. All 192 quantisation descriptors in the diffusion model and all 254 in the encoder read {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} (read from the files over HTTP range requests). Net effect of the warning: fused kernels lost on the diffusion model, nothing lost on the encoder. Fix it anyway; it is the torch line in step 1.

Every prompt change takes far longer than a seed change

That is consequence 1 under Results, not a fault. After sampling pushed it out, the encoder's 8.709 GiB has to come back from system RAM, and then the diffusion model has to be restaged. Three responses, in order of cost:

1. Iterate on the seed with a fixed prompt, which reuses the cached conditioning.
2. Swap to the w4a8 encoder or an NVFP4 diffusion model (Running) so that both fit on paper.
3. Accept it.

Do not reach for --enable-dynamic-vram: the dynamic loader is already the default on NVIDIA at this version, and the flag exists for platforms where it is not.

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

Issue #16435, described under Running. Set resolution to 1056. It and 512 are the values clean in both reports so far, and 512 shrinks the references to a quarter megapixel. At resolution 0 the grid the node resolves to is the first reference rounded to a multiple of 32, and the grids reported broken are 1024×1024 (on MPS and CPU) and 1536×1024 (on an RTX 5070 Ti). Disconnecting the VAE from TextEncodeQwenImage21 also removed the speckle in the first report, at the price of much weaker adherence to the reference.

Edits run many times slower than text-to-image

This is the prefix-cache placement at v0.37.0 falling back to recomputing every step (Running, Editing). On v0.37.0, set QwenImage21Cache to dtype int8. master has PR #16429's placement fix, and also the code path in #16443 (next entry). Setting device off makes the recompute permanent; the node's tooltip calls that "the one way to rule the cache out", a debugging setting rather than a fix.

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

Issue #16443, open with no replies on 2026-09-21, reports this hard crash on text-to-image. The setup is a Windows 11 machine with two RTX 5060 Ti 16 GB cards, a git checkout (commit not captured) and the dynamic loader. That most likely means one of those cards ran it. On Windows, ComfyUI forces single-GPU mode unless --cuda-device, --default-device or CUDA_VISIBLE_DEVICES is set (main.py). The report names none of them, and says it has not checked whether --cuda-device 0 avoids the crash. The mechanism PR #16450 proposes (below) has nothing to do with a second card either, so treat this as relevant to a single RTX 5060 Ti. The stack ends in the prefix cache's take → prefetch at qwen_image21/model.py line 353. That line is cache.take on master, where it also runs on the first step. At v0.37.0 the call runs only on cached steps, with no malloc-graph recording around it. The log stages a 6,018 MiB encoder, the size of the w4a8 file (an inference from sizes). No other reproduction has been reported. PR #16450, open and unmerged, attributes it to the cache's staging buffers being allocated while block-weight recording is active, "when the prefix 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).

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. The diffusion model expects 4096-wide conditioning from qwen3vl_8b_*. A prompt enhancer loaded in that slot gives unusable images instead (discussion #4). Load a qwen3vl_8b_* file (the int8 one from step 2, or the w4a8 or bf16 from the same repo) with type qwen_image.

Grid or moiré on skin at 2K

The VAE, per discussion #12 under Results. Post-process, or re-encode through another VAE. It is not a settings problem and not specific to this card.

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

ComfyUI reserves 7.031 GiB for decoding at 2048×2048 (Results, item 3); the real working set on the default loader is unmeasured. ComfyUI makes room by moving model weights off the card and, on a real out-of-memory, logs "Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding." and carries on, so the usual symptom is a slow decode rather than a crash. If you want more margin for other software, add --vram-headroom 1, which keeps an extra GiB free on top of both terms of the default loader's budget. --reserve-vram 1 does something narrower. On the default loader it raises only the capacity-based term from 256 MiB to 1 GiB, and the live check stays: 256 MiB of free VRAM on Linux; on Windows, 512 MiB of NVML free VRAM and a separate check that keeps usage plus 512 MiB under the WDDM budget. On the legacy loader it replaces the 400 MiB (Linux) or 700 MiB (Windows) reserve. 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!)

This is not the lead path here, since the int8 file already fits with room to spare. But GGUFs appeared within hours, and two publishers' cards disagree about which loader to use, so here is what the files say. city96's ComfyUI-GGUF (last commit 2026-01-12) passes a file whose general.architecture key is qwen_image straight to ComfyUI core, which detects 2.1 from the tensor names. A file with no key at all goes down a compatibility path that matches tensor names against its own template list, and that list has no 2.1 entry.

The headers, read over HTTP range requests on 2026-09-21: Abiray/Qwen-Image-2.1-GGUF's Q4_K_M declares qwen_image (3 metadata keys), and leejet/Qwen-Image-2.1-GGUF's Q4_K declares none. Run against city96's templates, leejet's tensor names match nothing, while the same test on a leejet Flux GGUF with no metadata matches Flux. leejet's fork commit adds exactly the missing template (detected on txt_in.text_norm.weight), so his files do need it. His card gives a different reason, that city96's repository appears no longer actively maintained; the header difference is this page's finding, not his. Abiray's card points at city96's node, and its files declare their architecture. A user on Abiray's discussion #1 posted this exact error without saying which file they loaded, and the publisher's answer was to update ComfyUI and the node. Nobody has published an end-to-end GGUF run on this card. If you need one, take a file that declares its architecture, or leejet's fork for his files, and report back via /contribute.

Those are the reports found for this model on 2026-09-21: the fourteen ComfyUI tracker threads that mention Qwen Image 2.1, the vendor's and Comfy-Org's Hugging Face discussions and the Hacker News launch thread; r/StableDiffusion refused this session. The only one naming this card is #16443, a two-card setup. This is launch week, and the tracker moves by the hour. Report problems, or better a measured run, via the submission form.