[Bug] Qwen-Image-2.1 transparent (RGBA) output: most of the background decodes opaque white (Metal)

[cristivez]

Git commit

6dcb5bb

Operating System & Version

macOS 26.5.2 (Apple M4 Max, 36 GB)

GGML backends

Metal

Command-line arguments used

sd-cli --diffusion-model qwen_image_2.1-Q4_K.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3VL-8B-Instruct-Q4_K_M.gguf -p "This is an RGBA image with transparency. A shiny golden trophy cup with two handles. The image has alpha channel and the background is transparent." -W 1024 -H 1024 --steps 20 --cfg-scale 1 --sampling-method euler -s 7 --diffusion-fa -o trophy.png

Steps to reproduce

1. Weights: leejet/Qwen-Image-2.1-GGUF (Q4_K, also Q8_0), Qwen/Qwen3-VL-8B-Instruct-GGUF (Q4_K_M, also Q8_0), Comfy-Org/Qwen-Image-2.1 vae/qwen_image_2.1_vae_bf16.safetensors.
2. Run the command above. The prompt uses the RGBA template from the model card. --cfg-scale 1 follows the model card's guidance-free default.
3. Inspect the PNG's alpha channel.

What you expected to happen

The trophy stays opaque and the background is transparent, like the model card's transparent examples.

What actually happened

The PNG is RGBA and the subject is correctly opaque, but most of the background decodes as opaque white. The transparent parts are islands, often a band hugging the subject's outline, and at 1024² they follow the 16 px latent grid.

Share of pixels with alpha < 32 (the empty background should be well over half the frame):

Setup (seed 7)	alpha < 32
Q4_K DiT + Q4_K_M TE, 20 steps	16.8%
Q8_0 DiT + Q8_0 TE, 20 steps	12.5%
Q4, 2048x2048, 8 steps	20.6%
Q4, longer "isolated cut-out, no background, no shadow" prompt, 8 steps	11.2%
model card prompt "A cute cartoon dragon sticker", 20 / 40 steps	38.3% / 34.1%

Nearly every pixel is either < 32 or ≥ 224; it is a binary mask with the wrong regions opaque, not soft edges. Neither step count, quantization, resolution nor prompt detail changes it. The Qwen3-VL template in conditioner.hpp matches the diffusers pipeline (same system prompt, system tokens dropped).

Caveat: I could not run the diffusers reference to confirm this differs from upstream. The Qwen HF Space returned "Queue is full" on each try. So this may be model behaviour rather than an sd.cpp bug; a quick check against QwenImage21Pipeline would tell.

Logs / error messages / stack trace

No errors at 1024². Separately, at 2048x2048 the untiled Metal VAE decode fails and falls back to tiling:

[ERROR  ] ggml_runner.cpp:880  - wan_vae segment 1/1 (graph) failed during weight preparation
[ERROR  ] vae.hpp:312  - vae decode compute failed
[INFO   ] image.cpp:619  - decode_first_stage completed, taking 881.28s

Additional context / environment details

On ordinary (non-transparent) prompts, 13–21% of pixels come back with alpha 224–254 rather than 255. That may be expected; I mention it in case it shares a cause.