最近总有人问我，显卡到底要多大才能跑本地大模型。这个问题看似简单，但网上流传的“7B模型要14GB显存”这种说法，很容易把人带沟里去。我见过太多人拿着公式算完觉得没问题，结果一加载就报CUDA Out of Memory，或者在Ollama里跑起来慢得像幻灯片。原因很简单：显存占用从来不只有“模型权重”这一项，KV Cache、精度格式、上下文长度、并发请求数，每一项都能让最终数字翻倍甚至翻几倍。
这篇文章我想把LLM推理时的显存占用彻底拆开，给出一套可以直接套用的通用计算公式，再把7B、14B、32B、72B这几个主流档位在FP16、INT8、INT4/GGUF Q4等常见精度下的真实显存需求整理成表。最后结合Ollama部署，聊聊低显存机器到底该怎么选模型、怎么调参数，以及我踩过的那些坑。无论你是刚接触本地部署的新手，还是准备给团队搭推理服务的工程师，这份笔记应该都能帮你少走不少弯路。
1. 显存占用拆解：一个能落地估算的通用公式
1.1 显存里的钱都花在哪四笔账上
很多人算显存只算模型权重，这是最大的误区。一次完整的LLM推理过程中，显存占用至少包含四部分：模型权重、KV Cache、激活值、框架开销。
模型权重好理解，就是模型参数本身占用的空间。KV Cache是注意力机制运行时的“草稿纸”，模型每生成一个token，都要把之前所有token的Key和Value缓存下来，用于计算当前token的注意力分数，这部分的显存占用会随上下文长度线性增长。激活值则是前向计算过程中每层的中间结果，推理时batch size不大，这部分通常只占几百MB到几个GB，但训练或微调时会暴涨。框架开销包括CUDA上下文、计算图、cuBLAS/cuDNN的临时缓冲区等，一般在几百MB到1GB左右，你会在nvidia-smi里看到一个“基础底噪”。
所以通用的估算公式可以写成：
推理显存(M) ≈ 模型权重 + KV Cache + 激活值 + 框架开销其中模型权重是最容易算的：参数量 × 每参数字节数。FP32是4字节，FP16/BF16是2字节，INT8是1字节，INT4约0.5字节。这也是为什么同一个模型在不同精度下，显存需求能差出好几倍。
1.2 从参数量到“B”到“GB”的换算
参数量里的“B”代表Billion，也就是十亿。一个7B模型FP16加载，光权重就需要 7 × 2 = 14GB。14B模型是28GB，32B是64GB，72B是144GB。这个基础数值就是你买显卡时的“地板价”，低于这个数，模型根本加载不进去。
但实际部署时很少直接用FP16裸跑，因为显存太贵了。量化技术可以把每参数压到1字节甚至0.5字节，INT8下7B模型权重约7GB，INT4下约3.5GB。再加上KV Cache和框架开销，一张8GB显卡跑7B模型的INT4量化版，在短上下文下是可行的，这就是“低显存跑大模型”能够成立的根本原因。
我把不同参数规模、不同精度下的纯模型权重显存需求整理成了表格，方便你对照：
| 参数量 | FP32 (4B/param) | FP16/BF16 (2B/param) | INT8 (1B/param) | INT4 (0.5B/param) |
|---|---|---|---|---|
| 7B | 约28GB | 约14GB | 约7GB | 约3.5GB |
| 14B | 约56GB | 约28GB | 约14GB | 约7GB |
| 32B | 约128GB | 约64GB | 约32GB | 约16GB |
| 72B | 约288GB | 约144GB | 约72GB | 约36GB |
注意，这只是模型权重的理论值，实际文件还会因为Embedding、LM Head等模块的实现细节略有出入。但用它做选型判断已经足够了。我建议你把这个“权重×2=FP16显存”的口算方法刻在脑子里，以后看到任何模型，第一反应就能估算出它的底价。
2. 量化与精度：从FP16到INT4到底牺牲了什么
2.1 三种主流量化格式怎么选
量化是低显存部署的核心手段，原理很粗暴：把原来用2字节表示的浮点参数，压缩成1字节或0.5字节的整型，代价是精度损失。目前主流方案有三种：GPTQ、AWQ、GGUF。
GPTQ和AWQ都是面向GPU推理的量化方案，适用于批量推理和并发服务场景，vLLM、Text Generation Inference等框架里很常见。AWQ引入了激活感知，量化时会更照顾对输出影响大的通道，实际效果通常比GPTQ略稳。GGUF则是llama.cpp生态的格式，它的特点是支持CPU+GPU混合运行，Ollama底层用的就是它。GGUF还内置了多档量化等级，从Q2_K、Q3_K、Q4_K_M、Q5_K_M一路到Q8_0，粒度非常细。
这里我直接给结论：个人本地部署，优先选GGUF的Q4_K_M，这是性价比最均衡的一档。Q8_0效果更接近原版但文件体积大了近一倍，Q2和Q3日常用起来掉质量明显，我实测在代码生成和摘要任务上经常出现逻辑断裂，不建议正式使用。
2.2 7B/14B/32B/72B量化后实际有多大
理论字节数是一回事，真实文件大小是另一回事。GGUF的Q4_K_M并不是每个参数都严格用4bit，部分敏感层会保留更高精度，所以实际文件会略大于“参数量×0.5”。我以Qwen2.5系列官方GGUF文件为例，把常见档位的实际大小列出来：
| 模型 | FP16原版 | Q8_0 | Q5_K_M | Q4_K_M | Q3_K_M |
|---|---|---|---|---|---|
| 7B | 约15GB | 约7.5GB | 约5.2GB | 约4.7GB | 约3.8GB |
| 14B | 约29GB | 约14.5GB | 约9.7GB | 约9.0GB | 约7.0GB |
| 32B | 约65GB | 约33GB | 约21.5GB | 约20GB | 约15.5GB |
| 72B | 约144GB | 约73GB | 约47GB | 约44GB | 约34GB |
看到这里你大概理解了，为什么8GB显卡玩本地LLM的首选是7B模型Q4量化：权重约4.7GB，留给KV Cache和框架开销的空间还有3GB左右，只要把上下文长度控制在8K以内，完全可以跑。而要跑14B的Q4量化，光权重就要9GB，8GB显卡已经放不下了，只能把一部分层放到CPU，这就是所谓“部分offload”，速度会明显下降。
注意：量化后的模型文件大小直接影响的是加载时的最小显存需求，但KV Cache依然按加载精度另算。很多人在Ollama里拉了一个Q4模型，发现显存还是吃紧，多半就是没算KV Cache这笔账。
3. KV Cache：上下文长度带来的隐藏显存开销
3.1 KV Cache到底是怎么产生的
KV Cache大概是显存估算里最容易被忽略、也最容易导致OOM的部分。你可以把它理解为模型在对话时做的“笔记”：生成第100个token时，注意力机制需要重新计算第100个token与前面99个token的关系。如果不缓存，每次生成都要把前面所有token的Key和Value重新算一遍，速度会慢到不可接受。所以推理框架会把这些中间结果缓存下来，这就是KV Cache。
KV Cache的大小和模型的层数、注意力头数、上下文长度、并发请求数直接相关，核心计算公式是：
KV Cache大小 = 2（K和V两个矩阵） × 层数 × KV头数 × 每头维度 × 上下文长度 × 每元素字节数这里“每元素字节数”通常和模型加载精度一致，FP16就是2字节。注意一个关键差异：传统MHA结构里，KV头数等于注意力头数，比如Llama 2 7B有32个头；而新一代模型普遍使用GQA分组查询注意力，比如Qwen2.5-7B的KV头数只有8个。GQA的意义就在于大幅压缩KV Cache——这让长上下文推理成为可能。
3.2 不同模型在不同上下文下的KV Cache估算
以Qwen2.5-7B为例，它的配置是32层、KV头数8、每头维度128。代入公式：
每token KV显存 = 2 × 32 × 8 × 128 × 2字节 = 131072字节 ≈ 0.125MB所以8K上下文约需1GB，32K上下文约需4GB。听起来还行。再把同样的公式套到传统MHA结构的Llama 2 7B上，KV头数32，每token直接飙到0.5MB，同样的8K上下文要4GB，差距非常明显。
72B这种大模型的KV Cache反而不一定可怕，因为Qwen2.5-72B也用了GQA，KV头数同样是8，但层数增加到80层，每token的KV Cache约0.3125MB。8K上下文约2.5GB，32K约10GB。我把几个典型配置的估算结果整理成了表：
| 模型 | 结构 | 每token KV Cache | 4K上下文 | 8K上下文 | 32K上下文 |
|---|---|---|---|---|---|
| Qwen2.5-7B | GQA(8头) | 约0.125MB | 约0.5GB | 约1GB | 约4GB |
| Llama 2 7B | MHA(32头) | 约0.5MB | 约2GB | 约4GB | 约16GB |
| Qwen2.5-14B | GQA(8头) | 约0.18MB | 约0.7GB | 约1.5GB | 约6GB |
| Qwen2.5-32B | GQA(8头) | 约0.25MB | 约1GB | 约2GB | 约8GB |
| Qwen2.5-72B | GQA(8头) | 约0.31MB | 约1.3GB | 约2.5GB | 约10GB |
KV Cache还有一个放大效应容易被忽略：并发请求。如果你用Ollama的OLLAMA_NUM_PARALLEL开多个并行请求，每个请求都有自己独立的KV Cache，4个并发就是4倍。很多人开了并发后频繁OOM，往往不是权重放不下，而是KV Cache把剩余显存吃光了。
3.3 长上下文场景下的优化手段
针对KV Cache占用过高，实际部署时有几个有效手段。第一是量化KV Cache，在llama.cpp里可以设置KV Cache为8bit甚至4bit精度，显存能省一半以上，代价是极端长上下文场景下精度略有损失，我实测常规对话和文档总结场景几乎无感。第二是限制上下文长度，Ollama里可以通过num_ctx参数控制，比如只需要处理短文本时，没必要默认拉满128K。第三是使用支持PagedAttention的推理框架，它像操作系统的虚拟内存一样按需分配KV Cache，能显著降低碎片浪费，vLLM就是这个思路。
实操心得：我遇到的大部分“8GB显存跑不动7B”问题，最后查下来都是KV Cache在作祟。权重只要4.7GB，但有人把上下文长度拉满32K，KV Cache直接吃掉4GB，再加上框架开销，刚好爆掉。把上下文压到8K，问题立刻解决。
4. 按显存选方案：从8GB到80GB怎么配
4.1 8GB和12GB显卡的极限配置
8GB显存是目前很多玩家手里最尴尬的配置，但完全能玩。我的推荐顺序是：首选7B模型的Q4_K_M或Q5_K_M量化版，权重约4.7-5.2GB，上下文控制在8K以内，KV Cache约1GB，整体占用在6.5GB左右，运行稳定。次选是3B或4B模型的FP16版本，比如Qwen2.5-3B约6.5GB权重，短上下文也能跑。最不推荐的是硬上14B的Q4，虽然有些教程说“8GB也能跑”，但那是因为Ollama会自动把放不下的层丢到CPU，实际速度可能跌到每秒几个token，体验基本不可用。
12GB显卡（比如RTX 3060）就好很多。7B模型可以上FP16原版或Q8_0，几乎不掉质量；14B模型选Q4_K_M也刚好能放下，权重约9GB，再加上KV Cache，只要上下文不超过16K，体验很流畅。
4.2 16GB和24GB的舒适区间
16GB显存是玩14B模型的性价比甜点区。我自己的主力机就是16GB，日常用14B的Q4_K_M跑代码生成，上下文拉到32K，显存占用大概11-12GB，剩余空间给激活值和系统缓冲，非常稳。想追求效果的话，14B的Q5_K_M或Q8_0也可以，只是长上下文时要注意剩余空间。
24GB（RTX 4090/3090）则可以驾驭32B模型的Q4量化，权重约20GB，剩下4GB维持KV Cache，短上下文没问题，长上下文就需要权衡了。想追求高质量的代码补全或复杂推理，这个组合基本够用。如果一定要在24GB上跑72B，也不是完全不行，Q3_K_M量化后权重34GB，超出部分offload到CPU，属于“能跑但慢”的状态，只适合玩玩，不适合正经工作。
4.3 32GB以上：大模型与多卡策略
32GB显存（比如Mac Studio的M系列统一内存或高端专业卡）可以舒服地跑32B全精度FP16或72B的Q4量化。80GB（A100/H100级别）则能原生承载72B的FP16。但80GB一张卡太贵了，很多团队会选择双卡方案。多卡推理的基本逻辑是把模型按层切分，每张卡放一部分层，卡间用NVLink或PCIe通信。实践中最需要注意的是通信带宽，我测过PCIe 4.0 x16跑7B模型做张量并行，通信开销占比不小，所以多卡方案优先考虑NVLink或者至少PCIe 5.0。
这个方案表格是我根据这些实操经验整理的，可以直接当选型参考：
| 显存规模 | 推荐模型配置 | 上下文建议 | 适合场景 |
|---|---|---|---|
| 8GB | 7B Q4_K_M / 3B FP16 | 8K以内 | 入门体验、日常对话 |
| 12GB | 7B FP16 / 14B Q4_K_M | 16K以内 | 轻度开发、代码生成 |
| 16GB | 14B Q4/Q5 / 7B FP16 | 32K以内 | 主力开发、Agent任务 |
| 24GB | 32B Q4 / 14B FP16 | 16K-32K | 高质量推理、复杂任务 |
| 32GB | 32B FP16 / 72B Q4 | 32K以内 | 研究实验、长文档处理 |
| 80GB | 72B FP16 / 更大模型 | 视需求 | 生产环境、全量微调 |
5. 低显存运行实操：Ollama部署与调优记录
5.1 Ollama的显存策略与环境变量
Ollama是目前本地部署最省心的工具，它对显存的态度是“有多少用多少，不够就offload到CPU”。默认情况下，它会把所有模型层尽量加载进显存，显存不足时自动把一部分层放到内存，通过CPU计算。这种设计保证了低显存机器“能跑”，但代价是速度下降。
想让Ollama的显存策略更可控，有三个环境变量非常关键。OLLAMA_MAX_LOADED_MODELS控制同时加载的模型数量，设置为1可以避免多个模型抢占显存；OLLAMA_KEEP_ALIVE控制模型在显存中的保留时间，设为0表示处理完请求立刻释放，适合多模型切换频繁的场景；OLLAMA_NUM_PARALLEL控制并发请求数，每增加一个并发，KV Cache占用就翻一倍，显存紧张时务必设置为1。
Linux下通过systemd配置环境变量的方法我直接给出来：
sudo systemctl edit ollama在打开的编辑窗口里填入：
[Service] Environment="OLLAMA_MAX_LOADED_MODELS=1" Environment="OLLAMA_KEEP_ALIVE=0" Environment="OLLAMA_NUM_PARALLEL=1"保存后重启服务：
sudo systemctl daemon-reload sudo systemctl restart ollamaWindows用户在系统环境变量里设置同名变量后重启Ollama即可，macOS用户可以用launchctl setenv设置。
5.2 一次8GB显存跑7B模型的完整配置过程
我拿自己一台8GB显存的旧机器，一步步演示怎么把Qwen2.5-7B跑起来。第一步自然是安装Ollama并拉取模型：
ollama run qwen2.5:7b默认会拉取Q4_K_M量化版。运行后立刻查看显存占用：
nvidia-smi我观察到的情况是模型权重约4.7GB，加上CUDA上下文等开销，初始占用5.2GB左右。因为是默认参数，上下文长度会按模型配置来，此时如果直接抛一个很长的文档进去，KV Cache就会迅速膨胀，很可能OOM。
把这个参数压下来，在Ollama交互式会话里执行：
/set parameter num_ctx 8192 /set parameter num_predict 2048设置后再次观察nvidia-smi，显存占用大概在6.3GB附近，非常稳定。如果遇到加载时直接被系统OOM Kill（不是CUDA OOM，而是进程被杀），说明物理内存也不够，建议换更小的量化档位，比如把7B的Q4降级到Q3_K_M，或者直接换3B模型。
5.3 微调场景：LoRA和QLoRA显存怎么估
聊完推理，再聊微调。很多人在搜索“LoRA一个9B模型需要多少显存”这类问题时，得到的答案五花八门。实际上LoRA微调的显存大头不是训练参数，而是模型加载成本和激活值。全参微调9B模型，混合精度AdamW下，权重、梯度、优化器状态叠加，通常需要接近20倍参数字节数的显存，也就是9B × 2字节 × 16左右，单卡根本跑不动。但LoRA只训练极少一部分参数，优化器状态可以忽略不计，显存主要就是模型权重加激活值。
我的经验公式是：LoRA微调的显存≈模型加载显存×1.5到2倍。以9B模型为例，如果用BF16加载，权重约18GB，LoRA微调通常要28-36GB，一张24GB显卡比较悬。如果用QLoRA把模型量化到4bit再挂LoRA，权重只要约6GB，总显存10-14GB就能跑，8GB显卡贴着边也能试，但batch size要调得比较小。
激活值这部分很多人忽略。micro batch size翻倍、序列长度翻倍，激活值都会大幅上涨。我在微调时遇到过loss正常但显存持续攀升的情况，最后定位就是length参数设置过大。实操时建议从batch size=1、seq_len=512开始，逐步加到显存临界点，这样既不容易OOM，也能通过对比不同长度下的loss曲线，找到自己的数据最合适的训练配置。
6. 常见问题与显存排查实录
6.1 显存溢出和异常排查速查表
部署时间长了，会遇到各种稀奇古怪的显存问题，我把最常见的情况整理成了一张速查表：
| 现象 | 可能原因 | 处理方法 |
|---|---|---|
| 加载模型直接CUDA OOM | 模型权重大于显存 | 换更小量化档位，或换更小模型 |
| 跑一会才OOM | KV Cache随上下文膨胀 | 调低num_ctx，限制上下文长度 |
| 卡顿但显存没满 | 部分层被offload到CPU | 减少同时加载的模型数量，关掉并发 |
| 经常被系统Kill | CPU物理内存不足 | 升级内存，或放弃大模型换小模型 |
| 推理结果离谱 | 量化等级太低 | 换Q5_K_M或Q8_0，牺牲一点显存换质量 |
| 显存占用一直不降 | 模型常驻显存 | 设OLLAMA_KEEP_ALIVE=0，请求后立即释放 |
| 花屏/报错但配置没问题 | 显存颗粒故障 | 用NVIDIA MATS工具做颗粒级检测 |
最后一行重点说一下。如果你确认推理配置没问题，但显存占用异常或者跑着跑着花屏，那可能是显存颗粒硬件有故障。NVIDIA的MATS（Memory Test System）是显卡维修圈常用的显存检测工具，能在Linux环境下对显存颗粒做精准压力测试，甚至可以定位到具体是哪颗颗粒坏了。普通用户操作门槛比较高，但如果你手里有淘汰显卡想捡垃圾，这工具比那些Windows下的花哨检测软件靠谱得多。
6.2 部署安全：API密钥和配置管理的习惯
还有一个容易被忽略的点，虽然和显存无关，但本地部署LLM时迟早会碰到——用Ollama这类本地推理工具，密钥问题不太明显，但如果你的项目要调用云端LLM API，或者自己搭了OpenAI兼容网关，API密钥千万别写死在代码和配置里。
我见过有人把API Key直接写进ComfyUI节点配置或者Python脚本里，然后整个仓库传上GitHub，几分钟内就被爬虫扫走。正确的做法是用环境变量管理密钥，运行时读取：
export OPENAI_API_KEY=sk-xxxxPython侧这样读取：
import os api_key = os.environ.get("OPENAI_API_KEY") if not api_key: raise ValueError("请先设置 OPENAI_API_KEY 环境变量")涉及配置文件时，始终把.env之类的文件添加到.gitignore里，密钥永远不要进版本库。这是一个成本极低但收益极高的习惯，越早养成越好。
最后再分享一个我个人的体会：显存计算和选型这件事，最忌讳的就是只看纸面数字。公式能帮你快速排除不靠谱的方案，但真正让部署顺滑的，是对KV Cache、并发、上下文长度这些软参数的反复调优。我现在的习惯是拿到一个新显卡，先跑一遍nvidia-smi看底噪，再按这篇文章的思路把权重和KV Cache分开算，最后用小模型把推理框架的配置调顺了，再放大模型一次到位。这个过程不能省，省了就是无穷无尽的OOM和深夜排查。
