大模型推理服务弹性伸缩触发条件设计，不能只看请求数或处理器利用率。相同请求量下，输入长度、生成长度和并发情况不同，服务承受的压力也会不同。以下五个信号能帮助定位真正的瓶颈；阈值应先作为起点，再按模型、硬件和延迟目标校准。
一、队列等待时间先于队列长度报警
队列长度容易受请求大小影响：几个长上下文请求，可能比许多短请求更难处理。观察最老请求等待时间或排队时长的分位数，并按模型路由分别统计。若服务目标是快速开始生成，可在排队时间持续消耗可用延迟预算时扩容，而不是等队列明显堆积。
可先在连续多个采样窗口内观察，例如每分钟汇总、连续两三个窗口超过预算的一半至三分之二时触发，再结合新副本就绪时间修正。这里的比例是调试起点，不是通用标准；窗口太短会追逐瞬时波动，太长则容易错过持续拥塞。
二、生成吞吐下降，但到达量没有下降
请求数稳定并不代表负载稳定。输出 token 速率持续走低，且排队等待同步上升，可能意味着解码阶段已成为瓶颈；若输入 token 处理变慢，则更应检查预填充阶段。把输入、输出 token 吞吐与请求到达量放在同一时间轴，能避免只按请求数扩容。
这项信号适合按模型和请求长度分组分析。若吞吐下降同时伴随下游工具调用变慢，增加推理副本未必有效，应先排查依赖服务或网络。
三、KV 缓存压力逼近容量边界
并发会话和长上下文会占用 KV 缓存。观察缓存占用、因缓存不足而被抢占或重算的次数，以及请求被拒绝的记录。缓存压力持续升高时，扩容可能有帮助，但前提是新副本确实有可用设备资源；若每个副本的模型权重已接近单机容量，盲目增加副本可能导致调度失败。
设置前应核对单副本权重、运行时开销与缓存预留，并为加载过程留出余量。缓存指标要与上下文长度、并发量一起看，不能仅凭一个百分比判断。
四、错误率与重试正在放大负载
HTTP 429、5xx、超时和客户端取消可作为过载信号，但重试会制造额外请求，形成“越忙越重试”的循环。把原始请求量与重试量分开统计；若错误上升、队列变长且重试同步增加，扩容之外还应限制重试次数、采用退避等待，并检查限流是否作用于正确的模型路由。
五、扩容请求发出，不等于容量已经到位
新副本可能需要等待资源调度、权重加载和健康检查。观察待调度实例数、启动耗时及就绪状态；若扩容经常晚于拥塞到来，可根据历史启动时间提前触发。若实例反复启动失败，则应先处理资源不足、镜像或模型文件不可用等原因，而不是继续提高期望副本数。
把触发信号变成可执行规则
- 按模型路由、输入长度和输出长度分组，记录排队时间、吞吐、缓存压力、错误率及副本就绪耗时。
- 明确服务延迟目标，确定哪些信号代表用户体验正在恶化，并用连续采样窗口过滤短暂尖峰。
- 先设置扩容规则和冷却时间；缩容采用更长观察窗口，并确认负载回落、错误恢复后再执行。
- 回放历史指标或小范围验证，检查扩容后排队是否改善、错误是否下降，以及新副本是否按预期就绪。
可靠的大模型推理服务弹性伸缩触发条件设计，应同时回答“何时扩”“容量何时可用”和“何时缩”。队列、吞吐、缓存、错误和就绪状态互相印证，通常比单一利用率阈值更能识别真实风险。
常见问题
只用请求并发数触发扩容可以吗？
不建议单独使用。请求长度和生成量差异会改变实际计算与缓存压力，应结合吞吐和排队时间。
为什么扩容后延迟仍没有改善？
可能是副本尚未就绪、瓶颈在下游，或新副本没有获得足够资源。先核对就绪时间与各阶段耗时。
缩容要和扩容使用同一阈值吗？
通常不宜。缩容应使用更长观察窗口或滞回区间，避免流量波动时反复增减副本。
