KV Cache管理架構大變革：逐步邁向統一混合內存新模式

在生產環境部署過LLM的人都知道模型權重只是問題的一半，另一半是KV cache：存儲注意力狀態的運行時內存，讓模型在生成token時不必從頭開始重算。能不能管好這塊內存決定了系統是一個卡頓的demo還是一個可用的推理服務。

本文梳理KV cache管理經歷的5個時代，從它根本不存在的階段，到今天正在成型的統一內存架構。文中會結合多個模型的部署經驗，對比vLLM、SGLang和TensorRT-LLM在各階段的應對思路。讀完后應當能建立一套判斷框架，為具體場景選擇合適的方案。

先從KV cache本身說起。

背景：Prefill、Decode與KV Cache

LLM推理分兩個階段。Prefill階段并行處理全部輸入token，在每個注意力層為每個token計算Key和Value向量，屬于計算密集型，GPU并行度越高越好。Decode階段則以自回歸方式逐token生成，每個新token都要對先前所有Key-Value對做注意力計算；GPU大部分時間花在從HBM讀取KV cache而非運算上，瓶頸在內存帶寬。

KV cache的作用就是把已經算過的Key和Value向量緩存下來，避免每個decode步驟重復計算。沒有它每生成一個token就得對整個序列重跑一遍注意力，推理速度完全無法接受。

以Llama-3–70B、8K上下文為例：

KV cache per token = 2 (K+V) x 80 layers x 8 KV heads x 128 head_dim x 2 bytes (FP16)
= 2 x 80 x 8 x 128 x 2 = 327,680 bytes ≈ 320 KB per token
For 8K tokens: 320 KB x 8,192 = 2.56 GB per request
For 32 concurrent requests: 2.56 GB x 32 = 81.9 GB

81.9 GB：一塊A100 80GB的全部顯存都裝不下留給模型權重的空間是零。KV cache管理重要正是因為這一點。

Era 0：Pre-GenAI（2017年之前）

Transformer出現之前深度學習的主力是ResNet、YOLO、VGG、Inception這些無狀態前饋架構。每次推理獨立處理一個輸入步驟之間沒有任何持久狀態，KV cache的概念自然無從談起。

ONNX Runtime、TensorRT等推理框架也是為這類無狀態負載設計的：加載模型，跑前向傳播，返回結果。

如果今天仍然只是服務傳統視覺或表格模型，后面這些復雜度都不需要關心。

Era 1：連續KV Cache（2017年）

Transformer原始論文（2017）帶來了自注意力機制，也帶來了在decode步驟之間緩存Key和Value張量的需求。

早期推理引擎如HuggingFace Transformers用最簡單的的方式實現KV cache：為每個請求預分配一個max_seq_len大小的連續張量，單個請求的存儲量為2 x num_layers x num_heads x head_dim x max_seq_len。

好處是實現簡單，相比每步重算注意力有很大的速度提升。

代價也很明顯，內存占用按max_seq_len x batch_size線性增長而非跟隨實際序列長度；大多數請求遠短于最大長度，造成嚴重的內部碎片；并發batch大小因此受限，請求之間也無法共享內存。

性能分析的數據很直白：在這些系統中已分配的KV cache內存只有20–38%真正存儲了有用的token狀態，其余全部浪費在填充和碎片上。

Era 2：PagedAttention（2023年）

PagedAttention是真正改變規則的技術，UC Berkeley的vLLM團隊從操作系統借來了一個基本思路：帶分頁的虛擬內存。

做法是把KV cache切分為固定大小的頁（block），隨著序列增長按需分配，而非一次性為每個請求開辟一大塊連續內存。一個block table將邏輯頁映射到物理內存，原理和操作系統頁表將虛擬地址映射到物理RAM完全一致。

vLLM論文給出的數據相當驚人：吞吐量比FasterTransformer和Orca提升2–4倍；碎片率降到4%以下（之前是60–80%）內存浪費接近于零；并發請求數從幾十躍升到數百乃至數千。

PagedAttention還打開了前綴緩存的大門：SGLang的RadixAttention正是基于此。多個請求如果共享同一前綴（系統提示詞、共享文檔等）對應的KV cache頁可以直接復用而非重新計算。對多輪對話和RAG場景而言，這是一個巨大的吞吐量倍增器。

不過PagedAttention并非沒有取舍：注意力kernel因為非連續內存訪問變得更復雜，block大小需要調優，而且它默認假設KV cache是同構的：每層大小一致。

這些局限并不妨礙它成為事實標準。今天vLLM、SGLang、TensorRT-LLM全部以PagedAttention為底層基礎。

實踐比較：vLLM vs SGLang前綴緩存

兩個框架都支持前綴緩存，實現路徑不同。vLLM在block級別做基于哈希的前綴匹配；SGLang則用RadixAttention樹在基數樹結構中維護KV block的LRU緩存，支持跨多次生成調用的自動復用。

從實際部署看，SGLang的方案在復雜多調用場景（agent、思維樹）中緩存命中率更高，vLLM的方案更簡潔標準聊天場景下表現良好。

Era 3：異構KV Cache（2024年）

2024年模型架構和優化技術快速分化，推理系統需要管理形狀、生命周期、訪問模式各異的多種緩存狀態。"KV cache"這個術語的外延已經遠超原始定義。

投機解碼用一個小型草稿模型一次提出多個候選token，再由大型目標模型批量驗證，草稿模型和目標模型各自維護獨立的KV cache。視覺語言模型（VLM）如QwenVL、InternVL的視覺編碼器會產生大型圖像嵌入，這些嵌入可以跨請求緩存復用，但尺寸與文本KV cache不同。量化KV Cache用FP8等低精度格式壓縮存儲，需要額外維護縮放因子。滑動窗口注意力（SWA）只關注最近window_size個token，KV cache管理需要判斷哪些token在窗口內、哪些已過期可以淘汰。

Mamba / 狀態空間模型則是另外一條完全不同的路：用循環狀態替代注意力，每個新token更新一個固定大小的向量。這種狀態無法在token粒度上共享也不容易回滾，和KV cache在本質上就不是一回事。

混合模型則在單個模型中組合多種層類型：

• 滑動窗口 + 全注意力（Gemma 2/3、Ministral）
• Mamba + 全注意力（Jamba、Bamba）
• 局部分塊 + 全注意力（Llama 4）

Jenga論文給出了量化數據：Llama 3.2 11B Vision如果把所有層按統一方式管理，內存浪費達79.6%；Gemma-2為25%；Ministral為56.25%。

異構緩存帶來的麻煩包括：多個獨立緩存管理器之間的內存碎片、服務器啟動時難以預測內存分配、前綴緩存按類型各自實現導致命中率下降，以及功能組合的復雜度急劇上升。

vLLM等框架在實踐中走向了分離管理器的路線——普通KV cache一個管理器，視覺編碼緩存一個，Mamba緩存又一個。能用，但脆弱，擴展性差。

Era 4：分布式KV Cache（2025+）

模型規模持續增長單GPU甚至單節點已不足以承載。KV cache管理正在變成一個多節點、數據中心級別的問題。

解耦推理

DistServe的核心提案是將prefill和decode階段部署到不同的GPU實例上。prefill受計算約束，decode受內存約束，兩者適合不同的硬件配置和并行策略——分開部署比混在一起更合理。

DistServe的實測數據：與共置系統相比請求處理量提升4.48倍（或在同等吞吐下收緊SLO 10.2倍）。這時候問題就變為了KV cache從prefill節點到decode節點的傳輸效率。

vLLM的Encoder Disaggregation將視覺編碼器拆為獨立可擴展服務，專門用于多模態場景，消除編碼器與解碼器之間的干擾后goodput提升2–2.5倍。

KV Cache感知的負載均衡

NVIDIA Dynamo引入了KV cache感知路由：請求路由器優先把請求轉發到已經持有相關KV cache的實例上，在集群層面最大化前綴緩存命中率。這要求每個實例都能獲取集群范圍內的緩存狀態視圖。

分層KV Cache

Moonshot AI的Mooncake采用以KV cache為中心的解耦架構，冷KV頁從GPU HBM溢出到CPU DRAM或SSD，熱頁留在GPU上，從而在不犧牲熱數據訪問速度的前提下擴展有效緩存容量。從低層級加載或寫回一層KV的延遲可以和前一層的GPU計算重疊，從而被隱藏。

長上下文場景下Mooncake的吞吐量最高提升525%，同時滿足SLO約束。在Kimi的真實負載中，請求處理量多出75%。

分布式時代的困難很實際：投機解碼、VLM等不少優化手段和分布式推理還無法兼容；部署需要相當的專業知識和耐心；節點間網絡（InfiniBand、RoCE）本身就是難題，NIXL一類的庫還很不成熟；故障轉移、落后者節點、硬件缺陷、自動擴縮容。每一項都在真實環境中帶來額外的復雜度。

Kubernetes原生方案如NVIDIA Dynamo、vLLM Production Stack、llm-d、AIBrix正在試圖收斂這些復雜度，但整體仍處于早期。

Era 5：統一混合KV Cache（2025+）

當前前沿工作的方向是構建統一內存系統：異構KV類型共享同一個內存池，而非各自維護獨立的分配器。貫穿其中的主題是可組合性——每一項優化都應當能和其他任意優化疊加使用。

Jenga：大頁 + LCM尺寸對齊

Jenga提出了兩級內存分配器。核心思路是取不同嵌入尺寸的最小公倍數（LCM）作為"大頁"尺寸，讓不同KV形狀在同一內存池中共存而不產生碎片。

舉例來說，圖像token的KV為256字節，文本token的KV為384字節，則取LCM(256, 384) = 768字節為大頁尺寸。大頁再按特定層類型細分為小頁。

與原版vLLM相比，Jenga的GPU內存利用率最高改善79.6%，吞吐量最高提升4.92倍（平均1.80倍）。

SGLang：CUDA虛擬內存

SGLang則又用了另外一個方法：利用CUDA Virtual Memory API動態重映射設備內存，讓KV頁在虛擬地址空間中連續、物理上分散。彈性內存池可以在運行時動態調整不同池類型（如Mamba池與KV cache池）之間的分配比例。

SGLang 2026年Q1路線圖明確把功能可組合性列為核心目標：在解耦部署中跨多節點對混合VLM執行投機解碼。要達成這一目標，需要對引擎核心組件做長周期的架構重構。

比較表：各時代一覽

不同場景下的選擇

結合生產部署經驗給出一些判斷。

標準文本LLM服務（聊天、補全）：Era 2（PagedAttention）是基礎，選vLLM或SGLang即可。有共享系統提示詞的場景應開啟前綴緩存。

多模態模型（VLM）：屬于Era 3的范疇，需要關注框架對視覺嵌入的處理方式。圖像密集型負載占比高時，可以評估vLLM的編碼器解耦（Era 4）。

混合架構（Gemma 3、Jamba、Llama 4）：Era 5直接相關。SGLang的CUDA虛擬內存方案和Jenga的LCM分配器正是針對此類場景設計。

大規模高吞吐量生產：Era 4是重點。解耦prefill/decode配合KV感知路由對成本效率的改善非常可觀，NVIDIA Dynamo和Mooncake是參考架構。

長上下文負載（100K+ token）：分層KV cache（Era 4）配合GPU到CPU的溢出機制不可或缺，否則GPU顯存根本撐不住。

總結

KV cache才是真正的瓶頸，Llama-3–70B在32個并發8K token請求下的KV cache總量超過80GB，比一整塊A100的顯存還大。

KV cache管理的演進軌跡和操作系統內存管理的歷史驚人地相似：從連續分配到虛擬內存、分頁，再到分布式共享內存。區別在于操作系統花了40年走完的路，KV cache管理在8年內走完了，背后的驅動力是LLM負載的爆發式增長。對于正在構建LLM基礎設施的工程團隊來說，理解這些演進階段沒有可選項：后面所有工作都建立在這個基礎之上。

https://avoid.overfit.cn/post/6272647e7bc24c8084545ec3f5ca7972

by Luv Bansal