大模型服务中断频发：从一次API故障看稳定性治理

一、事件背景：为什么“修好了”不等于“完全恢复”

某大模型平台在月初出现网页端与API服务部分中断，官方状态页随后更新称已完成修复并进入监控阶段，但同时提示“部分服务性能仍下降”。这类表述在近两年的大模型服务故障通告中非常典型：故障修复（incident resolved）与性能恢复（performance restored）是两个不同阶段。

对开发者而言，真正影响业务的是后者。API返回200不代表链路健康——延迟抖动、吞吐下降、超时率上升、流式输出中断，都会直接传导到上层应用的用户体验。因此，理解“已恢复但性能下降”的成因，比关心单次故障本身更有长期价值。

从公开信息与行业共性来看，这类高频迭代平台的服务中断，往往不是单点 bug，而是容量、依赖、发布流程与可观测性四类因素叠加的结果。下文逐层拆解。

二、典型成因分析

2.1 容量过载：需求侧弹性远大于供给侧弹性

大模型服务的显著特征是“价格与速度具备竞争力时，流量会在短时间内非线性涌入”。推理服务的扩容并非无状态 Web 服务那样简单：

• GPU 资源池扩容存在分钟级到小时级的交付延迟，涉及调度、镜像拉取、模型权重加载与预热；
• 模型权重加载本身消耗大量显存带宽与主机 IO，冷启动期间实例不可用或性能极差；
• 新实例加入后需要经过预热（warmup）才能达到稳定吞吐。若预热不充分，请求会被分配到“尚未热透”的实例，表现为首包延迟（TTFT）显著升高。

因此，当流量峰值超过预留容量时，系统会先进入排队—超时—重试放大的恶性循环：客户端超时重试进一步推高入站 QPS，形成正反馈式的拥塞崩溃。这是“服务太忙”类报错最常见的根因。

2.2 限流与排队策略：保护系统还是放大抖动

限流是必要手段，但策略设计不当会带来次生问题：

• 全局限流 vs 租户级限流：全局令牌桶能保护后端，但会让少数高并发租户挤占多数用户配额；租户级隔离更公平，但实现复杂度高。
• 排队队列长度：队列过长会把超时压力后移，客户端已放弃的请求仍在服务端消耗算力，造成“无效计算”挤占有效容量。
• 重试语义：若服务端对可重试错误返回过快，客户端激进重试会瞬间放大流量。合理的做法是配合指数退避与抖动（jitter），并在服务端返回明确的 Retry-After 提示。

2.3 依赖组件劣化：推理链路上的“隐性单点”

一次对话请求往往串联多个组件：网关鉴权、配额与计费、请求路由、推理调度、向量检索（如启用 RAG）、日志与计量上报。任一环节劣化都会表现为“整体变慢”：

• 元数据存储或配置中心抖动，导致路由决策变慢；
• 计量与日志上报采用同步写，峰值时反压主链路；
• 缓存层击穿，热点系统提示词或会话状态频繁回源。

这类问题的迷惑性在于：主推理服务指标正常，但端到端 P99 延迟恶化。排查时必须具备全链路追踪能力。

2.4 发布与回滚不彻底：灰度残留与配置漂移

高频迭代平台的发布节奏快，风险随之上升：

• 灰度发布只回滚了镜像版本，未回滚关联的配置项与开关，导致新旧逻辑混跑；
• 模型服务版本与服务框架版本存在兼容矩阵，回滚时版本错配引发性能退化；
• 连接池、线程池参数随发布变更但未纳入版本管理，形成“配置漂移”。

“API 已恢复但性能仍下降”很可能对应此类场景：功能路径已通，但性能相关配置尚未回到基线。

2.5 可观测性盲区：监控覆盖不到的地方就是故障藏身处

若监控只覆盖可用性（成功率）而不覆盖饱和度与延迟分位，就会出现“一切正常但用户很慢”的割裂。建议至少建立以下指标体系：

• 请求侧：QPS、TTFT、TPOT（每输出 token 耗时）、端到端 P50/P95/P99；
• 资源侧：GPU 利用率、显存占用、批处理队列深度、KV Cache 命中率；
• 依赖侧：各下游依赖的成功率与延迟分位；
• 业务侧：限流触发次数、重试率、超时率、降级开关状态。

三、面向开发者的韧性实践

3.1 客户端侧：超时、退避与熔断

不要把重试写成固定间隔的循环。推荐带抖动的指数退避，并对不可重试错误快速失败：

import random
import time
RETRYABLE = {429, 500, 502, 503, 504}
def call_with_backoff(fn, max_attempts=5, base=0.5, cap=8.0):
    for attempt in range(max_attempts):
        try:
            return fn()
        except Exception as e:
            status = getattr(e, "status_code", None)
            if status not in RETRYABLE or attempt == max_attempts - 1:
                raise
            delay = min(cap, base * (2 ** attempt))
            time.sleep(delay + random.uniform(0, delay * 0.5))

配合熔断器：当错误率超过阈值时快速失败一段时间，避免把故障期流量持续压向已过载的服务。

3.2 应用侧：降级与多级模型路由

• 能力降级：非核心场景（如摘要、改写）在故障期切换到更小、更快的模型或关闭流式输出；
• 功能降级：暂时关闭 RAG 检索、工具调用等重链路能力，仅保留纯生成；
• 结果缓存：对相同或相似请求做语义缓存，故障期提高命中率以削减后端压力；
• 异步化：把非实时任务迁移到消息队列削峰，避免与交互式请求争抢配额。

3.3 架构侧：隔离与容量规划

• 按业务线划分租户配额与资源池，避免单一业务打满全局容量；
• 预留突发容量（burst capacity），并明确其触发条件与上限；
• 对关键依赖设置独立线程池/连接池，防止级联阻塞；
• 定期进行容量压测与故障演练（如注入下游延迟、模拟限流），验证降级路径真实可用。

四、小结

大模型平台的服务中断之所以“频发”，本质上是因为其系统同时具备重资源、快迭代、强弹性需求三重特征，任何一个维度的失衡都会外化为可用性或性能问题。“API 已恢复、部分性能仍下降”通常意味着功能链路已通，但容量水位、依赖质量或配置基线尚未回归。

对开发者而言，可行的策略是把不确定性当作常态：在客户端做好超时、退避与熔断，在应用层设计多级降级与缓存，在架构上落实隔离与容量规划，并以全链路可观测性支撑快速定位。这样即使上游出现波动，业务侧也能把影响控制在可接受范围内。