One request, five minutes, fourteen cores, the GPU at 6%, on a card with room
for the whole model. Eviction was never the problem -- it freed 14.2 GB and
handed the loader 22.9 GB. Two defects then threw that away.

The journal key was `<path>@<n_ctx>`, so a 7.5 GB KV measurement taken before
swa_full=False stayed reachable after it. The real cache was 1.0 GB. That
inflated the requirement from ~16.2 GB to 22.7 GB. The key now carries a hash
of the settings that decide the cache size (swa_full, cache_type_k/v,
kv_offload), so a measurement taken under one configuration is a miss under
another; an unreadable config still yields a signature, because orphaning old
entries is the safe direction and over-invalidating only costs one
measurement.

The sizing then never asked for more room. It sampled free VRAM once, found
itself 0.2 GB inside a 95% trigger, and gave layers away while another engine
still held VRAM it would have released on request. It now asks the manager to
evict what a full-GPU placement needs, re-samples, and skips the spill
entirely if it then fits; a failed eviction is not fatal and leaves the old
decision. This is only safe because _evict_models_for_vram consults
_is_key_busy and waits for idle -- and that check became trustworthy for
embedding models when external_busy was wired into the embeddings path
earlier today.

Separately, geoclip never worked. `geoclip` and `geoclip-location` were
advertised by /v1/models and both answered 500 in half a second, because they
share _load_geoclip and the package was absent from the image: declared in
requirements.txt, which the incremental overlay never installs from. Exactly
the fault vosk had, in the same file, for the same reason, and fixed the same
way -- including `--target`, since the venv is not writable by the container
user and a plain install lands in ~/.local where the engine will not find it.
Found by listing the built image's packages; it is invisible from the source
tree. The install was verified in a throwaway container: all three imports
resolve.

And the reason that took so long to find: there is a 400 handler that logs why
a request was rejected, and no 500 handler. The detail existed ("No module
named 'geoclip'") and went only to the client, which in a capability sweep is
a row in somebody else's report; the engine log held the thermal check, the
VRAM estimate, then `Response status: 500`. A 400 is a statement about the
request and a 500 is a statement about us, and this side logged the first and
not the second. Behaviour unchanged; the class is now diagnosable.

Four KV tests asserted exact argument lists and broke on the signature
change. They now match the call through collapsed whitespace, via one shared
helper, so the next reformat does not break them again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC