在 LLM 推理服务中，响应缓存是降低 P99 延迟的关键手段，但缓存失效策略设计不当会导致严重的数据一致性问题。本文以 DeepSeek 推理栈为例，拆解三类典型场景下的工程实践。

场景一：高频迭代的知识库问答

当 RAG 系统依赖每周更新的企业知识库时，直接缓存最终响应会引发信息滞后。我们的实践： 1. 分层缓存：对向量检索结果（文档片段）与 LLM 生成结果分离缓存 2. 版本化键设计：cache_key = hash(query + embedding_model_version + doc_version) 3. 被动失效：通过文档更新时间戳触发批量 key 淘汰

实施细节： - 使用 Redis 的 Sorted Set 存储文档版本时间轴，ZREMRANGEBYSCORE 自动清理旧版本 - 对 embedding 模型变更采用蓝绿部署，确保新旧版本缓存键不会冲突 - 实测显示，这种策略在 1000QPS 压力下仍能保持 95% 缓存命中率，同时数据滞后不超过 1 个发布周期

场景二：带用户上下文的会话

对于客服对话场景，缓存必须处理两种动态因素： - 用户画像变更（权限/偏好） - 会话历史更新（最近 3 轮对话）

解决方案： - 会话感知缓存键：包含 user_id + session_hash(last_3_turns) - 主动预热：当检测到用户资料变更时，异步重建其最近 5 个会话的缓存 - 熔断机制：在缓存未命中且 P95>800ms 时触发降级，返回不含个性化信息的通用响应

性能优化： - 会话哈希计算采用 xxHash 算法，单次计算仅 0.2ms - 采用 LRU + TTL 双重淘汰策略，防止长时间不活跃会话占用内存 - 在 DeepSeek-V4 的 32k 上下文场景下，缓存体积需额外增加 15% 的元数据开销

场景三：多模型路由场景

当网关需要根据负载切换 DeepSeek-V4 和其他模型时，缓存系统必须处理： 1. 模型版本差异：相同 prompt 在不同模型下的响应可能不兼容 2. 路由策略变更：灰度发布可能导致同一用户请求被路由到不同模型

技术实现： - 模型指纹标记：在缓存值中存储 model_id+quantization_type - 路由状态感知：缓存键包含当前路由表版本 route_config_md5 - 双写校验：新路由策略上线时，并行运行新旧策略 1 小时对比缓存命中率

边界条件处理： - 当模型响应格式差异大于 30%（通过文本相似度检测）时自动丢弃缓存 - 为每个路由版本保留最小缓存池（至少 1000 个高频查询） - 监控指标需区分「模型内命中率」和「跨模型命中率」

进阶话题：缓存雪崩防护

在高峰期缓存大规模失效时，我们采用分级重建策略： 1. 优先重建高频查询（基于历史访问计数） 2. 对长尾查询采用概率性过期（10% 请求触发重建） 3. 通过 DeepSeek 的批处理接口预生成热点问题的响应

成本与性能权衡

TL;DR 关键检查清单

1. 永远不要在缓存键中只使用原始 query text - 必须包含数据版本和模型特征
2. 对于动态数据源，采用被动失效 + 版本化键的组合策略
3. 会话场景必须将会话指纹纳入缓存键，而非单纯 user_id
4. 多模型环境下需要显式编码模型特征和路由状态
5. 通过分级重建和概率过期防止缓存雪崩
6. 监控应区分命中率、数据新鲜度、跨模型一致性三个维度
7. 在 DeepSeek-V4 的长上下文场景中，需评估缓存元数据开销