AI 训练存储选型：GPFS、Alluxio 与 JuiceFS 的架构差异和适用边界

AI 存储选型不能只比较顺序吞吐量。数据加载、检查点保存、模型分发和特征读取会产生完全不同的 I/O 模式，而 GPFS、Alluxio 与 JuiceFS 解决问题的出发点也并不相同：GPFS 更接近高性能并行文件系统，Alluxio 侧重数据编排与缓存加速，JuiceFS 则以元数据服务和对象存储组合出分布式文件系统。

因此，这三者不是简单的同类替换关系。真正需要回答的是：数据放在哪里、计算节点如何访问、热数据是否重复读取，以及团队愿意承担多少基础设施和运维成本。

先识别 AI 工作负载的 I/O 形状

一套 AI 平台通常同时存在以下访问模式：

• 训练集读取：大量并发读取，可能是少量大文件，也可能是数百万个图片、音频或分片文件。前者更看重持续带宽，后者更容易受元数据延迟和小文件操作影响。
• 多轮训练与超参数搜索：相同数据被不同任务反复读取，本地或节点级缓存通常能显著减少远端流量。
• 检查点写入：周期性写入数 GB 到数百 GB，要求稳定带宽、原子发布和故障恢复能力。训练节点同时保存时还会形成突发流量。
• 模型分发与推理启动：读取频率不一定高，但启动延迟直接影响扩缩容速度。热点模型适合缓存，长尾模型更适合放在低成本持久存储中。
• 数据预处理：会创建、重命名和删除大量文件，对 POSIX 语义、目录遍历和元数据服务形成压力。

选型前至少应记录四个指标：文件数量及大小分布、峰值并发客户端数、热数据集大小、读写比例。只拿单客户端的大文件顺序读结果做决策，往往会掩盖生产环境中的真正瓶颈。

三种架构分别在解决什么问题

GPFS：把共享高性能文件系统作为基础设施

GPFS 适合需要多个计算节点并行访问同一命名空间，并且对文件系统语义、稳定带宽和集中管理有较高要求的环境。它更像一套长期运行的核心存储基础设施，而不是为单个训练任务临时增加的缓存。

这种方案的成本不能只看磁盘容量。还要计算存储服务器、网络、许可、扩容方式、故障域设计和专业运维投入。如果组织已经拥有成熟的 HPC 平台，这些成本可能已经被基础设施团队吸收；如果从零建设，则需要把部署周期和人员能力纳入决策。

Alluxio：用缓存缩短计算与数据之间的距离

Alluxio 的价值通常出现在后端数据较远、读取重复度较高的场景。例如，多组训练任务反复扫描对象存储中的同一数据集时，可以利用靠近计算节点的缓存降低后端请求和网络开销。

它并不会自动消除所有存储问题。冷启动阶段仍可能受后端带宽限制；如果工作集远大于缓存，或者任务几乎只读取一次，缓存命中率不足会削弱收益。设计时应明确后端存储是真实数据源，并为缓存预热、淘汰、容量隔离和节点故障制定策略。

JuiceFS：用对象存储承载容量，用元数据服务提供文件视图

JuiceFS 适合希望保留文件系统接口，同时利用对象存储容量、耐久性和弹性能力的团队。计算节点不必与固定的存储设备同步扩容，在 Kubernetes 和弹性计算环境中尤其容易形成清晰的资源边界。

这类架构也意味着性能路径被拆成多个部分。打开文件、列目录和创建文件主要考验元数据服务；读取文件内容会经过客户端缓存、网络和对象存储；一致性与可用性还依赖元数据引擎的部署质量。对象存储单价较低，并不代表端到端成本必然最低，还需计算 API 请求、跨区域流量、缓存盘和元数据服务费用。

用场景而不是产品名称做选择

可以按以下方式缩小范围：

• 大型 HPC 或稳定的本地 GPU 集群：已有高速网络和专业存储团队，任务要求稳定并行吞吐与完整文件语义时，优先评估 GPFS。
• 对象存储上的数据被频繁重复训练：后端读取成本或延迟明显，并且热数据集能够被缓存覆盖时，重点验证 Alluxio 的命中率和冷启动时间。
• 云原生训练平台或弹性 GPU 集群：希望存储与计算独立扩缩容，同时让旧程序继续通过文件接口访问数据时，可以评估 JuiceFS。
• 混合方案：Alluxio 可以作为加速层放在持久存储之前。此时必须先定义数据权威副本和故障回退路径，避免把缓存误当成备份。

没有任何一个选项能同时在最低成本、最强语义、最高冷读性能和最少运维上占优。比如缓存提高热读性能，却增加容量管理；对象存储降低容量扩展压力，却可能引入请求延迟；高性能并行文件系统提供稳定能力，但基础设施投入更重。

在真实挂载点上做一轮可重复测试

下面的脚本可以在三个已经挂载好的目录中运行同一组 fio 测试。它会在每个目录创建一个临时测试文件并在结束时删除，因此不要把目标指向空间紧张的生产目录。运行前安装 fio，并按实际数据规模调整 FILE_SIZE；默认的 4 GiB 只适合验证流程，不能代表生产结论。

#!/usr/bin/env bash
set -euo pipefail

if [[ "$#" -lt 1 ]]; then
  echo "Usage: $0 /mnt/gpfs [/mnt/alluxio /mnt/juicefs]" >&2
  exit 1
fi

FILE_SIZE="${FILE_SIZE:-4G}"
RUNTIME="${RUNTIME:-60}"
RESULT_DIR="${RESULT_DIR:-./fio-results}"
mkdir -p "$RESULT_DIR"

for mount_dir in "$@"; do
  if [[ ! -d "$mount_dir" || ! -w "$mount_dir" ]]; then
    echo "Skip unavailable directory: $mount_dir" >&2
    continue
  fi

  name="$(basename "$mount_dir")"
  test_file="$mount_dir/.ai-storage-benchmark-${USER}"

  fio --name=prepare \
      --filename="$test_file" \
      --size="$FILE_SIZE" \
      --rw=write \
      --bs=1M \
      --ioengine=libaio \
      --direct=1 \
      --iodepth=16 \
      --end_fsync=1

  fio --name=sequential-read \
      --filename="$test_file" \
      --size="$FILE_SIZE" \
      --rw=read \
      --bs=1M \
      --ioengine=libaio \
      --direct=1 \
      --iodepth=32 \
      --time_based=1 \
      --runtime="$RUNTIME" \
      --group_reporting=1 \
      --output-format=json \
      --output="$RESULT_DIR/${name}-sequential-read.json"

  fio --name=random-read \
      --filename="$test_file" \
      --size="$FILE_SIZE" \
      --rw=randread \
      --bs=128K \
      --ioengine=libaio \
      --direct=1 \
      --iodepth=32 \
      --time_based=1 \
      --runtime="$RUNTIME" \
      --group_reporting=1 \
      --output-format=json \
      --output="$RESULT_DIR/${name}-random-read.json"

  rm -f "$test_file"
done

运行示例：

chmod +x benchmark-storage.sh
FILE_SIZE=20G RUNTIME=180 ./benchmark-storage.sh \
  /mnt/gpfs /mnt/alluxio /mnt/juicefs

这项测试只能测量受控块 I/O。正式评估还应增加三个步骤：使用生产文件大小分布进行数据加载测试；从多台训练节点同时发压；分别记录冷缓存和热缓存结果。对于小文件数据集，还要测量目录遍历、stat、文件打开和关闭延迟，而不是仅看 fio 带宽。

落地前的检查清单

在做最终决定前，建议把候选方案放入一次包含真实模型和数据加载器的试运行，并回答以下问题：

• 冷启动和缓存命中后的首个 batch 延迟分别是多少？
• 多节点并发时，瓶颈位于客户端、网络、元数据服务还是后端存储？
• 检查点是否能原子发布，失败任务会不会留下不可识别的半成品？
• 单节点、缓存节点、元数据服务或网络链路故障时，任务如何恢复？
• 三年总成本是否包含许可、对象存储请求、流量、缓存盘和运维人力？
• 现有训练代码依赖哪些 POSIX 行为，候选方案是否经过实际验证？

如果核心需求是稳定的共享并行文件系统，应从 GPFS 的基础设施能力出发评估；如果主要矛盾是远端数据的重复读取，应先计算 Alluxio 可实现的缓存命中率；如果目标是让文件接口与对象存储、弹性计算结合，则重点验证 JuiceFS 的元数据性能和端到端延迟。最终选择应由真实数据加载链路和故障演练决定，而不是由单项峰值带宽决定。