Vulkan on integrated GPU (UMA): model manager reports "available 0.00 MB device" — Qwen-Image 2.1 fails at weight prep

[EdRochaMagic360]

Title: Vulkan on integrated GPU (UMA): model manager reports "available 0.00 MB device" — Qwen-Image 2.1 fails at weight prep

Build: master-890-74988b2, official release sd-master-74988b2-bin-win-vulkan-x64.zip, Windows 11
GPU: Intel UHD Graphics (i5-13420H), uma: 1, driver 32.0.101.7088 (June 2026)
RAM: 40 GB, ~38 GB free

Command:
sd-server --diffusion-model qwen-image-2.1-Q4_K_M.gguf --vae qwen_image_2.1_vae_bf16.safetensors --llm Qwen3VL-8B-Instruct-Q8_0.gguf --backend "diffusion=Vulkan0,vae=Vulkan0,te=cpu" --max-vram "Vulkan0=3" --diffusion-fa --vae-tiling --cfg-scale 1.0 -v

Log:
auto-fit plan: Vulkan0 Intel(R) UHD Graphics free 31703 MiB, budget 3072 MiB
DiT params 4391 MiB -> compute Vulkan0, params cpu
...
get_learned_condition completed, taking 3.49s (text encoder on CPU works)
qwen_image_2_1 using 34 segments
[WARN] model_manager.cpp:1801 - model manager cannot make enough memory available on Vulkan0: need 625.39 MB device / 113.39 MB budget, available 0.00 MB device / 3072.00 MB budget
[ERROR] ggml_runner.cpp:873 - qwen_image_2_1 segment 1/34 (qwen_image_2_1.prelude) failed during weight preparation

Tried, none help:

• --max-vram Vulkan0=3 / no --max-vram
• --params-backend on Vulkan0 vs cpu (VRAM 0.00MB resident, still 0.00 available)
• --disable-segmented-compute (fails the same at segment 1/1)
• GGML_VK_VISIBLE_DEVICES=0 to hide the second (NVIDIA) Vulkan device
• Intel driver updated from 32.0.101.6129 to 32.0.101.7088

Notes:

• auto-fit reads 31703 MiB free at startup, but the model manager reads 0.00 MB at generation time → looks like accounting, not capacity.
• Same files work on CUDA (RTX 3050, 1.32 s/it) and on CPU backend.
• Possibly related to CUDA: model manager reports "available 0.00 MB device" on discrete GPUs — klein/z-image fail at weight prep #1989 / fix: handle GPU memory reports and LLM encoding failures #2020: fix: handle GPU memory reports and LLM encoding failures #2020 kept the free-memory underflow rejection for Vulkan, which may be what blocks UMA devices.

[RChang06]

Likely cause: the free > total guard in check_capacity

At src/model_manager.cpp:1648-1651

// Vulkan's heap budget subtraction can underflow when usage exceeds the budget.
if (total_bytes > 0 && free_bytes > total_bytes && sd_backend_is(backend, "Vulkan")) {
    return size_t{0};
}

I couldn't get my pc to reproduce this bug but I found similar reports the driver reports free > total (spec violation, see ggml-org/llama.cpp#29277: heap 36.20 GiB, budget 46.76 GiB, on drivers .8860, .8724, and .7088 ). Essentially the section above acts as a defensive measure as ggml computes free = heapBudget - heapUsage unsigned, and the spec allows usage > budget, so the result can wrap to ~2^64. However in your case it seems that the driver can also simply over-report the budget (no wrap, just a value a few GiB above the heap), and the guard zeroes that too, turning a healthy device into 0 MB available.

So even if this turns out not to be your exact failure, the guard is wrong as written: it can't distinguish "wrapped to 2^64" from "driver over-reports by 10 GiB".

Possible fixes:

• Only treat it as a wrap when the excess is absurd, e.g. free - total > total, or free > 1 << 60; otherwise clamp to min(free, total - resident) like every other backend.

• Clamp at the source in ggml's ggml_backend_vk_get_device_memory (budget = min(budget, heap.size), free = budget > usage ? budget - usage : 0), which fixes every consumer at once.

If anyone can verify this theory, feel free to add a pr