Multi-GPU num só nó vs. múltiplos nós: quando escalar horizontalmente

O erro mais caro na fase de compra é repartir um orçamento de GPU por dois nós quando um nó maior teria resolvido o problema. O segundo mais caro é ficar por um único nó quando a carga de trabalho precisa mesmo de fabric e depois passar seis meses a fingir que a máquina está a aguentar.

Este artigo é a lógica de decisão para essa escolha: quando uma única máquina de 8 GPU é a resposta certa, quando não é, e como perceber de que lado da linha está a sua carga de trabalho. Os artigos complementares cobrem a mecânica (K02 treino, K03 inferência, K07 limites do PCIe, K06 gestão de falhas); este é a decisão de quem compra.

O limite dos 8 GPU, por modelo

A primeira questão é saber se o modelo cabe num só nó. Com 8× RTX Pro 6000 Blackwell (96 GB cada) obtém 768 GB de VRAM utilizável; com 8× RTX 5090 (32 GB cada) obtém 256 GB. Nenhum é pouco para os padrões de 2026, nenhum chega para tudo.

O precipício está na linha dos 405B / 671B. Abaixo dela, uma máquina de 8 GPU Pro 6000 chega. A partir daí, ou está a quantizar agressivamente (pesos INT4 — bons para inferência, péssimos para treino) ou está a atravessar a fronteira de um nó.

"Cabe" não é o mesmo que "corre bem". Um modelo que ocupa 95% da VRAM sem margem para a cache KV, a cache de prefixos, os CUDA graphs ou a memória de ativações vai preterir pedidos sob qualquer carga real. A regra prática: pesos a 60–70% da VRAM, deixando 30–40% para todo o resto. Com essa restrição, 405B em FP8 não cabe com folga em 8× Pro 6000 para inferência com qualquer concorrência útil — cabem os pesos, não a carga de trabalho.

Quando NÃO deve escalar horizontalmente

Casos em que ficar por um único nó é inequivocamente correto:

• Inferência para qualquer modelo que caiba. Se o modelo mais o KV couberem na concorrência pretendida, o TP multinó sobre Ethernet ou IB é sempre mais lento do que um único nó. O PCIe Gen5 dentro de uma máquina entrega ~50 GB/s entre GPU no mesmo switch; 200 Gbps de IB entre nós entregam ~25 GB/s. Uma carga de trabalho que já coxeia em PCIe arrasta-se em IB.
• Produção com um único inquilino. Um modelo, um cliente, concorrência moderada. Uma máquina de 8 GPU Pro 6000 aguenta 70B com 32–64 pedidos em simultâneo sem dificuldade. Uma segunda máquina só serve como reserva quente ou para duplicar o débito em DP — nenhuma das duas coisas é "escalar horizontalmente" no sentido fortemente acoplado.
• Laboratórios de investigação com modelos de 7B–72B. A maior parte do trabalho académico e aplicado em 2026 está aqui — Llama 3.x 8B, Qwen 7B/14B/32B, Mistral, Gemma, a cauda de fine-tunes de 70B. Nenhum precisa de mais do que um nó.
• Fine-tuning LoRA / QLoRA. O propósito do PEFT é precisamente não precisar dos recursos de um treino de modelo completo. Um LoRA de 70B cabe em 4–8 GPU num só nó; um QLoRA de 405B cabe em 8× Pro 6000.
• Inferência em lote e cargas offline. Se o SLA é "processar este corpus até sexta-feira", o batching em modo de débito numa máquina de 8 GPU resolve. O multinó só ajuda quando não consegue terminar a tempo — normalmente porque o modelo é demasiado grande, não porque um nó é demasiado lento.

Cerca de 80% dos clientes da Kentino deveriam comprar um nó maior em vez de dois mais pequenos, e a maioria dos restantes 20% quer na verdade réplicas DP atrás de um balanceador de carga, não um cluster.

Quando TEM mesmo de escalar horizontalmente

Os casos em que um nó realmente não chega são mais estreitos do que se julga.

Treinar um modelo de 70B+ de raiz. Oito GPU não dão tempo de relógio suficiente. Um pré-treino de 70B com os orçamentos de tokens publicados (1.5–15T) leva centenas de meses-GPU em hardware da classe H100, mais ainda em GPU de consumo ligados por PCIe. Este trabalho exige 32–128+ GPU e um fabric SXM. A Kentino não constrói este escalão.

Fine-tuning de posto completo de 70B+. Não LoRA — fine-tuning completo com os estados do otimizador, gradientes e ativações residentes. Um fine-tune completo de 70B (pesos FP16 + Adam FP32 + gradientes + ativações) são 1.2–1.5 TB de estado, acima do que um nó de 8 GPU aguenta mesmo com FSDP. Justifica um cluster IB de 2–4 nós.

Alojar 405B+ com latência de produção. Os pesos cabem em INT4 em 8× Pro 6000, mas a cache KV mais o serviço concorrente com latência utilizável empurram-no para dois ou mais nós. Duas máquinas de 8 GPU Pro 6000 em TP=8 × PP=2 ou TP=4 × PP=4 é o mínimo realista para o Llama 3.1 405B com um QPS decente. K03 detalha isto.

Produção multi-inquilino a >100k QPS agregados. Um nó de 8 GPU serve 500–2,000 tok/s agregados em 70B FP8. Acima de dezenas de milhares de QPS vai querer várias réplicas e, acima disso, um cluster a sério com um router e encaminhamento sensível à cache de prefixos. A resposta certa é normalmente muitas réplicas DP, não um cluster TP gigante.

Fora destes quatro, o argumento enfraquece depressa. A maioria dos "preciso de multinó" acaba por ser "quero mais débito" — uma questão de réplicas, não de fabric.

O ponto ideal de um único nó

A geometria de uma boa configuração de nó único, com hardware que a Kentino realmente expede:

A restrição decisiva: estas placas não têm NVLink. As RTX 5090, RTX Pro 6000 Blackwell, L40 e L4 ligam-se por PCIe. Os módulos SXM com fabric NVLink (H100 SXM, B200 SXM, GB200) exigem baseboards HGX que não construímos. K07 trata do custo; N03 trata de quando o NVLink importa.

O caminho PCIe é o certo para trabalho centrado em inferência e para a maior parte do treino aquém da fronteira. O batching em modo de débito amortiza o custo do all-reduce na inferência. No fine-tuning de modelos de tamanho fixo, a penalização em tempo de relógio face ao SXM é de 1.2–1.4× — normalmente aceitável. No treino tensor-paralelo de 70B+ de raiz a penalização é de 2–3×, e a resposta é "compre SXM ou não faça este trabalho em hardware Kentino".

O precipício entre nó único e multinó

O que faz do multinó uma categoria de sistema diferente é o precipício de interligação entre o interior do nó e a ligação entre nós, em largura de banda e em latência.

Dentro de uma máquina, dois GPU comunicam a ~50 GB/s com saltos abaixo do microssegundo. Entre nós, obtém ~25 GB/s em IB de 200 Gbps — uma penalização de 2× em IB, 4–5× em 100 GbE, 15× em 25 GbE. Para os coletivos TP que disparam em cada camada do transformer, isso dói a sério. K07 tem a tabela de tempos do all-reduce.

A latência multiplica o efeito: entre nós são 5–15 microssegundos em RoCE afinado, contra nanossegundos dentro da máquina. Para treino e prefill isso desaparece no arredondamento; para inferência interativa de baixa latência com TP apertado, não.

É por causa deste precipício que "basta acrescentar outra máquina" não é uma decisão contínua. Tudo o que mal sobrevive em PCIe dentro de um nó não sobreviverá em Ethernet ou IB entre nós.

A matemática do strong scaling: onde é que desaba

A lei de Amdahl: o ganho de velocidade está limitado pela fração série da carga de trabalho e, no treino distribuído, essa fração é o overhead de comunicação. Para um passo de treino da classe 70B em hardware PCIe da classe Kentino, a eficiência de escalamento (débito por GPU face à linha de base de um único GPU) é esta nas configurações que já expedimos:

Duas conclusões. Primeira: dividir um trabalho de 8 GPU por dois nós de 4 GPU é pior do que corrê-lo numa única máquina — qualquer fabric entre nós é mais lento do que o PCIe dentro da máquina que já tinha. Segunda: o paralelismo de dados escala muito melhor do que o paralelismo tensorial através de fabric. Se a sua pergunta real é "consigo servir mais pedidos" e não "consigo correr um modelo maior mais depressa", as réplicas DP funcionam — e funcionam sobre 100 GbE comum.

Se a eficiência projetada cair abaixo de 60%, a carga de trabalho tem a forma errada para multinó sobre fabric comum. Reformule a arquitetura (TP dentro do nó, PP ou DP entre nós), compre um nó único maior ou compre hardware da classe SXM. A força bruta não resulta.

A armadilha do laboratório de investigação e o imposto operacional

Um padrão que vemos com frequência suficiente para o assinalar: um laboratório planeia para "o futuro" e encomenda dois nós de 4 GPU em vez de um nó de 8 GPU. O que obtém, na prática, é pior treino (0.65× em TP entre nós contra 0.73× dentro do nó), pior inferência para qualquer modelo que coubesse numa máquina, o dobro da carga operacional (dois BMC, duas afinações de NIC, dois estados fixos de controlador, dois domínios de falha) e um custo de componentes praticamente igual depois da segunda NIC, da segunda fonte de alimentação e da atualização do switch. Compre primeiro um nó de 8 GPU.

O multinó, quando é a resposta certa, não é gratuito. O imposto adicional:

• Armazenamento partilhado — o NVMe local deixa de chegar. NFS, BeeGFS ou Lustre, mais uma VLAN de armazenamento (K04).
• Checkpoints assíncronos e fragmentados — escritas síncronas não fragmentadas para NFS bloqueiam o cluster. O PyTorch DCP ou o NeMo é obrigatório, não opcional.
• Afinação de NIC e NCCL — controlo de fluxo RoCE, PFC, ECN, jumbo frames, escolha do transporte NCCL, ficheiros de topologia, algoritmos em anel ou em árvore. Todos os parâmetros virão errados de origem.
• Monitorização — DCGM por nó, federação de Prometheus, buffers de trace do NCCL.
• Gestão de falhas — nós que se desligam, NIC que reiniciam, portas de switch instáveis. K06 cobre os modos; as taxas de falha em multinó são cerca de N vezes as de um nó único e a recuperação é mais complicada.

Em tempo de engenharia, o multinó custa 4–5× por cada nó acrescentado. Planeie-o, ou aceite que o cluster passe os primeiros seis meses a metade da capacidade teórica.

O fluxo de decisão concreto

Percorra isto por ordem. O primeiro "sim" termina a conversa.

1. O modelo cabe em 8× 96 GB em FP8 com 30–40% de margem de VRAM para o KV? Se sim, um nó, está feito.
2. Cabe em INT4 com a mesma margem? Se sim e se estiver a fazer inferência (não treino), um nó em INT4 é a resposta. Os pesos INT4 não são viáveis para o caminho dos gradientes no treino — continue.
3. A carga de trabalho está limitada pelo débito e não pelo tamanho do modelo? Se sim, a resposta são réplicas em paralelismo de dados de configurações de um nó, não um cluster. Duas máquinas atrás de um balanceador de carga, sem necessidade de fabric.
4. A carga de trabalho é treino tensor-paralelo de um modelo que não cabe num só nó? Multinó com InfiniBand. Projete a eficiência de escalamento com a tabela de K07. Abaixo de 60%, reformule a arquitetura (TP dentro, PP entre nós) ou reduza o número de nós e aceite um tempo de relógio mais lento.
5. A carga de trabalho é o pré-treino de um modelo de 70B+ de raiz? Caso de fronteira. Multinó com IB NDR ou SXM. A Kentino consegue construir o lado IB, mas a maioria dos clientes que faz esta pergunta não precisa, na verdade, de fazer este trabalho por si própria.

Os passos um e dois são o grosso do mercado. O passo três significa que está a crescer bem — a resposta são réplicas, não um cluster. Os passos quatro e cinco são reais, mas raros.

Opinião honesta

O multinó é a escolha certa na fronteira — treino de 70B+ de raiz, inferência de 405B+ com latência de produção, serviço à escala hyperscale acima de 100k QPS, ou investigação que dependa de um débito diário que uma só máquina não consegue entregar. São cargas de trabalho reais. Não são a maior parte do que se constrói.

Para tudo o resto, um nó de 8 GPU bem especificado é a resposta. Corre todas as cargas de inferência de pesos abertos de 2026 que caibam em 768 GB em FP8/INT4, LoRA e QLoRA até 405B, fine-tunes completos da classe 13B sem queixas, e escala para duas ou três réplicas DP em débito sem qualquer fabric de cluster. E é dramaticamente mais simples de operar.

A forma da conversa que temos com a maioria dos clientes: descrever a carga de trabalho, fazer as contas de ajuste, projetar a eficiência de escalamento. Se a projeção der um cluster, construímos um cluster. Se der um nó, construímos um nó. Se der duas réplicas atrás de um router, construímos isso. Não vendemos a maior configuração que o cliente tolere — vendemos aquela que vai realmente funcionar.

---

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