1. 部署大模型前先搞明白显存都花在哪了刚接触大模型本地部署的朋友最容易上来就问一句话“我要跑个7B的模型得买多大的显卡”这个问题的标准答案往往很模糊因为7B只是模型参数量真正决定显存需求的是三个东西模型权重本身、KV Cache以及框架运行时的开销。这三块加一起才是你实实在在要掏钱买的显存。我自己的经验是很多人第一次部署失败根本不是显卡不够好而是压根没算清楚显存账。比如有人说自己用一张24G的4090跑Qwen2.5-14B结果一启动就OOM翻日志才发现是上下文长度开到了32KKV Cache直接把显存吃光了。这种事情特别典型也非常可惜——只要提前算一笔账完全可以避免。所以这篇文章就围绕“部署一个模型到底需要几张GPU”这个核心问题把显存计算的逻辑完整拆开讲一遍。你不需要有很深的算法基础只需要跟着公式走一遍就能搞清楚自己的场景该买什么卡、买几张、怎么分配最划算。这个思路同样适用于Ollama、vLLM、TensorRT-LLM这些主流部署工具不管你是用单卡跑个小模型还是想多卡跑个几十B的大模型这套计算逻辑都能复用。提示以下计算主要面向推理场景。如果你要做微调比如LoRA或全量微调显存需求会额外增加优化器状态和梯度显存通常至少是推理的2-4倍这个后面单独说。2. 模型权重到底占多少显存一算就明白2.1 权重显存的本质参数量 × 每个参数的字节数模型权重大小本质上就是参数量乘以每个参数存储的字节数。公式极其简单权重显存 模型参数量 × 每个参数的显存占用关键在“每个参数的显存占用”这个数值上。模型权重常用的数据类型主要有三种FP3232位浮点每个参数占4字节FP16/BF1616位浮点每个参数占2字节INT88位整数每个参数占1字节INT44位整数量化每个参数占0.5字节实际部署中绝大部分模型权重是用FP16或BF16格式存储的也就是每个参数2字节。所以一个7B模型的权重理论大小就是7 × 10^9 × 2 14GB注意这里说的是“理论大小”实际加载进显存时还要加一点额外开销比如模型结构本身的结构体、参数管理用的元数据等通常会让实际占用比理论值多个几百MB到1GB左右。所以7B模型在FP16下单张16G的显卡是很勉强能放下的24G就很从容了。2.2 量化如何改变权重显存很多人问我“为什么别人说7B模型只要8G显存就能跑”这里面的秘密就是量化。量化用更低位宽来存参数以损失一点精度为代价换取显存的大幅压缩。数据类型每参数占用7B模型理论权重13B模型理论权重70B模型理论权重FP324字节28GB52GB280GBFP16/BF162字节14GB26GB140GBINT81字节7GB13GB70GBINT40.5字节3.5GB6.5GB35GB从表格能看出来对你个人开发者来说INT4量化的7B模型只需要3.5GB权重显存加上其他开销8GB显存的卡照跑不误。这也是为什么很多“消费级显卡跑大模型”的教程都推荐用量化版本。但量化不是白吃的午餐。INT4量化后模型输出质量会略有下降尤其是逻辑推理、代码生成这类对精度敏感的任务可能回答变短、逻辑变弱。所以我的建议是先试着跑FP16显存实在不够再降级到INT8最后才考虑INT4。能不动量化就不动动了就要接受质量折损。2.3 计算权重显存时的常见误区第一个误区是只看模型文件大小。比如你从Hugging Face下载模型看到文件是14GB就以为加载进显存也是14GB。其实文件往往已经做了某种压缩或分片存储实际加载到显存后会膨胀一些。第二个误区是忽略模型并行时的权重冗余——有些多卡方案会在每张卡上都存一份完整权重比如流水线并行做不好时那每张卡的计算就要乘以卡数。第三个误区是忘了PyTorch/CUDA上下文本身就占显存一般在300MB到1GB之间这个小头叠加起来也挺可观。3. KV Cache才是真正的隐形显存杀手3.1 KV Cache是什么为什么它和大模型的对话长度强相关KV CacheKey-Value Cache是大模型推理过程中用来缓存历史计算结果的机制。你可以把它理解成对话记忆模型生成每个token时都要“回顾”之前所有token的信息。如果不缓存每生成一个新token模型都要把之前所有历史重新算一遍速度会慢到无法接受。所以部署框架会把之前算好的Key和Value矩阵存在显存里这就是KV Cache。它的显存占用公式比权重要多几个变量KV Cache显存 2Key和Value两份× 层数 × 每层注意力头数 × 每个头的维度 × 序列长度 × 批次大小 × 每参数字节数这个公式看起来复杂但核心逻辑就是模型越深、头数越多、序列越长、并发越大KV Cache就越大。其中序列长度和批次大小是变量模型结构是固定常数。3.2 用实际例子感受KV Cache的膨胀速度我们来算一个具体例子。以Llama 2 7B为例它的结构参数是32层、32个注意力头、每个头维度128。那么每层的KV维度就是32头数 × 128头维度 × 2Key和Value 8192也就是说每层每个token要缓存8192个数值全部32层就是262144个数值用FP16存储就是约0.5MB。听上去不多是吧但对话场景下上下文长度轻松到4096甚至8192。如果用户和模型聊了4096个token那么KV Cache就是0.5MB × 4096 2GB如果是8192的上下文那就直接到4GB。如果是服务多个并发用户批次大小8那再去乘832GB就没了。到这一步你就明白了为什么很多人单卡推理性能不错一旦拉到长上下文或高并发就直接爆显存——权重没吃掉显存KV Cache吃掉了。3.3 不同模型的KV Cache估算表模型参数量近似KV Cachesequence4096, batch1近似KV Cachesequence8192, batch1Qwen2.5-7B7.6B约2.2GB约4.4GBLlama 3.1-8B8.0B约1.7GB约3.4GBQwen2.5-14B14.7B约4.3GB约8.6GBMixtral-8x7B (MoE)46.7B约4.1GB约8.2GB注意一个有意思的现象Mixtral是MoE模型总参数量很大但推理时每次只激活部分专家KV Cache反而比同体量的密集模型小不少。这也解释了为什么MoE模型被广泛用在部署场景——同样显存下它能用更少的有效计算处理更长的上下文。注意不同框架对KV Cache的管理策略不同。vLLM默认会预留部分显存作为KV Cache池而Ollama则是按需分配。这也导致同样模型在不同框架下显存占用曲线差异明显。4. 还有一笔“运行开销”别漏算4.1 运行开销来自哪些地方模型权重和KV Cache是你算得出的“大头”但真正跑起来显存里还会多出一堆你没算到的开销。主要来自这几个方面CUDA上下文CUDA Context只要使用GPU跑深度学习/推理框架CUDA就会分配一部分显存用于运行环境通常300MB起步多卡环境下每张卡都有。PyTorch/CUDA缓存分配器PyTorch为了提高张量分配效率通常会预申请一块显存作为缓存池。即使模型只用了一部分它也可能把一个大的显存块据为己有。激活值Activations虽然推理阶段激活值比训练小很多但在长序列下中间激活仍然可能占用几百MB到几个GB。部署框架自身的开销vLLM的调度器、PagedAttention的块管理器、Ollama的并行管理器都有各自的显存占用。我用实际部署经验给你一个经验公式实际显存需求 权重显存 KV Cache显存 1.5GB到2GB的保守运行开销。这个数字对于单卡场景基本够用多卡场景还要再加上通信缓冲区的开销每张卡再额外加0.5GB左右。4.2 实操算一张整机的显存总需求我们把上面的公式整合给出一个完整的计算流程。假设你要用vLLM部署Qwen2.5-14B最大上下文长度8192最大并发请求4使用FP16权重不量化第一步权重显存14.7B × 2字节 约29.4GB。第二步KV Cache显存查表可知该模型在8192上下文下每个并发约8.6GB4并发就是34.4GB。实际上vLLM的PagedAttention是动态分配KV Cache块的但估算时按最大预留来算更稳妥。第三步运行开销加2GB。第四步总计29.4 34.4 2 65.8GB。这个亮出来很直观——单张48GB的A6000跑不动需要两张。如果你用的是双路409048GB刚好能塞下但几乎没有冗余。如果希望留出30%的显存余量来应对峰值波动那就要考虑3张24GB卡或者直接上80GB的H100/A100。4.3 为什么“刚够”和“从容”之间差着体验上面算了65.8GB需求48GB卡是“塞不下”但就算配置刚好压在90%左右比如需求43GB卡48GB实际用起来也会很难受。因为当显存接近上限时系统会调用内存交换或触发GCGarbage Collection导致推理速度剧烈抖动甚至出现“GPU Crash Dump Triggered”之类的崩溃。我在部署vLLM时踩过这个坑模型加载完看似还有2GB富余并发稍微一高立刻OOM最后把KV Cache的gpu_memory_utilization参数调低才稳定下来。所以我的习惯是按建模需求算完后再乘以1.3的系数作为真正的购买/租用目标。比如算出65.8GB需求我会奔着85GB以上的显存去配置。这多出来的30%不是为了参数好看是为了给调度、峰值和未来扩展留余量。5. 不同部署方案下GPU该怎么分配5.1 单卡方案消费级显卡也有一席之地如果你的目标是自己开发、测试或者本地小范围使用单卡方案是最省心的起点。选卡的关键判断依据是你要跑的模型多大、上下文多长、并发多高。7B模型 4K上下文 单用户16GB显存足够RTX 4080/4090或A4000都可以。7B模型 8K上下文 少量并发24GB显存更稳RTX 3090/4090是性价比之王。14B模型 4-8K上下文24GB刚起步有条件上48GBA6000会更从容。70B模型 长上下文别想了单卡消费级跑不动除非做非常激进的量化INT4 短上下文但体验会很差。这里单独提一下Mac用户尤其M系列芯片。M3/M4的MacBook Air或Pro虽然有统一内存比如16G或32G可以跑一些模型但它的“共享显存”和NVIDIA的GDDR/HBM显存相比带宽差异很大大模型的生成速度会明显慢。16G内存的MacBook Air跑7B INT4模型实测生成速度只有NVIDIA 4060的一半左右如果没有特别理由部署大模型我还是建议优先考虑NVIDIA显卡。5.2 多卡方案两种并行方式怎么选当模型或KV Cache超出单卡容量就要上多卡。多卡部署主要有两种方式张量并行Tensor Parallelism和流水线并行Pipeline Parallelism。张量并行把一张卡上的矩阵运算拆到多张卡上并行算。好处是显存利用效率高、单步延迟低坏处是卡之间需要频繁通信对NVLink或PCIe带宽要求高。vLLM、TensorRT-LLM在单机多卡推理中默认走张量并行通常要求卡间通信带宽高否则性能提升非常有限。流水线并行把模型按层切分成多个阶段每张卡负责一部分层。好处是通信频率低坏处是首个字延迟高而且GPU利用率不够均匀。这个方案通常用于超大模型跨节点部署。实际操作中普通开发者用vLLM做单机多卡推理直接设tensor-parallel-size2或4即可。以两张24G卡为例跑Qwen2.5-32BFP16权重约64GB都绰绰有余。但要注意vLLM的张量并行要求每张卡的显存配置尽量一致混插不同型号的卡会导致显存利用率大打折扣。5.3 GPU算力不够时的租用思路自己买卡毕竟是大投入更灵活的选择是租用GPU。云厂商一般提供按小时计费的单卡或多卡实例部署前建议先按文章里的公式估算显存需求再去搜对应型号。比如单张24G4090/A5000适合7B-14B模型单张48GA6000/L40S适合14B-32B模型单张80GA100/H100适合70B模型。租卡时最容易忽略的是“卡间通信条件”。你想租4张卡跑张量并行就要确认这些卡是不是在同一台物理机上、有没有NVLink。有些云厂商的“4卡”其实是分布在两台机器上的通过千兆网络通信那种跑张量并行效率惨不忍睹不如直接租个单卡80G省心。6. 部署框架的显存调优实用技巧6.1 vLLM的显存利用率调参vLLM是目前最主流的高性能推理框架它的几项关键参数直接决定显存分配策略gpu_memory_utilization控制GPU显存中可用于模型和KV Cache的比例默认0.9即预留10%给CUDA上下文等。如果你发现显存吃紧可以调低到0.8或0.85给运行时更多缓冲。max-model-len限制最大序列长度这是控制KV Cache最简单的手段。把默认32K改成16K甚至8KKV Cache显存立刻减半。max-num-seqs控制并发的最大序列数降低这个值可显著减少KV Cache峰值占用。我实际调参的经验先满载跑一次看日志输出的显存分布。如果“KV Cache size”比“Model weights size”还大说明你的上下文或并发设置过大优先降max-model-len。如果模型权重占了显存的大头那该考虑量化或换更大显存的卡。6.2 Ollama的显存控制Ollama胜在简单但显存控制比较“黑盒”。不过它有几个实用的环境变量OLLAMA_MAX_LOADED_MODELS限制同时加载到显存中的模型数量防止加载多个模型导致显存爆掉。OLLAMA_NUM_PARALLEL设置并行请求数控制并发对KV Cache的压力。OLLAMA_KEEP_ALIVE控制模型在显存中保留的时间设为0可以立即释放显存。如果你在Windows上用Ollama发现GPU没用满先检查一下是不是跑在CPU模式。在终端输入ollama ps看进程的“PROCESSOR”列是GPU还是CPU。如果是CPU检查NVIDIA驱动和CUDA toolkit是否安装正确。很多人装了Ollama后忘记装最新NVIDIA驱动导致Ollama无法识别GPU。6.3 TensorRT-LLM与更激进的显存策略TensorRT-LLM是NVIDIA官方的高性能推理框架优势在于把模型编译成TensorRT引擎权重显存和KV Cache分配都更精细。你可以通过配置KV Cache的free_gpu_memory_fraction来精确控制预留比例还能进行attention的算子融合减少中间显存占用。代价是编译时间较长模型切换不太灵活。对个人开发者来说我的建议是如果只是本地跑一跑、验证功能优先选Ollama如果要对外提供服务、追求并发和吞吐选vLLM如果要在NVIDIA卡上把性能榨到极限再考虑TensorRT-LLM。这个优先级顺序能帮你少走很多弯路。7. 部署前必看的GPU选型速查表为了方便你直接对照自己的场景我整理了一张速查表。假设所有计算基于FP16权重、不同上下文和并发取中值运行开销已含在内场景模型规模上下文长度并发建议显存示例GPU本地聊天测试7B INT44K18GBRTX 4060个人开发调试7B FP164K116GBRTX 4080本地服务7B FP168K424GBRTX 3090/4090企业应用14B FP168K448GBA6000/L40S企业高并发32B INT84K880GBA100/H100大模型科研70B FP164K1-2160GB2×A100/H100对照上面的表大概率你就能算出自己该买几张卡了。如果你的配置和表里偏差较大那就按前面讲的公式从头算一遍用不了五分钟。提醒以上针对纯推理场景。如果需要微调请将显存需求乘以2到4倍后再选卡。微调大模型时优化器状态AdamW会额外占用与模型权重相当甚至更多的显存梯度也需要额外空间很多人一开始低估了这部分。8. 部署过程中的实际经验与避坑建议说了这么多理论最后聊聊我自己踩过的坑和真实经验。第一个经验是一定要留足显存冗余。我第一次用一张24G卡跑Qwen2.5-14B的INT4量化版算下来权重6.8GB加KV Cache 4GB加运行开销2GB总共13GB左右按理说24G绰绰有余。但实际部署时把上下文的max-model-len设成了32KKV Cache直接飙升到20GB启动就OOM。当时日志里就一行“GPU Crash Dump Triggered”排查了半小时才发现是KV Cache把显存吃爆了。所以提醒大家上下文长度是隐形的显存大头调参时先确认max-model-len再调其他参数。第二个经验不要迷信“一张卡跑所有”。有段时间我图省事想用一张A6000跑70B模型的INT4量化版权重只占35GB加上KV Cache和运行开销勉强塞进48GB。但实测生成速度非常感人一个短回答要等一分多钟。后来换了两张24G卡做张量并行速度提升了近10倍。这说明显存不是唯一瓶颈算力也要匹配得上。当模型被压缩到勉强能跑时往往牺牲的是速度和质量。第三个经验用docker部署时显存分配要和宿主机策略对齐。通过--gpus all把GPU传给容器只是第一步真正影响显存利用率的是你在容器里启动服务时用的参数。比如NVIDIA GPU Operator在Kubernetes环境下的官方配置几个关键参数会直接影响显存切分如果需要给不同团队分配不同大小的GPU资源要提前规划好GPU instance或Multi-Instance GPU的划分否则后面调整成本很高。第四个经验一定记住显存计算只是部署的第一步别忽略框架本身的开销差异。同一个模型在Ollama、vLLM和TensorRT-LLM下的显存占用相差可能达到20%-30%。vLLM由于PagedAttention机制显存利用效率通常最高Ollama图省事但显存分配不够精细TensorRT-LLM要编译调优但性能上限最高。选框架时要把“显存效率”和“易用性”放在一起权衡而不只是看谁的显存占用更低。最后再分享一个小技巧在实际部署前先用一个小的并发压测脚本打一下观察显存占用曲线确认峰值到底是多少。别只按公式算完就完事公式给的是理论值真实环境还有显存碎片和分配器缓存的影响。实测下来和理论值偏差10%到15%都是正常的。有了这份实测数据你再决定是调参还是加卡说服力就强很多了。说到底买几张GPU这个问题没有标准答案但有一套标准算法。把权重、KV Cache和运行开销三笔账算清楚再结合自己的模型规模、上下文长度和并发需求答案自己就会浮现出来。希望这篇文章能帮你在部署大模型的路上少踩几个坑省下一些不必要的硬件投入。