一、先分清两条扩容路径

弹性扩容有两条路，作用点完全不同。第一条是横向扩容：增加或减少实例数量，让更多副本分摊请求。它的好处是架构简单、上限高，几乎任何推理框架都支持多实例部署，扩缩不涉及实例内部的配置变更。代价是每次增减都是一个完整实例，粒度粗，且新实例要经过调度、拉镜像、读入模型才能就绪，这段时间内进来的请求只能靠队列缓冲。第二条是纵向扩容：不改变实例数量，而是调整单个实例可用的加速卡配额与显存，让一个实例处理更多请求。它的优势是快，调整配额往往在秒级完成，不必重启也不必重新读入模型，适合流量小幅突增。它的边界也很清楚：单张卡的能力有上限，涨到顶就只能靠加实例。实际配置时两者是配合关系，不是二选一——小幅突增先用纵向那条腿顶住，涨势确认后再横向加实例，回落时反向操作。

二、触发指标怎么选

自动伸缩的核心是“看什么决定加不加”。常用的四类指标各有适用面。第一类是请求延迟，比如响应时间超过某个分位值持续一段时间就扩。它贴近用户体验，但属于事后指标——延迟已经上去了才动手，用户已经受到影响。第二类是队列深度或并发请求数，即等待处理的请求积压到多少。这一类是前置指标，能在延迟恶化之前就发出信号，突发场景下比延迟更灵敏。第三类是资源使用率，比如加速卡的使用率或显存占用持续高于某个区间。它反映的是实例真实忙不忙，但对访客侧的感受不直接。第四类是自定义业务指标，比如每秒请求数或会话数，适合流量形态稳定的业务。实践中较稳的做法是以队列深度为主、延迟为辅，两者同时满足才扩，防止单指标抖动引发误扩。阈值不要拍一个整数，先跑一周采集真实分布，取高峰时段的常态值作为起点，再逐步收紧。

三、突发流量分三种形态

第一种是可预期的峰：活动上线、定时任务集中触发、工作日早间的集中访问。这类峰有时间表，自动伸缩不必独自应对，提前按计划把副本数调上去更省心，扩在前、收在后。第二种是不可预期的尖刺：热点事件带来的陡增，几分钟内翻几倍，随后快速回落。这类尖刺靠加实例追不上——实例就绪往往要几十秒到几分钟，等扩出来峰已经过去了，硬加反而留下大量闲置。对付尖刺的正确做法是前面挡一层：限流保住核心请求、排队削峰、把非关键请求降级，让服务不被打垮，同时用纵向扩容吃掉一部分增量。第三种是缓慢爬升：业务自然增长或长尾热点，几分钟到几小时内持续上升。这一类最适合自动伸缩，决策有时间生效，扩容步长也能按趋势给。把三种形态分开看，配置就不再是“设一个阈值了事”，而是按形态各配一套应对。分形态的好处还在于事后复盘：一次高峰过去，能判断它是哪一种形态、当时的应对是否对症。若把尖刺当成爬升去加实例，复盘时会发现实例加了不少、峰值体验却没改善；若把爬升当成尖刺去限流，代价是主动丢掉了一部分本可以正常服务的请求。这两种误判都很常见，而判断依据其实就是高峰持续了多久、回落有多快。

四、冷启动是那道硬约束

横向扩容的速度受限于实例就绪时间，这不是配置能绕过的。一个推理实例从调度到可用，要经过拉取镜像、初始化运行环境、读入模型权重、预热几个阶段，几秒到几分钟不等，模型越大、镜像越大越慢。能做的优化有四处。第一，保底实例：始终留一到两个实例常驻，不随缩容归零，保证任何时刻都有能接流量的副本。第二，镜像与权重的就近缓存：把常用镜像层与模型权重提前放到离算力近的存储里，扩容时只需拉取差异部分，能显著缩短就绪时间。第三，预热：在流量趋势确认上升时就启动实例、先完成环境与权重准备，等流量真正到顶时立即接流。第四，控制单实例的启动复杂度：把初始化阶段能省的动作省掉，别在启动时做数据取回或格式转换这类重活。这四点合起来，能把扩容的响应速度从“分钟级”压到可接受的范围，但不等于消除延迟，策略上仍要假设扩容有时滞。

五、一份可落地的策略配置

配置自动伸缩时，有六个参数值得逐一定。第一，副本数上下限：下限按低谷时的真实需求定，不要设成一；上限按资源配额与成本预算定，设得太高会在异常时把配额吃光。第二，扩容步长：一次加几个。步长太小追不上爬升，太大容易过量，可按当前副本数按比例给，比如每次增加当前数量的一半，并设一个单次上限。第三，缩容步长与冷却时间：缩容要比扩容保守，冷却期设长一些，防止刚回收又立刻需要。第四，判断窗口：连续多少个采样周期满足条件才动作，窗口太短会被抖动带着走。第五，指标阈值：按上一节的方法取真实分布。第六，与健康检查绑定：实例不健康时自动换下，这属于容错，与扩缩同等重要。把这六个参数写进配置说明，谁改了什么一眼可见，值班的人不必猜当前策略是谁调过。

六、扩缩过程中的稳定性

扩缩动作本身不能影响在线请求，这需要几层配合。第一层是滚动方式：新实例先就位、再逐步撤下旧实例，全程不中断。第二层是灰度接流：新实例先接少量流量跑一段，确认模型就位、响应正常，再放开全量，防止带病实例直接承接。第三层是会话与状态：推理实例尽量做成无状态的，会话数据外置，否则扩缩时正在处理的请求会丢；有状态的部分要单独处理，不能指望新实例自动接上。第四层是限流兜底：伸缩再快也有上限，入口处留一道限流，超出部分排队或拒绝，比让所有请求一起变慢要好。第五层是变更留痕：谁在何时因为什么调整了副本数、改了哪个阈值，记录下来，事后回溯与复盘都靠它。五层做完，扩缩就从“能加机器”变成“加了不出事”。还有一件常被漏掉的事：把扩缩动作与告警打通。副本数在短时间内频繁上下、或触到上限后仍持续积压，这两类信号都该主动通知到人，而不是等业务方打来电话。前者说明阈值或步长需要重调，后者说明配额或架构到了该动的阶段。

七、上线后怎么观察与调整

策略配好不是终点，要看效果。第一周重点看四个数：响应时间的分位值而不只是均值、错误率、实例整体使用率、以及扩容触发到接流完成的实际耗时。分位值能暴露少数用户的糟糕体验，均值会把它们掩盖掉；实际耗时决定策略的提前量是否够。第二周看成本侧：单次扩缩带来的资源开销、闲置实例的占比，判断上限与步长是否过于保守或激进。第三周做一次压测：用可控的流量把服务推到预设上限，确认限流与降级在真触发时行为符合预期，而不是只在文档里写着。调整的节奏建议一次只改一个参数，改完观察至少一个业务周期，否则多个改动混在一起，效果好坏说不清。最后把整套策略与这几次调整的结论写成一份说明，交接时它就是最省时间的东西。说明里至少要写清三件事：当前阈值的来历、上限受什么约束、哪些情形需要人工介入。三者写明白，值班的人遇到异常才敢判断该等自动伸缩还是立刻手动加实例。

结语

推理服务的弹性扩容，实质是把两件事调匀：让流量高峰不排队，让低谷不空转。横向扩容负责总量、纵向扩容负责瞬时，两者配合而非择一；触发指标以队列深度为主、延迟为辅，阈值从真实分布里取；突发流量按可预期、尖刺、爬升三种形态分别应对，尖刺要靠限流与预热带前挡住；冷启动是硬约束，靠保底实例、就近缓存、预热压短；策略的六个参数要写清并留痕，扩缩过程靠滚动、灰度、限流、留痕四层保证不出事。上线后按分位值、错误率、触发到接流的实测耗时逐周调，一次只改一处，这套东西才真正稳下来。