缓存 LLM 响应：何时与如何

按软件的标准看，对语言模型的调用又慢又贵。它们耗费可观的时间，每个请求都要花钱。缓存——复用一个已存的结果，而不是再发一次调用——是你能同时撬动这两者最直接的杠杆。但 LLM 让缓存复杂化的方式是普通网页缓存所没有的，因为同一个问题可以有上千种问法，而模型对同一个提示词每次给出的答案可能都不一样。本文讲清缓存何时有帮助、有哪些种类，以及如何运用它们而不至于悄悄端出陈旧或错误的答案。

为什么缓存值得这番折腾

支持缓存的理由立足于三项好处，而它们会随你规模化而复利累加。

• 成本。 每一次缓存命中，都是一次你没有付钱的模型调用。在大用量、重复性的工作负载下，这就是一个可行的产品与一个昂贵的产品之间的分别。
• 延迟。 返回一个已存答案，比生成一个新答案要快得多。对于交互式产品，这份速度被用户直接感受到。
• 稳定性。 一个缓存的答案每次都一模一样。对于一致性比新意更要紧的工作流，那种确定性是一种特性，而非局限。

这些好处的大小，完全取决于你的工作负载有多重复。一个用户反复问相似问题的应用，缓存潜力巨大。一个每个请求都独一无二的应用，几乎没有缓存潜力。先弄清你属于哪一种，是第一个决策。

精确匹配缓存：简单、安全的起点

最直截了当的做法，是用精确的请求作为缓存的键。如果一模一样的提示词，连同一模一样的模型和参数，再次进来，就返回已存的响应，而不去调用模型。

这种做法安全、也易于推理，因为匹配是字面上的——不存在两个请求是否"足够接近"的判断。它在真正重复的请求上大放异彩：一个固定的系统提示词处理同一份文档、一个被原封不动问起的热门问题，或者重新跑相同输入的自动化任务。它的局限同样清晰：自然语言变化多端，"你们的退款政策是什么？"和"我怎么申请退款？"是两个不同的字符串，尽管想要的是同一个答案，却都会在精确匹配缓存上落空。精确匹配缓存恰恰是正确的起点，因为它绝不会把错误的答案端给错误的问题——它只是更经常地落空而已。

语义缓存：强大且更冒险

语义缓存通过按含义而非精确文本来匹配，解决了变化多端的问题。它嵌入进来的请求，去寻找一个嵌入与之足够接近的已存请求，若有一个相近，就返回那个缓存的答案。

这会大幅提高自然语言工作负载的命中率，因为改述如今也能匹配上了。它也引入了一个真实的风险："足够接近"是一种判断，而一个设得太松的相似度阈值，会把答案端给一个相似但不同的问题。"我怎么取消订阅？"和"我怎么更改订阅？"这两条查询在语义上相近、在实质上不同——而一个松散的缓存会乐呵呵地返回错误的那个。语义缓存很强大，但它用精确匹配那种字面上的安全，换来了覆盖面。在"看似合理却错误"的答案尚可容忍之处使用它，把阈值调得保守些，并盯住它端出了什么。

提示词前缀缓存：供应商层面的一记胜招

还有一种不同的缓存，运作在模型供应商内部，而非在它前面。许多供应商让你缓存对一段长而稳定的前缀的处理——一个庞大的系统提示词、一组固定的指令，或一大块在许多请求间复用的上下文——这样重复的工作就不必在每次调用时重做。

当你反复发送同样的大块上下文、而只有末尾一小部分在变化时，这尤其有价值，这在检索和智能体工作流里很常见。好处是共享部分的成本和延迟降低了，而那条变化的尾巴仍被新鲜处理，所以最终答案不会陈旧。由于其机制和约束因供应商而异，要确认前缀缓存如何构成、又需要什么，Anthropic 和 OpenAI 的文档是该去看的地方。关键点在于，这缓存的是对一段稳定前缀的计算，而非最终答案——所以它能与上面的响应缓存良好地组合，而非与之竞争。

你能安全缓存什么、不能缓存什么

缓存的安全性取决于请求是为了什么，而这个区分值得明确指出来。

• 稳定、事实性、参考型的答案适合缓存。如果正确答案在两个一模一样的请求之间不会变，那复用它既安全又有益。
• 个性化或依赖上下文的答案草率缓存起来很危险。为一个用户的数据算出来的答案，绝不能端给另一个用户。任何个性化内容的缓存键，都必须包含相关的身份或上下文，否则你就有酿成严重数据泄露 bug 的风险。
• 时效性的答案会变陈旧。任何依赖当前状态的东西都有保质期，而缓存必须通过过期机制来尊重它。
• 刻意求变或有创造性的输出可能根本不该缓存。如果用户期待每次都有新的演绎，那一个缓存的重复就破坏了这个意义。

贯穿始终的规则是：一个缓存键必须捕捉一切本该改变答案的东西。忘了把用户、上下文或参数包含进去，你就造出了一个把某人的答案端给别人的 bug。

让缓存保持新鲜

一个永不过期的缓存会变成错误答案的源头。有两种机制让它保持诚实。第一，基于时间的过期：设一个与底层信息变化速度相称的生命周期，对易变的内容短些，对稳定的参考材料长些。第二，变更时失效：当某个缓存答案背后的源数据被更新时，那条缓存条目必须被清除，好让下一个请求重新生成它。典型的失败是更新了你的知识库，却继续端出基于旧版本构建的答案。为每个缓存有意地决定你的新鲜度策略，而不要让"永远"成为意外的默认。

一个务实的采用顺序

按风险递增的顺序铺开缓存。从精确匹配缓存开始，它绝不会把错误的答案端给错误的问题，并立刻捕获真正重复的请求。在你复用大块稳定上下文之处加上供应商前缀缓存，因为它是一记低风险的成本与延迟胜招。只在你理解了自己的流量、并能调校和监控一个相似度阈值之后，才去动用语义缓存，因为它是那个唯一可能信心十足地端出错误答案的做法。在每一层，都构建包含一切影响答案之因素的缓存键，并在你交付之前——而不是在一个陈旧答案让你难堪之后——设好新鲜度策略。

总结

缓存是撬动 LLM 成本与延迟最直接的杠杆，但语言模型让它比普通缓存更棘手，因为措辞多变，答案又可能是个性化或时效性的。从精确匹配缓存起步，看重它字面上的安全；为复用的上下文叠加供应商前缀缓存；并在"看似合理却错误"的答案尚可容忍之处谨慎采用语义缓存。最重要的是，让每个缓存键都捕捉本该改变答案的东西，并给每条条目一个新鲜度策略。带着这份纪律去做，缓存是一记巨大而安全的胜招；草率地做，它就是一台悄悄把错误答案飞快端出去的机器。