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

大模型熔断策略失败时先保护核心链路一、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 调用按优先级拆开配置超时、熔断、降级和重试边界系统才不会被一个智能功能拖成整体不可用。