AI推理服务弹性伸缩，最容易犯的错误是只盯着副本数。副本变多，看起来吞吐上去了，但如果请求队列没有被约束，GPU利用率没有被真正吃满，首 token 延迟和整体排队时间还是会抖得很厉害。
对生产环境来说，弹性伸缩不是单纯扩容，而是让 延迟、吞吐、成本和稳定性 同时可控。特别是大模型推理，短请求、长上下文、流式输出和批量任务混在一起时，伸缩策略如果只看 CPU 或单一 GPU 指标，很容易误判。
先把伸缩目标说清楚
AI推理服务的目标通常有三种：第一种是保住在线响应时间；第二种是提高 GPU 利用率；第三种是控制单位请求成本。三者不能同时无限放大，必须按业务优先级排序。
如果是交互式问答，首 token 延迟和 P95 响应时间更重要；如果是批量生成，吞吐和成本更重要；如果是混合负载，就要把请求拆成不同队列，否则一个长任务就可能拖慢整条链路。
伸缩策略的第一步，不是算要不要加机器，而是先定义“什么信号代表真的需要扩容”。
只看副本数会漏掉关键瓶颈
很多团队会直接把 HPA 或自定义伸缩器接到推理服务上，但如果只看副本数，常见问题会被忽略：
- 副本数增加了，但 GPU 显存还是被单个大请求占满
- 并发提高了，但队列过长，延迟反而更差
- 服务实例变多了，但模型加载时间太长，扩容来不及
- 新副本起来后请求分配不均，热点实例依旧过载
所以，AI推理服务的伸缩应该同时看几个信号：GPU 利用率、显存占用、排队长度、请求等待时间、首 token 延迟和错误率。单一指标经常会把问题藏起来。
队列要先分层，再考虑扩容
推理服务里最值钱的往往不是“更多副本”，而是“更合理的队列”。如果交互式请求、批处理请求和高优先级任务混在一起，伸缩系统会被噪声干扰。
建议至少分成三层：
1. 在线交互队列：优先保证低延迟
2. 批量任务队列：允许排队，强调吞吐
3. 高优先级队列：用于关键业务或人工介入场景
分层后，伸缩器才能根据不同队列的压力做决策。否则一个批量任务高峰，可能会把在线接口一起拖慢。
GPU 利用率不是越高越好
GPU 利用率高，通常意味着资源吃得更满，但在推理服务里，过高利用率不一定等于更优。因为大模型推理还要考虑显存碎片、上下文长度波动和 kernel 排队。
更稳妥的做法是看“可承受利用率区间”，而不是追求 100%。很多场景下，留出一定余量，反而能让突发请求更平滑地进入队列，避免出现明显抖动。
如果某个服务长期跑在高利用率区间，但延迟稳定、错误率低、排队短，那它是健康的；如果利用率高但延迟开始飘、超时增加，那就说明该扩容了，不要只看表面指标。
扩容慢的问题要提前处理
AI推理服务和普通无状态服务不一样。实例扩容后，新副本往往还要经历模型下载、权重加载、显存初始化和预热。如果这个过程太慢，HPA 触发再快也救不了峰值流量。
因此，生产里要提前处理三个问题：
- 模型启动时间能不能被监控到
- 预热请求是否足够覆盖真实路径
- 扩容中间是否会出现流量集中到旧副本
如果模型加载很慢，宁可保留少量热副本，也不要把所有实例都压到极限再等扩容。
观测指标要能回答“为什么慢”
AI推理服务的监控不能只给一个总耗时。最好能拆成：排队时间、模型加载时间、首 token 时间、生成时间、工具调用时间和下游等待时间。这样平台团队才知道问题是出在网关、推理引擎还是资源层。
对伸缩来说，最有价值的不是“今天流量涨了多少”，而是“哪类请求让队列变长了、哪类请求让 GPU 更吃紧了、哪类模型最先触发了降级”。
POC 建议看 4 个场景
在验证 AI推理服务弹性伸缩时，建议至少跑 4 个场景：
- 短请求突发并发
- 长上下文持续占用
- 混合流量交错
- 模型预热期间扩容
这四个场景能看出队列设计、扩容速度和资源利用率是否真的合理。只测匀速流量，通常测不出问题。
常见问题
AI推理服务伸缩应该优先看什么指标？
优先看队列长度、等待时间和首 token 延迟，再看 GPU 利用率。因为真正影响用户体验的，往往不是算力是否空闲，而是请求有没有被及时处理。
为什么 GPU 利用率高了反而还要扩容？
因为高利用率不等于高可用。如果利用率已经挤压到延迟和错误率上升，就说明系统已经接近饱和，需要留出余量。
副本越多越好吗？
不是。副本数量只是手段，真正的目标是让请求分布更均衡、排队更可控、扩容更及时。如果副本变多但模型加载慢或路由不均，效果反而会变差。
下一步建议
如果你在搭 AI推理服务，先不要急着调大副本上限。先把请求分层、队列长度、预热时间和关键延迟指标定义好，再谈自动伸缩，效果会稳定很多。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/1504/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
