Qwen-Image-2.1 on RTX 5080: the int8 ComfyUI template and the edit timings from a ComfyUI PR

What You'll Build

A ComfyUI graph on one RTX 5080 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 on 2026-09-22 from public sources. Every VRAM budget on it 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, against the capacity this card actually reports. Two different loaders live in that source, and each figure says which one it belongs to. The arithmetic settles one thing. The three template files together are bigger than this card, so the text encoder and the diffusion model take turns, and the encoder is what gives way every time the prompt changes.

Hardware data: RTX 5080 (16GB VRAM, compute capability 12.0) · not measured on this card: every budget here is derived, and the only timings are PR #16429's edit figures, from code that is not in v0.37.0 · the three template files total 16.096 GiB against the 15.894 GiB CUDA reports for this card on the recommended build on Windows (15.457 GiB in the one native-Linux log) · See benchmark data

ℹ️ Nothing on this page was measured on an RTX 5080 by this site. The site operator's two sessions for this model ran on a different card, an RTX 5060 Ti 16GB (raw data: cu130 session, cu128 session). This page uses them only for facts about the software and the files, never as a time or a memory figure for this card, and labels each use where it appears: what the cu130 warning costs the int8 path (Troubleshooting), how the w4a8 encoder changes the image and the size it stages at (Running; Troubleshooting, the #16443 entry), and which of the int8 and bf16 files was faster per step on cu130 (Results, item 4). Each is one rig, one operator, unreplicated. The two cards share an architecture and a VRAM size, and nothing on this page scales one card's timing to the other. The only timings that name an RTX 5080 are two image edits in PR #16429, run by that PR's author (Results).

The card. NVIDIA's RTX Blackwell architecture whitepaper (Appendix B) lists the RTX 5080 as a GB203 with 84 SMs, 16 GB of GDDR7 on a 256-bit bus at 30 Gbps for 960 GB/s, a 360 W total graphics power and a PCI Express Gen 5 interface; NVIDIA's CUDA GPU list puts it at compute capability 12.0. What matters for the budgets is the capacity CUDA reports, which is less than 16 GiB. ComfyUI prints it at startup as Total VRAM … MB, in MiB, from torch.cuda.mem_get_info (model_management.py). A search of the ComfyUI tracker returned twelve desktop RTX 5080 startup logs (2025–2026), nine in issue bodies and three in comments. Eleven are Windows installs, one of them apparently under WSL2 (#11428: its OS reads linux, but every model path is under /mnt/f/, WSL's mount of drive F:), and all eleven read Total VRAM 16303 MB, among them #15455 on the recommended build (ComfyUI 0.31.1, PyTorch 2.13.0+cu130). ComfyUI rounds that line to the nearest MiB. A report's system-stats block gives the exact figure as VRAM Total, read from the same call (server.py): 17,094,475,776 B = 15.920 GiB in seven RTX 5080 reports, #15455 among them. One more RTX 5080 report on the recommended build, #15968 (Windows, PyTorch 2.13.0+cu130, ComfyUI 0.33.0), reads 17,066,033,152 B = 15.894 GiB, 27 MiB less; it carries only the system stats, so the startup-line search misses it. The same 16,275 MiB reading appears on the RTX 5070 Ti, the same die, on this build (#16086, PyTorch 2.13.0+cu130). The twelfth log is native Linux: #8708's reporter writes that they are running Ubuntu, and their log (ComfyUI 0.3.42, PyTorch 2.7.1+cu126, an older build) reads Total VRAM 15828 MB, exactly 16,597,319,680 B = 15.457 GiB. The RTX 5070 Ti on native Linux reads 15,806 to 15,840 MiB (#10256, #14560), while that WSL2 log reads the Windows figure, so the gap appears to go with the native Linux driver rather than with the PyTorch build (an inference from these logs). The budgets below use 17,066,033,152 B = 15.894 GiB, the lower of the two Windows readings on the recommended build; on the higher one every margin is 28,442,624 B = 0.026 GiB wider. That basis is conservative for Windows only. On native Linux every margin below is narrower: by 468,713,472 B = 0.437 GiB where only the capacity differs, and by 154,140,672 B = 0.144 GiB on the legacy loader, whose Linux reserve is 300 MiB smaller. Each margin gives the Linux figure beside it; no conclusion changes. Whatever drives your display comes out of it too.

⚠️ 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. The repack's README, updated on 2026-09-22, says they "are for prompt enhancement, to be used with the TextGenerate -node." (README at 5dc5850e). On the repack's discussion #4 a user who put one in the text-encoder slot reports garbled images. If you do try them through TextGenerate, #16441 (open) reports a hard crash on the second generation inside one node execution, first on an RTX 5070 Ti (the same GB203 die as this card) with v0.37.0 and the Qwen3-VL encoder file, then reproduced by a second user on a 16 GB RTX 4060 Ti with the PE-I2I file. This page does not install them.

If you ran the 20B predecessor on this card, see Qwen-Image on RTX 5080. 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). This page pins that revision. The repo's head moved to 5dc5850e at 2026-09-22T13:06Z, and that commit changed only the README: every weight file has the same size and LFS sha256 at both revisions (tree API, read 2026-09-22).

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

min_vram_gb is 12. That is the smallest card size in this catalogue on which every stage of this install keeps its weights whole under both loaders, a derivation done on this model's RTX 3060 page. This page's own table agrees: the largest legacy stage at 1024×1024 is 9.899 GiB (Results).

Installation

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

Support is in ComfyUI core, not a custom node: PR #16400 by kijai, merged 2026-09-19T22:44Z as commit 6bfaacc67c. The TextEncodeQwenImage21 node is absent from that commit's parent and from tag v0.36.0, and present from 6bfaacc67c on. The first tag that contains it is v0.37.0 (commit 73c9bad4), 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 and was still the latest GitHub release at 20:50Z on 2026-09-22. A v0.37.1 tag was cut at 19:12Z that day (commit 3f767e7f67), with no release object or portable build behind it as of 20:50Z. Against v0.37.0 it adds three commits: Hunyuan Image 3.5 partner nodes (#16462), the workflow-templates pin raised from 0.11.66 to 0.11.68 (#16466), and the version bump. Nothing in it is for this model: the three Qwen-Image-2.1 template workflows are unchanged since 371a7b7171, the commit 0.11.66 already carried. Between templates 0.11.66 and 0.11.68, which add the Hunyuan Image 3.5 templates, the only changes that touch Qwen-Image-2.1 are translated titles and descriptions for its background-removal template (in scripts/data/i18n.json and eleven localized templates/index.*.json files) and a trailing comma after that template's name in bundles.json, where the new templates are appended. This page keeps v0.37.0, the latest release, as its floor. 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 whose timings were taken on an RTX 5080, and PR #16430, which compiles the transformer blocks. 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, and it is the number every capability check in ComfyUI reads. The CUDA version matters for a concrete reason in the source: comfy/quant_ops.py at the tag parses torch.version.cuda, and below 13 it switches off comfy-kitchen's CUDA kernels and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." The int8 model still runs without them, on a slower path (Troubleshooting). ComfyUI's maintainer put the support position plainly on #16455, about a cu128 install on an RTX 4090: "We do not support using cuda 12 on newer GPUs." requirements.txt at the tag pins comfy-kitchen==0.2.35, comfy-aimdo==0.5.5 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 on both Windows and Linux (setup.py), which covers compute capability 12.0.

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 Comfy-Org's bf16 file carries the same LFS sha256 (68bdc82b…) in the repack and in Comfy-Org/Qwen3-VL, a repository that predates this model. Qwen has not said so 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. Comfy-Org/Qwen3-VL (head 02f0d3ee) also holds an fp8_scaled 8B file (10,588,637,512 B = 9.861 GiB) and an nvfp4 one (6,305,221,764 B = 5.872 GiB). Read over HTTP range requests on 2026-09-22, both headers carry model.visual.deepstack_merger_list.0.norm.weight and the 8B merger width, so both take the same route by construction. Nobody has reported running either with 2.1: not in the 21 ComfyUI tracker threads that mention Qwen Image 2.1 (bodies and comments), and not in any of the 47 discussions on the vendor's repo and the repack (re-read 2026-09-22T17:15Z). There is also no reason to on this card. The encoder's format is a memory choice, not a speed choice (Troubleshooting, cu130 warning), and at 9.861 GiB the fp8 file is larger than the template's int8 one, while the nvfp4 file is nearly the size of Comfy-Org's w4a8 encoder (5.872 against 5.879 GiB, or 6,013.13 against 6,019.69 MiB), which sits in the same repo as the template.

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, and pytorch version: should end in +cu130. There should be no cu130 warning.
• 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.
• Total VRAM 16275 MB or 16303 MB on Windows, or 158xx MB on native Linux (15828 in #8708, the one RTX 5080 Linux log; Card, above), and DynamicVRAM support detected and enabled.
• When the diffusion model loads, Native ops: should list all seven quantisation formats (int8_tensorwise, convrot_w4a4, asym_w4a8_int8, nvfp4, mxfp8, float8_e4m3fn, float8_e5m2, in no fixed order) with no emulated ops part. At v0.37.0, get_disabled_quant_formats() in comfy/ops.py moves a format to emulated ops only when a capability check in model_management.py fails: supports_int8_compute() is true on any CUDA device, supports_fp8_compute() needs compute capability 8.9 or above (on 8.9 also PyTorch 2.3, or 2.4 on Windows), supports_nvfp4_compute() needs 10 or above, and supports_mxfp8_compute() needs 10 or above and PyTorch 2.10 or newer. On compute capability 12.0 with the portable's PyTorch 2.13 every one passes. An RTX 5080 log on the recommended build line, #15455 (Windows, ComfyUI 0.31.1, PyTorch 2.13.0+cu130), prints exactly that seven-format line. With PyTorch older than 2.10, mxfp8 alone moves to emulated ops, which does not matter here: the template's files use int8_tensorwise.

That Native ops line looks only at the GPU, so a cu128 install prints the same thing. The build shows up in the pytorch version and comfy_kitchen lines, which is why they come first. The Troubleshooting entry on the cu130 warning has what each of the two 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.

The template and the docs now agree. The first template commit, at 05:10Z on 2026-09-20 (templates 0.11.65), loaded the bf16 encoder, and commit #1277 at 12:56Z the same day (templates 0.11.66, which v0.37.0 pins) switched it to int8. The docs.comfy.org tutorial listed only the bf16 encoder until 2026-09-22T07:39Z, when Comfy-Org/docs #1744 synced it with the templates; its source now lists qwen3vl_8b_int8_convrot.safetensors as the one the templates load and the bf16 file as the full-precision alternative. If you followed the docs before that, you 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 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. Those figures depend on the files, not the card: the encoder stages at 8916 in #16441's log from an RTX 5070 Ti (the same die as this card), and the diffusion model at 6920 in #16437's.
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. How long that takes on this card has not been measured, and the two loaders move different amounts. On the default loader, making room frees the weights on the card without copying them anywhere, and bringing a model back reads it over the card's PCI Express Gen 5 link: from the model file when ComfyUI classifies the drive as fast storage (the log prints Model storage policy: fast_disk=True for each model), otherwise from pinned system RAM. On the legacy loader, unloading first copies the evicted weights back to system RAM (partially_unload() to the offload device, model_patcher.py), so an evict-and-reload crosses the link twice.

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"; the reply 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; on the legacy loader it becomes the largest single item ComfyUI reserves at 2048×2048, and on the default loader it reserves nothing (Results, item 3). No 2K run on an RTX 5080 turned up in the sources listed at the end of this page.

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, and sampling time grows with the step count. 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 on its outer node; 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. 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. Every prompt token adds 524,288 B more.

At v0.37.0, select_prefix_cache() in that file places the cache with the auto setting like this: on the GPU if four times its size is free at the moment of the check, else in system RAM under the same four-times rule, and otherwise it recomputes the prefix on every step. Four times the cache is 15.750 GiB at resolution 0 and 16.766 GiB at 1056, or 8.383 GiB with int8. With the diffusion model's weights on the card, no more than 17,066,033,152 − 7,256,783,064 = 9,809,250,088 B = 9.136 GiB of it can be free on Windows (8.699 GiB on native Linux), so in bf16 the GPU leg fails. With int8 at 1056 it could pass only if everything else on the card (the CUDA context, the display, the encoder's leftovers) took less than 17,066,033,152 − 7,256,783,064 − 9,000,976,384 (four times the int8 cache) = 808,273,704 B = 0.753 GiB at that moment on Windows (339,560,232 B = 0.316 GiB on native Linux). PR #16429's author describes the check as one that "gets disrupted by smart memory + dyn vram", since the dynamic loader keeps the card full of weights. So the RAM leg is what decides: it needs that four-times figure free in system RAM, on a machine that is also holding the staged weights.

PR #16429 shows both outcomes on this card, an RTX 5080 with 32 GB of RAM, running the old logic that v0.37.0 still has. A two-reference edit (580×1152 and 2048×1024, scaled up 1.3² in area, so more than twice the template's 8,064 reference tokens) fell back to full recompute; the same edit scaled down 0.6² went to pinned RAM. The timings are under Results. 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", and it halves the RAM the four-times rule asks for. 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 latest tag.

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

• The original reporter (mpbrewing, Apple MPS and CPU) finds broadband speckle when the grid comes out at exactly 1024: "Composition and identity are correct; only the rendering is degraded." 512, 992 and 1056 are clean. The reporter's follow-up makes the template affected: "the template's 0 is equally affected whenever the first reference image is 1024×1024".
• A second commenter, on an RTX 5070 Ti (the same GB203 die as this card; Windows 11, v0.37.0 tag, PyTorch 2.13.0+cu130, comfy-kitchen 0.2.35, comfy-aimdo 0.5.5, custom nodes disabled, the bf16 diffusion model with the int8 encoder, 25 steps) 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-22, with no fix on master. PR #16444, a first-time contributor's proposal to chunk the attention, 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. The w4a8 encoder from the same repo and revision (text_encoders/qwen3vl_8b_w4a8.safetensors, 5.879 GiB) lets the encoder and the diffusion model sit on the card together on paper (Results, item 2): download it and change only the CLIPLoader file name. It is Comfy-Org's own file, and stock ComfyUI loads it. Whether it saves time on this card has not been measured. The only timed run of it found is on a different card, the operator's RTX 5060 Ti on the cu128 install, where from the same seed it gave a clearly different composition, just as clean (one rig, one operator, unreplicated; cu128 session). In the sources this page searched (listed at the end), the one report of it in editing is most likely the master-branch crash under Troubleshooting (#16443): that report does not name its encoder file, but its log stages the encoder at exactly the size the w4a8 file stages at (the match is in that entry); at v0.37.0 the call at the top of that crash's stack runs only on cached steps, with no malloc-graph recording around it.

Why this page does not offer an NVFP4 diffusion model. Community NVFP4 builds of the diffusion model exist, for example BennyDaBall/Qwen-Image-2.1-NVFP4's 4,197,574,664 B file (3.909 GiB), whose header marks all 192 quantised layers nvfp4. Stock v0.37.0 has nvfp4 among its quantisation formats and runs it natively on compute capability 10 and up, so it would load on this card, and that publisher's PR #16432 reports those files running on stock ComfyUI master on an RTX 5090. On a 16 GB card it buys the same thing the w4a8 encoder buys, both models resident, and it gets there by requantising the diffusion model, the part that draws the image, with a third party's four-bit weights instead of shrinking the encoder with Comfy-Org's own file. No run of it on a 16 GB Blackwell card turned up in the sources listed at the end of this page or on the NVFP4 repos' own cards and discussions, and its speed against the int8 file on this card is unknown. The template's int8 files already run here, so the page stops at the w4a8 encoder.

Results

• Speed: no text-to-image timing on an RTX 5080 has been published in any source searched (listed at the end of this page, 2026-09-22). The only RTX 5080 timings are the two edits in PR #16429, from its author's own test on "Windows, RTX5080, 32GB RAM, fast disk", 25 steps, taken from the sampling progress bar only (not end to end). The two-reference edit scaled up 1.3² took 01:40 at 4.01 s/it before the change, which fell back to full recompute, and 00:24 at 1.02 it/s after it, with the prefix cache in RAM. The same edit scaled down 0.6² took 00:14 either way (1.74 and 1.76 it/s), once with the cache pinned in RAM and once in VRAM. Neither build is v0.37.0. The PR does not say which commit the "before" run used; its branch starts five commits before the tag, and the "after" code reached master two commits after it. The PR's text also does not say which diffusion-model or encoder files were loaded. What carries over to v0.37.0 is the logic, not the numbers: the tag still has the placement check the "before" run used (Running, Editing). These are edit figures for a larger edit than the template's, and they say nothing about text-to-image. A text-to-image run on this card is the most useful thing this page is missing: /contribute.

• VRAM usage: not measured on this card. 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 three replies by 2026-09-22, none from Qwen. What follows is derived, loader by loader, and every margin is given for both platforms: Windows, against the 15.894 GiB this card reports on the recommended build, and native Linux, against 15.457 GiB. The legacy loader's reserve also differs between them (below). A whole-card memory reading under the default loader would not settle it either: that loader fills the card with whatever weights fit, so the card reads nearly full whatever the job needs.

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

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

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

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

The other term adds aimdo's own usage to a headroom, 256 MiB by default, and compares the sum with the card's total capacity. --reserve-vram X sets only that second term's headroom; per aimdo's own docstring, raising it above 256 MiB is honoured and lowering it changes nothing. That threshold describes the Linux build; on Windows, where the live floor is 512 MiB, a value up to that changes nothing either. The live check stays either way. --vram-headroom X (default 0) is added on top of whichever term wins. So on this loader the card holds whichever weights are running plus their real activations, and pages the rest in from system RAM. The one fact the arithmetic settles is that 6.758 + 8.709 + 0.629 = 16.096 GiB of template weights cannot all be resident on this card's 15.894 GiB at once, before anything else takes its share: they are over by 17,283,091,112 − 17,066,033,152 = 217,057,960 B = 0.202 GiB on Windows (685,771,432 B = 0.639 GiB on native Linux).

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; on Windows it is 600 MiB plus 100 MiB more when the card's total is above 15 × 1024 MiB, which every Windows reading of this card's total (16,275–16,303 MiB) is, so 700 MiB (model_management.py).

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. The CUDA context and whatever drives your display come out of the card's capacity under either loader.

Four consequences of the arithmetic:

1. The int8 encoder and the diffusion model cannot both stay on the card, under either loader. The weights alone are 17,283,091,112 B = 16.096 GiB. On the legacy path, encoding leaves 17,066,033,152 − 10,943,795,019 = 6,122,238,133 B = 5.702 GiB on Windows (its row is 0.293 GiB higher) and 16,597,319,680 − 10,629,222,219 = 5,968,097,461 B = 5.558 GiB on native Linux, both less than the diffusion model's 6.758. Sampling leaves 8,044,454,737 B = 7.492 GiB on Windows and 7,890,314,065 B = 7.348 GiB on native Linux, both less than the encoder's 8.709 (8.109 + 8.709 = 16.818 GiB on the Linux rows). 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, 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, and this page does not carry it over.
2. Everything resident is possible on paper with the w4a8 encoder. The weights come to 14,244,398,116 B = 13.266 GiB, which leaves 2,821,635,036 B = 2.628 GiB of the card on Windows and 2,352,921,564 B = 2.191 GiB on native Linux for activations, the CUDA context, the display and aimdo's floor (256 MiB on Linux, 512 MiB on Windows, more if the WDDM-budget check binds first). On the legacy path the sampling stage with everything resident asks for 15,694,620,667 B = 14.617 GiB on Linux, leaving 902,699,013 B = 0.841 GiB of a native-Linux card, and 16,009,193,467 B = 14.910 GiB on Windows, leaving 1,056,839,685 B = 0.984 GiB. Tight on both. (The NVFP4 diffusion model with the int8 encoder would land in the same place, 13.247 GiB of weights; Running says why this page does not use it.)
3. At native 2K, on the legacy loader, the VAE decode reserve is the biggest item ComfyUI asks for. For this VAE, comfy/sd.py estimates decoding at 900 × h × w × 256 × 2 bytes over the latent grid: 1,887,436,800 B = 1.758 GiB at 1024×1024 (64×64 latents) and 7,549,747,200 B = 7.031 GiB at 2048×2048 (128×128). On the legacy path sampling at 2K grows only to 10.989 GiB on Linux (12,113,954,868 B = 11.282 GiB on Windows), 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, which leaves 16,597,319,680 − 15,901,470,352 = 695,849,328 B = 0.648 GiB of a native-Linux card, and 16,216,043,152 B = 15.102 GiB on Windows, which leaves 849,990,000 B = 0.792 GiB; whether the legacy loader then moves part of the diffusion model off the card depends on what the CUDA context and the display hold at that moment, which the arithmetic cannot know. On the default loader nothing is reserved. There the VAE is a dynamic model too: sd.py builds it with CoreModelPatcher, which main.py rebinds to ModelPatcherDynamic when DynamicVRAM is on, and #16437's log shows it staging as Model WanVAE prepared for dynamic VRAM loading. 644MB Staged. So every model in the call is dynamic, and free_memory() does not unload one dynamic model to make room for another (model_management.py). VAE.decode() in sd.py then uses the estimate only to choose how many images to decode per pass, and for one image that is always one. Whether a 2K decode on this card pushes diffusion-model weights off the card is decided by the decode's real allocations under aimdo's budget, and nobody has measured that. On a real out-of-memory, on either loader, the decode retries with tiled decoding. No 2K decode on an RTX 5080 turned up in the sources listed at the end of this page.
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, leaving 916,816,513 B = 0.854 GiB of a native-Linux card, and 15,995,075,967 B = 14.897 GiB on Windows, leaving 1,070,957,185 B = 0.997 GiB. The smaller test of whether it goes on the card whole is 15,508,704,475 B = 14.444 GiB on Linux, leaving 1,088,615,205 B = 1.014 GiB of a native-Linux card, and 15,823,277,275 B = 14.737 GiB on Windows, leaving 1,242,755,877 B = 1.157 GiB. Every prompt change then moves more than 16 GiB of weights through system RAM. On the default loader it runs on a 16 GB GB203 card: #16435's RTX 5070 Ti commenter ran the edit template with it on v0.37.0, cu130, up to resolution 2048, with no memory figure or timing given. Which of bf16 and int8 is faster on this card has not been measured. On the operator's RTX 5060 Ti, a different Blackwell card, int8 was the faster file per step on the cu130 portable (one rig, one operator, unreplicated; cu130 session); that ordering is not a figure for this card. The template loads the int8 file by default, and this page follows it.

• Quality notes: Users report a visible grid at high resolution and blame the VAE. On the vendor's discussion #12 a user posting as Rkss, crediting the example image to another user, writes "It's more noticeable when you generate a high-resolution image that has people with light skin tones and zoom in on their faces." The same user describes an encode→decode round trip through the VAE, with no diffusion model involved, as the way to show it, without posting the result of one; another commenter there argues that a similar stripe pattern in a different model came from its diffusion model. 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. Separately, on the repack's discussion #11 (2026-09-22) a user posting as Xenodermus reports faint banding on skin, fabric and fur at the template's 25 steps and 1024×1024, the same with the int8 and bf16 files and with the simple and normal schedulers, and writes of raising the steps to 40: "Artifact disappeared completely at 40." The first reply (18:01Z) posts a different, two-sampler workflow without addressing the cause. At 22:11Z the original poster wrote that with that 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, 40 steps or that workflow with a milder prompt. It is one thread, with no reply from a Comfy-Org member as of 2026-09-23, and it is not established whether this is the same artifact. Neither thread names hardware. No image made on an RTX 5080 has been compared for this page.

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

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

Your PyTorch is a CUDA 12 build. Fix it: the torch line in step 1, or the v0.37.0 portable, which ships the cu130 build. What the warning costs has not been measured on this card. On a different card, the operator's RTX 5060 Ti 16GB, the same template took 21.4 s from a cold start on the v0.37.0 cu130 portable against 69.4 s on a Comfy Desktop install that printed this warning (one rig, one operator, unreplicated; cu130 session, cu128 session). That is one install against another, not one flag flipped, and it is a 5060 Ti's time, not this card's. It is enough to say the gate is worth checking. On a second 5060 Ti, a user on a cu128 portable reports in #16470 that the int8 file ran slower than a Q8 GGUF at about 4 MP, with other settings in play too (a hard disk, sage attention, fp16 accumulation). kijai, a ComfyUI collaborator, answered that report on 2026-09-22: "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 (step 3) comes from the GPU checks alone, 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. 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 the NVFP4 encoder in that PR: "The weights are dequantized for encoding rather than using native NVFP4 matrix multiplication." Net effect of the warning: fused kernels lost on the diffusion model, nothing lost on the encoder.

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. How long that takes on this card has not been measured. If prompt changes feel slow, in order:

1. Check step 3's log lines. A cu128 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 w4a8 encoder under Running makes both models fit on paper; whether that saves time on this card is unmeasured.

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, the same die as this card). Disconnecting the VAE from TextEncodeQwenImage21 also removed the speckle in both reports, 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), the path PR #16429's "before" run took on this card. 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 image editing (img-to-img). 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." Read in full at 14:35Z on 2026-09-22, the thread now says more. Both people in it have an RTX 5060 Ti 16 GB, neither has seen text-to-image crash, and both see the crash only when editing, and only some of the time. The second user (10:27Z) says it crashed as soon as the edit resolution went above 1 MP; the reporter (14:08Z) says the crashing workflow feeds two inputs of roughly 1500×1000, and that since switching to smaller inputs it has not crashed so far. The reporter also launched with --cuda-device 0 to force a single GPU and still got the crash, which rules out the second card as the trigger in that setup. Neither gives a ComfyUI commit. The reporter's log stages its encoder at 6,018 MiB, which is what Comfy-Org's w4a8 file stages as: the operator's cu128 session logged 6018MB Staged for it (one rig, one operator, unreplicated; cu128 session), and Comfy-Org's nvfp4 8B file, at 6,013 MiB on disk, is too small to stage that. So the reporter was most likely running the w4a8 encoder that Running offers for keeping both models on the card. The stack ends in the prefix cache's take → prefetch at qwen_image21/model.py line 353, which is cache.take on master (head b33e2b55 on 2026-09-22) and unrelated code at v0.37.0, where the call runs only on cached steps. 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", which is where a large edit goes on a 16 GB card (Running, Editing). No report names an RTX 5080. If you hit this on master, go back to v0.37.0 (git checkout v0.37.0, or update_comfyui_stable.bat on the portable).

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_*. 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.

Expecting value: line 1 column 1 (char 0) while the encoder loads

Reported once, in #16472, on an AMD Radeon 890M integrated GPU with 7.8 GB of system RAM, loading the template's int8 encoder. The open PR #16474 attributes it to a layer whose quantisation marker is present but empty. kijai, a ComfyUI collaborator, replied on the issue: "This is most likely a corrupt/incomplete model file." None of the 21 tracker threads read for this page reports it on NVIDIA, and the same file loads on a GB203 card in #16441's RTX 5070 Ti log (8916MB Staged). Check the file's sha256 against step 2 before anything else.

Grid or moiré on skin at 2K

Discussion #12 (Results, Quality notes) points at the VAE, and the mitigations named there are post-processing or re-encoding through another VAE. One user on the repack's discussion #11 reports that banding at the template's 25 steps went away at 40 steps, which costs sampling time in proportion; it is a single report. Nothing in either thread is 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 (Results, item 3), which with the diffusion model resident leaves 0.792 GiB of this card on Windows (700 MiB reserve) and 0.648 GiB on native Linux (400 MiB reserve), so it moves diffusion-model weights off when the context and the display need more than that. On the default loader it reserves nothing and pages weights on demand, and how much a 2K decode actually needs on this card has not been measured. On a real out-of-memory either loader 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 files already run on this card. But GGUFs keep appearing, and their loaders disagree, so here is what the files and the loaders say on 2026-09-22.

• city96's ComfyUI-GGUF is still at its 2026-01-12 head. It 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. A community pull request to add one, city96/ComfyUI-GGUF#483, is open and unmerged.
• Headers read over HTTP range requests on 2026-09-22: Abiray/Qwen-Image-2.1-GGUF's Q4_K_M declares qwen_image (3 metadata keys), so city96's node takes it. leejet/Qwen-Image-2.1-GGUF's Q4_K and unsloth/Qwen-Image-2.1-GGUF's Q4_K_M carry no metadata keys at all, so city96's node sends them down the compatibility path, which ends in this error. unsloth's card points readers to stable-diffusion.cpp rather than ComfyUI.
• leejet's fork added the missing template on 2026-09-20 and two more fixes on 2026-09-21 (cee9bb15, which adds qwen_image21 to the accepted architectures, and a dequantisation fix for 1-D tensors). leejet's files need it.

No GGUF run on this card turned up in the sources listed below. If you need one, take a file that declares its architecture, or leejet's fork for the metadata-free ones, and report back via /contribute.

Those are the reports found for this model on 2026-09-22: the 21 ComfyUI tracker threads and pull requests created since 2026-09-18 that mention Qwen Image 2.1 (bodies and comments), every issue created since then searched for "5080", the 47 discussions on the vendor's repo and the Comfy-Org repack as of 17:15Z (48 by 18:51Z; the new one names no card), the 194-comment Hacker News launch thread and Civitai's 2.1 listings; r/StableDiffusion and r/comfyui refused this session. The only RTX 5080 figures among them are PR #16429's. This is launch week, and the tracker moves by the hour. Report problems, or better a measured run on this card, via the submission form.