Model inference software llama.cpp b12291 expands cache processing optimization that reuses previous computation results. It broadens optimization coverage in the Vulkan computation path and fixes an error that misclassified some data sizes. The developers observed large speed gains at certain sizes. They said the bug fix should help even when the new optimization is not applied.
1. More paths can use cached data for computation
The change in this release expands the Vulkan paths that can use key-value cache dequantization optimization. A key-value cache stores previous computation results for reuse. Dequantization converts compact, compressed data into a form usable for computation. This change focuses on expanding the execution paths that can use this optimization.
This optimization is also allowed on the coopmat2(CM2) path. Its selection follows a heuristic based on the query token count multiplied by the GQA ratio. The GQA ratio is the ratio of query heads to key-value heads. Attention computes relationships between input elements. Both input length and the head configuration of this operation influence optimization selection.
For Vulkan users, the relevant change is not just the name of the execution environment but which processing path is selected for actual workloads. The two factors in the release notes help developers interpret the change in terms of their own inputs and model configurations. Even within the same Vulkan environment, examining both query token counts and model head configurations is a starting point for understanding this change.
2. An error misclassifying aligned data was corrected
The developers said they observed very large speed gains at certain head sizes during their work. A head is a unit that handles part of an attention operation. The release notes explain that these sizes had been incorrectly treated as unaligned and were fixed to be treated as aligned.
Alignment checks determine whether data follows memory spacing and positioning suitable for computation. Since GQA uses nbq2 as its stride, or data access interval, the alignment check was corrected to inspect this value too. The change corrects the reference value used to check alignment rather than rearranging the data.
The developers expect the alignment fix to help even when the dequantization optimization is not applied. Developers running Vulkan environments can therefore examine the effects of the alignment check fix independently of whether the new cache processing path is used.
3. Performance benefits and adoption testing need joint assessment
The release notes provide no throughput figures, speedup factors, or details of the hardware, models, and settings used for measurement. To translate potential performance benefits into an adoption decision, plan tests against the previous version using your own models and inputs.
4. Published Vulkan builds let users examine the changes
b12291 was published as a prerelease on November 11, 2026. Users evaluating this version can select a Vulkan build matching their operating system and processor configuration from the release page's asset list.
The Ubuntu asset list includes Vulkan builds for x64 and arm64. The Windows list also offers Vulkan builds for the same two architectures. Users of these environments can examine the changes starting with the published packages. Since the asset list distinguishes both operating systems and processor architectures, check both when selecting a file.
The core of b12291 is broader coverage for Vulkan cache optimization alongside a fix to alignment checks that matters even outside that optimization.
