ling0322/libwaifu-qwen-image-2.1

Qwen-Image 2.1 — the libwaifu package

Qwen-Image 2.1, converted to the package format libwaifu reads. The same weights drawing the same pictures; a different file layout and a narrower dtype.

By downloading these files you agree to the Qwen RESEARCH LICENSE AGREEMENT, a copy of which is distributed here as LICENSE. The agreement is non-commercial (research and evaluation) use only — see LICENSE for the exact terms, including how to request a commercial license.

This is a modified copy — see NOTICE for what was changed — and it is not an official Qwen product and is not endorsed by Alibaba or the Qwen team. This project is Built with Qwen. The original weights are at Qwen/Qwen-Image-2.1.

What is here

package	on disk	what it is
qwen-image-2.1.yaml and its parts	30.0 GB	float16 throughout
qwen-image-2.1-fp8.yaml and its parts	16.0 GB	the matrices as E4M3 with one scale per output channel, everything else float16

Either one carries the whole model: the 7B single-stream DiT, the language half of a Qwen3-VL-8B text encoder (read at its last layer), and the Wan-2.2-style autoencoder — 64 latent channels, an alpha channel out. Nothing else has to be fetched to draw. The runtime composites the RGBA output over white by default; the raw four channels are available too (generate_rgba).

Drawing with it

waifu webui -m qwen-image-2.1.yaml

or from Rust:

let manifest = Manifest::open("qwen-image-2.1.yaml")?;
let model = QwenImage::from_manifest(Device::Cuda, Residency::LowVram, &manifest)?;
let image = model.generate("a red fox sitting in fresh snow", &options)?;

The package suggests forty steps at no guidance (suggested: block) — true_cfg_scale = 1 is what the model card calls "meant to be sampled without guidance"; a guidance above one runs a second pass on the negative prompt, the way the reference does.

How close it is to the original

Measured against diffusers' QwenImage21Pipeline on the same weights, 256x256, ten steps, with every input taken off one real trajectory rather than from torch.randn:

	float16 package	fp8 package
encoder, last layer before the norm (against float32)	1.07e-2	1.21e-1
velocity at step six	7.5e-3	2.15e-2
decoder, RGBA (against float32)	6.5e-4	6.5e-4 — it is not quantized
the whole ten-step walk	1.33e-2	1.19e-1

The float16 numbers are close to what the two float types disagree by and little else: the reference's own bfloat16 run is itself 6.9e-2 from float32 on the encoder's last layer, so float16 (1.07e-2) is the more exact of the two.

The fp8 package costs considerably more here than in libwaifu's other fp8 packages — about eleven times the float16 package's encoder error, against roughly four to five times for this runtime's other models. This weighs down that encoder and the walk it feeds more than it does the per-step denoising error. It is still a real, working package — nothing NaNs or crashes, and the decoder is exactly as exact either way, since it is never quantized — but take it only when the card is genuinely the constraint, and expect a more noticeably different picture than the other fp8 packages here draw.

Memory

Measured upstream on a 16 GB card with Residency::LowVram, 1024x1024: about 3.2 GB of card memory at peak (the weights stream through a layer at a time) and 27 GB of host memory for the float16 package mapped in. The fp8 package is about half that on disk and in host memory. Residency::Device instead holds the whole package on the card — budget roughly the on-disk size of the package plus a few gigabytes of activations.

Attribution

Qwen is licensed under the Qwen RESEARCH LICENSE AGREEMENT, Copyright (c) 2026 Hangzhou Tongyi Laboratory Technology Co., Ltd. All Rights Reserved. This project is Built with Qwen.