说件真事。我去年给实验室配了一套双卡工作站，原本以为显存够了、显卡插上、驱动装完就能把大模型硬件部署跑顺，结果前前后后折腾了一个多星期，踩遍了显存、电源、PCIe、软件栈和压测五个大坑。这篇文章把每一个坑摊开讲透，附上排查思路和数据，给想做本地部署、私有化部署，或者在机房搭建企业推理服务的同学当个参考。
1. 一算显存就漏了KV Cache：模型权重只是冰山一角
1.1 70B模型权重140GB，为什么还是不够用
很多人规划显存的方式特别朴素：打开模型页，看到Llama-3-70B或者Qwen2.5-72B的BF16权重大概140GB，然后算出“需要4张A100 80G”或“2张H100 80G”。这个算法不能说错，但落地时一定会被现实教育。
因为推理时显存里装的不只是权重。自回归模型每生成一个token，都需要把历史token的Key和Value缓存下来，避免重复计算整段注意力。这就是KV Cache，它的增长速度跟上下文长度、并发请求数是直接相乘的关系。很多第一次搭服务的人以为模型装得下就万事大吉，结果请求一多、上下文一长，显存直接满掉，服务开始OOM崩或者疯狂swap到内存变慢。
我见过一个最典型的场景：团队把Llama-3-70B的BF16权重拆到4张80G卡上，单起一个测试请求都很正常，但一旦同时开几十个会话、每段对话上下文拉到8K以上，显存立刻见底。查了半天都不是权重问题，是KV Cache把剩余显存吃光了。
1.2 KV Cache消耗有多大：一个公式看清真相
KV Cache的显存占用可以这样估算：
KV Cache字节数 = 2 × 层数 × KV头数量 × 头维度 × 序列长度 × batch大小 × 每个元素字节数
以70B模型为例，假设80层、GQA的KV头数是8、头维度128、FP16存储，那么单个token的KV Cache就是：
2 × 80 × 8 × 128 × 2字节 = 320KB/token
这个数字初看不大，但乘以实际场景就吓人了。我做过一张对比表：
| 场景 | 上下文长度 | 并发batch | KV Cache预估 |
|---|---|---|---|
| 单请求短对话 | 2K | 1 | 约0.64GB |
| 单请求长文档 | 32K | 1 | 约10.24GB |
| 多会话常规并发 | 8K | 32 | 约80GB |
| 高并发长上下文 | 32K | 32 | 约320GB |
权重140GB放得了，但长上下文加高并发时，光KV Cache就能吃掉几百GB显存。这也是为什么现在推理引擎普遍支持GQA/MQA——通过减少KV头数，把缓存开销压下来。你规划显存的时候如果漏掉这一块，后面上线压力测试基本必炸。
1.3 显存预算的实操模板与避坑建议
我自己现在做配置方案，一定先问三个问题：模型权重多大、预期并发多少、上下文窗口多长。这三个参数决定显存下限，然后在这个基础上加10%到20%余量，给CUDA context、激活值、中间buffer留空间。
如果预算卡死，优先考虑的永远是量化。INT4量化后的70B模型权重降到36GB左右，单张80G卡也能跑，只是上下文长度和并发数依然受KV Cache限制。想用消费级24G卡跑7B/8B模型的同学，我建议把默认上下文长度控制在8K到16K，同时限制并发数，否则很容易出现“明明模型能加载，跑了一会就OOM”的情况。
注意：用Ollama或vLLM等框架时，模型文件大小不等于运行时显存占用。GGUF格式显示20GB，不代表20GB显存够用，KV Cache和运行开销会在此基础上叠加。
2. 电源散热不加预算：装完一跑就黑屏重启
2.1 功耗预算怎么算：别只看TDP
硬件部署里最容易被低估的其实是供电。以双4090工作站为例：单卡TDP 450W，CPU按200W算，主板、风扇、硬盘、水冷泵等零零碎碎100W，整机满载已经到1200W。这时候你买一个850W电源，看起来空闲容量够标称功耗，实际上开机加载模型的一瞬间，整机功耗会冲得很高。
4090这类卡还有个瞬时功耗问题。实测中单卡瞬时能冲到600W左右，双卡同时碰到功耗峰值的概率虽然不高，但电源一旦扛不住，表现就是跑推理跑到一半突然重启，有时候连操作系统日志都来不及写。排查这种问题特别费时间，因为硬件表面看起来一切正常。
我建议整机电源按“峰值功耗总和 + 30%冗余”来选。双4090的机器，起步就是1600W 80PLUS金牌电源，有条件直接上2000W钛金。不要为了省几百块钱把整套硬件稳定性搭进去。
2.2 降频是在悄悄偷走性能
供电只是第一关，散热才是持续运行的硬门槛。GPU满载工作后，核心温度超过86°C左右通常开始降频，热点温度（Hot Spot）超过100°C时保护机制会更激进，频率和功耗都会被压下来。
我实测过一张3090，在开放式平台上跑大模型时温度稳定在75°C左右，塞进塔式机箱、风道被CPU散热器和硬盘挡住后，满载温度能爬到91°C，生成速度比开放式环境慢了15%到20%。如果用的是多卡，卡与卡之间挨得太近，上卡会直接吃下卡的尾气，温度叠叠乐更严重。
机房部署还要考虑机柜单位功率上限。2U的GPU服务器塞4张卡，整机功耗可能超过2500W到2600W，如果机柜单路供电、单U功率分配没提前确认，上架之后不是跳闸就是线缆过热。
2.3 供电散热部署清单
- 电源功率按峰值定，不要按TDP定，留20%到30%余量。
- 显卡供电接口核对清楚，12VHPWR转接线不要贪便宜，转接不当会烧端子。
- 塔式机箱确保前出后进风道，显卡位置避开CPU散热器出风区。
- 水冷不是必须，但高负载长时间推理的场景，效果确实立竿见影。
- 上架后定期看nvidia-smi -q -d TEMPERATURE里的GPU Current Temp和GPU Hot Spot。
- 机房部署先和运维确认单机柜供电容量，再决定几台GPU服务器塞同一个柜。
注意：遇到跑模型重启、花屏、随机死机，先查温度日志再查电源。很多时候不是驱动问题，是供电和散热在背后搞事。
3. 多卡互联没看拓扑：PCIe带宽才是性能天花板
3.1 张量并行与通信开销
单卡显存放不下大模型，就得用多卡张量并行（Tensor Parallelism）。原理是把每个Transformer层的矩阵拆成几份，分别放到不同GPU上计算，计算完再跨卡做一次all-reduce同步。模型越大、TP维度的卡越多，通信量越大，这一步如果走的是PCIe，就会有非常明显的性能瓶颈。
很多人想当然地认为“两张卡跑大模型一定比一张卡快”，这是一个很容易踩的误区。对于70B级别的模型，如果用两张消费级卡通过PCIe互联，吞吐可能比一张大显存专业卡还差。因为每次token生成都要跨卡传输中间结果，PCIe带宽远不够用的。
3.2 PCIe 4.0与NVLink的差距
对比一下关键数据：PCIe 4.0 x16的单向带宽约16GB/s，双向约32GB/s；而H100上的NVLink总带宽约900GB/s，差距数十倍。消费级卡之间通常没有NVLink，多卡推理走的就是PCIe，通信开销直接决定最终吞吐。
我实测过一次双4090用PCIe 4.0 x16跑Qwen2.5-72B BF16，TP=2，单请求生成速度只有大概10到15 token/s；同一套方案换成4卡A800，有NVLink加持，生成速度能到30到40 token/s。差距不在卡的浮点算力，而在卡与卡之间的数据搬运速度。
3.3 主板通道分配陷阱与拓扑命令
另一个隐性坑是主板的PCIe通道分配。很多消费级主板看似有两个PCIe x16插槽，实际第二根插槽只能跑x8，甚至有主板为了优先给M.2固态硬盘让路，把显卡插槽降到x4。x8带宽直接砍半，x4更是灾难。
排查方法很简单，用nvidia-smi topo -m查看GPU拓扑，重点关注两个卡之间的距离类型：
- NV# 表示NVLink互联，最好；
- PIX 表示同一PCIe Switch下，通信效率次之；
- PHB 表示走不同根端口，性能更差；
- CPU 表示跨CPU通信，最糟糕。
如果发现两张卡之间是PHB或CPU级拓扑，而你又想跑张量并行，那就得认真考虑换平台了。消费级主板堆多卡做70B模型推理，是性价比很低的方案。
经验：跑70B以上模型，优先考虑支持NVLink/SXM形态的专业加速卡，或者干脆用云GPU集群。消费卡量化后跑7B到14B模型其实是更舒服的甜点区。
4. 软件栈版本地狱：驱动、CUDA、引擎、模型格式缺一不可
4.1 依赖链上每一环都可能卡住你
硬件装好了，软件才是真正开始折磨人的地方。大模型推理的依赖链条大致是：GPU驱动 → CUDA Runtime → PyTorch/Triton → 推理引擎（vLLM/Ollama/llama.cpp） → 模型文件格式。任何一层版本不匹配，都可能出现莫名其妙的报错。
我碰到过几个高频案例。第一是驱动版本太老，装了需要CUDA 12.x的PyTorch，结果驱动只支持到CUDA 11.8，程序能启动但有些算子会回退到兼容模式，性能大幅下降。第二是PyTorch与FlashAttention版本不匹配，vLLM要求FlashAttention 2.x，结果编译时找不到flash_attn，直接assert失败。第三是模型格式搞混，Ollama只吃GGUF格式，vLLM更适配safetensors，有人把GGUF格式的模型丢给vLLM，一通折腾最后发现是格式不对。
还有个容易被忽略的点：BF16支持。BF16在Ampere架构以上的GPU上才有比较好的硬件加速，在更早的显卡上虽然能跑，但性能和FP16比没有优势，甚至某些算子会回退得很难看。
4.2 快速自查命令与版本组合参考
部署前先跑下面几个命令，把环境状态摸清楚：
nvidia-smi # 查看驱动版本和CUDA版本 python -c "import torch; print(torch.__version__, torch.version.cuda)" vllm --version # 推理引擎版本 python -c "import flash_attn; print(flash_attn.__version__)"如果是在NVIDIA平台上做中小模型本地部署，我自己常用的组合是：
- 驱动版本：550.x及以上，对应CUDA 12.4+；
- PyTorch：2.5或2.6，配CUDA 12.4/12.6；
- vLLM：0.6.x及以上；
- 模型格式：优先safetensors；
- 新手调试：可以先从Ollama入手，GGUF格式对小白最友好，但深入定制时再切到vLLM。
这个组合在当前环境下经过多次验证，跑Qwen、Llama系列都不会有太大兼容性问题。
4.3 环境隔离：用容器解决版本冲突
不同项目经常需要不同版本的PyTorch和vLLM，如果全部装在宿主机上，往往会陷入“装了这个坏了那个”的泥潭。我的习惯是每个部署场景一个独立环境，要么conda/venv，要么Docker。
企业私有化部署建议直接上Docker加NVIDIA Container Toolkit，镜像版本锁死，模型文件单独挂在数据目录。这样部署、回滚、环境迁移都方便。团队里如果多人共用一台服务器，容器隔离能避免不少互相踩踏的惨案。
注意：同一张GPU上如果想跑多个推理服务，必须留意显存占用。vLLM默认会尽量把显存留给KV Cache，多个服务抢同一块卡很容易OOM，需要显式设置gpu_memory_utilization等参数做隔离。
5. 不上压测就上线：并发一起来，服务当场崩
5.1 连续批处理与静态批处理的巨大差距
部署完模型并不等于部署完服务。很多人本地试了一张图、生成了一段文字，感觉速度还行，就开放给团队使用，结果几个人同时一用，响应速度立刻惨不忍睹。
这里的关键是推理引擎的调度机制。Ollama、llama.cpp这类工具在做轻量服务时，往往倾向于简单的排队和批处理；而vLLM这类专为在线推理设计的引擎支持连续批处理（continuous batching），能够在生成过程中动态插入新请求，吞吐量通常会高出好几倍。同样的硬件，选不同引擎，支持并发的能力天差地别。
5.2 压测要看的四类指标
上线前一定要压测，而且不能只看生成速度。我自己主要关注四个指标：
- QPS：每秒能处理多少个请求，决定了系统容量的直接上限；
- TTFT（Time To First Token）：首token延迟，影响用户的第一感知；
- TPOT（Time Per Output Token）：生成一个字要多少毫秒，反映生成流畅度；
- P99延迟：最差那1%请求的延迟，比平均值更能暴露排队问题。
压测工具可以用vLLM自带的benchmark脚本，也可以用hey、wrk这类通用压测工具。我的建议是先在小并发下记录基线，再逐渐加压，观察吞吐的拐点。并行加载模型时，性能会从线性增长变为平缓，最后断崖下跌。找到那个拐点，就知道这台机器的真实承载能力。
5.3 一次OOM排查实录
分享一个真实记录。团队用一张24G显存的卡跑13B模型，我设了max-model-len为32K，并发压到20个请求时，服务在10秒左右直接OOM崩溃。当时第一反应是模型太大，但其实权重只占一半左右，真正爆掉的是KV Cache。
排查链路是这样的：
- 先看nvidia-smi，显存确实打满；
- 再看vLLM日志，明确提示OutOfMemoryError，发生在KV Cache分配阶段；
- 拿公式算了一遍：13B模型层数40、KV头数32、头维度64，单token约160字节，并发32、上下文32K时，KV Cache需求约160GB，这远超单卡显存。
最后把max-model-len降到16K，gpu_memory_utilization设为0.85，max-num-seqs限制到8，问题立刻消失。这个案例说明一个通用排查思路：遇到显存崩溃，先分清是权重太大还是KV Cache设置太激进，不要盲目加卡，很多时候调参就能解决。
金句：大模型硬件部署的核心不是堆硬件，而是给显存、带宽、功耗、散热和软件兼容性做预算。先算后买，先压后上，这两句话能替你省下大量时间和金钱。
最后再分享一个个人小习惯：无论多自信的方案，我都会先在目标硬件上用一个小模型跑通完整链路，验证驱动、引擎、格式、并发都没有问题，再把真正的模型文件换上去。这一步看起来多花半小时，但能避开绝大多数部署翻车现场。
