Implementação de frotas: vários robôs, computação partilhada

Um robô é um projeto. Cinco robôs são um sistema. Vinte robôs são uma operação. Todas as equipas que cresceram para além da primeira unidade descobrem que o problema de engenharia muda de forma duas vezes pelo caminho — uma por volta dos três robôs, outra por volta dos dez. Este artigo trata do que muda, de porque é que os servidores Kentino AI que a Kentino fornece escalam melhor do que as pessoas esperam, e da disciplina operacional de que realmente precisa no dia 1 da frota 2 do robô 3.

I01 tratou do problema das duas caixas para um robô e um servidor. K03 explicou como o vLLM reparte um modelo por várias GPU. R08 fundamentou a razão para ter tudo nas próprias instalações. Este artigo assenta sobre os três anteriores e responde à pergunta seguinte: agora que quer fazê-lo N vezes, o que é que parte?

Os três regimes

Existem três regimes relevantes de dimensão de frota. As transições entre eles são operacionais, não técnicas — o hardware é semelhante; a forma de o gerir não é.

Sem rodeios: conte com uma pessoa dedicada às operações de robótica por volta do robô 3. A barreira não é a rede nem o servidor GPU; a barreira é a atenção humana. Um operador consegue gerir dois robôs de forma improvisada. Aos cinco, a cadência do "a este acabou a bateria, àquele desalinhou-se o lidar, ao terceiro falhou a rede" é um trabalho a tempo inteiro, e fingir o contrário só desperdiça a primeira contratação a fazê-lo a meio tempo e mal.

A economia da computação — o que um Kentino AI de 8 GPU serve de facto

O número que deve orientar o dimensionamento é o de pedidos VLM simultâneos por segundo e por robô, e não o de robôs por servidor. Um robô não é uma carga fixa; é uma classe de carga de trabalho. Uma tarefa de picking a 2 Hz não é igual a uma tarefa de navegação a 0.5 Hz, que por sua vez não é igual a um agente de diálogo a 0.2 Hz.

Envelopes aproximados para um Kentino AI 256 de 8 GPU com 8× RTX 5090 (vLLM FP8 / INT4, modelo único, batching contínuo ativo, cache de prefixo ativa; ver I02 e K03):

Estes são envelopes, não promessas. Os números variam com o comprimento do prompt, a resolução da imagem, a taxa de acerto da cache de prefixo (muito mais alta em contexto de frota, porque robôs no mesmo edifício partilham o contexto do ambiente) e a mistura exata entre prefill e decode. O padrão que importa é a forma: cargas de trabalho só com VLM pequeno servem muitos robôs por servidor; cargas com VLM grande no ciclo servem poucos.

Uma instalação real raramente corre um só modelo. Uma frota a fazer trabalho útil quer normalmente um VLM de 72B para raciocínio de cena, um LLM de 32B para planeamento e um VLA pequeno para a intenção de movimento ao detalhe. O Kentino AI de 8× corre os três em simultâneo. Com essa mistura, o teto realista num servidor é de 4–6 humanoides a fazer trabalho VLM em ciclo fechado. É esse o número com que deve planear — e não o otimista "medimos 24 pedidos 7B em simultâneo".

A alavanca do batching (e porque as frotas saem baratas)

A razão pela qual um único servidor grande ganha a muitos servidores pequenos é o batching contínuo. O vLLM mantém um lote rotativo de pedidos em curso; em cada passagem para a frente, os pedidos concluídos saem e entram pedidos novos. Benchmarks públicos mostram o vLLM a atingir 2.3× o débito do Text Generation Inference e 14–24× o do PyTorch simples no mesmo hardware, precisamente graças a esta alavanca.

Numa frota, o efeito acumula-se. Cinco robôs a bater no mesmo endpoint VLM com prompts semelhantes produzem um padrão de batching quase ideal: a maioria dos pedidos partilha um longo prompt de sistema (80–95% de acerto na cache de prefixo), os tempos de chegada são suficientemente descorrelacionados para o lote se manter cheio, e o custo por pedido amortiza-se no trabalho de prefill partilhado.

1 robô    = 1.00× de computação (base)
2 robôs   = ~1.6× de computação (o batching ajuda)
4 robôs   = ~2.5× de computação
8 robôs   = ~4.0× de computação

Duplicar os robôs não duplica o custo de computação quando partilham um backend. Este é o argumento do lado da carga a favor de um servidor grande em vez de muitos pequenos. Junte-lhe o argumento do capex (uma máquina com 8× 5090 é ~15–25% mais barata na lista de materiais do que duas com 4× 5090) e o argumento operacional (um servidor a monitorizar, não dois) e as contas são unânimes para frotas até cerca de oito robôs.

Acima de oito, passa a ser necessário um segundo servidor de qualquer forma, e a questão passa a ser como repartir o tráfego — ver abaixo.

A arquitetura para uma frota de 3–8 robôs

Três planos num único host físico (abaixo de ~8 robôs): gestão da frota, coordenação e inferência. Cada um é logicamente distinto; acima dessa dimensão, separam-se por vários hosts.

Três planos, não uma caixa. O plano de gestão da frota é a camada virada para o operador — inventário de robôs, telemetria, atualizações OTA, alertas. O plano de coordenação é a camada entre robôs — mapas partilhados, alocação de tarefas, memória de cena. O plano de inferência é a camada de serviço dos modelos — vLLM atrás de um router. Correm no mesmo host físico Kentino AI em frotas abaixo de ~8 robôs e em hosts separados acima disso.

Encaminhamento de pedidos: o que fica à frente do vLLM

Uma montagem ingénua com um endpoint vLLM, quatro robôs e round-robin TCP funciona durante uma semana e cai na primeira vez que um pedido demora 8 segundos e os quatro seguintes ficam atrás dele na fila. O router é o que evita isso.

Três opções, por ordem de complexidade:

nginx simples com least_conn. O round-robin é a escolha errada; o que se quer é o menor número de ligações ativas, para que um pedido lento não arraste toda a frota atrás de si. Cinco linhas de configuração. A resposta certa para um modelo, um endpoint, duas réplicas. Não faz nada pela cache KV nem pela localidade de prefixo.

vLLM Router (Rust, lançado no final de 2025). Hashing consistente sobre o prefixo do prompt, para que a mesma conversa caia sempre na mesma réplica e a cache de prefixo se mantenha quente. Numa frota em que cada robô tem a sua conversa mas todos partilham um longo prompt de sistema, esta é a escolha certa. As políticas são cache_aware, power_of_two e round_robin; a cache-aware é a predefinição para frotas em produção.

llm-d em Kubernetes. Desagregação de prefill/decode, escalonamento multi-réplica, extensões de inferência no gateway. A resposta certa quando se tem ≥4 réplicas, vários tipos de modelo e uma equipa de operações nativa em Kubernetes. Excessivo para todos os outros.

A afinidade de sessão é a questão subtil. Um robô a conversar com um agente de planeamento beneficia de encaminhamento fixo para a mesma réplica (cache de prefixo). Um robô que dispara etiquetas de cena VLM avulsas não — essas são sem estado, encaminhe-as em round-robin. A resposta certa é encaminhar por tipo de pedido, não por cliente: planeamento para cache-aware, etiquetagem de cena para round-robin. O vLLM Router suporta ambos através de política por endpoint.

Memória de cena: onde vive o contexto de cada robô

Um robô não é um cliente sem estado. Lembra-se de onde deixou a chave inglesa ontem, de quem entrou pela porta há uma hora, de que a caixa de cartão no corredor 7 já lá está há três dias. Essa memória tem de viver nalgum sítio, e a escolha do onde é uma das decisões estruturais no desenho de uma frota.

Três padrões:

Opção A — pgvector por robô no servidor. Cada robô tem a sua própria coleção numa instância partilhada de Postgres+pgvector. A memória é duradoura, consultável do lado do servidor e acessível à gestão da frota. Simples, escala para dezenas de robôs num só Postgres. A privacidade é o ponto fraco: cada byte da memória de cada robô fica centralizado.

Opção B — memória de cena no robô, com RAG para o servidor. O robô guarda os seus próprios embeddings num repositório local sqlite-vss ou DuckDB. Quando consulta o VLM do servidor, envia os excertos recuperados relevantes como parte do prompt. A memória é local e privada; a rede só vê aquilo que o robô decidiu enviar. Melhor para implementações sensíveis (saúde, defesa, ou onde o operador não queira que a memória em bruto saia do robô). Consome mais largura de banda por chamada.

Opção C — repositório de cena partilhado com namespaces. Todos os robôs escrevem e leem num único repositório pgvector, com namespaces por local ou por tarefa. O robô 2 pode perguntar "o que viu o robô 1 no cais de carga esta manhã?" e obter uma resposta útil. É a única opção que suporta verdadeiras tarefas colaborativas. É também a opção em que uma escrita envenenada por um robô contamina a visão do mundo dos restantes.

A predefinição honesta para uma frota de 3–8 robôs é a Opção C com controlo de acessos rigoroso — os robôs escrevem no seu próprio namespace e leem de um namespace "mundo" partilhado e curado (o gestor da frota promove-lhe observações depois de as validar). Para implementações sensíveis em matéria de privacidade, a Opção B. A Opção A é o caminho de menor resistência e serve perfeitamente se a colaboração não for um requisito.

Estratégias de partilha de modelos

A opção por omissão — um modelo a servir N robôs — é a certa para a maioria das frotas. Os robôs fazem tarefas semelhantes; o modelo base é o mesmo; as diferenças estão nos prompts e no contexto recuperado, não nos pesos. É o caminho mais barato e o que dá maior eficiência de batching.

Dois casos em que isso deixa de funcionar:

Cabeças afinadas por robô. O robô 1 vive no armazém e está afinado para o manuseamento de paletes. O robô 2 vive no laboratório e está afinado para a manipulação de instrumentos. Serve-se o mesmo VLM base com adaptadores LoRA distintos carregados por pedido. O vLLM suporta serviço multi-LoRA (--enable-lora --max-loras N) com uma pequena sobrecarga por pedido e batching partilhado do modelo base. Útil quando as afinações representam 0.1–1% dos pesos base (o típico em LoRA) e existem 2–10 adaptadores distintos.

Modelos especializados por classe de tarefa. Um modelo diferente por tarefa — Qwen2.5-VL para raciocínio geral de cena, OpenVLA para preensão, um 7B afinado para diálogo. Cada modelo recebe o seu endpoint vLLM na sua fatia de GPU. Encaminha-se por tipo de pedido. Mais VRAM, menos batching por modelo, mais superfície operacional. É a resposta certa depois de validar que um só modelo não dá conta do trabalho, não antes.

Comece com um modelo. Acrescente adaptadores LoRA quando tiver uma diferença de qualidade por robô medida. Acrescente modelos especializados quando tiver uma diferença por tarefa medida que o LoRA não resolva.

Gestão de frotas de robôs (RFM) — escolha um produto

Construir o seu próprio RFM é uma armadilha em que a maioria das equipas cai uma vez. As funcionalidades parecem óbvias no papel, mas são caras na realidade: inventário, ingestão de telemetria, armazenamento de séries temporais, pipeline de OTA, encaminhamento de alertas, acessos por perfil, registos de auditoria e multi-inquilino se tiver clientes. Uma equipa pequena constrói uma versão que funciona para uma frota e parte à segunda. Em vez disso, compre um destes e personalize à volta dele.

O Open-RMF é gerido pela Open Source Robotics Alliance desde 2024 e trata da alocação de tarefas, da resolução de conflitos e da arbitragem de infraestrutura partilhada (elevadores, portas, corredores). Para uma implementação nas instalações ao estilo Kentino, com robôs de vários fabricantes — por exemplo, um Unitree G1, um Booster T1 e um quadrúpede Go2, todos no mesmo local —, o Open-RMF é o único caminho aberto credível. O Formant e o Orbit são excelentes, mas são SaaS e preferem o seu próprio ecossistema.

A predefinição honesta: Open-RMF para instalações próprias com vários fabricantes, Formant para soluções alojadas com forte componente de observabilidade, Orbit para parques exclusivamente Boston Dynamics. Construir o seu próprio RFM é um erro, a menos que venda explicitamente RFM como produto.

Coordenação multirrobô na rede

Namespaces em ROS 2. Cada robô corre a sua stack ROS 2 sob um namespace único (/r01/, /r02/, …). Os tópicos, serviços e parâmetros DDS também têm namespace. Os robôs subscrevem os tópicos de estado dos pares (/r02/pose, /r03/pose) diretamente por DDS, sem broker. O DDS do ROS 2 é ponto a ponto e escala bem até dezenas de robôs numa LAN; acima de ~50, o tráfego de descoberta torna-se ruidoso e convém particionar por DDS domain ID ou passar para o modo discovery-server do ROS 2.

MQTT para telemetria a subir e comandos a descer. O ROS 2 / DDS é excelente para estado entre pares com baixa latência na LAN. Não é bom para "enviar telemetria de saúde a 0.5 Hz para a cloud de gestão da frota através de um backhaul LTE instável". O MQTT é a ferramenta certa para isso — leve, mediado por broker, com níveis de QoS para entrega garantida e suporte nativo em todas as plataformas de frota. A divisão típica: DDS na LAN, MQTT (ou HTTPS) na WAN.

Alocação de tarefas. Duas abordagens realmente usadas nas frotas de 2026:

1. Escalonador central. O gestor da frota atribui tarefas com base na disponibilidade do robô, na bateria, na localização e nas capacidades. Simples, previsível, serve 90% dos casos. O Open-RMF faz isto de origem.
2. Baseada em leilão. Os robôs licitam pelas tarefas com base numa função de custo (distância, bateria, carga atual). Ganha a licitação mais baixa. Melhor para frotas heterogéneas ou ambientes dinâmicos. Trabalhos recentes mostram métodos de leilão a conseguir ~12% de poupança energética face à alocação pela tarefa mais próxima, em frotas de 2–20 robôs. A complexidade compensa em frotas de 10 ou mais; abaixo disso é excessiva.

Prevenção de colisões. Cada robô publica a sua pose a 10 Hz e subscreve as poses dos pares. Os planeadores locais têm em conta as trajetórias dos outros. Em frotas onde dois robôs partilham rotineiramente 1 m² de espaço de trabalho, é também necessária uma camada de coordenação (a gestão de tráfego do Open-RMF é a resposta canónica).

Gestão de falhas à escala da frota

O princípio é simples: as falhas devem ser isoladas, os modos degradados devem ser suaves e a recuperação deve ser automática. Os padrões práticos:

Um robô morre, os outros continuam. Cada robô é autónomo na computação que leva a bordo para segurança e perceção reativa. Perder um robô é perder um robô — os pares não ficam bloqueados à sua espera. O gestor da frota marca-o como indisponível, realoca as suas tarefas e alerta uma pessoa.

O servidor de inferência falha. Todos os robôs devem conseguir recuar para um modo exclusivamente de bordo quando o servidor está inacessível: sem VLM grande, sem planeamento de longo horizonte, mas com controlo local, desvio de obstáculos e passos de missão pré-carregados a funcionar. Na prática, o robô fica "cego à linguagem", mas não falha. Planeie isto e teste-o mensalmente com um bloqueio deliberado na firewall do lado do servidor.

Atualização progressiva do servidor de inferência. Duas réplicas atrás do vLLM Router: esvazie uma, reimplemente, verifique, esvazie a outra, reimplemente. Os robôs não notam qualquer interrupção, porque o router só esvazia réplicas sem pedidos em curso. O blue/green é também a escolha certa para trocar de modelo — carregue o novo modelo na réplica B, mude o ponteiro do router, valide algumas consultas e retire a réplica A. Saltar o passo de aquecimento morde toda a gente exatamente uma vez (ver I02 sobre a armadilha do aquecimento).

A regra do 1 em N. Em qualquer momento, numa frota de N robôs, parta do princípio de que um está degradado, um está offline e um está a fazer algo inesperado. Dimensione a capacidade para N-2 robôs efetivos. Se N-2 não chegar para a carga de trabalho, a frota está mal dimensionada.

Observabilidade à escala da frota

O dashboard que realmente interessa, por ordem de prioridade:

1. Estado de saúde por robô. Bateria, temperatura da GPU de bordo, hora do último contacto, tarefa atual, último erro. Uma linha por robô, atualização de 5 em 5 segundos, estado vermelho/amarelo/verde. É a primeira coisa que o operador olha todas as manhãs.
2. Latência de cada robô até ao servidor de inferência. Tempo de ida e volta P50, P95 e P99 das chamadas VLM de cada robô. Saltos no P99 são o primeiro indicador de degradação do Wi-Fi, de sobrecarga do servidor ou de uma troca de modelo sem aquecimento.
3. Profundidade da fila de serviço dos modelos. vllm_num_requests_waiting por endpoint. Um valor sustentadamente acima de zero é o sinal de que a frota está a ultrapassar o servidor. Alerte a partir de 10 durante mais de um minuto.
4. Mapa de calor da utilização da frota. Que robôs estão ocupados, onde no edifício e a fazer o quê. Vista operacional; diz ao gestor se a frota está equilibrada.
5. Amostragem das saídas do modelo. Uma pequena fração (1–5%) das respostas do modelo guardada numa fila de revisão. Verificação manual por amostragem semanal. A única forma de apanhar regressões silenciosas de qualidade.

Prometheus + Grafana para as métricas; a vista de saúde por robô é normalmente a que vem com o RFM (Formant, Orbit ou um Grafana próprio). As séries vLLM relevantes são vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds — são elas que contam a saúde do lado da inferência; o exportador DCGM cobre o lado da GPU.

A realidade da escala de custos

Duas observações:

• O capex por robô é praticamente constante a partir dos 4 robôs. Abaixo de 4, domina o custo fixo do servidor. Acima de 4, paga-se linearmente a computação proporcional à carga. O ponto ideal para o primeiro servidor é de 4–6 robôs.
• O capex dos robôs (que é separado e domina) escala linearmente. A computação é a rubrica pequena a partir de ~3 robôs. A grande alavanca de custo é "precisa sequer de ter tudo nas suas instalações" (ver R08), e não "que tamanho de servidor".

A economia da computação argumenta fortemente a favor de um grande servidor Kentino AI a servir 4–8 robôs em vez de vários servidores mais pequenos. Duas máquinas Kentino AI 256 são piores do que um Kentino AI 256 com 8× Pro 6000 para a mesma frota, até se atingir um teto de capacidade do servidor que obrigue a DP=2. O ponto de viragem depende da carga de trabalho, mas situa-se por volta dos 7–9 robôs em trabalho pesado com VLM no ciclo.

A opinião honesta

Frotas acima de cinco robôs são uma disciplina operacional diferente das unidades isoladas. Não são "cinco vezes um projeto de um robô". São um projeto de outra forma, onde:

• A computação é uma rubrica pequena; as operações são a grande rubrica
• O estrangulamento costuma ser humano (a atenção do gestor) antes de ser técnico
• O planeamento de Wi-Fi e de energia morde três vezes mais do que numa frota de 1
• O custo de uma afinação por robô é real; o custo da degradação do modelo em toda a frota é ainda mais real
• Construir o seu próprio RFM é quase sempre um erro; escolha um e personalize-o

O lado computacional do problema está genuinamente resolvido em 2026. vLLM + um router + um servidor Kentino AI bem dimensionado dão conta de frotas de até cerca de 8 humanoides numa só máquina. Acima disso, escala-se por paralelismo de dados (mais servidores atrás do router) — abordado em K03. Os problemas difíceis acima dos 5 robôs são operacionais, não arquiteturais.

---

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