A model configured cache_type_k/v=q8_0 at n_ctx=128000 got a 47.7 GB KV cache
placed in host RAM and the engine was SIGKILLed mid-load, taking every other
model resident on it down too. The placement plan that exists to prevent exactly
that skipped itself, because any pin — type or location — was read as consent to
whatever size resulted. Quantized KV at a long context is the configuration
someone writes because they are worried about size; it is the one that most needs
checking.

A pin is now honoured without switching the check off: a pinned type is never
requantized, a pinned placement is never moved, and when the remaining levers
cannot make it fit the load is refused with a message naming the pin.

That refusal needs a measured size, and the measurement was being taken after a
successful load and printed as advice to copy into the config by hand. A KV cache
big enough to need the plan is big enough to kill the process before the load
ends — so there was no "after", nobody was reading, and the engine died, got
respawned, and repeated the identical load forever. It is now journalled the
moment llama.cpp names the size, before the allocation is faulted in.
measured_kv_gb still wins; the journal only answers when the config was silent.

Separately: a quantizer that drops a checkpoint's NextN (multi-token-prediction)
blocks without lowering block_count makes llama.cpp ask for a block the file does
not have, reported as a bare "missing tensor 'blk.64.attn_norm.weight'" — which
reads like a corrupt download. When the file's shape proves that is what
happened (blocks contiguous from 0, exactly nextn_predict_layers short), the
declared count is corrected via llama.cpp's own kv_overrides. A file missing
blocks for any other reason still fails, because a truncated download must not be
silently reinterpreted into a model that loads and answers nonsense.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC