LLMs e modelos VLA embarcados em robôs 2026: o que cabe, o que não cabe

A pilha de software de um robô tem pelo menos cinco tarefas distintas, e apenas duas delas são território plausível hoje para um LLM ou VLA. Tratar "IA em robótica" como um bloco indiferenciado é o erro de enquadramento mais comum na cobertura desse espaço — leva à pergunta errada ("consegue rodar um LLM?") em vez da pergunta útil ("qual dessas cinco tarefas o modelo está realmente fazendo, e a que taxa?").

As cinco tarefas, na ordem em que os dados fluem por elas: percepção (transformar dados de câmera/lidar/IMU em uma representação estruturada do mundo), estimativa de estado (fundir esses dados ao longo do tempo em uma estimativa estável da própria pose do robô e do estado do mundo), planejamento de tarefas (decidir *o que* fazer a seguir — "pegar a xícara azul", "navegar até a doca de carregamento"), planejamento de movimento (traduzir uma tarefa em uma trajetória viável — ângulos das articulações, um caminho, uma abordagem de preensão) e controle (converter a trajetória planejada em comandos de motor, momento a momento, rejeitando perturbações).

Percepção é onde VLMs e modelos de visão leves já fazem trabalho real — detecção de objetos, descrição de cena, rotulagem semântica — geralmente na faixa de 5–30 Hz que um feed de câmera produz. Planejamento de tarefas é onde um VLA ou LLM agrega valor genuíno: traduzir um objetivo em linguagem natural ou visual em um subobjetivo simbólico sobre o qual um sistema downstream pode agir. Essas são as duas tarefas que este artigo trata como território legítimo de VLA/LLM.

Estimativa de estado, planejamento de movimento e controle são de natureza diferente. A estimativa de estado normalmente roda um filtro de Kalman ou de partículas — matemática determinística e bem compreendida que uma rede neural não melhora no problema central de estimativa. O planejamento de movimento é dominado por otimizadores de trajetória clássicos (CHOMP, RRT*, planejadores baseados em MPC) precisamente porque oferecem satisfação de restrições verificável — uma propriedade que a saída de um modelo de linguagem não tem. O controle é o mais rápido e o menos adequado a modelos de todos: executa um loop de feedback contra o erro do sensor em taxas que um forward pass de transformer não consegue se aproximar.

A restrição limitante do que um robô pode fazer com um VLA é o número de decisões por segundo alcançável pelo modelo — não a classificação de TOPS de pico do acelerador. Uma ficha técnica de hardware citando 100 TOPS não diz nada sobre quantas vezes por segundo um VLA de 2–7B parâmetros consegue executar um forward pass completo e produzir uma ação utilizável; esse número depende conjuntamente do tamanho do modelo, quantização, tamanho do lote, número de câmeras e largura de banda de memória, e geralmente fica bem abaixo do que o número de TOPS sugere para uma carga de trabalho de fluxo único e baixa latência.

Loops diferentes toleram latências muito diferentes. Um loop de equilíbrio de locomoção em um robô com pernas ou autoequilibrado precisa de correções em milissegundos de um único dígito — isso é um loop de controle de 100–1.000 Hz, e nenhuma arquitetura VLA publicada roda nessa taxa. Um loop de planejamento de tarefas de manipulação (decidir "alcançar a xícara" vs. "alcançar a tigela") tolera 100–1.000 ms de latência sem degradar visivelmente o comportamento — essa é a faixa de 1–10 Hz em que um VLA opera de forma realista. Um loop de replanejamento em nível de navegação (recalcular rota ao redor de um obstáculo) muitas vezes tolera vários segundos.

É por isso que a taxa de saída do modelo, não os FLOPs subjacentes do modelo, é o número contra o qual orçar. Dois VLAs com contagens de parâmetros semelhantes podem ter Hz alcançáveis muito diferentes, dependendo de quanto do pipeline (encoder de visão, decoder de ação, tokenização) fica no caminho crítico por decisão — e dependendo de quantos fluxos de câmera alimentam o mesmo forward pass, já que a maioria das arquiteturas VLA trata cada câmera adicional como contexto adicional, não paralelismo adicional.

Um modelo no loop de controle é um risco de segurança, não apenas de desempenho. Saídas de redes neurais não são formalmente verificáveis como são as margens de estabilidade de um controlador PID ou MPC — não há prova de que um transformer nunca produzirá uma ação insegura para uma distribuição de entrada nunca vista. Essa é a razão central pela qual paradas com classificação de segurança, limites de torque e intertravamentos anticolisão permanecem em código de controle determinístico em toda pilha de robô em produção que conhecemos, não importa quão capaz o modelo da camada de raciocínio se torne: uma função de segurança certificável precisa de um comportamento que possa ser caracterizado exaustivamente, e uma grande rede neural atualmente não pode oferecer essa garantia.

Use a calculadora abaixo para estimar qual taxa de decisão uma combinação específica de hardware/número de câmeras consegue realmente atingir, antes de se comprometer com um modelo ou uma placa. As estimativas são aproximações de engenharia para orçamento inicial, não benchmarks de fabricante — valide contra o modelo e o hardware reais antes de finalizar um design.

Cinco modelos VLA cobrem a maior parte do panorama aberto e semiaberto que equipes de robótica avaliam em 2026, além de um modelo de acesso restrito que vale a pena acompanhar para ver para onde o campo está indo. As contagens de parâmetros abaixo marcadas com "~" vêm de reportagens secundárias em vez de uma ficha técnica primária do fabricante — trate-as como direcionais, não exatas.

O NVIDIA Isaac GR00T N1 e sua revisão N1.5 são modelos VLA orientados a humanoides, lançados abertamente, com aproximadamente ~2,2B parâmetros (número de fonte secundária). A NVIDIA afirma explicitamente que o GR00T N1.5 roda em sua placa Jetson Thor — este é um alvo de implantação embarcada confirmado pelo fabricante, não inferido.

O π0 (pi-zero) da Physical Intelligence é um VLA de flow-matching com aproximadamente ~3B parâmetros (fonte secundária), lançado com pesos abertos, construído sobre um backbone de visão-linguagem da classe PaliGemma (detalhe de fonte secundária). Tem atraído atenção por gerar ações suaves e de alta frequência em comparação com designs VLA anteriores.

O OpenVLA, com 7 bilhões de parâmetros, é a linha de base acadêmica comum para pesquisa em VLA — aberto, bem documentado, amplamente usado como referência de benchmark. Seu tamanho o torna o ponto de referência para "quão grande um VLA capaz precisa ser", mas normalmente não é a primeira escolha para um orçamento de latência embarcada apertado.

O Gemini Robotics On-Device do Google DeepMind tem uma contagem de parâmetros não divulgada e acesso restrito/de parceiro — não é uma opção que a maioria das equipes pode acessar hoje. O que o torna digno de acompanhamento mesmo assim: o Google DeepMind afirma que ele foi projetado explicitamente para rodar localmente no robô sem conexão à internet. Esse é o sinal mais claro de um grande laboratório de que a inferência embarcada agora é um alvo de implantação de primeira classe, não uma reflexão tardia de pesquisa enxertada em um sistema pensado primeiro para nuvem.

O SmolVLA é um VLA compacto e aberto com aproximadamente ~450M parâmetros (fonte secundária) — a opção realista quando o hardware alvo é genuinamente de baixa potência (um acelerador pequeno em vez de uma placa completa da classe Jetson), onde a pegada de memória e a latência de forward pass de um modelo de 2–7B simplesmente não cabem no orçamento.

Octo e RT-2 são arquiteturas VLA de gerações anteriores, úteis principalmente para o enquadramento histórico de como o campo chegou aos designs atuais de flow-matching e ação tokenizada — não uma recomendação vigente para uma decisão de implantação em 2026.

Além da categoria VLA, a NVIDIA afirma que modelos de propósito geral Llama, Qwen e DeepSeek (LLMs), além de Qwen2.5-VL e Llama 3.2 Vision (VLMs), rodam no Jetson Thor. Eles cuidam da camada de compreensão de linguagem e descrição de cena em uma pilha de robô onde um VLA completo é desnecessário — um robô de serviço respondendo a uma pergunta verbal, ou um braço de manipulação lendo um rótulo de texto, não precisa de nenhum modelo de saída de ação.

O ROS 2 é a fronteira prática entre a camada de raciocínio lenta e a camada de controle rápida na maioria das pilhas de robôs em produção. Um nó VLA publica uma intenção em nível de tarefa — uma pose alvo, um subobjetivo, um ponto de preensão — como uma mensagem ROS 2, e um nó de controle clássico separado se inscreve nessa mensagem e a executa nas taxas do loop de controle. O VLA nunca fala diretamente com os motores; ele fala com um tópico, e um nó determinístico é dono de tudo a jusante desse tópico.

Em hardware NVIDIA (níveis Jetson Orin e Thor), TensorRT e TensorRT-LLM são o caminho de runtime padrão para levar um VLA ou LLM quantizado à sua taxa de inferência alcançável — cuidam de fusão de kernels, calibração de precisão (FP8/INT8/INT4) e otimização específica de hardware que um loop de inferência PyTorch ingênuo deixa passar. Pular essa etapa é a razão mais comum pela qual um modelo que "deveria" atingir um Hz alvo no papel não o atinge na prática.

Para alvos embarcados menores que não são baseados em NVIDIA — um acelerador Hailo-10H, ou uma placa compacta baseada em ARM — ExecuTorch e llama.cpp são os caminhos de runtime relevantes para os componentes de linguagem/percepção. Nenhum dos dois é hoje um runtime VLA pronto para uso; equipes visando essas placas menores mais frequentemente rodam um VLM compacto (para percepção/descrição de cena) do que um VLA completo, com o planejamento de tarefas simplificado em lógica baseada em regras ou executado com menos frequência, em uma cadência que o acelerador menor consegue sustentar.

O padrão prático de integração, em ordem: (1) o nó VLA/VLM roda de forma assíncrona em seu Hz alcançável, publicando intenção em um tópico ROS 2; (2) um planejador clássico se inscreve, convertendo a intenção em uma trajetória; (3) um nó de controle executa a trajetória a 100–1.000 Hz, usando seu próprio loop de feedback de sensores — nunca esperando a próxima saída do VLA para agir. Se o nó VLA travar ou atrasar, o nó de controle continua executando a última trajetória válida ou mantém a posição com segurança; ele não bloqueia esperando a camada lenta.

Robôs móveis autônomos (AMRs) em armazéns e maquinário agrícola representam a realidade implantada da autonomia de robôs hoje — humanoides recebem a cobertura da mídia mas são a classe de máquina menos implantada discutida neste artigo. Essa lacuna importa para quem precisa decidir onde investir tempo de engenharia: a categoria de robô mais intensiva em computação e mais discutida é também aquela com menos unidades realmente rodando em ambientes de produção agora.

Humanoides são a classe mais intensiva em computação, menos implantada: carregam mais sensores, mais graus de liberdade, e consequentemente a carga de trabalho da camada de raciocínio mais pesada (múltiplos fluxos de câmera, planejamento de tarefas de corpo inteiro), que é exatamente por que são o alvo principal do silício embarcado mais novo e capaz (Jetson Thor) e das arquiteturas VLA mais recentes (GR00T N1.5). Seu volume de implantação hoje é pequeno em relação à atenção que recebem.

Robôs móveis autônomos (AMRs) — os robôs com rodas que movem estoque em armazéns — foram implantados comercialmente em escala significativa há anos, rodando pilhas clássicas de navegação e desvio de obstáculos. O que está mudando em 2026 é a adição de uma camada de interface de linguagem/visão sobre uma pilha de autonomia já madura: um VLM para descrição de cena ou uma camada de planejamento de tarefas leve que permite a um humano dar uma instrução em linguagem natural, não uma substituição total da lógica de navegação subjacente.

Braços industriais em células de fabricação fixas ficam entre esses extremos: planejamento de movimento e controle são tipicamente totalmente clássicos há décadas (um braço de solda ou pick-and-place não precisa de um VLA para repetir uma trajetória ensinada), mas camadas de percepção — detecção de defeitos, identificação de peças — cada vez mais usam modelos de visão leves, onde uma posição de câmera fixa e uma tarefa restrita tornam um modelo menor e treinado com propósito específico suficiente sem um VLA completo.

Maquinário agrícola é a classe de implantação mais frequentemente negligenciada na cobertura de "robótica com IA", apesar de ter implantado autonomia comercial — direção guiada por GPS, detecção de obstáculos em tratores e colheitadeiras — em escala há anos, bem antes da onda VLA atual. O que está sendo adicionado agora segue o mesmo padrão dos AMRs: uma camada de interface de linguagem/visão (identificação de cultura ou erva daninha, comandos do operador em linguagem natural) sobre sistemas de navegação e controle que já eram autônomos e já eram clássicos.

Três categorias de hardware cobrem a maior parte de uma construção de inferência embarcada em robô: um kit de desenvolvimento da classe Jetson para a camada de raciocínio, uma ou mais câmeras de profundidade/estéreo para entrada de percepção, e uma plataforma de desenvolvimento de robô para montar tudo. Esta seção nomeia categorias, não SKUs específicos, preços ou alegações de fabricante — verifique especificações e preços atuais diretamente com cada fabricante antes de comprar, já que ambos mudam mais rápido do que um artigo consegue acompanhar.

Kits de desenvolvimento Jetson Orin e Jetson Thor são o ponto de partida padrão para avaliar um VLA ou VLM embarcado — veja Hardware Edge AI para LLMs Locais para a divisão nível por nível (Orin Nano até AGX Thor) cobrindo envelope de potência e computação relativa.

Câmeras de profundidade ou estéreo são a entrada de percepção padrão para um VLA — a maioria das pesquisas VLA publicadas e designs de referência de fabricantes assume entrada RGB-D ou estéreo em vez de RGB monocular apenas, já que a profundidade simplifica a estimativa de ponto de preensão e distância a obstáculos da qual a camada de saída de ação depende.

Uma plataforma de desenvolvimento de robô — uma plataforma de referência com rodas ou baseada em braço em vez de uma construção mecânica do zero — é o ponto de partida prático para uma equipe validando uma integração VLA antes de se comprometer com hardware personalizado.

Quatro cargas de trabalho permanecem fora do robô mesmo em uma arquitetura agressivamente local-first: aprendizado de frota, atualizações de modelo, compartilhamento de contexto entre robôs e simulação pesada. Nenhuma delas é sensível à latência como percepção ou planejamento de tarefas são, e todas se beneficiam de computação e dados aos quais nenhum robô individual tem acesso.

Aprendizado de frota — agregar experiência de muitos robôs implantados para melhorar uma política ou modelo compartilhado — inerentemente precisa de dados de mais unidades do que qualquer robô individual carrega, e a computação de treinamento envolvida está muito além do orçamento ou propósito de um acelerador embarcado.

Atualizações de modelo (um novo checkpoint de VLA, um modelo de percepção ajustado) são enviadas ao robô em vez de treinadas nele; o robô é um alvo de inferência, não um nó de treinamento, em praticamente todo padrão de implantação em produção usado hoje.

Contexto entre robôs — um robô se beneficiando do que outro robô na mesma frota acabou de observar — requer um backend compartilhado, já que não existe um mecanismo embarcado útil para um robô acessar diretamente o histórico de sensores de outro.

Simulação pesada — as cargas de trabalho de física e renderização em larga escala usadas para gerar dados de treinamento ou validar uma política antes da implantação — roda em computação de classe data center pelo mesmo motivo que o aprendizado de frota: o orçamento de computação não tem equivalente embarcado.

Na UE, um componente de IA que funciona como componente de segurança de maquinário é tratado como de alto risco sob o AI Act da UE, e o Regulamento de Máquinas da UE (2023/1230) — aplicável a partir de janeiro de 2027 — exige separadamente avaliação de conformidade para maquinário com uma função de segurança orientada por IA. Um robô com um modelo no caminho de uma função de segurança pode precisar satisfazer ambos os frameworks, não apenas um.

Esta é nossa própria análise fundamentada, não uma orientação regulatória publicada: a arquitetura em duas camadas descrita ao longo deste artigo — manter funções de segurança (paradas de emergência, limites de torque, intertravamentos de colisão) em código de controle clássico e determinístico, e confinar a camada de raciocínio VLA/LLM a papéis consultivos ou de nível de tarefa que nunca condicionam diretamente uma função de segurança — plausivelmente reduz a carga de avaliação de conformidade, porque uma função de segurança certificável precisa de comportamento que possa ser caracterizado exaustivamente com antecedência, o que código determinístico pode oferecer e uma grande rede neural atualmente não pode. Não temos conhecimento de nenhum regulador ter publicado orientação específica confirmando esse enquadramento; trate-o como um argumento técnico-regulatório para avaliar com seu próprio consultor jurídico, não como uma garantia de conformidade.

Isso não constitui aconselhamento jurídico. O escopo da avaliação de conformidade, as normas harmonizadas aplicáveis e a classificação específica das funções de segurança de um determinado robô dependem do design real do sistema e da jurisdição de venda — consulte um consultor jurídico e regulatório qualificado antes de fazer uma determinação de conformidade para um produto específico. No Brasil, um sistema robótico que capta imagens ou voz de pessoas no ambiente de trabalho também está sujeito aos princípios gerais da LGPD (Lei Geral de Proteção de Dados) quanto à minimização e à base legal do tratamento — esta seção trata apenas de segurança de máquinas e certificação de produto, não de proteção de dados.