Repository navigation
[Bug] Z-Image Base GGUF checkpoints produce blank white images in stable-diffusion.cpp CUDA builds #1488
Description
Release: master-596-90e87bc
Release file: sd-master-90e87bc-bin-win-cuda12-x64.zip
I tested the Z-Image Base GGUF diffusion checkpoints in the stable-diffusion.cpp CUDA build and they consistently completed the job but returned a blank white PNG instead of an image.
Tested GGUFs:
- z-image-Q4_K_M.gguf
- z-image-Q5_0.gguf
- z-image-Q8_0.gguf
Working comparison:
- z_image_turbo-Q4_K_M.gguf
The safetensor Base checkpoint works normally, so the failure appears specific to the Base GGUF diffusion path rather than Base mode in general.
Observed behavior:
- the job submits and completes successfully
- the backend logs on both the CLI and server show the model loads and sampling starts normally
- the final output image is a pure white frame
- this happens across the Base GGUF variants I tested
- Turbo GGUF still works normally in the same setup
This does not look like an app UI or orchestration issue. The runtime accepts the request and finishes it, but the Base GGUF diffusion path produces an unusable blank image.
Operating System & Version
Windows 11, Version 10.0.26200, Build 26200, 64-bit
GGML backends
CUDA
Command-line arguments used
sd-cli.exe --offload-to-cpu --diffusion-fa
Steps to reproduce
Steps to Reproduce
- Run sd-cli.exe with a Z-Image Base GGUF diffusion checkpoint.
- Submit a normal text-to-image request.
- Observe that the job completes successfully.
- Open the output PNG.
- Confirm the image is blank white.
Observed with
- z-image-Q4_K_M.gguf
- z-image-Q5_0.gguf
- z-image-Q8_0.gguf
What you expected to happen
A normal non-blank image should be generated from the Base GGUF checkpoint, just like with the Base safetensor checkpoint.
What actually happened
The job completed successfully, but the resulting PNG was blank white instead of a real image.
Logs / error messages / stack trace
No response
Additional context / environment details
No response
Activity
nArn0 commentedon May 19, 2026
Very similar to what i had #1253
This was still the case on the last tests i did indeed. It may due to some dequantization overflow, but it is probably hard to track as-is: #1385
It would be cool to know where to put a debug flag to check this in a test version (meanwhile, i am enjoying all the great new features 💜)
LFd3v commentedon Jun 8, 2026
@xtianxian can you please provide the log when trying to use the base model GGUFs?
I experienced the same result (white PNG output) when using z-image-turbo_fp8_scaled_e5m2_KJ.safetensors from Kijai, which works perfectly fine in ComfyUI, but then I noticed this in the sd.cpp log:
There is no error, the inference ends and then VAE kicks in, but it results is a plain white output.png. Using the GGUF from leejet works just fine tho.
rainman74 commentedon Jun 26, 2026
same here with z_image_turbo-Q4_K_M.gguf
alex-ie commentedon Sep 3, 2026
I will add my 5 cents. I have recently tried ZiB in koboldcpp 1.120 and noticed "black/gray square".
Summary:
TL;DR:
ZiT works always in my setups, but Z-Image-Base works only on CPU or Maxwell NVIDIA GPU, on Pascal (exactly same software, only different couple of years newer computer) - black square already at 1st latent step (koboldcpp 1.120 allow preview of latent steps), whereas in "normal" diffusion run e.g. on Pascal already 1st step is fuzzy sketch (so after couple of waits to final image - which were grey squares on Pascal - I started to cancel after 1-2 SD steps). I have tried CUDA, Vulkan, "old PC" kcpp build (retrospectively same error on "old" makes sense, I have read "old" means CUDA 11.5, but Maxwell is AFAIK way older) with Vulkan and CUDA, two quants from different accounts on HF - same black square.
What do you think about this Maxwell vs Pascal difference? I have idea to build kcpp with NVIDIA compute capability limited to Maxwell level and try to run on Pascal. Is it easy to do? Cheers.
P.S. Does unquantized ZiB works without this issue? If so I will try to download, though it is rather large for my hardware.