LLM y modelos VLA a bordo de robots 2026: qué encaja y qué no

El stack de software de un robot tiene al menos cinco tareas distintas, y solo dos de ellas son territorio plausible hoy para un LLM o un VLA. Tratar "la IA en robótica" como un bloque indiferenciado es el error de enfoque más común en la cobertura de este espacio: lleva a la pregunta equivocada ("¿puede ejecutar un LLM?") en lugar de la pregunta útil ("¿cuál de estas cinco tareas está haciendo realmente el modelo, y a qué frecuencia?").

Las cinco tareas, en el orden en que fluyen los datos: percepción (convertir datos de cámara/lidar/IMU en una representación estructurada del mundo), estimación de estado (fusionar esos datos a lo largo del tiempo en una estimación estable de la propia pose del robot y del estado del mundo), planificación de tareas (decidir *qué* hacer a continuación: "recoger la taza azul", "navegar hasta el muelle de carga"), planificación de movimiento (traducir una tarea en una trayectoria factible: ángulos de articulación, un camino, un enfoque de agarre) y control (convertir la trayectoria planificada en comandos de motor, momento a momento, mientras se rechazan perturbaciones).

La percepción es donde los VLM y los modelos de visión ligeros ya hacen trabajo real: detección de objetos, descripción de escena, etiquetado semántico, normalmente en el rango de 5–30 Hz que produce un flujo de cámara. La planificación de tareas es donde un VLA o LLM añade valor genuino: traducir un objetivo en lenguaje natural o visual en un subobjetivo simbólico sobre el que un sistema posterior puede actuar. Esas son las dos tareas que este artículo trata como territorio legítimo de VLA/LLM.

La estimación de estado, la planificación de movimiento y el control son de naturaleza distinta. La estimación de estado suele ejecutar un filtro de Kalman o un filtro de partículas: matemáticas deterministas y bien comprendidas que una red neuronal no mejora para el problema central de estimación. La planificación de movimiento está dominada por optimizadores de trayectoria clásicos (CHOMP, RRT*, planificadores basados en MPC) precisamente porque ofrecen satisfacción de restricciones verificable, una propiedad que la salida de un modelo de lenguaje no tiene. El control es el más rápido y el menos apto para modelos de todos: ejecuta un bucle de retroalimentación contra el error del sensor a frecuencias que un paso hacia adelante de un transformer no puede aproximarse.

La restricción vinculante sobre lo que un robot puede hacer con un VLA es el número de decisiones por segundo alcanzables por el modelo, no la calificación de TOPS pico del acelerador. Una hoja de datos de hardware que indica 100 TOPS no dice nada sobre cuántas veces por segundo un VLA de 2–7B parámetros puede ejecutar un paso hacia adelante completo y producir una acción utilizable; ese número depende conjuntamente del tamaño del modelo, la cuantización, el tamaño de lote, el número de cámaras y el ancho de banda de memoria, y suele estar muy por debajo de lo que la cifra de TOPS sugiere para una carga de trabajo de un solo flujo y baja latencia.

Distintos bucles toleran latencias muy diferentes. Un bucle de equilibrio en locomoción en un robot con patas o autoequilibrado necesita correcciones en milisegundos de un solo dígito: es un bucle de control de 100–1.000 Hz, y ninguna arquitectura VLA publicada corre a esa frecuencia. Un bucle de planificación de tareas en manipulación (decidir "alcanzar la taza" frente a "alcanzar el bol") tolera 100–1.000 ms de latencia sin degradar visiblemente el comportamiento: ese es el rango de 1–10 Hz en el que un VLA opera de forma realista. Un bucle de replanificación a nivel de navegación (rehacer la ruta alrededor de un obstáculo) suele tolerar varios segundos.

Por eso la tasa de salida del modelo, no los FLOPs subyacentes del modelo, es la cifra sobre la que hay que presupuestar. Dos VLA con recuentos de parámetros similares pueden tener frecuencias Hz alcanzables muy diferentes según cuánto del pipeline (codificador de visión, decodificador de acción, tokenización) esté en la ruta crítica por decisión, y según cuántos flujos de cámara alimenten el mismo paso hacia adelante, ya que la mayoría de las arquitecturas VLA procesan cada cámara adicional como contexto adicional, no como paralelismo adicional.

Un modelo dentro del bucle de control es un riesgo de seguridad, no solo un problema de rendimiento. Las salidas de las redes neuronales no son formalmente verificables como lo son los márgenes de estabilidad de un controlador PID o MPC: no hay prueba de que un transformer nunca produzca una acción insegura ante una distribución de entrada nunca vista. Esta es la razón fundamental por la que las paradas con clasificación de seguridad, los límites de par y los enclavamientos anticolisión permanecen en código de control determinista en todos los stacks de robots en producción de los que tenemos conocimiento, sin importar cuán capaz llegue a ser el modelo del nivel de razonamiento: una función de seguridad certificable necesita un comportamiento que pueda caracterizarse de forma exhaustiva, y una red neuronal grande no puede ofrecer actualmente esa garantía.

Usa la calculadora de abajo para estimar qué tasa de decisión puede alcanzar realmente una combinación dada de hardware y número de cámaras, antes de comprometerte con un modelo o una placa. Las estimaciones son aproximaciones de ingeniería para presupuestos iniciales, no benchmarks del fabricante: valídalas contra el modelo y el hardware reales antes de finalizar un diseño.

Cinco modelos VLA cubren la mayor parte del panorama abierto y semiabierto que los equipos de robótica evalúan en 2026, además de un modelo de acceso restringido que vale la pena seguir para ver hacia dónde va el campo. Los recuentos de parámetros marcados con "~" a continuación provienen de reportes secundarios en lugar de una hoja de especificaciones primaria del fabricante: trátalos como orientativos, no exactos.

NVIDIA Isaac GR00T N1 y su revisión N1.5 son modelos VLA orientados a humanoides, publicados abiertamente, con aproximadamente ~2,2B parámetros (cifra de fuente secundaria). NVIDIA afirma explícitamente que GR00T N1.5 corre en su placa Jetson Thor: es un objetivo de despliegue a bordo confirmado por el fabricante, no inferido.

π0 (pi-zero) de Physical Intelligence es un VLA de flow-matching con aproximadamente ~3B parámetros (fuente secundaria), publicado con pesos abiertos, construido sobre un backbone de visión-lenguaje de la clase PaliGemma (detalle de fuente secundaria). Ha atraído atención por su generación de acciones fluida y de alta frecuencia en comparación con diseños VLA anteriores.

OpenVLA, con 7.000 millones de parámetros, es la línea base académica habitual para la investigación en VLA: abierto, bien documentado, ampliamente usado como referencia de benchmark. Su tamaño lo convierte en el punto de referencia para "qué tan grande debe ser un VLA capaz", pero normalmente no es la primera opción para un presupuesto de latencia a bordo ajustado.

Gemini Robotics On-Device de Google DeepMind tiene un recuento de parámetros no divulgado y acceso restringido/de socios: no es una opción que la mayoría de los equipos puedan usar hoy. Lo que lo hace digno de seguimiento igualmente: Google DeepMind afirma que fue diseñado explícitamente para correr localmente en el robot sin conexión a internet. Esa es la señal más clara de un gran laboratorio de que la inferencia a bordo es ahora un objetivo de despliegue de primera clase, no una idea de investigación tardía añadida a un sistema pensado primero para la nube.

SmolVLA es un VLA compacto y abierto con aproximadamente ~450M parámetros (fuente secundaria): la opción realista cuando el hardware objetivo es genuinamente de bajo consumo (un acelerador pequeño en lugar de una placa completa de la clase Jetson), donde la huella de memoria y la latencia de paso hacia adelante de un modelo de 2–7B simplemente no caben en el presupuesto.

Octo y RT-2 son arquitecturas VLA de generaciones anteriores, útiles principalmente para el encuadre histórico de cómo el campo llegó a los diseños actuales de flow-matching y acción tokenizada: no es una recomendación vigente para una decisión de despliegue en 2026.

Más allá de la categoría VLA, NVIDIA afirma que los modelos generales Llama, Qwen y DeepSeek (LLM), además de Qwen2.5-VL y Llama 3.2 Vision (VLM), corren en Jetson Thor. Estos gestionan la capa de comprensión del lenguaje y descripción de escena en un stack de robot donde un VLA completo es innecesario: un robot de servicio que responde a una pregunta verbal, o un brazo de manipulación que lee una etiqueta de texto, no necesita ningún modelo de salida de acción en absoluto.

ROS 2 es el límite práctico entre el nivel de razonamiento lento y el nivel de control rápido en la mayoría de los stacks de robots en producción. Un nodo VLA publica una intención a nivel de tarea —una pose objetivo, un subobjetivo, un punto de agarre— como un mensaje de ROS 2, y un nodo de control clásico independiente se suscribe a ese mensaje y lo ejecuta a las frecuencias del bucle de control. El VLA nunca habla directamente con los motores; habla con un topic, y un nodo determinista posee todo lo que está aguas abajo de ese topic.

En hardware de NVIDIA (niveles Jetson Orin y Thor), TensorRT y TensorRT-LLM son la ruta de ejecución estándar para llevar un VLA o LLM cuantizado a su tasa de inferencia alcanzable: gestionan la fusión de kernels, la calibración de precisión (FP8/INT8/INT4) y la optimización específica de hardware que un bucle de inferencia ingenuo de PyTorch deja sobre la mesa. Saltarse este paso es la razón más común por la que un modelo que "debería" alcanzar una frecuencia Hz objetivo sobre el papel no la alcanza en la práctica.

Para objetivos a bordo más pequeños que no son de NVIDIA —un acelerador Hailo-10H, o una placa compacta basada en ARM— ExecuTorch y llama.cpp son las rutas de ejecución relevantes para los componentes de lenguaje/percepción. Ninguna de las dos es hoy un runtime VLA listo para usar; los equipos que apuntan a estas placas más pequeñas suelen ejecutar más un VLM compacto (para percepción/descripción de escena) que un VLA completo, con la planificación de tareas simplificada a lógica basada en reglas o ejecutada con menos frecuencia a una cadencia que el acelerador más pequeño pueda sostener.

El patrón de integración práctico, en orden: (1) el nodo VLA/VLM corre de forma asíncrona a su Hz alcanzable, publicando intención a un topic de ROS 2; (2) un planificador clásico se suscribe, convirtiendo la intención en una trayectoria; (3) un nodo de control ejecuta la trayectoria a 100–1.000 Hz, usando su propio bucle de retroalimentación de sensores, sin esperar nunca a la siguiente salida del VLA para actuar. Si el nodo VLA se atasca o se retrasa, el nodo de control continúa ejecutando la última trayectoria válida o mantiene la posición de forma segura; no se bloquea esperando al nivel lento.

Los robots móviles autónomos (AMR) en almacenes y la maquinaria agrícola representan la realidad desplegada de la autonomía robótica hoy: los humanoides reciben la cobertura mediática pero son la clase de máquina menos desplegada de las tratadas en este artículo. Esta brecha importa para cualquiera que decida dónde invertir tiempo de ingeniería: la categoría de robot más intensiva en cómputo y más discutida es también la que tiene menos unidades realmente corriendo en entornos de producción ahora mismo.

Los humanoides son la clase más intensiva en cómputo y menos desplegada: llevan más sensores, más grados de libertad, y en consecuencia la carga de trabajo del nivel de razonamiento más pesada (múltiples flujos de cámara, planificación de tareas de cuerpo completo), que es exactamente por qué son el objetivo principal del silicio a bordo más nuevo y capaz (Jetson Thor) y de las arquitecturas VLA más recientes (GR00T N1.5). Su volumen de despliegue hoy es pequeño en relación con la atención que reciben.

Los robots móviles autónomos (AMR) —los robots con ruedas que mueven inventario en almacenes— se han desplegado comercialmente a escala significativa durante años, ejecutando stacks clásicos de navegación y evitación de obstáculos. Lo que está cambiando en 2026 es la adición de una capa de interfaz de lenguaje/visión sobre un stack de autonomía ya maduro: un VLM para descripción de escena o una capa de planificación de tareas ligera que permite a un humano dar una instrucción en lenguaje natural, no un reemplazo total de la lógica de navegación subyacente.

Los brazos industriales en celdas de fabricación fijas se sitúan entre estos extremos: la planificación de movimiento y el control suelen ser completamente clásicos desde hace décadas (un brazo de soldadura o de recoger-y-colocar no necesita un VLA para repetir una trayectoria enseñada), pero las capas de percepción —detección de defectos, identificación de piezas— usan cada vez más modelos de visión ligeros, donde una posición de cámara fija y una tarea acotada hacen que un modelo más pequeño y entrenado con un propósito específico sea suficiente sin un VLA completo.

La maquinaria agrícola es la clase de despliegue más frecuentemente pasada por alto en la cobertura de "robótica con IA", a pesar de haber desplegado autonomía comercial —dirección guiada por GPS, detección de obstáculos en tractores y cosechadoras— a escala durante años, mucho antes de la ola VLA actual. Lo que se está añadiendo ahora sigue el mismo patrón que en los AMR: una capa de interfaz de lenguaje/visión (identificación de cultivos o malezas, comandos del operador en lenguaje natural) sobre sistemas de navegación y control que ya eran autónomos y ya eran clásicos.

Tres categorías de hardware cubren la mayor parte de una construcción de inferencia a bordo de un robot: un kit de desarrollo de la clase Jetson para el nivel de razonamiento, una o más cámaras de profundidad/estéreo para la entrada de percepción, y una plataforma de desarrollo robótico sobre la que montar todo. Esta sección nombra categorías, no SKUs específicos, precios o afirmaciones del fabricante: verifica las especificaciones y precios actuales directamente con cada fabricante antes de comprar, ya que ambos cambian más rápido de lo que un artículo puede seguir.

Los kits de desarrollo Jetson Orin y Jetson Thor son el punto de partida estándar para evaluar un VLA o VLM a bordo: consulta Hardware Edge AI para LLM locales para el desglose nivel por nivel (de Orin Nano a AGX Thor) que cubre la envolvente de potencia y el cómputo relativo.

Las cámaras de profundidad o estéreo son la entrada de percepción estándar para un VLA: la mayoría de la investigación VLA publicada y los diseños de referencia de fabricantes asumen entrada RGB-D o estéreo en lugar de RGB monocular únicamente, ya que la profundidad simplifica la estimación del punto de agarre y la distancia a obstáculos de la que depende la capa de salida de acción.

Una plataforma de desarrollo robótico —una plataforma de referencia con ruedas o basada en brazo en lugar de una construcción mecánica desde cero— es el punto de partida práctico para un equipo que valida una integración VLA antes de comprometerse con hardware personalizado.

Cuatro cargas de trabajo permanecen fuera del robot incluso en una arquitectura agresivamente local-first: aprendizaje de flota, actualizaciones de modelo, intercambio de contexto entre robots y simulación pesada. Ninguna de ellas es sensible a la latencia como lo son la percepción o la planificación de tareas, y todas se benefician de cómputo y datos a los que ningún robot individual tiene acceso.

El aprendizaje de flota —agregar experiencia de muchos robots desplegados para mejorar una política o modelo compartido— necesita inherentemente datos de más unidades de las que lleva un solo robot, y el cómputo de entrenamiento involucrado está muy por encima del presupuesto o propósito de un acelerador a bordo.

Las actualizaciones de modelo (un nuevo checkpoint de VLA, un modelo de percepción ajustado) se empujan al robot en lugar de entrenarse en él; el robot es un objetivo de inferencia, no un nodo de entrenamiento, en prácticamente todos los patrones de despliegue de producción usados hoy.

El contexto entre robots —un robot beneficiándose de lo que otro robot en la misma flota acaba de observar— requiere un backend compartido, ya que no existe un mecanismo a bordo útil para que un robot acceda directamente al historial de sensores de otro.

La simulación pesada —las cargas de trabajo de física y renderizado a gran escala usadas para generar datos de entrenamiento o validar una política antes del despliegue— corre en cómputo de clase centro de datos por la misma razón que el aprendizaje de flota: el presupuesto de cómputo no tiene equivalente a bordo.

En la UE, un componente de IA que funciona como componente de seguridad de maquinaria se trata como de alto riesgo bajo la Ley de IA de la UE, y el Reglamento de Máquinas de la UE (2023/1230) —aplicable desde enero de 2027— exige por separado una evaluación de conformidad para maquinaria con una función de seguridad impulsada por IA. Un robot con un modelo en la ruta de una función de seguridad puede necesitar satisfacer ambos marcos, no solo uno.

Esto es nuestro propio análisis razonado, no una orientación regulatoria publicada: la arquitectura de dos niveles descrita a lo largo de este artículo —mantener las funciones de seguridad (paradas de emergencia, límites de par, enclavamientos de colisión) en código de control clásico y determinista, y confinar el nivel de razonamiento VLA/LLM a roles consultivos o de nivel de tarea que nunca condicionan directamente una función de seguridad— probablemente reduce la carga de la evaluación de conformidad, porque una función de seguridad certificable necesita un comportamiento caracterizable de forma exhaustiva por adelantado, algo que el código determinista puede ofrecer y una red neuronal grande actualmente no puede. No tenemos constancia de que ningún regulador haya publicado orientación específica que confirme este enfoque; trátalo como un argumento técnico-regulatorio para evaluar con tu propio asesor legal, no como una garantía de cumplimiento.

Esto no constituye asesoramiento legal. El alcance de la evaluación de conformidad, las normas armonizadas aplicables y la clasificación específica de las funciones de seguridad de un robot dado dependen del diseño real del sistema y de la jurisdicción de venta: consulta a un asesor legal y regulatorio cualificado antes de tomar una determinación de cumplimiento para un producto específico.