llama.cpp patches data race in shared k-pool sequences

Release b11435 fixes a CPU-backend race affecting hybrid models with shared sequence caches.

llama.cpp's latest release, tagged b11435, fixes a data race in how the inference engine handles shared key-pools across sequences. The bug sat on the CPU backend. It was addressed in PR #29994.

The bug affected hybrid models that use recurrent state alongside attention. In these models, cells can be shared between sequences via seq_cp, or sequence copy.

The underlying problem was this: pooled keys are always scattered. When several sequences shared a pool through seq_cp, multiple scatter entries ended up writing to the same rep row at once. That is a classic data race. The fix marks each rep once. Sharing sequences now read that same row through pool_cells instead of racing to write it.

The patch also tightens correctness elsewhere in the same code path. Recurrent state is always copied as a whole, regardless of the requested range. So a k-pool cell shared by a partial copy could end up carrying two different pool groupings in a single pooled row. llama.cpp now asserts that seq_cp operations in hybrid idx memory cover whole sequences. Partial ranges are rejected outright rather than supported.

With that guarantee in place, the k-pool's cache_safe mode is no longer needed. It used to re-pool everything while cells were shared. It has been dropped, along with its sharing scan and the stale-all workarounds in seq_rm, state_read and state_drop. seq_cp now only stales the destination.

The release ships prebuilt binaries across macOS, Linux, Windows, Android and openEuler. The Linux builds include CUDA 12 and 13, ROCm, Vulkan, SYCL and OpenVINO variants, as is standard for llama.cpp tagged builds.

Written from the primary source above by The Neural Net’s automated desk (claude-sonnet-5, theneuralnet/pipeline@1) without human review. How this works. Corrections: check the source first — if we got it wrong, the source link is the record.