🔬 Anatomia de um VLA: Visão + Linguagem + Ação
Desmontando a arquitetura por dentro: como encoder visual, backbone de linguagem e decodificador de ações se conectam para transformar pixels e palavras em movimento físico.
👁️ Encoder Visual: SigLIP, DINOv2, ViT
O encoder visual é o primeiro degrau da percepção: converte cada frame da câmera em vetores densos que o backbone de linguagem consegue "ler". A escolha do encoder — SigLIP, DINOv2 ou ViT puro — define o que o robô é capaz de enxergar com precisão.
🔍 Como funciona o patch embedding
A imagem de 224×224 pixels é dividida em patches de 14×14 ou 16×16 pixels. Cada patch é projetado linearmente num vetor denso de alta dimensão (tipicamente 768 ou 1024 dimensões). Esses vetores — os visual tokens — são a linguagem interna que o encoder fala com o backbone LLM.
Uma imagem de 224×224 com patches de 14×14 gera 256 visual tokens. Cada token carrega informação local sobre textura, cor e bordas — o conjunto carrega a estrutura espacial da cena inteira.
✓ SigLIP e DINOv2 brilham quando
- ✓SigLIP: tarefa exige alinhar objetos a nomes ("pegue o copo azul")
- ✓DINOv2: tarefa exige estimativa de profundidade ou segmentação implícita
- ✓Dual encoder (SigLIP + DINOv2): combina os dois — padrão no OpenVLA
- ✓Resolução maior (336×336) melhora manipulação fina de objetos pequenos
✗ Armadilhas comuns
- ✗Usar encoder treinado apenas em web images — perde geometria 3D
- ✗Congelar o encoder durante fine-tuning — features não adaptam para a tarefa
- ✗Resolução muito baixa (112×112) — objeto de 2 cm vira ruído de 1 token
- ✗Ignorar a projection layer — visual tokens precisam de escala compatível com o LLM
🧠 Backbone LLM: Llama, Gemma, Qwen
O backbone LLM é o cérebro central do VLA. É ele que funde visual tokens com text tokens, raciocina sobre a cena e decide o que fazer. A escolha do backbone — e quantos parâmetros ele tem — define o trade-off fundamental entre capacidade de raciocínio e latência de resposta.
💡 Por que reusar um LLM pré-treinado?
Modelos como Llama 3, Gemma 2 e Qwen 2.5 foram treinados em trilhões de tokens de texto. Eles já "sabem" o que é um copo, onde fica a pia e como seguir instruções compostas como "coloque o garfo à esquerda do prato". Treinar esse conhecimento do zero para cada robô seria proibitivamente caro — o reuso é a chave da generalização.
Fluxo de processamento dentro do backbone
Projection Layer
Uma MLP simples (2 camadas lineares) mapeia visual tokens do espaço do encoder (ex: 1024 dims) para o espaço de embedding do LLM (ex: 4096 dims). Esse "tradutor" é o único novo componente que precisa ser treinado do zero.
Fusão Multimodal
Visual tokens e text tokens são concatenados numa sequência unificada. O mecanismo de atenção do transformer trata ambos da mesma forma — não há diferença arquitetural entre "ver" e "ler".
Geração de Representação
O backbone processa a sequência completa e produz embeddings de saída ricos que codificam: "o copo está 15 cm à frente, à esquerda do prato, instrução diz para pegá-lo". Esses embeddings alimentam o action head.
🎯 Action Head: Tokenizando Ações Contínuas
O action head é onde VLA diverge radicalmente de um VLM comum. Robôs operam em espaços contínuos — posição em metros, torque em Newton-metro — mas LLMs geram tokens discretos. O action head é o componente que resolve essa incompatibilidade fundamental.
O problema da continuidade
Um robô manipulador de 7 DoF precisa de 7 números reais a cada timestep: (x, y, z, rotX, rotY, rotZ, gripper). Esses números podem ser 0.3427m ou 1.7293 Nm — valores arbitrariamente precisos. O vocabulário de um LLM tem tokens discretos como "cat", "42" ou "[EOS]". Não existe token para "0.3427".
Diferentes action heads resolvem isso de formas distintas: discretização em bins, regressão direta via MLP, ou modelos generativos (diffusion, flow matching). Cada abordagem tem trade-offs de precisão, latência e suavidade de movimento.
✓ Action heads que funcionam bem
- ✓Bins discretos (RT-2, OpenVLA): simples, compatível com vocabulário LLM, bom para tarefas lentas
- ✓Diffusion head (Octo): ações suaves e multimodais, bom quando há múltiplos caminhos válidos
- ✓Flow matching (π0): alta frequência (50 Hz), ótimo para dexterous manipulation
✗ Problemas frequentes
- ✗Bins com resolução baixa (64 bins) — imprecisão de ~1.5 mm em workspace de 10 cm
- ✗MLP de regressão sem normalização de ações — gradientes explodem ou colapsam
- ✗Diffusion com muitos steps de denoising — latência proibitiva para controle em tempo real
💡 Flow matching vs Diffusion
Ambos transformam ruído em ações. A diferença: diffusion usa um processo de denoising iterativo com muitos passos (tipicamente 10-100); flow matching aprende um campo vetorial e resolve uma ODE em menos passos (2-4). Resultado: π0 consegue gerar ações suaves a 50 Hz, enquanto heads difusivos típicos precisam de comprometimento entre qualidade e velocidade.
📐 Tokenização de Trajetórias: Bin Discreto vs Contínuo
Como representar uma trajetória robótica como sequência processável? Duas filosofias fundamentais: discretizar o espaço de ações em buckets (compatível com vocabulário LLM, porém limitado em resolução) ou gerar valores contínuos diretamente via modelos generativos (preciso, porém arquiteturalmente mais complexo).
📊 Números reais: resolução de bins
🔄 Co-fine-tuning: Visão + Linguagem Juntos
Co-fine-tuning é o processo de treinar simultaneamente os componentes visuais e linguísticos do VLA em dados de demonstração robótica. Em vez de congelar o encoder e treinar só o action head, todos os componentes aprendem juntos — e é exatamente isso que faz VLAs superarem pipelines modulares.
💡 O resultado do OpenVLA
O OpenVLA demonstrou empiricamente que co-fine-tuning melhora a performance em até 16,5% comparado ao fine-tuning apenas do action head. A razão: quando o encoder visual pode se adaptar à tarefa, ele aprende features específicas para manipulação — como detectar bordas de preensão — que features de web images não capturam.
✓ Benefícios do co-fine-tuning
- ✓Gradientes da action loss propagam até o encoder — features visuais se adaptam para controle
- ✓Representações convergem para o que é relevante para a tarefa, não para classificação web
- ✓Melhor generalização para objetos novos não vistos nas demonstrações
- ✓LoRA torna co-fine-tuning viável em uma única GPU de consumo
✗ Riscos e mitigações
- ✗Catastrophic forgetting: backbone perde capacidade linguística → use learning rate baixo (1e-5)
- ✗Overfitting: dados robóticos são escassos; poucos dados → modelo memoriza em vez de generalizar
- ✗Custo computacional: co-fine-tuning de 7B é 3-4× mais caro que fine-tuning só do action head
⚡ Latência e Throughput: Budget de Tokens
O gargalo mais cruel dos VLAs reais não é a arquitetura — é o tempo. Um robô precisa decidir ações a 5–50 Hz, mas um LLM de 7B parâmetros pode levar centenas de milissegundos por token. O budget de tokens define quantos tokens visuais e textuais o sistema consegue processar dentro do tempo de controle disponível.
Frequências de controle e o que cada uma viabiliza
Tarefas lentas — empilhar blocos, abrir gavetas
200 ms por ação. VLAs de 7B com quantização INT8 (ex: OpenVLA) conseguem operar nessa frequência em GPUs de consumo. Suficiente para 80% das tarefas de manipulação tabletop.
Manipulação fluida — pegar e colocar objetos variados
~67 ms por ação. Requer modelos menores (3B), quantização agressiva (INT4) ou async inference com action chunking. KV-cache é obrigatório para reusar tokens do contexto.
Dexterous manipulation — dobrar roupa, encaixar peças
20 ms por ação. Território do π0 com flow matching (2-4 ODE steps). Inviável com discretização bin + LLM full size. Requer co-design de arquitetura e hardware.
📊 Técnicas de aceleração e seus ganhos
💡 Jetson Orin: VLA na borda
O Nvidia Jetson AGX Orin (275 TOPS) permite rodar SmolVLA ou Qwen-VLA <3B com quantização INT4 a 8–12 Hz — suficiente para tarefas tabletop — sem nenhum servidor externo. Para modelos de 7B como OpenVLA, ainda é necessário uma GPU discreta (RTX 3090 ou superior) no loop.
🎓 Resumo do Módulo
Próximo Módulo:
1.3 — Panorama dos Modelos: RT-2, OpenVLA, π0, Qwen-VLA. O ecossistema de modelos VLA, de pioneiros fechados a open-source.