🔬 Anatomía de un VLA: visión + lenguaje + acción
Desarmando la arquitectura por dentro: cómo se conectan el encoder visual, el backbone de lenguaje y el decodificador de acciones para transformar píxeles y palabras en movimiento físico.
👁️ Codificador visual: SigLIP, DINOv2, ViT
El encoder visual es el primer paso de la percepción: convierte cada frame de la cámara en vectores densos que el backbone de lenguaje puede "leer". La elección del encoder —SigLIP, DINOv2 o ViT puro— define lo que el robot es capaz de ver con precisión.
🔍 Cómo funciona el patch embedding
La imagen de 224×224 píxeles se divide en patches de 14×14 o 16×16 píxeles. Cada patch se proyecta linealmente en un vector denso de alta dimensión (normalmente de 768 o 1024 dimensiones). Estos vectores —los visual tokens — son el lenguaje interno que el encoder usa para comunicarse con el backbone LLM.
Una imagen de 224×224 con parches de 14×14 genera 256 visual tokens. Cada token contiene información local sobre textura, color y bordes; en conjunto, representan la estructura espacial de toda la escena.
✓ SigLIP y DINOv2 destacan cuando
- ✓SigLIP: la tarea exige alinear objetos con nombres ("toma el vaso azul")
- ✓DINOv2: la tarea exige estimación de profundidad o segmentación implícita
- ✓Dual encoder (SigLIP + DINOv2): combina ambos — estándar en OpenVLA
- ✓Una resolución mayor (336×336) mejora la manipulación precisa de objetos pequeños
✗ Errores comunes
- ✗Usar un encoder entrenado solo con imágenes web — pierde geometría 3D
- ✗Congelar el encoder durante el fine-tuning — las features no se adaptan a la tarea
- ✗Resolución muy baja (112×112): un objeto de 2 cm se convierte en ruido de 1 token
- ✗Ignorar la projection layer — los visual tokens necesitan una escala compatible con el LLM
🧠 Backbone LLM: Llama, Gemma, Qwen
El backbone LLM es el cerebro central de VLA. Fusiona los visual tokens con los text tokens, razona sobre la escena y decide qué hacer. La elección del backbone —y la cantidad de parámetros que tiene— define el compromiso fundamental entre capacidad de razonamiento y latencia de respuesta.
💡 ¿Por qué reutilizar un LLM preentrenado?
Modelos como Llama 3, Gemma 2 y Qwen 2.5 se entrenaron con billones de tokens de texto. Ya «saben» qué es un vaso, dónde está el fregadero y cómo seguir instrucciones compuestas como «coloca el tenedor a la izquierda del plato». Entrenar este conocimiento desde cero para cada robot sería prohibitivamente caro: reutilizarlo es clave para la generalización.
Flujo de procesamiento dentro del backbone
Projection Layer
Una MLP simple (2 capas lineales) mapea los visual tokens del espacio del encoder (p. ej., 1024 dims) al espacio de embedding del LLM (p. ej., 4096 dims). Este «traductor» es el único componente nuevo que debe entrenarse desde cero.
Fusión multimodal
Los tokens visuales y los tokens de texto se concatenan en una secuencia unificada. El mecanismo de atención del transformer trata ambos de la misma manera: no hay diferencia arquitectónica entre «ver» y «leer».
Generación de representaciones
El backbone procesa la secuencia completa y produce embeddings de salida enriquecidos que codifican: «el vaso está 15 cm adelante, a la izquierda del plato; la instrucción dice que lo agarre». Esos embeddings alimentan el action head.
🎯 Action Head: tokenización de acciones continuas
El action head es donde VLA se diferencia radicalmente de un VLM común. Los robots operan en espacios continuos —posición en metros, torque en Newton-metro—, pero los LLM generan tokens discretos. El action head es el componente que resuelve esta incompatibilidad fundamental.
El problema de la continuidad
Un robot manipulador de 7 DoF necesita 7 números reales en cada timestep: (x, y, z, rotX, rotY, rotZ, gripper). Esos números pueden ser 0.3427m o 1.7293 Nm — valores con precisión arbitraria. El vocabulario de un LLM tiene tokens discretos como «cat», «42» o «[EOS]». No existe un token para «0.3427».
Diferentes action heads resuelven esto de distintas formas: discretización en bins, regresión directa mediante MLP o modelos generativos (diffusion, flow matching). Cada enfoque tiene sus ventajas y desventajas en precisión, latencia y suavidad del movimiento.
✓ Cabezas de acción que funcionan bien
- ✓Bins discretos (RT-2, OpenVLA): simple, compatible con el vocabulario LLM, bueno para tareas lentas
- ✓Diffusion head (Octo): acciones fluidas y multimodales, bueno cuando hay varios caminos válidos
- ✓Flow matching (π0): alta frecuencia (50 Hz), excelente para la manipulación diestra
✗ Problemas frecuentes
- ✗Bins con baja resolución (64 bins): imprecisión de ~1.5 mm en un espacio de trabajo de 10 cm
- ✗MLP de regresión sin normalización de acciones: los gradientes explotan o colapsan
- ✗Diffusion con muchos pasos de denoising — latencia prohibitiva para el control en tiempo real
💡 Flow matching vs Diffusion
Ambos transforman el ruido en acciones. La diferencia: diffusion usa un proceso de denoising iterativo con muchos pasos (típicamente 10-100); flow matching aprende un campo vectorial y resuelve una ODE en menos pasos (2-4). Resultado: π0 puede generar acciones suaves a 50 Hz, mientras que los heads difusivos típicos requieren un compromiso entre calidad y velocidad.
📐 Tokenización de trayectorias: bin discreto vs. continuo
¿Cómo representar una trayectoria robótica como una secuencia procesable? Hay dos filosofías fundamentales: discretizar el espacio de acciones en buckets (compatible con el vocabulario de los LLM, pero limitado en resolución) o generar valores continuos directamente mediante modelos generativos (preciso, pero más complejo desde el punto de vista arquitectónico).
📊 Cifras reales: resolución de bins
🔄 Co-fine-tuning: visión + lenguaje juntos
El co-fine-tuning es el proceso de entrenar simultáneamente los componentes visuales y lingüísticos del VLA con datos de demostraciones robóticas. En vez de congelar el encoder y entrenar solo el action head, todos los componentes aprenden juntos — y eso es precisamente lo que hace que los VLA superen a los pipelines modulares.
💡 El resultado de OpenVLA
OpenVLA demostró empíricamente que el co-fine-tuning mejora el rendimiento hasta en 16,5% en comparación con el fine-tuning solo del action head. La razón: cuando el encoder visual puede adaptarse a la tarea, aprende features específicas para la manipulación —como detectar bordes de agarre— que las features de imágenes web no capturan.
✓ Beneficios del co-fine-tuning
- ✓Los gradientes de la action loss se propagan hasta el encoder: las features visuales se adaptan al control
- ✓Las representaciones convergen hacia lo relevante para la tarea, no hacia la clasificación web
- ✓Mejor generalización a objetos nuevos que no aparecen en las demostraciones
- ✓LoRA hace viable el coajuste fino en una sola GPU de consumo
✗ Riesgos y mitigaciones
- ✗Catastrophic forgetting: el backbone pierde capacidad lingüística → usa una tasa de aprendizaje baja (1e-5)
- ✗Sobreajuste: los datos robóticos son escasos; pocos datos → el modelo memoriza en lugar de generalizar
- ✗Costo computacional: el co-fine-tuning de 7B es 3-4× más costoso que el fine-tuning solo del action head
⚡ Latencia y throughput: presupuesto de tokens
El cuello de botella más difícil de los VLA reales no es la arquitectura, sino el tiempo. Un robot necesita decidir acciones a 5–50 Hz, pero un LLM de 7B parámetros puede tardar cientos de milisegundos por token. El budget de tokens define cuántos tokens visuales y textuales puede procesar el sistema dentro del tiempo de control disponible.
Frecuencias de control y lo que permite cada una
Tareas lentas: apilar bloques, abrir cajones
200 ms por acción. Las VLA de 7B con cuantización INT8 (p. ej., OpenVLA) pueden operar a esta frecuencia en GPU de consumo. Suficiente para el 80 % de las tareas de manipulación de mesa.
Manipulación fluida: recoger y colocar objetos variados
~67 ms por acción. Requiere modelos más pequeños (3B), cuantización agresiva (INT4) o inferencia asíncrona con action chunking. KV-cache es obligatorio para reutilizar tokens del contexto.
Manipulación diestra — doblar ropa, encajar piezas
20 ms por acción. Territorio de π0 con flow matching (2-4 pasos ODE). Inviable con discretización en bins + LLM de tamaño completo. Requiere codesarrollo de arquitectura y hardware.
📊 Técnicas de aceleración y sus beneficios
💡 Jetson Orin: VLA en el borde
Nvidia Jetson AGX Orin (275 TOPS) permite ejecutar SmolVLA o Qwen-VLA <3B con cuantización INT4 a 8–12 Hz —suficiente para tareas tabletop— sin ningún servidor externo. Para modelos de 7B como OpenVLA, todavía se necesita una GPU discreta (RTX 3090 o superior) en el loop.
🎓 Resumen del módulo
Siguiente módulo:
1.3 — Panorama de los modelos: RT-2, OpenVLA, π0, Qwen-VLA. El ecosistema de modelos VLA, desde pioneros cerrados hasta open source.