LLM Serving 中的四种缓存：KV Cache、Prefix Cache、Prompt Cache 与 Semantic Cache
随着大模型上下文越来越长，LLM Serving 的性能瓶颈已经不只是模型参数量和 GPU 算力。
一个典型的 LLM 请求可能包含：
- System Prompt
- Tool Definitions
- Conversation History
- RAG 检索出来的文档
- 用户当前问题
- Few-shot Examples
- Agent 的上下文和状态
这些内容经常达到几千、几万甚至更多 Token。
如果每一次请求都从头计算这些 Token，那么大量 GPU 算力实际上消耗在了重复计算上。
因此，"缓存"逐渐成为现代 LLM Serving 系统最重要的优化手段之一。
目前讨论最多的缓存机制主要包括：
- KV Cache
- Prefix Cache
- Prompt Cache
- Semantic Cache
不过，这四者并不是完全处于同一个抽象层级。
可以先用一句话理解：
KV Cache 是基础设施，Prefix Cache 是跨请求复用 KV Cache 的技术，Prompt Cache 是面向用户/API 的 Prompt 前缀缓存能力，而 Semantic Cache 则是在模型之前直接复用历史答案。
1. 什么是 LLM Cache？
传统 Web 系统中的缓存通常是：
text
Request
│
▼
Cache
├── Hit → 直接返回结果
└── Miss → Database / Backend例如：
text
GET /product/123如果 Redis 中已经存在：
text
product:123 → {...}那么就不需要重新查询数据库。
LLM 的缓存思想类似，但比传统缓存复杂很多。
因为一次 LLM 请求内部大致经历：
text
Prompt
│
▼
Tokenization
│
▼
Prefill
│
▼
KV Cache
│
▼
Decode
│
▼
Response因此，我们可以在不同层面消除重复计算。
例如：
text
LLM Request
│
▼
┌────────────────┐
│ Semantic Cache │
└───────┬────────┘
│ Miss
▼
┌────────────────┐
│ Prompt/Prefix │
│ Cache │
└───────┬────────┘
│
▼
Transformer
│
▼
KV Cache
│
▼
Decode因此，不同缓存解决的问题其实并不相同：
| 缓存 | 主要解决的问题 |
|---|---|
| KV Cache | 同一次生成过程中，不重复计算已经生成过的 Token |
| Prefix Cache | 不同请求之间，不重复计算相同的 Prompt 前缀 |
| Prompt Cache | 从 API / 产品层面复用重复 Prompt 的计算结果 |
| Semantic Cache | 相似问题直接复用历史答案，甚至不调用 LLM |
理解这几个层次非常重要。
2. 四种 LLM Cache
2.1 KV Cache
2.1.1 KV Cache 是什么？
KV Cache 是 Transformer 推理中最基础、也是最重要的一类缓存。
Transformer 的 Attention 可以简单表示为：
text
Q = XWq
K = XWk
V = XWv
Attention(Q,K,V)在自回归生成过程中，例如已经生成：
text
I love large language现在需要生成下一个 Token。
对于之前几个 Token：
text
I
love
large
language它们对应的 Key 和 Value 已经计算过了。
如果每生成一个新 Token 都重新计算之前所有 Token 的 K/V，计算量会非常大。
因此 Serving 系统会把历史 Token 的：
text
Key
Value保存下来。
也就是：
text
KV Cache下一次生成只需要计算新 Token 的 Q/K/V，然后读取之前的 KV。
流程从：
text
Token 1
Token 1 + Token 2
Token 1 + Token 2 + Token 3
Token 1 + Token 2 + Token 3 + Token 4
...变成：
text
KV(1)
KV(1) + KV(2)
KV(1,2) + KV(3)
KV(1,2,3) + KV(4)
...所以 KV Cache 本质上解决的是：
单次请求的 Decode 阶段，避免重复计算历史 Token。
2.1.2 KV Cache 的特点
KV Cache 通常存储在：
text
GPU HBM因为 Decode 阶段需要频繁读取它。
它的优点非常明显：
- 大幅减少自回归 Decode 的重复计算
- 几乎是现代 Transformer LLM Serving 的标准配置
- 不改变模型输出
- 对用户完全透明
但缺点也非常明显：
非常占显存。
KV Cache 大小通常与以下因素相关：
text
Batch Size
× Sequence Length
× Number of Layers
× KV Heads
× Head Dimension
× Data Type所以长上下文模型时代，一个非常核心的问题变成了：
text
GPU Memory
│
├── Model Weights
└── KV Cache有时候 Serving 系统真正限制并发量的，并不是模型权重，而是 KV Cache。
这也是为什么 vLLM 的 PagedAttention 会如此重要：它希望像操作系统管理虚拟内存一样，以 Block 的方式管理 KV Cache，减少显存碎片并提高利用率。
2.2 Prefix Cache
Prefix Cache 可以理解为：
跨请求共享 KV Cache。
这是它和普通 KV Cache 最大的区别。
假设两个请求分别是：
text
Request A:
System Prompt
+ 10000 token document
+ "总结这篇文章"以及：
text
Request B:
System Prompt
+ 10000 token document
+ "这篇文章的核心观点是什么？"前面的：
text
System Prompt
+ 10000 token document完全一样。
传统情况下：
text
Request A:
10000 Token Prefill
↓
KV A
Request B:
10000 Token Prefill
↓
KV B虽然内容完全一样，但计算了两遍。
Prefix Cache 的做法是：
text
第一次：
10000 Token
│
▼
Prefill
│
▼
KV Cache
│
▼
Prefix Cache第二次：
text
Same Prefix
│
▼
Prefix Cache Hit
│
▼
Reuse KV因此 Request B 不需要重新 Prefill 那 10000 个 Token。
vLLM 的 Automatic Prefix Caching 就是典型实现：它缓存已经计算出来的 KV Cache Block，当新的请求具有相同 Token Prefix 时，可以直接复用这些 Block，从而跳过共享部分的计算。
Prefix Cache 的关键点
Prefix Cache 通常要求：
text
Token Prefix 必须一致例如：
text
A:
You are a helpful assistant.
Document: xxxxxxxxx
Question: A
B:
You are a helpful assistant.
Document: xxxxxxxxx
Question: B可以很好命中。
但是：
text
A:
Document
System Prompt
Question
B:
System Prompt
Document
Question即使内容基本一样，因为 Token 顺序不同，通常也不能复用同一个 Prefix。
所以 Prefix Cache 非常依赖一个工程实践：
把稳定、不变、重复率高的内容放在 Prompt 前面，把变化最大的内容放在后面。
例如：
text
推荐：
System Prompt
Tool Definitions
Shared Knowledge
Conversation History
Current User Query而不是：
text
Current User Query
System Prompt
Tool Definitions
Shared Knowledge在 vLLM 中，Prefix Cache 会基于 Token Block 计算 Hash，并寻找最长可复用前缀。现代实现还需要考虑多租户隔离以及 timing side-channel 等安全问题。
2.3 Prompt Cache
Prompt Cache 是一个特别容易和 Prefix Cache 混淆的概念。
从用户或者 API 使用者角度，可以理解成：
LLM Provider 帮用户缓存重复 Prompt 的计算结果，让后续请求减少 Prefill 计算。
例如：
text
Prompt:
System Prompt 2K
Tool Definitions 3K
Knowledge 15K
User Question 100总长度：
text
20K Token第二次调用时只有：
text
User Question发生变化。
那么 Provider 可以把前面的：
text
System Prompt
Tool Definitions
Knowledge对应的计算状态缓存下来。
于是：
text
第一次请求：
20K Input
│
├── 20K Prefill
└── 建立 Cache
第二次请求：
20K Input
│
├── 19K Cached
└── 1K New这样 Prefill 成本和 TTFT 都会明显下降。
Prompt Cache 和 Prefix Cache 到底有什么区别？
严格来说，它们经常不是两套完全独立的底层技术。
很多情况下：
text
Prompt Cache
│
▼
Prefix Matching
│
▼
Cached KV State也就是说：
Prompt Cache 更像产品/API 概念，而 Prefix Cache 更像 Serving Engine 的实现机制。
OpenAI 当前对 Prompt Caching 的说明也明确指出，其复用的是 Prompt 中未变化前缀对应的 KV states，而不是简单把 Prompt 文本存在一个字符串缓存里。
因此可以简单理解：
text
KV Cache
↑
│
Prefix Cache
↑
│
Prompt Cache API三者实际上存在明显的上下层关系，而不是三个互相独立的缓存。
Prompt Cache 最适合哪些场景？
尤其适合：
text
Agent
RAG
Chat
Coding Assistant
Long Document QA
Few-shot Learning
Tool Calling因为这些应用的 Prompt 往往具有：
text
大量固定内容
+
少量变化内容例如一个 Agent：
text
System Prompt 3000
Tool Definitions 5000
Instructions 2000
Conversation History 5000
Current Query 300总计：
text
15300 Tokens如果前 10000～15000 Token 经常重复，那么 Prompt Cache 的价值非常高。
2.4 Semantic Cache
Semantic Cache 和前三种缓存的思路完全不同。
前三种主要是在：
text
LLM Serving / Transformer内部减少计算。
Semantic Cache 则位于：
text
LLM 调用之前它解决的问题是：
这个问题以前是不是已经回答过？
比如用户问：
text
公司的退款政策是什么？之前另外一个用户问过：
text
我买的东西怎么退款？字符串完全不同。
传统 Cache：
text
Hash("公司的退款政策是什么？")
!=
Hash("我买的东西怎么退款？")所以无法命中。
Semantic Cache 会先将问题转成 Embedding：
text
Query
│
▼
Embedding Model
│
▼
Vector然后搜索历史问题：
text
Vector DB / Vector Index
Q1 ── 0.96 similarity ──> Current Query
Q2 ── 0.51
Q3 ── 0.43如果：
text
similarity > threshold就直接返回之前的 Response。
即：
text
User Query
│
▼
Embedding
│
▼
Semantic Cache
/ \
Hit Miss
│ │
│ ▼
│ LLM
│ │
└────────┘
│
▼
ResponseRedis、LangChain 等目前都已经提供 Semantic Cache 相关能力，其基本思路就是通过 Embedding + Vector Similarity Search 寻找语义相似的问题，并直接复用已有答案。
Semantic Cache 最大的优势
如果 Prefix Cache 命中：
text
仍然需要执行 LLM Decode而 Semantic Cache 命中：
text
LLM 可以完全不运行因此理论上：
text
Semantic Cache Hit
Cost ≈ Embedding + Vector Search而不是：
text
Cost = Prefill + Decode所以 Semantic Cache 对：
text
客服
FAQ
知识问答
IT Helpdesk
标准化问答
重复查询较多的 Copilot特别有效。
Semantic Cache 最大的问题
问题也很明显：
语义相似 ≠ 答案一定相同。
例如：
text
Query A:
iPhone 17 多少钱？
Query B:
iPhone 17 去年多少钱？Embedding Similarity 可能非常高。
但答案完全不是一个问题。
所以 Semantic Cache 必须综合考虑：
text
Similarity Threshold
Tenant
User
Language
Region
Time
Model Version
Knowledge Version
Permission
Prompt VersionRedis 的 Semantic Cache 文档也特别强调了这个问题：Similarity Threshold 太松容易产生 False Positive，太严格又会让 Hit Rate 明显下降，因此通常需要结合 metadata filtering、TTL 等机制保证正确性。
2.5 四种 Cache 对比
| 维度 | KV Cache | Prefix Cache | Prompt Cache | Semantic Cache |
|---|---|---|---|---|
| 缓存内容 | Attention K/V | 可复用 Prefix 的 KV | Prompt Prefix 对应的计算状态 | Query + Response |
| 所在层 | Transformer Runtime | Serving Engine | Provider / API / Serving | Application |
| 是否跨请求 | 通常不是重点 | 是 | 是 | 是 |
| 匹配方式 | 当前 Sequence | Token Prefix | Prompt Prefix | Semantic Similarity |
| 是否要求文本完全一致 | N/A | Prefix 基本一致 | Prefix 基本一致 | 不需要 |
| 是否减少 Prefill | Decode 本身不重复历史计算 | 是 | 是 | 完全跳过 |
| 是否减少 Decode | 否 | 否 | 否 | 是 |
| 是否仍调用 LLM | 是 | 是 | 是 | Hit 时不调用 |
| 正确性风险 | 极低 | 极低 | 极低 | 较高 |
| GPU Memory 压力 | 高 | 高 | Provider 管理 | 很低 |
| 典型场景 | 所有 LLM 推理 | Shared Prompt | Agent/RAG/Chat | FAQ/客服 |
| 典型实现 | vLLM KV Cache | vLLM APC / SGLang | OpenAI 等 Provider | Redis / LangChain |
从"节省计算"的角度，可以画成：
text
节省计算程度
↑
Semantic Cache │ ███████████████
│
Prompt Cache │ ██████████
Prefix Cache │ ██████████
│
KV Cache │ ███████
│
└──────────────────→但是不能简单说：
text
Semantic Cache > Prompt Cache > KV Cache因为它们解决的问题不同。
更准确地说，它们可以同时存在。
3. LLM Cache 的现状：为什么现在缓存比例甚至可以达到 90%？
目前 LLM Serving 一个非常明显的趋势是：
Prompt 正在变得越来越长，但真正变化的 Token 占比反而越来越小。
这是缓存价值快速提升的根本原因。
3.1 以前的 LLM 请求
早期 ChatGPT 风格请求可能只有：
text
User:
帮我介绍一下 TransformerPrompt：
text
100 Tokens这 100 个 Token 基本都是新的。
缓存空间很小。
3.2 今天的 Agent 请求
今天一个 Agent 请求可能是：
text
System Prompt 3000
Developer Instructions 2000
Tool Definitions 5000
Memory 3000
RAG Documents 5000
Conversation History 10000
Current User Query 500总计：
text
28500 Tokens真正新增的可能只有：
text
500 Tokens假设其中 25000 Token 都能够从 Cache 复用：
text
Cached Token Ratio
=
25000 / 28500
≈ 87.7%再极端一些：
text
Cached = 90000
New = 10000
Cache Ratio
=
90000 / 100000
=
90%这就是很多人所说：
LLM Cache 可以达到 90%
背后的核心原因。
3.3 注意：90% 通常指的不是"90% 的请求完全命中"
这是一个非常重要的区别。
传统 Cache 经常讨论：
text
Request Hit Rate例如：
text
100 个请求
90 个 Redis Hit
Hit Rate = 90%但是 LLM Prompt Cache / Prefix Cache 更应该关注：
text
Cached Token Ratio例如：
text
一个请求：
10000 Input Tokens
9000 Cached Tokens
1000 New Tokens那么：
text
Token Cache Ratio = 90%虽然这个请求依然：
text
调用了 LLM但 90% 的 Prompt Prefill 可以复用。
因此：
text
Request Hit Rate和：
text
Cached Token Ratio不能混为一谈。
这也是理解"90% 缓存命中率"的关键。
3.4 为什么现代 LLM 应用特别容易达到高 Cache Ratio？
主要有几个原因。
第一，System Prompt 越来越长
复杂 Agent 的 System Prompt 已经不再是：
text
You are a helpful assistant.而可能是几千 Token：
text
Role
Behavior Rules
Safety Rules
Output Format
Workflow
Examples
Domain Knowledge这些内容在大量请求之间完全相同。
因此天然适合 Prefix Cache。
第二，Tool Definitions 非常稳定
一个拥有大量 Tools 的 Agent：
text
search()
read_file()
write_file()
send_email()
query_database()
create_calendar_event()
...每一个 Tool 都包含 Schema。
几十甚至上百个 Tool 的定义可能占据：
text
数千到数万 Token而这些 Tool Schema 在不同请求之间基本不变化。
这实际上是非常理想的 Prefix Cache 数据。
第三，Conversation History 大量重叠
假设：
text
Turn 1:
A
Turn 2:
A B
Turn 3:
A B C
Turn 4:
A B C D实际上：
text
Turn N+1几乎完全包含：
text
Turn N所以天然形成：
text
越来越长的 Shared PrefixPrefix Cache 对 Chat 场景尤其有效。
第四，RAG 文档经常重复
很多人会认为：
text
RAG 每次检索出来的 Document 都不同实际上生产环境中经常存在非常明显的 Hot Documents。
例如公司内部 Copilot：
text
Employee Handbook
Pricing
Refund Policy
API Documentation
Security Policy
Product Documentation大量用户会重复命中同一批文档。
因此这些文档对应的 KV 也有很高的复用价值。
第五，Agent 本身就是重复执行相同 Workflow
典型 Agent：
text
User Query
↓
Plan
↓
Tool Call
↓
Observation
↓
Reason
↓
Tool Call
↓
Observation
↓
Final Answer每一步调用模型时：
text
System Prompt
Tools
Previous History都基本不变。
真正新增的通常只是：
text
Tool Result因此 Agent 是目前 Prefix / Prompt Cache 价值最高的场景之一。
3.5 高 Cache Ratio 带来的最大收益是什么？
很多人第一反应是：
text
省 Token Cost但从 Serving 系统来看，更重要的往往是：
text
降低 Prefill ComputeLLM 推理大体分成：
text
Prefill
+
DecodePrefill 负责：
text
处理 Input TokensDecode 负责：
text
逐 Token 生成 Output对于一个：
text
100K Context的请求，如果其中：
text
90K Cached
10K New那么 Prefill 实际只需要重点计算新增部分。
这意味着：
text
更低 TTFT
+
更低 GPU Compute
+
更高吞吐量
+
更低 Serving Cost尤其对于：
text
Long Context
Agent
RAG
Coding非常明显。
3.6 但不是所有业务都能达到 90%
"90% Cache Ratio"不能理解成一个行业统一数字。
如果业务是：
text
完全独立的 Prompt
+
用户之间没有共享上下文
+
每次 RAG 文档不同
+
System Prompt 很短那么 Prefix Cache 的收益可能非常有限。
例如：
text
Request 1:
Write a poem about cats
Request 2:
Analyze PostgreSQL query plans
Request 3:
Translate this French article三次请求没有多少公共 Prefix。
那么 Cache Ratio 自然很低。
所以缓存效果最终取决于：
text
Workload Locality即：
请求之间到底有多少重复内容。
3.7 当前 LLM Serving 的趋势
现在越来越多 Serving Engine 已经把 Prefix Cache 当成基础能力。
例如 vLLM 已经提供 Automatic Prefix Caching，并且底层采用 KV Block 复用。
而行业正在进一步从：
text
Single GPU KV Cache发展到：
text
GPU
↓
CPU DRAM
↓
Remote Memory
↓
SSD
↓
Distributed KV Cache即所谓：
text
KV Cache Tiering或者：
text
Disaggregated KV Cache原因很简单：
如果：
text
KV Cache 只存在某块 GPU那么请求调度到另外一块 GPU：
text
Cache Miss如果 KV Cache 可以跨节点共享：
text
GPU 1 ─┐
GPU 2 ─┼── Distributed KV Cache
GPU 3 ─┘整个集群的 Cache Hit Ratio 就可以进一步提升。
vLLM 生态目前也已经在探索利用 GPU、DRAM、SSD 和远程 KV Cache Backend 扩展可缓存容量，以提高 Prefix Cache 的有效命中率。
因此未来 LLM Serving 的核心能力之一很可能会从：
text
How fast can I compute KV?逐渐变成：
text
How much KV can I reuse?4. 总结：如何更好地利用 LLM Cache？
真正做好 LLM Cache，不能只是：
text
enable_cache = true而是应该从 Prompt、Serving、Application 三个层面共同设计。
4.1 第一原则：稳定内容放前面，动态内容放后面
推荐：
text
Stable
─────────────────────
System Prompt
Tool Definitions
Few-shot Examples
Shared Knowledge
─────────────────────
Conversation History
Current Context
Current User Query
─────────────────────
Dynamic也就是：
text
Stable → Dynamic而不是反过来。
因为 Prefix Cache 本质上是：
text
Longest Common Prefix前面越稳定：
text
Cached Prefix越长。
4.2 第二原则：减少无意义的 Prompt 变化
下面两个 Prompt 对人来说基本一样：
text
Today is 2026-10-01.
You are a helpful assistant.
text
Today is 2026-10-02.
You are a helpful assistant.但是如果日期放在最前面：
text
Token 1 就不同可能导致整个后续 Prefix 无法复用。
更好的方式是：
text
You are a helpful assistant.
...
...
Current date: 2026-10-02也就是说：
高频变化字段尽量后移。
类似的字段包括：
text
Timestamp
Request ID
Trace ID
Random ID
User-specific Metadata
Current Query4.3 第三原则：让 Prompt Canonicalize
例如：
text
Temperature: 0.7
temperature:0.7
temperature = 0.7语义相同，但 Token 不一定相同。
对于 Prefix Cache：
text
Token 不同 = Cache Miss所以 Prompt 模板应该尽量：
text
Deterministic包括：
text
JSON Key 顺序固定
Whitespace 固定
Tool 顺序固定
Document 顺序稳定
Template Version 固定这样可以显著提升 Cache Hit。
4.4 第四原则：做好 Cache-Aware Routing
假设：
text
GPU A:
已经缓存 Prompt X
GPU B:
没有 Prompt X此时新请求：
text
Prompt X如果 Load Balancer 只考虑：
text
GPU utilization可能把它分配给：
text
GPU B导致 Cache Miss。
更加智能的 Scheduler 应该综合：
text
GPU Load
+
KV Cache Locality
+
Prefix Similarity也就是：
text
Cache-Aware Routing未来 Serving Scheduler 的优化方向，不再只是：
text
Load Balance而会越来越倾向：
text
Load Balance
+
Cache Affinity4.5 第五原则：建立多级 KV Cache
理想架构：
text
┌──────────────┐
│ GPU HBM │
│ Hot KV │
└──────┬───────┘
│
┌──────▼───────┐
│ CPU DRAM │
│ Warm KV │
└──────┬───────┘
│
┌──────▼───────┐
│ Remote Cache │
│ Distributed │
└──────┬───────┘
│
┌──────▼───────┐
│ SSD │
│ Cold KV │
└──────────────┘目标类似 CPU Cache：
text
L1
L2
L3
Memory
Disk只不过这里缓存的是：
text
LLM KV State而不是普通内存数据。
4.6 第六原则：Semantic Cache 一定要谨慎
Semantic Cache 应优先用于：
text
FAQ
Customer Support
Documentation Q&A
Stable Knowledge而不适合直接用于：
text
金融价格
新闻
实时库存
个人数据
权限相关回答
高风险决策
强上下文问题必须至少考虑：
text
Query Embedding
+
Similarity Threshold
+
Tenant
+
User Scope
+
Knowledge Version
+
Prompt Version
+
Model Version
+
TTL否则很容易出现：
text
Cache Hit但返回的是：
text
Wrong Answer这是 Semantic Cache 与 Prefix Cache 最大的区别：
text
Prefix Cache Hit
→ 计算结果仍然等价
Semantic Cache Hit
→ 业务上"认为"两个问题可以共享答案后者天然存在判断风险。
4.7 最理想的 LLM Cache 架构
最终，一个成熟 LLM 系统往往不是选择一种 Cache，而是多层同时使用：
text
User Query
│
▼
┌────────────────┐
│ Semantic Cache │
└───────┬────────┘
│ Miss
▼
┌────────────────┐
│ Prompt Cache │
└───────┬────────┘
│
▼
┌────────────────┐
│ Prefix Cache │
│ KV Blocks │
└───────┬────────┘
│
▼
LLM Prefill
│
▼
KV Cache
│
▼
Decode
│
▼
Response对应的优化目标分别是：
text
Semantic Cache
↓
减少 LLM Call
Prompt / Prefix Cache
↓
减少 Prefill
KV Cache
↓
减少 Decode 重复计算所以 LLM Serving 的性能优化可以归纳成一句话：
不要让模型重复做已经做过的计算。
进一步来看，未来 LLM Serving 的竞争很可能不只是：
text
GPU FLOPS
Model Quantization
Batching
Kernel Optimization还会越来越依赖：
text
KV Cache Management
Prefix Reuse
Cache-Aware Scheduling
Distributed KV Cache
Semantic Reuse尤其进入 Agent 和 Long Context 时代之后：
text
100K Prompt中真正新增的可能只有：
text
1K～10K Token其余绝大部分都是：
text
System Prompt
Tools
Memory
History
Documents
Previous Agent State这也是为什么在合适的 Agent、Chat、RAG 工作负载中，Cached Token Ratio 达到 80%～90% 甚至更高并不奇怪。
但应该始终记住：
所谓"90% Cache"更多指 Token 级的可复用比例，而不是说 90% 的用户请求都可以直接返回缓存答案。
这是理解现代 LLM Cache 最关键的一点。