Arquitetura de IA no edge: robô e servidor de inferência

Quem compra um humanoide ou um quadrúpede em 2026 recebe apenas metade do sistema. A outra metade é a computação que corre os grandes modelos que o próprio robô não consegue alojar. Este artigo explica o que vive realmente onde, porque é que o caminho on-premise existe quando as APIs na cloud são baratas e como as duas metades se ligam, física e logicamente.

O público são compradores e integradores que querem uma imagem clara antes de assinar uma nota de encomenda — ainda não engenheiros a escrever o código de ligação.

O problema das duas caixas

Um humanoide moderno como o Unitree G1 ou o Booster T1 leva a bordo um módulo de computação embebido: normalmente um Jetson Orin (classe NX ou AGX) ou um SoC da classe Snapdragon, muitas vezes acompanhado de um pequeno MCU dedicado ao ciclo de controlo dos motores. Os quadrúpedes como o Unitree Go2 usam um esquema semelhante, a uma escala menor.

Essa computação a bordo chega para:

• Controlo de motores em tempo real — binário das articulações, equilíbrio, marcha. Corre a 500 Hz–1 kHz e não tolera qualquer salto de rede. Fica local, ponto final.
• Reflexos de segurança imediatos — proteção contra quedas, paragem de emergência, resposta ao contacto. Mesma restrição, mesma resposta.
• Perceção de baixa latência — profundidade por estéreo ou RGB-D, fusão de IMU, deteção básica de objetos (normalmente uma variante pequena de YOLO ou MobileNet).
• Palavra de ativação por voz e encaminhamento básico de comandos.

O que a computação a bordo não consegue razoavelmente correr:

• Grandes modelos de visão-linguagem (VLM) como o Qwen2.5-VL 72B, o NVIDIA Cosmos ou o OpenVLA. Precisam de dezenas de GB de VRAM e consomem demasiado para uma plataforma alimentada a bateria.
• Grandes modelos de linguagem (LLM) para diálogo ou planeamento acima da classe 7B–8B quantizada.
• Planeadores de movimento por difusão ou autorregressivos que trabalham sobre centenas de milissegundos de contexto.
• Memória de cena e grafos de tarefas de longo horizonte.

Esta divisão não é uma opinião da Kentino. É a partição real com que hoje sai qualquer plataforma humanoide credível. O módulo a bordo é dimensionado para a segurança e a latência; o raciocínio pesado vai para fora.

O destino «fora de bordo» pode ser a cloud (OpenAI, Anthropic, NVIDIA Cosmos alojado) ou um servidor de inferência on-premise. O resto deste artigo trata de quando e porquê se quer a opção on-premise.

O que vive onde — a divisão na prática

A divisão em duas caixas: o controlo local fica no robô; a inferência pesada e o treino vão para o servidor on-premise através da LAN.

Três pontos a reter:

1. O robô não precisa de um servidor GPU para andar. Se a LAN cair, a unidade continua a levantar-se, a manter o equilíbrio e a evitar a parede. O pipeline fora de bordo acrescenta capacidade — linguagem, planeamento, tarefas de longo horizonte —, não substitui o controlo local.
2. Algumas cargas de trabalho são negociáveis. Um VLM pequeno (por exemplo, Qwen2.5-VL 7B quantizado) corre num Jetson Orin AGX. Pô-lo a bordo ou fora de bordo é uma questão de potência, térmica e latência. Não há uma resposta única.
3. O servidor faz mais do que servir inferência. Uma instalação séria corre também treino (para afinar o modelo a um ambiente específico), simulação (Isaac Sim para iterar políticas) e memória de cena / recuperação. «Servidor de inferência» é a forma abreviada de dizer «backend de computação GPU».

O orçamento de latência

O número que determina se a sua arquitetura vai funcionar é o tempo de ida e volta entre o robô e o servidor.

Os números que dominam o orçamento são a latência do modelo no servidor e, se usar rede sem fios, o jitter do Wi-Fi. O transporte em si raramente é o estrangulamento numa LAN com fios. É por isso que as instalações robóticas sérias usam um cabo de ligação ou um ponto de acesso Wi-Fi 6/6E dedicado, com linha de vista para a área de trabalho.

Se o robô tiver de responder a um comando verbal em menos de um segundo, a conta é aproximadamente esta:

captura de áudio       ~ 50 ms
palavra de ativação + STT  100–250 ms  (a bordo ou fora de bordo, à escolha)
TTFT do LLM (planeamento)  200–500 ms  (no servidor)
LLM a debitar 20 tokens   600–1200 ms
TTS                    100–300 ms
reprodução de áudio    ~ 50 ms
                       --------------
                       ~ 1.1 – 2.3 s

Hoje não há forma de ficar «abaixo de um segundo ponta a ponta» com um LLM de 70B no circuito. Ou se aceita a latência, ou se usa um modelo mais pequeno on-premise (classe 8B–13B), ou se divide a resposta (confirmar de imediato e planear em segundo plano).

É o tipo de compromisso que nada tem a ver com a rede e tudo a ver com a escolha do modelo. É também o tipo de compromisso em que ter servidor próprio conta: pode trocar de modelos, correr vários ao mesmo tempo, agrupar pedidos de outra forma. Com uma API na cloud, fica com aquilo que o fornecedor serve.

Porquê on-premise, afinal

A inferência na cloud é barata, escala sem esforço e não exige capex. Então porque é que alguém compraria um servidor de quatro ou oito GPU quando uma chave de API da OpenAI custa cinquenta dólares?

Há quatro razões a sério, por ordem aproximada da frequência com que determinam a decisão:

1. Os dados não saem do edifício. Instalações industriais, de defesa, de saúde e sujeitas ao RGPD na UE muitas vezes não podem enviar dados brutos de sensores para uma cloud de terceiros. O robô vê o chão de fábrica, o quarto de um doente, a bancada de um laboratório. Esse vídeo é privilegiado, regulado ou sensível do ponto de vista concorrencial. A inferência on-premise resolve isto de forma limpa. A cloud não.

2. O piso de latência. Cada chamada à cloud tem 15–40 ms de RTT em WAN acrescidos à latência do modelo. Para a maioria das tarefas robóticas, não é problema. Para controlo reativo em malha fechada — pick-and-place a alta cadência, recuperação do equilíbrio após um empurrão, manipulação fina —, esse piso é demasiado alto. O on-premise baixa-o para menos de 1 ms.

3. Custo em carga sustentada. Uma única chamada a um VLM de 70B quase nada custa ao fornecedor de cloud, que lhe cobra uns cêntimos. Mas um robô que está «sempre a pensar» faz milhares de chamadas por hora. Um laboratório de investigação que corra treino e uma frota de robôs a inferir contra os mesmos modelos chega a esgotar 5,000–15,000 $/mês em cloud. Um servidor on-premise de 4× ou 8× GPU paga-se em menos de doze meses com essa carga.

4. Escolha e personalização dos modelos. Quer afinar um VLM ao seu ambiente específico. Quer correr um modelo que os fornecedores de cloud não alojam. Quer combinar modelos de pesos abertos de vários fabricantes num pipeline próprio. O on-premise permite-lhe isso. As APIs na cloud não.

Se nenhuma destas quatro razões se aplica à sua instalação, use a cloud. A resposta honesta é que talvez 30–40% dos compradores de robótica precisem mesmo de on-premise; os restantes escolhem-no por prestígio ou porque o departamento de compras não está à vontade com a cloud. Também são razões válidas, mas não vamos fingir o contrário.

Topologia de rede

Topologia de rede: robô em Wi-Fi 6E → AP dedicado → switch 10 GbE → servidor de inferência. A saída e a WAN são opcionais.

Algumas notas práticas que costumam apanhar as pessoas desprevenidas:

• O Wi-Fi 6E é o mínimo, não o máximo. A banda dos 6 GHz é a única com comportamento de baixa latência consistente em ambientes com outros dispositivos. Conte com um AP por cada ~50 m² de área de trabalho do robô, com linha de vista sempre que possível.
• Com fios continua a ser melhor. Se o robô tiver opção de cabo (alguns humanoides de investigação têm, os quadrúpedes normalmente não), use-a durante o desenvolvimento. Trabalhar com uma LAN de latência inferior a um milissegundo é muitíssimo mais agradável do que lutar com o Wi-Fi.
• A saída para a Internet é opcional, mas útil. Mesmo numa instalação totalmente on-premise, costuma querer-se saída WAN para: atualizar modelos, obter dados de mapas, descarregar contentores NVIDIA NGC e enviar telemetria para a sua monitorização. Proteja-a com uma firewall apertada; não exponha o robô nem o servidor à Internet.
• A sincronização horária importa. Corra um servidor NTP local. A fusão de sensores e o planeamento de movimento avariam de formas subtis quando os relógios do robô, do servidor e de eventuais dispositivos edge auxiliares divergem.

Energia e arrefecimento

Um servidor Kentino AI de 4 GPU (4× RTX 5090 ou 4× RTX Pro 6000 Blackwell) consome 1.8–2.4 kW em carga sustentada. Um servidor de 8 GPU consome 3.5–4.5 kW. Não são números de computador de secretária; exigem circuitos de 16 A e um fluxo de ar de rack adequado.

Para um laboratório de robótica, o orçamento aproximado é este:

Planeie a sala antes da instalação, não depois. A maioria dos laboratórios que «acrescentou computação GPU mais tarde» acaba a disparar disjuntores no primeiro mês.

O fluxo de ar conta tanto como a potência. Os servidores Kentino AI usam fluxo de ar industrial de rack, da frente para trás, com ventoinhas de 120 mm, e foram explicitamente concebidos para carga sustentada 24/7. Não são torres de secretária e vão saturar o AVAC de uma sala pequena. Ou os coloca num rack num compartimento com arrefecimento dedicado, ou os instala numa sala separada e puxa uma ligação 10 GbE.

Pilha de software — o que corre de facto

É aqui que vive a implementação. A imagem geral:

Divisão do software: o ROS 2 no robô comunica por gRPC com o servidor de inferência que corre vLLM / SGLang.

Algumas escolhas assumidas:

• O vLLM é a pilha de serviço por omissão para VLM e LLM baseados em transformers. É mais rápido do que a inferência direta com HuggingFace e suporta batching contínuo e cache de prefixos. O SGLang é uma boa alternativa para saída estruturada ou fluxos de trabalho em estilo de agente.
• O llama.cpp é a resposta certa quando corre um modelo pequeno (classe 7B–13B) numa GPU com que o vLLM não se dá bem (por exemplo, uma RTX 4090 com paralelismo de tensores complicado), ou no próprio robô.
• O NVIDIA Triton dá mais trabalho a configurar, mas é a escolha acertada se mistura tipos de modelos (LLM + visão + fala) e quer uma única camada de serviço para todos.
• O ROS 2 Humble é a língua franca. Os SDK dos fabricantes (Unitree, Booster, EngineAI) incluem wrappers para ROS 2. Construa a sua integração do lado do ROS 2 e não sobre o protocolo proprietário do fabricante, a menos que tenha um motivo concreto.

Um exemplo concreto

Imagine a montagem de produção viável mais simples: um humanoide (Unitree G1), um servidor de inferência (Kentino AI 256 Turin Dual com 8× RTX 5090), um switch e um AP, num laboratório de 30 m².

Hardware:
- Unitree G1 (uma unidade, ~1 kW de consumo em carregamento)
- Kentino AI 256 Turin Dual / 8× RTX 5090 (sustentado ~4 kW)
- switch 10 GbE (5 portas, ~30 W)
- AP Wi-Fi 6E (~15 W)
- circuito trifásico de 32 A ou 2× monofásico de 16 A
- ~6 kW de arrefecimento dedicado (AC split)

Software no servidor:
- Ubuntu 22.04, CUDA 13, Docker
- vLLM a servir Qwen2.5-VL 72B em INT4
- vLLM a servir Qwen2.5 32B (apenas texto, para planeamento)
- pgvector para a memória de cena
- Isaac Sim para trabalho sobre políticas
- Prometheus + Grafana

Software no robô:
- driver ROS 2 da Unitree
- nó ROS 2 próprio de encaminhamento de comandos
- cliente gRPC para os endpoints do vLLM
- YOLO local para deteção rápida de obstáculos

Esta é uma arquitetura real e viável, que se pode comprar e pôr de pé em duas a três semanas. O orçamento total do lado da computação (servidor, rede, instalação elétrica, acréscimo de arrefecimento) situa-se na faixa dos 60k €–90k €, conforme a configuração. O robô é uma rubrica à parte.

Para um laboratório de investigação com 2–4 robôs, o mesmo servidor escala — o vLLM lida bem com pedidos concorrentes e o estrangulamento passa a ser a memória das GPU (se quiser alojar mais modelos em simultâneo) ou a potência disponível na tomada.

O que avaria

Lista honesta dos modos de falha que já vimos, por ordem aproximada da frequência com que atacam:

• Jitter de Wi-Fi em carga. Uma rede até aí impecável fica congestionada quando entra um novo dispositivo, a latência salta de 5 ms para 80 ms e o comportamento reativo do robô degrada-se. Solução: SSID dedicado à robótica, apenas 6 GHz, AP com linha de vista.
• A troca de modelo deita o sistema abaixo. Atualiza o VLM, o vLLM tem de recarregar e o pipeline de comandos do robô excede o tempo limite. Solução: serviço blue/green, dois endpoints, trocar um de cada vez.
• Throttling térmico do servidor. Com treino e inferência sustentados, o AC da sala não dá conta e as GPU entram em throttling. A latência de inferência duplica em silêncio. Solução: dimensionar o arrefecimento para 1.3× da carga sustentada, monitorizar as temperaturas das GPU e alarmar aos 80 °C.
• Falhas de cabos e conectores do lado do robô. Os robôs vibram. Os fios fatigam-se. Conte com uma falha de cabo de rede ou de sensor por robô e por trimestre em unidades de uso intenso. Tenha sobressalentes.
• Incompatibilidade entre driver NVIDIA e versão do CUDA depois de um apt-get upgrade. Isto apanha toda a gente exatamente uma vez. Fixe a versão do driver, use contentores e não faça apt-get dist-upgrade num servidor que está a funcionar.
• Desvio de relógio entre o robô e o servidor. As marcas temporais dos sensores afastam-se dezenas de milissegundos, a fusão de sensores produz lixo e ninguém percebe porquê. Solução: NTP local, monitorizá-lo e alarmar com desvio > 5 ms.

Nada disto é catastrófico. Tudo isto é previsível depois de acontecer uma vez.

Quando o caminho on-premise é a resposta errada

Para sermos honestos: o servidor de inferência on-premise é a resposta errada quando —

• O seu robô é puramente teleoperado e o operador já está sentado a uma estação de trabalho na cloud. Use simplesmente a cloud.
• Está a instalar um quadrúpede para uma tarefa de inspeção no exterior e não há necessidade de inferência com modelos grandes; a computação a bordo chega.
• O tamanho do seu modelo cabe mesmo num Jetson Orin AGX (50–70 W de TDP) e o seu orçamento de latência permite correr a bordo. O Orin corre um LLM de 7B em INT4 a uma velocidade utilizável.
• Está a fazer uma demonstração pontual. A cloud é mais rápida de montar, mais barata com carga zero e pode desmontá-la numa tarde.

O caminho on-premise é o acertado quando a instalação é permanente, os dados são sensíveis, o orçamento de latência é apertado ou as necessidades de personalização são reais. Quase todo o trabalho sério de robótica em 2026 cumpre pelo menos uma destas condições.

Isto 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.