Qwen-Image-2.1 on RTX 5060 8 GB: Which Stages Fit, What Streams, and the NVFP4 Swap

What You'll Build

A ComfyUI graph on one RTX 5060 8GB that turns a prompt into a 1024×1024 image — with a real alpha channel if you ask for one — using Qwen-Image-2.1, a 7B single-stream diffusion transformer behind a Qwen3-VL-8B text encoder and a 64-channel RGBA autoencoder, released 2026-09-20 with support in ComfyUI core. Editing from reference images works on this card too, with two caveats covered under Running.

This page was written the day after release, entirely from public sources. Nothing on it was measured on this card, and no measurement on any 8 GB card turned up in the searches listed under Results. Every VRAM figure below is arithmetic over byte counts from the Hugging Face tree API and constants read out of ComfyUI's source at tag v0.37.0, and each one is labelled as derived.

The short version of that arithmetic: on 8 GiB the question is not whether it runs — ComfyUI's default loader keeps whatever does not fit in system RAM and pages it in as needed — but which files keep each stage on the card. Swap the template's text encoder for the smallest one in the Qwen-Image-2.1 repack and the encode stage fits. The official int8 diffusion model is then borderline: under the default loader its weights plus the 0.250 GiB that loader keeps free leave 0.992 GiB of the nominal 8 GiB for the driver, the display and sampling's working memory, and nobody has shown whether that is enough; under the legacy loader it does not fit. A community NVFP4 build of the same model — a format this card executes natively — fits under either loader, with 3.841 GiB left on paper under the default one.

⚠️ Read the licence before you download 14.24 GB. Qwen-Image-2.1 ships under a non-commercial licence. The Qwen Research License Agreement defines Non-Commercial in §1.i as "for research or evaluation purposes only" and grants its rights in §2.a "FOR NON-COMMERCIAL PURPOSES ONLY"; §2.b routes commercial use to a separate licence request. There is no territory clause — the grant in §2.a is worldwide, and §4.a is an export-controls reminder rather than a geographic exclusion. §4.b reaches past the weights: if you train or fine-tune a model you distribute on this model's outputs, "you shall prominently display “Built with Qwen” or “Improved using Qwen” in the related product documentation". The Comfy-Org repack and every community quantisation below inherit these terms. This is a reader's summary of the text, not legal advice.

Hardware data: RTX 5060 (8GB VRAM, Blackwell, compute capability 12.0) · largest resident stage of the recommended setup: the w4a8 encode, 6.129 GiB under ComfyUI's default DynamicVRAM loader (7.069 GiB under the legacy loader), derived, not measured · See benchmark data

Requirements

The compute capability is NVIDIA's own figure: the CUDA GPUs table lists the GeForce RTX 5060 under 12.0.

The files, byte-exact from the Comfy-Org repack at revision ace0edeb3791a594ddfa36ed5f41a178a394e921 and from the two community repositories this page offers as alternatives:

Comfy-Org ships no official fp8 or NVFP4 build of the diffusion model: the repack's recursive tree lists exactly two files under diffusion_models/, the bf16 and the int8 above.

The arithmetic, stage by stage — and which loader it describes

A single-image run is three stages — encode, sample, decode — that take turns on the card rather than sharing it. How much room each one needs depends on which of ComfyUI's two loaders is managing it, and the two keep very different margins.

DynamicVRAM — the default on this card. At v0.37.0, main.py turns it on whenever the device is NVIDIA, PyTorch is 2.8 or newer and the comfy-aimdo package initialises; the startup log then prints DynamicVRAM support detected and enabled. Weights are staged from system RAM, loaded on demand and evicted when an allocation needs the room. There is no fixed reserve: comfy-aimdo 0.5.5, the version v0.37.0 pins, keeps VRAM_HEADROOM — 256 MiB, 0.250 GiB — free as measured live by cuMemGetInfo (src/plat.h#L145-L146, src/control.c#L174). ComfyUI's own reserve and per-model estimates do not decide residency here: ModelPatcherDynamic.partially_load() never uses the memory budget it is handed (comfy/model_patcher.py#L2147-L2159), and the comment on its estimate says that when every model is dynamic "this is ignored and its all done dynamically." (#L1840-L1843).

Legacy estimate-based loading is what you get with --disable-dynamic-vram (or --highvram, --gpu-only, --novram, --cpu). It also governs the GGUF diffusion model in either mode, because city96's GGUFModelPatcher subclasses ComfyUI's plain ModelPatcher, which reports itself as non-dynamic (nodes.py#L35). Here the reserve is minimum_inference_memory() in comfy/model_management.py: (1024 * 1024 * 1024) * 0.8 plus EXTRA_RESERVED_VRAM, 400 MiB on Linux — 1.191 GiB in all. That is the reserve at 1024²; for sampling, load_models_gpu() takes the larger of it and the model's own activation estimate plus EXTRA_RESERVED_VRAM, and at 2048² the estimate wins — 2.311 GiB for this model. A model that does not fit under that line is partly loaded and the rest streamed.

Linux, 1024², vs 8 GiB       weights  DynamicVRAM (+0.250)          legacy (+1.191)
encode  qwen3vl_8b_w4a8        5.879   6.129   1.871 left            7.069   0.931 left
encode  qwen3vl_8b_int8_conv   8.709   weights alone exceed the card — streams under either loader
sample  int8_convrot DiT       6.758   7.008   0.992 left, borderline 7.949   0.051 left → streams
sample  NVFP4 DiT              3.909   4.159   3.841 left            5.100   2.900 left
sample  GGUF Q6_K              5.473   —  (GGUF is always legacy)     6.664   1.336 left
decode  VAE, 1024²             0.629   + ComfyUI's decode estimate 1.758 = 2.387

Both loaders measure against free VRAM, not capacity. comfy-aimdo polls cuMemGetInfo; the legacy loader's get_free_memory() reads torch.cuda.mem_get_info(). Either way the driver, the CUDA context and any display surface have already taken their share, and nothing on this page knows how large that share is on your machine.

That is why the int8 diffusion model is marked borderline rather than streaming. Under DynamicVRAM, 6.758 GiB of weights plus aimdo's 0.250 GiB leaves 0.992 GiB of the nominal 8 GiB for the driver, the display and sampling's own working memory. Whether that is enough for the whole model to stay on the card is not established either way — no one has published a run on an 8 GB card. If it is not, the part that does not fit is paged in from system RAM as it is used, which costs time, not the image. Under the legacy loader the answer is settled: 0.051 GiB on paper, less than nothing once the driver has its cut, so part of it streams on every step. On paper the NVFP4 build and the w4a8 encoder each fit under either loader; the template's int8 encoder fits under neither.

On Windows the margins are larger. The legacy reserve uses 600 MiB instead of 400 (the extra 100 MiB in that block applies only above 15 GiB, so not to this card): 1.386 GiB, which puts the int8 sampling stage at 8.144 GiB, over the card. comfy-aimdo on Windows keeps 512 MiB below the budget WDDM grants the process — which can sit below physical VRAM — and, with NVML pressure on (the default), 512 MiB of free VRAM by NVML (src-win/shmem-detect.c#L105-L107). That is 0.500 GiB instead of 0.250, so the int8 DiT has 0.742 GiB left on paper, before a desktop that Windows is also drawing on this card.

Neither diffusion model co-resides with the encoder. int8 DiT plus w4a8 encoder is 12.637 GiB of weights; NVFP4 plus w4a8 is 9.788 GiB. Under DynamicVRAM, free_memory() deliberately does not unload one dynamic model for another (comfy/model_management.py#L912-L916); on a prompt change the encoder's weights are paged in as encoding runs and the diffusion model's are evicted as that needs the room, then the reverse. Under the legacy loader the same exchange happens as partial or whole-model unloads. Re-running with only the seed changed skips it, because the conditioning is cached. The issue #16437 reporter describes the same exchange on a 16 GB AMD card, where the int8 pair "cannot co-reside" either.

The decode estimate is ComfyUI's, and it is conservative. For this VAE, comfy/sd.py budgets memory_used_decode = 900 × h × w × 256 × dtype_size over the latent grid: 64 × 64 at 1024² gives 1.758 GiB in bf16. Under the legacy loader ComfyUI frees that much before decoding, unloading the diffusion model if it must. Under DynamicVRAM the estimate only sizes the decode batch; the diffusion model's weights are evicted when the decode's allocations need the room.

Activations are small at 1024² and not at 2048². The largest single intermediate in a block is the fused MLP's gate_up output, 24,576 features wide (read from the GGUF header's tensor shapes): 4,096 image tokens × 24,576 × 2 bytes = 0.1875 GiB at 1024². At 2048² it is 16,384 tokens and 0.75 GiB. That is one tensor, not a peak — but it is why the int8 DiT's 0.992 GiB above is borderline at 1024² and clearly short at 2048². Attention adds little: build_sequence gives only text segments a causal mask, and image segments reach attention with mask=None, so no sequence-squared mask is built.

What else DynamicVRAM changes on an 8 GB card

• --lowvram does nothing here. Its help text in comfy/cli_args.py says "Doesn't do anything if dynamic vram is enabled."
• The text encoder runs on the GPU. text_encoder_device() returns the GPU whenever DynamicVRAM is on (PR #16374, in v0.37.0). If you would rather it never touched the card, the CLIPLoader node's advanced device input accepts cpu — expect a slow encode.
• Running out of margin is designed to cost time, not the image. A tight stage means more of it streams; neither loader refuses a model for being larger than free VRAM.

Installation

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

Qwen-Image-2.1 support is in ComfyUI core — PR #16400 by kijai, merged 2026-09-19T22:44Z — and tag v0.37.0 (commit 73c9bad4) is 8 commits ahead of that merge with none behind, so it is the floor. A GitHub release now exists for it: v0.37.0 was published 2026-09-21T07:35Z with Windows portable assets, including ComfyUI_windows_portable_nvidia.7z, which the v0.37.0 README describes as shipping Python 3.13 and PyTorch built for CUDA 13.0. Earlier reports on the repack's discussion #1 that only 0.36.0 was available predate that release. I could not confirm a Desktop build carrying 0.37.0; if you use Desktop, check that TextEncodeQwenImage21 exists before downloading anything.

This page installs the v0.37.0 tag, and every ComfyUI code reference on it is to that tag. Current master is v0.37.0 plus five commits, two of which touch this card: PR #16430 compiles the transformer blocks, and its author (rattus128, a repository contributor) writes that "Some users in specific conditions (slow PCIe bus, disk offload) will have considerable speedup when offload is the bottleneck." — which is the int8 diffusion model's situation here if it turns out not to fit. PR #16429 changes where the edit path's K/V cache may live (see Editing). git checkout master instead of the tag is a reasonable choice for either reason; neither change has been timed on an 8 GB card. One caveat if you take master and edit images: open issue #16443 reports a hard abort in the prefix-cache copy path, and open PR #16450 blames the allocation-recording wrapper that #16430 put around the block loop — code that exists only on master, runs whenever DynamicVRAM is on with CUDA, and is reached when the edit cache sits in system RAM, which is where this card puts it (see Editing). The evidence is one report from a Windows machine with two GPUs, where ComfyUI's default — it forces single-GPU mode on Windows unless told otherwise (main.py#L46-L53) — would have run on one of them; the cause is unconfirmed and the proposed fix has no maintainer review; the v0.37.0 tag does not have that wrapper.

The CUDA version is a hard gate in comfy/quant_ops.py: below CUDA 13 it disables comfy-kitchen's CUDA backend and logs "WARNING: You need pytorch with cu130 or higher to use optimized CUDA operations." The official int8 and the NVFP4 diffusion models are formats that backend accelerates (the GGUF build is dequantised by its own custom node instead, and the text encoders are a different case, covered in step 2), so install the cu130 stack last, after requirements.txt, so nothing resolves a different wheel over it:

The shell blocks on this page are for Linux (bash or zsh). Windows users should take the v0.37.0 portable and follow the separate Windows block after step 3.

export COMFY="$HOME/ComfyUI"    # absolute path; in any new shell, run this line again first
git clone https://github.com/Comfy-Org/ComfyUI.git "$COMFY" && cd "$COMFY" && \
  git checkout v0.37.0 && \
  python3 -m venv .venv && source .venv/bin/activate && \
  pip install -r requirements.txt && \
  pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
    torch torchvision torchaudio && \
  python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.get_device_capability())"

The last line must print a CUDA version starting 13 and (12, 0). For master instead of the tag (it adds #16429 and #16430, and the edit-path caveat above), replace v0.37.0 with master. If ~/ComfyUI already exists, git clone fails and nothing after it runs: either point COMFY at a new folder, or replace git clone https://github.com/Comfy-Org/ComfyUI.git "$COMFY" && cd "$COMFY" && with cd "$COMFY" && git fetch --tags && and run the rest of the chain unchanged. Every later block starts with cd "${COMFY:?…}" && source .venv/bin/activate && … as one chained command: if COMFY is unset the whole block stops with a message instead of silently installing into the system Python or downloading to /models.

2. Download the official files — with the smaller encoder

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  pip install -U huggingface_hub && \
  hf download Comfy-Org/Qwen-Image-2.1 \
    vae/qwen_image_2.1_vae_bf16.safetensors \
    text_encoders/qwen3vl_8b_w4a8.safetensors \
    diffusion_models/qwen_image_2.1_int8_convrot.safetensors \
    --local-dir "$COMFY/models"

The repack's folder layout matches ComfyUI's, so the three files land in models/vae/, models/text_encoders/ and models/diffusion_models/. The template's own encoder, qwen3vl_8b_int8_convrot, is left out on purpose: at 8.709 GiB it is larger than the card, so it could only ever stream.

Why the smallest encoder costs you nothing in speed: at v0.37.0 every quantised text encoder is dequantised matrix by matrix for encoding — the text-encoder layers are built with mixed_precision_ops(..., full_precision_mm=True) in comfy/sd1_clip.py, and the context that switches quantised matmul back on is used only for text generation, not for conditioning. So the encoder's format is a memory choice, not a compute choice, and on an 8 GB card memory is the only thing that matters. PR #16432, open and unmerged, proposes changing that for NVFP4 encoders.

A note on encoder identity, because it explains why swapping is safe. The bf16 encoder in this repack has the same LFS sha256 (68bdc82b…12669a9) as the file of the same name in Comfy-Org/Qwen3-VL, uploaded there on 2026-06-06 — three months before Qwen-Image-2.1's weights existed — and two users on the model's discussion #5 report comparing tensors against stock Qwen3-VL-8B-Instruct and finding no retraining. ComfyUI picks the Qwen-Image-2.1 encoder path from the tensors present, not from the filename — it keys on the vision tower's DeepStack weights (comfy/sd.py#L1707-L1708) and then on type: qwen_image (#L1955-L1958) — so any complete 8B Qwen3-VL build, vision tower included, in a format it loads takes the same path. No side-by-side comparison of the w4a8 and int8 encoders' output turned up. The w4a8 file is the smallest encoder in the Qwen-Image-2.1 repack; Comfy-Org/Qwen3-VL also carries qwen3vl_8b_nvfp4.safetensors at 6,305,221,764 B, 6.9 MB smaller, whose header includes the vision tower and so takes the same path — at v0.37.0 both are dequantised for encoding, so the difference does not matter here.

3. Optional — a diffusion model that fits with room to spare

Two community builds bring the diffusion model well under the card's budget. Both are a day old, both inherit the research licence, and neither has been run on an 8 GB card by anyone who published the result. Fitting is not the same as being faster, and the two differ on that: see the GGUF paragraph.

NVFP4 (Blackwell-native). On this card ComfyUI treats NVFP4 as a native format: supports_nvfp4_compute() in comfy/model_management.py returns true for compute capability 10 and up, and comfy-kitchen 0.2.35 — the version v0.37.0 pins — ships a CUDA scaled_mm_nvfp4 kernel. BennyDaBall's file declares nvfp4 in its per-layer comfy_quant metadata (read from the safetensors header), was converted from the Comfy-Org bf16 at the same revision this page pins, and its uploader validated it only on an RTX 5090. Take the diffusion model only; its NVFP4 encoder is 7.031 GiB, larger than the w4a8 one, and its README says it needs an extra runtime patch to run the encoder's matrix multiplies in FP4.

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  hf download BennyDaBall/Qwen-Image-2.1-NVFP4 \
    diffusion_models/qwen_image_2.1_nvfp4.safetensors --local-dir "$COMFY/models"

A second NVFP4 build of the same size, pottokao/Qwen-Image-2.1-DiT-NVFP4-ComfyUI, reports loading in ComfyUI and a run on a GB10; its encoders are refusal-ablated derivatives, not the stock model.

GGUF (any NVIDIA architecture). Abiray's files are made for city96's ComfyUI-GGUF, which dequantises on the fly; that they load there is a reading of the loader code below, not a run. Because that node's patcher is non-dynamic, the legacy column above applies: Q6_K leaves 1.336 GiB on paper; Q8_0 (7.070 GiB) does not fit. Resident does not mean faster. ComfyUI's own startup warning, printed when you pass --disable-dynamic-vram, advises GGUF users to keep it on and use native formats, because "ComfyUI native formats like fp8, int8 and w4a8 will be faster even if they are larger than your memory." (main.py#L569-L576). That is the ComfyUI team's general claim, not a measurement of this model, but it is a reason not to assume Q6_K beats the int8 build on this card.

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  git clone https://github.com/city96/ComfyUI-GGUF custom_nodes/ComfyUI-GGUF && \
  pip install -r custom_nodes/ComfyUI-GGUF/requirements.txt && \
  hf download Abiray/Qwen-Image-2.1-GGUF qwen_image_2.1_Q6_K.gguf --local-dir "$COMFY/models/unet"

Why these files and not leejet's: read over an HTTP range request, Abiray's GGUF header declares general.architecture = qwen_image, which is in city96's IMG_ARCH_LIST, and its tensor names carry every key ComfyUI v0.37.0 uses to recognise Qwen-Image-2.1 (comfy/model_detection.py). leejet's files are stable-diffusion.cpp conversions whose header has no metadata keys at all; city96's loader then guesses the architecture from tensor names and knows no Qwen-Image layout, so they need leejet's fork, which adds exactly that one template. The two publishers' cards disagree about loaders because each is right about its own files. This is a reading of the loader code, not a run.

The GGUF route still needs the Comfy-Org w4a8 encoder from step 2. The official Qwen/Qwen3-VL-8B-Instruct-GGUF encoder does not substitute: its language-model file carries no vision tensors (399 tensors, i.e. 36 layers × 11 plus 3 — the vision tower ships as a separate mmproj file), city96's text-encoder loader grafts an mmproj only for qwen2vl files (loader.py#L501), and without vision tensors ComfyUI classifies the file as a text-only Qwen3-8B and routes it to a different model's encoder class (comfy/sd.py#L1919-L1924). Again a reading of the code, not a run.

Windows: the v0.37.0 portable

The v0.37.0 release's ComfyUI_windows_portable_nvidia.7z already carries a cu130 PyTorch, so step 1 does not apply. There is no .venv and no hf on the PATH: use the interpreter the portable ships, python_embeded\python.exe — the same one its run_nvidia_gpu.bat starts ComfyUI with — and run these in Command Prompt (cmd.exe, not PowerShell) from the portable's top folder, the one that holds python_embeded and ComfyUI. The official files (step 2):

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 vae/qwen_image_2.1_vae_bf16.safetensors text_encoders/qwen3vl_8b_w4a8.safetensors diffusion_models/qwen_image_2.1_int8_convrot.safetensors --local-dir ComfyUI\models

Optional (step 3), the NVFP4 diffusion model:

python_embeded\python.exe -s -m huggingface_hub.cli.hf download BennyDaBall/Qwen-Image-2.1-NVFP4 diffusion_models/qwen_image_2.1_nvfp4.safetensors --local-dir ComfyUI\models

Optional (step 3), the GGUF route, which needs git on the PATH:

git clone https://github.com/city96/ComfyUI-GGUF ComfyUI\custom_nodes\ComfyUI-GGUF
python_embeded\python.exe -s -m pip install -r ComfyUI\custom_nodes\ComfyUI-GGUF\requirements.txt
python_embeded\python.exe -s -m huggingface_hub.cli.hf download Abiray/Qwen-Image-2.1-GGUF qwen_image_2.1_Q6_K.gguf --local-dir ComfyUI\models\unet

-m huggingface_hub.cli.hf is the module behind the hf command, and it runs directly because cli/hf.py ends in a __main__ guard. The GGUF git clone and pip lines are the ones city96's README gives for the portable.

Running

Text to image

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && python main.py

On the Windows portable, double-click run_nvidia_gpu.bat in its top folder, which runs python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build.

Before loading anything, read the startup log for three things: no cu130 warning; the comfy-kitchen line Found comfy_kitchen backend cuda: showing 'disabled': False — not merely 'available': True, because the cu130 gate calls registry.disable("cuda"), which comfy-kitchen's registry reports as 'disabled': True while 'available' can stay True; and DynamicVRAM support detected and enabled. When a quantised model loads you will also see a Native ops: line. On this card it lists every format with no emulated ops suffix — but that line reports ComfyUI's device check (comfy/ops.py#L1710-L1745), not the kernel backend, so a cu128 install prints the same line while running everything through comfy-kitchen's slower pure-PyTorch fallback. The cu130 warning is the one that tells you.

Then open the Templates panel and load Qwen Image 2.1: Text to Image (under Image). The bundled template is image_qwen_image_2_1_t2i.json from workflow templates v0.11.66, which is the version v0.37.0's requirements.txt pins. Its subgraph node exposes unet_name, clip_name and vae_name directly:

• set clip_name to qwen3vl_8b_w4a8.safetensors — the one change this card needs;
• leave unet_name on qwen_image_2.1_int8_convrot.safetensors, or pick qwen_image_2.1_nvfp4.safetensors if you downloaded it;
• keep the template's defaults: 25 steps, cfg 1, euler, simple, 1024×1024 from the ResolutionSelector.

The template's own notes say the official pipeline uses 40–50 Euler steps and that the negative prompt is unused while cfg is 1. For the GGUF build, load Abiray's included Qwen_Image_2.1_GGUF_Text2Image.json instead, or unpack the subgraph and replace UNETLoader with Unet Loader (GGUF).

Transparent images. The vendor's GitHub README gives this prompt format, and the template saves 8-bit PNG so the alpha channel survives:

This is an RGBA image with transparency. <your description>. The image has alpha channel and the background is transparent.

2048×2048 on this card is unmeasured. Set the ResolutionSelector to 1:1 and 4 megapixels. With the NVFP4 build the sampling stage fits on paper under either loader — 4.159 GiB under the default one plus a gate_up intermediate of 0.75 GiB, or 6.220 GiB under the legacy one, whose sampling reserve at 2048² is 2.311 GiB — but ComfyUI's decode estimate at a 128 × 128 latent is 7.031 GiB, more than the card has. If the real decode does not fit, comfy/sd.py catches the out-of-memory error, logs Warning: Ran out of memory when regular VAE decoding, retrying with tiled VAE decoding. and finishes tiled. With the int8 build, 2K is where borderline turns into streaming: that 0.75 GiB intermediate alone takes most of the 0.992 GiB the default loader leaves beside its weights.

Editing

Load Qwen Image 2.1: Image Edit from the same panel, set its clip_name to the w4a8 encoder as above, and mention references in the prompt as <image1>, <image2> and so on. Two things to know on this card:

• Some reference sizes render as noise, and the two reports disagree on which. The shipped edit template sets the encoder's resolution to 0 on its outer node — its note says "This template starts at 0: no resize beyond a multiple of 32." — so a reference keeps its own size, rounded to a multiple of 32. Issue #16435 holds two community reports with the VAE connected. On Apple MPS and on CPU, the original reporter measures broadband noise when the reference's grid is 64 × 64 — a 1024-pixel square reference at resolution=0, or resolution=1024 — and clean output at 992 and 1056 (follow-up). On CUDA, a second report (comment; RTX 5070 Ti, the v0.37.0 tag, torch 2.13.0+cu130) finds that same 1024×1024 reference clean, but a 1536×1024 reference (grid 96 × 64) broken — over-sharpened, speckled, and with the edit instruction ignored — both at resolution=0 and at 1248, which resolves to the same size; 512, 1024, 1056 and 2048 were clean. Its conclusion is that "the trigger is the resolved grid, not the parameter value or the code path that produced it". The same commenter notes that both failing grids, 4,096 and 6,144 tokens, are multiples of 2,048 — an observation, not a confirmed cause. The two reports also differ in backend, operating system, build, attention path, encoder precision, reference image and step count, so backend is one possible explanation for their disagreement, not an established one. Two settings were clean in both reports, resolution = 1056 and 512; use 1056 rather than the template's 0, since 512 shrinks the reference. Disconnecting vae from TextEncodeQwenImage21 also avoids it, at the cost of much weaker adherence to the reference, per both reports. A proposed fix, PR #16444, is currently marked draft by its author; it comes from a first-time contributor, and its own description says full-model reproduction was unavailable, so it has only been checked by unit tests.
• The prefix K/V cache will not fit in VRAM. Edits cache the text-and-reference K/V across steps; per the select_prefix_cache code in model.py the cost is 2 × 32 blocks × tokens × 4,096 × 2 bytes, so one 1024² reference's 4,096 tokens alone add 2.000 GiB. At v0.37.0, in auto mode, it goes to the GPU only when free VRAM exceeds four times that, otherwise to system RAM under the same condition, otherwise it is recomputed every step — so at the default dtype the GPU is ruled out on this card. The Qwen Image 2.1 Cache node's dtype set to int8 halves it (1.000 GiB, so the GPU test needs more than 4 GiB free) and int4 quarters it (0.500 GiB, just over 2 GiB free — which the NVFP4 build leaves on paper). On master, PR #16429 rewrote both tests: the GPU test counts memory the dynamic loader could evict, and the RAM test becomes a pinned-memory budget check at one times the cache size rather than four times free RAM. There the smaller caches will take the GPU more readily, at the cost of evicting diffusion-model weights; the default-dtype cache still cannot, because four times 2.000 GiB is more than the card.

Qwen also ships two prompt-enhancer models beside this one; they rewrite prompts in a separate LLM step and are not text encoders, so do not load them in CLIPLoader.

Results

• Speed: omitted. No published timing on an RTX 5060, or on any 8 GB card, surfaced in the searches below. The named-GPU timings that do exist are on cards with two to four times this VRAM, where nothing streams — an RTX 4090 in the Hacker News launch thread, an RTX 5080 in PR #16429, and RTX 5090 runs in PR #16430 and on BennyDaBall's card — so they describe a different regime and are not repeated here as if they applied. If you time a run, /contribute it with the DiT file you used and your resolution.
• VRAM usage: derived, not measured, and loader-dependent. Under ComfyUI's default DynamicVRAM loader the largest stage of the recommended setup is the w4a8 encode, 6.129 GiB on Linux (5.879 GiB of weights plus comfy-aimdo's 0.250 GiB headroom); sampling is 4.159 GiB with the NVFP4 build and 7.008 GiB with the int8 build, which leaves the int8 build borderline rather than settled. Under the legacy loader the same stages are 7.069, 5.100 and 7.949 GiB, and the int8 build streams. The vendor publishes no VRAM figure: neither the Hugging Face card nor the GitHub README gives one beyond suggesting enable_model_cpu_offload(), and issue #4 on the vendor repo, asking for minimum and recommended hardware, has no answer from the team. The live figure, once someone submits one, is at /check/qwen-image-2-1/rtx-5060.
• Where I looked for an 8 GB run: the eight Qwen-Image-2.1 issues and pull requests among the 17 ComfyUI tracker hits for "qwen image 2.1", with their comments; every comment in the Hacker News launch thread (none reports an 8 GB run, and the one asking whether 8 GB works has no reply); every discussion on the model's own repository, on the Comfy-Org repack (in #5 an RTX 5050 laptop owner with 8 GB asks for NVFP4, with no results posted) and on the community quant repositories above; the vendor repo's issues and pull requests; and Civitai's entries under the base-model label it uses for this family ("Qwen 2"). None of them reports an 8 GB run. These surfaces were growing by the hour during launch week, so re-run the search rather than trusting any count. Reddit refused every request from this session, including a control request to a subreddit's front page, so it is not covered.
• Quality notes: no independent comparison of the NVFP4, GGUF or int8 builds' output against each other turned up; BennyDaBall publishes same-seed comparisons of its NVFP4 package against bf16. One user on the int4 ConvRot build's repository reports poor output quality, which is why that smaller build is not offered here. No step-distilled (Lightning-style) LoRA for 2.1 surfaced among the Hugging Face repositories whose names contain "Qwen-Image-2.1" or in Civitai's listing for the family, so plan on the full step count.

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

Troubleshooting

WARNING: You need pytorch with cu130 or higher… at startup

PyTorch is older than CUDA 13, so comfy-kitchen's CUDA backend is disabled and the diffusion model's quantised layers run through its pure-PyTorch fallback — nothing fails, it is just slow. Reinstall the cu130 stack into the page's venv, not the system Python, and check the version print again:

cd "${COMFY:?set COMFY first, see step 1}" && source .venv/bin/activate && \
  pip install --force-reinstall --index-url https://download.pytorch.org/whl/cu130 \
    torch torchvision torchaudio && \
  python -c "import torch; print(torch.__version__, torch.version.cuda)"

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

That is city96's ComfyUI-GGUF refusing a GGUF with no general.architecture key, which is what leejet's stable-diffusion.cpp conversions are. The same error appears on Abiray's discussion #1. Use Abiray's files with city96's node, or leejet's files with leejet's fork — not a mix.

Given normalized_shape=[4096], expected input with shape [*4096]

The file in CLIPLoader is not the Qwen-Image-2.1 encoder. On the repack's discussion #2 the same error, with conditioning of width 5120, was the reporter loading the wrong file. A GGUF of the encoder lands here by another route (step 3 explains why ComfyUI assigns it a different encoder class). The prompt-enhancer checkpoints fail differently: users on discussion #4 report garbled images rather than an error when one is loaded as the encoder. Use one of the Comfy-Org qwen3vl_8b_* safetensors with type: qwen_image.

Edit output over-sharpened or speckled, or the edit ignored

Issue #16435 above: certain reference grids break the VAE-reference path, and the two reports disagree on which (64 × 64 on MPS and CPU in one, 96 × 64 on CUDA in the other; backend is one possible reason, not an established one). Set resolution to 1056 — clean in both reports, as was 512, which shrinks the reference — or disconnect vae and accept weaker reference adherence.

A fine diamond grid on faces at high resolution

A community report on the model's discussion #12 attributes it to the VAE: "It's more noticeable when you generate a high-resolution image that has people with light skin tones and zoom in on their faces." Posters there reproduce it with a bare encode–decode round trip and point to workarounds (a post-processing node, or re-encoding through a different VAE); no fix has landed upstream, and no hardware is named.

Green, channel-swapped output after changing the prompt

Issue #16437 documents output whose channels come back as [B, A, B, A] after any model reload with DynamicVRAM on — and an 8 GB card reloads on every prompt change. It is reported on AMD only; the reporter writes "I don't have an NVIDIA card to test whether this is ROCm-specific." and "Removing --enable-dynamic-vram fixes it completely." No NVIDIA report surfaced. If you see it, restart ComfyUI, then try --disable-dynamic-vram and report the result on that issue.

Everything is slow, and the disk light stays on

System RAM is short. The official set is 13.27 GiB and ComfyUI keeps what is not on the card in RAM; with 16 GB installed, the operating system can end up paging. Close other applications, use the NVFP4 build (10.42 GiB for the set), or add RAM.

---

See also: the 2025 Qwen-Image (20B) has no page for an 8 GB card on this site; Qwen-Image-2.1 is a new 7B model from the same team, not a quantised or cut-down version of it.