1. 一切显存焦虑的根源模型参数怎么换算成字节很多朋友第一次接触本地推理时都有过类似的经历看到一个能力不错的开源模型兴奋地下载启动之后推理框架报了个错大意是显存不足无法分配XX MB空间。然后就开始怀疑是不是驱动有问题或者框架装坏了。其实绝大多数情况没那么玄就是显存不够而你本可以在下载之前就算清楚。显存和模型之间的换算关系本质上是一道乘法题。模型在显存里存储的最小单位是参数而每个参数占几个字节取决于你用什么精度去存它。最常见的精度是FP16半精度浮点每个参数占2个字节。于是一个参数总量700亿的模型——也就是我们常说的7B模型——光是把权重塞进显存就需要7 × 10^9 × 2 字节 140亿字节 ≈ 14 GB这就是为什么很多人第一次看到7B模型需要14GB显存这类说法时会疑惑模型压缩包下载下来才十几GB怎么运行还要更多因为下载的是量化后的压缩权重运行时还要加上推理过程的中间开销。你如果拿着一个8GB显存的显卡想全精度跑7B模型从数学上就不成立跟你用什么框架、调什么参数都没关系。这句乘法公式值得刻进脑子里权重显存 ≈ 模型参数量 × 每个参数的字节数网上到处流传的XX模型需要XX GB表格基本都是这个公式的产物。只要你记住参数量再记住精度对应的字节数任何模型你都能自己在心里估算一个大概。等到后面我们把KV Cache、激活值这些额外开销加进来也只是在这条主干公式上做加法核心逻辑不会变。值得一提的是很多人会把模型文件大小和运行所需显存画等号。模型文件在硬盘上是压缩存储的而运行时解压到显存里往往需要更大空间。模型文件显示8GB不代表8GB显存就能跑——这一点在后面避坑部分我会展开细说。2. 量化精度才是下决定的主开关2.1 从FP32到INT4每个格式各吃掉多少显存既然权重显存和每个参数的字节数直接挂钩那这个字节数到底有哪些常见取值就得先盘清楚。表格 1常见精度格式与对应字节数精度格式每个参数占用7B模型权重大致占用说明FP324字节约28 GB精度最高几乎没人直接用来推理FP16 / BF162字节约14 GB训练和推理最常用的基准精度INT81字节约7 GB精度损失较小显存压力减半INT40.5字节约3.5 GB显存占用极低但精度损失需要权衡注意INT4那一行的0.5字节是理论均值。实际量化存储往往还要加一些额外的缩放因子和零偏移量所以INT4量化后的真实占用通常比参数量×0.5字节略高一些。比如7B模型用INT4量化后常见文件大小在3.8GB到4.2GB之间不是严格等于3.5GB。这个误差在估算时可以接受因为它不影响我们判断到底够不够用。FP16和BF16虽然都占2字节但内部表示方式不同。FP16是常规半精度浮点范围有限BF16牺牲了尾数精度换取更大的表示范围在训练场景更稳。对推理显存估算来说两者可以当成同一档处理。2.2 量化不是白给的精度与容忍度有经验的朋友看到我上面这表格肯定会说那直接用INT4不是什么都解决了吗为什么还要纠结FP16还是INT8因为量化是在压缩精度和节省空间之间做交易而且这笔交易不是完全等价的。量化相当于把一张照片从无损RAW格式压成高质量JPEG。JPEG看起来几乎一样但如果你放大到200%、逐像素去看细节就是丢了。语言模型同理INT4推理时的输出在大多数日常任务上和FP16差距不大但在需要精确计算、代码逻辑严谨、长文本理解这类任务上你可能会明显感觉到这个模型怎么变笨了。有些模型原始能力很强一量化之后反而表现不如小一号但更高精度的模型这种情况并不少见。所以模型选择永远是两条线并行一条线看精度档位一条线看参数量。量化后8GB显存能跑的7B模型和FP16下需要14GB才能跑的7B模型本质上是两个不同档次的模型。如果你有14GB显存你是选择跑一个7B的高精度版本还是跑一个13B的INT8版本没有标准答案取决于你更看重智商上限还是响应速度。这句更高精度的更小模型和更低精度的更大模型之间的取舍是本地推理玩家每天都在做的选择题。2.3 怎么用量化位宽推算实际文件大小我们平时从网上下到的模型文件很多已经标注了量化版本。比如你会在文件名里看到类似7B_q4_K_M、7B_q8_0这样的后缀。q4就是INT4量化q8就是INT8量化。文件名里的这些信息可以直接拿来估算显存需求。以7B模型为例最常用的几个量化版本的权重占用如下表格 27B模型不同量化版本的权重资源和显存区间量化标识含义权重文件约推理时建议显存q8_08bit量化约7 GB10 GB以上q6_K6bit量化约5.5 GB8 GB以上q4_K_M4bit量化中高精度方案约4.1 GB6 GB以上q2_K2bit量化约2.9 GB5 GB以上我的习惯是下载前先拿参数量×0.6粗略估计INT4占用再用参数量×0.5粗略估计INT4占用再留出20%到30%的余量给后续要讲的KV Cache和激活值。比如7B模型选q4_K_M权重大约4GB乘上1.3的余量系数大约需要5.5GB到6GB显存。如果你的卡是8GB那大概率可以跑得动如果是6GB就得谨慎点或者把上下文长度调短。千万别只看文件大小就决定下载。文件压缩是实打实的占用量而不是运行所需量下载下来能跑也得能运行文件大小只是参考线。3. 你以为算完权重就够了激活值和KV Cache才是隐形成本3.1 为什么推理阶段峰值显存会突然跳一截按上面的方法算出权重显存后很多人第一次实际跑起来时会发现显存占用比预计的高出不少。这不是估算公式错了而是推理阶段的显存需求从来不是只装权重那么干净。你可以把显存想象成一间厨房。模型权重是冰箱里各种食材KV Cache是你在做菜过程中产生的半成品和临时容器激活值则是你正在切的菜、正在调的味道。食材总量决定了你要买多大冰箱但真正开火做饭时台面上还堆着一堆东西厨房太窄照样转不开身。推理时显存的峰值恰恰是所有这些东西同时存在的瞬间。先说激活值。模型每生成一个token都要在每一层做一次前向计算中间结果就是激活值。激活值的大小跟批次大小batch size、序列长度强相关。你如果一次只生成一个tokenbatch1激活值通常不大但在长序列场景下依然会累积成可观的开销。真正的大头往往在KV Cache。为了不让模型在生成每一个新token时重新计算之前所有token的注意力推理框架会把历史token的Key和Value缓存起来。这个缓存随着对话变长而线性增长长对话跑到后期KV Cache轻松超过2GB到3GB。这就是同一个模型为什么短对话能跑长对话突然就OOMOut Of Memory显存耗尽的原因。3.2 KV Cache的精确公式与实例演算KV Cache的占用可以写成下面这个公式KV Cache大小 2 × 层数 × 隐藏层维度 × 序列长度 × 精度字节数 × 批次大小公式中的2是Key和Value两份层数和隐藏层维度都是模型架构里写死的超参数。问题来了这些参数我从哪儿查其实都挂在模型配置里你打开模型描述页或者配置文件就能找到num_hidden_layers和hidden_size这两个字段。拿一个代表性架构举例假设某7B模型有32层隐藏层维度4096用FP16推理上下文长度设为2048批次大小设为1。代入公式2 × 32 × 4096 × 2048 × 2 字节 × 1 10.7亿字节 ≈ 1 GB也就是说这个模型在2048上下文长度下KV Cache就要吃掉1GB显存。如果把上下文拉长到8192KV Cache就是4GB直接相当于又塞进来一个INT4量化版的7B模型权重。这么一算你就明白为什么长上下文是显存最大的软性变量。不同的模型架构KV Cache差异极大。有的模型使用了分组查询注意力GQA多个头共享KV缓存显著缩小有的老架构用多头注意力缓存就大不少。所以别拿着别人博客里算好的KV数字硬套最靠谱的做法是在配置里找到自己模型的层数和隐藏维度现场算一遍。3.3 核心公式之外的边角余量除了权重、激活值、KV Cache这三驾马车实际运行起来还有一堆边角开销单独看不大凑在一起就是几个百分点到十几个百分点推理框架自身的CUDA上下文几百MB起步跟模型大小无关对话模板、tokenizer词表通常几十MB到几百MB采样参数相关的临时缓冲区量级不大但确实存在显存碎片如果断断续续跑了很久显存碎片会让可用空间低于理论值。所以我综合下来给一个经验公式一个模型跑得动总显存最好满足以下条件总显存 ≥ 权重显存 KV Cache预估 0.5 GB框架开销如果你卡在临界线上比如剩余空间比这个数少200MB我也建议别赌它跑得动后续一旦出现OOM整个对话进程直接崩溃体验比宁可量化高一档差得多。4. 主流显存档位能跑多大模型几张表把边界划清楚4.1 8GB档能玩但必须精打细算8GB显存是近些年入门卡的基准线也是最容易让人抱有不切实际期待的档位。经过上面的公式现在你可以自己判断了7B模型用INT4量化权重约4GB加上1GB到2GB的KV Cache和0.5GB框架开销刚好能在8GB边缘跑起来——前提是上下文窗口别太长。这个档位我实际体验下来最顺手的组合是目标建议配置建议上下文上限日常问答7B模型INT4量化4096以内编程辅助7B模型INT8量化2048以内中文场景3B到4B模型INT8量化8192以内8GB有个很尴尬的点它跑7B的INT4版本感觉性能被量化打折跑更高精度的7B显存又不够跑3B小模型倒是绰绰有余但很多任务上能力不够。我的建议是接受现实把8GB当作轻度玩家入门档优先选量化得当的中小模型不要挑战那些宣传满血性能的大家伙。4.2 12GB档最拥挤但最实用的区间12GB是另一个热门档位。按理说它比8GB多了一半但实际体验提升比一半大得多因为7B模型的INT8量化约7GB权重加上KV Cache后12GB能比较从容地跑。12GB档位值得推荐的方案目标建议配置建议上下文上限高质量对话7B模型INT8或INT4高规格量化8192左右代码生成7B到8B模型INT4量化4096到8192轻量微调测试3B模型FP16LoRA低秩适应409612GB最舒服的地方在于你可以在量化程度和上下文长度之间做灵活调节。跑INT8的7B模型时把上下文压缩到2048能应付大多数短任务遇到长文档需求切换成INT4版本把节省出的显存留给KV Cache。这种切换只需要在启动参数里改两行非常方便。4.3 16GB档本地推理的甜点区到了16GB日子就好过多了。这个显存容量能跑7B模型的FP16全精度版本约14GB权重上下文还能留出一定余量。对于追求输出稳定性、又不想忍受量化损失的朋友16GB是门槛最低的全精度入场券。16GB档位我体验下来的最佳实践目标建议配置建议上下文上限全精度对话7B模型FP164096到8192大型任务13B模型INT4量化8192多任务并行两个7B INT4量化模型同时驻留各自4096这里有个隐藏福利16GB显存能容纳两个INT4量化的小体量模型同时驻留显存切换模型时不用重新加载流畅度提升非常明显。很多人觉得我要跑大模型才需要大显存其实多模型并行才是16GB区别于12GB的重大优势。4.4 24GB及以上天花板在哪里24GB这个数字在本地推理圈子里几乎成了准专业的代名词。它能做什么13B到14B模型的FP16全精度勉强能塞进去或者让7B模型跑FP16的同时给出极长的上下文窗口。再往上48GB或更大显存就到了可以碰70B级别模型的级别——当然通常得用INT4量化而且KV Cache策略要非常讲究。表格 6主流24GB及以上档位的模型匹配思路显存7B模型13B规模模型30B以上规模模型24GBFP16全精度长上下文INT4量化中等上下文不推荐48GB任意精度超长上下文FP16全精度INT4量化短上下文80GB以上任意精度任意上下文FP16全精度长上下文INT4量化中等上下文每次看到有人在能不能跑XX模型的问题下争论不休我都会建议先把显卡型号、显存大小、目标模型的参数量、目标量化格式这四样列出来套一遍上面的公式。答案往往自己就浮出水面了。带不带得动本质上是数学跑得好不好才是调优。5. 显存不够又不肯换卡时的四项急救措施5.1 调整量化等级砍精度换空间显存不够的第一反应应该是能不能换个更低精度的模型文件。从FP16换成INT8显存需求直接对半砍从INT8换成INT4又砍一半。这是一条立竿见影且成本最低的路。但要注意两个细节。第一量化等级越低输出质量波动越大尤其在你没有仔细调提示词的时候模型很容易显得答非所问。第二不同的量化方案质量差异很大同样是4bit有的方案比另外的方案的生成质量高一个档次。我建议优先挑选口碑好的量化方案而不是纯看数字大小。必要时可以同一模型下载两个不同量化版本实际跑几天日常任务再决定留下哪一个。5.2 裁剪对话长度KV Cache是最大的软性变量KV Cache随上下文线性增长这意味着对话长度是你手中最灵活的调节杆。跑一个7B模型的INT8版本上下文从8192压到2048KV Cache能省下1.5GB到2GB。这个空间拿去提升模型精度或者同时驻留另一个小模型都更划算。实操上我一般会设置一个轮换窗口只保留最近几轮对话参与注意力计算更早的内容会被系统自动丢弃或压缩。很多框架里都有类似保留最近N轮的参数适当地调整它能换来一个几乎白得的显存缓冲。代价是模型会忘记早先聊过的内容如果你需要它记住关键信息得靠提示词里重复强调。5.3 开启逐层卸载用速度换显存所谓逐层卸载简单说就是显存不够就把一部分模型层暂时挪到内存里需要计算时才搬回显存。这个方案能让8GB显存的人跑本来需要12GB的模型代价是速度骤降——每生成一个token都要在内存和显存之间搬运数据速度可能从每秒几十个token掉到每秒两三个。该不该用这条策略得看你愿不愿意等。我自己的经验是适合聊天场景不适合代码补全这类需要即时反馈的任务。聊天时等几秒还能接受写代码时等十几秒才蹦出一个token耐心基本就耗尽了。5.4 关闭无关功能给推理进程腾地方把自己电脑上其他吃显存的功能全关掉。听起来像废话但我见过太多人在跑模型的时候后台挂着好几个渲染程序甚至开着多个浏览器页面显存被占掉一两GB然后说这个模型跑不动。一个干净的运行环境比任何调参都实在。另外系统里如果有其他正在加载模型的服务或后台进程也一并停掉。哪怕它们只占了几百MB也可能成为压垮临界配置的最后一根稻草。每次都先把显存占用情况看一眼再决定跑什么模型是最稳妥的习惯。6. 我踩过的显存估算坑6.1 只看参数量忽略了架构差异当年我第一次估模型显存时以为同样参数的模型显存需求就一样。结果实际跑了两个不同架构的同规模模型一个能轻松跑长上下文另一个跑到一半就OOM。原因就在KV Cache的架构差异上有的模型用共享KV机制缓存小有的模型每个注意力头都独立缓存KV开销几乎翻倍。所以现在的我在看模型时一定先看配置文件里的层数、隐藏维度、注意力头结构再决定怎么算。参数相同的模型显存需求上下浮动20%都很正常这个误差在8GB档位足以决定模型的生死。6.2 只算模型文件大小没有算上KV缓存那次失败经历让我长记性下载了一个模型文件大小7GB我的显卡12GB显存心想肯定能装下。结果启动后运行到几百token就崩了一查显存记录峰值飙到了11GB。7GB权重只是开始KV Cache加激活值直接把剩余空间吃干抹净。这件事之后我再也没偷过懒每次都老老实实把权重、KV Cache、框架开销三部分加起来再下结论。只要养成这个习惯绝大多数跑着跑着爆显存的问题都能在启动前被拦截掉。6.3 被8K上下文的宣传迷住模型页面上写着支持8192上下文我就真按8192去配显存然后翻车了。支持和能跑是两回事。支持8192上下文意味着它在技术上能处理那么长但你的显卡得有那么多额外空间存放对应的KV Cache。对于12GB显存卡想在FP16下跑7B模型并开满8192上下文几乎是不可行的。要我说宣传里的最大上下文就是个上限值不是推荐值。日常使用建议按实际需求的1.5倍到2倍预留。对话场景用2048或4096就很够只有处理长文档时才值得把上下文拉高并且拉高之前先确认显存余量。最后分享一个实用的排查顺序先用参数量×精度字节数算权重再用2×层数×隐藏维度×序列长度×精度字节数算KV Cache最后加0.5GB框架开销把这个数和显卡显存对比。大前提确认了再讨论量化和框架调优。这套流程我用了很久翻车率极低。如果你预算有限又犹豫买多大显存的卡也可以先拿它推演一下自己常用的模型和上下文长度再决定是选8GB、12GB还是更高的档位——总比买回家跑不动或者多花冤枉钱买过剩的容量来得更踏实。