Qwen-Image-2.1 on RTX 4080: ComfyUI int8 template in 16 GB, encoder and DiT take turns

What You'll Build

A ComfyUI graph on one RTX 4080 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 (DiT), a Qwen3-VL-8B text encoder and a four-channel (RGBA) autoencoder, released on 2026-09-20 with support in ComfyUI core from day one.

The RTX 4080 is the one AD103 card NVIDIA's Ada whitepaper documents in full: 76 of the die's 80 streaming multiprocessors, 9,728 CUDA cores, 16 GB of 22.4 Gbps GDDR6X on a 256-bit bus for 716.8 GB/s, and a 320 W board power. The RTX 4080 SUPER beside it on NVIDIA's spec table has the same 16 GB, bus and power, so the fit on this page is the same for both cards.

Nothing on this page was measured on an RTX 4080. The card facts come from NVIDIA and from ComfyUI startup logs that owners of this card posted in public bug reports. Every VRAM budget 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, each labelled with the loader it belongs to. The arithmetic settles one thing a measurement would only confirm. The two big files, the text encoder (8.709 GiB) and the diffusion model (6.758 GiB), come to 15.467 GiB. That leaves 0.525 GiB of the 15.992 GiB this card reports on Windows, and less against the Linux reading below, for the CUDA context, whatever drives the display, the sampling activations and the default loader's own floor, which is 512 MiB on Windows and 256 MiB on Linux by itself. So the two take turns on this card, and the encoder is what gives way every time the prompt changes.

Hardware data: RTX 4080 (16GB VRAM, Ada AD103 with 76 SMs, compute capability 8.9) · not measured on this card · encoder and diffusion model total 15.467 GiB against the 15.992 GiB ComfyUI reports for this card on Windows, too little room left for the loader's own floor and the activations, so they take turns · See benchmark data

ℹ️ What was measured, and on which card. The site's own measured runs of this install are the operator's, on one RTX 5060 Ti 16GB, a Blackwell card and not this one: one rig, one operator, unreplicated (cu130 session, cu128 session). This page uses them in five places, and never as a figure for the RTX 4080: (1) an install whose log prints ComfyUI's cu130 warning ran the template's int8 image far slower there than the cu130 portable did (Troubleshooting); (2) the int8-versus-bf16 order was opposite on those two builds (Results, item 4); (3) that machine's 31 GiB of RAM is one of the RAM data points (Requirements); (4) what its desktop and ComfyUI's own process held before each run (The card); (5) its default loader completed 2048×2048 on these files with no out-of-memory (Results, item 3). Each of those places carries the same label and link. The finding that int8 beat bf16 on speed was made on Blackwell with cu130; no comparison of the two files on an Ada card turned up.

⚠️ 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 §2.a grant 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 anything you build on their outputs: a model you create, train, fine-tune or improve with them and then distribute has to say "Built with Qwen" or "Improved using Qwen" in its documentation. Two users report on discussion #7 that the commercial-licence address bounced, the second on 2026-09-22. 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. The repack's README, edited on 2026-09-22, says they are "to be used with the TextGenerate -node", and on its 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 4080. 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 card: what the RTX 4080 brings, and what it does not change

RTX 4080 or RTX 4080 SUPER: for this model it does not matter which. The SUPER adds four SMs and 0.6 Gbps of memory speed. Capacity, bus width, host link, compute capability and board power are identical, and those are the only card properties any memory figure on this page uses. If you are choosing between them for Qwen-Image-2.1, nothing found so far separates them.

Against its two siblings (the RTX 4070 Ti SUPER is AD103 on most boards, a cut-down AD102 on a few, per Tom's Hardware, 12 July 2024) this card sits in the middle: 76 SMs against the RTX 4070 Ti SUPER's 66 and the RTX 4080 SUPER's 80, 716.8 GB/s against 672 and 736. Its capacity, bus width, host link and compute capability are the same as theirs, so the fit below is the same on all three. The differences can only show up as speed, and no Qwen-Image-2.1 timing on any of the three turned up (Results, Speed, lists where this page looked). This page does not turn the spec gap into a number: scaling another card's time by SM count or bandwidth is an estimate, not a measurement. The siblings' figures come from NVIDIA's RTX 4070 family table, NVIDIA's launch release (672 GB/s) and PNY's RTX 4080 SUPER brochure.

The capacity that matters is the one the driver reports, not the one on the box. ComfyUI prints it at startup as Total VRAM … MB, and the figure is MiB: model_management.py divides the total PyTorch reports by 1,048,576 and rounds it. An owner of this card posted Total VRAM 16376 MB on Windows (#10940), and the same log's system-information block gives the unrounded total, 17,170,956,288 B = 15.992 GiB. The one 2026 Linux log found, #13394, reads 15,942 MiB = 15.568 GiB. Neither log says why the platforms differ, and this page does not guess. Whatever drives your display and the CUDA context then come out of that figure. How much your desktop takes is your machine's number, not this card's: on the operator's RTX 5060 Ti (one rig, one operator, unreplicated; session), the desktop, the display and ComfyUI's own process held 1,147–1,352 MiB before each run.

The files

The three files the official text-to-image template loads, byte-exact from the Comfy-Org repack at revision 5dc5850e (2026-09-22T13:06Z, a README edit; every weight file's size and LFS hash is the same as at the previous revision ace0edeb, which the site's other pages for this model pin):

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 at that revision 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, and it is not this card's number. It is the smallest card size in this catalogue on which every stage of this exact install keeps its weights whole under both of ComfyUI's loaders, a derivation done on this model's RTX 3060 page. Every page that installs these three files carries the same floor. 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 tag v0.36.0 and present from 6bfaacc67c on. The first tag that contains it is v0.37.0 (commit 73c9bad4), 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. A v0.37.1 tag followed on 2026-09-22 at 19:12Z; read at 20:45Z it has no release object and no portable of its own, so v0.37.0 is still the latest release. Against v0.37.0 the tag adds three commits: Hunyuan Image 3.5 partner nodes, workflow templates 0.11.68 and the version bump. None of them touches Qwen-Image-2.1, and none of the three 2.1 template files has changed since 371a7b7171, so either tag runs this page's workflow; the page pins v0.37.0 because that is the one with a portable build. The template's own note says why the Desktop app can lag behind that: "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 and are on master only: PR #16429, which changes where the edit cache is kept, and PR #16430, which compiles the transformer blocks. Neither is needed to run the templates. v0.37.0 is the safer default. master also carries the code path in the open crash report on image editing, #16443 (Troubleshooting).

Windows, the short route. Download ComfyUI_windows_portable_nvidia.7z from the v0.37.0 release and extract it. The ComfyUI README says that portable comes with Python 3.13 and PyTorch for CUDA 13.0. Do not take the nvidia_cu126 build: the same 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 download 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 (8, 9)

(8, 9) is Ada's compute capability. NVIDIA's CUDA GPU list files the GeForce RTX 4080 and RTX 4070 Ti under 8.9 and does not name the SUPER variants separately, so the line above is the check that counts on your own machine. 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 what that cost on one measured card, and why it is not a figure for this one). requirements.txt at the tag pins comfy-kitchen==0.2.35 and comfyui-workflow-templates==0.11.66. The x86-64 Linux and Windows wheels of that comfy-kitchen release are built with 89 in their CUDA architecture lists (setup.py: 75-real;80-real;89;120f on Windows, 75-real;80-real;89;90a-real;100f;120f on Linux; the build workflow overrides the list only for the Windows-on-ARM wheel), which covers this card, and its CUDA backend takes the CUTLASS int8 path on any card whose compute capability starts at 8 (backends/cuda/__init__.py, _cuda_device_supports_cutlass_int8_dequant).

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 5dc5850eb514a3685f6a03a2641728a8f7549c69 --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 the same 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 5dc5850eb514a3685f6a03a2641728a8f7549c69 --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: two users on the vendor's discussion #5 report comparing its tensors with the original Instruct and finding no further training, and Comfy-Org's bf16 copy carries the same LFS sha256 in Comfy-Org/Qwen3-VL, a repo that held it months before this model existed. Qwen has not said so themselves. If you already have qwen3vl_8b_int8_convrot.safetensors for another model, it is the same file (same hash in both repos).

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. On this card it should show:

• Total VRAM 16376 MB on Windows (the 2026 Linux log quoted above read 434 MiB less). A much smaller figure means a 12 GB card, not this one.
• pytorch version: ending in +cu130, and no cu130 warning.
• Found comfy_kitchen backend cuda: with '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.
• DynamicVRAM support detected and enabled, and ComfyUI version: 0.37.0 or higher.

When the diffusion model loads, ComfyUI prints Using mixed precision operations and a Native ops: … , emulated ops: … line (comfy/ops.py, pick_operations). On compute capability 8.9 the native side lists int8_tensorwise, which is what the template's files use, together with the two float8 formats, convrot_w4a4 and asym_w4a8_int8; the emulated side lists nvfp4 and mxfp8, both of which need compute capability 10 or higher (model_management.py, supports_nvfp4_compute and supports_mxfp8_compute). The order of the names varies between runs. That line says how ComfyUI routes each format; which kernel serves int8_tensorwise is the separate question the cu130 gate decides.

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 closed while this page was written. The first template commit on 2026-09-20 (templates 0.11.65) loaded the bf16 encoder, and commit #1277 the same day (0.11.66, the version v0.37.0 pins) switched it to int8. The docs.comfy.org tutorial listed only the bf16 encoder until its source was synced to the templates on 2026-09-22 at 07:39Z (docs commit 9d133794); it now lists the int8 encoder as "loaded by the templates, lower memory" and the bf16 one as full precision. If you followed the docs before that, you may have a 16.330 GiB encoder the template does not load, bigger than this card.

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 (or, on a drive ComfyUI classifies as fast, is read back from the model file, the mode --fast-disk describes as "disk-backed dynamic loading and offload over unpinned 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 across the card's PCIe 4.0 x16 link, and the diffusion model has to be restaged after it. How long that takes on an RTX 4080 has not been measured.

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), while the vendor's scheduler_config.json turns on dynamic shifting (base 0.5 at 256 tokens, max 0.9 at 8,192), which the vendor's diffusers pipeline (pipeline_qwenimage21.py) extends linearly with no upper clamp: 0.69 at 1024×1024, 1.313 at the README's own 2048×2048. Issue #16447 (open) reports the mismatch. A ComfyUI maintainer replied on 2026-09-22 that the fixed shift is "kind of on purpose", because "the higher the shift the more you see a grid pattern which is very obvious in your first image". So the reply points at the grid in the reporter's own image; it does not say whether that is the VAE grid of discussion #12 (Quality notes). Another user disagreed the same day, finding the fixed-shift output far noisier than it should be. The VAE's decode estimate grows with the pixel count too, and at 2048×2048 it becomes the largest item on the legacy loader's list, while the default loader does not reserve it at all (Results, item 3). A 2K run on this card has not been published.

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

cfg and steps. The template note is explicit: "cfg: keep 1 for the Qwen Image 2.1 official path. Raise it only if you use a negative prompt." Raising it makes every step a conditional plus an unconditional pass. The vendor's own diffusers example runs 40 steps with no guidance setting; the template starts at 25. A step-distilled option for 2.1 appeared on 2026-09-22: Viggle/Qwen-Image-2.1-viggle-turbo, a third-party 4-step distillation by Viggle, shipped as a rank-64 LoRA and as a full bf16 transformer and labelled a v0.1 preview. Its card says the release "still falls short of the base model": text-to-image at 4 steps is usable, complicated edits are clearly worse. The card documents diffusers only, with its own scheduler setting, and names no ComfyUI workflow; nothing on this page was run with it.

Editing. 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 a 16 GB card. The code (comfy/ldm/qwen_image21/model.py) sizes it as 2 × 32 layers × prefix tokens × 4096 × 2 bytes. At the resolution 1056 this page recommends below, the template's two 896×1152 references resize to 928×1184 and become 2 × 58 × 74 = 8,584 tokens: 4,500,488,192 B = 4.191 GiB, or 2.096 GiB with dtype int8, and every further token in the prefix, the prompt's among them, adds 524,288 B. At v0.37.0 the auto setting keeps the cache on the GPU only if four times its size is free at the moment of the check, then tries system RAM under the same rule, and otherwise recomputes the prefix on every step. Four times the bf16 cache is 16.766 GiB, more than the whole card. Four times the int8 cache is 8.383 GiB, and with the diffusion model's 6.758 GiB on the card no more than 9.234 GiB of its 15.992 can be free before the CUDA context, the display and anything else resident take their share, so even then the GPU leg is marginal. The author of PR #16429 adds that the tag's VRAM test "gets disrupted by smart memory + dyn vram", and that its RAM test "requires 4x RAM to be free and doesnt account the pin quotas at all". That PR shows the fallback on an RTX 5080 (16 GB, a Blackwell card, not this one) with 32 GB of RAM: a two-reference edit ran at 4.01 s/it before the change, which the author captions as full recompute, and at 1.02 it/s after it. That PR is on master, not in v0.37.0.

What to do on v0.37.0, all derived from the node's code and none measured on this card: set the cache node's dtype to int8; its tooltip says "int8 halves the cache at about bf16 accuracy". If edits still run many times slower than text-to-image, that is the recompute fallback. device cpu or device gpu skip the four-times test and ask for only twice the cache free on that device (4.191 GiB for the int8 cache at resolution 1056); the tooltip says "cpu (RAM) is prefetched behind compute and costs little speed." Moving to master for #16429 is the other route, but #16443, a hard crash on master, is reported on exactly this kind of edit.

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

• The original reporter (Apple MPS and CPU) finds broadband speckle when the grid comes out at exactly 1024: "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 1024×1024 reference clean but a 1536×1024 one broken at both resolution 0 and 1248, with the edit instruction ignored; 512, 1024, 1056 and 2048 are clean there. The two setups 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; the output then comes out about 1056×1056 pixels in the first reference's aspect ratio. The issue was still open on 2026-09-22 with no new comment since 2026-09-21. PR #16444, which proposed a fix by chunking the attention and had been validated by its author with unit tests only, 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. Swaps that shrink the weights, each judged for this architecture, none measured on this card:

• The w4a8 encoder from the same repo and revision (text_encoders/qwen3vl_8b_w4a8.safetensors, 5.879 GiB): change only the CLIPLoader file name. The template's diffusion model, this encoder and the VAE come to 14,244,398,116 B = 13.266 GiB, which leaves 2.726 GiB of the 15.992 GiB this card reports on Windows and 2.302 GiB of its Linux reading. On paper that covers the legacy loader's 1024×1024 stages, but its decode stage takes 2.441 GiB of that on Windows and 2.148 GiB on Linux, leaving 0.284 GiB and 0.154 GiB for the CUDA context and whatever drives the display (Results, item 2): tight, and untested. At 2048×2048 it is not enough on that loader, where the decode estimate alone is 7.031 GiB. It is Comfy-Org's own file. It trades encoder precision for co-residence, and what that costs in images is your call.
• A community NVFP4 diffusion model (for example BennyDaBall's) buys nothing here but size. ComfyUI marks nvfp4 as emulated below compute capability 10, so on this card those layers are dequantised for every matmul.
• A community INT4 ConvRot build such as toxicdog's is a different case on Ada than on Blackwell: ComfyUI lists convrot_w4a4 as native on this card, and comfy-kitchen 0.2.35's native int4 kernel is enabled only when the compute capability's major number is 8 (_cuda_device_supports_native_int4_mma), which includes 8.9. No run of one on a named card turned up, and the only comment on that repo's discussion tab, from a user who names no card, reports poor output quality. It is a third-party quantisation of the same research-licensed weights.
• Comfy-Org's qwen3vl_8b_fp8_scaled encoder in Comfy-Org/Qwen3-VL carries the same 750 tensor names as the int8 one (read over HTTP range requests), so the qwen_image loader takes it by construction. It is 10,588,637,512 B = 9.861 GiB, 1.153 GiB bigger than the int8 file, and it gains nothing from this card's FP8 cores (next section). No report of anyone running it with 2.1 was found.

What Ada's FP8 does, and does not do, here

The RTX 4080 has FP8 tensor cores; ComfyUI reports float8_e4m3fn native on it (supports_fp8_compute is true from compute capability 8.9 up). For this model in v0.37.0 that is idle, for three separate reasons, each read from the files or the source:

• The diffusion model is not an FP8 file. Its header carries 192 quantisation markers; the twelve read over HTTP range requests (the first, the last and ten at random) all say {"format": "int8_tensorwise", "convrot": true, "convrot_groupsize": 256} with no full-precision opt-out, so it runs INT8 matmuls, which Ada and Ampere both have. Comfy-Org publishes no FP8 diffusion model to switch to.
• The encoder is dequantised however it is stored. Quantised text encoders load through mixed_precision_ops(..., full_precision_mm=True) in comfy/sd1_clip.py; only the text-generation path lifts that, and encoding does not use it. PR #16432's author describes the same thing for an NVFP4 encoder: "The weights are dequantized for encoding rather than using native NVFP4 matrix multiplication." So the encoder's format is a memory choice on every card, not a compute choice.
• NVFP4 files are emulated. Covered in the list above.

Results

• Speed: not measured on this card, and none was found for it, so none is given. Nothing turned up for the RTX 4080 or for the RTX 4080 SUPER or RTX 4070 Ti SUPER, whose figure could stand in with attribution, in the ComfyUI tracker threads that mention Qwen Image 2.1, every discussion on the vendor's and Comfy-Org's Hugging Face repos, the Hacker News launch thread, SGLang's Qwen-Image-2.1 cookbook (its rows are RTX 4090, RTX 5090, RTX PRO 6000, DGX Spark, B200 and H200, none of them an AD103 card), Civitai's 2.1 listings or this site's own benchmark data (all re-read 2026-09-22 around 17:00Z, the tracker, discussions and launch thread again at 20:35Z; Reddit refused this session). The one report found of these files on a 16 GB Ada card, a user's RTX 4060 Ti 16GB run of the template's three files on the vendor's discussion #35, is a different card, so its times are not repeated here; it does show the template's int8 files completing text-to-image and editing on a 16 GB Ada card. The measured facts this page takes from the site's own runs, on another card, are listed in the box at the top; the other cards' reports it uses, among them #35 here, #16470, #16435, #16437 and PR #16429, are named where they appear. A timing from an RTX 4080 is the most useful thing this page is missing: /contribute.

• VRAM usage: derived, not measured. Neither Qwen nor Comfy-Org publishes a figure: the vendor's README gives enable_model_cpu_offload() as its memory advice and no number, and the docs page gives none. 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; the comment in model_management.py reads "don't actually unload dynamic models for the sake of other dynamic models".

What does govern is comfy-aimdo's budget (plat.h, comfy-aimdo 0.5.5), 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. On Linux it keeps 256 MiB (VRAM_HEADROOM) free by cuMemGetInfo (control.c). On Windows the aimdo DLL takes its budget poll from the Windows-specific source (build workflow); shmem-detect.c runs two checks and takes the stricter, one keeping aimdo's usage plus 512 MiB under the operating system's WDDM video-memory budget, the other keeping 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, which describes the Linux build (on Windows a value up to 512 MiB changes nothing either). --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. What the arithmetic settles on this loader: 6.758 + 8.709 + 0.629 = 16.096 GiB of template weights cannot all be resident on the 15.992 GiB this card reports on Windows (over by 112,134,824 B = 0.104 GiB), and the encoder and diffusion model alone, 15.467 GiB, leave less than aimdo's own floor plus the CUDA context, the display and the activations need (item 1 below).

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 Windows for a card that reports more than 15 GiB, which this one does.

On Windows each row is 0.293 GiB higher (encode 10.192 GiB). When it frees memory for a model the legacy loader also asks for 10% headroom on that model's weights, which the rows leave out. For the encode and decode rows, what is asked for is also the test of whether the model goes on the card whole. For sampling it is not: sampler_helpers.py hands load_models_gpu() a second estimate at batch 1, and the whole-or-partial decision uses the diffusion model's weights plus that estimate and the reserve, never less than the fixed minimum. At 1024×1024 that is 7,256,783,064 + 858,993,459 + 419,430,400 = 8,535,206,923 B = 7.949 GiB on Linux (the batch-1 estimate, 515,396,075 B, plus the reserve is below the fixed minimum), and at 2048×2048 7,256,783,064 + 2,061,584,302 + 419,430,400 = 9,737,797,766 B = 9.069 GiB; both are 0.293 GiB higher on Windows. The sampling row is the free memory the loader unloads weights to reach, not the point where the diffusion model stops fitting. An edit adds its reference latents to the sampling estimate (memory_usage_factor_conds in model_base.py), so the edit template's sampling row is larger than this one. Below, Linux stages are set against this card's Linux reading and Windows stages against its Windows figure, and every remainder is computed from the byte figures and rounded once, so it can differ by 0.001 GiB from a subtraction of the rounded numbers.

Four consequences of the arithmetic, none measured on this card:

1. The int8 encoder and the diffusion model cannot both stay on the card, under either loader. All three files together are 17,283,091,112 B = 16.096 GiB, over the Windows figure by 112,134,824 B = 0.104 GiB, so the three can never be resident at once. The encoder and the diffusion model alone are 16,607,581,424 B = 15.467 GiB, which fits on paper, but only just. On the default loader that leaves 0.525 GiB of the Windows figure, of which comfy-aimdo keeps 512 MiB free by itself, before the CUDA context, the display and the sampling activations; against the Linux reading it leaves 0.101 GiB, less than aimdo's 256 MiB Linux floor on its own. On the legacy loader the stages settle it too. On Windows, encoding leaves 5.799 GiB, less than the diffusion model's 6.758, and sampling (8.402 GiB) leaves 7.590 GiB, less than the encoder's 8.709; on Linux the same two stages leave 5.669 and 7.459 GiB of the Linux reading. 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." Its two figures are the weights' sizes in MiB, not peaks, and the output corruption that issue is about is tied to --enable-dynamic-vram on ROCm; this page does not carry it over to an NVIDIA card.
2. Everything resident is possible on paper with the w4a8 encoder at 1024×1024, at 13.266 GiB of weights (Running). On the legacy path, with all three resident, the sampling stage asks for 14.617 GiB on Linux and 14.910 GiB on Windows, and the decode stage, the tighter one, for 16,551,265,316 B = 15.415 GiB on Linux and 15.708 GiB on Windows. That clears this card's Linux reading by 0.154 GiB and its Windows figure by 0.284 GiB, before the CUDA context and whatever drives the display. At 2048×2048 the decode estimate alone (7.031 GiB) is more than the weights leave, so all-resident does not hold there. Tight, and untested on this card.
3. At native 2K the VAE decode estimate is the biggest item on the legacy loader's list, and the default loader does not reserve it. 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 loader, load_models_gpu() asks for that much free before the decode, so a 2K decode with the diffusion model still resident asks for 6.758 + 0.629 + 7.031 + 0.391 = 14.809 GiB on Linux (0.759 GiB left of the Linux reading) and 15.102 GiB on Windows (0.889 GiB left), and weights are unloaded to make room; sampling at 2K grows only to 10.989 GiB there, because the activation estimate quadruples to 3.840 GiB. On the default dynamic loader the same estimate reserves nothing: the VAE is a dynamic model too, free_memory() does not unload one dynamic model for another, and beyond that call the figure only sizes the decode batch. Weights leave the card there only when the decode's own allocations need the room, and how large those are at 2K has not been measured. Attention is not the risk at 2K: per PR #16400, "blocks stay unmasked on the fast kernels and only text runs carry a mask". On an actual out-of-memory, the decode retries tiled rather than failing, on either loader. The published 2K-class runs of these files on a 16 GB card found so far are all on the RTX 5060 Ti: the operator's session (one rig, one operator, unreplicated; cu130 session) completed 2048×2048 with no out-of-memory and no tiled-decode line, and the #16470 reporter ran 1760×2368 (Troubleshooting). They show how the default loader handles files bigger than the card, not a result for the RTX 4080.
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 on Linux (0.965 GiB left of the Linux reading) and 14.897 GiB on Windows (1.095 GiB left); the smaller test of whether it goes on the card whole is 15,508,704,475 B = 14.444 GiB on Linux (1.125 GiB left) and 15,823,277,275 B = 14.737 GiB on Windows (1.255 GiB left). Every prompt change then moves more than 16 GiB of weights between the card and system RAM. On the default loader it pages rather than failing. Whether it is slower or faster than the int8 file on this card is unmeasured. The only published comparisons found (searches listed under Speed) are the operator's two sessions on one Blackwell RTX 5060 Ti (one rig, one operator, unreplicated; cu130, cu128), and they point both ways: with cu130 the int8 file was faster (21.4 s against 41.9 s at 1024×1024, 124.1 s against 208.4 s at 2048×2048), and on the cu128 build that printed the cu130 warning bf16 was faster (46.2 s against 69.4 s, and 217.4 s against 297.9 s). comfy-kitchen 0.2.35 sends the int8 matmul on every card of compute capability 8.0 and up through the same code, its CUTLASS path included (only Turing, 7.5, has kernels of its own; _cuda_device_supports_cutlass_int8_dequant in backends/cuda/__init__.py), so a cu130 install on this card takes the same int8 path as that card's cu130 run. What differs is the silicon, and no comparison of the two files on an Ada card turned up. The template loads the int8 file, 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 says a plain encode→decode round trip through the VAE shows it, with no diffusion model involved; the image posted with it is credited to another user. The mitigations named in that thread are a GLSL node, a node pack, or re-encoding through the Flux VAE; the thread was still open on 2026-09-22 with no fix from Qwen or ComfyUI, and it names no hardware because it does not need to. (b) One complaint found blames the int8 file. The #16470 reporter (an RTX 5060 Ti, a cu128 build with sage attention and --fast options on) ends by saying the int8 file "can distort body parts more often than Q8 version with the same seed", where "Q8 version" is the reporter's Q8_0 GGUF, with no images or counts posted. No other quality complaint found blames the int8 files; among them are the 2K schedule (#16447, under Running), fingers and toes (the vendor's discussion #29, one user, with a reply suggesting a higher cfg and a negative prompt), a yellow colour cast (Comfy-Org's discussion #10, where a user offers a custom node to correct it), garbled text rendered inside images (Comfy-Org's discussion #6, two users), the VAE grid in (a), the edit-path issue #16435 (Running) and the banding in (c). A complaint about a different file, the community INT4 ConvRot build, is under Running. The int8 files are Comfy-Org's default. (c) On Comfy-Org's discussion #11 a user reports faint banding on skin, fabric and fur at the template's 25 steps, the same with either diffusion-model file, either encoder and either scheduler, and writes "Artifact disappeared completely at 40" steps at the same 1024×1024. At 22:11Z the same user wrote that with another user's workflow and a toned-down prompt, "I see no streaks", and on 2026-09-23 at 01:15Z a third user advised 40 steps, so the thread reports two remedies. It is one thread, with no reply from a Comfy-Org member as of 2026-09-23, and nothing in it ties the banding to the VAE grid in (a) or to the 2K schedule of #16447; if you see it, 40 steps, the vendor's own default, is the cheap thing to try, and a milder prompt the other.

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

Troubleshooting

TextEncodeQwenImage21 or QwenImage21Cache is missing when the template loads

Your ComfyUI core is older than v0.37.0: 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

Fix it: it is the torch line in step 1, or the v0.37.0 portable, which ships the cu130 build. What it costs on this card has not been measured. On the one card where it was, the operator's RTX 5060 Ti (one rig, one operator, unreplicated; cu128 session, cu130 session), an install whose log printed the warning took 69.4 s for the template's 1024×1024 image against 21.4 s on the cu130 portable, both from a cold start. That was one install against another, not one flag flipped (they also differed in core commit, Python version and more, all listed in the session READMEs), but the bf16 diffusion model, which never goes through the int8 kernels, moved only about 10% between them, which ties most of the gap to those kernels. A second report points the same way on the same kind of card: on #16470 a user with an RTX 5060 Ti on the v0.37.0 core and PyTorch 2.10.0+cu128, a build the gate switches off, found the int8 file slower than a Q8_0 GGUF at 1760×2368, with sage attention and other --fast options on, and kijai, a ComfyUI collaborator, replied "You need pytorch with cu130 for int8 models to work properly." Neither run is a figure for the RTX 4080. They say the gate is worth checking.

Here is why, read from the source at v0.37.0. Two separate things are decided in two places. The Native ops: line comes from get_disabled_quant_formats() in comfy/ops.py, which looks only at the GPU, so a cu128 install on this card still lists int8_tensorwise as native, meaning 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, slower than the fused kernel and the same arithmetic up to rounding. The text encoder loses nothing either way, because it is dequantised for encoding on any card (previous section).

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 from the model file, and then the diffusion model has to be restaged. Iterate on the seed with a fixed prompt to reuse the cached conditioning, check step 3's log lines, and if you want both models resident, try the w4a8 encoder (Running). 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). Set QwenImage21Cache to dtype int8, and if that is not enough, to device cpu. 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 image-edit (img-to-img) workflows. Read again on 2026-09-22 at 17:05Z (four comments, the last at 14:08Z), the thread holds two users: the reporter, on a machine with two RTX 5060 Ti 16 GB cards, and a second user with one RTX 5060 Ti 16 GB plus an RTX 3060 12 GB. The reporter runs a git checkout, with no commit captured, and the dynamic loader; the second user gives no install details. Both say text-to-image works for them, and both describe the crash as intermittent and tied to larger input images: the second user saw it only once the resolution went above 1 megapixel, and the reporter with two inputs of about 1500×1000 each, but not so far after switching to smaller ones. The reporter corrected the original description on 2026-09-22: "I have not confirmed this crash with pure text-to-image generation." The reporter added at 14:08Z that forcing a single GPU with --cuda-device 0 did not help, so the second 5060 Ti in that machine is not the explanation. The stack ends in the prefix cache's take → prefetch at qwen_image21/model.py line 353 of the reporter's checkout. On master (read at 95539f56, 16:27Z) that line is the cache.take call inside the malloc-graph recording PR #16430 added; at v0.37.0 the same call sits at line 337 and runs only on cached steps, with no such recording around it. PR #16450, open, unmerged and not reviewed by a maintainer, attributes the crash to the cache's staging buffers being allocated during that recording, "when the prefix cache spills to host RAM". No report names an RTX 4080. If you hit it on master, go back to v0.37.0 (git checkout v0.37.0, or update_comfyui_stable.bat on the portable), or feed smaller references.

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

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

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_*, and a prompt enhancer loaded in that slot gives unusable images instead. 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

Issue #16472 (opened 2026-09-22, on an AMD integrated GPU, not an NVIDIA card) reports this at the CLIPLoader with qwen3vl_8b_int8_convrot.safetensors, and open PR #16474 first attributed it to a quantisation marker stored empty in that file; at 17:20Z the same day its author reported the hosted file's marker intact and pointed to an incomplete local download instead. This page's own read agrees that Comfy-Org's file at the revision this page pins has no empty marker: all 254 comfy_quant entries in its header are 72 bytes long, the embedding table's included, and the two read in full say int8_tensorwise (read over HTTP range requests on 2026-09-22). kijai, a ComfyUI collaborator, replied on the issue: "This is most likely a corrupt/incomplete model file." So on this page's install, check the file's sha256 against the one in step 2 before suspecting ComfyUI.

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 specific to this card. A separate user report of faint banding at 25 steps, gone at 40, is under Quality notes (c); nothing establishes that it is the same artifact.

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

On the legacy loader ComfyUI asks for 7.031 GiB free before decoding at 2048×2048 and unloads weights to get it; on the default dynamic loader it reserves nothing and weights are evicted only when the decode's own allocations need the room (Results, item 3). On a real out-of-memory either one 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. For more margin, --vram-headroom 1 keeps an extra GiB free on top of both terms of the default loader's budget; --reserve-vram 1 raises only the capacity-based term. Closing whatever else holds VRAM (a browser with hardware acceleration counts) is worth more than any flag. Or render at 2 megapixels first.

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

Not the lead path here, since the int8 file is the template's own. But GGUFs appeared within hours, and two publishers disagree about which loader to use. city96's ComfyUI-GGUF, whose last commit is still 2026-01-12, passes a file whose general.architecture key is qwen_image straight to ComfyUI core; a file with no key at all goes down a compatibility path whose template list has no 2.1 entry. Read over HTTP range requests on 2026-09-22, Abiray/Qwen-Image-2.1-GGUF's Q8_0 declares qwen_image (3 metadata keys) and leejet/Qwen-Image-2.1-GGUF's Q8_0 declares none. leejet's fork adds the missing detection, and on 2026-09-21 it gained two more 2.1 fixes (one adds the qwen_image21 architecture name its own converter writes). On city96's own repo, PR #483, opened 2026-09-21, proposes the same detection; it was open and unmerged on 2026-09-22. A user on Abiray's discussion #1 posted this exact error without saying which file they loaded. Take a file that declares its architecture, or leejet's fork for files that do not. No GGUF run on this card turned up in the searches listed under Results; if you make one, report it via /contribute.

This is launch week, and the tracker moves by the hour. Report problems, or better a measured run on an RTX 4080, via the submission form.