你手头有块 8G 显存的显卡想把最近开源的 7B 或 14B LLM 拉到本地跑一跑。网上的说法五花八门有人说 7B 模型 FP16 就得 14G 显存有人说量化后 7B 只要 5G还有人提醒你光看权重没用上下文一长照样爆显存。到底谁对其实都对差别在于你算的是哪一部分显存。这篇东西就是想把这些账一笔笔算清楚给你一套可以直接套用的计算公式顺便把 7B、14B、32B、72B 这几个主流规模的显存需求拉一张表看完你就能判断自己的显卡能跑什么、不能跑什么以及该怎么调参。市面上讲显存优化的文章不少但大多数只给结论不讲公式从哪来。这次我把模型权重、KV Cache、运行时开销全部拆开算并且把每一步推导过程写出来。你后面拿到任何模型只要填几个数字心里就有底了。1. 显存到底被谁吃掉了1.1 第一大头模型权重说到 LLM 部署绝大多数人第一反应就是模型文件有多大。比如 7B 模型名字里的 7B 表示它有 70 亿个参数。每个参数需要占一段内存来存数值这个数值精度决定了占用大小。如果用 FP16半精度浮点数每个参数占 2 字节用 FP32占 4 字节用 INT8占 1 字节用 INT4 或 Q4 这类量化格式大概占 0.5 字节。用最简单的公式算一下7B 参数的模型FP16 精度下权重部分就是 7 乘以 2等于 14GB。这就是“7B 要 14G 显存”说法的来源。这个数字是跑不掉的固定项无论你用多短的上下文、多大的 batch模型权重都实打实放在显存里。不过权重只是每个参数本身的大小。真正跑起来之后显存占用会明显高于这个数字因为还有另外几笔开销在等着你。1.2 第二大头KV CacheKV Cache 是很多人第一次部署时完全没概念的东西。它的作用是缓存历史 token 的 Key 和 Value 向量让模型在生成下一个 token 时不用从头计算前文的所有注意力。打个比方KV Cache 就像开会时的会议记录员。前面每个人说了什么他都认真记下来后面发言的人只要翻记录就能知道之前的内容不用把每个人再喊起来重新说一遍。但这个记录会随着会议时间越来越长笔记本也越来越厚。对应到显存里就是上下文越长KV Cache 占用的显存越大。很多人在短文本测试时看着显存还行一条长文本进去直接 OOM就是因为 KV Cache 涨上来了。极端情况下序列长度翻倍KV Cache 也翻倍而模型权重纹丝不动。1.3 被忽略的隐性开销除了权重和 KV Cache还有一块容易被忽略的开销CUDA context、激活值、临时缓冲区、推理框架自身的池化内存。这块很难精确计算但通常在 1GB 到 3GB 之间。如果开 Flash Attention、PagedAttention 这类显存优化方案激活值压力会小一些但框架初始化占用的基础内存依然存在。我见过最典型的情况有人用 nvidia-smi 看空闲显存是 14GB觉得跑 7B FP16 刚好够结果加载模型后立刻报 out of memory。原因就是他没给运行时开销留余量。所以后面所有估算里我都会强制加一个 1.5GB 左右的余量项。2. 权重显存的计算公式2.1 模型精度与每参数字节数权重的计算公式就一句话权重显存 参数量(单位 B) × 每参数占用的字节数这里的参数量单位 B 就是十亿7B 就是 714B 就是 14。不同精度的每参数占用如下精度类型每参数字节典型使用场景FP324 字节训练时主权重显存消耗极大FP16 / BF162 字节常用推理精度效果稳定INT81 字节量化推理有轻微精度损失INT4 / Q4约 0.5 字节GGUF 量化部署显存最省注意实际 GGUF 的 Q4_K_M 这类格式由于分块量化需要额外存储 scale 和 min/max 信息文件会比理论值略大一些。7B 模型 Q4 量化文件通常在 4GB 到 5GB 之间而不是精确的 3.5GB。但做显存估算时用 0.5 字节这个近似值已经足够。2.2 7B/14B/32B/72B 权重显存速查表用上面公式把四个主流规模分别算一遍模型规模FP32FP16 / BF16INT8INT4 / Q47B28GB14GB7GB约 4GB14B56GB28GB14GB约 7.5GB32B128GB64GB32GB约 18GB72B288GB144GB72GB约 40GB这张表可以直接解释很多现象。为什么 8G 显存只能跑 7B 量化因为 7B Q4 权重约 4GB还能挤一挤为什么 14B 至少要 16G 显存因为 14B Q4 权重约 7.5GB加上 KV Cache 和运行余量8G 卡实在塞不下。很多人看完这张表会说那我用 FP16 跑 32B 是不是需要 64G 显存对消费级显卡基本没戏但量化到 INT8 后 32GB 就能装进一张 48G 专业卡量化到 Q4 后 16G 到 24G 也有机会。这就是量化本地部署受欢迎的根本原因。3. KV Cache 是看不见的大户3.1 KV Cache 显存公式推导KV Cache 的计算公式比权重稍微复杂一点要理解每个变量KV Cache 单 token 占用(字节) 2 × 层数 × KV 头数 × head_dim × 精度字节数乘 2 是因为要同时缓存 K 和 V 两组向量。层数就是模型里的 Transformer 层数KV 头数和 head_dim 要重点解释一下。现在主流大模型基本都用了 GQA分组查询注意力也就是多个 Q 头共用一组 KV 头。以 Qwen2.5 系列为例子7B 模型是 28 层、4 个 KV 头、head_dim 128。代入公式2 × 28 × 4 × 128 × 2 57344 字节 ≈ 56KB/token也就是说每生成或处理一个 token多占 56KB 显存。如果上下文长度是 32K那 KV Cache 就是56KB × 32768 ≈ 1.75GB如果是 14B 模型层数和 KV 头数都会增加单 token 占用量就会大得多。每多一个 token 多几十上百 KB短文本感觉不到长文本直接爆显存。3.2 主流模型的 KV Cache 测算表不同模型的层数、KV 头数不一样严格来说要看模型 config.json 里的参数。这里以 Qwen2.5 系列的常见配置为例算出来的结果如下模型规模层数KV 头数head_dim单 token KV(FP16)8K 上下文32K 上下文128K 上下文7B28412856KB约 0.45GB约 1.75GB约 7GB14B488128192KB约 1.5GB约 6GB约 24GB32B648128256KB约 2GB约 8GB约 32GB72B808128320KB约 2.5GB约 10GB约 40GB看到这张表你应该明白我为什么说 KV Cache 是隐形大户。72B 模型只跑 8K 上下文KV Cache 只要 2.5GB但如果把上下文拉到 128KKV Cache 就要 40GB比很多量化后的模型权重还大。所以部署长上下文模型时KV Cache 量化非常值。把 KV Cache 从 FP16 压到 INT8KV 这块直接减半压到 INT4再减半。llama.cpp 这类框架已经支持这个选项后面我会给具体命令。4. 一套完整的显存估算公式附脚本4.1 把分项合成总公式完整估算应该是总显存 ≈ 模型权重显存 KV Cache 显存 运行时开销权重显存用参数量乘以精度字节数KV Cache 用前面的公式算运行时的 CUDA context、激活值、临时 buffer 统一按 1GB 到 3GB 预留。这样算出来的结果才接近你按下启动键之后 nvidia-smi 看到的真实占用。我自己的项目里通常按 1.5GB 预留runtime。如果开了 tensor parallel 或多进程服务预留量还要再加。宁多勿少因为一旦 OOM整个服务都会挂掉重启成本非常高。4.2 可以复制粘贴的估算脚本把公式整理成一个 Python 函数以后不管拿到什么模型填几个参数就有答案def estimate_vram( params_b: float, # 模型参数量7B 就填 7 precision_bytes: float, # 权重每参数字节数2FP16, 1INT8, 0.5INT4/Q4 layers: int, # Transformer 层数 kv_heads: int, # GQA 的 KV 头数 head_dim: int, # 单头维度 seq_len: int, # 期望的上下文长度 batch_size: int 1, kv_precision_bytes: float 2, # KV Cache 精度INT8 填 1 runtime_gb: float 1.5, # CUDA context 等运行余量 ): import math # 权重占用的字节 weights_bytes params_b * 1e9 * precision_bytes weights_gb weights_bytes / (1024**3) # KV Cache 占用的字节 kv_bytes ( 2 * layers * kv_heads * head_dim * seq_len * batch_size * kv_precision_bytes ) kv_gb kv_bytes / (1024**3) total_gb weights_gb kv_gb runtime_gb print(f权重显存: {weights_gb:.2f} GiB) print(fKV Cache: {kv_gb:.2f} GiB) print(f运行余量: {runtime_gb:.2f} GiB) print(f预计总占用: {total_gb:.2f} GiB) return total_gb # 示例Qwen2.5-7BQ4 权重KV 也压到 INT88K 上下文 estimate_vram( params_b7, precision_bytes0.5, layers28, kv_heads4, head_dim128, seq_len8192, kv_precision_bytes1, )输出大概会告诉你权重约 3.26 GiBKV Cache 约 0.22 GiB加运行余量后约 5 GiB。这个结果和 Ollama 实际跑 7B Q4 模型的占用非常接近。4.3 四档显卡到底能跑什么把权重和 KV Cache 打包看可以得到一张很实用的“显卡适配表”显卡显存推荐组合说明8G7B Q4 4K 上下文权重约 4GBKV 约 0.2GB可以流畅跑12G14B Q4 8K 上下文 或 7B FP1614B Q4 权重约 7.5GB8K 上下文 KV 约 1.5GB刚好16G14B Q4 32K 上下文 或 32B Q4 短上下文32B Q4 权重约 18GB16G 卡有点紧需 offload24G32B Q4 8K 上下文 或 14B FP16 长上下文32B Q4 权重约 18GB再加 KV 是极限操作48G72B Q4 短上下文 或 32B FP1672B Q4 权重约 40GB上下文长了就要上 KV 量化8G 显存跑 14B Q4 能不能跑能但必须把大量层 offload 到 CPU速度会掉到每秒几个 token体验很差。与其这样不如老老实实跑 7B Q4。这是我用“算完后发现显存不够”踩过几次坑之后总结出来的原则。5. 低显存部署可以这样操作5.1 量化是第一生产力在低显存环境下跑 LLM量化是绕不开的一条路。最推荐的做法是直接用 GGUF 格式的量化模型配合 llama.cpp 或 Ollama 这类推理框架。GGUF 里的 Q4_K_M、Q5_K_M、Q6_K 都是比较常见的量化档位。我的选择习惯是能上 Q5 或 Q6 就不上 Q4前提是显存允许。Q4 在大部分任务上表现还可以但在需要输出复杂代码、长文推理、精确计算这些场景下和 FP16 的差距会明显一些。所以显存紧张时先用 Q4 跑通流程如果发现质量确实不行再升到 Q5 或 Q6。对于 DeepSeek 蒸馏版这类 7B 模型直接下载 Q4_K_M 的 GGUF 文件在 Ollama 里一条命令就能跑起来。这也是很多新手第一次在本地跑起对话模型的路径。5.2 控制上下文长度就是控制显存很多人以为自己需要 32K 上下文实际上大多数日常任务 4K 到 8K 就够用。上下文长度直接影响 KV Cache所以把模型默认的 32K 改成 8KKV Cache 直接降到四分之一。Ollama 里用 Modelfile 设置上下文长度FROM qwen2.5:7b-instruct-q4_K_M PARAMETER num_ctx 8192然后用这个 Modelfile 创建模型ollama create my-7b -f Modelfilellama.cpp 里更直接启动时加上-c参数./llama-cli -m qwen2.5-7b-instruct-q4_K_M.gguf -c 8192 -ngl 99这里的-ngl 99表示尽可能把层放到 GPU如果你的显存不够放全部层改成具体数字比如-ngl 28让一部分层跑在 CPU 上。5.3 KV Cache 量化也能省不少权重可以做 INT4KV Cache 同样可以量化。llama.cpp 支持把 K 和 V 缓存压到 INT8 或 INT4效果非常直接。结合前面的公式KV Cache 量化成 INT8 后那一大块显存直接减半。在 llama.cpp 新版命令里可以加-ctk q8_0 -ctv q8_0如果追求更极端可以用q4_0但效果会变差一些。我一般在 24G 显存上跑 32B 模型长上下文时会开 KV INT8视觉上几乎感觉不到质量下降但 OOM 的概率明显降低。5.4 进阶手段显存池化与页式注意力如果项目允许可以考虑换用 vLLM 这类推理框架。它有 PagedAttention把 KV Cache 按页管理显存利用率比传统缓存分配高不少还能用--max-model-len限制最大长度防止某个极端请求把显存打满。另外不管用什么框架都要养成显存清理的意识。PyTorch 生态里torch.cuda.empty_cache()只能释放缓存块不保证归还给操作系统最可靠的方式是删掉对象之后重启进程。像 ComfyUI 这类应用里专门有显存清理节点本质也是调用类似机制。换模型之前清一次比堆好几个模型一起把显存耗尽要稳得多。6. 常见问题与排查技巧实录6.1 按公式算够用为什么还是 OOM这是我被问过最多次的问题。公式算出来 14.5GB刚好接近 16G 显卡结果一加载就爆。原因通常出在三个地方一是激活值。推理时计算中间的 Attention 矩阵和一整层前向传播的中间结果都会占用额外显存。尤其使用 transformers 库时如果没开 Flash Attention长序列下激活值非常可观。二是显存碎片。CUDA 显存分配往往不是连续的多次申请释放之后即使总空闲容量足够也可能没有一整块连续空间放得下新的大张量。我的经验是算出来的总占用写 16GB实际在 16G 显卡上基本别跑最好留出至少 1GB 到 2GB 缓冲。三是框架自身的池化内存。你看进程占用了 15G其实里面有一部分是 PyTorch 或 CUDA 的缓存池虽然 nvidia-smi 显示占用但可以通过 empty_cache 部分释放。解决办法就是暴力重启进程或者用 vLLM 这类专门做显存调度的框架。6.2 量化之后模型“变笨”怎么办遇到这种情况先别急着怪量化。先用同样提示词跑几次 FP16 或低量化版本对比确定是不是精度损失导致的。如果确实是量化精度问题按优先级调整把 Q4 换成 Q5_K_M 或 Q6_K损失一点显存换回质量再把上下文长度缩短因为过长上下文会放大量化误差最后才考虑换更大的模型但保持低量化比如 14B Q4 通常比 7B FP16 更适合生成复杂内容。我实测下来的体感是日常对话、文案写作、知识问答这类任务Q4 完全够用但结构化输出、工具调用、代码生成这些任务Q5 以上更稳。6.3 训练和微调需要多少显存训练比推理费显存得多因为推理只需要保存模型参数训练还要保存梯度、优化器状态以及反向传播需要的中间激活值。同等规模下训练通常需要推理权重的 4 到 6 倍显存。拿 LoRA 微调来举例。9B 模型 FP16 推理权重 18GB但做 LoRA 微调实际显存需求可能要 35GB 到 50GB具体取决于 batch size、序列长度、是否使用梯度检查点。这就是为什么很多人用 Q4 量化版做 LoRA而不是直接拿全精度模型练。如果你只有 8G 显存LoRA 微调 9B 模型基本不现实即使强行量化可行速度和稳定性也很成问题。这种情况不如租一张 24G 以上的卡或者直接用云端 API。6.4 如何准确看到显存用量排查显存问题别靠感觉直接用工具看。终端里基础命令nvidia-smi想盯实时变化加一个 watch 循环watch -n 1 nvidia-smi在 Python 里还可以更细地看每个 tensor 的占用import torch print(torch.cuda.memory_summary()) del model torch.cuda.empty_cache()不过要明确一点empty_cache()只是把 PyTorch 持有的缓存块还给 CUDA 缓存池进程实际占用不一定立刻掉下来。这在换模型测试时很常见最舒服的办法还是重启 Python 进程。6.5 长上下文为什么越跑越卡很多人发现同一个模型对话长度超过一定量之后生成速度越来越慢。原因有四层一是 KV Cache 越来越大计算时读写显存的开销增加二是传输带宽有限长上下文注意力计算量增长比线性还快三是有些框架在显存不够时开始把 KV Cache 换到 CPU速度断崖式下降四是碎片化导致缓存效率降低。所以长上下文场景下如果发现越跑越慢先看看显存是不是已经接近占满再看是不是 CPU offload 被触发了。如果是优先做 KV Cache 量化或者干脆把上下文上限调低一点。最后说一个我自己的习惯。拿到一个新模型我会先按“权重 KV Cache 1.5G 余量”把账算一遍再决定精度档位、上下文长度和要不要 offload。这套流程帮我避开好多次“以为够结果跑不起来”的翻车。另外如果你的显存卡得很紧别急着换模型先把上下文减半再试一次。从 32K 减到 16KKV Cache 直接少一半而模型权重还是那个固定值。这种改动往往比折腾半天量化参数更立竿见影。
