La inferencia robótica de NVIDIA se traslada a bordo, pero los centros de datos aún piensan a mayor escala
La inferencia robótica de NVIDIA se ha acercado mucho más a la propia máquina, pese a años de desarrollo de IA centrado en centros de datos remotos. Jetson Thor proporciona a los fabricantes de robots suficiente capacidad de cómputo a bordo para ejecutar varios modelos exigentes sin esperar a que cada decisión atraviese una red.
Este cambio no vuelve obsoleta a la nube. Crea una división más nítida entre el control físico inmediato y el razonamiento computacionalmente costoso. Los robots necesitan reflejos locales, mientras que los centros de datos siguen ofreciendo modelos más grandes, memoria compartida, actualizaciones más sencillas y un mejor aprovechamiento de los recursos.
Por tanto, la competencia central no enfrenta al hardware de borde con la infraestructura en la nube. Enfrenta la autonomía local con la inteligencia centralizada, y cada empresa de robótica debe decidir dónde trazar ese límite. Google DeepMind, NVIDIA y los fabricantes de robots ya están construyendo en torno a distintas versiones de esta división.
La inferencia robótica de NVIDIA ha llegado a la máquina
NVIDIA ha convertido la inferencia a bordo de una alternativa limitada en una base creíble para un comportamiento robótico sofisticado.
La señal de hardware más clara llegó con la disponibilidad general de Jetson AGX Thor en agosto de 2025. NVIDIA diseñó el ordenador compacto para humanoides, máquinas industriales, dispositivos médicos y otros sistemas que procesan datos de sensores en tiempo real.
La empresa afirma que Jetson Thor ofrece 7,5 veces más capacidad de cómputo de IA que Jetson AGX Orin. NVIDIA también informa de una eficiencia energética 3,5 veces superior a la de su predecesor.
Estas comparaciones siguen siendo afirmaciones del proveedor, y el rendimiento real depende del modelo, la precisión, el uso de memoria y la configuración del software. Aun así, las especificaciones básicas de la plataforma explican por qué la ubicación de la inferencia robótica se ha convertido en una cuestión arquitectónica urgente.
Jetson AGX Thor incluye 128GB de memoria y ofrece hasta 2.070 teraflops FP4, según NVIDIA. FP4 es un formato numérico compacto de cuatro bits que reduce el almacenamiento y el cómputo de los modelos, aunque acepta cierta pérdida de precisión.
La capacidad de memoria importa tanto como la cifra principal de cómputo. Un robot puede ejecutar simultáneamente cargas de trabajo de percepción, lenguaje, mapeo, planificación de movimientos y seguridad. Cada carga compite por ancho de banda de memoria, tiempo de procesamiento y un presupuesto energético limitado.
NVIDIA afirma que su comunidad de software de robótica reúne a más de dos millones de desarrolladores. Entre los primeros usuarios de Thor citados por la empresa se encuentran Amazon Robotics, Boston Dynamics, Figure, Agility Robotics, Caterpillar y Medtronic.
La lista abarca almacenes, humanoides, maquinaria pesada y atención sanitaria. Sugiere que la IA a bordo se está convirtiendo en una decisión de infraestructura compartida, más que en una función limitada a una sola categoría de robots.
Google DeepMind ha impulsado este cambio desde el lado de los modelos. Su modelo local de robótica se presentó en junio de 2025 como un sistema de visión-lenguaje-acción optimizado para ejecutarse directamente en robots.
Un modelo de visión-lenguaje-acción, habitualmente llamado VLA, traduce imágenes e instrucciones en acciones físicas. Combina percepción visual, comprensión del lenguaje y control motor dentro de un único sistema aprendido.
DeepMind presentó su modelo como útil cuando la latencia de red o la conectividad limitarían a un robot dependiente de la nube. Según la empresa, el modelo también puede adaptarse a nuevas tareas con demostraciones adicionales.
Estos lanzamientos cambiaron el punto de partida práctico para la arquitectura robótica. Los desarrolladores ya no tienen que asumir que la percepción avanzada y la manipulación de propósito general requieren una conexión permanente a un centro de datos.
Sin embargo, ni NVIDIA ni Google han demostrado que todas las capas de la inteligencia robótica deban residir a bordo. Sus productos hacen posible, en cambio, un diseño híbrido, y eso crea decisiones más difíciles sobre qué cálculos deben mantenerse locales.
Un robot no puede esperar a que la nube lo alcance
Los sistemas físicos imponen plazos a la inteligencia, y no cumplirlos puede importar más que generar la respuesta más sofisticada.
Un chatbot puede detenerse mientras un modelo remoto genera una respuesta. Un robot que se equilibra sobre dos piernas, evita a un trabajador o sujeta material frágil no puede considerar un retraso de red impredecible como una molestia menor.
Cada solicitud a la nube añade varias etapas. El robot debe codificar la información de los sensores, transmitirla, esperar el procesamiento remoto, recibir un resultado y verificar que la instrucción sigue siendo pertinente.
El mundo físico puede cambiar durante ese recorrido. Una persona puede cruzarse en el camino, un objeto puede resbalar o un vehículo puede entrar en una intersección. Una respuesta correcta pero tardía puede volverse funcionalmente incorrecta.
Esta restricción favorece los bucles de control locales. Un bucle de control mide repetidamente un sistema, calcula una corrección y la aplica para mantener estable el movimiento.
El equilibrio de bajo nivel, la prevención de colisiones, el control de articulaciones y la parada de emergencia deben permanecer cerca del hardware. Estas funciones necesitan un comportamiento determinista, lo que significa que su tiempo de respuesta se mantiene dentro de un intervalo conocido.
La conectividad introduce variabilidad incluso cuando la latencia media parece aceptable. La congestión, una cobertura deficiente, los problemas de enrutamiento y las interrupciones del servicio generan retrasos de cola larga que las medias ocultan.
El funcionamiento sin conexión también importa más allá de las ubicaciones remotas. Las fábricas pueden aislar las redes de producción por seguridad. Los hospitales pueden limitar las transferencias externas de datos, mientras que las granjas y las obras suelen carecer de conectividad fiable.
La privacidad refuerza la misma presión arquitectónica. Los robots pueden recopilar vídeo, audio, mapas espaciales, información médica y observaciones de hogares privados. Enviar cada flujo de sensores sin procesar a un servicio remoto amplía la superficie de exposición.
El procesamiento local puede descartar información innecesaria antes de transmitirla. Un robot de almacén podría enviar un informe compacto de excepciones en lugar de vídeo continuo del entorno de los trabajadores.
El ancho de banda presenta otra limitación. Varias cámaras, micrófonos, sensores de profundidad y sistemas lidar pueden generar flujos continuos. Subirlo todo consumiría capacidad de red antes de que el centro de datos comenzara su trabajo de inferencia.
El filtrado en el dispositivo permite al robot decidir qué observaciones merecen análisis remoto. Puede mantener local la navegación rutinaria y escalar situaciones desconocidas con imágenes seleccionadas, resúmenes de estado o contexto comprimido.
La energía complica el panorama. El cómputo local consume batería y genera calor, pero la transmisión inalámbrica también tiene un coste energético. La mejor opción depende de las condiciones de radio, el tamaño de la carga de trabajo y los aceleradores disponibles.
La seguridad hace que esto sea más que una optimización de infraestructura. Un robot debe seguir siendo controlable cuando desaparece su conexión a la nube. Ese requisito traslada los reflejos esenciales, los límites operativos y los comportamientos de respaldo a la propia máquina.
La nube aún puede asesorar al robot. No debería convertirse en el único componente capaz de detenerlo.
Para la inferencia robótica de NVIDIA, la oportunidad es, por tanto, concreta. Los procesadores a bordo pueden gestionar la ruta sensible al tiempo, incluso cuando un modelo remoto más grande se encarga del trabajo deliberativo.
Los centros de datos aún dominan el límite de la inteligencia
Los chips locales mejoran la capacidad de respuesta de un robot, pero los centros de datos conservan una ventaja decisiva cuando una tarea exige escala, memoria o cómputo compartido.
Un ordenador robótico opera dentro de límites estrictos. Tiene memoria, capacidad de refrigeración, duración de batería, espacio físico y coste de fabricación finitos. Aumentar un recurso suele empeorar otra restricción.
Los centros de datos pueden distribuir un modelo entre muchos aceleradores. Las interconexiones de alta velocidad permiten a esos aceleradores compartir parámetros y datos intermedios que no cabrían dentro de un solo robot.
Esta diferencia establece un límite de inteligencia. Un modelo compacto puede gestionar objetos comunes e instrucciones conocidas, mientras que un modelo remoto examina situaciones poco frecuentes con conocimiento más amplio y un contexto más extenso.
El tamaño del modelo no es una medida perfecta de capacidad. Los sistemas más pequeños pueden superar a los más grandes cuando se optimizan para una tarea específica. Sin embargo, los grandes modelos remotos siguen siendo útiles para solicitudes desconocidas, planificación de varios pasos y conocimiento amplio del mundo.
Los centros de datos también se benefician del procesamiento por lotes. El procesamiento por lotes combina solicitudes de varios usuarios o máquinas, lo que permite a los aceleradores costosos procesarlas de forma más eficiente.
SemiAnalysis ha descrito la disyuntiva de inferencia resultante entre el rendimiento del sistema y la interactividad individual. Los lotes grandes mejoran el aprovechamiento del hardware, mientras que los lotes más pequeños generalmente ofrecen respuestas más rápidas a cada usuario.
Un solo robot no puede reproducir esa economía. Su procesador puede permanecer infrautilizado durante la operación rutinaria, pero aun así necesita suficiente capacidad para el momento local más exigente.
La infraestructura centralizada agrupa esa demanda en toda una flota. Un clúster remoto puede atender a muchos robots cuyas solicitudes difíciles llegan en momentos distintos.
Las actualizaciones también son más sencillas en el centro de datos. Un operador puede implementar un nuevo modelo una vez, supervisar su comportamiento y revertirlo sin intervenir en cada máquina.
Los modelos locales requieren una canalización de distribución. Los equipos deben gestionar variaciones de hardware, límites de almacenamiento, compatibilidad de firmware, seguimiento de versiones y fallos durante la instalación.
El aprendizaje de flotas también favorece la centralización. Cuando un robot encuentra un paquete, una herramienta o una configuración de sala inusual, un servicio compartido puede incorporar ese caso para otras máquinas.
El entrenamiento pertenece aún con más firmeza a la infraestructura centralizada. NVIDIA describe una arquitectura de tres ordenadores que separa el entrenamiento, la simulación y la ejecución a bordo.
En ese modelo, los sistemas DGX entrenan la IA, los servidores generan experiencia simulada y los ordenadores Jetson ejecutan capacidades seleccionadas dentro de los robots. La arquitectura distribuye el trabajo según sus requisitos físicos y computacionales.
Esta división muestra por qué una narrativa basada solo en el borde es incompleta. La inteligencia robótica depende de una canalización que crea, prueba, despliega, observa y actualiza modelos.
El centro de datos no es simplemente un cerebro distante que responde a solicitudes en tiempo real. También es el taller donde se construye y mejora el cerebro local de un robot.
La inferencia remota sigue siendo valiosa dentro de esa canalización. Un robot puede pedir a un modelo más grande que interprete una instrucción desconocida, compare varios planes o busque en una amplia base de conocimiento técnico.
La respuesta no necesita controlar directamente un motor. Puede proporcionar un plan que los sistemas locales validen y ejecuten bajo las restricciones de seguridad actuales.
Esta distinción protege al robot frente a comandos retrasados o inapropiados. También preserva el acceso a capacidades que no caben a bordo.
La arquitectura ganadora separa los reflejos del razonamiento
La respuesta práctica es una jerarquía: los sistemas locales controlan el comportamiento inmediato, mientras que los sistemas remotos gestionan el razonamiento costoso y el aprendizaje de toda la flota.
Los desarrolladores ya utilizan control jerárquico en robótica. Los componentes rápidos gestionan la estabilidad y el movimiento, mientras que los componentes más lentos eligen objetivos y secuencias.
La IA generativa amplía esa estructura en lugar de sustituirla. Un modelo VLA puede conectar instrucciones con acciones, pero sigue funcionando junto a controladores, monitores de seguridad, sistemas de percepción y planificadores.
El límite más seguro lo marca la urgencia. Los cálculos con plazos estrictos permanecen en el dispositivo. Las tareas que toleran demoras pueden trasladarse a un centro de datos cuando el procesamiento remoto ofrece mejores capacidades.
Un robot de reparto ofrece un ejemplo útil. Los sistemas locales deben detectar peatones, seguir el bordillo, detenerse ante obstáculos y mantener el equilibrio sin conexión a internet.
Un sistema remoto puede interpretar una nueva instrucción de entrega, reorganizar una ruta o evaluar la entrada de un edificio desconocido. Después, el robot puede contrastar el plan propuesto con las condiciones locales.
Los robots industriales plantean una división similar. El procesamiento integrado puede inspeccionar piezas y corregir movimientos durante el ensamblaje. Un servicio central puede analizar patrones de producción en varias instalaciones.
Los humanoides hacen que este límite sea más difícil de definir porque sus tareas son menos predecibles. Necesitan un control rápido de todo el cuerpo, pero los usuarios pueden pedirles que completen secuencias largas y novedosas.
La investigación original de Google sobre Gemini Robotics describe modelos diseñados para generalizar entre tareas y formas robóticas. La generalización es importante, pero una evaluación de laboratorio no puede reflejar todas las condiciones de despliegue.
Una arquitectura híbrida permite escalar capacidades. Cuando la confianza cae por debajo de un umbral, el robot puede detenerse, solicitar asistencia o enviar contexto seleccionado a un modelo remoto más potente.
La confianza por sí sola no basta. Los modelos entrenados pueden seguir equivocándose con seguridad, por lo que los sistemas también necesitan límites operativos explícitos y comprobaciones independientes.
El servicio remoto debería devolver intenciones estructuradas en lugar de comandos de actuadores sin restricciones. Por ejemplo, podría proponer como objetivo «coloca el contenedor azul en el estante tres».
El software de planificación local puede rechazar ese objetivo si el estante está bloqueado, el objeto es inestable o una persona entra en el área de trabajo.
Este diseño convierte al centro de datos en un asesor, no en un titiritero. Conserva la inteligencia centralizada sin introducir la fiabilidad de la red en cada bucle de control.
El enrutamiento de cargas de trabajo se convierte en una capacidad central del producto. El sistema debe determinar qué modelo puede resolver cada solicitud dentro de sus presupuestos de tiempo, energía, privacidad y seguridad.
Las solicitudes sencillas pueden permanecer en el dispositivo. Las complejas pueden usar inferencia remota, mientras que las solicitudes sensibles pueden requerir procesamiento local incluso si el resultado local es menos capaz.
El almacenamiento en caché puede reducir las llamadas repetidas a la nube. Un robot puede obtener orientación remota para una tarea nueva y luego guardar una política compacta para usos futuros.
Los operadores de flotas también pueden programar análisis no urgentes. Los registros de tareas completadas pueden cargarse durante periodos seguros, lo que permite a los modelos del centro de datos identificar fallos sin afectar al comportamiento en tiempo real.
Este enfoque se asemeja a las arquitecturas informáticas que combinan aplicaciones locales con servicios en la nube. La robótica eleva las exigencias porque el resultado modifica objetos físicos y entornos compartidos.
La ventaja de NVIDIA reside en suministrar ambos lados de esta división. Sus aceleradores para centros de datos respaldan el desarrollo de modelos y la inferencia remota, mientras que Jetson ejecuta cargas de trabajo seleccionadas en el edge.
Esa posición también genera tensiones para los clientes. Una pila integrada verticalmente puede simplificar el desarrollo, pero puede aumentar la dependencia del hardware, el software y las herramientas de modelos de un solo proveedor.
Google aborda el problema mediante modelos y servicios en la nube, mientras que los fabricantes de robots controlan la integración final del hardware. Otros fabricantes de chips pueden competir ofreciendo menor consumo energético u opciones de despliegue más abiertas.
La competencia importante no consiste en qué empresa se declara el cerebro del robot. Consiste en qué pila tecnológica mueve el trabajo por la jerarquía sin comprometer la latencia, la seguridad ni la viabilidad económica.
Lo que no demuestran las afirmaciones sobre la IA en el dispositivo
Las especificaciones de los proveedores demuestran que cabe más capacidad de cómputo dentro de los robots, pero no prueban una autonomía fiable en entornos no controlados.
Las cifras de rendimiento máximo rara vez describen un sistema completo ya desplegado. Los robots reales deben repartir recursos entre cámaras, sensores, redes, planificación, registros y funciones de seguridad.
También importa la precisión anunciada. El rendimiento FP4 representa computación de baja precisión, pero algunos modelos u operaciones necesitan mayor precisión. Su rendimiento efectivo puede diferir de la cifra destacada.
La capacidad de memoria tampoco equivale a la capacidad útil para modelos. El sistema operativo, las canalizaciones de percepción, las cachés y las aplicaciones simultáneas consumen parte del espacio disponible.
El calor puede reducir el rendimiento sostenido. Un procesador puede alcanzar su máximo brevemente y luego ralentizarse cuando la refrigeración no puede extraer suficiente calor de una carcasa compacta.
Los robots alimentados por batería afrontan otra disyuntiva. Un mayor razonamiento integrado puede reducir la dependencia de la red, pero el uso constante de aceleradores puede acortar el tiempo de funcionamiento o requerir una batería más grande.
La compresión de modelos introduce sus propios riesgos. La cuantización reduce el número de bits utilizados para los pesos del modelo, haciéndolo más pequeño y rápido.
Sin embargo, la compresión puede degradar el rendimiento de forma desigual. Los objetos poco frecuentes, los detalles visuales sutiles o las instrucciones inusuales pueden verse más afectados que las tareas habituales de los benchmarks.
Las demostraciones de laboratorio suelen funcionar dentro de conjuntos de tareas controlados. Los despliegues comerciales introducen reflejos, polvo, ruido, objetos dañados, espacios concurridos y usuarios que formulan solicitudes de forma impredecible.
Un modelo generalista aún puede fallar en los límites de su distribución de entrenamiento. La pregunta clave no es si completó una demostración cuidadosamente preparada.
Los operadores necesitan conocer las tasas de fallo durante despliegues prolongados. También necesitan datos sobre el comportamiento de recuperación, la frecuencia de intervención y el rendimiento después de que las temperaturas del hardware se estabilicen.
La inferencia remota afronta carencias comparables. Un modelo más grande puede generar un plan mejor, pero sigue siendo vulnerable a información obsoleta de los sensores o a instrucciones ambiguas.
Las estadísticas de disponibilidad de la nube tampoco reflejan la calidad de conexión de cada robot. Un servicio puede seguir operativo mientras una máquina pierde cobertura local dentro de un ascensor o una instalación con paredes metálicas.
La seguridad tiene dos caras. El procesamiento local reduce la transmisión de datos, pero colocar modelos valiosos y registros operativos en un dispositivo crea un objetivo para ataques físicos.
Los atacantes pueden robar un robot, inspeccionar su almacenamiento o explotar un servicio local sin actualizar. Los sistemas centralizados son más fáciles de actualizar, aunque una sola vulneración puede afectar a una flota mayor.
Los sistemas híbridos heredan ambas superficies de ataque. Necesitan autenticación de dispositivos, comunicaciones cifradas, actualizaciones de modelos firmadas, controles de acceso y reglas claras para operar sin conexión.
La dependencia de proveedores también merece escrutinio. Una empresa de robótica puede optimizar modelos en torno a un único acelerador, entorno de ejecución y cadena de herramientas de despliegue.
Cambiar de proveedor puede requerir después convertir modelos, repetir pruebas de rendimiento y realizar una nueva validación de seguridad. Esos costes pueden persistir durante toda la vida comercial de un robot.
NVIDIA afirma que su pila de IA física conecta Jetson Thor con el software de robótica Isaac y herramientas relacionadas de procesamiento de sensores. Los clientes deben decidir si esa integración compensa el coste de la dependencia.
Los lanzamientos en dispositivo de Google DeepMind plantean otra incertidumbre: el acceso. Los programas tempranos o para evaluadores de confianza pueden demostrar una dirección técnica sin mostrar una disponibilidad amplia en producción.
Ni un hardware impresionante ni un VLA capaz resuelven la cuestión de la responsabilidad. Cuando un robot híbrido falla, los investigadores deben determinar si el error fue causado por el dispositivo, la red, el modelo remoto o la política de enrutamiento.
Ese reto de diagnóstico dará forma a los seguros, las compras y la regulación. Los compradores exigirán registros que reconstruyan qué observó y decidió cada componente.
Los despliegues más sólidos no ocultarán esta complejidad tras una única puntuación de autonomía. Medirán por separado el comportamiento local, la escalada a la nube y la intervención humana.
Tres señales revelarán dónde piensan realmente los robots
La próxima etapa la decidirá el comportamiento desplegado, no otra ronda de anuncios sobre capacidad máxima de cómputo.
La primera señal es la proporción de tareas robóticas completadas sin inferencia remota. Los proveedores deberían informar con qué frecuencia las máquinas escalan, cuánto tardan esas escaladas y qué ocurre durante una desconexión.
Un aumento de la tasa de finalización local reforzaría el argumento a favor de la inferencia robótica de NVIDIA y otras plataformas de edge. Demostraría que los sistemas integrados pueden gestionar más que reflejos de emergencia.
Sin embargo, la métrica necesita una definición estable de la tarea. Un robot que gestiona asignaciones más sencillas localmente no supera necesariamente a otro que envía problemas más difíciles a la nube.
La segunda señal es el rendimiento sostenido bajo límites reales de energía y temperatura. Los compradores necesitan resultados de robots completos operando durante turnos largos, no procesadores aislados ejecutando pruebas breves.
Si Jetson Thor y los sistemas competidores sostienen varios modelos sin penalizaciones inaceptables de calor o batería, más planificación migrará a las máquinas. Una limitación térmica persistente mantendría un papel mayor para la nube.
La tercera señal es el diseño de las arquitecturas de flotas en producción. Observe si los principales fabricantes de robots presentan la operación local primero, la escalada remota y un comportamiento de respaldo auditable como características explícitas del producto.
Una jerarquía clara validaría la tesis híbrida. Un sistema que depende discretamente de conectividad constante demostraría que su inteligencia más importante sigue residiendo en otro lugar.
Los proveedores de centros de datos también tienen motivos para respaldar esa jerarquía. Pueden vender razonamiento de mayor valor, analítica de flotas, simulación y entrenamiento sin procesar cada fotograma de sensores.
Los fabricantes de chips para edge se benefician cuando se expanden las cargas de trabajo locales. Los fabricantes de robots se benefician cuando pueden elegir el lugar de ejecución seguro más económico para cada tarea.
Los clientes deberían plantear preguntas directas a los proveedores antes de elegir una plataforma. ¿Qué funciones sobreviven a una caída de red? ¿Qué datos salen de la máquina? ¿Qué modelo produce cada decisión?
También deberían preguntar cómo rechaza el robot las instrucciones obsoletas de la nube. Un plan remoto creado unos segundos antes puede no ajustarse ya a la escena actual.
Para los desarrolladores, la tarea principal de diseño ya no consiste en elegir una única ubicación de inferencia. Consiste en construir un enrutador que trate la latencia, la confianza, la privacidad y la seguridad como restricciones de primer orden.
Los trabajadores del conocimiento encontrarán la misma decisión a través de robots de oficina, dispositivos autónomos y sistemas de IA que observan espacios físicos. La ubicación de los datos determinará la confianza tanto como la capacidad del modelo.
La inferencia robótica de NVIDIA hace más práctica una arquitectura local primero, pero no resuelve la competencia más amplia. Los centros de datos siguen proporcionando los modelos más grandes y el ciclo compartido de aprendizaje.
Por tanto, la mejor pregunta no es dónde piensa un robot. Hay que preguntar qué pensamientos deben ocurrir ahora, cuáles requieren mayor escala y quién sigue siendo responsable cuando ambos discrepan.
