提示缓存与语义缓存经济学

提示缓存与语义缓存经济学

定价快照日期:2026-04。 下文数字反映本节发布时抓取的厂商费率卡;下游引用前请对照链接文档再核一遍。

缓存发生在两层。L2(厂商级)提示/前缀缓存复用重复前缀的注意力 KV——Anthropic 的提示缓存文档宣称长提示上最高 90% 成本降低、85% 延迟降低;对 Claude 3.5 Sonnet,缓存读 0.30 美元/百万 vs 全新 3.00 美元/百万,5 分钟 TTL,1 小时 TTL 选项写溢价 2 倍(docs.anthropic.com,2026-04)。OpenAI 的提示缓存对 ≥1024 token 的提示自动启用,缓存输入相对全新约打 9 折(platform.openai.com,2026-04);具体每模型缓存费率依实时费率卡。L1(应用级)语义缓存在 embedding 相似命中时彻底跳过 LLM。厂商的「95% 准确率」指的是匹配正确度,不是命中率——社区报告的生产命中率从 10%(开放聊天)到 70%(结构化 FAQ)不等;两家厂商都未发布官方基线,故视作社区遥测而非保证。生产陷阱:并行化会杀死缓存(N 个并行请求在首次缓存写入前发出,可让花费膨胀数倍),前缀内的动态内容会彻底阻止命中。ProjectDiscovery 报告(2025-11)把动态文本移出可缓存前缀后,命中率从 7% 升到 74%。

对应原课程:Phase 17 · Lesson 14 · 14-prompt-semantic-caching(原英文 phases/17-infrastructure-and-production/14-prompt-semantic-caching/docs/en.md)。

学习目标

阅读完本节,你应当能够:

1. 区分 L2 提示/前缀缓存(厂商处 KV 复用)与 L1 语义缓存(相似提示绕过 LLM)。
2. 解释 Anthropic 的 cache_control 显式标记与两种 TTL 选项(5 分钟 vs 1 小时)及其价格乘数。
3. 给定命中率、提示/响应构成、token 价格,算出预期月度节省。
4. 点名让账单膨胀 5~10 倍的并行化反模式,以及让命中率坍塌的动态内容反模式。

一、问题与直觉

你给 RAG 服务加了提示缓存。账单没动。你量命中率——7%。你的提示看着静态,其实不是:系统提示里有精确到分钟的当前日期、一个请求 ID、为多样性做的随机示例重排。每个请求写一个新缓存项,读零。

与此同时,你的 Agent 每个用户问题跑十个并行工具调用。十个都在首次缓存写入完成前到达厂商。十次写、零次读。你的账单是「开了缓存」本该花费的 5~10 倍。

缓存是一套协议,不是一个 flag。两层,两种失败模式。

二、核心概念

L2 —— 厂商提示/前缀缓存

厂商存可缓存前缀的注意力 KV,在下个匹配前缀的请求上复用。你付一次写成本,读近乎免费。

Anthropic(Claude 3.5 / 3.7 / 4 系列):请求里的显式 cache_control 标记,你标哪些 block 可缓存。TTL:5 分钟(写成本 1.25× 基价)或 1 小时(写成本 2× 基价)。缓存读:Claude 3.5 Sonnet 上 0.30 美元/百万 vs 全新 3.00 美元/百万——便宜 10 倍(docs.anthropic.com,2026-04)。各模型费率不同(Opus/Haiku 另发),永远对照实时定价页。

OpenAI:对 ≥1024 token 提示自动缓存(platform.openai.com,2026-04),无显式 flag。当前 gpt-4o/gpt-5 费率卡上缓存输入比全新便宜约 10 倍。文档与发布说明都不发官方命中率基线;社区报告在精心提示设计下聚在 30%~60%。监控 usage.cached_tokens 量你自己的。

Google(Gemini):经显式 API 做上下文缓存;100 万 token 上下文让缓存更划算。

自托管(vLLM、SGLang):第 06 节讲 RadixAttention——在你自己的算力上同模式。

L1 —— 应用级语义缓存

在调 LLM 之前,哈希提示、embed 它、找一个相似缓存请求(余弦相似度高于阈值,通常 0.95+)。命中返回缓存响应,未命中调 LLM 并缓存结果。

开源:Redis 向量相似度、GPTCache、Qdrant。商业:Portkey Cache、Helicone Cache。

厂商的准确率宣称指「返回的缓存响应有多少比例语义恰当」——不是你多常命中。生产命中率:

• 开放聊天:10%~15%。
• 结构化 FAQ / 客服:40%~70%。
• 代码问题:20%~30%(小变体杀命中)。
• 语音 Agent 重复提示:50%~80%(语音归一化的固定集合)。

并行化反模式

你的 Agent 并行发 10 个工具调用,都有同一个 4K token 系统提示。Anthropic 缓存写按请求;首次缓存写在厂商看到提示后约 300 ms 完成。请求 2~10 在同一毫秒窗口到达,各自看到缓存未命中。你付 10 次写溢价、0 次读折扣。

修复:串行优先批处理——先单独发请求 1,等 1 的缓存填好再发 210。给首个工具调用加 300 ms,省 510 倍账单。

动态内容反模式

你的系统提示长这样:

You are a helpful assistant. The current time is 14:32:17.
User ID: abc123. Today is Tuesday...
​

每个请求都唯一,每个请求都写,零命中。

修复:把真正静态的东西移进可缓存前缀,动态内容放在缓存边界之后:

[cacheable]
You are a helpful assistant. [rules, examples, instructions]
[/cacheable]
[dynamic, not cached]
Current time: 14:32:17. User: abc123.
​

ProjectDiscovery 这样把命中率从 7% 提到 74%,并公开了解剖。

给夜间工作负载叠加 batch + cache

批处理 API(第 15 节)给 24 小时周转 50% 折扣,缓存输入再叠约 10 倍。夜间分类、标注、报告生成工作负载可降到同步未缓存成本的约 10%。

你该记住的数字

定价点 2026-04 抓取自链接厂商文档,每几个月漂移——依赖前再核。

• Anthropic 缓存读:Claude 3.5 Sonnet 上 0.30 美元/百万,比全新输入便宜约 10 倍。
• Anthropic 缓存写溢价:1.25×(5 分钟 TTL)或 2×(1 小时 TTL)。
• OpenAI 自动缓存:适用于 ≥1024 token 提示;缓存输入定价约为全新输入的 10%。
• 语义缓存命中率(社区报告):开放聊天约 10%;结构化 FAQ 高至约 70%。非厂商文档基线。
• ProjectDiscovery:把动态移出前缀,命中率 7% → 74%(2025-11 博客)。
• 并行化反模式:N 个并行请求错过首次缓存写时,典型账单膨胀 5~10 倍。

三、从零实现:双层缓存模拟器

原课程 code/main.py 在混合工作负载上模拟 L1 + L2 缓存,报告命中率、账单,并展示并行化惩罚。下面给最小可读的成本估算骨架。

def monthly_cost(requests_per_day, input_tokens, output_tokens,
                 fresh_input_per_m, fresh_output_per_m,
                 cached_input_per_m, hit_rate, cache_write_premium=1.25):
    """估算 L2 提示缓存的月度成本。

    假设:每个请求的 input_tokens 中,系统提示等可缓存部分占 cacheable_share。
    """
    cacheable_share = 0.8  # 假设 80% 输入是可缓存前缀
    monthly = requests_per_day * 30
    # 未命中:全价写(带写溢价),命中:缓存读价
    miss = monthly * (1 - hit_rate)
    hit = monthly * hit_rate
    # 写:可缓存部分 × 写溢价 × 全价;不可缓存部分永远全价
    write_cost = miss * (input_tokens * cacheable_share * cache_write_premium * fresh_input_per_m / 1e6
                         + input_tokens * (1 - cacheable_share) * fresh_input_per_m / 1e6)
    # 读命中:可缓存部分 × 缓存价 + 不可缓存全价
    read_cost = hit * (input_tokens * cacheable_share * cached_input_per_m / 1e6
                       + input_tokens * (1 - cacheable_share) * fresh_input_per_m / 1e6)
    output_cost = monthly * output_tokens * fresh_output_per_m / 1e6
    return round(write_cost + read_cost + output_cost, 2)


# 案例:Claude 3.5 Sonnet,4000 输入 / 200 输出,10000 请求/天
base = monthly_cost(10000, 4000, 200, 3.0, 15.0, 3.0, hit_rate=0.0)   # 不开缓存
hit7 = monthly_cost(10000, 4000, 200, 3.0, 15.0, 0.30, hit_rate=0.07) # 7% 命中(动态前缀)
hit74 = monthly_cost(10000, 4000, 200, 3.0, 15.0, 0.30, hit_rate=0.74)# 74% 命中(修复后)
print(f"未缓存 ${base}/月 → 7% 命中 ${hit7}/月 → 74% 命中 ${hit74}/月")
​

💡 「我开了缓存但账单没降」几乎总是两个原因之一:前缀里有动态内容(命中率低),或并行请求错过首次写(写溢价 ×N)。先量命中率,再看并行模式。

四、框架对比:L2 厂商缓存 vs L1 应用语义缓存

心法:L2 是「便宜地重算」,L1 是「根本不算」。先榨干 L2(修前缀纪律),再考虑 L1(高频重复负载)。两者可叠加,但 L1 的阈值要按准确率回归调。

五、可复用产物

本节产出 outputs/skill-cache-auditor.md(原课程目录)。给定提示模板与流量,它审计可缓存性并推荐重构:

1. L2 命中率诊断:前缀里哪些是动态内容,该如何后置。
2. 并行化审计:是否有 N 个并行请求错过首次写。
3. TTL 选择:5 分钟 vs 1 小时的盈亏平衡(依请求到达率)。
4. L1 阈值建议:按负载类型给语义相似度门槛与回归集。

六、练习

1. 跑通模拟器:运行 code/main.py。切换并行化 flag,账单变多少?

2. 动态移出:你的系统提示里有日期。把它移出,展示前后命中率的算术。

3. TTL 盈亏:给定你的请求到达率,算 1 小时 TTL(2× 写)vs 5 分钟 TTL(1.25× 写)的盈亏平衡。

4. 语义阈值:0.95 阈值命中 20%,0.85 命中 50% 但出现错误缓存响应。选对的阈值并论证。

5. 并行改写:你每个用户问题批 10 个并行子查询。在不加端到端延迟的前提下改成缓存友好。

本节要点回顾

1. 两层缓存:L2 厂商级(复用前缀 KV)、L1 应用级(embedding 相似绕过 LLM)。
2. Anthropic 是显式 cache_control:5 分钟 TTL 写溢价 1.25×,1 小时 2×;缓存读比全新便宜约 10 倍。
3. OpenAI 是自动缓存:≥1024 token 自动启用,缓存输入约为全新的 10%。
4. 语义缓存命中率因负载而异:开放聊天 10%~15%,结构化 FAQ 40%~70%,代码 20%~30%。
5. 并行化反模式:N 个并行请求错过首次写,账单膨胀 5~10 倍——串行优先批处理修复。
6. 动态内容反模式:前缀里的时间/ID/随机示例杀命中率,后置可缓存边界。
7. ProjectDiscovery 案例:动态移出前缀,命中率 7% → 74%。
8. batch + cache 叠加:夜间工作负载可降到同步未缓存的约 10%。
9. 命中率要量不要猜:监控 usage.cached_tokens,先修前缀纪律再调 L1 阈值。

下一节,我们把缓存叠加到另一个省钱杠杆上——批处理 API:看 50% 折扣如何成为行业标准,以及哪些工作负载在默默浪费 90% 的账单。