大模型本地跑的瓶颈从来不是网速而是显存。我经常看到有人兴冲冲下载了一个“据说很强”的模型结果一加载就报显存不足或者在某个上下文特别长的瞬间直接崩溃。更麻烦的是同一个模型网上有人说 8G 能跑有人说必须 24G看起来矛盾其实是因为大家默认的精度、上下文长度和并发数都不同。显存这件事是可以自己算出来的算清楚之后你的显卡能跑多大的模型、该选什么精度、该开多长上下文都会有明确答案而不是靠运气。这篇文章我会从显存的构成讲起给一套能直接套用的估算公式再按 6G、8G、12G、16G、24G、48G 这些常见档位给出选型思路最后聊聊实际运行中那些公式算不到的“隐藏开销”和排查经验。适合所有想在本机跑模型、做微调或布置本地推理服务的读者尤其是被各种“最低配置”说法搞糊涂的朋友。1. 显存到底被谁占满了一张模型卡在 GPU 上的四大开销拆解很多人以为“模型文件多大显存就占多大”这个说法只对了一半。模型文件是权重快照真正运行时显存里同时挤着权重、KV 缓存、中间激活和框架预留这四样东西哪一样都不能少。1.1 权重是最大的一块但大小完全取决于精度权重就是模型里所有“参数”本身。同一个模型参数个数是固定的但它在显存里占的字节数不固定取决于每个参数用几个字节来表示fp32每参数 4 字节精度最高体积也最大fp16 / bf16每参数 2 字节大多数推理场景的主流选择int8每参数 1 字节量化后的常见格式int4每参数 0.5 字节最省显存通常配合反量化逻辑读取换算很简单权重体积约等于参数数量乘以每参数字节数。以 7B 参数级模型为例fp16 下就是 7 × 10^9 × 2 字节约 14GBint8 约 7GBint4 约 3.5GB。第一步很多人会算但接下来往往把另外三块开销忘得干干净净。1.2 上下文越长KV 缓存越大KV 缓存也叫注意力键值缓存是模型生成时临时存放的历史键值对目的是让新 token 只跟历史 token 做注意力计算不用每步重算完整前向。代价是它随上下文长度线性增长长对话、长文档场景下这块经常大到和权重一个量级。KV 大小的粗略公式是2Key 和 Value 两套 × 层数 × 注意力头数 × 每头维度 × 每参数字节数再乘上当前序列长度。不同模型架构差异很大拿一个 7B 级、32 层、32 头、每头 128 维的常见结构来套单个 token 大约 0.5MB。看着不起眼上下文到 8K 时就是 4GB 左右直接顶掉半张 8G 卡。所以“模型 int4 量化完才 3.5GB我肯定能跑长上下文”这种想法通常会栽在 KV 上。中间激活在推理时也有主要是前向计算里的隐藏状态和临时张量通常比权重小。但只要 batch size 开大、序列变长它也会变成足够让你报错的另一刀。所以从这四块的关系已经能看出结论显存需求不是一个“模型固定数字”而是模型精度、上下文长度、并发批大小三者的函数。2. 从“参数B”到“显存GB”的快速公式fp16/bf16/int8/int4的换算逻辑进入实操环节。先给一条能直接套用的经验公式推理场景的单路估算显存 ≈ 权重体积 KV 缓存单 token 体积 × 上下文长度 × 并发数 余量权重体积按前面的换算KV 缓存则需要知道目标模型的具体结构尤其是有没有共享 KV 头的设计。KV 单 token 字节数可用模型配置里的层数、注意力头数、头维度来算KV_bytes_per_token 2 × 层数 × 注意力头数 × 头维度 × 精度字节如果模型采用了 GQA、MQA 这类共享 KV 头设计要用 KV 头数而不是总注意力头数能省下不少显存。具体以模型配置文件为准不同架构差异可能达到两到四倍。2.1 一张精度换算表把参数 B 直接换成显存 GB精度每参数字节7B 模型权重13B 模型权重70B 模型权重fp324约 28GB约 52GB约 280GBfp16/bf162约 14GB约 26GB约 140GBint81约 7GB约 13GB约 70GBint40.5约 3.5GB约 6.5GB约 35GB这张表能给你一个直觉70B 级模型不是“13B 的五倍负担”而是每次上档都要重新审视自己的卡。很多人问“40G 大显存能不能跑 70B”答案很明确fp16 权重 140GB连边都摸不到int8 也要 70GB只有 int4 下的 35GB 才能勉强塞进 48G 左右的卡里。这就是为什么要先算账再下载不然白花时间。2.2 代入三个实际场景7B、13B、70B 都别只看权重场景一8G 卡想跑 7B 原版 fp16。权重 14GB直接出局。换成 int4 权重约 3.5GB如果上下文限定在 4KKV 按单 token 0.5MB 来算约 2GB整机预估 3.5 2 1.5 余量 7GB比较贴近但不宽裕。如果贪心把上下文拉到 8KKV 直接变 4GB总预估到 9GB8G 卡必然爆。所以 8G 卡跑 7B int4上下文 4K 以内更稳。场景二16G 卡想跑 13B fp16。权重 26GB单卡放不下。换成 int8 约 13GB4K 上下文的 KV 约 2GB加上 1-2GB 余量正好卡在 16G 附近可以试但紧张。想要更长上下文只能退到 int4 或者缩短序列。场景三24G 卡想跑 70B int4。权重 35GB单卡纯 GPU 根本放不下。所以“24G 就能跑 70B”的说法背后往往要么是走了 CPU 分载要么是把上下文压得非常短要么是多卡并行。单卡显存层面这个级别的模型已经不属于“放得下”的范畴。2.3 上下文和 batch 是两个乘数不是两个常数公式里的 KV 量级是随“序列长度 × 并发请求数”线性放大的。并发 4 路、上下文 8K 时KV 开销变成单路对话的 4 倍batch 进公式的时候也要乘进去别只按 1 来算。提示所有估算值都应额外留出 10%-20% 缓冲。实际分配不是真空的并行计算库、驱动、日志缓冲都会吃几十 MB 到几百 MB。预算贴太紧加载那一刻就可能报错。3. 量化不是白给的从 FP16 到 int4 的取舍逻辑量化是目前小显存跑大模型的现实手段但“改成 int4”背后是有代价的。3.1 量化到底做了什么量化本质上是用低位宽表示权重通过分段缩放系数尽量保住数值范围。直观理解fp16 是每 2 字节记一个数int4 是每 0.5 字节记一个数体积压缩到四分之一但低比特必然丢精度。效果怎么样主要取决于量化算法的质量不是简单“砍一半”就能等价。我实测下来的体感是int8 在很多场景几乎感知不到劣化int4 在常用对话里也还能用但在数学推理、复杂因果、稀有词这些地方会明显变“笨”或变“糊”。如果你的任务对输出确定性要求高比如代码生成、结构化输出优先选更高精度不要一门心思冲 int4。3.2 不同显存档位量化的“安全水位”不同卡显存7B 方案13B 方案70B 方案6G不太建议int4 短上下文勉强基本不行不行8Gint4 短上下文可行int4 很紧张不行12Gint4 常规长度可行 / int8 短长度int4 短长度勉强不行16Gfp16 可行 / int8 带长上下文int8 短到中长度 / int4 更宽裕不行24Gfp16 大上下文轻松fp16 中长上下文 / int4 余量够只 int4 且很吃紧48G随便fp16 宽裕int4 有一定余量int8 仍不够这只是档位粗配真实情况要和上下文、batch、是否微调强绑定。“能放进去”和“能用得舒服”是两回事。比如 24G 卡上跑 13B fp16日常对话没问题但你要一次读进去一份几万 token 的文档KV 就会把剩余显存吃掉大半。3.3 两个实测过的量化翻车现场第一个翻车为了在 8G 卡上硬上 13B int4我把上下文设成了 16K。权重 6.5G 进去了但 KV 直接失控13B 级模型的 KV 单 token 比 7B 大不少16K 上下文的 KV 能到 5-6G剩余的一点点显存还没生成几个 token 就被耗尽。后来把上下文砍到 4K稳定跑完。教训就是不要先定模型后定上下文要先算总账。第二个翻车我把一个 70B 级模型在 24G 卡上用 int4 强行推理。短问答没问题连续追问几轮也还能跑一上长上下文就崩而且每步要从内存或磁盘反复捞权重速度慢到像死机。最后把一部分层分载到内存关键时刻确实能顶住代价是慢但对“一定要在单卡上跑一次大模型”的人来说这种慢是可以接受的。4. 推理和微调是两笔账优化器状态如何把显存需求翻上三倍想微调的人常犯一个错误拿推理公式往上怼。“7B 模型 fp16 才 14G我 24G 卡应该能全参微调吧”答案是不够差得很远。训练要在推理基础上额外存三样东西梯度、优化器状态、激活。4.1 Adam 系优化器是显存黑洞训练时为了让权重迭代反向传播先要算出梯度梯度和权重同大小fp16 模型就多 14G优化器如果用的是 AdamW它为每个参数还要再存一阶动量、二阶动量通常还会留一份 fp32 精度的权重副本来做数值稳定的更新。粗暴概括就是权重之外至少还要按 12-16 字节每参数来算更保守的估算会直接按 20 字节每参数。全参数微调一个 7B 模型按 fp16 权重加优化器状态的总代价来算量级直奔上百 GB这显然不是单卡消费级能承受的。24G 卡全参微调 7B我基本会劝退。这也是现在 LoRA 类方案流行的根本原因。4.2 LoRA 为什么能省它只给一小块参数配“可训练副本”LoRA 的思路不是更新全部权重而是在注意力矩阵旁边加一排低秩的可训练小矩阵冻结原权重前向推理照常训练只更新小矩阵。7B 模型可能只需要训练千分之几到百分之一的参数优化器状态和梯度不再跟全模型挂钩训练显存会瞬间降下来。再把基础模型量化成 int4就是常见的 QLoRA 方案单卡 16G 到 24G 微调 7B 类模型能成为现实原因就在这里。4.3 一表看清推理、全参微调、LoRA 的差距配置7B fp16 权重需求额外显存需求单卡结论纯推理约 14GBKV 激活少量24G 卡轻松全参微调权重 梯度 优化器状态激活数十 GB单卡基本别想LoRA 微调14G 权重 小矩阵状态激活仍较大24G 卡比较勉强需降批或短序列QLoRAint4 权重约 4G 小矩阵激活较大单卡 16G-24G 可试注意微调时的激活开销会随 batch size 和序列长度猛涨且无法通过权重简单推算。就算 LoRA 把优化器状态省掉一段长上下文也可能把显存吃到手抖。微调前务必从更短的序列、更小的 batch 起步边跑边观察再逐步加大。5. 按显存档位选模型6G 到 48G 到底怎么配公式算明白了接下来落地到“我的卡能跑多大模型”。下面是我常用的档位路线不是绝对命令。实测逼近之前永远要根据自己的任务目标做微调。5.1 六个档位的参考配置显存推荐档位精度 / 上下文建议适合场景6G4B 级以下7B 别强求int4 2K-4K轻量对话、小任务8G7B 是上限int4 4K 以内int8 只适合极短上下文通用对话、普通代码12G7B 较舒服13B 谨慎7B int8/int4 可加长13B 仅 int4 短上下文对话、中等文档摘要16G13B int4/int87B fp16 随便跑13B int4 建议 8K 内int8 建议 4K 内复杂任务、长对话24G13B fp16 舒服27B-30B 级需 int470B 需分载13B fp16 长上下文30B int4 短上下文70B 靠外部分载本地推理、LoRA 微调48G30B int8 舒服70B int4 有戏70B 上下文化能压则压避免 KV 爆炸单卡大模型、中规模微调如果你心里已经有一个目标模型做法是查出它的参数量、层数、注意力头数、KV 头数先算权重大小和单 token KV 体积上下文按自己的实际需要来短对话按 4K 到 8K 算长文档按 16K 到 32K 认真评估。不要照搬别人的“16G 能跑”结论因为对方可能只聊了两句话你要的是读完整份文档。5.2 档位之间的隐形坑6G 和 8G 档最常踩的坑是忽视“连续聊天轮次”。一轮对话的上下文是连续累积的聊到第三、第四轮就把 KV 撑大了本地聊天助手一开始很流畅聊久了开始卡或报错本质就是 KV 线性增长撞墙。12G 档要注意别同时开多个推理服务每个进程会独立缓存一份权重两个 7B int4 进程加起来照样超过 10G。24G 档的口号是“本地跑大模型”最响亮但一定要分清是推理还是微调。推理 70B int4 可以凑合微调 13B 全参几乎不可能LoRA 反而是现实选择。48G 档虽然算单体大卡了也要检查 CPU 内存和带宽是否成为瓶颈模型分载时经常是“读到哪、算到哪”内存喂太慢 GPU 就空转。5.3 显存不够的另一条路分载和多卡如果算下来就差一点有三条常见方案把部分层分载到系统内存换取这个级别模型的可运行性用多卡张量并行比如两张 24G 卡跑 70B int4 会舒服很多或者反过来压需求降低量化等级或缩短上下文。三条路都可走但要在“能跑”和“体验”里做取舍。分载让每个 token 慢到让人怀疑人生多卡有同步开销缩上下文可能丢信息没有完美答案。6. 实际运行中那些“算外”的显存开销与排查经验公式算完不代表运行就顺利。实测中总有一堆“算外”开销这里挑我遇到最多的三块讲。6.1 框架缓存和系统预留监控工具的数字不能直接解读打开显卡监控工具你会看到自己的进程显示的显存占用比“权重 KV”的估算值高出一截而且不会即时回落。原因是主流深度学习框架倾向于向驱动申请大块显存池分配在前、回收在后进程退出前这块池子可能一直占着。所以用监控工具判断“模型到底占多大”是不准的要看进程自己报的那一项或者从框架内部的显存统计接口查实际分配量。另一块是并行计算运行时的上下文和各种底层库的初始化开销几百 MB 起步。这跟模型没关系但会占掉你可用显存里的“零头”。前面估算时要求留 10%-20% 缓冲对应的就是这件事。6.2 一次 OOM 的完整排查链路按这个顺序来我实际遇过一次看似“模型明明能放下却报显存不足”的情况。排查过程大概是先用公式算7B int4 权重 3.5G上下文 8K 时估 KV 约 4G卡是 8G加缓冲已经到 7.5G 附近。第一反应是“就差一点”于是把上下文降到 4K但还是报错。查框架内部的显存分配接口发现峰值分配早就超过了估算。把模型配置拉出来重新算发现它的 KV 头配置比通用例子多单 token 不是 0.5MB 而是 0.75MB8K 上下文的实际 KV 成本比预估高了一半。确认框架预留分布式缓存、临时分配池这些默认打开的预留机制吃了一部分设置释放后回到公式附近问题解决。最后验证改完配置连续跑多轮长对话再用进程内的峰值统计接口记录整条曲线确认估算对得上。任何一次大模型 OOM 都应该走类似链路先核对参数配置再验上下文和 batch再看框架预留最后动量化或换模型。不要一上来就“换个 int4”或“换个小模型”那样只是把问题表面压掉换个场景还会再爆。6.3 验证算得对不对的三个指标我建议日常关注三个指标加载阶段的显存峰值、跑单轮对话时的峰值分配、跑到长上下文时的峰值分配。三个值分别反映不同开销加载只反映权重搬运单轮对话反映权重加 KV 的日常量长上下文直接检验 KV 是否成为瓶颈。当你把这些值记录下来会发现一个规律如果长上下文运行时的峰值显著超过“权重 估算 KV × 长度”那多半是激活或框架池在作祟不是模型本身的问题。我现在的习惯是每次下载新模型前先用公式把边界算出来跑一次就做一次三个指标对照。时间久了显存规划会准得惊人连“该不该换卡”这种问题都能用数据回答而不是靠心情。最后分享一个小技巧在你准备冲一个大模型之前先拿它的量化版跑一遍把上下文故意调到你真实使用的最大长度来回多聊几轮。如果这一关能稳定过那我恭喜你这台卡在相当长一段时间内都不用换了。
