大模型部署需要什么服务器配置？参数规模、显存与推理需求分析

"我们要部署一个大模型，需要什么配置的服务器？"——这是运维接到 AI 需求时最常见、也最容易被低估复杂度的一个问题。业务方往往只给出一个模型名字（比如"7B"或"70B"），但真正决定服务器配置的不是模型名字，而是四个变量：参数规模、推理精度、并发量、上下文长度。这四个变量组合不同，同样的模型可能一张消费级卡就够，也可能要 8 卡集群。

本文给出一套可以直接套用的估算方法：先算显存，再定卡型，最后补齐 CPU、内存、存储和网络。过程中会给出具体的估算公式和实机查看命令，照着做就能得出一个有依据的采购清单。

一、先厘清任务：训练还是推理

这是第一步，也是最重要的一步。训练和推理对硬件的要求完全不同：

• 训练：需要保存梯度、优化器状态、激活值，显存需求通常是推理的 5～10 倍，且必须多卡并行，对互联带宽敏感。
• 推理：只需要权重和 KV Cache，显存需求小得多，但对显存带宽和并发调度更敏感。
• 微调：介于两者之间。全参数微调接近训练，LoRA/QLoRA 微调接近推理（但仍有激活值和梯度）。

大多数企业场景其实是推理。如果业务方说的是"部署一个模型对外提供服务"，那本文的估算路径完全适用；如果涉及持续训练或微调，需要在此基础上额外加一档余量。

二、显存估算：四个部分加总

2.1 模型权重

权重显存 = 参数量 × 每参数字节数。每参数字节数由精度决定：

这个表可以直接用来做第一道筛选。比如要在单张 24GB 的 RTX 4090 上跑 13B 模型，FP16 的 26GB 显然装不下，必须降到 INT8（13GB）或 INT4（6.5GB）。反过来，如果业务要求必须用 BF16 精度保证效果，那 13B 至少要一张 40GB 的 A100。

2.2 KV Cache

这是最容易被忽略、也是最容易在生产环境"炸显存"的一项。大语言模型自回归生成时，会把每一层的 Key 和 Value 缓存下来，避免重复计算。KV Cache 的大小为：

KV Cache = 2 × 层数 × KV头数 × 每头维度 × 上下文长度 × 批大小 × 每参数字节数

以常见的 Llama 架构为例：Llama-2-7B 是 32 层、32 个 KV 头、每头维度 128，FP16 下每个 token 约 512 KB；Llama-2-70B 用了 GQA（分组查询注意力），只有 8 个 KV 头，80 层，每个 token 约 320 KB。换算成实际占用：

注意看 7B 那一行的最后一列：模型权重只有 14GB，但 16 个并发 × 8K 上下文的 KV Cache 就要 64GB。这就是为什么"单卡跑 7B 明明很轻松，一上生产就 OOM"。规划时必须把峰值并发数 × 平均上下文长度作为硬约束算进去，而不是按单条请求估算。

2.3 激活值与框架开销

推理阶段的激活值相对小，通常几百 MB 到 1～2GB，随 batch size 线性增长。框架开销包括 CUDA context（约 200～500MB）、cuBLAS/cuDNN workspace、以及内存碎片，一般预留 1～2GB 即可。如果用的是 vLLM，还要额外预留 PagedAttention 的块管理开销和它默认的显存利用率上限（gpu_memory_utilization，默认 0.9，意味着它只会用到 90% 的显存，剩下 10% 留给其他进程）。

2.4 完整公式与算例

总显存 ≈ 参数量 × 每参数字节数
       + 单tokenKV × 上下文长度 × 并发数
       + 激活值（0.5~2 GB）
       + 框架开销（1~2 GB）
最后再乘 1.2 的安全系数

算一个实际例子：线上部署 Qwen 类 14B 模型，INT4 量化，平均上下文 4K，峰值并发 8。

• 权重：14 × 0.5 = 7 GB
• KV Cache：约 0.8 MB/token × 4096 × 8 ≈ 26 GB（INT4 场景下 KV 通常仍用 FP16，这里按 FP16 算）
• 激活值与开销：约 3 GB
• 小计 36 GB × 1.2 ≈ 43 GB

结论：单张 48GB 的 L40S 勉强够，单张 80GB 的 A100 更从容，两张 24GB 的 4090 则需要做张量并行。这个结论不靠猜，是算出来的。

三、卡型选择：显存、带宽与成本的三方权衡

显存算出来之后，选卡就有了硬指标。下面按场景给出判断：

这里要强调一个反直觉的点：推理场景，显存带宽往往比算力更重要。因为解码阶段是 memory-bound（访存受限），每生成一个 token 要把全部权重读一遍。H100 的 3.35 TB/s 对比 A100 80G 的 2039 GB/s，在大 batch 推理上吞吐差距接近带宽比。而 H200 的 141GB HBM3e 和 4.8 TB/s，就是专门为"大模型推理 + 长上下文"设计的。

四、CPU、内存、存储与网络怎么配

4.1 CPU 与系统内存

推理服务的 CPU 压力主要来自 tokenization、请求排队、后处理和 HTTP 层。经验配比：

• CPU：每 GPU 8～16 核。纯推理取下限，带复杂预处理或高并发调度取上限。
• 系统内存：每 GPU 配 64～128GB。另外要注意，如果做模型热备（多模型常驻显存不够时在内存里轮转），内存容量要能装下至少一份完整的模型权重。

4.2 存储

模型文件本身是主要占用：7B FP16 约 14GB，70B FP16 约 140GB，如果保留多个版本（FP16 + INT4 + 不同微调分支）很容易到 TB 级。建议：

• 系统盘和模型盘分离，模型放在独立 NVMe 上。
• 预留 3～5 倍于单模型的空间，方便版本回滚。
• 用 df -h 和 iostat -x 1 监控模型加载时的 IO 情况，冷启动慢通常是这里的问题。

4.3 网络

单机部署时网络不是瓶颈，但要注意：模型权重从对象存储拉取时，千兆网拉 140GB 需要 20 分钟以上，建议内网万兆或提前预热到本地盘。多机部署（如 70B 需要跨机张量并行）时，节点间每步都要同步激活值，至少需要 100GbE 或 InfiniBand，否则通信延迟会吃掉大部分算力。

五、部署前的配置核查清单

1. 确认模型与精度：拿到具体的参数量、架构（决定 KV 头数）、以及业务能接受的精度下限。
2. 统计并发与上下文：向业务方要峰值 QPS 和平均/最大上下文长度，这是算 KV Cache 的前提。
3. 按公式算显存：权重 + KV + 激活 + 开销，乘 1.2 安全系数。
4. 选卡型与卡数：优先单卡装下；装不下再考虑张量并行，并确认卡间有 NVLink。
5. 配 CPU 与内存：按每卡 8～16 核、64～128GB 内存来配。
6. 规划存储：模型盘独立，预留 3～5 倍空间。
7. 实机验证：装机后执行下面的命令确认资源，再跑压测。
8. 压测校准：用真实并发压一遍，观察显存峰值和 GPU 利用率，回头修正估算。

# 确认 GPU 数量、型号与显存总量
nvidia-smi --query-gpu=index,name,memory.total,driver_version --format=csv

# 部署后持续观察显存与利用率（每秒采样，输出 60 次）
nvidia-smi dmon -s mu -d 1 -c 60

# 查看 CPU 核数、内存总量、NUMA 分布
lscpu
free -g
numactl --hardware

# 确认模型盘空间与 IO 能力
df -h /data
iostat -x 1 5

六、三个典型场景的参考配置

6.1 内部知识库问答（7B，日活几百人）

1 张 RTX 4090（24GB）+ 16 核 CPU + 64GB 内存 + 1TB NVMe。INT4 量化，并发 4～8，完全可以支撑。整机功耗 1kW 以内，普通机房即可。

6.2 对外客服/助手服务（13B～14B，高并发）

2 张 L40S（48GB×2）或 1 张 A100 80G，32 核 CPU，256GB 内存，2TB NVMe，配 vLLM 做连续批处理。需要关注显存带宽，因此 L40S 虽然算力不如 A100，但 48GB 显存和大容量对推理很友好。

6.3 通用大模型 API 服务（70B，多租户）

4～8 张 H100 80G（SXM，NVLink 全互联），双路高核数 CPU，512GB～1TB 内存，4TB+ NVMe，节点间 200Gb InfiniBand。这个级别要当成小型集群来做，包括调度、监控、故障转移都要配套。

小结

大模型部署的服务器配置不是拍脑袋定的，而是由显存需求倒推出来的。核心公式记住两条：权重 = 参数量 × 精度字节数；KV Cache = 单 token 占用 × 上下文长度 × 并发数。把这两个数算清楚，卡型和卡数基本就确定了，剩下的 CPU、内存、存储都是配套项。

避坑建议：第一，永远不要按"单条请求"估显存，一定要带上峰值并发；第二，别忽视 KV Cache，长上下文场景下它经常比权重还大；第三，推理优先看显存带宽而非峰值算力；第四，给显存留 20% 余量，业务侧悄悄把上下文从 2K 提到 8K 是很常见的事；第五，单机装不下时优先换更大显存的单卡，跨卡并行会显著增加运维复杂度。

本文给出的显存估算为工程近似方法，实际占用会因推理框架、算子实现与并行策略而略有差异，建议以压测实测值为最终依据。