Skip to main content

Module kv_window

Module kv_window 

Source
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 compare MetalKvBuffers::seq_len against the host cache’s rows() and its positions() in five places, and take the two as interchangeable. They are, until a host cache evicts. So a run with FERROX_METAL_ATTN on 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§

KvWindowPolicy
Whether this run may evict, decided once at load time.

Constants§

KV_WINDOW_ENV
The one spelling of the switch.