Nvidia open source cuFile APIs for GPU-direct storage

Nvidia has announced that it will open source cuFile APIs and the vertical storage software stack beneath them, making a core part of its GPUDirect Storage technology available for outside contribution. The Nvidia open source cuFile move matters to storage vendors and AI infrastructure teams because the software is intended to create a direct data path between storage and GPU memory, avoiding a CPU memory bounce buffer.

Nvidia made the announcement at the Future of Memory and Storage conference. The company says the APIs and underlying stack will live at the xio-sig GitHub organization, whose inaugural maintainers are Google, Intel, Meta and Nvidia. Nvidia did not disclose the license, the precise code included in the release or release-version boundaries in the material reviewed.

What does Nvidia open source cuFile mean for GPU storage?

cuFile is the application interface used by software to access Nvidia GPUDirect Storage. According to Nvidia's cuFile reference documentation, GPUDirect Storage uses direct memory access, or DMA, for transfers between storage and GPU memory. By avoiding an intermediate copy through CPU-managed system memory, the design can reduce CPU load while improving bandwidth and latency.

The direct path does not mean GPUs independently call the API. Nvidia's documentation says cuFile API calls are issued by the CPU. In a typical application flow, a developer initializes the driver, registers a file handle and, optionally, a buffer, then performs reads or writes through cuFileRead and cuFileWrite. Cleanup calls release the associated driver, file and buffer resources.

Nvidia says the technology lets GPUs read from and write to storage directly, and claims storage data can be accessed in microseconds. That is a company performance claim, not a published independent benchmark. SiliconANGLE characterized the access latency in milliseconds, and neither account provides a reproducible workload or configuration that would establish a general speedup.

Direct transfers remain configuration-dependent

Opening the code does not make GPUDirect Storage's direct path available on every deployment. Nvidia says direct peer-to-peer transfers require supported hardware and filesystem configurations. Its documentation also identifies unsupported filesystems, absent RDMA links, unavailable kernel support and nonoptimal configurations as cases where direct GDS operation may not be available.

In those cases, cuFile compatibility mode can use POSIX I/O to host memory and copy data to GPU memory when applicable. Operators evaluating the release will still need to test their GPU, storage, networking and filesystem combination rather than assume a storage-side upgrade alone will change application performance.

Storage-Next expands the vendor effort

Separately, Nvidia announced Storage-Next, an industry initiative it says includes more than 40 storage and flash vendors, including DDN, Kioxia and Micron. Nvidia says the group will work with storage, controller, cooling, orchestration and standards organizations on interoperable standards for GPU-driven storage.

The initiative is tied to SCADA, short for scaled, accelerated data access, which Nvidia describes as a framework for massively parallel GPUs to pull needed data from storage into high-speed memory. Nvidia says SCADA uses a privileged setup component to establish protected access under Linux security protocols, while performance-sensitive application components stay outside the trusted computing base.

For infrastructure buyers, the announcement offers a potentially broader development and standards channel around Nvidia's storage path. It does not yet establish a universal performance improvement, or resolve the deployment compatibility work that has shaped GPUDirect Storage adoption.

This story draws on original reporting from SiliconANGLE.