GPU 集群基础设施全景——训练框架之下、硬件之上的那一层 / GPU Cluster Infrastructure Between Training Frameworks and Hardware
📅 创建时间：2026-06-03 🏷️ 标签：#AI-Infra #集群侧 #全景 #调度 #存储 #网络 📚 前置知识：[[../training-infra/00-aiinfra-overview]]（AI Infra 训练侧全景） 📚 相关知识：[[01-gpu-cluster-hardware]]（GPU 集群硬件架构）[[04-job-scheduling]]（作业调度系统）
场景：万卡集群的一个早晨
┌─────────────────────────────────────────────────────────────┐
│ │
│ 早上 8:00，集群调度系统收到 3 个训练作业： │
│ │
│ 作业 A：「要训练 405B 模型，申请 1024 张 H100」 │
│ 作业 B：「要微调 7B 模型，申请 8 张 A100」 │
│ 作业 C：「跑推理服务，申请 4 张 L40S」 │
│ │
│ 集群现状： │
│ ├── 当前运行：作业 D（512 张 H100，预训练） │
│ ├── 空闲节点：2 台 × 8 卡 A100 = 16 卡 │
│ └── 即将释放：今晚 22:00，作业 E 的 64 张 H100 │
│ │
│ 调度系统必须回答： │
│ → 作业 A 能跑吗？不能跑的话要等多久？ │
│ → 作业 B 和 C 如何共享 16 张空闲 A100？ │
│ → 作业 D 的一台机器故障了怎么办？ │
│ → 作业 A 跑完后，Checkpoint 存在哪里？谁来清理磁盘？ │
│ │
│ 这些问题 Training-Infra 不回答——那是 Cluster-Infra 的工作。 │
│ │
└─────────────────────────────────────────────────────────────┘第1节：Cluster-Infra 在整个 AI Infra 中的位置
上下承接的中间层
┌─────────────────────────────────────────────────────────────┐
│ AI Infra 全栈视角 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户层（你的训练代码 / 推理服务） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ PyTorch / DeepSpeed / vLLM / TensorRT-LLM │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↑ ↑ │
│ │ │ │
│ ↓ ↓ │
│ ┌─────────────────┐ ┌─────────────────────────┐ │
│ │ Training-Infra │ │ Cluster-Infra ← 你在这里 │ │
│ │ │ │ │ │
│ │ 分布式并行策略 │ │ GPU 集群资源管理 │ │
│ │ 显存优化 │ │ 作业调度系统 │ │
│ │ NCCL 通信 │ │ 网络 & RDMA │ │
│ │ Checkpoint │ │ 分布式存储 │ │
│ └────────┬────────┘ └───────────┬─────────────┘ │
│ │ │ │
│ └───────────┬───────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Hardware（GPU / CPU / DPU / 网络设备 / 存储设备） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘Cluster-Infra 解决的问题
Training-Infra 解决的是"单作业"内部的问题：如何把一个模型分到多张卡上、如何省显存、如何让 NCCL 通信更高效。
Cluster-Infra 解决的是"多作业集群"的问题：谁先跑、谁等待、故障了怎么办、资源如何最大化利用。
┌─────────────────────────────────────────────────────────────┐
│ Training-Infra vs Cluster-Infra 的边界 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Training-Infra（训练侧 Infra）： │
│ "我有一个 405B 模型，怎么在 1024 张 H100 上跑起来？" │
│ → 关注点：并行策略、显存优化、通信效率 │
│ │
│ Cluster-Infra（集群侧 Infra）： │
│ "我有 10000 张 H100，来自 10 个团队，每天收到 50 个作业， │
│ 怎么分配能让集群利用率最高、同时保证公平？" │
│ → 关注点：调度策略、多租户隔离、故障恢复、运营效率 │
│ │
└─────────────────────────────────────────────────────────────┘第2节：集群基础设施的核心组件
硬件层：从单卡到万卡集群
┌─────────────────────────────────────────────────────────────┐
│ GPU 集群的物理层次结构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 单卡 → 单机（8 卡）→ 单机柜（多机）→ Pod → 集群 │
│ │
│ ┌──────────┐ │
│ │ 单卡 │ NVIDIA H100 SXM5：80GB HBM3 │
│ └─────┬────┘ CUDA Core + Tensor Core + NVLink Ports │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 单机 8卡 │ NVSwitch 全互联：900 GB/s 节点内带宽 │
│ └─────┬────┘ 共享 PCIe / NVLink │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 单机柜 │ InfiniBand HDR 200 Gbps 或 RoCE 400 Gbps │
│ └─────┬────┘ Spine switch 汇聚 │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Pod │ 同一网络域下的一组节点（通常 64-256 节点） │
│ └─────┬────┘ 共享 InfiniBand 交换机 │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ 集群 │ 多 Pod + 中心存储 + 调度系统 │
│ └──────────┘ 万卡级别：跨 Pod 通信 + 统一命名空间 │
│ │
└─────────────────────────────────────────────────────────────┘软件层：集群操作系统的核心组件
┌─────────────────────────────────────────────────────────────┐
│ GPU 集群软件栈 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 作业层 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ PyTorch Distributed / DeepSpeed / Megatron-LM │ │
│ │ （提交给调度系统的"作业"，理解调度系统的资源分配） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 调度层 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Slurm / Kubernetes + Volcano / Yarn │ │
│ │ （作业入口，分配 GPU 资源，决定运行顺序） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 资源管理层 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU 虚拟化 / DCGM 监控 / 作业隔离 │ │
│ │ （让多作业安全共享 GPU 资源） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 网络层 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ NCCL + RDMA（IB/RoCE）+ GPUDirect RDMA │ │
│ │ （卡间高速通信，参考 [[06-network-rdma]]） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 存储层 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 分布式文件系统 / 对象存储 / 数据编排层 │ │
│ │ （训练数据 + Checkpoint 存储，参考 [[08-distributed-storage]]）│ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 硬件层 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ GPU / CPU / DPU / InfiniBand / 以太网 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘第3节：集群管理员 vs ML 工程师的视角差异
两个世界，同一个集群
┌─────────────────────────────────────────────────────────────┐
│ 两种视角看同一个万卡集群 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ML 工程师视角： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ "我的 405B 模型训练需要： │ │
│ │ - 1024 张 H100，跨 16 个 Pod │ │
│ │ - TP=8（同节点内），PP=4，DP=32 │ │
│ │ - 存储：训练数据 10TB，Checkpoint 3TB │ │
│ │ - 网络：需要跨 Pod 通信（IB HDR） │ │
│ │ - 运行时间：预计 7 天 │ │
│ │ → 提交作业，等调度，安排资源" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 集群管理员视角： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ "当前集群状态： │ │
│ │ - 总资源：10000 张 H100 + 2000 张 A100 │ │
│ │ - 利用率：87%（目标 > 85%） │ │
│ │ - 运行中作业：23 个，其中 3 个是抢占式 │ │
│ │ - 作业 A（405B）申请 1024 卡 → 等待中（资源不足） │ │
│ │ - 告警：Pod-7 的 2 台机器 NVLink 降级 │ │
│ │ → 调整调度策略，运维硬件，计费账单" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘关键分歧点
| 维度 | ML 工程师 | 集群管理员 |
|---|---|---|
| 目标 | 作业尽快跑完、MFU 高 | 集群整体利用率高、公平分配 |
| 关注时间 | 单个作业的几小时~几天 | 全天 24 小时运营 |
| 故障处理 | 作业失败要重跑 | 节点故障要隔离、维修 |
| 资源需求 | 希望资源越多越好 | 必须在有限资源内做最优分配 |
| 通信需求 | 需要 NCCL 拓扑感知 | 需要知道哪些节点之间网络快 |
第4节：为什么需要 Cluster-Infra
一个 GPU 集群的规模问题
┌─────────────────────────────────────────────────────────────┐
│ 不同规模集群的挑战对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ │ 规模 │ 单卡 │ 单机 │ Pod级 │ 万卡级 │
│ ├──────────────┼────────┼────────┼─────────┼─────────────┤
│ │ 节点数 │ 1 │ 1 │ 64~256 │ 1000+ │
│ │ GPU 数 │ 1 │ 8 │ 512~2K │ 8000+ │
│ │ 存储 │ 本地 │ 本地 │ 共享网络│ 分布式存储 │
│ │ 调度复杂度 │ 无 │ 无 │ 中等 │ 极高 │
│ │ 故障概率(天) │ 低 │ 低 │ 中等 │ 高 │
│ │ 运维关注点 │ 稳定性 │ 散热 │ 网络拓扑│ 调度+弹性 │
│ │
│ 万卡集群的特点： │
│ → 每天都有 GPU 故障（MTBF ~ 100,000 小时 ÷ 10000 ≈ 10 小时）│
│ → 故障不是异常，是常态 │
│ → 必须从设计层面就考虑容错 │
│ │
└─────────────────────────────────────────────────────────────┘三大挑战：集群独有的问题
┌─────────────────────────────────────────────────────────────┐
│ Cluster-Infra 独有的三大挑战 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 资源碎片化（Resource Fragmentation） │
│ → 作业 A 要 64 卡，当前最大连续空闲块只有 32 卡 │
│ → 明明总体空闲率 30%，却跑不了任何一个 64 卡作业 │
│ → 解法：调度算法优化 + 资源预留策略 │
│ │
│ 2. 通信拓扑敏感（Topology Sensitivity） │
│ → TP=8 要求 8 张卡全在同节点（NVLink 900 GB/s） │
│ → DP 跨节点可以用 IB（200 Gbps） │
│ → 调度器必须理解拓扑，不是随机分配 GPU │
│ │
│ 3. 多租户公平性（Multi-Tenant Fairness） │
│ → 10 个团队共享集群，每个团队都觉得自己优先级最高 │
│ → 大作业吃资源但排队久，小作业频繁但总占用少 │
│ → 解法：分层队列 + 抢占策略 + 配额机制 │
│ │
└─────────────────────────────────────────────────────────────┘第5节：Cluster-Infra 系列章节导航
章节依赖关系
┌─────────────────────────────────────────────────────────────┐
│ Cluster-Infra 章节依赖图 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 第0章（本章）：集群全景 ── 整个系列的"总地图" │
│ │ │
│ ├──► 第1章：GPU 集群硬件架构 │
│ │ │ 理解物理拓扑是调度和通信的基础 │
│ │ └──► 第2章：异构硬件生态 │
│ │ │
│ ├──► 第3章：GPU 虚拟化与资源隔离 │
│ │ │ 多作业共享 GPU 的前提 │
│ │ │ │
│ │ ├──► 第4章：作业调度系统 │
│ │ │ │ K8s/Slurm 是集群的入口 │
│ │ │ │ │
│ │ │ └──► 第5章：多作业与多租户管理 │
│ │ │ │
│ ├──► 第6章：网络架构与 RDMA │
│ │ │ 高速网络是集群通信的基础 │
│ │ │ │
│ │ └──► 第7章：NCCL 集群组网 │
│ │ │ 大规模 NCCL 调优是集群通信的核心 │
│ │ │ │
│ └──► 第8章：分布式存储 │
│ │ 数据和 Checkpoint 的存储基础 │
│ │ │
│ └──► 第9章：集群运营与故障处理 │
│ │ 监控 + 故障 + 升级 = 完整运营闭环 │
│ │ │
│ （依赖所有前置章节） │
│ │
└─────────────────────────────────────────────────────────────┘与 Training-Infra 的衔接
┌─────────────────────────────────────────────────────────────┐
│ Cluster-Infra 如何引用 Training-Infra │
├─────────────────────────────────────────────────────────────┤
│ │
│ Training-Infra 告诉你"作业内部"发生了什么： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 02-distributed-training：TP/PP/DP 在单作业内怎么切分 │ │
│ │ 04-mixed-precision：NCCL AllReduce 的原理 │ │
│ │ 01-gpu-hardware：GPU SM、Tensor Core、NVLink 基础 │ │
│ │ 09-training-engineering：Checkpoint 和故障恢复 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Cluster-Infra 告诉你"集群层面"如何支撑这些： │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 04-job-scheduling：调度系统如何分配 GPU 给这些作业 │ │
│ │ 07-nccl-cluster-networking：跨节点 NCCL 拓扑感知 │ │
│ │ 01-gpu-cluster-hardware：GPU 集群的物理拓扑 │ │
│ │ 09-cluster-operations：集群级故障处理 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 一个完整的训练请求链路： │
│ 用户提交作业 → 调度系统分配 GPU → 作业启动 │
│ ↓ │
│ NCCL 探测拓扑 → 根据拓扑选择并行策略 │
│ ↓ │
│ 训练过程中 → 监控 GPU 利用率和网络带宽 │
│ ↓ │
│ 定期 Checkpoint → 写入分布式存储 │
│ ↓ │
│ 故障检测 → 自动恢复或重新调度 │
│ │
└─────────────────────────────────────────────────────────────┘各章节主题
| 章节 | 主题 | 核心问题 |
|---|---|---|
| [[01-gpu-cluster-hardware]] | GPU 集群硬件架构 | 节点内 NVLink vs 跨节点 IB/RoCE，集群拓扑设计 |
| [[02-heterogeneous-hardware]] | 异构硬件生态 | CPU/DPU/NPU 在集群中的角色 |
| [[03-gpu-virtualization]] | GPU 虚拟化与隔离 | MPS/MIG/vGPU，多作业共享 GPU |
| [[04-job-scheduling]] | 作业调度系统 | Slurm vs K8s，Gang Scheduling |
| [[05-multi-tenant-management]] | 多作业与多租户 | 资源配额、抢占、计费 |
| [[06-network-rdma]] | 网络架构与 RDMA | RoCE v2 / PFC / DCQCN / GPUDirect RDMA |
| [[07-nccl-cluster-networking]] | NCCL 集群组网 | 拓扑感知、Ring/Tree/CollNet、大规模调优 |
| [[08-distributed-storage]] | 分布式存储 | Lustre/GPFS/Alluxio、IO 模式分析 |
| [[09-cluster-operations]] | 集群运营 | DCGM/Prometheus 监控、故障处理、滚动升级 |
与 Hardware 文件夹的关系
本系列与 [[/02-systems-and-performance/02-computer-architecture-and-hardware/00-hardware-overview]]（Hardware 目录）有一定内容重叠，以下是各章与 Hardware 目录的对应关系，供已学完 Hardware 的读者参考取舍：
┌─────────────────────────────────────────────────────────────┐
│ Cluster-Infra 与 Hardware 目录的内容重叠映射 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Cluster-Infra 第 1 章：GPU 集群硬件架构 │
│ ↔ Hardware 第 3 章：GPU 架构 │
│ 重合内容： │
│ • NVLink / NVSwitch 拓扑与带宽 │
│ • HBM 显存容量与带宽 │
│ • InfiniBand / RoCE 基础概念 │
│ Cluster-Infra 独有： │
│ • Pod / 集群级物理拓扑（rack → pod → cluster） │
│ • 调度拓扑感知的实践含义 │
│ │
│ Cluster-Infra 第 2 章：异构硬件生态 │
│ ↔ Hardware 第 9 章：异构计算、第 12 章：NPU 生态 │
│ 重合内容： │
│ • CPU-GPU 协同（Pinned Memory / CUDA Streams） │
│ • NPU 概览（Ascend / TPU / AMD Instinct） │
│ Cluster-Infra 独有： │
│ • DPU（BlueField）的网络卸载与集群价值 │
│ • Grace-Hopper Superchip 的 NVLink-C2C 互联 │
│ • 异构集群的统一调度挑战（HCCL ≠ NCCL ≠ RCCL） │
│ │
│ Cluster-Infra 第 7 章：NCCL 集群组网 │
│ ↔ Hardware 第 8 章：MPI 集群 HPC 通信 │
│ 重合内容： │
│ • Ring AllReduce / Tree AllReduce 算法 │
│ • NCCL 集合通信原语（all_reduce / all_gather） │
│ • NVLink vs InfiniBand 带宽对比 │
│ Cluster-Infra 独有： │
│ • CollNet 算法与大规模跨 Pod 通信调优 │
│ • NCCL 拓扑感知配置（NCCL_TOPO_DUMP / 拓扑 XML） │
│ • NVLS（NVLink Sharp）硬件加速 │
│ • NCCL Test 基准测试与故障诊断流程 │
│ │
│ Cluster-Infra 第 9 章：集群运营与故障处理 │
│ ↔ Hardware 第 11 章：性能分析工具 │
│ 重合内容： │
│ • nvidia-smi / DCGM 指标（利用率 / 显存 / ECC） │
│ Cluster-Infra 独有： │
│ • Prometheus + Grafana 监控栈与告警配置 │
│ • Kubernetes / Slurm 节点隔离与故障处理 │
│ • 滚动升级策略与容量规划 │
│ │
│ 不重合的章节（Cluster-Infra 独有内容）： │
│ • 第 3 章：GPU 虚拟化（MPS / MIG / vGPU） │
│ • 第 4 章：作业调度系统（Slurm / Kubernetes） │
│ • 第 5 章：多作业与多租户管理 │
│ • 第 6 章：网络架构与 RDMA（PFC / DCQCN / GPUDirect） │
│ • 第 8 章：分布式存储（Lustre / Alluxio / JuiceFS） │
│ │
└─────────────────────────────────────────────────────────────┘两个系列的核心定位差异
┌─────────────────────────────────────────────────────────────┐
│ Hardware vs Cluster-Infra 的定位边界 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Hardware 目录： │
│ "从算法/性能视角看硬件" │
│ → 核心问题：GPU 为什么这么快？CUDA 怎么写？NCCL 怎么算？│
│ → 视角：让单个 GPU 跑得更快 │
│ │
│ Cluster-Infra 目录： │
│ "从系统管理视角看硬件" │
│ → 核心问题：集群怎么建？怎么调度作业？怎么保证多租户？ │
│ → 视角：让很多 GPU 组成的集群被所有人高效使用 │
│ │
│ 一个比喻： │
│ Hardware 告诉你每辆车的发动机怎么工作， │
│ Cluster-Infra 告诉你怎么管理一个城市的交通系统。 │
│ 理解发动机有助于理解交通系统，但两者解决的问题截然不同。 │
│ │
└─────────────────────────────────────────────────────────────┘
---
## 升华：集群的哲学┌─────────────────────────────────────────────────────────────┐ │ Cluster-Infra 的核心工程哲学 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. 共享即妥协：多租户共享集群 = 每个人都要让出一部分效率 │ │ → 没有完美的调度策略，只有适合的 trade-off │ │ → 公平 vs 效率，这是永恒的张力 │ │ │ │ 2. 故障是常态，不是异常： │ │ → 万卡集群每天都在发生故障 │ │ → 好的集群设计让故障影响最小化 │ │ → Checkpoint 策略就是集群的"存档点" │ │ │ │ 3. 物理约束是不可逾越的边界： │ │ → NVLink 带宽是 TP 的硬约束 │ │ → IB 带宽是跨节点通信的硬约束 │ │ → 调度器不理解拓扑，就会在错误的地方分配资源 │ │ │ │ 4. 监控是一切的基础： │ │ → 没有 DCGM/Prometheus 的集群 = 盲人开飞机 │ │ → 告警阈值配置不当 = 要么漏报要么淹没 │ │ │ │ 一句话总结： │ │ Cluster-Infra 是把"很多 GPU"变成"一个好用系统"的工程。 │ │ 它不追求单作业最优，而是追求集群整体的价值最大化。 │ │ │ └─────────────────────────────────────────────────────────────┘
---
## "AI 可查 vs 必须理解"清单AI 可查： ✅ Kubernetes/Slurm 的具体配置参数 ✅ DCGM/Prometheus 的具体部署方式 ✅ 不同型号 InfiniBand 交换机的规格对比 ✅ 特定 GPU 集群的拓扑图设计
必须理解： 🔴 Cluster-Infra 在整个 AI Infra 全栈中的位置（上下承接关系） 🔴 集群管理员视角和 ML 工程师视角的核心差异 🔴 万卡集群的三大独有挑战：资源碎片化、拓扑敏感性、多租户公平性 🔴 章节之间的依赖关系（为什么调度要学在网络前面） 🔴 为什么"调度不理解拓扑"是严重的设计缺陷
---
**学习状态**：🟡 开始学习