llama.cpp releases a Vulkan kernel built for one model

llama.cpp's b10712 release adds a top-k radix sort and top-k QSA fusion path for its Vulkan backend, with tests written against Qwen 3.8 Flash Next. That model's sparse-attention design made large-k sampling the slow part of inference on Vulkan, and the release exists to fix that specific bottleneck.

The same morning, build b10714 went up with a separate fix, RDNA3 mat-vec tuning locked to a static shape of 4 rows above 4 columns, aimed at Strix Halo hardware.

Neither change is a generic backend speedup. Both are written against the shape of one model or one chip. This is a change in how the codebase moves. For years llama.cpp's Vulkan and CUDA work optimized for throughput across whatever model you pointed it at. Now a release exists because one model's attention mechanism has a specific slow path, and another exists because one AMD chip has a specific memory layout.

If that pattern holds, the changelog starts reading less like a backend roadmap and more like a list of which models and chips got attention on a given day. Vulkan users on anything other than Qwen 3.8 Flash Next or Strix Halo hardware are waiting on a dedicated pass of their own, and nothing in these two builds says one's coming.