NVIDIA cuObject brings RDMA object storage to GPUs

NVIDIA is putting object storage on the same fast path its accelerators already use for files. The company has expanded xio-sig to cover cuObject alongside cuFile and released the cuObject client and server libraries as generally available, in partnership with Google Cloud and Microsoft.

What cuObject changes

Accelerators have long been able to reach file storage directly, bypassing the server's CPU-controlled memory and moving data over RDMA through a ConnectX NIC or BlueField DPU. Object storage lacked the equivalent. Developers were left juggling provider-specific integrations because object storage over RDMA had no shared wire protocol.

cuObject supplies that protocol and an API set. Applications and servers can be built against cuObject's RDMA path, and xio-sig gives the client a route to interoperate with any server-side implementation that follows the same wire protocol. The object control protocol runs over HTTPS and TCP, while the bulk data transfers travel over RDMA.

The point of all this is throughput and CPU headroom. Moving object data without staging it through host memory raises transfer rates, cuts latency and reduces CPU utilisation on both reads and writes — the sort of saving that matters when training runs, inference context, tool calls and database lookups are all competing for the same storage fabric.

SCADA and the Storage-Next bet

The second half of the announcement sits under NVIDIA's Storage-Next initiative, which now involves more than 40 vendors and customers including NAND makers, controller vendors, storage providers, hyperscalers and application developers. NVIDIA is using it to define how GPU-driven storage should behave before the industry settles into incompatible answers.

The new piece of software is the Scaled Accelerated Data Access Server SDK. It lets storage providers build servers that accept requests from GPU-based SCADA clients, serve them from local or remote storage, and return results over RDMA. A Storage Lender Service and a SCADA command-line tool for configuration and deployment ship alongside it. IBM has demonstrated interoperability with a prototype that combines SCADA and IBM Storage Scale.

Where Google Cloud and Microsoft sit

Google Cloud is already a maintainer for cuFile in xio-sig and, according to the post, is evaluating a wider role covering cuObject. Microsoft has said it expects to join the xio-sig board to work on storage I/O interoperability. NVIDIA also notes that xio-sig's repository is now structured for both cuFile and cuObject, but that headers, the cuObject wire protocol and the libxFile and xFilekernel implementation code will only be shared once the production-ready stack clears conformance tests. Governance documents are still being reviewed by incoming board members.

cuObject Server 2.0.0 is available for download now, and the API reference sits alongside NVIDIA's existing GPU Direct Storage documentation.

Our opinion

This is one of the less glamorous announcements of the year and probably one of the more consequential. Every AI cluster conversation starts with how many accelerators fit in a rack and ends with an awkward pause about what feeds them, and object storage has been the weak link precisely because nobody agreed on a wire protocol. NVIDIA stepping in with a protocol, an open repository structure and a partner list that includes two hyperscalers is the fastest route to a standard, and also the route that makes NVIDIA the arbiter of it. That is worth flagging rather than celebrating. The conformance-test gate on the actual source code is a reasonable guard against shipping something half-finished, but until libxFile and the wire protocol headers are public, cuObject is a specification with downloads rather than a genuinely open stack. The Storage-Next pledge towards interoperable standards will be judged on whether competing storage vendors ship servers against it, or merely support it in a press release.