成本与性能已更新 2026-06-24 · 版本 1.1
语义缓存
语义缓存存储以往的模型响应，并在新请求与先前请求语义相似时重新使用它们——通过嵌入（embeddings）按含义进行匹配，而非精确文本匹配。它降低了生产环境中常见的重复或近乎重复查询的成本和延迟。
证据: 生产环境置信度: 低来源: 生产系统来源: 个人经验来源: 行业观察
问题
许多生产环境中的查询只是对已回答问题的改写，因此对每个查询都重新运行完整模型会浪费成本并增加延迟。
适用场景
当流量中包含许多相似或重复的问题，且答案足够稳定可供复用时（如常见问题解答 FAQ、技术支持、文档助手），请使用语义缓存。
解决方案
对每个传入的请求进行向量化（Embed），并在先前请求的向量缓存中进行搜索。如果存在足够相似的条目（高于相似度阈值），则返回其存储的响应；否则调用模型并存储这一新的请求-响应对。
仔细调整相似度阈值：过宽的阈值会针对有细微差别的提问返回错误的答案；过严的阈值则会漏掉有效的缓存命中。添加 TTL 和失效机制，以防缓存的答案过期。
组件
请求的向量化（Embedding）向量缓存相似度阈值TTL / 失效机制回退到模型
优势
- 通过避免重复的模型调用来降低成本。
- 缓存命中时延迟更低。
- 对相似问题提供更一致的回答。
风险
- 过宽的阈值会提供错误的缓存答案。
- 若没有 TTL 或失效机制，缓存会过期变质。
- 个性化或时效性强的回答缓存效果较差。
不适用场景
- 当大多数查询都是唯一的时候。
- 当回答依赖于最新的、特定于用户或特定于时间的数据时。
- 当即使是微小的偏差也无法接受时。
技术
Embedding modelsVector databasesGPTCacheRedis / KV stores
示例
- 在“如何重置密码”的多种不同表述中复用同一个答案。
- 在支持助手（Support Assistant）中缓存常见的文档问题。
- 对重复的相同分析问题进行快速短路处理（直接返回缓存）。
生产实践证据
- 上下文
- 在 57 天内观察到的单操作员、本地优先的 OpenClaw 部署（161 个会话 / 2,776 轮对话），数据聚合自智能体自身的轨迹追踪。
- 场景
- 提示词和上下文缓存是通过 cache_control 标记、工作区文件缓存以及路由缓存来构建的，因此重复的结构可以直接从缓存中提供。
- 技术
- 在系统和消息上注入 Anthropic cache_control、OpenRouter 透传、工作区文件缓存、路由缓存，以及 cache_read/write 成本核算。
- 负载
- 57 天内总计 28.1M token，其中约 19.6M token 通过缓存读取（cache-read）提供。
- 结果
- 大约 70% 的 token 由缓存提供，将混合成本控制在每 1M token 15.21 美元（缓存读取费用为 41 美元，而全新输入费用为 374 美元）。这是单操作员、本地优先的部署——该比例反映了此工作负载'的重复性；请根据您自己的情况进行评估。
KPI
- 缓存命中率
- 从缓存中提供服务的请求比例；这是节省成本和降低延迟的关键杠杆。
- 误命中率
- 语义上“相似”的命中返回错误或过期答案的频率——这是按含义进行缓存的核心风险。
- 每次命中节省的成本和延迟
- 缓存命中时省去的 token 和时间，这是您用误命中风险换取的收益。
- 相似度阈值校准
- 匹配阈值是否平衡了命中率与误命中率；过宽会损害质量，过严则会抹杀节省的效果。
已观测到的失效模式
- 误命中：两个查询在向量空间中相似，但需要不同的答案，导致缓存返回了错误的结果。
- 过期：底层事实已发生变化，而缓存的答案已过时。
- 阈值微调不当：过宽会返回错误答案，过严则几乎无法命中。
- 缓存污染：错误的答案被缓存，随后被反复提供。
经验教训
- 根据实际流量调整相似度阈值；这是决定成败的关键参数。
- 在时效性或正确性至关重要的场景下，如果没有失效策略，切勿进行缓存。
- 对缓存命中进行验证或抽样，以便在用户发现之前捕获错误的匹配。
- 严格限制缓存范围（按租户、按上下文），以避免在不同用户之间泄露错误的答案。
常见问题
- 这与普通缓存有什么区别？
- 普通缓存匹配精确的键；语义缓存则使用向量化（Embeddings）按含义进行匹配，因此换个说法的提问仍能命中。
- 主要风险是什么？
- 过宽的相似度阈值会针对实际上不同的问题返回缓存的答案。请调整阈值并在实际流量中进行验证。
- 如何避免过期的答案？
- 设置 TTL 并在底层数据发生变化时使条目失效；避免缓存个性化或时效性强的响应。