feat: upgrade llama.cpp from b10883 to b10902 - #430
Merged
Conversation
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
had a problem deploying
to
maven-central
September 11, 2026 06:47 — with
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
maven-central
September 11, 2026 06:47 — with
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
startgate
September 11, 2026 06:47 — with
GitHub Actions
Error
|
This was referenced Sep 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Summary
Bumps the pinned llama.cpp version from
b10883tob10902across 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.shproposedb10901as an intermediate step. Bumped straight through tob10902instead: the 23 KiB that pushes it over the line is entirelyggml/src/ggml-opencl/**(the #28268 kernel), i.e. a single backend's kernel source, not review surface. Of the 30 files, 998 lines are underggml/srcand 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/ortools/mtmd/— every row of the priority-ordered review table inCLAUDE.mdhas no input, and the three mechanicaltools/server/contract greps (request-field set + bounds, response keys) have nothing to diff. Two of the 19 commits are upstream's ownggml-cpus390x work (#28667, #28606, 291 lines), which is why thebuild-linux-s390xjob 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}(patch0012), and only by two additive enumerators (LLM_TYPE_3B_A800M,LLM_TYPE_32B_A9B) well away from the patched region. Re-verified against the pristineb10902tree rather than assumed, since the fail-loud applier detects "does not apply" but never "upstream already fixed this":0001common_params_parse_mainincommon/arg.h#ifdef _WIN32count-guardedargv = utf8.ptrs.data()override is still atarg.cpp:1282→ still required0010{"vocab_type", meta.model_vocab_type}inserver-context.cppserver-context.cpp:4554→ still required0012split_sumguard insrc/llama-model.cppsplits[i] /= split_sum;atllama-model.cpp:1491, no zero-sum guard → still requiredTest plan
test_model_split.cppfor0012,test_utils.cpp'sContentOnlyParseUtf8for0011,NativeLibraryLoadSmokeTestfor the version-constant ↔ linked-binary pin).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):
df03399b885831b2a1603b3abb0d8c156808e363plus all nine patch SHA-256s; no "does not apply cleanly" abort.ctest: 537/537 passing, matching the documented total.OAI_LAYERreader sweep included).nm -D libjllama.so: 40Java_*exports, 0 mangled symbols.NativeLibraryLoadSmokeTest— 4/4 with acleanfirst, sonativeBuildInfoMatchesPinnedVersionConstantactually compared the rebuilt binary'sb10902-df03399bagainst the newLlamaCppVersionconstant rather than a stale class.mvn test: 1755 run, 0 failures, 0 errors (269 skipped — the model-gated classes; no GGUF in this sandbox).spotless:checkclean;javadoc:jarBUILD SUCCESS.Related issues
None.
Checklist
mvn spotless:applyrun for Java changes) — no.javaformatting changes; the one Java file touched is a constant + javadoc.README.mdbadge/link,CLAUDE.mdpinned-version line (plus three incidental version mentions: the WebUI local-build recipe, the sccache section, the FetchContent source-tree section), and a newb10883–b10902pair of rows indocs/history/llama-cpp-breaking-changes.md(one for the upstream changes, one recording the patch + drop-check verification).Files changed (5)
llama/CMakeLists.txtGIT_TAG b10883→b10902llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.javaLLAMA_CPP_VERSIONconstant + 3 javadoc mentionsREADME.mdCLAUDE.mddocs/history/llama-cpp-breaking-changes.mdTODO.md:159is 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