GPU集群基础：GPU计算特点、集群拓扑、对存储的需求

在讨论分布式存储架构之前，必须先理解GPU集群本身的工作方式。GPU不是通用CPU的简单加速卡，它的计算模型、数据流模式以及集群互联方式，决定了存储系统必须满足何种性能指标。本章从GPU计算的核心特征出发，逐步展开集群拓扑结构，并推导出存储需求的具体约束。

2.1 GPU计算特点：吞吐优先于延迟

GPU最初为图形渲染设计，其架构本质是大量简单计算核心并行执行相同指令。现代通用GPU（如NVIDIA A100/H100、AMD MI250X）拥有数千个CUDA核心或流处理器，但每个核心的时钟频率远低于CPU。这种设计带来一个关键特性：GPU追求吞吐量（Throughput），而非单任务延迟（Latency）。

从存储视角看，GPU计算有三个显著特征：

• 数据并行性：同一操作应用于海量数据元素。例如矩阵乘法中，每个输出元素的计算相互独立，可同时执行。这意味着存储系统需要支持高并发、大批量的数据读取，而非低延迟的单次小请求。
• 计算密集与访存密集并存：GPU计算单元速度极快，但片上缓存（L2）和显存（HBM）容量有限。当数据集超过显存容量时，数据必须从外部存储（NVMe SSD或分布式存储）持续流入，形成“流式”访问模式。
• 同步屏障（Barrier）频繁：GPU内核（Kernel）执行过程中，多个线程块（Thread Block）需要在特定点同步。若某个线程块等待数据到达，整个内核的执行时间将被拉长。因此，存储延迟的抖动会直接转化为计算效率的损失。

2.2 集群拓扑：从单机到超节点

GPU集群的物理拓扑直接决定了数据流动的路径和瓶颈所在。当前主流拓扑分为三个层级：

2.2.1 单节点内部拓扑

一台GPU服务器通常包含8张GPU卡，通过PCIe Gen5或NVLink/NVSwitch互联。NVLink提供高达900GB/s的双向带宽（H100），远高于PCIe的128GB/s。这种高速互联使得同一节点内的GPU可以共享显存数据，形成显存池化效应。

节点内部存储层次如下：

GPU显存（HBM3，约80GB/卡）
  ↓ NVLink（900GB/s）
GPU L2缓存（50MB/卡）
  ↓ PCIe/NVLink-C2C
CPU内存（DDR5，1-2TB/节点）
  ↓ PCIe Gen5（128GB/s）
本地NVMe SSD（3-8TB，RAID0/1）
  ↓ 网络（25/100/200GbE或IB）
分布式存储集群

这一层次结构决定了：热数据应尽量驻留在显存或本地SSD，冷数据才需要访问分布式存储。但训练数据集往往远超本地容量，因此分布式存储成为必然选择。

2.2.2 跨节点拓扑：Fat-Tree与Dragonfly

大规模GPU集群（数百至数千卡）采用两层或三层网络拓扑。最常见的是Fat-Tree（胖树）结构：

• 叶层（Leaf）：每台GPU服务器连接2个叶交换机（冗余），带宽通常为2×200GbE或2×400GbE。
• 脊层（Spine）：叶交换机上行至脊交换机，形成无阻塞全带宽互联。例如，128台服务器（1024卡）需要64个叶交换机和32个脊交换机。

另一种新兴拓扑是Dragonfly（蜻蜓），用于超大规模集群（万卡级）。它将节点分组，组内全互联，组间通过少量全局链路连接，牺牲部分带宽换取更低延迟和成本。

2.2.3 超节点与存储加速卡

NVIDIA DGX SuperPOD、Google TPU Pod等超节点架构，将数百张GPU通过专用互联（NVLink Switch、OCS光交换）组成单一逻辑计算域。此时，存储系统必须支持并行文件系统（如Lustre、WEKA），以提供聚合带宽。例如，一个包含512张H100的SuperPOD，其存储聚合带宽需求可达2-4TB/s。

2.3 对存储的需求：带宽、IOPS与一致性

综合上述计算特点和拓扑结构，GPU集群对存储的需求可归纳为三个维度：

需求维度	典型指标	原因
顺序读带宽	每GPU卡≥2GB/s，聚合≥100GB/s	训练数据集（图像、文本）以顺序方式读取，且需多卡并行加载
随机写IOPS	≥50K IOPS（每节点）	检查点（Checkpoint）写入、日志记录、中间结果落盘
元数据操作	≥10K ops/s	训练过程中频繁打开/关闭文件、创建新版本数据集
一致性语义	强一致性或租约（Lease）	多节点同时读写同一数据集，需避免脏读

特别需要关注检查点（Checkpoint）场景。大模型训练每10-30分钟保存一次模型状态，数据量可达数十GB至数百GB。若存储写入带宽不足，检查点保存时间会超过训练迭代间隔，导致GPU空转等待。例如，一个1750亿参数的GPT-3模型，检查点大小约3.5TB（含优化器状态），在100GB/s聚合带宽下需要35秒，尚可接受；但若带宽降至20GB/s，则需175秒，严重拖慢训练进度。

2.4 典型场景：数据加载流水线

以PyTorch分布式训练为例，数据从存储到GPU的完整路径如下：

1. 存储集群（分布式文件系统，如Lustre）
   ↓ 网络（RDMA/RoCE）
2. 客户端节点（存储客户端，Page Cache）
   ↓ 本地PCIe
3. CPU内存（预取缓冲区）
   ↓ 数据加载器（DataLoader，多进程）
4. GPU显存（训练批次）
   ↓ 计算
5. 检查点写入（反向路径）

实践中，存储预取（Prefetch）是隐藏延迟的关键。数据加载器使用独立进程提前读取下一批数据，使GPU计算与数据加载重叠。这要求存储系统能持续提供稳定带宽，而非突发高带宽后回落。

2.5 误区与复盘：存储规划中的典型错误

在多个实际GPU集群部署案例中，以下错误反复出现：

• 误区一：存储容量规划不足。仅按数据集大小规划，忽略了检查点、日志、临时文件、多版本数据集。实际需求通常是数据集大小的3-5倍。
• 误区二：网络带宽与存储带宽不匹配。例如，配置了400GbE网络，但存储节点仅提供10GbE出口，导致网络空闲而存储成为瓶颈。
• 误区三：忽略元数据性能。训练框架会频繁执行stat、open、close操作。若元数据服务器（MDS）性能不足，即使数据带宽充裕，整体吞吐也会受限。
• 误区四：使用NFS等通用协议。NFS的锁机制和协议开销在高并发下会导致严重性能下降。GPU集群应使用并行文件系统（Lustre、WEKA、GPFS）或对象存储（S3兼容）配合高性能客户端。

一个值得借鉴的复盘案例：某互联网公司部署128台8卡A100集群，初期使用NFS存储，训练吞吐仅达到理论值的30%。排查发现，NFS的元数据操作延迟高达50ms，且单客户端并发数受限。迁移至Lustre并行文件系统后，聚合带宽从12GB/s提升至85GB/s，训练吞吐恢复至理论值的85%。