GPU 服务器机架：架构、性能与云部署指南

GPU 服务器机架不仅仅是一个装满加速器的机柜。它是一个部署边界，在这里，GPU 拓扑、网络结构、存储、管理、电力、散热和调度要么协同工作，要么造成代价高昂的瓶颈。

对于 AI 开发人员和 ML 基础设施工程师而言，有用的问题不是“一个机架能容纳多少块 GPU？”而是：这个机架能否提供工作负载所需的通信、数据路径和恢复能力？本指南将这一问题转化为一份架构检查清单和云端验收计划。

什么是 GPU 服务器机架？

GPU 服务器机架是指一个物理机架，或由提供商管理的机架级资源分配，其中包含一台或多台 GPU 服务器，以及运行这些服务器所需的网络、电力、散热和管理组件。在云部署中，您可能无法控制机柜本身，但仍应询问拓扑中的哪些部分受到保证：每台主机的 GPU 数量、主机内互连、主机间网络、存储路径、维护域和放置策略。

单台 GPU 服务器是一个节点。GPU 服务器机架则是围绕多个节点构建的系统。GPU 集群可能跨越一个或多个机架。这些区别很重要，因为推理服务可能受限于单台主机的 GPU 内存以及 PCIe/NVLink 路径，而分布式训练或大规模推理则可能受限于主机之间的网络和存储路径。

NVIDIA 的 BasePOD 参考架构说明了这种差异：它将 InfiniBand 计算网络、以太网管理与存储网络，以及带外管理网络分开。您的设计不必复制该参考架构，但在确定容量之前，应明确相应的路径。NVIDIA DGX BasePOD 参考架构

GPU 服务器机架架构：需要梳理的六项内容

首先绘制机架图，展示物理布局和逻辑路径。如果提供商无法披露每个组件，请记录其保证的内容，并在验收窗口期间测试其余部分。

1. 将拓扑视为工作负载输入

GPU 数量并不是完整的容量描述。对于单台主机，应检查 GPU 之间以及 GPU 与 NIC 之间的连接方式。对于跨主机场景，应明确作业是否会停留在单台服务器、单个机架内，还是跨越多个机架。应在工作负载规格中记录预期的放置规则，而不是假定“八块 GPU”在任何环境中都描述同一种机器。

当 CUDA 报告相关 GPU 可以访问彼此的内存时，NCCL 会使用直接的点对点路径。NVIDIA 将 nvidia-smi topo -p2p 记录为检查点对点状态的一种方式；请将其用作验证输入，而不是工作负载基准测试的替代品。NCCL GPU 故障排除指南

2. 分离计算、数据和管理流量

GPU 服务器机架所需的不仅是快速的训练网络。当管理流量、构件拉取、遥测、共享存储和用户访问共用容量不足的路径时，它们可能会干扰工作负载流量。应在架构需要时使用独立的逻辑或物理路径，然后定义以下各项由哪条路径承载：

• 集合通信和 GPU 直连流量；
• 镜像拉取、模型权重、数据集和检查点；
• Kubernetes、SSH、BMC、日志记录和监控流量；
• 到 API、对象存储或下游服务的出站流量。

这在云容量规划中尤其重要：请询问带宽数值描述的是主机间带宽、机架上行链路、存储吞吐量，还是尽力而为的聚合带宽。它们不能互相替代。

3. 将电力和散热作为容量约束进行设计

不要仅根据机架单位数来确定 GPU 服务器机架的规模。机械上能够放入的配置，可能会受设施电力、PDU 冗余、气流方向、液冷要求、电缆弯曲半径或维护净空的限制。NVIDIA 指出，机架布局会因当地的最大功率和散热基础设施而异；实际资源分配应以您的服务器供应商和托管服务提供商的最新文档为准。NVIDIA DGX SuperPOD 常见问题

部署前，请要求以书面形式回答以下问题：

1. 持续机架功耗范围是多少，其中包含哪些冗余假设？
2. 冷却设计采用风冷、芯片直连液冷、后门热交换，还是组合方案？
3. 哪个组件会最先触发降频或维护事件：主机、PDU、网络交换机，还是设施回路？
4. 技术人员能否在不影响相邻容量的情况下维护节点、线缆或后门组件？

如果部署仅在云端进行，请将同样的问题转换为云服务商术语：专用主机放置、维护域、主机更换策略，以及配置完成后资源分配是否可能改变拓扑。

4. 仅在有用时让调度器感知机架

当工作负载关注局部性或故障域时，机架标签很有价值。分布式训练作业可能优先选择单机架放置，然后再扩展到多个机架。高可用推理服务可能会刻意将副本分布在不同机架或主机上。先从一组小型、可审计的标签开始，例如 topology.rack、topology.host-class、topology.fabric 和 topology.failure-domain，然后验证调度器放置是否遵循这些标签。

对于 Kubernetes，请根据其受支持的操作系统、Kubernetes、驱动程序、运行时和部署选项，验证整个 GPU 软件栈——而不仅仅是集群版本。NVIDIA 的 GPU Operator 支持矩阵区分裸金属、GPU 直通 VM 和 vGPU 部署，并发布受支持环境的兼容性详细信息。NVIDIA GPU Operator 平台支持

如何为您的工作负载选择 GPU 服务器机架

使用工作负载简报来确定您需要的是单台高密度主机、一个机架，还是多机架集群。

对于新部署，应将机架方案与更简单的替代方案进行比较。如果工作不需要控制拓扑、数据局部性或自定义服务栈，托管模型 API 的运维负担可能更低。将此GPU 云与模型 API 对比作为决策的一部分，而不是将 GPU 服务器机架视为默认答案。

如何评估 GPU 服务器机架性能

不要仅根据峰值加速器数量就接受一套 GPU 服务器机架。构建一个简短的验收测试，以区分主要性能路径。

步骤 1：采集库存和拓扑基线

对于每台分配的主机，收集 GPU 标识、驱动程序和 CUDA 版本、GPU 到 GPU 的拓扑、GPU 到 NIC 的亲和性、CPU NUMA 布局、本地存储和网络接口。将此记录与部署修订版本一同保存。当镜像、固件、驱动程序或主机更换后性能发生变化时，它可为您提供比较基准。

nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n

不要根据通用检查清单更改内核、BIOS、IOMMU 或 PCIe 访问控制设置。NVIDIA 记录了 Linux 裸金属系统中依赖配置的点对点行为；请使用您实际运行的服务器和云平台所支持的设置。NCCL 拓扑和点对点故障排除

步骤 2：在关键边界进行测试

在三个范围内运行具有代表性的测试：

1. 单节点，用于验证 GPU 可见性以及本地 NVLink/NVSwitch 或 PCIe 路径。
2. 同一机架，用于验证主机间放置和本地网络结构。
3. 跨机架，用于了解当容量扩展或发生故障转移时调度器将使用的路径。

NVIDIA 的 NCCL 测试指南明确使用单节点、单机架和多机架运行来验证 GPU 可见性、节点内互连、节点间网络结构和放置。将延迟和带宽与测试命令、容器镜像摘要、节点列表及放置标签一并记录，以便复现结果。NCCL 验证教程

步骤 3：测量真实应用路径

然后运行您计划提供服务的工作负载。对于训练，请报告每步耗时、数据等待时间、集合通信时间、检查点时间和恢复行为。对于推理，请报告首个令牌时间、输出吞吐量、尾延迟、排队延迟、缓存行为以及错误或重启率。在比较不同部署位置时，保持相同的模型、批处理/并发配置、上下文长度和缓存状态。

这就是如何区分 GPU 问题与数据、网络、调度器或配置问题。

第 4 步：测试计划内故障

可运营的 GPU 服务器机架需要具备恢复路径。在生产流量上线前，请验证当工作节点被排空、节点不可用、作业被抢占，或检查点需要在其他位置恢复时会发生什么。确认持久数据与可替换计算资源相互分离，并且凭证、镜像和可观测性在替换路径上仍然有效。

在云中部署 GPU 服务器机架：实用流程

云部署改变的是控制边界，而非工程工作。您仍然需要明确硬件和部署位置假设。

1. 编写工作负载契约。 明确模型大小、GPU 数量、内存需求、延迟或吞吐量 SLO、网络敏感性、数据源、检查点位置、可用性目标和预算护栏。
2. 选择拓扑边界。 确定作业是否必须保持在单台主机、单个机架或定义的多机架网络结构内。应将此作为向提供商提出请求时的要求，而非非正式偏好。
3. 索取资源分配表。 要求提供主机类别、GPU 数量、GPU 互连、NIC、网络结构、存储选项、部署位置保证、维护策略，以及向您的调度器公开的任何拓扑元数据。
4. 固定软件契约。 记录操作系统、内核、NVIDIA 驱动程序、CUDA、容器运行时、Kubernetes 版本、GPU Operator 版本、框架镜像和应用程序镜像摘要。上线前，请根据受支持矩阵验证该组合。
5. 创建范围有限的验收窗口。 在迁移持续流量之前，运行清单、拓扑、同节点/同机架/跨机架通信、存储、应用程序和恢复测试。
6. 为每一层设置监控。 分别针对 GPU 健康状况、网络结构错误、存储等待、调度器等待、温度或降频事件以及应用程序 SLO 设置告警。单一利用率指标无法解释机架规模的事故。
7. 保留退出和恢复选项。 独立于特定资源分配，维护镜像定义、基础设施配置、持久数据位置、检查点和回滚计划。

有关此流程中主机级部分，请参阅GPU 服务器部署指南。有关多节点控制平面和网络结构视角，请参阅GPU 集群架构指南。

GPU 服务器机架验收清单

在验收新的 GPU 服务器机架、云端专用资源分配或托管部署时，请使用此清单。

• [ ] 工作负载契约明确了拓扑边界：单台主机、同一机架或多机架。
• [ ] 资源分配表明确了每台主机的 GPU 数量、加速器互连、NIC、网络结构和存储路径。
• [ ] 电源、冷却、PDU 冗余、气流或液冷要求以及维护净空均有负责人。
• [ ] 已记录 GPU、驱动程序、CUDA、内核、容器运行时和编排版本。
• [ ] 调度器会公开并遵守工作负载所需的部署位置或故障域标签。
• [ ] 已为每种主机类别存储清单和 nvidia-smi 拓扑输出。
• [ ] 通信测试涵盖生产调度器可能创建的单节点、同机架和跨机架部署位置。
• [ ] 应用程序测试使用具有代表性的数据源和工作负载配置。
• [ ] 已演练检查点、主机排空、替换和回滚路径。
• [ ] 成本报告将有效 GPU 时间与空闲、重试、数据和支持成本分开统计，且不会重复计算相同时间。有关更广泛的成本模型，请先阅读这份GPU 租赁指南。

常见问题

GPU 服务器机架与 GPU 集群相同吗？

不相同。GPU 服务器机架描述物理或由提供商管理的机架级部署边界。GPU 集群是节点的逻辑分组，可以跨越一个机架的一部分、整个机架或多个机架。当网络、存储、故障域和调度跨越物理边界时，这一区别至关重要。

一个 GPU 服务器机架能容纳多少台 GPU 服务器？

不存在有实际意义的通用数量。服务器深度和机架单位数只是第一个约束条件。实际答案取决于服务器的功耗、冷却设计、PDU 容量和冗余、电缆布线、维护访问条件以及设施批准的密度。请根据您将使用的具体主机、机架和数据中心设计验证答案。

每个 GPU 服务器机架都需要 InfiniBand 吗？

不需要。合适的网络结构取决于工作负载和拓扑。单主机工作负载可能根本不需要节点间高性能网络结构。应在分布式工作负载实际使用的网络路径上进行测试，包括同机架和跨机架部署。避免仅根据营销规格选择网络结构。

在验收云 GPU 机架容量之前，我应测试什么？

测试您获得的资源分配：硬件清单、拓扑、GPU 到 NIC 的亲和性、本地和共享存储行为、单节点通信、同机架通信、生产环境中（如可能）跨机架通信、代表性应用行为，以及从计划内故障中恢复的能力。

何时应避免运营 GPU 服务器机架？

当您的工作负载不需要机架级运营所提供的控制能力时，应避免进行机架级运营。如果托管模型 API 能满足模型、延迟、可用性、隐私和成本要求，它可以免除硬件、网络结构、驱动程序、调度器和容量管理方面的工作。在决定采用 GPU 服务器机架之前，请有意识地进行这一比较。

围绕工作负载构建机架

当 GPU 服务器机架的物理设计和云资源分配与工作负载的通信、数据和恢复路径相匹配时，它才能成功运行。明确拓扑，分离可能相互干扰的流量类别，在单节点、同机架和跨机架范围内验证性能，并且仅在真实应用和故障路径都经过测试后才接受容量。

如果不需要机架级控制，请在承担运营负担之前比较模型 API 路径。如果确实需要，请将本指南与 GPU 服务器指南、GPU 集群架构指南和GPU 云成本清单结合使用，将容量转化为可验证的部署。

来源

• NVIDIA DGX BasePOD 参考架构
• NVIDIA DGX SuperPOD 常见问题
• NVIDIA GPU Operator 平台支持
• NVIDIA NCCL GPU 故障排除
• NVIDIA Run:ai NCCL 验证教程