GPU cloud: 7 provedores para treinar e rodar IA em 2026

Escolha seu provedor de GPU cloud de acordo com o trabalho: Runpod para fazer fine-tuning com controle direto do ambiente, Modal para inferência serverless com código próprio, Together AI para acessar modelos por uma API gerenciada e Vast.ai para alugar máquinas em um marketplace e executar tarefas que podem ser retomadas. A seleção de 7 provedores também inclui Lambda para máquinas virtuais com GPU, CoreWeave para capacidade planejada em clusters e Google Cloud quando a aplicação já depende dessa infraestrutura. Comece pela memória que o modelo exige e pelo tempo de execução cobrado, antes de olhar a menor tarifa anunciada.

Preços e documentação dos produtos verificados em 30 de outubro de 2026. Os valores abaixo estão em USD e correspondem aos preços exibidos nas páginas dos próprios fornecedores naquela data. A comparação se baseia na documentação, sem testes práticos de desempenho. Disponibilidade, impostos e a configuração final da implantação podem alterar o valor pago.

Qual provedor de GPU cloud escolher para cada tipo de trabalho?

Runpod é a primeira opção a avaliar para quem quer fazer fine-tuning diretamente no ambiente; Modal e Together AI são os primeiros candidatos para disponibilizar o modelo sem manter uma máquina com GPU ligada o tempo todo. Essa escolha muda quando você precisa de uma região específica, capacidade contínua ou um ambiente de processamento em lote que facilite a recuperação de tarefas.

Comparativo de preços de GPU na nuvem: confira a unidade de cobrança

Cada preço inicial identifica o produto e o hardware correspondente. São portas de entrada para serviços diferentes, com desempenhos que não se equivalem necessariamente. O preço de uma GPU acoplada à máquina não inclui a máquina virtual hospedeira; a tarifa de GPU por segundo em serverless não inclui recursos cobrados à parte; e o preço de inferência dedicada não é o preço de uma API por tokens.

Uma oferta de marketplace pode deixar de existir, e a placa mais barata da lista talvez não tenha memória suficiente para seu modelo. A coluna de teste grátis descreve a oferta pública verificada, sem abranger todos os programas de créditos negociados. Together AI exige pagamento antecipado; a restrição do Google ao uso de GPUs aparece expressamente nos termos do Free Trial.

Inferência serverless: código próprio ou API de modelos?

Antes de escolher a GPU, decida se precisa controlar o ambiente de execução do modelo. Inferência é usar um modelo treinado para produzir uma resposta. Uma API gerenciada permite solicitar essa resposta; um ambiente serverless programável permite fornecer o código que a produz. Essa diferença pesa mais do que o uso da palavra “serverless” pelos dois produtos.

1. Modal: inferência em Python com código próprio e tráfego variável

Modal é uma plataforma de computação serverless para aplicações em contêineres implantadas por meio de Python. É uma boa opção quando o código que disponibiliza o modelo faz parte do produto. Um serviço de processamento de documentos, por exemplo, pode precisar reunir pré-processamento próprio, uma chamada ao modelo e pós-processamento na mesma implantação. Modal ajusta a capacidade à demanda, mas o período cobrado inclui a inicialização e o tempo ocioso em que o ambiente fica pronto para responder, além do cálculo útil do modelo. Escolha Modal quando quiser controlar o ambiente de execução sem manter uma VM permanentemente ligada.

Indicado para: Equipes que usam Python para implantar inferência personalizada ou tarefas em fila com GPU e demanda variável.
Diferencial: Implantação no nível da aplicação e escalabilidade automática, com medição separada dos recursos de computação.
Preço: Computação com GPU T4 a partir de $0.000164/segundo, mais CPU e memória, conforme verificado em 30 de outubro de 2026 na página de preços do Modal.
Teste grátis: O plano Starter inclui $30/mês em créditos de computação; os Shared Endpoints cobrados por tokens ficam fora dessa franquia.

O principal obstáculo prático é a latência após um período sem uso. O cold start é o trabalho necessário para preparar um novo contêiner antes que ele possa responder. Iniciar o contêiner, importar bibliotecas e carregar os pesos do modelo são etapas distintas. Um contêiner que inicia rapidamente não garante que o modelo esteja pronto no mesmo instante.

Modal oferece controles para manter contêineres prontos e capacidade de reserva. Eles podem melhorar o tempo de resposta, mas também mantêm recursos alocados. Em um assistente voltado ao cliente, teste tanto a primeira requisição após um período de inatividade quanto as requisições durante uma sessão movimentada. Em uma fila de extração executada durante a madrugada, esperar pela inicialização pode ser aceitável. O guia de cold start do Modal explica essa relação entre custo e latência.

O plano Starter também tem limites claros de escala: 3 usuários no workspace e 10 GPUs simultâneas. Isso permite um piloto útil, mas um pico de workers independentes pode atingir o limite de simultaneidade antes de o gasto mensal parecer alto. Volumes persistentes e tráfego de saída têm franquias incluídas e cobrança adicional após esses limites; por isso, considere também o caminho dos dados na estimativa.

A localização exige outra decisão de configuração. Modal distingue a região que executa o contêiner da região que roteia as requisições. Fixar uma região também aplica um multiplicador ao preço. Executar o modelo perto do banco de dados só resolve o problema se o caminho das requisições também atender às exigências de latência e residência dos dados. A documentação de seleção de região descreve os dois controles.

2. Together AI: quando você precisa de um endpoint de modelo

Together AI é uma plataforma gerenciada de inferência e treinamento para equipes que querem lançar uma funcionalidade baseada em modelos antes de assumir a infraestrutura de GPU. A API serverless é o ponto de partida natural quando o modelo necessário está no catálogo; a inferência dedicada acrescenta controle sobre o hardware que atende às requisições. O limite está na personalização: acessar um modelo compatível por API é diferente de executar qualquer ambiente de treinamento escolhido por você. Escolha Together AI quando o endpoint atender à necessidade do produto e contrate capacidade dedicada quando o tráfego ou as exigências de controle justificarem.

Indicado para: Equipes que disponibilizam modelos compatíveis ou usam fine-tuning gerenciado e inferência dedicada.
Diferencial: Permite começar com uma API cobrada por tokens e avançar para inferência dedicada.
Preço: Inferência dedicada com NVIDIA HGX H100 a partir de $5.49/GPU-hora; as tarifas da API serverless dependem do modelo, conforme verificado em 30 de outubro de 2026 na página de preços do Together AI.
Teste grátis: Não há teste grátis; é obrigatório comprar créditos pré-pagos.

Separe os modelos de cobrança. A inferência serverless de linguagem cobra pelos tokens de entrada e saída, os fragmentos de texto processados pelo modelo. A inferência dedicada cobra por minuto para cada réplica pronta, ou seja, uma cópia em execução do serviço que atende o modelo. Segundo a documentação, o provisionamento e o cold start ficam fora da cobrança de computação dedicada, mas uma réplica pronta continua gerando custo mesmo quando recebe poucas requisições. Reduzir a escala a zero interrompe essa cobrança de computação. A documentação de cobrança da inferência dedicada define esse limite.

Em uma aplicação de suporte com conversas esporádicas, serverless evita a contratação de capacidade ociosa para o modelo. Em uma aplicação movimentada, com um padrão de tráfego conhecido, vale comparar réplicas dedicadas usando os mesmos prompts e comprimentos de resposta. Não migre apenas porque a tarifa por GPU parece menor: é preciso medir a vazão para convertê-la em custo por resposta concluída.

O fine-tuning gerenciado também precisa de uma estimativa própria. Together oferece LoRA baseado em adaptadores e fine-tuning completo, com cobrança por tokens que considera as passagens de treinamento e a avaliação. Uma época é uma passagem pelo conjunto de dados de treinamento. Repetir o conjunto aumenta o volume de tokens processados; o tamanho do arquivo enviado, sozinho, não determina a conta.

O produto de clusters de GPU é outra oferta distinta. Há capacidade sob demanda e reservada, com armazenamento persistente cobrado separadamente. As reservas de clusters são pré-pagas e não reembolsáveis; excluir um cluster não torna automaticamente gratuitos todos os volumes mantidos. A documentação de clusters informa que não há cobrança por tráfego de entrada ou saída. Não presuma que essas regras se apliquem a todos os produtos de API. Os detalhes estão na documentação de cobrança de clusters.

Para disponibilizar um modelo, verifique modelo e região em conjunto. Alguns modelos serverless permitem inferência restrita aos Estados Unidos; outras exigências regionais apontam para endpoints dedicados. O tempo de resposta da API compartilhada pode variar com a demanda, e a aplicação continua precisando tratar novas tentativas. A documentação serverless explicita esses limites.

Pods e VMs sob demanda para fine-tuning

Alugue um ambiente sob seu controle enquanto ainda estiver alterando o script de treinamento, as dependências ou o modelo. Fine-tuning é adaptar um modelo existente com seus dados. Um Pod ou uma máquina virtual permite investigar falhas e executar a tarefa novamente; também deixa com você a responsabilidade de encerrar a computação e preservar os resultados.

3. Runpod: por onde começar para fazer fine-tuning na prática

Runpod oferece Pods com GPU dedicada, além de produtos Serverless e de clusters. É um candidato inicial prático para uma equipe pequena que está desenvolvendo seu próprio fluxo de trabalho com modelos. Você pode escolher uma GPU e um template de contêiner, realizar o fine-tuning e depois avaliar uma implantação Serverless separada para inferência. Os limites são concretos: a confiabilidade do Community Cloud varia conforme o host, o armazenamento persistente tem um ciclo de vida próprio e parar um Pod não garante que a mesma GPU estará disponível na retomada. Runpod entra na seleção pelo controle e pela flexibilidade de implantação, sem prometer o menor custo para toda carga de trabalho.

Indicado para: Quem precisa de um contêiner com GPU para experimentos, fine-tuning com adaptadores e desenvolvimento de inferência personalizada.
Diferencial: Produtos Pod e Serverless separados para as etapas de desenvolvimento e disponibilização do modelo.
Preço: A página consultada lista Pods com RTX A5000 e 24 GB de VRAM a partir de $0.27/hora, conforme verificado em 30 de outubro de 2026 na página de preços do Runpod.
Teste grátis: A página de preços consultada não informava teste gratuito de GPU.

Comece pela memória, antes de se deixar levar pelo nome da GPU. Runpod lista placas de 24 GB, opções de 48 GB como A40 e RTX A6000 e variantes A100 e H100 de 80 GB. Isso dá a uma equipe pequena várias faixas de memória para avaliar sem precisar projetar um cluster logo de início. A lista não estabelece um ranking de vazão: o motor de inferência, a precisão do modelo e a configuração dos lotes podem mudar qual placa vale mais a pena.

Secure Cloud e Community Cloud também exigem escolhas diferentes. Runpod descreve Secure Cloud como infraestrutura de data centers e Community Cloud como oferta peer-to-peer com confiabilidade variável. Um experimento que pode ser refeito tolera falhas diferentes das aceitáveis em um serviço que atende clientes. Escolha o conjunto de recursos conforme as exigências de recuperação e suporte da tarefa. O guia de seleção de Pods do Runpod explica a distinção.

O armazenamento é o ponto com maior chance de surpreender na primeira implantação. O disco do contêiner é temporário. O disco de volume preserva os dados quando o Pod é parado, mas não quando ele é excluído. Um volume de rede persiste de forma independente, porém está disponível para Pods no Secure Cloud e vincula a escolha de hardware à sua localização. Guardar checkpoints apenas em armazenamento temporário anula a utilidade de salvá-los. A documentação de volumes de rede explica essa restrição de localização.

Pods cobram computação por segundo e, segundo as regras de preços verificadas, não cobram taxas de tráfego de entrada ou saída. O armazenamento de um Pod parado pode continuar gerando cobranças. Serverless tem outro ciclo de vida: os workers são cobrados durante a inicialização, a execução e a espera ociosa, até serem parados. Workers Flex podem reduzir a escala a zero; workers Active permanecem em execução. Essas escolhas definem por quanto tempo você paga para manter recursos alocados, além de mudar o nome da tarifa. Consulte a cobrança de Pods e a cobrança de Serverless.

Para consultar o quadro completo de tarifas e armazenamento, use o guia de preços do Runpod do site. Ele ajuda a estimar execuções recorrentes e inferência mantida no ar continuamente.

1. 1

   Defina a tarefa antes da implantação

   Anote o checkpoint exato do modelo, o modo de inferência ou fine-tuning, a precisão, o comprimento máximo da entrada e a simultaneidade esperada. Escolha uma faixa de memória de GPU com espaço para o ambiente de execução, além do arquivo do modelo.

2. 2

   Escolha primeiro onde os dados ficarão

   Se a tarefa precisar de um volume de rede, crie ou selecione esse volume no data center desejado antes de escolher a GPU. Confirme a disponibilidade de GPUs adequadas naquele local. Mantenha uma cópia separada dos dados de treinamento e checkpoints que não podem ser perdidos.

3. 3

   Implante um template compatível

   Em Pods, selecione a GPU, escolha o template de contêiner, defina a quantidade de GPUs e faça a implantação sob demanda. Confira a compatibilidade do template com o filtro de CUDA do host. CUDA é a plataforma de software da qual dependem muitas aplicações para GPUs NVIDIA.

4. 4

   Faça um teste pequeno e confira o encerramento

   Percorra o mesmo fluxo de carregamento, treinamento e gravação de checkpoints previsto para a tarefa real. Registre o pico de memória da GPU e o tempo decorrido. Antes de parar ou encerrar a computação, confirme que o checkpoint existe no armazenamento persistente; depois, verifique as cobranças de armazenamento que permanecem.

Esses controles de implantação estão documentados em Gerenciar Pods. Use esse ensaio também para testar a recuperação: a próxima execução deve conseguir continuar sem depender de uma máquina específica usada anteriormente.

4. Lambda: para quem prefere uma máquina virtual com GPU

Lambda é uma nuvem de GPUs com máquinas virtuais Linux e ofertas de clusters reservados. Atende equipes que querem uma máquina convencional para uma sessão prolongada de treinamento. Os ambientes incluem ferramentas NVIDIA, e o catálogo vai de configurações com uma GPU a alocações maiores. O ponto de atenção na contratação é o tamanho da alocação: a mesma GPU pode ter uma tarifa unitária diferente conforme a quantidade alugada. Escolha Lambda para ter controle sobre o ambiente de treinamento e confira o seletor de quantidade de GPUs antes de tratar uma tarifa como o total da conta.

Indicado para: Equipes de treinamento e fine-tuning que preferem acesso SSH a uma VM com GPU.
Diferencial: Instâncias com uma GPU e uma oferta separada de clusters reservados.
Preço: As Single-GPU Instances começam em $0.69/GPU-hora para uma Quadro RTX 6000 com 24 GB de VRAM, conforme verificado em 30 de outubro de 2026 na página de preços do Lambda.
Teste grátis: A página de preços consultada não informava teste gratuito de GPU.

O catálogo inclui A6000 com 48 GB e variantes H100 PCIe e SXM com 80 GB. Os nomes fazem diferença. “RTX 6000”, “A6000” e placas mais novas com nomes parecidos não são compras equivalentes. Registre o nome completo e a memória da GPU nas anotações de implantação para evitar que uma execução futura use outro dispositivo sem que você perceba.

A computação sob demanda do Lambda tem preço anunciado por hora, mas a cobrança ocorre em incrementos de um minuto, desde a inicialização bem-sucedida da instância até seu encerramento. Uma máquina ligada, mesmo sem executar trabalho, continua sendo cobrada. Em um treinamento, organize o desligamento de acordo com o ciclo de encerramento do provedor: terminar o processo Python não significa encerrar o aluguel. A documentação de cobrança do Lambda descreve a medição.

Sistemas de arquivos persistentes exigem mais uma etapa de planejamento: precisam ser anexados durante a criação da instância e ficar na mesma região dela. A cobrança continua enquanto existirem, mesmo desmontados; segundo a documentação, não há cobrança de tráfego de entrada e saída desses sistemas de arquivos. Antes de preparar um conjunto de dados grande, confirme que a GPU e o sistema de arquivos podem coexistir na localização desejada. A documentação de instâncias do Lambda apresenta as regras de região e armazenamento.

A opção de cluster reservado representa outra escala de contratação. A tabela pública de 1-Click Cluster começa em 16 GPUs e um prazo de duas semanas. Isso pode atender a uma campanha concentrada de treinamento, mas é um ponto de partida ruim para quem ainda está descobrindo se uma adaptação em uma única GPU resolve o problema. Comece pelo menor experimento viável e amplie somente depois de estabelecer a vazão necessária.

GPUs em marketplaces e instâncias interrompíveis

Só aceite o risco de interrupção depois de comprovar que a tarefa consegue se recuperar. Um marketplace reúne ofertas de diferentes hosts. Uma instância interrompível pode ser pausada ou ter seus recursos retomados pelo provedor. Os conceitos se cruzam, mas um aluguel sob demanda em marketplace não é automaticamente interrompível.

5. Vast.ai: tarefas que podem ser retomadas, com flexibilidade de localização

Vast.ai é um marketplace de GPUs em que os hosts definem os preços. É útil para quem pode examinar cada oferta e lidar com uma disponibilidade de máquinas que muda ao longo do tempo. Uma tarefa de geração de embeddings em lote ou um experimento de fine-tuning reproduzível pode se encaixar bem, desde que os dados de entrada e checkpoints sejam preservados após o fim da instância. O limite está nos custos específicos de cada host: computação, armazenamento e transferência de dados nos dois sentidos podem ter cobranças separadas. Escolha Vast.ai quando puder adaptar a solução às condições da oferta, sem depender de um comportamento idêntico entre todas elas.

Indicado para: Experimentos sensíveis a custo, processamento em lote e treinamentos que podem ser retomados a partir de checkpoints.
Diferencial: Escolha por host entre aluguéis sob demanda, reservados e interrompíveis.
Preço: Tarifas de GPU definidas pelo host e cobradas por segundo, mais armazenamento e transferência; confira a oferta inicial da configuração desejada na página de preços atualizados do Vast.ai, consultada em 30 de outubro de 2026.
Teste grátis: A página de preços consultada não informava teste gratuito de GPU.

A oferta mais barata só é útil se o hardware atender à tarefa. O catálogo consultado do Vast.ai lista RTX 3090 e RTX 4090 de 24 GB, L40S de 48 GB e H100 SXM de 80 GB. Primeiro, filtre pela memória e pelo software necessários. Depois, compare CPU, memória do sistema, armazenamento, condições de transferência e localização de cada host.

A computação é medida por segundo durante a execução. O armazenamento continua sendo cobrado enquanto a instância existir, inclusive quando estiver parada. As tarifas de upload e download variam por host. Assim, uma GPU barata que precisa baixar repetidamente um modelo ou conjunto de dados grande pode sair cara para uma tarefa curta. Compare todo o caminho dos dados, além da placa de vídeo. A documentação de preços do Vast.ai explica esses componentes.

Em um treinamento interrompível, salvar apenas o arquivo do modelo pode não bastar para uma retomada correta. Preserve o estado necessário ao framework de treinamento e valide a retomada antes de depender dela. Em uma fila de tarefas em lote, atribua identificadores estáveis para que novas tentativas não dupliquem resultados visíveis ao cliente. Esses são critérios de aceitação para contratar capacidade interrompível; não significam que o provedor faz a recuperação por você.

Vast.ai também oferece infraestrutura serverless. Isso não elimina as questões de host e custo de dados: a documentação verificada descreve a cobrança serverless com base nos custos de computação, armazenamento e tráfego da instância. Esta seleção dá mais destaque ao aluguel em marketplace por ser o uso mais claro para uma equipe pequena disposta a administrar essas condições.

Clusters reservados e infraestrutura de nuvem existente

Reserve capacidade depois de medir a demanda estável; mantenha a execução perto da infraestrutura existente quando a mudança gerar mais trabalho do que economia. São motivos diferentes para escolher uma plataforma maior. Uma equipe pequena pode ter qualquer um deles sem precisar contratar na escala de uma grande empresa de nuvem.

6. CoreWeave: para uma necessidade de cluster bem definida

CoreWeave é uma nuvem de infraestrutura de IA com Kubernetes gerenciado em nós de GPU bare-metal. Faz sentido para uma equipe que já passou da fase experimental e tem uma necessidade de computação planejada. Kubernetes coordena contêineres entre máquinas; é útil quando a implantação exige essa orquestração e há alguém responsável por ela. Para equipes pequenas, os limites estão na alocação e na operação: contratar por nó e usar um cluster gerenciado ainda exige uma carga de trabalho clara, um plano de armazenamento e um responsável pela operação. Inclua CoreWeave na avaliação quando o planejamento de capacidade for uma necessidade real, em vez de usá-lo como ponto de partida para descobrir as exigências do modelo.

Indicado para: Equipes com demanda conhecida por clusters e capacidade de operar uma carga de trabalho em Kubernetes.
Diferencial: Kubernetes gerenciado em nós bare-metal, com rede e isolamento para clusters.
Preço: A tabela da América do Norte lista uma instância GH200 com uma GPU por $6.50/hora; capacidade reservada exige cotação, conforme verificado em 30 de outubro de 2026 na página de preços do CoreWeave.
Teste grátis: A página de preços consultada não informava teste gratuito de GPU.

Leia as colunas do CoreWeave com atenção. Várias instâncias publicadas contêm 8 GPUs, incluindo as linhas de H100, H200, A100, L40 e L40S. A página mostra separadamente preços de inferência com uma GPU, e a nota de rodapé restringe esses preços aos clientes da plataforma de inferência. Dividir o preço de um nó pela quantidade de GPUs ajuda na análise de custos, mas não comprova que seja possível alugar uma fração desse nó para uma tarefa comum em cluster.

A página de preços separa América do Norte e Europa e lista opções sob demanda, spot e reservadas. Para uma reserva, peça a configuração exata dos nós, a localização da implantação, o prazo do compromisso e as condições de capacidade. Confirme também a granularidade da cobrança na cotação: anunciar uma tarifa por hora não comprova que a medição seja feita segundo a segundo.

CoreWeave informa que a transferência de dados pela internet e dentro da rede é gratuita, enquanto armazenamento e serviços de IP público têm cobrança própria. Isso merece análise para cargas com grande movimentação de dados, mas a capacidade de computação contratada ainda precisa ser útil. Transferência barata não compensa um cluster que passa a maior parte da reserva ocioso.

A documentação do CoreWeave Kubernetes Service descreve o plano de controle gerenciado, os nós bare-metal, as redes privadas e a rede de GPUs. Para uma equipe pequena de IA, a pergunta decisiva é quem assume a operação: quem vai empacotar tarefas, acompanhar falhas, gerenciar segredos e restaurar o serviço? Se for a mesma pessoa que ainda está validando a aplicação, um Pod ou uma API mais simples pode colocar uma funcionalidade no ar mais cedo.

7. Google Cloud: quando a GPU precisa ficar perto da aplicação existente

Google Cloud oferece máquinas virtuais do Compute Engine com GPUs. É um candidato natural quando a aplicação e os dados já estão hospedados lá. Manter a execução do modelo perto do restante do sistema pode simplificar a decisão de implantação, mesmo quando uma nuvem especializada oferece uma cotação atraente de GPU. O obstáculo é o acesso: tipo de máquina, região, cota e disponibilidade física precisam coincidir. Escolha Google Cloud quando a carga de trabalho se beneficiar da localização e da operação já estabelecida, sem tratar o preço inicial da GPU como o preço de um servidor completo.

Indicado para: Quem vai acrescentar processamento com GPU a uma aplicação já operada no Google Cloud.
Diferencial: Famílias de máquinas com GPU, disponibilidade regional documentada e controles de cota.
Preço: Uma T4 acoplada em Iowa começa em $0.35/hora somente pela GPU, mais a VM, conforme verificado em 30 de outubro de 2026 na página de preços de aceleradores do Google.
Teste grátis: Não é possível adicionar GPUs durante o Free Trial; é necessário fazer upgrade para uma conta paga.

Quanto custa uma GPU no Google Cloud? Inclua a VM na conta

Uma GPU acoplada é um recurso adicional, não uma máquina inteira. A T4 citada tem 16 GB de memória de GPU. Se a aplicação precisa de mais memória ou de outro acelerador, escolha outra configuração antes de montar o orçamento com base nessa tarifa inicial.

O Google também lista famílias de máquinas com GPUs integradas, incluindo G2 com L4, A2 com variantes A100 e variantes A3 com H100 ou H200. O preço de uma máquina integrada e o de uma GPU acoplada cobrem recursos diferentes. Inclua o tipo de máquina escolhido na estimativa, junto com armazenamento e rede.

O Compute Engine cobra por segundo após um mínimo de um minuto. Uma VM ligada e ociosa continua sendo cobrada. Reservas também podem gerar cobrança mesmo sem os recursos terem sido iniciados; reservar disponibilidade e executar uma tarefa são decisões diferentes. As regras de cobrança do Compute Engine descrevem esses limites.

Disponibilidade de GPUs no Google Cloud: ter cota não basta

A presença de uma GPU no catálogo não garante que sua conta consiga iniciá-la hoje na zona desejada. O Google documenta o suporte a GPUs por zona, e os controles de cota são separados da capacidade física disponível. Confira a máquina desejada na lista de regiões e zonas de GPU e depois confirme as cotas de GPU necessárias.

Por exemplo, uma equipe que atende clientes perto do banco de dados existente deve identificar localizações próximas aceitáveis antes de solicitar uma configuração de GPU. Se a zona desejada estiver sem capacidade, mover apenas o servidor do modelo para mais longe pode alterar tanto o tempo de resposta quanto o caminho de transferência de dados. Trate essa alternativa como uma mudança na aplicação que precisa ser testada.

O Free Trial tem uma restrição própria: não permite adicionar GPUs nem solicitar aumentos de cota. O Free Tier contínuo do Google também exclui GPUs. Portanto, um anúncio de créditos de boas-vindas não comprova que uma conta nova poderá iniciar imediatamente um experimento com GPU. A regra está nos termos do próprio Google.

Como escolher uma GPU na nuvem para IA?

Descarte o hardware que não comporta a carga de trabalho antes de comparar os provedores que o oferecem. A memória da GPU, geralmente chamada de VRAM, armazena o modelo e o estado necessário para executá-lo. Um modelo que carrega no limite da memória ainda pode falhar quando chega um prompt mais longo ou outra requisição simultânea.

Comece com uma estimativa apenas dos pesos. Com 16 bits, cada parâmetro ocupa 2 bytes; com 4 bits, o peso bruto ocupa meio byte. Assim, um modelo de 8 bilhões de parâmetros tem cerca de 16 GB de pesos em 16 bits ou 4 GB de pesos brutos em 4 bits. Um modelo de 32 bilhões de parâmetros resulta em 64 GB ou 16 GB; um de 70 bilhões, em 140 GB ou 35 GB. Esses são nossos cálculos em GB decimais, e não requisitos medidos de inferência. O guia de dimensionamento do Runpod apresenta a regra de memória usada como base.

O espaço que falta nessa conta importa. O ambiente de inferência precisa de memória de trabalho, e o cache KV armazena o estado da atenção conforme a geração avança. O comprimento do contexto e as requisições simultâneas alteram esse estado. Um “modelo de 35 GB” não implica uma implantação que caiba em 35 GB. A documentação de cache do Hugging Face explica por que o cache exige uma decisão de memória separada.

Use placas de 24 GB, 48 GB e 80 GB como faixas de avaliação, sem tratá-las como garantias. Um modelo pequeno e quantizado pode deixar uma folga útil em uma placa de 24 GB. Um modelo maior, contexto mais longo ou mais requisições simultâneas pode exigir outra faixa. Reserve uma margem explícita sobre o maior uso de memória observado, em vez de dimensionar a partir da menor requisição bem-sucedida.

Fine-tuning muda o problema. O treinamento completo acrescenta gradientes, estado do otimizador e ativações salvas. Métodos baseados em adaptadores atualizam um subconjunto menor de parâmetros, o que pode reduzir os requisitos, mas não elimina todos os custos de memória. Conseguir executar inferência não comprova que o fine-tuning completo caberá na mesma placa. Consulte a composição do uso de memória no treinamento e a visão geral do fine-tuning eficiente em parâmetros.

Depois, confira a variante da GPU e a compatibilidade de software. Um provedor listar H100 não comprova que todas as ofertas de H100 tenham o mesmo formato físico, configuração de memória, alocação de CPU ou interconexão. Várias GPUs também exigem um framework capaz de dividir o trabalho de forma eficiente; contratar mais placas não resolve automaticamente uma tarefa lenta ou grande demais.

Termine pelo ciclo completo de cobrança. Para cada finalista, separe inicialização, trabalho útil, espera com o ambiente pronto, encerramento e armazenamento mantido. Estime um mês com base na rotina esperada, incluindo períodos ociosos e novas tentativas. Uma máquina alocada continuamente e uma tarefa curta executada todos os dias exigem orçamentos diferentes, mesmo quando a tarifa por hora é idêntica.

Qual provedor faz mais sentido para você?

A escolha muda primeiro conforme a necessidade de controlar o ambiente de execução e, depois, conforme a utilidade de mantê-lo pronto para responder. Se uma API compatível entrega a funcionalidade, comece avaliando Together AI. Se seu próprio código de inferência é essencial e o tráfego varia, compare Modal com Runpod Serverless. Se precisa de um ambiente interativo ou de uma execução prolongada de fine-tuning, comece por Runpod Pods e instâncias Lambda.

Para processamento em lote que pode ser retomado e tem flexibilidade de localização, acrescente Vast.ai. Para uma carga conhecida de cluster com um responsável pela operação, inclua CoreWeave. Se a aplicação já depende de uma localização e de uma estrutura operacional específicas do Google Cloud, avalie a capacidade de GPU dessa infraestrutura antes de arcar com a migração para outro provedor.

Reservar capacidade faz sentido quando você sabe que o hardware continuará útil durante o prazo contratado e quando a própria disponibilidade importa. Não faça uma reserva para descobrir a utilização. Execute a carga primeiro, identifique a demanda que persiste nos períodos mais tranquilos e reserve apenas a capacidade justificada por essa base.

Um serviço sensível à latência também pode se beneficiar de capacidade dedicada ou mantida pronta mesmo com um volume relativamente baixo de requisições. Deixar o cliente esperando após cada intervalo sem uso pode custar mais do que um worker ocioso. Meça a primeira resposta após a inatividade e as respostas mais lentas durante os picos; a latência média pode esconder os dois problemas.

Se ainda está decidindo se vale a pena controlar um ambiente de execução com GPU, o guia de chips de inferência versus GPUs explica essa decisão mais ampla sobre controle de hardware.

Como os provedores foram selecionados?

Os critérios são adequação à carga de trabalho, unidade de contratação verificável, memória suficiente, custos de dados, comportamento na inicialização e acesso regional. Os sete provedores abrangem APIs gerenciadas de modelos, aplicações serverless com código próprio, aluguel direto de GPUs, marketplaces e clusters planejados. Cada indicação corresponde a um tipo de tarefa, sem estabelecer um ranking universal de velocidade.

Os preços e as afirmações sobre recursos foram conferidos nas páginas dos fornecedores em 30 de outubro de 2026. Nenhuma GPU foi alugada, e não houve testes de vazão ou disponibilidade para esta comparação. As estimativas dos pesos são cálculos explícitos; as recomendações de plataformas resultam da análise do comportamento documentado.

A seleção mantém o foco em quem desenvolve produtos ou trabalha em uma equipe pequena de IA. Diretórios mais amplos de nuvem, intermediários de contratação e outros grandes provedores acrescentariam nomes sem substituir a primeira decisão: você precisa de um endpoint de modelo, uma máquina ou um cluster? Um provedor só deve entrar na avaliação final se conseguir fornecer a configuração necessária em uma localização que você possa usar.

Quais escolhas evitar?

Evite um modelo de contratação inadequado para sua carga de trabalho, mesmo quando o fornecedor é uma boa escolha em outro contexto.

• Capacidade interrompível do Vast.ai para uma tarefa que não consegue retomar ou repetir a execução com segurança. Valide a recuperação antes de assumir o risco de interrupção.
• Runpod Community Cloud quando o plano depende de anexar um volume de rede do Runpod. Essa opção de armazenamento é para Pods no Secure Cloud.
• Modal com escala reduzida a zero quando toda primeira resposta precisa cumprir uma meta rigorosa de latência e você ainda não mediu a inicialização. Inclua capacidade mantida pronta no orçamento ou altere a implantação.
• Lambda 1-Click Clusters ou uma reserva do CoreWeave enquanto a quantidade útil de GPUs e a duração da carga ainda forem estimativas sem validação. Comprove a demanda primeiro com um aluguel menor.
• Together AI serverless quando o checkpoint necessário ou o comportamento do ambiente de execução estiver fora do que a API oferece. Avalie os produtos dedicados ou um ambiente de GPU programável.
• Free Trial do Google Cloud sem upgrade como plano para acesso imediato a GPUs. As restrições de GPU são explícitas.

Dúvidas sobre GPU na nuvem

Quais são os principais provedores de GPU na nuvem?

Os sete provedores comparados aqui são Runpod, Lambda, CoreWeave, Vast.ai, Modal, Together AI e Google Cloud. Comece pela categoria de produto necessária: API gerenciada de modelos, computação serverless com código próprio, máquina sob demanda, aluguel em marketplace ou capacidade reservada em cluster. As seções de cada provedor explicam onde essas categorias se sobrepõem.

Existe GPU na nuvem grátis?

O plano Starter do Modal inclui créditos mensais limitados de computação, sem oferecer acesso ilimitado a GPUs, e os tokens de Shared Endpoint são cobrados à parte. O Free Trial do Google bloqueia GPUs acopladas até o upgrade para uma conta paga, enquanto o Free Tier contínuo exclui GPUs. Together AI exige expressamente pagamento antecipado para o acesso. Use créditos para avaliar uma carga de trabalho, sem tratá-los como um plano de capacidade para produção.

Como comparar serviços de GPU na nuvem?

Compare o mesmo checkpoint, precisão, comprimentos de entrada e simultaneidade na variante exata de GPU e no mesmo tamanho de alocação. Inclua inicialização e ociosidade cobradas, armazenamento, transferências e trabalho perdido por falhas. O resultado útil é o custo do trabalho concluído que atende às exigências de latência e recuperação, e não o menor número ao lado de “GPU-hora”.

Na próxima semana, execute a mesma carga pequena, com os mesmos critérios de aceitação, em dois finalistas. Registre o pico de memória, o tempo até o primeiro resultado útil, a vazão de tarefas concluídas, o período cobrado pelos recursos e o custo que permanece após a parada. Para treinamento, ensaie a recuperação a partir de um checkpoint salvo; para inferência, teste uma requisição após a inatividade e um pico de acesso. Amplie a implantação somente quando essas evidências sustentarem a decisão.

Receba o checklist de auditoria de fluxos de trabalho de IA para negócios e a newsletter para quem opera esses sistemas.