很多人来问我我这显卡能跑多大的模型一开始我以为是问配置后来发现大部分人真正想知道的是手头这块卡到底能带动哪个模型、什么精度的、能开多长的上下文。这个问题看似简单真要回答清楚得先搞清楚显存都花在哪儿了然后才能算明白自己能跑到哪儿。这篇文章就把我平时给项目估算显存的完整思路和实战记录整理出来看完你也能自己算。1. 显存到底被谁吃掉了模型部署的显存开销拆解1.1 权重参数是基本盘模型体积由参数量和精度决定显存占用的第一大头永远是模型本身的权重参数。表达力越强的模型参数量越大占用的显存就越多。参数驻留显存的计算方式非常直观就是把模型里每一个参数的数值按你加载时用的数据类型换算成字节数再乘以参数量。比如一个70亿参数7B的模型用FP32加载每个参数占4字节总计约28GB用FP16或BF16每个参数占2字节总计约14GB用INT8量化每个参数占1字节总计约7GB用INT4量化每个参数约0.5字节算上量化开销实际落到4GB到5GB。这里最容易踩的坑是很多人以为下载文件多大加载到显存就是多大。实际上GGUF格式的模型文件是压缩后的打包体积加载时量化内核会做一些对齐和反量化缓冲最终驻留显存会略高于文件体积高出0.5GB甚至1GB都正常。所以千万别按文件大小估显存。1.2 推理时隐藏的大头KV Cache和激活值权重只是静态占用。真正让你算得头疼的是推理过程中的KV Cache。KV Cache是Transformer模型在逐个生成Token时把历史Token的Key和Value缓存下来、避免重复计算的显存开销。它的大小跟模型架构强相关跟上下文长度和并发数强相关。对普通单用户本地推理KV Cache的估算公式可以写成KV Cache大小 2Key和Value两份 × 层数 × KV头数 × 头维度 × 序列长度 × 单元素字节数我拿一个常见的中型模型举例32层、8个KV头、每个头维度128、以BF16推理、上下文长度设为4096。代入公式算下来大概在512MB左右如果把上下文拉到8192直接翻倍过1GB。这个开销往往在你没意识到的时候就悄悄挤掉了模型本身的加载空间。1.3 容易被忽略的碎块CUDA Context、临时缓冲区除了权重和KV Cache显存里还住着一些零零碎碎但躲不掉的东西。CUDA Context是当你调用GPU推理框架时自动分配的环境显存不同框架差异不小有的只占300MB左右有的能占到接近1GB。激活值中间计算结果虽然不像训练时那样夸张但在较长的序列下也会有几百MB级的开销。加载图形化界面或WebUI中间件时背后还会占掉一部分显存。这些都是你在纸上估算时特别容易漏掉的量。我自己估算时的安全经验是把权重和KV Cache算完再往上加1GB到1.5GB的房屋公摊才是一个比较接近于真实的开机占用。2. 显存估算的实操公式动手算清楚你的模型上限2.1 权重参数显存计算从模型参数量到加载方式为了让你能直接抄作业我把整个估算流程拆成三步走。第一步查模型的参数量。在模型主页上一般都能看到比如7B、13B、34B、70B之类这些数字是四舍五入的。第二步定你要跑的数据精度。第三步套用字节数。下面这张表是我整理好的参考可以直接对着抄加载精度单参数字节7B模型占用13B模型占用70B模型占用FP324字节约28GB约52GB约280GBFP16/BF162字节约14GB约26GB约140GBINT81字节约7GB约13GB约70GBINT4量化约0.5字节约4GB约7GB约35GB这里提醒一句有些模型标称7B实际参数量是6.9B还是7.6B结果会有一些差异。另外像MoE混合专家架构的模型虽然总参数量看着很大但每次推理只激活部分参数实际权重显存占用按全量参数算这一点要看清架构说明。2.2 KV Cache显存计算给上下文长度留够量KV Cache的计算公式前面给过这里直接代入一个典型例子。假设我用一个8B级别的模型架构参数按常见开源模型来定32层、每层有8个KV头、每个头维度128、推理精度用FP162字节。当我设定上下文长度是4096时计算如下KV Cache 2 × 32 × 8 × 128 × 4096 × 2字节 2 × 32 × 8 × 128 × 8192字节 536,870,912字节约512MB把上下文拉到8192就是约1GB如果要开32K那就是约4GB。你要是用满血多头注意力架构比如不采用GQA的旧模型KV头数会大好几倍同样长度下的KV Cache会暴涨到几GB甚至十几GB。这就是为什么新模型普遍都换成了GQA分组查询注意力目的之一就是在长上下文场景省显存。2.3 汇总公式和判断标准把静态和动态两块合起来单次推理一条请求的显存需求大约是这样总显存需求 ≈ 模型权重显存 KV Cache显存 推理框架开销1GB左右再补充一条多并发场景的规则KV Cache是按请求数量线性复制的。服务端并发8个请求KV Cache开销就是单条的8倍。所以本地跑单用户娱乐随便开长上下文但要做服务部署并发一多显存立刻爆掉。判断能不能跑我习惯看两个指标一是显存够不够二是生成速度能不能接受。显存不够的直接表现是CUDA Out Of Memory显存刚好够但速度只有每秒几个Token用起来也会让人崩溃。3. 不同档位显卡的模型选择多少显存能做什么事3.1 6GB到8GB档小显存的边界选择这个档位是入门卡和部分轻薄本独显的常见区间。6GB到8GB显存能做的事远比很多人想象得多但你必须接受量化。我实测下来最稳妥的选择是跑7B到8B级别模型的INT4量化版本。比如常见的7B/8B模型用Q4_K_M量化后权重落到4GB到5.5GB之间给KV Cache预留2GB到3GB开4096到8192的上下文显存刚刚好。生成速度取决于显卡带宽新一代显卡在8GB档位通常能跑到每秒15到25个Token日常问答完全够用。这个档位千万别碰13B级别的INT4模型。13B的INT4量化后权重约7GB看着好像能塞进去但一旦开长上下文KV Cache加框架开销直接给你顶到溢出。我见过太多人用8GB卡硬跑13B INT4结果只开2048上下文还时不时闪退。3.2 10GB到12GB档甜品卡的舒适区10GB到12GB是目前非常主流的一个区间。这个档位的显存大小正好卡在能跑中型模型和开长上下文的交汇点。我的推荐是13B到14B级别模型的INT4量化版本这是这个显存区间里性价比最高的选择。13B INT4权重约7GB剩下3GB到5GB给KV Cache开8192上下文非常从容。想再激进一点17B到20B出头的MoE模型也能塞进去但需要把上下文压短否则会顶满显存。这个档位的甜点玩法是模型选13B或14B的INT4上下文开8192部署工具用GGUF推理框架不考虑复杂服务化选项。实测生成速度稳定在每秒10到20个Token体验已经接近商业应用的水平。3.3 16GB到24GB档中高端卡的自由区间16GB到24GB显存是当前本地部署体验最好的区间之一。16GB能覆盖大部分13B模型的FP16原版权重也能跑20B到30B级别模型的INT4量化。24GB更舒服32B级别的INT4模型可以直接带得动甚至能尝试40B级别的MoE模型。这里我说一个很多人不知道的技巧在24GB显存下跑32B模型INT4量化权重约18GB到20GB剩余显存看起来只够开很短的上下文但如果用支持KV Cache量化的部署工具KV Cache的每元素字节数可以从2字节压到0.5字节上下文长度能翻好几倍。这就是为什么同样一张卡不同工具下的表现差异会这么大。另外24GB显存是跑34B级别量化模型的及格线。低于24GB你只能把上下文控制在2048以内高于24GB才能兼顾上下文和并发体验完全不一样。3.4 48GB以上专业场景和中高端部署48GB及以上的显存多见于专业计算卡或双卡组合。这个量级下你的选择余地变得很大可以跑70B级别模型的INT4量化也可以跑32B模型的FP16或更高精度还能同时服务多个并发请求。不过显存大到这个程度真正的瓶颈往往不再是放不放得下而是推理速度。70B INT4的权重约40GB哪怕是带宽接近1TB/s的旗舰卡理论每Token生成也得读取一次全部参数实测生成速度通常也就每秒10到20个Token。所以这个档位更适合做批量离线推理或者用多卡方案做分布式推理单人对谈的体验反而未必比中端卡好多少。4. 部署实操量化方案与推理工具的取舍4.1 量化格式怎么选GGUF、GPTQ、AWQ量化是把模型权重从FP16压到低比特数的过程。同样的显存条件下量化能让卡多跑一个量级的模型但代价是精度损失和速度变化。目前主流的量化方案有三种我逐个说下实际体感GGUF是目前生态最成熟、兼容性最强的格式适合llama.cpp和Ollama这类工具。它的特点是量化等级极其丰富从Q2_K到Q8_0你可以在精度和体积之间找到非常细的档位。CPU、GPU混合部署时它也是最稳的。我的建议是低显存用户无脑选GGUFQ4_K_M档位是甜点。GPTQ是一种GPU专属的量化方案量化后显存占用比同等GGUF略低推理速度也快一些但是需要在量化过程中使用校准数据集量化不当可能出现个别层掉精度明显的情况。如果你要用vLLM做服务化部署GPTQ是常见选择。AWQ则是从激活值分布角度做保护性量化对重要权重通道保留更高精度。实测它在大模型上的精度崩溃风险比GPTQ略低但生态兼容性不如前两者。简单说追求省心和稳定选GGUF追求GPU极致利用可以试GPTQ对精度敏感就研究AWQ。4.2 推理工具选型Ollama、llama.cpp、vLLM怎么选工具选型其实和场景强相关。本地单人用我强烈推荐Ollama安装即用一条命令拉模型显存管理不折腾默认配置对新手友好。它的底层是llama.cpp模型格式统一为GGUF环境变量可以调上下文长度、KV Cache精度等参数灵活性也不算差。llama.cpp本体则适合老手直接操作编译后通过命令行控制自由度更高但需要自己处理模型下载和参数调优。如果你要做服务端吞吐优化那选vLLM它有PagedAttention机制能够把KV Cache按页管理显存利用率显著提升支持高并发、连续批处理。代价是部署步骤复杂、依赖环境要求高。我做本地部署时的选型经验很简单能用Ollama解决的绝不折腾vLLM只有在压测后发现并发吞吐满足不了需求才切换服务化方案。工具本身不复杂复杂的是你非要让它干不擅长的事。4.3 上下文长度与批处理大小的显存规划上下文长度是显存规划里最灵活的旋钮。同样一个模型上下文从4096拉到8192KV Cache立刻翻倍。我见过很多人模型加载成功了但一生成就报错溢出就是因为在启动参数里把上下文长度设得过大忽略了KV Cache随长度线性增长的事实。另一个旋钮是批处理大小。本地单用户推理时批大小通常为1影响不大一旦服务化批大小直接乘以KV Cache开销。比如一个咨询服务的并发请求量为8模型单条请求的KV Cache是1GB那光KV Cache就是8GB。显存规划时必须把这两个参数当成和模型大小同等重要的决策变量。建议在部署初期先把上下文设为2048跑通然后逐步往上调观察显存占用。这是最简单也最不会翻车的做法。5. 常见问题与排查实录5.1 CUDA Out of Memory最经典的显存溢出CUDA Out of MemoryOOM是本地跑模型遇到最多的错误。遇到这种情况先别急着换显卡按顺序排查确认模型加载精度是不是不小心选成了FP16而不是INT4确认上下文长度是否过大长上下文是KV Cache膨胀的根源确认是否并行加载了多个进程很多人挂着WebUI又跑推理脚本显存自然不够确认部署工具的预留缓冲是否过大部分工具默认会给KV Cache分配一个巨大上限实际用不到。我处理过一次典型的OOM24GB卡跑32B模型INT4服务刚启动就报错。排查后发现是工具默认把KV Cache上限设到了可用显存的90%实际根本不需要那么多。手动调低KV Cache预留比例后模型正常加载速度还快了。5.2 显存没满却提示无法分配碎片化的麻烦有时候你会碰到一种奇怪情况看监控显存还剩几个GB但一加载模型就报错。这不是容量不够而是显存碎片化。显存被反复加载、释放不同大小的内存块后剩余空间可能不连续导致无法一次性分配大块内存。这类问题的常规解法是重启推理进程让显存重新整合。长期来看可以调小部署工具的显存缓存上限避免它反复分配大块内存碎片化。在本地调试场景重启就是最好的碎片整理工具。5.3 量化模型效果变差怎么判断还能不能用很多人担心量化后模型变笨。实际上INT4量化对模型能力的影响在大多数任务上体现得没那么明显但敏感任务如代码、数学推理确实可能出现轻微退化。我的验证方法是拿同一段Prompt分别跑FP16和INT4版本对比输出的稳定性和关键细节是否符合预期。如果在业务里对精度非常敏感建议至少保留一份更高精度模型做离线验证生产用INT4或者INT8效果别只看单条输出要看一批测试集上的整体表现。另外不同量化档位之间差异很大Q4_K_M通常比Q2_K好很多如果显存不是极紧张尽量别选太激进的量化档位。5.4 生成速度慢带宽才是真瓶颈模型部署之后生成的每个新Token都需要把模型全部权重读一遍。这意味着推理速度的上限不是算力而是显存带宽。我一台机器跑7B INT4权重约4GB旗舰显卡带宽约1TB/s理论每Token上限是每秒250个Token左右但实测远低于这个数字因为还有KV Cache读写和计算等待。如果速度慢检查一下是否有一部分权重被卸载到了CPU内存。显存不够时工具会自动做CPU offloadCPU和GPU之间交换权重的过程极其拖速度。最好的办法是缩模型或缩上下文保证权重全部驻留显存。写在最后的实操体会跑了这么多配置最大的心得是显存规划不是够不够的问题而是如何取舍的问题。同一个人在不同的上下文需求、并发需求、精度需求下答案可能完全不同。先把权重和KV Cache两笔大账算清楚再去考虑工具调优基本不会踩坑。最后提醒一条小技巧部署工具的显存统计很多时候只显示权重占用不显示预留缓冲和CUDA Context。看显存是否够用别只盯工具自带的统计要看系统级的GPU监控那里显示的数字才是真实的压力值。