[Bug] Qwen-Image-2.1: periodic 8px/4px grid artifacts at native 2K resolutions (CUDA and Vulkan, Q8_0 and Q6_K)

[bhoult]

Git commit

88411ef (master-908). Also reproduced on 137f740 (master-883, the first Qwen-Image-2.1 commit): same seed and settings give pixel-identical output.

Operating System & Version

Ubuntu 26.04.1 LTS, kernel 7.0.0-31. NVIDIA GeForce RTX 5080 (16 GB), driver 595.91.07, CUDA 13.2.

GGML backends

CUDA and Vulkan (both affected).

Command-line arguments used

sd-cli --diffusion-model qwen_image_2.1-Q8_0.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3VL-8B-Instruct-Q8_0.gguf --sampling-method euler --cfg-scale 5 --steps 40 -W 2048 -H 2048 --diffusion-fa --offload-to-cpu --sage-attn -s 757604577 -p "a photograph of an old stone fishing harbor at golden hour, wooden boats moored at the quay, calm water with reflections, weathered houses, sharp focus, 50mm lens, natural light"

The diffusion model is qwen_image_2.1-Q8_0.gguf from leejet/Qwen-Image-2.1-GGUF. The VAE is qwen_image_2.1_vae_bf16.safetensors.

Steps to reproduce

1. Run the command above at 2048x2048, one of the model's native sizes.
2. View the output at 100%.

What you expected to happen

A clean image at the model's native 2K resolution. The same prompt at 1024x1024 comes out clean.

What actually happened

Everything at 2048x2048 and 2752x1536 carries a regular fine grid, a crosshatch of horizontal and vertical lines with an 8 px period and a strong 4 px harmonic. It covers the whole image and is most visible on smooth or textured areas such as water, stone and sails. Scaled down, the images look fine; at 100% the grid is obvious, and it also shows up in painterly prompts. At 1024x1024 it is essentially absent.

Images (1024 vs 2048 crop, and a grid of 2048 variants): https://gist.github.com/bhoult/0b9535a30fd7b2ec8c4f664935cd0004

To measure it rather than judge by eye, I used the gridscore.py in the gist. It takes the power spectrum of the high-passed luminance and divides the power at frequency N/P by the median of nearby frequencies, taking the larger of the horizontal and vertical values. Around 1-10 means no grid.

Image (same prompt; 2048 runs use the same seed)	P=4 px	P=8 px
1024x1024, CUDA, Q8_0, cfg 5	1.2	8.9
2048x2048, CUDA, Q8_0, cfg 5, FA + sage (baseline)	544	266
same, VAE decoded on CPU (--backend vae=cpu, no tiling)	544	273
same, without --sage-attn	543	230
same, master-883 (137f740), no sage	543	230 (pixel-identical to the line above)
same, Q6_K diffusion model	809	273
same, cfg 1 / 3 / 6	274 / 728 / 416	149 / 317 / 166
same, Vulkan backend	695	217
2752x1536 (16:9), different prompt	295	268

What this rules out:

• VAE tiling. At 2048 the GPU VAE decode runs out of memory and falls back to tiling, but decoding the same latent untiled on the CPU gives the same grid.
• SageAttention.
• The master-883 to master-908 changes. That range includes the circular RoPE refactor and the Wan VAE 2D-convolution change.
• Quantization. Q8_0 and Q6_K both show it.
• CFG scale.
• The GPU backend. CUDA and Vulkan both show it.

Not tested:

• Running without --diffusion-fa. At 2048 that needs about 34 GB of VRAM, more than this card has.
• Comparing against the reference diffusers pipeline at 2048. So I can't rule out that the upstream model itself does this. But 2048x2048 is listed as a native resolution on the Qwen/Qwen-Image-2.1 model card, so I'd expect a clean result there.

Since the grid is backend- and quantization-independent and appears only at the 2K sizes, my guess is shared code that depends on resolution: positional embedding or RoPE scaling for large token grids, the automatically chosen resolution-dependent flow shift, or patchify/unpatchify. The 8 px period with a 4 px harmonic may point at the patch or latent layout. This is only a guess.

Logs / error messages / stack trace

No errors from the diffusion step. At 2048 the log contains VAE decode ran out of memory; retrying with spatial tiling, which is expected on a 16 GB card. The CPU-decode test above shows the tiling isn't the cause.

Additional context / environment details

• Text encoder: Qwen3-VL-8B-Instruct Q8_0 GGUF.
• --offload-to-cpu is set in every 2048 run. It only moves weights, so I don't expect it to matter.
• 3072x3072 at 20 steps also runs, but the tiled VAE decode fails there: it wants about 23 GB even when tiled.

[stduhpf]

That's an issue with the model itself I'm afraid. I've seen peaople complain about it on ComfyUI too, and people are using some post-porocessing custom nodes to try to get rid of this artifact becase of that.

Interesting to see it doesn't seem to appear at 1024x1024 though.

[CarlGao4]

I think it should be a bug of sd.cpp

I tried the same prompt on diffusers using weights without quantization and here are the results:

image                                             size     P=4     P=8    P=16   (h/v max)
../../2048-diffusers.png                    2048x2048     18.2    25.3     4.3
../../2048-sdcpp.png                        2048x2048    160.2   316.6     3.7

My sd.cpp command is

./stable-diffusion.cpp/build/bin/sd-cli --diffusion-model model/transformer/diffusion_pytorch_model.safetensors.index.json --vae model/vae/diffusion_pytorch_model.safetensors --llm model/text_encoder/ --fa -W 2048 -H 2048 -o 2048-sdcpp.png --offload-to-cpu --cfg-scale 1.0 --steps 40 -p "a photograph of an old stone fishing harbor at golden hour, wooden boats moored at the quay, calm water with reflections, weathered houses, sharp focus, 50mm lens, natural light"

I ran diffusers with following codes:

import torch
from diffusers import QwenImage21Pipeline
pipe = QwenImage21Pipeline.from_pretrained(
    "./model", torch_dtype=torch.bfloat16
)
pipe.enable_model_cpu_offload()
image = pipe(
    prompt="a photograph of an old stone fishing harbor at golden hour, wooden boats moored at the quay, calm water with reflections, weathered houses, sharp focus, 50mm lens, natural light",
    width=2048, height=2048,
    num_inference_steps=40,
    generator=torch.Generator("cuda").manual_seed(42),
).images[0]
image.save("2048-diffusers.png")

2048-diffusers.png	2048-sdcpp.png

[Green-Sky]

In my test I saw the same issue. (cuda q8_0 streaming)

The officially supported resolutions are all in the 2k range.

aspect_ratios = {
    "1:1":  (2048, 2048),
    "4:3":  (2400, 1792),
    "3:4":  (1792, 2400),
    "3:2":  (2528, 1696),
    "2:3":  (1696, 2528),
    "16:9": (2752, 1536),
    "9:16": (1536, 2752),
}

[CarlGao4]

It shouldn't be VAE precision issue now, I ran the tests above using my PR build with official weights without quantization, which means that the whole path uses F32

[CarlGao4]

Reproduced the results on 1792x1792 - with and without fast attention

python gridscore.py 2048-diffusers.png 2048-sdcpp.png 1536-sdcpp.png 1536-sdcpp-fa.png 1792-sdcpp.png 1792-sdcpp-nofa.png
image                                             size     P=4     P=8    P=16   (h/v max)
2048-diffusers.png                          2048x2048     18.2    25.3     4.3
2048-sdcpp.png                              2048x2048    160.2   316.6     3.7
1536-sdcpp.png                              1536x1536     14.5    28.3     2.2
1536-sdcpp-fa.png                           1536x1536     16.5    28.6     2.3
1792-sdcpp.png                              1792x1792     89.4    36.4     1.2
1792-sdcpp-nofa.png                         1792x1792    197.9    67.2     2.2

Sorry my file naming is a bit annoying but I guess you can understand

[CarlGao4]

Update: the grid is already present in sd.cpp's latent, not introduced by its VAE. I dumped the final latent from a 2048x2048 run, denormalized it and decoded it with the reference diffusers VAE — the grid comes back:

• sd.cpp full pipeline: P=4 160.2 / P=8 316.6
• diffusers VAE decoding sd.cpp's latent: P=4 161.5 / P=8 300.1
• diffusers full pipeline (reference): P=4 18.2 / P=8 25.3

sd.cpp output	sd.cpp with vae decoded with diffusers

So the VAE (dtype, tiling, weights) is exonerated; the artifact comes from the DiT side.

[CarlGao4]

I think this hasn't been fixed - using the latest build 2f88688 the grid still exists. @jeeb @Green-Sky Can you test the latest builds again?

The gridscore differents because I only ran 16 steps using this build

python gridscore.py T:\2f88688.png
image                                             size     P=4     P=8    P=16   (h/v max)
T:\2f88688.png                              2048x2048    102.3   150.2     4.8

[Green-Sky]

Maybe the shift is off? If it did not have enough steps it looks cooked on any resolution.

Run with 25 steps:

512²
1024²
2048²

$ sd-cli --diffusion-model models/qwen_image_2.1-Q8_0.gguf --vae models/qwen21/qwen_image_2.1_vae_bf16.safetensors --llm models/Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf --cfg-scale 6.0 --sampling-method euler --scheduler simple -v --offload-to-cpu --fa --vae-conv-direct --steps 25 -W 2048 -H 2048 -p "a lovely cat holding a sign says 'qwen2.1.cpp'" -o qwen21_cat_2048.png

2f88688

[Green-Sky]

@leejet is it possible resolution dependent shifting is not clamped? Not sure qi21 has an upper limit, but eg krea2 and other models had one.

[Green-Sky]

Haven't tried yet, but might be related: https://huggingface.co/madebyollin/texture-fix-vae-for-qwen-image-2.1

[CarlGao4]

I tested its outputs, here is the results:

python gridscore.py decode-qwen-image-2.1-vae-full.png decode-texture-fix-vae-full.png
image                                             size     P=4     P=8    P=16   (h/v max)
decode-qwen-image-2.1-vae-full.png          2048x2048     75.5   144.9     4.0
decode-texture-fix-vae-full.png             2048x2048     40.5   145.0     4.1

It seems that this fine-tuned vae could significantly reduce 4px grid. But as I've tested, passing the latent generated by sd.cpp to diffusers VAE produces images with grids, so I'll keep on investigating the true cause