On this page · 4 sections
TL;DR
Two llama.cpp releases dated 2026-10-25 change different areas. Release b11871 makes the server answer 400 to request JSON nested more than 128 levels, where the notes say deep requests crash llama-server. Release b11873 adds initial Q2_K support to the OpenCL backend for Adreno GPUs. Operators who accept JSON from clients, and teams running Q2_K models on Adreno devices, should read both notes.
| Change | Who is affected | Action |
|---|---|---|
| JSON nesting limit of 128 levels (b11871, #30242) | Operators running llama-server with chat tools, json_schema, /completion or /v1/systemone input from clients | Upgrade to b11871 and handle HTTP 400 for deeply nested JSON |
| Initial Q2_K support in OpenCL (b11873, #30999) | Users running the OpenCL backend on Adreno GPUs with Q2_K models | Test Q2_K models on the target Adreno device |
Version b11871: Deep JSON Requests Can Crash llama-server #
The b11871 release notes say the schema builder, the jinja engine and the decision code walk request JSON recursively, and a request nested deep enough overflows the stack of the HTTP thread and llama-server dies. The notes name SIGBUS on macOS and SIGSEGV on Linux. They give the depths as a tool schema from a few hundred levels on macOS and about 10000 levels on Linux. For operators, the check matters wherever clients can reach the chat, completion or systemone endpoints. The notes do not describe how such a request would be sent, so exposure depends on who can reach your deployment.
Endpoints That Answer 400 Past 128 Levels #
The fix adds a depth check that runs before the walk and answers 400 past 128 levels. The notes list the chat inputs in common_chat_templates_apply (tools, tool-call arguments, chat_template_kwargs and json_schema), the json_schema of /completion, and the whole /v1/systemone body. Clients that send deeply nested input to any of these will receive 400 instead of a crash. The notes say the authors chose to "fix the root, not the call side", which suggests the check sits in the shared walkers rather than in each caller, though the notes do not show the code layout.
gemma4 Tool Results Stay as Text #
According to the notes, a gemma4 tool result that is too deep stays text instead of being rejected. This differs from the 400 response used for the other inputs listed above. Pipelines that expect structured tool results from gemma4 should check how a deep result arrives downstream before upgrading. This suggests that a parser expecting structured data could receive a string in that case, so test the path with a deep result.
Platform Builds Listed in the Release #
The notes list prebuilt assets for macOS, iOS, Linux, Android, Windows and openEuler, plus a UI entry. Two targets are marked DISABLED: macOS Apple Silicon with KleidiAI enabled, and the openEuler group. Confirm availability on the release page before planning a rollout to those targets. The other listed groups are:
- macOS and iOS: Apple Silicon (arm64), Intel (x64), iOS XCFramework
- Linux: Ubuntu x64, arm64 and s390x (CPU), Vulkan, CUDA 12 and 13, ROCm 10.0, OpenVINO, SYCL FP32 and FP16, Linux arm64 Snapdragon
- Android: arm64 (CPU) and arm64 Snapdragon
- Windows: x64 and arm64 CPU, arm64 OpenCL Adreno, CUDA 12 and 13, Vulkan, OpenVINO, SYCL, ROCm 10.0
Version b11873: Initial Q2_K Support Arrives in the OpenCL Backend #
The b11873 release, titled "opencl: add initial q2_k support", lists five commits. The notes state that they add a mul_mv_q2_k_f32 kernel and initial Q2_K support for the OpenCL backend. For teams with Adreno hardware, this means Q2_K models can be run through the OpenCL path these commits describe. Readers who run the OpenCL backend on Adreno GPUs should plan a test of Q2_K models on that path.
Kernel Paths Added for Q2_K #
The notes break the work into the following entries:
- mul_mv_q2_k_f32 added
- Q2_K SOA matrix-vector and tiled matrix-multiply paths added
- Q2_K noshuffle GEMM and GEMV paths for Adreno added
- Q2_K dp4a GEMM path for Adreno added
- Q2_K kernels tuned for Adreno
Checking Q2_K Performance on Adreno Devices #
The notes contain no performance figures or device test results, so the release does not show how Q2_K compares with other quantizations on Adreno. This suggests that throughput and output quality have to be measured on the target device. Run those checks before moving production traffic to a Q2_K model on the OpenCL path, since the release alone does not establish either.
Upgrade Steps for llama-server and OpenCL Adreno Builds #
Work through these steps in order, because the b11871 upgrade is the one that addresses the deep-JSON crash on llama-server.
- Find out whether your llama-server accepts tools, json_schema, chat_template_kwargs, /completion json_schema or /v1/systemone bodies from clients.
- Upgrade to b11871 for the 128-level JSON depth check, and pick the asset for your platform from the release page.
- Make client code handle HTTP 400 for JSON nested past 128 levels.
- If you use gemma4 tool results, confirm how a result that is too deep, and therefore kept as text, is handled downstream.
- If you run Q2_K models on Adreno with OpenCL, use the b11873 build and test on the target device, since the notes include no benchmarks.
Sources
- Release b11873: opencl: add initial q2_k support (#30999) · ggml-org/llama.cpp · GitHub github.com · Oct 25, 2026
- Release b11871 · ggml-org/llama.cpp · GitHub github.com · Oct 25, 2026
Edited and approved by Jarosław Krzemiński. Spotted a mistake? Report a correction or read the corrections policy.




Comments