第 113 题：推理服务的auto-scaling策略？基于GPU利用率还是请求队列？
题目
推理服务的auto-scaling策略？基于GPU利用率还是请求队列？
完整讲解
一、基于 GPU 利用率的扩缩容
思路：监控实例的 GPU 利用率（如 nvidia-smi、DCGM）；当 均值或 P95 高于阈值（如 80%）时 扩容，低于某阈值（如 30%）时 缩容。优点：直接反映「算力是否吃满」。缺点：利用率高可能来自 少量大请求，此时扩容未必改善延迟；利用率低可能是 请求少 或 batch 未填满，缩容可能增加排队。适用：吞吐优先、负载较平稳时；需设上下界与冷却时间，避免抖动。
二、基于请求队列的扩缩容
思路：监控 排队长度 或 等待时间；队列超过某长度或等待时间超过 SLA 时 扩容，队列空且持续一段时间后 缩容。优点：与 延迟/SLA 直接相关，更贴近「用户等多久」。缺点：需暴露队列指标、与负载均衡配合；短时尖峰可能触发过度扩容。适用：延迟敏感、有明确 SLA 时；常与 最大排队长度、超时 配合。
三、策略组合与建议
- 混合：队列为主（保证延迟），利用率为辅（避免空跑过多实例）；例如「队列深度 > N 或 P99 超 SLA 则扩容」「利用率持续低且队列空则缩容」。
- 预热与冷却：扩容后新实例需 warmup 再接流量；缩容前设 cooldown，避免刚缩又扩。HPA/KEDA 等可根据 queue length、GPU 利用率、自定义 metric 做扩缩容；推理服务常用 队列深度 + 延迟 作为主指标，GPU 利用率 作参考与成本控制。
面试要点
- GPU 利用率：反映算力是否吃满；高则扩容、低则缩容；易受少数大请求影响，需防抖动。
- 请求队列：反映等待与 SLA；队列长或超时则扩容，更贴近延迟目标。
- 建议：队列/延迟为主、利用率为辅；配合 warmup、cooldown 与 HPA/KEDA。
记忆要点
- 利用率 = 算力维度；队列/延迟 = 用户体验维度。
- 延迟敏感以队列为主；吞吐/成本以利用率为参考。
- 扩缩容需 warmup 与 cooldown，避免抖动。