大模型API高并发故障排查与容量治理

一、事件背景：当“服务繁忙”成为高频返回

某日，某大模型平台对外发布公告称其API服务已恢复，但部分服务性能仍有下降，高峰时段部分请求会返回“服务繁忙”类错误，并建议用户在紧急情况下临时切换至其他可用的模型服务作为兜底。随后社区中出现了关于补偿额度的讨论，有用户调侃“要是再返几天用量就真要谢天谢地了”。

这类事件并不罕见。对大模型API而言，“崩溃”往往不是单一进程的彻底挂掉，而是容量水位被击穿后的一系列连锁反应：入口层拒绝、队列积压、超时放大、重试风暴，最终表现为用户侧的报错率上升与延迟飙升。本文不讨论具体厂商的补偿策略，而是从工程视角拆解：一次“服务繁忙”背后，可能有哪些技术原因，以及开发者与企业用户应当如何构建自己的防御体系。

二、“服务繁忙”背后的常见技术成因

1. 推理算力与显存瓶颈

大模型推理对GPU算力的消耗是刚性的。单次请求的算力开销取决于模型参数量、上下文长度、输出长度以及批处理策略。当请求量在短时间内上涨，而算力池无法同步扩容时，最直接的后果就是排队。更隐蔽的问题是显存：长上下文请求会显著抬高单请求的显存占用，导致可并发处理的请求数下降。也就是说，同样的GPU数量，在长文本场景下的有效吞吐会明显低于短文本场景，容量评估若按平均值估算，很容易在长文本高峰时失真。

2. 批处理与调度策略的抖动

为提升吞吐，推理服务通常采用动态批处理（continuous batching）策略：把多个请求拼进同一批次计算，以摊薄单请求成本。但批处理对延迟敏感型业务并不友好——一个请求可能为了“凑批”而等待，也可能因为批次中某个长输出请求而拖慢整批。当流量结构突变（例如大量请求集中在少数几个超长输出任务上），调度器的最优策略会剧烈变化，吞吐与延迟同时恶化，表现为部分服务“性能下降”。

3. 限流与配额设计不合理

很多平台采用多层限流：网关层按QPS限流、租户层按配额限流、模型层按并发数限流。问题常出在限流维度与真实资源不匹配。例如仅按QPS限流，但实际瓶颈是并发推理槽位；或者租户配额是静态的，无法在资源紧张时动态收缩。一旦某一层限流阈值设置过高，压力会穿透到推理层；设置过低，则正常业务被误伤。合理的做法是让限流信号与资源水位挂钩，而非仅依赖请求计数。

4. 重试风暴与级联放大

这是最容易被忽视的放大器。客户端在收到超时或“服务繁忙”后，往往自动重试；若重试策略是固定间隔且无退避，多个客户端会在同一时刻再次打满入口。更糟的是，若上层业务有多个调用方各自重试，一次真实过载会被放大数倍。过载场景下，重试是毒药而非解药，必须配合指数退避、抖动与熔断。

5. 依赖链拥塞

大模型API并非孤立服务，其背后还有鉴权、配额校验、日志埋点、计费、内容安全过滤等依赖。任一环节的延迟上升都会传导到入口。例如鉴权服务抖动会拖慢每一个请求的建立阶段，表现为整体吞吐下降；日志写入阻塞则可能反压主流程。排查时必须把API当作一条链路来看，而非只看推理服务本身。

三、容量评估：从“拍脑袋”到可量化

容量评估不能只看历史均值，而应关注峰值形态与请求结构。建议从三个维度建模：

• 请求结构：统计输入token与输出token的分布（P50/P90/P99），长尾请求往往决定资源上限；
• 并发模型：估算在目标延迟SLO下，单卡可承载的并发请求数，并乘以实例数得到理论容量；
• 水位冗余：为突发流量与故障切换预留冗余，通常建议核心链路保留30%以上余量，而非跑满。

一个简单的容量估算示意：

def estimate_capacity(gpu_count, qps_per_gpu_at_slo, peak_factor=2.0):
    base = gpu_count * qps_per_gpu_at_slo
    # 预留峰值冗余，避免跑满
    return base / peak_factor

这里的qps_per_gpu_at_slo必须通过压测获得，且压测负载应贴近真实token分布，否则估算会严重偏乐观。

四、限流、降级与熔断的协同设计

1. 分级限流

建议按“租户 → 业务线 → 全局”三级设置限流，且阈值与资源水位联动。租户级限流保护单个调用方不挤占他人资源；全局限流保护系统不被击穿。限流算法可选令牌桶（允许一定突发）或滑动窗口（更平滑），关键是指标要可观测、阈值要可热更新。

2. 优雅降级

降级策略应提前定义：例如在高压时缩短最大输出长度、关闭非核心的富化能力、将部分请求路由到更小规格的模型。降级必须由配置开关驱动，并能在分钟级生效，而不是依赖发版。

3. 熔断与退避

客户端侧应实现熔断：当错误率超过阈值时快速失败，避免持续重试拖垮下游；重试务必使用指数退避加随机抖动：

import random, time
def backoff_retry(attempt, base=0.5, cap=8):
    delay = min(cap, base * (2 ** attempt))
    return delay * (0.5 + random.random())

同时，服务端应返回明确的错误码与Retry-After提示，帮助客户端做正确决策。

五、可观测性：先看见，才治得好

过载治理的前提是能快速定位瓶颈。建议至少覆盖以下指标：

• 入口层：QPS、错误率、P99延迟、限流拒绝数；
• 推理层：排队长度、批大小分布、GPU利用率、显存占用、单请求token数分布；
• 依赖层：鉴权/计费/日志等下游的延迟与错误率；
• 业务层：按租户与接口维度的成功率，便于快速识别受影响范围。

告警应围绕SLO设置，例如“P99延迟持续5分钟超过阈值”或“限流拒绝率突增”，避免只监控CPU这类间接指标。

六、应急响应：把故障当流程而非事故

一次过载事件的处置质量，取决于预案是否可执行。建议明确角色与动作：

1. 确认影响面：通过租户维度指标判断是全局过载还是局部热点；
2. 快速止血：提升限流强度、开启降级开关、扩容推理实例；
3. 保护客户端：发布公告并给出建议的重试策略，必要时建议切换备用服务；
4. 复盘：记录时间线、根因与改进项，重点检查容量评估是否失真、限流阈值是否合理、重试是否放大。

七、给开发者的实践建议

对依赖大模型API的业务方而言，不要把可用性完全寄托于单一服务。建议在架构上做到：多供应商抽象层、请求超时与重试策略统一管理、关键链路本地缓存与降级文案、以及对配额与用量的持续监控。这样即使遇到“服务繁忙”，业务也能体面降级而非直接不可用。

总结来说，“服务繁忙”是容量、调度、限流与依赖链共同作用的结果，治理它需要工程手段与流程机制并用。把容量算清楚、把限流做精细、把重试管住、把监控做全，才是应对高并发故障的长期解法。