本地部署大语言模型需要多少内存？模型规模与硬件配置指南

"我想在本地部署一个大语言模型，需要多少内存？"这个问题里说的"内存"，通常其实包含三样东西：显存（GPU VRAM）、系统内存（RAM）、以及硬盘空间。三者各有各的用途，缺哪个都跑不起来。很多部署失败的案例，根源就是只算了一样。

更麻烦的是，网上的配置建议经常互相矛盾：有人说 7B 模型 8GB 显存就够，有人说要 24GB。其实两种说法都对，差别在于精度、并发数和上下文长度。本文给出一套完整的算法，从模型参数量出发，把三种存储需求全部算清楚，并给出可直接照抄的配置档位。

一、先把三种"内存"分清楚

类型	装什么	不够的后果	能否扩展
显存 VRAM	模型权重、KV Cache、激活值、CUDA 运行时	直接 OOM，跑不起来	不可扩展（焊在卡上）
系统内存 RAM	模型加载时的中转、CPU 侧推理的权重、DataLoader 缓存	加载失败或频繁换页变慢	可加内存条
硬盘（SSD）	模型文件、量化版本、向量库、日志	放不下模型文件	可加盘

最重要的一条结论先说在前面：显存是不可扩展的硬约束，系统内存和硬盘都可以后期加。所以规划时的顺序必须是"先算显存 → 定卡 → 再配内存和硬盘"。

二、显存怎么算：四部分加总

2.1 第一部分：模型权重

权重显存 = 参数量 × 每参数字节数。精度决定字节数，这是唯一确定的一项。

参数量	FP16 / BF16（2 字节）	INT8（1 字节）	INT4（0.5 字节）	GGUF Q4_K_M（约 0.55）	GGUF Q2_K（约 0.3）
1.5B	3 GB	1.5 GB	0.75 GB	约 0.9 GB	约 0.5 GB
7B	14 GB	7 GB	3.5 GB	约 4.1 GB	约 2.2 GB
13B / 14B	26～28 GB	13～14 GB	6.5～7 GB	约 8 GB	约 4.3 GB
34B	68 GB	34 GB	17 GB	约 19 GB	约 10 GB
70B	140 GB	70 GB	35 GB	约 40 GB	约 22 GB
180B	360 GB	180 GB	90 GB	约 100 GB	约 55 GB

这张表是选型的起点。比如你手上有一张 24GB 的 RTX 4090，那么：7B FP16（14GB）没问题，13B FP16（26GB）装不下，13B INT8（13GB）可以，34B INT4（17GB）可以。一步就能划出可行区间。

2.2 第二部分：KV Cache

这是最容易被忽略的一项，也是"单条请求能跑、一上并发就崩"的元凶。

KV Cache = 2 × 层数 × KV 头数 × 每头维度 × 上下文长度 × 并发数 × 每参数字节数

常用 Llama 架构模型的单 token KV 占用（FP16）

模型	层数	KV 头数	单 token KV（FP16）	2K 上下文	4K 上下文	8K 上下文	32K 上下文
Llama-2-7B	32	32	约 0.50 MB	1.0 GB	2.0 GB	4.0 GB	16 GB
Llama-2-13B	40	40	约 0.78 MB	1.6 GB	3.1 GB	6.3 GB	25 GB
Llama-2-70B	80	8（GQA）	约 0.31 MB	0.6 GB	1.3 GB	2.5 GB	10 GB

注意看 70B 这一行：因为用了 GQA（分组查询注意力），KV 头数从 80 降到 8，单 token KV 占用反而比 13B 还小。所以不能想当然认为模型越大 KV 越占显存，要看架构。

上面是单并发。乘上并发数就是总量：7B 模型、8K 上下文、8 并发 = 4.0 × 8 = 32GB，已经远超它 14GB 的权重。这就是为什么长上下文对话服务必须精打细算。

2.3 第三部分：激活值与框架开销

• 激活值：推理时相对小，约 0.5～2GB，随 batch size 增长。
• CUDA context：每张卡上每个进程约 200～500MB，这是固定成本。
• cuBLAS / cuDNN workspace：几百 MB。
• 推理框架预留：vLLM 默认 gpu_memory_utilization=0.9，也就是只用到 90% 显存，剩余留给系统和其他进程。

综合起来，框架开销按 1～2GB 预留即可，保险起见可以在算完前面几项后整体乘 1.2 的安全系数。

2.4 完整公式与三个算例

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

算例 A：个人开发机，7B INT4，单用户，2K 上下文

• 权重 3.5GB + KV 1.0GB + 开销 1.5GB = 6GB，× 1.2 = 约 7.2GB
• 结论：8GB 显存的卡就能跑，12GB 更从容。

算例 B：小团队内部服务，14B FP16，8 并发，4K 上下文

• 权重 28GB + KV（0.8MB × 4096 × 8 ≈ 26GB）+ 开销 2GB = 56GB，× 1.2 = 约 67GB
• 结论：需要 80GB 显存，即 A100 80G 或 H100 80G。降到 INT8 则权重变 14GB，总共约 53GB，一张 A100 80G 更宽裕。

算例 C：对外服务，70B INT4，16 并发，8K 上下文

• 权重 35GB + KV（0.31MB × 8192 × 16 ≈ 40GB）+ 开销 2GB = 77GB，× 1.2 = 约 92GB
• 结论：单张 80G 装不下，需要 H100 80G 两张做张量并行，或者用 H200 141G 单卡。注意 KV 通常仍用 FP16 存储，所以量化权重省下的是权重空间，KV 不会同步减少。

三、系统内存（RAM）需要多少

系统内存的用途有三类，要分别算：

3.1 GPU 推理时的内存需求

即使模型完全跑在 GPU 上，加载过程也需要内存：模型文件先从硬盘读入内存，做反序列化和格式转换，再搬到显存。因此内存必须能装下至少一份完整的模型权重。经验规则：

• 7B 模型：建议 ≥ 16GB 内存。
• 13B～14B：建议 ≥ 32GB 内存。
• 70B：建议 ≥ 128GB 内存。

3.2 CPU 推理 / GPU 卸载时的内存需求

用 llama.cpp 这类框架时，可以只把部分层卸载到 GPU（-ngl 参数控制层数），其余层留在内存里由 CPU 计算。这时内存需要装下"未被卸载的那部分权重"，外加运行时的开销。

# llama.cpp 只卸载前 20 层到 GPU，其余在 CPU 内存
./main -m ./models/llama-2-13b.Q4_K_M.gguf -ngl 20 -c 4096 -n 512 -t 16

# 观察内存与显存占用
free -g
nvidia-smi --query-gpu=memory.used --format=csv

# 完全纯 CPU 推理（无 GPU 时的兜底方案）
./main -m ./models/llama-2-7b.Q4_K_M.gguf -ngl 0 -c 2048 -t $(nproc)

纯 CPU 推理时，内存需求 ≈ 模型文件大小 + 2～4GB 运行时开销。7B Q4_K_M 约 4.1GB，加开销约 6～8GB 即可；13B Q4_K_M 约 8GB，加开销需 12GB 左右。CPU 推理的速度高度依赖内存带宽（DDR4/DDR5 通道数），此时内存带宽比 CPU 主频更关键。

3.3 其他内存占用

• 向量数据库：如果做 RAG，Faiss、Milvus 一类会常驻内存。百万级 768 维向量（FP32）约需 3GB，加上索引结构再乘 1.3～1.5 倍。
• 推理框架与调度：Python 进程、tokenizer、请求队列，通常 2～4GB。
• 系统与缓存：操作系统和文件缓存，预留 4～8GB。

四、硬盘需要多少

硬盘需求容易被低估，因为模型往往不止一个版本。要点：

• 模型文件 = 权重大小：7B FP16 的 .safetensors 文件就是约 14GB，70B FP16 约 140GB。
• 保留多版本：FP16 原版 + 多个量化版本 + 不同微调分支，很容易到 TB 级。建议按"单模型大小 × 3～5"规划。
• 必须用 SSD：机械盘加载 140GB 模型要十几分钟。NVMe SSD 顺序读 3～7 GB/s（PCIe 4.0），加载时间能压到 1 分钟内。

# 查看模型文件实际占用
du -sh /data/models/*
df -h /data

# 查看磁盘健康（NVMe 专用工具）
sudo nvme smart-log /dev/nvme0n1 | grep -E "temperature|percentage_used|available_spare"

# 检查是否有盘快满
df -h | awk '$5+0 > 80 {print $0}'

五、分档配置建议

档位	可跑模型（含精度）	显存	系统内存	硬盘	适用场景
入门体验	7B Q4 / 1.5B FP16	8～12 GB	16 GB	256 GB SSD	个人试用、功能验证
个人工作站	7B FP16 / 13B Q4	24 GB	32～64 GB	1 TB NVMe	开发调试、本地助手
小团队服务	14B FP16 / 34B INT8	48～80 GB	128 GB	2 TB NVMe	内部知识库、部门级应用
生产级单卡	70B INT4 / 34B FP16	80～141 GB	256 GB	4 TB NVMe	对外 API、中等并发
生产级多卡	70B FP16 / 180B INT4	2～8 × 80 GB	512 GB～1 TB	8 TB+ NVMe	高并发多租户

注意最后一档：多卡时系统内存也要同步增加。经验配比是每 GPU 配 64～128GB 内存，因为每张卡上的进程都需要独立的数据加载和预处理空间。

六、CPU 与纯 CPU 部署的可行性

没有 GPU 时能不能跑？能，但要接受慢。判断标准是内存带宽和核心数：

• 纯 CPU 推理的速度大致与"内存带宽 × 核心利用率"成正比。DDR5-4800 四通道的理论带宽约 150 GB/s，相比 A100 的 2039 GB/s 差了一个数量级以上，实际生成速度通常在每秒几个 token 的量级。
• 核心数越多，并行矩阵乘越快。建议 ≥ 8 核，最好 16 核以上。
• 用 -t $(nproc) 让 llama.cpp 用满所有核心；注意超过物理核心数（超线程）收益有限，甚至可能变慢。

所以纯 CPU 部署适合：低频的内部工具、离线批处理、或者只是想验证流程。不适合交互式对话。

七、配置核查与上线步骤清单

1. 确定模型与精度：拿到参数量、架构层数与 KV 头数，确定业务可接受的精度下限。
2. 统计并发与上下文：峰值并发数 × 平均/最大上下文长度，这是算 KV Cache 的输入。
3. 按公式算显存：权重 + KV + 激活 + 开销，乘 1.2。
4. 定 GPU 型号与数量：优先单卡装下；装不下再考虑张量并行，并确认卡间有 NVLink。
5. 配系统内存：至少能装下一份完整权重（CPU 推理时是未卸载部分），再加 8GB 余量。
6. 规划硬盘：单模型大小 × 3～5，必须用 NVMe SSD。
7. 确认 CPU：GPU 推理每卡 8～16 核；纯 CPU 推理尽量多核。
8. 装机后实测：跑一次真实并发压测，记录显存峰值与内存峰值。
9. 回头修正：用实测值校准估算，确认余量是否足够。
10. 设监控告警：显存占用超 90%、内存占用超 85%、硬盘超 80% 都要告警。

# 一次性查看三项资源余量
echo "=== GPU ==="
nvidia-smi --query-gpu=index,name,memory.used,memory.total --format=csv
echo "=== RAM ==="
free -g
echo "=== DISK ==="
df -h / /data

# 压测时同时采集三项资源（每秒一次，共 120 次）
nvidia-smi dmon -s um -d 1 -c 120 &
vmstat 1 120 &
iostat -x 1 120 &
wait

小结

本地部署大语言模型的资源配置，核心是把三个"内存"分开算：显存决定能不能跑、能跑多少并发，系统内存决定模型能不能加载和 CPU 侧兜底，硬盘决定能放几个模型版本和加载快不快。

记住两条公式就够了：权重 = 参数量 × 精度字节数，KV Cache = 单 token 占用 × 上下文长度 × 并发数。前者是固定成本，后者是变量，而后者往往是压垮显存的那根稻草。

避坑建议：显存按 1.2 倍安全系数留余量，因为业务随时可能把上下文长度翻倍；系统内存至少能装下一份完整权重，否则模型加载阶段就会失败；硬盘一定用 NVMe，机械盘的加载时间会让人崩溃；规划多卡时别忘了系统内存和 CPU 也要同步扩容。最后，任何纸面估算都不如一次真实压测——先按公式定配置，再用实测数据回头校准。

---

本文的显存与内存估算为工程近似方法，实际占用会受推理框架、算子实现、并行策略与内存碎片影响，请以压测实测值为最终依据。