llama.cpp b11558 Ships Same-Day OpenCL Fixes for Q4_K Kernels on Adreno GPUs
llama.cpp pushed three pre-release binary tags in under four hours on 11 October. The newest, b11558, fixes OpenCL image-limit handling for Q4_K dense bin kernels plus q4_0 broadcast and rms_norm subgroup issues. Here is what changed and how to roll it out safely.
llama.cpp, the plain C/C++ inference runtime the project describes as enabling LLM and VLM inference with minimal setup across a wide range of hardware, locally and in the cloud, shipped three pre-release binary tags in under four hours on 11 October. The newest, b11558, published by the project’s github-actions release account at 17:25 UTC, is a focused OpenCL maintenance drop. If you run Q4_K-quantized models on Adreno-class mobile GPUs, or you mix CPU and GPU backends across a fleet, this is the tag to read before you pin.
What b11558 actually changes
The b11558 release notes are short and specific. The tag contains one merged change set listing three OpenCL fixes:
- Q4_K weight images. The OpenCL backend now falls back when Q4_K weight images exceed device limits.
- rms_norm. The kernel avoids launching an incomplete subgroup.
- Dense bin kernels and q4_0. The conditions for dense bin kernels were refined, and the broadcast path for q4_0 was fixed.
All three fixes were co-authored with a Qualcomm engineer, which fits the target: the llama.cpp repository lists OpenCL as its supported backend for Adreno GPUs. The tag lists 38 release assets across macOS, Linux, Windows and Android. It was published from commit c83f305, which GitHub marks as created on GitHub.com and signed with GitHub’s verified signature, and the release page links attestation records you can check before deploying.
The afternoon’s release train
b11558 did not arrive alone. The releases index shows a rapid same-day cadence, and the two preceding tags carry their own operational weight:
| Tag | Published (UTC, 11 Oct) | Headline change |
|---|---|---|
| b11556 | 13:31 | Runtime support for Prism Bonsai 2 27B, including converter work for the model’s Hadamard-folded weights |
| b11557 | 15:10 | GGML_RPC_DEBUG becomes a numeric verbosity level (0-3) with a shared logging choke point for the RPC backend |
| b11558 | 17:25 | OpenCL Q4_K image-limit fallback, q4_0 broadcast fix, rms_norm subgroup fix |
Two of the three are quietly about operating models, not launching them. The RPC logging rework in b11557 turns the old on/off debug macro into a dial: unset or 0 disables debug logs, 1-3 emit increasingly detailed output covering handshake, buffer operations, tensor transfers, graph computes and cache decisions. Degraded-operation events such as remote allocation failure, RDMA falling back to TCP and unexpected peer disconnects are now promoted to warnings, and graph cache eviction is logged on both client and server so the incremental graph update contract stays observable. One practical footnote from the notes: llama.cpp applications drop ggml debug records unless you raise the verbosity threshold with -lv 5.
If you run distributed inference across machines with the RPC backend, the new logging is the easiest upgrade in the batch to justify:
# client or server environment
export GGML_RPC_DEBUG=2 # per-tensor transfers and per-command traces
What operators should do with a four-hour release train
The llama.cpp repository describes the project’s goal as LLM and VLM inference with minimal setup across a wide range of hardware, and the binary cadence now matches a continuous-delivery rhythm more than a traditional release cycle. That is good for bug turnaround and bad for anyone treating a local runtime as an unpinned, fire-and-forget dependency. A same-day train means your canary window is the only thing standing between a broken edge lane and your whole fleet.
A workable rollout pattern:
- Read the notes, not just the tag. Each of these tags contains one focused change set. The b11558 notes are three bullet points; skim them before promoting anything.
- Canary one lane per backend class. If you run Adreno OpenCL devices, canary b11558 there specifically — the fixes target device-limit behavior that your CUDA lanes will never exercise. Our guide to canarying every CLI upgrade covers why unpinned lanes drift in defaults and behavior long before anyone notices.
- Pin and record. Note the tag, commit hash and attestation link for every deployed runtime in a register, the same way you would track background model upgrades on adjacent local runtimes.
- Match hardware to backend deliberately. Mobile OpenCL, desktop Vulkan and CPU-only lanes fail in different ways; a local AI workstation plan that names the backend per device makes these notes actionable instead of academic.
None of these three tags is a headline feature launch. Together they show something more useful for day-to-day operations: the local-inference floor is being maintained at cadence, across model support, distributed debugging and mobile GPU correctness, with prebuilt assets ready to download the same afternoon.