八张 GPU 为什么不是八倍算力？多卡扩展效率、通信与拓扑怎么理解
GPU 数量增加并不意味着训练或推理性能按卡数线性增长。本文从并行方式、通信开销、NVLink/PCIe 拓扑、NCCL、CPU 与 I/O、Batch 和模型规模出发，解释多 GPU 扩展效率为什么会下降，以及怎样判断 2 卡、4 卡、8 卡是否真正有价值。
- Slug
why-eight-gpus-not-eight-times-performance- 更新
- 2026-09-02
- 来源
- 4
- 关系
- 4
“一张卡跑 100，八张卡是不是就能跑 800？”这是多 GPU 服务器选型中非常常见的误区。GPU 数量增加后，系统多出来的不只是计算资源，也同时增加了数据切分、同步、通信、调度和内存管理成本。
先给结论：多 GPU 的价值不是“把单卡性能直接乘以卡数”，而是让一个更大的模型或更多任务能够并行运行。实际加速比取决于工作负载能否并行、GPU 间通信量、拓扑、并行策略、Batch、CPU/存储供给以及框架实现。某些任务可以接近线性扩展，另一些任务即使增加 GPU，收益也可能很有限。
先区分两个概念：容量扩展和性能扩展
增加 GPU 通常带来两种不同收益：
- 容量扩展：更多显存可以承载更大模型、更长 Context 或更多并发。
- 性能扩展：多个 GPU 同时计算，使单位时间处理更多 Token、样本或任务。
容量通常比较容易理解，而性能不一定线性增长。比如一个模型从单卡无法加载变成 4 卡可以加载，这是明确的容量收益；但从 4 卡增加到 8 卡，吞吐是否翻倍，需要看通信和并行效率。
什么叫多卡扩展效率？
可以用一个简单思路理解：
扩展效率 ≈ 多卡实际吞吐 ÷（单卡吞吐 × GPU 数量）
如果单卡吞吐为 X，8 卡实际吞吐接近 8X，说明扩展效率很高；如果只有 4X，则说明增加的计算资源有相当一部分被通信、等待或其他瓶颈消耗。
这个指标必须在相同模型、相同精度、相同输入输出长度和可比的并发/Batch下计算，否则没有直接可比性。
为什么多卡一定会引入额外开销？
大模型训练和推理常见的数据并行、张量并行、流水线并行和专家并行，都需要在 GPU 之间交换信息。
| 并行方式 | 基本思路 | 典型额外成本 |
|---|---|---|
| Data Parallel | 每张 GPU 处理不同数据 | 梯度同步、参数同步 |
| Tensor Parallel | 一个算子/模型层拆到多张 GPU | 高频 All-Reduce / All-Gather 等通信 |
| Pipeline Parallel | 不同层放在不同 GPU 或节点 | 流水线气泡、阶段间传输 |
| Expert Parallel | MoE 专家分布在不同设备 | Token 路由与 All-to-All 通信 |
NCCL 提供 All-Reduce、All-Gather、Reduce-Scatter、Broadcast 和点对点通信等多 GPU 通信原语，并会根据 PCIe、NVLink、NVSwitch、InfiniBand、RoCE 等可用拓扑选择通信路径。也正因为通信真实存在，多卡计算不可能只看 GPU 数量。
NVLink、PCIe 为什么会影响多卡效率？
当模型通过 Tensor Parallel 等方式频繁交换中间结果时，GPU 间通信带宽和延迟会直接影响计算单元能否持续工作。
常见路径包括：
- GPU 通过 PCIe 直接或经过 PCIe Switch 通信；
- 支持 NVLink 的 GPU 通过 NVLink 形成更高带宽的点对点路径；
- 部分平台通过 NVSwitch 构建更完整的多 GPU NVLink 互联。
因此，两台同样“8×GPU”的服务器，如果一个具有更好的 GPU 互联和拓扑，另一个存在大量跨 CPU Socket 或受限 PCIe 路径，实际多卡表现可能不同。
为什么一定要看拓扑，而不是只看接口规格？
拓扑决定“GPU A 到 GPU B 的数据究竟走哪条路”。有些 GPU 之间可能是直接 NVLink，有些需要经过 PCIe Switch，有些还可能跨 CPU Root Complex。
可以使用 nvidia-smi topo -m 查看 GPU、NIC 和 CPU 之间的拓扑关系。NVIDIA DCGM 也可以查询 NVLink 状态和拓扑信息。
需要注意：拓扑图只能说明连接关系，并不能代替带宽测试和真实应用测试。
模型越大，多卡效率一定越差吗？
不一定。真正关键的是计算量和通信量的比例。
如果每次通信前 GPU 能执行大量计算，通信成本可以被摊薄；如果模型或请求很小，但为了使用更多 GPU 被强行拆分，就可能出现 GPU 大量时间用于等待同步。
因此：
- 大模型可能必须依靠多卡才能运行；
- 小模型不一定适合做很高的 Tensor Parallel；
- 高并发推理有时更适合多副本，而不是把单个请求拆到所有 GPU。
Batch 和并发为什么也会改变 8 卡表现？
GPU 需要足够的并行工作量才能提高利用率。如果请求很少、Batch 很小或输出很短，增加 GPU 后可能没有足够任务填满每张卡。
推理系统还需要在 TTFT、单请求延迟和总吞吐之间取舍。为了追求高吞吐增加 Batch 或并发，可能会改变单请求延迟，因此不能只用一个数字评价多卡性能。
GPU 之外，CPU、内存、存储也可能拖住 8 张卡
即使 GPU 互联很好，如果主机侧无法持续供给数据，多卡同样可能跑不满。
- CPU 核心不足：预处理、Tokenizer 或调度成为瓶颈；
- 系统内存带宽不足：主机侧数据搬运受限；
- NVMe / 网络存储不足：训练数据或模型加载无法及时供应；
- NIC 拓扑不合理：多节点通信需要跨 NUMA 或受 PCIe 限制；
- 电源/散热受限：GPU 无法维持目标频率。
从单机 8 卡到多机多卡，为什么更难扩展？
单机内 GPU 通信通常依赖 PCIe、NVLink 或 NVSwitch；跨节点以后，通信还要经过 InfiniBand 或 Ethernet/RoCE 等网络。此时网络带宽、交换机设计、RDMA、GID、拥塞控制和 NIC/GPU 亲和关系都会影响性能。
因此，8 卡单节点能跑好，并不能直接推出 16 卡、32 卡甚至更多节点能够按比例扩展。
判断 8 张卡是否“值”，建议这样测试
- 先建立单卡或最小可运行基线。
- 固定模型、精度、输入/输出和数据集。
- 依次测试 1/2/4/8 卡，而不是只测最终 8 卡。
- 记录吞吐、延迟、GPU 利用率、显存、功耗和通信指标。
- 用 NCCL Tests 或平台诊断工具验证通信链路。
- 比较扩展效率，并判断瓶颈来自计算、通信还是 I/O。
常见误区
误区 1：总 TFLOPS 直接相加就是应用性能
理论算力是硬件上限指标之一，真实训练和推理还受到算子效率、内存带宽、通信和软件实现影响。
误区 2：8 张卡总显存就是一块统一大显存
多卡显存彼此独立。模型需要依赖并行框架进行切分，跨卡访问和同步会产生额外通信。
误区 3：只要 NVLink 正常，多卡就一定线性
NVLink 可以改善特定 GPU 间通信，但模型并行方式、Batch、Kernel、CPU、网络和 I/O 仍然可能限制整体扩展效率。
常见问题 FAQ
Q1：8 卡服务器应该期待几倍性能？
没有通用倍数。不同模型、并行策略和负载的扩展效率差异很大，应通过 1/2/4/8 卡的同条件基线实测判断。
Q2：推理一定要让一个模型占满 8 张卡吗？
不一定。如果模型单卡或少量 GPU 已能放下，高并发服务可能更适合部署多个模型副本；如果模型权重或 KV Cache 超过少量 GPU 容量，则需要更高的模型并行。
Q3：训练为什么通常更看重 GPU 间互联？
训练过程中梯度和参数同步频繁，部分并行方式需要大量集合通信。通信效率低时，GPU 会等待同步，降低整体利用率。
Q4：怎么确认问题是不是 NCCL 或拓扑？
可以结合 nvidia-smi topo、DCGM、NCCL Tests 和实际应用 Profile 逐层排查。单纯看到 GPU 利用率低，不能直接判断根因。
赋创可提供的支持
赋创可结合客户现有模型、并行方式和代表性业务负载，协助梳理多 GPU 平台的显存、拓扑、CPU、网络和存储需求，并通过标准通信测试与真实业务基线建立多卡扩展和验收参考。
方案咨询
验证多 GPU 平台是否真正有效扩展
赋创可结合客户模型、并行方式、输入输出特征和目标吞吐，协助梳理 GPU 拓扑、通信、主机与网络需求，并通过相同负载建立单卡到多卡的性能基线。