HRX0/Vulkan0 split fails above ~4750 tokens, path-independent of flash_attention.decode_split

[bong-water-water-bong]

Split off from engine#123. The HRX0,Vulkan0 -ts 1,0 -ot exps=Vulkan0 split fails above ~4750 tokens, and it is not the decode-split multipass.

Repro (gfx1151, pinned f5b7f4ad, Qwen3-Coder-30B-A3B, -ngl 99 -fa 1 -c 8192)

A ~4800-token prompt (a 86-section synthetic doc):

• -dev HRX0,Vulkan0 -ts 1,0 -ot exps=Vulkan0: at ~2128/2512/3000 tokens the code word ZX-4718-QQ is exact (18/18); at ~4800 it fails.
• -dev HRX0,Vulkan0 (no -ot exps=Vulkan0): same failure at ~4800.
• -dev HRX0 alone: 0 faults, but the code word comes back wrong at ~4800 (2/3), while at ~4704 it is exact.
• -dev Vulkan0 alone: clean.

Recorded with the env + dispatch per condition in strixhalo:~/goal-verify/split-inspect/{mp-on,mp-off}.{env,srv} and ~/goal-verify/sv-*.srv: with flash_attention_decode_split enabled the dispatch is flash_attention_decode_split_next_q8; with GGML_HRX_DISABLE_DISPATCH=flash_attention_decode_split the dispatch is flash_attention_f32_f16_wmma only — i.e. no multipass runs — yet the failure is the same. So the cause is upstream of / independent of the decode-split (a context-size, cross-device, or server-side issue).

Evidence

• strixhalo:~/goal-verify/cov2/split-depths.txt, cov2/split.server
• strixhalo:~/goal-verify/cor responses -> ~/goal-verify/corr-{mp,fb}.srv (a server_context_impl::post_decode/update_slots abort)
• llama-bench cannot run this split at all: both split benchmarks abort with ggml_backend_sched: pre-allocated tensor (blk.0.ffn_down_exps.weight) in a buffer (Vulkan0) that cannot run the operation (NONE).

Not part of #123's multipass fix. Filed so #123 can close on its own defect.

[bong-water-water-bong]

Obsolete — the configuration this issue exercises no longer exists

This reports an HRX0,Vulkan0 split:

HRX0,Vulkan0 -ts 1,0 -ot exps=Vulkan0 fails above ~4750 tokens

main no longer has a Vulkan device to split onto. RFC #213 stage 3 removed it (PR #306, "Core engine: HRX + HIP + NPU only (strip Vulkan, ROCm, ZINC, CUDA, ComfyUI…)"), and the removal is now enforced in code rather than merely absent:

// app/serve.cpp
void refuse_removed_device(const std::string& device) {
    if (device == "vulkan" || device == "rocm")
        throw std::runtime_error("--device " + device + " was removed: the engine's GPU route is HRX (--device hrx, or auto), "
                                 "and it builds no Vulkan or ROCm llama.cpp (RFC #213). Lemonade's own llamacpp backend "
                                 "serves Vulkan and ROCm (docs/lemonade.md)");

Checked on main: the llama.cpp-vulkan submodule is gone from .gitmodules, there are 0 Vulkan docs in the tree, and --device vulkan throws.

So -ts 1,0 -ot exps=Vulkan0 cannot be constructed, and the "path-independent of flash_attention.decode_split" note is moot with it. Suggest closing as no longer applicable — if anyone wants the FFN-placement question revisited, it belongs in a new issue against a configuration the engine still builds (HRX + CPU, e.g. HRX0,CPU -ts 1,0), and I'd open it on request.

Not touching #301 — that one is about the HRX-only in-range path (2049–32768) and its libhrx transient pinning, which does still exist.