💻 computer science

How Fast Can I Run My VLA? Demystifying VLA Inference Performance with VLA-Perf

Este artículo presenta VLA-Perf, un modelo analítico que realiza el primer estudio sistemático del rendimiento de inferencia de los modelos Visión-Lenguaje-Acción (VLA) para ofrecer orientación práctica sobre cómo diseñar arquitecturas y sistemas de despliegue que cumplan con las estrictas restricciones de tiempo real.

Autores originales: Wenqi Jiang, Jason Clemons, Karu Sankaralingam, Christos Kozyrakis

Publicado 2026-02-23

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Wenqi Jiang, Jason Clemons, Karu Sankaralingam, Christos Kozyrakis

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

¡Claro que sí! Imagina que los Modelos Visuales-Lenguaje-Acción (VLA) son como el "cerebro" de un robot moderno. Este cerebro no solo ve lo que pasa a su alrededor (como una cámara) y entiende lo que le decimos (como un humano), sino que también decide qué movimiento físico hacer (como mover un brazo).

El problema es que, para que un robot sea útil en la vida real (como ayudar en una cocina o conducir un coche), su cerebro debe pensar extremadamente rápido. Si tarda demasiado, el robot se vuelve torpe o peligroso.

Los autores de este paper (de NVIDIA) se preguntaron: "¿Qué tan rápido pueden correr estos cerebros de robots y cómo podemos hacerlos más rápidos?"

Para responder, crearon una herramienta llamada VLA-Perf. Imagina que VLA-Perf es como un "simulador de videojuegos" o un "laboratorio virtual". En lugar de construir 100 robots reales y probarlos (lo cual costaría millones y tardaría años), usan este simulador para predecir cómo se comportarán diferentes diseños de robots en diferentes escenarios.

Aquí te explico sus descubrimientos principales con analogías sencillas:

1. El tamaño importa (pero hay un límite)

La analogía: Imagina que el modelo es un estudiante. Un estudiante con un cerebro pequeño (modelo pequeño) puede responder rápido, pero quizás no sea muy inteligente. Un estudiante con un cerebro gigante (modelo grande) es un genio, pero tarda más en procesar la información.
El hallazgo: Si usas computadoras muy potentes (como las de los centros de datos, "Datacenter GPUs"), puedes usar cerebros gigantes y seguir siendo rápido. Pero si intentas poner ese cerebro gigante en un robot pequeño (como un ordenador de bolsillo o "edge GPU"), el robot se vuelve lento y torpe.
- Conclusión: Para robots pequeños, necesitas cerebros más ligeros. Para robots grandes y potentes, puedes usar cerebros gigantes.

2. ¿Dónde debe vivir el cerebro? (En el robot o en la nube)

La analogía: Imagina que eres un chef (el robot).
- Opción A (En el robot): Tienes todos los ingredientes y recetas en tu propia cocina. Es rápido porque no tienes que llamar a nadie, pero tu cocina es pequeña.
- Opción B (En el servidor/nube): Tienes una cocina pequeña, pero llamas a un chef experto en una cocina gigante a kilómetros de distancia. El chef experto es increíble, pero tienes que esperar a que te envíe la receta por teléfono. Si la línea telefónica es mala, tardas mucho.
El hallazgo:
- Si tienes una conexión de internet rápida (como fibra óptica o 5G bueno), es mejor usar el "chef experto" en la nube. Es mucho más rápido que intentar hacerlo todo tú mismo en el robot.
- Si tu internet es lento o inestable (como en medio del desierto), es mejor que el robot piense por sí mismo, aunque sea un poco menos inteligente.

3. El truco de la "Asincronía" (Hacer dos cosas a la vez)

La analogía: Imagina que estás cocinando una sopa.
- Sincronizado: Cortas la cebolla, esperas a que termine de picar, luego la echas a la olla, esperas a que hierva, y luego cortas la zanahoria. Todo es en serie.
- Asincrónico: Mientras la cebolla se cocina sola en la olla, tú ya estás picando la zanahoria. No esperas a que termine un paso para empezar el siguiente.
El hallazgo: Permitir que el robot piense en el siguiente movimiento mientras aún está ejecutando el anterior (o mientras espera la respuesta de internet) hace que el sistema sea mucho más rápido, especialmente si la conexión a internet es lenta.

4. ¿Cuántos pasos de "limpieza" necesita el robot?

La analogía: Algunos modelos de IA (los que usan "difusión") funcionan como un artista que dibuja una imagen borrosa y luego la va limpiando paso a paso hasta que sale perfecta. Cada paso de limpieza toma tiempo.
El hallazgo: Si pides al robot que haga 50 pasos de limpieza para decidir un movimiento, tardará mucho. Si reduces esos pasos a 10, se vuelve mucho más rápido y sigue siendo bastante preciso. Es un equilibrio entre "perfume" y "velocidad".

5. El futuro: ¿10 veces por segundo o 100 veces?

Los autores definen dos metas:

10 Hz (10 veces por segundo): Es como un ritmo de baile normal. Es suficiente para la mayoría de las tareas.
100 Hz (100 veces por segundo): Es como un velocista olímpico. Necesario para tareas muy complejas o de alta precisión.

Sus 15 conclusiones clave (simplificadas):

Las computadoras de centros de datos actuales ya son lo suficientemente rápidas para robots pequeños.
Los robots pequeños (con chips de bajo consumo) sufren mucho si el modelo es muy grande.
Hacer el modelo más grande lo hace más lento de forma lineal (si duplicas el tamaño, duplicas el tiempo).
Los chips de centros de datos pueden manejar modelos 30 veces más grandes que los actuales y seguir siendo rápidos.
Si el robot necesita recordar el pasado (contexto largo), los chips potentes pueden manejarlo, pero los pequeños no.
El número de pasos de "limpieza" (denoising) es lo que más afecta la velocidad.
El tamaño del "paquete" de acciones (cuántos movimientos predice a la vez) no afecta mucho la velocidad.
Los modelos que generan acciones paso a paso (autoregresivos) son lentos; los que usan "difusión" son mucho más rápidos.
Usar un servidor (nube) es casi siempre mejor que usar solo el robot, a menos que tu internet sea terrible.
Intentar dividir el trabajo entre el robot y el servidor (colaboración) suele ser más lento que hacerlo todo en el servidor.
La "asincronía" (hacer cosas a la vez) es un superpoder para redes lentas.
Los sistemas de "doble cerebro" (uno rápido y uno lento) ayudan, pero dependen mucho de la red.
Para llegar a 100 Hz en un robot pequeño, hay que reducir el tamaño del modelo drásticamente.
Para llegar a 100 Hz en un servidor, necesitas chips muy potentes y buena internet.
Para llegar a 100 Hz en la nube, la asincronía es obligatoria.

En resumen

Este paper nos dice que no hay una solución mágica única. Diseñar un robot rápido es como armar un equipo de fútbol:

Si tienes un estadio pequeño (robot con recursos limitados), necesitas jugadores ágiles y ligeros (modelos pequeños).
Si tienes un estadio gigante (servidor potente), puedes tener jugadores gigantes y geniales, pero necesitas un transporte rápido (internet rápido) para que lleguen a tiempo.
Y siempre, siempre, es mejor que el equipo trabaje en paralelo (asincronía) en lugar de esperar a que uno termine para que empiece el siguiente.

¡Espero que esta explicación te haya ayudado a entender cómo los científicos están aprendiendo a hacer que los robots piensen más rápido!

1. El Problema

Los modelos Visión-Lenguaje-Acción (VLA) han demostrado capacidades impresionantes en tareas de inteligencia artificial encarnada (embodied AI), permitiendo a los robots percibir, razonar y actuar. Sin embargo, desplegar estos modelos en robots del mundo real impone restricciones estrictas de inferencia en tiempo real (baja latencia y alto rendimiento).

El desafío principal es que el panorama de rendimiento de inferencia de los VLA es un espacio combinatorio vasto y poco comprendido, determinado por la interacción de:

Arquitecturas de modelos: Tamaño, diseño (autoregresivo vs. difusión), contexto largo, pasos de denoising, etc.
Sistemas de inferencia: Hardware (desde GPUs de borde como Jetson Thor hasta centros de datos como B100), ubicación de la inferencia (dispositivo, servidor de borde, nube) y configuración de red (cableada, WiFi, 4G/5G).

La falta de una comprensión sistemática dificulta la respuesta a preguntas fundamentales: ¿Cómo diseñar modelos y sistemas para lograr inferencia en tiempo real? ¿Qué combinaciones de hardware y software son viables para frecuencias de 10 Hz a 100 Hz?

2. Metodología: VLA-Perf

Para abordar este problema, los autores introducen VLA-Perf, un modelo de rendimiento analítico basado en el "roofline" (techo de rendimiento).

Enfoque: En lugar de realizar evaluaciones empíricas exhaustivas (que serían costosas y limitadas a configuraciones existentes), VLA-Perf predice la latencia y el rendimiento óptimos para combinaciones arbitrarias de modelos y sistemas.
Modelado:
- Descompone el flujo de inferencia en componentes (codificador de visión, backbone VLM, experto de acción) y transferencias de datos (locales o de red).
- Calcula la latencia total ( $T_{total}$ ) como la suma de la latencia de inferencia del modelo y la latencia de movimiento de datos.
- Utiliza el modelo roofline para estimar la latencia de cada operador basándose en el límite de cómputo (FLOPS) y el ancho de banda de memoria del hardware.
- Considera configuraciones asíncronas, pipelines de doble sistema, y contextos largos.
Validación: El modelo se validó contra implementaciones reales de Triton en una RTX 4090, logrando una fidelidad del 73% al 82% respecto al rendimiento teórico, lo que se considera suficiente para guiar el diseño.

3. Contribuciones Clave

El estudio sistemático realizado con VLA-Perf genera 15 conclusiones clave (takeaways) que guían el diseño futuro. Las más destacadas se agrupan en dos categorías:

A. Diseño de Modelos (Model Design Knobs)

Escalado de modelos: La latencia escala linealmente con el tamaño del modelo. Las GPUs de centros de datos (ej. B100) pueden manejar modelos VLA más de 30 veces más grandes que los actuales manteniendo inferencia en tiempo real, mientras que las GPUs de borde (Jetson Thor) luchan incluso con modelos pequeños.
Contexto Largo: Las GPUs de centros de datos pueden soportar inferencia con contextos de hasta 1.000 pasos temporales en tiempo real, mientras que las GPUs de borde y consumidoras se limitan a ~100 pasos debido a restricciones de memoria y ancho de banda.
Arquitectura de Acción: Los modelos basados en difusión son significativamente más rápidos (1-2 órdenes de magnitud) que los modelos autoregresivos estándar cuando se utiliza "chunking" de acciones. Los modelos autoregresivos solo son competitivos con decodificación paralela o en espacios de acción muy pequeños.
Pasos de Denoising vs. Chunk Size: El número de pasos de denoising tiene un impacto lineal y significativo en la latencia. En cambio, el tamaño del "chunk" de acción tiene un efecto marginal porque la predicción de acción está limitada por el ancho de banda de memoria, no por el cómputo.

B. Despliegue de Sistemas (System Knobs)

Ubicación de la Inferencia: La inferencia en el servidor (incluso con GPUs de consumo como RTX 4090) supera a la inferencia en el dispositivo (Jetson Thor) en la mayoría de los escenarios, excepto en condiciones de red extremadamente pobres (4G lento o nube lejana).
Colaboración Dispositivo-Servidor: Dividir la carga (VLM en servidor, experto de acción en dispositivo) suele ser más lento que usar solo el servidor o solo el dispositivo, debido a la latencia de descargar el caché KV del VLM al dispositivo.
Inferencia Asíncrona: En entornos de servidor con redes lentas (WiFi, 5G), la inferencia asíncrona (superponiendo transmisión de red y cómputo) puede mejorar el rendimiento (throughput) entre 2.6x y 13x, aunque no reduce la latencia final.
Pipelines de Doble Sistema: Un diseño donde un sistema lento (VLM) actualiza un sistema rápido (experto de acción) puede ofrecer mejoras de rendimiento, pero dependen críticamente de la capacidad del hardware y la latencia de red.

4. Resultados y Escenarios de Rendimiento

El estudio define dos objetivos de rendimiento: 10 Hz (aceptable, cerca de la ingesta de video) y 100 Hz (alto rendimiento).

Inferencia en Dispositivo (On-Device):
- 10 Hz: Alcanzable con la GPU de borde más avanzada (Jetson Thor) en modelos actuales (π0).
- 100 Hz: Requiere optimizaciones a nivel de modelo (reducir tamaño, pasos de difusión o cuantización), ya que el hardware actual no es suficiente.
Inferencia en Servidor de Borde (Edge-Server):
- 10 Hz: Alcanzable con GPUs de consumo (RTX 4090) incluso en redes 4G.
- 100 Hz: Requiere GPUs de centro de datos (B100) y redes rápidas (Ethernet 10G o WiFi 7).
Inferencia en la Nube (Cloud-Server):
- 10 Hz: Factible con buena conectividad.
- 100 Hz: Generalmente requiere inferencia asíncrona. La latencia de red por sí sola (más de 10 ms por ida/vuelta) impide alcanzar 100 Hz en modo síncrono, incluso con hardware potente.

5. Significado e Impacto

Este trabajo es fundamental porque:

Desmitifica el rendimiento VLA: Proporciona la primera visión sistemática y cuantitativa de cómo interactúan las decisiones de diseño de modelos con las limitaciones del sistema de despliegue.
Guía de Diseño Práctica: Ofrece criterios claros para ingenieros y investigadores:
- Si se necesita alta frecuencia (>100 Hz), la inferencia en la nube requiere asincronía.
- Si se usa hardware de borde, se deben priorizar modelos pequeños y arquitecturas de difusión.
- Evitar la colaboración dispositivo-servidor a menos que se tenga una red de 10Gbps cableada.
Herramienta Abierta: Al liberar VLA-Perf como código abierto, permiten que la comunidad evalúe futuras arquitecturas y configuraciones de hardware sin necesidad de costosos despliegues físicos.

En resumen, el artículo establece que no existe una solución única para la inferencia VLA en tiempo real; la elección óptima depende de un equilibrio preciso entre la arquitectura del modelo, la potencia del hardware y las condiciones de la red, y que el uso de modelos de difusión y estrategias asíncronas es crucial para escalar hacia frecuencias de control robótico más altas.