NVIDIA adds cuObject to xio-sig and ships the SCADA Server SDK, letting GPUs reach file and object storage directly over RDMA

NVIDIA, in partnership with Google Cloud and Microsoft, is expanding xio-sig to include NVIDIA cuObject alongside cuFile, and is announcing the general availability of the cuObject client and server libraries. Previously, object storage over RDMA lacked a common wire protocol, leaving developers to support provider-specific integrations or rely on traditional access methods; cuObject now provides APIs and an RDMA wire protocol, and xio-sig offers a path for the cuObject client to interoperate with any server-side implementation that adheres to that wire protocol. The text describes this as a partnership announcement with Google Cloud and Microsoft and states the cuObject client and server libraries are generally available; the repository structure is set up for cuFile and cuObject separately, but headers, the cuObject wire protocol, and libxFile and xFilekernel implementation code will be shared once the production-ready stack passes conformance tests, and governance documents are under review by pending Board Members.

The new SCADA Server SDK enables storage providers to build SCADA servers that receive requests from GPU-based SCADA clients, fulfill them using local or remote storage, and deliver results over RDMA. SCADA is positioned as the software infrastructure supporting high-throughput, fine-grained, GPU-initiated storage access, aimed at small, fine-grained I/O requests initiated by accelerators that do not fit traditional storage media or protocols. The text notes the effort also includes the Storage Lender Service and a SCADA command-line utility for configuring and deploying SCADA; IBM Storage demonstrated a prototype in which a SCADA client sends requests to its initial version of the Storage Scale SCADA server built on the new SDK, illustrating interoperability.

Through the NVIDIA Storage-Next initiative, NVIDIA is leading a group of over 40 vendors and customers, including NAND vendors, controller vendors, storage providers, hyperscalers, and application developers, to define how GPU-driven storage should work and turn those advancements into interoperable, open industry standards. It moves GPU-initiated storage access from single-vendor implementations toward multi-party open standards work spanning media, controllers, and applications. The text gives the participant count as over 40 and lists their categories, and identifies SCADA as the software infrastructure supporting this access; it does not give specific draft provisions or a timeline.

With cuObject libraries generally available, AI application developers, open source framework developers, storage providers, and storage consumers gain standardized methods for accelerated AI data access using both file and object protocols, with accelerators accessing storage over RDMA without routing data through the server CPU. It unifies the file and object paths under shared APIs and protocols, so these roles can start using cuObject and prepare to contribute to the community's work on interoperable APIs and protocols for both cuFile and cuObject. The text states this enables higher throughput, lower latency, and reduced CPU utilization for data writes and reads; Google Cloud is evaluating expanding its participation for cuObject in xio-sig, and Microsoft looks forward to joining the xio-sig Board to improve interoperability in storage I/O.

This combination targets AI infrastructure engineers, storage developers, and cloud service providers who need fast and secure access to high-capacity file and object storage for AI workloads, covering on-premises and cloud deployments and data access for training, fine-tuning, inference context, tool calls, searches, and database lookups. The cuObject client and server libraries are generally available, so developers can build accelerated object-storage applications and servers; storage providers can build SCADA servers that respond to GPU-initiated requests using the SCADA Server SDK, along with the Storage Lender Service and the SCADA command-line utility for configuration and deployment. The xio-sig expansion provides a path for the cuObject client to interoperate with any server-side implementation that adheres to the wire protocol, Google Cloud is evaluating expanding its participation for cuObject, and Microsoft looks forward to joining the xio-sig Board.

The text gives no specific figures for throughput, latency, or CPU utilization, describing higher throughput, lower latency, and reduced CPU utilization only qualitatively; the sharing of cuObject headers, the wire protocol, and libxFile and xFilekernel implementation code depends on the production-ready stack passing conformance tests, and governance documents are still under review by pending Board Members, so the timing for interoperability commitments remains unclear. The Storage-Next open standards effort involves over 40 participants, but the text does not describe draft contents or a timeline; SCADA interoperability is currently demonstrated through an IBM Storage prototype, with no indication of adoption by other storage vendors. Semantic search, recommender systems, and fraud detection are described as applications that could benefit, which is forward-looking rather than a verified result.