前两天帮朋友看一台准备跑大模型的服务器配置，他发来的单子看着挺合理：两块RTX 4090，128GB内存，2TB NVMe固态，电源1500W。我问他想跑什么模型，他说准备部署一个7B的量化模型做本地知识库问答，理由很简单——7B的FP16权重撑死14GB，24GB显存一张卡就够装了，两张卡怎么都算有余量。

这个配置单的问题就在这：显存容量确实够了，但决定大模型部署体验的从来不只是显存大小。推理速度、总线带宽、电源余量、散热策略，这些真正影响"能不能顺利用起来"的因素，几乎全被忽略了。我这些年帮人调过多台推理机器，自己也折腾过从单卡到多卡、从工作站到端侧开发板的各种部署方案，踩过的坑基本绕不开五个方向。这篇就把我实际遇到的坑一个个拆开讲，顺带把每个坑背后的计算逻辑和规避方案说清楚，给正准备本地部署、企业私有化部署或者做端侧AI硬件选型的朋友做个参考。

1. 显存幻觉：容量够大，带宽不够就白搭

1.1 同一个模型，两张卡跑出天壤之别

很多人第一次选推理显卡，第一反应是看显存大小。这本身没错，显存决定了能不能把模型装进去，但真正决定推理快慢的，往往是另一个参数——显存带宽。

这里有个底层逻辑：大模型推理和传统神经网络推理不一样，它在生成每个token时，需要把模型权重从头到尾完整读一遍。这种操作是典型的内存带宽敏感型任务，而不是算力敏感型任务。换句话说，模型推理阶段主要被"读数据的快慢"卡着，而不是被"计算能力"卡着。

我实测过同一个Qwen2.5-7B，在24GB显存的两张卡上跑，速度差了一倍还多。一张是RTX 4090，一张是RTX A5000，两款卡都是24GB显存规格，但4090的显存带宽约1008GB/s，A5000只有768GB/s。带宽差了30%多，实测推理速度也差了30%。更极端的情况是拿A2000 12GB和4070 12GB对比，单看显存容量完全一样，但带宽差了一倍，跑同一个3B模型的速度一个约40 token/s，一个可能连20 token/s都不到。

这个现象用公式说就特别直观：7B FP16模型权重约14GB，在带宽1008GB/s的4090上，理论最高生成速度是1008÷14≈72 token/s；如果把模型换成Q4量化版本，权重缩到4GB左右，同样4090上理论极限能到250 token/s左右。所以在某些宣传中看到"某显卡跑大模型速度很快"时，先别急着信，看看跑的是哪个模型、什么量化精度、什么上下文长度，同型号同显存容量的卡放一起，跑同一模型可能天差地别。

提示：看显卡规格表时，不要只看第一屏的FLOPS和TOPS，一定要翻到显存配置那一栏，看带宽数值。带宽单位通常是GB/s，数值越大，LLM解码阶段越快。

1.2 为什么"算力榜"在这里失效

还有一个常见误解是把显卡的游戏性能和AI推理性能画等号。游戏帧率主要吃算力（GPU核心数量、频率）和显存容量，而大模型生成阶段吃的是显存带宽和模型能不能塞进显存。所以一张游戏评测里表现一般的专业卡，跑大模型可能反而比游戏卡快；一张游戏评测榜排名很高的卡，跑大模型也可能被同价位的"计算卡"按在地上摩擦。

这里要区分大模型推理的两个阶段：预填阶段（prefill）和生成阶段（decode）。预填阶段要一次性处理大量输入的prompt token，计算量集中，对算力要求高；生成阶段是一个token一个token地吐，每吐一个都要全量读一遍模型权重，这时候算力绰绰有余，瓶颈全在带宽上。像ChatBot、RAG问答这种场景，用户输入一般不长，绝大部分时间都花在生成阶段，所以带宽几乎决定了体验。

顺带说一句，很多人在选型时纠结"是不是非要数据中心卡"。如果模型能在一张24GB卡上放下，把RTX 4090和A100 80G放在一起对比，4090的显存带宽只有1008GB/s，A100则约2TB/s。也就是说，A100跑7B模型理论上比4090快接近一倍。预算允许当然选大卡，但预算有限时，与其买一张大显存但带宽平庸的低端卡，不如买一张显存刚好够、但带宽更高的消费级旗舰。

1.3 算一下你的实际推理速度

先给出一个粗略的估算方法。根据我的实测经验，在llama.cpp这类对带宽利用优化得比较好的推理后端里，速度曲线非常接近"显存带宽÷当前精度模型权重大小"，实际效率大约为理论值的60%到85%，具体取决于量化格式、上下文长度和单batch还是多batch。

以Qwen2.5-7B为例，做一张表看看：

这表是"单batch、短上下文"的场景。一旦请求并发数提升，或者显存里同时驻留多个模型副本，带宽会被其他任务分走，速度也要相应打折。

我的实际建议是：选卡前先确定两件事——第一，你要跑什么规模、什么精度的模型，权重占多少显存；第二，你的主要场景是聊天气泡式交互还是多用户并发。前者决定显存下限，后者决定带宽需求。拿着这两个数去挑卡，基本不会买错。

2. KV Cache：被大多数人漏掉的显存大头

2.1 KV Cache是怎么吃掉显存的

我见过太多人部署大模型时只算模型权重的体积，认为"7B模型FP16权重14GB，我24GB显存够用了"。这个说法在短上下文、单用户场景下勉强成立，但只要把上下文拉长，或者加上几个并发用户，显存立刻告急。原因就是大家普遍忽略的KV Cache。

简单解释一下KV Cache是什么。推理时，模型每生成一个token，都要依赖前面所有token的Key和Value向量做注意力计算。如果每次都重新计算，成本过高，所以推理框架会把每一层的Key和Value缓存下来，这就是KV Cache。它的特点是：随上下文长度线性增长，随并发请求数线性增长，且需要在显存里持续驻留，不能像中间激活值那样算完就丢。

KV Cache的大小有个计算方法：2（Key和Value两组）× 层数 × 注意力头数 × 头维度 × 序列长度 × batch大小 × 每个元素字节数。看起来乱，我直接用Llama系列的结构给你算一遍。

Llama 3.2 3B模型，层数28，KV头数8，头维度128。假设上下文长度4096，单请求，FP16精度存储：

2 × 28 × 8 × 128 × 4096 × 2 ≈ 4.7亿字节，约449MB。看起来不大，模型权重按Q4算大概是2GB左右，KV Cache只占四分之一，没问题。

但如果上下文拉到32k，数值直接变这样：

注意看7B那一列，模型权重按FP16也就14GB，上下文一旦拉到32k，KV Cache反而变成33GB，是模型权重的两倍还多。之前有人跟我争论"本地部署7B用4090跑全精度词表加长上下文没压力"，我让他把上下文设成64k试一下，结果还没敲到第50个token就OOM了，原因就是KV Cache把显存撑爆了。

2.2 上下文越长，显存需求越离谱

这里要多说一句，为什么现在开源模型动辄宣传128k、1M的上下文窗口。模型训练的上下文窗口和实际部署能支撑的上下文窗口是两回事。模型可能训练到了128k，但推理框架如果没做KV Cache的优化（如page attention、量化KV Cache、稀疏注意力），实际部署时根本撑不起那么长的上下文。

我踩过一个典型坑：有一回给客户的文档问答系统做私有化部署，对方要求能处理整本技术手册的问答，希望上下文至少30k。我当时选型时只盯着"模型权重+一点余量"买了一张24GB显卡，模型是Qwen2.5-14B的INT4版本。权重约9GB，看着24GB绰绰有余，结果上下文拉到32768之后，KV Cache直逼12GB，再加上CUDA context、推理框架的中间缓冲，显存直接爆掉，只能把并发数降到1、上下文砍到8k才勉强稳住。

这也是为什么业界出现了大量的KV Cache量化方案和PagedAttention这类显存管理技术，目的就是在有限的显存里塞下更长的上下文和更多并发。如果只是自己单机用，可以采用下面这个更稳妥的估算方式。

2.3 部署前显存估算公式

我的经验是把显存需求拆成四块：模型权重、KV Cache、计算图的中间激活、CUDA上下文和运行时缓冲。中间激活在单请求推理时通常不大，但batch一旦上去会明显膨胀；CUDA上下文在Torch或vLLM这类框架下基本固定占用几百MB到2GB不等。

所以比较稳的估算公式是：显存下限 = 模型权重 × 1.2 + KV Cache × 1.3，然后再加2GB左右的运行时占用。如果部署后用vLLM这类框架，还要考虑它默认给每个序列预留的最大KV Cache空间，可能需要额外设置--max-model-len来限制。

注意：如果模型支持GQA（分组查询注意力）或MLA（多头潜在注意力），KV Cache会小很多。选型时优先看模型的这些特性，同样显存能放更长的上下文。比如DeepSeek系模型用MLA，KV Cache就比传统MHA模型小了一个数量级，这是它推理成本低的核心原因之一。

3. 多卡互联：加了第二张卡，速度反而变慢了

3.1 数据并行和张量并行的区别

显存不够怎么办？大多数人第一反应是加卡。加了之后发现，速度不升反降的情况非常多。我前几年帮人搭过一台双3090的机器，本来是单卡跑7B模型已经能到50 token/s，加上第二张卡想跑更大的模型，结果用张量并行跑13B时速度只有30多，比单卡跑7B还慢。

问题出在并行方式上。多卡部署大模型主要有两条路：数据并行和张量并行。

数据并行，就是每张卡上一份完整的模型权重，把请求分散到不同卡上。这种方式单请求速度不变，但总吞吐量翻倍，适合多用户并发场景。卡与卡之间几乎不需要通信，PCIe慢一点也没关系。缺点是显存利用率低——模型权重在每个卡上都有一份。

张量并行，是模型太大单卡装不下时，把权重矩阵切到多张卡上共同计算，每层前向传播都要做一次全局通信同步。通信量取决于模型大小和层结构，模型越大，通信越频繁。这种方式下单张卡上的权重少了很多，显存瓶颈解决了，但通信开销可能比计算开销还大。

实测数据更直接。在PCIe 4.0 x16互联的两张4090上跑7B模型，单卡能放下的前提下，张量并行几乎不会带来任何提速，很多算子反而因为通信等待变慢20%到30%。跑14B模型时，因为单卡放不下，张量并行是唯一选择，但受限于PCIe带宽，速度远达不到"四舍五入等于把显存翻倍"的预期。

3.2 PCIe与NVLink的带宽差距

这里的关键在于互联带宽。一张高端的工业级加速卡之间，NVLink的总带宽能做到600GB/s到900GB/s，而PCIe 4.0 x16的双向带宽理论值约为64GB/s，实际能用到50GB/s出头就已经不错了。这个量级的差距意味着，在张量并行场景下，数据在卡间搬运的成本截然不同。

我测过同一套模型在NVLink和PCIe环境下的表现。模型基于8卡A100，Tensor并行度切成4，NVLink组内时性能比PCIe组间快了接近3倍。具体来说，在PCIe环境下跑70B模型，张量并行度4的前提下batch=1的吞吐很惨，几乎就是每生成一个token都要等一次全卡同步，而NVLink环境就能跑得相对流畅。

所以我的经验是：如果能单卡塞下模型，绝不上张量并行；如果模型确实超过单卡显存，优先考虑更大显存的单卡，而不是多卡拼装。企业场景如果不得不走多卡张量并行，务必选择带NVLink的工业级加速卡（比如A100、H100、A800/H800等），并通过nvidia-smi topo -m检查卡间拓扑是否走NVLink，还是绕了PCIe switch甚至CPU root。

3.3 消费级主板的PCIe通道陷阱

还有一个容易忽略的坑：消费级CPU和主板的PCIe通道数有限。以常见的Z790平台为例，CPU直连的PCIe通道一共16条，显卡插满两条或四条时，通道会被拆分，从x16降到x8甚至x4。

我在一张主板上插过三张卡做测试，第三张卡走的是芯片组（PCH）通道，带宽只有PCIe 4.0 x4，实际跑张量并行时通信延迟骤增。跑小模型还好，模型稍微大一点，通信等待时间比计算时间还长，整体性能反而比双卡时退化。

所以，如果预算允许往4卡走，建议直接上服务器平台（如英特尔的至强、AMD的EPYC或霄龙系列），它们有更多PCIe通道，而且设计了针对GPU通信的直连拓扑。一定要用消费级平台的话，优先保证两卡环境：CPU直连x16+x16，或是查清楚主板说明书里第二根PCIe x16槽位实际是x8还是x4，提前做好心理准备。

提示：跑GPU推理之前，可以用nvidia-smi topo -m查看卡间连接方式。显示NV#代表NVLink连接，显示PIX/PXB代表PCIe直连或Switch连接，显示CPU/cpu代表跨CPU，通信成本依次递增。

4. 供电与散热：显卡自己会"罢工"

4.1 满载功耗和电源选型

聊完性能聊稳定性。很多自组AI服务器的人，第一次跑大模型满载时翻车，最常见的场景是：训练或推理负载跑了几分钟，机器突然黑屏重启，然后怎么排查都查不出问题，最后发现是电源功率不够。

这里必须把显卡的实际功耗算清楚。以RTX 4090为例，官方TDP标称450W，很多非公版在满载时实际功耗能冲到500W以上，瞬时功耗甚至可以到600W。四张4090同时满载，光GPU就是1800W到2000W，加上CPU、主板、内存、硬盘和风扇，整机功耗轻松超过2500W。有人拿1600W电源带四卡，结果就是上文说的一跑高负载就重启。

我给的电源选型公式是：整机额定功率 =（GPU满载总功耗 + CPU功耗 + 其他硬件约100W）× 1.3到1.5。这个余量不是浪费，而是应付GPU瞬时功耗尖峰和电源转换效率的衰减。金牌电源的转换效率一般在90%左右，标称功率不等于实际输出能力，长期满载还要预留老化余量。

如果上一台8卡机，建议直接看服务器电源方案，比如2+2冗余的2000W电源模块，或者双路1600W以上并联。家用环境想要带多卡，建议用ATX 3.0标准的1600W或2000W电源，新标准对瞬态功耗的处理明显更好。

4.2 温度墙与降频实录

供电满足之后，散热就是下一个坑。显卡不是恒定满频率运行的，它有一个温度墙，一般是83°C到90°C。一旦温度摸到墙，它就会自动降频保护自己，轻则频率小幅波动，重则性能直接砍半。

我见过一个特别典型的机箱散热案例：工作站用的塔式机箱，前面板进风，塞了三张4070。跑模型负载二十分钟后，中间那张卡温度飙到89°C，频率从2.5GHz掉到1.6GHz左右，推理速度肉眼可见地掉下去。后来把侧板拆开通风，温度降了10°C，速度回升了一大截。

操作上，装卡之前先想清楚风道：消费级显卡是三风扇开放式散热，热风会朝四周散，如果卡间距太小，中间那张卡吸进去的全是旁边卡的尾气。我的实际建议是，多张卡部署优先选择涡轮散热版本（数据中心卡或专门定制的涡轮卡），这种卡直接往机箱后方排风，对密集安装友好得多。如果手上只有普通三风扇卡，建议用开放式机架，保持卡间距至少相当一个PCIe槽位，加装一组面向卡间的高风压机箱风扇。

还要检查一件事：显卡是否撞上了功率墙或电压墙。用nvidia-smi -q -d POWER可以查看当前功耗和功耗上限，如果发现功率长期顶在100%，频率却达不到标称，说明供电或散热不足。可以通过小幅提高功耗上限，或调整风扇转速曲线来改善。在Linux下也可以用nvidia-smi -pl 350手动把功耗限制调低，换稳定性。

4.3 线缆、机箱与后续维护的细节

供电散热这块的细节坑还不止功率。4090的12VHPWR接口是出了名的娇气，插不到位会导致接触电阻异常增大，满载时端子发热烧毁接口，网上熔接口案例不少。每次插线后建议确认接口卡扣完全到位，最好用带角度转接头或弯头线，减少机箱侧板对线缆的压迫。

还有一个关于机箱承载的问题。很多消费级显卡厚达2.5到3个槽位，插满后单卡重达1.5到2公斤，时间长了PCB变形甚至PCIe插槽被拽弯的情况我也见过。装多卡时用显卡支架或者竖装方案是很有必要的。

如果部署环境在机房，还要考虑机房自身的供电容量和散热条件。发生过不止一次，机器本身配置合理，但机房单机柜供电不够，或者空调制冷不足，最终导致整体降频运行。这一点在预算和部署方案里最好提前算进去。

5. 端侧AI硬件：跑得起来不等于跑得动

5.1 端侧硬件的算力幻觉

说完服务器级部署，再聊大模型的端侧部署。这几年"端侧AI"特别火，从手机芯片到树莓派板子，都喊着能跑大模型。但实际接触下来，我最大的感受是：很多端侧硬件"能加载模型"和"能流畅用起来"之间，隔着一整条鸿沟。

端侧硬件最容易让人产生误解的参数是TOPS。比如某些NPU标称几十TOPS，听上去比一张专业卡还猛，但大模型推理的核心瓶颈如前所述——是内存带宽。手机NPU再强，LPDDR5内存的带宽也就几十GB/s，远不及独显的几百上千GB/s。NPU算力再高，模型权重要从内存里读出来才能喂给它算，内存带宽直接把上限卡死了。

我实际测过一块标称"可跑7B大模型"的国产端侧开发板，模型用Q4量化塞进去了，但推理速度只有每秒钟两三个token，一个像样的答案要等三四十秒。它不是不能跑，是根本没法用。这种现象在端侧特别普遍，厂家验证"能加载模型"就算跑成功了，但真正要对话交互，"跑得动"的标准至少是每秒10个token以上。

给端侧硬件摸个底：

5.2 生态绑定比芯片规格更关键

端侧硬件绕不开的另一个坑是软件生态。同样是"能跑大模型"，不同硬件的适配成本天差地别。

Jetson系列是我踩过最多次的。它虽然用的是NVIDIA的GPU，但驱动和CUDA版本都绑定在JetPack这个发行版上。JetPack 5对应CUDA 11.4，JetPack 6对应CUDA 12.x，想用新版本的PyTorch或vLLM，往往要自己从头编译依赖。我试过在Jetson上编译一个带FlashAttention支持的推理后端，光依赖解决就花了一个晚上，而且编译完性能和预期差别不小。

苹果的M系列芯片走的是另一条路线，llama.cpp的Metal后端和MLX框架支持得不错，7B模型的Q4量化跑起来相当流畅。但框架生态相对封闭，想跑vLLM或者SGLang这类服务化高并发框架，基本没戏。适合自己单机折腾，不适合正经做推理服务。

手机端则是另一套玩法：芯片厂商提供的SDK，高通的QNN、联发科的NeuroPilot、华为的CANN/MindSpore Lite，这些才是真正能把模型跑在NPU上的工具链。但它们对模型格式、量化精度、算子集都有严格要求，不是随便拿个ONNX或者GGUF就能跑的。这也是为什么你在手机上看到的各种"AI助手"，翻来覆去就那几个特定量化版本，因为每换一个新的NPU芯片，就得重新适配一次。

5.3 端侧部署的正确姿势

如果你确实要在端侧做部署，我的建议是：先确认目标设备的推理后端到底支持什么。有CUDA核心或者支持llama.cpp的芯片（比如Jetson、Mac、x86核显），优先用llama.cpp系或者GGUF格式的量化模型，这套组合最省心、性能也相对好。NPU确实提供了更高能效，但代价是你会被绑定在厂家的私有工具链上，换来换去极其痛苦。

另一个实用建议是：端侧部署尽量选小模型，而不是硬上大模型。在端侧场景里，3B量化模型的体验往往比7B模型好得多——不只是速度快，温度、功耗、内存占用都更可控。现在很多设备端跑的都是1B到3B规模的模型，配合服务端的更大模型做两级调度，这是当前比较成熟的落地方式。

如果预算和功耗允许，优先选择带宽高的统一内存架构设备，比如高端的Jetson系列或者苹果M系，它们在跑大模型时的效率远超同价位的其他设备。

最后分享一个我每次部署前都会做的动作：在买硬件之前，先拿目标模型和推理框架在云GPU或者别人的机器上测一轮，用llama-bench或者Ollama自带的性能测试，记录下不同上下文长度、不同并发数下的实际速度。这样能提前知道你的使用场景对带宽和显存的真实需求，避免在全套硬件买齐、上线跑起来的那一刻才意识到方向选错了。硬件部署的坑，九成靠提前计算可以避开，剩下的一成，基本都在散热和供电的实测里兜住。