VPS com GPU: quando você realmente precisa de uma

Você precisa de um VPS com GPU ou a CPU é suficiente?

Um VPS com GPU muda duas coisas ao executar um modelo por conta própria: a velocidade de geração dos tokens e o tamanho máximo do modelo que cabe na memória. Ele não muda mais nada. Se sua carga de trabalho usa um modelo de chat quantizado de 7B a 27B respondendo a uma pessoa por vez, executa um trabalho de embeddings em baixo volume ou faz transcrição de fala com Whisper small, um VPS comum com CPU e RAM suficiente já dá conta. Comece com a CPU, meça o número que está causando o problema e depois aumente os recursos.

O motivo é a largura de banda da memória. Quando um modelo de linguagem gera um token, ele lê da memória todos os pesos necessários. Um modelo 8B quantizado para 4 bits ocupa aproximadamente 4.7 GB no disco e cerca da mesma quantidade na memória. Portanto, gerar um token significa transferir cerca de 4.7 GB. Divida a largura de banda da memória da máquina por esse número para obter o limite de tokens por segundo. Essa única divisão explica quase todos os benchmarks que você encontrará.

O que uma GPU realmente oferece

Largura de banda. A memória DDR5 de um servidor em um host moderno processa dezenas de gigabytes por segundo. A memória da GPU (VRAM, video RAM) processa de centenas a mais de mil. Essa proporção determina o ganho de velocidade, que é grande.

Capacidade com velocidade. Uma máquina com CPU e 64 GB de RAM pode carregar um modelo 70B em 4 bits. Ele funcionará em um ritmo mais próximo da leitura do que de uma conversa. Uma GPU só ajuda nesse caso se o modelo couber na VRAM, porque, assim que as camadas excedem a capacidade e passam para a RAM do sistema, o caminho lento volta a controlar o processamento.

Throughput em lote. Esta é a parte que as pessoas subestimam. Uma GPU que gera respostas para um usuário permanece com a maior parte da capacidade de computação ociosa, pois fica aguardando a memória. Atenda 20 solicitações ao mesmo tempo, e a mesma leitura dos pesos atenderá às 20. A quantidade agregada de tokens por segundo aumenta várias vezes, enquanto a velocidade por usuário quase não diminui. Uma CPU não faz isso. Dois usuários simultâneos em uma máquina com CPU reduzem aproximadamente pela metade o desempenho um do outro. Se você está criando uma API chamada por muitos clientes, o processamento em lote é o principal argumento a favor de uma GPU, mais do que a velocidade bruta de um único fluxo.

Processamento do prompt. A leitura de um prompt longo é limitada pela capacidade de computação, não pela memória, e é neste ponto que as GPUs vencem pela maior margem. Um contexto de 30,000 tokens que uma CPU processa em um minuto leva alguns segundos em uma GPU. Configurações de recuperação que inserem documentos em cada solicitação sentem esse efeito constantemente.

Valores aproximados e como interpretá-los

O bloco abaixo apresenta valores típicos publicados para uma única sequência de um modelo 8B com quantização de 4 bits, em julho de 2026. Eles servem apenas como orientação de ordem de grandeza, não como garantia. A quantização, o tamanho do contexto e o mecanismo de inferência podem alterá-los.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

A linha da GPU de 24 GB mostra 50 tokens por segundo, contra 11 em um servidor com CPU e DDR5. Isso corresponde a aproximadamente cinco vezes mais, o que acompanha a proporção de largura de banda, e não uma diferença no poder bruto de processamento. A vazão real também fica abaixo do resultado de dividir a largura de banda pelo tamanho do modelo, porque a atenção sobre um contexto crescente adiciona processamento que essa divisão simples não considera.

Para comparação, uma pessoa lê aproximadamente de 5 a 10 palavras por segundo. Qualquer valor igual ou superior a 15 tokens por segundo já parece uma digitação normal para um único leitor. Por isso, muitas configurações que usam somente CPU funcionam bem sem chamar atenção.

Dimensionamento da VRAM antes da compra

O tamanho do arquivo do modelo é o mínimo necessário, não o requisito total. Reserve espaço para os pesos, para o cache KV (cache de chave-valor, a memória por token mantida pelo mecanismo de atenção) e para cerca de 1 GB de sobrecarga.

Uma regra prática em julho de 2026: pegue o tamanho do arquivo do modelo em gigabytes e acrescente 20 por cento para um contexto normal de 8k a 16k. Um modelo 8B de 4.7 GB precisa de cerca de 6 GB de VRAM. Um modelo 27B em 4 bits ocupa cerca de 16 GB e precisa de aproximadamente 20 GB. Um modelo 70B em 4 bits ocupa cerca de 40 GB e precisa de uma placa de 48 GB ou de duas placas menores.

Contextos longos invalidam essa regra. O cache KV cresce linearmente com o tamanho do contexto e, em 128k tokens, pode exceder os próprios pesos. Se você planeja usar contextos longos, dimensione primeiro o cache e verifique quais opções de quantização de cache o seu mecanismo oferece.

Verifique o que a máquina realmente tem

Em uma instância com GPU, confirme primeiro que o driver detecta a placa.

nvidia-smi

A saída deve conter uma tabela com o nome da GPU, a versão do driver e a memória usada em relação ao total. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver significa que o driver está ausente ou que o módulo do kernel não foi recompilado após uma atualização do kernel. Em uma imagem padrão do Ubuntu, a correção geralmente é sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install. Em seguida, reinicie o sistema para carregar o novo módulo.

Para contêineres, apenas o driver não é suficiente. O Docker precisa do NVIDIA Container Toolkit para expor o dispositivo ao contêiner.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Depois, confirme que a passagem do dispositivo funciona dentro de um contêiner:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

A mesma tabela deve aparecer. Uma linha docker: Error response from daemon: could not select device driver que informe o nome de um recurso de GPU que não pode ser atendido significa que o toolkit está instalado, mas o Docker não foi reconfigurado ou reiniciado. Nesse caso, execute novamente a linha nvidia-ctk e faça a reinicialização. No Compose, o equivalente é uma entrada deploy.resources.reservations.devices cujo driver seja nvidia e cuja lista de capabilities contenha gpu. Essa entrada se integra às definições de serviço comuns abordadas em Docker Compose em um VPS.

Meça antes de atualizar

Execute o modelo que você realmente pretende usar no servidor com CPU que já possui e registre os números. Com hospedando um LLM por conta própria com Ollama em um VPS, isso exige apenas uma flag:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

A saída termina com os tempos. eval rate é a velocidade de geração em tokens por segundo. prompt eval rate indica a velocidade com que a máquina leu sua entrada. Esses dois números mostram qual atualização ajuda: um eval rate baixo indica um problema de largura de banda da memória, e um prompt eval rate baixo em entradas longas indica um problema de capacidade de processamento.

Em uma máquina com GPU, verifique se o modelo realmente foi carregado nela:

ollama ps

A coluna PROCESSOR mostra 100% GPU quando tudo cabe, ou algo como 43%/57% CPU/GPU quando não coube. Uma divisão parcial costuma ser pior do que o esperado, porque cada token ainda precisa aguardar a metade mais lenta.

A questão do custo

Instâncias com GPU custam várias vezes mais que uma instância de CPU equivalente. A cobrança é feita por cada hora em que elas existem, não pela quantidade de tokens que produzem. Manter uma GPU sempre ligada para atender a poucas solicitações por dia é a forma mais cara de executar inferência. O ponto de equilíbrio é a utilização: uma GPU ocupada tem baixo custo por token, enquanto uma GPU ociosa é puro desperdício.

Três padrões funcionam de forma previsível. Mantenha o trabalho contínuo de baixo volume em um VPS com CPU. Envie solicitações difíceis e ocasionais para uma API hospedada e pague por token. Alugue uma GPU por hora para jobs em lote, fine-tuning ou uma execução em massa de embeddings e, depois, destrua a instância. É normal combinar essas opções. A disciplina de orçamento descrita em controle de custos de agentes de IA em um VPS sempre ligado também se aplica aqui. A diferença é que o vazamento está no tempo ocioso, e não na quantidade de tokens.

O que continua funcionando bem sem uma GPU

Embeddings em baixo volume. Um modelo pequeno de embeddings processa centenas de documentos curtos por minuto usando alguns núcleos de CPU, e um índice criado uma vez não precisa ser rápido.

Whisper small e base para transcrição. O faster-whisper em CPU faz transcrição quase em tempo real com o modelo small, o que é suficiente para um pipeline executado durante a noite.

Modelos de chat quantizados de até aproximadamente 27B, para um ou dois usuários. Lentos, legíveis e utilizáveis.

Qualquer tarefa que você classificaria como um job em lote. Se ninguém estiver acompanhando a tela, a velocidade do tempo de execução é uma questão de agendamento, não um requisito.

O que realmente precisa de uma GPU: treinamento ou fine-tuning além de um adaptador pequeno, atendimento a muitos usuários simultâneos, geração de imagens e vídeos e fala em tempo real, quando a latência é o produto.

FAQ

De quanta VRAM preciso para um modelo 7B ou 8B?

Cerca de 6 GB para um modelo 8B quantizado em 4 bits com um contexto normal de 8k a 16k. Os pesos ocupam aproximadamente 4.7 GB. O restante corresponde ao cache KV e a cerca de 1 GB de sobrecarga. Uma placa de 12 GB deixa uma margem confortável para contextos mais longos. Se você pretende usar um contexto de 128k, dimensione o cache separadamente, pois ele pode ficar maior que os pesos.

Posso executar o Ollama sem uma GPU?

Sim. O Ollama usa a CPU automaticamente como alternativa e precisa apenas de RAM suficiente para carregar o modelo. Para um modelo 8B em 4 bits, espere aproximadamente 5 a 12 tokens por segundo, dependendo da velocidade da memória. Isso é próximo da velocidade de leitura para um usuário. Prompts longos são o principal problema na CPU, pois processar 30,000 tokens de contexto exige muito processamento e demora bem mais que gerar a resposta.

Por que minha GPU é apenas um pouco mais rápida que a CPU?

A causa mais comum é o modelo não caber inteiramente na VRAM. Nesse caso, algumas camadas são executadas na CPU, e cada token precisa esperar pela parte mais lenta. Execute ollama ps e verifique se a coluna PROCESSOR mostra 100% GPU. Se houver uma divisão, use uma quantização menor ou um modelo menor. Outra causa comum é um benchmark curto, no qual o tempo de carregamento do modelo domina a medição.

Vale a pena usar uma GPU VPS para um único usuário?

Geralmente, não. Uma pessoa lê de 5 a 10 palavras por segundo, e uma máquina com CPU já produz tokens mais rapidamente que isso para modelos de até aproximadamente 13B. Os casos que justificam o custo para um único usuário são prompts longos, geração de imagens e fine-tuning. Atender muitos usuários simultaneamente é o principal argumento, pois o processamento em lote permite que uma GPU responda a vinte solicitações por um custo próximo ao de responder a uma.

Devo alugar uma GPU por hora ou mantê-la sempre ativa?

Alugue por hora quando o trabalho ocorrer em picos: fine-tuning, uma execução em lote para gerar embeddings ou um trabalho de transcrição em lote. Mantenha a GPU sempre ativa apenas quando a placa permanecer ocupada, pois uma instância de GPU é cobrada pelo tempo em execução, não pela quantidade de tokens produzidos. Um assistente com pouco tráfego custa menos em uma CPU VPS ou em uma API hospedada com cobrança por token do que em uma GPU ociosa.