NVIDIA gibt cuObject für RDMA-Direktzugriff auf S3-Objektspeicher frei
Die neuen Bibliotheken umgehen den CPU-TCP-Pfad und beschleunigen KI-Workloads durch direkte RDMA-Transfers zwischen GPU-Speicher und S3-kompatiblem Objektspeicher.
Mit KI erstellt◆ Fakten auf einen Blick
- NVIDIA hat die allgemeine Verfügbarkeit der cuObject-Client- und Serverbibliotheken sowie des SCADA-Server-SDKs angekündigt.
- cuObject ermöglicht direkte Datenübertragungen zwischen GPU-Speicher oder Systemspeicher und S3-kompatiblem Objektspeicher über RDMA und umgeht die CPU-TCP-Verarbeitung.
- cuObject besteht aus zwei Komponenten: cuObjClient (Client-APIs für GET/PUT mit RDMA-Datenpfad) und cuObjServer (RDMA-beschleunigte Serverseite für S3-kompatible Objektspeicher).
- Die cuObject-Client-Bibliothek ist ab CUDA Toolkit 13.1.1 verfügbar und unterliegt der CUDA Toolkit End User License Agreement.
- cuObject v1.3.0 führt RDMA Token Reset ein, um veraltete RDMA-Token zu invalidieren.
- Die xio-sig Storage-Interoperabilitätsinitiative wurde um cuObject erweitert; Google Cloud prüft eine erweiterte Teilnahme, Microsoft hat die Absicht signalisiert, dem xio-sig Board beizutreten.
NVIDIA gibt cuObject für RDMA-Direktzugriff auf S3-Objektspeicher frei
NVIDIA hat die allgemeine Verfügbarkeit der cuObject-Client- und Serverbibliotheken sowie des SCADA-Server-SDKs angekündigt. cuObject ermöglicht direkte RDMA-Datenübertragungen zwischen GPU-Speicher oder Systemspeicher und S3-kompatiblem Objektspeicher. Der bisherige Engpass bei KI-Workloads liegt im host-vermittelten I/O-Pfad: Jede Speicheroperation läuft über die CPU, die den TCP/IP-Stack verarbeitet und Daten häufig erst in lokale Scratch-Dateisysteme staged, bevor sie die GPU erreichen. Das verursacht Latenz, hohe CPU-Auslastung und redundante Datenkopien. cuObject umgeht diesen CPU-TCP-Pfad, indem es die Steuerungsebene von der Datenebene trennt: Die GPU-Anwendung initiiert eine S3-GET/PUT-Anfrage über ein modifiziertes SDK, das RDMA-Metadaten wie x-amz-rdma-token anhängt. Nach Token-Verifizierung baut das Storage-Gateway einen Dynamic-Connection-Transport über InfiniBand oder RoCE v2 auf, und die Nutzdaten werden per RDMA_READ oder RDMA_WRITE direkt in den GPU-Speicher gestreamt – ohne Beteiligung der CPU am Datenpfad. Dadurch wird CPU-Kernel-Code für TCP-Verarbeitung vermieden und die CPU für Daten-Nutzdaten umgangen. Die RDMA-Übertragungen laufen über NVIDIA ConnectX-NICs und BlueField-DPUs und ermöglichen Zero-Copy-Transfers. cuObject bringt GPUDirect-Storage-Semantik auf S3-kompatiblen Objektspeicher und flacht die Topologie von Data-Lake zu Scratch-Dateisystem zu GPU ab. Erste Messungen zeigen das Potenzial: Dell erreichte eine Time-to-First-Token von 837 ms bei 235K-Token-Kontext – 13,4-mal schneller als das Neuberechnen des Prefill (11.223 ms) – und Cloudian berichtet von nachhaltig mehr als 200 GB/s Durchsatz auf GPU-attached S3 Fabrics.
Technische Details und erste Partnerintegrationen
cuObject besteht aus zwei Komponenten: cuObjClient stellt Client-APIs für GET- und PUT-Operationen bereit, bei denen die Steuerung über Callbacks läuft, der Datenpfad aber RDMA nutzt. Die Client-Bibliothek wird in GPU-Anwendungen oder Middleware integriert und fängt S3-Anfragen ab, um den RDMA-Datenpfad zu verwalten. cuObjServer implementiert die RDMA-beschleunigte Serverseite für S3-kompatible Objektspeicher und unterstützt Multithreading, automatisches Verbindungsmanagement und Dynamic-Connection-Transport über InfiniBand oder RoCE v2. Die Client-Bibliothek ist ab CUDA Toolkit 13.1.1 verfügbar. Version 1.3.0 führt einen RDMA Token Reset ein, mit dem veraltete RDMA-Token invalidiert werden können. Die xio-sig-Storage-Interoperabilitätsinitiative wurde um cuObject erweitert; die Initiative führt einen gemeinsamen RDMA-Wire-Protokoll ein, damit beschleunigte Objektspeicher-Anwendungen über verschiedene Server-Implementierungen hinweg interoperabel bleiben. Google Cloud prüft eine erweiterte Teilnahme, Microsoft hat die Absicht signalisiert, dem xio-sig Board beizutreten. Diese mögliche Beteiligung ist für cuObject von Bedeutung, weil sie den gemeinsamen RDMA-Wire-Protokoll auf die großen Cloud-Plattformen ausdehnen würde. Anwender erhielten dadurch einen breiteren Interoperabilitätsstandard: Beschleunigte Objektspeicher-Anwendungen könnten dann über verschiedene Server-Implementierungen hinweg denselben RDMA-Pfad nutzen, ohne auf proprietäre Schnittstellen angewiesen zu sein. Für cuObject-Nutzer bedeutet das mehr Auswahl bei S3-kompatiblen Speicherzielen und geringeres Risiko von Lock-in-Effekten. Dell Technologies hat gemeinsam mit NVIDIA eine beschleunigte Engine für das NIXL OBJ Plugin beigetragen, das Upstream gemerged wurde. Damit können vLLM, LMCache und NIXL KV-Cache über RDMA direkt in GPU-Speicher via cuObject auslagern, etwa auf Dell ObjectScale. Bei einem einzelnen Request mit 235K Token entstand ein 43 GB großer KV-Cache. Dell hat bei diesem Kontext eine Time-to-First-Token von 837 ms gemessen – 13,4-mal schneller als das Neuberechnen des Prefill (11.223 ms) und 1,3- bis 1,5-mal schneller als derselbe Offload über S3-HTTP. VAST Data und MinIO integrieren cuObject über den gemeinsamen RDMA-Wire-Protokoll der xio-sig-Initiative. Dadurch können ihre S3-kompatiblen Speicherlösungen als RDMA-fähige Ziele für cuObject-Anwendungen dienen: Der Datenpfad wird vom Steuerpfad getrennt, und Objekt-Payloads werden per RDMA_READ oder RDMA_WRITE direkt in den GPU-Speicher gestreamt, ohne den CPU-TCP-Stack zu durchlaufen. Für Anwender ergibt sich daraus der Vorteil, dass sie bestehende VAST-Data- oder MinIO-Installationen ohne Umweg über Scratch-Dateisysteme als hochperformante Datenquelle für KI-Training und Inferenz nutzen können. Cloudian berichtet von nachhaltig mehr als 200 GB/s Durchsatz auf GPU-attached S3 Fabrics.



