llama.cpp b11724 Fixes a CUDA Flash‑Attention Race; b11723 Reworks Hexagon Paths

What the two releases list #

The two release pages follow the same layout: a short list of changes at the top, then a build matrix of platform artifacts. The changes themselves are small in number. Release b11724 lists one headline change, and Release b11723 lists one headline change with three sub-items. The table below maps each item to the people who should look at it.

The CUDA fix in b11724 #

The headline entry in Release b11724 reads "CUDA: fix shared-memory WAR hazard in flash_attn_ext_vec ( #30573 )". The commit text beneath it gives more detail: it describes a "KQ write-after-read race" in the same kernel. The notes also contain a follow-up commit titled "CUDA: apply review suggestions for KQ sync comments," and list two co-authors, both shown as Johannes Gäßler.

The notes state the change and its location, but they do not include benchmark numbers, reproduction steps, or a description of the observed symptom. The release text therefore supports only the statement that a write-after-read hazard in the shared-memory path of flash_attn_ext_vec was fixed. Any claim about how often it appeared or what it broke would go beyond the source.

The commit text also includes an "Assisted-by: ChatGPT" line. The notes do not say how that assistance was used, so readers should treat the line as metadata and nothing more.

The Hexagon changes in b11723 #

Release b11723 lists the headline "hexagon: FLASH_ATTN_EXT improvements for longer context and SWA models ( #30731 )" and then three hex-fa items. The first is "support for masked block skipping to reduce DMA fetching." The notes give that as the purpose of the change, and they do not give measured DMA volumes or throughput figures.

The second item is "finetuning the hmx->hvx crossover thresholds (boosting gemma-4)." The parenthetical is the release's own wording. It names gemma-4 as the model the tuning is labelled with, but it provides no before-and-after measurements, so this article cannot state how large any gain was or on which hardware it was measured.

The third item is "update hmx gate to account for mdev.count." The notes name the variable but do not explain the gate logic. Teams with multi-device Hexagon setups should check device selection directly rather than assume the behaviour from the changelog.

Reading the build matrices #

Both releases carry the same overall matrix of artifacts. For this upgrade, the entries that matter most are the CUDA and Snapdragon rows. In Release b11724, the Linux CUDA artifacts are listed as Ubuntu x64 (CUDA 12) with CUDA 12.8 libraries, Ubuntu x64 (CUDA 13) with CUDA 13.4 libraries, and Ubuntu arm64 (CUDA 13) with CUDA 13.4 libraries. The Windows CUDA entries are listed as CUDA 12.4 DLLs and CUDA 13.4 DLLs for x64, and CUDA 13.4 DLLs for arm64.

Release b11723 lists the Snapdragon artifacts for Linux arm64 and Android arm64, each described as "CPU, Adreno GPU, Hexagon NPU," with a setup guide link for each. Those are the artifacts that match the Hexagon changes above.

The flattened text of the matrices contains a "DISABLED" label near the macOS and openEuler entries. The extracted text does not make clear which entry each label applies to, so this article does not draw a conclusion from it. Check the live release page if you depend on those platforms.

Upgrade checklist #

1. Record the llama.cpp version currently deployed, and whether it is a CUDA or Hexagon build.
2. If you run CUDA with flash attention, read the b11724 entry for #30573 and confirm which artifact matches your CUDA major version: CUDA 12.8 libraries, CUDA 13.4 libraries, or the Windows DLLs listed for CUDA 12.4 and 13.4.
3. If you run Snapdragon Hexagon builds on long-context or SWA models, read the three b11723 hex-fa items and map each to a workload you actually run.
4. Stage the new artifact on a non-production device for the target platform, then run your own prompts and long-context inputs.
5. Compare output quality and latency against your current build using your own model, and record the numbers. The release notes do not supply comparison figures.
6. If you run a multi-device Hexagon setup, confirm device enumeration and selection after the mdev.count gate change.
7. Roll out to production only after the staged tests pass, and keep the previous artifact available for rollback.

What remains unknown #

The two notes establish what changed, where, and in which artifacts, but they do not establish the impact on any particular workload. They give no reproduction for the CUDA race, no benchmark for the Hexagon changes, and no statement of which earlier builds contained the problems. Any conclusion about those points would need a separate source or your own testing.