NVIDIA Developer Blog · · 8 min read

Expanding AI Storage Access with NVIDIA cuObject and the NVIDIA SCADA Server SDK

Mirrored from NVIDIA Developer Blog for archival readability. Support the source by reading on the original site.

Expanding AI Storage Access with NVIDIA cuObject and the NVIDIA SCADA Server SDK

Illustration of a data storage system connected by a glowing green path to rows of servers.

AI-Generated Summary

  • NVIDIA cuObject client and server libraries are now generally available, providing standardized APIs and an RDMA wire protocol for accelerated object storage access without routing data through the server CPU.
  • The xio-sig consortium is expanding to include cuObject alongside cuFile, with Google Cloud evaluating participation and Microsoft planning to join the board to improve storage I/O interoperability.
  • The new SCADA Server SDK enables storage providers to build servers that respond to GPU-initiated requests from SCADA clients, and IBM Storage has demonstrated a prototype integrating SCADA with IBM Storage Scale.
  • NVIDIA Storage-Next initiative coordinates over 40 vendors and customers to define open industry standards for GPU-driven, fine-grained storage access, with SCADA as the supporting software infrastructure.

Next Steps

  • Watch the xio-sig repository for updates on cuObject and cuFile interoperability work.
  • Review the cuObject documentation to understand the APIs and integration patterns.
  • Download cuObject Server 2.0.0 to begin evaluating the accelerated object storage libraries.
Powered by NVIDIA Nemotron. AI-generated content may summarize information incompletely. Verify important information. Learn more

AI infrastructure engineers, storage developers, and cloud service providers need fast and secure access to high-capacity file and object storage to support AI workloads.

AI workloads increasingly require high-speed data access for training, fine-tuning, inference context, tool calls, searches, and database lookups. Much of this data lies in files and objects stored both on-premises and in the cloud. Compute accelerators—including GPUs, TPUs, and XPUs—need remote direct memory access (RDMA) that uses NIC- or DPU-accelerated data transfers (like NVIDIA ConnectX NIC or NVIDIA BlueField DPU) and doesn’t copy the data through the server’s CPU-controlled memory. The need for RDMA-accelerated, zero-copy data transfers grows with faster GPU architectures.

Developers building direct access to file and object storage have had to navigate different APIs and protocols across providers. Object storage over RDMA has also lacked a common wire protocol, leaving developers to support provider-specific integrations or rely on traditional access methods.

The expansion of xio-sig and the new Scaled Accelerated Data Access (SCADA) Server SDK offer two ways to build more interoperable storage access for AI workloads.

New developments in xio-sig and SCADA

NVIDIA is expanding xio-sig to include NVIDIA cuObject alongside cuFile, in partnership with Google Cloud and Microsoft. It is also announcing the general availability of cuObject client and server libraries. Developers can use cuObject’s APIs and RDMA wire protocol to build accelerated object-storage applications and servers, while xio-sig provides a path toward enabling the cuObject client to interoperate with any server-side implementation that adheres to the wire protocol.

A new SCADA Server SDK enables storage providers to build SCADA servers that respond to GPU-initiated requests from SCADA clients. IBM has shown interoperability with a prototype that integrates SCADA and IBM Storage Scale. Together with the xio-sig expansion, these efforts give AI developers, storage providers, and cloud services more ways to build and use accelerated storage through shared APIs and protocols.

There is also an emerging class of AI data access involving small, fine-grained I/O requests initiated by accelerators that don’t fit traditional storage media or protocols. 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. The software infrastructure supporting high-throughput, fine-grained, GPU-initiated storage access is SCADA. The FMS blog on open-source cuFile APIs, Storage-Next, and SCADA provides background on these efforts.

cuObject support in xio-sig

The general availability of cuObject libraries provides AI application developers, open source framework developers, storage providers, and storage consumers with standardized methods for accelerated AI data access using both file and object protocols, as shown in Figure 1. AI accelerators can access file and object storage using RDMA, without routing data through the server CPU, enabling higher throughput, lower latency, and reduced CPU utilization for data writes and reads.

A block diagram on the left side illustrates how an AI application can use the cuObject Client API to access object storage servers over a network using different object control protocol SDKs, which may be supported by various cloud providers in the future. The diagram shows that the object protocol control path runs over HTTPS/TCP while the object data transfers run over RDMA networks.
Figure 1. cuObject enables developers to accelerate application access to object storage servers using different object control protocols and SDKs. The object control protocol runs over HTTPS/TCP, while the object data transfers occur over RDMA

Building on its involvement as a maintainer for cuFile in xio-sig, Google Cloud is evaluating expanding its participation for cuObject, reflecting its focus on high-performance cloud file and object storage. Microsoft also looks forward to joining the xio-sig Board to improve interoperability in storage I/O.

xio-sig progress

The repository structure is set up for each of cuFile and cuObject. Headers for cuFile and cuObject, the cuObject wire protocol, and library implementation code for libxFile and xFilekernel code will be shared once the production-ready stack passes conformance tests. The governance documents are currently under review by pending Board Members.

NVIDIA Storage-Next and SCADA expansion

Within the Storage-Next initiative, the new SCADA Server SDK enables storage partners to build servers that receive requests from GPU-based SCADA clients, fulfill them using local or remote storage, and deliver the results over RDMA. The effort also includes the Storage Lender Service and a SCADA command-line utility for configuring and deploying SCADA. These components support storage-provider servers that can interoperate with SCADA clients.

A block diagram shows a SCADA client on the left connecting via PCIe, NVIDIA NVLink, or a network to a 3rd-party SCADA Server in the middle. The SCADA server connects via a network to 3rd-party file servers on the right side. The middle part of the diagram illustrates that different SCADA servers can be built using the SCADA Server SDK and respond to requests from SCADA clients.
Figure 2. The SCADA Server SDK enables third-party developers to build SCADA storage servers that respond to SCADA client requests through a common interface

IBM Storage has demonstrated a prototype in which a SCADA client sends requests to their initial version of the Storage Scale SCADA server, built on the new SCADA Server SDK. This shows how storage vendors can collaborate with NVIDIA to build an ecosystem for SCADA’s accelerated, GPU-initiated storage access, paving the way for software infrastructure that could support access to large datasets for applications such as semantic search, recommender systems, and fraud detection.

Get started with cuObject and xio-sig

With xio-sig expanding to include NVIDIA cuObject and cuObject libraries now generally available, storage partners, providers, and consumers can start using cuObject and prepare to contribute to the community’s work on interoperable APIs and protocols for both cuFile and cuObject.

See the notice regarding software product information.

Discuss (0)

Tags

AI Platforms/Deployment | Data Center / Cloud | General | Intermediate Technical | Deep dive | AI Factory | AI Networking | Cloud APIs | Cloud Networking | Open Source

About the Authors

Harish Arora
About Harish Arora
Harish Arora is a principal product manager in the DGX Platforms and Solutions group. He manages the group’s storage program and leads STX product definition and storage partner engagement. Additionally, Harish is the product manager for NVIDIA cuObject, an RDMA acceleration technology for high-performance object storage. Harish joined NVIDIA five years ago. His 27-year career in the storage industry, spanning startups and large organizations, has focused on creating new products and defining new business models. Harish began his career as an engineer before transitioning to roles in business development, corporate development, and product management. He holds a master’s degree in computer science from IMT Ghaziabad in India and an MBA from the Johnson School at Cornell University.
Avatar photo
About Vikram Sharma Mailthody
Dr. Vikram Sharma Mailthody is part of NVIDIA Research and a co-architect of NVIDIA Dynamo. His work focuses on solving foundational systems-level challenges in emerging data center workloads, with an emphasis on scalable GPU memory and storage system architectures.
Avatar photo
About Kiran K. Modukuri
Kiran Modukuri is a principal software engineer at NVIDIA, where he works on accelerating IO pipelines. He is the co-architect of the GPUDirect Storage product. Before joining NVIDIA, he worked as a senior software engineer at NetApp. He earned a master's in computer science at the University of Arizona. He has over 15 years of experience in distributed filesystems and storage technologies.
Avatar photo
About CJ Newburn
Chris J. Newburn, who goes by CJ, is a principal architect in the Compute Software Group at NVIDIA, where he leads HPC strategy and the software product roadmap, with a special focus on systems and programming models for scale. CJ is the architect of Magnum IO and the co-architect of GPUDirect Storage, heads the Summit Dev2Dev Series with the Department of Energy, and leads the HPC Containers Advisory Council. CJ has contributed to both hardware and software technologies for the past 20 years and has over 100 patents. He's a community builder with a passion for extending the core capabilities of hardware and software platforms from HPC into AI, data science, and visualization. Before getting his Ph.D. at Carnegie Mellon University, CJ did stints at a couple of startups, working on a voice recognizer and a VLIW supercomputer. He's delighted to have worked on volume products that his mom used.

Comments

Discussion (0)

Sign in to join the discussion. Free account, 30 seconds — email code or GitHub.

Sign in →

No comments yet. Sign in and be the first to say something.

More from NVIDIA Developer Blog