Model setup recipes

Qwen-Image 2.1 GGUF: Unsloth setup guide

A 4.2GB Q4 file sounds small, until the runtime1 also asks for an encoder and VAE2. Nothing is wrong with the download: the denoiser, prompt encoder and image decoder are separate. This guide assembles the matching Unsloth components.

Three components, three jobs

The Unsloth GGUF3 repository contains the denoiser that builds an image from noise. A separate Qwen3-VL-8B encoder reads the prompt; the VAE converts the compressed representation into pixels. A valid denoiser with a mismatched encoder or VAE can still fail or produce broken output. Compatibility comes before file size.

For 2.1, use qwen_image_2.1_vae_bf16.safetensors, not an older Qwen-Image or Wan 2.2 VAE. The UD-Q4_K_XL encoder is also separate from the Q4_K_M denoiser. Recording the model name and each file's role helps avoid duplicate downloads when changing runtimes.

Files for the Unsloth GGUF setup
ComponentDownloadFile size
Q4 denoiserqwen-image-2.1-Q4_K_M.gguf4.2GB
Q4 text encoderQwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf5.15GB
Image decoder VAEqwen_image_2.1_vae_bf16.safetensors0.68GB

Files for the Unsloth GGUF setup

Q4 denoiser

Download
qwen-image-2.1-Q4_K_M.gguf
File size
4.2GB

Q4 text encoder

Download
Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf
File size
5.15GB

Image decoder VAE

Download
qwen_image_2.1_vae_bf16.safetensors
File size
0.68GB
Three modules in separate trays on a workbench
The denoiser, encoder and VAE have different roles.

Start with Q4; compare Q8 when memory permits

Q4_K_M reduces the denoiser to about 4.2GB. Q5_K_M is 5.39GB, Q6_K 6.27GB and Q8_0 7.64GB. Smaller weights save storage and memory but do not eliminate dequantization costs. Lower precision is not automatically faster or visually identical.

Unsloth retains higher precision in sensitive parts, but that does not guarantee pixel-identical output. Keep familiar prompts and seeds fixed and inspect lettering, contours and patterns. One published Mac setup ran Q8 faster than Q4 at 1K; ample RAM4 is a reason to test both, not select by file size alone.

Download only the files you will use

These commands require the Hugging Face hf tool. They download only the Q4 denoiser, Q4 encoder and VAE under models. Complete any requested authentication or license acceptance on the repository page first. Existing files can be reused by changing the paths in the run command.

The three files occupy roughly 10GB on disk. Download size is not runtime memory: 10GB free storage does not establish that inference5 will fit. Leave extra storage for additional formats, and remember that macOS and other apps share unified memory6 with the model.

Download the three required files
hf download unsloth/Qwen-Image-2.1-GGUF qwen-image-2.1-Q4_K_M.gguf --local-dir models
hf download unsloth/Qwen3-VL-8B-Instruct-GGUF Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf --local-dir models
hf download unsloth/Qwen-Image-2.1-FP8 vae/qwen_image_2.1_vae_bf16.safetensors --local-dir models
The VAE is saved in the models/vae subdirectory.

Generate the first image with stable-diffusion.cpp

sd-cli7 is the stable-diffusion.cpp executable. Use a Qwen-Image 2.1-capable version built for CUDA8 or Metal; the example assumes sd-cli is on PATH. On Windows, use the path to sd-cli.exe. Run from the directory containing models. This creates a local image, not a publicly exposed server.

The starting recipe follows Unsloth's sd.cpp example: 20 steps, CFG 6.0, Euler, 1024 square. It is not a universal optimum. Align settings before comparing timing against 40-step Diffusers or LightX2V runs. Verify one successful image first, then change steps or resolution one at a time.

Run Q4 text-to-image
sd-cli --diffusion-model models/qwen-image-2.1-Q4_K_M.gguf \
  --vae models/vae/qwen_image_2.1_vae_bf16.safetensors \
  --llm models/Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf \
  -p "A green ceramic teapot on an oak table, soft window light, simple cream background" \
  --steps 20 --cfg-scale 6.0 --sampling-method euler \
  -W 1024 -H 1024 --diffusion-fa -o qwen21-first.png
If memory is tight, check sd.cpp's --offload-to-cpu option and try a smaller resolution first.
A drawer with blocks and spare room beside a computer
Leave working space after loading the weights.

On 12–16GB hardware, reduce the right settings first

Avoid starting with 2K or concurrent images. Try one image at 1024 or below with Q4 and offloading9, pausing other GPU10 tasks. If memory still runs out, check where the encoder is loaded before further compressing the denoiser. A large encoder on the same GPU can consume the expected savings.

Offloading makes more configurations runnable; it is not free acceleration. CPU11 RAM and transfer speed affect the wait. On Mac, heavy swapping can feel slow despite ample SSD12 space. A missing time estimate for a low-memory configuration is not a claim that it cannot run, but a refusal to promise a stable swap-dependent duration.

Editing also needs the vision component

If text-to-image works but reference images fail, check the vision projector. sd.cpp documents a separate mmproj supplied through --llm_vision for editing with GGUF encoders. Match it to the encoder model; filenames vary by distributor. Redownloading the denoiser alone will not solve this.

Pass references with -r, repeating it for multiple images. First verify a one-image background edit. Preserve alpha in PNG or WebP. If your ComfyUI node or desktop app lacks a feature, distinguish model capability from application support and use a compatible workflow or runtime.

A laptop and print displaying a teapot
Finish one image first, then change one setting at a time.

Save a working setup before comparing hardware

The first run includes loading weights. Where possible, record at least three subsequent generations and take the median. Full sd-cli process time, which may reload weights each invocation, differs from a warmed server request. Recording the generation phase separately makes updates easier to compare.

Save filenames, runtime version, encoder, VAE, resolution, steps, seed and offload settings. Replacing hardware before separating configuration problems from GPU limits can reproduce the same issue. This is an installation guide, not a claim of our own measurements. The original research license still applies; check separate commercial permission when relevant.

Terminology notes

  1. RuntimeSoftware that loads model files and runs their computations. Supported formats, hardware, and optimizations vary by runtime.

    Back to the text
  2. VAEShort for Variational Autoencoder. It can encode input into a compact latent representation or decode that representation into an output.

    Back to the text
  3. GGUFA file format for model data, widely used by llama.cpp-based tools. The format alone does not guarantee compatibility or speed on particular hardware.

    Back to the text
  4. System RAMSystem memory that temporarily holds data while programs run. It differs from storage and from a discrete GPU’s VRAM.

    Back to the text
  5. InferenceThe process of using a trained model to compute an output for an input. Here, local inference means running the model on the user’s device.

    Back to the text
  6. Unified memoryAn architecture where the CPU and GPU share one physical memory pool. It does not increase total memory capacity; available capacity depends on the system.

    Back to the text
  7. CLIShort for Command-Line Interface: operating a program by entering commands in a terminal.

    Back to the text
  8. CUDAA software platform for general-purpose computing on NVIDIA GPUs. Programs built for CUDA are not guaranteed to run unchanged on other GPUs.

    Back to the text
  9. OffloadingMoving some model data from GPU memory to system RAM or storage when capacity is limited. This adds data transfer.

    Back to the text
  10. GPUA processor designed to handle many calculations in parallel. It performs model computations during AI inference.

    Back to the text
  11. CPUThe central processor that executes general-purpose program instructions. AI workloads may divide work between it and other processors such as GPUs.

    Back to the text
  12. SSDA data storage device that uses flash memory. It retains data without power and serves a different role from system memory.

    Back to the text