Repository navigation
Conversation
|
The panel reads the engine's own histograms ( (Review notes prepared with Claude Code on behalf of the maintainer.) |
9747859 to
c31c804
Compare
|
Both points are in Restart behaviour, pinned by a test.
Totals from the new process still replace the old ones when it reports them, so the panel recovers on the next poll. History is unaffected here — it already rebaselines on the epoch (in #362). Checks after the rebase: |
|
Device-validation update; no engine-pin or inference-policy change:
No production lifecycle controls, automatic tuning, new model requests, or private deployment material are added by these PRs. Draft/merge decisions remain with the maintainers. |
|
Restart semantics are pinned in the dependent history stack (#362): a new engine epoch seeds a fresh baseline and does not claim reuse for a prompt window spanning the restart; the new observation-identity test also covers a repeated timestamp with a changed epoch. The live collector clears its reuse window on epoch change. Follow-up 3738afd adds visible restart/reset/gap markers and pressure coverage, with failing-before/passing-after backend/UI regressions. Current-main/TFOT rebase remains separate upstream integration work; the matched deployment checks are not evidence that a newer main has been device-qualified. |
…r-stream ratio - LlmProbe parses /health.live.cache into a validated group: full / partial / unavailable / inconsistent / unsupported, with the four disjoint pool categories, the prompt-state store's storage and classified failures, the engine epoch and the observation time. Categories that do not sum to the capacity are refused, an older engine reads 'unavailable', never a zero. - LlmPanel: a TensorFold-only cache panel (partition bar, capacity/per-request/ streams, lifetime reuse, invalidations vs placements refused, snapshot churn, failures by stage) linked to the history anchor. - Overview: a compact 'active · kept' chip from the same accounting. - vramBreakdown: TensorFold's kv_cache_usage_ratio no longer colours the legend or raises 'pool nearly full'; other backends keep their semantics. - tests cover the group's validation, the panel's four states, the overview chip and the VRAM verdict.
c31c804 to
3643a05
Compare
|
Rebased onto current upstream Fresh checks on this exact head:
This is a source-only review refresh. The earlier bounded live-device validation applies to the deployed pinned integration, not a claim that current upstream main was deployed. No production lifecycle action or new model workload was performed for this refresh. The history PR #362 includes this live commit; merge #361 first, then review/merge the remaining history diff. Both branches now preserve current upstream localization and have fresh test results. |
Current review status
Ready for review at
3643a05, rebased onto upstreamda20ac5. Fresh typecheck/build/npm test and whitespace checks pass: 1,676 server pass /16 skip; 971 frontend pass; 11 i18n checks pass. These are local checks, not a claim of hosted CI or a new production deployment. Merge #361 before #362; history includes the identical live commit. See the latest validation comment for boundaries and details.Draft: read TensorFold's shared cache from the engine, and stop presenting its per-stream ratio as pool fill.
What it adds
Collector (
server/collectors/LlmProbe.js) parses the optionallive.cachegroup into a validatedobservation with six states:
fullpartialunavailableinconsistentunsupportedinvalidThe four pool categories are accepted only when they sum to the reported capacity, and the store's
charged bytes only within its budget. A failed health read clears the previous observation, so a
stale pool is never presented as current. The same
/metricsread also keeps the cumulative TTFT /latency histogram buckets for the history sampler (a separate PR). Nothing here uses
kv_cache_usage_ratio.Live panel (
LlmCachePanel) is TensorFold-only: a partition bar (active / kept prefixes /reclaimable growth / unclaimed) with the capacity, the per-request limit, the streams, lifetime
token reuse, and a detail block that separates the things that used to be one number: pool
invalidations vs placements refused, snapshot evictions/refusals, lookups, and failures by stage
(keep / restore / peer forget) beside the legacy total. An engine without the group gets one sentence,
not a row of zeros.
Overview chip shows
% active · % keptfrom the same accounting, with the pool size, per-requestlimit, streams and store budget in its tooltip.
VRAM breakdown: TensorFold's
kv_cache_usage_rationo longer colours the legend or raises"Engine KV pool nearly full" — that ratio is one stream's share of its own window, not the shared
pool's occupancy. Other backends keep exactly their previous behaviour, and the legend says "not
reported by TensorFold" instead of guessing.
Verification
npm run typecheck,npm run build,npm run test:frontend(817 tests),npm run test:server(1457 tests),
npm run i18n:check,git diff --check— all pass.disabled store / failed read clears), the panel's states, the overview chip, and the VRAM verdict
for TensorFold vs an engine whose ratio is pool occupancy.
Compatibility: the endpoint snapshot only gains optional fields, and every field stays absent for
backends that do not report the group. The history PR builds on this one.