显卡能跑多大模型？显存估算公式与量化选型实操指南

显卡能跑多大的模型这个问题我几乎每天都能在交流群里看到。有人刚入坑就买了张8GB显存的游戏卡兴冲冲下了个号称“性能炸裂”的34B模型结果一加载就OOM直接死机重启也有人手头明明是24GB的专业卡却只敢开7B小模型纯粹浪费算力。说到底很多人不是缺显存而是缺一套“显存怎么算”的方法。这篇文章就把这块讲透显存到底被哪些东西吃掉了、怎么在选模型之前用公式估算占用量、FP16和INT4这些精度到底差多少、不同显存档位适合跑多大的模型以及我自己实测中踩过的坑。不搞玄学全是能直接套用的计算方法和参考结论。2. 显存被谁吃掉了不是只有模型权重这一项很多人以为显存占用就等于模型文件大小这其实是最大的误解。模型权重确实是大头但远不是全部。实际推理时显存里住着好几拨“住户”它们分工不同、占用方式也不同少算任何一拨都可能让你的卡直接爆显存。2.1 模型权重最大但不代表全部权重就是模型里那些可训练的参数它是显存里最直观、最好算的一块。但注意我见过不少新手对着网盘里下载的模型文件大小来估算显存这是完全错误的参照系。模型文件的存储格式可能经过压缩或者分片加载进显存的体积跟文件大小不是一回事。真正准确的算法是参数量 × 每个参数占用的字节数。这里每个参数占多少字节取决于你用什么精度来加载模型后面我会单独讲精度这里先记住这个公式就行。一个70B的模型用最常见的2字节精度加载光权重就是140GB普通显卡根本想都不要想。所以选模型的第一件事永远是先看参数量和精度而不是看下载文件有多少GB。2.2 KV Cache那句“上下文越长越吃显存”的真正原因KV Cache这个东西很多教程一句话带过但它恰恰是跑长文本时最容易把显存吃爆的“隐形大户”。简单说模型每处理一个token都要把之前所有已经处理过的信息保存下来形成“缓存”下次生成新token时要拿这个缓存去和当前内容做计算。你让它处理的文本越长、对话轮数越多这个缓存就越大。举个直觉化的例子你和模型聊天它要在脑子里把前面你说过的每句话都“记”住才能接得上。这个“记”不是抽象的是真的要占存储空间。一段2048个token的对话跟一段8192个token的对话KV Cache能差出好几GB。很多人在短文本测试时发现显卡还能跑一上长文档就OOM十有八九就是栽在KV Cache上。KV Cache的计算公式大概是2 × 层数 × KV投影维度 × 序列长度 × 精度字节数。其中层数和KV投影维度是模型结构决定的你改不了但序列长度是你能控制的。所以“减少上下文长度”是跑不动大模型时最立竿见影的操作。2.3 激活值与框架开销那几百MB到1GB的“神秘占用”除了权重和KV Cache显卡加载模型后还会多占几百MB到1GB左右的空间主要三块一是CUDA上下文这是运行环境初始化时固定占用的大概300MB到600MB不管跑多小的模型都得掏二是推理框架的临时缓冲区负责存放计算过程中的中间结果也就是激活值批量处理或者输入变长时它会跟着涨三是各种内存池和碎片。这些开销平时不起眼但当你把显存算到“刚好够”的时候它们就是压垮骆驼的最后一根稻草。3. 三步估算显存拿计算器按出来的结论最靠谱搞清楚了显存里住了谁接下来就能动手算。我给很多朋友演示过这套方法基本上用计算器五分钟就能得出结论准确率足以支撑选型决策。算之前先问自己三个问题你打算跑的模型参数量是多少你打算用什么精度加载你日常最长会用多长的上下文3.1 第一步权重体积 参数量 × 精度字节数这是最核心的公式。参数量以“B”为单位也就是十亿参数。精度字节数看下表精度类型每参数字节数7B模型权重体积34B模型权重体积70B模型权重体积FP324字节28GB136GB280GBFP16/BF162字节14GB68GB140GBINT81字节7GB34GB70GBINT40.5字节3.5GB17GB35GB实际接触量化模型时你会发现有些做了INT4量化的模型权重体积比我表格里算的略小一点因为量化多少会砍掉一些冗余结构但大体上按这个表估就行误差不超过10%。我用这个公式给朋友做选型参考比对着网盘文件大小猜靠谱得多因为网盘里的文件往往还带了分词器、配置文件这些附带内容容易让人高估显存需求。3.2 第二步KV Cache按上下文长度补一笔接着算KV Cache。这里我告诉你一个更省事的经验值拿你选定的精度估算大约每处理1000个token需要多少缓存空间。实操中一个主流的7B模型在FP16精度下KV Cache大约是每1000个token吃掉60MB到130MB如果模型用的注意力头数很多且没有做分组查询优化这个数字会翻几倍。为了保险我通常就按“FP16下每1K token约占0.1GB到0.3GB”来粗估INT8/INT4精度对应减半甚至更低。举个例子一个7B模型INT4量化加载权重3.5GB上下文4096个tokenKV Cache按0.2GB每1K粗略算就是0.8GB加上0.5GB左右的框架开销总占用约4.8GB。8GB的显卡完全能跑甚至还能留出一部分余量。但如果换FP16加载同一个模型权重就变成14GB直接劝退。3.3 第三步留出20%的安全边际算完前两项我强烈建议你把总数再乘上1.2当作风控线。原因很简单你在测试时用的上下文长度跟实际使用时不一定一致CUDA上下文、激活值这些开销在不同框架下的差异也很大就算你算出来正好16GB消费级显卡实际可用显存往往比标称少几百MB系统、显示都要占用一部分。一旦真到了满负载边缘轻则推理速度骤降重则直接崩。所以我的原则永远是“宁买大不买小”算出来16GB要跑就直接奔24GB的卡去这多出来的8GB能让你在调参和长文本上获得巨大的呼吸空间。4. 精度与量化同样的模型不同“饭量”精度这个东西很像是照片的分辨率和压缩格式——原始高清大图最占空间压缩成JPG后体积小了很多肉眼看差别不大但放大到极限时细节确实有损失。模型的FP32、FP16、INT8、INT4就是类似的逻辑。4.1 FP16与BF16为什么是主流“全精度”选择现在推理和微调的默认精度基本都是FP16或者BF16也就是每参数2字节。FP32每参数4字节存储和计算都更大但实际推理收益微乎其微现在已经很少有人在推理阶段用它了。BF16是FP16的“变体”它牺牲了一些小数精度换取了更大的数值范围在训练中大模型经常用它防止梯度溢出。推理阶段你只要知道这俩都按2字节算就行。4.2 INT8与INT4量化牺牲多少换显存INT8每参数1字节INT4每参数0.5字节。量化说白了就是把模型原本高精度的权重“四舍五入”到更粗糙的整数表示。它对显存的削减是肉眼可见的一个34B模型FP16需要68GBINT8直接砍半到34GBINT4更是降到17GB。这让原本只有24GB显存的卡也能摸到34B模型的边。但代价也不是没有。量化后的模型做简单问答、代码补全你基本感觉不到差别可一旦进入需要精确计算、数值推理、长文本逻辑强相关的任务量化模型可能就会出现逻辑跳跃、数字算错这类问题。我实测过一个场景同一个数学推理题FP16模型算对INT4量化后答案就错了改回FP16又对了。这种情况在越小规模的模型上越明显因为小模型本身的“能力余量”就少再一压缩就露馅。所以我对量化的态度是7B这种小模型能用INT8尽量不用INT434B以上的模型为了塞进消费级显卡用INT4也是权宜之计但别指望它在硬核任务上跟原版一模一样。4.3 量化选型的实操建议这里有一套我总结的选型顺序按你的显存和任务来如果显存非常紧张8GB到12GB目标只是让它“能跑起来”那就选INT4量化模型优先保证可用性任务难度别太高。如果显存相对充裕16GB到24GB优先选INT8量化平衡体积和效果实在不行再上INT4但任务上回避强计算类场景。如果显存特别充裕48GB以上直接FP16跑原版别折腾量化。你花大价钱买大显存不就是为了不妥协吗。5. 按显存选模型四个档位的参考配置表有了前面的公式我现在直接给你整理一份“抄作业”级别的配置参考。注意这是综合了权重、常见上下文长度和运行开销后的经验值你实际使用时按自己的上下文长度微调。5.1 8GB到12GB入门档但也能玩这个档位是普通消费级游戏卡的主战场也是问得最多的。先说结论FP16的7B模型权重14GB在8GB卡上没戏在12GB卡上也很悬因为加上KV Cache和开销已经逼近上限。但换成INT4量化7B模型的权重只有3.5GB加上缓存和开销也能控制在6GB到8GB以内8GB卡能跑12GB卡则比较从容。34B这种级别在12GB卡上就基本告别了INT4也有17GB权重硬塞进去只能靠极短上下文和极端量化体验极差。这个档位上的实操建议是7B INT4是甜点位首选支持长上下文的量化版本把上下文控制在4096以内别逞强开8192推理框架里开启显存优化选项后面会讲。预算能提到12GB的话还能试试更大的13B INT4模型权重约6.5GB加上开销勉强能挤进12GB但余量确实不多。5.2 16GB到24GB中坚力量玩34B的门槛到了16GB和24GB这个档位选择面一下就宽了。24GB显存跑FP16的13B模型毫无压力权重26GB不对13B FP16是26GB超了——这里我得修正一下13B FP16权重26GB24GB卡其实跑不了FP16原版得用INT8量化13GB权重才能塞进去。更稳妥的方案是13B INT8约13GB权重加中等上下文整体能控制在19GB上下24GB卡跑得很舒服。34B模型在这个档位就必须依赖INT4了17GB权重加KV Cache和开销基本就是贴着24GB上限走属于“能跑但没多少余量”的状态适合短对话、代码生成这类场景。16GB这个档位比较尴尬它比12GB宽裕不少但离24GB又差一截。我的建议是用13B INT8或者干脆用7B模型的FP16版后者也有14GB权重加上开销正好卡在16GB边缘跑短上下文问题不大长上下文就有风险了。别在16GB卡上强行上34B INT417GB权重连加载都过不去。5.3 32GB以上大模型自由区到了32GB甚至48GB你已经跨进了另一个世界。单张48GB能直接FP16跑34B模型68GB不行FP16 34B是68GB48GB也装不下。让我重新算一下34B模型FP16是68GB需要两块48GBINT8是34GB单张48GB能跑但余量一般INT4是17GB单张48GB非常宽松。70B模型FP16要140GB单张48GB不行INT8要70GB也不行INT4大约35GB加上KV Cache和开销48GB单卡可以跑短上下文32GB则比较危险。这个档位的实操建议是优先考虑INT8的34B模型这是性价比最高的组合如果需求是70B INT4那就直接考虑多卡方案或更高显存的规格。多卡跑模型不是简单的显存相加还涉及并行策略、通信带宽和框架支持复杂度比单卡高一个量级这是另一篇文章的话题了。6. 实操估算工具、实测监控与优化技巧公式和表格都给了但纸上算完还得落地验证。我讲讲实际跑起来时的工具和监控方法以及几个能帮你把显存榨出更多余量的框架级优化手段。6.1 用现成的工具快速估算不想手算也可以直接用开源社区提供的显存估算脚本原理就是我前面说的公式输入模型参数量、精度、上下文长度它能给出一个理论占用值。我自己的习惯是先用这种工具粗筛一批候选模型再用下面的实测方法验证。粗筛的意义是快速排除明显不可能的选项避免把时间浪费在下载一个根本跑不动的模型上。很多朋友上来就下大模型下了两天发现显存不够这种时间成本完全可以靠一个估算脚本规避。6.2 实测显存占用看清每一GB去哪了模型真正跑起来之后一定要开显存监控。最简单的方式是开系统自带的任务管理器切到GPU那一栏看专用显存占用更精确的做法是用命令行查看显存使用情况。但有个细节你需要注意监控看到的占用往往比理论值高。因为推理框架启动时会把CUDA上下文、算子缓存、内存池一次性垒起来这些跟模型大小无关的固定开销在监控里都算在“专用GPU内存”里了。所以实测的用途不是验证理论值而是确认一个关键问题实际运行有没有触发内存交换或者有没有接近OOM边缘。如果你发现显存占用在生成过程中持续上涨而不是稳定在某个值附近那大概率是KV Cache在累积这时候就该检查上下文长度设置或者换更短的输入。6.3 三个立竿见影的显存优化手段第一个是限制上下文长度。我之前反复强调KV Cache跟上下文长度成正比所以把你的最大上下文限制在实际需要的范围内是最简单也是最有效的省显存手段。很多人喜欢把上限拉到最大以为“总比不够好”结果就是显存白白被缓存吃掉还拖慢速度。第二个是开启推理框架自带的显存优化选项。不同的推理框架有不同的优化开关有的能动态分配KV Cache有的能实现按需加载、减少预分配这些选项通常默认关闭或者需要手动配置。我在实践中发现对于小显存设备开这些选项前后显存占用能差出10%到15%。这个概念很接近手机上“后台限制”的思路——不提前把内存全占上用多少给多少压力自然小很多。第三个是分批处理而不是一次喂太多。如果你想做批量推理把一批大输入拆成几个小批次依次处理峰值显存会明显下降。批量推理的本质是用时间换空间速度会慢但至少能跑。真到了非跑大模型不可、又只有小显存的绝境这招往往能救急。7. 常见问题与排查技巧实录这部分全是实操中反复出现的问题每条都是我或者身边的同好真实踩过的坑整理成速查表供你对号入座。7.1 加载就报OOM或“显存不足”这是最典型的翻车现场。原因就三种一是权重本身就超出显存总量这个最无解换小模型或降精度二是上下文长度配置太高KV Cache在加载阶段就撑爆了显存把上下文调低就好三是系统其他程序占用了大量显存尤其是开着浏览器多标签页、视频播放或者其他占用显存的软件先把它们关了再跑模型。这里有个必须养成的习惯跑模型前先看一眼显存被谁占着。很多人的机器上有其他进程在悄悄吃显存模型还没开始加载就已经少了几百MB可用空间。这跟手机清理后台是一个道理看起来是小事但在显存卡得很死的模型上这几百MB就是分界线。7.2 能加载但生成到一半就崩这种比直接加载失败更折磨人因为问题往往出在KV Cache的动态增长上。你测试时用的短提示词没事真用起来上下文越积越长缓存不断膨胀最终在生成中途触顶OOM。排查方法是看崩溃发生的位置和当时的输入长度如果每次都发生在长上下文场景就把最大上下文长度下调一档或者在对话过长时主动清空部分历史记录。还有一个容易被忽略的诱因生成长度设置得过高。模型逐字生成时每生成一个token都在扩大KV Cache如果你设置了超长的生成长度它就一直涨一直涨直到崩溃。我的建议是生成长度按实际需求来设不是越长越好。7.3 为什么“能跑”和“跑得流畅”是两码事有人看到自己的显卡勉强加载了大模型很开心结果一用发现每秒只能蹦几个字基本没法交互。这是因为显存勉强够时计算库可能动用了更慢的路径比如显存碎片化导致的换入换出或者精度选择导致计算效率下降。这种“能跑”在我看来其实等于“不能跑”只能算“加载成功”而已。判断一个模型在你的卡上是否真正可用我给自己定的及格线是日常对话场景下生成速度能到每秒10个token以上且连续跑10分钟不崩、不抖动。低于这个水平体验是真的痛苦慢慢打字比你等它都快人会崩溃的。愿意接受这个慢速的话也行但请提前管理好自己的预期。7.4 新手容易踩的两个隐性坑第一个是把“下载的模型文件有多大”当作“加载占多少显存”。文件可能是分片压缩打包的里面有额外的配置和分词器文件跟实际显存占用完全不挂钩。第二个是不区分模型参数量和模型量化等级笼统地说“我跑了7B”但实际上7B的INT4和7B的FP16在显存需求上差了4倍没有任何可比性。跟人交流或者自己规划时一定要把“参数量精度上下文”三要素说全否则一切估算都是空的。8. 一点个人体会这套显存计算方法我用了很久最深的体会是选模型这件事不是“我的显卡能跑多大”而是“我的显卡配上我能接受的精度和上下文能跑多大”。很多人一上来就追大参数模型仿佛参数量小了就低人一等结果卡在OOM边缘反复折腾时间成本远比显存成本高。我自己也是从8GB时代一路过来的踩过爆显存的坑也试过为了塞大模型把量化拉到极限然后看着它答错数学题的尴尬。现在我的原则很简单富余永远比极限更重要——显存多留20%省下的是无数调试头发和等待时间。全文最想让你记住的其实就一句话先算再下后跑。别让你的显卡替你交学费。