Token Budgeting and Cache Management

As LLM context windows expand to 1M+ tokens, managing the "token budget" transitions from a simple cost problem to a fundamental memory and throughput bottleneck.

1. Tokenizer Volatility

The mapping from "words" to "tokens" is non-linear and model-dependent.

2. The KV-Cache Bottleneck

In Transformer models, the Key-Value (KV) Cache stores the pre-computed attention vectors for all tokens in the current context.

2.1 Memory Footprint

The KV cache size is \mathcal{O}(L)(sequence length). For a 70B parameter model:

\text{Memory per token} \approx 2 \times \text{layers} \times \text{heads} \times d_{head} \times \text{precision\_bytes}

At a 32k context, the cache for a single request can exceed 10GB of VRAM.

3. Cache Eviction Strategies

When the token count exceeds the physical memory or the model's architectural limit, we must "evict" tokens from the cache.

  1. Sliding Window (FIFO): Simply drop the oldest tokens.
    • Risk: Loses the "System Prompt" and initial instructions, causing the model to lose track of the task.
  2. Pinned Context: Protect critical tokens (e.g., indices 0-500) from eviction while using a sliding window for the middle of the conversation.
  3. Heavy Hitter Oracle (H2O): Evicts tokens that receive the lowest cumulative attention scores. This keeps "semantically important" tokens (like the subject of a conversation) while dropping fillers.
  4. Semantic Summarization: Instead of evicting, the system triggers a background LLM call to summarize the oldest 2000 tokens into 200 tokens, which are then re-inserted as a "memory" block.

4. Architectural Optimizations