VPS com GPU: quando você realmente precisa de uma

Precisa de uma VPS com GPU ou a CPU é suficiente?

Uma VPS com GPU altera 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. Não altera mais nada. Se a sua carga de trabalho for um modelo de chat quantizado de 7B a 27B que responde a uma pessoa de cada vez, um trabalho de embeddings com baixo volume ou transcrição de voz com Whisper small, uma VPS comum com CPU e RAM suficiente já dá conta do trabalho. Comece pela CPU, meça o valor que está a causar problemas e só depois faça um upgrade.

A razão é a largura de banda da memória. Quando um modelo de linguagem gera um token, lê da memória todos os pesos de que precisa. Um modelo 8B quantizado para 4 bits ocupa aproximadamente 4.7 GB em disco e aproximadamente o mesmo na memória. Assim, gerar um token implica transferir cerca de 4.7 GB. Divida a largura de banda da memória da máquina por esse valor para obter o limite máximo de tokens por segundo. Essa única divisão explica quase todos os benchmarks que irá encontrar.

O que uma GPU realmente oferece

Largura de banda. A DDR5 de servidor num host moderno transfere dezenas de gigabytes por segundo. A memória da GPU (VRAM, video RAM) transfere centenas a mais de mil. O rácio corresponde ao ganho de velocidade, e é elevado.

Capacidade com velocidade. Um sistema com CPU e 64 GB de RAM consegue carregar um modelo 70B a 4 bits. Vai executá-lo a um ritmo mais próximo da leitura do que de uma conversa. Uma GPU só ajuda neste caso se o modelo couber na VRAM, porque, assim que as camadas passam para a RAM do sistema, o caminho lento volta a assumir o controlo.

Throughput de lotes. Esta é a parte que as pessoas subestimam. Uma GPU a gerar texto para um utilizador deixa a maior parte da sua capacidade de computação inativa, porque está à espera da memória. Ao processar 20 pedidos em simultâneo, a mesma leitura dos pesos serve os 20 pedidos. O número agregado de tokens por segundo aumenta várias vezes, enquanto a velocidade por utilizador diminui pouco. Uma CPU não faz isto. Dois utilizadores concorrentes num sistema com CPU reduzem aproximadamente para metade a velocidade um do outro. Se estiver a criar uma API chamada por muitos clientes, o processamento em lotes é 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 é nesta tarefa que as GPUs ganham pela maior margem. Um contexto de 30,000 tokens que uma CPU processa penosamente durante um minuto demora alguns segundos numa GPU. Os sistemas de retrieval que inserem documentos em todos os pedidos sentem este efeito constantemente.

Números 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. Servem como orientação da ordem de grandeza, não como garantia. A quantização, o comprimento do contexto e o mecanismo de inferência podem alterar esses valores.

[
  {
    "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 num sistema com CPU e DDR5. Isso corresponde aproximadamente a cinco vezes mais, o que acompanha a proporção da largura de banda, e não uma diferença no poder de computação bruto. O débito 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 acrescenta trabalho que essa divisão simples ignora.

Para comparação, uma pessoa lê cerca de 5 a 10 palavras por segundo. Qualquer valor igual ou superior a 15 tokens por segundo já parece uma velocidade normal de escrita para um único leitor. É por isso que tantas configurações que usam apenas CPU são suficientes na prática.

Dimensionamento da VRAM antes da compra

O tamanho do ficheiro do modelo é o mínimo necessário, não o requisito completo. Reserve espaço para os pesos, para a 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: use o tamanho do ficheiro 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 a 4 bits ocupa cerca de 16 GB e precisa aproximadamente de 20 GB. Um modelo 70B a 4 bits ocupa cerca de 40 GB e requer uma placa de 48 GB ou duas placas menores. O mesmo cálculo continua a funcionar para modelos muito maiores, e o cálculo de VRAM para um modelo de 2.8 biliões de parâmetros como o Kimi K3 mostra em que ponto escolher uma placa deixa de ser sequer a questão principal.

Os contextos longos quebram esta regra. A cache KV cresce linearmente com o comprimento do contexto e, com 128k tokens, pode exceder os próprios pesos. Se pretende usar contextos longos, dimensione primeiro para a cache e confirme que opções de quantização da cache o seu motor disponibiliza.

Verifique o que a máquina realmente tem

Numa instância com GPU, confirme primeiro que o driver deteta a placa.

nvidia-smi

A tabela deve listar o nome da GPU, a versão do driver e a memória utilizada em relação ao total. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver significa que o driver está em falta ou que o módulo do kernel não foi recompilado depois de uma atualização do kernel. Numa imagem Ubuntu padrão, a correção costuma ser sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, seguida de um reboot para carregar o novo módulo.

Para contentores, o driver, por si só, não é suficiente. O Docker precisa do NVIDIA Container Toolkit para passar o dispositivo para o contentor.

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 a partir de um contentor:

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

A mesma tabela deve ser apresentada. Uma linha docker: Error response from daemon: could not select device driver, que indique uma capacidade de GPU que não pode ser satisfeita, significa que o toolkit está instalado, mas o Docker nunca foi reconfigurado ou reiniciado. Nesse caso, execute novamente a linha nvidia-ctk e faça o restart. No Compose, o equivalente é uma entrada deploy.resources.reservations.devices cujo driver é nvidia e cuja lista de capacidades contém gpu. Esta entrada pode ser integrada nas definições de serviço habituais descritas em Docker Compose numa VPS.

Meça antes de atualizar

Execute o modelo que pretende realmente utilizar no servidor CPU que já tem e registe os valores. Com Alojamento próprio de um LLM com Ollama numa VPS, basta uma flag:

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

O resultado termina com os tempos de execução. eval rate é a velocidade de geração, em tokens por segundo. prompt eval rate indica a velocidade a que a máquina leu a sua entrada. Estes dois valores mostram qual é a atualização mais útil: um eval rate baixo indica um problema de largura de banda da memória, enquanto um prompt eval rate baixo em entradas longas indica um problema de capacidade de processamento.

Num servidor com GPU, confirme que o modelo foi realmente carregado nela:

ollama ps

A coluna PROCESSOR apresenta 100% GPU quando tudo cabe na GPU, ou algo como 43%/57% CPU/GPU quando isso não acontece. Uma divisão parcial costuma ser pior do que espera, porque cada token continua a aguardar pela metade mais lenta.

A questão do custo

As instâncias GPU custam várias vezes mais do que uma instância CPU equivalente e são cobradas por cada hora em que existem, não pelos tokens que produzem. Uma GPU sempre ligada a servir alguns pedidos por dia é a forma mais dispendiosa de executar inferência. O ponto de equilíbrio é a utilização: uma GPU ocupada tem um custo baixo por token, enquanto uma GPU ociosa é puro desperdício.

Há três padrões eficazes. Mantenha o trabalho contínuo de baixo volume numa VPS CPU. Envie os pedidos difíceis ocasionais para uma API alojada e pague por token. Alugue uma GPU à hora para tarefas em lote, fine-tuning ou uma execução em massa de embeddings e, depois, destrua-a. É normal combinar estas opções. A disciplina orçamental descrita em Controlo de custos de um agente de IA numa VPS sempre ligada também se aplica aqui, mas a diferença é que o tempo ocioso é a fuga de custos, e não a quantidade de tokens.

O que continua a funcionar bem sem uma GPU

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

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

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

Tudo o que possa ser considerado um trabalho em lote. Se ninguém estiver a acompanhar o ecrã, a duração total é uma questão de agendamento, não um requisito.

O que realmente precisa de uma GPU: treino ou fine-tuning para além de um adaptador pequeno, atendimento de muitos utilizadores em simultâneo, geração de imagens e vídeo e voz em tempo real, quando a latência é o próprio produto.

FAQ

Quanta VRAM preciso para um modelo 7B ou 8B?

Cerca de 6 GB para um modelo 8B quantizado a 4 bits com um contexto normal de 8k a 16k. Os pesos ocupam aproximadamente 4.7 GB. O restante corresponde à cache KV e a cerca de 1 GB de overhead. Uma placa de 12 GB deixa uma margem confortável para contextos mais longos. Se pretende executar com um contexto de 128k, dimensione a cache separadamente, porque ela pode crescer mais do que os pesos.

Posso executar o Ollama sem uma GPU?

Sim. O Ollama passa automaticamente para a CPU e precisa apenas de RAM suficiente para manter o modelo. Espere aproximadamente 5 a 12 tokens por segundo para um modelo 8B a 4 bits, dependendo da velocidade da memória. Isso é próximo da velocidade de leitura para um utilizador. Os prompts longos são o verdadeiro problema na CPU, porque ler 30,000 tokens de contexto exige muitos cálculos e demora muito mais do que gerar a resposta.

Por que a minha GPU é apenas ligeiramente mais rápida do que a CPU?

A causa habitual é o modelo não caber inteiramente na VRAM. Nesse caso, algumas camadas são executadas na CPU e cada token fica à espera da parte mais lenta. Execute ollama ps e confirme se a coluna PROCESSOR mostra 100% GPU. Se aparecer uma divisão, use uma quantização menor ou um modelo menor. A outra causa comum é um benchmark curto em que o tempo de carregamento do modelo domina a medição.

Vale a pena usar uma GPU VPS para um único utilizador?

Normalmente, não. Uma pessoa lê a 5 a 10 palavras por segundo, e uma máquina com CPU já produz tokens a uma velocidade superior para modelos até cerca de 13B. Os casos que justificam o custo para um único utilizador são prompts longos, geração de imagens e fine-tuning. Servir muitos utilizadores em simultâneo é o argumento mais forte, porque o batching permite que uma GPU responda a vinte pedidos por um custo próximo do custo de responder a um pedido.

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

Alugue-a por hora quando a carga for intermitente: fine-tuning, uma execução em massa de embeddings ou um trabalho de transcrição em lote. Mantenha-a sempre ligada apenas quando a placa estiver ocupada durante a maior parte do tempo, porque uma instância GPU é cobrada pelo tempo de existência, não pelos tokens produzidos. Um assistente com pouco tráfego fica mais barato numa CPU VPS ou numa API alojada com pagamento por token do que numa GPU ociosa.