一、一条规则要写清四件事

1. 看什么指标

指标决定信号的灵敏度与可信度。选利用率，反应快但容易误判；选队列积压，更贴近真实压力但需要业务侧配合埋点。同一个伸缩组里，不同指标承担不同角色。

2. 越过多算线

阈值就是那条线。定高了启动晚，定低了空转多。它对业务延迟的容忍度极其敏感：在线交互类可以定得积极一些，离线批处理类则可以从容一些。

3. 持续多久才算数

瞬时越线不算数，连续若干个采样点越线才触发。这一步决定规则是否稳定。缺少这一项，规则会把每一次短促波动都当成需求增长。

4. 一次动多少

扩几个实例、缩几个实例，以及实例总数的上限与保底。上限是对支出的硬性约束，保底是对基础处理能力的保障。这两项不设，伸缩就成了一件没有边界的事。

四件事凑齐才是一条完整规则。只写前两项的规则，上线后基本都要返工。

二、指标选型：五类信号加一条搭配原则

1. 显卡利用率

衡量计算单元被占用的比例。它直观、易得，但对短任务极其敏感：一个几十秒的任务就能把数值顶到高位，随后迅速回落。用它作触发指标，必须配合较长的观察窗口与连续次数，否则一天能触发几十次。

2. 显存占用

推理场景里，这一项往往比利用率更能反映真实压力。上下文变长、并发变多，显存先满，随后才是算力吃紧。核这一项时要注意区分静态占用与缓存占用，缓存部分会随请求量涨落，不能当成容量不足。

3. 队列积压

等待处理的请求条数，或预计等待时长。这是较为贴近用户体验的信号，反应也较快：队列一长，用户已经在等了。它的问题是可能被调度策略污染——任务分配不均也会让队列变长，这时加机器不一定有用，得先看分配逻辑。

4. 响应延迟分位值

取高分位值，而不是均值。均值会把少数极慢的请求抹掉，而用户感受到的恰恰是那些慢请求。延迟适合当兜底信号：前两类都没触发但它持续偏高，说明有别的瓶颈在起作用。

5. 请求速率与就绪实例数

请求速率的用途是预判，在增长趋势明确时提前动手，抵消扩容空窗期。就绪实例数则用来确认新资源是否真的可用，实例创建成功不等于服务已就绪。另有一项常被漏掉：新实例从创建到能接流量的就绪判定时间。若就绪探测过于宽松，实例刚创建就被打上流量，前几个请求的失败比例会明显偏高。

6. 单一指标为什么不够

计算单元的利用率与真实压力之间常常脱节。数据搬运、批处理窗口、请求长短不齐，都会让利用率显示不高但用户已在排队。所以指标至少要两类搭配：一类反映资源，一类反映体验。两者背离时，以体验那一类为准。

三、阈值怎么定：从基线出发定上下沿

1. 先测基线，再谈取舍

连续采集一到两周，得到日常水准与日内峰值两组数。没有基线就定阈值，等于在猜。基线里还要标出周期性规律，比如每天固定时段的高峰、每周固定的批量任务。

2. 上沿要算上扩容空窗

扩容从触发到可用需要几分钟到十几分钟。这段时间里请求仍在涌入，队列会继续增长。所以上沿不能按当前用量卡，要把空窗期内预计新增的量提前算进去，让动作早一点发生。

3. 下沿必须比上沿低一截

上沿与下沿之间要留一条回差带。假如上沿设在七成、下沿也设在七成，资源会在同一条线上反复加减，这叫抖动。常规做法是上沿七成到八成，下沿三成到四成，中间的三四十个百分点就是缓冲。

4. 按业务性质调整松紧

对等待敏感的在线服务，上沿可以压到六成左右，宁可多备一点；能等的离线批处理，上沿可以放到八成以上，把资源用足。这不是优劣之分，是取舍之别。

四、窗口与连续次数：把瞬时抖动滤掉

1. 窗口与采样点要成对设定

指标每三十秒采集一次，要求连续三个点越线，实际观察窗口就是一分钟半。窗口太短滤不掉抖动，太长则响应变慢。经验做法是让观察窗口大致等于扩容准备时间的一半。

2. 队列类指标可以用短窗口

队列积压本身就是累积结果，噪声小，可以用较短的窗口快速响应。比如积压条数越过设定值并持续一分钟，就可以动手。

3. 延迟类指标的窗口要拉长

延迟受网络、数据读取、请求大小多重因素影响，波动大。用它作触发条件时，窗口要拉长到十分钟以上，否则一次网络抖动就能引发一轮无谓扩容。

五、扩缩两侧不能对称

1. 扩容要快

扩容侧的冷却时间应设得很短，甚至不设。需求增长时等待没有收益，每一分钟都是用户在排队。若担心连续触发，用步长控制即可：每次加一两个实例，而不是一次加满。

2. 缩容要慢，还要排空

缩容前的第一件事是确认目标实例上没有正在跑的任务。做法是先停止向它分派新请求，等存量任务跑完再释放。直接收回实例，正在跑的任务会失败，重跑的代价往往高于省下的资源费用。

3. 缩容的稳定窗口要长

缩容条件的持续时间建议设在十五分钟以上，并且要求相关指标同时满足。只满足一条就缩，会在两次小高峰之间误缩，随后又被迫扩回来。

4. 上限与保底要写死

上限按支出预算定，保底按基础处理能力定，通常取峰值的两到三成。这两项是规则之外的护栏，任何自动动作都不能越过。

六、多规则叠加时的冲突处置

1. 扩容用或，缩容用与

多条规则同时存在时，扩容侧只要有一条满足就动手，确保不漏；缩容侧要所有条件都满足才动手，确保不误缩。这个不对称设计能挡掉大部分抖动。

2. 给规则排优先级

定时规则与指标规则可能给出相反结论。比如预定的高峰扩容与低利用率缩容同时成立。此时应让定时规则优先，因为它是基于已知业务规律的预判，指标规则只是当下的观察。

3. 规格必须统一

伸缩组内的实例规格要一致。混用不同型号的计算卡，调度侧无法准确衡量总算力，会出现加了机器任务仍在积压的情况，而排查时指标一切正常。

4. 状态要能被看见

每条规则近期一次触发时间、触发原因、动作结果，都要能在同一处看到。规则多了之后，出问题时第一个要回答的问题是：刚才到底是谁动的。

七、规则上线后怎么校准

1. 每周看三个数

触发次数、实例驻留时长、缩容后半小时内是否回弹。触发次数过多说明阈值太紧；驻留时长过短说明扩了就用不上；缩容后迅速回弹说明下沿定得偏高。

2. 抖动是较易辨认的信号

一天之内同一规则触发超过五六次，基本可以判定阈值或窗口不合理。此时不要急着调阈值，先看窗口是否太短。多数抖动是窗口问题，不是阈值问题。

3. 每季度复测一次基线

业务量在变，模型在换，硬件规格也可能调整。三个月前的基线今天未必成立。复测之后，阈值与窗口要跟着一起改，只改一项容易产生新的错配。

4. 大促前手动预扩

已知的大流量节点，不要指望规则自己反应。提前按预估峰值的手动扩到位，规则只在期间做微调。自动伸缩擅长应对未知波动，不擅长应对可以预知的高峰。

结语

伸缩规则的价值不在于写得多复杂，而在于四个要素是否齐备、彼此是否配合。指标要资源与体验各选一类，阈值要从实测基线出发并留出回差带，窗口与连续次数负责滤掉噪声，动作幅度与上下限负责把成本锁在边界内。扩缩两侧不对称是核心经验：扩容快、缩容慢，扩容用或、缩容用与。规则上线之后靠三个数校准，抖动先查窗口，别急着动阈值。GPU算力的支出弹性很大，一套定准的规则，能让资源跟着真实需求走，而不是跟着指标的瞬时波动走。