VDURA V12 brings enterprise storage architecture designed for hyperscaler GPU-intensive workloads, addressing the challenge of keeping accelerators fully utilized.

Cloud operators are investing heavily in GPUs and need to keep them productively utilized. Storage is critical to this equation—specifically, how quickly the storage system can move data to and from GPUs. In some AI clusters, storage has already become a constraint.

Hyperscalers have dealt with similar storage challenges for years. VDURA now wants to bring those proven approaches to AI infrastructure with V12, which is now generally available and qualified on Supermicro hardware.

A key aspect of V12 is more efficient use of expensive flash storage. Active training sets and hot data may require NVMe performance, but older checkpoints and archived datasets often do not. VDURA enables operators to use both tiers without splitting data across separate storage systems.

VDURA calls this Context-Aware Tiering. It moves data between flash and hard drives—hot data stays on flash, while colder data migrates to disk. From the user's perspective, they see a single storage pool. This means companies avoid paying for flash across their entire system.

The multi-tenant features in V12 are clearly aimed at cloud operators. VDURA's customers share infrastructure but have different performance needs and security requirements. With V12, operators can now isolate tenants with separate namespaces, quality-of-service (QOS) policies, encryption keys, and network controls.

V12 adds Kubernetes CSI support, REST APIs, and infrastructure-as-code tools—giving operators multiple ways to manage storage. Critically, these features integrate with tools operators may already use for GPU management, reducing the need for separate operational workflows.

Inference presents another challenge. A Kubernetes pod can stop, restart, crash, or be replaced. What happens to the KV cache in these scenarios? V12 addresses this with KVCache Writeback, which preserves the cache during pod changes and allows it to be restored later. This means models don't have to rebuild context from scratch, reducing time-to-first-token and GPU workload. Real-world benefit will depend on the specific workload.

Supermicro's qualification provides customers with a validated hardware configuration that works with V12. V12 runs on Supermicro Building Block systems with AMD EPYC processors, NVMe storage, and hybrid capacity configurations. The architecture scales from a handful to 100,000 GPUs, with storage nodes communicating to GPU servers over RDMA, keeping data movement fast without requiring a separate back-end network.

At around 20 PB, the balance between flash and capacity storage becomes important. VDURA offers flexibility—customers can keep most of the system on cheaper capacity storage, go all-flash, or choose a configuration in between based on workload.

VDURA claims more than twice the performance per watt and a total cost of ownership more than 60% lower than competing systems at similar data feed rates. These are the company's own figures; real savings will vary with workload and configuration.

CEO Ken Claffey framed V12 as a response to persistent operator requests: keep GPUs fed, isolate tenants, automate storage management, and add capacity without deploying a second system. He described V12 as a packaged version of the mixed-fleet, software-defined approach hyperscalers use internally.

The broader trend is a shift in how storage is evaluated—less as a standalone product, more by its impact on GPU cluster economics. For cloud operators, the goal isn't simply more capacity. It's keeping expensive accelerators fully utilized without building an equally expensive storage layer. V12 is VDURA's attempt to hit both targets. Customer deployments in the coming quarters will demonstrate whether it succeeds.