为什么大模型需要多张 GPU？从显存需求到 TP、PP、DP 讲清 8 卡部署逻辑

概述

看到大模型服务器配置时，经常会出现 4×GPU、8×GPU，甚至多个 8-GPU 节点。一个很自然的问题是：单张 GPU 已经拥有很高的计算性能，为什么一个模型还需要同时使用多张 GPU？

原因通常不只是“为了更快”。对大模型来说，多 GPU 更常见的作用是解决三件事：模型和运行时数据能不能放得下、计算任务如何拆开，以及系统能不能支撑更大的训练规模或推理吞吐。

因此，理解多 GPU 部署时，最好不要先从“几张卡”开始，而是先看模型规模、数据精度、上下文长度、并发、GPU 互联方式和最终性能目标。

第一道门槛：往往不是算力，而是显存

模型权重的显存占用可以先做一个基础估算：

以 70B 参数模型为例，只计算模型权重时，大致可以得到：

数据精度	单参数存储量	70B 权重理论占用
FP16 / BF16	约 2 Byte	约 140GB
FP8 / INT8	约 1 Byte	约 70GB
INT4	约 0.5 Byte	约 35GB

但这里有一个很容易被忽略的地方：权重显存不等于完整部署显存。

模型真正运行时，还可能占用 KV Cache、运行时缓存、临时 Tensor、框架和算子工作区等空间。上下文越长、并发越高，KV Cache 等运行时显存的压力通常也越明显。

如果是训练场景，还要继续考虑激活值、梯度、优化器状态以及分布式训练过程中的额外内存开销。

多张 GPU 怎么一起跑一个模型？

当单张 GPU 无法承载完整模型，或者单卡无法满足计算和吞吐要求时，就需要把模型、计算或数据分配到多张 GPU。

常见的并行方式包括 Tensor Parallel、Pipeline Parallel 和 Data Parallel。它们解决的问题并不一样，实际系统中也经常组合使用。

Tensor Parallel：把同一层计算拆到多张 GPU

Tensor Parallel，简称 TP。它会把单个模型层内部的 Tensor 或矩阵计算拆分到多个 GPU 上协同完成。

可以把它理解成：同一道很大的计算任务，由多张 GPU 一起完成。

TP 适合处理单层较大、单卡难以容纳或计算压力较高的模型结构，但它也意味着 GPU 之间需要更频繁地交换中间结果。因此，TP 对 GPU 间通信能力比较敏感。

在实际系统中，NVLink、NVSwitch、PCIe 拓扑，以及通信库和软件实现，都会影响这类并行的效率。

Pipeline Parallel：把不同模型层分配到不同 GPU

Pipeline Parallel，简称 PP。它会沿模型深度方向切分，把不同层放到不同 GPU 或不同 Pipeline Stage 上。

例如，可以让 GPU 1 负责前面一部分层，GPU 2 负责中间一部分层，后面的 GPU 再继续完成剩余计算。

这种方式能够降低单张 GPU 承载完整模型的压力，但 Pipeline 并不是任何时候都能保持满负荷运行。不同 Stage 之间可能出现等待，也就是常说的 Pipeline Bubble。

因此，PP 的实际效率还会受到 Stage 划分、Micro Batch 和调度方式的影响。

Data Parallel：复制模型，拆分数据

Data Parallel，简称 DP。它的基本思路不是把同一个模型层拆开，而是让不同 GPU 持有模型副本，并分别处理不同的数据或请求。

在训练中，各个数据并行副本通常需要同步梯度；在推理服务中，也可以通过多个 Replica 来提高整体并发和吞吐。

因此，传统 DP 更主要解决的是数据规模和吞吐扩展。如果完整模型本身就无法放入单张 GPU，单纯增加 DP 副本并不能直接解决模型容量问题。

需要补充的是，现代分布式训练还存在 FSDP、ZeRO 等对模型状态进行分片的方式，它们与传统“完整复制模型”的数据并行并不完全相同。实际项目中需要结合训练框架和模型规模具体判断。

为什么 8 张 GPU 不等于 8 倍性能？

理论上，如果把一张 GPU 的性能记作 1，8 张 GPU 的峰值算力可以简单相加。但真实应用中的性能通常不会完全线性增长。

主要原因包括：

• GPU 间通信：TP 等并行方式需要频繁交换 Tensor 或中间计算结果。
• 同步等待：不同 GPU 的计算进度并不总是一致，部分设备可能需要等待其他设备。
• Pipeline Bubble：流水线启动、排空和 Stage 不均衡都会降低有效利用率。
• 显存与数据搬运：AI 工作负载不仅受计算单元影响，也会受到 HBM、PCIe、CPU 内存以及节点间网络的限制。
• 软件栈与调度：Kernel、通信库、推理引擎、Batch 策略和调度方式都会影响最终性能。

所以，看多 GPU 系统时，比“GPU 数量”更有意义的是扩展效率：增加 GPU 以后，真实吞吐提升了多少，延迟是否满足要求，以及为了得到这些性能付出了多少通信和系统成本。

为什么经常看到 8-GPU 服务器？

8 GPU 并不是大模型部署的固定答案，它更多是一种常见的高密度服务器节点形态。

有些模型单张大显存 GPU 就可以部署；有些需要 2 张或 4 张；更大的模型、更长上下文、更高并发，或者训练任务，则可能需要 8 张 GPU，甚至多个计算节点。

所以，“大模型 = 8 GPU”并不成立。更准确的问题应该是：

这个模型和业务，为什么需要 8 张 GPU？

只有把模型规模、精度、上下文、并发目标和 GPU 互联方式一起放进来，8 卡配置才有实际意义。

实际选型时，应该看哪些指标？

评估一套 4-GPU 或 8-GPU AI 服务器时，建议至少同时看下面几个维度。

维度	主要影响
模型参数规模与数据精度	决定模型权重的基础显存需求，也直接影响是否需要多卡分片。
上下文长度	会影响 KV Cache 等运行时显存占用，长上下文场景尤其需要单独估算。
并发与 Batch	决定系统需要同时服务多少请求，以及吞吐与显存之间如何平衡。
首 Token 延迟与生成速度	直接影响交互体验，不能只看总吞吐。
整体吞吐	决定单位时间内能够处理多少 Token 或请求。
GPU 互联方式	会影响 TP 等多 GPU 并行中的通信效率。
CPU、内存、PCIe 与网络	共同决定整机数据供给、扩展和多节点通信是否可能形成瓶颈。
软件栈	推理引擎、通信库、量化方案和调度策略都会影响实际利用率。

常见问题

为什么大模型需要多张 GPU？

常见原因包括单卡显存无法容纳模型和运行时数据、需要把模型或计算拆到多个 GPU，以及需要提升训练规模或推理吞吐。多 GPU 首先解决容量和计算拆分问题，并不只是为了提升速度。

70B 模型到底需要多少显存？

如果只计算权重，70B 模型在 FP16/BF16 下约为 140GB，在 FP8/INT8 下约为 70GB，在 INT4 下约为 35GB。但实际部署还需要为 KV Cache、运行时缓存、框架和算子工作区等预留显存，因此不能直接用权重大小等同于完整部署需求。

8 张 GPU 会比 1 张 GPU 快 8 倍吗？

通常不会。多 GPU 系统会增加通信、同步、流水线和调度开销，真实扩展效率取决于模型结构、并行方式、GPU 互联、软件栈和负载特征。

TP、PP、DP 有什么区别？

TP 主要拆分单个模型层内部的计算，PP 主要按模型深度拆分不同层，DP 则主要复制模型并拆分数据或请求。三者解决的问题不同，在大型训练或推理系统中可以组合使用。

模型能放进单张 GPU，是不是就没必要用多卡？

不一定。如果单卡已经能够满足目标上下文、并发、吞吐和延迟要求，多卡可能没有必要；如果单卡虽然能装下模型，但业务要求更高的并发或吞吐，仍可能需要多 GPU 或多副本部署。

结论

大模型使用多张 GPU，可以按三个层面来理解：先解决“放不放得下”，再解决“怎么算”，最后才是“怎样跑得更快、服务更多请求”。

所以，看到 4 卡、8 卡或者多节点配置时，真正值得关注的不是 GPU 数量本身，而是模型为什么需要这些 GPU、采用了什么并行方式，以及最终获得了多少有效性能。

实际选型也应该从模型和业务目标倒推：模型规模、数据精度、上下文、并发、延迟和吞吐要求确定以后，再决定 GPU 型号、数量、互联和整机架构。

方案咨询

需要把方案落到实际配置？

联系赋创获取算力、软件栈和交付路径建议。

咨询方案浏览指南