模型上线后请求激增时，推理算力扩容的核心原则是：预测性扩容打底，反应式扩容兜底，模型优化减负，把这三件事同时办好，才能在流量高峰扛住压力，流量回落后不浪费预算。
模型上线后请求激增时怎么扩容，先分清瓶颈在哪
请求激增的第一反应是加机器,但很多时候瓶颈不在GPU算力本身，先看四个常见卡点：
- GPU显存容量：模型权重和KV Cache放不下时，请求直接排队甚至报错，这类问题加机器有用，但换大显存卡更直接。
- 显存带宽：小batch并发场景下，算力没吃满，显存带宽反而被读取模型权重占满，此时加大batch或换带宽更高的卡才有效。
- 网络吞吐：负载均衡入口带宽被打满时，后端GPU再闲也白搭，先查SLB和网关规格再谈扩容。
- 推理框架效率：没有启用连续批处理或PagedAttention的服务，GPU在等请求的空窗期大量空转，吞吐差距明显。
动手扩容前,先用压力测试工具摸清底细，用wrk或k6打并发，同时执行nvidia-smi观察GPU-Util和显存占用，如果GPU-Util高且请求积压，加算力是正解；如果显存满了但利用率不高，先做量化或换大显存卡，行业共识认为，推理服务上线前至少用真实流量回放做一轮完整压测，否则你根本不知道扩容该扩什么。
推理算力扩容方案对比：横向扩容、纵向扩容还是混用
不同业务阶段有不同的扩容路径,不存在万能药，把三种方式摆在一起看更清楚，具体选择取决于你的服务特征和预算结构。
| 对比项 | 横向扩容 | 纵向扩容 | 混合扩容 |
|---|---|---|---|
| 扩展方式 | 增加GPU实例数量 | 升级单卡或单机规格 | 横向扩流量 + 纵向提容量 + 模型优化 |
| 适用场景 | 无状态API、多副本服务 | 单卡显存吃紧、大模型推理 | 有稳定底座 + 明显峰值波动的生产环境 |
| 成本特点 | 按需付费，弹性最好 | 升级成本偏高，通常需要停机 | 用优先级调度平衡成本与稳定性 |
| 操作难度 | K8s配合较容易 | 涉及实例迁移和验证 | 需要全链路监控和压测数据支撑 |
GPU算力租赁价格差异背后的扩容逻辑：按需实例弹性好但单价高，适合应对突发峰值；竞价实例便宜不少，适合非关键推理任务如批量离线打分，但不适合核心在线服务；包月包年在长稳运行场景下折算成本更低，把常驻流量用包月卡扛住，把突刺流量打到按需或竞价实例上，是多数团队的实际操作。
容器化+K8s是扩容的操作底座
没有K8s,横向扩容就是手工活，容器化之后，扩容就是一条命令的事，临时要顶住一波流量时：
kubectl scale deployment llama-api --replicas=8
流量回落再缩回来：
kubectl scale deployment llama-api --replicas=3
配合Cluster Autoscaler或简米云的节点池弹性伸缩，Pod因为资源不足pending时，集群自动加节点，不用人工盯控制台，这是目前推理服务扩容最主流的操作路径。
按流量规律做时间窗口扩容，比反应式扩容更从容
等告警响了再扩容,前几分钟的请求已经跪了，对话助手的流量曲线通常有明确规律：晚上8点到11点是高峰，周末比工作日高一大截，用CronHPA定义好时间表，提前15分钟把副本数扩上去，高峰过了再缩回来，用户完全无感，比临时抱佛脚体面得多。
- 提前分析业务日志,画出周维度QPS曲线
- 用
kubectl apply部署CronHPA配置，按时间表达式触发放缩 - 定期复盘流量预测与实际流量的偏差,校准时间窗口
事件驱动扩容应对无规律突发
没有明显规律的业务,靠KEDA这类事件驱动伸缩组件，KEDA监听消息队列积压、Prometheus指标或自定义事件，队列堆积到阈值就自动扩容，队列空了自动缩容，特别适合上游异步任务触发的推理场景，比如批量图片审核或文档解析，流量来得很突然，但消息量是可以度量的。
反应式扩容：让K8s自己决定加不加机器
最基础的自动伸缩是HPA,一条命令即可生效：
kubectl autoscale deployment llama-api --cpu-percent=70 --min=2 --max=10
CPU超过70%自动加副本，低于阈值自动回收，但CPU指标对GPU推理服务往往不够灵敏，瓶颈经常出在GPU利用率或显存占用上，更可行的做法是暴露自定义指标到Prometheus，把GPU-Util作为HPA的度量来源，或者干脆用KEDA监听请求队列长度，队列一长立即扩容。
反应式扩容的副作用是延迟,从指标触发到新副本就绪通常需要几分钟，所以它适合兜底，不适合当主力，真正的大流量来临时，提前扩好的实例才是主力。
地域扩容：为什么北京上海之外还要备一个节点
说到扩容,不能只盯着机器数量，还得看地域分布，一个中心节点扛全国流量，延迟和稳定性都吃力，华东用户请求打到华北机房，光网络往返就多几十毫秒，体验差别明显，业内专家指出，相当一部分生产级推理服务已经采用多地域多节点架构：在北京、上海、广州各放一组推理节点，配合DNS就近解析，用户访问延迟明显下降，单点故障时流量可以自动切换。
地域扩容在成本上有另一层好处,不同地域的GPU算力租赁价格和库存余量不一样，把峰值流量切到价格更低的区域节点，等于用调度换预算，多地域部署不是大厂的专利，小团队用两家云厂商各开一个轻量集群，也能达到同样的效果。
扩容之外，先想想怎么把算力需求降下来
加卡是最省事的方案,也是最花钱的方案，模型侧的优化往往能在投入更小的情况下让吞吐大幅提升，扩容和优化两件事应该同时做，不是二选一。
- 模型量化：FP16权重换成INT8或INT4，显存占用明显下降，推理吞吐随之提升，多数开源模型对INT8量化兼容良好，实际操作中只需少量校准数据。
- 连续批处理：把动态到达的请求拼在同一个batch里处理，而不是等凑够一定数量才开工，vLLM这类框架内置了continuous batching能力，换框架不动模型就能看到吞吐改善。
- 蒸馏和小模型：用蒸馏后的小模型替代原模型，单次请求的算力消耗成倍下降，常见做法是保留大模型做离线蒸馏，在线服务全部切到小模型，效果接近但成本低得多。
- 缓存兜底：相似问题直接复用历史答案，不重新计算，高频推荐和客服场景中，缓存能抵消一部分峰值压力，相当于给推理服务加了免费带宽。
模型上线后请求激增时推理算力该怎么扩容，答案不是无脑加卡，而是先用压测找瓶颈，再用K8s+HPA+Cluster Autoscaler搭自动化弹性底座，结合时间窗口预测和模型侧优化，让每一分GPU预算都花在刀刃上。
模型上线后请求激增时推理算力扩容常见问题
Q1：请求激增时已经在排队，扩容来不及怎么办？
先做三个动作：给服务设置快速失败和队列上限，避免连接全部占满导致雪崩；把非核心推理任务切到低优先级队列或直接降级；如果主服务有抢占式实例，确保能快速切换到按需实例，忙时先保可用性，再谈效率。
Q2：推理算力扩容方案中，横向扩容和纵向扩容该怎么选？
显存没满而GPU算力吃紧时,横向扩容更合适，加实例分摊请求；单卡显存放不下模型，或者KV Cache膨胀明显时，纵向换大显存卡才能解决，多数生产场景是基座用纵向满足容量上限，流量上升时靠横向扩响应。
Q3：预算有限时，扩容和优化哪个优先级更高？
先做模型层面优化,包括量化、连续批处理和缓存，瓶颈依然明显时再扩容，这条路能在较小预算投入下榨出可观的推理吞吐提升，也是开源社区实践中验证过的默认路径，GPU算力租赁价格近年来选择更多样，但模型优化的边际回报长期高于盲目加卡。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/789844.html
