跑大模型要多少显存？显存估算公式与选卡指南
想在自己的 GPU 上跑开源大模型，第一个问题永远是”显存够不够”。但大多数教程给的数字缺乏来源，本文直接给你估算公式和对照表，让你在选卡或选实例前把显存账算清楚。
显存需求从哪里来？
推理时显存主要分为三块：
总显存 ≈ 模型权重 + KV Cache + 框架开销
三部分的性质截然不同：权重固定、KV Cache 随并发和上下文长度动态增长、框架开销几乎是常数。
我见过太多人只算了第一项就去买卡或开实例，结果上线跑到 8 并发就 OOM 崩溃——问题不在权重，而在 KV Cache 被严重低估。权重是”一次性成本”，加载完就不变；KV Cache 是”运行时成本”，请求越多、上下文越长，它涨得越快。所以选卡前一定要按你真实的并发和上下文长度去估，而不是只看模型卡片上写的”最低显存需求”（那基本只算了权重）。
第一块：模型权重占用
这是最容易算的部分，近似公式：
权重显存(GB) ≈ 参数量(十亿) × 每参数字节数
| 精度 | 每参数字节 | 说明 |
|---|---|---|
| FP32 | 4 字节 | 全精度，训练常用，推理几乎不用 |
| BF16 / FP16 | 2 字节 | 推理主流精度，精度损失可忽略 |
| INT8 | 1 字节 | 量化后，速度提升显著，精度基本无损 |
| INT4 / Q4 | 0.5 字节 | 积极量化，显存减半，轻微精度损失 |
这张表背后的道理是：推理阶段不需要反向传播，不需要保存梯度和优化器状态（Adam 优化器状态通常是权重本身的 2 倍以上），所以训练时必须的 FP32 精度在推理时是浪费。BF16/FP16 之所以成为推理主流，是因为大模型的权重分布对精度不敏感——你把每个参数从 4 字节压到 2 字节，模型输出的困惑度（perplexity）几乎不变，但显存直接减半。这也是为什么几乎没人在生产环境里用 FP32 跑推理，纯粹是浪费显卡。
需要提醒一点：上面的字节数是”每参数存储字节数”，不是”每参数计算字节数”。有些框架（比如 vLLM 的某些内核）在计算时会把 INT8/INT4 权重反量化回 FP16 再做矩阵乘法，这意味着量化省的是存储显存，不一定等比例省计算时间——量化模型推理更快，主要是因为显存带宽压力变小了（数据搬运量减少），而不是算力需求变小。
不同参数量 × 精度对照表
| 模型规模 | FP16（GB） | INT8（GB） | INT4（GB） |
|---|---|---|---|
| 1B | ~2 | ~1 | ~0.5 |
| 3B | ~6 | ~3 | ~1.5 |
| 7B | ~14 | ~7 | ~3.5 |
| 13B / 14B | ~28 | ~14 | ~7 |
| 30B | ~60 | ~30 | ~15 |
| 70B | ~140 | ~70 | ~35 |
| 72B | ~144 | ~72 | ~36 |
注意：以上为权重部分估算，实际还需加上 KV Cache 和框架开销。
反过来用这张表更实用：如果你手上是一张 24GB 的卡（比如 4090），刨去 KV Cache 和框架开销留个 6–8GB 余量，权重能占的空间大概是 16–18GB。对照表一看，INT4 量化的 30B 模型（~15GB）勉强能塞进去，但几乎没有 KV Cache 空间了，只能跑单并发短上下文；如果换成 INT4 的 13B（~7GB），才有足够余量支撑几路并发。这就是为什么”24GB 显卡能跑 70B 模型”这种说法基本不成立——权重是能塞进去，但塞进去之后你跑不了几个并发，体验上等同于单机演示，不是能用的服务。
第二块：KV Cache
KV Cache 是推理加速的核心机制，但也是显存的”动态杀手”。
单 token KV Cache 占用近似（FP16 精度）：
每 token KV 显存(Bytes) ≈ 2 × 层数 × 头数 × 头维度 × 2字节
对于 Llama-3-8B（层数 32、KV 头数 8、头维度 128）：
每 token KV ≈ 2 × 32 × 8 × 128 × 2 = 131,072 字节 ≈ 0.125 MB
注意公式里用的是”KV 头数”，不是模型的注意力头总数，这是理解现代大模型显存优化的关键。Llama-3-8B 的注意力头总数是 32，但它用的是 GQA（Grouped Query Attention）架构，只有 8 个独立的 K/V 头，每 4 个 Query 头共享同一组 K/V。也就是说，如果按老式的 MHA（Multi-Head Attention，每个头都有独立 K/V）来算，KV Cache 会是现在的 4 倍。这不是巧合，而是 Llama-3、Qwen2、Mistral 这些主流开源模型从 2023 年后集体转向 GQA/MQA 的核心动机——纯粹为了压缩 KV Cache，让长上下文和高并发变得可行。所以选模型时，如果两个模型参数量接近，优先看它用的是 GQA 还是老式 MHA，前者的显存表现会好非常多。
实际意义：
| 并发请求数 | 上下文长度 | 近似 KV Cache（Llama-3-8B） |
|---|---|---|
| 1 | 4K token | ~0.5 GB |
| 8 | 4K token | ~4 GB |
| 32 | 4K token | ~16 GB |
| 8 | 16K token | ~16 GB |
高并发 + 长上下文场景，KV Cache 可以轻松超过权重本身的显存占用。vLLM 的 PagedAttention 技术正是为了优化 KV Cache 的显存碎片化问题而设计。
为什么会碎片化？ 传统实现会为每个请求预分配”最大可能长度”的连续显存块，比如你设了 max_model_len=8192，即便某个请求只用了 200 token，也可能预留了 8192 token 的空间——请求一多，显存里全是这种”预留但没用满”的空洞，实际能承载的并发数远低于理论值。PagedAttention 借鉴操作系统虚拟内存分页的思路，把 KV Cache 切成固定大小的小块（block），按需分配、用完释放，显存利用率能从 20%–40% 提到 90% 以上。这也是为什么同样一张卡，vLLM 跑的并发数往往比原生 HuggingFace Transformers 高出几倍——不是算力更强，是显存管理更聪明。
第三块：框架开销
框架本身（PyTorch、CUDA 上下文、vLLM 运行时等）通常占用 1–3 GB，可当作固定项加入估算。这部分具体拆开是：CUDA context 本身大概 300–500MB（每张卡、每个进程都要占一份，这也是为什么同一张卡起多个推理进程比想象中费显存）；PyTorch 的 caching allocator 会预留一部分显存池减少频繁申请释放的开销，通常几百 MB 到 1GB；再加上 vLLM/TensorRT-LLM 这类推理框架自己的运行时缓冲区。
真正容易被低估的是 prefill 阶段的 activation 显存。生成阶段（decode）每次只处理 1 个新 token，activation 很小；但 prefill 阶段要一次性处理整段输入 prompt（比如一次丢进去 4000 token 的长文档），中间层的激活值显存会随 batch size × 序列长度线性增长，短时间内可能冲高到 GB 级别，跑完这一次 forward 就释放。如果你的框架开销预算只按 decode 阶段的稳态显存来估，遇到长 prompt 批量请求时很容易被 activation 显存打个措手不及，报 OOM。保守做法是留 3–5GB 的浮动余量而不是 1GB。
完整估算示例
场景：用 vLLM 部署 Llama-3-70B（INT4），支持 16 路并发，上下文 4K
- 权重：70 × 0.5 ≈ 35 GB
- KV Cache（按 70B 模型参数比例估算）：~20 GB
- 框架开销：~2 GB
- 合计：约 57 GB
这意味着需要两张 A100 40GB（张量并行）或一张 H100 80GB。
部署完怎么验证估算准不准？ 别只看理论值就上线，跑起来后用 nvidia-smi -l 1（每秒刷新一次）盯着显存曲线，同时用压测工具（比如 vLLM 自带的 benchmark 脚本，或者简单地写个脚本并发发请求）模拟你的真实流量。你应该看到显存占用先跳到一个基线（权重 + 框架开销），然后随并发数上升逐步增长，最终稳定在一个平台期——如果稳定不下来、持续爬升直到 OOM，说明有请求没有正常释放（常见于没有正确处理超时/断连的请求，KV Cache 块一直没归还），得去查框架的请求生命周期管理，而不是简单加显存了事。
真实踩坑：CUDA OOM 报错怎么排查。 vLLM 部署后如果看到类似 torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 256.00 MiB 或者 vLLM 自己报的 ValueError: No available memory for the cache blocks，先别急着加卡，按这个顺序排查：
- 先看
gpu_memory_utilization参数：vLLM 默认会尝试占满你设定比例（默认 0.9）的显存来分配 KV Cache 块，如果这台机器上还跑着别的进程占了显存，vLLM 启动时探测到的”可用显存”是错的，会导致后续分配失败。解决办法是先用nvidia-smi确认这张卡真实空闲多少，再手动调低这个参数到实际能用的比例。 - 再看
max_model_len：如果你把它设成了模型支持的最大值（比如 Llama-3 的 8192 甚至更长），vLLM 会按这个长度预估 KV Cache 需求，值越大能同时支撑的并发请求数越少。如果你的业务场景用不到这么长的上下文，主动调小这个值，能直接换回更多并发容量。 - 看是不是 prefill 阶段的长 prompt 撞上了：如果 OOM 只在处理特别长的输入（比如上传的长文档）时出现，稳态运行没问题，大概率是前面说的 activation 显存峰值问题，可以通过降低
max_num_batched_tokens限制单批次处理的 token 总量来缓解。 - 最后才是加卡或换更大显存的卡：前三步都调过还是不够，才说明是真实容量不足，这时候该老老实实按估算公式重新选型，而不是头痛医头地不断调参数。
消费卡 vs 专业卡对比
| 卡型分类 | 代表型号 | 显存范围 | 特点 | 适用场景 |
|---|---|---|---|---|
| 消费卡（高端） | RTX 3090 / 4090 | 24 GB | 价格相对亲民，无 ECC | 个人实验、7B–13B 小模型 |
| 消费卡（主流） | RTX 3080 / 4080 | 10–16 GB | 量化后可跑 7B | 本地开发测试 |
| 专业卡（入门） | A10G / L4 | 24 GB | ECC 内存，生产稳定 | 小批量生产推理 |
| 专业卡（主力） | A100 / H100 | 40–80 GB | NVLink、HBM，高带宽 | 生产级高并发，70B+ |
| 专业卡（新品） | H20 / H200 | 80–141 GB | 超大显存 HBM3e | 超大模型单卡部署 |
关键差异：
- ECC 内存：消费卡没有 ECC（错误纠正），长时间运行下内存错误风险更高，不建议用于对准确性要求高的生产场景
- 显存带宽：专业卡的 HBM 带宽通常是 GDDR 的 3–5 倍，对推理吞吐量影响显著
- 多卡互联：NVLink 支持高速多卡张量并行，消费卡通过 PCIe 互联带宽受限
关于二手消费卡的提醒：4090/3090 二手市场上不少是”矿卡”（挖矿长期满载运行过），显存颗粒老化风险更高，长时间高负载推理时更容易出现显存 ECC 错误或稳定性问题（虽然消费卡本身没有 ECC 校验，但硬件老化会直接体现为偶发花屏、驱动崩溃、甚至无提示的输出乱码）。如果你是拿来做生产服务而不是个人实验，二手卡省下的钱可能远不够抵消一次线上故障排查的时间成本。个人本地开发、离线批处理这类容错场景，二手卡的性价比确实很有吸引力。
多卡互联对实际吞吐的影响也值得算一笔账：NVLink 的带宽通常在 600GB/s 以上（A100 NVLink 3.0），而消费卡走 PCIe 4.0 x16 的带宽只有 32GB/s 左右，差了近 20 倍。这个差距在单卡能装下模型时感觉不出来，但一旦你需要跨卡张量并行（比如两张 4090 拼 48GB 去跑一个 24GB 装不下的模型），每一层前向传播都要做一次跨卡通信，PCIe 带宽瓶颈会让多卡消费卡组合的实际吞吐远低于”两张卡显存相加”给你的直觉预期。这也是为什么专业卡贵得不只是显存容量，互联带宽才是撑起大规模并行推理的关键差异点。
量化怎么选？
| 量化方案 | 显存节省 | 精度损失 | 推荐程度 |
|---|---|---|---|
| FP16（无量化） | 基准 | 无 | 显存充裕时首选 |
| INT8（LLM.int8()） | ~50% | 几乎无 | 显存紧张时首选 |
| GPTQ INT4 | ~75% | 轻微 | 显存极紧张，可接受轻微损失 |
| AWQ INT4 | ~75% | 比 GPTQ 略好 | 推荐优先于 GPTQ |
| GGUF Q4_K_M | ~75% | 轻微 | llama.cpp 生态，CPU 推理必选 |
怎么在这几个方案里做决策，别只看表格里的”推荐程度”，看你的实际约束：
- 如果你用 vLLM/TensorRT-LLM 这类专注 GPU 服务化部署的框架，量化格式选 AWQ：它的量化校准过程比 GPTQ 更关注激活值分布（activation-aware），同等 4bit 精度下困惑度通常更低，而且主流推理框架对它的算子支持已经很成熟，推理速度不吃亏。
- 如果你要在 Mac、笔记本、没有独立 GPU 的机器上跑，或者想用 CPU+GPU 混合推理，选 GGUF（配合 llama.cpp / Ollama）：它是为纯 CPU 和消费级硬件设计的格式，量化档位选择更细（Q4_K_M、Q5_K_M、Q8_0 等），可以按你的内存和速度需求灵活权衡，这是 GPTQ/AWQ 不具备的生态优势。
- GPTQ 现在更多是历史遗留选择——如果你要用的模型只发布了 GPTQ 版本、没有 AWQ 版本，才退而求其次用它，新项目没必要主动选它。
- 不确定量化对你的具体任务影响多大，别凭感觉判断，花十分钟跑一遍你的真实业务样本（哪怕只有几十条），INT4 和 FP16 版本各跑一遍对比输出质量，这比看任何通用榜单都可靠——量化损失在不同任务类型上的表现差异很大，通用评测集的结论未必适用于你的场景。
常见问题
显卡显存不够能用内存凑吗？
可以，但代价极大——模型推理速度会降低 10–100 倍以上（CPU 带宽远低于 GPU HBM）。仅适合没有延迟要求的批处理场景，或实在买不到更大显存卡时的临时方案。
多卡张量并行是否线性增加显存？
是的，张量并行会将权重均匀切分到多卡，显存近似线性叠加。但多卡之间有通信开销，实际吞吐不是线性提升。
量化后的模型能用于所有任务吗？
对话、摘要、翻译、代码生成等常见任务，INT4 量化影响通常可忽略。但对数学推理、长链逻辑推理等任务，量化可能带来更明显的精度下降，建议先评测后再决策。
不想真的部署一遍，有没有办法提前验证显存够不够？
有两种低成本方式。一是直接用本文的公式手算，权重按参数量×字节数、KV Cache 按并发数×上下文长度×每 token 占用，两项加上 3–5GB 框架开销，基本能estimate 到八九不离十。二是很多推理框架支持”干跑”模式，比如 vLLM 启动时加 --enforce-eager 并观察启动日志里打印的显存分配情况，它会在真正接受请求前把权重加载和 KV Cache 池的显存需求打印出来，不用真发请求就能看到框架自己算出来的显存占用，比你手算更准，因为它把你模型的具体层结构都算进去了。
云 GPU 实例选型时，显存和价格怎么权衡？
别只看”每 GB 显存多少钱”这种单一指标，你要看的是”每 GB 显存能承载多少有效并发”。同样是 80GB 显存，H100 因为算力和带宽都更强，同等并发下响应延迟更低、单位时间能处理的请求数更多，实际的”每请求成本”可能比看起来更便宜的老卡（比如同显存的 A100）还低——尤其是长上下文、高并发场景，算力和带宽的差距会被放大。如果你的场景是低并发、对延迟不敏感的离线批处理，选性价比更高的老卡或者混合精度更激进的量化方案，反而更划算。判断标准始终是你的真实流量画像，不是显卡参数表上的数字。
延伸阅读：
- 算力基础全景：大模型算力基础：GPU 云、推理部署与 API 取舍
- 自托管与 API 账单对比：自托管 vs 用 API 怎么算账
- 算力专题 Hub：算力专题
- 不想自己折腾 GPU 显存？加入候补，直接调用 API 省心省力