本文评估口径：本文围绕 GPU推理副本数设置，不承诺通用性能指标，只给上线前初始副本数判断框架；最终容量仍需基于目标模型、硬件、推理框架和真实请求做压测验证。
GPU推理副本数设置不是简单把副本开到 CPU 服务那样多。一个副本会占用模型权重、运行时缓存、KV Cache 或批处理缓冲，不同并发下的显存曲线也不同。更可靠的做法是先确定单副本能承载什么，再决定副本数和扩缩容策略。
先确认单副本能否稳定装下模型
Kubernetes 支持通过设备插件把 GPU 作为可调度资源暴露给 Pod，容器通常以资源请求方式声明需要的 GPU 数量[1]。但调度成功只说明资源被分配，不代表模型在目标并发下显存足够。
显存判断应拆成三层：
- 静态占用：模型权重、推理引擎、运行时库和常驻缓存。
- 动态占用：请求上下文、batch、KV Cache、输入输出张量。
- 安全余量：框架碎片、峰值请求、重试和监控采样带来的额外波动。
如果单副本在低并发下已经接近显存上限，继续增加副本数并不能解决问题，反而可能导致调度失败或 OOM。此时应先考虑模型量化、batch策略、显存隔离或更合适的 GPU 规格。
图1：GPU推理副本数设置中显存、并发、延迟和调度边界的判断矩
再估算单副本并发上限
副本数的核心问题是：一个副本能在目标延迟内处理多少请求。对于文本生成、图片生成、Embedding 或传统模型推理，这个上限差异很大。不能只看平均 QPS，还要关注 P95 / P99 延迟、排队时间和失败率。
一个可落地的估算顺序是：
- 固定模型版本、镜像、GPU规格和推理框架[1]。
- 从低并发开始压测，记录显存、GPU利用率、延迟和错误率。
- 找到延迟明显抬升或显存接近阈值的拐点。
- 把拐点前的稳定吞吐作为单副本容量，再加安全折扣。
这里不建议直接用离线 benchmark 结果推生产副本数。真实流量的输入长度、请求峰谷、缓存命中和下游依赖都会改变容量判断。
图2：GPU推理副本数设置中用显存余量、并发拐点和延迟目标估算
副本数要和GPU调度边界一起看
当副本需要独占整卡时，副本数上限受 GPU 卡数影响；当平台采用 MIG、时间片或其他共享方式时，还要关注隔离粒度、显存边界和调度策略。副本数决策会直接受到 GPU调度 模型影响，不能只由应用团队单独设置。
常见场景可以这样判断：
| 场景 | 初始副本策略 | 风险点 |
|---|---|---|
| 单模型低并发 | 1-2 个副本起步 | 冷启动和单点维护窗口 |
| 多模型共享GPU | 按显存和优先级切分 | 互相抢占、延迟抖动 |
| 峰值明显业务 | 保留最小常驻副本 + 弹性扩容 | 冷启动时间可能赶不上流量峰值 |
| 强SLO服务 | 按P95/P99容量倒推副本 | 成本较高，需要容量冗余 |
扩缩容不能只看请求数
Kubernetes HPA 可以基于指标调整副本数[2]，KServe 等推理平台也提供推理服务部署与伸缩能力[3]。但 GPU 推理扩容存在镜像拉取、模型加载和显存初始化时间，扩容速度通常慢于普通无状态服务。
因此，GPU推理副本数设置要同时规划最小副本数、预热策略和流量峰值保护。对于冷启动长的大模型，完全依赖突发扩容可能无法满足延迟目标。
上线前用四个问题定初始值
建议上线评审时直接回答：
- 单副本显存是否稳定？低并发和目标并发下是否都保留安全余量。
- 单副本容量是多少？用压测拐点而不是理论吞吐做依据。
- 扩容要多久生效？包含调度、镜像、模型加载和就绪检查时间。
- 失败时如何降级？是否能限流、排队、切备用模型或临时增加节点。
如果这四个问题无法回答，副本数就不应直接写死为生产结论。可以先采用保守初始值，上线后用真实流量校准，再逐步调整。
图3：GPU推理副本数从初始估算、压测验证到线上校准的上线验证
小结
GPU推理副本数设置要从单副本显存开始，而不是从期望 QPS 倒推一个看似整齐的数字。先确认模型能稳定运行，再通过压测找到单副本容量，最后结合调度边界、扩缩容速度和延迟目标确定初始副本数。
适合生产的副本数不是一次算出来的，而是“初始估算 + 压测验证 + 线上校准”的结果。
参考资料
常见问题
GPU推理副本数设置可以直接按QPS计算吗？
不建议只按QPS。GPU推理还受显存、输入长度、batch策略、延迟目标和冷启动影响。QPS可以作为结果指标，但不能替代显存和延迟拐点测试。
一个GPU上可以放多个推理副本吗？
取决于平台能力、模型大小、显存余量和隔离方式。若没有明确的显存隔离或共享策略，多个副本可能互相影响，导致延迟抖动或显存不足。
HPA适合GPU推理服务吗？
可以使用，但要谨慎选择指标和窗口[2]。普通CPU利用率不一定反映GPU排队情况，扩容还涉及模型加载时间。建议结合请求队列、延迟、GPU指标和最小常驻副本设计。
副本数越多延迟一定越低吗？
不一定。副本数过多可能带来显存浪费、调度失败、冷启动增加和缓存命中下降。只有当瓶颈来自排队且资源足够时，增加副本才更可能降低延迟。
