GPU 云服务器的软件系统设计和实践

发布时间：2025-11-05 12:33:05 来源：创站工坊 作者：域名

当我们在云上部署 DeepSeek 系列大模型的服务时候，可以选择多机或者单机 8 卡的软件 GPU 裸金属实例运行满血版，或者选择单卡和双卡 GPU 虚拟机运行蒸馏版。系统

这些 GPU 云服务器实例能否发挥多机、设计多卡、和实单卡的服务性能，将直接影响部署的软件 DeepSeek 服务的吞吐能力。除此之外，系统在训练场景中这些实例的设计相关能力能将直接影响训练时长。

本文将针对 GPU 云服务器的和实软件系统设计和实现进行概述，并分享百度智能云的服务最新实践成果。

1. GPU 处理数据流程

在具体讨论 GPU 云服务器的软件软件设计工作之前，我们首先来看下 GPU 在服务器中是系统如何工作的。

下图是设计一个简化的 GPU 处理数据的流程图，以便梳理一下影响 GPU 云服务器性能的和实关键因素。从图中我们可以看到，数据处理分为以下几个步骤：

图片

第 1 步，所有数据都需要从网络或者存储中读取到内存。这里就涉及到网络或者存储的亿华云传输性能。

第 2 步，当读取到内存之后，CPU 需要从内存中读取相关数据进行预处理，然后将预处理后的数据再写回到内存中。这个过程就涉及到内存自身的带宽性能和 CPU 的处理性能。

第 3 步 ，数据需要从内存拷贝到 GPU 的显存中。这就涉及到 GPU 和系统内存之间的数据传输性能，一般称之为 H2D（Host To Device）。

第 4 步，GPU 从 GPU 显存中读取相关的数据进行运算。此时主要涉及 GPU 的显存带宽和 GPU 的计算性能。如果数据比较庞大，单个GPU无法处理，就涉及到多个 GPU 的处理，那么这里就涉及到多 GPU 之间的集合通信。

第 5 步，如果是单机多卡的情况，就涉及到 GPU 在机内之间数据传输的性能；如果是源码下载多机多卡的场景，那么就涉及到多节点之间的网络传输性能。

第 6 步，当 GPU 运算完成后，数据需要从 GPU 的显存再拷贝到内存中。这里也涉及到 GPU 和系统内存之间的数据传输性能。一般称之为 D2H（Device To Host）。

我们在设计 GPU 云服务器时，需要综合考虑上面 GPU 数据处理链路的每一个环节，然后结合业务特点和使用成本，进行 GPU 云服务器的设计。

2.GPU 云服务器设计的层次划分

谈到 GPU 云服务器的设计，我们一般分为了 4 个层次。下图展现了这个层次结构，涉及到硬件和软件的多个层面。

图片

首先从最下面来看，主要是 GPU 云服务器底层基础技术组件，包括如硬件选型、拓扑结构、GPU 互联和虚拟化技术。这些技术不仅决定了单卡运行的效率，也会影响上层多卡通信的云南idc服务商效率。

向上一层是多卡通信方式。此时我们需要考虑硬件和软件的支持程度，比如是采用共享内存、P2P 、NVLink 还是 GDR 结构，每一种结构都需要考虑到对应的硬件和软件实现。比如有的软件不支持 P2P，此时我们可能就需要退回到共享内存的方式。如果涉及到大模型就需要采用多机多卡，此时还涉及到 RDMA 网络的通讯。

再上一层是集合通信库，即在多卡通信的场景下，我们需要考虑如何提升集合通信的性能，一般会各种 CCL (Collective Communications Library )的通信库，这些库会基于 GPU 卡的互联技术和软件支持，来进行合理的选路。一般来说会先探测出当前的 GPU 能进行哪些通信（比如支持 P2P 或者支持共享内存），然后根据该结果进行合理的选路，并通过合适的通信算法，最大化提升集合通信的性能。

再往上就是 AI 框架。AI 框架依赖于集合通信的性能以提高 AI 计算的能力。

下面我们将详细叙述最底部的 2 个层次如何影响到 GPU 云服务器设计。

2.1. GPU 云服务器基础技术

首先来看下 GPU 云服务器的最底层实现技术，这关系到 GPU 云服务器性能的基础，通常包括如下几方面：

A.硬件拓扑：

a.NUMA 拓扑，包括 CPU、内存和外设等拓扑结构。

b.PCIe 拓扑：包括 GPU 和 RDMA 网卡等设备的 PCIe 拓扑结构。

B.虚拟拓扑：主要指以上拓扑在虚拟机里的实现。

a.如果是单机，包括 PCIe 或者专有总线，影响到单机内多卡通信的效率。

b.如果是多机，主要指多机多卡的互联，包括各种网络协议，如 RDMA 协议，或者专有各种总线协议。

a.前者的 GPU 云服务器以虚拟机形态实现，涉及到 CPU，内存，GPU 的虚拟化，会影响到 GPU 的运行效率。

b.后者的 GPU 云服务器以裸金属形态实现，主要特点是网络和存储的通过硬卸载到 DPU 来提供服务。

CPU：根据 GPU 云服务器的用途，如推理或者训练，选择合适的 CPU。需要考虑的因素，主要有 CPU 的平台类型、核心数量和主频。

内存：GPU 云服务器应配备足够容量和带宽的内存，以支持 GPU 的数据处理需求。例如，使用 DDR5 内存可以提供高达 1200 GB/s 的理论带宽。

GPU：根据 GPU 服务器的用途，如推理或者训练，选择合适的 GPU，主要考虑 GPU 的计算性能、显存大小和互联方式等。

网络：通常包括南北向和东西向两张网络。前者通常用于存储网络业务，后者负责 GPU 跨机通信。要确保两张网络的带宽都足够高，以避免数据传输成为瓶颈。例如，A100/A800 机型的东西向的网卡带宽达 100 Gbps 或者 200 Gbps，不同的网卡带宽会导致集合通信的带宽有差异，从而影响集群训练的性能。

存储：通常配置大容量的 SSD 磁盘，用来存储业务的数据，这里主要考虑磁盘的 I/O 性能和容量等因素。但在进行集群训练时通常会采用分布式文件系统用于存储业务数据，那么对本地磁盘的需求就没有那么高，而分布式文件系统的选型就至关重要。

硬件选型中，每个组件的性能要合理配合，不能导致系统存在瓶颈。比如 CPU 预处理数据时，如果性能过低，会导致 GPU 等待时间过长，或者网络带宽低导致获取数据速度慢，都会导致 GPU 的使用率降低。

单机层面的硬件拓扑，主要涉及 GPU 和 GPU，GPU 和其他组件的拓扑结构，主要包括如下方面：

NUMA（Non-Uniform Memory Access，即非统一内存访问）是一种针对多处理器系统的内存组织方式，每个处理器都有自己的本地内存，处理器访问本地内存的速度比访问其他处理器的内存要快。

GPU 云服务器大多具备多路 CPU，那么系统的 NUMA 拓扑和设置，不仅影响到 CPU 对内存访问的性能，还影响到一些需要访问内存的外设的性能，比如网卡和  GPU 等设备。有关 NUMA 的问题主要包括：

涉及以下几方面：

多个 GPU 之间的互联，根据扩展方式的不同，可以分为 Scale Up 和 Scale Out 两种方式。

Scale Up 是指在同一台服务器上增加 GPU 的数量，提升单机性能，通常可以通过 PCIe 总线和专有总线来扩展。

Scale Out 通过增加多台服务器，每台服务器上配置多个 GPU，形成一个 GPU 集群，来提升整体计算能力，通常通过 RDMA 网络和其他专有网络技术来实现。

PCIe 主要用于连接 CPU 与其他高速设备如 GPU、SSD 和网卡等，2003 年 PCIe 1.0 版本发布，目前已经更新到 6.0 版本，传输速率高达 64 GT/s，16 通道的双向带宽可以达到 256 GB/s，性能和可扩展性不断提高。GPU 通常通过PCIe 连接到 CPU，可以是直通或者通过 PCIe Switch，那么同一主机上的 GPU 可以通过 PCIe 进行通信。

PCIe 总线迭代速度赶不上 GPU 对互联带宽的需求，当前可用的PCIe 5.0 总线的双向带宽只有 128GB/s，无法满足需求，于是各个 GPU 厂家都推出了自己的专有总线。

NVLink 是 NVIDIA 推出的支持 GPU 之间高效通信的总线，目前 NVLink 已经发展到了第 4 代，在 H100 中可以达到最高 900 GB/s 的双向带宽。

图片

NVSwitch 是它的 Switch 芯片，可以支持 GPU 全域互联，目前已经发展到了第 3 代。

图片

如果仅仅使用 NVLink，只能实现点对点的连接，而如果加入到 Switch 之后，就可以实现任意两个 GPU 之间的高速互联，解决了点对点通信的拓扑缺陷。

HCCS 是华为自研的一款高速互联总线，主要用于昇腾系列 AI 处理器之间的互联。它提供了一种高效、可靠的数据传输方式，使得多个昇腾处理器能够协同工作，共同完成大规模的 AI 计算任务。HCCS 采用对等拓扑，单链路的最大带宽是 56 GB/s。昇腾 910B 中的 HCCS 采用点对点拓扑，单链路的最大带宽是 56 GB/s。

当涉及到多机 GPU 通信时，目前主流的选择是 RDMA 网络，包含 Infiniband 和 RoCE 网络。传统的 TCP/IP 网络通信因为需要操作系统内核的介入，涉及较多数据移动和数据复制，不适用高性能计算和大数据分析等需要 I/O 高并发、低时延的场景。

RDMA 是一种计算机网络技术，网卡可以直接远程访问内存或者 GPU 显存的数据，而无需操作系统内核介入，不占用 CPU 资源，可以显著提高数据传输的性能并且降低延迟，因此更适配于大规模并行计算机集群的网络需求。

虚拟化技术主要分为两大类：

他们共同要解决的问题主要是：

传统的 GPU 云服务器，都是基于 CPU 的硬件虚拟化技术来实现，并且大多使用 QEMU 和 KVM 开源技术来开发。GPU 通过透传的方式透传到虚拟机里，GPU 的性能损耗很低。

当前云厂商主流 GPU 云服务器，都开始基于 DPU 进行设计。

DPU 是继 CPU 和 GPU 之后的「第三颗主力芯片」，其设计目标是卸载 CPU 在网络传输和存储的负载。基于 DPU 设计的服务器，大多数为裸金属服务器，没有采用传统虚拟化技术，此时 CPU 和 GPU 基本实现了零损耗。

2.2 GPU 云服务器的多卡通信

基于上面介绍过的 GPU 硬件互联技术，接下来讨论在硬件能力的基础上，多个 GPU 之间如何实现实现多卡通信，这涉及到硬件和软件的支持。

我们知道，很多 AI 模型已经超过了单个 GPU 的显存大小。无论是推理还是训练，都需要多 GPU 来实现。这就涉及到单机多卡和多机多卡的通信问题，这也是我们在 GPU 云服务器设计时面临的主要挑战之一。

首先是单机多卡通信的场景，主要有三种方式。

图片

然后是多机多卡通信的场景，就需要采用上面介绍的 RDMA 网络技术来实现。

多卡通信的性能，决定了上层集合通信的性能。集合通信库会先探测出当前的 GPU 和系统能进行哪些多卡通信的方式，然后根据该结果进行合理的选路，同时选择合适的通信算法，最大化提升集合通信的性能。

单机上多个 GPU 可以通过 PCIe 总线，访问系统内存来共享数据，从而达到通信的目标。

单机上多个 GPU 也可以通过 PCIe 总线，直接进行通信，这就是 P2P 通信。

上面我们介绍过几个厂家的专有互联硬件总线，它们都需要相应的软件支持，来到达单机多卡的通信。

多机多卡场景下，传统的 TCP/IP 网络通信速度过慢，无法满足业务的需求。目前我们主要使用基于 RDMA 网络的 GDR 技术来实现， 即 GPU Direct RDMA。它支持 RDMA 的网卡直接访问 GPU 的数据，大大提升了多机多卡的通信效率。下面我通过一个例子来为大家讲解 GDR 是如何提升通信效率的。

在传统的多卡通信中，即图中红色步骤，共分为 5 步：GPU 将数据传给内存 —— RDMA 网卡从内存中拿到数据 —— RDMA 网卡将数据传给另外一个节点的 RDMA 网卡 —— 新节点的 RDMA 网卡将数据传给该节点的内存 —— GPU 从内存中拿到该数据。

而 GDR 的方式绕过了系统内存的中转，让 RDMA 网卡可以直接从 GPU 处获取数据，如图中蓝色步骤，共分为 3 步：RDMA 网卡从 GPU 处获取数据—— RDMA 网卡将数据传给另外一个节点的 RDMA 网卡 —— 新节点的 RDMA 网卡将数据传输给 GPU。

图片

得益于 GDR 的方式可以在 PCIe Switch 中进行传输，不仅仅提供了高速了数据传输，同时也减少了上行链路中的带宽争抢。相比于传统的方式，采用 GDR 的方法可以提升整体 3-4 倍的带宽。大大提升了多机多卡的通信效率。

3. 百度智能云的 GPU 云服务器设计实践

百度智能云主要有两类 GPU 云服务器的实例，第一类是 BCC（Baidu Cloud Compute） GPU 云服务器，基于 Qemu/KVM 虚拟化的 GPU 服务器。第二类是 BBC（Baidu Baremetal Compute） GPU 云服务器，即基于裸金属的 GPU 云服务器。

3.1 BCC GPU 云服务器

我们先来看 BCC，即基于 Qemu/KVM  虚拟化的 GPU 云服务器。整体的设计如下图所示：最下方是实际的 GPU 硬件，上层是包括 VFIO 和 KVM 在内的内核，再往上是 Hypervisor 和实际的虚拟机。主要适用于小模型的训练和推理、图像识别、推荐系统等场景。

图片

在这样的结构中，GPU 会通过 VFIO 技术整卡透传给虚拟机，使得整体算力的的损耗比较小。此外，它还可以支持 1 卡、2 卡、4 卡和 8 卡的实例，让客户可以根据实际需要来进行采购，大大降低了客户的使用成本。

但在这种结构中，BCC 的拓扑结构是虚拟的，这也意味着虚拟机中的拓扑结构和实际物理形态中的拓扑结构是有差异的。这些会为实际业务的运行带来一些性能影响，我们通过一些虚拟机的设计消化了影响，分别为：

虚拟机里为什么需要 GPU 的 NUMA 感知呢？主要的原因在于保证 CPU 和 GPU 在同一个 NUMA 下，这样就可以避免数据在系统内存和 GPU 显存之间的传输性能损失。

实际上，系统内存、CPU 和 GPU 都存在 NUMA 属性的，如果彼此之间不在一个  NUMA 中，那么实际的性能差距就会受到影响，尤其是在 AMD MILAN 平台上， GPU 跨 NUMA 访问的 PCIe 带宽只有同 NUMA 访问性能的一半。

图片

在虚拟机实现时，如果没有考虑到 NUMA 属性，当我们将 GPU 透传到虚拟机时，CPU 0 以及 Memory 0 不知道它要访问的 GPU 是在同一个 NUMA 下还是跨 NUMA，这就大大降低了 GPU 和内存之间的传输效率。所以我们需要在 GPU 透传到虚拟机的时候，让它感知到在哪一个 NUMA 下，这样在虚拟机内就可以强制把 GPU、CPU 以及 Memory 绑定在一起，大大降低了传输过程中的性能损失。

在实现时，虚拟机每个 NUMA 的 CPU 都会扩展出一个 PCIe bus。此时，实际物理机上的 NUMA 0 上的 GPU，在透传给虚拟机的时候就会挂载到虚拟机的 NUMA 0 的 PCIe bus 上，NUMA 1 上的 GPU 会挂载到 NUMA 1 的 PCIe bus 上，这样 GPU 就可以在虚拟机中感知到 NUMA，从而避免跨 NUMA 传输的性能损失。

图片

我们的第二个改进是在虚拟机内对 GPU 的 PCIe P2P 支持。在物理机上如果要支持多 GPU 的 P2P，一般需要满足两个条件：

在物理机以上两个条件都是支持的，但是当 GPU 透传到虚拟机的时候就，要支持 PCIe P2P 就有新问题。

第一个问题是因为虚拟机的 PCIe 拓扑结构是扁平的，驱动在虚拟机内无法识别 GPU 的拓扑，所以无法开启 GPU 的 P2P 能力。这里需要修改 Hypervisor 的实现，在 Hypervisor 模拟的 GPU PCIe 配置空间里增加一个 PCI Capability，让驱动识别出 GPU 的 P2P 亲和性，这样 GPU 驱动就可以根据这个信息来开启 P2P 能力。

第二个问题是，如果在物理机上通过 PCIe Switch 连接的两个 GPU，要在虚拟机场景下进行 P2P 通信，比物理的性能要差很多。这是因为透传到虚拟机的 GPU 不支持 ATS，他们的 P2P 通信都会被路由到 IOMMU，而无法通过 PCIe Switch  中转，这样通信的路径就长了，导致性能下降。这个问题目前暂时无法解决。

第三个改进是实现了对 A100 和 A800 的 Shared NVSwtich 机型的支持。

下图是 A100 和 NVSwitch 连接的拓扑图。我们可以看到，一台机器中有 8 张 A100 的卡，以及 6 个 NVSwitch。它通过 NVSwitch 的连线，可以进行任意两卡之间的 NVlink 高速互联。

图片

但如果要做 A100 的虚拟机，会存在有一个问题：如果我们要实现一个 2 卡的虚拟机，在将 GPU 传到虚拟机的同时还需要透传 NVSwitch。但由于 NVSwitch 采用了全连接的形式，如果要保证两卡的满速互联，那么就需要将 6 个 NVSwitch 都透传到虚拟机中，此时剩下的 6 张 GPU 就无法继续使用 NVSwitch，这就造成了 GPU 资源的浪费。

为了解决这个问题，可以使用如下两种方案：

第一种是 Full Passthrough 机型。这种方案就是将所有的 GPU 和所有的 NVSwitch 都透传到一个虚拟机中，但这样的机型在 1 卡、2 卡、4 卡的情况下会损失部分 NVLink 的带宽。

图片

另外一种是 Shared NVSwtich 机型。这种设计需要创建一个 Service VM 的虚拟机，这个虚拟机只透传 NVSwitch。而用户使用的虚拟机则只需要透传 GPU。在 Service VM 中可以对 NVSwitch 进行管控，让用户虚拟机内的 GPU 都可以进行高速互联。

图片

通过这样的方式，解决了用户使用 1 卡、2 卡或者 4 卡虚拟机时，虚拟机内部  GPU 之间 NVLink 高速互联不损失的问题。

第四个改进是支持 RDMA 网卡透传。有的 GPU 机型，除了要透传 GPU 外，还需要把 RDMA 网卡透传到虚拟机里。透传 RDMA 网卡这点从技术上实现是比较简单的，但是如果未做任何优化手段的话，实测发现，虚拟机里的 GDR 性能，只有物理机的 25% 左右，这显然是无法接受的。为了改进这个问题，需要我们做一些相关的设置和改进。

通过以上两个设置，就可以加速虚拟机中的 GDR 传输性能。

但是我们发现另外一个问题，即多机 NCCL 的性能只有物理机的 1/4。在物理机拓扑中，RDMA 网卡和 GPU 在同一个 PCIe Switch 下，但是在虚拟机拓扑中， GPU 和 RDMA 网卡是平铺在一个总线上的。而对于 NCCL 来说，如果是物理机的场景，那么 NCCL 就会选择 GDR 通信；而在虚拟机场景下，NCCL 则会认为这些网卡和 GPU 无法做 GDR 通信，因此还是按传统的通过内存中转的方式来进行通讯。我们采用了 2 种解决方法来修复这个问题：

通过这样的方式，我们虚拟的集合通信的性能可以和我们的物理机打平。

3.2 BBC GPU 云服务器（裸金属）

接着是 BBC GPU 云服务器，即基于裸金属的 GPU 云服务器。服务器的外设除了 GPU、NVSwitch 和 RDMA 等硬件之外，还通过 PCIe 总线连接了一个 DPU，给主机提供网络和存储的卸载功能，主机上的网络和存储的相关功能都在 DPU 上实现。

这类服务器相比 BCC 服务器来说，因为 CPU、内存、GPU 都不需要虚拟化，整体的算力损耗是零。

图片

目前，我们已经实现了 BCC 和 BBC 的融合，在统一的硬件架构上，既可以交付虚拟机形态或者裸金属形态的 GPU 计算实例。

图片

DPU 核心能力在于卸载、加速和隔离数据中心的基础设施任务，从而释放主机的 CPU 算力，提升整体主机的系统效率。其核心功能包括：

以下是我们主推的 A800 训练机型，它的规格如下：

其中 8 个 A800 芯片通过 6 个 NVLink Switch 芯片进行卡间的高速互联，双向带宽达到 400 GB/s，同时通过 4 张 PCIe Switch 和网卡进行连接。（每张 PCIe Switch 连接了两张 A800 和两张 CX6 100G RoCEv2 的网卡进行 GDR 的通讯）。

目前百度智能云也提供了 L20 的机型。由于 L20 可以进行卡间的 P2P 传输。所以每个 PCIe Switch 都连接了 2 张 L20 和一张 400G RoCE v2 网卡，大大提升多机互联的带宽。通过这样的架构设计，我们既可以做模型的推理，也可以进行大模型的训练。

百度智能云也提供了 H20 96GB 显存版本的 BBC 机型。H20 96GB 是 H100 的精简版，虽然对算力进行了剪裁，但是保留了 H100 的卡间互联带宽，支持 NVLink 和 NVSwitch，适合大模型的推理和训练。

H20 96G 8 卡 BBC 机型支持单机跑 DeepSeek V3 和 DeepSeek R1 模型的满血版本。百度智能云同时推出了 H20  141GB 显存版本的机型，提供单卡 141GB 的显存，对 Deepseek 大模型提供了更高的吞吐支持。

4. GPU 云服务器的未来发展

4.1 Scale Up 和 Scale Out 的融合统一

在过去万卡集群的建设中，云厂商的注意力主要放在 Scale Out 上，通过多机互联技术合理的网络架构，建设一个超大规模的集群，以实现超强算力。

同时，Scale Out 和 Scale Up 技术是互相促进和发展，Scale Out 的互联带宽要匹配对应的 Scale Up 带宽，如果 Scale Up 带宽很高，而相应的 Scale Out 的带宽较低，会造成集合通信在多节点上成为瓶颈。这个相互关系，我们可以从 H800 实例配置 400G 的 RDMA 中可见一斑。

不过，随着集群能力的要求越来越高，单纯扩大规模变得不够经济有效，Scale Up 逐渐成为关注点，并且两者之间的边界变得模糊，节点间和节点内的互联技术逐渐对齐，以 NVL72 为代表的「高密机型」就是这个思想的体现，使用 NVLink 作为节点间的连接方式。

4.2 推理卡和训练卡的分野

大模型推理需求的爆发，将使得成本的关注变得非常敏感。相比算力的提高，大模型推理对 GPU 显存的大小和互联带宽有着更高的需求，从 DeepSeek R1/V3 可见一斑。

同时，专用芯片的崛起，将进一步降低大规模部署情况下的成本。例如现在各大厂商都在设计针对推理优化的 ASIC 芯片，通过简化计算单元、采用 SRAM 替代 HBM，可以实现数倍于传统 GPU 的能效比提升。

相关文章