NVIDIA cuObject amplia o armazenamento de IA além dos arquivos, mas a interoperabilidade ainda está incompleta
A NVIDIA disponibilizou de forma geral as bibliotecas de cliente e servidor cuObject em 30 de setembro, ampliando o acesso acelerado ao armazenamento para IA além dos sistemas de arquivos convencionais. O lançamento do NVIDIA cuObject adiciona APIs padronizadas e um protocolo de comunicação RDMA para mover dados de objetos sem encaminhar as cargas úteis pela CPU de um servidor.
A empresa também apresentou um SCADA Server SDK para processar solicitações de armazenamento iniciadas por GPUs. SCADA significa Scaled Accelerated Data Access, uma estrutura projetada para grandes volumes de operações de armazenamento granulares. A IBM já desenvolveu um protótipo inicial do Storage Scale com o SDK.
O anúncio mira uma divisão persistente na infraestrutura de IA. O armazenamento de objetos oferece capacidade e interfaces compatíveis com S3 já conhecidas, enquanto pipelines de treinamento e inferência de alto desempenho frequentemente dependem de sistemas de arquivos mais rápidos ou de armazenamento temporário local. A NVIDIA quer que o cuObject reduza essa divisão, mas seu plano mais amplo de interoperabilidade continua incompleto.
NVIDIA cuObject deixa de ser uma biblioteca de produto para se tornar uma proposta para o setor
A mudança importante não é apenas que a NVIDIA lançou outra biblioteca de armazenamento. Ela está pedindo que provedores de nuvem e armazenamento converjam para um protocolo comum de objetos acelerados.
De acordo com o anúncio da NVIDIA, as bibliotecas de cliente e servidor cuObject agora estão disponíveis de forma geral. A NVIDIA também lançou o cuObject Server 2.0.0 para provedores de armazenamento que estejam avaliando a integração do lado do servidor.
A biblioteca de cliente fica dentro de uma aplicação de GPU, carregador de dados ou camada de middleware. Ela conecta operações de objetos no nível da aplicação a um caminho de dados RDMA. O acesso remoto direto à memória, ou RDMA, permite que o hardware de rede transfira dados diretamente entre regiões de memória registradas.
A biblioteca de servidor integra-se a um serviço de armazenamento de objetos. Ela gerencia buffers registrados e realiza as operações RDMA que movem dados de ou para o cliente. O sistema pode direcionar os dados para a memória da GPU ou para a memória do sistema.
Esse design aborda um problema que o GPUDirect Storage não resolveu completamente. O GPUDirect Storage já fornecia um caminho direto entre o armazenamento e a memória da GPU, mas sua interface mais conhecida, cuFile, era centrada no acesso a arquivos. Muitos conjuntos de dados de IA, por sua vez, ficam atrás de interfaces de objetos.
Essa diferença importa para organizações que mantêm amostras de treinamento, documentos, imagens, checkpoints e artefatos gerados em repositórios compatíveis com S3. Esses sistemas são atraentes porque escalam em grandes espaços de nomes e separam o armazenamento da computação. No entanto, o acesso convencional a objetos normalmente passa por uma pilha TCP e buffers gerenciados pela CPU.
O NVIDIA cuObject mantém operações de controle orientadas a objetos enquanto altera o caminho da carga útil. Um cliente ainda pode emitir solicitações familiares de GET ou PUT por meio de um kit de desenvolvimento de software S3 adaptado. Os dados do objeto podem então ser movidos via RDMA, em vez de seguir o caminho de dados TCP comum.
A disponibilidade geral oferece aos desenvolvedores um ponto de partida com suporte, mas a NVIDIA busca um objetivo mais amplo por meio do xio-sig. O grupo está se expandindo do acesso a arquivos para o acesso a objetos, com trabalhos separados planejados para APIs de cliente, um protocolo de comunicação e testes de conformidade.
O Google Cloud está avaliando uma participação ampliada em torno do cuObject. A Microsoft também afirmou que planeja se juntar ao conselho do xio-sig. O protótipo SCADA da IBM adiciona um fornecedor de armazenamento ao grupo inicial, embora um protótipo não seja equivalente ao suporte em produção.
A distinção é central para a história. A NVIDIA agora tem componentes para download, documentação e parceiros discutindo interoperabilidade. Ela ainda não tem um padrão maduro de armazenamento de objetos multi-fornecedor, com diversas implementações comprovadas em produção.
Isso torna o lançamento ao mesmo tempo concreto e provisório. Os desenvolvedores podem começar a avaliar as bibliotecas agora. A promessa maior depende de plataformas de nuvem, fornecedores de armazenamento, frameworks e desenvolvedores de aplicações adotarem as mesmas interfaces.
Como o NVIDIA cuObject separa controle e dados
O NVIDIA cuObject mantém mensagens de controle no estilo S3 em um caminho familiar, enquanto move as cargas úteis dos objetos por RDMA.
A arquitetura do cuObject divide cada operação em um plano de controle e um plano de dados. As solicitações padrão de GET e PUT do S3 permanecem parte do fluxo de controle. Um SDK S3 adaptado adiciona metadados que descrevem a transferência RDMA.
A carga útil do objeto segue uma rota diferente. O cliente registra uma região de memória e cria um token RDMA contendo as informações necessárias para a transferência. Esse token é anexado à solicitação HTTP por meio de um cabeçalho personalizado.
O gateway de armazenamento analisa a solicitação e orienta um nó de dados apropriado a realizar a operação. Esse nó registra seu buffer local por meio das APIs de servidor cuObject. Em seguida, ele envia ou obtém a carga útil usando uma gravação ou leitura RDMA.
Uma resposta bem-sucedida do gateway conclui a transação de controle após a operação RDMA terminar. Essa separação permite que a aplicação mantenha a semântica de objetos enquanto remove a CPU do servidor do caminho principal da carga útil.
A abordagem busca mais do que largura de banda bruta. O processamento pela CPU pode se tornar uma limitação quando muitos aceleradores geram operações simultâneas de armazenamento. Evitar o processamento TCP para cada carga útil pode preservar a capacidade da CPU para metadados, coordenação, segurança e outros serviços.
A implementação atual usa o transporte Dynamically Connected, normalmente chamado de DC. O DC evita manter uma conexão confiável entre cada par de cliente e servidor de armazenamento. Essa característica é útil quando um grande cluster de computação alcança muitos nós de armazenamento.
A NVIDIA documenta suporte a DC via InfiniBand e RoCEv2. O RoCEv2 transporta tráfego RDMA por redes Ethernet configuradas para suportar o comportamento exigido. Ambas as opções exigem planejamento de infraestrutura que vai além de instalar uma biblioteca.
O cliente também não interage com um endpoint S3 inalterado. A documentação da NVIDIA afirma que a integração exige modificações no SDK S3 do lado do cliente e no software de armazenamento do lado do servidor. Essas mudanças criam o caminho acelerado e trocam metadados RDMA.
As operações compatíveis incluem GET, PUT, operações de upload multipartes e leituras de intervalos de bytes. O acesso por intervalo é relevante quando uma aplicação precisa apenas de parte de um objeto grande, em vez de transferir o objeto inteiro para a memória da GPU.
Essa arquitetura pode eliminar uma etapa comum de preparação. Pipelines tradicionais de IA frequentemente copiam dados de um repositório de objetos para um sistema de arquivos temporário local ou distribuído. Os nós de computação então leem dessa camada intermediária.
A preparação pode fornecer desempenho previsível, mas consome capacidade e adiciona trabalho operacional. As equipes precisam agendar cópias, monitorar a sincronização, limpar dados obsoletos e decidir quais conjuntos de dados merecem armazenamento rápido.
O NVIDIA cuObject propõe um caminho mais direto do armazenamento de objetos para a memória do acelerador. Se houver suporte de ponta a ponta, uma aplicação poderá ler de seu repositório principal de objetos sem antes criar outra cópia completa.
Esse benefício não elimina todas as operações intermediárias. Os dados ainda podem exigir decodificação, descompressão, validação, criação de lotes ou transformação. O software de armazenamento também pode usar buffers internos antes de entregar uma carga útil via RDMA.
Portanto, o lançamento altera a oportunidade de transporte, não todo o pipeline de dados. As aplicações ainda precisam gerenciar formatos, permissões de acesso, metadados de objetos e recuperação de falhas. Os fornecedores de armazenamento precisam conectar o caminho acelerado aos seus próprios sistemas de posicionamento e durabilidade.
O NVIDIA cuObject funciona melhor como uma camada de integração entre esses componentes. Ele não substitui o armazenamento de objetos, o plano de controle S3, o carregador de dados nem a infraestrutura de rede.
O SCADA Server SDK transfere o controle de solicitações para mais perto das GPUs
O SCADA Server SDK aborda outro gargalo: muitas solicitações pequenas cuja coordenação pode sobrecarregar uma CPU antes que o armazenamento atinja seus limites.
Grandes transferências sequenciais tornam a largura de banda a métrica mais evidente. Trabalhos de treinamento que leem amostras ou checkpoints volumosos podem amortizar a sobrecarga das solicitações em cada transferência. O trabalho de controle passa a representar uma parcela menor da operação total.
Sistemas de inferência e recuperação criam outro padrão. Busca semântica, recomendação, detecção de fraudes e memória de agentes podem gerar muitas consultas menores. Uma GPU pode ter trabalho paralelo suficiente para emitir essas operações com alta concorrência.
O software de armazenamento convencional espera que uma CPU construa, envie e conclua essas solicitações. Esse design se torna menos eficiente à medida que os tamanhos das solicitações diminuem e a quantidade de operações aumenta. Custos fixos de processamento consomem uma parcela maior de cada transação.
O SCADA permite que clientes baseados em GPU iniciem solicitações de armazenamento por meio de uma interface comum. O novo SDK oferece a provedores terceirizados de armazenamento uma forma de criar servidores que recebem essas solicitações. Um servidor pode atendê-las a partir de armazenamento local ou remoto antes de devolver dados via RDMA.
O SDK não exige que todos os sistemas de armazenamento exponham diretamente à GPU seu design interno. Em vez disso, um servidor SCADA atua como ponte entre uma interface de cliente compartilhada e a lógica de armazenamento específica de cada fornecedor.
A IBM demonstrou um servidor inicial baseado no SDK para o IBM Storage Scale. Nesse protótipo, um cliente SCADA envia solicitações a um servidor desenvolvido pela IBM. O servidor conecta o modelo comum de solicitações ao Storage Scale.
Esse é um sinal inicial de interoperabilidade, mas continua limitado. A NVIDIA não publicou resultados independentes de produção para o protótipo da IBM. O anúncio também não fornece medições comparativas de latência, throughput ou utilização de CPU.
O SCADA inclui trabalhos de suporte além do SDK de servidor. A NVIDIA publicou um Storage Lender Service para provisionar acesso a filas NVMe. Um utilitário de linha de comando também se destina a ajudar a configurar e implantar componentes SCADA.
A iniciativa Storage-Next fornece o contexto mais amplo do setor. A NVIDIA afirma que o grupo inclui mais de 40 fornecedores e clientes de flash, controladores, sistemas de armazenamento, infraestrutura de nuvem e desenvolvimento de aplicações.
Esse grupo está tentando definir como o armazenamento orientado por GPU deve se comportar. Seu trabalho abrange tanto a movimentação de grandes volumes de dados quanto operações pequenas e granulares. O objetivo é transformar a colaboração entre fornecedores em interfaces e padrões interoperáveis.
O momento reflete a mudança nos padrões de acesso a dados de IA. O treinamento continua importante, mas a inferência em produção introduz recuperação de contexto, chamadas de ferramentas, consultas a bancos de dados e memória persistente. Cada solicitação de usuário pode acionar várias operações de dados subsequentes.
Um serviço de contexto longo também pressiona recursos fora da memória da GPU. Os dados do cache de chave-valor registram o estado de atenção de tokens processados anteriormente. Quando esse estado não pode permanecer na memória do acelerador, os sistemas precisam de outra camada capaz de devolvê-lo com eficiência.
O armazenamento é mais barato e tem maior capacidade do que a memória do acelerador, mas possui características de latência diferentes. O SCADA tenta permitir que as GPUs tolerem essa diferença por meio do paralelismo. Muitas threads de GPU podem manter operações em andamento, em vez de aguardar uma sequência de solicitações conduzida pela CPU.
A ideia complementa o cuObject, em vez de substituí-lo. O NVIDIA cuObject se concentra no acesso acelerado ao armazenamento de objetos compatível com S3. O SCADA se concentra no acesso granular iniciado por GPU em diferentes implementações de armazenamento.
Juntas, amplían la influencia de NVIDIA desde la computación hacia los protocolos que conectan aceleradores y datos almacenados. Esa expansión genera la principal presión competitiva detrás del anuncio.
Las interfaces abiertas compiten con la aceleración específica de cada proveedor
La competencia principal se da entre interfaces compartidas de acelerador y almacenamiento, e integraciones independientes diseñadas para cada proveedor de nube o almacenamiento.
El almacenamiento de objetos mediante RDMA ha carecido de un protocolo común de comunicación ampliamente adoptado. Un desarrollador que buscara acceso directo a la GPU podía depender de transferencias S3 tradicionales, utilizar un sistema de archivos intermedio o desarrollar en torno a la ruta acelerada de un proveedor específico.
Cada opción impone un coste distinto. El acceso tradicional mantiene la compatibilidad, pero conserva la sobrecarga de CPU y TCP. El almacenamiento intermedio puede mejorar la proximidad de los datos, aunque los duplica. Una integración específica de un proveedor puede ofrecer buen rendimiento, pero crea otra dependencia.
NVIDIA quiere que xio-sig reduzca esa fragmentación. La organización xio-sig describe iniciativas independientes de cuObject para una API de cliente, un protocolo de comunicación acelerado y una suite de conformidad. La misma organización también alberga trabajo relacionado con cuFile.
La conformidad es fundamental, porque publicar una interfaz no garantiza un comportamiento compatible. Las implementaciones deben coincidir en la semántica de las solicitudes, el registro de memoria, el manejo de errores, los límites de seguridad y el comportamiento de respaldo. También deben comportarse de forma coherente ante fallos y concurrencia.
En el momento de la publicación, la organización pública indica que el código aparecerá después de que los participantes fundadores integren y validen las capas. Su página de estado también señala que las pilas deben superar pruebas de conformidad antes de que se produzca esa publicación.
Esto deja una brecha relevante entre el anuncio de NVIDIA y la capa de interoperabilidad terminada. La estructura de los repositorios existe y los componentes previstos están identificados. Gran parte de la implementación lista para producción sigue pendiente de publicación pública.
Google Cloud y Microsoft aportan una credibilidad importante porque los proveedores de nube operan grandes plataformas de almacenamiento de objetos. Su participación también pone a prueba si xio-sig puede adaptarse a una infraestructura no controlada por NVIDIA.
Sin embargo, los socios han asumido compromisos diferentes. Google Cloud está evaluando una participación más amplia en cuObject. Microsoft ha indicado su intención de unirse al consejo. Ninguna de estas declaraciones confirma por sí sola la disponibilidad general para clientes en sus servicios de objetos.
El prototipo de IBM ofrece una implementación más tangible, pero se refiere a SCADA y Storage Scale. No demuestra que varias plataformas independientes compatibles con S3 puedan intercambiar tráfico cuObject mediante un único protocolo probado en producción.
Las empresas de almacenamiento también tienen motivos para preservar sus propios métodos de aceleración. Las rutas específicas de cada proveedor pueden exponer funciones diferenciadas de caché, ubicación, seguridad o servicios de datos. Un protocolo compartido debe seguir siendo lo bastante amplio para permitir la interoperabilidad sin eliminar esas capacidades.
NVIDIA tiene su propio interés estratégico. Una ruta común desde el almacenamiento hasta la memoria de la GPU puede facilitar el uso de los aceleradores de NVIDIA con conjuntos de datos más grandes. También puede integrar productos de redes, DPU, software CUDA y socios de almacenamiento en una arquitectura coordinada.
Eso no convierte de forma inherente el impulso de interoperabilidad en algo cerrado. La organización publicada utiliza una licencia Apache-2.0 para su repositorio actual, y el trabajo de conformidad puede reducir el riesgo de integración. Sin embargo, los detalles de gobernanza e implementación determinarán cuán abierto será el resultado.
Otros proveedores de aceleradores plantean otra prueba. La publicación de NVIDIA se refiere a GPU, TPU y XPU al describir la demanda de computación. Una interfaz de almacenamiento realmente portátil no debería depender de una sola arquitectura de acelerador en todas las capas.
La evidencia más clara procederá de implementaciones ajenas a NVIDIA que superen pruebas compartidas. El soporte en marcos de trabajo comunes también sería importante. A los desarrolladores les importa menos la membresía organizativa que la posibilidad de que una aplicación existente pueda cambiar de backend sin reescribirse.
Para los compradores de almacenamiento, la cuestión práctica es la portabilidad. Una interfaz tiene valor cuando mantiene el comportamiento de las aplicaciones entre varios productos compatibles. Una ruta rápida ligada a una combinación validada sigue siendo una integración, no un estándar industrial.
La disponibilidad general no elimina el riesgo de despliegue
Las bibliotecas están disponibles, pero la adopción en producción sigue requiriendo redes especializadas, software modificado, una gestión cuidadosa de la memoria y benchmarks creíbles.
Las notas de lanzamiento de cuObject muestran que el cliente alcanzó la versión 1.3.0 en agosto de 2026. Las versiones anteriores añadieron conmutación por error multipath, recuperación tras conmutación e IPv6. La versión 1.3.0 incorporó un método para invalidar tokens RDMA obsoletos.
Estas incorporaciones abordan preocupaciones operativas, pero la misma documentación enumera limitaciones importantes. Una única llamada de registro de memoria tiene un máximo inferior a 4 GiB. No se admiten operaciones GET y PUT simultáneas en el mismo búfer registrado.
Las transferencias de memoria de host requieren búferes registrados. Parte del comportamiento de configuración difiere de cuFile, incluida la ausencia de un grupo de hilos para emitir E/S de cuObject. Las aplicaciones deben entender estas restricciones antes de adoptar esta ruta.
Los ciclos de vida de la memoria exigen un cuidado especial. Un cliente no debe reutilizar ni cancelar el registro de un búfer mientras una operación siga pendiente. El manejo de errores también debe impedir que solicitudes obsoletas accedan a una región de memoria después de que se reutilice su clave.
Estos requisitos no son inusuales en software RDMA de alto rendimiento. Aun así, desplazan la responsabilidad hacia desarrolladores de aplicaciones, frameworks y almacenamiento. Una integración incorrecta puede producir fallos difíciles de diagnosticar.
La red también importa. El transporte DC mediante InfiniBand o RoCEv2 presupone adaptadores, switches, enrutamiento y configuración adecuados. Las organizaciones no pueden esperar que la ruta acelerada aparezca en una red ordinaria sin trabajo de infraestructura.
Los despliegues de RoCE pueden ser sensibles a la congestión y al diseño del tejido de red. El comportamiento multipath, la recuperación ante fallos y la telemetría deben probarse con tráfico realista. Una transferencia satisfactoria en laboratorio no demuestra un rendimiento predecible en todo el clúster.
La seguridad merece la misma atención. El movimiento directo de datos reduce la participación de la CPU en la ruta de carga útil, pero no puede eludir la autorización. Los sistemas siguen necesitando una capa de control de confianza que determine qué proceso puede acceder a cada región registrada y objeto almacenado.
NVIDIA describe SCADA como una separación entre el trabajo de aplicaciones sin privilegios y un componente privilegiado de configuración. Esa estructura puede proteger la ruta de datos si se implementa correctamente. Los proveedores de almacenamiento aún deben conectarla con aislamiento de inquilinos, auditoría, gestión de credenciales y revocación.
El anuncio no contiene un benchmark estandarizado que compare cuObject con S3 convencional, acceso a archivos por etapas o alternativas específicas de proveedores. Tampoco cuantifica las mejoras del prototipo de IBM.
Esta omisión impide extraer conclusiones amplias sobre rendimiento. RDMA puede reducir copias y procesamiento de CPU, pero los resultados de las aplicaciones dependen del tamaño de los objetos, los patrones de acceso, los medios de almacenamiento, la topología de red, la concurrencia y el preprocesamiento.
Las lecturas secuenciales grandes pueden funcionar ya adecuadamente mediante sistemas de archivos optimizados. Las solicitudes muy pequeñas pueden revelar limitaciones en otros puntos, incluidas las capas de traducción flash, los servicios de metadatos o la sincronización de aplicaciones.
El análisis independiente de almacenamiento sobre SCADA enfatiza esa distinción. Las transferencias masivas y las lecturas detalladas imponen requisitos distintos, por lo que ninguna cifra única de rendimiento máximo puede describir ambas.
Por tanto, los desarrolladores deberían tratar NVIDIA cuObject como una ruta que evaluar, no como un resultado de rendimiento garantizado. Las pruebas deberían utilizar tamaños de objetos reales, concurrencia representativa, transformaciones existentes y escenarios de fallo previstos.
Una prueba de concepto creíble debería medir más que el ancho de banda. Debería registrar la latencia de cola, el consumo de CPU del servidor, la utilización de la GPU, la sobrecarga de registro de memoria, el tiempo de recuperación y el comportamiento cuando la ruta RDMA deja de estar disponible.
Los equipos también deberían verificar el comportamiento de respaldo. Una aplicación de producción necesita una respuesta definida cuando un servidor no admite RDMA o falla un componente del tejido de red. La compatibilidad con el acceso ordinario a objetos puede ser tan importante como el rendimiento acelerado máximo.
El mayor escepticismo se refiere a la adopción, más que a la posibilidad técnica. NVIDIA ha demostrado que los componentes pueden construirse. Aún no ha demostrado que una amplia variedad de proveedores mantenga implementaciones compatibles durante varios ciclos de lanzamiento.
Qué observar después del lanzamiento del SDK de servidor NVIDIA SCADA
Tres señales mostrarán si NVIDIA cuObject se convierte en infraestructura compartida o sigue siendo un conjunto de integraciones optimizadas de socios.
La primera señal es código público de xio-sig acompañado de pruebas de conformidad funcionales. La organización ha identificado repositorios para la API de cliente de cuObject, el protocolo de comunicación y la suite de conformidad. Esos repositorios necesitan implementaciones sustanciales, no solo descripciones de interfaces.
Superar pruebas entre clientes y servidores mantenidos de forma independiente reforzaría la afirmación de interoperabilidad de NVIDIA. Retrasos, una cobertura de pruebas limitada o dependencias de una sola combinación de hardware la debilitarían.
La segunda señal es el soporte de producción de proveedores de nube y almacenamiento. La evaluación de Google Cloud y la participación prevista de Microsoft en el consejo son significativas, pero la disponibilidad orientada al cliente importaría más.
Los compradores deberían buscar combinaciones de servicios compatibles, requisitos de despliegue documentados y matrices de compatibilidad claras. Más implementaciones de servidores SCADA, además de IBM Storage Scale, también pondrían a prueba si el SDK se generaliza entre distintos diseños de almacenamiento.
La tercera señal es la evidencia específica de cada carga de trabajo. Los proveedores deben publicar resultados reproducibles para la ingesta de entrenamiento, operaciones de checkpoint, recuperación, búsqueda semántica y acceso a caché de inferencia. Estas pruebas deberían comparar transferencias de objetos estándar, flujos de trabajo de almacenamiento intermedio y rutas habilitadas para RDMA.
Los resultados deberían incluir consumo de CPU y latencia de cola, no solo rendimiento máximo. También deberían revelar tamaños de objetos, configuración de red, medios de almacenamiento y comportamiento ante fallos. Sin ese contexto, será difícil aplicar las cifras de rendimiento.
Los desarrolladores no tienen que esperar antes de estudiar la arquitectura. Pueden identificar dónde sus aplicaciones almacenan datos de objetos por etapas, perfilar el tiempo de CPU en transferencias de almacenamiento y medir la distribución de tamaños de solicitud. Este trabajo revela si cuObject o SCADA aborda un cuello de botella real.
La pregunta final no es si RDMA puede mover datos más rápido. Es si varios proveedores pueden ofrecer una ruta fiable sin atrapar las aplicaciones dentro de una pila limitada. Observe los repositorios de conformidad, los productos de proveedores compatibles y las pruebas de carga de trabajo reproducibles. Estas señales determinarán si NVIDIA cuObject se convierte en una capa de almacenamiento de IA portátil u otra opción de aceleración especializada.
