企业官网建设流程全解析

前几天有个做AI应用的朋友问我：我想在公司内网部署一个开源大模型，用来做内部问答，到底得买几张卡？这个问题听起来简单，但直接问"几张卡"，其实问错了方向。答案不是"N张"，而是由三个变量决定的：模型参数量、运行精度、你要跑的是推理还是训练。同样一个7B（70亿参数）级别的模型，如果只做问答推理，一张24GB显存的显卡就能跑；如果要做全参微调，五六张24GB的卡可能都紧张；如果还要塞进很长的上下文，光是缓存就可能吃掉你大半张卡。

这篇文章我会把"大模型本地部署需要几张卡"这件事彻底拆开：先算清显存这笔账，再讲单卡和多卡的边界在哪里，然后直接给出一张可以按场景对号入座的估算表，最后说说我自己在实操里踩过的那些坑。如果你也在纠结该买几张卡、买多大显存的卡，这篇文章应该能帮你少花不少冤枉钱。

1. 先记住这个公式：模型显存不是参数直接乘2

1.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显存。

所以你会看到一种很反直觉的现象：模型权重只有14GB，24GB的卡按理说是够的，但一旦把上下文调到很大的档位，照样爆显存。这就是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要14GB，INT8只要7GB，INT4只要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。这时候卡间互联带宽决定了你加第二张卡到底是"1+1约等于2"还是"1+1约等于1.2"。

我打个比方，单卡运行大模型相当于一个团队里所有人都在一间大办公室，传材料递个文件都很方便；多卡张量并行相当于把团队拆成几个办公室，每干一步活都要通过走廊递一次材料，走廊越窄，效率越低。

如果你的多卡方案用的是普通PCIe转接方案，卡间通信带宽可能只有几十GB每秒，这时候跑大模型，理论上显存翻倍了，但实际吞吐量可能只提升了20%到30%。如果用的是专用的高带宽互联方案，那两张卡几乎像一张卡一样协同工作，效率接近线性提升。所以我一直跟人说：打算上多卡之前，先搞清楚你的主板插槽、供电方案和卡间互联方案是不是能组成一个整体，而不是二三十张卡简单塞进机器里。

3.3 两张卡"拼"起来之后，仍要面对的不完美

即便互联方案到位了，多卡也不是没代价。第一，张量并行的显存还会多出一些通信缓冲区和切分开销，意味着"2张40GB=80GB"的实际可用显存往往要打个九折。第二，多卡推理的启动时间会更长，因为初始化时要分配和同步通信缓冲区，小请求可能感受不到速度优势，反而因为启动开销变慢。第三，显存利用率不均衡很常见，有的层切分后负载高、有的层负载低，某一张卡爆满另一张卡却在打盹。

所以我的经验是：如果你的模型量级只是"24GB单卡通过量化硬撑一下"的情况，不要急着加第二张卡，先把量化和上下文优化做好，很多时候省下的是一整张卡的钱。真正需要上多卡的场景，通常是模型大小已经稳定超过了单卡极限，且你会长期高频使用。

4. 按场景对号入座：推理、微调、全量训练各需要几张卡

4.1 一张估算表，覆盖主流模型规模

说了这么多理论，我直接给一张可以落地的参考表。这里的"卡"默认指的是24GB显存级别的显卡，也就是目前中小团队最常用的档位；如果换成48GB或80GB级别的专业计算卡，数量可以大幅缩减。

这张表的依据是哪来的？7B全参训练前面算过约112GB，4张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单个请求约占2GB，4个就是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的余量看起来也不少。可一旦上下文长度拉到32K，KV Cache直接吃掉几十GB，80GB的卡照样爆。这就是为什么现在很多模型服务框架要单独做上下文管理，比如动态回收久未使用的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-gpu=memory.free，如果剩余显存低于模型估算需要的120%，直接拒绝启动并打印原因。这一招帮我在多卡机器上杜绝了很多次因为显存被其他任务占用导致模型启动即崩溃的情况。

6.4 别忘了CPU内存、硬盘和供电这些"周边"

最后提醒一个典型的翻车点：显卡显存够了，但CPU内存不够。加载7B模型到显存时，通常要先读入CPU内存再转过去，如果你CPU内存只有16GB，加载14GB权重的过程就可能把整台机器卡死。更夸张的是全参训练场景，CPU内存通常要有"显存总需求的一半或持平"才玩得转，不然光是在CPU和GPU之间导数据就卡得要命。

硬盘也容易被忽略。大模型权重文件动辄几十GB，从机械硬盘加载和从固态加载的体验差距巨大，本地部署强烈建议用固态硬盘。供电和散热就是另一个层面的事了，我曾经在一台额定功率只比峰值功耗贵一点点的机器上跑双卡训练，没跑多久就开始降频掉速，排查了半天发现是电源余量不足。

说白了，大模型本地部署需要几张卡，本质上是一个预算和场景的权衡题。把显存账算准、把并行方案选对、把上下文和并发控制好，你会发现很多场景根本不需要堆那么多卡；而真正需要堆卡的场景，也千万别只盯着显存容量，互联带宽和整体系统的匹配程度可能更加要命。我在实际项目中反复体会到的就是：先小规模验证，再逐步加资源，比一开始就按最大规格配齐要稳妥得多，也省钱得多。