大模型本地部署要多少显存？把权重、KV cache 和并发拆开算

一个 70B 模型，INT4 量化后权重只要 35GB，看起来一张 48GB 卡就装得下。真上手会发现第三个请求就 OOM——因为漏了 KV cache，而 KV 是按并发线性涨的。

显存不是一个数，是几块加起来的账：权重 + KV cache + 框架预留，其中 KV 还要再乘并发。

商红科技（bencom.cn）在深圳、东莞、惠州、广州、上海等全国多地交付过本地推理与小规模微调的机器，下面这套算法按交付现场的口径整理，文末附一张可以自己改参数重算的表。

显存到底被谁吃掉了？

吃掉显存的是四块：权重、KV cache、框架预留、并发放大。权重是第一块，但常常不是最大的那块。

• 权重：参数量 × 权重量化字节。FP16 每参数 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。它是一次性占住的固定成本。

• KV cache：每个 token 都要为每一层存一份 Key 和 Value。它随上下文长度和并发数一起涨，是变动成本。

• 框架预留：CUDA context、显存池、图捕获（graph capture）、以及显存碎片，经验值 1–3GB。

• 并发放大：前面三块里只有 KV 会被并发成倍放大——这是最容易被漏掉的一块。

把权重和 KV 分开叫"固定成本"和"变动成本"，是理解显存的关键。固定成本决定能不能装下这个模型，变动成本决定能同时服务几个人。

这两件事对应完全不同的采购决策：前者看单卡容量，后者看卡数、带宽和上下文策略。

自己验一遍：找一张正在跑的卡，nvidia-smi 记一次显存占用，停掉推理服务再记一次。两个数的差值就是"权重 + 框架"，通常会比你以为的权重大 2–3GB——那 2–3GB 就是框架预留。

还有一个常见的困惑：同一个模型，别人的机器够，你的不够。差异通常不在卡上，而在三处：

一是框架版本。不同版本对显存的预分配策略不一样，新版通常会吃掉更多显存换吞吐。

二是并发策略。默认参数往往按"跑得动"设，不按"多带人"设；最大序列数一调，同一张卡的可用并发能差好几倍。

三是上下文习惯。业务里把 32k 当默认上下文开着，KV 就是 8k 的四倍，卡数自然也要跟着涨。

7B、32B、70B、千亿模型，各要多少显存？

权重这一层可以直接乘出来，差异全在精度上。下表按十进制 GB 计（1B 参数 = 10 亿参数）。

这里有个容易被忽略的细节：厂商写 GB，框架里显示 GiB。1 GiB = 1.074 GB。

所以按 140GB 买的卡，在 nvidia-smi 里看到的是 128GiB 左右。算的时候用 GB，看的时候记得换算，否则会平白差出 7% 的余量。

KV 那一层跟架构强相关，而且反直觉：KV 头数少的反而更省。

KV/token = 2 × KV 头数 × head_dim × 字节数。以 8k 上下文、FP16 KV 为例：

看懂这张表就明白一件事：7B 用 MHA，KV 头数和注意力头数一样多（32:32）；70B 用 GQA，64 个注意力头只留 8 个 KV 头。所以 8k 上下文下，7B 的单序列 KV 反而比 70B 更贵。

千亿级模型还有第二道门槛：200GB 权重意味着单卡放不下，必须做张量并行切分。切分之后每张卡只装一部分权重，但层数、通信、以及每张卡要预留的显存池都会重新改变余量计算。

复算一下：7B 权重 14GB + 8 并发 KV 32GB + 框架 2GB = 48GB。KV 比权重还大两倍多——这就是"按权重买卡"必然翻车的地方。上下文从 8k 拉到 32k，KV 直接乘 4，账会变得完全不一样。

上面三个数是查出来的，不是估的。打开你模型的 config.json，三个字段就够：

• num_hidden_layers：层数，直接乘进 KV 公式；

• num_key_value_heads：KV 头数，GQA 模型这个数远小于注意力头数；

• hidden_size ÷ num_attention_heads：算出 head_dim，多数模型是 128。

模型自己带的说明里没写清楚，就用这三个字段算，不要用"听说 70B 要几张卡"来过预算。

为什么「刚好装下」一上并发就 OOM？

因为在并发场景下 KV cache 才是显存的主要消费者，而它按并发数线性增长。

以 70B FP16 为例：单序列 8k 的 KV 是 2.5GB，看上去很少。但 8 个并发就是 20GB，20 个并发就是 50GB，100 个并发就是 250GB。

权重不会这样变。权重是一次性占住的，KV 是随着请求进来一直在涨的。

再叠加三层现实：

第一层，框架的显存阈值。vLLM 默认 gpu_memory_utilization=0.9，启动时就按 90% 显存预分配 KV 块。权重若已占掉 87.5%，框架连启动都可能失败。

第二层，块管理带来的碎片。PagedAttention 把 KV 切成固定大小的块来分配，利用率比朴素实现高很多，但块边界、序列长度不均、以及不同请求长短混跑，仍然会留下无法利用的空隙。

第三层，排队本身也在消耗体验。并发拉满时，新请求的 TTFT（首字延迟）会明显变长，因为它在等前面的序列把 KV 块释放掉。这时候"没 OOM"并不等于"能用"。

对着你的机器查一下：服务启动日志里通常有一行 GPU blocks 或 maximum concurrency 的信息，那个数字就是当前配置实际能扛的并发。它往往比你按公式估的更小，差的就是碎片与预留。

于是"长上下文"和"多并发"本质上是同一笔预算的两种花法：上下文翻倍，能同时服务的人就减半；并发需求翻倍，能开的上下文就得收一半。

先把业务里的真实分布摸清楚——是少量超长文档，还是大量短问答——比笼统地问"要多大的卡"有用得多。

量化能救显存吗？

能救权重，救不了 KV——这是量化最常被误解的地方。

INT4 把 70B 从 140GB 压到 35GB，确实让单卡部署从不可能变成可能。但 KV cache 的精度默认仍是 FP16，除非你额外开了 KV 量化（FP8 或 INT8 KV）。

所以量化之后，卡数仍然要按 KV 的账算：

INT8 这一档常被跳过去，但它其实是性价比区间：显存减半，精度损失通常远小于 INT4。如果 INT4 的效果不行，先退到 INT8，往往比硬上 INT4 更划算。

量化的代价也要讲清。INT4 在长上下文、代码和数学任务上的损失通常更明显；AWQ 与 GPTQ 都需要校准集，校准集选得不对，掉点会更难看。KV cache 量化再省一半显存，但同样要重新测一遍精度。

自己测一次：拿你真实业务里的 20–30 条难样本，FP16、INT8、INT4 各跑一遍。比总分更有价值的是"错在哪一类"——如果掉的都是引用与数字复述，那这类业务就别省这半张卡。

怎么给一台机器定卡数？

先算总需求，再除 0.7 留余量，最后看能不能被单卡显存整除。顺序不能反。

公式就四行：

权重       = 参数量(B) × 权重字节（FP16=2 / INT8=1 / INT4=0.5）
KV/token   = 2 × KV头数 × head_dim × KV字节 ÷ 1024      （KV 字节默认 2）
单序列 KV  = KV/token × 层数 × 上下文 ÷ 1024 ÷ 1024
总需求     = 权重 + 单序列KV × 并发 + 框架预留
建议卡显存  = 总需求 ÷ 0.7复制

三个"只算权重"的典型结果：

多卡不只是"显存相加"。张量并行把每一层切开，卡之间每一步都要同步，通信开销随卡数上升；负载不均又会让你不得不按最忙那张卡留余量。

所以现实里的选择常常是：宁可多买一张中等卡，也不要赌一张超大卡——前者的余量可以靠调度摊开，后者一旦卡住就没有退路。

卡型这一层，公开参数可以直接对比：A100 80GB 的 HBM2e 带宽 1935GB/s；H100 80GB 是 2039GB/s 并配 NVLink 600；国产的寒武纪思元 590 是 345 TFLOPS（FP16）加 96GB HBM2e。显存决定能不能跑，带宽决定跑多快，两件事要分开看。

下单之前还有一步不能省：用最小可用的机器跑一次真压测。不用全量业务，20–30 条真实请求就够，重点看三个指标——首个 token 的延迟（TTFT）、每 token 的间隔（TPOT）、以及并发到第几个开始 OOM。

这三个数出来，卡数就不用猜了。反过来，纸面上算得再漂亮，没有这一步，验收时仍有很大概率对不上。

复算一遍：把四行公式套进一张表，改三个数（参数量、并发、上下文），十分钟就能排出三四套配置的差价。比在群里问"70B 要几张卡"快得多，也比听报价单上的"够用"可靠。

文末附了一份可下载的换算表，改黄色格子自动重算，样例里已经算好 7B/32B/70B/千亿四档 × 三种精度。

常见问题

本地部署 70B，最少要几张卡？
看上下文和并发。8k、单请求的场景，2 张 80GB 能跑起来但余量很紧；要支撑 8 并发，按 162GB 算更稳妥，得 3 张 80GB 或 2 张 141GB 级。想省卡就先上 INT8 或 INT4，但要接受精度损失。

消费级 24GB 卡能不能跑 7B？
能跑，但只适合单请求、短上下文。7B FP16 权重 14GB，加上 8k 上下文与 8 并发的 KV 就要 48GB。想多带人，要么换 48GB 级以上的卡，要么把上下文压短、并发调低。

显存够大就够快吗？
不够。显存决定能不能装下，带宽和算力决定跑多快。H100 与 A100 显存同为 80GB，但带宽和算力差一档，同模型同并发下的 tokens/s 差得明显。

能不能只买一张大卡、不买多卡？
单卡省掉张量并行的通信开销，部署也简单，但显存有物理上限。等模型和并发超过单卡容量，多卡就是唯一选项——那时要提前把通信开销与负载不均的余量算进去。

要按你的模型和并发算一份配置，可以联系我们（400-0755-816），说清三件事：模型规模与精度、上下文长度、同时在线人数。想先看机型，可以对比 GPU 服务器 与 AI 工作站 各自适合什么场景。

资料来源与核验

显存公式与样例计算为本文自行推算，口径固定可复现；卡型参数取自厂商公开规格。数据截止 2026 年 11 月。

• NVIDIA A100 / H100 规格（HBM2e 带宽、NVLink）：https://www.nvidia.cn/data-center/

• 寒武纪思元 590 公开规格（345 TFLOPS FP16、96GB HBM2e）：https://www.cambricon.com/

• vLLM 官方文档（gpu_memory_utilization、PagedAttention 行为）：https://docs.vllm.ai/

• Llama 系列公开模型架构（层数、注意力头数、KV 头数）：https://github.com/meta-llama/llama-models

大模型本地显存换算表下载：

f1f3bb340e20f897892672a3f978e769.xlsx