Eval bug: CUDA decode+prefill collapse at deep KV position on qwen35 hybrid (~5.5x tg, ~21x pp at d154855) #29172

System

• OS: Windows 11 (x64)
• GPU: NVIDIA GeForce RTX 5060 Ti 16GB (16283 MiB, compute capability 12.0 Blackwell, sm_120)
• Driver: 616.92, CUDA 13.4 runtime
• CPU: AMD Ryzen 5 7500F (6C/12T)
• RAM: 16GB DDR5-5600 single stick
• Build: prebuilt llama-b11047-bin-win-cuda-13.4-x64.zip + matching cudart (upstream release, not self-built)
• Version string: version: 0.3.0-dev (build 11047) — exact string from --version below

Configuration

llama-bench.exe -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -fa on -p 512 -n 32 -r 1 -o md -d <depth>

Model: prism-ml/Ternary-Bonsai-2-27B-gguf, file Ternary-Bonsai-2-27B-PTQ1_0.gguf (5.95 GB, PTQ1_0 ternary, arch=qwen35, 64 blocks, hybrid attention ~75% linear, SHA256 53107f53…fe33ee3 verified)
Note: this is a ternary-weight model, but the symptom below is in the backend decode path (identical shape to dense-model reports #27623/#27734), not in weight dequantization.

The Issue

Decode (and at depth, also prefill) throughput collapses once the KV position passed in via -d exceeds roughly 150K tokens, on an otherwise healthy fully-GPU-resident run. Short-context numbers on the same binary/model/GPU are normal.

llama-bench -p 512 -n 32 -r 1 (engine-internal timings, not wall clock):

That is a ~21x prefill collapse and ~5.5x decode collapse at depth, with exit code 0 (no error, no OOM, no CPU fallback lines). The -d 154855 run took ~1h20m wall, all of it in prompt processing of the synthetic depth prefix.

Same-model CLI spot checks agree: -c 154855 short prompt gives pp ~153 / tg ~42, while -c 262144 gives pp ~44 / tg ~9.

Related control: llama-bench -fa off -d 154855 fails in ~7s at context creation (non-FA path must materialize the full attention matrix); -fa off -d 32768 works (pp 314 / tg 29); -fa off at d0 matches -fa on (pp 462 / tg 43.9). So FA tiled kernels are required at depth, and the collapse happens within the FA path.

Suspected Area

Decode-path attention over long KV for hybrid linear/full-attention models (qwen35-family here: 64 blocks, ~75% linear). Possibly a fallback/slow kernel engaged past some KV-extent threshold, or a memory-latency-bound matvec regime (per #26581's ~21-25ns/KV/attention-layer constant, which is backend-invariant and also points at decode-attention kernels rather than bandwidth).

Two candidate mechanisms I have already ruled out on this machine, with evidence:

1. Vulkan-style suballocation fragmentation (Vulkan: ~78% decode throughput cliff at 131072 context — suballocation fragmentation; fixed via GGML_VK_SUBALLOCATION_BLOCK_SIZE=4 GiB #27734): does not apply to CUDA. The CUDA backend uses ggml_cuda_pool_vmm (contiguous 32GB virtual reservation via cuMemAddressReserve, on-demand physical mapping, LIFO free) on this card (VMM: yes in init log). There is no suballocation block splitting to tune, and no GGML_CUDA_* pool-size knob exists in the binary (all 14 GGML_CUDA_* env strings enumerated — none pool-related).
2. FA VEC→MMA kernel switch at K>=8192 (fattn.cu:617, gqa_ratio > 4 && K->ne[1] >= 8192): exists in source, but is 19x below the observed 155K cliff and cannot explain it directly.

What I have not done: Nsight/ncu profiling of the deep-position decode kernels (no CUDA toolkit profiler on this box), so I cannot say whether the time goes to a specific fallback kernel, TLB/page-table effects, or latency-bound matvecs. Happy to run any diagnostic build/flags a maintainer suggests — the model file and repro are cheap (modulo the ~80min deep bench run).

Relationship to Existing Issues

• Qwen3.8-27B (hybrid Gated DeltaNet): decode throughput collapses ~25x at context positions >~80K while prompt processing stays fast #27623 (CUDA + Qwen3.8, ~25x decode collapse at 91K): closest symptom match, but that reporter retracted (metric included prefill time); my numbers above are engine-internal llama-bench timings, not wall clock. Also their pp stayed fast while mine collapses too — possibly a different (or deeper) threshold of the same family.
• Vulkan: ~78% decode throughput cliff at 131072 context — suballocation fragmentation; fixed via GGML_VK_SUBALLOCATION_BLOCK_SIZE=4 GiB #27734 (Vulkan suballocation cliff at 131072): same model family and same depth neighborhood, but Vulkan-specific mechanism (see above for why it doesn't transfer to CUDA).
• Performance: decode attention is memory-latency-bound on Intel Xe2 (Arc Pro B70) — constant ~21-25 ns per KV position per layer, identical on Vulkan and SYCL #26581 (Xe2 memory-latency-bound decode attention): different vendor, but the only report with a backend-invariant per-KV-position constant — most compatible with my dmon observation (SM 1-2%, mem ~40%: neither compute nor bandwidth saturated while time is spent).
• Eval bug: Qwen3.8-27B decode throughput degrades ~30% within a single generation on CUDA #27444 (closed, build-env nsm=1 misread): not applicable — prebuilt official binary, and short-context numbers are healthy (a broken nsm would slow everything, not just deep positions).

Steps to Reproduce

1. Download Ternary-Bonsai-2-27B-PTQ1_0.gguf from prism-ml/Ternary-Bonsai-2-27B-gguf.
2. Official CUDA build is enough (no special flags):

   llama-bench.exe -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -fa on -p 512 -n 32 -r 1 -o md
   llama-bench.exe -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -fa on -p 512 -n 32 -r 1 -o md -d 154855

3. Compare the tg32 rows (44.68 vs 8.10). Expect ~80min wall for the deep run (all prefill).

Expected: modest depth decay (cf. 2×3090 non-repro in #27623: 40.92 → 28.68 from d0 to d131072).
Actual: ~5.5x decode and ~21x prefill collapse at d154855.

Logs

$ llama-bench.exe -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -fa on -p 512 -n 32 -r 1 -o md
| qwen35 27B PTQ1_0 - 1.75 bpw ternary (group 128) |   5.53 GiB |    26.90 B | CUDA       |  99 |   1 |           pp512 |        464.81 ± 0.00 |
| qwen35 27B PTQ1_0 - 1.75 bpw ternary (group 128) |   5.53 GiB |    26.90 B | CUDA       |  99 |   1 |            tg32 |         44.68 ± 0.00 |
build: d8f26eec7 (10683)

$ llama-bench.exe [same] -d 154855
| qwen35 27B PTQ1_0 - 1.75 bpw ternary (group 128) |   5.53 GiB |    26.90 B | CUDA       |  99 |   1 | pp512 @ d154855 |        21.87 ± 0.00 |
| qwen35 27B PTQ1_0 - 1.75 bpw ternary (group 128) |   5.53 GiB |    26.90 B | CUDA       |  99 |   1 |  tg32 @ d154855 |          8.10 ± 0.00 |
build: d8f26eec7 (10683)

Disclosure: this report was drafted with AI assistance (Muse Spark 1.3). Every number above is a measured value from the listed hardware (the deep bench run took ~80min, exit code 0); no AI-generated code is included. The hypothesis section is labeled as such — the VMM/FA-switch analysis is from reading the b11047 source, the latency-bound pointer is from #26581, neither is claimed as a diagnosis.