AI推理业务选择GPU服务器，不能只看模型参数量或“是否使用了深度学习框架”，而要同时看单位时间的计算量、请求并发、输入输出规模、显存占用和延迟目标。通常，计算密集、可批处理、并发波动明显或需要持续生成大量结果的推理业务，更容易从GPU中获得收益；请求量很低、模型很小、处理链路以串行逻辑和数据整理为主的业务，则不一定适合优先部署GPU服务器。

判断是否适合，建议先用目标模型、真实请求分布和明确的服务等级目标做基准测试。只有当GPU方案在目标并发下同时满足延迟、吞吐、显存和稳定性要求，并且仍保留可解释的增长余量时，才适合进入容量规划。单看GPU利用率高低，不能直接得出选型结论。

先把负载画像写清楚

容量规划的起点不是服务器型号，而是业务负载。至少需要记录以下变量：

• 请求类型：交互式单请求、批量任务、异步队列，还是实时流式请求。
• 并发定义：同时连接数、同时执行数、等待队列长度，不能把这几个概念混为一谈。
• 请求规模：文本输入长度、输出长度、图像分辨率、音频时长、视频帧数等。
• 峰值特征：平均请求量、业务高峰、突发流量和高峰持续时间。
• 延迟目标：关注首字节、首Token、单请求完成时间，还是整批任务完成时间。
• 模型状态：模型是否常驻显存，是否需要频繁切换模型或加载不同版本。
• 结果要求：是否允许量化、降采样、减少生成步数或降低输出质量。

如果已知基础请求量和峰值放大系数，可以先用下面的关系估算峰值需求：

D_peak = D_base × K_peak

其中，D_base是基准时间内的平均请求需求，K_peak是从历史监控或业务排期中测得的峰值系数。没有真实业务数据时，不应直接套用固定的峰值倍数，而应先采集一段能够覆盖高峰和低谷的流量记录。

对于大语言模型，单纯统计请求数通常不够。相同的请求数，输入长度、输出长度和上下文长度不同，消耗的计算资源与显存也可能明显不同。可以先估算Token需求：

T_demand = request_rate × (input_tokens + output_tokens)

这只是容量规划的初步指标。输入Token、输出Token和KV Cache对资源的影响并不完全相同，最终仍应使用真实长度分布进行测试。

图像和视频推理也不能只按“图片数量”规划。图像分辨率、批大小、模型类型和预处理方式都会影响结果；视频还需要考虑每秒帧数、片段长度和是否逐帧推理。音频业务则需要记录音频时长、采样处理方式以及是否采用流式识别。

按模型和并发判断适用边界

更容易适合GPU服务器的场景

以下业务在满足显存、延迟和部署条件时，通常更适合优先测试GPU服务器：

这类场景的共同点是：计算阶段占比高，而且多个请求可以在设备上并行执行。若测试中吞吐随着并发上升而增加，延迟仍在目标范围内，GPU资源也没有因显存或数据搬运出现明显瓶颈，GPU服务器才具有较明确的容量价值。

通常不应优先选择GPU的场景

以下情况并不是绝对不能使用GPU，而是说明GPU方案需要更严格的成本和性能验证：

1. 模型很小、请求量很低、并发长期接近空闲

如果单请求计算时间很短，CPU已经能够满足延迟要求，GPU的初始化、数据传输、运行时调度和显存占用可能无法换来可观察的业务收益。此时应先对比CPU基线，再决定是否引入GPU。

1. 请求无法形成有效批处理

如果请求到达非常零散，业务又要求每个请求立即执行，动态批处理可能会增加等待时间。此时即使GPU峰值算力较高，也可能因设备没有得到持续利用而无法改善整体延迟。

1. 主要耗时在预处理、后处理或串行业务逻辑

例如数据解码、复杂规则判断、数据库读取、结果整理占据大部分时间，而模型本身只占很小比例。测试时可能出现GPU利用率不高、CPU利用率持续较高的现象。这类业务应先定位流水线瓶颈，而不是直接增加GPU数量。

1. 模型频繁切换，无法稳定常驻显存

频繁装载和卸载模型会带来等待时间与显存碎片问题。若一个服务需要在多个模型之间频繁切换，应分别测量模型加载时间、切换频率和常驻方案，而不能只测某个模型的热启动性能。

1. 模型或上下文规模超过单卡显存，但没有验证多卡通信

多GPU并不等于线性扩展。模型切分、张量通信、同步等待和跨设备数据搬运都可能吞掉增加的算力。只有在目标模型、目标上下文和目标并发下验证过多卡方案，才可将其作为容量结论。

1. 延迟目标极严，但请求规模非常小

对极短请求而言，调度、排队和数据搬运的固定开销可能占主要比例。若业务更关注单请求尾延迟，而不是批量吞吐，应重点测试并发为低值时的p95、p99延迟，不能用高并发吞吐结果替代。

资源变量决定GPU方案能否落地

显存不是只看模型权重

模型能否加载只是第一道门槛。实际显存需求通常包括：

M_required =
M_weights
+ M_runtime
+ M_activation
+ M_KVCache
+ M_batch
+ M_reserved

M_weights是模型权重占用，M_runtime是推理框架和运行时开销，M_activation是中间激活，M_KVCache主要影响长上下文生成，M_batch与并发和批处理有关，M_reserved则用于覆盖波动和临时开销。

因此，模型在单请求下能够加载，并不代表在目标并发下能够稳定运行。尤其是生成类模型，随着上下文长度、并发请求数和输出长度增加，KV Cache可能成为显存压力的主要来源。

如果采用低精度或量化，应同时复测以下内容：

• 模型输出质量是否达到业务要求；
• 不同输入长度下的显存峰值；
• 首Token延迟和持续生成速度；
• 批处理后是否出现更高的尾延迟；
• 部署框架是否对目标模型和算子提供完整支持。

GPU利用率低，不代表服务器有余量

GPU利用率需要和其他指标一起解释：

• GPU计算利用率低、CPU利用率高：可能是预处理、后处理或数据供给不足。
• GPU计算利用率低、队列较长：可能存在同步等待、数据搬运或框架调度问题。
• GPU利用率高、显存充足但p99延迟超标：可能是计算已经达到瓶颈，或并发超过了可持续区间。
• 显存接近上限、GPU利用率不高：可能是模型驻留、KV Cache或批处理限制了并发。
• GPU和CPU都不高，但延迟仍高：需要检查存储读取、线程调度、锁等待和服务间调用。

不能把“显存还有空间”直接理解为“还能增加同等比例的并发”，也不能把“GPU利用率达到较高水平”直接理解为“已经完成容量验证”。

多模型、多租户需要按资源池计算

如果同一台服务器承载多个模型，应分别测出每个模型在目标SLO下的可持续吞吐量。可以用下面的方式做初步规划：

U_total = Σ(D_i / Q_i)

其中，D_i是第i类请求的峰值需求，Q_i是该类请求在目标延迟约束下测得的可持续吞吐量。U_total接近或超过设备的有效容量时，不能只依靠平均流量判断是否安全。

这个公式是规划近似值。模型之间如果共享显存、共享CPU预处理线程或存在不同的请求长度分布，还需要通过混合负载测试修正结果。

测试环境与方法

先固定测试条件

测试环境应尽量减少与业务无关的变量。至少记录以下信息：

测试应区分冷启动和热运行。冷启动需要记录模型加载和首次请求时间，热运行则用于评估长期稳定吞吐。二者不能混在同一组结果中，否则会误判持续推理能力。

按并发梯度进行测试

建议至少覆盖以下测试状态：

1. 单请求或低并发，观察固定调度开销和基础延迟。
2. 业务常态并发，观察平均吞吐和典型延迟。
3. 计划峰值并发，验证是否满足SLO。
4. 高于计划峰值的压力区间，寻找排队和尾延迟开始明显上升的位置。
5. 持续运行测试，观察显存增长、内存泄漏、温度变化和吞吐波动。
6. 突发流量测试，观察队列是否快速堆积，以及恢复到正常负载所需的时间。

每个并发档位都应使用相同的请求分布，并保留预热阶段。对于动态批处理，要分别记录批大小、等待时间和实际合并情况，因为“配置了批处理”不等于“请求实际形成了有效批次”。

指标必须同时覆盖性能和稳定性

建议采集以下指标：

• 吞吐：请求每秒、Token每秒、图片每秒或音频处理速率；
• 延迟：平均值、p50、p95、p99，以及首Token或首结果延迟；
• 排队：等待时间、队列长度、批处理等待时间；
• 资源：GPU计算利用率、显存使用、CPU利用率、主机内存和数据传输情况；
• 稳定性：超时、错误、显存不足、进程重启和吞吐波动；
• 质量：输出正确性、识别质量、生成结果质量和量化后的偏差。

其中，p95和p99比平均延迟更能反映高并发下的用户体验。若平均延迟较低，但p99随着并发快速上升，说明服务已经进入排队或资源争用区间。

看懂测试结果：瓶颈决定是否适合

一个重要判断是：吞吐达标不等于业务达标。如果业务是离线批处理，吞吐通常优先；如果业务是在线问答、实时识别或交互生成，则必须同时满足首结果延迟和尾延迟目标。

用测试结果做容量规划

以SLO约束下的吞吐作为容量基线

设单台GPU服务器在目标请求分布、目标并发和目标延迟约束下测得的可持续吞吐为Q_slo，峰值需求为D_peak，预留系数为R，则同构服务器的初步数量可以按以下方式估算：

N = ceil(D_peak × (1 + R) / Q_slo)

这里的R不能随意填写。它应综合以下因素确定：

• 历史峰值与平均流量的差异；
• 未来业务增长速度；
• 模型版本更新带来的资源变化；
• 服务器维护或故障时是否需要保留服务能力；
• 流量是否存在短时间突发；
• 多模型混部时的资源争用程度。

如果业务请求大小差异很大，不能用单一的Q_slo代表全部流量。应按输入长度、输出长度、分辨率或音频时长分桶，分别测试后再进行加权规划。

用并发关系检查结果是否合理

对于稳定服务，可以用排队理论中的基本关系检查测量结果：

并发数 ≈ 到达速率 × 平均处理时间

该关系适合做一致性校验，但不能替代p95和p99测试。因为长尾请求、批处理等待和突发流量会让平均值掩盖真实的排队风险。

例如，测试记录显示请求速率没有明显增加，但并发数和p99延迟同时上升，通常说明处理时间或排队时间正在扩大。此时应先定位资源瓶颈，而不是简单增加客户端并发。

什么时候需要重新测试

以下变化发生后，原有GPU容量结论通常不能直接沿用：

• 模型版本、权重、精度或量化方式发生变化；
• 上下文长度、最大输出长度或图像分辨率发生变化；
• 请求比例从短请求转向长请求；
• 动态批处理、并发上限或队列策略发生变化；
• 驱动、运行时、推理框架或编译方式发生变化；
• 从单模型部署改为多模型混部；
• 从单卡改为多卡，或从单机改为多实例；
• 业务SLO从吞吐优先改为尾延迟优先。

复测时不应只跑一组“最高并发”。至少要重新覆盖低并发、常态并发、峰值并发、突发流量和持续运行五类状态，并保留与旧版本相同的请求样本，便于比较变化来自模型还是流量。

监控与扩容触发点怎么定

扩容阈值应从压测曲线中确定，而不是直接套用一个固定的GPU利用率。具体方法可以分为四步：

1. 在多个并发档位下记录吞吐、p95、p99、队列长度、GPU计算利用率和显存使用。
2. 找到延迟开始明显上升、吞吐增长变慢或错误率增加的“容量拐点”。
3. 将业务实际峰值与该拐点比较，预留增长、突发和故障切换空间。
4. 将扩容条件设置在SLO即将恶化之前，并增加连续观测时间和缩容冷却时间，避免流量短暂波动造成频繁扩缩。

建议至少设置以下监控维度：

• 需求侧：请求速率、Token速率、请求长度和峰值持续时间；
• 服务侧：排队时间、并发数、p50/p95/p99延迟、超时和错误率；
• GPU侧：计算利用率、显存使用、显存峰值、批大小和设备异常；
• 主机侧：CPU、内存、线程、存储读写和数据传输；
• 模型侧：输出质量、模型版本和精度配置。

当队列持续增长、p99接近或超过业务目标、显存峰值触及测试边界，或者按照增长预测计算出的剩余容量已经无法覆盖下一阶段峰值时，应进入扩容或降载评估。反过来，如果GPU利用率偏低但CPU、队列或数据处理环节已经饱和，扩容GPU通常不是第一动作，应先处理真正的瓶颈。

因此，AI推理业务选择GPU服务器的核心判断可以归纳为：模型计算是否足够重、请求是否能够有效并行、显存是否覆盖目标并发、GPU是否确实是主要瓶颈，以及在目标SLO下是否仍有可验证的容量余量。满足这些条件时，GPU服务器更适合承担推理负载；若主要问题是低并发、串行处理、频繁切换或数据供给不足，则应先完成CPU基线和链路测试，再决定是否采用GPU方案。