Expand description
Whether a windowed layer’s host KV cache may drop rows behind its window, and which window it drops behind.
ferrox_core::kv_swa::KvWindow is the arithmetic – how many rows
survive N positions. This module is the decision: which layers get
one at all, and whether this particular run is one where dropping a
row is safe. Those are different questions with different owners, and
keeping them apart is what stops the budget from pricing a saving the
store did not take (#33) or the store from taking one the budget did
not price.
§Off by default
FERROX_KV_WINDOW=1 turns it on, and nothing else does. The switch
exists in the shape FERROX_CPU_POOL established: one env var, so
the before and the after are one word apart and reverting costs
nothing.
§What the switch refuses to do
Eviction is the contiguous host store on the CPU path, and only that (#61 steps 3 and 4 are the GPU stores and the paged one). Two things it therefore turns itself off for:
- Metal attention.
Decoder’s Metal arms compareMetalKvBuffers::seq_lenagainst the host cache’srows()and itspositions()in five places, and take the two as interchangeable. They are, until a host cache evicts. So a run withFERROX_METAL_ATTNon does not evict, and says so here rather than in five separate conditions that would drift apart. - Full-attention layers, obviously, and that is the interesting half of the saving rather than a caveat: an alternating-SWA model keeps every position in its dense layers no matter what this switch says. The Gemma-3 figure in #61 is a per-layer number, not a whole-model one.
CUDA needs no exclusion: the resident-KV decode hook in
Decoder::gqa_attention is reachable only from the window == None
arm of push_and_attend_row, so it never sees a cache that evicts.
Structs§
- KvWindow
Policy - Whether this run may evict, decided once at load time.
Constants§
- KV_
WINDOW_ ENV - The one spelling of the switch.