大模型 Cache 科普：原理、作用和如何提高命中率

2026-03-05

什么是大模型的 Cache？

简单说：Cache 就是”记住算过的东西，下次不用重新算”。

当你给 AI（比如 ChatGPT、Claude）发消息时，AI 需要先”读懂”你发的所有文字，这个过程很耗计算资源。如果你下次发的消息前半段和上次一样，AI 可以直接用上次算好的结果，只处理新增的部分。

这就是 Cache——把计算结果存起来复用。

用一个生活比喻

想象你去一家餐厅，每次点餐都要把菜单从头看到尾：

没有 Cache：每次去都重新看完 200 页菜单，再告诉服务员你要什么

有 Cache：服务员记住了你上次看到第 180 页的进度，这次你只需要从第 180 页看起

AI 处理文字就像”看菜单”，Cache 就是”记住看到哪里了”。

Cache 的两种类型

1. Prompt Cache（提示词缓存）

最常见，也是最重要的。

当你每次调用 AI 时，发送的内容通常分两部分：

[系统提示词 - 固定不变] + [用户的具体问题 - 每次不同]

比如：

系统提示词（固定）：”你是一个客服助手，以下是我们的产品手册……（5000字）”

用户问题（变化）：”退货流程是什么？”

没有 Cache 时：每次用户提问，AI 都要重新处理那 5000 字的产品手册。

有 Cache 时：第一次处理完产品手册后，结果被缓存。后续用户提问时，AI 直接复用缓存，只处理新的问题。

效果：

⚡ 速度快 2-3 倍（跳过了重复处理）

💰 费用降低 50-90%（缓存命中的部分按折扣计费）

2. KV Cache（键值缓存）

这是 AI 内部的技术细节，非技术人员只需要知道：

KV Cache 是 AI “思考”过程中的临时记忆。它让 AI 在生成回答时不用每个字都从头想，而是基于之前想好的中间结果继续。

这个对用户是透明的，AI 框架自动处理。

Cache 命中率是什么？

Cache 命中率 = 复用了缓存的比例。

命中率 80% → 80% 的内容不用重新计算，只有 20% 是新的

命中率 0% → 完全没用上缓存，所有内容都重新计算了

命中率越高，速度越快、费用越低。

如何提高 Cache 命中率？

✅ 方法 1：保持提示词前缀一致

最重要的一条规则：Cache 从头开始匹配，遇到第一个不同的地方就停止。

好的例子 ✅
请求1: [系统提示A] + [问题1]
请求2: [系统提示A] + [问题2] ← 系统提示A 完全一样，命中缓存！

坏的例子 ❌
请求1: [系统提示A] + [问题1]
请求2: [系统提示B] + [问题2] ← 开头就不同，完全不命中

关键：不要在提示词开头放变化的内容（比如时间戳、随机 ID）。把变化的内容放在最后。

✅ 方法 2：固定内容放前面，变化内容放后面

推荐的消息结构：
┌─────────────────────────┐
│ 系统提示词（固定） │ ← 会被缓存
│ 参考文档/知识库（固定） │ ← 会被缓存
│ 对话历史（逐渐增长） │ ← 部分缓存
│ 用户当前问题（每次不同） │ ← 不缓存，但很短
└─────────────────────────┘

✅ 方法 3：提示词长度要够（不同厂商有最低门槛）

各厂商对缓存有最小长度要求：

厂商

最低缓存长度

备注

Anthropic (Claude)

1024 tokens (~800字)

自动缓存，无需手动开启

OpenAI (GPT)

1024 tokens

自动缓存

Google (Gemini)

32,768 tokens

需要手动标记缓存区域

如果你的提示词太短（比如只有一句话），就达不到缓存门槛，不会生效。

✅ 方法 4：减少不必要的提示词变动

每次修改提示词模板都会让缓存失效。如果提示词稳定不变，缓存就能一直复用。

✅ 方法 5：使用对话历史

多轮对话天然适合缓存——每一轮新消息只在末尾追加，前面的历史消息保持不变，所以历史部分都能命中缓存。

费用影响

以 Anthropic Claude 为例：

场景

输入价格

说明

无缓存

$3 / 百万 token

完整价格

缓存命中

$0.3 / 百万 token

便宜 90%

首次写入缓存

$3.75 / 百万 token

第一次贵 25%，但后续都便宜

举例：你有一个 5000 token 的系统提示词，每天调用 1000 次。

无缓存：5000 × 1000 × \(3/M = **\)15/天**

有缓存（假设 95% 命中）：首次 \(0.02 + 命中 \)1.43 = $1.45/天，节省 90%

常见误区

❌ “Cache 需要手动开启”

大多数厂商（Anthropic、OpenAI）的 Prompt Cache 是自动的，不需要任何代码修改。只要你的请求前缀相同，就会自动命中。

❌ “Cache 会让回答变得一样”

不会。Cache 只是跳过了”理解你的提示词”的步骤，AI 仍然会根据你的具体问题生成不同的回答。就像服务员记住了菜单不代表每次给你上一样的菜。

❌ “Cache 会泄露其他用户的数据”

不会。Cache 是按请求内容精确匹配的，而且同一账号内隔离。不同用户的缓存互不影响。

❌ “用了 Cache 回答质量会下降”

完全不会。Cache 复用的是中间计算结果，和从头计算是完全等价的，输出质量没有任何区别。

总结

项目

说明

Cache 是什么

记住算过的东西，下次不重新算

核心好处

更快、更便宜

最重要的优化

保持提示词前缀不变

费用节省

最高可达 90%

需要开发吗

大多数情况不需要，自动生效

一句话：让你发给 AI 的内容尽量”前面不变、后面变”，缓存就能自动帮你省钱加速。

补充：LiteLLM 代理的缓存层

如果你用 LiteLLM 做 API 代理（统一管理多家大模型），它有两层完全不同的缓存：

第一层：Provider Prompt Cache（透传，自动生效）

这就是前面讲的 Prompt Cache，由 OpenAI/Anthropic/Deepseek 等厂商自己实现。LiteLLM 只是透传，不需要额外配置。

各厂商支持情况：

Provider

触发条件

特殊参数

OpenAI

1024+ tokens，自动

prompt_cache_key（路由提示，提高命中率）、prompt_cache_retention="24h"（延长缓存）

Anthropic

1024+ tokens

需要在 message 中标记 cache_control: {type: "ephemeral"}（Anthropic 对写入缓存额外收费）

Deepseek

自动

同 OpenAI 方式

Bedrock

看具体模型

部分模型支持

LiteLLM 会统一返回缓存命中信息：

{
"usage": {
"prompt_tokens": 2006,
"prompt_tokens_details": {
"cached_tokens": 1920
}
}
}

cached_tokens 就是命中缓存的 token 数。

特点：每次回答仍然不同，只是省了”理解提示词”的计算。

第二层：LiteLLM 应用层缓存（需要主动开启）

这是 LiteLLM 自己实现的缓存，完全相同的请求直接返回之前的结果，不再调用 API。

支持多种后端：

后端

适合场景

In-Memory

单机、测试用

Redis

生产环境，多实例共享

Redis Semantic

语义相似的问题也能命中（用 embedding 匹配）

S3 / GCS

持久化存储，适合离线分析

Disk

本地持久化

控制参数：

no-cache：强制调 API，不用缓存

no-store：不把结果写入缓存

ttl：缓存有效期（秒）

s-maxage：只接受多少秒内的缓存

⚠️ 注意：这层缓存会返回完全一样的回答。适合确定性查询（比如”1+1等于几”），不适合需要多样性回答的场景。

两层缓存对比

Provider Prompt Cache

LiteLLM 应用层缓存

谁实现的

OpenAI/Anthropic 等厂商

LiteLLM 自己

是否调 API

调（但更快更便宜）

不调（直接返回旧结果）

回答是否相同

不同（重新生成）

相同（完全复用）

是否自动

大多数厂商自动

需要主动配置

省钱幅度

50-90%（缓存 token 打折）

100%（不产生 API 费用）

风险

无

可能返回过时/不合适的回答

实际建议

Provider Prompt Cache 不用管，自动生效，做好”前面不变后面变”就行

LiteLLM 应用层缓存按需开启——高频重复查询可以省很多钱，但要注意回答可能过时

Redis Semantic Cache 是个有趣的折中：语义相似的问题也能命中，但精确度不如精确匹配