大模型 API 突然超时怎么办？用熔断与降级机制提高 AI 应用稳定性

前言

在开发 AI 应用时，我们通常会关注模型的回答质量、Token 消耗和响应速度。

但实际使用中，还有一个很重要的问题：

如果大模型 API 突然不可用，我们的应用应该怎么办？

例如，一个基于大模型的智能客服系统，平时运行正常，但某天模型服务突然出现超时。

如果程序没有设计异常处理，用户可能一直看到加载动画，最后得到一个错误页面。

对于 AI Agent 来说，问题甚至更复杂。

模型调用失败后，Agent 可能不断重试，导致整个任务长时间无法结束。

因此，构建稳定的 AI 应用，不能只考虑模型正常工作的情况，还要提前设计故障应对机制。

本文介绍四个常见的工程方法：超时控制、有限重试、熔断保护和服务降级。

一、为什么大模型 API 可能突然变慢？

大模型服务通常涉及多个环节：

用户请求
   ↓
AI 应用服务器
   ↓
模型 API 网关
   ↓
模型推理服务
   ↓
生成结果
   ↓
返回用户

其中任何一个环节出现异常，都可能影响最终响应。

常见原因包括：

• 网络连接不稳定。

• API 请求频率受到限制。

• 模型服务负载较高。

• 上游服务出现临时故障。

• 输入上下文过长，导致推理耗时增加。

• 客户端或代理服务器提前终止连接。

如果程序没有设置合理的超时时间，一个请求就可能持续等待很久。

更严重的是，当大量请求同时等待时，还可能占用应用服务器的连接、线程或其他资源。

因此，第一步不是盲目增加重试次数，而是明确控制每个请求允许消耗的时间。

二、第一道防线：设置超时

超时控制的目标很简单：

不能让一个外部 API 请求无限等待。

例如，使用 Python 的 HTTP 客户端时，可以分别设置连接超时和读取超时。

下面是一个使用 requests 的示例：

import requests

def call_model_api(url, payload, headers):
    response = requests.post(
        url,
        json=payload,
        headers=headers,
        timeout=(5, 30)
    )

    response.raise_for_status()

    return response.json()

这里的超时参数表示：

• 连接超时为 5 秒。

• 单次底层读取等待超时为 30 秒。

需要注意，requests 中的读取超时并不等于整个请求的总时长限制。对于长时间流式返回的模型接口，还需要额外控制整体请求期限。

实际数值应根据模型类型、请求规模和业务要求确定，不能所有应用都使用相同配置。

例如，普通文本分类可能需要较短的等待时间，而长篇文档处理则可能需要更宽松的时限。

三、第二道防线：有限重试

当模型 API 出现临时错误时，重试有时可以恢复服务。

但重试必须有边界。

例如，下面这种处理方式就不合理：

while True:
    try:
        result = call_model()
        break
    except Exception:
        pass

这段代码可能无限循环，而且没有区分错误类型。

如果 API 凭据错误，重试一万次也无法解决问题。

因此，需要根据不同错误采取不同策略。

对于支持重试的请求，可以使用指数退避。

例如，初始等待 1 秒，之后逐步增加等待时间，并加入少量随机抖动，避免大量客户端同时重试。

不过，重试也不是越多越好。

如果上游服务已经严重过载，大量重复请求反而可能进一步增加服务压力。

对于具有创建、支付或发布等副作用的操作，还必须配合幂等性机制，不能直接套用普通查询请求的重试策略。

四、第三道防线：熔断机制

熔断机制（Circuit Breaker）是一种常见的服务保护方法。

可以把它理解为家里的电路保护开关。

当外部服务连续出现异常时，系统暂时停止向该服务发送新请求，避免不断重复失败操作。

熔断器通常包含三个状态。

CLOSED：关闭状态

正常允许请求通过。这里的“关闭”指熔断器未切断请求。

OPEN：打开状态

达到故障阈值后，暂时拒绝新的模型调用。

HALF_OPEN：半开状态

经过一段冷却时间后，允许少量探测请求，判断服务是否恢复。

一个基本流程如下：

正常调用模型
     ↓
连续出现故障
     ↓
达到熔断阈值
     ↓
暂时停止请求
     ↓
等待冷却时间
     ↓
尝试恢复探测
     ├── 成功 → 恢复正常
     └── 失败 → 继续熔断

熔断机制的优势在于：

当上游服务持续不可用时，应用可以快速失败并进入备用处理流程，而不是让每个用户都经历漫长的超时等待。

五、Python 实战：实现一个简单熔断器

下面使用 Python 标准库实现一个最小示例，不需要连接真实大模型 API。

import time


class CircuitBreaker:
    def __init__(self, threshold=2, cooldown=30):
        self.threshold = threshold
        self.cooldown = cooldown
        self.failures = 0
        self.open_until = 0

    def call(self, func):
        now = time.monotonic()

        if now < self.open_until:
            raise RuntimeError("服务处于熔断状态")

        try:
            result = func()

            # 成功后恢复正常
            self.failures = 0
            self.open_until = 0

            return result

        except Exception:
            self.failures += 1

            if self.failures >= self.threshold:
                self.open_until = (
                    time.monotonic() + self.cooldown
                )

            raise


def mock_model():
    raise ConnectionError("模拟模型服务故障")


breaker = CircuitBreaker(
    threshold=2,
    cooldown=30
)

for i in range(3):
    try:
        breaker.call(mock_model)
    except Exception as e:
        print(f"第 {i + 1} 次请求：{e}")

预期输出：

第 1 次请求：模拟模型服务故障
第 2 次请求：模拟模型服务故障
第 3 次请求：服务处于熔断状态

可以看到，前两次请求真实调用了模拟模型。

当连续失败次数达到阈值后，第三次请求不再调用上游服务。

这就是最简单的熔断保护。

这段代码仅用于说明原理。在生产系统中，还应区分可计入熔断的故障类型、限制恢复探测的并发数量，并处理多实例共享状态等问题。

六、第四道防线：服务降级

熔断只能减少无效请求，但不能保证用户一定得到有用的结果。

因此，还需要考虑服务降级（Fallback）。

所谓服务降级，就是在主要功能不可用时，提供一个能力较弱但仍然可靠的备用方案。

例如，一个 AI 客服系统可以采用：

这里需要特别强调：

降级不应该意味着编造答案。

例如，用户询问最新的订单状态，如果模型服务不可用，而系统又无法查询订单接口，就不应该随便返回一个看起来合理的订单结果。

正确做法应该是明确提示当前无法获取实时数据。

对于高风险任务，降级方案甚至可以是停止自动执行，等待系统恢复。

七、给熔断器增加一个降级入口

沿用前面的代码，可以添加一个简单的备用回答机制。

FAQ = {
    "什么是 Docker？":
        "Docker 是一种常见的容器化技术。",
    "什么是 HTTP？":
        "HTTP 是用于传输超文本等资源的应用层协议。"
}


def safe_answer(question):
    try:
        return breaker.call(
            lambda: mock_model()
        )
    except Exception:
        if question in FAQ:
            return FAQ[question]

        return "AI 服务暂时不可用，请稍后重试。"


print(safe_answer("什么是 Docker？"))
print(safe_answer("我的订单到哪里了？"))

这个示例体现了两个原则：

第一，对于知识稳定且经过审核的固定问题，可以使用备用答案。

第二，对于缺乏可靠数据来源的问题，应该明确说明服务不可用，而不是生成未经验证的信息。

实际应用中，还需要通过日志和指标区分正常模型回答、缓存回答以及降级回答，方便后续分析。

八、为什么超时、重试和熔断必须配合使用？

这几种机制解决的问题不同。

超时解决的是：单个请求等待太久。

重试解决的是：临时故障可能很快恢复。

熔断解决的是：持续故障时避免重复请求。

降级解决的是：主要服务不可用时，系统还能提供什么能力。

它们不是互相替代的关系。

一个比较合理的处理过程是：

用户请求
   ↓
检查熔断状态
   ↓
允许请求
   ↓
调用模型并设置超时
   ↓
成功？ ── 是 → 返回结果
   │
   否
   ↓
判断是否允许重试
   ↓
有限重试 / 记录故障
   ↓
仍然失败
   ↓
触发熔断条件
   ↓
进入安全降级流程

此外，还应当为整个用户请求设置总时间预算，避免每一层都单独重试，最终把等待时间叠加得过长。

九、生产环境还需要监控哪些指标？

仅仅实现熔断器是不够的。

如果没有监控，就可能出现服务已经持续降级，但开发者却没有及时发现的问题。

建议重点关注以下指标：

例如，如果大模型接口成功率较高，但用户最终任务成功率很低，就需要继续检查应用逻辑、工具调用以及其他依赖。

反过来，如果模型接口偶尔失败，但系统能够通过合理降级保持基础服务，也可以减少用户受到的影响。

真正需要优化的，不只是单个模型接口的表现，而是整个 AI 应用的可用性。

十、总结

随着大模型逐渐进入实际业务系统，开发者需要面对的不再只是模型输出质量，还包括网络异常、接口超时、服务不可用和外部依赖故障等工程问题。

通过超时控制、有限重试、熔断保护和服务降级，可以让 AI 应用在异常情况下保持更可控的行为。

本文主要总结了四个原则：

1. 每个外部请求都应有合理的超时边界。

2. 重试必须区分错误类型，并设置次数与时间预算。

3. 对持续故障使用熔断机制，避免无效调用。

4. 降级回答必须可靠，不能为了保持响应而编造信息。

对于 AI Agent，还应该特别注意外部工具操作的副作用。

当模型或工具服务不可用时，能够安全停止任务、保留进度并明确报告状态，有时比继续尝试更重要。

我认为，一个成熟的 AI 应用不仅要在模型正常运行时表现良好，也应该在模型暂时不可用时保持可预测、可恢复的行为。

真正稳定的 AI 系统，不是永远不会失败，而是能够在失败发生时，控制影响范围并提供合理的恢复路径。