前几天一位朋友在群里抛了个直球问题：“大模型本地部署，到底要几张显卡？”这句话看着像硬件题，实际上是一道显存、带宽、部署方式和预算约束叠在一起的综合题。用过一段时间推理框架的人都懂，同一个模型，在不同精度、不同并发、不同上下文长度下，结论能差出两倍甚至四倍。
这篇内容我就按自己实际部署时踩过的坑来讲，把“几张卡”这个问题拆成三层来回答：模型本身占多少显存、具体用什么精度跑、以及你想让它跑成什么样。看完你就能对着自己的机器盘算出一个靠谱的数字，而不是被网上“一张卡就能跑”的说法带着走。
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 拉长到 32k，KV 缓存可能是几倍的差距。日常经验里，7B 模型在 4k 到 8k 上下文下，KV 缓存少则 1GB，多则 3GB；70B 这种大模型配合长上下文，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 卡数 |
|---|---|---|---|---|---|
| 7B | FP16/BF16 | 14GB | 约 18-20GB | 1 | 1 |
| 7B | INT8 | 7GB | 约 12GB | 1 | 1 |
| 13B | FP16/BF16 | 26GB | 约 32GB | 2 | 1 |
| 13B | INT8 | 13GB | 约 20GB | 1 | 1 |
| 32B | FP16/BF16 | 64GB | 约 80GB | 4 | 1 到 2 |
| 32B | INT8 | 32GB | 约 46GB | 2 | 1 |
| 32B | INT4 | 16GB | 约 28GB | 2，极限 1 张 | 1 |
| 70B | FP16/BF16 | 140GB | 约 170GB | 8 | 3 |
| 70B | INT8 | 70GB | 约 85GB | 4 | 2 |
| 70B | INT4 | 35GB | 约 52GB | 3，极限 2 张 | 1 |
这张表的价值在于给了你一个“档位感”。比如目标只是想本地跑一个 7B 模型做聊天问答，一张 24GB 卡从头到尾都够用；如果把目标换成 70B 模型，还要对外提供稳定服务，那么 8 张 24GB 卡或 2 到 3 张 80GB 卡是比较合理的预期。
看表的时候注意几个细节：所有数值都是动态的。把上下文从 4k 拉长到 32k，总显存会往上走；并发从 1 升到 16，KV 缓存也会明显变大。所以表里的“卡数”只适合作为起点，真到部署时还得反复压测确认。
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 缓存、总显存记下来；再依次调大上下文和并发，观察显存的增量趋势。这样就能建立一套自己的“模型显存模型”，以后遇到新模型可以直接按比例预估，不用每次都从零开始试错。
第四个习惯是给同一个模型准备两套配置。一套是高精度低并发，用于验证模型能力；一套是低精度高并发，用于线上服务。本地调试时用第一套，发布服务时用第二套，避免“调试能跑、上线就崩”的尴尬。
“大模型本地部署需要几张卡”这个问题，最终不是由一个模型参数决定的，而是由你的使用场景、显存预算、性能目标共同决定的。先算权重账，再算缓存账，再算并发账，最后卡数就自然浮现了。希望这篇内容能帮你在采购和配置阶段少走一些弯路。
: 选择题和判断题（题解）)
