Computação no Dispositivo vs. Fora do Dispositivo em Robôs

Todas as cargas de trabalho de um robô vivem num de dois sítios: a bordo, a consumir a bateria e as ventoinhas do peito, ou fora de bordo, num servidor ligado à corrente a um salto de LAN de distância. A questão difícil não é se precisa de ambos — quase sempre precisa — mas que carga de trabalho vai para onde, e porquê. O R08 defende que existe de facto um nível dedicado de edge. Este artigo trata da decisão carga a carga: controlo dos motores aqui, VLM ali, STT depende, e assim por diante.

O enquadramento é assumidamente opinativo. Há uma resposta certa para cada carga de trabalho, e essa resposta muda à medida que o silício de bordo recupera terreno. Vamos indicar para que lado cada peça está a caminhar em 2026–2027.

Os dois orçamentos que decidem tudo

Uma carga de trabalho pode correr a bordo se e só se couber em dois orçamentos em simultâneo: potência e memória. A latência é a terceira restrição, mas normalmente diz-lhe para que lado empurrar uma carga que já cabe, e não se cabe de todo.

Orçamento de potência num humanoide. Um humanoide de 30–50 kg transporta 700–900 Wh de bateria. A marcha sustentada consome 200–500 W nos atuadores, com picos acima de 800 W em movimento dinâmico. Parado a pensar, consome 80–150 W nos atuadores (manter binário é barato, manter a postura custa). Sobram cerca de 60–120 W para tudo o resto — computação, sensores, ventoinhas de arrefecimento, rádio — se quiser uma autonomia utilizável de duas horas. O orçamento de computação dentro desse envelope é de 30–80 W sustentados. Manter o Jetson em MAX_N (60 W) permanentemente reduz a autonomia do robô para metade. Isto é física não negociável, não uma opção de projeto.

Orçamento de memória. Um Jetson AGX Orin de 64 GB tem 64 GB de LPDDR5 partilhados entre o CPU e a GPU. Subtraia o sistema operativo (4–6 GB), o ROS 2 e o SDK do fabricante (2–4 GB), os buffers de perceção (2–4 GB para profundidade estéreo e nuvens de pontos) e o código da aplicação. O orçamento realista utilizável por LLM/VLM fica em 40–48 GB. Num módulo Jetson Thor de 128 GB, o teto sobe para cerca de 96 GB utilizáveis. Num Orin NX de 16 GB, cai para cerca de 8–10 GB utilizáveis — o suficiente para um modelo pequeno.

Fora de bordo, ambos os orçamentos são problemas diferentes. Um Kentino AI 96 (4× RTX 5090) tem 128 GB de VRAM dedicada e 1.0–1.5 kW de potência de GPU alimentada pela rede elétrica. Um Kentino AI 256 (8× RTX 5090) duplica ambos. A potência e a memória simplesmente deixam de ser restrições — troca-as por capex, AVAC da sala e rede com fios.

Silício de bordo, a realidade de 2026

As opções de bordo que hoje realmente equipam humanoides e quadrúpedes a sério:

O Thor é um salto, não uma iteração. O teto de memória de 128 GB e os tensor cores Blackwell nativos em FP4 deslocam a fronteira de bordo de "VLM 7B, a custo" para "VLM 32B, com utilidade" numa só geração. Cargas de trabalho que em 2025 eram estruturalmente de fora de bordo — VLM de dimensão moderada, legendagem contínua de cenas, planeadores LLM de dimensão média — tornam-se candidatas a bordo em 2026, se a solução térmica do robô aguentar 100–130 W sustentados.

A Hailo e a classe das NPU dedicadas não são aceleradores de LLM. São descarga do pipeline de visão: mantêm o Jetson principal livre para o modelo maior e correm a visão computacional da câmara sempre ativa (deteção de objetos, seguimento, VLM-lite básico) num chip de 3 W.

A classe QRB da Snapdragon é a resposta para robôs centrados na voz — palavra de ativação, beamforming, STT — onde um Jetson é exagero e um Cortex-M fica curto. Útil, específica, cada vez mais comum.

Fora de bordo: a gama Kentino AI como referência

O alvo fora de bordo referido ao longo desta série é a linha Kentino AI — alimentada pela rede elétrica, em rack 4U ou 5U, com 4 ou 8 GPU em EPYC ou Xeon, num switch 10 GbE a um salto do robô. Os três níveis que interessam à robótica:

A matriz de decisão

Todas as cargas de trabalho de robótica se arrumam com clareza numa de cinco categorias: sempre a bordo, preferencialmente a bordo, qualquer uma, preferencialmente fora de bordo, só fora de bordo. A razão de cada colocação é o orçamento que a limita — potência, memória ou latência.

Três leituras desta tabela merecem destaque.

As linhas de "sempre a bordo" são física. Nenhuma quantidade de largura de banda resolve um ciclo de controlo que exige resposta a 1 kHz. Estas nunca saem de bordo, por muito que a rede ou a computação fora de bordo melhorem.

As linhas de "qualquer uma" são onde entra o verdadeiro juízo de engenharia. É aqui que vivem quase todos os compromissos interessantes. Que um VLM de 7B corra a bordo ou fora de bordo determina uma fatia real do comportamento do sistema. Não há uma resposta certa universal.

As linhas de "só fora de bordo" mexem-se devagar. Um modelo de 72B continuará provavelmente a ser só de fora de bordo em 2027. Um modelo de 32B passará para bordo à medida que o Thor chegue em volume. A fronteira do "que cabe no dispositivo" avança cerca de uma classe de dimensão de modelo a cada 18–24 meses.

Mapeamento por nível de latência

O orçamento de latência em quatro níveis do I01 mapeia-se diretamente na colocação:

É nos dois níveis intermédios que assentam as verdadeiras decisões de arquitetura. Uma carga reflexiva que à justa cabe em 50 ms pode caber fora de bordo numa LAN com fios (0.5 ms de trânsito + 40 ms de inferência + 0.5 ms de regresso = 41 ms), mas rebenta o orçamento em Wi-Fi 6E sob carga (8 ms × 2 + 40 ms = 56 ms, mais jitter). É por isso que os cabos de amarração importam durante o desenvolvimento: permitem ver se uma carga de trabalho fundamentalmente cabe fora de bordo antes de lutar com a rede sem fios.

A realidade da rede

Fora de bordo só funciona se a rede funcionar. Os números reais:

Para cargas deliberativas (orçamento de 100 ms – 1 s), Wi-Fi 6E num SSID dedicado e com um AP em linha de vista chega perfeitamente. Para cargas reflexivas (10–50 ms), o cabo é a resposta segura e o Wi-Fi 6E é a resposta com sorte. Planeie em conformidade: se a tarefa de um robô tiver qualquer componente reflexiva fora de bordo, preveja uma opção com fios para o desenvolvimento e um modo de recurso para quando o Wi-Fi degradar.

O padrão híbrido — divisão rápido/lento

O padrão para o qual convergem a maioria das implementações sérias de 2026 é a divisão rápido/lento de VLM: um VLM pequeno a bordo para resposta imediata, um VLM grande fora de bordo para decisões ponderadas, ambos a alimentar o mesmo planeador.

Forma concreta:

Divisão rápido/lento: o 7B a bordo trata da resposta imediata; o 72B fora de bordo trata do raciocínio ponderado e das atualizações do plano.

O modelo rápido trata do "há uma pessoa a vir na minha direção, abrandar". O modelo lento trata do "a pessoa que vem na minha direção é o operador, que me pediu para parar se se aproximasse com a prancheta vermelha, e aquilo é uma prancheta vermelha, logo parar". O modelo rápido compromete-se primeiro com um comportamento seguro; o modelo lento melhora-o.

A história da migração — o que passa para bordo em 2026–2027

Três forças comprimem o lado de fora de bordo: o Thor chega em volume (2070 TFLOPS FP4, 128 GB de memória unificada, envelope de 130 W — um salto estrutural face ao Orin); a eficiência dos VLM continua a melhorar (um VLM de perceção "suficientemente bom" era de 70B+ em 2024, é de 32B em 2026 e será plausivelmente de 13B–20B em 2027); e a descodificação especulativa com pequenos modelos de rascunho permite servir qualidade de modelo grande com latência de modelo pequeno.

Cargas de trabalho com maior probabilidade de migrar para bordo nos próximos 18 meses: VLM de cena da classe 7B (já está a mover-se), planeador LLM de 13B (o Thor torna-o confortável), STT-LLM-TTS de contexto curto para voz, VLM de 7B afinados para domínios específicos.

Cargas de trabalho que não migram: tudo o que seja 70B+, memória de cena à escala da frota, treino e simulação, fusão VLM multifluxo. Estas ficam fora de bordo pelo menos até 2027. A largura de banda de memória e a energia da bateria não cedem assim tão depressa.

Duas configurações concretas

Um único G1 EDU, laboratório de investigação. O AGX Orin de bordo corre o ROS 2, YOLOv11-s a 30 FPS, STT Whisper-distil e Qwen2.5-VL 7B INT4 a 5–8 FPS (deliberativo). Fora de bordo, um Kentino AI 96 (4× RTX 5090, 128 GB de VRAM) corre vLLM com Qwen2.5-VL 72B e Qwen2.5 32B só de texto, memória de cena em pgvector e Isaac Sim nas GPU inativas.

Frota pequena, 3 humanoides, bordo da classe Thor. Cada unidade corre um SoC de visão Hailo-15 para deteção multicâmara sempre ativa, Whisper-small no dispositivo e Qwen2.5-VL 32B INT4 a 10–15 FPS — de forma nativa, já sem margens apertadas. Fora de bordo, um Kentino AI 256 (8× RTX 5090, 256 GB de VRAM) aloja um Qwen2.5-VL 72B e um Llama-3.1 70B partilhados para planeamento, uma base pgvector partilhada pelos três robôs e duas GPU reservadas para afinação LoRA durante a noite.

Onde as implementações puras de um só nível funcionam mesmo

O modelo só de bordo funciona para quadrúpedes de tarefa restrita (patrulha de perímetro com YOLO + câmara térmica), robôs teleoperados (o operador é o planeador, sem VLM no ciclo), robôs de demonstração ou de ensino com os modelos mais pequenos e qualquer implementação sem rede nenhuma (inspeção no exterior, locais remotos).

O modelo só de cloud funciona para assistentes robóticos apenas de voz sem ciclo de perceção fechado, protótipos em que a rapidez de instalação se sobrepõe a tudo e implementações em que os dados já vão, intencionalmente, para uma carga de trabalho na cloud.

O híbrido é a resposta para tudo o que fica pelo meio — ou seja, cerca de 90% da robótica séria em 2026. Se estiver a construir seja o que for com perceção VLM no ciclo, vai acabar com os dois níveis. Conte com isso desde o primeiro dia.

---

Este artigo faz parte da Kentino Wiki, uma série de referência sobre computação de IA, robótica e os sistemas que as ligam. Comentários e correções são bem-vindos em info@kentino.com.