A pergunta mais comum sobre nuvem de GPU é "qual é a mais barata?". É a pergunta errada para quem vai self-hostar um LLM open-weight. A pergunta certa vem antes: qual nuvem consegue, de fato, hospedar o modelo que você escolheu? Um provedor com o melhor preço por hora do mercado é inútil se o nó de 8 GPUs que você precisa está com estoque zero, se a liberação de cota leva duas semanas ou se o contrato mínimo é anual.
Este comparativo olha para capacidade e adequação: VRAM por nó, disponibilidade real, fricção contratual e tempo até a instância subir. O preço entra como fator secundário — se você quer o ranking puro de custo por hora, ele está no nosso comparativo de preços de cloud GPU de 2026, que é leitura complementar a esta.
O modelo define o hardware, e o hardware define o fornecedor. Modelos de até ~700B quantizados cabem num nó de 8 GPUs de 80 GB e podem rodar em praticamente qualquer nuvem especializada. Acima disso, você entra no território de multi-nó com InfiniBand, onde só hyperscalers e algumas neoclouds de escala jogam — e onde a fricção contratual sobe muito.
Passo 1: o modelo escolhido define o hardware
Antes de comparar fornecedor, calcule o que você precisa. A conta é razoavelmente simples e a regra prática funciona bem:
- FP16/BF16: ~2 GB de VRAM por bilhão de parâmetros.
- FP8: ~1 GB por bilhão.
- INT4 / AWQ / GPTQ: ~0,5 GB por bilhão.
- Cache KV e overhead do runtime: some 15% a 30% em cima do total — e bem mais que isso se você quiser servir contexto muito longo para vários usuários simultâneos.
Vale lembrar que quase todos os modelos grandes de 2026 são Mixture-of-Experts: o número de parâmetros ativos por token é pequeno (dezenas de bilhões), mas todos os pesos precisam estar carregados em VRAM. Um MoE de 1T com 32B ativos não é "um modelo de 32B" na hora de dimensionar a máquina — é um modelo de 1T.
| Modelo open-weight | Parâmetros | VRAM aprox. (FP8) | VRAM aprox. (~4 bits) | GPUs de 80 GB |
|---|---|---|---|---|
| Kimi K3 (Moonshot) | 2,8 T (MoE, ~32B ativos) | ~1,4 TB (MXFP4 nativo) | ~650 GB – 1 TB (quant. agressiva) | além de 1 nó |
| Kimi K2 (Moonshot) | ~1 T (MoE) | ~1 TB | ~500–600 GB | 8 (quantizado) |
| GLM-5.2 (Z.ai) | 753 B (MoE, ~40B ativos) | ~750 GB | ~380–450 GB | 6–8 (quantizado) |
| DeepSeek-R1 | 671 B (MoE) | ~670 GB | ~340–400 GB | 5–8 (quantizado) |
| Llama 405B | 405 B (denso) | ~405 GB | ~200–240 GB | 3–6 |
| Qwen3 235B | 235 B (MoE) | ~235 GB | ~120–140 GB | 2–4 |
| Llama 70B | 70 B (denso) | ~70 GB | ~40 GB | 1 |
| Qwen3 32B | 32 B (denso) | ~32 GB | ~18–20 GB | 1 (cabe até em 24–48 GB) |
| Qwen3 8B | 8 B (denso) | ~8 GB | ~5 GB | 1 GPU de entrada |
Números aproximados, para dimensionamento. A qualidade da quantização varia por modelo e por método, e o consumo real de cache KV depende do contexto e da concorrência que você vai servir.
O K3 foi anunciado pela Moonshot AI em 16 de julho de 2026 — 2,8 trilhões de parâmetros, MoE com ~32B ativos por token, 1 milhão de contexto. Os pesos ainda não são públicos (previsão: até 27 de julho). Pelas estimativas divulgadas, os pesos em MXFP4 ocupam cerca de 1,4 TB — mais do que um único nó de 8 GPUs entrega na maioria dos provedores hoje. Assim que os pesos e as primeiras quantizações da comunidade saírem, publicamos aqui um teste real de o que cabe onde.
Passo 2: os critérios que realmente decidem
Definido o alvo de VRAM, os critérios de escolha da nuvem mudam de figura. Preço deixa de ser o primeiro filtro e passa a ser o desempate. O que decide é:
- VRAM máxima por nó. O formato dominante continua sendo o nó de 8 GPUs: 640 GB com H100 de 80 GB, ~1.128 GB com H200 de 141 GB, ~1.536 GB com B200 de 192 GB. Se o seu modelo cabe em um nó, seu universo de fornecedores é enorme. Se não cabe, ele encolhe drasticamente.
- Existe multi-nó de verdade? Juntar duas máquinas por rede comum não resolve: inferência distribuída de modelo grande exige interconexão de baixa latência (InfiniBand ou equivalente) e um cluster montado para isso. Muita nuvem "tem 8× H200" mas não tem cluster.
- Disponibilidade real de estoque. Página de preços não é inventário. O hardware de ponta é o mais anunciado e o mais escasso — vale checar o console antes de planejar o projeto em cima dele.
- Exige contrato ou compromisso? Reserva anual, mínimo mensal, compromisso de gasto, processo comercial. Muda a viabilidade de um experimento de três dias.
- Tempo até a instância subir. De segundos (container em pool quente) a semanas (aprovação de cota corporativa).
- Moeda de cobrança e granularidade. Cobrança em dólar adiciona câmbio e IOF para quem opera no Brasil; cobrança por hora versus mensal muda o custo de um teste que dura uma tarde.
Passo 3: o comparativo por capacidade
Seis opções, avaliadas pelos critérios acima — não por preço. Onde o dado varia por região e por momento, indicamos a ordem de grandeza típica.
| Opção | VRAM máx. por nó | Multi-nó | Contrato | Tempo até subir | Moeda / granularidade |
|---|---|---|---|---|---|
| AWS | 8 GPUs (até classe H200/B200 conforme região) | Sim, clusters grandes | On-demand existe, mas capacidade de ponta costuma passar por reserva/blocos | Minutos a semanas (cota/aprovação) | US$ · por segundo |
| Google Cloud | 8 GPUs (famílias A3/A4) | Sim, clusters grandes | On-demand + filas de agendamento para capacidade escassa | Minutos a dias (fila/cota) | US$ · por segundo |
| Azure | 8 GPUs (séries ND) | Sim, InfiniBand | Cota corporativa; capacidade alta normalmente negociada | Dias a semanas | US$ · por segundo |
| CoreWeave | 8 GPUs por nó, clusters muito grandes | Sim — é o forte da casa | Orientada a reserva/compromisso; processo comercial | Dias (onboarding) e depois rápido | US$ · reserva + on-demand |
| Lambda | 8 GPUs por nó | Sim, clusters de múltiplos nós | On-demand por hora, sem contrato para o básico | Minutos (quando há estoque) | US$ · por hora |
| GPUBrasil | Até 8 GPUs por nó — 640 GB no maior nó com estoque hoje | Não — cada deploy é uma VM | Nenhum — por hora, sem compromisso | Minutos (segundos em containers) | R$ · por hora, via PIX |
Os dados de terceiros são de referência e mudam por região, por família de instância e por momento de mercado — confirme sempre no provedor. Os dados da GPUBrasil são o nosso estado real em 18 de julho de 2026.
Onde cada opção ganha de verdade
Hyperscalers (AWS, Google Cloud, Azure)
Ganham quando a GPU não é o problema principal. Se o seu LLM precisa conversar com um data warehouse gerenciado, viver dentro de uma VPC corporativa auditada, herdar políticas de IAM existentes e aparecer numa fatura que o jurídico já aprovou, o prêmio de preço se paga. Também são a resposta certa quando você precisa de certificação formal de compliance em um processo de auditoria, ou de escala multi-nó com suporte contratual. O custo disso é fricção: cota, aprovação, console complexo e preço por hora que costuma ser o mais alto do mercado.
Neoclouds de escala (CoreWeave, Lambda)
Ganham em disponibilidade de hardware de ponta e preço melhor que o do hyperscaler, com clusters interligados de verdade. Se você vai treinar em 16, 32 ou 64 GPUs interligadas, é aqui — ou no hyperscaler — que a conversa acontece. A contrapartida varia: parte do mercado orienta o produto a reserva e compromisso, o que atrapalha quem quer uma tarde de experimento; e o estoque de topo de linha é disputado.
GPUBrasil
Ganhamos em um recorte específico e bem definido: 1 a 8 GPUs, sem contrato, cobrado em reais.
- Cobrança em reais, sem exposição cambial. Você paga via PIX, o custo é previsível em R$ e não sobe com o dólar no meio do mês — nem carrega IOF e spread de cartão internacional, que não aparecem no "preço em dólar" do concorrente.
- Por hora, sem compromisso. Subiu, testou o modelo, mediu tokens/s, desligou. Nenhum processo comercial no caminho.
- Deploy rápido. A instância sobe em minutos, com acesso root, sem fila de aprovação de cota.
- Instância dedicada só sua. Você controla os pesos, o runtime e os logs. Nenhum prompt sai para a API de um terceiro — o que resolve boa parte dos casos de dado sensível sem depender de contrato de processamento de dados com um fornecedor de LLM.
- Suporte em português, por gente que entende do problema técnico e não só da fatura.
Onde não somos a melhor escolha
Vale ser explícito, porque escolher errado custa caro:
- Treino distribuído em larga escala. Não oferecemos multi-nó com InfiniBand. Cada deploy é uma VM independente. Se o seu job precisa de 32 GPUs falando entre si em um único treinamento, vá para uma neocloud de escala ou um hyperscaler.
- Modelos que não cabem em um nó. Nosso maior nó com estoque hoje entrega 640 GB de VRAM. Um modelo que exige mais do que isso em qualquer quantização viável não roda conosco — e o Kimi K3 completo, pelas estimativas atuais, é exatamente esse caso.
- Compliance com certificação formal exigida em contrato. Se a sua auditoria exige um relatório de certificação específico do provedor, o hyperscaler tem esse papel pronto e nós não.
- GPU em território brasileiro. Nossas GPUs ficam no exterior. Cobramos em reais e somos empresa brasileira, mas isso não é o mesmo que residência de dados no Brasil — se o seu requisito é geográfico e não financeiro, precisa ser dito na proposta. (Temos instâncias CPU em São Paulo, mas isso é outro produto.)
Um teste prático antes de decidir
A forma mais barata de validar a escolha é medir, não estimar. Suba o modelo com vLLM na menor configuração que a tabela indica e veja se ele carrega e responde no throughput que você precisa:
# Sobe um modelo grande quantizado num nó de 8 GPUs e expõe endpoint OpenAI-compatible
vllm serve deepseek-ai/DeepSeek-R1-AWQ \
--tensor-parallel-size 8 \
--max-model-len 65536 \
--gpu-memory-utilization 0.92 \
--port 8000
# Se der OOM no carregamento, o modelo não cabe: reduza --max-model-len,
# baixe a quantização ou troque para um nó com mais VRAM.O erro de OOM no carregamento significa que os pesos não cabem — não adianta ajustar. OOM depois, sob carga, significa que os pesos cabem mas o cache KV não: aí dá para reduzir contexto ou concorrência e seguir.
Teste o modelo antes de decidir a infraestrutura
GLM-5.2, Kimi K2, DeepSeek-R1, Qwen3 e Llama rodam hoje, por hora e em reais, com acesso root e sem contrato. O K3 mostrou que o open-weight chegou na fronteira — e o que dá para self-hostar agora já resolve a maior parte dos casos.
Ver GPUs disponíveis →Recomendação por perfil
| Perfil | O que pesa | Recomendação |
|---|---|---|
| Pesquisador / acadêmico | Orçamento apertado, uso intermitente, 1–8 GPUs, quer começar hoje | Nuvem por hora sem contrato. GPUBrasil se você paga em reais; Lambda se você já opera em dólar. |
| Startup servindo um modelo | Custo previsível, deploy rápido, endpoint estável, 1–8 GPUs | Nuvem especializada por hora. Se o faturamento é em R$, cobrar em R$ elimina o descasamento de moeda entre receita e custo. |
| Empresa com compliance pesado | Auditoria formal, VPC corporativa, contratos, integração com o stack existente | Hyperscaler (AWS, Google Cloud, Azure), aceitando o prêmio de preço. Instância dedicada em nuvem especializada resolve o caso de "o dado não vai para API de terceiro", mas não substitui certificação exigida em contrato. |
| Treino em larga escala | Dezenas de GPUs interligadas, InfiniBand, semanas de job | CoreWeave ou hyperscaler, com reserva. Não é caso de nuvem por hora de nó único — inclusive não é caso nosso. |
Perguntas frequentes
Quantas GPUs eu preciso para rodar um LLM open-weight grande?
Depende dos parâmetros e da precisão. Regra prática: em FP8, ~1 GB de VRAM por bilhão de parâmetros; em INT4/AWQ, ~0,5 GB por bilhão — e some 15% a 30% para o cache KV. Assim, DeepSeek-R1 (671B) e GLM-5.2 (753B) cabem em 8 GPUs de 80 GB quantizados em 4 bits, enquanto um Qwen3 de 32B roda em uma única GPU de 48 GB.
Qual é o limite de VRAM de um único nó de GPU em 2026?
O formato dominante é o nó de 8 GPUs: 640 GB com H100 de 80 GB, ~1.128 GB com H200 de 141 GB e ~1.536 GB com B200 de 192 GB. Acima disso é preciso juntar nós com InfiniBand ou equivalente — o que muda o tipo de fornecedor que você precisa contratar.
Dá para rodar o Kimi K3 em uma nuvem de GPU hoje?
Ainda não dá para avaliar na prática: os pesos não são públicos até 18 de julho de 2026 e devem sair até 27 de julho. Pelas estimativas divulgadas, os pesos em MXFP4 ocupam cerca de 1,4 TB — mais do que um único nó de 8 GPUs entrega hoje na maioria dos provedores. Rodar o modelo completo vai exigir quantização agressiva da comunidade ou uma configuração multi-nó. Vamos publicar o teste real assim que os pesos e as primeiras quantizações aparecerem.
Quando vale mais a pena usar um hyperscaler em vez de uma nuvem especializada?
Quando o gargalo não é a GPU e sim o entorno: integração com serviços gerenciados, isolamento de rede corporativo, certificações formais de compliance, cláusulas contratuais específicas ou treinos com dezenas de nós interligados. Para subir um modelo open-weight em 1 a 8 GPUs e servir um endpoint, o custo e a fricção do hyperscaler raramente se justificam.
Conclusão
Escolher nuvem de GPU pelo preço por hora é começar pela última pergunta. Comece pela primeira: quanto de VRAM o meu modelo exige, e quem consegue entregar isso quando eu precisar? Se o seu alvo cabe em um nó — e a maior parte do que é útil hoje cabe, incluindo GLM-5.2, DeepSeek-R1, Qwen3 e Llama quantizados —, o mercado é amplo e o desempate fica com moeda, contrato e velocidade de deploy. Se não cabe, o comparativo relevante é outro: multi-nó, InfiniBand e reserva de capacidade, com uma lista bem mais curta de fornecedores.
Nós somos a resposta certa para o primeiro caso e a errada para o segundo. Dizer isso claramente economiza o tempo de todo mundo.
Leia também: Comparativo de preços de cloud GPU 2026 · Quando o self-hosting compensa · Como escolher a GPU certa