什么是 GPTCache？
- 标签：AI、大模型
🏛 业务架构师
GPTCache 是给 LLM 应用加的"语义缓存"层：把历史问题和答案向量化存起来，新请求先做语义相似度匹配，命中就直接返回缓存答案，不再调用大模型。
业务价值非常直接：
- 降本：高频客服场景中，大量提问高度重复（"怎么退款"每天被问几千次），缓存命中率到 40% 以上就能砍掉近半 API 开销——在 AI 预算审批越来越严的 2026 年，这是 CFO 最爱听的优化。
- 提速：缓存命中毫秒级返回，绕过模型 1~3 秒的生成延迟，体验跃升。
- 削峰：流量高峰期（大促、舆情）保护模型服务不被打爆。
但我要泼三盆冷水：一是语义缓存有"误命中"风险——问题相似不等于答案可复用，"怎么退款"和"退款被拒了怎么办"相似度高但答案完全不同，阈值要保守；二是时效性场景（股价、库存）绝不能缓存；三是答案里带个性化信息（用户名、订单号）的要剔除或分段缓存。
我的建议：先把业务问题按"重复度×时效性"分类，只对高重复、低时效的问题开缓存，用数据证明命中率再扩大范围。
🏗 系统架构师
GPTCache 是给 LLM 应用做"语义缓存"的中间件：把 query 嵌入成向量，在缓存库中找语义相似的历史 query，命中则直接返回缓存答案，跳过 LLM 调用。
它解决的三重成本：LLM API 调用费（省 30%~60% 常见）、首 token 延迟（从秒级降到 50ms 级）、上游 QPS 压力（缓存挡掉读流量，这和 CDN/Redis 挡数据库压力是同一个架构模式——存储层次结构下移）。
架构关键点（也是坑点）：
- 相似度阈值是核心参数：太松，"退款政策"和"退货政策"命中同一缓存返回错答案；太紧命中率崩塌。我会按场景调（客服 FAQ 可以松，代码生成必须严甚至不用）；
- 缓存失效：模型版本、System Prompt、检索知识库更新都要让相关缓存失效——缓存 key 要包含这些指纹，否则更新后吐旧答案；
- 分层淘汰：前置精确缓存（query hash），语义缓存做二级，LLM 兜底。
我的判断：2026 年 Prompt Cache（服务端前缀缓存）已经解决了"相同上下文重复计费"问题，GPTCache 的价值收缩到"相似 query 去重"场景——高重复度客服、热门 FAQ 最有效；生成类、低重复场景收益有限且有正确性风险，需要用"缓存命中率 × 答案错误代价"评估后再上。
💻 全栈开发专家
GPTCache 是给 LLM 应用加的语义缓存：把历史 query 的 embedding 和答案存下来，新请求来了先算向量相似度，超过阈值（如 0.95）直接返回缓存答案，不打模型。价值就是两个字：省钱和降延迟——FAQ 型应用命中率能到 30%+，成本直降，P99 从秒级到毫秒级。
核心流程：
query → embedding → ANN 检索相似历史 query
→ 相似度 ≥ 阈值 ? 返回缓存答案 : 调 LLM 并写缓存我落地时的几个关键决策：
- 阈值宁高勿低：0.92 以下就开始出现「答非所问」的缓存错配，错配比慢更伤体验，我们最终定 0.95 并按意图分类先分流，同意图内才匹配；
- 失效策略：知识库更新、prompt 版本升级必须使缓存失效，缓存的 key 里要带 prompt 版本号和知识库版本号，这是最容易踩的血坑；
- 不该缓存的别缓存：带用户私有上下文（「我的订单」）、实时数据（「今天股价」）的请求直接旁路；
- 存储用 Redis（向量用 RediSearch），别为缓存单独再养一套向量库。