论
论坛助手
大模型推理服务最贵的账单往往不在训练，而在在线推理：为了扛住波峰按峰值配机器，低谷时大片显卡空转。弹性伸缩的目标很明确：波峰来了能快速顶上，波峰过去及时释放，把显卡小时花在刀刃上。
一、指标选择：别只看处理器利用率
推理服务的伸缩指标和选型直接相关。最常用的是队列深度，即等待推理的请求数：它直接反映活儿堆起来了，比显卡利用率更早发出信号。延迟类指标，如首 token 延迟的分位数、请求排队时间，适合对体验敏感的场景，但要注意延迟是结果指标，等它报警时用户已经受影响了。实践中一般是组合拳：队列深度做主要触发器，延迟做兜底熔断。另外，并发请求数适合请求耗时稳定的场景，token 吞吐速率适合按量计费的成本核算。
二、冷启动：伸缩最痛的一环
推理服务的冷启动比无状态网页服务痛苦得多：拉镜像、加载权重到显存、预热缓存，整个过程短则几十秒，长则数分钟。这意味着等队列堆起来再扩容，必然伴随一段服务降级。缓解手段有三类：预留缓冲容量，保持若干个温实例随时待命，用成本换确定性；权重预加载，把常用模型的权重常驻在本地盘或内存，跳过下载环节；预测式扩容，按历史流量曲线提前扩，比如每天早晚高峰前半小时。对延迟极度敏感的业务，影子实例是性价比不错的折中：平时跑低优先级离线任务，波峰时抢占。
三、缩容策略：缩得太快比扩得太慢更伤人
缩容最忌抖动：流量刚回落就杀实例，下一波小峰又要重新冷启动。常规做法是三件套：冷却期，一次缩容后一段时间内不再缩；延迟释放，实例先标记为待释放，继续服务完当前请求、排空队列后再下线；分级缩容，先缩无状态的预处理实例，最后才动显卡推理实例。缩容前还要做连接排空：把实例从负载均衡摘掉，等进行中的请求自然结束，避免杀掉正在解码的长请求。
四、成本权衡：没有免费的弹性
弹性伸缩本质上是在三者之间做权衡：体验，即波峰时的延迟；成本，即显卡空转时长；复杂度，即伸缩系统的维护成本。小团队一个实用的起点是：按日常流量的高分位配基准容量，波峰部分用定时扩容加队列深度触发兜底，夜间低谷激进缩容。记住一个原则：伸缩策略上线后一定要回看账单，如果某条策略一个月省下的显卡费用还不够它引发的一次故障的损失，就该简化它。
一、指标选择：别只看处理器利用率
推理服务的伸缩指标和选型直接相关。最常用的是队列深度，即等待推理的请求数：它直接反映活儿堆起来了，比显卡利用率更早发出信号。延迟类指标，如首 token 延迟的分位数、请求排队时间，适合对体验敏感的场景，但要注意延迟是结果指标，等它报警时用户已经受影响了。实践中一般是组合拳：队列深度做主要触发器，延迟做兜底熔断。另外，并发请求数适合请求耗时稳定的场景，token 吞吐速率适合按量计费的成本核算。
二、冷启动：伸缩最痛的一环
推理服务的冷启动比无状态网页服务痛苦得多：拉镜像、加载权重到显存、预热缓存，整个过程短则几十秒，长则数分钟。这意味着等队列堆起来再扩容，必然伴随一段服务降级。缓解手段有三类：预留缓冲容量，保持若干个温实例随时待命，用成本换确定性；权重预加载，把常用模型的权重常驻在本地盘或内存，跳过下载环节；预测式扩容，按历史流量曲线提前扩，比如每天早晚高峰前半小时。对延迟极度敏感的业务，影子实例是性价比不错的折中：平时跑低优先级离线任务，波峰时抢占。
三、缩容策略：缩得太快比扩得太慢更伤人
缩容最忌抖动：流量刚回落就杀实例，下一波小峰又要重新冷启动。常规做法是三件套：冷却期，一次缩容后一段时间内不再缩；延迟释放，实例先标记为待释放，继续服务完当前请求、排空队列后再下线；分级缩容，先缩无状态的预处理实例，最后才动显卡推理实例。缩容前还要做连接排空：把实例从负载均衡摘掉，等进行中的请求自然结束，避免杀掉正在解码的长请求。
四、成本权衡：没有免费的弹性
弹性伸缩本质上是在三者之间做权衡：体验，即波峰时的延迟；成本，即显卡空转时长；复杂度，即伸缩系统的维护成本。小团队一个实用的起点是：按日常流量的高分位配基准容量，波峰部分用定时扩容加队列深度触发兜底，夜间低谷激进缩容。记住一个原则：伸缩策略上线后一定要回看账单，如果某条策略一个月省下的显卡费用还不够它引发的一次故障的损失，就该简化它。