Running Lustre Directly on Cloud Object Storage: Our MLPerf Storage v3.0 Results

Blog written by Supramani Sammandam, founder and CEO, ZettaLane Systems, published September 1, 2026

The wall every cloud AI team hits
Cloud teams building AI and HPC storage keep hitting the same wall. Managed file services are fast, but priced so that large datasets become cost-prohibitive. Object storage is cheap and effectively limitless — but it is not a file system, so applications either get rewritten to speak object semantics or burn time staging data in and out of a faster tier. And enterprise NAS and high-performance parallel file systems have historically been separate products, on separate infrastructure, with separate budgets.MayaNAS was built to collapse that. It is one engine that presents standard enterprise file protocols and high-performance parallel file systems, with bulk capacity written directly to cloud object storage. In MLPerf Storage v3.0 — the industry’s independent, peer-reviewed benchmark for AI storage — we put it on the record.

The result

• Only: v3.0 submission running Lustre directly on cloud object storage
• 32.42 GB/s: Llama 3 70B checkpoint write (two clients)
• 72 B200 accelerators fed from a single 200 Gbps client

ZettaLane submitted CLOSED-division, MLCommons-verified results in MLPerf Storage v3.0, run entirely on standard Google Cloud virtual machines, with two engines — MayaNAS (object-backed parallel file system) and MayaScale (NVMe-over-TCP block):

Among all MLPerf Storage v3.0 submissions, MayaNAS is the only one to run the Lustre parallel file system directly on a cloud object-storage tier. A single approach served training, checkpointing, and inference-cache workloads across the pipeline.

Per-node efficiency — and it scales out
These runs used a compact footprint driven to full saturation — a few storage nodes and clients, with 200 Gbps client networking fully utilized and no cores or bandwidth left idle. Read the figures as per-client and per-node efficiency, not a ceiling: the same architecture scales out by adding storage-node HA pairs and clients.

The storage was not the bottleneck; the client network was. On RetinaNet, one MayaScale client fed 72 B200-class accelerators — the most of any single-client submission — and on 3D U-Net a single MayaScale client fed 4 B200 to the edge of its 200 Gbps link. In each case the limit was the client NIC, not MayaScale. A B200 node’s natural configuration pairs eight accelerators with 400 Gbps networking, so these single-client figures reflect a networking limit, not a storage one. MayaNAS and MayaScale scale out by adding clients and storage-node HA pairs — not by moving to a premium tier.

How it works
MayaNAS runs Lustre and OpenZFS with one twist that changes the economics: each OST is an OpenZFS dataset whose vdevs are regional, Standard-class Google Cloud Storage buckets. Bulk data is read and written directly and concurrently to object storage through our objbacker layer, while a small NVMe special vdev holds only pool metadata and small blocks. There is no local SSD or ephemeral scratch tier in the data path — the read results were served cold from object storage, confirmed independently by Google Cloud’s own ingress/egress telemetry.

Clients connect with the standard, open-source Lustre and NFS clients already in the Linux kernel. Nothing proprietary is installed on the compute or GPU nodes.

Object storage is a first-class AI tier — but only POSIX serves the whole pipeline
MLPerf Storage v3.0 added an S3 object-storage access layer alongside its POSIX layer — a clear signal that object storage is moving into territory once held by parallel file systems. But the round also drew the boundary sharply: the S3 access layer covers training and checkpointing only. The two inference-era workloads — KV cache and vector database — are POSIX, and no submission ran either on S3.

That is the case for the fusion. Going all-in on object-native (S3) semantics means you cannot serve the inference tier today. MayaNAS approaches the shift from the file-system side: a complete POSIX parallel file system whose data path runs directly on object storage. Existing applications are not rewritten, and the full pipeline — including the POSIX-only KV cache — runs on object economics. We published a KV-cache result on object; an S3-native-only stack cannot yet.

How this differs from other approaches
Several good architectures put object storage near AI workloads, and they solve different problems:

MayaNAS is a fourth thing: not a cache in front of object; not a parallel FS on premium block; not an appliance. That is why it is the only Lustre-on-object submission in the round.

Why it matters
First, NAS is only the starting point. MayaNAS delivers what teams expect from enterprise NAS — NFS and SMB with Active Directory, active-active HA, snapshots, replication, compression — and the same engine scales to the parallel throughput HPC and AI demand via Lustre and pNFS Flex Files. No second storage system to feed the GPUs.

Second, parallel-file-system performance arrives at object-storage economics, in your own cloud. Capacity lives on Standard-class object storage rather than premium managed file or provisioned block. And because the file system, buckets, and encryption keys never leave the customer’s own cloud account, the design is sovereign by design — meeting data-residency and sovereignty requirements without a vendor data plane in the path.

Industry context
The round’s own leadership framed the direction. As Curtis Anderson, MLPerf Storage working group co-chair, put it in MLCommons’ v3.0 results announcement: “…we expect object-based storage systems to emerge as a viable — and possibly preferred — alternative to filesystem-based storage.”

MayaNAS delivers exactly that: object storage carrying the full AI pipeline, as a complete parallel file system. Teams get object-storage economics and Lustre’s POSIX interface from one engine — object storage as the foundation for the file system, with nothing to rewrite and nothing staged in and out.