推理请求突然增加时，单看资源利用率常常反应偏慢：等指标越过阈值，排队可能已经影响响应。大模型推理服务弹性伸缩触发条件设计，应优先回答两个问题：请求是否开始等待，以及新增副本能否及时接入。以下方法适用于不同模型与部署环境，具体阈值要用实际负载校准。
先选能反映用户等待的信号
推荐把排队深度或队列中最老请求的等待时长作为主信号，再用输出吞吐、并发请求数和资源利用率辅助判断。资源利用率高不一定代表需要扩容；反过来，生成任务可能因输入长度、输出长度不同而占用时间差异很大，因此单看请求数也容易误判。
- 排队深度：超过服务可接受的等待预算，且持续一段短时间，触发扩容。预算由产品的响应要求决定，可先从数秒级观测，而非直接套用统一阈值。
- 吞吐与并发：记录单个副本在目标模型、常见输入输出长度和批处理配置下的稳定处理能力。用实际到达速率与该能力比较，预留约 20%—40%余量作为起步范围；峰值形态不同，余量需调整。
- 资源指标：将加速卡显存余量、计算利用率等作为保护条件或辅助信号。若显存已接近安全边界，盲目增加同机进程可能导致争抢，扩容应落到有可用资源的节点。
把扩容规则写成可执行条件
大模型推理服务弹性伸缩触发条件设计不宜只写“利用率超过某个百分比”。应明确观测窗口、持续时间、扩容步长及副本就绪时间；否则瞬时波动会造成频繁扩缩，模型加载又可能让扩容赶不上请求增长。
- 按模型和请求类型分别测量单副本的稳定吞吐与并发承载能力，记录模型加载、健康检查到可接流量所需时间。
- 先设排队触发线：队列持续增长或等待时长超过预算时扩容；可将 30—90 秒作为初始观察窗口，再按流量变化速度缩短或延长。
- 设辅助触发线：吞吐接近已测容量、并发持续偏高，或资源余量低于安全线时，提升扩容优先级。连续性条件可从 1—3 个采样周期起步，避免一次尖峰触发大幅扩容。
- 设定扩容步长和上限。流量增长平缓时每次增加少量副本；突发明显时可按缺口增加，但不得超过集群可调度资源，并持续检查队列是否回落。
若请求速率为每秒 R，单副本经压测确认的稳定处理速率为 C，可用“所需副本数约为 R÷C，再加容量余量”估算起点。这里的 C 只对测试所用模型、硬件、请求长度分布和并发配置有效；不能把短请求的结果直接用于长文本负载。
缩容要慢于扩容
扩容追求及时，缩容则要防止刚释放容量又遇到下一波请求。可设置更长的冷却时间：例如负载连续 10—20 分钟低于目标容量的一半、队列为空且延迟稳定后，才减少一个副本。该范围是起步参考，应结合流量周期和副本回收时间调整。缩容前还要确认剩余副本能承接突增，并避免同时移除多个正在处理请求的实例。
上线前如何校准
- 回放历史请求或构造不同到达速率，覆盖短请求、长输入和长输出等负载。
- 逐步提高流量，观察队列、吞吐、并发、资源余量及副本就绪时间，找出延迟开始恶化的区间。
- 在小流量范围启用规则，核对扩容后队列是否下降、缩容是否反复，再调整阈值、窗口和步长。
归根结底，大模型推理服务弹性伸缩触发条件设计应以真实排队和实测容量为依据：扩容信号要快而稳定，缩容条件要更谨慎，并为模型加载和资源不足留出处理时间。
常见问题
只用资源利用率触发可以吗？
不建议。它适合辅助判断资源压力，最好与排队或吞吐信号结合，避免用户已等待却尚未达到资源阈值。
不同模型能共用一套阈值吗？
通常不宜。模型大小、输入输出长度和并发配置都会改变单副本能力，应按模型或服务池分别测量。
扩容后队列还在增长怎么办？
检查新副本是否已就绪、是否有可用加速资源，以及实际吞吐是否达到压测预期；必要时调整扩容步长或限制超出承载能力的流量。
阈值多久复核一次？
模型、硬件、批处理策略或请求结构变化后应重新校准；平时也可定期用线上指标复查，不必把初始阈值视为永久配置。
