大模型熔断策略：失败时先保护核心链路

一、AI 调用失败不能拖垮主流程

很多产品把 AI 能力嵌进核心流程：客服回复、文档生成、代码分析、风控辅助、运营报表。如果模型服务变慢或失败，后端不能让用户请求一直等在那里。AI 调用必须有熔断、超时和降级。

熔断不是承认系统不可靠，而是承认下游一定会有波动。高可用系统的关键，是下游波动时核心链路还能提供可预期的体验。

二、先识别核心与非核心

flowchart TD
  A[用户请求] --> B{是否核心链路}
  B -- 是 --> C[短超时调用 AI]
  B -- 否 --> D[异步任务队列]
  C --> E{成功}
  E -- 是 --> F[返回增强结果]
  E -- 否 --> G[降级返回基础结果]
  D --> H[后台重试]

核心链路里的 AI 调用应该短超时、少重试、可降级。非核心链路可以排队、延迟执行、后台重试。不要把所有 AI 请求都当同步调用处理，否则高峰期很容易把线程池、连接池和用户耐心一起耗光。

还要给不同功能设置优先级。用户正在支付或提交表单时，AI 建议失败可以跳过；后台生成长报告失败，可以重试或通知用户稍后查看。

三、熔断状态要透明

type CircuitState = "closed" | "open" | "half_open"

type CircuitMetric = {
  feature: string
  state: CircuitState
  errorRate: number
  p95LatencyMs: number
  openedAt?: string
}

熔断器不能只是代码里的一个布尔值。它需要指标、日志、告警和管理入口。运维或研发要知道哪个功能被熔断，为什么熔断，什么时候尝试半开恢复。

ai_circuit_breaker:
  timeout_ms: 2500
  failure_rate_threshold: 0.2
  min_requests: 50
  open_seconds: 60
  half_open_requests: 5

阈值不能拍脑袋。短文本任务和长文档任务的延迟分布不同，应该按功能配置。统一阈值很容易让低成本功能过度保护，让高成本功能保护不足。

四、降级结果也要可解释

AI 失败后，不要只返回“系统繁忙”。如果基础功能仍然可用，就返回基础结果，并在页面上说明智能增强暂时不可用。对后台任务，可以记录失败原因，允许用户稍后重试。

后端还要避免熔断雪崩。模型失败后，如果所有请求都立刻重试，会把下游打得更重。重试要有退避、抖动和最大次数，队列也要有长度限制。

熔断策略还要和缓存结合。对于摘要、分类、标签推荐这类可重复任务，可以在模型异常时返回最近一次可信结果，并标记为缓存命中。对于强实时任务，则宁愿返回基础结果，也不要拿过期答案假装智能能力还正常。不同功能的降级语义要提前写清楚。

压测时也要模拟下游故障。把模型调用延迟拉高、错误率拉高、响应格式打乱，观察核心接口是否还能在目标延迟内完成。只有在失败场景里验证过，熔断才不是纸面配置。

告警策略也要避免过度噪音。一次短暂超时不必惊动所有人，但熔断持续打开、半开恢复失败、降级比例持续升高，就应该进入值班流程。告警文案要带上功能名、供应商、模型、规则版本和最近错误样本，方便快速判断是外部波动还是内部发布引起。

同时要记录用户侧影响面，例如有多少请求拿到了基础结果、有多少任务进入延期队列。这样复盘时能衡量故障损失，而不是只讨论技术指标。

五、总结

大模型熔断策略的目标，是在模型服务失败、变慢或成本异常时保护核心链路。

把 AI 调用按优先级拆开，配置超时、熔断、降级和重试边界，系统才不会被一个智能功能拖成整体不可用。