NVIDIA cuObject abre el almacenamiento de IA más allá de los archivos, pero la interoperabilidad sigue sin completarse
NVIDIA puso a disposición general sus bibliotecas cliente y servidor cuObject el 30 de septiembre, ampliando el acceso acelerado al almacenamiento para IA más allá de los sistemas de archivos convencionales. La versión de NVIDIA cuObject incorpora API estandarizadas y un protocolo RDMA para transferir datos de objetos sin enrutar las cargas útiles a través de la CPU de un servidor.
La compañía también presentó un SCADA Server SDK para gestionar solicitudes de almacenamiento iniciadas por GPU. SCADA significa Scaled Accelerated Data Access, un marco diseñado para grandes volúmenes de operaciones de almacenamiento detalladas. IBM ya ha desarrollado un prototipo inicial de Storage Scale con el SDK.
El anuncio apunta a una división persistente en la infraestructura de IA. El almacenamiento de objetos ofrece capacidad e interfaces conocidas compatibles con S3, mientras que las canalizaciones de entrenamiento e inferencia de alto rendimiento suelen depender de sistemas de archivos más rápidos o almacenamiento temporal local. NVIDIA quiere que cuObject reduzca esa brecha, pero su plan más amplio de interoperabilidad sigue incompleto.
NVIDIA cuObject pasa de ser una biblioteca de producto a una propuesta para la industria
El cambio importante no es solo que NVIDIA haya lanzado otra biblioteca de almacenamiento. Está pidiendo a proveedores de nube y almacenamiento que converjan en un protocolo común para objetos acelerados.
Según el anuncio de NVIDIA, tanto las bibliotecas cliente como servidor de cuObject ya están disponibles de forma general. NVIDIA también lanzó cuObject Server 2.0.0 para proveedores de almacenamiento que evalúan la integración del lado del servidor.
La biblioteca cliente se integra en una aplicación de GPU, un cargador de datos o una capa de middleware. Conecta las operaciones de objetos a nivel de aplicación con una ruta de datos RDMA. El acceso directo remoto a memoria, o RDMA, permite que el hardware de red transfiera datos directamente entre regiones de memoria registradas.
La biblioteca de servidor se integra con un servicio de almacenamiento de objetos. Gestiona los búferes registrados y realiza las operaciones RDMA que trasladan datos hacia o desde el cliente. El sistema puede dirigirse tanto a la memoria de la GPU como a la memoria del sistema.
Este diseño aborda un problema que GPUDirect Storage no resolvía por completo. GPUDirect Storage ya proporcionaba una ruta directa entre el almacenamiento y la memoria de GPU, pero su interfaz más conocida, cuFile, se centraba en el acceso a archivos. En cambio, muchos conjuntos de datos de IA se encuentran detrás de interfaces de objetos.
Esa diferencia importa para las organizaciones que mantienen muestras de entrenamiento, documentos, imágenes, puntos de control y artefactos generados en repositorios compatibles con S3. Estos sistemas resultan atractivos porque escalan en grandes espacios de nombres y separan el almacenamiento del cómputo. Sin embargo, el acceso convencional a objetos suele atravesar una pila TCP y búferes gestionados por CPU.
NVIDIA cuObject conserva las operaciones de control orientadas a objetos mientras modifica la ruta de las cargas útiles. Un cliente puede seguir emitiendo solicitudes GET o PUT conocidas mediante un kit de desarrollo de software S3 adaptado. Los datos de los objetos pueden entonces desplazarse por RDMA en lugar de seguir la ruta de datos TCP habitual.
La disponibilidad general ofrece a los desarrolladores un punto de partida con soporte, pero NVIDIA persigue un objetivo más amplio a través de xio-sig. El grupo se está expandiendo del acceso a archivos al acceso a objetos, con trabajo separado previsto para API cliente, un protocolo de red y pruebas de conformidad.
Google Cloud está evaluando una participación ampliada en torno a cuObject. Microsoft también ha indicado que planea unirse al consejo de xio-sig. El prototipo SCADA de IBM incorpora a un proveedor de almacenamiento al grupo inicial, aunque un prototipo no equivale a soporte de producción.
La distinción es fundamental en esta historia. NVIDIA ya cuenta con componentes descargables, documentación y socios que hablan de interoperabilidad. Aún no cuenta con un estándar maduro de almacenamiento de objetos multivendedor con varias implementaciones de producción probadas.
Esto hace que el lanzamiento sea a la vez concreto y provisional. Los desarrolladores pueden comenzar a evaluar las bibliotecas ahora. La promesa más amplia depende de que las plataformas en la nube, los proveedores de almacenamiento, los marcos de trabajo y los desarrolladores de aplicaciones adopten las mismas interfaces.
Cómo NVIDIA cuObject separa el control de los datos
NVIDIA cuObject mantiene los mensajes de control de estilo S3 en una ruta conocida mientras desplaza las cargas útiles de los objetos mediante RDMA.
La arquitectura de cuObject divide cada operación en un plano de control y un plano de datos. Las solicitudes estándar S3 GET y PUT siguen formando parte del flujo de control. Un SDK S3 adaptado añade metadatos que describen la transferencia RDMA.
La carga útil del objeto sigue una ruta distinta. El cliente registra una región de memoria y crea un token RDMA que contiene la información necesaria para la transferencia. Ese token se adjunta a la solicitud HTTP mediante una cabecera personalizada.
La puerta de enlace de almacenamiento analiza la solicitud y indica a un nodo de datos apropiado que realice la operación. Ese nodo registra su búfer local mediante las API de servidor de cuObject. Luego envía o extrae la carga útil mediante una escritura o lectura RDMA.
Una respuesta satisfactoria de la puerta de enlace completa la transacción de control después de finalizar la operación RDMA. Esta separación permite que la aplicación conserve la semántica de los objetos mientras elimina la CPU del servidor de la ruta principal de la carga útil.
El enfoque apunta a más que al ancho de banda bruto. El procesamiento de CPU puede convertirse en una limitación cuando muchos aceleradores generan operaciones de almacenamiento simultáneas. Evitar el procesamiento TCP para cada carga útil puede preservar capacidad de CPU para metadatos, coordinación, seguridad y otros servicios.
La implementación actual utiliza transporte Dynamically Connected, habitualmente llamado DC. DC evita mantener una conexión fiable entre cada par de cliente y servidor de almacenamiento. Esta característica resulta útil cuando un gran clúster de cómputo llega a muchos nodos de almacenamiento.
NVIDIA documenta compatibilidad con DC sobre InfiniBand y RoCEv2. RoCEv2 transporta tráfico RDMA por redes Ethernet configuradas para admitir el comportamiento necesario. Ambas opciones exigen planificación de infraestructura más allá de instalar una biblioteca.
El cliente tampoco interactúa con un punto de conexión S3 sin modificaciones. La documentación de NVIDIA indica que la integración requiere cambios en el SDK S3 del lado cliente y en el software de almacenamiento del lado servidor. Esos cambios crean la ruta acelerada e intercambian metadatos RDMA.
Las operaciones compatibles incluyen GET, PUT, operaciones de carga multipartes y lecturas de rangos de bytes. El acceso por rangos es relevante cuando una aplicación necesita solo una parte de un objeto grande, en lugar de transferir el objeto completo a la memoria de GPU.
Esta arquitectura puede eliminar un paso habitual de preparación. Las canalizaciones de IA tradicionales suelen copiar datos de un repositorio de objetos a un sistema de archivos temporal local o distribuido. Los nodos de cómputo leen luego desde esa capa intermedia.
La preparación puede ofrecer un rendimiento predecible, pero consume capacidad y añade trabajo operativo. Los equipos deben programar copias, supervisar la sincronización, eliminar datos obsoletos y decidir qué conjuntos de datos merecen almacenamiento rápido.
NVIDIA cuObject propone una ruta más directa desde el almacenamiento de objetos hasta la memoria del acelerador. Si se admite de extremo a extremo, una aplicación puede leer desde su repositorio principal de objetos sin crear primero otra copia completa.
Esa ventaja no elimina todas las operaciones intermedias. Los datos aún pueden requerir decodificación, descompresión, validación, agrupación por lotes o transformación. El software de almacenamiento también puede utilizar búferes internos antes de entregar una carga útil mediante RDMA.
Por tanto, el lanzamiento modifica la oportunidad de transporte, no toda la canalización de datos. Las aplicaciones aún deben gestionar formatos, permisos de acceso, metadatos de objetos y recuperación ante fallos. Los proveedores de almacenamiento deben conectar la ruta acelerada con sus propios sistemas de ubicación y durabilidad.
NVIDIA cuObject funciona mejor como una capa de integración entre esos componentes. No sustituye al almacén de objetos, al plano de control S3, al cargador de datos ni a la red.
El SCADA Server SDK desplaza el control de solicitudes hacia las GPU
El SCADA Server SDK aborda otro cuello de botella: muchas solicitudes pequeñas cuya coordinación puede sobrecargar una CPU antes de que el almacenamiento alcance sus límites.
Las transferencias secuenciales grandes hacen que el ancho de banda sea la métrica evidente. Los trabajos de entrenamiento que leen muestras o puntos de control considerables pueden amortizar la sobrecarga de las solicitudes a lo largo de cada transferencia. El trabajo de control se convierte en una parte menor de la operación total.
Los sistemas de inferencia y recuperación generan otro patrón. La búsqueda semántica, las recomendaciones, la detección de fraude y la memoria de agentes pueden generar muchas consultas más pequeñas. Una GPU puede tener suficiente trabajo paralelo para emitir estas operaciones con alta concurrencia.
El software de almacenamiento convencional espera que una CPU construya, envíe y complete esas solicitudes. Ese diseño se vuelve menos eficiente a medida que disminuye el tamaño de las solicitudes y aumenta el número de operaciones. Los costes fijos de procesamiento consumen una proporción mayor de cada transacción.
SCADA permite que clientes basados en GPU inicien solicitudes de almacenamiento mediante una interfaz común. El nuevo SDK proporciona a proveedores de almacenamiento externos una forma de crear servidores que reciban esas solicitudes. Un servidor puede atenderlas desde almacenamiento local o remoto antes de devolver datos mediante RDMA.
El SDK no exige que cada sistema de almacenamiento exponga directamente a la GPU su diseño interno. En su lugar, un servidor SCADA actúa como puente entre una interfaz de cliente compartida y la lógica de almacenamiento específica del proveedor.
IBM ha demostrado un servidor inicial basado en el SDK para IBM Storage Scale. En ese prototipo, un cliente SCADA envía solicitudes a un servidor desarrollado por IBM. El servidor conecta el modelo de solicitud común con Storage Scale.
Esta es una señal temprana de interoperabilidad, pero sigue siendo limitada. NVIDIA no ha publicado resultados de producción independientes para el prototipo de IBM. El anuncio tampoco ofrece mediciones comparativas de latencia, rendimiento o utilización de CPU.
SCADA incluye trabajo complementario más allá del SDK de servidor. NVIDIA ha publicado un Storage Lender Service para aprovisionar acceso a colas NVMe. Una utilidad de línea de comandos también está destinada a ayudar a configurar e implementar componentes SCADA.
La iniciativa Storage-Next aporta el contexto más amplio de la industria. NVIDIA afirma que el grupo incluye a más de 40 proveedores y clientes de flash, controladores, sistemas de almacenamiento, infraestructura en la nube y desarrollo de aplicaciones.
El grupo intenta definir cómo debería comportarse el almacenamiento impulsado por GPU. Su trabajo aborda tanto el movimiento de grandes cantidades de datos como las operaciones pequeñas y detalladas. El objetivo es convertir la colaboración entre proveedores en interfaces y estándares interoperables.
El momento refleja los cambios en los patrones de acceso a datos de IA. El entrenamiento sigue siendo importante, pero la inferencia de producción introduce recuperación de contexto, llamadas a herramientas, consultas a bases de datos y memoria persistente. Cada solicitud de usuario puede desencadenar varias operaciones de datos posteriores.
Un servicio de contexto largo también genera presión fuera de la memoria de GPU. Los datos de caché clave-valor registran el estado de atención de los tokens procesados previamente. Cuando ese estado no puede permanecer en la memoria del acelerador, los sistemas necesitan otro nivel que pueda devolverlo de manera eficiente.
El almacenamiento es más económico y ofrece más capacidad que la memoria del acelerador, pero tiene características de latencia diferentes. SCADA intenta que las GPU toleren esa brecha mediante paralelismo. Muchos hilos de GPU pueden mantener operaciones en curso en lugar de esperar una secuencia de solicitudes controlada por CPU.
La idea complementa a cuObject en lugar de sustituirlo. NVIDIA cuObject se centra en el acceso acelerado al almacenamiento de objetos compatible con S3. SCADA se centra en el acceso detallado iniciado por GPU a través de distintas implementaciones de almacenamiento.
Juntas, amplían la influencia de NVIDIA desde el cómputo hacia los protocolos que conectan los aceleradores con los 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 enfrenta a las interfaces compartidas entre aceleradores y almacenamiento con integraciones independientes diseñadas para cada proveedor de nube o almacenamiento.
El almacenamiento de objetos sobre RDMA ha carecido de un protocolo de red común ampliamente adoptado. Un desarrollador que buscara acceso directo a GPU podía recurrir a transferencias S3 tradicionales, usar un sistema de archivos intermedio o desarrollar sobre una ruta acelerada específica de un proveedor.
Cada opción impone un coste distinto. El acceso tradicional preserva la compatibilidad, pero mantiene la sobrecarga de CPU y TCP. La preparación intermedia puede mejorar la proximidad de los datos, aunque los duplica. Una integración específica de 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 red acelerado y una suite de conformidad. La misma organización también alberga trabajo relacionado con cuFile.
La conformidad es esencial porque publicar una interfaz no garantiza un comportamiento compatible. Las implementaciones deben coincidir en la semántica de las solicitudes, el registro de memoria, la gestión de errores, los límites de seguridad y el comportamiento de respaldo. También deben responder de forma consistente ante fallos y concurrencia.
En el momento de la publicación, la organización pública afirma que el código aparecerá después de que los participantes fundadores integren y validen las capas. Su página de estado también indica que las pilas deben superar pruebas de conformidad antes de dicha publicación.
Esto deja una brecha significativa 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.
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 admitir infraestructura que no esté controlada por NVIDIA.
Sin embargo, los socios han asumido compromisos distintos. Google Cloud está evaluando una participación más amplia en cuObject. Microsoft ha señalado su intención de unirse al consejo. Ninguna de las dos 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 de 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 capacidades diferenciadas de caché, ubicación, seguridad o servicios de datos. Un protocolo compartido debe mantener suficiente amplitud para permitir interoperabilidad sin eliminar esas funciones.
NVIDIA tiene su propio interés estratégico. Una ruta común desde el almacenamiento hasta la memoria de GPU puede facilitar el uso de aceleradores NVIDIA con conjuntos de datos más grandes. También puede integrar productos de red, 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 hace referencia a GPU, TPU y XPU al describir la demanda de cómputo. Una interfaz de almacenamiento realmente portátil no debería depender de una sola arquitectura de aceleradores en todas las capas.
La evidencia más clara llegará con implementaciones ajenas a NVIDIA que superen pruebas compartidas. El soporte dentro de frameworks comunes también importaría. A los desarrolladores les preocupa menos la pertenencia 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 preserva el comportamiento de la aplicación entre varios productos compatibles. Una ruta rápida vinculada a una combinación validada sigue siendo una integración, no un estándar de la industria.
La disponibilidad general no elimina el riesgo de despliegue
Las bibliotecas están disponibles, pero la adopción en producción aún exige redes especializadas, software modificado, una gestión cuidadosa de la memoria y benchmarks creíbles.
Las notas de la versión 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 sobre el mismo búfer registrado.
Las transferencias de memoria del host requieren búferes registrados. Parte del comportamiento de configuración difiere de cuFile, incluida la ausencia de un grupo de hilos para emitir operaciones de E/S de cuObject. Las aplicaciones deben comprender estas restricciones antes de adoptar la ruta.
La vida útil de la memoria requiere especial cuidado. Un cliente no debe reutilizar ni cancelar el registro de un búfer mientras una operación siga pendiente. La gestión de errores también debe impedir que solicitudes obsoletas accedan a una región de memoria después de reutilizarse su clave.
Estos requisitos no son inusuales en software RDMA de alto rendimiento. Aun así, desplazan la responsabilidad hacia los desarrolladores de aplicaciones, frameworks y almacenamiento. Una integración incorrecta puede generar fallos difíciles de diagnosticar.
La red también importa. El transporte DC sobre InfiniBand o RoCEv2 presupone adaptadores, switches, enrutamiento y configuración adecuados. Las organizaciones no pueden esperar que la ruta acelerada aparezca en una red convencional sin trabajo de infraestructura.
Los despliegues de RoCE pueden ser sensibles a la congestión y al diseño de la 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 establece un rendimiento predecible en todo el clúster.
La seguridad merece la misma atención. El movimiento directo de datos reduce la intervención de la CPU en la ruta de carga útil, pero no puede eludir la autorización. Los sistemas aún necesitan 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 de configuración privilegiado. Esa estructura puede proteger la ruta de datos si se implementa correctamente. Los proveedores de almacenamiento aún deben conectarla con el aislamiento de inquilinos, la auditoría, la gestión de credenciales y la revocación.
El anuncio no contiene ningún benchmark estandarizado que compare cuObject con S3 convencional, acceso a archivos con preparación intermedia o alternativas específicas de proveedor. Tampoco cuantifica las ganancias del prototipo de IBM.
Esa omisión impide extraer conclusiones generales de rendimiento. RDMA puede reducir copias y procesamiento de CPU, pero los resultados de las aplicaciones dependen de los tamaños de los objetos, patrones de acceso, medios de almacenamiento, topología de red, concurrencia y preprocesamiento.
Las lecturas secuenciales grandes pueden ya funcionar adecuadamente mediante sistemas de archivos optimizados. Las solicitudes muy pequeñas pueden revelar límites 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 en torno a SCADA destaca esa distinción. Las transferencias masivas y las lecturas de grano fino imponen requisitos diferentes, por lo que ninguna cifra única de rendimiento máximo puede describir ambas.
Por ello, los desarrolladores deberían considerar NVIDIA cuObject como una ruta para evaluar, no como un resultado de rendimiento garantizado. Las pruebas deberían usar tamaños de objetos reales, concurrencia representativa, transformaciones existentes y escenarios de fallo esperados.
Una prueba de concepto creíble debería medir más que el ancho de banda. Debería seguir la latencia de cola, el consumo de CPU del servidor, la utilización de GPU, la sobrecarga del 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 de la 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, no a la posibilidad técnica. NVIDIA ha demostrado que los componentes pueden construirse. Aún no ha demostrado que una amplia variedad de proveedores mantendrá implementaciones compatibles durante varios ciclos de lanzamiento.
Qué observar tras el lanzamiento del SDK de servidor NVIDIA SCADA
Tres señales mostrarán si NVIDIA cuObject se convierte en infraestructura compartida o permanece como 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 red 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, cobertura de pruebas limitada o dependencias de una única combinación de hardware la debilitarían.
La segunda señal es soporte de producción por parte 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 evidencia específica de cada carga de trabajo. Los proveedores deben publicar resultados reproducibles para la ingesta de entrenamiento, las operaciones de checkpoints, la recuperación, la búsqueda semántica y el acceso a caché de inferencia. Esas pruebas deberían comparar transferencias de objetos estándar, flujos de preparación intermedia y rutas habilitadas para RDMA.
Los resultados deberían incluir el consumo de CPU y la latencia de cola, no solo el rendimiento máximo. También deberían revelar los tamaños de objetos, la configuración de red, los medios de almacenamiento y el comportamiento ante fallos. Sin ese contexto, será difícil aplicar las cifras de rendimiento.
Los desarrolladores no necesitan esperar para estudiar la arquitectura. Pueden identificar dónde sus aplicaciones preparan datos de objetos, perfilar el tiempo de CPU en transferencias de almacenamiento y medir la distribución del tamaño de las solicitudes. Ese 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 exponer una única ruta fiable sin atrapar las aplicaciones dentro de una pila limitada. Observe los repositorios de conformidad, los productos compatibles de los proveedores y las pruebas reproducibles de cargas de trabajo. Esas señales determinarán si NVIDIA cuObject se convierte en una capa de almacenamiento de IA portátil o en otra opción de aceleración especializada.
