AI 系统如何处理模型调用失败、超时和降级？

安逸Ai2026/6/17大约 6 分钟系统设计面试容错降级

AI 系统如何处理模型调用失败、超时和降级？

面试问到这个问题，核心考的就是：当 AI 模型不给力的时候，你的系统怎么不崩？

说白了就三件事：错误来了怎么办、系统过载了怎么熔断、彻底挂了有没有兜底。把这三个问题答清楚，面试基本稳了。

先认错再处理——错误分类是降级的第一步

AI 模型调用失败，不是所有错误都一个处理方式。你得先分清楚是哪类错误，才能对症下药。

把 AI 调用错误当成外卖配送异常来理解就简单了：

骑手联系不上（超时）：换个骑手重试就行，不算大事
商家缺货（余额不足/429限流）：等一等再试，或者切换备选商家
地址错误（401/403权限问题）：直接放弃，重试也没用

具体怎么处理？看 HTTP 状态码决定策略：

状态码	含义	处理方式
401/403	认证失败/权限不足	直接报警，不重试
429	请求过多/限流	等待后重试，用指数退避
500/502/503	服务端错误	重试 1-3 次
超时	模型响应太慢	触发降级

重点说下 429 和超时。429 是 AI 服务在告诉你"现在太忙了"，这时候别傻等，要用 exponential backoff（指数退避）：第一次等 1 秒，第二次等 2 秒，第三次等 4 秒，倍数增长。

超时一般设置 5-10 秒，超过就直接走降级流程，别在那干等浪费用户时间。

错误分类处理流程图，横向标注401/403直接报警、429等待重试、500系重试1-3次、超时触发降级的决策分支

阅读全文

给系统装上"保险丝"——熔断降级机制

错误分类搞定了，接下来要防的就是：某个模型持续抽风，把整个系统拖垮。

这就需要 熔断器（Circuit Breaker）。

想象一下家庭电路的场景： 当某个房间短路电流过大时，保险丝会熔断，切断整个房间电源。这个房间的故障就不会影响到其他房间。等你修好线路，再把保险丝合上恢复正常。

AI 系统里的熔断器就是这个原理，三状态切换：

CLOSED（关闭）：正常状态，所有请求都过
OPEN（打开）：错误率超标，直接返回降级响应，不再调用模型
HALF_OPEN（半开）：试探恢复，放一部分请求过去试试

触发条件一般是：

10 秒内错误率超过 40%
或者连续失败超过 5 次

熔断打开后，等待 30-60 秒，然后进入半开状态。如果试探请求成功了，就关闭熔断恢复正常；还是失败就继续打开。

另外还有个 Bulkhead（隔板） 概念，就是把并发调用隔离开。比如你同时调用 GPT-4 和 Claude，别让其中一个的失败影响另一个，各占各的"隔间"。

熔断器状态转换图，显示CLOSED/OPEN/HALF_OPEN三态及错误率大于40%等触发条件

层层设防——多级降级策略

熔断器防止的是短时间内的过载，但如果模型真的彻底挂了怎么办？

答案是：多级降级，一层一层兜底。

就像网购的多个收货地址：

首选地址填错了 → 自动用备用地址
备用地址也失效 → 用第三个地址
都没填 → 用默认地址

总有一个能收到货。

AI 调用也是同样的逻辑，从高到低依次尝试：

缓存命中 → 主模型调用 → 备用模型 → 默认兜底响应

第一级：缓存

语义相似的问题，之前回答过，直接返回缓存结果
响应快、零成本

第二级：主模型

GPT-4、Claude 这些主力模型
正常情况下走这里

第三级：备用模型

主模型熔断了，切到备用
可以是更小更快的模型，比如 GPT-3.5、或者本地开源模型

第四级：默认响应

所有模型都挂了
返回"系统繁忙，请稍后再试"，或者返回预设的兜底答案

另外还有个 令牌桶限流，控制每分钟调用次数。别让用户刷爆你的 API 额度，也别花太多钱。设置个成本预算，超了就降级。

工具箱对比——三大框架各司其职

光知道原理不够，面试最好能说出具体用什么工具。

三个主流框架，各管一摊：

框架	负责什么	核心功能
Spring Retry	重试	`@Retryable` 注解，指定重试次数和回退策略
Resilience4j	熔断	熔断器、限流、舱壁，支持滑动窗口统计
Sentinel	限流	流量控制、熔断降级、热点参数限流

用装修工具来理解：

电钻负责打孔（重试）→ Spring Retry
锯子负责切割（熔断）→ Resilience4j
卷尺负责测量（限流）→ Sentinel

Spring 生态里，Resilience4j 是目前主流的熔断方案。它支持滑动窗口统计，能更精确地计算错误率，不容易被突发失败骗到。

如果用 Spring AI，还有更直接的 @Retryable 和 @Recover 注解， Retryable 管重试，Recover 管重试失败后的降级回调。

@Retryable(retryFor = AiException.class, maxAttempts = 3, backoff = @Backoff(delay = 1000, multiplier = 2))
public String callModel(String prompt) {
    // 调用 AI 模型
}

@Recover
public String fallback(AiException e) {
    // 降级处理，返回缓存或默认响应
}

三框架能力对比图，展示Spring Retry/Resilience4j/Sentinel的核心功能与适用场景

面试怎么答

基础版（能说清楚基本思路）：

AI 系统处理模型调用失败，核心是三步走。首先根据错误类型分类处理：401/403 直接报警不重试，429 等一等用指数退避重试，500 系重试 1-3 次，超时直接降级。其次加熔断器，当错误率超过 40% 就打开熔断，后续请求直接走兜底逻辑，防止系统被拖垮。最后做多级降级：缓存 > 主模型 > 备用模型 > 默认响应，一层层兜底。

加分版（能结合实际和深入原理）：

错误处理我一般用 Spring Retry 做重试，配合 Resilience4j 的熔断器。熔断器用滑动窗口统计 10 秒内的错误率，超过阈值就打开熔断，30 秒后进入半开状态试探恢复。降级策略上，优先查缓存，缓存没有就切备用模型，所有模型都不可用就返回兜底响应。另外我会用令牌桶控制调用频率，设置成本预算防止额度被刷穿。如果用 Spring AI，可以用 @Retryable 和 @Recover 注解配合使用，代码更简洁。

一句话总结

AI 调用失败处理的核心就是：先分类、再熔断、最后兜底——三层防线保你不崩。