LLM 推論的六大 KV Cache 優化方向：Memory Allocation、Prefix Reuse、Hierarchical Cache、Compression、Eviction、Disaggregation
Chris Chien 整理 LLM 記憶體議題中的六大 KV Cache 優化方向：Memory Allocation、Prefix Reuse、Hierarchical Cache、Compression、Eviction、Disaggregation。這是部署 LLM serving 時的核心成本框架：不只看模型參數量，還要看長上下文、並發請求、prefill 重用、GPU/CPU/SSD 分層、量化壓縮與跨節點共享。
LLM Serving · KV Cache · Memory Efficiency
LLM 服務的成本不只取決於模型多大，也取決於 KV Cache 怎麼存、怎麼重用、放在哪裡、如何縮小、何時丟掉，以及能否跨裝置共享。這則 Threads 把 KV Cache 優化整理成六大方向，正好可作為部署長上下文與高並發推論服務時的檢查表。
- Threads：Chris Chien 整理六大 KV Cache 優化方向
- 可見作者 follow-up 補足後三項：Compression、Eviction、Disaggregation。
- 本文將 Threads 架構整理成 LLM serving 決策框架；具體實作可對應 vLLM PagedAttention、prefix caching、KV cache quantization、offloading、分散式 serving 等技術，但原文未指定單一框架。
六大方向總表
| 方向 | 核心問題 | 典型目標 |
|---|---|---|
| Memory Allocation | 如何存 | 降低碎片化，提高 GPU VRAM 利用率。 |
| Prefix Reuse | 如何重用 | 找出不同請求的共同 prefix，避免重複 prefill。 |
| Hierarchical Cache | 放在哪裡 | 在 GPU、CPU、SSD、遠端記憶體間分層管理，突破 VRAM 限制。 |
| Compression | 如何縮小 | 用 quantization 或壓縮降低 KV Cache 空間。 |
| Eviction | 丟掉哪些 | 保留高價值 cache，釋放低價值或不再需要的記憶體。 |
| Disaggregation | 如何跨裝置共享 | 讓 KV Cache 跨 GPU / server 重用，避免節點重複建立。 |
為什麼 KV Cache 是成本核心
長上下文與高並發時，KV Cache 會快速吃掉 GPU VRAM。模型權重可能是固定成本，但每個請求的上下文長度、batching、prefill、decode 階段，都會讓 KV Cache 成為動態瓶頸。優化 KV Cache 的目的，是同一張 GPU 能服務更多使用者，或在同樣延遲目標下支援更長 context。
Prefill 成本
長 prompt 進來時要先計算大量 token 的 KV；共同 system prompt、RAG 模板與工具說明若可重用，就能節省重複計算。
Decode 成本
生成每個新 token 都要讀歷史 KV；cache 位置與壓縮會直接影響 latency 與 throughput。
長上下文
context 越長，KV Cache 越大；只看模型參數量會低估實際 serving 記憶體。
多租戶服務
高並發時 allocator、eviction 與 prefix sharing 決定是否能避免 VRAM 浪費。
部署檢查表
- 服務是否支援 paged / block-based KV allocation，避免大塊連續記憶體造成碎片化？
- 是否有固定 system prompt / tools / RAG template 可做 prefix cache？
- GPU VRAM 不足時，是要降 context、降 batch、offload 到 CPU/SSD，還是換更大 GPU？
- KV quantization 對目標模型與長上下文品質是否可接受？