大模型的访问量说涨就涨，靠人盯着加机器肯定来不及，自动扩缩容就是让系统自己看水位、自己决定加减实例的那套机制。
扩容信号从哪里来
常用信号有三个：加速器利用率、请求队列长度、首字延迟。利用率高、队列堆积、首字变慢，都说明算力不够用。进来的是监控指标，发生的是阈值比对，出去的是「该扩容」或「先看看」。
信号要防抖：偶尔一个尖刺就扩容，流量退了又缩，机器反复起停，成本和稳定性双输。通常要求指标连续多个采样周期越线才作数。
不同信号的脾气不同：利用率波动快，适合短窗口；队列长度更稳，适合中窗口；延迟最贴近用户感受，但噪声也最大，常作为兜底信号。
信号来源也不止一套：业务侧的大促排期、前一天的同期曲线，都可以提前喂给控制器，让扩容从「响应」变成「预备」。阈值还要留安全余量，贴着利用率上限设线，等于每次都踩线才动作，留一成余量更从容。
加减机器的完整链路
第一步判定。控制器按窗口聚合指标，决定扩几台、缩几台。进来的是时间序列，发生的是规则或预测，出去的是目标实例数。
第二步调度。新实例要拉镜像、加载模型，模型大的时候这一步以分钟计，这段时间的流量缺口只能靠老实例和限流先顶着。进来的是目标数，发生的是资源申请与启动，出去的是注册上来的新实例。
调度层还要看亲和：同用户的请求尽量落到有它缓存的实例，扩容后重新洗牌会丢掉这部分好处，需要在新实例预热完成后再切换。
第三步接入。新实例先不接流量，预热通过健康检查后再被负载均衡纳入。进来的是新实例，发生的是探活与灰度放量，出去的是真实接活的成员。
缩容相反：先摘流量，等在途请求跑完，再回收机器。进来的是过剩实例，发生的是排水与释放，出去的是降下来的成本账。回收也不是一关了之：磁盘上的模型文件通常保留，下次扩容直接复用，省掉又一次拉取。
| 步骤 | 进来什么 | 出去什么 |
|---|---|---|
| 判定 | 按窗口聚合的时间序列 | 目标实例数 |
| 调度 | 目标实例数 | 注册上来的新实例 |
| 接入 | 新实例 | 真实接活的成员 |
| 缩容 | 过剩实例 | 降下来的成本账 |
抖动是怎么被压下去的
关键是冷却期：扩完容一段时间内不许再扩，缩完同理；再加一条「缩容要慢于扩容」的非对称规则，因为加错机器只是费钱，减错机器就是服务中断，两者的后悔成本完全不对等。
冷启动期间如果流量已经压过来，宁可让老实例先扛一会儿，也不要让半热的新实例接重活，否则故障率反而上升。预测式扩容是进阶做法：按历史规律提前加机器，等流量真来了已经就位。
你在 DeepSeek、海螺AI 高峰期提问照样有响应，靠的就是这套链路在后台跑。它不替模型答题，只保证答题的机器随时够用。
- 速查：扩容看利用率、队列、延迟三类信号；信号要连续越线防抖；新实例先预热再接流量；缩容先排水再回收。
和它前后脚配合的还有负载均衡是怎么分流请求的？多实例配合、语义缓存是怎么判断「相似问题」的？、优先级队列是怎么排 VIP 的？权重怎么定和限流算法是怎么计数的？令牌桶的思路。
关于自动扩缩容再多问三句
- 扩容一定要等到指标越线吗？：也可以按时间规律预测，比如每天上午九点前先加一批。
- 缩容缩太猛会怎样？：在途请求被赶走，用户看到超时，所以排水和冷却期不能省。
- 实例数有没有上限？：有，受配额和成本约束，触顶时靠限流和降级兜底。
