前端学 LLM

成本、延迟与路由：缓存、降级和模型选择如何进入生产策略

生产环境里的成本和延迟不是单次模型调用参数能解决的问题。

同一个 AI 功能可能同时包含检索、工具调用、模型生成、重试、缓存、fallback 和人工接管。用户关心的是能不能及时得到可信结果，业务关心的是单位任务成本和服务可用性。成本、延迟与路由的目标，是在质量、预算、速度和风险之间建立可解释的策略，而不是简单选择“最强”或“最便宜”的模型。

1. 提出问题

在一个面向企业客户的客服助手中，AI 要处理三类请求：

  • 简单问题：改写客服回复、分类工单、提取订单号。
  • 中等问题：基于知识库回答政策、总结历史工单。
  • 复杂问题：结合客户状态、订单工具、合同条款和历史沟通给出处理建议。

上线初期团队为了保证质量，所有请求都走强模型，并携带较长上下文。随着用量增长，问题出现了：

  • 简单分类和改写也消耗大量 token。
  • 复杂请求在工具等待和模型生成上延迟很高。
  • 高频 FAQ 每次都重新检索和生成。
  • 高峰期供应商 429 导致整条链路失败。
  • 某些租户成本明显偏高，但不知道是长上下文、重试还是工具导致。
  • 为了节省成本直接切便宜模型后，人工修改率上升。

这个场景不能只问“哪个模型便宜”。更准确的问题是：哪些请求可以缓存，哪些可以用小模型，哪些必须保留强模型，哪些可以异步，哪些失败时必须降级或转人工。

请求类型用户期待成本延迟风险策略重点
分类抽取快、稳定、可入库大模型过配小模型、schema、缓存
FAQ 回答有引用、低延迟重复检索生成检索缓存、答案缓存、引用版本
复杂建议准确、可解释工具慢、上下文长强模型、分段 trace、部分结果
高风险动作可审计、可确认错误成本高人工确认、强模型、回滚

2. 分析问题

成本、延迟与路由要拆成任务类型、风险等级和链路阶段。

分析项具体判断工程含义
问题类型分类、抽取、改写、检索、生成、判断、工具调用不同任务不应默认同一模型
收益来源降低单位成本、缩短等待、提升可用性路由要服务业务体验
失败代价错答、超时、越权、成本突增、降级误导降级必须诚实展示能力边界
人工位置高风险确认、低置信度兜底、异常接管人工是策略的一部分

模型适合处理语言理解、总结、推理和生成。系统应该处理预算、路由、缓存、限流、超时、fallback 和成本归因。人工应该处理高风险决策、低置信度结果和多次失败后的接管。

生产策略至少要记录四类指标。

  • 成本指标：输入 token、输出 token、缓存命中、重试成本、单位业务成本、租户成本。
  • 延迟指标：TTFT、总耗时、检索耗时、工具耗时、队列等待、P95/P99。
  • 质量指标：采纳率、修改率、schema 成功率、引用正确率、投诉率。
  • 路由指标：模型分布、fallback 率、降级率、人工接管率、限流率。

没有这些指标时，路由会变成拍脑袋：便宜模型可能增加人工成本，强模型可能浪费在简单任务上，缓存可能返回过期或越权结果。

3. 列举方案

成本延迟策略可以从基础控制逐步升级。

第一层是成本归因。先知道钱花在哪里：哪个租户、哪个功能、哪个任务、哪个模型、哪个版本、多少 token、多少重试、多少缓存未命中。

第二层是上下文预算。限制历史消息、检索片段、工具字段和输出长度。简单 prompt 足够的场景，通常通过预算和格式约束就能控制成本。

第三层是缓存。可缓存对象包括系统提示前缀、检索结果、工具查询、分类抽取结果和稳定 FAQ 答案。缓存必须带权限、租户、数据版本、prompt 版本和失效策略。

第四层是模型路由。按任务、风险、用户等级、置信度和预算选择模型。分类抽取可以走小模型，高风险判断走强模型，低置信度结果升级，主模型失败进入 fallback。

第五层是超时与并发控制。设置网关、后端、检索、工具、模型首 token 和总生成超时。高峰期通过队列、优先级、限流和异步任务保护系统。

第六层是 fallback 和降级。供应商失败时切同级模型；成本压力大时限制上下文或使用轻量模型；工具失败时返回部分结果；高风险或多次失败时转人工。降级可以降低能力，但不能伪装成完整成功。

第七层是反馈回归。每一次路由、缓存、降级和模型切换，都要同时看质量、成本和延迟。只降本不看人工修改率，会把成本转嫁给用户。

4. 决策判断

场景条件推荐方案不推荐方案判断理由额外成本
简单分类抽取量大小模型 + schema 校验 + 低置信度升级强模型处理全部请求任务边界清晰，可自动校验小模型评估和路由
FAQ 高频重复检索缓存 + 答案缓存 + 文档版本失效每次重新生成重复问题不应重复消耗完整链路缓存键、权限、失效
长上下文成本高上下文预算 + 摘要 + 片段排序全量历史塞入 prompt多数旧上下文不是当前任务必需摘要和检索评估
用户重视首字速度streaming + TTFT 监控 + 快速状态反馈只优化总耗时用户感知首先来自是否有响应流式协议和前端状态
工具调用慢工具超时 + 部分结果 + 异步补全同步等待所有工具实时工具不应拖垮整个回答任务状态和补全逻辑
高峰期供应商限流队列 + 限流 + fallback 模型无限重试重试会放大成本和拥塞队列、优先级、告警
成本预算严格租户配额 + 路由策略 + 告警月底统一看账单预算需要实时控制配额系统和策略管理
高风险建议强模型 + 证据引用 + 人工确认便宜模型直接自动输出错误代价高于模型成本审核 UI 和审计

常见反模式：

第一，只按模型单价路由。路由应该看任务完成成本，包括重试、人工修改、延迟损失和错误风险。

第二，缓存不带权限和版本。多租户系统里，缓存键如果没有租户、角色、数据版本和 prompt 版本，可能返回越权或过期答案。

第三，把降级做成静默成功。工具失败时不能假装已经查到实时数据；轻量模型回答也应该在产品状态上表达能力边界。

第四，用无限重试对抗不稳定。重试会扩大拥塞和账单。更合理的是错误分类、退避、总预算、fallback 和人工接管。

第五，只优化 P50 延迟。真实用户投诉常来自 P95/P99、首 token 慢和工具尾延迟。监控和策略要关注尾部。

5. 结论收束

成本、延迟与路由的生产判断是：先归因，再优化；先区分任务和风险，再选择模型；先明确降级边界，再追求可用性。简单功能可以从 token 日志、上下文预算和少量缓存开始；核心链路必须建立路由、配额、超时、fallback、监控和反馈回归。

上线前检查清单：

  • 场景边界：请求类型、风险等级、同步或异步要求是否明确。
  • 成本归因：是否按租户、功能、任务、模型、版本、token、重试和缓存拆分。
  • 延迟预算：TTFT、总耗时、检索、工具、队列和持久化是否分别设预算。
  • 上下文预算：历史、检索片段、工具字段和输出长度是否有限制。
  • 缓存策略：缓存对象、缓存键、权限隔离、数据版本、失效条件是否清楚。
  • 模型路由：不同任务、风险、置信度、用户等级和预算是否有路由规则。
  • 降级策略：模型失败、工具超时、成本超限、上下文过长时是否有 fallback。
  • 用户感知：降级、异步、部分结果和人工接管是否有明确状态。
  • 质量回归：每次降本或加速是否对比采纳率、修改率、错误率和投诉率。
  • 回滚恢复：路由规则、模型版本、缓存策略和降级开关是否能快速恢复旧状态。