弹性伸缩与成本优化

弹性伸缩 = 推理/训练集群按实时负载增减 GPU 副本,是成本与延迟的平衡阀。三个核心信号: ① QPS(每秒请求数)——最直观但最滞后,不能反映单请求负载差异(1 token 与 1K token 的请求都是 1 QPS);② 队列长度/排队延迟——最直接反映过载,队列积压说明副本已吃不下,比 QPS 更适合触发扩容;③ GPU 利用率——健康区通常定为 70-90%:低于 70% 说明 GPU 闲置、钱花在空转上,高于 90% 意味着排队延迟开始非线性飙升、抖动加剧。实现上,推理服务用 K8s HPA(HPA 支持自定义指标,扩缩容冷却 cooldown 防止抖动)或 Ray autoscaler;训练集群按队列积压任务数伸缩。成本侧: ① Spot 实例——比按需便宜 60-90%,但可能被回收(回收前约 2 分钟预警),适合无状态、可中断、可重试的负载(批处理推理/训练),关键在线服务用 spot + 按需混合池;② 预留实例/承诺用量换取折扣;③ 利用率监控 + off-peak 批处理把闲时填满。

任何有波动的线上服务(白天峰值/夜间低谷、热点事件突发);训练集群的队列伸缩;面试高频“用哪些指标做扩缩容”“GPU 利用率多少合适”“怎么用 spot 省钱”。

固定部署要么峰值过载(排队、超时、丢请求),要么低谷空转(60% 以上时间 GPU 利用率不足 50%,成本浪费)。按队列长度/利用率伸缩把副本数贴着负载走,再叠加 spot 与预留策略,同等 SLA 下成本可降一半以上——核心权衡是扩容延迟(冷启动/镜像拉取)与过载风险。

伸缩指标选型: QPS、队列长度/排队延迟、GPU 利用率各自的优劣;为什么队列积压比 QPS 更适合触发扩容(请求负载不均)?

GPU 利用率为什么定在 70-90%: 低于 70% 空转浪费、高于 90% 排队延迟非线性飙升;目标值与延迟预算如何挂钩?

扩缩容实现: K8s HPA 自定义指标与 cooldown 防抖动;扩容的冷启动延迟(镜像拉取/模型加载)如何缓解(预热池/预加载模型)?

Spot 实例: 为什么能便宜 60-90%,回收机制(约 2 分钟预警)是什么;哪些负载适合 spot,在线服务如何用 spot + 按需混合池保证 SLA?

成本优化组合拳: spot、预留实例、利用率监控、off-peak 批处理如何叠加;一次完整的成本优化流程从哪一步开始?