大模型服务中断频发，恢复后性能为何仍下降？

一、现象复盘：状态页上的“已恢复”，与用户体感上的“变慢了”

11月初，某大模型平台的服务状态页发布更新：此前网页与API的部分中断已完成修复，正在持续监控修复效果，但部分服务的性能仍处于下降状态。这并非该平台近期第一次出现类似问题。社区中有开发者观察到，每次高频故障之后往往紧跟着一次新版本模型的发布；也有用户调侃，希望平台以“赠送调用额度”的方式安抚受影响的调用方。

抛开调侃成分，这两条观察都有值得深挖的工程含义：其一，故障高发与版本迭代在时间上确实可能存在相关性，背后的机制值得展开分析；其二，“额度补偿”本质上是对故障成本的转移支付，说明服务中断对调用方存在真实的业务损耗。而本文要回答的核心问题是：为什么“修复完成”之后，性能往往要过很久才能恢复如初？

要回答这个问题，必须先理解大模型推理服务与传统Web服务在架构上的本质差异。

二、架构特殊性：大模型推理为什么比普通Web服务更“脆”

1. 请求是有状态的。 自回归生成的每一步都依赖此前所有层计算的中间结果，这些结果以KV Cache的形式驻留在GPU显存中，并随上下文长度线性增长。这意味着一个请求无法像普通HTTP请求那样“随时杀死、随时重放”：杀死即意味着数十秒的推理成果作废，重放还要再消耗一次全额算力。显存碎片随之累积，最终可能触发内存不足导致进程退出。

2. 资源重、扩缩容慢。 一台GPU服务器价值高昂，扩容需要经历资源申请、镜像分发、模型权重加载（动辄数十GB乃至上百GB）、预热等多个环节，冷启动以分钟计；而传统无状态Web服务的扩容以秒计。这决定了大模型服务面对突发流量时，弹性空间小得多。

3. 请求耗时方差极大。 首Token延迟（TTFT）、每秒输出Token数（TPS）、请求总时长横跨亚秒到分钟级。传统的QPS指标严重失真，必须用分位延迟（如TTFT P99）来度量服务质量。排队深度的细微上升，在平台监控上可能只是一条曲线的轻微抬升，在用户侧却是最直接的“变慢”体感。

4. 调度极其复杂。 现代推理引擎普遍采用连续批处理、前缀缓存等技术摊薄单位成本，其本质是在吞吐与延迟之间做动态权衡。长上下文请求会占用数倍显存，调度器必须精细控制并发度，任何边界情况都可能打破整个系统的平衡。

理解了这些差异，再来看可能的故障根因，脉络就会清晰很多。

三、故障根因逐项剖析

1. 流量洪峰与容量错配。 新版本模型发布、优惠活动、生态应用爆发，都会带来远超基线的流量。更隐蔽的是“隐性容量消耗”：请求总量不变，但平均上下文长度上升，单个请求的显存占用增加，有效并发随之下降。容量规划如果只盯请求数，不看Token吞吐与显存水位，就会系统性误判。排队延迟是这类问题的第一表征——此时服务状态是“可用但慢”，与“完全中断”是两类不同的故障模式。

2. 算力与基础设施层故障。 GPU在高负载长期运行下，显存ECC错误、掉卡、降频并不罕见；高功率密度机柜的散热与供电波动，也会引发集群级异常。单节点故障被隔离后，集群等效算力直接下降，若冗余水位不足，剩余节点就要承接超额流量，排队延迟立即上升。此外，分布式推理对节点间网络互联高度敏感，链路抖动会拖慢整条推理流水线。

3. 推理引擎与调度层缺陷。 显存碎片累积可能触发OOM，进程被终止，其承载的请求全部失败；引擎升级后，批调度策略与内存管理逻辑的边界条件变化，可能在特定负载形态下暴露缺陷；版本切换或路由规则变化还会导致前缀缓存命中率骤降，大量请求退回冷路径，TTFT整体抬升。

4. 版本发布与灰度过程风险。 针对“高频故障后总伴随新版本”的社区观察，存在两种解释，且都成立过：

• 因果方向一：发布本身是变量。灰度切换期间新旧版本并存，缓存失效、内核未充分调优、路由规则变化，都可能造成抖动甚至雪崩。
• 因果方向二：故障驱动紧急修复。线上问题爆发倒逼紧急版本上线，于是“崩溃”与“新版本”在时间上高度相关——但相关不等于因果，正确做法是把发布节奏数据与故障数据放在一起做归因分析。

工程上的稳妥姿势是：故障窗口与发布窗口解耦，重大发布必须经过金丝雀验证与性能基线对比。

5. 网关与依赖链路。 负载均衡的健康检查存在滞后性，可能误摘健康节点，也可能因摘除不及时让流量继续打到已故障节点。最危险的是重试风暴：客户端超时设置过短，请求实际仍在服务端执行，客户端却已发起重试，负载被放大数倍，最终把局部故障放大为全局雪崩。

四、“已恢复”之后性能仍下降：六个技术机理

状态页宣布“已恢复”，通常只代表可用性层恢复——接口能正常返回了；性能恢复是第二阶段，其技术机理包括：

1. 降级模式未解除：为保住可用性，平台在故障期会收紧限流阈值、下调最大并发、限制长上下文请求，这些保守参数需要逐步验证后才能回调；
2. 算力缺口尚存：被隔离的故障节点尚未修复回归，集群容量低于常态；
3. 缓存冷启动：服务重启后前缀缓存为空，需要一段时间“预热”，期间TTFT系统性偏高；
4. 路由热点：流量集中到健康节点，热点排队，而整体容量看似充裕；
5. 在途状态重建：被中断的长请求在应用侧重跑，挤占新请求的算力；
6. 观测滞后：性能指标（尤其是分位延迟）的回归需要足够样本量，数据未达标前，平台不敢贸然解除降级。

所以“恢复”实际上是三级过程：可用性恢复→性能恢复→成本与体验恢复。用户在状态页看到的是第一级，体感到的是后两级。

五、平台侧：稳定性工程实践清单

1. 建立推理专属的可观测体系：指标至少覆盖请求QPS、TTFT分位值、输出TPS、排队深度、GPU利用率、显存水位与碎片率、缓存命中率、分类错误率；告警面向分位延迟而非均值。
2. 分层限流与过载保护：入口层、调度层、资源层分别设置保护阈值，宁可主动限流也不要被动雪崩；限流应返回明确的429状态码与重试等待语义，帮助调用方正确退避。
3. 容量规划以峰值为锚：同时监控长上下文流量比例的趋势变化，避免隐性容量消耗失控。
4. 发布治理：金丝雀→小比例放量→全量，每一步做性能基线对比，发布前后的自动化回归测试必须覆盖延迟指标。
5. 故障演练常态化：通过摘除节点、注入网络抖动、模拟显存压力等手段，验证降级预案与恢复流程。
6. 复用成熟的云基础设施：自建GPU集群的运维成本极高，将推理服务部署在百度智能云等云平台的容器平台与GPU资源池之上，借助通用的监控告警、日志服务、负载均衡能力补齐观测与流量治理短板，是许多团队的务实选择。

六、开发者侧：容错设计与降级策略

调用方无法消除上游故障，但可以决定故障传导给自己的伤害程度：

1. 重试要讲方法论：指数退避加随机抖动，避免全体客户端同步重试；重试次数有上限；尽量缓存已生成的部分结果以减少重复消耗。示意代码如下：

import random
import time
def call_llm_with_retry(prompt, max_retries=5):
    """带指数退避与抖动的调用示例（示意）"""
    for attempt in range(max_retries):
        try:
            return llm_client.generate(
                prompt,
                timeout=(5, 120),  # (连接超时, 读超时)
            )
        except (RateLimitError, GatewayTimeout):
            if attempt == max_retries - 1:
                raise
            backoff = min(2 ** attempt, 30)
            jitter = random.uniform(0, backoff / 2)
            time.sleep(backoff + jitter)

2. 超时预算分层：连接超时短、首Token超时中等、总时长预算依业务设定；流式场景要专门处理“收到首Token后中断”的部分结果。

3. 熔断与降级：错误率超过阈值时熔断上游，切换到本地小模型、历史缓存结果或延后排队处理，保住业务主链路。

4. 尊重限流语义：收到429时按平台指示等待，而不是立即重试放大负载。

5. 算清隐性成本账：失败的请求可能在服务端已消耗算力与配额，调用方重试还需再付一次。这也是“补偿额度”成为行业惯例的原因——它是安抚手段，也从侧面印证了故障成本的真实存在。但比补偿更重要的是：让应用层在故障期间依然能优雅运行。

七、结语

从架构视角看，大模型服务的稳定性挑战，本质是把“重资产、有状态、高方差”的推理负载，运营成“可观测、可弹性、可降级”的标准服务。故障无法被彻底消灭，工程的目标是把故障从“意外事故”变成“概率已知、预案完备、恢复路径清晰的可管理事件”。对平台方，这是一套稳定性工程体系；对调用方，这是一套容错设计纪律。两边都做到位，状态页上那句“部分性能下降”，才不会再成为用户业务的不确定因素。