大模型推理服务弹性伸缩触发条件设计，重点不是找到一个适用于所有模型的 GPU 利用率数字，而是判断请求是否正在排队、延迟是否接近服务目标，以及新实例能否及时接手流量。只依赖 GPU 利用率，可能在短时波动时反复扩缩，也可能等到用户延迟升高后才扩容。
先用延迟目标确定扩容信号
先明确服务的延迟目标，例如首令牌时间（TTFT）和请求完成时间的分位数目标，再观察正常负载下的基线。监控至少包含请求到达率、并发数、排队时延、错误率、GPU 利用率和实例启动耗时。GPU 利用率说明设备忙不忙，却不能单独说明服务是否过载：批处理策略、输入长度和生成速度都会改变它与延迟的关系。
更稳妥的扩容判断是组合信号：排队时延持续上升，或待处理请求数超过经压测确认的单实例承载范围，同时延迟逼近目标，就增加副本。可将排队时延达到延迟预算的约一半至三分之二作为初始观察线；具体比例应按流量突发程度和扩容耗时校准，而非直接作为通用标准。
把阈值变成可执行规则
- 测出单实例能力。在接近真实请求分布的条件下逐步增加并发，记录延迟、吞吐和错误率，找出延迟明显恶化前的稳定区间。模型、硬件、请求长度和批处理设置不同，容量也会不同。
- 设定扩容目标。优先用排队时延、待处理请求数或并发数等直接反映积压的指标。以 GPU 利用率作辅助时，可先把持续数分钟处于约 65%—75% 作为候选扩容线，再结合压测结果调整；短暂尖峰不宜立即触发扩容。
- 设定缩容保护。缩容线应明显低于扩容线。例如，负载连续约 10—20 分钟低于容量目标的 30%—40%，且队列为空、延迟稳定，才考虑减少副本。这些时间和比例只是起始范围，需结合流量周期及实例回收风险验证。
- 限制变化速度。每轮只增加或减少有限副本，并为扩缩容设置冷却窗口。冷却时间至少覆盖指标观察周期和实例启动耗时；若模型加载较慢，应优先保留预热实例，避免流量先到、容量后到。
用滞回、预热和容量边界防止抖动
扩容阈值高、缩容阈值低，形成滞回区间；再用持续时间过滤短促波动，比让同一个阈值同时控制增减更稳定。Kubernetes HPA 可按 CPU 等指标扩容，但推理服务常需把队列或延迟指标接入自定义指标链路；采用 Prometheus 时，应确认采集间隔、指标聚合方式和控制器读取延迟一致，否则看似精确的阈值也会滞后。
同时设置最小与最大副本数：最小值覆盖常态底流量和必要的预热需求，最大值受 GPU 配额、可用实例数及预算约束。缩容前检查在途请求，采用优雅摘除，让现有请求完成后再回收实例。若流量存在可预测的日内高峰，可提前增加预热容量；突发流量则依靠队列保护、限流或拒绝过载请求，弹性伸缩不能替代过载控制。
上线后按事件复核
每次触发都记录触发指标、扩缩副本数、实例就绪时间以及延迟变化。若扩容后队列仍上升，可能是新增实例启动慢、单实例能力估计偏高，或瓶颈在模型加载与依赖资源；若频繁缩容后又扩容，应拉长缩容观察期、扩大滞回区间，或提高最低副本数。大模型推理服务弹性伸缩触发条件设计应随实测结果迭代，而不是一次定值后长期不变。
常见问题
只按 GPU 利用率扩容可以吗？
不建议。它适合作为辅助信号，应同时检查队列、延迟和错误率。
扩容后为什么延迟没有马上下降？
新实例可能仍在启动或加载模型；测量从触发到就绪的时间，并配置适量预热容量。
资源闲置时应先降最低副本吗？
先确认低负载是否持续、缩容后是否容易触发回扩，再调整最低副本和缩容等待时间。目标是在成本与延迟风险间取得平衡。
归根结底，大模型推理服务弹性伸缩触发条件设计要以服务目标和压测容量为依据，用直接的积压信号扩容、用更严格的条件缩容，并以冷却和预热减少抖动与闲置。
