[Bug] GGUF with 5D patch_embedding fails

[desirel-dev]

Git commit

Subject: Wan 2.1 GGUF with 5D patch_embedding fails on older builds – request for compatibility note

Hi leejet,

First of all, thank you for the amazing work on stable-diffusion.cpp — I use sd-server daily on Windows with Vulkan (Intel Iris Xe) and it's the only backend that runs reliably on my hardware.

I'm hitting a loader mismatch with Wan 2.1 1.3B models exported by current community converters.

Environment:

sd-server.exe commit bb84971 (pre-September 2025 build)
Model: wan2.1-i2v-1.3b-480p-q8_0.gguf (from city96 / calcuis)
Command: --diffusion-model wan2.1-i2v-1.3b-480p-q8_0.gguf --t5xxl umt5-xxl-encoder-Q4_K_M.gguf --vae wan_2.1_vae.safetensors

Error:
Code

[ERROR] ggml_extend.hpp:70 - gguf_init_from_reader: tensor 'patch_embedding.weight' has invalid number of dimensions: 5 > 4
[ERROR] ggml_extend.hpp:70 - gguf_init_from_reader: failed to read tensor info
[ERROR] stable-diffusion.cpp:1416 - model metadata validation failed

The GGUF contains patch_embedding.weight with shape [2, 2, 1, 48, 1536] (5D), while the loader in this build expects max 4D. I understand that Wan 2.1 support (including 5D tensors) was added on 2025-09-14, but many users still use older prebuilt binaries.

Would it be possible to either:

Add a clear note in the README/releases that Wan 2.1 GGUFs require build >= 2025-09-14 due to 5D patch_embedding, or
Consider a small backport that gracefully reports "model requires newer build with 5D support" instead of the generic dimension error?

I'm happy to test any patch on Windows/Vulkan if helpful.

Thanks again for your work, and for maintaining such a lightweight project.

Best regards,

Operating System & Version

win11

GGML backends

Vulkan

Command-line arguments used

sd-cpp> cd C:\sd-cpp; .\sd-server.exe --diffusion-model wan2.1-fun-control-1.3b-q8_0.gguf --t5xxl umt5-xxl-encoder-Q4_K_M.gguf --vae wan_2.1_vae.safetensors -l 127.0.0.1 --listen-port 8080 --backend diffusion=vulkan0,vae=cpu,te=cpu --threads 8 --fa .\sd-server.exe :

Steps to reproduce

sd-cpp> cd C:\sd-cpp; .\sd-server.exe --diffusion-model wan2.1-fun-control-1.3b-q8_0.gguf --t5xxl umt5-xxl-encoder-Q4_K_M.gguf --vae wan_2.1_vae.safetensors -l 127.0.0.1 --listen-port 8080 --backend diffusion=vulkan0,vae=cpu,te=cpu --threads 8 --fa
.\sd-server.exe :

What you expected to happen

change that if (tensor->n_dims > 4) {
LOG_ERROR("tensor '%s' has invalid number of dimensions: %d > 4", name, tensor->n_dims);
return false;
}

What actually happened

error dim>4

Logs / error messages / stack trace

No response

Additional context / environment details

No response

[wbruna]

sd-server.exe commit bb84971 (pre-September 2025 build)

This is inconsistent: bb84971 is the latest version, from today, 2026-07-06.

Also, the first server release was master-411-2aecdd5 (2aecdd5), from December 2025.

but many users still use older prebuilt binaries.

Any reason they can't simply update?

Consider a small backport that gracefully reports "model requires newer build with 5D support" instead of the generic dimension error?

How would that even work? If they can update to that backported version, wouldn't be more reasonable to update to a release that does support it instead?

Unless this issue actually affects the current release?

[desirel-dev]

Hi, thanks for the quick reaction!

Sorry — my AI assistant mixed up the dates. The issue is not about an old binary.

I'm on sd-server.exe commit bb84971 (2026-07-06) — latest master, built today. Same 5D error as before.

Digging through the code, in my build there are three places that would need a manual rewrite for Wan 2.1 GGUF to work:

ggml_extend.hpp:70 — the >4 check. Even if I bump it to 5, old ggml can't allocate a 5D tensor because ggml_tensor only has ne[4]. You'd need to swap the whole ggml to the llama.cpp version from mid-2025.

src/wan.cpp — old loader creates patch_embedding with ggml_new_tensor_4d. Wan 2.1 needs ggml_new_tensor_5d and then ggml_conv_3d. Without it the model loads but segfaults at inference because weights don't match the graph.

src/model_loader.cpp + src/model.cpp — metadata validation (model_manager.cpp:493) checks GGUF shape vs expected shape. Old code expects [2,2,1536,48] (4D), file has [2,2,1,48,1536] (5D). You'd have to rewrite the whole name→shape map for Wan 2.1.

So the error is correct for the current release — it's not just a bad error message, the loader really can't handle 5D yet.

Thanks again for the fast response — happy to test if you point me to a branch with the new ggml.

[Green-Sky]

Extending ggml to support 5dims was previously denied.

Checkout ggml-org/llama.cpp#15669 for more info.

[wbruna]

llama.cpp version from mid-2025
old ggml can't allocate a 5D tensor

Unfortunately, that's not a version issue: ComfyUI GGUFs are usually generated with the help of a modified llama.cpp binary. Probably from:

https://github.com/city96/ComfyUI-GGUF/tree/6ea2651e7df66d7585f6ffee804b20e92fb38b8a/tools#quantizing-using-custom-llamacpp

Which BTW also mentions:

For hunyuan video/wan 2.1, you will have to run fix_5d_tensor.py after the quantization step is done.