Vulkan backend crashes with GGML_ASSERT on maxComputeWorkGroupCount (Intel Arc B70/Battlemage)

[aangelinsf]

Description

vulkan-vibevoice-cpp (via LocalAI's POST /v1/audio/diarization) crashes reliably during inference on Intel Arc GPUs (confirmed on an Intel Arc Pro B70 / Battlemage), even though model loading succeeds fine. cpu-vibevoice-cpp with the identical model/weights works correctly, so this is Vulkan-backend-specific, not a model or config issue.

Crash

/LocalAI/backend/go/vibevoice-cpp/sources/vibevoice.cpp/third_party/ggml/src/ggml-vulkan/ggml-vulkan.cpp:6610:
GGML_ASSERT(wg0 <= ctx->device->properties.limits.maxComputeWorkGroupCount[0] &&
            wg1 <= ctx->device->properties.limits.maxComputeWorkGroupCount[1] &&
            wg2 <= ctx->device->properties.limits.maxComputeWorkGroupCount[2]) failed

Backend process exits (exit code 2 under LocalAI's supervisor, or a native abort/SIGABRT when run standalone), taking the whole request down. LocalAI's own process-supervisor logging doesn't surface this — it just reports a generic "backend process exited unexpectedly" / gRPC EOF — this trace was captured by running the backend binary manually and driving it with a raw gRPC LoadModel+Diarize call.

Environment

• Model: vibevoice-cpp-asr (7B, Q4_K GGUF, from mudler/vibevoice.cpp-models on HuggingFace)
• Backend: vulkan-vibevoice-cpp (from quay.io/go-skynet/local-ai-backends:latest-gpu-vulkan-vibevoice-cpp)
• GPU: Intel Arc Pro B70 (Battlemage), kernel driver xe
• LocalAI: v4.8.2
• Confirmed working: same model + weights via cpu-vibevoice-cpp (CPU backend), accurate real-world diarization result (correct speaker count and turn attribution on a 55s, 6-turn, two-speaker test), just slow (~2.3x realtime)

Reproduction

1. Load vibevoice-cpp-asr (or presumably any vibevoice.cpp ASR/diarization model) via the vulkan-vibevoice-cpp backend on an Intel Arc GPU.
2. Send a real Diarize (or presumably Transcript) request against any real audio clip a few seconds or longer.
3. The backend process aborts with the assertion above; the caller sees the load/inference call fail (Unavailable: Socket closed over gRPC, or a generic 500 via LocalAI's HTTP layer).

Likely related

This looks like the same bug class reported multiple times against ggml-org/llama.cpp's Vulkan backend (which vibevoice.cpp vendors under third_party/ggml), on unrelated models and even different GPU vendors:

• Vulkan: GGML_ASSERT failed on Kimi-Linear-48B with large context - maxComputeWorkGroupCount exceeded ggml-org/llama.cpp#19471 (large-context workgroup overflow)
• TurboQuant Vulkan backend crashes with maxComputeWorkGroupCount` assertion on RDNA4 (RX 9070 XT) ggml-org/llama.cpp#23098 (same assert, RDNA4/AMD)
• Eval bug: GGML_ASSERT Devstral-Small-2507 with Vulkan ggml-org/llama.cpp#18510 (same assert, another model)

Root cause per those reports: some op computes a workgroup dispatch count from a tensor dimension (context size, batch, etc.) that can exceed a Vulkan device's per-dimension maxComputeWorkGroupCount limit — proposed fixes split an oversized dispatch into multiple vkCmdDispatch calls, or fix the workgroup-size denominator math. If third_party/ggml here is a submodule/vendored snapshot of upstream ggml, a fix landing there would likely resolve this too once synced.

Happy to provide more detail (exact request parameters, full backend stdout/stderr) if useful.