🗺️ Panorama dos Modelos: RT-2, OpenVLA, π0, Qwen-VLA
O ecossistema de modelos VLA mapeado de ponta a ponta — dos pioneiros fechados do Google aos compactos open-source que rodam em CPU. Entenda o que cada modelo resolve e quando escolher cada um.
Diagrama ilustrativo — posicionamento relativo por abertura e tamanho dos principais modelos VLA.
🔬 RT-2 e RT-X: os pioneiros do Google DeepMind
O RT-2 redefiniu o que um modelo de linguagem pode fazer: em vez de apenas descrever o mundo, ele age nele. Ao co-treinar dados robóticos com dados web em escala massiva, o Google DeepMind demonstrou que conhecimento da internet transfere para controle motor — um resultado que surpreendeu boa parte da comunidade em 2023.
🔑 O que RT-2 e RT-X são
- RT-2Robotics Transformer 2. Primeiro VLA a co-treinar dados robóticos com dados web em larga escala, demonstrando que o conhecimento da internet transfere para controle motor. Representa ações como tokens de texto, reutilizando o vocabulário do LLM.
- RT-XOpen X-Embodiment extension. Estende o RT-2 treinando sobre o dataset Open X-Embodiment com trajetórias de 22 embodiments diferentes, criando um modelo generalista cross-embodiment.
✓ Pontos fortes do RT-2
- ✓ Web-scale knowledge transfer: reconhece objetos nunca vistos em demos
- ✓ Emergent generalization: executa tarefas sem treinamento específico
- ✓ Co-fine-tuning: dados web + robóticos no mesmo loop de treino
✗ Limitações do RT-2
- ✗ Modelo fechado: pesos e código não disponíveis ao público
- ✗ 55B parâmetros: infraestrutura de inferência proibitiva
- ✗ Latência alta: frequência de controle insuficiente para tarefas de alta destreza
💡 Por que estudar RT-2 mesmo sendo fechado
RT-2 definiu o paradigma que praticamente todos os VLAs seguem hoje. Entender suas escolhas de design e limitações é o que contextualiza por que a comunidade buscou alternativas abertas e eficientes como OpenVLA, Octo e SmolVLA. Ele é o ponto de referência histórico incontornável.
🔓 OpenVLA: o padrão open-source da Stanford
Se o RT-2 mostrou o que era possível, o OpenVLA mostrou que era acessível. Um modelo de 7B parâmetros totalmente aberto, treinado sobre 970 mil trajetórias do Open X-Embodiment, com performance competitiva ao RT-2-X usando uma fração dos recursos — e com pesos, código e receita de fine-tuning disponíveis para qualquer pessoa.
🏗️ Arquitetura em três camadas
SigLIP + DINOv2 combinados: features semânticas + geométricas para manipulação fina.
Backbone de 7B parâmetros: raciocínio e compreensão de instruções em linguagem natural.
Ações mapeadas em 256 bins por dimensão, emitidas como tokens do vocabulário do LLM.
💡 Fine-tuning em uma GPU de consumo
O fine-tuning eficiente via LoRA roda em uma única GPU de consumo (ex.: RTX 4090). Quantização INT4 permite inferência a ~6 Hz em hardware modesto. OpenVLA é o ponto de partida para qualquer projeto real com orçamento limitado.
📊 Resultado chave do paper original
Co-fine-tuning (visão + linguagem + ação juntos) melhora a performance em até +16,5% comparado a fine-tuning apenas do action head, justificando o custo computacional extra. O dual encoder supera encoders simples em tarefas de manipulação fina em múltiplos benchmarks.
🌊 π0 (pi0): flow matching da Physical Intelligence
O π0 é a resposta à pergunta: e se o action head não fosse discreto, mas contínuo e gerado por um processo de denoising? Ao usar flow matching em vez de tokenização de ações, a Physical Intelligence alcançou 50 Hz de controle com trajetórias suaves — necessárias para tarefas de alta destreza como dobrar roupas.
Linha do tempo da inovação do π0
VLM
PaliGemma como backbone
O π0 usa o PaliGemma (VLM do Google) como base de percepção e raciocínio, aproveitando pré-treino em dados web de altíssima qualidade.
Expert
Action experts acoplados
Sub-redes dedicadas à geração de ação recebem tokens do backbone VLM e produzem trajetórias contínuas via flow matching — sem discretização.
Match
Geração a 50 Hz
O campo vetorial aprende a transportar ruído gaussiano para ações via ODE. Resultado: controle a 50 Hz com suavidade incompatível com tokenização discreta.
🔑 Conceitos-chave do π0
Aprende um campo vetorial que transporta ruído gaussiano para a distribuição de ações via ODE. Mais estável que diffusion e mais rápido na inferência.
Viabiliza tarefas de alta destreza (dobrar roupas, montar caixas) com feedback em tempo quase contínuo — impossível com tokenização discreta.
Projetado para múltiplos robôs: um único checkpoint funciona em diferentes morphologies sem retreinar tudo do zero.
Destaque em tarefas de manipulação fina onde VLAs discretos falham: movimentos fluidos e multimodais em espaço de ação contínuo.
Diagrama ilustrativo — action head discreto em degraus vs. contínuo com flow matching.
🐙 Octo: o transformer generalista de Berkeley
Enquanto RT-2 e π0 buscam máxima capacidade, o Octo aposta na pergunta oposta: qual o menor modelo capaz de generalizar? Com 27M a 93M parâmetros — centenas de vezes menor que o RT-2 — ele demonstrou que arquitetura modular e dados de qualidade valem mais que escala bruta.
🧩 Arquitetura modular
Novos sensores e action heads podem ser adicionados sem retreinar o core. Um transformer com blocos de atenção sobre tokens de observação e tarefa — plugável e extensível.
🎯 Diffusion action head
Gera ações multimodais suaves via processo de denoising iterativo. Suporta condicionamento por linguagem ou por imagem-objetivo — mais flexível que binning discreto.
📦 800k trajetórias Open X-E
Treinado sobre 800 mil trajetórias do Open X-Embodiment, cobrindo múltiplos robôs e ambientes, permitindo zero-shot transfer para novos embodiments.
💻 Deploy em hardware modesto
93M parâmetros rodam em GPUs acessíveis. Ideal para pesquisa rápida e prototipagem quando OpenVLA é grande demais para o orçamento de compute.
💡 Quando usar Octo
Use Octo quando precisar de um baseline rápido de treinar e testar ou quando o orçamento de GPU for limitado. Ele prova que nem todo VLA precisa de bilhões de parâmetros — arquitetura certa + dados certos > escala bruta.
📱 Qwen-VLA, SmolVLA e a era dos modelos compactos
A terceira geração de VLAs não busca bater benchmarks em servidores de data center — ela busca rodar em hardware embarcado e de baixo custo. SmolVLA roda em CPU; Qwen-VLA equilibra capacidade e latência em 1–3B parâmetros. A pergunta não é mais "quão bom?" mas "quão bom com o hardware que tenho?"
✓ O que os compactos resolvem
- ✓ Inferência on-device sem GPU cloud
- ✓ Fine-tuning em uma única GPU de consumo
- ✓ Prototipagem com plataformas baratas (SO-100, Jetson)
- ✓ Knowledge distillation preserva capacidades essenciais
✗ O que os compactos não entregam
- ✗ Generalização zero-shot competitiva com modelos grandes
- ✗ Alta destreza em tarefas de manipulação fina complexa
- ✗ Robustez a cenários muito fora da distribuição de treino
🔑 Técnicas que viabilizam compactos
- KDKnowledge distillation: transfere capacidade de modelos grandes para pequenos, preservando raciocínio sem custo de parâmetros.
- INT4Quantização agressiva: pesos em 4 bits reduzem footprint de memória em ~8x com perda mínima de desempenho em tarefas estruturadas.
- AsyncAsync inference (SmolVLA): percepção e geração de ação rodam em threads separadas — throughput melhorado sem aumento de parâmetros.
⚖️ Comparativo: tamanho, licença, embodiments, performance
Não existe o melhor modelo VLA absoluto — existe o melhor modelo para cada restrição. A escolha errada custa semanas de trabalho e milhares de dólares em compute. Entender os trade-offs antes de começar é a diferença entre um projeto que avança e um que empaca.
📊 Como os modelos são avaliados
- LIBEROBenchmark de aprendizado contínuo em manipulação; mede retenção de tarefas anteriores ao aprender novas. Padrão para comparar fine-tuning eficiente.
- SimplerEnvAmbiente simplificado com métricas de success rate padronizadas; permite comparação justa entre modelos em cenários de laboratório controlados.
- Embodiment coverageDetermina se o modelo transfere para o seu robô específico sem fine-tuning extenso — crucial para projetos reais com hardware proprietário.
✓ Critérios para escolha certa
- ✓ Definir restrição de compute primeiro
- ✓ Verificar cobertura de embodiments
- ✓ Avaliar se licença permite uso comercial
- ✓ Checar frequência de controle vs. requisito da tarefa
✗ Erros comuns na escolha
- ✗ Escolher o maior modelo disponível sem checar budget
- ✗ Ignorar latência de inferência vs. frequência necessária
- ✗ Usar modelo fechado em projeto que exige reprodutibilidade
- ✗ Negligenciar compatibilidade de embodiment
✅ Resumo do Módulo
Próximo módulo
1.4 — Datasets: Open X-Embodiment e DROID