语义缓存
缓存三层：精确缓存、prompt 前缀缓存、语义缓存 —— 每上一层，正确性的责任就往你这边转移一层。语义缓存拿 embedding 相似度当缓存键，FAQ 类高重复问题省大钱，但阈值稍松就误命中答错话；多租户必须隔离，盈亏平衡点要会算。
也叫：语义缓存 · semantic cache · 缓存键 · 命中率 · 误命中 · 缓存三层
三、缓存三层：正确性责任在哪一层转移出自 T6-3
层级 位置 命中条件 模型跑不跑 正确性风险 ───────────────────────────────────────────────────────────────────── exact cache 应用/网关 请求完全相同 不跑 零 prompt/prefix 厂商侧 prefix 逐 token 相同 跑 零 semantic cache 应用/网关 向量相似度 ≥ 阈值 不跑 不可消除
第二层和第三层之间，正确性的责任发生了转移。 prompt 缓存由厂商保证"输出与不用缓存时完全相同"，只省重算不改结果；语义缓存没有任何人给你这个保证。
有一组公开评测把这件事钉死了：某云厂商用 6 万多条真实 query 做的基准里，阈值拉到 0.99（几乎等于精确匹配）时命中答案的准确率仍只有 92.1%；放宽到 0.75，准确率只掉到 91.2%，降本幅度却从 15.8% 涨到 86.3%。
两个反直觉结论： ① 误命中是结构性的，调阈值消不掉——阈值买的是命中率不是准确率。② 真正决定准确率的是缓存键的硬隔离维度：租户、用户、权限组、模型与 embedding 版本、prompt 模板版本、语料版本、语言，必须硬相等匹配。开头那个故障就是想用相似度做软隔离，已有公开安全 issue 证明这条路必然漏。
还有一整类 query 必须在查缓存之前拦掉：时间敏感、个性化、权限相关的"易变查询"。最锋利的例子是"现在几点"在 14:00 和 14:05 问，两次余弦相似度永远是 1.0、答案却不同，分数不会给你任何"过期了"的提示——这个判定只能放在应用层。官方还明说了一条边界：多轮与 Agent 场景不适用，连续轮次文本几乎相同、相似度约 0.99，会导致 agent 重放旧响应、重复工具调用。
降本动作有一个正确的顺序（T6-4 展开每一步的量化判据）：
exact cache（零风险，吃掉典型流量 15–30%）→ prompt/prefix cache（零风险，只省输入侧） → effort 档位（改输出侧）→ 跨模型路由（有双轴评测之后）→ 级联
以上节选自T6-3 LLM 网关：限流、降级、缓存与路由的四笔账，读全文能看到前后语境。