Skip to content

feat: upgrade llama.cpp from b10883 to b10902 - #430

Merged
bernardladenthin merged 1 commit into
mainfrom
claude/llama-cpp-b10902
Sep 11, 2026
Merged

feat: upgrade llama.cpp from b10883 to b10902#430
bernardladenthin merged 1 commit into
mainfrom
claude/llama-cpp-b10902

Conversation

@bernardladenthin

Copy link
Copy Markdown
Owner

Summary

Bumps the pinned llama.cpp version from b10883 to b10902 across all four pin sites, and appends the upgrade range to the breaking-changes history.

Diff size / chunking decision. The range is 110 KiB / 19 commits / 30 files — nominally over the runbook's 100 KiB threshold, so llama-next-version.sh proposed b10901 as an intermediate step. Bumped straight through to b10902 instead: the 23 KiB that pushes it over the line is entirely ggml/src/ggml-opencl/** (the #28268 kernel), i.e. a single backend's kernel source, not review surface. Of the 30 files, 998 lines are under ggml/src and 93 lines span the 13 project-relevant files. Same reasoning as the b10870 → b10878 step.

API-compat review: vacuously clean. Zero files changed under common/*.h, include/, tools/server/ or tools/mtmd/ — every row of the priority-ordered review table in CLAUDE.md has no input, and the three mechanical tools/server/ contract greps (request-field set + bounds, response keys) have nothing to diff. Two of the 19 commits are upstream's own ggml-cpu s390x work (#28667, #28606, 291 lines), which is why the build-linux-s390x job is the one worth watching.

Patches: all nine still apply, and the three drop-checks all still say "required". The only patch target that moved at all is src/llama-model.{cpp,h} (patch 0012), and only by two additive enumerators (LLM_TYPE_3B_A800M, LLM_TYPE_32B_A9B) well away from the patched region. Re-verified against the pristine b10902 tree rather than assumed, since the fail-loud applier detects "does not apply" but never "upstream already fixed this":

Patch Check Result at b10902
0001 common_params_parse_main in common/arg.h 0 occurrences; the #ifdef _WIN32 count-guarded argv = utf8.ptrs.data() override is still at arg.cpp:1282still required
0010 {"vocab_type", meta.model_vocab_type} in server-context.cpp still uncast at server-context.cpp:4554still required
0012 split_sum guard in src/llama-model.cpp still a bare splits[i] /= split_sum; at llama-model.cpp:1491, no zero-sum guard → still required

Test plan

  • Tested locally
  • Added/updated tests — no new tests; this is a pin bump. The existing guards are the test plan (test_model_split.cpp for 0012, test_utils.cpp's ContentOnlyParseUtf8 for 0011, NativeLibraryLoadSmokeTest for the version-constant ↔ linked-binary pin).
  • CI passes

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

  • Patch applier — stamp records upstream head df03399b885831b2a1603b3abb0d8c156808e363 plus all nine patch SHA-256s; no "does not apply cleanly" abort.
  • C++ unit suitectest: 537/537 passing, matching the documented total.
  • Wire-name extraction — 138 CLI names / 57 request fields / 15 trainer keys, all contracts satisfied (the configure-time OAI_LAYER reader sweep included).
  • JNI surfacenm -D libjllama.so: 40 Java_* exports, 0 mangled symbols.
  • NativeLibraryLoadSmokeTest — 4/4 with a clean first, so nativeBuildInfoMatchesPinnedVersionConstant actually compared the rebuilt binary's b10902-df03399b against the new LlamaCppVersion constant rather than a stale class.
  • Full Java suitemvn 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

None.

Checklist

  • Code follows project style (mvn spotless:apply run for Java changes) — no .java formatting changes; the one Java file touched is a constant + javadoc.
  • Documentation updated — README.md badge/link, CLAUDE.md pinned-version line (plus three incidental version mentions: the WebUI local-build recipe, the sccache section, the FetchContent source-tree section), and a new b10883–b10902 pair of rows in docs/history/llama-cpp-breaking-changes.md (one for the upstream changes, one recording the patch + drop-check verification).
  • No breaking changes — none to this project's API; no upstream API surface this project consumes moved at all.
Files changed (5)
File Change
llama/CMakeLists.txt GIT_TAG b10883b10902
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 rows

TODO.md:159 is deliberately left reading "Counts are from the b10883 pin" — it records the provenance of a measurement, and the request schema is byte-unchanged at b10902, so the numbers it cites still hold.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH


Generated by Claude Code

No project-source change, and not one file on the priority review list moved.

110 KiB / 19 commits / 30 files, which is over the runbook's 100 KiB chunking
threshold -- so the decision to bump straight through is recorded rather than
taken quietly. llama-next-version.sh proposed stopping at b10901 (87 KiB); the
23 KiB that pushes b10902 over is entirely ggml/src/ggml-opencl/** -- one
CMakeLists line, ggml-opencl.cpp, and a new gemv_noshuffle_q4_0_f32_32b_trans.cl
kernel (#28268). Bucketed by top-level directory the range is 998 lines of
ggml/src backend internals against 93 lines across 13 files of everything this
project compiles, links or includes. Chunking would have split a backend-kernel
addition in half and reviewed nothing extra.

Zero files under common/*.h, include/, tools/server/ or tools/mtmd/, so every
row of the API-compatibility table is vacuously satisfied and 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 moved. The one
common/ file in the range is speculative.cpp, an implementation TU compiled by
upstream, not a header this project includes; its change is internal to the
DFlash draft path (#28587) and moves no signature.

Every patch-target file is byte-unchanged except src/llama-model.{cpp,h},
verified by diffing those paths explicitly rather than inferred from the
aggregate -- and that diff is two additive llm_type enumerators
(LLM_TYPE_3B_A800M, LLM_TYPE_32B_A9B) nowhere near patches/0012's hunks.

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

  * 0001 -- common_params_parse_main appears 0 times in b10902:common/arg.h and
    the #ifdef _WIN32 argv = utf8.ptrs.data() override is still at
    common/arg.cpp:1282. Still required.
  * 0010 -- b10902:tools/server/server-context.cpp:4554 still emits
    {"vocab_type", meta.model_vocab_type} uncast, so the common_json
    enum-to-bool trap is still live. Still required.
  * 0012 -- b10902:src/llama-model.cpp:1491 still normalises with a bare
    splits[i] /= split_sum; and carries no split_sum == 0 guard. Still required.

Worth knowing for the s390x job: two of the 19 commits are upstream's own
ggml-cpu s390x work (#28667 q4_0 repack, #28606 Q1_0 vector intrinsics, 291 new
lines under ggml/src/ggml-cpu/arch/s390/). Those are upstream's big-endian
kernels; the build-linux-s390x qemu ctest gate covers this project's own
endian-sensitive layer, which the range does not touch.

Verified: fresh rm -rf build && cmake -B build -DBUILD_TESTING=ON through the
real FetchContent path, configure clean, stamp written at head df03399b8 (=
b10902) with all nine hashes; Release build clean; ctest 537/537, including the
seven LlamaModelSplits.* cases that are the only place 0012's extracted
functions are linked and the six wire-contract cases whose configure-time
OAI_LAYER reader sweep re-ran against b10902 (138 CLI / 57 request / 15 trainer
names, unchanged); nm -D reports 40 Java_* exports and 0 C++-mangled ones;
mvn -pl llama clean test -Dtest=NativeLibraryLoadSmokeTest 4/4, 0 skipped,
including nativeBuildInfoMatchesPinnedVersionConstant; full mvn test 1755 tests,
0 failures; SpotBugs 0, spotless and javadoc:jar clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
@bernardladenthin
bernardladenthin merged commit adb3937 into main Sep 11, 2026
8 of 14 checks passed
@bernardladenthin
bernardladenthin deleted the claude/llama-cpp-b10902 branch September 11, 2026 06:47
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants