语义缓存：大幅降低LLM API成本的隐形成本杀手

传统缓存检查你是否见过完全相同的输入。语义缓存则检查你是否见过语义上相似的输入——用 embeddings 替代字符串匹配来实现。对基于 LLM 的应用而言，这可以在不改动任何提示词或模型选择的情况下，将 API 成本降低 30%–70%，并将延迟从秒级缩短到毫秒级。

如果你在使用 LLM API 构建任何应用，可能已经注意到：

用户会用十几种不同方式问同一个问题（"你们的退款政策是什么？"、"退款怎么操作？"、"我能退钱吗？"） 标准缓存（Redis、精确键查找）会把这些问题全部漏掉，因为字符串不匹配 上述每一条语义重复的提问都会触发一次完整的、可计费的模型调用

你在为冗余工作支付全价——同时承担全量延迟。

语义缓存的不同之处

语义缓存不做原始输入字符串的哈希，而是：

将传入的查询嵌入为向量 在向量存储中搜索"足够接近"的历史查询（余弦相似度高于某个阈值，如 0.92+） 若命中则即时返回缓存的响应 若未命中则调用 LLM，然后将新的查询+响应对存储起来供下次使用

这将缓存命中率从"仅精确重复"提升到了"模型会以相同方式回答的一切查询"。

在生产环境中，将内存中的列表替换为向量数据库（支持向量搜索的 Redis、Pinecone、Qdrant 或 pgvector），这样缓存在重启后依然保留，且能扩展到数千条以上。

适用场景

客户支持机器人——用户之间的表述方式高度重叠 RAG 系统——针对同一知识库的重复提问 内部开发工具——反复出现的"我如何……"类查询 高流量应用——即使 20% 的缓存命中率也能显著影响账单

需要注意的地方

阈值调优很关键。太宽松会给语义不同但 embedding 相近的问题返回过时或错误答案（"取消我的订阅"和"取消我的免费试用"embedding 可能很接近，但含义截然不同）。

对时间敏感的查询（"天气怎么样"、"最新价格"）根本不应该缓存——在缓存前加一个 bypass 列表或意图分类器。

缓存失效依然是那个老大难问题。如果底层数据变了，过时的缓存答案就不再是特性，而是隐患。

Embedding 成本并非免费——但通常比一次完整 completion 调用便宜 10–50 倍，所以对大多数负载来说，缓存的数学账仍然合算。

总结

语义缓存与其说是一项新发明，不如说是一个"时机已到"的显而易见的主意——如今 embeddings 已经足够廉价和快速。如果你的 LLM 成本在不断攀升，且你的查询在意图上存在任何重复（哪怕措辞不同），这是本周你可以添加的杠杆最高、努力最低的优化手段之一。

你在生产环境中实现过语义缓存吗？用什么阈值和向量存储效果最好？欢迎在评论区留言。