chore(deps): update ghcr.io/ggml-org/llama.cpp:server-cuda docker digest to e80ed28

[renovate]

This PR contains the following updates:

Package	Update	Change
ghcr.io/ggml-org/llama.cpp	digest	8d1e8dd → e80ed28

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[claude]

• Risk: LOW — digest-only bump of the ggml-org/llama.cpp:server-cuda rolling tag (now server-cuda12-b9976, built ~2h before this PR). This image is rebuilt from master continuously (10-20+ builds/day), so the digest jump spans ~3.5 weeks and hundreds of commits since the prior pin (2026-06-19) — there's no single versioned changelog to diff, it's effectively tracking nightly. More importantly, controllers.llamacpp.replicas is 0 (per the in-file comment, this experiment is parked/abandoned), so blast radius is zero either way.
• Breaking changes: Unable to produce a meaningful changelog — llama.cpp doesn't publish curated release notes for continuous rolling builds, and diffing ~200+ commits of an actively-developed server is not actionable here. The CLI flags this HelmRelease depends on (--hf-repo, --hf-file, -ngl, -c, -fa on, --host/--port, --alias) are long-stable core server args, not recently touched per spot-checking recent release titles. Since the controller is scaled to 0, no breaking behavior can actually manifest from this merge.
• Action needed: None to merge safely on green. If replicas is ever flipped back to 1 to resume the Gemma 26B-A4B experiment, do a fresh smoke test (auto-download via --hf-repo/--hf-file, -fa on still needs a value, /health probe timing) before trusting it, since this particular digest hasn't been runtime-verified against ~3.5 weeks of upstream changes.

[claude]

• Risk: LOW — digest-only bump on the rolling server-cuda tag (no semver, roughly b9xxx-range of nightly builds over ~3.5 weeks). replicas: 0 in this HelmRelease (app parked, Gemma-4 experiment abandoned), so blast radius is effectively zero even if something regressed.
• Breaking changes: Could not correlate the two digests to exact commit SHAs (ghcr manifest API not reachable from this environment), so I reviewed tools/server history over the relevant window instead. Nothing affecting this repo's usage:
  • --hf-repo/--hf-file auto-download: refactored to a dedicated child process (#24834), but external behavior, LLAMA_CACHE handling, and startup timing are unchanged per the PR description.
  • --no-mmproj-auto multimodal-detection tweak (#25590) doesn't apply — this config relies on default vision auto-enable via --hf-repo, not --no-mmproj-auto.
  • No changes found to -fa, -ctk/-ctv, -ngl, --host/--port/--alias, or /health.
• Action needed: None — safe to merge on green. (Note: since replicas: 0, green here just means the manifest applies cleanly; the new image won't actually be exercised until this controller is scaled back up.)

[claude]

Risk: LOW — digest-only bump on the rolling server-cuda tag (2026-06-19 → ~2026-07-14 build), no version/semver change. llamacpp controller is currently parked at replicas: 0 (Gemma 26B experiment abandoned per in-file comment), so blast radius on the live cluster is nil even if something did regress.

Breaking changes: Scanned llama.cpp master/server commit history for the window. The one relevant change is the model-handling refactor (ggml-org/llama.cpp#24980, merged 2026-06-25), which:

• removed --skip-download in favor of --offline — not used here, no effect.
• regressed draft/MTP model resolution and split-GGUF (*-00001-of-000NN.gguf) loading — this repo uses a single-file --hf-repo/--hf-file pull (unsloth/gemma-4-26B-A4B-it-qat-GGUF, gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf), no draft model, no split files, so it's outside the affected paths. Follow-up fixes (#25039, #25043, #25194) landed shortly after anyway.
• No changes found to -fa, -ngl, -c, --host/--port/--alias, or the /health endpoint used by this HelmRelease's probes.

Couldn't enumerate every intermediate build (llama.cpp cuts many per day on this rolling tag), so this is based on server/model-loading-relevant commits in range rather than a full diff — flagging that limitation rather than guessing further.

Action needed: none, safe to merge on green. If/when replicas is flipped back to 1, worth a smoke test against /health and a model reload given the loader refactor above.

[claude]

Risk: LOW — this is a digest-only bump of the floating server-cuda tag (no semver), and the llamacpp controller is currently replicas: 0 (parked per the Gemma-26B-A4B abandonment note), so nothing in-cluster is actually running this image.

Breaking changes: New digest resolves to upstream build b10015 (2026-07-15); old digest was pinned ~2026-06-19, so this spans roughly a month / thousands of upstream commits — too broad for a single changelog diff. I checked server-tool commit history in that window for anything touching the CLI flags this repo relies on (--hf-repo, --hf-file, -ngl, -c, -fa, --host, --port, --alias, mmproj auto-download, /health): nothing explicitly flagged as breaking for these. One relevant-adjacent change: "common: refactor model handling" (2026-06-25) touched the model-loading path used by --hf-repo/--hf-file, and "server: Don't consider models with --no-mmproj-auto as multimodal" (2026-07-12) — not applicable here since this config doesn't set --no-mmproj-auto.

Action needed: None to merge now. When replicas is later flipped back to 1 to revisit this model, re-verify the existing in-file quirk notes still hold (bare -fa needs an explicit value, GGUF auto-download + mmproj vision download on first boot) before trusting it unattended.

[claude]

Risk: LOW — digest-only bump on the server-cuda rolling tag (~1 month of upstream commits, 2026-06-19 → now, no semver). llamacpp HelmRelease is replicas: 0 (parked, Gemma-4 experiment on hold), so blast radius is zero until someone scales it back up.

Breaking changes: Reviewed upstream tools/server commit history for the window. No breaking changes found to the CLI flags this repo relies on:

• --hf-repo / --hf-file (Unsloth GGUF auto-download)
• -fa on (explicit value still required/supported)
• -ngl, -c 32768
• mmproj/vision auto-download for Gemma-4 26B-A4B

Notable upstream changes in the window (none affect this config): CORS flag additions, server-side SSE streaming refactor, a fix so --no-mmproj-auto models are still classified as multimodal, and a CLI migration to an HTTP-based implementation (server-side, not this container's invocation).

Could not find a curated llama.cpp changelog for this exact digest range since ggml-org/llama.cpp doesn't tag semantic releases on the server-cuda image — assessment is based on tools/server commit log, not a changelog doc.

Action needed: None to merge safely. Before flipping replicas back to 1 to resume the Gemma-4 experiment, do a quick smoke test (health probe + a sample completion) since it hasn't run against this build yet.

[claude]

• Risk: LOW — digest-only bump of the rolling server-cuda tag (no semver/version change), and llamacpp is currently parked at replicas: 0 (see helm-release.yaml comment: Gemma 26B-A4B experiment paused pending upstream fixes), so blast radius in-cluster is zero until someone scales it back up.
• Breaking changes: Checked upstream commits touching tools/server between 2026-06-19 and 2026-07-19 for anything affecting the flags this repo uses (--hf-repo, --hf-file, -ngl, -c, -fa, --host/--port, mmproj auto-download):
  • cli: move to HTTP-based implementation (c264f65, Jul 8) — touches tools/cli + adds a --server-base client mode; does not modify --hf-repo/--hf-file/-fa server args.
  • server: Don't consider models with --no-mmproj-auto as multimodal (#25590, Jul 12) — only changes /v1/models capability advertisement when --no-mmproj-auto is explicitly passed. This config never sets that flag, so mmproj auto-download for the vision-capable 26B-A4B model is unaffected.
  • No other breaking changes found to the args/health-endpoint this deployment relies on.
• Action needed: None — safe to merge on green. No values renames, CRD changes, or migration steps required.

[claude]

• Risk: LOW — digest-only bump on the server-cuda rolling tag (~1 month of upstream commits, 2026-06-19 → now). No semver/release tag to diff since this tracks master snapshots, not tagged releases. Blast radius is further limited: llamacpp controller is currently parked at replicas: 0 (see comment in helm-release.yaml), so nothing is actively serving traffic.
• Breaking changes: Checked upstream release notes (github.com/ggml-org/llama.cpp/releases) for the window covering this bump. Changes in that range are backend/kernel-level (OpenCL/Adreno, Vulkan Q2_0, SYCL, DFlash KV rotation, DeepSeek-V4 quant fix) — no changes to server CLI flags used here (--hf-repo, --hf-file, -ngl, -c, -fa, --host, --port, --alias), no /health endpoint changes, no KV-quant flag changes affecting the f16 KV config in this HelmRelease.
• Action needed: None — safe to merge on green. Since the controller is scaled to 0, there's no live validation until it's flipped back on; when it is re-enabled, do a quick smoke check that the Gemma 26B-A4B GGUF still loads and /health responds given the ~1 month of upstream drift.

[claude]

• Risk: LOW — digest-only bump of the server-cuda rolling tag (no semver/tag change), and llamacpp is currently parked at replicas: 0 (Gemma 26B-A4B experiment on hold per in-file comment), so blast radius is nil either way.

• Breaking changes: Can't produce a real diff here — ggml-org/llama.cpp doesn't publish curated release notes for the server-cuda image; it's rebuilt continuously per-commit under auto build numbers (e.g. b10077–b10087 just in the last 24h). The gap between the digest pinned 2026-06-19 and this one spans hundreds of such builds, so "read the changelog between old and new" isn't meaningful here — flagging that explicitly rather than guessing. Skimmed the latest GitHub releases listing for this repo: no mentions of removed/renamed llama-server CLI flags, so the args this repo passes (--hf-repo, --hf-file, -ngl, -c, -fa on, --host, --port, --alias) aren't called out as affected.

• Action needed: None to merge now (controller disabled). Before scaling llamacpp back to replicas: 1, smoke-test boot + the existing -fa (bare flag ate next arg on an earlier build, per in-file comment) and vision/mmproj auto-download behavior, since a month of upstream commits sits between the two digests.

[claude]

Risk: LOW — digest bump on the server-cuda rolling tag (~1 month of upstream commits, 8d1e8dd → 72ca3a0), but llamacpp controller is currently parked at replicas: 0, so blast radius is zero until it's re-enabled.

Breaking changes: Checked upstream tools/server commit history for the window — no renames/removals affecting the flags this repo depends on (--hf-repo/--hf-file auto-download, -ngl 99, -c 32768, -fa on, --host/--port/--alias). One behavior tweak landed upstream (Jul 12): models using --no-mmproj-auto are no longer treated as multimodal — doesn't apply here since this config relies on default auto-mmproj download (no --no-mmproj-auto set), so vision loading is unaffected.

Action needed: None, safe to merge on green. When this controller is next scaled back to replicas: 1, worth a smoke-test that -fa on still doesn't crash (the existing comment in the manifest notes a prior build where bare -fa ate the next arg) and that the mmproj vision encoder still auto-downloads as expected.

[claude]

Risk: LOW — digest-only bump on the rolling server-cuda tag (no version/tag change), and llamacpp controller is parked at replicas: 0 (Gemma 26B-A4B experiment on hold), so blast radius is effectively nil even if something regressed.

Breaking changes: None identified affecting this repo's usage.

• Renovate bumps a floating-tag digest, not a semver release, so there's no single upstream changelog entry to diff against — I instead checked the current tools/server README/CLI reference for the flags this repo relies on.
• All args used here (--hf-repo, --hf-file, -ngl, -c, -fa on, --host, --port, --alias) match current upstream syntax — no renames or removals.
• The one recent upstream deprecation (--mlock/--mmap/-dio → -lm/--load-mode) doesn't apply — this manifest doesn't set any of those flags.
• /health endpoint contract (200 {"status":"ok"} / 503 while loading) is unchanged, so the existing startup/liveness/readiness probes remain valid.
• Note: I could not pull the exact commit range between the old (8d1e8dd) and new (f96be8d) digests (GHCR manifest/API access wasn't reachable from this environment), so this is based on current docs vs. the flags in use, not a literal diff of the two builds.

Action needed: None — safe to merge on green. If replicas is later flipped back to 1 to resume the Gemma 26B experiment, worth a quick smoke test of model load + /health given the long startup window, but that's unrelated to this digest bump specifically.

[claude]

• Risk: LOW — this is a digest bump on a rolling tag (server-cuda), not a semver/version jump, so there's no discrete old-version-to-new-version changelog to diff. Blast radius is also effectively zero right now: the llamacpp controller is replicas: 0 (parked per the in-file comment, pending an upstream Gemma-4 fix), so nothing actually runs this image until someone flips it back on.

• Breaking changes: Could not resolve either digest to a specific commit/build number — GHCR manifest inspection (skopeo) and gh api calls to the upstream repo were blocked by sandbox network approval in this run, so I can't give an exact commit range for 8d1e8dd… → 48b8053…. Based on llama.cpp's public release history, builds land very frequently (10+ per day; latest at time of writing was b10201), so this digest likely spans hundreds of commits over roughly 6 weeks. I reviewed recent release notes for changes to the server flags this repo relies on (--hf-repo, --hf-file, -ngl, -c, -fa, --host, --port, --alias, mmproj/vision auto-download) and found nothing flagged as breaking. I can't verify this exhaustively given the rolling-tag/no-changelog nature of the image — flagging that explicitly rather than guessing.

• Action needed: None to merge — safe on green given the app is scaled to 0. Before scaling llamacpp back to replicas: 1, smoke-test -fa on and the Gemma vision/mmproj auto-download path, since this build track has previously changed behavior on both (per the existing in-repo comments).

[claude]

• Risk: LOW — digest-only bump on a rolling tag (server-cuda, tracks llama.cpp master), no semver change. Blast radius is further reduced because the llamacpp controller in cluster/apps/ai/llamacpp/app/helm-release.yaml is currently parked at replicas: 0 (per in-file comment, superseded by vLLM for Gemma 4 12B) — this image isn't actively serving traffic.
• Breaking changes: Unable to determine precisely — server-cuda is a rolling/CI tag built per-commit from master, not tied to a GitHub release, so there's no changelog entry that maps directly to the digest range (8d1e8dd → 11b2641, 2026-06-19 → 2026-08-02). Scanned upstream release tags (b10216–b10227 and surrounding) from that window and found no documented server API, CLI flag, or config-format breaking changes — only feature/perf work (Qwen3 parser support, SYCL/Vulkan/WebGPU fixes, chat reasoning-content handling). Flagging explicitly rather than guessing: this is not a verified diff of actual changes.
• Action needed: None required to merge. If/when this controller is scaled back up (replicas: 1), it'd be worth a quick smoke test of the --hf-repo/--hf-file GGUF auto-download and -fa on flag behavior before relying on it, since rolling-tag bumps can silently change CLI flag semantics over a ~6-week span.

[claude]

Risk: LOW

This is a digest-only bump on a rolling CI tag (server-cuda), not a semver release — llama.cpp cuts a new build (b#####) multiple times per day, so the old→new digest spans ~6 weeks and likely thousands of upstream commits with no consolidated changelog covering that range. Additionally, llamacpp is currently parked (replicas: 0, per the comment in the file — vLLM Gemma 4 12B is the active daily driver), so blast radius is effectively zero even if something regressed.

Breaking changes: Unable to fully verify — release notes for this rolling tag are unreachable (llama.cpp doesn't publish per-build changelogs, and GHCR manifest inspection requires registry auth this run doesn't have). I did check the upstream tools/server/README.md against every flag this repo passes (--hf-repo, --hf-file, -ngl, -c, -fa on, --host, --port, --alias) — all still exist with unchanged semantics (-fa still requires an explicit on|off|auto value, matching the existing comment/workaround in this file).

Action needed: None required to merge safely given replicas: 0. Before scaling back up (per the file's TODO to revisit Gemma 4 thinking-termination bugs), do a quick smoke test of the 26B-A4B GGUF load + vision path, since a 6-week jump is large enough that upstream behavior may have shifted even if flags are unchanged.

[claude]

• Risk: LOW — digest-only bump on the rolling server-cuda tag (no version/tag change), and llamacpp controller is currently replicas: 0 (Gemma 26B-A4B experiment parked per in-file comment), so blast radius is effectively none — nothing is serving traffic today.
• Breaking changes: Digest pins don't map to a discrete llama.cpp release, so an exact commit-range diff isn't available. Sampled the upstream releases list (github.com/ggml-org/llama.cpp/releases) covering the recent build range — no changes found to --hf-repo/--hf-file auto-download, -fa/--flash-attn, /health, --host/--port, or KV-cache quant flags (-ctk/-ctv), all of which this HelmRelease depends on. Note: only the most recent page of releases was checked, not the full ~6-week window since the prior digest (2026-06-19), so a low-probability unlisted change can't be fully ruled out.
• Action needed: None required now since the controller is scaled to 0. If/when replicas is flipped back to 1 to resume the Gemma experiment, do a quick smoke test of --hf-repo GGUF auto-download, vision/mmproj loading, and the -fa on flag before relying on it — safe to merge on green in the meantime.

[claude]

• Risk: LOW — llamacpp controller is replicas: 0 (parked; Gemma-4 experiment abandoned per in-file comment), so blast radius is zero until someone flips it back on. Blocking issue on the container args referenced there (Eval bug: Infinite repetition loop in llama-server with peg-gemma4 parser during tool calls ggml-org/llama.cpp#21375) is unrelated to this bump.
• Breaking changes: Unknown/not mappable. This is a digest pin on the rolling server-cuda tag, not a semver release — there's no changelog entry tied to a specific digest, and GHCR's package UI doesn't expose per-digest build metadata without auth. I checked the llama.cpp GitHub releases feed for anything touching the flags this repo actually uses (--hf-repo/--hf-file auto-download, -fa, -ngl, -c, --host/--port) and found nothing obviously breaking in the recent history I could see; the only notable breaking change flagged was to the separate llama-tts binary, not llama-server.
• Action needed: None to merge now since the workload is scaled to 0. Before flipping replicas back to 1, sanity-check the -fa on and --hf-repo auto-download behavior still works as expected with the new digest (the in-file comments note both were previously finicky).

[claude]

Risk: LOW — digest-only refresh of the floating server-cuda tag (build b10236-ish → b10290, ~7 weeks of upstream commits), no semver jump. llamacpp controller is currently parked at replicas: 0 (Gemma 26B-A4B experiment on hold), so blast radius is effectively zero even if something did regress.

Breaking changes: Reviewed tools/server commit history on ggml-org/llama.cpp between 2026-06-19 and today. Nothing found that affects this repo's usage:

• A "notice for upcoming default port change 8080 → 9931" was added, but this HelmRelease already sets --port 8080 explicitly, so it's unaffected.
• No changes found to --hf-repo/--hf-file/LLAMA_CACHE auto-download behavior for single-model (non-router) mode — the one download-related commit in range only adds sidecar downloads for speculative-decoding models, which this config doesn't use.
• No changes to -fa, -c, -ngl, --alias, --host semantics surfaced in the range reviewed.

Note: this is a rolling build tag with no changelog/release notes doc, so this is based on commit-log skimming rather than authoritative release notes — treat as directional, not exhaustive.

Action needed: None, safe to merge on green. Worth a quick smoke test (scale replicas 0→1) next time this model is actually turned back on, given the size of the digest jump.

[claude]

Risk: LOW

Digest-only bump on the server-cuda rolling tag for ghcr.io/ggml-org/llama.cpp (8d1e8dd → 27cf25e), spanning ~7 weeks of upstream commits (pinned 2026-06-19 → now). This isn't a semver release — llama.cpp ships continuous per-commit builds (bNNNNN), so there's no single changelog entry to diff; I checked upstream's recent release notes and the current tools/server/README.md instead of guessing.

Breaking changes: None found affecting how this repo uses the image.

• /health endpoint (used for all 3 probes: startup/liveness/readiness) is still present and unchanged.
• -fa, -ngl, -c, --hf-repo, --hf-file, --host, --port — all flags used in helm-release.yaml args — remain supported with no documented signature changes.
• Blast radius is further reduced by controllers.llamacpp.replicas: 0 — this workload is currently parked (not serving), so even an unnoticed server-side regression wouldn't affect production until someone scales it back up.

Action needed: none, safe to merge on green. Worth a quick manual smoke test (scale to 1, check /health + a completion) next time this gets un-parked, since a 7-week jump on a fast-moving rolling build is untested by CI here.

[claude]

• Risk: LOW — digest bump on a rolling server-cuda build (no semver), and the llamacpp controller is currently replicas: 0 (parked per the Gemma-4 thinking-termination bug workaround), so blast radius is zero until it's scaled back up.
• Breaking changes: Could not get a scoped changelog for this digest range — ghcr.io/ggml-org/llama.cpp server-cuda images are rolling builds off master with no per-digest release notes, and the registry manifest API isn't reachable from here (needs auth token). Checked upstream commit history for the ~7-week window (2026-06-19 → 2026-08-08) instead: found server: add notice for upcoming default port change 8080 → 9931 (0b14b87, Aug 3, server: add notice for upcoming default port change 8080 --> 9931 ggml-org/llama.cpp#26508). This repo's HelmRelease explicitly passes --port 8080, so it's unaffected — the change is only a warning notice for users relying on the default, and the actual switch hasn't landed yet. No changes found to --hf-repo, --hf-file, -ngl, -c, -fa, --host, --alias, or /health, but I can't rule out others given the volume of unreviewed commits in this window.
• Action needed: None to merge safely. Worth a follow-up note (not blocking) that upstream is planning to change the default port to 9931 in a future release — irrelevant here since port is pinned, but flag if this HelmRelease ever drops the explicit --port.

[claude]

Risk: LOW — digest bump on the server-cuda rolling tag (not a semver jump; ~7 weeks of upstream commits, 2026-06-19 → now). Blast radius is further limited: llamacpp controller is currently parked at replicas: 0 (Gemma 26B-A4B experiment abandoned per in-file comment), so this image isn't even running in-cluster.

Breaking changes: None found affecting how this repo uses the image. Checked recent llama.cpp release notes (b10318–b10331, covering early Aug builds) for changes to the server CLI flags and behavior this HelmRelease relies on (--hf-repo/--hf-file auto-download, -ngl, -c, -fa on, --host/--port/--alias, /health endpoint) — no breaking changes to any of these were reported; recent changes were CUDA/SYCL perf fixes, bug fixes, and additive server features (backward compatible).

Action needed: None — safe to merge on green. If/when replicas is flipped back to 1 to revisit the Gemma 26B experiment, worth a quick sanity check that the model still loads and /health responds as expected, since the digest wasn't smoke-tested against this specific GGUF/config in the interim.