NVIDIA cuObject apre lo storage AI oltre i file, ma l'interoperabilità è ancora incompleta

Il 30 settembre NVIDIA ha reso generalmente disponibili le librerie client e server di cuObject, estendendo l'accesso accelerato allo storage per l'AI oltre i tradizionali file system. La release di NVIDIA cuObject introduce API standardizzate e un protocollo wire RDMA per spostare dati oggetto senza instradare i payload attraverso la CPU di un server.

L'azienda ha inoltre presentato un SCADA Server SDK per gestire richieste di storage avviate dalle GPU. SCADA significa Scaled Accelerated Data Access, un framework progettato per elevati volumi di operazioni di storage granulari. IBM ha già realizzato un primo prototipo di Storage Scale con l'SDK.

L'annuncio affronta una divisione persistente nell'infrastruttura AI. Lo storage a oggetti offre capacità e interfacce familiari compatibili con S3, mentre le pipeline di training e inferenza ad alte prestazioni spesso si affidano a file system più veloci o storage scratch locale. NVIDIA vuole ridurre questa divisione con cuObject, ma il suo piano più ampio per l'interoperabilità resta incompleto.

NVIDIA cuObject passa da libreria di prodotto a proposta per il settore

Il cambiamento importante non è soltanto il rilascio di un'altra libreria di storage da parte di NVIDIA. L'azienda sta chiedendo a provider cloud e fornitori di storage di convergere su un protocollo comune per oggetti accelerati.

Secondo l'annuncio di NVIDIA, le librerie client e server di cuObject sono ora generalmente disponibili. NVIDIA ha inoltre rilasciato cuObject Server 2.0.0 per i fornitori di storage che valutano l'integrazione lato server.

La libreria client risiede all'interno di un'applicazione GPU, di un data loader o di un livello middleware. Collega le operazioni sugli oggetti a livello applicativo a un percorso dati RDMA. L'accesso remoto diretto alla memoria, o RDMA, consente all'hardware di rete di trasferire dati direttamente tra regioni di memoria registrate.

La libreria server si integra con un servizio di object storage. Gestisce i buffer registrati ed esegue le operazioni RDMA che spostano i dati da o verso il client. Il sistema può puntare alla memoria GPU oppure alla memoria di sistema.

Questo design affronta un problema che GPUDirect Storage non aveva risolto completamente. GPUDirect Storage forniva già un percorso diretto tra storage e memoria GPU, ma la sua interfaccia più nota, cuFile, era incentrata sull'accesso ai file. Molti dataset AI risiedono invece dietro interfacce a oggetti.

La differenza è rilevante per le organizzazioni che conservano campioni di training, documenti, immagini, checkpoint e artefatti generati in repository compatibili con S3. Questi sistemi sono interessanti perché scalano su namespace di grandi dimensioni e separano storage e calcolo. Tuttavia, l'accesso convenzionale agli oggetti passa di norma attraverso uno stack TCP e buffer gestiti dalla CPU.

NVIDIA cuObject mantiene le operazioni di controllo orientate agli oggetti, modificando al contempo il percorso del payload. Un client può ancora inviare richieste GET o PUT familiari tramite un kit di sviluppo software S3 adattato. I dati dell'oggetto possono quindi essere trasferiti via RDMA anziché seguire il normale percorso dati TCP.

La disponibilità generale offre agli sviluppatori un punto di partenza supportato, ma NVIDIA persegue un obiettivo più ampio attraverso xio-sig. Il gruppo si sta espandendo dall'accesso ai file a quello agli oggetti, con attività separate pianificate per API client, protocollo wire e test di conformità.

Google Cloud sta valutando una partecipazione più ampia attorno a cuObject. Microsoft ha inoltre dichiarato di voler entrare nel consiglio di xio-sig. Il prototipo SCADA di IBM aggiunge un fornitore di storage al gruppo iniziale, sebbene un prototipo non equivalga al supporto in produzione.

La distinzione è centrale per questa vicenda. NVIDIA dispone ora di componenti scaricabili, documentazione e partner che discutono di interoperabilità. Non dispone ancora di uno standard maturo per lo storage a oggetti multi-vendor con diverse implementazioni in produzione già collaudate.

Questo rende la release al tempo stesso concreta e provvisoria. Gli sviluppatori possono iniziare a valutare le librerie già ora. La promessa più ampia dipende dall'adozione delle stesse interfacce da parte di piattaforme cloud, fornitori di storage, framework e sviluppatori di applicazioni.

Come NVIDIA cuObject separa controllo e dati

NVIDIA cuObject mantiene i messaggi di controllo in stile S3 su un percorso familiare, spostando al contempo i payload degli oggetti tramite RDMA.

L'architettura di cuObject divide ogni operazione in un piano di controllo e un piano dati. Le richieste S3 GET e PUT standard restano parte del flusso di controllo. Un SDK S3 adattato aggiunge metadati che descrivono il trasferimento RDMA.

Il payload dell'oggetto segue un percorso diverso. Il client registra una regione di memoria e crea un token RDMA contenente le informazioni necessarie al trasferimento. Il token viene allegato alla richiesta HTTP tramite un header personalizzato.

Il gateway di storage analizza la richiesta e indirizza un nodo dati appropriato a eseguire l'operazione. Quel nodo registra il proprio buffer locale attraverso le API server di cuObject. Quindi invia o riceve il payload tramite una scrittura o lettura RDMA.

Una risposta positiva del gateway completa la transazione di controllo al termine dell'operazione RDMA. Questa separazione consente all'applicazione di mantenere la semantica degli oggetti rimuovendo al contempo la CPU del server dal percorso principale del payload.

L'approccio punta a più della sola larghezza di banda. L'elaborazione della CPU può diventare un vincolo quando molti acceleratori generano operazioni di storage concorrenti. Evitare l'elaborazione TCP per ciascun payload può preservare capacità della CPU per metadati, coordinamento, sicurezza e altri servizi.

L'implementazione attuale utilizza il trasporto Dynamically Connected, comunemente chiamato DC. DC evita di mantenere una connessione affidabile tra ogni coppia di client e server di storage. Questa caratteristica è utile quando un grande cluster di calcolo raggiunge molti nodi di storage.

NVIDIA documenta il supporto DC su InfiniBand e RoCEv2. RoCEv2 trasporta il traffico RDMA su reti Ethernet configurate per supportare il comportamento richiesto. Entrambe le opzioni richiedono una pianificazione dell'infrastruttura che va oltre l'installazione di una libreria.

Il client non interagisce inoltre con un endpoint S3 invariato. La documentazione di NVIDIA afferma che l'integrazione richiede modifiche all'SDK S3 lato client e al software di storage lato server. Questi cambiamenti creano il percorso accelerato e scambiano metadati RDMA.

Le operazioni supportate includono GET, PUT, operazioni di upload multipart e letture di intervalli di byte. L'accesso per intervalli è rilevante quando un'applicazione necessita solo di una parte di un grande oggetto, anziché trasferire l'intero oggetto nella memoria GPU.

Questa architettura può eliminare un passaggio di staging comune. Le pipeline AI tradizionali spesso copiano i dati da un repository a oggetti in un file system scratch locale o distribuito. I nodi di calcolo leggono quindi da questo livello intermedio.

Lo staging può offrire prestazioni prevedibili, ma consuma capacità e aggiunge lavoro operativo. I team devono pianificare le copie, monitorare la sincronizzazione, eliminare i dati obsoleti e decidere quali dataset meritano storage veloce.

NVIDIA cuObject propone un percorso più diretto dall'object storage alla memoria dell'acceleratore. Se supportato end-to-end, un'applicazione può leggere dal proprio repository a oggetti principale senza prima crearne un'altra copia completa.

Questo vantaggio non elimina ogni operazione intermedia. I dati possono comunque richiedere decodifica, decompressione, convalida, batching o trasformazione. Il software di storage può inoltre utilizzare buffer interni prima di consegnare un payload tramite RDMA.

La release modifica quindi l'opportunità di trasporto, non l'intera pipeline dati. Le applicazioni devono ancora gestire formati, autorizzazioni di accesso, metadati degli oggetti e recupero dagli errori. I fornitori di storage devono collegare il percorso accelerato ai propri sistemi di posizionamento e durabilità.

NVIDIA cuObject funziona al meglio come livello di integrazione tra questi componenti. Non sostituisce l'object store, il piano di controllo S3, il data loader o il fabric di rete.

SCADA Server SDK sposta il controllo delle richieste verso le GPU

SCADA Server SDK affronta un diverso collo di bottiglia: molte piccole richieste il cui coordinamento può sovraccaricare una CPU prima che lo storage raggiunga i propri limiti.

I grandi trasferimenti sequenziali rendono la larghezza di banda la metrica più evidente. I job di training che leggono campioni o checkpoint di grandi dimensioni possono distribuire l'overhead delle richieste su ciascun trasferimento. Il lavoro di controllo diventa una parte minore dell'operazione complessiva.

I sistemi di inferenza e recupero dati generano un altro modello. Ricerca semantica, raccomandazioni, rilevamento delle frodi e memoria degli agenti possono produrre numerose ricerche più piccole. Una GPU può disporre di sufficiente lavoro parallelo per emettere queste operazioni con elevata concorrenza.

Il software di storage convenzionale si aspetta che una CPU costruisca, invii e completi queste richieste. Questo design diventa meno efficiente con la riduzione delle dimensioni delle richieste e l'aumento del numero di operazioni. I costi di elaborazione fissi assorbono una quota maggiore di ogni transazione.

SCADA consente ai client basati su GPU di avviare richieste di storage attraverso un'interfaccia comune. Il nuovo SDK offre ai fornitori di storage di terze parti un modo per creare server che ricevono tali richieste. Un server può soddisfarle dallo storage locale o remoto prima di restituire i dati tramite RDMA.

L'SDK non richiede a ogni sistema di storage di esporre direttamente alla GPU il proprio design interno. Un server SCADA funge invece da ponte tra un'interfaccia client condivisa e la logica di storage specifica del fornitore.

IBM ha dimostrato un server iniziale basato sull'SDK per IBM Storage Scale. In quel prototipo, un client SCADA invia richieste a un server realizzato da IBM. Il server collega il modello di richiesta comune a Storage Scale.

Questo è un primo segnale di interoperabilità, ma rimane limitato. NVIDIA non ha pubblicato risultati di produzione indipendenti per il prototipo IBM. L'annuncio non fornisce neppure misurazioni comparative di latenza, throughput o utilizzo della CPU.

SCADA include attività di supporto oltre al server SDK. NVIDIA ha pubblicato un Storage Lender Service per il provisioning dell'accesso alle code NVMe. Un'utilità a riga di comando è inoltre pensata per aiutare a configurare e distribuire i componenti SCADA.

L'iniziativa Storage-Next fornisce il contesto industriale più ampio. NVIDIA afferma che il gruppo include oltre 40 fornitori e clienti nei settori flash, controller, sistemi di storage, infrastruttura cloud e sviluppo applicativo.

Il gruppo sta cercando di definire il comportamento dello storage guidato dalle GPU. Il suo lavoro affronta sia grandi spostamenti di dati sia operazioni piccole e granulari. L'obiettivo è trasformare la collaborazione tra fornitori in interfacce e standard interoperabili.

La tempistica riflette l'evoluzione dei modelli di accesso ai dati nell'AI. Il training rimane importante, ma l'inferenza in produzione introduce recupero del contesto, chiamate a strumenti, ricerche nei database e memoria persistente. Ogni richiesta utente può attivare diverse operazioni dati a valle.

Un servizio a contesto lungo crea inoltre pressione al di fuori della memoria GPU. I dati della cache chiave-valore registrano lo stato di attenzione dei token elaborati in precedenza. Quando questo stato non può restare nella memoria dell'acceleratore, i sistemi necessitano di un altro livello in grado di restituirlo in modo efficiente.

Lo storage è più economico e capiente della memoria dell'acceleratore, ma presenta caratteristiche di latenza diverse. SCADA tenta di consentire alle GPU di tollerare questo divario attraverso il parallelismo. Molti thread GPU possono mantenere le operazioni in corso invece di attendere una sequenza di richieste guidata dalla CPU.

L'idea è complementare a cuObject, non una sua sostituzione. NVIDIA cuObject si concentra sull'accesso accelerato allo storage a oggetti compatibile con S3. SCADA si concentra sull'accesso granulare avviato dalla GPU attraverso implementazioni di storage.

Insieme, estendono l'influenza di NVIDIA dal calcolo ai protocolli che collegano acceleratori e dati archiviati. Questa espansione crea la principale pressione competitiva alla base dell'annuncio.

Le interfacce aperte competono con l'accelerazione specifica del provider

La sfida principale è tra interfacce condivise per acceleratori e storage e integrazioni separate realizzate per ciascun provider cloud o di storage.

Lo storage a oggetti su RDMA non dispone di un protocollo wire comune ampiamente adottato. Uno sviluppatore che cerchi l'accesso diretto alla GPU può affidarsi ai tradizionali trasferimenti S3, usare un file system intermedio oppure sviluppare attorno a un percorso accelerato specifico di un provider.

Ogni opzione impone un costo diverso. L'accesso tradizionale preserva la compatibilità, ma mantiene l'overhead di CPU e TCP. Lo staging può migliorare la località duplicando però i dati. Un'integrazione specifica del provider può offrire buone prestazioni, ma crea un'ulteriore dipendenza.

NVIDIA vuole che xio-sig riduca questa frammentazione. L'organizzazione xio-sig descrive iniziative cuObject separate per un'API client, un protocollo wire accelerato e una suite di conformità. La stessa organizzazione ospita anche lavori correlati su cuFile.

La conformità è cruciale perché pubblicare un'interfaccia non garantisce un comportamento compatibile. Le implementazioni devono concordare su semantica delle richieste, registrazione della memoria, gestione degli errori, confini di sicurezza e comportamento di fallback. Devono inoltre comportarsi in modo coerente in caso di guasti e concorrenza.

Al momento della pubblicazione, l'organizzazione pubblica afferma che il codice apparirà dopo che i partecipanti fondatori avranno integrato e convalidato i livelli. La relativa pagina di stato afferma inoltre che gli stack devono superare test di conformità prima che tale pubblicazione avvenga.

Ciò lascia un divario significativo tra l'annuncio di NVIDIA e il livello di interoperabilità completato. La struttura dei repository esiste e i componenti previsti sono stati denominati. Gran parte dell'implementazione pronta per la produzione è ancora in attesa di rilascio pubblico.

Google Cloud e Microsoft apportano una credibilità importante, poiché i provider cloud gestiscono grandi piattaforme di storage a oggetti. La loro partecipazione verifica inoltre se xio-sig possa accogliere infrastrutture non controllate da NVIDIA.

Tuttavia, i partner hanno assunto impegni diversi. Google Cloud sta valutando una partecipazione più ampia a cuObject. Microsoft ha indicato l'intenzione di entrare nel consiglio di amministrazione. Nessuna delle due dichiarazioni, da sola, conferma la disponibilità generale per i clienti nei rispettivi servizi a oggetti.

Il prototipo di IBM offre un'implementazione più concreta, ma riguarda SCADA e Storage Scale. Non dimostra che varie piattaforme indipendenti compatibili con S3 possano scambiare traffico cuObject attraverso un unico protocollo testato in produzione.

Anche le aziende di storage hanno ragioni per preservare i propri metodi di accelerazione. I percorsi specifici del fornitore possono offrire caching, posizionamento, sicurezza o servizi dati differenziati. Un protocollo condiviso deve restare abbastanza ampio da consentire l'interoperabilità senza eliminare tali funzionalità.

NVIDIA ha un proprio interesse strategico. Un percorso comune dallo storage alla memoria GPU può rendere gli acceleratori NVIDIA più facili da usare con dataset più grandi. Può anche integrare prodotti di networking, DPU, software CUDA e partner di storage in un'architettura coordinata.

Ciò non rende intrinsecamente chiusa l'iniziativa per l'interoperabilità. L'organizzazione pubblicata utilizza una licenza Apache-2.0 per il repository attuale e il lavoro di conformità può ridurre il rischio di integrazione. Tuttavia, i dettagli di governance e implementazione determineranno quanto aperto sarà il risultato.

Altri fornitori di acceleratori costituiscono un ulteriore banco di prova. Nel descrivere la domanda di calcolo, il post di NVIDIA fa riferimento a GPU, TPU e XPU. Un'interfaccia di storage realmente portabile non dovrebbe dipendere da un'unica architettura di acceleratore a ogni livello.

L'evidenza più chiara arriverà da implementazioni non NVIDIA che superino test condivisi. Anche il supporto all'interno di framework comuni sarebbe importante. Agli sviluppatori interessa meno l'appartenenza organizzativa rispetto alla possibilità che un'applicazione esistente possa cambiare backend senza una riscrittura.

Per gli acquirenti di storage, la questione pratica è la portabilità. Un'interfaccia ha valore quando preserva il comportamento dell'applicazione tra diversi prodotti supportati. Un singolo percorso rapido legato a una combinazione convalidata resta un'integrazione, non uno standard di settore.

La disponibilità generale non elimina il rischio di distribuzione

Le librerie sono disponibili, ma l'adozione in produzione richiede ancora reti specializzate, software modificato, un'attenta gestione della memoria e benchmark credibili.

Le note di rilascio di cuObject mostrano che il client ha raggiunto la versione 1.3.0 nell'agosto 2026. Le versioni precedenti hanno aggiunto failover multipath, failback e supporto IPv6. La versione 1.3.0 ha aggiunto un metodo per invalidare token RDMA obsoleti.

Queste aggiunte affrontano questioni operative, ma la stessa documentazione elenca limitazioni importanti. Una singola chiamata di registrazione della memoria ha un limite massimo inferiore a 4 GiB. Le operazioni GET e PUT concorrenti non sono supportate sullo stesso buffer registrato.

I trasferimenti dalla memoria host richiedono buffer registrati. Alcuni comportamenti di configurazione differiscono da cuFile, inclusa l'assenza di un pool di thread per l'emissione di I/O cuObject. Le applicazioni devono comprendere questi vincoli prima di adottare il percorso.

I cicli di vita della memoria richiedono particolare attenzione. Un client non deve riutilizzare o deregistrare un buffer mentre un'operazione è ancora in sospeso. La gestione degli errori deve inoltre impedire alle richieste obsolete di accedere a una regione di memoria dopo il riutilizzo della sua chiave.

Questi requisiti non sono insoliti per il software RDMA ad alte prestazioni. Tuttavia, spostano la responsabilità verso gli sviluppatori di applicazioni, framework e storage. Un'integrazione errata può produrre guasti difficili da diagnosticare.

Anche la rete è importante. Il trasporto DC su InfiniBand o RoCEv2 presuppone adattatori, switch, routing e configurazione adeguati. Le organizzazioni non possono aspettarsi che il percorso accelerato compaia su una rete ordinaria senza interventi sull'infrastruttura.

Le distribuzioni RoCE possono essere sensibili alla congestione e alla progettazione del fabric. Il comportamento multipath, il recupero dai guasti e la telemetria devono essere testati con traffico realistico. Un trasferimento riuscito in laboratorio non dimostra prestazioni prevedibili a livello dell'intero cluster.

La sicurezza merita altrettanta attenzione. Lo spostamento diretto dei dati riduce il coinvolgimento della CPU nel percorso del payload, ma non può aggirare l'autorizzazione. I sistemi necessitano comunque di un livello di controllo affidabile che decida quale processo possa accedere a ciascuna regione registrata e oggetto archiviato.

NVIDIA descrive SCADA come una separazione tra lavoro applicativo non privilegiato e un componente di configurazione privilegiato. Questa struttura può proteggere il percorso dati se implementata correttamente. I provider di storage devono comunque collegarla a isolamento dei tenant, auditing, gestione delle credenziali e revoca.

L'annuncio non contiene benchmark standardizzati che confrontino cuObject con S3 convenzionale, accesso a file in staging o alternative specifiche del provider. Inoltre, non quantifica i guadagni per il prototipo IBM.

Questa omissione impedisce conclusioni generali sulle prestazioni. RDMA può ridurre copie ed elaborazione della CPU, ma i risultati delle applicazioni dipendono da dimensioni degli oggetti, schemi di accesso, supporti di storage, topologia di rete, concorrenza e preelaborazione.

Le grandi letture sequenziali possono già offrire prestazioni adeguate tramite file system ottimizzati. Richieste molto piccole possono evidenziare limiti altrove, inclusi livelli di traduzione flash, servizi di metadati o sincronizzazione dell'applicazione.

L'analisi indipendente sullo storage relativa a SCADA sottolinea questa distinzione. I trasferimenti in blocco e le letture granulari impongono requisiti diversi, quindi nessun singolo dato di throughput di riferimento può descrivere entrambi.

Gli sviluppatori dovrebbero quindi considerare NVIDIA cuObject come un percorso da valutare, non come un risultato prestazionale garantito. I test dovrebbero usare dimensioni reali degli oggetti, concorrenza rappresentativa, trasformazioni esistenti e scenari di guasto previsti.

Una prova di concetto credibile dovrebbe misurare più della larghezza di banda. Dovrebbe monitorare latenza di coda, consumo della CPU del server, utilizzo della GPU, overhead di registrazione della memoria, tempo di ripristino e comportamento quando il percorso RDMA diventa indisponibile.

I team dovrebbero anche verificare il comportamento di fallback. Un'applicazione di produzione necessita di una risposta definita quando un server non supporta RDMA o un componente del fabric si guasta. La compatibilità con l'accesso ordinario agli oggetti può essere importante quanto le prestazioni accelerate di picco.

Lo scetticismo più forte riguarda l'adozione, piuttosto che la possibilità tecnica. NVIDIA ha dimostrato che i componenti possono essere realizzati. Non ha ancora dimostrato che un'ampia gamma di provider manterrà implementazioni compatibili per diversi cicli di rilascio.

Cosa osservare dopo il rilascio dell'SDK NVIDIA SCADA Server

Tre segnali mostreranno se NVIDIA cuObject diventerà un'infrastruttura condivisa o resterà un insieme di integrazioni partner ottimizzate.

Il primo segnale è il codice xio-sig pubblico accompagnato da test di conformità funzionanti. L'organizzazione ha identificato repository per l'API client cuObject, il protocollo wire e la suite di conformità. Tali repository necessitano di implementazioni sostanziali, non soltanto di descrizioni delle interfacce.

Il superamento dei test tra client e server mantenuti in modo indipendente rafforzerebbe la tesi di interoperabilità di NVIDIA. Ritardi, copertura dei test limitata o dipendenze da una sola combinazione hardware la indebolirebbero.

Il secondo segnale è il supporto in produzione da parte di provider cloud e storage. La valutazione di Google Cloud e la prevista partecipazione di Microsoft al consiglio sono significative, ma la disponibilità rivolta ai clienti sarebbe più importante.

Gli acquirenti dovrebbero cercare combinazioni di servizi supportate, requisiti di distribuzione documentati e chiare matrici di compatibilità. Ulteriori implementazioni di server SCADA oltre IBM Storage Scale verificherebbero inoltre se l'SDK si generalizza tra diversi design di storage.

Il terzo segnale è costituito da evidenze specifiche per i carichi di lavoro. I fornitori devono pubblicare risultati riproducibili per ingestione di addestramento, operazioni di checkpoint, recupero, ricerca semantica e accesso alla cache di inferenza. Tali test dovrebbero confrontare trasferimenti standard di oggetti, workflow di staging e percorsi abilitati a RDMA.

I risultati dovrebbero includere consumo della CPU e latenza di coda, non solo il throughput di picco. Dovrebbero inoltre indicare dimensioni degli oggetti, configurazione della rete, supporti di storage e comportamento in caso di guasto. Senza questo contesto, i dati sulle prestazioni saranno difficili da applicare.

Gli sviluppatori non devono attendere prima di studiare l'architettura. Possono identificare dove le loro applicazioni effettuano lo staging dei dati degli oggetti, profilare il tempo CPU nei trasferimenti di storage e misurare la distribuzione delle dimensioni delle richieste. Questo lavoro rivela se cuObject o SCADA affrontino un vero collo di bottiglia.

La domanda finale non è se RDMA possa spostare i dati più velocemente. È se vari provider possano esporre un percorso affidabile senza intrappolare le applicazioni in uno stack ristretto. Osservate i repository di conformità, i prodotti dei fornitori supportati e i test riproducibili dei carichi di lavoro. Questi segnali determineranno se NVIDIA cuObject diventerà un livello di storage AI portabile o un'altra opzione di accelerazione specializzata.