feat: upgrade llama.cpp to b11012

[bernardladenthin]

Summary

• Upgrades llama.cpp b10988 → b11012 (24 commits, 206 KiB, 65 files), walked in four chunks. The tail chunk is 13 KiB and was kept separate on purpose: folding it into the third makes one 100.6 KiB step — over the runbook's threshold by a hair, and "barely over" is the rationalisation the threshold exists to prevent.
• Two files on the priority review list, both common/ implementation behind unchanged signatures. #28849 (common/fit.cpp) is the one with teeth — an auto-sized context (-c 0) with --parallel > 1 and a unified KV cache now gets n_ctx_train * n_seq_max instead of n_ctx_train.
• The first range in a while where a patch target actually moved. #27625 adds a whole architecture (HrmTextForCausalLM) and edits src/llama-model.{cpp,h} — patches/0012's targets. The collision was checked, not assumed, and 0012's anchor shifted 1493 → 1518 underneath it.

The four chunks

Step	Size	Contents
b10988 → b11002	75 KiB, 14 commits	#28849 fit.cpp auto-context sizing, #28869 qwen3-coder \n</think>, #28901 qwen4exp hc ops, CUDA/HIP/Vulkan/Metal/hexagon/RPC backend work
b11002 → b11005	33 KiB, 3 commits	#27625 HrmTextForCausalLM (DFM Mimir 1B), #28989 Nemotron-H, #28995 hexagon rope probe
b11005 → b11011	88 KiB, 6 commits	#28549 CUDA graph for MTP draft, #28981 SYCL signature fix, #28975 NV argsort workaround, #28965 TP split state, #28994 hexagon K-quants
b11011 → b11012	13 KiB, 1 commit	#28988 Vulkan support for the qwen4exp hc ops added in chunk 1

Neither common/ change is a compile or link consequence — both are implementation-only in TUs upstream compiles into llama-common. Nothing here calls common_params_fit_impl directly (it's reached via common_init_from_params when n_ctx == 0), so #28849 surfaces as "an auto-sized parallel server may now ask for more context" — upstream's intended fix, not a regression to absorb.

Zero tools/server/ files moved, so the three mechanical server-contract greps have no input: the request-field set, its set_hard_limits bounds and the emitted response keys cannot have changed.

Two ggml/include headers move and both were opened rather than waved past. ggml.h is purely additive (a new ggml_dsv4_hc_pre_gated plus a comment — no existing signature moves, and this project calls no ggml_dsv4_*). ggml-sycl.h's ggml_backend_sycl_split_buffer_type gains a leading int main_device — a real signature break, but of a backend-internal symbol no project code calls; the three sycl-* classifier jobs compile upstream's own self-consistent tree. src/llama-context.h is an internal header this project does not include (the only internal one it does is src/llama-model.h, from test_model_split.cpp), and #28549's change there is a private member.

The patch-collision check (patches/0012)

#27625 edits src/llama-model.cpp in three places — an LLM_ARCH_HRM_TEXT case in llama_model_mapping, a MIRRORED meta-split branch for that arch's aliased cache slots, and a rope-type case — at roughly lines 316, 477 and 3030. patches/0012's hunks are the load_tensors split arithmetic at 1493–1518. A thousand lines apart, and src/llama-model.h gains only an additive hrm_z_l_init member.

Worth noting for the next bump: 0012's anchor moved 1493 → 1518 under the new arch code. That is exactly why the drop-checks are written to match content rather than a line number.

Test plan

• Affected unit / integration tests pass locally
• CI is green on this branch — the full matrix cannot run automatically here; see the note below
• Docs / CHANGELOG updated where applicable — two rows appended to docs/history/llama-cpp-breaking-changes.md

Verified at the target tag from a fresh configure (rm -rf build, real FetchContent path):

Check	Result
Configure	clean; stamp head 35822afe58475e0506cd51e6573903e46d4c67c9 (= b11012) with nine SHA-256 lines
verify-patches-applied.sh	9 applied, tree dirty, patches/0010 cast present
Wire-name extraction	138 CLI / 57 request / 15 trainer — unchanged
Release build	clean, 0 errors, 0 warnings
ctest	551/551
nm -D	40 Java_* exports, 0 C++-mangled
NativeLibraryLoadSmokeTest	4/4, 0 skipped after a clean — cross-validates LLAMA_CPP_VERSION against the linked build-info
mvn test	1763 tests, 0 failures
SpotBugs / spotless / javadoc:jar	0 bugs, clean, clean

All six standing drop-checks run against the pristine tag — all still required, none droppable:

0001 (common_params_parse_main 0 occurrences in b11012:common/arg.h, WIN32 override still at common/arg.cpp:1282) · 0002 (load_progress_callback still unguarded at server-context.cpp:1095) · 0003/0006/0008 (get_slot_prompt_similarity, llama_server_set_embedded, LLAMA_SERVER_WORKER_CMD all absent from b11012:tools/server/) · 0010 (vocab_type still uncast at server-context.cpp:4554) · 0012 (bare splits[i] /= split_sum; still at src/llama-model.cpp:1518)

This is also the first bump to exercise the verify-patches-applied.sh fix from #438 — the guard that had been failing on every correct tree now passes on a real build, as it always should have.

Note

The full Publish matrix will not run on this PR automatically — it is dispatch-only in practice here (recent push-to-main and pull_request runs are cancelled in the startgate abort window). Validating the branch end-to-end needs a workflow_dispatch with publish_to_central left at its default false.

The same four checks will be red and none is from this diff — all inherited, triaged in detail on #437: claude-review (account-side credentials), both Verify GPG signing key jobs (environment: maven-central secrets are not delivered on a pull_request event, which publish.yml documents as an expected red), and analyze/CodeQL (KotlinVersionTooRecentError on Kotlin 2.4.20, red on main).

Related issues / PRs

Follows #438. No upstream issue — nothing in this range required a report.

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits
• No security-sensitive changes

🤖 Generated with Claude Code

https://claude.ai/code/session_01Cft7guQngfyKycdJfBEfJP

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud