提示词缓存与复用：省一半 token 的实战方案
谭谭老师167 阅读
大模型 API 按 token 收费，而 RAG 的每次请求都要带上 system prompt、检索上下文、对话历史——其中大量内容每次都是重复的。如果能缓存，成本能省下一大截。这篇文章讲我的省钱方案。
第一层：system prompt 缓存。如果你用 OpenAI 等支持 prompt caching 的 API，system prompt 和固定的工具定义会自动命中缓存，费用打折。这个零成本，只要把静态内容放 system 里，别混进动态内容。
第二层：对话前缀缓存。长对话里，前面几轮的内容是不变的，每次只追加新轮次。支持缓存的话，重复前缀不重复计费。实现上要保证消息结构稳定，别在中间插东西。
第三层：语义缓存（最有用）。用户问的问题经常重复："怎么退款"、"退款流程"——意思一样。对用户查询做 embedding，如果和最近某个查询的相似度 > 0.92，直接返回上次的答案，不调模型。
Python
# 查询缓存实现
cache_hit = vector_db.search(query_embedding, threshold=0.92)
if cache_hit:
return cache_hit.answer # 直接返回，0 成本
# miss：正常调 LLM，然后把 (query, answer) 存进缓存
实测效果：加上语义缓存后，API 成本降了约 40%，因为用户真实问题里重复率不低（特别是客服场景）。响应速度也快了——缓存命中的回答是毫秒级，不用等模型生成。
坑：
-
缓存命中率别贪。阈值设太低（0.8）会把"相似但不同"的问题也命中，给错答案。0.92 是我调出来比较稳的值，宁可 miss 也不给错。
-
缓存要有过期和淘汰。业务规则变了，缓存里的旧答案就不能再用了。我按时间过期（如 24 小时）+ 容量上限淘汰。
-
缓存命中要能感知。用户问相同问题应该能看到不同答案（如果业务更新了）。缓存答案上带个"回答时间"，让用户知道这不是实时生成的。
-
敏感数据不入缓存。涉及隐私或时效性强的查询，强制走实时。
最后：成本优化别只盯着模型选型，缓存是投入产出比最高的手段之一。
评论0
还没有评论，来抢沙发～