推理服务的硬件问题，往往不是“算力不够”这么简单：模型可能能加载，却在并发上升后因显存不足频繁排队；也可能单卡运行正常，多卡通信却拖慢响应。制定推理服务硬件配置指南时，应先明确模型、请求长度、并发目标和响应要求，再逐项验证资源是否匹配。
先算显存：权重之外还有运行开销
模型权重是显存的基础占用，但不是总占用。推理时还要容纳 KV 缓存、临时张量、框架及算子工作区。权重大小可先按“参数量 × 每参数字节数”粗估：低精度格式通常比 FP32 占用少，但实际节省会受量化方式、对齐和运行时实现影响。
对自回归模型，KV 缓存会随上下文长度和并发请求增长。单条序列的缓存可按“2 × 层数 × KV 头数 × 每头维度 × token 数 × 每元素字节数”估算，再乘以并发数。这个估算不含额外工作区，应留出余量；长上下文场景尤其要避免只按模型权重选卡。
分清算力、带宽与响应延迟
算力不是所有阶段的唯一限制
输入提示较长时，预填充阶段会集中处理大量 token；逐 token 生成阶段则更受内存带宽、批处理方式和请求排队影响。因此，仅看芯片峰值算力不能推断服务吞吐。记录首 token 延迟、生成速度和不同并发下的 p95 延迟，才能看出瓶颈落在哪个阶段。
用目标负载比较设备
NVIDIA L4、A10 与 H100 属于不同定位的加速卡，显存容量、带宽、算力和功耗配置并不相同；AMD Instinct MI300X 则采用不同的软件与设备生态。不能只按型号或峰值参数横向下结论：应确认推理框架和算子支持，再用同一模型、精度、输入长度及并发配置实测。较小规模、并发较低的服务可优先比较单卡成本与功耗；高并发或长上下文负载则要重点核对显存余量和带宽。
排查主机、互联和机房条件
- 主机内存：检查模型加载、缓存和运行进程的峰值占用；内存不足会导致加载失败或系统换页，延迟可能明显恶化。
- 设备互联：多卡部署要确认 PCIe 代际、通道数和拓扑，检查卡间通信是否经过不理想的路径。若使用 NVLink 等高速互联，仍需验证框架实际采用的通信方式。
- 网络：测量客户端到服务端的带宽、往返时延和突发流量下的丢包情况。网络不适合承载超出链路能力的请求流量；多机部署还应检查节点间通信。
- 供电与散热：按整机和加速卡规格核对电源余量、机柜供电及进风条件。持续负载下观察温度、频率和功耗，确认没有热降频或功率限制。
上线前按这套流程验证
- 固定模型版本、推理精度及服务框架，记录权重、最大上下文和目标并发。
- 估算权重与 KV 缓存占用，启动服务后观察显存、主机内存和加载时间，留出运行余量。
- 构造短输入、长输入和混合长度请求，逐步增加并发；每档记录吞吐、首 token 延迟、生成速度及 p95 延迟。
- 并发压测时同步查看设备利用率、显存带宽、温度、功耗、网络和多卡通信，定位先饱和的资源。
- 调整批处理上限、并发队列或硬件配置后，重复同一组测试，并验证持续运行时指标稳定。
这份推理服务硬件配置指南的关键不是挑一张参数最高的卡，而是让显存、带宽、互联和整机条件适配真实请求。上线决策应以目标负载下的压测结果为准，并保留扩容余地。
常见问题
显存够放下模型，就一定能启动服务吗？
不一定。KV 缓存、工作区和运行时开销也占用显存，需在目标上下文与并发条件下实测。
单卡测试通过，能说明多卡配置也合适吗？
不能。多卡会增加设备间通信要求，应检查拓扑与通信表现，并在目标并发下重新压测。
压测时优先看哪个指标？
按服务目标同时看首 token 延迟、生成速度、吞吐和 p95 延迟，并结合资源监控找出先饱和的环节。
