推理服务弹性伸缩比普通 Web 服务更复杂。普通服务扩容后很快接流量，而模型服务需要加载权重、初始化运行时、预热缓存并占用显存。
如果扩容信号和模型可用时间之间存在明显滞后，流量峰值到来时，新增副本可能还没有准备好。推理弹性设计的核心，是让容量变化跟得上业务流量，而不是只让副本数自动变化。
热池、最小副本、容量预测和服务分层，是推理平台降低冷启动影响的关键能力。
相关主题可以结合 模型推理、算力调度、AI基础设施 一起阅读。本文重点放在推理与部署的工程边界、稳定性指标和平台化治理方法上，避免只停留在概念解释。
先量化冷启动过程
冷启动可以拆成调度等待、镜像拉取、模型下载、权重加载、显存分配、缓存预热和健康检查。不同阶段的耗时差异很大。
如果平台只记录副本启动时间，不记录模型真正可服务时间，就会低估冷启动对延迟的影响。
冷启动治理必须先量化每个阶段，而不是笼统说扩容慢。
扩缩容指标不能只看 CPU
推理服务的压力可能来自 QPS、队列长度、P95 延迟、显存水位、GPU 利用率和批处理等待时间。CPU 指标经常不足以代表真实负载。
对于 GPU 推理，显存和队列长度往往比 CPU 更能反映容量风险。
扩缩容策略应根据模型类型组合指标，避免扩得太晚或缩得太快。
热池适合高价值和高频模型
热池通过提前保留可用副本或预加载模型，减少流量突增时的等待。它会增加基础成本，但能显著降低冷启动风险。
不是所有模型都适合热池。高频、核心、冷启动长的模型更值得保留热资源；低频模型可以接受按需加载。
热池不是浪费，而是用可控成本换取关键服务的稳定性。
容量预测能减少被动扩容
很多推理流量具有周期性，例如业务高峰、批处理任务、活动流量或固定时间窗口。平台可以用历史数据提前准备容量。
预测不需要一开始非常复杂，先根据小时、日、业务事件和模型热度做规则化预留，也能降低被动扩容压力。
容量预测应和热池、最小副本、灰度流量一起协同，而不是孤立存在。
缩容要避免抖动和误杀
缩容过快会导致刚释放资源后又遇到流量回升，形成频繁扩缩容；对模型服务来说，这会反复触发冷启动。
缩容策略应考虑冷却时间、流量趋势、模型加载成本和当前副本状态。
对于核心服务，缩容目标不应是把资源压到最低，而是保持合理安全余量。
弹性策略需要按服务等级分层
实时交互、内部低频、批量推理和实验模型，对弹性策略的要求不同。统一策略会造成成本或稳定性问题。
高等级服务优先保延迟和可用性，低等级服务可以更激进地按需加载或共享资源。
成熟的推理弹性平台，应让每类模型都有清楚的容量目标、冷启动预算和成本边界。
弹性设计先定义服务等级
不同推理服务的弹性目标不同。核心在线模型要求低延迟和高可用，内部工具模型可以接受短暂等待，离线推理任务则更关注整体完成时间。
如果所有模型使用同一套扩缩容策略，高等级服务可能扩容不及时，低等级服务又可能长期占用热资源。服务等级决定弹性策略，而不是所有模型默认一套规则。
平台可以把模型按业务影响、调用频率、冷启动耗时和资源成本分层，再设置最小副本、热池、扩容阈值和缩容冷却时间。
冷启动预算要量化
冷启动不是一个模糊概念，而是从调度到可接流量的完整时间。大模型下载、权重加载和缓存预热可能占据主要耗时。
每个模型都应有冷启动预算：允许多久启动、启动期间是否接流量、是否需要预热、失败后如何重试。没有预算，就无法判断扩容策略是否足够。
冷启动预算越明确，热池和容量预测的投入就越容易评估。
扩容和路由要协同
扩容完成之前，新副本不应该过早接收关键流量；副本刚启动但未预热时，也可能造成长尾延迟。路由层需要理解副本状态，而不是只看 Pod 是否 Ready。
更稳妥的方式是区分启动、预热、可接少量流量和完全可用几个状态，让流量逐步进入新副本。
如果扩容和路由割裂，平台会出现副本数增加但用户延迟没有下降的情况。
缩容要保护稳定性
缩容不只是释放资源，还会影响后续冷启动和流量承接能力。缩得太快，平台会在流量波动中频繁启动和释放模型，反而增加成本和延迟。
缩容策略应设置观察窗口和冷却时间，并结合业务周期判断是否真的进入低峰。对于冷启动长的模型，可以保留少量热副本。
弹性伸缩的目标不是让资源曲线贴着流量曲线，而是在稳定性和成本之间保留合理缓冲。
弹性策略的常见误区
第一个误区是只看副本数。副本数增加不代表服务容量立即增加，尤其是模型还在加载或预热时。第二个误区是只看 QPS，忽略上下文长度、批大小和显存水位。
第三个误区是缩容过于激进。短时间低流量不一定代表可以释放资源，尤其是冷启动长的模型，频繁释放和重建会让整体体验更差。
更好的策略是把扩容阈值、预热状态、路由接入和缩容冷却时间组合起来，让弹性动作更接近真实可服务容量。
容量规划和弹性要配合
弹性伸缩不能替代容量规划。对于流量相对稳定或有明显周期的模型，提前规划基础容量比完全依赖实时扩容更可靠。实时扩容适合处理波动，不适合承担全部容量保障。
平台可以根据历史流量、业务活动、模型热度和冷启动耗时设置基础容量，再用弹性策略应对突发变化。这样既能减少冷启动风险，也能避免长期过度预留。
容量规划还应考虑资源池层面。如果多个模型同时进入高峰，单个模型的扩容策略可能都正确，但资源池总量仍然不足。因此平台需要同时观察模型级和资源池级容量。
小结
推理弹性伸缩要围绕真实可服务容量设计，而不是只观察副本数量变化。冷启动预算、热池策略、扩缩容指标和路由接入状态一起工作，才能在流量波动时同时兼顾延迟、成本和可用性。
常见问题
推理服务弹性伸缩为什么不能只看 CPU 或 GPU 利用率？
推理服务的可服务能力不仅取决于计算利用率，还取决于显存、队列长度、批处理等待、模型加载状态、上下文长度和副本是否完成预热。单看 CPU 或 GPU 利用率，可能会错过请求已经排队、显存接近上限或新副本尚未可用的情况。弹性指标应组合使用，并尽量反映真实用户延迟和排队压力。
热池适合所有模型吗？
不适合。热池会占用持续资源，适合高价值、低延迟、调用频繁或冷启动成本高的模型。低频实验模型、内部工具模型或可接受等待的批量任务，不一定需要长期热驻留。更好的做法是按模型重要性、调用频率、冷启动时间和业务容忍度分层，决定最小副本、预热策略和是否进入热池。
扩容速度很快，为什么用户仍然感到慢？
扩容动作完成不等于副本已经具备服务能力。大模型可能还需要拉取镜像、加载权重、初始化运行时、预热缓存和占用显存。如果路由层在这些步骤完成前就分配流量，新副本会成为新的长尾来源。因此弹性设计要区分“副本创建成功”“模型加载成功”“预热完成”和“允许接流量”几个状态。
如何避免扩缩容频繁抖动？
需要同时设置扩容触发、缩容冷却和最低服务容量。推理流量常常有突发峰值和短周期波动，如果缩容过快，会导致下一次峰值重新冷启动；如果扩容过敏，会浪费资源。可以把队列长度、P95/P99、请求速率和资源水位结合起来，并为关键模型保留最小热副本，让弹性策略围绕稳定体验而不是副本数量本身。
转载请注明出处：https://www.cloudnative-tech.com/p/8456/
