上一篇文章讨论了 Agent 的核心组件——RAG、向量库、Function Calling 与 Skill 体系。但把这些组件拼起来之后更棘手的问题浮出水面多轮对话怎么管重复请求怎么省上游挂了怎么办这三个问题对应的正是大模型后端设计的三大支柱上下文管理、缓存策略和降级容错。如果说 Agent 的组件决定了系统“能做什么”那这三大支柱决定了系统“能不能活下来”。一、先理解核心矛盾大模型的“无状态”特性所有后端架构决策都源于大模型的一个基本事实每一次 LLM 调用都是无状态的。模型读上下文窗口生成响应然后忘掉一切。这意味着所有记忆能力必须由应用侧实现。模型不会主动存储对话记录如果两次请求之间不手动拼接历史内容模型无法识别两次提问的关联。每次请求都在重复“购买”上下文。用户的历史对话、系统提示、检索结果、工具定义——每一次调用都要重新传入Token 成本随对话轮次加速增长。模型的“健康状态”不可预测。延迟波动大、可能限流、可能超时传统后端的健康检查机制在这里完全不够用。理解了这三个约束上下文管理、缓存、降级的设计就有了统一的出发点。大模型后端 vs 传统后端的本质差异维度 传统 Web 后端 大模型后端响应耗时 10–100ms 1–20s流式更长状态模型 无状态为主 强状态关联上下文依赖资源瓶颈 CPU/内存/带宽 GPU 显存/算力故障模式 快速失败 长时间阻塞→雪崩降级方式 直接返回错误码 需要柔性兜底缓存/小模型/静态答案大模型推理高度依赖 GPU 显存和算力单卡能承载的并发数极其有限贸然扩容还会产生极高的硬件成本这是大模型后端必须做精细化流量管控的核心原因。同时大模型推理是非确定性的相同输入可能产生不同输出这使得传统缓存的“精确匹配”策略在很多场景下失效。二、上下文管理从“什么都塞”到“精准投喂”2.1 为什么上下文管理是后端设计的核心上下文工程已经成为 Agentic 系统的独立基础设施层。Agent 失败最常见的原因不是模型能力不足而是上下文设计失误给得太少导致模型凭空猜测给得太多导致上下文窗口溢出或触发“上下文腐化”切割方式不对导致任务边界不清。一个完整的 200K 上下文窗口理想的分层结构应该是这样的text┌─────────────────────────────────────────────┐│ Layer 1: System Prompt [预算: 2,000–8,000] ││ · 角色定义 / 能力边界 / 行为约束 / 输出格式 │├─────────────────────────────────────────────┤│ Layer 2: Injected Memory [预算: 3,000–10,000] ││ · 长期记忆(压缩后) / 用户偏好 / 跨轮摘要 │├─────────────────────────────────────────────┤│ Layer 3: Retrieved Context [预算: 10,000–40,000]││ · RAG检索结果 / 代码片段 / 架构决策文件 │├─────────────────────────────────────────────┤│ Layer 4: Conversation History [动态预算] ││ · 近期对话原文 / 工具调用记录 │├─────────────────────────────────────────────┤│ Layer 5: Current Task [动态] ││ · 当前问题 / 临时指令 / 结构化输出要求 │└─────────────────────────────────────────────┘关键原则让模型在任意时刻看到的上下文窗口恰好包含完成当前步骤所需的全部信息且不多也不少。2.2 四种上下文压缩策略的取舍生产环境中最常用的四种上下文管理策略各自适合不同场景策略 原理 成本 信息保留度 适用场景滑动窗口 保留最近N轮对话丢弃更早的 零成本~0ms延迟 低远期信息完全丢失 高频短会话、客服机器人摘要压缩 用LLM将旧对话压缩为摘要 高额外LLM调用 中关键信息保留细节丢失 长对话Agent、代码助手优先级截断 按消息重要性评分保留高分消息 零成本 中依赖评分准确性 信息密度不均的场景向量记忆 将历史存入向量库按需检索 中需向量化检索 高按相关性召回 跨会话、用户画像场景滑动窗口保留最近几轮对话最近几轮信息密度最高、最不该失真用滑动窗口原样保留是成本最低的选择。而摘要压缩则适合更长的场景——生产系统如 Anthropic 的 Claude Code 和 OpenAI 的 Codex以及 LangChain 和 LlamaIndex 等框架都依赖 LLM 摘要调用来在接近窗口限制时压缩上下文。实践中最有效的方案是“滑动窗口 滚动摘要”的混合策略维护一个会话级摘要捕捉关键讨论点和用户目标同时保留最近3–5轮对话的滑动窗口用于维持语气和上下文连续性。一个关键工程陷阱滑动窗口虽然零成本但可能破坏前缀缓存的连续性。如果每次请求的 system prompt 和工具定义都不同前缀缓存永远无法命中。最佳实践是一旦系统提示和工具定义确定不要更改它们动态信息时间戳、用户状态始终追加到对话末尾而不是修改系统提示。2.3 上下文持久化四层架构大模型本身无记忆能力所有的上下文关联、对话记忆、用户会话状态都需要业务层手动进行存储、裁剪、拼接、分发与销毁。一套完整的会话状态由四大模块组成对话上下文状态系统角色设定、历史问答、临时指令直接参与 Prompt 拼接消耗 Token 最多会话基础属性状态会话ID、用户标识、创建时间、过期时长、状态标记正常/冻结/归档/删除用于会话隔离与生命周期管控业务临时状态工具调用记录、函数执行结果、中间计算数据、用户偏好配置全局配置状态单会话独立的模型参数温度系数、最大生成长度、知识库绑定范围在存储层面实践中可以按记忆寿命分层——寿命长的放前面不动保证缓存复用寿命短的放后面随时覆盖状态栏寿命已过的压缩或删除。2.4 生产级记忆系统的五阶段流水线更完整的方案是构建持久化记忆系统。LLM Agent 需要持久化记忆来支撑连续对话、用户画像、知识沉淀与崩溃恢复但满上下文方案成本高、延迟大、易出错。核心流水线是五阶段抽取 → 整合 → 存储 → 检索 → 遗忘。同时区分四种记忆类型记忆类型 存放什么 存储位置 生命周期 典型失效模式工作记忆 当前对话、工具结果 上下文窗口(prompt) 仅当前会话 窗口填满模型跟丢早期指令情景记忆 过往会话记录 向量数据库 数周到数月 检索到不相关旧情景、时间混淆语义记忆 蒸馏出的事实、用户偏好 向量库/知识图谱 持久化 知识冲突、过时未更新过程记忆 可复用的操作流程 结构化存储 持久化 流程变更后未同步更新成本数据很能说明问题满上下文方案在 LOCOMO 基准上能拿到 72.9% 的准确率代价是 p95 延迟 17.12 秒、Token 开销翻 14 倍。一个中等规模 SaaS 若每月 1000 万次 Agent 调用走满上下文仅 LLM Token 就约 100 万美元同样的工作负载换成选择性记忆会降到约 10 万美元。这就是“demo 与能摆到付费用户面前的系统之间的分界线”。三、缓存策略AI 应用成本优化的最高杠杆3.1 五层缓存架构缓存是 AI 应用成本与延迟优化的最高杠杆手段——一次缓存命中可以节省 100% 的 LLM 调用成本与 95% 的延迟。但 AI 缓存比传统 Web 缓存复杂得多需要语义匹配、TTL 与失效策略、以及多层分级。完整的多层缓存架构如下text请求 → L1:精确缓存 → L2:语义缓存 → L3:前缀缓存(KV) → LLM调用↓命中 ↓命中 ↓命中(仅decode)直接返回 直接返回 部分复用各层的关键参数层级 匹配方式 目标命中率 延迟节省 TTL 存储L1 精确缓存 query 完全匹配 15% 100% 1h RedisL2 语义缓存 向量相似度0.95 25% 95% 1h 向量库L3 前缀缓存 系统提示 KV 复用 40% 70% 永久 GPU显存L4 嵌入缓存 query 嵌入结果 30% 90% 24h RedisL5 检索缓存 RAG 检索结果 20% 85% 5min Redis这五层并非都要同时实现。建议按优先级逐步建设先做 L1 精确缓存和 L3 前缀缓存实现简单、收益高再考虑 L2 语义缓存复杂度较高最后补上 L4/L5。3.2 语义缓存生产环境的分层设计语义缓存是最有“AI特色”的一层。生产部署通常采用分层静态-动态设计静态缓存存储经过离线审核的精选响应动态缓存在线填充。但实践中的一个硬约束是两类缓存通常共用一个嵌入相似度阈值这导致了硬性权衡——保守阈值会错过安全复用机会激进阈值可能返回语义不正确的响应。一个前沿方案是异步 LLM 裁判机制当最近邻相似度略低于阈值时异步调用 LLM 判断缓存响应是否可接受通过验证的匹配被晋升到动态缓存。在模拟测试中这种方法在对话流量上提升缓存命中率至 2.4 倍在搜索型查询上提升 3.9 倍。实现建议对于已经使用 Redis 的团队Redis 的向量搜索功能提供了生产就绪的语义缓存方案无需引入新服务。语义缓存的阈值调优建议从 0.95 起步逐步根据误命中率调整。3.3 前缀缓存最被低估的优化手段前缀缓存Prefix Caching的机制是当后续调用与之前的调用共享前缀时推理引擎可以直接复用缓存的 KV 状态而不需要重新计算整个 prefill。但它的效果高度依赖严格的 Prompt 结构化。前缀缓存要求逐字节完全匹配即使是微小的格式差异也会破坏缓存命中。工程上的应对策略是系统提示和工具定义一旦确定不要随意更改。任何修改都会使所有缓存的 KV 状态失效。动态信息追加到末尾。时间戳、用户状态等变化内容应作为新消息追加到对话末尾而不是修改系统提示。确定性的排序规则。对于检索结果等动态注入的内容使用确定性的排序如字母序而非相似度分数排序以保证相同内容集的前缀一致。vLLM 与 Mooncake 的集成实践表明通过将分布式 KV 缓存存储集成到 vLLM 中可实现 3.8 倍吞吐量提升、首字延迟降低 46 倍、端到端延迟降低 8.6 倍。3.4 缓存的失效与一致性大模型缓存比传统缓存多了一层复杂性知识更新后缓存需要失效。工程上的应对策略包括TTL 分层精确缓存和语义缓存设 1 小时 TTL检索缓存设 5 分钟嵌入缓存设 24 小时嵌入结果变化小版本化缓存键当知识库或模型版本变更时通过修改缓存键前缀使旧缓存自动失效命中率监控如果某一层的命中率持续低于预期说明缓存策略或阈值需要调整四、降级策略保障系统不雪崩的最后防线4.1 限流、熔断、降级的关系在大模型高可用架构中限流、熔断、降级是三大核心容错策略三者是协同互补、层层防护的关系限流事前防御控制流量规模。通过限制单位时间内的请求数量防止 GPU 算力过载。熔断事中保护隔离故障。当下游服务连续异常、错误率超标时自动切断上游对故障服务的持续调用快速失败防止资源耗尽。降级事后兜底保障体验。上游不可用时提供低成本、高稳定的替代方案确保核心业务可用。三者的协同关系可以用一句话概括限流挡流量、熔断断故障、降级给兜底。4.2 大模型熔断的特殊设计大模型推理服务有独特运行特性传统熔断机制无法直接适配单次推理链路长超时判定阈值需要远高于传统接口GPU 显存与算力资源占用极高并发承载能力有限流式输出链路易中断半开状态探测策略需要重新设计第三方模型接口存在网络波动与配额限制一个关键的工程洞察限流的模型是健康的不是故障的。将 429 限流视为“暂时降速”而非“失败”不要触发熔断器可以显著提升可用性。生产中的错误分类处理策略错误类型 熔断器行为 降级动作限流(429) 不计入失败defer 路由到下一个候选模型瞬时错误(5xx/超时) 计入失败 触发failover可选重试终端错误(auth/参数) 不计入失败请求级问题 返回明确错误failover熔断器采用三态流转模型CLOSED正常通行→ OPEN快速断连→ HALF_OPEN渐进放行。4.3 降级的四个层次大模型服务降级需要覆盖模型推理层、向量检索层、知识库服务层、缓存层全链路而非单一节点降级。按代价递增排列的四层降级策略L1 缓存兜底代价最低 当模型推理超时或不可用时直接返回缓存的历史回答。适合高频标准化问答场景。L2 模型降配从千亿参数模型快速切流至百亿参数模型以保底输出牺牲部分推理精度换取响应速度。实测中按意图复杂度自动选择模型档位后日均 Token 成本降低 64%同时复杂问题解决率不降。L3 检索降级当向量数据库故障时跳过语义检索直接使用关键词匹配或静态知识库。L4 静态答案兜底代价最高体验最差 返回预置的标准话术如“系统正在维护请稍后重试”。这是最后的安全网。在多模型 fallback 的路由策略上推荐按可靠性排序的备用链第一回退同供应商小模型——应对主模型并发限流第二回退备用供应商对应模型——应对主供应商网络或 API 错误最终兜底静态答案或缓存响应4.4 降级的可观测性降级必须埋点监控统计各类降级发生频次。如果某一类降级大量触发代表上游链路存在隐患需要优化 Prompt、路由策略或者扩容模型资源。关键 SLO 指标建议成功率 ≥ 99.5%、P95 延迟、降级率 1%。每次降级事件都应记录触发原因超时/限流/错误、降级层级、用户影响范围、恢复时间。五、三大模块的协同一个完整的请求生命周期把上下文管理、缓存和降级串起来看一个生产级大模型请求的完整链路是text用户请求│├── 1. 网关层│ ├── 限流检查令牌桶/滑动窗口│ └── 上下文长度预检ai-context-limit插件可在网关层提前拦截超限请求│├── 2. 缓存层│ ├── L1 精确缓存命中→ 返回│ ├── L2 语义缓存命中→ 返回│ └── 未命中 → 继续│├── 3. 上下文组装│ ├── 加载会话状态Redis/DB│ ├── 选择压缩策略滑动窗口/摘要/向量检索│ ├── 注入记忆和检索结果│ └── 拼接 Prompt前缀缓存友好的结构│├── 4. 模型调用│ ├── 熔断器状态检查CLOSEDOPENHALF_OPEN│ ├── 路由选择按复杂度/成本/可用性│ ├── 调用主模型│ └── 失败→ Fallback链小模型 → 备供应商 → 静态兜底│├── 5. 响应处理│ ├── 写入缓存精确语义│ ├── 更新会话状态│ └── 记录可观测性数据延迟/Token/降级标记│└── 返回用户这个链路中网关层是承上启下的关键。现代 AI Gateway 不只是反向代理而是集成了上下文限制检查、语义缓存、多模型路由和降级策略的治理层。六、关键工程决策速查决策点 推荐方案 核心理由上下文压缩策略 滑动窗口(3-5轮) 滚动摘要 兼顾近期精度和远期信息保留上下文存储 Redis(热数据) 向量库(冷数据) 按访问频率分层降低延迟缓存优先级 精确缓存 → 前缀缓存 → 语义缓存 按实现复杂度递增收益递减语义缓存阈值 0.95起步逐步调优 保守阈值优先保证正确性前缀缓存 系统提示固定不变动态内容追加末尾 任何前缀变更都会使缓存失效熔断阈值 错误率50%持续30s触发 大模型场景需比传统服务更宽容降级链路 缓存→小模型→备供应商→静态答案 按代价递增优先保体验可观测性 全链路追踪降级埋点 没有数据就无法优化七、写在最后大模型后端的核心挑战可以归结为一个根本矛盾模型是无状态的、昂贵的、不稳定的但用户需要的是有记忆的、经济的、可靠的体验。上下文管理解决“记忆”问题——通过分层预算、压缩策略和持久化架构在有限的窗口内精准投喂模型所需的信息。缓存策略解决“成本”问题——通过五层分级缓存把高频、重复的请求拦截在 LLM 调用之前。降级策略解决“可靠性”问题——通过限流、熔断、降级的协同在部分组件故障时仍能提供可接受的用户体验。这三个模块不是独立的优化点而是相互制约的系统工程。上下文压缩可能破坏前缀缓存缓存策略可能影响降级判断降级路由可能改变上下文长度——每一个决策都需要在全局视角下权衡。正如一位一线工程师所说“这个问题的答案必须在出事之前写好因为出事的当下你没有时间设计它。” 上下文管理、缓存和降级都是需要在系统设计阶段就纳入架构的基础设施而不是事后补救的补丁。
上一篇文章讨论了 Agent 的核心组件——RAG、向量库、Function Calling 与 Skill 体系。但把这些组件拼起来之后更棘手的问题浮出水面多轮对话怎么管重复请求怎么省上游挂了怎么办这三个问题对应的正是大模型后端设计的三大支柱上下文管理、缓存策略和降级容错。如果说 Agent 的组件决定了系统“能做什么”那这三大支柱决定了系统“能不能活下来”。一、先理解核心矛盾大模型的“无状态”特性所有后端架构决策都源于大模型的一个基本事实每一次 LLM 调用都是无状态的。模型读上下文窗口生成响应然后忘掉一切。这意味着所有记忆能力必须由应用侧实现。模型不会主动存储对话记录如果两次请求之间不手动拼接历史内容模型无法识别两次提问的关联。每次请求都在重复“购买”上下文。用户的历史对话、系统提示、检索结果、工具定义——每一次调用都要重新传入Token 成本随对话轮次加速增长。模型的“健康状态”不可预测。延迟波动大、可能限流、可能超时传统后端的健康检查机制在这里完全不够用。理解了这三个约束上下文管理、缓存、降级的设计就有了统一的出发点。大模型后端 vs 传统后端的本质差异维度 传统 Web 后端 大模型后端响应耗时 10–100ms 1–20s流式更长状态模型 无状态为主 强状态关联上下文依赖资源瓶颈 CPU/内存/带宽 GPU 显存/算力故障模式 快速失败 长时间阻塞→雪崩降级方式 直接返回错误码 需要柔性兜底缓存/小模型/静态答案大模型推理高度依赖 GPU 显存和算力单卡能承载的并发数极其有限贸然扩容还会产生极高的硬件成本这是大模型后端必须做精细化流量管控的核心原因。同时大模型推理是非确定性的相同输入可能产生不同输出这使得传统缓存的“精确匹配”策略在很多场景下失效。二、上下文管理从“什么都塞”到“精准投喂”2.1 为什么上下文管理是后端设计的核心上下文工程已经成为 Agentic 系统的独立基础设施层。Agent 失败最常见的原因不是模型能力不足而是上下文设计失误给得太少导致模型凭空猜测给得太多导致上下文窗口溢出或触发“上下文腐化”切割方式不对导致任务边界不清。一个完整的 200K 上下文窗口理想的分层结构应该是这样的text┌─────────────────────────────────────────────┐│ Layer 1: System Prompt [预算: 2,000–8,000] ││ · 角色定义 / 能力边界 / 行为约束 / 输出格式 │├─────────────────────────────────────────────┤│ Layer 2: Injected Memory [预算: 3,000–10,000] ││ · 长期记忆(压缩后) / 用户偏好 / 跨轮摘要 │├─────────────────────────────────────────────┤│ Layer 3: Retrieved Context [预算: 10,000–40,000]││ · RAG检索结果 / 代码片段 / 架构决策文件 │├─────────────────────────────────────────────┤│ Layer 4: Conversation History [动态预算] ││ · 近期对话原文 / 工具调用记录 │├─────────────────────────────────────────────┤│ Layer 5: Current Task [动态] ││ · 当前问题 / 临时指令 / 结构化输出要求 │└─────────────────────────────────────────────┘关键原则让模型在任意时刻看到的上下文窗口恰好包含完成当前步骤所需的全部信息且不多也不少。2.2 四种上下文压缩策略的取舍生产环境中最常用的四种上下文管理策略各自适合不同场景策略 原理 成本 信息保留度 适用场景滑动窗口 保留最近N轮对话丢弃更早的 零成本~0ms延迟 低远期信息完全丢失 高频短会话、客服机器人摘要压缩 用LLM将旧对话压缩为摘要 高额外LLM调用 中关键信息保留细节丢失 长对话Agent、代码助手优先级截断 按消息重要性评分保留高分消息 零成本 中依赖评分准确性 信息密度不均的场景向量记忆 将历史存入向量库按需检索 中需向量化检索 高按相关性召回 跨会话、用户画像场景滑动窗口保留最近几轮对话最近几轮信息密度最高、最不该失真用滑动窗口原样保留是成本最低的选择。而摘要压缩则适合更长的场景——生产系统如 Anthropic 的 Claude Code 和 OpenAI 的 Codex以及 LangChain 和 LlamaIndex 等框架都依赖 LLM 摘要调用来在接近窗口限制时压缩上下文。实践中最有效的方案是“滑动窗口 滚动摘要”的混合策略维护一个会话级摘要捕捉关键讨论点和用户目标同时保留最近3–5轮对话的滑动窗口用于维持语气和上下文连续性。一个关键工程陷阱滑动窗口虽然零成本但可能破坏前缀缓存的连续性。如果每次请求的 system prompt 和工具定义都不同前缀缓存永远无法命中。最佳实践是一旦系统提示和工具定义确定不要更改它们动态信息时间戳、用户状态始终追加到对话末尾而不是修改系统提示。2.3 上下文持久化四层架构大模型本身无记忆能力所有的上下文关联、对话记忆、用户会话状态都需要业务层手动进行存储、裁剪、拼接、分发与销毁。一套完整的会话状态由四大模块组成对话上下文状态系统角色设定、历史问答、临时指令直接参与 Prompt 拼接消耗 Token 最多会话基础属性状态会话ID、用户标识、创建时间、过期时长、状态标记正常/冻结/归档/删除用于会话隔离与生命周期管控业务临时状态工具调用记录、函数执行结果、中间计算数据、用户偏好配置全局配置状态单会话独立的模型参数温度系数、最大生成长度、知识库绑定范围在存储层面实践中可以按记忆寿命分层——寿命长的放前面不动保证缓存复用寿命短的放后面随时覆盖状态栏寿命已过的压缩或删除。2.4 生产级记忆系统的五阶段流水线更完整的方案是构建持久化记忆系统。LLM Agent 需要持久化记忆来支撑连续对话、用户画像、知识沉淀与崩溃恢复但满上下文方案成本高、延迟大、易出错。核心流水线是五阶段抽取 → 整合 → 存储 → 检索 → 遗忘。同时区分四种记忆类型记忆类型 存放什么 存储位置 生命周期 典型失效模式工作记忆 当前对话、工具结果 上下文窗口(prompt) 仅当前会话 窗口填满模型跟丢早期指令情景记忆 过往会话记录 向量数据库 数周到数月 检索到不相关旧情景、时间混淆语义记忆 蒸馏出的事实、用户偏好 向量库/知识图谱 持久化 知识冲突、过时未更新过程记忆 可复用的操作流程 结构化存储 持久化 流程变更后未同步更新成本数据很能说明问题满上下文方案在 LOCOMO 基准上能拿到 72.9% 的准确率代价是 p95 延迟 17.12 秒、Token 开销翻 14 倍。一个中等规模 SaaS 若每月 1000 万次 Agent 调用走满上下文仅 LLM Token 就约 100 万美元同样的工作负载换成选择性记忆会降到约 10 万美元。这就是“demo 与能摆到付费用户面前的系统之间的分界线”。三、缓存策略AI 应用成本优化的最高杠杆3.1 五层缓存架构缓存是 AI 应用成本与延迟优化的最高杠杆手段——一次缓存命中可以节省 100% 的 LLM 调用成本与 95% 的延迟。但 AI 缓存比传统 Web 缓存复杂得多需要语义匹配、TTL 与失效策略、以及多层分级。完整的多层缓存架构如下text请求 → L1:精确缓存 → L2:语义缓存 → L3:前缀缓存(KV) → LLM调用↓命中 ↓命中 ↓命中(仅decode)直接返回 直接返回 部分复用各层的关键参数层级 匹配方式 目标命中率 延迟节省 TTL 存储L1 精确缓存 query 完全匹配 15% 100% 1h RedisL2 语义缓存 向量相似度0.95 25% 95% 1h 向量库L3 前缀缓存 系统提示 KV 复用 40% 70% 永久 GPU显存L4 嵌入缓存 query 嵌入结果 30% 90% 24h RedisL5 检索缓存 RAG 检索结果 20% 85% 5min Redis这五层并非都要同时实现。建议按优先级逐步建设先做 L1 精确缓存和 L3 前缀缓存实现简单、收益高再考虑 L2 语义缓存复杂度较高最后补上 L4/L5。3.2 语义缓存生产环境的分层设计语义缓存是最有“AI特色”的一层。生产部署通常采用分层静态-动态设计静态缓存存储经过离线审核的精选响应动态缓存在线填充。但实践中的一个硬约束是两类缓存通常共用一个嵌入相似度阈值这导致了硬性权衡——保守阈值会错过安全复用机会激进阈值可能返回语义不正确的响应。一个前沿方案是异步 LLM 裁判机制当最近邻相似度略低于阈值时异步调用 LLM 判断缓存响应是否可接受通过验证的匹配被晋升到动态缓存。在模拟测试中这种方法在对话流量上提升缓存命中率至 2.4 倍在搜索型查询上提升 3.9 倍。实现建议对于已经使用 Redis 的团队Redis 的向量搜索功能提供了生产就绪的语义缓存方案无需引入新服务。语义缓存的阈值调优建议从 0.95 起步逐步根据误命中率调整。3.3 前缀缓存最被低估的优化手段前缀缓存Prefix Caching的机制是当后续调用与之前的调用共享前缀时推理引擎可以直接复用缓存的 KV 状态而不需要重新计算整个 prefill。但它的效果高度依赖严格的 Prompt 结构化。前缀缓存要求逐字节完全匹配即使是微小的格式差异也会破坏缓存命中。工程上的应对策略是系统提示和工具定义一旦确定不要随意更改。任何修改都会使所有缓存的 KV 状态失效。动态信息追加到末尾。时间戳、用户状态等变化内容应作为新消息追加到对话末尾而不是修改系统提示。确定性的排序规则。对于检索结果等动态注入的内容使用确定性的排序如字母序而非相似度分数排序以保证相同内容集的前缀一致。vLLM 与 Mooncake 的集成实践表明通过将分布式 KV 缓存存储集成到 vLLM 中可实现 3.8 倍吞吐量提升、首字延迟降低 46 倍、端到端延迟降低 8.6 倍。3.4 缓存的失效与一致性大模型缓存比传统缓存多了一层复杂性知识更新后缓存需要失效。工程上的应对策略包括TTL 分层精确缓存和语义缓存设 1 小时 TTL检索缓存设 5 分钟嵌入缓存设 24 小时嵌入结果变化小版本化缓存键当知识库或模型版本变更时通过修改缓存键前缀使旧缓存自动失效命中率监控如果某一层的命中率持续低于预期说明缓存策略或阈值需要调整四、降级策略保障系统不雪崩的最后防线4.1 限流、熔断、降级的关系在大模型高可用架构中限流、熔断、降级是三大核心容错策略三者是协同互补、层层防护的关系限流事前防御控制流量规模。通过限制单位时间内的请求数量防止 GPU 算力过载。熔断事中保护隔离故障。当下游服务连续异常、错误率超标时自动切断上游对故障服务的持续调用快速失败防止资源耗尽。降级事后兜底保障体验。上游不可用时提供低成本、高稳定的替代方案确保核心业务可用。三者的协同关系可以用一句话概括限流挡流量、熔断断故障、降级给兜底。4.2 大模型熔断的特殊设计大模型推理服务有独特运行特性传统熔断机制无法直接适配单次推理链路长超时判定阈值需要远高于传统接口GPU 显存与算力资源占用极高并发承载能力有限流式输出链路易中断半开状态探测策略需要重新设计第三方模型接口存在网络波动与配额限制一个关键的工程洞察限流的模型是健康的不是故障的。将 429 限流视为“暂时降速”而非“失败”不要触发熔断器可以显著提升可用性。生产中的错误分类处理策略错误类型 熔断器行为 降级动作限流(429) 不计入失败defer 路由到下一个候选模型瞬时错误(5xx/超时) 计入失败 触发failover可选重试终端错误(auth/参数) 不计入失败请求级问题 返回明确错误failover熔断器采用三态流转模型CLOSED正常通行→ OPEN快速断连→ HALF_OPEN渐进放行。4.3 降级的四个层次大模型服务降级需要覆盖模型推理层、向量检索层、知识库服务层、缓存层全链路而非单一节点降级。按代价递增排列的四层降级策略L1 缓存兜底代价最低 当模型推理超时或不可用时直接返回缓存的历史回答。适合高频标准化问答场景。L2 模型降配从千亿参数模型快速切流至百亿参数模型以保底输出牺牲部分推理精度换取响应速度。实测中按意图复杂度自动选择模型档位后日均 Token 成本降低 64%同时复杂问题解决率不降。L3 检索降级当向量数据库故障时跳过语义检索直接使用关键词匹配或静态知识库。L4 静态答案兜底代价最高体验最差 返回预置的标准话术如“系统正在维护请稍后重试”。这是最后的安全网。在多模型 fallback 的路由策略上推荐按可靠性排序的备用链第一回退同供应商小模型——应对主模型并发限流第二回退备用供应商对应模型——应对主供应商网络或 API 错误最终兜底静态答案或缓存响应4.4 降级的可观测性降级必须埋点监控统计各类降级发生频次。如果某一类降级大量触发代表上游链路存在隐患需要优化 Prompt、路由策略或者扩容模型资源。关键 SLO 指标建议成功率 ≥ 99.5%、P95 延迟、降级率 1%。每次降级事件都应记录触发原因超时/限流/错误、降级层级、用户影响范围、恢复时间。五、三大模块的协同一个完整的请求生命周期把上下文管理、缓存和降级串起来看一个生产级大模型请求的完整链路是text用户请求│├── 1. 网关层│ ├── 限流检查令牌桶/滑动窗口│ └── 上下文长度预检ai-context-limit插件可在网关层提前拦截超限请求│├── 2. 缓存层│ ├── L1 精确缓存命中→ 返回│ ├── L2 语义缓存命中→ 返回│ └── 未命中 → 继续│├── 3. 上下文组装│ ├── 加载会话状态Redis/DB│ ├── 选择压缩策略滑动窗口/摘要/向量检索│ ├── 注入记忆和检索结果│ └── 拼接 Prompt前缀缓存友好的结构│├── 4. 模型调用│ ├── 熔断器状态检查CLOSEDOPENHALF_OPEN│ ├── 路由选择按复杂度/成本/可用性│ ├── 调用主模型│ └── 失败→ Fallback链小模型 → 备供应商 → 静态兜底│├── 5. 响应处理│ ├── 写入缓存精确语义│ ├── 更新会话状态│ └── 记录可观测性数据延迟/Token/降级标记│└── 返回用户这个链路中网关层是承上启下的关键。现代 AI Gateway 不只是反向代理而是集成了上下文限制检查、语义缓存、多模型路由和降级策略的治理层。六、关键工程决策速查决策点 推荐方案 核心理由上下文压缩策略 滑动窗口(3-5轮) 滚动摘要 兼顾近期精度和远期信息保留上下文存储 Redis(热数据) 向量库(冷数据) 按访问频率分层降低延迟缓存优先级 精确缓存 → 前缀缓存 → 语义缓存 按实现复杂度递增收益递减语义缓存阈值 0.95起步逐步调优 保守阈值优先保证正确性前缀缓存 系统提示固定不变动态内容追加末尾 任何前缀变更都会使缓存失效熔断阈值 错误率50%持续30s触发 大模型场景需比传统服务更宽容降级链路 缓存→小模型→备供应商→静态答案 按代价递增优先保体验可观测性 全链路追踪降级埋点 没有数据就无法优化七、写在最后大模型后端的核心挑战可以归结为一个根本矛盾模型是无状态的、昂贵的、不稳定的但用户需要的是有记忆的、经济的、可靠的体验。上下文管理解决“记忆”问题——通过分层预算、压缩策略和持久化架构在有限的窗口内精准投喂模型所需的信息。缓存策略解决“成本”问题——通过五层分级缓存把高频、重复的请求拦截在 LLM 调用之前。降级策略解决“可靠性”问题——通过限流、熔断、降级的协同在部分组件故障时仍能提供可接受的用户体验。这三个模块不是独立的优化点而是相互制约的系统工程。上下文压缩可能破坏前缀缓存缓存策略可能影响降级判断降级路由可能改变上下文长度——每一个决策都需要在全局视角下权衡。正如一位一线工程师所说“这个问题的答案必须在出事之前写好因为出事的当下你没有时间设计它。” 上下文管理、缓存和降级都是需要在系统设计阶段就纳入架构的基础设施而不是事后补救的补丁。
