# Validation Results

This document presents results from `scripts/validate_eviction_random_init.py`, a multi-step validation that exercises the H2O eviction logic across 1,000 simulated generation steps on a mock KV cache that mirrors the canonical DeepseekV3 / MLA cache structure.

## What was validated

The eviction logic was validated against four properties:

1. **Cache size grows linearly during the warm-up phase** (steps before the cap is reached).
2. **Cache size stabilizes at exactly `n_sink + budget + n_recent`** once the cap is hit.
3. **Eviction triggers on every step past the cap**, removing exactly the amount needed to stay at the bound.
4. **Sinks and recent windows are preserved** across all eviction events (verified by the eviction policy's slicing logic).

## Configuration

```
num_layers   = 4
budget       = 64
n_sink       = 4
n_recent     = 16
expected cap = 4 + 64 + 16 = 84 tokens per layer

heads        = 4
qk_dim       = 192    (DeepseekV3 canonical)
v_dim        = 128    (DeepseekV3 canonical)
```

## Results

```
[B1] running 1000 simulated generation steps...

  [step     0/1000] max=    1  avg=1.0   events=0
  [step    50/1000] max=   51  avg=51.0  events=0
  [step   100/1000] max=   84  avg=84.0  events=68
  [step   150/1000] max=   84  avg=84.0  events=268
  ...
  [step   950/1000] max=   84  avg=84.0  events=3468

[B1] done: 1000 steps in 1.1s (913.6 steps/sec)

[B1] final state: max_cache=84  expected_cap=84  over_cap=0
[B1] PASS: cache stayed at or below expected cap throughout
[B1] PASS: 3664 eviction events triggered correctly
```

Full per-step CSV in `results/validate_eviction_random_init.csv`.

## Interpretation

- **Steps 0-83:** Cache grows from 1 to 84 tokens. No evictions yet — cache is below the cap.
- **Step 84 onward:** Every new token triggers an eviction, holding the cache at exactly 84 tokens for the rest of the run.
- **3,664 total eviction events** across 4 layers and ~916 post-cap steps = ~916 events per layer, matching the expected behavior of one eviction per post-cap step per layer.
- **913.6 steps/sec on CPU** demonstrates the eviction overhead is not a bottleneck even on modest hardware.

## Memory implication

At the validated configuration on the canonical DeepseekV3 layout (61 layers, 64 heads, FP16):

| Cache state | Memory |
|---|---|
| Full cache at 32K context (no eviction) | ~82 GB |
| Evicted cache at budget=64 | ~0.2 GB |

The mock test uses small budgets (64) because we want to exercise the eviction logic in the post-cap regime quickly. In production deployments, `budget=4096` is typical, giving ~10.2 GB cache against the 82 GB full-cache baseline.

## What this validates and what it does not

**Validates:** the eviction policy mechanics. The function `_maybe_evict` correctly identifies which tokens to keep (sinks + heavy hitters + recent) and which to drop, slices the cache accordingly, and updates the score state. The post-cap stabilization at exactly `n_sink + budget + n_recent` confirms the policy's mathematical correctness.

**Does NOT validate:** end-to-end generation quality on a real model. That requires loading actual model weights, running real prompts, and comparing outputs against full-cache baselines on standard benchmarks (RULER 128K NIAH, etc.). See the roadmap below for the planned full-model benchmark.

## Note on transformers version compatibility

The patch in `src/kv_eviction_mla.py` was originally written against the transformers 4.x KV cache API (`DynamicCache.key_cache` / `value_cache` lists). transformers 5.x reorganized the cache to `DynamicCache.layers[i]`, so the patch needs an API porting pass before it runs end-to-end on transformers 5.x.

The eviction logic itself (the part validated here) is unchanged across transformers versions; only the API plumbing differs. Modernization of the patch for transformers 5.x is on the roadmap (`README.md` § Roadmap).

## Reproducing

```bash
git clone https://huggingface.co/GenomaLabs-com/kv-cache-eviction-mla
cd kv-cache-eviction-mla
pip install torch  # only torch is required; no transformers needed for this script
python scripts/validate_eviction_random_init.py \
    --steps 1000 --budget 64 --n-sink 4 --n-recent 16 \
    --out-csv results/validate_eviction_random_init.csv
```

Expected output: matches the results above within RNG variance on the eviction event counts.