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, then re-cut on 2026-09-22 once its install had been run on this card (the note below). The timings are measured. Every VRAM budget and requirement is still arithmetic (the only measured memory figures are whole-card readings, which on this loader are not one): 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 a whole-card memory reading cannot: the text encoder and the diffusion model take turns, and the encoder is what gives way every time the prompt changes. Their weights alone come to 15.467 GiB, just under the 15.929 GiB the card reports, and that is not enough room: on the legacy loader neither stage leaves space for the other model, and on the default loader about 0.46 GiB would remain for the CUDA context, the display, the activations and aimdo's 512 MiB floor on Windows (Results, consequence 1).

Hardware data: RTX 5060 Ti (16GB VRAM, compute capability 12.0) · measured: the template's 1024×1024 image in 21.4 s from a cold start, 2048×2048 in 124.1 s, no out-of-memory · encoder and diffusion model are 15.467 GiB of weights against the 15.929 GiB the card reports, too little room to keep both, so they take turns · See benchmark data

ℹ️ What was measured, and how far to trust it. On 2026-09-22 this page's own install ran five times on the site operator's own RTX 5060 Ti 16GB: the ComfyUI v0.37.0 Windows portable (PyTorch 2.13.0+cu130, comfy-kitchen's cuda backend enabled), Comfy-Org's repack at ace0edeb and the text-to-image template's settings, on Windows with a monitor on the card, 31 GiB of RAM and driver 591.86. Dynamic VRAM and pinned memory were on, as by default, and ComfyUI classified the model drive as fast storage (Model storage policy: fast_disk=True for every model, in both sessions). At v0.37.0 that is the mode --fast-disk forces, which cli_args.py describes as "disk-backed dynamic loading and offload over unpinned RAM": offloaded weights are read from the model file instead of being pinned in RAM. A drive it does not classify as fast gets pinned-RAM offload instead; that case was not measured. Every run started cold, with the models unloaded first. All five completed, at 1024×1024 and 2048×2048, with no out-of-memory and no tiled-decode line in the log. The evening before, the same template and variations of it ran eight times on a Comfy Desktop install that had a cu128 PyTorch and printed the cu130 warning. This page uses that session for what the slower install cost, most of it the warning (Troubleshooting), and for three configurations the cu130 session did not repeat, each labelled. Editing was not run. Memory readings are whole-card nvidia-smi samples with the desktop included, and on this loader they are not a requirement (Results). One rig, one operator: unreplicated. Both raw sessions are published: cu130 and cu128.

⚠️ 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 on Linux, 10.192 GiB on Windows (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 on image editing, #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: on this card a cu128 install that printed the warning took 69.4 s for the template's image against 21.4 s on the cu130 portable, most of it down to those kernels (Troubleshooting has the details, and what else differed). 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 mentioned Qwen Image 2.1 on 2026-09-21 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. On the measured portable the lines read pytorch version: 2.13.0+cu130, 'available': True, 'disabled': False, DynamicVRAM support detected and enabled and ComfyUI version: 0.37.0; the triton line reporting No module named 'triton' is expected there and did no harm. Check the torch and comfy-kitchen lines whatever the version line says. The Comfy Desktop install measured for this page also printed ComfyUI version: 0.37.0, while its log showed PyTorch 2.12.0.dev20260220+cu128, the cu130 warning and 'disabled': True, and the template's image took 69.4 s on it instead of 21.4 s. If you use Desktop, read these lines there too.

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 listed only qwen3vl_8b_bf16.safetensors under text encoders until 2026-09-22, when it was synced with the templates (Comfy-Org/docs 9d133794). It now lists qwen3vl_8b_int8_convrot.safetensors as the one the templates load and the bf16 file as the full-precision alternative that needs more memory. If you followed the docs before that, you may 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. On the measured card those lines read 8916 for the encoder, 6920 for the diffusion model and 644 for the VAE.
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. On the measured card that work was smaller than the sampling. Every run there started cold, so each one loaded, encoded, staged and decoded from scratch, and on cu130 all of that together took about 6 s of the template's 21.4 s; the 25 steps took the other 15. A prompt change inside a running session was not timed on its own. Troubleshooting has what the numbers do and do not cover.

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. A ComfyUI maintainer replied on 2026-09-22 that the fixed shift is "kind of on purpose": "the higher the shift the more you see a grid pattern"; he does not say whether that is the VAE grid under Quality notes. Another user disagreed the same day, finding the fixed-shift output far noisier than it should be. The VAE's decode estimate also grows with the pixel count, and at 2048×2048 it becomes the largest single item the legacy loader reserves; the default loader reserves nothing for it (Results, item 3). Measured on this card, 2048×2048 completes on the template's files, in 124.1 s from a cold start on cu130 (4.35 s/it) against 21.4 s at 1024×1024.

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. Time follows the step count: in the cu128 session 40 steps took 104.3 s against 69.4 s for 25, at the same 2.47 s/it. The 40-step image was not compared with the 25-step one. One user reports a reason to try 40: on Comfy-Org's discussion #11, Xenodermus sees faint banding on skin, fabric and fur at the template's 25 steps, with the int8 and bf16 diffusion models and encoders alike and with the simple and normal schedulers, and at 1024×1024 writes "Artifact disappeared completely at 40". Later the same day, after switching to another user's workflow and toning down the prompt, they report no streaks. It is one user's report, and no Comfy-Org member had replied when this page read the thread on 2026-09-23.

A step-distilled option for 2.1 exists: Viggle/Qwen-Image-2.1-viggle-turbo, a third-party distillation by Viggle, labelled a preview and updated several times since its first release on 2026-09-22. As read on 2026-09-24 (revision b667ee50), its card recommends v0.2.1, a 6-step LoRA, says the student "still falls short of the base model" on complicated editing, and ships two ComfyUI custom nodes (a sigma schedule, and a LoRA loader that applies the adapter without merging it into the weights) with text-to-image and edit workflows, tested on a ComfyUI that reports 0.37.0 with frontend 1.53.6, a build newer than the v0.37.0 tag. Those workflows' optional prompt enhancer uses a TextGenerate input that first appears in tag v0.37.2. Nothing measured on this page used any version of it; check the card for the current files and settings. Of the 23 ComfyUI tracker threads opened since 2026-09-18 that a search for the model's names returns (read 2026-09-23), two tie a problem to a LoRA on this model, both closed on 2026-09-23: PR #16493 (Troubleshooting), and issue #16496, in which one user's edits came out shifted to the left, which that user attributed at 13:16Z to Viggle's 4-step LoRA, i.e. the first release (v0.1), naming no GPU or build, before closing it.

Editing. Load Qwen Image 2.1: Image Edit (image_qwen_image_2_1_image_edit.json). 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 at the default dtype. With int8 at 1056 it asks for more than 8.383 GiB, which passes only if, beside the diffusion model, everything else on the card comes to less than 0.787 GiB of the 15.929 GiB it reports; on the measured machine the card held 1,147–1,352 MiB before each run (Results), so there it fails too. That is arithmetic from the code, not a run. 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, but #16443, a hard crash on master, is reported on exactly this kind of edit. 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 highest v* tag, which since 2026-09-23 (18:34Z) is v0.37.2 (Troubleshooting).

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 still open on 2026-09-23. A proposed fix, PR #16444, was closed without merging on 2026-09-22 by kijai; no fix is linked to #16435 now.

If you want both models on the card at once. Two swaps let the encoder and the diffusion model sit on the card together on paper. Only the first has been tried on this card, on the cu128 install only, and it bought no time there; 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. It was measured only in the cu128 session: a cold template run took 70.9 s with it against 69.4 s with the int8 encoder, so it saved no time there, and from the same seed it gave a clearly different composition, just as clean. It was not rerun on cu130, where the most it could save is part of the roughly 6 s a cold run spends outside sampling.
• 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, and it was not measured on this card.

Results

• Speed: measured on this card (the note at the top; table below). On this page's install the template's 1024×1024 image takes 21.4 s from a cold start (20.6 s with a second seed), of which the 25 steps take about 15 s at 1.63 it/s, i.e. 0.61 s/it. 2048×2048 takes 124.1 s (4.35 s/it). The same two runs on the cu128 install took 69.4 s and 297.9 s. Most of that gap is the cu130 warning, but the two installs differed in more than the PyTorch build (Troubleshooting). On cu130 the int8 diffusion model is also the fast file: more than twice as fast per step as bf16 at 1024×1024 (0.61 against 1.38 s/it) and 1.7× at 2048×2048 (4.35 against 7.43). On cu128 the order was the other way round, bf16 46.2 s against int8's 69.4 s. The GPU was busy about 100% of the time through sampling in every run of both sessions (nvidia-smi), so the loader bringing weights in did not set the pace. Editing was not timed. The only edit figures found are PR #16429's RTX 5080 ones under Running, from a larger edit than the template's: from the sizes it states, more than twice the template's 8,064 reference tokens. No other figure for this card turned up on 2026-09-21 in the ComfyUI tracker, the vendor's and Comfy-Org's Hugging Face discussions, the 176-comment Hacker News launch thread or Civitai's 2.1 listings (Reddit refused that session), so a run on a second rig is the most useful thing this page is missing: /contribute.

Every time is ComfyUI's own execution time for one image from a cold start (models unloaded first, so loading is included), 25 steps unless stated, cfg 1, euler, simple. s/it is the average ComfyUI's KSampler prints at the end of the run.

• VRAM usage: measured whole-card, which on this loader is not a requirement. Before each cu130 run the card already held 1,147–1,352 MiB: the desktop, the display and ComfyUI's own process. At peak it read 14,626–15,844 MiB of the 16,311 MiB it reports (14,485–15,719 MiB in the cu128 session, with the Comfy Desktop app open, so not comparable one to one), and in the cu130 session the three 1024×1024 runs peaked higher than the two 2048×2048 ones. The dynamic loader fills the card with whatever weights fit, so these figures say how full ComfyUI chose to make it, not what the job needs, and they are not a floor. In the two cu130 bf16 runs Windows' shared GPU memory also rose, by 1.2 and 4.3 GiB, while dedicated memory was never sampled full; what caused the rise was not established, and it is not attributed to spilling. 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. What the arithmetic settles is consequence 1 below: the encoder and the diffusion model cannot both stay resident, although their 15.467 GiB of weights is under the 15.929 GiB the card reports, because neither loader leaves room for both beside what else the card must hold. All three template files, 6.758 + 8.709 + 0.629 = 16.096 GiB, are more than the card reports even before anything else. The measured runs fit this picture: nothing failed, and the card read nearly full at every size. A whole-card reading cannot say how much of each model was resident at a given moment, or what the job's true peak is, so those two are still not measured.

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 card's 15.929 GiB under either loader. On the measured machine the card held 1,147–1,352 MiB before each cu130 run, with ComfyUI started and its models unloaded: the desktop, the display and ComfyUI's own process together.

Four consequences of the arithmetic, each saying where the measured runs bear on it:

1. The int8 encoder and the diffusion model cannot both stay on the card, under either loader. Their weights alone are 16,607,581,424 B = 15.467 GiB, under the 15.929 GiB (16,311 MiB) the card reports, so what rules it out is the room each loader needs beside them. On the legacy path, with the Linux reserve and even against a nominal 16 GiB, 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); the Windows reserve makes both worse. On the default loader the two models would leave 15.929 − 15.467 = 0.462 GiB for the CUDA context, the display, the activations and aimdo's floor, which on Windows is 512 MiB by itself, and on the measured machine the card already held 1,147–1,352 MiB before each cu130 run. 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.663 and 2.682 GiB of the 15.929 GiB the card reports, 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, and on the legacy loader on Windows 0.293 GiB tighter. The w4a8 case ran and completed in the cu128 session, on the default loader; whether that loader actually kept all three models resident is not something a whole-card reading can show. The NVFP4 case was not run.
3. At native 2K the VAE decode reserve is the biggest item the legacy loader reserves. For this VAE, comfy/sd.py estimates 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 (Linux reserve) 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 Linux, 0.293 GiB more on Windows. On the legacy loader, expect part of the diffusion model to leave the card for the decode and come back for the next image. The default loader reserves nothing for the decode: the VAE is itself a dynamic model, free_memory() does not unload one dynamic model for another, and the estimate only sets how many images are decoded per batch, so diffusion-model weights leave the card only if the decode's real allocations need the room. On an actual out-of-memory, the decode retries with tiled decoding. Measured on this card, it did not come to that: 2048×2048 completed on both builds (124.1 s on cu130) and 2752×1536 on cu128 (301.2 s), with no out-of-memory and no tiled-decode line in either log. That shows the default loader copes at 2K with a desktop on the card. It does not show how much margin was left, because under dynamic VRAM the whole card reads nearly full at every size (VRAM usage, above).
4. The bf16 diffusion model is 13.253 GiB of weights on its own. On the legacy path, with the Linux reserve, its sampling stage asks for 14.604 GiB, leaving 1.325 GiB of the 15.929 GiB the card reports, and every prompt change then moves more than 16 GiB of weights through system RAM. On the default loader it runs on this card, measured at 1024×1024 (41.9 s on cu130) and 2048×2048 (208.4 s), with no out-of-memory. On cu130 it is also the slower file, 1.38 against int8's 0.61 s/it at 1024×1024 and 7.43 against 4.35 at 2048×2048, for an image with the same composition from the same seed (Quality notes). On this card bf16 is a quality reference, not a speed option. 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) The measured runs' images were compared by eye, same prompt and seed (4001). They are not published, so this is the operator's judgement rather than something you can check. In the cu128 session the int8 and bf16 diffusion models gave nearly the same image. Across the two builds the int8 image kept its composition, pose and palette and differed in small details, and the bf16 images were nearly identical. The w4a8 encoder, tried on cu128 only, gave a clearly different composition from the same seed, just as clean. 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

Measured on this card, the install that printed it took more than three times as long for the template's image. The same template, files, prompt and seeds ran first on a Comfy Desktop install whose log printed this warning (PyTorch 2.12.0.dev20260220+cu128, comfy-kitchen cuda 'disabled': True), then on the v0.37.0 portable (2.13.0+cu130, 'disabled': False). Cold, the 1024×1024 image took 69.4 s against 21.4 s (2.47 against 0.61 s/it), and 2048×2048 took 297.9 s against 124.1 s (11.51 against 4.35 s/it). That is one install against another, not one flag flipped. They also differ in Python (3.12 against 3.13), and the Desktop core was past the tag whatever its banner said: it asked for frontend package 1.53.6, which v0.37.0 does not, and after each of its eight sampling passes it logged Comfy model compiler graph breaks: 0, rogues: 0, a line the portable never printed. At the tag Qwen-Image-2.1's transformer builds no such graph; PR #16430, on master, adds it. The Desktop app itself was also open during that session, with its own custom node packs loaded. What ties the difference to the int8 kernels is the bf16 diffusion model, which never goes through them and moved far less between the two (46.2 against 41.9 s at 1024×1024, about 10%, or 1.53 against 1.38 s/it; 7.66 against 7.43 s/it at 2048×2048). It is also why, with the warning, bf16 beat int8 (46.2 s against 69.4 s), while on cu130 int8 is the faster file. The raw sessions are linked in the note at the top. A ComfyUI maintainer says as much: 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."

Here is why, 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 up to rounding, which fits what the two measured builds produced from the same seed: the same composition, differing in small details. 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, and on this card, going by the bf16 control above, that loss is most of the slower install's time. Fix it: it is the torch line in step 1, or the v0.37.0 portable, which ships the cu130 build.

A prompt change takes 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, or on the measured machine from the model file, and then the diffusion model has to be restaged. The measurements put that cost in proportion without timing it directly. Every run on this page was a cold start that loaded all three models afresh, and on cu130 everything outside the 25 steps (loading, encoding, staging, decoding) took 5–6 s of each template image. A prompt change inside a running session was not timed on its own. The files were probably coming from Windows' file cache during those runs, which were back to back on a machine with 31 GiB of RAM, but that was not recorded; a first run after a reboot reads 17.3 GB from disk and was not timed. If prompt changes feel slow, in order:

1. Check step 3's log lines. On the cu128 install the same cold run spent 6–8 s outside sampling and about 62 s inside it, so a slow install shows up as slow steps, not as a slow reload.
2. Iterate on the seed with a fixed prompt, which reuses the cached conditioning.
3. The swaps under Running make both models fit on paper. The one that was tried, the w4a8 encoder, saved no time on a cold run on the cu128 install; it was not rerun on cu130.

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 edit-time crash 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 when editing

Issue #16443, open, reports this hard crash on an image-edit (img-to-img) workflow. Its reporter first called it text-to-image and corrected that on 2026-09-22: "I have not confirmed this crash with pure text-to-image generation." 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 body sets none of them, and in a comment on 2026-09-22 the reporter adds: "I also tested launching ComfyUI with --cuda-device 0 to force a single GPU, but the same crash still occurs." 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, which is what the w4a8 file stages as: this page's cu128 session logged 6018MB Staged for it. On 2026-09-22 a second user, also with an RTX 5060 Ti 16 GB (plus a 3060 12 GB), reported the same error on img-to-img only, with text-to-image working; neither report gives a ComfyUI commit. Later that day both described the crash as intermittent and pointed at image size: the second user saw it only once img-to-img went above 1 MP, and the reporter's failing workflow uses two input images of about 1500×1000, with no crash so far after swapping in smaller ones; both say they have run too few images to be sure. The thread had four comments and no maintainer reply when this page read it on 2026-09-23. This page's cu128 session ran on a core past the tag that carries the malloc-graph wrapper PR #16450 blames (see the cu130 WARNING entry), and its eight text-to-image runs completed, which is consistent with the crash being edit-only. PR #16450, open, unmerged and not reviewed by a maintainer, 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 a tag: git checkout v0.37.0, or update_comfyui_stable.bat on the portable, which checks out the highest v* tag. Since 2026-09-23 (18:34Z) that is v0.37.2, nine commits past v0.37.0 over two tags (v0.37.1, cut on 2026-09-22, was the first): 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; none changes the three Qwen-Image-2.1 workflow files, and none carries master's changes above.

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; from v0.37.0 through v0.37.2 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, so going back to v0.37.0 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.

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

PR #16493, opened and closed unmerged by its author within three minutes on 2026-09-23, reports that adding or removing a LoRA on an already-resident quantised model raises this error on master, with a Qwen-Image-2.1 int8/convrot checkpoint (it names both the int8 and the ConvRot W4A4 layouts), and that every later generation fails the same way until the server restarts. At v0.37.0 the legacy patcher's unpatch_model restores backed-up weights through comfy.utils.set_attr_param, which has the same code as the PR's "before", so the path the PR reports exists at the tag on the legacy loader. The default dynamic loader restores backed-up weights through the same function: ModelPatcherDynamic.load() calls restore_loaded_backups(), which passes every backed-up weight to comfy.utils.set_attr_param (comfy/model_patcher.py). Whether those backups hold quantised weights when a LoRA changes has not been shown either way, so whether the default loader can hit the error is not established. That is a reading of the code, not a report. Viggle's own ComfyUI LoRA node (Running) adds the adapter through forward hooks instead of patching the weights; whether that avoids this restore path is not established. If you hit it after adding or removing a LoRA, restart ComfyUI.

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.

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.", and on 2026-09-22 the reporter confirmed that downloading it again fixed it. Compare the file's sha256 with the list in step 2 and download it again if they differ.

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

On the legacy loader ComfyUI reserves 7.031 GiB for decoding at 2048×2048; on the default loader that estimate only sizes the decode batch (Results, item 3). On the measured card, with the desktop and a monitor on it, neither 2048×2048 nor 2752×1536 ran out of memory or fell back to tiled decoding, and at 2048×2048 on cu130 the log shows about 9 s from the end of sampling to the finished image, about 4 s of it after the VAE's load line. The working set itself is not measured, because a whole-card reading on the default loader is not one. 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. One end-to-end GGUF run on this card has been published since, in issue #16470 (2026-09-22): leejet's fork with a Q8_0 file at 1760×2368 and 20 steps, three images in 308, 158 and 158 s against 330, 234 and 267 s for the int8 file on the same install. That install ran PyTorch 2.10.0+cu128, below the cu130 gate (the cu130 WARNING entry), so it says nothing about the int8 file on cu130. If you need a GGUF, 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; #16470, opened the next day, also names it (GGUF entry above). This is launch week, and the tracker moves by the hour. Report problems, or better a measured run from a second rig, via the submission form.