容量余量留多少
推理集群按「峰值并发乘一个系数」预留余量，用排队时长与 KV 水位作为扩容触发条件。扩容本身有加载与预热成本，所以触发线要按增长斜率提前设计；等水位打满再扩，用户已经感受到了。
基本信息
| 基线一 | 峰值并发与队列长度 |
|---|---|
| 基线二 | 延迟目标下的单实例吞吐 |
| 基线三 | KV 水位峰值，留一到两成裕量 |
| 触发线 | 排队时长或 KV 水位越线 |
| 扩容成本 | 加载与预热是分钟级 |
典型使用场景
- 制定季度容量计划
- 给自动扩缩容设定阈值
- 评估大促前的资源准备
- 判断该加卡还是该优化单实例效率
- 把扩容耗时实测一次，作为触发线的输入
三条基线与触发线
三条基线与触发线
# 1) 峰值并发与队列长度（含时间分布）
# 2) 延迟目标下的单实例吞吐
# 3) KV 水位峰值，预留一到两成裕量
# 触发线：排队时长超过延迟预算的一半，或 KV 峰值水位连续一段时间越线触发信号怎么定
| 触发信号 | 阈值思路 | 说明 |
|---|---|---|
| 排队时长 | 超过延迟预算的一半 | 体验开始变差 |
| KV 峰值水位 | 连续超阈值 | 接近抢占边界 |
| 并发增长斜率 | 按扩容耗时倒推 | 预留提前量 |
容量评审按周看趋势：请求长度分布的变化会直接改变单实例吞吐，不能照搬上周的结论。
缩容求稳：先降权重再观察，宁可慢一点也不要把容量反复抖到谷底，抖动本身就在消耗用户体验。
余量不是越多越好：长期大量闲置就是成本浪费，目标是在触发线之前把容量平稳扩上去。
触发线要与业务日历对齐：活动开始前先扩容，而不是等流量上来之后被动响应。