前天有个朋友在群里说他用8G显存的显卡把一个十几亿参数规模的模型给跑起来了。我第一反应不是“厉害”而是“能跑但能跑多远”。果然他又补了一句上下文一超过一千字就不行再长一点直接报错退出。这种场景我见了太多次大多数人判断显卡能不能跑模型只看模型文件体积和显存容量但实际展示卡住你的往往不是容量本身而是那一堆容易被忽略的隐性开销。关于显存计算与模型选择其实有一个很简单却很关键的思路把显存需求拆成模型权重、KV缓存、运行时开销三层来算。这篇文章不是理论堆砌而是基于本地部署单卡场景讲清楚“你的显卡能跑多大的模型”这个问题的完整判断链路顺便把我这些年踩过的坑也一并说了。1. “能跑”不是只看模型大小显存需求要拆成三笔账1.1 第一笔账模型权重本身公式其实很简单模型占显存的第一大头是模型文件的权重。公式可以写成模型权重显存 ≈ 参数量 × 每个参数占用的字节数举个例子一个130亿参数规模的模型如果用FP16半精度存储每个参数占2个字节那么权重就是130 × 2 260亿字节 ≈ 24到26GB这里的“GB”和“GiB”有些差异我们不纠结单位只要记住数量级就行。换成BF16也差不多还是约26GB。如果用INT8量化每个参数占1个字节那就变成约13GB。如果用INT4量化每个参数占0.5个字节那就是约6.5GB到7GB。很多人一看INT4版本只要7GB再看自己显卡有8GB显存就觉得能跑。这就是第一重误会权重只是基础后面还有两笔账没算。1.2 第二笔账上下文长度和KV缓存最容易翻车的一笔KV缓存全称是Key-Value Cache是用来缓存模型在生成过程中已经算好的中间结果避免每生成一个token都重头再算一遍。你可以把它理解成记笔记你每说一句话模型都要把关键信息写在便利贴上后面再说新话的时候翻便利贴就行。问题在于这个便利贴非常占地方。它的大小跟模型的层数、隐藏维度直接相关。大约可以这样估算KV缓存大小 ≈ 2 × 层数 × 隐藏维度 × 精度字节数 × 上下文长度一个常见的130亿参数模型假设它有约40层隐藏维度约5120用FP16存储KV缓存那么每个token大约占用接近0.8MB。你听着好像不多但乘上上下文长度就吓人了上下文长度4096约3.2GB上下文长度8192约6.4GB上下文长度32768直接超过25GB现在你应该明白我朋友为什么上下文一到1000多字就崩了他那个模型在INT4下权重可能只有7GB但上下文一旦拉长KV缓存可以轻松吞掉几个GB在他那张8G显存的卡上根本装不下。这个坑是“显存够但一聊长就崩”的头号原因。1.3 第三笔账运行时开销和框架占用除了权重和KV缓存你的显卡还要腾出一部分显存给计算框架、CUDA上下文、内核代码、临时计算图这些杂七杂八的东西。这部分不是固定的但一般来说1GB到2GB是常态。如果你还开着图形界面、浏览器或者用了一些带WebUI的服务端再吃几百MB到1GB也不是什么稀罕事。所以真正可靠的显存估算至少应该是运行所需显存 ≈ 权重 KV缓存 1.5GB左右如果你想更进一步做微调那还得算上优化器状态和梯度那是另一个量级的问题。这篇文章只讨论直接加载模型做推理和生成的情况。我第一次本地跑模型就是只看模型文件大小觉得12GB显存跑一个13GB的模型差不多结果连启动都报错后来一查才知道框架本身就吃掉了1G多。从那以后我再也不敢忽略“运行时开销”这个小数目了。2. 精度和量化为什么同样是13B有人说8G能跑有人说要24G2.1 先搞清楚FP16、BF16、INT8、INT4到底差多少模型精度决定了每个参数占几个字节这也是为什么同一个模型不同精度下显存需求天差地别。整理成一张表给你看精度类型每参数字节数130亿参数模型大致权重大小FP324字节约52GBFP16 / BF162字节约26GBINT81字节约13GBINT40.5字节约6.5GB到7GBFP32很少有人用因为太大了。FP16和BF16是很多模型默认的保存格式也是效果最稳的格式。INT8和INT4是把原始权重做压缩代价是丢掉一部分精度信息换来了更小的文件体积和更低的显存门槛。2.2 量化不是万能的KV缓存不会因权重量化而缩水这里要特别提醒一个误区很多人以为用了INT4量化整个显存占用都会变成原来的四分之一。错。量化只压缩权重那一部分KV缓存往往还是会用FP16或BF16存储运行时开销也不会因为你量化了权重就自动变少。也就是说一个130亿参数模型即使权重被压到7GBKV缓存该要3GB还是3GB运行时该占1GB还是1GB。这样一算8GB显存想跑长上下文就是极限中的极限只适合非常短的对话或者测试场景。如果你真想长聊16GB显存才是比较舒服的起点。2.3 用一张表看不同参数量下的显存门槛我平时选模型的时候习惯按照“权重 中等上下文 运行时开销”来归类大致可以参照下面这张表参数量FP16/BF16INT8INT4典型适配思路70亿左右约14GB约7GB约4GB8GB显存紧凑12GB以上稳妥130亿左右约26GB约13GB约7GB16GB显存较理想12GB需短上下文320亿左右约64GB约32GB约16GB24GB显存需把上下文控制在4K以内700亿左右约140GB约70GB约35GB48GB以上或CPU卸载/多卡方案这张表的“典型适配思路”是按我个人使用习惯来的不是绝对标准。因为上下文长短会影响很大所以表里很多档位是“能做到但是紧巴巴”。我自己的经验是不要踩着容量上限选模型否则你后续调上下文、开并行、挂服务都会非常痛苦。3. 显存之外带宽、算力、容量三样缺一样都会让你怀疑人生3.1 显存带宽为什么比容量更能决定“卡不卡”有一类问题模型确实加载进去了显存也够但生成速度慢得令人发指一分钟出不来几个字。这就不是容量问题而是显存带宽问题。大模型生成token的时候要把模型权重一遍又一遍地从显存里读出来做矩阵计算。可以粗略认为每秒生成token数约等于理论生成速度 ≈ 显存带宽 ÷ 模型权重举个例子某个显卡显存带宽大概在每秒500GB左右跑一个权重7GB的模型简单除一下就是500 ÷ 7 ≈ 70 tokens/s但实际还要算KV缓存、计算损耗、其他开销所以到手的数字往往比这个理论值低。如果你用CPU卸载方案或者显卡带宽本身一般那速度可能掉到个位数。这就解释了为什么同一张显卡跑70亿模型飞快跑700亿模型就如同幻灯片因为权重大了十倍带宽却没变。所以选模型的时候不光要问“显存装不装得下”还要问“装下之后跑得动吗”。3.2 计算力和批量大小一次要处理多少请求显存带宽决定的是“读取权重”的速度而GPU算力决定的是“计算权重”的速度。在纯文本生成这类场景里大多数时候瓶颈在带宽因为模型参数量太大计算往往反而不是第一位。但如果你的场景是批量处理、多路并发或者让模型同时回答很多请求那计算力的影响就会明显上升。显存里同时塞进多个请求的KV缓存之后容量和带宽的压力会同步放大。我的建议是先搞清楚自己是一次只和一个模型对话还是要跑一个多用户服务这决定了你选卡、选模型时的余量标准。3.3 显存容量带来了一个“模型多大才合适”的现实选择我把自己的选择逻辑总结成一句话先定场景再定显存最后定模型。如果你只是日常体验跑一个70亿到130亿参数级别的INT4模型8GB到12GB显存就够折腾了。如果你想做认真的创作、代码生成或者长文档处理建议至少16GB到24GB这样上下文才能开得足够长。如果你要跑320亿甚至700亿参数级别的模型24GB是起点再大就得考虑多卡或比较麻烦的CPU卸载方案。我见过有人只有8GB显存却非要跑130亿参数结果为了塞进去把上下文限制到极短生成几百字就要重来一次体验很差。这种情况下我真觉得不如老老实实跑一个70亿参数的模型反而速度和稳定性都更好。4. 手把手判断流程三步算出你的显卡上限4.1 第一步明确你到底是在做推理还是训练同样的模型推理和训练/微调对显存的需求完全不同。推理是拿现成的权重去生成内容显存需求主要就是权重加KV缓存。微调或训练则要额外保存梯度、优化器状态和大量中间激活值显存需求可以轻松翻两三倍甚至更多。所以判断“显卡能跑多大模型”之前先问自己我是只用来推理对话还是想拿它来微调如果是后者你要按“至少三倍模型权重”去准备显存不然中途就会碰到各种内存不足的报错。这篇文章后面说的都是推理场景训练场景我另找时间专门聊。4.2 第二步按公式算出预估显存再留出余量我自己真正操作时用的是这个算术所需显存 ≈ 模型权重 KV缓存 1.5GB运行时开销 告警余量告警余量我一般会留10%到15%。不要小看它显卡驱动、桌面环境、偶尔跳出来的后台进程都有可能在关键时候咬你一口。拿比较主流的配置来算一遍8GB显存跑70亿参数INT4权重约4GB如果你把上下文限制在2000左右KV缓存约1GB加运行时约6.5GB到7GB勉强能用。16GB显存跑130亿参数INT4权重约7GB上下文开8192KV缓存约6.4GB再加运行时1.5GB总共约15GB极限但可行。所以很多人说16GB跑130亿模型是甜点配置是有道理的。24GB显存跑320亿参数INT4权重约16GB上下文只能控制在4096左右KV缓存约6GB加运行时约23GB已经接近满载。想开更长上下文就得往下降参数量。我把这几个数字写在表格里方便你对照自己的显卡判断显存参数量建议推荐配置注意事项8GB70亿及以下INT4短上下文上下文超过4096很容易崩12GB70亿到130亿INT4中等上下文130亿只能短对话16GB130亿为主INT48192上下文兼顾速度和容量的平衡点24GB320亿以下INT44096上下文运行大模型但要把上下文压低4.3 第三步用实际测量代替“我以为”公式算完只是第一步真正可靠的判断是实测。别急着下载完整的大模型先找一个量化版本启动后马上看显存占用情况。然后在空跑一段长文本把窗口往上推看显存在什么时候开始报警。我自己的习惯是第一次加载时只看显存能不能装下然后立刻做一次长度为模型上下文80%左右的长文本生成。只有这一轮撑过去我才会正式把它作为日常主力模型。很多模型表面容量合适但一拉长便原形毕露实测能帮你少走很多弯路。5. 排坑显存明明够为什么还是会崩溃5.1 上下文长度突然一变长KV缓存瞬间翻倍我在本地部署时踩过最多次的坑就是上下文长度没算进KV缓存里。有次我以为16GB显存跑130亿参数模型很稳结果某次会话里贴了一段超长文档系统提示加输入内容再加之前的对话历史上下文长度一下冲到上限显存直接爆掉。所以不要只看模型启动时占了多少显存那只是“静止状态”。生成起来之后KV缓存会随着对话长度快速增长你那一两GB的余量可能在不知不觉中就耗完了。如果你想长期使用最好把上下文设定在一个保守值比如显存余量不够时就把上下文从8192降到4096效果立竿见影。5.2 显存碎片化和后台程序偷内存才是最隐蔽的敌人还有一种情况非常气人你关了模型显存看起来有很多空闲但重新加载更大的模型时还是报错。这可能是显存碎片化造成的前面反复加载释放模型显存被切成很多小块新模型需要一大块连续空间时反而分配不出来。遇到这种情况重启一下程序有时候就解决了。另外浏览器开着视频页面、图形桌面、远程桌面连接都会悄悄占用几百MB到1GB的显存。我测试的时候会先关掉所有可能占资源的程序再用显卡监控命令看空闲显存到底有多少。空余显存和“你以为的空余显存”完全是两个概念。5.3 一条最实用的经验永远留出20%的安全边界很多人看到显存容量还有百分之几的余量就觉得自己稳了结果一跑起来才知道边缘有多窄。我现在的原则是预估占用超过显存85%的配置一律不采用。宁可向下兼容一个更小的模型或者把量化等级再压一档也要保证给KV缓存、运行时和突发情况留出足够空间。用显存容量打着擦边球去强行跑大模型最后大概率会以频繁重启结束体验极差。真正用下来你会发现稳定、快速、能长时间连续对话的模型哪怕参数小一点也比三天两头崩溃的大模型实用得多。再说一个我后来养成的习惯先下载最小量化版本做测量再决定要不要下完整版本。很多时候最小版本都扛不住完整版本就更别说了这样能省下不少下载时间和硬盘空间。显存计算与模型选择说到底不是数学考试而是为了让你在本地跑模型时更省心、更实用。