同一个模型，供内部少量用户偶尔调用，与面向大量用户持续提供服务，所需硬件可能完全不同。制定推理服务硬件配置指南时，应先回答两个问题：高峰时有多少请求同时运行，业务能接受多长等待时间？再结合模型、输入长度和软件环境选择设备，而不是仅按参数规模估算。
先把并发和时延目标说清楚
并发量不是日均请求数，而是高峰时尚未完成的请求数量。时延也不宜只看平均值：交互式服务应关注首 token 时延和高分位响应时间；离线任务则更重视单位时间完成的请求数，即吞吐量。两种目标对硬件的偏好不同。
- 低并发、宽松时延：先评估多核 CPU，尤其是模型较小、请求不频繁或部署环境不便使用加速器的服务。
- 并发较高、响应时间敏感：评估专用加速器，重点测量并发上升时的响应曲线，而非只看单请求速度。
- 批量处理、时限较宽：可以用动态批处理合并请求提升设备利用率，但批次等待会增加单个请求的延迟。
按服务形态选择设备组合
小规模、低频调用
先用现有服务器验证 CPU 推理是否达标。Intel Xeon Scalable 和 AMD EPYC 都属于常见服务器处理器系列，可作为 CPU 方案的评估对象。优点是部署路径相对直接，也便于与既有服务共用主机；不足是模型计算量增大或并发持续升高时，可能难以同时满足吞吐和时延目标。应实测核心数、内存带宽与请求表现，不能只按处理器型号推断容量。
高并发或严格交互时延
可比较 Intel Gaudi 2 等 AI 加速器，以及 Google Cloud TPU 等云端加速平台。选择时要核对模型框架、算子支持、部署工具链和数据所在环境。加速器通常适合并行计算密集的负载，但迁移和运维成本可能更高；云端平台可减少自建设备工作，却需要把网络、实例供给和持续使用成本纳入评估。不同产品不能仅凭标称算力直接横向换算。
用压测把配置落到实处
- 固定测试条件：记录模型版本、精度、输入与输出长度、软件版本和服务参数；同一轮比较尽量只改变硬件或并发设置。
- 复现真实请求：按实际流量构造短输入、长输入和高峰请求，逐步增加并发。没有生产数据时，可先用代表性样本测试，再向业务团队确认边界情况。
- 同时记录指标：查看吞吐量、首 token 时延、整体响应时间的高分位值，以及设备显存或内存占用。只看平均值容易漏掉排队造成的慢请求。
- 验证连续运行：在预计高峰负载下持续运行一段时间，观察是否出现排队增长、内存不足或性能波动，并留出余量应对流量起伏。
若显存吃紧，可评估量化，但需用目标硬件和真实任务检查精度影响、算子支持与速度变化。若时延超标，应先判断瓶颈在模型计算、请求排队还是数据传输，避免只增加设备却没有消除瓶颈。
配置决策应保留调整空间
采购或选云实例前，建议分别测单请求、目标并发和高于目标的压力档，并记录每档的吞吐与高分位时延。最终选择能达到服务目标、且在持续负载下不易触顶的方案。对于推理服务硬件配置指南，核心不是给出一张适用于所有团队的设备清单，而是让硬件选择能由负载证据复核，并在模型、流量变化时重新验证。
常见问题
并发量应按日均还是高峰估算？
以高峰时同时处理的请求为主，并参考高峰持续时间；日均值容易低估排队压力。
平均时延达标就可以上线吗？
不够。还应检查高分位响应时间，确认少数慢请求不会违反业务目标。
量化后一定能降低硬件需求吗？
不一定。它可能减少权重占用，但速度和精度收益取决于模型、量化方式及设备支持，需实测。
什么时候重新做硬件评估？
模型版本、输入长度、并发目标或软件栈发生明显变化时，应重新压测并检查服务目标。
