When 90% of Your KV Cache Doesn't Matter: The Mathematics Behind Intelligent Token Eviction

A 70B parameter model with a 128K context window needs approximately 40 GB of GPU memory just for the KV cache. That’s before counting model weights, activations, or any other overhead. TheKV cache grows linearly with sequence length, creating a fundamental barrier to long-context inference that no amount of GPU memory can solve. The breakthrough came from an unexpected observation: most tokens in your KV cache contribute almost nothing to the final output. Researchers discovered that intelligently evicting 90% of cached tokens often results in negligible accuracy loss. This isn’t compression through quantization—it’s compression through understanding which tokens actually matter. ...

7 min · 1331 words

How Ring Attention Breaks the Memory Barrier: Enabling Million-Token Contexts Through Distributed Computation

In April 2025, Meta’s Llama 4 Scout achieved something previously thought impossible: processing 10 million tokens in a single context window. To put this in perspective, that’s roughly 20 novels, 40 hours of video, or an entire mid-sized codebase—all in one prompt. The secret behind this breakthrough isn’t a revolutionary new model architecture or exotic hardware. It’s a clever distributed computing technique called Ring Attention that fundamentally rethinks how we compute attention across multiple GPUs. ...

7 min · 1456 words

The Hidden Memory Tax: Why Your 80GB GPU Still Can't Handle Long-Context LLMs

In March 2024, a team of researchers attempted to deploy a 70-billion parameter language model on a single NVIDIA H100 GPU with 80GB of VRAM. The model weights alone consumed approximately 140GB in FP16—already exceeding their hardware capacity. But even after applying 4-bit quantization to squeeze the weights down to ~40GB, the system still ran out of memory when processing contexts beyond 8,000 tokens. The culprit wasn’t the model size. It was something far more insidious: the KV cache. ...

9 min · 1846 words

How Bloom Filters Store 100 Million Items in 120 MB While Never Missing a Match

In 1970, Burton Howard Bloom faced a problem that would feel familiar to any modern software engineer working with large datasets. He needed to check whether words required special hyphenation rules, but storing 500,000 dictionary entries in memory was prohibitively expensive. His solution—a data structure that uses dramatically less space than any traditional approach—became one of the most widely deployed probabilistic data structures in computing history. The insight was radical: what if you could trade certainty for space? A Bloom filter will never tell you an item is absent when it’s actually present (no false negatives), but it might occasionally claim an item exists when it doesn’t (false positives). For many applications, this trade-off is not just acceptable—it’s transformative. ...

6 min · 1225 words