大模型本地部署需要几张显卡？从显存、量化到并行计算的配置指南

前几天一位朋友在群里抛了个直球问题“大模型本地部署到底要几张显卡”这句话看着像硬件题实际上是一道显存、带宽、部署方式和预算约束叠在一起的综合题。用过一段时间推理框架的人都懂同一个模型在不同精度、不同并发、不同上下文长度下结论能差出两倍甚至四倍。这篇内容我就按自己实际部署时踩过的坑来讲把“几张卡”这个问题拆成三层来回答模型本身占多少显存、具体用什么精度跑、以及你想让它跑成什么样。看完你就能对着自己的机器盘算出一个靠谱的数字而不是被网上“一张卡就能跑”的说法带着走。1. 先算显存账模型到底“吃”多少内存1.1 一张卡能压住的“池子”有多大大模型推理主要吃显存而不是吃内存。显卡的显存就是一张“工作台”工作台越大能摊开的模型权重越多。目前主流显卡的显存分成几个档位消费级的 8GB、12GB、16GB、24GB专业级和工作站级的 40GB、48GB、80GB。你问“需要几张卡”本质上是在问“模型权重和运行时数据需要多大的工作台而一张工作台又有多大”。24GB 在当前本地部署的语境里是个分水岭。这个显存量级的消费级卡能覆盖大量 7B 到 32B 量化模型的推理需求也是很多人的入门配置。往上走是 40GB、48GB 的专业卡再往上就是 80GB 的旗舰计算卡。显存越大单卡能兜住的模型就越大需要的卡数自然越少。这里有个新手常犯的误区以为显存只是用来装模型文件。实际上模型文件只是其中一部分推理过程中还需要为上下文申请缓存为计算框架预留临时空间。所以不能只看模型文件占几个 GB就按这个体积去买卡。1.2 三个隐藏的“内存大户”权重、KV缓存、运行时开销显存占用可以从三个部分去拆第一部分是模型权重本身第二部分是 KV 缓存第三部分是运行时开销。模型权重可以用一个很直接的公式估算参数量乘以每个参数占用的字节数。通常说的“7B 模型”就是指 70 亿参数。如果按半精度 FP16/BF16 加载每个参数占 2 字节那么光权重就要 14GB。如果是 70B 模型还是半精度那就是 140GB。这个乘法非常朴素但很多人算到这一步就停了。第二步是 KV 缓存。这是一个很多人忽略的占显存大户。模型在生成每个 token 时都要把历史上下文的“键值对”缓存下来用于计算注意力。它的大小跟模型结构、上下文长度、并发请求数强相关。同样一个 7B 模型把上下文从 2k 拉长到 32kKV 缓存可能是几倍的差距。日常经验里7B 模型在 4k 到 8k 上下文下KV 缓存少则 1GB多则 3GB70B 这种大模型配合长上下文KV 缓存可以轻松吃掉 8 到 16GB 显存。第三步是运行时开销。CUDA 上下文、推理框架的临时缓冲区、输入输出的中间激活值这些零零碎碎通常要占 1 到 3GB。越是大型模型、越高并发这部分开销越明显。综合下来可以套用一个粗略公式显存需求约等于模型权重加上 KV 缓存再乘以 1.1 到 1.3 的余量系数。拿 7B 半精度来算14GB 权重加 2GB KV 缓存再加上 2GB 左右的运行时开销结果就在 18GB 上下。这也解释了为什么 24GB 的卡能成为入门甜点位因为它刚好能兜住一个小模型的全部开销。1.3 一张卡能兜多大的模型如果只按单张 24GB 显存来算能放下的模型大概是这个范围7B 模型全程半精度没问题13B 模型半精度会非常紧张因为权重 26GB 已经超了但用量化压低精度之后又可以放进一张卡32B 模型在半精度下完全放不下只有 4bit 或 8bit 量化之后才有可能单卡运行。至于 70B 级别的模型单张 24GB 卡无论怎么量化都很勉强通常需要两张以上的卡来分担。所以“需要几张卡”不是拍脑袋而是先算清楚显存账。算完你会得到一个“最小卡数”但最小卡数不等于推荐卡数因为还有并发、吞吐和稳定性这些后面的坑。2. 摸清主流大模型的显存需求7B、13B、32B、70B 怎么选2.1 精度和量化从“全副武装”到“轻装上阵”同样的模型加载精度不同显存需求直接腰斩。最常见的几种精度是 FP16/BF16、INT8、INT4。FP16 每个参数占 2 字节INT8 占 1 字节INT4 在压缩存储下每个参数只占 0.5 字节。把 70B 模型按不同精度加载权重分别是 140GB、70GB、35GB。这就是为什么有人用两张 24GB 卡跑 70B 模型而有人得用 4 张甚至 8 张卡核心区别就在精度上。量化当然不是免费的。INT8 对大多数场景影响很小实际部署里经常直接使用。INT4 就需要谨慎一些虽然显存省了 75%但输出质量会有可感知的下降尤其在逻辑推理、代码生成这类任务上。另一个风险是某些算子上量化支持不完整部署时可能出现算子不兼容的问题。所以量化方案不是越激进越好而是结合你手上的显存去倒推一个“能塞进去的最低精度”。2.2 一张速查表不同精度下各需要几张卡下面这张表是我实际部署时常用的参考值。权重部分按理论计算总显存按“权重 KV 缓存 运行时开销”估算KV 缓存假设在中等长度上下文和低并发场景下。表格里的卡数是“推荐偏稳”的数值不只是“极限能跑”的数值。模型规模精度权重近似含缓存总显存估算24GB 卡数80GB 卡数7BFP16/BF1614GB约 18-20GB117BINT87GB约 12GB1113BFP16/BF1626GB约 32GB2113BINT813GB约 20GB1132BFP16/BF1664GB约 80GB41 到 232BINT832GB约 46GB2132BINT416GB约 28GB2极限 1 张170BFP16/BF16140GB约 170GB8370BINT870GB约 85GB4270BINT435GB约 52GB3极限 2 张1这张表的价值在于给了你一个“档位感”。比如目标只是想本地跑一个 7B 模型做聊天问答一张 24GB 卡从头到尾都够用如果把目标换成 70B 模型还要对外提供稳定服务那么 8 张 24GB 卡或 2 到 3 张 80GB 卡是比较合理的预期。看表的时候注意几个细节所有数值都是动态的。把上下文从 4k 拉长到 32k总显存会往上走并发从 1 升到 16KV 缓存也会明显变大。所以表里的“卡数”只适合作为起点真到部署时还得反复压测确认。3. 从“塞得下”到“跑得动”为什么有时候“一张能装”还得上两张卡3.1 三种并行模式张量并行、流水线并行、数据并行很多人遇到第一个误区是“模型能塞进一张卡一张卡就够了”。但实际部署时你会发现即使模型权重只占一张卡的一半线上并发一旦上来响应速度和吞吐会迅速劣化。因为一张卡要同时处理请求排队、推理计算、内存读写算力和显存都成了瓶颈。这时候多卡的价值就体现出来了。推理部署里常见三种并行方式。张量并行是把模型的一层权重切开分布在多张卡上计算时通过高速互联协同完成。它适合单个模型太大、单卡放不下的场景。流水线并行是按层切分第一张卡算完一层传给第二张卡像工厂流水线一样。数据并行没那么复杂它在每张卡上放一个完整模型副本把不同的请求分开调度到不同的卡上能有效提升吞吐。实际推理框架里用得最多的是张量并行加数据并行。模型太大时用张量并行分摊权重模型不大但并发高时用数据并行复制多份。这两者需要的卡数是叠加的如果模型要 2 张卡做张量并行才能装下而你希望同时处理 4 倍并发那实际可能要 8 张卡因为你要开 4 份副本。3.2 并发、吞吐量、首字延迟软指标决定硬配置“跑得动”这个词包含三个指标吞吐量也就是每秒能处理多少请求首字延迟也就是用户发出请求后多久看到第一个字以及并发能力也就是同时挂多少个连接还不崩溃。对于单张 24GB 卡来说只跑一个 7B 模型单用户使用通常没什么问题。但如果做成一个小型 API 服务十几个请求同时进来显存和计算资源就会迅速被占满。我实测过一个小型 7B 模型服务单卡处理单请求的生成速度很可观但在并发到 8 个请求之后部分请求的首字延迟直接从 300 毫秒飙到 3 秒以上。解决方式很直接把模型副本扩展到两张卡或更多卡让请求分散。这就是“一张能装”和“一张够用”的区别。本地自测可以接受排队等待但对外提供服务就得按并发需求倒推卡数。一般经验是保留 20% 到 30% 的显存余量不要让显存长期处于 95% 以上的高水位。3.3 多卡并不是免费“开箱即用”显存碎片和通信开销多卡部署还有一个容易被忽略的问题通信开销。张量并行每算一层就要跨卡同步一次卡间通信越快性能损失越小。如果卡间走的是普通 PCIe 通道而不是高带宽的专用互联多卡带来的算力提升会被通信严重拖累甚至出现“八张卡跑不过四张卡”的情况。另外多卡分配也不是简单的“显存总量相加”。每张卡上都要保留操作系统、驱动和运行时占用的显存实际可用总量通常要打 5% 到 10% 的折扣。把一张 70B 模型按张量并行切到 8 张 24GB 卡上时不要觉得 8 乘以 24 等于 192GB 就能完全放下 170GB实际上每张卡可用显存只有 22GB 左右总可用大约 176GB很接近上限稍微把上下文调长一点就可能 OOM。多卡部署的另一层隐藏成本是模型加载。TP 切分后权重需要按层切好再分发到各卡加载时间会变长推理框架如果对量化格式支持不全跨卡通信还会多一层反量化和再量化拖慢速度。所有这些都不是账面上的显存数字能直接体现的。4. 部署实操从选卡到上线的一套完整步骤4.1 按预算和模型规模对照的“卡数配置方案”结合前面的计算下面给几套直接可用的配置方案。先说清楚这些方案都假设你用的是常见推理框架显存利用率设置在 90%上下文长度控制在 4k 到 8k并发目标定在低水平。场景推荐配置理由本地体验 7B 模型1 张 24GB 消费级卡FP16 加载都绰绰有余还能留出 KV 缓存余量本地体验 13B 模型1 张 24GB 卡INT8 量化权重约 14GB加 KV 缓存总显存约 20GB能跑但已接近上限本地体验 32B 模型1 张 24GB 卡INT4 量化单卡能塞但并发和上下文都不能开高更稳妥是 2 张卡个人开发调试 70B 模型4 张 24GB 卡INT8 量化显存充足能保持较高精度和中等并发对外提供 70B 模型服务2 张 80GB 专业计算卡或 8 张 24GB 卡高并发下需要数据并行副本卡数按负载继续翻倍个人做本地部署时我的倾向是“单卡容量优先于卡数”。如果预算相同用一张 48GB 专业卡往往比两张 24GB 消费卡更省心没有跨卡通信损耗不需要张量并行配置显存碎片少稳定度高。多卡是“不得不用”的选项而不是“优先选择”的选项。4.2 推理框架里的关键参数tensor-parallel-size 和显存利用率部署时最核心的配置项是两个一个是并行度另一个是显存利用率上限。以我常用的服务框架为例启动一个 7B 模型的开法是这样的python -m vllm.entrypoints.openai.api_server \ --model /data/models/7b-chat \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9如果要在两台 80GB 卡上跑 70B 模型配置改成python -m vllm.entrypoints.openai.api_server \ --model /data/models/70b-chat \ --tensor-parallel-size 2 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9tensor-parallel-size这个参数必须小于等于机器上的卡数。它的含义是把模型权重切到多少张卡上共同计算。如果你有两张卡但参数写成 1那第二张卡只是空着模型根本没用到。如果你只有一张卡参数写成 2启动阶段就会直接报错。gpu-memory-utilization控制框架最多使用多少比例的显存。我习惯写成 0.9也就是只用到 90%。剩下 10% 是给驱动、CUDA 上下文和其它进程兜底的。有些人在 24GB 卡上把利用率拉到 0.98看起来腾出了更多 KV 缓存但实际运行中经常出现莫名其妙的 OOM 或者显存分配冲突为了多几个 GB 的缓存空间把稳定性搭进去不值得。4.3 一套快速验证“卡数够不够”的检查流程配置写完不算完还得压测。我常用的做法分三步第一步看启动日志。框架加载模型后会把“模型权重大小”、“KV 缓存大小”、“可用显存总量”打出来。重点看 KV 缓存剩余量一般至少留 1GB 以上。如果日志显示剩余显存只有几百 MB赶紧调低max-model-len或增大卡数。第二步用系统命令盯实时显存。在跑推理的同时开一个监控窗口nvidia-smi -l 2两块卡都看一眼使用率。如果模型是张量并行部署两张卡的显存占用和利用率应该接近如果一张卡 90% 而另一张卡只有 10%大概率是并行参数不对或者是模型太小但并行度设太高通信开销把性能吃掉了。第三步做并发压测。用一个简单的脚本不停地发请求观察显存曲线和响应延迟。如果并发从 1 升到 16显存没有明显波动延迟还在可接受范围说明卡数是够的如果延迟很快变差说明瓶颈在算力或显存带宽这时候要么加数据并行副本要么换更大的卡。5. 我踩过的坑和给新手的几条建议5.1 最容易翻车的三个瞬间第一个翻车点只看模型权重不看 KV 缓存。我早期部署一个 13B 模型时算出来权重只有 26GB想着两张 24GB 卡绰绰有余结果把上下文调到 32k 后直接 OOM。后来查日志才发现上下文一拉长KV 缓存从 2GB 涨到 10GB 以上总显存需求完全变了一个量级。第二个翻车点多卡利用率不均。有次在 4 张卡上跑 32B 模型启动日志说权重加载成功但nvidia-smi显示只有第一张卡在忙另外三张几乎空闲。查了才发现是并行参数没配好模型整个跑在一张卡上另外三张只是挂空。这种情况性能比单卡还差因为还要承担额外的通信线程开销。第三个翻车点无脑压量化精度。INT4 虽然显存省得很香但有些模型在代码生成任务上会明显变“笨”。我有一个开源 32B 模型INT8 时写出的代码基本能跑压到 INT4 后频繁出现低级错误。如果你的场景对输出质量要求高宁愿多上一张卡也不要无条件降低精度。5.2 显存实在不够时的妥协方案量化加 CPU 卸载如果预算卡得很死一张卡就是放不下某个模型还有一个折中方案CPU 卸载。很多推理框架支持把一部分模型层或者部分 KV 缓存放到系统内存里显存只保留核心计算部分。这样确实能用更少的卡跑更大的模型但代价是性能会跌得很厉害。我之前在一台只有一张 24GB 卡的机器上试过跑 70B 量化模型开了 CPU 卸载之后生成速度从每秒钟 40 字节直接掉到每秒钟 5 字节差距接近一个数量级。这个方案适合本地验证模型效果比如确认某个 70B 模型的表现是否值得你去买更多卡但绝对不适合做实时交互或对外服务。如果你必须走这条路建议优先卸载 KV 缓存而不是权重因为权重卸载会让每一层计算都等待内存传输延迟成倍放大KV 缓存的卸载只影响长上下文场景短上下文下影响相对小。5.3 我个人的几个实战习惯从多次部署经验里沉淀下来的习惯有几个。第一个习惯是无论算出来多少显存都要额外预留 10% 到 15% 的余量。显存和磁盘不一样接近 100% 水位时性能波动会非常明显而且随时可能 OOM。哪怕你的模型算出来正好能塞进卡里我也会建议把并发和上下文打折扣或者多准备一张卡。第二个习惯是“优先调小上下文而不是优先加卡”。在跑 32B 以上模型时如果只是做单轮问答或代码生成把上下文从 32k 降到 16k可以空出好几 GB 显存效果几乎无感。很多人的显存焦虑其实是被超长上下文需求带起来的现实中未必用得到那么长。第三个习惯是记录每次部署的显存基线。拿到一个模型后先用小上下文、低并发跑一遍把权重、KV 缓存、总显存记下来再依次调大上下文和并发观察显存的增量趋势。这样就能建立一套自己的“模型显存模型”以后遇到新模型可以直接按比例预估不用每次都从零开始试错。第四个习惯是给同一个模型准备两套配置。一套是高精度低并发用于验证模型能力一套是低精度高并发用于线上服务。本地调试时用第一套发布服务时用第二套避免“调试能跑、上线就崩”的尴尬。“大模型本地部署需要几张卡”这个问题最终不是由一个模型参数决定的而是由你的使用场景、显存预算、性能目标共同决定的。先算权重账再算缓存账再算并发账最后卡数就自然浮现了。希望这篇内容能帮你在采购和配置阶段少走一些弯路。