An NVIDIA developer post dated September 30 announces the general availability of the cuObject client and server libraries. Developers can use cuObject’s APIs and RDMA wire protocol to build accelerated object-storage applications and servers. The page also carries a generated summary at the top, and the footer says that summary may be incomplete. The facts below are taken from the body.

[1]
Etching: a teal dashed arc leaves an open tray, clears a closed box, and lands on a small chip.
An open tray sits on the left, a lidded box in the middle, and a small chip on the right. The dashed arc clears the closed box and never enters it. That is object data that does not pass through the server CPU. An illustration, not a photograph of a diagram., AI-generated illustration, not a news photograph

The post says training, fine-tuning, inference context, tool calls, searches, and database lookups increasingly need fast access to files and objects, both on premises and in the cloud. GPUs, TPUs, and XPUs need remote direct memory access, with transfers accelerated by a NIC or a data-processing unit, and without copying the data through memory controlled by the server CPU. Direct access to file and object storage has meant different APIs and protocols for each provider. Object storage over RDMA has also lacked a common wire protocol, so developers either built provider-specific integrations or fell back to older access methods.

With cuObject, accelerators reach file and object storage over RDMA without routing data through the server CPU. The post describes that path as higher throughput, lower latency, and less CPU use. It does not give measurements. The figure caption says the object control protocol runs over HTTPS/TCP, while object data transfers occur over RDMA.

[1]

NVIDIA is expanding xio-sig to include cuObject alongside cuFile, and it names Google Cloud and Microsoft as partners. Google Cloud is already a cuFile maintainer in xio-sig and is evaluating a wider role for cuObject. Microsoft looks forward to joining the xio-sig board to improve storage I/O interoperability. The post says “looks forward to joining,” not that Microsoft has joined.

The stated path is for a cuObject client to work with any server that follows the wire protocol. The repository is already split between cuFile and cuObject. Headers for both, the cuObject wire protocol, and the libxFile and xFilekernel implementation code will be shared once a production-ready stack passes conformance tests. Governance documents are still under review by pending board members.

[1]

The same post announces the SCADA Server SDK. Storage providers can use it to build servers that answer requests from GPU-based SCADA clients, fill them from local or remote storage, and return results over RDMA. IBM has shown a prototype in which a SCADA client sends requests to an initial Storage Scale SCADA server built on the SDK. That is an interoperability prototype, not a product on sale.

Under the effort named Storage-Next, NVIDIA is leading a group of more than 40 vendors and customers, including NAND vendors, controller vendors, storage providers, hyperscalers, and application developers, to define GPU-driven storage and turn it into interoperable open standards. The software stack for high-throughput, fine-grained, GPU-initiated access is SCADA. The page links cuObject Server 2.0.0.

[1]

要点

  • The cuObject client and server libraries are generally available, with APIs and an RDMA wire protocol for object storage that does not route data through the server CPU.
  • Control traffic uses HTTPS/TCP and data uses RDMA. The post gives no throughput or latency measurements.
  • Google Cloud is evaluating a wider role. Microsoft looks forward to joining the xio-sig board and has not joined yet. Headers and implementation code wait on conformance tests.
  • The SCADA Server SDK lets storage vendors answer GPU-initiated requests. IBM showed a Storage Scale prototype. The Storage-Next group has more than 40 members.