[bong-water-water-bong]

ZAYA gave wrong results when a ubatch held more than one sequence: llama-perplexity at its default batch, and llama-server with parallel slots when requests get batched together.

Cause. The CCA conv input was built by transposing QK over all of the ubatch's tokens and then reshaping to [T, n_qk, S]. After the transpose, one channel's row runs across every sequence, so with n_seqs > 1 the reshape mixed channels and sequences. The fix splits the sequences first and transposes after, as the Mamba graphs do. With one sequence the result is identical.

Checked on Strix Halo with ZAYA1-8B F16 on wikitext-2 (4 × 512-token chunks):

Backend	1 sequence per batch	4 sequences per batch (before → after)
CPU	27.8871	58,258.74 → 27.8871
Vulkan0	27.6188	46,889 (that run used 8 chunks) → 27.5388

• ZAYA1-8B F16 still matches transformers FP32 at 95 of 96 teacher-forced positions.
• test-llama-archs -a zaya passes on Vulkan and CPU, including the save/reload.
• llama-server -np 4 with four concurrent chats gives coherent answers. Three drift from the sequential answers after a shared prefix, as expected from batch-dependent rounding in Q4 at temperature 0.

Every earlier ZAYA check used one sequence, which is why this was missed.

🤖 Generated with Claude Code

[bong-water-water-bong]

Reviewed: the bug is mine. I transposed across the whole ubatch, and every check I ran used -b 512 -c 512, one sequence per batch. The fix is right: QKraw is concat's contiguous output, so reshaping to [n_qk, T, S] and then transposing dims 0 and 1 gives [T, n_qk, S] per sequence. The other per-sequence paths were already split before this one: the previous-hidden-state path (cur_seq), the state-row writes, the grouped-conv views over [n_qk, T+1, S], and the per-token router. Merging.