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

GPU 服务器不仅仅是连接到 CPU 的加速器。对于 AI 工作负载而言，有效的单位是整个系统：GPU 内存、主机内存、CPU 通道、存储路径、网络路径、运行时、调度策略，以及衡量已完成工作的方式。

本指南可帮助 AI 开发人员和 ML 基础设施工程师选择、部署和验证云 GPU 服务器，而不是将决策简化为型号名称或每小时费率。使用它来编写工作负载简介，测试实际获得的拓扑结构，安全部署，并让成本与有效产出保持关联。

快速解答：什么是 GPU 服务器？

GPU 服务器是配备一个或多个图形处理单元、用于并行计算的物理或虚拟服务器。它通常包括：

• 一个或多个 GPU 及其高带宽内存（HBM 或 VRAM）
• CPU、系统 RAM、PCIe 通道和主板拓扑
• 用于缓存或暂存的本地 NVMe，以及用于数据和检查点的持久存储
• 面向用户、对象存储以及（在多节点系统中）集合通信的网络接口
• 驱动程序、容器运行时、监控，有时还包括编排层

对于推理，GPU 服务器必须同时支撑模型、KV 缓存、批处理行为和延迟目标。对于训练或分布式微调，GPU 与节点之间的通信路径可能与原始加速器吞吐量同等重要。对于媒体和批处理流水线，存储和启动行为通常决定机器是否将其付费时间用于完成有效工作。

实际含义很简单：根据工作负载简介选择 GPU 服务器，然后使用自己的工作负载进行验证。不要假设具有相同加速器标签的两台主机会有相同表现。

GPU 服务器架构：决定结果的六个层面

可以将 GPU 服务器视为六个相互连接的层面。任何薄弱层面都可能限制整个系统。

加速器和内存是起始约束，而非完整答案

首先考虑模型的内存占用、精度或量化方案、预期上下文长度、并发量和安全余量。GPU 不仅需要容纳静态权重：服务还需要运行时分配、工作区，以及通常会不断增长的 KV 缓存。训练还会增加激活值、梯度和优化器状态。

因此，AI GPU 选择指南应从工作负载开始，而不是从通用的“最佳 GPU”排名开始。如果工作负载能轻松容纳在单个设备上，额外互连可能并不重要。如果它需要张量并行或同步训练，拓扑就成为容量需求的一部分。

节点内拓扑决定多个 GPU 能否协同工作

多 GPU 工作并不会自动变快。GPU 可以通过 PCIe、直接高带宽链路或交换结构进行通信，而且不同 GPU 对之间的路径可能不同。NVIDIA 文档指出，nvidia-smi topo -m有助于揭示节点内拓扑，带宽工具则可验证预期的 GPU 间路径。

在确定使用多 GPU 服务器之前，请记录：

1. 精确主机类型的拓扑图。
2. 框架将使用的 GPU 对之间的点对点可用性。
3. 简单的带宽或集合通信基线。
4. CPU 和 NIC 相对于 GPU 的亲和性。

基于 NVLink 或 NVSwitch 的系统可提供不同于纯 PCIe 布局的通信设计。NVIDIA 的Fabric Manager 文档介绍了 NVLink 和 NVSwitch 在连接 GPU 及管理网络结构中的作用。应将其视为工作负载匹配问题，而非一种标识：独立的单 GPU 推理端点不需要与同步多 GPU 作业相同的互连结构。

主机层和数据路径是常见瓶颈

当主机正在进行分词、媒体解码、加载分片、恢复检查点，或通过意外的 PCIe 路径复制数据时，GPU 可能处于空闲状态。除加速器规格外，还应询问 CPU、RAM、NUMA、本地磁盘和网络的详细信息。

有意识地将本地 NVMe 用于可丢弃的缓存和暂存。对于需要持久保存的模型工件、数据集、检查点、工作流和已验收输出，应将其存放在可更换实例后仍能保留的数据存储上。这种分离方式可使云 GPU 服务器更易于重建，并降低因停止、调整规格或主机故障而丢失恢复工作所需内容的风险。

软件将 GPU 转化为可调度的容量

对于单台服务器，最基本的软件路径通常包括受支持的驱动程序、兼容 CUDA 的运行时、容器工具、工作负载镜像、可观测性和受控访问路径。在 Kubernetes 中，GPU 服务器还需要设备发现、供应商设备插件和调度策略。

Kubernetes 通过设备插件和自定义可调度资源公开 GPU；其GPU 调度文档说明，GPU 资源通过容器限制进行请求。NVIDIA 的GPU Operator捆绑了驱动程序、容器工具包、设备插件、节点标签和基于 DCGM 的监控等常用组件。这些组件可减少重复的配置工作，但版本兼容性、访问策略和验收测试仍由您负责。

根据工作负载概要选择 GPU 服务器

在评估 AI GPU 服务器或专用 GPU 服务器托管方案之前，先编写这份一页式概要：

这份概要可避免代价高昂的不匹配。低延迟服务工作负载可能需要可预测的容量和预热的工件。若批处理作业能够干净地创建检查点，则可能可以容忍中断。训练运行可能需要经过验证的集合通信和持久化检查点。列表中标注“NVIDIA GPU 服务器”或“服务器 GPU”，不足以回答上述任何问题。

在了解工作负载的空闲容忍度和运维需求后，可比较无服务器 GPU 容量与专用 GPU 容量，以权衡不同容量模型。

如何评估 GPU 服务器性能

看起来规格最快的配置，未必能最快完成工作负载。请按以下顺序建立基线。

1. 衡量面向用户或作业的结果

选择工作负载负责人认可的一小组指标：

• 交互式 LLM 服务：首个令牌时间、令牌间延迟、每分钟成功请求数，以及在目标并发量下的尾延迟。
• 批量推理或媒体生成：每小时完成项目数、失败/重试率、队列延迟和每个已验收输出的成本。
• 训练或微调：每秒样本数/令牌数、步骤时间、通信时间、检查点持续时间和恢复时间。
• 嵌入或检索：每秒文档数/向量数、端到端摄取时间和索引持久化时间。

记录输入分布、模型版本、运行时版本、并发量、缓存状态和时间窗口。没有这些条件的基准测试很难复现或比较。

2. 在调优框架之前验证拓扑

对于多 GPU 工作负载，首先检查实际拓扑。NVIDIA 的 NCCL 指南建议在调整调优参数之前，检查节点内映射并测量预期的 GPU 到 GPU 带宽。该指南还警告称，某一基准测试中的改进可能会在其他场景中造成不利影响。

这是一个有用的保护措施：不要一开始就复制另一台主机的环境变量。请先确认 GPU、NIC、驱动程序和通信路径是否符合您希望获得的结果所依据的假设。

3. 分离计算、通信和数据路径时间

如果加速器利用率较低，GPU 不一定就是问题所在。将一次运行拆分为：

1. 排队和冷启动时间
2. 工件下载或模型加载时间
3. CPU 预处理或令牌化
4. GPU 计算
5. GPU 到 GPU 或节点到节点的通信
6. 输出写入、检查点或后处理时间

这种分解让下一步测试变得清晰明确。如果模型加载占主导，就测量存储性能；如果同步作业发生停滞，就测量拓扑和集合通信；如果 GPU 在等待，就测量 CPU 和输入管道行为。然后重新测试相同的工作负载，而不是将新设置与无关的运行结果进行比较。

4. 针对不同问题使用健康检查和主动诊断

生产遥测数据会告诉你节点在运行期间是否出现过某种状况。主动诊断则测试已排空的资源能否执行已知工作负载。NVIDIA 的 DCGM Diagnostics 文档 区分了两者，并指出主动测试可能消耗计算、内存、PCIe、互连、电源和散热容量。

仅在已从正常服务中移除的容量上运行侵入式诊断。利用所得证据决定是恢复、隔离还是进一步调查 GPU 服务器——而不是将其作为应用程序级验收测试的替代方案。

部署云 GPU 服务器：面向生产的流程

以下部署流程可先用于单个虚拟机或裸金属服务器，然后在运营模式需要时扩展至调度器。

步骤 1：将持久状态与可替换计算资源分离

定义三类数据：

• 临时数据：可重新构建的容器层、编译产物和缓存。
• 持久运行时状态：模型、数据集、检查点、工作流和已接受的输出。
• 密钥和配置：凭据、注册表访问权限、服务配置和与审计相关的设置。

通过适合您平台的存储方式挂载持久状态。保留明确的恢复路径。可复现的 GPU 服务器部署应能够替换计算资源，而无需猜测模型或最新检查点的位置。

步骤 2：固定并记录软件栈

记录操作系统映像、GPU 驱动分支、CUDA/运行时兼容性、容器映像摘要、框架版本、模型修订版本和启动配置。不要将“latest”作为生产工作负载唯一的版本引用。

这份记录有助于区分硬件或拓扑问题与意外的软件变更。它还会在驱动程序、运行时或模型更新后为您提供回滚点。

步骤 3：默认将访问设为私有

仅向用户和服务授予其所需的访问权限。常见控制措施包括受限的入站网络规则、基于密钥或身份的管理访问、短期凭据、私有模型/数据路径、最小权限服务账户，以及使用密钥管理器而非将值硬编码到映像中。

具体控制措施取决于您的云环境和合规边界，但原则不变：暴露的 Notebook、推理端口或远程桌面并不是部署策略。

步骤 4：在接收工作负载流量前验证主机

使用简短的预检清单：

• 确认操作系统识别到预期的 GPU 清单和驱动程序。
• 确认容器可以访问目标 GPU。
• 运行一个小型的代表性工作负载。
• 当涉及多个 GPU 时，采集拓扑和通信证据。
• 读取并写入用于模型/检查点的存储位置。
• 确认日志、指标和告警会到达运维人员能够据此采取行动的位置。

在 Kubernetes 集群上，请先安装供应商支持的驱动程序和设备插件路径，再调度工作负载。以下最小示例展示了资源声明；请根据您自己的环境调整映像、命名空间、安全控制措施和调度规则。

apiVersion: batch/v1
kind: Job
metadata:
  name: gpu-acceptance-check
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: workload
          image: registry.example.com/your-workload@sha256:replace-with-image-digest
          resources:
            limits:
              nvidia.com/gpu: 1

使用节点标签、亲和性、污点和配额，防止不兼容的工作负载争用相同的 GPU 容量。Kubernetes GPU 集群指南对多节点调度、队列和运维控制进行了更深入的介绍。

步骤 5：在生产环境之前创建验收门槛

针对每种新主机类型、映像更新或重大拓扑变更，使用相同的验收门槛。

成本控制：为完成的工作付费，而非为看似强大的闲置机器付费

云 GPU 定价只是 GPU 服务器总成本中的一项。应将付费时段与有效产出进行对照追踪：

completed-work cost = compute + storage + data movement + platform/operations overhead + failed/retried work

然后问：

• 服务器保持运行是因为它正在处理有价值的流量，还是仅仅因为关机不方便？
• 工作负载是否能以可预测的方式创建检查点并清理临时数据？
• 模型工件是否被反复复制，而不是从有意配置的缓存或持久存储中挂载？
• 失败的作业是否在没有预算或错误分类的情况下被重试？
• 多 GPU 拓扑是否确实改善了关键工作？

有关容量模型的框架，请参阅GPU 租用价格指南；有关存储、出站流量、空闲时间和支持问题，请参阅云 GPU 隐性成本指南。对于更大规模的部署，GPU 集群架构指南涵盖了当单台服务器不再足够时所需的计算、网络、存储和控制平面层。

何时 GPU 服务器是合适的工具——以及何时不是

当你需要控制运行时、模型工件、调度、系统库、数据本地性或加速器拓扑时，应使用 GPU 专用服务器或云 GPU 服务器。当工作负载的需求足够稳定，足以证明采用这种运维边界是合理的，这也是一个明智的选择。

当直接控制系统并非需求的一部分，且优先目标是在无需自行负责驱动程序、容量分配、运行时维护和硬件诊断的情况下交付模型能力时，应选择托管模型/API 路径。决策应比较已完成工作成本和运维负担，而不应仅在价目表上比较“GPU 云”与“API”。有关这一界限，请参阅GPU 云与模型 API。

GPU 服务器部署检查清单

在批准服务器进入生产环境之前，请确认你能对每个问题回答“是”：

• 工作负载说明是否明确涵盖模型、内存、并发性和成功指标？
• 你是否测试了确切的 GPU 服务器拓扑，而不只是加速器型号？
• 你能否通过固定版本和镜像摘要复现软件栈？
• 持久状态是否与可替换的计算资源分离？
• 工作负载是否具有受限的访问路径和受管理的密钥？
• 你是否具备应用程序基准，以及拓扑和数据路径证据？
• 运维人员能否查看健康状况、错误、利用率和与成本相关的活动？
• 你是否已使用相同的持久状态方案测试重启或替换？
• 当服务器未提供有价值的工作时，是否会被停止、扩缩容或重新用于其他用途？

常见问题

GPU 服务器有什么用途？

GPU 服务器用于可受益于并行加速的工作负载，包括 AI 推理、模型训练、微调、嵌入、仿真、渲染和媒体生成管道。正确的部署方式取决于工作负载的内存、延迟、吞吐量、数据和运维要求。

专用 GPU 服务器是否始终比无服务器 GPU 容量更快？

不是。专用 GPU 服务器可以提供更强的控制力和更稳定的预热容量，但其实用性取决于利用率、启动行为、运行时调优以及周边数据路径。无服务器容量可能更适合突发性、可重启的工作。应在你实际运行时的条件下测量已完成的工作负载。

如何为 LLM 选择合适的 GPU 服务器？

从模型权重、精度、上下文长度、并发性和 KV 缓存余量开始。然后确定模型能否装入单个 GPU，还是需要多个设备；并使用具有代表性的流量，对首个令牌时间、令牌间延迟、吞吐量和尾部表现进行基准测试。不要只根据参数量进行选择。

一台 GPU 服务器需要 Kubernetes 吗？

不是。单个、管理良好的主机可以是最简单且可靠的部署方式。当您需要可重复的调度、隔离、策略、多节点协调，或跨团队共享容量时，Kubernetes 会更有用。采用它是因为它能解决运维问题，而不是因为涉及 GPU。

如何在投入生产前测试 GPU 服务器？

测试与生产环境相似的容器、小型且具有代表性的工作负载、存储读写、可观测性和恢复能力。对于多 GPU 工作负载，还应采集拓扑和通信证据。当需要基础设施级验证时，使用健康监控获取持续信号，并在已排空的容量上运行主动诊断。

围绕工作负载构建系统

合适的 GPU 服务器，能够以可衡量的性能、可恢复的状态和可控的运营成本，持续将您的预期输入转化为可接受的输出。从工作负载说明开始，验证您收到的系统，并让架构决策基于证据而非硬件标签。

如果直接控制硬件至关重要，请利用这些证据自信地选择和运行 GPU 容量。如果并非如此，在承担不需要的基础设施之前，请将服务器的运营成本与托管模型/API 路径进行比较。

来源

• Kubernetes：调度 GPU
• NVIDIA GPU Operator
• NVIDIA DCGM 诊断
• NVIDIA NCCL：性能与调优
• NVIDIA Fabric Manager