“你的显卡能跑多大的模型”这个问题几乎是每个本地模型玩家的第一道坎。显存计算说穿了就是算清楚模型要在显存里占几份、每份多重、有哪些临时的“草稿纸”。把这笔账算明白模型选择就会从“下载了才知道行不行”变成“看一眼参数量和量化档位就能判断八九不离十”。我见过太多人拿着16GB的卡去跑FP16精度的13B模型加载到一半跳出显存不足然后怀疑卡是不是坏了——其实根本没有算过账。这篇就是把这笔账彻底拆开讲。这篇文章面向的读者是想在本地显卡上部署或微调模型的人不管你是刚入门的爱好者还是想快速评估模型能不能落地的工程同学。我的目标是让你看完之后能拿着任何一张显卡三分钟做出判断甚至不用等模型文件真正下载完。1. 显存里装的到底是什么权重精度决定了“每页纸的厚度”1.1 所有显存账单的起点是参数量模型的“体重”上限由参数量决定。参数就是神经网络里成千上万个可学习的数值7B意味着七十亿个参数13B就是一百三十亿个。你把它理解成一本书的页数——页数定了纸张总重就大致定了剩下的问题是“用多厚的纸来印”。这个“纸的厚度”在深度学习里叫精度也就是每个参数用多少个字节来存储。常见的档位我给你列出来FP32单精度浮点每个参数占4字节最精确但最费显存。FP16 / BF16半精度浮点每个参数占2字节推理和混合精度训练的主流选择。INT88位整数量化每个参数占1字节。INT44位整数量化每个参数约占0.5字节现在大量本地部署用的就是这个档位。显存计算最核心的一条口算规则FP32 ≈ 4字节 / 参数FP16 / BF16 ≈ 2字节 / 参数INT8 ≈ 1字节 / 参数INT4 ≈ 0.5字节 / 参数1.2 参数量 × 精度 模型权重的基础显存这一段是纯算术但一定要亲手过一遍。十几亿参数在当前开源生态里已经是“小模型”我们也从1B开始看参数量FP32FP16/BF16INT8INT4约1B4GB2GB1GB0.5GB7B28GB14GB7GB3.5GB13B52GB26GB13GB6.5GB34B136GB68GB34GB17GB70B280GB140GB70GB35GB这个表格是整个显存计算的基石。举个例子某个7B模型以FP16保存权重就是14GB你看到下载链接旁边标了“13GB”或“14GB”的文件大小基本就是它了。反过来你看到某个13B模型提供的是INT4量化版权重算下来约6.5GB文件实际大小通常在7GB上下也基本吻合。1.3 别忽视词表和Embedding这类“固定杂费”模型文件里除了Transformer主干的参数还有一大块是词表Tokenizer对应的Embedding表。这部分把文本转成向量是模型真正“认识字”的地方。它对中文支持好的模型词表往往扩得比较大Embedding表可能占到1-2GB而且这个数字跟你的上下文长度无关是刚性的固定开销。所以更准确地说模型权重显存 主干参数显存 Embedding表显存。不过在工程估算里主干参数显存已经占了大头Embedding那点增量可以用后面要说的“安全系数”一起覆盖掉。我的习惯是先把表格里的数背下来再给最终结果预留出2GB左右的余量。2. 推理场景的真实账单权重之外还有KV Cache和运行时开销2.1 KV Cache就是那张越来越厚的“草稿纸”很多人以为显存账单到权重就结束了结果模型加载成功生成一小段就报显存不足。问题多半出在KV Cache上。自回归模型生成每一个新token时都要重新计算“当前token”和“之前所有token”之间的注意力关系。为了避免每次都把前面的文本重新算一遍模型会把每一个已经生成token的Key向量和Value向量暂存在显存里。这就是KV Cache名字的来历。你把它理解成做长题时的草稿纸不是每写一行就重读全文而是必须把已经写下的步骤都记下来随时拿来对照。上下文越长这张草稿纸就越厚而且它只增不减从生成第一个token开始就不断往上堆。2.2 手算一次KV Cache的量级KV Cache的显存公式可以简化为约等于 2 × 层数 × 每层每个token的KV存储量 × 上下文长度 × 精度字节我拿一个典型7B规模的模型举例32层、32个注意力头、每个头128维FP16精度。每个token在每一层里K和V各占一份也就是 2 × 32 × 128 8192 个浮点数。上下文长度设为2048时每个token每层8192 × 2字节 16KB一层所有token16KB × 2048 32MB全部32层32MB × 32 约1GB这个数字已经不小了。如果上下文开到4096KV Cache直接翻倍到约2GB。若是13B、34B这类更深更宽的模型层数更多、头数更多KV Cache还要再涨一截。长上下文是显存的隐形杀手但很多人完全没给它留预算。2.3 一张表看清不同上下文下KV Cache差异模型规模层数参考上下文2048上下文4096上下文81927B32约1GB约2GB约4GB13B40约1.6GB约3.2GB约6.4GB34B56约2.8GB约5.6GB约11GB这个表是按FP16精度估算的。如果你的推理框架支持KV Cache量化到8位那这些数字还能再砍一半代价是极轻微的质量折损。长上下文场景下我很推荐开。2.4 用16GB显卡推演一次完整账单现在把三块拼起来权重 KV Cache 运行时开销。运行时开销包括CUDA context、激活值、采样阶段临时张量、以及加载框架本身的占用通常在1.5-2GB上下具体取决于框架实现和批处理大小。先看7B模型FP16权重14GBKV Cache上下文2048约1GB运行时开销约1.5GB总计约16.5GB结论16GB卡跑7B FP16属于压线稍微开长上下文就可能OOM。再看7B模型INT4权重约4GBKV Cache上下文4096约2GB运行时开销约1.5GB总计约7.5GB结论非常轻松甚至可以把上下文拉高到8192。再看13B模型INT4权重约7GBKV Cache上下文4096约3.2GB运行时开销约2GB总计约12.2GB结论16GB卡能跑但上下文要克制4096是相对舒服的上限。这就是为什么同是16GB显卡跑13B模型几乎都推荐INT4量化——FP16的26GB权重从一开始就不可能塞进去。3. 训练与微调完全是另一笔账全参训练的显存账单为何能吓退单卡玩家3.1 优化器状态让每个参数的账单飙升到16字节如果你不是只跑推理还想训一训模型那显存账单直接改天换地。推理时你只需要把模型权重放进显存训练时你不仅要有权重还要有梯度还要有优化器的历史状态。以最常用的Adam优化器 混合精度训练为例每个参数大致要牵动这些开销项目每个参数的字节数FP16权重副本2字节FP32主权重用于精度累积4字节梯度2-4字节Adam一阶矩动量4字节Adam二阶矩方差4字节合计16-20字节拿7B模型算7B × 16字节 ≈ 112GB。这还没算前向反向过程中产生的激活值缓存真跑起来只会更高。所以全参数微调一个7B模型单卡几乎不用想需要的是多张专业计算卡组集群。这就是为什么基于LoRA这类参数高效微调的技术会那么流行——它只训练新增的一小撮参数优化器账单从“全模型规模”缩到“小参数规模”。3.2 LoRA微调为什么对显存友好得多LoRA的思路很简单冻结预训练模型的主干权重在旁边加一条低秩的旁路训练时只更新旁路。这样一来显存里的权重还是那么大7B FP16 14GB但梯度、优化器状态只跟旁路参数有关可能只占几百MB。不过别高兴得太早反向传播时为了计算梯度依然要保存前向过程的激活值。这些激活值随批量大小、序列长度线性增长。所以7B模型LoRA微调24GB卡能跑得比较从容16GB则需要配合梯度检查点不保存全部激活反向时重新算和小批量。3.3 一张对照表看清几种模式的显存需求模式7B模型大致需求说明全参微调混合精度110GB以上单卡基本没戏全参微调纯FP32130GB以上更夸张LoRA微调18-24GB可启动需小批量 梯度检查点推理FP16约16GB上下文2048左右推理INT45-7GB上下文可控所以下次看到有人问“我的卡能不能训练13B模型”先别急着答能或不能问他一句“全参还是LoRA”答案完全不同。4. 显存不够怎么办量化档位、上下文裁剪、内存调度与多卡拆分的取舍4.1 压低精度是性价比最高的第一步把权重从FP16降到INT8显存直接减半再降到INT4又减半。这个操作对所有模型都有效而且当下的量化算法已经非常成熟。不少人担心INT4会把模型“压废”但实测下来对话、翻译、文档总结这类任务上4位量化和FP16的输出普通人几乎分辨不出差别。真正敏感的是数学推理、代码生成这类需要严格逻辑的任务这时我会至少保留INT8或者干脆用小一号的FP16模型换精度。一个值得记住的经验能用INT4绝不上FP16省下来的显存留给上下文长度长期来看更值。量化模型的质量拐点通常在2位以下才明显4位远没到崩坏的程度。4.2 上下文裁剪是最容易忽略的显存开关KV Cache和上下文长度成正比。把默认的4096砍到2048很可能立刻释放1-2GB。遇到OOM时别急着换模型先问自己一个问题我真的需要那么长的上下文吗日常问答、代码补全2048基本够用只有处理长文档、长对话时再把窗口调大。很多推理框架还支持KV Cache量化把这个选项打开又能省约一半的缓存显存。两个开关一起动7B模型在8GB卡上跑出16GB卡才有的舒适度完全可能。4.3 权重借内存慢但能跑有些推理框架支持把模型权重部分放在系统内存里按层调度到显存或者利用内存映射机制按需读取。这种模式能把“模型显存需求”压缩到很小一块8GB显存的卡甚至能跑几十B量级的模型代价是每次生成token都要跨设备搬运数据速度慢得让人着急。它适合什么场景离线批量任务、偶尔跑一次验证、或者你预算有限但就是想看看大模型的本事。速度换容量是一个很公平的交易。4.4 多卡拆分把大模型按块分散如果你手头有多张卡张量并行可以把一个模型按层或按张量切片分布到多张卡上各自的KV Cache也跟着分摊。这个方案需要注意的是卡间通信带宽如果两张卡通过PCIe公共通道互联性能打折比较严重如果支持高速直连效率会好很多。多卡方案适合已经有多张卡的人不建议为了跑模型专门买一沓卡——很多时候一张24GB的卡比两张12GB卡更好用。4.5 按显存选模型的速查表推理场景显存容量推荐模型档位建议上下文8GB7B INT4 / 3B FP162048左右12GB7B INT8 / 13B INT42048-409616GB7B FP16 / 13B INT42048-409624GB13B FP16 / 34B INT44096左右48GB以上70B INT4 / 34B FP164096-8192这个表是我的实测习惯不是绝对的因为不同框架、不同量化方案的实现细节会有偏差但用来做第一次选型决策已经足够了。5. 实测验证与隐蔽坑别让显存监控数字骗了你5.1 十几行代码验证你的估算纸上算完最好的做法是用一个真实加载脚本验一遍。下面是我常用的最小验证方案以PyTorch生态为例import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id 你的模型目录 tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto ) model.eval() params sum(p.numel() for p in model.parameters()) print(f参数量: {params / 1e9:.2f}B) print(f模型权重显存: {model.get_memory_footprint() / 1024**3:.2f} GB)然后再开一个终端盯着显卡nvidia-smi --query-gpumemory.used,memory.total --formatcsv跑完加载后看两个数字get_memory_footprint()给出模型本体占用nvidia-smi给出包含运行时开销的真实占用两者之差基本就是CUDA context和框架杂项。接着把上下文设成你计划用的长度真正生成一段文本再看一次显存峰值——那个数字才是你实际部署时的硬上限。5.2 四个隐蔽坑我全踩过坑一上下文窗口设太高KV Cache爆掉。有个朋友在4090上跑7B INT4模型生成到一半必爆显存排查半天发现他把上下文窗口设成了16KKV Cache在FP16下吃掉了8GB。窗口调回4096一切正常。上下文这个参数在框架里太显眼了默认值往往又很大很多人根本没意识到它和KV Cache线性挂钩。坑二模型文件“半加载”占用的不是显存而是内存。有些框架为了启动更快先把权重映射到系统内存里按需搬运到显存。这时候你在nvidia-smi里看到显存占用不高但系统内存暴涨跑起来一个token要等半天。这不是显存判断错了是加载模式变了。看模型能不能跑不能只看显存剩余还要看内存压力。坑三服务框架退出后显存没释放。运行Web界面、API服务时进程如果没被完全终止显存会被一直占着。你查一下会发现没有活跃进程但显存使用率居高不下。遇到这种“莫名其妙少了几GB显存”的情况先看看有没有僵尸进程把它清理掉再判断模型能不能跑。坑四系统把内存“借”给了显卡看起来能跑实则龟速。Windows这类桌面系统在显存不够时会把系统内存当作共享显存模型不会直接报错而是“看起来加载成功”了但生成速度掉到每秒几个token还容易假死。如果你看到监控工具里“共享GPU内存”占用很高基本就是这个状态。在这种模式下测出来的“能不能跑”没有任何参考价值。5.3 统一内存和分页的作用边界现代框架越来越擅长“曲线救国”。统一寻址让CPU和GPU可以共享一块地址空间分页管理让权重可以在内存和显存之间按需换入换出。这些机制确实把能跑模型的显存下限压低了但代价是性能剧烈波动。我的建议是这些特性适合“偶尔跑一次”的容忍场景不适合作为常态部署方案。常态部署一定要保证模型权重能完整放进显存再留足KV Cache和运行时余量。否则你得到的是一个“时快时慢、还容易卡死”的体验远不如退一档模型来得稳定。我的实际操作习惯我现在选模型基本固定一套流程先查显卡显存再决定量化档位然后按“权重 KV Cache预算 2GB固定余量”反推上下文长度。模型库里常年备着三个档位——一个INT4的小模型处理日常问答一个FP16的中模型应对严谨任务一个INT8的大模型留给长文档。切换的成本很低但每换一次心里那本显存账都会重新过一遍。显存计算这件事说到底就是把“我买得起多大的卡”和“我应该下载哪个模型文件”两件事提前对齐省下来的是来回下载、反复OOM的时间。这篇文章里的数字都是工程近似不同框架、不同量化实现会有几个百分点的浮动但足够你把模型选择从“玄学”变成“算术”。下次再看到某模型标着“消费级显卡可跑”先别急着点下载拿这套方法算一遍你会有自己的答案。
