September 1, 2026. MLCommons released the MLPerf Storage v3.0 results. MLPerf Storage is an industry standard benchmark for evaluating storage systems under representative AI training and inference workloads.

OpenLake achieved the highest read and write bandwidth among the published Closed division S3 results for Llama 3.1 8B checkpointing with one client node and one data parallel instance.

These five submissions represent the closest like for like comparison in the published results, although the underlying storage configurations differ.

The result was delivered by OpenLake’s Infinity Core I/O Engine through its S3 API interface.

OpenLake is a high performance storage system powered by io_uring and GPUDirect Storage. Its asynchronous I/O engine is designed to deliver low latency, high throughput storage for AI workloads.

OpenLake’s MLPerf Storage v3.0 result

MLPerf Storage is a reproducible, architecture neutral benchmark. Its checkpointing workload emulates the Llama 3 family from 8B to 1.25 trillion parameters.

For the Llama 3.1 8B configuration, eight processes write and read a checkpoint through 16 files. The test performs 10 checkpoint writes followed by 10 reads and reports average performance. This estimates how a storage system behaves at full load when training processes save model state or restore it after a failure.

Figure 1a: Checkpoint write bandwidth. OpenLake reached 6.72 GiB/s, 1.98× the next fastest comparable submission.

Figure 1b: Checkpoint read bandwidth. OpenLake reached 11.55 GiB/s, the highest of the five comparable submissions.

Figure 2a: Mean checkpoint write duration. Lower is better.

Figure 2b: Mean checkpoint read duration.

The comparison below is limited to the five published results with the same Closed division checkpointing workload, S3 API interface, Llama 3.1 8B model, one client node, and one data parallel instance. Values are rounded to two decimal places.

How OpenLake delivered the result

The submitted system used one client node connected over a 400 Gb/s InfiniBand network to an NVMe backed OpenLake gateway.

OpenLake’s checkpoint data path is powered by the Infinity Core I/O Engine. The implementation uses:

• Asynchronous io_uring I/O for nonblocking kernel operations

• Pinned execution threads

• Fine grained I/O coalescing

• XFS and workload specific storage tuning

• An S3 API interface for writing and reading checkpoints

This architecture keeps I/O operations in flight while reducing scheduling and CPU overhead. For checkpointing, that means accepting parallel writes efficiently, committing each checkpoint durably, and serving the same data quickly during recovery.

Why checkpoint performance matters

Large scale model training can run for weeks across hundreds or thousands of GPUs. To protect that work, training jobs periodically save model weights, optimizer state, and other training state to storage. That saved state is a checkpoint.

During synchronous checkpointing, training cannot continue until the checkpoint has been written durably. Storage performance therefore affects training in two direct ways:

• Checkpoint write performance determines how long training pauses to save state.

• Checkpoint read performance determines how quickly training can recover after a failure.

At large scale, checkpoints can reach hundreds of gigabytes or several terabytes. The storage system must sustain highly parallel I/O while still delivering fast, predictable reads.

What these numbers mean for training infrastructure

Faster checkpoint writes shorten the time GPUs sit idle while state is saved, improving accelerator utilization and reducing training cost. Faster reads shorten the recovery path after a failure.

Across multi million dollar GPU clusters, even small reductions in checkpoint and recovery time compound across every accelerator involved. The result is less wasted GPU time and shorter job runtimes.

This becomes increasingly important for reinforcement learning, pretraining, and post training jobs, where checkpoints may be created frequently and infrastructure failures can otherwise erase substantial amounts of progress.

OpenLake is proud to advance the frontier of large scale LLM training. Data movement will be one of the defining challenges of the next generation of AI, and OpenLake is building the storage foundation required to scale beyond today’s limits.

Looking ahead

OpenLake is committed to keeping the community informed through open, industry neutral, standard benchmarks.

We plan to expand OpenLake’s benchmark coverage across AI storage requirements, including KV cache offloading, checkpointing, training, vector search, and context storage.

Connect with OpenLake

• Explore the project: GitHub

• Join the conversation: Discord

• Follow our progress: LinkedIn

• Want to build at the frontier? Join us