Tutoriais de VPS
Recomendações de GPU VPS 2026: como escolher GPU e configuração para Ollama, ComfyUI e AI Agents
Guia de compra e configuração de GPU VPS: compare GPU cloud, GPU VPS e servidores dedicados, escolha VRAM, CPU, RAM, disco e cobrança para Ollama, ComfyUI, ajuste fino LoRA e AI Agents, com estimativas de preço, checklist de segurança e solução de problemas.
Se você quer rodar Ollama, ComfyUI, Stable Diffusion ou um AI Agent em uma VPS, a verdadeira dificuldade não é digitar um comando Docker, mas sim comprar a GPU certa primeiro. Muitas pessoas olham apenas para o "modelo da GPU" e o "preço por hora", mas ignoram a VRAM, a velocidade de leitura/gravação do disco, os drivers, se a instância será recuperada e se os dados continuam lá depois de desligar.
Este artigo é escrito em torno da decisão de compra: primeiro determine qual tipo de GPU você precisa, depois apresente pontos de partida de configuração para Ollama, ComfyUI, treinamento e AI Agents, e por fim compare instâncias GPU cloud, GPU VPS e servidores GPU dedicados. Os preços mudam com o estoque e a região; os números deste artigo servem apenas para montar um orçamento e não devem ser tratados como cotações de longo prazo.
Se o seu objetivo é "rodar modelos locais ocasionalmente, gerar imagens, testar fluxos de trabalho", priorize instâncias GPU cloud cobradas por hora em vez de assinar diretamente uma GPU VPS de um ano. Assim você pode parar quando terminar e primeiro verificar o modelo, os drivers e os requisitos reais de VRAM.
- Ollama com modelos quantizados 7B/8B: 24GB de VRAM é um ponto de partida confortável; RTX 3090, RTX 4090, L4 ou GPUs equivalentes são opções a considerar.
- Ollama com modelos quantizados 14B/32B: priorize 48GB de VRAM; se o modelo precisar de contexto maior ou mais concorrência, considere 80GB ou mais, ou configurações multi-GPU.
- Geração de imagens com ComfyUI: SDXL geralmente parte de 16GB–24GB de VRAM; com fluxos de trabalho complexos, upscaling ou geração em lote, 24GB é mais estável.
- Ajuste fino LoRA e treinamento em pequena escala: 24GB serve para experimentos iniciais; 32GB–48GB é melhor para reduzir a complicação de batch size e otimização de VRAM.
- AI Agents, APIs ou serviços de equipe online a longo prazo: não dá para olhar só a GPU; no mínimo considere também 8 vCPU, 32GB de RAM, NVMe, IP público fixo, disco persistente e estratégia de backup.
Um princípio prático: compre primeiro por VRAM e depois otimize pela capacidade de processamento da GPU. Por mais forte que seja a GPU, se o modelo não couber na VRAM, no fim ele não vai rodar.
"GPU VPS" pode significar produtos completamente diferentes em cada provedor. Antes de fazer o pedido, confirme o método de virtualização e o método de cobrança.
| Tipo | Cobrança | Cenários adequados | Principais riscos |
|---|---|---|---|
| Instância GPU cloud | Por segundo, por hora ou por mês | Testes de modelos, tarefas curtas, inferência elástica | Se o disco e o IP público continuam sendo cobrados após desligar |
| GPU VPS | Mensal ou por consumo, geralmente com ambiente de sistema fixo | Ollama, ComfyUI, API pessoal em execução prolongada | Se a GPU é exclusiva, se há overselling, se é possível trocar drivers |
| Servidor GPU dedicado | Mensal, locação ou colocation | Alta concorrência estável, treinamento, uso compartilhado em equipe | Prazo mínimo de locação longo, alto custo de máquina e largura de banda |
| Marketplace de GPU sob demanda | Ofertas de provedores, por segundo ou por hora | Processamento em lote de baixo custo, tarefas tolerantes a falhas | Preempção, qualidade do nó, grandes diferenças de rede e persistência de dados |
Tomando como exemplo o marketplace de GPU sob demanda, a Vast.ai informa oficialmente que seus preços são determinados pela oferta e pela demanda, e distingue On-Demand, Interruptible e Reserved: Interruptible pode ser recuperada, enquanto Reserved é adequada para tarefas estáveis. A RunPod também cobra separadamente Pods, Serverless e Clusters, correspondentes a instâncias de longa duração, cargas de inferência e cenários multinó. Não compare diretamente o preço por inferência do Serverless com a mensalidade de uma VPS em execução contínua.
As configurações abaixo são pontos de partida de compra, não uma lista de planos de fornecedores. O mesmo modelo em plataformas cloud diferentes pode ter VRAM, geração PCIe, cota de CPU, disco e rede completamente diferentes.
| Objetivo | VRAM recomendada | Ponto de partida CPU / RAM | Disco recomendado | Instâncias adequadas |
|---|---|---|---|---|
| Ollama 7B/8B quantizado | 16GB–24GB | 4 vCPU / 16GB | 80GB NVMe | RTX 4000, L4, 3090, 4090 |
| Ollama 14B/32B quantizado | 24GB–48GB | 8 vCPU / 32GB | 120GB NVMe | 4090, A6000, A40, L40S |
| ComfyUI / SDXL | 16GB–24GB | 8 vCPU / 16GB | 100GB NVMe | 3090, 4090, L4, A5000 |
| Ajuste fino LoRA | 24GB–48GB | 8–16 vCPU / 32–64GB | 200GB NVMe | 4090, A6000, A40, L40S |
| API de inferência multiusuário | 48GB–80GB | 16 vCPU / 64GB | 200GB+ NVMe | L40S, A100, H100 |
| Treinamento multi-GPU | 80GB+ | 32 vCPU / 128GB+ | 500GB+ NVMe | A100, H100, B200, etc. |
8GB de VRAM consegue rodar modelos pequenos, imagens de baixa resolução e parte da inferência quantizada, mas a margem é muito pequena. Ao aumentar o comprimento do contexto, carregar ControlNet, ativar upscaling de imagem ou solicitações concorrentes, o resultado comum é CUDA out of memory. A menos que você já tenha confirmado que o fluxo de trabalho é fixo e as tarefas são muito leves, 16GB é um mínimo mais razoável e 24GB é o ponto ideal para a maioria dos usuários individuais.
O tamanho do modelo do Ollama não é a única métrica; também é preciso considerar o formato de quantização, o comprimento do contexto, a concorrência e o KV cache. Um modelo 8B Q4 pode caber em 8GB de VRAM, mas isso não significa que ele consiga rodar de forma estável contextos longos, chamadas de ferramentas e múltiplas sessões na mesma máquina.
Para um único usuário com baixa concorrência, dá para começar com 24GB de VRAM e reservar 80GB–120GB para o disco do sistema. Arquivos de modelo, imagens Docker e logs vão ocupar espaço continuamente, e um disco pequeno demais costuma virar problema antes da VRAM. Ao rodar a API, faça o Ollama escutar apenas na rede interna ou no localhost, e deixe o Caddy, Nginx ou um gateway de aplicação fornecer HTTPS, autenticação e limitação de taxa.
Se você quer rodar de forma estável modelos quantizados de 14B ou 32B, 48GB de VRAM é mais tranquilo. 24GB também consegue rodá-los via CPU offload ou quantização mais agressiva, mas a velocidade e a concorrência serão claramente afetadas. Antes de comprar, confirme se a plataforma oferece drivers NVIDIA completos, se a versão do CUDA é compatível com os contêineres e se imagens Docker personalizadas são permitidas.
AI Agents normalmente não ocupam apenas a GPU: bancos de dados vetoriais, navegadores, sandboxes de código, filas, logs e uploads de arquivos consomem CPU, RAM e disco. Para uma única GPU VPS, recomenda-se pelo menos 8 vCPU e 32GB de RAM; se você também rodar PostgreSQL, Redis, SearXNG ou vários Workers, recomenda-se 64GB de RAM, ou separar o banco de dados e o armazenamento de objetos.
O consumo de VRAM do ComfyUI depende do modelo base, da resolução, do sampler, do ControlNet, do LoRA, do VAE e dos nós de upscaling. Não julgue se a configuração é suficiente apenas por "consegue iniciar".
- Apenas SD 1.5, imagens de tamanho pequeno: dá para tentar com 12GB–16GB;
- SDXL, 1024×1024 comum: 16GB–24GB é mais adequado;
- Vários ControlNets, high-res fix, upscaling e filas em lote: 24GB–48GB;
- Geração de vídeo, modelos grandes Flux ou grafos de nós complexos: avalie primeiro com 48GB de VRAM e use GPUs da classe de 80GB quando necessário.
O diretório de modelos do ComfyUI deve ficar em um disco persistente ou em um Volume separado. Depois que uma instância temporária é recuperada, o contêiner pode continuar existindo, mas os modelos, as imagens de saída e os nós personalizados podem não estar mais lá. Ao comprar, confirme: se o disco do sistema e o disco de dados são separados, se o Volume é mantido entre instâncias, se os snapshots são cobrados e se o IP público é liberado após excluir a instância.
Não se limite a multiplicar "preço por hora × 30 dias". O custo completo inclui pelo menos a GPU, CPU/RAM, disco do sistema, Volume persistente, IPv4 público, tráfego de saída, snapshots e tarifas de instância ociosa.
Por exemplo, com base nos preços de exemplo da página pública atual da RunPod, a RTX 3090 custa cerca de $0.50/hora, a RTX 4090 cerca de $0.69/hora, a A40 cerca de $0.44/hora e a L40S cerca de $0.99/hora; se rodarem o dia todo, os custos mensais de processamento GPU seriam aproximadamente $360, $497, $317 e $713 respectivamente, e os preços reais variam com a região, o estoque e o tipo de instância. Instâncias por hora são adequadas para uso intermitente; antes de rodar 24×7 a longo prazo, vale comparar com servidores dedicados mensais ou preços Reserved.
Você pode estimar com esta fórmula:
月成本 = GPU小时价 × 实际运行小时 + 磁盘/月 + Volume/月 + IP/月 + 出站流量 + 快照
Se você só usar à noite, 4 horas por dia, cerca de 120 horas por mês, GPUs por hora costumam valer mais a pena do que alugar o dia todo. Por outro lado, se a API de inferência precisa ficar online o dia todo, o preço e a estabilidade de uma GPU exclusiva mensal geralmente são mais fáceis de controlar.
- A GPU é exclusiva, particionada ou compartilhada?
- A capacidade de VRAM e o modelo da GPU estão claramente indicados na página do pedido?
- A instância pode ser preemptada ou recuperada? Há notificação antes da recuperação?
- Após desligar, a GPU, o disco, o IP e o Volume continuam sendo cobrados?
- É possível usar drivers oficiais da NVIDIA e Docker, e qual é a versão do CUDA?
- Kernels, contêineres e portas personalizados são permitidos?
- O IPv4 público é fixo e muda após reinstalar o sistema?
- O disco de dados é independente da instância de processamento e pode ser mantido após excluir a instância?
- Como são cobrados, respectivamente, snapshots, backups e replicação entre regiões?
- Há limite de tráfego de saída e como é cobrado ou limitado após ultrapassá-lo?
- Existe política de reembolso, migração, troca de GPU e compensação por falhas?
- O provedor oferece console, VNC ou modo de resgate, e você consegue se recuperar sozinho se o driver da GPU quebrar?
Se o atendimento ao cliente não conseguir responder claramente a "se a GPU é exclusiva" e "se os dados são mantidos após excluir a instância", não faça o pedido só porque é barato. Uma diferença de alguns dólares no preço da GPU é muito menor do que o custo de uma perda de dados e uma reinstalação do ambiente.
Servidores GPU geralmente expõem Jupyter, ComfyUI, Open WebUI ou portas de API, e expor diretamente as interfaces de administração à internet é perigoso.
- Permita apenas login SSH por chave, desative o login por senha e restrinja os IPs de administração;
- Use Caddy ou Nginx para HTTPS e não exponha bancos de dados, Redis e o Docker Socket à internet;
- Adicione autenticação ao ComfyUI, Jupyter, Open WebUI e à API do Ollama, ou coloque-os atrás de uma VPN;
- Faça backup separado dos arquivos de modelo e dos arquivos enviados pelos usuários; não faça backup apenas do contêiner;
- Configure alertas para GPU, disco, VRAM, temperatura, reinicializações de contêiner e erros de API;
- Configure alertas de orçamento, saldo e uso anormal para contas de pagamento por uso;
- Fixe as versões das imagens e crie snapshots antes de atualizar CUDA, drivers e PyTorch;
- Tarefas de treinamento e em lote devem salvar checkpoints periodicamente para evitar começar do zero após a recuperação de uma instância preemptada.
Primeiro confirme que a instância realmente tem uma GPU alocada, depois verifique o driver do host, o runtime do contêiner e o NVIDIA Container Toolkit. Não reinstale o PyTorch de imediato; se o driver do host estiver faltando, instalar mais pacotes CUDA dentro do contêiner não vai adiantar.
Reduza, em ordem, o batch size, a resolução e o comprimento do contexto, desative ControlNet ou concorrência desnecessários e depois confirme se outros processos estão ocupando VRAM. Para uso a longo prazo, aumentar a VRAM geralmente economiza mais tempo do que alterar parâmetros repetidamente.
Verifique se a GPU é compartilhada, se a potência está limitada, se o link PCIe está degradado e se a CPU virou gargalo no pré-processamento de dados. Para AI Agents, verifique também a latência da API do modelo, a recuperação vetorial e as ferramentas de navegador, não apenas a utilização da GPU.
Normalmente é porque os modelos foram gravados em uma camada de contêiner temporária ou em um disco temporário. Mapeie o diretório de modelos para um Volume persistente, salve o arquivo Compose, as variáveis de ambiente, a lista de plugins e os scripts de inicialização, e faça backups externos periodicamente.
Se é a primeira vez que você roda IA local, recomenda-se começar com uma instância GPU por hora de 24GB de VRAM, 8 vCPU, 32GB de RAM, 120GB NVMe, e primeiro verificar o fluxo de trabalho real com Ollama ou ComfyUI. Se você só usa algumas horas por dia, inicie e pare sob demanda; se precisar de um serviço de API o dia todo, compare então GPU VPS mensal, instâncias Reserved e servidores dedicados.
Com orçamento limitado, priorize a VRAM e o disco persistente, e não sacrifique a segurança dos dados por um modelo superior. Para modelos grandes, multiusuário e tarefas de treinamento, escolha diretamente soluções de 48GB, 80GB ou até multi-GPU, e inclua bancos de dados, armazenamento de objetos e backups no custo total.
Como próximo passo, liste seus modelos, a concorrência desejada, as horas de funcionamento diárias e se você precisa de uma API pública, e depois filtre as GPU VPS com esses quatro pontos. Assim é menos provável errar do que olhando primeiro para um "ranking de preços de GPU".