llama.cpp发布b11302：修复glm5-next稀疏索引器多线程写冲突
该补丁让每个失效索引槽写入独立行n_kv + slot，避免填充池、缺失序列和尾部单元格争用同一sentinel行导致ThreadSanitizer报出的数据竞争。
AI解读：llama.cpp发布构建b11302，核心改动是给glm5-next的稀疏索引器掩码中每个失效槽分配独立scatter行，修复sanitize CI中ThreadSanitizer报出的数据竞争。
问题出在多个失效来源——填充池、缺失序列、缺失尾部单元格——都指向同一个n_kv sentinel行，被top_k选中的不可见池又与token尾部单元格重叠，导致多个CPU线程写同一元素。
改动同时为两条选择路径分配槽掩码，活跃槽仍指向互不重叠的单元，因此一个token的scatter索引保持唯一。
该版本照例附带macOS、Linux、Windows、Android等多平台预编译二进制，包括CUDA 12/13、Vulkan、ROCm 10.0、OpenVINO、SYCL等后端；KleidiAI的macOS Apple Silicon构建与openEuler构建仍为DISABLED状态。
依据是GitHub Releases页面的发布说明与摘要，未包含该修复在实际推理性能或正确性上的基准数据。
llama.cpp发布b11302构建，附带一项针对glm5-next的修复：为稀疏索引器掩码中的每个失效槽分配唯一的scatter行，提交标题为 “glm5-next: give dead indexer slots unique scatter rows (#29745)”。
发布说明指出，该稀疏索引器掩码通过set_rows scatter构建。此前填充池、缺失序列和缺失尾部单元格都指向同一个n_kv sentinel行；被top_k选中填充选择的不可见池会与token的尾部单元格重叠，导致多个CPU线程写入同一元素，在sanitize CI中触发ThreadSanitizer数据竞争报告。
修复方式是为两条选择路径都分配槽掩码，并把每个失效槽路由到自己的dump行n_kv + slot。活跃槽指向互不重叠的单元，因此一个token的scatter索引保持唯一。
该版本提供的构建产物
发布页列出各平台预编译包。macOS/iOS提供Apple Silicon arm64、Intel x64和iOS XCFramework；其中启用KleidiAI的macOS Apple Silicon构建标记为DISABLED，链接指向PR 23780。
- Linux：Ubuntu x64/arm64/s390x CPU，Vulkan x64/arm64，CUDA 12.8与CUDA 13.4（x64/arm64），ROCm 10.0 x64，OpenVINO 2026.4 x64，SYCL FP32/FP16 x64，以及Snapdragon（CPU、Adreno GPU、Hexagon NPU）arm64构建。
- Android：arm64 CPU与Snapdragon（CPU、Adreno GPU、Hexagon NPU）arm64构建，附设置指南链接。
- Windows：x64/arm64 CPU、arm64 OpenCL Adreno、CUDA 12.4/13.4（x64/arm64）、Vulkan x64、OpenVINO 2026.4 x64、SYCL x64、ROCm 10.0 x64。
- openEuler：x86 310p、x86 910b ACL Graph、aarch64 310p、aarch64 910b ACL Graph均标记为DISABLED，链接指向PR 23705。
- UI包：llama-b11302-ui.tar.gz。
已知限制与说明
发布内容只陈述了索引器scatter的数据竞争修复与二进制清单，未提供该改动对推理速度或输出正确性的实测数据。macOS Apple Silicon的KleidiAI构建和openEuler全部构建处于禁用状态，相关链接分别对应PR 23780与PR 23705。