前几天有个做AI应用的朋友问我我想在公司内网部署一个开源大模型用来做内部问答到底得买几张卡这个问题听起来简单但直接问几张卡其实问错了方向。答案不是N张而是由三个变量决定的模型参数量、运行精度、你要跑的是推理还是训练。同样一个7B70亿参数级别的模型如果只做问答推理一张24GB显存的显卡就能跑如果要做全参微调五六张24GB的卡可能都紧张如果还要塞进很长的上下文光是缓存就可能吃掉你大半张卡。这篇文章我会把大模型本地部署需要几张卡这件事彻底拆开先算清显存这笔账再讲单卡和多卡的边界在哪里然后直接给出一张可以按场景对号入座的估算表最后说说我自己在实操里踩过的那些坑。如果你也在纠结该买几张卡、买多大显存的卡这篇文章应该能帮你少花不少冤枉钱。1. 先记住这个公式模型显存不是参数直接乘21.1 参数量、精度字节数、总显存的关系所有显存估算都从同一个公式开始模型权重占用 参数量 × 每个参数占用的字节数这里每个参数占用的字节数由精度决定。常用精度有几种FP32是4字节FP16/BF16是2字节INT8是1字节INT4是0.5字节。所以一个7B模型用FP16加载权重占用是7 × 2 14GB左右换成INT8就大约是7GB换成INT4就只剩3.5GB上下。很多人听到FP16需要14GB的第一反应是那我16GB显存的卡应该够吧——这只是权重你还没算运行时的KV Cache、激活值、框架自带的临时缓冲。实际跑起来16GB的卡加载一个7B模型FP16版本一个请求没问题一开并发或者上下文一长照样会OOM。这就是为什么我习惯按权重占用 × 1.3到1.5来预估最少显存后面章节我会详细讲这0.3到0.5是从哪来的。1.2 推理、微调、全参训练三笔完全不同的账本地部署这个词其实很模糊它至少包含三种场景纯推理只加载权重跑前向计算。显存需求 权重 KV Cache 激活值 框架开销。高效微调比如做LoRA大部分参数冻结只训练低秩矩阵。显存需求 权重 梯度 优化器状态 激活值。全参训练/继续预训练所有参数都更新。显存需求 权重 梯度 优化器状态 激活值而且优化器状态是大头。这里的关键区别是梯度和优化器状态究竟占多大。推理是不需要梯度的所以权重之外的开销相对温和。一旦进入训练每个参数要额外保存梯度然后Adam优化器还会为每个参数保存一阶动量、二阶动量以及一份FP32的权重副本。按照最常见的混合精度训练配置一个参数在训练状态下大约要占到16字节FP16权重2字节、FP16梯度2字节、FP32主权重4字节、FP32一阶动量4字节、FP32二阶动量4字节。这样算下来7B模型全参训练的显存需求量是7 × 16 112GB随便就是5张24GB显存的卡起步。而如果只做推理7B模型FP16也就是14GB多一点一张24GB的卡就足够了。这三笔账差着数量级所以问需要几张卡之前先问自己我到底要做什么。1.3 那些被忽略的额外开销KV Cache和激活值权重算清楚了还不能高兴太早因为推理时的KV Cache会随上下文长度线性增长。KV Cache是什么简单说模型在生成每一个新token时需要不断回顾前面所有token的注意力信息。为了不重复计算框架会把前面token的Key和Value缓存下来这个缓存就是KV Cache。KV Cache的占用可以这样近似KV Cache字节数 ≈ 2 × 层数 × 隐藏层维度 × 序列长度 × 精度字节数拿常见的7B级别模型来举例假设32层、隐藏层维度4096、用FP16计算那么每个token的KV Cache大约是2 × 32 × 4096 × 2 约524KB。也就是说生成1000个token的上下文KV Cache就要占用约0.5GB生成10000个token就要5GB左右。如果序列长度拉到100K级别不好意思KV Cache能轻松吃掉几十GB显存。所以你会看到一种很反直觉的现象模型权重只有14GB24GB的卡按理说是够的但一旦把上下文调到很大的档位照样爆显存。这就是KV Cache在背后搞鬼。训练场景里的激活值也是一样的道理尤其是序列很长、batch size很大的时候激活值甚至可能超过权重本身好在训练框架普遍支持gradient checkpointing这种用计算换显存的策略可以把激活值压下去不少。2. 单卡场景的边界在哪里推理、量化与显存余量2.1 24GB显存是单卡推理的坎如果你只是做推理一张24GB显存的显卡其实是目前性价比最高的单卡方案。为什么是24GB这个档位因为7B级别的模型FP16需要约14GB权重加上KV Cache和框架开销24GB刚刚好能覆盖常规场景13B/14B级别的模型用FP16就需要约26GB到28GB严格来说24GB超了但用INT8量化后可以压到15GB左右24GB也能跑。如果是30B到32B级别的模型FP16权重就要60GB以上24GB单卡基本没戏只能用INT4量化后勉强塞进去差不多正好卡在24GB的边缘。所以对绝大多数个人开发者和中小团队来说24GB显存的单卡意味着7B轻松跑、14B可以跑、32B靠量化硬撑、70B想都不要想。那48GB和80GB级别的专业卡又是什么体验48GB单卡可以直接FP16跑14B级模型还可以给32B级模型留出宽裕的量化空间80GB级别的旗舰卡可以直接跑32B甚至更大一点点的模型也能用FP8/INT8去处理更大的模型。我实测下来80GB单卡做70B级别模型的INT4推理是勉强能用的但速度一般着实谈不上愉快。2.2 量化是把双刃剑省显存但不省心谈到单卡跑大模型就不能不提量化。量化本质上就是降低参数精度来省显存比如把FP16的权重变成INT8或INT4。从算账角度看很划算7B模型FP16要14GBINT8只要7GBINT4只要3.5GB一张16GB的卡都能跑了。但量化是有代价的而且这个代价不只是精度略微下降这么简单。高版本的混合精度量化技术在推理时可以把损失控制得很小可一旦量化到INT4尤其是不加任何补偿方案的幼稚量化模型的输出质量会有肉眼可见的下跌逻辑推理能力、长文本稳定性都会打折。更麻烦的是有些量化格式对算子支持不完整你在一个框架里量化好的文件换到另一个框架可能跑不起来或者某些层被强制回退成高精度计算显存没省多少速度还变慢了。我做过的建议是单卡推理优先试INT8这一步通常不损失太多质量而且显存占用直接减半如果INT8仍然爆显存再上INT4。不要上来就图最省显存的方案先用能用的精度跑通业务再去优化显存。2.3 一张卡也能跑的典型场景和实际效果单卡跑大模型不是纸上谈兵我见过不少团队真的就是这么干的。举个最常见的例子某开发者在公司内网部署了一个7B级别模型用24GB的消费级显卡INT8精度上下文限制在4096 token以内同时最多接受2到3个并发请求。实测下来的感受是单请求延迟可以做到几百毫秒到一两秒虽然在GPU利用率上远不如专业卡但胜在便宜部署方便。另一个场景是个人开发者自己做知识库问答。用一张大显存显卡加载14B级别模型配合向量检索和RAG框架把上下文控制得很短效果相当能打成本只要一张显卡的钱加一台普通服务器。这里要注意的是单卡推理的瓶颈往往不在显存而在显存带宽。权重在显存里就2字节一个参数每次生成一个token都要把所有参数过一遍所以卡的显存带宽越高生成速度越快这和游戏显卡的游戏帧率逻辑不完全一样。3. 多卡不是加几张显卡那么简单并行方式和互联瓶颈3.1 三种并行方式张量并行、流水线并行、数据并行一旦单卡装不下自然就要考虑多卡。但多卡并不是说把两张卡像组双硬盘一样拼起来就能当一张大显存卡用你得选择并行方式。主流的做法有三类。张量并行是把一个线性层的矩阵切成几块分给多张卡卡之间每算一步都要同步通信。这种并行对于Attention层和MLP层的效果最好也是你在常见推理框架里看到的那种4卡加载大模型的主要做法。流水线并行是把整个模型按层切段第一张卡负责前面若干层第二张卡负责后面若干层数据像流水线一样经过各卡。它的通信量比张量并行小但有流水线气泡问题就是某一段算完得等前面算完才能接力利用率会有损失。数据并行则是每张卡都放一份完整的模型把不同批次的数据分给不同卡去算训练时再把梯度同步一下。这种并行省心但显存不会省因为每张卡都装着完整权重。本地部署大模型时最常见的是张量并行。两个40GB显存的计算卡通过高速互联方案合起来就能加载80GB级的大模型权重这是很多中型团队跑70B级别开源模型的标准配置。3.2 卡间带宽才是多卡方案的生死线关键问题来了多卡不是显存简单相加。张量并行的通信频率非常高每算一两个算子就要做一次AllGather或者ReduceScatter。这时候卡间互联带宽决定了你加第二张卡到底是11约等于2还是11约等于1.2。我打个比方单卡运行大模型相当于一个团队里所有人都在一间大办公室传材料递个文件都很方便多卡张量并行相当于把团队拆成几个办公室每干一步活都要通过走廊递一次材料走廊越窄效率越低。如果你的多卡方案用的是普通PCIe转接方案卡间通信带宽可能只有几十GB每秒这时候跑大模型理论上显存翻倍了但实际吞吐量可能只提升了20%到30%。如果用的是专用的高带宽互联方案那两张卡几乎像一张卡一样协同工作效率接近线性提升。所以我一直跟人说打算上多卡之前先搞清楚你的主板插槽、供电方案和卡间互联方案是不是能组成一个整体而不是二三十张卡简单塞进机器里。3.3 两张卡拼起来之后仍要面对的不完美即便互联方案到位了多卡也不是没代价。第一张量并行的显存还会多出一些通信缓冲区和切分开销意味着2张40GB80GB的实际可用显存往往要打个九折。第二多卡推理的启动时间会更长因为初始化时要分配和同步通信缓冲区小请求可能感受不到速度优势反而因为启动开销变慢。第三显存利用率不均衡很常见有的层切分后负载高、有的层负载低某一张卡爆满另一张卡却在打盹。所以我的经验是如果你的模型量级只是24GB单卡通过量化硬撑一下的情况不要急着加第二张卡先把量化和上下文优化做好很多时候省下的是一整张卡的钱。真正需要上多卡的场景通常是模型大小已经稳定超过了单卡极限且你会长期高频使用。4. 按场景对号入座推理、微调、全量训练各需要几张卡4.1 一张估算表覆盖主流模型规模说了这么多理论我直接给一张可以落地的参考表。这里的卡默认指的是24GB显存级别的显卡也就是目前中小团队最常用的档位如果换成48GB或80GB级别的专业计算卡数量可以大幅缩减。模型规模纯推理FP16纯推理INT8/INT4LoRA微调全参训练/继续训练3B级别约30亿参数1张24GB1张24GB甚至更小1张24GB2-4张24GB7B级别约70亿参数1张24GB1张24GB1张24GBINT8/OFFLOAD也可4-8张24GB13B/14B级约130-140亿参数1张48GB或2张24GB1张24GBINT82-4张24GB8张24GB起步30B/32B级约300亿参数2张48GB或4张24GB1张48GB或2张24GBINT48张24GB不太好跑基本要上多节点方案70B级约700亿参数8张24GB或4张48GB4张24GBINT4勉强不建议用24GB卡跑建议直接用80GB级集群这张表的依据是哪来的7B全参训练前面算过约112GB4张24GB是96GB不够所以至少要5张实际考虑到激活值8张24GB才稳。13B/14B全参训练就是约224GB起步8张24GB正好处于临界点。30B级以上全参训练24GB级别的卡拼起来既费电又费互联带宽性价比远不如大显存专业卡。4.2 纯推理场景怎么精确定卡数纯推理场景有一个更精确的流程。先把模型权重显存算出来再预估你要支持的并发数和上下文长度然后加上KV Cache最后留出20%左右的余量。举个例子你部署一个7B模型FP16权重14GB计划支持4个并发请求每请求上下文约4096 token。KV Cache单个请求约占2GB4个就是8GB加上权重14GB、框架开销和CUDA上下文占用你会得到25GB以上的总需求。这时候一张24GB的卡就悬了要么把上下文降到2048要么用INT8量化给权重减负要么限制并发到2个。如果你的业务必须支持几十个并发那单卡根本不用考虑直接上多卡方案因为KV Cache会随着并发数成倍增长。4.3 训练场景的卡数翻倍逻辑训练场景的卡数估算正确的起点是优化器状态而不是权重本身。前面说过全参训练Adam混合精度下每个参数大约要占16字节7B模型就是112GB。这个需求只和参数量有关和你的卡数无关——你用的卡越多每张卡摊到的显存负载越小但总量不会变少。LoRA这类高效微调为什么省卡因为低秩矩阵只更新极少量参数优化器状态也只维护那些更新参数的状态所以7B模型做LoRA的显存需求可以降到和推理差不多甚至略高一点的水平一张24GB卡完全能跑。很多开源框架在单卡上跑LoRA时甚至还会把冻结的参数部分offload到CPU内存来进一步省显存代价只是训练速度变慢。如果你只是想微调一个内部模型LoRA是性价比最高的方式。5. 理论算得够实际还是卡那些被忽略的开销5.1 长上下文是显存最大的隐形杀手我在1.3小节算过KV Cache的公式但很多人对它的爆发力没有感觉。拿一个80GB显存的专业卡来说跑70B级别模型INT8量化权重占70GB左右剩下10GB的余量看起来也不少。可一旦上下文长度拉到32KKV Cache直接吃掉几十GB80GB的卡照样爆。这就是为什么现在很多模型服务框架要单独做上下文管理比如动态回收久未使用的KV Cache、用paged attention机制按页分配显存目的都是控制这个大头。如果你在本地跑大模型又需要长上下文最直接的办法是限制maximum length。很多业务场景其实根本用不到几万token的长上下文把限制从32K降到8K显存压力立刻小一个量级。做RAG的时候与其一次性把一大堆文本塞进上下文不如拆成小段分段检索效果和显存占用都会好很多。5.2 并发请求会让显存按倍数膨胀权重是固定开销但KV Cache是和并发数线性相关的。一个请求有一条独立的上下文两个请求就有两份KV Cache十个请求就是十份。所以单卡能跑7B和单卡能扛住20个并发同时跑7B完全是两回事。我自己做过一次简单压测同一个7B模型FP16不限制并发时显存占用约16GB左右开到4个并发显存占用涨到约20GB开到8个并发直接突破24GB。如果你只给自己用那单卡确实够如果你想给整个团队当服务用就得把并发数乘以单请求的KV Cache算账不然分分钟OOM。5.3 我突然爆显存了常见原因到底是谁老是被明明理论够跑起来却爆显存困扰的朋友可以从这几个原因里排查。权重版本与精度设置不一致你下的是FP16权重框架为了计算精度又用FP32跑归一化层多出来的几个GB就爆了。CUDA上下文与框架缓存PyTorch的CUDA缓存机制很霸道不是用完就立刻释放它会为后面的计算预留空间所以你看到的显存占用比实际需要的多好几GB。显卡本身的显示功能占用如果你同时接着显示器GPU会预留一部分显存给显示输出服务器核显还好消费级显卡通常要少几百MB。碎片化问题反复加载卸载小张量后显存会被碎片占满明明剩余总量不少却分配不出一块连续的显存。遇到OOM我建议先看一眼nvidia-smi里的GPU Memory Usage和Processes列把进程占用和模型理论值对一下通常很快能找到是哪个环节多吃了显存。5.4 CPU offload是救急药不是常用药显存实在不够的时候可以把权重的一部分放到CPU内存里用的时候再临时加载到GPU。这个方案我可以明确说它是用来跑通实验、让流程不断在低配环境下验证业务的不适合真正的高频线上服务。因为CPU到GPU的传输速度远低于显存内部的带宽权重每次换入换出都要排队吞吐量会大幅下降。我自己测过一个14B模型在24GB卡上用offload跑推理生成速度可能只有几百毫秒一个token比全显存加载慢十几倍。对偶尔跑个测试来说能忍但对交互式产品来说基本不可用。所以如果你确定模型以后要服务很多用户别把offload当常态该买卡就买卡。6. 我踩过几次坑之后的选卡心得6.1 先跑小模型验证再决定买几张卡我的第一个建议其实很反直觉别一开始就照着大模型的部署目标去买卡。先把你要用的模型降一档跑一个小规模版本比如本来想用30B的模型先用7B版把推理流程、prompt格式、RAG链路全打通量一量单请求的显存峰值、生成延迟、并发上限。这样做的好处是你能用几块硬盘钱拿到真实数据再推算大模型需要多少显存而不是靠公式估算。有一次我评估一个大模型的内部服务化方案按理论算8张24GB卡够用结果实际跑起来因为并发和上下文开得太大8张全满幸好先用7B模型做了压测才提前发现了这个问题改成64GB大显存方案最后4张就解决了。6.2 显存不够时优先砍什么顺序很重要遇到显存紧张砍东西的顺序直接影响效果。我一般按这个优先级先缩短上下文长度这是最有效的一刀通常能砍掉一大块KV Cache然后降并发数用排队策略把瞬时并发压下来再做量化从FP16降到INT8再不行INT4最后才考虑换小模型。很多人一上来就直接换小模型其实没有必要。很多场景里7B模型和14B模型的效果差距并没有想象中大而显存占用差了快一倍。把上下文、并发、量化三板斧打完往往7B能顶住的任务就不用换更小的模型了。6.3 用监控工具把显存情况看清楚本地部署大模型不是部署完就完事了后面调优全靠监控。我的习惯是开一个终端挂着nvidia-smi的实时刷新模式或者用更友好的nvtop看每块卡的实时利用率、显存占用、温度功耗。在压测时长上下文、高并发的时候紧盯显存曲线的变化看看是哪一块先被打满往往能暴露并行切分不均的问题。另一个经验是部署脚本里尽早加上显存预检。比如服务启动时读取nvidia-smi --query-gpumemory.free如果剩余显存低于模型估算需要的120%直接拒绝启动并打印原因。这一招帮我在多卡机器上杜绝了很多次因为显存被其他任务占用导致模型启动即崩溃的情况。6.4 别忘了CPU内存、硬盘和供电这些周边最后提醒一个典型的翻车点显卡显存够了但CPU内存不够。加载7B模型到显存时通常要先读入CPU内存再转过去如果你CPU内存只有16GB加载14GB权重的过程就可能把整台机器卡死。更夸张的是全参训练场景CPU内存通常要有显存总需求的一半或持平才玩得转不然光是在CPU和GPU之间导数据就卡得要命。硬盘也容易被忽略。大模型权重文件动辄几十GB从机械硬盘加载和从固态加载的体验差距巨大本地部署强烈建议用固态硬盘。供电和散热就是另一个层面的事了我曾经在一台额定功率只比峰值功耗贵一点点的机器上跑双卡训练没跑多久就开始降频掉速排查了半天发现是电源余量不足。说白了大模型本地部署需要几张卡本质上是一个预算和场景的权衡题。把显存账算准、把并行方案选对、把上下文和并发控制好你会发现很多场景根本不需要堆那么多卡而真正需要堆卡的场景也千万别只盯着显存容量互联带宽和整体系统的匹配程度可能更加要命。我在实际项目中反复体会到的就是先小规模验证再逐步加资源比一开始就按最大规格配齐要稳妥得多也省钱得多。