
同样一张显卡玩本地大模型有的人说“8G显存轻松跑7B模型”有的人却说“16G都不够用”。两边都觉得自己没骗人问题出在哪其实他们说的根本不是一回事。这篇文章想跟你把“显存计算”这件事彻底掰扯清楚一个模型到底吃多少显存、量化精度怎么影响你的卡能不能塞得下、不同显存容量到底对应什么级别的模型以及买卡之前怎么用几分钟验证一台机器是不是真的“能跑”。内容比较干建议收藏。我做了快十年的模型训练和推理优化踩过的坑不少。早期做大模型微调的时候我经常被问“为什么显存明明够一跑就爆”后来发现大多数人压根没有系统的显存预估思路全凭感觉。这篇文章我会把底层的账一笔一笔算给你看顺带给你一套可以照着用的选购和部署策略。1. 同样的模型为什么有人说能跑有人说跑不动1.1 “能跑”的三个层次先讲一个我经常拿来打比方的例子一辆卡车能不能运货能运但要看运多远、运多少趟。模型推理也一样“能跑”这句话至少有三个完全不同的含义能加载模型文件被成功读入显存没有报OOM显存溢出。能推理加载之外还能正常生成内容速度可以接受。能服务除了会话推理还能支撑多用户并发、较长上下文和长期稳定运行。很多人说“8G显存能跑7B模型”指的是“能加载短对话能推理”而且大概率是把上下文长度压到了极低水平另外一些人说“16G都不够用”指的是“长时间维护超长上下文的服务”两者之间差异巨大。想要把显存算明白第一步就是搞清楚你讨论的是哪一种“能跑”。1.2 讨论歧义的来源精度、上下文、吞吐即便同样是“能推理”不同团队、不同工具给出的结论也可能天差地别。来源主要有三个精度设置不同同一个模型FP16精度的原始大小和INT4量化的“瘦身版”显存需求能差4倍。说“能跑”的人可能默认用INT4说“跑不了”的人可能根本不知道还有INT4这回事。上下文长度不同很多新手的显存计算只把模型权重算进去完全忘了上下文越长、KV Cache越大的事实。同样一个模型上下文从2K拉到32K显存占用可能翻一番还多。是否计入额外开销推理框架的激活值、CUDA缓冲、碎片化占用都有损耗实际占用往往比理论上限高出一截。所以有人问“某张显卡能不能跑某某模型”的时候我的第一个反问永远是“你打算用什么精度跑多长的上下文”如果对方答不上来那我不给结论只给计算办法。2. 显存账本逐项拆解权重、KV Cache与激活值各占多少2.1 权重所有参数乘每参数字节数模型权重是显存占用的第一大项也是最好计算的。核心公式是权重显存 参数量 × 每个参数所需字节数大模型参数通常以“B”为单位Billion十亿所以换算成显存GB时有 10^9 和 2^30 两种口径容易把人绕晕我一般按以下工程近似值快速推算精度每参数字节数7B模型理论权重大小13B模型理论权重大小FP324字节约28GB约52GBFP16/BF162字节约14GB约26GBINT81字节约7GB约13GBINT40.5字节约3.5GB约6.5GB这里用的换算化解方案是“参数量×字节数后÷1024三次方”实际用计算器的时候建议直接用参数量(以B为单位) × 字节数 × 0.93135得到的GB数更接近系统实际的二进制换算结果。比如7B模型FP167 × 2 × 0.93135 ≈ 13GB和我表格里的约14GB相差不大多出的部分可以当成余量。为什么“模型文件大小”不等于“显存占用”因为模型文件往往是压缩过的比如量化版本会做紧凑排列而推理框架加载后可能还会有对齐填充、算子优化等额外开销。实际操作中建议在理论值基础上额外留出10%-15%的余量。2.2 KV Cache随上下文线性增长的隐藏开销权重模型大小是固定的真正随用户输入变化的是KV Cache。这部分的底层逻辑是模型在生成每个新token时都需要“回顾”之前所有token的Key和Value向量如果每次重新计算速度会慢到不可接受所以推理框架会把这些向量缓存在显存里。KV Cache的显存并不难算关键参数包括层数、注意力头数、头维度、序列长度、批大小和字节数。工程上我倾向于用一个快速估算方法KV Cache约等于模型权重的10%-20%具体取决于上下文长度。上下文越长这个比例越接近上限甚至超过上限。举个例子我实际测过一些7B量级的模型FP16精度下上下文从2K拉到16KKV Cache显存会从约0.4GB变成约3GB如果再叠加连续对话的记录8G显卡确实会被塞满。所以当你打算长期挂一个长上下文服务时KV Cache不是小头而是必须明算的大头。2.3 激活值与运行时缓冲容易被忽略的几GB推理过程中中间激活值也是显存占用的一部分主要包括每一层的临时张量、LayerNorm的中间结果、Softmax的注意力矩阵等。推理和训练不同推理通常batch很小所以激活值不像训练那么爆炸。但当你开启长输出、beam search束搜索、并行解码等高级功能时激活值同样会明显增加。我在实际部署中还发现推理框架本身也会预分配一部分显存作为计算缓冲比如CUDA context驱动层上下文普遍占几百MB到1GB部分框架默认预分配可达数GB。这类开销最典型的表现是显存明明还有剩余但一加载模型就报OOM原因就是框架提前占用了“看起来空闲”的空间。所以一个比较稳的显存预算公式是实际显存需求 权重显存 KV Cache显存 激活值/运行时缓冲显存除非你对自己的负载非常清楚否则建议在计算结果的1.2倍以上找显卡。宁可买大不要买刚好够的——显存这东西用起来永远比预估吃紧。3. 量化精度才是卡脖子的关键从FP16到INT4的显存账本怎么算3.1 量化为什么能成倍“缩小”模型量化说白了就是用更少的bit表示一个浮点数。FP16用16bit表示一个数INT8用8bitINT4用4bit。精度降了数值范围也小了但换来的是显存和带宽开销直线下降而且经过良好校准的量化模型质量损失往往小到可以接受。用刚才那张表来想一个13B模型FP16下理论权重需要约26GB绝大多数人手里的显卡根本装不下INT8降到约13GB一张14G显存的卡刚好塞进去INT4再降到约6.5GB8G卡也有机会跑。量化能直接改变“能跑还是不能跑”的结论是选型时最先要考虑的因素。从亲测感受上讲INT8和FP16的输出质量差距很难感知INT4在部分复杂推理任务上会暴露出一些“变笨”的迹象但只要量化格式靠谱日常问答、代码补齐这类场景也够用。真正不建议的是INT4以下的极限压缩比如INT2那已经不是“压缩”而是“破坏”了。3.2 INT4量化下的实际卡位与质量损失把INT4量化引入之后模型选择的“卡位”会发生非常大的变化。还是拿13B模型举例它的原始FP16版本需要约26GB多数人手里的24G卡都跑得战战兢兢但换成INT4量化后理论权重约6.5GB加上KV Cache、激活值和缓冲大概不超过10GB。那么一张12G显卡就能把它驾驭起来体验远胜于勉强的8G卡。INT4质量损失的体感有多明显我做过一组对比测试同一个13B模型FP16和INT4在百科知识类问答上的答案几乎一样但做多步数学推理的时候INT4偶尔会在一两步内算错。关键是别选过于粗糙的量化策略——有些量化工具只是简单地把数值截断有些则做了校准和分组优化。后者通常比前者好得多这也是为什么同样是INT4实际体验能差出一个档位。3.3 选择合适的量化格式不同推理框架对量化格式的支持差异非常大。实践里同一个模型在不同框架下的文件大小不一样性能也完全不同。选择时必须结合部署目标而不是只看“位数”。我自己的选择规则是显存明明够用首选FP16/BF16原版不做量化。显存差一点优先INT8质量和速度均衡。显存紧张但还想跑大模型选INT4中公认的质量较好的量化类型优先4bit的K级量化工程上质量口碑比较好按分组方式计算细节不同框架命名不同。极少数内存受限场景才会考虑更低的bit数比如嵌入式设备通常不推荐。这里有一条重要经验不要只看量化位数更要看“量化粒度”。同是INT4有的按128个数值一组做缩放有的按32个数值一组做缩放后者的质量通常更好这是很多教程不会细讲的点。4. 不同显存容量的“模型地图”与推理参数对照4.1 6G-8G显卡门槛级玩家这个容量区间现在很尴尬。一张8G显存的显卡跑7B模型在原版FP16下不够约13-14GB跑INT4量化倒是能行。但刚够和不舒服之间有明显差距7B INT4模型权重约3.5GB加上KV Cache和缓冲8G显存勉强够上下文必须控制在4K-8K以内。6G显存则更紧通常只建议跑1.5B-4B级别的INT4模型或者7B INT4但上下文压到2K以内并关闭并发。如果你的显卡只有6G-8G我的建议是不要追逐模型尺寸重点选那些针对小参数量优化过、而且支持量化质量较好的模型。你需要对“能不能跑”有个清醒预期能聊天、能写短文案但长上下文和多轮复杂任务大概率吃力。这个区间的另一个致命瓶颈是内存带宽。8G卡通常带宽也只有两百多GB/s跑大模型生成速度会明显偏慢现实体验大概是每秒几个token到十几个token。换句话说能跑和“好用”是两回事。4.2 12G-16G显卡最值得认真计算的黄金区间12G-16G是目前最容易产生认知差异的区间。用公式推算13B模型INT4权重约6.5GB加KV Cache约1-3GB加缓冲约1-2GB总需求约9-11GB。12G卡可以跑16G卡跑起来更从容。7B模型FP16权重约13GB加缓冲后总需求14-15GB。12G卡几乎不够16G卡刚好但长期用会有压力。13B模型INT8权重约13GB加KV Cache和缓冲后约16-18GB超过16G卡的承受范围建议别轻易尝试。我把这个区间的结论总结成一张实查表显存推荐模型档位推荐精度上下文建议12G13BINT44K-8K12G7BINT88K-16K16G13BINT48K-16K16G7BFP1616K-32K16G14B左右INT8/INT44K-8K这个区间的重点不是“能不能跑”而是“想怎么跑”。如果你多数时间只是单用户会话12G就够如果你要挂API接口给多人用16G是个更稳妥的起步点。4.3 24G及以上进入真正的部署领域到了24G这个级别选型和玩法就不一样了13B模型FP16权重约26GB理论不够但加INT8或INT4后非常宽裕。30B模型INT4权重约15GB左右加上KV Cache和缓冲约18-22GB24G卡可以跑但上下文和并发要克制。65B/70B模型INT4权重约33GB以上24G单卡跑不了但可以做部分层卸载到内存CPU offload速度会慢。24G以上的显存配置更有意思的地方在于你可以尝试“大模型长上下文”的组合。比如用13B模型FP16还剩下近10GB上下文可以开到32K以上多路并发也基本无压力。在这个级别上显存不再是瓶颈内存带宽和计算单元的负载才是。5. 买卡前怎么验证“能跑”逐层逼近的推理测试5.1 理论计算先行买卡之前先把理论账算明白。比如你打算买一台16G显卡的机器想跑13B模型第一步就是用前面讲的公式算13B模型INT4权重约6.5GBKV Cache预算按上下文8K算约3GB激活值和缓冲约2GB合计约11.5GB小于16GB可行如果想跑13B INT8权重约13GB加上KV Cache与缓冲估计就到了17GB以上结论是超了不建议。这个阶段不要急着信别人的“实测”因为实测环境和你完全不一样——别人那台机器的框架版本、上下文长度、量化格式都可能是另一个体系。理论计算至少能帮你排除80%的错误选项。5.2 用离线脚本验证理论推到“差不多能跑”的时候就该做实际验证。最低成本的做法是下载一个离线推理框架加载目标模型跑一小段测试。重点观察模型加载后显存实际占用是多少。生成一段较长文本比如500-1000个token过程中显存是否稳定。上下文拉长后内存占用是否线性增长。连续多轮对话后是否触发OOM。我自己习惯用一个很简单的验证逻辑先按1个并发、短上下文跑通然后逐步把上下文加到目标长度再加到2-4个并发。只要过程中显存峰值没有超过显存总量这单就算稳了。但有一点必须反复强调“加载成功”不等于“长期稳定”。我有一次在测试环境跑得很顺部署上生产环境后一天之内崩了三次后来才发现是某个用户的超长历史对话把上下文顶爆了。真实用户不会像测试样本那样规矩所以验证时一定要留足余量。5.3 注意共享显存与Windows/Mac环境的差异还有一个很关键的坑共享显存和统一内存体系不一定是显卡显存。很多办公本、迷你主机宣称“16G显存”实际是显卡与系统内存共享的“最大共享显存”真实的独立显存可能只有8G或更少。跑大模型时CPU内存会被当作显存“溢出区”速度直接掉一个数量级。Mac苹果电脑平台的统一内存又是另一套逻辑。它的内存和显存是同一块物理内存理论上“统一内存多少显存就能用多少”但实际上系统还有其他进程占用只有约70%-80%能分给模型。所以一台16G内存的Mac大致相当于一台12G显存的Windows机器而不是16G。如果你在Windows NVIDIA英伟达环境下跑强烈建议打开任务管理器确认“专用GPU内存”和“共享GPU内存”两个数字。所谓的“8G显存”指标应该是专用GPU内存别被写着“可用总图形内存”的大数字骗了。6. 显存之外还需要关注的几件事6.1 内存带宽比显存还容易卡脖子的地方显存够了不代表速度就快。大模型推理的每一步都需要把权重从显存搬运到计算单元搬运速度的上限就是显存带宽。一个13B INT4模型大约6.5GB假设你要求每秒生成20个token每个token推理需要至少读一遍全部6.5GB权重这就意味着带宽需求高达130GB/s——很多中低端显卡的带宽还不够这个数字。这也是为什么同一个模型在不同显卡上的生成速度可以天差地别。高端显卡带宽动辄800GB/s以上低端独显只有一两百GB/s。买卡的时候不要只看显存大小一定要同时看带宽。我自己选卡几乎会先看带宽再看显存。举个直观的例子两张都支持13B INT4的显卡一张带宽低一张带宽高生成速度差距可能拉到3倍以上。前者聊天都感觉到明显停顿后者几乎可以连续输出。选卡时把“显存容量”和“内存带宽”放在同一行看不要单独比较。6.2 CPU内存与磁盘离线环境最后的一道墙如果你主要用CPU跑模型比如某些没有独显的服务器或老机器那重点就变成了内存容量。CPU推理的权重同样吃内存13B INT4模型约6.5GB但运行时还会申请大量中间内存建议系统总内存至少两倍于模型大小。补充一句大模型加载的启动时间经常被忽略。从磁盘读一次13B INT4模型机械硬盘可能要读很久NVMe固态硬盘则快得多。很多人第一次加载模型时以为“卡死了”其实是硬盘默默背了锅。建议模型文件放固态硬盘上能明显缩短启动时间。6.3 多卡并行是更大的系统课题显存不够了怎么办很多人会想到“多卡”。但要提醒一句单卡跑不动堆两张卡往往并不是简单翻倍。多卡并行需要把模型切分到多张卡节点间通信用的是PCIe高速互联通道通信延迟会吃掉一部分性能。另外多卡方案对软件配置要求高很多踩坑成本并不低。我的经验是如果单卡能跑哪怕勉强也优先单卡单卡实在跑不了且你有长期部署需求才考虑多卡。这个阶段需要从显存计算转向更复杂的系统设计包括通信拓扑、精度对齐和故障恢复不是简单把一张卡的配置复制两份就行的。结束语关于显存计算和显卡选型我自己在实际操作中的最大体会是永远为用户留出至少20%的显存余量。显存不是账面上的静态数字真实负载下的碎片化开销、长对话历史、并发请求都会悄悄吃掉存量。算账时老老实实把权重、KV Cache、激活值、缓冲四个大头都列出来再预留一点buffer就不会被“能跑”还是“跑不了”的口水仗牵着走。最后再分享一个小技巧拿到一新模型先去查它的参数量和推荐量化的位数然后用“权重×字节数上下文KV Cache预算”快速估算落到哪个档位。这个方法我用了很多年准确率足够高值得收藏。如果你读完还有拿不准的组合欢迎在评论区带上你的显卡型号、显存大小和目标模型我尽量帮你按这个公式算一遍。