On September 30 NVIDIA announced general availability of the cuObject client and server libraries. cuObject moves data directly over RDMA between GPU or system memory and S3-compatible object storage.
RDMA (Remote Direct Memory Access) lets the network card move data without passing through memory controlled by the server CPU. In cuObject, S3 GET and PUT control requests go over HTTPS/TCP, and only the data payload moves over RDMA.
The client library is included in CUDA Toolkit 13.1.1 and later, while the storage-side server library is downloaded separately. Both the client S3 SDK and the server storage software need changes.
The same announcement introduced the SCADA (Scaled Accelerated Data Access) Server SDK. It lets storage vendors build servers that respond to GPU-initiated requests.
Caveats: a prototype integration and network requirements
The IBM Storage Scale integration in the announcement is a prototype built with the SCADA Server SDK, not evidence of support across all object stores.
According to the docs, the current cuObject implementation requires DC (Dynamic Connection) transport, which works over InfiniBand and RoCEv2. Storage server compatibility and an RDMA network must be in place.
What is described here is NVIDIA’s architecture and availability description, not a hardware or integration test or an independent throughput measurement.
An adoption order that starts with locating the bottleneck
First, find whether the bottleneck is object-request cost, transfer, preprocessing or GPU consumption speed. Faster payload movement helps only when payload movement is what blocks the work.
Then align supported storage and the network path and compare end-to-end training throughput. A familiar S3 interface alone does not show whether this path is available.
cuObject removes the CPU detour for object payloads, and the benefit appears only when storage and network support it together.