fix: guard the qwen4exp PLE prefetch on the model architecture (SIGSEGV at ubatch >= 4096)

[dzannotti]

Overview

llama_context::decode calls qwen4exp_ple_prefetch for every architecture once a batch
reaches 4096 tokens (src/llama-context.cpp:1745), and the function immediately downcasts the
model to llama_model_qwen4exp and reads ple_disk from it. On any other architecture that
offset holds an unrelated object; when those bytes are non-zero the !pmodel.ple_disk check
passes and page_cached() dereferences them.

Any non-qwen4exp model therefore segfaults at ubatch >= 4096. qwen4exp models are unaffected,
because there the cast is valid — which is why this survived review of #63.

Thread 1 "llama-bench" received signal SIGSEGV, Segmentation fault.
0x00007ffff72a9634 in llama_ple_disk::page_cached() const () from libllama.so.0
#0  llama_ple_disk::page_cached() const ()
#1  qwen4exp_ple_prefetch(llama_model const&, int const*, int) ()
#2  llama_context::decode(llama_batch const&) ()
#3  llama_decode ()

Reproducer, on master 8c1c282ec:

llama-bench -m Signal-3.8-27B-AP-Q4_K_XL.gguf -ngl 99 -fa on -p 4096 -n 0 -b 4096 -ub 4096
# -> exit 139 (SIGSEGV)

Guards both the call site and the function, so any future caller is safe too.

Measurements

Not applicable: this only stops a call that must not happen on these architectures. The guarded
path is qwen4exp-only and unchanged there; no kernel, dispatch or graph behaviour is touched.
Prefill/decode throughput on qwen4exp is unaffected by construction.

Device:     Ryzen AI Max+ 395 (Radeon 8060S, gfx1151)
Memory:     128 GB LPDDR5X-8000
Backend:    ROCm 7.2.1 (rocm/dev-ubuntu-24.04:7.2.1-complete container)
Build:      -DGGML_HIP=ON -DGPU_TARGETS=gfx1151 -DCMAKE_BUILD_TYPE=Release
Baseline:   8c1c282ec (master)
Change:     57f5bde66

Correctness: before this patch, ubatch 4096 / 8192 / 16384 all exit 139 on
Signal-3.8-27B-AP-Q4_K_XL (qwen35) and Qwen3.8-27B-GSQ-RCO-IQ3_S (qwen35). After it, all of
them complete:

  Signal-3.8-27B Q4_K_XL    ub=4096   pp4096    127.70
  Signal-3.8-27B Q4_K_XL    ub=8192   pp8192    126.64
  Signal-3.8-27B Q4_K_XL    ub=16384  pp16384   123.45
  Qwen3.8-27B IQ3_S         ub=4096   pp4096    119.65
  Qwen3.8-27B IQ3_S         ub=16384  pp16384   115.65

gemma-4-26B-A4B and gpt-oss-20b (MoE) also run clean at ubatch 2048-16384 after the fix.

test-backend-ops -b ROCm0 passes 29695/29695 on master, before and after — the crash is on the
host side, so op coverage never saw it.

Additional information

Noted while reading, not fixed here: the detached prefetch thread captures &pmodel and &hp by
reference, so a model freed while it runs would leave it reading dead memory. It needs the model
to outlive a detached thread that nothing joins.

The default ubatch is 512, so this never fires in a default llama-server or llama-bench run —
only when someone raises -ub to 4096 or beyond, which is exactly what the large-prefill
configurations do.

qwen4exp verification (added after the first draft)

The guarded-in path was since exercised with ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF Q2_0
(qwen4exp), to confirm this does not guard out the architecture the prefetch exists for:

• ubatch 4096, where the call site is live: pp4096 545.17 with this PR, 547.60 on master, 545.80 on
  pwilkin/strix-halo official merge #63 alone — no crash, no change.
• ubatch 16384: pp16384 575.59 with this PR, 576.60 on master.
• --lazy-mode on-direct, the only route into llama_ple_disk and therefore the only configuration
  where qwen4exp_ple_prefetch does real work: pp4096 548.48 / tg32 29.82 with this PR, 549.72 /
  29.31 on master. The reader and the prefetch both run.

So qwen4exp keeps the prefetch and every other architecture stops taking the invalid downcast.

Requirements

• I have read and agree with the contributing guidelines
• This change is Strix Halo specific, or justified by measurements on Strix Halo. General llama.cpp improvements
  belong in halo-box/llama.cpp instead
• AI usage disclosure: AGENT-AUTHORED. Claude (Claude Code) found the crash, wrote the patch and this
  description, and ran every measurement; the owner reviews.
• What was NOT verified: CUDA (NVIDIA) was not built. The prefetch's own correctness (does the
  readahead help?) was not measured, only that the path runs without crashing.