NVIDIA cuObject and SCADA Server SDK: A New Approach to Accelerated AI Storage Access

AI training and inference are placing unprecedented demands on storage systems. As model sizes and datasets continue to grow, enabling GPUs to access massive file and object storage at maximum speed with minimal overhead has become an unavoidable bottleneck for AI infrastructure engineers. NVIDIA's cuObject and SCADA Server SDK are purpose-built solutions for exactly this challenge.

The Core Challenges of AI Storage Access

The data access patterns of AI workloads are fundamentally different from those of traditional enterprise applications. Training large models requires GPUs to continuously read terabyte- to petabyte-scale datasets from storage; and in inference and Retrieval-Augmented Generation (RAG) scenarios, high-concurrency, low-latency access to object storage is equally critical.

As highlighted in NVIDIA's developer blog, AI infrastructure engineers, storage developers, and cloud service providers all need fast and secure access to high-capacity file and object storage to support modern AI applications. The problem is that traditional storage access paths typically require data to be relayed multiple times through CPU memory — consuming precious CPU cycles and creating a significant performance gap between GPUs and storage.

When thousands of GPUs simultaneously issue requests to storage, this relay overhead is dramatically amplified, directly slowing overall training efficiency and driving up data center operating costs.

About RAG: Retrieval-Augmented Generation (RAG) is one of the most widely adopted paradigms for deploying large language models today. Its core idea is to retrieve relevant document snippets from an external knowledge base (typically a vector database or object storage) at inference time — rather than compressing all knowledge into model parameters — and then inject those snippets into the prompt before generating a response. This allows the model to access continuously updated private data while reducing dependence on extremely large parameter counts. However, the pressure RAG places on storage systems is significant: each inference request may trigger multiple vector searches and document reads. In high-concurrency serving scenarios, storage latency and throughput directly determine overall response time — which is why low-latency object storage access is considered a critical performance metric at the inference stage as well.

cuObject: Object Storage Acceleration for GPUs

cuObject is designed to give GPUs more direct and efficient access to object storage. Object storage (such as S3-compatible interfaces) has become the dominant medium for large-scale AI datasets thanks to its near-unlimited scalability, but optimizing its access path performance has long been an industry challenge.

With cuObject, developers can build data pipelines that bypass redundant data copies, allowing data from storage to flow more directly into GPU memory. This approach follows the same philosophy as NVIDIA's earlier work on GPUDirect Storage — both aim to shorten the physical and logical path from storage to compute units while reducing CPU involvement in the I/O chain.

For AI pipelines that frequently read from object storage — such as large-scale pretraining data loading and vector database retrieval — this type of acceleration delivers tangible throughput gains.

About GPUDirect Storage: GPUDirect Storage (GDS), introduced by NVIDIA around 2020, allows storage devices (such as NVMe SSDs or network-attached storage) to write data directly into GPU memory via the PCIe bus, completely bypassing the CPU and system memory (host memory). In the traditional path, data must first be read from storage into CPU memory, then transferred to GPU memory via a CPU-initiated DMA — each copy consuming CPU cycles and system memory bandwidth. GDS introduces a "direct data path" that compresses this chain into a single hop from storage to GPU memory. cuObject can be understood as extending the GDS philosophy to the object storage protocol layer. Since object storage is natively accessed over HTTP/HTTPS, data passes through the application layer more times, making optimization considerably harder. cuObject's work is to redesign the data path at this protocol layer so that object storage access efficiency approaches that of block storage.

The Role of SCADA Server SDK

The SCADA Server SDK approaches the problem from the server side, providing development tools that help storage vendors and cloud service providers build storage services compatible with NVIDIA's accelerated ecosystem.

This means storage access optimization is no longer limited to the client-side GPU — it forms an end-to-end collaboration: clients issue efficient requests via cuObject, while servers leverage the SCADA Server SDK to deliver matching high-performance responses. Together, they complete the full AI storage access chain.

For service providers building AI cloud platforms, this SDK lowers the barrier to developing a high-performance storage access layer in-house, enabling them to deliver competitive storage performance to customers more quickly.

What This Means for AI Infrastructure

Storage I/O rarely gets as much attention as GPU compute, yet it is one of the decisive factors in the real-world efficiency of large-scale AI systems. No matter how powerful the compute, GPUs sit idle if data cannot be delivered fast enough.

The combination of cuObject and SCADA Server SDK reflects NVIDIA's strategic intent to extend acceleration capabilities beyond compute into adjacent domains like storage and networking — building a fully integrated, hardware-software AI data center stack. For teams facing data throughput bottlenecks, these tools are worth including in any technology evaluation.

It is worth noting that this article is based on NVIDIA's public developer blog. Specific performance metrics, integration details, and supported hardware should be verified against official technical documentation. Engineering teams planning adoption should conduct real-world testing against their own storage architectures.