在大规模 LLM Agent 部署场景中，每一次模型调用都意味着真实的计算成本与响应延迟。重复的用户意图、同样的工具调用序列、以及会话上下文的频繁访问，构成了缓存优化的天然场景。当前业界主流的做法是采用多层缓存架构，将精确匹配缓存、语义缓存与 LLM 调用形成级联，既能最大化命中率，又能保留模型推理的灵活性。本文从架构设计出发，详细拆解各层实现细节与可落地参数。
多层缓存架构的核心逻辑
传统缓存策略往往依赖单一的键值匹配，无法处理用户意图的微妙变化。多层缓存架构的核心思想是建立一条从最快到最慢、从最精确到最模糊的检索链路：当一个请求进入系统时，首先在最近邻域查找完全一致的命中；若未命中，则进入语义层进行向量相似度搜索；只有当前两层都无法满足时，才不得不调用底层 LLM 进行推理。这种级联设计的关键在于，每一层都有明确的职责边界和退出条件，层层递进而不是互相干扰。
AWS 在其官方博客中披露的案例显示，使用 ElastiCache-for-Valkey 作为语义缓存层后，推理成本降低了 86%，而响应延迟则下降了 40% 以上。这一数据印证了多层缓存在生产环境中的实际价值。Redis 官方同样指出，Redis 8 的语义缓存功能可将重复调用的成本削减 50%，对于意图高度集中的对话场景尤为有效。
第一层：精确匹配缓存的实现
精确匹配缓存是整个架构中响应速度最快的环节，通常部署在进程内存或靠近请求入口的边缘节点。这一层的实现逻辑极为直接：将用户输入的完整提示词或对话摘要作为键（Key），将模型输出或工具执行结果作为值（Value），存入快速访问的存储介质中。常见的实现方案包括进程内字典（如 Python 的 dict 或 Go 的 map）、本地文件缓存（如 LRU 缓存），以及 Redis 集群的裸键操作。
在参数配置层面，精确缓存需要关注以下几个关键指标。首先是缓存容量上限，建议设置为单实例内存的 10% 至 20%，避免挤占模型推理所需的内存空间。其次是过期时间（TTL），对于客服机器人等场景，建议设置为 5 至 15 分钟，以平衡缓存命中率与内存占用；对于代码生成等场景，可适当延长至 30 分钟至 1 小时。第三是驱逐策略，LRU（最近最少使用）是生产环境中最稳妥的选择，它能在内存压力下保留热点数据。具体的配置示例如下：假设使用 Redis 作为 Tier 1 存储，可通过 maxmemory-policy allkeys-lru 启用 LRU 驱逐，maxmemory 2gb 限制单实例内存占用，EXPIRE 命令设置 600 秒的默认 TTL。
精确缓存的适用场景边界同样需要明确界定。它最适合处理完全相同的请求，例如重试机制发送的相同请求、模板化生成的固定提示词、以及高频复现的调试场景。值得注意的是，这一层不应当存储包含时间戳、随机数或会话特定上下文的信息，否则缓存命中率会急剧下降。
第二层：语义缓存的设计与落地
当精确缓存未命中时，请求会进入语义缓存层进行处理。这一层的核心挑战在于，如何判断 “语义相似” 的两个请求是否值得复用同一份回答。业界通用的做法是先将用户输入转换为向量嵌入（Embedding），然后在向量数据库或支持向量检索的键值存储中查找相似结果。Valkey 和 Redis 都能通过模块扩展支持向量检索功能，Redis 官方的 Redis Stack 更是原生集成了向量搜索能力。
在工程实现上，语义缓存需要解决三个关键问题。第一是向量生成管道的延迟控制。建议在请求入口处同步生成 Embedding，并向量化模型的推理延迟应控制在 10 毫秒以内，超出此阈值的方案需要考虑预计算或批量处理。第二是相似度阈值的选取，这是一个需要在命中率与准确率之间进行权衡的参数。根据 AWS 的最佳实践，相似度阈值建议设置在 0.85 至 0.95 之间，低于 0.85 的匹配结果容易导致答案不相关，高于 0.95 则会让语义缓存形同虚设。第三是向量索引的构建策略，对于 QPS 较高的场景，建议使用 HNSW（Hierarchical Navigable Small World）算法构建索引，它能在保持较高搜索精度的同时将查询延迟控制在毫秒级。
Valkey 与 Redis 在这一层的选型上存在细微差别。Valkey 作为 Redis 7.2.4 的开源分支，保留了核心的内存缓存模型和 Redis 兼容的命令集，适合对开源主导权有强需求的团队；Redis 则在 AI 能力上更为领先，提供了原生的向量集合、混合搜索以及 LangCache 等语义缓存产品化的解决方案。如果团队对向量检索的工程化投入有限，Redis 的开箱即用方案能显著降低上线周期。
第三层：LLM 回退与状态管理
当语义缓存也无法满足需求时，请求最终会到达 LLM 推理层。这一层的核心任务不仅是执行模型推理，还包括将本次推理的输入输出同步回写到缓存层，以便后续相同或相似的请求能够命中缓存。在实现上，建议采用写穿透（Write-Through）策略：每当 LLM 完成一次推理，无论是成功还是失败，都将原始输入（及对应的 Embedding）与输出写入缓存层。写入操作应当是异步的，避免阻塞模型响应的返回。
会话状态的管理是多层缓存架构中容易被忽视的细节。Agent 场景下的会话通常包含多轮对话历史、工具执行上下文以及中间推理结果。对于这类状态数据，建议采用独立的缓存命名空间进行隔离管理，使用会话 ID 作为键的前缀（如 session:{session_id}:history），并将完整的对话历史序列化后存入 Redis。在会话恢复场景下，只需从缓存中读取对应会话 ID 的历史数据，即可快速重建上下文，无需重新调用模型。
监控指标与回滚策略
生产环境中的缓存系统需要完善的监控体系来保障稳定性。建议重点关注以下指标：缓存命中率（Hit Rate）反映了整体缓存架构的效率，生产环境下 Tier 1 的命中率应维持在 30% 以上，Tier 2 的累计命中率应达到 60% 以上；平均响应时间（p50/p99）用于评估缓存层带来的延迟收益，命中缓存的请求应当比直接调用 LLM 快 100 毫秒以上；内存使用率用于监控缓存层的资源消耗，Valkey/Redis 的内存使用率不应超过 70%，超过阈值时应当触发告警。
回滚策略的设计同样关键。当语义缓存层出现异常（如向量索引损坏或相似度计算错误）时，系统应当具备自动降级的能力：完全跳过语义缓存层，仅依赖精确缓存和 LLM 调用。这种降级不会导致服务不可用，只是会损失一部分缓存收益。当精确缓存层出现问题时（如 Redis 连接超时），应用层应当具备本地缓存的兜底能力，确保核心业务流程不中断。
工程落地的关键建议
在将多层缓存架构投入生产之前，有几个实践要点值得特别关注。第一是缓存键的设计策略，除了使用原始提示词作为键之外，建议增加业务维度的前缀（如用户 ID、场景类型），既能实现租户隔离，也方便后续的细粒度管理。第二是 Embedding 模型的选型，建议选择延迟低且维度适中的模型（如 BGE-small-zh-v1.5），过高维度的向量会显著增加存储成本和检索延迟。第三是缓存数据的序列化格式，JSON 是最通用的选择，但如果对性能有极致要求，可以考虑使用 MessagePack 或 Protobuf 进行压缩。
多层缓存架构的本质是以空间换时间、以确定性换性能。在实际业务中，需要根据用户的请求分布特征、模型的调用成本以及基础设施的投入预算进行灵活的层次划分和参数调优。当架构设计合理、参数配置恰当时，缓存层能够将 LLM 的实际调用量削减一半以上，同时将用户体验的响应时间压缩到原来的三分之一。
参考资料
- AWS: "Lower cost and latency for AI using Amazon ElastiCache as a semantic cache with Amazon Bedrock"
- Redis Blog: "What is Valkey? A comparison with Redis"
- YouTube: "Semantic Caching with Valkey and Redis - Martin Visser"