Qwen-Image-2.1 GGUF: What a Quantised Build Actually Costs You

There is no official GGUF of Qwen-Image-2.1. Every .gguf file carrying that name was produced by somebody else, after the fact, by taking the vendor's 7B diffusion transformer and re-encoding its weights at lower precision — GGUF being the single-file quantised checkpoint format the local inference stacks read. That one sentence answers the first question a reader has and raises the harder ones this page settles: what a quantisation of an image model actually compresses, what the file leaves out of the box, what the levels cost you in the picture rather than only in the clock, and what redistributing one requires under the licence the weights came with.

The model itself is the fact that dates this page, not the news it reports. Qwen-Image-2.1 went up on Hugging Face and ModelScope on 20 September 2026, and community quantisations of it followed the same day — the leejet, Abiray and RealRebelAI repositories were all created on 20 September and unsloth's on 21 September, which is 23 days before this page was written. Nothing about that timeline needs restating here; what a reader typing "qwen image 2.1 gguf" wants is the operating manual, and this is it.

What a GGUF of this model is, and what it is not

The first thing to internalise is that the file is a fragment. Qwen-Image-2.1 is not one network; it is a diffusion transformer plus a vision-language text encoder plus an autoencoder. The quantisations circulating under its name contain the first of those and nothing else, and the repositories say so themselves. Unsloth's card for its Qwen-Image-2.1 GGUF puts it in one line: "A GGUF is the denoiser only, so it needs the VAE and the Qwen3-VL text encoder alongside it."

So a GGUF download is the transformer — 32 single-stream DiT layers, 7B parameters in the visual generation component — restated at reduced numeric precision. The text encoder and the VAE stay in their original formats or get quantised separately, by different people, in different repositories. This is the structural difference from the text-model situation most readers are carrying in their heads: when you download a GGUF of a chat model, you have downloaded the model. Here you have downloaded a third of a pipeline.

None of this is the vendor's packaging. The vendor repository Qwen/Qwen-Image-2.1 is a Diffusers-layout release — model_index.json, transformer/, text_encoder/, vae/, scheduler/, processor/ — and its file listing, read on 13 October 2026, contains no .gguf file of any kind. The quantisations are community artifacts, published under their authors' names, and they inherit the vendor's licence rather than the vendor's endorsement.

Why text-model quantisation wisdom does not transfer

The received wisdom about GGUF comes from language models, where it is roughly: Q8_0 is effectively lossless, Q4_K_M is the sweet spot, anything below Q3 is a compromise, and quality is measured as perplexity or KL divergence against a full-precision reference. Almost none of that carries across to an image model, and the reasons are worth being precise about.

There is no perplexity for a diffusion transformer. The model does not emit a token distribution you can score; it emits a latent that a VAE decodes into pixels. The metrics that exist on this side of the fence — LPIPS, SSIM against a reference render — require the same seed, the same prompt and the same sampler settings on both sides of the comparison, and they still measure perceptual distance rather than correctness. So the question "how much does Q4_K_M cost me?" has no single published number the way it does for a text model, and anyone quoting one is quoting one measurement on one seed.

Second, and more consequentially: on an image model the average bit width matters less than which tensors lost their bits. The attention projections and the MLP paths that carry image structure degrade visibly when rounded, while small normalization and modulation tensors tolerate almost anything. A conversion that hits a uniform target across every tensor can therefore look worse than a conversion with the same nominal label that protects the sensitive layers — which is exactly what the people doing this work found. RealRebelAI, publishing the most explicit quantisation notes we could find, states that "a standard generic Q4_K_M conversion showed visible quality loss in fine structure and anatomy compared with the reference INT8 model," and that its own builds keep attention Q/K/V/Out at Q8_0 inside a Q4_K_M file to recover it. The label on the filename is the base quantisation, not the policy.

Third, the failure mode is different in kind. Text quantisation degrades mostly as fluency, and it degrades gracefully — a slightly worse sentence is still a sentence. Image quantisation at the low rungs fails in ways that are obvious and sometimes unusable: hands and anatomy, fine texture, small typography, and — the one that is easy to miss because it is not a pixel artifact at all — prompt adherence. If a build stops obeying half of a long instruction, that is a quantisation cost, and it will not show up in a side-by-side of two good renders.

The ladder, in files rather than adjectives

File sizes are the one part of this that is hard fact rather than judgement, because every repository publishes its own listing. Read on 13 October 2026, the two most-downloaded community quantisations disagree slightly with each other, which is itself informative.

• Unsloth Dynamic 2.0 (12 files): F16 14.23 GB, Q8_0 7.64 GB, Q6_K_XL 6.72 GB, Q6_K 6.27 GB, Q5_K_M 5.39 GB, Q5_K_S 4.50 GB, Q4_K_M 4.20 GB, Q4_K_S 3.91 GB, Q3_K_XL 3.61 GB, Q3_K_M 3.17 GB, Q3_K_S 2.72 GB, Q2_K 2.47 GB.

• leejet / stable-diffusion.cpp (7 files): Q8_0 7.69 GB, Q6_K 6.00 GB, Q5_0 5.07 GB, Q4_K 4.20 GB, Q4_0 4.20 GB, Q3_K 3.27 GB, Q2_K 2.56 GB.

• Abiray (6 files): Q8_0 7.59 GB, Q6_K 5.88 GB, Q5_K_M 5.01 GB, Q4_K_M 4.19 GB, Q4_K_S 4.06 GB, Q3_K_M 3.19 GB.

• RealRebelAI publishes a mixed-precision ladder with an -HQv3 suffix rather than plain levels, and documents per-module precision in a table; the base quantisations run from Q2_K to Q8_0.

The spread is real. Q8_0 spans 7.59 to 7.69 GB across three publishers, and Q6_K spans 5.88 to 6.27 GB — a 0.4 GB gap for the same nominal level, which is the mixed-precision policy showing up as bytes. Anyone comparing two builds by filename alone is comparing labels, not artifacts.

For scale on the other side: the reference F16 transformer is 14.23 GB, and the vendor's own bfloat16 diffusion component in the Comfy-Org repack is 14.23 GB. So a Q4-class GGUF is roughly a 3.4× reduction on the transformer, and no reduction at all on the text encoder unless you quantise that separately.

What each rung costs, where a source says so

Almost nobody publishes a measured quality cost per level for this model, and the honest thing to do is separate the three kinds of claim in circulation.

• Memory guidance, community-reported. Abiray's repository pairs each file with a recommended VRAM profile: Q8_0 7.59 GB at "12 GB+ (near-lossless fidelity)", Q6_K 5.88 GB at 10–12 GB, Q5_K_M 5.01 GB at 8–10 GB, Q4_K_M 4.19 GB and Q4_K_S 4.06 GB at 6–8 GB, and Q3_K_M 3.19 GB at 4–6 GB for "extreme budget / minimum VRAM". These are the publisher's own rule-of-thumb, not a vendor specification and not a benchmark we could reproduce; they also describe the transformer file alone, so the headroom you need for the text encoder sits on top.

• A measured comparison, quantiser-reported and single-seed. Unsloth publishes one number pair for the encoder side of the pipeline: its Dynamic 2.0 4-bit text encoder against a uniform Q4_K_M encoder, both at a shared seed with the denoiser and VAE held fixed, at LPIPS 0.029 and SSIM 0.959, in 5.15 GB versus 5.03 GB and 36.5 s versus 39.0 s. It is one measurement by the party selling the file, on one seed, and it is the only published quantitative comparison of two quantisation policies for this model that we could locate.

• Qualitative failure lists, community-reported. RealRebelAI names what lower-bit quantisation can still affect — "fine detail, hands and anatomy, typography, prompt adherence, edit fidelity, texture consistency" — and advises moving up a rung when degradation is visible. It states plainly that Q3_K_M and Q2_K are for memory-constrained systems and "may still show increasing quality loss despite the protected high-precision layers."

What is not published is as important as what is. There is no vendor statement about quantisation quality for Qwen-Image-2.1 at all, no independent benchmark of any GGUF build, and no throughput table on named consumer hardware from anyone we could find. The direction of the memory trade-off is certain and the direction of the speed trade-off is broadly certain; the size of the fidelity cost is not established in public, and this page will not estimate it for you.

What actually runs it

The runtime story is unusually settled for a format this recent, which is a real advantage over the usual GGUF situation.

• stable-diffusion.cpp — the reference implementation for image-model GGUF. Its project news list records Day-0 support for Qwen-Image-2.1 on 20 September 2026, and it documents a dedicated page for the model. The command line takes the quantised diffusion model directly: --diffusion-model qwen-image-2.1-Q4_K_M.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf, with --steps 20 --cfg-scale 6.0 --sampling-method euler in the publisher's own example.

• ComfyUI, through a custom node. This is the route most readers will take, and it has a wrinkle worth knowing before you install anything. The repository most quantisers point at is city96/ComfyUI-GGUF; the stable-diffusion.cpp author publishes his own fork, leejet/ComfyUI-GGUF, and his README carries an explicit instruction to prefer it, on the stated grounds that "the city96 repository appears to no longer be actively maintained." That is a claim by one party about another and it is dated; the commit history on city96/ComfyUI-GGUF does show its most recent activity in January 2026. ComfyUI's own official documentation page for Qwen-Image-2.1 lists only .safetensors weights and does not mention GGUF at all, so the custom node is not optional and is not vendor-blessed. Both loaders place the file in ComfyUI/models/diffusion_models/ and expose it through a GGUF diffusion-model loader.

• llama.cpp / ggml — not a sampler for this model, but the origin of the format and the toolchain that produces these files. Both the leejet and Abiray repositories credit it explicitly. If you want a level nobody published, this is what you convert with.

• Unsloth Desktop — named by the unsloth repository as a supported front end alongside stable-diffusion.cpp.

One runtime conspicuously does not load it: Diffusers. The vendor's own quick-start is a QwenImage21Pipeline over the bfloat16 safetensors repository, and there is no GGUF path in that pipeline. If you want Diffusers, you are not the audience for a quantised file; if you want a quantised file, stable-diffusion.cpp or a ComfyUI graph is where you land.

The part that actually blocks people

Every failure report around this format traces back to the same thing: the GGUF is the transformer, so the rest of the pipeline has to be assembled by hand, in the right formats, from the right repositories. Three components are in scope and one of them has a trap in it.

• The text encoder. Qwen-Image-2.1 conditions on Qwen3-VL 8B, and that encoder is bigger than the transformer at full precision — 17.53 GB in bfloat16 in the Comfy-Org repack, against 14.23 GB for the diffusion model. Quantised alternatives exist at 9.35 GB (int8) and 6.31 GB (w4a8) in the same repack, and independently as GGUF: the vendor publishes a first-party Qwen/Qwen3-VL-8B-Instruct-GGUF with F16 at 16.39 GB, Q8_0 at 8.71 GB and Q4_K_M at 5.03 GB. Note that this encoder GGUF is a vendor artifact, unlike the transformer GGUF it sits next to — the two halves of your pipeline come from different publishers with different provenance.

• The VAE. A single file, qwen_image_2.1_vae_bf16.safetensors, 0.68 GB in the Comfy-Org repack. It is small and it is the component people most often assume is interchangeable, and it is not: stable-diffusion.cpp's documentation states that the earlier Qwen Image and Wan 2.2 VAE weights are not interchangeable with the Qwen Image 2.1 VAE weights. Pair the wrong one and the graph loads and produces the wrong picture.

• The vision projector, if you want to edit. Text-to-image is the easy half. For image editing the encoder needs a separate multimodal projector: the stable-diffusion.cpp docs instruct readers to also download mmproj-Qwen3VL-8B-Instruct-F16.gguf (1.16 GB) from the encoder repository and pass it with --llm_vision, and repeat -r once per reference image. A transformer-only GGUF plus a text encoder is a text-to-image pipeline and nothing more.

Two further uploads are worth knowing about. The release also ships two prompt-rewriting encoders — Qwen-Image-2.1-PE-T2I and Qwen-Image-2.1-PE-I2I, both fine-tuned 9B models — which the vendor recommends running in front of the image model, and those are being quantised too: a GGUF build of the T2I rewriter from the LightX2V project appeared on Hugging Face on 12 October 2026, alongside several community builds. And the alpha channel, which is one of this model's more distinctive features, survives quantisation but not every container: the diffusion model decides transparency from the prompt rather than from a switch, and the alpha is kept only in .png and .webp output.

Memory planning around the GGUF itself is a place where the runtime documentation is genuinely specific, which is rare. stable-diffusion.cpp reuses the step-independent text and reference-image keys and values as a prefix cache, and publishes what that costs per condition for the 32-layer model at a 4096-token prefix: 4 GiB at FP32, 2 GiB at FP16, 1.0625 GiB at q8_0, 0.5625 GiB at q4_0. Quantising the cache is a second, separate trade from quantising the weights, it is off by default, and quantised cache storage introduces additional rounding error the documentation flags rather than hides.

The licence the quantisation inherits

This is the section most GGUF pages skip, and for this model it is the one that changes what you can do.

The base weights are not distributed under a permissive licence. The Qwen/Qwen-Image-2.1 repository carries license: other with license_name: qwen-research, and the LICENSE file is the Qwen Research License Agreement, release date 20 September 2026. Read in full on 13 October 2026, its operative grant is a non-exclusive, worldwide, non-transferable, royalty-free licence to "use, reproduce, distribute, copy, create derivative works of, and make modifications to the Materials FOR NON-COMMERCIAL PURPOSES ONLY", with "Non-Commercial" defined inside the agreement as "for research or evaluation purposes only" and commercial use routed to a separate licence requested by email at the address the agreement names.

A quantised checkpoint is a derivative work of those Materials, which means redistribution of a GGUF is redistribution under that agreement and picks up every condition attached to it. Three of them are concrete:

• You must pass the agreement on. Section 3(a) requires you to give anyone who receives the materials or a derivative a copy of the licence. A GGUF repository with a licence tag and no agreement text is not compliant, whatever its download count.

• You must mark what you changed. Section 3(b) requires modified files to carry prominent notices stating they were changed. A re-encoded weight file is a modified file.

• You must carry the attribution notice verbatim. Section 3(c) requires the notice text — "Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved." — to be retained in a "Notice" text file distributed with the copies.

Two further rules bind the person doing the quantising and anyone building on the result. If you train, fine-tune or improve an AI model using the materials or their outputs and then distribute it, you must prominently display "Built with Qwen" or "Improved using Qwen" in the product documentation. And you may not use "Qwen" as the primary name or identifier of a derivative work, though descriptive use such as "fine-tuned from Qwen Image" is permitted. Governing law is Chinese, with exclusive jurisdiction in the People's Courts of Hangzhou.

The practical upshot is one line, and it is worth stating plainly because the format hides it: quantising the weights does not change the licence. Every repository inspected for this page carries license_name: qwen-research and links back to the vendor's LICENSE file, and the download count on a GGUF file is not a grant of commercial rights. For contrast, the earlier Qwen image line was permissive — the model cards for Qwen-Image, Qwen-Image-Edit, Qwen-Image-Edit-2511 and Qwen-Image-2512 all read apache-2.0 on 13 October 2026 — and Qwen-Image-2.1 is the break in that pattern. If a commercial pipeline is the goal, the licence is the first thing to read and not the last.

Where this leaves you

Stated as a decision rather than a summary: if your card cannot hold the 14.23 GB transformer plus a 17.53 GB encoder plus the VAE, a GGUF build is the only way you are running Qwen-Image-2.1 at all, and the honest expectation is that a mid-level quantisation buys you the run and costs you something in fine detail, hands, small text and instruction-following — with no published measurement to tell you how much. If your card can hold it, the safetensors path is the one the vendor documents and the one with a defined reference.

Two readers need one sentence each elsewhere on this property. If what you actually want is a community build with the safety filtering stripped out rather than a discussion of the format, that is a different page and the uncensored builds are covered there. And if your real destination is a working node graph rather than a file you have to assemble by hand, the ComfyUI page walks the whole pipeline, loader by loader.

What is left open is the thing the ecosystem has not published: a controlled comparison of these levels on a fixed seed, with the same prompt and the same sampler, on hardware somebody names. RealRebelAI's note that a generic Q4_K_M visibly degraded against an INT8 reference while a mixed-precision build at the same label did not is the closest thing to that answer in public, and it is one publisher's own A/B test. Until someone publishes the comparison, the level you should pick is the highest one your memory allows, and the label on the filename is a weaker guarantee than the tensor policy behind it.