一、伸缩到底在解决什么

（一）固定规格与峰谷之间的矛盾

多数团队的算力需求不是一条直线。发版前集中训练、季度末集中跑批、临时插入的试验，都会让用量在几天内翻几倍。按峰值常备，低谷期大量资源空转；按均值配置，高峰期任务排队，进度受影响。伸缩就是在这两者之间找一条跟着需求走的曲线。

（二）扩容延迟带来的空窗

扩容不是瞬间完成的，从发出请求到新资源可用，中间有几分钟到十几分钟的空窗。这段时间里请求仍在涌入，队列会积压。所以阈值不能只看当前用量，还要把空窗期内预计新增的量算进去，提前触发。

二、三类触发信号

（一）利用率信号

利用率是最直观的信号，通常取显卡利用率和显存占用两个指标。问题在于利用率是瞬时值，一个短任务就能把它顶得很高，然后马上回落，只看单点会频繁误触发。做法是用连续采样窗口，比如连续若干个采样点都超过阈值才动手。

（二）队列长度信号

队列长度比利用率更贴近体验：任务在排，说明资源确实不够。以积压条数或预计等待时间为触发条件，反应更快也更准。需要注意的是，队列积压有时是调度策略造成的，不一定是资源总量不足，两者要分开看。

（三）时延信号

响应时延是最终体验指标，适合作为兜底信号。当时延连续超过设定值时触发扩容，可以减少前面两类信号漏掉的情况。时延受网络、数据读取等多个因素影响，单独用它容易误判，和其他信号一起用更稳。

① 利用率类信号配连续采样窗口，过滤瞬时抖动。

② 队列类信号直接按积压条数触发，反应最快。

③ 时延类信号放在最后一层，作为前面两类没有覆盖到时的兜底。

三、阈值设高还是设低

（一）设高的代价与设低的代价

阈值设高，扩容启动晚，高峰期任务要等；设低，稍微一动就扩，资源闲置时间变长。取舍的依据是业务对时延的容忍度：在线推理类业务对等待敏感，阈值可以低一些；离线训练类任务能等，阈值可以高一些，把钱花在更紧要的地方。

（二）冷却时间怎么定

冷却时间是两次伸缩动作之间的最小间隔，用来防止抖动。设得太短，资源反复增减；设得太长，需求真正变化时跟不上。经验做法是把冷却时间设成扩容准备时间的一点五倍左右，再根据实际观察调整。

四、缩容比扩容更需要谨慎

（一）任务中断风险

缩容要处理的是正在跑的任务。直接收回实例会导致任务失败，重跑的代价往往高于省下的资源费。所以缩容前要先确认目标实例上没有未完成任务，或者先停止接收新任务，等存量任务跑完再释放。

（二）先摘流再释放

标准流程是先摘流，把实例从调度池里移除，不再接收新任务，然后等待一段时间，最后再释放。这个等待时间要给足，长任务要单独标记，标记过的实例不参与自动缩容。

五、与调度策略的配合

（一）可抢占任务的腾挪

把任务分成可抢占和不可抢占两类，能显著提高资源利用率。可抢占任务在资源紧张时让位，资源宽松时补跑。这类任务本身要能从中断处继续，检查点保存得越密，被抢占的损失越小。

（二）多规格混跑

不同规格的显卡混着用，调度器就能在小任务上用低规格、大任务上用高规格，减少大材小用。混跑的前提是任务要声明自己的资源需求，声明得越清楚，调度越准。

六、上线后的观察指标

（一）扩容触发次数与及时率

1. 触发次数

一段时间内扩容被触发的次数过多，说明阈值偏低或者冷却时间偏短，需要往回收一收。

2. 及时率

从触发到资源可用的及时率偏低，说明扩容流程本身有瓶颈，最常见的是镜像准备太慢。

3. 监控本身的运行环境

监控与调度脚本可以用天翼云主机来跑，规格不用高，但要保持常开，减少监控成为盲区。

（二）闲置卡时占比

闲置卡时占比是伸缩效果好坏的最终指标，等于闲置卡时除以总卡时。这个数字下降，说明伸缩真的在起作用。统计时要按天和按周分别看，短周期波动大，容易误导判断。

伸缩规则最好写成配置文件而不是散落在脚本里，改动要能追溯，出问题可以回退到上一版。

新业务接入伸缩之前，先跑一段时间固定规格，摸清它的用量曲线，再定阈值，比一开始就上伸缩稳。

扩容用的镜像要提前准备好并保持更新，很多及时率不达标的问题，根源都在镜像准备这一步。

七、不同负荷的伸缩策略差异

（一）在线推理

在线推理对时延敏感，策略上宁可多留余量。可以设一个最小实例数，保证低峰也有基本能力，剩下的部分交给伸缩去补。

（二）离线训练

离线训练更看重吞吐和成本，可以接受排队。策略上把阈值设高一些，让资源尽量吃满，同时用检查点保证中断之后能接着跑。

（三）批量推理

批量推理有明确的开始和结束，适合用定时扩缩：任务开始前集中扩容，结束即整体释放，比按指标触发更干脆。

（四）开发调试环境

开发环境的用量集中在工作时段，可以按时间表伸缩，上班前扩容、下班后缩容。规则简单，效果也稳定。

（五）混合负荷的隔离

几类负荷混跑时，互相干扰会让指标失真。建议按负荷类型分成不同的资源组，各自单独伸缩，减少一个组的抖动带着另一个组一起动。

（六）多地域的伸缩

业务覆盖多个地域时，各地域单独设策略更合理，因为高峰时段并不相同。统一设一套会让部分地区长期闲置。

八、演练与回退

（一）定期做一次扩容演练

演练能暴露镜像、权限、配额上的问题。这些问题日常看不出来，真到高峰期才暴露，代价就太大了。

（二）给伸缩设一个手动开关

自动策略失灵时，手动开关是最后一道保障。开关要放在显眼处，并且让每个值班的人都清楚怎么用。

（三）记录每次伸缩的原因

把触发时间、触发信号、扩缩数量记下来，事后回看能发现阈值是否合理。日志保留得够长，才看得出季节规律。

（四）监控面板上该放哪几条曲线

监控面板上至少要放三条曲线：资源量、队列长度、响应时延。三条放在一起看，能快速判断是资源不足还是调度出了问题。

（五）策略改动先小范围验证

伸缩策略改完不要立刻全量生效，先在一个资源组上观察一两天，确认没有异常再推广到全部。这类改动的问题往往在第二天才显现。

结语：伸缩的难点从来不是能不能扩，而是什么时候扩、什么时候收。先把业务按对时延的容忍度分成几类，再为每类配不同的信号与阈值，比统一设一套参数有效得多。上线之后盯住闲置卡时占比这一个数字，持续优化即可。