大模型显存怎么算？从权重到KV cache的完整指南

1. 先算权重大账：不同精度下7B、13B、70B模型各占多少显存

我见过太多人问“我的显卡能跑多大的模型”，然后拿着7B、13B这样的参数到处问别人。其实这事完全可以自己算出来，而且算出来之后你就不会再对着别人的截图眼馋了。模型参数量（Parameters）和显存占用之间，本质就是一个简单的乘除法关系：参数数量 × 每个参数的字节数 = 权重占用的内存。

1.1 从参数到字节的换算逻辑

先记住一组基础数字：

• FP32（float32）：4字节，训练老模型时常见，推理基本不用，太占显存
• FP16 / BF16：2字节，目前推理和微调的默认主力
• INT8：1字节，量化推理的常见选择
• INT4（如GPTQ、GGUF里的Q4）：0.5字节，当前本地模型玩家最常用的档位

所以一个70亿参数（7B）的模型：

• 用FP16加载，权重部分就是：7 × 10^9 × 2字节 = 14GB
• 用INT8，就是 7GB
• 用INT4，只要 3.5GB

这就是为什么你看到有些人拿着12GB显存的老显卡，跟没事人一样跑7B模型做对话。不是他有什么黑科技，就是他用了INT4量化，占了显存的大头只有3.5GB而已。同理，130亿参数（13B）FP16要26GB，量化到INT4约6.5GB；700亿参数（70B）FP16要140GB，量化到INT4也要35GB。所以70B模型想本地跑，24GB显卡都很勉强，80GB才算是宽敞。

1.2 常见参数对照表

我做了一个快速对照表，按主流推理框架加载完整权重来算，不含上下文缓存（这个后面专门讲）：

这张表的前提是“短上下文”，也就是对话长度不长，KV cache还没爆发。一旦上下文拉长，事情就完全不一样了。

1.3 千万别忽略的固定开销：CUDA上下文和碎片

权重只是第一部分。真实加载模型时，显存里还躺着几样东西：推理框架本身的CUDA上下文、算子库临时缓冲、显存碎片。我实测过很多次，一个空空的CUDA进程在主流推理框架下启动后，什么都不干就先占0.5GB到1.5GB显存。如果你的显卡只有6GB，这部分就很肉疼了。

还有一个很多人没意识到的问题：显存碎片。模型加载、内存分配、释放，反复几次之后，经常会出现“显存总量够用，但空闲块不连续”的情况。我在16GB显卡上调模型，明明算下来权重加KV只有13GB，结果加载到一半就OOM，后来重启进程、限定框架使用固定显存池才好。所以实操上，我建议在估算结果上再留10%~15%的余量。这个习惯救了我很多次。

2. KV cache才是真正的显存黑洞

如果你只按权重算显存，那你会踩一个特别大的坑：上下文长度。同一个7B模型，上下文从2K拉长到32K，显存占用可能从10GB飙到20GB以上。这个变量，就是KV cache。

2.1 KV cache是怎么产生的，为什么不能不要

在大模型的注意力机制里，每个token都要跟之前所有token计算相关度。为了不每次生成都重新算一遍历史token的Key（键）和Value（值），推理框架会把它们缓存下来。这个缓存就是KV cache。没有它，每生成一个token就要重算整个序列的注意力，慢到你怀疑人生。

KV cache的大小是有公式的：

KV cache大小 = 2 × 层数 × KV头数 × 头维度 × 上下文长度 × 每个元素字节数

其中前面的2，是因为Key和Value各要存一份。以常见的7B模型为例：

• 层数：32层
• 注意力头数：32，KV头数32
• 头维度：128
• 如果用FP16（2字节）

那每个token对KV cache的消耗量就是：

2 × 32 × 32 × 128 × 2 = 524,288字节 ≈ 0.5MB/token

看着不多对吧？但这个0.5是“每个token”的量。上下文2048个token，就是 0.5MB × 2048 ≈ 1GB；上下文32768个token，就是 0.5MB × 32768 = 16MB每token？不对，是乘整个序列长度，即0.5MB × 32768 ≈ 16GB。对，没看错，光KV cache就能吃掉16GB。再加上14GB的FP16权重，一个7B模型想在32K上下文下跑全精度，总共要30GB显存。

2.2 长短上下文的算账示例：从2K到32K

我们用同一个7B模型做一次完整算账，FP16权重14GB，看看不同上下文下的实际需求：

这就是为什么很多人问“8GB显卡能不能跑7B模型”，别人回答“可以量化到4bit”之后，他还是跑不起来——因为他把上下文设成了32K甚至64K。量化只把14GB权重砍到3.5GB，但KV cache还在膨胀。你省下来的权重空间，全被上下文吞了。

2.3 选GQA架构能省多少显存

后来有个好消息：新一代模型普遍采用了GQA（分组查询注意力）或者MQA（多查询注意力），它们把KV头数量控制得非常小。同样是7B规模的模型，有些新模型的KV头数只有8个甚至1个，而不是32个。

你可以看下这个对比：

• 传统多头注意力模型：KV cache各层按完整头数存，7B级别约0.5MB/token
• GQA模型（如某7B模型，KV头数8）：约 0.125MB/token
• MQA模型（KV头数1）：约 0.0156MB/token

同样是8K上下文，传统模型要4GB KV cache，GQA只要1GB，MQA甚至只要0.1GB。差距非常夸张。所以选模型时，如果看重长上下文场景，优先看架构。同样8GB显存，跑GQA模型的体验会比跑旧架构模型好得多。这也是为什么现在市面上的新模型基本都是GQA起步。

3. 量化等级怎么选：INT8和INT4差在哪

显存不够怎么办？大多数人第一反应就是量化。但量化也不是随便选个等级就好。INT8和INT4，显存占用能砍一半，但代价也是实打实的。

3.1 量化的质量代价

量化本质上是把连续的浮点数值映射到离散的整数网格上。INT8只有256个量化档位，INT4更是只有16个档位。模型参数从FP16的精确表示变成这种粗糙网格，必然会有误差。好消息是模型本身有很强的冗余度，所以即便INT4，在很多任务上跟FP16的结果差距并不大。

我自己的测试经验：在对话、写代码、知识问答这类场景里，7B模型INT4和FP16的差异，普通人基本感受不出来。但在数学推理、长文档归纳这类需要高精度计算的场景，量化后的掉点就比较明显了。所以如果你要跑代码生成或者数学类任务，尽量用INT8或者FP16；如果只是聊天、文案、总结，INT4完全够用。

3.2 不同量化方案的细节差异

同样是INT4量化，工具链不同，效果也天差地别。我这里说几个常见的：

• 逐层量化的方案（类似GPTQ思路）：先加载模型，在显存或CPU内存里做校准，输出一份量化后的权重文件。这种方案推理质量稳定，是目前跑大模型的主流。
• 动态量化方案（类似GGUF里Q4_K_M这类）：把权重拆成小块，每块单独算scale和min/max。块越小精度越好，但metadata开销越大。GGUF的Q4_K_M是很多人的“甜点档位”。
• 还有一类低比特量化需要配合校准数据集，如果校准数据跟你的实际任务差别太大，量化质量会明显下滑。

我的建议是：搞不清楚就优先选Q4_K_M或同等档位的4bit量化。它兼顾了体积、速度和效果，是绝大多数本地玩家的默认选择。如果你想要更稳的质量，INT8是个平衡点，代价是显存占用比INT4翻倍。

3.3 量化对速度的影响

很多人以为量化后模型变小了，推理速度会自动变快。这话只说对了一半。权重显存的减少，确实减少了每次生成token时从显存搬运的数据量，所以decode速度会有提升。但是，某些量化格式在计算时需要额外的反量化步骤，如果框架的算子没优化到位，反而可能更慢。我实测过同一个模型，在同一个显卡上，INT8比INT4在某些架构下更快，因为那个INT8的算子优化得更好。所以，别只看显存，跑一下benchmark再说。

补一个关键点：如果你用CPU推理（没有独立显卡可用），量化就更加重要。CPU内存带宽比显存低一个数量级，权重越紧凑，搬运耗时越短，生成速度快得越明显。很多老笔记本能跑大模型，靠的就是极致的4bit量化加CPU offload。

4. 一张表看懂常见显卡的真实容量

现在我们把前面几节的知识合起来，给常见显卡做一次实测级容量判断。

4.1 显存-容量快速对照表

前提：短上下文（2K~4K），使用INT4量化作为大众档，并预留10%开销。

这张表我按实际体验调整过。为什么说24GB是“甜点之王”？因为当前社区里大量优秀模型在32B规模，INT4量化后权重16GB，24GB显卡加载后还能剩点空间给KV cache，跑4K~8K上下文很舒服。如果你只有12GB，13B的INT4模型权重6.5GB，剩下5.5GB给KV和开销，照样可以玩得很开心。

4.2 显存不是越看越大越好，关键是“匹配任务”

我在帮别人配机器时经常问三个问题：你主要跑多大的模型？上下文希望多长？是只做推理还是要微调？这三件事决定了显存需求完全不同的路线。

如果只跑7B聊天，8GB显卡就够了，别浪费钱上24GB。如果你想跑70B本地长文档分析，那光24GB也不够，要么买48GB以上，要么接受CPU offload的慢速。最怕的是“我什么都想跑”，那你就只能奔着24GB或更高走，而且还得接受一些模型只能低精度跑。

有些人问：那我先买一个8GB卡，后面不够再换？可以，但要注意，换卡牵扯到电源、散热、机箱尺寸，整套成本远高于一次性到位。这个我后面会提。

5. 显存够就万事大吉？算力和带宽同样卡脖子

显存是容量，算力是速度。这两件事经常被混为一谈。我有过一段经历：某次在48GB显存的专业卡上跑一个30B模型，居然比24GB的消费级卡还慢。后来查了参数才发现，那张48GB卡的核心是老架构，显存带宽反而不如新一代消费卡高。这就引出了一个容易被忽略的关键指标——显存带宽。

5.1 decode阶段是显存带宽的生意

大模型推理分两个阶段：prefill（对prompt做预处理）和decode（逐个生成输出token）。decode阶段是统治性的慢，它的速度几乎由“显存带宽”决定。

为什么？因为生成每个token时，推理框架都需要把模型全部权重过一遍。假设一个INT4量化后的30B模型，权重占约17GB。你的显存带宽如果是500GB/s，那每生成一个token，至少要读17GB权重，理想情况下的上限就是：500 ÷ 17 ≈ 29 token/s。实际还有各种开销，能跑到一半就算不错。

所以看显卡时，除了显存容量，还要看显存带宽：

这也是为什么同一个30B模型，在24GB高端卡上跑起来丝般顺滑，换成内存带宽低的平台就只能看到一顿一顿地输出。带宽不够，显存再多，速度也上不去。

5.2 prefill阶段才是拼算力的地方

反过来，prefill阶段处理长prompt时，计算量很大，这时候显卡的浮点算力（TOPS/TFLOPS）更重要。你用一个大模型做长文档总结，prompt本身就有好几千token，prefill就会花掉大量时间，如果显卡算力太弱，你会发现“首字延迟”特别久。

现在的消费级显卡在FP16算力上差距没有带宽那么夸张，但如果你要在本地做微调，那算力就是决定训练耗时的核心。很多东西不是显存不够，是算力不够。这句话听完可能就帮你避开了“只看显存容量买卡”的坑。

5.3 显存足够但跑不满的常见原因

我经常遇到“显存明明够，但推理特别慢”的情况，逐个排查下来通常是这几个问题：

第一，推理框架没开对优化。比如批量推理模式、算子融合、投机解码没启用，导致计算单元利用率很低。第二，系统内存跟显存之间发生了交换，模型一部分驻留在系统内存里，速度直接被内存带宽拖死。第三，电源管理或显卡功耗限制导致降频，笔记本尤其常见，插着电跟不插电跑出来的速度能差30%。

所以，你不仅要算显存，还要在跑正式任务之前看一眼显卡的功耗和温度。用工具观察功耗是不是跑满了，温度是不是过热降频了，这些细节才是决定实际体验的最后一公里。

6. 显存不够的四种续命方案

如果算完账发现显存确实不够，有几种成熟方案可以续命，各有代价，按需选择。

6.1 方案一：降低精度加控制上下文

这个最简单。把FP16换成INT8或者INT4，把上下文从16K降到8K甚至4K，显存需求马上就降下来。代价是长对话能力变弱，但如果你只是做固定任务的推理，影响很小。这也是我优先建议的步骤。尤其是很多人跑OOM，根本不是权重装不下，而是上下文设置得太放飞自我。我在某次测试里，把上下文从32K降到4K，同样一份模型，直接从OOM变成了流畅运行，前后只花了5分钟改配置。

6.2 方案二：CPU offload，慢但能跑

把一部分层放在CPU内存中，GPU只保留部分层。这样哪怕你的显卡只有8GB，也能跑30B甚至更大的模型。代价是速度断崖式下跌，因为CPU和GPU之间走PCIe总线，数据传输速度远低于显存带宽。

我个人的经验是：CPU offload适合“离线阶段性任务”，比如批量数据处理、一次性文档分析。你要是拿它做实时聊天，体验会很煎熬。而且注意，CPU内存必须足够大，比如你想跑70B的INT4（35GB权重），CPU内存至少得准备64GB以上，还得开足够大的交换分区。这种方法不是救命稻草，而是最后的兜底手段。

6.3 方案三：KV cache压缩和投机解码

如果你不想牺牲权重精度，又想省显存，可以从KV cache下手。很多推理框架支持KV cache的量化，比如用INT8代替FP16，KV cache占用立刻减半。再配合一些投机解码策略，运行时的显存占用也能有效控制。

投机解码的大致思路是：先用一个小模型快速草拟一批候选token，再让大模型批量验证。因为大模型只做验证而不用逐token生成，推理效率提高，显存压力也小一些。这项技术现在已经比较成熟，对长上下文场景的帮助非常明显。

6.4 从全量微调转向LoRA/QLoRA

如果你不光要推理，还要让模型学会新知识、新风格，那显存账本就要重新算了。全量微调一个7B模型，权重14GB，梯度14GB，优化器状态（比如AdamW）28GB，加起来60GB以上，普通显卡根本跑不了。这也是很多新手兴致勃勃下载模型想微调，结果一启动就OOM的原因。

而LoRA（低秩适配）只训练一小部分参数，显存需求大幅下降。QLoRA更夸张，它把基座模型量化到4bit再挂LoRA，7B模型的微调显存需求可以压到6~8GB。这意味着8GB显卡也能做微调实验。代价是微调能力比全量微调弱一点，但如果你只是想让模型学会某个领域风格，或者做角色扮演、格式化输出，LoRA绰绰有余。我一直觉得，普通人玩微调，直接上LoRA就是正解，别一上来就碰全量微调，那是花钱买教训。

7. 三步估算流程：从拿到模型到确认能不能跑

讲了这么多理论，最后给你一套可以直接照着做的实操流程。

7.1 第一步：拿到模型先查config

拿到一个模型，不要去网上搜“XX模型要多少显存”，直接看它的配置文件里的几个关键参数：模型参数量、层数、KV头数、头维度。如果你下载的是最新格式的模型文件，这些参数大概率就写在模型的配置信息里。打开看一眼，后面所有计算就都清楚了。

7.2 第二步：套一个估算公式

用下面这段Python代码，把关键参数填进去，立刻能看到估算结果（注意这是简化的估算脚本，实际框架会有额外开销，我会在后面加上修正系数）：

# 显存估算脚本（简化版） # 手动改这几个值 params_b = 7_000_000_000 # 模型参数量 layers = 32 # 层数 kv_heads = 8 # KV头数（GQA模型看这个，传统模型=注意力头数） head_dim = 128 # 每个头的维度 ctx_len = 4096 # 你想跑多少上下文 weight_bytes = 2 # FP16:2，INT8:1，INT4:0.5 # 1. 权重显存 weight_gb = params_b * weight_bytes / 1e9 print(f"权重显存: {weight_gb:.1f} GB") # 2. KV cache显存 kv_gb = 2 * layers * kv_heads * head_dim * ctx_len * 2 / 1e9 # 假设KV用FP16 print(f"KV cache: {kv_gb:.1f} GB") # 3. 加上框架开销和余量 total_gb = (weight_gb + kv_gb) * 1.15 print(f"推荐显存: {total_gb:.1f} GB")

跑出来的结果就是你要的“最低推荐值”。如果你的显卡显存比这个值小，要么砍上下文，要么换量化等级，要么就要接受CPU offload。

7.3 第三步：实测校准，别纸上谈兵

估算只是第一步，真正要看的是实际加载后的显存占用。我自己的习惯是：跑一个固定脚本，加载模型后随机生成一小段文本，用显卡状态工具看显存占用曲线。这样能同时验证权重显存、KV cache和框架开销三个部分准不准。

过程中注意看几个指标：空闲显存、加载模型后的显存、跑完一段长prompt后的显存峰值。如果峰值接近显存上限，就说明余量留得不够，建议降低上下文或者换量化档位。我踩过最惨的一次坑是：估算出来刚好卡在13.5GB，结果真跑起来直接OOM，后来一查是框架开了动态图显存优化，临时缓冲把空间撑爆了。所以，估算是用来“筛掉不可能的选项”的，不是用来精确预言“一定能跑”的。

如果非要我给一个最稳妥的结论：对于本地推理，显存留出20%余量是最舒服的；对于微调，余量建议保持30%以上，因为梯度回传和优化器状态会突然吃掉一大块显存。

最后再分享一个小技巧：你用同一张显卡，在相同框架下，分别用FP16、INT8、INT4加载同一个模型，跑同一段prompt，记录下显存占用和输出速度。这个简单的对比曲线，比任何参数表都更贴合你自己的实际环境。以后你再拿到新模型，直接查一下它的量化版本在这个曲线上的位置，就能在一分钟内判断出值不值得下载。这套方法我前后用了快两年，每次配新环境、新模型都是这么干的，几乎没有再被显存问题卡过脖子。