大模型服务持续“系统繁忙”：从架构、调度到限流降级的完整排查指南

一、问题不只是“用户太多”

大模型服务在高并发时段频繁出现“系统繁忙”或请求被拒绝，从表面看是流量过大、资源不足，但实际处理时，往往涉及多个层次的叠加因素。只把问题归结为“机器不够”，会掩盖真正影响稳定性的结构性问题。

一个典型的现象是：服务在流量平稳时表现正常，一旦突发流量进入，错误率迅速上升，且恢复时间明显拉长。这说明系统并非处于线性过载状态，而是在某些关键路径上出现了非线性退化。

要理解这一点，需要先区分两类资源瓶颈：

• 算力型瓶颈：推理集群整体利用率接近上限，所有请求都被拖慢。
• 结构型瓶颈：集群整体尚有富余，但某些局部节点或模块先被打满，造成请求排队、超时和失败。

大量线上故障属于第二类，而不是第一类。因此，仅靠增加硬件往往只能缓解一时，无法根除问题。

二、需求增长与供给扩张之间的“剪刀差”

大模型服务的需求增长曲线通常比算力供给曲线更陡。用户规模可能在数月内增长超过五成，而算力储备的增幅往往只有个位数。当两条曲线之间的缺口持续扩大，系统会在高峰期出现明显过载。

这种“剪刀差”带来几个值得关注的后果：

1. 高峰期负载远高于平均负载。如果以日均利用率评估容量，很可能低估峰值压力。
2. 调度余量被快速消耗。原本用于吸收突发流量的缓冲空间，在持续增长的需求面前被不断压缩。
3. 故障恢复窗口变短。上一次扩容带来的余量，很快被新增流量吃掉，故障间隔越来越短。

因此，容量规划不能只看平均指标，还要结合峰值并发、请求耗时分布和排队长度进行综合评估。

三、推理架构层面的“局部拥堵”

服务端推理在架构上并非均匀消耗算力。某些模型结构会放大流量不均的影响，让局部节点先于整体达到瓶颈。

以常见的稀疏激活式大模型为例，其设计思路是：模型总体规模很大，但每次推理只激活其中一部分计算单元。这样做可以降低平均推理成本，但也带来了新的调度问题。

关键点在于：每次请求激活哪些计算单元，由输入内容动态决定，而不是预先固定分配。 这意味着不同请求对底层资源的消耗存在差异。即使总请求量相同，只要请求内容分布发生变化，资源热点也可能随之转移。

在并行推理场景中，这种不均会表现为：

• 同一层内，不同计算卡处理的请求数量存在明显差别。
• 某些计算卡在短时间内处理了远高于平均值的请求量。
• 热点卡会频繁变化，难以通过静态配置固定下来。

由于并行推理通常需要层内同步——即每一层结束后等待最慢的计算单元——只要有一张卡过载，整体延迟就会被拖高。流量平稳时，调度器尚有空间消化这些差异；流量一大，局部偏斜被迅速放大，形成“局部拥堵—全局抖动”的连锁反应。

这也解释了为什么扩展整体算力后，问题未必消失：瓶颈不是总资源不足，而是资源分布与请求特征之间的匹配精度不够。

四、限流、熔断与降级设计的不足

理想情况下，当某个模块过载时，系统应该优先保护核心链路，而不是让全部请求一起失败。可现实中的系统往往做不到这一点，原因主要有三方面：

1. 熔断粒度不够细

很多服务的熔断策略只到“整个推理服务”或“整个集群”级别。一旦触发熔断，所有请求都会被拒绝。更合理的做法是把熔断粒度下沉到模块、模型分片或计算单元级别，只隔离真正过载的部分。

2. 限流触发滞后

如果限流阈值设置过高，或者统计窗口过长，系统可能在高负载已经形成之后才开始限流。此时排队请求已经大量堆积，后续请求的失败率会迅速上升。

3. 降级通道不完善

部分服务在过载时缺少可用的降级路径，例如：

• 切换到更小的模型实例
• 缩短最大生成长度
• 返回缓存结果或预生成结果
• 降低采样复杂度

没有这些降级手段，系统只能“硬扛”，最终导致全局不可用。

五、低价策略如何放大洪峰

免费或低定价会显著改变用户调用行为。当调用成本几乎可以忽略时，用户不会主动优化请求频率和Token消耗，一些高消耗用法会快速增长，例如：

• 长文本反复生成与调试
• 批量任务自动重试
• 高频Agent调用
• 大量无关测试请求

这些行为在正常定价下可能被成本约束，但一旦价格降到极低水平，调用量可能出现数量级增长。此时如果扩容节奏跟不上，洪峰高度会被进一步推高。

低价本身不是问题，问题在于：价格策略启动需求侧变化的速度，通常快于算力供给侧的建设速度。 这种时间差会加剧容量缺口。

六、可行的排查与优化路径

面对大模型服务的“系统繁忙”，建议从以下几个方面系统排查：

1. 建立分层监控

至少需要监控四个层面：

• 接入层：请求量、错误率、限流触发次数
• 调度层：排队长度、等待耗时、分发均衡度
• 推理层：单卡利用率、单卡请求量、层内同步耗时
• 业务层：端到端延迟、超时率、用户重试行为

通过分层监控，可以判断故障是从哪一层开始蔓延的。

2. 分析请求分布与热点

统计不同时间段、不同输入类型下的资源消耗分布。如果发现某些请求集中在少数计算单元上，说明调度策略需要调整。

可以考虑将请求先进行轻量分类，再根据分类结果分发到不同实例组，减少资源竞争。

3. 优化限流与降级策略

限流阈值应该动态调整，而不是固定不变。可以根据实时排队长度和推理耗时，逐步收紧或放松流量。

降级策略需要提前设计，例如：

• 高峰期自动切换至更小的模型版本
• 对长文本请求限制最大长度
• 对重试请求进行退避处理
• 对非核心请求返回缓存结果

4. 调整容量规划方式

容量规划应基于峰值并发和P99延迟，而不是只看平均利用率。同时需要预留足够的缓冲空间，以吸收突发流量。

对于增长快、波动大的服务，可以考虑按“周”级别滚动评估容量，而不是等出现明显故障后再扩容。

七、总结

大模型服务频繁出现“系统繁忙”，通常是多种因素叠加的结果：需求增速超过供给、推理负载不均、熔断限流不够灵活、低价策略放大峰值。单纯增加硬件只能解决一部分问题，真正的改善需要从架构调度、监控体系、弹性降级和容量规划入手。

对于开发者来说，最有效的方法是先把监控数据补齐，搞清楚问题到底出在哪一层，再针对具体瓶颈制定优化方案。否则，每一次扩容可能都只是把下一次故障的时间点向后推迟而已。