💻 computer science

Characterizing Vision-Language-Action Models across XPUs: Constraints and Acceleration for On-Robot Deployment

Este artículo aborda los desafíos de desplegar modelos Visión-Lenguaje-Acción (VLA) en robots con recursos limitados mediante la evaluación sistemática de las compensaciones entre modelo y hardware en diversos aceleradores, la identificación de un cuello de botella en la inferencia de dos fases y la propuesta de las técnicas DP-Cache y V-AEFusion para lograr aceleraciones significativas tanto en GPUs como en NPUs de borde con una pérdida mínima de rendimiento.

Autores originales: Kaijun Zhou, Qiwei Chen, Da Peng, Zhiyang Li, Xijun Li, Jinyu Gu

Publicado 2026-04-28

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Kaijun Zhou, Qiwei Chen, Da Peng, Zhiyang Li, Xijun Li, Jinyu Gu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando enseñar a un robot a realizar una tarea, como recoger una taza o limpiar una mesa. Para lograrlo, el robot necesita un "cerebro" llamado modelo de Visión-Lenguaje-Acción (VLA). Este cerebro observa el mundo (Visión), comprende lo que dices (Lenguaje) y decide qué hacer (Acción).

El problema es que estos cerebros son actualmente muy pesados y lentos de ejecutar, especialmente en un robot que necesita moverse en tiempo real sin chocar. La mayoría de los investigadores han estado probando estos cerebros en superordenadores masivos y costosos (como un ordenador de escritorio de gama alta), pero los robots reales necesitan ejecutarse en dispositivos más pequeños, baratos y alimentados por baterías.

Este artículo es como una guía de mecánico y un afinador de rendimiento para estos cerebros de robots. Aquí está lo que descubrieron y cómo lo solucionaron, explicado de forma sencilla:

1. La analogía del coche "del tamaño adecuado"

Los investigadores se hicieron una pregunta sencilla: ¿Realmente necesitamos un motor de coche de carreras de Fórmula 1 para ir a la tienda de comestibles?

La vieja forma: Todos asumían que necesitabas la tarjeta gráfica más potente y costosa (como una NVIDIA RTX 4090) para ejecutar estos cerebros de robots. Es como poner un motor de coche de carreras en una minivan. Es rápido, pero cuesta una fortuna y consume mucha gasolina (energía).
El nuevo descubrimiento: Crearon una Tabla de clasificación (un marcador) que probó estos cerebros de robots en muchos tipos diferentes de hardware, desde ordenadores de escritorio potentes hasta chips más pequeños y baratos encontrados en dispositivos de borde.
El resultado: Descubrieron que para muchas tareas, un motor más pequeño "del tamaño adecuado" (un chip más barato y de menor potencia) es en realidad mejor. Es más barato de comprar, consume menos batería y es lo suficientemente rápido para hacer el trabajo perfectamente. No siempre necesitas la herramienta más grande y costosa para el trabajo.

2. El problema del "baile de dos pasos"

Cuando observaron de cerca cómo funcionan estos cerebros de robots, descubrieron un extraño problema de ritmo. El cerebro no funciona a una velocidad constante; tiene dos fases distintas, como un baile de dos pasos:

Paso 1: El Pensador (Modelo Visión-Lenguaje): Esta parte mira la cámara y comprende la escena. Trabaja muy duro, utilizando casi el 100% de la capacidad cerebral del ordenador. Es como un corredor de maratón haciendo un sprint.
Paso 2: El Planificador (Experto en Acción): Esta parte decide exactamente cómo mover el brazo. Sorprendentemente, esta parte es muy perezosa con la potencia del ordenador. Mayormente espera a que se traigan datos desde la memoria, dejando al potente ordenador sentado inactivo. Es como un velocista que se detiene a atarse los cordones de los zapatos durante la mitad de la carrera.

El cuello de botella: Como estos dos pasos ocurren uno después del otro (secuencialmente), el potente ordenador pasa mucho tiempo esperando mientras el "Planificador" es lento. Esto desperdicia energía y ralentiza todo.

3. Las soluciones: "Saltar pasos" y "Estacionamiento en paralelo"

Para solucionar esto, el equipo inventó dos trucos inteligentes para hacer al robot más rápido sin hacerlo "más tonto" (perder precisión).

Truco A: La caché "Saltar-paso" (DP-Cache)

La parte del "Planificador" a menudo funciona dando 100 pequeños pasos para calcular un movimiento, como dibujar un boceto una y otra vez hasta que sea perfecto.

La solución: Los investigadores notaron que, en medio de este proceso, el boceto no cambia mucho durante un tiempo. Así que construyeron una Caché (un atajo de memoria). Una vez que el boceto se estabiliza, el robot simplemente reutiliza el resultado anterior en lugar de recalcularlo desde cero.
La analogía: Imagina que estás pintando una pared. En lugar de mezclar pintura nueva y aplicarla en cada pulgada cuadrada, te das cuenta de que la sección central ya está seca y perfecta, así que simplemente saltas pintarla y te mueves a los bordes. Esto les ahorró hasta 6 veces la velocidad en algunos chips más pequeños.

Truco B: La "línea de montaje" (V-AEFusion)

Dado que el "Pensador" y el "Planificador" suelen trabajar uno después del otro, el ordenador se queda inactivo.

La solución: Hicieron que las dos partes trabajaran al mismo tiempo, como una línea de montaje. Mientras el "Pensador" mira la escena actual, el "Planificador" comienza a trabajar en el siguiente movimiento utilizando los datos de la escena anterior. Como los robots se mueven lentamente, la escena "anterior" es casi idéntica a la "actual", por lo que el "Planificador" no se confunde.
La analogía: Imagina a un chef (Pensador) picando verduras y a un cocinero (Planificador) friendolas. En lugar de esperar a que el chef termine todo el picado antes de que el cocinero empiece a freír, el cocinero empieza a freír el primer lote mientras el chef sigue picando el segundo lote. Esto mantiene la cocina (el ordenador) ocupada y en movimiento más rápido.

4. La conclusión

El artículo concluye que:

No gastes en exceso: No siempre necesitas el ordenador más costoso para ejecutar un robot. Chips más pequeños y baratos pueden hacer el trabajo igual de bien si eliges el adecuado.
Entiende el ritmo: Los cerebros de robots tienen una fase "ocupada" y una fase "de espera".
Atajos inteligentes: Al saltar cálculos redundantes y permitir que diferentes partes del cerebro trabajen en paralelo, puedes hacer que los robots sean de 2 a 6 veces más rápidos sin necesidad de volver a entrenarlos ni gastar más dinero.

Incluso construyeron un sitio web público (una tabla de clasificación) donde cualquiera puede verificar qué cerebro de robots funciona mejor en qué chip de ordenador específico, ayudando a los ingenieros a construir robots mejores y más baratos.

1. Declaración del Problema

Los modelos Visión-Lenguaje-Acción (VLA) ofrecen una gran promesa para el control de robots generalistas, pero su despliegue en robots físicos se ve severamente limitado por las restricciones de inferencia en tiempo real bajo presupuestos estrictos de costo y energía.

La Brecha: La mayoría de las evaluaciones anteriores se basan en GPUs de escritorio de gama alta (por ejemplo, NVIDIA RTX 4090), lo que oculta las compensaciones involucradas en el despliegue de estos modelos en aceleradores de borde heterogéneos (GPUs, NPUs, XPUs) utilizados en robots reales.
El Desafío: Los profesionales carecen de un marco sistemático para determinar:
1. Qué plataforma de hardware de "tamaño adecuado" satisface las tasas de control en tiempo real (latencia) mientras minimiza el costo de adquisición y el consumo de energía.
2. Cuáles son los cuellos de botella computacionales específicos en los bucles de inferencia de VLA en hardware restringido.
La Realidad: Simplemente reducir el tamaño del modelo no garantiza una inferencia más rápida, y las GPUs insignia a menudo conducen a una mala relación costo-eficiencia o a una subutilización del hardware debido a características computacionales desajustadas.

2. Metodología

Los autores proponen un enfoque de co-caracterización modelo-hardware que involucra tres pilares principales:

A. Tabla de Clasificación entre Aceleradores (Marco CET)

Marco: Construyeron una tabla de clasificación interactiva que evalúa pipelines VLA representativos en aceleradores heterogéneos (GPUs de NVIDIA, XPUs Intel Arc, NPUs Huawei Ascend).
Métricas: Introdujeron la métrica CET:
- Tiempo (T): Latencia de extremo a extremo/frecuencia de control (umbral de viabilidad).
- Costo (C): Costo de adquisición del hardware.
- Energía (E): Consumo de energía durante la inferencia.
Clasificación: Los modelos se clasifican como Consumidores "Pequeños" o "Grandes" según la cantidad de parámetros; el hardware se clasifica como Productores "Básicos", "Estándar" o "Ultra" según los FLOPS pico y la capacidad de VRAM.

B. Perfilado Sistemático y Análisis Roofline

Perfilado: Utilizando herramientas como Nsight Systems, analizaron la descomposición de la latencia y la utilización del hardware (utilización de SM) de los flujos de trabajo VLA.
Modelo Roofline: Aplicaron el modelo Roofline para determinar si componentes específicos de VLA están limitados por cómputo (limitados por FLOPS) o limitados por memoria (limitados por ancho de banda).

C. Optimizaciones Algorítmicas y del Sistema

Basándose en las perspectivas del perfilado, desarrollaron dos técnicas de aceleración sin entrenamiento:

DP-Cache (Caché de Política de Difusión): Apunta al Experto de Acción (módulo de difusión) para omitir pasos intermedios redundantes.
V-AEFusion (Fusión VLM-Experto de Acción): Una estrategia de paralelismo de pipeline que superpone la inferencia del backbone VLM con las etapas tempranas del Experto de Acción.

3. Hallazgos Clave y Contribuciones

Contribución 1: La Perspectiva de Despliegue de "Tamaño Adecuado"

Hallazgo: El tamaño del modelo no es un predictor definitivo de la velocidad de inferencia. Contra intuitivamente, modelos más pequeños con políticas de difusión iterativas (por ejemplo, 100 pasos) pueden ser más lentos que modelos más grandes con menos pasos (por ejemplo, 4 pasos).
Resultado: Los dispositivos de borde de "tamaño adecuado" (por ejemplo, Jetson Orin, Ascend 310P) a menudo proporcionan una mejor relación costo/energía que las GPUs insignia (RTX 4090) mientras cumplen con las restricciones de tasa de control. La RTX 4090 no es invariablemente la mejor opción para el despliegue.

Contribución 2: El Desequilibrio Computacional de Dos Fases

Hallazgo: La inferencia VLA exhibe un patrón dual-fase distintivo:
1. Backbone VLM: Limitado por cómputo. Alta intensidad aritmética (por ejemplo, ~840 FLOPs/Byte en RTX 4090), lo que lleva a una alta utilización del hardware (>90%).
2. Experto de Acción: Limitado por memoria. Baja intensidad aritmética (por ejemplo, ~64 FLOPs/Byte), lo que lleva a una subutilización severa (uso de SM del 20–40%) y dominancia de latencia.
Implicación: Esta transición de fase causa un desperdicio significativo de recursos, ya que las unidades de cómputo de alto rendimiento permanecen inactivas durante la fase del Experto de Acción limitada por memoria.

Contribución 3: Técnicas de Aceleración

DP-Cache: Explota la redundancia temporal en las políticas de difusión. Al almacenar en caché los resultados durante segmentos de difusión estables (pasos 20–80), omite cálculos redundantes.
- Resultado: Aceleración de 1.9× en GPUs con una degradación mínima de la tasa de éxito (SR).
V-AEFusion: Explota el desequilibrio de latencia entre el VLM y el Experto de Acción. Ejecuta los pasos iniciales de "desenfoque" (denoising) "obsoletos" del Experto de Acción (utilizando características del cuadro anterior) en paralelo con la inferencia actual del VLM.
- Resultado: Aceleración de 1.3× en GPUs.
Impacto Combinado: Cuando se combina con compilación de modelos (por ejemplo, torch.compile, ATC), el sistema logra hasta 2.9× de aceleración en GPUs y 6× de aceleración en NPUs de borde (Ascend 310P).

4. Resumen de Resultados

Tabla de Clasificación: Los autores proporcionan una tabla de clasificación pública (vla-leaderboard-01.vercel.app) que permite a los usuarios filtrar modelos por restricciones de hardware (VRAM, Costo, Energía) para encontrar combinaciones óptimas.
Ganancias de Rendimiento:
- RTX 4090: 2.9× de aceleración (de ~102 ms a ~35 ms para $\pi_0$ ).
- Ascend 310P (NPU): 6.0× de aceleración (de ~1853 ms a ~310 ms para Política de Difusión).
- Validación en el Mundo Real: Validado en un brazo Franka y un robot de doble brazo JAKA, mostrando la finalización exitosa de tareas (por ejemplo, limpieza de mesa, manipulación de bloques) con solo caídas marginales en la tasa de éxito (por ejemplo, <6% de caída en SR).
Sensibilidad al Hardware: Las optimizaciones como la compilación de modelos muestran una efectividad variable en diferentes hardware (por ejemplo, 2.9× en 4090 vs. 1.5× en Jetson Thor), destacando la necesidad de ajuste específico para cada hardware.

5. Significado

Cambio de Paradigma: Mueve el campo de "modelos más grandes en GPUs más grandes" a un enfoque de co-diseño a nivel de sistema, demostrando que las NPUs de borde y las GPUs de gama media pueden ser más eficientes para la robótica que las GPUs de consumo insignia.
Despliegue Práctico: Proporciona una guía de selección concreta y reproducible (análisis CET) para que los profesionales elijan hardware basándose en restricciones específicas del robot (batería vs. costo vs. velocidad).
Perspectiva Arquitectónica: Identifica la naturaleza limitada por memoria del Experto de Acción como un cuello de botella crítico, desplazando el enfoque de la optimización futura desde la compresión pura de modelos hacia el paralelismo de pipeline y la optimización del ancho de banda de memoria.
Ciencia Abierta: El lanzamiento de una tabla de clasificación multiplataforma y código de optimización sin entrenamiento reduce la barrera para el despliegue de VLA en robots con recursos limitados.

En conclusión, este artículo establece que un despliegue eficiente de VLA en robots requiere comprender las características computacionales específicas de las fases del modelo y combinarlas con hardware y estrategias de pipeline apropiadas, en lugar de depender simplemente de la potencia bruta de cómputo.