大模型服务偶发崩溃与性能下降的排查思路

近期，某大模型平台出现了一次网页端与API服务部分中断的事件，官方随后确认相关中断已完成修复，API服务恢复可用，但部分服务性能仍存在一定程度的下降，并处于持续监控之中。这类“先恢复、后降性能”的现象在大型在线推理服务中并不罕见，值得从工程角度做一次系统梳理。本文不针对任何具体厂商做评价，而是以该事件为背景，抽象出大模型服务偶发崩溃与性能退化的通用成因与排查方法，供开发者和企业用户参考。

一、现象拆解：为什么“恢复了但没完全恢复”

在一次典型的服务中断事件中，用户侧通常能观察到几个阶段：

1. 完全不可用阶段：请求大量超时或返回服务繁忙类错误，网页端与API同时受影响；
2. 部分恢复阶段：核心接口恢复响应，但错误率仍高于基线，长尾延迟明显抬升；
3. 性能下降阶段：请求成功率恢复正常，但吞吐量、首Token延迟、生成速度等指标未回到故障前水平。

第三阶段最容易被忽视，却是判断故障是否真正收敛的关键。常见原因包括：故障期间积压的请求在恢复瞬间形成“重试风暴”；为快速止血而临时收紧的限流阈值未及时回调；部分推理节点被隔离后集群整体容量下降；缓存与连接池处于冷态导致命中率偏低。这些因素叠加，会表现为“服务已恢复，但性能仍下降”。

二、可能的诱因分析

1. 流量侧：突发流量与重试放大

大模型服务的特点是单请求资源占用高、耗时长。一旦出现短时错误，客户端SDK或业务层的自动重试会在短时间内将请求量放大数倍。若重试策略缺少指数退避与抖动，恢复瞬间的流量峰值可能超过故障前水平，直接压垮刚恢复的推理集群。这是“恢复后再次抖动”的最常见原因之一。

2. 接入层：网关与限流组件瓶颈

API网关承担鉴权、配额校验、路由与限流职责。当并发连接数激增时，网关自身的连接池、线程池或配额计数服务可能成为瓶颈。若限流规则基于固定阈值而非自适应速率，故障期间的规则调整若未同步回滚，就会出现“后端已扩容、入口仍限流”的错配。

3. 推理侧：GPU资源争抢与调度抖动

推理集群通常按模型副本划分资源池。故障处置过程中常见的操作包括隔离异常节点、迁移副本、临时扩容。这些操作会引发调度抖动：新副本加载模型权重需要时间，期间该副本不可用或处于慢启动状态；被隔离节点的在途请求需要重新路由，造成长尾延迟。若集群缺少足够的冗余容量，整体吞吐就会下降。

4. 变更侧：发布与配置回滚不彻底

很多故障由变更引发。快速止血通常采用回滚，但回滚往往只覆盖主版本，配置项、特性开关、缓存参数等可能残留。例如为缓解故障临时关闭了某类缓存，恢复后未重新开启，就会导致后端压力持续偏高，表现为性能下降。

5. 依赖侧：存储与外部服务冷态

会话上下文、向量检索、日志上报等依赖组件在故障期间可能积累大量待处理数据。恢复后这些组件需要追赶处理，占用带宽与连接资源，间接拖慢主链路。连接池与DNS缓存的冷启动同样会抬高首请求延迟。

三、可落地的排查路径

建议按“入口—编排—推理—依赖”的顺序逐层定位，每层都设置明确的判断指标：

入口层：QPS、错误率、P99延迟、限流触发次数、重试请求占比
编排层：队列深度、排队时长、路由失败率、副本可用数
推理层：GPU利用率、显存占用、批处理大小、首Token延迟、生成TPS
依赖层：缓存命中率、连接池等待时长、外部调用超时率

排查时的关键动作包括：

• 对比基线：将当前指标与故障前7天同时段基线对比，而不是与绝对阈值对比；
• 区分错误类型：区分“被限流拒绝”与“后端超时”，前者说明入口策略有问题，后者说明推理侧容量不足；
• 观察重试比例：若重试请求占比显著升高，优先治理客户端重试策略；
• 检查配置快照：核对故障前后所有变更项是否完整回滚，包括特性开关与缓存参数；
• 验证副本健康：确认所有副本均已完成模型加载并进入就绪状态，避免“假就绪”。

四、治理建议：从应急到常态化

1. 容量冗余与弹性伸缩：为推理集群保留一定比例的突发容量，扩容策略应基于队列深度与延迟而非仅CPU/GPU利用率；模型加载慢启动问题可通过预热池缓解。
2. 自适应限流与分级降级：入口限流应采用基于并发度或延迟的自适应算法，并预设分级降级方案，例如在高负载时优先保障短输出请求、限制超长上下文请求。
3. 重试治理：客户端统一采用指数退避加随机抖动，设置重试预算；服务端通过请求ID做幂等与去重，避免重试风暴。
4. 变更管理：所有配置项纳入版本管理与灰度发布，回滚清单需覆盖配置与开关，回滚后自动校验关键指标是否回到基线。
5. 可观测性建设：打通请求级追踪，确保能从单条慢请求追溯到网关、编排、推理节点与依赖调用；对首Token延迟、生成速度等大模型特有指标建立独立看板。
6. 故障演练：定期进行节点隔离、副本迁移、限流触发等场景的演练，验证降级路径与恢复时长，避免真实故障时才发现策略失效。

五、小结

大模型服务的稳定性问题，往往不是单点故障，而是流量、接入、推理、依赖多个层面耦合的结果。“服务已恢复但性能仍下降”提示我们，故障收敛的判断标准不能只看可用性，还要看性能指标是否回归基线。对开发者而言，理解这些通用成因并提前建设容量冗余、自适应限流、重试治理与可观测性能力，比事后追责更有价值。对于企业用户，建议在选型与架构设计阶段就将降级方案与多通道备份纳入考量，以降低单一服务波动对业务连续性的影响。