GPU 集群架构指的是整个系统的形态，而不仅仅是 GPU 数量。生产级集群必须先协调计算节点、高速网络、存储、调度器、访问控制、遥测和恢复路径，才能把昂贵的加速器转化为有用的训练任务或可靠的推理服务。
实际问题很简单：你的团队能否足够快地移动数据、调度作业、恢复故障并衡量成本，以保持 GPU 持续繁忙？如果不能，即使配备更好的卡，集群的经济性也可能不如更小的托管 GPU 服务或模型 API。
本指南为 AI 平台团队提供一个关于 gpu cluster architecture 的实用模型：计算层应包含什么，网络必须验证什么，存储和检查点如何配合，Kubernetes 或 Slurm 如何成为控制平面，以及在租用或购买多节点容量之前应测试什么。
Flatkey 的实用原则是从工作负载边界开始。如果产品只需要模型输出，先基准测试一条 GPU cloud vs model API 路径。如果你需要自定义权重、放置控制、长时间运行的训练或私有服务基础设施，那么就要围绕工作负载的计算、网络、存储和控制平面需求来设计 GPU 集群。
GPU 集群架构快速答案
一个有用的 GPU 集群包含四个平面：
| Plane | What it owns | Common failure when skipped |
|---|---|---|
| Compute | GPU 服务器、CPU/RAM 比例、本地 NVMe、GPU 拓扑、驱动、CUDA、容器、MIG 或整卡分配 | 团队买对了 GPU 型号，却买错了节点形态、内存布局或驱动栈。 |
| Network | 节点内 NVLink/NVSwitch、跨节点 InfiniBand、RoCE、EFA、以太网、放置、DNS、入口、服务网格边界 | 多节点作业扩展性很差，因为“高速网络”从未用真实的 all-reduce 或服务流量进行验证。 |
| Storage | 数据集分发、模型权重、检查点写入、共享文件系统、对象存储、本地临时空间、快照、备份、清理 | GPU 因数据加载而空闲，检查点阻塞训练，或重启恢复耗时过长。 |
| Control plane | Kubernetes、Slurm、Kueue、Volcano、Ray、用户访问、配额、可观测性、计费标签、安全策略、事件响应 | 作业可以运行，但没人能解释排队时间、资源分配公平性、故障或单位成本。 |
当这些平面被一起设计时，multi-node gpu cluster architecture 才能成功。没有网络织物的计算只是孤立容量。没有存储的织物只是在搬运瓶颈。没有配额、遥测和运行手册的 Kubernetes 只是一种启动机制。
GPU 集群架构图
在比较供应商或批准机架设计之前，可将此图作为审查框架。
users / CI / product traffic / API clients
|
v
+------------------------------------------------------+
| control plane |
| Kubernetes or Slurm scheduler, queues, quotas, |
| secrets, registry access, policy, telemetry, billing |
+------------------------------------------------------+
| | |
v v v
+-------------------+ +-------------------+ +-------------------+
| gpu compute node | | gpu compute node | | gpu compute node |
| GPUs, CPU, RAM, | | GPUs, CPU, RAM, | | GPUs, CPU, RAM, |
| local NVMe, NICs | | local NVMe, NICs | | local NVMe, NICs |
+-------------------+ +-------------------+ +-------------------+
\ | /
\ | /
v v v
+------------------------------------------------------+
| high-speed fabric |
| NVLink/NVSwitch inside node; InfiniBand, RoCE, EFA, |
| or Ethernet across nodes; placement and routing |
+------------------------------------------------------+
|
v
+------------------------------------------------------+
| storage and data path |
| object store, shared filesystem, local scratch, |
| model cache, checkpoints, snapshots, backups |
+------------------------------------------------------+对于 kubernetes gpu cluster architecture diagram，在控制平面周围添加 Kubernetes 特有对象：
cluster admins -> node images -> GPU Operator / device plugin -> GPU nodes
app teams -> namespace -> quota -> job queue -> Pod / Job / RayJob
finance -> labels -> usage export -> cost per job / team / model
security -> secrets -> image policy -> network policy -> audit logs这张图刻意保持简洁。目标不是画出每一项服务，而是在集群成为生产依赖之前发现缺失的职责。
从工作负载开始，而不是从机架开始
在选择 Kubernetes、Slurm、云预留资源或裸金属供应商之前，先写一页工作负载说明。
| 字段 | 需要定义什么 |
|---|---|
| 工作负载类型 | 预训练、微调、批量推理、在线推理、嵌入、检索、图像/视频生成、仿真或研究笔记本。 |
| 框架 | PyTorch、JAX、TensorFlow、vLLM、SGLang、TensorRT-LLM、Ray、Slurm、Kubernetes Jobs，或自定义服务。 |
| GPU 目标 | H100、H200、B200、A100、L40S、RTX PRO、AMD MI 系列，或可接受的范围。 |
| 节点形态 | 每节点 GPU 数、GPU 显存、CPU 核心数、系统内存、本地 NVMe、NIC 数量和功耗预算。 |
| 规模形态 | 单节点、多节点同步训练、分片推理、批处理队列或混合平台。 |
| 网络敏感度 | 所需的 all-reduce 性能、延迟容忍度、placement group 需求、流量隔离和出站路径。 |
| 存储敏感度 | 数据集大小、模型权重大小、检查点频率、恢复目标、文件系统需求以及对象存储区域。 |
| 运维边界 | 谁负责驱动、镜像、调度器策略、遥测、支持、补丁、用户访问和事件响应。 |
| 业务分母 | 每次完成的训练运行成本、每个被接受的推理输出成本、GPU 小时利用率或预留 GPU 月。 |
如果你无法填写这张表，现在还不要签长期容量合同。先租用更小的一部分，运行基准测试，并把日志整理成采购简报。GPU 集群租赁指南在架构形态明确后提供买方检查清单。
计算平面：GPU 节点并非可互换
计算平面定义了一个作业实际上可以使用什么。完整的计算规格不仅仅是“8x H100”或“B200 集群”。
请询问：
- GPU 型号、显存大小，以及相关场景下是 PCIe 还是 SXM。
- 每节点 GPU 数量及节点内拓扑。
- CPU 型号、CPU 数量、系统内存和 NUMA 布局。
- 本地 NVMe 容量和预期吞吐量。
- NIC 数量、NIC 速度，以及是否支持 GPU-direct 路径。
- 驱动、CUDA、容器运行时和 OS 镜像生命周期。
- MIG、vGPU、时间切片或整卡分配策略。
- 节点同质性和替换策略。
节点内拓扑很重要，因为一台服务器中的八块 GPU 并不等同于八个单 GPU 节点。节点设计决定了内存压力、CPU 瓶颈、本地暂存速度，以及跨节点通信会变得多昂贵。
NVIDIA 的 Kubernetes GPU Operator 文档在这里很有用，因为它展示了如何将驱动、NVIDIA Container Toolkit、device plugin、DCGM 遥测以及相关组件作为一个集群栈来管理，而不是零散地配置单个节点。Kubernetes device plugin 文档解释了用于将厂商设备作为可调度资源暴露出来的一般扩展点。
网络平面：用基准测试证明 Fabric
多节点训练和高吞吐量服务依赖网络。集群规格应写明 fabric 和验收测试，而不只是带宽宣传数字。
请询问：
- 节点内 NVLink 或 NVSwitch 细节。
- 跨节点 InfiniBand、RoCE、EFA 或以太网设计。
- 每节点 NIC 数量和速度。
- 放置保证和故障域。
- 超售比。
- 相关场景下的 GPUDirect RDMA 支持。
- 容器和主机网络模型。
- 对 fabric 错误、重传、拥塞和节点故障的可观测性。
在承诺开始前使用验收测试：
network acceptance test:
run NCCL all_reduce across every rented node
record bandwidth, latency, node IDs, GPU model, driver, CUDA, NCCL version
repeat after installing the production container image
save logs and compare them with the provider's quoted topologyNVIDIA NCCL 和 NCCL tests 是验证分布式 GPU 工作负载中集合通信行为的标准参考。关键不是追逐某一个基准数字。关键是在完整训练运行失败之前，发现不匹配的节点、错误的放置、fabric 拥塞或驱动/容器漂移。
对于推理，网络测试应包括真实流量路径：请求入口、模型分片通信、KV 缓存行为（如适用）、存储拉取和出站流量。如果服务栈跨越太多网络边界，那么即使训练 fabric 单独看起来很强，也可能产生较差的用户延迟。
存储平面：让数据、权重和检查点远离关键路径
存储是许多 GPU 集群架构方案变得昂贵的地方。GPU 报价是可见的。数据路径通常隐藏着，直到第一次生产运行才暴露。
围绕四条流来设计存储：
| 流 | 架构问题 |
|---|---|
| 数据集暂存 | 将数据集从对象存储、远程文件系统或数据仓库移动到节点需要多长时间？ |
| 模型权重 | 基础权重、微调权重、分词器文件和引擎产物缓存在哪里？ |
| 检查点 | 检查点写入频率是多少、大小多大，以及节点故障后恢复需要多长时间？ |
| 输出和日志 | 生成的产物、指标、追踪和审计日志存到哪里，适用什么保留策略？ |
对于训练，检查点吞吐量和恢复时间是架构问题，而不是备份细节。对于推理，模型权重加载、本地缓存预热和持久卷行为会影响部署时间和故障切换时间。
NVIDIA 的 GPUDirect Storage 文档是一个很有用的参考来源，适用于架构需要在本地或远程存储与 GPU 内存之间建立直接数据路径的场景。并非每个集群都需要 GPUDirect Storage，但那些传输大规模数据集或检查点的团队，应明确决定存储栈是普通方案、优化方案，还是接受其成为瓶颈。
控制平面：Kubernetes、Slurm，还是两者兼有？
控制平面将硬件转化为平台。它决定谁可以运行什么、作业何时启动、故障如何重试，以及团队如何理解资源使用情况。
Kubernetes GPU 集群架构
Kubernetes 适合需要服务部署、多租户命名空间、容器原生工作流、API 驱动自动化、策略以及与云原生可观测性集成的 GPU 平台。生产环境中的 kubernetes gpu cluster architecture 通常包括：
- 节点镜像和引导自动化。
- GPU Operator 或厂商特定的驱动/设备插件管理。
- 用于 GPU 暴露的设备插件或动态资源分配。
- 命名空间、RBAC、密钥、镜像拉取策略和网络策略。
- Jobs、Deployments、RayJob、训练 operator 或推理服务。
- 当批处理公平性很重要时，使用 Kueue 或其他排队层。
- 按团队、项目、环境或客户划分的配额。
- DCGM、Prometheus、日志、追踪以及计费标签。
- 针对镜像、特权工作负载、主机挂载和 GPU 共享的准入控制。
Kubernetes 设备插件将 GPU 作为扩展资源暴露出来。Kubernetes 动态资源分配为设备和其他专用资源引入了更丰富的基于声明的资源模型。Kueue 增加了工作负载、队列、cohort 和资源 flavor 等作业排队概念，用于批处理以及 AI/ML 调度。将这些工具组合起来，可以把 GPU 资源池变成受治理的平台，而不是一组可通过 SSH 访问的机器。
Slurm GPU 集群架构
Slurm 适合许多 HPC 风格和研究环境，因为它围绕队列、分区、计费、保留和批处理作业构建。Slurm 的 GRES 文档涵盖了 GPU 资源以及作业如何请求这些资源。
在以下情况下，Slurm 往往是很好的选择：
- 用户提交批训练作业。
- 队列策略居于核心地位。
- 团队已经具备 HPC 运维经验。
- 工作负载的服务化程度较低。
- MPI、NCCL 测试和批计费是熟悉的运维原语。
有些组织会同时运行两者：用 Slurm 负责研究和大规模训练队列，用 Kubernetes 负责推理服务和平台 API。这可以奏效，但前提是身份、数据访问、可观测性和成本分摊必须跨两个系统进行设计。
可观测性和成本控制应当在最初设计中包含
不要等集群上线后再补 telemetry。对工程和财务真正重要的问题是可以预见的：
- 哪些作业使用了哪些 GPU？
- 是哪个命名空间、团队、客户、模型或实验导致了这些支出？
- 实际有效利用率是多少，而不只是分配到的 GPU 时间？
- 有多少时间耗在队列等待上？
- 哪些故障消耗了最多的 GPU 小时？
- 是哪些存储或网络瓶颈导致 GPU 闲置？
- 每次完成运行或接受输出的成本是多少？
最低限度的 telemetry 应包括：
- GPU 利用率、内存利用率、功耗、温度和 ECC 事件。
- 按作业划分的运行时间、排队时间、重试次数、退出原因和所有者。
- 网络 fabric 健康状况和基准测试历史。
- 存储吞吐量、延迟、检查点时间和恢复时间。
- 调度器分配事件和配额拒绝记录。
- 与业务单元关联的计费标签或使用导出数据。
Flatkey 的模型/API 基线在这里很重要。如果某个托管模型 API 能以更清晰的单位成本和更低的运维负担产出同样可接受的结果，那么在计算空闲时间、重试、存储和人工成本后，集群必须超越这一基线才算合理。
安全、隔离与访问设计
GPU 集群通常起初只是工程项目，后来会成为共享基础设施。应将访问设计视为架构的一部分。
定义：
- 认证与身份来源。
- 命名空间、项目或账户隔离。
- SSH 策略（如果有）。
- 容器镜像仓库、签名和扫描。
- 密钥管理。
- 网络出站策略。
- 作业结束后的数据删除与清理。
- 审计日志保留。
- 紧急访问（break-glass）。
- 厂商支持访问和远程协助流程。
对于多租户集群，需要决定是否允许 GPU 共享。整卡分配更简单。MIG、vGPU 或时间切片可以提高利用率，但它们也会改变隔离、遥测、调度和性能预期。
集群规模设计：把架构转化为数字
规模设计应由有用单位驱动：
required_gpu_capacity =
target_work_completed_per_month
/ useful_work_per_gpu_month_after_failures_idle_and_retries然后对其进行压力测试：
| 容量规划问题 | 为何重要 |
|---|---|
| 什么样的利用率才算有价值，而不只是已分配？ | 空闲预留和失败运行并不能帮助产品产出。 |
| 最长可接受的排队时间是多少？ | 即使是便宜的集群，也可能错过上线或训练窗口。 |
| 当某个节点在运行中途故障时会发生什么？ | 重启时间会改变有效吞吐量。 |
| 模型能迁移到另一种 GPU 规格吗？ | 硬件承诺的周期可能长于模型架构本身。 |
| 扩容的前置时间是多少？ | GPU 需求的变化速度可能快于采购速度。 |
| 退出路径是什么？ | 转售、合同终止、数据清理和迁移成本都应纳入决策。 |
对于成本模型，请将本文与您的 GPU 集群 TCO 工作表关联起来：
effective_cluster_unit_cost =
(compute + network + storage + support + operations + idle + retries)
/ accepted workload units分母应与产品一致：已完成的训练任务、已接受的推理 token、生成的媒体作业、搜索索引更新或客户请求。
架构评审清单
在批准 multi node gpu cluster architecture diagram 或供应商报价之前，请使用此清单。
| 领域 | 通过条件 |
|---|---|
| 工作负载简述 | 团队已定义模型、框架、规模形态、数据路径、利用率目标和业务分母。 |
| 计算 | 节点形态包含 GPU 拓扑、CPU/RAM、本地 NVMe、NIC、驱动/CUDA 生命周期以及替换策略。 |
| 网络 | 已记录网络类型、部署位置、超售、故障域，以及 NCCL 或服务基准测试。 |
| 存储 | 已测试数据集暂存、权重缓存、检查点写入/恢复、对象存储、快照和清理。 |
| 调度器 | Kubernetes、Slurm 或混合架构对队列、配额、重试和用户访问有明确的责任归属。 |
| 可观测性 | 作业、GPU、网络、存储和成本均可按团队和工作负载查看。 |
| 安全性 | 身份、密钥、镜像策略、网络策略、审计日志和数据清理均已定义。 |
| 验收测试 | 供应商或内部团队可以运行生产容器、对网络进行基准测试、写入和恢复检查点，并导出日志。 |
| 单位经济性 | 使用相同分母，将集群与云租赁、托管机房、机房自建以及模型/API 基线进行比较。 |
建议一直打开的官方参考资料
在架构评审期间，将官方文档作为来源核对：
| 来源 | 用途 |
|---|---|
| Kubernetes device plugins | GPU 等专用硬件如何暴露给 Kubernetes 调度。 |
| Kubernetes Dynamic Resource Allocation | 专用资源的基于声明的分配模型。 |
| NVIDIA GPU Operator | Kubernetes 的驱动、容器运行时、device plugin、MIG 和 GPU 遥测管理。 |
| NVIDIA NCCL documentation 和 NCCL tests | 分布式通信和实用的 all-reduce 验证。 |
| NVIDIA GPUDirect Storage | 针对大规模数据和检查点流的数据从存储到 GPU 的路径考虑。 |
| Kueue concepts | 面向批处理和 AI/ML 工作负载的 Kubernetes 原生排队概念。 |
| Slurm GRES | Slurm 中的 GPU 资源、计费和作业请求。 |
请将这些内容视为架构参考，而不是对将要运行的具体集群进行验收测试的替代。
何时 GPU 集群不是正确的架构
不要仅仅因为 GPU 小时价格看起来有吸引力，就构建或预留一个集群。当以下情况出现时，直接使用 GPU 集群可能不是正确的架构：
- 产品只需要模型输出。
- 模型组合每周都在变化。
- 团队无法运维驱动、调度器、存储、网络和故障事件。
- 工作负载具有突发性且利用率低。
- 数据移动成本高于计算成本。
- 在有基准证据之前，采购就要求三年期承诺。
- 财务无法将集群支出映射到已接受的产出。
在这些情况下，先比较 云 GPU 租赁价格、无服务器 GPU 或模型 API。正确的架构，是以最低总运营成本交付可靠已接受产出的方案，而不是加速器库存最多的方案。要做供应商层面的市场扫描，请在申请报价之前使用 GPU cloud comparison。
最终结论
一个强大的gpu cluster architecture是一种系统设计：与工作负载匹配的计算节点，经过基准测试验证的网络互连，不会让 GPU 缺乏数据供给的存储，以及能够调度、安全保护、监控并进行成本分摊的控制平面。
对于小规模实验，可以先从租用或托管 API 开始。对于严肃的多节点训练或私有推理，在承诺使用某个提供商、机架或预留资源之前，请先使用上面的图表和检查清单。昂贵的错误不是选择 Kubernetes 而不是 Slurm，或者选择 H100 而不是 H200。真正昂贵的错误是在架构证明它能够把这些 GPU 容量转化为有用工作之前，就先购买 GPU 容量。
