显存不够这件事几乎每个跟模型打交道的人都撞过墙。你可能也经历过兴冲冲下载了一个几十GB的开源权重加载到一半程序直接崩掉终端甩出一行冷冰冰的显存溢出报错或者勉强把模型塞进去了一跑推理就卡成幻灯片生成速度慢到怀疑人生。问题的根源往往不在于显卡本身不够强而在于没有提前算清楚这张卡到底能扛多大的模型。显存计算与模型选择说白了就是一套在动手之前先把账算明白的方法论——它决定了你该选哪个尺寸的模型、用什么精度加载、要不要做量化、批处理能开多大。这套东西对刚入门的新手和已经踩过几次坑的老手同样重要因为模型迭代太快每换一个架构、每调一次参数显存账本就得重新算一遍。接下来我会把显存占用的每一块拆开讲透从理论公式到实测验证再到不同显卡档位的选型建议尽量让你看完就能自己动手估算不再靠反复试错来碰运气。1. 显存到底被谁吃掉了很多人以为显存占用就是模型文件大小下载一个14GB的权重觉得16GB显存的卡应该刚好够用。结果一加载就爆。这种误判非常普遍根源在于没有把显存占用的各个组成部分拆开看。实际上模型权重只是显存开销的一部分而且在大 batch 或长上下文场景下它甚至不是最大的一块。1.1 模型权重精度决定基础开销模型权重占用的显存取决于参数数量和每个参数用多少字节来存储。这是最基础的一笔账也是最容易算清楚的一笔。常见的精度格式和它们对应的每参数字节数如下精度格式每参数字节说明FP324 字节全精度训练常用推理很少用FP16 / BF162 字节半精度推理主流选择INT81 字节8位量化精度损失较小INT40.5 字节4位量化精度损失需评估混合量化如Q4_K_M约0.55-0.65字节部分层保持较高精度计算公式很直接权重显存 参数量 × 每参数字节数。举个例子一个70亿参数7B的模型用FP16加载权重占用就是 7 × 10^9 × 2 字节 14GB。如果用INT4量化理论上是 7 × 10^9 × 0.5 3.5GB但实际量化格式往往有额外开销比如分组量化需要存储缩放因子和零点所以实际占用通常在3.8GB到4.2GB之间。这里有个容易忽略的点参数量通常以B为单位1B等于10亿参数。有些模型标注的是7B有些标注的是6.7B差0.3B看起来不多但在FP16下就是0.6GB的差距对于显存紧张的卡来说可能就是能不能跑的区别。注意模型文件在硬盘上的大小和加载到显存后的大小不一定完全一致。比如GGUF格式的量化模型文件大小通常已经接近显存占用但如果是PyTorch的.bin或.safetensors格式加载后还会因为框架的对齐和缓存机制略有膨胀。1.2 激活值与中间张量推理时的动态开销权重加载完之后模型在推理过程中还会产生大量的中间计算结果这些被称为激活值activations或中间张量。它们的大小和输入序列长度、batch size、模型隐藏层维度直接相关。对于Transformer架构的模型激活值显存的大致估算可以用这个思路每一层的激活值大约与batch_size × sequence_length × hidden_size成正比。层数越多、序列越长、batch越大这部分开销就越惊人。具体来说推理时激活值占用的经验公式可以简化为激活显存 ≈ batch_size × seq_len × hidden_size × num_layers × 系数这个系数取决于具体实现通常在2到6之间因为除了隐藏状态本身还有注意力矩阵、前馈网络的中间结果等。以7B模型为例hidden_size通常是4096num_layers是32。如果batch_size1seq_len2048那么激活值大约在 1 × 2048 × 4096 × 32 × 4 ≈ 1GB 到 3GB 之间。如果seq_len拉到8192这部分就会膨胀到4GB到12GB。这就是为什么长上下文场景下显存特别紧张——权重没变但激活值翻了好几倍。1.3 注意力机制的KV Cache长对话的隐形杀手KV Cache是自回归生成过程中缓存键值对的地方它的存在是为了避免每生成一个新token都重新计算之前所有token的注意力。没有KV Cache生成速度会慢到无法接受有了KV Cache显存占用就会随着对话长度线性增长。KV Cache的显存计算公式KV Cache 2 × batch_size × seq_len × num_layers × hidden_size × 精度字节数其中2是因为要缓存Key和Value两个矩阵。还是以7B模型为例hidden_size4096num_layers32FP16精度2字节batch_size1seq_len4096KV Cache 2 × 1 × 4096 × 32 × 4096 × 2 字节 ≈ 2GB如果seq_len拉到32768KV Cache就是16GB。这还没算权重和其他开销。所以很多长上下文模型即使权重不大实际部署时也需要非常大的显存KV Cache是主要瓶颈之一。实操心得如果你的应用场景是长文档问答或多轮对话KV Cache的显存预算一定要单独留出来。我见过不少人用INT4量化把权重压到4GB以内结果对话开到8000token就爆显存问题全出在KV Cache上。1.4 框架与运行时开销不可忽视的零头除了上述三大块深度学习框架本身也会占用一部分显存。CUDA上下文、cuDNN句柄、PyTorch的缓存分配器、通信缓冲区等加起来通常在0.5GB到1.5GB之间。这部分开销相对固定但在小显存卡上就是压死骆驼的最后一根稻草。比如一张8GB的卡权重占了5GB激活值占了1.5GBKV Cache占了0.8GB加起来7.3GB看起来还有0.7GB余量。但框架开销一进来直接爆掉。所以估算时一定要留出至少1GB到1.5GB的安全余量。2. 不同精度与量化方案的显存账本理解了显存被谁吃掉之后下一步就是搞清楚不同精度和量化方案到底能省多少、代价是什么。这部分直接决定了你在有限显存下能跑多大的模型。2.1 FP16与BF16推理的基准线FP16和BF16都是16位浮点数每参数2字节。它们是目前推理场景的主流选择因为大多数模型在训练时就是用这两种精度推理时直接加载不需要额外转换。BF16相比FP16的优势在于数值范围更大不容易出现溢出但精度略低。对于推理来说两者在实际效果上差异很小显存占用完全一样。选择哪个主要看模型训练时用的什么精度以及你的硬件是否原生支持。以常见模型尺寸为例FP16/BF16下的权重显存如下模型参数量FP16/BF16权重显存实际可运行的最低显存建议1.5B3GB4GB3B6GB8GB7B14GB16GB13B26GB32GB34B68GB80GB70B140GB160GB这里的最低显存建议已经包含了激活值、KV Cache和框架开销的粗略预算适用于短序列、小batch的推理场景。如果你的序列长度超过4096或者batch大于1还需要往上加。2.2 INT8量化性价比最高的折中INT8量化把每个参数从2字节压到1字节权重显存直接减半。7B模型从14GB降到7GB13B从26GB降到13GB。这个压缩比非常诱人而且精度损失通常很小在大多数任务上几乎感知不到。INT8量化的实现方式主要有两种一种是训练后量化PTQ直接对训练好的模型做校准和转换另一种是量化感知训练QAT在训练过程中就模拟量化效果。推理场景下PTQ就够用了。实际操作中INT8量化后的模型显存占用大约是FP16的一半再加一点额外开销。比如7B模型INT8后权重约7.5GB加上激活值和KV Cache12GB显存的卡就能比较舒服地跑起来。注意事项INT8量化对某些层特别敏感比如LayerNorm和Softmax通常这些层会保持FP16精度。所以实际压缩比可能略低于理论值但差距不大。2.3 INT4量化小显存的救命稻草INT4量化把每参数压到0.5字节权重显存降到FP16的四分之一。7B模型理论上只要3.5GB实际因为分组量化的开销大约在3.8GB到4.5GB之间。这意味着8GB显存的卡可以轻松跑7B模型甚至12GB的卡可以尝试13B模型。但INT4的代价是精度损失更明显。对于简单对话和摘要任务损失可能不明显但对于需要精确推理、代码生成或数学计算的任务INT4可能会导致明显的质量下降。目前主流的INT4量化方案有GPTQ、AWQ、GGUF等。它们的具体实现不同显存占用和精度表现也有差异量化方案7B模型权重显存特点GPTQ-4bit约3.8GB推理速度快生态成熟AWQ-4bit约3.9GB精度保持较好适合指令模型GGUF Q4_K_M约4.1GB适合CPUGPU混合推理GGUF Q4_0约3.6GB压缩最狠精度损失稍大选择哪种方案取决于你的硬件、推理框架和对精度的要求。如果用的是消费级显卡做本地推理AWQ和GPTQ都是不错的选择如果显存特别紧张或者想用CPU分担一部分GGUF的灵活性更好。2.4 混合精度与分层量化精细控制显存除了整体量化还可以做混合精度——对显存敏感的层用低精度对精度敏感的层用高精度。比如嵌入层和输出层通常参数量大但对精度要求相对低可以用INT4注意力层的投影矩阵可以用INT8LayerNorm保持FP16。这种精细控制需要工具支持比如一些量化框架允许你指定每层的精度。好处是在相同显存预算下获得更好的效果代价是配置复杂度上升需要做一些实验来找到最佳组合。3. 从显存反推模型选型实战计算方法理论讲完了现在进入最实用的部分给定一张显卡怎么快速算出它能跑多大的模型。我总结了一套三步走的估算流程实测下来误差通常在10%到20%之间足够做选型决策了。3.1 第一步确定可用显存预算首先要知道你的显卡实际可用显存是多少。标注的显存和实际可用的之间有差距因为系统、驱动和显示输出会占用一部分。显卡标注显存实际可用显存无显示输出实际可用显存有显示输出8GB约7.2GB约6.5GB12GB约11GB约10GB16GB约15GB约14GB24GB约23GB约22GB48GB约47GB约46GB如果是多卡并行可用显存不是简单相加因为张量并行会有通信开销和冗余存储。通常两张卡并行时有效显存是单卡的1.7到1.8倍而不是2倍。3.2 第二步扣除固定开销从可用显存中扣除框架开销和KV Cache预算。框架开销按1GB到1.5GB算KV Cache根据你的目标序列长度来定。KV Cache的快速估算方法每1K token的KV Cache大约占用2 × num_layers × hidden_size × 2字节 / 10^9GB。对于7B模型32层4096隐藏维度每1K token约0.5GB。如果你要支持8K上下文就要留4GB给KV Cache。实操心得如果你不确定序列长度可以按目标场景的P95长度来算再留20%余量。比如聊天场景大部分对话在2K以内偶尔到4K那就按4K算KV Cache。3.3 第三步反推最大模型参数量剩余显存除以每参数字节数就是能承载的最大参数量。最大参数量 (可用显存 - 框架开销 - KV Cache预算) / 每参数字节数举个例子一张12GB的卡实际可用11GB框架开销1GB目标序列4K的KV Cache约2GB7B模型剩余8GB给权重。如果用INT4量化0.5字节/参数最大参数量 8GB / 0.5字节 ≈ 16B。也就是说12GB的卡用INT4可以跑13B模型但跑不了34B。如果用INT81字节/参数最大参数量 8B只能跑7B模型。如果用FP162字节/参数最大参数量 4B只能跑3B模型。这个计算过程可以整理成一张速查表显卡显存FP16最大模型INT8最大模型INT4最大模型8GB1.5B-3B3B-7B7B-13B12GB3B-7B7B-13B13B-20B16GB7B13B20B-34B24GB13B20B-34B34B-70B勉强48GB34B70B70B这里的范围考虑了不同序列长度和batch size的影响。短序列小batch取上限长序列大batch取下限。3.4 实测验证用工具快速确认理论算完之后最好用实际工具验证一下。有几个方法可以快速确认模型能不能跑第一种是用推理框架自带的显存估算功能。比如一些主流的推理框架在加载模型时会打印显存占用日志你可以先用小序列长度加载看实际占用多少再推算长序列下的表现。第二种是用nvidia-smi实时监控。加载模型后跑一个短序列推理观察显存峰值。然后逐步增加序列长度看显存增长曲线是否符合预期。第三种是直接用量化工具做一次转换看输出模型的元数据里标注的显存需求。很多量化工具会在模型卡片里写明推荐显存。注意实测时一定要跑真实场景的输入长度不要只用短序列测试。我见过太多人用128token测试没问题上线后用户输入2000token直接爆显存。4. 不同场景下的模型选择策略显存算清楚了接下来就是根据具体场景做选择。不同应用对模型大小、精度、速度的要求差异很大不能一概而论。4.1 本地对话助手7B-13B是甜点区如果你是想在自己的电脑上跑一个对话助手日常问答、写邮件、整理笔记7B到13B的模型在INT4量化下已经能提供相当不错的体验。这个尺寸的模型在消费级显卡上推理速度可以接受首token延迟通常在1秒以内生成速度在20-50 token/秒之间。具体选择上8GB显存的卡建议选7B INT412GB的卡可以上13B INT416GB的卡可以跑13B INT8或者7B FP16。如果追求更好的效果20B左右的模型在24GB卡上用INT4也能跑但速度会慢一些。4.2 代码生成与补全精度比尺寸更重要代码任务对模型的精确性要求很高INT4量化在代码生成上可能会出现明显的质量下降比如生成不存在的API、语法错误增多。所以代码场景下宁可选小一点但精度高的模型也不要选大而量化狠的。7B模型在INT8或FP16下的代码能力往往优于13B模型在INT4下的表现。如果显存允许代码场景优先考虑FP16或INT8。16GB的卡跑7B FP16是比较稳妥的选择24GB的卡可以跑13B INT8。4.3 长文档处理KV Cache是主要矛盾处理长文档时序列长度可能达到16K甚至32KKV Cache的显存占用会超过权重本身。这种情况下选择模型时要优先考虑KV Cache优化技术比如分组查询注意力GQA、多查询注意力MQA等。GQA可以把KV Cache减少到原来的1/4到1/8。同样7B模型普通多头注意力在32K序列下KV Cache要16GB用GQA可能只要2GB到4GB。所以长文档场景下模型是否支持GQA比参数量更重要。4.4 批量推理服务吞吐量与显存的平衡如果是做批量推理服务比如同时处理多个用户请求batch size会显著增加激活值和KV Cache的占用。这时候需要做吞吐量和显存的权衡。大batch能提高GPU利用率但显存占用线性增长。通常建议把batch size控制在显存预算的70%到80%留出余量应对突发流量。如果显存不够可以考虑动态批处理——把多个短请求合并成一个batch而不是固定大batch。5. 常见问题与排查技巧实录实际部署中遇到的问题往往比理论计算复杂得多。这里整理了一些典型问题和排查思路都是我在实践中反复遇到的。5.1 加载成功但推理时爆显存这是最常见的情况。模型权重加载没问题但一跑推理就报显存不足。原因通常是激活值或KV Cache超出了预期。排查步骤先用最小输入比如1个token跑一次确认基础显存占用。然后逐步增加输入长度观察显存在哪个长度开始飙升。如果显存增长曲线在某个点突然变陡可能是注意力机制的实现有问题比如没有正确使用KV Cache或者注意力矩阵没有分块计算。解决方法降低batch size、缩短序列长度、启用量化KV Cache、或者换用支持Flash Attention的推理框架。5.2 量化后效果明显变差量化后模型变笨了回答质量下降这是INT4常见的副作用。排查时先确认是不是所有层都量化了——有些敏感层应该保持高精度。解决方法尝试不同的量化方案GPTQ换AWQ或者换GGUF的不同量化等级或者做混合量化把嵌入层和输出层保持FP16。另外量化时的校准数据集也很关键用与目标任务分布接近的数据做校准效果会好很多。5.3 多卡并行显存没有翻倍两张24GB的卡理论上应该有48GB可用但实际能跑的模型远小于单卡24GB的两倍。这是因为张量并行需要存储冗余的权重副本而且卡间通信需要额外的缓冲区。排查时看nvidia-smi如果两张卡的显存占用不均衡可能是并行策略配置有问题。解决方法调整张量并行的切分方式或者改用流水线并行。对于推理场景如果模型能单卡放下尽量不要多卡因为通信开销会拖慢速度。5.4 显存碎片导致无法分配有时候显存总量够但因为碎片化无法分配出连续的大块显存。这种情况在长时间运行的服务中特别常见。排查方法观察nvidia-smi的显存占用是否持续增长但不释放。解决方法设置PyTorch的PYTORCH_CUDA_ALLOC_CONF环境变量启用expandable_segments来减少碎片。或者定期重启推理服务释放碎片。问题现象可能原因排查方法解决方向加载成功推理爆显存激活值/KV Cache超预期逐步增加序列长度观察降batch、缩序列、量化KV量化后质量下降敏感层被量化对比不同量化方案混合量化、换校准集多卡显存不翻倍冗余存储和通信开销看各卡占用是否均衡调整并行策略显存碎片长时间运行未释放观察显存是否持续增长启用expandable_segments首token延迟高权重加载慢或计算量大测加载时间和首token时间用更小模型或更快框架实操心得显存问题排查最重要的是养成记录习惯。每次部署时把模型大小、量化方案、序列长度、batch size、实际显存峰值记下来积累多了就能形成直觉新模型一看参数就能估个八九不离十。6. 工具链与实操建议工欲善其事必先利其器。显存计算和模型选择涉及不少工具选对了能省很多时间。6.1 显存估算工具有一些在线工具和脚本可以根据模型配置和输入参数估算显存需求。比如HuggingFace的模型页面通常会标注推荐显存一些量化工具的文档里也有详细的显存对照表。自己写一个估算脚本也不难核心就是前面讲的公式。把模型配置层数、隐藏维度、注意力头数和推理参数序列长度、batch size、精度作为输入输出各部分的显存占用和总计。这种脚本一次写好后面换模型只需要改配置。6.2 量化工具选择GPTQ和AWQ是目前最主流的两种量化方案。GPTQ生态更成熟支持的模型更多AWQ在指令模型上精度保持更好。GGUF适合需要CPUGPU混合推理的场景灵活性最高。选择时考虑三点你的推理框架支持哪种格式、你的任务对精度要求多高、你的硬件是什么。如果用的是主流推理框架通常GPTQ和AWQ都有支持如果显存特别紧张需要CPU分担GGUF是唯一选择。6.3 推理框架的显存优化不同推理框架的显存效率差异很大。一些框架支持PagedAttention来减少KV Cache碎片一些支持连续批处理来提高吞吐量还有一些支持投机解码来加速生成。选择框架时除了看功能还要看它对你目标模型的优化程度。有些框架对特定模型架构做了深度优化显存占用和速度都明显优于通用框架。6.4 监控与调优部署后要持续监控显存使用情况。除了nvidia-smi还可以用框架自带的监控指标比如每秒处理的token数、显存峰值、KV Cache命中率等。调优时优先调整对显存影响最大的参数序列长度和batch size。这两个参数对显存的影响是线性的降一半就能省一半。其次是量化方案从FP16换到INT8能省一半权重显存换到INT4再省一半。我个人在实际操作中的体会是显存计算这件事理论公式给你一个起点但真正的经验来自反复实测。同一个模型在不同框架、不同驱动版本、不同输入分布下显存表现可能差很多。所以我的习惯是新模型先用小序列跑通记录基础占用然后逐步加压到目标场景观察显存曲线。这个过程虽然花时间但比上线后爆显存再回头排查要划算得多。另外不要迷信推荐显存这个数字它通常是在理想条件下的估算实际部署时留出20%到30%的余量会更稳妥。 
长河君 · 2026/10/12 19:14:39 · 阅读 1.2k 大模型显存计算与模型选型实战指南
显存不够这件事几乎每个跟模型打交道的人都撞过墙。你可能也经历过兴冲冲下载了一个几十GB的开源权重加载到一半程序直接崩掉终端甩出一行冷冰冰的显存溢出报错或者勉强把模型塞进去了一跑推理就卡成幻灯片生成速度慢到怀疑人生。问题的根源往往不在于显卡本身不够强而在于没有提前算清楚这张卡到底能扛多大的模型。显存计算与模型选择说白了就是一套在动手之前先把账算明白的方法论——它决定了你该选哪个尺寸的模型、用什么精度加载、要不要做量化、批处理能开多大。这套东西对刚入门的新手和已经踩过几次坑的老手同样重要因为模型迭代太快每换一个架构、每调一次参数显存账本就得重新算一遍。接下来我会把显存占用的每一块拆开讲透从理论公式到实测验证再到不同显卡档位的选型建议尽量让你看完就能自己动手估算不再靠反复试错来碰运气。1. 显存到底被谁吃掉了很多人以为显存占用就是模型文件大小下载一个14GB的权重觉得16GB显存的卡应该刚好够用。结果一加载就爆。这种误判非常普遍根源在于没有把显存占用的各个组成部分拆开看。实际上模型权重只是显存开销的一部分而且在大 batch 或长上下文场景下它甚至不是最大的一块。1.1 模型权重精度决定基础开销模型权重占用的显存取决于参数数量和每个参数用多少字节来存储。这是最基础的一笔账也是最容易算清楚的一笔。常见的精度格式和它们对应的每参数字节数如下精度格式每参数字节说明FP324 字节全精度训练常用推理很少用FP16 / BF162 字节半精度推理主流选择INT81 字节8位量化精度损失较小INT40.5 字节4位量化精度损失需评估混合量化如Q4_K_M约0.55-0.65字节部分层保持较高精度计算公式很直接权重显存 参数量 × 每参数字节数。举个例子一个70亿参数7B的模型用FP16加载权重占用就是 7 × 10^9 × 2 字节 14GB。如果用INT4量化理论上是 7 × 10^9 × 0.5 3.5GB但实际量化格式往往有额外开销比如分组量化需要存储缩放因子和零点所以实际占用通常在3.8GB到4.2GB之间。这里有个容易忽略的点参数量通常以B为单位1B等于10亿参数。有些模型标注的是7B有些标注的是6.7B差0.3B看起来不多但在FP16下就是0.6GB的差距对于显存紧张的卡来说可能就是能不能跑的区别。注意模型文件在硬盘上的大小和加载到显存后的大小不一定完全一致。比如GGUF格式的量化模型文件大小通常已经接近显存占用但如果是PyTorch的.bin或.safetensors格式加载后还会因为框架的对齐和缓存机制略有膨胀。1.2 激活值与中间张量推理时的动态开销权重加载完之后模型在推理过程中还会产生大量的中间计算结果这些被称为激活值activations或中间张量。它们的大小和输入序列长度、batch size、模型隐藏层维度直接相关。对于Transformer架构的模型激活值显存的大致估算可以用这个思路每一层的激活值大约与batch_size × sequence_length × hidden_size成正比。层数越多、序列越长、batch越大这部分开销就越惊人。具体来说推理时激活值占用的经验公式可以简化为激活显存 ≈ batch_size × seq_len × hidden_size × num_layers × 系数这个系数取决于具体实现通常在2到6之间因为除了隐藏状态本身还有注意力矩阵、前馈网络的中间结果等。以7B模型为例hidden_size通常是4096num_layers是32。如果batch_size1seq_len2048那么激活值大约在 1 × 2048 × 4096 × 32 × 4 ≈ 1GB 到 3GB 之间。如果seq_len拉到8192这部分就会膨胀到4GB到12GB。这就是为什么长上下文场景下显存特别紧张——权重没变但激活值翻了好几倍。1.3 注意力机制的KV Cache长对话的隐形杀手KV Cache是自回归生成过程中缓存键值对的地方它的存在是为了避免每生成一个新token都重新计算之前所有token的注意力。没有KV Cache生成速度会慢到无法接受有了KV Cache显存占用就会随着对话长度线性增长。KV Cache的显存计算公式KV Cache 2 × batch_size × seq_len × num_layers × hidden_size × 精度字节数其中2是因为要缓存Key和Value两个矩阵。还是以7B模型为例hidden_size4096num_layers32FP16精度2字节batch_size1seq_len4096KV Cache 2 × 1 × 4096 × 32 × 4096 × 2 字节 ≈ 2GB如果seq_len拉到32768KV Cache就是16GB。这还没算权重和其他开销。所以很多长上下文模型即使权重不大实际部署时也需要非常大的显存KV Cache是主要瓶颈之一。实操心得如果你的应用场景是长文档问答或多轮对话KV Cache的显存预算一定要单独留出来。我见过不少人用INT4量化把权重压到4GB以内结果对话开到8000token就爆显存问题全出在KV Cache上。1.4 框架与运行时开销不可忽视的零头除了上述三大块深度学习框架本身也会占用一部分显存。CUDA上下文、cuDNN句柄、PyTorch的缓存分配器、通信缓冲区等加起来通常在0.5GB到1.5GB之间。这部分开销相对固定但在小显存卡上就是压死骆驼的最后一根稻草。比如一张8GB的卡权重占了5GB激活值占了1.5GBKV Cache占了0.8GB加起来7.3GB看起来还有0.7GB余量。但框架开销一进来直接爆掉。所以估算时一定要留出至少1GB到1.5GB的安全余量。2. 不同精度与量化方案的显存账本理解了显存被谁吃掉之后下一步就是搞清楚不同精度和量化方案到底能省多少、代价是什么。这部分直接决定了你在有限显存下能跑多大的模型。2.1 FP16与BF16推理的基准线FP16和BF16都是16位浮点数每参数2字节。它们是目前推理场景的主流选择因为大多数模型在训练时就是用这两种精度推理时直接加载不需要额外转换。BF16相比FP16的优势在于数值范围更大不容易出现溢出但精度略低。对于推理来说两者在实际效果上差异很小显存占用完全一样。选择哪个主要看模型训练时用的什么精度以及你的硬件是否原生支持。以常见模型尺寸为例FP16/BF16下的权重显存如下模型参数量FP16/BF16权重显存实际可运行的最低显存建议1.5B3GB4GB3B6GB8GB7B14GB16GB13B26GB32GB34B68GB80GB70B140GB160GB这里的最低显存建议已经包含了激活值、KV Cache和框架开销的粗略预算适用于短序列、小batch的推理场景。如果你的序列长度超过4096或者batch大于1还需要往上加。2.2 INT8量化性价比最高的折中INT8量化把每个参数从2字节压到1字节权重显存直接减半。7B模型从14GB降到7GB13B从26GB降到13GB。这个压缩比非常诱人而且精度损失通常很小在大多数任务上几乎感知不到。INT8量化的实现方式主要有两种一种是训练后量化PTQ直接对训练好的模型做校准和转换另一种是量化感知训练QAT在训练过程中就模拟量化效果。推理场景下PTQ就够用了。实际操作中INT8量化后的模型显存占用大约是FP16的一半再加一点额外开销。比如7B模型INT8后权重约7.5GB加上激活值和KV Cache12GB显存的卡就能比较舒服地跑起来。注意事项INT8量化对某些层特别敏感比如LayerNorm和Softmax通常这些层会保持FP16精度。所以实际压缩比可能略低于理论值但差距不大。2.3 INT4量化小显存的救命稻草INT4量化把每参数压到0.5字节权重显存降到FP16的四分之一。7B模型理论上只要3.5GB实际因为分组量化的开销大约在3.8GB到4.5GB之间。这意味着8GB显存的卡可以轻松跑7B模型甚至12GB的卡可以尝试13B模型。但INT4的代价是精度损失更明显。对于简单对话和摘要任务损失可能不明显但对于需要精确推理、代码生成或数学计算的任务INT4可能会导致明显的质量下降。目前主流的INT4量化方案有GPTQ、AWQ、GGUF等。它们的具体实现不同显存占用和精度表现也有差异量化方案7B模型权重显存特点GPTQ-4bit约3.8GB推理速度快生态成熟AWQ-4bit约3.9GB精度保持较好适合指令模型GGUF Q4_K_M约4.1GB适合CPUGPU混合推理GGUF Q4_0约3.6GB压缩最狠精度损失稍大选择哪种方案取决于你的硬件、推理框架和对精度的要求。如果用的是消费级显卡做本地推理AWQ和GPTQ都是不错的选择如果显存特别紧张或者想用CPU分担一部分GGUF的灵活性更好。2.4 混合精度与分层量化精细控制显存除了整体量化还可以做混合精度——对显存敏感的层用低精度对精度敏感的层用高精度。比如嵌入层和输出层通常参数量大但对精度要求相对低可以用INT4注意力层的投影矩阵可以用INT8LayerNorm保持FP16。这种精细控制需要工具支持比如一些量化框架允许你指定每层的精度。好处是在相同显存预算下获得更好的效果代价是配置复杂度上升需要做一些实验来找到最佳组合。3. 从显存反推模型选型实战计算方法理论讲完了现在进入最实用的部分给定一张显卡怎么快速算出它能跑多大的模型。我总结了一套三步走的估算流程实测下来误差通常在10%到20%之间足够做选型决策了。3.1 第一步确定可用显存预算首先要知道你的显卡实际可用显存是多少。标注的显存和实际可用的之间有差距因为系统、驱动和显示输出会占用一部分。显卡标注显存实际可用显存无显示输出实际可用显存有显示输出8GB约7.2GB约6.5GB12GB约11GB约10GB16GB约15GB约14GB24GB约23GB约22GB48GB约47GB约46GB如果是多卡并行可用显存不是简单相加因为张量并行会有通信开销和冗余存储。通常两张卡并行时有效显存是单卡的1.7到1.8倍而不是2倍。3.2 第二步扣除固定开销从可用显存中扣除框架开销和KV Cache预算。框架开销按1GB到1.5GB算KV Cache根据你的目标序列长度来定。KV Cache的快速估算方法每1K token的KV Cache大约占用2 × num_layers × hidden_size × 2字节 / 10^9GB。对于7B模型32层4096隐藏维度每1K token约0.5GB。如果你要支持8K上下文就要留4GB给KV Cache。实操心得如果你不确定序列长度可以按目标场景的P95长度来算再留20%余量。比如聊天场景大部分对话在2K以内偶尔到4K那就按4K算KV Cache。3.3 第三步反推最大模型参数量剩余显存除以每参数字节数就是能承载的最大参数量。最大参数量 (可用显存 - 框架开销 - KV Cache预算) / 每参数字节数举个例子一张12GB的卡实际可用11GB框架开销1GB目标序列4K的KV Cache约2GB7B模型剩余8GB给权重。如果用INT4量化0.5字节/参数最大参数量 8GB / 0.5字节 ≈ 16B。也就是说12GB的卡用INT4可以跑13B模型但跑不了34B。如果用INT81字节/参数最大参数量 8B只能跑7B模型。如果用FP162字节/参数最大参数量 4B只能跑3B模型。这个计算过程可以整理成一张速查表显卡显存FP16最大模型INT8最大模型INT4最大模型8GB1.5B-3B3B-7B7B-13B12GB3B-7B7B-13B13B-20B16GB7B13B20B-34B24GB13B20B-34B34B-70B勉强48GB34B70B70B这里的范围考虑了不同序列长度和batch size的影响。短序列小batch取上限长序列大batch取下限。3.4 实测验证用工具快速确认理论算完之后最好用实际工具验证一下。有几个方法可以快速确认模型能不能跑第一种是用推理框架自带的显存估算功能。比如一些主流的推理框架在加载模型时会打印显存占用日志你可以先用小序列长度加载看实际占用多少再推算长序列下的表现。第二种是用nvidia-smi实时监控。加载模型后跑一个短序列推理观察显存峰值。然后逐步增加序列长度看显存增长曲线是否符合预期。第三种是直接用量化工具做一次转换看输出模型的元数据里标注的显存需求。很多量化工具会在模型卡片里写明推荐显存。注意实测时一定要跑真实场景的输入长度不要只用短序列测试。我见过太多人用128token测试没问题上线后用户输入2000token直接爆显存。4. 不同场景下的模型选择策略显存算清楚了接下来就是根据具体场景做选择。不同应用对模型大小、精度、速度的要求差异很大不能一概而论。4.1 本地对话助手7B-13B是甜点区如果你是想在自己的电脑上跑一个对话助手日常问答、写邮件、整理笔记7B到13B的模型在INT4量化下已经能提供相当不错的体验。这个尺寸的模型在消费级显卡上推理速度可以接受首token延迟通常在1秒以内生成速度在20-50 token/秒之间。具体选择上8GB显存的卡建议选7B INT412GB的卡可以上13B INT416GB的卡可以跑13B INT8或者7B FP16。如果追求更好的效果20B左右的模型在24GB卡上用INT4也能跑但速度会慢一些。4.2 代码生成与补全精度比尺寸更重要代码任务对模型的精确性要求很高INT4量化在代码生成上可能会出现明显的质量下降比如生成不存在的API、语法错误增多。所以代码场景下宁可选小一点但精度高的模型也不要选大而量化狠的。7B模型在INT8或FP16下的代码能力往往优于13B模型在INT4下的表现。如果显存允许代码场景优先考虑FP16或INT8。16GB的卡跑7B FP16是比较稳妥的选择24GB的卡可以跑13B INT8。4.3 长文档处理KV Cache是主要矛盾处理长文档时序列长度可能达到16K甚至32KKV Cache的显存占用会超过权重本身。这种情况下选择模型时要优先考虑KV Cache优化技术比如分组查询注意力GQA、多查询注意力MQA等。GQA可以把KV Cache减少到原来的1/4到1/8。同样7B模型普通多头注意力在32K序列下KV Cache要16GB用GQA可能只要2GB到4GB。所以长文档场景下模型是否支持GQA比参数量更重要。4.4 批量推理服务吞吐量与显存的平衡如果是做批量推理服务比如同时处理多个用户请求batch size会显著增加激活值和KV Cache的占用。这时候需要做吞吐量和显存的权衡。大batch能提高GPU利用率但显存占用线性增长。通常建议把batch size控制在显存预算的70%到80%留出余量应对突发流量。如果显存不够可以考虑动态批处理——把多个短请求合并成一个batch而不是固定大batch。5. 常见问题与排查技巧实录实际部署中遇到的问题往往比理论计算复杂得多。这里整理了一些典型问题和排查思路都是我在实践中反复遇到的。5.1 加载成功但推理时爆显存这是最常见的情况。模型权重加载没问题但一跑推理就报显存不足。原因通常是激活值或KV Cache超出了预期。排查步骤先用最小输入比如1个token跑一次确认基础显存占用。然后逐步增加输入长度观察显存在哪个长度开始飙升。如果显存增长曲线在某个点突然变陡可能是注意力机制的实现有问题比如没有正确使用KV Cache或者注意力矩阵没有分块计算。解决方法降低batch size、缩短序列长度、启用量化KV Cache、或者换用支持Flash Attention的推理框架。5.2 量化后效果明显变差量化后模型变笨了回答质量下降这是INT4常见的副作用。排查时先确认是不是所有层都量化了——有些敏感层应该保持高精度。解决方法尝试不同的量化方案GPTQ换AWQ或者换GGUF的不同量化等级或者做混合量化把嵌入层和输出层保持FP16。另外量化时的校准数据集也很关键用与目标任务分布接近的数据做校准效果会好很多。5.3 多卡并行显存没有翻倍两张24GB的卡理论上应该有48GB可用但实际能跑的模型远小于单卡24GB的两倍。这是因为张量并行需要存储冗余的权重副本而且卡间通信需要额外的缓冲区。排查时看nvidia-smi如果两张卡的显存占用不均衡可能是并行策略配置有问题。解决方法调整张量并行的切分方式或者改用流水线并行。对于推理场景如果模型能单卡放下尽量不要多卡因为通信开销会拖慢速度。5.4 显存碎片导致无法分配有时候显存总量够但因为碎片化无法分配出连续的大块显存。这种情况在长时间运行的服务中特别常见。排查方法观察nvidia-smi的显存占用是否持续增长但不释放。解决方法设置PyTorch的PYTORCH_CUDA_ALLOC_CONF环境变量启用expandable_segments来减少碎片。或者定期重启推理服务释放碎片。问题现象可能原因排查方法解决方向加载成功推理爆显存激活值/KV Cache超预期逐步增加序列长度观察降batch、缩序列、量化KV量化后质量下降敏感层被量化对比不同量化方案混合量化、换校准集多卡显存不翻倍冗余存储和通信开销看各卡占用是否均衡调整并行策略显存碎片长时间运行未释放观察显存是否持续增长启用expandable_segments首token延迟高权重加载慢或计算量大测加载时间和首token时间用更小模型或更快框架实操心得显存问题排查最重要的是养成记录习惯。每次部署时把模型大小、量化方案、序列长度、batch size、实际显存峰值记下来积累多了就能形成直觉新模型一看参数就能估个八九不离十。6. 工具链与实操建议工欲善其事必先利其器。显存计算和模型选择涉及不少工具选对了能省很多时间。6.1 显存估算工具有一些在线工具和脚本可以根据模型配置和输入参数估算显存需求。比如HuggingFace的模型页面通常会标注推荐显存一些量化工具的文档里也有详细的显存对照表。自己写一个估算脚本也不难核心就是前面讲的公式。把模型配置层数、隐藏维度、注意力头数和推理参数序列长度、batch size、精度作为输入输出各部分的显存占用和总计。这种脚本一次写好后面换模型只需要改配置。6.2 量化工具选择GPTQ和AWQ是目前最主流的两种量化方案。GPTQ生态更成熟支持的模型更多AWQ在指令模型上精度保持更好。GGUF适合需要CPUGPU混合推理的场景灵活性最高。选择时考虑三点你的推理框架支持哪种格式、你的任务对精度要求多高、你的硬件是什么。如果用的是主流推理框架通常GPTQ和AWQ都有支持如果显存特别紧张需要CPU分担GGUF是唯一选择。6.3 推理框架的显存优化不同推理框架的显存效率差异很大。一些框架支持PagedAttention来减少KV Cache碎片一些支持连续批处理来提高吞吐量还有一些支持投机解码来加速生成。选择框架时除了看功能还要看它对你目标模型的优化程度。有些框架对特定模型架构做了深度优化显存占用和速度都明显优于通用框架。6.4 监控与调优部署后要持续监控显存使用情况。除了nvidia-smi还可以用框架自带的监控指标比如每秒处理的token数、显存峰值、KV Cache命中率等。调优时优先调整对显存影响最大的参数序列长度和batch size。这两个参数对显存的影响是线性的降一半就能省一半。其次是量化方案从FP16换到INT8能省一半权重显存换到INT4再省一半。我个人在实际操作中的体会是显存计算这件事理论公式给你一个起点但真正的经验来自反复实测。同一个模型在不同框架、不同驱动版本、不同输入分布下显存表现可能差很多。所以我的习惯是新模型先用小序列跑通记录基础占用然后逐步加压到目标场景观察显存曲线。这个过程虽然花时间但比上线后爆显存再回头排查要划算得多。另外不要迷信推荐显存这个数字它通常是在理想条件下的估算实际部署时留出20%到30%的余量会更稳妥。