AI推理服务器需要什么配置？CPU、GPU、内存与存储规划

模型训练完，真正的挑战才刚开始：怎么把它稳定、高效、低成本地跑在线上，服务真实的用户请求。很多人直接把训练用的机器拿来推理，结果发现显存浪费、延迟忽高忽低、并发上来就卡。AI 推理服务器的配置逻辑和训练完全不同——训练追求峰值算力和大规模并行，推理追求的是低延迟、高吞吐和好的性价比。这篇文章按显存、CPU、内存、存储、网络、并发这几个维度，讲清楚推理服务器该怎么规划，以及量化和推理框架在这里扮演什么角色。

一、推理和训练的资源需求差别

先建立正确的预期。训练时 GPU 长时间满载、需要保存梯度、需要频繁同步，显存和互联都是瓶颈；推理时 GPU 往往是"间歇性"工作——来一个请求算一次，请求之间可能空闲，瓶颈转移到显存容量、批处理策略和内存带宽上。

最典型的差别是：训练几乎只看 GPU，推理则要综合考虑显存、CPU（预处理和后处理）、内存、存储、网络。一个常见的失误是推理服务延迟高，排查发现 GPU 利用率只有 30%，瓶颈其实在 CPU 的图像预处理或文本分词上。

所以推理服务器的配置原则是：GPU 显存要够装模型和处理并发，其余部件要能"喂饱"GPU，别让它在等数据。

二、显存：决定能装多大的模型

推理服务器的第一硬约束还是显存。模型权重、KV Cache（推理过程中的键值缓存）、以及框架开销都要占显存。

经验量级（具体估算见 097 篇）：FP16 下模型权重约等于参数量 × 2 字节，INT8 约 × 1 字节，INT4 约 × 0.5 字节。KV Cache 的大小和模型的层数、隐藏维度、序列长度、并发数都相关，长上下文、大并发会显著抬高它的占用。这就是为什么很多推理服务"模型加载进去了，一上并发就 OOM"。

结论：选显存时不能只按"模型权重刚好装下"来算，要额外留出 KV Cache 和运行时开销的空间。一个常见的经验做法是，让权重占用不超过总显存的 60% 到 70%，剩下的留给缓存和并发。如果模型本身就很大，就要考虑多卡切分或量化。

# 查看推理时显存占用（模型加载后、压测中都要看）
nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv
# 持续观察，判断显存随并发的变化
watch -n 1 nvidia-smi
# 用 PyTorch 查看显存分配情况（在服务进程内）
# torch.cuda.memory_allocated() / torch.cuda.max_memory_allocated()

三、CPU：预处理、后处理和调度

GPU 负责模型的前向计算，但请求进来和结果出去都要经过 CPU。CPU 承担的工作包括：网络请求接收、文本分词（tokenize）、图像解码和缩放、数据格式转换、批处理组装、结果后处理（如解码、格式化）。推理服务的 CPU 用量和请求类型强相关。

如果是文本模型，分词和调度是主要 CPU 开销；如果是视觉模型，图像解码和预处理可能很重；如果是语音模型，音频解码也是 CPU 密集的。经验上，小模型推理可以按每张 GPU 配 4 到 8 个 CPU 核，视觉类或预处理重的工作负载建议 8 到 16 核甚至更多。

CPU 的频率对延迟敏感的推理服务有影响，因为预处理是串行的一部分。核数则影响并发能力。如果你的服务延迟高、GPU 却不满载，先看 CPU 使用率是不是打满了。

# 观察推理服务各进程 CPU 占用
top -H -p $(pgrep -f 'python .*serve' | head -1)
# 按核看使用率，判断是否某个环节单线程瓶颈
mpstat -P ALL 2 3    # sysstat 包
# 查看进程的线程级 CPU（识别预处理瓶颈）
pidstat -t -p  1 5

四、内存：模型加载与缓存

主机内存的作用常被低估。它至少要满足：加载模型权重（从磁盘读到内存，再传到显存）、缓存数据集或词表、支撑服务框架的运行时、以及处理并发请求时的临时数据。

经验配比：主机内存建议不低于显存总量的 1.5 到 2 倍。如果显存总和是 80 GB，主机内存至少 128 GB 到 160 GB。这个系数不是绝对的，但如果内存太小，模型加载会变慢、大并发时容易 OOM。

另外，内存不足还会导致模型从磁盘反复读取（page cache 命中率低），拖慢首次响应和冷启动。对于需要频繁加载多个模型的服务（如多模型路由），内存要更充裕。

# 查看内存总量与可用量
free -h
# 查看内存与交换使用，确认没有换出
vmstat 1 5
# 查看进程实际占用内存（RSS）
ps -eo pid,rss,cmd --sort=-rss | head -10

五、存储：模型读写速度与容量

推理服务器的存储需求相对训练小，但对"读取速度"有要求，因为服务启动时要快速把模型加载进显存，冷启动时间直接影响可用性和弹性扩缩容的效果。

建议：模型文件放在 NVMe SSD 上，避免放在慢速网络盘上导致每个副本启动都要等很久。容量按"单个模型大小 × 常驻模型数 + 余量"准备，如果模型很多或要做版本共存，容量要留足。多副本部署时，每个节点本地都要有模型文件副本，或者用足够快的共享存储。

# 查看磁盘读取速度（粗略测试，需谨慎在生产盘上跑）
# hdparm -t --direct /dev/nvme0n1
# 查看磁盘使用与 IO
df -h
iostat -x 2 5    # 关注 %util 和 await
# 查看模型目录大小
du -sh /models/*

六、网卡带宽：被忽视的组成部分

推理服务要对客户端提供接口，网卡带宽决定了单位时间能返回多少数据。对于返回大对象（图像、音频、长文本流）的服务，带宽容易成为瓶颈。

经验参考：文本类推理接口输出小，千兆网卡通常够用；图像、视频、大量并发短请求的场景建议万兆；如果是模型分片跨节点、或者在集群内做推理网关转发，带宽需求更高。另外要注意延迟——有些场景吞吐够但延迟高，靠的是低延迟网络（低延迟网络卡、RDMA 等）。

# 查看网卡速率与状态
ethtool eth0 | grep -E 'Speed|Duplex'
# 查看网卡流量
sar -n DEV 1 3      # sysstat 包
# 简单的带宽测量（需两台机器配合，服务端 nc -l，客户端 dd | nc）

七、并发与批处理：吞吐与延迟的权衡

这是推理服务最核心的调优维度。GPU 擅长并行计算，把多个请求"攒一批"一起算（批处理，batching），能大幅提高 GPU 利用率，提升总吞吐（每秒处理的请求数）；但攒批会让每个请求多等一点时间，增加延迟。

于是有了几个策略：静态批处理（凑够固定数量或超时后一起算）、动态批处理（请求陆续到达时随时组批，框架如 Triton 类思路支持）、连续批处理（continuous batching，新请求可以加入正在进行的批次，是大模型推理框架的关键优化）。目标是让 GPU 尽量不空闲，同时把延迟控制在可接受范围。

调优思路：先测出单请求延迟，再逐步增加并发和批大小，观察吞吐和延迟的变化曲线，找到"吞吐接近饱和、延迟还可接受"的甜点。注意批大小受显存限制，批越大 KV Cache 占用越高，容易 OOM。

# 用压测工具测并发下的延迟与吞吐（示例：locust / wrk / 自定义脚本）
# 文本模型常用压测思路：并发 N，连续发请求，记录 P50/P95/P99 延迟与 QPS
# 观察 GPU 利用率是否随并发上升
nvidia-smi --query-gpu=utilization.gpu,memory.used --format=csv -l 1

八、量化：用精度换资源和速度

量化是推理优化的重要手段，把模型参数从高精度降到低精度，带来三个好处：显存占用下降、计算速度提升、可以跑更大的模型或更高并发。代价是精度可能下降，需要评估对业务效果的影响。

常见精度和直觉量级：FP16/BF16 是常用起点；INT8 显存约减半，多数场景精度损失较小；INT4 显存约降到四分之一，适合显存受限的场景，但要根据任务评估精度；更激进的量化可能带来明显质量下降。量化对资源的影响直接体现在配置规划上——同样的卡，量化后能装更大的模型或更高的并发。

# 量化通常通过框架工具完成，导出后再用推理引擎加载
# 示例思路（具体命令依框架而定）：
# - 训练后量化：用校准数据跑一遍，生成 INT8 模型
# - 权重量化：把权重转成 INT4 格式，推理时反量化
# 加载后确认显存占用是否下降
nvidia-smi --query-gpu=memory.used --format=csv

九、推理框架的定位

推理框架（如 TensorRT 类、vLLM 类、Triton 类等不同思路的产品）负责把模型高效地跑起来，解决几个问题：算子优化、内存管理、批处理调度、多模型管理、服务化接口。

不同框架侧重点不同：有的专注单模型极致优化（编译优化、算子融合）；有的专注大模型推理的显存管理和高并发（分页式 KV Cache、连续批处理）；有的专注多模型多框架的统一服务与调度。选型的思路是先明确你的场景（单模型还是多模型、大模型还是小模型、延迟敏感还是吞吐敏感），再看框架的能力是否匹配，不要盲目追新。

# 用容器部署推理框架是主流做法，便于版本管理和隔离
# docker run --gpus all -p 8000:8000 -v /models:/models <推理框架镜像>
# 验证服务健康
curl -s http://127.0.0.1:8000/health
# 发一个推理请求
curl -s -X POST http://127.0.0.1:8000/predict \
  -H 'Content-Type: application/json' \
  -d '{"input":"hello"}'

十、成本权衡

推理服务的成本优化，本质是在延迟、吞吐、成本之间找平衡点。几个实用的方向。

第一，按需选卡，不要用训练卡跑推理。推理对双精度和大互联的需求低，中等配置的卡配合量化往往性价比更高。

第二，提高单卡利用率。用批处理、连续批处理、多实例（把一张卡切成多个小实例）把 GPU 喂满，同样的硬件服务更多请求。

第三，做好自动伸缩。流量低谷时缩容，减少闲置。但要注意大模型冷启动慢，缩容太激进会导致恢复时延迟尖刺。

第四，区分在线和离线。延迟敏感的在线服务用高配卡保证响应；大批量离线任务用低成本卡，慢慢跑完即可。

常见问题

Q：训练用的服务器能直接拿来做推理吗？
可以，但通常浪费。训练机配置偏重算力和互联，推理更看重显存容量、CPU 配套和性价比。可能的后果是花了高价买算力，实际推理用不上。

Q：推理一定要用 GPU 吗？
不一定。小模型、低并发、对延迟不敏感的场景，用 CPU 也能跑，成本可能更低。但大模型或高并发场景，GPU 几乎是必需的。

Q：显存刚好装下模型，能上线吗？
不建议。还要留 KV Cache 和运行时开销，并发一上来就会 OOM。经验上让权重占比不超过 60% 到 70%。

Q：为什么 GPU 利用率很低，延迟却很高？
大概率瓶颈不在 GPU。检查 CPU 使用率（预处理/分词）、内存是否不足、存储读取是否慢、网络是否拥塞。GPU 在等上游数据。

Q：批处理越大越好吗？
不是。批越大吞吐越高但延迟越高，且受显存限制。要找吞吐和延迟的平衡点，用压测确定合适的批大小。

Q：量化会不会影响效果？
会，程度取决于量化精度和任务。INT8 通常影响较小，INT4 需要评估。上线前务必用业务数据对比量化前后的效果。

总结

推理服务器的配置逻辑和训练不同：训练看 GPU 峰值算力，推理看显存、CPU 配套、内存、存储和网络能否"喂饱"GPU。

显存是第一约束，决定能装多大模型和多少并发。别按权重刚好装下算，要留 KV Cache 和运行时开销，权重占比控制在 60% 到 70%。

CPU 承担预处理和后处理，是常见的隐藏瓶颈；内存建议不低于显存总量的 1.5 到 2 倍；模型放 NVMe 保证加载速度；网卡按返回数据量选带宽。

并发与批处理是核心调优维度，目标是在延迟可接受的前提下尽量喂满 GPU。量化能显著降显存、提速度，但要评估精度影响。推理框架要按场景选，别盲目追新。

成本优化的原则是按需选卡、提高利用率、做好伸缩、在线离线分开。本文涉及的显存、并发、带宽数字均为经验量级，实际以你的压测为准。