Alluxio Delivers High-Performance AI Data Access on Amazon S3 in MLPerf Storage v3.0

The latest MLPerf Storage v3.0 benchmark reflects a new generation of AI infrastructure challenges: faster accelerators, larger models, more demanding checkpointing workloads, and the growing use of cloud object storage as the persistent data layer. In the latest benchmark, Alluxio Enterprise AI demonstrated that organizations can keep persistent AI datasets in Amazon S3 while delivering the high-performance data path required by modern GPU infrastructure.

Alluxio supported 32 simulated NVIDIA B200 accelerators for RetinaNet and eight for 3D U-Net, while delivering 147.03 GiB/s of write bandwidth and 124.34 GiB/s of read bandwidth for Llama 3 405B checkpointing. The results demonstrate a software-defined architecture in which Amazon S3 remains the system of record and Alluxio creates a distributed cache close to GPU compute, using local NVMe as the cache medium in this benchmark configuration.

MLPerf Storage v3.0 raises the bar for modern AI infrastructure

MLCommons expanded MLPerf Storage v3.0 to reflect a broader range of AI storage workloads, including S3 object-storage access alongside POSIX, newer accelerator demand, and checkpointing for Llama 3 models up to 1.25T parameters. That makes this year’s benchmark especially relevant to organizations building AI on cloud object storage while trying to keep increasingly expensive GPU infrastructure productive.

For training, MLPerf emulates accelerator demand rather than requiring physical GPUs. In v3.0, a valid result must keep simulated accelerators above the required utilization threshold: 90% for 3D U-Net and 85% for RetinaNet. Checkpointing separately measures the synchronous write path that can stall training, as well as the recovery read path, across multiple Llama 3 model sizes.

What the benchmark architecture actually looked like

The benchmark used a straightforward data path: Amazon S3 → Alluxio distributed cache → POSIX/FUSE → AI workload clients. Alluxio ran on general-purpose AWS cloud instances and was deployed on Kubernetes through the Alluxio Operator.

1. Llama 3 405B checkpointing at 147.03 GiB/s on Alluxio's distributed cache

Checkpointing can become a costly storage stall in large-scale training because synchronous writes pause progress until model and optimizer state reach the configured checkpoint tier. For the MLPerf Llama 3 405B workload, 512 processes write roughly 5.29 TB of checkpoint data, making sustained write performance especially important.

Alluxio delivered 147.03 GiB/s of aggregate write bandwidth and 124.34 GiB/s of read bandwidth on this workload. The average full-checkpoint write completed in approximately 37.5 seconds across ten consecutive writes. The 1.18 write:read bandwidth ratio is also write-favored — significant because checkpoint writes directly pause training, while reads primarily matter during recovery.

The result came from the same software-defined design described above: 32 cloud workers, 50 Gb Ethernet, and a distributed cache backed by local NVMe, with no dedicated parallel filesystem, storage appliance, or InfiniBand fabric.

2. Near-linear checkpoint scaling makes performance easier to plan

Alluxio scaled from 4.64 GiB/s on one worker to 147.03 GiB/s on 32 workers — a 31.7× throughput increase from 32× the workers, or 98.9% of ideal linear scaling. For infrastructure teams, that makes capacity planning more predictable: scale the distributed cache alongside compute demand rather than replacing the storage architecture when the model grows.

3. Strong B200-class training results across opposite I/O profiles

AI training storage must handle more than one access pattern. 3D U-Net is dominated by large sequential reads, while RetinaNet stresses millions of relatively small JPEG files and therefore puts more pressure on file-open latency, metadata operations, and small-request handling.

Alluxio cleared the MLPerf utilization bar in every timed run across both profiles. At eight simulated NVIDIA B200 accelerators, 3D U-Net reached 43.68 GiB/s at 92.63% accelerator utilization. At 32 simulated B200 accelerators, RetinaNet delivered 4.38 GiB/s at 90.38% utilization. On the small-file profile, the system sustained 14,564 complete file reads per second from a single storage node against a 6.5-million-file dataset.

How Alluxio compares with other MLPerf Storage v3.0 submissions

Aggregate throughput is heavily influenced by the size of the deployed cluster, so it is not sufficient by itself for comparing storage architectures. The five cloud-deployed Llama 3 405B submissions also differed in client networking, usable capacity, and implementation.

Two normalized measures provide more useful context: whether checkpoint performance is optimized for the write path that stalls training, and how much checkpoint write bandwidth the system delivers per TiB of usable capacity.

Because synchronous checkpoint writes pause training while reads occur primarily during recovery, this write-favored profile is more relevant than mathematical symmetry between the two paths.

Together, these results show that Alluxio did not simply achieve strong throughput by deploying a larger cluster. It delivered the most write-favored profile and the highest capacity-normalized checkpoint write throughput among the cloud entries.

Source and methodology: MLPerf Storage v3.0 Closed-division Llama 3 405B results for submissions declaring a cloud deployment. Write-to-read ratio equals published checkpoint write bandwidth divided by read bandwidth. Write bandwidth per usable TiB equals published checkpoint write bandwidth divided by declared usable capacity. Configurations, networking, and durability modes differ; these metrics indicate write-path orientation and throughput density, not cost, total system efficiency, or end-to-end durability.

Why this architecture matters for AI infrastructure teams

Keep object storage as the durable source of truth. Teams do not have to migrate the full dataset into a separate high-performance storage silo before training.

Put performance where GPUs need it. Alluxio creates a distributed cache close to compute using available storage resources; this benchmark configuration used local NVMe. The cache reduces the distance between training jobs and hot data.

Scale storage performance with the workload. The checkpoint results show near-linear scale-out from one to 32 workers.

Support multiple application interfaces. Applications can access data through POSIX via FUSE, S3, HDFS, and other interfaces while persistent data remains in object storage.

Improve GPU infrastructure economics. Faster data loading and checkpoint writes reduce time spent waiting on I/O, helping expensive accelerators spend more time doing useful work.

The takeaway: keep object storage as the system of record without making it the performance ceiling

MLPerf Storage v3.0 validates an architecture many AI teams are moving toward: scalable object storage for durable data, paired with a high-performance data layer close to compute. Alluxio’s results show that this approach can support sustained B200-class training reads and multi-terabyte LLM checkpoint bursts without permanently relocating datasets into a specialized storage system.

For organizations standardizing on cloud object storage, the strategic question is not whether to abandon S3 for performance. It is how to add a scalable acceleration layer that keeps the simplicity, economics, and flexibility of object storage while meeting the I/O demands of modern AI.

Ready to benchmark your own AI data pipeline? Talk to Alluxio about accelerating training data access and checkpointing while keeping your existing object storage as the system of record.

‍

FAQ: MLPerf Storage v3.0 and Alluxio

What did Alluxio achieve in MLPerf Storage v3.0?

Alluxio achieved 147.03 GiB/s write and 124.34 GiB/s read bandwidth for Llama 3 405B checkpointing, 43.68 GiB/s for 3D U-Net training with eight simulated B200 accelerators, and 4.38 GiB/s for RetinaNet with 32 simulated B200 accelerators.

Did Alluxio use Amazon S3 in the benchmark?

Yes. Amazon S3 was the under-file-system and system of record for Alluxio’s v3.0 Closed-division training and checkpointing submissions, with Alluxio providing a distributed caching layer close to compute, backed by local NVMe in this benchmark configuration.

How fast did Alluxio write a Llama 3 405B checkpoint?

The published result was 147.03 GiB/s for approximately 5.29 TB of checkpoint data written by 512 processes, corresponding to an average full-checkpoint write of about 37.5 seconds.

How did Alluxio scale?

The checkpointing results increased from 4.64 GiB/s on one worker to 147.03 GiB/s on 32 workers, equal to 31.7× throughput from 32× the workers, or 98.9% of ideal linear endpoint scaling.

How should MLPerf Storage results be compared?

Compare systems within the same workload and model size. Because aggregate throughput depends heavily on deployed cluster size, normalized measures such as checkpoint write-to-read ratio and write bandwidth per usable capacity provide important additional context. Client-node count is a harness property rather than a storage-performance metric.