Lustre and WEKA can both keep a large GPU cluster busy, but they ask the buyer to operate very different machines. Lustre exposes the classic separation between metadata and object-storage services and lets the site assemble the hardware. WEKA sells a distributed software platform built around NVMe, with commercial management, snapshots, object tiering and supported GPU-direct data paths. The right choice often appears in the operations rota before it appears in a benchmark.
Executive summary
Lustre is the stronger candidate for teams that already run HPC infrastructure, want an open parallel POSIX filesystem, need hardware freedom and can own tuning, failover and upgrades. It remains a direct answer for scratch, checkpoint and large shared-file workloads.
WEKA is the stronger candidate for teams that want a commercial high-performance file tier, NVMe-led scale-out, integrated object-store lifecycle, several access protocols and a vendor support path. Its client and backend design can consume reserved CPU resources and needs careful network qualification; licensing and a supported hardware matrix also change the cost model.
For mixed estates, Lustre can minimise software dependency while WEKA can reduce integration work. Neither platform should be selected from vendor peak figures. Run the intended data loader, checkpoint format and restore process on the proposed clients. GPUMachines can include that storage decision in a scale-out storage and GPU-fabric review.
Quick comparison
| Area | Lustre | WEKA | | --- | --- | --- | | Product model | Open source parallel filesystem; commercial support is available from third parties | Commercial software data platform | | Data path | Clients communicate with metadata and object-storage services through LNet | Distributed WEKA services across NVMe nodes and clients, with kernel-bypass paths in supported modes | | Primary storage | Flexible: flash, HDD or external storage according to design | NVMe flash performance tier, with optional object-store capacity tier | | Access | Native Lustre client and POSIX namespace | POSIX plus product support for NFS, SMB, S3 and GPUDirect Storage in qualified configurations | | Operations | Site assembles management, monitoring and lifecycle practices | Integrated GUI, CLI, APIs, support and platform lifecycle | | Cloud use | Available through self-managed and managed services | On-premise and public-cloud deployment options, subject to WEKA support terms | | Best fit | Experienced HPC teams and dedicated parallel-file workloads | AI, HPC and data teams seeking a packaged high-performance shared tier |
Start with the data path, not the feature list
In Lustre, a client contacts Metadata Servers for namespace information and reads or writes file extents directly to Object Storage Targets through Object Storage Servers. LNet carries the traffic over the selected fabric. Files and directories can be striped to spread work.
WEKA distributes file-system functions across its cluster and uses NVMe SSDs as the performance tier. Its documentation describes backend compute, drive and frontend services, with different deployment modes for dedicated storage servers, converged systems and clients. It can use RDMA and NVIDIA GPUDirect Storage in supported environments, reducing copies through host memory for suitable I/O.
These designs create different sizing questions. Lustre asks how many metadata and object-storage services, targets and client paths the workload needs. WEKA asks how many backend resources, NVMe drives, reserved CPU cores and frontend paths are required, plus how the object tier will behave for warm data.
Both need a low-latency, high-bandwidth network. Both can disappoint when the application issues unfriendly I/O.
Where Lustre has the advantage
Open software and hardware choice
Community Lustre does not impose a proprietary filesystem subscription. An experienced site can select storage servers, media, RAID or software-defined protection and fabrics according to local requirements. The team controls release adoption and can inspect or change the source.
This fits research centres that keep systems for many years and already own the operational tooling. It also supports unusual capacity/performance mixes that may fall outside a commercial product matrix.
Clear HPC lineage
Lustre's role is easy to understand: a parallel shared filesystem for clients that need aggregate bandwidth and POSIX access. It integrates naturally with Linux compute clusters and schedulers. Sites with existing Lustre conventions for project spaces, scratch, quotas and striping can reuse them.
Flexible media economics
A Lustre system can put low-latency flash under metadata, use NVMe for a checkpoint tier and retain HDD capacity for large datasets. It can also use enterprise storage arrays behind targets. The architecture does not require every byte to live on NVMe.
The site must integrate lifecycle and protection, but it can tune the spend closely to its data classes.
No required client-side product service beyond Lustre
Lustre clients need compatible kernel modules and network software, which is real work. They do not normally reserve CPU cores for a proprietary user-space filesystem data path in the way some high-performance WEKA modes do. Check both platforms on the actual GPU host; host CPU pressure may matter for preprocessing-heavy jobs.
Where WEKA has the advantage
Productised operations
WEKA supplies installation, management, telemetry, APIs, support and an upgrade path as one product. That packaging can shorten deployment and reduce the number of components a small platform team must maintain. It also gives the buyer a clear escalation route for filesystem behaviour.
Commercial support does not operate the application or switching fabric for you. The contract should state supported kernels, NICs, clouds and server configurations, and the customer must preserve that matrix through change.
NVMe-led performance tier
WEKA was designed around flash and distributed file services rather than adapting an HDD-era layout. Its architecture spreads data and metadata work, and its supported RDMA and GPUDirect Storage modes target low-latency paths for GPU and HPC clients.
This can suit mixed I/O where both metadata and large-file bandwidth matter. The proposed cluster still needs measurements at capacity and during component loss.
Integrated object tiering
WEKA can attach object storage to a filesystem so less-active data leaves the SSD tier while remaining in the namespace. Writes complete to SSD first; background processes copy data to object storage according to policy. Cold reads may return from the object tier and therefore carry different latency.
The integration is useful for active/archive economics, but it creates policy work. WEKA documentation warns administrators not to modify WEKA-managed object data directly because the platform stores it in internal structures. Object tiering should not be mistaken for a generally browsable S3 copy.
Multiple access methods and snapshots
WEKA supports product features around NFS, SMB, S3, snapshots, writable snapshots and object-based protection. This can reduce the need for separate gateways and tools in an enterprise estate. Validate the exact release, licence and performance path for each protocol; a feature checkbox does not guarantee that NFS and native clients behave alike.
Dataset reads: large shards or millions of small files?
Large, well-sharded training datasets suit both platforms. Lustre can stripe large files across OSTs, while WEKA can distribute the data across NVMe services. The deciding factors become client count, read concurrency, network and the share of data resident on the flash tier.
Small-file collections put more pressure on metadata and software overhead. Lustre may need additional MDTs, directory striping and faster metadata storage. WEKA distributes its metadata work but still needs adequate cluster and CPU resources. Test directory enumeration, file opens and random sample access, not only sequential readers.
Many teams improve either system by changing the dataset. Packing samples into suitably sized shards, maintaining indexes and avoiding recursive scans can remove more storage load than another shelf of drives.
Checkpoint writes and restore time
Checkpointing is the fairest AI storage test because it combines bandwidth, metadata, synchronisation and failure recovery. Record how long the training job pauses, how quickly the checkpoint reaches protected storage and how long a replacement job takes to restore it.
Lustre gives the operator direct control over stripe count and placement. A tuned layout can spread large checkpoints across many OSTs. The team owns the defaults and must stop users from applying giant stripe counts to tiny files.
WEKA distributes writes across its flash tier and markets the platform heavily for AI checkpoint workloads. Treat published results as WEKA claims until your framework reproduces them. If checkpoints later tier to object storage, distinguish the time at which the application write completes from the time an independent recoverable copy exists.
GPUDirect Storage is useful, not magical
WEKA documents support for NVIDIA GPUDirect Storage in qualified environments. GDS can move data between storage and GPU memory while avoiding some CPU-memory copies, which may reduce CPU overhead and latency for suitable large I/O.
It does not make every training pipeline faster. Data decompression, augmentation, Python workers and small random reads can keep the CPU in the path. The GPU framework, CUDA stack, NIC, mount mode and WEKA release all need support. Measure application throughput and CPU use with GDS enabled and disabled.
Lustre can participate in GPU-direct work through ecosystem components and supported configurations, but this is not a universal upstream promise for every Lustre build. Buyers who require GDS should treat exact support as a gating item, not an assumed feature.
Network design and CPU reservation
WEKA can use TCP, UDP, DPDK or RDMA-related paths depending on deployment mode and release. Some modes dedicate host CPU cores to WEKA services for predictable performance. Those cores are not free on a GPU server that also performs data preparation, tokenisation or simulation.
Lustre's kernel client and LNet stack have their own CPU and memory costs, although the resource model differs. NUMA placement still matters. A NIC under one CPU socket and a GPU or storage path under another can introduce cross-socket traffic.
For either platform, calculate usable switch bandwidth in both directions. Include redundant links, object-tier traffic, backup, recovery and GPU collective communication. If storage and compute share Ethernet, define congestion control and traffic isolation. If they share InfiniBand, check partitions, service levels and rail mapping.
Failure behaviour
Lustre production systems protect MDTs and OSTs and use server failover. The site chooses the storage redundancy, fencing and multipath model. Recovery should be tested with active clients, because a nominally available service can still violate job-latency targets.
WEKA distributes data and service functions across nodes and provides product-level self-healing and protection features. Ask what happens at the minimum supported cluster size after a node or drive loss, how rebuild traffic affects clients and which failures require support involvement.
In both cases, a filesystem snapshot on the same cluster is not a complete backup. Maintain an independent copy according to the value of the data.
Expansion and lifecycle
Community Lustre can accept varied expansions, but balance matters. Adding a small number of faster OSTs may create uneven placement or operational tiers that applications do not understand. Metadata capacity and server failover pairs need their own growth plan.
WEKA expands within a supported configuration and can adjust flash and object capacity according to its architecture. Ask about minimum node counts, mixed hardware generations, rebalance time, licence metrics and whether converged deployments can later separate storage from clients.
Do not buy only for year one. A three-year model should show client growth, active data, object-tier growth, network ports, rack power and migration time.
Security, tenants and user access
Research Lustre often assumes a trusted cluster network and central Linux identity. Modern GPU services may need stronger tenant isolation, encryption, audit and protocol-specific controls. Lustre can participate in secure designs, but the site must assemble identity, network and operational controls.
WEKA packages enterprise security and multi-tenancy capabilities, with details varying by version and licence. Check the exact authentication source, encryption boundary, key ownership, audit export and tenant performance isolation. A commercial checkbox is useful only when it matches the organisation's control requirements.
Cost model
For Lustre, include metadata and object servers, storage enclosures, media, switches, spares, integration, monitoring, support if bought and engineer time. Hardware flexibility can produce excellent cost per usable terabyte, especially when only the hot tier uses flash.
For WEKA, include software licensing, supported servers or cloud instances, NVMe, reserved client or backend CPU, object storage, support, professional services and renewal. Object capacity may be inexpensive, but cold-read latency and cloud retrieval charges can affect workflow cost.
The cheapest design on paper may delay every checkpoint. Translate storage behaviour into GPU-hours and staff-hours before deciding.
Who should choose Lustre?
Lustre fits teams with a mature HPC operating model, in-house filesystem and fabric skills, a clear POSIX workload and a reason to control hardware or source. It is also attractive when an existing Lustre estate can expand without introducing another management stack.
Choose it because the organisation can run it, not because the source can be downloaded.
Who should choose WEKA?
WEKA fits AI platforms that need a supported high-performance file tier, fast flash, integrated snapshots and object lifecycle, and possibly GDS in a qualified configuration. It can be easier to deploy across mixed enterprise and cloud environments than a hand-built Lustre service.
The commercial contract must earn its cost through performance, operations or reduced platform sprawl. Run a proof phase before assuming all workloads belong on the premium tier.
Who should choose neither?
A small inference cluster may load models from object storage to local NVMe and rarely touch shared files after startup. A conventional NFS service or Ceph may cost less and require less specialist work.
Teams needing one open platform for S3, virtual-machine disks and Kubernetes volumes should compare Ceph and WEKA. Buyers wanting broad multiprotocol consolidation rather than a classic parallel filesystem should read Lustre versus VAST Data.
A two-tier pattern
Lustre or WEKA can serve the active tier while object storage holds the durable corpus. WEKA integrates object tiering into its namespace. Lustre sites often use external data movers, workflow engines or hierarchical-storage tooling.
The integrated route reduces assembly, whereas the modular route gives the operator more choice over object format and migration. Test cold-data recall before allocating GPUs. A scheduler that starts a job while terabytes are still staging converts storage delay into an expensive compute queue.
Questions to ask in a proof phase
Use the same server image, NIC configuration and dataset on both platforms. Measure client CPU consumption as well as storage throughput. Repeat the test during node or drive failure.
Ask how each platform handles:
- Native training reads and framework checkpoint writes.
- Restore after a failed run.
- Metadata-heavy project trees and software environments.
- Capacity above the early-life empty state.
- Rolling upgrades and client-kernel changes.
- Object-tier outage or slow response, if tiering is part of the design.
- Security logging and tenant separation.
Document every manual step. Operational complexity often hides between benchmark runs.
GPUMachines technical view
There is no reason to force a general winner. Lustre offers an open, proven parallel filesystem and can deliver excellent value in expert hands. WEKA offers a modern commercial platform that may reach the target with less integration and more built-in lifecycle support.
The sharp dividing line is ownership. If the team wants to engineer and operate the file system, Lustre deserves a serious design. If it wants to buy a supported data service and can justify the subscription, WEKA deserves the proof phase.
GPUMachines can size either route across storage nodes, GPU clients, Ethernet or InfiniBand clusters, racks and hosting. We can also test whether a smaller active tier plus capacity storage would avoid overbuying flash.
FAQ
Is WEKA based on Lustre?
No. WEKA uses its own distributed filesystem architecture. Both provide parallel shared file access, but their internal designs, deployment models and support terms differ.
Which is faster, Lustre or WEKA?
There is no credible product-wide answer. Compare proposed configurations with identical clients, protection settings and application I/O. Published peaks cannot tell you checkpoint pause time on your cluster.
Does WEKA require NVMe?
Its high-performance tier uses NVMe flash. Object storage can extend capacity for warm data, but writes land on SSD first and cold reads have different behaviour. Confirm current product requirements with WEKA.
Can Lustre tier data to S3?
Lustre sites can integrate external object stores and data-movement or hierarchical-storage tools, but upstream Lustre does not present the same integrated object-tier model as WEKA. The site owns more of the workflow.
Which works better with NVIDIA GPUDirect Storage?
WEKA documents GDS support for qualified configurations. Lustre support depends on the selected distribution and ecosystem stack. Require written support for the exact client, CUDA and network versions, then test the application.
Is Lustre cheaper?
It avoids a proprietary filesystem licence, but integration, testing, on-call coverage and lifecycle work have cost. It is often economical for teams that already own those capabilities.
Can WEKA run in the cloud?
WEKA documents public-cloud deployments and object integration. Instance types, networking, licensing and support vary by cloud and release, so size the actual environment rather than assuming on-premise behaviour.
Do either replace backup?
No. Snapshots and internal redundancy improve recovery, but valuable data needs an independent copy and a tested restore process.
Verdict
Lustre gives capable operators control, open software and a direct parallel-file architecture. WEKA sells a supported NVMe-led platform with integrated lifecycle features and GPU-oriented data paths. The first can cost less when the skills already exist; the second can cost less when integration delay and storage incidents would strand expensive compute.
Choose the operating model you can defend, then make both candidates prove the workload.
Compare Lustre and WEKA configurations with GPUMachines.
Sources and further reading
- Lustre Software Release 2.x Operations Manual
- Lustre project wiki
- WEKA Data Platform introduction
- WEKA networking, RDMA and GPUDirect Storage documentation
- WEKA data lifecycle overview
- WEKA object-store management documentation
- WEKA snapshot documentation
WEKA performance and product statements come from WEKA documentation unless another source is named. Verify the quoted version, licence and support matrix during procurement.