Caso de Estudo: Estação de Trabalho de IA com 4x RTX 4090

Este artigo documenta uma montagem completa encomendada por um cliente de investigação que necessitava de uma estação de trabalho de inferência LLM instalável em rack, capaz de funcionar 24/7 e com VRAM suficiente para alojar modelos da classe 70B sem dependência da cloud. Tudo o que aqui consta foi medido no hardware real. Sem estimativas sintéticas, sem números de marketing.

A montagem foi encomendada e entregue em abril de 2026. Os benchmarks de comissionamento foram executados a 2026-04-10.

Porquê 4× RTX 4090

O requisito de carga de trabalho era claro desde o início: executar um LLM 70B quantizado com uma latência utilizável por pedido individual, servir pedidos simultâneos no contexto de uma pequena equipa de investigação e manter tudo on-premises por razões de controlo de dados. A questão era quantas GPU e de que tipo.

Um modelo 70B em INT4 (AWQ ou GGUF Q4_K_M) ocupa na prática cerca de 38–40 GB de VRAM. Isso elimina por completo as soluções de GPU única — nem sequer uma RTX 4090 com 24 GB consegue alojar o modelo sozinha. São necessárias pelo menos duas, de preferência quatro, para que o serviço em paralelismo de tensores sob vLLM tenha margem para a cache KV.

Quatro placas RTX 4090 dão 96 GB de VRAM total. É suficiente para carregar um modelo Llama 3.3 70B AWQ INT4 com gpu_memory_utilization=0.80 e continuar a ter espaço de cache KV relevante para pedidos em lote. Dá também capacidade de computação — 4× chips de 128 SM a funcionar em simultâneo — que conta para a velocidade de processamento do prompt.

A alternativa considerada foi 4× RTX Pro 6000 Blackwell, que daria 4× 96 GB = 384 GB de VRAM. É um patamar completamente diferente: mais VRAM do que qualquer modelo 70B necessita, adequado a executar vários modelos grandes em simultâneo ou a alojar modelos da classe 200B+ com uma quantização razoável. Para esta carga de trabalho — um modelo principal, lote simultâneo pequeno, com o orçamento de uma estação de trabalho de inquilino único — essa capacidade extra ficaria por usar e a diferença de custo é significativa. As 4× RTX 4090 foram a resposta certa para o caso de utilização indicado.

Existe também na gama uma alternativa de 8× L40. A L40 oferece 48 GB de VRAM por placa, suporte ECC e foi concebida para carga sustentada de centro de dados. Para este cliente, a carga de trabalho não exigia contratos de fiabilidade de nível de centro de dados, a ausência de particularidades de drivers de classe consumidor na L40 era um benefício menor e o orçamento não chegava lá. Vale a pena conhecer como caminho de upgrade.

Um limite arquitetural a referir desde já: as placas RTX 4090 não têm NVLink. Toda a comunicação entre GPU faz-se por PCIe peer-to-peer. Isto é relevante para a inferência com paralelismo de tensores (abordada na secção de benchmarks) e vale a pena compreendê-lo antes de encomendar. Consulte N03 para um tratamento completo de quando o NVLink conta e quando não conta.

Especificação do hardware

Algumas notas sobre as escolhas:

CPU. O EPYC 7542 é um chip da geração Rome com 32 núcleos e 128 MB de cache L3 distribuídos por 8 CCD. Para uma estação de trabalho de inferência, é sobredimensionado em número de núcleos — não se saturam 64 threads em inferência pura. Onde ganha o seu lugar é no orçamento de linhas PCIe: o EPYC Rome disponibiliza 128 linhas PCIe 4.0 a partir do CPU, razão pela qual é possível colocar quatro GPU em x16 completo nesta plataforma sem partilha de linhas nem bifurcação. A RTX 4090 é um dispositivo PCIe 4.0 x16; são precisas quatro ranhuras x16 completas, e o EPYC dá-as. Consulte W02 para o detalhe da topologia de linhas.

RAM. O sistema foi fornecido com 512 GB DDR4 ECC LRDIMM, acima dos 256 GB originalmente especificados. A RAM de sistema adicional é genuinamente útil aqui: o carregamento do modelo a partir do NVMe passa pela RAM do sistema antes da transferência para a VRAM e, com modelos maiores ou ao alternar entre modelos, 512 GB permitem manter vários conjuntos de pesos em RAM em simultâneo e evitar leituras repetidas do NVMe.

NVMe. O armazenamento de modelos (2 TB) está numa unidade NVMe PCIe 4.0 de alta velocidade. A velocidade de leitura sequencial conta no momento do carregamento: um ficheiro de modelo de 38 GB a 4,589 MB/s de leitura sequencial carrega em cerca de 8–10 segundos. Os tempos de carregamento medidos confirmam-no: o llama.cpp carregou o GGUF 70B Q4_K_M em 10.8 segundos; o vLLM (que também constrói grafos CUDA ao carregar) demorou 95 segundos.

Fonte de alimentação dupla. O chassis utiliza duas fontes de alimentação ATX. Trata-se de um fornecimento de energia repartido: cada fonte de alimentação alimenta uma parte do sistema — normalmente duas GPU e os componentes de placa associados. Se uma das fontes falhar, perdem-se as GPU ligadas ao seu barramento. Isto não é redundância N+1; é um arranjo de capacidade de potência, não um arranjo de failover. Em sistemas de produção em que a disponibilidade é contratual, esta distinção conta. Consulte W04 para a discussão completa sobre o dimensionamento da fonte de alimentação.

Fluxo de ar do chassis. O chassis é de montagem em rack, com fluxo de ar industrial dirigido da frente para trás. As GPU não estão ao ar livre; ficam num canal de fluxo de ar dirigido, com ventoinhas da caixa a puxar ar através dos dissipadores e a expulsá-lo pela traseira. Isto torna o sistema adequado a funcionamento sustentado 24/7 num ambiente de rack. Consulte W05 para o detalhe do design térmico.

Stack de software

O ambiente Python encontra-se em /home/logic/llm-env/, os modelos no NVMe em /mnt/nvme/models/.

Resultados do comissionamento

Linha de base de computação da GPU

O primeiro teste é sempre a computação bruta: multiplicação de matrizes em FP16 (via Tensor Core) e FP32. Confirma que as placas funcionam corretamente e dá uma linha de base de computação para comparar com as especificações nominais.

Para referência: o pico teórico FP16 nos Tensor Core da RTX 4090 é de ~330 TFLOPS e o FP32 de ~82.6 TFLOPS. Os valores do benchmark, a ~52% do pico FP16, são esperados — a medição é uma multiplicação de matrizes de débito sustentado que não atinge o pico teórico de um kernel GEMM otimizado à mão. Confirmam que os quatro conjuntos de Tensor Core estão a funcionar e são consistentes.

A GPU 1 está ~6% abaixo das restantes em FP16. Trata-se de variação normal do silício dentro do mesmo lote. Não há qualquer falha de hardware.

Largura de banda de memória da GPU

A largura de banda de VRAM de 920 GB/s está em linha com a especificação da RTX 4090 (pico de 1,008 GB/s; a diferença é overhead do benchmark). É este valor de largura de banda que conta para o débito de descodificação: cada token gerado exige carregar da VRAM o conjunto completo de cache KV e tensores de pesos, pelo que a largura de banda define diretamente o limite da velocidade de geração.

O valor entre GPU (19–22 GB/s por PCIe peer-to-peer) é a restrição arquitetural relevante para o serviço com paralelismo de tensores. Com NVLink, este caminho atinge 900 GB/s. Só com PCIe, obtém-se cerca de 2% disso. Não é catastrófico para a inferência — a maior parte da comunicação de paralelismo de tensores de um modelo 70B AWQ INT4 por 4 GPU cabe no que o PCIe consegue suportar — mas reduz a velocidade de descodificação de pedidos individuais face a um sistema ligado por NVLink. Veja a secção de benchmarks abaixo e N03 para a discussão mais ampla.

Uma anomalia: a largura de banda do dispositivo para o host foi medida em 1.4 GB/s, muito abaixo dos ~26 GB/s esperados para PCIe Gen4 x16. Trata-se de um comportamento conhecido do CUDA com memória não fixada (non-pinned). Se a sua aplicação mover dados da GPU para o host com frequência (por exemplo, amostragem a partir dos logits de saída num pipeline personalizado), utilize torch.pin_memory() ou pré-aloque buffers fixados. Os pipelines de serviço padrão do vLLM e do llama.cpp não acionam este caminho no ciclo crítico.

Todas as ligações PCIe foram confirmadas em Gen4 x16 (16 GT/s) sob carga. Em repouso, o driver usa a poupança de energia ASPM e as ligações descem para Gen1 (2.5 GT/s) — isto é normal e não indica falha de cablagem ou do riser.

Armazenamento NVMe

São bons números de NVMe para uma unidade PCIe 4.0 de gama consumidor/prosumer. Para o serviço de modelos, o número relevante é a leitura sequencial: 4,589 MB/s significam que um modelo de 38 GB carrega para a RAM em aproximadamente 8–9 segundos, antes de qualquer transferência para a VRAM. Os 568K IOPS aleatórios são mais relevantes para quem executa um pipeline de recuperação (RAG, base vetorial), em que a carga de trabalho são muitas leituras aleatórias pequenas — esta unidade dá conta disso sem se tornar o estrangulamento.

Inferência vLLM — Llama 3.3 70B AWQ INT4

Este é o benchmark central. Modelo: casperhansen/llama-3.3-70b-instruct-awq. Serviço: vLLM 0.19.0 com tensor_parallel_size=4, max_model_len=2048, gpu_memory_utilization=0.80.

A velocidade de descodificação de 8.0 tok/s em pedido individual exige contexto. O vLLM 0.19.0 executou o modelo AWQ com o kernel awq e não com awq_marlin. O kernel awq_marlin é o caminho mais rápido para AWQ em GPU Ada Lovelace (RTX 4090) e Blackwell — as notas do benchmark indicam que não foi selecionado durante esta execução de comissionamento, e espera-se uma melhoria de 2–3× na velocidade de descodificação por pedido individual. Com awq_marlin, o mesmo modelo no mesmo hardware deverá atingir aproximadamente 16–24 tok/s em fluxo único.

O agregado de 179.3 tok/s com 32 pedidos simultâneos é o número mais relevante para produção. É o que uma pequena equipa a aceder ao endpoint em simultâneo verá como débito combinado do sistema. O batching contínuo do vLLM faz com que os pedidos simultâneos amortizem a cache KV e o cálculo de atenção ao longo do lote, razão pela qual 32× utilizadores não produzem 32× a latência.

A latência de 2,043 ms num pedido de 16 tokens é o mínimo de TTFT (time-to-first-token) do vLLM nesta configuração. Para casos de utilização interativa (chat, assistência de código), fica do lado lento. O principal responsável é o overhead de scatter/gather do paralelismo de tensores entre quatro GPU através de PCIe — cada passo de prefill exige um AllReduce entre as quatro placas pela fabric PCIe. Com NVLink, o TTFT seria de cerca de 50–100 ms; com PCIe P2P a 20 GB/s estica-se mais. Este é o custo direto da arquitetura sem NVLink em pedidos individuais sensíveis à latência (consulte N03).

llama.cpp — Llama 3.3 70B Q4_K_M GGUF

Modelo: Llama-3.3-70B-Instruct-Q4_K_M.gguf. Backend: llama-cpp-python 0.3.20 com CUDA/cuBLAS, todas as camadas descarregadas para a GPU.

O llama.cpp entrega cerca de 20 tok/s em descodificação de fluxo único — melhor do que o valor atual do vLLM com AWQ e atribuível ao facto de o caminho de kernel baseado em cuBLAS do llama.cpp funcionar bem com a quantização Q4_K_M. O llama.cpp não suporta batching simultâneo de vários pedidos como o vLLM, pelo que os 20 tok/s são um teto por sessão e não capacidade agregada. Em fluxos de trabalho interativos de utilizador único, o llama.cpp a 20 tok/s é uma velocidade de leitura confortável para saída em inglês.

A velocidade de processamento de prompt de 1,568 tok/s é elevada. Mede a rapidez com que o modelo ingere o prompt (fase de prefill). Um prefill rápido conta quando se executa um modelo com prompts de sistema longos ou contexto documental. A 1,568 tok/s, um contexto documental de 4,000 tokens é processado em menos de 3 segundos antes de a geração começar.

Para a análise económica e a comparação com alternativas na cloud, consulte T01 (tok/s por euro) e T02 (custo por milhão de tokens on-premises vs cloud).

Para que serve cada um dos dois motores

Teste de esforço — carga sustentada

Foram executados três testes de esforço de 60 segundos para verificar a estabilidade térmica e elétrica sob carga máxima: burn só de GPU, burn só de CPU e burn combinado de GPU+CPU.

Burn de GPU (multiplicação de matrizes FP16 a 100%, 60 s)

Zero erros de computação nas quatro GPU. As temperaturas subiram de uma linha de base de ~28°C para um patamar estável ao segundo 40. A GPU 2 foi a mais quente, com 72°C — é a placa mais quente no percurso do fluxo de ar do chassis naquela posição. O limiar de throttling térmico da RTX 4090 é 83°C; a temperatura máxima medida (72°C) deixa uma margem de 11°C. O sistema não entrou em throttling em momento algum.

Os limites de potência estavam definidos com valores diferentes nas quatro placas (480 W, 450 W, 500 W, 480 W). É uma inconsistência menor que deve ser normalizada: nvidia-smi -pl 480 -i 0,1,2,3 (ou o limite que for adequado) para definir limites consistentes antes da utilização em produção.

Burn combinado de GPU + CPU (as 4 GPU + 64 threads de CPU em simultâneo, 60 s)

Adicionar 64 threads de CPU a 100% de carga reduziu os TFLOPS agregados das GPU em apenas 0.6%. O EPYC 7542 consome cerca de 200 W de TDP em carga máxima; o sistema combinado funcionava a aproximadamente 2.1–2.2 kW no total. Todas as temperaturas se mantiveram dentro da margem: a GPU 2 atingiu um pico de 73°C em carga combinada, ainda 10°C abaixo do limiar de throttling.

O load average atingiu 55+ durante a fase de burn do CPU (esperado para 64 threads). O sistema manteve-se totalmente estável; sem eventos térmicos, sem erros de computação, sem kernel panics.

Isto confirma que o sistema é adequado a cargas de trabalho de inferência sustentadas 24/7 em que o CPU também está ocupado (pré-processamento, tokenização, overhead da infraestrutura de serviço).

O que correu bem

A plataforma EPYC. O orçamento de linhas PCIe está genuinamente resolvido. As quatro placas RTX 4090 funcionam em Gen4 x16 completo sob carga (confirmado na verificação 04d do estado PCIe). Sem bifurcação, sem ranhuras degradadas. Algumas montagens AMD Ryzen com quatro GPU funcionam com duas ou mais ranhuras em x8; no EPYC Rome não é o caso.

RAM. 512 GB é confortável. Durante o carregamento do modelo no llama.cpp, o ficheiro GGUF de 38 GB é mapeado em memória; ter 512 GB disponíveis significa poder executar vários processos a par do servidor LLM sem competir por memória.

Velocidade sequencial do NVMe. 4,589 MB/s de leitura sequencial mantêm curtos os tempos de carregamento. Num fluxo de trabalho de iteração de modelos — carregar, testar, trocar de modelo — isto soma-se ao longo de um dia.

Comportamento térmico. Temperatura sustentada de pior caso de 73°C (GPU 2, burn combinado), com 10°C de margem. Numa carga de trabalho de inferência típica, as GPU não funcionam continuamente a 100% de utilização — a descodificação é limitada pela largura de banda da VRAM, não pela computação —, pelo que as temperaturas reais de funcionamento serão inferiores ao pico do teste de esforço.

Avaliação de prompt do llama.cpp a 1,568 tok/s. Este número surpreendeu-nos pela positiva. O caminho de prefill por cuBLAS em quatro 4090 é rápido. As aplicações de contexto longo beneficiam disto.

O que nos surpreendeu

O kernel AWQ errado no vLLM. O benchmark correu com o kernel awq em vez de awq_marlin. A suite de comissionamento acionou-o automaticamente com base na configuração do modelo à data. Com awq_marlin, espera-se que o débito por pedido individual suba de 8 tok/s para 16–24 tok/s. Trata-se de uma correção de configuração de software, não de uma limitação de hardware — verifique a string do método de quantização do vLLM ao configurar o serviço em produção.

Largura de banda D2H. Os 1.4 GB/s do dispositivo para o host apanharam-nos de surpresa na análise inicial. É um comportamento do CUDA com memória não fixada, não uma falha do PCIe. Para stacks de serviço padrão (vLLM, llama.cpp) não tem importância. Para código de inferência personalizado que move tensores para o CPU para pós-processamento, utilize alocações de memória fixada.

Erros PCIe AER corrigidos na GPU 3. Durante o benchmark do vLLM, a GPU 3 (bus c1:00.0) registou erros PCIe corrigidos (RxErr + BadTLP). Foram corrigidos automaticamente pelo hardware e não afetaram a computação. Causa provável: encaixe do riser PCIe ou renegociação da ligação à velocidade Gen4. A recomendação é monitorizar sob carga de produção sustentada; se a contagem de erros aumentar, volte a encaixar o cabo riser da GPU 3. Zero erros durante os próprios testes de esforço.

Breve oscilação da ligação da NIC. A interface de rede caiu brevemente e voltou durante a carga do benchmark de GPU (13:38 UTC). Provavelmente um transiente de potência resultante do arranque simultâneo das GPU. Em produção, com o nvidia-persistenced em execução (que mantém os contextos de GPU inicializados), os transientes de potência no arranque da carga são menores. Ative o nvidia-persistenced como serviço systemd antes de entrar em produção.

O que faríamos de diferente numa v2

Ativar o awq_marlin desde o início. Verificar o caminho do kernel de quantização do vLLM durante o comissionamento, não depois. Acrescentar ao script de comissionamento uma verificação da identidade do kernel.

Normalizar os limites de potência das GPU antes do benchmarking. As quatro placas vieram com limites configurados diferentes (480 W, 450 W, 500 W, 480 W). Definir um limite consistente (nvidia-smi -pl) antes da primeira execução do benchmark dá números mais limpos e comparáveis e evita o consumo inconsistente durante o burn combinado.

Acrescentar uma stack de monitorização na entrega. O Prometheus com o exportador DCGM, mais o Grafana, demora algumas horas a configurar e torna visíveis em tempo real a temperatura das GPU, a utilização de VRAM e as taxas de erro PCIe. Incluir isto no comissionamento padrão em vez de o deixar como tarefa pós-entrega. Consulte L05 para o guia de configuração da stack.

Fixar o nvidia-persistenced no ficheiro de unidade systemd durante a instalação do SO. É uma linha só, mas é sistematicamente esquecida. Sem ela, o primeiro carregamento de GPU após um período de inatividade demora alguns segundos adicionais e produz o transiente de potência que causou a oscilação da NIC.

Expansão do LVM. O disco do SO (SATA de 512 GB) tem apenas 100 GB atribuídos à partição LVM. Os restantes 374 GB estão por atribuir. Não há razão para os deixar assim: lvextend e resize2fs demoram 30 segundos e devolvem esse espaço para overhead do SO, registos e camadas Docker.

Ponderar um segundo NVMe para armazenamento de modelos. O único NVMe de 2 TB guarda atualmente todos os modelos e irá encher à medida que a biblioteca de modelos cresce. Um segundo NVMe de 4 TB em RAID 0, ou simplesmente como um ponto de montagem /mnt/nvme2 separado, acrescentaria flexibilidade e manteria elevado o desempenho de leitura sequencial numa biblioteca total maior.

Comparação: alternativas a esta montagem

A carga de trabalho do cliente poderia ter sido abordada com hardware diferente. Aqui fica uma comparação honesta:

As 4× RTX 4090 com 96 GB são a configuração mínima viável para executar o Llama 3.3 70B AWQ INT4 sob vLLM com débito de lote relevante. Não é o teto; uma montagem de 8 GPU acrescenta capacidade proporcionalmente. Para um cliente de investigação que quer uma única estação de trabalho dedicada — e não um cluster de serviço —, 4× é muitas vezes o ponto de partida certo.

Nem a configuração de 4× nem a de 8× têm NVLink entre GPU, o que significa que a inferência com paralelismo de tensores funciona sobre PCIe. A consequência prática está na latência de TTFT em pedidos individuais, não no débito agregado em lote. Para uma carga de trabalho de dimensão de equipa (dezenas de pedidos por hora, não milhares), isto não é um fator limitativo. Para requisitos de TTFT abaixo de 100 ms, consulte N03 e a fundamentação de por que razão a gama aposta em multi-GPU ligadas por PCIe em vez de sistemas com fabric NVSwitch.

Potência total e planeamento elétrico

Sob carga sustentada de GPU, a potência total do sistema foi de aproximadamente 1,900–2,200 W medidos nos barramentos das GPU (1,914 W no burn só de GPU; ~2,100 W estimados em conjunto com CPU, discos e placa). Conte com as perdas de eficiência da fonte de alimentação (assuma 90%) e planeie no mínimo um circuito de 16 A/230 V, preferindo 20 A para ter margem.

A disposição com fonte de alimentação dupla reparte isto por duas tomadas. Ambas as tomadas têm de estar em circuitos capazes de suportar a carga de forma independente: se a fonte A alimentar duas GPU a 500 W cada mais 200 W de placa/CPU, são 1,200 W no seu circuito. Dimensione em conformidade.

Orçamento de arrefecimento da sala: trate este sistema como 2.5 kW sustentados (valor conservador, que inclui perdas de eficiência e uma margem). Numa sala de servidores ou num armário de rack com vários sistemas, o valor agregado acumula-se rapidamente.

Consulte P01 para considerações sobre monofásico vs trifásico e P04 para o dimensionamento do disjuntor.

Escalão de preço

Uma montagem com esta especificação — plataforma EPYC 7542, 512 GB de RAM ECC, 4× RTX 4090, NVMe de 2 TB, chassis de rack com fonte de alimentação dupla — situa-se na faixa dos €18,000–€24,000 sem IVA aos preços atuais dos componentes, dependendo da escolha do chassis, do momento de aquisição da RAM e da disponibilidade das GPU. O prazo de entrega é de 10–28 dias consoante a disponibilidade dos componentes, confirmado na encomenda.

Esta faixa não inclui instalação, PDU de rack, rede (switch 10 GbE, cablagem) nem qualquer licenciamento de software. O sistema é fornecido com o Ubuntu 24.04 LTS pré-instalado e o venv Python pré-configurado; os pesos do modelo são da responsabilidade do cliente.

Para que esta montagem é indicada

• Inferência LLM para investigação e equipas pequenas. Executar um modelo 70B para uma equipa de 5–15 utilizadores. O agregado de 179 tok/s sob vLLM dá conta das sessões simultâneas com folga.
• Avaliação e iteração de modelos. Os tempos de carregamento rápidos do NVMe tornam rápida a troca entre modelos candidatos. O orçamento de linhas PCIe da plataforma EPYC faz com que as quatro GPU estejam sempre à largura de banda máxima.
• Implementações com soberania de dados. Toda a inferência é local. Nenhum token sai do edifício. Esta é a principal razão não económica para funcionar on-premises em contextos de investigação.
• Porta de entrada para 70B com orçamento contido. A RTX 4090 é a GPU de consumo com mais VRAM disponível. Com 24 GB por placa e quatro placas, os 96 GB totais chegam à classe 70B sem passar para os preços das GPU profissionais.

Para que esta montagem não é indicada

• TTFT abaixo de 100 ms em pedidos individuais. A topologia de paralelismo de tensores sobre PCIe P2P impõe um mínimo ao TTFT em modelos grandes. Se o cliente precisa de latência interativa rápida em modelos 70B+, esta arquitetura é a escolha errada. São precisas GPU ligadas por NVLink, o que significa uma classe de hardware completamente diferente (consulte N03).
• Executar vários modelos grandes em simultâneo. Com 96 GB de VRAM total e gpu_memory_utilization=0.80, restam cerca de 77 GB utilizáveis. Um segundo modelo 70B INT4 não caberia. Para alojar dois modelos em simultâneo, é preciso passar a uma plataforma com mais VRAM por GPU ou com mais GPU.
• Serviço de produção em grande escala. Para centenas de utilizadores simultâneos ou disponibilidade garantida por SLA, esta arquitetura (sem NIC adicionais num chassis de 4 GPU, nó único, GPU de consumo com ECC desativado) não é a base certa. O servidor Kentino AI de 8 GPU com L40 ou RTX Pro 6000 Blackwell, monitorização adequada e NIC duplas, sim.
• Treinar modelos grandes. Com 96 GB de VRAM total é possível fazer fine-tuning (LoRA, QLoRA) em modelos 70B, mas não treiná-los com todos os parâmetros. No treino, o orçamento de VRAM é mais apertado do que na inferência. Se o treino fizer parte do plano de carga de trabalho, tenha-o em conta.

---

Isto faz parte da Kentino Wiki, série C (estudos de caso). Dados da montagem medidos a 2026-04-10. Artigo publicado a 2026-05-15. Correções e medições de seguimento são bem-vindas em info@kentino.com.