"Preciso de um servidor com 8 GPUs." Quando a gente pergunta para quê, a resposta mais comum revela um problema que uma placa resolve — e às vezes uma placa de R$ 3 por hora.
Vale separar os três motivos possíveis, porque eles têm soluções completamente diferentes e só o primeiro exige mesmo várias placas juntas.
Motivo 1 — o modelo não cabe
Este é o caso legítimo e o único que obriga várias GPUs na mesma máquina, com interligação rápida entre elas.
Mas antes de aceitar, faça a conta com quantização. Usando a fórmula de VRAM:
| Modelo | 16 bits | 8 bits | 4 bits | Cabe em uma placa? |
|---|---|---|---|---|
| 8B | 19 GB | 10 GB | 5 GB | Sim, até em 16 GB |
| 32B | 77 GB | 38 GB | 19 GB | Sim em 4 bits, numa de 24 GB |
| 70B | 168 GB | 84 GB | 42 GB | Sim em 4 bits, numa de 48 GB |
| ~120B | 288 GB | 144 GB | 72 GB | Em 4 bits, numa de 80 GB — no limite |
| ~250B ou mais | 600 GB+ | 300 GB+ | 150 GB+ | Não. Aqui sim, várias placas |
Ou seja: até 70 bilhões de parâmetros, uma placa resolve se você aceitar 4 bits — e, na maioria das tarefas, a perda não é mensurável. O pedido de oito placas costuma virar um pedido de uma, mais barata que o servidor inteiro.
Você já testou o modelo quantizado nos seus casos reais? Se a resposta for não, teste primeiro. Uma hora de GPU e trinta casos respondem uma decisão de milhares de reais por mês.
Quando é mesmo necessário
Modelos realmente gigantes só rodam distribuídos, dividindo as camadas entre as placas (tensor parallel). Três coisas para saber:
- A interligação entre as GPUs é o gargalo. Elas trocam dados a cada camada. Placas na mesma máquina com interligação dedicada funcionam bem; placas em máquinas diferentes, via rede comum, não — a latência mata o ganho.
- O número precisa dividir a arquitetura. Use 2, 4 ou 8. Três placas costuma não funcionar, porque o número de cabeças de atenção não divide.
- Vários fornecedores só alugam o nó inteiro nessa faixa de placa. Não existe "meia máquina de 8 GPUs" — a conta é do bloco todo.
vllm serve Org/Modelo-Gigante \
--tensor-parallel-size 8 \
--max-model-len 8192 \
--gpu-memory-utilization 0.92Motivo 2 — o treino demora
Aqui várias placas ajudam, mas a pergunta anterior é: demora quanto, e isso é um problema?
Ajuste com LoRA de um modelo de 8B com mil exemplos leva menos de uma hora numa placa só. Dividir em quatro para terminar em vinte minutos não muda a vida de ninguém e adiciona complexidade real.
Várias placas se justificam em treino quando:
- O treino de uma passada leva mais de 12 horas e você precisa iterar várias vezes.
- O modelo com os estados do otimizador não cabe em uma placa nem com QLoRA.
- Você está treinando de fato, do zero ou com ajuste completo — não adaptando com LoRA.
Quatro placas raramente rendem 4×. Entre 2,8× e 3,5× é o normal, por causa da sincronização de gradientes a cada passo. Em treino pequeno, o custo fixo de coordenação pode comer todo o ganho.
Meça com uma fração do conjunto antes de comprometer o treino inteiro num nó caro.
Motivo 3 — a vazão não dá conta
Este é o caso em que a resposta certa é quase sempre várias máquinas independentes, não várias placas na mesma máquina.
Se o modelo cabe numa GPU e o problema é atender mais gente, você não precisa de paralelismo interno — precisa de mais cópias do mesmo servidor, com um balanceador na frente:
| Abordagem | Custo | Tolerância a falha | Complexidade |
|---|---|---|---|
| 1 máquina com 4 GPUs em paralelo interno | Alto (nó fechado) | Baixa — cai tudo junto | Média |
| 4 máquinas de 1 GPU com balanceador | Menor, e elástico | Alta — cai uma, sobram três | Baixa |
A segunda linha ganha em quase tudo. E permite algo que a primeira não permite: ligar e desligar máquinas conforme a demanda — três no horário comercial, uma de madrugada. Em carga que varia ao longo do dia, isso corta a conta pela metade.
O paralelismo interno só ganha quando o modelo não cabe numa placa. Fora disso, ele é uma forma cara de comprar fragilidade.
A árvore de decisão
- O modelo em 4 bits cabe numa placa disponível? Sim → uma placa. Pare aqui.
- Não cabe, mas um modelo menor resolveria a tarefa? Teste com os seus casos. Muitas vezes resolve — e a diferença de custo é de dez vezes.
- Precisa mesmo do modelo grande? Então várias GPUs no mesmo nó, com potência de 2.
- O problema é vazão, com o modelo cabendo? Várias máquinas de 1 GPU, com balanceador.
- O problema é tempo de treino acima de 12 h? Multi-GPU no mesmo nó, medindo o ganho real antes.
A conta que costuma decidir
Servir um modelo de 70B para uma equipe, oito horas por dia:
| Opção | Configuração | Custo/hora | Mês (176 h) |
|---|---|---|---|
| Quantizado em 4 bits | 1 placa de 48 GB | a partir de R$ 5,87 | ~R$ 1.033 |
| Em 8 bits | 1 placa de 96 GB | a partir de R$ 10,34 | ~R$ 1.820 |
| Em 16 bits | 2 placas de 96 GB | ~R$ 20,68 | ~R$ 3.640 |
Preços de agosto de 2026, para uma GPU avulsa, sem interrupção programada. O catálogo muda: confira a vitrine antes de fechar a conta.
Três vezes e meia de diferença entre a primeira e a última linha, para um modelo que, em 4 bits, a maioria dos usuários não distingue do original. É a decisão de arquitetura com maior impacto financeiro em todo o projeto.
Comece por uma placa e meça
Placas de 24, 48 e 96 GB por hora, cobradas em reais. Suba, teste os seus casos e só então decida o tamanho do compromisso.
Criar conta →Erros comuns
- Pedir 8 GPUs porque o modelo "é grande". Faça a conta de VRAM em 4 bits antes.
- Usar paralelismo interno para ganhar vazão. Mais cópias, não mais divisão.
- Escolher 3 ou 6 placas. Use potências de 2.
- Distribuir por rede comum. Paralelismo interno pede interligação dedicada entre placas do mesmo nó.
- Manter o nó grande ligado 24 horas para uma carga de duas horas por dia. Vale tratar como lote.
Conclusão
A pergunta "quantas GPUs eu preciso?" quase sempre tem a mesma resposta: uma, com o modelo quantizado — e a resposta certa custa dez vezes menos que a intuitiva.
Várias placas no mesmo nó se justificam em dois casos: modelo que não cabe de jeito nenhum e treino longo de verdade. Para vazão, a escala é horizontal — mais máquinas pequenas, que ainda por cima você pode desligar quando a demanda cair.
Continue: quantização e VRAM · dimensionar vazão · trabalho em lote