最近总有人问我显卡到底要多大才能跑本地大模型。这个问题看似简单但网上流传的“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模型是28GB32B是64GB72B是144GB。这个基础数值就是你买显卡时的“地板价”低于这个数模型根本加载不进去。但实际部署时很少直接用FP16裸跑因为显存太贵了。量化技术可以把每参数压到1字节甚至0.5字节INT8下7B模型权重约7GBINT4下约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.5GB14B约56GB约28GB约14GB约7GB32B约128GB约64GB约32GB约16GB72B约288GB约144GB约72GB约36GB注意这只是模型权重的理论值实际文件还会因为Embedding、LM Head等模块的实现细节略有出入。但用它做选型判断已经足够了。我建议你把这个“权重×2FP16显存”的口算方法刻在脑子里以后看到任何模型第一反应就能估算出它的底价。2. 量化与精度从FP16到INT4到底牺牲了什么2.1 三种主流量化格式怎么选量化是低显存部署的核心手段原理很粗暴把原来用2字节表示的浮点参数压缩成1字节或0.5字节的整型代价是精度损失。目前主流方案有三种GPTQ、AWQ、GGUF。GPTQ和AWQ都是面向GPU推理的量化方案适用于批量推理和并发服务场景vLLM、Text Generation Inference等框架里很常见。AWQ引入了激活感知量化时会更照顾对输出影响大的通道实际效果通常比GPTQ略稳。GGUF则是llama.cpp生态的格式它的特点是支持CPUGPU混合运行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_0Q5_K_MQ4_K_MQ3_K_M7B约15GB约7.5GB约5.2GB约4.7GB约3.8GB14B约29GB约14.5GB约9.7GB约9.0GB约7.0GB32B约65GB约33GB约21.5GB约20GB约15.5GB72B约144GB约73GB约47GB约44GB约34GB看到这里你大概理解了为什么8GB显卡玩本地LLM的首选是7B模型Q4量化权重约4.7GB留给KV Cache和框架开销的空间还有3GB左右只要把上下文长度控制在8K以内完全可以跑。而要跑14B的Q4量化光权重就要9GB8GB显卡已经放不下了只能把一部分层放到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大小 2K和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上下文约需1GB32K上下文约需4GB。听起来还行。再把同样的公式套到传统MHA结构的Llama 2 7B上KV头数32每token直接飙到0.5MB同样的8K上下文要4GB差距非常明显。72B这种大模型的KV Cache反而不一定可怕因为Qwen2.5-72B也用了GQAKV头数同样是8但层数增加到80层每token的KV Cache约0.3125MB。8K上下文约2.5GB32K约10GB。我把几个典型配置的估算结果整理成了表模型结构每token KV Cache4K上下文8K上下文32K上下文Qwen2.5-7BGQA(8头)约0.125MB约0.5GB约1GB约4GBLlama 2 7BMHA(32头)约0.5MB约2GB约4GB约16GBQwen2.5-14BGQA(8头)约0.18MB约0.7GB约1.5GB约6GBQwen2.5-32BGQA(8头)约0.25MB约1GB约2GB约8GBQwen2.5-72BGQA(8头)约0.31MB约1.3GB约2.5GB约10GBKV Cache还有一个放大效应容易被忽略并发请求。如果你用Ollama的OLLAMA_NUM_PARALLEL开多个并行请求每个请求都有自己独立的KV Cache4个并发就是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但有人把上下文长度拉满32KKV 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也可以只是长上下文时要注意剩余空间。24GBRTX 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量化。80GBA100/H100级别则能原生承载72B的FP16。但80GB一张卡太贵了很多团队会选择双卡方案。多卡推理的基本逻辑是把模型按层切分每张卡放一部分层卡间用NVLink或PCIe通信。实践中最需要注意的是通信带宽我测过PCIe 4.0 x16跑7B模型做张量并行通信开销占比不小所以多卡方案优先考虑NVLink或者至少PCIe 5.0。这个方案表格是我根据这些实操经验整理的可以直接当选型参考显存规模推荐模型配置上下文建议适合场景8GB7B Q4_K_M / 3B FP168K以内入门体验、日常对话12GB7B FP16 / 14B Q4_K_M16K以内轻度开发、代码生成16GB14B Q4/Q5 / 7B FP1632K以内主力开发、Agent任务24GB32B Q4 / 14B FP1616K-32K高质量推理、复杂任务32GB32B FP16 / 72B Q432K以内研究实验、长文档处理80GB72B 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] EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE0 EnvironmentOLLAMA_NUM_PARALLEL1保存后重启服务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加载权重约18GBLoRA微调通常要28-36GB一张24GB显卡比较悬。如果用QLoRA把模型量化到4bit再挂LoRA权重只要约6GB总显存10-14GB就能跑8GB显卡贴着边也能试但batch size要调得比较小。激活值这部分很多人忽略。micro batch size翻倍、序列长度翻倍激活值都会大幅上涨。我在微调时遇到过loss正常但显存持续攀升的情况最后定位就是length参数设置过大。实操时建议从batch size1、seq_len512开始逐步加到显存临界点这样既不容易OOM也能通过对比不同长度下的loss曲线找到自己的数据最合适的训练配置。6. 常见问题与显存排查实录6.1 显存溢出和异常排查速查表部署时间长了会遇到各种稀奇古怪的显存问题我把最常见的情况整理成了一张速查表现象可能原因处理方法加载模型直接CUDA OOM模型权重大于显存换更小量化档位或换更小模型跑一会才OOMKV Cache随上下文膨胀调低num_ctx限制上下文长度卡顿但显存没满部分层被offload到CPU减少同时加载的模型数量关掉并发经常被系统KillCPU物理内存不足升级内存或放弃大模型换小模型推理结果离谱量化等级太低换Q5_K_M或Q8_0牺牲一点显存换质量显存占用一直不降模型常驻显存设OLLAMA_KEEP_ALIVE0请求后立即释放花屏/报错但配置没问题显存颗粒故障用NVIDIA MATS工具做颗粒级检测最后一行重点说一下。如果你确认推理配置没问题但显存占用异常或者跑着跑着花屏那可能是显存颗粒硬件有故障。NVIDIA的MATSMemory Test System是显卡维修圈常用的显存检测工具能在Linux环境下对显存颗粒做精准压力测试甚至可以定位到具体是哪颗颗粒坏了。普通用户操作门槛比较高但如果你手里有淘汰显卡想捡垃圾这工具比那些Windows下的花哨检测软件靠谱得多。6.2 部署安全API密钥和配置管理的习惯还有一个容易被忽略的点虽然和显存无关但本地部署LLM时迟早会碰到——用Ollama这类本地推理工具密钥问题不太明显但如果你的项目要调用云端LLM API或者自己搭了OpenAI兼容网关API密钥千万别写死在代码和配置里。我见过有人把API Key直接写进ComfyUI节点配置或者Python脚本里然后整个仓库传上GitHub几分钟内就被爬虫扫走。正确的做法是用环境变量管理密钥运行时读取export OPENAI_API_KEYsk-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和深夜排查。