Skip to content

cuda: keep the quantized K/V type in the short-query MMA FA fallback - #353

Closed
bri-prism wants to merge 1 commit into
merge/upstream-20261011from
fix/cuda-fa-quant-kv-oob
Closed

bri-prism wants to merge 1 commit into
merge/upstream-20261011from
fix/cuda-fa-quant-kv-oob

Conversation

@bri-prism

Copy link
Copy Markdown
Collaborator

Fixes an illegal memory access in CUDA flash attention with quantized K/V. Stacked on #352 (base merge/upstream-20261011); prism has the same bug and this patch applies there unchanged.

What

The short-query fallback added in #189 (ggml_cuda_flash_attn_ext_mma_f16_switch_ncols1, quantized V with 3-4 queries) always launched the F16 instance of the ncols=64 MMA kernel. When the call comes from the in-place q4_0/q8_0 K/V dispatch (head size 128/256, K and V the same type), the F16 instance converts K and V to F16 into scratch after dst, but ggml_cuda_flash_attn_ext_get_alloc_size reserves no scratch for the in-place kernels. The conversion writes past the allocation.

The fix passes type_KV through, so the fallback uses the matching in-place instance (already instantiated). The F16 and mixed-type paths and the #189 routing are unchanged.

Validation (H200, sm_90a)

Check Result
test-backend-ops -o FLASH_ATTN_EXT 4051/4051 pass (crashed before, e.g. hsk=256, nr23=[6,1], kv=1024, nb=3, q4_0/q8_0)
compute-sanitizer memcheck on the failing shapes 0 errors
test-backend-ops -o MUL_MAT 2841/2841, same as before
27B Q2_0 KLD, -fa on -ctk q8_0 -ctv q8_0, vs unpatched mean 0.000000, same top 100%
llama-bench q8_0 KV, pp512 / tg128 no change
sm_89 compile of the affected instances clean

MUL_MAT_ID still fails 4 f16 dup=1 cases on CUDA, identically on unmodified upstream master; unrelated to this change.

The Q length 3-4 quantized-V fallback in
ggml_cuda_flash_attn_ext_mma_f16_switch_ncols1 always launched the F16
instance of the ncols=64 kernel. When the call came from the in-place
q4_0/q8_0 K/V dispatch (hs 128/256, K and V the same type), that F16
instance converts K and V to F16 into scratch after dst, but
ggml_cuda_flash_attn_ext_get_alloc_size reserves no such scratch for the
in-place kernels. The conversion then wrote past the dst allocation and
FLASH_ATTN_EXT hit an illegal memory access (e.g. hsk=256, nr23=[6,1],
kv=1024, nb=3, q4_0/q8_0).

Pass type_KV through so the fallback uses the matching in-place instance.
@bri-prism

Copy link
Copy Markdown
Collaborator Author

Superseded by #355, which merged the same fix with tests.

@bri-prism bri-prism closed this Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant