fix(container): update image nousresearch/hermes-agent (v2026.8.16 ➔ v2026.8.16.2) - #4519
Merged
Merged
Conversation
…ng (#4509) * feat(llmkube): add qwen 3.8 benchmark lane * feat(llmkube)!: cut Qwen 3.8 over to production, retire Qwen 3.6 SGLang vLLM v0.27.1's new RDNAHybridW4A16LinearKernel closes the dense-INT4 decode-kernel gap that lost the June vLLM-vs-SGLang evaluation on this hardware. Live-qualified against the SGLang 3.6 baseline: C1 +28%, C8 +14%, C16 +199%. - promote qwen38-27b-vllm to production (replicas 1, parallelSlots 16, cudagraph_capture_sizes capped per vLLM #39010, MTP deliberately omitted per the tool-calling wedge) - port the OffloadingConnector RAM+disk KV tier from qwen36-27b-vllm to raise context from 32768 to 96000 (Hermes hard-requires >=64K and measures p90 94K); vision stays loaded (unlike the qwen36 config's --language-model-only) since Hermes' auxiliary.vision uses it - park qwen36-27b-sglang (replicas 0) instead of deleting, for rollback - drop the throwaway qwen38-27b-benchmark manifest - repoint the qwen-3.6/qwen-3.6-fast litellm aliases at the new backend, keeping the alias names for downstream compat (karakeep, omniroute); maxInputTokens corrected to match the real ceiling BREAKING CHANGE: qwen-3.6/qwen-3.6-fast litellm aliases now serve Qwen 3.8 via vLLM instead of Qwen 3.6 via SGLang. Max input context drops from 171808 to 87808 tokens. * perf(llmkube): shrink Mamba conv-state cache dtype, raise Qwen 3.8 context to 98K --mamba-cache-dtype (conv-state pool, separate from the already-set --mamba-ssm-cache-dtype which only covers SSM state) was left at the model-config default. Setting it to bfloat16 too freed ~0.23 GiB, raising the GPU KV pool from 99,809 to 107,428 tokens at the same gpuMemoryUtilization ceiling — real headroom, not a quality tradeoff, since bfloat16 is already the precision floor we accept elsewhere. That let maxModelLen go from 96000 to 98000 (106000, closer to Hermes' p95 of 106K, didn't fit — vLLM's own estimate at this budget tops out at 100000). Updated Hermes' context_length and litellm's maxInputTokens to match the real ceiling. * perf(llmkube): size Qwen 3.8 KV pool explicitly, raise context to 112K Deriving the KV pool from gpuMemoryUtilization left it at 3.22 GiB -- 99,519 tokens, or 1.02x concurrency at the old 98000 context, so a second full-length request had to queue behind the first. vLLM's own memory profiler reported 6.88 GiB as the ceiling that still fits on this card. Set --kv-cache-memory to 6 GiB and raise gpuMemoryUtilization to 0.97 (it now only has to admit weights + activations + that block, not size KV itself). Measured on the R9700: 187,945 KV tokens, 1.68x concurrency at 112000 context. Context goes 98000 -> 112000, which covers Hermes' measured p100 so routine sessions stop truncating; litellm maxInputTokens follows to 103808. Concurrency sweep vs the SGLang 3.6 baseline: C1 15.36 vs 14.96 tok/s C8 40.11 vs 36.24 tok/s (+11%) C16 76.12 vs 34.49 tok/s (+121%) Review remarks: - Replace the no-op liveness probe with a real /health check. The startup probe owns the load window, so liveness only runs against a serving engine; slack thresholds (20x30s) keep a saturated GPU from being mistaken for a dead one. - Run the kv-offload free-space guard hourly instead of daily. hostpath enforces no quota, so this job is the only control; hourly bounds the exposure to one hour of writes. Noted in-file that a quota-enforcing storage class is the real fix and why it is not taken. - Drop the session handoff doc: it described a paused, unsafe live state (Flux suspended, production stopped) that no longer exists. Fix the bench script's hardcoded qwen-3.6 served name, which made every request fail silently after the cutover and report 0 tok/s. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DcmiaP2xnvqGmvshQUteVK * fix(llmkube): stop the kv-offload guard wiping the whole L3 tier every run The guard's 160Gi free-space floor was never reachable on the qwen38 node: the disk is 500G with ~370G held by everything else, so df reported 131G free even with an empty store. Every run therefore took the "below floor" branch and did `rm -rf /kvoffload/*`. Confirmed live -- the last job logged `avail: 128291444K (floor: 167772160K) / below floor, wiping the L3 store` and the store is currently 4K. The tier that reports a 95.7% external prefix hit rate was being deleted daily. Two changes, applied identically to qwen36-27b-vllm.yaml so the copies cannot drift: - Floor 160Gi -> 80Gi, a value this disk can actually satisfy. - Evict oldest-first instead of wiping: blocks are write-once, so mtime is the recency signal the old comment claimed did not exist. The cutoff walks 30/14/7/3/1/0 days and stops as soon as it is back above the floor, so an overshoot costs a slice of cold blocks rather than weeks of warm ones. An unreachable floor now degrades to "keep the last 24h" instead of erroring. This is what makes the hourly schedule safe; hourly plus wipe-all would have destroyed the cache 24x a day. qwen36's guard moves to hourly to match. Also from review: - Fix the same hardcoded qwen-3.6 served name in spectest.py, not just concsweep.py -- spectest has no exception handling and would traceback rather than silently report 0. Both now take the model as an optional 2nd argv, matching the existing _port() convention instead of adding an env var. - Trim comments that restated neighbouring comments or git history. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DcmiaP2xnvqGmvshQUteVK * fix(llmkube): fail the kv-offload guard when it cannot reach its floor The eviction ladder exited 0 even after walking all the way down, so a node whose free space was short for reasons other than this cache reported a healthy guard run until it filled up. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * refactor(ai): rename qwen-3.6 litellm aliases to qwen-3.8 The aliases now serve Qwen 3.8, so the 3.6 names were actively misleading. Renamed atomically across every consumer that hardcodes them: karakeep's image model, the PR-review action's fallback, the proxy's omniroute fallback chain, and the alias definitions. Hermes' own profile configs live in its PVC and were updated in the same pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * refactor(ai): retire the Qwen 3.6 lane and its sglang references qwen38-27b-vllm has taken all traffic, so the parked qwen36 sglang and vllm manifests were dead weight -- and their kv-offload guard CronJobs kept sweeping two multi-hundred-thousand-file stores hourly for models that never serve. Removes both manifests and everything left dangling by them: the sglang-rdna4 Renovate rule (no image left to track), the sglang Grafana dashboard link and its chart toggle, and the kustomization entries. Comments naming the deleted services are repointed rather than dropped -- muse-glimmer's scale-down condition named qwen36-27b-vllm, which would have sent a future operator looking for a service that no longer exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * fix(llmkube): restore the 0.875 VRAM ceiling shared with Jellyfin The 0.97 this shipped with broke a documented hard constraint: the R9700 is shared with Jellyfin transcoding, and the ~4.6 GB free at 0.875 is that reservation, not slack. At 0.97 free VRAM measured 3.41 GB -- under the reservation, so a concurrent transcode would contend or OOM. The raise was also based on a misreading. vLLM logs 'skipped memory profiling ... does not respect the gpu_memory_utilization config' when --kv-cache-memory is set, so the KV pool never came from the 0.97 at all; the explicit flag was doing the work by itself. Sizing KV at 5 GiB instead keeps 112K context and measures 5.46 GB free (0.86 GB over the reservation). It also benchmarks faster at the concurrency end than the 0.97 build did: 53.93 vs 40.11 tok/s at 8, 100.82 vs 76.12 at 16. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * fix(llmkube): ship the vLLM dashboard now that sglang is gone The dashboard ship-list carried sglang-dashboard because production ran SGLang. Removing the qwen36 lane dropped it without adding the vLLM equivalent, which would have left the new engine with no dashboard at all -- `only` is a static ship-list and does not follow what is deployed. operator.mode defaults to auto, so vllm-dashboard publishes only while a vLLM InferenceService exists and self-suppresses instead of rendering blank if qwen38 is ever parked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * refactor(ai): use upstream litellm dashboard and auto runtime gating litellm dashboard: drop the 542-line vendored copy for grafana.com 24965. It was forked because 24965's $job/$instance vars query litellm_proxy_total_requests_metric_created, which litellm did not export -- every panel came up blank. v1.97.0 exports that series (91 live) and all 10 metrics the dashboard queries; $model resolves too. Revision pinned: no Renovate manager covers grafanaCom. llmkube dashboards: list both runtimes we ship manifests for and let operator.mode: auto decide. vllm follows qwen38, llamacpp follows muse-glimmer, so parking or scaling either no longer needs an edit here. `only` stays: auto gates only the three runtime dashboards, so dropping it would ship four that render blank regardless -- verified pyrra is absent (llmkube-slo) and we export drm_* not amdgpu_* (amd-gpu- observability), plus quota/model-router need features we don't deploy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * refactor(ai): drop the explicit dashboard pins Track grafana.com 24965's latest revision instead of pinning one, and let operator.mode fall through to the chart's auto default rather than restating it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * docs(ai): trim the verbose comments Same reasoning, fewer lines: keep the measured numbers and the constraint each value encodes, drop the prose around them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * refactor(ai): apply simplify review findings - Drop 6 redundant `namespace: ai` declarations; the Flux Kustomization sets targetNamespace and three of four siblings already omit them. - Drop --mamba-ssm-cache-dtype: it defaults to following --mamba-cache-dtype, so both flags plus five lines argued one setting. - Remove two citations to files that do not exist in this repo (docs/hermes-config.md, project_vllm_toolcalling_specdecode.md); the numbers they backed are already inline. - Lead the gpuMemoryUtilization comment with INERT rather than a HARD CEILING banner over a field vLLM logs that it ignores. - Correct the memory comment: measured 13.3Gi steady state (8Gi of it tmpfs), not the inherited '24Gi base' figure. - models.yaml no longer claims the rename was atomic with hermes -- hermes' profiles live on its PVC and were edited by hand. - Renovate: match the hf://repo@sha source form too, so the primary serving model's weights digest is tracked (3 of 5 models -> 5 of 5). - Docs: engine-benchmarks still named SGLang as production, the bench recipe port-forwarded a deleted Service, and sglang-blockers described a retired setup in the present tense. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG * refactor(llmkube): drop the dashboard only-list Ship every dashboard and let the operator's auto mode gate the runtime ones. The four non-runtime dashboards auto does not cover will render blank; the comment says which and why. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PusTnmBZMnHEJDRLQprNRG --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@@ spec.template.spec.containers.app.image @@
# apps/v1/Deployment/ai/hermes
! ± value change
- nousresearch/hermes-agent:v2026.8.16@sha256:f8f548d87d16634d1ad9e3777280f3f577ba2358703f04e18e74007ffd3621bf
+ nousresearch/hermes-agent:v2026.8.16.2@sha256:a39fc11620213e3669a327aff5c6cb1eb2b8a238c6044e33e7ef8885833d89a7
|
@@ spec.values.controllers.hermes.containers.app.image.tag @@
# helm.toolkit.fluxcd.io/v2/HelmRelease/ai/hermes
! ± value change
- v2026.8.16@sha256:f8f548d87d16634d1ad9e3777280f3f577ba2358703f04e18e74007ffd3621bf
+ v2026.8.16.2@sha256:a39fc11620213e3669a327aff5c6cb1eb2b8a238c6044e33e7ef8885833d89a7
|
AI Automated ReviewAnalysis engine: qwen-3.8-fast@http://litellm.ai.svc.cluster.local/v1 (openai) — fallback (primary failed) Recommendation: Approve. This is a standard Renovate patch bump for Must-check items:
Sources: PR diff and metadata only; upstream release notes for |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| image: | ||
| repository: nousresearch/hermes-agent | ||
| tag: v2026.8.16@sha256:f8f548d87d16634d1ad9e3777280f3f577ba2358703f04e18e74007ffd3621bf | ||
| tag: v2026.8.16.2@sha256:a39fc11620213e3669a327aff5c6cb1eb2b8a238c6044e33e7ef8885833d89a7 |
There was a problem hiding this comment.
Info (docs): Upstream release notes for v2026.8.16.2 were not retrieved; patch-level changes are unverified.
Automated finding from AI PR review.
Contributor
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
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
1 participant
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.
This PR contains the following updates:
v2026.8.16→v2026.8.16.2Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Configuration
📅 Schedule: (in timezone Europe/Brussels)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.