做推理服务硬件配置指南，先别问哪种设备“更快”，要先明确服务承诺：每秒处理多少请求、用户能等多久，以及高峰时有多少请求同时到达。同一模型在不同输入长度、批处理方式和软件后端下，结果可能差很多；只比较设备规格表，往往选不准。
先区分要优化的时延和负载
并发量是同时在处理或等待的请求数，不等同于每秒请求数。面向在线交互的服务，除了平均响应时间，还应看 p95 latency（95% 请求不超过的时延）和首 token 时延；批量任务则更关心单位时间处理量、整体完成时间和每次推理成本。
记录真实请求的输入长度、输出长度、到达频率和峰值时段，再设定可验收的目标。目标要按业务定义，不能把某个毫秒数当成所有模型通用的门槛。推理服务硬件配置指南的第一步，是用实际流量画像代替“并发很多”这种模糊描述。
CPU 与 GPU 的差异，落在工作负载上
CPU：适合低并发和轻量、规则明确的任务
CPU 通常更适合小模型、短输入、请求量不高的服务，以及预处理、排序、特征计算等任务。部署灵活，也便于与应用服务共置；但大型神经网络或高并发生成任务，可能需要更多核心才能提升吞吐，功耗、机架空间与调度开销也要计入成本。可将 AWS Graviton3 作为 ARM 服务器平台的评估对象，但实际效果取决于程序是否支持相应架构及所用推理后端。
GPU：适合并行计算密集、吞吐目标较高的任务
GPU 能并行执行大量计算，通常更适合较大的深度学习模型、图像处理和文本生成等负载。请求较多时，合适的批处理可能提高吞吐；代价是设备采购或租用成本较高，显存容量、批处理等待和设备共享也会影响时延。NVIDIA T4 可作为常见推理加速卡之一纳入候选，但型号名称不能替代针对目标模型的压测。
因此，低并发、短请求且时延达标时，CPU 可能更经济；并发持续较高、计算量大，或 CPU 达不到吞吐目标时，再评估 GPU。GPU 不保证每个请求都更快：小任务若受排队、数据传输或批处理策略影响，端到端时延未必占优。
用同一套压测比较，而不是对照峰值参数
- 固定测试条件：使用同一模型版本、输入样本、精度和推理框架，记录硬件型号与软件配置。若使用量化，也要将精度变化纳入验证。
- 逐步增加并发：从 1 个并发开始，之后逐级加倍，直到超过预计峰值。每档运行足够时间覆盖预热和稳定阶段，并重复测试，避免把短暂波动当成结果。
- 记录服务指标：至少记录请求吞吐、p50 与 p95 时延、错误率、队列长度和设备利用率。生成式服务还应分开记录首 token 时延与输出 tokens/s。
- 加入实际峰值负载：按线上输入长度分布回放流量，比较是否满足目标时延和错误率，再计算每千次请求或每单位输出量的成本。
比较时要观察拐点：并发提高后，吞吐是否继续增加，p95 是否突然上升，队列是否持续增长。若 GPU 的批处理提高了吞吐，却让短请求等待过久，应缩短批处理等待窗口或拆分服务；若 CPU 已达到时延目标且利用率仍有余量，则未必需要迁移。
按结果做选择，并留出验证空间
决策可分三种：CPU 达标且成本更低，优先用 CPU；GPU 明显改善吞吐或时延，且总成本可接受，采用 GPU；两者各有优势时，把轻量请求留在 CPU、重任务放到 GPU，或按不同模型拆分部署。多模型共用设备时，还要测资源争用和单个服务故障的影响。
这份推理服务硬件配置指南不以某个型号作固定答案：真正的比较对象应是“设备加软件栈”在目标流量下的表现。上线前用灰度流量复核监控数据，流量变化、模型更新或后端升级后重新压测，再依据成本与服务目标调整。
常见问题
并发低就一定选 CPU 吗？
不一定。若单个请求计算量很大，GPU 仍可能更合适；应以目标时延和单请求成本实测判断。
只看平均时延够不够？
不够。平均值可能掩盖排队造成的慢请求，至少同时关注 p95、错误率和队列变化。
批处理越大越好吗？
不是。批处理常能增加吞吐，但可能增加等待时间和显存占用，应按时延目标调节。
多久需要重新比较一次？
模型、推理框架、输入分布或流量规模改变时应重新压测；没有变化时也可按既定运维周期复核。
