Configuração de referência: um laboratório de robótica e IA num só rack

Os artigos anteriores descrevem a arquitetura, a stack de software, o orçamento energético e o desenho da rede. Este coloca um preço e uma lista de componentes em tudo isso — a partir de hardware real que a Kentino já expediu e submeteu a benchmarks, não de uma BOM teórica montada a partir de uma ficha de marketing.

O cenário de implementação é um laboratório de investigação ou integração com um a quatro robôs, a par de inferência on-premise e de uma pista de treino. Escala intermédia: nem uma máquina de amador que mal consegue servir um 7B, nem um cluster à escala de hyperscaler que exige uma equipa de instalações. Um ambiente de trabalho sério que uma equipa de duas a seis pessoas consegue montar, operar e fazer evoluir sem DevOps dedicado.

O artigo cobre dois níveis do mesmo padrão arquitetural. O nível de desenvolvimento de 4 GPU é onde a maioria dos laboratórios começa. O nível de produção de 8 GPU é onde acabam por chegar depois da primeira carga de trabalho a sério. As escolhas de hardware são diferentes; a arquitetura é idêntica.

O que os dados da frota mostram

A Kentino implementou uma frota de nós de computação de 4 GPU com configuração uniforme. Cada unidade tem a mesma especificação: AMD EPYC 7542 (32 núcleos / 64 threads, 2.9 GHz boost), 512 GB DDR4 ECC LRDIMM a 2666 MT/s em oito DIMM, quatro GPU RTX 4090 (24 GB de VRAM cada, 96 GB no total), um disco NVMe de 2 TB para scratch e um SSD SATA de 512 GB para o sistema operativo. A placa-mãe é a ASRockRack ROMED8-2T/BCM. Ubuntu 24.04 LTS, kernel 6.8.0-generic, driver NVIDIA 590.48.01, CUDA 13.1/13.2.

Os dez nós produzem números de benchmark idênticos. Isso não é um acaso — é precisamente o objetivo de uma build de referência. Quando todas as unidades saem com a mesma configuração, o benchmark é uma especificação e não um resultado de sorte.

Computação GPU

Multiplicação de matrizes FP16 em tensor cores nas quatro placas (carga de trabalho 8192 × 8192):

A GPU 1 fica cerca de 6% abaixo das GPU 0, 2 e 3 — dentro da dispersão normal da lotaria do silício em placas de consumo. As quatro passaram 60 segundos de GPU-burn e de burn combinado GPU+CPU sem qualquer erro de cálculo. A margem térmica é confortável: o limiar de throttling térmico da RTX 4090 é de 83 °C e a placa mais quente da frota atingiu no máximo 73 °C sob carga simultânea de GPU e CPU. Não se observou throttling em nenhum nó.

Uma nota prática sobre limites de potência: a frota é expedida com limites por placa ligeiramente diferentes (450 W, 480 W, 500 W consoante a slot). Para uso continuado em produção, normalizar as quatro a 450 W suaviza o consumo agregado e reduz o desequilíbrio entre as fontes de alimentação. A penalização em TFLOPS a 450 W face a 500 W fica abaixo de 2% — não compensa a carga assimétrica nas linhas.

Inferência em vLLM — Llama 3.3 70B AWQ

Testado com vLLM 0.19.0, tensor_parallel_size=4, gpu_memory_utilization=0.80, max_model_len=2048:

Uma ressalva importante: o benchmark usou o kernel de quantização awq e não awq_marlin. O caminho awq_marlin em Ada Lovelace (RTX 4090) é 2–3× mais rápido na latência de pedido único. As implementações em produção devem usar awq_marlin ou o caminho FP8 em vLLM 0.20+, que reduz ainda mais a diferença. Com awq_marlin, o valor de pedido único acima passa de ~8 tok/s para aproximadamente 16–20 tok/s nestas placas — mais coerente com o que os utilizadores observam na prática. O ganho no débito agregado em lote é proporcionalmente menor, porque com elevada concorrência o estrangulamento passa da computação para a largura de banda de memória.

Estes números referem-se ao Llama 3.3 70B em INT4 (AWQ). Um modelo 7B ou 8B em Q4 corre 4–6× mais depressa por token no mesmo hardware; um modelo 13B corre cerca de 2.5× mais depressa. O número do 70B é a restrição de dimensionamento relevante para VLM e grandes modelos de planeamento num contexto de robótica.

llama.cpp — utilizador único, sem concorrência

Testado com llama-cpp-python 0.3.20 (CUDA/cuBLAS), Llama 3.3 70B Instruct Q4_K_M GGUF, com as quatro GPU:

O llama.cpp carrega mais depressa (10.8 s contra 95 s do vLLM) e entrega maior velocidade de descodificação para um só utilizador nestas placas, porque não paga a sobrecarga do escalonador de batching contínuo. A contrapartida é concorrência zero — um utilizador de cada vez. A leitura certa destes números: o llama.cpp num nó de 4 GPU dá a um programador um modelo 70B com boa resposta para uso interativo; o vLLM é a escolha certa a partir do momento em que há mais do que um cliente.

Consulte I02 para a matriz de decisão completa da stack de serviço. Em resumo: comece com vLLM em Docker, use quantização awq_marlin e passe para llama.cpp apenas em máquinas de desenvolvimento de utilizador único ou em implementações Jetson.

Largura de banda da memória da GPU

A largura de banda device-to-device (na própria placa) é consistente, entre 920.2 e 920.6 GB/s nas quatro placas — com menos de 0.04% de diferença entre si, o que confirma que a GDDR6X não é a variável aqui. A largura de banda PCIe Host→Device fica em 26.2–26.3 GB/s, confirmando que o Gen4 x16 é plenamente negociado sob carga (em repouso o estado da ligação aparece como Gen1 devido à poupança de energia ASPM — normal, não é uma falha). As transferências peer entre GPU por PCIe (sem NVLink) medem 19–22 GB/s, que é o teto esperado para peer-to-peer num complexo raiz PCIe partilhado sem NVLink (ver N03 para contexto).

Armazenamento NVMe

A largura de banda sequencial está perto do teto do Gen4 x4. As IOPS aleatórias com profundidade de fila 32 saturam bem: 568K IOPS de leitura estão muito acima do que o carregamento de pesos de LLM ou os padrões de acesso a conjuntos de dados exigem à escala de um único nó. Carregar um modelo de NVMe para VRAM demora 10–30 segundos, consoante o tamanho do modelo; este disco não é o estrangulamento.

A build de referência

BOM — nível de desenvolvimento de 4 GPU

O nível de desenvolvimento é o ponto de partida certo para um laboratório com um ou dois robôs, um ou dois modelos ativos e algum fine-tuning LoRA ocasional em paralelo.

Nível de desenvolvimento: nó de computação de 4 GPU + switch ToR gerido + AP 6 GHz + UPS online de 5 kVA.

BOM — nível de produção de 8 GPU

O nível de produção duplica o número de GPU. O padrão arquitetural é o mesmo; a CPU, a RAM e o chassis escalam em conformidade para suportar oito slots PCIe com largura de banda plena. Uma plataforma AMD EPYC Genoa ou Turin fornece o orçamento de linhas PCIe para 8 slots x16 sem compromissos de bifurcação (ver W02).

Nota: a NIC 25 GbE opcional só é viável em chassis de 8 GPU. O chassis de 4 GPU não tem espaço livre de slot para uma placa de rede adicional — as portas 10 GbE integradas na ROMED8-2T/BCM são o limite prático no nível de 4 GPU (ver N01 e as regras da página de produto).

Armazenamento para além do nó de computação

Para o nível de desenvolvimento, um NAS de 4 baias com 4 discos de 16 TB dá 48 TB utilizáveis em RAID-5 — suficiente para um ano de dados de episódios num laboratório com 2 robôs. Ligue-o a 10 GbE ao switch ToR; não o coloque na mesma interface que o tráfego dos robôs.

Energia e arrefecimento do rack

A partir de I04:

Os dados do teste de stress da frota confirmam que o nó de 4 GPU consome ~1,914 W com as GPU em carga máxima e as quatro placas a atingir os respetivos limites de potência. Somando a CPU (~120 W em contínuo), o NVMe e as ventoinhas, o nó fica aproximadamente em 2.1–2.2 kW sustentados.

Instalação elétrica para o nível de desenvolvimento: uma alimentação trifásica de 400 V 16 A é o mínimo; 32 A trifásicos dão margem para crescer. Cabos das fontes de alimentação em duas fases separadas. Ver I04 e P02 para o esquema de cablagem. Para o nível de produção (rack completo de 10 kW), é necessária uma alimentação trifásica de 400 V 32 A com pelo menos 15 kW de capacidade de arrefecimento.

Dimensionamento da UPS: dimensione apenas para o servidor, não para os robôs. Para o nível de desenvolvimento, uma UPS online de dupla conversão de 5 kVA é o mínimo razoável. Para o nível de produção, 10 kVA. Especifique sempre online de dupla conversão. Ver P05.

Stack de software em bare metal

Stack de software: Ubuntu + driver NVIDIA fixados → container toolkit → vLLM + llama.cpp + nginx + monitorização.

Fixar a versão do driver não é negociável. A frota corre o driver 590.48.01; apt-mark hold nvidia-driver-590 é a primeira coisa a fazer depois da instalação do sistema operativo em bare metal. Um apt-get upgrade não vigiado que puxe um driver mais recente já estragou a inferência em produção exatamente tantas vezes quantas seria de esperar. Ver L01 para o procedimento completo.

A monitorização não é opcional. Os dados da frota mostram que a GPU 3 de um dos nós teve erros PCIe AER corrigíveis (RxErr + BadTLP) durante os benchmarks — corrigidos automaticamente pelo hardware, mas visíveis nos contadores DCGM. Sem monitorização, isto aparece semanas mais tarde sob a forma de "erros estranhos ocasionais na inferência". Configure o DCGM e defina um alerta para erros ECC corrigíveis acima de uma taxa de referência. Ver L05 para a stack Prometheus + Grafana.

Variações de dimensionamento

O nível de desenvolvimento de 4 GPU — o que consegue realmente correr

96 GB de VRAM no total (4× 24 GB) com TP=4:

O VLM de 72B não cabe com folga em 4× 24 GB em INT4 — as contas ficam à justa, mas janelas de contexto acima de 4K ultrapassam o limite. Use a variante VLM de 32B ou suba para o nível de 8 GPU ou para um nó com 4× RTX Pro 6000 Blackwell (96 GB de VRAM cada) para a classe 72B. Ver W07 para a discussão entre VRAM e escalão de modelo.

O nível de desenvolvimento dá conta de: um modelo de inferência 70B a servir 1–3 clientes robóticos em simultâneo, um VLM (classe 32B) para consultas visuais e fine-tuning LoRA ocasional sobre um modelo base mais pequeno. Isso cobre 80% dos casos de uso de laboratórios de robótica em 2026.

O nível de produção de 8 GPU — a margem extra

192 GB de VRAM no total (8× 24 GB):

O nível de 8 GPU abre também a porta ao serviço simultâneo de vários modelos: um LLM de 70B em 4 GPU e um VLM de 32B nas outras 4, servindo ao mesmo tempo, a partir de uma única máquina, uma frota mista de robôs com requisitos de modelo diferentes. No nível de 4 GPU isto exige uma troca de modelo, com 30–120 s de indisponibilidade por troca.

Nota sobre TP=8 para um 70B: TP=8 sobre peer-to-peer PCIe (sem NVLink) escala pior do que TP=4 × PP=2 com concorrência acima de 8, porque o custo de comunicação do all-reduce cresce com o grau de paralelismo tensorial. Os dados de benchmark mostram largura de banda PCIe entre GPU de 19–22 GB/s — suficiente para TP=4, mas o all-reduce com TP=8 em lotes grandes satura essas ligações. A configuração recomendada para um 70B em 8× 4090 é TP=4 × PP=2, como se mostra em I02.

Disposição do rack

O nó de computação fica sempre abaixo do switch e da UPS — o fluxo de ar frente-para-trás exige que o ar frio entre pela frente do rack (corredor frio ou insuflação de ar condicionado da sala), atravesse o servidor e saia para o corredor quente na retaguarda. Ver W05 e I04 para a disciplina de fluxo de ar.

O jump host é uma máquina 1U ou de formato reduzido com saída de vídeo, usada para o arranque inicial, instalação de drivers e manutenção quando o servidor principal está inacessível pela rede. Não precisa de GPU. Uma estação de trabalho usada ou um pequeno 1U com 16 GB de RAM e um SSD Gen3 chegam perfeitamente.

O que esta build não é

Não é um servidor GPU de secretária dentro de uma caixa de rack. A build em torre de secretária ao ar livre — GPU montadas numa riser card, sem caixa, ventoinhas apontadas ao teto — não é o que aqui se descreve. As builds de secretária servem para desenvolvimento; não estão homologadas para funcionamento contínuo 24/7 e não oferecem o fluxo de ar dirigido de frente para trás que mantém as GPU a uma temperatura de funcionamento estável durante semanas.

Não é um cluster NVLink. A RTX 4090 (classe consumo/estação de trabalho) não tem NVLink. As transferências entre GPU passam por PCIe a 19–22 GB/s e não a 900 GB/s. Isto chega para servir inferência com TP=4 e é uma limitação real para treino com TP=8. Se a sua carga de trabalho for treino distribuído pesado num modelo de 70B ou maior, a RTX Pro 6000 Blackwell (compatível com NVLink na sua edição multi-GPU) ou uma plataforma com NVSwitch mudam as contas — mas também o preço. Ver N03.

Não são fontes de alimentação redundantes. A configuração com duas fontes de alimentação é de entrega repartida: a fonte A alimenta as GPU 0 e 1 (mais a placa-mãe) e a fonte B alimenta as GPU 2 e 3. Se a fonte A falhar, perde duas GPU e a placa-mãe. Nada assume a carga automaticamente. Isto é uma solução honesta de dupla fonte — equilibra a carga nas linhas e reduz o risco de ponto único face a uma única fonte de grande potência, mas não é redundância N+1. Ver W04.

Não é alternativa à cloud para tudo. Se a carga de trabalho principal do seu laboratório for uma chamada a um modelo dez vezes por dia, as contas de TCO não justificam a solução on-premise. Esta build compensa face ao custo de APIs na cloud quando se corre inferência continuada para vários clientes, se faz fine-tuning com regularidade ou se opera sob restrições de residência de dados. Ver T02 para as contas detalhadas.

Porquê estas escolhas em concreto

AMD EPYC 7542 como CPU anfitriã. Um EPYC de 32 núcleos fornece 128 linhas PCIe 4.0 só a partir da CPU, o suficiente para 4 GPU a x16 sem bifurcação, mais uma placa de rede, armazenamento e um switch PCIe para expansão. Há uma razão para o EPYC ser a plataforma padrão em servidores de IA multi-GPU a esta escala: um Intel Xeon com a mesma contagem de núcleos oferece menos linhas PCIe, o que força compromissos de bifurcação em configurações com 4 ou mais GPU. Ver W02 para a aritmética das linhas PCIe.

512 GB de RAM de sistema. A frota é expedida com 512 GB (8× 64 GB), acima da especificação nominal de 256 GB. É intencional: o carregamento de modelos grandes no arranque do contentor, o pré-carregamento de conjuntos de dados para treino e a cache de páginas do sistema operativo consomem todos RAM que a VRAM não pode dar. No vLLM com espaço de swap da KV-cache ativado, a RAM de sistema é diretamente utilizável como transbordo — 4 GB de swap por GPU exigem 16 GB de margem de RAM de sistema. Os 512 GB dão essa margem com espaço para o Isaac Sim, que pode manter 10–30 GB de estado de simulação em RAM de sistema durante o treino de políticas.

2 TB de NVMe para scratch. O benchmark mostra 4,589 MB/s de leitura sequencial — rápido o suficiente para carregar um modelo 70B em FP8 (~75 GB) em menos de 20 segundos. Para um laboratório que troca de modelo com frequência (fluxo de desenvolvimento, testes A/B de stacks de inferência), o tempo de carregamento conta. Um SSD SATA mais lento duplica ou triplica esse tempo em cada troca.

Fluxo de ar no rack de frente para trás. O erro mais comum em builds de estreia: a orientação de secretária (entrada lateral, exaustão superior, exaustão traseira) não funciona num rack fechado. O nó de computação tem de usar fluxo de ar dirigido, de acordo com a convenção de corredor frio / corredor quente do rack. Ver I01 e W05.

A leitura honesta do hardware de 2026

Esta é uma build de referência para maio de 2026. A RTX 4090 não é a opção de GPU mais recente da Kentino — a RTX 5090 (32 GB de VRAM, arquitetura Blackwell, sm_120) e a RTX Pro 6000 Blackwell (96 GB de VRAM) estão disponíveis e alteram significativamente a conta de VRAM por placa. Um nó de 4 GPU com RTX Pro 6000 Blackwell dá 384 GB de VRAM — suficiente para alojar o Qwen 2.5 VL 72B com folga em FP8 nas quatro placas — a um custo por placa proporcionalmente mais elevado.

O que não muda entre gerações: o padrão arquitetural. Anfitrião AMD EPYC, multi-GPU por PCIe, chassis de frente para trás, dupla fonte de alimentação, Ubuntu 24.04, vLLM em Docker, Prometheus + exportador DCGM. Esse padrão manteve-se ao longo de duas gerações de GPU e vai sobreviver à seguinte. A lista de componentes fica mais barata e mais rápida; o padrão mantém-se.

---

Este artigo 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.