feat: upgrade llama.cpp from b10905 to b10909

[bernardladenthin]

Summary

• Bumps the pinned llama.cpp version from b10905 to b10909 (the latest upstream release) across all four pin sites, and appends two row pairs to the breaking-changes history.
• Chunked into two commits, because git diff b10905 b10909 is 149 KiB — over the runbook's 100 KiB per-step threshold. .github/scripts/llama-next-version.sh selected b10908 as the largest intermediate tag under it.
• Unlike the last three bumps, this range is not empty on our review surface: it renames a struct field on priority row 3, and it edits a file one of our patches also patches.

Commit	Step	Upstream	Size
4ab0f5e	b10905 → b10908	3 commits, 8 files	40 KiB
f87c2dc	b10908 → b10909	1 commit, 26 files	111 KiB

Chunk 1 (b10905 → b10908) — one real API-compat hit, contained

Upstream	What it is
#28715	"server: fix speculation after an image" — common/speculative.{h,cpp}, examples/speculative-simple, one line of tools/server/server-context.cpp
#28630	MTP context KV-cache allocation for deepseek2/glm4moe — src/llama-model.cpp
#28692	Metal: idle threads in the remaining iq mul_mv kernels for ne00 < 1024

common/speculative.h (priority row 3) renames common_speculative_draft_params::n_past to pos0, and server-context.cpp's designated-initializer call site follows it (slot.prompt.n_tokens() → slot.prompt.tokens.pos_next()).

This needs no project-side change, verified rather than assumed: grep over llama/src/main/cpp/ finds zero references to common_speculative, draft_params or n_past. The only consumer is upstream's own server-context.cpp, which we compile into libjllama and which upstream updated in the same commit — so the rename lives entirely inside upstream translation units.

src/llama-model.cpp is a patches/0012 target, but its diff sits in create_memory (~line 2644), not load_tensors (~1491), so the hunks do not meet.

Chunk 2 (b10908 → b10909) — larger, but zero priority-list files

One commit, #28164 ("metal : single-source fusion table + fusion debug rework"): a new ggml-metal-fusion.{cpp,h} pair (606 lines), reworked ggml-metal-ops.cpp, 2 lines of src/llama-context.cpp, three src/models/*.cpp, and test/CI scaffolding.

None of common/, include/, tools/server/ or tools/mtmd/ is touched, so every row of the API-compatibility table has no input. The tests/* files are applied but never compiled here — a FetchContent subproject builds with LLAMA_BUILD_TESTS=OFF, the same reason 0001's and 0012's upstream tests are inert. The real gate for this chunk is the three macOS arm64 jobs, where the reworked Metal fusion path is actually compiled and run.

Patches: all ten apply, and the collision candidate was checked

Chunk 2 edits tests/CMakeLists.txt — which patches/0012 also patches. Rather than infer, all ten patches were applied in filename order to a pristine b10909 worktree before anything else was touched: all ten applied cleanly, 0012 included, so the two hunks do not collide.

All four standing drop-checks were run against the pristine tag, because the fail-loud applier detects "does not apply" but never "upstream already fixed this":

Patch	Check	Result at b10909
0001	common_params_parse_main in common/arg.h	0 occurrences; WIN32 argv = utf8.ptrs.data() override still at common/arg.cpp:1282 → still required
0010	{"vocab_type", meta.model_vocab_type}	still uncast at server-context.cpp:4554 → still required
0012	split_sum zero guard	still a bare splits[i] /= split_sum; at src/llama-model.cpp:1491 → still required
0013	the three s390x VXE helpers	still unguarded at lines 73/77/83, between the guard blocks at 28 and 100 → still required

0013 was filed upstream during this bump as ggml-org/llama.cpp#28775 ("ggml-cpu(s390x): guard VXE-only repack helpers"), approved by the s390x maintainer and open at the time of writing. The history row now records what happens when it merges: the first tag carrying it makes the applier abort the configure on every platform, and the response is to delete 0013, not refresh it (the 0009 precedent at b10280).

Test plan

• Affected unit / integration tests pass locally
• CI is green on this branch
• Docs / CHANGELOG updated where applicable

Verified locally on Linux x86_64 from a fresh configure (build directory removed first, so the applier took its clean-tree path and wrote a new stamp):

• Patch applier — stamp at head a2878d30df0130dde503a7d9ba30d3d21bd71b9f (= b10909) with all ten SHA-256 lines; no "does not apply cleanly" abort.
• Build — full cmake --build --config Release, zero errors.
• C++ unit suite — ctest: 537/537.
• Wire-name extraction — unchanged at 138 CLI / 57 request / 15 trainer names (10 OAI_LAYER keys swept for upstream readers against b10909's sources), so no registry drifted.
• JNI surface — nm -D: 40 Java_* exports.
• NativeLibraryLoadSmokeTest — 4/4, 0 skipped, run after a clean so nativeBuildInfoMatchesPinnedVersionConstant compared the rebuilt binary against the new constant rather than a stale class.
• Full Java suite — mvn test: 1755 run, 0 failures, 0 errors (269 skipped — the model-gated classes; no GGUF in this sandbox).
• Gates — SpotBugs 0 findings; spotless:check clean; javadoc:jar BUILD SUCCESS.

Related issues / PRs

Refs ggml-org/llama.cpp#28775 — the upstream carry of patches/0013, filed during this bump.

Checklist

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

Files changed (5, both commits combined)

File	Change
llama/CMakeLists.txt	GIT_TAG b10905 → b10909
llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java	LLAMA_CPP_VERSION constant + 3 javadoc mentions
README.md	badge + link
CLAUDE.md	pinned-version line + 3 incidental mentions
docs/history/llama-cpp-breaking-changes.md	two appended row pairs (one per chunk)

CHANGELOG.md is deliberately untouched: it records consumer-visible behaviour, and llama.cpp pin bumps are not recorded there.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH

---

Generated by Claude Code

[bernardladenthin]

Standing non-PR check failures on this branch

Recording these once so they are not re-diagnosed per bump. None is caused by this diff — which changes five files: a CMake tag, a Java constant, and three docs.

Check	Why it fails	This PR's?
Verify GPG signing key (no secrets printed)	Declares environment: maven-central (publish.yml:119). GitHub refuses to start a job whose environment is not available on a PR branch — it failed in 2 s, with no steps executed.	No
Verify GPG signing key — Gradle/BouncyCastle path	Same, publish.yml:233. Also 2 s.	No
analyze (CodeQL java-kotlin)	The extractor aborts inside kotlinc: "Kotlin version 2.4.20 is too recent. CodeQL currently supports versions below 2.4.20." That fails mvn compile for llama-kotlin, hence the whole reactor, so CodeQL reports a configuration error and produces zero results for the repository. Tracked upstream as github/codeql#22381.	No
claude-review	API-side rejection before any model call (num_turns: 1, total_cost_usd: 0, empty modelUsage). Failing on every run since 2026-09-09.	No
License Compliance (commit status)	14 issues, repo-wide and long-standing — the identical status with the identical count sits on merged PRs #430 and #432.	No

Not re-running any of them. A re-run is for distinguishing a flake from a real failure; all five are deterministic by construction (an environment gate, a toolchain version bound, an API rejection, a repo-wide scan), so re-running would consume CI minutes and change nothing.

No fix is ported into this PR, because for each the fix lives outside a llama.cpp version bump and would widen it:

• the two GPG jobs would need if: github.event_name != 'pull_request', which is a release-safety decision about when the signing key is verified;
• CodeQL needs either upstream Kotlin 2.4.20 support or an extractor/scan-scope change;
• claude-review and License Compliance are configuration outside this repository's build.

The checks that do gate this change — C++ Tests, the platform build/test matrix, Java Tests *, the fat-jar smokes — run behind Start gate (abort window) and are reported separately.

---

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