模型推理服务的容量管理和传统 Web 服务长得像又不一样：像的是都要应对流量波动，不一样的是推理的「单请求成本」高得多（一条请求吃一个 GPU 时间片），扩容慢（GPU 资源紧俏）、缩容有风险（冷启动要加载模型）。这篇按演进阶段把推理扩缩容的方案捋一遍。
阶段一：定时扩缩容（起步可用）
按业务流量的时间规律预设扩缩容计划：早九点扩到 8 实例，晚八点缩回 2。优点是可预测、零算法成本；缺点是应对不了突发（热搜、活动、故障切换的流量）和规律的漂移（用户行为慢慢变了，计划没跟上）。
定时方案的关键细节：缩容时间点要比流量回落晚半小时——提前缩容的代价是秒级报错，晚缩半小时的代价是些微成本，账很好算。
阶段二：指标驱动（主流方案）
HPA 模式：目标指标（QPS/GPU 利用率/队列深度）超出阈值扩容、低于缩容。推理服务选哪个指标有讲究：
- QPS 不合适：不同请求的推理成本差异大（10 token 和 2000 token 的请求不等价），QPS 持平但算力需求可能差十倍
- GPU 利用率可用但要小心：利用率高可能是 batching 做得好（健康），也可能是真到瓶颈（要扩）——需要结合排队指标区分
- 队列深度+等待延迟是推理服务的黄金指标：请求在队列里等，就是要扩的直接证据；队列空且延迟低，就是可以缩的信号
缩容策略要比扩容保守得多：稳定窗口拉长（十分钟无反弹才缩）、缩容步幅限制（一次最多缩 1/3）、缩容保护期（刚扩完的实例 15 分钟内不参与缩容）——这三个参数是防「扩缩震荡」的铁三角，震荡的代价是反复的模型冷启动。
阶段三：预测驱动（进阶）
用历史流量做时序预测，在流量到来前预热扩容。推理场景的特殊价值：GPU 实例扩容含模型加载（分钟级），预测式预热把这个延迟藏进流量高峰之前。实现路径不必复杂：七日同时段流量的移动平均 + 安全系数，就能覆盖大部分规律性流量，剩下的交给指标驱动兜底。
推理特有的两个容量课题
多模型混部：一张卡跑多个模型（分时复用或显存共占），扩缩容的粒度从「实例」细化到「模型份额」——这是成本优化的大头，但调度复杂度陡增，建议规模到了再上。
冷启动治理：模型加载几分钟，缩下去的容量回不来那么快。对策：常驻小池（保留最低算力）+ 模型分层常驻（高频模型不缩、低频模型激进缩）+ 镜像与权重预热（镜像预拉取、权重放本地缓存盘）。
容量演练：扩缩容的期末考试
定期（季度）做一次演练：人为制造 3 倍峰值流量，观察扩容触发时间、到位时间、请求失败率。没演练过的自动扩缩容，和没测过的灾备一样——你相信它能工作，但它大概率会在非常需要的那天给你惊喜。
（模型工程系列：迁移评估 → 竞技场选型 → 网关路由 → 本文：扩缩容 → 计划中：多模型混部的调度）
