Servidor de inferência de 576 GB de VRAM: diário de arranque

A maioria dos textos sobre servidores descreve a máquina que foi encomendada. Este descreve a máquina que foi construída — incluindo as duas coisas que estavam mal quando arrancou pela primeira vez, e aquela que nunca explicámos por completo.

Configuração: rack 7U · 2× AMD EPYC 7643 (96C/192T) · 512 GB DDR4 ECC · 6× NVIDIA RTX PRO 6000 Blackwell Max-Q, 576 GB GDDR7 · 2 TB + 4 TB NVMe
Montagem e comissionamento: agosto de 2026, oficina Kentino, Praga · Estado: entregue

Achamos que esse é o artigo mais útil. Copiar uma lista de componentes qualquer um consegue.

O que é

Seis placas RTX PRO 6000 Blackwell Max-Q, 96 GB cada, numa plataforma EPYC Rome de duplo socket com 512 GB de memória ECC. 576 GB de VRAM numa só máquina, o suficiente para alojar um modelo de 753 mil milhões de parâmetros em 4 bits e ainda sobrar espaço para um milhão de tokens de contexto.

A variante Max-Q faz diferença. Com 300 W por placa em vez de 600, seis delas cabem dentro de um envelope térmico e elétrico que uma oficina — e mais tarde uma sala de servidores — consegue realmente suportar. A potência medida à tomada em carga máxima foi de ~2.9 kW, cerca de 80% de um único circuito de 16 A/230 V.

O chassis é um desenho nosso, de 7U: dois blocos de quatro baias de GPU arrefecidos de forma independente, para que nenhuma placa fique na exaustão de mais de três outras.

A primeira falha: duas GPU a funcionar discretamente a meia velocidade

O sistema arrancou, as seis placas foram todas enumeradas e o nvidia-smi parecia impecável.

Duas delas estavam a funcionar em PCIe Gen4 x8 em vez de x16.

Nada reportou qualquer erro. O driver estava satisfeito, as placas funcionavam, a inferência corria. A única forma de detetar isto era medir a largura de banda entre host e dispositivo placa a placa e reparar que duas delas devolviam 13.9 GB/s onde as outras devolviam 27.7.

A causa era uma falha de camada física em dois conectores do chassis — não nas placas, não na motherboard, não no desenho das risers. Ambas as ligações foram passadas para conectores sobresselentes e as seis confirmaram então Gen4 x16 sob carga. Os dois conectores suspeitos ficam registados pelo nome no ficheiro da montagem e permanecem sem uso durante toda a vida da máquina.

Uma GPU que treina com metade da largura de pista não se anuncia. Se o seu processo de comissionamento não medir a largura de banda PCIe por placa sob carga, vai expedir esta falha e nunca saber dela.

A segunda falha: um padrão de ECC que não era a memória

A meio do comissionamento, dois DIMM começaram a registar erros ECC corrigíveis. Corrigíveis significa que o hardware os detetou e corrigiu: sem perda de dados, sem respostas erradas, sem impacto em qualquer resultado. Mas dois módulos a reportar erros são normalmente dois módulos a substituir.

Não os substituímos, e a razão é a parte interessante.

Os eventos estavam espaçados de 4 h 30 m e 4 h 01 m, e cada um deles ocorreu em ambos os módulos dentro do mesmo segundo. Dois módulos de memória marginais e independentes não falham a um intervalo quase fixo, e muito menos falham no mesmo segundo três vezes seguidas. Não é assim que se comporta silício em degradação. É a assinatura de algo externo e periódico.

O intervalo coincidia com uma carga de comutação de elevada potência no ambiente de comissionamento. Corremos então ~20 horas de soak instrumentado sob carga real contínua, com telemetria por minuto em todas as seis GPU, no CPU, na memória, no disco e no registo de eventos do BMC. Zero eventos ECC.

E assim os módulos ficaram.

O que fazemos questão de dizer: nunca correlacionámos os eventos com um ciclo registado da fonte suspeita. A atribuição é inferência, não prova. Reportámos ao cliente a observação, o intervalo e a janela de teste, e dissemos com clareza que não se trata de uma causa raiz provada. Se a causa era ambiental, não viaja com a máquina — e vinte horas de silêncio sob carga são uma boa evidência, não uma garantia.

Uma nota prática que nos custou tempo: esta plataforma usa tratamento de erros pelo firmware em primeiro lugar, por isso os contadores ECC do lado do Linux leem zero, aconteça o que acontecer. A saúde da memória tem de ser lida no registo de eventos do BMC. Se monitorizar o edac e mais nada, está a monitorizar coisa nenhuma.

O que a máquina faz de facto

Todos os valores foram medidos neste sistema em concreto, não retirados de uma ficha técnica.

Computação e consistência

Medição	Resultado
Matmul denso FP16, por placa	291–302 TFLOPS (3.5% de dispersão entre as seis)
Largura de banda de VRAM, por placa	~1,471 GB/s (uniforme até 0.2%)
Inferência com paralelismo de dados em seis vias	3,859 tok/s · 90.8% de eficiência de escalabilidade
Dispersão por réplica entre as seis GPU	0.45%

Essa dispersão de meio por cento entre seis placas é o número que mais nos importa. Significa que nenhuma placa está discretamente a render abaixo do esperado — e só tem significado porque a falha de PCIe acima foi encontrada primeiro.

Inferência de modelos grandes

GLM-5.2 — 753 mil milhões de parâmetros (40 B ativos), 4 bits, 341 GB residentes nas seis placas:

Pedidos em simultâneo	1	4	16	32	48
Geração em tok/s	38.0	78.5	117–120	148.1	172.2

Carrega também o contexto nativo de 1,048,576 tokens do modelo neste hardware — 494 GiB de VRAM, deixando 6.6 GiB livres na placa mais apertada. Funciona, mas é uma margem fina e dissemos isso mesmo.

Afinar o micro-lote de prefill (-b/-ub 4096) fez subir o processamento de prompt de 403 para 606 tok/s, um ganho de 50% com uma alteração de uma linha. A descodificação especulativa acrescentou +53% em fluxo único, mas custou 6% no trabalho em lote com prompts longos, pelo que é ativada por carga de trabalho em vez de globalmente.

Burn-in

810,033 matmuls em seis GPU a 100% de carga. Zero erros de computação. Pico de 88 °C, 300 W sustentados por placa, sem throttling térmico — o clocks_event_reasons indicou Not Active do princípio ao fim.

Onde esta máquina está no limite, e dissemo-lo

A margem térmica é de ~2 °C. Pico de 88 °C contra um ponto de throttling de ~90 °C, com uma temperatura ambiente de 28–33 °C numa oficina sem climatização em agosto. Numa sala abaixo dos 25 °C há folga confortável. Numa sala quente não há. As cargas de trabalho reais e contínuas atingiram as mesmas temperaturas que o burn-in sintético, pelo que esta não é uma preocupação só de testes sintéticos.

A alavanca óbvia é um limite de potência da GPU — 260 W em vez de 300 W. Não medimos quanto é que isso custa em débito nesta máquina, por isso não o recomendámos como se o tivéssemos medido. Teste-o contra a sua própria carga de trabalho.

A pilha de software é específica e frágil. O GLM-5.2 não corre em vLLM nem em SGLang nesta geração de GPU — três limitações distintas a montante. O llama.cpp é o caminho que funciona. À parte disso, a instalação de vLLM traz um patch local que corrige um crash em concorrência com modelos quantizados, e esse patch não sobrevive a um pip install -U vllm. Fixe as versões.

Duplo socket significa NUMA. A largura de banda entre host e dispositivo divide-se por socket: as GPU 0–2 num, 3–5 no outro, com uma penalização de cerca de 20% para buffers de host alocados no nó errado. Não é uma falha — é física — mas tem de fixar os processos com numactl sempre que a largura de banda host↔dispositivo seja importante.

Há um teste genuinamente incompleto. A fase final de carga máxima combinada CPU+GPU foi interrompida por uma avaria do equipamento de distribuição elétrica da oficina. As ~20 horas de testes de resistência em carga mista cobrem o caso real de operação, pelo que reportámos a lacuna em vez de discretamente rebatizar os ensaios de resistência como o teste em falta.

Porque publicamos as falhas

Um relatório de comissionamento que diz que passou tudo não lhe diz nada sobre quem o escreveu. Toda a máquina com esta complexidade tem alguma coisa mal no primeiro arranque. A questão é se isso é encontrado na nossa bancada ou no seu rack.

Nesta montagem foram dois conectores a degradar um quarto do tecido de GPU para metade da velocidade, invisíveis a todos os indicadores de estado do sistema. Foi preciso medir para encontrar e dez minutos para corrigir.

É para isso que serve o comissionamento.