惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

C
CXSECURITY Database RSS Feed - CXSecurity.com
A
About on SuperTechFans
H
Help Net Security
Engineering at Meta
Engineering at Meta
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏
The Register - Security
The Register - Security
WordPress大学
WordPress大学
MongoDB | Blog
MongoDB | Blog
Hugging Face - Blog
Hugging Face - Blog
爱范儿
爱范儿
C
Check Point Blog
人人都是产品经理
人人都是产品经理
云风的 BLOG
云风的 BLOG
N
Netflix TechBlog - Medium
酷 壳 – CoolShell
酷 壳 – CoolShell
雷峰网
雷峰网
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
I
InfoQ
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The GitHub Blog
The GitHub Blog
Last Week in AI
Last Week in AI
D
Docker
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
博客园 - 叶小钗
Jina AI
Jina AI
F
Fortinet All Blogs
宝玉的分享
宝玉的分享
小众软件
小众软件
有赞技术团队
有赞技术团队
F
Full Disclosure
月光博客
月光博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Recorded Future
Recorded Future
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
量子位
U
Unit 42
T
The Blog of Author Tim Ferriss
Microsoft Azure Blog
Microsoft Azure Blog
V
V2EX
O
OpenAI News
S
Secure Thoughts
罗磊的独立博客
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Google Online Security Blog
Google Online Security Blog
Cloudbric
Cloudbric
W
WeLiveSecurity
IT之家
IT之家

Modular Blog

Qualcomm to Acquire Modular Modular 26.4: SOTA MoE Serving, Model Bringup via Agent Skills, Mojo 1.0 Beta 2 and More ModCon 2026: Modular’s Developer Conference Day Zero: MiniMax M3 Open Weights on Modular Cloud Modverse #55: Mojo 1.0 Beta, Community Mojo Libraries, and Real-Time Patient Conversations Powered by MAX What about OpenCL and CUDA C++ alternatives? (Democratizing AI Compute, Part 5) Why LLM Inference Needs a New Kind of Router - Part 3 Three trends from MLSys 2026 Why LLM Inference Needs a New Kind of Router - Part 2 How I built a pure Mojo app (and 10 libraries) with AI agents Hippocratic AI partners with Modular to power flexible, high-quality inference for real-time patient conversations Translating to Mojo via AI Agents Inkwell: Why Your Inference Platform Matters As Much As Your Model Why LLM Inference Needs a New Kind of Router - Part 1 Modular 26.3: Mojo 1.0 Beta, MAX Video Gen, and more Modverse #54: AMD AI DevDay, New Modular Offices, and a Community That Keeps Shipping How Frontier Coding Agents Built a Video Diffusion Pipeline on MAX TileTensor Part 1 - Safer, More Efficient GPU Kernels Modular Opens Edinburgh & San Francisco Offices Structured Mojo Kernels Part 4 - Portability and the Road Ahead Day Zero Launch: Fastest Performance for Gemma 4 on NVIDIA and AMD Modverse #54: From GTC to Edinburgh, a Community Building Momentum Software Pipelining for GPU Kernels: Part 1 - The Pipeline Problem Structured Mojo Kernels Part 3 - Composition in Practice Modular 26.2: State-of-the-Art Image Generation and Upgraded AI Coding with Mojo Modular at NVIDIA GTC 2026: MAX on Blackwell, Mojo Kernel Porting, and DeepSeek V3 on B200 Structured Mojo Kernels Part 2 - The Three Pillars Modverse #53: Community Builds, Research Milestones, and a Growing Ecosystem Structured Mojo Kernels Part 1 - Peak Performance, Half the Code The Claude C Compiler: What It Reveals About the Future of Software BentoML Joins Modular Modular 26.1: A Big Step Towards More Programmable and Portable AI Infrastructure How to Beat Unsloth's CUDA Kernel Using Mojo—With Zero GPU Experience 🔥 Modular 2025 Year in Review The path to Mojo 1.0 Modverse #52: Advancing AI Together — Community Projects & Platform Milestones Modular 25.7: Faster Inference, Safer GPU Programming, and a More Unified Developer Experience "TTS 1 Max" (powered by Modular Platform) Ranked #1 Speech Model on Artificial Analysis PyTorch and LLVM in 2025 — Keeping up With AI Innovation Achieving State-of-the-Art Performance on AMD MI355 — in Just 14 Days Modular Raises $250M to scale AI's Unified Compute Layer Modular 25.6: Unifying the latest GPUs from NVIDIA, AMD, and Apple Matrix Multiplication on Blackwell: Part 4 - Breaking SOTA Modverse #51: Modular x Inworld x Oracle, Modular Meetup Recap and Community Projects Matrix Multiplication on Blackwell: Part 3 - The Optimizations Behind 85% of SOTA Performance Matrix Multiplication on Blackwell: Part 2 - Using Hardware Features to Optimize Matmul Matrix Multiplication on Blackwell: Part 1 - Introduction Modverse #50: Modular Platform 25.5, Community Meetups, and Mojo's Debut in the Stack Overflow Developer Survey Modular Platform 25.5: Introducing Large Scale Batch Inference SF Compute and Modular Partner to Revolutionize AI Inference Economics AI Agents for AWS Marketplace Modverse #49: Modular Platform 25.4, Modular 🤝 AMD, and Modular Hack Weekend Inside Modular Hack Weekend: Top Projects and Community Highlights How is Modular Democratizing AI Compute? (Democratizing AI Compute, Part 11) Modular 25.4: One Container, AMD and NVIDIA GPUs, No Lock-In Introducing Mammoth: Enterprise-Scale GenAI Deployments Made Simple Modular + AMD: Unleashing AI performance on AMD GPUs Modverse #48: Modular Platform 25.3, MAX AI Kernels, and the Modular GPU Kernel Hackathon Exploring Metaprogramming in Mojo Modular GPU Kernel Hackathon Highlights: Innovation, Community, & Mojo🔥 Modular’s bet to break out of the Matrix (Democratizing AI Compute, Part 10) Modular Platform 25.3: 450K+ Lines of Open Source Code and pip Packaging A New, Simpler License for MAX and Mojo Why do HW companies struggle to build AI software? (Democratizing AI Compute, Part 9) Modverse #47: MAX 25.2 and an evening of GPU programming at Modular HQ What about the MLIR compiler infrastructure? (Democratizing AI Compute, Part 8) What about Triton and Python eDSLs? (Democratizing AI Compute, Part 7) MAX 25.2: Unleash the power of your H200's–without CUDA! What about TVM, XLA, and AI compilers? (Democratizing AI Compute, Part 6) Modverse #46: MAX 25.1, MAX Builds, and Democratizing AI Compute CUDA is the incumbent, but is it any good? (Democratizing AI Compute, Part 4) MAX 25.1 - Introducing MAX Builds How did CUDA succeed? (Democratizing AI Compute, Part 3) Paged Attention & Prefix Caching Now Available in MAX Serve What exactly is “CUDA”? (Democratizing AI Compute, Part 2) Modular DeepSeek's Impact on AI (Democratizing AI Compute, Part 1) Modular Hands-on with Mojo 24.6 Evaluating Llama Guard with MAX 24.6 and Hugging Face Modular Introducing MAX 24.6: A GPU Native Generative AI Platform MAX GPU: State of the Art Throughput on a New GenAI platform Understanding SIMD: Infinite Complexity of Trivial Problems Community Spotlight: Writing Mojo with Cursor Hands-on with Mojo 24.5 MAX 24.5 - With SOTA CPU Performance for Llama 3.1 Announcing stack-pr: an open source tool for managing stacked PRs on GitHub Debugging in Mojo🔥 Write hardware-agnostic custom ops for PyTorch | Modular Take control of your AI Develop locally, deploy globally A brief guide to the Mojo n-body example What's new in MAX 24.4? MAX on macOS, fast local Llama3, native quantization and GGUF support What’s new in Mojo 24.4? Improved collections, new traits, os module features and core language enhancements MAX 24.4 - Introducing quantization APIs and MAX on macOS Deep dive into ownership in Mojo What ownership is really about: a mental model approach Fast⚡k-means clustering in Mojo🔥: a guide to porting Python to Mojo🔥 for accelerated k-means clustering
The Five Eras of KVCache
No items found. · 2026-02-05 · via Modular Blog

February 5, 2026

Brian Zhang

Introduction

Key–Value Cache (KV cache/KVCache) is a foundational building block of modern LLM serving systems. It stores past attention states so the model can generate new tokens efficiently without excessive re-computation.

There are two phases to LLM inference: Prefill and Decode. In the Prefill phase, the attention states are computed for each token in the input prompt. In the subsequent Decode phase, new tokens are generated one by one in an autoregressive fashion by attending on the Key-Value associated with previous tokens.

https://www.nature.com/articles/s41586-023-06647-8
https://www.nature.com/articles/s41586-023-06647-8

vLLM, SGLang, TensorRT-LLM, and MAX Serve are all built on top of increasingly sophisticated KV cache management. This blog explores the evolution and role of the KV cache in these inference engines

Era 0: Pre-GenAI (<2017)

Before transformers took over, deep learning was dominated by stateless, feed-forward architectures like ResNet, YOLO, VGG, and Inception. These models did not require persistent state across inference steps, so the concept of a KVCache simply didn’t exist even in inference frameworks like ONNX or TensorRT.

Era 1: Continuous KV Cache (2017)

The original transformer (2017) established the architecture that would eventually dominate ML. This design was a departure from prior models, requiring a KVCache to efficiently keep track of the state associated with each request. Nevertheless, the major step-change in intelligence enabled by transformers more than justified their added complexity.

At the time, early LLM serving engines implemented KV caches naively:

  • For each request, they preallocated a contiguous KV tensor with max_seq_len tokens.
  • The storage was 2 x num_layers × num_heads × head_dim × max_seq_len per request.

This Contiguous KV cache design was extremely wasteful, but still offered huge performance gains over recomputing attention keys/values for each token:

  • ✔ Simple
  • ✘ Memory usage scales aggressively due to the max_seq_len × batch_size factor
  • ✘ Constrained max_batch_size due to limited memory capacity
  • ✘ High memory fragmentation due to variable-length requests
  • ✘ Most request are far shorter than max_seq_len, leaving much wasted capacity

This was the approach of early inference engines like HuggingFace Transformers.

Era 2: PagedAttention (2023)

A breakthrough arrived with PagedAttention, introduced by vLLM. The key idea was to borrow a technique from Operating Systems by allocating KV in fixed-size pages that could be dynamically allocated as sequences grew.

Benefits:

  • ✔ Dramatically improves memory utilization and reduces fragmentation
  • ✔ Enables hundreds / thousands of concurrent requests
  • ✔ Drives up throughput via larger batch sizes
  • ✔ Allows for efficient KV cache reuse via Prefix Caching, a huge throughput multiplier for multi-turn chat workloads

PagedAttention became the de-facto standard for LLM serving, leading to new inference engines like TensorRT-LLM and SGLang.

Era 3: Heterogenous KV Caches (2024)

The world of ML and the LLM serving landscape is far more complex now. New optimizations along with modern multimodal and hybrid models require multiple different kinds of state, each with separate caching requirements. In this Era, the term “KV Cache” is being stretched far beyond its original meaning.

  1. Speculative decoding accelerates LLM inference by having a small draft model generate multiple tokens ahead and then using a larger target model to verify and accept those tokens in a single pass. With this technique, a separate KV cache needs to be maintained for the draft and target model.
  2. Vision encoders in Vision–Language Models (VLMs) generate large image embeddings that can be cached and reused across requests. While this differs from the traditional notion of a “KV cache” or prefix caching, it follows the same underlying principle of memoizing expensive intermediate states. Models which benefit from this cache include QwenVL and InternVL.
  3. Quantized KV Cache: Low precision datatypes like FP8 help reduce the storage requirements of the KV cache and rely on per-tensor/row/block scaling factors to preserve numerical range. This requires the KV cache implementation to also manage memory for these scaling factors.
  4. Sliding Window Attention (SWA) limits each token to attend only to the preceding window_size tokens instead of the entire sequence, reducing memory and compute. As a result, KV cache management and prefix caching must track which tokens fall within the current window, making cache hits and evictions more complex than in full attention.
    Fig 11. https://arxiv.org/pdf/2503.18292
    Fig 11. https://arxiv.org/pdf/2503.18292
  5. Mamba / State Space Models replaces attention with a recurrent state that updates a single large vector for each new token. This makes prefix caching more complex because serving systems must decide when and how to checkpoint or store the evolving state vector for future reuse.
  6. Composite Models are composed of multiple sub-models. For example, it is a common pattern to combine an LLM backbone with an audio decoder. Each of these sub-models may require maintaining separate KV caches.
  7. Hybrid Models combine multiple layer types within a single model, which often necessitates maintaining multiple KV caches to handle each layer’s distinct attention or state mechanism. Examples include:
    1. Sliding Window Attention + Full Attention (Gemma2/3, Ministral, GPT-OSS, Cohere)
    2. Mamba + Full Attention (Jamba, Bamba, Minimax)
    3. Local Chunked + Full Attention (Llama4)
    Fig 1. https://arxiv.org/pdf/2503.18292
    Fig 1. https://arxiv.org/pdf/2503.18292
  • This list is non-exhaustive. There are a ton of other ideas like Transfusion for joint text–image generation, dynamic KV cache compression, Cross-Attention (not to be confused with Cross-Layer Attention), etc.
  • This heterogeneity and diversity of KV cache’s with different shapes, lifetimes, and properties led to the creation of specialized managers in modern LLM serving engines. For example, vLLM has the Vision Encoding Cache, Mamba Cache, etc, in additional to its normal KV cache.

    There are several challenges emerging with this design:

    • ✘ Memory fragmentation due to multiple KV cache managers can lead to small batch sizes
    • ✘ Challenging to predict at server startup how much memory to allocate per KV cache
    • ✘ Disjoint Prefix Caching implementations lead to suboptimal cache hit rates
    • ✘ Diversity makes feature composition challenging

    Era 4: Distributed KV Cache (2025+)

    As LLMs grow in size and handle increasing workloads, a single GPU or node becomes insufficient. Now LLM serving and the KV cache is becoming multi-node and distributed, often spanning an entire datacenter. Managing the massive scale of the KV cache requires new techniques as such:

    • Disaggregated Inference: LLM inference is divided into Prefill and Decode phases, deployed and scaled on separate model instances to reduce interference and optimize resource usage. A key challenge is efficiently transferring the KV cache from Prefill nodes to Decode nodes. Recently new variants of disaggregation have emerged like Encoder Disaggregation.
    • KV Cache-aware Load Balancing: Request routing prioritizes instances that already hold the relevant KV cache, maximizing prefix cache hits. This requires a cluster-wide view of the current state of the KV cache on each of the individual instances.
    • Hierarchical KVCache: To increase KV cache capacity, cold pages can be spilled from GPU memory to more abundant CPU RAM or SSD. This extends the effective KV cache size while keeping the hot, frequently accessed pages in GPU memory for low-latency access. The higher latency of loading/storing of KV cache for one model layer from a lower tier of the cache can be hidden by overlapping it with the GPU execution for the prior layer.

    Many new kubernetes-native inference solutions like Nvidia Dynamo, vLLM Production Stack, llm-d, or AIBrix have emerged to tame this complexity. However, distributed LLM inference is still very hard:

    • ✘ Many existing optimizations or architectures are still incompatible with distributed inference like speculative decoding or VLMs
    • ✘ Despite the wide availability of open-source solutions, it still requires expert knowledge and a lot of patience to deploy
    • ✘ Inter-node GPU networking over Infiniband or RoCE is challenging and many libraries like NIXL are nascent
    • ✘ There are many inherent problems for large-scale distributed systems such as managing failover, stragglers, hardware defects, auto-scaling, etc

    Era 5: Unified Hybrid KV Caches (2025+)

    The next stage is building unified KV memory systems where many heterogeneous KV types share a common memory pool rather than isolated allocators. Another overarching theme in this era is striving for composability between all available optimizations.

    This evolution is happening today!

    Emerging approaches:

    1. vLLM / Jenga – Huge Pages + LCM Sizing
      1. Use huge pages with sizes chosen as the least common multiple of smaller page formats so different KV shapes can co-exist efficiently.
      2. Unified Prefix Caching design that takes into consideration many KV caches at once to improve balance and hit rate.
    Jenga
    Jenga
    Jenga
    Jenga

    2. SGLang – CUDA Virtual Memory

    1. SGLang uses CUDA Virtual Memory APIs to dynamically remap device memory and unify different KV regions.
    2. his enables virtually contiguous but physically scattered KV pages
    https://pytorch.org/blog/hybrid-models-meet-sglang-more-than-full-attention/
    https://pytorch.org/blog/hybrid-models-meet-sglang-more-than-full-attention/
    1. Significant effort is also being invested into feature composability. In fact, this is one of the critical tenets of the 2025Q4 SGLang roadmap. For instance, one should be able to run a VLM model with Speculative Decoding across multiple nodes in a disaggregated setup. This will require long-term software investment and re-architecting core components of the inference engine.

    Conclusion

    What began as a simple optimization—caching attention states to avoid recomputation—has evolved into one of the most complex subsystems in modern AI infrastructure. Each era has brought new challenges: memory fragmentation, heterogeneous model architectures, distributed coordination, and now the need for unified systems that compose cleanly across all these dimensions. As new models, optimizations, and hardware emerge, KV cache management will require innovation across all layers of the LLM inference stack from GPU kernels to cluster-scheduling.

    This complexity is precisely why we built MAX with a ground-up approach to KV cache management. Combined with Mojo's performance and flexibility, we're building infrastructure that handles today's models while adapting to tomorrow's innovations.

    • Person with blonde hair using a laptop with an Apple logo.

      Sign up today

      Signup to our Cloud Platform today to get started easily.

      Sign Up

    • Magnifying glass emoji with black handle and round clear lens.

      Browse open models

      Browse our model catalog, or deploy your own custom model

      Browse models

    Sign up for our newsletter

    Get all our latest news, announcements and updates delivered directly to your inbox. Unsubscribe at anytime.

    Thanks for signing up to our newsletter! 🚀

    Thank you,

    Modular Sales Team

    Oops! Something went wrong while submitting the form.