本地部署大模型跑得慢？别怪显卡不够强——显存带宽和PCIe才是真瓶颈（实测拆解）

为什么同样"显存够"，有人 3 token/s，有人 25 token/s

先说个我踩过的坑。

去年我配了台机器跑 7B 模型，显存 24GB，理论上单卡就能塞下 FP16 的 7B（约 14GB）。结果跑起来给我整不会了——生成一句话要卡好几秒，同事在旁边问：你这显卡是不是假的？

我第一反应是显存不够，加钱换 48GB。换完呢？速度几乎没变化。

问题来了，真正卡死吞吐的从来不是"显存够不够"，而是显存带宽和PCIe 带宽。这两个东西，全网讲清楚的人真不多。今天把这层窗户纸捅破。

你品，你细品——显存容量决定"能不能跑"，显存带宽决定"跑多快"，PCIe 带宽决定"内存兜底的时候有多惨"。

大模型的"吞吐公式"：先看懂瓶颈在哪

本地推理慢，90% 的人归因于"显卡不够强"。但大模型和传统渲染不一样，它有个硬规律。

1. 显存容量：决定"装不装得下"

公式走一遍：

显存需求(GB) ≈ 参数量(B) × 单参数精度字节数

权重部分：

注意这只是权重。实际部署还要给中间激活值（KV cache）留 20%~30% 余量。70B INT8 权重 70GB，batch=1 跑起来激活值又吃掉约 15GB，实际按 85GB 算。

所以很多人装机时容量算得明明白白，却栽在下一环。

2. 显存带宽：决定"吐 token 有多快"——这才是命门

关键认知：大模型生成阶段是 memory-bound（带宽受限），不是 compute-bound（算力受限）。

为什么？生成每个 token 都要把整个模型的权重从显存里读一遍参与运算。权重越重、显存带宽越窄，读得就越慢。这时显卡 TFLOPS 再高也白搭，瓶颈根本不在算力。

看一张真实带宽对照表：

看出来没？同样是"显存够"，24GB 的 4090 和 48GB 的 6000 Ada，前者带宽反而更高。如果你跑 7B 这种一张卡塞得下的模型，带宽高的卡通常更快，而不是显存大的卡。

这是无数"显存至上论"翻车的地方。

一句话——显存大是"装得多"，带宽大才是"跑得快"。很多人拿 48GB 大显存卡跑 7B，其实这张卡的带宽在打酱油。

3. PCIe 带宽：模型的"救命通道"，也是速度杀手

真正让 90% 的人欲哭无泪的是这个。

很多人买了 70B 这种大头模型，权重 140GB 放不进单卡，就把权重 offload（卸载）到 CPU 内存，靠 PCIe 总线来回搬运。结果呢？

• 显存带宽：约 900GB/s ~ 1TB/s
• CPU 内存带宽：通常约 50GB/s
• 差多少？接近 20 倍。

哪怕你的显卡是顶级货，一旦权重溢出到内存，瓶颈就完全转移到 PCIe 和内存带宽上，吞吐直接崩到个位数。这就是为什么网上有人用 8GB 内存也能"跑"万亿参数模型——能跑，但每秒 0.03 个 token，纯属行为艺术。

PCIe 版本也关键：

如果你打算靠"显存+内存混合"跑大模型（vLLM unified memory、llama.cpp GPU+CPU offload），PCIe 5.0 的机器能把内存兜底速度比 4.0 翻一倍。这一点，装机的很少有人主动提。

你品，你细品——本地部署选硬件，显存容量是"及格线"，显存带宽是"速度分"，PCIe 是"兜底分"。及格线过了就够，速度分和兜底分才决定你用起来是"爽"还是"想砸电脑"。

实测方法：怎么量化"推理慢"而不是凭感觉

正式调优前，先把测试方法固定下来，否则你根本分不清是卡的问题还是设置的问题。

稳定测试脚本（压测 + 记录关键指标）

用 vLLM 自带的 benchmark 是最稳的：

# 1. 压测吞吐（tokens/s）
cd vllm/benchmarks
python benchmark_throughput.py \
  --model /models/Qwen2.5-7B \
  --backend vllm \
  --input-len 512 \
  --output-len 256 \
  --num-prompts 20 \
  --max-num-seqs 4

# 2. 记录延迟（首 token 时间 / 单 token 时间）
python benchmark_latency.py \
  --model /models/Qwen2.5-7B \
  --input-len 128 \
  --output-len 128

同时用 NVIDIA 工具看硬件占用，判断瓶颈到底在哪：

nvidia-smi dmon -s pucvmet -d 1   # 实时看 GPU/显存/带宽/温度

关键看两列：
- GPU 利用率（% ） 和 显存带宽利用率
- 如果 GPU 利用率没满但已经很慢 → 大概率是 offload 到内存/PCIe 在拖后腿

先用 nvidia-smi 确认权重有没有全部进显存：

nvidia-smi                          # 看每张卡的显存使用（Used/Total）

如果 Used 明显小于模型权重 + KV cache 的理论值，说明权重在往内存跑——恭喜，你找到了慢的根源之一。

实测：7B 模型从 3 token/s 优化到 25 token/s 的完整过程

下面是测试环境里真实记录的一轮调优（batch=1，单卡 24GB，跑 FP16 的 7B；具体数值会因环境、版本、量化方式浮动，重点看优化逻辑）。

第一版（默认跑，慢到怀疑人生）：

吞吐：约 3 token/s
原因：权重溢出了一部分到内存，PCIe 成了瓶颈

第一步：关掉 CPU offload，让权重全进显存

python -m vllm.entrypoints.openai.api_server \
  --model /models/Qwen2.5-7B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192

结果：3 → 12 token/s。就这一个动作，翻 4 倍。

第二步：量化到 INT8/INT4，进一步压权重体积

# llama.cpp 里量化跑，权重砍半
llama-cli -m qwen2.5-7b-q8_0.gguf \
  -ngl 99 \
  --no-mmap

结果：12 → 22 token/s。INT8 精度损失 <1%，体验几乎无感。

量化精度对照（面子里子怎么选）：

建议：对精度敏感（医疗、金融诊断）用 INT8；对延迟敏感（实时对话）可接受 INT4。

第三步：调并发 + 走 PCIe 5.0 通道

# vLLM 里调 batch，吃满带宽
--max-num-seqs 8 \
--max-num-batched-tokens 4096

结果：稳定 25 token/s 左右。

这一路核心就三个字：别让权重出显存，别让精度白白占带宽，别让总线拖后腿。

说白了——本地部署优化，一半是"让硬件各司其职"，一半是"别自己做傻事"。

附带送一个：CPU/内存调度口诀

如果你的场景必须走内存兜底，至少把这几件事做了：

1. 权重尽量量化（INT8/INT4），减搬运量
2. 内存条组满通道，CPU 内存带宽从 8 通道吃到满
3. 优先 PCIe 5.0 主板 + 支持该版本的卡
4. 跑 vLLM unified memory 前先测一轮 offload 质比

冷启动也是隐性速度坑：模型加载那 2 分钟去哪了

很多人只盯着"生成快不快"，忽略了一个更扎心的事实——模型加载（冷启动）本身可能就要占掉你几分钟。

70B INT8 的权重就有 70GB。从硬盘/SSD 读进显存，走的是存储 → 内存 → 显存这条链路，速度由存储和总线一起决定：

实测差异就是这么夸张：一个走 SSD，一个走内存。如果你经常重启服务 / 切换模型，冷启动时间会直接影响"能不能用"，比推理还烦人。

优化三板斧：

1. 用 NVMe SSD（读速 >7GB/s），别用 SATA 机械盘
2. 内存够就 mmap 常驻，提升每次加载
3. 7×24 在线服务，尽量不频繁冷启动

你品，你细品——推理速度是"使用体验"，冷启动速度是"维护体验"。两个都得管，缺一个都难受。

服务器 vs 工作站：本地部署该买谁？（含决策树）

这是最容易被忽略的一步。同样是跑大模型，塔式工作站和机架式服务器完全是两套选法。下面两张是我实际接触过的样机形态（型号来自公开配置方案，仅作场景对比）：

决策树（抄作业版）：

Q：你是跑"推理/微调"还是"要长期并发服务"？
├─ 单机桌面跑 7B~30B、研究/小团队 → 选塔式工作站
│   ├─ 预算紧 → 单 GPU + PCIe 5.0 主板
│   └─ 要快 → 高显存带宽的卡 + 更多内存
└─ 70B+、并发高、要 7×24 稳定 → 选机架服务器
    ├─ 要国产化 → 留意信创型号
    └─ 要 8 卡 + 液冷 → 服务器密度

预算分层（本地部署 7B~13B 场景）：
- 入门 3~8 万：单张 24GB 消费卡，跑 INT8 的 7B 没问题
- 进阶 10~20 万：48GB 专业卡 / 工作站，13B FP16、7B 全量微调都够
- 旗舰 20 万+：多卡服务器 + 液冷，70B 推理 / 高性能微调

一句话——你先想清楚"放办公室还是进机房"、"单机还是并发"，再谈买卡，顺序反了必踩坑。

避坑清单（装机前对着打勾）

• [ ] 别只看显存容量，显存带宽决定单卡跑得爽不爽
• [ ] 模型放不下时确认走 PCIe 5.0，别再让 4.0 拖后腿
• [ ] 优先级：权重全进显存 > INT8 量化 > 调并发 > 加内存
• [ ] 塔式工作站还是机架服务器，先定场景再定卡
• [ ] 预算别光算买卡钱，电费 + 散热 + 机房机柜都是隐性成本
• [ ] 买前让供应商把型号 + PCIe 版本 + 显存带宽写进配置单

KV Cache：并发一大就爆内存的隐藏凶手

还有一个常被忽略的显存黑洞——KV Cache。

大模型生成时，整段 prompt 的注意力 Key/Value 都要缓存在显存里，随上下文长度和并发数线性增长。所以"显存需求公式"其实要写成：

总显存 ≈ 权重 + KV Cache + 计算缓冲

其中 KV Cache 大致是：

KV ≈ 层数 × 注意力头数 × 隐层维度 × 2 × 上下文长度 × batch

这也是为什么官方内存管理里有个 --max-model-len：它直接限制 KV Cache 能占多大。如果你并发一开大、上下文一拉长，明明权重才 14GB，KV Cache 却能吃掉另外几十 GB，然后就开始往内存吐，速度一泻千里。

实测中的真实表现（7B，32K 上下文 vs 8K）：

一句话——别只算权重。权重是"底盘"，KV Cache 是"加速时往你车上塞的货"，货一多，底盘再好也跑不快。

FAQ

Q：显存 48GB 是不是一定比 24GB 跑得快？
A：不一定。如果是 7B 这种 24GB 就塞得下的模型，决定速度的是显存带宽，不是容量；除非你要跑 30B+。

Q：模型太大完全放不下怎么办？
A：量化（INT8/INT4）优先，其次才考虑 offload 到内存。offload 是最后的兜底，PCIe 5.0 + 高内存带宽能救回来一点。

Q：个人开发者预算有限，怎么起步？
A：先用消费级 24GB 卡 + INT8 跑 7B，够绝大多数场景；要上 13B 全量微调或并发服务再升级。

后记：样机从哪来，数据怎么验证

本文测试样机的配置信息（联想 ThinkStation PX、浪潮 NF5468M6）由浪潮/联想授权渠道商提供。我只负责跑数据和踩坑，不构成对任何一家经销商的推荐。实际选购时，认准正规授权渠道，让供应商把具体型号 + PCIe 版本 + 显存带宽白纸黑字写进配置单，比听一句"高配"靠谱得多。

性能数值受环境、版本、量化方式影响会有浮动。建议你直接跑文中的 benchmark 脚本，在自己机器上复现一遍，再决定怎么买——这正是这篇的价值：别信广告，信数据。

本文基于公开的显存/带宽规格与实测记录整理，性能数值为特定测试环境的观察，请以实际测试为准，不构成任何购买推荐。