你的显卡能跑多大的模型我在各种群里看到这个问题没有一千也有八百次。很多人上来就报显卡型号然后问“能跑多少B”仿佛显存这件事存在一张标准答案表。但实际答案完全不同同一个7B模型FP16和INT4之间能差出三四倍显存上下文从4K拉到32KKV Cache能多占十几个G推理和训练两个场景需求更是差出一个数量级。与其抄别人的配置单不如花几分钟把显存这笔账自己算明白。这篇文章就把显存计算拆开讲清楚给你一套可以落地用的估算方法并且附上我平时用的一段显存估算脚本。不管你是刚入门的玩家还是想上大模型微调的老手看完都能自己回答“我的卡能跑多大的模型”这个问题。1. 显存账本模型跑起来显存花在了哪三笔1.1 第一笔模型权重是绕不开的“大头基础款”权重就是模型里那些矩阵参数所有人都知道要先算这笔账。模型参数量如果是7B也就是70亿个参数用半精度FP16存储时每个参数占2字节那权重部分就是7×214GB。这是很单纯的一道乘法参数量十亿为单位乘以每参数字节数等于权重需要的显存。这里有一个值得记下的细节BF16和FP16在我们做显存估算时都按2字节算但它们的特性不一样。BF16的指数范围和FP32一样宽尾数精度低大数值不容易溢出所以现在很多开源模型预训练和推理默认用BF16FP16尾数精度高但指数范围窄数值一大容易出现NaN。对显存计算来说这两个精度没有差别都是2字节结论一样。很多人到这里就算完了然后买卡实际一跑直接爆显存。因为权重只是第一笔账后面还有两笔在等着。1.2 第二笔KV Cache是长上下文下最会偷显存的隐形住户先解释一下KV Cache是什么。Transformer模型在生成内容时是逐个token来的每生成一个新token都要和之前所有token做注意力计算。如果每个token都把历史重新算一遍计算量会随序列长度平方级增长。所以工程上会把每个已生成token对应的Key和Value缓存下来后续直接读取历史缓存这个缓存就是KV Cache。KV Cache占多大显存不直接取决于模型参数量而是取决于模型结构和上下文长度。常用公式KV Cache字节数 ≈ 2 × 层数 ×KV头数 / 总头数× 隐藏维度 × 上下文长度 × 每参数字节数对于传统的不带分组注意力的模型KV头数等于总头数括号里就是1。以一个标准7B结构为例32层、隐藏维度4096上下文长度4096时KV Cache约为2×32×4096×4096×2≈2.1GB。上下文开到8K就是4.2GB开到32K直接涨到16.8GB。这个增长速度是线性的但基数一大就很吓人。更麻烦的是KV Cache跟量化关系不大。模型权重可以做INT4量化压到3.5GB但KV Cache在绝大多数情况下还是按原始精度保存的。所以你经常会遇到这种情况模型量化得很小一张8G卡看起来绰绰有余上下文一拉长KV Cache照样把显存吃掉好几个G最后还是得换卡。现在很多新模型会用GQA分组查询注意力来压低KV Cache。比如70B级别的大模型通常KV头数只有总头数的八分之一同样的上下文长度KV Cache能缩减到原来的八分之一。如果你特别在意长上下文优先选带GQA结构的模型比单纯依赖量化更划算。1.3 第三笔激活值与运行时开销账单上不能忽略的杂项权重和KV Cache是两块显眼的大头但实际跑起来还有额外开销最典型的是中间激活值。模型前向计算时每一层的中间张量都要暂存在显存里推理时激活值相对小和batch size成正比训练时就惊人了反向传播需要保存前向中间结果这一部分可以数倍于权重。另外还有框架运行时开销比如CUDA context以及各类推理引擎自己的显存池。简单粗暴的估法推理场景给权重和KV Cache算完总和之后额外预留15%-20%给杂项训练场景按权重字节数乘以8起步做总量估算因为除了权重还得有梯度、优化器状态甚至主权重副本。这还没算中间激活值最终占用只会更高。2. 算清显存的核心公式一张表解决90%的选型问题2.1 精度档位决定权重的“每字节单价”动手算之前先给一张最常用的精度对照表。这张表看一眼就会后面所有计算都依赖它。精度档位每参数字节7B权重估算70B权重估算FP32428GB280GBFP16/BF16214GB140GBINT817GB70GBINT40.53.5GB35GB基本原则是推理任务能跑FP16先用FP16显存不够再量化。量化不是免费的INT8的质量损失一般可控INT4在数学计算、严谨问答这类任务上精度下降会很明显。如果只是做文本总结或闲聊INT4基本没问题要是做代码生成或需要准确推理的任务建议至少用INT8。2.2 KV Cache计算最容易记错的两个参数套KV Cache公式时最容易忽略的是GQA和MQA。MHA是每个注意力头都存完整的K和VGQA是几个查询头共享一组K和VMQA是所有查询头共享一组。GQA/MQA的KV Cache小很多所以不能拿一套固定参数套所有模型。再给一个便于口算的参考数字如果是32层、隐藏维度4096的标准7B结构且没有GQA每增加1K上下文KV Cache大约增加0.52GB。如果换成带GQA的72B模型每增加1K上下文通常增加不到0.2GB。这个数据能帮你在看显卡时快速判断“我能不能开长上下文”。2.3 训练和推理的倍数关系差在哪很多人以为显存计算跑一遍就完事了实际还要看你是推理还是训练。推理的目标是加载权重生成内容训练则要额外存储梯度、优化器状态和中间激活。拿FP16的7B模型举例。推理权重14GBKV Cache约2.1GB再加杂项总计约17-18GB一张24G卡跑起来很稳。训练就完全不一样了权重14GB之外梯度还要14GBAdam优化器里的动量和方差更是以FP32保存还有其他辅助状态。业内粗略估算混合精度全参数训练按每参数16字节左右准备是一个比较现实的下限7B对应的训练基础就是112GB量级激活还要另算。所以单卡24G要全参数训练7B不开梯度检查点、不把batch压到极低基本不可能通常做法是量化加LoRA这类参数高效微调把可训练参数量压到总参数的1%以内24G卡才有操作空间。看到这里你应该明白为什么游戏显卡和专业计算卡能差出好几倍价格。显存只是一个维度带宽、算力、多卡通信都影响最终体验但显存是最硬的约束——卡上装不下一切免谈。3. 实操写一个自己的显存估算计算器3.1 一个可直接运行的Python脚本理论讲完直接上干活用的工具。我平时选型前都会跑一下下面这个脚本把参数量、精度、结构参数填进去几秒钟就出一份显存估算报告。脚本没有依赖Python 3直接能跑。# -*- coding: utf-8 -*- def estimate_vram( params_b: float, # 模型参数量单位十亿如7、13、70 precision: str fp16, # fp32/fp16/bf16/int8/int4 context_len: int 4096, # 输入输出总长度单用户上下文 num_layers: int 32, hidden_size: int 4096, num_heads: int 32, kv_heads: int 32, # GQA时传实际KV头数MHA时等于num_heads mode: str inference, # inference / train ): bytes_map {fp32: 4, fp16: 2, bf16: 2, int8: 1, int4: 0.5} b bytes_map[precision] weights_gb params_b * b # KV Cache单位GB按1GB1024^3字节 # KV Cache通常按FP16保存所以这里的每参数字节数写死为2 kv_gb ( 2 * num_layers * hidden_size * (kv_heads / num_heads) * context_len * 2 / (1024**3) ) if mode inference: overhead_gb (weights_gb kv_gb) * 0.15 total weights_gb kv_gb overhead_gb print(f权重估算: {weights_gb:.1f} GB) print(fKV Cache估算: {kv_gb:.1f} GB) print(f杂项预留15%: {overhead_gb:.1f} GB) print(f推理估算总量: {total:.1f} GB) else: # 混合精度全参数训练权重梯度优化器状态主权重副本等按推理权重的8倍起 train_base_gb weights_gb * 8 activation_gb weights_gb * 0.5 # 极小batch、低序列长度情况下的粗估 total train_base_gb activation_gb kv_gb print(f训练基础(权重梯度优化器主副本): {train_base_gb:.1f} GB) print(fKV Cache估算: {kv_gb:.1f} GB) print(f激活粗估: {activation_gb:.1f} GB) print(f训练估算总量: {total:.1f} GB) if __name__ __main__: estimate_vram( params_b7, precisionfp16, context_len4096, num_layers32, hidden_size4096, num_heads32, kv_heads32, modeinference, )注意这个脚本做的是粗略估算用来在买卡、选模型、调上下文之前形成判断不能替代实际运行时的显存profiling。训练模式下激活值波动很大跟batch size、序列长度、是否用梯度检查点强相关脚本里给的是一个非常保守的经验系数。3.2 用脚本验算几个典型场景场景一7B模型FP16推理4K上下文。脚本输出约14GB权重加2.1GB KV再加杂项总量约18.5GB24G卡能跑16G卡紧巴巴容易爆。场景二同一个7B模型改成INT4量化上下文拉到32K。权重降到3.5GBKV Cache却涨到16.8GB加上杂项总量超过23GB。一张8G卡哪怕量化到极限也跑不了32K上下文。这个例子特别能说明问题量化解决的是权重问题解决不了上下文带来的KV膨胀。场景三70B级别模型INT4量化4K上下文使用GQA结构。假设80层、hidden size 8192、64个总头、8个KV头KV Cache是2×80×8192×(8/64)×4096×2/(1024^3)≈0.64GB权重35GB加上杂项总量约41GB。结论是单张48G专业卡可以比较稳地推理想塞进两张24G卡也可以但对显存均衡和通信带宽要求比较高。3.3 算完对不上实际占用里还有几个隐藏项估算数字和实际占用对不上最常见原因有三类。一是推理引擎自身有内存池有些框架默认预分配显存模型一加载就把显存占走一大块看起来比理论值高很多。二是PyTorch这类框架里模型加载后reserved显存和allocated显存是两个概念reserved高不代表真正用掉的allocated高。三是并发场景一个模型服务多个用户每个用户都有自己的KV Cache那就要按“上下文长度×并发数”重新计算KV部分。多用户并发这件事值得单独提醒。单用户4K上下文KV占2.1GB权重14GB一张24G卡看着很宽裕但如果同时有8个用户都在跑KV就变成16.8GB加上权重14GB总量超过30GB24G卡已经撑不住了。所以做在线服务型项目时选型公式要改成权重 平均上下文长度 × 并发数对应的KV总和 杂项。用脚本算的话把context_len乘以并发人数即可。4. 按显存选模型从8G到48G怎么配最划算4.1 8GB级别老老实实走量化路线这个量级的卡核心策略是“量化优先、上下文别贪”。7B模型只能跑INT4或INT8量化FP16的7B权重就要14GB装不下3B以下小模型可以用FP16。上下文建议控制在4K以内再高就轮到KV Cache反噬了。LoRA微调在这个量级也可以做但目标只能是低秩参数7B模型INT4量化加LoRA显存占用大概在6-7GB属于地板被踩得很紧的状态。启动训练前建议先跑一次小规模模拟确认不会中途爆显存。一句话总结8G卡是“能玩”的程度适合入门验证别指望跑高难度任务或大上下文。4.2 12-16GB级别主流性价比区间12GB级别是现在最主流的显卡容量之一。7B模型FP16推理约18.5GB在12G卡上装不下所以12G卡跑7B依然要量化INT8或INT4都可以14B模型在12G卡上可以跑INT4量化上下文控制在4-6K。16GB级别会舒服很多。7B模型FP16推理可以跑但上下文不能拉太长4K左右比较稳14B模型FP16依然紧张量化后可以跑到8K上下文。这个量级覆盖了大多数个人开发者日常任务代码辅助、本地知识库问答都能应付。4.3 24GB级别个人玩家的甜点位到了24GB玩法明显不一样了。7B模型FP16推理加8K上下文总共也就18GB左右运行非常宽裕。32B模型用INT4量化可以轻松跑INT8量化在控制上下文的情况下也能跑。训练方面24G卡是一张非常典型的LoRA训练入门卡。7B模型FP16加LoRA显存大概在14-16GB能比较舒服地做参数高效微调全参数微调就别想了112GB量级的基础需求摆在那里。如果你的主要方向是个人项目和模型调优24G卡目前的综合性价比确实不错二手市场也相对活跃。4.4 48GB级别与多卡方案大模型玩家的门槛到48GB这个级别基本是专业计算卡或旗舰工作站卡的领地。70B级别模型INT4量化推理大概40GB左右单卡48G刚好能装进去4K上下文比较稳妥想拉到8K-16K就紧张了得配合更激进的KV Cache优化手段。32B模型FP16或INT8在这个量级可以跑得从容长上下文也能开。多卡方案是另一条路。用两张24G卡跑70B量化模型需要把模型拆分到两张卡上同时注意通信带宽。如果只是普通PCIe带宽速度会明显下降更理想的是支持高带宽互联的版本。多卡的好处是KV Cache可以分散在不同卡上但工程复杂度比单卡高不少新手不建议第一套方案就上多卡。下面这张表可以收藏起来对照显存档位推理推荐配置训练推荐配置8GB7B INT43B以下FP16上下文≤4K7B INT4 LoRA12GB7B INT8/INT414B INT47B LoRA14B INT4 LoRA16GB7B FP164K14B INT4/INT87B LoRA 舒服14B LoRA 紧24GB7B FP16长上下文32B INT47B LoRA小规模全参实验48GB70B级INT432B FP16/INT870B LoRA32B小batch全参5. 常见误区与排查实录5.1 误区一只算权重忘了上下文这个变量我见过最多次的问题就是“我有16G显存跑7B模型为什么爆了”一查权重14GB理论确实够可对方把上下文调到了16K。用前面的公式一算KV Cache差不多要8.4GB加一起22GB出头16G卡不爆才怪。排查方法很简单把上下文长度调到最低比如512如果显存占用明显下降说明瓶颈在KV Cache如果没怎么变再检查权重精度和框架开销。这个二分法可以快速定位爆显存的真正原因。5.2 误区二量化之后直接按参数×0.5算显存很多人看到INT4量化后7B模型只有3.5GB就觉得随便一张卡都能跑。实际上除了权重KV Cache、中间激活、框架运行时一分不少。更极端的情况如果上下文拉得很长KV Cache反而超过权重成为主要开销。而且不是所有量化实现都那么“纯净”。有些量化格式除了权重本身还要加载额外的高精度通道参数比如按组的缩放因子和零点这部分也会占显存。所以量化后的实际权重占用通常比理论值略高脚本里只按理论值算最终选型时心里要再加一点余量。5.3 误区三显存够用就等于跑得快显存只是“装得下”的约束装得下之后还要看“跑得快不快”。推理时每生成一个token都要访问全部权重这是典型的显存带宽敏感场景一张低端大显存卡在生成速度上可能反而不如小显存但高带宽的卡。专业计算卡贵一部分就贵在显存带宽和算力上。判断方法很简单同一模型同一量化精度跑一轮生成看每秒生成多少token。目标是聊天交互20 token/s以上体感还行目标是批量处理大量文本吞吐比单次延迟重要得多。选型之前真的建议先拿一张能装的卡实测一遍参数够用和体验好是两件事。5.4 实用排查三板斧与工具排查显存问题我常用三板斧第一板斧跑nvidia-smi看实时显存占用和进程列表第二板斧把上下文调到最低对比显存变化区分权重瓶颈与KV瓶颈第三板斧换一种精度或量化方式对比确认是不是权重太大。这三招能解决八成问题。进阶一点在PyTorch里用torch.cuda.memory_allocated和torch.cuda.memory_reserved分别观察已分配与预分配显存。如果两者差距很大说明框架预留了缓冲池不一定是模型真的大到跑不动。再不行就开显存profiling一帧一帧看峰值出现在哪个算子。很多时候峰值和平均值是两个概念只盯着一个数字容易误判。6. 最后分享几条选型心得写了这么多最后说几条实操中沉淀下来的个人经验不一定全面但都是被现实毒打过之后才记住的。第一任何估算都留10%-20%余量。我见过太多理论刚好够、实际一跑就爆的例子原因不外乎框架开销、显存碎片化、峰值和平均值差异。与其卡着上限配不如往上跳一档省下来的是时间。第二选模型前先查结构不只看参数量。同样叫70B有没有GQA、层数和隐藏维度是多少KV Cache可以差出好几倍。参数大小相同长上下文表现可能完全不同。第三能动手测就不要只动脑估。本地起一个最小复现把量化精度和上下文参数试一遍看真实占用和速度比任何公式都靠谱。公式帮你排除明显不行的方案实测帮你确定最终方案。显存计算这件事知道公式只是入门关键是把“权重、KV Cache、运行时杂项”三本账分开记。以后有人再问“你的显卡能跑多大的模型”你可以反问他打算用什么精度上下文打算开多长跑推理还是跑训练这几个问题一问答案自己就出来了。