开源模型显存需求对比：7B/13B/70B要多少显存？一张表帮你少花冤枉钱

我常被问“跑一个7B、13B、70B开源模型到底要多少显存”。这个问题没有统一答案，显存占用受很多变量影响。我习惯先搭一个评估框架，把显存拆成几块，再看变量如何放大或缩小。这样做开源模型显存需求对比时，不同模型、不同量化、不同场景的数字才有统一参照，不容易被一张截图带偏。

1.1 显存需求的核心构成：模型权重、KV Cache、激活值、框架与运行时开销

我拆显存时先看模型权重。权重是模型参数按精度位宽占用的显存。FP16下每个参数2字节，7B约14GB，13B约26GB，70B约140GB。这个数很硬，量化会改。权重之外有KV Cache，我做推理时感受很深。上下文越长、并发越高，KV Cache涨得很快，有时比权重更吃卡。KV Cache和层数、头数、头维度、序列长度、批大小相关。7B模型在长上下文高并发下，KV Cache可能到几十GB。

激活值是前向传播中间结果。推理时激活值不大，训练和微调时明显。批大小、序列长度、是否梯度检查点都会影响。框架与运行时开销常被忽略。CUDA上下文、PyTorch缓存分配器、推理框架的预分配、通信缓冲区、日志和监控进程都占显存。我实测时见过权重14GB的7B模型，nvidia-smi显示18GB往上。差额来自运行时和缓存。做显存对比要把这部分列进去，不然理论值和实测值对不上。

1.2 影响显存占用的关键因素：参数量、精度位宽、量化方案、上下文长度、批大小与并发数

参数量是最直观变量。7B到13B接近翻倍，13B到70B五倍多。权重显存按参数量线性走。精度位宽也直接。FP32每参数4字节，FP16/BF16每参数2字节，INT8每参数1字节，INT4每参数0.5字节。量化方案不只看位宽。GPTQ、AWQ、GGUF、QLoRA有不同分组、缩放因子、内核开销。我对比时会把有效位宽和额外开销一起算。上下文长度、批大小和并发数影响KV Cache。KV Cache随序列长度线性增长，随并发数线性增长。长上下文加高并发能把显存需求推高一个档。

我遇到过一种情况，同一模型同样量化，单请求短上下文能跑在24GB卡上，开到8路并发和8K上下文就爆显存。变量不在权重，在KV Cache和激活值。批大小对训练影响更大。全参微调时优化器状态、梯度、激活值会叠加。LoRA和QLoRA会改变显存构成。我做选型会把参数量、位宽、量化方案、上下文、批大小、并发数做成一张表，逐项调。这样对比不同模型的显存需求更接近真实。

1.3 对比口径统一：推理与训练、单卡与多卡、理论估算与实测占用

显存对比最容易乱在口径。推理和训练不是一回事。推理主要看权重、KV Cache、运行时开销。训练要看权重、梯度、优化器状态、激活值。全参微调7B模型用FP16，权重14GB，梯度14GB，Adam优化器状态可能56GB，激活值另算。单卡和多卡也不一样。多卡并行有张量并行、流水并行、数据并行。每张卡显存占用不同，通信缓冲区也占。我对比时会标明场景和卡数，不把单卡推理数字和多卡训练数字混在一起。

理论估算和实测占用要分开写。理论估算按公式算权重和KV Cache。实测用nvidia-smi或框架统计。实测常高于理论。PyTorch缓存分配器会保留显存，vLLM会预分配KV Cache块。我一般给两个数：理论下限和实测建议。理论下限帮判断能不能加载，实测建议帮判断能不能稳定跑。对比表里写清口径，读者才不会被不同来源的数字带偏。

1.4 显存需求对比的指标体系：最低显存、推荐显存、吞吐、延迟与成本

我看显存需求不只看一个数。最低显存是模型能加载并完成一次推理的下限。推荐显存是留出上下文、并发和运行时余量后的配置。吞吐和延迟要一起看。显存省了，吞吐可能掉，延迟可能升。量化到INT4能降权重显存，解码速度有时升有时降。我评估时会跑固定输入输出长度，记录tokens/s和P99延迟。成本也要算进去。一张24GB卡和一张80GB卡的单位token成本不同。显存需求对比要落到业务可用性。

我的指标表里放最低显存、推荐显存、最大并发、吞吐、延迟、硬件成本和每百万token成本。不同业务权重不同。在线客服看延迟和并发，离线批处理看吞吐和成本。开源模型显存需求对比不是比谁数字小，是比在目标场景下谁更合适。我把这套框架用在7B、13B、70B模型上，后面再看量化、推理训练差异和实测方法，数字就有统一参照。

我常把7B、13B、70B三档开源模型放在一张表里看。它们像三个台阶，参数量跨一步，显存和硬件选择就换一套思路。做开源大模型显存需求对比时，我会先把权重显存算清楚，再把KV Cache、运行时开销和部署方式叠上去。这样得到的数字能指导选卡，也能减少“理论能跑、实测爆显存”的尴尬。

2.1 FP32、FP16与BF16精度下的基准显存估算方法

我算权重显存常用一个简单公式：参数量 × 位宽 ÷ 8。FP32每个参数4字节，FP16和BF16每个参数2字节。7B模型FP32约28GB，FP16/BF16约14GB；13B模型FP32约52GB，FP16/BF16约26GB；70B模型FP32约280GB，FP16/BF16约140GB。这个结果是理论权重下限，实际部署还要加运行时开销。我一般再留10%到20%的余量，CUDA上下文、框架缓存、通信缓冲区都会吃显存。

FP16和BF16显存占用一样，差别在数值范围和硬件支持。我做推理时更关注显卡对BF16的原生支持，老卡跑BF16可能回退或变慢。FP32适合精度验证和小模型调试，7B跑FP32要28GB权重，24GB卡放不下。13B和70B跑FP32更偏向实验环境，生产推理很少这样配。开源模型显存需求对比里，精度位宽是最直接的乘数，先把这一层算准，后面的KV Cache和并发才有讨论基础。

KV Cache也要进基准估算。我常用近似公式：2 × 层数 × KV头数 × 头维度 × 序列长度 × 批大小 × 字节数。7B模型FP16下每token约0.5MB，8K上下文单请求约4GB；13B每token约0.8MB，8K约6.4GB；70B用GQA结构时每token约0.32MB，8K约2.5GB。模型结构不同，KV Cache差别很大，70B用MHA结构时8K单请求能到20GB。我做对比表会标明模型结构和上下文长度，不把不同结构的KV数字直接混在一起。

2.2 7B开源模型显存需求、部署门槛与典型应用场景

7B模型是很多人接触开源大模型的第一站。FP16权重约14GB，加运行时开销，24GB卡跑短上下文比较稳。16GB卡能加载，上下文和并发要收着用。8GB卡基本要走INT4量化，上下文别开太大。我实测7B FP16在24GB卡上，nvidia-smi常显示18GB到20GB，权重之外的部分来自框架预分配和KV Cache。这个数字对部署很关键，只看14GB容易把卡配小。

7B的部署门槛低，应用场景很宽。在线客服、内容摘要、文本分类、轻量RAG、边缘设备原型，7B都能先跑起来。它适合高并发、低延迟、成本敏感的业务。24GB卡可以跑4K上下文加少量并发，8K上下文加8路并发就要算KV Cache。7B FP16下8K单请求约4GB，8路就是32GB，24GB卡扛不住。我会把并发和上下文一起压测，再决定卡型和量化等级。

从成本角度看，7B单卡试错成本低，适合快速验证业务闭环。一张24GB卡能覆盖原型和小流量生产，扩容也简单。7B的效果在复杂推理和长文任务上有边界，业务对答案质量要求高时，我会拿13B做对照。7B开源模型显存需求不算高，难点在并发和上下文管理。把这两项控制住，7B的性价比很突出。

2.3 13B开源模型显存需求、性能成本平衡与适用边界

13B模型卡在7B和70B中间，显存需求接近7B的两倍。FP16权重约26GB，24GB卡放不下权重，硬跑要量化或CPU卸载。40GB和48GB卡跑FP16更从容。INT8权重约13GB，INT4约6.5GB，24GB卡用INT8或INT4能部署。我选13B时先看业务是否需要更强的语言理解和推理能力，再看显存预算能不能覆盖并发。

13B的性能成本平衡点在中等复杂度任务。代码补全、知识问答、RAG、内容生成，13B比7B多一层质量余量。它的吞吐低于7B，延迟也高一些。48GB卡跑13B FP16，权重26GB，剩22GB给KV Cache和运行时。8K单请求KV约6.4GB，加运行时后余量不多，4K上下文加2路到4路并发更现实。24GB卡跑13B INT8，权重13GB，剩11GB给KV和缓存，上下文和并发要压得比较紧。

13B的适用边界很清楚。业务对效果有要求，预算又不到70B多卡级别，13B是折中选择。我常把13B放在7B验证之后做效果升级，显存从单卡24GB往40GB或48GB走。13B开源模型显存需求对比里，FP16和INT8的差距很大，量化能把门槛拉回单卡24GB，精度损失要按业务测。长上下文和高并发场景，13B的KV Cache放大效应比7B更明显，选型时不能只看权重。

2.4 70B开源模型显存需求、多卡并行与高门槛部署策略

70B模型是另一个量级。FP16权重约140GB，单张80GB卡放不下。FP32权重约280GB，基本是实验配置。INT8权重约70GB，单张80GB卡能加载，KV Cache和运行时余量很小。INT4权重约35GB，单卡80GB能跑，吞吐和精度要实测。70B的部署门槛不在“能不能加载”，在“能不能稳定跑出业务需要的并发和延迟”。

70B生产部署通常走多卡并行。2张80GB卡跑FP16，权重每卡70GB，剩10GB给KV Cache、通信缓冲和框架开销，短上下文能试，长上下文和高并发会紧张。4张80GB卡更稳，张量并行能把权重和计算分开，通信开销也上来。8卡配置适合更高吞吐和更长上下文。多卡并行不只是显存加法，卡间通信、批调度、KV Cache分布都会影响实际占用。我做70B方案会先定上下文和并发，再算卡数。

70B适合质量优先的业务。企业知识库、复杂推理、长文摘要、多轮对话，70B的效果上限更高。它的硬件成本、电费、运维复杂度也高。70B用GQA结构时KV Cache比MHA小很多，8K单请求约2.5GB，16路并发约40GB。权重140GB摆在那里，KV优化只能缓解一部分压力。70B开源模型显存需求对比的结论很直接：单卡时代结束，多卡和量化是常态，部署前要做压测和成本核算。

2.5 7B/13B/70B显存阶梯对比：规模增长带来的显存与硬件跃迁

我把三档模型的FP16权重和典型硬件放在一张表里，阶梯感很明显。7B到13B权重接近翻倍，13B到70B权重涨了五倍多。硬件从24GB单卡跳到40GB或48GB单卡，再到多张80GB卡。这个跃迁不只是买更多卡，机箱、电源、网络、散热都要跟着换。开源大模型显存需求对比里，70B的门槛是系统级门槛，不是一张显卡的显存数字。

这张表里的KV Cache是单序列8K估算，实际并发要乘并发数。7B FP16在24GB卡上跑8K加8路并发，KV Cache约32GB，明显超过卡容量。13B FP16在48GB卡上跑8K加4路并发，KV约25.6GB，加权重26GB已经超过48GB。70B权重太大，多卡并行后每卡分到的权重仍然可观。我做容量规划会把权重、KV Cache、运行时开销分开列，再乘安全系数。

规模增长带来的成本不是线性的。7B可以单卡试错，13B要换卡或量化，70B要上多卡和机房条件。吞吐和延迟也会变。70B单次推理更慢，多卡并行能提吞吐，通信开销会拉低扩展效率。我用每百万token成本看三档模型，7B适合高并发低价场景，13B适合质量与成本平衡，70B适合高价值任务。显存阶梯背后是业务分层，不是单纯比谁的数字大。

2.6 不同参数规模模型的选型启示：效果、成本与可部署性权衡

我选模型先问业务场景。高并发、低延迟、成本敏感，7B优先。效果要求中等，预算能覆盖40GB或48GB卡，13B更合适。复杂推理、长文、企业知识库，70B进入候选。量化能降显存门槛，7B INT4能上更小的卡，13B INT8能回24GB卡，70B INT4能压到单张80GB卡。量化后的精度损失、吞吐变化要按业务测，不能只看显存数字。

可部署性是很现实的约束。7B单卡就能跑，运维简单，扩容直接加卡或加实例。13B要关注卡型和量化方案，24GB卡跑INT8，48GB卡跑FP16，选择空间大。70B要多卡并行，机房网络和运维能力要跟上。我常建议先用7B做原型验证，把业务流程跑通，再用13B做效果升级，70B放在高价值场景。这个路径能控制试错成本，也能让显存预算跟着业务走。

效果、成本、可部署性三个维度要一起看。7B不是“低配”，它在很多分类、摘要、客服任务上够用。13B是中间档，显存翻倍换来效果余量。70B是质量上限，硬件门槛和成本也高。开源大模型显存需求对比的落点是业务可用性，不是参数崇拜。我把三档模型的显存、硬件、吞吐、延迟和成本放进同一张决策表，按业务权重打分，选出来的方案更稳。

我一开始做量化，心里想得很美：把权重从FP16压到INT4，显存直接砍到四分之一，小卡也能跑大模型。真上手跑了一圈才发现，量化省下来的显存是实打实的，可它不是全部。权重只是显存账本里的一项，KV Cache、激活值、框架缓冲还在那儿站着。我做开源大模型量化后显存占用对比，会把这几项分开算，再把精度和速度拉进来一起看，这样得出的结论才能落到部署上。

3.1 常见量化方案对比：INT8、INT4、GPTQ、AWQ、GGUF、QLoRA等

INT8和INT4是最直观的两档。INT8每个参数占1字节，7B权重约7GB，13B约13GB，70B约70GB。INT4每个参数占0.5字节，7B约3.5GB，13B约6.5GB，70B约35GB。这两个数字是我做容量规划的起点，实际占用要往上加运行时开销和KV Cache。我常跟人讲，INT4的7B权重听起来像3.5GB，但真跑起来显存表显示五六个GB很正常。

GPTQ和AWQ是两条主流量化路线。GPTQ走训练后量化，用校准数据算二阶信息，把权重压到INT4或INT8。AWQ是激活感知的权重量化，思路是保护那些对激活影响大的权重通道。我实测下来，两者在7B和13B上都能把权重压到接近理论值，困惑度涨幅在小数点后。GPTQ生态成熟，工具链多；AWQ在某些模型上推理速度更稳。选哪个我会看模型支持情况和推理框架的兼容性，不盲目追新。

GGUF是llama.cpp生态里的格式，它把量化等级分得很细，Q4_K_M、Q5_K_M、Q8_0这些名字背后是不同的权重和部分激活的混合精度。GGUF的好处是CPU和GPU都能跑，消费级卡和Mac都能部署。QLoRA不是纯推理量化，它是4bit量化基础模型加LoRA适配器做微调，显存省在基础权重和优化器状态上。我把这几套方案放在一张表里对比，标注适用场景：纯推理看GPTQ、AWQ、GGUF，微调看QLoRA，边缘设备看GGUF的低比特等级。

3.2 7B/13B/70B模型量化后权重显存占用对比

三个规模量化后的权重数字，我拉出来看梯度很清楚。7B在FP16下约14GB，INT8约7GB，INT4约3.5GB。13B FP16约26GB，INT8约13GB，INT4约6.5GB。70B FP16约140GB，INT8约70GB，INT4约35GB。从7B到70B，同精度下权重差二十倍，量化等级每降一档，权重减半。这个规律简单，做估算够用。

表里最后一列是我在实测中看到的典型值，比理论权重大一截。7B INT4在8GB卡上能加载，上下文别开太大。13B INT4在12GB卡上能跑短上下文，16GB卡更从容。70B INT4约35GB权重，单张48GB卡能放下，KV Cache和并发要压着用。70B INT8约70GB，单张80GB卡刚够加载，余量很小，长上下文容易顶到红线。

这些数字放到硬件选型里很有用。7B INT4让8GB卡进入候选，13B INT4让12GB和16GB卡有了用武之地，70B INT4把门槛从多张80GB卡拉低到单张48GB或80GB卡。量化不是免费午餐，它把权重显存压下来，把精度和速度的账留给我在后面算。我做对比会把理论权重和实测占用并排放，避免拿3.5GB去规划一张8GB卡的完整部署。

3.3 量化对KV Cache、激活值及推理运行时显存的影响

权重能量化，KV Cache也能量化，这两件事经常被混在一起说。KV Cache量化到INT8能把缓存占用减半，量化到INT4能减到四分之一。7B FP16下8K单请求KV约4GB，INT8后约2GB，INT4后约1GB。这个节省在高并发场景很可观。KV Cache量化的精度影响比权重量化更敏感，长上下文任务里表现更明显，我一般会做业务侧的效果回归再上线。

激活值这块容易被忽略。推理时激活值占用比训练小很多，但在大batch、长上下文、大隐藏维度下也会冒头。量化权重后，部分框架会把激活也走低精度计算，显存省一点，数值稳定性要盯。我遇到过INT4权重配FP16激活的配置，显存比全INT4高，精度反而更稳。这种混合配置在实际部署里很常见，不能只看权重位宽一个数字。

运行时开销是量化对比里最容易被低估的部分。CUDA上下文、框架预分配、通信缓冲、临时张量，这些不随量化等级线性缩小。7B INT4权重3.5GB，实测占用五六GB，多出来的就是这些。70B多卡并行时，通信缓冲和KV Cache分布让每卡占用更复杂。我做量化显存对比会把权重、KV Cache、激活、运行时分成四栏，每栏标量化前后的变化，这样才知道省下来的显存到底来自哪里。

3.4 量化精度损失、推理速度收益与显存节省的权衡

量化最直接的收益是显存，其次是速度。INT8在多数推理框架里能带来吞吐提升，INT4的加速比要看硬件和kernel支持。我在同一张卡上测7B，FP16、INT8、INT4三档的token吞吐能拉开明显差距，INT4往往最快，前提是推理框架对INT4有优化过的kernel。没有优化的情况下，INT4反量化开销可能吃掉一部分收益，速度不一定比INT8快。

精度损失要按任务看。7B INT8在分类、摘要、客服问答上，和FP16的差距我用业务指标测，多数场景在小范围内。INT4的困惑度涨幅更明显，复杂推理、代码生成、长文理解这些任务要谨慎。13B INT4的绝对效果可能接近7B FP16，显存却低不少，这种跨规模对比很有意思。70B INT4在质量上通常还能压住13B FP16，显存从140GB降到35GB，代价是精度和推理稳定性。

我的权衡方法是做三档对照：FP16看效果上限，INT8看性价比，INT4看极限压缩。每档都测显存、吞吐、延迟和业务指标，画一张四维表。显存节省和速度收益很诱人，精度损失要拿业务数据说话。量化等级不是越低越好，找到业务能接受的最低精度，才是显存和效果的平衡点。我见过为了省显存硬上INT4、结果线上答案质量下滑的案例，返工成本比省下的卡钱高。

3.5 量化部署的显存红线：不同硬件下的可行模型规模与量化等级

显存红线这件事，我按卡容量分档来看。8GB卡上，7B INT4能加载，上下文控制在2K到4K，并发压到一两路。12GB和16GB卡上，7B INT4跑得更从容，13B INT4也能进候选，上下文和并发要收着。24GB卡是很多人的主力，7B FP16、13B INT8、13B INT4都能跑，70B INT4放不下，权重就35GB了。这张卡上我会优先考虑13B INT8加中等上下文。

48GB卡的选择空间大很多。70B INT4权重约35GB，剩十几GB给KV Cache和运行时，短上下文加低并发能跑。13B FP16权重26GB，剩二十多GB做KV Cache，8K上下文加几路并发比较稳。80GB卡上，70B INT8权重70GB刚够加载，余量很小，实际部署我更倾向70B INT4或FP16多卡。单张80GB卡跑70B INT8属于极限操作，长上下文和高并发基本没空间。

这张表是起点不是终点。KV Cache、上下文长度、并发数、推理框架都会把红线往下推。我常提醒，表里的“可行”指的是能加载并短时间跑通，生产环境要留20%到30%的显存余量。70B INT4在48GB卡上跑通和稳定跑业务是两回事，压测这步不能省。显存红线是动态的，跟业务负载绑在一起看才准。

3.6 量化后显存占用对比的常见误区与正确评估方式

我见过最多的误区是拿理论权重当全部显存。7B INT4算出来3.5GB，就以为4GB卡能跑，实际权重加运行时加KV Cache，8GB卡才勉强。权重只是显存账本的第一页，KV Cache和框架开销在后面几页。我做对比会把理论值和实测值并排放，差值标出来，规划时用实测值加安全系数。

第二个误区是混着比量化等级。拿7B INT4的显存去比13B INT8，得出“13B更费显存”的结论，这种对比没有意义。同规模比量化等级，同量化等级比规模，交叉对比要标清楚条件。GGUF的Q4_K_M不是纯INT4，它混了不同精度的层，直接和GPTQ INT4比显存会失真。我在表里会把量化方案、精度配置、校准数据都写清楚，避免读者误读。

正确评估方式我总结成三步。第一步算理论权重，参数乘位宽除八。第二步加KV Cache，按上下文和并发算。第三步加运行时开销，用实测校准。三步走完再做精度和速度测试，四组数据放一起决策。量化显存对比不是比谁的数字小，是比谁能在业务约束下跑得稳、跑得省。我自己的习惯是每次换模型或换量化方案都重新压测一遍，旧数据不直接套用，硬件和框架版本一变，显存占用就跟着变。

我经常遇到一个提问：同一张卡，跑推理能装下的模型，拿来微调为什么就爆显存了？这个问题看着简单，答案藏在显存账本的构成里。推理和训练对显存的需求不是差一点，是差一个量级。我做显存需求对比时会把两个场景分开算账，再把它们放进同一张表里看差距。这一章就是讲这个差从哪来、有多大、对硬件选择意味着什么。

4.1 推理场景显存构成：权重、KV Cache、并发请求与上下文长度

推理的显存构成相对好算。权重加载占大头，之后是KV Cache，再往后是激活值和框架运行时开销。7B模型FP16权重约14GB，INT4约3.5GB，这部分是固定的。KV Cache按请求分配，每条请求每个token都要存一份key和value。上下文越长、并发越多，KV Cache的占比就越往上走。我见过7B模型在长上下文高并发下，KV Cache的显存超过权重本身的场景。

并发请求对显存的影响是乘法的。一个请求8K上下文占1GB到2GB KV Cache，10个并发就变成10GB到20GB。推理框架一般会预分配KV Cache池子，池子大小按最大并发和最大上下文算。我在部署vLLM时习惯先把最大并发和最大上下文定下来，再反推需要多少显存。这个数字经常比权重更能决定你该用哪张卡。

上下文长度是另一个放大器。同样一条请求，2K上下文和32K上下文的KV Cache差十几倍。7B模型8K单请求FP16 KV Cache约4GB，32K就接近16GB。13B和70B的KV Cache还要按层数和隐藏维度放大。我在做推理显存预算时会把权重、KV Cache上限、激活和框架开销四项分开列，四项加起来才是真正要预留的显存。

表里的数字让我能快速判断卡够不够。70B FP16单卡跑推理，权重140GB就先排除80GB卡了，必须多卡。7B FP16在24GB卡上跑8K上下文和几路并发比较从容，32K上下文就要把并发压下来。推理场景的显存需求弹性很大，弹性的来源就是上下文和并发，把这两个参数定死，显存账才算得准。

4.2 微调场景显存构成：全参微调、LoRA、QLoRA与优化器状态

微调和推理的显存差距，主要差在训练状态上。全参微调要存权重、梯度、优化器状态三套东西。FP16全参微调，权重2字节每参数，梯度2字节，Adam优化器还要存一阶矩和二阶矩各4字节，加起来每个参数要16字节到20字节。7B模型全参微调，光这三项就超过100GB，还没算激活值。这就是为什么单卡微调7B全参基本不可能。

LoRA把可训练参数压到很小一部分，通常不到总参数的1%。7B模型LoRA微调时，基础权重冻结不存梯度和优化器状态，只有适配器那部分要训练。显存大头从训练状态变成了基础权重加激活值。我在24GB卡上跑7B LoRA微调是能跑通的，批次大小和序列长度要调小。13B LoRA在24GB卡上比较紧，40GB或48GB卡更稳。70B LoRA在单卡上基本不用想，多卡或者QLoRA才有戏。

QLoRA是在LoRA基础上把基础模型量化到4bit。7B基础权重从14GB降到3.5GB左右，训练状态只针对LoRA适配器。这个组合让7B微调的显存门槛降到8GB到12GB级别，13B降到16GB到24GB级别。我实测QLoRA在24GB卡上跑13B微调，序列长度中等的情况下是可行的。70B QLoRA在48GB卡上能跑起来，批次和序列长度要压得很低。

全参微调的显存需求经常被低估。我见过拿7B模型问单卡80GB能不能全参微调的，答案是不能，差得远。全参微调7B至少要两三张80GB卡，13B要四到六张，70B是集群级别的事。LoRA和QLoRA才是大多数团队实际会走的路。我在选微调方案时先看效果要求，效果够用就选QLoRA省显存，效果不够再往上加资源。

优化器状态这一项特别值得说。Adam的优化器状态是参数量的8字节，7B就是56GB，比权重和梯度加起来还大。用SGD能省一些，但收敛慢。8bit优化器能把状态压到2字节每参数，省显存但可能有精度损失。我在做全参微调显存估算时会把优化器类型单独标出来，不同优化器的显存账差很多。很多人算漏了优化器状态，规划出来的硬件方案根本跑不起来。

4.3 长上下文与高并发对7B/13B/70B模型显存需求的放大效应

长上下文对推理显存的放大是非线性的。KV Cache随上下文长度线性增长，但注意力计算里的中间激活会随长度平方级增长，好在推理时这部分是临时的，峰值占用不如训练明显。我做7B模型的长上下文测试，2K到8K的KV Cache增长还算平缓，8K到32K就明显吃紧了。70B模型在32K上下文下，KV Cache单项就能吃掉几十GB。

高并发的叠加效应更直接。并发数乘以单请求KV Cache就是总缓存需求。7B模型8K上下文跑32路并发，KV Cache可能到100GB以上，权重才14GB。这个场景下权重反而不是主要矛盾了。我在部署高并发推理服务时会把KV Cache池子设成上限，超过就排队。池子设多大取决于峰值并发和上下文上限，这两个参数直接决定要几张卡。

70B模型在高并发长上下文场景下的显存需求是碾压级的。70B FP16权重140GB，32K上下文单请求KV Cache约48GB，16路并发就是768GB。这个量级不是几张消费卡能解决的，要用80GB卡多机组集群。我一般建议70B模型部署时把上下文和并发做成可配参数，按业务峰值调，不要一开始就按最大值预留资源。

训练场景的长上下文放大效应比推理更狠。微调时序列长度从2K拉到8K，激活值显存涨四倍左右。7B LoRA在2K序列下24GB卡能跑，8K序列下同样的卡就吃力了。QLoRA能缓解权重部分的压力，激活值该占还是占。我在做长上下文微调时优先用梯度检查点技术，用计算时间换显存，能省不少激活值空间。批次大小和序列长度是跷跷板，调一个另一个就得让。

4.4 多卡并行、模型卸载与分布式策略对显存对比结果的影响

多卡并行改变了单卡显存账本的算法。张量并行把权重和计算切到多张卡上，每张卡只存一部分。7B模型两张卡做张量并行，每卡权重7GB左右，KV Cache也分摊。流水线并行按层切分，每卡存不同层的权重。这两种策略能让你用多张小卡拼出大模型的容量，通信开销和卡间带宽会成为新瓶颈。我做多卡部署对比时会把通信缓冲的显存也算进去，这部分在张量并行下不可忽略。

模型卸载是把不活跃的层或缓存放到CPU内存甚至磁盘上。显存不够时这是个兜底方案，代价是延迟上升。7B模型INT4权重3.5GB，8GB卡跑推理装得下，微调装不下时可以把优化器状态卸载到CPU。我试过把优化器状态放CPU的QLoRA配置，显存省下来了，训练速度掉了不少。卸载方案适合显存红线附近勉强跑的场景，不适合追求吞吐的生产环境。

分布式策略对显存对比结果的影响在于口径。单卡显存占用和多卡总显存占用是两个概念。70B FP16在8张80GB卡上做张量并行，每卡显存占用大约20GB权重加KV Cache分摊，看起来每卡很轻松。总显存还是640GB起步。我做对比时会同时标注单卡占用和总显存，避免有人拿每卡20GB去规划一张卡跑70B。分布式的前提是卡间互联够快，PCIe和NVLink下的表现差很多。

训练场景的分布式更复杂。数据并行每张卡存完整模型副本，显存占用等于单卡全参微调的量。张量并行加数据并行混合，显存分摊方式又不一样。ZeRO把优化器状态、梯度、权重分阶段切分到多卡上，7B全参微调用ZeRO-3在8张80GB卡上能跑通。这些策略的显存账差异很大，我在做训练硬件方案时会先选并行策略再算显存，顺序反了容易白算。

4.5 推理与训练显存需求对比：同一模型在不同任务下的硬件选择差异

同一个7B模型，推理和微调的硬件选择能差一个档位。推理用INT4量化，8GB卡能加载，12GB卡跑得舒服，24GB卡可以上FP16加中等并发。微调用QLoRA，8GB到12GB卡能跑小批次短序列，24GB卡跑13B QLoRA比较稳。全参微调7B，80GB卡单张都不够，要两三张起步。这张对比表我经常拿给团队看，让大家对“同一模型不同任务”的硬件差距有直觉。

70B模型的推理和训练差距最夸张。推理用INT4在48GB单卡上能跑短上下文低并发，训练用QLoRA要48GB到80GB单卡跑得很勉强，全参微调直接进集群领域。我在做70B相关项目时，推理和训练的硬件预算会分开申请，混在一起算容易出偏差。推理的硬件投入相对可控，训练的硬件投入是数量级上的差别。

硬件选择上我有个经验法则：推理看权重加KV Cache上限，微调看权重加训练状态加激活值。推理的弹性在上下文和并发，微调的弹性在批次和序列长度。两个场景对显存的要求没有可比性，拿推理的硬件方案去跑微调，大概率爆显存。反过来拿微调的硬件跑推理是浪费。我在给团队做选型建议时会把场景先分清楚，再谈卡型和数量。

推理和训练对显存带宽和算力的侧重也不同。推理是显存带宽敏感，权重读一遍算一遍，带宽决定吞吐。训练是算力敏感，前向反向加优化器更新，算力决定速度。这个差异影响卡型选择，推理可以用带宽高的卡，训练要算力强的卡。我在做同一模型不同任务的硬件对比时，会把带宽、算力、显存三个维度放一起看，不只是比显存大小。显存够不够是门槛，带宽和算力决定跑得好不好。

前面几章我把显存账本拆成了权重、KV Cache、激活值、训练状态几块，也把推理和训练的差距摆出来了。账算得再细，落地时还是得靠实测兜底。这一章讲的就是我实际怎么测、怎么选、怎么判断趋势。纸上估算和真机跑出来的数字经常对不上，误差来源不少，这一章把我踩过的坑和常用的工具链摊开说。

5.1 实测工具与基准设置：nvidia-smi、PyTorch显存统计、vLLM等推理框架

我最常用的工具还是nvidia-smi。简单直接，能看到每张卡的显存占用、进程分布、功耗和温度。它的局限也明显，采样是秒级的，峰值占用经常被漏掉。加载模型那一瞬间的显存峰值、推理第一个请求进来时的激活峰值，nvidia-smi盯不住。我一般会配合一个轮询脚本，把采样间隔压到100毫秒以内，跑完整流程再回看曲线。

PyTorch的显存统计细一些。torch.cuda.memory_allocated()看当前张量占用的显存，torch.cuda.max_memory_allocated()看峰值，torch.cuda.memory_reserved()看缓存池向驱动申请的显存。这三个数经常不一样，预留的缓存池会比自己实际用的多。我做对比时会把allocated和reserved都记下来，前者是真实需求，后者是框架的预留行为。换框架、换版本，reserved的量会变，对比时要注意口径。

vLLM这类推理框架有自己的显存管理逻辑。PagedAttention把KV Cache切成块管理，启动时会预分配一个显存池，参数叫gpu_memory_utilization，默认0.9左右。这个参数设多少直接影响能跑多大并发。我在测vLLM部署时会把利用率参数固定，比如统一设0.85，然后逐步加压并发，看吞吐和延迟的拐点。不同框架的预分配策略不一样，跨框架对比要先统一这类参数，否则数字没有可比性。

基准设置要一次性定死。模型版本、精度、量化方案、序列长度、批次大小、并发数、框架版本、驱动版本，这些变量任何一个变了，实测数字就不能直接比。我做过一个习惯，每次对比实验先写一页基准配置表，跑完把实测结果填进去。过两周回头看，知道当时的数字是在什么条件下测出来的。

测试流程我一般分三段。加载阶段测权重占用和峰值，稳态阶段测空载占用，加压阶段按并发梯度跑请求，记录吞吐、延迟和显存峰值。三段分开测，出了问题容易定位。加载爆显存是权重问题，稳态超标是框架开销问题，加压后爆是KV Cache或者激活的问题。

5.2 面向不同硬件的模型规模与量化方案推荐

选型这件事我习惯从手头有的卡倒推。消费级8GB到12GB卡，7B模型INT4量化是主力方案，GGUF或者AWQ都行。这个组合显存占用在4GB到6GB，留出KV Cache和框架开销后跑短上下文单路请求比较稳。想跑并发，把上下文压到2K以内，能挤出几路。13B模型INT4在这个档位能加载，跑起来比较勉强，上下文和并发都得压得很低。

24GB卡是很多团队的主力。7B模型FP16能跑，中等并发加8K上下文有空间。7B的QLoRA微调也在这个档位跑得舒服。13B模型INT4在这个档位是比较甜的点，显存占用8GB到10GB，能留出足够的KV Cache空间。我见过不少团队用24GB卡跑13B量化推理做业务验证，性价比不错。70B在这个档位只能靠极低比特量化加超短上下文，实用价值有限。

48GB到80GB卡是另一个台阶。13B模型FP16在这个档位很从容，长上下文高并发都能上。70B模型INT4量化在48GB卡上跑短上下文单路可行，80GB卡上能跑中等并发。70B的QLoRA微调在48GB到80GB卡上能跑起来，批次和序列长度要压。全参微调7B在这个档位要两到三张80GB，13B要四张以上。

我选型时会先问三个问题：业务要多长上下文、要多少并发、效果能不能接受量化损失。三个问题答完，卡型和量化方案基本就定了。先看卡再选模型，容易削足适履。先定业务参数再匹配硬件，方案更靠谱。

5.3 成本、吞吐、延迟与显存占用的综合决策方法

显存够不够只是入场券，真正决定方案的是成本和性能的组合。我做过一个对比，同一套业务负载，用两张24GB卡跑13B INT4和用一张48GB卡跑13B FP16，显存账前者更宽裕，卡的数量多一张，整机成本和功耗上去了。后者的单卡成本高，部署简单，延迟更稳。这种选择题没有标准答案，要看业务对延迟和成本的敏感度。

吞吐和延迟经常是跷跷板。批次开大、并发拉高，吞吐上去，单请求延迟变长。显存占用也跟着涨，KV Cache池子要开大。我在做推理服务时会把延迟目标先定下来，比如P99控制在多少毫秒，再在这个约束下调批次和并发找最大吞吐。显存按这个最优点的峰值再留20%余量。

单位token成本是我评估方案的核心指标。总硬件成本加电费，除以单位时间能处理的token数，得出每个token的成本。量化方案在这个指标上优势明显，同等的卡能跑更大的模型或者更多的并发。量化带来的精度损失要单独评估，业务能接受就用，接受不了就老实上更高精度的方案和更贵的卡。

我一般会给团队出两到三套方案，每套标明硬件清单、量化方案、预期吞吐、延迟区间和成本。让大家在明确的数字上讨论，比在"大概能跑"上争论有效得多。方案之间不是好坏关系，是适配关系，业务场景不同，最优解也不同。

5.4 开源模型显存优化趋势：高效量化、KV Cache优化与分布式推理

量化这条线这两年推进得很快。4bit量化已经是主流部署方案，精度损失在多数任务上可以接受。更低的比特数也在探索，3bit、2bit的方案开始出现，效果稳定性还在打磨。我关注的是量化方案和推理框架的结合度，AWQ在vLLM里的支持成熟，GGUF在llama.cpp生态里方便，选方案时生态支持度比纸面指标更重要。

KV Cache优化是显存账本里变化最大的部分。PagedAttention把碎片问题解决了，KV Cache的显存利用率上去了。GQA和MQA这类注意力结构变体从模型层面压缩了KV Cache的尺寸，70B级别的模型用GQA能把KV Cache砍掉一大截。还有KV Cache量化，把缓存本身压到8bit甚至4bit，进一步省显存。这些优化叠加起来，长上下文高并发的显存门槛在往下走。

分布式推理的进步也在改变选型逻辑。张量并行、流水线并行的框架支持越来越成熟，多张小卡拼大模型的路子越走越顺。分离式推理把prefill和decode拆到不同硬件上跑，各自按需配置。这些方案让70B级别的模型部署门槛在降，不再是几张80GB卡起步的事。我在做中长期规划时会把这类趋势考虑进去，避免按当下最优方案把硬件锁死。

这些趋势对选型的启示是，硬件规划别只看当下。量化方案在演进，同样一张卡明年能跑的模型规模可能比今年大。我建议硬件选型时优先选显存带宽和互联能力好的卡，这类卡的保值性更强，后续优化技术能用得上。

5.5 面向实际业务的显存需求对比结论与部署建议

把前面所有章节收拢，我的核心结论有几条。显存估算必须分场景，推理和训练的账本结构完全不同，混在一起算必然出错。量化是降低显存门槛最有效的手段，效果可接受的场景优先用量化方案。上下文和并发是推理显存的两个放大器，业务参数没定死之前，任何显存结论都是暂时的。

部署建议上，我倾向小步验证再扩容。先用手头卡按目标业务负载跑一轮实测，拿到真实的吞吐、延迟和显存峰值，再决定采购多少卡、选什么量化等级。一次性按理论估算采购，超配浪费钱，欠配跑不动。实测这一环省不得。

我给团队的落地清单一般是这几项：明确业务上下文长度和峰值并发，按目标模型规模做显存估算，选两套量化方案做对比实测，按实测数据出硬件清单和成本预算，预留20%显存余量应对流量波动。这套流程走下来，方案落地后爆显存的概率会低很多。

长期看，显存优化的技术在持续进步，同样的预算能跑的模型规模在变大。硬件选型给未来留点空间，部署方案保持可调整，比一次性押注某个具体配置更稳妥。显存需求对比这件事，本质是让每个决策都在数字上站得住脚，而不是凭感觉拍脑袋。