out of memory issues after the new update

[xcalibir2]

I have been dealing with multiple crashes when using krea 2 since --diffusion-fa switched to --flash-attn off, diffusion=on .. on older versions --diffusion-fa work perfectly, my pc specs are the worst actually (ryzen 3 2200g + 16gb of ram no gpu) and i use vulkan 0. i will continue to use the older sd.cpp and i really hope this issue gets solved in future updates, it looks like the new --flash-attn flag uses a different approach which adds more ram overhead

[Medamineelkhattabi]

--diffusion-fa is exactly --flash-attn off,diffusion=on (one argument, no space after the comma), and the old flag still works as a deprecated alias, so the rename itself isn't what's using the extra memory. The alias just writes that string (common.cpp L785-L791), and the engine then turns flash attention on for the diffusion model only, same as before (diffusion_engine.cpp L1191-L1199, L1273-L1277).

What did change in that window is Vulkan memory handling. 60423ab ("reclaim before accepting wrapped Vulkan iGPU memory estimates") landed two hours before the flag rename, and #2154 bisected a Krea2 OOM on Vulkan to it. That reporter suspected the flash attention change at first too. It was fixed in master-987 (#2183). A ggml update in master-1031 then caused another Krea2 OOM on Vulkan (#2254), fixed in master-1037 (#2256). Both reports were on a discrete card, but your Vega goes through the same capacity checks. If the build that crashes is older than master-1037, try master-1053 first.

Also new since master-1024 (#2228): auto-fit, which is on by default, now plans weight placement on iGPU-only machines instead of skipping them. Any --params-backend, including the one --offload-to-cpu adds, turns auto-fit off (diffusion_engine.cpp L937).

With 16 GB shared between CPU and GPU, file size matters most. The Q8_0 used in the Krea2 docs is about 13.7 GB on its own; Krea-2-Base-Q4_K_M.gguf from the same repo is about 7.3 GB. This is what I'd try:

sd-cli --diffusion-model Krea-2-Base-Q4_K_M.gguf --llm Qwen3VL-4B-Instruct-Q4_K_M.gguf --vae wan_2.1_vae.safetensors -p "your prompt" --flash-attn off,diffusion=on --offload-to-cpu --params-backend te=disk --max-vram vulkan0=4 --vae-tiling -v

--offload-to-cpu keeps the weights in RAM and makes Vulkan copies on demand, which stay around until something needs the space (performance.md L138). On an APU both copies sit in the same RAM, so --max-vram vulkan0=4 sets a budget for the Vega side. It's a soft budget, not a hard cap; go lower if it still crashes. --params-backend te=disk reads the Qwen3-VL weights from the file when needed instead of keeping them in RAM (performance.md L117-L126). --vae-tiling decodes in 256x256 tiles.

If it still crashes, the model manager memory on Vulkan0: reported free ... warnings printed just before it, plus the commit from sd-cli --version, would show which of these it is.