推理服务器的 GPU 数量，应先满足模型与运行时的显存驻留，再用真实请求分布验证并发、首字延迟和持续吞吐。模型参数量只能提供初始估算，量化方式、上下文长度、KV Cache、动态批处理、框架开销和多租户隔离都会改变最终容量。
先建立请求与服务等级基线
收集输入长度、输出长度、峰值并发、请求到达分布、首字延迟和完整响应时间，不要只用固定长度的离线样本。在线问答、批量摘要和嵌入服务的调度特征不同，应分别测量。还要明确单实例故障时需要保留多少服务能力，避免正常状态刚好满载。
把显存拆成可解释的组成
显存表应区分权重、运行时工作区、KV Cache、批数据、通信缓冲和框架保留空间。不同精度和推理引擎会改变占用，但不能在未经质量验证时直接采用更低精度。多模型共卡还要观察峰值是否重叠，并保留碎片和版本升级余量。
用批处理和并发曲线找工作点
逐步增加并发与批量，记录吞吐提升、排队时间、显存和功耗，找到满足服务等级的稳定区间。动态批处理可能提高吞吐，也可能增加等待时间；长短请求混合时应使用生产分布回放。最终容量以持续测试的低分位表现和故障后结果为依据。
项目核验要点
- 固定模型、框架、驱动、精度和推理引擎版本。
- 同时记录平均值、分位延迟、吞吐、显存和错误率。
- 验证单卡、单机、多机以及单实例退出后的容量。
- 将增长余量、升级窗口和回退条件写入容量表。
建议先用一台代表性服务器形成“并发—批量—延迟—显存”曲线，再按照可用性目标扩展节点数量。这样得到的是可复核的服务容量，而不是脱离业务的峰值算力比较。
WeChat
Profile