Qwen-Image 2.1 VRAM and quantization: what the published measurements support

What the publisher publishes, and what it does not

Source: publisher model card, ModelScope card, official repository, release blog. All read 2026-09-26.

Component sizes on disk

The vLLM-Omni recipe is the only source that splits the pipeline into named components and sizes them. These are checkpoint sizes on disk, not peak memory.

Source: vLLM-Omni recipe for Qwen-Image-2.1, updated 2026-09-19. The same recipe notes that roughly a quarter of the saving available from quantization comes from the transformer and most of it from the text encoder.

Measured peaks, each with its conditions

SGLang's diffusion cookbook publishes the widest spread, including one consumer card. Measured 2026-09-20 at 1024x1024, 40 steps, guidance 1, one RGBA PNG per run, with VRAM sampled during the request phase rather than at startup.

The same page states that the RTX 5090 recipe uses transformer layerwise offload with Torch SDPA and has not been retested against the updated checkpoint, so its row is not published. Its GGUF section carries no figure at all, only the warning that GGUF reduces weight storage without guaranteeing lower latency. Source: SGLang cookbook, Qwen-Image 2.1.

The vLLM-Omni recipe reports its own peaks on datacenter Blackwell, and is explicit that the numbers are `NVIDIA GPUs only` and that support is `not in a tagged release` at the time of writing.

The recipe's own conclusion is worth quoting because it inverts the usual assumption: the text encoder is the bigger saving by a wide margin, about 6 GB against about 2 GB for the transformer, and neither path runs faster. The FP8 variants carry quality costs against BF16 as well, measured as average PSNR: 26.1 dB when every eligible layer is quantized, 29.7 dB when the image MLP stays BF16. Source: vLLM-Omni recipe, updated 2026-09-19.

The quantization tiers that exist, and who publishes them

No publisher, official or third-party, maps a tier to a memory requirement. That mapping is exactly what a buyer needs, and it does not exist in public. Sources: Comfy-Org repack, ComfyUI tutorial, unsloth GGUF card.

Where the published numbers disagree, and why

For the same model at the same 1024x1024 scale, public figures run from about 2 GB to 38.4 GiB. That is a factor of nineteen, and the reason is not measurement error. There are three different memory models behind those numbers:

1. Fully resident. Every weight is on the accelerator. SGLang measures 38.4 GiB on an H200; vLLM-Omni measures 34.0 GB BF16 on a GB300.
2. Partly offloaded. Some components move to host memory between steps. SGLang measures a 22.7 GiB peak on a 24 GB RTX 4090 by offloading the text encoder layer by layer, and the same page notes that CPU offload requires host RAM.
3. Streamed. Weights live in system memory and are fed to the GPU as needed. An ncnn and Vulkan implementation reports full BF16 precision on as little as 2 GB of dedicated GPU memory with no CPU or disk offload in the usual sense, and says it runs on a GTX 1060. That is a different trade: host bandwidth, not VRAM, becomes the constraint.

Two further reports are worth recording with their limits. A diffusers measurement on a single RTX 5090 reports resident weights of 16.6 GB at 8-bit and 10.6 GB at 4-bit, peaks of 21.3 and 15.2 GB at 1024x1024, 22.6 and 15.4 GB at 2048x2048, and peaks of 25.6 and 19.1 GB with two reference images. Its stated scope is one GPU and one seed per prompt with no BF16 baseline, and it flags its own run configuration. Separately, a forum post claims that INT8 fits 8 GB of VRAM and INT4 fits 4 GB, without naming a resolution, step count, runtime version or measurement method. We record that as an unsupported claim, not as a measurement.

Cross-vendor speed reports are equally unsynchronised. In one community thread a 24 GB RTX 4090 takes nine minutes for a 1376x768 edit with five reference images while plain text-to-image takes about twenty seconds, and another commenter first reports 49 seconds for three references at 2K on a 12 GB RTX 3060 and then corrects it to about a megapixel in twenty seconds. Input resolution, reference count, step count and attention backend are never held together across reports, which is why the disagreements cannot be resolved by reading more of them.

One contradiction that looked like a GGUF problem was partly retracted. A ComfyUI issue reported the int8 repack running 234 to 330 seconds against 158 to 308 seconds for a Q8 GGUF on a 16 GB RTX 5060 Ti. The first reply attributed it to the PyTorch CUDA build rather than the format, and the reporter's follow-up with a cu130 build brought int8 down to 75 and 76 seconds with the GGUF numbers unchanged. The useful lesson is a variable to pin, not a settled result.

Failure modes the memory numbers do not cover

These are open reports against the pipelines people actually use. They matter more than a gigabyte figure when nothing runs at all.

• GGUF architecture detection. GGUF exports from stable-diffusion.cpp carry no architecture metadata, so the community loader answers that the model is not supported until it learns the 2.1 fingerprint. The distinguishing key is the image MLP gate layer, which 1.0 does not have.
• Missing vision tower in a GGUF text encoder. A Qwen3-VL GGUF used as the text encoder without its mmproj projector builds the wrong encoder and emits 12288-wide hidden states instead of 4096, which surfaces as a shape mismatch in the sampler. Fixes are open upstream.
• VAE mismatch. The FP8 VAE linked from one GGUF card was rejected by ComfyUI; the official bf16 VAE worked in the same setup.
• Dynamic VRAM on ROCm. With dynamic VRAM enabled on an RX 9070 XT, output is silently corrupted after the first model reload, in a channel-interleaved pattern, until the server restarts. Removing the flag fixes it completely.
• Prefix cache and the allocator. A hard process abort has been reported in the prefix-cache prefetch path on Windows multi-GPU, with a fix still open upstream.
• Sampling schedule. The shipped template pins the shift value to the 1024x1024 case for every resolution, while the model ships a dynamic-shift scheduler computed from the latent token count.
• Silent attention fallback. The default template warns on every step that FlashAttention is unavailable and falls back to SDPA.

Pointers: loader workaround, vision tower fix, ROCm dynamic VRAM, prefix cache abort, sampling schedule, attention fallback.

How to decide without trusting a single figure

1. Pin the checkpoint revision, the quantization tier, the runtime and its CUDA or torch build, and the placement policy before comparing two numbers. The retracted int8 result above shows a build change flipping a conclusion.
2. Compare peak memory, not on-disk size. The same pipeline is 33.1 GB of components, 38.4 GiB resident, and a 22.7 GiB peak under layerwise offload.
3. Budget the text encoder first. It is the largest single component and the larger quantization saving.
4. Do not assume the transformer dominates under full layerwise offload. SGLang's own GGUF guide warns that VAE decode and offload buffers can still dominate peak GPU memory.
5. Expect the first request after startup to cost more than later ones; the vLLM-Omni recipe measures roughly 1.3x.
6. If you go the GGUF route, budget for three files and one loader: a denoiser, the VAE, and a Qwen3-VL GGUF text encoder with its mmproj, on a loader that recognizes this architecture.

Evidence table

What this page does not claim

We own no test hardware and this page contains no measurement of ours. No checkpoint was downloaded to write it. Nothing here is a promise that the pipeline runs on your card: every figure was produced by someone else, on the hardware named beside it, and the conditions matter more than the number. The fit figure on the model directory entry is the on-disk component total, which is a starting point for planning rather than a VRAM requirement.

Related: local hardware purchase paths and GPU selection by workload and runtime.