GPU 在孟买，训练数据在爱荷华？跨区域读取在每次 epoch 都会产生高昂开销。

我们在 Alluxio（位于存储桶前）和 Anyscale 上的 Ray Data 中部署了 NVMe 缓存：1TB 热读取速度提升了 20 倍。

https://t.co/FqomwsoqpS https://t.co/e6Yfi9124s

使用 Alluxio 与 Ray Data，训练数据读取速度提升 20 倍：跨区域基准测试 | Anyscale

来源：https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale 当训练数据位于一个云区域而你的 GPU 位于另一个区域时，每次 epoch 的每次读取都需要支付跨区域开销。我们在跨区域 GCS 存储桶前部署了 Alluxio (https://www.alluxio.io/)——一个与 Ray on Anyscale (https://www.anyscale.com/platform) 协同工作的计算端 NVMe 层，充当分布式缓存——并运行了一个 1TB 的 Ray Data 基准测试：热缓存读取时间从 4,241 秒降至 208 秒——实现了 20 倍加速。

ALLUXIO – GCS - 1TB 基准测试结果摘要

ALLUXIO -- GCS - 1TB 基准测试结果摘要

链接问题https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#the-problem

跨区域读取是分布式 AI 训练中 GPU 数据管道 最常见、最痛苦且最昂贵的瓶颈之一。在我们的基准测试设置中，Ray 集群运行在 asia-south1（孟买），而训练数据位于 us-central1 的 GCS 存储桶中。每次读取都要跨越海洋。

使用 Ray Data (https://docs.anyscale.com/runtime/data)——一个用于分布式多模态数据处理的开放源代码库——直接从 GCS 读取 1TB 的 Parquet 文件，单次遍历耗时超过 4,200 秒。对于需要在多个 epoch 中重复读取同一数据集的训练任务，这种延迟会迅速累积。GPU 处于空闲状态，被数据管道阻塞。标准的 Ray Data 调用看起来很简单：

ds = ray.data.read_parquet("gs://us-central1-bucket/dataset/")
ds.map_batches(train_step).count()
# 每次 epoch 耗时 4,294 秒。

问题不在于 Ray——而在于数据距离 10,000 英里远，并且每次你都要重新获取它。

链接解决方案https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#the-solution

Anyscale 是一个多云 AI 平台，使团队能够使用 Ray 构建和扩展完整的、GPU 加速的 AI 生命周期。Anyscale 提供 Python API，抽象了部署 Kubernetes 集群或管理在 K8s 集群上运行的 Ray 分布式计算的过程。为了支持多云体验，Anyscale 充当一个统一面板，连接你的 AWS 账户、Google Cloud 项目或另一个云中的 Kubernetes 集群中的云资源。除了统一管理体验外，你还可以配置多个云资源配置，以便当主配置中的资源不可用于你的 Anyscale 集群时，Anyscale 任务可以回退到使用另一个区域或云提供商的资源。

Alluxio 是一个与 Ray 集群共置的计算端、基于 NVMe 的分布式缓存。在首次读取时，数据从底层存储中拉取并写入本地 NVMe SSD。后续每次读取——每次 epoch、每次试验、每次重复遍历——都完全从缓存提供。无需跨区域跳转。

Alluxio 是存储无关的：同样的缓存层适用于 Amazon S3、Google Cloud Storage、Azure Blob Storage、任何兼容 S3 的对象存储，以及 POSIX 兼容的文件系统，包括本地 NAS 和 HDFS。

多云架构图，显示 Anyscale 管理跨 AWS、GCP 和 Azure 的 Ray + Alluxio 集群。每个区域使用本地 NVMe 缓存，并通过统一的 Alluxio 命名空间连接到集中式对象存储（S3、GCS 或 Azure Blob）。

多云架构图，显示 Anyscale 管理跨 AWS、GCP 和 Azure 的 Ray + Alluxio 集群。每个区域使用本地 NVMe 缓存，并通过统一的 Alluxio 命名空间连接到集中式对象存储（S3、GCS 或 Azure Blob）。 我们使用 Anyscale 的 Kubernetes operator 部署了 Anyscale Kubernetes 云资源，同时使用 Alluxio 的 Kubernetes operator，并挂载了文件存储。我们利用 Alluxio 进行数据访问。

在此基准测试中，底层存储桶恰好位于 GCS us-central1——但无论数据位于何处，其架构、访问模式和性能特征都是相同的。假设你的训练数据在 S3 而 GPU 在其他地方，或者你正在从本地存储拉取数据到云端 Ray 集群，同样的方法都适用。这就是为何使用 Alluxio 缓存 Ray Data 在多云环境中是实用的——而不仅仅针对单一云进行了优化。

[ Ray 集群 · asia-south1 (孟买) ]
5 × n2-standard-8 · ray.data.read_parquet()
        ↕ S3 API (端口 29998) 或 FUSE 挂载 ↕
[ Alluxio 工作节点 · NVMe 缓存 ]
3 × n2-standard-16 · 每个节点 8× NVMe SSD · 总共 6TB 页面存储
        ↕ 仅首次读取 ↕
[ GCS · us-central1 ]
跨区域对象存储 · 缓存预热后不再访问

Ray Data 通过两种访问模式连接到 Alluxio：兼容 S3 的 API（端口 29998，使用 s3fs）或 FUSE 挂载（本地 POSIX 路径 /mnt/alluxio）。两者对训练代码完全透明——无需更改模型、管道或 Ray 作业定义。

对于迭代训练工作负载——多个 epoch、Ray Tune 超参数搜索、重复数据集遍历——其经济效益非常可观：精确支付一次跨区域网络成本，然后后续每次迭代都以本地 NVMe 速度读取。

链接我们踩过的陷阱https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#the-traps-we-fell-into

达到 20 倍并非一蹴而就。我们运行了五次基准测试脚本，并遇到了两个与 Ray 用户直接相关的重大陷阱。我们在此记录，因为它们很容易踩到——而且其中一个曾短暂产生了一个我们差点就公布的数据。

链接陷阱 #1 —— .materialize() 在大规模下严重影响了我们的数据https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#trap-#1-%E2%80%94-

我们最初的运行使用了 ray.data.read_parquet(paths).materialize()——这是强制完全加载数据的自然选择。在 1.2GB 时，我们得到了令人兴奋的 18 倍热缓存加速。但随着规模扩大，数字开始崩坏：

数据集

配置

Ray 工作节点

热加速比

1.2 GB (1 个文件)

1 个 Alluxio 工作节点，RAM 页面存储

1

18x ✓

20 GB (17 个文件)

1 个 Alluxio 工作节点，RAM 页面存储

5

2x

120 GB (153 个文件)

1 个 Alluxio 工作节点，RAM 页面存储

5

0.41x ⚠ 变慢

500 GB (12 个目录)

3 个工作节点，每个 2Ti NVMe

18

1.63x

0.41x —— 我们让情况变得更糟了在 120GB 时，Alluxio 比直接读取 GCS 还要慢。罪魁祸首：.materialize() 将所有反序列化后的数据写入 Ray 的对象存储。在大规模下，这会触发大量的磁盘溢出，完全掩盖了本地 NVMe 缓存的优势。你实际上测量的是溢出吞吐量，而非数据访问速度。

修复方法：改用 .map_batches(lambda x: x).count()。这会强制进行完整的行级反序列化——每个字节都被读取和解码——但结果被丢弃，而不是写入 Ray 对象存储。没有溢出，没有隐藏的瓶颈。

# ❌ 之前——大规模下触发磁盘溢出，掩盖缓存优势
ray.data.read_parquet(paths).materialize()

# ✓ 之后——完整数据读取，无对象存储压力
ray.data.read_parquet(paths, filesystem=fs).map_batches(lambda x: x).count()

这是 Ray 特定的一个陷阱。当你希望数据在对象存储中供下游任务使用时，.materialize() 是正确的选择。但如果你在基准测试数据加载吞吐量，它会引入一个写入瓶颈，使任何缓存层看起来都比实际更差。切换后，我们在相同的硬件上立即看到了 3 倍的改进。

链接完整脚本演变https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#full-script-evolution

v1 / v2 —— materialize() —— 在小规模下有效，在大规模下崩溃使用 .materialize()。在 1.2GB 时产生了最初的 18 倍。在 120GB 和 5 个 Ray 工作节点时，导致对象存储溢出，将结果逆转为 0.41 倍。v2 扩展了 v1，通过环境变量支持多数据集配置。

v3 —— map_batches().count() —— 首个有效的大规模版本，使用 S3 API通过 .map_batches(lambda x: x).count() 强制进行完整的行反序列化，而不写入对象存储。消除了两个陷阱。仅支持 S3 API 访问路径。

v4 —— FUSE + S3 API 可切换 —— 最终版本，所有头条结果添加 ACCESS_MODE 环境变量，可在不更改代码的情况下在 S3 API 和 FUSE 之间切换。所有 1TB 结果，包括头条的 20.35 倍热缓存加速，都是在 FUSE 模式下使用此版本生成的。

链接结果https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#the-results

使用 v4 并设置 ACCESS_MODE=fuse，我们运行了一个干净的 3 次 1TB 基准测试：首次冷读取，后续热读取。数据集：来自 GCS us-central1 的 FineWeb-Edu Parquet；计算在 asia-south1。

链接1TB FUSE 基准测试——最终数据https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#1tb-fuse-benchmark-%E2%80%94-final-numbers

运行

GCS 直接

Alluxio (FUSE)

加速比

1 — 冷缓存

4,294s

1,771s

2.43x

2 — 热缓存

4,161s

207s

20.10x

3 — 热缓存

4,321s

210s

20.58x

平均 (所有运行)

4,259s

729s

整体 5.84x

热缓存加速比：20.35x。在第二次和第三次读取时，Alluxio 在约 208 秒内从本地 NVMe 提供了 1TB 的 Parquet 数据。而 GCS 直接读取耗时超过 4,200 秒。数据已经在本地；没有跨区域网络，没有差异。

冷缓存结果（~2.4x）是诚实的且符合预期：首次读取仍然从 GCS 拉取数据，但 Alluxio 的并行预取管道比简单的直接读取更高效。你只需精确支付一次跨区域成本。

为什么我们报告热加速比，而非整体加速比整体 5.84x 包括了冷首次遍历。在实际训练中，第一个 epoch 填充缓存。从第二个 epoch 到第 N 个 epoch——这占据了你大部分挂钟时间——都以热缓存速度运行。20.35x 是你的训练作业实际体验到的速度。

链接60GB S3 API 基准测试——辅助数据https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#60gb-s3-api-benchmark-%E2%80%94-supporting-data

运行

GCS 直接

Alluxio (S3 API)

加速比

1 — 冷缓存

1,142s

735s

1.55x

2 — 热缓存

1,057s

204s

5.18x

3 — 热缓存

1,059s

205s

5.17x

在 60GB 并通过 S3 API 时，热缓存加速比为 5.17x。在大规模下，FUSE 优于 S3 API，因为它消除了 s3fs 协议转换层——Ray Data 直接从本地 POSIX 路径读取，这更干净地与 Ray 的并行预取工作模型匹配。对于大数据集（>100GB），FUSE 是推荐的访问模式。

链接最佳适用场景https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#when-this-helps-most

Ray 的分布式缓存 工作负载在以下四种场景中价值最大：

多 epoch 训练任何多次读取同一数据集的作业。缓存将跨区域成本分摊到所有 epoch 中——迭代次数越多，回报越好。

Ray Tune 超参数搜索多个并发试验读取同一数据集。Alluxio 从本地 NVMe 为所有试验提供数据，而不是向 GCS 发起并行的跨区域请求。

跨区域 / 多云计算在一个区域，数据在另一个区域。智能地跨区域和云提供商回退，以最大化可用性并最小化成本。适用于 GCS、S3 和 Azure Blob。一次数据摄取，之后全部本地速度。

链接入门指南https://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#getting-started

Alluxio 作为 Kubernetes operator 与你的 Ray 集群一起部署。此 operator 不会与部署在 Anyscale Kubernetes 云资源上的 Anyscale operator 交互。与 Ray Data 的集成需要以下两种设置之一：

import s3fs, ray

# 选项 1 — S3 API (开箱即用)
alluxio_fs = s3fs.S3FileSystem(
    key="alluxio", secret="alluxio",
    endpoint_url="http://alluxio-worker.alluxio.svc:29998",
    client_kwargs={"region_name": "us-east-1"},
    config_kwargs={"s3": {"addressing_style": "path"}},
)
ds = ray.data.read_parquet("s3://gcs/your-dataset/", filesystem=alluxio_fs)

# 选项 2 — FUSE (推荐用于大规模读取)
ds = ray.data.read_parquet("/mnt/alluxio/gcs/your-dataset/")

# 无论哪种方式——使用此方法进行基准测试，而不是 .materialize()
ds.map_batches(lambda x: x).count()

链接在 Anyscale 上的 Ray 工作负载中试用 Alluxiohttps://www.anyscale.com/blog/20-times-faster-cross-region-training-data-reads-alluxio-ray-on-anyscale#try-alluxio-with-your-ray-on-anyscale-workloads

如果你正在使用 Ray Data 访问云端对象存储——尤其是跨区域或跨云——Alluxio 的分布式缓存可以为你的数据集带来类似的加速，而无需更改训练代码。

立即使用 Anyscale 开始，获得 $100 免费额度 (https://authkit.anyscale.com/?) 来构建你选择的 AI 应用，无论是处理大规模视频和 VLM 的多模态数据管道、为物理 AI 微调 VLA，还是大规模运行 LLM 推理。此处及更多入门模板。

免费开始使用 Alluxio AI (https://www.alluxio.io/alluxio-ai-free-trial-c) 来对你的工作负载进行基准测试，或探索 Fireworks AI 案例研究 (https://www.alluxio.io/customers/fireworks-ai)，了解一个生产级 AI 平台如何利用 Alluxio 来加速模型服务和训练数据交付。