Description
YuE2 generation (family: yue2, task: gen) crashes the server process partway through the AR batched-decode step, every time, on an Intel Arc B580. The crash is a GGML_ASSERT in ggml-vulkan.cpp:
external/ggml/src/ggml-vulkan/ggml-vulkan.cpp:2020: GGML_ASSERT(!src1 || get_misalign_bytes(ctx, src1) == 0) failed
This is init_pushconst_tensor_offsets, which asserts every source/dest tensor's view offset is a multiple of minStorageBufferOffsetAlignment. On the Arc B580 this alignment requirement appears stricter than on AMD/NVIDIA, and some tensor view produced during YuE2's CFG-batched AR decode isn't padded to satisfy it.
Environment
- GPU: Intel Arc B580 (12GB), Vulkan 1.4.357 (LunarG SDK used for the build)
- Also has an AMD Radeon iGPU as Vulkan device 1 on the same machine
- OS: Windows 11
- Build:
windows-vulkan-release preset, -ModelSet custom -Models yue2,sheetsage2, dev branch
- Model:
audio-cpp/Yue2-3B-GGUF, tried both yue2-3b-q8_0.gguf (native) and with yue2.weight_type=f16
Repro
server.json:
{
"host": "127.0.0.1", "port": 8080, "backend": "vulkan", "device": 0,
"models": [
{ "id": "yue2", "family": "yue2", "path": "<path to Yue2-3B-GGUF>", "task": "gen", "mode": "offline" }
]
}
Request:
curl http://127.0.0.1:8080/v1/tasks/run -H "Content-Type: application/json" -d '{
"model": "yue2",
"request": {
"lyrics": "[Verse]\nA quick smoke test.\n[Chorus]\nJust a few short bars.",
"seed": 42,
"num_inference_steps": 4,
"options": { "style": "English, indie pop, acoustic guitar, soft drums", "cot": "off" }
}
}'
Server log always reaches the same point before the process dies:
[TIMING] yue2.ar.batched_decode.graph.build_ms ...
[TIMING] yue2.ar.cfg.start_decode_ms ...
<crash, no further output>
What I tried (device 0, Arc B580) — all reproduce the same assert
- Default
weight_type (native/q8_0)
yue2.weight_type=f16
GGML_VK_DISABLE_COOPMAT=1 (confirmed via log: matrix cores: none)
- Both of the above combined
Workaround found (not a fix)
Switching "device": 1 (the AMD iGPU on the same box) avoids this specific assert — generation proceeds through AR decode and NAR synthesis successfully — but then the process dies silently (no assert, no log line) during VAE decode, ~20 minutes in for a ~15-second test clip, likely an iGPU memory ceiling. Also far too slow to be practical either way.
Ask
Is this a known Arc-specific alignment issue in the YuE2 AR decode path (e.g. a KV-cache or CFG-batch buffer that needs to be padded to minStorageBufferOffsetAlignment)? Happy to test a patch or provide more logs/traces if useful — this is currently the only thing blocking a fully local, non-CUDA YuE2 setup on this hardware.
Description
YuE2 generation (
family: yue2,task: gen) crashes the server process partway through the AR batched-decode step, every time, on an Intel Arc B580. The crash is aGGML_ASSERTinggml-vulkan.cpp:This is
init_pushconst_tensor_offsets, which asserts every source/dest tensor's view offset is a multiple ofminStorageBufferOffsetAlignment. On the Arc B580 this alignment requirement appears stricter than on AMD/NVIDIA, and some tensor view produced during YuE2's CFG-batched AR decode isn't padded to satisfy it.Environment
windows-vulkan-releasepreset,-ModelSet custom -Models yue2,sheetsage2,devbranchaudio-cpp/Yue2-3B-GGUF, tried bothyue2-3b-q8_0.gguf(native) and withyue2.weight_type=f16Repro
server.json:{ "host": "127.0.0.1", "port": 8080, "backend": "vulkan", "device": 0, "models": [ { "id": "yue2", "family": "yue2", "path": "<path to Yue2-3B-GGUF>", "task": "gen", "mode": "offline" } ] }Request:
Server log always reaches the same point before the process dies:
What I tried (device 0, Arc B580) — all reproduce the same assert
weight_type(native/q8_0)yue2.weight_type=f16GGML_VK_DISABLE_COOPMAT=1(confirmed via log:matrix cores: none)Workaround found (not a fix)
Switching
"device": 1(the AMD iGPU on the same box) avoids this specific assert — generation proceeds through AR decode and NAR synthesis successfully — but then the process dies silently (no assert, no log line) during VAE decode, ~20 minutes in for a ~15-second test clip, likely an iGPU memory ceiling. Also far too slow to be practical either way.Ask
Is this a known Arc-specific alignment issue in the YuE2 AR decode path (e.g. a KV-cache or CFG-batch buffer that needs to be padded to
minStorageBufferOffsetAlignment)? Happy to test a patch or provide more logs/traces if useful — this is currently the only thing blocking a fully local, non-CUDA YuE2 setup on this hardware.