企业官网建设流程全解析

先别急着数卡，先说清楚需求。经常有人一上来就问我：“大模型本地部署需要几张卡？” 我一般会反问一句：你想部署多大的模型，准备几个人用，跑多长的上下文？这三个问题没答上来，任何“几张卡”的回答都是在猜。因为“几张卡”从来不是一个固定数字，而是一笔需要自己算的账。这篇文章就是把这笔账彻底拆开：从模型参数、量化、KV Cache 这些硬指标，到张量并行、流水线并行背后的通信开销，再到 7B、13B、32B、70B 各档模型的实际卡数参考和排错经验。无论你是刚入坑想在本地跑个小模型尝鲜，还是团队里要搭一个内网推理服务，都能照着算出来。

1. 先别急着数卡：把需求讲清楚再算账

1.1 你是自己玩、团队内网用，还是对外提供服务？

同样是“本地部署”，三种场景对卡数的要求差出好几倍，必须先分清楚。

第一种是自己玩或者做技术验证。这种场景通常单用户、低并发、不追求稳定在线，对延迟的容忍度也高。哪怕模型稍微大一点，跑慢点也能接受。这种情况下，一张显存过得去的消费级显卡往往就够起步了，核心任务是先把模型跑通、把效果验证了。

第二种是团队内网部署。两三同事、几十个同事用一个服务，这时候要考虑的就是并发和可用性：同时几个人提问，每个请求占多少显存，模型能不能稳定跑一整天不 OOM。这种场景下，单卡的显存上限会很快成为瓶颈，多卡方案开始变得必要。

第三种是对外提供服务或者支撑核心业务。高并发、低延迟、不能挂，这时候除了卡数，还要考虑推理框架的优化、批处理吞吐、甚至是冗余备份。卡的数量不只是“能不能装下模型”，而是“能不能扛住流量”。

所以开头那句话不是废话，它直接决定你是该买一张大显存卡、两张卡做并行，还是一整个多卡节点。

1.2 决定卡数的三个变量：显存、算力、卡间带宽

把需求拆开之后，落到硬件层面，真正决定卡数的变量就三个：显存、算力、卡间带宽。

显存是最直观的账。模型权重、KV Cache、激活值、框架本身的开销，全都要住在显存里。显存不够，模型根本加载不进去；就算硬塞进去，一跑长上下文也立刻爆。算力决定的是生成速度：每秒吐几个 token、同时能扛几个人。很多人的误区是“卡越多越快”，但如果你只是单用户聊天，7B 这种小模型一张卡反而比两张卡快，因为多卡之间的通信开销可能比计算节省还大。

卡间带宽是多人最容易忽略的。多卡跑一个大模型的时候，几乎每一层都要做一次跨卡通信。如果卡之间走的是高速互连总线，通信开销可控；如果只是走传统的 PCIe 通道，那数据搬运的时间可能比计算本身还长。

这三个变量合起来，就是“需要几张卡”的完整答案。显存决定下限，算力决定体验，卡间带宽决定多卡方案划不划算。

2. 一张卡能不能跑？先搞懂显存账本

2.1 模型参数与显存的换算关系

判断一张卡够不够，第一步是算模型权重占多少显存。公式非常简单：

权重显存 = 模型参数量 × 每个参数占用的字节数

主流模型用 FP16 或 BF16 精度存储参数时，每个参数占 2 字节。所以：

• 7B 模型：70 亿参数，约 14GB 权重
• 13B 模型：约 26GB 权重
• 32B 模型：约 64GB 权重
• 70B 模型：约 140GB 权重

注意这只是权重本身。实际部署时，显存里还要塞几样东西：KV Cache（后面细说）、激活值、推理框架和底层库的固定开销。固定开销通常小几百MB到1-2GB，但KV Cache 可以轻松吃掉比权重还多的显存。

我习惯把公式再扩展一步：

单卡所需显存 ≈ 权重显存 + KV Cache 显存 + 激活值与框架开销（1~2GB）

拿 7B FP16 举例：14GB 权重 + 4K 上下文约 2GB KV + 2GB 框架开销，总共 18GB 左右。这意味着单张 16GB 的卡会很紧张，24GB 的卡就比较从容。这是很多人“明明模型只有14GB，16GB显卡却跑不起来”的原因——你只算了权重，没算周边开销。

2.2 量化是本地部署的“减脂手术”

如果显存不够，最有效的办法是量化。量化本质上就是降低每个参数的存储精度，压缩权重体积，代价是模型效果有轻微的精度损失。

• INT8 量化：每个参数占 1 字节，7B 模型约 7GB
• INT4 量化：每个参数约 0.5 字节，7B 模型约 3.5GB
• 更低精度的量化方案也常见，但效果退化会更明显

量化的账很好算。同样是 70B 模型，FP16 要 140GB，INT4 只要 35GB 左右。一张 24GB 显卡确实装不下 FP16 的 70B，但两张 24GB 卡跑 INT4 的 70B 是完全可行的。这也是本地大模型部署里最常用的“降显存”手段。

实操经验是：先用 FP16 或 BF16 把模型效果验证通过，再决定要不要量化到 INT4 去提吞吐。如果只是内部工具、对回答内容敏感度不高，INT4 完全够用；但如果涉及代码生成、数学推理这类对精度敏感的任务，量化后效果退化会更明显，要谨慎。

2.3 KV Cache 与上下文长度同样吃显存

KV Cache 是推理过程中缓存历史 token 中间状态的内存，很多人第一次算显存时完全忘了它，结果一跑长上下文就 OOM。

KV Cache 的粗略公式可以记成：

每个 token 的 KV 占用 ≈ 层数 × 隐藏维度 × 2（K和V） × 字节数

一个典型的 7B 模型，假设 32 层、隐藏维度 4096、FP16 精度，那么每个 token 大约占 512KB。4K 上下文就是 2GB，32K 上下文就是 16GB，还没算并发。

这就是关键结论：上下文越长、并发越高，KV Cache 吃掉的显存越多，甚至可能远超权重本身。所以部署时一定要把“模型权重显存”和“KV Cache 预算”分开算。我的习惯是：先定好最大上下文长度和预期并发数，算出 KV 上限，再反推需要多少显存。日常个人使用，单用户 4K 上下文还好说；一旦做成多用户服务，KV 这头往往是决定卡数的第一因素。

3. 多卡部署的核心逻辑：三种并行到底怎么选

3.1 张量并行、流水线并行、数据并行各管什么

模型太大一张卡装不下，那就把负载拆到多张卡上。拆法主要有三种，管的事完全不同。

数据并行最简单：每张卡都放一份完整模型，把不同的请求分给不同卡处理。它不解决“单卡装不下模型”的问题，但能解决“并发高了单卡扛不住”的问题。团队内部几十个人同时用，数据并行把请求摊开，每张卡只处理自己那份。

张量并行是拆模型本身：把每一层的权重矩阵按行或列切成多块，分别放在不同卡上，一次推理请求由所有卡协作完成。这是本地部署大模型最常用的并行方式，因为单张卡显存装不下时，张量并行能把权重和 KV 都摊到多张卡上。代价是每一层都要做一次跨卡通信。

流水线并行则是按层切分：卡 A 跑前面的层，卡 B 跑后面的层，数据像流水线一样流过去。通信量比张量并行小，但会有流水线气泡——部分卡在等待前面卡算完，利用率打折扣。实际很少单独用，更多是和张量并行组合。

部署推理服务时，我的建议优先级是：模型单卡能装下就用单卡 + 数据并行扩展并发；单卡装不下再上张量并行；流水线并行通常是在跨节点部署时才考虑。

3.2 为什么不是卡越多越快

这是新手最容易踩的误区。你以为加一张卡速度翻倍，实际可能是变慢。

原因在于张量并行每一层都要做同步通信。以 7B 模型为例，单卡跑一层可能只要几毫秒，但拆到两张卡上，每层多了一次通信和数据同步，如果卡间带宽不够，通信时间可能比计算时间还长。结果就是：两张卡跑 7B，比一张卡更慢。

我实测过不少配置，规律大概是这样的：模型越小、批处理越小，加卡的收益越低甚至为负；模型越大、并发越高，加卡的收益越明显。所以大厂部署 70B 以上模型动辄八卡，不是炫富，是模型大得单卡实在装不下，而且大模型单层计算量大，通信占比相对变小，多卡摊薄权重显存后反而划算。

另一个视角是扩展效率：两张卡理论上限是 2 倍，实际上因为通信开销，能做到 1.7~1.8 倍就不错；四张卡堆到 3~3.5 倍也算健康。低于这个数，先别急着再加卡，大概率是通信瓶颈或者并行配置不对。

3.3 多卡方案的通信前提：卡间互连和 PCIe 差多远

多卡部署最容易被忽视的硬件参数，是卡与卡之间的通信链路。

同一台机器内的多张卡，如果通过高速互连总线直连，通信延迟低、带宽高，张量并行跑起来效率才像样。如果只是通过传统的 PCIe 通道互通，数据搬运的带宽和延迟就差了一个数量级，张量并行的通信损耗会非常明显。

所以选多卡方案时有几个实操准则：同一张量并行组的卡，尽量放在同一台机器内，别跨机箱；跨机箱通信基本只能走网络，张量并行就别考虑了。消费级双卡通过 PCIe 跑张量并行，能跑但效率打折，如果预算允许，用一张大显存卡替代两张小显存卡往往是更省心的选择。

一句话总结：加卡之前先搞清楚你的卡是怎么连的，再决定要不要走多卡方案。

4. 不同规模模型到底要几张卡：一张可抄作业的参考表

4.1 7B~13B：消费级单卡起步

先给一个权重显存的速查表，所有数字都是近似值：

7B 是目前本地部署最主流的规模。INT4 量化后权重只有 3.5GB，一张 8~12GB 显存的卡就能跑，适合个人尝鲜、写代码辅助、本地 RAG 问答这类场景。FP16 完整精度则推荐 24GB 显存起步，因为还要给 KV Cache 和并发留空间。

13B 是比 7B 聪明一档但代价也高一档的存在。INT4 权重约 6.5GB，12~16GB 显存可以跑，但上下文和 KV 空间会比较紧；FP16 权重约 26GB，单卡 32GB 或者双卡 16GB 张量并行都能跑。团队小规模使用、希望效果比 7B 好，13B 是很实用的中间档。

4.2 32B~70B：双卡到八卡的取舍

32B 和 70B 是本地部署的分水岭，也是“几张卡”这个问题问得最多的地方。

32B FP16 权重约 64GB，单卡 80GB 显存的数据中心级加速卡能装下，或者三张 24GB 卡做张量并行也行。但绝大多数人不需要 32B 的 FP16，INT4 量化后只有 16GB 权重，一张 24GB 卡就能跑，加上 KV Cache 也富余。所以 32B 真正的主流配置是“单张 24GB 卡 + INT4”，性价比非常高。

70B 才是真正考验多卡方案的门槛。INT4 量化后权重约 35GB，两张 24GB 卡做张量并行刚好装下，但要留意 KV Cache 会让显存压力变大，上下文和并发需要克制一些。FP16 权重约 140GB，推荐方案是两张 80GB 卡，或者八张 24GB 卡做张量并行加数据并行的组合。

下面这张表可以直接参考：

我自己的体验是：能用单卡解决的，绝不轻易上双卡；能用 INT4 解决的，绝不硬上 FP16。卡数越少，硬件、供电、散热、通信的麻烦事越少。

4.3 多模型并发服务时怎么算卡数

很多人算完单模型显存就觉得完事了，但一旦做成服务，并发会直接把显存账翻倍。因为每个并发请求都会额外占用一份 KV Cache。

结合前面的公式算一笔账：7B INT4 模型，权重约 3.5GB；假设 4K 上下文，单用户 KV 约 2GB。50 个并发用户，KV 总占用就是 100GB，加上权重，保守估计需要 4~5 张 24GB 卡才能扛住。权重反而不是大头了。

所以并发服务的卡数估算公式我习惯写成：

总显存需求 ≈ 权重显存 + 单用户 KV × 目标并发数 + 框架开销

实操时还有两个经验系数：不要把显存算到 100% 满，留 15%~20% 余量应对显存碎片和波动；不要按“所有用户同时满负载”的极端情况配卡，按 80% 峰值并发算更划算。现代推理框架普遍会做 KV Cache 的内存池化管理，把显存利用效率提上去，但总账还是这本账，只是少浪费一点。

5. 实操中的排错与提速经验

5.1 显存不够的常见信号与处理顺序

本地部署最常见的故障就是显存溢出。你启动模型时报错，提示显存不足，或者跑着跑着突然被杀掉。这时候先别急着加卡，按下面的顺序排查：

第一步，看是哪个环节爆的。启动时爆，大概率是权重加载阶段；跑一段上下文才爆，大概率是 KV Cache；并发一上来就爆，大概率是内存池管理的问题。第二步，按代价从低到高处理：先降并发数，再缩短上下文长度，然后把模型量化到 INT4，最后才考虑加卡或者上多卡并行。第三步，如果显存还有碎片问题，检查推理框架的显存分配策略，必要时限制最大批处理大小。

这里特别提醒：CPU 内存卸载（把部分参数放到内存里）是最后的手段，真正的最后手段。因为内存带宽和显存带宽差一个数量级，卸载之后速度会明显下滑，只适合“能跑就行”的验证场景，不适合正式服务。

5.2 多卡推理的通信瓶颈排查

多卡方案最诡异的问题是：加卡之后速度没提升，甚至更慢。这时候九成是通信瓶颈。

排查方法很简单：先用一个小模型在单卡上跑出基线速度，再在同配置下用两张卡跑同一个模型，对比吞吐和延迟。如果两卡比单卡还慢，直接检查卡间互连链路是不是被降级了；如果两卡有提升但远低于 1.5 倍，检查并行切分策略是否合理，以及通信库是否用了正确的传输方式。

还有一个常见坑：卡间通信默认走了慢速通道。一些消费级主板只有部分插槽能跑高速互连，卡插错位置就会导致通信带宽骤降。换卡槽之后性能恢复的情况，我见过不止一次。多卡用户的建议是：先确认卡的物理拓扑，再把同组并行卡插在同一个互连域内。

另外，多卡同时满载时的供电和散热问题也容易漏。两张卡跑满功率，电源余量不足会触发降频，表现为“加卡后速度反而下降”。排查时不要只看显存占用，要同时看功耗和温度。

5.3 容易被忽视的周边配置：供电、散热、模型加载

最后说几个实际部署中特别容易翻车、但很少有人提前提的周边问题。

供电是第一个。一张大功耗显卡满载就要几百瓦，两张就是上千瓦。普通电源只够单卡，多卡必须提前算总功耗，留至少 20% 余量，否则就会出现开机正常、一跑模型就重启的诡异故障。第二个是散热。多卡密集插在一个机箱里，热量非常集中，机箱风道不行就会降频，看起来像是性能没跑满，实际上是热墙卡住了。我的习惯是部署前先把满载功耗和温度跑一遍压力测试，确认没问题再上业务。

第三个是模型加载时间。大模型从硬盘加载到显存需要时间，70B FP16 光权重就是 140GB，机械硬盘加载可能要等好几分钟，配置好一点的 NVMe 固态能大幅缩短这个过程。正式服务一定要做模型预加载，别让每个请求都触发冷启动。第四个是底层驱动和加速库版本。多卡并行对驱动版本和通信库的版本一致性很敏感，升级之前先确认兼容性，别在生产环境里贸然升级。

还有个细节：显存占用并不等于模型大小，系统库和推理框架本身也要占显存。所以配置表里的数字，实际部署时我都会在 24GB 卡上按“可用显存大约 22GB”来规划，给自己留点余量，这个习惯帮我避开过不少 OOM 的坑。

最后再分享一点我个人的体会：本地部署大模型，很多时候不是卡不够，而是账没算清。先把模型规模、量化方式、上下文长度、并发数这四个参数定下来，显存需求就是一道乘法题。想清楚“要几个人用、跑多长上下文”，再决定是上一张 24GB 卡、两张 24GB 卡，还是直接上 80GB 的大家伙。先跑通，再优化，别一上来就奔着八卡去。