企业官网建设流程全解析

1. 一张图看懂大模型显存占用规则

先说个很多人踩过的坑：很多朋友来问我“我要跑7B的模型，是不是一张4070就够”，或者“听说70B的模型很牛，我两张3090能不能跑”。这些问题其实都绕开了一个最核心的变量——你压根没算过模型到底吃多少显存。

本地部署大模型的显卡数量，不是按模型“多少B”拍脑袋定的，而是按显存倒推的。显存不够，卡再多也没用；显存够了，一张卡也能跑得飞快。所以先搞清楚显存怎么算，你才知道自己到底缺不缺卡。

1.1 模型权重是显存消耗的大头

模型部署时，第一笔显存开销是权重本身。计算公式很简单：

显存需求（GB）= 参数量（B）× 每个参数占用的字节数

这里有个关键的精度概念：如果以FP16（半精度，2字节）加载模型，那么：

• 7B模型：7 × 2 = 14GB
• 13B模型：13 × 2 = 26GB
• 33B模型：33 × 2 = 66GB
• 70B模型：70 × 2 = 140GB

这就是为什么一张24GB的显卡跑不了FP16精度的70B模型，因为光权重就要140GB，还没算别的开销，差距太远了。

1.2 KV Cache决定你的上下文能拉多长

权重只是基础，实际推理时还有一个隐藏的显存杀手——KV Cache。说白了，模型在生成每个token时，都要把之前所有输入和生成内容的注意力键值对缓存下来，避免重复计算。这个缓存的大小和输入长度、上下文长度直接相关。

一个经验公式大致是这样：

KV Cache显存 ≈ 2 × 层数 × 注意力头数 × 每头维度 × 上下文长度 × 字节数

举个例子，一个7B模型如果只撑4K上下文，KV Cache可能只要1~2GB，但如果你硬拉到32K上下文，立刻飙升到8~10GB。这也是为什么很多人跑长文档时，明明显存看着够，一跑长文就Out of Memory。

1.3 实际部署还得留出运行余量

除了权重和KV Cache，显存还要分给CUDA上下文、中间激活值、推理框架自身的buffer，这些杂七杂八的开销通常要额外预留2~4GB。所以算总账的时候，我习惯用这个更保守的公式：

总显存需求 ≈ 权重显存 × 1.2 + KV Cache显存 + 2GB

用这个公式，你反过来推显卡数量就清晰了：先定模型规模和量化方式，再定上下文长度，算出总显存需求，然后看单张卡能装多少，装不下就上多卡。

2. 不同规模模型到底要几张卡

把公式落到实际场景里，我按模型规模给你拆一遍，顺便把量化这个变量也考虑进来。因为量化直接改变每个参数占用的字节数，是影响“几张卡”最大的一张牌。

2.1 量化能让模型“瘦身”一大截

FP16占2字节，INT8占1字节，INT4理论上占0.5字节。实际部署时最主流的量化方案是GGUF格式的Q4_K_M级别，或者GPTQ/AWQ的4bit量化，效果都还不错。

用Q4量化后，权重显存大概变成：

• 7B模型：7 × 0.5 ≈ 3.5GB（再加一些中间开销，5~6GB就够）
• 13B模型：13 × 0.5 ≈ 6.5GB（实际8~10GB）
• 33B模型：33 × 0.5 ≈ 16.5GB（实际20GB上下）
• 70B模型：70 × 0.5 ≈ 35GB（实际40~45GB）

这个数字一出来，选卡的思路就清晰多了。

2.2 7B~14B：一张24GB显卡基本通吃

先说最常见的小规模模型，7B和13B/14B。这个级别目前是本地部署的主力区间，因为用途广、硬件门槛不高，几乎覆盖了日常聊助、代码补全、文档总结这些场景。

如果你用Q4量化：

• 7B模型只要6~8GB显存，一张RTX 4060 Ti 16G就能跑，甚至8G的卡也能尝试
• 13B/14B模型要10~12GB显存，一张16G显存卡就能稳跑，24G更是舒服

如果坚持要FP16精度，7B需要约16GB实际占用，一张3090/4090就吃得下；13B的FP16需要接近28GB，那就得上3090/4090 24G并开启部分CPU offload，或者直接上双卡。

我的建议是：家用场景，一张4090 24G是真正的甜点卡，通吃7B~14B的任意精度和任意量化档位，还留够KV Cache的余量，能拉长上下文。

2.3 33B~34B：24G卡能跑但吃力，双卡才是正道

33B/34B的Q4量化权重约17GB，加上KV Cache和运行开销，一张24G卡其实勉强能塞下。但实际体验不太理想，因为上下文稍长就可能爆显存，而且随着显存占用逼近上限，推理速度也会明显下降。

我自己实测下来，这个规模最舒服的配置是双卡：

• 两张24G卡（比如两张4090或者3090），总显存48GB
• 用Q4量化，权重占20GB，剩下28GB全给KV Cache，32K上下文随便拉
• 甚至可以尝试FP16精度，34B × 2字节 ≈ 68GB，双卡48GB还是不够，得靠CPU offload

所以如果你有34B级别的需求，别犹豫，两张24G卡起步比较合适。

2.4 70B级别：双卡起步，四卡才舒服

70B是目前本地部署的“分水岭”，因为它的Q4量化后权重约35~40GB，一张卡绝对放不下；FP16要140GB，普通玩家基本上可以放弃。

在这个级别上，主流方案是这样的：

• 双卡方案：两张4090/3090 24G，总显存48GB，跑Q4量化的70B权重约40GB，剩余的8GB勉强维持短上下文，速度一般，但能跑
• 四卡方案：四张24G卡，总显存96GB，跑Q4量化后余量非常充足，长上下文、并发请求都扛得住；甚至可以用INT8量化，跑起来更稳

再往上还有100B+或MoE架构的大模型，Q4量化也需要60~100GB显存，那就得考虑两张48G或者四张24G以上的配置了。这类模型家用基本不现实，一般是企业或实验室场景。

2.5 一张表看清各规模选卡方案

3. 多卡到底怎么分工：并行策略完全拆解

很多人以为多卡就是把模型“分一半”放进两张卡里，这个理解太粗糙了。多卡部署涉及不同的并行策略，选错了方案，显卡数量再够也跑不出应有的速度。

3.1 张量并行：一张卡装不下就拆到多张

张量并行的核心思路是：把每一层的大矩阵拆成块，同时放在多张GPU上，计算时每张卡只算自己那部分，再通过通信把结果拼起来。

它最典型的应用场景就是：模型太大，单卡放不下。比如70B的Q4模型，权重40GB，单张24G放不下，但拆成两块，每张卡只放20GB左右，就都放得下了。

但有一个关键点：张量并行对GPU间通信带宽的要求非常苛刻，因为每一层都要做多次中间结果的合并传输。如果用了PCIe Gen4 x16通道连接，带宽大概32GB/s，速度还能接受；但如果是PCIe Gen4 x8甚至x4，通信时间会直接吃掉计算时间，导致多卡比单卡还慢的尴尬局面。

所以玩张量并行，第一件事是确认你的主板支持PCIe拆分，并插到正确的插槽上。

3.2 流水线并行：每张卡负责不同层，通信压力小

流水线并行和张量并行正好反过来：模型是多层的堆叠，那干脆把不同层分给不同GPU，第1张卡负责前面的层，第2张卡负责后面的层，数据按顺序流过每张卡。

它的优点是对通信带宽要求不高，因为卡与卡之间只在层边界传递一次结果；缺点是存在流水线气泡，GPU利用率不如张量并行，而且如果模型层数分配不均匀，快的卡要等慢的卡，整体性能会打折扣。

在实际框架里，像vLLM的部分并行策略、DeepSpeed的Pipeline并行，都是这类思路的实现。个人玩家多卡部署大模型时，更推荐优先用张量并行，除非你说的是跨卡跑批量不同小模型。

3.3 数据并行：多卡跑不同请求，扩展吞吐量

如果你的模型单卡就能放下，那多卡的意义其实不在“放下”，而在“跑得快”。数据并行就是把同一份模型复制到多张卡上，每张卡独立处理不同的请求，互不干扰。

这种场景典型出现在API服务、个人搭建的聊天机器人上，因为多个用户同时来请求，一张卡排队太慢。比如一张卡每秒能处理20个并发请求，两张卡就翻倍到40个，四张卡再翻倍。

数据并行的技术实现简单，几乎不要求通信带宽，因为它不需要卡间共享参数，只要在最后汇总结果就行。前提是你要用一个支持并发调度的推理框架，比如vLLM、TensorRT-LLM，而不是简单地把模型加载两次。

3.4 真实部署中选择并行的经验

多卡方案在实际部署时，框架层面大概率会被动处理好这些细节。比如你指定两张卡跑一个大模型，主流的推理框架会自动做张量并行，分层的策略则可以手动配置。

但作为过来人，我建议的顺序是这样的：

1. 先尽量量化压缩模型，尝试单卡搞定。多卡通信再快，也不如单卡零通信。能省则省。
2. 实在超出一张卡的容量，再考虑双卡张量并行。选PCIe x16直连的插槽，或者干脆用NVLink桥接。
3. 如果是做API服务，数据并行优先。多卡跑同一个模型，配负载均衡，吞吐量直接线性扩展。

4. 显存之外：显卡型号、带宽与CPU的隐性影响

决定“要几张卡”的，除了显存容量，还有几个容易忽略的因素。很多朋友照着显存配了卡，结果速度和预期差很远，问题大多出在这些隐性参数上。

4.1 显存带宽决定生成速度

大模型推理本质上是显存带宽密集型任务，因为每生成一个token，都要把完整权重从显存读一遍。你算算看：7B的Q4模型权重3.5GB，每秒生成30个token，那每秒要从显存里读取超过100GB的数据。

所以显存带宽直接决定了你推理速度的天花板：

• RTX 4060 Ti：显存带宽约288GB/s，跑7B Q4大约每秒30~40token
• RTX 4070 Ti SUPER：带宽约672GB/s，速度能到50~60token
• RTX 4090：带宽约1008GB/s，速度能到80~120token
• A6000：带宽约768GB/s，速度约和4080差不多

这里的核心结论是：显存越大不等于速度越快，显存带宽才是推理速度的关键指标。同样是24G显存，4090比3090快接近50%，就是因为带宽从936GB/s涨到了1008GB/s。

4.2 显存型号差异：GDDR6与HBM差距很大

消费级显卡用的基本都是GDDR6或GDDR6X，带宽在288~1008GB/s之间；而专业卡（比如A系列、H系列）用HBM2e或HBM3显存，带宽高达2TB/s以上。同样是跑70B模型，专业卡在速度上确实碾压消费级。

但专业卡的价格动辄是消费卡的几倍。对个人玩家来说，如果只是自己玩，追求综合性价比，4090是很不错的选择；如果是为了跑服务、并发量大，预算充足再考虑专业卡。

4.3 CPU和内存的双重影响

还有一个常见的坑：很多人只配了好显卡，CPU和内存却拉了后腿。

大模型推理不是纯GPU活。在预处理阶段，比如处理文本、编码Prompt、加载模型分片时，CPU性能都会直接影响整体时延。如果使用CPU offload（把部分层放到内存跑），CPU和内存带宽的瓶颈就更显著了。

我的建议是：

• CPU至少8核以上，12核以上更好
• 内存建议32GB起步，64GB合适，70B模型配合CPU offload时，64GB内存是起步
• 内存通道数和速度也很重要，四通道DDR5比双通道DDR4在offload场景下能快一截

5. 部署实操：双卡跑70B量化模型流程实录

讲了这么多理论，我拿一个最常见的配置——双卡24G跑70B Q4量化模型——给你完整走一遍流程。这个方案是目前个人玩家在“成本”和“效果”之间相对均衡的选择。

5.1 环境准备与依赖安装

我以Linux系统为例，Windows下逻辑类似，但驱动和CUDA的坑会多一些。

首先是驱动和CUDA，必须保证两张卡都能被系统识别。安装完驱动后用nvidia-smi查看，确认两张卡都显示正常。然后安装CUDA工具链（12.x版本）和cuDNN。

接着创建Python虚拟环境并安装必要的库：

python -m venv llm_env source llm_env/bin/activate pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate sentencepiece protobuf

还有一个重要组件是flash-attention，对推理加速和显存优化很有用。安装可能比较耗时，但值得等：

pip install flash-attn

5.2 下载并转换模型权重

从模型仓库拉取70B基座模型，建议直接用GGUF格式，这种格式对显存占用和加载效率都更友好。

如果拿到的模型是FP16的完整格式，需要用llama.cpp或相关工具链转成GGUF Q4_K_M格式。这个过程包含校准、量化、拆分几个环节，转换本身需要时间，但一次性做完以后，后续每次启动都省心。

5.3 张量并行加载与推理参数配置

加载模型时关键在device_map的设置。用transformers库的话，可以通过device_map="auto"自动把不同层分配到不同GPU上；用llama.cpp或vLLM，则可以直接指定GPU层数和张量并行数。

以llama.cpp服务端为例，启动指令大致是：

./llama-server -m model-q4_k_m.gguf -ngl 99 -t 8 --parallel 2

这里的-ngl 99表示把模型所有层都放到GPU上（99是极值，实际层数没这么多也能全部放GPU），-t 8是CPU线程数，--parallel 2允许同时处理两个请求。

用双卡跑70B Q4，我会在确保张量并行正确拆分的前提下，把全部层推到GPU，因为此时48GB显存刚好装得下40GB权重和部分缓存，虽然余量不多，但运行是没问题的。

5.4 启动与实测评估

启动完成后，直接发几个Prompt测试速度和显存占用：

nvidia-smi

重点看两张显卡的显存使用和功耗。如果发现只有一张卡在跑，回头检查并行配置；如果两张卡都在跑但速度很慢，多半是卡间通信瓶颈。

实测下来，双卡跑70B Q4，输出速度大约在20~40 token/s之间波动，这个速度能接受，日常对话感知不到明显的卡顿，但如果追求丝滑体验，还是得缩到34B级别或者上四卡。

另外一个实测经验：显存余量低于10%时，推理速度会突然掉一半甚至更多，因为框架可能开始做一些保守的显存清理，反而拖慢速度。所以配置时千万别把显存塞得刚刚好，一定要留出冗余。

6. 常见问题与排查技巧实录

6.1 显卡利用率低，只有一格在跳

这是新手最容易遇到的问题。显卡利用率只有30%不到，输出速度还慢，首先怀疑并行拆分没生效。

排查思路：

1. nvidia-smi看一下两张卡是不是都有进程和显存占用
2. 如果只有一张卡有进程，检查框架的GPU数量配置是否正确
3. 用CUDA_VISIBLE_DEVICES=0,1显式指定两块卡

还有个隐蔽问题：有些主板插了两张卡，但第二张卡跑在PCIe x4通道上，带宽只有x16的1/4。这时候就要检查PCIe链路速度了：

nvidia-smi -q | grep -A 2 "Link"

如果看到Current Link Width是x8或x4，而板子支持x16，那就要换插槽位置，否则通信带宽会拖后腿。

6.2 明明按公式算够用，一跑就崩

这种情况大概率是KV Cache设置得太大了。很多人光算了权重，没算长上下文带来的KV Cache开销。

拿风速解决：

1. 先把上下文长度降到4K或8K，跑通再慢慢往上拉
2. 确认是否开启KV Cache量化，很多框架可以把KV Cache从FP16压缩到INT8，显存占用直接减半
3. 适当降低并行请求数，--parallel设为1，跑通后再加

另外也别忘了CUDA context的固定开销，每张卡上约200~500MB，多卡就是翻倍累积，这个容易忽略。

6.3 输出速度比预期慢很多

速度慢涉及多个环节，按优先级排查：

1. 显存带宽是否耗尽：看nvidia-smi的显存占用率，如果接近100%，那就没救了，只能砍上下文或换精度的卡
2. 是否触发了CPU offload：如果显存不足，某些层会被分配到内存，速度直接掉一个数量级。解绑方法就是减小上下文、换更小的量化档位
3. 是否单卡flag：有些加载方式只让一张卡干活，另一张卡闲置，看起来有显存但没算力，并行没生效

6.4 供电发热与稳定性问题

多卡部署还有一个不能忽视的现实问题——电源。一张4090满载功耗450W，双卡就是900W+，还不算CPU和主板。供电不足轻则原地重启，重则烧电源。

经验法则：

• 单卡24G级：电源750W起步
• 双卡24G级：电源1200W起步，最好是ATX 3.0规格
• 四卡：需要双电源或服务器电源方案

发热也一样，两张卡满载的时候，机箱散热跟不上的话，GPU温度飙到90度以上就会强制降频，降频后速度下滑明显。多卡部署时一定要工业级散热机架或开放式支架，别留恋普通家用机箱。

7. 给不同场景的最终选卡建议

结合这些实战经验，我给不同用途的朋友一套可以直接照着买的配置清单。

轻量办公与学习（跑7B~14B Q4）：一张16G显存卡就够，比如RTX 4060 Ti 16G，价格便宜，功耗低，日常跑跑文档总结、代码助手完全够用。如果预算宽裕，直接上24G卡，就不用为显存发愁了。

深度本地推理爱好者（跑14B~34B FP16或Q4）：一张4090是理想选择，24G显存+千G带宽，7B~14B的任意精度都能跑，34B Q4也能勉强用。预算低就收一张二手3090，显存同样是24G，带宽略低但日常够用。

小型团队或项目组（跑34B~70B）：双卡4090或双卡3090，总显存48GB。70B Q4能跑，34B FP16也能跑，覆盖大部分企业内部应用场景。记得配大电源和好散热。

服务千人以上的API服务（跑70B或更大模型）：建议四张24G或直接上两张48G专业卡。配合vLLM这类高性能推理框架，做张量并行+数据并行，才能顶住高并发。这个配置个人钱包就有点吃力了，通常是公司报销的范畴。

我个人在实际操作中的体会是：不要被“必须跑多大模型”绑架。本地部署的核心价值不是跑满血版，而是让模型在你能接受的硬件条件下稳定高效地跑起来。很多场景，一个7B量化模型配上32K上下文，比硬塞一个70B模型只给2K上下文靠谱得多。先跑起来，再往上迭代，这才是本地部署最务实的路径。