7 篇博文 含有标签「caching」

语义缓存命中是唯一一种能在不到一毫秒的时间内，将错误答案发送给错误用户的 LLM 优化方式。SQL 缓存之所以会返回你或他人的数据行，是因为有人写错了 join —— 这种故障模式属于查询 bug。而语义缓存返回另一个租户的响应，是因为两个 embedding 在 0.03 的余弦距离内落到了一起，这正是系统完全按设计运行的结果。缓存完成了它的工作，问题在于这份工作本身。

大多数团队将语义缓存作为一种成本方案来推行 —— 每个 AI 工程 Slack 频道里都流传着一份“削减 70% 账单”的 PPT —— 并且像对待 Redis TTL 一样审查缓存键（cache key）：完全不审。这种审查通常交由性能团队负责。安全团队永远看不到设计文档，因为没有人会为“我们增加了一条更快的路径”提交安全审查。六个月后，某人的合规审计发现，“我无法登录我的账户，我的电子邮件是 [email protected]”和“我无法登录我的账户，我的电子邮件是 [email protected]”在向量化后都处于“我无法登录我的账户”的阈值内，于是缓存愉快地向 Bob 提供了原本为 Jane 生成的响应，其中包含了她账户请求的密码重置链接。

这篇文章将讨论为什么语义缓存值得拥有与 SQL 谓词相同的审查严谨性、如何通过缓存键设计从结构上防止跨用户泄露，以及你需要什么样的审计追踪来区分“缓存命中提供了正确答案”与“缓存命中在亚毫秒级延迟下提供了他人的答案”。

Phil Karlton有句名言——"计算机科学中只有两件难事：缓存失效和命名"——这句话诞生于语言模型进入生产之前。将AI加入技术栈后，缓存失效不只是变得更难；它在每一层同时变得更难，而且每一层的原因从根本上不同。

传统缓存存储的是确定性输出：数据库行、渲染的HTML、计算出的价格。当源数据变化时，你使该键失效，下一个请求获取新数据。契约很简单，因为答案是一个事实。

AI缓存存储的是不同的东西：对查询的响应，而这些响应的"正确"答案取决于上下文、时效性、模型行为以及模型所获取的源文档。这里的"陈旧"不意味着过时——它意味着在语义上出错，而你的监控不会发现，直到用户注意到为止。

大多数部署 AI Agent 的团队在实现了提示词缓存 (Prompt Caching)，或许再加上语义缓存之后，就认为大功告成了。但他们实际上错失了 40-60% 的潜在节省空间。原因并非在于懒惰 —— 而是 Agent 工作负载产生的缓存问题在简单的请求-响应式 LLM 调用中并不存在，其解决方案需要从传统 Web 缓存从未涉及的层级进行思考。

单个 Agent 任务可能涉及一个 4,000 Token 的系统提示词、三个分别返回不同结构数据的工具调用、一个在结构上与昨天完全相同的多步计划，以及一个需要在对话中持久化但绝不能跨用户共享的会话上下文。其中每一项都代表了不同的缓存机会，具有不同的 TTL (生存时间) 要求、不同的失效触发机制，以及在缓存失效时不同的故障模式。

大多数团队都是以同样的方式发现请求合并的：收到一张出乎意料的大额账单。他们上线了基于 LLM 的功能，使用量增长，然后账单仪表板显示他们每天为五万个请求付费，而仔细观察后发现其中大约三万个请求在问同一件事，只是措辞略有不同。每一个"总结这份文档"的改写都单独命中了模型。每一个近乎重复的请求都触发了完整的推理周期。成本随流量规模线性增长，而不是随用户实际想要的语义多样性增长。

请求合并正是解决这一问题的模式。它不是单一技术，而是一种分层架构：用于防止并发重复的飞行中去重、用于重复相同提示的精确缓存，以及用于捕捉中间改写变体的语义批处理。顺序很重要，阈值很重要，理解该模式何处会失效——尤其是围绕流式传输——是可用实现与那种在暂存服务器上节省了钱但在生产中引发隐蔽 bug 的实现之间的差别所在。

大多数构建 LLM 应用的团队都了解 Prompt caching —— 这是 API 提供商提供的一种前缀重用机制，旨在对重复的输入 Token 进行折扣。部署其上一层技术的团队则少之又少：语义缓存 (Semantic Caching)，它能彻底消除那些语义相同但表述不同的查询所产生的 LLM 调用。这种差距并非源于怠惰，而是源于对语义缓存供应商文档中 “95% 准确率” 含义的普遍误解。

那 95% 的数字指的是缓存命中时的匹配正确性，而不是缓存实际被命中的频率。实际生产环境中的命中率从开放式聊天的 10% 到结构化 FAQ 系统的 70% 不等 —— 在你编写任何缓存代码之前，你应该先计算出你处于该范围的哪一侧。

每个销售 LLM 网关的供应商都会向你展示一张标有“95% 缓存命中率”的幻灯片。那张幻灯片不会告诉你的是小字说明：这个数字是指在找到匹配项时的匹配准确度，而不是找到匹配项的频率。实际的生产系统命中率为 20–45% —— 营销与现实之间的差距正是大多数团队踩坑的地方。

语义缓存（Semantic caching）是一项非常有用的技术。但在不了解其失效模式的情况下部署它，会导致你以极高的置信度向用户返回错误答案，并让你纳闷为什么支持工单翻了一倍。

大多数基于 LLM 构建产品的团队都多付了 60%–90% 的费用。这并不是因为他们使用了错误的模型或提示词效率低下，而是因为他们在每次请求中都在重复处理相同的 Token。提示词缓存（Prompt caching）可以解决这个问题，且只需大约 10 分钟即可实现。然而，它仍然是生产级 LLM 系统中利用率最低的优化手段之一。

实际情况是：每次你向 LLM API 发送请求时，模型都会对提示词中的每一个 Token 运行注意力机制（Attention）。如果你的系统提示词（System prompt）有 10,000 个 Token，且每天处理 1,000 个请求，那么你每天仅为提示词中的静态部分（即永不变化的上下文）就要支付 1,000 万个 Token 的处理费用。提示词缓存会存储中间计算结果（即 Key-Value 注意力状态），以便后续请求可以完全跳过这部分工作。