双卡2080Ti跑大模型：PCIe带宽是瓶颈吗？（重算修正版）
本文最后更新于 2026年8月9日 凌晨
本文是对《双卡2080Ti跑大模型：PCIe带宽是瓶颈吗？一次深度实测》的重算修正版。原文的显存带宽天花板计算存在量化精度错误，导致理论极限被高估了近一倍。修正后，结论方向不变（显存带宽是瓶颈，PCIe 不是），但数字全部对齐。
为什么要重算
原文的核心论证链是这样的：
- Qwen3.6-35B-A3B 每次只激活约 3B 参数
- Q4_K_M 量化 → 按 2 bytes/param 算
- 每 token 需读取 3B × 2 = 6 GB
- 2080 Ti 显存带宽 616 GB/s
- 理论天花板 = 616 ÷ 6 ≈ 103 t/s
- 实测 105 t/s → “几乎完全吻合”
问题出在第 2 步。Q4_K_M 不是 2 bytes/param。 Q4 就是 4-bit，加上 K-Quant 的分组缩放因子，实际权重体积约 0.55-0.6 bytes/param。原文把 Q4 当成了 FP16（2 bytes），导致每 token 的数据搬运量被高估了约 3.5 倍。
用错误的 6 GB 算，刚好凑出 103 t/s ≈ 实测 105 t/s，看起来完美闭合。但这是一个巧合——数字对上了，物理模型是错的。
修正后的计算
每 token 激活的数据量
先理清楚 MoE 模型推理时每个 token 到底读什么：
必须读取（每 token 都读）：
- 激活的 Expert 权重：A3B 表示每个 token 只激活 ~3B 参数的 Expert。Q4_K_M 约 0.55 bpw（bits per weight），换算成字节 ≈ 3B × 0.55 / 8 = 0.206 GB
- 共享层（Attention + Shared Expert）：这部分每个 token 必读。Qwen3.6-35B-A3B 的共享参数约 2-3B（含 attention），算 2.5B × 0.55 / 8 = 0.172 GB
小计：每 token 权重读取 ≈ 0.38 GB
额外开销（不能忽略）：
- KV Cache：每个 token 生成时需要读取已生成的 KV cache。假设上下文 4K tokens，模型 64 层，每层 KV 在 Q4_K_M 下约 32 KB/token → 4K × 64 × 32KB ≈ 8 GB 的 KV cache 读取（摊到每个 token 的边际读取很小，但总量大）
- 激活值、中间 buffer：约 0.02-0.05 GB/token
显存带宽天花板（修正）
2080 Ti 单卡显存带宽 616 GB/s。但推理不是纯线性读取，实际有效带宽通常只有标称的 50-70%（因为随机访问模式、cache miss、kernel 调度间隙等）。
取有效带宽 60%：
- 有效带宽 ≈ 616 × 0.6 = 370 GB/s
- 每 token 需读取 ≈ 0.38 GB（权重）+ KV cache 增量 ≈ 0.4 GB
- 单卡理论速度 ≈ 370 ÷ 0.4 ≈ 925 t/s？
这个数字远高于实测的 73 t/s（单卡）。说明权重读取不是唯一的瓶颈——计算本身（矩阵乘法）也要时间。
更合理的模型：算力 + 带宽双重约束
Turing 架构（2080 Ti）的 Q4 矩阵乘法吞吐：约 100 TOPS（INT4/FP16 混合）。
- 每 token 激活 ~5.5B 参数（3B Expert + 2.5B 共享）
- 每 param 约 1-2 FLOPs（矩阵乘）→ 5.5B × 2 ≈ 11 GFLOP/token
- 算力上限 ≈ 100 TOPS ÷ 11 GFLOP ≈ 9000 t/s
算力也不是瓶颈。那是什么限制了单卡只有 73 t/s？
答案是 kernel launch 开销 + 调度间隙。MoE 模型每层有 routing（专家选择）、gather/scatter 操作，这些不是密集计算，而是大量小 kernel 串行调度。每个 kernel launch 约 5-10 μs，64 层 × 多个 kernel/层 → 每个 token 的调度开销可以吃掉 30-50% 的时间。
重新解读原始数据
原文的监控数据本身是可信的，只是解释模型错了。重新解读：
PCIe 利用率（原文数据，可信）：
- GPU0 (x16)：平均 0.5%，峰值 15%
- GPU1 (x4)：平均 4.4%，峰值 33.9%
- Replay 错误：零
结论不变：PCIe x4 在推理场景下确实不是瓶颈。x4 的 3.9 GB/s 理论带宽，推理时只用不到 200 MB/s，余量超过 20 倍。
GPU SM 利用率（原文数据，可信）：
- 两卡均 39-44%
- 功耗 130W / 250W = 52%
重新解读：SM 利用率 40% 不代表”算力有富余被卡住了”。更可能是 MoE 的 routing/gather 操作让 SM 时忙时闲——计算密集时打满，调度间隙时空转，平均下来 40%。这跟”显存带宽天花板”是两个独立的约束。
修正后的核心结论
| 问题 | 原文结论 | 修正结论 |
|---|---|---|
| PCIe x4 是瓶颈吗？ | 不是（利用率<5%） | 不是（利用率<5%，结论不变） |
| 显存带宽是天花板？ | 是（616÷6≈103 t/s） | 是天花板之一，但计算方式错了——Q4_K_M 是 0.55 bpw 不是 2 bpw |
| 双卡效率为什么只有 45%？ | PHB 同步延迟 | MoE 调度开销 + PHB 同步延迟，后者是次因 |
| 真正的限制因素 | 显存带宽 | kernel 调度间隙 + 显存带宽，两者叠加 |
| MTP 为什么只提升 13%？ | 显存带宽用完了 | MoE 调度间隙——投机 token 也得过 routing，间隙吃掉了并行收益 |
最大的修正：原文说”103 t/s 理论天花板跟实测 105 t/s 完全吻合”，这个吻合是假象。修正后的理论模型显示，显存带宽上限远高于实测速度，真正的瓶颈是 MoE 架构的调度开销（routing + gather/scatter 的大量小 kernel 串行执行）。
为什么双卡效率仍然只有 45%
原文归因于 PHB 同步延迟，这个方向对，但权重分配需要修正：
- PHB 跨卡同步（次要因）：Tensor Parallel 每层 all-reduce，64 层 × 5-10 μs/层 ≈ 320-640 μs/token，约占 3-6%
- MoE routing 的跨卡 gather（主要因）：A3B 模型的 Expert 分布在两张卡上，每次激活的 Expert 可能在另一张卡上。跨卡读取 Expert 权重走 PCIe，虽然带宽够用，但 延迟累积——每 token 可能触发多次跨卡 gather，每次 10-50 μs，64 层下来可能吃掉 1-3 ms/token
- 负载不均衡：MoE 的 routing 是动态的，两张卡的 Expert 被选中频率不均，导致一张卡等待另一张卡
升级建议修正
原文的 ROI 分析方向正确，但需要补充一点：
| 方案 | 原文预期 | 修正预期 |
|---|---|---|
| 换 X570 主板 | ~0% | ~0%（不变，PCIe 确实不是瓶颈） |
| NVLink 桥接 | 5-10% | 10-15%（消除跨卡 gather 延迟，对 MoE 收益比原估更高） |
| 换 2× RTX 3090 | +50% | +40-50%（带宽提升+调度优化，但 MoE 开销仍在） |
| 换 2× RTX 4090 | +65% | +60-70%（FP8 加速对 MoE routing 有硬件级优化） |
NVLink 的价值被低估了。 原文假设 MoE 同步数据量小，NVLink 收益有限。但修正后发现，MoE 的跨卡 Expert gather 是高频小包延迟，NVLink 的低延迟特性（比 PCIe 低 5-10 倍）对 MoE 场景的收益可能比传统 Dense 模型更高。
如何自己做这个分析
1 | |
附录：原始数据 vs 修正解读
30 轮压力测试（原文数据，可信）：
1 | |
注意：facts.md 记录 Qwen3.6 实测 103 t/s，与本数据的中位数 106.8 基本一致（长输出场景均值会偏低，因为长序列的 KV cache 读取开销增大）。
Q4_K_M 量化精度对照：
| 量化方式 | bpw（bits per weight） | bytes/param | 35B 模型体积 |
|---|---|---|---|
| FP16 | 16 | 2.0 | 70 GB |
| Q8_0 | 8 | 1.0 | 35 GB |
| Q4_K_M | 4.5 | 0.56 | 19.6 GB |
| Q3_K_M | 3.5 | 0.44 | 15.4 GB |
Q4_K_M 的 0.56 bytes/param 是关键修正值。原文用的 2.0 是 FP16 的精度，套在 Q4 模型上完全错了。
修正版基于：Qwen3.6-35B-A3B Q4_K_M，llama.cpp 2026-06 build，RTX 2080 Ti 22GB 魔改 × 2（总显存 44 GB），B550M 主板（x16/x4 PCIe Gen3）。