feat!: upgrade llama.cpp from b10819 to b10850, and record the isolated macOS cause - #420
Merged
Merged
Conversation
…ed macOS cause
Two things in one change set because they belong to the same investigation: the
bump, and the documentation the run that justified it produced.
llama.cpp b10819 -> b10850
--------------------------
No project-source change. 31 commits and 466 KB in total, but the review
surface -- common/, include/, tools/server/, tools/mtmd/, ggml/include/, the
top-level CMakeLists.txt -- is 10 files, +181/-98, 27 KB. include/,
ggml/include/ and tools/mtmd/ are not touched at all.
The header moves are additive: common_log_set_jsonl plus a level_str helper and
a json.h include in common/log.{cpp,h}, and two new common_arg entries
(--log-jsonl / --no-log-jsonl) in common/arg.cpp. Nothing here calls either.
The 159 rewritten lines in tools/server/server-models.cpp are the router's
instance lifecycle, not its argv rendering, and server-models.h gains
request_stop(name).
The patch intersection was NOT empty this time, which is the part that needed
proving rather than asserting: common/arg.cpp is patch 0001's target and
tools/server/server-models.cpp is patch 0008's. A fresh rm -rf build && cmake -B
build applied all eight clean and stamped them at head f114f91f. The server wire
contract was re-checked mechanically and is byte-identical -- request-field set,
set_hard_limits bounds, and response keys in BOTH emit forms.
Chunking, recorded rather than decided quietly: with the exclusion list the
earlier rows in the history table used (ggml/src, tools/ui, docs, .github,
conversion) the diff is still 171 KB, over the runbook's 100 KiB threshold. That
figure is misleading -- the remainder is scripts/ui-assets.cmake,
tests/test-backend-ops.cpp, a new model architecture (src/models/spark2-5.cpp
plus its Jinja template) and gguf-py/, none of which this project links against
and none of which the old exclusion list names. Both numbers are in the history
row so the call is auditable instead of asserted.
macOS-15: the cause is isolated
-------------------------------
Run 33994480652 (#910, the first dispatch after the -DGGML_METAL=OFF fix) turns
the two macOS-15 jobs into a clean single-variable comparison, and they
disagree. Same runner, same OS, same -DGGML_NATIVE=OFF, identical 1742 tests /
11 skipped on both sides, differing only in GGML_METAL:
with Metal: 2 errors -- MemoryManagementTest 1 of 10, LlamaModelTest 1 of
60, both "llama_model_load: error loading model: vector"
without Metal: 0 errors, those same classes 10/10 and 60/60, and ZERO
MTL0/ggml_metal lines where the old build had 44
It is a Metal bug. The standing conclusion "the no-Metal job fails identically,
so this is not a Metal problem" was an artifact of the no-op flag and is retired.
What this does not establish is written down too: macOS 14 + Metal is green, but
that job differs in two variables at once (OS version and GGML_NATIVE), so it
cannot narrow "Metal" to "Metal on macOS 15". Only the macos-15 pair isolates
anything.
The bisect window stays b10618 -> b10797 in tags, but the candidate set collapses
to ggml/src/ggml-metal/** -- the directory every bump review in that table waved
through as "GPU backend, safe to skip". That rule is sound for compile and link
breaks and blind to runtime ones; this is the first entry where it cost
something. Metal moved in THIS range too (ggml-metal-device.m +7/-2, a new
147-line ggml-metal-tuning.cpp), which is noted without claiming it fixes
anything.
Verified locally: fresh configure clean, full build, ctest 520/520, mvn clean
verify 1742 tests / 0 failures (including NativeLibraryLoadSmokeTest, 4 tests, 0
skipped -- the guard that cross-checks LLAMA_CPP_VERSION against the linked
build-info), bytecode gate clean over llama/target (616 classes in 5 jars, 0
above major 52).
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 7, 2026 23:31 — with 
GitHub Actions
Failure
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
startgate
September 7, 2026 23:31 — with
GitHub Actions
Error
GitHub Actions
Error
bernardladenthin
had a problem deploying
to
maven-central
September 7, 2026 23:31 — with
GitHub Actions
Failure
GitHub Actions
Failure
✅ Review CompleteThis is a well-executed llama.cpp version bump with comprehensive verification and excellent documentation. Strengths
Metal Investigation QualityThe investigation conclusively shows:
No Issues Found
Expected CI state: All jobs green except |
|
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
2 participants
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
Two things, same investigation: the bump, and the documentation that run #910 produced.
llama.cpp
b10819→b10850No project-source change. 31 commits and 466 KB in total, but the review surface —
common/,include/,tools/server/,tools/mtmd/,ggml/include/, top-levelCMakeLists.txt— is 10 files, +181/−98, 27 KB.include/,ggml/include/andtools/mtmd/are not touched at all.The header moves are additive:
common_log_set_jsonlplus alevel_strhelper and ajson.hinclude incommon/log.{cpp,h}, and two newcommon_argentries (--log-jsonl/--no-log-jsonl) incommon/arg.cpp. Nothing here calls either. The 159 rewritten lines intools/server/server-models.cppare the router's instance lifecycle, not its argv rendering;server-models.hgainsrequest_stop(name).The patch intersection was NOT empty this time, which is the part that needed proving rather than asserting:
common/arg.cppis patch0001's target andtools/server/server-models.cppis patch0008's. A freshrm -rf build && cmake -B buildapplied all eight clean and stamped them at headf114f91f. Server wire contract re-checked mechanically: byte-identical — request-field set,set_hard_limitsbounds, response keys in both emit forms.Chunking, recorded rather than decided quietly. With the exclusion list the earlier history rows used (
ggml/src,tools/ui,docs,.github,conversion) the diff is still 171 KB, over the runbook's 100 KiB threshold. That figure is misleading: the remainder isscripts/ui-assets.cmake,tests/test-backend-ops.cpp, a new model architecture (src/models/spark2-5.cpp+ its Jinja template) andgguf-py/— none of which this project links against, and none of which the old exclusion list names. Both numbers are in the history row so the call is auditable instead of asserted.macOS-15: the cause is isolated
Run 33994480652 (#910) — the first dispatch after the
-DGGML_METAL=OFFfix from #418 — turns the two macOS-15 jobs into a clean single-variable comparison, and they disagree. Same runner, same OS, same-DGGML_NATIVE=OFF, identical 1742 tests / 11 skipped on both sides, differing only inGGML_METAL:MemoryManagementTest1/10,LlamaModelTest1/60, bothllama_model_load: error loading model: vectorMTL0/ggml_metallog linesIt is a Metal bug. The standing conclusion "the no-Metal job fails identically, so this is not a Metal problem" was an artifact of the no-op flag and is retired. The zero
MTL0lines also confirm #418's flag fix took effect.What this does not establish, written down too:
Java Tests macOS 14 arm64 (Metal)is green, but that job differs in two variables at once — OS version andGGML_NATIVE(macos-14 builds host-native, macos-15 passes-DGGML_NATIVE=OFF) — so it cannot narrow "Metal" to "Metal on macOS 15". Only the macos-15 pair isolates anything.What it buys. The bisect window stays
b10618 → b10797in tags, but the candidate set collapses from every upstream change to the Metal backend alone (ggml/src/ggml-metal/**) — precisely the directory every bump review in that table waved through as "GPU backend, safe to skip". That rule is sound for compile/link breaks and blind to runtime ones; this is the first entry where it cost something. Metal moved in this range too (ggml-metal-device.m+7/−2, a new 147-lineggml-metal-tuning.cpp), noted without claiming it fixes anything.Test plan
BUILD_EXIT=0ctest --test-dir llama/build→ 520/520, 0 failedmvn -f llama/pom.xml clean verify→ 1742 tests, 0 failures, 0 errors, incl.NativeLibraryLoadSmokeTest4 tests / 0 skipped — the guard that cross-checksLLAMA_CPP_VERSIONagainst the linked build-info, i.e. the one that catches a half-applied pin.github/verify-bytecode-version.sh --max-major 52 llama/target→ 616 class files in 5 jars; 0 jars over major 52f114f91fJava Tests macOS 15 arm64 (Metal)is expected to stay red. This bump neither targets nor is known to fix the Metal issue; every other job was green in #910.b10731 → b10850; two history rows (the bump, and the isolated cause); the superseded "not resolved" row now points at the new oneRelated issues / PRs
Follows #417 (b10817 → b10819) and #418 (the
-DGGML_METAL=OFFfix that made run #910's comparison meaningful).Checklist
CONTRIBUTING.mdandCODE_OF_CONDUCT.md🤖 Generated with Claude Code
https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
Generated by Claude Code