大模型缓存如何失效和更新？
简化版
大模型缓存必须把“影响结果的全部版本”放进缓存键：租户/权限、模型、Prompt、知识库、工具、策略、解码配置和规范化输入。任一依赖变化时，旧结果不能继续作为当前答案。
失效采用版本化命名空间为主、TTL 为兜底、事件驱动主动失效为补充。安全撤权、文档删除等强一致事件必须立即失效；普通知识更新可短 TTL 或 Stale-While-Revalidate。更新时用单航班和随机过期防止缓存击穿与雪崩。
详细版
先区分响应缓存、语义缓存、前缀/KV 缓存和检索缓存。它们的正确性边界不同，不能共享一套粗糙 Key。
cache_key = hash(
tenant_scope, normalized_input,
model_version, prompt_version,
index_version, policy_version,
tool_schema_version, generation_config
)部署新版本时优先切换命名空间，避免全表扫描删除；后台渐进清理旧空间。命中后仍检查权限与内容版本，记录命中类型、数据年龄和来源。高风险场景宁可 Miss 重算，也不能返回无法证明新鲜度的结果。
完整版教学
1. LLM 缓存有哪些类型
响应缓存保存最终答案；语义缓存按向量相似度复用相近问题；前缀缓存复用 Prompt KV；检索缓存保存候选文档或重排结果。
不同层失效原因不同。模型升级会影响回答与 KV，文档更新影响检索与回答，但不一定影响公共 System Prompt 的 KV。
2. 缓存正确性的核心是什么
命中条件应表示“在当前执行语义和权限下结果仍等价”。仅用用户问题字符串作为 Key，遗漏版本和授权，极易返回过期或越权内容。
先列结果依赖图，再决定 Key 和失效事件；缓存设计不是最后加一个 Redis 即可。
3. Key 应包含哪些维度
模型权重、Adapter、Tokenizer、Prompt 模板、索引、Embedding、重排、工具 Schema、安全策略和关键解码配置都可能改变结果。
| 依赖变化 | 应失效对象 |
|---|---|
| 模型/Adapter | 响应、语义、KV |
| Prompt/策略 | 响应、语义、相关 KV |
| 文档/索引 | 检索、基于其生成的响应 |
| 权限 | 该权限域全部派生缓存 |
| 工具 Schema | 工具计划与结构化响应 |
Key 不必存完整内容，可保存不可变版本 ID 或哈希。
4. 权限为什么必须先于命中
相同问题在不同租户或角色下可见文档不同。必须在权限域内查缓存，或将授权集合版本纳入 Key。
用户撤权和租户删除属于强一致事件，要主动清除/隔离对应条目。不能等普通 TTL 自然过期后才停止泄露。
5. TTL 怎么设置
TTL 取决于数据变化速度、错误代价和重算成本。新闻/库存需要短 TTL，稳定公共 FAQ 可更长，高风险实时数据甚至不缓存最终答案。
增加随机抖动避免大量条目同一时刻过期：
effective_ttl = base_ttl × random(0.8, 1.2)TTL 是兜底，不应替代已知版本变更的主动失效。
6. 版本化命名空间的优势
发布新模型或索引时把 namespace 从 v1 切到 v2，新请求天然不命中旧数据，无需同步扫描删除海量 Key。
旧命名空间保留短期回滚窗口，随后异步清理。代价是切换初期命中率下降，可对高频安全条目预热。
7. 事件驱动失效如何做
文档更新、删除、权限变化和策略发布发送带版本的失效事件，消费者幂等处理。缓存条目可保存依赖文档 ID，便于精确反向清理。
事件可能重复、乱序或丢失，因此比较版本号，并用周期一致性扫描兜底。删除事件优先级高于普通更新。
8. Stale-While-Revalidate 何时适用
条目过期后先返回短时间旧值，同时后台刷新，可降低尾延迟与击穿。但只适合允许短暂陈旧的低风险内容。
安全策略、权限、价格和高时效事实通常不允许 SWR。响应应携带数据时间，产品契约要明确新鲜度。
9. 如何防缓存击穿
热点 Key 过期时若所有请求同时重算，会冲击模型。使用 Singleflight 让一个请求刷新，其余等待或读取允许的旧值。
miss -> acquire per-key lease -> one recompute
\----> others wait / staleLease 要有超时，刷新者失败后允许接管，避免永久锁死。
10. 如何防缓存雪崩和穿透
雪崩通过 TTL 抖动、分批预热和容量保护缓解。穿透是大量永不存在/不可缓存请求持续打到底层，可对确定性空结果设置短负缓存，并配合限流。
负缓存不能掩盖刚创建的数据，TTL 应短且包含版本；权限拒绝也不能跨用户共享。
11. 语义缓存为何更危险
相似问题不一定答案等价，“能否退款”和“如何退款”可能向量很近但意图不同。命中需相似度、意图、实体、权限和时效共同约束。
高风险场景可只缓存检索候选，不缓存最终生成；上线前用对抗样本评估错误命中率，而非只看命中率。
12. 前缀缓存如何失效
KV 与模型、Tokenizer、Adapter、位置编码和 Token 前缀绑定。任一变化都需新命名空间；不能把旧模型 KV 给新模型使用。
共享块使用引用计数，请求结束只减引用；版本下线时停止新引用，等待在途请求排空后释放。
13. 如何监控缓存
记录命中率之外，还要看命中 Token、节省成本、数据年龄、错误命中、失效延迟、刷新失败、击穿等待和占用容量。
高命中率可能来自返回陈旧答案。抽样对命中请求做旁路重算，比较语义和事实差异，可发现静默错误。
14. 如何测试与发布
覆盖模型/Prompt/索引更新、权限撤销、文档删除、并发热点过期、失效事件乱序和回滚。验证旧条目不能跨版本或跨租户命中。
先影子记录潜在命中，再小流量启用；错误命中、安全和数据新鲜度设独立回滚线。清缓存必须按精确命名空间操作，避免误删整个共享存储。
缓存命中的前提不是“看起来相似”，而是结果依赖和权限仍然完全有效。
15. 常见误区与追问
- 误区：只用问题文本做缓存 Key。 会忽略模型、知识和权限版本。
- 误区：有 TTL 就不需要主动失效。 撤权和删除不能等待自然过期。
- 误区：命中率越高越好。 错误命中比 Miss 更危险。
- 误区：语义相似就能复用回答。 意图、实体和时效可能不同。
- 误区：发布时 FLUSHALL 最简单。 会伤害其他租户并引发重算雪崩。
- 追问：如何支持快速回滚？ 保留旧版本命名空间，并让路由随 Manifest 切换。
- 追问：热点过期怎么办？ Singleflight、TTL 抖动和允许场景下的 SWR。
16. 加强记忆
- 先分缓存：响应、语义、检索、前缀 KV。
- 再画依赖：模型、Prompt、索引、策略、工具、权限。
- 再建 Key：版本与租户域必须齐全。
- 再定失效：版本命名空间、事件主动失效、TTL 兜底。
- 再抗并发：Singleflight、抖动、预热与负缓存。
- 再守红线：撤权/删除立即生效，高风险拒绝陈旧。
- 最后验收：错误命中、新鲜度和隔离优先于命中率。