大模型API中断复盘：故障归因与韧性实践

一、事件回顾：一次典型的“部分恢复”

近日，某大模型服务平台更新了状态公告：此前发生的网页及API服务部分中断问题已实施修复，官方正在持续监控修复效果，但部分服务性能仍处于下降状态。

这段简短的公告包含三个值得注意的信号：

1. 故障范围是“部分中断”：说明并非全局性宕机，更可能是某机房、某集群、某类资源或某条链路出了问题；
2. “已实施修复、监控效果”：这是典型的灰度修复表述，意味着修复方案正在逐步放量验证，而非一次性全量生效；
3. “性能仍下降”：服务在功能层面可用，但时延、吞吐或成功率指标尚未回到稳态，指向容量缺口或降级运行，而不单纯是某个代码缺陷。

对使用者而言，“已恢复但不健康”的窗口期恰恰最容易引发生产事故：探活请求成功，真实业务请求却持续超时，客户端重试逻辑反而进一步放大服务端压力。因此，理解这类现象背后的机理，无论对故障归因还是业务自保都非常重要。

二、大模型在线服务为何比传统Web服务更脆弱

大模型推理服务与传统Web服务在架构上存在本质差异，这些差异决定了它“更容易出问题、更难快速恢复”：

• 算力密度极高：单次请求的计算量比普通接口高出多个数量级，少量请求即可占满一整块GPU；
• 请求时延长、连接占用久：流式生成动辄持续数十秒，连接与队列资源被长时间持有；
• 显存刚性约束：KV缓存随并发数与上下文长度近似线性增长，无法像CPU那样通过超卖换取弹性；
• 扩容周期长：GPU资源稀缺且昂贵，无法像无状态CPU服务那样分钟级横向扩容；
• 冷启动代价大：单节点加载模型权重可达数十GB至数百GB，重启节点需要较长预热时间。

这些特性叠加，使大模型服务的容量规划普遍偏紧、故障传导速度更快、恢复路径也更复杂。

三、可能的故障原因逐层剖析

3.1 流量层：突发洪峰与排队雪崩

热点事件、新版本发布或批量任务集中触发，都会带来瞬时的请求洪峰。推理服务普遍在入口处部署排队与限流，当队列持续积压时，外部表现正是“服务能通，但响应明显变慢”。更危险的是雪崩效应：请求时延上升导致客户端超时重试，重试流量进一步加剧拥塞，形成正反馈循环。

3.2 算力层：GPU节点故障与容量水位

在数千卡规模的推理集群中，单节点故障（驱动异常、网卡掉线、互联链路抖动、显存纠错等）是常态。传统Web服务节点冗余度高，摘除个别节点影响甚微；而推理集群的容量冗余通常设计得更紧，当部分节点被摘除后，流量转移到剩余节点，整体时延抬升、排队加深，就会出现“API恢复了但性能下降”的直接体感。

3.3 推理引擎层：KV缓存与批调度压力

现代推理引擎普遍采用连续批处理调度，其吞吐高度依赖批的饱满程度和KV缓存命中。长上下文请求会让KV缓存快速膨胀、缓存复用率下降；预填充与解码两阶段的资源特征不同，负载结构突变时吞吐可能骤降。若故障后切换了调度参数或批大小配置以保稳定，也会主动牺牲部分性能。

3.4 工程层：变更、依赖与级联故障

统计上，多数线上事故与变更直接相关：模型权重更新、推理引擎版本升级、网关规则调整都可能引入回归。此外，大模型服务并非孤立系统——负载均衡、鉴权、限流组件、日志存储等任一依赖故障，都会以“部分中断”的形式暴露。故障后的紧急修复本身也是一种变更，若不灰度，极易引发二次事故。

四、“已恢复但性能仍下降”的合理解释

将公告信息与技术机理对应，“恢复但降速”通常来自以下三类原因：

（1）降级运行模式。 故障期间及恢复初期，平台常主动收紧限流阈值、缩小调度批大小、优先保障高优先级通道、关闭非核心功能。这些手段换取了可用性，代价就是吞吐与时延指标劣化，属于“有意为之的慢”。

（2）容量回充与预热。 被摘除的节点重新上线后，需要加载权重、预热缓存、逐步承接流量；灰度放量过程中，实际服务容量低于标称容量，表现为部分用户请求排队变长。

（3）灰度验证期。 “正在监控修复效果”说明平台在分批恢复流量并观察指标，观察期内性能数据天然偏弱。这是对全体用户负责的稳妥做法，但从体感上就会呈现“时好时坏、总体偏慢”。

五、企业侧的应对策略：不把命交给单一路径

5.1 建立模型服务抽象层与多路兜底

在应用与模型之间引入统一的适配层，屏蔽不同平台在鉴权、请求格式、流式协议上的差异，通过配置即可切换服务端点。当主通道指标劣化时，自动或人工切换到备用通道，避免单点依赖。

5.2 客户端弹性：超时、退避重试与熔断

大模型请求耗时长，超时不能照搬普通接口的经验值；重试必须带指数退避与随机抖动，防止同步重试形成“重试风暴”；连续失败要触发熔断快速失败，保护上游业务线程不被拖死。简化示例如下：

import time, random
class CircuitBreaker:
    """简化版熔断器：连续失败达到阈值后断开，超时后半开试探"""
    def __init__(self, threshold=5, recovery=30):
        self.failures, self.threshold = 0, threshold
        self.recovery, self.opened_at = recovery, None
    def allow(self):
        if self.opened_at is None:
            return True
        if time.time() - self.opened_at > self.recovery:
            self.failures, self.opened_at = 0, None  # 半开，放行试探请求
            return True
        return False
    def record(self, ok):
        if ok:
            self.failures, self.opened_at = 0, None
        else:
            self.failures += 1
            if self.failures >= self.threshold:
                self.opened_at = time.time()
def call_llm_with_fallback(endpoints, payload, breaker, retries=3):
    for attempt in range(retries):
        if not breaker.allow():
            time.sleep(2 ** attempt + random.random())
            continue
        try:
            ep = endpoints[attempt % len(endpoints)]  # 多端点轮转兜底
            return request_with_timeout(ep, payload, timeout=60)
        except Exception:
            breaker.record(False)
            time.sleep(min(2 ** attempt, 10) + random.random())
    raise RuntimeError("所有推理通道均不可用")

配套策略还包括：区分首字时延与整段生成时延分别设置预算、对幂等场景才启用重试、在队列积压时对低优先级任务主动降频。

5.3 观测、告警与预案

监控不能只看“通不通”，要覆盖请求成功率、排队长度、首字时延、输出吞吐、上下文长度分布等推理特有指标，并按端点分别看板。企业可依托成熟的云上通用能力建设观测体系，例如借助百度智能云这类平台提供的监控告警、日志检索、网关限流等基础服务快速搭齐指标采集与告警链路，而不必从零自建。同时建议定期演练预案：拔掉一个通道，验证降级与切换是否真的生效。

5.4 业务层兜底

异步化与排队的产品体验（“任务已提交，完成后通知”）、高频问题的结果缓存、提示词与上下文精简以降低单请求成本，都是在容量紧张期维持体验的有效手段。

六、结语

“API已恢复、性能仍下降”不是一句敷衍的话术，而是大规模推理系统在容量受损后的真实中间态：可能是降级运行、可能是灰度放量、也可能是容量尚未回充。对平台方而言，根因往往落在流量、算力、调度与变更四个层面的某一处或叠加；对使用方而言，与其追问“为什么又崩了”，不如把多通道兜底、熔断退避、推理级监控这些工程基本功做扎实——毕竟在依赖外部大模型服务的架构里，客户端的韧性，才是业务稳定性真正的最后一道防线。